Environment changes in the Inbox
Locked
12
12
Re: Environment changes in the Inbox
 
|
Re: Environment changes in the Inbox
|
|
Re: Environment changes in the Inbox
|
|
Re: Environment changes in the Inbox
|
|
Re: Environment changes in the Inbox
|
|
Re: Environment changes in the Inbox
|
|
Re: Environment changes in the Inbox
|
|
Re: Environment changes in the Inbox
|
|
Re: Environment changes in the Inbox
|
|
On 3/22/17, H. Hirzel <[hidden email]> wrote:
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> >>> wrote: >>> >>>> Let me see if I understand ... >>>> >>>> On Thu, Mar 2, 2017 at 3:45 AM, Jakob Reschke < >>>> [hidden email]> 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 >>> >> > |
Choose_Environment_in_Monticello_Browser_Screenshot_2017-03-22.png (35K)
Fwd: Environment changes in the Inbox
|
|
In reply to this post by Hannes Hirzel
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`.  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 <[hidden email]>: > 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 <[hidden email]> 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/ >> >> I volunteer to help. >> >> --Hannes >> >> On 3/6/17, Eliot Miranda <[hidden email]> 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 <[hidden email]> >>> wrote: >>> >>>> Let me see if I understand ... >>>> >>>> On Thu, Mar 2, 2017 at 3:45 AM, Jakob Reschke < >>>> [hidden email]> 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 >>> >> |
Re: Environment changes in the Inbox
|
|
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. It shouldn't make a difference for loading a version like above, though. 2017-03-22 13:29 GMT+01:00 Jakob Reschke <[hidden email]>:
|
Re: Environment changes in the Inbox
|
|
Re: Environment changes in the Inbox
|
|
Re: Environment changes in the Inbox
|
|
In reply to this post by Eliot Miranda-2
On 3/22/17, Eliot Miranda <[hidden email]> wrote:
> Hi Jakob, > >> On Mar 22, 2017, at 5:36 AM, Jakob Reschke <[hidden email]> >> 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 <[hidden email]>: >>> 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 <[hidden email]>: >>> > 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 <[hidden email]> 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 <[hidden email]> 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 >>> >>> <[hidden email]> >>> >>> wrote: >>> >>> >>> >>>> Let me see if I understand ... >>> >>>> >>> >>>> On Thu, Mar 2, 2017 at 3:45 AM, Jakob Reschke < >>> >>>> [hidden email]> 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 >>> >>> >>> >> >>> >> >> > |
Re: Environment changes in the Inbox
|
|
Re: Environment changes in the Inbox
|
|
Re: Environment changes in the Inbox
|
|
Re: Environment changes in the Inbox
|
|
| Free forum by Nabble | Edit this page |