Compiler evaluate: -> Smalltalk evaluate:
Hello, Recently in Pharo there was some tendency to replace Compiler evaluate: by Smalltalk evaluate:. Stef does not seem to agree with that. My question is which one is the correct convention to call #evaluate: ? thanks in advance, -- Andre Hora
On 07 Apr 2014, at 12:15, Andre Hora <andrehoraa@gmail.com> wrote:
Hello,
Recently in Pharo there was some tendency to replace Compiler evaluate: by Smalltalk evaluate:. Stef does not seem to agree with that. My question is which one is the correct convention to call #evaluate: ?
The problem is that Compiler is the old Compiler. There is Compiler and OpalCompiler. If you now hard-code Compiler, then the old compiler is used. Yes, this is not beautiful, but is is *very* hard to move a system to a new compiler and new API without some ugliness while doing so. In 4.0, we will remove the old compiler and then we can see how to make the API perfect. Marcus
Hello, I do not like 'Smalltalk evaluate:' either. One solution is to do 'self class compiler evaluate:'. 2014-04-07 5:02 GMT-07:00 Sergi Reyner <sergi.reyner@gmail.com>:
2014-04-07 11:51 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
In 4.0, we will remove the old compiler and then we can see how to make
the API perfect.
Will it be able to decompile by then?
I believe we cannot remove the old compiler if we do not provide something to access the method's sources. It will have either a decompiler or in-image sources if we achieve to compress them enough (recently a guy compressed the AST in 15Mb by sharing nodes, which is half the size of the sources).
Cheers, Sergi
On 7 avr. 2014, at 16:31, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
I do not like 'Smalltalk evaluate:' either.
One solution is to do 'self class compiler evaluate:'.
Yes IMO, calling #compiler on a class is the best solution since it returns a compiler with the options that the class defines.
2014-04-07 5:02 GMT-07:00 Sergi Reyner <sergi.reyner@gmail.com>: 2014-04-07 11:51 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
In 4.0, we will remove the old compiler and then we can see how to make the API perfect.
Will it be able to decompile by then?
I believe we cannot remove the old compiler if we do not provide something to access the method's sources.
It will have either a decompiler or in-image sources if we achieve to compress them enough (recently a guy compressed the AST in 15Mb by sharing nodes, which is half the size of the sources).
Cheers, Sergi
Thanks guys! On Apr 7, 2014 4:36 PM, "Camille Teruel" <camille.teruel@gmail.com> wrote:
On 7 avr. 2014, at 16:31, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
I do not like 'Smalltalk evaluate:' either.
One solution is to do 'self class compiler evaluate:'.
Yes IMO, calling #compiler on a class is the best solution since it returns a compiler with the options that the class defines.
2014-04-07 5:02 GMT-07:00 Sergi Reyner <sergi.reyner@gmail.com>:
2014-04-07 11:51 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
In 4.0, we will remove the old compiler and then we can see how to make
the API perfect.
Will it be able to decompile by then?
I believe we cannot remove the old compiler if we do not provide something to access the method's sources.
It will have either a decompiler or in-image sources if we achieve to compress them enough (recently a guy compressed the AST in 15Mb by sharing nodes, which is half the size of the sources).
Cheers, Sergi
On 07 Apr 2014, at 14:02, Sergi Reyner <sergi.reyner@gmail.com> wrote:
2014-04-07 11:51 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>: In 4.0, we will remove the old compiler and then we can see how to make the API perfect.
Will it be able to decompile by then?
Yes, we will solve that problem, too. Marcus
participants (5)
-
Andre Hora -
Camille Teruel -
Clément Bera -
Marcus Denker -
Sergi Reyner