links to this page:    Smalltalk Environment Swiki Page List Environments 2012 Smalltalk global variable Environments update (Sept 2016, F) Loading changes from the inbox (example)

Summary of changes in March 2017

• ClassReference gets an environment inst var like MethodReferences already has
• text-only references to classes and methods must be replaced with proper MethodReferences and ClassReferences that associate an environment with the name
• an exception is Browser which already had an own environment inst var, so this must be used instead, where appropriate, but care must be taken for class hierarchies spanning multiple environments
• replace occurrences of "Smalltalk at:" by "someEnvironment valueOf:" or "someEnvironment at:" depending on the use case (lookup vs."residents accessing")
• add additional variants of compiler and constructor methods, with an environment argument
• use the added parameter in the tools, for example when saving a class definition
• make sure methods and source code are compiled in the "correct" environment
• do not use singletons like "SystemOrganization" or "PackageOrganizer default" when there is an environment specific equivalent (typically in EnvironmentInfo)
• make sure every object used as a model for tools can at least understand the query for the displayed/worked-on environment and answer an Environment object
• give Workspace an environment – currently you can only fill that programmatically ("myWorkspace environment: xyz", or "myEnvironment beCurrentDuring: [Workspace open]")
• give MCWorkingCopy an environment, as the target for loading and the source for snapshots
• add a menu item to change a working copy's environment
• PackageInfo and MCPackage remain somewhat environment agnostic, so they can be used to investigate the same (or equally named) package in different environments – they must use the current environment instead of "Smalltalk", of course
• wrap a working copy's MCPackage such that the working copy's environment will be made the current environment during snapshots
• to that end, go to the package via the working copy when doing something with an MCVersion, for example
• because MCDefinitions know nothing about environments, MCCodeTools must know the "context" environment of the displayed definitions and use that in operations
• add a menu item to the MCSnapshotBrowser class list, to load a class into a different environment

How to load the environments updates in the Inbox

Use case for environments

Bert Freudenberg
<bert@freudenbergs.de>	Fri, Mar 3, 2017 at 12:06 AM
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Reply | Reply to all | Forward | Print | Delete | Show original
Let me see if I understand ...

On Thu, Mar 2, 2017 at 3:45 AM, Jakob Reschke <jakob.reschke@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 -




Add star 
Chris Muller
<asqueaker@gmail.com>	Fri, Mar 3, 2017 at 3:15 AM
Reply-To: ma.chris.m@gmail.com, The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>

I know we've already discussed it a lot in the past, but since none of
the reasoning for using Environments to solve this issue has changed,
the simpler approaches still deserve advocacy.  (Below..)

>>> My Environments use case, for which I have gone through all of this,
>>> is that I need to use and work on a Pharo package that uses the
>>> FileSystem library. The FileSystem classes have different names in
>>> Pharo, compared to the FS package available on SqueakSource.
>>
>>
>> Can you walk us through this use case? What tools do you use in which order?
>
> Well, if I were to start from scratch with my changes already in the
> image, I would do the following:
>
> 1. prepare the environment in a workspace, because there are no tools for it:
   ... snip...
>
> 2. open a Workspace that "lives" in the new environment:
>
   ...snip...
>
> 3. in the Monticello Browser, add a working copy for the package I
> want to work on (+ Package)
> 4. right-click on it > change environment... choose my new environment
> named NewProjectWithPharoBindings.
>
> 5. add the appropriate repository, open it, load the package -or- use
> Metacello to do it (you have to know the relevant package names and
> prepare them with steps 3 and 4) -but- I have not checked if Metacello
> goes through the MCWorkingCopy, so this might not work yet. In that
> case, wrap "env beCurrentDuring: [...]" around the Metacello load.
> This might be the easier way after all...
>
> 6. in the workspace created in step 2, send #browse to a class loaded
> in step 5, to open a browser in the new environment
>
> 7. if appropriate and desired, import some or all of the new classes
> back into Smalltalk globals. This also simplifies opening browsers,
> because you can do it via the search box.
>
>    Smalltalk globals from: env import: { ... }.
>
> Then I do whatever I intend to do with that package. Probably port the
> code when selectors have changed as well, not only the class names.

That's a LOT of stuff!  Environments provides a "trade-off" for the
developer to engage in one sort of work instead of another sort of
work.  A sort of work unfamiliar to Smalltalkers..

> This is (ideally) no different from developing without environments.
>
> I did not commit the TestRunner yet... like for Workspace, I added an
> environment instvar there. Will do that later today.
>
>>
>>> A remaining issue is that FSPath was renamed Path, which conflicts with
>>> ST80's Path class.

Given the broad meaning for the word "path", that was a very
ill-advised rename.  FilesystemPath is a much more correct and
appropriate for Smalltalk.

Equally, our own "Path" is so ambiguous, it's just wrong.  Sitting up
there as an abstract superclass -- we should rename it.

>> Our environments support renaming, doesn't that help?
>>
>
> Yes, it does. What I meant is that because of this name conflict, I
> require another environment at all. Unless I consider it desirable to
> rename one of the Path classes and possibly change all the references
> from Path to FSPath in the loaded package. Or rename Path to St80Path
> and hope that nobody will ever add another method uses it under the
> name "Path".

If someone added a new method, your app still wouldn't be calling it
unless you change it to do so..

> It is not possible to load a version of FileSystem where
> FSPath is called Path into the same environment as ST80 without
> overwriting ST80's Path.

Unless you renamed it.  I think of Berts question in the context of
system configuration.  Applications have code which configures the
image for themself.  Codifying the rename there (pre-load) means you
can still always use the latest-and-greatest versions without having
to do any more work than setting up Environments.

Name collisions are such a very-rare problem, and we're make the
system more complicated in *so* many places, it really does feel like
the tail wagging the dog.
_____
Environments is for developers (nerds). Although my preference is to
reduce and simplify the system (by removing it altogether), I will
respect developers who want to push forward as long as it is not
exclusionary to power users and Smalltalk newbies, meaning 

Best,
  Chris

Reply | Reply to all | Forward | Print | Delete | Show original

Add star 
Jakob Reschke
<jakob.reschke@student.hpi.de>	Fri, Mar 3, 2017 at 3:34 AM
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Reply | Reply to all | Forward | Print | Delete | Show original
2017-03-03 0:06 GMT+01:00 Bert Freudenberg <bert@freudenbergs.de>:
> Let me see if I understand ...
>
> On Thu, Mar 2, 2017 at 3:45 AM, Jakob Reschke <jakob.reschke@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.
>
>

>
> 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.


David T. Lewis
<lewis@mail.msen.com>	Fri, Mar 3, 2017 at 4:22 AM
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
To: ma.chris.m@gmail.com, The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>

On Thu, Mar 02, 2017 at 08:15:26PM -0600, Chris Muller wrote:
> >
> >>
> >>> A remaining issue is that FSPath was renamed Path, which conflicts with
> >>> ST80's Path class.
>
> Given the broad meaning for the word "path", that was a very
> ill-advised rename.  FilesystemPath is a much more correct and
> appropriate for Smalltalk.

Renaming FSPath to Path was just plain stupid. But with respect to Environments,
that may be exactly the use case we are interested in. Somebody did something
stupid, and we have no way of changing it. Now we are faced with the problem of
using some package of general interest that happens to depend on the stupid thing
that we cannot fix. What to do?

There are plenty of kludgy hacks that might be applied to work around a problem
like this. I have done quite a few of them in my OSProcess package in an ongoing
effort to keep pace with various random refactorings and ill-advised cleaning
initiatives. That experience leaves me wondering if there might not be a better
way of dealing with such issues.

I do not really know if Environments will provide a practical solution, or if
instead it will just end up adding complexity without really carrying its weight.
Time will tell. But my gut feel tells me that Environments is both simple and
general in design, and that makes it worth the effort to see if we can find a
way put it to good use.

...
Dave