Hey Neil,
On Tue 28 Oct 2008 00:51, Neil Jerram neiljer...@googlemail.com 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
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 acts as
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 hack to
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 else, of
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 overflow with the
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
child
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
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 to
