[email protected] (Ludovic Courtès) writes:
> Hi Joakim!
>
> [email protected] skribis:
>
>> Anyway, the problem is that clutter needs its own event loop,
>> clutter-main, so then I can't simply use the Guile REPL as I'd like.
>
> Maybe you could start a REPL server? (See the (system repl server)
> module.)
>
> You could then use Geiser to connect to it (M-x geiser-connect), which
> should allow you to get a nice development environment.
>
> Hope this helps,
> Ludo’.
Okay this approach started out nicely!
The C code boots both Guile and Clutter in the same thread(I think).
I can access the REPL port with nc. Thus, bliss and happiness so far!
However. Unevitable this happy narrative is disturbed by problems.
I am unable to export a C function to Guile. I've tried snarfing and a
more primitive approach as well. The C function doesn't wind up
available in the REPL. All I get is:
nc localhost 37146
...
(myloadfromdata "")
;;; socket:9:17: warning: possibly unbound variable `myloadfromdata'
socket:9:17: In procedure #<procedure b51600 at socket:9:17 ()>:
socket:9:17: In procedure module-lookup: Unbound variable: myloadfromdata
The only difference I can think of as compared to the documentation is
that inner main looks like this at the moment:
static void
inner_main (void *closure, int argc, char **argv)
{
scm_c_define_gsubr ("myloadfromdata", 1, 0, 0, myloadfromdata);
printf("starting guile server\n");
scm_c_primitive_load("init.scm");
printf("starting clutter\n");
main_view(argc, argv);
}
If I instead use scm_shell (argc, argv); rather than
scm_c_primitive_load("init.scm"); the function is accessible,
so maybe there is some namespace issue?
init.scm looks like:
(define-module (mytest)
#:use-module (system repl server))
(spawn-server)
--
Joakim Verona
