November 2017 - Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #329: 20176-Error-in-ByteArraybooleanAt

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #329 was: SUCCESS. The Pull Request #539 was integrated: "20176-Error-in-ByteArraybooleanAt" Pull request url: https://github.com/pharo-project/pharo/pull/539 Issue Url: https://pharo.fogbugz.com/f/cases/20176 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 25, 2017

Re: [Pharo-dev] OpalCompiler evaluate speed

by Stephane Ducasse

Could not we do a task force to clean the compiler? We need a better infrastructure for the tool. Stef On Fri, Nov 24, 2017 at 11:35 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2017-11-24 10:54 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: >> >> >> >> > On 23 Nov 2017, at 23:37, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> > >> > Hi Nicolas. >> > >> > Just some comments: >> > >> > Another thing you can try is to remove the allocation of Opal's IR. It >> > seems people use the IR only through the IRBuilder, so the API can be kept >> > but it can generate directly bytecode instead of IR then bytecode. Removing >> > those allocations would speed things up. It means merging IRFix / >> > IRTranslator / IRBytecodeGenerator somehow and have the IRBuilder API >> > directly call the new resulting merged class. >> > >> > Another thing is that when Opal became the default compiler, I evaluated >> > the speed and saw it was slower, but when loading large projects it seemed >> > loading time was dominated by Monticello / source reading / source loading >> > and the compilation time was overall not that significant (< 20% of time). I >> > don't know if this is still the case with GIT. I have problems currently >> > when editing some large methods (it seems in the IDE the method is compiled >> > at each keystroke...) and when doing OpalCompiler recompileAll (which I do >> > often since I edit bytecode sets) but else the performance of Opal seems to >> > be OK. Evaluate performance may be relevant in some cases but I've never >> > found such cases outside of the IDE in production. >> > >> >> Yes, the IR came over from the existing design of the ClosureCompiler for >> Squeak that Opal is was based on initiallyâ¦ I liked it at first because I >> was looking into byte code >> manipulation back then and for that it was quite nice. >> >> But for compiling, it adds a layer that is not really needed. If I would >> do it again I would not use this IR level in the compiler but instead do >> something simpler and use >> the BytecodeBuilder directly. >> >> But as Clement notes: it is not that much time when doing compilation if >> you consider the whole use-case of compiling, so this seemed not that of a >> problem >> (e.g. for compiling the image, we were happy with a factor 2, I did not >> benchmark recently, but I think this is what we reached). >> >> For the frontend (compile to AST + name analysis), it is fast enough to do >> syntax highlighting in the browser with it instead of a specialised parser, >> so that part is >> quite ok. > > > Agree >> >> >> One other thing that needs cleanup: the API/ OpalCompiler class. This >> tries to be compatible with the old API (e.g. failBlock) and got quite >> hacked to death over >> timeâ¦ we should clean that up. The complexity of #evaluate is partly due >> to that, I think. >> >> Marcus > > > Yes, that was exactly my feeling. >

Nov. 25, 2017

[Pharo 7.0-dev] Build #328: 20756-Secondary-selections-are-dark-after-switch-to-the-white-theme-in-Pharo-7

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #328 was: SUCCESS. The Pull Request #540 was integrated: "20756-Secondary-selections-are-dark-after-switch-to-the-white-theme-in-Pharo-7" Pull request url: https://github.com/pharo-project/pharo/pull/540 Issue Url: https://pharo.fogbugz.com/f/cases/20756 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 24, 2017

[Pharo 7.0-dev] Build #327: 20729-Monticello-history-browser-should-enable-diffing-with-parent

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #327 was: SUCCESS. The Pull Request #513 was integrated: "20729-Monticello-history-browser-should-enable-diffing-with-parent" Pull request url: https://github.com/pharo-project/pharo/pull/513 Issue Url: https://pharo.fogbugz.com/f/cases/20729 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 24, 2017

[Pharo 7.0-dev] Build #326: 20753-testStoreOn-using-the-compiler-should-have-a-more-descriptive-name

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #326 was: SUCCESS. The Pull Request #534 was integrated: "20753-testStoreOn-using-the-compiler-should-have-a-more-descriptive-name" Pull request url: https://github.com/pharo-project/pharo/pull/534 Issue Url: https://pharo.fogbugz.com/f/cases/20753 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 24, 2017

[Pharo 7.0-dev] Build #325: 20754-make-longer-timeout-for-some-randomly-failing-tests

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #325 was: SUCCESS. The Pull Request #536 was integrated: "20754-make-longer-timeout-for-some-randomly-failing-tests" Pull request url: https://github.com/pharo-project/pharo/pull/536 Issue Url: https://pharo.fogbugz.com/f/cases/20754 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 24, 2017

Re: [Pharo-dev] [Pharo-users] I love the launcher!!!!

by Peter UhnÃ¡k

Hi Herby, normally people use different images for their different projects, different versions, trying things, etc. Which means we end up with many locations on disk, and it can be hard to track. So PharoLauncher is a nice tool where you can download fresh image just by clicking, and you see the list of your local images and can launch them, etc. Peter On Thu, Nov 23, 2017 at 12:56 PM, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > Stephane Ducasse wrote: > >> Hi >> >> I love the PharoLauncher. >> > > Pardon my question, I have downloaded it and looked at it, but I don't get > it. What does it do / what are the use cases (honest question)? > > Thanks, Herby > > > It helps me to manage my parallel development and projects. >> >> We should put a link on the Pharo web site because >> >> http://files.pharo.org/platform/launcher/ >> >> is arcane. >> >> Stef >> >> > >

Nov. 24, 2017

Re: [Pharo-dev] Bloc Tutorial Feedback

by Sean P. DeNigris

Aliaksei Syrel wrote > you probably have a shared repo of bloc > somewhere on your machine. > The tutorial's code is up-to date :) Aha! Yes, okay. I will (hopefully) get used to that gotcha soon!! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 24, 2017

[Pharo 7.0-dev] Build #324: 20749-All-packages-need-to-be-reexported

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #324 was: SUCCESS. The Pull Request #531 was integrated: "20749-All-packages-need-to-be-reexported" Pull request url: https://github.com/pharo-project/pharo/pull/531 Issue Url: https://pharo.fogbugz.com/f/cases/20749 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 24, 2017

Re: [Pharo-dev] OpalCompiler evaluate speed

by Nicolas Cellier

2017-11-24 10:54 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > > On 23 Nov 2017, at 23:37, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > Hi Nicolas. > > > > Just some comments: > > > > Another thing you can try is to remove the allocation of Opal's IR. It > seems people use the IR only through the IRBuilder, so the API can be kept > but it can generate directly bytecode instead of IR then bytecode. Removing > those allocations would speed things up. It means merging IRFix / > IRTranslator / IRBytecodeGenerator somehow and have the IRBuilder API > directly call the new resulting merged class. > > > > Another thing is that when Opal became the default compiler, I evaluated > the speed and saw it was slower, but when loading large projects it seemed > loading time was dominated by Monticello / source reading / source loading > and the compilation time was overall not that significant (< 20% of time). > I don't know if this is still the case with GIT. I have problems currently > when editing some large methods (it seems in the IDE the method is compiled > at each keystroke...) and when doing OpalCompiler recompileAll (which I do > often since I edit bytecode sets) but else the performance of Opal seems to > be OK. Evaluate performance may be relevant in some cases but I've never > found such cases outside of the IDE in production. > > > > Yes, the IR came over from the existing design of the ClosureCompiler for > Squeak that Opal is was based on initiallyâ¦ I liked it at first because I > was looking into byte code > manipulation back then and for that it was quite nice. > > But for compiling, it adds a layer that is not really needed. If I would > do it again I would not use this IR level in the compiler but instead do > something simpler and use > the BytecodeBuilder directly. > > But as Clement notes: it is not that much time when doing compilation if > you consider the whole use-case of compiling, so this seemed not that of a > problem > (e.g. for compiling the image, we were happy with a factor 2, I did not > benchmark recently, but I think this is what we reached). > > For the frontend (compile to AST + name analysis), it is fast enough to do > syntax highlighting in the browser with it instead of a specialised parser, > so that part is > quite ok. > Agree > > One other thing that needs cleanup: the API/ OpalCompiler class. This > tries to be compatible with the old API (e.g. failBlock) and got quite > hacked to death over > timeâ¦ we should clean that up. The complexity of #evaluate is partly due > to that, I think. > > Marcus > Yes, that was exactly my feeling.

Nov. 24, 2017