[squeak-dev] Using Environments (was: porting VW code to squeak)

Jakob Reschke forums.jakob at resfarm.de
Fri Dec 20 22:12:32 UTC 2019


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 <
lewis at mail.msen.com>:

> 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 <
> > marcel.taeumel at hpi.de>:
> >
> > > 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 <tim at rowledge.org>:
> > >
> > >
> > > > 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191220/34547ed4/attachment.html>


More information about the Squeak-dev mailing list