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

Fernando Olivero fernando.olivero at usi.ch
Thu Aug 16 17:31:13 CEST 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 at 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 at inria.fr> wrote:
>>>
>>> On Aug 16, 2012, at 9:32 AM, Fernando Olivero <fernando.olivero at 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
>>>
>>
>>



More information about the Pharo-project mailing list