October 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Conversion of my Libraries/Frameworks to GitHub/Tonel/TravisCI, Part 1

by Stephane Ducasse

Excellent! Tx Sven. I love Tonel :). I'm super happy because I dreamt about bootstrap in 2001 and Tonel also and now we get them. On Fri, Oct 5, 2018 at 2:06 PM Sven Van Caekenberghe <sven(a)stfx.eu> 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 > > > > >

Oct. 6, 2018

Re: [Pharo-dev] Slowness when loading code in Pharo 7?

by Alexandre Bergel

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

Oct. 5, 2018

Re: [Pharo-dev] Slowness when loading code in Pharo 7?

by Andrei Chis

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 <tinchodias(a)gmail.com> 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 <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

Oct. 5, 2018

Re: [Pharo-dev] Creating a new class using `Class new superclass:` blocks the image in Pharo 7

by tesonep＠gmail.com

Thanks a lot, I will check it in this days. On Fri, 5 Oct 2018, 20:28 Andrei Chis, <chisvasileandrei(a)gmail.com> wrote: > Done: > https://pharo.fogbugz.com/f/cases/22547/Creating-a-new-class-using-Class-ne… > > Cheers, > Andrei > > On Fri, Oct 5, 2018 at 8:15 PM tesonep(a)gmail.com <tesonep(a)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, <chisvasileandrei(a)gmail.com> >> 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 <chisvasileandrei(a)gmail.com> >>> 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 >>>> >>>

Oct. 5, 2018

Re: [Pharo-dev] Creating a new class using `Class new superclass:` blocks the image in Pharo 7

by Andrei Chis

Done: https://pharo.fogbugz.com/f/cases/22547/Creating-a-new-class-using-Class-ne… Cheers, Andrei On Fri, Oct 5, 2018 at 8:15 PM tesonep(a)gmail.com <tesonep(a)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, <chisvasileandrei(a)gmail.com> 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 <chisvasileandrei(a)gmail.com> >> 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 >>> >>

Oct. 5, 2018

Re: [Pharo-dev] Creating a new class using `Class new superclass:` blocks the image in Pharo 7

by tesonep＠gmail.com

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, <chisvasileandrei(a)gmail.com> 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 <chisvasileandrei(a)gmail.com> > 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 >> >

Oct. 5, 2018

Re: [Pharo-dev] Creating a new class using `Class new superclass:` blocks the image in Pharo 7

by Andrei Chis

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 <chisvasileandrei(a)gmail.com> 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 >

Oct. 5, 2018

[Pharo 7.0-dev] Build #1310: 22537 Tag ManifestMultilingualEncodings and related classes in Multilingual-Encodings-Manifest

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

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…

Oct. 5, 2018

Creating a new class using `Class new superclass:` blocks the image in Pharo 7

by Andrei Chis

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

Oct. 5, 2018

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

by Stephane Ducasse

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 <monty2(a)programmer.net> 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" <stepharo.self(a)gmail.com> > > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > > 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 <sven(a)stfx.eu> wrote: > > > > > > I think that would be monty, email addresses (CC-ed) > > > > > > monty2(a)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 <stepharo.self(a)gmail.com> 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 > > > > > > > > > > > > > > >

Oct. 5, 2018