December 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 2360 in pharo: nil out locals in a block if readBeforeWritten

by pharo＠googlecode.com

Comment #9 on issue 2360 by marcus.denker: nil out locals in a block if readBeforeWritten http://code.google.com/p/pharo/issues/detail?id=2360 Issue 3416 has been merged into this issue.

Dec. 21, 2010

[Pharo-project] Issue 3473 in pharo: Issue 1213: Unable to type some czech characters

by pharo＠googlecode.com

Status: Closed Owner: marcus.denker Labels: Milestone-1.2 New issue 3473 by marcus.denker: Issue 1213: Unable to type some czech characters http://code.google.com/p/pharo/issues/detail?id=3473 I will delete issue 1213 (which is un-closable). I attach a printout as pdf and the code. Attachments: Issue 1213 - pharo - Unable to type some czech characters - Project Hosting on Google Code.pdf 171 KB

Dec. 21, 2010

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