[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