This is an interesting problem. There is currently no simple way of executing a message at compile-time instead of at runtime in Pharo, which is useful to have settings but no runtime overhead. I did a simple extension for opal compiler for this purpose, adding the message Cvalue, which is compiled by Opal either to its receiver's block value or the result of its value depending on the result of #allowPrecompilation sent to its class using AST manipulation before the semantic analysis. Example: MyClass>>#example ^ [ Smalltalk vm class ] Cvalue if MyClass allowPrecompilation answers true, it is compiled to: ^ VirtualMachine if MyClass allowPrecompilation answers false, it is compiled to: ^ Smalltalk vm class if MyClass does not use the compiler extension, Cvalue is implemented as ^ self value on BlockClosure. In your case it's slightly different, if you write [ Processor outputDebugLine: 'Trace something' ] Cvalue. It would either compile to the body of the block or evaluate the expression at compile-time, and you don't want to evaluate the expression at compile-time but just delete it. I believe something similar to what I did could solve your problem. However, it's difficult to do something easy to read and to use without having to extend too much the Smalltalk language... Here I added a special selector which is an important constraint so I don't think such code should be in the base image. If you're interested, the code is on Smalltalkhub ClementBera/NeoCompiler, you need to recompile the NeoCompiler examples once they're loaded to have them working, then you can look at the bytecode generated in NeoCompilerExample>>#example and NeoCompilerExample2>>#example to easily understand what is compiled. If you change NeoCompiler>>#precompile: to replace the 'aBlock CValue' expression by (RBLiteralNode value: nil) instead of the result of the expression it should do what you want. Now as I said this is not difficult to implement the problem is how to do it without having extensions and constraints in the Smalltalk semantics. 2015-06-13 13:20 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>:
I know we usually have the debugger in front of us - but sometimes a
trace or log is
required to see where code crashes. Think of a headless situation in a webserver or a small device like the pi where you want to reduce the performance overhead.
This leads to several questions: - Is something like this feasible/already possible in Pharo? - Any pointers on how Opal does optimizations? Do we have similar optimizations (removing code that could not be reached) that could be used.
The only optimisation we do is that we do not compile a
push pop
for variables (and even blocks) that are compiled for âeffectâ as there is no effectâ¦
One could of course add support for a special case like that.
But what I donât really like is that all this would require explicit recompilation⦠and it would be always globalâ¦
Marcus