Compiler messages

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Bill Schwab
> Sent: 11 November 2007 12:25 AM
> To: [hidden email]
> 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: [hidden email]
> Tel: (352) 846-1285
> FAX: (352) 392-7029
>
> _______________________________________________
> UI mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/ui

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Bill Schwab
> Sent: 11 November 2007 12:25 AM
> To: [hidden email]
> Subject: [UI] Compiler messages
>
>
> Hello all,
>
> I am trying to get something done, so I thought it might be a good

> 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: [hidden email]
> Tel: (352) 846-1285
> FAX: (352) 392-7029
>
> _______________________________________________
> UI mailing list
> [hidden email]
> 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
>
> _______________________________________________
> UI mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>

> > 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
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>

>
> 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]

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Colin Putney
> Sent: 13 November 2007 4:59 PM
> To: Squeak's User Interface
> Subject: Re: [UI] Compiler messages
>
>
>
> 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
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of tim Rowledge
> Sent: 13 November 2007 6:04 PM
> To: Squeak's User Interface
> Subject: Re: [UI] Compiler messages
>
>
>
> 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; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: BOZO: Use Multics operating system
>
>
> _______________________________________________
> UI mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>

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