porting VW code to squeak

> Hi,
>
> I loaded FileSystem-Git in a different environment where the FileSystem
> classes for Squeak were named like they are in Pharo (without the FS
> prefix, which was especially troublesome for the class "Path").
>
> Environments don't take away the effort of adapting the interface (messages
> sent and methods) though.
>
> Kind regards,
> Jakob
>
>
> Am Fr., 20. Dez. 2019 um 15:06 Uhr schrieb Marcel Taeumel <
> [hidden email]>:
>
> > If I recall correctly, Jakob (jr) could successfully load a second
> > FileDirectory implementation into Squeak using the environments. Maybe he
> > can help out?
> >
> > Best,
> > Marcel
> >
> > Am 19.12.2019 21:52:37 schrieb tim Rowledge <[hidden email]>:
> >
> >
> > > On 2019-12-19, at 6:50 AM, Marcel Taeumel wrote:
> > >
> > > > ... lots of differently named classes ...
> > >
> > > So, you can try out Squeak's environments for that? :-)
> > If I had ever read anything that appeared to explain them and the tools to
> > use them without going insane, I might try. Personally I think it unlikely
> > to work. Happy to be shown evidence to the contrary.
> >
> >
> > tim

> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Code reproduced from mind to set up the environment and import back to
> Smalltalk:
> (All of this happened in a workspace because as of now there are no tools
> for configuring environments.)
> "initialize new environment"
> (Environment named: 'FileSystem-Git')
>    exportSelf; importSelf;
>    import: Smalltalk globals.
> "load FileSystem-Git"
> (Environment named: 'FileSystem-Git') beCurrentDuring:
>     [Metacello new "... load FileSystem-Git, or use Gofer or set the
> environment of the package in MCWorkingCopyBrowser, or whatever to load
> it"].
> "repeat the above after the following changes until it loads successfully"
> "import certain classes under different names"
> (Environment named: 'FileSystem-Git')
>     from: Smalltalk globals import: #FSPath -> #Path;
>     from: Smalltalk globals import: #FSFileSystem -> #FileSystem;
>     from: Smalltalk globals import: #FSReference -> #FileReference
>     ...
> "open browser to look at the other environment"
> ((Environment named: 'FileSystem-Git') valueOf: #GitRepository) browse.
> "make classes of other environment visible in Smalltalk globals"
> Smalltalk globals import: (Environment named: 'FileSystem-Git').
>
> 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.
>
> Am Fr., 20. Dez. 2019 um 17:11 Uhr schrieb David T. Lewis <
> [hidden email]>:
>
> > Can you explain how this worked once the FileSystem-Git package
> > was loaded into a different environment? If I understand correctly,
> > you would have the ST-80 class named 'Path' in the default Smalltalk
> > environment, and you would also have the FileSystem class named
> > 'Path' in a different environment.
> >
> > To start making use of FileSystem-Git in the different environment,
> > is it simply a matter of changing the current environment from
> > Smalltalk to the different environment? And/or is there some mechanism
> > for explicitly specifying which of the two 'Path' classes is being
> > referenced?
> >
> > Sorry if this is a repeat question, I am quite sure that you have
> > explained this previously but I am (obviously) a bit confused.
> >
> > Thanks,
> > Dave
> >
> >
> > On Fri, Dec 20, 2019 at 04:07:31PM +0100, Jakob Reschke wrote:
> > > Hi,
> > >
> > > I loaded FileSystem-Git in a different environment where the FileSystem
> > > classes for Squeak were named like they are in Pharo (without the FS
> > > prefix, which was especially troublesome for the class "Path").
> > >
> > > Environments don't take away the effort of adapting the interface
> > (messages
> > > sent and methods) though.
> > >
> > > Kind regards,
> > > Jakob
> > >
> > >
> > > Am Fr., 20. Dez. 2019 um 15:06 Uhr schrieb Marcel Taeumel <
> > > [hidden email]>:
> > >
> > > > If I recall correctly, Jakob (jr) could successfully load a second
> > > > FileDirectory implementation into Squeak using the environments. Maybe
> > he
> > > > can help out?
> > > >
> > > > Best,
> > > > Marcel
> > > >
> > > > Am 19.12.2019 21:52:37 schrieb tim Rowledge <[hidden email]>:
> > > >
> > > >
> > > > > On 2019-12-19, at 6:50 AM, Marcel Taeumel wrote:
> > > > >
> > > > > > ... lots of differently named classes ...
> > > > >
> > > > > So, you can try out Squeak's environments for that? :-)
> > > > If I had ever read anything that appeared to explain them and the
> > tools to
> > > > use them without going insane, I might try. Personally I think it
> > unlikely
> > > > to work. Happy to be shown evidence to the contrary.
> > > >
> > > >
> > > > tim
> >
> >
> >
> >