[cells-devel] New Cells User Feedback (includes patch!)
Kenny Tilton
ktilton at nyc.rr.com
Fri Apr 29 03:08:15 UTC 2005
James Bielman wrote:
>Hi,
>
>Here's a patch containing the changes I made to get Cells to compile
>on a current OpenMCL (just Cells, none of the GUI stuff). Also, the
>files in the UTILS-KT defsystem had no dependencies, so I added
>:serial t to compile them in the order they appear.
>
>I added a paragraph to the documentation about calling CELL-RESET
>after errors occur and accessors just print ".". This drove me crazy
>for awhile---I was restarting my Lisp image once I got in this state
>because I couldn't figure out what to do!
>
>What about doing something like this in MD-SLOT-VALUE (untested, and
>assuming I haven't completely misunderstood what's going on):
>
>(defun md-slot-value (...)
> (tagbody
> retry
> (when *stop*
> (restart-case
> (error "Cells is stopped due to a prior error.")
>
When I went to do something like that it came back to me in a flash: two
different Lisp implementations killed me for hours until I figured out
what was going on, in exactly the same way. It is OK to put up one
backtrace, but the Lisp environments both then allow OS events through
to my application windows, events such as "deactivate window". My
application code then might fail again and put up another backtrace, and
the only way out was to kill the Lisp environments.
So once I see the *stop* sign, I literally try to do zero processing and
simply return.
Now the situation here is unusual because I do more GUI development than
the average bear, so maybe something could be worked out. I could have a
second special which tells the Cells engine that I have an application
window up, and set that in some with-application-window macro right at
my top-level testing function. then, if that flag is clear, I could have
a patch such as yours to alert developers of the *stop* thing.
Thoughts?
kt
More information about the cells-devel
mailing list