Hello All.
If anyone is interested in struct, I have completed updating it
for modern day systems. Thanks to Jay Logue for invaluable help in
completing the work and to Bakul Shah for his interest and support.
See https://github.com/arnoldrobbins/struct; I have merged the
modernization work into the master branch. The README.md describes
what was done in more detail.
Doug McIlroy - if you want me to add anything to the README.md, please send
it on and I will do so, quoting you as appropriate.
Jay Logue and Bakul Shah - if you want me to add anything to the
README.md, please let me know (privately).
Thanks,
Arnold
Hi all,
Has anybody ever seen a console floppy image anywhere on the internet
labeled:
/"RX11 VAX DSK LD DEV #1"/
It is referenced in BSD 4 documentation with respect to formatting disks
(edited):
USING DEC SOFTWARE TO FORMAT
Warning: These instructions are for people with 11/780 CPU’s.
You should shut down UNIX and halt the machine to do any disk
formatting.
Formatting an RP06. Load the console floppy labeled, "RX11 VAX DSK
LD DEV #1" in the console disk drive, and type the following commands:
>>>BOOT
DIAGNOSTIC SUPERVISOR. ZZ-ESSAA-X5.0-119 23-JAN-1980 12:44:40.03
DS>ATTACH RH780 SBI RHO 8 5
DS>ATTACH RPO6 RHO DBA0
DS>SELECT DBAO
DS>LOAD EVRAC
DS>START/SEC:PACKINIT
This is for drive 0 on mbaO; use 9 instead of 8 for mbal, etc.
> I've just watched an interesting presentation given last Friday via
> video link to the Linux Conference in Australia:
> Brian Kernighan
> The early days of Unix at Bell Labs
> https://www.youtube.com/watch?v=ECCr_KFl41E
Here's an earlier incarnation of the talk:
https://www.youtube.com/watch?v=nS-0Vrmok6Y
I rather enjoyed seeing it with closed captions in Spanish and
speakers turned off. Aided by the slides, I was pretty well able to
read the Spanish, which otherwise would have been quite mysterious.
Doug
I've just watched an interesting presentation given last Friday via
video link to the Linux Conference in Australia:
Brian Kernighan
The early days of Unix at Bell Labs
https://www.youtube.com/watch?v=ECCr_KFl41E
48 minutes
While most of the talk subjects are well known to TUHS list members,
there are nice things said about various people, and about the value
of TUHS.
Other talks at the conference may be of interest as well: see the
schedule at
https://linux.conf.au/schedule/
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
Any takers for a (free) two-volume 7th Ed manual (1983), or ring-bound 8th Ed (1985), or PDP11 processor handbook (1981)? These would need to be picked up in Lindfield, Sydney, Australia. Condition is fair, but they've been in storage for 35 years so are slightly mouldy, but still perfectly usable. Images at http://jon.es/other/7th-ed.jpg and http://jon.es/other/8th-ed.jpg If you’d like them, let me know in email ASAP please.
Regards,
Terry Jones
> From: Angelo Papenhoff
> to my knowledge no troff version before the C rewrite in v7
Apologies if I missed something, but between this list and COFF there's so
much low S/N traffic I skip a lot of it. Having said that, was there ever a
troff in assembler? I'd always had the impression that the first one was in C.
> The v6 distribution has deleted directory entries for troff source but
> not the files themselves. I hope it is not lost. Maybe someone here has
> an idea where it could be found?
The MIT 'V6+' (I think it's probably basically PWB1) system had troff -
i guess it 'fell off the back of a truck', like a lot of other stuff MIT had,
such as 'typesetter C', the Portable C Compiler, etc.
Theirs was modified to produce output for a Varian (I forget which model,
maybe the docs or driver say).
nroff on that system seems to have been generated from the troff sources; the
assembler nroff sources aren't present.
I looked at its n1.c, and compared it to the V7 one:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/troff/n1.c
and this one appears to be slightly earlier; e.g. it starts:
#include "tdef.h"
#include "t.h"
#include "tw.h"
/*
troff1.c
consume options, initialization, main loop,
input routines, escape function calling
*/
extern int stdi;
and in the argument processing, it has quite a lot fewer.
So that one is a "troff version before the C rewrite in .. v7", but it is in
C. Is that of any interest?
Noel
Most of y'all are aware of Brian Kernighan's troff involvement. My
understanding is that he pretty much took over nroff/troff after Joe Ossana
died, and came out with ditroff.
But Brian had much earlier involvement with non-UNIX *roff. When he was
pursuing his PhD at Princeton, he spent a summer at MIT using CTSS and
RUNOFF. When he came back to P'ton, he wrote a ROFF for the IBM 7094,
later translated to the IBM 360. Many generations of students, myself
included, use the IBM ROFF (batch, not interactive) as a much friendlier
alternative to dumb typewriters. I don't know if 360 ROFF spread beyond
Princeton, but I wouldn't be surprised.
BTW, during my summer at Bell, nroff/troff was one of the few programs I
could not port to the Interdata 8/32 - it was just a mess of essentially
typeless code. I don't think Joe Ossana got around to it either before he
died.
--
- Tom
Hello All.
We recently discussed Brenda Baker's struct program, that read Fortran
and generated Ratfor. Many of us remarked as to what a really cool
program it was and how much we admired it, myself included.
For fun (for some definition of "fun") I decided to try to bring the code
into the present. I set up a GitHub repo with the V7, V8 and V10 code,
and then started work in a separate branch.
(https://github.com/arnoldrobbins/struct, branch "modernize".)
The program has three main parts:
- structure, which reads Fortran and outputs something that is
almost Ratfor on standard output.
- beautify, which reads the output of structure and finishes the job,
primarily making conditions readable (.not. --> !, removing double
negatives, etc.)
- struct.sh - a simple shell script that runs the above two components.
This is what the user invokes.
The code was written in 1974. As such, it is rife with "type punning"
between int, int *, int **, and char *. These produce a lot of warnings
from a modern day C compiler. The code also uses a, er, "unique" bracing
style, making it nearly illegible to my stuck-in-a-rut programming brain.
Here is what I've accomplished so far:
* Converted every function definition and declaration to use modern (ANSI)
C style, adding a header file with function declarations that is
included everywhere.
* Run all the code through the indent program, formatting it as traditional
K&R bracing style, with tabs.
* Fixed some macros to use modern style for getting parameter values as strings
into the macros.
* Fixed a few small bugs here and there.
* Fixed beautify to work with modern byacc/bison (%union) and to work with
flex instead of lex. This latter was a challenge.
In structure, only three files still generate warnings, but they all relate
to integer <--> pointer assignment / use as. However, when compiled in
32 bit mode (gcc -m32), where sizeof(int) is the same as sizeof(pointer),
despite the warnings, structure works!!
Beautify works, whether compiled in 32 or 64 bit mode.
What I've done so far has been mostly mechanical. I hereby request help from
anyone who's interested in making progress on "the hard part" --- those three
files that still generate warnings.
I think the right way to go is to replace int's with a union that holds and
int, a char* and an int*. But I have not had the quiet time to dive into
the code to see if this can be done.
Anyone who has some time to devote to this and is interested, please drop
me a note off-list.
Thanks,
Arnold Robbins
This is clearly getting off track of TUHS. I'll stop
after this reply.
> *From:* Blake McBride <blake1024(a)gmail.com>
> *Date:* January 11, 2022 at 2:48:23 PM PST
> *To:* Jon Forrest <nobozo(a)gmail.com>
> *Cc:* TUHS main list <tuhs(a)minnie.tuhs.org>
> *Subject:* *[TUHS] TeX and groff (was: roff(7))*
> Although I'm not connected with the TeX community, I don't agree with
> much of what you said.
>
> 1. TeX source to C is fine - stable and works. It would be
> impossible to rewrite TeX in any other language without introducing
> bugs and incompatibilities. Leaving TeX as-is means that it can be
> converted to other languages too if/when C goes out of style. TeX
> as-is is exactly what it is. Anything else wouldn't be TeX.
I agree that Web->C works but it's a major obstacle in doing any
development work on TeX. Try making a major change in the Web source
that requires debugging.
Anything that can pass the TeX Trip Test can be called TeX. I know of
a full C reimplementation that passes the test but the author doesn't
want to make it free software.
There are other rewrites out there that could be candidates but someone
will enough power will have to proclaim one as the official TeX
alternative.
> 2. Drop DVI? Are you kidding me? Although PDF may be popular now,
> that may not be the case 20 years from now. A device-independent
> format is what is needed, and that's what DVI is. TeX is guaranteed
> to produce the exact same output 100 years from now.
And .PDF isn't?
.DVI was great until .PDF matured. .DVI has almost no penetration
these days, whereas .PDF is everywhere. I'm not saying that .PDF
will always be the proper alternative but a properly rewritten TeX
should make it much easier to replace .PDF will whatever comes
next.
> 3. I am curious about memory limitations within TeX.
TeX has various fixed sized memory pools, and contains clever code
to work around limited memory. Some of the newer TeXs,
like LuaTeX, use dynamic allocation but this isn't official.
Given how primitive things were when TeX was developed it's a
miracle it works as well as it does.
> 4. Knuth is getting up in age. Someone will have to take over.
Exactly. I don't follow the TeX community so I don't know what
they're doing about this.
Jon Forrest