Bruce Korb <[EMAIL PROTECTED]> writes:
> Neil Jerram wrote:
>> I'm seeing a failure of the test-system-cmds test, and have narrowed
>> it down to this:
>> [EMAIL PROTECTED]:~/guile-cvs-head/guile/guile-core$ ./pre-inst-guile -q
>> guile> (exit 42)
>> Segmentation fault
>
> Marius was saying someth
Hey,
When compiling latest CVS on x86-64 SMP, I still cannot build. It hangs
when snarfing docs, like so (prepare yourself):
creating guile
cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc chars.doc
continuations.doc debug.doc deprecation.doc deprecated.doc
discouraged.doc dynl.doc
Rob Browning <[EMAIL PROTECTED]> writes:
> I suppose that leaves just the vicinity related definitions in
> question.
As far as I can tell, the vicinity related definitions aren't exported
or documented, so I think we can just drop those too.
For those still following this discussion, I'm planni
Rob Browning <[EMAIL PROTECTED]> writes:
>
> This would only work if you forbid side-effects, right?
Well, leave it up to the application to keep itself out of trouble if
the code is not reentrant. That'd be consistent a general policy of
not stopping stupid multi-thread code, only code that migh
Kevin Ryde <[EMAIL PROTECTED]> writes:
>> I was also wondering about the possibilities for deadlock with the
>> current code, and then what they might be with a srfi-45 force,
>
> Whenever arbitrary code executes in a mutex I guess there's scope for
> that. srfi-45 shouldn't be inherently worse.
