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

Re: [Pharo-dev] Removing name from Object

by Sean P. DeNigris

EstebanLM wrote > deprecate it like any other method change or removal? (And then remove it > in Pharo 6) > > +1 > thatâs the way to do it :) +1. I'm glad we're finally getting around to this :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Removing-name-from-Object-tp4847514p4847641.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 2, 2015

Re: [Pharo-dev] Removing name from Object

by Sean P. DeNigris

Hannes Hirzel wrote > Which other kinds of problems do you see with this method? > Could you elaborate a bit please why you want to remove Object>>name? Off the top of my head, in the worst case implementing #name on the class-side can be fatal. Less seriously one can get confusing result if e.g. you create a #name instVar and expect something to fail because you haven't created the getter yet, but instead it surprises you by using the unkown default implementation. At minimum, it creates confusion by using an overly generic name deep in the system. There should be as few reserved words like #class as possible, and only with very good reason, as it makes the system harder to understand. For more info, see: http://forum.world.st/name-tt3739677.html http://forum.world.st/name-selector-tt4760402.html ----- Cheers, Sean -- View this message in context: http://forum.world.st/Removing-name-from-Object-tp4847514p4847640.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 2, 2015

Re: [Pharo-dev] [Experiment] Automatic rewriting of sends to deprecated methods

by Ben Coman

On Wed, Sep 2, 2015 at 2:13 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >>>> Imagine, this is a functionality (I think) no other system has! >> >> >> Yes but we should make it pluggable. >> > Yes! > >> >> I would like something that says >> before all the tests were green and after these automatic changes >> they are also green :) > > > Exactly, that's what I implemented: you run the tests and all code covered > will be transformed automaticallly Ahh. I thought you were thinking of doing it in normally executing code. Doing it while running tests makes more sense. It only occurs on a specific user action. If you start with clean packages, all changes can be reviewed. cheers -ben

Sept. 2, 2015

Broken GTSpotter in #50298

by Peter UhnÃ¡k

Hi, is Spotter working for you in latest Pharo? (#50298) I downloaded fresh image and its dying on not understanding #canUnderstand: Peter

Sept. 2, 2015

Re: [Pharo-dev] Pharo CI Validation Timeout

by Marcus Denker

I have the feeling that is is an artefact of the virtualisation somehow. > On 02 Sep 2015, at 10:24, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > I saw also that one of the linux slaves is much much slower than the others. Just check this: > > https://ci.inria.fr/pharo/job/30-Bootstrap/buildTimeTrend <https://ci.inria.fr/pharo/job/30-Bootstrap/buildTimeTrend> > > In one of the slaves the build takes one hour. In the other it takes 6. > > El miÃ©., 2 de sept. de 2015 a la(s) 9:11 a. m., Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> escribiÃ³: > I donât think soâ¦ the job used to run in 15 minutes. But we added more tests, > Rules got slowerâ¦ > >> On 02 Sep 2015, at 08:34, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >> >> It is possible to see from the console output which rule or test takes a lot time? >> >> 2015-09-02 8:09 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: >> >>> On 01 Sep 2015, at 19:15, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>> >>> Do you want to try a post-load... >>> Delay delaySchedulerClass: DelayExperimentalSemaphoreScheduler >>> >>> which fixes the "super fast delay" on virtual machines reported here... >>> http://comments.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/100873 <http://comments.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/100873> >>> >>> Its named "experimental" only since it was integrated just before >>> Pharo 4 release and did not have wide spread community testing, but >>> its complete and working. There is some further overall streamlining >>> of the DelayScheduler hierarchy I'd like to do later, but it would be >>> good to give this one a run as the default for a while to see how it >>> impacts the issue. (It would be good to get rough "CIAndRule: Timeout" >>> before and after statistics.) >>> >>> btw, is that CI error indicating it times out after one hour? Are >>> there any other timestamps present in the log that indicate if 1 hour >>> really passed? >>> >> >> Yes, I think soâ¦ >> >> https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/buildTimeTrend <https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/buildTimeTrend> >> >> Now looking at it (no idea why it is chinese), it seems that we have some >> slowdown recently and all runs take 40-50 minutes, a slowdown to 60 can happen >> just by having less compute power available (or running multiple things in parallel). >> >> We should >> >> -> do a pass over slow tests >> -> do a pass over slow rules >> >> I will put the limit higher than 60 min for now. >> >> Marcus >> >> >> >

Sept. 2, 2015

Re: [Pharo-dev] Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp

by Sven Van Caekenberghe

But Timestamp was already removed completely from 4.0, why re-add it, even deprecated ? I am sure many external packages are already modified, I know I did it for mine. > On 02 Sep 2015, at 13:19, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 02 Sep 2015, at 12:32, stepharo <stepharo(a)free.fr> wrote: >> >> Hi guille >> >> there is not stress. I just wanted to let you know. >> I was wondering if just subclassing DateAndTime would not be enough for now. > > Yes, as far as I remember Timestamp was just an empy subclass. > > We could: > > -> add it back to Deprecated50 or maybe even to a âCompatibilityâ package > -> Write a Quality Check rule. > >> I will go back to code with Pharo 40 >> >> stef >> >> Le 2/9/15 10:30, Guillermo Polito a Ã©crit : >>> If somebody can check it and fix it it would be good :). I've just started my new job and my evenings are busy looking for an apartment or staying in a hostel without a proper internet connection... >>> >>> If not, I think we can wait a bit. The first step should be enabling CI jobs for pharo5. Also, I do not think the intersection between 'people using garage opendbx' and 'people using pharo5' is that big to justify a rush. >>> >>> Guille >>> >>> El miÃ©., 2 de sept. de 2015 a la(s) 10:12 a. m., stepharo <stepharo(a)free.fr> escribiÃ³: >>> for your info... >>> >>> Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp >>> >>> Stef >>> >> >

Sept. 2, 2015

Re: [Pharo-dev] Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp

by stepharo

Yes!!!! marcus it would be a good idea. Stef Le 2/9/15 13:19, Marcus Denker a Ã©crit : > >> On 02 Sep 2015, at 12:32, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> Hi guille >> >> there is not stress. I just wanted to let you know. >> I was wondering if just subclassing DateAndTime would not be enough >> for now. > > Yes, as far as I remember Timestamp was just an empy subclass. > > We could: > > -> add it back to Deprecated50 or maybe even to a âCompatibilityâ package > -> Write a Quality Check rule. > >> I will go back to code with Pharo 40 >> >> stef >> >> Le 2/9/15 10:30, Guillermo Polito a Ã©crit : >>> If somebody can check it and fix it it would be good :). I've just >>> started my new job and my evenings are busy looking for an apartment >>> or staying in a hostel without a proper internet connection... >>> >>> If not, I think we can wait a bit. The first step should be enabling >>> CI jobs for pharo5. Also, I do not think the intersection between >>> 'people using garage opendbx' and 'people using pharo5' is that big >>> to justify a rush. >>> >>> Guille >>> >>> El miÃ©., 2 de sept. de 2015 a la(s) 10:12 a. m., stepharo >>> <stepharo(a)free.fr <mailto:stepharo@free.fr>> escribiÃ³: >>> >>> for your info... >>> >>> Garage-OpenDBX does not load on Pharo 50 because it uses >>> Timestamp >>> >>> Stef >>> >> >

Sept. 2, 2015

Re: [Pharo-dev] Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp

by Marcus Denker

> On 02 Sep 2015, at 12:32, stepharo <stepharo(a)free.fr> wrote: > > Hi guille > > there is not stress. I just wanted to let you know. > I was wondering if just subclassing DateAndTime would not be enough for now. Yes, as far as I remember Timestamp was just an empy subclass. We could: -> add it back to Deprecated50 or maybe even to a âCompatibilityâ package -> Write a Quality Check rule. > I will go back to code with Pharo 40 > > stef > > Le 2/9/15 10:30, Guillermo Polito a Ã©crit : >> If somebody can check it and fix it it would be good :). I've just started my new job and my evenings are busy looking for an apartment or staying in a hostel without a proper internet connection... >> >> If not, I think we can wait a bit. The first step should be enabling CI jobs for pharo5. Also, I do not think the intersection between 'people using garage opendbx' and 'people using pharo5' is that big to justify a rush. >> >> Guille >> >> El miÃ©., 2 de sept. de 2015 a la(s) 10:12 a. m., stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> escribiÃ³: >> for your info... >> >> Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp >> >> Stef >> >

Sept. 2, 2015

Re: [Pharo-dev] widgetDo: vs ifWidget:

by Peter UhnÃ¡k

In that case I rest my case and I will stick with #widgetDo: :) Not even the naming. I would say. lot of code in spec should be rewritten. > The holder should be most of the time directly exposed to reduce the API. I know; it is moving, albeit slowly. Thanks, Peter

Sept. 2, 2015

Re: [Pharo-dev] Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp

by stepharo

Hi guille there is not stress. I just wanted to let you know. I was wondering if just subclassing DateAndTime would not be enough for now. I will go back to code with Pharo 40 stef Le 2/9/15 10:30, Guillermo Polito a Ã©crit : > If somebody can check it and fix it it would be good :). I've just > started my new job and my evenings are busy looking for an apartment > or staying in a hostel without a proper internet connection... > > If not, I think we can wait a bit. The first step should be enabling > CI jobs for pharo5. Also, I do not think the intersection between > 'people using garage opendbx' and 'people using pharo5' is that big to > justify a rush. > > Guille > > El miÃ©., 2 de sept. de 2015 a la(s) 10:12 a. m., stepharo > <stepharo(a)free.fr <mailto:stepharo@free.fr>> escribiÃ³: > > for your info... > > Garage-OpenDBX does not load on Pharo 50 because it uses > Timestamp > > Stef >

Sept. 2, 2015