TUHS

tuhs@tuhs.org

6515 discussions

by jnc＠mercury.lcs.mit.edu

> From: Steve Johnson > references that were checked using the pointer type of the structure > pointer. My code was a nightmare, and some of the old Unix code was at > least a bad dream. I had a 'fun' experience with this when I went to do the pipe splice() system call (after the discussion here). I elected to do it in V6, which I i) had running, and ii) know like the back of my hand. Alas! V6 uses 'int *' everywhere for pointers to structures. It also, in the pipe code, uses constructs like '(p+1)' to provide wait channels. When I wrote the new code, I naturally declared my pointers as 'struct inode *ip', or whatever. However, when I went to do 'sleep(ip+1)', the wrong thing happened! And since V6 C didn't have coercions, I couldn't win that way. IIRC, I finally resorted to declaring an 'int *xip', and doing an 'xip = ip' before finally doing my 'sleep(xip+1)'. Gack! Noel

6 years, 7 months

C entry keyword

by Steve Simon

“entry” was a reserved word in K&R Ed.1, my personal favourite C trivia. I have never seen it used outside fortran on mainframes though. -Steve

6 years, 7 months

Re: [TUHS] Another one (Was: In memoriam: Jon Postel)

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > We lost ... on this day An email from someone on a related topic has reminded me of someone else you should make sure is only your list (not sure if you already have him): J. C. R. Licklider; we lost him on June 26, 1990. He didn't write much code himself, but the work of people he funded (e.g. Doug Engelbart, the ARPANet guys, Multics, etc, etc, etc) to work on his vision has led to today's computerized, information-rich world. For people who only know today's networked world, the change from what came before, and thus his impact on the world (since his ideas and the work of people he sponsored led, directly and indirectly, to much of it), is probably hard to truly fathom. He is, in my estimation, one of the most important and influential computer scientists of all. I wonder how many computer science people had more of an impact; the list is surely pretty short. Babbage; Turing; who else? Noel

6 years, 7 months

Re: [TUHS] In memoriam: Jon Postel

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > We lost Jon Postel, regarded as the Father of the Internet Vint and Bob Kahn might disagree with that that... :-) > (due to his many RFCs) You need to distinguish between the many for which he was an editor (e.g. IP, TCP, etc), and the (relatively few, compared to the others) which he actually wrote himself, e.g. RFC-925, "Multi-LAN address resolution". Not that he didn't make absolutely huge contributions, but we should be accurate. Noel

6 years, 7 months

Re: [TUHS] Reconstructed and newly set UNIX Manual

by Doug McIlroy

> Now it could be that v7 troff is perfectly capable of generating the > manual just like older troff would have. On taking over editorship for v7, I added some macros to the -man package. I don't specifically recall making any incompatible changes. If there were any, they'd most likely show up in the title and synopsis and should be fixable by a minor tweak to -man. I'm quite confident that there would be no problems with troff proper. Doug

6 years, 7 months

Re: [TUHS] Reconstructed and newly set UNIX Manual

by Nelson H. F. Beebe

Angelo Papenhoff <aap(a)papnet.eu> writes about the conversion of printer points to other units: >> >From my experience in the world of prepress 723pts == 10in. >> >> Then Adobe unleashed PostScript on us and redefined the point >> so that 72pt == 1in. >> >> Ibunaware of any other definitions of a point. The most important other one is that used by the TeX typesetting system: 72.27pt is one inch. TeX calls the Adobe PostScript one a big point: 72bp == 1in. Here is what Don Knuth, TeX's author, wrote on page 58 of The TeXbook (Addison-Wesley, 1986, ISBN 0-201-13447-0): >> ... >> The units have been defined here so that precise conversion to sp >> is efficient on a wide variety of machines. In order to achieve >> this, TeX's ``pt'' has been made slightly larger than the official >> printer's point, which was defined to equal exactly .013837in by >> the American Typefounders Association in 1886 [cf. National Bureau >> of Standards Circular 570 (1956)]. In fact, one classical point is >> exactly .99999999pt, so the ``error'' is essentially one part in >> 10^8. This is more than two orders of magnitude less than the >> amount by which the inch itself changed during 1959, when it >> shrank to 2.54cm from its former value of (1/0.3937)cm; so there >> is no point in worrying about the difference. The new definition >> 72.27pt=1in is not only better for calculation, it is also easier >> to remember. >> ... Here sp is a scaled point: 65536sp = 1pt. The distance 1sp is smaller than the wavelength of visible light, and is thus not visible to humans. TeX represents physical dimensions as integer numbers of scaled points, or equivalently, fixed-point numbers in points, with a 16-bit fraction. With a 32-bit word size, that leaves 16 bits for the integer part, of which the high-order bit is a sign, and the adjacent bit is an overflow indicator. That makes TeX's maximum dimension on such machines 1sp below 2^14 (= 16,384) points, or about 5.75 meters or 18.89 feet. ------------------------------------------------------------------------------- - 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/ - -------------------------------------------------------------------------------

6 years, 7 months

Re: [TUHS] Reconstructed and newly set UNIX Manual

by Angelo Papenhoff

[this was meant to go over the list, Warren quoted it, but it destroyed the formatting somewhat] On 27/10/18, Warren Toomey wrote: > On Fri, Oct 26, 2018 at 09:46:36PM +0200, Angelo Papenhoff wrote: > > And most importantly: is the old troff really lost? > > Angelo, I just trawled through the Unix Archive. Below is a list > of tarballs with roff stuff in them. Hope this helps. Sorry that > they are not in date order. > Cheers, Warren Unfortunately that does not include the old troff written in PDP-11 assembly. The v6 tape and file system contain traces of it in the directory /usr/source/s7, so we at least know (some of) the file names: │002655f0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 | | │00265600 6d 01 72 6f 66 66 33 2e-73 00 00 00 00 00 00 00 |m?roff3.s | │00265610 6c 01 72 6f 66 66 34 2e-73 00 00 00 00 00 00 00 |l?roff4.s | │00265620 6b 01 72 6f 66 66 35 2e-73 00 00 00 00 00 00 00 |k?roff5.s | │00265630 6a 01 72 6f 66 66 37 2e-73 00 00 00 00 00 00 00 |j?roff7.s | │00265640 69 01 72 6f 66 66 38 2e-73 00 00 00 00 00 00 00 |i?roff8.s | │00265650 00 00 73 75 66 72 63 00-00 00 00 00 00 00 00 00 | sufrc | │00265660 67 01 73 75 66 74 61 62-2e 73 00 00 00 00 00 00 |g?suftab.s | │00265670 00 00 74 63 61 74 73 69-6d 2e 73 00 00 00 00 00 | tcatsim.s | │00265680 00 00 74 72 63 00 00 00-00 00 00 00 00 00 00 00 | trc | │00265690 00 00 74 72 6f 66 66 31-2e 73 00 00 00 00 00 00 | troff1.s | │002656a0 00 00 74 72 6f 66 66 32-2e 73 00 00 00 00 00 00 | troff2.s | │002656b0 00 00 74 72 6f 66 66 33-2e 73 00 00 00 00 00 00 | troff3.s | │002656c0 00 00 74 72 6f 66 66 34-2e 73 00 00 00 00 00 00 | troff4.s | │002656d0 00 00 74 72 6f 66 66 35-2e 73 00 00 00 00 00 00 | troff5.s | │002656e0 00 00 74 72 6f 66 66 36-2e 73 00 00 00 00 00 00 | troff6.s | │002656f0 00 00 74 72 6f 66 66 36-61 00 00 00 00 00 00 00 | troff6a | │00265700 00 00 74 72 6f 66 66 38-2e 73 00 00 00 00 00 00 | troff8.s | │00265710 00 00 78 78 78 78 78 00-00 00 00 00 00 00 00 00 | xxxxx | │00265720 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 | | Now it could be that v7 troff is perfectly capable of generating the manual just like older troff would have, I just haven't dived more deeply into it all yet. I was more concerned about reconstructing the actual content rather than the exact looks for now, but it's still something i want to get right eventually. This didn't go through the list but I'll reply here: On 26/10/18, Ken Thompson wrote: > nice job. Thanks, You've always been an inspiration to me! aap

6 years, 7 months

Re: [TUHS] System III on 11/34 + rl02

by jnc＠mercury.lcs.mit.edu

> From: Jacob Ritorto > If this is true, I wonder why the install only offers rl01? Where does it say this? (I didn't search for that.) > I'm totally in the market for an Able Enable board too! Out of > zcuriosity, is it totally out of the question to just find the prints > and do a production run? Rotsa ruck! They're down the same mine as Jimmy Hoffa!! :-) But seriously, if you could find them, that would be fantastic. I've managed to collect (thanks Clem!) a tiny bit of info about them: http://gunkies.org/wiki/Able_ENABLE and I _think_ I've worked out how they worked, but more is better. We had a set of the prints at MIT BITD, but we didn't have the PROM/PLA/PAL/etc programming info, and one would need that too to reproduce them. > I sure hope there's a pdp11 sdcard / usb disk solution someday like they > did for the Commodore 64 So Dave Bridgham and I have been working on a QBUS card with an FPGA that uses an SD card to hold the bits, and emulates an RK11/RP11/etc controller. We have a wire-wrap prototype working (the RK11's done, the RP11 should be a short edit of that), and UNIX boots and runs. Now to turn it into PCB's... We've planned that the next step will be to do a UNIBUS version, which will also include ENABLE functionality (although it won't be plug compatible with an ENABLE, the memory will be on-board). Now to find the time/energy to make it happen... :-( Noel

6 years, 7 months

Re: [TUHS] Software Archeology: QED

by jnc＠mercury.lcs.mit.edu

> From: Noel Hunt > In addition to SINE, does anyone know what happened to EINE? Was replaced by ZWEI fairly early on. Zwei Was Eine Initially Dunno if it still exists on an MIT dump-tape somewhere. Noel

6 years, 7 months

Software Archeology: QED

by arnold＠skeeve.com

Hi All. I am starting to collect, if possible, different versions of the QED editor; with a hope to put up a git repo. If you have a tarball of code, please send it to me with as much info about it as you have. I would like to track down the qedbuf(1) man page also. I have contacted Rob Pike and got one tarball from him. I have another tarball that I got sometime in 1987 and have a promise of code coming Donald Mitchell. Much thanks! Arnold

6 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS