Rob Browning <[EMAIL PROTECTED]> writes:
> In any case, I'll see if I can still get it to hang using
> --without-threads.
I have a tree here where I added a (gc) call before and after the
port-for-each call in popen.scm (in the child). Given that and
--with-threads=yes, "make check" would hang e
A while ago, I finished a SRFI-45 compliant force/delay/eager
implementation for Guile, the core of which is more or less a
translation of the SRFI reference code.
(I started this in part with an eye toward lazy process streams,
i.e. "find -printf ..." -> lazy-stream-of-lines)
The implementation
Greg Troxel <[EMAIL PROTECTED]> writes:
>
> it still seems really gross to impose the two
> sets of calls, esp. in 2006 when the transitional API should have been
> transitioned already ...
"Tell him he's dreamin"
-- Dale Kerrigan :-)
Transition is probably do-able in a source based
Rob Browning <[EMAIL PROTECTED]> writes:
>
> The implementation works (it passes all of the tests they provide),
> and I believe could completely replace Guile's existing eval.c
> force/delay, but I wanted to know if anyone knew of a reason it
> shouldn't.
I remember I thought it could go in C in
Rob Browning <[EMAIL PROTECTED]> writes:
> Though not conclusive, these results, when combined with the gdb
> backtrace I posted earlier showing the blockage in scm_gc() while
> trying to lock a a mutex, seem to suggest that the remaining problem
> is thread related.
On a related topic, in order
Kevin Ryde <[EMAIL PROTECTED]> writes:
> I remember I thought it could go in C in the core nicely enough, or at
> least just extending `force' in the core and leaving the actual
> `eager' to the srfi module perhaps. I don't remember the details
> though, except it might be nice to lose the mutexe
Rob Browning <[EMAIL PROTECTED]> writes:
> On a related topic, in order for Guile 1.8 to make it into Debian etch
> (the upcoming stable release), we're essentially out of time to fix
> this problem. Because of this I'm contemplating uploading the initial
> Guile 1.8 packages with --with-threads=
