- Pharo-dev - lists.pharo.org

Esteban's ChangeLog week of 21 August 2017

by estebanlm＠gmail.com

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

Aug. 28, 2017

This sentence made my day [WAS] Re: [Pharo-users] Dark Mode

by Mariano Martinez Peck

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

Aug. 28, 2017

Re: [Pharo-dev] pillars runs into an infinite loop on a simple typo

by Peter UhnÃ¡k

It interprets it as an unordered list text := '--text--'. doc := PRPillarParser parse: text. PRPillarWriter write: doc. "'- --text\-\-'" it thinks that it is a unordered list as you can see by the writing out. But imho producing unordered list is also wrong because there is no preceeding "first level" (two dashes indicate 2. level nesting, but there was no 1. level) On Sun, Aug 27, 2017 at 8:30 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > This is strange because we should probably have test for this. > Can you paste your example? > > > > On Sat, Aug 26, 2017 at 9:15 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > While we are at it, Pillar cannot parse strikethrough if it is on the > start > > of the line > > > > > > On Sat, Aug 26, 2017 at 7:05 PM, Stephane Ducasse < > stepharo.self(a)gmail.com> > > wrote: > >> > >> No pillar is line based and the beginning of the line is key. > >> > >> On Sat, Aug 26, 2017 at 5:56 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> > 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 > >> > > > >

Aug. 27, 2017

Re: [Pharo-dev] pillars runs into an infinite loop on a simple typo

by Stephane Ducasse

This is strange because we should probably have test for this. Can you paste your example? On Sat, Aug 26, 2017 at 9:15 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > While we are at it, Pillar cannot parse strikethrough if it is on the start > of the line > > > On Sat, Aug 26, 2017 at 7:05 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> No pillar is line based and the beginning of the line is key. >> >> On Sat, Aug 26, 2017 at 5:56 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> > 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 >> >

Aug. 27, 2017

Re: [Pharo-dev] Spotter references?

by Stephane Ducasse

tX! On Sun, Aug 27, 2017 at 12:39 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Indeed, this was a bug. I fixed it and committed in the GT repo. > > Doru > > >> On Aug 22, 2017, at 9:14 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> 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 >> > > -- > www.tudorgirba.com > www.feenk.com > > "Don't give to get. Just give." > > > > > > >

Aug. 27, 2017

Re: [Pharo-dev] [Moose-dev] [ann] moldable editor - with expandable elements

by Tudor Girba

Hi Tim, Thanks for the kind words. What you see now is only the first more tangible effect of what Bloc represents. Expect significantly more :). Cheers, Doru > On Aug 26, 2017, at 9:56 AM, Tim Mackinnon <tim(a)testit.works> wrote: > > Guys - this is absolutely astounding. 6 months ago I tagged a tweet with #pharoproject about why we put up with static source code when we can do so much more, and I'm stunned that in literally months this is a evolving around us. > > This community is awesome! > > Tim > > Sent from my iPhone > > On 26 Aug 2017, at 01:03, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> 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. >> >> <pillar-mondrian-examples.png> >> >> 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). >> >> <pillar-mondrian-expanded-preview.png> >> >> 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." >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "There are no old things, there are only old ways of looking at them."

Aug. 26, 2017

Re: [Pharo-dev] Spotter references?

by Tudor Girba

Hi, Indeed, this was a bug. I fixed it and committed in the GT repo. Doru > On Aug 22, 2017, at 9:14 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > 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 > -- www.tudorgirba.com www.feenk.com "Don't give to get. Just give."

Aug. 26, 2017

Re: [Pharo-dev] libpng fails to download

by Alistair Grant

Hi Nicolas, On Sat, Aug 26, 2017 at 10:10:02PM +0200, Nicolas Cellier wrote: > Yes, that's a problem. > Some projetcs have a strict policy and remove old versions (for example because > they have vulnerabilities). > So we have to regularly update our upstream links. > But we have caches on Travis/Appveyor because reconstructing those external > dependencies is very costly > (see the cache directive near line 7 of https://github.com/OpenSmalltalk/ > opensmalltalk-vm/blob/Cog/.travis.yml). > Consequently, a green build on the CI server might well be red anywhere else... > > Nicolas Thanks for the clarification, I guessed that something like this might be happening. I've opened issue #20341: https://pharo.fogbugz.com/f/cases/20341/ Pull request to follow... Cheers, Alistair > 2017-08-26 20:51 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > > Hi Stef, > > On Sat, Aug 26, 2017 at 07:59:09PM +0200, Stephane Ducasse wrote: > > Indeed. > > Tx alistair. > > This is a little terse for me to be sure of your meaning, but I'll take > it to mean I should submit the patch. :-) > > BTW: I tested libpng-1.6.30 on the full test suite, and the set of > failing tests was the same. > > > Cheers, > Alistair > > > > > On Fri, Aug 25, 2017 at 10:04 AM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > > > 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 > > >

Aug. 26, 2017

Re: [Pharo-dev] libpng fails to download

by Nicolas Cellier

Yes, that's a problem. Some projetcs have a strict policy and remove old versions (for example because they have vulnerabilities). So we have to regularly update our upstream links. But we have caches on Travis/Appveyor because reconstructing those external dependencies is very costly (see the cache directive near line 7 of https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.travis.yml) Consequently, a green build on the CI server might well be red anywhere else... Nicolas 2017-08-26 20:51 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > Hi Stef, > > On Sat, Aug 26, 2017 at 07:59:09PM +0200, Stephane Ducasse wrote: > > Indeed. > > Tx alistair. > > This is a little terse for me to be sure of your meaning, but I'll take > it to mean I should submit the patch. :-) > > BTW: I tested libpng-1.6.30 on the full test suite, and the set of > failing tests was the same. > > > Cheers, > Alistair > > > > > On Fri, Aug 25, 2017 at 10:04 AM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > > > 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 > >

Aug. 26, 2017

Re: [Pharo-dev] [Vm-dev] usage of Pharo-vm repository [was Latest Debian, Ubuntu and CentOS packages of the pharo-vm]

by Nicolas Cellier

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

Aug. 26, 2017