Re: add-relative-load-path ? - scm_add_load_path too?
Hi Ian,
Ian Hulin writes:
> I've just seen the add-load-path scheme function in the new git
> documentation.
>
> Please, please, pretty please can we have a scm_add_load_path API
> equivalent callable from C/C++? The LilyPond initialization code
> currently does disgusting things like faking
> (eval (set! %load-path cons ( %load-path ) ) )
I took a look at the relevant Lilypond code:
string s = "(set! %load-path (cons \"" + dir + "\" %load-path))";
scm_c_eval_string (s.c_str ());
and indeed this isn't very nice. I can suggest a couple of alternatives
that are much nicer.
Probably the easiest option here is to simply prepend the desired
directories onto the GUILE_LOAD_PATH environment variable before calling
scm_boot_guile. Its contents will automatically be prepended to
%load-path during Guile initialiation. The nice thing about this method
is that it will work with older versions of Guile as well, at least as
far back as Guile 1.4.
Barring that, the nicer (and more robust) way to prepend to any list is
as follows:
SCM var = scm_c_lookup ("%load-path");
scm_variable_set_x (var, scm_cons (scm_from_locale_string (dir),
scm_variable_ref (var)));
Finally, although I don't recommend it in this case, if you really want
to build an expression to evaluate, it is much more robust to build list
structures instead of strings. In this case:
scm_primitive_eval
(scm_list_3 (scm_from_locale_symbol ("set!"),
scm_from_locale_symbol ("%load-path"),
scm_list_3 (scm_from_locale_symbol ("cons"),
scm_from_locale_string (dir),
scm_from_locale_symbol ("%load-path";
All of these suggestions should work with Guile 1.8 as well as 2.0.x.
Hope this helps.
Regards,
Mark
Re: GNU Guile 2.0.5 released
l...@gnu.org (Ludovic Courtès) writes: > We are pleased to announce GNU Guile release 2.0.5. This release fixes > the binary interface information (SONAME) of libguile, which was > incorrect in 2.0.4. It does not contain other changes. > > Please be sure to upgrade to 2.0.5 if you already installed 2.0.4. > We apologize for the inconvenience. Mozilla, eat your heart out. :) -- Ian Price "Programming is like pinball. The reward for doing it well is the opportunity to do it again" - from "The Wizardy Compiled"
Re: GNU Guile 2.0.4 released
On Mon 30 Jan 2012 23:15, l...@gnu.org (Ludovic Courtès) writes: > All apologies. This should be fixed now with 2.0.5. Thanks for handling the release, Ludo. What a crazy process, this time. Do you have any thoughts about how it might be made smoother in the future? > And note that this significantly increases our average release rate, > which is excellent for publicity, no? :) -- http://wingolog.org/
Re: [PATCH] Doc: protecting procedure->pointer pointers from GC
On Mon 30 Jan 2012 22:32, Neil Jerram writes: > Following debugging of a strange issue where oFono appeared to be > sending a D-Bus signal from the wrong object, but I eventually realised > that the problem was in my own code... The docs are good, but the example is irritating ;) Is there a reason you are unable to use guile-gnome for the object wrapping? You can use the FFI to call scm_from_gtype_instance or whatever it's called, after loading (gnome gobject). Andy -- http://wingolog.org/
Re: GNU Guile 2.0.4 released
Hi, Andy Wingo skribis: > On Mon 30 Jan 2012 23:15, l...@gnu.org (Ludovic Courtès) writes: > >> All apologies. This should be fixed now with 2.0.5. > > Thanks for handling the release, Ludo. What a crazy process, this > time. Indeed. > Do you have any thoughts about how it might be made smoother in the > future? For the SONAME error, I should just have been more carefully reading the check-list (doc/release.org). It’s really PEBKAC here, so the only good fix would be to change the guy. ;-) Regarding bug fixing, there’s probably room for improvement. For instance, when a bug is filed, we could assign a target release for the fix, and stick to it. Perhaps we could have a more formal freeze window also, during which we would only fix new bugs and be extremely conservative about anything else. What do you think? Thanks, Ludo’.
Re: GNU Guile 2.0.5 released
Ian Price skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> We are pleased to announce GNU Guile release 2.0.5. This release fixes >> the binary interface information (SONAME) of libguile, which was >> incorrect in 2.0.4. It does not contain other changes. >> >> Please be sure to upgrade to 2.0.5 if you already installed 2.0.4. >> We apologize for the inconvenience. > > Mozilla, eat your heart out. I am pleased to announce Guile 7, which features an enhanced README. :-) Ludo’.
Re: GNU Guile 2.0.4 released
On Tue 31 Jan 2012 14:20, l...@gnu.org (Ludovic Courtès) writes: > Regarding bug fixing, there’s probably room for improvement. For > instance, when a bug is filed, we could assign a target release for the > fix, and stick to it. Perhaps we could have a more formal freeze window > also, during which we would only fix new bugs and be extremely > conservative about anything else. I don't know. Releases are also energetic times, when people become more active -- and it's not always activity that can be redirected to fixing bugs, unfortunately :/ So if we're too strict, we might lose some of that without it going in other productive directions. The local-eval thing was not satisfying for many reasons, and it did delay the release. Still, it's good to have it in and settled. > What do you think? I guess in summary: I don't know :) Andy -- http://wingolog.org/
Re: add-relative-load-path ? - scm_add_load_path too?
Replying to myself...
> Probably the easiest option here is to simply prepend the desired
> directories onto the GUILE_LOAD_PATH environment variable before calling
> scm_boot_guile.
On second thought, this is probably not a good idea, because you don't
want this setting to propagate to other subprocesses. This is probably
the best thing:
> SCM var = scm_c_lookup ("%load-path");
> scm_variable_set_x (var, scm_cons (scm_from_locale_string (dir),
> scm_variable_ref (var)));
Does that work for you?
Mark
Clearing stale references from the stack
Hi! "Andy Wingo" skribis: > +;; Recurse through a C function that should clear any values that might > +;; have spilled on the stack temporarily. (The salient feature of > +;; with-continuation-barrier is that currently it is implemented as a C > +;; function that recursively calls the VM.) > +;; > +(define* (clear-stale-stack-references #:optional (n 10)) > + (if (positive? n) > + (with-continuation-barrier > + (lambda () > + (clear-stale-stack-references (1- n)) > + > ;;; Call THUNK with a given locale > (define (with-locale* nloc thunk) >(let ((loc #f)) > diff --git a/test-suite/tests/gc.test b/test-suite/tests/gc.test > index 97eeb19..1afcea3 100644 > --- a/test-suite/tests/gc.test > +++ b/test-suite/tests/gc.test > @@ -49,13 +49,6 @@ > ;;; > ;;; > > -(define (stack-cleanup depth) > - ;; Clean up stack space for DEPTH words. This is defined here so that > - ;; `peval' doesn't inline it. > - (let cleanup ((i depth)) > -(and (> i 0) > - (begin (cleanup (1- i)) i > - Note that ‘1-’ here is a subr call (because ‘stack-cleanup’ is interpreted), so both procedures may have a similar effect, no? Thanks, Ludo’.
Re: Clearing stale references from the stack
Hello :-) On Tue 31 Jan 2012 19:02, l...@gnu.org (Ludovic Courtès) writes: > "Andy Wingo" skribis: > >> +;; Recurse through a C function that should clear any values that might >> +;; have spilled on the stack temporarily. (The salient feature of >> +;; with-continuation-barrier is that currently it is implemented as a C >> +;; function that recursively calls the VM.) >> +;; >> +(define* (clear-stale-stack-references #:optional (n 10)) >> + (if (positive? n) >> + (with-continuation-barrier >> + (lambda () >> + (clear-stale-stack-references (1- n)) >> + >> ;;; Call THUNK with a given locale >> (define (with-locale* nloc thunk) >>(let ((loc #f)) >> diff --git a/test-suite/tests/gc.test b/test-suite/tests/gc.test >> index 97eeb19..1afcea3 100644 >> --- a/test-suite/tests/gc.test >> +++ b/test-suite/tests/gc.test >> @@ -49,13 +49,6 @@ >> ;;; >> ;;; >> >> -(define (stack-cleanup depth) >> - ;; Clean up stack space for DEPTH words. This is defined here so that >> - ;; `peval' doesn't inline it. >> - (let cleanup ((i depth)) >> -(and (> i 0) >> - (begin (cleanup (1- i)) i >> - > > Note that ‘1-’ here is a subr call (because ‘stack-cleanup’ is > interpreted), so both procedures may have a similar effect, no? I don't think so. The question for me is, how far up the C stack does this get? For `stack-cleanup' (I have to learn how to type those nice quotes some day), there will never be more than one `1-' frame active on the C stack. With clear-stale-stack-references, there will be `depth' many. I think! Andy -- http://wingolog.org/
Re: [PATCH] Doc: protecting procedure->pointer pointers from GC
Andy Wingo writes: > On Mon 30 Jan 2012 22:32, Neil Jerram writes: > >> Following debugging of a strange issue where oFono appeared to be >> sending a D-Bus signal from the wrong object, but I eventually realised >> that the problem was in my own code... > > The docs are good, but the example is irritating ;) Is there a reason > you are unable to use guile-gnome for the object wrapping? You can use > the FFI to call scm_from_gtype_instance or whatever it's called, after > loading (gnome gobject). Because Ludo and you have made it so easy to be productive with just (system foreign) ! But your implication is right, it is a more interesting and complex question than just that. My current project is a phone application for the GTA04, which is an ARM device with most of the promising software stacks being Debian-based. Hence, aside from Guile itself - where I still have some fixing and upstreaming to do - I'd ideally like not to take on any dependencies other than things that are already available for ARM in Debian unstable. I didn't actually go ahead and check beforehand whether a Guile 2-compatible guile-gnome was available, but I know that guile-2.0 itself has only recently landed in Debian, so I guess I assumed a compatible guile-gnome was very unlikely to be available yet. (And, on checking, I believe that's still correct.) So then it would be a matter of building and packaging guile-gnome for my device. I remember that from Nokia 770 days... It's quite doable, but it takes time (and requires slib and g-wrap first, IIRC), and compared with that it's way easier, and doesn't impede the hack, just to grab the entry points that I need using pointer->procedure. Another relevant factor is that I need relatively few guile-gnome entry points because I'm only using gobject/glib to get gdbus, and the UI is built with Edje, not Gtk/Gnome. In fact it's a strange (but IMO fun) hotchpotch: - Edje/Evas for the UI (using 17 pointer->procedures) - GDBus to access the oFono D-Bus API (using pointer->procedures: 3 for basic GObject stuff, 11 for GVariant handling, and 2 for GDBus). and I will probably add in more stuff for audio routing (PulseAudio?) and accessing contact information (whatever the latest evolution of Evolution Data Services is). But even if I needed a lot more guile-gnome APIs, I'd (at least initially) be tempted to grab a .defs file and try to hack something based on that, rather than compiling C code... I think the key benefit is that the (system foreign) approach is so immediate. I just add whatever API I need there, and the hack continues... My only reservation - and quite a big one - is that it's a bit like going back in time to when compilers had no type checking for pointers. In that sense it is rather fast and loose, compared to C programming. But overall I love it, and I'd suggest that an alternative question (to the one you asked above) would be why do you think we need bindings anymore? Well I hope that's of interest, and I'm sure you'll have interesting counter-thoughts... In case you or anyone wants to look at the code, I've pushed it to http://git.savannah.gnu.org/cgit/ossaulib.git/. The main script is at scripts/phone. Neil
Re: Build Error in master
I've done some debugging. Here is what I know so far: The error happens in scm_bootstrap_vm, which is called before we enter Scheme, so the error is only in the C code. It happens in scm_i_str2symbol, when scm_bootstrap_vm wants to make some symbol. Here's how symbols work: there is a variable called 'symbols', in symbols.c, which is a weak set holding all of our symbols. This is presumably how we intern them. When scm_i_str2symbol wants to make a new symbol, it first checks if the symbol already exists, and if it does not, calls scm_c_weak_set_add_x with the symbols set and the new symbol. scm_i_str2symbol passes the 'symbols' object to scm_c_weak_set_add_x. scm_c_weak_set_add_x then unpacks it (it is an SCM) to get an scm_t_weak_set. That weak set was stored in 'symbols' by scm_symbols_prehistory. However, in the run that fails, scm_c_weak_set_add_x unpacks a *different* scm_t_weak_set value than scm_symbols_prehistory stored there. This value points to memory that is not allocated, which is where we get the segmentation fault. More specifically, In scm_symbols_prehistory, the "symbols" set is at 0x1006cff50, and the SCM 'symbols' is 0x10101cff0 In the failing call, the SCM 'symbols' is 0x10101cff0, but the failing set is at 0x304, which has not been allocated. So the question is, what might change this value wrongly? Does anyone know? Or alternatively, what's a good way for me to debug this? Thanks, Noah On Sun, Jan 29, 2012 at 3:21 PM, Catonano wrote: > > > Il giorno 26 gennaio 2012 23:06, Andy Wingo ha scritto: > >> On Thu 26 Jan 2012 15:26, Noah Lavine writes: >> >> > I just checked out the latest master. I attempted to build it, but got >> > stuck at this point: >> >> Is it http://lists.gnu.org/archive/html/bug-guile/2011-12/msg00058.html >> ? > > > yyes, in my case, this is what happens with the version checked out from > git. > > The tarballed 3.0.2 works fine > > Hope this helps
Should we add scm_to_pointer, or just use SCM_POINTER_VALUE?
I was chatting with rcfox on #guile, who needed to extract the C pointer from a SCM pointer object, from C code. In this case, it was a C callback created using 'procedure->pointer'. I tried to discourage him from using SCM_POINTER_VALUE, because it's undocumented and will embed internal details of our representation into his binary, but he was undeterred :) Should we add 'scm_to_pointer'? For most other accessors, the trend seems to be to discourage use of C macros and move people over to C functions instead. With that in mind, it seems inconsistent to have people using SCM_POINTER_VALUE for lack of a C function to do this job. What do you think? Mark
