On 01/30/12 14:02, Ludovic Courtès wrote:
We are pleased to announce GNU Guile release 2.0.5.
And we users are pleased to have it. Thank you!!
Regards, Bruce
All apologies. This should be fixed now with 2.0.5.
And note that this significantly increases our average release rate,
which is excellent for publicity, no?
Ludo’.
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.
On 30 Jan 2012, at 22:13, Ludovic Courtès wrote:
> ... and I forgot to bump the SONAME. :-/
>
> I guess I have to push a 2.0.5 tarball now? Thoughts?
Are you sure it was there in earlier versions? Though OS X uses different
objective file format, I could not find it in the .dylib.
Hans
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...
Neil
>From 02d80ad14c3bb8f89d7ba807dac658be6dd06df1 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Mon, 30 Ja
l...@gnu.org (Ludovic Courtès) writes:
> ... and I forgot to bump the SONAME. :-/
>
> I guess I have to push a 2.0.5 tarball now? Thoughts?
I'm afraid I've forgotten the implications of that...
But congratulations and thanks for the release anyway; for my FFI
hacking I particularly appreciate
... and I forgot to bump the SONAME. :-/
I guess I have to push a 2.0.5 tarball now? Thoughts?
Ludo’.
We are pleased to announce GNU Guile release 2.0.4, the next maintenance
release for the 2.0.x stable series.
The Guile web page is located at http://gnu.org/software/guile/ .
Guile is an implementation of the Scheme programming language, with
support for many SRFIs, packaged for use in a wide va
Hi Andy, Ludo,
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
Andy Wingo writes:
> On Mon 30 Jan 2012 07:39, Mark H Weaver writes:
>
>> One idea is to change 'error' into a macro, and use tricks similar to
>> what 'load' does, to cleverly makes it look like a procedure.
>
> Unfortunately this is an incompatible change. Existing compiled files
> which refe
l...@gnu.org (Ludovic Courtès) writes:
> Can we s/scm_call_varargs/scm_call/ instead? (For consistency with
> scm_list_n, it would be ‘scm_call_n’, but that one is already taken for
> something else.)
Excellent suggestion! 'scm_call' it is :)
Thanks,
Mark
Andy Wingo skribis:
> On Mon 30 Jan 2012 02:04, Mark H Weaver writes:
>
>> Andy suggested that we should add these, so here's a patch to do so.
>> Okay to push?
>
> Looks great to me, thanks. Please push.
Can we s/scm_call_varargs/scm_call/ instead? (For consistency with
scm_list_n, it would
On Mon 30 Jan 2012 07:39, Mark H Weaver writes:
> When 'error' is called, the user should _automatically_ be told the
> exact source location where it was called, and the procedure that called
> it should be present in the backtrace. Therefore, we should somehow
> prevent it from being tail-call
On Mon 30 Jan 2012 02:04, Mark H Weaver writes:
> Andy suggested that we should add these, so here's a patch to do so.
> Okay to push?
Looks great to me, thanks. Please push.
Andy
--
http://wingolog.org/
On Mon 30 Jan 2012 00:14, Mark H Weaver writes:
> What do you think?
Please push, thanks!
Andy
--
http://wingolog.org/
15 matches
Mail list logo
