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@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
gazzaguru2@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@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Bill Schwab Sent: 11 November 2007 12:25 AM To: ui@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@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
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 11-Nov-07, at 6:37 AM, Bill Schwab wrote:
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?
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.
Colin
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]
Then the interactive user of the compiler can handle the exception via a menu or a nice dialogue or even an acually *nice* UI, and the non- interactive user can handle it silently. A lint-like user could let the compile proceed whilst logging the infraction, for example. Or preferably by applying a significant voltage to the shiny stainless steel mouse buttons....
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim USER ERROR: replace user and press any key to continue.
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.
The next egregious thing to fix is the way the browsers and the parser use the Text that's submitted for compilation as a ValueHolder for the source code. Ugh.
Colin
+1. There is way too much user interaction code buried down in the model classes.
On Nov 11, 2007 9:10 PM, Colin Putney cputney@wiresong.ca wrote:
On 11-Nov-07, at 6:37 AM, Bill Schwab wrote:
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?
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.
Colin
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
-
Bill Schwab -
Colin Putney -
Jason Johnson -
tim Rowledge