VersionOfDoc.tioga
Mike Spreitzer, July 24, 1986 1:37:25 pm PDT
VersionOf
CEDAR 6.1 — FOR INTERNAL XEROX USE ONLY
VersionOf
Mike Spreitzer
© Copyright 1986 Xerox Corporation. All rights reserved.
Abstract: VersionOf provides a procedural and a command-tool interface for discovering the version stamps of loaded modules and BCD files. The command also shows the nesting of modules in the loadstate.
Created by: Mike Spreitzer
Maintained by: Mike Spreitzer <Spreitzer.pa>
Keywords: Loadstate, Loaded, Module, VersionStamp, BCD file, Config, Bound Modules, Nested Modules, Module Nesting
XEROX   Xerox Corporation
    Palo Alto Research Center
    3333 Coyote Hill Road
    Palo Alto, California 94304

For Internal Xerox Use Only
1. Cedar Interface
VersionOf.Mesa
There are three procedures. One, NamedContexts, is rather general --- it lets you get your hands on the Abstract Machine's representation for loaded modules. This procedure is here because the corresponding procedure in the Abstract Machine (AMModel.NamedContexts) is an enumerator, and is thus a pain to call from the interpreter.
Another, GetVersions, is more specialized. It's for finding out what's going wrong when you've got version problems. It simply returns a list of the version stamps of the loaded instances of modules with the given name.
There is also a procedure, VersionOfBcd, for getting the version stamp out of a BCD file. This is useful for comparison with version stamps from the loadstate.
2. Command-tool Interface
name VersionOf:
syntax
VersionOf moduleNameOrFileName moduleNameOrFileName ...
description
Want to know what version of the STPServer you're running? Want to know what's the latest version? This command will do it. If an argument includes the string ".bcd", it is taken to be the name of a BCD file, which is read, and whose version stamp is reported. Otherwise an argument is taken to be the name of a module in the loadstate, and the version stamp of each module in the loadstate with the given name is reported.
Another puzzler people are sometimes faced with is this: FooImpl is in the loadstate, but the loadstate offers nothing in interface Foo, even though FooImpl exports Foo. This probably means that FooImpl is bound into something that doesn't export Foo --- but what? When the VersionOf command prints information about a module in the loadstate, it also describes the module it's bound into, if any.
examples
% VersionOf FastMouse [Cedar]<CedarChest6.1>FastMouse>FastMouse.bcd
FastMouse:gfh#70714—181703d1e167 in FastMouse—181703d1e167
[Cedar]<CedarChest6.1>FastMouse>FastMouse.bcd!6—181703d1e167
The user wondered if he is running the current version of FastMouse; he found out he is.
% VersionOf ComputeServerImpl
ComputeServerImpl:gfh#75024—46ae3d05d15e in SummonerPackage:ConfigIndex#63—fc079e66e753
This user noted that although ComputeServerStatistics.NextServerEvent is exported by ComputeServerImpl, and ComputeServerImpl is in the loadstate, ComputeServerStatistics.NextServerEvent is unavailable. So this user wondered what turkey config forgot to export ComputeServerStatistics --- and found out that it's SummonerPackage. Note that in fact this is wrong --- ComputeServerImpl is bound into SummonerServer, which is then bound into SummonerPackage. The Abstract Machine sometimes tells lies.
% VersionOf Watch
Watch:gfh#23334—31a8875be1ff in Watch—31a8875be1ff
This poor sucker just wanted to see something work, but stumbled on another of the Abstract Machine's current bogosities --- it sometimes invents phony configs. In truth, the program Watch is not bound into a config named Watch --- it just looks that way.
stop/undo
STOP!
Warnings
The module nesting reported by the VersionOf command may be slightly wrong --- the Abstract Machine sometimes tells lies.