>>> 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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
14 matches
Mail list logo