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

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

Re: [Pharo-dev] Versionner and BaselineOf

by stepharo

continue to push the bootstrap please please Le 1/9/15 14:36, Christophe Demarey a Ã©crit : > Le 25 aoÃ»t 2015 Ã 04:10, Sean P. DeNigris a Ã©crit : > >> For projects developed with git, BaselineOfXyzs replace ConfigurationOfXyzs. >> What are the plans to update Versionner for this development? I've gotten >> spoiled and I'm not enjoying writing BaselineOfs by hand! :/ > You're right. It would be good to have support for that. > BaselineOfs are far easier to work with that ConfigurationOfs but a cool UI would be appreciated. > > For now, it is low-priority for me, I'm working on the bootstrap with Guillermo.

Sept. 1, 2015

Re: [Pharo-dev] [Pharo-users] [ANN] Pillar 1.0.0.

by Tudor Girba

Sounds great. I am really looking forward to using the PetitPillar parser. Cheers, Doru On Tue, Sep 1, 2015 at 3:45 PM, Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com> wrote: > Hello guys! > > I finished 5 months of internship into the RMoD team. I worked on Pillar > and I am glad to announce the version 1.0.0! > You can find an updated documentation of this version here : > > https://ci.inria.fr/pharo-contribution/view/Books/job/EnterprisePharoBook/l… > . > > We decided with Damien Cassou to use Semetic Versioning from now (see: > http://semver.org/) > > I will now explain the main changes I did on Pillar during my internship. > > For each new feature I added tests and documentation. > > I will begin with the changes of Pillar's structure > > - The configuration system is now manage by Cocoon > (http://www.smalltalkhub.com/#!/~PharoExtras/Cocoon) > -- We now use Magritte in Cocoon > > - I added Annotations : A syntax extension point > > - I added Transformers : A way to transform a document model before an > export (to add a section structure in HTML for example) > > - Some small refactoring. > -- Improvement of the template management > -- Improvement of the Pillar model parameters > > - Improvement of the document model > -- Now the figures and links are two different entity > > - I begun a PetitPillar (with PetitParser) in order to replace the old > parser too complicated. > > Now I will talk about new features for the users > > - Improvement of the usability of Pillar under Windows > > - Beamer and Deck.js exporters > > - Annotations : > -- To include a Pillar file into an other (${inputFile:path}$) (Example: > > https://github.com/SquareBracketAssociates/EnterprisePharo/blob/master/Ente… > ) > -- To create new slides in Beamer and Deck.js (${slide:My > Title|label=optional}$) > -- To create columns into a Pillar document (currently works in Beamer, > Deck.js and HTML) > -- â¦ > > - Transformers > -- You can now add a parameter "lineNumber=true" to a script and Pillar > will transform them to add the line numbers > -- You can now import a script from an other file (see the documentation > of the scripts) > -- â¦ > > - Improvement of the errors raised by Pillar > > - Addition of the inter-files links > > - Improvement of the title configuration for numbering > > - No need to make scripts anymore to use Pillar ! > -- You can used "defaultExporters" in your configuration to do multiple > export (see documentation) > -- Pillar generate a script for LaTeX compilation (only for Unix for now) > > - Possibility to export everything into a different folder (simpler to > clean after) > -- And possibility to copy some support files > > For the two previous point you can take example on Enterprise Pharo > (https://github.com/SquareBracketAssociates/EnterprisePharo) and Pharo > Mooc (https://github.com/SquareBracketAssociates/PharoMooc) > > This was a really cool internship :) > > If you have some questions do not hesitate! > > -- > Cyril > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 1, 2015

Re: [Pharo-dev] Removing name from Object

by Sven Van Caekenberghe

> On 01 Sep 2015, at 21:44, 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 I tried it in the past. I just tried again on the latest #50297. I did put a 'self haltOnce' in Object>>#name and with 'Halt enableHaltOnce' I can still browse and run all Zinc-Tests so we might be closer than we thought. In any case, almost any code that needs Object>>#name could probably we rewritten to send #printString (being lazy). Sven

Sept. 1, 2015