Re: guile-gnome2 - Segmentation fault
On Tue 06 Jul 2010 16:37, Patrick Bernaud writes: > Hi David, > > David Pirotte writes: > > [...] > > Does it crashes for you [any guile-gnome user willing to try?] too? > > Yes it does for me too. > > In versions of gtk >= 2.11, tree iterators (GtkTreeIter) are allocated > through the GSlice memory allocator > (http://library.gnome.org/devel/glib/stable/glib-Memory-Slices.html) > while current guile-gnome is allocating them through the more general > memory-handling g_malloc() and friends. > > Freeing one item allocated with g_malloc() (what guile-gnome does) > with GSlice func (what GTK does) has the consequences you > experimented. > > GtkTextIter is also concerned by the problem and maybe other types > too. > > Until guile-gnome is updated, set the environment variable G_SLICE to > 'always-malloc' > (http://library.gnome.org/devel/glib/stable/glib-running.html#G_SLICE) > and it should be ok. Aah, I see now. Thank you for the analysis. Will fix soon. Andy -- http://wingolog.org/
Re: Best way to call a user defined hook (written in guile) from C when the hook need plenty parameters
On Mon 05 Jul 2010 21:18, Neil Jerram writes: > ri...@happyleptic.org writes: > >> (define (hook-helper %s) (lambda () #\t)) >> >> where %s is the long list of parameters (foo bar baz...) that's inserted by >> the C program. >> And : >> >> (define (hook . args) (local-eval (cons print-user-fields user-fields) >> (procedure-environment (apply hook-helper args > > Using local-eval and procedure-environment like this won't work in Guile > 1.9/2.0, I believe. > > But you could get a similar effect - which I think will still work in > 1.9/2.0 - by creating a module, defining values in it, and then > evaluating in that module. (In Guile, module == top level > environment.) Yes, I think this is the best option, too. FWIW anyway :) Andy -- http://wingolog.org/
Re: Thread and guile environment
On Mon 05 Jul 2010 09:23, ri...@happyleptic.org writes: > Suppose I have a multithreaded C program. Isn't the guile environment supposed > to be shared amongst all threads ? That's what I understood from reading the > docs anyway. > > Yet this simple exemple shows the opposite (see the 3 attached files). > So am I supposed to source my global scheme definitions in all threads > ? Interestingly, the first thread has you in (guile-user), but the second has you in (guile). So you don't see the full definition of format, nor do you see hug. A workaround is to do: scm_with_guile(hug_me, "(begin (set-current-module (resolve-module '(guile-user))) (hug 2))"); instead of scm_with_guile(hug_me, "(hug 2)"); But it's quite ugly. Does anyone have any input as to what module should be current when a thread previously unknown to Guile enters Guile? Andy -- http://wingolog.org/
Re: Jumping back to REPL prompt on ^C
Hi Neil & Taylor, On Sun 04 Jul 2010 21:52, Neil Jerram writes: > Taylor Venable writes: > >> Hi there, I'm writing a piece of code with a web server component, and >> part of that being that I want to jump back to the REPL when one hits >> ^C. So it would go something like this: >> >> scheme@(guile-user)> (start-server) >> ;;; handling requests >> ^C >> scheme@(guile-user)> >> >> What I tried doing was essentially this: >> >> (call/cc (lambda (k) (sigaction SIGINT (lambda (_) (k))) (start-server))) > > Just a couple of notes here. > > First, continuations usually take an argument: the value which will be > the return value of the (call/cc ...) expression. So '(k)' may be > wrong. Indeed, though the intention may be that an escape returns 0 values; unlikely however. > Second, I wonder if you meant (lambda _ ...) instead of (lambda (_) > ...). I often use the former when I want a lambda that accepts any > number of arguments. True, though sigaction handlers do get called with only one argument. >> Except *sometimes* when I hit ^C I ended up with an error that stops >> the guile program completely, seemingly due to the readline library >> that I've enabled in the REPL. When I simplify my test I'm able to >> get the same fatal error all the time. > [..] >> In unknown file: >>?: 0 [catch-closure misc-error "%readline" "readline is not reentrant" () >> #f] You know, I've seen this on a couple occaisions. If you can find out how to reproduce this I would be very interested. In the future you should be able to just return to the prompt on SIGINT by setting a REPL option. Dunno if that works for Taylor, though... Andy -- http://wingolog.org/
Re: Jumping back to REPL prompt on ^C
On Thu 08 Jul 2010 21:31, Andy Wingo writes: >>> Except *sometimes* when I hit ^C I ended up with an error that stops >>> the guile program completely, seemingly due to the readline library >>> that I've enabled in the REPL. When I simplify my test I'm able to >>> get the same fatal error all the time. >> [..] >>> In unknown file: >>>?: 0 [catch-closure misc-error "%readline" "readline is not reentrant" >>> () #f] > > You know, I've seen this on a couple occaisions. If you can find out how > to reproduce this I would be very interested. I believe I have quashed all of these. Let me know if you can still reproduce this with git. Andy -- http://wingolog.org/
Re: Thread and guile environment
-[ Thu, Jul 08, 2010 at 08:48:33PM +0100, Andy Wingo ] > Interestingly, the first thread has you in (guile-user), but the second > has you in (guile). So you don't see the full definition of format, nor > do you see hug. Interresting indeed. Is there a definition of these modules and their purpose somewhere ? > scm_with_guile(hug_me, "(begin (set-current-module (resolve-module > '(guile-user))) (hug 2))"); Ok for me. I think I will have to play with modules anyway (see my other thread). Thank you for your help !
Re: Thread and guile environment
On Fri 09 Jul 2010 17:54, Cedric Cellier writes: > -[ Thu, Jul 08, 2010 at 08:48:33PM +0100, Andy Wingo ] >> Interestingly, the first thread has you in (guile-user), but the second >> has you in (guile). So you don't see the full definition of format, nor >> do you see hug. > > Interresting indeed. > Is there a definition of these modules and their purpose somewhere ? Mmm, some of this is not as documented as it should be. There is "Modules" in the manual, and there is the source of boot-9.scm (fairly well commented). If you have more specific questions, please ask the list. Andy -- http://wingolog.org/
Re: Thread and guile environment
Andy Wingo writes: > On Mon 05 Jul 2010 09:23, ri...@happyleptic.org writes: > >> Suppose I have a multithreaded C program. Isn't the guile environment >> supposed >> to be shared amongst all threads ? That's what I understood from reading the >> docs anyway. >> >> Yet this simple exemple shows the opposite (see the 3 attached files). >> So am I supposed to source my global scheme definitions in all threads >> ? > > Interestingly, the first thread has you in (guile-user), but the second > has you in (guile). So you don't see the full definition of format, nor > do you see hug. That's what I thought too. But in that case I have no idea why my '(define-module (guile-user))' suggestion didn't work. > But it's quite ugly. Does anyone have any input as to what module should > be current when a thread previously unknown to Guile enters Guile? Surely it has to be (guile-user), since that what the end of boot-9.scm moves into - and hence is well-established for the single thread case. I suspect that a program that calls scm_with_guile() on multiple threads can't necessarily predict which of the threads will perform the Guile startup. Neil
