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

[Pharo 7.0-dev] Build #1316: 22541 Tag and comment ManifestGTSpotter

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

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

Oct. 8, 2018

Esteban's ChangeLog week of 1 October 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 1 October 2018 to 7 October 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=1/10/2018&to=7/10/2018 ChangeLog ========= 5 October 2018: --------------- * I made a couple of backports to Pharo 6.1 * [case: 22517](https://pharo.fogbugz.com/f/cases/22517) : Update ProfStef and fix spelling mistakes * [case: 22535](https://pharo.fogbugz.com/f/cases/22535) : Backport Tonel v1.0.9 to Pharo 6.1 * I finished a "simple" [PR for Calypso](https://github.com/pharo-ide/Calypso/pull/330): It was about better exposing the usage of certain command when using the +cmd+/+ Calypso-Spotter help. Now, this was not obvious because this correspons to a command nobody is using it yet, but it will become important as we enhance discoverability of it :) 2 October 2018: --------------- * Well... I spent the full day debugging on smalltalkCI to send a [new fix](https://github.com/hpi-swa/smalltalkCI/pull/399) to allow the load of projects with packages already installed in the image. This is very useful for us, developing Pharo and their components. * Spec * Calypso * Iceberg * Zinc * etc. And maybe it will be useful for others in the future. cheers! Esteban

Oct. 8, 2018

Re: [Pharo-dev] [squeak-dev] DelayIdleScheduler experiment

by Ben Coman

Hi Tim, Thanks for your feedback On Mon, 8 Oct 2018 at 01:27, tim Rowledge <tim(a)rowledge.org> wrote: > I may be out of date on this but I think that the Cog setup makes it > possible to have a timer check every 2mS by default. The > relinquishProcessor stuff was a definite hack to try to reduce cpu usage on > laptoppy things and I don't think anyone ever expected it to be used for > more than 1mS sleeps. It was one of those "I wonder if this will improve > anything?" ideas that got left in place. > > Surely the ideal would be to > a) as you point out, add this delay to the main delay list > Its not a separate delay. The "activeDelay" is split into separate pieces relinquished around asynchronous I/O like mouse, etc. b) find a way to provide an outside timer to trigger the delay at the top > of the list rather than relying on the vm eventually checking the tick etc. > The key thing is to inform the VM that there are no runnable processes and pause the main-native-thread and heartbeat-thread until the next image-scheduled wakeup time. One alternative may be to adapt #primSignal:atUTCMicroseconds: to be #primSignal:atUTCMicroseconds:idle: > > Interestingly, we have the threaded ticker for many systems as part of the > Cog vm. I don't know if it works on all systems; I do know it would be > 'interesting' to implement on RISC OS, but that's life. A quick look at > unix/sqUnixHeartbeat.c suggests to me that it might be plausible to use > variable length beats Q: does the main-native-thread stop running if the heatbeat stops? > and tie the time to any sooner-than-2mS event wanted. We'd (probably) change Delay handling to behave as if there were always a 1 > or 2mS (fake)delay even if the nearest actual Delay were far beyond that. > I can't follow where you are going with that. If your on a cloud server, you may want to idle for minutes or hours without processing delays, and restarting delays when I/O comes in. cheers -ben > > > On 2018-10-07, at 1:11 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > > 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 > > > > > tim > -- > tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim > Bayard(n): a person armed with the self-confidence of ignorance > > >

Oct. 7, 2018

[Pharo 7.0-dev] Build #1315: 22539 Tag ManifestRPackageCore and related classes in RPackage-Core

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

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

Oct. 7, 2018

[Pharo 7.0-dev] Build #1314: 20344-DualChangeSorter-shows-debug-context-menu

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

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…

Oct. 7, 2018

[Pharo 7.0-dev] Build #1313: 22546 Tag classes in FuzzyMatcher-Tests

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

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…

Oct. 7, 2018

[Pharo 7.0-dev] Build #1312: 22544 Comment File package

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

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…

Oct. 7, 2018

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

by Esteban Lorenzano

Hi, > On 5 Oct 2018, at 19:03, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > 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. It is not just that is a modern vcs tool. I already talked a lot about the technical advantages of using git. But let me put the accent now in some ânon technicalâ reasons: - Imagine if we migrate to github all the projects at sthub, ss, ss3, etcâ¦ There are thousands of projects there (yes, many od them are dead code, but is the same about most of the projects on GitHub too): we will be making something to help re-place Smalltalk in the map (is not of course ensured, but is a small contribution to gain a visibility we do not have now. - you know a lot of companies look at the GitHub profiles of applicants these days, to see how they work on open source projects, etc. Which means having GitHub exposure will also help people willing to start with Pharo (or Smalltalk in general) and do not do it because that will not help them to get a job. One important reason why we selected GitHub and not another provider (personally I prefer GitLab, for example) is precisely that: increase visibility and lower the artificial barriers to adopt Pharo.And of course, this is just a small thing among the huge amount of things to do, but that does not means is not an important one. Esteban > > 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. 7, 2018

DelayIdleScheduler experiment

by Ben Coman

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

Oct. 7, 2018

[Pharo 7.0-dev] Build #1311: 22542 Tag and comment ManifestGTDebugger

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

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…

Oct. 6, 2018