[UI] Compiler messages

[Bill Schwab]

Gary,

Agreed, with the caveat that I am currently thinking contexts are
preferred to exceptions in this case (for speed).  Of course, that would
require changing a LOT of code, where the exception solution can be
stealthy.  Changing default actions is a worthy compromise.  I will take
a shot at it.

This reminds me of EndOfStream.  I would very much like to see #next:,
#next, etc. raise exceptions on stream exhaustion, with #nextOrNil and
#nextAvailable: truncating w/o errors.  When a stream unexpected hits
bottom, I like to know about then vs. waiting for incomplete data to
confuse higher layers.  Unfortunately, the default actions appear not to
be relevant in that case.

Bill




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bschwab at anest.ufl.edu
Tel: (352) 846-1285
FAX: (352) 392-7029


>>> gazzaguru2 at btinternet.com 11/13/2007 2:07 PM >>>
So Bill, if you want to suppress the messages, change the default
action for
the exceptions now, or make them preference based, debugger based,
whatever.
At least there is a nicer way to handle things now. I'm not sure under
what
circumstances you'd want the popups now... I guess a preference would
be
best (interactive or logged (to Transcript)). But that can now be done
in
the default handler, rather then the (model) Parser code.

Just my thoughts...

> -----Original Message-----
> From: ui-bounces at lists.squeakfoundation.org 
> [mailto:ui-bounces at lists.squeakfoundation.org]On Behalf Of Bill
Schwab
> Sent: 13 November 2007 6:50 PM
> To: ui at lists.squeakfoundation.org 
> Subject: Re: [UI] Compiler messages
>
>
> Tim,
>
> I take exception: Colin's code does not stop the messages: it
enables
> the IDE to do so.  Your idea of a compiler subclass is well-taken.
>
> Bill
>
>
>
>
>
> Wilhelm K. Schwab, Ph.D.
> University of Florida
> Department of Anesthesiology
> PO Box 100254
> Gainesville, FL 32610-0254
>
> Email: bschwab at anest.ufl.edu 
> Tel: (352) 846-1285
> FAX: (352) 392-7029
>
>
> >>> tim at rowledge.org 11/13/2007 1:03 PM >>>
>
> On 13-Nov-07, at 9:18 AM, Bill Schwab wrote:
>
> > Colin,
> >
> > First, not meaning to be dense, I load the code and the compiler
> > continues to nag me over both selectors and variables.  Do I need
to
>
> > set
> > the mode, or does you fix work only with specific browsers?
>
> Take a look at the code Bill; Colin made changes to abstract the
> notifications by raising specific signals instead of explicitly
using
>
> menus. If you want to handle the exceptions you can. The
defaultAction
>
> is to open a menu as before, a very logical and reasonable choice.
>
> > I would probably opt to simply patch it enough to stop the
nonsense,
>
> > at
> > least to start.
>
> That's exactly what Colin's code does. It stops the nonsense and
> provides a way for clients to do what they need as well as leaving
the
>
> system fully functional when there is no specific handling of
errors.
>
> The next part of the job would be to find all the relevant places
> where the Parser is used (ie start with all senders of the public
> access protocols in the Parser class) and to decide whether to
handle
>
> the exceptions or not. Without digging into it too far I'd suggest
> that a subclass of Compiler (called perhaps InteractiveCompiler) be
> built that handled all the exceptions with menus  or preferably
better
>
> dialogues. Then the various browsers would be altered to use
> InteractiveCompiler instead of the plain old Compiler. This could
even
>
> allow nicer behaviour such as showing where a shadowed varname is
> 'originally' used, stuff integrated into the actual browser.
> Eventually you could change the defaultAction for the exceptions to
> just open a debugger since they'd now be more of a system error. For
> any batch loading system - like a changeset loader or whatever - you
> would add another subclass of Compiler (say ChangeSetLoaderCompiler)
> that handles the exceptions appropriately. If you look at
> PositionableStream>fileInAnnouncing: you'll see how some of that is
> curently handled, more as a bad example than anything. Also look at
> all references to InMidstOfFileinNotification. Err, yuck.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim 
> Strange OpCodes: BOZO: Use Multics operating system
>
>
> _______________________________________________
> UI mailing list
> UI at lists.squeakfoundation.org 
> http://lists.squeakfoundation.org/mailman/listinfo/ui 
> _______________________________________________
> UI mailing list
> UI at lists.squeakfoundation.org 
> http://lists.squeakfoundation.org/mailman/listinfo/ui 

_______________________________________________
UI mailing list
UI at lists.squeakfoundation.org 
http://lists.squeakfoundation.org/mailman/listinfo/ui