Opal, custom compilers and class-side methods

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

Opal, custom compilers and class-side methods

camille teruel
Hi all,

With Opal, if you want to customize how methods are compiled into a class you can override #compilerClass on class-side:
MyClass class>>#compilerClass
^ MySpecialCompiler

However this custom compiler is not taken into account when compiling methods on the class-side:
MyClass class compilerClass ---> OpalCompiler
I was expecting to have the same compiler class for the metaclass. The consequence is that right now there is no way to specialize how methods are compiled in *one* metaclass.
Is it on purpose or is it a bug? 

Also is there cases where one wants instance-side methods and class-side methods to be compiled with different compiler classes?
My rough guess is that in most cases you want the same compiler class, but I don't fell confortable forcing that.
So I propose to add a method #classSideCompilerClass:
Class>>#classSideCompilerClass
^ self compilerClass

Then compilerClass can be implemented for metaclasses:
Metaclass>>#compilerClass
^ self instanceSide classSideCompilerClass

Likewise, if I override compilerClass, it is taken into account for both instance-side and class-side methods but I can still say that I want a different compiler for class-side methods by overriding classSideCompilerClass. Tell me what you think about it and if you're ok, I open a bug entry with the slice.

Cheers,
Camille
 
Reply | Threaded
Open this post in threaded view
|

Re: Opal, custom compilers and class-side methods

Marcus Denker-4

On 27 Aug 2014, at 17:53, Camille Teruel <[hidden email]> wrote:

Hi all,

With Opal, if you want to customize how methods are compiled into a class you can override #compilerClass on class-side:
MyClass class>>#compilerClass
^ MySpecialCompiler

However this custom compiler is not taken into account when compiling methods on the class-side:
MyClass class compilerClass ---> OpalCompiler
I was expecting to have the same compiler class for the metaclass. The consequence is that right now there is no way to specialize how methods are compiled in *one* metaclass.
Is it on purpose or is it a bug? 

This is a bug, clearly.

Also is there cases where one wants instance-side methods and class-side methods to be compiled with different compiler classes?
I hope not… but the, could be interesting (e.g. when experimenting).
If the overhead is not large, this would be nice.

My rough guess is that in most cases you want the same compiler class, but I don't fell confortable forcing that.
So I propose to add a method #classSideCompilerClass:
Class>>#classSideCompilerClass
^ self compilerClass

Then compilerClass can be implemented for metaclasses:
Metaclass>>#compilerClass
^ self instanceSide classSideCompilerClass

Likewise, if I override compilerClass, it is taken into account for both instance-side and class-side methods but I can still say that I want a different compiler for class-side methods by overriding classSideCompilerClass. Tell me what you think about it and if you're ok, I open a bug entry with the slice.

Yes, this looks good!

Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Opal, custom compilers and class-side methods

camille teruel
Ok then, here the bug entry https://pharo.fogbugz.com/f/cases/13938/Opal-custom-compilers-and-class-side-methods
Slice in inbox

On 28 août 2014, at 10:24, Marcus Denker <[hidden email]> wrote:


On 27 Aug 2014, at 17:53, Camille Teruel <[hidden email]> wrote:

Hi all,

With Opal, if you want to customize how methods are compiled into a class you can override #compilerClass on class-side:
MyClass class>>#compilerClass
^ MySpecialCompiler

However this custom compiler is not taken into account when compiling methods on the class-side:
MyClass class compilerClass ---> OpalCompiler
I was expecting to have the same compiler class for the metaclass. The consequence is that right now there is no way to specialize how methods are compiled in *one* metaclass.
Is it on purpose or is it a bug? 

This is a bug, clearly.

Also is there cases where one wants instance-side methods and class-side methods to be compiled with different compiler classes?
I hope not… but the, could be interesting (e.g. when experimenting).
If the overhead is not large, this would be nice.

My rough guess is that in most cases you want the same compiler class, but I don't fell confortable forcing that.
So I propose to add a method #classSideCompilerClass:
Class>>#classSideCompilerClass
^ self compilerClass

Then compilerClass can be implemented for metaclasses:
Metaclass>>#compilerClass
^ self instanceSide classSideCompilerClass

Likewise, if I override compilerClass, it is taken into account for both instance-side and class-side methods but I can still say that I want a different compiler for class-side methods by overriding classSideCompilerClass. Tell me what you think about it and if you're ok, I open a bug entry with the slice.

Yes, this looks good!

Marcus

Reply | Threaded
Open this post in threaded view
|

Re: Opal, custom compilers and class-side methods

Uko2
In reply to this post by camille teruel

On 27 Aug 2014, at 17:53, Camille Teruel <[hidden email]> wrote:

Hi all,

With Opal, if you want to customize how methods are compiled into a class you can override #compilerClass on class-side:
MyClass class>>#compilerClass
^ MySpecialCompiler


I’ve missed this feature. This is super cool!

However this custom compiler is not taken into account when compiling methods on the class-side:
MyClass class compilerClass ---> OpalCompiler
I was expecting to have the same compiler class for the metaclass. The consequence is that right now there is no way to specialize how methods are compiled in *one* metaclass.
Is it on purpose or is it a bug? 

Also is there cases where one wants instance-side methods and class-side methods to be compiled with different compiler classes?
My rough guess is that in most cases you want the same compiler class, but I don't fell confortable forcing that.
So I propose to add a method #classSideCompilerClass:
Class>>#classSideCompilerClass
^ self compilerClass

Then compilerClass can be implemented for metaclasses:
Metaclass>>#compilerClass
^ self instanceSide classSideCompilerClass

Likewise, if I override compilerClass, it is taken into account for both instance-side and class-side methods but I can still say that I want a different compiler for class-side methods by overriding classSideCompilerClass. Tell me what you think about it and if you're ok, I open a bug entry with the slice.

Cheers,
Camille
 

Reply | Threaded
Open this post in threaded view
|

Re: Opal, custom compilers and class-side methods

Marcus Denker-4

On 28 Aug 2014, at 15:54, Yuriy Tymchuk <[hidden email]> wrote:


On 27 Aug 2014, at 17:53, Camille Teruel <[hidden email]> wrote:

Hi all,

With Opal, if you want to customize how methods are compiled into a class you can override #compilerClass on class-side:
MyClass class>>#compilerClass
^ MySpecialCompiler


I’ve missed this feature. This is super cool!


There is now in addition #compiler, an instance, not the class.

This is useful as you can set compiler options this way. e.g. InstructionStream does not need to use a subclass but can  do

compiler
"The JIT compiler needs to trap all reads to instance variables of contexts. As this check is costly, it is only done
in the long form of the bytecodes, which are not used often. In this hierarchy we force the compiler to always generate
long bytecodes"
^super compiler options: #(+ optionLongIvarAccessBytecodes)

Reply | Threaded
Open this post in threaded view
|

Re: Opal, custom compilers and class-side methods

camille teruel

On 28 août 2014, at 15:58, Marcus Denker <[hidden email]> wrote:


On 28 Aug 2014, at 15:54, Yuriy Tymchuk <[hidden email]> wrote:


On 27 Aug 2014, at 17:53, Camille Teruel <[hidden email]> wrote:

Hi all,

With Opal, if you want to customize how methods are compiled into a class you can override #compilerClass on class-side:
MyClass class>>#compilerClass
^ MySpecialCompiler


I’ve missed this feature. This is super cool!


There is now in addition #compiler, an instance, not the class.

Hum right... I should do the same thing with a #classSideCompiler then, right?


This is useful as you can set compiler options this way. e.g. InstructionStream does not need to use a subclass but can  do

compiler
"The JIT compiler needs to trap all reads to instance variables of contexts. As this check is costly, it is only done
in the long form of the bytecodes, which are not used often. In this hierarchy we force the compiler to always generate
long bytecodes"
^super compiler options: #(+ optionLongIvarAccessBytecodes)


Reply | Threaded
Open this post in threaded view
|

Re: Opal, custom compilers and class-side methods

Igor Stasenko
In reply to this post by Marcus Denker-4



On 28 August 2014 15:58, Marcus Denker <[hidden email]> wrote:

On 28 Aug 2014, at 15:54, Yuriy Tymchuk <[hidden email]> wrote:


On 27 Aug 2014, at 17:53, Camille Teruel <[hidden email]> wrote:

Hi all,

With Opal, if you want to customize how methods are compiled into a class you can override #compilerClass on class-side:
MyClass class>>#compilerClass
^ MySpecialCompiler


I’ve missed this feature. This is super cool!


There is now in addition #compiler, an instance, not the class.


Right. Factory method(s) like this are significantly more flexible, since implementor may want to provide a special way of initializing the compiler, you can't foresee via class standard '#new' protocol before hanging it over to user.
Giving just a class, make things quite hard and limiting.. especially in situation when developer wants to make a subclass which carries additional state , which needs to be initialized properly.

That's why, I prefer to use factory methods instead of 'SomethingClass' everywhere i need.

 
This is useful as you can set compiler options this way. e.g. InstructionStream does not need to use a subclass but can  do

compiler
"The JIT compiler needs to trap all reads to instance variables of contexts. As this check is costly, it is only done
in the long form of the bytecodes, which are not used often. In this hierarchy we force the compiler to always generate
long bytecodes"
^super compiler options: #(+ optionLongIvarAccessBytecodes)




--
Best regards,
Igor Stasenko.
Reply | Threaded
Open this post in threaded view
|

Re: Opal, custom compilers and class-side methods

Marcus Denker-4
In reply to this post by camille teruel

On 28 Aug 2014, at 16:03, Camille Teruel <[hidden email]> wrote:


On 28 août 2014, at 15:58, Marcus Denker <[hidden email]> wrote:


On 28 Aug 2014, at 15:54, Yuriy Tymchuk <[hidden email]> wrote:


On 27 Aug 2014, at 17:53, Camille Teruel <[hidden email]> wrote:

Hi all,

With Opal, if you want to customize how methods are compiled into a class you can override #compilerClass on class-side:
MyClass class>>#compilerClass
^ MySpecialCompiler


I’ve missed this feature. This is super cool!


There is now in addition #compiler, an instance, not the class.

Hum right... I should do the same thing with a #classSideCompiler then, right?

yes… but when #compiler is set, it should be valid for both instance and class side... 


This is useful as you can set compiler options this way. e.g. InstructionStream does not need to use a subclass but can  do

compiler
"The JIT compiler needs to trap all reads to instance variables of contexts. As this check is costly, it is only done
in the long form of the bytecodes, which are not used often. In this hierarchy we force the compiler to always generate
long bytecodes"
^super compiler options: #(+ optionLongIvarAccessBytecodes)



Reply | Threaded
Open this post in threaded view
|

Re: Opal, custom compilers and class-side methods

Marcus Denker-4

On 28 Aug 2014, at 16:32, Marcus Denker <[hidden email]> wrote:


On 28 Aug 2014, at 16:03, Camille Teruel <[hidden email]> wrote:


On 28 août 2014, at 15:58, Marcus Denker <[hidden email]> wrote:


On 28 Aug 2014, at 15:54, Yuriy Tymchuk <[hidden email]> wrote:


On 27 Aug 2014, at 17:53, Camille Teruel <[hidden email]> wrote:

Hi all,

With Opal, if you want to customize how methods are compiled into a class you can override #compilerClass on class-side:
MyClass class>>#compilerClass
^ MySpecialCompiler


I’ve missed this feature. This is super cool!


There is now in addition #compiler, an instance, not the class.

Hum right... I should do the same thing with a #classSideCompiler then, right?

yes… but when #compiler is set, it should be valid for both instance and class side... 

or not: as it seems to never have applied to the class side, it should be fine to keep them
separate.

that is, #compiler applies to instance side, and a classSideCompiler applies to the class side
by default people only override the instance side one, but when needed, they can override the classSide one, too.

(e.g. when you do a DSL, you want to still have the #initialize on the class side be untouched smalltalk in most
cases).
Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Opal, custom compilers and class-side methods

Tudor Girba-2
In reply to this post by Marcus Denker-4
+1

Objects are always better than classes :)

Doru


On Thu, Aug 28, 2014 at 2:58 PM, Marcus Denker <[hidden email]> wrote:

On 28 Aug 2014, at 15:54, Yuriy Tymchuk <[hidden email]> wrote:


On 27 Aug 2014, at 17:53, Camille Teruel <[hidden email]> wrote:

Hi all,

With Opal, if you want to customize how methods are compiled into a class you can override #compilerClass on class-side:
MyClass class>>#compilerClass
^ MySpecialCompiler


I’ve missed this feature. This is super cool!


There is now in addition #compiler, an instance, not the class.

This is useful as you can set compiler options this way. e.g. InstructionStream does not need to use a subclass but can  do

compiler
"The JIT compiler needs to trap all reads to instance variables of contexts. As this check is costly, it is only done
in the long form of the bytecodes, which are not used often. In this hierarchy we force the compiler to always generate
long bytecodes"
^super compiler options: #(+ optionLongIvarAccessBytecodes)




--

"Every thing has its own flow"