On 9/17/09 2:33 PM, Tobias C. Rittweiler wrote:
Tobias: are you relying on visual inspection of the problem here, or are you getting a backtrace somehow? I didn't understand your comment "(we come here through *DEBUGGER-HOOK*)".
*DEBUGGER-HOOK* is set to SWANK-DEBUGGER-HOOK which calls DEBUG-IN-EMACS which calls SLDB-LOOP.
READ-FROM-STRING calls ERROR which calls INVOKE-DEBUGGER which calls the function in *DEBUGGER-HOOK*
Does that make more sense?
Yep: thanks for helping ol' thick-in-the-head here.
Just insert some FORMAT calls to SLDB-LOOP, in particular one before the UWP, and one as the first form of the protected form.
If I patch swank.lisp as attached I see
SLDB-LOOP-1 SLDB-LOOP-2 SLDB-LOOP-3 SLDB-LOOP-6 SLDB-LOOP-7 SLDB-LOOP-8
indicating that the SLDB-LOOP UNWIND-PROTECT is executing part of the protected forms, and then going to the cleanup forms. Or am I misinterpreting something again?
SBCL writes the string to a temporary file, then compiles that file. Since the ABCL code for compiling a file works ok, I would maybe pursue that route.
Yes, that's the way it should be implemented for other reasons: COMPILE does not process source as file compiler, think of EVAL-WHEN.
See my comment at http://trac.common-lisp.net/armedbear/ticket/56 for the proper way of how to implement SWANK-COMPILE-STRING.
Eliminating the use of temporary files in the compiler as you suggest in your note to ticket #56 is needed in the near future anyways so ABCL can operate in the absence of a filesystem, so implementing COMPILE-FROM-STREAM is a good idea anyways.
I'll make it go the route over a temp file, but the UWP issue should be resolved first otherwise I'd remove the way to reproduce this issue.
Can you refactor the UNWIND-PROTECT problem into non-SLIME code somehow?