<div dir="ltr"><div>I'll try to recapitulate this from memory because I don't want to search for this image from 2016 and have changed the code of FileSystem-Git (the variant included with Squot) since then, so it does not need another environment any longer.</div><div><br></div>I created a new environment that imported all of Smalltalk, and then tried to load FileSystem-Git into this new environment. To make this loading work, I changed various packages and submitted the patches back in 2016/2017, so that the code loading facilities in Squeak would compile code in the "current" Environment (see Environment class>>current). So you make this environment the current one while running a block that loads the code. During that it would then complain about missing required class definitions for those classes that have different names in Pharo. So I imported specifically these classes a second time under their Pharo names from the Smalltalk environment. Eventually this environment "contained" the FileSystem-Git classes.<div><br></div><div>Code compiled in this environment would resolve Path to FSPath instead of ST80's Path. The latter was invisible in the other environment. Though you could access the ST80 Path with dynamic look-ups such as Object environment valueOf: #Path (because Object came from the original Smalltalk environment) or (Environment named: #Smalltalk) valueOf: #Path, but I didn't need that for FileSystem-Git.<div><div><br></div><div>Finally I imported this other environment back into Smalltalk, so all the FileSystem-Git classes became visible there (not via Smalltalk at:, but with Smalltalk globals valueOf:, and of course when compiling code with class references). Since only the declarations are exported from the other environment, not the bindings, Path still resolved to ST80 Path 

in the Smalltalk environment 

and the FileSystem-Git class names resolved to those classes in the other environment, done.</div><div><div><br></div><div>Code reproduced from mind to set up the environment and import back to Smalltalk:</div><div>(All of this happened in a workspace because as of now there are no tools for configuring environments.)</div><div>"initialize new environment"</div><div>(Environment named: 'FileSystem-Git')</div><div>   exportSelf; importSelf;</div><div>   import: Smalltalk globals.</div><div>"load FileSystem-Git"</div><div>(Environment named: 'FileSystem-Git') beCurrentDuring:</div><div>    [Metacello new "... load FileSystem-Git, or use Gofer or set the environment of the package in MCWorkingCopyBrowser, or whatever to load it"].</div><div>"repeat the above after the following changes until it loads successfully"</div><div>"import certain classes under different names"</div><div>(Environment named: 'FileSystem-Git')</div><div>    from: Smalltalk globals import: #FSPath -> #Path;</div><div>    from: Smalltalk globals import: #FSFileSystem -> #FileSystem;</div><div>    from: Smalltalk globals import: #FSReference -> #FileReference</div><div>    ...</div><div>"open browser to look at the other environment"<br></div><div>((Environment named: 'FileSystem-Git') valueOf: #GitRepository) browse.</div><div>"make classes of other environment visible in Smalltalk globals"</div><div>Smalltalk globals import: (Environment named: 'FileSystem-Git').</div><div><br></div></div></div></div><div><div>Later I added a "change environment..." menu item to the Monticello working copy menu in the Monticello browser, and introduced this MCPackageInEnvironment decorator to make it possible to load code into another environment via the Monticello tools. It works by transparently making the selected environment for the working copy "current" around the snapshot and load operations. To use this, first press +Package before loading, then yellow-click: change environment, select the prepared environment, then proceed to add repositories to the working copy and load the code from there.<br><div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Fr., 20. Dez. 2019 um 17:11 Uhr schrieb David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Can you explain how this worked once the FileSystem-Git package<br>
was loaded into a different environment? If I understand correctly,<br>
you would have the ST-80 class named 'Path' in the default Smalltalk<br>
environment, and you would also have the FileSystem class named<br>
'Path' in a different environment.<br>
<br>
To start making use of FileSystem-Git in the different environment,<br>
is it simply a matter of changing the current environment from<br>
Smalltalk to the different environment? And/or is there some mechanism<br>
for explicitly specifying which of the two 'Path' classes is being<br>
referenced?<br>
<br>
Sorry if this is a repeat question, I am quite sure that you have<br>
explained this previously but I am (obviously) a bit confused.<br>
<br>
Thanks,<br>
Dave<br>
<br>
<br>
On Fri, Dec 20, 2019 at 04:07:31PM +0100, Jakob Reschke wrote:<br>
> Hi,<br>
> <br>
> I loaded FileSystem-Git in a different environment where the FileSystem<br>
> classes for Squeak were named like they are in Pharo (without the FS<br>
> prefix, which was especially troublesome for the class "Path").<br>
> <br>
> Environments don't take away the effort of adapting the interface (messages<br>
> sent and methods) though.<br>
> <br>
> Kind regards,<br>
> Jakob<br>
> <br>
> <br>
> Am Fr., 20. Dez. 2019 um 15:06 Uhr schrieb Marcel Taeumel <<br>
> <a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>>:<br>
> <br>
> > If I recall correctly, Jakob (jr) could successfully load a second<br>
> > FileDirectory implementation into Squeak using the environments. Maybe he<br>
> > can help out?<br>
> ><br>
> > Best,<br>
> > Marcel<br>
> ><br>
> > Am 19.12.2019 21:52:37 schrieb tim Rowledge <<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>>:<br>
> ><br>
> ><br>
> > > On 2019-12-19, at 6:50 AM, Marcel Taeumel wrote:<br>
> > ><br>
> > > > ... lots of differently named classes ...<br>
> > ><br>
> > > So, you can try out Squeak's environments for that? :-)<br>
> > If I had ever read anything that appeared to explain them and the tools to<br>
> > use them without going insane, I might try. Personally I think it unlikely<br>
> > to work. Happy to be shown evidence to the contrary.<br>
> ><br>
> ><br>
> > tim<br>
<br>
<br>
<br>
</blockquote></div>