gnome-clutter + repl?

gnome-clutter + repl?

[joakim]

hello,

I'm interested in prototyping an application with gnome-clutter and
Guile.

This application will probably be a C application that embedds
Guile. (I've tried many other approaches* but they fail so lets discuss
this particular scenario)

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.

So these appear to be my choices and I'd appreciate help selecting a
good approach:

- Don't use the REPL as is, instead make the C application call the
  Guile evaluation routines. Then I must decide things in advance and
  can't use explorative programming

- Make separate threads for the REPL and Clutter. Then I get boring thread
  synchronisation issues.

It seems guile-gnome-platform take the first approach.


*) Ideally I'd like no C and only Guile. 
I've mostly tried different ways to interface to Clutter from Guile. I
hacked guile-clutter until it compiled but then it didn't want to
runtime link. I tried Sbank, but it didn't work with guile. I also tried
guile-gir, but it didn't work too well either. So until any of these
other approaches pan out I can embedd guile.

-- 
Joakim Verona

Re: gnome-clutter + repl?

[Mark H Weaver]

joakim@verona.se writes:
> 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.
>
> So these appear to be my choices and I'd appreciate help selecting a
> good approach:
>
> - Don't use the REPL as is, instead make the C application call the
>   Guile evaluation routines. Then I must decide things in advance and
>   can't use explorative programming
>
> - Make separate threads for the REPL and Clutter. Then I get boring thread
>   synchronisation issues.

You could minimize the thread synchronization issues as follows:

* Make a procedure (call-within-clutter-thread THUNK) that arranges for
  THUNK to be run within the clutter thread in the near future (and also
  arranging for its result to be returned back to the REPL thread),
  waits for it to run, and returns the result.

* Optionally make convenience syntax for `call-within-clutter-thread'
  that wraps a (lambda () ...) around the provided body.

* Optionally modify the REPL to automatically wrap each expression
  within the convenience syntax for `call-within-clutter-thread'.

One way to implement call-within-clutter-thread would be via a job queue
protected by a mutex, where each element in the queue would contain the
thunk to run, a mutable cell in which to place the result, and a
condition variable with which to signal completion of the job.

     Mark

Re: gnome-clutter + repl?

[Ludovic Courtès]

Hi Joakim!

joakim@verona.se 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’.

Re: gnome-clutter + repl?

[joakim]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi Joakim!
>
> joakim@verona.se 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

Re: gnome-clutter + repl?

[Ludovic Courtès]

Hi Joakim,

joakim@verona.se skribis:

> 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?

Possibly.

> init.scm looks like:
> (define-module (mytest)
>   #:use-module (system repl server))
>
> (spawn-server)

The server may run in the (mytest) module, whereas the
scm_c_define_gsubr call was made in the default module, called
(guile-user).

Check what (current-module) says in each case.

HTH,
Ludo’.

Re: gnome-clutter + repl?

[Andy Wingo]

On Sat 24 Sep 2011 16:57, joakim@verona.se writes:

> - Don't use the REPL as is, instead make the C application call the
>   Guile evaluation routines. Then I must decide things in advance and
>   can't use explorative programming
>
> - Make separate threads for the REPL and Clutter. Then I get boring thread
>   synchronisation issues.

You could try (gnome gobject event-repl), if it still works.

Andy
-- 
http://wingolog.org/