Importing class(es) from an ENVY Library

I am trying to write Smalltalk code to do what the browsers can do...
and it's proving a lot harder than I thought it would. I am trying to
write code to import the class from a .dat file that represents an
exported class.  (This is in support of some tools I am developing to
support distributed development, something ENVY doesn't do very well.)

I can get the app name (listing 1) and the class name from the .dat
file (listing 2)... but that seems to be the extent of what I can
accomplish. I have been pouring through EmInterface and
EmStandardAccessor for cluse.  I just want to do what the browser does
when you import a class, but I can't even find the code to step through
it.  I need to get the class editions from the .dat file and then copy
all or some of them to the default library. Sounds so simple.... I was
able to write code to import an entire application using
moveApplications.  Any thoughts?


Listing one: get the names of apps in the .dat file:
path :=3D 'c:\src\test\ClassToExport_2.0=AD.dat'.
previousDefaultLib :=3D EmLibrary default.
myLib :=3D EmLibrary new open: path readOnly: true.
myLib becomeDefault.
appNames :=3D Application allNames.


Listing 2: get class name(s)
appPartsRecord :=3D  (myLib operationsInterface)
applicationPartsRecordFor: Application named: appName.
className :=3D appPartsRecord classNamesDictionary keys
asSortedCollection.

Bring up the browser and Ctrl-Y into it.  Drill down into the builder
for the menu that contains the import.  Place your break point onthe
method for the appropriate selection.  Now you should be able to walk
through it.  If you can't find the menu in all the components it may be
easier to put a break point in the menu controller, but make sure
qualify it with something like control-alt-shift.

BTW: if you are using VW, just switch to Store.

Hope this helps,

Chris Lopeman

OK, its easier than I thought...
Having obtained the app name and class name, you can use:
app := Application shadowClass named: appName
timeStamp: EmTimeStamp undefined.
editions := app classEditionsFor:  className.
app move: (editions first) from: lib to: prevDefLib.

They key is that you can use a "dummy" shadow version of the app.

There's a bunch of discussion of this sort of thing in the Mastering
ENVY/Developer book, if you can still find it.

"PaulAtKP" <paul.macmillan@kp.org> wrote in news:1117153747.512198.112810
@g14g2000cwa.googlegroups.com:

> OK, its easier than I thought...
> Having obtained the app name and class name, you can use:
> app := Application shadowClass named: appName
>                timeStamp: EmTimeStamp undefined.
> editions := app classEditionsFor:  className.
> app move: (editions first) from: lib to: prevDefLib.
>
> They key is that you can use a "dummy" shadow version of the app.
>
>



--
Alan Knight [|], Cincom Smalltalk Development
knight@acm.org
aknight@cincom.com
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." -
Niall Ross

Maybe I am a little sensitive after seeing years of st criticism, the java
people coming and criticizing, etc. . . . but the comment was made by the
OP, 'envy does not handle distirbuted development very well'.  I would like
to know who does handle it well?  Distributed in this case sounds like
multi-code base/muti-repository development.

-g

Actually, I think that what was meant was more simply geographical
distribution. ENVY likes to have a fast connection always available. It's
also not ideal for distributed development, in that to copy things between
repositories, you need to version, which is a fairly heavy operation. I
think it works reasonably well with checkpoints, though.

I think that both Store and Monticello work well for the multi-code
base/multi-repository situation, depending of course on exactly what the
situation is.

"Geoff" <nospam@nospam.com> wrote in
news:uU7me.1627$s64.170@newsread1.news.pas.earthlink.net:

> Maybe I am a little sensitive after seeing years of st criticism, the
> java people coming and criticizing, etc. . . . but the comment was
> made by the OP, 'envy does not handle distirbuted development very
> well'.  I would like to know who does handle it well?  Distributed in
> this case sounds like multi-code base/muti-repository development.
>
> -g
>
>
>
>



--
Alan Knight [|], Cincom Smalltalk Development
knight@acm.org
aknight@cincom.com
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." -
Niall Ross

Store has as huge advantage over Envy in that you can work while
disconnected. But saying that it works 'well' for multi repository or
distributed development is something I wouldn't do. It supports
switching between multiple repositories but that is roughly where the
support ends too.

For instance replicating code between Store repositories does not yield
congruent version trees. Comparing code between repositories is not
supported, loading prerequisite packages from different repositories is
not supported etc.
Finally working remotely is dead slow, publishing reasonably sized
packages from the other side of the globe is something you need to plan
since it takes *hours* instead of seconds.


R
-


Alan Knight wrote:
> Actually, I think that what was meant was more simply geographical
> distribution. ENVY likes to have a fast connection always available. It's
> also not ideal for distributed development, in that to copy things between
> repositories, you need to version, which is a fairly heavy operation. I
> think it works reasonably well with checkpoints, though.
>
> I think that both Store and Monticello work well for the multi-code
> base/multi-repository situation, depending of course on exactly what the
> situation is.
>
> "Geoff" <nospam@nospam.com> wrote in
> news:uU7me.1627$s64.170@newsread1.news.pas.earthlink.net:
>
> 
>
>
>
>

Reinout Heeck <reinout@soops.nl> wrote in
news:2e6e2$429c04bb$3e3aa2c2$18347@news.versatel.net:

> Store has as huge advantage over Envy in that you can work while
> disconnected. But saying that it works 'well' for multi repository or
> distributed development is something I wouldn't do. It supports
> switching between multiple repositories but that is roughly where the
> support ends too.
>
> For instance replicating code between Store repositories does not
> yield congruent version trees.

What do you mean by that?

> Comparing code between repositories is
> not supported, loading prerequisite packages from different
> repositories is not supported etc.

Well, as I said, it depends on exactly what the situation is, and what
one means by distributed. I tend to think of it as meaning that you have
multiple local databases, and that they can be synced together fairly
easily and quickly.  That, I think, works fairly well, at least with
judicious use of add-ons. I have the things I work on syncing back and
forth between my local repository, the public Store in Cincinnati, and
our internal database in Santa Clara hourly. That was part of my
motivation for writing said add-ons.

I don't tend to think of distribution as meaning that different versions
and/or different packages will be in different databases and remain
there, although that's clearly another type of usage that could be
desirable to support.

> Finally working remotely is dead slow, publishing reasonably sized
> packages from the other side of the globe is something you need to
> plan since it takes *hours* instead of seconds.

Well, I can replicate across the globe in seconds, or perhaps minutes
depending on exactly what needs copying. The same code is very nearly
capable of publishing, but I don't quite trust the representation
conversion involved enough to enable it yet.

> R
> -
>
>
> Alan Knight wrote: 



--
Alan Knight [|], Cincom Smalltalk Development
knight@acm.org
aknight@cincom.com
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it
run." - Niall Ross