[squeak-dev] Environment changes in the Inbox

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


2017-03-01 22:33 GMT+01:00 Levente Uzonyi <leves at caesar.elte.hu>:
> I'd love to see a summary about the changes. :)
>
> Levente

Did I just read somebody asking me for a wall of text? :-)

The "summary":
- 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

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

>
> On Wed, 1 Mar 2017, Tobias Pape wrote:
>
>> Hi all,
>>
>> Should nobody object, I'll put Jakob's Environment improvements
>> into the trunk tonight.
>>
>> Best regards
>>       -Tobias
>


More information about the Squeak-dev mailing list