Re: [Pharo-dev] Slowness when loading code in Pharo 7?
--- Begin Message --- 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 > wrote: > > > From: Juraj Kubelka > 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 > > > 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 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 >> (chisvasileand...@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 >> > > > > --- End Message ---
Re: [Pharo-dev] Slowness when loading code in Pharo 7?
Hi, In my case I get: pharo 61 * disabled: 0:00:09:39.43 * enabled: 0:00:10:25.173" pharo 70 * disabled: 0:00:12:44.701 * enabled: 0:00:21:21.285 Each time in a clean folder with a new image. All tests are with the current stable vm on High Sierra. Cheers, Andrei On Thu, Oct 4, 2018 at 8:23 AM wrote: > On Wed, 2018-10-03 at 20:08 +0200, Peter Uhnak wrote: > > > > > > On Wed, Oct 3, 2018 at 7:31 PM Juraj Kubelka via Pharo-dev > @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 > > I ran the attached script on my debian 64 bits (disk: slow HDD w/ext4, > cpu: i5 ram: 12gb). Here, the slowdown from 61 to 70 is not as evident > as in your cases. > > It's only me? It can help if others can run the script and report your > results in other computers and OSs. > > Two output examples: > --- > > pharo 61 > * disabled: > 0:00:07:30.783 > * enabled: > 0:00:08:27.931 > > pharo 70 > * disabled: > 0:00:08:24.403 > * enabled: > 0:00:09:12.858 > > --- > > pharo 61 > * disabled: > 0:00:08:16.036 > * enabled: > 0:00:09:21.368 > > pharo 70 > * disabled: > 0:00:08:06.57 > * enabled: > 0:00:10:05.194 > > --- > > pharo 61 > * disabled: > 0:00:07:39.538 > * enabled: > 0:00:08:33.778 > > pharo 70 > * disabled: > 0:00:07:23.528 > * enabled: > 0:00:09:11.453 > > --- > Note: the script removes pharo-local/ before loading the code to > download again everything (and I don't have configured a central repo > in personal settings or something like that). It should be more fair to > compare to have locally cached as much as possible. I tried once and it > was reducing a couple of minutes, but the conclusion was the same. > > Additionally: In both 61 and 70, I browsed the resulting ombu file > (>110 mb), it was not thaat bad... > ~5 seconds when I clicked on the file, and then almost no delay on > scroll and when clicking on a particular change. > > But: The problem was when I clicked on a filter and it started to parse > each change... I waited like 10 minutes and then closed it. No visual > feedback, and looks too inefficient. > > > Martín
Re: [Pharo-dev] Creating a new class using `Class new superclass:` blocks the image in Pharo 7
Thanks a lot, I will check it in this days. On Fri, 5 Oct 2018, 20:28 Andrei Chis, wrote: > Done: > https://pharo.fogbugz.com/f/cases/22547/Creating-a-new-class-using-Class-new-superclass-blocks-the-image-in-Pharo-7 > > Cheers, > Andrei > > On Fri, Oct 5, 2018 at 8:15 PM teso...@gmail.com > wrote: > >> Hi Andrei, would you mind opening an issue for this, making a comment in >> a merged PR does not help to see it. >> >> Thanks >> >> On Fri, 5 Oct 2018, 20:09 Andrei Chis, >> wrote: >> >>> Now I found the comment from >>> https://github.com/pharo-project/pharo/pull/1618. >>> Will add a comment there. >>> >>> On Fri, Oct 5, 2018 at 7:48 PM Andrei Chis >>> wrote: >>> 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 >>>
Re: [Pharo-dev] Creating a new class using `Class new superclass:` blocks the image in Pharo 7
Done: https://pharo.fogbugz.com/f/cases/22547/Creating-a-new-class-using-Class-new-superclass-blocks-the-image-in-Pharo-7 Cheers, Andrei On Fri, Oct 5, 2018 at 8:15 PM teso...@gmail.com wrote: > Hi Andrei, would you mind opening an issue for this, making a comment in a > merged PR does not help to see it. > > Thanks > > On Fri, 5 Oct 2018, 20:09 Andrei Chis, wrote: > >> Now I found the comment from >> https://github.com/pharo-project/pharo/pull/1618. >> Will add a comment there. >> >> On Fri, Oct 5, 2018 at 7:48 PM Andrei Chis >> wrote: >> >>> 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 >>> >>
Re: [Pharo-dev] Creating a new class using `Class new superclass:` blocks the image in Pharo 7
Hi Andrei, would you mind opening an issue for this, making a comment in a merged PR does not help to see it. Thanks On Fri, 5 Oct 2018, 20:09 Andrei Chis, wrote: > Now I found the comment from > https://github.com/pharo-project/pharo/pull/1618. > Will add a comment there. > > On Fri, Oct 5, 2018 at 7:48 PM Andrei Chis > wrote: > >> 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 >> >
Re: [Pharo-dev] Creating a new class using `Class new superclass:` blocks the image in Pharo 7
Now I found the comment from https://github.com/pharo-project/pharo/pull/1618. Will add a comment there. On Fri, Oct 5, 2018 at 7:48 PM Andrei Chis wrote: > 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 >
[Pharo-dev] [Pharo 7.0-dev] Build #1310: 22537 Tag ManifestMultilingualEncodings and related classes in Multilingual-Encodings-Manifest
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%20and%20branch%20Pipeline/job/development/1310/
[Pharo-dev] Creating a new class using `Class new superclass:` blocks the image in Pharo 7
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
Re: [Pharo-dev] Migrating XML support to github/PharoContributions/
Hi monty I really think that we should move to github. I mean really. Let us use a pro VCS - I do not like much git but Iceberg improves the feeling. Stef On Wed, Oct 3, 2018 at 8:28 AM monty wrote: > > It would also prefer an SS3-based STHub, at least as an alternative to GitHub. > ___ > montyos.wordpress.com > > > > Sent: Saturday, September 29, 2018 at 6:43 AM > > From: "Stephane Ducasse" > > To: "Pharo Development List" > > Subject: Re: [Pharo-dev] Migrating XML support to github/PharoContributions/ > > > > Hi Sven > > > > SmalltalkHub is dying. And we will turn it readonly by January. > > Esteban has something else to do that to take care of it. It is a legacy. > > We are about to announce that we cannot create account and projects anymore. > > We are waiting to do that after the mooc. > > Now you want to use Squeaksource or SS3 I do not want. > > I want to use github and I guess that I do not have to explain why for real. > > > > Stef > > > > On Sat, Sep 29, 2018 at 11:27 AM Sven Van Caekenberghe wrote: > > > > > > I think that would be monty, email addresses (CC-ed) > > > > > > mon...@programmer.net > > > > > > I should note that he has been very good at maintaining the XML packages > > > (the specs of which are super complex), and as far as I know, the code > > > works under Pharo 7 ... > > > > > > What does not work for you ? > > > > > > Sven > > > > > > > On 29 Sep 2018, at 10:38, Stephane Ducasse > > > > wrote: > > > > > > > > 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 > > > > > > > > > > > > > > >
Re: [Pharo-dev] Migrating XML support to github/PharoContributions/
Hi Peter If you can go ahead please. I do not remember if I started to migrate PharoExtras/BitmapCharacterSet PharoExtras/OrderPreservingDictionary Now I suggested to Cyril to create a ston file that we archive with all the mappings that we need. So this way we will avoid that every body has to find all the bindings for jb jba jean-baptiste anrut jean-baptiste arnaud Stef On Wed, Oct 3, 2018 at 7:56 AM monty wrote: > > That would be appreciated, if you can do it and preserve the history. > But you also need: > PharoExtras/BitmapCharacterSet > PharoExtras/OrderPreservingDictionary > > ___ > montyos.wordpress.com > > > Sent: Saturday, September 29, 2018 at 6:18 AM > From: "Peter Uhnak" > To: "Pharo Development List" > Cc: monty > Subject: Re: [Pharo-dev] Migrating XML support to github/PharoContributions/ > Hi Stef, > > XMLParser is maintained by monty (I've CCed him). > > > Now the question still remains: who is planning to migrate the XML packages. > > I'd be happy to do that (including preserving the history), unless monty > wants to do it themselves. > > Peter > > On Sat, Sep 29, 2018 at 10:39 AM Stephane Ducasse > wrote: >> >> 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 >>
Re: [Pharo-dev] Conversion of my Libraries/Frameworks to GitHub/Tonel/TravisCI, Part 1
Great! And yet another reminder that all projects should consider moving to git. Norbert > Am 05.10.2018 um 14:05 schrieb Sven Van Caekenberghe : > > Hi, > > I started converting my Libraries/Frameworks to GitHub/Tonel/TravisCI. > So far I did the following: > > https://github.com/svenvc/NeoJSON > https://github.com/svenvc/NeoCSV > https://github.com/svenvc/ztimestamp > https://github.com/svenvc/P3 > https://github.com/svenvc/stamp > https://github.com/svenvc/SimpleRedisClient > https://github.com/svenvc/NeoConsole > > More will follow, in particular Zinc/Zodiac and STON, both of which are more > complex. > > The TravisCI builds now run for Pharo 7 (32 & 64 bits) and Pharo 6.1. > By loading the latest Metacello and Tonel, the code is also loadable in Pharo > 6 or 5. > > After a while I will switch the Catalog entries and declare these repo the > main ones. > > Sven > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > >
[Pharo-dev] [Pharo 7.0-dev] Build #1309: 22538 Tag ManifestFileSystemZip and related classes in FileSystem-Zip package
There is a new Pharo build available! The status of the build #1309 was: FAILURE. The Pull Request #1876 was integrated: "22538 Tag ManifestFileSystemZip and related classes in FileSystem-Zip package" Pull request url: https://github.com/pharo-project/pharo/pull/1876 Issue Url: https://pharo.fogbugz.com/f/cases/22538 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1309/
Re: [Pharo-dev] Conversion of my Libraries/Frameworks to GitHub/Tonel/TravisCI, Part 1
+100 Thank you Sven. On Fri, Oct 5, 2018 at 9:06 AM Sven Van Caekenberghe wrote: > Hi, > > I started converting my Libraries/Frameworks to GitHub/Tonel/TravisCI. > So far I did the following: > > https://github.com/svenvc/NeoJSON > https://github.com/svenvc/NeoCSV > https://github.com/svenvc/ztimestamp > https://github.com/svenvc/P3 > https://github.com/svenvc/stamp > https://github.com/svenvc/SimpleRedisClient > https://github.com/svenvc/NeoConsole > > More will follow, in particular Zinc/Zodiac and STON, both of which are > more complex. > > The TravisCI builds now run for Pharo 7 (32 & 64 bits) and Pharo 6.1. > By loading the latest Metacello and Tonel, the code is also loadable in > Pharo 6 or 5. > > After a while I will switch the Catalog entries and declare these repo the > main ones. > > Sven > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > > >
[Pharo-dev] Conversion of my Libraries/Frameworks to GitHub/Tonel/TravisCI, Part 1
Hi, I started converting my Libraries/Frameworks to GitHub/Tonel/TravisCI. So far I did the following: https://github.com/svenvc/NeoJSON https://github.com/svenvc/NeoCSV https://github.com/svenvc/ztimestamp https://github.com/svenvc/P3 https://github.com/svenvc/stamp https://github.com/svenvc/SimpleRedisClient https://github.com/svenvc/NeoConsole More will follow, in particular Zinc/Zodiac and STON, both of which are more complex. The TravisCI builds now run for Pharo 7 (32 & 64 bits) and Pharo 6.1. By loading the latest Metacello and Tonel, the code is also loadable in Pharo 6 or 5. After a while I will switch the Catalog entries and declare these repo the main ones. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
[Pharo-dev] [Pharo 7.0-dev] Build #1308: 22532-Adding-repository-to-package-via-MonticelloBrowser-is-broken
There is a new Pharo build available! The status of the build #1308 was: FAILURE. The Pull Request #1870 was integrated: "22532-Adding-repository-to-package-via-MonticelloBrowser-is-broken" Pull request url: https://github.com/pharo-project/pharo/pull/1870 Issue Url: https://pharo.fogbugz.com/f/cases/22532 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1308/
[Pharo-dev] [Pharo 7.0-dev] Build #1307: 22520-Deprecate-HistoryCollection
There is a new Pharo build available! The status of the build #1307 was: FAILURE. The Pull Request #1869 was integrated: "22520-Deprecate-HistoryCollection" Pull request url: https://github.com/pharo-project/pharo/pull/1869 Issue Url: https://pharo.fogbugz.com/f/cases/22520 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1307/
[Pharo-dev] [Pharo 7.0-dev] Build #1306: 22533-WelcomeHelp-should-not-have-hardcoded-version
There is a new Pharo build available! The status of the build #1306 was: SUCCESS. The Pull Request #1868 was integrated: "22533-WelcomeHelp-should-not-have-hardcoded-version" Pull request url: https://github.com/pharo-project/pharo/pull/1868 Issue Url: https://pharo.fogbugz.com/f/cases/22533 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1306/
[Pharo-dev] [Pharo 7.0-dev] Build #1305: 22500-LinkedListrejectthenCollect-is-slow
There is a new Pharo build available! The status of the build #1305 was: FAILURE. The Pull Request #1845 was integrated: "22500-LinkedListrejectthenCollect-is-slow" Pull request url: https://github.com/pharo-project/pharo/pull/1845 Issue Url: https://pharo.fogbugz.com/f/cases/22500 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1305/
[Pharo-dev] [Pharo 7.0-dev] Build #1304: 22505-Storing-and-restoring-of-settings-cause-startup-errors
There is a new Pharo build available! The status of the build #1304 was: SUCCESS. The Pull Request #1867 was integrated: "22505-Storing-and-restoring-of-settings-cause-startup-errors" Pull request url: https://github.com/pharo-project/pharo/pull/1867 Issue Url: https://pharo.fogbugz.com/f/cases/22505 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1304/
