April 2018 - Pharo-users - lists.pharo.org

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

Re: [Pharo-users] Literals

by Esteban A. Maringolo

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" :) 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

Re: [Pharo-users] [Voyage] Possible to save an OrderedCollection?

by sergio ruiz

Ah.. ok. this did it.. So, this works, meaning that the production code i have in place is the problem.. I must have a loop somewhere.. I canât find it for the life of me.. On April 27, 2018 at 4:10:53 PM, Esteban Lorenzano (estebanlm(a)gmail.com) wrote: did you add the property after doing some tests?Â in that case, you need to reset Voyage cachÃ©. ---- peace, sergio photographer, journalist, visionary Public Key:Â http://bit.ly/29z9fG0 #BitMessageÂ BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.codeandmusic.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

April 27, 2018

Re: [Pharo-users] [Voyage] Possible to save an OrderedCollection?

by Esteban Lorenzano

> On 27 Apr 2018, at 15:30, sergio ruiz <sergio.rrd(a)gmail.com> wrote: > > Hi, esteban.. > > In this case, the persisted object is TestBox.. > > it does show up just fine in Mongo, but the OrderedCollection of points does not. did you add the property after doing some tests? in that case, you need to reset Voyage cachÃ©. usually, VORepository current flush will do it Esteban > > On April 27, 2018 at 8:57:26 AM, Esteban Lorenzano (estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>) wrote: > >> >> what you need to save is the persistent object, the one marked as âisVoyageRootâ in class side. > ---- > peace, > sergio > photographer, journalist, visionary > > Public Key: http://bit.ly/29z9fG0 <http://bit.ly/29z9fG0> > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > http://www.codeandmusic.com <http://www.codeandmusic.com/> > http://www.twitter.com/sergio_101 <http://www.twitter.com/sergio_101> > http://www.facebook.com/sergio101 <http://www.facebook.com/sergio101>

April 27, 2018

Re: [Pharo-users] #ast vs. #parseTree

by Sean P. DeNigris

Marcus Denker-4 wrote > I will add commentsâ¦ I got confused by this again and created an issue: https://pharo.manuscript.com/f/cases/21806/Document-Difference-between-ast-… And then Peter Uhnak reminded me on Discord about this thread. I'm happy to add the comments, but not sure I understand the issue well enough. IIUC #ast is cached, but #parseTree is not. What I don't understand is the purpose of this difference and when one would use one over the other. For example, when, if ever, would a user want to access a CM's #ast (as opposed to #parseTree) and could modifying it create problems? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 27, 2018