Andy Wingo <wi...@pobox.com> writes: > As for explanations... Catch and throw are implemented using fluids and > prompt and abort. (A discussion of that is here: > http://wingolog.org/archives/2010/02/14/sidelong-glimpses .) An abort > can pass arguments to the prompt's abort handler. It does so by pushing > those values and a number-of-values marker onto the Scheme stack, after > the Scheme and dynamic stacks are unwound to the prompt. The prompt > then needs to pop off those values and pass them to the handler. > > It so happens that this values-then-number-of-values convention is the > same convention as is used for multiple-value returns -- so for compiled > code what happens is that the compiler inlines the handler, and the VM > just does a multiple-value bind on the values from the stack. (See > truncate-values in the VM instruction docs.) > > That's what happens when `prompt' is compiled, as it is in eval.scm. > But before eval.scm is compiled, we use eval.c, which also has to have > support for prompt and abort; but it's necessarily a different > mechanism. This commit fixed a bug in that mechanism: that instead of > looking for the number-of-values marker (the exact integer that it was > expecting) from the VM's stack, as unwound by the abort,
i.e. SCM_VM_DATA (vm), I presume > it was looking > for it at the VM's stack-pointer as seen when the prompt was created > -- i.e. SCM_PROMPT_REGISTERS (prompt) > which necessarily is below any values returned to the prompt's abort > handler. > > We didn't see this issue before because compiling eval.scm did not cause > a `throw'. Interesting, no? But since I changed the implementation of > ensure-writable-dir to one that probably throws, we see this error. > > Any other error that caused a `throw' to a `catch' to occur before > eval.scm was compiled probably caused this error in the past. I don't > know if we had any reports of it; I wouldn't be surprised. In any case, > a tricky bug, and a good one to have fixed. > > We do have prompt and abort tests for the VM implementation. We don't > run them with the boot evaluator, because we can't, not after eval.scm > is compiled -- and anyway, now compilation causes throws at times, so > we'll pick up these issues from users if it comes back. > > Hope that explains things :) It certainly does, thank you! Neil