- Pharo-dev - lists.pharo.org

Use less CPU (improve battery life or reduce cost in the cloud)
by Holger Freyther Aug. 29, 2017

Aug. 29, 2017

Hi, I have done some early prototype for the Unix VM end of 2015(?) and I have improved and repeated these for MacOS now and the thread based heartbeat (now that it is the universal default). I won't make it to ESUG this year but this might be something to play with? The motivations is simple: Polling increases the CPU usage which will reduce your battery life, takes away resources from other processes (e.g. more Pharo images) or these days increases your cloud computing bill. On top of that it might increase network latency (time from socket becoming readable to the time the semaphore is signaled). To complete the work we have work inside the Image and the VM and some of it is on the way and others might need more discussion. The idle process: ProcessorScheduler>># idleProcess "A default background process which is invisible." [true] whileTrue: [self relinquishProcessorForMicroseconds: 1000] Let's please yield the CPU for more than a 1ms. Unless I am missing something an expired Delay or network IO would make us wake up earlier anyway? The delay scheduler: The VM supports that when the next wake-up time is set to 0, the VM can sleep indefinitely. There is a pending patch to sleep "0" in our Delay scheduler. Currently we force a wake-up earlier than that. I think we should trust the VM to do wake us up even if it is a second away. Morphic UI: I don't understand the WorldState>>#interCyclePause but then I never looked at Morphic. Do we really need to poll like that? Under which circumstances does the world update? We get an event (where we have the event semaphore), we get some I/O (where we have a semaphore) or we have a timeout (where we sleep on a semaphore). Did anyone ever look at removing the tick? VM I/O: Currently we receive a SIGIO but from what I can see (and I still need to write a benchmark) the processing might be delayed 20ms? My hack removes the usage of nextPollUsecs and instead checks a variable that is set by the SIGIO handler. Besides missing memory barriers this should work(tm). The biggest issue seems that for macos/ios the input is driven by polling. E.g. some wheel events seem to require to pump the event queue. Is this something we could trigger from the image in the future? I had hoped to get a fd to a machport we could get SIGIO for.. but that doesn't seem to exist. I have hacked out the honoring of the relinquish delay, added the polling into a iOS specific routine and thanks to the Morphic Delay we bump the event loop frequently enough. VM heartbeat thread: The process keeps ticking even if the VM doesn't run. E.g. sleeps and waits for an event. There is a cost in deciding when to halt the thread so there must be a cut-off for which delays we bother to disable the heartbeat thread. I think the current code would allow the hearbeat to drift so the new code might just make it a bit worse. Where are we now? I have pushed my changes to https://github.com/zecke/opensmalltalk-vm/tree/mac-use-less-cpu and would be happy to have people look at it, look at the memory synchronization, maybe run to see if they notice extra delays or such? I started the same image with the plain-vm and my hacked one and let it run for about 20min. The output is coming from top. COMMAND %CPU TIME Pharo 4.3 00:48.49 Pharo 0.8 00:10.20 Looking for comments and feedback. regards holger

1 0

[ Pharo 70 ] PR log
by Stephane Ducasse Aug. 29, 2017

Aug. 29, 2017

1 0

[ Pharo 70 ] Build 61 - 64
by Marcus Denker Aug. 29, 2017

Aug. 29, 2017

[ Pharo 70 ] Build 64 PR 196 Add validation step for binary loaded tests https://github.com/pharo-project/pharo/pull/195 https://pharo.fogbugz.com/f/cases/20332 [ Pharo 70 ] Build 62 PR 222 20346-Update-Iceberg-to-057 https://pharo.fogbugz.com/f/cases/20346 https://github.com/pharo-project/pharo/pull/222 [ Pharo 70 ] Build 61 PR 218 Dead code: #destinationBuffer: and #digitBuffer: https://github.com/pharo-project/pharo/pull/218 https://pharo.fogbugz.com/f/cases/20234

1 0

Current VM build problems. (was: Fwd: Errored: OpenSmalltalk/opensmalltalk-vm#835 (Cog - 7dff211))
by Tobias Pape Aug. 29, 2017

Aug. 29, 2017

Hi all, currently the vm fails to build properly due to two main problems: a) #testBecomeIdentityHash fails on Squeak5.1 for linux32x86 squeak.cog.spur https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/269505448#L3172 linux32x86 squeak.sista.spur https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/269505458#L3208 linux32x86 squeak.stack.spur https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/269505461#L1842 macos32x86 squeak.cog.spur https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/269505499#L8455 macos32x86 squeak.sista.spur https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/269505503#L8517 macos32x86 squeak.stack.spur https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/269505505#L7383 (Or said differently: on 32x86 for squeak.*.spur) I recall we had problems there but I thought those were fixed 2..3 years ago? Someone can comment? b) the pharo deployment seems to not work correctly: https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/269505445#L1900 https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/269505471#L8223 https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/269505444#L1900 for 64x64 pharo.cog.spur. If it is correct that those 3 vms cannot be deployed, please fix the deploy script to not try to. IF incorrect, pleas fix on your side/site. Best regards -Tobias > Begin forwarded message: > > From: Travis CI <builds(a)travis-ci.org> > Subject: Errored: OpenSmalltalk/opensmalltalk-vm#835 (Cog - 7dff211) > Date: 29. August 2017 um 13:02:09 MESZ > > OpenSmalltalk / opensmalltalk-vm (Cog) > > Build #835 has errored. 48 minutes and 25 seconds > Tobias Pape 7dff211 Changeset â > [squeakssl] follow suit with the unix hostname validation things > Want to know about upcoming build environment updates? > Would you like to stay up-to-date with the upcoming Travis CI build environment updates? We set up a mailing list for you! Sign up here. > Documentation about Travis CI > Need help? Mail support! > Choose who receives these build notification emails in your configuration file. > > Would you like to test your private code? > Travis CI for Private Projects could be your new best friend!

1 0

This sentence made my day [WAS] Re: [Pharo-users] Dark Mode
by Mariano Martinez Peck Aug. 28, 2017

Aug. 28, 2017

On Sun, Aug 27, 2017 at 6:50 PM, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > I agree with Dimitris - it is all a matter of preference - not all eyes > are the same. For myself, I find the default dark theme in Pharo very > uncomfortable. On my system, some elements have a black foreground on a > dark grey background, which is almost impossible to see. This is always > true of the maximise/minimise/close buttons, but sometimes also of text > fields in a playground. Whenever I download a new image, I immediately > switch to the Watery theme, with light background and nice coloured buttons > on the windows. > > Of course, my eyes may not be typical. I am now aged 84, and I have had > cataract operations on both eyes. My sight is actually quite good - my > optometrist confirms that I am legal to drive without spectacles - but my > adverse reaction to dark mode is strong and immediate. > > Sometimes is hard to explain to someone outside the community why Smalltalkers love they language so much. I think above paragraph says it all. It made my day. I wish I can follow that path! hahaha. > Just my 2p worth > > Peter Kenny > > -----Original Message----- > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf > Of stephan > Sent: 27 August 2017 21:46 > To: pharo-users(a)lists.pharo.org > Subject: Re: [Pharo-users] Dark Mode > > On 27-08-17 22:37, Dimitris Chloupis wrote: > > White or dark is a matter of preference. But the matter of preference > > is also a matter of biology . Not all eyes are same. > > The research is pretty clear: a large majority of developers does better > with light themes. I have been sufficiently clear on the choice to make > Pharo6 theme dark default > > Stephan > > > > -- Mariano http://marianopeck.wordpress.com

1 0

pillars runs into an infinite loop on a simple typo
by Peter UhnÃ¡k Aug. 27, 2017

Aug. 27, 2017

Apparently this is enough to run into an infinite loop somewhere. text := '- one - # cry'. doc := PRPillarParser parse: text. Also question regarding pillar syntax, is not possible to indent it in the syntax? e.g. - one -# one.one - two -# two.one -# two.two Flattening it makes an _indented_ list hard to read (and defeats the point why we indent things in the first place...) Peter

2 4

Spotter references?
by Stephane Ducasse Aug. 27, 2017

Aug. 27, 2017

Hi I tried Command Shift n to get the class references in Spotter I got #References Point but I got an empty list while if I do Point Cmd shift n I get a list Stef

2 2

[ann] moldable editor - with expandable elements
by Tudor Girba Aug. 26, 2017

Aug. 26, 2017

Hi, We are really pleased to announce another major advancement in the development of the moldable editor, and most of it was enabled because of one new feature: expandable elements. We think this will impact significantly our day to day interactions. To exemplify what we mean, we will make use of two more alpha projects that we did not announce yet: GT Documenter (a set of documentation tools based on Pillar and GT Examples) and GT Mondrian (the graph visualization engine), both of which are being implemented in Bloc. Please take a look at the following pictures showing the documentation Pillar file that ships together with GT Mondrian. What stands out are the two embedded pictures. These are actually not pictures, but visualizations rendered live during the viewing of the document out of a referenced GT Example. Now, GT Examples are likely also new for most people. We introduced them a couple of years ago based on the original idea of Markus Gaelli. These are a kind of tests that return an object and that can be built out of other examples. The nice thing is that they are always executable and testable. So, of course, if you see the resulting object, you can also see the code that created it, and if you see the code, you can even execute it live, right in place (notice the preview of the second snippet). Perhaps the most controversial part of GT Examples is that they offer a mechanism to define static dependencies via pragmas. Please, letâs leave this debate to another occasion, but please also notice that tools can use that static information to unfold the code of the referenced method (notice the nested code editors). A side note: if you look closer at the list with three items at the top of the Tutorial section, you will notice numbering next to #. That is actually syntax highlighting and so is the mechanism that embeds the expandable elements. Itâs really cool. Taking step back, when we introduced the editor a few weeks ago, we called it moldable because we said we can make it take different shapes easily. GT Documenter with everything you see in the above screenshots has currently ~500 lines of code, and all this while still having an editor that is highly scalable. We think that Bloc and Brick will change dramatically face of Pharo and now we can start to get a glimpse of what is possible. For example, the use case presented above is more than a technical tool, and we think this will change both the way we write documentation and the way we consume it. All these will be presented at ESUG both during presentations and at the Innovation Awards competition. In the meantime, those that want to play with it can execute the following in both Pharo 6.1 and Pharo 7.0: Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'GToolkit'; repository: 'github://feenkcom/gtoolkit/src'; load. And then inspect: './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' asFileReference Cheers, The feenk team -- www.tudorgirba.com www.feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."

3 5

libpng fails to download
by Alistair Grant Aug. 26, 2017

Aug. 26, 2017

Hi All, Esteban, I just attempted to build the pharo vm on Win32 and it failed due to: ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng16/libpng-1.6.29.tar.gz not being available. The current version is 1.6.30, which also appears to be unavailable from this address. I successfully downloaded 1.6.29 from: http://prdownloads.sourceforge.net/libpng/libpng-1.6.29.tar.gz?download which is referenced on what appears to be the official web page: http://www.libpng.org/pub/png/libpng.html I plan to test with 1.6.30 tonight. Is there any reason not to submit a PR pointing to sourceforge? Thanks, Alistair

3 4

Re: [Pharo-dev] [Vm-dev] usage of Pharo-vm repository [was Latest Debian, Ubuntu and CentOS packages of the pharo-vm]
by Nicolas Cellier Aug. 26, 2017

Aug. 26, 2017

2017-08-23 17:14 GMT+02:00 Holger Freyther <holger(a)freyther.de>: > > > > On 18. Aug 2017, at 23:56, Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com> wrote: > > Hi! > > Hi Holger, > > Are the packaging stuff in opensmalltalk too, or just in pharo-vm? > > It would be great to move all to opensmalltalk. > > What is specificity of pharo-vm repository now? > > the packaging bits are in the pharo-vm repository only. What is pharo > specific from a technical point of view is that I re-generate the sources > before building the source package. There is a Makefile[1] that drives > building the source package and the actual compilation is here[2]. > > Ah yes, there have been some propositions to perform this task in a specific development branch in opensmalltalk, but so far nothing has happened... As Eliot explained once, we currently have no guaranty to regenerate identical sources (mostly we observe signed/unsigned type swapping). Probably type inference depends on the order of MethodDictionary scanning which is random. Of course it should be fixed, but someone has to do it.... Untill then, generated sources have to be versionned, there is no alternative way, otherwise we don't have reproducible artefacts... A specific build could suddenly start crashing without any easy way to reproduce and debug, think of it twice before regenerating sources... Porting VM to another OS without having to regenerate still is another valuable feature. I also find the ability to track generated-source diffs valuable: it's a complementary check, especially when changing code-generation part. That's why we continue to version generated source, whatever the ready-made thinking. Once the code generation is stable, it can be done by a bot. But don't forget that not all VMMaker commit will produce interesting C sources, because a great deal of development happens in VM-Simulator, not in C - at least the major features that Eliot and Clement are after. > I don't want this to sound offensive but the non-technical part is that it > seems easier to get changes into the PharoVM than into opensmalltalk-vm. > One example could be the FilePlugin and my attempt to use inotify without > periodic polling (wastes power, adds latency and increases your bill in > cloud computing, etc). > > Backporting upstream changes between squeak/newspeak vm and pharo vm was not sustainable, and mostly one way (unfair). That's also what motivated the switch to opensmalltalk: it's dialect neutral. Of course, changes in opensmalltalk must be done with retro and cross compatibility constraints which may require a little more effort, but at worse we have dialect-specific #ifdef directives. Remember that VM stability is valued not only because there are grumpy old and conservative fellows here ;) Without VM stability, how could we have a smooth and sustainable overall development process? That said, I hate nothing much than stale pull request and it's clearly the next obstacle to contributions (in case vm contributions was easy enough). If that's the case, that's regrettable. So don't hesitate to complain here. It doesn't mean that every PR has to be accepted. Ideally, they should be closed in a reasonnable time, with comments telling why or what needs to be improved for inclusion... IMO in absence of dedicated paid staff, we should start closing old PR (exactly as Pharo is closing stale fogbugz entries). it's not satisfying, but letting a long list of open PR is worse. Non-technically speaking, Esteban is among the core developpers of opensmalltalk, so it should be as easy to integrate changes as in a pharo-vm copy, modulo cross and retro compatibility concerns. We are supposed to have non regression tests to lower the level of heroism of the poor human integrators that we all are. > I am happy to answer questions about the packaging process or the > OBS/travis-ci integration! > > holger > > Thanks! I hope someone will jump at the opportunity :) > > [1] https://github.com/pharo-project/pharo-vm/blob/master/Makefile.debian > [2] https://github.com/pharo-project/pharo-vm/blob/master/ > packaging/pharo6-vm-core/debian/rules

1 0