> Would this also explain the 'corruption' in the evaluator we have been
> seeing ("bad bindings at .. ")?
I don't think so; in fact, I just got one of those errors while
looping your test code. I think it's something else, unrelated to the
patch I just sent in. I'll keep looking at it. You ha
Julian Graham escreveu:
> Okay, I think I know what the problem is: Part of the SRFI-18 thread
> start / creation process involves contention for a mutex, and there's
> a bug in fat_mutex_lock code that causes the locking thread to
> sometimes miss an unlocking thread's notification that a mutex is
Okay, I think I know what the problem is: Part of the SRFI-18 thread
start / creation process involves contention for a mutex, and there's
a bug in fat_mutex_lock code that causes the locking thread to
sometimes miss an unlocking thread's notification that a mutex is
available. So it's actually a
Hi,
I'm trying to compile GUILE on a x86_64 machine, to figure out the GC problems
autoreconf: Entering directory `.'
autoreconf: configure.in: not using Gettext
autoreconf: running: aclocal --force -I guile-config -I m4
configure.in:815: warning: macro `AM_GNU_GETTEXT' not found in library
autor
2008/8/30 Ludovic Courtès <[EMAIL PROTECTED]>:
>
> Nevertheless, the change *will* appear in the next stable release.
Do you mean the next 1.8.x release, or the first 1.10.x release
(whenever that might occur)?
Regards,
Neil
2008/8/30 Ludovic Courtès <[EMAIL PROTECTED]>:
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> Ludovic Courtès escreveu:
>
>>> Then I guess I'm happy to abolish ChangeLogs. Two questions remain:
>>>
>>> 1. Should we remove ChangeLog files from the repo?
>>> 2. Should we generate ChangeLogs
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Ludovic Courtès escreveu:
>> Then I guess I'm happy to abolish ChangeLogs. Two questions remain:
>>
>> 1. Should we remove ChangeLog files from the repo?
>> 2. Should we generate ChangeLogs for releases?
>>
>> I'd say "yes" to (1) and "no" to
Hello,
Andy Wingo <[EMAIL PROTECTED]> writes:
> The removal of the scm_i_* functions is an ABI break in the stable 1.8
> series. It should be reverted. (It's a great fix for master though.)
After discussion with Andy on IRC and looking for uses for `scm_i_' in
Google's codesearch, I've become co
Ludovic Courtès escreveu:
> Hey!
>
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> Ludovic Courtès escreveu:
>
>>> That said, the ideal would be something like `add-change-log-entry' that
>>> operates on Git logs instead of ChangeLogs, but there doesn't seem to be
>>> anything like this. DV
Hi,
"Julian Graham" <[EMAIL PROTECTED]> writes:
> Ugh, sorry. One day I'll get the hang of git, I promise. In the
> meantime, find attached a new version of the patch.
Thanks, pushed!
Ludo'.
Hey!
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Ludovic Courtès escreveu:
>> That said, the ideal would be something like `add-change-log-entry' that
>> operates on Git logs instead of ChangeLogs, but there doesn't seem to be
>> anything like this. DVC is said to support things like that, b
Hi Ludovic,
> Furthermore, I think `srfi-18.test' needs to be modified so that, when
> threads aren't available, it does not "(use-modules (srfi srfi-18))" so
> that we don't get the error.
>
> Can you fix that?
Ugh, sorry. One day I'll get the hang of git, I promise. In the
meantime, find att
Hi Julian,
"Julian Graham" <[EMAIL PROTECTED]> writes:
> Ah, yes -- I remember those from five years ago, the first time I
> tried to add thread cancellation support to Guile. Find attached a
> patch that raises an error if `(srfi srfi-18)' is loaded when Guile
> has been built using --without-t
13 matches
Mail list logo
