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 mode, currently turned on, in which we > try ensure that the top of the stack is non-NULL and that all > elements past the top are set to NULL. There are a number of checks > in various places that this is the case. The idea is to avoid lost > references when GC runs, and the heap structure's idea of the VM > registers is out of sync with what the VM regs actually are; or > there is some sloppy programming somewhere. When turned off, this > code incurs no overhead. > > This mode helped to catch a number of stack GC bugs. Are you referring to leaks due to a stack that contains references to Scheme objects that have not been overwritten for a while? Or are there other bugs? > * All of Guile's test suites pass now, with (ice-9 ...) compiled, > including boot-9. Woow! > The ugly: > > * 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 interpreter more often than any other test. Don't know why. > * I had to disable compilation of popen.scm in order to get the tests > to pass, as it was causing really strange, nondeterministic things > to happen. I don't know why. > > 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 > run which itself might cause VM problems. Ouch, that's a tricky area, and I think Rob had some ideas about it (I remember discussions on IRC about that quagmire). > My goal is: correct execution of all existing code that: > * does not do runtime side-effects in macros > * does not call (the-environment) > * does not unquote in values into macros How about code that does "(read-set! keywords 'prefix)" and the likes? :-) > Well that's a long enough update! Questions, comments, and help are most > welcome. You rock! > Bytecode: > > 0 (late-variable-ref 0) ;; `open-output-file' > 2 (local-ref 0) ;; `file' (arg) > 4 (call 1) at > r4rs.scm:145:16 And that's very nice too! Thanks, Ludo'.
