---------------------------------------------------------------------- $Source: /usr/local/src/gum/RCS/FAQ,v $ $Revision: 1.0 $ $Date: 1995/06/12 21:34:33 $ ---------------------------------------------------------------------- GUM FAQ - Generic Universal M Frequently Asked Questions ---------------------------------------------------------------------- This file is part of the GUM - Generic Universal M project. Copyright (c) 1995 The Regents of the University of California. All rights reserved. A. GUM Source Code and Its Management 1. How are the sources to GUM managed? A suite of scripts (in bin/) are used to manage an RCS archive. 2. How are the releases numbered? Releases are numbered by the form .[.]. Where: - The monotonically, increasing by one, version of the source code tree. The initial version is 0 (zero). When the is incremented, then the and are both reset to 0 (zero). Further all prior "inactive" elements (files, scripts, etc) are removed from the source tree. That is, we get to "start over" with a clean archive. - A release of GUM is the monotonically, increasing by one, value that is incremented for each "public" release of GUM. This number is the "major" revision number of the RCS source tree archive. - This number is the "minor" revision number of the RCS archive at the time that the interim release is created. It is intended that the for all "official" releases is always 0 (zero). This leaves the available to local source code management by other team members. Every "public release" of GUM is, by definition, 0 (zero). 3. What is the current version? At this point, version 0 is being created. The first fully functional implementation of GUM will receive "version 1". Just exactly what constitutes "fully functional" is not currently stipulated, but full conformance to ANSI X.11 (1995+) is a "minimal requirement". 4. Who maintains the source? The 'master' GUM archive is maintained by landis@tiger.cs.ucdavis.edu. 5. Are all elements (files, scripts, etc) released each time? Generally, the 'master' archive is not released, rather only the current "active" elements (see bin/mkRCSdist) are in a release. At this point, there is no plan for 'partial' releases. However, "patch" files are created for each release to allow upgrading an existing source tree. In general, only the previous and current "full archive" (in several formats: .tgz=tar/gzip, .cpio=cpio and .zip=pkzip) is at the URL ftp://tiger.cs.ucdavis.edu/pub/gum site. 6. Are all of the files in a release at the same revision? Yes. Regardless of whether or not there were changes to a file, each "active" file is "checkpointed" at .0 in the source tree. 7. How do I know that I have all of the files for a release? All releases (except .ZIP, which are expecting all files to conform to the FILENAME.EXT or 8.3-format) each directory contains a file named ".files" which contains the names of all active "regular" files in that directory. If a directory has subdirectories, then a file named ".dirs" contains the name of each active subdirectory in that directory. This process is recursive, thereby containing all active files. 8. Why doesn't the "other" directory have ".dirs" or ".files"? The contents of the "other" directory do not directly participate in the GUM source tree. Items in "other" are other "public" source code, that frequently already exists on many systems. When it is discovered that GUM uses some "public" technology, which has proven to not be widely installed, then the most recent known version of that "public" software is distributed in the "other" directory for your convenience. Getting the code in "other" to work is, usually, left as an exercise (for you). An exception to this is if GUM directly creates part of its source tree from one of these sources (e.g. it is expected that the IIOP - Internet InterOrb Protocol from omg.org will be one of these technologies). In a case like this, a script applies a set of GUM maintained patches, creating a GUM-ified source, thereby integrating that source. Only "freely redistributable" code is *ever* considered for use as part of GUM. B. GUM General Questions 1. What is GUM? GUM is a freely available implementation of the ANSI-X.11 programming language/environment M (aka ISO-11756). 2. Who is working on GUM? This code is derived from software contributed to UC Davis by a research team under the leadership of Dick Walters (Professor, Dept of Computer Science, University of California, Davis). 3. What Internet forums exist (news, mail list, WWW and ftp sites)? We are just starting. Expect this answer to change soon. If you have an interest in providing either the material or some resources at your site, please contact Dick Walters. There are two Usenet News groups dealing with M. These are: comp.std.mumps and comp.lang.mumps. GUM hasn't been around long enough for much discussion about it yet. This too may soon change (Come on you swarthy M volunteer programmers! or ex-M/MIIS programmers that have been hacking C and are just really missing that wonderful "sparse array" "global", and want to help make it happen). 4. How do I get involved? Contact Dick Walters (at walters@tiger.cs.ucdavis.edu). You can get the code from the URL stated elsewhere in this document, so check out the progress periodically until things are far enough along that you feel comfortable in getting involved. If you are an M programmer, please consider contributing M-code utilities. GUM's ability to run M programs is not immediate, but we don't have to wait for that to begin creating the GUM utility library. (Consider how long GNU had editors, compilers, link editors, and POSIX conformant utilities before Linux came along. The GNU/Hurd is still likely a few years away). In short, please get involved. If not directly by contacting Dick, then do it by picking up GUM and check on the progress. (The file URL ftp://tiger.cs.ucdavis.edu/pub/gum/README is updated with current information and next steps each public revision). Since GUM is currently "at the beginning" it is not for everyone. It may not be for you, yet. Regardless, please consider keeping a WWW bookmark set for the README and take a look at it periodically! 5. What needs to be done? At this point, almost everything. If you were or are an M programmer and you want to contribute, there is a strong need for the normal suite of tools one normally finds in an M environment. Please consider contributing a utility or two or three. Make it "insanely great". One of the long term goals is to enable the GUM utilities to become part of what every commercial vendor supplies, which would aid in "normalizing" the M environment (i.e. no more trying to remember "Is it %GO, %go, or %GTO today?"). Start today! if you are running a commercial version of M, write a great utility and put it in GUM. If you don't have access to other implementations of M, someone else may, and they may make their contribution by identifying the changes needed to your utility to make it work on that environment. 6. What do I get for contributing code to the GUM project? Your contribution of code (whether original work, or modifications to an existing work) is acknowledged in the code. You are identified by name, unless you request to not be so acknowledged. 7. What happens to my ownership rights when I contribute my code? When you contribute code to GUM, it comes under the license (see the file License.UCD) issued by the Regents of the University of California. In contributing your code to GUM, you are giving up your rights to restrict the redistribution of your code, to be used for any purpose (to include, but not limited to: educational, commercial, non-profit, for-profit, defense, health care), by anyone (to include, but not limited to: individuals, universities, colleges, schools, businesses, domestic and foreign governments). As such, the GUM project *DOES NOT* accept any code with any such restrictions. 8. What if my contribution includes some other "public" code? If you are supplying "public" code which you received from other sources, you are free to do so, HOWEVER, before that code can become part of the official distribution, the GUM team MUST secure the rights to redistribute it. All copyrighted code must be supplied in its original form (no copyrights or source code changes other than by the author). 9. So how do I integrate "my changes" into "public" code? If, in order to use the "public" code, you had to make changes to the code, then the original source and a "patch" (used by the patch(1) utility) which renders your version of the code is to be supplied. In this case, the original source is redistributed under the "other" subdirectory, and your contributed "patch" file is redistributed in the source tree where appropriate. C. GUM Contrasted to Other M Implementations 1. How does GUM compare to other implementations? Today, it does not. D. GUM Interpreter E. GUM Global Managers and Handlers F. GUM End User Device (Terminal) Support G. GUM Configurations H. GUM Library Routines/Globals I. GUM SSVNs # # End of $Source: /usr/local/src/gum/RCS/FAQ,v $ ###