- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)
by Fernando Olivero Aug. 16, 2012

Aug. 16, 2012

Yes, caching is what i do in my system. It would amazing that Pharo implements such a caching scheme for methods and their ast . If you evaluate the code i pasted before, you will note that it does preserve the actual source. RBMethodNode>>source ^ source instead, RBMethodNode>>formtattedSource , vists the ast to return the source. Fernando On Thu, Aug 16, 2012 at 4:20 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Thu, 16 Aug 2012, Fernando Olivero wrote: > >> NICE! I would say lets go for it, 120MB is nothing nowadays. The IDE >> could be simplied and be more powerful. > > Let's be a bit more realistic. The current garbage collector is choking if > you add 100 MB of small objects to your image. Caching the recently > accessed ASTs sounds like a better idea. > >> >> For example, in gaucho i'm using the ast for pretty printing of the >> source, and for styling unsed variables differently, etc... > > You didn't answer yet if RB's AST can reproduce the exact same source > string or not. > > > Levente > >> >> >> Fernando >> >> On Thu, Aug 16, 2012 at 9:35 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> On Aug 16, 2012, at 9:32 AM, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >>> >>>> I've been using RB, which allows to recreate on demand the ast, but in >>>> my system i cached those values. >>>> >>>> >>>> ast := RBParser parseMethod: 'parsingAMethod >>>> | yeah | >>>> yeah := self doesAMethodNode remember its source. >>>> yeah >>>> ifTrue:[ ^ #hurray]'. >>>> >>>> ast source. >>>> ast formattedCode. >>>> >>>> ast := (Object>>#at:) parseTree. >>>> ast source. >>>> ast formattedCode >>>> >>>> >>>> Regarding the memory usage, in my system only the methods which have a >>>> "method shape" opened in the IDE, store their ast, thus i cannot >>>> provide numbers of the overhead. But why should one extra object more >>>> per method be a problem? >>>> >>> >>> It's not one object... it's a tree. I did once a system that stored the AST for each method >>> (uncompressed) in addition to what is there now (CompiledMethod). >>> The system was 120MB instead of 20MB. (based on Squeak 3.9) >>> >>> Which means, even then smaller than Eclipse ;-) >>> >>> Marcus >>> >>> >>> -- >>> Marcus Denker -- http://marcusdenker.de >>> >> >>

1 0

[Pharo-project] [update 1.4] #14458
by Esteban Lorenzano Aug. 16, 2012

Aug. 16, 2012

14458 ----- Issue 6555: DNU on ctrl home / ctrl end http://code.google.com/p/pharo/issues/detail?id=6555

1 0

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)
by Fernando Olivero Aug. 16, 2012

Aug. 16, 2012

NICE! I would say lets go for it, 120MB is nothing nowadays. The IDE could be simplied and be more powerful. For example, in gaucho i'm using the ast for pretty printing of the source, and for styling unsed variables differently, etc... Fernando On Thu, Aug 16, 2012 at 9:35 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Aug 16, 2012, at 9:32 AM, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > >> I've been using RB, which allows to recreate on demand the ast, but in >> my system i cached those values. >> >> >> ast := RBParser parseMethod: 'parsingAMethod >> | yeah | >> yeah := self doesAMethodNode remember its source. >> yeah >> ifTrue:[ ^ #hurray]'. >> >> ast source. >> ast formattedCode. >> >> ast := (Object>>#at:) parseTree. >> ast source. >> ast formattedCode >> >> >> Regarding the memory usage, in my system only the methods which have a >> "method shape" opened in the IDE, store their ast, thus i cannot >> provide numbers of the overhead. But why should one extra object more >> per method be a problem? >> > > It's not one object... it's a tree. I did once a system that stored the AST for each method > (uncompressed) in addition to what is there now (CompiledMethod). > The system was 120MB instead of 20MB. (based on Squeak 3.9) > > Which means, even then smaller than Eclipse ;-) > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de >

4 3

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)
by Fernando Olivero Aug. 16, 2012

Aug. 16, 2012

I've been using RB, which allows to recreate on demand the ast, but in my system i cached those values. ast := RBParser parseMethod: 'parsingAMethod | yeah | yeah := self doesAMethodNode remember its source. yeah ifTrue:[ ^ #hurray]'. ast source. ast formattedCode. ast := (Object>>#at:) parseTree. ast source. ast formattedCode Regarding the memory usage, in my system only the methods which have a "method shape" opened in the IDE, store their ast, thus i cannot provide numbers of the overhead. But why should one extra object more per method be a problem? Fernando On Wed, Aug 15, 2012 at 11:10 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Wed, 15 Aug 2012, Fernando Olivero wrote: > >> Hi, great point Marcus. I was wondering why cant a compiled method >> know the "ast" that generated it? > > Would you store all ASTs in memory all the time or recreate it every time > on demand? > >> >> It would ease the queries + manipulation, in the tools a lot! >> >> CompiledMethod>>getSourceReplacingSelectorWith: aSelector >> .... >> >> would be instead: >> >> CompiledMethod>>withSelector: aSelector >> ^ (self ast withSelector: aSelector) source. > > Is there an implementation of AST that can reproduce the exact same source > code? > > > Levente > >> >> >> I've been using an AST, instead of the CompiledMethods directly for >> this reason, to deal with more expressive power. >> >> Fernando >> >> On Tue, Aug 14, 2012 at 2:56 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> On Aug 14, 2012, at 2:01 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> >>>> Hi guys. Today, there is a part of the system coupled with Compiler. Issue is: http://code.google.com/p/pharo/issues/detail?id=6110 >>>> >>>> Now, if you see the method: >>>> >>>> getSourceReplacingSelectorWith: newSelector >>>> | oldKeywords newKeywords args newSelectorWithArgs source oldSelector s | >>>> source := self sourceCode. >>>> oldSelector := self parserClass new parseSelector: source. >>>> oldSelector = newSelector ifTrue: [ ^ source ]. >>>> oldKeywords := oldSelector keywords. >>>> newKeywords := (newSelector ifNil: [self defaultSelector]) keywords. >>>> [oldKeywords size = newKeywords size] assert. >>>> args := (self methodClass parserClass new >>>> parseArgsAndTemps: source string notifying: nil) copyFrom: 1 to: self numArgs. >>>> newSelectorWithArgs := String streamContents: [:stream | >>>> newKeywords withIndexDo: [:keyword :index | >>>> stream nextPutAll: keyword. >>>> stream space. >>>> args size >= index ifTrue: [ >>>> stream nextPutAll: (args at: index); space]]]. >>>> s := source string readStream. >>>> oldKeywords do: [ :each | s match: each ]. >>>> args isEmpty ifFalse: [ s match: args last ]. >>>> ^newSelectorWithArgs trimBoth, s upToEnd >>>> >>>> The 2 magic lines are: >>>> >>>> oldSelector := self parserClass new parseSelector: source. >>>> oldSelector = newSelector ifTrue: [ ^ source ]. >>>> >>>> So, why we cannot just replace "self parserClass new parseSelector: source." with "self selector". Well, I think (talking with Guille) this ONLY because of Trait transformation/aliases that associates a selector with a method of a different selector. >>>> >>>> If this is the case, it means that 99% of the cases,"oldSelector = newSelector ifTrue: [ ^ source ]. " is true. Because those aliases are only used in one trait in all the image (). >>>> >>>> So...if that is the case, can't we get the oldSelector from elsewhere rather than needing to use the Compiler to get the selector from the source code ? >>>> >>> As we now encode the selector in the CompiledMethod itself, this can be relaced with >>> >>> oldSelector := self selector. >>> >>> >>> But what you have left is the arguments... >>> >>> args := (self methodClass parserClass new >>> parseArgsAndTemps: source string notifying: nil) copyFrom: 1 to: self numArgs. >>> >>> The only way to get the the argument names (temps) of a method is to compile the source... no way around it. >>> >>> (I personally think this is another example why bytecode as the model for reflection is just wrong) >>> >>> >>> Marcus >>> >>> >>> -- >>> Marcus Denker -- http://marcusdenker.de >>> >>> >> >>

2 1

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)
by Fernando Olivero Aug. 15, 2012

Aug. 15, 2012

Hi, great point Marcus. I was wondering why cant a compiled method know the "ast" that generated it? It would ease the queries + manipulation, in the tools a lot! CompiledMethod>>getSourceReplacingSelectorWith: aSelector .... would be instead: CompiledMethod>>withSelector: aSelector ^ (self ast withSelector: aSelector) source. I've been using an AST, instead of the CompiledMethods directly for this reason, to deal with more expressive power. Fernando On Tue, Aug 14, 2012 at 2:56 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Aug 14, 2012, at 2:01 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> Hi guys. Today, there is a part of the system coupled with Compiler. Issue is: http://code.google.com/p/pharo/issues/detail?id=6110 >> >> Now, if you see the method: >> >> getSourceReplacingSelectorWith: newSelector >> | oldKeywords newKeywords args newSelectorWithArgs source oldSelector s | >> source := self sourceCode. >> oldSelector := self parserClass new parseSelector: source. >> oldSelector = newSelector ifTrue: [ ^ source ]. >> oldKeywords := oldSelector keywords. >> newKeywords := (newSelector ifNil: [self defaultSelector]) keywords. >> [oldKeywords size = newKeywords size] assert. >> args := (self methodClass parserClass new >> parseArgsAndTemps: source string notifying: nil) copyFrom: 1 to: self numArgs. >> newSelectorWithArgs := String streamContents: [:stream | >> newKeywords withIndexDo: [:keyword :index | >> stream nextPutAll: keyword. >> stream space. >> args size >= index ifTrue: [ >> stream nextPutAll: (args at: index); space]]]. >> s := source string readStream. >> oldKeywords do: [ :each | s match: each ]. >> args isEmpty ifFalse: [ s match: args last ]. >> ^newSelectorWithArgs trimBoth, s upToEnd >> >> The 2 magic lines are: >> >> oldSelector := self parserClass new parseSelector: source. >> oldSelector = newSelector ifTrue: [ ^ source ]. >> >> So, why we cannot just replace "self parserClass new parseSelector: source." with "self selector". Well, I think (talking with Guille) this ONLY because of Trait transformation/aliases that associates a selector with a method of a different selector. >> >> If this is the case, it means that 99% of the cases,"oldSelector = newSelector ifTrue: [ ^ source ]. " is true. Because those aliases are only used in one trait in all the image (). >> >> So...if that is the case, can't we get the oldSelector from elsewhere rather than needing to use the Compiler to get the selector from the source code ? >> > As we now encode the selector in the CompiledMethod itself, this can be relaced with > > oldSelector := self selector. > > > But what you have left is the arguments... > > args := (self methodClass parserClass new > parseArgsAndTemps: source string notifying: nil) copyFrom: 1 to: self numArgs. > > The only way to get the the argument names (temps) of a method is to compile the source... no way around it. > > (I personally think this is another example why bytecode as the model for reflection is just wrong) > > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > >

2 1

[Pharo-project] [ESUG 2012] Pharo/Moose workshop on Sunday 26th
by Rafael Luque Aug. 15, 2012

Aug. 15, 2012

Hi all, I have just registered to attend the ESUG 2012 conference and I'd like to have more info about the Pharo/Moose Workshop that will be organized on Sunday, August 26th in order to plan the trip and accomodation. On the other hand, is there an "official" hashtag to use with the tweets related with the event? Thank you, Rafael Luque

2 2

[Pharo-project] new Cog VMs
by Eliot Miranda Aug. 14, 2012

Aug. 14, 2012

Hi All, please find new VMs in http://www.mirandabanda.org/files/Cog/VM/VM.r2585/. These VMs try and fix an occasional crash (try because the fix doesn't handle all cases yet), and at least turn it into an orderly exit with error message (no room on youngReferrers list/youngReferrers list overflowed) instead of a hard crash. ------------------------------------------------------------------------ Cog VM binaries as per VMMaker.oscog-eem.201/r2585. Make sure youngReferrersList has room for every method since become/cache implicit receiver can cause any method to gain a young reference. Do so by counting methods in the zone. Make overflowing the youngReferrers list a hard error (appears to happen quite often in Newspeak code). Fix assert in interpretMethodFromMachineCode. Fix bug in changeClassFrom:to: if receiver is a compact class instance with a large header. -- best, Eliot

2 1

[Pharo-project] Interest in another devroom at FOSDEM?
by Stephan Eggermont Aug. 14, 2012

Aug. 14, 2012

Hello, Feb. 2 & 3 2013 there will be FOSDEM again in Brussels. Last year I organized a devroom where all kind of smalltalk related developments were shown. If there is sufficient interest, I'll ask for one again. Please tell me if you'd like to come/present and what you'd like to see. Stephan Eggermont

6 6

[Pharo-project] Breaking another dependency to Compiler (related to Traits I think)
by Mariano Martinez Peck Aug. 14, 2012

Aug. 14, 2012

Hi guys. Today, there is a part of the system coupled with Compiler. Issue is: http://code.google.com/p/pharo/issues/detail?id=6110 Now, if you see the method: getSourceReplacingSelectorWith: newSelector | oldKeywords newKeywords args newSelectorWithArgs source oldSelector s | source := self sourceCode. oldSelector := self parserClass new parseSelector: source. oldSelector = newSelector ifTrue: [ ^ source ]. oldKeywords := oldSelector keywords. newKeywords := (newSelector ifNil: [self defaultSelector]) keywords. [oldKeywords size = newKeywords size] assert. args := (self methodClass parserClass new parseArgsAndTemps: source string notifying: nil) copyFrom: 1 to: self numArgs. newSelectorWithArgs := String streamContents: [:stream | newKeywords withIndexDo: [:keyword :index | stream nextPutAll: keyword. stream space. args size >= index ifTrue: [ stream nextPutAll: (args at: index); space]]]. s := source string readStream. oldKeywords do: [ :each | s match: each ]. args isEmpty ifFalse: [ s match: args last ]. ^newSelectorWithArgs trimBoth, s upToEnd The 2 magic lines are: oldSelector := self parserClass new parseSelector: source. oldSelector = newSelector ifTrue: [ ^ source ]. So, why we cannot just replace "self parserClass new parseSelector: source." with "self selector". Well, I think (talking with Guille) this ONLY because of Trait transformation/aliases that associates a selector with a method of a different selector. If this is the case, it means that 99% of the cases,"oldSelector = newSelector ifTrue: [ ^ source ]. " is true. Because those aliases are only used in one trait in all the image (). So...if that is the case, can't we get the oldSelector from elsewhere rather than needing to use the Compiler to get the selector from the source code ? thanks -- Mariano http://marianopeck.wordpress.com

2 1

[Pharo-project] Questions on Traits
by Noury Bouraqadi Aug. 14, 2012

Aug. 14, 2012

Hi, -Why new methods are compiled from the ones of traits? I remember that in the first implementation, when a trait was used by a class, new entries were introduced to the methodDict where the values are the compiled methods from the trait. Currently, a new compiled method is introduced with the exact code of the on from the trait. Why? -It is possible to compile a method that includes a super send in traits. Does it make sense? Noury -- http://twitter.com/#!/NouryBouraqadi http://www.kroobe.com/profile/noury Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite Please consider the environment before you print

4 5