From: Jonathan S. S. <sh...@er...> - 2008-01-21 23:03:28
|
On Mon, 2008-01-21 at 15:47 -0700, Ray Lehtiniemi wrote: > > That will almost certainly be required. While you are there, check that > > OP_T0LVL isn't resetting the eval stack under the (mistaken) assumption > > that LOAD is being run from top level. At one point there was an error > > of this form in the logic of the machine. It may have subsequently been > > fixed, or I may be mis-recollecting where it was. > > i believe this may in fact be happening. the OP_T0LVL handler will > dump_stack_reset(), which appeared (to my uneducated eyes) to be a big part > of the problem. Yes. That is precisely the issue that I remembered. > i had tried splitting up the OP_T0LVL into OP_T0ALVL and OP_T0BLVL, but i > don;t really know what i'm doing.... i think i managed to get it to read the > first form out of the file by saving an OP_READ_INTERNAL on the stack, but > then it returned back to the top level and i couldn;t figure out how to make > it keep going :-( Yes. The problem will get even messier if you contrive to have C call back into Scheme, because you will really want to kick off OP_T0LVL there as well. I had this one fixed at one point, but then I decided that I really wanted bignum support. This led me into the GC system and the error stream problem, and then somewhere along the way I realized that PRINT would probably fail if GC was triggered from inside it (which became possible when I introduced string streams). This in turn is part of why I started down the preamble rat-hole, because a correct implementation of PRINT is necessarily recursive, and getting it all to work under GC looked VERY difficult. Pretty soon I was doing a ground-up rewrite, because once I started to tackle the GC issue I found some more issues. I will send a note in a moment outlining how to improve on the current situation in a simple way that I did not understand at that time. shap |