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 <Das.Linux at gmx.de>:
> Hi Colin,
>
> do you have an idea here?
>
> Best regards
>         -Tobias

2016-09-16 18:27 GMT+02:00 Chris Cunnington <brasspen at gmail.com>:
>>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 <jakob.reschke at student.hpi.de> 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
>>
>