Compiler messages

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Compiler messages

Schwab,Wilhelm K
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
Reply | Threaded
Open this post in threaded view
|

RE: Compiler messages

Gary Chambers-4
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: [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

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

RE: Compiler messages

Schwab,Wilhelm K
In reply to this post by Schwab,Wilhelm K
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: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

>>> [hidden email] 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: [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

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: Compiler messages

Colin Putney

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
Reply | Threaded
Open this post in threaded view
|

Re: Compiler messages

timrowledge

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; [hidden email]; http://www.rowledge.org/tim
USER ERROR: replace user and press any key to continue.


_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: Compiler messages

Jason Johnson-5
In reply to this post by Colin Putney
+1.  There is way too much user interaction code buried down in the
model classes.

On Nov 11, 2007 9:10 PM, Colin Putney <[hidden email]> 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
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: Compiler messages

Schwab,Wilhelm K
In reply to this post by Schwab,Wilhelm K
Tim,

Ok, then what do we do?  Distribute it as a group development, or try
for inclusion in the mainstream?

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/11/07 3:44 PM >>>

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; [hidden email]; http://www.rowledge.org/tim
USER ERROR: replace user and press any key to continue.


_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: Compiler messages

Schwab,Wilhelm K
In reply to this post by Schwab,Wilhelm K
+1???  I'd go further than that ;)



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/11/07 4:44 PM >>>
+1.  There is way too much user interaction code buried down in the
model classes.

On Nov 11, 2007 9:10 PM, Colin Putney <[hidden email]> 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
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: Compiler messages

timrowledge
In reply to this post by Schwab,Wilhelm K

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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: PSM: Print and SMear


_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: Compiler messages

Schwab,Wilhelm K
In reply to this post by Schwab,Wilhelm K
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: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

>>> [hidden email] 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: PSM: Print and SMear


_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: Compiler messages

Colin Putney
In reply to this post by timrowledge

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

Parser.3.cs (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Compiler messages

Schwab,Wilhelm K
In reply to this post by Schwab,Wilhelm K
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: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

>>> [hidden email] 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.


_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: Compiler messages

Colin Putney

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
Reply | Threaded
Open this post in threaded view
|

RE: Compiler messages

Gary Chambers-5
+1 (and more) for no UI bits in the Parser. Exceptions seem the way to go,
after all, no code problems, no exceptions... Means you'll have to catch
them in the interactive parts (more changes...).

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



Pinesoft Computers are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA



This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: Compiler messages

Schwab,Wilhelm K
In reply to this post by Schwab,Wilhelm K
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: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

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

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: Compiler messages

timrowledge

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
Reply | Threaded
Open this post in threaded view
|

RE: Compiler messages

Gary Chambers-5
For the moment, if you explicitly catch the exceptions you can make them
quiet (not tested here, I guess that's the jist though).

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



Pinesoft Computers are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA



This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: Compiler messages

Schwab,Wilhelm K
In reply to this post by Schwab,Wilhelm K
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
Reply | Threaded
Open this post in threaded view
|

RE: Compiler messages

Gary Chambers-4
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: [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

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: Compiler messages

timrowledge
In reply to this post by Schwab,Wilhelm K

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; [hidden email]; http://www.rowledge.org/tim
"Bother" said Pooh, when Piglet stubbed his fag out on the semtex.


_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
123