Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.mathworks.com!newsfeed.internetmci.com!howland.reston.ans.net!ix.netcom.com!netcom.com!kthompso
From: kthompso@netcom.com (Kevin Thompson)
Subject: Re: Envy to Non-Envy Image Conversion?
Message-ID: <kthompsoDpCo7s.MJo@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: <4k0q17$9d8@atlantis.dis.anl.gov>
Date: Thu, 4 Apr 1996 18:19:03 GMT
Lines: 33
Sender: kthompso@netcom20.netcom.com

In article <4k0q17$9d8@atlantis.dis.anl.gov>,
Mark Woyna <woyna@eid.anl.gov> wrote:
>Is there a prefered way to convert an Envy 3.01/VisualWorks 2.5 image
>into a standard VisualWorks 2.5 image? We have a single Envy license
>which we are using primarily for history management and I have a need
>to produce a non-Envy version of the image for our clients who will
>continue development of the product. They all have full development
>licenses.
>
>The ImageMaker utility strips out the development environment, and it
>appears that parcels to do not preserve the source code when they are
>loaded into a new image. Is this correct?
>
>I would hate to think that we have to file-out and file-in our entire
>application.

One *would* hate to think it, but it's what we do (in 2.0, we don't have 2.5)
... and Envy doesn't really support it properly.  Some things to be careful
of:
        order of class initialize (and getting them in at all)
        getting all class definitions out before any code (Envy has shadows,
non-Envy is sequential, order much more important)
        worst: you can *easily* write code dependent on OTI-specific methods.
We've ended up having to mark some dozen OTI methods as "things to go out in
our non-Envy image".  Often OTI has changed the semantics of a VW method, and
you don't notice for a long time ...

It never ceases to amaze me how much Envy assumes you'll *always* want to be
in Envy.

Kevin
-- 
kthompso@netcom.com        
