Smalltalk › Squeak › Squeak - Dev

Environment changes in the Inbox

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

38 messages Options

Tobias Pape

Environment changes in the Inbox

Hi all,

Should nobody object, I'll put Jakob's Environment improvements
into the trunk tonight.

Best regards
-Tobias

Chris Muller-3

Re: Environment changes in the Inbox

Hi Tobias, may I have more time to take a look? It's only been a few
hours, given that we're still looking for Environments first use-case,
there's no need to rush the code into the trunk.

I'd like to know what changes have been made to the browsers and
tools. I'd like to make sure that Environments' maintains its low
profile and minimal cost to non-developer users.

I see a lot of recent Inbox contributions -- one thing that would help
are instructions or a script on what I need to load and the order.

Best,
Chris

On Wed, Mar 1, 2017 at 9:40 AM, Tobias Pape <[hidden email]> wrote:
> Hi all,
>
> Should nobody object, I'll put Jakob's Environment improvements
> into the trunk tonight.
>
> Best regards
> -Tobias
>

Levente Uzonyi

Re: Environment changes in the Inbox

In reply to this post by Tobias Pape

I'd love to see a summary about the changes. :)

Levente

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

Jakob Reschke-2

Re: Environment changes in the Inbox

In reply to this post by Tobias Pape

2017-03-01 22:33 GMT+01:00 Levente Uzonyi <[hidden email]>:
> 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
>

Bert Freudenberg

Re: Environment changes in the Inbox

On Wed, Mar 1, 2017 at 3:42 PM, Jakob Reschke <[hidden email]> wrote:

2017-03-01 22:33 GMT+01:00 Levente Uzonyi <[hidden email]>:
> 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
>

Bert Freudenberg

Re: Environment changes in the Inbox

In reply to this post by Jakob Reschke-2

On Wed, Mar 1, 2017 at 3:42 PM, Jakob Reschke <[hidden email]> 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 -

Yoshiki Ohshima-3

Re: Environment changes in the Inbox

In reply to this post by Bert Freudenberg

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 <[hidden email]> wrote:

>
>
> On Wed, Mar 1, 2017 at 3:42 PM, Jakob Reschke <[hidden email]>
> wrote:
>>
>> 2017-03-01 22:33 GMT+01:00 Levente Uzonyi <[hidden email]>:
>> > 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

David T. Lewis

Re: Environment changes in the Inbox

In reply to this post by Jakob Reschke-2

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

Jakob Reschke-2

Re: Environment changes in the Inbox

In reply to this post by Jakob Reschke-2

2017-03-02 2:44 GMT+01:00 Bert Freudenberg <[hidden email]>:

> On Wed, Mar 1, 2017 at 3:42 PM, Jakob Reschke <[hidden email]>
> 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?

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:

env := Environment named: #NewProjectWithPharoBindings.
env import: Smalltalk globals.
env from: Smalltalk globals import: { #FSFilesystem -> #FileSystem.
#FSPath -> #Path. "..." }
env importSelf; exportSelf.

2. open a Workspace that "lives" in the new environment:

env beCurrentDuring: [Workspace open]

...and change its title to remember its purpose.

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.
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.
>
>
> 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". 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.

There is another pitfall with renamed imports and Monticello: The
class definition includes the superclass name -- its proper name, not
the renamed binding (for all we know, the class could have multiple
bindings in this environment...) All subclasses of FileSystem always
show up in the diff because as far as Monticello is concerned, the
superclass was changed from FileSystem to FSFilesystem, although these
are really the same thing. One could add special checks for that case
and manipulate the MCClassDefinition to not reflect the "superclass
name change". Otherwise the problem would resurface when the class
definition really changes and must be committed. Too bad everything is
so text based for us humans because we cannot read pointers or
remember UUIDs for classes. ;-)

Jakob Reschke-2

Re: Environment changes in the Inbox

You may add to the list:

SUnitGUI-jr.65 (environment in TestRunner)
SUnit-jr.106 (support ClassTestCase)
Monticello-jr.664 (support recompilePackage)

Ironically, the TestRunner change was the first that I made w.r.t.
environments and tools...

2017-03-02 12:45 GMT+01:00 Jakob Reschke <[hidden email]>:

> 2017-03-02 2:44 GMT+01:00 Bert Freudenberg <[hidden email]>:
>> On Wed, Mar 1, 2017 at 3:42 PM, Jakob Reschke <[hidden email]>
>> 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?
>
> 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:
>
> env := Environment named: #NewProjectWithPharoBindings.
> env import: Smalltalk globals.
> env from: Smalltalk globals import: { #FSFilesystem -> #FileSystem.
> #FSPath -> #Path. "..." }
> env importSelf; exportSelf.
>
> 2. open a Workspace that "lives" in the new environment:
>
> env beCurrentDuring: [Workspace open]
>
> ...and change its title to remember its purpose.
>
> 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.
> 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.
>>
>>
>> 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". 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.
>
> There is another pitfall with renamed imports and Monticello: The
> class definition includes the superclass name -- its proper name, not
> the renamed binding (for all we know, the class could have multiple
> bindings in this environment...) All subclasses of FileSystem always
> show up in the diff because as far as Monticello is concerned, the
> superclass was changed from FileSystem to FSFilesystem, although these
> are really the same thing. One could add special checks for that case
> and manipulate the MCClassDefinition to not reflect the "superclass
> name change". Otherwise the problem would resurface when the class
> definition really changes and must be committed. Too bad everything is
> so text based for us humans because we cannot read pointers or
> remember UUIDs for classes. ;-)

Bert Freudenberg

Re: Environment changes in the Inbox

In reply to this post by Jakob Reschke-2

Let me see if I understand ...

On Thu, Mar 2, 2017 at 3:45 AM, Jakob Reschke <[hidden email]> 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 -

Chris Muller-3

Re: Environment changes in the Inbox

In reply to this post by Jakob Reschke-2

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 it must
preserve the illusion of Smalltalk-80's original, simple, single
Smalltalk environment.

Best,
Chris

Jakob Reschke-2

Re: Environment changes in the Inbox

In reply to this post by Jakob Reschke-2

2017-03-03 0:06 GMT+01:00 Bert Freudenberg <[hidden email]>:

> Let me see if I understand ...
>
> On Thu, Mar 2, 2017 at 3:45 AM, Jakob Reschke <[hidden email]>
> 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.
>
>
> 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?

Bingo! Stupid me. There are some other relevant changes in TextEditor
as well. Add Morphic-jr.1325 to the list.

>
> 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

Re: Environment changes in the Inbox

In reply to this post by Chris Muller-3

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.

So let's get these changes into trunk. They are invisible to those of us not
working directly with Environments, and they appear to be very important for
anyone who might want to make practical use of Environments.

Dave

Bert Freudenberg

Re: Environment changes in the Inbox

In reply to this post by Jakob Reschke-2

On Thu, Mar 2, 2017 at 6:34 PM, Jakob Reschke <[hidden email]> wrote:

Bingo! Stupid me. There are some other relevant changes in TextEditor
as well. Add Morphic-jr.1325 to the list.

Okay. Here, for people to try: