February 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Metacello issues on Pharo 2.0

by Frank Shearar

On 20 February 2013 19:53, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> Metacello is perfectly well maintained, and runs on a number of >> Smalltalks. > > I do not know. If Dale did not had a look since this summer this is 8 months ago. > I have no problem that this would happen. I just want to know because > we want to build all the validation of packages on top of metacello. > >> It broke on Pharo 2.0 because things changed too quickly, >> too quickly for Dale to keep up. > > Probably. But I do not think so. Well, Dale certainly thought so, because he said so - it was when you replaced FileDirectory with FileSystem. >> What would be vastly more >> constructive than implying that Dale has abandoned Metacello would be >> applying some Pharo effort towards making it work again on 2.0. > > Frank I spent a lot of time pushing Metacello, christophe is working on a tool > so that everybody can produce more easily configuration. I know, and I appreciate that. > Now my question is still valid. I just want to know because my time is counted > and christophe is trying to understand metacello since some time and we should > move forward. Sure, and Metacello's quite a complicated beast. I'm trying to gently suggest out that since it was Pharo's changes that broke Metacello, and Pharo desperately needs to keep it working, that maybe Pharo should apply some of its funded muscle and help Dale. frank > Stef > >> >> frank >> >>> Stef >>> >>> >>> >>> >>> On Feb 15, 2013, at 3:09 PM, Christophe Demarey >>> <Christophe.Demarey(a)inria.fr> wrote: >>> >>> Hi all, >>> >>> I have issues with Metacello on Pharo 2.0 >>> >>> If I load and run tests for the version used in Pharo1.4, it gives: >>> (ConfigurationOfMetacello project version: '1.0-beta.31.1.4') load: 'Tests' >>> >>> <Capture dâÃ©cran 2013-02-15 Ã 14.45.15.png> >>> >>> Metacello packages shipped with Pharo 2.0 are all packages derived from the >>> latest stable Metacello baseline (1.0-beta.31.1.5) except the >>> MetacelloToolBox. >>> If I load and run tests packages with version described in the latest stable >>> Metacello baseline (1.0-beta.31.1.5), i.e. : >>> >>> Metacello-TestsCore-DaleHenrichs.14 and >>> Metacello-TestsMC-dkh.351, >>> >>> it gives (Pharo 2.0 #20547): >>> <Capture dâÃ©cran 2013-02-15 Ã 14.55.36.png> >>> >>> So, it seems there are some problems. Do we use the rigth versions of >>> Metacello packages? >>> >>> Regards, >>> Christophe. >>> >>> >>> >> > >

Feb. 20, 2013

[Pharo-project] spec className?

by StÃ©phane Ducasse

Hi dale I wrote in the book that we do not need to specify the className when the configurationOf has the same name as the project but I experienced a problem that I could not solve by specifying a className Is it something known? Stef Begin forwarded message: > first question: className usage in presence of regular package. > ------------------------------------------------------------------------------------------- > In the following baseline, I do not understand why I'm forced to specify the className because the configuration > is based on the project name. > > > spec project: 'OrderPreservingDictionary' with: [ > spec > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ without className > > versionString: #stable; > loads: #('Core'); > repository: 'http://smalltalkhub.com/mc/Pharo/OrderPreservingDictionary/main']. > > does not work > > while > > spec project: 'OrderPreservingDictionary' with: [ > spec > className: 'ConfigurationOfOrderPreservingDictionary'; > versionString: #stable; > loads: #('Core'); > repository: 'http://smalltalkhub.com/mc/Pharo/OrderPreservingDictionary/main']. > Works > > > baseline200: spec > <version: '2.0.0-baseline'> > > spec for: #common do: [ > spec > blessing: #baseline; > description: 'Migrated to SmalltalkHub and taking into account new configurations of subcomponents'; > repository: 'http://smalltalkhub.com/mc/Pharo/XMLWriter/main'. > > spec project: 'OrderPreservingDictionary' with: [ > spec > className: 'ConfigurationOfOrderPreservingDictionary'; > versionString: #stable; > loads: #('Core'); > repository: 'http://smalltalkhub.com/mc/Pharo/OrderPreservingDictionary/main']. > > spec package: 'XML-Writer' with: [spec requires: 'OrderPreservingDictionary']. > > spec > group: 'default' with: #('Core'); > group: 'Core' with: #('XML-Writer'); > group: 'Tests' with: #() ]. > > > spec for: #squeakCommon do: [ > spec package: 'Collections-Support' with: [ > spec repository: 'http://www.squeaksource.com/Pharo' ] ].

Feb. 20, 2013

Re: [Pharo-project] Metacello issues on Pharo 2.0

by stephane ducasse

> Metacello is perfectly well maintained, and runs on a number of > Smalltalks. I do not know. If Dale did not had a look since this summer this is 8 months ago. I have no problem that this would happen. I just want to know because we want to build all the validation of packages on top of metacello. > It broke on Pharo 2.0 because things changed too quickly, > too quickly for Dale to keep up. Probably. But I do not think so. > What would be vastly more > constructive than implying that Dale has abandoned Metacello would be > applying some Pharo effort towards making it work again on 2.0. Frank I spent a lot of time pushing Metacello, christophe is working on a tool so that everybody can produce more easily configuration. Now my question is still valid. I just want to know because my time is counted and christophe is trying to understand metacello since some time and we should move forward. Stef > > frank > >> Stef >> >> >> >> >> On Feb 15, 2013, at 3:09 PM, Christophe Demarey >> <Christophe.Demarey(a)inria.fr> wrote: >> >> Hi all, >> >> I have issues with Metacello on Pharo 2.0 >> >> If I load and run tests for the version used in Pharo1.4, it gives: >> (ConfigurationOfMetacello project version: '1.0-beta.31.1.4') load: 'Tests' >> >> <Capture dâÃ©cran 2013-02-15 Ã 14.45.15.png> >> >> Metacello packages shipped with Pharo 2.0 are all packages derived from the >> latest stable Metacello baseline (1.0-beta.31.1.5) except the >> MetacelloToolBox. >> If I load and run tests packages with version described in the latest stable >> Metacello baseline (1.0-beta.31.1.5), i.e. : >> >> Metacello-TestsCore-DaleHenrichs.14 and >> Metacello-TestsMC-dkh.351, >> >> it gives (Pharo 2.0 #20547): >> <Capture dâÃ©cran 2013-02-15 Ã 14.55.36.png> >> >> So, it seems there are some problems. Do we use the rigth versions of >> Metacello packages? >> >> Regards, >> Christophe. >> >> >> >

Feb. 20, 2013

Re: [Pharo-project] Weird behavior in Nautilus when doing a method rename

by stephane ducasse

On Feb 20, 2013, at 1:07 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > There is actually no simple way to simply rename a method. > We should maybe add one which keep track of the versions :) sure there is: click on the method in the text pane change the selector of the method and compile. > Historically (even if it sounds wrong today) you create a new method, > and delete the old one (and indeed this is disturbing for new comers ^^) > > I really think that both usage are valid even if I think that most of the time, > you want to do a refactoring while renaming :) > > Let's release Pharo 2.0, and then we will have fun experimenting this ^^ > > Ben

Feb. 20, 2013

Re: [Pharo-project] Weird behavior in Nautilus when doing a method rename

by stephane ducasse

to rename a method without refactoring: just click on the method and in the method pan change its name and recompile Stef On Feb 20, 2013, at 11:25 AM, phil(a)highoctane.be wrote: > Yes, but the rename is *not* in the refactoring menu. It is *below* > the refactoring menu. > So, it is an unexpected refactoring in disguise... > > There was a simple rename in 1.4 I think. Maybe can we get that one > back (in 3.0 of course...) > > Phil > > 2013/2/20 Fernando Olivero <fernando.olivero(a)usi.ch>: >> Hi, i had the same misconception once, but i recall Lukas pointed out >> that the refactoring engine is built on the original refactoring's >> from Fowler's book, and implemented in Smalltalk by Roberts and >> Johnson [1]. >> >> So the semantics of the refactoring are preserved in the implementation. >> >> If you just want a method rename, not a method refactoring rename, >> maybe is best have an option for that in the menu [2]. >> >> >> Fernando >> >> [1] http://st-www.cs.illinois.edu/users/droberts/tapos.pdf >> [2] or use a better widget for editing methods, than a simple code >> editor within the pane of the browser, as in Gaucho..which i'm working >> on. >> >> On Wed, Feb 20, 2013 at 11:03 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> and you are right, scoped browsing is a very powerful feature that can be tricky to newcomers... but at least now with nautilus it is there, as first option (in OB it was there, but more or less hidden in a submenu)... >>> It is a small step, but is something... and well... we can improve in next releases, one step at a time :) >>> >>> Esteban >>> >>> On Feb 20, 2013, at 10:52 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>> >>>> Yes, thanks, I figured that out. A newcomer wouldn't... and renaming >>>> is pretty common. >>>> >>>> What will happen is that people will remove the method and recreate a new one. >>>> Version history will then go away. >>>> >>>> Or is the system smart enough to find out about these things? >>>> >>>> Phil >>>> >>>> 2013/2/20 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>> hi, >>>>> >>>>> yes, you are right.. but that is a "nice to have", not a bug... so it will wait to 3.0 :) >>>>> In the mean time, you can do a scoped rename: you select the packages you want, then right click and "browse scoped", then you apply you rename, and it will apply the refactor in the scoped selection, not all the image. >>>>> >>>>> cheers, >>>>> Esteban >>>>> >>>>> On Feb 20, 2013, at 10:21 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>>> >>>>>> Well, look at the screenshot then tell me that this is what I want. >>>>>> >>>>>> It is definitively *not* what I want. Especially unchecking that >>>>>> endless list of methods. >>>>>> >>>>>> Adding a "Uncheck all" "Check all" button to the Changes Browser list >>>>>> would help... >>>>>> >>>>>> Regards >>>>>> Phil >>>>>> >>>>>> 2013/2/20 Camillo Bruni <camillobruni(a)gmail.com>: >>>>>>> there is 1 certain bug, that is that you cannot see the changes of the refactoring: >>>>>>> >>>>>>> https://code.google.com/p/pharo/issues/detail?id=7547 >>>>>>> >>>>>>> the rest I would consider a bug as well. But in the terms of refactoring it might >>>>>>> be "valid". It does preserve behavior by renaming also all implementors. >>>>>>> >>>>>>> How about this reasoning: >>>>>>> >>>>>>> Rename method >>>>>>> => rename all senders (since you refactor) >>>>>>> => you have to rename all implementors as well since you renamed all send sites >>>>>>> otherwise you'll run for sure into a DNU >>>>>>> >>>>>>> I think I just convinced myself :D >>>>>>> >>>>>>> On 2013-02-20, at 09:26, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>>>>>> I was doing a Refactoring>rename of the initialize method in Nautilus >>>>>>>> for the ClassMethodBrowser and then the changes browser proposed me to >>>>>>>> change all classes with initialize. WTF? >>>>>>>> >>>>>>>> Phil >>>>>>>> >>>>>>> >>>>>>> >>>>>> <PharoScreenshot.3.png> >>>>> >>>>> >>>> >>> >>> >> >

Feb. 20, 2013

Re: [Pharo-project] Continuing weirdness with SS3.gemstone.com and Monticello in Pharo 2.0

by stephane ducasse

are you sure that this is a freeze and not a timeout on the repository? Because the timeout can take some time. Stef On Feb 19, 2013, at 11:27 PM, phil(a)highoctane.be wrote: > Well, that's what you get from having people using some other kind of > workflow that the usual one you gurus use since years; they do click > on some unforseen button combinations. But frozen it was for sure. > > Anyway, cannot send you any image for testing... it was frozen. > > This makes me wonder: isn't there any way to put a kind of non > maskable kind of interrupt key in the VM that would interrupt its > execution for sure? > > I do encounter a tad too many freezes. Some of them my fault but quite > some others not really. I now understand why one would have a process > saving images with an incrementing number endlessly in the background > to avoid just that now. > > I don't even want to think about life before Monticello ... Yikes! > > Phil > > 2013/2/19 Camillo Bruni <camillobruni(a)gmail.com>: >> this is rather strange. >> We're using gemstone for all pharo development and we haven't had any problems with it. >> >> I loaded all the stuff from your test-repository and it worked. >> more details? ;) >> >> On 2013-02-19, at 22:06, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> >>> So, I wanted to merge my stuff from the SS3 project. >>> >>> When loading it needed to have BitBltPen (which I had somewhere as in >>> BitBltPen-MarianoMartinezPeck.4.mcz) >>> >>> I wanted to put that into my SS3 area and so, added the repository to >>> the list of repos in monticello, then took the mcz and then added the >>> repository to the package. >>> >>> Net result: Frozen image. >>> >>> No amount of Cmd-. could do anything. >>> >>> See screenshot. >>> >>> ... now restarting VM... >>> >>> Phil >>> <Capture dâÃ©cran 2013-02-19 Ã 22.01.46.png> >> >> >

Feb. 20, 2013

Re: [Pharo-project] [Issue Tracker][2.0] Down to 5 entries!

by stephane ducasse

this is really great. Thanks esteban to push that hard! And thanks the others to join and push too :) Stef On Feb 20, 2013, at 8:45 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Just 5 issues leftâ¦ > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D2.0 > > >

Feb. 20, 2013

Re: [Pharo-project] Pharo software distribution agreement errata (was "Smalllint for Traits")

by stephane ducasse

On Feb 20, 2013, at 1:00 AM, aizcorbe <juansebastian.aizcorbe(a)gmail.com> wrote: > Ok, is it possible to send a scan of the signed licence? where can i send it? to me or marcus. Stef > where is an updated version of the licence? we should update it. > > Cheers > > > > -- > View this message in context: http://forum.world.st/Smalllint-for-Traits-tp4662559p4670842.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Feb. 20, 2013

Re: [Pharo-project] Smalllint for Traits

by stephane ducasse

On Feb 19, 2013, at 11:22 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Tue, Feb 19, 2013 at 2:46 AM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >> The license page needs an update, "Copyright (c) Pharo Project, and >> Contributors Copyright (c) 1996-2008 " must be "Copyright (c) Pharo Project, >> and Contributors Copyright (c) 1996-2013" ? > > > done > > >> Maybe "The Distribution Agreement" can be updated with the Pharo consortium >> as the distributor? > > > I have no idea. Steph ? yes we should do that. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill

Feb. 20, 2013

Re: [Pharo-project] Metacello issues on Pharo 2.0

by Frank Shearar

On 20 February 2013 18:17, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Hi christophe > > We should clear up this issue. Did you make progress on that front? > The answer of dale are not really giving my hope. > I do not want to base all our infrastructure > on a tool that we do not know if it will be maintained. Metacello is perfectly well maintained, and runs on a number of Smalltalks. It broke on Pharo 2.0 because things changed too quickly, too quickly for Dale to keep up. What would be vastly more constructive than implying that Dale has abandoned Metacello would be applying some Pharo effort towards making it work again on 2.0. frank > Stef > > > > > On Feb 15, 2013, at 3:09 PM, Christophe Demarey > <Christophe.Demarey(a)inria.fr> wrote: > > Hi all, > > I have issues with Metacello on Pharo 2.0 > > If I load and run tests for the version used in Pharo1.4, it gives: > (ConfigurationOfMetacello project version: '1.0-beta.31.1.4') load: 'Tests' > > <Capture dâÃ©cran 2013-02-15 Ã 14.45.15.png> > > Metacello packages shipped with Pharo 2.0 are all packages derived from the > latest stable Metacello baseline (1.0-beta.31.1.5) except the > MetacelloToolBox. > If I load and run tests packages with version described in the latest stable > Metacello baseline (1.0-beta.31.1.5), i.e. : > > Metacello-TestsCore-DaleHenrichs.14 and > Metacello-TestsMC-dkh.351, > > it gives (Pharo 2.0 #20547): > <Capture dâÃ©cran 2013-02-15 Ã 14.55.36.png> > > So, it seems there are some problems. Do we use the rigth versions of > Metacello packages? > > Regards, > Christophe. > > >

Feb. 20, 2013