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

Re: [Pharo-dev] problems with RPackage and cie...

by Esteban Lorenzano

https://pharo.fogbugz.com/f/cases/12718 that should fix the problem. weâll see :P Esteban On 24 Jan 2014, at 14:58, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > Step to reproduce: > > Open latest Pharo30719. > Create a new package with shortcut or menu. > Name it âAST-Monkeyâ (to have a RPackage not a Tag) > Go in another package. > Select some classes. > CMD M + CMD C (and probably with the menu too) (note that the Drag nâ Drop works) > Type the name of the package âAST-Monkeyâ + enter > BOUM > > Might be that you fixed the drag n drop in the PackageTreeNautilusUI but not the move class. > > Ben > > On 24 Jan 2014, at 10:23, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> I would really like a reproducible caseâ¦ in the form of an image, if no else. >> >> btwâ¦ moose 5.0 images are severely broken in that area, so if you are using one of them you *will* have problems. >> >> Esteban >> >> On 24 Jan 2014, at 13:28, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >>> >>> >>> Le 23/01/2014 18:57, Benjamin Van Ryseghem a Ã©crit : >>>> Just that you know I faced it again :( >>>> I created a new RPackage, move classes in the newly created RPackage. >>>> And when I wanted to commit the code, it was empty. >>> >>> Have you tried with the old Browser to see if your classes were in the right category? >>> >>> (When I see something suspicious like that happening, I often open the three browsers to double check: AltBrowser, Nautilus and Browser). >>> >>> And I have not seen anything suspicious that I could pinpoint to RPackage so far. Small bugs easily corrected, yes. Big totally out of sync, no. >>> >>> Thierry >>> -- >>> Thierry Goubier >>> CEA list >>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>> 91191 Gif sur Yvette Cedex >>> France >>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>> >> >> >

Jan. 24, 2014

asReactiveVariable ????

by Pharo4Stef

Hi guys, I think that we will rename all the asReactiveVariable that got introduced into their old name asValueHolder. And we will rename the class too to its old name. Why? I think that we should not change at the last moment ValueHolder into ReactiveVariable even if the name could be better: - First there are books around (and not only mine) that use this vocabulary for decades. - Second all the Spec tools developed by people right now do not work in latest 3.0. - I think that this change does not worth the noise it introduced: all the future changes of Spec-based tools that will be using asReactive will not work in Pharo3.0. We are in beta and now we should not change that. Then I would appreciate that we discuss it before. Because I would not change that even between versions of Pharo. Stef

Jan. 24, 2014

Re: [Pharo-dev] [squeak-dev] [Fuel] Back to stable builds

by Mariano Martinez Peck

Thanks Max! So you finally implemented the prunning? If true, what about opening an issue to prune the stack in Pharo when: 1) we export from a debugger 2) the jenkins CI saves the failed test ? Thanks!!! On Thu, Jan 23, 2014 at 6:47 PM, Max Leske <maxleske(a)gmail.com> wrote: > Hi guys > > So apparently somehow the problems weâve had with the builds are now gone. > Iâve reenabled failure e-mails for failed / broken builds. > > Hereâs whatâs on my list and what I will work on (in that order): > - fix last failing test for 3.0 > - prepare compatibility packages for Squeak4.5 (see > https://code.google.com/p/fuel/issues/detail?id=204&colspec=ID%20Type%20Sta… > ) > - implement truncation (see > https://code.google.com/p/fuel/issues/detail?id=203&colspec=ID%20Type%20Sta… > ) > > Cheers, > Max > -- Mariano http://marianopeck.wordpress.com

Jan. 24, 2014

Re: [Pharo-dev] Issue 2711 Monticello wastes significant amounts of memory

by Sean P. DeNigris

Sean P. DeNigris wrote > If it's not for 4.0... Should have been "not for 3.0"â¦ duh... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-2711-Monticello-wastes-significant-amounts-of-m… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 24, 2014

Re: [Pharo-dev] Issue 2711 Monticello wastes significant amounts of memory

by Sean P. DeNigris

Stephan Eggermont wrote > The number of distinct authors of monticello packages is not so large. > ... > Can we expect issues if we replace the author string by a symbol? > â¦ > I donât think this should be a must-fix for 3.0 If it's not for 4.0, how about a real object? Something like "Authors authorNamed: aString". ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-2711-Monticello-wastes-significant-amounts-of-m… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 24, 2014

Issue 2711 Monticello wastes significant amounts of memory

by Stephan Eggermont

The number of distinct authors of monticello packages is not so large. MCVersionInfo allInstances size 13984 Pharo 30716 30721 Moose 5.0 (on 30714) (MCVersionInfo allInstances collect: [ :each | each author ]) asSet size 129 Pharo 30716 269 Moose 5.0 Can we expect issues if we replace the author string by a symbol? WideString issues perhaps? initializeWithName: vName id: aUUID message: aString date: aDate time: aTime author: initials ancestors: aCollection stepChildren: stepCollection name := vName. id := aUUID. message := aString. date := aDate. time := aTime. author := initials asSymbol. ancestors := aCollection. stepChildren := stepCollection author ^ author asString and then replace all authors by their symbols in the image? We could do the same for date (1821 unique in 30716, 3027 in Moose 5) This is issue 2711 I donât think this should be a must-fix for 3.0 Stephan

Jan. 24, 2014

Re: [Pharo-dev] [Moose-dev] Re: a problem in latest moose 5.0 image

by Tudor Girba

I am on the run and I do not have time to do it properly via the bug tracker right now, so I am just dumping here what I found after looking into this briefly. In AbstractNautilusUI we have: AbstractNautilusUI>>dropInAPackage: aCollection into: receiver aCollection do:[:aClass | self showGroups ifTrue: [ * receiver addClasses: { aClass }.* * ???I do not quite know when this one happens???.* ActiveHand shiftPressed ifFalse: [ self selectedGroup removeClass: aClass. self updateClassView ]] ifFalse: [ * receiver addClass: aClass theNonMetaClass. * * aClass theNonMetaClass category: receiver name asString.* ActiveHand shiftPressed ifTrue: [ self selectedClass: nil. self updateClassView ] ifFalse:[ self selectedPackage: receiver. self selectedClass: aClass. self updateBothView ]]] The problem seems to be that the red lines work directly with the RPackage, but at the moment the right thing to do is still to go via setting categories and to let the SystemAnnouncer trigger the behavior in RPackage. Cheers, Doru On Fri, Jan 24, 2014 at 2:59 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Retrying with the attachment. > > [image: Inline image 1] > > > On Fri, Jan 24, 2014 at 2:56 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> I also just downloaded the latest Pharo 3.0 (30719), and I took the first >> class AIRootContext from the 'AST-Interpreter-Core' and dragged it to >> 'AST-Core' and the category is not changed. So, the problem comes from >> Pharo. >> >> See the picture attached. >> >> Cheers, >> Doru >> >> [image: Inline image 1] >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> On Fri, Jan 24, 2014 at 2:52 PM, Stephan Eggermont <stephan(a)stack.nl>wrote: >> >>> Followups in the pharo-dev list, please >>> >>> Esteban wrote: >>> >I would really like a reproducible caseâ¦ in the form of an image, if no >>> else. >>> > >>> >btwâ¦ moose 5.0 images are severely broken in that area, so if you are >>> using one of them you *will* have problems. >>> >>> I can deny that it is a Moose problem, I can reproduce it in Pharo 30716 >>> on mac >>> >>> Open the image, open a Nautilus browser >>> Add new package AZ >>> Select AST-Core, Nodes >>> Select RBProgramNode >>> Copy the class with right-click menu >>> Rename to AZProgramNode >>> Enter your name (should have happened when creating the new package!) >>> Drag AZProgramNode to AZ >>> Category is not updated. >>> >>> Stephan >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 24, 2014

Re: [Pharo-dev] Null Object Pattern

by Sean P. DeNigris

On Jan 24, 2014, at 4:57 AM, "Nicolai Hess [via Smalltalk]" <ml-node+s1294792n4738969h27(a)n4.nabble.com> wrote: > Do you know this places where ifNil:ifNotNil: is called? > If so, you coulde change them to ifWorldNil:ifWorldNotNil: > and implement this on World, ActiveWorld, NullWorld and UndefinedObject. If I can't do it effectively with the compiler, that could be a good compromise. Thanks :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Null-Object-Pattern-tp4738574p4739061.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 24, 2014

Re: [Pharo-dev] [Moose-dev] Re: a problem in latest moose 5.0 image

by Tudor Girba

Retrying with the attachment. [image: Inline image 1] On Fri, Jan 24, 2014 at 2:56 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I also just downloaded the latest Pharo 3.0 (30719), and I took the first > class AIRootContext from the 'AST-Interpreter-Core' and dragged it to > 'AST-Core' and the category is not changed. So, the problem comes from > Pharo. > > See the picture attached. > > Cheers, > Doru > > [image: Inline image 1] > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > On Fri, Jan 24, 2014 at 2:52 PM, Stephan Eggermont <stephan(a)stack.nl>wrote: > >> Followups in the pharo-dev list, please >> >> Esteban wrote: >> >I would really like a reproducible caseâ¦ in the form of an image, if no >> else. >> > >> >btwâ¦ moose 5.0 images are severely broken in that area, so if you are >> using one of them you *will* have problems. >> >> I can deny that it is a Moose problem, I can reproduce it in Pharo 30716 >> on mac >> >> Open the image, open a Nautilus browser >> Add new package AZ >> Select AST-Core, Nodes >> Select RBProgramNode >> Copy the class with right-click menu >> Rename to AZProgramNode >> Enter your name (should have happened when creating the new package!) >> Drag AZProgramNode to AZ >> Category is not updated. >> >> Stephan >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 24, 2014

Re: [Pharo-dev] About doing things late (1 month before release)

by Benjamin

On 24 Jan 2014, at 10:53, Marcus Denker <marcus.denker(a)inria.fr> wrote: > What will it help? Who will then decide? Why does that person not help deciding now? Because it requires downloading an image, loading the slices check the diff. If in Lille this can takes few minutes (which is already long), in Chile this is roughly 10 minutes just to have the changes. Ben

Jan. 24, 2014