But isn't BC->IR a trivial 1 to 1 mapping?
IR->AST is the difficult part because of inlining...
But in most cases this should be un-necessary no?

Indeed, if you get the source code + byte code.
then you can just check integrity like this:
� � 1) compile source->AST->(IR1->)BC1
� � 2) check BC1=BC
� � � � � ifTrue: [proceed with AST]
� � � � � ifFalse: [invoke decompiler BC->IR->AST]

Nicolas

2013/1/28 Marcus Denker <marcus.denker@inria.fr>:

> � maybe others are interested.
>
> Begin forwarded message:
>
> From: Marcus Denker <marcus.denker@inria.fr>
> Subject: More progress...
> Date: January 28, 2013 1:07:19 PM GMT+01:00
> To: "pharo-compiler@lists.gforge.inria.fr"
> <pharo-compiler@lists.gforge.inria.fr>
>
> Hi,
>
> Lots of progress�
>
> -> BC to Text mapping (highlighting in the debugger)
> � � Instead of building the mapping in the code generator, we instead
> � � � � � � enhanced the AST and IR to have all the right information and
> needed
> � � � � � � mapping.
>
> � � This means: we can query the AST for "which statement generated the byte
> code at offset 24?"
> � � Or "which BlockNode is the one for this Context?".
>
> � � The AST combined with the �Scope/Var annotations and the IR contains all
> information needed,
> � � � � � � and in cases where something is wrong it is easy to debug.
>
> -> Correct Temp Vars for Contexts (via the Scope/Var knowledge)
> � �For accessing temps in blocks in the debugger.
> � �Here we delegate queries to the annotated AST, this means the Debugger
> uses
> � � � � � �the same data structures as the compiler when it wants to know
> about e.g. local temps.
>
> One of the nice effects is that the needed machinery is much simpler:
>
> DebuggerMethodMap linesOfCode 164
> DebuggerMethodMapOpal linesOfCode 62
>
> it is actually so simple that in a second step, there is no need for
> DebuggerMethodMapOpal at all,
> � � � �the code can be moved directly to better places (e.g. MethodContext).
> Caching is handled by ASTCache.
>
> -> Error Handling is working. All the error handling (Parsing and Semantic)
> are handled the same as
> � � the old compiler.
>
> TODO
> => Pass over integration. Clean up the Compiler/Parser facades.
> � � �(We will first have the whole thing to be compatible to the old from
> the Compiler/Parser POV,
> � � � � � � � here more cleanups are following after we have the stuff in
> the image)
>
> => Pass over the decompiler. BC->IR is working, IR->AST needs to be checked.
>
> => Fix all showstoppers here:
> http://code.google.com/p/pharo-newcompiler/issues/list
>
>
> Marcus and Clement
>
>