From paul.winalski at gmail.com Tue Feb 1 03:16:09 2022 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 31 Jan 2022 12:16:09 -0500 Subject: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> <9E47A62E-3AAD-491E-9164-3DCAD22EC1F7@kdbarto.org> <71ce6652-cf15-44db-01df-62ab89a5a134@gmail.com> Message-ID: On 1/30/22, Steve Nickolas wrote: > > And I think I've heard the Infocom compilers' bytecode called "Z-code" (I > use this term too). > That is correct. The Infocom games ran on an interpreter for an abstract machine called the Z-machine. Z-code is the Z-machine's instruction set. There is a freeware implementation out there called Frotz. -Paul W. "Plugh" (said in a hollow voice) From fair-tuhs at netbsd.org Tue Feb 1 06:00:40 2022 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Mon, 31 Jan 2022 12:00:40 -0800 Subject: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: References: Message-ID: <499.1643659240@cesium.clock.org> The definitions and boundaries between: Instruction Set Architecture (usually hardware, but see Webasm) P-code/bytecode interpreter internal instructions (e.g. Pascal, Java) Register Transfer Languages (RTL - compilers) seem awfully ... fuzzy. Are there any hard & fast rules for classifying particular implementations into taxnomical categories? Wikipedia has an over-arching definition for "intermediate representation" ... https://en.wikipedia.org/wiki/Intermediate_representation This is related to Unix in that Unix itself (both kernel system call API & C library) is an abstracting intermediary between the hardware (whole computer system including storage, networking), and application software, which "if written portably" doesn't have to care what hardware it's run on, so long as that hardware meets some minimum requirements for both Unix, and whatever the application's needs are. Erik From noel.hunt at gmail.com Tue Feb 1 06:22:52 2022 From: noel.hunt at gmail.com (Noel Hunt) Date: Tue, 1 Feb 2022 07:22:52 +1100 Subject: [TUHS] Ratfor s In-Reply-To: <202201310713.20V7Dxxf023410@freefriends.org> References: <87492671-3406-49DF-B458-5F701DDFC09B@gmail.com> <202201301609.20UG9CpQ023310@freefriends.org> <555F6961-A97C-4CCE-9AE9-20A49525AEAF@gmail.com> <202201310713.20V7Dxxf023410@freefriends.org> Message-ID: The splitting you talk about came about because of the Blit, one part of a program running on the host, the 'graphical' part on the terminal, i.e., the Blit; the two parts communicated with a simple protocol, an example of which you can see in 'sam'. 'Cip', 'proof', 'jim', 'sam' and 'pi' (really, 'pads'), followed this model. It wasn't necessary I think with all programs, and I'm sure 'icon', the bitmap editor, didn't. If you look in the various Blit/Jerq source directories in the distributions you will see programs with a 'host' and 'term' subdirectory. On Mon, Jan 31, 2022 at 6:18 PM wrote: > Thanks for the link. I skimmed it and will read it later. > > What struck me was the splitting of the editor into front and back ends > that did not have to be on the same machine. Rob Pike used that design > for "sam" somewhat later. I wonder if he got the idea from 's' or came > up with it on his own... (Dough, thoughts?) > > Thanks, > > Arnold > > Will Senn wrote: > > > Hi Arnold, > > > > It was mentioned in the STinP edit discussion, so of course, I had to go > looking! Here's the referenced article by Fraser: > > > > https://archive.org/details/compact-portable-crt > > > > Will > > Sent from my iPhone > > > > > On Jan 30, 2022, at 10:09 AM, arnold at skeeve.com wrote: > > > > > > Will Senn wrote: > > > > > >> Has anyone seen Fraser's original ratfor source for the s editor for > unix on the PDP-11. It was a screen editor front-end built on top of > Software Tools's edit. I've seen a c version, but I'm interested in the 375 > line version :). > > >> > > >> Will > > >> > > >> Sent from my iPhone > > > > > > I've never heard of this. Can you give some background please? > > > > > > Thanks, > > > > > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Tue Feb 1 06:46:23 2022 From: will.senn at gmail.com (Will Senn) Date: Mon, 31 Jan 2022 14:46:23 -0600 Subject: [TUHS] ratfor vibe Message-ID: All, I have been doing some language exploration in v7/4.3bsd and came across Software Tools (not the pascal version). It's written using ratfor, which I had seen in the v7 UPM. I fired up v7 and tried my hand at the first example: # copy - copy input characters to output         integer getc         integer c         while(getc(c) != EOF)                 call putc(c)         stop         end The first thing I noticed was that it read more like C than Fortran (I know C quite well, Fortran just a smidge)... awesome, right? So I ran the preprocessor on it and got the following f77 code: c copy - copy input characters to output       integer getc       integer c c     while 23000 if(.not.(getc(c) .ne. eof))goto 23001          call putc(c)          goto 23000 c     endwhile 23001 continue       stop       end Cool. The way it translated the EOF test is weird, but ok. Trying to compile it results in complaints about missing getc and putc: $ f77 copy.f copy.f:    MAIN: Undefined: _getc_ _putc_ _end Ah well, no worries. I know that they're in the c lib, but don't about fortran libs... Meanwhile, over on 4.3BSD, it compiles without issue. But running it is no joy: $ ./a.out This is a test $ I remembered that the authors mentioned something about EOF, so I tweaked the code (changed EOF to -1) and rebuilt/reran: $ ./a.out This is a test This is a test $ Fascinating. Dunno why no complaints from F77 about the undefined EOF (or maybe mis-defined), but hey, it works and it's fun. I'm curious how much ratfor was used in bell labs and other locations running v6, v7, and the BSD's. When I first came across it, I was under the impression that it was a wrapper to make f66 bearable, but the manpage says it's best used with f77, so that's not quite right. As someone coming from c, I totally appreciate what it does to make the control structures I know and love available, but that wasn't the case back then, was it? C was pretty new... Was it just a temporary fix to a problem that just went away, or is there tons of ratfor out there in the wild that I just haven't seen? I found ratfor77 and it runs just fine on my mac with a few tweaks, so it's not dead: ratfor77 -C copy.r | tee copy.f C Output from Public domain Ratfor, version 1.0 C copy - copy input characters to output       integer getc       integer c 23000 if(getc(c) .ne. eof)then       call putc(c)       goto 23000       endif 23001 continue       stop       end What's the story? Oh, and in v6 it looks like it was rc - ratfor compiler, which is not present in v7 or 4.3BSD - is there a backstory there, too? Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Tue Feb 1 08:45:58 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 31 Jan 2022 17:45:58 -0500 (EST) Subject: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> <9E47A62E-3AAD-491E-9164-3DCAD22EC1F7@kdbarto.org> <71ce6652-cf15-44db-01df-62ab89a5a134@gmail.com> Message-ID: On Mon, 31 Jan 2022, Paul Winalski wrote: > On 1/30/22, Steve Nickolas wrote: >> >> And I think I've heard the Infocom compilers' bytecode called "Z-code" (I >> use this term too). >> > That is correct. The Infocom games ran on an interpreter for an > abstract machine called the Z-machine. Z-code is the Z-machine's > instruction set. There is a freeware implementation out there called > Frotz. > > -Paul W. > > "Plugh" (said in a hollow voice) > There's also InfoTaskForce and JZIP, both of which I *think* work on *x, but they are not as advanced as Frotz. JZIP comes closer, having been Frotz's main competition for some time in the late 1990s. -uso. From gtaylor at tnetconsulting.net Tue Feb 1 12:12:32 2022 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 31 Jan 2022 19:12:32 -0700 Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> <20220127015505.GC10568@netmeister.org> <20220129023641.GL16452@mcvoy.com> Message-ID: <685fd0dc-e959-c7c1-0110-c8f55021b752@spamtrap.tnetconsulting.net> On 1/29/22 1:48 AM, Andy Kosela wrote: > I can speak only for myself, but I love that TUHS/COFF mailing lists > are still _the real_ mailing lists managed the old school way. Usenet is still a thing that I use daily. > I hate all those modern web 2.0 technologies with extremely bloated js > stacks which you can only use if you have the latest version of Chrome. I too dislike what the Web 2.0 world has turned into. I believe that it's possible for web pages to by dynamic via AJAX without all the bloat. Sadly this isn't done. > I am still using old Atari DOS, Amiga Workbench, MS-DOS/Win9x/WinXP > and of course Linux/FreeBSD. :-) > This is probably one of the last places on the Internet that is > still preserving one of its core ideas in the 80s/90s -- plain > text communication. It has been slowly dying in the last 15 years. > Text based Internet of the 80s and 90s has slowly been replaced by > binary protocols and image based interaction with a computer. Usenet. > I still just love using text based protocols and command line and > read it on a real CRT monitor in full screen text mode. We lost > something when the world moved on. I used to have similar thoughts. Then I realized that things like OpenSSL's s_client and curl allow interaction with encrypted and other protocols. So, that got me to questioning "what is the command line" (UI / UX) really? Does OpenSSL's s_client (Secure / TLS) client provide a textual interface to TLS encrypted servers? Yes it does. Does it count as "command line"? I think so. So, what if there was a different command line utility that allowed similar interface with HTTP2 / QUIC connections. Would that mean that they are similarly CLI? I think so. Extrapolating out even further, does it actually matter that the bits on the wire are ASCII and / or unencrypted if I have a UI / UX that is akin to a Network Virtual Terminal interface (e.g. telnet, OpenSSL's s_client, etc.)? Or does the client provide an abstraction to fulfill my CLI desires? I think that it probably would. I agree completely that HTTPS is decidedly different on the wire than venerable HTTP which I can communicate with using telnet (et al.). However, the /telnet/ *client* is still there and being used. So when you back up and look at what that /client/ does in providing an abstraction between the end user and the underlying / backing protocol, it turns out that the underlying / backing protocol is less important. > So please do not go anywhere.... I'm not planing on discontinuing using mailing lists or Usenet any time soon. Despite the fact that they have migrated from unencrypted to encrypted communications. Even my MUA / NUA is using encrypted connections to the servers. But /my/ /personal/ /interaction/ with my MUA / NUA hasn't changed. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From usotsuki at buric.co Tue Feb 1 12:21:33 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 31 Jan 2022 21:21:33 -0500 (EST) Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: <685fd0dc-e959-c7c1-0110-c8f55021b752@spamtrap.tnetconsulting.net> References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> <20220127015505.GC10568@netmeister.org> <20220129023641.GL16452@mcvoy.com> <685fd0dc-e959-c7c1-0110-c8f55021b752@spamtrap.tnetconsulting.net> Message-ID: On Mon, 31 Jan 2022, Grant Taylor via TUHS wrote: > On 1/29/22 1:48 AM, Andy Kosela wrote: >> I can speak only for myself, but I love that TUHS/COFF mailing lists are >> still _the real_ mailing lists managed the old school way. > > Usenet is still a thing that I use daily. As do I. > >> I hate all those modern web 2.0 technologies with extremely bloated js >> stacks which you can only use if you have the latest version of Chrome. > I too dislike what the Web 2.0 world has turned into. > > I believe that it's possible for web pages to by dynamic via AJAX without all > the bloat. Sadly this isn't done. The solution to bloat has, sadly, tended to be "throw more CPU/RAM/hard drive at it". That's one big reason WordPerfect 5.0 on a 486 is faster than a modern word processor on a recent i7. >> This is probably one of the last places on the Internet that is still >> preserving one of its core ideas in the 80s/90s -- plain text >> communication. It has been slowly dying in the last 15 years. Text based >> Internet of the 80s and 90s has slowly been replaced by binary protocols >> and image based interaction with a computer. > > Usenet. IRC. ;) > I'm not planing on discontinuing using mailing lists or Usenet any time soon. > Despite the fact that they have migrated from unencrypted to encrypted > communications. Even my MUA / NUA is using encrypted connections to the > servers. But /my/ /personal/ /interaction/ with my MUA / NUA hasn't changed. I still use the same software, in many cases, I've used since the 1990s. -uso. From lm at mcvoy.com Tue Feb 1 12:23:14 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 31 Jan 2022 18:23:14 -0800 Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: <685fd0dc-e959-c7c1-0110-c8f55021b752@spamtrap.tnetconsulting.net> References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> <20220127015505.GC10568@netmeister.org> <20220129023641.GL16452@mcvoy.com> <685fd0dc-e959-c7c1-0110-c8f55021b752@spamtrap.tnetconsulting.net> Message-ID: <20220201022314.GW25875@mcvoy.com> On Mon, Jan 31, 2022 at 07:12:32PM -0700, Grant Taylor via TUHS wrote: > On 1/29/22 1:48 AM, Andy Kosela wrote: > >I can speak only for myself, but I love that TUHS/COFF mailing lists are > >still _the real_ mailing lists managed the old school way. > > Usenet is still a thing that I use daily. So I used to be very active on Usenet, comp.arch and comp.unix.wizards were my jam. soc.singles, yeah, hung out there and I was not well loved for my views. I don't think I've been on usenet since the 1990's because it just turned into a cesspool of crap. Sort of Facebook but text. Are you saying there is still some decent value in Usenet or are you hanging on just because? From usotsuki at buric.co Tue Feb 1 12:31:32 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 31 Jan 2022 21:31:32 -0500 (EST) Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: <20220201022314.GW25875@mcvoy.com> References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> <20220127015505.GC10568@netmeister.org> <20220129023641.GL16452@mcvoy.com> <685fd0dc-e959-c7c1-0110-c8f55021b752@spamtrap.tnetconsulting.net> <20220201022314.GW25875@mcvoy.com> Message-ID: On Mon, 31 Jan 2022, Larry McVoy wrote: > On Mon, Jan 31, 2022 at 07:12:32PM -0700, Grant Taylor via TUHS wrote: >> On 1/29/22 1:48 AM, Andy Kosela wrote: >>> I can speak only for myself, but I love that TUHS/COFF mailing lists are >>> still _the real_ mailing lists managed the old school way. >> >> Usenet is still a thing that I use daily. > > So I used to be very active on Usenet, comp.arch and comp.unix.wizards > were my jam. soc.singles, yeah, hung out there and I was not well > loved for my views. > > I don't think I've been on usenet since the 1990's because it just > turned into a cesspool of crap. Sort of Facebook but text. > > Are you saying there is still some decent value in Usenet or are you > hanging on just because? Well, I mostly lurk on comp.sys.apple2 and comp.os.cpm... there's sometimes interesting stuff going on there still. -uso. From gtaylor at tnetconsulting.net Tue Feb 1 12:51:40 2022 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 31 Jan 2022 19:51:40 -0700 Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: <20220201022314.GW25875@mcvoy.com> References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> <20220127015505.GC10568@netmeister.org> <20220129023641.GL16452@mcvoy.com> <685fd0dc-e959-c7c1-0110-c8f55021b752@spamtrap.tnetconsulting.net> <20220201022314.GW25875@mcvoy.com> Message-ID: On 1/31/22 7:23 PM, Larry McVoy wrote: > So I used to be very active on Usenet, comp.arch and comp.unix.wizards > were my jam. soc.singles, yeah, hung out there and I was not well > loved for my views. I'll check out the comp.* groups and let you know what I see. > I don't think I've been on usenet since the 1990's because it just > turned into a cesspool of crap. Sort of Facebook but text. It seems to be a lot better as the number of people went down, there were fewer people for the trolls to feed on. > Are you saying there is still some decent value in Usenet or are you > hanging on just because? Yes, I have some good conversations in multiple newsgroups on the weekly basis and probably many on the monthly basis. My Thunderbird newsrc file has 427 lines of subscribed groups. I see worth while articles in 20-200 of them a day. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From blake1024 at gmail.com Tue Feb 1 22:45:05 2022 From: blake1024 at gmail.com (Blake McBride) Date: Tue, 1 Feb 2022 06:45:05 -0600 Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: <685fd0dc-e959-c7c1-0110-c8f55021b752@spamtrap.tnetconsulting.net> References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> <20220127015505.GC10568@netmeister.org> <20220129023641.GL16452@mcvoy.com> <685fd0dc-e959-c7c1-0110-c8f55021b752@spamtrap.tnetconsulting.net> Message-ID: On Mon, Jan 31, 2022 at 8:13 PM Grant Taylor via TUHS wrote: > On 1/29/22 1:48 AM, Andy Kosela wrote: > [...] > > I hate all those modern web 2.0 technologies with extremely bloated js > > stacks which you can only use if you have the latest version of Chrome. > I too dislike what the Web 2.0 world has turned into. > > I believe that it's possible for web pages to by dynamic via AJAX > without all the bloat. Sadly this isn't done. > Having many years developing development frameworks, and having a need for a simple way to write business applications for the Web, I ended up writing my own Java-based, open-source web development framework called KISS. KISS stands for exactly what you think it does! KISS supports the front-end and back-end already configured and running out-of-the-box. It runs on Linux, Mac, and Windows (and probably most other Unix-like environments that support Java). On the back-end, it supports writing your application in Java, Groovy, or Common Lisp. On the front-end, it is just plain HTML, CSS, and JavaScript. It comes with a new build system of my own making. That makes the whole system as easy as possible. For example, after downloading, you can download any needed libraries, build, and run the entire system by typing: ./bld develop That's it! You type the above and you have a complete, running web application built and running. It communicates over REST Web services. It also uses microservices and is designed so that both the front-end and back-end can be developed on a running system without the need for rebuilds or re-booting the server. This is also great for updating a production environment without bringing the system down! KISS also supports custom HTML controls, an SQL API, built-in authentication, reporting (using Groff & Tbl!), and a lot more. The system is being used in production environments today, so it isn't a beta. It comes with documentation. There is also a YouTube training series, and there has been a couple of articles written about it. With KISS, you can have an up-and-running web application running from scratch in less than five minutes. After that, you can build on it while it is running. Check it out! https://kissweb.org Blake McBride -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Feb 2 01:37:34 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Feb 2022 08:37:34 -0700 Subject: [TUHS] ratfor vibe In-Reply-To: References: Message-ID: <202202011537.211FbYSe017204@freefriends.org> Will, This will be a high level reply. I undoubtedly have some details wrong, as I wasn't inside Bell Labs. Sherman, set the wayback machine for 1974. -- Mr. Peabody In 1974, Unix was still young, and while C existed, it was not widespread. The predominant programmng language in use at the time in Bell Labs and in many, many other places, was Fortran. For our purposes, Fortran IV and Fortran 66 are the same thing: the only control flow constructs the language had was 'if', 'goto' and a 'do' loop that could only count up. The only data structure was the array. Structured Programming had started to take hold in the Computer Science community, with lots of discussion and papers about what the best control flow structures were, and so on. At the time there were preprocessors for Fortran that made it easier to program in. I don't know what got him started, by Brian Kernighan decided to write one that would give Fortran control flow constructs similar or identical to those of C. This was ratfor, for RATional FORtran. He used C and Yacc (which was also fairly young) to do this. Recognizing that the Unix environment was very pleasant, but that the wide world wouldn't drop everything they had to move to it, he and P.J. (Bill) Plauger used ratfor to create a bunch of tools that provided functionality similar or identical to many of the Unix utilities, and wrote a book on the tools, using it as a platform to at the same time teach good programming practices. This is https://www.amazon.com/Software-Tools-Brian-W-Kernighan/dp/020103669X/ref=sr_1_5?crid=LXBHQKV9D0QP&keywords=software+tools&qid=1643720166&s=books&sprefix=software+tools%2Cstripbooks%2C220&sr=1-5 which I STRONGLY recommend getting and reading, even almost 50 years after it was published (1975 or 1976). This book changed my life. Literally. The original tools are in the TUHS archives. (If anyone has not synched their copy, please do so, there were some errors in the files that I have recently fixed and which Warren has put in place.) (A modernized version of UNIX ratfor is at https://github.com/arnoldrobbins/ratfor, so you don't have to use V7 to get it. The doc is included and it's easy to make PDF of it.) The book and tools were extremely popular into the early 80s, until Unix itself started to spread. Debbie Scherer can give the history of her group, which took the tools and made them portable to all kinds of computing environments. At Georgia Tech, 3 students took the tools and adapted them into a lovely environment for use on Pr1me systems, which were otherwise rather less user-friendly. At Bell Labs, Brenda Baker wrote 'struct' which read Fortran and turned it into ratfor; see the recent list archives for more on my efforts to bring that program into the 21st century. (Apologies for the self plugs. :-) In ~ 1981, Kernighan and Plauger rewrote the tools in Pascal and redid the book to go with it. This is https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan/dp/0201103427/ref=sr_1_3?keywords=software+tools+in+pascal&link_code=qs&qid=1643727958&sourceid=Mozilla-search&sr=8-3 which I also recommend getting a copy of. This in turn led to Kernighan's famous "Pascal is not my favorite programming language" memo (which is also in my github :-). The Pascal tools are also in the TUHS archive. I hope this helps. Arnold Will Senn wrote: > All, > > I have been doing some language exploration in v7/4.3bsd and came across > Software Tools (not the pascal version). It's written using ratfor, > which I had seen in the v7 UPM. I fired up v7 and tried my hand at the > first example: > > # copy - copy input characters to output >         integer getc >         integer c > >         while(getc(c) != EOF) >                 call putc(c) >         stop >         end > > The first thing I noticed was that it read more like C than Fortran (I > know C quite well, Fortran just a smidge)... awesome, right? So I ran > the preprocessor on it and got the following f77 code: > > c copy - copy input characters to output >       integer getc >       integer c > c     while > 23000 if(.not.(getc(c) .ne. eof))goto 23001 >          call putc(c) >          goto 23000 > c     endwhile > 23001 continue >       stop >       end > > Cool. The way it translated the EOF test is weird, but ok. Trying to > compile it results in complaints about missing getc and putc: > > $ f77 copy.f > copy.f: >    MAIN: > Undefined: > _getc_ > _putc_ > _end > > Ah well, no worries. I know that they're in the c lib, but don't about > fortran libs... Meanwhile, over on 4.3BSD, it compiles without issue. > But running it is no joy: > > $ ./a.out > This is a test > $ > > I remembered that the authors mentioned something about EOF, so I > tweaked the code (changed EOF to -1) and rebuilt/reran: > > $ ./a.out > This is a test > This is a test > $ > > Fascinating. Dunno why no complaints from F77 about the undefined EOF > (or maybe mis-defined), but hey, it works and it's fun. > > I'm curious how much ratfor was used in bell labs and other locations > running v6, v7, and the BSD's. When I first came across it, I was under > the impression that it was a wrapper to make f66 bearable, but the > manpage says it's best used with f77, so that's not quite right. As > someone coming from c, I totally appreciate what it does to make the > control structures I know and love available, but that wasn't the case > back then, was it? C was pretty new... Was it just a temporary fix to a > problem that just went away, or is there tons of ratfor out there in the > wild that I just haven't seen? I found ratfor77 and it runs just fine on > my mac with a few tweaks, so it's not dead: > > ratfor77 -C copy.r | tee copy.f > C Output from Public domain Ratfor, version 1.0 > C copy - copy input characters to output >       integer getc >       integer c > 23000 if(getc(c) .ne. eof)then >       call putc(c) >       goto 23000 >       endif > 23001 continue >       stop >       end > > What's the story? Oh, and in v6 it looks like it was rc - ratfor > compiler, which is not present in v7 or 4.3BSD - is there a backstory > there, too? > > Will > > > From beebe at math.utah.edu Wed Feb 2 01:27:21 2022 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue, 1 Feb 2022 08:27:21 -0700 Subject: [TUHS] Ritchie/Thompson Unix Time-Sharing System in Classic Papers Message-ID: There is a new book from MIT Press, edited by Harry Lewis, with a collection of classic papers in computer science, among them 37: The Unix Time-Sharing System (1974) Dennis Ritchie, Kenneth Thompson DOI: https://doi.org/10.7551/mitpress/12274.003.0039 The book Web site is at https://direct.mit.edu/books/book/5003/Ideas-That-Created-the-FutureClassic-Papers-of ------------------------------------------------------------------------------- - 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 ralph at inputplus.co.uk Wed Feb 2 01:52:25 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 01 Feb 2022 15:52:25 +0000 Subject: [TUHS] ratfor vibe In-Reply-To: <202202011537.211FbYSe017204@freefriends.org> References: <202202011537.211FbYSe017204@freefriends.org> Message-ID: <20220201155225.5A9541FB21@orac.inputplus.co.uk> Hi Arnold, > In ~ 1981, Kernighan and Plauger rewrote the tools in Pascal and redid > the book to go with it. This is > https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan/dp/0201103427/ > which I also recommend getting a copy of. I agree the original Software Tools is a must read, but having done so, why would I suffer working through the hurdles put in place by Pascal compared to Ratfor? I never bothered so your recommendation makes me wonder what I missed. I did read Kernighan's ‘not my favourite’ and took from that I wouldn't enjoy the Pascal book given I'd read the original. -- Cheers, Ralph. From ralph at inputplus.co.uk Wed Feb 2 02:25:27 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 01 Feb 2022 16:25:27 +0000 Subject: [TUHS] Ritchie/Thompson Unix Time-Sharing System in Classic Papers In-Reply-To: References: Message-ID: <20220201162527.8D1801FB21@orac.inputplus.co.uk> Hi, Nelson wrote: > There is a new book from MIT Press, edited by Harry Lewis, with a > collection of classic papers in computer science, among them > > 37: The Unix Time-Sharing System (1974) > Dennis Ritchie, Kenneth Thompson > DOI: https://doi.org/10.7551/mitpress/12274.003.0039 > > The book Web site is at > > https://direct.mit.edu/books/book/5003/Ideas-That-Created-the-FutureClassic-Papers-of Looks interesting. Forty-six papers, each with a brief essay by Harry Lewis setting the context. ‘...with an emphasis on the period of 1936-1980 but also including important early work’. Amazon shows 4.8 out of 5 stars after 26 ratings: 77% 5*, 23% 4*. https://amzn.to/3rkvPaU One review says ‘The book originated from a discussion course the author taught at Harvard’, another points out Thompson's ‘Reflections’ is missing. :-) Amazon's ‘Look inside’ works to give a flavour. The list of papers is: - Prior Analytics (~350 BCE), by Aristotle - The True Method (1677), by Gottfried Wilhelm Leibniz - Sketch of the Analytical Engine (1843), by L. F. Menabreca - An Investigation of the Laws of Thought on Which Are Founded the Mathematical Theories of Logic and Probabilities (1854), by George Boole - Mathematical Problems (1900), by David Hilbert - On Computable Numbers, with an Application to the Entscheidungsproblem (1936), by Alan Mathison Turing - A Proposed Automatic Calculating Machine (1937), by Howard Hathaway Aiken - A Symbolic Analysis of Relay and Switching Circuits (1938), by Claude Shannon - A Logical Calculus of the Ideas Immanent in Nervous Activity (1943), by Warren McCulloch, Walter Pitts - First Draft of a Report on the EDVAC (1945), by John von Neumann - As We May Think (1945), by Vannevar Bush - A Mathematical Theory of Communication (1948), by Claude Shannon - Error Detecting and Error Correcting Codes (1950), by R. W. Hamming - Computing Machinery and Intelligence (1950), by Alan Mathison Turing - The Best Way to Design an Automatic Calculating Machine (1951), by Maurice Wilkes - The Education of a Computer (1952), by Grace Murray Hopper - On the Shortest Spanning Subtree of a Graph and the Traveling Salesman Problem (1956), by Joseph B. Kruskal, Jr. - The Perceptron: A Probabilistic Model for Information Storage and Organization (1958), by Frank Rosenblatt - Some Moral and Technical Consequences of Automation (1960), by Norbert Wiener - Man-Computer Symbiosis (1960), by J. C. R. Licklider - Recursive Functions of Symbolic Expressions and Their Computation by Machine (1960), by John McCarthy - Augmenting Human Intellect: A Conceptual Framework (1962), by Douglas C. Englebrt - An Experimental Time-Sharing System (1962), by Fernando Corbató, Marjorie Merwin Daggett, Robert C. Daly - Sketchpad (1963), by Ivan E. Sutherland - Cramming More Components onto Integrated Circuits (1965), by Gordon Moore - Solution of a Problem in Concurrent Program Control (1965), by Edsger Dijkstra - ELIZA -- A Computer Program for the Study of Natural Language Communication between Man and Machine (1966), by Joseph Weizenbaum - The Structure of the “THE”-Multiprogramming System (1968), by Edsger Dijkstra - Go To Statement Considered Harmful (1968), by Edsger Dijkstra - Gaussian Elimination is Not Optimal (1969), by Volker Strassen - An Axiomatic Basis for Computer Programming (1969), by C. A. R. Hoare - A Relational Model of Large Shared Data Banks (1970), by Edgar F. Codd - Managing the Development of Large Software Systems (1970), by Winston W. Royce - The Complexity of Theorem-Proving Procedures (1971), by Stephen A. Cook - A Statistical Interpretation of Term Specificity and Its Application in Retrieval (1972), by Karen Spärck Jones - Reducibility among Combinatorial Problems (1972), by Richard Karp - The Unix Time-Sharing System (1974), by Dennis Ritchie, Kenneth Thompson - A Protocol for Packet Network Intercommunication (1974), by Vnton Cerf, Robert Kahn - Programming with Abstract Data Types (1974), by Barbara Liskov, Stephen Zilles - The Mythical Man-Month (1975), by Frederick C. Brooks - Ethernet: Distributed Packet Switching for Local Computer Networks (1976), by Robert Metcalfe, David R. Boggs - New Directions in Cryptography (1976), by Whitfield Diffie, Martin Hellman - Big Omicron and Big Omega and Big Theta (1976), by Donald E. Knuth - Social Processes and Proofs of Theorems and Programs (1977), by Richard DeMillo, Richard Lipton, Alan Perlis - A Method for Obtaining Digital Signatures and Public-Key Cryptosystems (1978), by Ronald Rivest, Adi Shamir, Len Adelman - How to Share a Secret (1979), by Adi Shamir -- Cheers, Ralph. From clemc at ccc.com Wed Feb 2 02:58:02 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 1 Feb 2022 11:58:02 -0500 Subject: [TUHS] ratfor vibe In-Reply-To: <20220201155225.5A9541FB21@orac.inputplus.co.uk> References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> Message-ID: On Tue, Feb 1, 2022 at 10:53 AM Ralph Corderoy wrote: > I agree the original Software Tools is a must read, but having done so, > why would I suffer working through the hurdles put in place by Pascal > compared to Ratfor? I'll take a stab. Again set Arnold's Way-Back machine to the late '60 and through the mid 1970s. The Algol vs. FTN war was raging. FTN had 'won' the Science and Engineering communities and Algol was the Math/CS types [I'm over simplifying]. In fact, when I was at CMU in the mid-70s; my professors all said *FTN was dead* ( mind you production quality FTN code has paid my salary in the HPC world my entire career ). At CMU, the compromise is all engineers were required to take an intro to computing using in FTN/WATFIV course and then all other 200 level or greater CS course after that were usualy based using an Algol/ or later Pascal. The point being any reasonable computer system being brought to market by a *credible systems vendor* had at least an implementation of FTN4 that could pass the ANSI test suite and many started to have one that support F77 [although thank you DEC VMS FTN != F77]. But ... because of the push from the teaching/CS side in most places, Pascal started to show up as a standard offering [C did not - yet - have that backing]. I suspect if you check my generation and for the next 10-20 years after, you will see Pascal was the first language you saw in college. So by the late 70s/early 80s, [except for MIT where LISP/Scheme reigned] Pascal had become the primary teaching language for the CS communities at most schools. C was considered a tad 'dirty' [not as bad as assembler -- but close]. It might have been used in an OS or Compiler course. In fact in the grad Graphics course I took, which was taught by Xerox folks, I had to get a special exception to use C. But the fact is, at that time, if you read the literature, you would believe that Pascal was going to be the future. Hence the concept of doing the SWT in Pascal made sense >>in theory<<. Another important fact was that while the P4 system made moving Pascal easier than many other languages, as Rob pointed out, the Pascal I/O was so screwy and frankly not well bound to the host OS, that every new implementation messed with it in some manner [see Brian's wonderful tome for more details]. Similarly, the lack of standardized way to do separate compilation for support libs (which had been a prime idea in FTN and allowed a rich market for libraries), really had a huge effect. Again it was solved many times with each compiler implementation, but each scheme tended to be a little different. Fortran, of course, had been around long enough and had an ANSI standard (and a test suite for it) at least made portable FTN possible. So the theory was good -- Pascal was a 'better' language in theory and everyone was coming out of school knowing it. Again, reality ... since UNIX came with C and was 'open source' in the sense that everyone that had it, had the AT&T source code. One of the first things that happened was C was retargeted to a number of processors -- often not by either the manufacturer or by the system vendor. Interestingly, this was about 50/50 between Academics/Research and Industry. So while all the world's ISA were not a PDP-11, the fun part is the code *could be made reasonably* portable - in fact *in practice* [partly because C had a pre-processor which Pascal did not and of course is what ratfor is] have one source base that could compile for different targets. The problem (as you note) these issues are >>obvious<< in hindsight, but during that time -- it was not. It certainly seems like Pascal had a lot of momentum. They were a lot compilers for a lot of systems. Look, it was the language Apple used for the Lisa and Mac. Things like UCSD Pascal was being made by the press as 'the answer for 8 bit processors' [note MSFT had a FTN for the 8080 on CPM in those days]. Turbo Pascal was, in fact, an excellent compiler. But C was starting to come on strong. FWIW: In the end, I personally believe that C 'won' because the practical side made it cheaper to use (economics always beat architecture). The cynical part of me thinks that a big reason why C++ caught on is because a lot of the pro-Pascal community got to sing the praises of OOP with C++ and they could change sides without claiming C beat Pascal. Hey, Microsoft made a pretty good C for DOS and finally going C++ probably helped. It sold more than the FORTRAN and my guess is that people using FORTRAN at that point were scientists and needed the address space that 8086 did not have. The 386 with a linear address for using things like the PharLap tools made it possible and frankly the Intel 8087 started to make that processor a better target for science. In the end, Pascal never had a code base like the FTN Scientific code base or todays C and C++ code base. FWIW: I can think of few production Pascal codes from those days that are still being used [other than the Front-End of the DEC/Intel FORTRAN compiler - which was moved from BLISS to Pascal for all the same 'C is dirty' issues BTW]. -------------- next part -------------- An HTML attachment was scrubbed... URL: From silas8642 at hotmail.co.uk Wed Feb 2 03:02:12 2022 From: silas8642 at hotmail.co.uk (silas poulson) Date: Tue, 1 Feb 2022 17:02:12 +0000 Subject: [TUHS] ratfor vibe In-Reply-To: <20220201155225.5A9541FB21@orac.inputplus.co.uk> References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> Message-ID: > On 1 Feb 2022, at 15:52, Ralph Corderoy wrote: > I never bothered so your recommendation makes me wonder what I missed. Whilst I haven’t read the original, believe Kernighan and Plauger state in preface that Pascal enabled recursive algorithms to be written in their natural manner. Don’t believe Fortran has record or set datatypes and imagine those enabled code improvements between the Ratfor and the Pascal > I did read Kernighan's ‘not my favourite’ and took from that I > wouldn't enjoy the Pascal book given I'd read the original. Not quite sure reading both editions of the book but would definitely recommend examining the code which Arnold states is available on the TUHS archive. Silas From jnc at mercury.lcs.mit.edu Wed Feb 2 04:19:09 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 1 Feb 2022 13:19:09 -0500 (EST) Subject: [TUHS] ratfor vibe Message-ID: <20220201181909.6224518C086@mercury.lcs.mit.edu> > From: Clem Cole > So by the late 70s/early 80s, [except for MIT where LISP/Scheme reigned] Not quite. The picture is complicated, because outside the EECS department, they all did their own thing - e.g. in the mid-70's I took a programming intro couse in the Civil Engineering department which used Fortran. But in EECS, in the mid-70's, their intro programming course used assembler (PDP-11), Algol, and LISP - very roughly, a third of the time in each. Later on, I think it used CLU (hey, that was MIT-grown :-). I think Scheme was used later. In both of these cases, I have no idea if it was _only_ CLU/Scheme, or if they did part of it in other languages. Noel From clemc at ccc.com Wed Feb 2 04:19:30 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 1 Feb 2022 13:19:30 -0500 Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: <20220201022314.GW25875@mcvoy.com> References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> <20220127015505.GC10568@netmeister.org> <20220129023641.GL16452@mcvoy.com> <685fd0dc-e959-c7c1-0110-c8f55021b752@spamtrap.tnetconsulting.net> <20220201022314.GW25875@mcvoy.com> Message-ID: On Mon, Jan 31, 2022 at 9:23 PM Larry McVoy wrote: > I don't think I've been on usenet since the 1990's because it just turned > into a cesspool of crap. > My line at the time was that 'the signal to noise ratio seems to have disappeared'. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Wed Feb 2 04:24:43 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 01 Feb 2022 19:24:43 +0100 Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> <20220127015505.GC10568@netmeister.org> <20220129023641.GL16452@mcvoy.com> <685fd0dc-e959-c7c1-0110-c8f55021b752@spamtrap.tnetconsulting.net> <20220201022314.GW25875@mcvoy.com> Message-ID: <20220201182443.ukAaW%steffen@sdaoden.eu> Clem Cole wrote in : |On Mon, Jan 31, 2022 at 9:23 PM Larry McVoy wrote: | |> I don't think I've been on usenet since the 1990's because it just turned |> into a cesspool of crap. |> |My line at the time was that 'the signal to noise ratio seems to have |disappeared'. To be fair it is not different to almost anything else thus. --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 clemc at ccc.com Wed Feb 2 04:47:59 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 1 Feb 2022 13:47:59 -0500 Subject: [TUHS] ratfor vibe In-Reply-To: <20220201181909.6224518C086@mercury.lcs.mit.edu> References: <20220201181909.6224518C086@mercury.lcs.mit.edu> Message-ID: On Tue, Feb 1, 2022 at 1:19 PM Noel Chiappa wrote: > > From: Clem Cole > > > So by the late 70s/early 80s, [except for MIT where LISP/Scheme > reigned] > > Not quite. The picture is complicated, because outside the EECS department, > they all did their own thing - > Interesting .. I trust you, but I had thought ( famously) you folks had required a LISP and/or Scheme in the required "intro to computers" course using the Gerald Sussman and Hal Abelson "Structure of Computer Programs" [Scheme IIRC] until it was finally replaced a few years ago with a Python based one [I thought it was tjt that told me that, but I could easily have been misled/misunderstood]. FWIW: Through the 60s, the early and into the later 70s, CMU used to call its 15-104 "Intro to Computer Programming" and was based on batch (card) computing using FTN4, later WATFIV. They used a number of books. The book I had was from Waterloo and other than being blue and black in color, I remember little from it - since I already knew how and the TA let me take 'self-taught' by turning in assignments/taking the tests without going to class. Like Freshman Physics and Calc, all intro science and engineering majors were required to take it however, since the engineering depts were sure what you would see when you graduated was FTN based code [which was probably true for the more pure Science types]. Much later (many years after I left) the CS Dept finally convinced Mat Sci, Chem E and Mech E to allow the course to be taught using Pascal. I think they use either Java or Python now, but I haven't checked. On the other hand, at UCB the intro course was called CS-40 "Introduction to Computing" which was required of all Letters and Science Majors. When I helped to teach it in the early 80s as a grad student, we could only handle a thousand students and turned away over another thousand [for a required undergrad course]. We used Clancy and Cooper's "Oh Pascal" as the text and the UCB pi interpreter on the 11/70s running a flavor of V7 / 2BSD. Before I got there, they must have taught it on the CDC machine using FTN, but I'm not sure. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Feb 2 05:10:09 2022 From: crossd at gmail.com (Dan Cross) Date: Tue, 1 Feb 2022 14:10:09 -0500 Subject: [TUHS] ratfor vibe In-Reply-To: References: <20220201181909.6224518C086@mercury.lcs.mit.edu> Message-ID: On Tue, Feb 1, 2022 at 1:49 PM Clem Cole wrote: > [snip] > FWIW: Through the 60s, the early and into the later 70s, CMU used to call > its 15-104 "Intro to Computer Programming" and was based on batch (card) > computing using FTN4, later WATFIV. They used a number of books. The book > I had was from Waterloo and other than being blue and black in color, I > remember little from it - since I already knew how and the TA let me take > 'self-taught' by turning in assignments/taking the tests without going to > class. Like Freshman Physics and Calc, all intro science and engineering > majors were required to take it however, since the engineering depts were > sure what you would see when you graduated was FTN based code [which was > probably true for the more pure Science types]. Much later (many years > after I left) the CS Dept finally convinced Mat Sci, Chem E and Mech E to > allow the course to be taught using Pascal. I think they use either Java > or Python now, but I haven't checked. > There was a bit of a stir about 10 years ago when CMU switched from Java (I think?) to Python and SML for introductory computer science education. I remember reading a report at the time, which I _think_ is this: http://reports-archive.adm.cs.cmu.edu/anon/2010/CMU-CS-10-140.pdf Though perhaps not, because it _really_ bit into Java and the whole OOP thing. Robert Harper had a blog post that I found interesting about exposing freshmen to functional programming: https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/ - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Wed Feb 2 05:39:26 2022 From: rich.salz at gmail.com (Richard Salz) Date: Tue, 1 Feb 2022 14:39:26 -0500 Subject: [TUHS] ratfor vibe In-Reply-To: References: <20220201181909.6224518C086@mercury.lcs.mit.edu> Message-ID: > Interesting .. I trust you, but I had thought ( famously) you folks had > required a LISP and/or Scheme in the required "intro to computers" course > using the Gerald Sussman and Hal Abelson "Structure of Computer > Programs" [Scheme IIRC] until it was finally replaced a few years ago > with a Python based one [I thought it was tjt that told me that, but I > could easily have been misled/misunderstood]. > I think that wasn't until 1981. I took 6.912, which was an experimental pre-cursor to the SICP class as a sophomore. We did LISP programming on Multics. I might have the years off by one -- it was when "Fear of Music" came out. :) The mainstream intro classes used Algol on a PDP-11 I think? To emphasize Noel's point about the distributed nature, the intro to programming class in the MechE department, 2.10, was Fortran first on punch cards and then interactive when they got a big-ass DEC 20 running Digital software. Amusingly MIT AI got one shortly after, and there was some controversy about leaving TOPS-20 or converting it to ITS; ITS lost. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Feb 2 05:39:55 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 1 Feb 2022 14:39:55 -0500 Subject: [TUHS] ratfor vibe In-Reply-To: References: <20220201181909.6224518C086@mercury.lcs.mit.edu> Message-ID: Dan - thanks. Clem On Tue, Feb 1, 2022 at 2:10 PM Dan Cross wrote: > On Tue, Feb 1, 2022 at 1:49 PM Clem Cole wrote: > >> [snip] >> FWIW: Through the 60s, the early and into the later 70s, CMU used to >> call its 15-104 "Intro to Computer Programming" and was based on batch >> (card) computing using FTN4, later WATFIV. They used a number of books. >> The book I had was from Waterloo and other than being blue and black in >> color, I remember little from it - since I already knew how and the TA let >> me take 'self-taught' by turning in assignments/taking the tests without >> going to class. Like Freshman Physics and Calc, all intro science >> and engineering majors were required to take it however, since the >> engineering depts were sure what you would see when you graduated was FTN >> based code [which was probably true for the more pure Science types]. >> Much later (many years after I left) the CS Dept finally convinced Mat >> Sci, Chem E and Mech E to allow the course to be taught using Pascal. I >> think they use either Java or Python now, but I haven't checked. >> > > There was a bit of a stir about 10 years ago when CMU switched from Java > (I think?) to Python and SML for introductory computer science education. I > remember reading a report at the time, which I _think_ is this: > http://reports-archive.adm.cs.cmu.edu/anon/2010/CMU-CS-10-140.pdf > > Though perhaps not, because it _really_ bit into Java and the whole OOP > thing. > > Robert Harper had a blog post that I found interesting about exposing > freshmen to functional programming: > https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/ > > - Dan C. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Feb 2 07:21:37 2022 From: crossd at gmail.com (Dan Cross) Date: Tue, 1 Feb 2022 16:21:37 -0500 Subject: [TUHS] ratfor vibe In-Reply-To: References: <20220201181909.6224518C086@mercury.lcs.mit.edu> Message-ID: On Tue, Feb 1, 2022 at 2:40 PM Clem Cole wrote: > Dan - thanks. > Sure thing. By the way: the thing I was thinking about earlier that was so biting towards OOP was an earlier version of Harper's post, in which he writes, "Object-oriented programming is eliminated entirely from the introductory curriculum, because it is both anti-modular and anti-parallel by its very nature, and hence unsuitable for a modern CS curriculum." https://web.archive.org/web/20110321004746/https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/ (How's _that_ for an academic glove-slap?) It would appear that language was softened to read "unsuitable for our purposes" sometime in 2013, and then that rather inflammatory clause was removed entirely by early March, 2015. I had read the original and felt some schadenfreude. - Dan C. On Tue, Feb 1, 2022 at 2:10 PM Dan Cross wrote: > >> On Tue, Feb 1, 2022 at 1:49 PM Clem Cole wrote: >> >>> [snip] >>> FWIW: Through the 60s, the early and into the later 70s, CMU used to >>> call its 15-104 "Intro to Computer Programming" and was based on batch >>> (card) computing using FTN4, later WATFIV. They used a number of books. >>> The book I had was from Waterloo and other than being blue and black in >>> color, I remember little from it - since I already knew how and the TA let >>> me take 'self-taught' by turning in assignments/taking the tests without >>> going to class. Like Freshman Physics and Calc, all intro science >>> and engineering majors were required to take it however, since the >>> engineering depts were sure what you would see when you graduated was FTN >>> based code [which was probably true for the more pure Science types]. >>> Much later (many years after I left) the CS Dept finally convinced Mat >>> Sci, Chem E and Mech E to allow the course to be taught using Pascal. I >>> think they use either Java or Python now, but I haven't checked. >>> >> >> There was a bit of a stir about 10 years ago when CMU switched from Java >> (I think?) to Python and SML for introductory computer science education. I >> remember reading a report at the time, which I _think_ is this: >> http://reports-archive.adm.cs.cmu.edu/anon/2010/CMU-CS-10-140.pdf >> >> Though perhaps not, because it _really_ bit into Java and the whole OOP >> thing. >> >> Robert Harper had a blog post that I found interesting about exposing >> freshmen to functional programming: >> https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/ >> >> - Dan C. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Feb 2 07:33:19 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 1 Feb 2022 16:33:19 -0500 Subject: [TUHS] ratfor vibe In-Reply-To: References: <20220201181909.6224518C086@mercury.lcs.mit.edu> Message-ID: On Tue, Feb 1, 2022 at 4:22 PM Dan Cross wrote: > On Tue, Feb 1, 2022 at 2:40 PM Clem Cole wrote: > >> Dan - thanks. >> > > Sure thing. > > By the way: the thing I was thinking about earlier that was so biting > towards OOP was an earlier version of Harper's post, in which he writes, > "Object-oriented programming is eliminated entirely from the introductory > curriculum, because it is both anti-modular and anti-parallel by its very > nature, and hence unsuitable for a modern CS curriculum." > https://web.archive.org/web/20110321004746/https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/ > (How's _that_ for an academic glove-slap?) > Amen... My disagreement with them using scripting (python) as step one is the lack of teaching data typing early AND python's silly use space/tabs to set up structure instead of real {} or B/E blocks. Automatic data conversion has never been a good idea in my experience because like many things that happen magically, it almost never works as I expect. Funny we were discussing the roff family and that is why I like it over things like Word -- way too much hidden behind the screen for my taste. I'm a make it explicit kinda guy I guess. I hate surprises ... Also, it remains to be seen if teaching FP early helps - which they are clearly making play. Who am I to say, as one of the earliest languages I learned APL, so FP thinking was drilled into me in my youth. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Wed Feb 2 07:34:53 2022 From: will.senn at gmail.com (Will Senn) Date: Tue, 1 Feb 2022 15:34:53 -0600 Subject: [TUHS] BSD 4.1, 4.1x, Quasijarus, and 4.3x Message-ID: All, I did my research on this, but it's still a bit fuzzy (why is it that people's memories from 40 years ago are so malleable?). 1. What are y'all's recollections regarding BSD 4.1's releases, vis a vis the VAX. In McKusick's piece, Twenty Years of Berkeley Unix, I get one perspective, and from Sokolov's Quasijarus project, I get quite another. In terms of popularity and in terms of stable performance, what say you? Was 4.1 that much better than 4BSD? Was 4.1as obsolete immediately as McKusick says? 4.1b sounds good with FFS, was it? 4.1c's the last pre 4.2 release, but it sounds like it was nearly a beta version of 4.2... 2. Sokolov implies that the CSRG mission started going off the rails with the 4.3/4.3BSD-Tahoe and it all went pear shaped with the 4.3-Reno release, and that Quasijarus puts the mission back on track, is that so? 3. I've gotten BSD 4.2 and BSD 4.3 releases built from tape and working very well. I just can't decide whether to go back to one of the 4.x releases (hence question 1), or go get Quasijarus0c - thoughts on why one might be more interesting than another? 4. Is Quasijarus0c end of the line for VAX 4.xBSD? Why does tuhs only have Quasijarus0 and 0a, was there something wrong with 0b and 0c? 5. Has anyone unearthed an original 4.1 tape, or is Haertel's reconstruction of the 1981 tape 1 release as close as it gets? Later, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Feb 2 07:47:53 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 1 Feb 2022 13:47:53 -0800 Subject: [TUHS] BSD 4.1, 4.1x, Quasijarus, and 4.3x In-Reply-To: References: Message-ID: <20220201214753.GA25875@mcvoy.com> On Tue, Feb 01, 2022 at 03:34:53PM -0600, Will Senn wrote: > 2. Sokolov implies that the CSRG mission started going off the rails with > the 4.3/4.3BSD-Tahoe and it all went pear shaped with the 4.3-Reno release, > and that Quasijarus puts the mission back on track, is that so? I think the issue was that some of the core CSRG people went off to form BSDi to try and sell BSD on PCs. From treese at acm.org Wed Feb 2 07:50:49 2022 From: treese at acm.org (Win Treese) Date: Tue, 1 Feb 2022 16:50:49 -0500 Subject: [TUHS] ratfor vibe In-Reply-To: <20220201181909.6224518C086@mercury.lcs.mit.edu> References: <20220201181909.6224518C086@mercury.lcs.mit.edu> Message-ID: <65068AA0-BFEF-46B8-9068-2A24039371D3@acm.org> > On Feb 1, 2022, at 1:19 PM, Noel Chiappa wrote: > >> From: Clem Cole > >> So by the late 70s/early 80s, [except for MIT where LISP/Scheme reigned] > > Not quite. The picture is complicated, because outside the EECS department, > they all did their own thing - e.g. in the mid-70's I took a programming > intro couse in the Civil Engineering department which used Fortran. But in > EECS, in the mid-70's, their intro programming course used assembler > (PDP-11), Algol, and LISP - very roughly, a third of the time in each. Later > on, I think it used CLU (hey, that was MIT-grown :-). I think Scheme was used > later. In both of these cases, I have no idea if it was _only_ CLU/Scheme, or > if they did part of it in other languages. I took 6.001 (with Scheme) in the spring of 1983, which was using a course handout version of what became Structure and Interpretation of Computer Programs by Sussman and Abelson. My impression was that it had been around for a year before that, but not much more, and it was part of revamping the EECS core curriculum at the time. In at least the early 80s, CLU was used in 6.170, Software Engineering Laboratory, in which a big project was writing a compiler. And Fortran was still being taught for the other engineering departments. In 1982(ish), those departments had the Joint Computing Facility for a lot of their computing, of which the star then was a new VAX 11/782. - Win From chet.ramey at case.edu Wed Feb 2 08:04:17 2022 From: chet.ramey at case.edu (Chet Ramey) Date: Tue, 1 Feb 2022 17:04:17 -0500 Subject: [TUHS] BSD 4.1, 4.1x, Quasijarus, and 4.3x In-Reply-To: References: Message-ID: <1e78ebf7-476c-9a3c-76b2-2eb0a5d17dd6@case.edu> On 2/1/22 4:34 PM, Will Senn wrote: > 2. Sokolov implies that the CSRG mission started going off the rails with > the 4.3/4.3BSD-Tahoe and it all went pear shaped with the 4.3-Reno release, > and that Quasijarus puts the mission back on track, is that so? He seems to be saying that everything post-VAX was where the project lost its way. My recollection is that the switch from VAX to Tahoe was mostly driven by funding, hardware donations, and the Berkeley departments' and computing center's desire to move to the VAX 8000 series, which IIRC the CSRG was not prepared to support. (I'm a little fuzzy on the timing of that last piece.) -- ``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 crossd at gmail.com Wed Feb 2 08:18:29 2022 From: crossd at gmail.com (Dan Cross) Date: Tue, 1 Feb 2022 17:18:29 -0500 Subject: [TUHS] BSD 4.1, 4.1x, Quasijarus, and 4.3x In-Reply-To: References: Message-ID: On Tue, Feb 1, 2022 at 4:35 PM Will Senn wrote: > All, > > I did my research on this, but it's still a bit fuzzy (why is it that > people's memories from 40 years ago are so malleable?). > > 1. What are y'all's recollections regarding BSD 4.1's releases, vis a vis > the VAX. In McKusick's piece, Twenty Years of Berkeley Unix, I get one > perspective, and from Sokolov's Quasijarus project, I get quite another. In > terms of popularity and in terms of stable performance, what say you? Was > 4.1 that much better than 4BSD? Was 4.1as obsolete immediately as McKusick > says? 4.1b sounds good with FFS, was it? 4.1c's the last pre 4.2 release, > but it sounds like it was nearly a beta version of 4.2... > > 2. Sokolov implies that the CSRG mission started going off the rails with > the 4.3/4.3BSD-Tahoe and it all went pear shaped with the 4.3-Reno release, > and that Quasijarus puts the mission back on track, is that so? > Bluntly, no. Sokolov fell deeply into the nostalgia trap, and combined it with a revolutionary zeal that was off-putting at best. As far as I know, it was never more than one individual's project, and boasts of reclaiming the mantle of CSRG and BSD are grossly exaggerated. The world changed, and Unix moved in a different direction to accommodate; there's really no going back. 3. I've gotten BSD 4.2 and BSD 4.3 releases built from tape and working > very well. I just can't decide whether to go back to one of the 4.x > releases (hence question 1), or go get Quasijarus0c - thoughts on why one > might be more interesting than another? > Quasijarus is like 4.3 with some bug fixes and enhancements. If you want to run something like 4.3 in an emulator, it's not bad; I'm running it for a ham radio project (just for fun) and it's Y2K compliant and seems reliable. 4. Is Quasijarus0c end of the line for VAX 4.xBSD? Why does tuhs only have > Quasijarus0 and 0a, was there something wrong with 0b and 0c? > Well, no. Both OpenBSD and NetBSD ported back to the VAX, but the OpenBSD effort has ended due to lack of hardware and interest. It appears that NetBSD is still being actively developed on the VAX, however, so it's possible to get a "modern" 4.4BSD derived system on that architecture. 5. Has anyone unearthed an original 4.1 tape, or is Haertel's > reconstruction of the 1981 tape 1 release as close as it gets? > For the fifth time today this reminded me that I wanted to find my images from Kirk's CD collection and move them over to another machine. Sigh. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fair-tuhs at netbsd.org Wed Feb 2 08:30:14 2022 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Tue, 01 Feb 2022 14:30:14 -0800 Subject: [TUHS] ratfor vibe In-Reply-To: References: <20220201181909.6224518C086@mercury.lcs.mit.edu> Message-ID: <7660.1643754614@cesium.clock.org> With regard to programming languages at UCB in 1980 ... I'd done something of a survey of colleges, and in my mind at the time, there were two approaches to a CS degree: mostly or entirely theoretical (those CS departments that had grown out of Mathematics tended to have this focus), or more practical tools/techniques/operational theory (those CS departments that had grown out of Engineering tended to be this way). UCB was definitely the latter, and that's what I wanted. I got to UCB in fall 1980, admitted to the College of Letters & Science. At the time, there were two ways to get intro to programming: CS1 - FORTRAN IV, taught on the CDC 6400 running CalidoSCOPE in batch mode with real punch cards, punched up on IBM 029 keypunch machines. CS3 - Pascal, as Clem described. CS1 was for engineers & scientists, CS3 for students who wanted to get into the CS degree program in L&S. You could take CS1 in lieu of CS3, but that was frowned upon. Two paths to a computer science degree: A.B. CS from L&S, or B.S. EECS from the College of Engineering (which you had to be explicitly admitted to before you got there). There was a basic difference in emphasis between L&S and Engineering for CS: L&S was "software with a smattering of hardware" (cf. CS-150, CS-152), and Engineering's EECS (B.S.) degree was the inverse: "hardware with a smattering of software." L&S was the largest "college" at UCB: everyone got into that one "undeclared", and for your freshman & sophmore years, you studied to accumulate course credits towards declaring a major once you had "sophmore standing" (however, if you were prudent, you accumulated credits towards a "backup" major if the undergraduate degree program you wanted wouldn't/couldn't let you in). If you couldn't declare major at sophmore standing, you were bounced out of the university. Some of this setup was hangover from anti-student radical policies from the 1960s: prevent "students" from hanging around the university forever (and fomenting). The "weeder" course for L&S CS was CS40: more Pascal than you'd ever want to code in a lifetime. L&S CS needed that filter: just before I got there, they'd let anyone into the program, but in 1980 or 1981, they limited the class size to 200 undergrads because there was too much demand from students for that degree program for the department to handle - didn't make the cut? I hope you have a backup major ... They didn't formally teach C to undergrads until "upper division" (declared major in CS, junior or senior standing), and IIRC, there wasn't a formal course in it - you were expected to pick it up as part of the upper division course in operating systems. After all, you already know Pascal and Assembly, right? Of course, once you had an account on one of the PDP-11/70s running Unix, C and shell programming was entirely available to you, so I went for what amounted to self-directed learning (reading manuals & books) as fast as I could. Erik From cowan at ccil.org Wed Feb 2 09:12:56 2022 From: cowan at ccil.org (John Cowan) Date: Tue, 1 Feb 2022 18:12:56 -0500 Subject: [TUHS] ratfor vibe In-Reply-To: References: <20220201181909.6224518C086@mercury.lcs.mit.edu> Message-ID: On Tue, Feb 1, 2022 at 4:33 PM Clem Cole wrote: > My disagreement with them using scripting (python) as step one is the lack > of teaching data typing early > Teaching types is very important. But Python is strongly typed: a string is not a number is not a hashtable. When it's important for performance reasons or consistency across a large codebase, you can add static type information to your Python code without overloading n00b brains with mandatory type annotations. AND python's silly use space/tabs to set up structure instead of real {} > or B/E blocks. > Nobody would accept code that was incorrectly indented (although some languages have more than one indentation convention, like C) in an assignment or pull request. And when looking at correct or mostly correct code, we look at the indentation structure, not the braces. That being so, having both braces and indentation is fundamentally a DRY violation. Automatic data conversion has never been a good idea in my experience > because like many things that happen magically, it almost never works as > I expect. > I think it was a customer revolt that persuaded IBM to add "mixed-mode" expressions like "A + I" to Fortran IV; they had been disallowed in Fortran II. I haven't heard anyone saying we ought to revert that change. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Wed Feb 2 09:40:40 2022 From: ggm at algebras.org (George Michaelson) Date: Wed, 2 Feb 2022 09:40:40 +1000 Subject: [TUHS] BSD 4.1, 4.1x, Quasijarus, and 4.3x In-Reply-To: References: Message-ID: 4.2 was sockets. This was a huge change in network stack. It was also bust off the tape, we tried a unix domain socket binding and crashed the Vax. At that stage, we were using UUCP and cu heavily to do VMS-UNIX networking. When it settled down, much though I hated them, (I wanted the newcastle ... connection model to work, and then streams) sockets drove a lot of things. sockets became everything in some ways. the energy behind SunOS is NFS, and thats sockets. To me, noting some work on multi-core CPUs which fed into things, 4.3 onward is mostly about novel networking stacks. Its the side story to OS design, but the Van-Jacobsen work and related stuff by Sally Floyd, Alison Mankin and others looking into network dynamics and algorithms was huge. the IBM PC-RT became the fuzzball/BBN-Butterfly replacement in the NSFnet, run by Elise Gerich and others, Elise went on to be IANA after Jon Postel died. So the BSD-> IBM-PC/RT (BSD port) -> BGP story is huge in this. And .. It drives on sockets. BSD drove sockets drove NSFNet drove the explosive uptake of the network. Sockets sold machines. I don't entirely buy "off the rails" but I could believe the dynamic of the BSD workgroup and the surge in burden for not enough visible increment in benefit to Berkeley overall combined with the first pre-dotcom boom of Sun, Dec into the space probably drove people to seek salary and live outcomes better met in commerce. I didn't much get MT-XINU or the other breakout when the 386 port went live. an ISP I worked for used it, but frankly it was wierd. A Sun, pre Solaris was a more natural place to be for a BSD refugee. The dark side of this being Ingres. What happened there remains a bit shrouded to me, but I'm told a lot of dirty tricks went on. Kirk McKusick remained part of BSDs (V)FS story to this day. Others have become more occasional on the BSD lists but they are there, if they chose to remain silent, perhaps its because there's little upside to buying into the current debates. I didn't run BSD on any Vax after the 7 series, Maybe the effort to port to the later Vax-Cluster models was hard, but by then (looking backwards) DEC was already in Decline and Sun was spinning up to Solaris and the brave future of SYSV alignment hell. I had this wierd 2 floppy OS from some kid in northern europe, I mean FFS Andy Tannenbaum did tiny unix, who needs another one it doesn't have sockets it doesn't have anything. This linux thing will never work guys. We need more BSD. (worked out well, prognosticatiion-wise) DEC kind-of "got" networks but wierdly. They tried to sell UQueensland an entire campus of FDDI but we had to commit to buying 1000 linecards at a tiny discount. It was an insanely stupid idea. We stuck to thinwire and PCs with lightweight sockets stacks. Thats when two (2, I counted them) DECmate devices turned up and somebodys PA had to move over to them, hated them. The IBM Golfballs were much more heavily used. NetBSD, OpenBSD and FreeBSD can't agree on support for tabstop=4 and expandtabs in vi, and Python2 has just been deprecated EOL and Black rewrites tabs to 4 spaces. So I guess we can argue about that for some time yet. On Wed, Feb 2, 2022 at 7:35 AM Will Senn wrote: > > All, > > I did my research on this, but it's still a bit fuzzy (why is it that people's memories from 40 years ago are so malleable?). > > 1. What are y'all's recollections regarding BSD 4.1's releases, vis a vis the VAX. In McKusick's piece, Twenty Years of Berkeley Unix, I get one perspective, and from Sokolov's Quasijarus project, I get quite another. In terms of popularity and in terms of stable performance, what say you? Was 4.1 that much better than 4BSD? Was 4.1as obsolete immediately as McKusick says? 4.1b sounds good with FFS, was it? 4.1c's the last pre 4.2 release, but it sounds like it was nearly a beta version of 4.2... > > 2. Sokolov implies that the CSRG mission started going off the rails with the 4.3/4.3BSD-Tahoe and it all went pear shaped with the 4.3-Reno release, and that Quasijarus puts the mission back on track, is that so? > > 3. I've gotten BSD 4.2 and BSD 4.3 releases built from tape and working very well. I just can't decide whether to go back to one of the 4.x releases (hence question 1), or go get Quasijarus0c - thoughts on why one might be more interesting than another? > > 4. Is Quasijarus0c end of the line for VAX 4.xBSD? Why does tuhs only have Quasijarus0 and 0a, was there something wrong with 0b and 0c? > > 5. Has anyone unearthed an original 4.1 tape, or is Haertel's reconstruction of the 1981 tape 1 release as close as it gets? > > Later, > > Will From usotsuki at buric.co Wed Feb 2 09:54:39 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Tue, 1 Feb 2022 18:54:39 -0500 (EST) Subject: [TUHS] BSD 4.1, 4.1x, Quasijarus, and 4.3x In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022, Will Senn wrote: > 2. Sokolov implies that the CSRG mission started going off the rails with the > 4.3/4.3BSD-Tahoe and it all went pear shaped with the 4.3-Reno release, and > that Quasijarus puts the mission back on track, is that so? Wasn't he an anti-POSIX, anti-SysV zealot who thought the pre-rewrite BSD stuff was the Last Bastion of True Unix? At least that's the impression I've gotten from Quasijarus. -uso. From clemc at ccc.com Wed Feb 2 10:22:07 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 1 Feb 2022 19:22:07 -0500 Subject: [TUHS] BSD 4.1, 4.1x, Quasijarus, and 4.3x In-Reply-To: References: Message-ID: Dan/Will - I think we need the political way back machine ... below... On Tue, Feb 1, 2022 at 5:19 PM Dan Cross wrote: > On Tue, Feb 1, 2022 at 4:35 PM Will Senn wrote: > >> All, >> >> I did my research on this, but it's still a bit fuzzy (why is it that >> people's memories from 40 years ago are so malleable?). >> >> 1. What are y'all's recollections regarding BSD 4.1's releases, vis a vis >> the VAX. In McKusick's piece, Twenty Years of Berkeley Unix, I get one >> perspective, and from Sokolov's Quasijarus project, I get quite another. In >> terms of popularity and in terms of stable performance, what say you? Was >> 4.1 that much better than 4BSD? >> > Yes but you need to understand the politics. ARPA had been supplying 16/36 PDP-6/10s to the research community with BBN, MIT, Stanford and CMU sort of being the prime places. The compilers mostly were the same (close enough) although the OS's (user interfaces) were all different. Tenex vs. ITS vs. WAITS vs. TOPS (sort of). People forget that the real reason it happened was that UCB had a contract to get Maxima running on a Vax for DARPA [this work would begat 3BSD]. Only after that, did DARPA switch to the 32 bit vax as the system of choice. Stanford wanted VMS and mostly everyone else wanted UNIX. But DEC did not support UNIX. So ... ARPA funded CSRG to support UNIX for the ARPA contracts. But remember CSRG did not have everything - just a support contact [which raised a lot of hackels both inside and outside of UCB]. For instance networking for UNIX was at BBN not UCB. And all of CMU, Stanford and MIT had ARPA $s for basic OS research and other ideas. The Stanford crew tried to show that VMS was faster than 4BSD. Joy famously did the 'FASTVAX' work over a period oa 6-8 weeks and got UNIX within epsilon of VMS on almost everything and actually faster in a number of places. This would become 4.1 - add it was the version that most people that had vaxen started to use. > Was 4.1as obsolete immediately as McKusick says? >> > Well yes in that very few systems ran it. It was Joy's first attempt at creating sockets. I'm probably not being fair, but it was the BBN stack hacked to have a new interface. I ran it on UCBCAD and Sam probably had it running on 5-10 750s in Evans. I thought it got sent to a few sites outside of UCB, but 4.1B was pretty close behind. > 4.1b sounds good with FFS, was it? >> > Hmm, you'd have to check the sources. I thought Kirk had FFS running with 4.1a --- but maybe not. > 4.1c's the last pre 4.2 release, but it sounds like it was nearly a beta >> version of 4.2... >> > Hmm, not so much a release candidate as a test vehicle. Beta is probably a good term for it. 4.2 was not ready when I finished so I brought 4.1c with me to Masscomp - which is what we started with for the networking code. It was what we added MP support to and then added 4.2 fixes when it came out. But 4.1c was breaking a lot of user mode code and so 4.2 really did not go out until they had caught most of the issues. > >> >> 2. Sokolov implies that the CSRG mission started going off the rails with >> the 4.3/4.3BSD-Tahoe >> > Not really. A few things happened. First manufacturers (including DEC) were now supporting UNIX so DARPA no longer felt they needed to fund support. You could buy a computer and system vendor made work. Second as I said, there were people inside of the EECS Dept at UCB that felt that CSRG was turning the department away from research and they needed to reclaim that. And third as others have suggested, Joy went to Sun, and a number of the others formed BSDi. Kirk was still there and there was still some work going on, but it was nothing like it was. The net result was the desire to keep going was lost, less than going off the rails. It just did not have the same people, the same money and as such, the same effort. > and it all went pear shaped with the 4.3-Reno release, and that Quasijarus >> puts the mission back on track, is that so? >> > > Bluntly, no. Sokolov fell deeply into the nostalgia trap, and combined it > with a revolutionary zeal that was off-putting at best. As far as I know, > it was never more than one individual's project, and boasts of reclaiming > the mantle of CSRG and BSD are grossly exaggerated. The world changed, and > Unix moved in a different direction to accommodate; there's really no going > back. > Amen -- I can add little to that. > > 3. I've gotten BSD 4.2 and BSD 4.3 releases built from tape and working >> very well. I just can't decide whether to go back to one of the 4.x >> releases (hence question 1), or go get Quasijarus0c - thoughts on why one >> might be more interesting than another? >> > > Quasijarus is like 4.3 with some bug fixes and enhancements. If you want > to run something like 4.3 in an emulator, it's not bad; I'm running it for > a ham radio project (just for fun) and it's Y2K compliant and seems > reliable. > Then again, if the idea is running BSD on a Vax, Ultrix 4.5 is even better, and has all the DEC languages and layered products. > > 4. Is Quasijarus0c end of the line for VAX 4.xBSD? Why does tuhs only have >> Quasijarus0 and 0a, was there something wrong with 0b and 0c? >> > > Well, no. Both OpenBSD and NetBSD ported back to the VAX, but the OpenBSD > effort has ended due to lack of hardware and interest. It appears that > NetBSD is still being actively developed on the VAX, however, so it's > possible to get a "modern" 4.4BSD derived system on that architecture. > Right - either current NetBSD or the Ultrix 4.5 is what I would do. If NetBSD will run the Ultrix layered products, that would be the system with the most; but I'm not sure if that will work. Ultrix for instance supports DEC (VMS) FTN - which I know you (Will) have been messing with. That is the best (most complete) FTN for Vaxen. I believe there is Ada, PL/1 and maybe even Basic2 and Cobol/RPG [I think most of not all of the VMS languages for the VAX were released on Ultrix but frankly, I don't remember]. > 5. Has anyone unearthed an original 4.1 tape, or is Haertel's >> reconstruction of the 1981 tape 1 release as close as it gets? >> > > For the fifth time today this reminded me that I wanted to find my images > from Kirk's CD collection and move them over to another machine. Sigh.' > 😎 -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Wed Feb 2 10:38:36 2022 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 2 Feb 2022 11:38:36 +1100 Subject: [TUHS] BSD 4.1, 4.1x, Quasijarus, and 4.3x In-Reply-To: <20220201214753.GA25875@mcvoy.com> Message-ID: <20220202003836.GE17267@eureka.lemis.com> On Tuesday, 1 February 2022 at 15:34:53 -0600, Will Senn wrote: > All, > > I did my research on this, but it's still a bit fuzzy (why is it that > people's memories from 40 years ago are so malleable?). > > 1. What are y'all's recollections regarding BSD 4.1's releases, vis a > vis the VAX. In McKusick's piece, Twenty Years of Berkeley Unix, I get > one perspective, and from Sokolov's Quasijarus project, I get quite > another. Kirk was there the whole time, from far earlier until the end of the CSRG. Sokolov came later, and to my recollection he wasn't involved in core BSD at all. I don't have any personal recollections of the time, but it seems clear who is more plausible. > 5. Has anyone unearthed an original 4.1 tape, or is Haertel's > reconstruction of the 1981 tape 1 release as close as it gets? Clearly this is beyond what is on the 4 CD set, right? That tree contains a file TAPE with the comments (inter alia) Extracted from two 4.1BSD distribution tapes dated 7/10/81. First label on the tape: 4.1bsd VAX UNIX System 7/10/81 5 files on tape: 1 (boot stuff) 2 (root dump) 3 (/usr) 4 (/usr/src) 5(4.0/4.1) last three are tar; 1600 bpi But presumably you know that. Was this the Haertel reconstruction you mention? On Tuesday, 1 February 2022 at 13:47:53 -0800, Larry McVoy wrote: > On Tue, Feb 01, 2022 at 03:34:53PM -0600, Will Senn wrote: >> 2. Sokolov implies that the CSRG mission started going off the rails with >> the 4.3/4.3BSD-Tahoe and it all went pear shaped with the 4.3-Reno release, >> and that Quasijarus puts the mission back on track, is that so? > > I think the issue was that some of the core CSRG people went off to > form BSDi to try and sell BSD on PCs. BSDI came later, and the founders weren't CSRG people, though some CSRG people did join the company. I think the real issue was that CSRG no longer had a purpose: the research aspect was over and done with, and the funding dried up. 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.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From ylee at columbia.edu Wed Feb 2 10:54:39 2022 From: ylee at columbia.edu (Yeechang Lee) Date: Tue, 1 Feb 2022 16:54:39 -0800 Subject: [TUHS] ratfor vibe In-Reply-To: <7660.1643754614@cesium.clock.org> References: <20220201181909.6224518C086@mercury.lcs.mit.edu> <7660.1643754614@cesium.clock.org> Message-ID: <25081.54863.862763.202747@dobie-old.ylee.org> Erik E. Fair says: > With regard to programming languages at UCB in 1980 ... > > I'd done something of a survey of colleges, and in my mind at the > time, there were two approaches to a CS degree: mostly or entirely > theoretical (those CS departments that had grown out of Mathematics > tended to have this focus), or more practical > tools/techniques/operational theory (those CS departments that had > grown out of Engineering tended to be this way). Quoting my 2019 message to the cctech mailing list: ---- Adam Thornton says: > The genealogy of Computer Science departments (and their curricula) > (at least in the US) is also weird and historically-contingent. > Basically it seems to have been a tossup at any given school whether > it came out of the Electr[ical|onic] Engineering department, in > which case it was memories and logic gates and a bottom-up, > hardware-focused curriculum, or out of the Mathematics department, > in which case it was algorithms and complexity analysis and a > software-focused curriculum. Yes, I've noticed the same thing. Example: Harvard's CS department is originally from the math side, while MIT's is from EE (thus today's EECS). Berkeley = EE Brown = Math BYU = Math Caltech = EE Columbia = EE Cornell = Operations research, math Dartmouth = Math Illinois = Math NYU = Both (because Polytechnic developed its own CS program long before NYU acquired it to regain an engineering school) Penn = EE UCLA = OR (probably because of the RAND heritage) Caltech until very recently did not formally offer CS degrees; students received degrees in Engineering and Applied Science, with a focus on CS (or aeronautics, or civil, or ME). Illinois is an example of a track we might call "other" or even "defense". With government funding the university built its own computers (including ILLIAC and PLATO), and the group that did so became the CS department, but the undergraduate CS program began within the math department. Harvard's and Penn's programs might also qualify. Undergraduate CS degrees are BA (Example: Harvard), BS (Example: Penn), or both (Example: Columbia). At Penn one must be an engineering student to major in CS. At Columbia one can major in CS in either the liberal arts or engineering schools, but with different curriculums. At Yale there is one undergraduate school, within which one can receive a BA or BS in CS, with different curriculums. Cornell, Northwestern, and Berkeley offer CS in their separate liberal arts and engineering schools; undergraduates receive BA or BS degrees with identical CS curriculums, with only other requirements differing. I've read that medical schools are good at teaching either pharmacology (drugs), or pathology (diseases); perhaps this is also because of the expertise/specialty of their early faculty members. ---- > Two paths to a computer science degree: A.B. CS from L&S, or > B.S. EECS from the College of Engineering (which you had to be > explicitly admitted to before you got there). Still true today. As I mention above, Berkeley's CS curriculum is identical regardless of the degree (or was the last time I checked), something not always true at other universities that offer multiple CS undergraduate degree options. -- geo:37.783333,-122.416667 From web at loomcom.com Wed Feb 2 11:02:05 2022 From: web at loomcom.com (Seth Morabito) Date: Tue, 01 Feb 2022 17:02:05 -0800 Subject: [TUHS] BSD 4.1, 4.1x, Quasijarus, and 4.3x In-Reply-To: References: Message-ID: <47c39383-eca8-4ba4-9f39-731962588d18@www.fastmail.com> On Tue, Feb 1, 2022, at 1:34 PM, Will Senn wrote: > All, > > I did my research on this, but it's still a bit fuzzy (why is it that people's memories from 40 years ago are so malleable?). > > 1. What are y'all's recollections regarding BSD 4.1's releases, vis a vis the VAX. In McKusick's piece, Twenty Years of Berkeley Unix, I get one perspective, and from Sokolov's Quasijarus project, I get quite another. In terms of popularity and in terms of stable performance, what say you? Was 4.1 that much better than 4BSD? Was 4.1as obsolete immediately as McKusick says? 4.1b sounds good with FFS, was it? 4.1c's the last pre 4.2 release, but it sounds like it was nearly a beta version of 4.2... > > 2. Sokolov implies that the CSRG mission started going off the rails with the 4.3/4.3BSD-Tahoe and it all went pear shaped with the 4.3-Reno release, and that Quasijarus puts the mission back on track, is that so? My recollection from 1997 or 1998 is that Sokolov appeared out of nowhere, alone, with (as someone else in this thread best put it) a "revolutionary zeal", and decided to create Quasijarus with the specific goal of supporting VAXen beyond the models that had been originally supported under 4.2. Sokolov was 18 or 19 at the time, so I can certainly understand the revolutionary zeal (I miss mine!). Beyond that, I don't think anything else ever came out of it. -Seth -- Seth Morabito Poulsbo, WA web at loomcom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at anduin.eldar.org Wed Feb 2 10:43:59 2022 From: brad at anduin.eldar.org (Brad Spencer) Date: Tue, 01 Feb 2022 19:43:59 -0500 Subject: [TUHS] BSD 4.1, 4.1x, Quasijarus, and 4.3x In-Reply-To: (message from Clem Cole on Tue, 1 Feb 2022 19:22:07 -0500) Message-ID: Clem Cole writes: [snip] >> Well, no. Both OpenBSD and NetBSD ported back to the VAX, but the OpenBSD >> effort has ended due to lack of hardware and interest. It appears that >> NetBSD is still being actively developed on the VAX, however, so it's >> possible to get a "modern" 4.4BSD derived system on that architecture. >> > Right - either current NetBSD or the Ultrix 4.5 is what I would do. If > NetBSD will run the Ultrix layered products, that would be the system with > the most; but I'm not sure if that will work. Ultrix for instance > supports DEC (VMS) FTN - which I know you (Will) have been messing with. > That is the best (most complete) FTN for Vaxen. I believe there is Ada, > PL/1 and maybe even Basic2 and Cobol/RPG [I think most of not all of the > VMS languages for the VAX were released on Ultrix but frankly, I don't > remember]. [snip] NetBSD has a compat_ultrix that can be enabled for NetBSD/vax (and pmax / mips) that might allow some of those products to work. The man page for it does not mention any of that specifically and does say that there are a few limits to it. https://man.netbsd.org/compat_ultrix.8 -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From will.senn at gmail.com Wed Feb 2 11:19:24 2022 From: will.senn at gmail.com (Will Senn) Date: Tue, 1 Feb 2022 19:19:24 -0600 Subject: [TUHS] BSD 4.1, 4.1x, Quasijarus, and 4.3x In-Reply-To: References: Message-ID: <328d0bc1-b4b4-4693-ea2c-f7780410dbeb@gmail.com> On 2/1/22 6:43 PM, Brad Spencer wrote: > Clem Cole writes: > > [snip] > >>> Well, no. Both OpenBSD and NetBSD ported back to the VAX, but the OpenBSD >>> effort has ended due to lack of hardware and interest. It appears that >>> NetBSD is still being actively developed on the VAX, however, so it's >>> possible to get a "modern" 4.4BSD derived system on that architecture. >>> >> Right - either current NetBSD or the Ultrix 4.5 is what I would do. If >> NetBSD will run the Ultrix layered products, that would be the system with >> the most; but I'm not sure if that will work. Ultrix for instance >> supports DEC (VMS) FTN - which I know you (Will) have been messing with. >> That is the best (most complete) FTN for Vaxen. I believe there is Ada, >> PL/1 and maybe even Basic2 and Cobol/RPG [I think most of not all of the >> VMS languages for the VAX were released on Ultrix but frankly, I don't >> remember]. > [snip] > > NetBSD has a compat_ultrix that can be enabled for NetBSD/vax (and pmax > / mips) that might allow some of those products to work. The man page > for it does not mention any of that specifically and does say that there > are a few limits to it. > > https://man.netbsd.org/compat_ultrix.8 > I tried an install of netbsd latest on simh microvax a few weeks back and it installed without error. It was slow to boot to login, but I'm sure that's just the network being misconfigured somehow, I haven't had time to troubleshoot - let's just call it pilot error. From will.senn at gmail.com Wed Feb 2 11:30:54 2022 From: will.senn at gmail.com (Will Senn) Date: Tue, 1 Feb 2022 19:30:54 -0600 Subject: [TUHS] BSD 4.1, 4.1x, Quasijarus, and 4.3x In-Reply-To: References: Message-ID: On 2/1/22 4:18 PM, Dan Cross wrote: > snip... > > For the fifth time today this reminded me that I wanted to find my > images from Kirk's CD collection and move them over to another > machine. Sigh. > >         - Dan C. > > Having the CD's handy is very handy :) I usually mount the iso and build pdfs of the docs I'm interested, in or view source code or whatever: hdiutil mount "~/_workarea/_retro-resources/bits/csrg/The CSRG Archives CD-ROM 1 (August 1998) (Marshall Kirk McKusick).ISO" cd /Volumes/CDROM/4.2/usr/doc/setup eqn *.t | tbl | groff -Tps -ms > ~/Desktop/setup.ps ps2pdf ~/Desktop/setup.ps open ~/Desktop/setup.pdf I bought my copy back when from: https://www.mckusick.com/csrg/index.html Now they're conveniently hosted on archive.org. Here's the first cd as downloadable iso: https://archive.org/details/The_CSRG_Archives_CD-ROM_1_August_1998_Marshall_Kirk_McKusick Kirk's fine with them being hosted there, by the way. But, having the actual CD's are great in case of the apocalypse :). Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Wed Feb 2 11:35:27 2022 From: will.senn at gmail.com (Will Senn) Date: Tue, 1 Feb 2022 19:35:27 -0600 Subject: [TUHS] BSD 4.1, 4.1x, Quasijarus, and 4.3x In-Reply-To: References: Message-ID: <716d5149-77bf-6149-1d81-b3a89250704a@gmail.com> On 2/1/22 6:22 PM, Clem Cole wrote: > Dan/Will - I think we need the political way back machine ...  below... > That's a lot of history. Thanks. Always with the money, I thought it was strictly altruism that drove the pioneers :). > Then again, if the idea is running BSD on a Vax, Ultrix 4.5 is even > better, and has all the DEC languages and layered products. Wow. I will dig into this. I like the layered stuff. I thought you had to do RT11/RSTSE/TOPS/etc to have that. I had no idea it was available on a *nix platform. > > 4. Is Quasijarus0c end of the line for VAX 4.xBSD? Why does > tuhs only have Quasijarus0 and 0a, was there something wrong > with 0b and 0c? > > > Well, no. Both OpenBSD and NetBSD ported back to the VAX, but the > OpenBSD effort has ended due to lack of hardware and interest. It > appears that NetBSD is still being actively developed on the VAX, > however, so it's possible to get a "modern" 4.4BSD derived system > on that architecture. > > Right - either current NetBSD or the Ultrix 4.5 is what I would do.  > If NetBSD will run the Ultrix layered products, that would be the > system with the most; but I'm not sure if that will work.   Ultrix for > instance supports DEC (VMS) FTN - which I know you (Will) have been > messing with.   That is the best (most complete) FTN for Vaxen.  I > believe there is Ada, PL/1 and maybe even Basic2 and Cobol/RPG [I > think most of not all of the VMS languages for the VAX were released > on Ultrix but frankly, I don't remember]. Sweet. Off to hunt down Ultrix 4.5 :). Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Wed Feb 2 13:02:46 2022 From: rminnich at gmail.com (ron minnich) Date: Tue, 1 Feb 2022 19:02:46 -0800 Subject: [TUHS] CSRG at berkeley Message-ID: the discussion of why the CSRG disbanded in 1995 has come up elsewhere. My memory is that the reason was pretty simple: DARPA ended their funding at that time. Hoping for corrections to my memory :-) From clemc at ccc.com Wed Feb 2 14:02:49 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 1 Feb 2022 23:02:49 -0500 Subject: [TUHS] CSRG at berkeley In-Reply-To: References: Message-ID: On Tue, Feb 1, 2022 at 10:03 PM ron minnich wrote: > the discussion of why the CSRG disbanded in 1995 has come up elsewhere. > > My memory is that the reason was pretty simple: DARPA ended their > funding at that time. > > Hoping for corrections to my memory :-) > That’s pretty much it although they did have some alternative funds and equipment grants that helped keep them going. How long it could have been sustained without ARPA is not known. There was pressure inside of UCB to shut it down. -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From nobozo at gmail.com Wed Feb 2 14:18:11 2022 From: nobozo at gmail.com (Jon Forrest) Date: Tue, 1 Feb 2022 20:18:11 -0800 Subject: [TUHS] CSRG at berkeley In-Reply-To: References: Message-ID: Although not directly related to CSRG, there's an interesting piece of Unix history at Berkeley recounted in http://ucbvax.berkeley.edu/passing-of-ucbvax.txt I was there. Jon From fair-tuhs at netbsd.org Wed Feb 2 14:30:42 2022 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Tue, 01 Feb 2022 20:30:42 -0800 Subject: [TUHS] CSRG at berkeley In-Reply-To: References: Message-ID: <21873.1643776242@cesium.clock.org> Date: Tue, 1 Feb 2022 20:18:11 -0800 From: Jon Forrest Subject: Re: [TUHS] CSRG at berkeley Although not directly related to CSRG, there's an interesting piece of Unix history at Berkeley recounted in http://ucbvax.berkeley.edu/passing-of-ucbvax.txt I was there. Jon As was I. Erik From athornton at gmail.com Wed Feb 2 14:53:50 2022 From: athornton at gmail.com (Adam Thornton) Date: Tue, 1 Feb 2022 21:53:50 -0700 Subject: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> <9E47A62E-3AAD-491E-9164-3DCAD22EC1F7@kdbarto.org> <71ce6652-cf15-44db-01df-62ab89a5a134@gmail.com> Message-ID: On Mon, Jan 31, 2022 at 10:17 AM Paul Winalski wrote: > On 1/30/22, Steve Nickolas wrote: > > And I think I've heard the Infocom compilers' bytecode called "Z-code" (I > > use this term too). > That is correct. The Infocom games ran on an interpreter for an > abstract machine called the Z-machine. Z-code is the Z-machine's > instruction set. There is a freeware implementation out there called > Frotz. > > There's a reasonably functional Frotz implementation for TOPS-20, as it happens. The ZIP interpreter was easier to port to 2.11BSD on the PDP-11. https://github.com/athornton/tops20-frotz Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Wed Feb 2 15:30:27 2022 From: rminnich at gmail.com (ron minnich) Date: Tue, 1 Feb 2022 21:30:27 -0800 Subject: [TUHS] CSRG at berkeley In-Reply-To: <21873.1643776242@cesium.clock.org> References: <21873.1643776242@cesium.clock.org> Message-ID: I should have asked the other question: when did DARPA funding start? On Tue, Feb 1, 2022, 8:31 PM Erik E. Fair wrote: > > Date: Tue, 1 Feb 2022 20:18:11 -0800 > From: Jon Forrest > Subject: Re: [TUHS] CSRG at berkeley > > Although not directly related to CSRG, there's an interesting > piece of Unix history at Berkeley recounted in > > http://ucbvax.berkeley.edu/passing-of-ucbvax.txt > > I was there. > > Jon > > > As was I. > > Erik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Feb 2 17:47:29 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 02 Feb 2022 00:47:29 -0700 Subject: [TUHS] ratfor vibe In-Reply-To: <20220201155225.5A9541FB21@orac.inputplus.co.uk> References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> Message-ID: <202202020747.2127lTTh005669@freefriends.org> Ralph Corderoy wrote: > Hi Arnold, > > > In ~ 1981, Kernighan and Plauger rewrote the tools in Pascal and redid > > the book to go with it. This is > > https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan/dp/0201103427/ > > which I also recommend getting a copy of. > > I agree the original Software Tools is a must read, but having done so, > why would I suffer working through the hurdles put in place by Pascal > compared to Ratfor? I never bothered so your recommendation makes me > wonder what I missed. I did read Kernighan's ‘not my favourite’ > and took from that I wouldn't enjoy the Pascal book given I'd read > the original. > > -- > Cheers, Ralph. As others mentioned, recursion and real data structures make code easier to read. They also refined the text some. But in general, I think the principle of "ANYTHING written by Brian Kernighan is worth reading, at least once" applies, even in this case. FWIW, Brian has told me more than once that he wishes they'd done "Software Tools In C" instead of in Pascal, and that the Pascal book was a failure to read the market correctly. Long ago, I once dreamed that I found "Software Tools In C" in a bookstore; the cover had green lettering instead of the red and blue used in the real books. I was sorta disappointed when I woke up... :-) HTH, Arnold From rosenfeld at grumpf.hope-2000.org Wed Feb 2 20:28:01 2022 From: rosenfeld at grumpf.hope-2000.org (Hans Rosenfeld) Date: Wed, 2 Feb 2022 11:28:01 +0100 Subject: [TUHS] BSD 4.1, 4.1x, Quasijarus, and 4.3x In-Reply-To: References: Message-ID: On Tue, Feb 01, 2022 at 03:34:53PM -0600, Will Senn wrote: > 2. Sokolov implies that the CSRG mission started going off the rails with > the 4.3/4.3BSD-Tahoe and it all went pear shaped with the 4.3-Reno release, > and that Quasijarus puts the mission back on track, is that so? Well, thats just his opinion. You can still read all about it here: https://ifctfvax.superglobalmegacorp.com/ > 3. I've gotten BSD 4.2 and BSD 4.3 releases built from tape and working very > well. I just can't decide whether to go back to one of the 4.x releases > (hence question 1), or go get Quasijarus0c - thoughts on why one might be > more interesting than another? IIRC 4.3-Tahoe was the first to support running on MicroVAX II, III and later systems based on the CVAX chip and the QBus. But getting it installed on one of these was a pain to say the least. The main reason was that it required the use of disk labels on the directly-attached MSCP disks commonly found on these systems, but it lacked a standalone utility for creating them during installation. >From my recollection Michael made a few small improvements to what he found in 4.3-Tahoe, and a standalone disklabel utility may or may not have been one of them. I do remember that when I first installed 4.3-Tahoe (Or was it Quasijarus 0b?) on a real MicroVAX II about 20 years ago, I had to create the disklabels with NetBSD 1.5, which apparently were still reasonably compatible back then. > 4. Is Quasijarus0c end of the line for VAX 4.xBSD? Why does tuhs only have > Quasijarus0 and 0a, was there something wrong with 0b and 0c? It's basically just yet another branch off the Unix family tree, originating at 4.3BSD-Tahoe and not going very far. He had big plans to support most later MicroVAX models, but apparently that never materialized. Hans -- %SYSTEM-F-ANARCHISM, The operating system has been overthrown From crossd at gmail.com Thu Feb 3 01:16:27 2022 From: crossd at gmail.com (Dan Cross) Date: Wed, 2 Feb 2022 10:16:27 -0500 Subject: [TUHS] CSRG at berkeley In-Reply-To: References: <21873.1643776242@cesium.clock.org> Message-ID: On Wed, Feb 2, 2022 at 12:31 AM ron minnich wrote: > I should have asked the other question: when did DARPA funding start? > Salus's "25 Years of Unix" book covers this, and I was surprised to find it available here: https://wiki.tuhs.org/lib/exe/fetch.php?media=publications:qcu.pdf Pages 159-160 or so talks about this: it says the DARPA money appeared in 1980? - Dan C. On Tue, Feb 1, 2022, 8:31 PM Erik E. Fair wrote: > >> >> Date: Tue, 1 Feb 2022 20:18:11 -0800 >> From: Jon Forrest >> Subject: Re: [TUHS] CSRG at berkeley >> >> Although not directly related to CSRG, there's an interesting >> piece of Unix history at Berkeley recounted in >> >> http://ucbvax.berkeley.edu/passing-of-ucbvax.txt >> >> I was there. >> >> Jon >> >> >> As was I. >> >> Erik >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 3 01:28:21 2022 From: clemc at ccc.com (Clem Cole) Date: Wed, 2 Feb 2022 10:28:21 -0500 Subject: [TUHS] CSRG at berkeley In-Reply-To: References: <21873.1643776242@cesium.clock.org> Message-ID: On Wed, Feb 2, 2022 at 12:31 AM ron minnich wrote: > I should have asked the other question: when did DARPA funding start? > Sort of hard to count properly. DARA funded more than just CSRG. The first DARPA money associated with large address work was in 1980 for the Vax version of Maxima, although there might have been some other projects before that. But the CSRG project had not (yet) started when I arrived in Fall of '81, although the Stanford bake-off had and 4.1BSD was on the street - as Joy had done the FASTVAX work earlier than spring/summer. At that point there were two 780s for CS in Evan Halls (Ernie and Kim). The 'Vaxima' port was working and I believe that the first Franz-LISP release was out. FWIW: The CAD group had just gotten its first in Cory which was funded by the DEC/HP/IBM and some of the Si manufacturers. I believe that Ingress was still an 11/70, but I would defer to Eric on that - I'm not sure who/what was their funding source, although they had the original ARPAnet connection via a VDHI to LBL, so DARPA must have been involved. The C30 IMP (for CSRG) did not arrive in Evans until at least mid 82, I think maybe '83. So by 1981/82 the question of how UNIX (as a system) was going to be supported for the ARPA contractors had become a ripe concern. It must have been proposed by then and being negotiated. IIRC Prof Fabrey was officially the PI for what would become CSRG, but some one like Eric or Mary Ann who was already there before me might have more information on the politics -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Thu Feb 3 01:47:57 2022 From: rminnich at gmail.com (ron minnich) Date: Wed, 2 Feb 2022 07:47:57 -0800 Subject: [TUHS] CSRG at berkeley In-Reply-To: References: <21873.1643776242@cesium.clock.org> Message-ID: that's still an amazing run for DARPA funding. I suppose that aligns with the reign of Steve Squires. On Wed, Feb 2, 2022 at 7:28 AM Clem Cole wrote: > > > > On Wed, Feb 2, 2022 at 12:31 AM ron minnich wrote: >> >> I should have asked the other question: when did DARPA funding start? > > Sort of hard to count properly. DARA funded more than just CSRG. The first DARPA money associated with large address work was in 1980 for the Vax version of Maxima, although there might have been some other projects before that. But the CSRG project had not (yet) started when I arrived in Fall of '81, although the Stanford bake-off had and 4.1BSD was on the street - as Joy had done the FASTVAX work earlier than spring/summer. At that point there were two 780s for CS in Evan Halls (Ernie and Kim). The 'Vaxima' port was working and I believe that the first Franz-LISP release was out. FWIW: The CAD group had just gotten its first in Cory which was funded by the DEC/HP/IBM and some of the Si manufacturers. I believe that Ingress was still an 11/70, but I would defer to Eric on that - I'm not sure who/what was their funding source, although they had the original ARPAnet connection via a VDHI to LBL, so DARPA must have been involved. The C30 IMP (for CSRG) did not arrive in Evans until at least mid 82, I think maybe '83. > > So by 1981/82 the question of how UNIX (as a system) was going to be supported for the ARPA contractors had become a ripe concern. It must have been proposed by then and being negotiated. IIRC Prof Fabrey was officially the PI for what would become CSRG, but some one like Eric or Mary Ann who was already there before me might have more information on the politics From will.senn at gmail.com Thu Feb 3 14:00:21 2022 From: will.senn at gmail.com (Will Senn) Date: Wed, 2 Feb 2022 22:00:21 -0600 Subject: [TUHS] ratfor vibe In-Reply-To: References: Message-ID: On 1/31/22 2:46 PM, Will Senn wrote: > All, > > I have been doing some language exploration in v7/4.3bsd and came > across Software Tools (not the pascal version). It's written using > ratfor, which I had seen in the v7 UPM. I fired up v7 and tried my > hand at the first example: I thought I'd close the loop on the language side of this thread. I am happy to report that ratfor (and fortran) is alive and well. It works on my mac! The Software Tools book is awesome, if challenging. The first chapter is particularly challenging as it takes a bit to figure out where the authors are coming from and what they include, exclude, and highlight... and why. The key to understanding the book, as a modern reader, is to understand that the authors assume their readers are fortran (or PL/I) programmers.  Because of this, they don't explain anything that would be obvious to said programmers (read, write, LUNs, Hollerith cards, format, etc). In addition, they will push down details of implementation until they practically disappear (think singularity... annoyingly consistent in this regard). When they say something like "EOF is a symbolic constant... We won't tell you what its value is, since the particular value doesn't matter", they really mean it. Unfortunately, in order to actually implement stuff, you gotta know what every symbolic constant and macro replacement is :). For example, even in the tiny copy program example, from the introductory chapter, once you include the primitive getc and putc subroutines, there are 7 symbolic constants: MAXLINE, MAXCARD, NEWLINE, STDIN, STDOUT, EOF, SPACE and character, which is really an integer and gets replaced with integer by some mythical preprocessor (chapter 8). Anyhow, in the modern world, MAXLINE and MAXCARD don't really have meaning, but they can magically be treated as lines of a file, the rest do have meaning, but they don't evaluate to the same things in Fortran-land as in modern-land. STDIN is 5 and STDOUT is 6 (card reader and punch LUNs, again some magic that lets them be treated as terminal input and output),  EOF is -1, SPACE is 32, NEWLINE is 10. Anyhow, long story just a bit shorter, replace those constants, swap character for integer, and combine getc, putc, and copy and yahoo, a working copy program that works in v7, 4.xBSD, and Mac OS X Mojave (and BSD, etc), without any further modifications... at all. Included for the curioius (copynew.r): # on v7 # $ ratfor -C copynew.r > copynew.f # $ f77 -o copynew copynew.f # on mac # $ ratfor77 -C copynew.r > copynew.f # $ gfortran -o copynew copynew.f # $ ./copynew # This is a test. # This is a test. # CTRL-d # $ # getc (simple version) - get characters from standard input         integer function getc(c)         integer buf(81), c         integer i, lastc         data lastc /81/,buf(81) /10/         lastc = lastc + 1         if(lastc > 81) {                 read(5, 100, end=10) (buf(i), i = 1, 80)                         100 format(80 a 1)                 lastc = 1                 }         c = buf(lastc)         getc = c         return 10      c = -1         getc = -1         return         end # putc (simple version) - put characters on the standard output         subroutine putc(c)         integer buf(80), c         integer i, lastc         data lastc /0/         if (lastc > 80 | c == 10) {                 for (i = lastc + 1; i <= 80; i = i + 1)                         buf(i) = 32                 write(6, 100) (buf(i), i = 1, 80)                         100 format(80 a 1)                 lastc = 0                 }         if (c != 10) {                 lastc = lastc + 1                 buf(lastc) = c                 }         return         end # copy - copy input characters to output         integer getc         integer c         while(getc(c) != -1)                 call putc(c)         stop         end Of course, it's criminal to have all those hardcoded magic numbers, wouldn't it be swell if there were some sort of macro facility?... oh, wait, that's what Chapter 8's all about... I can't wait. Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Thu Feb 3 14:31:04 2022 From: aek at bitsavers.org (Al Kossow) Date: Wed, 2 Feb 2022 20:31:04 -0800 Subject: [TUHS] ratfor vibe In-Reply-To: References: Message-ID: <8a369501-eb51-d07c-fa31-d27e7eb31d71@bitsavers.org> On 2/2/22 8:00 PM, Will Senn wrote: > Of course, it's criminal to have all those hardcoded magic numbers Graybeards chucking at the follies of youth. From imp at bsdimp.com Thu Feb 3 15:16:05 2022 From: imp at bsdimp.com (Warner Losh) Date: Wed, 2 Feb 2022 22:16:05 -0700 Subject: [TUHS] ratfor vibe In-Reply-To: <8a369501-eb51-d07c-fa31-d27e7eb31d71@bitsavers.org> References: <8a369501-eb51-d07c-fa31-d27e7eb31d71@bitsavers.org> Message-ID: On Wed, Feb 2, 2022, 9:37 PM Al Kossow wrote: > On 2/2/22 8:00 PM, Will Senn wrote: > > > Of course, it's criminal to have all those hardcoded magic numbers > > Graybeards chucking at the follies of youth. > Yea, this code is quite well written relative to most of the code of that era... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Thu Feb 3 15:47:52 2022 From: rdm at cfcl.com (Rich Morin) Date: Wed, 2 Feb 2022 21:47:52 -0800 Subject: [TUHS] more about Brian... In-Reply-To: <202202020747.2127lTTh005669@freefriends.org> References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> Message-ID: <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> > On Feb 1, 2022, at 23:47, arnold at skeeve.com wrote: > > ... in general, I think the principle of "ANYTHING written by Brian > Kernighan is worth reading, at least once" applies, ... I've been having a good time watching YouTube videos that have Brian either interviewing or being interviewed by assorted folks. My favorite one, so far, is this "fireside chat": VCF East 2019 -- Brian Kernighan interviews Ken Thompson https://www.youtube.com/watch?v=EY6q5dv_B-o In any case, the K&P book I'd _really_ like to see brought up to date is "The Elements of Programming Style". It could have been subtitled "How to write small, simple programs that work." It's still a very fine book, but I'm not sure that the current crop of beginning programmers would be patient enough to deal with the sadly dated example code. If you're still here, I'll give you a vignette from many years ago. My spouse and I were both early fans of AWK, having been introduced to it around 1983 by our friend Jim Joyce. Indeed, she used AWK to process line printer plot files (dendograms, for the curious) into a format that my homegrown SunCore interpreter could render for screen display and printing on our dot matrix printer. Some of them ended up in her Master's Thesis... Anyway, we traveled with Jim to Copenhagen for a EurOpen conference. At the closing banquet, I got to an empty table before anyone else and tossed down a "no smoking" placard. Vicki and I then sat down. Shortly thereafter, Brian walked past and saw the placard. Brian: "Is this a non-smoking table?" Us: "It is now. (:-)" So, he sat down and we had a chance to dine with a personal hero (and all-around nice guy). The next day, we got on a train to Stockholm, on our way to Helsinki (to teach a Unix Intro course with Jim). Our four-person compartment turned out to include Brian, Vicki, me, and a long-suffering European businessman. IIRC, we pestered Brian for hours about AWK, Bell Labs, and so forth. He was unfailingly gracious and a wonderful person to spend the trip with. -r From meillo at marmaro.de Thu Feb 3 17:44:10 2022 From: meillo at marmaro.de (markus schnalke) Date: Thu, 03 Feb 2022 08:44:10 +0100 Subject: [TUHS] more about Brian... In-Reply-To: <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> Message-ID: <1nFWmo-1Gn-00@marmaro.de> Hoi. [2022-02-02 21:47] Rich Morin > > In any case, the K&P book I'd _really_ like to see brought up > to date is "The Elements of Programming Style". It could have > been subtitled "How to write small, simple programs that work." > It's still a very fine book, but I'm not sure that the current > crop of beginning programmers would be patient enough to deal > with the sadly dated example code. Don't you think that ``The Practice of Programming'' is the modern version of ``The Elements of Programming Style''? (Also a K&P book, btw. ;-) ) (Of course, the C++ and Java code in there would be seen as outdated as well, by now.) But even this one, today's programmers don't wanna read. They all go for ``Clean Code'', because they seem to like the style where someone with perfect selfconfidence answers all their questions and tells them what to do, as long it is not telling them to think for themselves and compromise between various conflicting goals that you all like go reach and thus that it depends on the specific situation. The problem IMO is not some dated example code but today's programmers having few interest in learning things outside their main modern focus and the style the're used to. They usually think that running fast is the best way moving forward, but they don't realize that slowing down, looking around, understanding the paths that lead us where we are and taking time to learn and think, isn't as slow as they might expect and eventually leads to better results. Being used to reading code and understanding concepts that are not fully in the style you're used to and transferring them to one's own world actually is a valuable ability, that people should train instead of avoid. Thus especially students should do read that good old ``Elements of Programming Style'' and discuss that, not a new book. Overall I don't really think that there's much hope in getting programmers to read such stuff, because they simply don't want to. Many don't care for good code, because they don't think in code lifespans of more than three to five years. They don't care to understand what they do and how the internals work, because that's hard work without instant results. And in today's world it's usually pays out to not do it. They don't care for simplicity but they want features and nice GUIs. Besides, they use technologies that favor huge programs and often are poorly suited for programming with small programs. Likewise, their whole thinking is focussed on large programs, because that's what they've been taught the whole time. What attracts them more and probably is more helpful is something like Go, which solves their problems. They don't use it because of conceptional beauty but because of its features. If you want to attract the masses, then you have to give them solutions to their problems and their wishes, not trying to educate them. ;-) To really step forward with the Unix philosophy Go needs to enter education and become today's Java as a main programming learning language. And for those, who are different, it doesn't matter so much how dated the examples are. It's the ideas and concepts which attract them. With Go there is a very modern technology, for beginners and experts alike, that carries Unix concepts and its way of thinking and decision making throughout. That probably is much more effective than any book. Besides, there are lots of Youtube videos around Go which transport the ideas and concepts, which as well are probably much more effective today than books. Anyone on this list, on the other hand, will probably be very happy in reading on of these old books (again) ... and have a great time! :-) meillo P.S. Thanks for sharing your bwk stories! From rdm at cfcl.com Thu Feb 3 18:18:10 2022 From: rdm at cfcl.com (Rich Morin) Date: Thu, 3 Feb 2022 00:18:10 -0800 Subject: [TUHS] more about Brian... In-Reply-To: <1nFWmo-1Gn-00@marmaro.de> References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> Message-ID: <5C3EC92F-9B85-4BDB-A501-7C8C4840DE2B@cfcl.com> > On Feb 2, 2022, at 23:44, markus schnalke wrote: > > Don't you think that ``The Practice of Programming'' is the modern > version of ``The Elements of Programming Style''? Not really. It's a fine book, but a lot bigger, so it contains a lot more (and more diverse) material. I like the facts that "The Elements of Programming Style" is pretty tightly focused and that it can be read quickly (and absorbed over time :-). That is, the title's homage to "The Elements of Style" is not an accident... -r From silas8642 at hotmail.co.uk Fri Feb 4 04:57:35 2022 From: silas8642 at hotmail.co.uk (silas poulson) Date: Thu, 3 Feb 2022 18:57:35 +0000 Subject: [TUHS] ratfor vibe In-Reply-To: <202202020747.2127lTTh005669@freefriends.org> References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> Message-ID: <8E7B6E10-E94E-4DC7-9B0A-69796C03F2D6@hotmail.co.uk> > FWIW, Brian has told me more than once that he wishes they'd done > “Software Tools In C" instead of in Pascal, and that the Pascal book > was a failure to read the market correctly. Ah, but then we wouldn’t have had his wonderful *Why Pascal* paper! Has Brian ever said what would’ve been different if a C version had been written? Silas From athornton at gmail.com Fri Feb 4 06:00:07 2022 From: athornton at gmail.com (Adam Thornton) Date: Thu, 3 Feb 2022 13:00:07 -0700 Subject: [TUHS] ratfor vibe In-Reply-To: References: Message-ID: On Wed, Feb 2, 2022 at 9:01 PM Will Senn wrote: > > For example, even in the tiny copy program example, from the introductory > chapter, once you include the primitive getc and putc subroutines, there > are 7 symbolic constants: MAXLINE, MAXCARD, NEWLINE, STDIN, STDOUT, EOF, > SPACE and character, which is really an integer and gets replaced with > integer by some mythical preprocessor (chapter 8). Anyhow, in the modern > world, MAXLINE and MAXCARD don't really have meaning, but they can > magically be treated as lines of a file, the rest do have meaning, but they > don't evaluate to the same things in Fortran-land as in modern-land. STDIN > is 5 and STDOUT is 6 (card reader and punch LUNs, again some magic that > lets them be treated as terminal input and output), EOF is -1, SPACE is > 32, NEWLINE is 10. > > Pretty sure that EOF is _still_ -1. SPACE and NEWLINE also look pretty > familiar and their values haven't changed, although we might spell them a > little differently these days. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Fri Feb 4 07:28:21 2022 From: norman at oclsc.org (Norman Wilson) Date: Thu, 3 Feb 2022 16:28:21 -0500 (EST) Subject: [TUHS] calendar events Message-ID: Whose birthday is it, Ken? Norman Wilson Toronto ON From cowan at ccil.org Fri Feb 4 07:45:58 2022 From: cowan at ccil.org (John Cowan) Date: Thu, 3 Feb 2022 16:45:58 -0500 Subject: [TUHS] calendar events In-Reply-To: References: Message-ID: On Thu, Feb 3, 2022 at 4:28 PM Norman Wilson wrote: Whose birthday is it, Ken? Who stole the weather, Abe? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Fri Feb 4 12:23:36 2022 From: athornton at gmail.com (Adam Thornton) Date: Thu, 3 Feb 2022 19:23:36 -0700 Subject: [TUHS] more about Brian... In-Reply-To: <1nFWmo-1Gn-00@marmaro.de> References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> Message-ID: It feels like the tide has turned from Go to Rust. I speak Go relatively fluently but have never used Rust in anger. Do the august personages on this list have opinions about Rust? People who generally have tastes consonant with mine tell me I'd like Rust. Although a bit outdated, I stand by what I wrote about Go several (six?) years ago: https://athornton.github.io/go-it-mostly-doesnt-suck Adam On Thu, Feb 3, 2022 at 12:45 AM markus schnalke wrote: > > > What attracts them more and probably is more helpful is something > like Go, which solves their problems. They don't use it because of > conceptional beauty but because of its features. If you want to > attract the masses, then you have to give them solutions to their > problems and their wishes, not trying to educate them. ;-) To > really step forward with the Unix philosophy Go needs to enter > education and become today's Java as a main programming learning > language. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Fri Feb 4 12:34:40 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 03 Feb 2022 18:34:40 -0800 Subject: [TUHS] more about Brian... [really Rust] In-Reply-To: References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> Message-ID: <202202040234.2142YeKN3307556@darkstar.fourwinds.com> Adam Thornton writes: > Do the august personages on this list have opinions about Rust? > People who generally have tastes consonant with mine tell me I'd like Rust. Well, I'm not an august personage and am not a Rust programmer. I did spend a while trying to learn rust a while ago and wasn't impressed. Now, I'm heavily biased in that I think that it doesn't add value to keep inventing new languages to do the same old things, and I didn't see anything in Rust that I couldn't do in a myriad of other languages. But, my real issue came from some of the tutorials that I perused. Rust is being sold as "safer". As near as I can tell from the tutorials, the model is that nothing works unless you enable it. Want to be able to write a variable? Turn that on. So it seemed like the general style was to write code and then turn various things on until it ran. To me, this implies a mindset that programming errors are more important than thinking errors, and that one should hack on things until they work instead of thinking about what one is doing. I know that that's the modern definition of programming, but will never be for me. Jon From drsalists at gmail.com Fri Feb 4 13:28:17 2022 From: drsalists at gmail.com (Dan Stromberg) Date: Thu, 3 Feb 2022 19:28:17 -0800 Subject: [TUHS] more about Brian... In-Reply-To: References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> Message-ID: On Thu, Feb 3, 2022 at 6:25 PM Adam Thornton wrote: > It feels like the tide has turned from Go to Rust. I speak Go relatively > fluently but have never used Rust in anger. Do the august personages on > this > list have opinions about Rust? People who generally have tastes consonant > with mine tell me I'd like Rust. > > Although a bit outdated, I stand by what I wrote about Go several (six?) > years ago: https://athornton.github.io/go-it-mostly-doesnt-suck > I think Rust brings something new and interesting to language design. Databases like to have many readers or a single writer for a given piece of data. Rust takes this idea and makes it part of the language. It also manages to be largely memory-leak free, without a garbage collector. And it still allows you to shoot your foot off if you really want to. But there's a hoop to jump through first, which, I think, is how it should be. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Fri Feb 4 15:11:14 2022 From: rdm at cfcl.com (Rich Morin) Date: Thu, 3 Feb 2022 21:11:14 -0800 Subject: [TUHS] more about Brian... In-Reply-To: References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> Message-ID: Well, this topic certainly took an odd turn. Owell... > On Feb 3, 2022, at 18:23, Adam Thornton wrote: > > It feels like the tide has turned from Go to Rust. ... The incursions of Rust (and not Go) into Linux, Mozilla, and such may indicate a trend. > Although a bit outdated, I stand by what I wrote about Go several (six?) years ago: https://athornton.github.io/go-it-mostly-doesnt-suck I quite enjoyed this and found it to be informative, as well. My personal reaction to Go (mostly derived from skimming Brian's book) is that (a) it's well tuned to Google's needs and (b) not well tuned to mine. Specifically... Google needs a language which runs efficiently and links in a reasonable amount of time, even when HUGE sets of libraries are involved. It also needs a convenient way to do massive concurrency. Finally, it needs zillions of programmers to be fungible, dropping into code bases that they've never seen before, without tripping over landmines. My impression is that Go meets these criteria admirably. But, horses for courses... I program mostly on my own, so most of these criteria are irrelevant to my needs. I use Ruby for short scripts and Elixir for larger programs. Neither one is blazingly fast, but they both feel comfortable to write in. I like Matz's taste in design and think that José Valim has pulled together a very appealing mix of concepts and syntax from Clojure, Erlang, F#, Lisp, Ruby, etc. One problem I have with Go is that it doesn't match the way I code. Kind of like (I imagine) an oil painter might work, I start with broad swatches and fill in the details over time. So, any new program is likely to have stubs lying about, waiting to be implemented. Also, I might well calculate a variable only to support a trace statement which is currently commented out. Go is very intolerant of this sort of thing: an unused variable, IIRC, is a fatal error. Google isn't paying me to put up with this sort of thing, so I don't. Another problem I have with Go is the concurrency model. First, it uses threads, which I've never felt competent to use safely. Shared mutable state is one of those things that seem to me like an accident waiting to happen. Also, though I have no real experience with CSP, it seems like the Actor model may be better suited to exploratory programming. Getting back to Rust, my impression is that its design assumes that having the computer put up guard rails will (mostly) keep programmers from making catastrophic mistakes. In contrast, the Erlang (and thus Elixir) approach assumes that things WILL crash and that the important thing is to make sure that the system as a whole keeps running smoothly. So, for example, it provides supervision trees which can handle any crash of an Actor, etc. Also, I learned pretty early in my career (ca. 1972) that some of the biggest botches come from folks not understanding the needs of the users. I wrote a 10 KLOC PDP-11 assembly language program, based on a 1" thick specification document. It never got used, because it didn't solve the users' problem. Fine code, broken spec... Having said all this, I'm actually quite happy about the fact that Rust is creeping into Linux. The coding style is likely to be a bit more careful and it may well help to provide some protection against security issues. (ducks) -r From ori at heliconbooks.com Fri Feb 4 16:06:32 2022 From: ori at heliconbooks.com (Ori Idan) Date: Fri, 4 Feb 2022 08:06:32 +0200 Subject: [TUHS] ratfor vibe In-Reply-To: References: Message-ID: SPACE is 32 and NEWLINE is 10 is that the reason that space in ASCII is 32 As for EOF it is 0xFF which is not always -1, depending if your char is signed or unsigned. -- Ori Idan CEO Helicon Books http://www.heliconbooks.com On Thu, Feb 3, 2022 at 10:01 PM Adam Thornton wrote: > > > On Wed, Feb 2, 2022 at 9:01 PM Will Senn wrote: > >> >> For example, even in the tiny copy program example, from the introductory >> chapter, once you include the primitive getc and putc subroutines, there >> are 7 symbolic constants: MAXLINE, MAXCARD, NEWLINE, STDIN, STDOUT, EOF, >> SPACE and character, which is really an integer and gets replaced with >> integer by some mythical preprocessor (chapter 8). Anyhow, in the modern >> world, MAXLINE and MAXCARD don't really have meaning, but they can >> magically be treated as lines of a file, the rest do have meaning, but they >> don't evaluate to the same things in Fortran-land as in modern-land. STDIN >> is 5 and STDOUT is 6 (card reader and punch LUNs, again some magic that >> lets them be treated as terminal input and output), EOF is -1, SPACE is >> 32, NEWLINE is 10. >> >> Pretty sure that EOF is _still_ -1. SPACE and NEWLINE also look pretty >> familiar and their values haven't changed, although we might spell them a >> little differently these days. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From akosela at andykosela.com Fri Feb 4 17:38:44 2022 From: akosela at andykosela.com (Andy Kosela) Date: Fri, 4 Feb 2022 08:38:44 +0100 Subject: [TUHS] more about Brian... In-Reply-To: References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> Message-ID: On 2/4/22, Adam Thornton wrote: > It feels like the tide has turned from Go to Rust. I speak Go relatively > fluently but have never used Rust in anger. Do the august personages on > this > list have opinions about Rust? People who generally have tastes consonant > with mine tell me I'd like Rust. > > Although a bit outdated, I stand by what I wrote about Go several (six?) > years ago: https://athornton.github.io/go-it-mostly-doesnt-suck 2010 Go != 2022 Go I used to be a big proponent of Go back in 2010. The language definitely felt fresh and minimal back then when Java and C++ were dominant on the market. And it definitely felt like the authors of Go wanted to replace them . It made sense in the Google environment, but very soon people realized that you can't write everything in Go. Garbage collector is cool but actually it prevents you from writing kernel or performance critical code, e.g. games. But Go became popular anyway. A lot of substandard PHP and New Age programmers started using it and it showed. In the beginning the humble authors of Go preferred minimal variable names and less than 80 char lines. In time all this turned into Java-like long, expressive variable names and extremely long lines. I really hate lines longer than 80 chars...in any language. They are really hard to focus as you need to constantly move your eyes from left to right. The same phenomenon happens with very wide browser windows. And due to popular demand they started to add on to the language features: modules, generics, etc.. The language still feels a lot less bloated than C++, but IMHO plain old C just feels more natural and minimal. And because I still program on a lot of old retro systems today I returned back to C. You can use C on pretty much everything -- from 8-bit machines to amd64. You can't say the same about Go. And Rust? If Go was trying to reinvent C, Rust definitely feels like it is trying to reinvent C++... --Andy From rodrigosloop at gmail.com Fri Feb 4 18:18:05 2022 From: rodrigosloop at gmail.com (=?UTF-8?Q?Rodrigo_G=2E_L=C3=B3pez?=) Date: Fri, 4 Feb 2022 09:18:05 +0100 Subject: [TUHS] calendar events In-Reply-To: References: Message-ID: What is the frequency, Kenneth? On Thu, Feb 3, 2022, 10:46 PM John Cowan wrote: > > > On Thu, Feb 3, 2022 at 4:28 PM Norman Wilson wrote: > > Whose birthday is it, Ken? > > > Who stole the weather, Abe? > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Fri Feb 4 18:10:16 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Fri, 4 Feb 2022 03:10:16 -0500 (EST) Subject: [TUHS] more about Brian... In-Reply-To: References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> Message-ID: On Fri, 4 Feb 2022, Andy Kosela wrote: > I used to be a big proponent of Go back in 2010. The language > definitely felt fresh and minimal back then when Java and C++ were > dominant on the market. And it definitely felt like the authors of Go > wanted to replace them . It made sense in the Google environment, but > very soon people realized that you can't write everything in Go. > Garbage collector is cool but actually it prevents you from writing > kernel or performance critical code, e.g. games. > > But Go became popular anyway. A lot of substandard PHP and New Age > programmers started using it and it showed. In the beginning the > humble authors of Go preferred minimal variable names and less than 80 > char lines. In time all this turned into Java-like long, expressive > variable names and extremely long lines. I really hate lines longer > than 80 chars...in any language. They are really hard to focus as you > need to constantly move your eyes from left to right. The same > phenomenon happens with very wide browser windows. I tend to prefer to keep everything to 77-79 when I'm actually formatting code for releases as opposed to "just don't care". > And due to popular demand they started to add on to the language > features: modules, generics, etc.. The language still feels a lot > less bloated than C++, but IMHO plain old C just feels more natural > and minimal. I tend to feel that C strikes a perfect balance between minimalist and powerful. > And because I still program on a lot of old retro systems today I > returned back to C. You can use C on pretty much everything -- from > 8-bit machines to amd64. You can't say the same about Go. Same. I mean, I've started to pick up 8086 assembler, but I can write C, I can code for my Apple //e, or I can code for my AMD64 boxen, or for my old PS/2, or theoretically for my ancient Macintoshes...or a number of other systems. It's not quite "write once run everywhere", but it's pretty close. -uso. From arnold at skeeve.com Fri Feb 4 18:26:14 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 04 Feb 2022 01:26:14 -0700 Subject: [TUHS] ratfor vibe In-Reply-To: <8E7B6E10-E94E-4DC7-9B0A-69796C03F2D6@hotmail.co.uk> References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <8E7B6E10-E94E-4DC7-9B0A-69796C03F2D6@hotmail.co.uk> Message-ID: <202202040826.2148QExq017156@freefriends.org> silas poulson wrote: > > FWIW, Brian has told me more than once that he wishes they'd done > > “Software Tools In C" instead of in Pascal, and that the Pascal book > > was a failure to read the market correctly. > > Ah, but then we wouldn’t have had his wonderful *Why Pascal* paper! > > Has Brian ever said what would’ve been different if a C version had > been written? No, he has not. I suspect it would have looked like the ratfor code but with real data structures and recursion, and without the need to build the standard I/O library (getc, putc, etc.). Arnold From meillo at marmaro.de Fri Feb 4 18:44:38 2022 From: meillo at marmaro.de (markus schnalke) Date: Fri, 04 Feb 2022 09:44:38 +0100 Subject: [TUHS] more about Brian... In-Reply-To: References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> Message-ID: <1nFuCs-2RI-00@marmaro.de> Hoi. [2022-02-04 03:10] Steve Nickolas > On Fri, 4 Feb 2022, Andy Kosela wrote: > > > > And due to popular demand they started to add on to the language > > features: modules, generics, etc.. The language still feels a lot > > less bloated than C++, but IMHO plain old C just feels more natural > > and minimal. > > I tend to feel that C strikes a perfect balance between minimalist and > powerful. You have to consider that each language is a child of its time; the culture of each programming language is shaped by the people who use it, write libraries and books and teach others. If you would introduce the C language today for the first time, it wouldn't become the same language that we like. Its libraries and culture would be very different because today's programmers are different. Likewise, would Go have been introduced in older times, it probably would have evolved differently. Thus, with liking the minimalist/powerful balance of C and the style of how programs in C are written (because that C culture has grown decades ago and is now also a part of the language) you actually say that you like the old times better than the new times. (I don't blame you for that.) This all is much more about culture and what types of people program and the reasons why they program and the kinds of projects they do and the kinds of companies and their motivation in programming and how all this shapes the culture of any language ... than it is about specific languages itself, IMO. meillo From usotsuki at buric.co Fri Feb 4 19:16:02 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Fri, 4 Feb 2022 04:16:02 -0500 (EST) Subject: [TUHS] more about Brian... In-Reply-To: <1nFuCs-2RI-00@marmaro.de> References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <1nFuCs-2RI-00@marmaro.de> Message-ID: On Fri, 4 Feb 2022, markus schnalke wrote: > You have to consider that each language is a child of its time; > the culture of each programming language is shaped by the people > who use it, write libraries and books and teach others. > > If you would introduce the C language today for the first > time, it wouldn't become the same language that we like. Its > libraries and culture would be very different because today's > programmers are different. Likewise, would Go have been > introduced in older times, it probably would have evolved > differently. Probably true. > Thus, with liking the minimalist/powerful balance of C and the > style of how programs in C are written (because that C culture > has grown decades ago and is now also a part of the language) > you actually say that you like the old times better than the new > times. (I don't blame you for that.) Could be that I cut my teeth on an 8-bit computer and did a lot of work on 16-bit systems, so I'm used to working with limited RAM and CPU. > This all is much more about culture and what types of people > program and the reasons why they program and the kinds of > projects they do and the kinds of companies and their motivation > in programming and how all this shapes the culture of any > language ... than it is about specific languages itself, IMO. There is certainly truth to that. And even human languages tend to adapt in culture-specific ways ("two countries divided by a common language" being a common joke about the US versus the UK, for example). -uso. From thomas.paulsen at firemail.de Fri Feb 4 23:07:19 2022 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Fri, 04 Feb 2022 14:07:19 +0100 Subject: [TUHS] more about Brian... [really Rust] In-Reply-To: <202202040234.2142YeKN3307556@darkstar.fourwinds.com> References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <202202040234.2142YeKN3307556@darkstar.fourwinds.com> Message-ID: <6f4ced6ef9f99389adc87a58347b674a@firemail.de> --- Ursprüngliche Nachricht --- Von: Jon Steinhart Datum: 04.02.2022 03:34:40 An: The Eunuchs Hysterical Society Betreff: Re: [TUHS] more about Brian... [really Rust] 'Well, I'm not an august personage and am not a Rust programmer. I did spend a while trying to learn rust a while ago and wasn't impressed. ...instead of thinking about what one is doing. I know that that's the modern definition of programming, but will never be for me.' check out go(lang), Ken and Rob are involved. From jra at andrusk.com Sat Feb 5 00:17:06 2022 From: jra at andrusk.com (Justin Andrusk) Date: Fri, 04 Feb 2022 14:17:06 +0000 Subject: [TUHS] Got kicked off list due to DNS Issues Message-ID: Back in September I was having serious DNS issues with my MX records. Finally was able to move to a new DNS provider. Could someone add me (jra at andrusk.com) back to the mailing list? Thanks, Justin Sent from ProtonMail mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sat Feb 5 03:01:20 2022 From: will.senn at gmail.com (Will Senn) Date: Fri, 4 Feb 2022 11:01:20 -0600 Subject: [TUHS] Document management in Unix, back in the day? Message-ID: <8b7daf0d-991a-e8be-9dff-63fe4fb688ab@gmail.com> Today I bit the bullet and dropped my many articles and electronic documents related to my technical explorations into Zotero. I was tired of constantly having to remember where the documents were located and I wanted to be able to curate them better (I tried git for a while, back when, but I'm not a fan of non-text data in my repos, and it wasn't really much better than the base file system approach). I've been using Zotero for years now, for academic works, but not for technical works unrelated to my research. I realized the man-years of effort to clean up the entries that I had created in about 30-40 seconds of exciting drag and drop, just about the time I deleted them from their original locations. I think the work will pay off in due time, but we'll see. Then I thought, surely, I'm not the first person to have had this problem... it occurred to me that y'all must have faced this very problem, a few years in, back in the late 70's, early 80's. That is, document management. What did you do, variously, considering both text and non-text? Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Sat Feb 5 03:35:38 2022 From: athornton at gmail.com (Adam Thornton) Date: Fri, 4 Feb 2022 10:35:38 -0700 Subject: [TUHS] ratfor vibe In-Reply-To: References: Message-ID: On Thu, Feb 3, 2022 at 11:07 PM Ori Idan wrote: > As for EOF it is 0xFF which is not always -1, depending if your char is > signed or unsigned. > > Ha! You fell into my trap! getc() returns an int! (I don't know if EOF is _always_ "all bits set", and even if it is, that's only -1 on a twos-complement machine, if we want to head off into some real pedantry...) The need to use feof() and ferror() at least appear in the BUGS section on my Mac. Linux is not so gracious. The real bug, if you ask me, which no one did, is that getc() and pals return an int rather than a char, which is surprising and certainly has tripped me up several times across the decades (and yes, I understand that since any character value is a legal character to have gotten, you need some other way of signalling an error). -------------- next part -------------- An HTML attachment was scrubbed... URL: From web at loomcom.com Sat Feb 5 03:35:19 2022 From: web at loomcom.com (Seth J. Morabito) Date: Fri, 04 Feb 2022 09:35:19 -0800 Subject: [TUHS] Document management in Unix, back in the day? In-Reply-To: <8b7daf0d-991a-e8be-9dff-63fe4fb688ab@gmail.com> References: <8b7daf0d-991a-e8be-9dff-63fe4fb688ab@gmail.com> Message-ID: <87pmo2leeg.fsf@loomcom.com> Will Senn writes: > Then I thought, surely, I'm not the first person to have had this > problem... it occurred to me that y'all must have faced this very > problem, a few years in, back in the late 70's, early 80's. That is, > document management. What did you do, variously, considering both text > and non-text? I'm sure the vast majority of document management was in real folders in real filing cabinets. We take our vast stores of electronic documents for granted these days, but it's shockingly recent in computing terms! Besides, it's fun to scribble notes all over printouts and Xeroxes :^) > Will -Seth -- Seth Morabito web at loomcom.com Poulsbo, WA, USA From athornton at gmail.com Sat Feb 5 03:43:59 2022 From: athornton at gmail.com (Adam Thornton) Date: Fri, 4 Feb 2022 10:43:59 -0700 Subject: [TUHS] Document management in Unix, back in the day? In-Reply-To: <87pmo2leeg.fsf@loomcom.com> References: <8b7daf0d-991a-e8be-9dff-63fe4fb688ab@gmail.com> <87pmo2leeg.fsf@loomcom.com> Message-ID: Don Lancaster's "Tearing" method of understanding Apple II assembly programs, but, really, generalizable to anything, is, forty years later, *still* magnificent. https://www.tinaja.com/ebooks/tearing_rework.pdf On Fri, Feb 4, 2022 at 10:40 AM Seth J. Morabito wrote: > > Besides, it's fun to scribble notes all over printouts and Xeroxes :^) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sat Feb 5 03:44:09 2022 From: will.senn at gmail.com (Will Senn) Date: Fri, 4 Feb 2022 11:44:09 -0600 Subject: [TUHS] ratfor vibe In-Reply-To: References: Message-ID: On 2/4/22 11:35 AM, Adam Thornton wrote: > > > On Thu, Feb 3, 2022 at 11:07 PM Ori Idan wrote: > > As for EOF it is 0xFF which is not always -1, depending if your > char is signed or unsigned. > > > Ha!  You fell into my trap!  getc() returns an int!  (I don't know if > EOF is _always_ "all bits set", and even if it is, that's only -1 on a > twos-complement machine, if we want to head off into some real > pedantry...) > > The need to use feof() and ferror() at least appear in the BUGS > section on my Mac.  Linux is not so gracious.  The real bug, if you > ask me, which no one did, is that getc() and pals return an int rather > than a char, which is surprising and certainly has tripped me up > several times across the decades (and yes, I understand that since any > character value is a legal character to have gotten, you need some > other way of signalling an error). This is prolly why the authors steadfastly refused to commit to a particular value for EOF. Instead, they said in essence, that it was a matter of agreement, convention, if you will, and that whatever value was chosen, it should NEVER be a legal character. I made it -1, for v7, cuz it worked... and I wanted so badly to get a working ratfor program that I sacrificed any semblance of technical rigor to make it copy a character, onscreen, in real time, live. Heck, and it only took me a couple of days to figure out all how to get it working, EOF was easy, STDIN and STDOUT, not so much. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Sat Feb 5 04:54:14 2022 From: cowan at ccil.org (John Cowan) Date: Fri, 4 Feb 2022 13:54:14 -0500 Subject: [TUHS] more about Brian... In-Reply-To: References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> Message-ID: On Fri, Feb 4, 2022 at 3:20 AM Steve Nickolas wrote: > > Garbage collector is cool but actually it prevents you from writing > > kernel or performance critical code, e.g. games. > I'm sure kernels with GC are on their way. I think they already exist in research contexts. As for games, the problem seems to be that the market will not pay enough for hardware to do a good job. so the attitude is "So what if it crashes, it's just a dumb game." The last C program I worked on was an interpreter for the Joy language. It had a precise GC for objects, but strings were a mess. I added libgc and ripped out all the half-assed solutions. If I had to write C today, I'd write it with libgc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Sat Feb 5 05:41:03 2022 From: cowan at ccil.org (John Cowan) Date: Fri, 4 Feb 2022 14:41:03 -0500 Subject: [TUHS] ratfor vibe In-Reply-To: <202202040826.2148QExq017156@freefriends.org> References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <8E7B6E10-E94E-4DC7-9B0A-69796C03F2D6@hotmail.co.uk> <202202040826.2148QExq017156@freefriends.org> Message-ID: On Fri, Feb 4, 2022 at 3:26 AM wrote: No, he has not. I suspect it would have looked like the ratfor code > but with real data structures and recursion, and without the need to > build the standard I/O library (getc, putc, etc.). > See Jez Higgins's STinC++ (Software Tools in C++) project at < https://www.jezuk.co.uk/tags/software-tools-in-c++.html>. He's working from ST in Pascal, but this is a rewrite from scratch, not a translation. So far he's done Chapters 1, 2, and 5, implementing each tool as he goes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.paulsen at firemail.de Sat Feb 5 05:45:38 2022 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Fri, 04 Feb 2022 20:45:38 +0100 Subject: [TUHS] more about Brian... In-Reply-To: References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> Message-ID: An HTML attachment was scrubbed... URL: From hellwig.geisse at mni.thm.de Sat Feb 5 06:28:10 2022 From: hellwig.geisse at mni.thm.de (Hellwig Geisse) Date: Fri, 04 Feb 2022 21:28:10 +0100 Subject: [TUHS] more about Brian... In-Reply-To: References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> Message-ID: <1644006490.2458.78.camel@mni.thm.de> Hi Thomas, On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: > I tell you one thing: I never ever experienced any problems with > traditional malloc()/free().­ did you ever write a program which does heavy malloc()/free() on complicated (i.e., shared) data structures *and* runs for days, perhaps weeks? IMO it's very difficult to do this without a GC, and you have to exercise quite an amount of discipline to do it right. > A kernel using GC is a kernel written by inexperienced kids. Well, not exactly. Niklaus Wirth's Oberon kernel (around 1990) used a GC, and it did that quite efficiently. Hellwig From cowan at ccil.org Sat Feb 5 06:51:37 2022 From: cowan at ccil.org (John Cowan) Date: Fri, 4 Feb 2022 15:51:37 -0500 Subject: [TUHS] Document management in Unix, back in the day? In-Reply-To: <87pmo2leeg.fsf@loomcom.com> References: <8b7daf0d-991a-e8be-9dff-63fe4fb688ab@gmail.com> <87pmo2leeg.fsf@loomcom.com> Message-ID: On Fri, Feb 4, 2022 at 12:39 PM Seth J. Morabito wrote: Besides, it's fun to scribble notes all over printouts and Xeroxes :^) > I mark up a printout with scribbles ("hourglasses and arrows and a documentation resource for each one, sayin' what they was about, to be used in evidence against us"[*]) and then re-transcribe them into the original electronic doc. I wish I had a better approach that wasn't so environmentally destructive, but I just don't notice errors as easily when they're just on the screen. [*] See < https://web.archive.org/web/20210321003206/http://vrici.lojban.org/~cowan/alice_flame.txt>. With feeling. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcapp at anteil.com Sat Feb 5 07:03:41 2022 From: jcapp at anteil.com (Jim Capp) Date: Fri, 4 Feb 2022 16:03:41 -0500 (EST) Subject: [TUHS] more about Brian... In-Reply-To: <1644006490.2458.78.camel@mni.thm.de> Message-ID: <8901533.793.1644008621545.JavaMail.root@zimbraanteil> I have a subsystem that populates a database from disparate data streams. It's been known to run for years without restarting, thanks to valgrind. From: "Hellwig Geisse" To: tuhs at minnie.tuhs.org Sent: Friday, February 4, 2022 3:28:10 PM Subject: Re: [TUHS] more about Brian... Hi Thomas, On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: > I tell you one thing: I never ever experienced any problems with > traditional malloc()/free().­ did you ever write a program which does heavy malloc()/free() on complicated (i.e., shared) data structures *and* runs for days, perhaps weeks? IMO it's very difficult to do this without a GC, and you have to exercise quite an amount of discipline to do it right. > A kernel using GC is a kernel written by inexperienced kids. Well, not exactly. Niklaus Wirth's Oberon kernel (around 1990) used a GC, and it did that quite efficiently. Hellwig -------------- next part -------------- An HTML attachment was scrubbed... URL: From woods at robohack.ca Sat Feb 5 07:22:02 2022 From: woods at robohack.ca (Greg A. Woods) Date: Fri, 04 Feb 2022 13:22:02 -0800 Subject: [TUHS] Go vs. Rust, and etc. (was: more about Brian...) In-Reply-To: References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> Message-ID: I find programming in Go to be an extremely fun, and usually relatively easy thing to do, and it's never boring or tedious (though when learning some new idiom or technique or library it can be challenging, but that's a good thing). Maybe writing tests can be tedious at times, but it's also very satisfying, and quite easy to do with the support in the Go environment. At Thu, 3 Feb 2022 21:11:14 -0800, Rich Morin wrote: Subject: Re: [TUHS] more about Brian... > > Another problem I have with Go is the concurrency model. First, > it uses threads, which I've never felt competent to use safely. > Shared mutable state is one of those things that seem to me like > an accident waiting to happen. Also, though I have no real > experience with CSP, it seems like the Actor model may be better > suited to exploratory programming. Go's concurrency model was a lot easier for me after I spent some time working in a C environment that transparently supported working with either proper threads (with the target system's libpthread as the underlying implementation) or coroutines (with libcoro as the underlying implementation). Valgrind was my friend for finding races and other things one should not do in a threaded program. > Getting back to Rust, my impression is that its design assumes > that having the computer put up guard rails will (mostly) keep > programmers from making catastrophic mistakes. In contrast, the > Erlang (and thus Elixir) approach assumes that things WILL crash > and that the important thing is to make sure that the system as a > whole keeps running smoothly. So, for example, it provides > supervision trees which can handle any crash of an Actor, etc. I find Rust to be appalling and very very very unappealing (to me). It's C++ for Perl programmers -- and all the bad parts/warts of both. Rust is, to me, ugly, inelegant, and hard to read and reason about. I still work on and write lots of C, but I'm very tired of UB. I want a C-like language (in that it's close the metal/SiO2) and that has absolutely zero UB in the spec. None. Everything MUST be defined behaviour. There are a couple of "new" languages in my sights (for applications where Go might not be ideal): - Drew Devault's secret new language: https://drewdevault.com/ - Zig -- http://ziglang.org/ (by Andrew Kelley) ready and running, apparently. BUT oh, gawd -- it's currently written in C++ and uses CMake (though apparently comes with its own built-in build system so that Zig programs don't need anything like CMake, etc.) - Jai: imperative static/strongly typed C-style language by Jonathan Loom https://inductive.no/jai/ https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md No implicit type conversions No header files Beautiful and elegant. Built-in build system. Jai code can be built on top of existing C libraries - V -- https://vlang.io Perhaps the most mature of the lot. But I would also be happy with just plain old C (though perhaps C99 not C11), with all the UB caveats nailed down into Defined Behaviour. The authors and maintainers of modern compilers are not really truly sane. They most certainly should not be allowed to exploit UB, especially not behind the user's back as they mostly do now. C's primitive nature engenders the programmer to think in terms of what the target machine is going to do, and as such it is extremely sad and disheartening that the standards committee chose to endanger C's users in so many ways. As Phil Pennock said: If I program in C, I need to defend against the compiler maintainers. [[ and future standards committee members!!! ]] If I program in Go, the language maintainers defend me from my mistakes. And I say: Modern "Standard C" is actually "Useless C" and "Unusable C" (especially if one does not fully embrace tools like Valgrind and enable all compiler features that point out UB in all possible ways at all times) BTW, there's also a new scripting language I've got on my stack to investigate further: https://wren.io -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From rich.salz at gmail.com Sat Feb 5 07:37:51 2022 From: rich.salz at gmail.com (Richard Salz) Date: Fri, 4 Feb 2022 16:37:51 -0500 Subject: [TUHS] Go vs. Rust, and etc. (was: more about Brian...) In-Reply-To: References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> Message-ID: I really wish there were a manpage that says "foo is the one true language" just like ed(1). Then this thread would stop. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Sat Feb 5 08:25:43 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 04 Feb 2022 23:25:43 +0100 Subject: [TUHS] more about Brian... In-Reply-To: <1644006490.2458.78.camel@mni.thm.de> References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <1644006490.2458.78.camel@mni.thm.de> Message-ID: <20220204222543.ZU3DO%steffen@sdaoden.eu> Hellwig Geisse wrote in <1644006490.2458.78.camel at mni.thm.de>: |Hi Thomas, | |On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: |> I tell you one thing: I never ever experienced any problems with |> traditional malloc()/free(). | |did you ever write a program which does heavy malloc()/free() |on complicated (i.e., shared) data structures *and* runs for |days, perhaps weeks? IMO it's very difficult to do this without Yes. |a GC, and you have to exercise quite an amount of discipline |to do it right. And i fail to see the relationship really. Especially given that all kernels and all daemons i know (he!) are all written in C. Object based programming is surely easier to manage, as containers manage containers manage containers manage whatever allocations. So you have a very natural chain of life, so to say. |> A kernel using GC is a kernel written by inexperienced kids. | |Well, not exactly. Niklaus Wirth's Oberon kernel (around 1990) |used a GC, and it did that quite efficiently. Well i have no idea of that also really, so i am not saying anything. I never liked GC; i looked at the source of "that" C GC however (yes, i have forgotten the name). It maybe different to languages like Nim or Lua or, sigh, JAVA, Go and such environments etc., where possibly every object is reference counted. And that where recursive mutexes are declared evil for performance reasons, and kernel code is full of ASSERT(is_locked()) stuff. But this is speculative execution and thus far out of my league. --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 steffen at sdaoden.eu Sat Feb 5 08:30:08 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 04 Feb 2022 23:30:08 +0100 Subject: [TUHS] more about Brian... In-Reply-To: <8901533.793.1644008621545.JavaMail.root@zimbraanteil> References: <8901533.793.1644008621545.JavaMail.root@zimbraanteil> Message-ID: <20220204223008.vEwDN%steffen@sdaoden.eu> Jim Capp wrote in <8901533.793.1644008621545.JavaMail.root at zimbraanteil>: |I have a subsystem that populates a database from disparate data streams. |It's been known to run for years without restarting, thanks to valgrind. Oh please, not. Have they fixed their file descriptor problems? Just go a bit and your allocator will tell you what there still is, and where it came from. I mean gigantic billions of modules plugged together to form a brilliant whole that is larger than its particels may be harder. $ prt-get quickdep libreoffice libnghttp2 openssl zlib xz expat jsoncpp attr bzip2 lzo libuv lzlib ncurses rhash ninja libffi libnsl libtirpc mpdecimal xorg-util-macros libgmp chrpath fakeroot giflib libpcre kmod db nasm xorg-libpciaccess xorg-libpixman libspiro libuninameslist libgpg-error linux-pam npth alsa-lib libogg libvisual opus hyphen icu cppunit glm libexttextcat hunspell libnumbertext libpaper libqrcodegen libtommath lpsolve libaio libpcre2 nspr libtool unzip file libpng potrace zstd libxml2 dbus neon acl elfutils zip readline xorg-xtrans glpk libmpfr swig eudev libgcrypt libksba libassuan libcap libvorbis libmythes curl boost libxslt libarchive gdbm sqlite3 unixodbc gcc-fortran util-linux libusb libtheora librevenge mdds raptor xmlsec cmake perl python3 nss openblas pinentry libabw libepubgen libwpd libmwaw libodfgen libpagemaker libqxp libstaroffice libvisio libwps libzmf rasqal abseil-cpp clucene metis libjpeg-turbo brotli libcuckoo fmt mariadb p5-xml-parser python3-setuptools xorg-xcb-proto lapack gnupg libmspub libwpg redland libtiff woff2 spdlog intltool meson python3-libxml2 llvm python3-markupsafe python3-chardet python3-soupsieve python3-cssselect python3-cython python3-webencodings coin-or-coinutils suitesparse gpgme libwebp lcms2 sane libixion xorg-xorgproto glib libdrm fribidi freetype orc itstool python3-mako python3-beautifulsoup4 python3-html5lib coin-or-osi libcdr libfreehand openjpeg2 liborcus xorg-libxau xorg-libxdmcp xorg-libxshmfence xorg-libice gobject-introspection liblangtag fontconfig graphite2 shared-mime-info python3-lxml coin-or-clp xorg-libxcb xorg-libsm atk graphene gstreamer libgudev libe-book libetonyek gdk-pixbuf coin-or-cgl xorg-libx11 xorg-xcb-util coin-or-cbc xorg-libxext xorg-libxfixes xorg-libxrender coin-or-mp xorg-libxinerama libglvnd xorg-libxv xorg-libxxf86vm xorg-libxi xorg-libxdamage xorg-libxcomposite xorg-libxcursor xorg-libxrandr cairo gl-headers xorg-libxvmc xorg-libxtst box2d harfbuzz mesa at-spi2-core xorg-libxft libepoxy at-spi2-atk pango gtk3 gst-plugins-base fontforge libreoffice It could be this requires a bit of work. --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 steffen at sdaoden.eu Sat Feb 5 08:32:39 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 04 Feb 2022 23:32:39 +0100 Subject: [TUHS] Go vs. Rust, and etc. (was: more about Brian...) In-Reply-To: References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> Message-ID: <20220204223239.uG3AQ%steffen@sdaoden.eu> Richard Salz wrote in : |I really wish there were a manpage that says "foo is the one true language" |just like ed(1). Then this thread would stop. |I really wish there were a manpage that says "foo is the one true langua\ |ge" just like ed(1).  Then this thread would stop. Manpages are second class citizens. --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 thomas.paulsen at firemail.de Sat Feb 5 09:05:06 2022 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Sat, 05 Feb 2022 00:05:06 +0100 Subject: [TUHS] Go vs. Rust, and etc. (was: more about Brian...) In-Reply-To: References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> Message-ID: <240ef01768d8f12fc50ec7a424bc4ec1@firemail.de> An HTML attachment was scrubbed... URL: From crossd at gmail.com Sat Feb 5 09:18:09 2022 From: crossd at gmail.com (Dan Cross) Date: Fri, 4 Feb 2022 18:18:09 -0500 Subject: [TUHS] more about Brian... [really Rust] In-Reply-To: <202202040234.2142YeKN3307556@darkstar.fourwinds.com> References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <202202040234.2142YeKN3307556@darkstar.fourwinds.com> Message-ID: [TUHS to Bcc, +COFF ] This isn't exactly COFF material, but I don't know what list is more appropriate. On Thu, Feb 3, 2022 at 9:41 PM Jon Steinhart wrote: > Adam Thornton writes: > > Do the august personages on this list have opinions about Rust? > > People who generally have tastes consonant with mine tell me I'd like > Rust. > > Well, I'm not an august personage and am not a Rust programmer. I did > spend a while trying to learn rust a while ago and wasn't impressed. > > Now, I'm heavily biased in that I think that it doesn't add value to keep > inventing new languages to do the same old things, and I didn't see > anything > in Rust that I couldn't do in a myriad of other languages. > I'm a Rust programmer, mostly using it for bare-metal kernel programming (though in my current gig, I find myself mostly in Rust userspace...ironically, it's back to C for the kernel). That said, I'm not a fan-boy for the language: it's not perfect. I've written basically four kernels in Rust now, to varying degrees of complexity from, "turn the computer on, spit hello-world out of the UART, and halt" to most of a v6 clone (which I really need to get around to finishing) to two rather more complex ones. I've done one ersatz kernel in C, and worked on a bunch more in C over the years. Between the two languages, I'd pick Rust over C for similar projects. Why? Because it really doesn't just do the same old things: it adds new stuff. Honest! Further, the sad reality (and the tie-in with TUHS/COFF) is that modern C has strayed far from its roots as a vehicle for systems programming, in particular, for implementing operating system kernels ( https://arxiv.org/pdf/2201.07845.pdf). C _implementations_ target the abstract machine defined in the C standard, not hardware, and they use "undefined behavior" as an excuse to make aggressive optimizations that change the semantics of one's program in such a way that some of the tricks you really do have to do when implementing an OS are just not easily done. For example, consider this code: uint16_t mul(uint16_t a, uint16_t b) { return a * b; } Does that code ever exhibit undefined behavior? The answer is that "it depends, but on most platforms, yes." Why? Because most often uint16_t is a typedef for `unsigned short int`, and because `short int` is of lesser "rank" than `int` and usually not as wide, the "usual arithmetic conversions" will apply before the multiplication. This means that the unsigned shorts will be converted to (signed) int. But on many platforms `int` will be a 32-bit integer (even 64-bit platforms!). However, the range of an unsigned 16-bit integer is such that the product of two uint16_t's can include values whose product is larger than whatever is representable in a signed 32-bit int, leading to overflow, and signed integer overflow is undefined overflow is undefined behavior. But does that _matter_ in practice? Potentially: since signed int overflow is UB, the compiler can decide it would never happen. And so if the compiler decides, for whatever reason, that (say) a saturating multiplication is the best way to implement that multiplication, then that simple single-expression function will yield results that (I'm pretty sure...) the programmer did not anticipate for some subset of inputs. How do you fix this? uint16_t mul(uint16_t a, uint16_t b) { unsigned int aa = a, bb = b; return aa * bb; } That may sound very hypothetical, but similar things have shown up in the wild: https://people.csail.mit.edu/nickolai/papers/wang-undef-2012-08-21.pdf In practice, this one is unlikely. But it's not impossible: the compiler would be right, the programmer would be wrong. One thing I've realized about C is that successive generations of compilers have tightened the noose on UB so that code that has worked for *years* all of a sudden breaks one day. There be dragons in our code. After being bit one too many times by such issues in C I decided to investigate alternatives. The choices at the time were either Rust or Go: for the latter, one gets a nice, relatively simple language, but a big complex runtime. For the former, you get a big, ugly language, but a minimal runtime akin to C: to get it going, you really don't have to do much more than set up a stack and join to a function. While people have built systems running Go at the kernel level ( https://pdos.csail.mit.edu/papers/biscuit.pdf), that seemed like a pretty heavy lift. On the other hand, if Rust could deliver on a quarter of the promises it made, I'd be ahead of the game. That was sometime in the latter half of 2018 and since then I've generally been pleasantly surprised at how much it really does deliver. For the above example, integer overflow is defined to trap. If you want wrapping (or saturating!) semantics, you request those explicitly: fn mul(a: u16, b: u16) -> u16 { a.wrapping_mul(b) } This is perfectly well-defined, and guaranteed to work pretty much forever. But, my real issue came from some of the tutorials that I perused. Rust is > being sold as "safer". As near as I can tell from the tutorials, the model > is that nothing works unless you enable it. Want to be able to write a > variable? Turn that on. So it seemed like the general style was to write > code and then turn various things on until it ran. > That's one way to look at it, but I don't think that's the intent: the model is rather, "immutable by default." Rust forces you to think about mutability, ownership, and the semantics of taking references, because the compiler enforces invariants on all of those things in a way that pretty much no other language does. It is opinionated, and not shy about sharing those opinions. To me, this implies a mindset that programming errors are more important > than thinking errors, and that one should hack on things until they work > instead of thinking about what one is doing. I know that that's the > modern definition of programming, but will never be for me. It's funny, I've had the exact opposite experience. I have found that it actually forces you to invest a _lot_ more in-up front thought about what you're doing. Writing code first, and then sprinkling in `mut` and `unsafe` until it compiles is a symptom of writing what we called "crust" on my last project at Google: that is, "C in Rust syntax." When I convinced our team to switch from C(++) to Rust, but none of us were really particularly adept at the language, and all hit similar walls of frustration; at one point, an engineer quipped, "this language has a near-vertical learning curve." And it's true that we took a multi-week productivity hit, but once we reached a certain level of familiarity, something equally curious happened: our debugging load went way, _way_ down and we started moving much faster. It turned out it was harder to get a Rust program to build at first, particularly with the bad habits we'd built up over decades of whatever languages we came from, but once it did those programs very often ran correctly the first time. You had to think _really hard_ about what data structures to use, their ownership semantics, their visibility, locking, etc. A lot of us had to absorb an emotional gut punch when the compiler showed us things that we _knew_ were correct were, in fact, not correct. But once code compiled, it tended not to have the kinds of errors that were insta-panics or triple faults (or worse, silent corruption you only noticed a million instructions later): no dangling pointers, no use-after-free bugs, no data races, no integer overflow, no out-of-bounds array references, etc. Simply put, the language _forced_ a level of discipline on us that even veteran C programmers didn't have. It also let us program at a moderately higher level of abstraction; off-by-one errors were gone because we had things like iterators. ADTs and a "Maybe" monad (the `Result` type) greatly improved our error handling. `match` statements have to be exhaustive so you can't add a variant to an enum and forget to update code to account in just that one place (the compiler squawks at you). It's a small point, but the `?` operator removed a lot of tedious boilerplate from our code, making things clearer without sacrificing robust failure handling. Tuples for multiple return values instead of using pointers for output arguments (that have to be manually checked for validity!) are really useful. Pattern matching and destructuring in a fast systems language? Good to go. In contrast, I ran into a "bug" of sorts with KVM due to code I wrote that manifested itself as an "x86 emulation error" when it was anything but: I was turning on paging very early in boot, and I had manually set up an identity mapping for the low 4GiB of address space for the jump from 32-bit to 64-bit mode. I used gigabyte pages since it was easy, and I figured it would be supported, but I foolishly didn't check the CPU features when running this under virtualization for testing and got that weird KVM error. What was going on? It turned out KVM in this case didn't support gig pages, but the hardware did; the software worked just fine until the first time the kernel went to do IO. Then, when the hypervisor went to fetch the instruction bytes to emulate the IO instruction, it saw the gig-sized pages and errored. Since the incompatibility was manifest deep in the bowels of the instruction emulation code, that was the error that returned, even though it had nothing to do with instruction emulation. It would have been nice to plumb through some kind of meaningful error message, but in C that's annoying at best. In Rust, it's trivial. https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ 70% of CVEs out of Microsoft over the last 15 years have been memory safety issues, and while we may poo-poo MSFT, they've got some really great engineers and let's be honest: Unix and Linux aren't that much better in this department. Our best and brightest C programmers continue to turn out highly buggy programs despite 50 years of experience. But it's not perfect. The allocator interface was a pain (it's defined to panic on allocation failure; I'm cool with a NULL return), though work is ongoing in this area. There's no ergonomic way to initialize an object 'in-place' (https://mcyoung.xyz/2021/04/26/move-ctors/), and there's no great way to say, essentially, "this points at RAM; even though I haven't initialized it, just trust me don't poison it" ( https://users.rust-lang.org/t/is-it-possible-to-read-uninitialized-memory-without-invoking-ub/63092 -- we really need a `freeze` operation). However, right now? I think it sits at a local maxima for systems languages targeting bare-metal. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From web at loomcom.com Sat Feb 5 09:15:19 2022 From: web at loomcom.com (Seth J. Morabito) Date: Fri, 04 Feb 2022 15:15:19 -0800 Subject: [TUHS] Go vs. Rust, and etc. (was: more about Brian...) In-Reply-To: References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> Message-ID: <871r0iz0cg.fsf@loomcom.com> Richard Salz writes: > I really wish there were a manpage that says "foo is the one true > language" just like ed(1). Then this thread would stop. [...] -rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed -rwxr-xr-t 4 root 1310720 Jan 1 1970 /usr/ucb/vi -rwxr-xr-x 1 root 5.89824e37 Oct 22 1990 /usr/bin/emacs [...] Of course, the wonderful thing about programming languages is that, like editors, there are so many to choose from and everyone can find one that they find enjoyment using. I really like C, and Rust, and Haskell, and Lisp, and Python, and Erlang, and many others. Some others I enjoy quite a bit less than these. And all of them can be used to write good programs and bad programs. -Seth -- Seth Morabito web at loomcom.com Poulsbo, WA, USA From athornton at gmail.com Sat Feb 5 11:41:26 2022 From: athornton at gmail.com (Adam Thornton) Date: Fri, 4 Feb 2022 18:41:26 -0700 Subject: [TUHS] Go vs. Rust, and etc. (was: more about Brian...) In-Reply-To: <871r0iz0cg.fsf@loomcom.com> References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <871r0iz0cg.fsf@loomcom.com> Message-ID: I've written COBOL for money. I'm not proud of it but I won't deny it. I've written Python, C, Perl, and Go (and doubtless some others) for both love and money at different times. I've written LISP (well, Scheme) for a grade and for love. I've written Inform 6 and 7, and 6502 assembler, and a bunch of other things, just for love. I am sure I couldn't stop writing programs if I had to. As Emmylou Harris sang: Well, I did it for kicks and I did it for hate I did it for lust and I did it for faith I did it for need and I did it for love Addiction stayed on tight like a glove On Fri, Feb 4, 2022 at 4:22 PM Seth J. Morabito wrote: > > I really like C, and Rust, and Haskell, and Lisp, and Python, and > Erlang, and many others. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brantley at coraid.com Sun Feb 6 03:00:23 2022 From: brantley at coraid.com (Brantley Coile) Date: Sat, 5 Feb 2022 17:00:23 +0000 Subject: [TUHS] 1994 One-minute Video for the UNIX 25th Birthday Party Message-ID: <1B0C3464-3807-4E37-8586-59492529BB39@coraid.com> https://www.youtube.com/watch?v=EmcSpzpYnRk From cmhanson at eschatologist.net Sun Feb 6 09:57:41 2022 From: cmhanson at eschatologist.net (Chris Hanson) Date: Sat, 5 Feb 2022 15:57:41 -0800 Subject: [TUHS] BSD 4.1, 4.1x, Quasijarus, and 4.3x In-Reply-To: References: Message-ID: On Feb 1, 2022, at 4:22 PM, Clem Cole wrote: > > Right - either current NetBSD or the Ultrix 4.5 is what I would do. If NetBSD will run the Ultrix layered products, that would be the system with the most; but I'm not sure if that will work. Ultrix for instance supports DEC (VMS) FTN - which I know you (Will) have been messing with. That is the best (most complete) FTN for Vaxen. I believe there is Ada, PL/1 and maybe even Basic2 and Cobol/RPG [I think most of not all of the VMS languages for the VAX were released on Ultrix but frankly, I don't remember]. I don’t know if NetBSD has Ultrix binary compatibility on VAX, but it does on MIPS—so much so that a few years back, someone accidentally pointed their NetBSD boot at the wrong partition on their DECstation and Ultrix booted right up using the NetBSD kernel! — Chris From lm at mcvoy.com Sun Feb 6 10:56:09 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 5 Feb 2022 16:56:09 -0800 Subject: [TUHS] more about Brian... In-Reply-To: <1644006490.2458.78.camel@mni.thm.de> References: <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <1644006490.2458.78.camel@mni.thm.de> Message-ID: <20220206005609.GG3045@mcvoy.com> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: > Hi Thomas, > > On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: > > I tell you one thing: I never ever experienced any problems with > > traditional malloc()/free().?? > > did you ever write a program which does heavy malloc()/free() > on complicated (i.e., shared) data structures *and* runs for > days, perhaps weeks? IMO it's very difficult to do this without > a GC, and you have to exercise quite an amount of discipline > to do it right. I've done this and I've employed people who have done this. We're a dieing breed, the focus seems to be on programming languages and tools for idiots. People don't want to learn the discipline it takes to work with malloc()/free(). It's sad. From will.senn at gmail.com Sun Feb 6 11:10:57 2022 From: will.senn at gmail.com (Will Senn) Date: Sat, 5 Feb 2022 19:10:57 -0600 Subject: [TUHS] more about Brian... In-Reply-To: <20220206005609.GG3045@mcvoy.com> References: <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> Message-ID: <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> On 2/5/22 6:56 PM, Larry McVoy wrote: > On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: >> Hi Thomas, >> >> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: >>> I tell you one thing: I never ever experienced any problems with >>> traditional malloc()/free().?? >> did you ever write a program which does heavy malloc()/free() >> on complicated (i.e., shared) data structures *and* runs for >> days, perhaps weeks? IMO it's very difficult to do this without >> a GC, and you have to exercise quite an amount of discipline >> to do it right. > I've done this and I've employed people who have done this. We're > a dieing breed, the focus seems to be on programming languages and > tools for idiots. People don't want to learn the discipline it takes > to work with malloc()/free(). It's sad. I completely agree. This is ridiculous. Do modern programmer's seriously think that the old code wasn't complex or robust? Sheesh, there's code out there that has run through more millions of transactions an hour for more years than most of these folks have been alive. There's also code that's been running without any updates, for decades. Most code written by the newbreed won't run for a month without surfacing dozens of bugs. Margaret Hamilton would prolly have some choice words for these folks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sun Feb 6 14:52:12 2022 From: robpike at gmail.com (Rob Pike) Date: Sun, 6 Feb 2022 15:52:12 +1100 Subject: [TUHS] more about Brian... In-Reply-To: <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> References: <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> Message-ID: Be careful with your castigations. Yes, there is lots of old working code, but keep in mind that that code has often not been as widely tested and deployed as much of the software that runs today. The fact that it worked well on old hardware doesn't mean it will be suitable for modern networked remotely administered multicore machines pounded on by millions of people. And speaking of multicore, it's possible to write code using malloc/free that doesn't leak when run concurrently, but it's a lot easier, safer, and robust to let the machine do the memory accounting. And the fact that "kids today" can't do it doesn't mean they are lazy or failures, it means they grew up in a different time. And a lot of them are as capable as you all, just in a different environment. Lately this list has a lot of attitude and prejudice pretending to be wisdom and superiority. -rob On Sun, Feb 6, 2022 at 12:11 PM Will Senn wrote: > On 2/5/22 6:56 PM, Larry McVoy wrote: > > On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: > > Hi Thomas, > > On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: > > I tell you one thing: I never ever experienced any problems with > traditional malloc()/free().?? > > did you ever write a program which does heavy malloc()/free() > on complicated (i.e., shared) data structures *and* runs for > days, perhaps weeks? IMO it's very difficult to do this without > a GC, and you have to exercise quite an amount of discipline > to do it right. > > I've done this and I've employed people who have done this. We're > a dieing breed, the focus seems to be on programming languages and > tools for idiots. People don't want to learn the discipline it takes > to work with malloc()/free(). It's sad. > > > I completely agree. This is ridiculous. Do modern programmer's seriously > think that the old code wasn't complex or robust? Sheesh, there's code out > there that has run through more millions of transactions an hour for more > years than most of these folks have been alive. There's also code that's > been running without any updates, for decades. Most code written by the > newbreed won't run for a month without surfacing dozens of bugs. Margaret > Hamilton would prolly have some choice words for these folks. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From halbert at halwitz.org Sun Feb 6 14:58:40 2022 From: halbert at halwitz.org (Dan Halbert) Date: Sat, 5 Feb 2022 23:58:40 -0500 Subject: [TUHS] more about Brian... In-Reply-To: References: <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> Message-ID: <6b7bfa10-65b1-a56e-e143-c8663532b934@halwitz.org>  Thank you, Rob. I composed a similar reply, and debated whether to send it. You hit all the right points more succinctly and directly. --Dan H. On 2/5/22 23:52, Rob Pike wrote: > Be careful with your castigations. Yes, there is lots of old working > code, but keep in mind that that code has often not been as widely > tested and deployed as much of the software that runs today. The fact > that it worked well on old hardware doesn't mean it will be suitable > for modern networked remotely administered multicore machines pounded > on by millions of people. > > And speaking of multicore, it's possible to write code using > malloc/free that doesn't leak when run concurrently, but it's a lot > easier, safer, and robust to let the machine do the memory accounting. > And the fact that "kids today" can't do it doesn't mean they are lazy > or failures, it means they grew up in a different time. And a lot of > them are as capable as you all, just in a different environment. > > Lately this list has a lot of attitude and prejudice pretending to be > wisdom and superiority. > > -rob > > > On Sun, Feb 6, 2022 at 12:11 PM Will Senn wrote: > > On 2/5/22 6:56 PM, Larry McVoy wrote: >> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: >>> Hi Thomas, >>> >>> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: >>>> I tell you one thing: I never ever experienced any problems with >>>> traditional malloc()/free().?? >>> did you ever write a program which does heavy malloc()/free() >>> on complicated (i.e., shared) data structures *and* runs for >>> days, perhaps weeks? IMO it's very difficult to do this without >>> a GC, and you have to exercise quite an amount of discipline >>> to do it right. >> I've done this and I've employed people who have done this. We're >> a dieing breed, the focus seems to be on programming languages and >> tools for idiots. People don't want to learn the discipline it takes >> to work with malloc()/free(). It's sad. > > I completely agree. This is ridiculous. Do modern programmer's > seriously think that the old code wasn't complex or robust? > Sheesh, there's code out there that has run through more millions > of transactions an hour for more years than most of these folks > have been alive. There's also code that's been running without any > updates, for decades. Most code written by the newbreed won't run > for a month without surfacing dozens of bugs. Margaret Hamilton > would prolly have some choice words for these folks. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sun Feb 6 15:06:20 2022 From: will.senn at gmail.com (Will Senn) Date: Sat, 5 Feb 2022 23:06:20 -0600 Subject: [TUHS] more about Brian... In-Reply-To: References: <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> Message-ID: Sure. It's gone off topic, quite a ways. I wasn't really castigating, just marveling at the hubris. On 2/5/22 10:52 PM, Rob Pike wrote: > Be careful with your castigations. Yes, there is lots of old working > code, but keep in mind that that code has often not been as widely > tested and deployed as much of the software that runs today. The fact > that it worked well on old hardware doesn't mean it will be suitable > for modern networked remotely administered multicore machines pounded > on by millions of people. > > And speaking of multicore, it's possible to write code using > malloc/free that doesn't leak when run concurrently, but it's a lot > easier, safer, and robust to let the machine do the memory accounting. > And the fact that "kids today" can't do it doesn't mean they are lazy > or failures, it means they grew up in a different time. And a lot of > them are as capable as you all, just in a different environment. > > Lately this list has a lot of attitude and prejudice pretending to be > wisdom and superiority. > > -rob > > > On Sun, Feb 6, 2022 at 12:11 PM Will Senn wrote: > > On 2/5/22 6:56 PM, Larry McVoy wrote: >> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: >>> Hi Thomas, >>> >>> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: >>>> I tell you one thing: I never ever experienced any problems with >>>> traditional malloc()/free().?? >>> did you ever write a program which does heavy malloc()/free() >>> on complicated (i.e., shared) data structures *and* runs for >>> days, perhaps weeks? IMO it's very difficult to do this without >>> a GC, and you have to exercise quite an amount of discipline >>> to do it right. >> I've done this and I've employed people who have done this. We're >> a dieing breed, the focus seems to be on programming languages and >> tools for idiots. People don't want to learn the discipline it takes >> to work with malloc()/free(). It's sad. > > I completely agree. This is ridiculous. Do modern programmer's > seriously think that the old code wasn't complex or robust? > Sheesh, there's code out there that has run through more millions > of transactions an hour for more years than most of these folks > have been alive. There's also code that's been running without any > updates, for decades. Most code written by the newbreed won't run > for a month without surfacing dozens of bugs. Margaret Hamilton > would prolly have some choice words for these folks. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erc at pobox.com Sun Feb 6 16:19:55 2022 From: erc at pobox.com (Ed Carp) Date: Sat, 5 Feb 2022 23:19:55 -0700 Subject: [TUHS] more about Brian... In-Reply-To: References: <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> Message-ID: "it's a lot easier, safer, and robust to let the machine do the memory accounting" I disagree. "The machine" is, as you know, is in reality app code built on top of frameworks built on top of libraries built on top of more libraries built on top of malloc/free calls. While the automated testing tools are a lot better than they were when I started coding C back in 1985, we're still talking about a *lot* of complexity and a lot of layers of code, and programmers today know far less about things like boundary conditions, off-by-one bugs, and the like that bit us in the ass - hard - and so we learned to watch for those sorts of things. On 2/5/22, Rob Pike wrote: > Be careful with your castigations. Yes, there is lots of old working code, > but keep in mind that that code has often not been as widely tested and > deployed as much of the software that runs today. The fact that it worked > well on old hardware doesn't mean it will be suitable for modern networked > remotely administered multicore machines pounded on by millions of people. > > And speaking of multicore, it's possible to write code using malloc/free > that doesn't leak when run concurrently, but it's a lot easier, safer, and > robust to let the machine do the memory accounting. And the fact that "kids > today" can't do it doesn't mean they are lazy or failures, it means they > grew up in a different time. And a lot of them are as capable as you all, > just in a different environment. > > Lately this list has a lot of attitude and prejudice pretending to be > wisdom and superiority. > > -rob > > > On Sun, Feb 6, 2022 at 12:11 PM Will Senn wrote: > >> On 2/5/22 6:56 PM, Larry McVoy wrote: >> >> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: >> >> Hi Thomas, >> >> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: >> >> I tell you one thing: I never ever experienced any problems with >> traditional malloc()/free().?? >> >> did you ever write a program which does heavy malloc()/free() >> on complicated (i.e., shared) data structures *and* runs for >> days, perhaps weeks? IMO it's very difficult to do this without >> a GC, and you have to exercise quite an amount of discipline >> to do it right. >> >> I've done this and I've employed people who have done this. We're >> a dieing breed, the focus seems to be on programming languages and >> tools for idiots. People don't want to learn the discipline it takes >> to work with malloc()/free(). It's sad. >> >> >> I completely agree. This is ridiculous. Do modern programmer's seriously >> think that the old code wasn't complex or robust? Sheesh, there's code >> out >> there that has run through more millions of transactions an hour for more >> years than most of these folks have been alive. There's also code that's >> been running without any updates, for decades. Most code written by the >> newbreed won't run for a month without surfacing dozens of bugs. Margaret >> Hamilton would prolly have some choice words for these folks. >> >> >> > From robpike at gmail.com Sun Feb 6 16:27:50 2022 From: robpike at gmail.com (Rob Pike) Date: Sun, 6 Feb 2022 17:27:50 +1100 Subject: [TUHS] more about Brian... In-Reply-To: References: <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> Message-ID: I don't understand your disagreement. In what way is automatic memory management harder, more unsafe, and less robust than hand-written memory management using malloc and free? You seem to think that garbage collection only exists in languages that have a smell you don't like. Perhaps that's true, but it's been around for 60 or more years and a lot of important languages use it, while the programmers that use those languages are often quite capable. Using malloc and free might be a badge of honor to some, but it's also a failure of automation. This discussion should probably go to COFF, or perhaps I should just leave the list. I am starting to feel uncomfortable here. Too much swagger. -rob On Sun, Feb 6, 2022 at 5:19 PM Ed Carp wrote: > "it's a lot easier, safer, and robust to let the machine do the memory > accounting" > > I disagree. "The machine" is, as you know, is in reality app code > built on top of frameworks built on top of libraries built on top of > more libraries built on top of malloc/free calls. While the automated > testing tools are a lot better than they were when I started coding C > back in 1985, we're still talking about a *lot* of complexity and a > lot of layers of code, and programmers today know far less about > things like boundary conditions, off-by-one bugs, and the like that > bit us in the ass - hard - and so we learned to watch for those sorts > of things. > > On 2/5/22, Rob Pike wrote: > > Be careful with your castigations. Yes, there is lots of old working > code, > > but keep in mind that that code has often not been as widely tested and > > deployed as much of the software that runs today. The fact that it worked > > well on old hardware doesn't mean it will be suitable for modern > networked > > remotely administered multicore machines pounded on by millions of > people. > > > > And speaking of multicore, it's possible to write code using malloc/free > > that doesn't leak when run concurrently, but it's a lot easier, safer, > and > > robust to let the machine do the memory accounting. And the fact that > "kids > > today" can't do it doesn't mean they are lazy or failures, it means they > > grew up in a different time. And a lot of them are as capable as you all, > > just in a different environment. > > > > Lately this list has a lot of attitude and prejudice pretending to be > > wisdom and superiority. > > > > -rob > > > > > > On Sun, Feb 6, 2022 at 12:11 PM Will Senn wrote: > > > >> On 2/5/22 6:56 PM, Larry McVoy wrote: > >> > >> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: > >> > >> Hi Thomas, > >> > >> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: > >> > >> I tell you one thing: I never ever experienced any problems with > >> traditional malloc()/free().?? > >> > >> did you ever write a program which does heavy malloc()/free() > >> on complicated (i.e., shared) data structures *and* runs for > >> days, perhaps weeks? IMO it's very difficult to do this without > >> a GC, and you have to exercise quite an amount of discipline > >> to do it right. > >> > >> I've done this and I've employed people who have done this. We're > >> a dieing breed, the focus seems to be on programming languages and > >> tools for idiots. People don't want to learn the discipline it takes > >> to work with malloc()/free(). It's sad. > >> > >> > >> I completely agree. This is ridiculous. Do modern programmer's seriously > >> think that the old code wasn't complex or robust? Sheesh, there's code > >> out > >> there that has run through more millions of transactions an hour for > more > >> years than most of these folks have been alive. There's also code that's > >> been running without any updates, for decades. Most code written by the > >> newbreed won't run for a month without surfacing dozens of bugs. > Margaret > >> Hamilton would prolly have some choice words for these folks. > >> > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stu at remphrey.net Sun Feb 6 16:40:20 2022 From: stu at remphrey.net (Stuart Remphrey) Date: Sun, 6 Feb 2022 14:40:20 +0800 Subject: [TUHS] more about Brian... In-Reply-To: References: <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> Message-ID: I like the point that malloc()/free() could be seen as a "failure of automation". As to the GC and (Go | Rust) vs (C | Java | C++) earlier in this increasingly-off-topic thread: perhaps it's an issue of whether that automation is applied at runtime or compile-time... (the latter still requiring guidance from the programmer, trading some programmer-brain-time against cpu-execution-time & memory space?) On Sun, 6 Feb 2022, 14:28 Rob Pike, wrote: > I don't understand your disagreement. In what way is automatic memory > management harder, more unsafe, and less robust than hand-written memory > management using malloc and free? > > You seem to think that garbage collection only exists in languages that > have a smell you don't like. Perhaps that's true, but it's been around for > 60 or more years and a lot of important languages use it, while the > programmers that use those languages are often quite capable. > > Using malloc and free might be a badge of honor to some, but it's also a > failure of automation. > > This discussion should probably go to COFF, or perhaps I should just leave > the list. I am starting to feel uncomfortable here. Too much swagger. > > -rob > > > On Sun, Feb 6, 2022 at 5:19 PM Ed Carp wrote: > >> "it's a lot easier, safer, and robust to let the machine do the memory >> accounting" >> >> I disagree. "The machine" is, as you know, is in reality app code >> built on top of frameworks built on top of libraries built on top of >> more libraries built on top of malloc/free calls. While the automated >> testing tools are a lot better than they were when I started coding C >> back in 1985, we're still talking about a *lot* of complexity and a >> lot of layers of code, and programmers today know far less about >> things like boundary conditions, off-by-one bugs, and the like that >> bit us in the ass - hard - and so we learned to watch for those sorts >> of things. >> >> On 2/5/22, Rob Pike wrote: >> > Be careful with your castigations. Yes, there is lots of old working >> code, >> > but keep in mind that that code has often not been as widely tested and >> > deployed as much of the software that runs today. The fact that it >> worked >> > well on old hardware doesn't mean it will be suitable for modern >> networked >> > remotely administered multicore machines pounded on by millions of >> people. >> > >> > And speaking of multicore, it's possible to write code using malloc/free >> > that doesn't leak when run concurrently, but it's a lot easier, safer, >> and >> > robust to let the machine do the memory accounting. And the fact that >> "kids >> > today" can't do it doesn't mean they are lazy or failures, it means they >> > grew up in a different time. And a lot of them are as capable as you >> all, >> > just in a different environment. >> > >> > Lately this list has a lot of attitude and prejudice pretending to be >> > wisdom and superiority. >> > >> > -rob >> > >> > >> > On Sun, Feb 6, 2022 at 12:11 PM Will Senn wrote: >> > >> >> On 2/5/22 6:56 PM, Larry McVoy wrote: >> >> >> >> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: >> >> >> >> Hi Thomas, >> >> >> >> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: >> >> >> >> I tell you one thing: I never ever experienced any problems with >> >> traditional malloc()/free().?? >> >> >> >> did you ever write a program which does heavy malloc()/free() >> >> on complicated (i.e., shared) data structures *and* runs for >> >> days, perhaps weeks? IMO it's very difficult to do this without >> >> a GC, and you have to exercise quite an amount of discipline >> >> to do it right. >> >> >> >> I've done this and I've employed people who have done this. We're >> >> a dieing breed, the focus seems to be on programming languages and >> >> tools for idiots. People don't want to learn the discipline it takes >> >> to work with malloc()/free(). It's sad. >> >> >> >> >> >> I completely agree. This is ridiculous. Do modern programmer's >> seriously >> >> think that the old code wasn't complex or robust? Sheesh, there's code >> >> out >> >> there that has run through more millions of transactions an hour for >> more >> >> years than most of these folks have been alive. There's also code >> that's >> >> been running without any updates, for decades. Most code written by the >> >> newbreed won't run for a month without surfacing dozens of bugs. >> Margaret >> >> Hamilton would prolly have some choice words for these folks. >> >> >> >> >> >> >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Sun Feb 6 16:44:12 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Sat, 5 Feb 2022 22:44:12 -0800 Subject: [TUHS] more about Brian... In-Reply-To: References: <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> Message-ID: <10B8CDC8-12FF-4B93-AD34-3393BA5C13D5@iitbombay.org> Just ignore the swagger. I would go further than Rob in that even for sequential programs there is no virtue in sticking to malloc/free if you don't have to. The whole point of automation (for me) is to delegate all the boring and repetitive work to computers so that I can focus on more interesting things! And solving malloc/free related bugs is boring and repetitive. For embedded code in limited space you want to use memory carefully but for most of userland code we don't have to worry about saving every byte. Most userland code is not real time code (and doesn't run on realtime OSes). That doesn't mean using memory like water -- there is a middle ground. Don't blame the GC for incompetently programmed websites or for layers of code using third party libraries using other third party libraries. > On Feb 5, 2022, at 10:27 PM, Rob Pike wrote: > > I don't understand your disagreement. In what way is automatic memory management harder, more unsafe, and less robust than hand-written memory management using malloc and free? > > You seem to think that garbage collection only exists in languages that have a smell you don't like. Perhaps that's true, but it's been around for 60 or more years and a lot of important languages use it, while the programmers that use those languages are often quite capable. > > Using malloc and free might be a badge of honor to some, but it's also a failure of automation. > > This discussion should probably go to COFF, or perhaps I should just leave the list. I am starting to feel uncomfortable here. Too much swagger. > > -rob > > > On Sun, Feb 6, 2022 at 5:19 PM Ed Carp wrote: > "it's a lot easier, safer, and robust to let the machine do the memory > accounting" > > I disagree. "The machine" is, as you know, is in reality app code > built on top of frameworks built on top of libraries built on top of > more libraries built on top of malloc/free calls. While the automated > testing tools are a lot better than they were when I started coding C > back in 1985, we're still talking about a *lot* of complexity and a > lot of layers of code, and programmers today know far less about > things like boundary conditions, off-by-one bugs, and the like that > bit us in the ass - hard - and so we learned to watch for those sorts > of things. > > On 2/5/22, Rob Pike wrote: > > Be careful with your castigations. Yes, there is lots of old working code, > > but keep in mind that that code has often not been as widely tested and > > deployed as much of the software that runs today. The fact that it worked > > well on old hardware doesn't mean it will be suitable for modern networked > > remotely administered multicore machines pounded on by millions of people. > > > > And speaking of multicore, it's possible to write code using malloc/free > > that doesn't leak when run concurrently, but it's a lot easier, safer, and > > robust to let the machine do the memory accounting. And the fact that "kids > > today" can't do it doesn't mean they are lazy or failures, it means they > > grew up in a different time. And a lot of them are as capable as you all, > > just in a different environment. > > > > Lately this list has a lot of attitude and prejudice pretending to be > > wisdom and superiority. > > > > -rob > > > > > > On Sun, Feb 6, 2022 at 12:11 PM Will Senn wrote: > > > >> On 2/5/22 6:56 PM, Larry McVoy wrote: > >> > >> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: > >> > >> Hi Thomas, > >> > >> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: > >> > >> I tell you one thing: I never ever experienced any problems with > >> traditional malloc()/free().?? > >> > >> did you ever write a program which does heavy malloc()/free() > >> on complicated (i.e., shared) data structures *and* runs for > >> days, perhaps weeks? IMO it's very difficult to do this without > >> a GC, and you have to exercise quite an amount of discipline > >> to do it right. > >> > >> I've done this and I've employed people who have done this. We're > >> a dieing breed, the focus seems to be on programming languages and > >> tools for idiots. People don't want to learn the discipline it takes > >> to work with malloc()/free(). It's sad. > >> > >> > >> I completely agree. This is ridiculous. Do modern programmer's seriously > >> think that the old code wasn't complex or robust? Sheesh, there's code > >> out > >> there that has run through more millions of transactions an hour for more > >> years than most of these folks have been alive. There's also code that's > >> been running without any updates, for decades. Most code written by the > >> newbreed won't run for a month without surfacing dozens of bugs. Margaret > >> Hamilton would prolly have some choice words for these folks. > >> > >> > >> > > From ralph at inputplus.co.uk Sun Feb 6 22:52:13 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sun, 06 Feb 2022 12:52:13 +0000 Subject: [TUHS] more about Brian... In-Reply-To: References: <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> Message-ID: <20220206125213.939BD1FE27@orac.inputplus.co.uk> rob wrote: > This discussion should probably go to COFF It should have long ago; way too noisy and off-topic for TUHS. -- Cheers, Ralph. From erc at pobox.com Sun Feb 6 23:14:36 2022 From: erc at pobox.com (Ed Carp) Date: Sun, 6 Feb 2022 06:14:36 -0700 Subject: [TUHS] more about Brian... In-Reply-To: References: <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> Message-ID: Since you made this personal and called me out specifically, I will respond: "In what way is automatic memory management harder, more unsafe, and less robust than hand-written memory management using malloc and free?" Because there's no difference in the two. Someone had to write the "automatic memory management", right? "You seem to think that garbage collection only exists in languages that have a smell you don't like." I said nothing of the kind. You've got me mixed up with someone else. Just because I respond to a thread doesn't mean I agree with everything said in the thread. "Using malloc and free might be a badge of honor to some, but it's also a failure of automation." Again, the automation code has to written by *someone*. It doesn't just appear by itself. "This discussion should probably go to COFF, or perhaps I should just leave the list. I am starting to feel uncomfortable here. Too much swagger." I read through the thread. Just because people don't agree with each other doesn't equate to "swagger". I've seen little evidence of anything other than reasoned analysis and rational, respectful discussion. Was there any sort of personal attacks that I missed? The fact of the matter is, code written with malloc/free, if written carefully, will run for *years*. There are Linux boxes that have been running for literally years without being rebooted, and mainframes and miniframes that get booted only when a piece of hardware fails. From crossd at gmail.com Mon Feb 7 00:13:56 2022 From: crossd at gmail.com (Dan Cross) Date: Sun, 6 Feb 2022 09:13:56 -0500 Subject: [TUHS] more about Brian... In-Reply-To: References: <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> Message-ID: Oh dear. This is getting a little heated. TUHS to Bcc:, replies to COFF. On Sun, Feb 6, 2022 at 8:15 AM Ed Carp wrote: > Since you made this personal and called me out specifically, I will > respond: > > "In what way is automatic memory management harder, more unsafe, and > less robust than hand-written memory management using malloc and > free?" > > Because there's no difference in the two. Someone had to write the > "automatic memory management", right? > I cannot agree with this, there is a big difference. With GC, you are funneling all of the fiddly bits of dealing with memory management through a runtime that is written by a very small pool of people who are intimately familiar with the language, the runtime, the compilation environment, and so on. That group of subject matter experts produce a system that is tested by every application (much like the _implementation_ of malloc/free itself, which is not usually reproduced by every programmer who _uses_ malloc/free). It's like in "pure" functional languages such as Haskell, where everything is immutable: that doesn't mean that registers don't change values, or that memory cells don't get updated, or that IO doesn't happen, or the clock doesn't tick. Rather, it means that the programmer makes a tradeoff where they cede control over those things to the compiler and a runtime written by a constrained set of contributors, in exchange for guarantees those things make about the behavior of the program. With manual malloc/free, one smears responsibility for getting it right across every program that does dynamic memory management. Some get it right; many do not. In many ways, the difference between automatic and manual memory management is like the difference between programming in assembler and programming in a high-level language. People have written reliable, robust assembler for decades (look at the airline industry), but few people would choose to do so today; why? Because it's tedious and life is too short as it is. Further, the probability of error is greater than in a high-level language; why tempt fate? [snip] > "This discussion should probably go to COFF, or perhaps I should just > leave the list. I am starting to feel uncomfortable here. Too much > swagger." > > I read through the thread. Just because people don't agree with each > other doesn't equate to "swagger". I've seen little evidence of > anything other than reasoned analysis and rational, respectful > discussion. Was there any sort of personal attacks that I missed? > It is very difficult, in a forum like this, to divine intent. I know for a fact that I've written things to this list that were interpreted very differently than I meant them. That said, there has definitely been an air that those who do not master manual memory management are just being lazy and that "new" programmers are unskilled. Asserting that this language or that is "ours" due to its authors while that is "theirs" or belongs solely to some corporate sponsor is a bit much. The reality is that languages and operating systems and hardware evolve over time, and a lot of the practices we took for granted 10 years ago deserve reexamination in the light of new context. There's nothing _wrong_ with that, even if it may be uncomfortable (I know it is for me). The fact of the matter is, code written with malloc/free, if written > carefully, will run for *years*. There are Linux boxes that have been > running for literally years without being rebooted, and mainframes and > miniframes that get booted only when a piece of hardware fails. > That there exist C programs that have run for many years without faults is indisputable. Empirically, people _can_ write reliable C programs, but it is often harder than it seems to do so, particularly since the language standard gives so much latitude for implementations to change semantics in surprising ways over time. Just in the past couple of weeks a flaw was revealed in some Linux daemon that allowed privilege escalation to root...due to improper memory management. That flaw had been in production for _12 years_. Sadly, this is not an isolated incident. That said, does manual memory management have a place in modern computing? Of course it does, as you rightly point out. So does assembly language. Rust came up in the context of this thread as a GC'd language, and it may be worth mentioning that Rust uses manual memory management; the language just introduces some facilities that make this safer. For instance, the concept of ownership is elevated to first-class status in Rust, and there are rules about taking references to things; when something's owner goes out of scope, it is "dropped", but the compiler statically enforces that there are no outstanding references to that thing. Regardless, when dealing with some resource it is often the programmer's responsibility to make sure that a suitable drop implementation exists. FWIW, I used to sit down the hall from a large subgroup of the Go developers; we usually ate lunch together. I know that many of them shared my opinion that Rust and Go are very complimentary. No one tool is right for all tasks. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Mon Feb 7 00:15:58 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 6 Feb 2022 06:15:58 -0800 Subject: [TUHS] more about Brian... In-Reply-To: References: <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> Message-ID: <20220206141558.GO3045@mcvoy.com> Let's keep it civil and non-personal, I don't think Rob was pointing at anyone, I think he was pointing at some not so forward thinking. I have to side with Rob on this one, even though I'm squarely in the I like C best camp. While I _can_ do all the malloc/free stuff myself (and have decades of working code to prove it), it's become harder and harder to find other people who can. Younger programmers just sort of stare at you with a "I have to do what?" look. They think you are a dinosaur for working like that when other reasonable languages do that work for you. When I did little-lang.org, granted, not widely used but we used it a lot, it did all the memory management behind the scenes, used reference counting so you never had the big GC sweep that some languages used, worked great. And super pleasant to not have to do all that memory management. Having the languages do more for you, and put up guard rails so people can't make stupid mistakes, seems to be the way of the future. It's not my future, I love C, it does what I want and I can live with what it needs me to do to have working code. But I'm a dinosaur and I know it. I'm not trying to push C where people don't want it. On Sun, Feb 06, 2022 at 06:14:36AM -0700, Ed Carp wrote: > Since you made this personal and called me out specifically, I will respond: > > "In what way is automatic memory management harder, more unsafe, and > less robust than hand-written memory management using malloc and > free?" > > Because there's no difference in the two. Someone had to write the > "automatic memory management", right? > > "You seem to think that garbage collection only exists in languages > that have a smell you don't like." > > I said nothing of the kind. You've got me mixed up with someone else. > Just because I respond to a thread doesn't mean I agree with > everything said in the thread. > > "Using malloc and free might be a badge of honor to some, but it's > also a failure of automation." > > Again, the automation code has to written by *someone*. It doesn't > just appear by itself. > > "This discussion should probably go to COFF, or perhaps I should just > leave the list. I am starting to feel uncomfortable here. Too much > swagger." > > I read through the thread. Just because people don't agree with each > other doesn't equate to "swagger". I've seen little evidence of > anything other than reasoned analysis and rational, respectful > discussion. Was there any sort of personal attacks that I missed? > > The fact of the matter is, code written with malloc/free, if written > carefully, will run for *years*. There are Linux boxes that have been > running for literally years without being rebooted, and mainframes and > miniframes that get booted only when a piece of hardware fails. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From brad at anduin.eldar.org Mon Feb 7 02:16:41 2022 From: brad at anduin.eldar.org (Brad Spencer) Date: Sun, 06 Feb 2022 11:16:41 -0500 Subject: [TUHS] more about Brian... In-Reply-To: <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> (message from Will Senn on Sat, 5 Feb 2022 19:10:57 -0600) Message-ID: Will Senn writes: [snip] >> I've done this and I've employed people who have done this. We're >> a dieing breed, the focus seems to be on programming languages and >> tools for idiots. People don't want to learn the discipline it takes >> to work with malloc()/free(). It's sad. > > I completely agree. This is ridiculous. Do modern programmer's seriously > think that the old code wasn't complex or robust? Sheesh, there's code > out there that has run through more millions of transactions an hour for > more years than most of these folks have been alive. There's also code > that's been running without any updates, for decades. Most code written > by the newbreed won't run for a month without surfacing dozens of bugs. > Margaret Hamilton would prolly have some choice words for these folks. This would appear to be a Not Unix conversation... but... So... the idea that code would run that long was not at all valued at my last job. The management found it simpler and better (for some definition of better) to just reinvent everything every 3 to 6 years. In the mean time, the languages used would change. The idea that one would "have to waste time" figuring out how to use malloc() and free() properly was not looked upon well when the development time would be better spend solving the needed higher level problems. In other words there literally was no interest in creating code that was going to be maintained for more than about 6 years and in a lot of cases would not be maintained more than 3 or even 1 year. To bring this back to Unix somewhat... When I started there, everything was a Solaris based private cloud (SmartOS by Joyent) running Java apps. In the 5 years I was there, the move was from Java to Go, due to the licensing changes that Oracle made to Java and then a move to containers. SmartOS has a container technology that is sort of like Docker, but since the majority of the containers in the world that people know about are fully Docker in some form with Linux it wasn't as compatible as required so SmartOS was dumped and everything was redone in Azure public cloud with Linux and as much of the native Azure stuff as they could stand to use. Make everything "green field" all of the time, or something.... I didn't really agree with much of this, but I became pretty mercenary as I got old and the place paid well. -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From imp at bsdimp.com Mon Feb 7 02:31:43 2022 From: imp at bsdimp.com (Warner Losh) Date: Sun, 6 Feb 2022 09:31:43 -0700 Subject: [TUHS] more about Brian... In-Reply-To: <20220206141558.GO3045@mcvoy.com> References: <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> <20220206141558.GO3045@mcvoy.com> Message-ID: On Sun, Feb 6, 2022 at 7:17 AM Larry McVoy wrote: > While I _can_ do all the malloc/free stuff myself (and have decades of > working code to prove it), it's become harder and harder to find other > people who can. > While it's not too bad to do malloc/free in userspace in single threaded programs, it gets harder for multi-threaded where you have multiple objects holding references to an object you might want to free. And to get things to run fast, you have to use increasingly sophisticated "locking" primitives to get performance: RCU, lifetime flexibility, etc. Those methods are hard to get right, which is why most of them include extensive run-time proofing / asserts to try to catch leaks and other problems. For kernel work, that adds a whole other level of complexity as well. I'd love to have all this stuff automatically optimized and correct. However, the state of the art for alternatives to C aren't there today for the kernel context. While rust in Linux is a thing, it's not in the fast path yet. Time will tell if it can grow up to do that or not, and I'll stop there since it's a rapidly developing area and I'm sure anything I say about the state of the art when I last looked will be wrong in some way. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Mon Feb 7 04:36:55 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 06 Feb 2022 10:36:55 -0800 Subject: [TUHS] more about Brian... [ really GC vs malloc/free languages ] In-Reply-To: <20220206141558.GO3045@mcvoy.com> References: <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> <20220206141558.GO3045@mcvoy.com> Message-ID: <202202061836.216IatiC3502688@darkstar.fourwinds.com> Larry McVoy writes: > Let's keep it civil and non-personal, I don't think Rob was pointing > at anyone, I think he was pointing at some not so forward thinking. > > I have to side with Rob on this one, even though I'm squarely in the > I like C best camp. > > While I _can_ do all the malloc/free stuff myself (and have decades of > working code to prove it), it's become harder and harder to find other > people who can. Younger programmers just sort of stare at you with a > "I have to do what?" look. They think you are a dinosaur for working > like that when other reasonable languages do that work for you. > > When I did little-lang.org, granted, not widely used but we used it a > lot, it did all the memory management behind the scenes, used reference > counting so you never had the big GC sweep that some languages used, > worked great. And super pleasant to not have to do all that memory > management. > > Having the languages do more for you, and put up guard rails so people > can't make stupid mistakes, seems to be the way of the future. It's > not my future, I love C, it does what I want and I can live with what > it needs me to do to have working code. But I'm a dinosaur and I > know it. I'm not trying to push C where people don't want it. I look at this from a different perspective. The world needs a lot of programmers these days. It takes a lot of work to have internet-connected refrigerators push advertising, to make washers and dryers sing about their work, to have Bixby piss off Samsung phone users, to ensure that IoT devices are insecure, and of course to leak personally identifying information on government web sites. This is critical work and there just aren't enough "good" programmers to go around. I view people that programming for Android, making web pages unusable, and so on, as if they're using domain-specific languages. The difference is that while many of us grew up loving domain-specific "little languages" these languages are huge. While I'm not an expert here, I'm sure that being an expert in the Android, IOS, Java, or WWW ecosystems involves more "learning" than many of us had to do when we learned our craft. A big problem with our profession is that we have no agreed on terminology to distinguish among practitioners. A story told to me by a co-worker in the '80s illustrates this well. Ken had gone home for Christmas with his family. One of his uncles took him aside and asked something like "Hey, you're a computer guy. Can you help me with this .COM and .BAT stuff?" Ken replied "Don't have a clue what you're talking about." When Ken related this story to me, he said "The funny thing about it was that we both walked away thinking that the other person didn't know anything about computers." I think some of what we're debating here is whether or not "programmers" need to understand fundamentals. Many of us think that they do, but we're not the ones working on a subscription model for starting your car. I replaced my deck last summer. Had to do a lot of contractor interviewing. I didn't choose one who said "I can do it" and showed me photos of work he had done. I chose one who said "I can do it" and looked around and said "You know, won't be able to tell until I get the old one removed but I think that there some things that need fixing underneath." Another example, because I'm also a hardware engineer. Many digital circuit designers think that digital is an isolated domain. There was a time a few decades ago when an analog engineer couldn't get a job. But then there was an awakening when folks realized that everything was analog at its core and all of a sudden "full stack hardware engineers" were writing their own tickets. Sure, many digital designers said "Why do I need to know this stuff? Nobody uses Rubylith anymore and the DRC (design rule checker) software takes care of stuff for me. Analog designers bail those people out when things don't work. To me, a big problem with what I'll call domain-specific programmers is that they get involved in standards and specifications and aren't trained in how to abstract. So standards are produced that result in enlarged, more complex domains. One of the best examples is CSS, a standard that is too complex to be documented. I have no clue as to how many CSS properties exist anymore. It's not cleanly designed, and of course with the addition of each new property the interaction matrix grows exponentially. And the increasing number of mode-switching properties is growing the number of interaction matrices. There are literally thousands of things a CSS "programmer" needs to know, yet people still ask question like "How do I vertically center something" because it's still hard to do. Even the worst programming language is orders of magnitude simpler than CSS. But hey, CSS isn't "programming" so of course it's better. Bottom line to me is that people with serious expertise are always going to be needed. Someone has to design the hardware, someone has to make the tools used to design the hardware, someone has to implement programming languages and operating systems and all that. But that's a different domain than what the majority of the world wants today. Jon From steffen at sdaoden.eu Mon Feb 7 05:08:22 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sun, 06 Feb 2022 20:08:22 +0100 Subject: [TUHS] more about Brian... In-Reply-To: <10B8CDC8-12FF-4B93-AD34-3393BA5C13D5@iitbombay.org> References: <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> <10B8CDC8-12FF-4B93-AD34-3393BA5C13D5@iitbombay.org> Message-ID: <20220206190822.WUfVe%steffen@sdaoden.eu> Bakul Shah wrote in <10B8CDC8-12FF-4B93-AD34-3393BA5C13D5 at iitbombay.org>: |Just ignore the swagger. | |I would go further than Rob in that even for sequential |programs there is no virtue in sticking to malloc/free if you |don't have to. The whole point of automation (for me) is to Well maybe. When i do perl or awk i do not even think about that memory as such exists, mostly. In so far. |delegate all the boring and repetitive work to computers so |that I can focus on more interesting things! And solving |malloc/free related bugs is boring and repetitive. For But, you know, this is a philosophy i do not like. Just like i never understood why Stroustrup gave C++ exceptions the full power of flexibility instead of allowing only a single base class but giving the entire C++ environment a toggle to produce __FILE__/__LINE__ diagnosis out of the box. Or instead of even introducing symbols which go the non-preprocessor if(XY) way and allowing access to these from within code if XY is true. So you have to invent preprocessor mess in order to be able to pass debug info down the call chain, or use non-portable ELF or so related info (which i never did). But if you do have the information at hand, your program could say #?1|kent:steffen$ s-nail -Rf /dev/empty s-nail: /dev/empty: No such entry, file or directory ... #?0!0/NONE#ERROR|:? quit ... s-nail[info]: Count cur/peek/all: 4/ 1658/ 12524 ... s-nail[info]: 0x55ef9a581b50 (72 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1064 There are messages in the error ring, manageable via `errors' command??? s-nail[info]: 0x55ef9a581ae0 (40 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1035 ????????????????E???????P?X??U??E??????? s-nail[info]: 0x55ef9a581420 (48 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1064 /dev/empty: No such entry, file or directory???? s-nail[info]: 0x55ef9a5813b0 (40 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1035 ??X??U??????????,??????? ?X??U??,???^??? even upon receive of a signal. And this is just a silly wrapper, not even a complete thing. It is just like always, "there is no wrong weather, just the wrong clothes". |embedded code in limited space you want to use memory |carefully but for most of userland code we don't have to |worry about saving every byte. Most userland code is not real |time code (and doesn't run on realtime OSes). That doesn't |mean using memory like water -- there is a middle ground. |Don't blame the GC for incompetently programmed websites or |for layers of code using third party libraries using other |third party libraries. All the new languages [offer] [myriads] of [symbol] [annotations] in order to improve things, which also aids in giving more info to the tools. And, what is maybe more important, all programs written in these languages are written from scratch. And even if people tend to produce bugs here and there, and tend to forget the background of a problem now and then, or did not know about it when they wrote the code, ... the experience with programming has improved a lot compared to times that members of these list went through! That is of course only my personal opinion. I like C a lot (like C++ without everything but classes). --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 jon at fourwinds.com Mon Feb 7 05:27:10 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 06 Feb 2022 11:27:10 -0800 Subject: [TUHS] more about Brian... [ really GC vs malloc/free languages ] In-Reply-To: <20220206141558.GO3045@mcvoy.com> References: <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> <20220206141558.GO3045@mcvoy.com> Message-ID: <202202061927.216JRAk43504029@darkstar.fourwinds.com> Oh, one more thing. It was kind of implied in my earlier post, but a big concern is when domain-specific programmers cross over into a different domain but think that the rules from the domain with which they're familiar apply. For example, I wouldn't want someone from a GC domain messing with an OS kernel without learning about memory and memory management. Stuff has to interoperate in a way that an insecure talking toaster doesn't. I probably have the quote completely wrong, but Dan Healy, sound man for The Grateful Dead an inventor of much of modern concert hall sound technology said something like "Bozos are fine people and fun to be around but that doesn't mean that I would let one near my soundboard with a pair of diagonal pliers." Jon From imp at bsdimp.com Mon Feb 7 05:33:17 2022 From: imp at bsdimp.com (Warner Losh) Date: Sun, 6 Feb 2022 12:33:17 -0700 Subject: [TUHS] more about Brian... [ really GC vs malloc/free languages ] In-Reply-To: <202202061927.216JRAk43504029@darkstar.fourwinds.com> References: <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> <20220206141558.GO3045@mcvoy.com> <202202061927.216JRAk43504029@darkstar.fourwinds.com> Message-ID: On Sun, Feb 6, 2022 at 12:27 PM Jon Steinhart wrote: > I probably have the quote completely wrong, > but Dan Healy, sound man for The Grateful Dead an inventor of much of > modern concert hall sound technology said something like "Bozos are > fine people and fun to be around but that doesn't mean that I would > let one near my soundboard with a pair of diagonal pliers." > I personally like having the choices. I don't want to be bothered with malloc/free when I'm hacking together an awk or python script. On the other hand, when it has to run fast or do lots of TPS inside a kernel, I really don't want somebody else deciding when a good time to take a 'hiccup' in performance is... It all depends on what I'm doing since using techniques from the latter to optimize the former is a waste of time. The whole reason I do a GC'd language is to write what I'm writing faster with less hassle... Some days I'm Dan Healy, some days I'm waving diagonal pliers around... :) Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Mon Feb 7 05:37:27 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 06 Feb 2022 11:37:27 -0800 Subject: [TUHS] more about Brian... [ really GC vs malloc/free languages ] In-Reply-To: References: <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> <20220206141558.GO3045@mcvoy.com> <202202061927.216JRAk43504029@darkstar.fourwinds.com> Message-ID: <202202061937.216JbRPT3504444@darkstar.fourwinds.com> Warner Losh writes: > I personally like having the choices. I don't want to be bothered with > malloc/free when I'm hacking together an awk or python script. On > the other hand, when it has to run fast or do lots of TPS inside a kernel, > I really don't want somebody else deciding when a good time to take > a 'hiccup' in performance is... It all depends on what I'm doing since > using techniques from the latter to optimize the former is a waste of > time. The whole reason I do a GC'd language is to write what I'm writing > faster with less hassle... > > Some days I'm Dan Healy, some days I'm waving diagonal pliers around... :) Completely agree with you. I do the same. But I actually know how to use those diagonal pliers; I don't want someone who doesn't know what they're doing to start snipping things. Jon From ralph at inputplus.co.uk Mon Feb 7 06:21:17 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sun, 06 Feb 2022 20:21:17 +0000 Subject: [TUHS] COFF is over there. In-Reply-To: <202202061937.216JbRPT3504444@darkstar.fourwinds.com> References: <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> <20220206141558.GO3045@mcvoy.com> <202202061927.216JRAk43504029@darkstar.fourwinds.com> <202202061937.216JbRPT3504444@darkstar.fourwinds.com> Message-ID: <20220206202117.5DD2B20152@orac.inputplus.co.uk> Hi Jon, You've brought up an interesting point to start this subthread, but it still isn't TUHS-worthy IME. COFF would welcome it. :-) -- Cheers, Ralph. From gingell at computer.org Mon Feb 7 13:04:01 2022 From: gingell at computer.org (Rob Gingell) Date: Sun, 6 Feb 2022 19:04:01 -0800 Subject: [TUHS] Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> Message-ID: On 1/29/2022 11:59 AM, Clem Cole wrote: > Sun later brought the UCB PI and PC to the SunOS, but pls Rob G/Larry > correct me here - I think they later did their own compiler when they > did their new C and Fortran. Sun never replaced the UCB Pascal front-end, just moved it across back-ends as it evolved them. The development of SPARC required Sun to develop back-end expertise. Although the investments focused on SPARC, there was also work on the back-ends for the Motorola- and Intel-based products. Sun's front-end investments began with the SVR4 project as an ANSI C compiler was needed. (A priority for SVR4 was conformance with then-current external standards such as POSIX and ANSI. Over the course of SVR4's development strict ANSI conformance came to be seen as problematic: most SV licensees didn't just use the release as delivered and instead merged portions into their extant, and not ANSI, product source code bases. This led to some late-in-the-project de-ANSIfying of the source in the interest of making SVR4 more digestible by the licensees.) That C compiler was the basis for the unbundled C compiler product that came out at the time of SunOS 4.1. Sun's larger investments in front-end development were motivated by the later transition from F77 to F9X. Which is another data point in support of Clem's frequent observation that FORTRAN is a big deal in parts of the real world. At that point Sun tended to its own front ends for C, C++, and FORTRAN but Pascal was always the UCB front end. From erc at pobox.com Tue Feb 8 15:22:44 2022 From: erc at pobox.com (Ed Carp) Date: Mon, 7 Feb 2022 22:22:44 -0700 Subject: [TUHS] more about Brian... In-Reply-To: References: <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> Message-ID: And that reminds me of the old "Three Envelopes" joke: A new CEO takes his seat at the helm of a large corporation He finds three envelopes on his desk, numbered 1 to 3, and a note. "Dear successor, On this desk you find 3 envelopes that will help you in times of a crisis. Open them only in the order they are numbered, and only when you face a crisis that you cannot manage. Best of luck". He stores them in his safe and goes to work. But the economy isn't picking up, the corporation isn't doing too well and the board wants an explanation. He decides it's time for the first envelope. He rips it open and reads: "Blame your predecessor". And he does. He steps up at the press conference and blames everything on the shortcomings and nearsightedness of his predecessor and how he just needs a bit more time to turn things around. Everyone is pleased and he remains CEO. But after a while, the displeasure isn't waning and the corporation isn't doing any better. Another press conference is held and he rips open the next envelope: "Call for reorganizations". And he does. He presents a great reorganization project with no stone remaining unturned, this will surely improve productivity and move the corporation into the future. Everyone's so busy reorganizing that nobody can even notice how the corporation is running worse and worse, until there's really no way to cover it up anymore. He reaches for the third and last envelope, hoping for the great reveal that will save him once and for all. He rips it open and reads: "Prepare 3 envelopes and a note". On 2/6/22, Brad Spencer wrote: > Will Senn writes: > > [snip] > >>> I've done this and I've employed people who have done this. We're >>> a dieing breed, the focus seems to be on programming languages and >>> tools for idiots. People don't want to learn the discipline it takes >>> to work with malloc()/free(). It's sad. >> >> I completely agree. This is ridiculous. Do modern programmer's seriously >> think that the old code wasn't complex or robust? Sheesh, there's code >> out there that has run through more millions of transactions an hour for >> more years than most of these folks have been alive. There's also code >> that's been running without any updates, for decades. Most code written >> by the newbreed won't run for a month without surfacing dozens of bugs. >> Margaret Hamilton would prolly have some choice words for these folks. > > This would appear to be a Not Unix conversation... but... > > So... the idea that code would run that long was not at all valued at > my last job. The management found it simpler and better (for some > definition of better) to just reinvent everything every 3 to 6 years. > In the mean time, the languages used would change. The idea that one > would "have to waste time" figuring out how to use malloc() and free() > properly was not looked upon well when the development time would be > better spend solving the needed higher level problems. In other words > there literally was no interest in creating code that was going to be > maintained for more than about 6 years and in a lot of cases would not > be maintained more than 3 or even 1 year. > > To bring this back to Unix somewhat... When I started there, everything > was a Solaris based private cloud (SmartOS by Joyent) running Java apps. > In the 5 years I was there, the move was from Java to Go, due to the > licensing changes that Oracle made to Java and then a move to > containers. SmartOS has a container technology that is sort of like > Docker, but since the majority of the containers in the world that > people know about are fully Docker in some form with Linux it wasn't as > compatible as required so SmartOS was dumped and everything was redone > in Azure public cloud with Linux and as much of the native Azure stuff > as they could stand to use. Make everything "green field" all of the > time, or something.... > > I didn't really agree with much of this, but I became pretty mercenary > as I got old and the place paid well. > > > > > > > > -- > Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org > From ralph at inputplus.co.uk Fri Feb 11 01:18:49 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Thu, 10 Feb 2022 15:18:49 +0000 Subject: [TUHS] ratfor vibe In-Reply-To: <202202020747.2127lTTh005669@freefriends.org> References: <202202011537.211FbYSe017204@freefriends.org> <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> Message-ID: <20220210151849.2693E21563@orac.inputplus.co.uk> Hi Arnold, > > I agree the original Software Tools is a must read, but having done > > so, why would I suffer working through the hurdles put in place by > > Pascal compared to Ratfor? I never bothered so your recommendation > > makes me wonder what I missed. I did read Kernighan's ‘not my > > favourite’ and took from that I wouldn't enjoy the Pascal book given > > I'd read the original. > > As others mentioned, recursion and real data structures make code > easier to read. They also refined the text some. > > But in general, I think the principle of "ANYTHING written by Brian > Kernighan is worth reading, at least once" applies, even in this case. Well, that's true. I've read every other technical book of his apart from the ‘AMPL: A Modeling Language for Mathematical Programming’. https://amzn.to/3BdQ0dV It was the quality of his writing which meant I could learn C and Unix at home well enough to get a C programming job on Sun OS on leaving school, which is sixteen over here. Within a year or so, work sent me to Sydney as part of shipping the flight simulator to Qantas. Good books have immeasurable worth across all their readers. Thanks, it's ordered, arriving Valentine's Day, which will impress SWMBO. :-) -- Cheers, Ralph. From will.senn at gmail.com Tue Feb 15 07:00:57 2022 From: will.senn at gmail.com (Will Senn) Date: Mon, 14 Feb 2022 15:00:57 -0600 Subject: [TUHS] unexported software for local use for v7 Message-ID: <9f9a8834-ac2a-ba8c-25b8-163c2b2fb398@gmail.com> A week or so after spending an entire day meticulously mapping manpages from version 0 to version 7, I came across Doug's combined table of contents. I love recreating the wheel <>, only saving grace is that the geniuses who came before, in this case Doug, had the same idea :). In it, he mentions an addendum for v7 that has pages for unexported software for local use: apl, cflow, cpio, cref, and a slew of other usefull commands get mentioned. By unexported, I'm gathering this means not included on the distro tapes -- I certainly don't see them in my installed system. Were they distributed at all, or just used internally at Bell, or what? Are there extant copies around? To be clear, I'm talking about the unexported versions, not later versions that might be fitted onto v7. Oh, and a bonus question, why weren't they exported. Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpl.jpl at gmail.com Wed Feb 16 07:17:04 2022 From: jpl.jpl at gmail.com (John P. Linderman) Date: Tue, 15 Feb 2022 16:17:04 -0500 Subject: [TUHS] Lorinda Cherry Message-ID: I got his from a friend today (15 February): =========== I'm sorry to report that Lorinda passed away a few days ago. I got a call from her sister today. Apparently the dog walker hadn't seen her for a few days and called the police. The police entered the house and found her there. Her sister says they are assuming either a heart attack or a stroke. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Feb 16 07:26:04 2022 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 16 Feb 2022 08:26:04 +1100 (EST) Subject: [TUHS] Lorinda Cherry In-Reply-To: References: Message-ID: Sic transit gloria mundi... This probably ought to go to COFF as well. -- Dave From jefftwopointzero at gmail.com Wed Feb 16 07:33:42 2022 From: jefftwopointzero at gmail.com (Jeffrey Joshua Rollin) Date: Tue, 15 Feb 2022 21:33:42 +0000 Subject: [TUHS] Lorinda Cherry In-Reply-To: References: Message-ID: <4287B8F5-515B-4A50-AA17-68F748BEEEDF@gmail.com> Sad news. Jeff Sent from my iPad > On 15 Feb 2022, at 21:21, John P. Linderman wrote: > >  > I got his from a friend today (15 February): > > =========== > > I'm sorry to report that Lorinda passed away a few days ago. I got a call from her sister today. Apparently the dog walker hadn't seen her for a few days and called the police. The police entered the house and found her there. Her sister says they are assuming either a heart attack or a stroke. -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Wed Feb 16 08:31:03 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 15 Feb 2022 17:31:03 -0500 Subject: [TUHS] Lorinda Cherry Message-ID: Lorinda Cherry, a long-time member of the original Unix Lab died recently. Here is a slightly edited reminiscence that I sent to the president of the National Center for Women and Information Technology in 2018 when they honored her with their Pioneer in Tech award. As Lorinda Cherry's longtime colleague at Bell Labs, I was very pleased to hear she has been chosen for the NCWIT Pioneer Award. At the risk of telling you things you already know, I offer some remarks about her career. I will mainly speak of things I saw at first hand when our offices were two doors apart, from the early '70s through 1994, when Lorinda left Bell Labs in the AT&T/Lucent split. Most of the work I describe broke new ground in computing; "pioneer" is an apt term. Lorinda, like many women (including my own mother and my wife), had to fight the system to be allowed to study math and science in college. She was hired by Visual and Acoustics Research at Bell Labs as a TA--the typical fate of women graduates, while their male counterparts were hired as full members of technical staff. It would take another decade for that unequal treatment to be rectified. Even then, one year she received a statement of benefits that explained what her wife would receive upon her death. When Lorinda called HR to confirm that they meant spouse, they said no, and demanded that the notice be returned. (She declined.) It seemed that husbands would not get equal treatment until AT&T lost a current court case. The loss was a foregone conclusion; still AT&T preferred to pay lawyers rather than widowers, and fought it to the bitter end. Lorinda moved to my department in Computing Science when the Unix operating system was in its infancy. Initially she collaborated with Ken Knowlton on nascent graphics applications: Beflix, a system for producing artistically pixillated films, and an early program for rendering ball-and-stick molecular models. She then joined the (self-organized) Unix team, collaborating on several applications with Bob Morris. First came "dc", an unlimited-precision desk calculator, which is still a Unix staple 45 years on. Building on dc, she would later make "bc", which made unlimited precision available in familiar programming-language notation and became the interface of choice to dc. Then came "form" and "fed", nominally a form-letter generator and editor. In fact they were more of a personal memory bank, a step towards Vannevar Bush's famous Memex concept--an interesting try that didn't pay off at that scale. Memex had to sleep two more decades before mutating into the Worldwide Web. Lorinda had a hand in "typo", too, a Morris invention that found gross spelling mistakes by statistical analysis. Sorting the words of a document by the similarity of their trigrams to those in the rest of the document tended to bring typos to the front of the list. This worked remarkably well and gained popularity as a spell-checker until a much less interesting program backed by a big dictionary took over. Taken together, these initial forays foretold a productive computer science career centered around graphics, little languages, and text processing. By connecting a phototypesetter as an output device for Unix, Joe Ossanna initiated a revolution in document preparation. The new resource prompted a flurry of disparate looking documents until Mike Lesk brought order to the chaos by creating a macro package to produce a useful standard paper format. Taking over from Lesk, Lorinda observed the difficulty of typesetting the mathematics (which the printing industry counted as "penalty copy") that occurred in many research papers, and set out to simplify the task of rendering mathematical formulas, Brian Kernighan soon joined her effort. The result was "eqn", which built on the way people read formulas aloud to make a quite intuitive language for describing display formulas. Having pioneered a pattern that has been adopted throughout the industry, eqn is still in use forty years later. Lorinda also wrote an interpreter to render phototypesetter copy on a cathode-ray terminal. This allowed one to see typeset documents without the hassle of exposing and developing film. Though everyone has similar technology at their fingertips today, this was genuinely pioneering work at the time. You are certainly aware of Writers Workbench, which gained national publicity, including Lorinda's appearance on the Today Show. It all began as a one-woman skunk-works project. Noticing the very slow progress in natuaral-language processing, she identified a useful subtask that could be carved out of the larger problem: identifying parts of speech. Using a vocabulary of function words (articles, pronouns, prepositions and conjunctions) and rules of inflection, she was able to classify parts of speech in running text with impressive accuracy. When Rutgers professor William Vesterman proposed a style-assessing program, with measures such as the frequencies of adjectives, subordinate clauses, or compound sentences, Lorinda was able to harness her "parts" program to implement the idea in a couple of weeks. Subsequently Nina MacDonald, with Lorinda's support, incorporated it into a larger suite that checked and made suggestions about other stylistic issues such as cliches, malapropisms, and redundancy. Another aspect of text processing that Lorinda addressed was topic identification. Terms (often word pairs) that occur with abnormal frequency are likely to describe the topic at hand. She used this idea to construct first drafts of indexes. One in-house application was to the Unix manual, which up until that time had only a table of contents, but no index. This was a huge boon for a document so packed with detail. In her final years at Bell Labs, Lorinda teamed up with AT&T trouble-call centers to analyze the call transcripts that attendants recorded on the fly--very sketchy prose, replete with ad-hoc contractions and misspellings. The purpose was to identify systemic problems that would not be obvious from transcripts considered individually. When an unusual topic appeared at the same time in multiple transcripts, those transcripts were singled out for further study. The scheme worked and led to early detection of system anomalies. In one case, it led AT&T to suspend publication of a house organ that rubbed customers the wrong way. Lorinda was not cut from the same mold as most of her colleagues. First she was a woman, which meant she faced special obstacles. Then, while there were several pilots among us, there was only one shower of dogs and only one car racer--moreover one who became a regional exec of the Sports Car Club of America. For years she organized and officiated at races as well as participating. Lorinda was always determined, but never pushy. The determination shows in her success in text analysis, which involves much sheer grit--there are no theoretical shortcuts in this subject. She published little, but did a lot. I am glad to see her honored. Doug McIlroy From usotsuki at buric.co Wed Feb 16 09:32:56 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Tue, 15 Feb 2022 18:32:56 -0500 (EST) Subject: [TUHS] Lorinda Cherry In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022, Douglas McIlroy wrote: > First came "dc", an unlimited-precision desk calculator, > which is still a Unix staple 45 years on. Building on dc, > she would later make "bc", which made unlimited precision > available in familiar programming-language notation and became > the interface of choice to dc. In the form of GNU/NetBSD bc, I use bc(1) to this day as my tool of choice for quick calculations. -uso. From jcapp at anteil.com Wed Feb 16 09:43:27 2022 From: jcapp at anteil.com (Jim Capp) Date: Tue, 15 Feb 2022 18:43:27 -0500 Subject: [TUHS] Lorinda Cherry In-Reply-To: References: Message-ID: Ditto on bc, in Linux. > On Feb 15, 2022, at 6:36 PM, Steve Nickolas wrote: > > On Tue, 15 Feb 2022, Douglas McIlroy wrote: > >> First came "dc", an unlimited-precision desk calculator, >> which is still a Unix staple 45 years on. Building on dc, >> she would later make "bc", which made unlimited precision >> available in familiar programming-language notation and became >> the interface of choice to dc. > > In the form of GNU/NetBSD bc, I use bc(1) to this day as my tool of choice for quick calculations. > > -uso. From lm at mcvoy.com Wed Feb 16 09:51:27 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 15 Feb 2022 15:51:27 -0800 Subject: [TUHS] Lorinda Cherry In-Reply-To: References: Message-ID: <20220215235127.GK3040@mcvoy.com> I do a ton of stuff in bc, it works well because when I get an answer I didn't expect, I can scroll backward and see where I screwed up. Nice writeup, Doug, I wish I had met her, she sounds like a super substantial person. On Tue, Feb 15, 2022 at 06:43:27PM -0500, Jim Capp wrote: > Ditto on bc, in Linux. > > > On Feb 15, 2022, at 6:36 PM, Steve Nickolas wrote: > > > > ???On Tue, 15 Feb 2022, Douglas McIlroy wrote: > > > >> First came "dc", an unlimited-precision desk calculator, > >> which is still a Unix staple 45 years on. Building on dc, > >> she would later make "bc", which made unlimited precision > >> available in familiar programming-language notation and became > >> the interface of choice to dc. > > > > In the form of GNU/NetBSD bc, I use bc(1) to this day as my tool of choice for quick calculations. > > > > -uso. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From ggm at algebras.org Wed Feb 16 10:09:12 2022 From: ggm at algebras.org (George Michaelson) Date: Wed, 16 Feb 2022 10:09:12 +1000 Subject: [TUHS] Lorinda Cherry In-Reply-To: References: Message-ID: I wrote a major part of the UQ phone directory in EQN, to post process T/Roff output so the existing bromide-mechanical printing braces for grouping common phoneline holders could be done in the new phototypesetter. Eqn was the tool which got me out of a self-dug hole over-promising delivery of "print-equivalent" outcome here. I use BC as a daily driver like most people. I never quite got DC, and wondered at the duality of them. Very interesting to have the background explained. The trigraph spelling checker sounds wonderful. Thanks for posting this. _G On Wed, Feb 16, 2022 at 8:35 AM Douglas McIlroy wrote: > > Lorinda Cherry, a long-time member of the original Unix Lab > died recently. Here is a slightly edited reminiscence that > I sent to the president of the National Center for Women and > Information Technology in 2018 when they honored her with > their Pioneer in Tech award. > > As Lorinda Cherry's longtime colleague at Bell Labs, I was > very pleased to hear she has been chosen for the NCWIT Pioneer > Award. At the risk of telling you things you already know, > I offer some remarks about her career. I will mainly speak of > things I saw at first hand when our offices were two doors > apart, from the early '70s through 1994, when Lorinda left > Bell Labs in the AT&T/Lucent split. Most of the work I describe > broke new ground in computing; "pioneer" is an apt term. > > Lorinda, like many women (including my own mother and my wife), > had to fight the system to be allowed to study math and science > in college. She was hired by Visual and Acoustics Research > at Bell Labs as a TA--the typical fate of women graduates, > while their male counterparts were hired as full members of > technical staff. It would take another decade for that unequal > treatment to be rectified. Even then, one year she received > a statement of benefits that explained what her wife would > receive upon her death. When Lorinda called HR to confirm that > they meant spouse, they said no, and demanded that the notice > be returned. (She declined.) It seemed that husbands would not > get equal treatment until AT&T lost a current court case. The > loss was a foregone conclusion; still AT&T preferred to pay > lawyers rather than widowers, and fought it to the bitter end. > > Lorinda moved to my department in Computing Science when > the Unix operating system was in its infancy. Initially she > collaborated with Ken Knowlton on nascent graphics applications: > Beflix, a system for producing artistically pixillated films, > and an early program for rendering ball-and-stick molecular > models. > > She then joined the (self-organized) Unix team, collaborating > on several applications with Bob Morris. > > First came "dc", an unlimited-precision desk calculator, > which is still a Unix staple 45 years on. Building on dc, > she would later make "bc", which made unlimited precision > available in familiar programming-language notation and became > the interface of choice to dc. > > Then came "form" and "fed", nominally a form-letter generator > and editor. In fact they were more of a personal memory > bank, a step towards Vannevar Bush's famous Memex concept--an > interesting try that didn't pay off at that scale. Memex had to > sleep two more decades before mutating into the Worldwide Web. > > Lorinda had a hand in "typo", too, a Morris invention that > found gross spelling mistakes by statistical analysis. Sorting > the words of a document by the similarity of their trigrams > to those in the rest of the document tended to bring typos to > the front of the list. This worked remarkably well and gained > popularity as a spell-checker until a much less interesting > program backed by a big dictionary took over. > > Taken together, these initial forays foretold a productive > computer science career centered around graphics, little > languages, and text processing. > > By connecting a phototypesetter as an output device for Unix, > Joe Ossanna initiated a revolution in document preparation. The > new resource prompted a flurry of disparate looking documents > until Mike Lesk brought order to the chaos by creating a macro > package to produce a useful standard paper format. > > Taking over from Lesk, Lorinda observed the difficulty of > typesetting the mathematics (which the printing industry counted > as "penalty copy") that occurred in many research papers, > and set out to simplify the task of rendering mathematical > formulas, Brian Kernighan soon joined her effort. The result > was "eqn", which built on the way people read formulas aloud > to make a quite intuitive language for describing display > formulas. Having pioneered a pattern that has been adopted > throughout the industry, eqn is still in use forty years later. > > Lorinda also wrote an interpreter to render phototypesetter > copy on a cathode-ray terminal. This allowed one to see > typeset documents without the hassle of exposing and developing > film. Though everyone has similar technology at their fingertips > today, this was genuinely pioneering work at the time. > > You are certainly aware of Writers Workbench, which gained > national publicity, including Lorinda's appearance on the Today > Show. It all began as a one-woman skunk-works project. Noticing > the very slow progress in natuaral-language processing, she > identified a useful subtask that could be carved out of the > larger problem: identifying parts of speech. Using a vocabulary > of function words (articles, pronouns, prepositions and > conjunctions) and rules of inflection, she was able to classify > parts of speech in running text with impressive accuracy. > > When Rutgers professor William Vesterman proposed a > style-assessing program, with measures such as the frequencies > of adjectives, subordinate clauses, or compound sentences, > Lorinda was able to harness her "parts" program to implement > the idea in a couple of weeks. Subsequently Nina MacDonald, > with Lorinda's support, incorporated it into a larger suite > that checked and made suggestions about other stylistic issues > such as cliches, malapropisms, and redundancy. > > Another aspect of text processing that Lorinda addressed was > topic identification. Terms (often word pairs) that occur with > abnormal frequency are likely to describe the topic at hand. She > used this idea to construct first drafts of indexes. One > in-house application was to the Unix manual, which up until > that time had only a table of contents, but no index. This > was a huge boon for a document so packed with detail. > > In her final years at Bell Labs, Lorinda teamed up with AT&T > trouble-call centers to analyze the call transcripts that > attendants recorded on the fly--very sketchy prose, replete > with ad-hoc contractions and misspellings. The purpose was > to identify systemic problems that would not be obvious from > transcripts considered individually. When an unusual topic > appeared at the same time in multiple transcripts, those > transcripts were singled out for further study. The scheme > worked and led to early detection of system anomalies. In one > case, it led AT&T to suspend publication of a house organ that > rubbed customers the wrong way. > > Lorinda was not cut from the same mold as most of her > colleagues. First she was a woman, which meant she faced > special obstacles. Then, while there were several pilots > among us, there was only one shower of dogs and only one car > racer--moreover one who became a regional exec of the Sports > Car Club of America. For years she organized and officiated > at races as well as participating. > > Lorinda was always determined, but never pushy. The > determination shows in her success in text analysis, which > involves much sheer grit--there are no theoretical shortcuts > in this subject. She published little, but did a lot. I am > glad to see her honored. > > Doug McIlroy From dave at horsfall.org Wed Feb 16 10:24:59 2022 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 16 Feb 2022 11:24:59 +1100 (EST) Subject: [TUHS] Lorinda Cherry In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022, George Michaelson wrote: > I use BC as a daily driver like most people. I never quite got DC, and > wondered at the duality of them. Very interesting to have the background > explained. You know you're a greybeard if you can remember why the DC sequence "99k2vp8opq" was so popular... -- Dave From will.senn at gmail.com Wed Feb 16 10:54:11 2022 From: will.senn at gmail.com (Will Senn) Date: Tue, 15 Feb 2022 18:54:11 -0600 Subject: [TUHS] Lorinda Cherry In-Reply-To: <20220215235127.GK3040@mcvoy.com> References: <20220215235127.GK3040@mcvoy.com> Message-ID: <710a98f1-eb31-8c6f-28ab-37159cb6c262@gmail.com> bc is my all time favorite calculator. I feel incomplete whenever I sit down at a Windows machine and have to pull up the so-called calculator there. And nothing beats it for simple base conversion, either. As a front-end for dc it's fun to have students wonder about the dual processes, then show them how they work together. Really good example of the unix way of doing things. Too bad they went and combined them in recent days. On 2/15/22 5:51 PM, Larry McVoy wrote: > I do a ton of stuff in bc, it works well because when I get an answer > I didn't expect, I can scroll backward and see where I screwed up. > > Nice writeup, Doug, I wish I had met her, she sounds like a super > substantial person. > > On Tue, Feb 15, 2022 at 06:43:27PM -0500, Jim Capp wrote: >> Ditto on bc, in Linux. >> >>> On Feb 15, 2022, at 6:36 PM, Steve Nickolas wrote: >>> >>> ???On Tue, 15 Feb 2022, Douglas McIlroy wrote: >>> >>>> First came "dc", an unlimited-precision desk calculator, >>>> which is still a Unix staple 45 years on. Building on dc, >>>> she would later make "bc", which made unlimited precision >>>> available in familiar programming-language notation and became >>>> the interface of choice to dc. >>> In the form of GNU/NetBSD bc, I use bc(1) to this day as my tool of choice for quick calculations. >>> >>> -uso. From andrew at humeweb.com Wed Feb 16 10:35:09 2022 From: andrew at humeweb.com (Andrew Hume) Date: Tue, 15 Feb 2022 16:35:09 -0800 Subject: [TUHS] Lorinda Cherry In-Reply-To: References: Message-ID: <8249A4E0-92D7-4B87-83F2-45724F10F7A5@humeweb.com> for many years, my office was diagonally opposite lorinda’s. we worked together most closely on the Unix manuals (ninth and tenth editions); lorinda spent considerable work on the permuted indices and the papers on Volume 2. she also shared in my my own weird story of synchronicity. i had been doing some work on polyhedra composed of regular polyhedra. to prove to myself that i had gotten things correct, i constructed a folding program to form the polyhedra by folding a flat network of faces. i did this in bc and verified that the vertices were sufficiently close together. and indeed, as i increased the precision, the points coincided. except one didn’t. for one polyhedra, one vertex stubbornly never got closer than about 1e-6 from its (supposedly) coincident alter points. it took about 3-4 days before i found the problem; in some exceptionally rare cases, division in bc yielded the wrong answer. i race around to lorinda to show her the problem (it was in the underlying dc code). to my astonishment, lorinda listened and said “you know, not 30 minutes ago, Vic Vyssotsky (our executive director) came in with exactly the same problem.” he had discovered it by using an extremely long-winded cyclical calculation used to detect errors in arithmetic units. she then discovered the bug occurred when she converted the original assembler code into C. the weird part was that this bug had been latent for some years, and two different people reported it to her with 30 minutes. From usotsuki at buric.co Wed Feb 16 12:58:22 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Tue, 15 Feb 2022 21:58:22 -0500 (EST) Subject: [TUHS] Lorinda Cherry In-Reply-To: <710a98f1-eb31-8c6f-28ab-37159cb6c262@gmail.com> References: <20220215235127.GK3040@mcvoy.com> <710a98f1-eb31-8c6f-28ab-37159cb6c262@gmail.com> Message-ID: On Tue, 15 Feb 2022, Will Senn wrote: > bc is my all time favorite calculator. I feel incomplete whenever I sit down > at a Windows machine and have to pull up the so-called calculator there. And > nothing beats it for simple base conversion, either. As a front-end for dc > it's fun to have students wonder about the dual processes, then show them how > they work together. Really good example of the unix way of doing things. Too > bad they went and combined them in recent days. You can use GNU's bc on Windows - that's what I do ;) -uso. From arnold at skeeve.com Wed Feb 16 17:54:37 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 16 Feb 2022 00:54:37 -0700 Subject: [TUHS] Lorinda Cherry In-Reply-To: References: Message-ID: <202202160754.21G7sbUa011318@freefriends.org> Dave Horsfall wrote: > On Wed, 16 Feb 2022, George Michaelson wrote: > > > I use BC as a daily driver like most people. I never quite got DC, and > > wondered at the duality of them. Very interesting to have the background > > explained. > > You know you're a greybeard if you can remember why the DC sequence > "99k2vp8opq" was so popular... > > -- Dave I guess I'm not enough of a greybeard: $ dc 99k2vp8opq 1.4142135623730950488016887242096980785696718753769480731766797379907\ 32478462107038850387534327641572 1.3240474631771674622042627661154672512575174353366027242235650231664\ 2753102603147144252257620301035270505416503 I recognize the first value as the square root of two. What is the second value? Thanks, Arnold From thomas.paulsen at firemail.de Wed Feb 16 18:02:41 2022 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Wed, 16 Feb 2022 09:02:41 +0100 Subject: [TUHS] Lorinda Cherry In-Reply-To: References: Message-ID: I didn't know that. R.I.P great programmer! --- Ursprüngliche Nachricht --- Von: Douglas McIlroy Datum: 15.02.2022 23:31:03 An: TUHS main list Betreff: [TUHS] Lorinda Cherry Lorinda Cherry, a long-time member of the original Unix Lab died recently. Here is a slightly edited reminiscence that I sent to the president of the National Center for Women and Information Technology in 2018 when they honored her with their Pioneer in Tech award. As Lorinda Cherry's longtime colleague at Bell Labs, I was very pleased to hear she has been chosen for the NCWIT Pioneer Award. At the risk of telling you things you already know, I offer some remarks about her career. I will mainly speak of things I saw at first hand when our offices were two doors apart, from the early '70s through 1994, when Lorinda left Bell Labs in the AT&T/Lucent split. Most of the work I describe broke new ground in computing; "pioneer" is an apt term. Lorinda, like many women (including my own mother and my wife), had to fight the system to be allowed to study math and science in college. She was hired by Visual and Acoustics Research at Bell Labs as a TA--the typical fate of women graduates, while their male counterparts were hired as full members of technical staff. It would take another decade for that unequal treatment to be rectified. Even then, one year she received a statement of benefits that explained what her wife would receive upon her death. When Lorinda called HR to confirm that they meant spouse, they said no, and demanded that the notice be returned. (She declined.) It seemed that husbands would not get equal treatment until AT&T lost a current court case. The loss was a foregone conclusion; still AT&T preferred to pay lawyers rather than widowers, and fought it to the bitter end. Lorinda moved to my department in Computing Science when the Unix operating system was in its infancy. Initially she collaborated with Ken Knowlton on nascent graphics applications: Beflix, a system for producing artistically pixillated films, and an early program for rendering ball-and-stick molecular models. She then joined the (self-organized) Unix team, collaborating on several applications with Bob Morris. First came "dc", an unlimited-precision desk calculator, which is still a Unix staple 45 years on. Building on dc, she would later make "bc", which made unlimited precision available in familiar programming-language notation and became the interface of choice to dc. Then came "form" and "fed", nominally a form-letter generator and editor. In fact they were more of a personal memory bank, a step towards Vannevar Bush's famous Memex concept--an interesting try that didn't pay off at that scale. Memex had to sleep two more decades before mutating into the Worldwide Web. Lorinda had a hand in "typo", too, a Morris invention that found gross spelling mistakes by statistical analysis. Sorting the words of a document by the similarity of their trigrams to those in the rest of the document tended to bring typos to the front of the list. This worked remarkably well and gained popularity as a spell-checker until a much less interesting program backed by a big dictionary took over. Taken together, these initial forays foretold a productive computer science career centered around graphics, little languages, and text processing. By connecting a phototypesetter as an output device for Unix, Joe Ossanna initiated a revolution in document preparation. The new resource prompted a flurry of disparate looking documents until Mike Lesk brought order to the chaos by creating a macro package to produce a useful standard paper format. Taking over from Lesk, Lorinda observed the difficulty of typesetting the mathematics (which the printing industry counted as "penalty copy") that occurred in many research papers, and set out to simplify the task of rendering mathematical formulas, Brian Kernighan soon joined her effort. The result was "eqn", which built on the way people read formulas aloud to make a quite intuitive language for describing display formulas. Having pioneered a pattern that has been adopted throughout the industry, eqn is still in use forty years later. Lorinda also wrote an interpreter to render phototypesetter copy on a cathode-ray terminal. This allowed one to see typeset documents without the hassle of exposing and developing film. Though everyone has similar technology at their fingertips today, this was genuinely pioneering work at the time. You are certainly aware of Writers Workbench, which gained national publicity, including Lorinda's appearance on the Today Show. It all began as a one-woman skunk-works project. Noticing the very slow progress in natuaral-language processing, she identified a useful subtask that could be carved out of the larger problem: identifying parts of speech. Using a vocabulary of function words (articles, pronouns, prepositions and conjunctions) and rules of inflection, she was able to classify parts of speech in running text with impressive accuracy. When Rutgers professor William Vesterman proposed a style-assessing program, with measures such as the frequencies of adjectives, subordinate clauses, or compound sentences, Lorinda was able to harness her "parts" program to implement the idea in a couple of weeks. Subsequently Nina MacDonald, with Lorinda's support, incorporated it into a larger suite that checked and made suggestions about other stylistic issues such as cliches, malapropisms, and redundancy. Another aspect of text processing that Lorinda addressed was topic identification. Terms (often word pairs) that occur with abnormal frequency are likely to describe the topic at hand. She used this idea to construct first drafts of indexes. One in-house application was to the Unix manual, which up until that time had only a table of contents, but no index. This was a huge boon for a document so packed with detail. In her final years at Bell Labs, Lorinda teamed up with AT&T trouble-call centers to analyze the call transcripts that attendants recorded on the fly--very sketchy prose, replete with ad-hoc contractions and misspellings. The purpose was to identify systemic problems that would not be obvious from transcripts considered individually. When an unusual topic appeared at the same time in multiple transcripts, those transcripts were singled out for further study. The scheme worked and led to early detection of system anomalies. In one case, it led AT&T to suspend publication of a house organ that rubbed customers the wrong way. Lorinda was not cut from the same mold as most of her colleagues. First she was a woman, which meant she faced special obstacles. Then, while there were several pilots among us, there was only one shower of dogs and only one car racer--moreover one who became a regional exec of the Sports Car Club of America. For years she organized and officiated at races as well as participating. Lorinda was always determined, but never pushy. The determination shows in her success in text analysis, which involves much sheer grit--there are no theoretical shortcuts in this subject. She published little, but did a lot. I am glad to see her honored. Doug McIlroy From meillo at marmaro.de Wed Feb 16 18:13:33 2022 From: meillo at marmaro.de (markus schnalke) Date: Wed, 16 Feb 2022 09:13:33 +0100 Subject: [TUHS] Lorinda Cherry In-Reply-To: <202202160754.21G7sbUa011318@freefriends.org> References: <202202160754.21G7sbUa011318@freefriends.org> Message-ID: <1nKFRN-4IZ-00@marmaro.de> Hoi. [2022-02-16 00:54] arnold at skeeve.com > Dave Horsfall wrote: > > On Wed, 16 Feb 2022, George Michaelson wrote: > > > > > I use BC as a daily driver like most people. I never quite got DC, and > > > wondered at the duality of them. Very interesting to have the background > > > explained. > > > > You know you're a greybeard if you can remember why the DC sequence > > "99k2vp8opq" was so popular... > > > > -- Dave > > I guess I'm not enough of a greybeard: > > $ dc > 99k2vp8opq > 1.4142135623730950488016887242096980785696718753769480731766797379907\ > 32478462107038850387534327641572 > 1.3240474631771674622042627661154672512575174353366027242235650231664\ > 2753102603147144252257620301035270505416503 > > I recognize the first value as the square root of two. What is > the second value? Decoding the program with the manpage: 99k set scaling factor to 99 (i.e. 99 digits on output) 2v square root of 2 p print it (but leave it on the stack) 8o switch to octal output p print the same value (now in octal) q quit More interesting is the question why you need sqrt(2) in octal? meillo From ralph at inputplus.co.uk Thu Feb 17 00:05:19 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Wed, 16 Feb 2022 14:05:19 +0000 Subject: [TUHS] Shower of Dogs. In-Reply-To: References: Message-ID: <20220216140519.BB6182111F@orac.inputplus.co.uk> Hi, Doug wrote: > Then, while there were several pilots among us, > there was only one shower of dogs What's a shower of dogs refer to in this context? I've been mulling it over for a while. I checked Wiktionary for shower and dogs and nothing obvious pops out as to what the phrase may mean in American to this English speaker. -- Cheers, Ralph. From chet.ramey at case.edu Thu Feb 17 00:09:41 2022 From: chet.ramey at case.edu (Chet Ramey) Date: Wed, 16 Feb 2022 09:09:41 -0500 Subject: [TUHS] Shower of Dogs. In-Reply-To: <20220216140519.BB6182111F@orac.inputplus.co.uk> References: <20220216140519.BB6182111F@orac.inputplus.co.uk> Message-ID: <453f7966-5b1a-e45b-443f-0ee616f108b7@case.edu> On 2/16/22 9:05 AM, Ralph Corderoy wrote: > Hi, > > Doug wrote: >> Then, while there were several pilots among us, >> there was only one shower of dogs > > What's a shower of dogs refer to in this context? Someone who trains dogs and competes with them at dog shows. -- ``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 ralph at inputplus.co.uk Thu Feb 17 00:34:45 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Wed, 16 Feb 2022 14:34:45 +0000 Subject: [TUHS] dc after bc. In-Reply-To: References: Message-ID: <20220216143445.7C4EE2111F@orac.inputplus.co.uk> Hi, Dave Horsfall wrote: > > I never quite got DC, and wondered at the duality of them. > > You know you're a greybeard if you can remember why the DC sequence > "99k2vp8opq" was so popular... I used to use bc, and still do when ‘a(1)*4’ would be useful, but moved to dc because I didn't know it well and wanted to improve. Plus reverse Polish tends to better match what I want to enter. But I think I'm missing the idiomatic way to use it; I'm puzzled there's no command to print and pop the top of stack followed by a linefeed. - ‘p’ prints the top of stack without popping it, and then linefeed. - ‘n’ pops and prints the top of stack but without a linefeed. - ‘f’ prints the stack, one number per line. - ‘c’ clears the stack. This means my multiple unrelated calculations tend to end with ‘pc’ as otherwise the stack builds up and I might accidentally use old stuff on the stack if the operators for this next sum don't push enough operands of their own. If I use n then the stack is popped, which I want, but the cursor remains after the number. I could see that's useful if the number was still the top of stack because I could continue typing on the same line to make use of it. So I'm left with ‘pc’ or ‘fc’, or ‘n10P’. Popping without printing is ‘ss’ or similar to store it in register s. So ‘pss’ prints ToS and pops just it, simpler than ‘n10P’. How did dc's users balance printing the results with not building stack detritus? -- Cheers, Ralph. From ralph at inputplus.co.uk Thu Feb 17 00:41:32 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Wed, 16 Feb 2022 14:41:32 +0000 Subject: [TUHS] Shower of Dogs. In-Reply-To: <453f7966-5b1a-e45b-443f-0ee616f108b7@case.edu> References: <20220216140519.BB6182111F@orac.inputplus.co.uk> <453f7966-5b1a-e45b-443f-0ee616f108b7@case.edu> Message-ID: <20220216144132.8AE752111F@orac.inputplus.co.uk> Chet wrote: > Someone who trains dogs and competes with them at dog shows. Ah, got it, thanks Chet, and the rest who responded on and off list. We have dog shows, but I think they tend to have exhibitors parading their charges; I didn't read it as shower as in show. :-) -- Cheers, Ralph. From ron at ronnatalie.com Thu Feb 17 00:35:58 2022 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 16 Feb 2022 14:35:58 +0000 Subject: [TUHS] Shower of Dogs. In-Reply-To: <453f7966-5b1a-e45b-443f-0ee616f108b7@case.edu> References: <20220216140519.BB6182111F@orac.inputplus.co.uk> <453f7966-5b1a-e45b-443f-0ee616f108b7@case.edu> Message-ID: It helps to pronounce it with a long O. As a SHOW - er of dogs, rather than shower like rain coming down. ------ Original Message ------ From: "Chet Ramey" To: "Ralph Corderoy" ; "TUHS" Cc: "Douglas McIlroy" Sent: 2/16/2022 9:09:41 AM Subject: Re: [TUHS] Shower of Dogs. >On 2/16/22 9:05 AM, Ralph Corderoy wrote: >> Hi, >> >> Doug wrote: >>> Then, while there were several pilots among us, >>> there was only one shower of dogs >> >> What's a shower of dogs refer to in this context? > >Someone who trains dogs and competes with them at dog shows. > >-- >``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates >Chet Ramey, UTech, CWRU chet at case.eduhttp://tiswww.cwru.edu/~chet/ From leah at vuxu.org Thu Feb 17 00:54:16 2022 From: leah at vuxu.org (Leah Neukirchen) Date: Wed, 16 Feb 2022 15:54:16 +0100 Subject: [TUHS] Lorinda Cherry In-Reply-To: <1nKFRN-4IZ-00@marmaro.de> (markus schnalke's message of "Wed, 16 Feb 2022 09:13:33 +0100") References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> Message-ID: <8735kig8vb.fsf@vuxu.org> markus schnalke writes: > Hoi. > > [2022-02-16 00:54] arnold at skeeve.com >> Dave Horsfall wrote: >> > >> > You know you're a greybeard if you can remember why the DC sequence >> > "99k2vp8opq" was so popular... >> > >> > -- Dave >> >> I guess I'm not enough of a greybeard: >> >> $ dc >> 99k2vp8opq >> 1.4142135623730950488016887242096980785696718753769480731766797379907\ >> 32478462107038850387534327641572 >> 1.3240474631771674622042627661154672512575174353366027242235650231664\ >> 2753102603147144252257620301035270505416503 >> >> I recognize the first value as the square root of two. What is >> the second value? > > Decoding the program with the manpage: > > 99k set scaling factor to 99 (i.e. 99 digits on output) > 2v square root of 2 > p print it (but leave it on the stack) > 8o switch to octal output > p print the same value (now in octal) > q quit > > More interesting is the question why you need sqrt(2) in octal? Apparently it was a popular benchmark back in the day: https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf > Tim Long: Quick Benchmarks of the Machines on Display > A simple cpu-bound benchmark was run on each of the machines on display. > The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It uses dc > (the desk calculator) to calculate the square root of 2 to 99 decimal places, > and to "print" the result in decimal and then in octal. The results are in > fact never printed, being piped to /dev/null. The user time is all that is > compared. > This benchmark has been applied to a large number of machines° It has > (up until now) been useful because most manufacturers have not optimised dc, > so the results are not likely to have been distorted by attempts to optimise > for benchmarks. > The results were: > DoEo UNITY (DE-68K) 11.3 sec > Plexus P/25 14.1 sec > NCR Tower 21.3 sec > Wicat 150WS 27.3 sec > Unison 32.6 sec > By comparison, a VAX 11/780 clocks about 5 to 6 secs, VAX750 9 sec, PDPIIs > range from 27 secs (11/23) to 6 secs (11/70), PDP ii/34s range from 12 to 19 > secs depending upon the presence of a cache. Perkin-Elmer range from 12o5 > secs (32/10) to 7°9 secs (32/40)o I looks like V7 dc used 100-limbs internally, so printing in decimal was fast, but printing in octal required conversion. -- Leah Neukirchen https://leahneukirchen.org/ From andrew at humeweb.com Thu Feb 17 00:09:31 2022 From: andrew at humeweb.com (Andrew Hume) Date: Wed, 16 Feb 2022 06:09:31 -0800 Subject: [TUHS] Shower of Dogs. In-Reply-To: <20220216140519.BB6182111F@orac.inputplus.co.uk> References: <20220216140519.BB6182111F@orac.inputplus.co.uk> Message-ID: lorinda was an avid dog owner. she spent a long time recycling racing greyhounds. she would own a few of these at any one time > On Feb 16, 2022, at 6:05 AM, Ralph Corderoy wrote: > > Hi, > > Doug wrote: >> Then, while there were several pilots among us, >> there was only one shower of dogs > > What's a shower of dogs refer to in this context? > > I've been mulling it over for a while. I checked Wiktionary for shower > and dogs and nothing obvious pops out as to what the phrase may mean in > American to this English speaker. > > -- > Cheers, Ralph. From lm at mcvoy.com Thu Feb 17 01:01:28 2022 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 16 Feb 2022 07:01:28 -0800 Subject: [TUHS] Shower of Dogs. In-Reply-To: References: <20220216140519.BB6182111F@orac.inputplus.co.uk> Message-ID: <20220216150128.GN3040@mcvoy.com> On Wed, Feb 16, 2022 at 06:09:31AM -0800, Andrew Hume wrote: > lorinda was an avid dog owner. > she spent a long time recycling racing greyhounds. > she would own a few of these at any one time Good on her, I have a friend who does this. Sweet dogs that deserve a retirement. From rdm at cfcl.com Thu Feb 17 01:08:05 2022 From: rdm at cfcl.com (Rich Morin) Date: Wed, 16 Feb 2022 07:08:05 -0800 Subject: [TUHS] Shower of Dogs. In-Reply-To: <20220216140519.BB6182111F@orac.inputplus.co.uk> References: <20220216140519.BB6182111F@orac.inputplus.co.uk> Message-ID: <0A48E54B-368D-44F2-853B-1106AA28032C@cfcl.com> > On Feb 16, 2022, at 06:05, Ralph Corderoy wrote: > > Doug wrote: >> while there were several pilots among us, there was only one shower of dogs. > > What's a shower of dogs refer to in this context? To understand this, you have to know the American idiom "raining cats and dogs". A "shower of dogs" is thus a heavy burst of large drops, which would of course be of concern to a pilot (:-). -r From douglas.mcilroy at dartmouth.edu Thu Feb 17 02:57:28 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 16 Feb 2022 11:57:28 -0500 Subject: [TUHS] Shower of Dogs. In-Reply-To: References: <20220216140519.BB6182111F@orac.inputplus.co.uk> Message-ID: Lorinda kept dobermans as household pets and show dogs. She even had an RV for taking them to exhibit in distant shows. She eventually switched to rescuing retired racing greyhounds and sold the RV. Doug On Wed, Feb 16, 2022 at 9:09 AM Andrew Hume wrote: > > lorinda was an avid dog owner. > she spent a long time recycling racing greyhounds. > she would own a few of these at any one time > > > On Feb 16, 2022, at 6:05 AM, Ralph Corderoy wrote: > > > > Hi, > > > > Doug wrote: > >> Then, while there were several pilots among us, > >> there was only one shower of dogs > > > > What's a shower of dogs refer to in this context? > > > > I've been mulling it over for a while. I checked Wiktionary for shower > > and dogs and nothing obvious pops out as to what the phrase may mean in > > American to this English speaker. > > > > -- > > Cheers, Ralph. > From drb at msu.edu Thu Feb 17 03:03:03 2022 From: drb at msu.edu (Dennis Boone) Date: Wed, 16 Feb 2022 12:03:03 -0500 Subject: [TUHS] Shower of Dogs. In-Reply-To: (Your message of Wed, 16 Feb 2022 11:57:28 -0500.) References: <20220216140519.BB6182111F@orac.inputplus.co.uk> Message-ID: <20220216170303.71B3717302@yagi.h-net.msu.edu> Between envisioning the rain of canines and the recycled greyhounds, this thread has provided me with several pre-caffeinated smiles so far. Thanks all! From imp at bsdimp.com Thu Feb 17 03:18:04 2022 From: imp at bsdimp.com (Warner Losh) Date: Wed, 16 Feb 2022 10:18:04 -0700 Subject: [TUHS] Shower of Dogs. In-Reply-To: <20220216170303.71B3717302@yagi.h-net.msu.edu> References: <20220216140519.BB6182111F@orac.inputplus.co.uk> <20220216170303.71B3717302@yagi.h-net.msu.edu> Message-ID: On Wed, Feb 16, 2022 at 10:15 AM Dennis Boone wrote: > Between envisioning the rain of canines and the recycled greyhounds, > this thread has provided me with several pre-caffeinated smiles so far. > Indeed. Reading it as a description of weather at first left me baffled. But knowing it is more of a title makes it make more sense. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From dds at aueb.gr Thu Feb 17 05:08:09 2022 From: dds at aueb.gr (Diomidis Spinellis) Date: Wed, 16 Feb 2022 21:08:09 +0200 Subject: [TUHS] Lorinda Cherry In-Reply-To: References: Message-ID: <904976bf-1673-3888-504c-4eec5468648d@aueb.gr> A description of text processing work at Bell Labs, including the use of trigrams for spell checking, readability analysis, and word class assignment was published in the BSTJ. L. E. McMahon; L. L. Cherry; R. Morris. Statistical text processing. The Bell System Technical Journal, 57(6):2137-2154, July-Aug. 1978. DOI: 10.1002/j.1538-7305.1978.tb02146.x You can find it openly available online at: https://archive.org/details/bstj57-6-2137/mode/2up The article was part of an amazing special issue of BSTJ devoted to Unix. A second such issue, 63(8) was published on October 1984. In the late 1980s both issues were also sold as books by Prentice Hall under the title "UNIX System Readings and Applications". I broke the bank buying them as a student, but didn't regret it. Diomidis - https://www.spinellis.gr On 16-Feb-22 2:09, George Michaelson wrote: > The trigraph spelling checker sounds wonderful. From jpl.jpl at gmail.com Thu Feb 17 06:55:43 2022 From: jpl.jpl at gmail.com (John P. Linderman) Date: Wed, 16 Feb 2022 15:55:43 -0500 Subject: [TUHS] Lorinda Cherry In-Reply-To: <904976bf-1673-3888-504c-4eec5468648d@aueb.gr> References: <904976bf-1673-3888-504c-4eec5468648d@aueb.gr> Message-ID: Someone unearthed a 1982 video in which Lorinda explains some of her work. https://www.youtube.com/watch?v=XvDZLjaCJuw&t=828s You can watch the whole thing by just lopping off the '&t=828s' at the end. On Wed, Feb 16, 2022 at 2:18 PM Diomidis Spinellis wrote: > A description of text processing work at Bell Labs, including the use of > trigrams for spell checking, readability analysis, and word class > assignment was published in the BSTJ. > > L. E. McMahon; L. L. Cherry; R. Morris. Statistical text processing. The > Bell System Technical Journal, 57(6):2137-2154, July-Aug. 1978. > DOI: 10.1002/j.1538-7305.1978.tb02146.x > > You can find it openly available online at: > https://archive.org/details/bstj57-6-2137/mode/2up > > The article was part of an amazing special issue of BSTJ devoted to > Unix. A second such issue, 63(8) was published on October 1984. In the > late 1980s both issues were also sold as books by Prentice Hall under > the title "UNIX System Readings and Applications". I broke the bank > buying them as a student, but didn't regret it. > > Diomidis - https://www.spinellis.gr > > On 16-Feb-22 2:09, George Michaelson wrote: > > The trigraph spelling checker sounds wonderful. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Feb 17 07:21:48 2022 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 17 Feb 2022 08:21:48 +1100 (EST) Subject: [TUHS] Shower of Dogs. In-Reply-To: <0A48E54B-368D-44F2-853B-1106AA28032C@cfcl.com> References: <20220216140519.BB6182111F@orac.inputplus.co.uk> <0A48E54B-368D-44F2-853B-1106AA28032C@cfcl.com> Message-ID: On Wed, 16 Feb 2022, Rich Morin wrote: > To understand this, you have to know the American idiom "raining cats > and dogs". A "shower of dogs" is thus a heavy burst of large drops, > which would of course be of concern to a pilot (:-). Also used in British/Australian English; the Americans probably picked it up from the British. -- Dave, who is British/Australian From cowan at ccil.org Thu Feb 17 07:25:13 2022 From: cowan at ccil.org (John Cowan) Date: Wed, 16 Feb 2022 16:25:13 -0500 Subject: [TUHS] Shower of Dogs. In-Reply-To: References: <20220216140519.BB6182111F@orac.inputplus.co.uk> <0A48E54B-368D-44F2-853B-1106AA28032C@cfcl.com> Message-ID: On Wed, Feb 16, 2022 at 4:23 PM Dave Horsfall wrote: > On Wed, 16 Feb 2022, Rich Morin wrote: > > > To understand this, you have to know the American idiom "raining cats > > and dogs". A "shower of dogs" is thus a heavy burst of large drops, > > which would of course be of concern to a pilot (:-). > > Also used in British/Australian English; the Americans probably picked it > up from the British. What is worse than raining cats and dogs? Hailing taxis; > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at humeweb.com Thu Feb 17 07:17:56 2022 From: andrew at humeweb.com (Andrew Hume) Date: Wed, 16 Feb 2022 13:17:56 -0800 Subject: [TUHS] Lorinda Cherry In-Reply-To: References: <904976bf-1673-3888-504c-4eec5468648d@aueb.gr> Message-ID: what a hoot of a program!! so many folks: john mashey, vi vyssocki[sic], denis, thommo, lorinda, cathi brooks (my second supervisor at the labs, system 3 days), kernighan, al aho. > On Feb 16, 2022, at 12:55 PM, John P. Linderman wrote: > > Someone unearthed a 1982 video in which Lorinda explains some of her work. > > https://www.youtube.com/watch?v=XvDZLjaCJuw&t=828s > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marzhall.o at gmail.com Thu Feb 17 07:59:44 2022 From: marzhall.o at gmail.com (Marshall Conover) Date: Wed, 16 Feb 2022 16:59:44 -0500 Subject: [TUHS] Lorinda Cherry In-Reply-To: References: <904976bf-1673-3888-504c-4eec5468648d@aueb.gr> Message-ID: Oh wow - a week or two ago I linked this video to a coworker who asked me how to "get into" nix systems when he saw me chaining a few commands together with pipes. Lorinda's section was one of the ones I pointed to as 'definitely pay hard attention to this bit' - well, maybe up until the coffee sipping with the numbers being read out. (Of course, that's not to say the rest of the video isn't important!) Thanks all for sharing your memories. Cheers, Marshall On Wed, Feb 16, 2022 at 4:02 PM John P. Linderman wrote: > > Someone unearthed a 1982 video in which Lorinda explains some of her work. > > https://www.youtube.com/watch?v=XvDZLjaCJuw&t=828s > > You can watch the whole thing by just lopping off the '&t=828s' at the end. > > On Wed, Feb 16, 2022 at 2:18 PM Diomidis Spinellis wrote: >> >> A description of text processing work at Bell Labs, including the use of >> trigrams for spell checking, readability analysis, and word class >> assignment was published in the BSTJ. >> >> L. E. McMahon; L. L. Cherry; R. Morris. Statistical text processing. The >> Bell System Technical Journal, 57(6):2137-2154, July-Aug. 1978. >> DOI: 10.1002/j.1538-7305.1978.tb02146.x >> >> You can find it openly available online at: >> https://archive.org/details/bstj57-6-2137/mode/2up >> >> The article was part of an amazing special issue of BSTJ devoted to >> Unix. A second such issue, 63(8) was published on October 1984. In the >> late 1980s both issues were also sold as books by Prentice Hall under >> the title "UNIX System Readings and Applications". I broke the bank >> buying them as a student, but didn't regret it. >> >> Diomidis - https://www.spinellis.gr >> >> On 16-Feb-22 2:09, George Michaelson wrote: >> > The trigraph spelling checker sounds wonderful. From dave at horsfall.org Thu Feb 17 08:27:39 2022 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 17 Feb 2022 09:27:39 +1100 (EST) Subject: [TUHS] Lorinda Cherry In-Reply-To: <8735kig8vb.fsf@vuxu.org> References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> Message-ID: On Wed, 16 Feb 2022, Leah Neukirchen wrote: > Apparently it was a popular benchmark back in the day: > https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf Yep. > > The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It > > uses dc (the desk calculator) to calculate the square root of 2 to 99 > > decimal places, Ugh; that "I" ought to be "|" (and I can see other typos), so someone really needs to proofread those PDF scans if they're going to be regarded as authoritative. Yes, I can help... > > This benchmark has been applied to a large number of machines° It has > > (up until now) been useful because most manufacturers have not > > optimised dc, so the results are not likely to have been distorted by > > attempts to optimise for benchmarks. Indeed, when a lot of compilers recognised the Sieve of Eratosthenes being used and optimised for it... Wasn't all that long ago that vehicle manufacturers also started doing the same thing :-) > > Wicat 150WS 27.3 sec > > Unison 32.6 sec The WICAT 150 was just a terminal with several serial ports, and was p*ss-awful (I worked for Lionel Singer, and had to support the poxy thing); I'm surprised that it beat another box, though... > I looks like V7 dc used 100-limbs internally, so printing in decimal was > fast, but printing in octal required conversion. Yep; extra work for the CPU. Not much of a benchmark these days, as CPUs are really fast; when I was supporting Unify I used to use its automatic tutorial as a benchmark, and I used to joke that I needed a calendar on some boxes... Trivia: Lionel Singer also sold the then-new Sun-3, and we had one set up at an AUUG conference, giggling whenever someone tried that benchmark; what they didn't know was that the prominent window was actually an "rlogin" to the Gould that we also sold... The looks on their faces were priceless :-) -- Dave From dillera at gmail.com Thu Feb 17 08:40:18 2022 From: dillera at gmail.com (Andrew Diller) Date: Wed, 16 Feb 2022 17:40:18 -0500 Subject: [TUHS] Lorinda Cherry In-Reply-To: References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> Message-ID: <429E30EC-E156-4F8E-B6C1-0B5400A48B49@gmail.com> > On Feb 16, 2022, at 5:27 PM, Dave Horsfall wrote: > > On Wed, 16 Feb 2022, Leah Neukirchen wrote: > >> Apparently it was a popular benchmark back in the day: >> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf > > Yep. > >>> The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It >>> uses dc (the desk calculator) to calculate the square root of 2 to 99 >>> decimal places, > I tried that on some of the systems I have at hand. It didn't even register on my Mac.... ------------------------------------------------- 33 MHZ MIPS R3010 # echo 99k2vp8opq | /bin/time dc > /dev/null real 0.4 user 0.3 sys 0.0 # uname -a power power 3.3.2 12031609 IP7 ------------------------------------------------- 900 MHZ MIPS R160000 $ echo 99k2vp8opq | /bin/time dc > /dev/null real 0.009 user 0.003 sys 0.002 dillera at fuel ~ $ uname -a IRIX64 fuel 6.5 07202013 IP35 mips IP35 Irix ------------------------------------------------- 3.5GHZ Xeon E5 $ echo 99k2vp8opq | time dc > /dev/null 0.00 real 0.00 user 0.00 sys dillera at trashcan ~ $ uname -a Darwin trashcan 20.6.0 Darwin Kernel Version 20.6.0: root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64 ------------------------------------------------- -andy From lm at mcvoy.com Thu Feb 17 08:42:54 2022 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 16 Feb 2022 14:42:54 -0800 Subject: [TUHS] Lorinda Cherry In-Reply-To: References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> Message-ID: <20220216224254.GA3040@mcvoy.com> On Thu, Feb 17, 2022 at 09:27:39AM +1100, Dave Horsfall wrote: > Indeed, when a lot of compilers recognised the Sieve of Eratosthenes being > used and optimised for it... Wasn't all that long ago that vehicle > manufacturers also started doing the same thing :-) Indeed. I hated when people cheated because benchmarks should teach you the capabilities of the machine being benchmarked. They aren't useful if people cheat. When I did LMbench, the rules were "cc -O2" and you could not link with any benchmarking libraries and you could only report a result if you reported all results. I had a beef with this guy: https://www.cs.jhu.edu/~shap/ because he had some toy OS that didn't have a VM system, didn't have networking, didn't have much of anything, but boy oh boy, did it context switch fast (because there was no context to speak of). He reported those numbers in blatant violation of my rules and I had to escalate to get him to stop. The bummer is he is a smart guy, capable of good work, there is no need to cheat. From clemc at ccc.com Thu Feb 17 08:56:35 2022 From: clemc at ccc.com (Clem Cole) Date: Wed, 16 Feb 2022 17:56:35 -0500 Subject: [TUHS] Lorinda Cherry In-Reply-To: <20220216224254.GA3040@mcvoy.com> References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> <20220216224254.GA3040@mcvoy.com> Message-ID: And before that, Fortran compilers were known to recognize Whetstone. Mashey did his wonder talk called 'Lies, Damn Lies and Benchmarks' in the mid-80s which begat the SPEC suite. Wasn't perfect but it did help. Marketing people in particular like to grab a single number for 'goodness' just to try to show mine is better than yours (my current disgust has been the clock rate of the processors which sadly, my employer was one of the worst in using as a figure of merit). On Wed, Feb 16, 2022 at 5:44 PM Larry McVoy wrote: > On Thu, Feb 17, 2022 at 09:27:39AM +1100, Dave Horsfall wrote: > > Indeed, when a lot of compilers recognised the Sieve of Eratosthenes > being > > used and optimised for it... Wasn't all that long ago that vehicle > > manufacturers also started doing the same thing :-) > > Indeed. I hated when people cheated because benchmarks should teach you > the capabilities of the machine being benchmarked. They aren't useful > if people cheat. > > When I did LMbench, the rules were "cc -O2" and you could not link with > any benchmarking libraries and you could only report a result if you > reported all results. > > I had a beef with this guy: https://www.cs.jhu.edu/~shap/ because he > had some toy OS that didn't have a VM system, didn't have networking, > didn't have much of anything, but boy oh boy, did it context switch > fast (because there was no context to speak of). He reported those > numbers in blatant violation of my rules and I had to escalate to > get him to stop. The bummer is he is a smart guy, capable of good > work, there is no need to cheat. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Thu Feb 17 09:49:01 2022 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 16 Feb 2022 18:49:01 -0500 Subject: [TUHS] Lorinda Cherry In-Reply-To: References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> <20220216224254.GA3040@mcvoy.com> Message-ID: On 2/16/22, Clem Cole wrote: > Marketing people in particular like to grab a single number for 'goodness' > just to try to show mine is better than yours (my current disgust has been > the clock rate of the processors which sadly, my employer was one of the > worst in using as a figure of merit). > That, and instructions/second. The IBM S/370 model 158 was a true 1 MIPS machine. The VAX-11/780 executed about 500 KIPS. But the 11/780 and the model 158 were almost a dead heat when it came to the execution speed of real world applications. Why? Mainly because the VAX architecture was a lot CISC-ier than S/370, which was basically a load/compute/store architecture. The VAX got a lot more done with each individeual instruction than the S/370. -Paul W. From bakul at iitbombay.org Thu Feb 17 09:49:18 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Wed, 16 Feb 2022 15:49:18 -0800 Subject: [TUHS] Benchmarks.... In-Reply-To: <20220216224254.GA3040@mcvoy.com> References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> <20220216224254.GA3040@mcvoy.com> Message-ID: > On Feb 16, 2022, at 2:42 PM, Larry McVoy wrote: > > On Thu, Feb 17, 2022 at 09:27:39AM +1100, Dave Horsfall wrote: >> Indeed, when a lot of compilers recognised the Sieve of Eratosthenes being >> used and optimised for it... Wasn't all that long ago that vehicle >> manufacturers also started doing the same thing :-) > > Indeed. I hated when people cheated because benchmarks should teach you > the capabilities of the machine being benchmarked. They aren't useful > if people cheat. > > When I did LMbench, the rules were "cc -O2" and you could not link with > any benchmarking libraries and you could only report a result if you > reported all results. > > I had a beef with this guy: https://www.cs.jhu.edu/~shap/ because he > had some toy OS that didn't have a VM system, didn't have networking, > didn't have much of anything, but boy oh boy, did it context switch > fast (because there was no context to speak of). He reported those > numbers in blatant violation of my rules and I had to escalate to > get him to stop. The bummer is he is a smart guy, capable of good > work, there is no need to cheat. My guess is, it was EROS, based on KeyKOS (or GNOSIS), a capability OS. It used the VM hardware to enforce capabilities so I imagine it did have a VM system! http://flint.cs.yale.edu/cs428/doc/eros.pdf The paper does say "microbenchmarks ... inspired by those of lmbench". My guess is Jon Shapiro wanted to show off his system's nimbleness. Should not be seen as an apples to apples comparison with commercial Unix systems. [Don't want to reopen a microkernel/capability system discussion here though] From lm at mcvoy.com Thu Feb 17 11:02:46 2022 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 16 Feb 2022 17:02:46 -0800 Subject: [TUHS] Benchmarks.... In-Reply-To: References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> <20220216224254.GA3040@mcvoy.com> Message-ID: <20220217010246.GI3040@mcvoy.com> On Wed, Feb 16, 2022 at 03:49:18PM -0800, Bakul Shah wrote: > My guess is, it was EROS, based on KeyKOS (or GNOSIS), a capability > OS. It used the VM hardware to enforce capabilities so I imagine > it did have a VM system! > > http://flint.cs.yale.edu/cs428/doc/eros.pdf > > The paper does say "microbenchmarks ... inspired by those of > lmbench". My guess is Jon Shapiro wanted to show off his system's > nimbleness. Should not be seen as an apples to apples comparison > with commercial Unix systems. "inspired" == blatent ripoff to get around the reporting rules of LMbench. I had pretty harsh words with Jon, that paper should never have been published, he ripped off the benchmarks and published some of the results without all of them. You'll note that Eros is pretty dead, nothing came of it. It was an academic thing in search of a problem and Jon had to cheat to make it look good. It's not a good look on him, color me very disappointed but it isn't the first time some pointy headed PhD dude claimed a bunch of stuff that wasn't quite true. From chet.ramey at case.edu Thu Feb 17 13:31:54 2022 From: chet.ramey at case.edu (Chet Ramey) Date: Wed, 16 Feb 2022 22:31:54 -0500 Subject: [TUHS] Shower of Dogs. In-Reply-To: References: <20220216140519.BB6182111F@orac.inputplus.co.uk> <0A48E54B-368D-44F2-853B-1106AA28032C@cfcl.com> Message-ID: <0c842374-7aaa-862a-c184-85d856a6c6f6@case.edu> On 2/16/22 4:25 PM, John Cowan wrote: > What is worse than raining cats and dogs? > > Hailing taxis; No one can argue with this. -- ``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 arnold at skeeve.com Thu Feb 17 15:51:26 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 16 Feb 2022 22:51:26 -0700 Subject: [TUHS] Lorinda Cherry In-Reply-To: <904976bf-1673-3888-504c-4eec5468648d@aueb.gr> References: <904976bf-1673-3888-504c-4eec5468648d@aueb.gr> Message-ID: <202202170551.21H5pQqH032317@freefriends.org> Diomidis Spinellis wrote: > The article was part of an amazing special issue of BSTJ devoted to > Unix. A second such issue, 63(8) was published on October 1984. I have original copies of both, bought directly from Bell Labs, back in the day. :-) I should dig them out and go through them again. Arnold From hveit01 at web.de Thu Feb 17 18:51:54 2022 From: hveit01 at web.de (hveit01 at web.de) Date: Thu, 17 Feb 2022 09:51:54 +0100 Subject: [TUHS] Lions' commentary on PCC pass1? Message-ID: An HTML attachment was scrubbed... URL: From akosela at andykosela.com Thu Feb 17 20:24:14 2022 From: akosela at andykosela.com (Andy Kosela) Date: Thu, 17 Feb 2022 11:24:14 +0100 Subject: [TUHS] Lorinda Cherry In-Reply-To: <429E30EC-E156-4F8E-B6C1-0B5400A48B49@gmail.com> References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> <429E30EC-E156-4F8E-B6C1-0B5400A48B49@gmail.com> Message-ID: On Wed, Feb 16, 2022 at 11:42 PM Andrew Diller wrote: > > > > > On Feb 16, 2022, at 5:27 PM, Dave Horsfall wrote: > > > > On Wed, 16 Feb 2022, Leah Neukirchen wrote: > > > >> Apparently it was a popular benchmark back in the day: > >> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf > > > > Yep. > > > >>> The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It > >>> uses dc (the desk calculator) to calculate the square root of 2 to 99 > >>> decimal places, > > > > I tried that on some of the systems I have at hand. It didn't even register on my Mac.... This would be more appropriate on modern machines: moon $ sysctl machdep.cpu.brand_string; echo 9999k2vp8opq | time -p dc > /dev/null machdep.cpu.brand_string: Intel(R) Core(TM) i5-4258U CPU @ 2.40GHz real 1.87 user 1.87 sys 0.00 --Andy From peter at rulingia.com Thu Feb 17 20:14:59 2022 From: peter at rulingia.com (Peter Jeremy) Date: Thu, 17 Feb 2022 21:14:59 +1100 Subject: [TUHS] Lorinda Cherry In-Reply-To: <429E30EC-E156-4F8E-B6C1-0B5400A48B49@gmail.com> References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> <429E30EC-E156-4F8E-B6C1-0B5400A48B49@gmail.com> Message-ID: On 2022-Feb-16 17:40:18 -0500, Andrew Diller wrote: >> On Feb 16, 2022, at 5:27 PM, Dave Horsfall wrote: >> >> On Wed, 16 Feb 2022, Leah Neukirchen wrote: >> >>> Apparently it was a popular benchmark back in the day: >>> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf >> >> Yep. >> >>>> The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It >>>> uses dc (the desk calculator) to calculate the square root of 2 to 99 >>>> decimal places, >> > >I tried that on some of the systems I have at hand. It didn't even register on my Mac.... Not only didn't it register on my Ryzen 3, it didn't even register on 2.11BSD running in simh on that box. I did get a non-zero reading on an original RPi: $ echo 99k2vp8opq | time dc > /dev/null 0.13 real 0.10 user 0.02 sys -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From stu at remphrey.net Thu Feb 17 22:36:15 2022 From: stu at remphrey.net (Stuart Remphrey) Date: Thu, 17 Feb 2022 20:36:15 +0800 Subject: [TUHS] Lorinda Cherry In-Reply-To: References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> Message-ID: Sad news. Had read her papers in BSTJ early in my career. Very interesting to read of her career, and thanks for the links. I'm a daily/weekly "dc" guy (RPN ftw). Never got into bc. Occasionally used eqn et al. ----- > Wicat 150WS 27.3 sec > Unison 32.6 sec Unison must have been real slow! Dave H. -- remember LSC's ads/posters: "WICAT with *new* GLTC Technology" Lionel/someone just made up the term. For a while no-one asked, eventually it was revealed to stand for "Goes Like The Clappers". ("A Wet Week" more like it) Fortunately I supported the Unix stuff from LSC Brisbane/Qld. So in my first UNIX job I got to play with Sun2-Sun4, lots'a Pyramids, one Convex. Don't recall LSC's Gould though; before I joined? When our sales reps sold WICAT (68000 or 68020?) it was mostly running PICK ported by a bloke in our office (another Dave? I recall him destroying a phone in frustration over the UART/terminal driver). Weird O/S: efficient on-disk hashed DB; but very prone to corruption on unclean shutdown. On Thu, 17 Feb 2022, 06:30 Dave Horsfall, wrote: > On Wed, 16 Feb 2022, Leah Neukirchen wrote: > > > Apparently it was a popular benchmark back in the day: > > https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf > > Yep. > > > > The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It > > > uses dc (the desk calculator) to calculate the square root of 2 to 99 > > > decimal places, > > Ugh; that "I" ought to be "|" (and I can see other typos), so someone > really needs to proofread those PDF scans if they're going to be regarded > as authoritative. Yes, I can help... > > > > This benchmark has been applied to a large number of machines° It has > > > (up until now) been useful because most manufacturers have not > > > optimised dc, so the results are not likely to have been distorted by > > > attempts to optimise for benchmarks. > > Indeed, when a lot of compilers recognised the Sieve of Eratosthenes being > used and optimised for it... Wasn't all that long ago that vehicle > manufacturers also started doing the same thing :-) > > > > Wicat 150WS 27.3 sec > > > Unison 32.6 sec > > The WICAT 150 was just a terminal with several serial ports, and was > p*ss-awful (I worked for Lionel Singer, and had to support the poxy > thing); I'm surprised that it beat another box, though... > > > I looks like V7 dc used 100-limbs internally, so printing in decimal was > > fast, but printing in octal required conversion. > > Yep; extra work for the CPU. Not much of a benchmark these days, as CPUs > are really fast; when I was supporting Unify I used to use its automatic > tutorial as a benchmark, and I used to joke that I needed a calendar on > some boxes... > > Trivia: Lionel Singer also sold the then-new Sun-3, and we had one set up > at an AUUG conference, giggling whenever someone tried that benchmark; > what they didn't know was that the prominent window was actually an > "rlogin" to the Gould that we also sold... The looks on their faces were > priceless :-) > > -- Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Fri Feb 18 01:50:50 2022 From: athornton at gmail.com (Adam Thornton) Date: Thu, 17 Feb 2022 08:50:50 -0700 Subject: [TUHS] Lorinda Cherry In-Reply-To: References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> <429E30EC-E156-4F8E-B6C1-0B5400A48B49@gmail.com> Message-ID: Today I learned that "time" is a shell built-in in zsh! adam at m1-wired:~$ echo 99k2vp8opq | time dc > /dev/null dc > /dev/null 0.00s user 0.01s system 69% cpu 0.011 total (M1 MacBook Air, late 2020, MacOS 12.2.1) -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at humeweb.com Fri Feb 18 02:05:09 2022 From: andrew at humeweb.com (Andrew Hume) Date: Thu, 17 Feb 2022 08:05:09 -0800 Subject: [TUHS] Lorinda Cherry In-Reply-To: References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> <429E30EC-E156-4F8E-B6C1-0B5400A48B49@gmail.com> Message-ID: <418893D3-8C29-4AE0-94C5-DC036CF01B52@humeweb.com> altho i date back to those days, i don’t recall using that benchmark. when i’ve needed something bc-ish to take some time, i normally use a bessel function from bc -l > On Feb 17, 2022, at 2:24 AM, Andy Kosela wrote: > > On Wed, Feb 16, 2022 at 11:42 PM Andrew Diller wrote: >> >> >> >>> On Feb 16, 2022, at 5:27 PM, Dave Horsfall wrote: >>> >>> On Wed, 16 Feb 2022, Leah Neukirchen wrote: >>> >>>> Apparently it was a popular benchmark back in the day: >>>> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf >>> >>> Yep. >>> >>>>> The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It >>>>> uses dc (the desk calculator) to calculate the square root of 2 to 99 >>>>> decimal places, >>> >> >> I tried that on some of the systems I have at hand. It didn't even register on my Mac.... > > This would be more appropriate on modern machines: > > moon $ sysctl machdep.cpu.brand_string; echo 9999k2vp8opq | time -p dc >> /dev/null > machdep.cpu.brand_string: Intel(R) Core(TM) i5-4258U CPU @ 2.40GHz > real 1.87 > user 1.87 > sys 0.00 > > --Andy From imp at bsdimp.com Fri Feb 18 02:38:26 2022 From: imp at bsdimp.com (Warner Losh) Date: Thu, 17 Feb 2022 09:38:26 -0700 Subject: [TUHS] Lorinda Cherry In-Reply-To: <418893D3-8C29-4AE0-94C5-DC036CF01B52@humeweb.com> References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> <429E30EC-E156-4F8E-B6C1-0B5400A48B49@gmail.com> <418893D3-8C29-4AE0-94C5-DC036CF01B52@humeweb.com> Message-ID: Damn, you guys found a bug in my venix emulation: % echo 99k2vp8opq | ./git/venix/tools/vm86venix/venix ./git/venix/tools/vm86venix/disbt/usr/bin/dc pid 70803 (venix): sigreturn eflags = 0x0 I'll have to see how hard it is to setup my Rainbow 100B running Venix and if the benchmark works there or not. Or if this is a bug in venix's dc... Warner On Thu, Feb 17, 2022 at 9:33 AM Andrew Hume wrote: > altho i date back to those days, i don’t recall using that benchmark. > when i’ve needed something bc-ish to take some time, i normally > use a bessel function from bc -l > > > On Feb 17, 2022, at 2:24 AM, Andy Kosela wrote: > > > > On Wed, Feb 16, 2022 at 11:42 PM Andrew Diller > wrote: > >> > >> > >> > >>> On Feb 16, 2022, at 5:27 PM, Dave Horsfall wrote: > >>> > >>> On Wed, 16 Feb 2022, Leah Neukirchen wrote: > >>> > >>>> Apparently it was a popular benchmark back in the day: > >>>> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf > >>> > >>> Yep. > >>> > >>>>> The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It > >>>>> uses dc (the desk calculator) to calculate the square root of 2 to 99 > >>>>> decimal places, > >>> > >> > >> I tried that on some of the systems I have at hand. It didn't even > register on my Mac.... > > > > This would be more appropriate on modern machines: > > > > moon $ sysctl machdep.cpu.brand_string; echo 9999k2vp8opq | time -p dc > >> /dev/null > > machdep.cpu.brand_string: Intel(R) Core(TM) i5-4258U CPU @ 2.40GHz > > real 1.87 > > user 1.87 > > sys 0.00 > > > > --Andy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Fri Feb 18 04:13:07 2022 From: will.senn at gmail.com (Will Senn) Date: Thu, 17 Feb 2022 12:13:07 -0600 Subject: [TUHS] 7th Edition C Reference Manual and UNIX Programming - First Edition Message-ID: <79e0e011-3565-e38f-3979-68688b40f496@gmail.com> All, 1. I have a physical copy of the V7 UPM published by Holt, Rinehart and Winston (HRW) from 1983 (2 volume phone book). In it, there is a C Reference Manual (pp. 247-277, reprinted with minor changes from the first C book by K&R and including a Recent Changes to C addendum). I also have a PDF that was supposedly created from sources that has a C Reference Manual in it, but, in /usr/doc/cman, there's an inscription that reads, "Sorry, but for copyright  reasons,  the  source  for  the  C Reference Manual is not distributed." and the one in the pdf appears to be identical to the one in the V6 UPM (which I have a print-on-demand version of). Are the *roff sources (or a clean PDF) available for the reprint? I have located a PDF copy of the HRW edition, but it's got the usual deficiencies of being a scanned copy. 2. In same manual, there is an article entitled, UNIX Programming -- Second Edition by K&R. Where is the first edition located? It isn't in the V6 UPM. Regards, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From tih at hamartun.priv.no Fri Feb 18 05:59:46 2022 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Thu, 17 Feb 2022 20:59:46 +0100 Subject: [TUHS] Lorinda Cherry In-Reply-To: <8735kig8vb.fsf@vuxu.org> (Leah Neukirchen's message of "Wed, 16 Feb 2022 15:54:16 +0100") References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> Message-ID: Leah Neukirchen writes: > Apparently it was a popular benchmark back in the day: > https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf >> [...] >> By comparison, a VAX 11/780 clocks about 5 to 6 secs, VAX750 9 sec, PDPIIs >> range from 27 secs (11/23) to 6 secs (11/70), PDP ii/34s range from 12 to 19 >> secs depending upon the presence of a cache. Perkin-Elmer range from 12o5 >> secs (32/10) to 7°9 secs (32/40)o Well, I just had to run it on some older hardware... 12MHz 80286 running MINIX 1.6.25 and the classic C version of dc: real 4.00 user 3.56 sys 0.25 DEC MicroPDP-11/23 running PWB UNIX 1.0 and the assembly coded dc: real 29.0 user 22.2 sys 0.7 Watching the prime number generator (from the Wikipedia page on dc) running on the 11/23 is much more entertaining than doing it on the modern workstation I'm typing this on: 2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x Incidentally, the Wikipedia page only lists Robert Morris as author of dc. If anyone here is able to edit Wikipedia, now would be a good time to get Lorinda Cherry's name on there, too. -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 dave at horsfall.org Fri Feb 18 06:23:50 2022 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 18 Feb 2022 07:23:50 +1100 (EST) Subject: [TUHS] Lorinda Cherry In-Reply-To: References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> <429E30EC-E156-4F8E-B6C1-0B5400A48B49@gmail.com> Message-ID: On Thu, 17 Feb 2022, Adam Thornton wrote: > Today I learned that "time" is a shell built-in in zsh! It's been a built-in in a lot of shells for ages; there is also [/usr]/bin/time if you want The Real Thing [tm]. -- Dave From dave at horsfall.org Fri Feb 18 07:18:03 2022 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 18 Feb 2022 08:18:03 +1100 (EST) Subject: [TUHS] Lorinda Cherry In-Reply-To: References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> Message-ID: On Thu, 17 Feb 2022, Tom Ivar Helbekkmo via TUHS wrote: > Watching the prime number generator (from the Wikipedia page on dc) > running on the 11/23 is much more entertaining than doing it on the > modern workstation I'm typing this on: > > 2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x Wow... About 10s on my old MacBook Pro, and I gave up on my ancient FreeBSD box. > Incidentally, the Wikipedia page only lists Robert Morris as author of > dc. If anyone here is able to edit Wikipedia, now would be a good time > to get Lorinda Cherry's name on there, too. Anyone can edit Wikipedia; if you're an editor then you have your name shown instead of your IP address (and someone ought to fix that stupid "cat file | cmd" construct as well), but beware of the edit-nazis who seem to think that they "own" something that is factually wrong and keep changing it back to suit their own cultural views e.g. Kokoda Track vs. Trail. -- Dave From bakul at iitbombay.org Fri Feb 18 07:44:07 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 17 Feb 2022 13:44:07 -0800 Subject: [TUHS] Lorinda Cherry In-Reply-To: References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> Message-ID: <4E3028A1-EC08-424A-B814-CC2AEEEAEC7B@iitbombay.org> On Feb 17, 2022, at 1:18 PM, Dave Horsfall wrote: > > On Thu, 17 Feb 2022, Tom Ivar Helbekkmo via TUHS wrote: > >> Watching the prime number generator (from the Wikipedia page on dc) >> running on the 11/23 is much more entertaining than doing it on the >> modern workstation I'm typing this on: >> >> 2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x > > Wow... About 10s on my old MacBook Pro, and I gave up on my ancient > FreeBSD box. That may be because FreeBSD continues computing primes while the MacOS dc gives up after a while! freebsd (ryzen 2700 3.2Ghz): # note: I interrupted dc after a while $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx ^C 11.93 real 11.79 user 0.13 sys $ wc xxx 47161 47161 319109 xxx $ size `which dc` text data bss dec hex filename 238159 2784 11072 252015 0x3d86f /usr/bin/dc MacOS (m1 pro, prob. 2Ghz) $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx time: command terminated abnormally 1.00 real 0.98 user 0.01 sys [2] 37135 segmentation fault command time dc <<< > xxx $ wc xxx 7342 7342 42626 xxx $ size `which dc` __TEXT __DATA __OBJC others dec hex 32768 16384 0 4295016448 4295065600 100018000 From davida at pobox.com Fri Feb 18 08:00:09 2022 From: davida at pobox.com (David Arnold) Date: Fri, 18 Feb 2022 09:00:09 +1100 Subject: [TUHS] Lorinda Cherry In-Reply-To: References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> Message-ID: <449BEB28-6CF3-4319-9B43-45592A757985@pobox.com> > On 18 Feb 2022, at 08:18, Dave Horsfall wrote: <…> >> Incidentally, the Wikipedia page only lists Robert Morris as author of >> dc. If anyone here is able to edit Wikipedia, now would be a good time >> to get Lorinda Cherry's name on there, too. > > Anyone can edit Wikipedia; if you're an editor then you have your name > shown instead of your IP address (and someone ought to fix that stupid > "cat file | cmd" construct as well), but beware of the edit-nazis who seem > to think that they "own" something that is factually wrong and keep > changing it back to suit their own cultural views e.g. Kokoda Track vs. > Trail. The best solution to that is citing an irrefutable source (I mean, at least for non-contested things). I can edit if you can point me at something definitive? d From will.senn at gmail.com Fri Feb 18 08:09:51 2022 From: will.senn at gmail.com (Will Senn) Date: Thu, 17 Feb 2022 16:09:51 -0600 Subject: [TUHS] Lorinda Cherry In-Reply-To: <904976bf-1673-3888-504c-4eec5468648d@aueb.gr> References: <904976bf-1673-3888-504c-4eec5468648d@aueb.gr> Message-ID: <2431414f-03b3-22c4-259e-997b6d6bdcef@gmail.com> Diomidis, Thanks for the reading suggestion. I've done a lot of work with n-grams. Nice to see a pragmatic treatment of the subject. Too bad I didn't read it back in school. BTW, Volume 1 UNIX System Readings and Applications (reprint of 1978 BSTJ 57:6 part 2 - the UNIX issue) is available at: http://www.bitsavers.org/pdf/att/unix/UNIX_System_Readings_and_Applications_Volume_1_1987.pdf And, volume 2 UNIX System Readings and Applications (1984 BSTJ 63:8 - the 2nd UNIX issue) is also available, at: http://www.bitsavers.org/pdf/att/unix/UNIX_System_Readings_and_Applications_Volume_2_1987.pdf Much cleaner than the other copies. Will On 2/16/22 1:08 PM, Diomidis Spinellis wrote: > A description of text processing work at Bell Labs, including the use > of trigrams for spell checking, readability analysis, and word class > assignment was published in the BSTJ. > > L. E. McMahon; L. L. Cherry; R. Morris. Statistical text processing. > The Bell System Technical Journal, 57(6):2137-2154, July-Aug. 1978. > DOI: 10.1002/j.1538-7305.1978.tb02146.x > > You can find it openly available online at: > https://archive.org/details/bstj57-6-2137/mode/2up > > The article was part of an amazing special issue of BSTJ devoted to > Unix.  A second such issue, 63(8) was published on October 1984.  In > the late 1980s both issues were also sold as books by Prentice Hall > under the title "UNIX System Readings and Applications".  I broke the > bank buying them as a student, but didn't regret it. > > Diomidis - https://www.spinellis.gr > > On 16-Feb-22 2:09, George Michaelson wrote: >> The trigraph spelling checker sounds wonderful. From norman at oclsc.org Fri Feb 18 13:18:25 2022 From: norman at oclsc.org (Norman Wilson) Date: Thu, 17 Feb 2022 22:18:25 -0500 (EST) Subject: [TUHS] Lorinda Cherry Message-ID: Perhaps the best irrefutable source for Lorinda's contribution to dc is that cited by https://en.wikipedia.org/wiki/Lorinda_Cherry? It is, by the way, Doug's A Research UNIX Reader. Those who subscribe to this list and haven't read it ought to do so; it's full of tidbits of history. Norman Wilson Toronto ON From otto at drijf.net Fri Feb 18 18:33:49 2022 From: otto at drijf.net (Otto Moerbeek) Date: Fri, 18 Feb 2022 09:33:49 +0100 Subject: [TUHS] Lorinda Cherry In-Reply-To: <4E3028A1-EC08-424A-B814-CC2AEEEAEC7B@iitbombay.org> References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> <4E3028A1-EC08-424A-B814-CC2AEEEAEC7B@iitbombay.org> Message-ID: On Thu, Feb 17, 2022 at 01:44:07PM -0800, Bakul Shah wrote: > On Feb 17, 2022, at 1:18 PM, Dave Horsfall wrote: > > > > On Thu, 17 Feb 2022, Tom Ivar Helbekkmo via TUHS wrote: > > > >> Watching the prime number generator (from the Wikipedia page on dc) > >> running on the 11/23 is much more entertaining than doing it on the > >> modern workstation I'm typing this on: > >> > >> 2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x > > > > Wow... About 10s on my old MacBook Pro, and I gave up on my ancient > > FreeBSD box. > > That may be because FreeBSD continues computing primes while the MacOS > dc gives up after a while! > > freebsd (ryzen 2700 3.2Ghz): # note: I interrupted dc after a while > $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx > ^C 11.93 real 11.79 user 0.13 sys > $ wc xxx > 47161 47161 319109 xxx > $ size `which dc` > text data bss dec hex filename > 238159 2784 11072 252015 0x3d86f /usr/bin/dc > > MacOS (m1 pro, prob. 2Ghz) > $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx > time: command terminated abnormally > 1.00 real 0.98 user 0.01 sys > [2] 37135 segmentation fault command time dc <<< > xxx > $ wc xxx > 7342 7342 42626 xxx > $ size `which dc` > __TEXT __DATA __OBJC others dec hex > 32768 16384 0 4295016448 4295065600 100018000 > MacOS uses the GNU implementation which has a long standing issue with deep recursion. It even cannot handle the tail recursive calls used here and will run out of its stack. -Otto From peter at rulingia.com Fri Feb 18 19:10:26 2022 From: peter at rulingia.com (Peter Jeremy) Date: Fri, 18 Feb 2022 20:10:26 +1100 Subject: [TUHS] Lorinda Cherry In-Reply-To: References: Message-ID: On 2022-Feb-17 22:18:25 -0500, Norman Wilson wrote: >Perhaps the best irrefutable source for Lorinda's contribution >to dc is that cited by https://en.wikipedia.org/wiki/Lorinda_Cherry? > >It is, by the way, Doug's A Research UNIX Reader. Those who >subscribe to this list and haven't read it ought to do so; it's >full of tidbits of history. It was already referenced from the dc entry and I've added Lorinda as a co-author with that as a citation. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From tih at hamartun.priv.no Fri Feb 18 19:58:39 2022 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Fri, 18 Feb 2022 10:58:39 +0100 Subject: [TUHS] Lorinda Cherry In-Reply-To: (Dave Horsfall's message of "Fri, 18 Feb 2022 08:18:03 +1100") References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> Message-ID: Dave Horsfall writes: >> 2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x > > Wow... About 10s on my old MacBook Pro, and I gave up on my ancient > FreeBSD box. That program shouldn't be redirected to /dev/null, but watched. It doesn't terminate; it just keeps printing prime numbers. :) -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 rdm at cfcl.com Sat Feb 19 08:33:26 2022 From: rdm at cfcl.com (Rich Morin) Date: Fri, 18 Feb 2022 14:33:26 -0800 Subject: [TUHS] Ping! I love that duck! Message-ID: <5FD366F7-329F-44AB-9983-8EC40FA45665@cfcl.com> I was just reminded of this and thought others might enjoy reading it... Customer Review https://www.amazon.com/gp/customer-reviews/R2VDKZ4X1F992Q/ > PING! The magic duck! > Using deft allegory, the authors have provided an insightful and intuitive explanation of one of Unix's most venerable networking utilities. Even more stunning is that they were clearly working with a very early beta of the program, as their book first appeared in 1933, years (decades!) before the operating system and network infrastructure were finalized. ... -r From will.senn at gmail.com Sun Feb 20 01:43:05 2022 From: will.senn at gmail.com (Will Senn) Date: Sat, 19 Feb 2022 09:43:05 -0600 Subject: [TUHS] v7 source code for sh Message-ID: <69d88b37-5817-9a0d-4971-3d8641c2d153@gmail.com> I have been poring through the v7 source code lately, and came across an oddity I would like to know more about. Specifically, in sh. The code for sh is c, but it makes *extensive* use of of macros, for example: /usr/src/cmd/sh/word.c ... WHILE (c=nextc(0), space(c)) DONE ... The macros for sh are defined in mac.h: /usr/src/cmd/sh/mac.h ... #define BEGIN   { #define END     } #define SWITCH  switch( #define IN      ){ #define ENDSW   } #define FOR     for( #define WHILE   while( #define DO      ){ #define OD      ;} #define REP     do{ #define PER     }while( #define DONE    ); ... I can read the resultant code through the lens of my experience coding c, but I'm curious why the macros and how this came about? In v6, the sh source is straight up c. Is there a story behind it worth knowing? Thanks, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Sun Feb 20 02:03:05 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Sat, 19 Feb 2022 11:03:05 -0500 (EST) Subject: [TUHS] v7 source code for sh In-Reply-To: <69d88b37-5817-9a0d-4971-3d8641c2d153@gmail.com> References: <69d88b37-5817-9a0d-4971-3d8641c2d153@gmail.com> Message-ID: On Sat, 19 Feb 2022, Will Senn wrote: > I have been poring through the v7 source code lately, and came across an > oddity I would like to know more about. Specifically, in sh. The code for sh > is c, but it makes *extensive* use of of macros, for example: > I can read the resultant code through the lens of my experience coding c, but > I'm curious why the macros and how this came about? In v6, the sh source is > straight up c. Is there a story behind it worth knowing? Apparently Bourne was heavily into ALGOL, and used those macros to make C into something more familiar. At least, that's what I concluded by reading her Wikipedia page as well as the code. -uso. From clemc at ccc.com Sun Feb 20 02:04:28 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 19 Feb 2022 11:04:28 -0500 Subject: [TUHS] v7 source code for sh In-Reply-To: <69d88b37-5817-9a0d-4971-3d8641c2d153@gmail.com> References: <69d88b37-5817-9a0d-4971-3d8641c2d153@gmail.com> Message-ID: Sure - this is lovingly referred to as 'Bourne-gol.' Steve Bourne was part of the Algol-68 development team at Cambridge before he came to BTL. Besides his being the 'editor' / 'release manager' of V7 (as Dennis is said to exclaimed 'never again' after V6), please also look at the sources to adb, srb's other major contribution (it is also written using his same macros). It's also why the syntax of his shell is basically Algol syntax. Clem On Sat, Feb 19, 2022 at 10:44 AM Will Senn wrote: > I have been poring through the v7 source code lately, and came across an > oddity I would like to know more about. Specifically, in sh. The code for > sh is c, but it makes *extensive* use of of macros, for example: > > /usr/src/cmd/sh/word.c > ... > WHILE (c=nextc(0), space(c)) DONE > ... > > The macros for sh are defined in mac.h: > > /usr/src/cmd/sh/mac.h > ... > #define BEGIN { > #define END } > #define SWITCH switch( > #define IN ){ > #define ENDSW } > #define FOR for( > #define WHILE while( > #define DO ){ > #define OD ;} > #define REP do{ > #define PER }while( > #define DONE ); > ... > > I can read the resultant code through the lens of my experience coding c, > but I'm curious why the macros and how this came about? In v6, the sh > source is straight up c. Is there a story behind it worth knowing? > > Thanks, > > Will > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Sun Feb 20 02:06:23 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Sat, 19 Feb 2022 08:06:23 -0800 Subject: [TUHS] v7 source code for sh In-Reply-To: <69d88b37-5817-9a0d-4971-3d8641c2d153@gmail.com> References: <69d88b37-5817-9a0d-4971-3d8641c2d153@gmail.com> Message-ID: <34EEC8D8-77BD-4A44-8C30-4E1C9015F42D@iitbombay.org> https://research.swtch.com/shmacro > On Feb 19, 2022, at 7:44 AM, Will Senn wrote: > >  I have been poring through the v7 source code lately, and came across an oddity I would like to know more about. Specifically, in sh. The code for sh is c, but it makes extensive use of of macros, for example: > /usr/src/cmd/sh/word.c > ... > WHILE (c=nextc(0), space(c)) DONE > ... > > The macros for sh are defined in mac.h: > /usr/src/cmd/sh/mac.h > ... > #define BEGIN { > #define END } > #define SWITCH switch( > #define IN ){ > #define ENDSW } > #define FOR for( > #define WHILE while( > #define DO ){ > #define OD ;} > #define REP do{ > #define PER }while( > #define DONE ); > ... > I can read the resultant code through the lens of my experience coding c, but I'm curious why the macros and how this came about? In v6, the sh source is straight up c. Is there a story behind it worth knowing? > > Thanks, > > Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Feb 20 02:07:53 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 19 Feb 2022 11:07:53 -0500 Subject: [TUHS] v7 source code for sh In-Reply-To: References: <69d88b37-5817-9a0d-4971-3d8641c2d153@gmail.com> Message-ID: On Sat, Feb 19, 2022 at 11:04 AM Steve Nickolas wrote: > Apparently Bourne was heavily into ALGOL, > That's sort of an understatement. I believe that when he was at Cambridge, he was one of the people that helped to take the Algol-X proposal and turned it into the Algol-68 definition. I also believe he worked on their famous implementation of same. -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Sun Feb 20 02:43:11 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Sat, 19 Feb 2022 11:43:11 -0500 (EST) Subject: [TUHS] v7 source code for sh In-Reply-To: References: <69d88b37-5817-9a0d-4971-3d8641c2d153@gmail.com> Message-ID: On Sat, 19 Feb 2022, Steve Nickolas wrote: > At least, that's what I concluded by reading her Wikipedia page as well as > the code. Oops, braino. Obviously I meant "his" -uso. From will.senn at gmail.com Sun Feb 20 02:57:11 2022 From: will.senn at gmail.com (Will Senn) Date: Sat, 19 Feb 2022 10:57:11 -0600 Subject: [TUHS] v7 source code for sh In-Reply-To: <34EEC8D8-77BD-4A44-8C30-4E1C9015F42D@iitbombay.org> References: <69d88b37-5817-9a0d-4971-3d8641c2d153@gmail.com> <34EEC8D8-77BD-4A44-8C30-4E1C9015F42D@iitbombay.org> Message-ID: <8417bc40-5970-a427-dfd5-dc4b99eb01ae@gmail.com> Thanks Bakul, that's interesting. Impetus for the obfuscated c contest?! The same contest where a guy wrote a pdp11 emulator capable of running v0, v6, and 2.9bsd in 50 lines of c (Mills, 2018)? I still get a kick out of that code. Particularly because you can run Mullender's 1984 entry on the 2.9 bsd instance it hosts (it also works in v7, but it's too fast, even with stty 300). Thankfully, macros, while adding an additional layer of complexity, aren't as impenetrable as the ioccc stuff: mills's prog.c snippet: struct timeval F,G; struct termios H,U={ T} ; enum{ N=64,a=N<<7,b=a-1,c=a*32,d =c-1,    e=c/    2,f=    a*2,    g=a/2,h =g/2,j =h/ 2,Q=V*j*5} ; char*s=P,K,M; int*      p,      l[      a]      ,m,n,J,o=A, O=j,E,R,i,k,t,r,q,u,v,w,x,y,z ,B,C,    *D,Z    ;int    main    (){ for(D=mmap... mullender's mullender.c in it's entirety (requires v7 or better and pdp11): short main[] = {     277, 04735, -4129, 25, 0, 477, 1019, 0xbef, 0, 12800,     -113, 21119, 0x52d7, -1006, -7151, 0, 0x4bc, 020004,     14880, 10541, 2056, 04010, 4548, 3044, -6716, 0x9,     4407, 6, 5568, 1, -30460, 0, 0x9, 5570, 512, -30419,     0x7e82, 0760, 6, 0, 4, 02400, 15, 0, 4, 1280, 4, 0,     4, 0, 0, 0, 0x8, 0, 4, 0, ',', 0, 12, 0, 4, 0, '#',     0, 020, 0, 4, 0, 30, 0, 026, 0, 0x6176, 120, 25712,     'p', 072163, 'r', 29303, 29801, 'e' }; Later, Will On 2/19/22 10:06 AM, Bakul Shah wrote: > https://research.swtch.com/shmacro > >> On Feb 19, 2022, at 7:44 AM, Will Senn wrote: >> >>  I have been poring through the v7 source code lately, and came >> across an oddity I would like to know more about. Specifically, in >> sh. The code for sh is c, but it makes *extensive* use of of macros, >> for example: >> >> /usr/src/cmd/sh/word.c >> ... >> WHILE (c=nextc(0), space(c)) DONE >> ... >> >> The macros for sh are defined in mac.h: >> >> /usr/src/cmd/sh/mac.h >> ... >> #define BEGIN   { >> #define END     } >> #define SWITCH  switch( >> #define IN      ){ >> #define ENDSW   } >> #define FOR     for( >> #define WHILE   while( >> #define DO      ){ >> #define OD      ;} >> #define REP     do{ >> #define PER     }while( >> #define DONE    ); >> ... >> >> I can read the resultant code through the lens of my experience >> coding c, but I'm curious why the macros and how this came about? In >> v6, the sh source is straight up c. Is there a story behind it worth >> knowing? >> >> Thanks, >> >> Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Sun Feb 20 03:24:42 2022 From: ron at ronnatalie.com (Ron Natalie) Date: Sat, 19 Feb 2022 12:24:42 -0500 Subject: [TUHS] v7 source code for sh In-Reply-To: References: Message-ID: This persisted in the shell until S5R2 when someone gratefully undid all those macros. adb was similarly afflicted. > On Feb 19, 2022, at 11:04, Steve Nickolas wrote: > > On Sat, 19 Feb 2022, Will Senn wrote: >> I have been poring through the v7 source code lately, and came across an oddity I would like to know more about. Specifically, in sh. The code for sh is c, but it makes *extensive* use of of macros, for example: > > > >> I can read the resultant code through the lens of my experience coding c, but I'm curious why the macros and how this came about? In v6, the sh source is straight up c. Is there a story behind it worth knowing? > > Apparently Bourne was heavily into ALGOL, and used those macros to make C into something more familiar. > > At least, that's what I concluded by reading her Wikipedia page as well as the code. > > -uso. From bakul at iitbombay.org Sun Feb 20 03:44:29 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Sat, 19 Feb 2022 09:44:29 -0800 Subject: [TUHS] v7 source code for sh Message-ID: <8102A7AB-21F5-477D-8D37-5412103CD396@iitbombay.org> On Feb 19, 2022, at 8:11 AM, Clem Cole wrote: > >  > On Sat, Feb 19, 2022 at 11:04 AM Steve Nickolas wrote: >> Apparently Bourne was heavily into ALGOL, > That's sort of an understatement. I believe that when he was at Cambridge, he was one of the people that helped to take the Algol-X proposal and turned it into the Algol-68 definition. I also believe he worked on their famous implementation of same. Some of you may be interested in this “A history of Algol68” paper: https://dl.acm.org/doi/pdf/10.1145/234286.1057810 The author, Charles H Lindsey, still occasionally posts on comp.lang.misc about Algol68. Among other things Bourne was a coauthor of Algol68C, a portable implementation of Algol68. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sun Feb 20 04:44:46 2022 From: robpike at gmail.com (Rob Pike) Date: Sun, 20 Feb 2022 05:44:46 +1100 Subject: [TUHS] v7 source code for sh In-Reply-To: <8102A7AB-21F5-477D-8D37-5412103CD396@iitbombay.org> References: <8102A7AB-21F5-477D-8D37-5412103CD396@iitbombay.org> Message-ID: I undid all the macros for the v8 shell, with Steve's blessing, before doing the key work on that shell. But no one outside cared about any of the research Unixes after v7, sad though that is to admit, so his macros and griping about them lingered on in the world. I did the same to adb, which turned out to have a really good debugger hidden under a few serious bugs of its own, which I fixed. -rob On Sun, Feb 20, 2022 at 4:46 AM Bakul Shah wrote: > On Feb 19, 2022, at 8:11 AM, Clem Cole wrote: > >  > On Sat, Feb 19, 2022 at 11:04 AM Steve Nickolas wrote: > >> Apparently Bourne was heavily into ALGOL, >> > That's sort of an understatement. I believe that when he was at > Cambridge, he was one of the people that helped to take the Algol-X > proposal and turned it into the Algol-68 definition. I also believe he > worked on their famous implementation of same. > > > Some of you may be interested in this “A history of Algol68” paper: > https://dl.acm.org/doi/pdf/10.1145/234286.1057810 > The author, Charles H Lindsey, still occasionally posts on comp.lang.misc > about Algol68. Among other things Bourne was a coauthor of Algol68C, > a portable implementation of Algol68. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Feb 20 05:29:11 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 19 Feb 2022 14:29:11 -0500 Subject: [TUHS] v7 source code for sh In-Reply-To: References: <8102A7AB-21F5-477D-8D37-5412103CD396@iitbombay.org> Message-ID: On Sat, Feb 19, 2022 at 1:44 PM Rob Pike wrote: > I did the same to adb, which turned out to have a really good debugger > hidden under a few serious bugs of its own, which I fixed. > Amen ... still my favorite. A number of us fixed them too. In fact, we put it into the kernel as kdb in the Masscomp system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Sun Feb 20 08:39:55 2022 From: cowan at ccil.org (John Cowan) Date: Sat, 19 Feb 2022 17:39:55 -0500 Subject: [TUHS] v7 source code for sh In-Reply-To: References: <8102A7AB-21F5-477D-8D37-5412103CD396@iitbombay.org> Message-ID: On Sat, Feb 19, 2022 at 1:45 PM Rob Pike wrote: > I undid all the macros for the v8 shell, with Steve's blessing, before > doing the key work on that shell. But no one outside cared about any of the > research Unixes after v7, > Lots of us would have loved to care about them and were sad that we couldn't until they were open sourced much later. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mascheck at in-ulm.de Sun Feb 20 09:11:59 2022 From: mascheck at in-ulm.de (Sven Mascheck) Date: Sun, 20 Feb 2022 00:11:59 +0100 Subject: [TUHS] v7 source code for sh In-Reply-To: References: <8102A7AB-21F5-477D-8D37-5412103CD396@iitbombay.org> Message-ID: <4a8c1f33-ab34-7f5d-321a-a8d759eee7c8@in-ulm.de> On 19.02.2022 23:39, John Cowan wrote: > On Sat, Feb 19, 2022 at 1:45 PM Rob Pike wrote: > > I undid all the macros for the v8 shell, with Steve's blessing, > before doing the key work on that shell. But no one outside cared > about any of the research Unixes after v7, > > > Lots of us would have loved to care about them and were sad that we > couldn't until they were open sourced much later. 8th ed sh (about '84) brought quite a few changes and fixes. Just naming a few: - environment variable HISTORY, pointing to a writable file, providing a history mechanism by means of "=(1)" - type is replaced by whatis, which produces output that can be re-evaluated by the shell - functions can be exported, in the same ways like variables keyword history: I always imagined that the Bourne shell would have been in much wider use even nowadays, if only it had provided line editing and a history at some point. Why not? Even Kenneth Almquist released his SVR4-like reimplementation intentionally without history. All that might have been implemented more elegant directly in the terminal I/O instead of in every program? (that is, not in a MS-DOS-like way, where every program even needs its own pager). I still wonder if it would be possible to properly provide line editing and history in the terminal I/O in general. Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sun Feb 20 09:34:40 2022 From: robpike at gmail.com (Rob Pike) Date: Sun, 20 Feb 2022 10:34:40 +1100 Subject: [TUHS] v7 source code for sh In-Reply-To: <4a8c1f33-ab34-7f5d-321a-a8d759eee7c8@in-ulm.de> References: <8102A7AB-21F5-477D-8D37-5412103CD396@iitbombay.org> <4a8c1f33-ab34-7f5d-321a-a8d759eee7c8@in-ulm.de> Message-ID: Terminal editing was done in general on the Blit and follow-on systems. That's primarily why the Research shells didn't do it. But history (ha!) chose another path. -rob On Sun, Feb 20, 2022 at 10:20 AM Sven Mascheck wrote: > On 19.02.2022 23:39, John Cowan wrote: > > On Sat, Feb 19, 2022 at 1:45 PM Rob Pike wrote: > > >> I undid all the macros for the v8 shell, with Steve's blessing, before >> doing the key work on that shell. But no one outside cared about any of the >> research Unixes after v7, >> > > Lots of us would have loved to care about them and were sad that we > couldn't until they were open sourced much later. > > > 8th ed sh (about '84) brought quite a few changes and fixes. Just naming a > few: > - environment variable HISTORY, pointing to a writable file, providing a > history mechanism by means of "=(1)" > - type is replaced by whatis, which produces output that can be > re-evaluated by the shell > - functions can be exported, in the same ways like variables > > keyword history: I always imagined that the Bourne shell would have been > in much wider use even nowadays, if only it had provided line editing and a > history at some point. Why not? Even Kenneth Almquist released his > SVR4-like reimplementation intentionally without history. All that might > have been implemented more elegant directly in the terminal I/O instead of > in every program? (that is, not in a MS-DOS-like way, where every program > even needs its own pager). > > I still wonder if it would be possible to properly provide line editing > and history in the terminal I/O in general. > > Sven > -------------- next part -------------- An HTML attachment was scrubbed... URL: From silas8642 at hotmail.co.uk Sun Feb 20 09:36:40 2022 From: silas8642 at hotmail.co.uk (silas poulson) Date: Sat, 19 Feb 2022 23:36:40 +0000 Subject: [TUHS] v7 source code for sh In-Reply-To: <4a8c1f33-ab34-7f5d-321a-a8d759eee7c8@in-ulm.de> References: <8102A7AB-21F5-477D-8D37-5412103CD396@iitbombay.org> <4a8c1f33-ab34-7f5d-321a-a8d759eee7c8@in-ulm.de> Message-ID: <301B9E3B-742B-4396-8414-C47AF6CE3806@hotmail.co.uk> > On 19 Feb 2022, at 23:11, Sven Mascheck wrote: > I still wonder if it would be possible to properly provide line editing and history in the terminal I/O in general. Probably not quite what you mean, but enjoy Plan 9’s combination via acme of text executable wherever exists and can see what you’ve written and how it’s been changed. Silas From rudi.j.blom at gmail.com Sun Feb 20 17:24:23 2022 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Sun, 20 Feb 2022 14:24:23 +0700 Subject: [TUHS] v7 source code for sh Message-ID: Second half of the 1980-tish when the computer division of Philips Electronics started on their own Motorola M68010 / UNIX System V.3 (don't remember for sure I'm afraid) they used a syntax.h with macros similar to mac.h. Only I understand it's more Pascal like. Appended the 1987 version I found in my archive. Cheers, rubl -- The more I learn the better I understand I know nothing. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- /* SCCSID(" @(#)syntax.h 87/08/01 )" */ #ifndef SYNTAX_H #define SYNTAX_H /* For a full explanation see the file syntax.help */ #define IF if( #define THEN ){ #define ELSIF }else if( #define ELSE }else{ #define ENDIF } #define NOT ! #define AND && #define OR || #define CASE switch( #define OF ){ #define ENDCASE break;} #define WHEN break;case #define CWHEN case #define IMPL : #define COR :case #define BREAK break #define WHENOTHERS break;default #define CWHENOTHERS default #define SELECT do{{ #define SWHEN }if( #define SIMPL ){ #define ENDSELECT }}while(0) #define SCOPE { #define ENDSCOPE } #define BLOCK { #define ENDBLOCK } #define FOREVER for(;; #define FOR for( #define SKIP #define COND ; #define STEP ; #define LOOP ){ #define ENDLOOP } #define NULLOOP ){} #define WHILE while( #define DO do{ #define UNTIL }while(!( #define ENDDO )) #define EXITWHEN(e) if(e)break #define CONTINUE continue #define RETURN return #define GOTO goto #define STRUCT struct #define UNION union #define TYPE typedef #define IS #define SIZEOF sizeof #define UNSIGNED unsigned #define CHAR char #define UCHAR unsigned char #define BYTE char #define UBYTE unsigned char #define SHORT short #define USHORT unsigned short #define INT int #define UINT unsigned int #define VOID void #define LONG long #define ULONG unsigned long #define FLOAT float #define DOUBLE double #define ENUM enum #define PRIVATE static #define IMPORT extern #define EXPORT #define AUTO auto #define FAST register #define FALSE 0 #define TRUE 1 #define MODULE(m,id) static char __mod__[]="m";\ static char __file__[]=__FILE__;static char __filid__[]="id" #define PROC #define ENDMODULE #define SHOULD_NOT #endif /* SYNTAX_H */ From dfawcus+lists-tuhs at employees.org Mon Feb 21 03:29:52 2022 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Sun, 20 Feb 2022 17:29:52 +0000 Subject: [TUHS] Lorinda Cherry In-Reply-To: <4E3028A1-EC08-424A-B814-CC2AEEEAEC7B@iitbombay.org> References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> <4E3028A1-EC08-424A-B814-CC2AEEEAEC7B@iitbombay.org> Message-ID: On Thu, Feb 17, 2022 at 01:44:07PM -0800, Bakul Shah wrote: > MacOS (m1 pro, prob. 2Ghz) > $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx > time: command terminated abnormally > 1.00 real 0.98 user 0.01 sys > [2] 37135 segmentation fault command time dc <<< > xxx > $ wc xxx > 7342 7342 42626 xxx > $ size `which dc` > __TEXT __DATA __OBJC others dec hex > 32768 16384 0 4295016448 4295065600 100018000 So macOS has got worse, or the systems have: $ sysctl machdep.cpu.brand_string machdep.cpu.brand_string: Intel(R) Core(TM)2 Duo CPU U9400 @ 1.40GHz $ uname -a Darwin Old-MBA.local 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 21 20:07:40 PDT 2018; root:xnu-3248.73.11~1/RELEASE_X86_64 x86_64 Old-MBA:~ derek$ time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx Segmentation fault: 11 real 0m14.982s user 0m12.608s sys 0m0.206s $ wc xxx 7868 7868 45782 xxx My old machine computed more primes before the program crashed! Given the comment about the GNU s/w running out of stack, I guess the x86 version uses smaller stack frames. DF From chet.ramey at case.edu Mon Feb 21 06:54:12 2022 From: chet.ramey at case.edu (Chet Ramey) Date: Sun, 20 Feb 2022 15:54:12 -0500 Subject: [TUHS] v7 source code for sh In-Reply-To: <4a8c1f33-ab34-7f5d-321a-a8d759eee7c8@in-ulm.de> References: <8102A7AB-21F5-477D-8D37-5412103CD396@iitbombay.org> <4a8c1f33-ab34-7f5d-321a-a8d759eee7c8@in-ulm.de> Message-ID: <5a9e9d48-aaad-851e-94af-1f4c100e1eb2@case.edu> On 2/19/22 6:11 PM, Sven Mascheck wrote: > keyword history: I always imagined that the Bourne shell would have been in > much wider use even nowadays, if only it had provided line editing and a > history at some point. Why not? I think it's that the people with the power to make it happen didn't view it as an appropriate feature for the shell. It was much easier to implement in the shell, both technically and socially. Instead of having to convince kernel developers to implement and maintain editing in the terminal driver (both emacs and vi modes, to boot), it's easier for one person, maybe a few, to do a user-space implementation. That's how it ended up in ksh, for instance. Rob already talked about the Blit editing, which obviated the need to have it in the shell. > Even Kenneth Almquist released his > SVR4-like reimplementation intentionally without history. Almquist released `atty' the same time as `ash', so he did at least provide a way to do editing and history using ptys, in the same way that `rlwrap' wraps readline. But he decried its lack of "elegance," and described it as something that "should be rewritten properly, with appropriate kernel support." > All that might > have been implemented more elegant directly in the terminal I/O instead of > in every program? (that is, not in a MS-DOS-like way, where every program > even needs its own pager). Elegant, maybe, but it never seemed to take off. There were a few different implementations, but none was ever blessed as something officially integrated into a widely-distributed kernel. (As I recall, Jon Payne, who wrote JOVE while in high school (!), wrote one as a college course project. I remember him describing it on Usenet back in the day. There were others.) It always seemed like it would have been just the thing to implement as a tty streams module, but research Unix went in a different direction. -- ``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 lm at mcvoy.com Mon Feb 21 07:02:16 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 20 Feb 2022 13:02:16 -0800 Subject: [TUHS] v7 source code for sh In-Reply-To: <5a9e9d48-aaad-851e-94af-1f4c100e1eb2@case.edu> References: <8102A7AB-21F5-477D-8D37-5412103CD396@iitbombay.org> <4a8c1f33-ab34-7f5d-321a-a8d759eee7c8@in-ulm.de> <5a9e9d48-aaad-851e-94af-1f4c100e1eb2@case.edu> Message-ID: <20220220210216.GJ3964@mcvoy.com> On Sun, Feb 20, 2022 at 03:54:12PM -0500, Chet Ramey wrote: > >All that might have been implemented more elegant directly in the terminal > >I/O instead of in every program? (that is, not in a MS-DOS-like way, where > >every program even needs its own pager). > > Elegant, maybe, but it never seemed to take off. > > It always seemed like it would have been just the thing to implement as a > tty streams module, but research Unix went in a different direction. Not really. You want history files, I have one for each tty. Telling the tty driver to write to this inode seems sort of weird. I guess you could make it work, but to me, this screams libc or libhistory or something like that. I agree it shouldn't be in each app that wants it but isn't that what libraries are for? From chet.ramey at case.edu Mon Feb 21 07:19:30 2022 From: chet.ramey at case.edu (Chet Ramey) Date: Sun, 20 Feb 2022 16:19:30 -0500 Subject: [TUHS] v7 source code for sh In-Reply-To: <20220220210216.GJ3964@mcvoy.com> References: <8102A7AB-21F5-477D-8D37-5412103CD396@iitbombay.org> <4a8c1f33-ab34-7f5d-321a-a8d759eee7c8@in-ulm.de> <5a9e9d48-aaad-851e-94af-1f4c100e1eb2@case.edu> <20220220210216.GJ3964@mcvoy.com> Message-ID: On 2/20/22 4:02 PM, Larry McVoy wrote: >> It always seemed like it would have been just the thing to implement as a >> tty streams module, but research Unix went in a different direction. > > Not really. You want history files, I have one for each tty. Telling > the tty driver to write to this inode seems sort of weird. I guess you > could make it work, but to me, this screams libc or libhistory or > something like that. History maybe, but most folks seem to want editing more, and just that incremental improvement would have made a difference. > I agree it shouldn't be in each app that wants > it but isn't that what libraries are for? That's why readline is a library, with application-specific hooks available, and relies on something like rlwrap if you want to use editing and history with an unmodified application. -- ``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 lyndon at orthanc.ca Mon Feb 21 07:19:01 2022 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Sun, 20 Feb 2022 13:19:01 -0800 Subject: [TUHS] v7 source code for sh In-Reply-To: <5a9e9d48-aaad-851e-94af-1f4c100e1eb2@case.edu> References: <8102A7AB-21F5-477D-8D37-5412103CD396@iitbombay.org> <4a8c1f33-ab34-7f5d-321a-a8d759eee7c8@in-ulm.de> <5a9e9d48-aaad-851e-94af-1f4c100e1eb2@case.edu> Message-ID: Chet Ramey writes: > It always seemed like it would have been just the thing to implement as a > tty streams module, but research Unix went in a different direction. I'm really surprised nobody has implemented a basic readline as a tty line discipline by now. I was poking around the OpenBSD NMEA line discipline code a few weeks ago and thinking it shouldn't be that hard to do. Did anyone think about doing this in the past? If yes, what made you decide against doing it? (Or a streams implementation, for that matter.) --lyndon From chet.ramey at case.edu Mon Feb 21 08:39:46 2022 From: chet.ramey at case.edu (Chet Ramey) Date: Sun, 20 Feb 2022 17:39:46 -0500 Subject: [TUHS] v7 source code for sh In-Reply-To: References: <8102A7AB-21F5-477D-8D37-5412103CD396@iitbombay.org> <4a8c1f33-ab34-7f5d-321a-a8d759eee7c8@in-ulm.de> <5a9e9d48-aaad-851e-94af-1f4c100e1eb2@case.edu> Message-ID: <615ad728-4a33-29d9-73a9-80f51e35f68e@case.edu> On 2/20/22 4:19 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > Chet Ramey writes: > >> It always seemed like it would have been just the thing to implement as a >> tty streams module, but research Unix went in a different direction. > > I'm really surprised nobody has implemented a basic readline as a > tty line discipline by now. I was poking around the OpenBSD NMEA > line discipline code a few weeks ago and thinking it shouldn't be > that hard to do. It's not that hard. The complexity is in how sophisticated you want to get with redisplay and whether you want to allow user-specified key bindings. > Did anyone think about doing this in the past? If yes, what made you > decide against doing it? (Or a streams implementation, for that matter.) There have been several implementations (I never did one). I suspect that the people who were in a position to integrate that functionality into distributed kernels were not supportive, or the code didn't get to them at the right time. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From crossd at gmail.com Mon Feb 21 11:01:12 2022 From: crossd at gmail.com (Dan Cross) Date: Sun, 20 Feb 2022 20:01:12 -0500 Subject: [TUHS] v7 source code for sh In-Reply-To: <615ad728-4a33-29d9-73a9-80f51e35f68e@case.edu> References: <8102A7AB-21F5-477D-8D37-5412103CD396@iitbombay.org> <4a8c1f33-ab34-7f5d-321a-a8d759eee7c8@in-ulm.de> <5a9e9d48-aaad-851e-94af-1f4c100e1eb2@case.edu> <615ad728-4a33-29d9-73a9-80f51e35f68e@case.edu> Message-ID: On Sun, Feb 20, 2022 at 5:42 PM Chet Ramey wrote: > On 2/20/22 4:19 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > > Did anyone think about doing this in the past? If yes, what made you > > decide against doing it? (Or a streams implementation, for that matter.) > > There have been several implementations (I never did one). I suspect that > the people who were in a position to integrate that functionality into > distributed kernels were not supportive, or the code didn't get to them > at the right time. > At this point, it feels like the die has been cast. Readline, or something like it, is "good enough" and those working with something plan9-like don't need the functionality at all. Arguably, on Unix-style systems it would be cleaner to do in the kernel, but aside from aesthetics, what's the incentive to change? - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Tue Feb 22 03:58:22 2022 From: norman at oclsc.org (Norman Wilson) Date: Mon, 21 Feb 2022 12:58:22 -0500 (EST) Subject: [TUHS] v7 source code for sh Message-ID: Rob Pike: I did the same to adb, which turned out to have a really good debugger hidden under a few serious bugs of its own, which I fixed. ===== Memories. Was it you who replaced ptrace with /proc in adb, or did I do that? I do remember I was the one who took ptrace out of sdb (which a few 1127-ers, or perhaps 112-ers on alice and rabbit still used). After which I removed ptrace from the kernel, and from the copy of the V8 manual in the UNIX room. Conveniently ptrace occupied two facing pages; I glued them together. I also later did some work to try to isolate the target-dependent parts of adb and to make them work in host-independent ways--e.g. assembling ints byte-by-byte rather than assuming byte order--to make it easier to make a cross adb, e.g. to examine PDP-11 or 68K core dumps on a VAX. I miss adb; maybe it's time to revive it, though these days I'd be tempted to rewrite it in Python so I could just load the right module at runtime to pick the desired target. Norman Wilson Toronto ON From robpike at gmail.com Tue Feb 22 04:10:14 2022 From: robpike at gmail.com (Rob Pike) Date: Tue, 22 Feb 2022 05:10:14 +1100 Subject: [TUHS] v7 source code for sh In-Reply-To: References: Message-ID: It was likely me, as I did a lot of work on the program, but I don't claim that I was the one. There is a db (the Plan 9 derivation of adb) in plan9port, but it struggles with modern binaries. -rob On Tue, Feb 22, 2022 at 5:00 AM Norman Wilson wrote: > Rob Pike: > > I did the same to adb, which turned out to have a really good debugger > hidden under a few serious bugs of its own, which I fixed. > > ===== > > Memories. > > Was it you who replaced ptrace with /proc in adb, or did I do that? > > I do remember I was the one who took ptrace out of sdb (which a > few 1127-ers, or perhaps 112-ers on alice and rabbit still used). > After which I removed ptrace from the kernel, and from the > copy of the V8 manual in the UNIX room. Conveniently ptrace > occupied two facing pages; I glued them together. > > I also later did some work to try to isolate the target-dependent > parts of adb and to make them work in host-independent ways--e.g. > assembling ints byte-by-byte rather than assuming byte order--to > make it easier to make a cross adb, e.g. to examine PDP-11 or > 68K core dumps on a VAX. > > I miss adb; maybe it's time to revive it, though these days I'd > be tempted to rewrite it in Python so I could just load the right > module at runtime to pick the desired target. > > Norman Wilson > Toronto ON > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at cuzuco.com Tue Feb 22 10:02:39 2022 From: tuhs at cuzuco.com (Brian Walden) Date: Mon, 21 Feb 2022 19:02:39 -0500 (EST) Subject: [TUHS] Lorinda Cherry Message-ID: <202202220002.21M02d4g023128@cuzuco.com> I enjoy this dc(1) discussion. I am a daily dc user, and since my fisrt calculator was an HP-45 (circa 1973) RPN felt right. However I think dc pre-dates ALL HP calculators, since there was one in the 1st Edition written in assembly. I extened my version of dc (way before gnu existed) based on common buttons I used from HP calculators: CMD WHAT # comment, to new line ~ change sign of top of stack (CHS key) | 1/top of stack (1/x key) e push 99 digits of e (2.718..) on the stack @ push 99 digits of pi on the stack (looks like a circle) r reverse top of stack (x<>y key) I had been fascinated with pi stemimg from the Star Trek epsiode Wolf in the Fold where Spock uses it to usa all computing power "Computer, this is a Class A compulsory directive. Compute to the last digit the value of pi." "As we know, the value of pi is a transcendental figure without resolution. The computer banks will work on this problem to the exclusion of all else until we order it to stop." As it was supposed to be "arbitrary precision" here was my tool. So I wrote Machin formula in dc slowing increasing the scale and printing the results. In the orginal dc, yes the whole part was arbitrary, but the decimal part (scale) was limited to 99. Well that became a disappiontment. (this program is lost to time) So I decided to rewrite it but increasing pi as a whole numbers instead of increasing scale (ex. 31415, 314159, 3141592, ... etc) I still have that program which is simply this -- [sxln_1ll*dsllb*dszli2+dsi5li^*/+dsn4*lelzli239li^*/+dse-dlx!=Q]sQ 1[ddsb5/sn239/se1ddsisllQx4*pclb10*lPx]dsPx if you run it you'll notice the last 1 to 2 digits are wrong due to precision. The next problem became small memory. I still have thes saved output before it crashed at 1024 digits. No idea what specs of the machine it was run on anymore its really old -- 3141592653589793238462643383279502884197169399375105820974944592307816\ 4062862089986280348253421170679821480865132823066470938446095505822317\ 2535940812848111745028410270193852110555964462294895493038196442881097\ 5665933446128475648233786783165271201909145648566923460348610454326648\ 2133936072602491412737245870066063155881748815209209628292540917153643\ 6789259036001133053054882046652138414695194151160943305727036575959195\ 3092186117381932611793105118548074462379962749567351885752724891227938\ 1830119491298336733624406566430860213949463952247371907021798609437027\ 7053921717629317675238467481846766940513200056812714526356082778577134\ 2757789609173637178721468440901224953430146549585371050792279689258923\ 5420199561121290219608640344181598136297747713099605187072113499999983\ 7297804995105973173281609631859502445945534690830264252230825334468503\ 5261931188171010003137838752886587533208381420617177669147303598253490\ 4287554687311595628638823537875937519577818577805321712268066130019278\ 76611195909216420198938095257201065485862972 out of space: salloc all 8587356 rel 8587326 headmor 1 nbytes -28318 stk 71154 rd 125364 wt 125367 beg 125364 last 125367 83 11 0 30 IOT trap - core dumped But I was much happier with that. On a side note: programming dc is hard. There was no comment character. And it's a pain to read, and it's a pain to debug. When I discovered the Chudnovsky algorithm for pi, of course I implemented it in dc -- [0ksslk3^16lkd12+sk*-lm*lhd1+sh3^/smlx_262537412640768000*sxll545140134+dsllm*lxlnk/ls+dls!=P]sP 7sn[6sk1ddshsxsm13591409dsllPx10005v426880*ls/K3-k1/pcln14+snlMx]dsMx At 99 digits of scale it ran out in 7 rounds, but now with that limitation removed and large memeories it just goes on and on..... -Brian PS: Thanks for the fast OpenBSD version of dc, Otto. Otto Moerbeek wrote: > On Thu, Feb 17, 2022 at 01:44:07PM -0800, Bakul Shah wrote: > > > On Feb 17, 2022, at 1:18 PM, Dave Horsfall wrote: > > > > > > On Thu, 17 Feb 2022, Tom Ivar Helbekkmo via TUHS wrote: > > > > > >> Watching the prime number generator (from the Wikipedia page on dc) > > >> running on the 11/23 is much more entertaining than doing it on the > > >> modern workstation I'm typing this on: > > >> > > >> 2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x > > > > > > Wow... About 10s on my old MacBook Pro, and I gave up on my ancient > > > FreeBSD box. > > > > That may be because FreeBSD continues computing primes while the MacOS > > dc gives up after a while! > > > > freebsd (ryzen 2700 3.2Ghz): # note: I interrupted dc after a while > > $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx > > ^C 11.93 real 11.79 user 0.13 sys > > $ wc xxx > > 47161 47161 319109 xxx > > $ size `which dc` > > text data bss dec hex filename > > 238159 2784 11072 252015 0x3d86f /usr/bin/dc > > > > MacOS (m1 pro, prob. 2Ghz) > > $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx > > time: command terminated abnormally > > 1.00 real 0.98 user 0.01 sys > > [2] 37135 segmentation fault command time dc <<< > xxx > > $ wc xxx > > 7342 7342 42626 xxx > > $ size `which dc` > > __TEXT __DATA __OBJC others dec hex > > 32768 16384 0 4295016448 4295065600 100018000 > > > > MacOS uses the GNU implementation which has a long standing issue with > deep recursion. It even cannot handle the tail recursive calls used > here and will run out of its stack. > > -Otto From tuhs at cuzuco.com Tue Feb 22 13:07:58 2022 From: tuhs at cuzuco.com (Brian Walden) Date: Mon, 21 Feb 2022 22:07:58 -0500 (EST) Subject: [TUHS] v7 source code for sh Message-ID: <202202220308.21M37wSb025906@cuzuco.com> The one I remember using in the 80s was called "fep" written by Kazumasa Utashiro of Software Research Associates. It was probbaly posetd posted to comp.sources.unix usenet group. -Brian Chet Ramey wrote: > On 2/20/22 4:19 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > > Chet Ramey writes: > > > >> It always seemed like it would have been just the thing to implement as a > >> tty streams module, but research Unix went in a different direction. > > > > I'm really surprised nobody has implemented a basic readline as a > > tty line discipline by now. I was poking around the OpenBSD NMEA > > line discipline code a few weeks ago and thinking it shouldn't be > > that hard to do. > > It's not that hard. The complexity is in how sophisticated you want to get > with redisplay and whether you want to allow user-specified key bindings. > > > Did anyone think about doing this in the past? If yes, what made you > > decide against doing it? (Or a streams implementation, for that matter.) > > There have been several implementations (I never did one). I suspect that > the people who were in a position to integrate that functionality into > distributed kernels were not supportive, or the code didn't get to them > at the right time. > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From drsalists at gmail.com Tue Feb 22 14:54:53 2022 From: drsalists at gmail.com (Dan Stromberg) Date: Mon, 21 Feb 2022 20:54:53 -0800 Subject: [TUHS] v7 source code for sh In-Reply-To: References: <8102A7AB-21F5-477D-8D37-5412103CD396@iitbombay.org> <4a8c1f33-ab34-7f5d-321a-a8d759eee7c8@in-ulm.de> <5a9e9d48-aaad-851e-94af-1f4c100e1eb2@case.edu> <615ad728-4a33-29d9-73a9-80f51e35f68e@case.edu> Message-ID: On Sun, Feb 20, 2022 at 5:05 PM Dan Cross wrote: > > At this point, it feels like the die has been cast. Readline, or something > like it, is "good enough" and those working with something plan9-like don't > need the functionality at all. Arguably, on Unix-style systems it would be > cleaner to do in the kernel, but aside from aesthetics, what's the > incentive to change? > Actually, isn't it usually better to put functionality in userspace libraries than inside an OS kernel, where feasible? Big kernels are buggier and less secure. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Tue Feb 22 15:39:28 2022 From: robpike at gmail.com (Rob Pike) Date: Tue, 22 Feb 2022 16:39:28 +1100 Subject: [TUHS] v7 source code for sh In-Reply-To: References: <8102A7AB-21F5-477D-8D37-5412103CD396@iitbombay.org> <4a8c1f33-ab34-7f5d-321a-a8d759eee7c8@in-ulm.de> <5a9e9d48-aaad-851e-94af-1f4c100e1eb2@case.edu> <615ad728-4a33-29d9-73a9-80f51e35f68e@case.edu> Message-ID: Alea iacta est. -rob > > Big kernels are buggier and less secure. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: linux.jpeg Type: image/jpeg Size: 79964 bytes Desc: not available URL: From ggm at algebras.org Tue Feb 22 15:54:49 2022 From: ggm at algebras.org (George Michaelson) Date: Tue, 22 Feb 2022 15:54:49 +1000 Subject: [TUHS] v7 source code for sh In-Reply-To: References: <8102A7AB-21F5-477D-8D37-5412103CD396@iitbombay.org> <4a8c1f33-ab34-7f5d-321a-a8d759eee7c8@in-ulm.de> <5a9e9d48-aaad-851e-94af-1f4c100e1eb2@case.edu> <615ad728-4a33-29d9-73a9-80f51e35f68e@case.edu> Message-ID: its a logistic supply curve. When it exceeds the available memory, and we've run out of PDP8 cores to recycle, they declare it's done and ship V1.0. If you can predict the asymptote, put your Roth on memory shares! On Tue, Feb 22, 2022 at 3:42 PM Rob Pike wrote: > > Alea iacta est. > > -rob >> >> >> Big kernels are buggier and less secure. >> From ralph at inputplus.co.uk Tue Feb 22 20:39:48 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 22 Feb 2022 10:39:48 +0000 Subject: [TUHS] Lorinda Cherry In-Reply-To: References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> <4E3028A1-EC08-424A-B814-CC2AEEEAEC7B@iitbombay.org> Message-ID: <20220222103948.1B0482206F@orac.inputplus.co.uk> Hi Otto, > MacOS uses the GNU implementation which has a long standing issue with > deep recursion. It even cannot handle the tail recursive calls used > here and will run out of its stack. When learning dc and seeing it relied on tail calls, the first thing I did was check it did tail-call elimination, and it did. That was GNU dc. Trying just now, I see no growth in memory usage despite heavy CPU load shown by TIME increasing. $ dc !ps u `pidof dc` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND ralph 11489 0.0 0.0 2332 1484 pts/1 S+ 10:33 0:00 dc [lmx]smlmx ^C Interrupt! !ps u `pidof dc` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND ralph 11489 75.5 0.0 2332 1488 pts/1 S+ 10:33 0:46 dc The memory used remained at that level during the macro execution too, watched from outside. Do you have more detail on what GNU dc can't handle? dc without tail-call elimination is a bit crippled. -- Cheers, Ralph. From chet.ramey at case.edu Wed Feb 23 00:28:14 2022 From: chet.ramey at case.edu (Chet Ramey) Date: Tue, 22 Feb 2022 09:28:14 -0500 Subject: [TUHS] v7 source code for sh In-Reply-To: <202202220308.21M37wSb025906@cuzuco.com> References: <202202220308.21M37wSb025906@cuzuco.com> Message-ID: On 2/21/22 10:07 PM, Brian Walden wrote: > The one I remember using in the 80s was called "fep" written by > Kazumasa Utashiro of Software Research Associates. It was probbaly posetd > posted to comp.sources.unix usenet group. I still have a copy of that somewhere. -- ``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 clemc at ccc.com Wed Feb 23 00:47:24 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 22 Feb 2022 09:47:24 -0500 Subject: [TUHS] v7 source code for sh In-Reply-To: <202202220308.21M37wSb025906@cuzuco.com> References: <202202220308.21M37wSb025906@cuzuco.com> Message-ID: On Mon, Feb 21, 2022 at 10:11 PM Brian Walden wrote: > The one I remember using in the 80s was called "fep" written by > Kazumasa Utashiro of Software Research Associates. It was probbaly posetd > posted to comp.sources.unix usenet group. > comp.sources.unix - volume16 ... fep/ Front end editor program fep/part01 v16i061: Front end editor program, Part01/05 fep/part02 v16i062: Front end editor program, Part02/05 fep/part03 v16i063: Front end editor program, Part03/05 fep/part04 v16i064: Front end editor program, Part04/05 fep/part05 v16i065: Front end editor program, Part05/05 http://sources.vsta.org/comp.sources.unix/volume16/fep/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From otto at drijf.net Wed Feb 23 01:53:06 2022 From: otto at drijf.net (Otto Moerbeek) Date: Tue, 22 Feb 2022 16:53:06 +0100 Subject: [TUHS] Lorinda Cherry In-Reply-To: <20220222103948.1B0482206F@orac.inputplus.co.uk> References: <202202160754.21G7sbUa011318@freefriends.org> <1nKFRN-4IZ-00@marmaro.de> <8735kig8vb.fsf@vuxu.org> <4E3028A1-EC08-424A-B814-CC2AEEEAEC7B@iitbombay.org> <20220222103948.1B0482206F@orac.inputplus.co.uk> Message-ID: On Tue, Feb 22, 2022 at 10:39:48AM +0000, Ralph Corderoy wrote: > Hi Otto, > > > MacOS uses the GNU implementation which has a long standing issue with > > deep recursion. It even cannot handle the tail recursive calls used > > here and will run out of its stack. > > When learning dc and seeing it relied on tail calls, the first thing > I did was check it did tail-call elimination, and it did. That was > GNU dc. > > Trying just now, I see no growth in memory usage despite heavy CPU load > shown by TIME increasing. > > $ dc > !ps u `pidof dc` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > ralph 11489 0.0 0.0 2332 1484 pts/1 S+ 10:33 0:00 dc > [lmx]smlmx > ^C > Interrupt! > !ps u `pidof dc` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > ralph 11489 75.5 0.0 2332 1488 pts/1 S+ 10:33 0:46 dc > > The memory used remained at that level during the macro execution too, > watched from outside. > > Do you have more detail on what GNU dc can't handle? dc without > tail-call elimination is a bit crippled. > > -- > Cheers, Ralph. On MacOS: $ dc --version dc (GNU bc 1.06) 1.3 ... $ dc [lmx]smlmx Segmentation fault: 11 $ On debian bullseye: $ dc --version dc (GNU bc 1.07.1) 1.4.1 ... $ dc [lmx]smlmx ... all ok. So the basic tail recursion case seems to be fixed in recent versions. But note that [laxp]sa 1 lax still segfaults on both GNU dc versions while on OpenBSD, using the dc I wrote: dc: recursion too deep: Cannot allocate memory This is not a tail recursion case, but segfaulting is not nice at all. -Otto From will.senn at gmail.com Sun Feb 27 06:14:47 2022 From: will.senn at gmail.com (Will Senn) Date: Sat, 26 Feb 2022 14:14:47 -0600 Subject: [TUHS] Lions v6 source code pdf Message-ID: <32881093-d19a-9bde-60f7-6baf0732e1b6@gmail.com> All, I got sick of poring over my Peer-to-Peer communications version of Lion's commentary - trying to read it while digging around in v6 was getting annoying. Of course, if you don't already own, rush out and by a copy. It's great stuff. Anyhow, the problem is that it's perfect bound, landscape and it's not searchable. Hunting around the internet, I found pdfs that were searchable, but they were based on v7 being back-engineered to v6 code. So, I located a decent source of electronically readable Lion's source at https://warsus.github.io/lions-/ and off I went. I took the code and did a bit (quite a bit) of tweakage on it to get it formatted in pdf, and created a version in letter format that I find pretty useful. It can be read from a printout while messing around in v6. I've done some proofing, but I don't claim it's perfect. If you find any issues with it, let me know and I'll try to fix them (thanks, Clem for early suggestions). Here's what's in the letter sized pdf: Tweaked Cover Page Improved Table of Contents Lion's version of V6 Source Code Appendices     Source File Sheets Alphabetical List     Source File Locations in Running V6 System What isn't in the pdf: Original Forewords, Prefaces, or Letters (not needed for coding) Symbol Lists, Cross references, or Indexes (beyond my skills at the moment) All in all, I have found it quite readable and useful for my own work. I don't claim any ownership or contribution, other than in improving the readability of the work for modern readers. If the cross reference thing kills you, just use gnu ctags on the source directories and ctags -x for the line numbers. Here's the link to the posting: http://decuser.blogspot.com/2022/02/tweaked-version-of-lions-v6-source-code.html - will -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sun Feb 27 06:39:57 2022 From: will.senn at gmail.com (Will Senn) Date: Sat, 26 Feb 2022 14:39:57 -0600 Subject: [TUHS] run commands at login in v6 and stty Message-ID: Login commands question: I'm sure it's simple, but I can't figure it out. How do I get something to run at login in v6? Right now, I use ed to create a file 'setprof' that contains: stty erase[space][backspace][return] stty nl0 cr0 Then after logging in: sh setprof It works, but, it is pretty clunky. stty question: So, I looked at stty.c and it looks like the following should work, if the terminal is sending ^H for backspace: #define BS0     0 #define BS1     0100000 modes[] ...         "bs0",         BS0, BS1,         "bs1",         BS1, BS1, but: stty bs0 or stty bs1 don't result in proper backspace handling.. but: stty[space][^h][return] works... Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at kjorling.se Sun Feb 27 07:03:09 2022 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sat, 26 Feb 2022 21:03:09 +0000 Subject: [TUHS] run commands at login in v6 and stty In-Reply-To: References: Message-ID: On 26 Feb 2022 14:39 -0600, from will.senn at gmail.com (Will Senn): > I'm sure it's simple, but I can't figure it out. How do I get something to > run at login in v6? >From a very quick perusal of https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s2/sh.c it doesn't look like you can, at least not in the way we're used to today of having the shell execute a magic file (such as ~/.bashrc) during startup. I also don't see anything in https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/etc/passwd that suggests that the shell can be specified on a per-user basis the way we're used to being able to do today, so the hack of making that point to a program that does some initial setup and then launches the shell proper also might not be readily available. On the other hand, https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh/main.c looks like it includes such support; see the section surrounding the pathopen(nullstr, profile) call toward the bottom of main(). (Beware: it's written in Bourne C.) I won't say "you can't do it in V6", because I don't know things anywhere near well enough to say that, but it doesn't look entirely trivial at least, and it seems to have been added in V7's sh. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From tuhs at cuzuco.com Sun Feb 27 07:45:45 2022 From: tuhs at cuzuco.com (Brian Walden) Date: Sat, 26 Feb 2022 16:45:45 -0500 (EST) Subject: [TUHS] run commands at login in v6 and stty Message-ID: <202202262145.21QLjjR0024198@cuzuco.com> 6th Edition used the Thompson shell as /bin/sh. I don't think it had those capabilities. Sometimes you could find an early version of the Bourne shell in /bin/nsh (new shell) in v6. The 7th Edition made the Bourne shell /bin/sh. And there sometimes you could find the Thompson shell in /bin/osh (old shell). Will Senn wrote: > Login commands question: > > I'm sure it's simple, but I can't figure it out. How do I get something > to run at login in v6? Right now, I use ed to create a file 'setprof' > that contains: > > stty erase[space][backspace][return] > stty nl0 cr0 > > Then after logging in: > > sh setprof > > It works, but, it is pretty clunky. > > stty question: > > So, I looked at stty.c and it looks like the following should work, if > the terminal is sending ^H for backspace: > > #define BS0 0 > #define BS1 0100000 > > modes[] > ... > "bs0", > BS0, BS1, > > "bs1", > BS1, BS1, > > > but: > > stty bs0 > or > stty bs1 > > don't result in proper backspace handling.. > > but: > > stty[space][^h][return] > > > works... > > Thoughts? From robpike at gmail.com Sun Feb 27 08:16:01 2022 From: robpike at gmail.com (Rob Pike) Date: Sun, 27 Feb 2022 09:16:01 +1100 Subject: [TUHS] run commands at login in v6 and stty In-Reply-To: <202202262145.21QLjjR0024198@cuzuco.com> References: <202202262145.21QLjjR0024198@cuzuco.com> Message-ID: Terminal input, shells and so on were all rudimentary by modern standards in v6. By v7 things had become more familiar to 21st century folks. But for v6, although it was an advancement on many systems extant at the time (although not all), the clunky nature of this generated a vast flurry of hackery around terminal drivers and shells. It's a messy history. For the record, our v5/v6 lab in Toronto had mostly paper terminals, despite being a graphics lab, and one of them, the DECWriter, didn't even have lower case. Be thankful for your current setup. One example of the limitations: in v6 you could not pipe into a shell script because the shell used the script itself as standard input. And the argument list was limited to 512 bytes.* But hey, in v1 there weren't even multipart path names. -rob * My first day at Google using Linux in 2002, I got "arg list too long" with a modest glob pattern, and thought, what, have we forgotten about dynamic memory allocation? Moving to a Unix system after a decade plus on Plan 9 was a shock. On Sun, Feb 27, 2022 at 8:48 AM Brian Walden wrote: > 6th Edition used the Thompson shell as /bin/sh. I don't think it had > those capabilities. Sometimes you could find an early version of the > Bourne shell in /bin/nsh (new shell) in v6. > > The 7th Edition made the Bourne shell /bin/sh. And there sometimes > you could find the Thompson shell in /bin/osh (old shell). > > Will Senn wrote: > > Login commands question: > > > > I'm sure it's simple, but I can't figure it out. How do I get something > > to run at login in v6? Right now, I use ed to create a file 'setprof' > > that contains: > > > > stty erase[space][backspace][return] > > stty nl0 cr0 > > > > Then after logging in: > > > > sh setprof > > > > It works, but, it is pretty clunky. > > > > stty question: > > > > So, I looked at stty.c and it looks like the following should work, if > > the terminal is sending ^H for backspace: > > > > #define BS0 0 > > #define BS1 0100000 > > > > modes[] > > ... > > "bs0", > > BS0, BS1, > > > > "bs1", > > BS1, BS1, > > > > > > but: > > > > stty bs0 > > or > > stty bs1 > > > > don't result in proper backspace handling.. > > > > but: > > > > stty[space][^h][return] > > > > > > works... > > > > Thoughts? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Feb 27 08:49:07 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 26 Feb 2022 17:49:07 -0500 Subject: [TUHS] run commands at login in v6 and stty In-Reply-To: References: Message-ID: Some thoughts .. 1.) the precursor to the csh is the newshell in {1}BSD. It's Joy's hack to the Thompson shell and you might find it more usable. 2.) PWB 1.0 is based on a V6 kernel and has the Mashey Shell, which is in C and predates Bourne's It might also be easier for you to use. 3.) srb wrote his shell during the transition between V6, TS and V7. At least one version ran on the V6++ system we had at CMU, but of course as pointed out, it is written in Bourne-Gol. And I'm pretty sure his CPP definitions will need at least a gen2 /lib/cpp implementation*** However, Steve was also doing it at the time when the compiler was being updated. FWIW: We also had the 'Typesetter C' running on our V6 system in those days. So my >>guess<< is that v6 + Typesetter C - will compile the V7 shell. Clem *** Rob or Steve Johnson - maybe remembers when cpp first appeared. I don't remember if it was part of V5 or not - those bits have faded from my brain. What I do remember is there were a couple of different cpp's early on. The first one was pretty crude by today's standards, albeit it was a cool idea and it was the one thing I really liked about C over BLISS early on [BLISS had Macros, which was cool aalso, but cpp could do things Bliss could not]. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sun Feb 27 09:12:39 2022 From: robpike at gmail.com (Rob Pike) Date: Sun, 27 Feb 2022 10:12:39 +1100 Subject: [TUHS] run commands at login in v6 and stty In-Reply-To: References: Message-ID: Cpp was definitely in v6, and I'm pretty sure it was in earlier editions. The first pass of the C compiler would invoke it if the first byte of the source file was a '#'. However, the early version only did #define and #include. It was rewritten for v7, I believe, introducing the catastrophe of #ifdef, while the existential horror of #if was later still, foisted on us by someone not in Research. -rob On Sun, Feb 27, 2022 at 9:53 AM Clem Cole wrote: > > Some thoughts .. > > 1.) the precursor to the csh is the newshell in {1}BSD. It's Joy's hack > to the Thompson shell and you might find it more usable. > 2.) PWB 1.0 is based on a V6 kernel and has the Mashey Shell, which is in > C and predates Bourne's It might also be easier for you to use. > 3.) srb wrote his shell during the transition between V6, TS and V7. At > least one version ran on the V6++ system we had at CMU, but of course as > pointed out, it is written in Bourne-Gol. And I'm pretty sure his CPP > definitions will need at least a gen2 /lib/cpp implementation*** However, > Steve was also doing it at the time when the compiler was being updated. > FWIW: We also had the 'Typesetter C' running on our V6 system in those > days. So my >>guess<< is that v6 + Typesetter C - will compile the V7 > shell. > > Clem > > > > *** Rob or Steve Johnson - maybe remembers when cpp first appeared. I > don't remember if it was part of V5 or not - those bits have faded from my > brain. What I do remember is there were a couple of different cpp's early > on. The first one was pretty crude by today's standards, albeit it was a > cool idea and it was the one thing I really liked about C over BLISS early > on [BLISS had Macros, which was cool aalso, but cpp could do things Bliss > could not]. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sun Feb 27 10:29:48 2022 From: will.senn at gmail.com (Will Senn) Date: Sat, 26 Feb 2022 18:29:48 -0600 Subject: [TUHS] CSR in V6 Message-ID: <3911910b-c205-25ce-a758-1f67a624028e@gmail.com> I noticed in v6 source that putch in prf.c - the system kernel printf's character routine, only prints to the console if the Console Switch Register is non-zero. My question is  - how did y'all run things - with CSR zero and no kernel messages (seems dangerous to me, being naive and all) or with CSR non-zero and kernel messages. On my FreeBSD instance, I value the messages that show up on console as they've alerted me to big problems in the past, but on my Mac, not as much (sure you can run Console and see them, but they aren't immediate). Oh, BTW, I know I've seen this noted elsewhere, but I can't remember where. Dennis's v6 doesn't have the Western Electric message: mem = 435 RESTRICTED RIGHTS Use, duplication or disclosure is subject to restrictions stated in Contract with Western Electric Company, Inc. It was a bit of a head scratcher as I was trying to read from the Dennis version of the distro on my mac while running Wellsch's tape on simh. I spent quite a while spinning my wheels looking for "Western" in the files to no avail. I thought something was screwy with the files or my mac. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Feb 27 10:46:49 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 26 Feb 2022 19:46:49 -0500 Subject: [TUHS] run commands at login in v6 and stty In-Reply-To: References: Message-ID: Yes. Thanks. I do remember it in 6 and the hack in cc to run it or not(it took years for me to break the habit of starting a C program with a #) but what I don’t remember was it in v5 - which we only ran briefly (I personally never saw V4 either although I know Columbia and I believe Harvard had it) Clem On Sat, Feb 26, 2022 at 6:12 PM Rob Pike wrote: > Cpp was definitely in v6, and I'm pretty sure it was in earlier editions. > The first pass of the C compiler would invoke it if the first byte of the > source file was a '#'. However, the early version only did #define and > #include. It was rewritten for v7, I believe, introducing the catastrophe > of #ifdef, while the existential horror of #if was later still, foisted on > us by someone not in Research. > > -rob > > > On Sun, Feb 27, 2022 at 9:53 AM Clem Cole wrote: > >> >> Some thoughts .. >> >> 1.) the precursor to the csh is the newshell in {1}BSD. It's Joy's hack >> to the Thompson shell and you might find it more usable. >> 2.) PWB 1.0 is based on a V6 kernel and has the Mashey Shell, which is in >> C and predates Bourne's It might also be easier for you to use. >> 3.) srb wrote his shell during the transition between V6, TS and V7. At >> least one version ran on the V6++ system we had at CMU, but of course as >> pointed out, it is written in Bourne-Gol. And I'm pretty sure his CPP >> definitions will need at least a gen2 /lib/cpp implementation*** However, >> Steve was also doing it at the time when the compiler was being updated. >> FWIW: We also had the 'Typesetter C' running on our V6 system in those >> days. So my >>guess<< is that v6 + Typesetter C - will compile the V7 >> shell. >> >> Clem >> >> >> >> *** Rob or Steve Johnson - maybe remembers when cpp first appeared. I >> don't remember if it was part of V5 or not - those bits have faded from my >> brain. What I do remember is there were a couple of different cpp's early >> on. The first one was pretty crude by today's standards, albeit it was a >> cool idea and it was the one thing I really liked about C over BLISS early >> on [BLISS had Macros, which was cool aalso, but cpp could do things Bliss >> could not]. >> > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sun Feb 27 17:38:12 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 27 Feb 2022 02:38:12 -0500 (EST) Subject: [TUHS] CSR in V6 Message-ID: <20220227073812.C63E318C083@mercury.lcs.mit.edu> > From: Will Senn > My question is - how did y'all run things - with CSR zero and no kernel > messages ... or with CSR non-zero and kernel messages. On the -11/45 V6+ at MIT, we didn't have a printing terminal on the console, just a VT52. We had a tool at MIT called 'dmesg': http://ana-3.lcs.mit.edu/~jnc/tech/unix/man8/dmesg.8 which made up for that a bit. We normally ran with the CSR set to 173030 - the 'boot in single-user' setting. That's because at one point the machine was in the 9th floor machine room, but the console VT52 was on the 5th floor (where our offices were - the famous print of the GE-645 Multics was on the hallway wall outside mine :-), and I'd added a 'reboot()' system call (nothing fancy, it just jumped to the bootstrap ROM), so we could reboot the machine without going up in the elevator (not if it had crashed, of course). Later on, after we'd done with kernel hacking (adding a network interface, and IP), and the machine stayed up for long periods, we moved the console up next to the machine (since if it crashed, you had to use the front panel to restart it, so you had to be up there anyway); we stayed with the default CSR setting, though. (If it panic'd, you could see the reason why when you went to reboot it.) > Oh, BTW, I know I've seen this noted elsewhere, but I can't remember > where. Maybe at: https://gunkies.org/wiki/UNIX_Sixth_Edition#Distros which discusses it? Noel From jnc at mercury.lcs.mit.edu Sun Feb 27 17:48:36 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 27 Feb 2022 02:48:36 -0500 (EST) Subject: [TUHS] run commands at login in v6 and stty Message-ID: <20220227074836.AE7C018C083@mercury.lcs.mit.edu> > From: Clem Cole > what I don't remember was it in v5 Your memory is going! :-) We discussed this recently (well, recently in _our_ timescale :-); it's built into in 'cc' in V5: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/cc.c see "expand(file)". Noel From lm at mcvoy.com Mon Feb 28 01:01:55 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 27 Feb 2022 07:01:55 -0800 Subject: [TUHS] run commands at login in v6 and stty In-Reply-To: References: Message-ID: <20220227150155.GG21168@mcvoy.com> On Sun, Feb 27, 2022 at 10:12:39AM +1100, Rob Pike wrote: > Cpp was definitely in v6, and I'm pretty sure it was in earlier editions. > The first pass of the C compiler would invoke it if the first byte of the > source file was a '#'. However, the early version only did #define and > #include. It was rewritten for v7, I believe, introducing the catastrophe > of #ifdef, while the existential horror of #if was later still, foisted on > us by someone not in Research. > > -rob As someone who has lived through a lot of #if / #ifdef et al, I've got mixed feelings. SGI definitely abused it, Dave Cutler was asked to make NT work on MIPS and was given the IRIX kernel source as a guide. That source was riddled with #ifdef WAR where "WAR" stood for "work around" (I might have the details wrong but definitely have the idea correct). All of those work arounds were kernel code that had to be different because various MIPS chips had bugs. Cutler's response was "Send me the kernel code when you have MIPS chips that actually work". He was disgusted and I don't blame him. On the other hand, I grew up in the era that X11 was sort of new, all the vendors had their own windowing system (Sunview comes to mind), and while they all had something to be said for them (the Sunview API was really nice), they all were different. So people like me carried around an X11 source tree and built it on whatever platform I happened to be running on today (I was a contractor early on, worked on lots of different boxes). The X11 tree was a heavily ifdef-ed. And it needed to be, I don't have an answer as to how you would reuse all that code on different hardware in a better way. Yep, ugly, but having N copies of the same code, all almost the same but a little different, yeah, that's a formula for having bugs fixed in one of those copies but not the others. So while I understand (I think) Rob's distaste for #ifdef, I've been very grateful for it when I needed it. I ran ctwm on X11 for decades and everything "just worked" on Suns, SGIs, PowerPC, PARISC, etc. --lm From clemc at ccc.com Mon Feb 28 03:10:09 2022 From: clemc at ccc.com (Clem Cole) Date: Sun, 27 Feb 2022 12:10:09 -0500 Subject: [TUHS] run commands at login in v6 and stty In-Reply-To: <20220227150155.GG21168@mcvoy.com> References: <20220227150155.GG21168@mcvoy.com> Message-ID: On Sun, Feb 27, 2022 at 10:01 AM Larry McVoy wrote: > So while I understand (I think) Rob's distaste for #ifdef, I've been very > grateful for it when I needed it. > Yep - like symlinks -- useful feature when appropriately used in specific moderation where they really do help. But both are like giving whiskey to teenagers, so don't be surprised when the result is catastrophic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mascheck at in-ulm.de Mon Feb 28 06:32:24 2022 From: mascheck at in-ulm.de (Sven Mascheck) Date: Sun, 27 Feb 2022 21:32:24 +0100 Subject: [TUHS] run commands at login in v6 and stty In-Reply-To: <202202262145.21QLjjR0024198@cuzuco.com> References: <202202262145.21QLjjR0024198@cuzuco.com> Message-ID: <4b57b17c-c23f-9c43-c734-7faa8298d9db@in-ulm.de> On 26.02.2022 22:45, Brian Walden wrote: > [...] Sometimes you could find an early version of the > Bourne shell in /bin/nsh (new shell) in v6. The 7th edition release of the Bourne shell contains a char version[] = "\nVERSION sys137 DATE 1978 Nov 6 14:29:22\n" in msg.c which was unfortunately not used, remained unchanged in descendants, and got removed with SVR2. I often wondered about the versions bevore "sys137". I thought they were just lost. So Brian's remark got my attention. I haven't found anything in the 6th ed variants I found in TUHS UNIX Archive. Does anybody know how to find a Bourne shell before 7th ed? Thanks and Cheers Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Mon Feb 28 11:04:55 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sun, 27 Feb 2022 20:04:55 -0500 Subject: [TUHS] run commands at login in v6 and stty Message-ID: > The X11 tree was a heavily ifdef-ed. And it needed to be, I don't have > an answer as to how you would reuse all that code on different hardware > in a better way. Plan 9 did it with #include. The name of the included file was the same for every architecture. Only the search path for include files changed. Done with care, this eliminates the typical upfront #ifdefs.that define constants and set flags. Other preprocessor conditionals can usually be replaced by a regular if, letting the compiler optimize away the unwanted alternative. This makes conditionals obey the scope rules of C. Doug From will.senn at gmail.com Mon Feb 28 15:48:04 2022 From: will.senn at gmail.com (Will Senn) Date: Sun, 27 Feb 2022 23:48:04 -0600 Subject: [TUHS] Memory on Lion's v6 Message-ID: <4e3c05d2-2496-b917-f1f4-1c6cba9ef58a@gmail.com> Does anybody know how much memory was configured on the PDP-11 that Lion's used for the commentary system. Here's what the book says about the system: ; from lions, page 1 ; The code selection presumes a "model" system consisting of: ; PDP11/40 processor; ; RK05 disk drives; ; LP11 line printer; ; PC11 paper tape reader/punch; ; KL11 terminal interface. I usually add the mag tape, too ; TM10 magnetic tape - not in lions, but super handy It seems like he must have had an MMU and 128k memory, but I don't know. I'm hoping y'all remember, know, or can otherwise divine the correct value. I've run with no MMU - crash on boot. I've also run with less memory, but then cc won't build mkconf, when I have the TM10 enabled kernel loaded. As a reminder, his book was published in 1977. Thanks, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Mon Feb 28 16:09:02 2022 From: imp at bsdimp.com (Warner Losh) Date: Sun, 27 Feb 2022 23:09:02 -0700 Subject: [TUHS] Memory on Lion's v6 In-Reply-To: <4e3c05d2-2496-b917-f1f4-1c6cba9ef58a@gmail.com> References: <4e3c05d2-2496-b917-f1f4-1c6cba9ef58a@gmail.com> Message-ID: On Sun, Feb 27, 2022, 10:51 PM Will Senn wrote: > Does anybody know how much memory was configured on the PDP-11 that Lion's > used for the commentary system. Here's what the book says about the system: > > ; from lions, page 1 > ; The code selection presumes a "model" system consisting of: > ; PDP11/40 processor; > ; RK05 disk drives; > ; LP11 line printer; > ; PC11 paper tape reader/punch; > ; KL11 terminal interface. > > I usually add the mag tape, too > ; TM10 magnetic tape - not in lions, but super handy > > It seems like he must have had an MMU and 128k memory, but I don't know. > I'm hoping y'all remember, know, or can otherwise divine the correct value. > I've run with no MMU - crash on boot. I've also run with less memory, but > then cc won't build mkconf, when I have the TM10 enabled kernel loaded. As > a reminder, his book was published in 1977. > V6 required the PDP-11 MMU. There are all kinds of code that writes directly to the memory mapping registers. So Lions had to have had an MMU. I'd imagine he had at least 128k of RAM, but likely not much more since the budgets for these machines at the time in Australia was notoriously tight. Warner Thanks, > > Will > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Mon Feb 28 17:22:28 2022 From: robpike at gmail.com (Rob Pike) Date: Mon, 28 Feb 2022 18:22:28 +1100 Subject: [TUHS] run commands at login in v6 and stty In-Reply-To: References: Message-ID: Plan 9 had the distinct advantage of a constant system interface at the source level. X11 did not, but it also made essentially no attempt to abstract it away, so the lines starting #ifdef often outnumbered the actual code. I couldn't make hide nor hair of it, and had no way to reliably test any change. C with #ifdefs is not portable, it is a collection of 2^n overlaid programs, where n is the number of distinct #if[n]def tags. It's too bad the problems of that approach were not appreciated by the C standard committee, who mandated the #ifndef guard approach that I'm sure could count as a provable billion dollar mistake, probably much more. The cost of building #ifdef'ed code, especially with C++, which decided to be more fine-grained about it, is unfathomable. Google alone might well count for many millions of dollars in wasted compilation equipment. I remember giving a Plan 9 demo to someone soon after I got to Google. None of the features of the system were of interest. The thing that astounded my audience was the ability to build the kernel on a P90 in 20 seconds or so, and the window system in under 3. At that time, a build of a Google server would require hours on a large distcc cluster. I still shudder to think of it. It's worse now, of course, far worse, but Google has far larger clusters to handle it and some improvement in tooling. However, the #ifdefs persist. Tom Cargill warned Bjarne about this around 1984, but the plea fell on deaf ears. -rob On Mon, Feb 28, 2022 at 12:07 PM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > > The X11 tree was a heavily ifdef-ed. And it needed to be, I don't have > > an answer as to how you would reuse all that code on different hardware > > in a better way. > > Plan 9 did it with #include. The name of the included file was the same for > every architecture. Only the search path for include files changed. Done > with > care, this eliminates the typical upfront #ifdefs.that define constants > and set > flags. > > Other preprocessor conditionals can usually be replaced by a regular if, > letting > the compiler optimize away the unwanted alternative. This makes > conditionals > obey the scope rules of C. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: