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@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@inria.fr> wrote:
On Aug 16, 2012, at 9:32 AM, Fernando Olivero <fernando.olivero@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