Re: [Pharo-dev] [Mm10] 2020-03-23 (WAS: No subject)

[Vincent Blondeau via Pharo-dev]

--- Begin Message ---
Hi Pablo,

Great news! We are eager to test this. Do you plan to backport the changes for 
the large images to Pharo8.0? Or should we try a 9.0 to try it?

Also, what is Aleph? (I cannot find a description in this list thread...)

Cheers,
Vincent Blondeau
Lifeware SA

-Original Message-
From: Pharo-dev On Behalf Of teso...@gmail.com
Sent: Monday, 23 March 2020 10:02
To: Pharo-dev 
Subject: Re: [Pharo-dev] (no subject)

Sorry for the subject less message, sending it too fast

On Mon, Mar 23, 2020 at 9:55 AM teso...@gmail.com  wrote:
>
> Monday morning, so I spam to tell what I have done last week for Pharo.
>
>  ### Last week:
>
> - Integrating Spotter processors with Aleph
> - Testing problem with Pharo8 and Metacello loading.
> - Debugging problem with SDL in OSX Pharo8 VM
> - Adding classes indexes to AlephIndexManager
> - Adding a baseline to load Spotter + Aleph + Completion: this 
> improves the spotter/completion and senders/implementors/... for large 
> images. An announcement will arrive when I have better index 
> generation times.
> - Generating a Big image for testing (using 
> github.com/tesonep/pharo-image generator)
> - Commenting and fixing PR
> - Deleting closed PR from Jenkins
> - A new version of the VM for RHEL (32 / 64 bits)
> - Improving the performance of the indexes of Spotter
>
>  ### This week... idealy (starting 2020-03-23):
>
> - Improving Large images index generation time.
> - Fixing Package List / Categories in Calypso
> - [VM] Fix symbolic links in Pharo8 VM
> - Adding a label to a PR when it has no test errors.
> - [OSSubprocess] Integrate Pavel + Christophe windows version.
> - [VM] Check the crash dumps in an endless loop
> - [VM] Improve the usage of Stdout and Stderr, in a correct way
> - [Pharo9] Propose a PR for Fuel to support Sista
> - [VM] Fixing Tests in Idle.
> - [VM] SDL Plugin for Idle.
> - [VM] Improving Speed of TFFI.
> - [VM] Writing tests for JIT generation
>
> --
> Pablo Tesone.
> teso...@gmail.com



--
Pablo Tesone.
teso...@gmail.com



--- End Message ---

Re: [Pharo-dev] PR without Tests

[Vincent Blondeau via Pharo-dev]

--- Begin Message ---
Great news!

I was wondering if they were also something planned to get some coverage 
information report to help to add more tests on parts of the system that are 
not tested?

Cheers,
Vincent


-Original Message-
From: Pharo-dev On Behalf Of teso...@gmail.com
Sent: Thursday, 6 February 2020 10:30
To: Pharo-dev ; r...@inria.fr list 
Subject: [Pharo-dev] PR without Tests

Hello,
   Pharo is not Smalltalk / Smalltalk is not Pharo / Pharo is Smalltalk.
Now that I have your attention because it seems the only read mail has to have 
this.

We have to continue improving the quality of Pharo. One of the biggest assets 
that we have in Pharo are the tons of tests. So, we need to reject any PR that 
does not have tests or it is not already tested.

To ease this quality measure, please add some comments on the PR about how your 
new code or modified code is tested or benchmarked.

Cheers.

--
Pablo Tesone.
teso...@gmail.com



--- End Message ---

Re: [Pharo-dev] [P9] Large images tag

[Vincent Blondeau via Pharo-dev]

--- Begin Message ---
Hi Stef,

Great idea! Here are some that could be added to the list:
https://github.com/pharo-project/pharo/issues/5478
https://github.com/pharo-project/pharo/issues/5260 
https://github.com/pharo-project/pharo/issues/5191 
https://github.com/pharo-project/pharo/issues/5188 
https://github.com/pharo-project/pharo/issues/5187 
https://github.com/pharo-project/pharo/issues/4896 

Cheers,
Vincent

Ps: only members of the Pharo git repo can tag issues.


-Original Message-
From: Pharo-dev On Behalf Of ducasse
Sent: Tuesday, 21 January 2020 20:34
To: Pharo Development List 
Subject: [Pharo-dev] [P9] Large images tag

Hi all

We are starting an effort to review and improve the behavior of pharo in 
presence of super large images. 
I created a special tag to highlight the issues. 
So if you have concerns and found annoying behavior related to slugginess in 
large image, please use this tag. 

We are also looking for misuse of operations fully scanning the memory or kind 
of like allInstances of and others. 

S. 




--- End Message ---

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