'Sup,
I was going to divide this update into the good, the bad, and the ugly,
but the bad is the ugly, and the good contains within it the bad as
well.
The good:
* I've hacked the disassembler to weave together the bits of
information that it has into a more coherent text.
So for exam
Hey Neil,
On Tue 28 Oct 2008 00:51, "Neil Jerram" writes:
> - the principle of the elisp integration is that there is a new value
> #nil, which acts as EOL in list contexts, and as #f in boolean
> contexts
>
> - as one example of this, the non-VM apply accepts and handles a list
> whose tail is
Hi Andy,
>My current speculation is that when you compile --with-threads, as I
>do, that the socketpair between the signal receiving thread and the
>main thread is not closed after the fork, therefore signals in the
>child might reach the parent or vice versa, causing random code t
Hi,
On Thu 16 Oct 2008 07:35, "Julian Graham" <[EMAIL PROTECTED]> writes:
>>My current speculation is that when you compile --with-threads, as I
>>do, that the socketpair between the signal receiving thread and the
>>main thread is not closed after the fork, therefore signals in the
>
Andy Wingo <[EMAIL PROTECTED]> wrote:
>It seems fork + signal handling is borked with a guile compiled --with-threads
>-- and that's not
>specific to the vm branch.
And this is the very reason that Debian guile was built --without-threads.
It's just not a good idea to mix fork() with pthre
Hi Andy,
Andy Wingo <[EMAIL PROTECTED]> writes:
> * The VM stack is now marked precisely.
Did you mean stack frame objects that link `program' object invocations?
I guess this stack is referenced by the C stack, so why does something
special need to be done?
> * There is a now a debugging m
Howdy,
On Thu 16 Oct 2008 21:25, [EMAIL PROTECTED] (Ludovic Courtès) writes:
> Andy Wingo <[EMAIL PROTECTED]> writes:
>
>> * The VM stack is now marked precisely.
>
> Did you mean stack frame objects that link `program' object invocations?
> I guess this stack is referenced by the C stack, so w
2008/10/16 Andy Wingo <[EMAIL PROTECTED]>:
>>> * Actually the bit about all of the test suites passing was a lie in
>>> another respect: the elisp test fails, with a C stack overflow,
>>> indicating too much recursion into the interpreter.
>>
>> I've seen `elisp.test' trigger a stack over
>>> I've seen `elisp.test' trigger a stack overflow with the interpreter
>>> more often than any other test. Don't know why.
>>
>> I hacked around this -- see what I've pushed to vm for more info.
>
> I plan to take a look at this after the srfi-18.test hang. (Not that
> that should stop anyone e
Hi Neil,
On Tue 28 Oct 2008 00:51, "Neil Jerram" <[EMAIL PROTECTED]> writes:
> It's not rocket science, and you probably guessed at that solution
> already - but I think it really is the _right_ fix, because
>
> - the principle of the elisp integration is that there is a new value
> #nil, which a
Hi,
Andy Wingo <[EMAIL PROTECTED]> writes:
> I do not think the interpreter / subr division is appropriate for a
> multilingual system. To me, the division should be:
>
> * The evaluator / interpreter, that deals in Scheme;
> * A layered compiler, with different top-level layers for e.g. Guile,
On Fri 31 Oct 2008 18:54, Andy Wingo <[EMAIL PROTECTED]> writes:
> Granted, we have ideals, and we have tradeoffs, and writing an elisp
> compiler. (Then again, maybe not that bad.) If I have to add what I
Meant to say here: "writing an elisp compiler might be a bit of work"
> consider to be a h
On 31/10/2008, Andy Wingo <[EMAIL PROTECTED]> wrote:
> I do not think the interpreter / subr division is appropriate for a
> multilingual system. To me, the division should be:
>
> * The evaluator / interpreter, that deals in Scheme;
> * A layered compiler, with different top-level layers fo
13 matches
Mail list logo