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

[Pharo-project] getting rid of these boring questions and popup

by StÃ©phane Ducasse

Hi guys I would like what you think of these wonderful popups that try to help to write cool code but just get in my way: "this variable is not used.... you did not store into it.... Could we agree that we are adults? and this is more a pain than anything else? Stef

Sept. 11, 2009

Re: [Pharo-project] New Pharo based on core 10446

by StÃ©phane Ducasse

cool thanks! On Sep 11, 2009, at 4:44 PM, Damien Cassou wrote: > http://pharo-project.org/pharo-download > > with refactorings in the package browser. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > 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] New Pharo based on core 10446

by Damien Cassou

http://pharo-project.org/pharo-download with refactorings in the package browser. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Sept. 11, 2009

Re: [Pharo-project] BrowserEnvironment is broken?

by Henrik Johansen

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 > > >

Sept. 11, 2009

[Pharo-project] [update] #10446

by StÃ©phane Ducasse

10446 ----- ar 315 UIManagerization. Replaces all the trivial references to PopUpMenu, SelectionMenu, CustomMenu, and FillInTheBlank. ar 314 Add a revert item to the patches menu so that local changes can be reverted after diffing to a repository. Useful to weed out intermediate changes that turn out to have no impact after all. bf 316 - sort class vars and pools (merging Eliot s and my fixes) bf 317 - deal with nil user/password in MCHttpRepository - bf 318 - store and read preambles/postscripts in textual source, too - show preambles/postscripts when browsing a snapshot rkrk 319 Making shortcuts work in the MCPatchBrowser tfel.320 Adapt a test-case to reality - In the MCSnapshotBrowser, when we have abolutely nothing selected, we don t want to see an empty string, instead we see the packages scripts or, in the testcase, the info that this package doesn t define any scripts

Sept. 11, 2009

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

by Lukas Renggli

> 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. > Â Â Â Â - 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? Class definitions are part of the patch that is calculated by Monticello. My guess is that the class didn't change for the delta you calculated. 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. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 11, 2009

Re: [Pharo-project] Getting Pharo 1.0 released

by Vicnet

> > 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? Oopps ! I download 40440 but was using 40118 !! Sorry. Is there anything else missing ? a+ Vicnet -- View this message in context: http://n2.nabble.com/Getting-Pharo-1-0-released-tp3578354p3625266.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 11, 2009

Re: [Pharo-project] Getting Pharo 1.0 released

by Oscar Nierstrasz

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?

Sept. 11, 2009

Re: [Pharo-project] Getting Pharo 1.0 released

by StÃ©phane Ducasse

On Sep 11, 2009, at 12:21 PM, Vicnet wrote: > > Hello, > > >>> 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? > I suppose that image will be build on official 1.0 so it is not ready. It will be the same as the dev + demoAndSample from the PharoMoprhic folder > > What should import on actual image (10440) to be able to do example ? > I found PharoMorphicExtra on Pharo wiki that seems to be ok for PBE > (except > some linked lib) ? > Is there anything else ? > > Thanks for PBE. > > a+ > Vicnet > > -- > View this message in context: http://n2.nabble.com/Getting-Pharo-1-0-released-tp3578354p3624877.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > 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] May be some problems with MC history

by StÃ©phane Ducasse

a couple of bugs when understanding the history based merge (ugly) - 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! This functionality by passes the changeset and this is not a good idea. Stef On Sep 11, 2009, at 11:56 AM, StÃ©phane Ducasse wrote: > thanks lukas > > in general you did not get any problems? > Beause I was careful and the changes seemed simple except the last one > The result is that apparently I lost classes that were not in the > changes! > and instance variables. > > I'm now comparing with the squeak trunk image to see if this is an MC > problem > because this is the first time I got that strange behavior. > > Stef > > On Sep 11, 2009, at 9:09 AM, Lukas Renggli wrote: > >>> Does any (lukas) use the history feature to merge? >> >> Sometimes, if I would like to merge changes made in another branch. >> Imagine the following situation: >> >> a.1 ---- wc (working copy) >> \---- b.1 --- b.2 >> >> Now I want to include the changes that happened between b.2 and b.3, >> but not those that were done between a.1 and b.1. I use the history >> and to calculate a diff between b.1 and b.2 and selectively load the >> changes. If the changes are separate from what happened between a.1 >> and wc and a.1 and b.1 this should be relatively simple. >> Unfortunately >> Monticello cannot figure out such dependencies, because it keeps the >> ancestry on a package level only. In fact, with Monticello 2 an >> operation like this should be smooth and automatic like a normal >> merge. >> >>> I will retry to do the changes one by one and run the tests in >>> between >>> to see what went wrong >>> but I 'm not sure that what is going wrong is the changes (I have >>> the >>> impression that may be MC history is not capturing >>> exactly everything but I can be wrong). >> >> MC1 does not capture the ancestry of the individual methods, that's >> why you have to extremely careful and check if you do not override >> changes that were made between a.1 and wc and if you do not introduce >> changes made between a.1 and b.1. I know this can be very tricky, >> especially when there are many changes between a.1 and wc and a.1 and >> b.1. MC2 promises rescue here. >> >> Lukas >> >> -- >> 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

Sept. 11, 2009