Doug McIlroy kindly sent me contact information for John Chambers,
co-author of the cited book about the S system. I have just heard
back from John, who offered a link to his summary paper from the
2020 HOPL conference proceedings
S, R, and data science
https://doi.org/10.1145/3386334
and reported that S was licensed to AT&T Unix customers only in binary
form, and that the original source code may no longer exist.
That is a definitive answer, even if not the one that I was hoping to
find.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah -
- 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/ -
-------------------------------------------------------------------------------
Eloquently put. Amen!
doug
> Unix brought automation to the forefront of possibilities. Using Unix,
> anyone could do it - even that kid in Jurassic Park. Today, everything
> is GUI and nothing can be automated easily or, most of the time,
> not at all.
> Unix is an ever shrinking oasis in a desert of non-automation and
complexity.
> It is the loss of automation possibilities that frustrates me the most
Hi folks,
Reiser and London's paper documenting their preparation of UNIX/32V, a
port of Seventh Edition Unix to the VAX-11/780, is an important
milestone in Unix development--as much I think for its frank critique of
C as "portable assembly" as for the status of the system documented: the
last common ancestor of the BSD and System V branches of development.
Because the only version I've ever seen of this paper is a scan of,
possibly, a photocopy several generations removed from the original, I
thought I'd throw an OCR tool at it and see about reconstructing it, not
just for posterity but to put the groff implementation of mm to the
test. So even if someone has a beautiful scan of this document
elsewhere, this exercise remains worthwhile to me for what it has
shown me about Documenter's Workbench mm and groff's mostly compatible
reimplementation thereof.
Please find attached my first draft of the reconstruction as an mm
document as well as a PDF rendered by bleeding edge groff.
I did not attempt to fix _any_ typos, solecisms, or non-idiomatic *roff
usage (like the employment of hyphens as arithmetic signs or operators)
in this document. I may have introduced errors, however, due to human
fallibility or incorrect inferences about what lay beneath scanning
artifacts. Hence its draft status. I welcome review.
Assuming this reconstruction survives peer scrutiny, I aim to put it up
on GitHub as I did Kernighan & Cherry's "Typesetting Mathematics"
paper.[1]
For the casual reader, I extract my documentary annotations below.
For groff list subscribers, I will add, because people are accustomed to
me venturing radical suggestions for reforms of macro packages, I
suggest that we can get rid of groff mm's "MOVE" and "PGFORM"
extensions. They're buggy (as the man page has long conceded), and I
don't think anyone ever mastered them, not even their author. I rewrote
"0.MT", essential to rendering of this document, without requiring them
at all. I _tried_ to use them, but "MOVE" in particular introduced
baffling errors in vertical spacing. When I threw it aside to attack
head-on the layout problems facing me, things got easier. Further,
simple caching and restoration of `.i` and `.l` register values (when
multiple changes were being made to them within a macro) obviated
`PGFORM`. I'm not sure that it is tractable to idiot-proof
manipulations of basic layout parameters like these, as these macros
seem to have tried to do. If a document author wants to seize control
of page layout from a full-service macro package and reach deep into the
guts of the formatter, they should glove up and put things back where
they found them. My opinion.
.\" London & Reiser's UNIX/32V porting paper
.\"
.\" Reconstruction in groff mm (but DWB 3.3 mm compatible)
.\" from scanned/OCRed text by G. Branden Robinson, June 2024
.\"
.\" The original scan shows no evidence of superscript usage, except on
.\" the cover sheet where "TM" superscripts "UNIX".
.\"
.\" Some differences may arise due to changes in the mm macro package
.\" itself from its PWB incarnation (ca. 1978) and DWB 3.3 (July 1992).
.\" Thanks to Dan Plassche for the history.
.\" https://www.tuhs.org/pipermail/tuhs/2022-March/025545.html
.\"
.\" The groff reimplementation of mm was undertaken mostly from
.\" 1991-1999 (by Juergen Haegg), based on the DWB documentation. It
.\" added features but also parameterized many aspects of package
.\" behavior, for example to facilitate easy localization. Later,
.\" Werner Lemberg and G. Branden Robinson contributed enhancements, bug
.\" fixes, and improvements to the groff_mm(7) man page.
.\"
.\" I anticipate adding further parameters to groff mm to better
.\" emulate the old version of mm used by this paper. (For example, the
.\" format of the caption applied to the reference page differs between
.\" PWB mm and DWB 3.3.) Where this document exercises such extensions,
.\" they should be prefixed with a `do` request so that AT&T troff will
.\" ignore them.
.\" Override: "By default, ... bold stand-alone headings are printed
.\" in a size one point smaller than the body."
.\" XXX: The cover "page" (more like a header block) is a mess when
.\" typeset with groff mm, and outright horrific in nroff mode. GBR has
.\" fixes for these pending for push to GNU Savannah's Git repository.
.\"
.\" XXX: Original scan capitalizes "Subject:"; DWB 3.3 renders it in
.\" full lowercase.
.\"
.\" XXX: Original scan bears a "TM:" heading for the technical
.\" memorandum number(s). DWB 3.3 lacks this.
.\"
.\" Memorandum captions may have changed from PWB to DWB 3.3 mm. groff
.\" mm has changed in Git (June 2024) to use the captions documented in
.\" the DWB 3.3 manual. We override the default for authenticity.
.\" XXX: Original scan sets reference marks as a typewriter might, at
.\" normal size on the baseline between square brackets. DWB 3.3
.\" converts them to superscripts but keeps the brackets(!). groff mm
.\" should add a "Rfstyle" register to control this.
.\" 0 = auto (nroff/troff); 1 = bracket; 2 = superscript; 3 = both. (?)
\" straight quotes in original
.ns \" XXX: Hack to keep `VL` from adding pre-list vertical space.
\" recte: *(\-\-p+i)
\" bad ellipsis spacing in original
\" - missing; error in text or scanner fubar?
\" recte: \-1
\" sic
.\" Either `AL` worked differently in 1978 mm, or didn't exist, or
.\" somebody wanted this list _just so_.
.\"AL "" 5
.\" XXX: Scan has signatures set farther to the right, not centered as
.\" DWB 3.3 mm sets them. groff mm follows DWB here.
.\"
.\" XXX: PWB and DWB 3.3 put the signature names in bold; groff mm sets
.\" them at normal weight. Bug.
.\"
.\" XXX: Scan has a couple of vees between the signature line and the
.\" flush left secretarial annotation. groff mm sets the annotation on
.\" the same line as the last author but also puts its information in
.\" the cover page header as DWB 3.3 does, described next. DWB 3.3: (1)
.\" omits the secretarial annotation altogether, putting it up in the
.\" cover page header under the authors' names; (2) does not use author
.\" initials (in the cover header) for this memorandum type; (3) puts
.\" the department number after "Org." on the line under the author
.\" name; (4) puts the abbreviated AT&T site name below that. Should we
.\" consider a `Sgstyle` register for groff mm?
.\"
.\" XXX: groff mm organizes the department and site name differently
.\" from DWB 3.3 in the cover head, and I don't see any reason for it
.\" to. Fix this.
.\" XXX: Scan only breaks between notations; DWB 3.3 and groff put 1v
.\" between them. Should we consider an `Nss` register for groff mm?
.\" XXX: Scan has references caption set flush left, in mixed case and
.\" bold (just like `HU`). DWB 3.3 and groff center it and set it in
.\" full caps in italics (at normal weight). If there were a way to
.\" dump the accumulated reference list independently of rendering the
.\" caption, that would give the author much more flexibility.
.\"
.\" XXX: The numbered reference list does not look like one produced
.\" with `RL` nor with `AL`. The numeric tag is left-aligned within the
.\" paragraph indentation. groff mm aligns it to the right.
.\"
.\" DWB 3.3 and Heirloom mm don't seem to honor `.RP 2` as the DWB
.\" manual documents. They start the table immediately after the
.\" reference list and go haywire boxing the table. Bug.
Regards,
Branden
[1] https://github.com/g-branden-robinson/retypesetting-mathematics
All,
There's an interesting dive into PID 0 linked to from osnews:
https://blog.dave.tf/post/linux-pid0/
In the article, the author delves into the history of the scheduler a
bit - going back to Unix v4 (his assembly language skills don't go to
PDP variants).
I like the article for two reasons - 1) it's clarity 2) it points out
the self-reinforcing nature of our search ecosystem.
I'm left with the question - how did scheduling work in v0-v4? and the
observation that search really sucks these days.
Later,
Will
The book ``S: An Interactive Environment for Data Analysis and
Graphics'' (Wadsworth, 1984), by Richard A. Becker and John
M. Chambers, and an earlier Bell Labs report in 1981, introduced the
S statistical software system that later evolved into the commercial
S-Plus system (now defunct, I think), and the vibrant and active R
system (https://cran.r-project.org/) that we use at Utah in our
statistics courses.
Almost 21,000 open-source packages for R are available, and they
appear to be the dominant form of statistical software package
publication, based on extensive evidence in our bibliography archives
that completely cover numerous journals in probability and statistics.
I'm interested in looking into the early S source code, if possible,
to see how some statistical software that I am freshly implementing
for high-precision computation was handled at Bell Labs more than four
decades ago.
Does anyone on this list know whether the original S system was ever
distributed in source code to commercial sites, and academic sites,
that licensed Unix from Bell Labs in the 1980s? Does that code still
exist (and is openly accessible), or has it been lost?
As with the B, C, D, and R programming languages, it is rather hard
for Web search engines to find things that are known only by a single
letter of the alphabet.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah -
- 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/ -
-------------------------------------------------------------------------------
Well, I really dove into using vi by way of nvi this past week and I
have to say... the water's fine. It turns out that vi is a much simpler
editor to understand and use (but no less powerful) than it's great
grandchild, vim. To be fair, vim is an interesting editor and having
used it off and on since the mid '90s, it's very familiar... but its
powers? difficult to attain.
vim stands as an excellent example of just how far you can take a
product that works, keeping its core, but expanding it in all
directions. No matter how much I tried to grasp its essence, it alluded
me. The online help files seemed inscrutable to me, mixing environment
settings, ex commands, ex mode commands, vi motions, insert mode
commands in ways that seemed quite confusing to me. I know that I'm
probably among a select few vim users that love it without really having
a clue as to how it works. My best resource has been the web and search,
but of late I've been wanting more. That's what drove me on this quest
to really dig in to how things used to work and nvi is the best
surrogate of the old ways that I could find (well, excluding heirloom
vi, the traditional vi, which I've confirmed works pretty much the same
way as nvi, with lisp support and without a few nice-to-haves nvi has).
Anyway, here's something I worked out, after much travail - vi appears
to be all about modes, movement, counts, operators, registers, and
screens (which I found very weird at first, but simple in retrospect)...
with these fundamentals down, it seems like you can do anything and I
mean anything... and all of the other functions are just bolted on for
the purpose of making their specific tasks work.
Getting this out of the existing documentation was a mess. Thankfully
the nvi docs (based on the 4.4 docs) are much slimmer and better
organized. Even so, they make assumptions of the reader that I don't
seem to fit. Take motions as prolly the most glaring example - all of
the docs I've ever seen organize these by logical units of text (words,
paras, etc), personally and apparently persistently, I think of motion
as directed, so it took me a lot of experimentation, head scratching,
and writing things out several times in several different ways to
realize I could represent the idea on a single notecard as (some
commands appear in multiple lines):
Leftward motions - [[, {, (, 0, ^|_, B, b, h|^H
Rightward Movement - l|SP, e, E, w, W, $, ), }, ]]
Upward motions - 1G, ^B, H, ^U, -, k | ^P
Downward motions - G, ^F, L, ^D, ^M | +, j | ^J | ^N
Absolute - | G
Relative - %, H, M, L
Marks - m, ', `, '', ``
Keeping in mind that movements left-to-right are - section, para,
sentence, line, text, word and endword (big, and small), and letter. And
up and down are - file, screen, in screen (HML), half-screen,
chars-in-line, and line. For me, this inversion from units of motion to
direction of motion put forty some-odd commands in much closer reach for
me. Looking back at the vim documentation, I see how its sheer volume
and the way it is organized got in the way of my seeing the forest.
Thankfully, in nvi, there are two incredibly useful ex commands to help
- exu[sage] and viu[sage]. I simply printed these out and worked with
them making the experimental assumption that they would serve as a
baseline that represented the full capabilities of vi... and sure
enough, after working and working with them, I am pretty confident they
are sufficient for any editing task. Wow, who knew? I loved vi, but
now, I'm starting to really appreciate it's simplicity?! I can't believe
those words are coming out of my mouth. I never thought of it as
simple... those movement commands were far too numerous as I understood
them.
Are there things I miss from vim? Sure, I miss command line completion
in ex mode, I want my help text to appear in a window where I can
search, I would like better window control. But, I think I'll stick with
nvi a while until I really nail it down. Then all of the cool stuff that
vim offers, or neovim, will seem like icing on the cake that is vi.
Thanks to Ken Thompson for writing a work of art that serves as the true
core of this editor, to Bill Joy for his great work in extending it,
again to Bill Joy for bringing vi to life, and to Mary Ann for the
macros and making it accessible to the rest of us, and others who
contributed. It's 2024 and I still can't find a better terminal editor
than vi... as it existed in the late '80s or as it exists today as
nvi/vim/neovim. Amazing piece of software.
Off to figure out tags!! Arg, seems like it oughtta be really useful in
my work with source code, why can't I figure it out?! Sheesh.
Will
A small reflection on the marvels of ancient writing...
Today, I went to the local Unix user group to see what that was like. I
was pleasantly surprised to find it quite rewarding. Learned some new
stuff... and won the door prize, a copy of a book entitled "Introducing
the UNIX System" by Henry McGilton and Rachel Morgan. I accepted the
prize, but said I'd just read it and recycle it for some other deserving
unix-phile. As it turns out, I'm not giving it back, I'll contribute
another Unix book. I thought it was just some intro unix text and
figured I might learn a thing or two and let someone else who needs it
more have it after I read it, but it's a V7 book! I haven't seem many of
those around and so, I started digging into it and do I ever wish I'd
had it when I was first trying to figure stuff out! Great book, never
heard of it, or its authors, but hey, I've only read a few thousand tech
books.
What was really fun, was where I went from there - the authors mentioned
some bit about permuted indexes and the programmer's manual... So, I
went and grabbed my copy off the shelf and lo and behold, my copy either
doesn't have a permuted index or I'm not finding it, I was crushed. But,
while I was digging around the manual, I came across Section 9 - Quick
UNIX Reference! Are you kidding me?!! How many years has it taken me to
gain what knowledge I have? and here, in 20 pages is the most concise
reference manual I've ever seen.
Just the SH, TROFF and NROFF sections are worth the effort of digging up
this 40 year old text.
Anyhow, following on the heels of a recent dive into v7 and Ritchie's
setting up unix v7 documentation, I was yet again reminded of the golden
age of well written technical documents. Oh and I guess my recent
perusal of more modern "heavy weight" texts (heavy by weight, not
content, and many hundreds of pages long) might have made me more
appreciative of concision - I long for the days of 300 page and shorter
technical books :). In case you think I overstate - just got through a
pair of TCL/TK books together clocking in at 1565 pages.
Thank you Henry McGilton, Rachel Morgan, and Dennis Ritchie and Steve
Bourne and other folks of the '70s and '80s for keeping it concise. As a
late to the party unix enthusiast, I greatly value your work and am
really thankful you didn't write like they do now...
Later,
Will
> was there ever any crossover regarding UNIX folks applying their
developments to other non-UNIX AT&T systems
Besides Sandy Fraser's long-term effort to advance digital communication
(as distinct from digital transmission), there was TPC; see TUHS
https://www.tuhs.org/pipermail/tuhs/2020-April/020802.html and other
mentions of TPC in the TUHS archives.
Ken Thompson did considerable handholding for early adopters of Unix for
applications within the Bell System, notably tracking automatic trouble
reports from switching systems and managing the workflow of craftspeople in
a wire center.
Bob Morris's intimate participation in a submarine signal-processing
project that Bell Labs contracted to produce for the US Navy set him on a
career path that led to becoming chief scientist at NSA's National Computer
Security Center.
Gerard Holtzmann collaborated to instill model-checking in switching and
transmission projects.
Andrew Hume spent much time with AT&T's call records.
Lorinda Cherry single-handedly automated the analysis of call centers'
notes on customer contacts, This enabled detection of significant
human-engineering and public-relations problems.
An important part of my role as a department head was to maintain contacts
with development labs so that R and D were mutually aware of each other's
problems and expertise. This encouraged consulting visits, internships, and
occasionally extended collaboration or specific research projects as
recounted above.
Doug
Today, as I was digging more into nroff/troff and such, and bemoaning
the lack of brevity of modern text. I got to thinking about the old days
and what might have gone wrong with book production that got us where we
are today.
First, I wanna ask, tongue in cheek, sort of... As the inventors and
early pioneers in the area of moving from typesetters to print on
demand... do you feel a bit like the Manhattan project - did you maybe
put too much power into the hands of folks who probably shouldn't have
that power?
But seriously, I know the period of time where we went from hot metal
typesetting to the digital era was an eyeblink in history but do y'all
recall how it went down? Were you surprised when folks settled on word
processors in favor of markup? Do you think we've progressed in the area
of ease of creating documentation and printing it making it viewable and
accurate since 1980?
I didn't specifically mention unix, but unix history is forever bound to
the evolution of documents and printing, so I figure it's fair game for
TUHS and isn't yet COFF :).
Later,
Will
> Were you surprised when folks settled on word processors in favor of
markup?
I'm not sure what you're asking. "Word processor" was a term coming into
prominence when Unix was in its infancy. Unix itself was sold to management
partly on the promise of using it to make a word processor. All word
processors used typewriters and were markup-based. Screens, which
eventually enabled WYSIWYG, were not affordable for widespread use.
Perhaps the question you meant to ask was whether we were surprised when
WYSIWYG took over word-processing for the masses. No, we weren't, but we
weren't attracted to it either, because it sacrificed markup's potential
for expressing the logical structure of documents and thus fostering
portability of text among distinct physical forms, e.g. man pages on
terminals and in book form or technical papers as TMs and as journal
articles. WYSIWYG was also unsuitable for typesetting math. (Microsoft Word
clumsily diverts to a separate markup pane for math.)
Moreover, WYSIWYG was out of sympathy with Unix philosophy, as it kept
documents in a form difficult for other tools to process for unanticipated
purposes, In this regard, I still regret that Luca Cardelli and Mark
Manasse moved on from Bell Labs before they finished their dream of Blue, a
WYSIWYG editor for markup documents, I don't know yet whether that blue-sky
goal is achievable. (.docx may be seen as a ponderous latter-day attempt.
Does anyone know whether it has fostered tool use?)
Doug
