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

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

new chapter on double dispatch for new book :)
by Stephane Ducasse Aug. 26, 2017

Aug. 26, 2017

feedback is welcome Good reading

3 5

[Pharo6] [Issue Tracker] Help Needed: issues tagged Pharo6
by Marcus Denker Aug. 26, 2017

Aug. 26, 2017

Hi, We have 40 issues that are tagged for Pharo6: https://pharo.fogbugz.com/f/filters/1192/6-0-All <https://pharo.fogbugz.com/f/filters/1192/6-0-All> We should move as many of those to âLaterâ, so that we can focus on important fixes and back portsâ¦ sadly here we need to be realistic: We can not fix everything or even back port everythingâ¦ we need to prioritise. It would help if people could âhelp decidingâ which issues do not need the Pharo6 milestone. Marcus

3 5

[Ann] PharoThings a live programming IoT platform based on Pharo
by Denis Kudriashov Aug. 25, 2017

Aug. 25, 2017

Hi. I am glad to announce the project PharoThings <https://github.com/pharo-iot/PharoThings> which brings the live programming environment into IoT domain. It includes: - development tools to lively program, explore and debug remote boards (based on TelePharo <https://github.com/dionisiydk/TelePharo>) - board modeling library which simplifies board configuration - Raspberry driven by WiringPi library - Arduino driven by Firmata, soon - Beaglebone, soon Follow github page <https://github.com/pharo-iot/PharoThings> and videos to get a feeling of this project: - https://youtu.be/ezfjditHjq4 - https://youtu.be/5i0tsgFtlOg - https://youtu.be/0H9of7PQet0 Now PharoThings is in beta stage together with documentation and videos. I would like any feedback on how to improve them. If you are going to Esug conference you can see PharoThings in live at awards competition. Best regards, Denis

4 3