Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!news.kei.com!newsfeed.internetmci.com!swrinde!sdd.hp.com!hplabs!hplextra!hplb!gw
From: gw@hplb.hpl.hp.com (Gunther Walther)
Subject: Re: ENVY: Installing PP Tools
Sender: news@hplb.hpl.hp.com (Usenet News Administrator)
Message-ID: <DIwxx9.D8C@hplb.hpl.hp.com>
Date: Fri, 1 Dec 1995 15:05:33 GMT
References: <49htgn$8kh@stern.fokus.gmd.de>
Nntp-Posting-Host: gwalther.hpl.hp.com
Organization: Hewlett-Packard Laboratories, Bristol, England
X-Newsreader: TIN [version 1.2 PL0.7]
Lines: 79

In article <49htgn$8kh@stern.fokus.gmd.de> you wrote:
: It's me and my ENVY, one more time,
:
: I have installed the ParcPlace Advanced Tools and DLL & C-Connect
: as new subapplications. 'FullBrowser' does not work, O.K, but now
: I want to use these tools as another user, but load of this
: PP-Tools edition fails. Obviously the order in which the classes are
: loaded and initialized is different from those when installing the
: tools. Is this a major problem of ENVY? The same happened
: for me with SmallWalker. 

The Advanced Tools are tricky. The problem is caused by changing
the compiler while filing it in. The Advanced Tools are bootstraped
as follows (during file in):

	1) file in new decompiled parser
	2) change over to the new parser
	3) file in source code (written in new language)
	   for the new parser (which at the moment is
	   compiled and running decompiled code)

The problem is caused by step 3), as step 3 overwrites the code
filed in in step 1). Now if you try to load the code from
step 3), you are in trouble, unless you loaded the code
from 1) first.

The is no easy way around it (please prove me wrong 8-), as long as
step 3) overwrites the code from step 1). An Advanced Tools version
from OTI also required a 2 manual step load (As far as I under-
stand it, the problem is there that changes are not committed until
the *whole* load has succeeded. So no matter what dependencies you
set up, it has to be two steps).

I would prepare an Envy image that contains APOK and the
parser which is owned by nobody and is in a public place.
Then other users can start with this image and don't have
to to learn about the loading issues. In most case your
project will have some baseline to start out. Having
an image which is at that baseline is a natural thing to
do, even if you could load the complete configuration map
in one step. There should not be any problem loading
subsequent versions of an initial configuration map, as
long as the parser is still in the image.

Hope this helps,

gunther


PS: As long as you avoid the parser and SQL stuff, the APOK
    should load/unload fine.

PS: The ways to get around the bootstrapping in Envy that I can
    see are:

	a) for OTI to provide a way to commit a partial load
	   after loading an application. One would also need
	   to set up dependencies between different versions
	   of applications. This approach feels like opening
	   a big can of worms...

	b) for PP to come up with a bootstrap process that
	   avoids overwriting code. Instead of filing out
	   decompiled code *for* the real parser, they could
	   file out (or generate within the image in a different
	   class) decompiled code *of* the real parser but
	   *for* a bootstrap parser class, that stays in place
	   and does not get overwritten. They have then to switch
	   between parsers once more, but this should not be
	   a great deal. However this still would require OTI
	   to provide a way to commit a partial load of an
	   application immediately after loading it in order
	   to avoid the two step loading process.

------------------------------------------------------------------
Gunther Walther                 | Phone: +44 117 9228518 (direct)
Hewlett-Packard Laboratories,   |    or: +44 117 9799910 x28518  
Filton Road, Stoke Gifford,     | FAX:   +44 117 9228972
Bristol, BS12 6QZ, U.K.         | EMAIL: gw@hplb.hpl.hp.com
