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

2012-08-16 Thread Stéphane Ducasse
>>> 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.

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

2012-08-16 Thread 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.

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

2012-08-16 Thread 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 wi

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

2012-08-16 Thread 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, th

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

2012-08-16 Thread 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

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

2012-08-16 Thread 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 recen

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

2012-08-16 Thread Camillo Bruni
On 2012-08-16, at 16:17, Marcus Denker wrote: > > On Aug 16, 2012, at 4:05 PM, Fernando Olivero 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

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

2012-08-16 Thread Marcus Denker
On Aug 16, 2012, at 4:05 PM, Fernando Olivero 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 s

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

2012-08-16 Thread 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 w

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

2012-08-16 Thread Marcus Denker
On Aug 16, 2012, at 9:32 AM, Fernando Olivero 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 rememberits

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

2012-08-16 Thread 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 rememberitssource. yeah ifTrue:[ ^ #hurray]'. ast

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

2012-08-15 Thread 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

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

2012-08-15 Thread 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

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

2012-08-14 Thread Marcus Denker
On Aug 14, 2012, at 2:01 PM, Mariano Martinez Peck 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 > | oldKeywo