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

Re: [Pharo-dev] Pinning Objects in Pharo

by Eliot Miranda

Hi Torsten, Hi Esteban, > On Aug 28, 2017, at 9:17 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > > As some of you are aware of Spur added memory pinning and in Pharo 6.1 (#60510) as well as Pharo 7 > we currently have > > Object>>pin > Object>>unpin > Object>>isPinned > > and also Object>>setPinned:. > > Object pinning is explained by Eliot here [1]. > > I would propose two changes (at least for Pharo but ideally also for Squeak): > > 1. IMHO #setPinned: should be moved to a private protocol > 2. Provide a #pinDuring: aBlock method like: > > pinDuring: aBlock > [ self pin. > aBlock value ] ensure: [ self unpin ] > > so we can ensure that a pinned object is unpinned after an operation. > > What do you think? > > Also I wonder why FFICallbackTests>>#testCqsortWithByteArray is sending #pin but not > #unpin afterwards. Maybe that is the reason why there is a flag in this method that it > is crashing on Windows. This test is news to me. Neither the test nor the class is in FFI-Tests at source.squeak.org, which is where the package lives. Why is it missing? > > Bye > T. > > [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-August/195129.h…

Aug. 28, 2017

Pinning Objects in Pharo

by Torsten Bergmann

As some of you are aware of Spur added memory pinning and in Pharo 6.1 (#60510) as well as Pharo 7 we currently have Object>>pin Object>>unpin Object>>isPinned and also Object>>setPinned:. Object pinning is explained by Eliot here [1]. I would propose two changes (at least for Pharo but ideally also for Squeak): 1. IMHO #setPinned: should be moved to a private protocol 2. Provide a #pinDuring: aBlock method like: pinDuring: aBlock [ self pin. aBlock value ] ensure: [ self unpin ] so we can ensure that a pinned object is unpinned after an operation. What do you think? Also I wonder why FFICallbackTests>>#testCqsortWithByteArray is sending #pin but not #unpin afterwards. Maybe that is the reason why there is a flag in this method that it is crashing on Windows. Bye T. [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-August/195129.h…

Aug. 28, 2017

Re: [Pharo-dev] Esteban's ChangeLog week of 21 August 2017

by Sean P. DeNigris

EstebanLM wrote > This is my weekly ChangeLog, from 21 August 2017 to 27 August 2017. Thank you for all the work you consistently do, especially the stuff deep down in the system which brings no personal glory but provides the foundation for the creations of our entire community! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Esteban-s-ChangeLog-week-of-21-August-2017-tp4964905p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 28, 2017

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