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

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

by monty

Oct. 3, 2018

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

by monty

Again, for the record, I have no idea who "monty kamath" (monthkamath@gmailcom) is. Do not send any inquiries to him about those projects. I am the principal maintainer of those projects, but any PharoExtras dev can contribute. And the blog below (which I plan on updating) provides additional information on them. ___ montyos.wordpress.com > Sent: Saturday, September 29, 2018 at 5:26 AM > From: "Sven Van Caekenberghe" <sven(a)stfx.eu> > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Cc: monty <monty2(a)programmer.net>, montykamath(a)gmail.com > Subject: Re: [Pharo-dev] Migrating XML support to github/PharoContributions/ > > I think that would be monty, email addresses (CC-ed) > > monty2(a)programmer.net > montykamath(a)gmail.com > > 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. 3, 2018

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

by Juraj Kubelka

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. 3, 2018

Re: [Pharo-dev] Pharo Downloads are sluggish

by Esteban Maringolo

Now I sent the mail it completed. :-) Esteban A. Maringolo El mar., 2 oct. 2018 a las 19:59, Esteban Maringolo (<emaringolo(a)gmail.com>) escribiÃ³: > I'm reviving this because I can't finish the download of an image using > the latest Pharo launcher. > > I'm timeout errors when attempting to download it. Tried 5 times at > different intervals. > > > [image: image.png] > > Any idea of what could be happening? > > Esteban A. Maringolo > > > El mar., 18 sept. 2018 a las 21:03, Esteban Maringolo (< > emaringolo(a)gmail.com>) escribiÃ³: > >> Is there a reason why the latest version of the builds linked from the >> website are not hosted in some CDN, Amazon S3 or similar? >> >> Maybe in Europe the speed is fast, but where I am (Argentina) it is >> really slow, the screenshot shows 3.5KB/s, it averages 10KB/s, with peaks >> of 40KB/s. >> >> This is an pitiful boarding experience, that will make many cancel it >> even before getting to open the downloaded launcher. >> >> [image: node-pharo.png] >> >> The screenshot shows that is not a problem with my home connection, which >> isn't the fastest but is "normal" for my use cases. >> >> Regards, >> >> Esteban A. Maringolo >> >> ps: When I finished writing this email, this was the progress... >> [image: image.png] >> >

Oct. 2, 2018

Re: [Pharo-dev] Pharo Downloads are sluggish

by Esteban Maringolo

I'm reviving this because I can't finish the download of an image using the latest Pharo launcher. I'm timeout errors when attempting to download it. Tried 5 times at different intervals. [image: image.png] Any idea of what could be happening? Esteban A. Maringolo El mar., 18 sept. 2018 a las 21:03, Esteban Maringolo (<emaringolo(a)gmail.com>) escribiÃ³: > Is there a reason why the latest version of the builds linked from the > website are not hosted in some CDN, Amazon S3 or similar? > > Maybe in Europe the speed is fast, but where I am (Argentina) it is really > slow, the screenshot shows 3.5KB/s, it averages 10KB/s, with peaks of > 40KB/s. > > This is an pitiful boarding experience, that will make many cancel it even > before getting to open the downloaded launcher. > > [image: node-pharo.png] > > The screenshot shows that is not a problem with my home connection, which > isn't the fastest but is "normal" for my use cases. > > Regards, > > Esteban A. Maringolo > > ps: When I finished writing this email, this was the progress... > [image: image.png] >

Oct. 2, 2018

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

by Martin Dias

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. 2, 2018

Re: [Pharo-dev] [ANN] 22477 DelayScheduler cleanup and refactoring [was: Where do we go now ?]

by Stephane Ducasse

Ben I would like to thank you! Simply. Stef On Tue, Oct 2, 2018 at 5:58 AM Ben Coman <btc(a)openinworld.com> wrote: > > On Fri, 13 Apr 2018 at 13:56, Benoit St-Jean via Pharo-users <pharo-users(a)lists.pharo.org> wrote: >> >> Do we really need 8 delay schedulers (DelayMicrosecondScheduler, DelayMillisecondScheduler, DelayNullScheduler, DelayExperimentalSpinScheduler, DelaySpinScheduler, DelayTicklessScheduler, DelayExperimentalCourageousScheduler, DelayExperimentalSemaphoreScheduler) ? > > > I've cleaned the delay scheduling subsystem [1] to condense these alternatives and separate orthogonal functionality. After a couple of reviews this was integrated and made active in last week's Build 1273. Could anyone with test scenarios from previous issues with delays have a bash at stressing the latest build. > > The old(existing) DelaySpinScheduler remains in the system so it can be activated as a point of comparison (System > Settings > System > Delay Scheduler). Pending any adverse reports the final step will be to remove the old hierarchy next week. > > There remain separate mutex and semaphore based schedulers since: > * they differ by only a couple of overridden methods > * their slightly different implementations help highlight the core algorithm > * they provide a simple in-Image example of different synchronisation mechanisms. > * in isolating edge cases its useful to be able to compare results between implementations > > I've retained both microsecond and millisecond operation, > but extracted into "ticker" classes orthogonal to the "scheduling" classes since: > * it makes the core scheduling algorithm independent of time base > * millisecond (or other custom) timebase might(?) be more efficient on smaller 32-bit embedded systems > * tests can now simulate ticker time to avoid tests interfering with system's-active-scheduler VM interaction (which may be the source of some random CI failures) > * delay scheduler tests are now independent of real-time (which may be the source of some random CI failures where delays are affected by varying CI server loads) > * when multi-threaded FFI callbacks become available, may facilitate experimenting with: > * wake-up from native timers > * wake-up of embedded Pharo from the encompassing system > > > Other refactors: > * during system snapshot, save/restore of resumption times was happening at user priority which risks a race condition reported at [2]. *All* modification of resumption times now occurs at timing/highest priority. > > > [1] https://pharo.manuscript.com/f/cases/22477/DelayScheduler-cleanup-and-refac… > [2] https://pharo.manuscript.com/f/cases/18359/

Oct. 2, 2018

Re: [Pharo-dev] Tonel support for Travis CI smalltalkCI for Pharo < 6.1

by Esteban Lorenzano

Btw tonel may be installed in a preLoad, when needed. > On 2 Oct 2018, at 17:43, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > useLatestMetacello will not load Tonel, it will use it if it finds it. > Something we may correct, if needed. > >> On 2 Oct 2018, at 17:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >>> On 2 Oct 2018, at 17:11, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>> >>>> If this does not work, does that then mean that for those versions of Pharo, they cannot load Tonel projects ? >>> >>> Tonel is not in <P6.1. You can try to add >>> >>> #useLatestMetacello : true, >>> >>> to your smalltalkci.ston file, but I believe smalltalkCI actually uses iceberg to load tonel projects... which would be much harder to backport. >>> >>> But try with #useLatestMetacello and let us know. >> >> Thanks for your reply. >> >> That does not seem to work (same result for 6.0 and 5.0, ), >> >> ...RETRY->BaselineOfZTimestamp >> ...RETRY->BaselineOfZTimestamp >> ...FAILED->BaselineOfZTimestamp[31mCould not resolve: BaselineOfZTimestamp [BaselineOfZTimestamp] in /home/travis/smalltalkCI-master/_builds/package-cache filetree:///home/travis/build/svenvc/ztimestamp/repository >> MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: >> >> and extra failures for 7.0 ! >> >> Fetched -> BaselineOfMetacello-CompatibleUserName.1526690791 --- https://github.com/Metacello/metacello.git[master] --- https://github.com/Metacello/metacello.git[master] >> Loaded -> BaselineOfMetacello-CompatibleUserName.1526690791 --- https://github.com/Metacello/metacello.git[master] --- https://github.com/Metacello/metacello.git[master] >> Fetched -> BaselineOfMetacello-CompatibleUserName.1526690791 --- https://github.com/Metacello/metacello.git[master] --- https://github.com/Metacello/metacello.git[master] >> Loaded -> BaselineOfMetacello-CompatibleUserName.1526690791 --- https://github.com/Metacello/metacello.git[master] --- https://github.com/Metacello/metacello.git[master] >> Loading baseline of BaselineOfMetacello...MetacelloNameNotDefinedError: project group, or package named: 'FileTree' not found when used in requires: or includes: field of package: 'Metacello-FileTree' for version: baseline of BaselineOfMetacello. >> MetacelloNameNotDefinedError >> >> >>> Peter >>> >>> On Tue, Oct 2, 2018 at 4:53 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> Hi, >>> >>> I managed to get successful BaselineOf builds out of a GitHub in Tonel format for Pharo 7 (64 & 32 bits) and Pharo 6.1 using Travis CI and smalltalkCI. >>> >>> However, this does not seem to work for Pharo 6 or 5. Is this to be expected ? >>> >>> You can see a build failure here: >>> >>> https://travis-ci.org/svenvc/ztimestamp/builds/436146649 >>> >>> If this does not work, does that then mean that for those versions of Pharo, they cannot load Tonel projects ? This is of course related to my previous question about the reach of Tonel/github. >>> >>> Thx, >>> >>> Sven >> >> >

Oct. 2, 2018

Re: [Pharo-dev] Tonel support for Travis CI smalltalkCI for Pharo < 6.1

by Esteban Lorenzano

useLatestMetacello will not load Tonel, it will use it if it finds it. Something we may correct, if needed. > On 2 Oct 2018, at 17:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> On 2 Oct 2018, at 17:11, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> >>> If this does not work, does that then mean that for those versions of Pharo, they cannot load Tonel projects ? >> >> Tonel is not in <P6.1. You can try to add >> >> #useLatestMetacello : true, >> >> to your smalltalkci.ston file, but I believe smalltalkCI actually uses iceberg to load tonel projects... which would be much harder to backport. >> >> But try with #useLatestMetacello and let us know. > > Thanks for your reply. > > That does not seem to work (same result for 6.0 and 5.0, ), > > ...RETRY->BaselineOfZTimestamp > ...RETRY->BaselineOfZTimestamp > ...FAILED->BaselineOfZTimestamp[31mCould not resolve: BaselineOfZTimestamp [BaselineOfZTimestamp] in /home/travis/smalltalkCI-master/_builds/package-cache filetree:///home/travis/build/svenvc/ztimestamp/repository > MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: > > and extra failures for 7.0 ! > > Fetched -> BaselineOfMetacello-CompatibleUserName.1526690791 --- https://github.com/Metacello/metacello.git[master] --- https://github.com/Metacello/metacello.git[master] > Loaded -> BaselineOfMetacello-CompatibleUserName.1526690791 --- https://github.com/Metacello/metacello.git[master] --- https://github.com/Metacello/metacello.git[master] > Fetched -> BaselineOfMetacello-CompatibleUserName.1526690791 --- https://github.com/Metacello/metacello.git[master] --- https://github.com/Metacello/metacello.git[master] > Loaded -> BaselineOfMetacello-CompatibleUserName.1526690791 --- https://github.com/Metacello/metacello.git[master] --- https://github.com/Metacello/metacello.git[master] > Loading baseline of BaselineOfMetacello...MetacelloNameNotDefinedError: project group, or package named: 'FileTree' not found when used in requires: or includes: field of package: 'Metacello-FileTree' for version: baseline of BaselineOfMetacello. > MetacelloNameNotDefinedError > > >> Peter >> >> On Tue, Oct 2, 2018 at 4:53 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Hi, >> >> I managed to get successful BaselineOf builds out of a GitHub in Tonel format for Pharo 7 (64 & 32 bits) and Pharo 6.1 using Travis CI and smalltalkCI. >> >> However, this does not seem to work for Pharo 6 or 5. Is this to be expected ? >> >> You can see a build failure here: >> >> https://travis-ci.org/svenvc/ztimestamp/builds/436146649 >> >> If this does not work, does that then mean that for those versions of Pharo, they cannot load Tonel projects ? This is of course related to my previous question about the reach of Tonel/github. >> >> Thx, >> >> Sven > >

Oct. 2, 2018

Re: [Pharo-dev] Tonel support for Travis CI smalltalkCI for Pharo < 6.1

by Sven Van Caekenberghe

> On 2 Oct 2018, at 17:11, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > If this does not work, does that then mean that for those versions of Pharo, they cannot load Tonel projects ? > > Tonel is not in <P6.1. You can try to add > > #useLatestMetacello : true, > > to your smalltalkci.ston file, but I believe smalltalkCI actually uses iceberg to load tonel projects... which would be much harder to backport. > > But try with #useLatestMetacello and let us know. Thanks for your reply. That does not seem to work (same result for 6.0 and 5.0, ), ...RETRY->BaselineOfZTimestamp ...RETRY->BaselineOfZTimestamp ...FAILED->BaselineOfZTimestamp[31mCould not resolve: BaselineOfZTimestamp [BaselineOfZTimestamp] in /home/travis/smalltalkCI-master/_builds/package-cache filetree:///home/travis/build/svenvc/ztimestamp/repository MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: and extra failures for 7.0 ! Fetched -> BaselineOfMetacello-CompatibleUserName.1526690791 --- https://github.com/Metacello/metacello.git[master] --- https://github.com/Metacello/metacello.git[master] Loaded -> BaselineOfMetacello-CompatibleUserName.1526690791 --- https://github.com/Metacello/metacello.git[master] --- https://github.com/Metacello/metacello.git[master] Fetched -> BaselineOfMetacello-CompatibleUserName.1526690791 --- https://github.com/Metacello/metacello.git[master] --- https://github.com/Metacello/metacello.git[master] Loaded -> BaselineOfMetacello-CompatibleUserName.1526690791 --- https://github.com/Metacello/metacello.git[master] --- https://github.com/Metacello/metacello.git[master] Loading baseline of BaselineOfMetacello...MetacelloNameNotDefinedError: project group, or package named: 'FileTree' not found when used in requires: or includes: field of package: 'Metacello-FileTree' for version: baseline of BaselineOfMetacello. MetacelloNameNotDefinedError > Peter > > On Tue, Oct 2, 2018 at 4:53 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I managed to get successful BaselineOf builds out of a GitHub in Tonel format for Pharo 7 (64 & 32 bits) and Pharo 6.1 using Travis CI and smalltalkCI. > > However, this does not seem to work for Pharo 6 or 5. Is this to be expected ? > > You can see a build failure here: > > https://travis-ci.org/svenvc/ztimestamp/builds/436146649 > > If this does not work, does that then mean that for those versions of Pharo, they cannot load Tonel projects ? This is of course related to my previous question about the reach of Tonel/github. > > Thx, > > Sven

Oct. 2, 2018