[UI] Compiler messages

[Gary Chambers]

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