How to use Environments?

Let me repeat my question which might have gone unnoticed in my
previous wall of text:

Why doesn't the global environment (Smalltalk globals) export anything
by default? Is there a reason at all, or was it simply forgotten at
some point (because "nobody uses Environments" anyway)?

Alternatively: Are there downsides of `Smalltalk globals exportSelf`
other than that you have to do it yourself in current Squeak images?

2016-09-23 17:28 GMT+02:00 Jakob Reschke <[hidden email]>:
> In the meantime, I figured out that the Smalltalk globals environment
> does not export anything. Hence, nothing can be imported from it by
> default.
>
> Further, I found this post [1] by Frank Shearar, which contains a
> snippet to load a package into an environment (however,
> EnvironmentRequest has been renamed to CurrentEnvironment since then).
> He also proposes `Smalltalk globals exportSelf` there, to let the
> global environment export its contents, which could be one way to
> solve my first problem.
>
> I am unsure how this is intended to be used; what is the reason for
> not letting the global environment export anything by default? After
> all, you have to start somewhere... To attempt an alternative, I
> created a fresh environment for the classes that I want to import
> later under other names like so:
>
>     fsenv := Environment named: #FileSystem.
>     fspackage := PackageOrganizer default packageNamed: 'FS' ifAbsent: [].
>     fspackage classes do: [:ea | fsenv bind: ea name to: ea ]
>     fsenv importSelf.
>     fsenv exportSelf.
>     testenv := Environment named: #TestEnv1.
>     testenv importSelf.
>     testenv exportSelf.
>     testenv import: fsenv removingPrefix: 'FS'.
>     testenv valueOf: #Filesystem "=> FSFilesystem"
>
> Now I can use testenv valueOf: #Filesystem to retrieve the
> FSFilesystem class, so far so good. I have not used my testenv for
> anything real yet, but it is still missing all the basics such as
> Object or Array. So I doubt it will be of much use, unless I set up
> another environment to import from that contains all the Kernel,
> Collections etc. classes. But this does not feel right, as there
> already is such an environment: Smalltalk globals...
>
> In the post from 2012 for which Chris posted the link, Colin linked an
> image (and luckily, he has not removed it from his webspace since
> then) from which I could grab the browser opening snippet. It is
> simply
>
>     Browser fullOnClass: aClassDefinedInAnotherEnvironment
>
> ...which in my case gives me a browser for the global environment
> instead, because the "renamed" classes stem from there, of course.
>
> Frank's post also has another snippet to browse an environment:
>
>     b := Browser new
>       selectEnvironment: anEnvironment;
>       yourself.
>     Browser openBrowserView: (b openEditString: nil) label: b
> defaultBrowserTitle
>
> But it seems like the browser will only show an environment's own
> contents, not the imported classes. Hence, I do not see anything in my
> environments so far. If my assumption is correct, there is no way to
> see the imported classes under their new names in the browser.
>
> When I try to define a new class using my empty browser on my
> environment, it goes back into Smalltalk globals and puts the class
> there instead. It also does that in Colin's old image, so I guess
> defining classes in environments is not supported that way.
>
> More elaborate tools are probably required to easily see what is going
> on, without exploring the Environments implementation in parallel.
>
> [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-December/175519.html
>
>
> 2016-09-23 11:59 GMT+02:00 Tobias Pape <[hidden email]>:
>> Hi Colin,
>>
>> do you have an idea here?
>>
>> Best regards
>>         -Tobias
>
> 2016-09-16 18:27 GMT+02:00 Chris Cunnington <[hidden email]>:
>>>Can I get a system browser for my environment (where saving a method
>>>compiles it with the environment bindings in place)?
>>
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-June/164605.html
>>
>> Chris
>
>>
>> On 16.09.2016, at 14:50, Jakob Reschke <[hidden email]> wrote:
>>
>>> Hello,
>>>
>>> I am having a look at Environments, but have not yet figured out, how
>>> to operate them. I would like to create a new environment with an
>>> additional binding for an existing class under another name, and load
>>> a package in that new environment.
>>>
>>> The most of a documentation I have found is http://wiki.squeak.org/squeak/6220
>>> and I have tried the following so far:
>>>
>>> testenv := Environment named: #TestEnv1.
>>> testenv import: Smalltalk globals.
>>> testenv from: Smalltalk globals import: { #String -> #MyString }.
>>> testenv importSelf.
>>> testenv exportSelf.
>>>
>>> However, testenv valueOf: #MyString or testenv valueOf: #String both
>>> return nil instead of the String class. Does it mean that the
>>> from:import: did not work? It seems to only add a policy to my
>>> environment, but no declarations or bindings.
>>>
>>> For evaluating something in context of the environment, I have found
>>> the EnvironmentLoader, but it does not seem to recognize the
>>> additional binding either:
>>>
>>> (EnvironmentLoader for: testenv) evaluate: 'MyString'. => nil
>>> (EnvironmentLoader for: testenv) evaluate: 'String'. => nil
>>>
>>> (at least the import of the original globals seems to have worked).
>>>
>>> What steps am I missing?
>>>
>>> Also it is not very convenient to make up strings of code everytime I
>>> want to do something in the other environment, is there a better way?
>>> Can I get a system browser for my environment (where saving a method
>>> compiles it with the environment bindings in place)?
>>>
>>> Best regards,
>>> Jakob
>>>
>>

2016-09-28 11:17 GMT+02:00 Jakob Reschke <[hidden email]>:

Let me repeat my question which might have gone unnoticed in my
previous wall of text:

Why doesn't the global environment (Smalltalk globals) export anything
by default? Is there a reason at all, or was it simply forgotten at
some point (because "nobody uses Environments" anyway)?

It's a bug.

Currently, the Environment SUnit tests only work because of strange name scope resolution:

we use the environment of superclass in that resolution with no good reason.
Since ProtoObject/Object are in the class hierarchy, we have undue access to Smalltalk globals.

See below some changes rotting for too long in squeak inbox.

IMO, we should evaluate 'Smalltalk exportSelf' in environment package post actions, then apply the fix below.

 

----------------------------

http://source.squeak.org/inbox/Kernel-nice.798.diff

 

----------------------------

Name: Kernel-nice.798
Author: nice
Time: 30 July 2013, 10:34:15.34 pm
UUID: e02ae597-3f6d-40b9-9468-bf01416db6de
Ancestors: Kernel-nice.797

Better fix for http://bugs.squeak.org/view.php?id=1554
A class variable defined in a superclass should take precedence over a global variable.

First look in local class variables.
Then look in local sharedPools (a local sharedPool will shadow a super class variable, that sounds fair).
Then look in superclass pools.
When superclass chain is exhausted, look in the Environment that were provided as parameter.

Note that this is mostly squeak 1.x implementation of #scopeHas:ifTrue: (or st-80), except that anEvironment parameter replaces Smalltalk.
This way we avoid duplicate lookup of previous workaround.
And we never ever look in superclass environment, that's not necessarily ours.

This currently breaks some EnvironmentTest because inheriting superclass environment is a cheap and easy way to  import all Smalltalk (unless you are not an Object or ProtoObject of course).
The longest and proper way would be to properly export some symbols from Smalltalk globals, and import them explicitely in the tested environment.

Alternatively: Are there downsides of `Smalltalk globals exportSelf`
other than that you have to do it yourself in current Squeak images?

2016-09-23 17:28 GMT+02:00 Jakob Reschke <[hidden email]>:
> In the meantime, I figured out that the Smalltalk globals environment
> does not export anything. Hence, nothing can be imported from it by
> default.
>
> Further, I found this post [1] by Frank Shearar, which contains a
> snippet to load a package into an environment (however,
> EnvironmentRequest has been renamed to CurrentEnvironment since then).
> He also proposes `Smalltalk globals exportSelf` there, to let the
> global environment export its contents, which could be one way to
> solve my first problem.
>
> I am unsure how this is intended to be used; what is the reason for
> not letting the global environment export anything by default? After
> all, you have to start somewhere... To attempt an alternative, I
> created a fresh environment for the classes that I want to import
> later under other names like so:
>
>     fsenv := Environment named: #FileSystem.
>     fspackage := PackageOrganizer default packageNamed: 'FS' ifAbsent: [].
>     fspackage classes do: [:ea | fsenv bind: ea name to: ea ]
>     fsenv importSelf.
>     fsenv exportSelf.
>     testenv := Environment named: #TestEnv1.
>     testenv importSelf.
>     testenv exportSelf.
>     testenv import: fsenv removingPrefix: 'FS'.
>     testenv valueOf: #Filesystem "=> FSFilesystem"
>
> Now I can use testenv valueOf: #Filesystem to retrieve the
> FSFilesystem class, so far so good. I have not used my testenv for
> anything real yet, but it is still missing all the basics such as
> Object or Array. So I doubt it will be of much use, unless I set up
> another environment to import from that contains all the Kernel,
> Collections etc. classes. But this does not feel right, as there
> already is such an environment: Smalltalk globals...
>
> In the post from 2012 for which Chris posted the link, Colin linked an
> image (and luckily, he has not removed it from his webspace since
> then) from which I could grab the browser opening snippet. It is
> simply
>
>     Browser fullOnClass: aClassDefinedInAnotherEnvironment
>
> ...which in my case gives me a browser for the global environment
> instead, because the "renamed" classes stem from there, of course.
>
> Frank's post also has another snippet to browse an environment:
>
>     b := Browser new
>       selectEnvironment: anEnvironment;
>       yourself.
>     Browser openBrowserView: (b openEditString: nil) label: b
> defaultBrowserTitle
>
> But it seems like the browser will only show an environment's own
> contents, not the imported classes. Hence, I do not see anything in my
> environments so far. If my assumption is correct, there is no way to
> see the imported classes under their new names in the browser.
>
> When I try to define a new class using my empty browser on my
> environment, it goes back into Smalltalk globals and puts the class
> there instead. It also does that in Colin's old image, so I guess
> defining classes in environments is not supported that way.
>
> More elaborate tools are probably required to easily see what is going
> on, without exploring the Environments implementation in parallel.
>
> [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-December/175519.html
>
>
> 2016-09-23 11:59 GMT+02:00 Tobias Pape <[hidden email]>:
>> Hi Colin,
>>
>> do you have an idea here?
>>
>> Best regards
>>         -Tobias
>
> 2016-09-16 18:27 GMT+02:00 Chris Cunnington <[hidden email]>:
>>>Can I get a system browser for my environment (where saving a method
>>>compiles it with the environment bindings in place)?
>>
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-June/164605.html
>>
>> Chris
>
>>
>> On 16.09.2016, at 14:50, Jakob Reschke <[hidden email]> wrote:
>>
>>> Hello,
>>>
>>> I am having a look at Environments, but have not yet figured out, how
>>> to operate them. I would like to create a new environment with an
>>> additional binding for an existing class under another name, and load
>>> a package in that new environment.
>>>
>>> The most of a documentation I have found is http://wiki.squeak.org/squeak/6220
>>> and I have tried the following so far:
>>>
>>> testenv := Environment named: #TestEnv1.
>>> testenv import: Smalltalk globals.
>>> testenv from: Smalltalk globals import: { #String -> #MyString }.
>>> testenv importSelf.
>>> testenv exportSelf.
>>>
>>> However, testenv valueOf: #MyString or testenv valueOf: #String both
>>> return nil instead of the String class. Does it mean that the
>>> from:import: did not work? It seems to only add a policy to my
>>> environment, but no declarations or bindings.
>>>
>>> For evaluating something in context of the environment, I have found
>>> the EnvironmentLoader, but it does not seem to recognize the
>>> additional binding either:
>>>
>>> (EnvironmentLoader for: testenv) evaluate: 'MyString'. => nil
>>> (EnvironmentLoader for: testenv) evaluate: 'String'. => nil
>>>
>>> (at least the import of the original globals seems to have worked).
>>>
>>> What steps am I missing?
>>>
>>> Also it is not very convenient to make up strings of code everytime I
>>> want to do something in the other environment, is there a better way?
>>> Can I get a system browser for my environment (where saving a method
>>> compiles it with the environment bindings in place)?
>>>
>>> Best regards,
>>> Jakob
>>>
>>