Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!tektronix!tekecs!orca!brucec
From: bru...@orca.UUCP (Bruce Cohen)
Newsgroups: net.sources
Subject: RE: Window documentation from umcp-cs!chris
Message-ID: <1378@orca.UUCP>
Date: Fri, 8-Jul-83 15:01:30 EDT
Article-I.D.: orca.1378
Posted: Fri Jul 8 15:01:30 1983
Date-Received: Sat, 9-Jul-83 13:15:39 EDT
Lines: 33
I just tried to rebuild the window documentation sent out in
net.sources so it would be readable. After about ten passes of
editing the nroff source, I got the first few pages to come out nearly
right (no page breaks, and the figures were still screwed up, but what
the hey), so I sent it to the printer. The result was almost 200
pages of listing, most of it blank or with a narrow ribbon of text
down the right side. I also got a mild chewing out (justified, too)
by one of our operators for sending something to the printer without
knowing what it would do. I thought I'd inform the news community of
the problem, and pass the second result back. So ...
< KINDLE >
For God's sake (and everyone else's too) don't send out
documentation without making sure that it can be rebuilt
properly! The same goes for sources for that matter. If
there is some esoteric macro package that should be used, let
us know! There was at least one command in there unknown to
standard nroff, but -me and -man didn't work either. Is there
a reason why -ms or -man can't be used for documentation at
all times? Those figure macros were cute, but they didn't
work, so what good are they? Have a thought for the people
who receive what you send on the net, and remember that they
don't necessarily all use the tools you have or know what
your methods are.
< EXTINGUISH >
Bruce Cohen
UUCP: ...!teklabs!tekecs!brucec
CSNET: tekecs!brucec@tektronix
ARPA: tekecs!brucec.tektronix@rand-relay
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site burl.UUCP
Path: utzoo!linus!philabs!cmcl2!floyd!whuxlb!pyuxll!eisx!npoiv!npois!hogpc!houxm!hocda!spanky!burl!rcj
From: r...@burl.UUCP
Newsgroups: net.sources
Subject: Re: RE: Window documentation from umcp-cs!chris
Message-ID: <226@burl.UUCP>
Date: Sat, 9-Jul-83 18:37:14 EDT
Article-I.D.: burl.226
Posted: Sat Jul 9 18:37:14 1983
Date-Received: Sun, 10-Jul-83 23:55:31 EDT
References: <1378@orca.UUCP>
Organization: Western Electric, Burlington, NC
Lines: 41
I haven't yet tried to generate chris' window documentation, but
I do want to say two things about the flame against sending non-
working stuff out on the net.
a) I agree with the stand taken -- unusable software and documentation
waste my time for no reason.
b) The flamer in question asked everyone to remember that not everyone
has all the tools that you do, and then asks why -ms or -man cannot
be used for all documentation. A worthy question, but he obviously
does not know that USG Unix does not have the -ms package. I do not
wish to flame the flamer, but merely to suggest something to the
net community at large:
~= /* flame on!! */
USG Unix exists!! There is something besides Berkeley Unix!!!
I fully realize that you cannot please everyone all the time, but
if you must send out software or documentation that runs on Berkeley,
at least say that it comes from a Berkeley system so that USG people
will be forewarned. Try to find a couple of reliable people who
are running USG, and send them a copy for conversion to USG, then
post that copy/those fixes to the net. USG does not have dup2(),
multiplexed pipes, ^Z suspension of processes, shell aliases,
or the ability to check whether or not all output has actually made
it to the terminal or not; to name but a few.
So how about it -- if you are going to send out something that runs
on BSD x.x, at the LEAST note that fact somewhere. I will be more
than happy to give anyone my fixes that allow it to run on USG 5.0,
if I can make the time. The shoe fits the other foot as well --
USG people should note the USGness of a piece of software and/or
documentation as well -- I have been guilty of not doing so myself.
If you try not to send out software using multiplexed pipes and
process suspension, then I'll try not to send out software using
semaphores, messages, and shared memory;
--
The MAD Programmer -- 919-228-3814 (Cornet 291)
alias: Curtis Jackson ...![ floyd sb1 mhuxv ]!burl!rcj
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP
Path: utzoo!linus!philabs!seismo!rlgvax!cvl!umcp-cs!chris
From: ch...@umcp-cs.UUCP
Newsgroups: net.sources
Subject: Re: Window documentation
Message-ID: <676@umcp-cs.UUCP>
Date: Sat, 9-Jul-83 21:55:15 EDT
Article-I.D.: umcp-cs.676
Posted: Sat Jul 9 21:55:15 1983
Date-Received: Sun, 10-Jul-83 04:54:35 EDT
References: <1378@orca.UUCP>
Organization: Univ. of Maryland, Computer Science Dept.
Lines: 17
Hmm, that's funny, it worked for me... let me try it again: "nroff
-me windows.nr". Works like a champ. Must be your nroff. (Or are you
by any chance using troff? I've heard that it doesn't work with troff.
We don't have a typesetter [yes I know CVL has one]; makes it hard for
me to test that.)
As for which macros to use, sorry about that, folks; I never use
anything but -me so I never realized that other people wouldn't know
which macros to use.
Can anyone explain the behaviour of his nroff?
- Chris
--
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs
ARPA: chris.umcp-cs@UDel-Relay
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site watcgl.UUCP
Path: utzoo!watmath!watcgl!rhcole
From: rhc...@watcgl.UUCP (Richard H Cole)
Newsgroups: net.sources
Subject: Re: more window documentation.
Message-ID: <574@watcgl.UUCP>
Date: Sun, 10-Jul-83 22:39:24 EDT
Article-I.D.: watcgl.574
Posted: Sun Jul 10 22:39:24 1983
Date-Received: Tue, 12-Jul-83 02:21:32 EDT
References: <1378@orca.UUCP>
Organization: U of Waterloo, Ontario
Lines: 17
** small flame **
Ah come on its not that hard to figure out that if the documentaion does
not have ms macros in it that it is probably using the me macros.
I had no problems with either the source or the documentaion. Hanoi
ran right off with no problems.
Admittedly it is a good idea to state what macros if any are being used
or what libraries need to be loaded with hanoi, but I wish all the
source that has come over the net was as well organized or as easy to
get going. I'm still working on the curses update and the program
to program the keys on the ann arbor ambasidors/genie's was down
right wrong, it did not agree with the documetation..............
Oh well enough of that.
Keep that source comming.
Thanks,
richard h cole , rhcole@watcgl