2017-03-01 22:33 GMT+01:00 Levente Uzonyi leves@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
On Wed, Mar 1, 2017 at 3:42 PM, Jakob Reschke jakob.reschke@student.hpi.de wrote:
2017-03-01 22:33 GMT+01:00 Levente Uzonyi leves@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
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@freudenbergs.de wrote:
On Wed, Mar 1, 2017 at 3:42 PM, Jakob Reschke jakob.reschke@student.hpi.de wrote:
2017-03-01 22:33 GMT+01:00 Levente Uzonyi leves@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
On Wed, Mar 1, 2017 at 3:42 PM, Jakob Reschke jakob.reschke@student.hpi.de wrote:
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?
A remaining issue is that FSPath was renamed Path, which conflicts with
ST80's Path class.
Our environments support renaming, doesn't that help?
- Bert -
On Thu, Mar 02, 2017 at 12:42:43AM +0100, Jakob Reschke wrote:
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.
Bravo! This sounds like exactly the kind of problem that Environments was designed to solve. I have been hoping to see such a "real world" use case for a long time, so I am happy to see this work being done.
Dave
squeak-dev@lists.squeakfoundation.org