On 3/22/17, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi Jakob,
>
>> On Mar 22, 2017, at 5:36 AM, Jakob Reschke <jakob.reschke at student.hpi.de>
>> wrote:
>>
>> In case somebody wonders what the difference between `Environment
>> withName:` and `Environment named:` is: there is a class pool variable
>> named 'Instances' in Environment. #named: registers the new instance
>> there, #withName: does not.

Thanks, Jakob,  for the note about this important distinction. And for
the screen shot which shows how the Pharo FileSystem may be loaded.

>> It shouldn't make a difference for loading a
>> version like above, though.
>
>     is this difference useful?  What purposes do unregistered environments
> satisfy?  Isn't it just a way of loosing my code without realizing it?

Environment withName: 'theNameOfMyEnvironment'  is used in EnvironmentTest.

Maybe we should have method comments which emphasize this distinction.

And what is the proper way of 'unregistering' an environment?

For the test cases it is just

tearDown
	env destroy.
	env := nil


For the case done with
     Environment named: 'myEnvironment'

I just see

Environment >>
destroy
	
	self allClasses do: [:ea | ea removeFromSystem].
	declarations keys do: [:ea | self unbind: ea].
	policies do: [:ea | ea removeObserver: self].
	observers do: [:ea | ea stopObserving: self].


Is this all I have to do or do I need to do something more to
unregister an environment?

--Hannes

>>
>> 2017-03-22 13:29 GMT+01:00 Jakob Reschke <jakob.reschke at student.hpi.de>:
>>> Hello Hannes,
>>>
>>> If the MCVersion you have loaded belongs into the package for which you
>>> have changed the environment, the classes should be loaded in that
>>> environment, not the default one.
>>>
>>> For example, in a fresh image I create a new environment
>>> 'NewEnvironment', add the yet unloaded package FS-Core in the Monticello
>>> Browser, change the package's (actually, the working copy's) environment
>>> like you did, then load a version of this package from a repository.
>>> Unless you import the new environment back into Smalltalk globals, you
>>> will only get a browser by "manual lookup" in the environment like this:
>>> `(newEnvironment at: #FileSystem) browse`.
>>>
>>> <Capture.PNG>
>>>
>>> Because there is environment activating code in MCVersion>>load, it
>>> should also work when you drag mcz files into the image. ...yep, it
>>> does.
>>>
>>> So if it did not work for you, please check if the package names of your
>>> working copy and the version in the mcz file are equal. In my example, it
>>> would not have worked if I had added a package 'FS' (instead of
>>> 'FS-Core'), because the MCVersion's package is 'FS-Core', not 'FS'.
>>>
>>> Kind regards,
>>> Jakob
>>>
>>> ​
>>>
>>> 2017-03-22 12:52 GMT+01:00 H. Hirzel <hannes.hirzel at gmail.com>:
>>> > Hello Jakob
>>> >
>>> > A follow up on the previous mail to find out more which Environment
>>> > support now can be made use of.
>>> >
>>> >
>>> > I understand that the I can choose an environment in the left pane of
>>> > a Monticello Browser (see screen shot).
>>> >
>>> > 1. I have created the environment with
>>> >
>>> >     henv := Environment withName: 'HJHenvironment'.
>>> >     henv import: Smalltalk globals.
>>> >     henv importSelf.
>>> >     henv exportSelf.
>>> >
>>> > 2. Then I choose the environment 'HJHenvironment' in the Monticello
>>> > Browser
>>> >
>>> > 3. Then I load an MCZ package and open a SystemBrowser.
>>> >
>>> > Question:
>>> > Are these classes loaded into the new environment?
>>> >
>>> > Actually it see the classes if I open a SystemBrowser.
>>> >
>>> > However I still see them after I have changed back the environment to
>>> > 'Smalltalk' in a newly opened browser.
>>> >
>>> > You write that the tool support for environments is minimal.
>>> >
>>> > How do I use this 'minimal support' successfully?
>>> >
>>> > Regards
>>> >
>>> > Hannes
>>> >
>>> >
>>> > How do I now file in an mcz file into the new and open a SystemBrowser
>>> > on it showing the imported classes?
>>> >
>>> >
>>> > On 3/7/17, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>>> >> Or even better, some entries in the 'Help System'
>>> >>
>>> >> It should include the 'Hello World' example from October 2016.
>>> >>
>>> >> http://wiki.squeak.org/squeak/6557
>>> >>
>>> >> I volunteer to help.
>>> >>
>>> >> --Hannes
>>> >>
>>> >> On 3/6/17, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>> >>> Hi Both,
>>> >>>
>>> >>> Can this conversation be captured as something like a workspace text
>>> >>> which
>>> >>> can be opened from the Help menu in the menu bar?  I'd love to see
>>> >>> something like "Working With Environments" underneath "Working With
>>> >>> Squeak".
>>> >>>
>>> >>> On Thu, Mar 2, 2017 at 3:06 PM, Bert Freudenberg
>>> >>> <bert at freudenbergs.de>
>>> >>> wrote:
>>> >>>
>>> >>>> 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.
>>> >>>>
>>> >>>>
>>> >>>>>    env importSelf;
>>> >>>>
>>> >>>>
>>> >>>> Makes future declarations in this environment visible to itself.
>>> >>>>
>>> >>>>
>>> >>>>> exportSelf.
>>> >>>>
>>> >>>>
>>> >>>> Makes future changes in this environment visible to other
>>> >>>> environments
>>> >>>> that imported it.
>>> >>>>
>>> >>>>
>>> >>>>> 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?
>>> >>>>
>>> >>>> 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).
>>> >>>>
>>> >>>> The general metaphor seems to be that an environment just replaces
>>> >>>> the
>>> >>>> global Smalltalk dictionary with its own, but the code in general
>>> >>>> doesn't
>>> >>>> even have to be aware of the existence of other environments. This
>>> >>>> is in
>>> >>>> contrast to how other systems handle modules and namespaces. Would
>>> >>>> you
>>> >>>> think this is a fair characterization?
>>> >>>>
>>> >>>> - Bert -
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> _,,,^..^,,,_
>>> >>> best, Eliot
>>> >>>
>>> >>
>>>
>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Environment_named_registers_instance_Screenshot_2017-03-22.png
Type: image/png
Size: 124523 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170322/1c23fc89/attachment-0001.png>