<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 1, 2017 at 3:42 PM, Jakob Reschke <span dir="ltr"><<a href="mailto:jakob.reschke@student.hpi.de" target="_blank">jakob.reschke@student.hpi.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">2017-03-01 22:33 GMT+01:00 Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu">leves@caesar.elte.hu</a>>:<br>
> I'd love to see a summary about the changes. :)<br>
><br>
> Levente<br>
<br>
</span>Did I just read somebody asking me for a wall of text? :-)<br>
<br>
The "summary":<br>
- ClassReference gets an environment inst var like MethodReferences already has<br>
- text-only references to classes and methods must be replaced with<br>
proper MethodReferences and ClassReferences that associate an<br>
environment with the name<br>
- an exception is Browser which already had an own environment inst<br>
var, so this must be used instead, where appropriate, but care must be<br>
taken for class hierarchies spanning multiple environments<br>
- replace occurrences of "Smalltalk at:" by "someEnvironment valueOf:"<br>
or "someEnvironment at:" depending on the use case (lookup vs.<br>
"residents accessing")<br>
- add additional variants of compiler and constructor methods, with an<br>
environment argument<br>
- use the added parameter in the tools, for example when saving a<br>
class definition<br>
- make sure methods and source code are compiled in the "correct" environment<br>
- do not use singletons like "SystemOrganization" or "PackageOrganizer<br>
default" when there is an environment specific equivalent (typically<br>
in EnvironmentInfo)<br>
- make sure every object used as a model for tools can at least<br>
understand the query for the displayed/worked-on environment and<br>
answer an Environment object<br>
- give Workspace an environment -- currently you can only fill that<br>
programmatically ("myWorkspace environment: xyz", or "myEnvironment<br>
beCurrentDuring: [Workspace open]")<br>
- give MCWorkingCopy an environment, as the target for loading and the<br>
source for snapshots<br>
- add a menu item to change a working copy's environment<br>
- PackageInfo and MCPackage remain somewhat environment agnostic, so<br>
they can be used to investigate the same (or equally named) package in<br>
different environments -- they must use the current environment<br>
instead of "Smalltalk", of course<br>
- wrap a working copy's MCPackage such that the working copy's<br>
environment will be made the current environment during snapshots<br>
- to that end, go to the package via the working copy when doing<br>
something with an MCVersion, for example<br>
- because MCDefinitions know nothing about environments, MCCodeTools<br>
must know the "context" environment of the displayed definitions and<br>
use that in operations<br>
- add a menu item to the MCSnapshotBrowser class list, to load a class<br>
into a different environment<br>
<br>
If you only work within one environment, nothing should change visibly<br>
(except for two new menu items in Monticello). CurrentEnvironment will<br>
be signalled more often...<br>
<br>
Ordered list of relevant versions (so far):<br>
Compiler-jr.329<br>
Kernel-jr.1061<br>
System-jr.927<br>
System-jr.928<br>
ToolBuilder-Kernel-jr.109<br>
Tools-jr.745<br>
ToolsTests-jr.79<br>
Environments-jr.71<br>
Traits-jr.309<br>
Monticello-jr.663<br>
Tests-jr.366<br>
PackageInfo-Base-jr.70<br></blockquote><div><br></div><div>For easy testing, execute this in a trunk image:</div><div><br></div><div><div>(MCConfiguration fromArray: #(</div><div>repository ('<a href="http://source.squeak.org/inbox">http://source.squeak.org/inbox</a>')</div><div>dependency ('Compiler' 'Compiler-jr.329' '6053da84-5a5b-b043-8dcc-019bc75762df')</div><div>dependency ('Kernel' 'Kernel-jr.1061' 'acd952fb-8e90-e940-8d2e-6c1a9e3a7d3f')</div><div>dependency ('System' 'System-jr.928' '3b79a197-c860-eb40-8f04-645f64bc7988')</div><div>dependency ('ToolBuilder-Kernel' 'ToolBuilder-Kernel-jr.109' 'edda3c34-f8df-fc4f-b6a5-6404053750f1')</div><div>dependency ('Tools' 'Tools-jr.745' 'c3e3bfae-ac2c-0d4e-a606-c41b7d388d67')</div><div>dependency ('ToolsTests' 'ToolsTests-jr.79' '633800f6-1e23-1744-8e1a-01ecd6e88cd2')</div><div>dependency ('Environments' 'Environments-jr.71' 'a50d4dbb-f587-6d46-bd22-bfcba43c4187')</div><div>dependency ('Traits' 'Traits-jr.309' '32a4e214-747f-cc42-8b8d-a95182963d05')</div><div>dependency ('Monticello' 'Monticello-jr.663' 'a39bff3c-bb90-704a-bbdc-1c9ce084747b')</div><div>dependency ('Tests' 'Tests-jr.366' 'a91286d9-df10-e24e-b128-dc03557db77a')</div><div>dependency ('PackageInfo-Base' 'PackageInfo-Base-jr.70' '4eaf925f-ff65-7647-8ef5-f9d0c9f7b58c')</div><div>)) upgrade</div></div><div><br></div><div><br></div><div> - Bert -</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I hope I will not stumble upon another affected package that I have<br>
still missed to save to the inbox. As to be expected, Environments are<br>
very cross cutting.<br>
<br>
Certainly not all the tools' features are covered by my changes, so<br>
some features might still not behave correctly in another environment.<br>
But it is a start. I can work with classes in another environment here<br>
without being interrupted all the time.<br>
<br>
With my changes, when you ask for senders or implementors in an<br>
environment, you currently only get the senders or implementors in<br>
that specific environment. Navigating imports and exports would be<br>
difficult/ugly because the connections are not explicit, but only<br>
present in an observer pattern for changing bindings.<br>
<br>
What I have done further, but not committed yet, are changes to<br>
ChangeSet and ChangeSorter, replacing the class names with<br>
ClassReferences, so you can use browse/senders/implementors/..<wbr>. from<br>
the change sorters and actually look at the changes in another<br>
environment there. The patching is tricky because you do not want to<br>
get in a state where you cannot save methods without debuggers popping<br>
up because ChangeSet methods were loaded in the wrong order. It works<br>
in my image and I have already split my relevant change sets, but did<br>
not have the time to convert that to Monticello versions.<br>
<br>
My Environments use case, for which I have gone through all of this,<br>
is that I need to use and work on a Pharo package that uses the<br>
FileSystem library. The FileSystem classes have different names in<br>
Pharo, compared to the FS package available on SqueakSource. A<br>
remaining issue is that FSPath was renamed Path, which conflicts with<br>
ST80's Path class.<br>
<br>
Kind regards,<br>
Jakob<br>
<span class="gmail-im gmail-HOEnZb"><br>
><br>
> On Wed, 1 Mar 2017, Tobias Pape wrote:<br>
><br>
</span><div class="gmail-HOEnZb"><div class="gmail-h5">>> Hi all,<br>
>><br>
>> Should nobody object, I'll put Jakob's Environment improvements<br>
>> into the trunk tonight.<br>
>><br>
>> Best regards<br>
>>       -Tobias<br>
><br>
<br>
</div></div></blockquote></div><br></div></div>