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

Re: [Pharo-dev] Pharo CI Validation Timeout

by Guillermo Polito

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

by Guillermo Polito

The problem is if (like in the past) name is extensively used by some library we depend upon (like... let's say morphic), a deprecation that raises an exception may turn the system unusable. It's not that it is not doable, but we should do it gently and with love. El miÃ©., 2 de sept. de 2015 a la(s) 9:30 a. m., Esteban Lorenzano < estebanlm(a)gmail.com> escribiÃ³: > On 02 Sep 2015, at 09:25, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > On Wed, Sep 2, 2015 at 8:40 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> How can we find out, which external projects depend on this? >> > > Is #name in any way special? Why not just deprecate it like any other > method change or removal? (And then remove it in Pharo 6) > > > +1 > thatâs the way to do it :) > > > Peter > > >

Sept. 2, 2015

Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp

by stepharo

for your info... Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp Stef

Sept. 2, 2015

size of MCbrowser should be proportional

by stepharo

Hi guys now when I open MCBrowser it gets 80% of my window. So this is good to make it larger but it should be proportional to the actual size. https://pharo.fogbugz.com/f/cases/16451/MCBrowser-default-size-should-propo… Could the person that originally changed it fix it? Stef

Sept. 2, 2015

Re: [Pharo-dev] Removing name from Object

by Esteban Lorenzano

> On 02 Sep 2015, at 09:25, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > On Wed, Sep 2, 2015 at 8:40 AM, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: > How can we find out, which external projects depend on this? > > Is #name in any way special? Why not just deprecate it like any other method change or removal? (And then remove it in Pharo 6) +1 thatâs the way to do it :) > > Peter

Sept. 2, 2015

Re: [Pharo-dev] Removing name from Object

by Peter UhnÃ¡k

On Wed, Sep 2, 2015 at 8:40 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > How can we find out, which external projects depend on this? > Is #name in any way special? Why not just deprecate it like any other method change or removal? (And then remove it in Pharo 6) Peter

Sept. 2, 2015

Re: [Pharo-dev] Removing name from Object

by stepharo

Good idea I will try when I have a moment to relax. I'm in a little focused hacking sprint then admin sprint :) Le 1/9/15 22:02, Sven Van Caekenberghe a Ã©crit : >> 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. 2, 2015

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

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

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

by stepharo

We could ship a specific package with rules for each version of Pharo. We did it with andre's work and we should continue. Le 1/9/15 10:23, Stephan Eggermont a Ã©crit : > On 01-09-15 08:35, Marcus Denker wrote: >> But just think how much this simplifies the experience of people >> loading old code into a new >> Pharo version: it just keeps running and fixes itself! Itâs that kind >> of things we need to be >> able to evolve the system. > > This is a crucial step to support continuous improvement indeed. > Just-in-time repeatable refactoring, reducing the cost of change > > Stephan > > >

Sept. 1, 2015

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

by stepharo

>> >> It can be made pluggable, of course. I donât want to have that there in a way that it requires >> the refactoring engine to be present all the time. >> >> If itâs there â> transform. If not â> do what it does now. >> >> But just think how much this simplifies the experience of people loading old code into a new >> Pharo version: it just keeps running and fixes itself! Itâs that kind of things we need to be >> able to evolve the system. >> >> Imagine, this is a functionality (I think) no other system has! Yes but we should make it pluggable. I would like something that says before all the tests were green and after these automatic changes they are also green :) > I will not like a feature where it transforms my code without asking. > I would prefer that a diff browser pops up and asks me if changes are ok. Automatic rewrite of code often forgot to check some specific cases and you end with bugs in your code if there is no review. > The idea is great but the choice of changing the code or not has to be in the user hands.

Sept. 1, 2015

Re: [Pharo-dev] Pharo CI Validation Timeout

by stepharo

Ben can you open a bug entry because we should really try your change now. And probably remove after the Experimental from the name. Stef Le 1/9/15 19:15, Ben Coman a Ã©crit : > 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? > > cheers -ben > > On Tue, Sep 1, 2015 at 11:23 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> This is different issue, same problem >> https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/12442//artifact/val… >> >> I'm blaming CI. >> >> On Tue, Sep 1, 2015 at 5:22 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>> Hi, >>> >>> CI is failing on >>> >>> a CIAndRule: Timeout (after 0:01:00:00) occured >>> >>> >>> https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/12440//artifact/val… >>> >>> Because the validation before it was ok and I just changed a protocol. >>> Is this my problem? Is this issue in CI? >>> >>> Thanks, >>> Peter >> >

Sept. 1, 2015

Removing name from Object

by stepharo

Hi guys I would love to see name removed from Object. It brings more problems than anything else. Any taker? Stef

Sept. 1, 2015

Re: [Pharo-dev] Pharo CI Validation Timeout

by Ben Coman

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? cheers -ben On Tue, Sep 1, 2015 at 11:23 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > This is different issue, same problem > https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/12442//artifact/val… > > I'm blaming CI. > > On Tue, Sep 1, 2015 at 5:22 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> Hi, >> >> CI is failing on >> >> a CIAndRule: Timeout (after 0:01:00:00) occured >> >> >> https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/12440//artifact/val… >> >> Because the validation before it was ok and I just changed a protocol. >> Is this my problem? Is this issue in CI? >> >> Thanks, >> Peter > >

Sept. 1, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50297 Home: https://github.com/pharo-project/pharo-core

Sept. 1, 2015

[pharo-project/pharo-core] cd1fb7: 50297

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: cd1fb747933fa128ad8283286ef8ecd0b4b82f18 https://github.com/pharo-project/pharo-core/commit/cd1fb747933fa128ad828328… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-01 (Tue, 01 Sep 2015) Changed paths: M ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version2019_.st M ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version219_.st M ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic versions/stable_.st A ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version1210_.st M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version306_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version3110_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version320_.st M GT-Inspector.package/extension/Object/instance/gtInspectorPresentationsIn_inContext_.st M GT-Spotter-EventRecorder.package/GTSpotterEventRecorder.class/instance/events/recordAccouncement_.st A GT-Spotter-EventRecorder.package/extension/GTSpotterActOn/instance/asRecorderEvent.st A GT-Spotter-EventRecorder.package/extension/GTSpotterCategorySelected/instance/asRecorderEvent.st A GT-Spotter-EventRecorder.package/extension/GTSpotterContextChanged/instance/asRecorderEvent.st A GT-Spotter-EventRecorder.package/extension/GTSpotterDiveInCategory/instance/asRecorderEvent.st A GT-Spotter-EventRecorder.package/extension/GTSpotterDiveInElement/instance/asRecorderEvent.st A GT-Spotter-EventRecorder.package/extension/GTSpotterDiveOut/instance/asRecorderEvent.st A GT-Spotter-EventRecorder.package/extension/GTSpotterExitAnnouncement/instance/asRecorderEvent.st A GT-Spotter-EventRecorder.package/extension/GTSpotterHidePreview/instance/asRecorderEvent.st A GT-Spotter-EventRecorder.package/extension/GTSpotterSearchFinished/instance/asRecorderEvent.st A GT-Spotter-EventRecorder.package/extension/GTSpotterSelectedCandidateChanged/instance/asRecorderEvent.st A GT-Spotter-EventRecorder.package/extension/GTSpotterShowPreview/instance/asRecorderEvent.st M GT-SpotterExtensions-Core.package/extension/AbstractCompiler/instance/silentlyDo_exceptionDo_.st M GT-SpotterExtensions-Core.package/extension/MCWorkingCopy/instance/versionInfo.st M GT-Tests-Inspector.package/GTInspectorExamplesTest.class/instance/tests/checkAllPresentationsOf_.st A Glamour-Core.package/GLMPresentation.class/instance/testing/hasTransformation.st M Glamour-Morphic-Renderer.package/GLMMorphicListingRenderer.class/instance/private/textInputFor_withHelpMessage_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50296.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50297.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50296.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50297.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50297 ConfigurationOfRubric http://files.pharo.org/image/50/50297.zip

Sept. 1, 2015

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

by Sven Van Caekenberghe

Thank you for your contributions, Cyril, we can only hope that you stick around. > On 01 Sep 2015, at 15:45, 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 >

Sept. 1, 2015

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

by Damien Cassou

Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com> writes: > 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…. Cyril has been a great student. His contributions to Pillar are all important. Now that Pillar 1.0.0 is released, we should try to move to PetitPillar (done at 90%). There might be some compatibility problems with existing documents but the great test suite (2100 tests covering 94% of the code) should limit them. The TODO list is now much larger but I guess that's a good sign: http://www.smalltalkhub.com/#!/~Pier/Pillar. Please contribute! -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Sept. 1, 2015

Re: [Pharo-dev] Pharo CI Validation Timeout

by Marcus Denker

Yes, for now just restart.. I will try to find time to look into this. > On 01 Sep 2015, at 17:31, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > So do I wait, or do I keeping pushing the monkey until it succeeds? > > On Tue, Sep 1, 2015 at 5:23 PM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > >> On 01 Sep 2015, at 17:22, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: >> >> Hi, >> >> CI is failing on >> a CIAndRule: Timeout (after 0:01:00:00) occured >> https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/12440//artifact/val… <https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/12440//artifact/val…> >> >> Because the validation before it was ok and I just changed a protocol. >> Is this my problem? Is this issue in CI? >> > > This is an issue with, I think, the virtual server belowâ¦ it is strange: some times the run takes > very very very long. I have not yet found out why (there is an issue tracker entry for it). > > Marcus > >

Sept. 1, 2015

Re: [Pharo-dev] Pharo CI Validation Timeout

by Peter UhnÃ¡k

So do I wait, or do I keeping pushing the monkey until it succeeds? On Tue, Sep 1, 2015 at 5:23 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 01 Sep 2015, at 17:22, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > CI is failing on > a CIAndRule: Timeout (after 0:01:00:00) occured > > https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/12440//artifact/val… > > Because the validation before it was ok and I just changed a protocol. > Is this my problem? Is this issue in CI? > > > This is an issue with, I think, the virtual server belowâ¦ it is strange: > some times the run takes > very very very long. I have not yet found out why (there is an issue > tracker entry for it). > > Marcus > >

Sept. 1, 2015

Re: [Pharo-dev] Pharo CI Validation Timeout

by Peter UhnÃ¡k

This is different issue, same problem https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/12442//artifact/val… I'm blaming CI. On Tue, Sep 1, 2015 at 5:22 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > CI is failing on > a CIAndRule: Timeout (after 0:01:00:00) occured > > https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/12440//artifact/val… > > Because the validation before it was ok and I just changed a protocol. > Is this my problem? Is this issue in CI? > > Thanks, > Peter >

Sept. 1, 2015

Re: [Pharo-dev] Pharo CI Validation Timeout

by Marcus Denker

> On 01 Sep 2015, at 17:22, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > CI is failing on > a CIAndRule: Timeout (after 0:01:00:00) occured > https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/12440//artifact/val… <https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/12440//artifact/val…> > > Because the validation before it was ok and I just changed a protocol. > Is this my problem? Is this issue in CI? > This is an issue with, I think, the virtual server belowâ¦ it is strange: some times the run takes very very very long. I have not yet found out why (there is an issue tracker entry for it). Marcus

Sept. 1, 2015

Pharo CI Validation Timeout

by Peter UhnÃ¡k

Hi, CI is failing on a CIAndRule: Timeout (after 0:01:00:00) occured https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/12440//artifact/val… Because the validation before it was ok and I just changed a protocol. Is this my problem? Is this issue in CI? Thanks, Peter

Sept. 1, 2015

Re: [Pharo-dev] SpecTableLayout & TableLayoutProperties

by webwarrior

It looks like I replied to Peter UhnÃ¡k directly, so I copy my message here: If you open halo menu on topmost [in hierarchy] PanelMorph in window, you can see that layout properties have been set properly. By default hResizing and vResizing are set to #spaceFill in SpecTableLayout, so: 1. rows are the same width - therefore cellPositioning doesn't matter 2. rows are occupying the whole height - therefore listCentering doesn't matter The following layout will allow to see effects of listCentering and cellPositioning (btw cellPositioning is #center by default): layout := SpecTableLayout column cellPositioning: #center; listCentering: #bottomRight; newRow: [ :r | r vResizing: #shrinkWrap; width: 120; add: #cell11; add: #cell12 ]; newRow: [ :r | r vResizing: #shrinkWrap; add: #cell21; add: #cell22]; yourself. -- View this message in context: http://forum.world.st/SpecTableLayout-TableLayoutProperties-tp4847376p48474… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 1, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50296 Home: https://github.com/pharo-project/pharo-core

Sept. 1, 2015

[pharo-project/pharo-core] ec12cb: 50296

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: ec12cbdee8521a20954aaaf9f9e2f0f81ef815e8 https://github.com/pharo-project/pharo-core/commit/ec12cbdee8521a20954aaaf9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-01 (Tue, 01 Sep 2015) Changed paths: M AST-Core.package/ASTCacheReset.class/definition.st M Balloon.package/BalloonEngine.class/instance/initialize/release.st A Deprecated50.package/extension/Color/instance/asHTMLColor.st A Deprecated50.package/extension/Color/instance/printHtmlString.st R Graphics-Primitives.package/Color.class/instance/conversions/asHTMLColor.st R Graphics-Primitives.package/Color.class/instance/html/printHtmlString.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadArray.st M Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitArrayNode_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50295.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50296.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50295.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50296.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tools.package/SyntaxErrorDebugger.class/instance/initialization/release.st Log Message: ----------- 50296 16448 #instead for Array https://pharo.fogbugz.com/f/cases/16448 16444 ASt-Core should not have a BlueInk rpackage tag https://pharo.fogbugz.com/f/cases/16444 16438 Deprecate Color>>printHtmlString and Color>>asHTMLColor https://pharo.fogbugz.com/f/cases/16438 14765 Missing calls of "super release" in #release methods https://pharo.fogbugz.com/f/cases/14765 http://files.pharo.org/image/50/50296.zip

Sept. 1, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40621 Home: https://github.com/pharo-project/pharo-core

Sept. 1, 2015

[pharo-project/pharo-core] d9d90b: 40621

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: d9d90b14903ef845e04a0fb8752f03c301d0e6ac https://github.com/pharo-project/pharo-core/commit/d9d90b14903ef845e04a0fb8… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-01 (Tue, 01 Sep 2015) Changed paths: M RPackage-Core.package/RPackageOrganizer.class/instance/-- all --/packageNamed_ifAbsent_.st M RPackage-Core.package/RPackageOrganizer.class/instance/accessing/packageNamed_ifAbsent_.st M ScriptLoader40.package/ScriptLoader.class/instance/-- all --/commentForCurrentUpdate.st R ScriptLoader40.package/ScriptLoader.class/instance/-- all --/script620.st A ScriptLoader40.package/ScriptLoader.class/instance/-- all --/script621.st R ScriptLoader40.package/ScriptLoader.class/instance/-- all --/update40620.st A ScriptLoader40.package/ScriptLoader.class/instance/-- all --/update40621.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script620.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script621.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40620.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40621.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40621 15935 Backport 4.0: Renaming a package just by changing upper/lowercase removes the package https://pharo.fogbugz.com/f/cases/15935 http://files.pharo.org/image/40/40621.zip

Sept. 1, 2015

[ANN] Pillar 1.0.0.

by Ferlicot D. Cyril

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

Sept. 1, 2015

Flattr added to pharo.org

by Marcus Denker

Hi, We added at Flattr button: http://pharo.org/contribute <http://pharo.org/contribute> Direkt link is: https://flattr.com/thing/4606474/Pharo-Welcome-to-Pharo Marcus

Sept. 1, 2015

Re: [Pharo-dev] Versionner and BaselineOf

by Christophe Demarey

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] No longer valid issues

by Ben Coman

On Tue, Sep 1, 2015 at 5:33 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> On 01 Sep 2015, at 10:46, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> Sometimes I encounter issue that is no longer valid (has been fixed / changed / ... ) >> >> Do I mark it as >> > I think it dependsâ¦ the strange thing that fogbugz makes âresolvingâ and âcloseâ two steps > helps here, though: we can keep issues open for some days to give the original submitter > a chance to react and âsymbolizeâ that this is not just a rude action on our partâ¦ > > So I would use ânot reproducibleâ if you canât reproduce. Then if two people canât, we close. > > And inside of âresolvedâ we have âNor reproducibleâ, âinvalidâ (e.g. if the subsystem has been removed > or changed). Or even âFixedâ. > >> There also seem to be quite large amount of stale issues... >> If someone didn't fix them nor even commented on them in years, maybe the issue should be let to die? >> If nobody is commenting on it, nobody is interested in it. >> If the issue pops up again, we can easily create fresh issue. >> > > Yes, we have a âTimeOutâ Stateâ¦ we should use that moreâ¦ it would be best to do that automatically, > so nobody can get upset against a person closing the issuesâ¦ The neutrality and consistency of this is a good idea. > 12 month after no action â> close with mail to original submitter. A two step action to close would be good. Resolve to "Stale" status while requesting an update from submitter, possibly also notifying anyone that commented. Then close it if it remains stale for some amount of time -- but we should take care that these don't end up in our release statistics as "wow look how many issue we closed." If possible, maybe there should also be a prominent message in the header or sidebar of our Fogbugz pages advising of this policy. > Re-opening is easy, and with that we > make sure that only valid issues stay in the issue tracker. > > (Many of these issues will actually be already fixed, so it will save a lot of timeâ¦) cheers -ben

Sept. 1, 2015

SpecTableLayout & TableLayoutProperties

by Peter UhnÃ¡k

Hi, it is my understanding that I should be able to change table layout properties with stuff like cellPositioning: / listCentering: / etc. However nothing I do have any change. Am I using it incorrectly, or is this not (properly) implemented? example: (the cell content is placed in #topLeft despite specifying positioning and centering) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |ui layout| ui := DynamicComposableModel new. ui instantiateModels: #( cell11 LabelModel cell12 LabelModel cell21 LabelModel cell22 LabelModel ). ui cell11 label: '1-1'. ui cell12 label: '1-2'. ui cell21 label: '2-1'. ui cell22 label: '2-2'. layout := SpecTableLayout column cellPositioning: #center; listCentering: #bottomRight; newRow: [ :r | r add: #cell11; add: #cell12 ]; newRow: [ :r | r add: #cell21; add: #cell22]; yourself. ui openWithSpecLayout: layout. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thanks, Peter

Sept. 1, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50295 Home: https://github.com/pharo-project/pharo-core

Sept. 1, 2015

[pharo-project/pharo-core] 788aa0: 50295

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 788aa01b2e6ab1496ab2765fbe4d13539b690a04 https://github.com/pharo-project/pharo-core/commit/788aa01b2e6ab1496ab2765f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-01 (Tue, 01 Sep 2015) Changed paths: M AST-Core.package/ManifestASTCore.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st M Compression.package/ManifestCompression.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st R Jobs.package/JobTest.class/README.md R Jobs.package/JobTest.class/definition.st R Jobs.package/JobTest.class/instance/tests/tearDown.st R Jobs.package/JobTest.class/instance/tests/testChildJob.st R Jobs.package/JobTest.class/instance/tests/testCurrentJob.st R Jobs.package/JobTest.class/instance/tests/testJobAnnouncements.st R Jobs.package/JobTest.class/instance/tests/testLookupJob.st R Jobs.package/JobTest.class/instance/tests/testOwner.st R Jobs.package/JobTest.class/instance/tests/testProgress.st R Jobs.package/JobTest.class/instance/tests/testProgressChangeByCurrentValue.st R Jobs.package/JobTest.class/instance/tests/testSingleJob.st A Jobs.package/ManifestJobs.class/class/meta-data - dependency analyser/ignoredDependencies.st A JobsTests.package/JobTest.class/README.md A JobsTests.package/JobTest.class/definition.st A JobsTests.package/JobTest.class/instance/tests/tearDown.st A JobsTests.package/JobTest.class/instance/tests/testChildJob.st A JobsTests.package/JobTest.class/instance/tests/testCurrentJob.st A JobsTests.package/JobTest.class/instance/tests/testJobAnnouncements.st A JobsTests.package/JobTest.class/instance/tests/testLookupJob.st A JobsTests.package/JobTest.class/instance/tests/testOwner.st A JobsTests.package/JobTest.class/instance/tests/testProgress.st A JobsTests.package/JobTest.class/instance/tests/testProgressChangeByCurrentValue.st A JobsTests.package/JobTest.class/instance/tests/testSingleJob.st M Monticello.package/ManifestMonticello.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st A OpalCompiler-Core.package/ManifestOpalCompilerCore.class/class/code-critics/rejectRules.st A OpalCompiler-Core.package/ManifestOpalCompilerCore.class/class/code-critics/ruleAssignmentInIfTrueRuleV1TruePositive.st A OpalCompiler-Core.package/ManifestOpalCompilerCore.class/class/code-critics/ruleBadMessageRuleV1FalsePositive.st A OpalCompiler-Core.package/ManifestOpalCompilerCore.class/class/code-critics/ruleMethodHasNoTimeStampRuleV1TruePositive.st A OpalCompiler-Core.package/ManifestOpalCompilerCore.class/class/code-critics/ruleTempsReadBeforeWrittenRuleV1FalsePositive.st A OpalCompiler-Core.package/ManifestOpalCompilerCore.class/class/code-critics/ruleToDoCollectRuleV1FalsePositive.st A OpalCompiler-Core.package/ManifestOpalCompilerCore.class/class/code-critics/ruleVariableAssignedLiteralRuleV1FalsePositive.st R OpalCompiler-Core.package/ManifestOpalCompilerCore.class/class/meta data/rejectRules.st R OpalCompiler-Core.package/ManifestOpalCompilerCore.class/class/meta data/ruleAssignmentInIfTrueRuleV1TruePositive.st R OpalCompiler-Core.package/ManifestOpalCompilerCore.class/class/meta data/ruleBadMessageRuleV1FalsePositive.st R OpalCompiler-Core.package/ManifestOpalCompilerCore.class/class/meta data/ruleMethodHasNoTimeStampRuleV1TruePositive.st R OpalCompiler-Core.package/ManifestOpalCompilerCore.class/class/meta data/ruleTempsReadBeforeWrittenRuleV1FalsePositive.st R OpalCompiler-Core.package/ManifestOpalCompilerCore.class/class/meta data/ruleToDoCollectRuleV1FalsePositive.st R OpalCompiler-Core.package/ManifestOpalCompilerCore.class/class/meta data/ruleVariableAssignedLiteralRuleV1FalsePositive.st A OpalCompiler-Core.package/ManifestOpalCompilerCore.class/class/meta-data - dependency analyser/ignoredDependencies.st M Ring-Monticello.package/ManifestRingMonticello.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50294.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50295.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50294.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50295.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/ManifestSlot.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st M System-Changes.package/ManifestSystemChanges.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st M System-FileRegistry.package/ManifestSystemFileRegistry.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st M System-Sources.package/ManifestSystemSources.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st R System-Support.package/ClassQueryTest.class/README.md R System-Support.package/ClassQueryTest.class/definition.st R System-Support.package/ClassQueryTest.class/instance/tests/testAllCallsOn.st R System-Support.package/ClassQueryTest.class/instance/tests/testAllCallsOnASymbol.st R System-Support.package/ClassQueryTest.class/instance/tests/testReferencedClasses.st M System-Support.package/ManifestSystemSupport.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st R System-Support.package/MethodQueryTest.class/README.md R System-Support.package/MethodQueryTest.class/definition.st R System-Support.package/MethodQueryTest.class/instance/tests/testReferencedClasses.st A System-SupportTests.package/ClassQueryTest.class/README.md A System-SupportTests.package/ClassQueryTest.class/definition.st A System-SupportTests.package/ClassQueryTest.class/instance/tests/testAllCallsOn.st A System-SupportTests.package/ClassQueryTest.class/instance/tests/testAllCallsOnASymbol.st A System-SupportTests.package/ClassQueryTest.class/instance/tests/testReferencedClasses.st A System-SupportTests.package/MethodQueryTest.class/README.md A System-SupportTests.package/MethodQueryTest.class/definition.st A System-SupportTests.package/MethodQueryTest.class/instance/tests/testReferencedClasses.st M Traits.package/ManifestTraits.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st M Transcript.package/ManifestTranscript.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st A UIManager.package/ManifestUIManager.class/class/meta-data - dependency analyser/ignoredDependencies.st M UIManager.package/ManifestUIManager.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st Log Message: ----------- 50295 Jobs-Tests http://files.pharo.org/image/50/50295.zip

Sept. 1, 2015

Re: [Pharo-dev] No longer valid issues

by Marcus Denker

> On 01 Sep 2015, at 10:46, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Sometimes I encounter issue that is no longer valid (has been fixed / changed / ... ) > > Do I mark it as > I think it dependsâ¦ the strange thing that fogbugz makes âresolvingâ and âcloseâ two steps helps here, though: we can keep issues open for some days to give the original submitter a chance to react and âsymbolizeâ that this is not just a rude action on our partâ¦ So I would use ânot reproducibleâ if you canât reproduce. Then if two people canât, we close. And inside of âresolvedâ we have âNor reproducibleâ, âinvalidâ (e.g. if the subsystem has been removed or changed). Or even âFixedâ. > There also seem to be quite large amount of stale issues... > If someone didn't fix them nor even commented on them in years, maybe the issue should be let to die? > If nobody is commenting on it, nobody is interested in it. > If the issue pops up again, we can easily create fresh issue. > Yes, we have a âTimeOutâ Stateâ¦ we should use that moreâ¦ it would be best to do that automatically, so nobody can get upset against a person closing the issuesâ¦ 12 month after no action â> close with mail to original submitter. Re-opening is easy, and with that we make sure that only valid issues stay in the issue tracker. (Many of these issues will actually be already fixed, so it will save a lot of timeâ¦) Marcus

Sept. 1, 2015

No longer valid issues

by Peter UhnÃ¡k

Sometimes I encounter issue that is no longer valid (has been fixed / changed / ... ) Do I mark it as a) Work Needed (Not Reproducible) but there's no more work needed b) Resolved (Fix Review Needed) with a comment that's no longer reproducible c) Resolved (Invalid) since it's no longer valid d) something else? Option b) makes probably most sense since someone just needs to review that it's truly not reproducible and close it. Or maybe option a), and change the "To Review" filter to also include this. There also seem to be quite large amount of stale issues... If someone didn't fix them nor even commented on them in years, maybe the issue should be let to die? If nobody is commenting on it, nobody is interested in it. If the issue pops up again, we can easily create fresh issue. Peter

Sept. 1, 2015

[Pharo4] Issues for review for Pharo4

by Marcus Denker

Hello, There are 4 issues for Pharo4 that need input: https://pharo.fogbugz.com/f/filters/45/Review <https://pharo.fogbugz.com/f/filters/45/Review> Marcus

Sept. 1, 2015

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

by Stephan Eggermont

On 01-09-15 08:35, Marcus Denker wrote: > But just think how much this simplifies the experience of people loading old code into a new > Pharo version: it just keeps running and fixes itself! Itâs that kind of things we need to be > able to evolve the system. This is a crucial step to support continuous improvement indeed. Just-in-time repeatable refactoring, reducing the cost of change Stephan

Sept. 1, 2015