DF Suites in PCedar DF Suites in PCedar Eduardo Pelegri-Llopart and Ken Pier Abstract: This is the organization of the DF suites for PCedar and packages shared between PCedar and DCedar. This document was valid for PCedar2.0 but for Cedar10.1 a very much simpler structure for df files is used. Created by: Eduardo Pelegri-Llopart Maintained by: Ken Pier Keywords: DF files, system modeling, smodel, suite, slice, makedo XEROX Xerox Corporation Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, California 94304 A note on Notation Throughout this document, the generic names CedarCommon, PCedar, and DCedar are used. They are expected to be mapped via pseudoservers in the D-Machine world and by prefix maps in the PCedar world into meaningful, release specific storage hierarchies. On March 6, 1990, CedarCommon mapped into CedarCommon2.0, PCedar into PCedar2.0, and DCedar references into Cedar7.0 and CedarChest7.0. Although this document uses "slashy" notation for path names, actual DF software requires the use of "brackety" path names in DF files. It may be helpful to the reader to refer to the examples at the end of this document and to actual DF files to illustrate and clarify this material. 1. Packages, Suites and Slices System modeling for PCedar is substantially more complex than for DCedar. Among the issues to consider are: multiple target machines (sun4, future platforms), multiple variants within a target machine (unoptimized, optimized, profiled, etc), multiple levels at which code is shared (source, installation files, runtime files, etc), system dependencies constraints (e.g. relative to non-local access and trickle-charging), and some compatibility with current usage. Existing DF tools cannot be twisted to provide adequate support for all the configurations of interest. Thus, the goal of the current method, described below, is to provide enough for our immediate needs until we build/obtain better system modeling tools. A package is described by a collection of DF files. We associate with each DF file the set of configurations to which it applies. A file f belongs to the DF file representing the largest number of configurations on which f applies. For example, documentation files may belong to -Source.df, while .mob (Mimosa compiler output) files to -PCR.df, and sun4>Foo.c2c.o to -Sun4.df. All the PCedar DF files for a package, the suite of DF files, are listed in the -Suite.df file. A configuration is specified by a sub-collection of DF files, also called a slice. Previously, slices were not described explicitly by DF files, but implicitly through system modeling commands. Thus, there exist(ed) a "MakeDo4" command that takes as arguments package names, uses them to select corresponding slices and then rebuilds them. Currently, a MakeDo command will take a top-level DF file and create all the slices included in that DF file. This is supposed to be a simplification. More below. The "Sun4 slice" includes -Source, -PCR, and -Sun4 DF files. The "Sun4O3 slice" includes -Source, -PCR, and -Sun4O3 DF files. Unshared Packages For a package called Foo that is entirely contained in PCedar and does not share any files with DCedar, the DF files involved are Foo-Suite.df, Foo-Source.df, Foo-PCR.df, Foo-Sun4.df, and Foo-Sun4O3.df; DF organization for sharing is discussed below. All the PCedar DF files for a package, the suite of DF files, are included in a top-level DF file, the -Suite.df file, which would be Foo-Suite.df in our example. All of these DF files reside in the /PCedar/Top/ directory and reference only other files in /PCedar/Top/ or files in the subdirectories /PCedar/Foo/, /PCedar/FamousFiles/, /PCedar/Foo/sun4/, and /PCedar/Foo/sun4-o3/. Readers unfamiliar with this DF organization may want to browse an existing unshared suite of DF files to illustrate this organization. /PCedar2.0/Top/IO-Suite.df is a good example. A package that remains totally in the DCedar domain can still have a single DF file, Foo.df, which describes it entirely and resides in /Cedar(Chest)7.0/Top/. It is imperative that this file not reference files in the PCedar storage hierarchy or the CedarCommon storage hierarchy. Shared Packages It is often desirable to share files between PCedar and DCedar; shareable files include source code, documentation, and runtime files. The previous sharing mechanism, in which shared files live in the DCedar domain, has been replaced by a new method which decouples the two worlds. A new domain, called (generically) CedarCommon, has been created. Files which are truely common (shared) between PCedar and DCedar need to be managed by top-level DF files in CedarCommon; top-level DF files in CedarCommon may only reference subdirectories in the CedarCommon hierarchy. In particular, package implementors managing shared sources in Foo-Source.df files currently in /Cedar(Chest)7.0/Top/ need to rework those -Source.df files to live in /CedarCommon/Top/ and to reference /CedarCommon/Foo/ directories. For non-source-shared packages that wish to share files (e.g. .tip, .icon(s), .gargoyle, and documentation(!)), a new type of DF file called -Common.df may be created and stored in /CedarCommon/Top/. PCedar runtime files, notably .tip and .icon(s), are required to live in the FamousFiles subdirectory of which there are now two: /PCedar/FamousFiles/ for unshared runtime files and /CedarCommon/FamousFiles/ for shared runtime files (for an explanation, see below under FamousFiles). Foo-Suite.df files on the PCedar side and Foo.df files on the DCedar side should be changed to Include the CedarCommon DFs as needed. A shared DF package might look like: For a source-shared package Foo, the Foo-Source.df may also manage other common files, including FamousFiles, and be manipulable from either PCedar or DCedar using the DF tools. Or, package implementors may create a Foo-Common.df file in /CedarCommon/Top/ which only references files in the CedarCommon subdirectories, such as /CedarCommon/Documentation/ or /CedarCommon/FamousFiles/. For package implementors willing to maintain a Foo-Common.df, non-source common files, including FamousFiles, can be managed in it. This could be especially useful for documentation and runtime files where there is no source code sharing. It is then necessary that Foo-Suite.df files on the PCedar side and Foo.df files on the DCedar side Include the CedarCommon-resident Foo-Common.df. See the example at the end of this document or browse /PCedar2.0/Top/BiScrollers-Suite.df and/or /PCedar2.0/Top/Gargoyle-Suite.df for an example of a shared package. FamousFiles Sometimes a package needs to read a data file that is maintained along with that package. Common examples are TIP tables and icon files. Usually these package data files are read during the start code of the package, but not always. The question arises of how the package should refer to these files, since absolute file names are frowned upon (and not always correct). The DCedarChest solution starts with making these data files public in the package's DF. Thus, a BringOver of the package puts these data files in the same directory as the program binaries. Because DCedarChest conventions ensure that the directory containing the binaries is current when they are run, a data file can be referred to with a short name (actually any relative name works) --- the same short (relative) name that is used in the package's DF. If the data file is to be read not during the starting of the package but later, the package must remember what directory was current at start time, and then look up the data file by a short (relative) name in that directory. The solution for DCedar (meaning the stuff in [Cedar7.0], as opposed to all D-machine Cedar stuff) is somewhat different, because DCedar corresponds roughly to the boot file and Basic.loadees, whose components are not started in the same way as DCedarChest components. However, DCedar programs also refer to their data files, if any, by relative names. By convention a certain local directory (unspecified in the convention, but currently []<>7.0>System>) is current during DCedar booting. A special DCedar-wide DF (BootEssentials.df) describes all the data files needed by DCedar programs, and DCedar booting normally includes a BringOver of this DF into that certain local directory. Again, if the data files are to be read later, the directory current during booting must be remembered. In PCedar, we do not have the Cedar/CedarChest distinction --- but there is a distinction between dynamically loaded packages and those bound into a packaged world via UNIX ld. The PCedar conventions ensure that during the starting of a dynamically loaded package, the release directory of the package (ie, /PCedar/PackageName/) is current. Thus, dynamically loaded packages could also refer to their data files by short names. Alas, it is not so for packages bound into packaged worlds, because there is no guarantee whatsoever about what directory will be current while a packaged world is starting. Note that this is worse than DCedar's problem in two ways: every package can be started in either way, and the current working directory is completely unspecified when starting pcakaged worlds. The solution is that PCedar packages search for their data files down the famous path, which is the following ordered list of directories: 1. the directory current when the package was started, 2. /PCedar/FamousFiles/, and 3. /CedarCommon/FamousFiles/. The starting directory is first so that when a maintainer is testing a new version, the new data files are found in preference to the old ones. /CedarCommon/FamousFiles/ is in the list so that these data files may be shared between PCedar and DCedar. /PCedar/FamousFiles/ comes before /CedarCommon/FamousFiles/ so that when a maintainer decides to cease source-sharing a data file, the new PCedar-specific version will be found in preference to the old shared version; it is expected that ceasing to source-share a previously shared file will be more common that starting to share a previously unshared-but-present-in-both-DCedar-and-PCedar file. Because the famous path uses .../FamousFiles/ rather than .../PackageName/, the package DF that owns the data file must put that data file in .../FamousFiles/ rather than .../PackageName/ (where ... is /PCedar or /CedarCommon, depending on whether the data file is shared). The implementations of Icons.NewIconFromFile and TIPUser.InstantiateNewTIPTable always search along the famous path when given a relative name; for all other kinds of data files this searching is not built in, and the package owning the data file is responsible for explicitly searching the famous path. There is a feeling underfoot that .../FamousFiles/ might not be a good idea --- a suspicion that we may want to change the famous path to be: 1. the directory current when the package was started, 2. /PCedar/PackageName/, and 3. /CedarCommon/PackageName/. Note that this makes the famous path depend on the name of the package owning the data file. And note that this may be different from the package that actually reads the data file; for example, while Gargoyle owns its TIP table, that table is read by the TIP package. If the module that determines where to find a data file is to be source-shared, it must follow both the DCedar(Chest) rules and the PCedar ones. To make this possible, we imagine that there is a famous path in DCedar and DCedarChest, and that it consists of two directories: the one current when the package is started, and /CedarCommon/FamousFiles/. Furthermore, there is an interface (FamousPath) that supports capturing and searching along this path. This interface can be used by any DCedar(Chest) or PCedar program. To be usable by programs in the DCedar bootfile means it must be a bootfile component, immediately following the FS package; it may be good enough to make the impl one of the Basic.loadees. [In an effort to minimize future changes, this interface takes the package name as a parameter, even though it is not currently used.] In PCedar, the implementation of this interface may be different for packaged worlds vs. dynamically loaded worlds; this means that clients cannot write a `Require' command that will always get the correct implementation, and thus the loading of the implementation, right after that of PFS, is the responsibility of each `World.pcr' file and world-packaging process. The interface looks like this: FamousPath: CEDAR DEFINITIONS = { ROPE: TYPE ~ Rope.ROPE; DirectoryList: TYPE ~ LIST OF ROPE; Search: PROC [packageName, relativeFName: ROPE] RETURNS [fullFName, directory: ROPE]; Get: PROC [packageName: ROPE] RETURNS [DirectoryList]; SearchList: PROC [list: DirectoryList, relativeFName: ROPE] RETURNS [fullFName, directory: ROPE]; Resolve: PROC [packageName, fName: ROPE] RETURNS [fullFName: ROPE]; ListResolve: PROC [list: DirectoryList, fName: ROPE] RETURNS [fullFName: ROPE]; }. Command and Require files .command files in PCedar are similar to .load files in DCedar. They reside in the well-know directory /PCedar/Commands/. When the CedarCommander is given an unknown command to execute, it follows its search path, which is defaulted to /PCedar/Commands/, looking for a .command (or .cm) file to interpret. A command file should reside there whose base name is the same as the command name; i.e. for a command named Bar, the corresponding command file is Bar.command. Usually, command files will Require that a package implementing that command be installed. See CommanderDoc.tioga for an explanation of Require. .require files in PCedar are similar to .install files in DCedar. They reside in their respective package directories. See CommanderDoc.tioga for an explanation of Require. 2. Configuration Requirements For packages in PCedar For every package Foo in PCedar there must exist at least all the DF files in the Sun4 slice. Inclusion of the sun4-o3 DF is now recommended. The Foo-Suite.df file must live on /PCedar/Top/. All component DF files must be referenced in the -Suite DF file using Include. Files should be placed as high (towards Foo-Source.df) in the configuration as is possible and sensible. For example, .require and .command files should not appear in CedarCommon storage. PCedar-specific DF files must live in /PCedar/Top/. They should not reference any files in DCedar directories. .command and .require files for unshared package Foo may be referenced in the Foo-Source DF file. .command and .require files for shared package Foo should be referenced in the Foo-PCR DF file. .command files must reside in the directory [PCedar]. .require files reside in the "home" directory of the package, /PCedar/Foo/. No "Exports" or "Exports Imports" clauses should appear in unshared PCedar DF files. DF files "lower" in a DF tree do not refer to (i.e. no "Imports" or "Exports Imports") their ancestors. The "gluing" is done by the -Suite DF files. Unshared DFs should not Export anything, with the understanding that current DFs can be left alone until it is convenient to remove Exports clauses. For packages in DCedar We are not free to change the rules for DF management of DCedar with regard to public/private files. A package Foo in DCedar sharing no files with PCedar is described simply by the DF file Foo.df, as before. If a DCedar package Foo shares files with PCedar the package will still be described with a DF file Foo.df in [Cedar(Chest)7.0]. That file Includes [CedarCommon]Foo-Source.df or [CedarCommon]Foo-Common.df as needed. Foo.df also contains all the unshared material for the DCedar package. The use of Foo-PrincOps.df on the DCedar side is hereby eliminated. There are only six packages using -PrincOps DFs today, so it is a minor inconvenience to change this now. Sharing Files Shared files (described in a DF of the form Foo-Source.df or Foo-Common.df) must reside in the CedarCommon storage hierarchy. This includes both the top-level DF file as well as the files referenced by it. DFs in CedarCommon will need to Export public files for users and not export files such as common sources which only maintainers need. 3. MakingDo To remain as consistent as possible with current practice, PCedar developers BringOver/SModel Foo-Suite.df and DCedar developers BringOver/SModel Foo.df and DCedar users BringOver -p Foo.df. This means that the only references are: Foo-Suite.df includes everything needed for maintenance of the PCedar variants, and Foo.df includes everything needed for maintenance and use of the DCedar variants. Note that the shared DF is included by TWO other DFs --- this is appropriate, since the shared stuff is being maintained for both worlds. Until recently, there were various aliases like makedo4 and makedo4O3 which attempted to implement the notion of slices. Once a package follows the regimen described herein, it will be possible to simply % makedo -df Foo-Suite.df -- a PCedar side makedo or % makedo -df Foo.df -- a DCedar side makedo If Foo-Suite.df includes a Foo-sun4O3.df, both optimized and unoptimized versions will be made. 4. PrefixMaps and PseudoServers As of March 6, 1990, the relevant PCedar prefix map entries for PARC were: /pseudo -vux:/pseudo /pcedar2.0 -vux:/pseudo/pcedar2.0 /pcedar -vux:/pseudo/pcedar2.0 /cedarcommon2.0 -vux:/pseudo/cedarcommon2.0 /cedarcommon -vux:/pseudo/cedarcommon2.0 /cedarchest7.0 -vux:/pseudo/cedarchest7.0 /cedar7.0 -vux:/pseudo/cedar7.0 As of March 6, 1990, the relevant DCedar pseudserver entries for PARC were: CedarCommon2.0 -r [Eich-NFS]CedarCommon2.0> [Eich-NFS]CedarCommon2.0> [Gharlane-NFS]CedarCommon2.0> PCedar2.0 -r [Eich-NFS]PCedar2.0> [Eich-NFS]PCedar2.0> [GharlDSane-NFS]PCedar2.0> YPServers [$] [13.1.100.208] Cedar7.0 -r [Eich-NFS]Cedar7.0> [Eich-NFS]Cedar7.0> [Gharlane-NFS]Cedar7.0> CedarChest7.0 -r [Eich-NFS]CedarChest7.0> [Eich-NFS]CedarChest7.0> [Gharlane-NFS]CedarChest7.0> 5. Examples -- Gargoyle-Suite.df Directory [PCedar2.0] Gargoyle-Suite.df Include [CedarCommon2.0]Gargoyle-Source.df Of ~= Include [PCedar2.0]Gargoyle-PCR.df Of ~= Include [PCedar2.0]Gargoyle-Sun4.df Of ~= Include [PCedar2.0]Gargoyle-sun4O3.df Of ~= -- Gargoyle-Source.df Directory [CedarCommon2.0] Gargoyle-Source.df Exports [CedarCommon2.0] -- common runtime files Gargoyle.tip Gargoyle.icons Directory [CedarCommon2.0] -- common documentation files GargoyleDoc.tioga Exports [CedarCommon2.0] -- common gargoyle scene files ProcessGuide-Y000.gargoyle ProcessGuide-Y010.gargoyle ... Directory [CedarCommon2.0] -- common Mesa source files GGActiveImpl.mesa GGAids.cm GGAlign.mesa GGAlignImpl.mesa ... -- Gargoyle-PCR.df Directory [PCedar2.0] Gargoyle-PCR.df Directory [PCedar2.0] Gargoyle.command GGToIP.command ... Directory [PCedar2.0] Gargoyle.require Gargoyle.config ... -- unshared, same-named source files -- you may not like same-named source files GGPortImpl.mesa -- lots of .mob and .c2c.c files follow ... -- Gargoyle.df Exports [CedarChest7.0] Gargoyle.df Include [CedarCommon2.0]Gargoyle-Source.df Of ~= Exports [CedarChest7.0] Gargoyle.install Gargoyle.load Gargoyle.bcd ... Directory [CedarChest7.0] -- unshared, like-named sources GGPortImpl.mesa Gargoyle.config ... Example 2: PreView is not Mesa source shared, but it uses the same .tip and .icons file. In addition, some sample interpress files come with the release. -- PreView-Common.df Directory [CedarCommon2.0] PreView-Common.df Exports [CedarCommon2.0] -- common runtime files PreView.tip PreView.icons Exports [CedarCommon2.0] -- common IP files NewWave.ip Stamp.ip ... -- PreView-Suite.df Directory [PCedar2.0] PreView-Suite.df Include [CedarCommon2.0]PreView-Common.df Of ~= Include [PCedar2.0]PreView-Source.df Of ~= Include [PCedar2.0]PreView-PCR.df Of ~= Include [PCedar2.0]PreView-Sun4.df Of ~= Include [PCedar2.0]PreView-sun4O3.df Of ~= -- PreView.df Exports [CedarChest7.0] PreView.df Include [CedarCommon2.0]PreView-Common.df Of ~= Exports [CedarChest7.0] PreView.install PreView.load PreViewPackage.bcd Directory [CedarChest7.0] -- unshared sources  PCedar2.0DFSuitesDoc.tioga Copyright 1990 by Xerox Corporation. All rights reserved. Eduardo Pelegri-Llopart, February 19, 1990 2:28 pm PST Ken Pier, May 4, 1990 10:40 am PDT Christian Jacobi, May 13, 1992 7:48 pm PDT This document was valid for PCedar2.0 but for Cedar10.1 a very much simpler structure for df files is used. [Artwork node; type 'Artwork on' to command tool] [Artwork node; type 'Artwork on' to command tool] [Artwork node; type 'Artwork on' to command tool] Returns [NIL, NIL] if not found; otherwise, fullFName is equal to directory.Concat[relativeFName] modulo case, except that relativeFName may have less specific version information than the corresponding part of fullFName. Returns [NIL, NIL] if not found; otherwise, fullFName is equal to directory.Concat[relativeFName] modulo case, except that relativeFName may have less specific version information than the corresponding part of fullFName. If given a relative name, returns Search[packageName, fName].fullFName; if given an absolute name, returns it. If given a relative name, returns SearchList[list, fName].fullFName; if given an absolute name, returns it. :NewlineDelimiter WordlistCedarCommon Foo PCR Mimosa DF DCedar PCedar truely decouples unshared Artwork FamousFiles MakeDo restarting restarted installer BiScrollers manipulable DFs subdirectory gargoyle icon subdirectories recompilations maintainers PrincOps tioga unoptimized aliases Mark lastEditedJ R Interpress/Xerox/3.0 fjkj=xj Gxjxeroxxc1-2-2 helvetica o)8/PCedar/Top/Foo-Suite.dfkxjxeroxxc1-2-2 helvetica V/PCedar/Top/Foo-PCR.dfkxjxeroxxc1-2-2 helvetica yV/PCedar/Top/Foo-Sun4.dfkxjxeroxxc1-2-2 helvetica qV/PCedar/Top/Foo-Sun4O3.dfk @@XeroxResearch RGBLinearxjrjsyf"̡ @@ juyW jWkkxjxeroxxc1-2-2 helvetica @@|Includeskxjxeroxxc1-2-2 helveticaWo)8/Cedar(Chest)7.0/Top/k @@xjrjJAsyf"̡ @@ juyW jWkkxjxeroxxc1-2-2 helvetica @@A|Includeskxjxeroxxc1-2-2 helveticaV/CedarCommon/Top/Foo-Common.dfkxjxeroxxc1-2-2 helvetica P/CedarCommon/Top/Foo-Common.dfkxjxeroxxc1-2-2 helvetica 9/PCedar/Top/Foo-Source.dfkkkg Interpress :0.0 mm xmin 0.0 mm ymin 189.1814 mm xmax 66.59075 mm ymax 69.41297 mm bigger topLeading 69.41297 mm bigger topIndent 1.411111 mm bigger bottomLeading 0.5 0.3 0.95 backgroundColor the topLeading 6 pt .sub backgroundAscent 3 pt backgroundDescent 4 pt outlineBoxThickness 1 pt outlineBoxBearoff Gargoyle file for scene: stuffed from Gargoyle at March 6, 1990 12:48:00 pm PST Produced by version 8906.16 Scripts: Slope: [F 150.0] [F 135.0] [F 120.0] [T 90.0] [F 60.0] [F 45.0] [F 30.0] [T 0.0] Angle: [F 90.0] [F 60.0] [F 45.0] [F 30.0] [F 0.0] [F -30.0] [F -45.0] [F -60.0] [F -90.0] Radius: [F 5.555556e-2 1/18] [F 0.1111111 1/9] [F 0.125 1/8] [F 0.25 1/4] [F 0.3333334 1/3] [F 0.5 1/2] [F 0.6666668 2/3] [F 0.75 3/4] [F 1.0 1] [F 2.0 2] [F 4.0 4] LineDistance: [F 0.0 0] [F 5.555556e-2 1/18] [F 0.1111111 1/9] [F 0.5 1/2] [F 1.0 1] Midpoints: F Heuristics: F ShowAlignments: T ScaleUnit: 72.0 DisplayStyle: print Gravity: T GravityExtent: 0.1736111 GravityType: pointsPreferred DefaultFont: xerox/xc1-2-2/helvetica [r1: 0.0 s: [12.0 12.0] r2: 0.0] 1.0 1.0 Defaults: [1 0.5] [1 1.0] 2.0 round round Dashed: F Shadows: []F Anchor: F Palette: F Entities: [12]: Text T "/PCedar/Top/Foo-Suite.df" xerox/xc1-2-2/helvetica [20.0 0.0 128.7187 0.0 20.0 508.1609][] F 1.0 props: ( F ) ls: 1.2 pList: ( ) Text T "/PCedar/Top/Foo-PCR.df" xerox/xc1-2-2/helvetica [12.0 0.0 173.5312 0.0 12.0 386.593][] F 1.0 props: ( F ) ls: 1.2 pList: ( ) Text T "/PCedar/Top/Foo-Sun4.df" xerox/xc1-2-2/helvetica [12.0 0.0 173.5312 0.0 12.0 362.593][] F 1.0 props: ( F ) ls: 1.2 pList: ( ) Text T "/PCedar/Top/Foo-Sun4O3.df" xerox/xc1-2-2/helvetica [12.0 0.0 173.5312 0.0 12.0 338.593][] F 1.0 props: ( F ) ls: 1.2 pList: ( ) Outline fillColor: [0 0.64 0.16 0.16] ow: T fillText: T 0 Children: [1] Traj (open) [4] arrows: 0 j: round e: T square w: 6.0 c: T [0 0.64 0.16 0.16] d: T F [255.2812,494.0] (Line ) [255.2812,458.0] (Line ) [248.9173,464.364] (Line ) [255.2812,458.0] (Line ) [261.6452,464.364] fwd: T pList: ( ) Text T "Includes" xerox/xc1-2-2/helvetica [20.0 0.0 269.0 0.0 20.0 476.0][0 0.64 0.16 0.16] F 1.0 props: ( F ) ls: 1.2 pList: ( ) Text T "/Cedar(Chest)7.0/Top/" xerox/xc1-2-2/helvetica [20.0 0.0 439.0 0.0 20.0 508.1609][] F 1.0 props: ( F ) ls: 1.2 pList: ( ) Outline fillColor: [0 0.64 0.16 0.16] ow: T fillText: T 0 Children: [1] Traj (open) [4] arrows: 0 j: round e: T square w: 6.0 c: T [0 0.64 0.16 0.16] d: T F [549.9276,494.0] (Line ) [549.9276,458.0] (Line ) [543.5635,464.364] (Line ) [549.9276,458.0] (Line ) [556.2915,464.364] fwd: T pList: ( ) Text T "Includes" xerox/xc1-2-2/helvetica [20.0 0.0 563.6462 0.0 20.0 476.0][0 0.64 0.16 0.16] F 1.0 props: ( F ) ls: 1.2 pList: ( ) Text T "/CedarCommon/Top/Foo-Common.df" xerox/xc1-2-2/helvetica [12.0 0.0 446.993 0.0 12.0 428.593][] F 1.0 props: ( F ) ls: 1.2 pList: ( ) Text T "/CedarCommon/Top/Foo-Common.df" xerox/xc1-2-2/helvetica [12.0 0.0 173.5312 0.0 12.0 432.0][] F 1.0 props: ( F ) ls: 1.2 pList: ( ) Text T "/PCedar/Top/Foo-Source.df" xerox/xc1-2-2/helvetica [12.0 0.0 173.5312 0.0 12.0 409.0][] F 1.0 props: ( F ) ls: 1.2 pList: ( ) 33Q QQQ  5Q7QQQQQPnh Q77QQQQ Icode ns ks !SSSS #S USSS6S &aSS  CSGGS&&S  OSDDS&&SSJQSpellingToolUserLikesThisWordCedarCommander SpellingToolUserLikesThisWordcm SpellingToolUserLikesThisWord CommanderDoc%Q1| SpellingToolUserLikesThisWord CommanderDoc%QbtxQ)2QFPQ)QpqQ2AQ-FSpellingToolUserLikesThisWordgluing7n[f QdQ KlQM) P Q- `+SpellingToolUserLikesThisWordMakingDo QM SpellingToolUserLikesThisWord BringOverSpellingToolUserLikesThisWordSModel$ SpellingToolUserLikesThisWord BringOverSpellingToolUserLikesThisWordSModel SpellingToolUserLikesThisWord BringOverf IdefaultT1TT+Q_] SpellingToolUserLikesThisWord PrefixMaps SpellingToolUserLikesThisWord PseudoServers J TT!!TT++T((T))T K T||TkkT""T``Txx T   JT  PO