Interesting... Thierry 2018-05-22 14:18 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>:

...

On 18 May 2018, at 10:39, Marcus Denker <marcus.denker@inria.fr> wrote:

Hi,

the #binding: API until now did not allow to shadow globals. But there is actually no reason to forbid that (and it can actually be interesting, e.g. to compile code where one class ref is switched to another).

The Pull Request does:

- add comment to OCExtraBindingScope - categorize tests - change #lookupVar: to allow shadowing of Globals. - change test to reflect the new behaviour

This means you can do:

result := Smalltalk compiler bindings: {(#Object -> Point)} asDictionary; evaluate: 'Object new'.

https://github.com/pharo-project/pharo/pull/1379

A second iteration now makes it work correctly for assignments:

https://github.com/pharo-project/pharo/pull/1397

Smalltalk compiler bindings: {(#test -> Point)} asDictionary; evaluate: 'test := 42'.

Marcus

Marcus, can you do inheritence / masking of a hierarchy of system dictionaries ? Could be used to make "kind of" sandboxes, around, say, user code so that it does not have the ability to override a certain system core. Thierry 2018-05-23 11:45 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>:

...

A second iteration now makes it work correctly for assignments:

https://github.com/pharo-project/pharo/pull/1397

Smalltalk compiler bindings: {(#test -> Point)} asDictionary; evaluate: 'test := 42’.

While #bindings: allows us now to add additional bindings or override global bindings from Smalltalk globals, there is another feature missing that would be nice: be able to set the global environment

I want to be able to tell the compiler: Do not use Smalltalk globals, but this SystemDictionary instead.

https://github.com/pharo-project/pharo/pull/1406

with this, we can create a SystemDictionary with just one binding in it:

environment := SystemDictionary new. environment at: #MyClass put: Point.

then we compile a method:

method := Smalltalk compiler environment: environment; compile: 'tt ^MyClass’.

and if we execute it, it shows that compilation used the environment:

return := method valueWithReceiver: nil arguments: #(). self assert: return equals: Point.

If we try to compile a ref to Object, we get a nil ref:

method := Smalltalk compiler environment: environment; compile: 'tt ^Object'. return := method valueWithReceiver: nil arguments: #(). self assert: return equals: nil.

But, as the Undeclared mechanism is not aware of it, it puts an undeclared for Object there.

In the same direction, all objects the compiler creates come still from Smalltalk globals (CompiledMethod, all Literals…).

But all this can be improved, we do pass the environment down the compiler chain already so that it is even available in the Parser/Scanner. Thus we could e.g. create Literals as instances from the classes in the environment. But how exactly has to be seen.

Marcus

Marcus Denker-4 wrote

method := Smalltalk compiler environment: environment; compile: 'tt ^MyClass’.

Awesome! Is it possible to override a global from /within/ a method (e.g. in a test)? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

On 23 May 2018, at 13:30, Thierry Goubier <thierry.goubier@gmail.com> wrote:

2018-05-23 13:20 GMT+02:00 Sean P. DeNigris <sean@clipperadams.com>:

...

Marcus Denker-4 wrote

...

method := Smalltalk compiler environment: environment; compile: 'tt ^MyClass’.

Awesome! Is it possible to override a global from /within/ a method (e.g. in a test)?

I think at the class level by manipulating that class compiler

Yes. You can override the class side method: in Behaviour, it is defined as compiler "Answer a compiler appropriate for source methods of this class." ^self compilerClass new environment: self environment; class: self so you can just compiler “Change the compiler environment " ^super compiler environment: self myEnvironment and it should work. an a per method bases, we can only manipulate the compiler via Pragmas to set options: <compilerOptions: #(+ optionInlineTimesRepeat)> for example.

(and forcing a method recompile...)

indeed.. I still believe that we should late-bind global access :-) Marcus

On 23 May 2018, at 13:53, Marcus Denker <marcus.denker@inria.fr> wrote:

...

On 23 May 2018, at 13:47, Marcus Denker <marcus.denker@inria.fr> wrote:

...

On 23 May 2018, at 13:30, Thierry Goubier <thierry.goubier@gmail.com> wrote:

2018-05-23 13:20 GMT+02:00 Sean P. DeNigris <sean@clipperadams.com>:

...

Marcus Denker-4 wrote

...

method := Smalltalk compiler environment: environment; compile: 'tt ^MyClass’.

Awesome! Is it possible to override a global from /within/ a method (e.g. in a test)?

I think at the class level by manipulating that class compiler

Yes. You can override the class side method:

in Behaviour, it is defined as

compiler "Answer a compiler appropriate for source methods of this class."

^self compilerClass new environment: self environment; class: self

so you can just

compiler “Change the compiler environment "

^super compiler environment: self myEnvironment

and it should work.

Here we can see, too, that we need to do more work. In Behaviour:

environment "Return the environment in which the receiver is visible" ^Smalltalk globals

For classes to automatically compile with the environment they are in, we somehow need to return here that environment…

This is already correct (Class overrides it, all classes have the ivar environment correctly set) Marcus

On 28 May 2018, at 12:07, Marcus Denker <marcus.denker@inria.fr> wrote:

...

Shortcomings: -> extensions are not treated, only the main package -> Not used much, for sure needs testing to see if this really works.

—> there might be other places in addition global #compilerClass: where we need to point to the overlay version For the complete “compile a method” it works, but I think there are other cases where it is not enough.

I think this one makes it really usable: https://github.com/pharo-project/pharo/pull/1455 <https://github.com/pharo-project/pharo/pull/1455> Now I can even put a halt in the semantic analysis which is called by syntax highlighting in the browser at each keystroke. Marcus

So what can we do with this? If you develop a compiler, it is always very annoying that any change that you do actually breaks the compiler if you do it wrong. Larger changes over multiple methods get quite hard to do.

One thing that we will soon have is the “accept for test” feature that I posted recently. Another idea is to use the #bindings: feature of the compiler.

I did small experiment, I added this method to the OpalCompiler class on the class side:

…..

And after that, you can put a #halt deep in the compiler (or do some change that needs multiple steps), yet compilation will not be affected. Most tests (not all) are writing in a way that they use classes from the package directly (they do not go via the global #compilerClass setting).

So this means that one can now change the compiler as much as one wants, test it by running tests and then be quite sure that it will not break anything.

Shortcomings: -> extensions are not treated, only the main package -> Not used much, for sure needs testing to see if this really works. -> Can we get rid of the #CompilerOverlay global?

I made a pull request: https://github.com/pharo-project/pharo/pull/1449 Marcus