Race condition in threading code?

Hi there, I have finished my GC cleanup. It mostly seems to work, but I get transient errors in the srfi-18 test. I am suspecting a race condition in the eval module WARNING: (srfi srfi-18): imported module (srfi srfi-34) overrides core binding `raise' ERROR: srfi-18.test: thread-start!: th

load_extension tests broken

Hi there, I just debugged myself silly to find a problem in the new GC as it was running the test suite. As it turns out, the test suite is loading extension modules (i18n.so to be precise) from the path I supplied in LD_LIBRARY_PATH. Since this was an old version, this failed in mysterious ways

Re: Race condition in threading code?

Hmmm... I don't recall seeing those when I was writing that test suite. Just to be clear, were you getting those errors before making your changes? On Sat, Aug 16, 2008 at 2:21 PM, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: > Hi there, > > I have finished my GC cleanup. It mostly seems to work

Re: Race condition in threading code?

Julian Graham escreveu: > Hmmm... I don't recall seeing those when I was writing that test > suite. Just to be clear, were you getting those errors before making > your changes? No, but some very unrelated changes made them go away again. I'm running GUILE through helgrind, but get inundated wi

Re: GUILE_MAX_HEAP_SIZE

Ludovic Courtès escreveu: > Hi, > > Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > >> After switching from the 1.8 branch to master, I get >> >> ./autogen.sh: line 22: gnulib-tool: command not found >> >> >> I'm on Fedora 9. Where do I get gnulib-tool ? > > With "git-clone git://git.sv

Re: GUILE_MAX_HEAP_SIZE

Han-Wen Nienhuys escreveu: > Ludovic Courtès escreveu: >> Hi, >> >> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: >> >>> After switching from the 1.8 branch to master, I get >>> >>> ./autogen.sh: line 22: gnulib-tool: command not found >>> >>> >>> I'm on Fedora 9. Where do I get gnulib-tool ?

Re: pass at srfi-89 implementation

(Sorry for the late reply -- I was out of the country last week...) >> Okay, I've tried -- at length. And so far I haven't been able to top >> the performance of the reference implementation. In fact, it actually >> seems to be fairly efficient > > Did you run some sort of "benchmark"? Yes. No