September 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] May be some problems with MC history

by StÃ©phane Ducasse

>> a couple of bugs when understanding the history based merge (ugly) > > It is not a merge operation, as I said in my mail. You are merely > applying the changes representing a delta between two versions > manually. That's all, no magic involved. Yes I know, I did not mean merging. Sorry for the bad working, >> - adding the new method to a cs does not work if you did not >> install >> the code before (ok) >> - class definition are not added (yeah) in the changeset. >> Really cool! > > I don't understand what this has to do with change-sets? there is a menu item: 'add to changeset' and I wanted to generate a cs for each of the commit because I wanted to be able to reload the work in another image to test. And not load and fuck up and restart kind of scenario. > Class definitions are part of the patch that is calculated by > Monticello. probably but when you use add to changesets they don't. > My guess is that the class didn't change for the delta you > calculated. Yes this is what I discovered see below. Now I really understand the limits of the functionality. > To illustrate, in the example above the changes between > b.1 and b.2 don't show a class change that happened between a.1 and > b.1, even if the delta depends on it. > > I use what I described all the time, it is maybe a bit tricky, but > works really well. I wanted to know if I can trust this functionality. So I did the following experiment and I learned a lot and now I deeply understanding what you mean :) I took latest pharo ScriptLoader new addExtraRepositories then you open the trunk repository and browse the monticello package I checked the changes made in ar 321, did not see an instance variable called methodAdditions nor the initialize method modification. The previous version of initialize was made in 2007. I compare the history between md.308 july 2006 and rkrk.320 there I saw that the initialize methods was added. I added the 3.10 repository and I found that the method initialize was added in rej.309 in 310. So now I understand and it would be nice to have a functionality to now when a change occurred. So now I can use the history and yes we should really be cautious. I wrote these emails so that other people can learn from it. So thanks lukas. Stef PS: L'idee de l'experience ne remplace pas l'experience So I'm happy I know more now :)

Sept. 11, 2009

[Pharo-project] Pavel? ChangeSorter vs ChangesOrganizer

by StÃ©phane Ducasse

Hi Pavel I have the impression that MCPackageLoader>>useChangeSetNamed: baseName during: aBlock "Use the named change set, or create one with the given name." | changeHolder oldChanges newChanges | changeHolder := (ChangeSet respondsTo: #newChanges:) ifTrue: [ChangeSet] ifFalse: [Smalltalk]. oldChanges := (ChangeSet respondsTo: #current) ifTrue: [ChangeSet current] ifFalse: [Smalltalk changes]. newChanges := (ChangeSorter changeSetNamed: baseName) ifNil: [ ChangeSet new name: baseName ]. changeHolder newChanges: newChanges. [aBlock value] ensure: [changeHolder newChanges: oldChanges]. should use Changes MCPackageLoader>>useChangeSetNamed: baseName during: aBlock "Use the named change set, or create one with the given name." | changeHolder oldChanges newChanges | changeHolder := (ChangeSet respondsTo: #newChanges:) ifTrue: [ChangeSet] ifFalse: [Smalltalk]. oldChanges := (ChangeSet respondsTo: #current) ifTrue: [ChangeSet current] ifFalse: [Smalltalk changes]. newChanges := (ChangesOrganizer changeSetNamed: baseName) ifNil: [ ChangeSet new name: baseName ]. changeHolder newChanges: newChanges. [aBlock value] ensure: [changeHolder newChanges: oldChanges]. It would be coherent not to really on UI (changeSorter) but on the domain objects (changeOrganizer). http://bugs.squeak.org/view.php?id= 4825 Stef

Sept. 11, 2009

[Pharo-project] An important infrastructural question

by StÃ©phane Ducasse

HI guys With simon we restarted to code on the new package to substitute packageInfo. Now we have a nice package class which works well (one little bug to fix) and a lot of cool tests. I believe that this was the easy part now we will have to think how to have a migration path and about the possible options. We want your feedback on the following points. Currently PackageOrganizer is not really used or half way and the responsibility are split with packageinfo ending in the kind of mess. We suggest to either use it as a factory and package registry or to remove it. The package manager class (either packageOrganizer or Package class side) should really be responsible to create, query, manage package and emit event. Since packageOrganizer is not really used may be this is easier to move its behavior to PackageInfo (and later Package) class side. events? we think that PackageOrganizer/Package should emit events so that other tools can register. Now the question is how this interact with systemNotification mutating from PackageInfo we could write a script that convert all package info (BTW full of crap) into our package: the question is then what to do with the code that we will load later and relied on * - idea: we keep the * notation but we hook into the tools to create real package. In particular the user could either explicitly add a method extension to a package or use the* notation. The end result should be the star notation in the cat and the use of a real package in the background. - fileout (MC). Similarly we could get rid of the convention at the cat level when fileouting a package. It would work at the package level but fileouting a class would break since the markers would be lost. Also porting code to Squeak or other MC based platform could be a problem. So lukas do you if VW uses the * convention, I imagine at least when saving code? So let us know what you think. Stef

Sept. 11, 2009

Re: [Pharo-project] icons in pluggablelistmorph

by StÃ©phane Ducasse

doru do you also need to do what lukas suggested with the tree of alain? Is there a reason not to use it? Stef On Sep 11, 2009, at 8:13 PM, Tudor Girba wrote: > Hi, > > I would like to specify an icon in a PluggableListMorph, but I cannot > find my way :). Can anyone tell me how to do it? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of > problem understanding." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 11, 2009

Re: [Pharo-project] BrowserEnvironment is broken?

by StÃ©phane Ducasse

If I would be red each time I do a mistake.... Stef On Sep 11, 2009, at 8:16 PM, Oscar Nierstrasz wrote: > > Boy, is my face red now! > > Thanks!!! This was driving me crazy. > > - on > > On Sep 11, 2009, at 15:51, Henrik Johansen wrote: > >> Remove your first cascade, and it works. >> I'm not sure how it worked back in July, but now selectMethods: >> doesn't >> modify the current environment, it return a new Environment on the >> methods. >> So your code is telling the Browser with the class as env to set its >> label and open, not the Browser with the methods as env. >> >> ((BrowserEnvironment new forClasses: (Boolean withAllSubclasses)) >> selectMethods: [:method | method sendsToSuper ]) >> label: 'super sends'; >> open. >> works like you expect. >> >> Cheers, >> Henry >> >> >> Oscar Nierstrasz skrev: >>> Hi Folks, >>> >>> In the latest pharo-web image (pharo1.0-10440-BETAweb09.09.1), the >>> BrowserEnvironment is acting strangely: >>> >>> (BrowserEnvironment new forClasses: (Boolean withAllSubclasses)) >>> selectMethods: [:method | method sendsToSuper ]; >>> label: 'super sends'; >>> open. >>> >>> This lists a whole bunch of methods that do *not* send super, >>> including Boolean>>#&. >>> >>> If I check: >>> >>> (Boolean>>#&) sendsToSuper --> false >>> >>> So what is wrong? This worked ok back at the beginning of July ... >>> >>> - on >>> >>> >>> _______________________________________________ >>> 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

Sept. 11, 2009

Re: [Pharo-project] icons in pluggablelistmorph

by Lukas Renggli

> I would like to specify an icon in a PluggableListMorph, but I cannot > find my way :). Can anyone tell me how to do it? You need to create a subclass of PluggableListMorph and LazyListMorph, override #listMorphClass in the PluggableListMorph to return the lazy morph class, and override the method #display:atRow:on: in the LazyListMorph subclass to customize the low-level drawing of the list item. As you imagined all pretty simple and strait-forward, have a look at the OB-Morphic for an example :-) Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 11, 2009

Re: [Pharo-project] icons in pluggablelistmorph

by Alexandre Bergel

Maybe you can have a look at how OB does. By overriding the OBNode>>icon, an icon appears on left to the item name. Cheers, Alexandre On 11 Sep 2009, at 14:13, Tudor Girba wrote: > Hi, > > I would like to specify an icon in a PluggableListMorph, but I cannot > find my way :). Can anyone tell me how to do it? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of > problem understanding." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 11, 2009

Re: [Pharo-project] BrowserEnvironment is broken?

by Oscar Nierstrasz

Boy, is my face red now! Thanks!!! This was driving me crazy. - on On Sep 11, 2009, at 15:51, Henrik Johansen wrote: > Remove your first cascade, and it works. > I'm not sure how it worked back in July, but now selectMethods: > doesn't > modify the current environment, it return a new Environment on the > methods. > So your code is telling the Browser with the class as env to set its > label and open, not the Browser with the methods as env. > > ((BrowserEnvironment new forClasses: (Boolean withAllSubclasses)) > selectMethods: [:method | method sendsToSuper ]) > label: 'super sends'; > open. > works like you expect. > > Cheers, > Henry > > > Oscar Nierstrasz skrev: >> Hi Folks, >> >> In the latest pharo-web image (pharo1.0-10440-BETAweb09.09.1), the >> BrowserEnvironment is acting strangely: >> >> (BrowserEnvironment new forClasses: (Boolean withAllSubclasses)) >> selectMethods: [:method | method sendsToSuper ]; >> label: 'super sends'; >> open. >> >> This lists a whole bunch of methods that do *not* send super, >> including Boolean>>#&. >> >> If I check: >> >> (Boolean>>#&) sendsToSuper --> false >> >> So what is wrong? This worked ok back at the beginning of July ... >> >> - on >> >> >> _______________________________________________ >> 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

Sept. 11, 2009

[Pharo-project] icons in pluggablelistmorph

by Tudor Girba

Hi, I would like to specify an icon in a PluggableListMorph, but I cannot find my way :). Can anyone tell me how to do it? Cheers, Doru -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

Sept. 11, 2009

Re: [Pharo-project] Getting Pharo 1.0 released

by StÃ©phane Ducasse

Yes we should ask damien to add the demosAndSampleMorph package in the script. + Sound also. Stef On Sep 11, 2009, at 12:32 PM, Oscar Nierstrasz wrote: > > SimpleSwitchMorph is in the latest pharo-web at least, but both > BouncingAtomsMorph and StarMorph are missing. > > - on > > > On Sep 11, 2009, at 12:28, StÃ©phane Ducasse wrote: > >>>>> Is "Pharo by Example" done ? >>>> Yes :) >>> >>> I don't find PBE.image and actual image is not ok (SimpleSwitchMorph >>> does't >>> exist). >> >> >> in the latest one you do not have SimpleSwitchMorph? > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 11, 2009