December 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] code loading performance

by George Ganea

Thank you Sven, weâre already skipping writing to the epicea log, Iâm now wondering can we also skip the notifications or not really? Cheers, George > On 6 Dec 2019, at 19:01, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Yes, some improvements are needed. > > There are many steps: > > - downloading the code (networking) > - loading the code (file io) > - compiling the code > - writing to the changes file > - writing to the epicea log > - system notifications > - reactions to those system notifications > > BTW, doing a cleanup for production is also too slow, so I am guessing most time is lost in the last 4 items. > >> On 6 Dec 2019, at 17:07, George Ganea <georgeganea(a)gmail.com> wrote: >> >> Hi all, >> >> Currently loading GToolkit takes quite some time (arount 18 minutes at the best of times) we were wondering if thereâs been any attempts at improving code loading times in Metacello/Monticello. Or mabye there are some ideas on how one might start doing something like this? >> >> Cheers, >> George > >

Dec. 6, 2019

Re: [Pharo-dev] code loading performance

by George Ganea

Hi Vincent, I will definitely try it out and report back. Thank you! George > Hi Georges, > > There have been quite some improvements those last weeks on the performance of loading classes and methods. But we are still waiting for the https://github.com/pharo-project/pharo/pull/5292 <https://github.com/pharo-project/pharo/pull/5292> to be integrated. > > And you have to encapsulate the loading code into: SourceFiles deferFlushDuring: [...] and use the latest pharo 8.0 image. > > You can give a try with this and tell us how it goes! > > Cheers, > Vincent > > -----Original Message----- > From: Pharo-dev On Behalf Of George Ganea > Sent: Friday, 6 December 2019 17:08 > To: pharo-dev at lists.pharo.org <http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org> > Cc: Chis Vasile Andrei <dedal18 at yahoo.com <http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org>> > Subject: [Pharo-dev] code loading performance > > Hi all, > > Currently loading GToolkit takes quite some time (arount 18 minutes at the best of times) we were wondering if thereâs been any attempts at improving code loading times in Metacello/Monticello. Or mabye there are some ideas on how one might start doing something like this? > > Cheers, > George

Dec. 6, 2019

Re: [Pharo-dev] code loading performance

by Sven Van Caekenberghe

Yes, some improvements are needed. There are many steps: - downloading the code (networking) - loading the code (file io) - compiling the code - writing to the changes file - writing to the epicea log - system notifications - reactions to those system notifications BTW, doing a cleanup for production is also too slow, so I am guessing most time is lost in the last 4 items. > On 6 Dec 2019, at 17:07, George Ganea <georgeganea(a)gmail.com> wrote: > > Hi all, > > Currently loading GToolkit takes quite some time (arount 18 minutes at the best of times) we were wondering if thereâs been any attempts at improving code loading times in Metacello/Monticello. Or mabye there are some ideas on how one might start doing something like this? > > Cheers, > George

Dec. 6, 2019

[Pharo 8.0] Build #1047: Fixed issue #5271

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

There is a new Pharo build available! The status of the build #1047 was: SUCCESS. The Pull Request #5327 was integrated: "Fixed issue #5271" Pull request url: https://github.com/pharo-project/pharo/pull/5327 Issue Url: https://github.com/pharo-project/pharo/issues/fix/ImproveExecutableComments… Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 6, 2019

RE: [Pharo-dev] code loading performance

by vincent.blondeau＠lifeware.ch

Hi Georges, There have been quite some improvements those last weeks on the performance of loading classes and methods. But we are still waiting for the https://github.com/pharo-project/pharo/pull/5292 to be integrated. And you have to encapsulate the loading code into: SourceFiles deferFlushDuring: [...] and use the latest pharo 8.0 image. You can give a try with this and tell us how it goes! Cheers, Vincent -----Original Message----- From: Pharo-dev On Behalf Of George Ganea Sent: Friday, 6 December 2019 17:08 To: pharo-dev(a)lists.pharo.org Cc: Chis Vasile Andrei <dedal18(a)yahoo.com> Subject: [Pharo-dev] code loading performance Hi all, Currently loading GToolkit takes quite some time (arount 18 minutes at the best of times) we were wondering if thereâs been any attempts at improving code loading times in Metacello/Monticello. Or mabye there are some ideas on how one might start doing something like this? Cheers, George

Dec. 6, 2019

code loading performance

by George Ganea

Hi all, Currently loading GToolkit takes quite some time (arount 18 minutes at the best of times) we were wondering if thereâs been any attempts at improving code loading times in Metacello/Monticello. Or mabye there are some ideas on how one might start doing something like this? Cheers, George

Dec. 6, 2019

About package deprecation

by vincent.blondeau＠lifeware.ch

Hi all, As everyone knows, the BlueInk and GTRecorder packages have been removed from Pharo8.0 quite rapidly https://github.com/pharo-project/pharo/issues/5217. And it breaks the loading of other projects on Pharo8.0, like Roassal2. Some claims that those packages will not be deprecated because they are loadable as it from another repository. Why not? So, I tried. For BlueInk, no repository containing the sources has been indicated. And not repository exists on github. For the GTRecorder, the sources are there: https://github.com/pharo-contributions/EventRecorder, according to https://github.com/pharo-project/pharo/issues/5232. The problem is that the EventRecorder project does not contain exactly the same classes, the prefix has been changed from GT to ER. So, any reference to one of the classes of this project has to be changedâ¦ In particular, we had to make this change to make it load correctly: https://github.com/lifeware-sa/Roassal2/commit/78ce17bba98b89cb21a996cf8acaf 4e053ae082b (and we just have tried to load it so far). I think that not only Roassal is using those dependencies (see there https://github.com/search?o=desc <https://github.com/search?o=desc&q=GTEventCollector&s=indexed&type=Code> &q=GTEventCollector&s=indexed&type=Code and they are just public repos) and migrating them to the latest version of Pharo will be more painful since we need to fix the issue it immediately, or, wait that the maintainer of each project provide a fix to bypass the issues. Therefore, as we have a nice deprecation mechanism in our system, I suggest we use it so we can focus on stuff more important than writing tons of emails. I am then pushing in favor of the integration of this PR: https://github.com/pharo-project/pharo/pull/5257 so that we can have some time to solve the bugs. And I expect that those packages will be removed in Pharo 9.0. Now that everything is exposed, could the maintainers of the Pharo project take a clear decision concerning this topic? Also, we are expecting some justification on the undertaken action. Thanks, Vincent www.lifeware.ch <http://www.lifeware.ch>

Dec. 6, 2019

Re: [Pharo-dev] [Pharo 8.0] Build #1040: [easyReview] fixing comment typos

by vincent.blondeau＠polytech-lille.net

Maybe this? https://ci.inria.fr/pharo-ci-jenkins2/blue/organizations/jenkins/Test%20pen… : Error: Bad BitBlt arg (Fraction?); proceed to convert. GrafPort(Object)>>error: GrafPort(BitBlt)>>copyBits GrafPort>>copyBits GrafPort>>image:at:sourceRect:rule: FormCanvas>>image:at:sourceRect:rule: FormCanvas(Canvas)>>translucentImage:at:sourceRect: HiColumnController>>newCellMorphForRow: [ self newCellMorphForRow: rowIndex ] in HiColumnController>>cellMorphAtRow: in Block: [ self newCellMorphForRow: rowIndex ] Dictionary>>at:ifAbsent: HiColumnController>>cellMorphAtRow: HiColumnController>>cellMorphAtValue: [ :item | hiedraColumnController cellMorphAtValue: item ] in HiSpecExample>>initializeWidgets in Block: [ :item | hiedraColumnController cellMorphAtValue:...etc... BlockClosure>>cull: SpImageTableColumn(SpTableColumn)>>readObject: SpMorphicTableCellBuilder>>addCellColumn: SpMorphicTableCellBuilder>>visitImageColumn: SpImageTableColumn>>acceptColumnVisitor: SpMorphicTableCellBuilder(SpMorphicTableColumnVisitor)>>visit: SpMorphicTableDataSource>>cellColumn:row: [ :columnIndex | | cell | cell := self table dataSource cellColumn: (columns at: columnIndex) row: rowIndex. cell width: (columnWidths at: columnIndex). row addMorphBack: cell ] in FTTableContainerMorph>>updateExposedRows in Block: [ :columnIndex | ... Interval>>do: FTTableContainerMorph>>updateExposedRows FTTableMorph>>resizeAllSubviews FTTableMorph>>extent: FTTableMorph(Morph)>>bounds: FTTableMorph(Morph)>>layoutInBounds: TableLayout>>layoutTopToBottom:in: TableLayout>>layout:in: Morph>>doLayoutIn: [ self doLayoutIn: self layoutBounds ] in Morph>>computeFullBounds in Block: [ self doLayoutIn: self layoutBounds ] Vincent From: Pharo-dev On Behalf Of Damien Pollet Sent: Friday, 6 December 2019 08:15 To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] [Pharo 8.0] Build #1040: [easyReview] fixing comment typos Looks like there's one red bubble for windows in the pipeline steps ? On Wed, 4 Dec 2019 at 21:45, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> > wrote: This build in fact has zero errors. I wonder why build script still returns 1 (hence exit status is failure). Any idea? Esteban > On 4 Dec 2019, at 17:43, ci-pharo-ci-jenkins2(a)inria.fr <mailto:ci-pharo-ci-jenkins2@inria.fr> wrote: > > There is a new Pharo build available! > > The status of the build #1040 was: FAILURE. > > The Pull Request #5305 was integrated: "[easyReview] fixing comment typos" > Pull request url: https://github.com/pharo-project/pharo/pull/5305 > > Issue Url: https://github.com/pharo-project/pharo/issues/typo > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Dec. 6, 2019

[Pharo 8.0] Build #1046: 5300-Traits-categories-are-not-updated-when-rebuilding-classes

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

There is a new Pharo build available! The status of the build #1046 was: SUCCESS. The Pull Request #5301 was integrated: "5300-Traits-categories-are-not-updated-when-rebuilding-classes" Pull request url: https://github.com/pharo-project/pharo/pull/5301 Issue Url: https://github.com/pharo-project/pharo/issues/5300 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 6, 2019

Re: [Pharo-dev] [Pharo 8.0] Build #1040: [easyReview] fixing comment typos

by Damien Pollet

Looks like there's one red bubble for windows in the pipeline steps ? On Wed, 4 Dec 2019 at 21:45, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > This build in fact has zero errors. > I wonder why build script still returns 1 (hence exit status is failure). > > Any idea? > > Esteban > > > On 4 Dec 2019, at 17:43, ci-pharo-ci-jenkins2(a)inria.fr wrote: > > > > There is a new Pharo build available! > > > > The status of the build #1040 was: FAILURE. > > > > The Pull Request #5305 was integrated: "[easyReview] fixing comment > typos" > > Pull request url: https://github.com/pharo-project/pharo/pull/5305 > > > > Issue Url: https://github.com/pharo-project/pharo/issues/typo > > Build Url: > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Dec. 6, 2019