> From: Clem Cole
> what I don't remember was it in v5
Your memory is going! :-) We discussed this recently (well, recently in _our_
timescale :-); it's built into in 'cc' in V5:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/cc.c
see "expand(file)".
Noel
> From: Will Senn
> My question is - how did y'all run things - with CSR zero and no kernel
> messages ... or with CSR non-zero and kernel messages.
On the -11/45 V6+ at MIT, we didn't have a printing terminal on the console,
just a VT52. We had a tool at MIT called 'dmesg':
http://ana-3.lcs.mit.edu/~jnc/tech/unix/man8/dmesg.8
which made up for that a bit.
We normally ran with the CSR set to 173030 - the 'boot in single-user'
setting. That's because at one point the machine was in the 9th floor machine
room, but the console VT52 was on the 5th floor (where our offices were - the
famous print of the GE-645 Multics was on the hallway wall outside mine :-),
and I'd added a 'reboot()' system call (nothing fancy, it just jumped to the
bootstrap ROM), so we could reboot the machine without going up in the
elevator (not if it had crashed, of course). Later on, after we'd done with
kernel hacking (adding a network interface, and IP), and the machine stayed up
for long periods, we moved the console up next to the machine (since if it
crashed, you had to use the front panel to restart it, so you had to be up
there anyway); we stayed with the default CSR setting, though. (If it panic'd,
you could see the reason why when you went to reboot it.)
> Oh, BTW, I know I've seen this noted elsewhere, but I can't remember
> where.
Maybe at:
https://gunkies.org/wiki/UNIX_Sixth_Edition#Distros
which discusses it?
Noel
I noticed in v6 source that putch in prf.c - the system kernel printf's
character routine, only prints to the console if the Console Switch
Register is non-zero.
My question is - how did y'all run things - with CSR zero and no kernel
messages (seems dangerous to me, being naive and all) or with CSR
non-zero and kernel messages.
On my FreeBSD instance, I value the messages that show up on console as
they've alerted me to big problems in the past, but on my Mac, not as
much (sure you can run Console and see them, but they aren't immediate).
Oh, BTW, I know I've seen this noted elsewhere, but I can't remember
where. Dennis's v6 doesn't have the Western Electric message:
mem = 435
RESTRICTED RIGHTS
Use, duplication or disclosure is subject to
restrictions stated in Contract with Western
Electric Company, Inc.
It was a bit of a head scratcher as I was trying to read from the Dennis
version of the distro on my mac while running Wellsch's tape on simh. I
spent quite a while spinning my wheels looking for "Western" in the
files to no avail. I thought something was screwy with the files or my mac.
All,
I got sick of poring over my Peer-to-Peer communications version of
Lion's commentary - trying to read it while digging around in v6 was
getting annoying. Of course, if you don't already own, rush out and by a
copy. It's great stuff. Anyhow, the problem is that it's perfect bound,
landscape and it's not searchable. Hunting around the internet, I found
pdfs that were searchable, but they were based on v7 being
back-engineered to v6 code. So, I located a decent source of
electronically readable Lion's source at
https://warsus.github.io/lions-/ and off I went. I took the code and did
a bit (quite a bit) of tweakage on it to get it formatted in pdf, and
created a version in letter format that I find pretty useful. It can be
read from a printout while messing around in v6. I've done some
proofing, but I don't claim it's perfect. If you find any issues with
it, let me know and I'll try to fix them (thanks, Clem for early
suggestions).
Here's what's in the letter sized pdf:
Tweaked Cover Page
Improved Table of Contents
Lion's version of V6 Source Code
Appendices
Source File Sheets Alphabetical List
Source File Locations in Running V6 System
What isn't in the pdf:
Original Forewords, Prefaces, or Letters (not needed for coding)
Symbol Lists, Cross references, or Indexes (beyond my skills at the moment)
All in all, I have found it quite readable and useful for my own work. I
don't claim any ownership or contribution, other than in improving the
readability of the work for modern readers. If the cross reference thing
kills you, just use gnu ctags on the source directories and ctags -x for
the line numbers.
Here's the link to the posting:
http://decuser.blogspot.com/2022/02/tweaked-version-of-lions-v6-source-code…
- will
Lorinda Cherry, a long-time member of the original Unix Lab
died recently. Here is a slightly edited reminiscence that
I sent to the president of the National Center for Women and
Information Technology in 2018 when they honored her with
their Pioneer in Tech award.
As Lorinda Cherry's longtime colleague at Bell Labs, I was
very pleased to hear she has been chosen for the NCWIT Pioneer
Award. At the risk of telling you things you already know,
I offer some remarks about her career. I will mainly speak of
things I saw at first hand when our offices were two doors
apart, from the early '70s through 1994, when Lorinda left
Bell Labs in the AT&T/Lucent split. Most of the work I describe
broke new ground in computing; "pioneer" is an apt term.
Lorinda, like many women (including my own mother and my wife),
had to fight the system to be allowed to study math and science
in college. She was hired by Visual and Acoustics Research
at Bell Labs as a TA--the typical fate of women graduates,
while their male counterparts were hired as full members of
technical staff. It would take another decade for that unequal
treatment to be rectified. Even then, one year she received
a statement of benefits that explained what her wife would
receive upon her death. When Lorinda called HR to confirm that
they meant spouse, they said no, and demanded that the notice
be returned. (She declined.) It seemed that husbands would not
get equal treatment until AT&T lost a current court case. The
loss was a foregone conclusion; still AT&T preferred to pay
lawyers rather than widowers, and fought it to the bitter end.
Lorinda moved to my department in Computing Science when
the Unix operating system was in its infancy. Initially she
collaborated with Ken Knowlton on nascent graphics applications:
Beflix, a system for producing artistically pixillated films,
and an early program for rendering ball-and-stick molecular
models.
She then joined the (self-organized) Unix team, collaborating
on several applications with Bob Morris.
First came "dc", an unlimited-precision desk calculator,
which is still a Unix staple 45 years on. Building on dc,
she would later make "bc", which made unlimited precision
available in familiar programming-language notation and became
the interface of choice to dc.
Then came "form" and "fed", nominally a form-letter generator
and editor. In fact they were more of a personal memory
bank, a step towards Vannevar Bush's famous Memex concept--an
interesting try that didn't pay off at that scale. Memex had to
sleep two more decades before mutating into the Worldwide Web.
Lorinda had a hand in "typo", too, a Morris invention that
found gross spelling mistakes by statistical analysis. Sorting
the words of a document by the similarity of their trigrams
to those in the rest of the document tended to bring typos to
the front of the list. This worked remarkably well and gained
popularity as a spell-checker until a much less interesting
program backed by a big dictionary took over.
Taken together, these initial forays foretold a productive
computer science career centered around graphics, little
languages, and text processing.
By connecting a phototypesetter as an output device for Unix,
Joe Ossanna initiated a revolution in document preparation. The
new resource prompted a flurry of disparate looking documents
until Mike Lesk brought order to the chaos by creating a macro
package to produce a useful standard paper format.
Taking over from Lesk, Lorinda observed the difficulty of
typesetting the mathematics (which the printing industry counted
as "penalty copy") that occurred in many research papers,
and set out to simplify the task of rendering mathematical
formulas, Brian Kernighan soon joined her effort. The result
was "eqn", which built on the way people read formulas aloud
to make a quite intuitive language for describing display
formulas. Having pioneered a pattern that has been adopted
throughout the industry, eqn is still in use forty years later.
Lorinda also wrote an interpreter to render phototypesetter
copy on a cathode-ray terminal. This allowed one to see
typeset documents without the hassle of exposing and developing
film. Though everyone has similar technology at their fingertips
today, this was genuinely pioneering work at the time.
You are certainly aware of Writers Workbench, which gained
national publicity, including Lorinda's appearance on the Today
Show. It all began as a one-woman skunk-works project. Noticing
the very slow progress in natuaral-language processing, she
identified a useful subtask that could be carved out of the
larger problem: identifying parts of speech. Using a vocabulary
of function words (articles, pronouns, prepositions and
conjunctions) and rules of inflection, she was able to classify
parts of speech in running text with impressive accuracy.
When Rutgers professor William Vesterman proposed a
style-assessing program, with measures such as the frequencies
of adjectives, subordinate clauses, or compound sentences,
Lorinda was able to harness her "parts" program to implement
the idea in a couple of weeks. Subsequently Nina MacDonald,
with Lorinda's support, incorporated it into a larger suite
that checked and made suggestions about other stylistic issues
such as cliches, malapropisms, and redundancy.
Another aspect of text processing that Lorinda addressed was
topic identification. Terms (often word pairs) that occur with
abnormal frequency are likely to describe the topic at hand. She
used this idea to construct first drafts of indexes. One
in-house application was to the Unix manual, which up until
that time had only a table of contents, but no index. This
was a huge boon for a document so packed with detail.
In her final years at Bell Labs, Lorinda teamed up with AT&T
trouble-call centers to analyze the call transcripts that
attendants recorded on the fly--very sketchy prose, replete
with ad-hoc contractions and misspellings. The purpose was
to identify systemic problems that would not be obvious from
transcripts considered individually. When an unusual topic
appeared at the same time in multiple transcripts, those
transcripts were singled out for further study. The scheme
worked and led to early detection of system anomalies. In one
case, it led AT&T to suspend publication of a house organ that
rubbed customers the wrong way.
Lorinda was not cut from the same mold as most of her
colleagues. First she was a woman, which meant she faced
special obstacles. Then, while there were several pilots
among us, there was only one shower of dogs and only one car
racer--moreover one who became a regional exec of the Sports
Car Club of America. For years she organized and officiated
at races as well as participating.
Lorinda was always determined, but never pushy. The
determination shows in her success in text analysis, which
involves much sheer grit--there are no theoretical shortcuts
in this subject. She published little, but did a lot. I am
glad to see her honored.
Doug McIlroy
The one I remember using in the 80s was called "fep" written by
Kazumasa Utashiro of Software Research Associates. It was probbaly posetd
posted to comp.sources.unix usenet group.
-Brian
Chet Ramey wrote:
> On 2/20/22 4:19 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> > Chet Ramey writes:
> >
> >> It always seemed like it would have been just the thing to implement as a
> >> tty streams module, but research Unix went in a different direction.
> >
> > I'm really surprised nobody has implemented a basic readline as a
> > tty line discipline by now. I was poking around the OpenBSD NMEA
> > line discipline code a few weeks ago and thinking it shouldn't be
> > that hard to do.
>
> It's not that hard. The complexity is in how sophisticated you want to get
> with redisplay and whether you want to allow user-specified key bindings.
>
> > Did anyone think about doing this in the past? If yes, what made you
> > decide against doing it? (Or a streams implementation, for that matter.)
>
> There have been several implementations (I never did one). I suspect that
> the people who were in a position to integrate that functionality into
> distributed kernels were not supportive, or the code didn't get to them
> at the right time.
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
On Feb 19, 2022, at 8:11 AM, Clem Cole <clemc(a)ccc.com> wrote:
>
>
> On Sat, Feb 19, 2022 at 11:04 AM Steve Nickolas <usotsuki(a)buric.co> wrote:
>> Apparently Bourne was heavily into ALGOL,
> That's sort of an understatement. I believe that when he was at Cambridge, he was one of the people that helped to take the Algol-X proposal and turned it into the Algol-68 definition. I also believe he worked on their famous implementation of same.
Some of you may be interested in this “A history of Algol68” paper:
https://dl.acm.org/doi/pdf/10.1145/234286.1057810
The author, Charles H Lindsey, still occasionally posts on comp.lang.misc
about Algol68. Among other things Bourne was a coauthor of Algol68C,
a portable implementation of Algol68.
Rob Pike:
I did the same to adb, which turned out to have a really good debugger
hidden under a few serious bugs of its own, which I fixed.
=====
Memories.
Was it you who replaced ptrace with /proc in adb, or did I do that?
I do remember I was the one who took ptrace out of sdb (which a
few 1127-ers, or perhaps 112-ers on alice and rabbit still used).
After which I removed ptrace from the kernel, and from the
copy of the V8 manual in the UNIX room. Conveniently ptrace
occupied two facing pages; I glued them together.
I also later did some work to try to isolate the target-dependent
parts of adb and to make them work in host-independent ways--e.g.
assembling ints byte-by-byte rather than assuming byte order--to
make it easier to make a cross adb, e.g. to examine PDP-11 or
68K core dumps on a VAX.
I miss adb; maybe it's time to revive it, though these days I'd
be tempted to rewrite it in Python so I could just load the right
module at runtime to pick the desired target.
Norman Wilson
Toronto ON
Second half of the 1980-tish when the computer division of Philips
Electronics started on their own Motorola M68010 / UNIX System V.3 (don't
remember for sure I'm afraid) they used a syntax.h with macros similar to
mac.h. Only I understand it's more Pascal like. Appended the 1987 version I
found in my archive.
Cheers,
rubl
--
The more I learn the better I understand I know nothing.
I have been poring through the v7 source code lately, and came across an
oddity I would like to know more about. Specifically, in sh. The code
for sh is c, but it makes *extensive* use of of macros, for example:
/usr/src/cmd/sh/word.c
...
WHILE (c=nextc(0), space(c)) DONE
...
The macros for sh are defined in mac.h:
/usr/src/cmd/sh/mac.h
...
#define BEGIN {
#define END }
#define SWITCH switch(
#define IN ){
#define ENDSW }
#define FOR for(
#define WHILE while(
#define DO ){
#define OD ;}
#define REP do{
#define PER }while(
#define DONE );
...
I can read the resultant code through the lens of my experience coding
c, but I'm curious why the macros and how this came about? In v6, the sh
source is straight up c. Is there a story behind it worth knowing?
Thanks,
Will
