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@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
tim@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@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: BOZO: Use Multics operating system
_______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
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@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Bill Schwab Sent: 13 November 2007 6:50 PM To: ui@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@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
tim@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@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: BOZO: Use Multics operating system
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
On 13-Nov-07, at 10:50 AM, Bill Schwab wrote:
Tim,
I take exception:
I'll raise your exception...
I don't think you actually want to prevent the error messages (aside from the radical approach that I've always tried to follow - don't make mistakes) as such. Error messages are the weakness leaving the code. Catch it and squeeze it to extract the truthiness for reinsertion.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother" said Pooh, when Piglet stubbed his fag out on the semtex.