- Pharo-users - lists.pharo.org

Re: [Pharo-users] Engineering notation

by Dimitris Chloupis

Nope I did not know that. I don't see my self using it any time soon because I like my code as English like as possible but It definitely can be useful in some cases. On Wed, Aug 30, 2017 at 11:49 PM Andreas Sunardi <a.sunardi(a)gmail.com> wrote: > 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. 31, 2017

Re: [Pharo-users] Engineering notation

by Peter UhnÃ¡k

Keep in mind that autoformatting will add the space. On Thu, Aug 31, 2017 at 8:54 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > yes, some people use > > 1halt. > +1halt. ;)

Aug. 31, 2017

Re: [Pharo-users] Engineering notation

by Marcus Denker

yes, some people use 1halt. instead of self halt as it is less characters to typeâ¦ Marcus > On 30 Aug 2017, at 22:48, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: > > 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. 31, 2017

Using different C libraries

by Andreas Sunardi

In Pharo 6's bin/pharo script, there is the following comment: # On some linuxes there multiple versions of the C library. If the image uses # libc (e.g. through the FFI) then it must use the same version that the VM uses # and so it should take precedence over /lib libc. This is done by setting # LD_LIBRARY_PATH appropriately, based on ldd's idea of the libc use by the VM My background story is I want to run Pharo 6, needing glibc > 2.15, in CentOS 6 that has glibc 2.12. I've built and installed 2.17 locally. (in another email thread Esteban has provided a better solution, which I haven't tried). I'm not sure if the comment is only referring to 32-bit and 64-bit versions or different glibc versions. Is it intended for user to be able to use different C library versions, as in glibc 2.15 vs 2.17 vs. 2.19? If it is, I claim it does not work and I'm curious if there is desire to support it. (It isn't an issue anymore for me and I can share my story how I got it to work. It isn't a clean way by any means, but hopefully it provides enough information) -- Andreas

Aug. 30, 2017

Pharo 6 FileSystem>>changeDirectory: is missing

by Andreas Sunardi

I found FileSystem class has changed from Pharo 5 to Pharo 6. I've been using FileSystem>>changeDirectory to make my program (Pharo 5) runs in the current working directory (thus able to find local files). This is now broken because #changeDirectory doesn't exist anymore. The change seems intentional. Question: Is there a different way in Pharo 6 do set working directory or is this a bug? -- Andreas

Aug. 30, 2017

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