- Pharo-dev - lists.pharo.org

Esteban's ChangeLog week of 21 August 2017
by estebanlm＠gmail.com Aug. 30, 2017

Aug. 30, 2017

Hello! This is my weekly ChangeLog, from 21 August 2017 to 27 August 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=21/8/2017&to=27/8/2017 ChangeLog ========= 22 August 2017: --------------- * I debugged a crash on the VM (I originally thought it was a Windows bug but turns out is general). But I need some discussion on it before fixing: [http://forum.world.st/bug-when-instantiating-ExternalData-to-return-void-fr… 21 August 2017: --------------- * I'm back from holidays! But... I spent the full day getting a windows VM to compile (so I can debug iceberg problems) :( cheers! Esteban

5 4

[GitHub] Please verify your email address.
by GitHub Aug. 30, 2017

Aug. 30, 2017

Hi @estebanlm! Help us secure your GitHub account by verifying your email address (pharo-dev(a)lists.pharo.org) This will let you receive notifications and password resets from GitHub. Click the link below to verify your email address: https://github.com/users/estebanlm/emails/36063542/confirm_verification/3bb… Youâre receiving this email because you recently created a new GitHub account or added a new email address. If this wasnât you, please ignore this email. --- Sent with <3 by GitHub. GitHub, Inc. 88 Colin P Kelly Jr Street San Francisco, CA 94107

2 1

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