- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)

by Camillo Bruni

On 2012-08-16, at 16:17, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Aug 16, 2012, at 4:05 PM, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > >> NICE! I would say lets go for it, 120MB is nothing nowadays. The IDE >> could be simplied and be more powerful. >> > > it kind of changes quite drasitically what you can do concerning behavioral reflection... > > As for space, compression should solve that quite nicely. or we simply build the cache lazily and flush it on image save for now. This scheme works pretty well and is dead simple to implement :P

Aug. 16, 2012

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)

by Marcus Denker

On Aug 16, 2012, at 4:05 PM, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > NICE! I would say lets go for it, 120MB is nothing nowadays. The IDE > could be simplied and be more powerful. > it kind of changes quite drasitically what you can do concerning behavioral reflection... As for space, compression should solve that quite nicely. > For example, in gaucho i'm using the ast for pretty printing of the > source, and for styling unsed variables differently, etc... > Yes... Marcus -- Marcus Denker -- http://marcusdenker.de

Aug. 16, 2012

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)

by Fernando Olivero

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 >

Aug. 16, 2012

Re: [Pharo-project] serializing DynamicVariables (Zinc so far)

by Sven Van Caekenberghe

Mariano, This is the same problem that occurred when the first code using ZnSignalProgress was integrated in Pharo 2.0, it failed the first time only. I just can't remember how we got past this, I guess by a manual intervention by one of the integrators. I could also be that Sean committed something. Anyway, Zinc is just using existing infrastructure here. Sven On 08 Aug 2012, at 14:45, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Guys...we are having a strange problem when exporting/importing Zinc. We have a problem when executing: > > executeRequestResponse > self logRequest. > ZnSignalProgress enabled > ...... > > The first time, #enable answers something wrong. The second time it is called, it seems to answer the correct value. > ZnSignalProgress is a subclass of DynamicVariable.... so I guess there is a black magic around this. > There is a hook in Fuel where I can substitute an object being serialized for something else. Should I substitute DynamicVariables with something when serialized? send #value before serialize it? nil something? > > Thanks in advance, > > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 16, 2012

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)

by Marcus Denker

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

Aug. 16, 2012

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)

by Fernando Olivero

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 >>> >>> >> >>

Aug. 16, 2012

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)

by Levente Uzonyi

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 >> >> > >

Aug. 15, 2012

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)

by Fernando Olivero

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 > >

Aug. 15, 2012

Re: [Pharo-project] [Pharo-users] [ESUG 2012] Pharo/Moose workshop on Sunday 26th

by Rafael Luque

> > On the other hand, is there an "official" hashtag to use with the tweets > related with the event? > > pick one and let us know :) > > I think #esug2012 is the obvious one. Perhaps it will be good idea to publish it in the event's website, so people that cannot attend the conference can follow it through Twitter. Rafa

Aug. 15, 2012

Re: [Pharo-project] new Cog VMs

by StÃ©phane Ducasse

Hi eliot thanks. Now could you reply to the questions we asked with igor about the bug in the eeInstantiate methods? I'm curious to understand the logic of turning around the GC triggering on newly created objects. Are you fixes related to that because this impacts Moose large images? Stef > 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 >

Aug. 14, 2012