- Pharo-dev - lists.pharo.org

Re: [Pharo-project] a way to ignore warnings?

by StÃ©phane Ducasse

>> Yes, I've seen the UndeclaredVariableWarning (from > Encoder>>undeclared: ) dialog many times when compiling > programatically, and one of things is that I have to handle every > compilation to avoid this dialog like this: > > [ self targetClass > compile: aString > classified: aCategoryClassification ] > on: UndeclaredVariableWarning > do: [: ex | self log: 'Warning UndeclaredVariableWarning in ' , self > targetClass asString , '>>' , aString asString ] > > I didn't found a preference to ignore this dialog, although I've found > > Parser warningAllowed -> false "That would be the More Warnings preference " > > I wonder is there a setting I've missed? it would be nice to have one. Hernan could you open a ticket? and if you provide code it will get in :) > >> To ignore #inform: in Pharo, handling ProvideAnswerNotification is a better >> choice than Notification, but you need to be aware of the implications of >> ignoring inform: as ProvideAnswerNotification is used for dealing with: >> >> inform: - return value is ignored >> confirm:: - return values is expected to be a Boolean >> request: - is expected to be a String >> >> As Adrian mentions, if you are want to automate the handling of >> inform:/confirm:/request: you are better off using valueSupplyingAnswers:. >> >> Finally, in the above example using 'ex return:'a string` is not the correct >> way to ignore a Warning or Notification. The #return: messages returns the >> arg as the result of the block (unwinding the stack). #resume: returns the >> arg as the result of the #signal: and continues execution from that point. >> Take a look at the different results for the following two expressions: >> >> | w x y z | >> w := x:= y:= z:= nil. >> x:= [ w := #before. >> y:= self confirm: 'test'. >> z := #after ] >> on: ProvideAnswerNotification >> do: [:ex | ex return: false ]. >> {w. x. y. z.}. >> >> | w x y z | >> w := x:= y:= z:= nil. >> x:= [ w := #before. >> y:= self confirm: 'test'. >> z := #after ] >> on: ProvideAnswerNotification >> do: [:ex | ex resume: false ]. >> {w. x. y. z.}. >> > > I don't know if assuming always that "correct" means continue > execution in that scope. It may depend on the warning or notification > and the block task, but of course #resume: is a more common sense > choice for most cases. > >> HernÃ¡n this is common mistake when putting together simple examples and if I >> hadn't just finished writing a series of automatic Warning handlers, I >> wouldn't have picked up on it:) >> > > I know :) it could be as complex as hell, that's why I say you have to > automate exceptions with a specific goal in mind, for example logging > or finish an unattended loading. > Cheers, > > -- > HernÃ¡n Morales > Information Technology Manager, > Institute of Veterinary Genetics. > National Scientific and Technical Research Council (CONICET). > La Plata (1900), Buenos Aires, Argentina. > Telephone: +54 (0221) 421-1799. > Internal: 422 > Fax: 425-7980 or 421-1799. >

Dec. 21, 2010

[Pharo-project] [update 1.2] #12284

by Marcus Denker

12284 ----- Issue 3472: Text selection problem in Pharo-dev 1.2 Issue 3463: [Failing Test] HelpBrowserTest.testOpen -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Dec. 21, 2010

Re: [Pharo-project] [Pharo-users] Nested classes

by Mariano Martinez Peck

On Tue, Dec 21, 2010 at 6:32 AM, Charles Monteiro <charles(a)nycsmalltalk.org>wrote: > > Hi, perhaps a bit off topic, but I was wondering from those that brought > Traits to ST, just by ignorance.....weren't traits invented in smalltalk? > what are their thoughts of the use of nested classes such as > used in Ruby and other languages. > > what are "nested classes" in ruby? > Good idea? If so should Smalltalk integrate these? Why? Why not ? > > thanks in advance > > -Charles > www.nycsmalltalk.org > -- > -- > View this message in context: > http://forum.world.st/Nested-classes-tp3125667p3125667.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Dec. 21, 2010

Re: [Pharo-project] Issue 3463 in pharo: [Failing Test] HelpBrowserTest.testOpen

by pharo＠googlecode.com

Updates: Status: Closed Comment #8 on issue 3463 by marcus.denker: [Failing Test] HelpBrowserTest.testOpen http://code.google.com/p/pharo/issues/detail?id=3463 12284

Dec. 21, 2010

[Pharo-project] Tron: thought you might be interested (though you probably already know)

by Chip Nowacek

Know the inspiration for Tron? None other than Smalltalk inventor Alan Kay. His wife, Bonnie MacBird <http://en.wikipedia.org/wiki/Bonnie_MacBird>, is a co-creator of Tron and says Alan provided the underpinnings of the story. So, when you go see Tron Refactored, remember it's just Smalltalk on the big screen. I thought it was cool anyway.

Dec. 21, 2010

Re: [Pharo-project] Issue 3472 in pharo: Text selection problem in Pharo-dev 1.2

by pharo＠googlecode.com

Updates: Status: Closed Labels: -Milestone-1.2-DevImage Milestone-1.2 Comment #4 on issue 3472 by marcus.denker: Text selection problem in Pharo-dev 1.2 http://code.google.com/p/pharo/issues/detail?id=3472 12284

Dec. 21, 2010

Re: [Pharo-project] Issue 3472 in pharo: Text selection problem in Pharo-dev 1.2

by pharo＠googlecode.com

Updates: Status: Fixed Comment #3 on issue 3472 by aplantec: Text selection problem in Pharo-dev 1.2 http://code.google.com/p/pharo/issues/detail?id=3472 In InBox SLICE-Issue-3472-Text-selection-problem-in-Pharo-dev-12

Dec. 21, 2010

Re: [Pharo-project] Issue 3472 in pharo: Text selection problem in Pharo-dev 1.2

by pharo＠googlecode.com

Comment #2 on issue 3472 by aplantec: Text selection problem in Pharo-dev 1.2 http://code.google.com/p/pharo/issues/detail?id=3472 It comes from SmalltalkEditor>>evaluateSelection .... rcvr class evaluatorClass new evaluate: self selectionForDoitAsStream in: ctxt to: rcvr notifying: editor ifFail: [FakeClassPool adopt: nil. ^ #failedDoit] logged: true. ... where the editor is passed as the requestor to Compiler>> evaluate:in:to:notifying:ifFail:logged:. It is bad because as a result of 'ProfStef next', the textMorph is set with a new text and as a board effect the morph paragraph/editor are released. So the editor morph should be passed instead of the editor itself. A fix is coming soon.

Dec. 21, 2010

[Pharo-project] Citezen vs. Google Scholar bug??

by Schwab,Wilhelm K

Stef, I *think* Google Scholar is in the wrong here, but I'll mention it just in case. I've tried to paste the controversial entry below, but in case it gets corrupted in transfer, it is the third hit on Google Scholar with surface tension inclined tube stability Dumitrescu @article{couÃ«t1987effects, title={{The effects of surface tension and tube inclination on a two-dimensional rising bubble}}, author={Cou{\\"e}t, B. and Strumolo, G.S.}, journal={Journal of Fluid Mechanics}, volume={184}, pages={1--14}, issn={0022-1120}, year={1987}, publisher={Cambridge Univ Press} } The BibTeX source above is from GS' "Import into BibTeX" feature. Citezen didn't like it. I am assuming that the problem is that accented e in the key. Changing it to a "plain" e allowed my code to proceed. The real question is whether extended characters are legal in the key? If not, then Citezen is correct to complain. Bill

Dec. 21, 2010

Re: [Pharo-project] a way to ignore warnings?

by Dale Henrichs

HernÃ¡n I agree with you, because practicality outweighs correctness... However I mainly wanted to point out that handling Notifications in the general case is not a good idea ... For development and personal scripts, where you can fix the problems on the fly just about anything goes ... Dale On 12/21/2010 10:41 AM, HernÃ¡n Morales Durand wrote: > Hi Dale, > > Thanks for your comments, some notes between lines... > > 2010/12/21 Dale Henrichs<dhenrich(a)vmware.com>: >> On 12/20/2010 09:27 PM, HernÃ¡n Morales Durand wrote: >>> >>> 2010/12/20 Esteban Lorenzano<estebanlm(a)gmail.com>: >>>> >>>> duh... >>>> [ ... ] on: Warning do: [ :w | w resume ]. >>>> forget my question... :( >>> >>> That wouldn't make it for Notifications such as: >>> >>> self inform: 'test' >>> >>> so you might want to write: >>> >>> [ self inform: 'test' ] >>> on: Warning, Notification >>> do: [: ex | ex return: 'Ignored: ' , ex class name , ' ' , ex messageText >>> ]. >>> >> >> I would be careful about handling all Notifications. Unlike Error, there is >> no "correct" pattern for handling Notifications, just take a look at all >> implementors of #defaultAction for subclasses of Notification and you will >> see that in most cases, the default action returns an application specific >> object, so returning a String instead will break them all .. >> >> Notifications are meant to be ignored unless you know what you are doing. >> > > Agree. Although I think you're focusing on handling properly the > answer but Esteban just wanted to bypass modal dialogs so a time > consuming operation could finish without human intervention. In that > case we can assume he isn't going to provide a "dangerous" default for > a confirm operation and he'd like to log warnings and informations. > Esteban may you comment is that your case? > >> It turns out that even handling Warning can be dangerous. For Warning it is >> correct to use #resume to ignore the Warning (which ends up doing a `ex >> resume: nil`). However, UndeclaredVariableWarning (a subclass of Warning) >> expects a Boolean result, so if the code you are wrapping does any compiles >> you'll have to special case UndeclaredVariableWarning to do `ex resume: >> true`. >> > > Yes, I've seen the UndeclaredVariableWarning (from > Encoder>>undeclared: ) dialog many times when compiling > programatically, and one of things is that I have to handle every > compilation to avoid this dialog like this: > > [ self targetClass > compile: aString > classified: aCategoryClassification ] > on: UndeclaredVariableWarning > do: [: ex | self log: 'Warning UndeclaredVariableWarning in ' , self > targetClass asString , '>>' , aString asString ] > > I didn't found a preference to ignore this dialog, although I've found > > Parser warningAllowed -> false "That would be the More Warnings preference " > > I wonder is there a setting I've missed? > >> To ignore #inform: in Pharo, handling ProvideAnswerNotification is a better >> choice than Notification, but you need to be aware of the implications of >> ignoring inform: as ProvideAnswerNotification is used for dealing with: >> >> inform: - return value is ignored >> confirm:: - return values is expected to be a Boolean >> request: - is expected to be a String >> >> As Adrian mentions, if you are want to automate the handling of >> inform:/confirm:/request: you are better off using valueSupplyingAnswers:. >> >> Finally, in the above example using 'ex return:'a string` is not the correct >> way to ignore a Warning or Notification. The #return: messages returns the >> arg as the result of the block (unwinding the stack). #resume: returns the >> arg as the result of the #signal: and continues execution from that point. >> Take a look at the different results for the following two expressions: >> >> | w x y z | >> w := x:= y:= z:= nil. >> x:= [ w := #before. >> y:= self confirm: 'test'. >> z := #after ] >> on: ProvideAnswerNotification >> do: [:ex | ex return: false ]. >> {w. x. y. z.}. >> >> | w x y z | >> w := x:= y:= z:= nil. >> x:= [ w := #before. >> y:= self confirm: 'test'. >> z := #after ] >> on: ProvideAnswerNotification >> do: [:ex | ex resume: false ]. >> {w. x. y. z.}. >> > > I don't know if assuming always that "correct" means continue > execution in that scope. It may depend on the warning or notification > and the block task, but of course #resume: is a more common sense > choice for most cases. > >> HernÃ¡n this is common mistake when putting together simple examples and if I >> hadn't just finished writing a series of automatic Warning handlers, I >> wouldn't have picked up on it:) >> > > I know :) it could be as complex as hell, that's why I say you have to > automate exceptions with a specific goal in mind, for example logging > or finish an unattended loading. > Cheers, >

Dec. 21, 2010