Andy Wingo escreveu:
> Hi again!
>
> On Wed 27 Aug 2008 12:00, Andy Wingo <[EMAIL PROTECTED]> writes:
>
>> On Wed 27 Aug 2008 07:00, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>>
>> http://thread.gmane.org/gmane.lisp.guile.user/6372
>>> I think reference counting is the correct solution
Ludovic Courtès escreveu:
> Sorry if I missed something but my understanding was that you were
> referring to a GC fix, which it isn't. Re-reading the thread, it seems
> I indeed missed the point, and I apologize.
I hope you do realize that every time you miss the point and send out a
reply y
Ludovic Courtès escreveu:
>> +#if (SCM_DEBUG_CELL_ACCESSES == 0 && SCM_SIZEOF_UNSIGNED_LONG == 4)
>
> x86-64 is not the only arch with 4-byte long long integers.
I'm not pretending it is the end-all fix. - we (I) need to understand
what is happening and make the numbers match up exactly. This i
Andy Wingo escreveu:
>> I think reference counting is the correct solution for this, as far as
>> I understand the problem from the quoted message.
>
> I don't think so; the use case is that (1) we don't want to prevent the
> C object from being freed, so we don't want to hold a reference on the C
Hi!
"Julian Graham" <[EMAIL PROTECTED]> writes:
> Yeah, no reason it couldn't do that -- unless you'd want it to
> automatically swap in some kind of cooperative, call/cc-based
> threading implementation in that situation. (I take it, though, that
> --without-threads means no threads of any kind
Hi Ludovic,
> Julian: shouldn't `srfi-18.scm' check for "(provided? 'threads)" and
> raise an error when it's false?
Yeah, no reason it couldn't do that -- unless you'd want it to
automatically swap in some kind of cooperative, call/cc-based
threading implementation in that situation. (I take i
Hi,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> i686-linux-gcc -DHAVE_CONFIG_H
> -I/home/lilydev/vc/gub/target/linux-x86/src/guil
> e-1.9.git -I.. -I/home/lilydev/vc/gub/target/linux-x86/src/guile-1.9.git/lib
> -I.
> ./lib -g -O2 -Wall -Wmissing-prototypes -MT libguile_la-scmsigs.lo -MD -MP
Hi again!
On Wed 27 Aug 2008 12:00, Andy Wingo <[EMAIL PROTECTED]> writes:
> On Wed 27 Aug 2008 07:00, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> http://thread.gmane.org/gmane.lisp.guile.user/6372
>>
>> I think reference counting is the correct solution for this, as far as
>> I unde
Hi,
On Wed 27 Aug 2008 07:00, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
http://thread.gmane.org/gmane.lisp.guile.user/6372
>
> I think reference counting is the correct solution for this, as far as
> I understand the problem from the quoted message.
I don't think so; the use case is
Hello Han-Wen,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Over the last weeks I have seen little discussion on your patches, eg.
Please, refrain from resorting to personal attacks.
> commit 582a4997abc8b34ac6caf374fda8ea3ac65bd571
> Author: Ludovic Courtès <[EMAIL PROTECTED]>
> Date:
Ludovic Courtès escreveu:
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> I am pushing a fix for this to master.
>
> Will you care to post and discuss your patches before pushing them?
Over the last weeks I have seen little discussion on your patches, eg.
commit 582a4997abc8b34ac6caf374fd
> I've seen `srfi-18.test' hang from time to time, but not often enough to
> give me an incentive to nail it down. :-( I don't think it relates to
> Han-Wen's GC changes.
Crap, I'm seeing some lockups now, too. Sorry, guys. I'm debugging,
but don't let that stop you from investigating as well
Hi,
Andy Wingo <[EMAIL PROTECTED]> writes:
> On Sat 16 Aug 2008 11:45, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> 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
Hi,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> I am pushing a fix for this to master.
Will you care to post and discuss your patches before pushing them?
This is all the more important that the patches don't seem to have any
relation with the problem at hand:
f85ea2a85fcdd051f432964806f044
14 matches
Mail list logo
