- Pharo-users - lists.pharo.org

Re: [Pharo-users] Literals

by Richard O'Keefe

A On 28 April 2018 at 20:21, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > What would entail actually extending the syntax and adding the set literal? > > From my brief observations (when I was discussing this with OP on discord): > > * adding a new AST node > * extend RBParser > * extend IRMethod/IRTranslator... maybe generating bytecode for `{ ... } > asSet` instead would be enough? (not sure how debugger would react to this) > > anything else? Would VM changes be required? > > I added > â '{' binarySelector expr '.' ... '.' expr ['.'] '}' to my âcompiler because I was sick of other people being able to write stuff more elegantly in Python than I could in Smalltalk. Here the binarySelector controls what kind of set: = Set == IdentitySet ?= CaseInsensitiveSet < SortedSet (splay trees) > SortedSet (with comparison reversed) <> TernarySet (ternary search string for strings). I'm not happy with the syntax, but it's the least ugly I've been able to find. Having syntax only for Set would be so limiting there'd be no real point. So. No change to the scanner. No change to the abstract syntax trees. {== x. y} generates the same syntax tree that ((IdentitySet new: 2) add: x; add: y; yourself) would have done. And therefore no change to the back end code generator. The *only* change was the parsing routine that responds to '{'. The fundamental issue is WHY you want an extension to the syntax. In my case, the {binarySelector exprs} syntax for sets and corresponding #{binarySelector maplets} syntax for dictionaries were to let me approximate the brevity of Python and Javascript. I didn't need new *semantics*. In contrast, the ##(expr) syntax in Dolphin, Smalltalk/X, and whatever others does NOT offer brevity at all but DOES offer new semantics. To the limited, not to say derisory, extent to which I understand the Dolphin compiler, it does have a special StOptimizedNode type of AST node for ##(...) forms. I don't *think* any VM changes are needed, unless of course you want to be able to decompile the byte-code and recover the ##(expr) source. I don't have a Windows box any more, so I can't run Dolphin, sorry, just admire it. I can say that it takes care not to put literals inside a ##(expr) form in the literal table.

April 28, 2018

Re: [Pharo-users] Pharo 7 image, some more size reducation

by phil＠highoctane.be

On Sat, Apr 28, 2018 at 11:16 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > Hi, > > Pharo7 has proven to be a reliable host for Dr. Geo, and thank you for > your advices and helps. In the past weeks several screenshots were posted > on DrGeo twitter, all based on P7 built. Many notable tools or frameworks > like Tonel, Glamour tool kit, Calypso, Metacello, VM builts have proven to > be reliable. > > I am now at the point where I am thinking about a new public release. > Before that I want to squeeze a bit more the image. It is now about 36MB, > and I am looking at some advices to shrink it a bit more. What is done is > described there[1]. For example is it possible to remove Nautilus? > > A temporary built can be fetched from there[2], tests and feedbacks are > also greatly appreciated. > > Thanks > > Hilaire > > [1] https://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/f > iles/head:/src/DrGeoII-Installer/ Very interesting to read that code. (There is a typo in workstation at one point). > > > [2] https://www.dropbox.com/s/a4wb7c6od4fdl9k/DrGeo.app-18.06a.zip?dl=0 Trying it out :-) Phil > > > -- > Dr. Geo > http://drgeo.eu > > > > >

April 28, 2018

Re: [Pharo-users] Pharo 7 image, some more size reducation

by Hilaire

I have a 6 days old image. Aha, so it explained why the image suddenly get smaller. Thanks Hilaire Le 28/04/2018 Ã 11:20, Cyril Ferlicot D. a Ã©critÂ : > Nautilus was removed 7days ago: > https://github.com/pharo-project/pharo/pull/1231 > > Versionner and Kommiter 4days ago: > https://github.com/pharo-project/pharo/pull/1245 > > So if you use a more recent Pharo 7 image it'll be smaller:) -- Dr. Geo http://drgeo.eu

April 28, 2018

Re: [Pharo-users] Pharo 7 image, some more size reducation

by Cyril Ferlicot D.

Le 28/04/2018 Ã 11:16, Hilaire a Ã©critÂ : > Hi, > > Pharo7 has proven to be a reliable host for Dr. Geo, and thank you for > your advices and helps. In the past weeks several screenshotsÂ were > posted on DrGeo twitter, all based on P7 built. Many notable tools or > frameworks like Tonel, Glamour tool kit, Calypso, Metacello, VM builts > have proven to be reliable. > > IÂ am now at the point where I am thinking about a new public release. > Before that I want to squeeze a bit more the image. It is now about > 36MB, and I am looking at some advices to shrink it a bit more. What is > done is described there[1]. For example is it possible to remove Nautilus? > > A temporary built can be fetched from there[2], tests and feedbacks are > also greatly appreciated. > > Thanks > > Hilaire > > [1] > https://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/files/head:/src/… > > > [2] https://www.dropbox.com/s/a4wb7c6od4fdl9k/DrGeo.app-18.06a.zip?dl=0 > Hi Hilaire, Nautilus was removed 7days ago: https://github.com/pharo-project/pharo/pull/1231 Versionner and Kommiter 4days ago: https://github.com/pharo-project/pharo/pull/1245 So if you use a more recent Pharo 7 image it'll be smaller :) -- Cyril Ferlicot https://ferlicot.fr

April 28, 2018

Pharo 7 image, some more size reducation

by Hilaire

Hi, Pharo7 has proven to be a reliable host for Dr. Geo, and thank you for your advices and helps. In the past weeks several screenshotsÂ were posted on DrGeo twitter, all based on P7 built. Many notable tools or frameworks like Tonel, Glamour tool kit, Calypso, Metacello, VM builts have proven to be reliable. IÂ am now at the point where I am thinking about a new public release. Before that I want to squeeze a bit more the image. It is now about 36MB, and I am looking at some advices to shrink it a bit more. What is done is described there[1]. For example is it possible to remove Nautilus? A temporary built can be fetched from there[2], tests and feedbacks are also greatly appreciated. Thanks Hilaire [1] https://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/files/head:/src/… [2] https://www.dropbox.com/s/a4wb7c6od4fdl9k/DrGeo.app-18.06a.zip?dl=0 -- Dr. Geo http://drgeo.eu

April 28, 2018

Re: [Pharo-users] Literals

by Peter UhnÃ¡k

What would entail actually extending the syntax and adding the set literal? >From my brief observations (when I was discussing this with OP on discord): * adding a new AST node * extend RBParser * extend IRMethod/IRTranslator... maybe generating bytecode for `{ ... } asSet` instead would be enough? (not sure how debugger would react to this) anything else? Would VM changes be required? Peter On Sat, Apr 28, 2018 at 8:33 AM, Richard O'Keefe <raoknz(a)gmail.com> wrote: > The ## syntax that some Smalltalks have (Smalltalk/X, for > example, which calls it a Dolphin extension) is related > to Common Lisp's > #.e the result of evaluating e at *read* time, > taken as a literal > #,e the result of evaluating e at *load* time, > taken as a literal. > This reminds us there are several times that a ## form > could be evaluated: > - in the parser, when a method is parsed (before code > generation) > - when code is generated > - when code is generated AND whenever the image is > restored > - when the value is first needed (I'd prefer this) > - when the value is first needed in a thread (that > is, each thread that encounters it will evaluate > it just once, so each thread may see a different > value). > > One continuing annoyance in Smalltalk is that I cannot > put a Fraction, a Date, a Time, or a DateAndTime in a > literal. It would be nice to have #1969-07-20 or #1/2 > or #16:40:32 as literals and they contain no expressions > that could result in any confusion about when they are > evaluated and cannot be changed any more than a character > literal can. > > Curly brace syntax {e1. ... en} is an expression form, > not a literal form. Similar forms for sets of several > kinds and dictionaries of several kinds are supported > in my Smalltalk, and they are indeed useful, but they > are especially useful because they are *not* literals > but create new values every time. > > > On 28 April 2018 at 16:13, lb <liangbing64(a)126.com> wrote: > >> Hi, >> I think the question is >> How automaticly create literal's objects , not initialize. >> e.g >> 'aString' >> #aSymbol >> { anArray} >> #[] >> ............ >> >> Cheers Liang >> >> >

April 28, 2018

Re: [Pharo-users] Literals

by Richard O'Keefe

The ## syntax that some Smalltalks have (Smalltalk/X, for example, which calls it a Dolphin extension) is related to Common Lisp's #.e the result of evaluating e at *read* time, taken as a literal #,e the result of evaluating e at *load* time, taken as a literal. This reminds us there are several times that a ## form could be evaluated: - in the parser, when a method is parsed (before code generation) - when code is generated - when code is generated AND whenever the image is restored - when the value is first needed (I'd prefer this) - when the value is first needed in a thread (that is, each thread that encounters it will evaluate it just once, so each thread may see a different value). One continuing annoyance in Smalltalk is that I cannot put a Fraction, a Date, a Time, or a DateAndTime in a literal. It would be nice to have #1969-07-20 or #1/2 or #16:40:32 as literals and they contain no expressions that could result in any confusion about when they are evaluated and cannot be changed any more than a character literal can. Curly brace syntax {e1. ... en} is an expression form, not a literal form. Similar forms for sets of several kinds and dictionaries of several kinds are supported in my Smalltalk, and they are indeed useful, but they are especially useful because they are *not* literals but create new values every time. On 28 April 2018 at 16:13, lb <liangbing64(a)126.com> wrote: > Hi, > I think the question is > How automaticly create literal's objects , not initialize. > e.g > 'aString' > #aSymbol > { anArray} > #[] > ............ > > Cheers Liang > >

April 28, 2018

Re: [Pharo-users] Literals

by lb

Hi, I think the question is How automaticly create literal's objects , not initialize. e.g 'aString' #aSymbol { anArray} #[] ............ Cheers Liang

April 28, 2018

Re: [Pharo-users] Literals

by Ben Coman

On 28 April 2018 at 03:34, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > The guy who asked the question said: "...when you want to shorten some > object initialization" > > Using ClassVariable is an alternative way to shorten object > initialization, reading a ClassVariable is almost the same performance as > reading a literal, so that looked like a good alternative to me. Both the > ClassVariable and the literal have the same issues (same object so if you > mutate it you have to deal with it). > > But yes, it's not a new literal. > > For new literals, you can extend the compiler or hard patch thing: > > MyClass>>foo > ^ #bar > > (MyClass>>#foo) literalAt: ((MyClass>>#foo) literals indexOf: #bar) put: > Set new. > > MyClass new foo > > >>> a Set () > > Obviously it depends what you mean by literal, the latter code uses the > literal bytecode instruction, which does not make the pushed object a > literal object... > > Maybe pool dictionaries provide a half-way house... http://www.instantiations.com/PDFs/Smalltalk-Report/pools.pdf http://files.pharo.org/books-pdfs/updated-pharo-by-example/2017-01-14-Updat… cheers -ben

April 28, 2018

Re: [Pharo-users] Literals

by Richard Sargent

On Fri, Apr 27, 2018 at 3:58 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > oh, you were talking about how te VM views the object, > I was thinking in terms of how the compiler sees the text. > > So I'm talking about literals "syntax". > > Thanks anyway for the "trick" :) > Another common technique is a "once block". Teach Block how to evaluate itself once and to use its cached result the next time. It's not as fast as a literal, but it is a pretty effective way to have a clean implementation with as complex code as one could wish. Clear the cache when saving the image or at image start up or ... whenever seems good (such as when you change the implementation of what was cached. e.g. [Dictionary new at: #a put: self something; at: #b put: self somethingElse; yourself] once > > On 27/04/2018 16:34, ClÃ©ment Bera wrote: > > The guy who asked the question said: "...when you want to shorten some > > object initialization" > > > > Using ClassVariable is an alternative way to shorten object > > initialization, reading a ClassVariable is almost the same performance > > as reading a literal, so that looked like a good alternative to me. Both > > the ClassVariable and the literal have the same issues (same object so > > if you mutate it you have to deal with it). > > > > But yes, it's not a new literal. > > > > For new literals, you can extend the compiler or hard patch thing: > > > > MyClass>>foo > > ^ #bar > > > > (MyClass>>#foo) literalAt: ((MyClass>>#foo) literals indexOf: #bar) put: > > Set new. > > > > MyClass new foo > > > >>>> a Set () > > > > Obviously it depends what you mean by literal, the latter code uses the > > literal bytecode instruction, which does not make the pushed object a > > literal object... > > > -- > Esteban A. Maringolo > >

April 27, 2018