nagler%olsen@unizh.UUCP (Robert Nagler) (09/02/88)
We have an ~80 module M2 library which we are going to release to the
public domain within the next few weeks. I have several questions
which will help me get the library ready for release. Please respond
to me directly (I will acknowledge receipt). If you would like to
know a bit about the library before answering these questions, I have
included a short description at the end of this note.
1. Is anyone interested in the library? Are you interested in being
a beta test site?
2. How would you like the library distributed? Source only?
Separate binary and source distributions? All the modules
in one directory? We have an added complication that the
library must be preprocessed before it is compiled. This doubles
the number of sources files. (You need to keep both copies around
if you want to debug the library.) Do you want our test programs?
3. We have quite an extensive manual. The text formatter we use
is Latex. Will this be a problem? (Note: the definition modules
are well commented so the need for a manual is not as great as
with other libraries.)
Thanx for any responses,
Rob Nagler
olsen!nagler@uunet.uu.net
Olsen & Associates
Seefeldstrasse 233
CH-8008 Zuerich
----------------------------------------------------------------
The following is a list of the general module groupings.
o Binary (direct) I/O o Text I/O
o List Managment o String Conversions and Manipulations
o High-level Memory Mgmt o Debugging Facilities
o Debugging Facilities o Light-weight processes
o Screen (Terminal) I/O o M2 Preprocessor (statement control only)
o Portable Types & Consts o Directory Facilities
o Random Numbers o I/O Name Space Manips
o Memory Ops o Formatted I/O (a la Fortran & C)
o Configuration Files o Centralized Error Handling Facilities
o Program Arguments & Environment
o Compiler ``Extensions'' such as 32 bit cardinals for the PC
The library currently runs with Logitech/86 2.0 & 3.0 on IBM-PCs/DOS 2.X & 3.X
and Sun M2 2.0 on Sun-3s/OS 3.X. It will probably port to Sun 4.0
fairly as well as Sun-2s and Sun-4s. We expect that the library will
port to other systems (VAX, Mac, Atari, etc.) fairly easily. If you
have a TOPS-20 machine the confusion between BYTE and WORD might make
things messy, but we have even tried to take these dinosaurs into account.
Applications which are written with the library as the sole operating
system interface will most certainly port to any system to which the
library can be ported.
If you are writing larger scale applications, you may find the library
quite useful. If you want to write the ``cat'' or ``type'' program,
it's easy but may be a little bulky compared with the versions supplied
with the operating system. We use it in our distributed information
system and for many tools such as a M2 Dependency Generator, a
M2 Preprocessor, and a Bitmap Editor.
The name of this library might be YAML and if you feel that way, so be it.
However, we are distributing it to help people in any way possible.
You may use a part or the whole thing. The I/O modules are layered
and integrated (yes, even ScreenIO), but there are many other standalone
modules such as ProgArgs, ProgEnviron, NameLists, Objects, etc. which
are not provided by any proposals know to me. If nothing else, the
library can serve as an alternative approach to programming in M2.peterson@mips.csc.ti.COM (Bob Peterson) (09/06/88)
In article <8809021249.AA04797@klaus.olsen.uucp> you write: >We have an ~80 module M2 library which we are going to release to the >public domain within the next few weeks. I have several questions >which will help me get the library ready for release. Please respond >to me directly (I will acknowledge receipt). If you would like to >know a bit about the library before answering these questions, I have >included a short description at the end of this note. > > 1. Is anyone interested in the library? Are you interested in being > a beta test site? Yes, there is interest in the library, but I'm not in a good position to be a beta test site. > 2. How would you like the library distributed? Source only? > Separate binary and source distributions? All the modules > in one directory? We have an added complication that the > library must be preprocessed before it is compiled. This doubles > the number of sources files. (You need to keep both copies around > if you want to debug the library.) Do you want our test programs? Source only is preferable, in my opinion. How the files are organized isn't that important, since I'll probably rearrange them anyway. I gather there is a problem with supplying the preprocessor? Otherwise you wouldn't need to provide the preprocessed version of the source? Yes, I most certainly want the test programs! Not only can they be used to ensure correct transmission, but to do regression testing when I make changes. Also, when recompiling or porting the code, your tests can help find any problems. > 3. We have quite an extensive manual. The text formatter we use > is Latex. Will this be a problem? (Note: the definition modules > are well commented so the need for a manual is not as great as > with other libraries.) LaTeX is not a problem for me, and I even have a way of producing ASCII from the .dvi output file. The latter is useful for those sites without LaTeX, e.g., personal computer users. >Thanx for any responses, >Rob Nagler >olsen!nagler@uunet.uu.net >Olsen & Associates >Seefeldstrasse 23 THANK YOU!! -- Hardcopy and Electronic Addresses: Office: Bob Peterson Compuserve: 70235,326 NB 2nd Floor CSC Aisle C3 P.O. Box 861686 Usenet: peterson@csc.ti.com Plano, Tx USA 75086 (214) 995-6080 (work) or (214) 596-3720 (ans. machine)