March 2017 - Pharo-dev - lists.pharo.org

[gsoc] Advances in Code Quality

by Myroslava Romaniuk

Hello, I'm Myroslava and I'm studying Computer Science at the Ukrainian Catholic University in Lviv. As part of my Google Summer of Code project I'm going to work on the quality of code in Pharo. This <https://docs.google.com/document/d/1cX7VJ2QZejq_Cu6Ur28UCiUwzSD-Bu8GgSDqECi…> is my proposal draft, and I would really appreciate some feedback, comments, suggestions and so on. Thanks!

March 31, 2017

Re: [Pharo-dev] Google Summer of Code - New Trait Implementation

by Stephane Ducasse

go go go go On Fri, Mar 31, 2017 at 2:14 PM, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Hello, > > I am planning in working in a new Traits implementation, the idea is to > have an implementation that can work as a loadable module. So you can use > it or not as another library. > > Also the idea is improve the support of all the tools by improving the > polymorphism between traits and classes. Clean up a little the API and add > support to have stateful traits. > > I would like to know if you have any suggestion or have a problem that I > could try to solve. I have been talking with some people in the community > to get ideas, but always having more opinions is better. > > Thanks in advance. > Pablo > > > -- > Pablo Tesone. > tesonep(a)gmail.com >

March 31, 2017

Re: [Pharo-dev] the new "fixed" compactor VM has FT broken...

by Stephane Ducasse

Peter I took the latest mac VM and Moose 6.1 and I used your example then I played during 15 min with all the roassal examples and I cannot reproduce but I'm on mac. On Fri, Mar 31, 2017 at 2:23 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Tx peter! > I really really sorry for this state of affair. > I would like to tell you that I thank you for all the feedback you sent. > Please continue. > I imagine what it is to get a system that blow up under your fingers. > I'm always trying to work with the alpha version (because I attract bugs) > I got some crashes playing with roassal - but I updated to the latest vm > and trying. > > Can you sync with esteban so that he can access your setup? And yes we are > burning > esteban on this.... We should pay attention that our faery does not get > too exhausted :). > > Stef > > > On Fri, Mar 31, 2017 at 1:10 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> >> >> On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >>> BTWâ¦ I just checked Latest VM with a Pharo 5.0 (50771), and FT2 DOES NOT >>> CRASHESâ¦ and it looks working fine, just installed somethings, etc. so I >>> cannot be sure it will remain like that, but I can tell you: FT2 fonts are >>> working fine in Windows (tested in 7) and Pharo 5.0 *with* latest VM. >>> >>> So, all this discussion is informative, but the mail that originates it >>> can be reviewed :) >>> >> >> No, this is still broken, even in Pharo 6 (with the latest VM). Maybe >> it's yet another cairo issue? But it complains about FT fonts... >> >> I did mention that it crashed on Athens canvas, so e.g. any Roassal >> presentation that contains text >> >> v := RTView new. >> v add: (RTLabel new elementOn: '-_-'). >> v >> >> >> â >> >> Or running AthensSurfaceExamples class>>exampleDrawText >> >> >> >> >> In the past 15 months there was not a single week when the VM would just >> work without crashing or failing, and seeing that Pharo 6/lastest VM one >> day before release still doesn't work makes me really question why I still >> put up with this. >> >> Peter >> >> >> >>> >>> Esteban >>> >>> >>> On 29 Mar 2017, at 14:43, phil(a)highoctane.be wrote: >>> >>> We cannot work in 5.0 professionally with the VM released at the time. >>> I am also using an intermediate VM thing to do the job. >>> >>> That is a pain. And not helping me push more Pharo to sysadmin people >>> because they cannot have a stable reference point. >>> >>> Phil >>> >>> On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm(a)gmail.com >>> > wrote: >>> >>>> >>>> > On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>> > >>>> > On Wed, Mar 29, 2017 at 11:05:28AM +0200, Esteban Lorenzano wrote: >>>> >> wellâ¦ >>>> >> >>>> >> Latest VM is intended to work with latest Pharo, not with older >>>> versions. >>>> >> Latest VM is *always* an experimental/unstable VM that needs to be >>>> consideredâ¦ that, experimental and unstable. Otherwise there would not be >>>> point on having the distinction between stable/latest, isnât? >>>> >> >>>> > >>>> >> So, no, Latest VM (which can also be known as âalpha vmâ) has not >>>> broken FT, it works fine in Pharo 6.0, which can also be know as âPharo 6.0 >>>> Alphaâ). >>>> >> >>>> >> BTWâ¦ Thatâs why in zeroconf you cannot download a âlatest vm for >>>> Pharo 5â. >>>> >> >>>> >> Of course, you can live at the edge, but that doesnât means >>>> something is broken when something fails if premises are not fulfilled :) >>>> > >>>> > Well considering VM for Pharo 5 never worked for me properly, whether >>>> it was crashing on BitBlt/Cairo, FT, or who knows what, I don't really have >>>> a choice but to use the latest. If there is a better way then I am all >>>> ears, constantly dealing with crashing VM when I need to get work done is >>>> extremely frustrating... >>>> > >>>> > Also I was under the impression that newer VM should work with older >>>> images, with the only exception being Cog/Spur change. Or should I have six >>>> different VMs and Pharo Launcher with six different VM configurations? >>>> >>>> we moved the paradigm a couple of years ago: each Pharo version comes >>>> with his own VM version (Other smalltalks do that too). >>>> Being infinite backward compatible is a lot of pain :) >>>> >>>> so yes, PharoLauncher needs to adapt to itâ¦ I added that requirement >>>> for PharoLauncher: you ship with latest stable but you can always download >>>> newers or olders (this is not yet implemented, is just a requirement I >>>> addedâ¦ well, couple of years ago when we changed the way we wanted VMs to >>>> work). >>>> >>>> Esteban >>>> >>>> > >>>> > Peter >>>> > >>>> >> >>>> >> Said thatâ¦ I had no problems with Latest VM + Pharo 6.0 (and they >>>> may happen, since this is all alfa :P) >>>> >> >>>> >> I donât know if âworkarounding the VMâ (by renaming libfreetype) >>>> will work, but if that works, ONCE we move latest vm to stable status we >>>> can consider backporting it to Pharo 5. >>>> >> >>>> >> Esteban >>>> >> >>>> >>> On 29 Mar 2017, at 10:37, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>> >>> >>>> >>> The new "fixed" compactor VM has broken FT... >>>> >>> >>>> >>> So any text drawn on Athens canvas results in red cross... >>>> >>> >>>> >>> Error in... >>>> >>> >>>> >>> CairoFontFace class>>primFtFace:loadFlags: >>>> >>> >>>> >>> 'Unable to find function address' >>>> >>> >>>> >>> Apparently because someone renamed libfreetype-6.dll to >>>> libfreetype.dll >>>> >>> >>>> >>> (Windows VM latest, Pharo 5) >>>> >>> >>>> >> >>>> >> >>>> > >>>> >>>> >>>> >>> >>> >> >

March 31, 2017

Re: [Pharo-dev] the new "fixed" compactor VM has FT broken...

by Stephane Ducasse

Tx peter! I really really sorry for this state of affair. I would like to tell you that I thank you for all the feedback you sent. Please continue. I imagine what it is to get a system that blow up under your fingers. I'm always trying to work with the alpha version (because I attract bugs) I got some crashes playing with roassal - but I updated to the latest vm and trying. Can you sync with esteban so that he can access your setup? And yes we are burning esteban on this.... We should pay attention that our faery does not get too exhausted :). Stef On Fri, Mar 31, 2017 at 1:10 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> BTWâ¦ I just checked Latest VM with a Pharo 5.0 (50771), and FT2 DOES NOT >> CRASHESâ¦ and it looks working fine, just installed somethings, etc. so I >> cannot be sure it will remain like that, but I can tell you: FT2 fonts are >> working fine in Windows (tested in 7) and Pharo 5.0 *with* latest VM. >> >> So, all this discussion is informative, but the mail that originates it >> can be reviewed :) >> > > No, this is still broken, even in Pharo 6 (with the latest VM). Maybe it's > yet another cairo issue? But it complains about FT fonts... > > I did mention that it crashed on Athens canvas, so e.g. any Roassal > presentation that contains text > > v := RTView new. > v add: (RTLabel new elementOn: '-_-'). > v > > > â > > Or running AthensSurfaceExamples class>>exampleDrawText > > > > > In the past 15 months there was not a single week when the VM would just > work without crashing or failing, and seeing that Pharo 6/lastest VM one > day before release still doesn't work makes me really question why I still > put up with this. > > Peter > > > >> >> Esteban >> >> >> On 29 Mar 2017, at 14:43, phil(a)highoctane.be wrote: >> >> We cannot work in 5.0 professionally with the VM released at the time. >> I am also using an intermediate VM thing to do the job. >> >> That is a pain. And not helping me push more Pharo to sysadmin people >> because they cannot have a stable reference point. >> >> Phil >> >> On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >>> >>> > On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>> > >>> > On Wed, Mar 29, 2017 at 11:05:28AM +0200, Esteban Lorenzano wrote: >>> >> wellâ¦ >>> >> >>> >> Latest VM is intended to work with latest Pharo, not with older >>> versions. >>> >> Latest VM is *always* an experimental/unstable VM that needs to be >>> consideredâ¦ that, experimental and unstable. Otherwise there would not be >>> point on having the distinction between stable/latest, isnât? >>> >> >>> > >>> >> So, no, Latest VM (which can also be known as âalpha vmâ) has not >>> broken FT, it works fine in Pharo 6.0, which can also be know as âPharo 6.0 >>> Alphaâ). >>> >> >>> >> BTWâ¦ Thatâs why in zeroconf you cannot download a âlatest vm for >>> Pharo 5â. >>> >> >>> >> Of course, you can live at the edge, but that doesnât means something >>> is broken when something fails if premises are not fulfilled :) >>> > >>> > Well considering VM for Pharo 5 never worked for me properly, whether >>> it was crashing on BitBlt/Cairo, FT, or who knows what, I don't really have >>> a choice but to use the latest. If there is a better way then I am all >>> ears, constantly dealing with crashing VM when I need to get work done is >>> extremely frustrating... >>> > >>> > Also I was under the impression that newer VM should work with older >>> images, with the only exception being Cog/Spur change. Or should I have six >>> different VMs and Pharo Launcher with six different VM configurations? >>> >>> we moved the paradigm a couple of years ago: each Pharo version comes >>> with his own VM version (Other smalltalks do that too). >>> Being infinite backward compatible is a lot of pain :) >>> >>> so yes, PharoLauncher needs to adapt to itâ¦ I added that requirement for >>> PharoLauncher: you ship with latest stable but you can always download >>> newers or olders (this is not yet implemented, is just a requirement I >>> addedâ¦ well, couple of years ago when we changed the way we wanted VMs to >>> work). >>> >>> Esteban >>> >>> > >>> > Peter >>> > >>> >> >>> >> Said thatâ¦ I had no problems with Latest VM + Pharo 6.0 (and they may >>> happen, since this is all alfa :P) >>> >> >>> >> I donât know if âworkarounding the VMâ (by renaming libfreetype) will >>> work, but if that works, ONCE we move latest vm to stable status we can >>> consider backporting it to Pharo 5. >>> >> >>> >> Esteban >>> >> >>> >>> On 29 Mar 2017, at 10:37, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>> >>> >>> >>> The new "fixed" compactor VM has broken FT... >>> >>> >>> >>> So any text drawn on Athens canvas results in red cross... >>> >>> >>> >>> Error in... >>> >>> >>> >>> CairoFontFace class>>primFtFace:loadFlags: >>> >>> >>> >>> 'Unable to find function address' >>> >>> >>> >>> Apparently because someone renamed libfreetype-6.dll to >>> libfreetype.dll >>> >>> >>> >>> (Windows VM latest, Pharo 5) >>> >>> >>> >> >>> >> >>> > >>> >>> >>> >> >> >

March 31, 2017

Google Summer of Code - New Trait Implementation

by tesonep＠gmail.com

Hello, I am planning in working in a new Traits implementation, the idea is to have an implementation that can work as a loadable module. So you can use it or not as another library. Also the idea is improve the support of all the tools by improving the polymorphism between traits and classes. Clean up a little the API and add support to have stateful traits. I would like to know if you have any suggestion or have a problem that I could try to solve. I have been talking with some people in the community to get ideas, but always having more opinions is better. Thanks in advance. Pablo -- Pablo Tesone. tesonep(a)gmail.com

March 31, 2017

Re: [Pharo-dev] the new "fixed" compactor VM has FT broken...

by Peter UhnÃ¡k

On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > BTWâ¦ I just checked Latest VM with a Pharo 5.0 (50771), and FT2 DOES NOT > CRASHESâ¦ and it looks working fine, just installed somethings, etc. so I > cannot be sure it will remain like that, but I can tell you: FT2 fonts are > working fine in Windows (tested in 7) and Pharo 5.0 *with* latest VM. > > So, all this discussion is informative, but the mail that originates it > can be reviewed :) > No, this is still broken, even in Pharo 6 (with the latest VM). Maybe it's yet another cairo issue? But it complains about FT fonts... I did mention that it crashed on Athens canvas, so e.g. any Roassal presentation that contains text v := RTView new. v add: (RTLabel new elementOn: '-_-'). v â Or running AthensSurfaceExamples class>>exampleDrawText In the past 15 months there was not a single week when the VM would just work without crashing or failing, and seeing that Pharo 6/lastest VM one day before release still doesn't work makes me really question why I still put up with this. Peter > > Esteban > > > On 29 Mar 2017, at 14:43, phil(a)highoctane.be wrote: > > We cannot work in 5.0 professionally with the VM released at the time. > I am also using an intermediate VM thing to do the job. > > That is a pain. And not helping me push more Pharo to sysadmin people > because they cannot have a stable reference point. > > Phil > > On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> >> > On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> > >> > On Wed, Mar 29, 2017 at 11:05:28AM +0200, Esteban Lorenzano wrote: >> >> wellâ¦ >> >> >> >> Latest VM is intended to work with latest Pharo, not with older >> versions. >> >> Latest VM is *always* an experimental/unstable VM that needs to be >> consideredâ¦ that, experimental and unstable. Otherwise there would not be >> point on having the distinction between stable/latest, isnât? >> >> >> > >> >> So, no, Latest VM (which can also be known as âalpha vmâ) has not >> broken FT, it works fine in Pharo 6.0, which can also be know as âPharo 6.0 >> Alphaâ). >> >> >> >> BTWâ¦ Thatâs why in zeroconf you cannot download a âlatest vm for Pharo >> 5â. >> >> >> >> Of course, you can live at the edge, but that doesnât means something >> is broken when something fails if premises are not fulfilled :) >> > >> > Well considering VM for Pharo 5 never worked for me properly, whether >> it was crashing on BitBlt/Cairo, FT, or who knows what, I don't really have >> a choice but to use the latest. If there is a better way then I am all >> ears, constantly dealing with crashing VM when I need to get work done is >> extremely frustrating... >> > >> > Also I was under the impression that newer VM should work with older >> images, with the only exception being Cog/Spur change. Or should I have six >> different VMs and Pharo Launcher with six different VM configurations? >> >> we moved the paradigm a couple of years ago: each Pharo version comes >> with his own VM version (Other smalltalks do that too). >> Being infinite backward compatible is a lot of pain :) >> >> so yes, PharoLauncher needs to adapt to itâ¦ I added that requirement for >> PharoLauncher: you ship with latest stable but you can always download >> newers or olders (this is not yet implemented, is just a requirement I >> addedâ¦ well, couple of years ago when we changed the way we wanted VMs to >> work). >> >> Esteban >> >> > >> > Peter >> > >> >> >> >> Said thatâ¦ I had no problems with Latest VM + Pharo 6.0 (and they may >> happen, since this is all alfa :P) >> >> >> >> I donât know if âworkarounding the VMâ (by renaming libfreetype) will >> work, but if that works, ONCE we move latest vm to stable status we can >> consider backporting it to Pharo 5. >> >> >> >> Esteban >> >> >> >>> On 29 Mar 2017, at 10:37, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> >>> >> >>> The new "fixed" compactor VM has broken FT... >> >>> >> >>> So any text drawn on Athens canvas results in red cross... >> >>> >> >>> Error in... >> >>> >> >>> CairoFontFace class>>primFtFace:loadFlags: >> >>> >> >>> 'Unable to find function address' >> >>> >> >>> Apparently because someone renamed libfreetype-6.dll to >> libfreetype.dll >> >>> >> >>> (Windows VM latest, Pharo 5) >> >>> >> >> >> >> >> > >> >> >> > >

March 31, 2017

Re: [Pharo-dev] Iceberg with SSH on Linux

by Ben Coman

On Fri, Mar 31, 2017 at 4:54 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > On 31 March 2017 at 10:14, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Eliot, > > > > On 31 March 2017 at 05:31, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> > >> > >> On Thu, Mar 30, 2017 at 8:20 PM, Eliot Miranda <eliot.miranda(a)gmail.com > > > >> wrote: > >>> > >>> Hi Alistair, > >>> > >>> On Thu, Mar 30, 2017 at 9:32 AM, Alistair Grant <akgrant0710(a)gmail.com > > > >>> wrote: > >>>> > >>>> Hi Eliot, > >>>> > >>>> On 30 March 2017 at 18:15, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >>>> > > >>>> > On Mar 30, 2017, at 2:58 AM, Pavel Krivanek < > pavel.krivanek(a)gmail.com> > >>>> > wrote: > >>>> >> > >>>> >> Yes, the same priority. See: > >>>> >> > >>>> >> The VM may have issues with clock jitter due to the heartbeat > thread > >>>> >> not running at elevated priority. > >>>> > > >>>> > > >>>> > It better /not/ be. This is wrong. The heartbeat thread /must/ > run at > >>>> > a > >>>> > higher priority for the VM not to lock up when it becomes compute > >>>> > bound. I > >>>> > thought the resolution was that the VM /will/ try and raise the > >>>> > priority if > >>>> > the heartbeat thread but will /not/ exit if it fails. This is > /very/ > >>>> > different from not trying to raise the priority at all. > >>>> > >>>> As Esteban wrote, the vm is trying to raise the priority. You can see > >>>> the change at: > >>>> > >>>> > >>>> https://github.com/pharo-project/pharo-vm/commit/ > 32f321583c69ca27e61ffaff6decc2a3e4b6ca5e > >>>> > >>>> I'd like to just make sure I understand your comment correctly: > >>>> > >>>> Are you saying that the VM will lock up if it gets in to, e.g., an > >>>> endless loop, so that Ctrl-. fails to interrupt. Or is it more > >>>> serious than that? Can the VM become locked up for just a long > >>>> running process (I guess it will be locked while the process is > >>>> running, but will eventually go back to normal once the process > >>>> completes)? > >>> > >>> > >>> The issue is that delays are recognized by periodically checking the > time > >>> against the next delay expiry. It is the heartbeat thread that causes > JITed > >>> Smalltalk code to break out of its execution to check for events, > including > >>> the next delay expiry. So if the heartbeat is at the same priority as > the > >>> JITed Smalltalk code, and the Smalltalk code is in tight enough a loop > (one > >>> that does not provoke a GC, does not do any process switches) the > heartbeat > >>> thread will not run and the delay expiry will never be tested for. > >> > >> > >> Something like the following should run forever if the heartbeat has the > >> same priority as the VM thread (and should be tried in a headless > >> configuration too): > >> > >> [| infiniteLoop | > >> infiniteLoop := [| sum | sum := 0. [sum < 10] whileTrue: [sum := sum + > (sum > >> even ifTrue: [1] ifFalse: [-1])]] newProcess. > >> infiniteLoop resume. > >> Processor activeProcess priority: Processor activePriority + 1. > >> (Delay forSeconds: 1) wait. > >> infiniteLoop terminate. > >> Processor activeProcess priority: Processor activePriority - 1] > timeToRun > >> 1001 > > > > I get the same result regardless of thread priority, UI or headless. > > I've just shown the output from the headless VM with the heartbeat > > thread at normal priority (I haven't incorporated Ben's comments in to > > the text yet): > > > > > > $ pharo Pharo.image --quit ~/pharo6/pharo/heartbeatTest.st > > pthread_setschedparam failed: Operation not permitted > > This VM uses a separate heartbeat thread to update the internal clock. > > For best operation, this thread should run at real-time priority, > > however the VM was unable to change the priority. The effect is that > > the clock may experience some jitter. To avoid clock jitter, please > > create the appropriate configuration file in /etc/security/limits.d > > by executing the following: > > > > cat <<END | sudo tee /etc/security/limits.d/pharo.conf > > * hard rtprio 2 > > * soft rtprio 2 > > END > > > > You will need to log out and log back in for the limits to take effect. > > For more information please see > > https://github.com/OpenSmalltalk/opensmalltalk- > vm/releases/tag/r3732#linux > > Time to run: 0:00:00:01 > > > > > > heartbeatTest.st: > > > > | time | > > > > time := [| infiniteLoop | > > infiniteLoop := [| sum | sum := 0. [sum < 10] whileTrue: [sum := sum + > > (sum even ifTrue: [1] ifFalse: [-1])]] newProcess. > > infiniteLoop resume. > > Processor activeProcess priority: Processor activePriority + 1. > > (Delay forSeconds: 1) wait. > > infiniteLoop terminate. > > Processor activeProcess priority: Processor activePriority - 1] > timeToRun. > > FileStream stdout > > nextPutAll: 'Time to run: '; > > nextPutAll: time printString; cr. > > time > > P.S It would be great is someone could reproduce this. Eliot and Ben's > descriptions make sense, so I can't help feeling I've done something > stupid here. > > Eliot, thanks for the test case. Using VM pharo-linux-i386threaded-201703281011 on an idle PC with pharo UI I get timeToRun of "0:00:00:01.001". >From the command line... $ vi heatbeatTestIdle.st | time | time := [ (Delay forSeconds: 1) wait ] timeToRun. FileStream stdout nextPutAll: 'Time to run: '; nextPutAll: time printString; cr. $ pharo-linux-i386threaded-201703281011/lib/pharo/5.0-201703281011/pharo \ 60453.image `pwd`/heatbeatTestIdle.st Time to run: 0:00:00:01.002 $ pharo-linux-i386threaded-201703281011/lib/pharo/5.0-201703281011/pharo \ 60453.image `pwd`/heatbeatTest.st Time to run: 0:00:00:01.001 Stressing the system per my test.c from [1] compiled to `fib`, on my four CPUs starting fifteen processes doing fibonnachi of 10E10 spread across three process priorities 0, 1 & 19, and then running heatbeatTest.st. $ N=$((10**10)) ; for NPROC in 1 2 3 4 5 ; do (./fib 19 $N &) && (./fib 1 $N &) && (./fib 0 $N &) ; done && \ pharo-linux-i386threaded-201703281011/lib/pharo/5.0-201703281011/pharo \ 60453.image `pwd`/heatbeatTest.st Time to run: 0:00:00:01.002 14758 @ 0 ==> execution time 23:341844995 14734 @ 0 ==> execution time 23:957766684 14746 @ 0 ==> execution time 24:425043841 14740 @ 0 ==> execution time 24:458788284 14752 @ 0 ==> execution time 24:899062965 14750 @ 1 ==> execution time 26:118315887 14732 @ 1 ==> execution time 26:302822374 14756 @ 1 ==> execution time 26:398550194 14738 @ 1 ==> execution time 26:605458137 14744 @ 1 ==> execution time 26:655449934 14736 @ 19 ==> execution time 36:799776693 14754 @ 19 ==> execution time 37:564087310 14742 @ 19 ==> execution time 39:511492537 14748 @ 19 ==> execution time 39:714399199 14730 @ 19 ==> execution time 39:748212349 Output format is... PID @ nicePriority ==> execution time After output completes, `cat /proc/loadavg` reports a 1 minute load average (i.e. average processes waiting) of 6.36. So to me it looks like the un-raised *static* priority heatbeat-thread is working okay :) cheers -ben [1] http://forum.world.st/Unix-heartbeat-thread-vs-itimer-tp4928943p4938456.html

March 31, 2017

Re: [Pharo-dev] Iceberg with SSH on Linux

by Alistair Grant

On 31 March 2017 at 10:14, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Eliot, > > On 31 March 2017 at 05:31, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> >> On Thu, Mar 30, 2017 at 8:20 PM, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >>> >>> Hi Alistair, >>> >>> On Thu, Mar 30, 2017 at 9:32 AM, Alistair Grant <akgrant0710(a)gmail.com> >>> wrote: >>>> >>>> Hi Eliot, >>>> >>>> On 30 March 2017 at 18:15, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>> > >>>> > On Mar 30, 2017, at 2:58 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>> > wrote: >>>> >> >>>> >> Yes, the same priority. See: >>>> >> >>>> >> The VM may have issues with clock jitter due to the heartbeat thread >>>> >> not running at elevated priority. >>>> > >>>> > >>>> > It better /not/ be. This is wrong. The heartbeat thread /must/ run at >>>> > a >>>> > higher priority for the VM not to lock up when it becomes compute >>>> > bound. I >>>> > thought the resolution was that the VM /will/ try and raise the >>>> > priority if >>>> > the heartbeat thread but will /not/ exit if it fails. This is /very/ >>>> > different from not trying to raise the priority at all. >>>> >>>> As Esteban wrote, the vm is trying to raise the priority. You can see >>>> the change at: >>>> >>>> >>>> https://github.com/pharo-project/pharo-vm/commit/32f321583c69ca27e61ffaff6d… >>>> >>>> I'd like to just make sure I understand your comment correctly: >>>> >>>> Are you saying that the VM will lock up if it gets in to, e.g., an >>>> endless loop, so that Ctrl-. fails to interrupt. Or is it more >>>> serious than that? Can the VM become locked up for just a long >>>> running process (I guess it will be locked while the process is >>>> running, but will eventually go back to normal once the process >>>> completes)? >>> >>> >>> The issue is that delays are recognized by periodically checking the time >>> against the next delay expiry. It is the heartbeat thread that causes JITed >>> Smalltalk code to break out of its execution to check for events, including >>> the next delay expiry. So if the heartbeat is at the same priority as the >>> JITed Smalltalk code, and the Smalltalk code is in tight enough a loop (one >>> that does not provoke a GC, does not do any process switches) the heartbeat >>> thread will not run and the delay expiry will never be tested for. >> >> >> Something like the following should run forever if the heartbeat has the >> same priority as the VM thread (and should be tried in a headless >> configuration too): >> >> [| infiniteLoop | >> infiniteLoop := [| sum | sum := 0. [sum < 10] whileTrue: [sum := sum + (sum >> even ifTrue: [1] ifFalse: [-1])]] newProcess. >> infiniteLoop resume. >> Processor activeProcess priority: Processor activePriority + 1. >> (Delay forSeconds: 1) wait. >> infiniteLoop terminate. >> Processor activeProcess priority: Processor activePriority - 1] timeToRun >> 1001 > > I get the same result regardless of thread priority, UI or headless. > I've just shown the output from the headless VM with the heartbeat > thread at normal priority (I haven't incorporated Ben's comments in to > the text yet): > > > $ pharo Pharo.image --quit ~/pharo6/pharo/heartbeatTest.st > pthread_setschedparam failed: Operation not permitted > This VM uses a separate heartbeat thread to update the internal clock. > For best operation, this thread should run at real-time priority, > however the VM was unable to change the priority. The effect is that > the clock may experience some jitter. To avoid clock jitter, please > create the appropriate configuration file in /etc/security/limits.d > by executing the following: > > cat <<END | sudo tee /etc/security/limits.d/pharo.conf > * hard rtprio 2 > * soft rtprio 2 > END > > You will need to log out and log back in for the limits to take effect. > For more information please see > https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux > Time to run: 0:00:00:01 > > > heartbeatTest.st: > > | time | > > time := [| infiniteLoop | > infiniteLoop := [| sum | sum := 0. [sum < 10] whileTrue: [sum := sum + > (sum even ifTrue: [1] ifFalse: [-1])]] newProcess. > infiniteLoop resume. > Processor activeProcess priority: Processor activePriority + 1. > (Delay forSeconds: 1) wait. > infiniteLoop terminate. > Processor activeProcess priority: Processor activePriority - 1] timeToRun. > FileStream stdout > nextPutAll: 'Time to run: '; > nextPutAll: time printString; cr. > time P.S It would be great is someone could reproduce this. Eliot and Ben's descriptions make sense, so I can't help feeling I've done something stupid here. Cheers, Alistair

March 31, 2017

Re: [Pharo-dev] Iceberg with SSH on Linux

by Alistair Grant

Hi Eliot, On 31 March 2017 at 05:31, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Thu, Mar 30, 2017 at 8:20 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: >> >> Hi Alistair, >> >> On Thu, Mar 30, 2017 at 9:32 AM, Alistair Grant <akgrant0710(a)gmail.com> >> wrote: >>> >>> Hi Eliot, >>> >>> On 30 March 2017 at 18:15, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> > >>> > On Mar 30, 2017, at 2:58 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>> > wrote: >>> >> >>> >> Yes, the same priority. See: >>> >> >>> >> The VM may have issues with clock jitter due to the heartbeat thread >>> >> not running at elevated priority. >>> > >>> > >>> > It better /not/ be. This is wrong. The heartbeat thread /must/ run at >>> > a >>> > higher priority for the VM not to lock up when it becomes compute >>> > bound. I >>> > thought the resolution was that the VM /will/ try and raise the >>> > priority if >>> > the heartbeat thread but will /not/ exit if it fails. This is /very/ >>> > different from not trying to raise the priority at all. >>> >>> As Esteban wrote, the vm is trying to raise the priority. You can see >>> the change at: >>> >>> >>> https://github.com/pharo-project/pharo-vm/commit/32f321583c69ca27e61ffaff6d… >>> >>> I'd like to just make sure I understand your comment correctly: >>> >>> Are you saying that the VM will lock up if it gets in to, e.g., an >>> endless loop, so that Ctrl-. fails to interrupt. Or is it more >>> serious than that? Can the VM become locked up for just a long >>> running process (I guess it will be locked while the process is >>> running, but will eventually go back to normal once the process >>> completes)? >> >> >> The issue is that delays are recognized by periodically checking the time >> against the next delay expiry. It is the heartbeat thread that causes JITed >> Smalltalk code to break out of its execution to check for events, including >> the next delay expiry. So if the heartbeat is at the same priority as the >> JITed Smalltalk code, and the Smalltalk code is in tight enough a loop (one >> that does not provoke a GC, does not do any process switches) the heartbeat >> thread will not run and the delay expiry will never be tested for. > > > Something like the following should run forever if the heartbeat has the > same priority as the VM thread (and should be tried in a headless > configuration too): > > [| infiniteLoop | > infiniteLoop := [| sum | sum := 0. [sum < 10] whileTrue: [sum := sum + (sum > even ifTrue: [1] ifFalse: [-1])]] newProcess. > infiniteLoop resume. > Processor activeProcess priority: Processor activePriority + 1. > (Delay forSeconds: 1) wait. > infiniteLoop terminate. > Processor activeProcess priority: Processor activePriority - 1] timeToRun > 1001 I get the same result regardless of thread priority, UI or headless. I've just shown the output from the headless VM with the heartbeat thread at normal priority (I haven't incorporated Ben's comments in to the text yet): $ pharo Pharo.image --quit ~/pharo6/pharo/heartbeatTest.st pthread_setschedparam failed: Operation not permitted This VM uses a separate heartbeat thread to update the internal clock. For best operation, this thread should run at real-time priority, however the VM was unable to change the priority. The effect is that the clock may experience some jitter. To avoid clock jitter, please create the appropriate configuration file in /etc/security/limits.d by executing the following: cat <<END | sudo tee /etc/security/limits.d/pharo.conf * hard rtprio 2 * soft rtprio 2 END You will need to log out and log back in for the limits to take effect. For more information please see https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux Time to run: 0:00:00:01 heartbeatTest.st: | time | time := [| infiniteLoop | infiniteLoop := [| sum | sum := 0. [sum < 10] whileTrue: [sum := sum + (sum even ifTrue: [1] ifFalse: [-1])]] newProcess. infiniteLoop resume. Processor activeProcess priority: Processor activePriority + 1. (Delay forSeconds: 1) wait. infiniteLoop terminate. Processor activeProcess priority: Processor activePriority - 1] timeToRun. FileStream stdout nextPutAll: 'Time to run: '; nextPutAll: time printString; cr. time >>> Also, a change was made to the travis test setup in: >>> >>> >>> https://github.com/pharo-project/pharo-vm/commit/5418a415e9297f601f6d57ee73… >>> >>> The comment is: "No need to raise rtprio limit anymore" >>> >>> From your comments above, this doesn't seem accurate. >> >> >> Right. What seems to occur is that certain linux distress don't require a >> conf file to allow raising the priority of a thread. Remember that rtprio >> is not the issue. We only require that the heartbeat thread has higher >> priority than the VM thread. >> >>> >>> I'm in the middle of adding some details to the text that is printed >>> out by the threaded heartbeat vm, and from what you're saying, maybe >>> we should add some more warnings. >> >> >> The VM should (& I believe already does) print an error if the attempt to >> raise the heartbeat thread priority fails. My underatanding is that the >> positive change is simply not to exit if the attempt fails. Right, it does print a message, I'm just trying to make it more accurate and informative. Thanks! Alistair

March 31, 2017

Re: [Pharo-dev] [Gsoc] [FastTable improvements] [Features request]

by Stephan Eggermont

On 31/03/17 08:14, Stephane Ducasse wrote: > To me a datasource should deliver data and not UI elements. AFAIK it is an old established designation for this. It is the data source of the table view, not of the persistency layer. It provides a single point of access to the data in a form that the table view can understand, which is cells. https://developer.apple.com/reference/uikit/uitableviewdatasource https://developer.apple.com/reference/uikit/uitableviewdelegate Stephan

March 31, 2017