Ludovic Courtès escreveu:
> Hello,
>
> Andy Wingo <[EMAIL PROTECTED]> writes:
>
>> ERROR: srfi-18.test: thread-start!:
>> thread activates only after start
>>- arguments: ((syntax-error "memoization"
>> "In file ~S, line ~S: ~A ~S in expression ~S."
>> ("
Ludovic Courtès escreveu:
> Hello,
>
> This is a followup to this discussion:
>
> http://thread.gmane.org/gmane.lisp.guile.devel/7194
>
> The attached patch changes several list-related functions so that they
> don't validate their input with `SCM_VALIDATE_LIST ()' since it's O(n).
>
> A side
Ludovic Courtès escreveu:
> Hello,
>
> Andy Wingo <[EMAIL PROTECTED]> writes:
>
>> ERROR: srfi-18.test: thread-start!:
>> thread activates only after start
>>- arguments: ((syntax-error "memoization"
>> "In file ~S, line ~S: ~A ~S in expression ~S."
>> ("
Hello,
This is a followup to this discussion:
http://thread.gmane.org/gmane.lisp.guile.devel/7194
The attached patch changes several list-related functions so that they
don't validate their input with `SCM_VALIDATE_LIST ()' since it's O(n).
A side-effect (besides performance improvements) is
Hello,
Andy Wingo <[EMAIL PROTECTED]> writes:
> ERROR: srfi-18.test: thread-start!:
> thread activates only after start
>- arguments: ((syntax-error "memoization"
> "In file ~S, line ~S: ~A ~S in expression ~S."
> ("/home/lilydev/vc/guile/srfi/srfi-18.scm
Hi,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Now that we're busy dropping cruft, it would be really nice if we could
> libtool too. (major sigh).
But we don't want to drop supported platforms, so we can't drop
Libtool. And Libtool is friendly, isn't it? :-)
Ludo'.
Hey!
"Julian Graham" <[EMAIL PROTECTED]> writes:
> Thread A wants to lock fat_mutex M. It seizes the administrative lock
> M->lock and examines the state of M. M is held by thread B, so thread
> A prepares to put itself onto the blocking queue for M by calling
> `SCM_TICK'. In order to call `S
Hi Ludovic,
> Let me rephrase it: what can happen is that, during the tick, another
> thread could actually take M, increase `M->level' and mark itself as the
> owner. After the tick, our primary thread takes `M->lock' back,
> thinking it now owns M, and goes to sleep; but M is actually already
>
Ludovic Courtès escreveu:
> Hello,
>
> "Han-Wen Nienhuys" <[EMAIL PROTECTED]> writes:
>
>> autoreconf: running: aclocal --force
>> autoreconf: configure.in: not using Libtool
>> autoreconf: running: /home/hanwen/usr/pkg/ac/bin/autoconf --force
>> configure.in:20: error: possibly undefined macro:
Ludovic Courtès escreveu:
>
> Looks like the machine is missing Libtool or at least that its M4 macros
> cannot be found. You need Libtool 1.5.x, *not* Libtool 2.2.
>
>> How do I get GUILE to actually compile now?
>
> How did you get it to compile last week? :-)
I used my 32 bit laptop, but
Julian Graham escreveu:
>> 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 i
Hi Julian,
"Julian Graham" <[EMAIL PROTECTED]> writes:
> ...
> scm_i_pthread_mutex_unlock (&m->lock);
> SCM_TICK;
> scm_i_scm_pthread_mutex_lock (&m->lock);
> }
> block_self (m->waiting, mutex, &m->lock, timeout);
>
> ...which means that if the lo
Hi,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Would this also explain the 'corruption' in the evaluator we have been
> seeing ("bad bindings at .. ")?
I've seen that after switching branches. Somehow, that must be the
result of files that did not get recompiled, something like that.
Runni
Hello,
"Han-Wen Nienhuys" <[EMAIL PROTECTED]> writes:
> autoreconf: running: aclocal --force
> autoreconf: configure.in: not using Libtool
> autoreconf: running: /home/hanwen/usr/pkg/ac/bin/autoconf --force
> configure.in:20: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
> If this t
Hello,
"Neil Jerram" <[EMAIL PROTECTED]> writes:
> Actually, perhaps it would be nicer to put both those notes in a top
> level file called "ChangeLog", rather than in HACKING.
Yes, that's the most obvious place to put information about ChangeLogs.
Other ChangeLogs can be renamed as you suggeste
Hi Neil,
"Neil Jerram" <[EMAIL PROTECTED]> writes:
> 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)?
I meant 1.10.x, sorry fo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Han-Wen Nienhuys wrote:
> Also, can someone tip me off how I create 64 bit binary on a mixed
> 32/64 machine? I assume the default
> will generate a 32 bit binary.
Actually I would think the default is to generate 64-bit code, but you can pass
gcc t
17 matches
Mail list logo
