From will.senn at gmail.com Sat Aug 1 08:57:37 2020 From: will.senn at gmail.com (Will Senn) Date: Fri, 31 Jul 2020 17:57:37 -0500 Subject: [TUHS] Regular Expressions Message-ID: <6e9ca056-dfb0-376d-effd-e41c9ed3ef2a@gmail.com> I've always been intrigued with regexes. When I was first exposed to them, I was mystified and lost in the greediness of matches. Now, I use them regularly, but still have trouble using them. I think it is because I don't really understand how they work. My question for y'all has to do with early unix. I have a copy of Thompson, K. (1968). Regular expression search algorithm. Communications of the ACM, 11(6), 419-422. It is interesting as an example of Thompson's thinking about regexes. In this paper, he presents a non-backtracking, efficient, algorithm for converting a regex into an IBM 7094 (whatever that is) program that can be run against text input that generates matches. It's cool. It got me to thinking maybe the way to understand the unix regex lies in a careful investigation into how it is implemented (original thought, right?). So, here I am again to ask your indulgence as the latecomer wannabe unix apprentice. My thought is that ed is where it begins and might be a good starting point, but I'm not sure - what say y'all? I also have a copy of the O'Reilly Mastering Regular Expressions book, but that's not really the kind of thing I'm talking about. My question is more basic than how to use regexes practically. I would like to understand them at a parsing level/state change level (not sure that's the correct way to say it, but I'm really new to this kind of lingo).  When I'm done with my stepping through the source, I want to be able to reason that this is why that search matched that text and not this text and why the search was greedy, or not greedy because of this logic here... If my question above isn't focused or on topic enough, here's an alternative set to ruminate on and hopefully discuss: 1. What's the provenance of regex in unix (when did it appear, in what form, etc)? 2. What are the 'best' implementations throughout unix (keep it pre 1980s)? 3. What are some of the milestones along the way (major changes, forks, disagreements)? 4. Where, in the source, or in a paper, would you point someone to wanting to better understand the mechanics of regex? Thanks! Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Aug 1 09:02:27 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 1 Aug 2020 09:02:27 +1000 (EST) Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> Message-ID: On Mon, 20 Jul 2020, John Cowan wrote: > I remember reading about something like that, though it's not connected > in my mind with A/UX.  What I do remember is that you had to type "Ls" > to pop up the options window: After all, most of the time you don't > *want* options for  "ls".  On a text terminal, the top half of the > screen became the options window; its scrolling content was restored > when the window was dismissed. I'm glad that it was sort of optional, otherwise it would annoy the hell out of me. SMIT was quite nice although; although it was a GUI (which I loathe), at least it displayed the command that was run as a result (which was just as well!) so you could type it yourself if you liked. -- Dave From rich.salz at gmail.com Sat Aug 1 09:12:57 2020 From: rich.salz at gmail.com (Richard Salz) Date: Fri, 31 Jul 2020 19:12:57 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> Message-ID: > SMIT was quite nice i have never seen those four words together like that before. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sat Aug 1 10:00:23 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 31 Jul 2020 20:00:23 -0400 (EDT) Subject: [TUHS] Regular Expressions Message-ID: <20200801000023.3CF0818C0C0@mercury.lcs.mit.edu> > From: Will Senn > I don't really understand how they work. > ... > maybe the way to understand the unix regex lies in a careful > investigation into how it is implemented I'm not sure what I did, but it wasn't the latter, since I have no idea how they are done! I just mentally break the regex search string up into substrings (I use them most in Epsilon, which has syntax to do substrings of search strings, which helps a lot); past that, I think it's just using them and getting used to them. > an IBM 7094 (whatever that is) IBM's last 36-bit scientific mainframe before the System/360's. CTSS (which DMR held out as the ancestor of Unix) ran on 7094's. Noel From bakul at iitbombay.org Sat Aug 1 10:01:56 2020 From: bakul at iitbombay.org (Bakul Shah) Date: Fri, 31 Jul 2020 17:01:56 -0700 Subject: [TUHS] Regular Expressions In-Reply-To: <6e9ca056-dfb0-376d-effd-e41c9ed3ef2a@gmail.com> References: <6e9ca056-dfb0-376d-effd-e41c9ed3ef2a@gmail.com> Message-ID: <402F66B1-12C1-4FED-89FD-38AB99D919B4@iitbombay.org> On Jul 31, 2020, at 3:57 PM, Will Senn wrote: > > I've always been intrigued with regexes. When I was first exposed to them, I was mystified and lost in the greediness of matches. Now, I use them regularly, but still have trouble using them. I think it is because I don't really understand how they work. > ... > 1. What's the provenance of regex in unix (when did it appear, in what form, etc)? > 2. What are the 'best' implementations throughout unix (keep it pre 1980s)? > 3. What are some of the milestones along the way (major changes, forks, disagreements)? > 4. Where, in the source, or in a paper, would you point someone to wanting to better understand the mechanics of regex? Start here: https://en.wikipedia.org/wiki/Thompson%27s_construction [I learned about regular expressions in an automata theory class, before I knew anything about Unix. What helped me was learning about finite state machines. You won't need more than paper and pencil to construct one. Reading source code would make more sense once you grasp how to construct a FSM corresponding to a RE.] From grog at lemis.com Sat Aug 1 10:12:07 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sat, 1 Aug 2020 10:12:07 +1000 Subject: [TUHS] BSDI git repo? In-Reply-To: References: Message-ID: <20200801001207.GT1032@eureka.lemis.com> On Friday, 31 July 2020 at 10:05:55 +0100, Steve Mynott wrote: > Is there full bsdi git repo anywhere? > > I've vague recollections parts were merged into FreeBSD in the early > 2000s so I assume it was open sourced? From June to September 2000 (exactly 20 years ago) I merged some parts of BSD/OS 5.0 into FreeBSD version 4, releasing it as FreeBSD 5.0. This was part of an agreement (obviously) with BSDI to improve FreeBSD's SMP processing. For this purpose I received three source trees, labeled 4.1-RELEASE, 4.1 and 5.0-smp-devel. I still have them, and as far as I can see they're complete. Clearly they weren't maintained under git, since it didn't exist yet. The headers suggest RCS or (probably) CVS. For example: * BSDI exec_elf.c,v 1.7 1998/08/24 19:03:08 torek Exp * BSDI kern_fork.c,v 2.10 1999/04/20 22:40:19 cp Exp None of this was "open sourced"; we were allowed to use it for this specific purpose. But if you can get approval from the copyright owners, I'll happily give you a copy. You might also be interested in my report of the meeting which set this off, at http://www.lemis.com/grog/diary-jun2000.php#15 In passing, it was an interesting experience. Both BSD/OS and FreeBSD derived from (most recently) 4.4BSD Lite, but they had diverged to a point where it was really painful to merge the code. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From robpike at gmail.com Sat Aug 1 10:36:48 2020 From: robpike at gmail.com (Rob Pike) Date: Sat, 1 Aug 2020 10:36:48 +1000 Subject: [TUHS] Regular Expressions In-Reply-To: <402F66B1-12C1-4FED-89FD-38AB99D919B4@iitbombay.org> References: <6e9ca056-dfb0-376d-effd-e41c9ed3ef2a@gmail.com> <402F66B1-12C1-4FED-89FD-38AB99D919B4@iitbombay.org> Message-ID: I think this link - https://swtch.com/~rsc/regexp/regexp1.html i- s the best place to start. Superb exposition on the background, theory, and implementation as well as a bit of history of how the industry lost its way with regular expressions. Regular expressions are beautiful, simple, and widely misunderstood. -rob On Sat, Aug 1, 2020 at 10:03 AM Bakul Shah wrote: > On Jul 31, 2020, at 3:57 PM, Will Senn wrote: > > > > I've always been intrigued with regexes. When I was first exposed to > them, I was mystified and lost in the greediness of matches. Now, I use > them regularly, but still have trouble using them. I think it is because I > don't really understand how they work. > > ... > > 1. What's the provenance of regex in unix (when did it appear, in what > form, etc)? > > 2. What are the 'best' implementations throughout unix (keep it pre > 1980s)? > > 3. What are some of the milestones along the way (major changes, forks, > disagreements)? > > 4. Where, in the source, or in a paper, would you point someone to > wanting to better understand the mechanics of regex? > > Start here: https://en.wikipedia.org/wiki/Thompson%27s_construction > > [I learned about regular expressions in an automata theory class, > before I knew anything about Unix. What helped me was learning > about finite state machines. You won't need more than paper and > pencil to construct one. Reading source code would make more > sense once you grasp how to construct a FSM corresponding to a RE.] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpl.jpl at gmail.com Sat Aug 1 10:53:43 2020 From: jpl.jpl at gmail.com (John P. Linderman) Date: Fri, 31 Jul 2020 20:53:43 -0400 Subject: [TUHS] Regular Expressions In-Reply-To: References: <6e9ca056-dfb0-376d-effd-e41c9ed3ef2a@gmail.com> <402F66B1-12C1-4FED-89FD-38AB99D919B4@iitbombay.org> Message-ID: Hear hear. And I think it should be possible to analyze regular expressions to determine if "simple" (hence fast) regexps are adequate. "Fancy" re's are rare. At least from those of us where they couldn't be expressed. On Fri, Jul 31, 2020 at 8:38 PM Rob Pike wrote: > I think this link - https://swtch.com/~rsc/regexp/regexp1.html i- s the > best place to start. Superb exposition on the background, theory, and > implementation as well as a bit of history of how the industry lost its way > with regular expressions. > > Regular expressions are beautiful, simple, and widely misunderstood. > > -rob > > > On Sat, Aug 1, 2020 at 10:03 AM Bakul Shah wrote: > >> On Jul 31, 2020, at 3:57 PM, Will Senn wrote: >> > >> > I've always been intrigued with regexes. When I was first exposed to >> them, I was mystified and lost in the greediness of matches. Now, I use >> them regularly, but still have trouble using them. I think it is because I >> don't really understand how they work. >> > ... >> > 1. What's the provenance of regex in unix (when did it appear, in what >> form, etc)? >> > 2. What are the 'best' implementations throughout unix (keep it pre >> 1980s)? >> > 3. What are some of the milestones along the way (major changes, forks, >> disagreements)? >> > 4. Where, in the source, or in a paper, would you point someone to >> wanting to better understand the mechanics of regex? >> >> Start here: https://en.wikipedia.org/wiki/Thompson%27s_construction >> >> [I learned about regular expressions in an automata theory class, >> before I knew anything about Unix. What helped me was learning >> about finite state machines. You won't need more than paper and >> pencil to construct one. Reading source code would make more >> sense once you grasp how to construct a FSM corresponding to a RE.] > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Sat Aug 1 11:31:39 2020 From: bakul at iitbombay.org (Bakul Shah) Date: Fri, 31 Jul 2020 18:31:39 -0700 Subject: [TUHS] Regular Expressions In-Reply-To: References: <6e9ca056-dfb0-376d-effd-e41c9ed3ef2a@gmail.com> <402F66B1-12C1-4FED-89FD-38AB99D919B4@iitbombay.org> Message-ID: <3D47666B-BF70-4810-9D43-CAE16E44F25D@iitbombay.org> I was trying to get Will to try simple stuff out himself from first principles (to get started) but this is of course far better! > On Jul 31, 2020, at 5:36 PM, Rob Pike wrote: > > I think this link - https://swtch.com/~rsc/regexp/regexp1.html i- s the best place to start. Superb exposition on the background, theory, and implementation as well as a bit of history of how the industry lost its way with regular expressions. > > Regular expressions are beautiful, simple, and widely misunderstood. > > -rob > > > On Sat, Aug 1, 2020 at 10:03 AM Bakul Shah > wrote: > On Jul 31, 2020, at 3:57 PM, Will Senn > wrote: > > > > I've always been intrigued with regexes. When I was first exposed to them, I was mystified and lost in the greediness of matches. Now, I use them regularly, but still have trouble using them. I think it is because I don't really understand how they work. > > ... > > 1. What's the provenance of regex in unix (when did it appear, in what form, etc)? > > 2. What are the 'best' implementations throughout unix (keep it pre 1980s)? > > 3. What are some of the milestones along the way (major changes, forks, disagreements)? > > 4. Where, in the source, or in a paper, would you point someone to wanting to better understand the mechanics of regex? > > Start here: https://en.wikipedia.org/wiki/Thompson%27s_construction > > [I learned about regular expressions in an automata theory class, > before I knew anything about Unix. What helped me was learning > about finite state machines. You won't need more than paper and > pencil to construct one. Reading source code would make more > sense once you grasp how to construct a FSM corresponding to a RE.] -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Aug 1 11:36:05 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 31 Jul 2020 18:36:05 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> Message-ID: <20200801013605.GG10778@mcvoy.com> On Fri, Jul 31, 2020 at 07:12:57PM -0400, Richard Salz wrote: > > SMIT was quite nice > > i have never seen those four words together like that before. Me neither. SMIT was HORRIBLE if you understood the files in /etc and knew what to do with them. It might be nice if you had no understanding of how to admin a Unix system and here is this "nice" curses based way to do admin. To anyone remotely competent, and I don't mean edit sendmail.cf, I mean you can edit inetd.conf, you can edit a crontab file, etc, SMIT was a nightmare that made something that should be vi $FILE, done 20 seconds later, a hellish journey through their menus. It was AWFUL. Ask me how I know. --lm From lm at mcvoy.com Sat Aug 1 11:39:54 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 31 Jul 2020 18:39:54 -0700 Subject: [TUHS] Regular Expressions In-Reply-To: References: <6e9ca056-dfb0-376d-effd-e41c9ed3ef2a@gmail.com> <402F66B1-12C1-4FED-89FD-38AB99D919B4@iitbombay.org> Message-ID: <20200801013954.GH10778@mcvoy.com> That link is a great read. On Sat, Aug 01, 2020 at 10:36:48AM +1000, Rob Pike wrote: > I think this link - https://swtch.com/~rsc/regexp/regexp1.html i- s the > best place to start. Superb exposition on the background, theory, and > implementation as well as a bit of history of how the industry lost its way > with regular expressions. > > Regular expressions are beautiful, simple, and widely misunderstood. > > -rob > > > On Sat, Aug 1, 2020 at 10:03 AM Bakul Shah wrote: > > > On Jul 31, 2020, at 3:57 PM, Will Senn wrote: > > > > > > I've always been intrigued with regexes. When I was first exposed to > > them, I was mystified and lost in the greediness of matches. Now, I use > > them regularly, but still have trouble using them. I think it is because I > > don't really understand how they work. > > > ... > > > 1. What's the provenance of regex in unix (when did it appear, in what > > form, etc)? > > > 2. What are the 'best' implementations throughout unix (keep it pre > > 1980s)? > > > 3. What are some of the milestones along the way (major changes, forks, > > disagreements)? > > > 4. Where, in the source, or in a paper, would you point someone to > > wanting to better understand the mechanics of regex? > > > > Start here: https://en.wikipedia.org/wiki/Thompson%27s_construction > > > > [I learned about regular expressions in an automata theory class, > > before I knew anything about Unix. What helped me was learning > > about finite state machines. You won't need more than paper and > > pencil to construct one. Reading source code would make more > > sense once you grasp how to construct a FSM corresponding to a RE.] -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From will.senn at gmail.com Sat Aug 1 12:33:39 2020 From: will.senn at gmail.com (Will Senn) Date: Fri, 31 Jul 2020 21:33:39 -0500 Subject: [TUHS] Regular Expressions In-Reply-To: References: <6e9ca056-dfb0-376d-effd-e41c9ed3ef2a@gmail.com> <402F66B1-12C1-4FED-89FD-38AB99D919B4@iitbombay.org> Message-ID: Yes, I googled it per Clem's suggestion and wound up on that exact link after wandering around admiring the scenery. I envy the more mathematically inclined among us their view of matters technical. This piece, being in C and having step by step articulation of the diagrams, is better for me than the more formal wikipedia article, although, when I get enough background, that looks like it'll be good, too. Thanks Rob, Clem and Bakul. Will On 7/31/20 7:36 PM, Rob Pike wrote: > I think this link - https://swtch.com/~rsc/regexp/regexp1.html i- s > the best place to start. Superb exposition on the background, theory, > and implementation as well as a bit of history of how the industry > lost its way with regular expressions. > > Regular expressions are beautiful, simple, and widely misunderstood. > > -rob > > > On Sat, Aug 1, 2020 at 10:03 AM Bakul Shah > wrote: > > On Jul 31, 2020, at 3:57 PM, Will Senn > wrote: > > > > I've always been intrigued with regexes. When I was first > exposed to them, I was mystified and lost in the greediness of > matches. Now, I use them regularly, but still have trouble using > them. I think it is because I don't really understand how they work. > > ... > > 1. What's the provenance of regex in unix (when did it appear, > in what form, etc)? > > 2. What are the 'best' implementations throughout unix (keep it > pre 1980s)? > > 3. What are some of the milestones along the way (major changes, > forks, disagreements)? > > 4. Where, in the source, or in a paper, would you point someone > to wanting to better understand the mechanics of regex? > > Start here: https://en.wikipedia.org/wiki/Thompson%27s_construction > > [I learned about regular expressions in an automata theory class, >  before I knew anything about Unix. What helped me was learning >  about finite state machines. You won't need more than paper and >  pencil to construct one. Reading source code would make more >  sense once you grasp how to construct a FSM corresponding to a RE.] > -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Sat Aug 1 12:50:57 2020 From: rdm at cfcl.com (Rich Morin) Date: Fri, 31 Jul 2020 19:50:57 -0700 Subject: [TUHS] Regular Expressions In-Reply-To: References: <6e9ca056-dfb0-376d-effd-e41c9ed3ef2a@gmail.com> <402F66B1-12C1-4FED-89FD-38AB99D919B4@iitbombay.org> Message-ID: You might want to pick up a used copy of this book, if only as an occasional resource: https://www.amazon.com/Mastering-Regular-Expressions-Jeffrey-Friedl/dp/0596528124 -r From lm at mcvoy.com Sat Aug 1 13:01:13 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 31 Jul 2020 20:01:13 -0700 Subject: [TUHS] Regular Expressions In-Reply-To: References: <6e9ca056-dfb0-376d-effd-e41c9ed3ef2a@gmail.com> <402F66B1-12C1-4FED-89FD-38AB99D919B4@iitbombay.org> Message-ID: <20200801030113.GL10778@mcvoy.com> I was a fan of this: http://www.cse.yorku.ca/~oz/regex.bun my employees moved me to PCRE at some point but OZ has a talent for writing really small implementations of useful stuff. Very early Unix like. On Fri, Jul 31, 2020 at 07:50:57PM -0700, Rich Morin wrote: > You might want to pick up a used copy of this book, if only as an occasional resource: > > https://www.amazon.com/Mastering-Regular-Expressions-Jeffrey-Friedl/dp/0596528124 > > -r -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From will.senn at gmail.com Sat Aug 1 13:07:09 2020 From: will.senn at gmail.com (Will Senn) Date: Fri, 31 Jul 2020 22:07:09 -0500 Subject: [TUHS] Regular Expressions In-Reply-To: References: <6e9ca056-dfb0-376d-effd-e41c9ed3ef2a@gmail.com> <402F66B1-12C1-4FED-89FD-38AB99D919B4@iitbombay.org> Message-ID: <50453bb3-af58-043d-07f5-cedb14e4224b@gmail.com> Oh, and one good google over another, I also found this: https://www.drdobbs.com/architecture-and-design/regular-expressions/184410904 Which is also great and simple to follow :). Will On 7/31/20 7:36 PM, Rob Pike wrote: > I think this link - https://swtch.com/~rsc/regexp/regexp1.html i- s > the best place to start. Superb exposition on the background, theory, > and implementation as well as a bit of history of how the industry > lost its way with regular expressions. > > Regular expressions are beautiful, simple, and widely misunderstood. > > -rob > > > On Sat, Aug 1, 2020 at 10:03 AM Bakul Shah > wrote: > > On Jul 31, 2020, at 3:57 PM, Will Senn > wrote: > > > > I've always been intrigued with regexes. When I was first > exposed to them, I was mystified and lost in the greediness of > matches. Now, I use them regularly, but still have trouble using > them. I think it is because I don't really understand how they work. > > ... > > 1. What's the provenance of regex in unix (when did it appear, > in what form, etc)? > > 2. What are the 'best' implementations throughout unix (keep it > pre 1980s)? > > 3. What are some of the milestones along the way (major changes, > forks, disagreements)? > > 4. Where, in the source, or in a paper, would you point someone > to wanting to better understand the mechanics of regex? > > Start here: https://en.wikipedia.org/wiki/Thompson%27s_construction > > [I learned about regular expressions in an automata theory class, >  before I knew anything about Unix. What helped me was learning >  about finite state machines. You won't need more than paper and >  pencil to construct one. Reading source code would make more >  sense once you grasp how to construct a FSM corresponding to a RE.] > -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From earl.baugh at gmail.com Sat Aug 1 14:31:00 2020 From: earl.baugh at gmail.com (Earl Baugh) Date: Sat, 1 Aug 2020 00:31:00 -0400 Subject: [TUHS] Regular Expressions In-Reply-To: <50453bb3-af58-043d-07f5-cedb14e4224b@gmail.com> References: <50453bb3-af58-043d-07f5-cedb14e4224b@gmail.com> Message-ID: <763C08F0-0AF5-48B8-988A-3D417CB0E3FA@gmail.com> I have a 30k+ character regex that I used to parse US street addresses from a single line of input into component pieces. That’s the largest ( and yes it was crazy... but it just grew and grew...and made sense to me as I decomposed the problem ). That’s the largest one I ever saw.... and it was the fastest way I could solve the problem.. both mentally and processing wise. ( there was some post processing to deal with soundex matching and data base matching of the pieces to confirm the right answer. But it solved the problem with 95%+ accuracy... that I got into the high 99%’s with the post processing. ) So that’s at least an example of an arbitrary problem that was solved with regex. Earl Sent from my iPhone > On Jul 31, 2020, at 11:08 PM, Will Senn wrote: > >  > Oh, and one good google over another, I also found this: > > https://www.drdobbs.com/architecture-and-design/regular-expressions/184410904 > > Which is also great and simple to follow :). > > Will > >> On 7/31/20 7:36 PM, Rob Pike wrote: >> I think this link - https://swtch.com/~rsc/regexp/regexp1.html i- s the best place to start. Superb exposition on the background, theory, and implementation as well as a bit of history of how the industry lost its way with regular expressions. >> >> Regular expressions are beautiful, simple, and widely misunderstood. >> >> -rob >> >> >> On Sat, Aug 1, 2020 at 10:03 AM Bakul Shah wrote: >>> On Jul 31, 2020, at 3:57 PM, Will Senn wrote: >>> > >>> > I've always been intrigued with regexes. When I was first exposed to them, I was mystified and lost in the greediness of matches. Now, I use them regularly, but still have trouble using them. I think it is because I don't really understand how they work. >>> > ... >>> > 1. What's the provenance of regex in unix (when did it appear, in what form, etc)? >>> > 2. What are the 'best' implementations throughout unix (keep it pre 1980s)? >>> > 3. What are some of the milestones along the way (major changes, forks, disagreements)? >>> > 4. Where, in the source, or in a paper, would you point someone to wanting to better understand the mechanics of regex? >>> >>> Start here: https://en.wikipedia.org/wiki/Thompson%27s_construction >>> >>> [I learned about regular expressions in an automata theory class, >>> before I knew anything about Unix. What helped me was learning >>> about finite state machines. You won't need more than paper and >>> pencil to construct one. Reading source code would make more >>> sense once you grasp how to construct a FSM corresponding to a RE.] > > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Sat Aug 1 14:53:00 2020 From: rminnich at gmail.com (ron minnich) Date: Fri, 31 Jul 2020 21:53:00 -0700 Subject: [TUHS] Regular Expressions In-Reply-To: <763C08F0-0AF5-48B8-988A-3D417CB0E3FA@gmail.com> References: <50453bb3-af58-043d-07f5-cedb14e4224b@gmail.com> <763C08F0-0AF5-48B8-988A-3D417CB0E3FA@gmail.com> Message-ID: kernighan did this one at a talk at udel in 1976: find all the words in the dictionary that you can see on a calculator looking at it upside down. On Fri, Jul 31, 2020 at 9:32 PM Earl Baugh wrote: > > I have a 30k+ character regex that I used to parse US street addresses from a single line of input into component pieces. That’s the largest ( and yes it was crazy... but it just grew and grew...and made sense to me as I decomposed the problem ). That’s the largest one I ever saw.... and it was the fastest way I could solve the problem.. both mentally and processing wise. > > ( there was some post processing to deal with soundex matching and data base matching of the pieces to confirm the right answer. But it solved the problem with 95%+ accuracy... that I got into the high 99%’s with the post processing. ) > > So that’s at least an example of an arbitrary problem that was solved with regex. > > Earl > > > Sent from my iPhone > > On Jul 31, 2020, at 11:08 PM, Will Senn wrote: > >  > Oh, and one good google over another, I also found this: > > https://www.drdobbs.com/architecture-and-design/regular-expressions/184410904 > > Which is also great and simple to follow :). > > Will > > On 7/31/20 7:36 PM, Rob Pike wrote: > > I think this link - https://swtch.com/~rsc/regexp/regexp1.html i- s the best place to start. Superb exposition on the background, theory, and implementation as well as a bit of history of how the industry lost its way with regular expressions. > > Regular expressions are beautiful, simple, and widely misunderstood. > > -rob > > > On Sat, Aug 1, 2020 at 10:03 AM Bakul Shah wrote: >> >> On Jul 31, 2020, at 3:57 PM, Will Senn wrote: >> > >> > I've always been intrigued with regexes. When I was first exposed to them, I was mystified and lost in the greediness of matches. Now, I use them regularly, but still have trouble using them. I think it is because I don't really understand how they work. >> > ... >> > 1. What's the provenance of regex in unix (when did it appear, in what form, etc)? >> > 2. What are the 'best' implementations throughout unix (keep it pre 1980s)? >> > 3. What are some of the milestones along the way (major changes, forks, disagreements)? >> > 4. Where, in the source, or in a paper, would you point someone to wanting to better understand the mechanics of regex? >> >> Start here: https://en.wikipedia.org/wiki/Thompson%27s_construction >> >> [I learned about regular expressions in an automata theory class, >> before I knew anything about Unix. What helped me was learning >> about finite state machines. You won't need more than paper and >> pencil to construct one. Reading source code would make more >> sense once you grasp how to construct a FSM corresponding to a RE.] > > > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF From andrew at humeweb.com Sat Aug 1 15:48:02 2020 From: andrew at humeweb.com (Andrew Hume) Date: Fri, 31 Jul 2020 22:48:02 -0700 Subject: [TUHS] Regular Expressions In-Reply-To: <6e9ca056-dfb0-376d-effd-e41c9ed3ef2a@gmail.com> References: <6e9ca056-dfb0-376d-effd-e41c9ed3ef2a@gmail.com> Message-ID: <88FBBEDA-3D60-4782-9C4B-43C64691BC35@humeweb.com> during the mid 80s, i was preparing one of the first invited talks for USENIX on the subject of regular expressions. i had concocted a massive RE that matched all the known spellings of saddam hussein. (it was complicated, and there were many different romanizations active at the time.) dennis ritchie wandered into the unix room and asked what it was and then immediately applied it to our somewhat newish AP news wire feed. it matched two new spellings!! From meillo at marmaro.de Sat Aug 1 17:14:36 2020 From: meillo at marmaro.de (markus schnalke) Date: Sat, 01 Aug 2020 09:14:36 +0200 Subject: [TUHS] Dennis Ritchie's Dissertation In-Reply-To: References: <202007310003.06V03OoV073870@chez.mckusick.com> Message-ID: <1k1lj2-7nP-00@marmaro.de> Hoi. [2020-07-30 20:30] Dan Cross > > I understood from Mike Anshel that he was rather proud of this, [...] I once read that someone is famous when people omit the titles, because they add nothing to the name, but rather would smaller it. A good example is Albert Einstein. Who cares what titles he has. Another is Dennis Ritchie. What does it matter what degrees, titles, whatever he has? -- He's already a genius! meillo From dave at horsfall.org Sat Aug 1 17:54:34 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 1 Aug 2020 17:54:34 +1000 (EST) Subject: [TUHS] vi in v7 In-Reply-To: References: Message-ID: On Sat, 25 Jul 2020, Warner Losh wrote: > Weren't V5/6/7/etc distributed as bootable tapes?  Set the switch > register to point to the tape instead of the disk... > > Yes. They were. We have V6 and V7 tapes (and a V5 disk image). Likely > earlier versions likely did too.  What I'd meant was that 2.8BSD is the > first 2BSD that had a bootable tape. Ah, my mistake. I think the loader also read just the first block, so woe betide you if you used a labelled tape... If I recall, VOL1, HDR1, etc. -- Dave From clemc at ccc.com Sat Aug 1 22:15:39 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 1 Aug 2020 08:15:39 -0400 Subject: [TUHS] vi in v7 In-Reply-To: References: Message-ID: Dave those are ANSI tape labels. Unix does not use them DEC did although was inconsistent with the use particularly WRT HDR2 records. Tom Quarles (of spice 3 fame) wrote probably the best version for Unix to deal with them. I believe I gave a copy but it will be in BSD 4.1 maybe 4.2 compiler syntax. I'll ask him if he ever updated it. Clem On Sat, Aug 1, 2020 at 3:55 AM Dave Horsfall wrote: > On Sat, 25 Jul 2020, Warner Losh wrote: > > > Weren't V5/6/7/etc distributed as bootable tapes? Set the switch > > register to point to the tape instead of the disk... > > > > Yes. They were. We have V6 and V7 tapes (and a V5 disk image). Likely > > earlier versions likely did too. What I'd meant was that 2.8BSD is the > > first 2BSD that had a bootable tape. > > Ah, my mistake. > > I think the loader also read just the first block, so woe betide you if > you used a labelled tape... > > If I recall, VOL1, HDR1, etc. > > -- Dave -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Sat Aug 1 23:31:55 2020 From: rich.salz at gmail.com (Richard Salz) Date: Sat, 1 Aug 2020 09:31:55 -0400 Subject: [TUHS] Regular Expressions In-Reply-To: <88FBBEDA-3D60-4782-9C4B-43C64691BC35@humeweb.com> References: <6e9ca056-dfb0-376d-effd-e41c9ed3ef2a@gmail.com> <88FBBEDA-3D60-4782-9C4B-43C64691BC35@humeweb.com> Message-ID: > during the mid 80s, i was preparing one of the first invited talks for > USENIX on the subject of regular expressions. > i had concocted a massive RE that matched all the known spellings of > saddam hussein. (it was complicated, > I wonder if that was the inspiration for the Qaddafi torture test; see http://sources.vsta.org/comp.sources.unix/volume9/fastgrep/part01 (June 87) The first time I saw "p[-1]" was looking at some regexp source. It blew/expanded my mind. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at humeweb.com Sat Aug 1 23:43:32 2020 From: andrew at humeweb.com (Andrew Hume) Date: Sat, 1 Aug 2020 06:43:32 -0700 Subject: [TUHS] Regular Expressions In-Reply-To: References: <6e9ca056-dfb0-376d-effd-e41c9ed3ef2a@gmail.com> <88FBBEDA-3D60-4782-9C4B-43C64691BC35@humeweb.com> Message-ID: <7A255575-3989-4869-88F8-762EA1875086@humeweb.com> i apologise. i was in fact referring to the qaddafi torture test (another victim of my stroke). thanks to rich for catching that slip. > On Aug 1, 2020, at 6:31 AM, Richard Salz wrote: > > > during the mid 80s, i was preparing one of the first invited talks for USENIX on the subject of regular expressions. > i had concocted a massive RE that matched all the known spellings of saddam hussein. (it was complicated, > > I wonder if that was the inspiration for the Qaddafi torture test; see http://sources.vsta.org/comp.sources.unix/volume9/fastgrep/part01 (June 87) > > The first time I saw "p[-1]" was looking at some regexp source. It blew/expanded my mind. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Aug 2 00:13:10 2020 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 1 Aug 2020 07:13:10 -0700 Subject: [TUHS] Dennis Ritchie's Dissertation In-Reply-To: <1k1lj2-7nP-00@marmaro.de> References: <202007310003.06V03OoV073870@chez.mckusick.com> <1k1lj2-7nP-00@marmaro.de> Message-ID: <20200801141310.GQ10778@mcvoy.com> On Sat, Aug 01, 2020 at 09:14:36AM +0200, markus schnalke wrote: > Hoi. > > [2020-07-30 20:30] Dan Cross > > > > I understood from Mike Anshel that he was rather proud of this, [...] > > I once read that someone is famous when people omit the titles, > because they add nothing to the name, but rather would smaller it. > A good example is Albert Einstein. Who cares what titles he has. > > Another is Dennis Ritchie. What does it matter what degrees, titles, > whatever he has? -- He's already a genius! My dad wasn't famous, but he had a PhD in physics. He never asked people to call him Dr McVoy. As we grew up and realized he could be called that we asked him why not. He said it sounds fancy, the only time he used it was when he wanted a table at a crowded restaurant (which was very rare, Madison didn't pay him very well). Somehow that stuck with me and I've always been sort of wary of people who use their title. The people I admire never did. Someone on the list said that they thought Dennis wouldn't appreciate it if we got his PhD official. I couldn't put my finger on it at the time, but I agreed. And I think it is because the people who are really great don't need or want the fancy title. I may be over thinking it, but Dennis does not need the title, it does nothing to make his legacy better, his legacy is way way more than that title. Which is a long ramble to say I agree with Markus. From imp at bsdimp.com Sun Aug 2 00:33:20 2020 From: imp at bsdimp.com (Warner Losh) Date: Sat, 1 Aug 2020 08:33:20 -0600 Subject: [TUHS] vi in v7 In-Reply-To: References: Message-ID: On Sat, Aug 1, 2020, 6:16 AM Clem Cole wrote: > Dave those are ANSI tape labels. Unix does not use them DEC did > although was inconsistent with the use particularly WRT HDR2 records. Tom > Quarles (of spice 3 fame) wrote probably the best version for Unix to deal > with them. I believe I gave a copy but it will be in BSD 4.1 maybe 4.2 > compiler syntax. I'll ask him if he ever updated it. Clem > How is that related to ansitar.c? Warner On Sat, Aug 1, 2020 at 3:55 AM Dave Horsfall wrote: > >> On Sat, 25 Jul 2020, Warner Losh wrote: >> >> > Weren't V5/6/7/etc distributed as bootable tapes? Set the switch >> > register to point to the tape instead of the disk... >> > >> > Yes. They were. We have V6 and V7 tapes (and a V5 disk image). Likely >> > earlier versions likely did too. What I'd meant was that 2.8BSD is the >> > first 2BSD that had a bootable tape. >> >> Ah, my mistake. >> >> I think the loader also read just the first block, so woe betide you if >> you used a labelled tape... >> >> If I recall, VOL1, HDR1, etc. >> >> -- Dave > > -- > Sent from a handheld expect more typos than usual > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpl.jpl at gmail.com Sun Aug 2 01:08:30 2020 From: jpl.jpl at gmail.com (John P. Linderman) Date: Sat, 1 Aug 2020 11:08:30 -0400 Subject: [TUHS] Dennis Ritchie's Dissertation In-Reply-To: <20200801141310.GQ10778@mcvoy.com> References: <202007310003.06V03OoV073870@chez.mckusick.com> <1k1lj2-7nP-00@marmaro.de> <20200801141310.GQ10778@mcvoy.com> Message-ID: The use of honorifics was subtly discouraged at the Labs. I never saw a policy statement, but nobody I knew used "Dr" (except those in the medical department), even though the place was crawling with doctoral degrees. On Sat, Aug 1, 2020 at 10:14 AM Larry McVoy wrote: > On Sat, Aug 01, 2020 at 09:14:36AM +0200, markus schnalke wrote: > > Hoi. > > > > [2020-07-30 20:30] Dan Cross > > > > > > I understood from Mike Anshel that he was rather proud of this, [...] > > > > I once read that someone is famous when people omit the titles, > > because they add nothing to the name, but rather would smaller it. > > A good example is Albert Einstein. Who cares what titles he has. > > > > Another is Dennis Ritchie. What does it matter what degrees, titles, > > whatever he has? -- He's already a genius! > > My dad wasn't famous, but he had a PhD in physics. He never asked people > to call him Dr McVoy. As we grew up and realized he could be called that > we asked him why not. He said it sounds fancy, the only time he used it > was when he wanted a table at a crowded restaurant (which was very rare, > Madison didn't pay him very well). > > Somehow that stuck with me and I've always been sort of wary of people > who use their title. The people I admire never did. > > Someone on the list said that they thought Dennis wouldn't appreciate > it if we got his PhD official. I couldn't put my finger on it at the > time, but I agreed. And I think it is because the people who are really > great don't need or want the fancy title. I may be over thinking it, > but Dennis does not need the title, it does nothing to make his legacy > better, his legacy is way way more than that title. > > Which is a long ramble to say I agree with Markus. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Aug 2 01:41:55 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 1 Aug 2020 11:41:55 -0400 Subject: [TUHS] vi in v7 In-Reply-To: References: Message-ID: Not that I know of. Tom's was called ansitape. On Sat, Aug 1, 2020 at 10:33 AM Warner Losh wrote: > > > On Sat, Aug 1, 2020, 6:16 AM Clem Cole wrote: > >> Dave those are ANSI tape labels. Unix does not use them DEC did >> although was inconsistent with the use particularly WRT HDR2 records. Tom >> Quarles (of spice 3 fame) wrote probably the best version for Unix to deal >> with them. I believe I gave a copy but it will be in BSD 4.1 maybe 4.2 >> compiler syntax. I'll ask him if he ever updated it. Clem >> > > How is that related to ansitar.c? > > Warner > > On Sat, Aug 1, 2020 at 3:55 AM Dave Horsfall wrote: >> >>> On Sat, 25 Jul 2020, Warner Losh wrote: >>> >>> > Weren't V5/6/7/etc distributed as bootable tapes? Set the switch >>> > register to point to the tape instead of the disk... >>> > >>> > Yes. They were. We have V6 and V7 tapes (and a V5 disk image). Likely >>> > earlier versions likely did too. What I'd meant was that 2.8BSD is >>> the >>> > first 2BSD that had a bootable tape. >>> >>> Ah, my mistake. >>> >>> I think the loader also read just the first block, so woe betide you if >>> you used a labelled tape... >>> >>> If I recall, VOL1, HDR1, etc. >>> >>> -- Dave >> >> -- >> Sent from a handheld expect more typos than usual >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Sun Aug 2 02:08:54 2020 From: cym224 at gmail.com (Nemo Nusquam) Date: Sat, 1 Aug 2020 12:08:54 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <20200801013605.GG10778@mcvoy.com> References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> Message-ID: On 07/31/20 21:36, Larry McVoy wrote (in part): > Me neither. SMIT was HORRIBLE [...] Hhmmm... I am reminded of the appendix "In defense of AIX" in Nemeth et alii. From crossd at gmail.com Sun Aug 2 02:43:06 2020 From: crossd at gmail.com (Dan Cross) Date: Sat, 1 Aug 2020 12:43:06 -0400 Subject: [TUHS] Dennis Ritchie's Dissertation In-Reply-To: References: <202007310003.06V03OoV073870@chez.mckusick.com> <1k1lj2-7nP-00@marmaro.de> <20200801141310.GQ10778@mcvoy.com> Message-ID: On Sat, Aug 1, 2020 at 11:09 AM John P. Linderman wrote: > The use of honorifics was subtly discouraged at the Labs. I never saw a > policy statement, but nobody I knew used "Dr" (except those in the medical > department), even though the place was crawling with doctoral degrees. > My officemate has a PhD and told me a funny story. Someone (not him) from his program graduated and shortly thereafter flew somewhere. Realizing that they could put "Dr" as an honorific when booking their flight, this person did so. Shortly after take-off, a flight attendant approached the newly-minted PhD and said something along the lines of, "Uh, Doctor? We have a passenger we think may be having a heart attack..." This person had to quickly explain that they were not "that kind of doctor" but rather "the other kind." The nonplussed flight attendant advised this person not to use "Dr" as a title when booking future flights. As an aside, I have a close friend who is a medical doctor and she's been on _five_ separate flights where the flight attendants have asked for medical assistance from qualified passengers: usually it's a heart-attack or an allergic reaction. As a result, she now prescribes herself an epi pen and keeps it in her bag. I think there are times when titles are contextually appropriate: perhaps on the byline of a paper, in accordance with the editorial guidelines of a publication or conference proceedings or something, or perhaps when teaching a class in an academic setting. Occasionally I teach a session of a graduate course somewhere or another; less occasionally I get emails from students who attended the lecture. I always find it flattering and amusing when they variously refer to me as "Dr" or "Prof": I am neither, though I understand that in academic settings that's simply the norm. About half of the people in the immediate vicinity of my office have PhDs. When my kids have come to visit, I try to use titles and last names. Sometimes this gets them confused, "why did I have to call that person Dr So-and-so but you call her Lucy?" "Because you're six and I'm her colleague." But otherwise everyone is on a first-name basis; if a PhD tried to assert use of their title outside of some context where it's explicitly relevant, I don't imagine it would go well and that person would likely not remain in their position long due to a cultural mismatch. A particular impedance mismatch is when someone has a PhD in a completely unrelated field: It's not unheard of for someone with a degree in the humanities to work in software. I once briefly met someone who had worked on MVS as a systems programmer, but who had a PhD in study of the Japanese language. I doubt he insisted on being called "Doctor" at work. - Dan C. On Sat, Aug 1, 2020 at 10:14 AM Larry McVoy wrote: > >> On Sat, Aug 01, 2020 at 09:14:36AM +0200, markus schnalke wrote: >> > Hoi. >> > >> > [2020-07-30 20:30] Dan Cross >> > > >> > > I understood from Mike Anshel that he was rather proud of this, [...] >> > >> > I once read that someone is famous when people omit the titles, >> > because they add nothing to the name, but rather would smaller it. >> > A good example is Albert Einstein. Who cares what titles he has. >> > >> > Another is Dennis Ritchie. What does it matter what degrees, titles, >> > whatever he has? -- He's already a genius! >> >> My dad wasn't famous, but he had a PhD in physics. He never asked people >> to call him Dr McVoy. As we grew up and realized he could be called that >> we asked him why not. He said it sounds fancy, the only time he used it >> was when he wanted a table at a crowded restaurant (which was very rare, >> Madison didn't pay him very well). >> >> Somehow that stuck with me and I've always been sort of wary of people >> who use their title. The people I admire never did. >> >> Someone on the list said that they thought Dennis wouldn't appreciate >> it if we got his PhD official. I couldn't put my finger on it at the >> time, but I agreed. And I think it is because the people who are really >> great don't need or want the fancy title. I may be over thinking it, >> but Dennis does not need the title, it does nothing to make his legacy >> better, his legacy is way way more than that title. >> >> Which is a long ramble to say I agree with Markus. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Sun Aug 2 02:44:20 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 01 Aug 2020 12:44:20 -0400 Subject: [TUHS] Dennis Ritchie's dissertation Message-ID: <202008011644.071GiKXP124091@tahoe.cs.Dartmouth.EDU> > The use of honorifics was subtly discouraged at the Labs. I never saw a policy statement, but nobody I knew used "Dr" (except those in the medical department) With the sole exception of the president's office, secretaries were instructed not to say "Dr so-and-so's office" when they picked up an unanswered phone call. (When that happened you could be sure that the party you were calling was genuinely unavailable. Part of the AT&T ethos--now abandoned--was that everybody, right up to the president, answered their own phones.) Doug From krewat at kilonet.net Sun Aug 2 03:01:02 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Sat, 1 Aug 2020 13:01:02 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> Message-ID: On 8/1/2020 12:08 PM, Nemo Nusquam wrote: > On 07/31/20 21:36, Larry McVoy wrote (in part): >> Me neither. SMIT was HORRIBLE [...] > > Hhmmm... I am reminded of the appendix "In defense of AIX" in Nemeth > et alii. > SMIT had an IBM-ish-ness to it all it's own. I seem to remember it was pretty easy to get the commands it was running, and just use those next time around. Nothing quite like having a customer's entire IT department outsourced to IBM, and having to go into SMIT and fix their cluster configs... Ah... good times. ak From ken at google.com Sun Aug 2 03:21:15 2020 From: ken at google.com (Ken Thompson) Date: Sat, 1 Aug 2020 10:21:15 -0700 Subject: [TUHS] Dennis Ritchie's Dissertation In-Reply-To: References: <202007310003.06V03OoV073870@chez.mckusick.com> <1k1lj2-7nP-00@marmaro.de> <20200801141310.GQ10778@mcvoy.com> Message-ID: long story: i have a friend with a phd in computer science. his wife has a phd in chaucer. i was having lunch with them when they were opening a bank account and were discussing what was to go on the checks. she wanted "dr & dr X", he said he would let her have her "dr", but insisted on "joe" - she hit the ceiling, "dr & joe X" wouldn't do. they both were very mad and "decided" on "dr and mr X." i am not sure what they put on the checks, but the best part of the story is when they left. they stomped out of the diner, very angry, and bumped into someone coming in. the guy coming in said "watch out asshole" and joe replied without hesitation "that's dr asshole to you." another friend, this time by name, bob (h) morris, would call me "boy" because he and i were the only non-phds within several floors at the labs. so, about dennis. he was always ambiguous about the title. from that, i gather that, since he put the time in, he wanted people to think he had a phd. but he never used the title because of the stigma around bell labs in so doing. so i would drop this discussion about him, which draws attention to the fact, leave it ambiguous and just call him "dennis." On Sat, Aug 1, 2020 at 9:44 AM Dan Cross wrote: > On Sat, Aug 1, 2020 at 11:09 AM John P. Linderman > wrote: > >> The use of honorifics was subtly discouraged at the Labs. I never saw a >> policy statement, but nobody I knew used "Dr" (except those in the medical >> department), even though the place was crawling with doctoral degrees. >> > > My officemate has a PhD and told me a funny story. Someone (not him) from > his program graduated and shortly thereafter flew somewhere. Realizing that > they could put "Dr" as an honorific when booking their flight, this person > did so. Shortly after take-off, a flight attendant approached the > newly-minted PhD and said something along the lines of, "Uh, Doctor? We > have a passenger we think may be having a heart attack..." This person had > to quickly explain that they were not "that kind of doctor" but rather "the > other kind." The nonplussed flight attendant advised this person not to use > "Dr" as a title when booking future flights. As an aside, I have a close > friend who is a medical doctor and she's been on _five_ separate flights > where the flight attendants have asked for medical assistance from > qualified passengers: usually it's a heart-attack or an allergic reaction. > As a result, she now prescribes herself an epi pen and keeps it in her bag. > > I think there are times when titles are contextually appropriate: perhaps > on the byline of a paper, in accordance with the editorial guidelines of a > publication or conference proceedings or something, or perhaps when > teaching a class in an academic setting. Occasionally I teach a session of > a graduate course somewhere or another; less occasionally I get emails from > students who attended the lecture. I always find it flattering and amusing > when they variously refer to me as "Dr" or "Prof": I am neither, though I > understand that in academic settings that's simply the norm. > > About half of the people in the immediate vicinity of my office have PhDs. > When my kids have come to visit, I try to use titles and last names. > Sometimes this gets them confused, "why did I have to call that person Dr > So-and-so but you call her Lucy?" "Because you're six and I'm her > colleague." But otherwise everyone is on a first-name basis; if a PhD tried > to assert use of their title outside of some context where it's explicitly > relevant, I don't imagine it would go well and that person would likely not > remain in their position long due to a cultural mismatch. > > A particular impedance mismatch is when someone has a PhD in a completely > unrelated field: It's not unheard of for someone with a degree in the > humanities to work in software. I once briefly met someone who had worked > on MVS as a systems programmer, but who had a PhD in study of the Japanese > language. I doubt he insisted on being called "Doctor" at work. > > - Dan C. > > On Sat, Aug 1, 2020 at 10:14 AM Larry McVoy wrote: >> >>> On Sat, Aug 01, 2020 at 09:14:36AM +0200, markus schnalke wrote: >>> > Hoi. >>> > >>> > [2020-07-30 20:30] Dan Cross >>> > > >>> > > I understood from Mike Anshel that he was rather proud of this, [...] >>> > >>> > I once read that someone is famous when people omit the titles, >>> > because they add nothing to the name, but rather would smaller it. >>> > A good example is Albert Einstein. Who cares what titles he has. >>> > >>> > Another is Dennis Ritchie. What does it matter what degrees, titles, >>> > whatever he has? -- He's already a genius! >>> >>> My dad wasn't famous, but he had a PhD in physics. He never asked people >>> to call him Dr McVoy. As we grew up and realized he could be called that >>> we asked him why not. He said it sounds fancy, the only time he used it >>> was when he wanted a table at a crowded restaurant (which was very rare, >>> Madison didn't pay him very well). >>> >>> Somehow that stuck with me and I've always been sort of wary of people >>> who use their title. The people I admire never did. >>> >>> Someone on the list said that they thought Dennis wouldn't appreciate >>> it if we got his PhD official. I couldn't put my finger on it at the >>> time, but I agreed. And I think it is because the people who are really >>> great don't need or want the fancy title. I may be over thinking it, >>> but Dennis does not need the title, it does nothing to make his legacy >>> better, his legacy is way way more than that title. >>> >>> Which is a long ramble to say I agree with Markus. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Sun Aug 2 03:48:42 2020 From: cowan at ccil.org (John Cowan) Date: Sat, 1 Aug 2020 13:48:42 -0400 Subject: [TUHS] Dennis Ritchie's Dissertation In-Reply-To: References: <202007310003.06V03OoV073870@chez.mckusick.com> <1k1lj2-7nP-00@marmaro.de> <20200801141310.GQ10778@mcvoy.com> Message-ID: On Sat, Aug 1, 2020 at 12:44 PM Dan Cross wrote: On Sat, Aug 1, 2020 at 11:09 AM John P. Linderman wrote: > >> The use of honorifics was subtly discouraged at the Labs. >> > I think this is true, or at least used to be true, everywhere between the East and California, where it was typical for tertiary students to address their teachers with the ordinary titles of Mr., Mrs., and Miss (now Ms. too, most likely). I once heard of an organization named "The Society for Calling University Professors 'Mister'". Occasionally I teach a session of a graduate course somewhere or another; > less occasionally I get emails from students who attended the lecture. I > always find it flattering and amusing when they variously refer to me as > "Dr" or "Prof": I am neither, > I have a standard reply to that when it comes from people who know nothing about me: "Neither doctor nor master nor even bachelor am I, but plain John of New Avalon. :-)" New Avalon is of course more usually known as the Big Apple. I use that and my middle name as my Twitter username (now long idle), @woldemar_avalon. > About half of the people in the immediate vicinity of my office have PhDs. > I have four siblings and two parents with doctorates, while I myself remain untitled (as shown above). When I was a kid and answered the phone, and someone asked for either Professor Cowan or Doctor Cowan, I would carefully ask "Do you mean Professor Thomas or Professor Marianne?" My mother wanted me to say "Do you want my mother or my father?", but I rejected this as below the dignity of a telephone receptionist. A particular impedance mismatch is when someone has a PhD in a completely > unrelated field: > Many people have advanced degrees in English (or another language) or library science but also a programming background: they tend to wind up in the digital humanities because their original fields aren't hiring. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org I should say generally that that marriage was best auspiced, for the achievement of happiness, which contemplated a relation between a man and a woman in which the independence was equal, the dependence mutual, and the obligations reciprocal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.paulsen at firemail.de Sun Aug 2 03:34:52 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Sat, 01 Aug 2020 19:34:52 +0200 Subject: [TUHS] Dennis Ritchie's Dissertation In-Reply-To: References: <202007310003.06V03OoV073870@chez.mckusick.com> <1k1lj2-7nP-00@marmaro.de> <20200801141310.GQ10778@mcvoy.com> Message-ID: > so i would drop this discussion about him, which > draws attention to the fact, leave it ambiguous > and just call him "dennis." the final word on the issue. Thanks a lot Ken.
_________________________________________________________________
Gesendet mit Firemail.de - Freemail From gnu at toad.com Sun Aug 2 06:24:49 2020 From: gnu at toad.com (John Gilmore) Date: Sat, 01 Aug 2020 13:24:49 -0700 Subject: [TUHS] Dennis Ritchie's Dissertation In-Reply-To: References: <202007310003.06V03OoV073870@chez.mckusick.com> <1k1lj2-7nP-00@marmaro.de> <20200801141310.GQ10778@mcvoy.com> Message-ID: <24207.1596313489@hop.toad.com> John P. Linderman wrote: > The use of honorifics was subtly discouraged at the Labs. I never saw a > policy statement, but nobody I knew used "Dr" (except those in the medical > department), even though the place was crawling with doctoral degrees. Yes -- but their administration was anything but egalitarian or meritocratic. I know someone who had immense trouble getting inside the door at the Labs because "all" he had was a bachelor's degree. Let their character be judged by how they treated a stranger. Sign me proud to have succeeded in life with no degrees at all, John Gilmore From doug at cs.dartmouth.edu Sun Aug 2 07:12:54 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 01 Aug 2020 17:12:54 -0400 Subject: [TUHS] Regular Expressions Message-ID: <202008012112.071LCsdo037245@tahoe.cs.Dartmouth.EDU> > 1. What's the provenance of regex in unix (when did it appear, in what form, etc)? > 2. What are the 'best' implementations throughout unix (keep it pre1980s)? > 3. What are some of the milestones along the way (major changes, forks, disagreements)? The editor ed was in Unix from day 1. For the necessarily tiny implementation, Ken discarded various features from the ancestral qed. Among the casualties was alternation in regular expressions. It has never fully returned. Ken's original paper described a method for simulating all paths of a nondeterministic finite automaton in parallel, although he didn't describe it in these exact terms. This meant he had to keep track of up to n possible states, where n is the number of terminal symbols in the regular expression. "Computing Reviews" published a scathing critique of the paper: everyone knows a deterministic automaton can recognize regular expressions with one state transition per input character; what a waste of time to have to keep track of multiple states! What the review missed was that the size of the DFA can be exponential in n. For one-shot use, as in an editor, it can take far longer to construct the DFA than to run it. This lesson came home with a vengeance when Al Aho wrote egrep, which implemented full regular expressions as DFA's. I happened to be writing calendar(1) at the same time, and used egrep to search calendar files for dates in rather free formats for today and all days through the next working day. Here's an example (egrep interprets newline as "|"): (^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*1)([^0123456789]|$) (^|[ (,;])((\* *)0*1)([^0123456789]|$) (^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*2)([^0123456789]|$) (^|[ (,;])((\* *)0*2)([^0123456789]|$) (^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*3)([^0123456789]|$) (^|[ (,;])((\* *)0*3)([^0123456789]|$) Much to Al's chagrin, this regular expression took the better part of a minute to compile into a DFA, which would then run in microseconds. The trouble was that the DFA was enormously bigger than the input--only a tiny fraction of the machine's states would be visited; the rest were useless. That led him to the brilliant idea of constructing the machine on the fly, creating only the states that were pertinent to the input at hand. That innovation made the DFA again competitive with an NFA. Doug From norman at oclsc.org Sun Aug 2 07:24:46 2020 From: norman at oclsc.org (Norman Wilson) Date: Sat, 1 Aug 2020 17:24:46 -0400 (EDT) Subject: [TUHS] Dennis Ritchie's Dissertation Message-ID: <20200801212446.419724422C@lignose.oclsc.org> John Gilmore: Yes -- but [Bell Labs'] administration was anything but egalitarian or meritocratic. I know someone who had immense trouble getting inside the door at the Labs because "all" he had was a bachelor's degree. Let their character be judged by how they treated a stranger. Sign me proud to have succeeded in life with no degrees at all, ==== That was where local management came in. I have no degrees at all. I haven't been nearly as successful in many ways as John, but I was recruited and hired by 1127. That I had no degree meant I was initially hired as a `special technical assistant' rather than a `member of technical staff,' but my department head and director and executive director (the last was the legendary Vic Vyssotsky) worked tirelessly on my behalf, without my pushing them at all, to get me upgraded, and succeeded after I'd been there about a year. It was only later that I realized just how much work they'd done on my behalf. The upgrade gave me a big raise in pay, but I was young enough and nerdy enough not to notice. Within the 1127 culture there was no perceptible difference; it was very much an egalitarian culture. I felt respected as an equal from the start (really from the day and a half I spent interviewing there). Not every part of the Labs, let alone AT&T, was like that, especially outside of the Research area. I didn't realize it initially but that was one of the ways I benefited from the success of UNIX (that 1127's and 112's management could push past such bureaucratic barriers). After all, Ken never had more than an MS. Norman Wilson Toronto ON From jon at fourwinds.com Sun Aug 2 08:00:42 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Sat, 01 Aug 2020 15:00:42 -0700 Subject: [TUHS] Dennis Ritchie's Dissertation [ really PhD's at BTL ] In-Reply-To: <20200801212446.419724422C@lignose.oclsc.org> References: <20200801212446.419724422C@lignose.oclsc.org> Message-ID: <202008012200.071M0gYN830031@darkstar.fourwinds.com> Norman Wilson writes: > John Gilmore: > > Yes -- but [Bell Labs'] administration was anything but egalitarian or > meritocratic. I know someone who had immense trouble getting inside the > door at the Labs because "all" he had was a bachelor's degree. Let > their character be judged by how they treated a stranger. > > Sign me proud to have succeeded in life with no degrees at all, > > ==== > > That was where local management came in. > > I have no degrees at all. I haven't been nearly as > successful in many ways as John, but I was recruited > and hired by 1127. That I had no degree meant I was > initially hired as a `special technical assistant' > rather than a `member of technical staff,' but my > department head and director and executive director > (the last was the legendary Vic Vyssotsky) worked > tirelessly on my behalf, without my pushing them at > all, to get me upgraded, and succeeded after I'd been > there about a year. It was only later that I realized > just how much work they'd done on my behalf. > > The upgrade gave me a big raise in pay, but I was > young enough and nerdy enough not to notice. > > Within the 1127 culture there was no perceptible > difference; it was very much an egalitarian culture. > I felt respected as an equal from the start (really > from the day and a half I spent interviewing there). > > Not every part of the Labs, let alone AT&T, was like > that, especially outside of the Research area. I > didn't realize it initially but that was one of the > ways I benefited from the success of UNIX (that 1127's > and 112's management could push past such bureaucratic > barriers). > > After all, Ken never had more than an MS. Having spend time in both areas 10 and 20, there were more advanced degrees in area 10. But, it was really low key. You wouldn't know unless you asked. One of the nice benefits at BTL is that they had a program for employees to get advanced degrees. I was told that if I decided to work there post college that I would need to plan on going for an advanced degree. There are many different definitions of success. I agree that John was successful at making money, and as being part of a team that made free software what it is today. But that's not the definition for pre-divestiture BTL. They were a research and development lab. Success meant blazing new trails and inventing. I don't think that BTL was specifically looking for people with PhDs, they were looking for people who had a history of doing good research. During most of BTLs history one found those people by reading dissertations. People who had no degree, much less an advanced degree, were researcher-wannabees, not proven researchers. They didn't hire Shannon because they liked his name, I'd guess that his master's theses opened the door. Another way to look at it is that one could certainly become financially successful by reimplementing tar as free software, but the invention of tar is successful research. The only way that I got my foot in the door was because Heinz and Carl knew me through the Explorer Scout post. My unscientific survey of summer students was that they either came from scouts, or were people working on advanced degrees in college. Jon From cbbrowne at gmail.com Sun Aug 2 10:45:12 2020 From: cbbrowne at gmail.com (Christopher Browne) Date: Sat, 1 Aug 2020 20:45:12 -0400 Subject: [TUHS] Regular Expressions In-Reply-To: <88FBBEDA-3D60-4782-9C4B-43C64691BC35@humeweb.com> References: <6e9ca056-dfb0-376d-effd-e41c9ed3ef2a@gmail.com> <88FBBEDA-3D60-4782-9C4B-43C64691BC35@humeweb.com> Message-ID: On Sat, 1 Aug 2020 at 02:38, Andrew Hume wrote: > > during the mid 80s, i was preparing one of the first invited talks for > USENIX on the subject of regular expressions. > i had concocted a massive RE that matched all the known spellings of > saddam hussein. (it was complicated, > and there were many different romanizations active at the time.) > > dennis ritchie wandered into the unix room and asked what it was and then > immediately applied it to our > somewhat newish AP news wire feed. it matched two new spellings!! > I recalled that one being about Khadaffi, of Libya, and there being a punchline involving one of the names being "squid-breath." -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.j.blom at gmail.com Sun Aug 2 14:59:54 2020 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Sun, 2 Aug 2020 11:59:54 +0700 Subject: [TUHS] Regular Expressions Message-ID: Probably same as others do, when I'm implementing some 'trace' messages in a new program or one just 'under investigation' I try to make sure the message has a nice format to be able to process a few megabyte of logfile easily. Cheers, uncle rubl From doug at cs.dartmouth.edu Sun Aug 2 23:40:48 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 02 Aug 2020 09:40:48 -0400 Subject: [TUHS] BTL summer employees Message-ID: <202008021340.072Demtg086822@tahoe.cs.Dartmouth.EDU> > My unscientific survey of summer students was that they either came > from scouts, or were people working on advanced degrees in college. Not all high-school summer employees were scouts (or scout equivalents - kids who had logins on BTL Unix machines). I think in particular of Steve Johnson and Stu Feldman, who eventually became valued permanent employees. The labs also hired undergrad summer employees. I was one. Even high-school employees could make lasting contributions. I am indebted to Steve for a technique he conceived during his first summer assignment: using macro definitions as if they were units of associative memory. This view of macros stimulated previously undreamed-of uses. Doug From arnold at skeeve.com Sun Aug 2 23:57:24 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 02 Aug 2020 07:57:24 -0600 Subject: [TUHS] BTL summer employees In-Reply-To: <202008021340.072Demtg086822@tahoe.cs.Dartmouth.EDU> References: <202008021340.072Demtg086822@tahoe.cs.Dartmouth.EDU> Message-ID: <202008021357.072DvOYo024549@freefriends.org> Doug McIlroy wrote: > Even high-school employees could make lasting contributions. I am > indebted to Steve for a technique he conceived during his first summer > assignment: using macro definitions as if they were units of associative > memory. This view of macros stimulated previously undreamed-of uses. Can you give some examples of what this looked like? Thanks, Arnold From rob at robdiamond.com Mon Aug 3 01:12:30 2020 From: rob at robdiamond.com (Robert Diamond) Date: Sun, 2 Aug 2020 11:12:30 -0400 Subject: [TUHS] BTL summer employees In-Reply-To: <202008021340.072Demtg086822@tahoe.cs.Dartmouth.EDU> References: <202008021340.072Demtg086822@tahoe.cs.Dartmouth.EDU> Message-ID: <8CF368A4-E75C-4123-8CB8-1E5BFA2E3C24@robdiamond.com> I was one of those high school employees, but worked year-round on weekends and full time in the summers into college. I came from the Explorer’s Club (scouts). Walter L. Brown of the Radiation Physics deptartment hired me mainly as a sysadmin on his lab’s PDP 11/45. (I still have all the manuals!). I also did some coding for him - one project I remember was doing some sort of processing of raw data from a magnetometer on the Voyager-1 spacecraft. I also worked for Steve Bourne re-writing some FORTRAN code into C. I would use the terminals in the Unix room typing my school papers using troff, printing them out on the phototypesetter, and presenting them in a Bell Labs white cover. I got to chat with Brian and Dennis and Doug (hi Doug!) and others often. I remember having lunch downstairs in the cafeteria and learning to play GO and having conversations with random employees that blew the mind of this teenager. I remember Steve Marcus showing me his speech synthesizer and speech recognition system, playing with a Unix system running in a box the size of a toaster oven, going to talks that mostly went over my head but still learning a huge amount, wandering those long hallways and peeking into people’s labs, ogling at the Cray in the computer center, etc. Those years created a future for me: I worked at AT&T (Long Lines and International) and Sun Microsystems, and still use Unix every day at Two Sigma (a quantitive hedge fund with a huge Unix infrastructure). Not sure I made any lasting contributions, but it left a lasting impression on me. Rob > On Aug 2, 2020, at 9:42 AM, Doug McIlroy wrote: > >  >> >> My unscientific survey of summer students was that they either came >> from scouts, or were people working on advanced degrees in college. > > Not all high-school summer employees were scouts (or scout equivalents - > kids who had logins on BTL Unix machines). I think in particular of Steve > Johnson and Stu Feldman, who eventually became valued permanent employees. > The labs also hired undergrad summer employees. I was one. > > Even high-school employees could make lasting contributions. I am > indebted to Steve for a technique he conceived during his first summer > assignment: using macro definitions as if they were units of associative > memory. This view of macros stimulated previously undreamed-of uses. > > Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2265 bytes Desc: not available URL: From doug at cs.dartmouth.edu Mon Aug 3 03:13:07 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 02 Aug 2020 13:13:07 -0400 Subject: [TUHS] BTL summer employees In-Reply-To: <202008021357.072DvOYo024549@freefriends.org> References: <202008021340.072Demtg086822@tahoe.cs.Dartmouth.EDU> <202008021357.072DvOYo024549@freefriends.org> Message-ID: <202008021713.072HD7Ba120877@tahoe.cs.Dartmouth.EDU> >> Even high-school employees could make lasting contributions. I am >> indebted to Steve for a technique he conceived during his first summer >> assignment: using macro definitions as if they were units of associative >> memory. This view of macros stimulated previously undreamed-of uses. > Can you give some examples of what this looked like? One useless, but telling, program of mine was a Turing-machine simulator. Tape cells were represented by macros that contained a symbol and the (macro) names of adjacent cells. New cells could be generated as needed, with names derived from a counter. A natural way to store the state-transition table (I forget how it was actually done) would be as macros whose names are the concatenation of state and symbol names. Path-compression as used in union-find algorithms originated in a macroprocessor implementation by Bob Morris. Each graph node was represented by a macro that pointed to or toward the root of a tree spanning its graph component. Doug From jon at fourwinds.com Mon Aug 3 05:05:03 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 02 Aug 2020 12:05:03 -0700 Subject: [TUHS] BTL summer employees In-Reply-To: <8CF368A4-E75C-4123-8CB8-1E5BFA2E3C24@robdiamond.com> References: <202008021340.072Demtg086822@tahoe.cs.Dartmouth.EDU> <8CF368A4-E75C-4123-8CB8-1E5BFA2E3C24@robdiamond.com> Message-ID: <202008021905.072J53Ug884344@darkstar.fourwinds.com> Robert Diamond writes: > I was one of those high school employees, but worked year-round on weekends > and full time in the summers into college. I came from the Explorer’s > Club (scouts). Walter L. Brown of the Radiation Physics deptartment hired > me mainly as a sysadmin on his lab’s PDP 11/45. (I still have all the > manuals!). I also did some coding for him - one project I remember was doing > some sort of processing of raw data from a magnetometer on the Voyager-1 > spacecraft. I also worked for Steve Bourne re-writing some FORTRAN code > into C. > > I would use the terminals in the Unix room typing my school papers using > troff, printing them out on the phototypesetter, and presenting them in > a Bell Labs white cover. I got to chat with Brian and Dennis and Doug > (hi Doug!) and others often. > > I remember having lunch downstairs in the cafeteria and learning to play > GO and having conversations with random employees that blew the mind of > this teenager. I remember Steve Marcus showing me his speech synthesizer > and speech recognition system, playing with a Unix system running in a > box the size of a toaster oven, going to talks that mostly went over my > head but still learning a huge amount, wandering those long hallways and > peeking into people’s labs, ogling at the Cray in the computer center, etc. > > Those years created a future for me: I worked at AT&T (Long Lines and > International) and Sun Microsystems, and still use Unix every day at Two > Sigma (a quantitive hedge fund with a huge Unix infrastructure). > > Not sure I made any lasting contributions, but it left a lasting impression > on me. > > Rob I wasn't claiming to be authoritative on who got to be summer students; it was just my observation based on who I ran into. I do remember some other kids in there but not sure how it happened or what became of them; Heinz may know. My first summer a group of underprivileged kids from Newark was brought in. It mainly sticks in my mind because one of them was terrified because the computer was so much smarter than he was, so someone (Hal Alles?) tasked him with programming a PDP-11/10 via the front panel switches which gave him a completely different perspective. My experience as similar to Robert's. Computers were slow in those days, and so while I was waiting I would wander around and poke my head into doors where I saw interesting looking stuff and ask people what they were doing. Two that really stick out to me were discovering the UNIX room, of course, and also Max Matthew's music lab. Like Robert, I'm not sure that I did anything timeless but I learned lots of amazing stuff from some of the smartest and strangest people that I ever met and it changed my life. Not sure how it would have played out had I thought about trying to go there after college. My summer jobs were all software even though I was an EE because hardware projects couldn't be finished in a summer. I grew up with very provincial parents in New Jersey and had never really been anywhere until I got a summer job in 1976 for Tektronix in Oregon. The great outdoors were so much greater than back east that I never even thought about being anywhere else. Oh yeah, does anyone have an early 1970s BTL phone book? I've been trying to remember someone's name. Our lab moved to 7C-217 when buildings 6 and 7 were completed. Would appreciate it if someone could tell me who else was on that side of the hall to the right of the lab if facing the lab door from the hall. I seem to remember that there was another lab that had the SS1, the department stockroom, and a few more offices including Dave Weller's. I think that our department's terminal room was across from Dave's. Anyway, would really like to know the names of the folks in those offices because there's one person that I wanted to acknowledge in my book, and I've been fixing mistakes for another printing and would add it if I could. Jon From heinz at osta.com Mon Aug 3 15:14:25 2020 From: heinz at osta.com (Heinz Lycklama) Date: Sun, 2 Aug 2020 22:14:25 -0700 Subject: [TUHS] BTL summer employees In-Reply-To: <202008021905.072J53Ug884344@darkstar.fourwinds.com> References: <202008021340.072Demtg086822@tahoe.cs.Dartmouth.EDU> <8CF368A4-E75C-4123-8CB8-1E5BFA2E3C24@robdiamond.com> <202008021905.072J53Ug884344@darkstar.fourwinds.com> Message-ID: <0ee2d259-f285-e7b3-e628-3f72127190a0@osta.com> On 8/2/2020 12:05 PM, Jon Steinhart wrote: > I wasn't claiming to be authoritative on who got to be summer students; it was > just my observation based on who I ran into. I do remember some other kids in > there but not sure how it happened or what became of them; Heinz may know. My > first summer a group of underprivileged kids from Newark was brought in. > It mainly sticks in my mind because one of them was terrified because the > computer was so much smarter than he was, so someone (Hal Alles?) tasked him > with programming a PDP-11/10 via the front panel switches which gave him a > completely different perspective. Jon, this brings back memories of working with summer students and Explorer Scout high schools students (like yourself) during my years at Bell Labs in MH. I have to credit Carl Christensen for bringing me in to work with him in helping making computers and training resources available to Explorer Scouts on Monday evenings shortly after I started at Bell Labs in 1969. I enjoyed this time in helping and motivating the students as well as taking them on hiking and spelunking trips in NY. I had one summer student work for me on the LSX projects. He was so brilliant that I had a challenge to keep him busy with the tasks I gave him because he finished them so quickly. One of the motivations for doing LSX was actually providing a platform for the music synthesizer that Hal Alles was building. If I can remember any other names for you I will let you know, but this was more than 45 years ago ... Heinz From arnold at skeeve.com Mon Aug 3 19:24:34 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 03 Aug 2020 03:24:34 -0600 Subject: [TUHS] BTL summer employees In-Reply-To: <202008021713.072HD7Ba120877@tahoe.cs.Dartmouth.EDU> References: <202008021340.072Demtg086822@tahoe.cs.Dartmouth.EDU> <202008021357.072DvOYo024549@freefriends.org> <202008021713.072HD7Ba120877@tahoe.cs.Dartmouth.EDU> Message-ID: <202008030924.0739OYR7005390@freefriends.org> Doug McIlroy wrote: > >> Even high-school employees could make lasting contributions. I am > >> indebted to Steve for a technique he conceived during his first summer > >> assignment: using macro definitions as if they were units of associative > >> memory. This view of macros stimulated previously undreamed-of uses. > > > Can you give some examples of what this looked like? > > One useless, but telling, program of mine was a Turing-machine > simulator. Tape cells were represented by macros that contained > a symbol and the (macro) names of adjacent cells. New cells > could be generated as needed, with names derived from a counter. > A natural way to store the state-transition table (I forget > how it was actually done) would be as macros whose names > are the concatenation of state and symbol names. > > Path-compression as used in union-find algorithms originated > in a macroprocessor implementation by Bob Morris. Each graph > node was represented by a macro that pointed to or toward > the root of a tree spanning its graph component. Thanks Doug. I have to admit, I didn't really grok this. My mental processes seem to have frozen somewhat and I need to see something like this in code before I really understand it. :-) Thanks, Arnold From jpl.jpl at gmail.com Mon Aug 3 22:55:28 2020 From: jpl.jpl at gmail.com (John P. Linderman) Date: Mon, 3 Aug 2020 08:55:28 -0400 Subject: [TUHS] BTL summer employees In-Reply-To: <0ee2d259-f285-e7b3-e628-3f72127190a0@osta.com> References: <202008021340.072Demtg086822@tahoe.cs.Dartmouth.EDU> <8CF368A4-E75C-4123-8CB8-1E5BFA2E3C24@robdiamond.com> <202008021905.072J53Ug884344@darkstar.fourwinds.com> <0ee2d259-f285-e7b3-e628-3f72127190a0@osta.com> Message-ID: Students living near MH had a bit of a leg up, having access to the Explorers (did that include any young women?). Offspring of employees, particularly executive level employees, seemed to appear quite often. Adam Buchsbaum and Rich Cox and Terry Crowley come to mind. But, as the names I remembered demonstrate, they were exceptionally bright, and often became (valued) regular employees. I share Heinz's recollection about trying to keep them busy. Terry Crowley joined us as a summer student, and we gave him the "summer project" of making some improvements (like eliminating the 512-byte record size limit) to /bin/sort. He came back in under a week and asked "What's next?" -- jpl On Mon, Aug 3, 2020 at 1:15 AM Heinz Lycklama wrote: > > > On 8/2/2020 12:05 PM, Jon Steinhart wrote: > > I wasn't claiming to be authoritative on who got to be summer students; > it was > > just my observation based on who I ran into. I do remember some other > kids in > > there but not sure how it happened or what became of them; Heinz may > know. My > > first summer a group of underprivileged kids from Newark was brought in. > > It mainly sticks in my mind because one of them was terrified because the > > computer was so much smarter than he was, so someone (Hal Alles?) tasked > him > > with programming a PDP-11/10 via the front panel switches which gave him > a > > completely different perspective. > Jon, this brings back memories of working with summer students and > Explorer Scout high schools students (like yourself) during my years > at Bell Labs in MH. I have to credit Carl Christensen for bringing me > in to work with him in helping making computers and training resources > available to Explorer Scouts on Monday evenings shortly after I started > at Bell Labs in 1969. I enjoyed this time in helping and motivating the > students as well as taking them on hiking and spelunking trips in NY. > I had one summer student work for me on the LSX projects. He was so > brilliant that I had a challenge to keep him busy with the tasks I gave > him because he finished them so quickly. One of the motivations > for doing LSX was actually providing a platform for the music synthesizer > that Hal Alles was building. > > If I can remember any other names for you I will let you know, but > this was more than 45 years ago ... > > Heinz > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Tue Aug 4 02:26:50 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 03 Aug 2020 09:26:50 -0700 Subject: [TUHS] BTL summer employees In-Reply-To: References: <202008021340.072Demtg086822@tahoe.cs.Dartmouth.EDU> <8CF368A4-E75C-4123-8CB8-1E5BFA2E3C24@robdiamond.com> <202008021905.072J53Ug884344@darkstar.fourwinds.com> <0ee2d259-f285-e7b3-e628-3f72127190a0@osta.com> Message-ID: <202008031626.073GQosa921169@darkstar.fourwinds.com> Heinz Lycklama writes: > Jon, this brings back memories of working with summer students and > Explorer Scout high schools students (like yourself) during my years > at Bell Labs in MH. I have to credit Carl Christensen for bringing me > in to work with him in helping making computers and training resources > available to Explorer Scouts on Monday evenings shortly after I started > at Bell Labs in 1969. I enjoyed this time in helping and motivating the > students as well as taking them on hiking and spelunking trips in NY. > I had one summer student work for me on the LSX projects. He was so > brilliant that I had a challenge to keep him busy with the tasks I gave > him because he finished them so quickly. One of the motivations > for doing LSX was actually providing a platform for the music synthesizer > that Hal Alles was building. Yes, aside from all of the amazing technical stuff, I'm really glad that you and Carl introduced me to spelunking. I'm fuzzy on the details on Hal's synthesizer. I thought that he was building the digital filter stuff for the SS1, and making music was a side-effect that took on a life of its own. I do remember the really clever keyboard that Dave Hagelbarger built for it, and the day that Stevie Wonder came to check it out and the halls were clogged with his admirers. John P. Linderman writes: > Students living near MH had a bit of a leg up, having access to the > Explorers (did that include any young women?). Offspring of employees, > particularly executive level employees, seemed to appear quite often. Adam > Buchsbaum and Rich Cox and Terry Crowley come to mind. But, as the names I > remembered demonstrate, they were exceptionally bright, and often became > (valued) regular employees. I share Heinz's recollection about trying to > keep them busy. Terry Crowley joined us as a summer student, and we gave > him the "summer project" of making some improvements (like eliminating the > 512-byte record size limit) to /bin/sort. He came back in under a week and > asked "What's next?" -- jpl There were three young women in scouts when I was there although two of them (Andrea and Kristen) were daughters of Hans Lie who was an advisor along with Heinz and Carl. Living near MH was a mixed blessing. I lived 8 miles away and bicycled there, uphill both ways. The final daily test was making it up Glenside Road on my old heavy Raleigh bike. I remember some issues around that; there were no employee showers at the labs. But, it turned out that dress code was up to your supervisor and Joe was OK with me wearing shorts. I occasionally had to explain that to old-timers who would see me in a hall and who thought that there was a fixed dress code. Jon From imp at bsdimp.com Wed Aug 5 03:08:08 2020 From: imp at bsdimp.com (Warner Losh) Date: Tue, 4 Aug 2020 11:08:08 -0600 Subject: [TUHS] 2.11BSD Status Update Message-ID: OK. I'm plowing through a lot of issues with the putative 2.11BSD reconstructions I've done to date. I keep finding things dated too new to be right. And it turns out that a few patches "snuck in" when the patch 80 catch up was done. I've outlined the ones I've found so far at https://bsdimp.blogspot.com/2020/08/missing-211bsd-patches.html but I'm sure there's at least one more. There was much ambiguity over /usr/new and /usr/local that lead to some of these, but others look like they were in the master tree, but never formally published that have all the hallmarks of legit bug fixes... I've also detailed the issues in going backwards. 2.11BSDpl195 had a different .o format than 2.11BSDpl0. And to make matters worse, its assembler couldn't assemble the assembler from the initial release, so I had to get creative (using apout, thanks to all who contributed to that!). I've also blogged about how to walk back a binary change when the old programs no longer build on the new system. I think I got lucky that it was possible at all :). https://bsdimp.blogspot.com/2020/08/bootstrapping-211bsd-no-patches-from.html has the blow by blow. There are a lot of steps to building even a normal system... Let alone walking through the minefield of errors that you need to do when stepping back... And neither of these even begin to get into the issues with the build system itself requiring workarounds for that... But anyway, I keep making "ur2.11BSD" tapes, installing them and fixing the issues I find... While much information was destroyed in the process, there's a surprising amount of redundancy that one can use to 'test' putative tapes. Warner P.S. ur2.11BSD is from urFOO in linguisting, meaning the original FOO that's been lost and which some amount of reconstruction / speculation is offered about it. Still looking for a good name for the reconstructed 2.11BSD release.... -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Thu Aug 6 11:28:58 2020 From: athornton at gmail.com (Adam Thornton) Date: Wed, 5 Aug 2020 18:28:58 -0700 Subject: [TUHS] Debugging help sought Message-ID: I finally munged lbforth.c (https://gist.github.com/lbruder/10007431) into compiling cleanly on mostly-stock v7 with the system compiler (lbforth itself does fine on 211BSD, but it needs a little help to build in a real K&R environment). Which would be nice, except that when it gets to the linker.... $ cc -o 4th forth.c ld:forth.o: Local symbol botch WTF? How do I begin to debug this? Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcapp at anteil.com Thu Aug 6 12:01:25 2020 From: jcapp at anteil.com (Jim Capp) Date: Wed, 5 Aug 2020 22:01:25 -0400 Subject: [TUHS] Debugging help sought In-Reply-To: References: Message-ID: <0DBD06AA-6E1D-4CD3-A953-C47A4D06B272@anteil.com> Looking through the code, I see some awfully long function names. Does anyone recall if there are/were limits on the size of variable and function names? Could that cause this error? > On Aug 5, 2020, at 9:30 PM, Adam Thornton wrote: > >  > I finally munged lbforth.c (https://gist.github.com/lbruder/10007431) into compiling cleanly on mostly-stock v7 with the system compiler (lbforth itself does fine on 211BSD, but it needs a little help to build in a real K&R environment). > > Which would be nice, except that when it gets to the linker.... > > $ cc -o 4th forth.c > ld:forth.o: Local symbol botch > > WTF? > > How do I begin to debug this? > > Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Aug 6 13:04:37 2020 From: imp at bsdimp.com (Warner Losh) Date: Wed, 5 Aug 2020 21:04:37 -0600 Subject: [TUHS] Debugging help sought In-Reply-To: <0DBD06AA-6E1D-4CD3-A953-C47A4D06B272@anteil.com> References: <0DBD06AA-6E1D-4CD3-A953-C47A4D06B272@anteil.com> Message-ID: On Wed, Aug 5, 2020, 8:12 PM Jim Capp wrote: > Looking through the code, I see some awfully long function names. Does > anyone recall if there are/were limits on the size of variable and function > names? > 8 I think was the limit. Could that cause this error? > Maybe too many symbols? The error comes from lookloc. This is called for external type relocations. It searches the local symbol table for something that matches the relocation entry. This error happens when it can't find it... Not sure of the root causes for *that* though. Warner > On Aug 5, 2020, at 9:30 PM, Adam Thornton wrote: > >  > I finally munged lbforth.c (https://gist.github.com/lbruder/10007431) > into compiling cleanly on mostly-stock v7 with the system compiler (lbforth > itself does fine on 211BSD, but it needs a little help to build in a real > K&R environment). > > Which would be nice, except that when it gets to the linker.... > > $ cc -o 4th forth.c > ld:forth.o: Local symbol botch > > WTF? > > How do I begin to debug this? > > Adam > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Aug 6 13:08:45 2020 From: imp at bsdimp.com (Warner Losh) Date: Wed, 5 Aug 2020 21:08:45 -0600 Subject: [TUHS] Debugging help sought In-Reply-To: References: <0DBD06AA-6E1D-4CD3-A953-C47A4D06B272@anteil.com> Message-ID: On Wed, Aug 5, 2020, 9:04 PM Warner Losh wrote: > > > On Wed, Aug 5, 2020, 8:12 PM Jim Capp wrote: > >> Looking through the code, I see some awfully long function names. Does >> anyone recall if there are/were limits on the size of variable and function >> names? >> > > 8 I think was the limit. > > Could that cause this error? >> > > Maybe too many symbols? > > The error comes from lookloc. This is called for external type > relocations. It searches the local symbol table for something that matches > the relocation entry. This error happens when it can't find it... > > Not sure of the root causes for *that* though. > Try cc -c and do size on the .o. that might give you a hint about what is too big. Warner Warner > >> On Aug 5, 2020, at 9:30 PM, Adam Thornton wrote: >> >>  >> I finally munged lbforth.c (https://gist.github.com/lbruder/10007431) >> into compiling cleanly on mostly-stock v7 with the system compiler (lbforth >> itself does fine on 211BSD, but it needs a little help to build in a real >> K&R environment). >> >> Which would be nice, except that when it gets to the linker.... >> >> $ cc -o 4th forth.c >> ld:forth.o: Local symbol botch >> >> WTF? >> >> How do I begin to debug this? >> >> Adam >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Thu Aug 6 14:49:06 2020 From: will.senn at gmail.com (Will Senn) Date: Wed, 5 Aug 2020 23:49:06 -0500 Subject: [TUHS] v7, adb, and fcreat Message-ID: <3949d53c-e075-ddf9-a272-d82f103ab59d@gmail.com> I've done research on this, but I'm confused and would appreciate some help to understand what's going on. In the 7th edition manual, vol 2, there's an ADB tutorial (pp. 323-336). In the tutorial, the authors, Maranzano and Bourne, walk the reader through a debugging session. The first example is predicated on a buffer overflow bug and the code includes: struct buf { int fildes; int nleft; char *nextp; char buff[512]; }bb; struct buf *obuf; ... if((fcreat(argv[1],obuf)) < 0){ ... Well, this isn't v7 code. As discussed in the v7 manual vol 1 (p. VII): Standard I/O. The old fopen, getc, putc complex and the old –lp package are both dead, and even getchar has changed. All have been replaced by the clean, highly efficient, stdio(3) package. The first things to know are that getchar(3) returns the integer EOF (–1), which is not a possible byte value, on end of file, that 518-byte buffers are out, and that there is a defined FILE data type. The buffers are out, fcreat is gone, etc. So, what's up with this? I don't think adb was in v6, where the fcreat function and buf struct are used... Were Maranzano and Bourne using some kind of hybrid 6+ system? Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Aug 6 14:57:25 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 6 Aug 2020 14:57:25 +1000 (EST) Subject: [TUHS] Debugging help sought In-Reply-To: References: <0DBD06AA-6E1D-4CD3-A953-C47A4D06B272@anteil.com> Message-ID: On Wed, 5 Aug 2020, Warner Losh wrote: > On Wed, Aug 5, 2020, 8:12 PM Jim Capp wrote: > Looking through the code, I see some awfully long function names. > Does anyone recall if there are/were limits on the size of > variable and function names? > > 8 I think was the limit. Seven plus the leading (implied) underscore? -- Dave From cowan at ccil.org Thu Aug 6 15:00:13 2020 From: cowan at ccil.org (John Cowan) Date: Thu, 6 Aug 2020 01:00:13 -0400 Subject: [TUHS] v7, adb, and fcreat In-Reply-To: <3949d53c-e075-ddf9-a272-d82f103ab59d@gmail.com> References: <3949d53c-e075-ddf9-a272-d82f103ab59d@gmail.com> Message-ID: The manual came out in editions, but the code, man pages, etc. changed continuously. So what you hear about in a particular paper is not necessarily correlated with a particular state of the manual. On Thu, Aug 6, 2020 at 12:49 AM Will Senn wrote: > I've done research on this, but I'm confused and would appreciate some > help to understand what's going on. In the 7th edition manual, vol 2, > there's an ADB tutorial (pp. 323-336). In the tutorial, the authors, > Maranzano and Bourne, walk the reader through a debugging session. The > first example is predicated on a buffer overflow bug and the code includes: > > struct buf { > int fildes; > int nleft; > char *nextp; char buff[512]; }bb; > struct buf *obuf; > > ... > if((fcreat(argv[1],obuf)) < 0){ > ... > > Well, this isn't v7 code. As discussed in the v7 manual vol 1 (p. VII): > > Standard I/O. The old fopen, getc, putc complex and the old –lp package > are both dead, and even getchar has changed. All have been replaced by the > clean, highly efficient, stdio(3) package. The first things to know are > that getchar(3) returns the integer EOF (–1), which is not a possible byte > value, on end of file, that 518-byte buffers are out, and that there is a > defined FILE data type. > > The buffers are out, fcreat is gone, etc. So, what's up with this? I don't > think adb was in v6, where the fcreat function and buf struct are used... > Were Maranzano and Bourne using some kind of hybrid 6+ system? > > Thanks, > > Will > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Thu Aug 6 15:55:42 2020 From: athornton at gmail.com (Adam Thornton) Date: Wed, 5 Aug 2020 22:55:42 -0700 Subject: [TUHS] Debugging help sought In-Reply-To: References: <0DBD06AA-6E1D-4CD3-A953-C47A4D06B272@anteil.com> Message-ID: Thanks. Part of getting the thing to compile for V7 was shortening the names so they were unique in the first 8 characters (rather like I had to do for Frotz on TOPS-20). I suspect “too many symbols” since I wrote a cpppp (C preprocssor preprocessor) to emulate the symbol pasting in the original code, and there are a _LOT_ (well, 71) of BUILTIN(a,b,c,d) and ADD_BUILTIN(c) which each expand into a function. Wondering if breaking it up into multiple source files, and thus object files, would help. Doubt it will but maybe I will try that tomorrow. Adam From otto at drijf.net Thu Aug 6 17:16:34 2020 From: otto at drijf.net (Otto Moerbeek) Date: Thu, 6 Aug 2020 09:16:34 +0200 Subject: [TUHS] Debugging help sought In-Reply-To: References: <0DBD06AA-6E1D-4CD3-A953-C47A4D06B272@anteil.com> Message-ID: <20200806071634.GA96322@clue.drijf.net> On Thu, Aug 06, 2020 at 02:57:25PM +1000, Dave Horsfall wrote: > On Wed, 5 Aug 2020, Warner Losh wrote: > > > On Wed, Aug 5, 2020, 8:12 PM Jim Capp wrote: > > Looking through the code, I see some awfully long function names. > > Does anyone recall if there are/were limits on the size of > > variable and function names? > > > > 8 I think was the limit. > > Seven plus the leading (implied) underscore? > > -- Dave K&R 1st edition Reference Manual section 2.2 mentions 8 (including underscore) as the number of significant characters, though names can be longer. External names are more restricted: it has a table of limits for external names for various targerts. PDP-11 is 7 chars, Honeywell 6000 is 6 chars (with no case distinction). -Otto From will.senn at gmail.com Thu Aug 6 22:15:25 2020 From: will.senn at gmail.com (Will Senn) Date: Thu, 6 Aug 2020 07:15:25 -0500 Subject: [TUHS] v7, adb, and fcreat In-Reply-To: References: <3949d53c-e075-ddf9-a272-d82f103ab59d@gmail.com> Message-ID: <5c410870-cfeb-a63b-d699-3cdfdb53f82b@gmail.com> Thanks, John. That is one concise answer that explains the problem quite well. Now that I think about it, it explains quite a bit about quite a bit :). Will On 8/6/20 12:00 AM, John Cowan wrote: > The manual came out in editions, but the code, man pages, etc. changed > continuously.  So what you hear about in a particular paper is not > necessarily correlated with a particular state of the manual. > > On Thu, Aug 6, 2020 at 12:49 AM Will Senn > wrote: > > I've done research on this, but I'm confused and would appreciate > some help to understand what's going on. In the 7th edition > manual, vol 2, there's an ADB tutorial (pp. 323-336). In the > tutorial, the authors, Maranzano and Bourne, walk the reader > through a debugging session. The first example is predicated on a > buffer overflow bug and the code includes: > > struct buf { > int fildes; > int nleft; > char *nextp; char buff[512]; }bb; > struct buf *obuf; > > ... > if((fcreat(argv[1],obuf)) < 0){ > ... > > Well, this isn't v7 code. As discussed in the v7 manual vol 1 (p. > VII): > > Standard I/O. The old fopen, getc, putc complex and the old –lp > package are both dead, and even getchar has changed. All have been > replaced by the clean, highly efficient, stdio(3) package. The > first things to know are that getchar(3) returns the integer EOF > (–1), which is not a possible byte value, on end of file, that > 518-byte buffers are out, and that there is a defined FILE data type. > > The buffers are out, fcreat is gone, etc. So, what's up with this? > I don't think adb was in v6, where the fcreat function and buf > struct are used... Were Maranzano and Bourne using some kind of > hybrid 6+ system? > > Thanks, > > Will > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF > -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Fri Aug 7 01:47:09 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Thu, 6 Aug 2020 11:47:09 -0400 Subject: [TUHS] Debugging help sought In-Reply-To: References: Message-ID: On 8/5/20, Adam Thornton wrote: > > $ cc -o 4th forth.c > ld:forth.o: Local symbol botch I hate error messages like that. Would it have been that much extra trouble for ld to tell you which symbol caused the problem? -Paul W. From lm at mcvoy.com Fri Aug 7 02:09:08 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 6 Aug 2020 09:09:08 -0700 Subject: [TUHS] Debugging help sought In-Reply-To: References: Message-ID: <20200806160908.GR10778@mcvoy.com> On Thu, Aug 06, 2020 at 11:47:09AM -0400, Paul Winalski wrote: > On 8/5/20, Adam Thornton wrote: > > > > $ cc -o 4th forth.c > > ld:forth.o: Local symbol botch > > I hate error messages like that. Would it have been that much extra > trouble for ld to tell you which symbol caused the problem? That's funny, I was just talking to my older son yesterday. We had the chat about how much you could get done in a semester in college, a buddy and I did about 80% of an Ada compiler. It was a lot. I told my kid that industry is different, it moves way slower and that is because there is a huge difference between something you get done in a few months and throw away and something that you are going to hand off to users. Error handling and messages matter a lot. Backwards compatibility matters a lot. Isn't Adam working on v7? If so, not so great error messages are sort of understood, it was early times. They got better. From paul.winalski at gmail.com Fri Aug 7 02:19:49 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Thu, 6 Aug 2020 12:19:49 -0400 Subject: [TUHS] Debugging help sought In-Reply-To: <20200806160908.GR10778@mcvoy.com> References: <20200806160908.GR10778@mcvoy.com> Message-ID: On 8/6/20, Larry McVoy wrote: > > Isn't Adam working on v7? If so, not so great error messages are > sort of understood, it was early times. They got better. > Unix *was* a research project in those days, wasn't it? It's easy to forget that these days. -Paul W. From lm at mcvoy.com Fri Aug 7 02:24:01 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 6 Aug 2020 09:24:01 -0700 Subject: [TUHS] Debugging help sought In-Reply-To: References: <20200806160908.GR10778@mcvoy.com> Message-ID: <20200806162401.GS10778@mcvoy.com> On Thu, Aug 06, 2020 at 12:19:49PM -0400, Paul Winalski wrote: > On 8/6/20, Larry McVoy wrote: > > > > Isn't Adam working on v7? If so, not so great error messages are > > sort of understood, it was early times. They got better. > > > Unix *was* a research project in those days, wasn't it? It's easy to > forget that these days. I think we also sometimes forget how small 64K was. Terseness wasn't a choice. From jnc at mercury.lcs.mit.edu Fri Aug 7 02:55:19 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 6 Aug 2020 12:55:19 -0400 (EDT) Subject: [TUHS] v7, adb, and fcreat Message-ID: <20200806165519.740A418C097@mercury.lcs.mit.edu> > From: Will Senn > I don't think adb was in v6, where the fcreat function and buf struct > are used... Were Maranzano and Bourne using some kind of hybrid 6+ system? In addition to the point about skew between the released and internal development, it's worth remembering just how long it was between the V6 and V7 releases, and how much ground was covered technically during that period. A lot of that stuff leaked out: we've talked about the upgraded 'Typesetter C' (and compilers), which a lot of people had, and the V6+ system at MIT (partially sort of PWB1) had both 'adb' and the stdio library. The latter also made its way to lots of places; in my 'improved V6 page': http://www.chiappa.net/~jnc/tech/ImprovingV6.html it talks about finding the standard I/O stuff in several later V6 repositories, including a UNSW tape. But it and typsetter C, also on the Shoppa pack, were clearly quite widespread. Noel From will.senn at gmail.com Fri Aug 7 04:36:27 2020 From: will.senn at gmail.com (Will Senn) Date: Thu, 6 Aug 2020 13:36:27 -0500 Subject: [TUHS] v7, adb, and fcreat In-Reply-To: <20200806165519.740A418C097@mercury.lcs.mit.edu> References: <20200806165519.740A418C097@mercury.lcs.mit.edu> Message-ID: <3781fab6-705c-f877-97fd-c1c2dfe5afb6@gmail.com> Noel, Funny how some things take a while to sink in. I've been messing around with my v6 instance for so long now, that I got to thinking it was v6 :). Sheesh, between you and Clem clueing me in, it finally clicked that it is just one (of many) bit buckets out there with the moniker v6. What confused me initially was that these were built from tapes - never mind that the tapes aren't gold standards, it never occurred to me that they weren't. I am coming from a world where OS version floppy/cd/dvd images are copies of a single master (or very small set of masters). Sure, there are OEM disks out there, but for the most part, if I say, grab OS X 10.14 and burn it, I'll get the same OS X 10.14 as pretty much everybody everywhere. These tape things could be snapshots of the systems they originate from at very different times and with different software/sources etc. I know I'm basically repeating what y'all said, but I'm still in shock :). Will On 8/6/20 11:55 AM, Noel Chiappa wrote: > > From: Will Senn > > > I don't think adb was in v6, where the fcreat function and buf struct > > are used... Were Maranzano and Bourne using some kind of hybrid 6+ system? > > In addition to the point about skew between the released and internal development, > it's worth remembering just how long it was between the V6 and V7 releases, and > how much ground was covered technically during that period. > > A lot of that stuff leaked out: we've talked about the upgraded 'Typesetter C' > (and compilers), which a lot of people had, and the V6+ system at MIT > (partially sort of PWB1) had both 'adb' and the stdio library. The latter also > made its way to lots of places; in my 'improved V6 page': > > http://www.chiappa.net/~jnc/tech/ImprovingV6.html > > it talks about finding the standard I/O stuff in several later V6 repositories, > including a UNSW tape. But it and typsetter C, also on the Shoppa pack, were > clearly quite widespread. > > Noel -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF From jnc at mercury.lcs.mit.edu Fri Aug 7 05:25:23 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 6 Aug 2020 15:25:23 -0400 (EDT) Subject: [TUHS] v7, adb, and fcreat Message-ID: <20200806192523.5774D18C08E@mercury.lcs.mit.edu> > From: Will Senn > it finally clicked that it is just one (of many) bit buckets out there > with the moniker v6. ... I am coming from a world where OS version > floppy/cd/dvd images are copies of a single master ... These tape things > could be snapshots of the systems they originate from at very different > times and with different software/sources etc. Well, sort of. Do remember that everyone with V6 had to have a license, which at that point you could _only_ get from Western Electric. So every _institution_ (which is not the same as every _machine_) had had to have had dealings with them. However, once your institution was 'in the club', stuff just got passed around. E.g. the BBN V6 system with TCP/IP: https://www.tuhs.org/cgi-bin/utree.pl?file=BBN-V6 I got that by driving over to BBN, and talking to Jack Haverty, and he gave us a tape (or maybe a pack, I don't recall exactly). But we had a V6 license, so we could do that. But my particular machine, it worked just the way you described: we got our V6 from the other V6 machine in the Tech Sq building (RTS/DSSR), including not only Bell post-V6 'leakage' like adb, but their local hacks (e.g. their TTY driver, and the ttymod() system call to get to its extended features; the ability to suspend selected applications; yadda, yadda). We never saw a V6 tape. Noel From clemc at ccc.com Fri Aug 7 06:20:54 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 6 Aug 2020 16:20:54 -0400 Subject: [TUHS] Unix and SW Releases (was V7 et al from Will) Message-ID: This topic is still primarily UNIX but is getting near the edge of COFF, so I'll CC there if people want to follow up. As I mentioned to Will, during the time Research was doing the work/put out their 'editions', the 'releases' were a bit more ephemeral - really a set of bits (binary and hopefully matching source, but maybe not always) that become a point in time. With 4th (and I think 5th) Editions it was a state of disk pack when the bits were copies, but by 6th edition, as Noel points out, there was a 'master tape' that the first site at an institution received upon executing of a signed license, so the people at each institution (MIT, Purdue, CMU, Harvard) passed those bits around inside. But what is more, is what Noel pointed out, we all passed source code and binaries between each other, so DNA was fairly mixed up [sorry Larry - it really was 'Open Source' between the licensees]. Sadly, it means some things that actually were sourced at one location and one system, is credited sometimes credited from some other place the >>wide<< release was in USG or BSD [think Jim Kulp's Job control, which ended up in the kernel and csh(1) as part in 4BSD, our recent discussions on the list about more/pg/less, the different networking changes from all of MIT/UofI/Rand, Goble's FS fixes to make the thing more crash resilient, the early Harvard ar changes - *a.k.a.* newar(1) which became ar(1), CMU fsck, e*tc*.]. Eventually, the AT&T Unix Support Group (USG) was stood up in Summit, as I understand it, originally for the Operating Companies as they wanted to use UNIX (but not for the licenses, originally). Steve Johnson moved from Research over there and can tell you many more of the specifics. Eventually (*i.e.* post-Judge Green), distribution to the world moved from MH's Research and the Patent Licensing teams to USG and AT&T North Carolina business folks. That said, when the distribution of UNIX moved to USG in Summit, things started to a bit more formal. But there were still differences inside, as we have tried to unravel. PWB/TS and eventually System x. FWIW, BSD went through the same thing. The first BSD's are really the binary state of the world on the Cory 11/70, later 'Ernie.' By the time CSRG gets stood up because their official job (like USG) is to support Unix for DARPA, Sam and company are acting a bit more like traditional SW firms with alpha/beta releases and a more formal build process. Note that 2.X never really went through that, so we are all witnessing the wonderful efforts to try to rebuild early 2.X BSD, and see that the ephemeral nature of the bits has become more obvious. As a side story ... the fact is that even for professional SW houses, it was not as pure as it should be. To be honest, knowing the players and processes involved, I highly doubt DEC could rebuild early editions of VMS, particularly since the 'source control' system was a physical flag in Cutler's office. The fact is that the problem of which bits were used to make what other bits was widespread enough throughout the industry that in the mid-late 80s when Masscomp won the bid to build the system that Nasa used to control the space shuttle post-Challenger, a clause of the contract was that we have put an archive of the bits running on the build machine ('Yeti'), a copy of the prints and even microcode/PAL versions so that Ford Aerospace (the prime contractor) could rebuild the exact system we used to build the binaries for them if we went bankrupt. I actually, had a duplicate of that Yeti as my home system ('Xorn') in my basement when I made some money for a couple of years as a contract/on-call person for them every time the shuttle flew. Anyway - the point is that documentation and actual bits being 100% in sync is nothing new. Companies work hard to try to keep it together, but different projects work at different speeds. In fact, the 'train release' model is what is usually what people fall into. You schedule a release of some piece of SW and anything that goes with it, has to be on the train or it must wait for the next one. So developers and marketing people in firms argue what gets to be the 'engine' [hint often its HW releases which are a terrible idea, but that's a topic for COFF]. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Aug 7 09:15:55 2020 From: imp at bsdimp.com (Warner Losh) Date: Thu, 6 Aug 2020 17:15:55 -0600 Subject: [TUHS] Unix and SW Releases (was V7 et al from Will) In-Reply-To: References: Message-ID: On Thu, Aug 6, 2020 at 2:22 PM Clem Cole wrote: > That said, when the distribution of UNIX moved to USG in Summit, things started > to a bit more formal. But there were still differences inside, as we > have tried to unravel. PWB/TS and eventually System x. FWIW, BSD went > through the same thing. The first BSD's are really the binary state of > the world on the Cory 11/70, later 'Ernie.' By the time CSRG gets stood > up because their official job (like USG) is to support Unix for DARPA, Sam > and company are acting a bit more like traditional SW firms with alpha/beta > releases and a more formal build process. Note that 2.X never really > went through that, so we are all witnessing the wonderful efforts to try to > rebuild early 2.X BSD, and see that the ephemeral nature of the bits has > become more obvious. > I'm rebuilding 2.11BSD as released, not any of the early bits... :) 1991 is quite late in the 2BSD timeline (oh, wait, it's still going strong in PiDP-11 land). Having said that, though, 2BSD through at least 2.8BSD gives the feeling of the tape of the day club. If you look closely at what's in the TUHS archive, and what's in Kirk's archive as well as other copies around, you'll likely notice small variations. Or you'll see a dozen or two files having newer dates than the documented release date. And the 2.79BSD tape... I'm more than half convinced it was really the 79th tape that had been made and they said 'nuts to that, for a while we'll do 2.8BSD since we now have a kernel'. This is pure speculation, I've not asked around... 2.9BSD, 2.10BSD and 2.10.1BSD all seem to be a little more controlled, though 2.9BSD has a lot of forks and it's not entirely clear they all started from the same spot. There's references to 2.9-SEISMO and 2.9.1 and 2.9 with patches and it isn't at all clear if these are the same thing or different (I think the same, but there's a 2.9 from princeton that's clearly a rollup release years later in kirk's archives). And even my 2.11BSD reconstruction shows that proper CM wasn't deployed for it. I've found half a dozen missing patches that were not released as real patches, but showed up in the 'catch-up' kit that seems to be hiding these sorts of minor sins in the first couple of years after 2.11BSD was released. I'm down to 10-20 files that I'm unsure about ever recovering. These are clearly local files (different kernel configs, UUCP data, games high score files), and I doubt I'll be able to recover them completely.... Though in the scheme of things, they likely are the least important files since they only had relevance to the site making the tapes and were deleted from later versions (which is why I can't find them :). In a way I've started thinking about this like quantum physics. Why you look at it at the macro level, it's all predictable, orderly and makes sense. But when you zoom in too much to any point on the timeline, you find that things get messy, chaotic and a bit indeterminate. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Fri Aug 7 09:41:41 2020 From: athornton at gmail.com (Adam Thornton) Date: Thu, 6 Aug 2020 16:41:41 -0700 Subject: [TUHS] Debugging help sought In-Reply-To: <20200806162401.GS10778@mcvoy.com> References: <20200806160908.GR10778@mcvoy.com> <20200806162401.GS10778@mcvoy.com> Message-ID: Here's the output of "size," which doesn't tell me much....I think. Unless in v7 data has to be under 32K rather than 64K? Surely not, right? (The data segment is 32K of main memory for FORTH, plus some for the startup Forth script, plus a bit for the line buffer and some miscellaneous pointer variables.) $ size forth.o 7580+34034+0 = 41614b = 0121216b On Thu, Aug 6, 2020 at 9:24 AM Larry McVoy wrote: > On Thu, Aug 06, 2020 at 12:19:49PM -0400, Paul Winalski wrote: > > On 8/6/20, Larry McVoy wrote: > > > > > > Isn't Adam working on v7? If so, not so great error messages are > > > sort of understood, it was early times. They got better. > > > > > Unix *was* a research project in those days, wasn't it? It's easy to > > forget that these days. > > I think we also sometimes forget how small 64K was. Terseness wasn't > a choice. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Aug 7 10:35:37 2020 From: imp at bsdimp.com (Warner Losh) Date: Thu, 6 Aug 2020 18:35:37 -0600 Subject: [TUHS] Debugging help sought In-Reply-To: References: Message-ID: On Thu, Aug 6, 2020, 9:48 AM Paul Winalski wrote: > On 8/5/20, Adam Thornton wrote: > > > > $ cc -o 4th forth.c > > ld:forth.o: Local symbol botch > > I hate error messages like that. Would it have been that much extra > trouble for ld to tell you which symbol caused the problem? > It's a relocation entry it can't find a symbol for that's the issue... Warner > -Paul W. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Fri Aug 7 12:49:21 2020 From: cowan at ccil.org (John Cowan) Date: Thu, 6 Aug 2020 22:49:21 -0400 Subject: [TUHS] Unix and SW Releases (was V7 et al from Will) In-Reply-To: References: Message-ID: On Thu, Aug 6, 2020 at 4:22 PM Clem Cole wrote: > [hint often its HW releases which are a terrible idea, but that's a topic > for COFF]. > Or for a "history of MS-DOS" list, if there is such a thing. DOS 1.0 for floppies, DOS 2.0 for 10 MB hard disks, etc. etc. It was in 2.0 that MS-DOS got all the Unix it was ever going to get. -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Fri Aug 7 12:56:39 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 6 Aug 2020 22:56:39 -0400 (EDT) Subject: [TUHS] Unix and SW Releases (was V7 et al from Will) In-Reply-To: References: Message-ID: On Thu, 6 Aug 2020, John Cowan wrote: > On Thu, Aug 6, 2020 at 4:22 PM Clem Cole wrote: > > >> [hint often its HW releases which are a terrible idea, but that's a topic >> for COFF]. >> > > Or for a "history of MS-DOS" list, if there is such a thing. DOS 1.0 for > floppies, DOS 2.0 for 10 MB hard disks, etc. etc. It was in 2.0 that > MS-DOS got all the Unix it was ever going to get. A list like that, I'd dig. -uso. From wobblygong at gmail.com Fri Aug 7 13:41:29 2020 From: wobblygong at gmail.com (Wesley Parish) Date: Fri, 7 Aug 2020 15:41:29 +1200 Subject: [TUHS] [COFF] Unix and SW Releases (was V7 et al from Will) In-Reply-To: References: Message-ID: I'm trying to get my head around this, in relation to the U of Canterbury, NZ's setup. I know they had had some PDPs, because one was offered for sale c 1992. I expect it would've been running 2.xBSD, because the U of C NZ was by and large a BSD house - when I asked about a suitable OS for my brand-new 486 in 1991 I was told if I could afford the (AT&T) license I could have the source tree of (would've been) 4.3BSD. I know they had VAXes, and from what I recall, though the admin ones were VMS boxen, the Computer Science one/s would've been running Unix. They also had Sun pizza boxes. Am I right in assuming that 2.xBSD was the state of the play on PDP while 4.xBSD was the source tree compatible state of play on the VAXes? That if you had a VAX you got the 4.xBSD tapes, whereas if you had a PDP you got the 2.xBSD tapes? Wesley Parish On 8/7/20, Warner Losh wrote: > On Thu, Aug 6, 2020 at 2:22 PM Clem Cole wrote: > >> That said, when the distribution of UNIX moved to USG in Summit, things >> started >> to a bit more formal. But there were still differences inside, as we >> have tried to unravel. PWB/TS and eventually System x. FWIW, BSD went >> through the same thing. The first BSD's are really the binary state of >> the world on the Cory 11/70, later 'Ernie.' By the time CSRG gets stood >> up because their official job (like USG) is to support Unix for DARPA, >> Sam >> and company are acting a bit more like traditional SW firms with >> alpha/beta >> releases and a more formal build process. Note that 2.X never really >> went through that, so we are all witnessing the wonderful efforts to try >> to >> rebuild early 2.X BSD, and see that the ephemeral nature of the bits has >> become more obvious. >> > > I'm rebuilding 2.11BSD as released, not any of the early bits... :) 1991 is > quite late in the 2BSD timeline (oh, wait, it's still going strong in > PiDP-11 land). > > Having said that, though, 2BSD through at least 2.8BSD gives the feeling of > the tape of the day club. If you look closely at what's in the TUHS > archive, and what's in Kirk's archive as well as other copies around, > you'll likely notice small variations. Or you'll see a dozen or two files > having newer dates than the documented release date. And the 2.79BSD > tape... I'm more than half convinced it was really the 79th tape that had > been made and they said 'nuts to that, for a while we'll do 2.8BSD since we > now have a kernel'. This is pure speculation, I've not asked around... > > 2.9BSD, 2.10BSD and 2.10.1BSD all seem to be a little more controlled, > though 2.9BSD has a lot of forks and it's not entirely clear they all > started from the same spot. There's references to 2.9-SEISMO and 2.9.1 and > 2.9 with patches and it isn't at all clear if these are the same thing or > different (I think the same, but there's a 2.9 from princeton that's > clearly a rollup release years later in kirk's archives). > > And even my 2.11BSD reconstruction shows that proper CM wasn't deployed for > it. I've found half a dozen missing patches that were not released as real > patches, but showed up in the 'catch-up' kit that seems to be hiding these > sorts of minor sins in the first couple of years after 2.11BSD was > released. I'm down to 10-20 files that I'm unsure about ever recovering. > These are clearly local files (different kernel configs, UUCP data, games > high score files), and I doubt I'll be able to recover them completely.... > Though in the scheme of things, they likely are the least important files > since they only had relevance to the site making the tapes and were deleted > from later versions (which is why I can't find them :). > > In a way I've started thinking about this like quantum physics. Why you > look at it at the macro level, it's all predictable, orderly and makes > sense. But when you zoom in too much to any point on the timeline, you find > that things get messy, chaotic and a bit indeterminate. > > Warner > From athornton at gmail.com Fri Aug 7 14:30:37 2020 From: athornton at gmail.com (Adam Thornton) Date: Thu, 6 Aug 2020 21:30:37 -0700 Subject: [TUHS] Debugging help sought In-Reply-To: References: Message-ID: So maybe I missed a symbol when I was trying to make everything unique in 8 chars? There are no external symbols; all that's in my forth.h are macros and typedefs. Adam On Thu, Aug 6, 2020 at 5:35 PM Warner Losh wrote: > > > On Thu, Aug 6, 2020, 9:48 AM Paul Winalski > wrote: > >> On 8/5/20, Adam Thornton wrote: >> > >> > $ cc -o 4th forth.c >> > ld:forth.o: Local symbol botch >> >> I hate error messages like that. Would it have been that much extra >> trouble for ld to tell you which symbol caused the problem? >> > > It's a relocation entry it can't find a symbol for that's the issue... > > Warner > >> -Paul W. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Aug 7 15:49:44 2020 From: imp at bsdimp.com (Warner Losh) Date: Thu, 6 Aug 2020 23:49:44 -0600 Subject: [TUHS] Debugging help sought In-Reply-To: References: Message-ID: It's likely too many. Ld used to have lots of fixed sized arrays... I had to hack on the 2.10.1BSD to change supported ar formats and noticed. Also had to tweak some of the constants to get something much bigger compiling. The BSD ld had overlay suppot merged into it, but was otherwise quite similar to V7, though I've not done a deep dive into ld from v7... Tl;dr: chances are good more, smaller files will work. Warner On Thu, Aug 6, 2020, 10:30 PM Adam Thornton wrote: > So maybe I missed a symbol when I was trying to make everything unique in > 8 chars? There are no external symbols; all that's in my forth.h are > macros and typedefs. > > Adam > > On Thu, Aug 6, 2020 at 5:35 PM Warner Losh wrote: > >> >> >> On Thu, Aug 6, 2020, 9:48 AM Paul Winalski >> wrote: >> >>> On 8/5/20, Adam Thornton wrote: >>> > >>> > $ cc -o 4th forth.c >>> > ld:forth.o: Local symbol botch >>> >>> I hate error messages like that. Would it have been that much extra >>> trouble for ld to tell you which symbol caused the problem? >>> >> >> It's a relocation entry it can't find a symbol for that's the issue... >> >> Warner >> >>> -Paul W. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Fri Aug 7 15:54:09 2020 From: athornton at gmail.com (Adam Thornton) Date: Thu, 6 Aug 2020 22:54:09 -0700 Subject: [TUHS] Debugging help sought In-Reply-To: References: Message-ID: Thanks. Since I am already pre-preprocessing the macros that generate the FORTH builtin words (no token pasting in K&R C), I can trivially split them out into individual files each with a single short function. On Thu, Aug 6, 2020 at 10:49 PM Warner Losh wrote: > It's likely too many. Ld used to have lots of fixed sized arrays... I had > to hack on the 2.10.1BSD to change supported ar formats and noticed. Also > had to tweak some of the constants to get something much bigger compiling. > The BSD ld had overlay suppot merged into it, but was otherwise quite > similar to V7, though I've not done a deep dive into ld from v7... > > Tl;dr: chances are good more, smaller files will work. > > > Warner > > On Thu, Aug 6, 2020, 10:30 PM Adam Thornton wrote: > >> So maybe I missed a symbol when I was trying to make everything unique in >> 8 chars? There are no external symbols; all that's in my forth.h are >> macros and typedefs. >> >> Adam >> >> On Thu, Aug 6, 2020 at 5:35 PM Warner Losh wrote: >> >>> >>> >>> On Thu, Aug 6, 2020, 9:48 AM Paul Winalski >>> wrote: >>> >>>> On 8/5/20, Adam Thornton wrote: >>>> > >>>> > $ cc -o 4th forth.c >>>> > ld:forth.o: Local symbol botch >>>> >>>> I hate error messages like that. Would it have been that much extra >>>> trouble for ld to tell you which symbol caused the problem? >>>> >>> >>> It's a relocation entry it can't find a symbol for that's the issue... >>> >>> Warner >>> >>>> -Paul W. >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Sat Aug 8 00:27:07 2020 From: cowan at ccil.org (John Cowan) Date: Fri, 7 Aug 2020 10:27:07 -0400 Subject: [TUHS] [COFF] Unix and SW Releases (was V7 et al from Will) In-Reply-To: References: Message-ID: On Thu, Aug 6, 2020 at 11:42 PM Wesley Parish wrote: > Am I right in assuming that 2.xBSD was the state of the play on PDP > while 4.xBSD was the source tree compatible state of play on the > VAXes? That if you had a VAX you got the 4.xBSD tapes, whereas if you > had a PDP you got the 2.xBSD tapes? > Broadly yes. 2BSD was for the PDP-11, and while it could probably have been ported to another 16-bit box, I don't think that was ever done by anyone. The VAX was the target machine for 3BSD to 4.3BSD. 4.3-Tahoe ran on the Vax and the Power 6/32, though the latter platform died fairly soon (but it was worth it because that release separated out portable and non-portable stuff), and 4.3-Reno on at least HP machines. Then came the Great Legal Mess followed by the BSD Explosion. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org It was dreary and wearisome. Cold clammy winter still held sway in this forsaken country. The only green was the scum of livid weed on the dark greasy surfaces of the sullen waters. Dead grasses and rotting reeds loomed up in the mists like ragged shadows of long-forgotten summers. --LOTR, "The Passage of the Marshes" -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Aug 8 01:37:32 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 7 Aug 2020 11:37:32 -0400 Subject: [TUHS] [COFF] Unix and SW Releases (was V7 et al from Will) In-Reply-To: References: Message-ID: On Thu, Aug 6, 2020 at 11:41 PM Wesley Parish wrote: > Am I right in assuming that 2.xBSD was the state of the play on PDP while > 4.xBSD was the source tree compatible state of play on the VAXes? Sort of/in theory and all that. 2.XBSD was initially developed by a group of folks that had already invested in PDP-11s (in mainly separate I/D based 11s) and could not afford a new Vax. The 11's are address space-constrained and with the introduction of the Vax, one of the side effects of BSD was much of the Unix 'small is beautiful' / 'do one job well' / 'KISS' ideas started to be lost,* i.e. * Rob's super 'cat -v harmful' became necessary to write (along sadly was often ignored). Since CSRG (EE and CS at EE) abandoned the 11's pretty fast, there was a group (originally lead by Keith Bostic in the Stat Dept) that wanted some of the new code (particularly the networking stack and sendmail) moved to their 11's. In some ways, I was surprised that it has kept going, as the 68000 & later 386 based UNIX systems came to the world, as the economics of running an 11 started to dwindle quickly. > That if you had a VAX you got the 4.xBSD tapes, whereas if you had a PDP > you got the 2.xBSD tapes? > If you were a University or Research type that qualified for a $100 style research license, you would get a pure V7 (PDP-11) or a 32/V(Vax) tape from AT&T patent and license. Once your site had that, you were part of the source 'club' and could whatever you wanted based on the AT&T V7 license. So if you were interested in the BSD releases your team then contacted the 'ILO' (UCB's Industrial Laison Office - BTW CSRG's worked with the ILO for all the BSD tapes) and asked to obtain UCB IP (be it the CAD tools such as SPICE, or the OS work like BSD, IC process technology, *et al*). There probably was some sort tape writing, *i.e.* short fees, associated with the specific IP on the order of $100-$1000 depending on what you requested, and there might be some licensing steps (exchange of AT&T license signature pages). When you had a license from the ILO, you were part of the UCB 'club.' The original BSD and 2BSD tapes themselves were released officially by the ILO, as with 3BSD and 4/4.1BSD. By the time of 4.1a BSD and later, we had CSRG, and those releases were done by them directly after the licensing was set up by the ILO. As part of the funding and creation of CSRG, UC Berekely finally had a C30 IMP in Evans (as opposed to the VDH to LBL), so the releases were also possible via ftp from a hidden location on ucbvax. 4X originally targetted Vaxen, but famously other systems like the 386 we available on that site. By the time of the 2X releases, UC Berekely had the C30 IMP ( *i.e. *direct internet connection). So, once you were licensed, you got the keys to be able to FTP different 'tapes' (which included sources and binaries), be it 2X or 4X base But, since CSRG stopped focusing on 16-bit, the 2X stuff became more of labor of love and was a bit less formal and was done with cooperation with the CSRG team. So ... if you owned a PDP-11 and were still running it and you had a proper UCB license, then yes, you might be tempted to run 2X; but the truth is most people began to turn them off in deference to more cost-effective platforms. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sat Aug 8 02:07:23 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 7 Aug 2020 12:07:23 -0400 (EDT) Subject: [TUHS] Debugging help sought Message-ID: <20200807160723.5E16918C08B@mercury.lcs.mit.edu> > From: Warner Losh > 8 I think was the limit. IIRC, you could use longer names than that (in C), but external references only used the first 7 (in C - C symbols had a leading '_' tacked on; I used to know why), 8 (in assembler). > Could that cause this error? Seems unlikely - see below. > The error comes from lookloc. This is called for external type > relocations. It searches the local symbol table for something that > matches the relocation entry. This error happens when it can't find > it... Someone who actually looked at the source: https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/ld.c instead of just guessing. Give that man a star! I spent a while looking at the code, trying to figure out i) how it works, and ii) what's going wrong with that message, but I don't have a definitive answer. The code is not super well commented, so one has to actually understand what it's doing! :-) It seems to my initial perusal that it maintains two symbol tables, one for globals (which accumulates as each file is processed), and one for locals (which is discarded/reset for each file). As Werner mentioned, the message appears when a local symbol referenced in the relocation information in the current file can't be found (in the local symbol table). It's not, I think, simply due to too many local symbols in an input file - there seems to be a check for that as it's reading the input file symbol table: if (lp >= &local[NSYMPR]) error(1, "Local symbol overflow"); *lp++ = symno; *lp++ = sp; although of course there could be a bug which breaks this check. It seems to me that this is an 'impossible' error, one which can only happen due to i) a bug in the loader (a fencepost error, or something), or ii) an error in the input a.out file. I don't want to spend more time on it, since I'm not sure if you've managed to bypass the problem. If not, let me know, and we'll track it down. (This may involve you addding some printf's so we have more info about the details.) Noel From cowan at ccil.org Sat Aug 8 03:11:46 2020 From: cowan at ccil.org (John Cowan) Date: Fri, 7 Aug 2020 13:11:46 -0400 Subject: [TUHS] Debugging help sought In-Reply-To: <20200807160723.5E16918C08B@mercury.lcs.mit.edu> References: <20200807160723.5E16918C08B@mercury.lcs.mit.edu> Message-ID: On Fri, Aug 7, 2020 at 12:07 PM Noel Chiappa wrote: IIRC, you could use longer names than that (in C), but external references > only used the first 7 (in C - C symbols had a leading '_' tacked on; I > used to > know why), 8 (in assembler). > Precisely to avoid collisions between external names in C and names in assembler (whose namespace was flat except for local labels) when they were linked into your program. For similar reasons, F77 names had a trailing '_' tacked on. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org There is / One art / No more / No less To do / All things / With art- / -Lessness --Piet Hein -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Aug 8 06:17:52 2020 From: imp at bsdimp.com (Warner Losh) Date: Fri, 7 Aug 2020 14:17:52 -0600 Subject: [TUHS] [COFF] Unix and SW Releases (was V7 et al from Will) In-Reply-To: References: Message-ID: On Fri, Aug 7, 2020 at 8:27 AM John Cowan wrote: > Broadly yes. 2BSD was for the PDP-11, and while it could probably have > been ported to another 16-bit box, I don't think that was ever done by > anyone. > I'm not aware of any 16-but 2BSD ports. In fact, I'm aware of only one 2BSD port, and that's RetroBSD to a 32-bit, though highly constrained, MIPS PIC part. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Aug 8 06:23:25 2020 From: imp at bsdimp.com (Warner Losh) Date: Fri, 7 Aug 2020 14:23:25 -0600 Subject: [TUHS] [COFF] Unix and SW Releases (was V7 et al from Will) In-Reply-To: References: Message-ID: On Fri, Aug 7, 2020 at 9:37 AM Clem Cole wrote: > By the time of the 2X releases, UC Berekely had the C30 IMP ( *i.e. *direct > internet connection). So, once you were licensed, you got the keys to be > able to FTP different 'tapes' (which included sources and binaries), be it > 2X or 4X base But, since CSRG stopped focusing on 16-bit, the 2X stuff > became more of labor of love and was a bit less formal and was done with > cooperation with the CSRG team. > 2.8BSD was supposed to be the last PDP-11 release: A final wrapup of everything, according to the release notes. However, there were a lot of PDP-11s in specialized niches that weren't easily replaced by more modern hardware, so 2.9, 2.10 and 2.11 happened as well. The formality of the release seemed to diminish a bit at each step (though that may just be my perceptions). By the time we arrive at 2.11BSD, the tapes were produced by USENIX where you had to send proof of license to get the tape... These releases were driven by Seismo, and the USGS and/or military deployments from everything I've read... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Aug 8 06:48:16 2020 From: imp at bsdimp.com (Warner Losh) Date: Fri, 7 Aug 2020 14:48:16 -0600 Subject: [TUHS] Debugging help sought In-Reply-To: <20200807160723.5E16918C08B@mercury.lcs.mit.edu> References: <20200807160723.5E16918C08B@mercury.lcs.mit.edu> Message-ID: On Fri, Aug 7, 2020 at 10:08 AM Noel Chiappa wrote: > > From: Warner Losh > > The error comes from lookloc. This is called for external type > > relocations. It searches the local symbol table for something that > > matches the relocation entry. This error happens when it can't find > > it... > > Someone who actually looked at the source: > > https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/ld.c > > instead of just guessing. Give that man a star! > I've spent some time in ld.c lately: https://github.com/bsdimp/mk211bsd/blob/master/hints/160.ld.diff since I had to retro-fit the new archive support into the 2.10.1BSD + patches posted to comp.bugs.2bsd version of ld I needed for 2.11BSDpl0 :) Ideally, nobody would be able to tell my retrofits from the usenet patch that's also in this diff... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Aug 8 07:07:52 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 7 Aug 2020 17:07:52 -0400 Subject: [TUHS] [COFF] Unix and SW Releases (was V7 et al from Will) In-Reply-To: References: Message-ID: On Fri, Aug 7, 2020 at 4:23 PM Warner Losh wrote: > 2.8BSD was supposed to be the last PDP-11 release: A final wrapup of > everything, according to the release notes. > Yeah, that sounds right. Bostic had moved into CSRG and I think he was hacking on it less and less. Also Ultrix/PDP-11 was out by then and Fred Cantor had sort of displaced Keith as the PDP-11/UNIX wizard. > However, there were a lot of PDP-11s in specialized niches that weren't > easily replaced by more modern hardware, so 2.9, 2.10 and 2.11 happened as > well. > You tell me from looking at the sources, do you know if there was any back population to these releases from DEC? The Ultrix team (aps et al) had fed CRSG drivers and some stuff for the Vax. Fred had a goal (took some pride) in trying to make the PDP-11/Ultrix release very much plug and play, but I had personally lost interest in the PDP-11 by then so I was not watching it directly, only socially knowing many of the players. > The formality of the release seemed to diminish a bit at each step (though > that may just be my perceptions). > Well, the formality of anything before that was happenstance. Because CSRG was getting more formal, I think Keith and company were trying to parrot the same schemes. As I said, 4.1 and before like, Research was sort of the state of the world when Joy made the tape. To be fair, disk space was expensive. So keeping a big hunk of space dedicated to the 'release bits' was not really reasonable much less imaginable. It was only with CRSG that for the Vax there was 'enough' hardware to have test machines and dedicated distribution. > By the time we arrive at 2.11BSD, the tapes were produced by USENIX where > you had to send proof of license to get the tape... These releases were > driven by Seismo, and the USGS and/or military deployments from everything > I've read... > That sounds right. By the time of later 2.X versions UCB folks were much less involved and I think you might be that USENIX took over some distribution work (I was not on the board then, Steve might have been). Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sun Aug 9 11:00:00 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 9 Aug 2020 11:00:00 +1000 (EST) Subject: [TUHS] Regular Expressions In-Reply-To: <88FBBEDA-3D60-4782-9C4B-43C64691BC35@humeweb.com> References: <6e9ca056-dfb0-376d-effd-e41c9ed3ef2a@gmail.com> <88FBBEDA-3D60-4782-9C4B-43C64691BC35@humeweb.com> Message-ID: On Fri, 31 Jul 2020, Andrew Hume wrote: > i had concocted a massive RE that matched all the known spellings of > saddam hussein. (it was complicated, and there were many different > romanizations active at the time.) Another neat test was to run it against all the variations of "Muammar Gaddafi" and its various Anglicised spellings. -- Dave From beebe at math.utah.edu Sun Aug 9 11:15:35 2020 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Sat, 8 Aug 2020 19:15:35 -0600 Subject: [TUHS] Regular Expressions In-Reply-To: Message-ID: Dave Horsfall writes about complex regular expressions: >> ... a test was to run it against all the variations of "Muammar >> Gaddafi" and its various Anglicised spellings. The name "Chebyshev" is well known in numerical computation in mathematics, science, and engineering. This Web site lists 207 variants in its transliteration from the Cyrillic alphabet to the Roman one: https://mathreader.livejournal.com/9239.html The MathSciNet and zbMATH databases each record more than 4300 publications with "Chebyshev" in their titles. Alas, no online publication database that I know of permits regular expressions in searches, so finding publications that use the 200+ variants would be rather difficult. ------------------------------------------------------------------------------- - 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 at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From will.senn at gmail.com Mon Aug 10 07:05:35 2020 From: will.senn at gmail.com (Will Senn) Date: Sun, 9 Aug 2020 16:05:35 -0500 Subject: [TUHS] 211bsd kermit working Message-ID: <40bd6da0-b83d-7963-1bc6-ab562bbde287@gmail.com> I'm running 211bsd pl 431 in SimH on FreeBSD. I've got networking working on a tap interface both inbound and outbound. I still have a few issues hanging around that are bugging me, but I'll eventually get to them. One that is of concern at the moment is kermit. It is in the system under /usr/new/kermit. When I call it, I get: kermit Bad system call - core dumped I don't see core anywhere and if I did, I'd need to figure out what to do with it anyway (mabye adb), but I'm wondering if anyone's used kermit successfully who is on pl 431 or knows what's going on? Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Aug 10 07:12:34 2020 From: clemc at ccc.com (Clem Cole) Date: Sun, 9 Aug 2020 17:12:34 -0400 Subject: [TUHS] 211bsd kermit working In-Reply-To: <40bd6da0-b83d-7963-1bc6-ab562bbde287@gmail.com> References: <40bd6da0-b83d-7963-1bc6-ab562bbde287@gmail.com> Message-ID: try this: adb /usr/new/kermit Then run it and let it crash. You'll get an adb prompt, look at the stack and see what system call number was pushed. I suspect it a versioning issue that Warner has been discussing as 2.X changed over time. That said, it might just be easier to try to recompile c-kermit. Clem On Sun, Aug 9, 2020 at 5:06 PM Will Senn wrote: > I'm running 211bsd pl 431 in SimH on FreeBSD. I've got networking working > on a tap interface both inbound and outbound. I still have a few issues > hanging around that are bugging me, but I'll eventually get to them. One > that is of concern at the moment is kermit. It is in the system under > /usr/new/kermit. When I call it, I get: > > kermit > Bad system call - core dumped > > I don't see core anywhere and if I did, I'd need to figure out what to do > with it anyway (mabye adb), but I'm wondering if anyone's used kermit > successfully who is on pl 431 or knows what's going on? > > Thanks, > > Will > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Mon Aug 10 07:31:36 2020 From: will.senn at gmail.com (Will Senn) Date: Sun, 9 Aug 2020 16:31:36 -0500 Subject: [TUHS] 211bsd kermit working In-Reply-To: References: <40bd6da0-b83d-7963-1bc6-ab562bbde287@gmail.com> Message-ID: <53608f1c-4bcc-a15c-7ca2-3317879a157c@gmail.com> Well, that sure sounds easy. I found the core file and figured out that: adb /usr/new/kermit kermit.core was the incantation to load stuff into adb. $c is the stack trace: $c 0177520: ~signal(016,01) from ~sysinit+034 0177542: ~sysinit() from ~main+010 0177560: _main() from start+0104 adb> ^D If this means it got signal 16... or 1 from the sysinit call (called from main), then according to man signal 16's urgent condition present on socket, and 01's just hangup. 's all greek to me at this point. I'm super new to adb. I tried your approach adb /usr/new/kermit and it brought up the adb prompt, so I gather it works that way too, but I couldn't figure out how to run it from there. A quick perusal of the adb man page didn't really help. I'm off to finish reading the ADB tutorial that I bailed on last week in v7 after I hit the there's no fcreat in v7 issue  :). Will On 8/9/20 4:12 PM, Clem Cole wrote: > try this: adb /usr/new/kermit > Then run it and let it crash.  You'll get an adb prompt, look at the > stack and see what system call number was pushed. > > I suspect it a versioning issue that Warner has been discussing as 2.X > changed over time. > > That said, it might just be easier to try to recompile c-kermit. > > Clem > > On Sun, Aug 9, 2020 at 5:06 PM Will Senn > wrote: > > I'm running 211bsd pl 431 in SimH on FreeBSD. I've got networking > working on a tap interface both inbound and outbound. I still have > a few issues hanging around that are bugging me, but I'll > eventually get to them. One that is of concern at the moment is > kermit. It is in the system under /usr/new/kermit. When I call it, > I get: > > kermit > Bad system call - core dumped > > I don't see core anywhere and if I did, I'd need to figure out > what to do with it anyway (mabye adb), but I'm wondering if > anyone's used kermit successfully who is on pl 431 or knows what's > going on? > > Thanks, > > Will > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF > -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Mon Aug 10 09:21:06 2020 From: imp at bsdimp.com (Warner Losh) Date: Sun, 9 Aug 2020 17:21:06 -0600 Subject: [TUHS] 211bsd kermit working In-Reply-To: <40bd6da0-b83d-7963-1bc6-ab562bbde287@gmail.com> References: <40bd6da0-b83d-7963-1bc6-ab562bbde287@gmail.com> Message-ID: Maybe rebuild kermit? A crapton of compat stuff was removed over time. Maybe the binary is stale? Warner On Sun, Aug 9, 2020, 3:06 PM Will Senn wrote: > I'm running 211bsd pl 431 in SimH on FreeBSD. I've got networking working > on a tap interface both inbound and outbound. I still have a few issues > hanging around that are bugging me, but I'll eventually get to them. One > that is of concern at the moment is kermit. It is in the system under > /usr/new/kermit. When I call it, I get: > > kermit > Bad system call - core dumped > > I don't see core anywhere and if I did, I'd need to figure out what to do > with it anyway (mabye adb), but I'm wondering if anyone's used kermit > successfully who is on pl 431 or knows what's going on? > > Thanks, > > Will > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Mon Aug 10 09:44:11 2020 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 10 Aug 2020 09:44:11 +1000 (EST) Subject: [TUHS] Regular Expressions In-Reply-To: <202008012112.071LCsdo037245@tahoe.cs.Dartmouth.EDU> References: <202008012112.071LCsdo037245@tahoe.cs.Dartmouth.EDU> Message-ID: On Sat, 1 Aug 2020, Doug McIlroy wrote: > This lesson came home with a vengeance when Al Aho wrote egrep, which > implemented full regular expressions as DFA's. I happened to be writing > calendar(1) at the same time, and used egrep to search calendar files > for dates in rather free formats for today and all days through the next > working day. [...] I heard somewhere (a Usenix paper?) that "egrep" turned out to be faster than "fgrep" (designed to look for fixed strings only), thus "egrep" is now symlinked everywhere. On my FreeBSD box (in /usr/bin): aneurin% ls -li *grep 25471 -r-xr-xr-x 7 root wheel 40744 Oct 15 2017 bsdgrep 25480 -r-xr-xr-x 9 root wheel 82136 Oct 15 2017 bzegrep 25480 -r-xr-xr-x 9 root wheel 82136 Oct 15 2017 bzfgrep 25480 -r-xr-xr-x 9 root wheel 82136 Oct 15 2017 bzgrep 25480 -r-xr-xr-x 9 root wheel 82136 Oct 15 2017 egrep 25480 -r-xr-xr-x 9 root wheel 82136 Oct 15 2017 fgrep 25480 -r-xr-xr-x 9 root wheel 82136 Oct 15 2017 grep 25471 -r-xr-xr-x 7 root wheel 40744 Oct 15 2017 lzegrep 25471 -r-xr-xr-x 7 root wheel 40744 Oct 15 2017 lzfgrep 25471 -r-xr-xr-x 7 root wheel 40744 Oct 15 2017 lzgrep 23554 lrwxr-xr-x 1 root wheel 10 Feb 18 2011 pgrep -> /bin/pgrep 25471 -r-xr-xr-x 7 root wheel 40744 Oct 15 2017 xzegrep 25471 -r-xr-xr-x 7 root wheel 40744 Oct 15 2017 xzfgrep 25471 -r-xr-xr-x 7 root wheel 40744 Oct 15 2017 xzgrep 25480 -r-xr-xr-x 9 root wheel 82136 Oct 15 2017 zegrep 25480 -r-xr-xr-x 9 root wheel 82136 Oct 15 2017 zfgrep 25480 -r-xr-xr-x 9 root wheel 82136 Oct 15 2017 zgrep OK, there's a few strays in there... -- Dave From dave at horsfall.org Mon Aug 10 09:53:14 2020 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 10 Aug 2020 09:53:14 +1000 (EST) Subject: [TUHS] Regular Expressions In-Reply-To: References: Message-ID: On Sat, 8 Aug 2020, Nelson H. F. Beebe wrote: > The name "Chebyshev" is well known in numerical computation in > mathematics, science, and engineering. This Web site lists 207 variants > in its transliteration from the Cyrillic alphabet to the Roman one: > > https://mathreader.livejournal.com/9239.html Interesting; I was taught it was "Chebychev", which as second ranking doesn't even come close to "Chebyshev"... Possibly a cultural thing; I went to an Australian university (UNSW). -- Dave From dave at horsfall.org Mon Aug 10 10:48:00 2020 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 10 Aug 2020 10:48:00 +1000 (EST) Subject: [TUHS] BTL summer employees In-Reply-To: <202008021340.072Demtg086822@tahoe.cs.Dartmouth.EDU> References: <202008021340.072Demtg086822@tahoe.cs.Dartmouth.EDU> Message-ID: On Sun, 2 Aug 2020, Doug McIlroy wrote: > Even high-school employees could make lasting contributions. I am > indebted to Steve for a technique he conceived during his first summer > assignment: using macro definitions as if they were units of associative > memory. This view of macros stimulated previously undreamed-of uses. I'd like to see an example or two of that... Of course, if you want to see macros etc abused, then take a look at the Obfuscated C Code Contest :-) -- Dave From robpike at gmail.com Mon Aug 10 10:50:41 2020 From: robpike at gmail.com (Rob Pike) Date: Mon, 10 Aug 2020 10:50:41 +1000 Subject: [TUHS] Regular Expressions In-Reply-To: References: <202008012112.071LCsdo037245@tahoe.cs.Dartmouth.EDU> Message-ID: Ken's grep for Plan 9 beats them all. % time /usr/local/plan9/bin/grep -c . /tmp/x 39536274 real 0m1.731s user 0m1.568s sys 0m0.158s % time /usr/bin/egrep -c . /tmp/x 39536274 real 0m9.798s user 0m9.644s sys 0m0.153s % % time /usr/local/plan9/bin/grep -c '(ab|cd)' /tmp/x 1023171 real 0m1.719s user 0m1.560s sys 0m0.158s % time /usr/bin/egrep -c '(ab|cd)' /tmp/x 1023171 real 0m32.692s user 0m32.525s sys 0m0.166s-rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Mon Aug 10 10:53:30 2020 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 9 Aug 2020 17:53:30 -0700 Subject: [TUHS] BTL summer employees In-Reply-To: References: <202008021340.072Demtg086822@tahoe.cs.Dartmouth.EDU> Message-ID: <20200810005330.GX21711@mcvoy.com> On Mon, Aug 10, 2020 at 10:48:00AM +1000, Dave Horsfall wrote: > On Sun, 2 Aug 2020, Doug McIlroy wrote: > > >Even high-school employees could make lasting contributions. I am > >indebted to Steve for a technique he conceived during his first summer > >assignment: using macro definitions as if they were units of associative > >memory. This view of macros stimulated previously undreamed-of uses. > > I'd like to see an example or two of that... I don't have any up my sleeve, but I've seen this play out over and over. Some hot shot young kid shows up, the gray beards say "solve this impossible problem" and half the time they do. It's pretty cool. From dave at horsfall.org Mon Aug 10 10:53:26 2020 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 10 Aug 2020 10:53:26 +1000 (EST) Subject: [TUHS] 211bsd kermit working In-Reply-To: <53608f1c-4bcc-a15c-7ca2-3317879a157c@gmail.com> References: <40bd6da0-b83d-7963-1bc6-ab562bbde287@gmail.com> <53608f1c-4bcc-a15c-7ca2-3317879a157c@gmail.com> Message-ID: On Sun, 9 Aug 2020, Will Senn wrote: > Well, that sure sounds easy. I found the core file and figured out that: > > adb /usr/new/kermit kermit.core > > was the incantation to load stuff into adb. $c is the stack trace: > $c > 0177520: ~signal(016,01) from ~sysinit+034 > 0177542: ~sysinit() from ~main+010 > 0177560: _main() from start+0104 > adb> ^D > > If this means it got signal 16... or 1 from the sysinit call (called > from main), then according to man signal 16's urgent condition present > on socket, and 01's just hangup. [...] Is not "016" octal i.e. 14 i.e. SIGTERM in older versions of *x? -- Dave From cowan at ccil.org Mon Aug 10 11:38:55 2020 From: cowan at ccil.org (John Cowan) Date: Sun, 9 Aug 2020 21:38:55 -0400 Subject: [TUHS] Regular Expressions In-Reply-To: References: Message-ID: On Sun, Aug 9, 2020 at 7:53 PM Dave Horsfall wrote: Interesting; I was taught it was "Chebychev", which as second ranking > doesn't even come close to "Chebyshev"... > "Chebychev" is downright bizarre. The first "Ch" is as in English "Chebyshev", the second is as in French "Tchebychev". The other variants are mostly explicable: for example, in German it's "Tschebyschew". The final vowel is written "e" but pronounced "o" in Russian, and can come out either way in transliteration. Likewise, the final "v" is pronounced "f", and can be written "v" or "ff" in transliteration. Tolstoy was affected by this too: his first name is usually given as either "Leo" (which is what it means) or "Lev" nowadays, but in the 19C it was usually spelled "Lyoff" (one syllable), which is how it's pronounced. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org You are a child of the universe no less than the trees and all other acyclic graphs; you have a right to be here. --DeXiderata by Sean McGrath -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Mon Aug 10 11:42:53 2020 From: will.senn at gmail.com (Will Senn) Date: Sun, 9 Aug 2020 20:42:53 -0500 Subject: [TUHS] 211bsd kermit working In-Reply-To: References: <40bd6da0-b83d-7963-1bc6-ab562bbde287@gmail.com> <53608f1c-4bcc-a15c-7ca2-3317879a157c@gmail.com> Message-ID: On 8/9/20 7:53 PM, Dave Horsfall wrote: > On Sun, 9 Aug 2020, Will Senn wrote: > >> Well, that sure sounds easy. I found the core file and figured out that: >> >> adb /usr/new/kermit kermit.core >> >> was the incantation to load stuff into adb. $c is the stack trace: >> $c >> 0177520: ~signal(016,01) from ~sysinit+034 >> 0177542: ~sysinit() from ~main+010 >> 0177560: _main() from start+0104 >> adb> ^D >> >> If this means it got signal 16... or 1 from the sysinit call (called >> from main), then according to man signal 16's urgent condition >> present on socket, and 01's just hangup. [...] > > Is not "016" octal i.e. 14 i.e. SIGTERM in older versions of *x? > > -- Dave Good catch on the octal, but here's the list from man signal: SIGALRM   14   alarm clock SIGTERM   15   software termination signal SIGURG    16@  urgent condition present on socket So, SIGALRM? Hmm.. I'm prolly gonna try to rebuild as Warner suggests... if I can locate the src. Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Mon Aug 10 16:33:57 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 10 Aug 2020 06:33:57 +0000 Subject: [TUHS] BTL summer employees In-Reply-To: <202008021340.072Demtg086822@tahoe.cs.Dartmouth.EDU> (Doug McIlroy's message of "Sun, 02 Aug 2020 09:40:48 -0400") References: <202008021340.072Demtg086822@tahoe.cs.Dartmouth.EDU> Message-ID: <7wr1sf2ene.fsf@junk.nocrew.org> Not a summer employee, but an MIT undergrad intern for most of a year, Alan Snyder was involved with the transition from B to C, suggested the use of a preprocessor, and the && and || operators. He brought Yacc and C with him back to MIT and the Dynamic Modeling PDP-10. He wrote a retargetable C compiler and a host of Unix utilities for ITS. This confused the rest of the users, who couldn't make sense of the terminal after AS has logged off. The C language enjoyed a rather modest success on the ITS operating system; for example the "R" typesetting program and the Dover printer spooler was written using Snyder's C compiler. From jnc at mercury.lcs.mit.edu Mon Aug 10 22:53:22 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 10 Aug 2020 08:53:22 -0400 (EDT) Subject: [TUHS] BTL summer employees Message-ID: <20200810125322.D85FD18C082@mercury.lcs.mit.edu> > From: Lars Brinkhoff > the Dover printer spooler was written using Snyder's C compiler I'm not sure if that's correct. I don't remember with crystal clarity all the details of how we got files to the Dover, but here's what I recall (take with 1/2 a grain of salt, my memory may have dropped some bits). To start with, there were different paths from the CHAOS and TCP/IP worlds. IIRC, there was a spooler on the Alto which ran the Dover, and the two worlds had separate paths to get to it. >From the CHAOS world, there was a protocol translation which ran on whatever machine had the AI Lab's 3Mbit Ethernet interface - probably MIT-AI's CHAOS-11? If you look at the Macro-11 code from that, you should see it - IIRC it translated (on the fly) from CHAOS to EFTP, the PUP prototocol which the spooler ran 'natively'. >From the IP world, IIRC, Dave Clark had adapted his Alto TCP/IP stack (written in BCPL) to run in the spooler alongside the PUP software; it included a TFTP server, and people ran TFTP from TCP/IP machines to talk to it. (IP access to the 3Mbit Ethernet was via another UNIBUS Ethernet interface which was plugged into an IP router which I had written. The initial revision was in Macro-11; a massive kludge which used hairy macrology to produce N^2 discrete code paths, one for every pair of interfaces on the machine. Later that was junked, and replaced with the 'C Gateway' code.) I can, if people are interested, look on the MIT-CSR machine dump I have to see how it (a TCP/IP machine) printed on the Dover, to confirm that it used TFTP. I don't recall a role for any PDP-10 C code, though. I don't think there was a spooler anywhere except on the Dover's Alto. Where did that bit about the PDP-10 spooler in C come from, may I enquire? Was it a CMU thing, or something like that? Noel From jnc at mercury.lcs.mit.edu Mon Aug 10 23:12:32 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 10 Aug 2020 09:12:32 -0400 (EDT) Subject: [TUHS] 211bsd kermit working Message-ID: <20200810131232.14B6E18C082@mercury.lcs.mit.edu> > From: Will Senn > $c > 0177520: ~signal(016,01) from ~sysinit+034 > 0177542: ~sysinit() from ~main+010 > 0177560: _main() from start+0104 > If this means it got signal 16... or 1 from the sysinit call (called > from main) I'm not sure that interpretation is correct. I think that trace shows signal() being called from sysinit(). On V6, signal() was a system call which one could use to set the handlers for signals (or set them to be ignored, or back to the default action). In. 2.11 it seems to be a shim layer which provides the same interface, but uses the Berserkly signal system interface underneath: https://www.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/include/signal.h https://www.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/man/cat3/signal.0 So maybe the old binary for kermit is still trying to use the (perhaps now-removed) signal system call? Noel From lars at nocrew.org Mon Aug 10 23:21:29 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 10 Aug 2020 13:21:29 +0000 Subject: [TUHS] BTL summer employees In-Reply-To: <20200810125322.D85FD18C082@mercury.lcs.mit.edu> (Noel Chiappa's message of "Mon, 10 Aug 2020 08:53:22 -0400 (EDT)") References: <20200810125322.D85FD18C082@mercury.lcs.mit.edu> Message-ID: <7wblji3acm.fsf@junk.nocrew.org> Noel Chiappa writes: > > the Dover printer spooler was written using Snyder's C compiler > > I'm not sure if that's correct. I haven't investigated it thoroughly, but I do see a file .DOVR.;.SPOOL 8 written in C by Eliot Moss. /* This program scans the directory .DOVR. for files whose first name starts with A-Z, and attempts to send them to the DOVER. If they are not PRESS files, or if they are successfully transmitted, they are deleted. It writes a log into .DOVR.;YYMMDD %LOG where YYMMDD is the year, month and day. It will keep N log files, where N is a compile time parameter. When sending to the DOVER, the spooler waits until Spruce is free before sending another file. [...] Written 24 January 1980, by EBM From will.senn at gmail.com Mon Aug 10 23:24:17 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 10 Aug 2020 08:24:17 -0500 Subject: [TUHS] 211bsd kermit working In-Reply-To: <20200810131232.14B6E18C082@mercury.lcs.mit.edu> References: <20200810131232.14B6E18C082@mercury.lcs.mit.edu> Message-ID: <2cd016ff-3441-2c0e-ec22-85cba2b67293@gmail.com> On 8/10/20 8:12 AM, Noel Chiappa wrote: > > From: Will Senn > > > $c > > 0177520: ~signal(016,01) from ~sysinit+034 > > 0177542: ~sysinit() from ~main+010 > > 0177560: _main() from start+0104 > > > If this means it got signal 16... or 1 from the sysinit call (called > > from main) > > I'm not sure that interpretation is correct. I think that trace shows signal() > being called from sysinit(). > > On V6, signal() was a system call which one could use to set the handlers for > signals (or set them to be ignored, or back to the default action). In. 2.11 > it seems to be a shim layer which provides the same interface, but uses > the Berserkly signal system interface underneath: > > https://www.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/include/signal.h > https://www.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/man/cat3/signal.0 > > So maybe the old binary for kermit is still trying to use the (perhaps > now-removed) signal system call? > > Noel > Noel, That makes a lot more sense. I'm still trying to locate source. Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF From jnc at mercury.lcs.mit.edu Tue Aug 11 00:02:16 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 10 Aug 2020 10:02:16 -0400 (EDT) Subject: [TUHS] BTL summer employees Message-ID: <20200810140216.47CB418C082@mercury.lcs.mit.edu> > From: Lars Brinkhoff > I haven't investigated it thoroughly, but I do see a file .DOVR.;.SPOOL > 8 written in C by Eliot Moss. > ... > When sending to the DOVER, the spooler waits until Spruce is > free before sending another file. Ah, so there was a spooler on the ITS machine as well; I didn't know/remember that. I checked on CSR, and it did use TFTP to send it to the Alto spooler: HOST MIT-SPOOLER, LCS 2/200,SERVER,TFTPSP,ALTO,[SPOOLER] I vaguely recall the Dover being named 'Spruce', but that name wasn't in the host table... I have this vague memory that 'MIT-Spooler' was the Alto which prove the Dover, but now that I think about it, it might have been another one (which ran only TFTP->EFTP spooler software). IIRC the Dover as a pain to run, it required a very high bit rate, and the software to massage it was very tense; so it may have made sense to do the TFTP->EFTP (I'm pretty sure the vanilla Dover spoke EFTP, but maybe I'm wrong, and it used the PUP stream protocol) in another machine. It'd be interesting to look at the Dover spooler on ITS, and see if/how one got to the CHAOS network from C - and if so, how it identified the protocol translating box. Noel From stewart at serissa.com Tue Aug 11 03:08:20 2020 From: stewart at serissa.com (Lawrence Stewart) Date: Mon, 10 Aug 2020 13:08:20 -0400 Subject: [TUHS] BTL summer employees In-Reply-To: <20200810140216.47CB418C082@mercury.lcs.mit.edu> References: <20200810140216.47CB418C082@mercury.lcs.mit.edu> Message-ID: <81311578-1C53-47F3-930C-8F0A950D4284@serissa.com> > On 2020, Aug 10, at 10:02 AM, Noel Chiappa wrote: > >> From: Lars Brinkhoff > >> I haven't investigated it thoroughly, but I do see a file .DOVR.;.SPOOL >> 8 written in C by Eliot Moss. >> ... >> When sending to the DOVER, the spooler waits until Spruce is >> free before sending another file. > > Ah, so there was a spooler on the ITS machine as well; I didn't know/remember > that. > > I checked on CSR, and it did use TFTP to send it to the Alto spooler: > > HOST MIT-SPOOLER, LCS 2/200,SERVER,TFTPSP,ALTO,[SPOOLER] > > I vaguely recall the Dover being named 'Spruce', but that name wasn't in the > host table... I have this vague memory that 'MIT-Spooler' was the Alto which > prove the Dover, but now that I think about it, it might have been another one > (which ran only TFTP->EFTP spooler software). IIRC the Dover as a pain to run, > it required a very high bit rate, and the software to massage it was very > tense; so it may have made sense to do the TFTP->EFTP (I'm pretty sure the > vanilla Dover spoke EFTP, but maybe I'm wrong, and it used the PUP stream > protocol) in another machine. > > It'd be interesting to look at the Dover spooler on ITS, and see if/how one > got to the CHAOS network from C - and if so, how it identified the protocol > translating box. > > Noel “A pain to run” and “tense” indeed! The Dover printing system was an Alto (6 MIPs ) driving “Orbit” hardware about half the size of the Alto itself*, driving the raster video to the printer. The hardware was called “orbit” because it could directly “OR” bits into the raster image, rather than requiring read-modify-write cycles. “Spruce” was the spooler and printer driver that ran on the Alto. Evidently the hardware is a typical Butler Lampson knife edge design up in the corner of what was possible, implemented by Bob Sproull and Severo Ornstein. Additional software by Dan Swinehart. There’s a page about this in https://bwlampson.site/38-AltoSoftware/Abstract.html and a patent https://patents.google.com/patent/US4203154 . I have a feeling I’ve seen a longer description of Orbit somewhere but I can’t remember where. Like most Stanford folks of the era I printed my thesis on one, assisted about 1 AM by Lyle Ramshaw who knew where to get a new drum for the printer. In any event, a vast improvement over the XGP and a godsend for those of us who have a phototypesetter. * An earlier one-off called EARS had printer hardware about 3 times the size of the attached Alto. That one was font-image based. To do things like lines and graphics the software constructed custom font glyphs to make up the image. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Tue Aug 11 04:13:29 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 10 Aug 2020 18:13:29 +0000 Subject: [TUHS] BTL summer employees In-Reply-To: <81311578-1C53-47F3-930C-8F0A950D4284@serissa.com> (Lawrence Stewart's message of "Mon, 10 Aug 2020 13:08:20 -0400") References: <20200810140216.47CB418C082@mercury.lcs.mit.edu> <81311578-1C53-47F3-930C-8F0A950D4284@serissa.com> Message-ID: <7w7du62wty.fsf@junk.nocrew.org> Noel Chiappa wrote: > It'd be interesting to look at the Dover spooler on ITS, and see > if/how one got to the CHAOS network from C - and if so, how it > identified the protocol translating box. It uses the C version of ITS system calls: chaoso() to open I/O channels, and pktiot() to send/receive packets. This is now straying out of TUHS territory, but I wouldn't want people to miss out on the Dover poem: Dover, oh Dover, arisen from dead. Dover, oh Dover, awoken from bed. Dover, oh Dover, welcome back to the Lab. Dover, oh Dover, we've missed your clean hand... And now your toner's toney, And your paper near pure white, The smudges on your soul are gone And your output's clean as light.. We've labored with your father, The venerable XGP, But his slow artistic hand, Lacks your clean velocity. Theses and papers And code in a queue Dover, oh Dover, We've been waiting for you. Disk blocks aplenty Await your laser drawn lines, Your intricate fonts, Your pictures and signs. Your amputative absence Has made the Ten dumb, Without you, Dover, We're system untounged- DRAW Plots and TEXage Have been biding their time, With LISP code and programs, And this crufty rhyme. Dover, oh Dover, We welcome you back, Though still you may jam, You're on the right track. -KWH 6/14/81 From will.senn at gmail.com Tue Aug 11 08:49:55 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 10 Aug 2020 17:49:55 -0500 Subject: [TUHS] in memoriam - Bill English, mouse co-creator Message-ID: <0bf32a22-d5a5-788f-a818-1fbe704a55bf@gmail.com> All, About a week ago, Bill English passed away. He was a Xerox guy, who along with Douglas Engelbart of "Mother of all demos" fame, created our beloved mouse: https://www.bbc.com/news/technology-53638033 I remember, back in the mid-1980's being part of a focus group evaluating Microsoft's mouse. Wow, time flies. -Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Aug 12 00:01:19 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 11 Aug 2020 10:01:19 -0400 Subject: [TUHS] in memoriam - Bill English, mouse co-creator In-Reply-To: <0bf32a22-d5a5-788f-a818-1fbe704a55bf@gmail.com> References: <0bf32a22-d5a5-788f-a818-1fbe704a55bf@gmail.com> Message-ID: Thanks, Will. A mild sigh while reading it though because history seems to often forget Jack Hawley's role. Truth is he did not invent it, but he >>is<< the one that made them and got people to use them (the Xerox Alto's used a Hawley Mouse, DEC would use it, E&S used them etc.). As this article points out, he made about 80% of all the mice used in the 1970s: https://www.oldmouse.com/mouse/hawley/ - certainly the first ones I used at CMU before we got the Altos and then after the first Alto's appeared. Tek's Magnolia used a flavor of the Hawley mouse in 1979 [the ones with buttons horizontal/parallel to the 'body' - the original Alto mouse the buttons were horizontal and colored), but I don't remember what 3Rivers PascAlto used - I think so, but I don't remember. On Mon, Aug 10, 2020 at 6:50 PM Will Senn wrote: > All, > > About a week ago, Bill English passed away. He was a Xerox guy, who along > with Douglas Engelbart of "Mother of all demos" fame, created our beloved > mouse: > > https://www.bbc.com/news/technology-53638033 > > I remember, back in the mid-1980's being part of a focus group evaluating > Microsoft's mouse. Wow, time flies. > > -Will > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From earl.baugh at gmail.com Wed Aug 12 03:30:14 2020 From: earl.baugh at gmail.com (Earl Baugh) Date: Tue, 11 Aug 2020 13:30:14 -0400 Subject: [TUHS] in memoriam - Bill English, mouse co-creator In-Reply-To: References: Message-ID: <5B43EBFF-B557-4FD3-8146-188D7ED4C64D@gmail.com> The Sun 1 also had a Hawley mouse ( as an early option ), before they switched to the optical. Earl Sent from my iPhone > On Aug 11, 2020, at 10:03 AM, Clem Cole wrote: > >  > Thanks, Will. A mild sigh while reading it though because history seems to often forget Jack Hawley's role. Truth is he did not invent it, but he >>is<< the one that made them and got people to use them (the Xerox Alto's used a Hawley Mouse, DEC would use it, E&S used them etc.). As this article points out, he made about 80% of all the mice used in the 1970s: https://www.oldmouse.com/mouse/hawley/ - certainly the first ones I used at CMU before we got the Altos and then after the first Alto's appeared. > > Tek's Magnolia used a flavor of the Hawley mouse in 1979 [the ones with buttons horizontal/parallel to the 'body' - the original Alto mouse the buttons were horizontal and colored), but I don't remember what 3Rivers PascAlto used - I think so, but I don't remember. > >> On Mon, Aug 10, 2020 at 6:50 PM Will Senn wrote: >> All, >> >> About a week ago, Bill English passed away. He was a Xerox guy, who along with Douglas Engelbart of "Mother of all demos" fame, created our beloved mouse: >> >> https://www.bbc.com/news/technology-53638033 >> >> I remember, back in the mid-1980's being part of a focus group evaluating Microsoft's mouse. Wow, time flies. >> >> -Will >> -- >> GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From stewart at serissa.com Wed Aug 12 03:40:06 2020 From: stewart at serissa.com (Lawrence Stewart) Date: Tue, 11 Aug 2020 13:40:06 -0400 Subject: [TUHS] in memoriam - Bill English, mouse co-creator In-Reply-To: <5B43EBFF-B557-4FD3-8146-188D7ED4C64D@gmail.com> References: <5B43EBFF-B557-4FD3-8146-188D7ED4C64D@gmail.com> Message-ID: <4E2C2AB2-A4F0-4A1D-B7F2-D1858384AC86@serissa.com> > On 2020, Aug 11, at 1:30 PM, Earl Baugh wrote: > > The Sun 1 also had a Hawley mouse ( as an early option ), before they switched to the optical. > > Earl > > Sent from my iPhone > >> On Aug 11, 2020, at 10:03 AM, Clem Cole wrote: >> >>  >> Thanks, Will. A mild sigh while reading it though because history seems to often forget Jack Hawley's role. Truth is he did not invent it, but he >>is<< the one that made them and got people to use them (the Xerox Alto's used a Hawley Mouse, DEC would use it, E&S used them etc.). As this article points out, he made about 80% of all the mice used in the 1970s: https://www.oldmouse.com/mouse/hawley/ - certainly the first ones I used at CMU before we got the Altos and then after the first Alto's appeared. >> >> Tek's Magnolia used a flavor of the Hawley mouse in 1979 [the ones with buttons horizontal/parallel to the 'body' - the original Alto mouse the buttons were horizontal and colored), but I don't remember what 3Rivers PascAlto used - I think so, but I don't remember. >> >> On Mon, Aug 10, 2020 at 6:50 PM Will Senn > wrote: >> All, >> >> About a week ago, Bill English passed away. He was a Xerox guy, who along with Douglas Engelbart of "Mother of all demos" fame, created our beloved mouse: >> >> https://www.bbc.com/news/technology-53638033 >> >> I remember, back in the mid-1980's being part of a focus group evaluating Microsoft's mouse. Wow, time flies. >> >> -Will >> -- >> GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF Hawley built the first mice used by PARC. The first optical mouse was invented, AFAIK, by Dick Lyon, see http://www.dicklyon.com/tech/OMouse/OpticalMouse-Lyon.pdf This paper has a brief history of Xerox mechanical mice as well. Dick is just a renaissance engineer, with contributions to hearing aids, the Fovea camera, and he later designed the Google Street View cameras. His book on Human and Machine Hearing is outstanding. -L -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Aug 12 09:41:33 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 12 Aug 2020 09:41:33 +1000 (EST) Subject: [TUHS] [simh] 2bsd tarball In-Reply-To: References: <6a0063f8-128d-751d-114f-a0f811d02098@gmail.com> <2cb3ad2a-f8c5-a003-661c-e257f7cbe38c@softjar.se> Message-ID: On Wed, 29 Jul 2020, John Cowan wrote: > When I talk about DECtape in my capacity as the local old fart, i > describe it as "a disk with one track and about 1500 small sectors that > spins ve-ry ve-ry slow-ly.. According to an ex-boss of mine, a demonstration of the DECtape's reliability was to blow cigarette smoke over the heads when the tape was moving (this was back when smoking was socially acceptable, if not actually encouraged). -- Dave From dave at horsfall.org Wed Aug 12 09:55:49 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 12 Aug 2020 09:55:49 +1000 (EST) Subject: [TUHS] [simh] 2bsd tarball In-Reply-To: <2d723104-6461-08ba-9235-99b06622f9fa@softjar.se> References: <6a0063f8-128d-751d-114f-a0f811d02098@gmail.com> <2cb3ad2a-f8c5-a003-661c-e257f7cbe38c@softjar.se> <5A12E0BB-4FFF-4C3E-B486-D4E852FAA97F@comcast.net> <2d723104-6461-08ba-9235-99b06622f9fa@softjar.se> Message-ID: On Wed, 29 Jul 2020, Johnny Billquist wrote: > However, seek times on DECtape aren't really comparable to magtape > either. Because DECtape deals with absolute block numbers. So you can > always, no matter where you are, find out where you are, and how far you > will need to move to get to the correct block. > > With magtapes, this is pretty much impossible. You'll have to rewind, > and then start seeking. Not if you used 512-byte blocks, and mounted it read-only; that way, you could use it as a file system (and I did, just for fun). Oh, you also needed a clever tape driver, of course. And the IRG was a bit of a problem, chewing up a lot of tape space. I posted this here a while back, and some idiot (his name is not important) practically called me a liar, until he was handed his arse on a plate by someone else with better knowledge than him. -- Dave From dave at horsfall.org Wed Aug 12 12:09:00 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 12 Aug 2020 12:09:00 +1000 (EST) Subject: [TUHS] CR delay for VT05 In-Reply-To: References: <20200719233207.BB69D2D9E6DD@macaroni.inf.ed.ac.uk> Message-ID: On Thu, 30 Jul 2020, Paul Winalski wrote: > The VT05 was designed to be a glass teletype. Literally. Hence the > screen width (same as a model 33 tty) and default upper-case only > transmission. The CR delay might be there to mimic the CR delay of a > model 33, too. Aha, thanks! I seem to recall that the VT05's timing was locked to the mains frequency, hence the delays were not easily changed. Hmmm... 50Hz vs. 60Hz? -- Dave From dave at horsfall.org Thu Aug 13 10:00:09 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 13 Aug 2020 10:00:09 +1000 (EST) Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <20200801013605.GG10778@mcvoy.com> References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> Message-ID: On Fri, 31 Jul 2020, Larry McVoy wrote: > On Fri, Jul 31, 2020 at 07:12:57PM -0400, Richard Salz wrote: >>> SMIT was quite nice [ context seemingly removed ] >> >> i have never seen those four words together like that before. > > Me neither. SMIT was HORRIBLE if you understood the files in /etc and > knew what to do with them. It might be nice if you had no understanding > of how to admin a Unix system and here is this "nice" curses based way > to do admin. SMIT was one just one of the systems that I had to sysadmin (along with Open/Xenix (hah!), Slowaris, PH-UX (as we called it), etc; I narrowly avoided Windoze, along with denying all knowledge of COBOL. > To anyone remotely competent, and I don't mean edit sendmail.cf, I mean > you can edit inetd.conf, you can edit a crontab file, etc, SMIT was a > nightmare that made something that should be vi $FILE, done 20 seconds > later, a hellish journey through their menus. It was AWFUL. Quite, because I liked the way that SMIT showed you the obtuse command that was being executed, so you could run it yourself with modifications. > Ask me how I know. Ditto... -- Dave From lm at mcvoy.com Thu Aug 13 11:47:20 2020 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 12 Aug 2020 18:47:20 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> Message-ID: <20200813014720.GP21027@mcvoy.com> You liked SMIT, it seems, I am among a large swath of people who did not. The SMIT I had did *not* show you what files it was editing and I ran SMIT on 1GB main memory powerpcs. I think it was AIX 4.something. Maybe it got better but it was awful for me. On Thu, Aug 13, 2020 at 10:00:09AM +1000, Dave Horsfall wrote: > On Fri, 31 Jul 2020, Larry McVoy wrote: > > >On Fri, Jul 31, 2020 at 07:12:57PM -0400, Richard Salz wrote: > >>>SMIT was quite nice [ context seemingly removed ] > >> > >>i have never seen those four words together like that before. > > > >Me neither. SMIT was HORRIBLE if you understood the files in /etc and > >knew what to do with them. It might be nice if you had no understanding > >of how to admin a Unix system and here is this "nice" curses based way to > >do admin. > > SMIT was one just one of the systems that I had to sysadmin (along with > Open/Xenix (hah!), Slowaris, PH-UX (as we called it), etc; I narrowly > avoided Windoze, along with denying all knowledge of COBOL. > > >To anyone remotely competent, and I don't mean edit sendmail.cf, I mean > >you can edit inetd.conf, you can edit a crontab file, etc, SMIT was a > >nightmare that made something that should be vi $FILE, done 20 seconds > >later, a hellish journey through their menus. It was AWFUL. > > Quite, because I liked the way that SMIT showed you the obtuse command that > was being executed, so you could run it yourself with modifications. > > >Ask me how I know. > > Ditto... > > -- Dave -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From cym224 at gmail.com Thu Aug 13 11:53:06 2020 From: cym224 at gmail.com (Nemo Nusquam) Date: Wed, 12 Aug 2020 21:53:06 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> Message-ID: <8816efce-edfa-a396-9eb3-11e16b803fee@gmail.com> On 08/12/20 20:00, Dave Horsfall wrote (in part): > SMIT was one just one of the systems that I had to sysadmin (along > with Open/Xenix (hah!), Slowaris, PH-UX (as we called it), etc; New one on me. We called it H-POX. N. From gtaylor at tnetconsulting.net Thu Aug 13 13:15:01 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 12 Aug 2020 21:15:01 -0600 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <20200813014720.GP21027@mcvoy.com> References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> <20200813014720.GP21027@mcvoy.com> Message-ID: On 8/12/20 7:47 PM, Larry McVoy wrote: > The SMIT I had did*not* show you what files it was editing My recollection is that smit(ty) did /not/ show you the commands that would be run /by/ /default/. That being said, there was a (P)F key you could press prior to executing, one of the many (P)F keys smit(ty) used, that would show you the command and all of it's arguments which would be run. I didn't like /using/ smit(ty) for much. But I did find it /useful/ for learning things which I didn't know by using the menu a few times and analyzing the command(s) that it would generate and run. I think it was a really advanced form of " command example" searches that I see people doing on the regular. The BIG advantage is that you used the menu interface to tweak parameters for your configuration. smit(ty) also had the added advantage that it could look up possible values of things to put in the fields for you. I don't know any seasoned AIX admins that use smit(ty) for their day to day, week to week, or even month to month activities. Though I think many of them end up using smit(ty) once every year or two to look at a particularly obtuse command. Sort of like a contextual aware man page. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From larry0 at me.com Thu Aug 13 14:02:20 2020 From: larry0 at me.com (Larry Cashdollar) Date: Thu, 13 Aug 2020 00:02:20 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: Message-ID: <21D18F80-1F88-4380-AA24-AEE5F815ACD0@me.com> Oh, I remember the Smitty person running at the top that would fall down when the command failed. Good times. -LC$ On Aug 12, 2020, at 11:15 PM, Grant Taylor via TUHS wrote: On 8/12/20 7:47 PM, Larry McVoy wrote: > The SMIT I had did*not* show you what files it was editing My recollection is that smit(ty) did /not/ show you the commands that would be run /by/ /default/. That being said, there was a (P)F key you could press prior to executing, one of the many (P)F keys smit(ty) used, that would show you the command and all of it's arguments which would be run. I didn't like /using/ smit(ty) for much. But I did find it /useful/ for learning things which I didn't know by using the menu a few times and analyzing the command(s) that it would generate and run. I think it was a really advanced form of " command example" searches that I see people doing on the regular. The BIG advantage is that you used the menu interface to tweak parameters for your configuration. smit(ty) also had the added advantage that it could look up possible values of things to put in the fields for you. I don't know any seasoned AIX admins that use smit(ty) for their day to day, week to week, or even month to month activities. Though I think many of them end up using smit(ty) once every year or two to look at a particularly obtuse command. Sort of like a contextual aware man page. -- Grant. . . . unix || die From crossd at gmail.com Fri Aug 14 03:14:17 2020 From: crossd at gmail.com (Dan Cross) Date: Thu, 13 Aug 2020 13:14:17 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <20200801013605.GG10778@mcvoy.com> References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> Message-ID: On Fri, Jul 31, 2020 at 9:37 PM Larry McVoy wrote: > On Fri, Jul 31, 2020 at 07:12:57PM -0400, Richard Salz wrote: > > > SMIT was quite nice > > > > i have never seen those four words together like that before. > > Me neither. SMIT was HORRIBLE if you understood the files in /etc and > knew what to do with them. The sysadmin in the CS department had a USENIX button on his wall: "SMIT happens." I always found that amusing. The Motif-version was especially horrible, and crashed all the time. The curses-based version was called `smitty`, which I found humorous in a way I wouldn't have expected coming from "This page intentionally left blank" IBM. In my mind, the worst part of admining RS/6000 boxes of that era was the little 3-digit LED code on the front: I guess those machines didn't assume that they had either a graphical head or a serial port, so this damn teeny tiny display would cycle through a sequence of codes that told you what the machine was doing; it came with a book that told you what each code meant. Something like "387" meant mounting /usr. Ugh; I just found a page on ibm.com describing these "IPL codes." It might be nice if you had no understanding > of how to admin a Unix system and here is this "nice" curses based way > to do admin. > The thing was that IBM changed a lot of stuff almost gratuitously. Specifics I remember were the print daemon (I ported `lpd` from 4.4BSD for that) and anything related to disks and filesystems. In fairness, they had logical volumes that could split across disks before most other Unix systems that I was working on at the time, but the commands were all custom to AIX and, frankly, weird: I remember that one would "vary on" a logical volume before one could mount a filesystem from it or something like that. I was told at the time that the people who'd built that side of things had come from the mainframe world, where that was the nomenclature. Creating JFS filesystems required these tools as well; there was new `newfs_jfs` as I recall. So I ended up using SMIT for basically anything related to filesystems, but for almost nothing else. To anyone remotely competent, and I don't mean edit sendmail.cf, I mean > you can edit inetd.conf, you can edit a crontab file, etc, SMIT was a > nightmare that made something that should be vi $FILE, done 20 seconds > later, a hellish journey through their menus. It was AWFUL. > One of the more gratuitous differences I remember from AIX was that instead of having e.g. /etc/shadow, they had /etc/password (all spelled out), which had semi-structured stanzas for each user. That was just weird. Fortunately, we were using NIS and it was smart enough to ignore that for NIS users. Ask me how I know. > I still have nightmares about AIX. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Fri Aug 14 03:19:18 2020 From: henry.r.bent at gmail.com (Henry Bent) Date: Thu, 13 Aug 2020 13:19:18 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> Message-ID: On Thu, 13 Aug 2020 at 13:16, Dan Cross wrote: > > The Motif-version was especially horrible, and crashed all the time. The > curses-based version was called `smitty`, which I found humorous in a way I > wouldn't have expected coming from "This page intentionally left blank" > IBM. In my mind, the worst part of admining RS/6000 boxes of that era was > the little 3-digit LED code on the front: I guess those machines didn't > assume that they had either a graphical head or a serial port, so this damn > teeny tiny display would cycle through a sequence of codes that told you > what the machine was doing; it came with a book that told you what each > code meant. Something like "387" meant mounting /usr. Ugh; I just found a > page on ibm.com describing these "IPL codes." > > That seems to have been a general IBM-ism. The BIOSes were the same way - they would display a series of numeric codes on the screen and if it stopped somewhere you had to drag out the manual and look up why. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Aug 14 03:58:30 2020 From: imp at bsdimp.com (Warner Losh) Date: Thu, 13 Aug 2020 11:58:30 -0600 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> Message-ID: On Thu, Aug 13, 2020, 11:20 AM Henry Bent wrote: > > > On Thu, 13 Aug 2020 at 13:16, Dan Cross wrote: > >> >> The Motif-version was especially horrible, and crashed all the time. The >> curses-based version was called `smitty`, which I found humorous in a way I >> wouldn't have expected coming from "This page intentionally left blank" >> IBM. In my mind, the worst part of admining RS/6000 boxes of that era was >> the little 3-digit LED code on the front: I guess those machines didn't >> assume that they had either a graphical head or a serial port, so this damn >> teeny tiny display would cycle through a sequence of codes that told you >> what the machine was doing; it came with a book that told you what each >> code meant. Something like "387" meant mounting /usr. Ugh; I just found a >> page on ibm.com describing these "IPL codes." >> >> > That seems to have been a general IBM-ism. The BIOSes were the same way - > they would display a series of numeric codes on the screen and if it > stopped somewhere you had to drag out the manual and look up why. > I have a port 80 decoder that let's me see the same thing but w/o the need for video to work... the same codes on the screen were outb'd to port 80... came in handy for driver debugging too Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Fri Aug 14 05:18:03 2020 From: athornton at gmail.com (Adam Thornton) Date: Thu, 13 Aug 2020 12:18:03 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> Message-ID: Early AIX is what happens when you give a detailed description of Unix to mainframers who've never seen Unix, and then tell them to implement that system, and then ship it, without at any point letting someone who's used an actual Unix system touch it. Adam On Thu, Aug 13, 2020 at 10:16 AM Dan Cross wrote: > On Fri, Jul 31, 2020 at 9:37 PM Larry McVoy wrote: > >> On Fri, Jul 31, 2020 at 07:12:57PM -0400, Richard Salz wrote: >> > > SMIT was quite nice >> > >> > i have never seen those four words together like that before. >> >> Me neither. SMIT was HORRIBLE if you understood the files in /etc and >> knew what to do with them. > > > The sysadmin in the CS department had a USENIX button on his wall: "SMIT > happens." I always found that amusing. > > The Motif-version was especially horrible, and crashed all the time. The > curses-based version was called `smitty`, which I found humorous in a way I > wouldn't have expected coming from "This page intentionally left blank" > IBM. In my mind, the worst part of admining RS/6000 boxes of that era was > the little 3-digit LED code on the front: I guess those machines didn't > assume that they had either a graphical head or a serial port, so this damn > teeny tiny display would cycle through a sequence of codes that told you > what the machine was doing; it came with a book that told you what each > code meant. Something like "387" meant mounting /usr. Ugh; I just found a > page on ibm.com describing these "IPL codes." > > It might be nice if you had no understanding >> of how to admin a Unix system and here is this "nice" curses based way >> to do admin. >> > > The thing was that IBM changed a lot of stuff almost gratuitously. > Specifics I remember were the print daemon (I ported `lpd` from 4.4BSD for > that) and anything related to disks and filesystems. In fairness, they had > logical volumes that could split across disks before most other Unix > systems that I was working on at the time, but the commands were all custom > to AIX and, frankly, weird: I remember that one would "vary on" a logical > volume before one could mount a filesystem from it or something like that. > I was told at the time that the people who'd built that side of things had > come from the mainframe world, where that was the nomenclature. Creating > JFS filesystems required these tools as well; there was new `newfs_jfs` as > I recall. So I ended up using SMIT for basically anything related to > filesystems, but for almost nothing else. > > To anyone remotely competent, and I don't mean edit sendmail.cf, I mean >> you can edit inetd.conf, you can edit a crontab file, etc, SMIT was a >> nightmare that made something that should be vi $FILE, done 20 seconds >> later, a hellish journey through their menus. It was AWFUL. >> > > One of the more gratuitous differences I remember from AIX was that > instead of having e.g. /etc/shadow, they had /etc/password (all spelled > out), which had semi-structured stanzas for each user. That was just weird. > Fortunately, we were using NIS and it was smart enough to ignore that for > NIS users. > > Ask me how I know. >> > > I still have nightmares about AIX. > > - Dan C. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Aug 14 05:28:34 2020 From: imp at bsdimp.com (Warner Losh) Date: Thu, 13 Aug 2020 13:28:34 -0600 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> Message-ID: On Thu, Aug 13, 2020, 1:19 PM Adam Thornton wrote: > Early AIX is what happens when you give a detailed description of Unix to > mainframers who've never seen Unix, and then tell them to implement that > system, and then ship it, without at any point letting someone who's used > an actual Unix system touch it. > Ha. Is there a good source of detailed technical info on early AIX systems? Like early 80s versions? Warner > Adam > > On Thu, Aug 13, 2020 at 10:16 AM Dan Cross wrote: > >> On Fri, Jul 31, 2020 at 9:37 PM Larry McVoy wrote: >> >>> On Fri, Jul 31, 2020 at 07:12:57PM -0400, Richard Salz wrote: >>> > > SMIT was quite nice >>> > >>> > i have never seen those four words together like that before. >>> >>> Me neither. SMIT was HORRIBLE if you understood the files in /etc and >>> knew what to do with them. >> >> >> The sysadmin in the CS department had a USENIX button on his wall: "SMIT >> happens." I always found that amusing. >> >> The Motif-version was especially horrible, and crashed all the time. The >> curses-based version was called `smitty`, which I found humorous in a way I >> wouldn't have expected coming from "This page intentionally left blank" >> IBM. In my mind, the worst part of admining RS/6000 boxes of that era was >> the little 3-digit LED code on the front: I guess those machines didn't >> assume that they had either a graphical head or a serial port, so this damn >> teeny tiny display would cycle through a sequence of codes that told you >> what the machine was doing; it came with a book that told you what each >> code meant. Something like "387" meant mounting /usr. Ugh; I just found a >> page on ibm.com describing these "IPL codes." >> >> It might be nice if you had no understanding >>> of how to admin a Unix system and here is this "nice" curses based way >>> to do admin. >>> >> >> The thing was that IBM changed a lot of stuff almost gratuitously. >> Specifics I remember were the print daemon (I ported `lpd` from 4.4BSD for >> that) and anything related to disks and filesystems. In fairness, they had >> logical volumes that could split across disks before most other Unix >> systems that I was working on at the time, but the commands were all custom >> to AIX and, frankly, weird: I remember that one would "vary on" a logical >> volume before one could mount a filesystem from it or something like that. >> I was told at the time that the people who'd built that side of things had >> come from the mainframe world, where that was the nomenclature. Creating >> JFS filesystems required these tools as well; there was new `newfs_jfs` as >> I recall. So I ended up using SMIT for basically anything related to >> filesystems, but for almost nothing else. >> >> To anyone remotely competent, and I don't mean edit sendmail.cf, I mean >>> you can edit inetd.conf, you can edit a crontab file, etc, SMIT was a >>> nightmare that made something that should be vi $FILE, done 20 seconds >>> later, a hellish journey through their menus. It was AWFUL. >>> >> >> One of the more gratuitous differences I remember from AIX was that >> instead of having e.g. /etc/shadow, they had /etc/password (all spelled >> out), which had semi-structured stanzas for each user. That was just weird. >> Fortunately, we were using NIS and it was smart enough to ignore that for >> NIS users. >> >> Ask me how I know. >>> >> >> I still have nightmares about AIX. >> >> - Dan C. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Fri Aug 14 06:04:22 2020 From: cowan at ccil.org (John Cowan) Date: Thu, 13 Aug 2020 16:04:22 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> Message-ID: On Thu, Aug 13, 2020 at 1:19 PM Henry Bent wrote: so this damn teeny tiny display would cycle through a sequence of codes >> that told you what the machine was doing; it came with a book that told you >> what each code meant. Something like "387" meant mounting /usr. Ugh; I just >> found a page on ibm.com describing these "IPL codes." >> > IPL = Initial Program Load = boot(strap), by the way. It also has the connotations of "toggle in". Seated one day at the keyboard I was weary and ill at ease, And my fingers rattled noisily Over the clicking keys I know not what I was coding Nor what I had IPLed in But I struck one chord of logic Like the sound of a great IF-THEN. --Guy Steele (I think) But this reminded me: Does anyone remember a system of any sort where there were *two* corresponding sets of alphanumeric error codes, one short and meaningless like F32 and the other somewhat meaningful like POWER_LOW? I made up this example, but I have a feeling I saw or read about such a system. I can't pin it down with Dr. Google. I already know about plenty of systems that have *numbers* and alphabetics, like , or just alphabetics and a (localizable) text explanation, like VMS, or just a number and a text explanation, like the BIOS errors. Such number-only error systems are still very common in things like "smart" washing machines, where the cost and unreliability of a non-tiny screen simply isn't acceptable. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Wer es in kleinen Dingen mit der Wahrheit nicht ernst nimmt, dem kann man auch in grossen Dingen nicht vertrauen. --Albert Einstein on honesty -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Fri Aug 14 06:09:49 2020 From: rdm at cfcl.com (Rich) Date: Thu, 13 Aug 2020 13:09:49 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> Message-ID: <28CC915D-5EC7-4555-B5AC-CEFB677385C4@cfcl.com> > On Aug 13, 2020, at 12:18, Adam Thornton wrote: > > Early AIX is what happens when you give a detailed description of Unix to mainframers who've never seen Unix, and then tell them to implement that system, and then ship it, without at any point letting someone who's used an actual Unix system touch it. My favorite characterization of AIX came from Barry Shein: "It will remind you of Unix." -r From lm at mcvoy.com Fri Aug 14 06:16:01 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 13 Aug 2020 13:16:01 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <28CC915D-5EC7-4555-B5AC-CEFB677385C4@cfcl.com> References: <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> <28CC915D-5EC7-4555-B5AC-CEFB677385C4@cfcl.com> Message-ID: <20200813201601.GV21027@mcvoy.com> On Thu, Aug 13, 2020 at 01:09:49PM -0700, Rich wrote: > > On Aug 13, 2020, at 12:18, Adam Thornton wrote: > > > > Early AIX is what happens when you give a detailed description of Unix to mainframers who've never seen Unix, and then tell them to implement that system, and then ship it, without at any point letting someone who's used an actual Unix system touch it. > > My favorite characterization of AIX came from Barry Shein: "It will remind you of Unix." Yeah, but in an oh-so-frustrating way. Sys V was not my cup of tea and AIX managed to make it worse. So happy to not be dealing with that. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From sauer at technologists.com Fri Aug 14 06:15:19 2020 From: sauer at technologists.com (Charles H Sauer) Date: Thu, 13 Aug 2020 15:15:19 -0500 Subject: [TUHS] AIX link repost [was Re: A/UX [was Linux is on-topic] In-Reply-To: References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> Message-ID: <5d68bfb6-14c9-2d98-55b8-7d62e181cec5@technologists.com> On 8/13/2020 2:28 PM, Warner Losh wrote: > Is there a good source of detailed technical info on early AIX systems? > Like early 80s versions? I'm biased, but I still view https://notes.technologists.com/notes/2017/03/08/lets-start-at-the-very-beginning-801-romp-rtpc-aix-versions/ and the included citations as the best info readily available on early AIX. That article doesn't discuss SMIT -- SMIT development was in early stages when I left AIX/IBM. Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer From crossd at gmail.com Fri Aug 14 06:52:23 2020 From: crossd at gmail.com (Dan Cross) Date: Thu, 13 Aug 2020 16:52:23 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> Message-ID: On Thu, Aug 13, 2020 at 4:04 PM John Cowan wrote: > On Thu, Aug 13, 2020 at 1:19 PM Henry Bent wrote: > >> so this damn teeny tiny display would cycle through a sequence of codes >>> that told you what the machine was doing; it came with a book that told you >>> what each code meant. Something like "387" meant mounting /usr. Ugh; I just >>> found a page on ibm.com describing these "IPL codes." >>> >> > IPL = Initial Program Load = boot(strap), by the way. It also has the > connotations of "toggle in". > Also, "IPL CMS" under VM! But this reminded me: Does anyone remember a system of any sort where there > were *two* corresponding sets of alphanumeric error codes, one short and > meaningless like F32 and the other somewhat meaningful like POWER_LOW? I > made up this example, but I have a feeling I saw or read about such > a system. I can't pin it down with Dr. Google. > It wouldn't surprise me if a DEC system had something similar involving random integers and more meaningful error strings. Maybe something like RSTS/E or RSX? I already know about plenty of systems that have *numbers* and alphabetics, > like , or just alphabetics and a (localizable) text explanation, > like VMS, or just a number and a text explanation, like the BIOS errors. > A nifty thing about VMS is that one can type 'help/message' to get contextual help on the last error message: $ dir foo %DIRECT-W-NOFILES, no files found $ help/message FNF, file not found Facility: RMS, OpenVMS Record Management Services Explanation: The specified file does not exist. User Action: Check the file specification and verify that the device, directory, file name, and file type are all specified correctly. If a logical name is specified, verify the current equivalence assigned to the logical name. If the equivalence is correct, verify that the correct volume is mounted on the specified device and that the file was not inadvertently deleted. $ Such number-only error systems are still very common in things like "smart" > washing machines, where the cost and unreliability of a non-tiny screen > simply isn't acceptable. > My smoke detector beeps three times quickly when it wants a new battery. Yay. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From iain at csp-partnership.co.uk Fri Aug 14 06:17:43 2020 From: iain at csp-partnership.co.uk (Dr Iain Maoileoin) Date: Thu, 13 Aug 2020 21:17:43 +0100 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <28CC915D-5EC7-4555-B5AC-CEFB677385C4@cfcl.com> References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> <28CC915D-5EC7-4555-B5AC-CEFB677385C4@cfcl.com> Message-ID: <3BA883F2-865C-40A2-AA9E-DC4B87135DA1@csp-partnership.co.uk> In the UK, in the 80s?, IBM used to put up HUGE billboards with a slogan like “.. we have added a million lines of code to UNIX”, some smart ar*es around the Uni would grafitti each one with “yes, and every line was wrong”. AIX had a lot going for it - in some ways, but as the feeling is here it really was not UNIX as we knew it. I am jaundiced since my car registration is "AIX OK”. > On 13 Aug 2020, at 21:09, Rich wrote: > >> On Aug 13, 2020, at 12:18, Adam Thornton wrote: >> >> Early AIX is what happens when you give a detailed description of Unix to mainframers who've never seen Unix, and then tell them to implement that system, and then ship it, without at any point letting someone who's used an actual Unix system touch it. > > My favorite characterization of AIX came from Barry Shein: "It will remind you of Unix." > > -r > From gtaylor at tnetconsulting.net Fri Aug 14 08:24:38 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 13 Aug 2020 16:24:38 -0600 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> Message-ID: <442ec50f-7ae6-eb32-b9a0-563058f848c4@tnetconsulting.net> On 8/13/20 11:14 AM, Dan Cross wrote: > The Motif-version was especially horrible, and crashed all the time. The > curses-based version was called `smitty` I think it's funny that you can use 'smitty' /or/ 'smit' to launch SMIT on serial consoles. But 'smit' had a very different behavior in an AIXterm. 'smit' would try to launch the Motif version. Conversely, 'smitty' would always launch the curses version. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From cbbrowne at gmail.com Fri Aug 14 11:04:08 2020 From: cbbrowne at gmail.com (Christopher Browne) Date: Thu, 13 Aug 2020 21:04:08 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <28CC915D-5EC7-4555-B5AC-CEFB677385C4@cfcl.com> References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> <28CC915D-5EC7-4555-B5AC-CEFB677385C4@cfcl.com> Message-ID: On Thu., Aug. 13, 2020, 4:11 p.m. Rich, wrote: > > On Aug 13, 2020, at 12:18, Adam Thornton wrote: > > > > Early AIX is what happens when you give a detailed description of Unix > to mainframers who've never seen Unix, and then tell them to implement that > system, and then ship it, without at any point letting someone who's used > an actual Unix system touch it. > > My favorite characterization of AIX came from Barry Shein: "It will remind > you of Unix." My favorite was from David Megginson, whose observation was that "you don't run AIX, you chase it" -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcapp at anteil.com Sat Aug 15 03:18:48 2020 From: jcapp at anteil.com (Jim Capp) Date: Fri, 14 Aug 2020 13:18:48 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: Message-ID: I first ran across A/UX at a tradeshow. I can’t recall the date, but I remember very clearly approaching an IBM sales rep who told me that they took UNIX and “fixed all the bugs”. I shook my head and laughed as I walked away. > On Aug 13, 2020, at 9:06 PM, Christopher Browne wrote: > >  > > >> On Thu., Aug. 13, 2020, 4:11 p.m. Rich, wrote: >> > On Aug 13, 2020, at 12:18, Adam Thornton wrote: >> > >> > Early AIX is what happens when you give a detailed description of Unix to mainframers who've never seen Unix, and then tell them to implement that system, and then ship it, without at any point letting someone who's used an actual Unix system touch it. >> >> My favorite characterization of AIX came from Barry Shein: "It will remind you of Unix." > > > My favorite was from David Megginson, whose observation was that "you don't run AIX, you chase it" -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Sat Aug 15 03:31:29 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 14 Aug 2020 13:31:29 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> Message-ID: On 8/13/20, John Cowan wrote: > On Thu, Aug 13, 2020 at 1:19 PM Henry Bent wrote: > > IPL = Initial Program Load = boot(strap), by the way. It also has the > connotations of "toggle in". IPL is one of several IBM-isms. A few others: main storage = memory. IBM considered "memory" too anthropomorphic. DASD = direct access storage device = disk. This is a hold-over from the days when, in addition to disks, there were drums and the IBM 2321 data cell drive (aka the noodle-picker). DECtape would probably be classified as DASD. -Paul W. From jcapp at anteil.com Sat Aug 15 03:37:48 2020 From: jcapp at anteil.com (Jim Capp) Date: Fri, 14 Aug 2020 13:37:48 -0400 (EDT) Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: Message-ID: <7222714.1225.1597426668147.JavaMail.root@zimbraanteil> Sorry, I meant AIX, A/UX :-( From: "Jim Capp" To: "The Eunuchs Hysterical Society" Sent: Friday, August 14, 2020 1:18:48 PM Subject: Re: [TUHS] A/UX [was Linux is on-topic] I first ran across A/UX at a tradeshow. I can’t recall the date, but I remember very clearly approaching an IBM sales rep who told me that they took UNIX and “fixed all the bugs”. I shook my head and laughed as I walked away. On Aug 13, 2020, at 9:06 PM, Christopher Browne wrote: On Thu., Aug. 13, 2020, 4:11 p.m. Rich, < rdm at cfcl.com > wrote: > On Aug 13, 2020, at 12:18, Adam Thornton < athornton at gmail.com > wrote: > > Early AIX is what happens when you give a detailed description of Unix to mainframers who've never seen Unix, and then tell them to implement that system, and then ship it, without at any point letting someone who's used an actual Unix system touch it. My favorite characterization of AIX came from Barry Shein: "It will remind you of Unix." My favorite was from David Megginson, whose observation was that "you don't run AIX, you chase it" -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Sat Aug 15 03:39:49 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 14 Aug 2020 10:39:49 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: Message-ID: <202008141739.07EHdn2U1381389@darkstar.fourwinds.com> Jim Capp writes: > I can’t recall the date, but I remember very clearly approaching an IBM sales > rep who told me that they took UNIX and “fixed all the bugs”. > > I shook my head and laughed as I walked away. You might laugh, but when I worked at Tektronix on their workstation product, they had a group that actually did that, or at least as close as possible. I remember them agonizing over fixing cpile bugs in eqn. Was actually really nice to have a pretty bug-free system available. But, in the tried and true bad management style that was Tektronix, nobody every asked whether there was any customer value proposition. Jon From mckusick at mckusick.com Sat Aug 15 05:15:11 2020 From: mckusick at mckusick.com (Kirk McKusick) Date: Fri, 14 Aug 2020 12:15:11 -0700 Subject: [TUHS] BSTJ archives Message-ID: <202008141915.07EJFBBH035202@chez.mckusick.com> I needed to look up something in the Bell System Technical Journal (Wikipedia didn't have it) and discovered that the old Alcatel-Lucent site that used to host a free archive of BSTJ no longer seems extant. (No surprise, the Web is nothing if not ephemeral.) After a bit of Googling, I did find that the archives are now residing at and found what I was looking for there. Hope others find this link useful. At least until it too "sublimaates". Kirk McKusick From beebe at math.utah.edu Sat Aug 15 06:31:44 2020 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Fri, 14 Aug 2020 14:31:44 -0600 Subject: [TUHS] BSTJ archives In-Reply-To: <202008141915.07EJFBBH035202@chez.mckusick.com> Message-ID: Kirk Mckusick points to https://archive.org/details/bstj-archives for an archive of the Bell System Technical Journal family. On 30-Apr-2014, the journal publication moved from Wiley to IEEE, and as of today, the latter has issues back to 1996 at http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=6731002 Complete coverage of the family from the first issue in July 1922, now 98 years ago, is at http://www.math.utah.edu/pub/tex/bib/bstjDDDD.{bib,html} where DDDD is any decade from 1920 to 2010. The last publication that I recorded is for volume 24, December 2019, and so far, nothing newer has appeared. For the record, in 2010, the IBM Journal of Research and Development also moved from IBM to IEEE, putting the issues behind a paywall for the first time. The companion IBM Systems Journal ceased publication in 2008, and in 2011, its archives were moved to IEEE: http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=5288519 http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=5288520 IEEE offers complete coverage for both journals. The DEC Technical Journal, the Hewlett--Packard Journal, and the Intel Technology Journal are covered at http://www.math.utah.edu/pub/tex/bib/dectechj.bib http://www.math.utah.edu/pub/tex/bib/hpj.bib http://www.math.utah.edu/pub/tex/bib/intel-tech-j.bib [Change .bib to .html for similar views, but with live hyperlinks.] I've never investigated whether Burroughs, CDC, Data General, Honeywell, NCR, Pr1me, SDS, Univac/Unisys, or Xerox had similar journals. Cray had CRAY Channels, but I have not located an archive for its issues. List readers who know of such publications are invited to post suitable links. ------------------------------------------------------------------------------- - 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 at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From rdm at cfcl.com Sat Aug 15 10:33:09 2020 From: rdm at cfcl.com (Rich) Date: Fri, 14 Aug 2020 17:33:09 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <202008141739.07EHdn2U1381389@darkstar.fourwinds.com> References: <202008141739.07EHdn2U1381389@darkstar.fourwinds.com> Message-ID: <4F69D0BB-C6C8-443C-A5A2-0F0C1E5578B0@cfcl.com> > On Aug 14, 2020, at 10:39, Jon Steinhart wrote: > > ...Was actually really > nice to have a pretty bug-free system available. But, in the tried and true > bad management style that was Tektronix, nobody every asked whether there was > any customer value proposition. Some years ago, I asked a engineer friend about the ceramic terminal strips (and accompanying spool of silver solder) that I had seen in Tektronix scopes. He responded by asking me what a terminal strip was supposed to do. Erm, make connections and provide physical stability between some wires while keeping all the connections insulated from each other? He said "yup", that's what these strips do. In particular, they aren't capacitors, resistors, or inductors to any significant degree... On a vaguely related note, I found it amusing that there was a well known hack for Cray's (or perhaps 6600's) which were misbehaving: put a Tektronix scope probe on a test point that generally had one there during final system checkout. The load (extremely mnimal by design) was just enough to stabilize the system. -r From lm at mcvoy.com Sat Aug 15 11:20:03 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 14 Aug 2020 18:20:03 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <4F69D0BB-C6C8-443C-A5A2-0F0C1E5578B0@cfcl.com> References: <202008141739.07EHdn2U1381389@darkstar.fourwinds.com> <4F69D0BB-C6C8-443C-A5A2-0F0C1E5578B0@cfcl.com> Message-ID: <20200815012003.GQ32735@mcvoy.com> On Fri, Aug 14, 2020 at 05:33:09PM -0700, Rich wrote: > On a vaguely related note, I found it amusing that there was a well known hack > for Cray's (or perhaps 6600's) which were misbehaving: put a Tektronix scope > probe on a test point that generally had one there during final system checkout. > The load (extremely mnimal by design) was just enough to stabilize the system. I'm sure everyone here knows this, but the Cray 1 (I think, the one that had what looked like a circular bench seat around the bottom) was designed like that because the clock was at the center and the clock signal went to all the boards and was right because all the clock lines to the boards were the same length. From dave at horsfall.org Sat Aug 15 11:24:41 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 15 Aug 2020 11:24:41 +1000 (EST) Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> Message-ID: On Fri, 14 Aug 2020, Paul Winalski wrote: > IPL is one of several IBM-isms. A few others: > > main storage = memory. IBM considered "memory" too anthropomorphic. > > DASD = direct access storage device = disk. This is a hold-over from > the days when, in addition to disks, there were drums and the IBM 2321 > data cell drive (aka the noodle-picker). DECtape would probably be > classified as DASD. Another one for you: LCS: Large Core Store (sort of extended memory). Ah, the noodle-picker... Also known as the Chicken Plucker, when it worked it worked OK, but when it didn't... There was also this rotating drum, where instead of the heads moving, the drum slid sideways, and the (male) operators used to show it to females... -- Dave From jon at fourwinds.com Sat Aug 15 11:33:11 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 14 Aug 2020 18:33:11 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <4F69D0BB-C6C8-443C-A5A2-0F0C1E5578B0@cfcl.com> References: <202008141739.07EHdn2U1381389@darkstar.fourwinds.com> <4F69D0BB-C6C8-443C-A5A2-0F0C1E5578B0@cfcl.com> Message-ID: <202008150133.07F1XCfE1392913@darkstar.fourwinds.com> Rich writes: > > On Aug 14, 2020, at 10:39, Jon Steinhart wrote: > > > > ...Was actually really > > nice to have a pretty bug-free system available. But, in the tried and true > > bad management style that was Tektronix, nobody every asked whether there was > > any customer value proposition. > > Some years ago, I asked a engineer friend about the ceramic terminal strips > (and accompanying spool of silver solder) that I had seen in Tektronix scopes. > He responded by asking me what a terminal strip was supposed to do. > > Erm, make connections and provide physical stability between some wires while > keeping all the connections insulated from each other? He said "yup", that's > what these strips do. In particular, they aren't capacitors, resistors, or > inductors to any significant degree... > > On a vaguely related note, I found it amusing that there was a well known hack > for Cray's (or perhaps 6600's) which were misbehaving: put a Tektronix scope > probe on a test point that generally had one there during final system checkout. > The load (extremely mnimal by design) was just enough to stabilize the system. > > -r Well, this is kind of off topic, but that wasn't my experience at Tek. There was an internal course called AFTR (amplifier frequency and transient response) which was basically a guide to black magic design, then things that you had to know if as we said, you needed to design amplifiers that were flat from DC to daylight. This is where one learned about things like t-coils which compensated for bonding wire impedance in ICs, hook (dC/dV of circuit certain circuit board dialectrics), and so on. Plus, we had a policy of making things bulletproof. Relating it back to workstations, it was a problem. We were unable to convince management (well, there really wasn't any management at Tek) that while customers expected a mil-spec scope to bounce and keep on working when dropped off of the back of a truck, the folks who bought workstations expected them to break when dropped. That's why we couldn't build an empty box of air for less than a thousand dollars. Jon From gregg.drwho8 at gmail.com Sat Aug 15 11:40:06 2020 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Fri, 14 Aug 2020 21:40:06 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: Message-ID: Hello! And you're going to react similarly when I mention that I first met AIX at an event concerning UNIX in general, in fact UNIXEXPO, and there it was the crowd of RT/PC designs that looked like strangely dressed PC/AT ones, and scared the stuffing out of the salesperson when I simply logged into each working station by using the telnet command and asking her the name of each. Next time they looked like the way they looked much the same as the final style, and that's what the salesmen said. that. I also laughed at it. I found the SUN booth more interesting. But Larry knows why. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Fri, Aug 14, 2020 at 1:20 PM Jim Capp wrote: > > I first ran across A/UX at a tradeshow. > > I can’t recall the date, but I remember very clearly approaching an IBM sales rep who told me that they took UNIX and “fixed all the bugs”. > > I shook my head and laughed as I walked away. > > On Aug 13, 2020, at 9:06 PM, Christopher Browne wrote: > >  > > > On Thu., Aug. 13, 2020, 4:11 p.m. Rich, wrote: >> >> > On Aug 13, 2020, at 12:18, Adam Thornton wrote: >> > >> > Early AIX is what happens when you give a detailed description of Unix to mainframers who've never seen Unix, and then tell them to implement that system, and then ship it, without at any point letting someone who's used an actual Unix system touch it. >> >> My favorite characterization of AIX came from Barry Shein: "It will remind you of Unix." > > > My favorite was from David Megginson, whose observation was that "you don't run AIX, you chase it" From dave at horsfall.org Sat Aug 15 12:02:51 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 15 Aug 2020 12:02:51 +1000 (EST) Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <4F69D0BB-C6C8-443C-A5A2-0F0C1E5578B0@cfcl.com> References: <202008141739.07EHdn2U1381389@darkstar.fourwinds.com> <4F69D0BB-C6C8-443C-A5A2-0F0C1E5578B0@cfcl.com> Message-ID: On Fri, 14 Aug 2020, Rich wrote: > On a vaguely related note, I found it amusing that there was a well > known hack for Cray's (or perhaps 6600's) which were misbehaving: put a > Tektronix scope probe on a test point that generally had one there > during final system checkout. The load (extremely mnimal by design) was > just enough to stabilize the system. There was also the story about the major difference between a Cyber 72 and a Cyber 73 was just a timing capacitor... Very expensive capacitor :-) -- Dave From dave at horsfall.org Sat Aug 15 12:08:22 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 15 Aug 2020 12:08:22 +1000 (EST) Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <20200815012003.GQ32735@mcvoy.com> References: <202008141739.07EHdn2U1381389@darkstar.fourwinds.com> <4F69D0BB-C6C8-443C-A5A2-0F0C1E5578B0@cfcl.com> <20200815012003.GQ32735@mcvoy.com> Message-ID: On Fri, 14 Aug 2020, Larry McVoy wrote: > I'm sure everyone here knows this, but the Cray 1 (I think, the one that > had what looked like a circular bench seat around the bottom) was > designed like that because the clock was at the center and the clock > signal went to all the boards and was right because all the clock lines > to the boards were the same length. Yep, timing was everything in those days (and I'm still amazed at the people who believe that electricity moves at the speed of light). Wasn't it Grace Hopper who used to demonstrate a nanosecond by holding up a foot of wire? -- Dave From imp at bsdimp.com Sat Aug 15 12:47:56 2020 From: imp at bsdimp.com (Warner Losh) Date: Fri, 14 Aug 2020 20:47:56 -0600 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <202008141739.07EHdn2U1381389@darkstar.fourwinds.com> <4F69D0BB-C6C8-443C-A5A2-0F0C1E5578B0@cfcl.com> <20200815012003.GQ32735@mcvoy.com> Message-ID: On Fri, Aug 14, 2020, 8:09 PM Dave Horsfall wrote: > On Fri, 14 Aug 2020, Larry McVoy wrote: > > > I'm sure everyone here knows this, but the Cray 1 (I think, the one that > > had what looked like a circular bench seat around the bottom) was > > designed like that because the clock was at the center and the clock > > signal went to all the boards and was right because all the clock lines > > to the boards were the same length. > > Yep, timing was everything in those days (and I'm still amazed at the > people who believe that electricity moves at the speed of light). > > Wasn't it Grace Hopper who used to demonstrate a nanosecond by holding up > a foot of wire? > Yes. A nanosecond is just over a foot in copper... I used to do high precision timing and we used to make cables specific lengths to bring the on time point of different parts of the signal distribution system into alignment... you could also see how bands or kinks in the cables moved the on time point... Warner -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at humeweb.com Sat Aug 15 12:45:56 2020 From: andrew at humeweb.com (Andrew Hume) Date: Fri, 14 Aug 2020 19:45:56 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <202008141739.07EHdn2U1381389@darkstar.fourwinds.com> <4F69D0BB-C6C8-443C-A5A2-0F0C1E5578B0@cfcl.com> Message-ID: <176D143B-8C1A-4CAB-94E9-5433DBE7E4A6@humeweb.com> not on the cyber 72 we shared, dave. it was, in fact, a length of wire. the 72 had one length, and the 76 had a shorter length. (i guess you could call that a sort-of timing capacitor?) i watched a cyber technician change the wires for the purposes of doing a verification test. > On Aug 14, 2020, at 7:02 PM, Dave Horsfall wrote: > > On Fri, 14 Aug 2020, Rich wrote: > >> On a vaguely related note, I found it amusing that there was a well known hack for Cray's (or perhaps 6600's) which were misbehaving: put a Tektronix scope probe on a test point that generally had one there during final system checkout. The load (extremely mnimal by design) was just enough to stabilize the system. > > There was also the story about the major difference between a Cyber 72 and a Cyber 73 was just a timing capacitor... Very expensive capacitor :-) > > -- Dave From lm at mcvoy.com Sat Aug 15 13:29:56 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 14 Aug 2020 20:29:56 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <202008141739.07EHdn2U1381389@darkstar.fourwinds.com> <4F69D0BB-C6C8-443C-A5A2-0F0C1E5578B0@cfcl.com> Message-ID: <20200815032956.GR32735@mcvoy.com> On Sat, Aug 15, 2020 at 12:02:51PM +1000, Dave Horsfall wrote: > On Fri, 14 Aug 2020, Rich wrote: > > >On a vaguely related note, I found it amusing that there was a well known > >hack for Cray's (or perhaps 6600's) which were misbehaving: put a > >Tektronix scope probe on a test point that generally had one there during > >final system checkout. The load (extremely mnimal by design) was just > >enough to stabilize the system. > > There was also the story about the major difference between a Cyber 72 and a > Cyber 73 was just a timing capacitor... Very expensive capacitor :-) I've been there when Neil Lincoln toggled the boot strap. https://en.wikipedia.org/wiki/ETA10 From thomas.paulsen at firemail.de Sat Aug 15 22:05:27 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Sat, 15 Aug 2020 14:05:27 +0200 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <20200815012003.GQ32735@mcvoy.com> References: <202008141739.07EHdn2U1381389@darkstar.fourwinds.com> <4F69D0BB-C6C8-443C-A5A2-0F0C1E5578B0@cfcl.com> <20200815012003.GQ32735@mcvoy.com> Message-ID: >I'm sure everyone here knows this, but the Cray 1 (I think, the one that had what looked like a circular bench seat around the bottom) was designed like that because the clock was at the center and the clock signal went to all the boards and was right because all the clock lines to the boards were the same length.< you mean that? https://upload.wikimedia.org/wikipedia/commons/f/f7/Cray-1-deutsches-museum.jpg
_________________________________________________________________
Gesendet mit Firemail.de - Freemail From ches at cheswick.com Sun Aug 16 02:55:17 2020 From: ches at cheswick.com (William Cheswick) Date: Sat, 15 Aug 2020 12:55:17 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <176D143B-8C1A-4CAB-94E9-5433DBE7E4A6@humeweb.com> References: <176D143B-8C1A-4CAB-94E9-5433DBE7E4A6@humeweb.com> Message-ID: <4C96E13E-353F-4828-B408-758EAF2E270B@cheswick.com> The wire lengths were important in CDC CPUs. I once saw an expert from CDC poking through the rats nest of wires on the backplane, yanking the wires around with his flashlight, and pulled one out thinking it was the wrong length. It was. Message by ches. Tappos by iPad. > On Aug 14, 2020, at 11:08 PM, Andrew Hume wrote: > > not on the cyber 72 we shared, dave. > it was, in fact, a length of wire. > the 72 had one length, and the 76 had a shorter length. > (i guess you could call that a sort-of timing capacitor?) > > i watched a cyber technician change the wires for the > purposes of doing a verification test. > >> On Aug 14, 2020, at 7:02 PM, Dave Horsfall wrote: >> >>> On Fri, 14 Aug 2020, Rich wrote: >>> >>> On a vaguely related note, I found it amusing that there was a well known hack for Cray's (or perhaps 6600's) which were misbehaving: put a Tektronix scope probe on a test point that generally had one there during final system checkout. The load (extremely mnimal by design) was just enough to stabilize the system. >> >> There was also the story about the major difference between a Cyber 72 and a Cyber 73 was just a timing capacitor... Very expensive capacitor :-) >> >> -- Dave From paul.winalski at gmail.com Sun Aug 16 03:44:05 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Sat, 15 Aug 2020 13:44:05 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <202008141739.07EHdn2U1381389@darkstar.fourwinds.com> <4F69D0BB-C6C8-443C-A5A2-0F0C1E5578B0@cfcl.com> <20200815012003.GQ32735@mcvoy.com> Message-ID: On 8/14/20, Dave Horsfall wrote: > > Wasn't it Grace Hopper who used to demonstrate a nanosecond by holding up > a foot of wire? Yes. She gave a talk back in 1982 at DEC's software engineering facility. She used the foot-long wire to illustrate a nanosecond and a big coil of wire for a microsecond. After the talk she handed out nanoseconds as souvenirs. I still have mine. Her talk was on the future of computing, and the point she was making with the nanosecond was that eventually there's a limit to Moore's Law., and any further computational speedups would require parallelism. She drew an analogy to the problem of a 19th century carter having to haul a load too heavy for one horse. The solution isn't to breed bigger horses--it's to hook up two of them. And here we are today, with multi-core processors. -Paul W. From mobile at majumdar.org.uk Sun Aug 16 07:50:47 2020 From: mobile at majumdar.org.uk (Dibyendu Majumdar) Date: Sat, 15 Aug 2020 22:50:47 +0100 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler Message-ID: Hi, I have a project to revive the C compiler from V7/V10. I wanted to check if anyone here knows about the memory management in the compiler (c0 only for now). I am trying to migrate the memory management to malloc/free but I am struggling to understand exactly how memory is being managed. Thanks and Regards Dibyendu From will.senn at gmail.com Sun Aug 16 11:01:54 2020 From: will.senn at gmail.com (Will Senn) Date: Sat, 15 Aug 2020 20:01:54 -0500 Subject: [TUHS] TUHS Digest, Vol 55, Issue 9 In-Reply-To: References: Message-ID: <13662C2D-466D-48E4-B22D-0CCC499C1A72@gmail.com> > > Message: 6 > Date: Fri, 5 Jun 2020 16:51:27 -0600 > From: Warner Losh > To: The Eunuchs Hysterical Society > Subject: [TUHS] My BSDcan talk > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > OK. Must be off my game... I forgot to tell people about my BSDcan talk > earlier today. It was streamed live, and will be online in a week or > three... > > It's another similar to the last two. I've uploaded a version to youtube > until the conference has theirs ready. It's a private link, but should work > for anybody that has it. Now that I've given my talk it's cool to share > more widely... https://www.youtube.com/watch?v=NRq8xEvFS_g > > The link at the end is wrong. https://github.com/bsdimp/bsdcan2020-demos is > the proper link. > > Please let me know what you think. > > Warner > Just saw your BSDcan talk. Great stuff, so much progress in the last five years. Just wanna say thanks. When I started looking into ancient systems, it was hard finding anything coherent on the historical side beyond manuals and this list (thankful to Warren & co for the list). Your talk is packed with interesting information and really pulls together the recent pieces. Great job, Warner. From andrew at humeweb.com Sun Aug 16 15:17:05 2020 From: andrew at humeweb.com (Andrew Hume) Date: Sat, 15 Aug 2020 22:17:05 -0700 Subject: [TUHS] bsdcan talk Message-ID: <67152536-0DA3-4DB9-8C65-2549CF956AE1@humeweb.com> fyi warner, in your talk, you referred to Alex Fraser at bell labs. he was my first director, and always went by “sandy”. i asked my wife (who was a secretary at the time) and she said he was occasionally referred to as Alex. certainly, every time i saw anything written by him or references to a talk by him always used “sandy”. andrew From imp at bsdimp.com Mon Aug 17 01:10:40 2020 From: imp at bsdimp.com (Warner Losh) Date: Sun, 16 Aug 2020 09:10:40 -0600 Subject: [TUHS] bsdcan talk In-Reply-To: <67152536-0DA3-4DB9-8C65-2549CF956AE1@humeweb.com> References: <67152536-0DA3-4DB9-8C65-2549CF956AE1@humeweb.com> Message-ID: Thanks for the update Warner On Sat, Aug 15, 2020, 11:39 PM Andrew Hume wrote: > fyi warner, > > in your talk, you referred to Alex Fraser at bell labs. > he was my first director, and always went by “sandy”. > i asked my wife (who was a secretary at the time) and she > said he was occasionally referred to as Alex. certainly, every > time i saw anything written by him or references to a talk by him > always used “sandy”. > > andrew > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Aug 17 01:20:42 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 16 Aug 2020 09:20:42 -0600 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: Message-ID: <202008161520.07GFKg9k028970@freefriends.org> Dibyendu Majumdar wrote: > Hi, > > I have a project to revive the C compiler from V7/V10. > I wanted to check if anyone here knows about the memory management in > the compiler (c0 only for now). I am trying to migrate the memory > management to malloc/free but I am struggling to understand exactly > how memory is being managed. > > Thanks and Regards > Dibyendu There already is a project that revived PCC, probably starting with the one in 4BSD. http://pcc.ludd.ltu.se/ I have a git mirror, just to make things easier for access through firewalls: https://github.com/arnoldrobbins/pcc-revived Starting from the V10 compiler would be interesting. It was not available when the above project was started. HTH, Arnold From velocityboy at gmail.com Mon Aug 17 01:27:52 2020 From: velocityboy at gmail.com (Jim Geist) Date: Sun, 16 Aug 2020 11:27:52 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: <202008161520.07GFKg9k028970@freefriends.org> References: <202008161520.07GFKg9k028970@freefriends.org> Message-ID: Do you have a link to the V10 compiler source? On Sun, Aug 16, 2020 at 11:21 AM wrote: > Dibyendu Majumdar wrote: > > > Hi, > > > > I have a project to revive the C compiler from V7/V10. > > I wanted to check if anyone here knows about the memory management in > > the compiler (c0 only for now). I am trying to migrate the memory > > management to malloc/free but I am struggling to understand exactly > > how memory is being managed. > > > > Thanks and Regards > > Dibyendu > > There already is a project that revived PCC, probably starting > with the one in 4BSD. > > http://pcc.ludd.ltu.se/ > > I have a git mirror, just to make things easier for access through > firewalls: > > https://github.com/arnoldrobbins/pcc-revived > > Starting from the V10 compiler would be interesting. It was not available > when the above project was started. > > HTH, > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Mon Aug 17 12:02:24 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 16 Aug 2020 22:02:24 -0400 (EDT) Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler Message-ID: <20200817020224.104B518C095@mercury.lcs.mit.edu> > From: Dibyendu Majumdar > the C compiler from V7/V10. I wanted to check if anyone here knows > about the memory management in the compiler (c0 only for now). I am > trying to migrate the memory management to malloc/free but I am > struggling to understand exactly how memory is being managed. Well, I don't know much about the V7 compiler; the V6 one, which I have looked at, doesn't (except for the optimizer, C2) use allocated memory at all. The V7 compiler seems to use sbrk() (the system call to manage the location of the end of a process' data space), and manage the additional data space 'manually'; it does not seem to use a true generic heap. See gblock() in c01.c: https://minnie.tuhs.org//cgi-bin/utree.pl?file=V7/usr/src/cmd/c/c01.c which seems to use two static variables (curbase and coremax) to manage that additional memory: p = curbase; if ((curbase =+ n) >= coremax) { if (sbrk(1024) == -1) { error("Out of space"); exit(1); } coremax =+ 1024; } return(p); My guess is that there's no 'free' at all; each C source file is processed by a new invocation of C0, and the old 'heap' is thrown away when the process exits when it gets to the EOF. Noel From crossd at gmail.com Tue Aug 18 02:13:07 2020 From: crossd at gmail.com (Dan Cross) Date: Mon, 17 Aug 2020 12:13:07 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: Message-ID: On Sat, Aug 15, 2020 at 5:52 PM Dibyendu Majumdar wrote: > I have a project to revive the C compiler from V7/V10. > I wanted to check if anyone here knows about the memory management in > the compiler (c0 only for now). I am trying to migrate the memory > management to malloc/free but I am struggling to understand exactly > how memory is being managed. > I'll confess I haven't looked _that_ closely, but I rather imagine that the V10 compiler is a descendant of PCC rather than Dennis's V6/V7 PDP-11 compiler. V10 only targets the VAX, and from what I can tell, the two compilers in use there are LCC and PCC. >From my light skimming of V10 sources, it appears that the various components of the default C compiler (that is, not LCC) either use malloc/free or call `sbrk` directly. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Tue Aug 18 04:02:20 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 17 Aug 2020 14:02:20 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: <20200817020224.104B518C095@mercury.lcs.mit.edu> References: <20200817020224.104B518C095@mercury.lcs.mit.edu> Message-ID: On 8/16/20, Noel Chiappa wrote: > > The V7 compiler seems to use sbrk() (the system call to manage the location of > the end of a process' data space), and manage the additional data space > 'manually'; it does not seem to use a true generic heap. See gblock() in > c01.c: This is very common in compilers. Both the DEC/Compaq and Intel compilers manage heap memory this way. Each particular phase or pass of a compiler tends to build its on set of data structures in heap, and then free the whole mess when the phase/pass is done. malloc/free doesn't fit the model very well because you have to free each structure individually, and for more persistent structures you don't get very good locality of reference. What works better is to use a multitude of mini-heaps that can be freed up all in one go. -Paul W. From velocityboy at gmail.com Tue Aug 18 04:13:43 2020 From: velocityboy at gmail.com (Jim Geist) Date: Mon, 17 Aug 2020 14:13:43 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: <20200817020224.104B518C095@mercury.lcs.mit.edu> Message-ID: You beat me to my response. malloc/free are great for long running processes where memory can't just infinitely increase, but there's a ton of stuff in a compiler -- types, expressions, symbols -- that survives until the process exits. There's benefit in both space (because you don't have to add headers to the blocks as malloc() does, so free() can work) and time to doing it this way. On Mon, Aug 17, 2020 at 2:03 PM Paul Winalski wrote: > On 8/16/20, Noel Chiappa wrote: > > > > The V7 compiler seems to use sbrk() (the system call to manage the > location of > > the end of a process' data space), and manage the additional data space > > 'manually'; it does not seem to use a true generic heap. See gblock() in > > c01.c: > > This is very common in compilers. Both the DEC/Compaq and Intel > compilers manage heap memory this way. Each particular phase or pass > of a compiler tends to build its on set of data structures in heap, > and then free the whole mess when the phase/pass is done. malloc/free > doesn't fit the model very well because you have to free each > structure individually, and for more persistent structures you don't > get very good locality of reference. What works better is to use a > multitude of mini-heaps that can be freed up all in one go. > > -Paul W. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Tue Aug 18 04:48:52 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 17 Aug 2020 14:48:52 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: <20200817020224.104B518C095@mercury.lcs.mit.edu> Message-ID: On 8/17/20, Jim Geist wrote: > You beat me to my response. malloc/free are great for long running > processes where memory can't just infinitely increase, but there's a ton of > stuff in a compiler -- types, expressions, symbols -- that survives until > the process exits. There's benefit in both space (because you don't have to > add headers to the blocks as malloc() does, so free() can work) and time to > doing it this way. > The other issue is locality of reference. Data structures such as the symbol table get built up gradually as the compilation processes each routine. Typically the symbol table is stored as a hash table where each entry is a pointer to the actual symbol table entry data structure. If you malloc() each symbol table entry individually, they can end up scattered all over the virtual address space. It's not as important these days, when main memory is measured in gigabytes, but back when machines had less real memory, the scattering could lead to excessive page faulting. Much better to allocate symbol table entries in chunks, and the easiest way to do that is to give the symbol table its own mini-heap. VMS implemented the mini-heap concept (VMS calls them zones) back in its first release in 1978. Dave Cutler took the concept to Windows NT (Microsoft calls them private heaps). Lots of applications have built their own mini-heap system on top of sbrk(), but has a library of mini-heap-type APIs ever been distributed on Unix? -Paul W. From velocityboy at gmail.com Tue Aug 18 05:08:48 2020 From: velocityboy at gmail.com (Jim Geist) Date: Mon, 17 Aug 2020 15:08:48 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: <20200817020224.104B518C095@mercury.lcs.mit.edu> Message-ID: When did mmap(2) come about? Another thing I've seen is building a small block allocator on top of that. You can guarantee that all your objects are nicely collected into the same set of pages for locality with very little overhead. On Mon, Aug 17, 2020 at 2:48 PM Paul Winalski wrote: > On 8/17/20, Jim Geist wrote: > > You beat me to my response. malloc/free are great for long running > > processes where memory can't just infinitely increase, but there's a ton > of > > stuff in a compiler -- types, expressions, symbols -- that survives until > > the process exits. There's benefit in both space (because you don't have > to > > add headers to the blocks as malloc() does, so free() can work) and time > to > > doing it this way. > > > The other issue is locality of reference. Data structures such as the > symbol table get built up gradually as the compilation processes each > routine. Typically the symbol table is stored as a hash table where > each entry is a pointer to the actual symbol table entry data > structure. If you malloc() each symbol table entry individually, they > can end up scattered all over the virtual address space. It's not as > important these days, when main memory is measured in gigabytes, but > back when machines had less real memory, the scattering could lead to > excessive page faulting. Much better to allocate symbol table entries > in chunks, and the easiest way to do that is to give the symbol table > its own mini-heap. > > VMS implemented the mini-heap concept (VMS calls them zones) back in > its first release in 1978. Dave Cutler took the concept to Windows NT > (Microsoft calls them private heaps). Lots of applications have built > their own mini-heap system on top of sbrk(), but has a library of > mini-heap-type APIs ever been distributed on Unix? > > -Paul W. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Aug 18 05:27:15 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 17 Aug 2020 15:27:15 -0400 (EDT) Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler Message-ID: <20200817192715.22D9518C09E@mercury.lcs.mit.edu> > From: Jim Geist > When did mmap(2) come about? Pretty sure it's a Berserkleyism. I think it came in with the VM stuff that DARPA mandated for VAX Unix (for the research project they funded). Noel From paul.winalski at gmail.com Tue Aug 18 05:28:27 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 17 Aug 2020 15:28:27 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: <20200817020224.104B518C095@mercury.lcs.mit.edu> Message-ID: On 8/17/20, Jim Geist wrote: > When did mmap(2) come about? Another thing I've seen is building a small > block allocator on top of that. You can guarantee that all your objects are > nicely collected into the same set of pages for locality with very little > overhead. > mmap(2) certainly can be used to allocate blocks for the mini-heap itself, but you still have to write your own equivalents of malloc() and free() to allocate data structures within the mini-heap. The nice thing about VMS heap zones and Microsoft's private heaps is that you get the malloc()/free() layer off-the-shelf; you don't have to roll your own. -Paul W. From lm at mcvoy.com Tue Aug 18 05:30:50 2020 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 17 Aug 2020 12:30:50 -0700 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: <20200817192715.22D9518C09E@mercury.lcs.mit.edu> References: <20200817192715.22D9518C09E@mercury.lcs.mit.edu> Message-ID: <20200817193050.GC11413@mcvoy.com> On Mon, Aug 17, 2020 at 03:27:15PM -0400, Noel Chiappa wrote: > > From: Jim Geist > > > When did mmap(2) come about? > > Pretty sure it's a Berserkleyism. I think it came in with the VM stuff that > DARPA mandated for VAX Unix (for the research project they funded). Bill Joy imagined it, the prototype is in one the 4.x BSD releases. Sun (Joe Moran) actually implemented it first in any Unix variant. It's possible the concept existed in some other OS but I'm not aware of it. From velocityboy at gmail.com Tue Aug 18 05:35:47 2020 From: velocityboy at gmail.com (Jim Geist) Date: Mon, 17 Aug 2020 15:35:47 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: <20200817020224.104B518C095@mercury.lcs.mit.edu> Message-ID: True, but zones and HeapAlloc do a fair bit of work to handle objects of multiple sizes. If you're partitioning up a page and you know every object on the page is 8 or 16 or 48 bytes, it's MUCH simpler. And a lot of the data structures in a compiler tend to be small-tens-of-bytes nodes. On Mon, Aug 17, 2020 at 3:28 PM Paul Winalski wrote: > On 8/17/20, Jim Geist wrote: > > When did mmap(2) come about? Another thing I've seen is building a small > > block allocator on top of that. You can guarantee that all your objects > are > > nicely collected into the same set of pages for locality with very little > > overhead. > > > mmap(2) certainly can be used to allocate blocks for the mini-heap > itself, but you still have to write your own equivalents of malloc() > and free() to allocate data structures within the mini-heap. The nice > thing about VMS heap zones and Microsoft's private heaps is that you > get the malloc()/free() layer off-the-shelf; you don't have to roll > your own. > > -Paul W. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Tue Aug 18 05:41:04 2020 From: rich.salz at gmail.com (Richard Salz) Date: Mon, 17 Aug 2020 15:41:04 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: <20200817020224.104B518C095@mercury.lcs.mit.edu> Message-ID: Apache has the "pool" concept, per-request storage; there are a few versions: https://commons.apache.org/proper/commons-pool/ (java) http://www.apachetutor.org/dev/pools (C server) -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Tue Aug 18 05:50:29 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 17 Aug 2020 15:50:29 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: <20200817193050.GC11413@mcvoy.com> References: <20200817192715.22D9518C09E@mercury.lcs.mit.edu> <20200817193050.GC11413@mcvoy.com> Message-ID: On 8/17/20, Larry McVoy wrote: > On Mon, Aug 17, 2020 at 03:27:15PM -0400, Noel Chiappa wrote: [regarding mmap(2)] > > Bill Joy imagined it, the prototype is in one the 4.x BSD releases. > Sun (Joe Moran) actually implemented it first in any Unix variant. > It's possible the concept existed in some other OS but I'm not aware > of it. > VAX/VMS had the equivalent of mmap(2) back in 1978. You can specify a range of contiguous pages in virtual memory and associate that with a (page-aligned) range of blocks in a file. The blocks in the file act as backing store for the virtual memory. VMS also has a system call $CRETVA (create virtual address space) that lets you associate a VA range using the system page file as backing store. The VMS image activator (runtime loader in Unix-speak) used these primitives to load program images into virtual memory. More than one process can map the same region of a file. This is how sharing of read-only program segments such as .text is implemented. I think Burroughs OSes had this concept even before VMS. There is also $EXPREG (expand address region), which is more or less equivalent to sbrk(). -Paul W. From jnc at mercury.lcs.mit.edu Tue Aug 18 05:51:08 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 17 Aug 2020 15:51:08 -0400 (EDT) Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler Message-ID: <20200817195108.75FED18C09E@mercury.lcs.mit.edu> > From: Larry > It's possible the concept existed in some other OS but I'm not aware of > it. It's pretty old. Both TENEX and ITS had the ability to map file pages into a process' address space. Not sure if anything else of that vintage had it (not sure what other systems back then _had_ paging, other than Atlas; those two both had custom KA10 homebrew hardware mods to support paging). Of course, there's always Multics... (sorry, Ken :-). Noel From halbert at halwitz.org Tue Aug 18 05:44:09 2020 From: halbert at halwitz.org (Dan Halbert) Date: Mon, 17 Aug 2020 15:44:09 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: <20200817193050.GC11413@mcvoy.com> References: <20200817192715.22D9518C09E@mercury.lcs.mit.edu> <20200817193050.GC11413@mcvoy.com> Message-ID: <283d2a61-3a52-9629-6f62-36e00687f949@halwitz.org> On 8/17/20 3:30 PM, Larry McVoy wrote: > On Mon, Aug 17, 2020 at 03:27:15PM -0400, Noel Chiappa wrote: >> > From: Jim Geist >> >> > When did mmap(2) come about? >> >> Pretty sure it's a Berserkleyism. I think it came in with the VM stuff that >> DARPA mandated for VAX Unix (for the research project they funded). > Bill Joy imagined it, the prototype is in one the 4.x BSD releases. > Sun (Joe Moran) actually implemented it first in any Unix variant. > It's possible the concept existed in some other OS but I'm not aware > of it. I have a clear memory of having a discussion with Bill Joy about the idea of vread(2) and vwrite(2) when we were both grad students at Berkeley. I remember we were eating sausages from Top Dog and sitting outside Etcheverry Hall on or near the grassy plaza. I think vfork may have already existed, and we were talking about adding some kind of memory-mapped file I/O. I think I suggested the actual names, as a parallel to vfork. Some of my thinking might have come from my experience with TENEX while working summers at BBN. I was just a sounding board; I wasn't implementing any of this. vread and vwrite were in BSD4.1, but dropped in 4.2 (so my Googling says). I think it became clear later that mmap was an easier concept than the initial vread and vwrite ideas. Dan H. From mobile at majumdar.org.uk Tue Aug 18 06:16:06 2020 From: mobile at majumdar.org.uk (Dibyendu Majumdar) Date: Mon, 17 Aug 2020 21:16:06 +0100 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: Message-ID: On Mon, 17 Aug 2020 at 17:13, Dan Cross wrote: > From my light skimming of V10 sources, it appears that the various components of the default C compiler (that is, not LCC) either use malloc/free or call `sbrk` directly. > Yes, it only uses sbrk(). One consequence I think is that sbrk() expands the process memory without invalidating existing use of memory - so the code is able to periodically expand heap while retaining all existing allocations. A simple workaround I used was to preallocate a heap and just stub out sbrk() calls - so that works. So in essence given a single chunk of memory (if large enough - which is still quite small by today's standards) the compiler manages fine. However I find this unsatisfactory and would like to improve it. But it is a bit difficult to understand how the memory is being used. Memory can be used for declarations, trees (for expressions) and strings as far as I can tell. Strings actually use the tree allocation, and just pretend that a node is a string. It seems that tree memory is allocated in a stack discipline. But what puzzled me is that when a tree starts, about 512 bytes of memory are left as gap for declarations to use. I have been trying to think in what circumstances would you encounter a declaration while parsing an expression - perhaps cast expressions? Anyway - if a declaration occurs inside an expression (i.e. tree) then it only has 512 bytes available. Of course this could be made bigger ... but at the least I would like to have separate heaps for declarations, trees and strings. I guess no one really dug into this code - as presumably once PCC came along the original compiler by Dennis stopped being used. Thanks and Regards Dibyendu From paul.winalski at gmail.com Tue Aug 18 06:34:17 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 17 Aug 2020 16:34:17 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: Message-ID: On 8/17/20, Dibyendu Majumdar wrote: > > Yes, it only uses sbrk(). One consequence I think is that sbrk() > expands the process memory without invalidating existing use of memory > - so the code is able to periodically expand heap while retaining all > existing allocations. If everyone does that, you can call other people's code without fear of stepping on their memory when you allocate memory in your code. Using a negative value to decrease the break is more problematic. malloc() usually uses sbrk() to extend its heap. When we ported DEC's GEM compilation system to Unix, I used sbrk() to extend memory and built my own multiple heap allocation scheme on top of that. I could have used malloc() to allocate the heap chunks, but there was no point. Might as well cut out the middleman. -Paul W. From mobile at majumdar.org.uk Tue Aug 18 06:43:59 2020 From: mobile at majumdar.org.uk (Dibyendu Majumdar) Date: Mon, 17 Aug 2020 21:43:59 +0100 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: Message-ID: On Mon, 17 Aug 2020 at 21:34, Paul Winalski wrote: > > On 8/17/20, Dibyendu Majumdar wrote: > > > > Yes, it only uses sbrk(). One consequence I think is that sbrk() > > expands the process memory without invalidating existing use of memory > > - so the code is able to periodically expand heap while retaining all > > existing allocations. > > If everyone does that, you can call other people's code without fear > of stepping on their memory when you allocate memory in your code. > Using a negative value to decrease the break is more problematic. > malloc() usually uses sbrk() to extend its heap. > > When we ported DEC's GEM compilation system to Unix, I used sbrk() to > extend memory and built my own multiple heap allocation scheme on top > of that. I could have used malloc() to allocate the heap chunks, but > there was no point. Might as well cut out the middleman. > Unfortunately sbrk() is not portable (I am building on Windows with MSVC too) and as far as I know was even removed from POSIX. >From Wikipedia: sbrk and brk are considered legacy even by 1997 standards (Single UNIX Specification v2 or POSIX.1-1998).[5] They were removed in POSIX.1-2001.[6] Regards Dibyendu From imp at bsdimp.com Tue Aug 18 07:05:39 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 17 Aug 2020 15:05:39 -0600 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: Message-ID: On Mon, Aug 17, 2020 at 2:45 PM Dibyendu Majumdar wrote: > On Mon, 17 Aug 2020 at 21:34, Paul Winalski > wrote: > > > > On 8/17/20, Dibyendu Majumdar wrote: > > > > > > Yes, it only uses sbrk(). One consequence I think is that sbrk() > > > expands the process memory without invalidating existing use of memory > > > - so the code is able to periodically expand heap while retaining all > > > existing allocations. > > > > If everyone does that, you can call other people's code without fear > > of stepping on their memory when you allocate memory in your code. > > Using a negative value to decrease the break is more problematic. > > malloc() usually uses sbrk() to extend its heap. > > > > When we ported DEC's GEM compilation system to Unix, I used sbrk() to > > extend memory and built my own multiple heap allocation scheme on top > > of that. I could have used malloc() to allocate the heap chunks, but > > there was no point. Might as well cut out the middleman. > > > > Unfortunately sbrk() is not portable (I am building on Windows with > MSVC too) and as far as I know was even removed from POSIX. > > From Wikipedia: > sbrk and brk are considered legacy even by 1997 standards (Single UNIX > Specification v2 or POSIX.1-1998).[5] They were removed in > POSIX.1-2001.[6] > gnu emacs was the last big user of sbrk. It was one of the few programs that didn't run on FreeBSD/arm64 which never had sbrk() because it wasn't possible to sanely implement. It wasn't until recently that gnu emacs fixed things to not use sbrk()... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From mobile at majumdar.org.uk Tue Aug 18 07:29:38 2020 From: mobile at majumdar.org.uk (Dibyendu Majumdar) Date: Mon, 17 Aug 2020 22:29:38 +0100 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: Message-ID: On Mon, 17 Aug 2020 at 21:16, Dibyendu Majumdar wrote: > Memory can be used for declarations, trees (for expressions) and > strings as far as I can tell. Strings actually use the tree > allocation, and just pretend that a node is a string. > It seems that tree memory is allocated in a stack discipline. But what > puzzled me is that when a tree starts, about 512 bytes of memory are > left as gap for declarations to use. I have been trying to think in > what circumstances would you encounter a declaration while parsing an > expression - perhaps cast expressions? Anyway - if a declaration > occurs inside an expression (i.e. tree) then it only has 512 bytes > available. Of course this could be made bigger ... but at the least I > would like to have separate heaps for declarations, trees and strings. > Okay it seems those are undefined symbols encountered in an expression. Symbols use the same allocation function as declarations. Regards Dibyendu From krewat at kilonet.net Tue Aug 18 08:05:09 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 17 Aug 2020 18:05:09 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: <20200817192715.22D9518C09E@mercury.lcs.mit.edu> <20200817193050.GC11413@mcvoy.com> Message-ID: <88b97e2f-ddd2-8c5b-f2ac-3d4305c6ae86@kilonet.net> On 8/17/2020 3:50 PM, Paul Winalski wrote: > VAX/VMS had the equivalent of mmap(2) back in 1978. You can specify a > range of contiguous pages in virtual memory and associate that with a > (page-aligned) range of blocks in a file. The blocks in the file act > as backing store for the virtual memory. I, and my boss, took advantage of that while converting his database software from TOPS-10 to VMS. His TOPS-10 implementation used various ways to optimize I/O from/to disk. On VMS, our benchmarks showed that as long as we understood the paging size, performance was about the same. RP06 vs. I think something bigger. Maybe RP07. But even still, it proved the operating system virtual memory system was up to the task. I seem to remember there was a way to sync a page after you wrote it just to make sure it was committed to disk. It worked so well that I also seem to recall that we used some of that file space as heap. art k. From norman at oclsc.org Tue Aug 18 08:32:29 2020 From: norman at oclsc.org (Norman Wilson) Date: Mon, 17 Aug 2020 18:32:29 -0400 (EDT) Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler Message-ID: <20200817223229.5401A4422E@lignose.oclsc.org> Dan Cross: I'll confess I haven't looked _that_ closely, but I rather imagine that the V10 compiler is a descendant of PCC rather than Dennis's V6/V7 PDP-11 compiler. ==== Correct. From 8/e to the end of official Research UNIX, cc was pcc2 with a few research-specific hacks. As Dan says, lcc was there too, but not used a lot. I'm not sure which version of lcc it was; probably it was already out-of-date. In my private half-backed 10/e descendant system, which runs only on MicroVAXes in my basement, cc is an lcc descendant instead. I took the lcc on which the book was based and re-ported it to the VAX to get an ISO- compliant C compiler, and made small changes to libc and /usr/include to afford ISO-C compliance there too. The hardest but most-interesting part was optimizing. lcc does a lot of optimization work by itself, and initially I'd hoped to dispense with a separate c2 pass entirely, but that turns out not to be feasible on machines like the VAX or the PDP-11: internally lcc separates something like c = *p++; into two operations c = *p; p++; and makes two distinct calls to the code generator. To sew them back together from cvtbl (p),c incl p to cvtbl (p)+,c requires external help; lcc just can't see that what it thinks of as two distinct expressions can be combined. It's more than 15 years since I last looked at any of this stuff, but I vaguely remember that lcc has its own interesting (but ISO/POSIX-compatible) memory-allocation setup. It allows several nested contexts' worth of allocation, freeing an inner context when there's no longer any need for it. For example, once the compiler has finished with a function and has no further need for its local symbols, it frees the associated memory. See the lcc book for details. Read the book anyway; it's the one case I know of in which the authors followed strict Literate Programming rules and made a big success of it. Not only is the compiler well- documented, but the result is a wonderful tour through the construction and design decisions of a large program that does real work. Norman Wilson Toronto ON From dave at horsfall.org Tue Aug 18 08:47:04 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 18 Aug 2020 08:47:04 +1000 (EST) Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: Message-ID: On Mon, 17 Aug 2020, Dibyendu Majumdar wrote: > From Wikipedia: > sbrk and brk are considered legacy even by 1997 standards (Single UNIX > Specification v2 or POSIX.1-1998).[5] They were removed in > POSIX.1-2001.[6] On a whim, I checked a couple of boxes around here (I haven't used sbrk() since malloc() came along): Mac: The brk and sbrk functions are historical curiosities left over from ear- lier days before the advent of virtual memory management. FreeBSD: The brk() and sbrk() functions are legacy interfaces from before the advent of modern virtual memory management. Both of them come right after the DESCRIPTION header. -- Dave From bakul at iitbombay.org Tue Aug 18 08:55:31 2020 From: bakul at iitbombay.org (Bakul Shah) Date: Mon, 17 Aug 2020 15:55:31 -0700 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: <20200817223229.5401A4422E@lignose.oclsc.org> References: <20200817223229.5401A4422E@lignose.oclsc.org> Message-ID: <7B3D5DB4-B593-4EC8-ABEE-2AC77DFE3F73@iitbombay.org> On Aug 17, 2020, at 3:32 PM, Norman Wilson wrote: > > The hardest but most-interesting part was optimizing. > lcc does a lot of optimization work by itself, and > initially I'd hoped to dispense with a separate c2 > pass entirely, but that turns out not to be feasible > on machines like the VAX or the PDP-11: internally > lcc separates something like > c = *p++; > into two operations > c = *p; > p++; > and makes two distinct calls to the code generator. > To sew them back together from > cvtbl (p),c > incl p > to > cvtbl (p)+,c > requires external help; lcc just can't see that > what it thinks of as two distinct expressions > can be combined. Didn't lcc use iburg or some such to generate the code generator, which could do such things? > See the lcc book for details. Read the book anyway; > it's the one case I know of in which the authors > followed strict Literate Programming rules and made > a big success of it. Not only is the compiler well- > documented, but the result is a wonderful tour > through the construction and design decisions of a > large program that does real work. Agree. They used noweb. Probably with a troff backend? From cym224 at gmail.com Tue Aug 18 09:06:56 2020 From: cym224 at gmail.com (Nemo Nusquam) Date: Mon, 17 Aug 2020 19:06:56 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: Message-ID: <107719ce-b631-c4c9-fedd-ac8845d01213@gmail.com> On 08/17/20 18:47, Dave Horsfall wrote: > On Mon, 17 Aug 2020, Dibyendu Majumdar wrote: > >> From Wikipedia: >> sbrk and brk are considered legacy even by 1997 standards (Single UNIX >> Specification v2 or POSIX.1-1998).[5] They were removed in >> POSIX.1-2001.[6] > > On a whim, I checked a couple of boxes around here (I haven't used sbrk() > since malloc() came along): > > Mac: > > The brk and sbrk functions are historical curiosities left over > from ear- > lier days before the advent of virtual memory management. > > FreeBSD: > > The brk() and sbrk() functions are legacy interfaces from before the > advent of modern virtual memory management. > > Both of them come right after the DESCRIPTION header. More whimsy from "man sbrk" on Solaris 10: The use of mmap(2) is now preferred because it can be used portably with all other memory allocation functions and with any function that uses other allocation functions. N. > > -- Dave From chet.ramey at case.edu Tue Aug 18 09:12:45 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Mon, 17 Aug 2020 19:12:45 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: <20200817223229.5401A4422E@lignose.oclsc.org> References: <20200817223229.5401A4422E@lignose.oclsc.org> Message-ID: On 8/17/20 6:32 PM, Norman Wilson wrote: > It's more than 15 years since I last looked at any > of this stuff, but I vaguely remember that lcc has > its own interesting (but ISO/POSIX-compatible) > memory-allocation setup. It allows several nested > contexts' worth of allocation, freeing an inner > context when there's no longer any need for it. > For example, once the compiler has finished with > a function and has no further need for its local > symbols, it frees the associated memory. Arenas. http://drhanson.s3.amazonaws.com/storage/documents/fastalloc.pdf I'm pretty sure this is the literate programming variant Fraser and Hanson used for the book: https://www.cs.tufts.edu/~nr/pubs/lpsimp.pdf -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From steffen at sdaoden.eu Tue Aug 18 09:40:13 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 18 Aug 2020 01:40:13 +0200 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: <20200817020224.104B518C095@mercury.lcs.mit.edu> Message-ID: <20200817234013.2Y5X5%steffen@sdaoden.eu> Richard Salz wrote in : |Apache has the "pool" concept, per-request storage; there are a few And BSD Mail had the "stringdope" of Kurt Shoens from the very start in 1978. It serves allocations of various size until reset time. (Different to the Apache thing it does not support destructor calls -- if i recall the Apache stuff, i have looked into that two decades ago.) I personally had objects caches and fluctuating object caches backed by generic C types pub GOCache(uir _objsz, uir _growby=8-1); ... pub uir count(void) const { return(m_count); } pub void *alloc(void); pub GOCache &free(void *_ptr); pub GOCache &clear(void); pub GOCache &swap(GOCache &_t); and used via all-inline template wrappers template class OCache : private GOCache{ ... OCache(uir _growby=8-1) : Super(szof(T), _growby) {} ... pub T *newObject(void) { return(SF_newHeap(T, Super::alloc())); } pub OCache &delObject(T *_tptr){ _AssertRetThis(_tptr != NIL); _tptr->~T(); return(s(Me&,Super::free(_tptr))); } ... The difference was that the normal could not free individual chunks, the other could pri union Atom{ Chunk *owner; // used Atom *next; // free }SF_CC_PACKED; pri struct Chunk{ Chunk *right; Atom *free; // freelist ui1 *top; // cast point or NIL if full uir count; // user pointers this Chunk }SF_CC_PACKED; vs pri struct Atom{ Atom *next; }SF_CC_PACKED; pri struct Chunk{ Chunk *right; ui1 *top; // cast point or NIL if full }SF_CC_PACKED; (here the free Atom free list was part of the cache object). That even worked out fine to serve nodes on hashmap and list objects, in practice. |versions: | https://commons.apache.org/proper/commons-pool/ (java) | http://www.apachetutor.org/dev/pools (C server) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From gingell at computer.org Tue Aug 18 10:52:08 2020 From: gingell at computer.org (Rob Gingell) Date: Mon, 17 Aug 2020 17:52:08 -0700 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: <20200817192715.22D9518C09E@mercury.lcs.mit.edu> References: <20200817192715.22D9518C09E@mercury.lcs.mit.edu> Message-ID: On 8/17/2020 12:27 PM, Noel Chiappa wrote: > > From: Jim Geist > > > When did mmap(2) come about? > > Pretty sure it's a Berserkleyism. I think it came in with the VM stuff that > DARPA mandated for VAX Unix (for the research project they funded). [What follows verges on being COFF-ish]. mmap() is descended from TENEX's PMAP, which is a simplified descendant of the file/process memory integration provided by Multics. (Other antecedents I leave to more informed genealogists than I.) A Multics process had an address space made up of segments (files) which were paged (vs. swapped). Segments were what programs dealt with, paging was done to manage the physical resources of the system. TENEX simplified everything to pages, address spaces were composed by mapping pages of the address space to files. Programs operated on pages, which were also what the system used to manage memory. Files were described by page tables, address spaces were described by page tables, lots of symmetry around things of size 512 (9 bits) (page size, page table size, page-tables of page tables for long files). File size and file system system capacities were announced in pages. Very harmonious, but uniquely so. Multics was most definitely not portable due to its unique hardware constraints (Intel's 432 being an exception). TENEX only required paging support but was not portable from PDP-10s which were not keeping up with the world's movement to computers that were increasingly 4-bits shy of a word (i.e., not 36 bits). Many more considerations apply but to keep it only verging on COFF-ish will stop there -- going deeper would be best done in person with tankards of ale. TENEX systems were ARPA's workhorse systems in the 1970s, supporting numerous research programs and sites. The file/process memory integration was a valued capability among the community (though, honestly, it was one of these things everyone said should exist though few actually used directly). Even though DEC provided commercial support by adopting TENEX as TOPS-20 and selling 1000s of them (vs. the 10s of them made via BBN + PARC's MAXC), as the 70's progressed it was apparent that things were going to shift elsewhere. DEC was hesitant about further 36-bit development and UNIX's arrival provided an intellectual migration path for the community that commercial alternatives didn't. If only UNIX could just accumulate some of the capabilities expected in the ARPA world, like file/process memory integration (ironically, one of the Multics complexities from which UNIX had departed.) mmap() is a simplified, portable form of PMAP. It was written into the specifications for ARPA via Bill Joy as Larry McVoy and Noel Chiappa noted. It existed only as a specification for quite a while. First implementations were as a device-driver level function for things like frame-buffers for use by window systems and perhaps for other devices I'm not remembering at the moment. The general file/process memory integration aspect didn't happen prior to SunOS 4.0 though I seem to recall some special-case subsets being tried by other UNIX implementations and also more generally with Mach, I believe. The gestalt of file/process memory integration in 4.0 was very TENEX-like in how it was used in fork()/exec()/brk()/shared libraries. 4.0 differed from TENEX in being portable, launched on heterogeneous hardware (VAX, 68010 (Sun-2's), 68020 (Sun-3's), 386 (386i), SPARC (Sun-4) all except the VAX being actively supported Sun products at the time), and a general-networking view of how coherency should work (vs. a clustered-network such as TOPS-20's CFS.) (As a hysterical note, every release of (BSD-based) SunOS through 4.0 was always ported to the VAX as a portability check. It also provied us utility as a convenient way to quickly check for "but it works on the VAX" problems with new things gotten from UCB. Prior to 4.0, given that the BSD-based implementation basically tried to mimic a VAX internally, that wasn't too bad. But the VAXectomy that occurred in 4.0 made that much more daunting, and so the 4.0 VAX port was a pretty half-hearted attempt and the last new task for the 11/750 that faded deeper and deeper into the back of the lab over time.) From arnold at skeeve.com Tue Aug 18 16:33:36 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 18 Aug 2020 00:33:36 -0600 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: <20200817223229.5401A4422E@lignose.oclsc.org> References: <20200817223229.5401A4422E@lignose.oclsc.org> Message-ID: <202008180633.07I6XaeI013719@freefriends.org> norman at oclsc.org (Norman Wilson) wrote: > See the lcc book for details. Read the book anyway; > it's the one case I know of in which the authors > followed strict Literate Programming rules and made > a big success of it. Oh, wouldn't you say that TeX also "followed strict Literate Programming rules and made a big success of it"? It's been a while, but I've read the TeX Book. It's a tour de force; what Knuth accomplishes in very little space is amazing. > Not only is the compiler well- > documented, but the result is a wonderful tour > through the construction and design decisions of a > large program that does real work. I'll agree, worth reading. Thanks, Arnold From dfawcus+lists-tuhs at employees.org Tue Aug 18 23:57:16 2020 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Tue, 18 Aug 2020 14:57:16 +0100 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> Message-ID: <20200818135716.GA93457@clarinet.employees.org> On Thu, Aug 13, 2020 at 04:04:22PM -0400, John Cowan wrote: > But this reminded me: Does anyone remember a system of any sort where there > were *two* corresponding sets of alphanumeric error codes, one short and > meaningless like F32 and the other somewhat meaningful like POWER_LOW? I > made up this example, but I have a feeling I saw or read about such > a system. I can't pin it down with Dr. Google. Something early from Digital Research? Not quite what you describe, but a late DR OS had the following scheme. http://bitsavers.org/pdf/digitalResearch/flexos/1073-2003_FlexOS_Users_Guide_V1.3_Nov86.pdf page 4, and 128 onwards: The help level can have a value between 1 and 4. Your computer manufacturer sets a default help level which you can override with DEFINE. 1 Displays the FlexOS function, the error source module, and the return code. 2 Identifies the command and type of error in one sentence. An example of a level 2 error message is "COPY: Write error." 3 Expands on the level 2 message and includes more specific information. An example of a level 3 message is "COPY: An error occurred writing report.txt on a:". 4 Expands on the level 3 message and often suggests a possible solution to the error. An example of a level 4 message is "COPY: An error occurred writing report.txt on a: The disk a: is full. You can erase unnecessary files to free up space." Where for scheme 1 it gave something like: Error Code = 80137712 System Source Module = Pipe System Function Returning the Error = write_data Error Argument (long in HEX) = 123456 Error Argument (character string) = string With only one of the last two lines printed, depending upon the function in question. DF From cowan at ccil.org Wed Aug 19 00:11:45 2020 From: cowan at ccil.org (John Cowan) Date: Tue, 18 Aug 2020 10:11:45 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <20200818135716.GA93457@clarinet.employees.org> References: <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> <20200818135716.GA93457@clarinet.employees.org> Message-ID: No, that definitely wasn't it: this is of the "numeric code plus text string" type, although it's interesting because it has multiple-length text strings to trade off verbosity/helpfulness. It kind of reminds me of what you get in ADVENT when you move to a place you have been before. You get only a brief description, but if you type DESCRIBE you get the full monty. That must have saved a lot of LA34/36 paper. :-) On Tue, Aug 18, 2020 at 10:07 AM Derek Fawcus < dfawcus+lists-tuhs at employees.org> wrote: > On Thu, Aug 13, 2020 at 04:04:22PM -0400, John Cowan wrote: > > But this reminded me: Does anyone remember a system of any sort where > there > > were *two* corresponding sets of alphanumeric error codes, one short and > > meaningless like F32 and the other somewhat meaningful like POWER_LOW? I > > made up this example, but I have a feeling I saw or read about such > > a system. I can't pin it down with Dr. Google. > > Something early from Digital Research? > > Not quite what you describe, but a late DR OS had the following scheme. > > > http://bitsavers.org/pdf/digitalResearch/flexos/1073-2003_FlexOS_Users_Guide_V1.3_Nov86.pdf > > page 4, and 128 onwards: > > The help level can have a value between 1 and 4. Your computer > manufacturer sets a default help level which you can override with DEFINE. > > 1 Displays the FlexOS function, the error source module, and the > return code. > 2 Identifies the command and type of error in one sentence. > An example of a level 2 error message is "COPY: Write error." > 3 Expands on the level 2 message and includes more specific > information. > An example of a level 3 message is "COPY: An error occurred writing > report.txt on a:". > 4 Expands on the level 3 message and often suggests a possible > solution to the error. > An example of a level 4 message is "COPY: An error occurred writing > report.txt on a: The disk a: is full. You can erase unnecessary files to > free up space." > > Where for scheme 1 it gave something like: > > Error Code = 80137712 > System Source Module = Pipe System > Function Returning the Error = write_data > Error Argument (long in HEX) = 123456 > Error Argument (character string) = string > > With only one of the last two lines printed, depending upon the function > in question. > > DF > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Fri Aug 21 00:09:41 2020 From: rich.salz at gmail.com (Richard Salz) Date: Thu, 20 Aug 2020 10:09:41 -0400 Subject: [TUHS] Style command source available? Message-ID: Is the style command (and perhaps other DWB programs) legally available anywhere? Replies to me will be summarized for the list. :) tnx. -------------- next part -------------- An HTML attachment was scrubbed... URL: From velocityboy at gmail.com Fri Aug 21 00:45:00 2020 From: velocityboy at gmail.com (Jim Geist) Date: Thu, 20 Aug 2020 10:45:00 -0400 Subject: [TUHS] Style command source available? In-Reply-To: References: Message-ID: I was recently looking at the C compiler in v10 in the TUHS archives and I believe it's in there. On Thu, Aug 20, 2020 at 10:11 AM Richard Salz wrote: > Is the style command (and perhaps other DWB programs) legally available > anywhere? > > Replies to me will be summarized for the list. :) > > tnx. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Aug 21 01:14:17 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 20 Aug 2020 11:14:17 -0400 Subject: [TUHS] Style command source available? In-Reply-To: References: Message-ID: The DWB distribution from the Toolkit is not around to my knowledge, but: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd look for the diction and style directories, which should be close. Note to Warren, probably should create and area for the Toolkit codes and see if we can start to collect them, such as a few versions of ksh, DWB, different games for the JERQ, *et al.* I wish I had a list of everything that was in it, but if we all go looking we might be able to pull much of that material together. On Thu, Aug 20, 2020 at 10:45 AM Jim Geist wrote: > I was recently looking at the C compiler in v10 in the TUHS archives and I > believe it's in there. > > On Thu, Aug 20, 2020 at 10:11 AM Richard Salz wrote: > >> Is the style command (and perhaps other DWB programs) legally available >> anywhere? >> >> Replies to me will be summarized for the list. :) >> >> tnx. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Fri Aug 21 01:44:33 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 20 Aug 2020 11:44:33 -0400 (EDT) Subject: [TUHS] Style command source available? In-Reply-To: References: Message-ID: On Thu, 20 Aug 2020, Clem Cole wrote: > Note to Warren, probably should create and area for the Toolkit codes and > see if we can start to collect them, such as a few versions of ksh, DWB, > different games for the JERQ, *et al.* I wish I had a list of everything > that was in it, but if we all go looking we might be able to pull much of > that material together. Funny you mention ksh since I've been trying to kitbash ksh93 into being able to compile with make instead of the funky build system it currently uses, without a lot of luck. -uso. From cowan at ccil.org Fri Aug 21 02:08:18 2020 From: cowan at ccil.org (John Cowan) Date: Thu, 20 Aug 2020 12:08:18 -0400 Subject: [TUHS] Style command source available? In-Reply-To: References: Message-ID: On Thu, Aug 20, 2020 at 11:55 AM Steve Nickolas wrote: > Funny you mention ksh since I've been trying to kitbash ksh93 into being > able to compile with make instead of the funky build system it currently > uses, without a lot of luck. > IIRC, Korn used make when developing ksh, but then shipped it with a /bin/sh script because it was more portable than make was in those days (and still is; there are tools that warn you to use gmake on BSD). After all, a build process (unless it is interrupted) just needs to build, it doesn't need to keep track of what has already been built. That said, I have no idea what the state of the build process is now. America is not a morally pure country. No country ever has been or ever will be, but in democratic countries you get things done by compromising your principles in order to form alliances with groups about whom you have grave doubts. --Richard Rorty, Achieving Our Country (1998) -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Fri Aug 21 02:30:33 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 20 Aug 2020 12:30:33 -0400 (EDT) Subject: [TUHS] Style command source available? In-Reply-To: References: Message-ID: On Thu, 20 Aug 2020, John Cowan wrote: > On Thu, Aug 20, 2020 at 11:55 AM Steve Nickolas wrote: > >> Funny you mention ksh since I've been trying to kitbash ksh93 into being >> able to compile with make instead of the funky build system it currently >> uses, without a lot of luck. > > IIRC, Korn used make when developing ksh, but then shipped it with a > /bin/sh script because it was more portable than make was in those days > (and still is; there are tools that warn you to use gmake on BSD). After > all, a build process (unless it is interrupted) just needs to build, it > doesn't need to keep track of what has already been built. > > That said, I have no idea what the state of the build process is now. It's still a shell script. Big huge shell script. I was trying to simplify the build process because I'm trying to coax ksh to build with a nonstandard cc/libc combination as part of an attempt to make Linux more like "real" (read: commercial/historic) Unices. They're pretty compatible with gcc and glibc, but they're not gcc and glibc. -uso. From cowan at ccil.org Fri Aug 21 02:48:04 2020 From: cowan at ccil.org (John Cowan) Date: Thu, 20 Aug 2020 12:48:04 -0400 Subject: [TUHS] Style command source available? In-Reply-To: References: Message-ID: That suggests to me like factoring the script would be the first place to start. On Thu, Aug 20, 2020 at 12:30 PM Steve Nickolas wrote: > On Thu, 20 Aug 2020, John Cowan wrote: > > > On Thu, Aug 20, 2020 at 11:55 AM Steve Nickolas > wrote: > > > >> Funny you mention ksh since I've been trying to kitbash ksh93 into being > >> able to compile with make instead of the funky build system it currently > >> uses, without a lot of luck. > > > > IIRC, Korn used make when developing ksh, but then shipped it with a > > /bin/sh script because it was more portable than make was in those days > > (and still is; there are tools that warn you to use gmake on BSD). After > > all, a build process (unless it is interrupted) just needs to build, it > > doesn't need to keep track of what has already been built. > > > > That said, I have no idea what the state of the build process is now. > > It's still a shell script. Big huge shell script. > > I was trying to simplify the build process because I'm trying to coax ksh > to build with a nonstandard cc/libc combination as part of an attempt to > make Linux more like "real" (read: commercial/historic) Unices. They're > pretty compatible with gcc and glibc, but they're not gcc and glibc. > > -uso. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Fri Aug 21 05:42:39 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Thu, 20 Aug 2020 15:42:39 -0400 Subject: [TUHS] Style command source available? In-Reply-To: References: Message-ID: <5c629889-d4b0-761e-9eb2-76b73ffa097b@case.edu> On 8/20/20 12:08 PM, John Cowan wrote: > > > On Thu, Aug 20, 2020 at 11:55 AM Steve Nickolas > wrote: >   > > Funny you mention ksh since I've been trying to kitbash ksh93 into being > able to compile with make instead of the funky build system it currently > uses, without a lot of luck. > > > IIRC, Korn used make when developing ksh, but then shipped it with a > /bin/sh script because it was more portable than make was in those days > (and still is; there are tools that warn you to use gmake on BSD).  After > all, a build process (unless it is interrupted) just needs to build, it > doesn't need to keep track of what has already been built. He might have started with make for ksh83 and 86, but switched to Fowler's nmake and then shipped that /bin/sh script in ksh88 for people (everyone, basically) who didn't have nmake. > That said, I have no idea what the state of the build process is now. Changing that was one of the controversial modifications made to ksh93 in ksh-2020. It's pretty complex. Here's a paper that describes part of it: https://www.usenix.org/legacy/publications/library/proceedings/vhll/full_papers/fowler.feature.ps -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From cowan at ccil.org Fri Aug 21 09:15:11 2020 From: cowan at ccil.org (John Cowan) Date: Thu, 20 Aug 2020 19:15:11 -0400 Subject: [TUHS] Style command source available? In-Reply-To: <5c629889-d4b0-761e-9eb2-76b73ffa097b@case.edu> References: <5c629889-d4b0-761e-9eb2-76b73ffa097b@case.edu> Message-ID: Unfortunately Ghostscript can't convert that .ps file to a PDF. On Thu, Aug 20, 2020 at 3:42 PM Chet Ramey wrote: > On 8/20/20 12:08 PM, John Cowan wrote: > > > > > > On Thu, Aug 20, 2020 at 11:55 AM Steve Nickolas > > wrote: > > > > > > Funny you mention ksh since I've been trying to kitbash ksh93 into > being > > able to compile with make instead of the funky build system it > currently > > uses, without a lot of luck. > > > > > > IIRC, Korn used make when developing ksh, but then shipped it with a > > /bin/sh script because it was more portable than make was in those days > > (and still is; there are tools that warn you to use gmake on BSD). After > > all, a build process (unless it is interrupted) just needs to build, it > > doesn't need to keep track of what has already been built. > > He might have started with make for ksh83 and 86, but switched to Fowler's > nmake and then shipped that /bin/sh script in ksh88 for people (everyone, > basically) who didn't have nmake. > > > That said, I have no idea what the state of the build process is now. > > Changing that was one of the controversial modifications made to ksh93 in > ksh-2020. It's pretty complex. > > Here's a paper that describes part of it: > > > https://www.usenix.org/legacy/publications/library/proceedings/vhll/full_papers/fowler.feature.ps > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Fri Aug 21 09:17:56 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Thu, 20 Aug 2020 19:17:56 -0400 Subject: [TUHS] Style command source available? In-Reply-To: References: <5c629889-d4b0-761e-9eb2-76b73ffa097b@case.edu> Message-ID: On 8/20/20 7:15 PM, John Cowan wrote: > Unfortunately Ghostscript can't convert that .ps file to a PDF. https://www.researchgate.net/profile/John_Snyder16/publication/261861597_Feature-based_portability/links/595657170f7e9bed45f67c53/Feature-based-portability.pdf See if that works better. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From jcapp at anteil.com Fri Aug 21 09:20:40 2020 From: jcapp at anteil.com (Jim Capp) Date: Thu, 20 Aug 2020 19:20:40 -0400 (EDT) Subject: [TUHS] Style command source available? In-Reply-To: Message-ID: <6304816.1759.1597965640616.JavaMail.root@zimbraanteil> There is an email header in the file. If you edit it and remove everything before the %!PS-Adobe-2.0 preamble, it will load with gs and converts perfectly to pdf with ps2pdf. From: "John Cowan" To: "chet ramey" Cc: "The Eunuchs Hysterical Society" Sent: Thursday, August 20, 2020 7:15:11 PM Subject: Re: [TUHS] Style command source available? Unfortunately Ghostscript can't convert that .ps file to a PDF. On Thu, Aug 20, 2020 at 3:42 PM Chet Ramey < chet.ramey at case.edu > wrote: On 8/20/20 12:08 PM, John Cowan wrote: > > > On Thu, Aug 20, 2020 at 11:55 AM Steve Nickolas < usotsuki at buric.co > > wrote: > > > Funny you mention ksh since I've been trying to kitbash ksh93 into being > able to compile with make instead of the funky build system it currently > uses, without a lot of luck. > > > IIRC, Korn used make when developing ksh, but then shipped it with a > /bin/sh script because it was more portable than make was in those days > (and still is; there are tools that warn you to use gmake on BSD). After > all, a build process (unless it is interrupted) just needs to build, it > doesn't need to keep track of what has already been built. He might have started with make for ksh83 and 86, but switched to Fowler's nmake and then shipped that /bin/sh script in ksh88 for people (everyone, basically) who didn't have nmake. > That said, I have no idea what the state of the build process is now. Changing that was one of the controversial modifications made to ksh93 in ksh-2020. It's pretty complex. Here's a paper that describes part of it: https://www.usenix.org/legacy/publications/library/proceedings/vhll/full_papers/fowler.feature.ps -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From skogtun at gmail.com Fri Aug 21 19:21:58 2020 From: skogtun at gmail.com (Harald Arnesen) Date: Fri, 21 Aug 2020 11:21:58 +0200 Subject: [TUHS] Style command source available? In-Reply-To: References: <5c629889-d4b0-761e-9eb2-76b73ffa097b@case.edu> Message-ID: <7b24cae8-604a-4b0f-d56e-479f32702b84@gmail.com> John Cowan [21.08.2020 01:15]: > ``The lyf so short, the craft so long to lerne.'' - Chaucer >                  ``Ars longa, vita brevis'' - Hippocrates Of course, what Hippokrates really wrote was "Ὁ βίος βραχύς, ἡ δὲ τέχνη μακρή" -- Hilsen Harald From cowan at ccil.org Sat Aug 22 00:42:45 2020 From: cowan at ccil.org (John Cowan) Date: Fri, 21 Aug 2020 10:42:45 -0400 Subject: [TUHS] Style command source available? In-Reply-To: <7b24cae8-604a-4b0f-d56e-479f32702b84@gmail.com> References: <5c629889-d4b0-761e-9eb2-76b73ffa097b@case.edu> <7b24cae8-604a-4b0f-d56e-479f32702b84@gmail.com> Message-ID: On Fri, Aug 21, 2020 at 5:22 AM Harald Arnesen wrote: > > ``Ars longa, vita brevis'' - Hippocrates > > Of course, what Hippokrates really wrote was > "Ὁ βίος βραχύς, ἡ δὲ τέχνη μακρή" > Naturally. But for hysterical raisins I stick to ASCII in my .sigs, and anyway, the Latin version allows me to say "Arse longa, vita brevis" when appropriate. What Hippocrates definitely didn't say was "First, do no harm", though it is close to something in the Epidemics which I have refrained from looking up. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org No, John. I want formats that are actually useful, rather than over- featured megaliths that address all questions by piling on ridiculous internal links in forms which are hideously over-complex. --Simon St. Laurent on xml-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Sat Aug 22 01:17:13 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Fri, 21 Aug 2020 11:17:13 -0400 (EDT) Subject: [TUHS] Style command source available? In-Reply-To: References: <5c629889-d4b0-761e-9eb2-76b73ffa097b@case.edu> <7b24cae8-604a-4b0f-d56e-479f32702b84@gmail.com> Message-ID: On Fri, 21 Aug 2020, John Cowan wrote: > What Hippocrates definitely didn't say was "First, do no harm", though it > is close to something in the Epidemics which I have refrained from looking > up. Sounds more like John Wesley, actually. -uso. From steffen at sdaoden.eu Sat Aug 22 01:23:11 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 21 Aug 2020 17:23:11 +0200 Subject: [TUHS] Style command source available? In-Reply-To: References: <5c629889-d4b0-761e-9eb2-76b73ffa097b@case.edu> <7b24cae8-604a-4b0f-d56e-479f32702b84@gmail.com> Message-ID: <20200821152311.kvK7n%steffen@sdaoden.eu> John Cowan wrote in : |On Fri, Aug 21, 2020 at 5:22 AM Harald Arnesen wrote: |>> ``Ars longa, vita brevis'' - Hippocrates |> |> Of course, what Hippokrates really wrote was |> "Ὁ βίος βραχύς, ἡ δὲ τέχνη μακρή" | |Naturally. But for hysterical raisins I stick to ASCII in my .sigs, and |anyway, the Latin version allows me to say "Arse longa, vita brevis" when |appropriate. | |What Hippocrates definitely didn't say was "First, do no harm", though it |is close to something in the Epidemics which I have refrained from looking |up. It was Schopenhauer who definetely said Neminem laede, imo omnes, quantum potes, juva! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From doug at cs.dartmouth.edu Sat Aug 22 13:29:50 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Fri, 21 Aug 2020 23:29:50 -0400 Subject: [TUHS] bare m4 (was BTL summmer employees) Message-ID: <202008220329.07M3ToZP041995@tahoe.cs.Dartmouth.EDU> > >> Even high-school employees could make lasting contributions. I am > >> indebted to Steve for a technique he conceived during his first summer > >> assignment: using macro definitions as if they were units of associative > >> memory. This view of macros stimulated previously undreamed-of uses. > > > Can you give some examples of what this looked like? > See attached for an answer to Arnold's question Doug -------------- next part -------------- define(_,`dnl')_ unobtrusive dnl, used for readability _ _ m4 is Turing complete even when stripped to the bare minimum _ of one builtin: `define'. This is not news; Christopher Strachey _ demonstrated it in his ancestral GPM, described in "A general _ purpose macrogenerator", The Computer Journal 8 (1965) 225-241. _ _ This program illustrates the fact by implementing bit-by-bit _ binary arithmetic, systematically employing some unusual m4 _ idioms, used in largely functional style: _ _ 1. Case-switching via macro names constructed on the fly. _ 2. Representing data structures by nested parenthesized lists. _ 3. Using macros as named places to store data. _ _ A case switch (Idiom 1) _ _ An essential feature of programming is conditional execution. _ Suppose there are predicates that yield `T' or `F' for true _ or false. A conditional switch of the form _ _ if(,`', `') _ _ constructs calls for `if_T, or `if_F' that select the _ appropriate action: _ define(if,`if_$1(`$2',`$3')')_ define(if_T,`$1')_ define(if_F,`$2')_ _ _ Example _ _ if(T,`yes',`no') => if_T(`yes',`no') => yes _ if(F,`yes',`no') => if_F(`yes',`no') => no _ _ Basic Boolean functions are easy to define in terms of `if': _ define(not,`if($1,`F',`T')')_ define(and,`if($1,`$2',`F')')_ define(or,`if($1,`T',`$2')')_ define(xor,`if($1,`not($2)',`$2')')_ _ _ List representation (Idiom 2) _ _ In order to provide access to individual members, sequences _ of data values may be represented as right-associated lists. _ In particular, binary integers may be represented in this _ manner: _ _ (1,(0,(1,(1,())))) _ _ To facilitate arithmetic algorithms, the presentation _ is little-endian. In customary base-2 notation the _ example becomes 1101 (decimal 13). An empty list `()' acts _ as terminator. Non-significant 0's (leading zeros in _ customary notation) are not allowed; _ the value zero is represented by the empty list. _ _ Macros as named storage (Idiom 3) _ _ Example _ _ define(thirteen,`(1,(0,(1,(1,()))))')_ _ _ Individual list elements may be accessed by a pun, in which _ the outer parentheses of a list are taken to be the _ argument-list delimiters in a macro call. Two basic macros _ use this schem to extract "head" and "tail" parts, _ and , from a nonempty list: _ _ head((,)) ==> _ tail((,)) ==> _ define(head,`_head$1')_ define(_head,`$1')_ _ define(tail,`_tail$1')_ define(_tail,`$2')_ _ _ Example _ _ head(thirteen) ==> _head(1,(0,(1,(1,())))) => 1 _ tail(thirteen) ==> _tail(1,(0,(1,(1,())))) => (0,(1,(1,())) _ _ (In showing the progress of macro expansion => denotes a single _ step; ==> denotes multiple steps.) _ _ According to the rules of m4, `head' and `tail' also work on _ the empty list, `()',in which case either function yields an _ empty string, `'. This property of `head' will be exploited. _ _ A digit-equality test, `eqd', is useful in arithmetic. It _ switches on two arguments chosen from the set {`', `0', `1'} _ and yields `T' or `F' according as they are or are not equal. _ The "digit" `' arises from expressions such as `head(())'. _ The macro switches on its two arguments in the same way that _ `if' switches on one argument. _ define(eqd,`eqd_$1_$2()')_ define(eqd__,`T')_ define(eqd__0,`F')_ define(eqd__1,`F')_ _ define(eqd_0_,`F')_ define(eqd_0_0,`T')_ define(eqd_0_1,`F')_ _ define(eqd_1_,`F')_ define(eqd_1_0,`F')_ define(eqd_1_1,`T')_ _ _ Example _ _ eqd(1,0) => eqd_1_0() => F _ _ The () appended by `eqd' is defensive. If () were _ omitted, then would mistakenly be eaten in a _ rare juxtaposition like _ _ eqd(1,0)() => eqd_1_0() => F _ _ The easiest arithmetic function is the successor function. _ It can be programmed entirely in terms of functions _ already defined. (The name `Succ' is capitalized to _ distinguish it from a different implementation that _ will soon be described.) _ define(Succ,`if(eqd(head($1),`'),`(1,())','_ ``if(eqd(head($1),`0'),`(1,tail($1))',`(0,Succ(tail($1)))')')')_ _ _ (Right and left quotes before and after `_' bring it to top _ level to keep it out of the text of `Succ'.) _ _ `Succ' ultimately expands in one of three different ways, _ each presented in a different context: the first alternative _ of an `if', the first alternative of a nested `if', and the _ second alternative of an `if'. It would be notionally _ cleaner to use a 3-way switch. _ _ Unfortunately, overt switch code relies on Idiom 1, a glaring _ deviation from the mainstream functional style employed in _ `Succ'. Fortunately, a remedy is at hand: macros that hide _ the idiom. _ _ A general pattern for switching on the head of the operand of _ a unary operation, , is _ _ define(,`_(head($1))($1)')_ _ define<_,`_$1')_ _ _ The pattern is hidden once and for all in the macro _ `cases1()'. _ define(cases1,`_cases1(dol(1),`$1')')_ define(_cases1,`define($2,`_$2(head($1))($1)')_ define(_$2,`$2_$1')')_ define(dol,`$$1')_ _ _ The magic here is the "dollar macro" _ _ dol(1) => $1 _ _ which results in `$1' being substituted for `$1' [sic] throughout _ the replacement text of `_cases1', while is substituted for _ `$2'. When is `succ', the expansion proceeds thus: _ _ cases1(succ) => _cases1(dol(1),`succ') => _ define(succ,`_succ(head($1))($1)')define(_succ,`succ_$1') _ _ Code for individual cases of the successor function remains _ to be supplied. _ cases1(succ)_ define(succ_,`(1,())')_ define(succ_0,`(1,tail($1))')_ define(succ_1,`(0,succ(tail($1)))')_ _ _ Example _ _ succ((1,()) => _succ(1,())((1,())) => succ_1((1,())) => _ (0,succ(tail((1,())))) ==> (0,succ(()) ==> (0,(1,())) _ _ Some small constants may be defined for future use (Idiom 3). _ define(zero,())_ define(one,succ(zero))_ define(two,succ(one))_ _ _ Here is a pretty-print macro that converts binary numbers _ in list form to ordinary binary notation. _ define(base2,`if(eqd(head($1),`'),`0',`_base2($1)')')_ cases1(_base2) define(_base2_,`')_ define(_base2_0,`_base2(tail($1))0')_ define(_base2_1,`_base2(tail($1))1')_ _ _ Example, with `thirteen' as given in a previous example _ _ base2(zero) ==> 0 _ base2(thirteen) ==> 1101 _ _ A counter based on `succ' may be held in a macro whose content may _ be updated by a macro`incr' or read out simply by expanding it. _ define(incr,`define(`$1',succ($1))')_ _ _ Example _ _ define(mycounter,()) _ incr(`mycounter') _ incr(`mycounter') _ base2(mycounter) => 10 _ _ Binary operations may be defined by switching on two _ parameters. The switching code, generated by a macro _ `cases2', is very like that generated by `cases1' with _ two calls of the dollar macro instead of one. _ define(cases2,`_cases2(dol(1),dol(2),$1)')_ define(_cases2,`define($3,`_$3(head($1),head($2))($1,$2)')_ define(_$3,`$3_$1_$2')')_ _ _ Now comes addition of binary numbers _ cases2(add)_ define(add__,zero)_ define(add__0,`$2')_ define(add__1,`$2')_ define(add_0_,`$1')_ define(add_0_0,`(0,add(tail($1),tail($2))')_ define(add_0_1,`(1,add(tail($1),tail($2))')_ define(add_1_,`$1')_ define(add_1_0,`(1,add(tail($1),tail($2))')_ define(add_1_1,`(0,add(tail($1),succ(tail($2))))')_ _ _ Further arithmetic operations like multiplication, power, _ and comparisons can be programmed similarly, as can a _ a division operator that yields a (quotient,remainder) _ pair. _ _ Definitions of operations need not switch on all arguments. _ This boringly similar macro provides the switch for _ a function that switches on the second of two arguments: _ define(cases2of2,`_cases2of2(dol(1),dol(2),$1)')_ define(_cases2of2,`define($3,`_$3(head($2))($1,$2)')_ define(_$3,`$3_$1')')_ _ _ A higher-level switch-generator might take the form _ _ cases(,,) _ _ where is a list of parameter numbers to _ switch on, and is a list of all parameter numbers. _ Then cases2of2 would be definable without messing with _ the dollar macro: _ _ define(case2of2,`cases(,(2,()),(1,(2,())))') _ _ Other data types _ _ The basic list-processing operations, head and tail, are _ agnostic about the content of lists. Head values can _ come from any set, for example alphanumeric characters. _ In principle a string-equality operator declared _ by `cases2(eqs)' could be programmed to yield `T' or _ `F' for examples like _ _ eqs((W,(O,(R,(D,(1,()))))),(W,(O,(R,(D,(2,()))))) _ _ but it would require a daunting N^2 = 3969 case macros, _ where N counts uppercase, lowercase and numeric characters _ plus the empty character. Fortunately there is a trick _ that reduces the number of case macros to N = 63. _ _ For every character define a case macro `eqc_' to _ yield `F'. Here's a small sample: _ define(eqc_A,`F')_ define(eqc_B,`F')_ define(eqc_C,`F')_ define(eqc_D,`F')_ define(eqc_,`F')_ _ _ Then `eqc(,)' redefines `eqc_' to yield `T' and _ calls `eqc_'. The result is `T' only if and are _ the same. Finally `eqc' restores the definition of `eqc_'. _ The only subtlety in the definition of `eqc' is the empty _ quotes that keep the result of `eqc_$2' from being tacked _ onto `define': _ define(eqc,`define(`eqc_$1',`T')eqc_$2`'define(`eqc_$1',`F')')_ _ _ In terms of `eqc' string-comparison becomes _ define(eqs,`if(eqc(head($1),`'),`T',`if(eqc(head($1),head($2)),'_ ``eqs(tail($1),tail($2))',`F')')')_ _ _ One might hope to automate the writing of case definitions _ for `eqc' by iterating over a list like _ _ (A,(B,(C,(D,()))) _ _ The hope is apparently vain: to identify the end of the list _ one needs a case switch over the set of elements that may _ appear in the list--infinite regress. I know of no workaround _ much less laborious than writing out all the cases directly. _ _ Universality _ _ It's not hard to envision simulating a simple computer, except _ for interactive input-out--a deficiency that is shared with _ Turing machines. Thus, aside from resource limitations, bare _ m4 is Turing complete. _ _ The program counter is maintained by `incr', and converted _ to string form by `base2'. _ _ The th word of memory is a binary number held in a macro _ named W, where is expressed in string form. _. _ Operation codes are a limited set of binary numbers , and _ may be switched on by converting them to string form I. _ _ A branch operation redefines the location counter. _ _ An assignment redefines the designated word. _ _ Other operations are coded in styles illustrated above. _ _ Words need not be limited in size. Numbers may be kept _ in sign-magnitude form. _ _ Instructions may be of variable length--one word of opcode, _ and following words of addresses or immediate operands. _ _ A control macro fetches an opcode according to the location _ counter. If the opcode is a halt instruction, the control _ terminates. Otherwise it calls the designated operation, _ updates the instruction counter according to the opcode, _ and calls the control recursively. _ _ Advice for m4 _ _ Recursion of the control macro is unlimited and unavoidable. _ Ufortunately few, if any, m4 implementations implement tail _ calls so as not to grow the program stack. Doing so would _ help this and other deeply recursive applications. _ From dave at horsfall.org Sun Aug 23 06:19:31 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 23 Aug 2020 06:19:31 +1000 (EST) Subject: [TUHS] bare m4 (was BTL summmer employees) In-Reply-To: <202008220329.07M3ToZP041995@tahoe.cs.Dartmouth.EDU> References: <202008220329.07M3ToZP041995@tahoe.cs.Dartmouth.EDU> Message-ID: On Fri, 21 Aug 2020, Doug McIlroy wrote: >>> Can you give some examples of what this looked like? >> > > See attached for an answer to Arnold's question Boy am I gonna have to bone up on M4... Impressive! -- Dave From bakul at iitbombay.org Sun Aug 23 07:02:46 2020 From: bakul at iitbombay.org (Bakul Shah) Date: Sat, 22 Aug 2020 14:02:46 -0700 Subject: [TUHS] bare m4 (was BTL summmer employees) In-Reply-To: <202008220329.07M3ToZP041995@tahoe.cs.Dartmouth.EDU> References: <202008220329.07M3ToZP041995@tahoe.cs.Dartmouth.EDU> Message-ID: On Aug 21, 2020, at 8:29 PM, Doug McIlroy wrote: > > >>>> Even high-school employees could make lasting contributions. I am >>>> indebted to Steve for a technique he conceived during his first summer >>>> assignment: using macro definitions as if they were units of associative >>>> memory. This view of macros stimulated previously undreamed-of uses. >> >>> Can you give some examples of what this looked like? >> > > See attached for an answer to Arnold's question Reminds me of Church numerals & encoding. https://en.wikipedia.org/wiki/Church_encoding From tih at hamartun.priv.no Sun Aug 23 18:58:19 2020 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Sun, 23 Aug 2020 10:58:19 +0200 Subject: [TUHS] Monitoring by loudspeaker In-Reply-To: <20200712145822.GA72854@fuz.su> (Robert Clausecker's message of "Sun, 12 Jul 2020 16:58:22 +0200") References: <20200711203020.GA1884@minnie.tuhs.org> <202007120222.06C2MtdJ140032@tahoe.cs.Dartmouth.EDU> <738ab925-586b-4921-b891-a4ec20348d4c@localhost> <20200712145822.GA72854@fuz.su> Message-ID: Robert Clausecker writes: > When the computer is in a tight endless loop, the accumulator takes the > same series of values every time it's in the loop. Thus, instead of > white noise you get a sound whose frequency is the clock frequency of > the machine divided by the number of cycles spent by one loop iteration. A buddy and I did something somewhat related back in the early eighties, when we were teaching ourselves programming, using, among other things, his Tandy TRS-80 home computer. We discovered that a cheap "transistor radio", sitting close to the computer, would be affected by the noise generated by it, and then we figured out that if we didn't tune it to a radio station, we'd get only the noise. Leaving that on as we worked on a program, we got familiar with the sound of the code, and became able to follow the execution by the changing patterns -- and if it did get stuck in a loop somewhere, we'd not only hear it, but we would also have a pretty good idea where it happened. -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay From arnold at skeeve.com Sun Aug 23 22:59:15 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 23 Aug 2020 06:59:15 -0600 Subject: [TUHS] bare m4 (was BTL summmer employees) In-Reply-To: <202008220329.07M3ToZP041995@tahoe.cs.Dartmouth.EDU> References: <202008220329.07M3ToZP041995@tahoe.cs.Dartmouth.EDU> Message-ID: <202008231259.07NCxFxI018996@freefriends.org> Doug McIlroy wrote: > > > >> Even high-school employees could make lasting contributions. I am > > >> indebted to Steve for a technique he conceived during his first summer > > >> assignment: using macro definitions as if they were units of associative > > >> memory. This view of macros stimulated previously undreamed-of uses. > > > > > Can you give some examples of what this looked like? > > > > See attached for an answer to Arnold's question > > Doug Thanks!!! I will definitely review this. Do you object to my putting it on GitHub to preserve for Posterity? Thanks again, Arnold From crossd at gmail.com Tue Aug 25 01:58:46 2020 From: crossd at gmail.com (Dan Cross) Date: Mon, 24 Aug 2020 11:58:46 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: Message-ID: On Mon, Aug 17, 2020 at 4:16 PM Dibyendu Majumdar wrote: > On Mon, 17 Aug 2020 at 17:13, Dan Cross wrote: > > From my light skimming of V10 sources, it appears that the various > components of the default C compiler (that is, not LCC) either use > malloc/free or call `sbrk` directly. > > Yes, it only uses sbrk(). No, that's not true; or at least it's only partially true. Note that I'm talking specifically about 10th Edition here. The compiler is implemented as several cooperating processes, some of which employ different memory management strategies. Notice, for example, that `ccom` uses `malloc` but not `sbrk`, while `c2` does the opposite and uses `sbrk` but not `malloc`. On the other hand, `cpp` does no dynamic memory allocation and instead has fixed-size symbol tables for preprocessor definitions etc. Finally, the assembler uses `sbrk` but `ld` uses `malloc`. > One consequence I think is that sbrk() > expands the process memory without invalidating existing use of memory > - so the code is able to periodically expand heap while retaining all > existing allocations. > A simple workaround I used was to preallocate a heap and just stub out > sbrk() calls - so that works. So in essence given a single chunk of > memory (if large enough - which is still quite small by today's > standards) the compiler manages fine. > > However I find this unsatisfactory and would like to improve it. But > it is a bit difficult to understand how the memory is being used. > So in a nutshell, `sbrk` works by setting the "break" pointer: that is, the highest usable virtual address in the process's data segment. Stacks may be at the top of the user portion of the address space; but I'd have to double check the details. When the process starts up and gets going, one can discover the initial value of that pointer by executing `sbrk(0)`: since `sbrk` takes a delta and returns the old value of the break, the return value will be (basically) the current end of the data segment. By manipulating the break pointer via `sbrk`, one can cause the kernel to allocate memory to a process. That memory can then be managed internally (that is, within the process) via e.g. malloc _or_ a hand-rolled allocator (e.g., a "bump" allocator): when you want to put something in memory, you know where the next available pointer is (after the last one you allocated), you know how much space is available on the heap (since you allocated it using `sbrk`) and you presumably know how big the thing you want to store is; if the current pointer + alignment + size of next object is > break, you allocate more memory using `sbrk` and continue. There are a couple of approaches you can take to modernize this. The first you've already discovered: preallocate a heap that you manage with a stub `sbrk` and be done with it. Another might be to try and find some otherwise unallocated region of the address space and using `mmap()` to allocate successive pages to that portion of the address space to simulate `sbrk`; this may fail if you run into something that's already allocated in one of those regions. The most robust way might be the hardest, which is to replace the `sbrk`-based allocator with calls to e.g. `malloc`. However, looking a little more closely at 10th Ed's `c2`, for example`, this doesn't seem like it would be all that bad: `sbrk` is mostly wrapped by a function called `alloc` that takes an integer number of bytes to allocate and returns a `struct node *`; the return value is cast to whatever type is needed though. The use of `struct node *` as the return value is almost certainly because the compiler was written before `void *` had achieved primacy in the ANSI C world. Anyway, I suspect if you simply replaced the guts of `alloc` with `return malloc(an);` you'd get approximately what you want. Memory can be used for declarations, trees (for expressions) and > strings as far as I can tell. Strings actually use the tree > allocation, and just pretend that a node is a string. > Not exactly. The return type of `alloc` is `struct node *`, but that's just a detail; in the dialect of C that e.g. 10th Ed's PCC is written in, the return type doesn't matter: it's just a pointer. You can cast it to `char *` and copy string data there if you want to. I don't know why `struct node *` was chosen for `alloc`, but I suspect simply convenience. It seems that tree memory is allocated in a stack discipline. But what > puzzled me is that when a tree starts, about 512 bytes of memory are > left as gap for declarations to use. I have been trying to think in > what circumstances would you encounter a declaration while parsing an > expression - perhaps cast expressions? Anyway - if a declaration > occurs inside an expression (i.e. tree) then it only has 512 bytes > available. Of course this could be made bigger ... but at the least I > would like to have separate heaps for declarations, trees and strings. > This sounds like it's something independent of the allocator and more about the program's strategy around allocation in general. It's a common trick in C programs to e.g., allocate the space for some structs plus things that may be pointed to by those structs in a single allocation; not only does this cut down on overhead with respect to calling into the allocator, it also gives you locality. I don't think you want separate _heaps_ for the things you mention, though you may want to allocate them separately using independent calls to e.g. `malloc`. That's fine. I guess no one really dug into this code - as presumably once PCC came > along the original compiler by Dennis stopped being used. > 10th Edition `cc` _is_ `pcc`. I haven't looked at the 7th Ed compiler in detail. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Tue Aug 25 03:08:31 2020 From: cowan at ccil.org (John Cowan) Date: Mon, 24 Aug 2020 13:08:31 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: Message-ID: On Mon, Aug 24, 2020 at 12:00 PM Dan Cross wrote: > Stacks may be at the top of the user portion of the address space; but I'd > have to double check the details. > That's always true on the PDP-11 and Vax, no matter what the OS, because the processor architecture (which has pre-increment and post-decrement instructions, but not their counterparts) makes anything but a downward-growing stack unmanageable. In OSes without virtual memory like RSX-11[ABC], RT-11, and mini-Unix/LSX-11, what counts as the top naturally varies. Dennis's compiler AFAIK was never extended to anything but the PDP-11, both as host and target. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Aug 25 03:15:38 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 24 Aug 2020 13:15:38 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: Message-ID: On Mon, Aug 24, 2020 at 1:09 PM John Cowan wrote: > Dennis's compiler AFAIK was never extended to anything but the PDP-11, > both as host and target. > FWIW: I'm pretty sure that the Teletype Z80 compiler and I know my hacked 68K compiler, used Dennis's V6+ compiler, not PCC as the base. I think a couple of the microprocessor compilers that the Purdie folks created did also. That said, the MIT RST folks suite for the Nu Machines used PCC and those became the 'standard' which many of the 'JAWS' ports started. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Aug 25 03:20:43 2020 From: crossd at gmail.com (Dan Cross) Date: Mon, 24 Aug 2020 13:20:43 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: Message-ID: On Mon, Aug 24, 2020 at 1:08 PM John Cowan wrote: > On Mon, Aug 24, 2020 at 12:00 PM Dan Cross wrote: > >> Stacks may be at the top of the user portion of the address space; but >> I'd have to double check the details. >> > > That's always true on the PDP-11 and Vax, no matter what the OS, because > the processor architecture (which has pre-increment and post-decrement > instructions, but not their counterparts) makes anything but a > downward-growing stack unmanageable. > Ah, but if one has a fixed-size stack that cannot be extended, one can put it anywhere one wants in the virtual address space. E.g., right after the program text segment or whatever (effectively using the text as a guard to detect stack overflow). I don't know why one would want to do that, except that it makes freeing the virtual address space slightly simpler when the process exits, but the point is that the Unix choice isn't the only way. That said, stacks and data growing toward each gives the maximum amount of flexibility. In OSes without virtual memory like RSX-11[ABC], RT-11, and > mini-Unix/LSX-11, what counts as the top naturally varies. > > Dennis's compiler AFAIK was never extended to anything but the PDP-11, > both as host and target. > That's my impression, as well. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Aug 25 03:24:16 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 24 Aug 2020 13:24:16 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: Message-ID: s/Purdie/Purdue/ s/RST/RTS/ sigh... On Mon, Aug 24, 2020 at 1:15 PM Clem Cole wrote: > > > On Mon, Aug 24, 2020 at 1:09 PM John Cowan wrote: > >> Dennis's compiler AFAIK was never extended to anything but the PDP-11, >> both as host and target. >> > FWIW: I'm pretty sure that the Teletype Z80 compiler and I know my hacked > 68K compiler, used Dennis's V6+ compiler, not PCC as the base. I think a > couple of the microprocessor compilers that the Purdie folks created did > also. That said, the MIT RST folks suite for the Nu Machines used PCC and > those became the 'standard' which many of the 'JAWS' ports started. > > Clem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at quintile.net Tue Aug 25 19:36:44 2020 From: steve at quintile.net (Steve Simon) Date: Tue, 25 Aug 2020 10:36:44 +0100 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler Message-ID: <055AE92B-2CDE-4EB1-BBEE-9A78898E7931@quintile.net> I am fairly sure the interdata port from Wollongong used the v6 c compiler, and this lived on in the “official” v7 port from perkin elmer, it still used the v6 compiler. i remember the pain of the global namespace for structure members. -Steve From krewat at kilonet.net Wed Aug 26 09:06:04 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Tue, 25 Aug 2020 19:06:04 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: Message-ID: <950cbd43-9ddb-e723-943d-9fb7ce3f746e@kilonet.net> On 8/24/2020 1:20 PM, Dan Cross wrote: > On Mon, Aug 24, 2020 at 1:08 PM John Cowan > wrote: > > On Mon, Aug 24, 2020 at 12:00 PM Dan Cross > wrote: > > Stacks may be at the top of the user portion of the address > space; but I'd have to double check the details. > > > That's always true on the PDP-11 and Vax, no matter what the OS, > because the processor architecture (which has pre-increment and > post-decrement instructions, but not their counterparts) makes > anything but a downward-growing stack unmanageable. > > > Ah, but if one has a fixed-size stack that cannot be extended, one can > put it anywhere one wants in the virtual address space. E.g., right > after the program text segment or whatever (effectively using the text > as a guard to detect stack overflow). I don't know why one would want > to do that, except that it makes freeing the virtual address space > slightly simpler when the process exits, but the point is that the > Unix choice isn't the only way. That said, stacks and data growing > toward each gives the maximum amount of flexibility. > > In OSes without virtual memory like RSX-11[ABC], RT-11, and > mini-Unix/LSX-11, what counts as the top naturally varies. > > On TOPS-10, I got into the habit of putting the PDL at the end of the lowseg. If it ran over, it would die. ak -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Wed Aug 26 23:24:59 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 26 Aug 2020 09:24:59 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler Message-ID: <202008261324.07QDOxln046419@tahoe.cs.Dartmouth.EDU> > That's always true on the PDP-11 and Vax, no matter what the OS, > because the processor architecture (which has pre-increment and > post-decrement instructions, but not their counterparts) makes > anything but a downward-growing stack unmanageable. I hadn't heard this urban legend before. A stack is certainly manageable without auto-increment/decrement (AID) instructions. In fact Dennis's compiler did not use AID instructions for that purpose. AID instructions are nice for a LIFO stack, in which a stacked item disappears as soon as it's used--as do intermediate results in expression evaluation. But when the stack contains local variables that are accessed multiple times, the accesses are offset from the stack pointer. If AID instructions set the pointer, then the offset of a particular local varies throughout the code. The compiler can cope with that (I once wrote a compiler that did so), but a debugger will have a devil of a time doing a backtrace when the offset of the return address in each stack frame depends on the location counter. AID instructions are fine for sequentially accessing arrays, and in principle Ken's ++ and -- operators can exploit them. Yet idiomatic C typically wants post-increment and pre-decrement instructions--the opposite of what DEC offered. Examples: char a[N], b[N]; char *ap = a; char *bp = b; int i; for(i=0; i= 0) a[i] = b[i]; Doug From cowan at ccil.org Thu Aug 27 01:41:21 2020 From: cowan at ccil.org (John Cowan) Date: Wed, 26 Aug 2020 11:41:21 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: <202008261324.07QDOxln046419@tahoe.cs.Dartmouth.EDU> References: <202008261324.07QDOxln046419@tahoe.cs.Dartmouth.EDU> Message-ID: On Wed, Aug 26, 2020 at 9:25 AM Doug McIlroy wrote: I hadn't heard this urban legend before. A stack is certainly > manageable without auto-increment/decrement (AID) instructions. Absolutely. I should have qualified my remarks by saying "when writing in assembly language", which was the universal language of all PDP-11 operating systems until Unix. VMS adopted Bliss (which is what C would be like if it had come to us through a different dharma line[*]) as its principal implementation language. > But when the stack contains > local variables that are accessed multiple times, the accesses > are offset from the stack pointer. Or the frame pointer, which has the advantage that the callee can push arbitrary stuff on the stack without having to explicitly account for it later, and the disadvantage that it ties up yet another register when they are in short supply. [*] Don't laugh too hard: you yourself have already been mythologized in precisely this fashion. See < http://www.catb.org/~esr/writings/unix-koans/two_paths.html> and < http://www.catb.org/~esr/writings/unix-koans/zealot.html>. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Mark Twain on Cecil Rhodes: I admire him, I freely admit it, and when his time comes I shall buy a piece of the rope for a keepsake. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Thu Aug 27 01:59:08 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 26 Aug 2020 11:59:08 -0400 (EDT) Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler Message-ID: <20200826155908.674C418C0CD@mercury.lcs.mit.edu> > From: John Cowan > That's always true on the PDP-11 and Vax ... because the processor > architecture (which has pre-increment and post-decrement instructions, > but not their counterparts) After Doug's message, I carefull re-read this, and I'm not sure it's correct? The PDP-11 has pre-decrement and post-increment, not the other way around (as above) - unless I'm misunderstanding what you meant by those terms? That's why: *p++ = 0; turns (if p is in R2) into CLR (R2)+ R2 is used, and then incremented after it has been used. Noel From imp at bsdimp.com Thu Aug 27 02:09:06 2020 From: imp at bsdimp.com (Warner Losh) Date: Wed, 26 Aug 2020 10:09:06 -0600 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: <20200826155908.674C418C0CD@mercury.lcs.mit.edu> References: <20200826155908.674C418C0CD@mercury.lcs.mit.edu> Message-ID: On Wed, Aug 26, 2020 at 9:59 AM Noel Chiappa wrote: > > From: John Cowan > > > That's always true on the PDP-11 and Vax ... because the processor > > architecture (which has pre-increment and post-decrement > instructions, > > but not their counterparts) > > After Doug's message, I carefull re-read this, and I'm not sure it's > correct? > The PDP-11 has pre-decrement and post-increment, not the other way around > (as > above) - unless I'm misunderstanding what you meant by those terms? > > That's why: > > *p++ = 0; > > turns (if p is in R2) into > > CLR (R2)+ > > R2 is used, and then incremented after it has been used. > This quirk of the PDP-11 is why I still prefer post-increment and pre-decrement in my code... even though there's no chance in hades that my code will ever run there... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From velocityboy at gmail.com Thu Aug 27 02:14:29 2020 From: velocityboy at gmail.com (Jim Geist) Date: Wed, 26 Aug 2020 12:14:29 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: <20200826155908.674C418C0CD@mercury.lcs.mit.edu> References: <20200826155908.674C418C0CD@mercury.lcs.mit.edu> Message-ID: You're right. Modes 2 and 3 are post-increment and post-increment deferred. 4 and 5 are pre-decrement and pre-decrement deferred. On Wed, Aug 26, 2020 at 12:00 PM Noel Chiappa wrote: > > From: John Cowan > > > That's always true on the PDP-11 and Vax ... because the processor > > architecture (which has pre-increment and post-decrement > instructions, > > but not their counterparts) > > After Doug's message, I carefull re-read this, and I'm not sure it's > correct? > The PDP-11 has pre-decrement and post-increment, not the other way around > (as > above) - unless I'm misunderstanding what you meant by those terms? > > That's why: > > *p++ = 0; > > turns (if p is in R2) into > > CLR (R2)+ > > R2 is used, and then incremented after it has been used. > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Thu Aug 27 03:31:58 2020 From: cowan at ccil.org (John Cowan) Date: Wed, 26 Aug 2020 13:31:58 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: <20200826155908.674C418C0CD@mercury.lcs.mit.edu> References: <20200826155908.674C418C0CD@mercury.lcs.mit.edu> Message-ID: On Wed, Aug 26, 2020 at 11:59 AM Noel Chiappa wrote: After Doug's message, I carefull re-read this, and I'm not sure it's > correct? > The PDP-11 has pre-decrement and post-increment, not the other way around > (as > above) - unless I'm misunderstanding what you meant by those terms? > Thank you! Post in haste, repent at leisure; but if I don't post in haste these days, I won't be able to post at all.... John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Almost all theorems are true, but almost all proofs have bugs. --Paul Pedersen -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Aug 27 05:13:04 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 26 Aug 2020 15:13:04 -0400 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler In-Reply-To: References: <20200826155908.674C418C0CD@mercury.lcs.mit.edu> Message-ID: On Wed, Aug 26, 2020 at 12:09 PM Warner Losh wrote: > This quirk of the PDP-11 is why I still prefer post-increment and > pre-decrement in my code... even though there's no chance in hades that my > code will ever run there... > Amen bro ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Aug 27 05:27:35 2020 From: imp at bsdimp.com (Warner Losh) Date: Wed, 26 Aug 2020 13:27:35 -0600 Subject: [TUHS] Quick video: what's the oldest BSD distro Message-ID: https://www.youtube.com/watch?v=ww60o940kEk You may be surprised :) Warner P.S. Hope this is relevant enough to share here. Also, if I botched anything I've not yet mentioned in the comments, please let me know... -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Thu Aug 27 06:17:33 2020 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 27 Aug 2020 06:17:33 +1000 Subject: [TUHS] Quick video: what's the oldest BSD distro In-Reply-To: References: Message-ID: <20200826201733.GA8476@minnie.tuhs.org> On Wed, Aug 26, 2020 at 01:27:35PM -0600, Warner Losh wrote: > [1]https://www.youtube.com/watch?v=ww60o940kEk > You may be surprised :) > Warner > P.S. Hope this is relevant enough to share here. Also, if I botched > anything I've not yet mentioned in the comments, please let me know... Really good Warner. Given that RetroBSD is based on 2.11BSD, you could even say that 2.11BSD is still in use on current hardware. Cheers, Warren From crossd at gmail.com Thu Aug 27 07:24:12 2020 From: crossd at gmail.com (Dan Cross) Date: Wed, 26 Aug 2020 17:24:12 -0400 Subject: [TUHS] Unix tools to aid in the production of Internet RFCs? Message-ID: Honestly, I'm not quite sure if this is a TUHS, COFF, or IH question. But since my background with respect to such things is largely Unix centric, I thought I'd ask in that context, hence asking on TUHS. I assume some of the regulars on this list have authored RFCs (of the IETF etc variety). The RFC format seems fairly well fixed: table of contents, fixed number of lines per page, page numbers and dates in the footer, and so forth. The format is sufficiently complex that it seems like some tooling could be usefully employed to aid in producing these documents. So I'm curious: what tools did people use to produce those documents? Perhaps `nroff` with custom macros or something? - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Thu Aug 27 07:30:26 2020 From: bakul at iitbombay.org (Bakul Shah) Date: Wed, 26 Aug 2020 14:30:26 -0700 Subject: [TUHS] Unix tools to aid in the production of Internet RFCs? In-Reply-To: References: Message-ID: On Aug 26, 2020, at 2:24 PM, Dan Cross wrote: > > Honestly, I'm not quite sure if this is a TUHS, COFF, or IH question. But since my background with respect to such things is largely Unix centric, I thought I'd ask in that context, hence asking on TUHS. > > I assume some of the regulars on this list have authored RFCs (of the IETF etc variety). The RFC format seems fairly well fixed: table of contents, fixed number of lines per page, page numbers and dates in the footer, and so forth. The format is sufficiently complex that it seems like some tooling could be usefully employed to aid in producing these documents. > > So I'm curious: what tools did people use to produce those documents? Perhaps `nroff` with custom macros or something? https://www.rfc-editor.org/pubprocess/tools/ From clemc at ccc.com Thu Aug 27 08:02:08 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 26 Aug 2020 18:02:08 -0400 Subject: [TUHS] Unix tools to aid in the production of Internet RFCs? In-Reply-To: References: Message-ID: On Wed, Aug 26, 2020 at 5:25 PM Dan Cross wrote: > So I'm curious: what tools did people use to produce those documents? > What was available at the time? Some of the first were done with a typewriter ;-). That said, a lot of the early ones (1960-thru late 70s) were done using one of the different flavors of the runoff schemes, with the PDP-10 family being pretty popular since many of the Arpa supplied systems were based on PDP6/10s. The output, as you see, was formatted ASCII printer listings. Once Unix hit the scene, particularly with Vaxen, nroff took the lead, but since other than CMU/Stanford/MIT, XGPs (or later Dovers) were rare. Using a plotter (*a.k.a. *vcat and family) troff starts to take off it some places beyond folks with an XGP (like UCB). By the time of the many different JAWS, and the Apple Laserwriter and eventually different HP printers, the nroff/troff family was very much the norm, with some Tex/LaTex at some point. MS-Word does not start to show up until about 15-20 years into the process. As you noted, Bakul has a pointer to the current set of tools; but you asked in the past tense; so I'm assuming you mean, how did the first 1-2K or so get created. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Thu Aug 27 18:37:58 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 27 Aug 2020 10:37:58 +0200 Subject: [TUHS] Memory management in Dennis Ritchie's C Compiler Message-ID: <91C9F0D7-181D-4677-AFCD-155D45858788@planet.nl> Doug, “In fact Dennis's compiler did not use AID instructions for that purpose.” Whilst local variables are indeed accessed as an offset from the base pointer, I’m not sure that the above statement is correct. In the V6 compiler (-sp) was certainly used to push arguments to the stack, and when the register allocation overflowed, the interim results were pushed to the stack as well with (-sp). See c10.c, the case CALL in rcexpr(), the function comarg() and sptab (which is right at the end of table.s) Links: https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/c/c10.c https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/c/table.s For interim result pushing/popping I refer to the FS and SS macro’s. Dennis discusses these in his “A tour of the C compiler” paper. https://www.jslite.net/cgi-bin/9995/doc/tip/doc/old-ctour.pdf Of course this is all implementational detail, not a core design aspect - as Richard Miller showed in his port to the Interdata architecture (including a port of the Ritchie C compiler). Maybe the sentence should have read: "In fact Dennis's compiler did not rely on having AID instructions for that purpose." Paul @Warren: at moments like these I really like having the line highlight feature that we discussed before Summer. From dot at dotat.at Fri Aug 28 04:06:24 2020 From: dot at dotat.at (Tony Finch) Date: Thu, 27 Aug 2020 19:06:24 +0100 Subject: [TUHS] early BIND Message-ID: Another question at the intersection of the Internet-History and TUHS lists... I was wondering about the early history of BIND. I started off wondering about the relative ages of JEEVES (the original PDP10 DNS server) and BIND. Judging by the dates on RFCs 881 - 883, the DARPA contract commissioning BIND, and the Berkeley tech reports, it seems there wasn't much time when the DNS was without BIND. But I was struck by the resolver API set out on page 8 of Berkeley tech report UCB/CSD-84-182: it looks nothing like the familiar API that ended up in 4.3BSD. https://www2.eecs.berkeley.edu/Pubs/TechRpts/1984/5957.html https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD/usr/src/lib/libc/net/named/gethostnamadr.c So I'm wondering if there's anything out there recording the history between the 1984 tech reports and the 4.3BSD release in 1986. (It's also noteworthy that early BIND supported incremental DNS updates and zone transfers, which didn't reappear in standard form until RFC 2136 (1997) and RFC 1995 (1996)...) Tony. -- f.anthony.n.finch http://dotat.at/ public services of the highest quality From dot at dotat.at Fri Aug 28 03:42:36 2020 From: dot at dotat.at (Tony Finch) Date: Thu, 27 Aug 2020 18:42:36 +0100 Subject: [TUHS] Quick video: what's the oldest BSD distro In-Reply-To: References: Message-ID: Warner Losh wrote: > https://www.youtube.com/watch?v=ww60o940kEk A small query: I think you dated Mac OS X to 2000, which I guess refers to the Public Beta [1] but there was a Mac OS X Server 1.0 release in 1999 [2] and developer preview releases in 1997 and 1998 when it was known by its codename Rhapsody (apparently Mac OS X Server 1.0 still called itself Rhapsody [3]). Rhapsody was clearly an intermediate stage between NEXTSTEP/OPENSTEP and Mac OS X, so I suppose it's too different to count as a continuation, following your argument that 2.11BSD is too different to 2.9/2.10BSD to count as a continuation... [1] https://en.wikipedia.org/wiki/Mac_OS_X_Public_Beta [2] https://en.wikipedia.org/wiki/Mac_OS_X_Server_1.0 [3] http://rhapsodyos.org/ Tony. -- f.anthony.n.finch http://dotat.at/ Bailey, Fair Isle, Faeroes: Variable mainly northerly 3 to 5, occasionally 6 in south Bailey and east Fair Isle. Slight or moderate, becoming rough later in southeast Fair Isle. Showers. Good. From dot at dotat.at Fri Aug 28 03:51:08 2020 From: dot at dotat.at (Tony Finch) Date: Thu, 27 Aug 2020 18:51:08 +0100 Subject: [TUHS] Unix tools to aid in the production of Internet RFCs? In-Reply-To: References: Message-ID: Clem Cole wrote: > On Wed, Aug 26, 2020 at 5:25 PM Dan Cross wrote: > > > So I'm curious: what tools did people use to produce those documents? > > What was available at the time? Some of the first were done with a > typewriter ;-). That said, a lot of the early ones (1960-thru late 70s) > were done using one of the different flavors of the runoff schemes, with > the PDP-10 family being pretty popular since many of the Arpa supplied > systems were based on PDP6/10s. Yes, very Not Unix. As Dan wondered, the best list for this question is internet-history, I think :-) The Network Information Center was at SRI, and they used the ARC NLS: Doug Englebart's Augmentation Research Center oN-Line System [1] but I get the impression that by the 1990s nroff on Unix was the main tool for producing RFCs. https://archive.computerhistory.org/resources/access/text/finding-aids/102706170-SRI/102706170-SRI.pdf Tony. -- f.anthony.n.finch http://dotat.at/ Wight, Portland, Plymouth: West or southwest 5 to 7, occasionally gale 8 at first in Wight and Portland, veering northwest 4 to 6 later. Moderate or rough. Thundery showers. Good, occasionally poor. From clemc at ccc.com Fri Aug 28 04:32:15 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 27 Aug 2020 14:32:15 -0400 Subject: [TUHS] Unix tools to aid in the production of Internet RFCs? In-Reply-To: References: Message-ID: On Thu, Aug 27, 2020 at 1:51 PM Tony Finch wrote: > Yes, very Not Unix. As Dan wondered, the best list for this question is internet-history, > I think :-) > Maybe - certainly true for the first 1K (more in a minute...) > > The Network Information Center was at SRI, and they used the ARC NLS: Doug > Englebart's Augmentation Research Center oN-Line System [1] SRI just published them, my experience/memory from the time, was the authors wrote them locally, which as I said was more often than not, PDP6/10 in the 70s. Certainly was true at CMU, Stanford, and MIT. The problem was we all had XGPs (later Dovers) and original the Stanford PUB system (folks with PDP-10s seemed to have tended to switch to Scribe after it became available) but those without a custom output device, many other folks did not. PUB really wanted an XGP, not a line printer and the runoff family pretty much assumed an ASCII printer page. Scribe could handle either, as well as the newly emerging 'daisy wheel' printers. Actually, typesetters like the C/A/T or the APS-5 were not as popular in CS departments (probably because the cost per page, the nuisance of the chemistry *et al*. Although a lot of places that had a 'publications' team (DEC, BBN, *etc*) had them. Lasers printers (particularly PS based ones) were really another 3-5 years away, first Apple, then Imagen, and finally, HP licensed PS. So the RFC/IENs et al would have followed the preferred/economic technology of the time. > but I get the impression that by the 1990s nroff on Unix was the main > tool for producing RFCs. > Certainly true, but I would think that the transition was at least 5 years earlier, maybe 7-8 given the rise of the Vaxen, and using tools like vcat(1) like we used at UCB (and I had done previous to that at Tektronix). But that was really the important thing for the IEN/RFCs. When the 10's stopped being the backbone of the Arpanet (now Internet) and UNIX took the helm, the troff family started to be the primary tool. To be fair, the Pascal version of Tex appeared in the early 1980s, but it was not until the Latex (Scribe style Tex macros) and the UNIX/C support that it really began to take off. There were a number of reasons for this, but maybe because Pascal was a second class citizen to C may have hindered its acceptance. I can not say. I have friends that swear by it and have cursed troff forever, and others like me, that tend the other way (emacs *vs.* vi I think). It's funny, I learned runoff, PUB, Scribe, troff, or sort of tex in that order. I have a soft spot for Scribe, but I used it for such a short time, and troff became my primary tool. Like Larry, I still prefer troff (groff) today to the tex family as I have fewer problems doing complex stuff with it; but that may be the familiarity with it being the best tool available to me for so long. I suspect, the RFC publishers could be a similar story. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Aug 28 10:17:10 2020 From: imp at bsdimp.com (Warner Losh) Date: Thu, 27 Aug 2020 18:17:10 -0600 Subject: [TUHS] Quick video: what's the oldest BSD distro In-Reply-To: References: Message-ID: On Thu, Aug 27, 2020 at 11:42 AM Tony Finch wrote: > Warner Losh wrote: > > > https://www.youtube.com/watch?v=ww60o940kEk > > A small query: I think you dated Mac OS X to 2000, which I guess refers to > the Public Beta [1] but there was a Mac OS X Server 1.0 release in 1999 > [2] and developer preview releases in 1997 and 1998 when it was known by > its codename Rhapsody (apparently Mac OS X Server 1.0 still called itself > Rhapsody [3]). Rhapsody was clearly an intermediate stage between > NEXTSTEP/OPENSTEP and Mac OS X, so I suppose it's too different to count > as a continuation, following your argument that 2.11BSD is too different > to 2.9/2.10BSD to count as a continuation... > Yea, that's what I thought. Either one could say that 2.9BSD was continued to 2.10 and 2.11 by Seismo and related folks (which puts its release back to 1983 or 1985 depending on how you count things) and also the NextStep / OpenStep -> Rhapsody -> MacOS would count which puts it 1989 as the first release. There was at least some level of discontinuity in each of the transitions (BSD -> Seismo and NextStep -> MacOS) so I excluded them both... In some ways there's a continuity between CSRG and FreeBSD (Kirk and others) and NetBSD (others) as well, so how do you count that? If you zoom in too much, it becomes hard to make an unambiguous break because the code pased from hand to hand so much with overlapping groups of people... Warner > [1] https://en.wikipedia.org/wiki/Mac_OS_X_Public_Beta > [2] https://en.wikipedia.org/wiki/Mac_OS_X_Server_1.0 > [3] http://rhapsodyos.org/ > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Bailey, Fair Isle, Faeroes: Variable mainly northerly 3 to 5, occasionally > 6 > in south Bailey and east Fair Isle. Slight or moderate, becoming rough > later > in southeast Fair Isle. Showers. Good. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Sat Aug 29 01:52:16 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Fri, 28 Aug 2020 11:52:16 -0400 Subject: [TUHS] bare m4 (was BTL summmer employees) Message-ID: <202008281552.07SFqGsM042808@tahoe.cs.Dartmouth.EDU> A modestly corrected and improved version of my bare-m4 program, which quickly builds from nothing to arithmetic on binary numbers using no builtins other than `define'. is posted at www.cs.dartmouth.edu/~doug/barem4.txt. (.txt because browsers balk at .m4) Doug From thomas.paulsen at firemail.de Sat Aug 29 02:41:34 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Fri, 28 Aug 2020 18:41:34 +0200 Subject: [TUHS] bare m4 (was BTL summmer employees) In-Reply-To: <202008281552.07SFqGsM042808@tahoe.cs.Dartmouth.EDU> References: <202008281552.07SFqGsM042808@tahoe.cs.Dartmouth.EDU> Message-ID: <67834aec6da4ba7f6d51694ff4f48dc3@firemail.de> thanks a lot, Doug! >A modestly corrected and improved version of my bare-m4 >program, which quickly builds from nothing to arithmetic on >binary numbers using no builtins other than `define'. is >posted at www.cs.dartmouth.edu/~doug/barem4.txt. (.txt >because browsers balk at .m4) From clemc at ccc.com Sat Aug 29 06:37:44 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 28 Aug 2020 16:37:44 -0400 Subject: [TUHS] Quick video: what's the oldest BSD distro In-Reply-To: References: Message-ID: On Thu, Aug 27, 2020 at 8:18 PM Warner Losh wrote: > If you zoom in too much, it becomes hard to make an unambiguous break > because the code pased from hand to hand so much with overlapping groups of > people... > And that's the real issue with any of these. At one point does one stop and another start. The people were pretty free and we all moved around. I do tend to think of FreeBSD and NetBSD and the follow on too much of CSRG and frankly, while they are different, they were more similar than different (FreeBSD focused on x86 originally and NetBSD was a little less polished in those days but worked on more HW). At some point, you are picking nits and it really becomes more opinion/what you value than anything else. I also think some of BSD (people & IP) leached into Research and vice versa. -------------- next part -------------- An HTML attachment was scrubbed... URL: