
@wottis has joined the channel

greetings

hi - quiet here at this time

thought so. probably most people located in the states or europe.

Yeah, I’m in the UK and it doesn’t really get busy until my afternoon.

maybe should ask the question also here

i got some troubles with FFI and can’t figure out why there’s a pointer value returned instead of an enum. the following pastebin provides the code and the error: https://pastebin.com/bk5RSrvu

Nice! Thanks.

@notjack back to the previous discussion, > Not quite sure what I’d do for responding to user input and sending messages to the server.

maybe I’ll just do them in the impure way then.

OK now there’s one more step. Let’s say, we want the ability to allow the user to write the triggers, and we load all scripts in a certain path in run time. How do we do this?

It’s like a scripting system. Usually, a mud client would be written in C, and then it embeds a Lua vm for scripting, and allows users to write scripts in lua. In my case, I want to write the client in Racket, but also use Racket for scripting.

@pierrebaille has joined the channel

@wottis That probably means that the enum value 203448384
is not in your _TCOD_keycode_t
enum definition.

You can test this by using the #:unknown
flag for your enum.

Giving you something like: (define _TCOD_keycode_t (_enum '(...) #:unknown (lambda (x) x))

What is a good environment for working with .rkt? Currently I’m using a mix of visual studio and dr racket and I’m getting the feeling that for serious racket programming using emacs is a must.

Is there a way to write a GUI app in a declarative way?

@plotnus Many people do serious Racket programming using DrRacket. It has excellent support for custom #lang
s, the best macro stepper, and more. Some probably use it exclusively or nearly exclusively. Some people use it alongside some other editor/env, such as Emacs. (I’m in this category.)

I’m mostly in Emacs, but from time to time fire up DrRacket for specific things.

For Racket in Emacs your two main choices these days are Geiser and racket-mode. Since I wrote the latter, I won’t recommend one. :slightly_smiling_face: I think it’s safe to say that you might prefer Geiser if you work with other Schemes as well as Racket, whereas racket-mode focuses only on Racket and so sometimes has deeper support. ¯_(ツ)_/¯

For scripting, I’d try to avoid runtime code loading and instead make a #lang my-mud
that expands to a program that launches the MUD client. Users would write a file in this lang, where a file that contains nothing but the #lang my-mud
line runs the client with default settings. Then they can add scripts and custom code and whatnot by adding code to their file. This eliminates the need for any sort of runtime code loading, plugin architecture, or script execution mechanism.
I personally haven’t tried that approach with any programs yet, but it’s worth noting that’s basically how the Racket package server works. The package server’s “config file” is basically just a program that calls a main
function provided by the server with a bunch of keyword arguments. It’s much more manageable than dynamic code loading, enables optimizations and reduced loading times via ahead-of-time compilation, and is much easier to implement and extend.

Oh and I just remembered that the frog
static blog generator does this too and there’s some public discussion about how it made the switch from a dynamically loaded config file to a #lang frog
program file.

Found the frog
pull request: https://github.com/greghendershott/frog/pull/194

@hjtimmer has joined the channel

I mostly use emacs + racket-mode but also DrRacket sometimes

Is there a way to query a child of top-level gui window?

like, if I have a frame
, and I want to find a canvas
with a certain label under the frame.

@markx A frame%
has a get-children
method, which returns all the direct child windows of the frame, you can test which child window is an area-container<%>
and call get-children
on it recursively. However, it might be better to keep a reference to the canvas outside the window hierarchy.