Just mentioning another use-case:
getDatabaseInstance
^ (Production CifTrue: [Database] CifFalse: [MockDatabase]) new
Since I use conditional compilation more often than just precompiling
constants.
I don't see an equivalent of asMethodConstant AST manipulation at runtime
strategy in the image for this case right now but it's probably a couple
lines of code with Reflectivity.
On Sat, May 26, 2018 at 7:28 AM, Clément Bera <bera.clem...@gmail.com>
wrote:
>
>
> On Fri, May 25, 2018 at 10:44 PM, Esteban Lorenzano <esteba...@gmail.com>
> wrote:
>
>>
>>
>> On 25 May 2018, at 17:30, Clément Bera <bera.clem...@gmail.com> wrote:
>>
>> What about a preprocessor like the Java preprocessors ? The Truffle
>> project relies heavily on that for high performance Java and it's quite
>> nice. It's difficult to do that in Smalltalk right now.
>>
>> I think if you want to do what are asking for you just need to write a
>> bytecode compiler extension.
>>
>> I did something similar in the past to have precomputed constants through
>> AST manipulation at compilation time. You can find it here with examples:
>> http://smalltalkhub.com/#!/~ClementBera/NeoCompiler. Once the code is
>> loaded you need to recompile the examples (NeoCompilerExample
>> withAllSubclassesDo: #compileAll.). With it you can write code such as:
>> [ Smalltalk vm class ] Cvalue
>> And depending if the compiler allowsPrecompilation or not, the bytecode
>> compiler generates:
>> Smalltalk vm class
>> Or just a push literal with the precomputed value (the class
>> VirtualMachine).
>>
>>
>> this is not what #asMethodConstant provides?
>>
>
> Can you turn asMethodConstant On and Off so you have the constant in
> production and not a development time ? Typically at development time I
> change the constants generated a lot and I don't want to waste time
> recompiling all the time.
>
> But yeah, my project is from 2014. I guess instead of preprocessing you
> could do everything at runtime with AST manipulation/recompilation like
> in asMethodConstant.
>
> The main point of preprocessing IMO is to control performance, it's just
> easier for me to just look at the generated bytecode and change the
> preprocessor until it gets what I want, it's not always easy to run code
> that will change your method at runtime quickly so you can look at the
> bytecode generated.
>
> Anyway, I am not convinced at all something like that should be in the
> base image.
>
>
>>
>> Esteban
>>
>> In the end I decided not to use this, but you can use it and extend it to
>> support more than just constants (any AST manipulation is possible).
>> Just checked it works in Pharo 6.
>>
>> On Fri, May 25, 2018 at 4:26 PM, Stephan Eggermont <step...@stack.nl>
>> wrote:
>>
>>> Debiller 777 <ozovozovozo...@gmail.com>
>>> wrote:
>>> > Well, I've already asked about adding new literals to pharo or
>>> Smalltalk in
>>> > general, however this time I have a better idea:
>>> > macros. Can they be added? Because if I understand correctly they may
>>> be
>>> > the only way to do that.
>>>
>>> Why do you think they would be a good idea? We have powerful
>>> meta-programming facilities that are well understood and somewhat
>>> supported
>>> by tooling. How do we get value out of macros?
>>>
>>> Stephan
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Clément Béra
>> https://clementbera.github.io/
>> https://clementbera.wordpress.com/
>>
>>
>>
>
>
> --
> Clément Béra
> https://clementbera.github.io/
> https://clementbera.wordpress.com/
>
--
Clément Béra
https://clementbera.github.io/
https://clementbera.wordpress.com/
