Opal, custom compilers and class-side methods
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
On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel@gmail.com> 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
Ok then, here the bug entry https://pharo.fogbugz.com/f/cases/13938/Opal-custom-compilers-and-class-side... Slice in inbox On 28 août 2014, at 10:24, Marcus Denker <marcus.denker@inria.fr> wrote:
On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel@gmail.com> 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
On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel@gmail.com> 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
On 28 Aug 2014, at 15:54, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel@gmail.com> 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)
On 28 août 2014, at 15:58, Marcus Denker <marcus.denker@inria.fr> wrote:
On 28 Aug 2014, at 15:54, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel@gmail.com> 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)
On 28 Aug 2014, at 16:03, Camille Teruel <camille.teruel@gmail.com> wrote:
On 28 août 2014, at 15:58, Marcus Denker <marcus.denker@inria.fr> wrote:
On 28 Aug 2014, at 15:54, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel@gmail.com> 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)
On 28 Aug 2014, at 16:32, Marcus Denker <marcus.denker@inria.fr> wrote:
On 28 Aug 2014, at 16:03, Camille Teruel <camille.teruel@gmail.com> wrote:
On 28 août 2014, at 15:58, Marcus Denker <marcus.denker@inria.fr> wrote:
On 28 Aug 2014, at 15:54, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel@gmail.com> 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
On 28 August 2014 15:58, Marcus Denker <marcus.denker@inria.fr> wrote:
On 28 Aug 2014, at 15:54, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel@gmail.com> 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.
+1 Objects are always better than classes :) Doru On Thu, Aug 28, 2014 at 2:58 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 28 Aug 2014, at 15:54, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel@gmail.com> 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)
-- www.tudorgirba.com "Every thing has its own flow"
participants (5)
-
Camille Teruel -
Igor Stasenko -
Marcus Denker -
Tudor Girba -
Yuriy Tymchuk