This is amazing work! Thank you! I am an outsider in this topic, but I would kindly ask everyone to take a moment and consider the achievement. This is the first important sign of a long, tedious and highly undervalued work towards a goal set essentially from the very beginning of Pharo. It might not appear glamorous, but it certainly is a cornerstone. It is precisely this type of work that places Pharo in a land of its own. Doru On Wed, Oct 16, 2013 at 12:05 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:

This opens a wide range of improvements. The future will be bright :). Thanks clement, camillo and marcus for this effort. Opal + slots will be really sexy.

Stef

...

Bravo!

Thierry

Le 16/10/2013 11:15, Marcus Denker a écrit :

...

Hi,

You can now do:

ScriptLoader new unloadPackageNamed: 'CompilerTests'. ScriptLoader new unloadPackageNamed: 'Compiler'.

and the system continues to work.

Marcus

-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

-- www.tudorgirba.com "Every thing has its own flow"

+10 On 16 Oct 2013, at 13:59, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

Well said!

Stef

On Oct 16, 2013, at 12:43 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

...

This is amazing work! Thank you!

I am an outsider in this topic, but I would kindly ask everyone to take a moment and consider the achievement.

This is the first important sign of a long, tedious and highly undervalued work towards a goal set essentially from the very beginning of Pharo. It might not appear glamorous, but it certainly is a cornerstone.

It is precisely this type of work that places Pharo in a land of its own.

Doru

On Wed, Oct 16, 2013 at 12:05 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: This opens a wide range of improvements. The future will be bright :). Thanks clement, camillo and marcus for this effort. Opal + slots will be really sexy.

Stef

...

Bravo!

Thierry

Le 16/10/2013 11:15, Marcus Denker a écrit :

...

Hi,

You can now do:

ScriptLoader new unloadPackageNamed: 'CompilerTests'. ScriptLoader new unloadPackageNamed: 'Compiler'.

and the system continues to work.

Marcus

-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

-- www.tudorgirba.com

"Every thing has its own flow"

Too bad :( One of the most brilliant anti-pattern onto which I burnt so many brain cells is gone, how are we going to teach good coding practices by counter examples. ;) 2013/10/16 Sean P. DeNigris <sean@clipperadams.com>

Stéphane Ducasse wrote

...

Well said!

Indeed :)

----- Cheers, Sean -- View this message in context: http://forum.world.st/Old-Compiler-is-now-unload-able-tp4714845p4715017.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

And for the curious my favourite brainfuck was code:type: and its senders. Because the first time you read (code: index type: type), you wonder * why you pass a parameter index (that overrides inst var index, but most caller invoke with index inst. var.) * with the key code: * since there is also an inst var named code that's really troubling... Also because there is a cryptic use of negated type on return And once you start analyzing senders, and inst var refs, you're puzzled... To decipher, code:type: answers an encoded bytecode, made from an index (temp index, inst var index etc..) and a type (load inst var, load temp var, etc...) thus its name code... Now, I've contemplated this code too much, and it almost sounds familiar, I can hardly remember how impenetrable it was. But make you a pleasure, put a newbie in front of it. To me, this a a very clever factorisation of bytecode encoding - much too clever - much too obfuscated - and I bet we can do much much clearer with not much more code. But I don't have to prove anything, there is Opal already... 2013/10/16 Stéphane Ducasse <stephane.ducasse@inria.fr>

...

Too bad :( One of the most brilliant anti-pattern onto which I burnt so many brain cells is gone, how are we going to teach good coding practices by counter examples. ;)

:) We should continue to build the new generation it is more exciting and now I can start to invest in reading the compiler code.

Stef

On Oct 17, 2013, at 7:49 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

Now have a look at Opal and help us making better because there are still edge corners and little bugs.

The most important thing to understand is that Opal is not perfect… it's just a little bit better than the old compiler. The idea is not perfection (because is does not exist), but to just have some infrastructure that allows us to build on top. (e.g. reviving the old Reflectivity stuff, as one example). For bugs, we have - temps defined in ifTrue: are compiled with the wrong offset in some case (I think when there are other blocks defining a temp with the same name) - Christoph saw some case with problems in to:do: but I have not yet been able to even find an example to re-create the problem - when stepping in the debugger, temp vars are sometimes looked up in the wrong scope. I think this has to do with #stepToSendOrReturn when you are entering a block will run until the first send of the new block, which is too far. For improvements: -> IR instruction should store *range* of the bc offset they generate, as they can generate more than one (this would simplify finding an IR instruction for a pc offset when doing bc->text mapping for the debugger) -> IRIntepreter should be an IRVisitor, clean up the dual visiting/interpreting interface -> Semantic analysis: TempVars should not have index (it is left over from pre-closure times and only used for sorting the variables at the end), Sub=case: Decide which implementation of a sorted dictionary to integrate in Pharo3 Big picture (unlikely to happen) --------------- -> move all optimzations to the IR level (Controll Flow Graph) -> same for some of the analysis related to blocks (e.g. detecting escaping writes in loops should much more beautiful of a CFG than the AST). But then, it works even if is a bit convoluted now. After getting rid of old Compiler ------------------------------------------ -> remove #failBlock: -> compiler should not care about #category, it only compiles. -> all users of RBScanner and RBParser should use the OpalCompiler facade or APIs on CompiledMethod (#ast). (this will allow us to replace the RBParser as we like, e.g. to experiment with PetitParser)