UI November 2007

ui@lists.squeakfoundation.org

15 participants
42 discussions

Re: [UI] Compiler messages
by Bill Schwab 14 Nov '07

14 Nov '07

Tim, That's not the "dimension" I had in mind: I was referring to the use of default actions. Unfortunately, giving teeth to EndOfStream appears not to be as simple as changing the default action. In the affected application (parsing medical data streams), I already have to protect against exceptions from other sources, so the speed hit for creating the handler is already in place. I would much rather have the exception arise "honestly" from reading off the end of a mal-formed (or mis-identfied) stream than to wait for some screwy knock-on effect of silent truncation. The real fear is that the truncated data _might_ appear valid. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> tim(a)rowledge.org 11/13/07 6:03 PM >>> > [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(a)rowledge.org; http://www.rowledge.org/tim Useful random insult:- A room temperature IQ.

1 0

RE: [UI] Compiler messages
by Bill Schwab 14 Nov '07

14 Nov '07

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(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> gazzaguru2(a)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(a)lists.squeakfoundation.org > [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Bill Schwab > Sent: 13 November 2007 6:50 PM > To: ui(a)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(a)anest.ufl.edu > Tel: (352) 846-1285 > FAX: (352) 392-7029 > > > >>> tim(a)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(a)rowledge.org; http://www.rowledge.org/tim > Strange OpCodes: BOZO: Use Multics operating system > > > _______________________________________________ > UI mailing list > UI(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/ui > _______________________________________________ > UI mailing list > UI(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/ui _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

3 2

Re: [UI] Compiler messages
by Bill Schwab 13 Nov '07

13 Nov '07

Tim, You are correct that it would be better to log the information vs. supressing it entirely. You compiler subclass idea should allow that, and w/o the burden of doing something that has to be adopted by the wider community in order to have remotely lasting value. I still think that exceptions are an inefficient solution to this particular problem. It strikes me as being similar to using #on:do: to protect #at: when #at:ifAbsent: can suffice. Exceptions of course have the power to "tunnel across the stack," but in this case, I suspect an optional context argument or extension of one that already exists is the preferred approach. #on:do: has overhead even if the exception is not raised, and even more if it is raised. It seems a heavy price to pay when loading large amounts of code. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> tim(a)rowledge.org 11/13/2007 2:17 PM >>> 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(a)rowledge.org; http://www.rowledge.org/tim "Bother" said Pooh, when Piglet stubbed his fag out on the semtex. _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

1 0

Re: [UI] Compiler messages
by Bill Schwab 13 Nov '07

13 Nov '07

Colin, Is the change set simply an example, or does it address something I missed? The exceptions would have to be resumable, right? I am starting to wonder whether exceptions or events are a good fit, as they both have overhead (especially exceptions??) that might be a problem when loading large change sets. It might be interesting to see what Dolphin 6 does for its code mentor. I bought it, but never converted from 5.1, so it is not readily available, but I can get to it. There is still the question of whether we want to simply gag the messages or write something that is a true fix to the mainstream release. Any ideas? Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> cputney(a)wiresong.ca 11/12/07 1:53 AM >>> On 11-Nov-07, at 12:44 PM, tim Rowledge wrote: > > On 11-Nov-07, at 12:10 PM, Colin Putney wrote: >>> >> >> I don't have any advice about that, but I would like to suggest >> this: please, please don't continue the tradition of having the >> parser interact with the user directly by opening menus and what >> not. This is a horrifying design that has given me much grief with >> OmniBrowser. > > I'd say this is one of those places where exceptions have a clear > and valuable role. > > When there is an unknown variable, instead of using something like > varname isUnknown ifTrue:[(PopUpMenu query:'is this a temp or cancel > compile') ifTrue:[self addTempNamed: varname] ifFalse:[^self > buggered]] > > try something a bit more like > varname isUnknown ifTrue:[CompilerUnknownVariableName informWith: > varname forCompiler: self] Yeah, that's what I ended up doing.

4 3

Re: [UI] Compiler messages
by Bill Schwab 13 Nov '07

13 Nov '07

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(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> tim(a)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(a)rowledge.org; http://www.rowledge.org/tim Strange OpCodes: BOZO: Use Multics operating system _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

3 2

Re: [UI] Compiler messages
by Bill Schwab 13 Nov '07

13 Nov '07

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? Second, of course I would not have the compiler directly use the GUI - I agree that is a terrible design (if one can call it a design). However, I would probably opt to simply patch it enough to stop the nonsense, at least to start. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> cputney(a)wiresong.ca 11/13/07 11:58 AM >>> On 13-Nov-07, at 6:46 AM, Bill Schwab wrote: > Is the change set simply an example, or does it address something I > missed? It addresses the Parsers habit of interacting directly with the user when it encounters undeclared variables and the like. > The exceptions would have to be resumable, right? Yes, they are resumable. > I am > starting to wonder whether exceptions or events are a good fit, as > they > both have overhead (especially exceptions??) that might be a problem > when loading large change sets. They only get signaled if the Compiler is invoked in "interactive mode." > There is still the question of whether we want to simply gag the > messages or write something that is a true fix to the mainstream > release. Any ideas? This code wasn't meant to address the problem you've raised. I was just requesting that if you're going to change the way the Compiler deals with unresolved references, that you don't continue the tradition of interacting directly with the user. Tim suggested using exceptions instead, and since the code I had written did use exceptions, I posted it. I imagine that the problem you want to solve will require more significant changes to the parser and compiler, and I hope you'll refrain from coupling the compiler to the UI. Colin _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

3 2

RE: [UI] Updating universe
by Bill Schwab 13 Nov '07

13 Nov '07

Gary, Not to rub salt in any wounds, what is the nature of the problem? Is it something you could fix with lazy initialization, or does it involve serialization or something else that gets confused? I ask because I layout changes of serialized objects hits close to home. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> gazzaguru2(a)btinternet.com 11/13/07 9:39 AM >>> You'll need to close anything that has a checkbox/radio button in due to the changes (the button has an instvar to determine which type now, rather than checking the "on image" form). > -----Original Message----- > From: ui-bounces(a)lists.squeakfoundation.org > [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Damien Cassou > Sent: 13 November 2007 2:04 PM > To: Squeak's User Interface > Subject: Re: [UI] Updating universe > > > 2007/11/13, Gary Chambers <gazzaguru2(a)btinternet.com>: > > Though now I have put a few more versions on SqueakSource. > version 261+ includes support for automatically loading a > background image for a theme if an image (.jpg) matching the > theme name is present in your squeak directory (Watery.jpg for example). > > > > I can do another Universe release if you like... > > > It's your package, you have to decide :-). > > Thank you for maintaining this. > > > -- > Damien Cassou > _______________________________________________ > UI mailing list > UI(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/ui > _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

2 2

Updating universe
by Damien Cassou 13 Nov '07

13 Nov '07

Hi, I would like to create a new squeak-dev image. Could you please, Gary, update the universe with what you think is the best version of the UI enhancements? Bye -- Damien Cassou

3 6

RE: [UI] Compiler messages
by Bill Schwab 12 Nov '07

12 Nov '07

Gary, I will gladly give it a shot. What is the best way to distribute it? Ideally, it should be part of the mainstream release so that the changes will be maintained, but it might be easier to make it part of our group's output. What do you think? Which version of Squeak would you recommend as a starting point? Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> gazzaguru2(a)btinternet.com 11/11/07 9:20 AM >>> You'll probably need to modify the "error correction" methods in the Parser class... perhaps some preferences would be in order (like "don't ask, show in Transcript instead" etc.). > -----Original Message----- > From: ui-bounces(a)lists.squeakfoundation.org > [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Bill Schwab > Sent: 11 November 2007 12:25 AM > To: ui(a)lists.squeakfoundation.org > Subject: [UI] Compiler messages > > > Hello all, > > I am trying to get something done, so I thought it might be a good time > to insist on Squeak on Linux. Is there any way to gag the compiler > messages that mess with me (in SERIES!!!!) about the unused variable > names (I will need them as soon as I enter the debugger to start the > real work) and confirming the method name that is not (YET) defined? > > The checks would be great, if not modal. > > Bill > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 846-1285 > FAX: (352) 392-7029 > > _______________________________________________ > UI mailing list > UI(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/ui _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

4 4

Re: [UI] Compiler messages
by Bill Schwab 12 Nov '07

12 Nov '07

No, but writing something with no plan for getting it used might be a good way to start one. Too many people have written too much fine code, only to see it lost because people cannot agree on a direction for Squeak. I am happy to make some small changes and share them here, or do a more elaborate job for wider consumption. Writing something highly involved only to watch it fall into the NIMBY black hole? No, thanks. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> tim(a)rowledge.org 11/11/07 6:57 PM >>> On 11-Nov-07, at 3:01 PM, Bill Schwab wrote: > Tim, > > Ok, then what do we do? Distribute it as a group development, or try > for inclusion in the mainstream? Well the first thing is to Just DoIt. If it existed and was well written and passed sensible tests then I don't think it would be too difficult to persuade whoever is/was the release team to incorporate it. Worrying about how to handle something that doesn't exits yet is a sure recipe for ulcers. tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Strange OpCodes: PSM: Print and SMear _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

UI November 2007