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

Re: [Pharo-dev] [ANN] Willow 4.0.0 released!

by Stephane Ducasse

Hi stephan I totally agree. So much things to try and not enough time!!!! On Sun, Nov 19, 2017 at 1:48 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Op 16-11-2017 om 15:44 schreef Gabriel Cotelli: >> >> Hi, >> >> We're happy to announce the general availability of Willow and it's >> related projects in the Web Stack ecosystem hosted at >> https://github.com/ba-st/. >> >> Willow is a Web Interaction Library that eases the burden of creating >> AJAX-based web applications. The project goals are: > > > Interesting approach. Might be useful to use as a target for (QC)Magritte. > So much things to try out, and not enough time! > > Stephan > >

Nov. 22, 2017

Re: [Pharo-dev] Deploying using the latest minimal image of Pharo (6.1)

by Stephane Ducasse

Hi Gabriel This is cool. Thanks for sharing it with us. I really want an object responsible for deploying an app. :) Your effort is nice in that directory. Keep pushing Stef On Sun, Nov 19, 2017 at 1:33 AM, gabriel sor <despotadesdibujau(a)gmail.com> wrote: > Hi, > In in the past days, in the context of the Smalltalks 2017 conference, I > talked about my attempt to deploy on production using the minimal image > of Pharo . > My goal was prepare an inmutable or staless minimal image for deploy, > without sources nor changes files. > The results are exposed in this tutorial. > The size of the image is 16 MB and it has loaded Seaside. > Just I have a pendeing issue: the staless image but everything else is > done and working. >

Nov. 22, 2017

Re: [Pharo-dev] Bloc Naming Suggestion

by Stephane Ducasse

+1 On Sun, Nov 19, 2017 at 4:34 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I think itâs not a bad idea. > > Doru > >> On Nov 19, 2017, at 4:31 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> What do you think about removing the #Attribute suffix from all the >> BrTextAttribute subclasses? The names seem pretty long (e.g. >> BrFontGenericFamilyAttribute, the longest) and IMHO `BrTextAttribute >> subclass: #BrFontWeight` is adequately intention revealing. Thoughts? >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> > > -- > www.tudorgirba.com > www.feenk.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > >

Nov. 22, 2017

Re: [Pharo-dev] nil suspend

by Stephane Ducasse

+1 On Mon, Nov 20, 2017 at 10:06 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Yes, it doesn't sound right. I vote for removal :) > > On Sat, Nov 18, 2017 at 11:04 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> It sounds like a left over... >> no time stamp in Squeak, so it must be old. >> Display reverse; reverse means we wanted to catch when such oddity was >> necessary. >> (I would do it differently with an Exception and a MessageTally like I >> already exhibited several times) >> The fact that reverse; reverse was commented is more difficult to >> interpret... Is it really necessary? >> I removed the method in a Squeak image, and so fare nothing wrong >> happened, but it does not prove anything. >> The best is to ask in Squeak lists, maybe someone can remember... >> Or carefully analyze all senders of suspend... >> >> 2017-11-18 22:36 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: >> >>> Hi, >>> >>> I was looking at nil (already funny) and found a very interesting >>> method: >>> >>> suspend >>> "Kills off processes that didn't terminate properly" >>> "Display reverse; reverse." "<-- So we can catch the suspend bug" >>> Processor terminateActive >>> >>> It means that the following code is probably the shortest way to kill >>> your image (save first!) >>> >>> nil suspend >>> >>> It terminates a UI process if evaluated from anywhere using CMD+d :D >>> >>> Cheers, >>> Alex >>> >> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Nov. 22, 2017

Re: [Pharo-dev] Advent of code

by Stephane Ducasse

Ok can you put a link on the advent of code web page? On Wed, Nov 22, 2017 at 9:11 PM, Julien <julien.delplanque(a)inria.fr> wrote: > Iâll write a README with some instructions to avoid clash when merging > pull requests. > > For example, each participant could create a directory with its name and > put all his stuff inside it. > > Julien > > Le 22 nov. 2017 Ã 21:09, Stephane Ducasse <stepharo.self(a)gmail.com> a > Ã©crit : > > Tx I forked it. > > On Wed, Nov 22, 2017 at 5:38 PM, Julien <julien.delplanque(a)inria.fr> > wrote: > >> Ok I created one [1], maybe if multiple people are playing with me we can >> gather the different solutions we get for each puzzle in this repository. >> >> Julien >> >> [1]: https://github.com/juliendelplanque/AdventOfCode2017WithPharo >> >> Le 22 nov. 2017 Ã 16:55, Stephane Ducasse <stepharo.self(a)gmail.com> a >> Ã©crit : >> >> Julien >> >> could you open a github project so that we can do the same as norviq? >> And get a log of the problems and solution? >> >> Stef >> >> On Wed, Nov 22, 2017 at 2:25 PM, Serge Stinckwich < >> serge.stinckwich(a)gmail.com> wrote: >> >>> BTW, the Japanese Smalltalk community is doing an advent Calendar every >>> year: >>> >>> https://qiita.com/advent-calendar/2016/smalltalk >>> >>> The 2017 edition is in preparation here: https://qiita.com/advent-calen >>> dar/2017/smalltalk >>> >>> >>> >>> On Wed, Nov 22, 2017 at 1:29 PM, Stephane Ducasse < >>> stepharo.self(a)gmail.com> wrote: >>> >>>> Hi pharoers >>>> >>>> I would like to know if you would like to participate to >>>> http://adventofcode.com/2016 >>>> >>>> For example we could do the same as >>>> https://github.com/norvig/pytudes/blob/master/ipynb/Advent%2 >>>> 0of%20Code.ipynb >>>> >>>> Stef >>>> >>>> >>> >>> >>> -- >>> Serge Stinckwich >>> UMI UMMISCO 209 (IRD/UPMC/UY1) >>> "Programs must be written for people to read, and only incidentally for >>> machines to execute."http://www.doesnotunderstand.org/ >>> >> >> >> > >

Nov. 22, 2017

Re: [Pharo-dev] Cannot inspect a temporary in debugger

by Stephane Ducasse

Thanks for pushing the debugger. I do not really like the list of binding in the inspector pane. Stef On Sat, Nov 18, 2017 at 10:02 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hi again, > I'm experiencing strange behaviour again... > This is with Pharo7.0-32bit-a8a1e21.image > the temp variable index does not want to print value in bottom pane. > but when I attempt to inspect it from code pane, no more luck... > > [image: Images intÃ©grÃ©es 1] >

Nov. 22, 2017

Re: [Pharo-dev] nil inspect

by Stephane Ducasse

Indeed I do not really like the blank window. On Sat, Nov 18, 2017 at 10:18 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Ah OK, it's expected then? > I find that surprising, because I could maybe want to look at meta side > like I can for other elementary objects: > > [image: Images intÃ©grÃ©es 1] > > 2017-11-18 22:03 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > >> Yes >> >> [image: Inline images 1] >> >> Cheers, >> Alex >> >> On 18 November 2017 at 21:56, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> Anyone tried 'nil inspect' recently? >>> >> >> >

Nov. 22, 2017

Re: [Pharo-dev] balloonHelp for menus

by Stephane Ducasse

We were brainstorming about how to "radically" change iceberg to convey the complexity of the situation and I was suggesting to have long menu to educate us (poor people). I proposed for icecube (the tool for newbies that do not want to work on fork and just want to get the MC workflow) the following: - âclone a repo" (with the indication if this is https or ssh) - âfetch (remote -> local)" - âcommit (image -> local)â - âpush (local -> remote)" - âload (local -> image)â - âmerge (local -> image)" - "pull (fetch + load)" Fetch and Pull should not have the same icons Optional - âcreate branchâ - âswitch branchâ And yes I want long menu to tell me all the time key information about the action. Stef On Mon, Nov 20, 2017 at 10:44 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hi again, > I see no balloon help in menus in Pharo 7.0. > Some menu labels are intention revealing and a balloon paraphrasing the > label is useless. > But that's not the general case, some complex actions like found in Iceberg > interface would deserve a bit more explanations for noobs like me. > A link from the menu to some Help topic would also be more than welcome > (maybe thru an anchor, a tag or some other machinery...)

Nov. 22, 2017

Re: [Pharo-dev] method usage example: annotation or comment?

by Stephane Ducasse

Hi nicolas I do not know what are < expr: (foo) results: bar > may be this is even me that tried something (shame on me) but I think that we should clean them. Now I use "foo >>> bar" because we can have non literal and we will start to build tools based on them. I would like to clean the proliferation of pragmas too. Stef On Mon, Nov 20, 2017 at 9:33 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hi, > I encountered some annotations in the form: > > < expr: (foo) result: bar > > > and some meta comments of the form: > > " foo >>> bar " > > I think both are aimed at providing examples of method usage for > documentation, non regression testing, etc... > > I note that the former is requiring a literal result, which is quite > limiting (1/3) is not a literal for example, 0@0 neither... > IMO it should be extended for handling any valid expression. > But that still makes two different ways of expressing the same intent. So > what's the canonical one?

Nov. 22, 2017

Re: [Pharo-dev] OpalCompiler evaluate speed

by Stephane Ducasse

Thanks this is good. I think that Opal deserves more energy. We are busy right now. Now marcus will certainly be interested. It will also speed up part of the bootstrap. Stef On Tue, Nov 21, 2017 at 2:19 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I have an ArbitraryPrecisionFloatTests doing an exhaustive test for printing > and reevaluating all positve half precision float. > > That's about 2^15 or approximately 32k loop which evaluate snippets like > > (ArbitraryPrecisionFloat readFrom: '1.123' readStream numBits: 10) > > The test was naively written with Compiler evaluate: and was using the > legacy Compiler. > > If I rewrite self class compiler evaluate: the test times out. > Let's see what increase is necessary: > > [ ArbitraryPrecisionFloatTest new testPrintAndEvaluate ] timeToRun. > -> 3s with legacy Compiler > -> 14s with OpalCompiler > > It's not unexpected that intermediate representation (IR) reification has a > cost, but here the 4.5x is a bit too much... > This test did account for 1/4 of total test duration already (3s out of > 12s). > With Opal, the total test duration doubles... (14s out of 23s) > > So let's analyze the hot spot with: > > MessageTally spyOn: [ ArbitraryPrecisionFloatTest new > testPrintAndEvaluate ]. > > (I didn't use AndreasSystemProfiler becuase outputs seems a bit garbbled, no > matter since the primitives do not account that much, a MessageTally will do > the job) > > I first see a hot spot which does not seem that necessary: > > | |24.6% {3447ms} RBMethodNode(RBProgramNode)>>formattedCode > > From the comments I understand that AST-based stuff requires a pattern > (DoIt) and an explicit return (^), but this expensive formatting seems too > much for just evaluating. i think that we should change that. > > Then comes: > > | |20.7% {2902ms} RBMethodNode>>generate: > > which is split in two halves, ATS->IR and IR->bytecode > > | | |9.3% {1299ms} RBMethodNode>>generateIR > > | | | |11.4% {1596ms} IRMethod>>generate: > > But then I see this cost a 2nd time which also leave room for progress: > > | |10.9% {1529ms} RBMethodNode>>generateIR > > | | |12.9% {1814ms} IRMethod>>generate: > > The first is in RBMethodNode>>generateWithSource, the second in > OpalCompiler>>compile > > Last comes the parse time (sourceCode -> AST) > > | 13.2% {1858ms} OpalCompiler>>parse > > Along with semantic analysis > > | 6.0% {837ms} OpalCompiler>>doSemanticAnalysis > > ----------------------------------- > > For comparison, the legacy Compiler decomposes into: > > | |61.5% {2223ms} > Parser>>parse:class:category:noPattern:context:notifying:ifFail: > > which more or less covers parse time + semantic analysis time. > That means that Opal does a fair work for this stage. > > Then, the direct AST->byteCode phase is: > > | 16.9% {609ms} MethodNode>>generate > > IR costs almost a 5x on this phase, but we know it's the price to pay for > the additional features that it potentially offers. If only we would do it > once... > > And that's all for the legacy one... > > -------------------------------------- > > This little exercize shows that a 2x acceleration of OpalCompiler evaluate > seems achievable: > - simplify the uselessely expensive formatted code > - generate bytecodes once, not twice > > Then it will be a bit more 2x slower than legacy, which is a better trade > for yet to come superior features potentially brought by Opal. > > It would be interesting to carry same analysis on method compilation

Nov. 22, 2017