[Openmcl-devel] Visual Bugs in the IDE

[Gary Byers]

In most cases, it should also be possible to display a modal dialog if
an error occurs during event processing, and it shouldn't be necessary
to saturate application-level code with condition-handling code in
order to achieve that much.  What we've generally been doing when an
error occurs on the event thread is to print a few pages of backtrace
info and the error message to the process-wide standard output and
then transfer control to a handler in the main event lopp;
transferring control to that handler should give intervening lisp and
ObjC code the opportunity to run UNWIND-PROTECT cleanup forms (which
may be @finally clauses in ObjC.)  Popping up some sort of modal
dialog that reports the condition isn't conceptually a lot different
from spitting out the backtrace and neither's ideal for interactive
debugging, but the general idea of abandoning processing of an event
that generates an error and waiting for the next event seems to work
reasobably well.

One case where this may not work as well - I don't know - is when
the  error occurs during a #/drawRect: method.  Some global (at
least thread-wide) graphics state gets set up before #/drawRect:
is called and I don't know exactly what happens if we just throw
out of the #/drawRect: (or if additional Bad Things would happen
if we popped up a window while we were supposed to be drawing a
view.)  The first part of this has to do with whether there's
an ObjC UNWIND-PROTECT (@try/@finally) that does whatever
graphics state cleanup is necessary.

In MCL, it could be very difficult to recover from an error that
occurred during a callback: you generally didn't know what state the
calling foreign code had set up and didn't know how to clean up
anything that needed to be cleaned up.  Similarly, if foreign code
used setjmp/longjmp to do some sort of control transfer (not too
common, but it could happen), that transfer wouldn't run intervening
lisp UNWIND-PROTECT cleanup forms.  ObjC offers a much more reasonable
exception-handling mechanism, Cocoa uses it extensively, and the ObjC
bridge does a pretty good job of making the ObjC and Lisp
stack-unwinding mechanisms cooperate.



On Wed, 20 May 2009, Andrew Shalit wrote:

> Do you want your end users to see these messages?
>
> Many "real" Macintosh applications send to the system log files.  Most Mac 
> users never see these messages, but if you look at the log files they're 
> there.  I wouldn't think it would be hard for CCL to do the same, rather than 
> sending output to the Alt Console.  But of course, it won't be visible to the 
> user then.
>
>
>
> On May 20, 2009, at 9:59 PM, Alexander Repenning wrote:
>
>> you have my vote too for the black text color. I don't mind the console 
>> looking different but the red font does look a tad disturbing. When running 
>> our event code in LUI we do produce output which always ends up in the 
>> AltConsole. At any rate this should not be hard to "fix". I suggest to 
>> include a config file for the console, e.g.,
>> 
>> textColor = "000000"  /* black
>> 
>> This way everybody can have it their way.
>> 
>> Here is a harder problem that we face: The console is fine for developer 
>> mode but in end-user mode, i.e., when using CCL to create a complete app 
>> without listener and with custom menus we absolutely cannot have the 
>> Altconsole. In MCL this was not exactly trivial to achieve either. We had 
>> to create a pretty complex conditions handler case that would catch all the 
>> conditions, present them in a standard dialog, e.g., simple-condition: 
>> division-by-zero "OK" and continue in some meaningful way, e.g., stop 
>> simulation, adjust controls such as run/stop/step buttons, and restart the 
>> event loop. Using native threads I can already anticipate tricky challenges 
>> but if CCL is to be used to build "real" applications this kind of 
>> functionality is rather crucial.
>> 
>> What to do?
>> 
>> Alex
>> 
>> 
>> 
>> On May 20, 2009, at 7:43 PM, John McAleely wrote:
>> 
>>>>> Is there a reason why the text in it is red, and not black like every
>>>>> other window?
>>>> 
>>>> Because it's not like every other window ?
>>>> 
>>>> AltConsole is a (small) separate application; it's supposed to provide
>>>> a primitive terminal-like interface to GUI applications that don't
>>>> ordinarily have such an interface.  If its window appears, there's
>>>> a good chance that that's because of something anomalous and that
>>>> something probably requires user or developer attention.
>>> 
>>> I understand the special status of this application window, and I
>>> empathise with the attempt to draw attention to it.
>>> 
>>> However, the text is marginally harder to read, and I fail to believe
>>> colouring it red provides any meaningful extra information to a
>>> developer or user. I feel it also manages to look surprisingly like
>>> some sort of bug itself.
>>> 
>>> J
>>> 
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>> 
>> 
>> Prof. Alexander Repenning
>> 
>> University of Colorado
>> Computer Science Department
>> Boulder, CO 80309-430
>> 
>> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
>> 
>> 
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>