[squeak-dev] Environment changes in the Inbox

Jakob Reschke jakob.reschke at student.hpi.de
Fri Mar 3 02:34:30 UTC 2017


2017-03-03 0:06 GMT+01:00 Bert Freudenberg <bert at freudenbergs.de>:
> Let me see if I understand ...
>
> On Thu, Mar 2, 2017 at 3:45 AM, Jakob Reschke <jakob.reschke at student.hpi.de>
> wrote:
>>
>>
>> 1. prepare the environment in a workspace, because there are no tools for
>> it:
>>
>>    env := Environment named: #NewProjectWithPharoBindings.
>
>
> This creates a new empty environment.
>
>>
>>    env import: Smalltalk globals.
>
>
> This makes all current classes available inside the new environment.
>
>>
>>    env from: Smalltalk globals import: { #FSFilesystem -> #FileSystem.
>> #FSPath -> #Path. "..." }
>
>
> This makes the FS classes (which you loaded previously) available under the
> non-prefixed name, too.

Correct.

>
>>
>>    env importSelf;
>
>
> Makes future declarations in this environment visible to itself.
>

Yes, and also the already existing ones (if any), but for some reason
the implementation of importSelf explicitly does not overwrite
existing (imported) bindings with own declarations. I wonder why...
But it does not matter all that much because of what I described in
the older thread titled "Environments: imported bindings overwriting
each other".

>>
>> exportSelf.
>
>
> Makes future changes in this environment visible to other environments that
> imported it.
>

Correct.

>>
>> 2. open a Workspace that "lives" in the new environment:
>>
>>   env beCurrentDuring: [Workspace open]
>>
>>   ...and change its title to remember its purpose.
>
>
> Yoshiki and I tried that but evaluating code still appears to use the
> Smalltalk environment. We had to change the evaluateSelectionAndDo: method
> in the Morphic package to use the model's environment. Is that a change you
> missed?

Bingo! Stupid me. There are some other relevant changes in TextEditor
as well. Add Morphic-jr.1325 to the list.

>
> In general it appears to be working well, although the tool support is
> minimal for now. It would be useful if environment-aware tools indicated the
> current environment (if it is not the default).

Maybe. I did it for the TestRunner, but playing with only two
different environments and without duplicate class names (except for
Path) I could always tell the environment from the visible classes.
Question is: How to indicate? Changing the title might make some
titles long. IIRC, Marcel once told me that Bastian Steinert indicated
environments with differently colored window borders in his thesis
work. But Marcel found that confusing, and I also think that would be
difficult to comprehend.


More information about the Squeak-dev mailing list