Thanks.  It feels magical when I talked about something and it happens!

I think I loaded all of those packages successfully.  Trying the
Monticello integration part needs some figuring out (as Bert asked)
but the work seems to be quite interesting!

On Wed, Mar 1, 2017 at 5:39 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
>
> On Wed, Mar 1, 2017 at 3:42 PM, Jakob Reschke <jakob.reschke at student.hpi.de>
> wrote:
>>
>> 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
>
>
> For easy testing, execute this in a trunk image:
>
> (MCConfiguration fromArray: #(
> repository ('http://source.squeak.org/inbox')
> dependency ('Compiler' 'Compiler-jr.329'
> '6053da84-5a5b-b043-8dcc-019bc75762df')
> dependency ('Kernel' 'Kernel-jr.1061'
> 'acd952fb-8e90-e940-8d2e-6c1a9e3a7d3f')
> dependency ('System' 'System-jr.928' '3b79a197-c860-eb40-8f04-645f64bc7988')
> dependency ('ToolBuilder-Kernel' 'ToolBuilder-Kernel-jr.109'
> 'edda3c34-f8df-fc4f-b6a5-6404053750f1')
> dependency ('Tools' 'Tools-jr.745' 'c3e3bfae-ac2c-0d4e-a606-c41b7d388d67')
> dependency ('ToolsTests' 'ToolsTests-jr.79'
> '633800f6-1e23-1744-8e1a-01ecd6e88cd2')
> dependency ('Environments' 'Environments-jr.71'
> 'a50d4dbb-f587-6d46-bd22-bfcba43c4187')
> dependency ('Traits' 'Traits-jr.309' '32a4e214-747f-cc42-8b8d-a95182963d05')
> dependency ('Monticello' 'Monticello-jr.663'
> 'a39bff3c-bb90-704a-bbdc-1c9ce084747b')
> dependency ('Tests' 'Tests-jr.366' 'a91286d9-df10-e24e-b128-dc03557db77a')
> dependency ('PackageInfo-Base' 'PackageInfo-Base-jr.70'
> '4eaf925f-ff65-7647-8ef5-f9d0c9f7b58c')
> )) upgrade
>
>
>  - Bert -
>
>>
>> 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
>> >
>>
>
>
>
>



-- 
-- Yoshiki