[squeak-dev] Environment changes in the Inbox

Jakob Reschke jakob.reschke at student.hpi.de
Thu Mar 2 22:30:09 UTC 2017


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 <jakob.reschke at student.hpi.de>:
> 2017-03-02 2:44 GMT+01:00 Bert Freudenberg <bert at freudenbergs.de>:
>> On Wed, Mar 1, 2017 at 3:42 PM, Jakob Reschke <jakob.reschke at student.hpi.de>
>> wrote:
>>>
>>>
>>> My Environments use case, for which I have gone through all of this,
>>> is that I need to use and work on a Pharo package that uses the
>>> FileSystem library. The FileSystem classes have different names in
>>> Pharo, compared to the FS package available on SqueakSource.
>>
>>
>>
>> Can you walk us through this use case? What tools do you use in which order?
>
> 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. ;-)


More information about the Squeak-dev mailing list