Squeak
  links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Environments update March 2017
Last updated at 11:15 am UTC on 16 May 2017
See http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/thread.html

NOTE: THIS PAGE STILL NEEDS CLEANING UP, PLEASE HELP IF YOU ARE IN THE POSITION TO DO SO.

The thread 'Environment changes in the Inbox'
http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193388.html
contains a summary of changes for the Environment updates added to trunk in March 2017.

Summary of changes in March 2017

Jakob Reschke jakob.reschke at student.hpi.de answered Wed Mar 1 23:42:43 UTC 2017

If you only work within one environment, nothing should change visibly
(except for two new menu items in Monticello).

CurrentEnvironment will

be signalled more often...



Ordered list of relevant versions (so far):
Compiler-jr.329
Kernel-jr.1061
System-jr.927
System-jr.928
ToolBuilder-Kernel-jr.109
Tools-jr.745
ToolsTests-jr.79
Environments-jr.71
Traits-jr.309
Monticello-jr.663
Tests-jr.366
PackageInfo-Base-jr.70

I hope I will not stumble upon another affected package that I have
still missed to save to the inbox. As to be expected, Environments are
very cross cutting.

Certainly not all the tools' features are covered by my changes, so
some features might still not behave correctly in another environment.
But it is a start. I can work with classes in another environment here
without being interrupted all the time.

With my changes, when you ask for senders or implementors in an
environment, you currently only get the senders or implementors in
that specific environment. Navigating imports and exports would be
difficult/ugly because the connections are not explicit, but only
present in an observer pattern for changing bindings.

What I have done further, but not committed yet, are changes to
ChangeSet and ChangeSorter, replacing the class names with
ClassReferences, so you can use browse/senders/implementors/... from
the change sorters and actually look at the changes in another
environment there. The patching is tricky because you do not want to
get in a state where you cannot save methods without debuggers popping
up because ChangeSet methods were loaded in the wrong order. It works
in my image and I have already split my relevant change sets, but did
not have the time to convert that to Monticello versions.

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. A
remaining issue is that FSPath was renamed Path, which conflicts with
ST80's Path class.

Kind regards,
Jakob




How to load the environments updates in the Inbox



How to load the environments changes from the inbox

This is not necessary anymore as the changes have been commited to trunk.

Environments-jr.68.mcz and around 20 more updates have been loaded by Mar 5, 2017 at 6:03 PM


Use case for environments



Bert Freudenberg
Fri, Mar 3, 2017 at 12:06 AM
Reply-To: The general-purpose Squeak developers list
To: The general-purpose Squeak developers list
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 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
Fri, Mar 3, 2017 at 3:15 AM
Reply-To: ma.chris.m@gmail.com, The general-purpose Squeak developers list
To: The general-purpose Squeak developers list

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
Fri, Mar 3, 2017 at 3:34 AM
Reply-To: The general-purpose Squeak developers list
To: The general-purpose Squeak developers list
Reply | Reply to all | Forward | Print | Delete | Show original
2017-03-03 0:06 GMT+01:00 Bert Freudenberg :
> Let me see if I understand ...
>
> On Thu, Mar 2, 2017 at 3:45 AM, Jakob Reschke
> 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
Fri, Mar 3, 2017 at 4:22 AM
Reply-To: The general-purpose Squeak developers list
To: ma.chris.m@gmail.com, The general-purpose Squeak developers list

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