Hello Gabriel Let us embrace changes for real! We do not want to hear about the old compiler - why …. because it is … old :) Clement developed clean block optimizations in one afternoon with the new compiler. So this shows what it should. Stef

Hello,

In Pharo3, we replace the *whole* stuff by something new which is much easier to understand.

So In Pharo3, all this is not used (Encoder, the old AST, Parser (subclass(!) of Scanner)… The first update of Pharo4 will be to remove the old compiler and then take the opportunity to clean up the compiler API considerably (the old Compiler then will be available as a loadable package, but only for third-party tools like SLANG, not in a state where it could replace the new infrastructure, as the API changes will not be portable without huge changes).

So question: do you need to use the old Compiler?

A quick overview can be found here:

http://marcusdenker.de/publications/Bera13a-OpalIWST.pdf

One nice thing (I think) is that we replaced the source code mapping infrastructure completely with one based on the RB AST / Opal IR. It is (at least for me) much cleaner and easier to understand. And it is especially easier to hack.

Marcus

On 06 Nov 2013, at 02:27, Gabriel Bursztyn <gabrielbursztyn@hotmail.com> wrote:

...

Hi guys, I am new in this list. I have a question related to the sourceRanges dictionary in Encoder class. I can see every compiled method has each corresponding methodNode, which is an instance of a ParseNode child class. Every methodNode is formed by different parts represented by other classes also children of ParseNode, like AssignmentNode or MessageNode. when you decompile the method into the MethodNode, the Encoder instance saves the intervals corresponding to each of these parts. It not saves all the parts, just the AssignmentNode, MessageNode and ReturnNode. (other intervals like the ones corresponding to TempVariableNodes for instance are not saved). The weird thing is that it saves the intervals for the MessageNodes but for some reason they do not corresponds to the positions in the sourceText method (property of MethodNode). I read that this sourceRanges is used for debugging purposes, and I hadn't issues debugging my code. I do not know if it is a bug or I do not understand well the Parser class. I am using Pharo 2.0 and this code is also in squeak and cuis versions as well. Example:

I have created an example class with the following method: ExampleClass>>#method1: method1 | a | a := 1 + (2 * 3). ^ a

--- So if i inspect the rawSourceRanges:.. (ExampleClass>>#method1) methodNode rawSourceRanges, I have a dictionary with the following keys: a := 1 + (2 * 3). (AssignmentNode) --> 19 to 30 (so if i extract the characters from 19 to 30 in the sourceText I obtain the AssignmentNode text) 1 + (2 * 3) (MessageNode) --> 24 to 30 2 * 3 - (MessageNode) --> 28 to 29 ( it is not logic to have an interval for 2 characters if 2*3 (without spaces) has 3 characters. ^ a (ReturnNode) --> 34 to 35.

So the ASsignmentNode and ReturnNode have their corresponding sourceText interval but from MessageNodes, I cannot see the same. Can anyone of you explain me why or if it is a bug? If you would like to watch a little more, the sourceRanges is filled in the Encoder class, when the Parser is parsing a method.

thanks