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

Re: [Pharo-project] [bug] 1.0-10505 Saving image kills version browsers

by Lukas Renggli

I can confirm this problem. Please create a bug report in the bug tracker: http://code.google.com/p/omnibrowser/ Lukas 2010/1/17 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Sun, Jan 17, 2010 at 3:13 AM, Martin McClure <martin(a)hand2mouse.com> > wrote: >> >> It looks like if you browse versions of a method, and save the image >> while the versions browser is open, this sets the source pointers in all >> of the versions in the browser to nil. >> >> Then you get a DNU if you click on any of the versions. >> >> Workaround: Close the bad version browser, open a new one. > > Wow! That's a cool bug :)Â Â Yes, I could reproduce it in 1.0 505 Dev, but > not in the core.Â Â Would you mind trying also in core? > > Because if it works on core, but not in dev, it would be a problem maybe > with OB. > > Cheers > > Mariano > >> >> Regards, >> >> -Martin >> >> _______________________________________________ >> 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

Jan. 17, 2010

Re: [Pharo-project] [bug] 1.0-10505 Saving image kills version browsers

by Mariano Martinez Peck

On Sun, Jan 17, 2010 at 3:13 AM, Martin McClure <martin(a)hand2mouse.com>wrote: > It looks like if you browse versions of a method, and save the image > while the versions browser is open, this sets the source pointers in all > of the versions in the browser to nil. > > Then you get a DNU if you click on any of the versions. > > Workaround: Close the bad version browser, open a new one. > Wow! That's a cool bug :) Yes, I could reproduce it in 1.0 505 Dev, but not in the core. Would you mind trying also in core? Because if it works on core, but not in dev, it would be a problem maybe with OB. Cheers Mariano > > Regards, > > -Martin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 17, 2010

Re: [Pharo-project] send a message code kata

by Henrik Sperre Johansen

If you add one on exceptions, maybe: [PrStef bareNext] on: MessageNotUnderstood do: [PrStef next] Cheers, Henry On 17.01.2010 11:39, laurent laffont wrote: > Hi, > > for PrStef (that may be renamed ProfStef - thanks Lukas) there are > several ways to go to the next lesson: > > PrStef next. > > [PrStef next] value. > > 3=3 ifTrue: [PrStef next]. > > 1 to: 1 do: [:i | PrStef next]. > > I'm thinking about adding more of it: > > (Smalltalk at: #PrStef) next. > > PrStef perform: #next. > > > I'm sure you know other funny ways to send #next on PrStef :) > > > Laurent > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 17, 2010

[Pharo-project] send a message code kata

by laurent laffont

Hi, for PrStef (that may be renamed ProfStef - thanks Lukas) there are several ways to go to the next lesson: PrStef next. [PrStef next] value. 3=3 ifTrue: [PrStef next]. 1 to: 1 do: [:i | PrStef next]. I'm thinking about adding more of it: (Smalltalk at: #PrStef) next. PrStef perform: #next. I'm sure you know other funny ways to send #next on PrStef :) Laurent

Jan. 17, 2010

Re: [Pharo-project] Pharo 1.0 & 1.1 failing tests testFinalizationOfEquals

by StÃ©phane Ducasse

ok I will digest all the discussions first On Jan 17, 2010, at 8:15 AM, Nicolas Cellier wrote: > 2010/1/17 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> >> On Sat, Jan 16, 2010 at 12:33 PM, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>> I wrote this test pre-closure. >>> The problem with closures is that they are optimized to retain a >>> pointer to the values of outer temporary variable they use when >>> activated. >> >> Not exactly. >> >>> >>> Thus the BlockClosures forAnyTwoEqualObjects ofDifferentIdentity >>> registeringAnActionAtFinalizationForEachObject all refer to 'hello' >>> pointed by o1 and its copy pointed by o2. >>> In other words, o1 and o2 are not the single pointers to the String >>> 'hello' and its copy. >> >> They are. See below. >> >>> >>> thenForcingFinalizationOfObjects only clean o1 and o2, but omit to >>> clean the closures that still point to 'hello'... >>> Thus, 'hello' is not finalized. >>> One possibility is to also clean the closures pointing to 'hello'. >>> But now the code is tricky... It's aim was to be simple damned :) >> >> There are single pointers to o1 and o2 from all the code in the test. o1 >> and o2 are stored in an indirect temp vector array created at the start of >> the method. The compiler puts them there because there is an assignment to >> each after they are closed over: >> o1 := o2 := nil. Smalltalk garbageCollect]. >> All the blocks that reference o1 or o2 actually reference the indirect temp >> vector, so there is only one reference to o1 and o2 from all code in the >> method, though a single indirect temp vector. So as soon as >> o1 := o2 := nil. >> is executed the only references to o1 & o2 from code have been deleted. > > Oh thanks, I get it, the tempVector is the only pointer to 'hello' > because it is used both inside and outside blocks. > Maybe the WeakKeyIdentityDictionary bug lead me to this false conclusion... > > Stef, Marcus, don't change this method, just correct issue 1839 (and > remove the expected failure) > > Nicolas > >>> >>> Nicolas >>> >>> >>> here is a corrected version : >>> >>> >>> testFinalizationOfEquals >>> "self debug: #testFinalizationOfEquals" >>> >>> | finalizationProbe o1 o2 >>> forAnyTwoEqualObjects >>> ofDifferentIdentity >>> registeringAnActionAtFinalizationForEachObject >>> thenForcingFinalizationOfObjects >>> implyBothRegisteredActionsAreExecuted | >>> >>> finalizationProbe := Set new. >>> o1 := 'hello' copy. >>> o2 := 'hello' copy. >>> forAnyTwoEqualObjects := [o1 = o2]. >>> ofDifferentIdentity := [o1 ~~ o2]. >>> registeringAnActionAtFinalizationForEachObject := [ >>> o1 toFinalizeSend: #add: to: finalizationProbe with: >>> 'first object finalized'. >>> o2 toFinalizeSend: #add: to: finalizationProbe with: >>> 'second object >>> finalized']. >>> thenForcingFinalizationOfObjects := [ >>> forAnyTwoEqualObjects := ofDifferentIdentity := >>> registeringAnActionAtFinalizationForEachObject := nil. >>> o1 := o2 := nil. Smalltalk garbageCollect]. >>> implyBothRegisteredActionsAreExecuted := [finalizationProbe size = >>> 2]. >>> >>> self >>> assert: forAnyTwoEqualObjects; >>> assert: ofDifferentIdentity; >>> should: [ >>> registeringAnActionAtFinalizationForEachObject >>> value. >>> thenForcingFinalizationOfObjects value. >>> implyBothRegisteredActionsAreExecuted value]. >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 17, 2010

Re: [Pharo-project] SystemWindow updatablePanes ivar

by StÃ©phane Ducasse

On Jan 17, 2010, at 4:33 AM, Igor Stasenko wrote: > Hello, > > I completely lost in the logic of this thing. > > why a SystemWindow cares about something called panes? > What if my window don't having/needs any of them? > Why Object cares about #updateListsAndCodeIn: aWindow ??? > > If model is updated, then it should just send #changed, or self > changed: #myPaneFoo > and if SystemWindow's pane is dependent, it will be updated. May be this is related to the fact that the style gets propagated to its subcomponent. I know I was bitten by that some years ago. > > What the point in using #verifyContents... > > This thing needs to be cleaned up. yes ;) > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 17, 2010

Re: [Pharo-project] strange local variable problem

by Lukas Renggli

> I believe this is a bug. That's the correct behavior. This is exactly how closures should behave. The variable declaration is outside the block you store thus one variable slot is shared among multiple block definitions inside. See ClosureTests for more examples of that behavior. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 17, 2010

Re: [Pharo-project] About versions on PharoInbox

by Levente Uzonyi

On Sun, 17 Jan 2010, Miguel Enrique CobÃ¡ Martinez wrote: > During the uploading of the mcz of Morphic to PharoInbox http://code.google.com/p/pharo/issues/detail?id=1841 I used a 10506 image. The software update gave 0 files and the Monticello browser showed: Morphic-MarkusDenker.392 my changes generated: Morphic-MiguelCoba.395 But when opening the PharoInbox I saw that there are versions like Morphic-nice.494 Morphic-TorstenBergmann.492 Morphic-AlainPlantec.490 and they have date as close as January 13, 2010. But the image has a version very old (or so appears by the version number) and my changes was based in MarkusDenker.392. Can someone explain this? Sure, 1.0 and 1.1 shares the same inbox. Levente Will this affect the integration of my change to PharoCore? Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 17, 2010

Re: [Pharo-project] strange local variable problem

by Levente Uzonyi

On Sun, 17 Jan 2010, Tudor Girba wrote: > Hi, > > I have a method that takes OBCommands and returns Actions: > > actionsFrom: aCollectionOfOBCommandClasses on: aTarget for: aRequestor > | command | > ^ aCollectionOfOBCommandClasses collect: [ :each | > command := each on: aTarget for: aRequestor. > GLMAction new > icon: command icon; > title: command label; > action: [:presentation | command execute ]; > yourself > ] > > These actions have a block that will be executed at a later time. The > problem here was that the command in the action block was always > pointing to the same command object, even at each point the command > variable was populated correctly. > > However, when the command is defined inside the block, everything > works as expected. > > actionsFrom: aCollectionOfOBCommandClasses on: aTarget for: aRequestor > ^ aCollectionOfOBCommandClasses collect: [ :each | > | command | > command := each on: aTarget for: aRequestor. > GLMAction new > icon: command icon; > title: command label; > action: [:presentation | command execute ]; > yourself > ] > > I believe this is a bug. This is exactly how it should work, it's a feature that I used to use. Levente > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Obvious things are difficult to teach." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 17, 2010

Re: [Pharo-project] Pharo 1.0 & 1.1 failing tests testFinalizationOfEquals

by Nicolas Cellier

2010/1/17 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Sat, Jan 16, 2010 at 12:33 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> I wrote this test pre-closure. >> The problem with closures is that they are optimized to retain a >> pointer to the values of outer temporary variable they use when >> activated. > > Not exactly. > >> >> Thus the BlockClosures forAnyTwoEqualObjects ofDifferentIdentity >> registeringAnActionAtFinalizationForEachObject all refer to 'hello' >> pointed by o1 and its copy pointed by o2. >> In other words, o1 and o2 are not the single pointers to the String >> 'hello' and its copy. > > They are. Â See below. > >> >> thenForcingFinalizationOfObjects only clean o1 and o2, but omit to >> clean the closures that still point to 'hello'... >> Thus, 'hello' is not finalized. >> One possibility is to also clean the closures pointing to 'hello'. >> But now the code is tricky... It's aim was to be simple damned :) > > There are single pointers to o1 and o2 from all the code in the test. Â o1 > and o2 are stored in an indirect temp vector array created at the start of > the method. Â The compiler puts them there because there is an assignment to > each after they are closed over: > Â Â Â Â Â Â Â Â Â o1 := o2 := nil. Smalltalk garbageCollect]. > All the blocks that reference o1 or o2 actually reference the indirect temp > vector, so there is only one reference to o1 and o2 from all code in the > method, though a single indirect temp vector. Â So as soon as > Â Â Â Â Â Â Â Â o1 := o2 := nil. > is executed the only references to o1 & o2 from code have been deleted. Oh thanks, I get it, the tempVector is the only pointer to 'hello' because it is used both inside and outside blocks. Maybe the WeakKeyIdentityDictionary bug lead me to this false conclusion... Stef, Marcus, don't change this method, just correct issue 1839 (and remove the expected failure) Nicolas >> >> Nicolas >> >> >> here is a corrected version : >> >> >> testFinalizationOfEquals >> Â Â Â Â "self debug: #testFinalizationOfEquals" >> >> Â Â Â Â | finalizationProbe o1 o2 >> Â Â Â Â forAnyTwoEqualObjects >> Â Â Â Â ofDifferentIdentity >> Â Â Â Â registeringAnActionAtFinalizationForEachObject >> Â Â Â Â thenForcingFinalizationOfObjects >> Â Â Â Â implyBothRegisteredActionsAreExecuted | >> >> Â Â Â Â finalizationProbe := Set new. >> Â Â Â Â o1 := 'hello' copy. >> Â Â Â Â o2 := 'hello' copy. >> Â Â Â Â forAnyTwoEqualObjects := [o1 = o2]. >> Â Â Â Â ofDifferentIdentity := [o1 ~~ o2]. >> Â Â Â Â registeringAnActionAtFinalizationForEachObject := [ >> Â Â Â Â Â Â Â Â o1 toFinalizeSend: #add: to: finalizationProbe Â with: >> 'first object finalized'. >> Â Â Â Â Â Â Â Â o2 toFinalizeSend: #add: to: finalizationProbe Â with: >> 'second object >> finalized']. >> Â Â Â Â thenForcingFinalizationOfObjects := [ >> Â Â Â Â Â Â Â Â forAnyTwoEqualObjects := ofDifferentIdentity := >> registeringAnActionAtFinalizationForEachObject := nil. >> Â Â Â Â Â Â Â Â o1 := o2 := nil. Smalltalk garbageCollect]. >> Â Â Â Â implyBothRegisteredActionsAreExecuted := [finalizationProbe size = >> 2]. >> >> Â Â Â Â self >> Â Â Â Â Â Â Â Â assert: forAnyTwoEqualObjects; >> Â Â Â Â Â Â Â Â assert: ofDifferentIdentity; >> Â Â Â Â Â Â Â Â should: [ >> Â Â Â Â Â Â Â Â Â Â Â Â registeringAnActionAtFinalizationForEachObject >> value. >> Â Â Â Â Â Â Â Â Â Â Â Â thenForcingFinalizationOfObjects value. >> Â Â Â Â Â Â Â Â Â Â Â Â implyBothRegisteredActionsAreExecuted value]. >> >> _______________________________________________ >> 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 >

Jan. 17, 2010