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

Engineering notation

by Andreas Sunardi

I probably telling what has been known for ages, but some months ago I was pleasantly surprise to find a space is not needed between the receiver and the message when the receiver is a number. Because of that I'm able to define, for example #u, #n and #k for micron, nano and kilo units, and use them as in 1u, 1n and 1k. I don't know if this is intended or not, but I'm using it to my benefit. I want to share this in case some body finds this and thinks it should be fixed. I'm pleading to leave it as is. -- Andreas Sunardi

Aug. 30, 2017

#parseMethod:onError: isn't as obvious as expected - is it me?

by Tim Mackinnon

Iâm looking for some feedback on the usage of RBParser>>#parseMethod:onError:. I am looking at ways of improving the way we edit code - and making things work (as least for me - but maybe for everyone) a bit more like IntelliJ where they have some great code operations and very good keyboard support. We are certainly close, but at times feel a bit clumsy - which is a shame as we have far better infrastructure to support equivalent features. So I thought I would have a go. Anyway - step one (which I think Iâve come close on), was to teach senders/implementors to look at the AST so you donât have to highlight exactly what you want to search on - instead it can infer from your cursorâ¦ however my next step was to improve how we can select code to ease refactoring, bracketing etcâ¦ So this is where Iâve hit a few issues which strike me as confusing (and I will freely admit that Iâm not a mega compiler, parser guy - but Iâd love to beâ¦). The following code blows up strangely - and I think its very confusingâ¦ as it turns out that #parseMethod:onError: doesnât work like I would expect (and this is where Iâm after feedback). It seems that the onError block doesât actually exit parsing - it takes the result and then keeps running with something in an intermediate state - thus below, when I try to parse with a subset of the code (and maybe this is a naive approach to handle the case when you start typing code in the middle of a complete method, but want to parse it before youâve entered a final â.â or â;â) - you actually end up with an AST that is using all of the source code because the result of the error block is then applied inside the executing method. I find this very confusing? There are no comments in this code, and for me the convention of onError: is to execute in isolation unless there is a parameter that the error block can interact with. Iâm wondering if those with more knowledge agree - or if it is my naivetÃ©? This was my original code (and yes it needs refactoring a bit) - but anyway: bestNodeInTextAreaOnError: aBlock "Find the best node in the editor text area at the current pointer location" | ast start stop node source | start := self textArea startIndex. stop := self textArea stopIndex. source := self textArea string trimRight. ast := RBParser parseMethod: source onError: [ RBParser parseExpression: source onError: [ source := (source truncateTo: stop) trimRight. RBParser parseMethod: source onError: [ RBParser parseExpression: source onError: aBlock ]]]. stop > source size ifTrue: [ start := stop := source size]. node := ast bestNodeFor: (start to: stop). node ifNil: aBlock. ^node But this doesnât work, as âastâ is incorrect when it parses truncated source. To work around what Iâm seeing I have to instead extract the ast assignment to another method that looks as follows - but to me it seems very unexpected to have the explicit ^ statements? agressivelyParse: source at: loc "Find the best node in the editor text area at the current pointer location" ^RBParser parseMethod: source onError: [ ^RBParser parseExpression: source onError: [ | reducedSrc | reducedSrc := (source truncateTo: loc) trimRight. ^RBParser parseMethod: reducedSrc onError: [ ^RBParser parseExpression: reducedSrc onError: [^nil]]]]. This forces the ast to be exactly what I would expect - but Iâm wondering if I am missing something obvious? Tim

Aug. 30, 2017

Roassal question on Kiviat diagrams and coloring

by Sebastian Heidbrink

Hi all! Does anybody have an advice on how to color Kiviat diagram nodes and edges based on a nodes property/attribute? For example, if I wanted to create a Kiviat diagram with weather information and color all days (nodes and edges) with temperatures above 0 degrees in red and those below 0 degrees in blue... how would I implement this? Thank you for any hint! Sebastian

Aug. 30, 2017

Re: [Pharo-users] [Fuel] Conditions for Fuel file compatibility?

by H. Hirzel

Norbert Thank you for the info that the version of Fuel is important, not image version nor VM. This looks promising: my Pharo 5 image has FLMaterializer new version 194 and the Pharo 6.0/6.1 image has FLMaterializer new version 194 I'll to some tests. Regards Hannes On 8/30/17, Norbert Hartl <norbert(a)hartl.name> wrote: > Hannes, > > fuel should not be depend on image or vm version just on its own version. > The rule is that if you have the same version of fuel in two images you > should be able to use it on both images regardless of image or vm version. > > The current issue is probably vm dependent. I can also read fuel files that > are produce by my service back into my image. But I cannot read the fuel > files produced by my jenkins server. Image is the same everywhere but the vm > is different. > > Norbert > >> Am 30.08.2017 um 12:58 schrieb H. Hirzel <hannes.hirzel(a)gmail.com>: >> >> Hello >> >> I think the question is good for a new thread: >> >> Tim M. reported that a fuel file from a 6.1 image could be read in a 7.0 >> image. >> >> I wonder what the conditions are for this type of compatibility >> >> - type of objects written? >> - no class definition changes? >> - ... >> >> Regards >> Hannes > >

Aug. 30, 2017

Re: [Pharo-users] [Fuel] Conditions for Fuel file compatibility?

by Norbert Hartl

Hannes, fuel should not be depend on image or vm version just on its own version. The rule is that if you have the same version of fuel in two images you should be able to use it on both images regardless of image or vm version. The current issue is probably vm dependent. I can also read fuel files that are produce by my service back into my image. But I cannot read the fuel files produced by my jenkins server. Image is the same everywhere but the vm is different. Norbert > Am 30.08.2017 um 12:58 schrieb H. Hirzel <hannes.hirzel(a)gmail.com>: > > Hello > > I think the question is good for a new thread: > > Tim M. reported that a fuel file from a 6.1 image could be read in a 7.0 image. > > I wonder what the conditions are for this type of compatibility > > - type of objects written? > - no class definition changes? > - ... > > Regards > Hannes

Aug. 30, 2017

[Fuel] Conditions for Fuel file compatibility?

by H. Hirzel

Hello I think the question is good for a new thread: Tim M. reported that a fuel file from a 6.1 image could be read in a 7.0 image. I wonder what the conditions are for this type of compatibility - type of objects written? - no class definition changes? - ... Regards Hannes

Aug. 30, 2017

Re: [Pharo-users] Pharo 61 crashes on iceberg history

by Esteban Lorenzano

there was a problem with latest VM. now, latest Iceberg release along with latest VM should fix this problem. Esteban > On 3 Aug 2017, at 11:32, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 3 Aug 2017, at 11:24, Herby VojÄÃk <herby(a)mailbox.sk> wrote: >> >> Esteban Lorenzano wrote: >>> Hi, >>> >>> can I have a reproducible case? >> >> IIRC, every click on a particular commit in history view just does that. > not really, I use it everyday (well, not now since Iâm on holidays, but every other day). > >> >>> and a bug report on https://github.com/pharo-vcs/iceberg/issues ? >> >> Not me, no github (and no plan to). > > then I will probably not remember issue because I cannot remember everything I see (I receive 150+ mails *a day*, imagine that in 20 days holidays). But if for real there is a crash so often, I will eventually hit it (or some other will eventually report it). > > cheers! > Esteban > >> >>> (so I do not forget when I comeback from holidays). >>> >>> cheers! >>> Esteban >>> >>>> On 30 Jul 2017, at 21:37, herby(a)mailbox.sk <mailto:herby@mailbox.sk> wrote: >>>> >>>> Me, too. Primitive failure. 117, IIRC. >>>> >>>> On July 30, 2017 3:51:56 AM GMT+02:00, "JuliÃ¡n Maestri" <serpi90(a)gmail.com <mailto:serpi90@gmail.com>> wrote: >>>>> I'm almost sure this is not the right place to report it. >>>>> >>>>> Im having a vm crash when looking at the history of a repository on >>>>> iceberg. >>>>> >>>>> urpharo: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top >>>>> (av) >>>>>> && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && >>>>> prev_inuse >>>>>> (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' >>>>> failed. >>>>>> ./pharo-u >> i: line 11: 2011 Aborted (core dumped) >>>>>> "$DIR"/"pharo-vm/pharo" "$@" >>>>>> >>>>> >>>>> Pharo downloaded from get.pharo.org/64/ <http://get.pharo.org/64/> on Ubuntu 16.04 (64bit) >>>>> >>>>> Has somebody had this problem? >>>>> Where's the right place to report this? >>>>> >>>>> Thanks, JuliÃ¡n >>>> >>> >> >> >> >

Aug. 30, 2017

Re: [Pharo-users] CodeImporter. 256 literals limit

by Esteban Lorenzano

you can try the new (still experimental) packaging for Pharo: CentOS 6.8: # Add the repo $ yum-config-manager --add-repo http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/C… # Install 32bit packages (with X11 dependency for *-ui or not) $ yum install pharo6-32-ui.i686 or pharo6-32.i386 # Install 64bit packages $ yum install pharo6-64-ui.x86_64 pharo6-64.x86_64 that will install correct vm for your distribution. cheers, Esteban > On 29 Aug 2017, at 18:58, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: > > Point well taken. Unfortunately, I'm not in charge of the infrastructure. I don't know if my experience is typical or not, but it's difficult for IT to find a period to disrupt engineering projects, potentially breaking tools, without drawing fire from engineering :) > > > On Tue, Aug 29, 2017 at 8:45 AM, Richard Sargent <richard.sargent(a)gemtalksystems.com <mailto:richard.sargent@gemtalksystems.com>> wrote: > my work environment is using RedHat6/CentOS6 with glibc 2.12 > > That's seven years of unpatched security vulnerabilities! Are you sure you really want to stay at such great risk? > > > On Tue, Aug 29, 2017 at 8:30 AM, Andreas Sunardi <a.sunardi(a)gmail.com <mailto:a.sunardi@gmail.com>> wrote: > That sounds good. Unfortunately for me, my work environment is using RedHat6/CentOS6 with glibc 2.12. Is there Pharo6 with glibc < 2.15 support. Or is there a way for me to build that myself? > > It's quite a departure to change my DSL into defining multiple methods. But that's my own problem. > > I'm happy to hear Pharo 6 can support a lot more literals. I tested my code on Pharo 6 (on my Windows box) and it works. I see SistaV1 compiler in Pharo 5 setting, but that causes Pharo to crash. > > Thank you guys for your answers. I think I have the information I need to make decision. But if there is a way to get Pharo 6 that works with glibc < 2.15, please let me know. > > Thank you > -- > Andreas > > On Tue, Aug 29, 2017 at 12:34 AM, ClÃ©ment Bera <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>> wrote: > Hi, > > If your tool works in Pharo 6, you can use the other bytecode set which supports up to 32k literals. To do so, go to: > World Menu > Settings > Compiler > Encoder > and pick SistaV1 instead of V3PlusClosures > Try to load your code. The default Pharo 6 VM supports both bytecode sets. > > Alternatively you need to split your methods with many literals in multiple methods with less literals, which is usually quite tricky to do right. > > On Tue, Aug 29, 2017 at 4:52 AM, Andreas Sunardi <a.sunardi(a)gmail.com <mailto:a.sunardi@gmail.com>> wrote: > I have written a tool (Pharo5) where user gives an input file to it, where the content is a smalltalk code, a DSL. I used a subclass of CodeImporter class to evaluate this input file. > > Recently my user used an input file where it hit the 256 literal limit (total of unique string, number, method name, etc), down in OpalEncoderForV3PlusClosures >> genPushLiteral:. The number seems to be hard coded and related to byte code generator, not something I can simply increase. I wasn't aware of this limitation. > > Before I overhaul my tool, I thought I should ask. Is there another alternative to evaluate a smalltalk file/script? The file is small, 27k, but the number of unique literals in it is > 256. Is it possible at all, seeing that the limit is related to byte code generator. > > Thank you in advance > -- > Andreas Sunardi > > > >

Aug. 30, 2017

Re: [Pharo-users] [Pillar] How do I open the Pillar editor in Pharo 6?

by Offray Vladimir Luna CÃ¡rdenas

Works pretty well! See the screen below. Now I'm pretty short on time, but I wonder how to make the Contents tab, the default view for markup nodes in Grafoscopio and how to enable autosaving when an edit is done in such tab. Cheers, Offray On 29/08/17 15:59, Tudor Girba wrote: > Hi, > > I did not check what is in the Catalog, but you can load the #stable > version through Metacello like this: > > Metacello new > smalltalkhubUser: 'Pier' project: 'Pillar';Â > configuration: 'Pillar'; > version: #stable; > load. > > If you inspect a .pillar or .pier file and you get something as seen > below. In this specific case, I clicked on the picture reference (the > one with magenta) and I got the preview to the right. > > > Cheers, > Doru > > >> On Aug 29, 2017, at 10:31 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: >> >> I did not know it :) so this is cool. >> Today we improved the makefile logic and I'm about to finish a hack to >> give the possibility to the makefile to be fully generic. >> After I will finally look at Luc makefile generator because we want to >> move more logic to Pharo. >> >> Stef >> >> On Tue, Aug 29, 2017 at 2:20 PM, H. Hirzel <hannes.hirzel(a)gmail.com >> <mailto:hannes.hirzel@gmail.com>> wrote: >>> On 8/28/17, Norbert Hartl <norbert(a)hartl.name >>> <mailto:norbert@hartl.name>> wrote: >>>> >>>>> Am 26.08.2017 um 12:56 schrieb Tudor Girba <tudor(a)tudorgirba.com >>>>> <mailto:tudor@tudorgirba.com>>: >>>>> >>>>> In an image having Pillar, inspect a Pillar file. Something like this: >>>>> >>>>> âpath/to/file.pillar' asFileReference >>>>> >>>> I downloaded a 6.1 image, loaded pillar from catalog and inspected >>>> >>>> 'foo.pillar' asFileReference >>>> >>>> and I get >>>> >>> >>> The same result here. >>> >>>> >>>> Looks like there are additional steps needed. >>>> >>>> Norbert >>>> >>> >>> >>> If I do >>> >>> >>> Â Â PRPillarParser parse: >>> Â Â 'myExample.pillar' asFileReference contents >>> >>> >>> I get a nice display of the Pillar Document Object Model and the >>> results after using different exporter objects (HTML, DeckJS, >>> Markdown, AsciiDoc, Beamer, LaTeX) >>> >>> But no Pillar editor. >>> >>> --Hannes >> > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > www.feenk.com > > "There are no old things, there are only old ways of looking at them." > > > >

Aug. 30, 2017

Re: [Pharo-users] [Pillar] How do I open the Pillar editor in Pharo 6?

by Tudor Girba

Hi, I did not check what is in the Catalog, but you can load the #stable version through Metacello like this: Metacello new smalltalkhubUser: 'Pier' project: 'Pillar'; configuration: 'Pillar'; version: #stable; load. If you inspect a .pillar or .pier file and you get something as seen below. In this specific case, I clicked on the picture reference (the one with magenta) and I got the preview to the right. Cheers, Doru > On Aug 29, 2017, at 10:31 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > I did not know it :) so this is cool. > Today we improved the makefile logic and I'm about to finish a hack to > give the possibility to the makefile to be fully generic. > After I will finally look at Luc makefile generator because we want to > move more logic to Pharo. > > Stef > > On Tue, Aug 29, 2017 at 2:20 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >> On 8/28/17, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>>> Am 26.08.2017 um 12:56 schrieb Tudor Girba <tudor(a)tudorgirba.com>: >>>> >>>> In an image having Pillar, inspect a Pillar file. Something like this: >>>> >>>> âpath/to/file.pillar' asFileReference >>>> >>> I downloaded a 6.1 image, loaded pillar from catalog and inspected >>> >>> 'foo.pillar' asFileReference >>> >>> and I get >>> >> >> The same result here. >> >>> >>> Looks like there are additional steps needed. >>> >>> Norbert >>> >> >> >> If I do >> >> >> PRPillarParser parse: >> 'myExample.pillar' asFileReference contents >> >> >> I get a nice display of the Pillar Document Object Model and the >> results after using different exporter objects (HTML, DeckJS, >> Markdown, AsciiDoc, Beamer, LaTeX) >> >> But no Pillar editor. >> >> --Hannes > -- www.tudorgirba.com www.feenk.com "There are no old things, there are only old ways of looking at them."

Aug. 29, 2017