- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo CI Validation Timeout

by Marcus Denker

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> 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] Removing name from Object

by Nicolai Hess

How can we find out, which external projects depend on this? 2015-09-02 7:06 GMT+02:00 H. Hirzel <hannes.hirzel(a)gmail.com>: > On 9/1/15, stepharo <stepharo(a)free.fr> wrote: > > Hi guys > > > > I would love to see name removed from Object. It brings more problems > > than anything else. > > Any taker? > > > > Stef > > > > > > > > Hi Stef > > About > > Object>> > name > "Answer a name for the receiver. This is used generically in the > title of certain inspectors, such as the referred-to inspector, and > specificially by various subsystems. By default, we let the object > just print itself out.. " > > ^ self printString > > > Are you refering to this > > http://comments.gmane.org/gmane.comp.lang.smalltalk.pharo.user/21476? > > Which other kinds of problems do you see with this method? > > Could you elaborate a bit please why you want to remove Object>>name? > > Regards > > Hannes > >

Sept. 2, 2015

Re: [Pharo-dev] Pharo CI Validation Timeout

by Nicolai Hess

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>: > > On 01 Sep 2015, at 19:15, Ben Coman <btc(a)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 > > 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 > > 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] [Experiment] Automatic rewriting of sends to deprecated methods

by stepharo

May be in that can we should have a deprecated: andTransform: message Now the question is when do you build a rule. We should discuss with gustavo and his macro recorder. Stef > > 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 > *and* with the gurantee that it is correct. There are no false > positives as we only transform when the deprecated > method is called. It's a "perfect" transformation, but of course only > for non-dead code. > > Marcus >

Sept. 2, 2015

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

by Marcus Denker

> 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 *and* with the gurantee that it is correct. There are no false positives as we only transform when the deprecated method is called. It's a "perfect" transformation, but of course only for non-dead code. Marcus

Sept. 2, 2015

Re: [Pharo-dev] Pharo CI Validation Timeout

by Marcus Denker

> On 01 Sep 2015, at 19:15, Ben Coman <btc(a)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 > > 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] Removing name from Object

by H. Hirzel

On 9/1/15, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > I would love to see name removed from Object. It brings more problems > than anything else. > Any taker? > > Stef > > Hi Stef About Object>> name "Answer a name for the receiver. This is used generically in the title of certain inspectors, such as the referred-to inspector, and specificially by various subsystems. By default, we let the object just print itself out.. " ^ self printString Are you refering to this http://comments.gmane.org/gmane.comp.lang.smalltalk.pharo.user/21476? Which other kinds of problems do you see with this method? Could you elaborate a bit please why you want to remove Object>>name? Regards Hannes

Sept. 2, 2015

Re: [Pharo-dev] ensure: and assignments RB Rule

by Eliot Miranda

On Tue, Sep 1, 2015 at 1:29 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > Thank you all for your response, > now the interesting question is, what should this rule recommend to use > instead? First assign to a block local variable and > add a nil check in the unwind block? > No. I think the pattern modifies this: | t | ... [t := initExpr. exprs] ensure: [t msg] to this | t | ... t := initExpr. [exprs] ensure: [t msg] Control never reaches the block [exprs] isf there is an error in initExpr so there's no issue with t being unassigned; control won't get to the ensure block, so no need to test for nil. > And maybe we should improve that rule, because in Pharo 5.0 there are 5 > methods catched by > this rule: > 3 have an explicit ifnonil check before accessing the variable - their > implementation actually behaves correctly. > The other two are just "testdata" used in the unit test for this rule > > > > 2015-08-31 15:30 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> If there's an error in the expression that is assigned to file, and the >> stack unwound, file won't have been assigned and the close will get sent to >> nil. The assignment to file should precede the block. >> >> Sent from my iPhone >> >> On Aug 31, 2015, at 5:03 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >> Anyone? We may remove this rule if no one understands for what this is >> good for. >> (if anyone knows, please comment that class). >> >> >> >> 2014-12-14 11:22 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: >> >>> >>> 2014-11-30 20:54 GMT+01:00 stepharo <stepharo(a)free.fr>: >>>> >>>> thanks we should open a bug entry to improve the class comment of this >>>> rule. >>>> Any taker? >>>> >>>> Stef >>>> >>>> Le 30/11/14 12:10, Thierry Goubier a Ã©crit : >>> >>> >>> done >>> 14618 <https://pharo.fogbugz.com/default.asp?14618> >>> Add a comment describing RBFileBlocksRule >>> >>> now I just need to have a good description for this rule. Please, can >>> someone outline the discussion on this thread: >>> - describe why code matching this rule is considered back practice >>> - describe how the code could be rewritten. >>> >>> nicolai >>> >>> >>> >>>> >>>> Le 30/11/2014 12:01, Max Leske a Ã©crit : >>>>> >>>>>> >>>>>> On 30.11.2014, at 11:18, Thierry Goubier <thierry.goubier(a)gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> Le 30/11/2014 11:06, Max Leske a Ã©crit : >>>>>>> >>>>>>>> The code would look like this: >>>>>>>> >>>>>>>> [ | file | >>>>>>>> file := StandardFileStream forceNewFileNamed: âfooâ. >>>>>>>> file nextPutAll: âbarâ ] >>>>>>>> ensure: [ file close ]. >>>>>>>> >>>>>>>> Why that is considered bad practice however, I canât tell. >>>>>>>> >>>>>>> >>>>>>> This one would fail because file is a temp to the block (and not >>>>>>> visible to the ensure block). >>>>>>> >>>>>> >>>>>> If it werenât visible, wouldnât the compiler raise an exception? >>>>>> >>>>> >>>>> In your example, yes. >>>>> >>>>> But the rule matched: >>>>> >>>>> | file | >>>>> [ >>>>> file := StandardFileStream forceNewFileNamed: âfooâ. >>>>> file nextPutAll: âbarâ ] >>>>> ensure: [ file close ]. >>>>> >>>>> (Hum: wouldn't the compiler complain of file might be nil in the >>>>> ensure block?) >>>>> >>>>> Another problem is that, if you have a failure in forceNewFileNamed:, >>>>>>> file is nil and the ensure: fail as well. >>>>>>> >>>>>> >>>>>> True, but thatâs a problem this rule doesnât really cover I guess. >>>>>> That oneâs up to the developer. >>>>>> >>>>> >>>>> I would expect that rule to flag bad coding practices, and I think it >>>>> does ;) >>>>> >>>>> Thierry >>>>> >>>>> >>>>> >>>> >>>> >> > -- _,,,^..^,,,_ best, Eliot

Sept. 2, 2015

Re: [Pharo-dev] Removing name from Object

by Ferlicot D. Cyril

Le 01/09/2015 21:44, stepharo a Ã©crit : > Hi guys > > I would love to see name removed from Object. It brings more problems > than anything else. > Any taker? > > Stef > That would be cool ! Sometimes I really needed a method "name" and that was really boring to have to think again and again to find another name for the methodâ¦ -- Cheers Cyril

Sept. 1, 2015

Re: [Pharo-dev] ensure: and assignments RB Rule

by Nicolai Hess

Thank you all for your response, now the interesting question is, what should this rule recommend to use instead? First assign to a block local variable and add a nil check in the unwind block? And maybe we should improve that rule, because in Pharo 5.0 there are 5 methods catched by this rule: 3 have an explicit ifnonil check before accessing the variable - their implementation actually behaves correctly. The other two are just "testdata" used in the unit test for this rule 2015-08-31 15:30 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > If there's an error in the expression that is assigned to file, and the > stack unwound, file won't have been assigned and the close will get sent to > nil. The assignment to file should precede the block. > > Sent from my iPhone > > On Aug 31, 2015, at 5:03 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Anyone? We may remove this rule if no one understands for what this is > good for. > (if anyone knows, please comment that class). > > > > 2014-12-14 11:22 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > >> >> 2014-11-30 20:54 GMT+01:00 stepharo <stepharo(a)free.fr>: >>> >>> thanks we should open a bug entry to improve the class comment of this >>> rule. >>> Any taker? >>> >>> Stef >>> >>> Le 30/11/14 12:10, Thierry Goubier a Ã©crit : >> >> >> done >> 14618 <https://pharo.fogbugz.com/default.asp?14618> >> Add a comment describing RBFileBlocksRule >> >> now I just need to have a good description for this rule. Please, can >> someone outline the discussion on this thread: >> - describe why code matching this rule is considered back practice >> - describe how the code could be rewritten. >> >> nicolai >> >> >> >>> >>> Le 30/11/2014 12:01, Max Leske a Ã©crit : >>>> >>>>> >>>>> On 30.11.2014, at 11:18, Thierry Goubier <thierry.goubier(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>> Le 30/11/2014 11:06, Max Leske a Ã©crit : >>>>>> >>>>>>> The code would look like this: >>>>>>> >>>>>>> [ | file | >>>>>>> file := StandardFileStream forceNewFileNamed: âfooâ. >>>>>>> file nextPutAll: âbarâ ] >>>>>>> ensure: [ file close ]. >>>>>>> >>>>>>> Why that is considered bad practice however, I canât tell. >>>>>>> >>>>>> >>>>>> This one would fail because file is a temp to the block (and not >>>>>> visible to the ensure block). >>>>>> >>>>> >>>>> If it werenât visible, wouldnât the compiler raise an exception? >>>>> >>>> >>>> In your example, yes. >>>> >>>> But the rule matched: >>>> >>>> | file | >>>> [ >>>> file := StandardFileStream forceNewFileNamed: âfooâ. >>>> file nextPutAll: âbarâ ] >>>> ensure: [ file close ]. >>>> >>>> (Hum: wouldn't the compiler complain of file might be nil in the ensure >>>> block?) >>>> >>>> Another problem is that, if you have a failure in forceNewFileNamed:, >>>>>> file is nil and the ensure: fail as well. >>>>>> >>>>> >>>>> True, but thatâs a problem this rule doesnât really cover I guess. >>>>> That oneâs up to the developer. >>>>> >>>> >>>> I would expect that rule to flag bad coding practices, and I think it >>>> does ;) >>>> >>>> Thierry >>>> >>>> >>>> >>> >>> >

Sept. 1, 2015