DFSuitesDiscussion.mail 26-Feb-90 To: PCedarImplementors^ Disussion: DF Suites for Cedar Date: 26 Feb 90 16:10:16 PST Sender: Kenneth A Pier:PARC:Xerox Subject: Disussion: DF Suites for Cedar To: PCedarImplementors^:PARC:Xerox Cc: Kenneth A Pier:PARC:Xerox Reply-To: Kenneth A Pier:PARC:Xerox I am attempting to integrate and document the agreed upon CedarCommon conventions with DF file conventions. I would like to resolve the following questions via this discussion. I will pose questions below; I will also propose answers if I have an opinion, which I will document unless dissent develops. Question 5 needs the most attention. The draft of the document may be found on /net/chroma/chroma/pier/temp/DFSuitesDoc.tioga. 1. Should -Suite DFs include -Sun4O3 DFs? Answer: Yes. O3 optimization is going to be around for a while. Most users want to run optimized code on a day to day basis. Package maintainers should be encouraged to keep all versions in step. 2. What DF files should be on the DCedar side now that sharing has moved into CedarCommon? Answer: A package Foo in Cedar or CedarChest sharing no files with PCedar is described simply by the DF file Foo.df, as before. If a Cedar or CedarChest package Foo shares files with PCedar, the package must be described with a DF file Foo.df in Cedar or CedarChest that Includes [PCedar2.0]Foo-Source.df and [Cedar(Chest)7.0]Foo-PrincOps.df. [Cedar(Chest)7.0]Foo-PrincOps.df then contains all the unshared material for the DCedar package. 3. Where do .install, .load, .require, and .command files appear in the DF hierarchy? Answer: .install, .load files appear in Foo-PrincOps.df for shared packages and in Foo.df for unshared packages. .require, and .command files always appear in Foo-PCR.df. 4. What is the proper use of EXPORTS, EXPORTS IMPORTS, and INCLUDE clauses in DF files for UNSHARED packages? Answer: nothing has changed on the DCedar side for unshared packages. For unshared packages on the PCedar side, no "Exports" or "Exports Imports" clauses should appear in PCedar-only packages. DF files "lower" in a DF tree do not refer (i.e. no "Imports", or "Exports Imports") to its ancestors. The "gluing" is done by the MakeDo commands. 5. What is the proper use of EXPORTS, EXPORTS IMPORTS, and INCLUDE clauses in DF files for SHARED packages? Answer: I don't have an answer. There was discussion sometime back about INCLUDE vs. EXPORTS IMPORTS which I would like repeated for this discussion. What are the issues? Can we simplify and still get the right functionality? Are there issues involving SSU or outbound clients we need to consider? Remember that DCedar will want to have common files EXPORTED by CedarCommon DFs for public bringovers in the DCedar world. 26-Feb-90 Tim Diebert Re: Disussion: DF Suites for Cedar Date: Mon, 26 Feb 90 16:31:31 PST In-reply-to: "Your message of 26 Feb 90 16:10:16 PST" Sender: Tim Diebert:PARC:xerox Subject: Re: Disussion: DF Suites for Cedar To: Kenneth A Pier:PARC:Xerox Cc: Tim Diebert:PARC:xerox, PCedarImplementors^:PARC:Xerox, Shibata:HARC:Fuji Xerox Reply-To: Tim Diebert:PARC:xerox Ken, I think that one of the major points to have CedarCommon in the first place is missed by your comments. In point 2 you reference "[PCedar2.0]Foo-Source.df" as the repository for the sources of package Foo. If a Cedar(Chest)7.0 package must access PCedar2.0, the entire purpose of CedarCommon is lost. When I proposed a SharedSources directory to Willie Sue, I was in Japan lamenting the fact that [PCedar2.0]Gargoyle-Suite.df referenced CedarChest7.0 for load and install files (and sources). These files were unavailable in Japan due to a very old copy of CedarChest7.0 on Magenta:PARC:Xerox because CedarChest would not all fit on an XNS server. By putting the sources on yet another directory, it becomes easier to distribute software to our remote sites, since you either make a copy of PCedar and CedarCommon or Cedar, CedarChest and CedarCommon. Not PCedar, Cedar, CedarChest and CedarCommon. I think that the simple rule needs to be: If I share any files between PCedar and Cedar(Chest) I will store those files in CedarCommon and I will use the appropriate INCLUDES in my DFs. If we don't use CedarCommon as a way to remove the interdependencies of PCedar upon Cedar(Chest) and Cedar(Chest) upon PCedar, why use CedarCommon at all? Tim 27-Feb-90 To: Tim Diebert Re: Disussion: DF Suites for Cedar Date: 27 Feb 90 10:59:05 PST In-reply-to: "Your message of Mon, 26 Feb 90 16:31:31 PST" Sender: Kenneth A Pier:PARC:Xerox Subject: Re: Disussion: DF Suites for Cedar To: Tim Diebert:PARC:xerox Cc: Kenneth A Pier:PARC:Xerox Tim- You discovered a bug/typo. Your conception is absolutely correct and was intended. Thanks for reading carefully. Ken 27-Feb-90 To: PCedarImplementors^ IMPORTANT CORRECTION to Disussion: DF Suites for Cedar Date: 27 Feb 90 11:03:46 PST Sender: Kenneth A Pier:PARC:Xerox Subject: IMPORTANT CORRECTION to Disussion: DF Suites for Cedar To: PCedarImplementors^:PARC:Xerox Cc: Kenneth A Pier:PARC:Xerox Reply-To: Kenneth A Pier:PARC:Xerox Point 2 should read: 2. What DF files should be on the DCedar side now that sharing has moved into CedarCommon? Answer: A package Foo in Cedar or CedarChest sharing no files with PCedar is described simply by the DF file Foo.df, as before. If a Cedar or CedarChest package Foo shares files with PCedar, the package must be described with a DF file Foo.df in Cedar or CedarChest that Includes [CedarCommon2.0]Foo-Source.df and [Cedar(Chest)7.0]Foo-PrincOps.df. [Cedar(Chest)7.0]Foo-PrincOps.df then contains all the unshared material for the DCedar package. Thanks to tim Diebert for noticing. The intent is that no DCedar DF files reference PCedar directly and that no PCedar DF files reference DCedar directly. Sharing occurs strictly via CedarCommon. 27-Feb-90 Mike Spereitzer Re: Disussion: DF Suites for Cedar Date: 27 Feb 90 11:31:29 PST Sender: Kenneth A Pier:PARC:Xerox Sender: Mike Spereitzer:PARC:Xerox Subject: Re: Disussion: DF Suites for Cedar To: PCedarImplementors^:PARC:Xerox Reply-To: PCedarImplementors^:PARC:Xerox I hope you are keeping in mind the fact that some of us have plans for another revision of practice at some later time (perhaps for PCedar3.0). With regards to your attempt to clarify and document current practice: 1. I agree. 2. I assume your use of [PCedar2.0] in this paragraph is a typo, and that you really meant [CedarCommon2.0]. Further, I thought we agreed earlier that we might not always want to use "-Source" for the common part, but sometimes prefer "-Common"; certainly we don't want to require that a shared package share ALL the sources. I dislike the requirements here. It looks like some unnecessary make-work for maintainers of shared packages. In particular, I see no advantage to having both Foo.df and Foo-PrincOps.df. Current practice for me and several others is to have all the DCedar stuff in Foo.df. It looks like, in your proposal, Foo.df is analogous to Foo-Suite.df and Foo-PrincOps.df is analogous to Foo-PCR.df and Foo-Sun4(O3).df. As I've pointed out earlier, I think the -Suite DFs should be abolished from PCedar; let's not introduce them into DCedar! As far as I know, there have been at least two uses of the -PrincOps suffix. The one that I think is most reasonable is not the one you propose. The one I think is most reasonable is this: [PCedar2.0]Foo-PrincOps.df describes a debugging version of a package that has been compiled in DCedar from PCedar sources; the idea is that you can run this package in DCedar and debug your PCedar source. This was (is?) most common for clients of (clients of (clients of ...)) Viewers. I'm not sure whether Cirio is good enough to obviate this use. You might try asking if anybody has any interest in keeping this option available. 3. It would be good to enunciate the general principle, which is that files go as "high" (that is, toward DFs with more uses) as they make sense. This principle says that the .require and .command files appear in the highest DF that's used only for PCedar; if you were to adopt my suggestion for (2), this principle would say that the .load and .install files go in Foo.df. 4. The most important gluing --- making sure consistent stuff is transferred by BringOver and SModel --- is done by the -Suite DFs. In fact, people willing to compile both optimized and unoptimized files at the same time can just point MakeDo at the -Suite and forget about special crocky commands. 5. There are a couple of issues here. One is, how to determine which files of a DF should be public and which should be private. The principle for CedarChest remains: export what a user needs to run the package (not what any maintainer needs to compile). I don't remember ever hearing a principle for Cedar packages, since there's another mechanism for constructing bootfiles. I think the public/private bit is not important for PCedar because of the way the Commander works (users don't bind to a package with BringOver); we could recommend that everything be private, just to establish order (I wouldn't suggest REQUIRING that, however, because that's asking people to do unimportant work). While we are free to make up rules for PCedar, I don't think we're free to make up rules for CedarChest or Cedar --- SO WE MUST CONTINUE FOLLOWING THE ESTABLISHED RULES (wrt public/private) FOR CEDARCHEST (and Cedar, if any). The other issue is how to glue things together. I suggest that to remain as consistent as possible with current practice, PCedar maintainers BringOver/SModel Foo-Suite.df and DCedar maintainers 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 maintainance of the PCedar variants, and Foo.df INCLUDEs everything needed for maintainance and use of the DCedar variants. Note that the shared DF is INCLUDEd by TWO other DFs --- I think this is appropriate, since the shared stuff is being maintained for both worlds. I think that, since the only PCedar variants now being maintained are the -Sun4 and -Sun4O3 ones, the above principle says that Foo-Suite.df INCLUDEs Foo-Source, Foo-PCR, Foo-Sun4, and Foo-Sun4O3 in the common case (where most of the sources are shared in [CedarCommon2.0]Foo-Source). I think the above principle also says that Foo.DF INCLUDEs [CedarCommon2.0]Foo-Source.df. It is my hope that some day we can abolish the use of -Suites, and have every DF reference its parent by INCLUDE. Otherwise, with N variants of a package, we need 2N DFs: for each variant, one (like Foo-Sun4) to contain variant-specific stuff and another (like Foo-Suite) to INCLUDE everything else you need. 6. We should coin some new terminology (Eduardo tried this earlier, and I liked his suggestions; unfortunately, not only were his suggestions ignored, but conflicting practice was adopted). When we have [CedarChest7.0]Foo.df and [PCedar2.0]Foo-Sun4.df and [PCedar2.0]Foo-Sun4O3.df, we need: A. A way to refer to the whole collection of DFs, or (interchangeably?) what's described by all those DFs. I like "package Foo". B. A way to refer to, for example, the -Sun4 variant. I like "the -Sun4 variant". I dislike trying use "version" here ('cause it's used so many other, different, places). C. A variant is a program and assorted other files. They are controlled by a set of DFs: Foo-Source, Foo-PCR, and Foo-Sun4; one of these (Foo-Sun4) is most specific to this variant. We need a way to refer to the set of DFs and a different way to refer to the most specific DF. I like "the -Sun4 DF path" and "the -Sun4.df". I think Eduardo suggested "the Sun4 slice" for the set of DFs and/or the variant. Mike 27-Feb-90 Kenneth A Pier Re: Disussion: DF Suites for Cedar Date: 27 Feb 90 12:22:56 PST Sender: Kenneth A Pier:PARC:Xerox Subject: Re: Disussion: DF Suites for Cedar To: PCedarImplementors^:PARC:Xerox Reply-To: PCedarImplementors^:PARC:Xerox In reply to Mike Spreitzer's message which I forwarded this morning: 1. Good. 2. Correct. Use of [PCedar2.0] in this paragraph is a typo; I really meant [CedarCommon2.0]. I agree to the simpler use of Foo.df for everything in DCedar. We have only six instances of Foo-Princops.df in /PCedar2.0/top/ today, so it would be painless to change now. So revised point 2 reads: A package Foo in Cedar or CedarChest is described simply by the DF file Foo.df, as before. If a Cedar or CedarChest package Foo shares files with PCedar, the sharing must use CedarCommon. The DCedar package must be described with a DF file Foo.df in Cedar or CedarChest that Includes [CedarCommon2.0]Foo-Source.df and/or [CedarCommon2.0]Foo-Common.df as needed. [Cedar(Chest)7.0]Foo.df contains all the unshared material for the DCedar package. 3. I agree. 4. So the correct way to Make a package is then MakeDo -df Foo-Suite.df on the PCedar side and MakeDo -df Foo.df on the DCedar side. 5. DFs in CedarCommon will need to EXPORT public files for users and not export files such as common sources which only maintainers need. Unshared DFs in PCedar can be private, with the understanding that current DFs can be left alone until it is convenient to remove EXPORT clauses. I like "the Sun4 slice" for the set of DFs and/or the variant because it is already documented that way. "Package Foo" to refer to the whole collection of DFs, or (interchangeably?) what's described by all those DFs is OK with me. 28-Feb-90 To: PCedarImplementors^ Re: Disussion: DF Suites for Cedar Date: 28 Feb 90 17:40:11 PST Sender: Kenneth A Pier:PARC:Xerox Subject: Re: Disussion: DF Suites for Cedar To: PCedarImplementors^:PARC:Xerox Cc: Kenneth A Pier:PARC:Xerox Reply-To: PCedarImplementors^:PARC:Xerox Well, a simple conversation about FamousFiles and where they live resulted in wonderful speculation on the right way to do packaged worlds, pseudocheckpoints, DF software, and international peace. However, I need something to document tomorrow, so I am going to KISS for now. Shared Famous Files will live in /CedarCommon/FamousFiles/. Unshared Famous Files will live in /PCedar/FamousFiles/. The search rules that the TIP and Icon software will follow are mostly unchanged from the current situation; they will be: 1. the working directory, 2. /PCedar/FamousFiles/, 3. /CedarCommon/FamousFiles/, 4. /r/. Yes, you can get stale files in the working directory. Don't do that. After all, it shouldn't happen if you are following the development rules. Another suggestion, that InstantiateNewTIPTable and NewIconsFromFile take another parameter, the Package name, would require interface changes and many recompilations, which we are choosing to avoid. Maybe for PCedar 3.0. 1-Mar-90 Jules Bloomenthal DFSuitesDoc Date: 01 Mar 90 11:48:18 PST Sender: Jules Bloomenthal:PARC:xerox Subject: DFSuitesDoc To: Pier:PARC:Xerox Reply-To: bloomenthal:PARC:Xerox Ken, Should this the document mention something about the necessary pseudo-server; for CedarCommon2.0? At the moment I can't read anything from /CedarCommon2.0, and I don't know sits associated server. Jules Ê–"Mail" style™J˜ sentHeader˜AIdefault˜ç—receivedHeader˜9L˜—˜=L˜Ý—˜YL˜‹—˜=L˜.—˜