- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #1314: 20344-DualChangeSorter-shows-debug-context-menu
by ci-pharo-ci-jenkins2＠inria.fr Oct. 7, 2018

Oct. 7, 2018

There is a new Pharo build available! The status of the build #1314 was: SUCCESS. The Pull Request #1881 was integrated: "20344-DualChangeSorter-shows-debug-context-menu" Pull request url: https://github.com/pharo-project/pharo/pull/1881 Issue Url: https://pharo.fogbugz.com/f/cases/20344 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1313: 22546 Tag classes in FuzzyMatcher-Tests
by ci-pharo-ci-jenkins2＠inria.fr Oct. 7, 2018

Oct. 7, 2018

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

1 0

[Pharo 7.0-dev] Build #1312: 22544 Comment File package
by ci-pharo-ci-jenkins2＠inria.fr Oct. 7, 2018

Oct. 7, 2018

There is a new Pharo build available! The status of the build #1312 was: FAILURE. The Pull Request #1883 was integrated: "22544 Comment File package" Pull request url: https://github.com/pharo-project/pharo/pull/1883 Issue Url: https://pharo.fogbugz.com/f/cases/22544 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Migrating XML support to github/PharoContributions/
by Stephane Ducasse Oct. 7, 2018

Oct. 7, 2018

Hi I contacted the maintainer (but I'm not sure in fact who it is :) ) about the XML related packages in Pharo extras. XMLParser XMLParserHTML XMLParserStAX XMLSupport XMLWriter XPath I did not get any answer so may be I sent a mail to the wrong email address. Probably. Now the question still remains: who is planning to migrate the XML packages. I was planning to do it but I will not consider history because I do not know how to do it and I do not have the time to do it (sorry). And yes I work the weekends and this is bad and this is not even on Pharo. I was planning to spend some time on the baseline and making sure that we can load everything and run the tests. So let me know. Stef

5 7

DelayIdleScheduler experiment
by Ben Coman Oct. 7, 2018

Oct. 7, 2018

Cross posting since at this level systems are still very similar. I've sometimes wondered about how the idle process relinquishing the CPU interacted with delay scheduling, since they operate at the extreme opposite ends of process priorities. Historically there was... ProcessorScheduler class >> idleProcess [ "A default background process which is invisible." [true] whileTrue: [self relinquishProcessorForMicroseconds: 1000] which had the following performance this for later comparison... (1 to: 10) collect: [:i | [ (Delay forMilliseconds: 1) wait ] timeToRun asMilliSeconds]. ==> "#(2 5 4 2 4 4 2 4 4 3)" To improve battery life yield time Pharo changed this to 50000 in... * https://pharo.fogbugz.com/f/cases/20425/Yield-longer-in-ProcessorScheduler-… * https://github.com/pharo-project/pharo/commit/0b0d12dc but had a negative impact on delays... (1 to: 10) collect: [:i | [ (Delay forMilliseconds: 1) wait ] timeToRun asMilliSeconds]. ==> "#(36 51 50 51 50 51 51 30 50 50)" as reported... https://pharo.fogbugz.com/f/cases/22400/Delays-are-not-working-properly The problem seems to be that #relinquishProcessorForMicroseconds: suspends the main VM thread for a fixed amount during which expired delays cannot be dealt with. I'm not sure of the exact mechanism in the VM but this looks related... Win: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/e2fa2d1/platforms/wi… Mac: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/a8a1dc1/platforms/un… I'm not sure about Linux One idea was to have a setting, but another path is to mix the idle-relinquish into the delay-scheduling to dynamically relinquish up to exactly when the activeDelay expires. After loading... https://github.com/pharo-project/pharo/pull/1887 you can do... DelayIdleTicker installExperiment. (1 to: 10) collect: [:i | [ (Delay forMilliseconds: 1) wait ] timeToRun asMilliSeconds]. ==>"#(1 1 2 2 2 2 2 2 2 2)" which btw is half the latency of the original DelayIdleTicker debug: true. "CPU usage goes way up" DelayIdleTicker uninstall. I'm now seeking: * comment on how this might interact with parts of the VM I'm not familiar with. * help to discover and stress test corner cases. * help to determine if there actually is a benefit and characterize what that is, especially anyone familiar with headless images with reduced UI and I/O events. I was surprised to see the existing system already often showed 0% CPU usage (in Windows). cheers -ben

1 0

[Pharo 7.0-dev] Build #1311: 22542 Tag and comment ManifestGTDebugger
by ci-pharo-ci-jenkins2＠inria.fr Oct. 6, 2018

Oct. 6, 2018

There is a new Pharo build available! The status of the build #1311 was: SUCCESS. The Pull Request #1880 was integrated: "22542 Tag and comment ManifestGTDebugger" Pull request url: https://github.com/pharo-project/pharo/pull/1880 Issue Url: https://pharo.fogbugz.com/f/cases/22542 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Re: [Pharo-dev] Slowness when loading code in Pharo 7?
by Alexandre Bergel Oct. 5, 2018

Oct. 5, 2018

Shouldnât the Metacello>>load be updated to disable EpMonitor? It seems to be an easy fix no? Alexandre > On Oct 2, 2018, at 11:31 PM, Juraj Kubelka via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: Juraj Kubelka <juraj.kubelka(a)icloud.com> > Subject: Re: [Pharo-dev] Slowness when loading code in Pharo 7? > Date: October 2, 2018 at 11:31:59 PM GMT-3 > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > Hi Martin, > > By disabling EpMonitor, the slowdown disappears. > > EpMonitor current disable. > [ Metacello new > baseline: 'GToolkit'; > repository: 'github://feenkcom/gtoolkit/src'; > load. > ] timeToRun "0:00:08:03.504â > > > Cheers, > Juraj > >> On Oct 2, 2018, at 18:14, Martin Dias <tinchodias(a)gmail.com> wrote: >> >> Hi Andrei. You can evaluate "EpMonitor current disable" before loading >> to compare times. >> El mar., 2 de oct. de 2018 a la(s) 11:18, Andrei Chis >> (chisvasileandrei(a)gmail.com) escribiÃ³: >>> >>> Hi, >>> >>> Are there any know slowdowns when loading code in Pharo 7? Usually on my machine (Mac - HighSierra) loading GToolkit in a Pharo 6.1 images takes around 9 minutes. In the latest Pharo 7 it takes 20 minutes. On two other newer laptops running Mac results are similar (15 minutes on Pharo 7 64it, and 7 minutes on Pharo 6.1 64bit). >>> >>> We have the impression that most of the times, the regression happens because of reading sources file. And the sources files are read because of checking Epicea method changes. We have not done a deep research on it, just whenever we do CMD+. it stops in that stage. >>> >>> Cheers, >>> Andrei >> > > > >

1 0

Re: [Pharo-dev] Slowness when loading code in Pharo 7?
by Peter Uhnak Oct. 5, 2018

Oct. 5, 2018

On Wed, Oct 3, 2018 at 7:31 PM Juraj Kubelka via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > Hi! > > I did the same measurement for Pharo 6.1. To summarize it I have those > results: > > By executing: > > -=-=-=- > EpMonitor current disable. > [ Metacello new > baseline: 'GToolkit'; > repository: 'github://feenkcom/gtoolkit/src'; > load. > ] timeToRun > -=-=-=- > > Pharo 6.1 64bit macOS: 6 minutes > Pharo 7.0 64bit macOS: 8 minutes > > With EpMonitor current enabled it is: > > Pharo 6.1 64bit macOS: 7 minutes > Pharo 7.0 64bit macOS: 15 minutes > So nice... I was just trying to install GToolkit in P6.1 on Windows (but with updated Iceberg)... it took over 1.5 hours (SmaCC was probably 30 minutes by itself), and then the image crashed... really looking forward to pre-made images :) Peter

3 2

Creating a new class using `Class new superclass:` blocks the image in Pharo 7
by Andrei Chis Oct. 5, 2018

Oct. 5, 2018

Hi, Executed in the latest Pharo 7 image (Pharo-7.0.0+alpha.build.1310.sha.a454977bb3d55bc4fcca3a57ac2fafcf137c0f30 (64 Bit)) the code below blocks the image (both with latest and stable vm on MacOs HighSierra). The vm does not crash but gets into a "Not Responding" state and does not get out: Class new superclass: GLMTransmission; setFormat: GLMTransmission format; classLayout: GLMTransmission classLayout copy; yourself Code like this is used in Moose in some tests and in SmaCC in the rewrite engine: Class new superclass: SmaCCRewriteMatchContext; setFormat: SmaCCRewriteMatchContext format; classLayout: SmaCCRewriteMatchContext classLayout copy; yourself. This worked in Pharo 6. Bug or here should be a different way to do this? Cheers, Andrei

2 4

[Pharo 7.0-dev] Build #1310: 22537 Tag ManifestMultilingualEncodings and related classes in Multilingual-Encodings-Manifest
by ci-pharo-ci-jenkins2＠inria.fr Oct. 5, 2018

Oct. 5, 2018

There is a new Pharo build available! The status of the build #1310 was: SUCCESS. The Pull Request #1875 was integrated: "22537 Tag ManifestMultilingualEncodings and related classes in Multilingual-Encodings-Manifest" Pull request url: https://github.com/pharo-project/pharo/pull/1875 Issue Url: https://pharo.fogbugz.com/f/cases/22537 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0