August 2012 - Pharo-dev - lists.pharo.org

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

by Stefan Marr

On 16 Aug 2012, at 19:29, StÃ©phane Ducasse wrote: > > On Aug 16, 2012, at 6:13 PM, Ralph Boland wrote: > >> I read a paper once (at the University of New Brunswick (Canada)) >> library in which the grammar for a language was used to construct a >> data compressor for syntaxly correct programs. The output was a >> compressed form of a parse/syntax tree with comments and white space >> included. Once decompressed, the tree could be used to reconstruct >> the source. I don't know if a compressed syntax tree would be very useful for >> programming tasks but it could be used to compress Smalltalk's source >> file and changes file. This assumes the time saved by filing in >> smaller chucks of programs segments would greater than the cost of >> decompression. > > do you have the reference? > One guy told me and in Oberon or something like that the ast was compressed long time ago. Franz, M. & Kistler, T. (1997), 'Slim Binaries', Commun. ACM 40 (12) , 87--94 . http://dl.acm.org/citation.cfm?id=265576 -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Aug. 16, 2012

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

by StÃ©phane Ducasse

On Aug 16, 2012, at 6:13 PM, Ralph Boland wrote: > I read a paper once (at the University of New Brunswick (Canada)) > library in which the grammar for a language was used to construct a > data compressor for syntaxly correct programs. The output was a > compressed form of a parse/syntax tree with comments and white space > included. Once decompressed, the tree could be used to reconstruct > the source. I don't know if a compressed syntax tree would be very useful for > programming tasks but it could be used to compress Smalltalk's source > file and changes file. This assumes the time saved by filing in > smaller chucks of programs segments would greater than the cost of > decompression. do you have the reference? One guy told me and in Oberon or something like that the ast was compressed long time ago. > I am designing and planning to implement a parser generator tool > (yes, another parser generator tool, something the world really needs ;-) ). This is another questions :) Why don't you want to improve petitparser? > If/when this project is complete perhaps I'll give this compressed AST > idea a try. > > Convincing the Squeak/Pharo world that it should be used is another matter > entirely. Since marcus PhD we want to have AST stored in the system, we just need to have a compressed version of AST to make an experiment and measure. Stef > > Ralph Boland >

Aug. 16, 2012

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

by Ralph Boland

I read a paper once (at the University of New Brunswick (Canada)) library in which the grammar for a language was used to construct a data compressor for syntaxly correct programs. The output was a compressed form of a parse/syntax tree with comments and white space included. Once decompressed, the tree could be used to reconstruct the source. I don't know if a compressed syntax tree would be very useful for programming tasks but it could be used to compress Smalltalk's source file and changes file. This assumes the time saved by filing in smaller chucks of programs segments would greater than the cost of decompression. I am designing and planning to implement a parser generator tool (yes, another parser generator tool, something the world really needs ;-) ). If/when this project is complete perhaps I'll give this compressed AST idea a try. Convincing the Squeak/Pharo world that it should be used is another matter entirely. Ralph Boland

Aug. 16, 2012

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

by Fernando Olivero

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

Aug. 16, 2012

[Pharo-project] [update 1.4] #14458

by Esteban Lorenzano

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

Aug. 16, 2012

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

by Levente Uzonyi

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

Aug. 16, 2012

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