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@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
gazzaguru2@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@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
_______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
On 13-Nov-07, at 2:47 PM, Bill Schwab wrote:
Gary,
Agreed, with the caveat that I am currently thinking contexts are preferred to exceptions in this case (for speed).
[snip]
This reminds me of EndOfStream.
Whoah, neddy!
This really isn't much like that at all. An EndOfStream exception might possibly cause a noticeable slowdown in a tight stream based loop, assuming that the rest of the work being done in said loop is trivial. Having exceptions involved in compiling is hardly the same; compiling is a pretty big job!
Having a 'signal exception' in your code costs nothing much, especially of course if it is not actually executed - the normal case. Actually raising the exception costs a scan of the execution stack - done in primitive code that is rather well written - with a check in Squeak code at each place where an exception handler context is found. If you had a really deep stack with an exception handler not relevant to your code at every other level (why it can't be at every level is left as an exercise for the student) then raising an exception would of course take some time.
Compile speed is rarely much of an issue and hasn't been for decades in ST code. Unless of course you're loading megabytes of the stuff at a gulp, in which case I'd politely suggest your overall process sucks.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- A room temperature IQ.
On 13-Nov-07, at 2:47 PM, Bill Schwab wrote:
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.
Tim is right, speed is just not an issue here. Exceptions only get raised if the compiler is in "interactive" mode, as when invoked from a browser. In that case, compilation takes milliseconds, and adding a few microseconds doesn't matter. Further, if the exception handler interacts with the user, the time to raise an exception is dwarfed by the time spend waiting for the user to react.
Colin