- Pharo-dev - lists.pharo.org

Re: [Pharo-project] about the closure

by Marcus Denker

On 01.04.2009, at 11:31, StÃ©phane Ducasse wrote: > > On Apr 1, 2009, at 11:12 AM, Lukas Renggli wrote: > >>> lukas is it normal that we get 3 tests yellow - did you get the same >>> in your image? >> >> #testToDoOutsideTemp and #testWhileModificationBefore are broken. I >> don't think that should stop us from integrating the closures into >> Pharo. Most "industrial strength" Smalltalk implementations have many >> more closure bugs than Pharo. > > This is integrated already and this is good to have such great test > suites. > I will integrate them this evening. > Lukas' teste should be already in, I think. Marcus -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

April 1, 2009

Re: [Pharo-project] how do replace barVal by barValTmp in a method?

by Lukas Renggli

With the regular expression extensions to OB-Refactory it is possible to search and replace strings across a selected set of methods. I understand that this is not what you want either, but I like the feature ;-) Lukas On Wed, Apr 1, 2009 at 11:31 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes I should have asked without using rb. > I think that any texteditor should have that feature :) > > Stef > > On Apr 1, 2009, at 11:05 AM, Lukas Renggli wrote: > >> The refactoring browser provides "refactor code > rename temporary". >> Make sure to have a temporary variable selected before trying to >> invoke that command. >> >> Lukas >> >> On Tue, Mar 31, 2009 at 9:38 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Hi >>> >>> this is several time that I need such simple edit function and I do >>> not suceed. >>> Does one of you know how do replace barVal by barValTmp in a method? >>> >>> Setf >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

April 1, 2009

Re: [Pharo-project] isMorphic left over

by StÃ©phane Ducasse

Thanks marcus. I should undertsand how to get internet in TGV On Apr 1, 2009, at 11:21 AM, Marcus Denker wrote: > > On 31.03.2009, at 20:56, StÃ©phane Ducasse wrote: > >> While playing with closure I got some isMorphic so I cleaned that. >> > > > http://code.google.com/p/pharo/issues/detail?id=703 > > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 1, 2009

Re: [Pharo-project] about the closure

by StÃ©phane Ducasse

On Apr 1, 2009, at 11:12 AM, Lukas Renggli wrote: >> lukas is it normal that we get 3 tests yellow - did you get the same >> in your image? > > #testToDoOutsideTemp and #testWhileModificationBefore are broken. I > don't think that should stop us from integrating the closures into > Pharo. Most "industrial strength" Smalltalk implementations have many > more closure bugs than Pharo. This is integrated already and this is good to have such great test suites. I will integrate them this evening. > > >> Did you say it to eliot? > > Eliot already fixed the third failure you are observing. Load the > attached change-set and recompile the tests. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > <TempVariableNode- > analyseClosure.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 1, 2009

Re: [Pharo-project] [ANN] #10262cl

by Lukas Renggli

I guess it is my fault. I forwarded it to various people, probably just not to the right ones ;-) Lukas On Wed, Apr 1, 2009 at 11:29 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Because marcus was not aware of it. > I will add it this evening (if nobody does it before). > > Stef > > On Mar 31, 2009, at 10:35 PM, Lukas Renggli wrote: > >>> on the closure related note, what is perhaps interesting in a >>> workspace is >>> >>> values := (1 to: 5) collect: [:each | [each] ]. >>> values collect: [:each | each value] >>> --> #(1 2 3 4 5) >> >> That's correct. >> >>> | i | >>> values := (1 to: 5) collect: [:each | >>> Â Â Â Â Â Â Â Â Â Â Â Â i := each. >>> Â Â Â Â Â Â Â Â Â Â Â Â [i] ]. >>> values collect: [:each | each value] >>> -->#(5 5 5 5 5) >> >> That behavior is correct. i is defined outside the block, thus it >> refers to the current number which is 5. >> >>> values := OrderedCollection new. >>> 1 to: 5 do: [:i | values add: [i] ]. >>> values collect: [:each | each value] >>> --> an OrderedCollection(6 6 6 6 6) >> >> That's a bug, but already fixed by Eliot. I don't know why the patch >> is not included with the image? Load the attachement. >> >> The two other failing tests are actually failing in most Smalltalk, >> even in commercial ones. >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> <TempVariableNode- >> analyseClosure.st>_______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

April 1, 2009

Re: [Pharo-project] how do replace barVal by barValTmp in a method?

by StÃ©phane Ducasse

Yes I should have asked without using rb. I think that any texteditor should have that feature :) Stef On Apr 1, 2009, at 11:05 AM, Lukas Renggli wrote: > The refactoring browser provides "refactor code > rename temporary". > Make sure to have a temporary variable selected before trying to > invoke that command. > > Lukas > > On Tue, Mar 31, 2009 at 9:38 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Hi >> >> this is several time that I need such simple edit function and I do >> not suceed. >> Does one of you know how do replace barVal by barValTmp in a method? >> >> Setf >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 1, 2009

Re: [Pharo-project] SUniGUI profiled DNU

by StÃ©phane Ducasse

Strange it did not show up. Stef On Apr 1, 2009, at 11:03 AM, Lukas Renggli wrote: >> From the Test Runner. Click on "Run Coverage". > > Lukas > > On Tue, Mar 31, 2009 at 8:37 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> lukas how to you invoke the coverage for a test? >> I tried with profiled and I got a DNU. >> >> Stef >> >> From: zork >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: [BUG]UndefinedObject(Object)>>doesNotUnderstand: #terminate >> >> here insert explanation of what you were doing, suspect changes >> you've >> made and so forth. >> >> 31 March 2009 8:36:50 pm >> >> VM: Mac OS - a SmalltalkImage >> Image: Pharo0.1 [Latest update: #10259] >> >> SecurityManager state: >> Restricted: false >> FileAccess: true >> SocketAccess: true >> Working Dir /Users/ducasse/Workspace/FirstCircle/ActiveResearch/ >> Pharo/ >> Pharo >> Trusted Dir /foobar/tooBar/forSqueak/bogus >> Untrusted Dir /Users/ducasse/Library/Preferences/Squeak/Internet/My >> Squeak >> >> UndefinedObject(Object)>>doesNotUnderstand: #terminate >> Receiver: nil >> Arguments and temporary variables: >> aMessage: terminate >> exception: MessageNotUnderstood: >> UndefinedObject>>terminate >> resumeValue: nil >> Receiver's instance variables: >> nil >> >> [] in MessageTally>>spyEvery:on: {[SmalltalkImage current >> getVMParameters keysAndValuesDo: [:idx :gcVal | gc...]} >> Arguments and temporary variables: >> millisecs: 1 >> aBlock: [] in TestRunner>>runProfiled {[self >> runAll]} >> myDelay: a Delay >> startTime: 311391 >> time0: 307811 >> idx: 40 >> gcVal: 4 >> >> BlockContext>>ensure: >> Receiver: [] in TestRunner>>runProfiled {[self runAll]} >> Arguments and temporary variables: >> aBlock: nil >> returnValue: a TestRunner >> b: [] in MessageTally>>spyEvery:on: >> {[SmalltalkImage current >> getVMParameters ...etc... >> Receiver's instance variables: >> sender: nil >> pc: nil >> stackp: 0 >> nargs: 0 >> startpc: 31 >> home: TestRunner>>runProfiled >> >> MessageTally>>spyEvery:on: >> Receiver: TestRunner >> runProfiled >> Arguments and temporary variables: >> millisecs: 1 >> aBlock: [] in TestRunner>>runProfiled {[self >> runAll]} >> myDelay: a Delay >> startTime: 311391 >> time0: 307811 >> idx: 40 >> gcVal: 4 >> Receiver's instance variables: >> class: TestRunner >> method: a CompiledMethod (1657) >> tally: 3568 >> receivers: an Array(TestRunner >> runAll >> SystemProgressMorph >> >> label:min:max: ...etc... >> senders: nil >> time: nil >> gcStats: #(3672228 3627200 4333372 -1629 0 0 >> 0 0 2511 917 47 0 0 0 >> 0 0 0 0 0 0 ...etc... >> maxClassNameSize: 30 >> maxClassPlusSelectorSize: 60 >> maxTabs: 60 >> >> >> --- The full stack --- >> UndefinedObject(Object)>>doesNotUnderstand: #terminate >> [] in MessageTally>>spyEvery:on: {[SmalltalkImage current >> getVMParameters keysAndValuesDo: [:idx :gcVal | gc...]} >> BlockContext>>ensure: >> MessageTally>>spyEvery:on: >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> MessageTally class>>spyOn: >> TestRunner>>runProfiled >> PluggableButtonMorphPlus(PluggableButtonMorph)>>performAction >> PluggableButtonMorphPlus>>performAction >> [] in PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp: {[:m | >> (m containsPoint: evt cursorPoint) ifTrue: [m performAction]]} >> Array(SequenceableCollection)>>do: >> PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp: >> PluggableButtonMorphPlus>>mouseUp: >> PluggableButtonMorphPlus(Morph)>>handleMouseUp: >> MouseButtonEvent>>sentTo: >> PluggableButtonMorphPlus(Morph)>>handleEvent: >> PluggableButtonMorphPlus(Morph)>>handleFocusEvent: >> [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self. >> ActiveEvent := anEvent. result := focusHolder han...]} >> [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]} >> BlockContext>>on:do: >> PasteUpMorph>>becomeActiveDuring: >> HandMorph>>sendFocusEvent:to:clear: >> HandMorph>>sendEvent:focus:clear: >> HandMorph>>sendMouseEvent: >> HandMorph>>handleEvent: >> HandMorph>>processEvents >> [] in WorldState>>doOneCycleNowFor: {[:h | ActiveHand := h. h >> processEvents. ActiveHand := nil]} >> Array(SequenceableCollection)>>do: >> WorldState>>handsDo: >> WorldState>>doOneCycleNowFor: >> WorldState>>doOneCycleFor: >> PasteUpMorph>>doOneCycle >> [] in Project class>>spawnNewProcess {[[World doOneCycle. Processor >> yield. false] whileFalse. nil]} >> [] in BlockContext>>newProcess {[self value. Processor >> terminateActive]} >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 1, 2009

Re: [Pharo-project] [ANN] #10262cl

by StÃ©phane Ducasse

Apparently this is realted to the bug I mentioned can you test the fixes that mike sent. Stef On Apr 1, 2009, at 10:19 AM, Torsten Bergmann wrote: > When evaluating > > "ScriptLoader loadSuperOB" > > in this image I'll get nil DNU #charCode in the Method > UTF8DecomposedTextConverter>>nextFromStream: > > (with both - the newest win32 vm from Andreas and > the latest Exupery VM with closures). > > Thx > Torsten > -- > Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + > Telefonanschluss fÃ¼r nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 1, 2009

Re: [Pharo-project] [ANN] #10262cl

by StÃ©phane Ducasse

Because marcus was not aware of it. I will add it this evening (if nobody does it before). Stef On Mar 31, 2009, at 10:35 PM, Lukas Renggli wrote: >> on the closure related note, what is perhaps interesting in a >> workspace is >> >> values := (1 to: 5) collect: [:each | [each] ]. >> values collect: [:each | each value] >> --> #(1 2 3 4 5) > > That's correct. > >> | i | >> values := (1 to: 5) collect: [:each | >> i := each. >> [i] ]. >> values collect: [:each | each value] >> -->#(5 5 5 5 5) > > That behavior is correct. i is defined outside the block, thus it > refers to the current number which is 5. > >> values := OrderedCollection new. >> 1 to: 5 do: [:i | values add: [i] ]. >> values collect: [:each | each value] >> --> an OrderedCollection(6 6 6 6 6) > > That's a bug, but already fixed by Eliot. I don't know why the patch > is not included with the image? Load the attachement. > > The two other failing tests are actually failing in most Smalltalk, > even in commercial ones. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > <TempVariableNode- > analyseClosure.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 1, 2009

Re: [Pharo-project] [ANN] #10262cl

by StÃ©phane Ducasse

It would be great. I mean Really great. Even if we want to have a better OB based may be system having a fall back is really important On Mar 31, 2009, at 10:07 PM, Dale Henrichs wrote: > > ----- "Michael Roberts" <mike(a)mjr104.co.uk> wrote: > > | guys I have done a quick test of the closure image, with the mac VM > | on > | the inria page. > | > | I think it is probably unrelated but the old debugger in the core > | image is severely broken. Could someone please remind me > | > | 1) what we were going to do with the old debugger. I know there is > | work going on in the dev image on the new one... what is the > | strategy? > | > | 2) i'd appreciate if someone could see if there is a bug report that > | confirms this behaviour below. Otherwise I will at least file a > | report. Candidate bug report is #329 but I am not sure exactly if > it > | is what I see. > | > | steps > | 1. run ClosureTests in the test runner > | 2. 3 fail, so click on testToDoWithArgument > | 3. hit debug > | 4. restart the test method > | 5. step over the to:do:. you only enter the loop block once, BUG #1 > | ? > | 6. step into the assertValues: method as it is highlighted > | 7. highlight now enters the loop again, not into the utility method. > | BUG #2 ? > | 8. carefully step until you get into the assert method, if you do > | this > | wrong a new notifier pops up BUG #3. if you kill this you get error > | unwind pop up that you can't ever kill. BUG #4 ? > | > | basically this debugger is unusable and I think it has been for some > | time. I'm sure I commented in the past. so please give me your > | thoughts on the old debugger and live issues in the tracker. Do > | people not notice, because they generally load the OB debugger? I > | want to know where to concentrate my efforts. I'm not sure we should > | develop the old debugger too much, but at one point it did work in > | squeak. I'm sure the unwind notifier bug predates pharo. surely > it's > | not just me. my vote would be to attempt to fix the debugger, so we > | have one in the core image that works, and then perhaps leave it > | alone.. or we promote the new one into it when it can be a > | replacement. > | > | on the closure related note, what is perhaps interesting in a > | workspace is > | > | values := (1 to: 5) collect: [:each | [each] ]. > | values collect: [:each | each value] > | --> #(1 2 3 4 5) > | > | | i | > | values := (1 to: 5) collect: [:each | > | i := each. > | [i] ]. > | values collect: [:each | each value] > | -->#(5 5 5 5 5) > | > | values := OrderedCollection new. > | 1 to: 5 do: [:i | values add: [i] ]. > | values collect: [:each | each value] > | --> an OrderedCollection(6 6 6 6 6) > | > | I know the second and third gives non closure related result, but I > | don't know if the first one shows valid closure or not. > | > | Anyway please direct and I will keep testing. > > If there is consensus to fix the old debugger, and noone else steps > to the plate, I would be willing to see what I could do in getting > the old debugger functional with the ClosureTests... > > Dale > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 1, 2009