Re: [Pharo-dev] code loading performance

[Serge Stinckwich]

On Fri, Dec 6, 2019 at 5:08 PM George Ganea  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?
>
>
Could be even worse when you dl from low-bandwith countries like in Africa.
While waiting a better solution, it possible to have build images available
from PharoLauncher ?
Regards,

-- 
Serge Stinckwic
h

Int. Research Unit
 on Modelling/Simulation of Complex Systems (UMMISCO)
Sorbonne University
 (SU)
French National Research Institute for Sustainable Development (IRD)
U
niversity of Yaoundé I, Cameroon
"Programs must be written for people to read, and only incidentally for
machines to execute."
https://twitter.com/SergeStinckwich

[Pharo-dev] [Pharo 8.0] Build #1048: 5323-5320-Code-completion-failure-on-method-name

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #1048 was: SUCCESS.

The Pull Request #5330 was integrated: 
"5323-5320-Code-completion-failure-on-method-name"
Pull request url: https://github.com/pharo-project/pharo/pull/5330

Issue Url: https://github.com/pharo-project/pharo/issues/5323
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/1048/

Re: [Pharo-dev] code loading performance

[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  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  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
> 
> 

Re: [Pharo-dev] code loading performance

[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 
>  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 
> 
> Cc: Chis Vasile Andrei  >
> 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

Re: [Pharo-dev] code loading performance

[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  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

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

[ci-pharo-ci-jenkins2]

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/ImproveExecutableCommentsToIsAllAlphaNumerics
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/1047/

Re: [Pharo-dev] code loading performance

[Vincent Blondeau via Pharo-dev]

--- Begin Message ---
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@lists.pharo.org
Cc: Chis Vasile Andrei 
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


--- End Message ---

[Pharo-dev] code loading performance

[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

[Pharo-dev] About package deprecation

[Vincent Blondeau via Pharo-dev]

--- Begin Message ---
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

=GTEventCollector=indexed=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  

 

 

<>--- End Message ---

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

[vincent.blondeau]

Maybe this?

 

https://ci.inria.fr/pharo-ci-jenkins2/blue/organizations/jenkins/Test%20pending%20pull%20request%20and%20branch%20Pipeline/detail/Pharo8.0/1040/pipeline
 :

 

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 
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 mailto:esteba...@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-jenki...@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%20and%20branch%20Pipeline/job/Pharo8.0/1040/






 

-- 

Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

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

[ci-pharo-ci-jenkins2]

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%20and%20branch%20Pipeline/job/Pharo8.0/1046/