> What is the name of the mathematic symbols
Here are some readings, not exactly names
incl (used with partial orderings) is included in, or is less than
|> is not greater than
|< is not less than
<wig
>wig
wig is approximately, or asymptotically approaches
~wig is approximately
Doug
I had an experience similar to Tom London's:
To: alice!rob
Subject: you've spoiled me
I can't believe it. I'm sitting here at home in front of my
2621, and I can't work.
Damn it. I've got to get a blit at home.
When I left Bell Labs, I had an X11 workstation at work, but
only a simple terminal at home. Having used a Jerqblit5620 for
years at both work and home, I found it incredibly limiting.
After a year or so I came across a reseller who had a lot of
off-lease 5620s for sale cheap (like USD 150 or so each). I
asked around the university I now worked at, found a handful
of other people who wanted in, and then a local small company
who did System V system-administration consulting who wanted
some for themselves, and were willing to handle all the paperwork.
All that allowed us to negotiate the price down even more.
In the end I bought six, of which I think four are still working,
though I haven't turned any of them on for years.
None of the Unixes I used at the time came with 5620 support,
but the protocol for the basic window system built into the ROM
was well-documented and I managed to roll my own host support.
I also managed to cobble up my own binary-loading tools sufficient
to get sam working (I forget how I compiled the binary for the
terminal); that was rather more work, but it was worth it to
be able to have sam and multiple windows from home, even though
it was the ROM OS and therefore mpx rather than mux.
I remember porting my version of the host code to Ultrix,
SunOS 4, and IRIX.
My workplace at the time had a little bit of VAX/VMS around.
I didn't use that much but wanted to try porting my host code
to VMS as well. VMS had had a C compiler for some years and
some sort of pseudo-terminal for a shorter time, so it ought
to have been possible. I didn't get around to it before we
finally left VMS behind in the dustbin of history. I wish I'd
found time to do it, just to show that there really was nothing
Unix-specific about the idea or the implementation. It's just
a multiplexing protocol; it needs no kernel support except that
needed to run a command-line session not attached to a physical
terminal, and networking has long since made that available on
any competent OS.
Norman Wilson
Toronto ON
The standard routine for drawing menus on the jerq was
'menuhit'. Items in the menu were centered, and the menu was
scrollable when a certain threshold number of items was
reached, and in addition, when the mouse pointer was in the
top (bottom) item of the menu and it was possible to scroll
in the appropriate direction, the menu was scrolled up or
down 1 line. The structure associated with these menus is
'Menu'.
There was however another menu-drawing routine, 'mhit', the
menus drawn by this being hierarchical, the structure NMenu,
which no longer contained text strings but an array of NItems.
NMenus also had provision for 'help' text to be displayed, a
simple string displayed on the screen, when button 1 was
pressed while an entry in the menu was selected.
The earliest version in the Eight Edition jerq code, also has
one function in the NMenu structure which is called when the
mouse pointer invokes a hierarchical menu. By Ninth Edition
this has been expanded, with 3 functions, one as above, one
invoked when an item is selected ('hit') and one when a
hierarchical menu is exited.
In the jerq code directories, under 'lib/jj', is a small 'ms'
document, 'A Library of Goo for the 5620', which lists
routines available in the library, and their authors. Andrew
Hume is listed as the author of 'mhit'.
Are there examples of code using these three menu functions
('dfn', 'hfn', 'bfn')?
There seems to have been little interest in hierarchical menus
at the labs, their use was quite limited. I found a program
in the Tenth Edition archive, 'bubble' (which seems to be a
program for displaying the three-dimensional structure of
molecules) which uses them. 'samuel' made heavy use of them,
including use of the 'hit' function, and Tom Cargill used
basically the same code in 'pads' wherein the routine was
called 'scripthit'.
The plain 'menuhit' survived into Plan9, but as far as I
know, it is only used by 'sam'.
Available at https://www.skeeve.com/bell-labs-cstrs.tar.gz
Warren and Brantley and anyone else, feel free to retrieve.
I have two sets - both are in the tarball so there are undoubtedly
duplications. If someone else can curate them into single canonical
set that'd be helpful, I just don't have the time right now.
Enjoy,
Arnold
> once you've got M3 and M4, you've got a naming convention; I'd
> think it a safe bet that there was an M5 that was an internal
> experiment, and that M6 was simply the next in line
M6 came first, created by Andy Hall as a portability tool for Altran.
I always assumed the name echoed Ken Knowlton's L6 (BelL Labs low
level list language, with a superscript 6). I seem to recall that M6
was endowed with a very labored acronym.
Doug
Hi All.
Attached is "A Supplemental Document For Awk". This circulated on USENET
in the 80s. My copy is dated January 18, 1989, but I'm sure it's
older than that. One clue is the reference to the 4.2 BSD manual,
and 4.3 came out already in 1986 or so.
Does anyone else have a copy of this with perhaps an older date?
As far as I can tell from a short search, the author is no
longer living. If someone knows better and can provide contact
info for him, that'd be great.
In the meantime, Warren, do you want to add it to the archives?
Thanks!
Arnold
There is a little known suite of programs, written by Peter Weinberger,
found as 'btree', or 'cbt', in the archives for Eighth and Tenth
Edition.
The code in the Eighth Edition archive seems to be the earliest, and
has fewer utilities than available in the Tenth Edition code. A search
through files shows that it was used by 'road', 'weather' and
'apnews'.
There is an ms file, 'memo', describing the programs, amongst the code,
but an appendix seems to be missing. If anyone knows about this or
where it might be I'd like to get my hands on it.
'Memo' itself is interesting because it's the only troff document I've
seen amongst the reseach papers (excluding Christopher Van Wyk's own
paper of course) that uses 'ideal', in this case, for drawing a
picture depicting B-tree structure.
Hello, I'd like to share some analysis from my recent Sixth Edition pass of my mandiff repository. For the V5-V6 diff, I opted for a branching approach, starting with a last universal common ancestor (which isn't quite right [1]). I compared each set of changes with the MERT0, PWB 1.0, CB-UNIX 2.3, 32V, and to a lesser extent V7 and System III manuals attempting to suss out the spiderweb of changes between them all. I created a series of branches representing last common changes between groups of branches as well. This has resulted in a littering of merge commits in the repository, but a banana's gonna have a peel.
A few important points about document genealogy here:
- The MERT0 manual, in the introduction, denotes descent from the USG Program Generic 3 manual. Furthermore, there is a listing of which pages would be replaced, which also serves as a key to which pages should be PG3 original text. However, the hs(IV) and ht(IV) pages make reference to specific MERT pages, so I question the veracity of this list. In any case, for the purposes of this analysis, much may extrapolate to USG PG3 as well. More study is needed.
- The CB-UNIX manual currently available is Edition 2.3. In studying the numbering system for CB, I've found that this represents Release 2, Issue 3, as in the kernel there are references to releases, not editions. The clue is in one of the manpages somewhere, I don't recollect as of this typing where, but that'll come back around soon enough. The manual itself appears to be from a binder that was once a CB-UNIX 2.1 binder and had select pages replaced. There are some bits and pieces of 2.1 pages that were otherwise slated to be replaced, alluding to things like the /etc/lines file in common with PG3. In any case I've prioritized 2.1 changes over 2.3 changes where they can be determined, but like PG3, no complete picture can be determined of 2.1 from available documentation.
For each of the branches, the following number of files in total reflect V5-V6 changes which aren't incorporated:
- 32V: 7
- PWB: 15
- MERT0: 46
Of these MERT0 has the greatest number of items lacking research's upstream changes from late '74-early '75. Among them:
- Has a V5-ish bas(I), no rc(I) (ratfor) at all
- The group system is not present, newgrp(I), group(V), chgrp(VIII), etc. are nowhere to be found
- nice(I) has no priority argument, simply sets a "low priority"
- TTYs are still referred to as "teletypes" instead of "typewriters" in many places
- there are 10 TTYs max so many commands don't reflect adjustments for two-digit IDs (ps(I) in particular is quite different, very V5)
- retains the lpr print command (which shows up again in 32V and System III)
- additionally, according to the replacement page list, PG3 retained the fed and form editing programs
- Program Generic may not have had a man(I) page, as the one here is a MERT0 addition, hard to say
CB tragically needs to be remerged, found as I was typing this up the system call section got an errant merge with V6 changes that shouldn't be there. Needless to say there is much in section II of the CB manual that leans more V5-ish than V6-ish. PWB differs in minor ways.
The differences can be found in this list https://gitlab.com/segaloco/mandiff/-/merge_requests?scope=all&state=closed
Each of the obviously labeled, closed merges represents a snapshot diff of the particular branch in question. As stated, the CB branch currently is in dire straits, I'm going to work that up again sometime in the future, but I should be able to use this to produce diff-able reproductions of the MERT0 and CB-UNIX 2.3 manual sources for this repository, as well as any other materials that may pop up.
- Matt G.
[1] - This pass I did not take good notes on such matters, but there are a few pages I'll anecdotally say reflect contents predating V5 sprinkled amongst the various manuals. I will consult with previous diffs when questions arise on in-depth analysis of the non-research changes in the branches. In any case the historical record already confirms CB-UNIX at the very least branched off quite early.
Hello everyone,
this is my first post on this list.
After looking at the archives for this mailing list, I have seen that
the B language has been discussed several times already.
After viewing Ken Thompson's interview by Brian Kernighan at VCF East
2019, I became interested in the B language, as it seemed full-featured
for system programming, close to C, and simple enough to write a parser
for it without a code generation tool.
So for fun and self-education, I am now writing a (or yet another) B
compiler, in C, after reading Jack Crenshaw's "Let's build a compiler"
documentation ( https://compilers.iecc.com/crenshaw/ )
Here it is: https://git.sr.ht/~f4grx/bpars
It is now starting to generate code for the 68hc11 8-bit platform. It
can also generate C code.
I have written some test programs, found some B examples, but I thought
it would be great to use my compiler with actual B software.
Of course, B was a "transition" language, that did not have a continued
use as soon as it evolved into C. so if any software remains, it will be
quite hard to find.
And here is my question, is any of you aware of original B source code
archives? or are in touch with people that would know?
In particular, I read on this document written by Dennis Ritchie:
https://www.bell-labs.com/usr/dmr/www/chist.html
> After the TMG version of B was working, Thompson rewrote B in itself
(a bootstrapping step).
I have also read that the YACC tool was initially written in B.
There might be other historical B sources that I am not aware of.
Do you know if any of this code has survived to this day? Where could I
find more information about this?
Thank you very much,
Sebastien Lorquet (F4GRX)
