Environment changes in the Inbox

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Environment changes in the Inbox

Tobias Pape
Hi all,

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

Best regards
        -Tobias

Reply | Threaded
Open this post in threaded view
|

Re: Environment changes in the Inbox

Chris Muller-3
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
>

Reply | Threaded
Open this post in threaded view
|

Re: Environment changes in the Inbox

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

Reply | Threaded
Open this post in threaded view
|

Re: Environment changes in the Inbox

Jakob Reschke-2
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
>

Reply | Threaded
Open this post in threaded view
|

Re: Environment changes in the Inbox

Bert Freudenberg


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: #(
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
>




Reply | Threaded
Open this post in threaded view
|

Re: Environment changes in the Inbox

Bert Freudenberg
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 -Ā 



Reply | Threaded
Open this post in threaded view
|

Re: Environment changes in the Inbox

Yoshiki Ohshima-3
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

Reply | Threaded
Open this post in threaded view
|

Re: Environment changes in the Inbox

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: Environment changes in the Inbox

Jakob Reschke-2
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. ;-)

Reply | Threaded
Open this post in threaded view
|

Re: Environment changes in the Inbox

Jakob Reschke-2
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. ;-)

Reply | Threaded
Open this post in threaded view
|

Re: Environment changes in the Inbox

Bert Freudenberg
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 -Ā 


Reply | Threaded
Open this post in threaded view
|

Re: Environment changes in the Inbox

Chris Muller-3
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

Reply | Threaded
Open this post in threaded view
|

Re: Environment changes in the Inbox

Jakob Reschke-2
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.

Reply | Threaded
Open this post in threaded view
|

Re: Environment changes in the Inbox

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: Environment changes in the Inbox

Bert Freudenberg
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:

(MCConfiguration fromArray: #(
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.664' '5f7f61e8-c5f7-7749-8d7f-c39b5b4584fb')
dependency ('Tests' 'Tests-jr.366' 'a91286d9-df10-e24e-b128-dc03557db77a')
dependency ('PackageInfo-Base' 'PackageInfo-Base-jr.70' '4eaf925f-ff65-7647-8ef5-f9d0c9f7b58c')
dependency ('SUnit' 'SUnit-jr.106' '675e77ab-782e-2c47-a754-a9d1ca6f9c03')
dependency ('SUnitGUI' 'SUnitGUI-jr.65' '2fc0a490-bd92-cc43-96c7-ede4b233243d')
dependency ('Morphic' 'Morphic-jr.1325' 'ec6312f8-a496-fe46-8c4e-e1ca155b499d')
)) upgradeĀ 

Is it fair to say that we can pretty much ignore environments in daily use? That we only create one if we need it? Or do you think they would be useful for regular development?

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: Environment changes in the Inbox

David T. Lewis
On Thu, Mar 02, 2017 at 07:23:21PM -0800, Bert Freudenberg wrote:

> 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:
>
> (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.664'
> '5f7f61e8-c5f7-7749-8d7f-c39b5b4584fb')
> dependency ('Tests' 'Tests-jr.366' 'a91286d9-df10-e24e-b128-dc03557db77a')
> dependency ('PackageInfo-Base' 'PackageInfo-Base-jr.70'
> '4eaf925f-ff65-7647-8ef5-f9d0c9f7b58c')
> dependency ('SUnit' 'SUnit-jr.106' '675e77ab-782e-2c47-a754-a9d1ca6f9c03')
> dependency ('SUnitGUI' 'SUnitGUI-jr.65'
> '2fc0a490-bd92-cc43-96c7-ede4b233243d')
> dependency ('Morphic' 'Morphic-jr.1325'
> 'ec6312f8-a496-fe46-8c4e-e1ca155b499d')
> )) upgrade

Thanks, this loads cleanly into my trunk 64 image, and causes no problems
that I can see with respect to normal Squeak usage.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Environment changes in the Inbox

Hannes Hirzel
Another confirmation:

(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.664'
'5f7f61e8-c5f7-7749-8d7f-c39b5b4584fb')
dependency ('Tests' 'Tests-jr.366' 'a91286d9-df10-e24e-b128-dc03557db77a')
dependency ('PackageInfo-Base' 'PackageInfo-Base-jr.70'
'4eaf925f-ff65-7647-8ef5-f9d0c9f7b58c')
dependency ('SUnit' 'SUnit-jr.106' '675e77ab-782e-2c47-a754-a9d1ca6f9c03')
dependency ('SUnitGUI' 'SUnitGUI-jr.65' '2fc0a490-bd92-cc43-96c7-ede4b233243d')
dependency ('Morphic' 'Morphic-jr.1325' 'ec6312f8-a496-fe46-8c4e-e1ca155b499d')
)) upgrade


loads fine into a Squeak6.0alpha-16966-32bit.image

I start testing it....

--Hannes


On 3/3/17, David T. Lewis <[hidden email]> wrote:

> On Thu, Mar 02, 2017 at 07:23:21PM -0800, Bert Freudenberg wrote:
>> 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:
>>
>> (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.664'
>> '5f7f61e8-c5f7-7749-8d7f-c39b5b4584fb')
>> dependency ('Tests' 'Tests-jr.366' 'a91286d9-df10-e24e-b128-dc03557db77a')
>> dependency ('PackageInfo-Base' 'PackageInfo-Base-jr.70'
>> '4eaf925f-ff65-7647-8ef5-f9d0c9f7b58c')
>> dependency ('SUnit' 'SUnit-jr.106' '675e77ab-782e-2c47-a754-a9d1ca6f9c03')
>> dependency ('SUnitGUI' 'SUnitGUI-jr.65'
>> '2fc0a490-bd92-cc43-96c7-ede4b233243d')
>> dependency ('Morphic' 'Morphic-jr.1325'
>> 'ec6312f8-a496-fe46-8c4e-e1ca155b499d')
>> )) upgrade
>
> Thanks, this loads cleanly into my trunk 64 image, and causes no problems
> that I can see with respect to normal Squeak usage.
>
> Dave
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Environment changes in the Inbox

Jakob Reschke-2
In reply to this post by Jakob Reschke-2
2017-03-03 0:06 GMT+01:00 Bert Freudenberg <[hidden email]>:
>
> 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?

The metaphor sounds adequate to me, but I think the validity of the
contrast depends on your view of what environments really are in the
context of modules or namespaces.

An object file compiled from C also does not know where its externals
will come from until it is linked with other objects or libraries.
Java classes also do not know where the other packages will come from
until a class loader starts collecting things from a classpath.
Environment variables (ha!) like PATH, CLASSPATH, PYTHONPATH, and
include paths might be a good analogy for our environments: they
provide a context to resolve names (executable names, fully qualified
class names, module names, included file names, and in Squeak "global"
variables) by the system (runtime, compiler/linker), and they
typically do not appear in the source code. They are part of a module
system, but they are neither the module system all by themselves nor
namespaces as a language feature. In fact, they are not language
features at all.

Our environments are different from those path variables in that they
support renaming and fine granular imports. In Python, Java, C++ this
is done by the language's "import" features. Hence, Python modules,
Java packages, and C++ namespaces (and C function prototypes, if you
want to look at them as imports) all do appear in the source code. For
this aspect, your contrast definitely holds.

It might be interesting that the centrality of PYTHONPATH also poses a
challenge to coexisting applications, leading to solutions like
virtualenv. In Squeak we can either use multiple images or use
multiple environments to resolve conflicts.


2017-03-03 4:23 GMT+01:00 Bert Freudenberg <[hidden email]>:
> On Thu, Mar 2, 2017 at 6:34 PM, Jakob Reschke <[hidden email]>
> wrote:
>
> Is it fair to say that we can pretty much ignore environments in daily use?
> That we only create one if we need it? Or do you think they would be useful
> for regular development?

You should not always need them and you can usually ignore them,
unless you run into Path classes frequently... ;-) If the Smalltalk
library ecosystem were larger (Java sized), the need for more explicit
namespaces or environments might be more pressing.

Reply | Threaded
Open this post in threaded view
|

Re: Environment changes in the Inbox

Jakob Reschke-2
In reply to this post by Jakob Reschke-2
2017-03-03 3:15 GMT+01:00 Chris Muller <[hidden email]>:

> 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..
>
> [...]
>
>> 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.

That might be true if you are developing an application as in "the
thing that you want to start up an image for". But what I am currently
working on is not meant to be an application in that sense, but
another set of tools and a library. I expect them to be loaded to
support development of other applications, not to be loaded all for
themselves (as much as FileSystems is a library, from Squeak's
perspective). And for a library, I do not like the idea of telling
users that they must first rename some class in their system before
they can safely install the library. Performing the rename silently in
a pre-load script is even more offensive IHMO, see below.

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

I do not really understand. Maybe there was a misunderstanding. If my
library automatically renames Path to St80Path (or forces the user to
do it manually) and at a later time the user loads another package
that has "Path" in some method that expects it to be the Path from
ST80, the code is screwed. Sounds like a problem that Craig tries to
solve with Naiad.

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

I touched the system in many places, indeed, but I do not agree to
have made it horribly more complex. The core of the matter is
replacing the singleton "Smalltalk" or "Smalltalk globals" by
references to something that is more specific to the respective
context, and making sure that the context tells which more specific
environment that has to be.

What does have become somewhat more complex is to think about how to
correctly load code, when you develop the loading facilities. But how
loading and compiling works is hardly trivial anyway. In comparison to
other systems, it probably is, but not absolutely.

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

Programming tools are for developers. Nobody criticizes their
unconditional presence, though. Environments are a tool to be used
under the right circumstances, offering a way out of some tricky
conflicts that arise in the real world and that developers (or nerds)
need to solve.

Multiple environments simply are not the same as a single environment.
To simulate the view of a monolithic environment at any time, it might
help if browser & co. also showed the imported classes, not only the
declared classes of an environment. But then it is imperative to
indicate the environment more prominently, as Bert requested, because
otherwise users might be more frequently grabbing the wrong browser
window and wondering "why are my classes not here?"

If we wanted to always show all classes from all environments, each
visual class reference would have to carry an environment tag, like
"Path [FileSystems]" and "Path [MVC]" (could be omitted for the
original Smalltalk environment). It might be distracting, though. For
example when every other class in the test runner would carry a tag
and you could not easily deselect or filter by tag/environment. For
tools that have a category list, the tag could be added to the
category instead, segregating classes in dependent list views by
environment. Though, it might cause confusion about what categories
are (or rather are not). You would still need the tag on the class
name when no category is indicated, such as in message traces.
.

What is more important and where environments are really lacking at
the moment IMHO is that there is no easy or canonical way of
transferring them to another image. As long as my library uses
environments to deal with Path and friends, it cannot be installed by
simply loading a Monticello package or configuration. Users are still
burdened with setting up and organizing environments, like they would
traditionally be burdened with renaming ST80's Path and remembering it
when they encounter bugs in yet another package. So I agree that
environments are not a finished solution and realize they are not the
complete answer to the needs for a module system. But they will never
become better if you cannot even work with them.

Reply | Threaded
Open this post in threaded view
|

Re: Environment changes in the Inbox

David T. Lewis
In reply to this post by Tobias Pape
On Wed, Mar 01, 2017 at 04:40:56PM +0100, Tobias Pape wrote:
> Hi all,
>
> Should nobody object, I'll put Jakob's Environment improvements
> into the trunk tonight.
>
> Best regards
> -Tobias
>

Can we please move these changes moved into trunk now? I see no reason for
delay and I do not want to wait for bit rot to set in. This is good work,
so let's just get it done.

Thanks,
Dave
 

12