Old Compiler is now unload able!

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Old Compiler is now unload able!

Marcus Denker-4
Hi,

You can now do:

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

and the system continues to work.


        Marcus

signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Old Compiler is now unload able!

Goubier Thierry
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

Reply | Threaded
Open this post in threaded view
|

Re: Old Compiler is now unload able!

NorbertHartl
In reply to this post by Marcus Denker-4

Am 16.10.2013 um 11:15 schrieb Marcus Denker <[hidden email]>:

> Hi,
>
> You can now do:
>
> ScriptLoader new unloadPackageNamed: 'CompilerTests'.
> ScriptLoader new unloadPackageNamed: 'Compiler'.
>
> and the system continues to work.
>

Very good. So this is kind of a "real" start for opal, isn't it?

Norbert

Reply | Threaded
Open this post in threaded view
|

Re: Old Compiler is now unload able!

Marcus Denker-4

On Oct 16, 2013, at 11:19 AM, Norbert Hartl <[hidden email]> wrote:

>
> Am 16.10.2013 um 11:15 schrieb Marcus Denker <[hidden email]>:
>
>> Hi,
>>
>> You can now do:
>>
>> ScriptLoader new unloadPackageNamed: 'CompilerTests'.
>> ScriptLoader new unloadPackageNamed: 'Compiler'.
>>
>> and the system continues to work.
>>
>
> Very good. So this is kind of a "real" start for opal, isn't it?
>
Hmm… when we finally remove it and use that chance to clean up the APIs…
(e.g. get rig of DebuggerMethodMap, failBlock: and more…)

        Marcus


signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Old Compiler is now unload able!

Stéphane Ducasse
In reply to this post by Goubier Thierry
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
>


Reply | Threaded
Open this post in threaded view
|

Re: Old Compiler is now unload able!

Tudor Girba-2
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 <[hidden email]> 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
>





--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: Old Compiler is now unload able!

Stéphane Ducasse
Well said!

Stef

On Oct 16, 2013, at 12:43 PM, Tudor Girba <[hidden email]> 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 <[hidden email]> 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
>





--

"Every thing has its own flow"

Reply | Threaded
Open this post in threaded view
|

Re: Old Compiler is now unload able!

Sven Van Caekenberghe-2
+10

On 16 Oct 2013, at 13:59, Stéphane Ducasse <[hidden email]> wrote:

> Well said!
>
> Stef
>
> On Oct 16, 2013, at 12:43 PM, Tudor Girba <[hidden email]> 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 <[hidden email]> 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"
>


Reply | Threaded
Open this post in threaded view
|

Re: Old Compiler is now unload able!

Sean P. DeNigris
Administrator
In reply to this post by Stéphane Ducasse
Stéphane Ducasse wrote
Well said!
Indeed :)
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Old Compiler is now unload able!

Nicolas Cellier
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 <[hidden email]>
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.


Reply | Threaded
Open this post in threaded view
|

Re: Old Compiler is now unload able!

Stéphane Ducasse
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Old Compiler is now unload able!

Nicolas Cellier
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 <[hidden email]>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: Old Compiler is now unload able!

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


Stef
On Oct 16, 2013, at 10:21 PM, Nicolas Cellier <[hidden email]> wrote:

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 <[hidden email]>
> 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


Reply | Threaded
Open this post in threaded view
|

Re: Old Compiler is now unload able!

Marcus Denker-4

On Oct 17, 2013, at 7:49 AM, Stéphane Ducasse <[hidden email]> 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)






signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Old Compiler is now unload able!

Pavel Krivanek-3
In reply to this post by Tudor Girba-2
More than that. The RPackage-MCPackage unification and the important
Morphic-Base package remodularization was integrated.

Today will be written with golden letters to the memoirs of Pharo... :-)

-- Pavel

2013/10/16 Tudor Girba <[hidden email]>:

> 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
> <[hidden email]> 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"