the discussion of why the CSRG disbanded in 1995 has come up elsewhere.
My memory is that the reason was pretty simple: DARPA ended their
funding at that time.
Hoping for corrections to my memory :-)
> From: Clem Cole
> So by the late 70s/early 80s, [except for MIT where LISP/Scheme reigned]
Not quite. The picture is complicated, because outside the EECS department,
they all did their own thing - e.g. in the mid-70's I took a programming
intro couse in the Civil Engineering department which used Fortran. But in
EECS, in the mid-70's, their intro programming course used assembler
(PDP-11), Algol, and LISP - very roughly, a third of the time in each. Later
on, I think it used CLU (hey, that was MIT-grown :-). I think Scheme was used
later. In both of these cases, I have no idea if it was _only_ CLU/Scheme, or
if they did part of it in other languages.
Noel
Some of the folks here might like this FB group...
Internet Old Farts Club
https://www.facebook.com/groups/internetoldfarts/
> This group is for self-declared Internet Old Farts, who want to discuss any aspect of the the Internet or its history. People in this group had their bits walk up hill both ways.
> Welcome to the Internet Old Farts group.
The purpose of this group is both social and technical. Feel free to revisit the past, explore the future, grouse about technical problems that you or others created. Feel free to self-aggrandize, complain about your least favorite standards organization or its politics, and how those young whippersnappers are running the show today.
By participating in this group you are admitting or proclaiming that you are indeed an Internet Old Fart. Perhaps we should give a prize for the youngest and oldest Old Fart.
-r
There is a new book from MIT Press, edited by Harry Lewis, with a
collection of classic papers in computer science, among them
37: The Unix Time-Sharing System (1974)
Dennis Ritchie, Kenneth Thompson
DOI: https://doi.org/10.7551/mitpress/12274.003.0039
The book Web site is at
https://direct.mit.edu/books/book/5003/Ideas-That-Created-the-FutureClassic…
-------------------------------------------------------------------------------
- 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/ -
-------------------------------------------------------------------------------
Has anyone seen Fraser's original ratfor source for the s editor for unix on the PDP-11. It was a screen editor front-end built on top of Software Tools's edit. I've seen a c version, but I'm interested in the 375 line version :).
Will
Sent from my iPhone
Resending this as realised accidentally replied off list
Silas
On 30 Jan 2022, at 18:39, silas poulson <silas8642(a)hotmail.co.uk<mailto:silas8642@hotmail.co.uk>> wrote:
On 30 Jan 2022, at 18:07, Dan Stromberg <drsalists(a)gmail.com<mailto:drsalists@gmail.com>> wrote:
And is Java? They both have a byte code interpreter.
My understanding is Java is both a compiled and interpreted language -
with javac compiling java code to byte code and then JVM interpreting
and executing the byte code.
And then there's the CPython implementation of Python. <snip>
Granted, it has an implicit, cached compilation step, but is it less compiled for that?
I would so no - in my mind compiling analyses the entire source and
then translates it whilst interpreters only explore a single line or
expression. Simply because the compilation happens only Just In Time,
doesn’t make it any less of a compilation step.
Hope that helps,
Silas
One of architechture supported by 4.4BSD, luna68k's compiled binary is
now available.
http://www.netside.co.jp/~mochid/comp/bsd44-build/
luna68k is OMRON LUNA, m68k cpu workstation. This binary set works on
"nono" emulator software.
http://www.pastel-flower.jp/~isaki/nono/
It's author, Isaki-san have done some minor modification for 4.4BSD,
binary set for luna68k run rather well.
OMRON, already dropped thier workstation products. LUNA-I, LUNA-II
equipped with m68k, same CPU as CSRG's main target arch hp300.
So userland programs may binary compatible.
-mochid
I'm working through 4.3BSD setup and configuration and came across this:
"There is no equivalent service for network names yet. The full host and network name databases are normally derived from a file retrieved from Internet Network Information Center at SRI... use gettable to retrieve the NIC host database and htable to convert it to the format used by the libraries."
Does this mean I should expect functionality like resolv.conf and ping yahoo.com not to work in 4.3, or by some miracle is gettable still a functional system?
Will
Sent from my iPhone
Hi all,
I've been hard at work on my retro-fuse project over the past few
months, and so I thought I'd update the list with my progress.
I have just released version 7 of retro-fuse on github
(https://github.com/jaylogue/retro-fuse) This version adds support for
initializing and mounting 2.9 and 2.11BSD filesystems on modern
systems. It also includes fixes for a number of bugs in v6 and v7 support.
Beyond the work on 2.11 support, I also spent a significant amount of
time building an automated test framework. I'm a pretty big fan of
automated testing. So I'm happy to say that the project now includes a
series of tests verifying basic file I/O functionality as seen from the
modern system. While not exhaustive (because filesystem testing is
/hard/) the new tests give me reasonable confidence that things are
behaving as they should.
Additionally (in what was perhaps the most fun part of the project to
date) I have also created tests to verify the integrity of the generated
filesystems as seen from the historical systems. In particular, for each
of the supported Unix versions I've built tests that: launch the os
under simulation (simh), mount the generated filesystems, verify the
filesystems using the original integrity check tools (icheck/fsck), and
enumerate and compare the filesystem contents to that generated on the
modern system. As you might imagine, this involved a lot of
learning--from how to build size-reduced system images from the original
distribution tapes, to how to implement a modern POSIX cksum command
with old dev tools. All thoroughly enjoyable.
With this under my belt, I'll probably take a break from retro-fuse to
concentrate on other things. If anyone has any problems (or successes!)
using it, please drop me a line.
--Jay
Wow. Brings back memories
On Mon, Jan 24, 2022 at 1:32 PM Robert Diamond <rob(a)robdiamond.com> wrote:
> Just found this program from 1979 of an Explorer Club (aka “The Scouts”)
> Family Night, which included a talk from Ken Thompson on Computer Chess.
> There’s a few notable names in there.
>
> See PDF at
> https://drive.google.com/file/d/15fXhkk9KlmJNrhGlFnWuH23XQ09vLG4o/view?usp=…
--
Aaron Cohen
908-759-9069
> Did roff do all of what troff and nroff did?
No way. Ossanna deserves all the praise you give him. Roff extended
runoff in various ways:
relative numeric operators, e.g. .in +8
tabbing (left, right and centered)
underlining
tripartite headers and footers
arabic and roman page numbering
adjustable head and foot margins
automatic hyphenation, thanks to Molly Wagner
footnotes
merge patterns for change marks, column separators, etc.
various special requests: .ne, .ti, .tr, .po, .op (odd page)
But roff did NOT have conditionals, traps, special characters,
environments, or arbitrary motion control. Crucially (and ironically,
because I was Mr. Macro), it did not have anything like macros,
strings and diversions until after Joe pioneered them in nroff.
So there was a gaping disparity: nroff was Turing complete, roff
wasn't. Roff merely added features to runoff; nroff leapt into a
different universe.
-----------------------
The features listed above are in the January 1971 manual for BCPL
roff, which is probably the anonymous reference cited in the November
1971 v1 manual. The v1 manual lists Osanna, Ken and Dennis as authors
of the Unix implementation. I believe Ossanna is named because he
added line-numbering--and maybe more--to entice the patent department
to switch to roff.
BCPL roff allowed all four arithmetic operators in contexts like .ls
*3. Only + and - were allowed in nroff. Eventually both BCPL roff and
nroff got number registers (defined by different commands); I don't
recall which came first. BCPL roff also got a weak macro facility,
definitely after nroff.
Doug
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