Hi
2018-05-26 8:46 GMT+03:00 Clément Bera <bera.clem...@gmail.com>:
> Just mentioning another use-case:
>
> getDatabaseInstance
> ^ (Production CifTrue: [Database] CifFalse: [MockDatabase]) new
>
I think following code will work:
getDatabaseInstance
^ (Production ifTrue: [Database] ifFalse: [MockDatabase])
asMethodConstant 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/
>
