From moody at posixcafe.org Tue Oct 1 01:00:31 2024 From: moody at posixcafe.org (Jacob Moody) Date: Mon, 30 Sep 2024 10:00:31 -0500 Subject: [TUHS] On computerese In-Reply-To: References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <1256d60f-5a1b-de93-6633-642b572aab35@horsfall.org> <20240916232457.GS29162@mcvoy.com> <202409170554.48H5sduP148200@freefriends.org> <202409300816.48U8GuKj303510@freefriends.org> Message-ID: <980281fd-8377-4780-bddc-cb0cd2ed6ff0@posixcafe.org> On 9/30/24 07:10, Russ Cox wrote: > On Mon, Sep 30, 2024 at 4:17 AM > wrote: > > > One of the tidyings I did during covid lockdown was to rewrite > > rc's parser not to use yacc anymore [1], specifically to make > > it easy to allow "foo x=y". As I wrote in the commit message, > > dd fans rejoice! (Also fans of -foo=bar flag syntax.) > > Very cool. Have other Plan 9 distros picked this up? Just wondering. > > > I looked at https://9p.io/plan9/ and also 9front and neither has the change. > I don't think either is particularly maintained at this point. Since (and including) 2020, 9front has averaged 700 commits a year to the project, a very large portion of that being bug fixes and upkeep. We've also been presenting some of the more interesting new work at recent IWP9 conferences, now that they've become a yearly occurrence again thanks to the Plan 9 Foundation. From my perspective things have been quite lively lately. We did take a look at your rc parser changes (closer to when they were first pushed to plan9port) but had decided not to adopt them at the time. Thank you, Jacob Moody From paul.winalski at gmail.com Tue Oct 1 01:49:28 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 30 Sep 2024 11:49:28 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240928180559.GF9067@mcvoy.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180559.GF9067@mcvoy.com> Message-ID: [moving to COFF as this has drifted away from Unix] On Sat, Sep 28, 2024 at 2:06 PM Larry McVoy wrote: > I have a somewhat different view. I have a son who is learning to program > and he asked me about C. I said "C is like driving a sports car on a > twisty mountain road that has cliffs and no guard rails. If you want to > check your phone while you are driving, it's not for you. It requires > your full, focussed attention. So that sounds bad, right? Well, if > you are someone who enjoys driving a sports car, and are good at it, > perhaps C is for you." > > If you really want a language with no guard rails, try programming in BLISS. Regarding C and C++ having dangerous language features--of course they do. Every higher-level language I've ever seen has its set of toxic language features that should be avoided if you want reliability and maintainability for your programs. And a set of things to avoid if you want portability. Regarding managed dynamic memory allocation schemes that use garbage collection vs. malloc()/free(), there are some applications where they are not suitable. I'm thinking about real-time programs. You can't have your missle defense software pause to do garbage collection when you're trying to shoot down an incoming ballistic missile. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Tue Oct 1 02:05:52 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 30 Sep 2024 12:05:52 -0400 Subject: [TUHS] On computerese In-Reply-To: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: On Sat, Sep 28, 2024 at 8:49 PM Aron Insinga wrote: > For the counter-example, I wonder if anyone ever tried to type very much > (verbose) DCL on VAX/VMS using a Teletype. :-) > > I had occasion to use an ASR model 33 Teletype with VAX/VMS. Hated it. The DECwriter LA36 was acceptable, though. While DCL commands generally involved complete words, they could be abbreviated to the smallest unique abbreviation. Thus one mostly typed DIR instead of DIRECTORY. Command keywords also were be required to be unique in the first 4 characters--the DCL parser ignored all but the first four. characters. The engineers at DEC's Marlboro MA facility named one of their networked machines TWINKIE so that to log into it they could type SET HOSTESS TWINKIE. The terse Unix command verb style can be a steep learning curve for beginners. How is one supposed to know that you say 'ls' to get a directory listing? And unfortunately man pages aren't very useful for beginners because you have to know what the command verb is in order to call up its man page. Unix lacks a place to ask questions such as "how do I get a directory listing?". -Paul W. -Paul W. > > On 9/15/24 16:43, sjenkin at canb.auug.org.au wrote: > > ... > For non touch typists, shorter commands & keywords are helpful. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Oct 1 04:07:17 2024 From: crossd at gmail.com (Dan Cross) Date: Mon, 30 Sep 2024 14:07:17 -0400 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: On Mon, Sep 30, 2024 at 1:22 PM Paul Winalski wrote: > On Sat, Sep 28, 2024 at 8:49 PM Aron Insinga wrote: >> For the counter-example, I wonder if anyone ever tried to type very much (verbose) DCL on VAX/VMS using a Teletype. :-) >> > I had occasion to use an ASR model 33 Teletype with VAX/VMS. Hated it. The DECwriter LA36 was acceptable, though. > > While DCL commands generally involved complete words, they could be abbreviated to the smallest unique abbreviation. Thus one mostly typed DIR instead of DIRECTORY. Command keywords also were be required to be unique in the first 4 characters--the DCL parser ignored all but the first four. characters. The engineers at DEC's Marlboro MA facility named one of their networked machines TWINKIE so that to log into it they could type SET HOSTESS TWINKIE. > > The terse Unix command verb style can be a steep learning curve for beginners. How is one supposed to know that you say 'ls' to get a directory listing? And unfortunately man pages aren't very useful for beginners because you have to know what the command verb is in order to call up its man page. Unix lacks a place to ask questions such as "how do I get a directory listing?". This makes me wonder when the `apropos` command was introduced; surely the name was also somewhat of an obscure joke ("what is apropos of listing a directory?" is not exactly the phrase that springs immediately to mind when wondering how to list a directory). But the other form of it, `man -k`, is reasonable. Plan 9 called the similar thing, `lookman`. - Dan C. From steffen at sdaoden.eu Tue Oct 1 05:12:16 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 30 Sep 2024 21:12:16 +0200 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: Message-ID: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Rob Pike wrote in : |On Mon, Sep 30, 2024 at 2:56 AM Douglas McIlroy < |douglas.mcilroy at dartmouth.edu> wrote: |>>>> malloc(0) isn't undefined behaviour but implementation defined. |>>> |>>> In modern C there is no difference between those two concepts. |> |>> Can you explain more about your view |> |> There certainly is a difference, but in this case the practical |> implications are the same: avoid malloc(0). malloc(0) lies at the \ |> high end |> of a range of severity of concerns about implementation-definedness. \ |> At the |> low end are things like the size of ints, which only affects applications |> that may confront very large numbers. In the middle is the default |> signedness of chars, which generally may be mitigated by explicit type |> declarations. |> |> For the size of ints, C offers guardrails like INT_MAX. There is no test |> to discern what an error return from malloc(0) means. |> |> Is there any other C construct that implementation-definedness renders |> useless? |Gradually the writers of optimizing compilers have leaned so hard on the |implementation-defined and undefined behaviors that, while far from |useless, C and C++ have become non-portable and dangerously insecure, as |well as often very surprising to the point that the US government arguing |against using them. Never attribute to malice what can adequately be explained by incompetence. is the signature of Poul-Henning Kamp (whose email regarding that cstr list (i did not yet have TM-74-1273-1 aka the C Reference Manual as of 1974-01-15, thank you!) was forwarded by Warren). Only propaganda left everywhere, including here, namely for Rust. But your statement in particular reminds me of "Who's afraid of a big bad optimizing compiler?" of LWN.net, from July 15, 2019. It may be fun to read by some. (Offline, searching surely works.) It ends with Acknowledgments We owe thanks to a surprisingly large number of compiler writers and members of the C and C++ standards committees who introduced us to some of the things a big bad optimizing compiler can do,[.] But i think those eh people there (that US government) surely have been hammered with "memory-safe language" a thousand times, and noone ever told them that even the eldest C can be used in a safe way; on freebsd-hackers (PHK is an early FreeBSD committer) there was one of their bikeshed threads around September 5th, after several CVEs where fixed, and another long time major contributor started a thread saying things like |>|The real takeaway here is that C is no longer sufficient for writing |>|high quality code in the 2020s. Everyone needs to adapt their tools. which (also) i (not FreeBSD, only by heart, maybe) spoke against. He was hailing Option>> or Vec::with_capacity(262144) as solutions to the CVEs. (Which, as far as i looked, had nothing really to do with C as such; one "guilty" programmer said, as far as i understood that, the same for "his CVE".) Vectors and string "objects" with (optionally) checked index access and such are uncomfortable, but easy to do, also with C, and right from the start (i said). (P.S.: i miss bit enumerations in C and C++, as compilers get stricter and stricter (you cannot even enum1|enum2 without warnings no more, in i think C23; without cast, of course), but bit flags "can" only come in via preprocessor constants, and are completely unchecked. And enum1|enum2 *i* often have, if some subtype adds flags on top of a basic type, isn't that natural, no support on that front. And cast-less "super class casts". I had not downloaded cstr#108-the_c++_programming_language yet.) --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 henry.r.bent at gmail.com Tue Oct 1 05:15:27 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 30 Sep 2024 15:15:27 -0400 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: On Mon, 30 Sept 2024 at 14:08, Dan Cross wrote: > > This makes me wonder when the `apropos` command was introduced; surely > the name was also somewhat of an obscure joke ("what is apropos of > listing a directory?" is not exactly the phrase that springs > immediately to mind when wondering how to list a directory). > Looks like it was introduced in 2BSD, written by Bill Joy, though the 4.4BSD manpage claims that it was introduced in 3BSD. Neither the BSD source nor manpage are particularly enlightening about the choice of name. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From halbert at halwitz.org Tue Oct 1 06:00:55 2024 From: halbert at halwitz.org (Dan Halbert) Date: Mon, 30 Sep 2024 16:00:55 -0400 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: On 9/30/24 15:15, Henry Bent wrote: > On Mon, 30 Sept 2024 at 14:08, Dan Cross wrote: > > > This makes me wonder when the `apropos` command was introduced; surely > the name was also somewhat of an obscure joke ("what is apropos of > listing a directory?" is not exactly the phrase that springs > immediately to mind when wondering how to list a directory). > > > Looks like it was introduced in 2BSD, written by Bill Joy, though the > 4.4BSD manpage claims that it was introduced in 3BSD.  Neither the BSD > source nor manpage are particularly enlightening about the choice of name. I was one of the Berkeley grad students in the office with Bill Joy around this time. I think the name probably  come from the "apropos" command in Emacs. That command is mentioned here: https://worrydream.com/refs/Stallman_1979_-_EMACS,_The_Extensible,_Customizable,_Self-Documenting_Display_Editor.pdf, which is dated June 1979, but the Emacs command existed before that date. The Berkeley source code is dated 1979: https://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/src/apropos.c I had used Emacs at MIT as an undergraduate. Bill would sometimes ask me, "how do they do that in Emacs", or ITS, and then riff on a feature and put it into vi or whatever. Whether I suggested an "apropos" Unix command or someone wanted something like that, or I said, "sounds like 'apropos' in Emacs", I don't remember. Dan H -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Tue Oct 1 06:03:15 2024 From: rich.salz at gmail.com (Rich Salz) Date: Mon, 30 Sep 2024 16:03:15 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240930191216.tIpea9lo@steffen%sdaoden.eu> References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: On Mon, Sep 30, 2024 at 3:12 PM Steffen Nurpmeso wrote > noone ever told them that even the eldest C can be used in a safe > way; Perhaps we have different meanings of the word safe. void foo(char *p) { /* interesting stuff here */ ; free(p); } void bar() { char *p = malloc(20); foo(p); printf("foo is %s\n", p); foo(p); } Why should I have to think about this code when the language already knows what is wrong. -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Tue Oct 1 06:11:27 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 30 Sep 2024 16:11:27 -0400 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: On Mon, 30 Sept 2024 at 16:01, Dan Halbert wrote: > On 9/30/24 15:15, Henry Bent wrote: > > On Mon, 30 Sept 2024 at 14:08, Dan Cross wrote: > >> >> This makes me wonder when the `apropos` command was introduced; surely >> the name was also somewhat of an obscure joke ("what is apropos of >> listing a directory?" is not exactly the phrase that springs >> immediately to mind when wondering how to list a directory). >> > > Looks like it was introduced in 2BSD, written by Bill Joy, though the > 4.4BSD manpage claims that it was introduced in 3BSD. Neither the BSD > source nor manpage are particularly enlightening about the choice of name. > > > I was one of the Berkeley grad students in the office with Bill Joy around > this time. I think the name probably come from the "apropos" command in > Emacs. That command is mentioned here: > https://worrydream.com/refs/Stallman_1979_-_EMACS,_The_Extensible,_Customizable,_Self-Documenting_Display_Editor.pdf, > which is dated June 1979, but the Emacs command existed before that date. > The Berkeley source code is dated 1979: > https://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/src/apropos.c > > I had used Emacs at MIT as an undergraduate. Bill would sometimes ask me, > "how do they do that in Emacs", or ITS, and then riff on a feature and put > it into vi or whatever. Whether I suggested an "apropos" Unix command or > someone wanted something like that, or I said, "sounds like 'apropos' in > Emacs", I don't remember. > That definitely tracks with an outlier I turned up in my search of sources, an "apropos.doc" that appears on the CSRG DVD with the sources for CMU Emacs. It's just a list of mappings from commands to keybindings, for example: ... delete-next-character ^D delete-next-word ESC-D delete-other-windows ^X1 delete-previous-character ^H delete-previous-character RUBOUT ... I'm not particularly an Emacs person, but it looks like it could be the output from an "apropos" command, or perhaps the input to it. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From rik at rikfarrow.com Tue Oct 1 06:14:48 2024 From: rik at rikfarrow.com (Rik Farrow) Date: Mon, 30 Sep 2024 13:14:48 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240930191216.tIpea9lo@steffen%sdaoden.eu> References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: This is the 'problem' with C/C++: it's not the language itself so much as the people who are allowed, or forced, to use it. Many, if not all, of the people on this list have worked with great programmers, when most programmers are average at best. I saw some terrible things back when doing technical sales support for a startup selling a graphics library with C bindings. I came away convinced that most of the 'programmers' I was training were truly clueless. Rik On Mon, Sep 30, 2024 at 12:12 PM Steffen Nurpmeso > Never attribute to malice what can adequately be explained by > incompetence. > > is the signature of Poul-Henning Kamp (whose email regarding that > cstr list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Oct 1 06:39:07 2024 From: clemc at ccc.com (Clem Cole) Date: Mon, 30 Sep 2024 16:39:07 -0400 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: On Mon, Sep 30, 2024 at 4:01 PM Dan Halbert wrote: > I was one of the Berkeley grad students in the office with Bill Joy around > this time. > IIRC Dark curly hair, and I can not think of his name either. I bet if I saw a picture, I could identify him. apropos(1) was a great hack, but I always thought whoever came up with locate(1) really hit the jackpot. ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Tue Oct 1 06:51:00 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 30 Sep 2024 22:51:00 +0200 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: <20240930205100.iOO2gbzi@steffen%sdaoden.eu> Henry Bent wrote in : |On Mon, 30 Sept 2024 at 14:08, Dan Cross wrote: |> This makes me wonder when the `apropos` command was introduced; surely |> the name was also somewhat of an obscure joke ("what is apropos of |> listing a directory?" is not exactly the phrase that springs |> immediately to mind when wondering how to list a directory). |> | |Looks like it was introduced in 2BSD, written by Bill Joy, though the |4.4BSD manpage claims that it was introduced in 3BSD. Neither the BSD |source nor manpage are particularly enlightening about the choice of name. "a pro position" maybe. (Having said that #?0|kent:linux$ apropos 'directory list' CURLOPT_DIRLISTONLY (3) - ask for names only in a directory listing vs #?0|kent:linux$ apropos 'list directory' dir (1) - list directory contents ls (1) - list directory contents ls (1p) - list directory contents vdir (1) - list directory contents vs #?0|kent:linux$ apropos -a list directory chacl (1) - change the access control list of a file or directory CURLOPT_DIRLISTONLY (3) - ask for names only in a directory listing dir (1) - list directory contents ls (1) - list directory contents ls (1p) - list directory contents vdir (1) - list directory contents vs #?0|kent:linux$ apropos -a directory list ..same.. needs a "pro user" from the start; AI would instead and additionally clean your back i would assume. --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 Tue Oct 1 07:15:39 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 30 Sep 2024 23:15:39 +0200 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: <20240930211539.94nSvOdZ@steffen%sdaoden.eu> Rich Salz wrote in : |On Mon, Sep 30, 2024 at 3:12 PM Steffen Nurpmeso wrote |> noone ever told them that even the eldest C can be used in a safe |> way; | |Perhaps we have different meanings of the word safe. | | void foo(char *p) { /* interesting stuff here */ ; free(p); } | void bar() { char *p = malloc(20); | foo(p); | printf("foo is %s\n", p); | foo(p); |} |Why should I have to think about this code when the language already knows |what is wrong. It can also be used in an unsafe way? O-ha. Sounds dangerous in my ears (given human behaviour in particular). I was so focused on winning against Putin, .. that i did realize this context. (Btw i like The Cures new song "Alone", after 14 years!, and its accompanying thrilling mega mega boom boom boom video.) P.S.: In the real world i would now, as the conservative and integer (up against the floating-point!) person that i am point "you" to C++, and simply pass a string object. But let us pass a reference so we gain compile-time non-NIL "meat" (vegan!!), and impressive state-of-the-art speed characteristics. Human behaviour can destroy everything: faster so with C++! --End of Btw i hate these random message-ids, they reveal nothing! Like in all those rooms i never visit. I am all for the wonderful Klaus von Dohnanyi, now also 96 years old, and his saying "Ach bitte, sagen Sie nicht Chatroom, sagen Sie Plauderstübchen" ("Oh please, do not say chatroom, just say [little talk chamber][ʃtyːpçən]" [1] (needs scripting-enabled browser). [1] https://translate.google.com/?sl=auto&tl=en&text=Plauderst%C3%BCbchen&op=translate --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 henry.r.bent at gmail.com Tue Oct 1 07:25:09 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 30 Sep 2024 17:25:09 -0400 Subject: [TUHS] On computerese In-Reply-To: <20240930205100.iOO2gbzi@steffen%sdaoden.eu> References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> <20240930205100.iOO2gbzi@steffen%sdaoden.eu> Message-ID: On Mon, 30 Sept 2024 at 16:51, Steffen Nurpmeso wrote: > Henry Bent wrote in > : > |On Mon, 30 Sept 2024 at 14:08, Dan Cross wrote: > |> This makes me wonder when the `apropos` command was introduced; surely > |> the name was also somewhat of an obscure joke ("what is apropos of > |> listing a directory?" is not exactly the phrase that springs > |> immediately to mind when wondering how to list a directory). > |> > | > |Looks like it was introduced in 2BSD, written by Bill Joy, though the > |4.4BSD manpage claims that it was introduced in 3BSD. Neither the BSD > |source nor manpage are particularly enlightening about the choice of > name. > > "a pro position" maybe. > > needs a "pro user" from the start; AI would instead and > additionally clean your back i would assume. > Well, I no longer have institutional access to the full Oxford English Dictionary, but Merriam Webster is happy to provide an extended paragraph (!) on the etymology: -- *Apropos* wears its ancestry like a badge—or a beret. From the French phrase *à propos*, meaning “to the purpose,” the word’s emphasis lands on its last syllable, which ends in a silent “s”: \ap-ruh-POH. *Apropos* typically functions as an adjective describing what is suitable or appropriate (“an apropos comment”), or as a preposition (with or without *of*) meaning “with regard to,” as in “apropos (of) the decision, implementation will take some time.” The phrase “apropos of nothing” suggests that something does not relate to a specified topic. -- -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Tue Oct 1 08:00:35 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 01 Oct 2024 00:00:35 +0200 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: <20240930220035.3nZHrUot@steffen%sdaoden.eu> Rik Farrow wrote in : |On Mon, Sep 30, 2024 at 12:12 PM Steffen Nurpmeso  | || Never attribute to malice what can adequately be explained by || incompetence. | ||is the signature of Poul-Henning Kamp (whose email regarding that ||cstr list |This is the 'problem' with C/C++: it's not the language itself so much as |the people who are allowed, or forced, to use it. Many, if not all, of the |people on this list have worked with great programmers, when most |programmers are average at best. I saw some terrible things back when doing |technical sales support for a startup selling a graphics library with C |bindings. I came away convinced that most of the 'programmers' I was |training were truly clueless. I cannot comment on that, humans "get a good job with more pay you are ok", have interests here and there, have (unfulfilled) desires, problems with family or partner, aka "that sex machine", and so in the end one can be lucky if that was not Jeffrey Dahmer or something, and you do not end up as canned. "Or forced", yes! Here on this lists are (me aside) intellectual but especially witty people who love(d) their (likely) even-more-than-a-job, at the "top of the pyramid", Mr. McIlroy just again remembered an impressive scenario of how these people were (and are) self-driving up that spiral staircase with nothing but the help of their mind and a free library .. which was available for them. Other than that, you know, there are plenty of languages with plenty of support (syntax checks, sanitizers, "debug stuff"), far beyond vim(1), let that start with JAVA (documented pretty well right from the start as far as i know), and all the other options that arose since then, and in parts are used. I personally "go on the gums" if i have to work with OpenSSL, and image processing is no fun either, so it could be it was me who drove you down... (And complexity is never easy, i think, to noone.) --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 tuhs at tuhs.org Tue Oct 1 08:14:38 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Mon, 30 Sep 2024 15:14:38 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: On Sep 30, 2024, at 1:03 PM, Rich Salz wrote: > > > On Mon, Sep 30, 2024 at 3:12 PM Steffen Nurpmeso wrote > noone ever told them that even the eldest C can be used in a safe > way; > Perhaps we have different meanings of the word safe. > > void foo(char *p) { /* interesting stuff here */ ; free(p); } > void bar() { char *p = malloc(20); > foo(p); > printf("foo is %s\n", p); > foo(p); > } > Why should I have to think about this code when the language already knows what is wrong. The language doesn't know! The compiler can't know without the programmer indicating this somehow, especially if foo() is an extern function. I am still interested in making C safer (to secure as best as possible all the zillions of lines of C code in OS kernels). The question is, can we retrofit safety features into C without doing major violence to it & turning it into an ugly mess? No idea if this is even feasible but seems worth exploring with possibly a great ROI. Take the above code as an example. It is "free()" that invalidates the value of its argument on return and this property is then inherited by its callers. One idea is to declare free as follows: void free(`zap void*ptr); // `zap is says *ptr will be invalid on return Now a compiler can see and complain that foo() will break this and insist that foo() too must express the same thing. So we change it to void foo(`zap char* p) { ... free(p); } Now the compiler knows p can't dereferenced after calling foo() and can complain on seeing p being printf'ed. This was just an example of an idea -- remains to be seen if it amounts to anything useful. In an earlier email I had explored bounds checking. Clearly all such extensions would have to play well together as well as with the existing language. My hope is that the language can be evolved in this way and gradually kernel code can be fixed up to benefit from it. Bakul From steffen at sdaoden.eu Tue Oct 1 08:38:00 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 01 Oct 2024 00:38:00 +0200 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> <20240930205100.iOO2gbzi@steffen%sdaoden.eu> Message-ID: <20240930223800.Z9vdkp7Q@steffen%sdaoden.eu> Henry Bent wrote in : |On Mon, 30 Sept 2024 at 16:51, Steffen Nurpmeso wrote: |> Henry Bent wrote in |> : |>|On Mon, 30 Sept 2024 at 14:08, Dan Cross wrote: |>|> This makes me wonder when the `apropos` command was introduced; surely |>|> the name was also somewhat of an obscure joke ("what is apropos of |>|> listing a directory?" is not exactly the phrase that springs |>|> immediately to mind when wondering how to list a directory). |>| |>|Looks like it was introduced in 2BSD, written by Bill Joy, though the |>|4.4BSD manpage claims that it was introduced in 3BSD. Neither the BSD |>|source nor manpage are particularly enlightening about the choice of |> name. |> |> "a pro position" maybe. |> |> needs a "pro user" from the start; AI would instead and |> additionally clean your back i would assume. | |Well, I no longer have institutional access to the full Oxford English |Dictionary, but Merriam Webster is happy to provide an extended paragraph |(!) on the etymology: Oh! Apropos is known in Germany as a (*that*) word, too, also commonly heard, even in the (upper) middle class, but sounding like "apro-poh" here. Ef "Apropos -- have i already" etc etc. I was "only leaving of the e of that creat", so to say. (I am not looking at the online "Duden" because they now require Javascript and tracking, if i recall correctly.) |-- |*Apropos* wears its ancestry like a badge—or a beret. From the French |phrase *à propos*, meaning “to the purpose,” the word’s emphasis lands on |its last syllable, which ends in a silent “s”: \ap-ruh-POH. *Apropos* |typically functions as an adjective describing what is suitable or |appropriate (“an apropos comment”), or as a preposition (with or without |*of*) meaning “with regard to,” as in “apropos (of) the decision, |implementation will take some time.” The phrase “apropos of nothing” |suggests that something does not relate to a specified topic. |-- | |-Henry --End of --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 tuhs at tuhs.org Tue Oct 1 08:46:44 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Mon, 30 Sep 2024 15:46:44 -0700 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> <20240930205100.iOO2gbzi@steffen%sdaoden.eu> Message-ID: Apropos of apropos: https://www.etymonline.com/search?q=apropos etymonline.com is my goto etymological dictionary site. > On Sep 30, 2024, at 2:25 PM, Henry Bent wrote: > > On Mon, 30 Sept 2024 at 16:51, Steffen Nurpmeso > wrote: >> Henry Bent wrote in >> >: >> |On Mon, 30 Sept 2024 at 14:08, Dan Cross > wrote: >> |> This makes me wonder when the `apropos` command was introduced; surely >> |> the name was also somewhat of an obscure joke ("what is apropos of >> |> listing a directory?" is not exactly the phrase that springs >> |> immediately to mind when wondering how to list a directory). >> |> >> | >> |Looks like it was introduced in 2BSD, written by Bill Joy, though the >> |4.4BSD manpage claims that it was introduced in 3BSD. Neither the BSD >> |source nor manpage are particularly enlightening about the choice of name. >> >> "a pro position" maybe. >> >> needs a "pro user" from the start; AI would instead and >> additionally clean your back i would assume. > > Well, I no longer have institutional access to the full Oxford English Dictionary, but Merriam Webster is happy to provide an extended paragraph (!) on the etymology: > > -- > Apropos wears its ancestry like a badge—or a beret. From the French phrase à propos, meaning “to the purpose,” the word’s emphasis lands on its last syllable, which ends in a silent “s”: \ap-ruh-POH. Apropos typically functions as an adjective describing what is suitable or appropriate (“an apropos comment”), or as a preposition (with or without of) meaning “with regard to,” as in “apropos (of) the decision, implementation will take some time.” The phrase “apropos of nothing” suggests that something does not relate to a specified topic. > -- > > -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at ultimate.com Tue Oct 1 09:25:28 2024 From: phil at ultimate.com (Phil Budne) Date: Mon, 30 Sep 2024 19:25:28 -0400 Subject: [TUHS] Origins of "Unix Philosophy" Message-ID: <202409302325.48UNPSfs020034@ultimate.com> I'm wondering if there are places where people who were in the Unix Room wrote about the origins and evolution of what people (at least used to(*)) refer to as "Unix Philosophy", and since some are in THIS (TUHS) room, what they might have to say about it. How much was in reaction to the complexity of Multics, and how much was simply a response to the limited address spaces of available and affordable hardware? Eric S. Raymond wrote in "The Art of Unix Programming" quoting Doug McIlroy and Rob Pike: http://www.catb.org/esr/writings/taoup/html/ch01s06.html And I wonder if they care to comment on it? I have trouble taking ESR as authoritative, as, it seems to me that Research Unix was more a product of the "Cathedral" (or at least a contained community) than the "Bazaar" (at least the modern bazaar, where everyone needs to leave a new feature grafito on the town walls), and ESR A side question for Rob Pike, is the "Not only is UNIX dead, it's starting to smell really bad." quote accurate? Was it in reaction to BSD, GNU, or all of the above? (*) I say "used to", because, for the most part, minimalism seems to have left the building. I can't look at modern GNU utilities, and many, if not most open source packages and think they've gone WAY past classic Unix minimalism, especially since I remember hearing that Bell Research had happily stripped excess features (removal of "cat -s" sticks in my mind) from later day research Unix, and because Stallman is said to have coined the term "New Jersey" style as a synonym for what Richard P. Gabriel called "Worse is Better", which seems, an attack on minimalism (nothing less than "the right thing" is acceptable) Worse is.... readings: https://dreamsongs.com/WorseIsBetter.html https://dreamsongs.com/RiseOfWorseIsBetter.html https://dreamsongs.com/Files/IsWorseReallyBetter.pdf https://dreamsongs.com/Files/worse-is-worse.pdf Anti-flamage disclainmers: Inclusion of links above does not imply any agreement on my part! My apologies in advance for any offense, misquote, or misunderstanding on my part. From flexibeast at gmail.com Tue Oct 1 11:42:00 2024 From: flexibeast at gmail.com (Alexis) Date: Tue, 01 Oct 2024 11:42:00 +1000 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: (Bakul Shah via TUHS's message of "Mon, 30 Sep 2024 15:14:38 -0700") References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: <87setgzjiv.fsf@gmail.com> Bakul Shah via TUHS writes: > I am still interested in making C safer (to secure as best as > possible > all the zillions of lines of C code in OS kernels). The question > is, > can we retrofit safety features into C without doing major > violence to > it & turning it into an ugly mess? No idea if this is even > feasible > but seems worth exploring with possibly a great ROI. Related: Ten years ago, Pascal Cuoq, Matthew Flatt, and John Regehr proposed "Friendly C": > We are not trying to fix the deficiencies of the C language nor > making > an argument for or against C. Rather, we are trying rescue the > predictable little language that we all know is hiding within > the C > standard. This language generates tight code and doesn’t make > you feel > like the compiler is your enemy. We want to decrease the rate of > bit > rot in existing C code and also to reduce the auditing overhead > for > safety-critical and security-critical C code. The intended > audience > for -std=friendly-c is people writing low-level systems such as > operating systems, embedded systems, and programming language > runtimes. These people typically have a good guess about what > instructions the compiler will emit for each line of C code they > write, and they simply do not want the compiler silently > throwing out > code. If they need code to be faster, they’ll change how it is > written. -- https://blog.regehr.org/archives/1180 Some of the concrete features proposed included: > 1. The value of a pointer to an object whose lifetime has ended > remains the same as it was when the object was alive. > > 2. Signed integer overflow results in two’s complement wrapping > behavior at the bitwidth of the promoted type. > > 3. Shift by negative or shift-past-bitwidth produces an > unspecified > result. i seem to recall there have been other proposals in the vein of "Friendly C", but they're not coming to mind right now. Alexis. From lars at nocrew.org Tue Oct 1 14:31:12 2024 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 01 Oct 2024 04:31:12 +0000 Subject: [TUHS] On computerese In-Reply-To: (Dan Halbert's message of "Mon, 30 Sep 2024 16:00:55 -0400") References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: <7w7caswijz.fsf@junk.nocrew.org> Dan Halbert wrote: > I had used Emacs at MIT as an undergraduate. Bill would sometimes ask > me, "how do they do that in Emacs", or ITS, and then riff on a feature > and put it into vi or whatever. Whether I suggested an "apropos" Unix > command or someone wanted something like that, or I said, "sounds like > 'apropos' in Emacs", I don't remember. I'm curious if you remember any other features that Bill might have picked up from Emacs or ITS? From you or anyone else. Another interesting example would be job control that was done by Jim Kulp. From lars at nocrew.org Tue Oct 1 14:44:47 2024 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 01 Oct 2024 04:44:47 +0000 Subject: [TUHS] Origins of "Unix Philosophy" In-Reply-To: <202409302325.48UNPSfs020034@ultimate.com> (Phil Budne's message of "Mon, 30 Sep 2024 19:25:28 -0400") References: <202409302325.48UNPSfs020034@ultimate.com> Message-ID: <7w34lgwhxc.fsf@junk.nocrew.org> Phil Budne wrote: > Stallman is said to have coined the term "New Jersey" style as a > synonym for what Richard P. Gabriel called "Worse is Better" Do you have a source for this? Gabriel does write "New Jersey Style" in his essay. Of course, he could have got it from Stallman anyway. From arnold at skeeve.com Tue Oct 1 22:43:20 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 06:43:20 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930003630.GE17434@mcvoy.com> Message-ID: <202410011243.491ChKiV419651@freefriends.org> Luther Johnson wrote: > 'Go' is also a pretty C-like advanced C kind of thing. What do Go > writers think of it vs. C, for safety, reliability, clarity of > expression, etc. ? I have what to say about the topics in this thread, but I wanted to answer this. I've been working in Go for about two years in my current $DAYJOB. I haven't done as much of it as I'd like. As preface, I've been programming (heavily) in C since 1983 and quite a fair amount in C++ since 1999 or so, with Python in the mix more recently. Overall, I like Go. The freedom from manual memory management takes some getting used to, but is very liberating once you do. I do find it too terse in some cases, mostly in the initialization syntax, and in the use of nested function objects. I also find Go modules to be totally opaque, I don't understand them at all. One thing I'm still getting used to is the scoping with := vs. =. Here's a nasty bug that I just figured out this week. Consider: var ( clientSet *kubernetes.Interface ) func main() { .... // set the global var (we think) clientSet, err := cluster.MakeClient() // or whatever .... } func otherfunc() { // use the global var (but not really) l := clientSet.CoreV1().NetworkPolicyList(ns).Items } In main(), I *think* I'm assigning to the global clientSet so that I can use it later. But because of the 'err' and the :=, I've actually created a local variable that shadows the global one, and in otherfunc(), the global clientSet is still nil. Kaboom! The correct way to write the code is: var err error clientSet, err = cluster.MakeClient() // or whatever "When the light went on, it was blinding." Of course, the Goland IDE actually warns me that this is the case, by changing the color of clientSet in the assignment, but it's an extremely subtle warning, and if you don't hover over it, and you're not paying a lot of attention to the coloring, you miss it. So, I like Go, and for a new project that I wouldn't write in Awk or Python, I would use Go. The time or two I've looked at Rust, it seemed to be just too difficult to learn, as well as still evolving too fast. It does look like Rust will eventually replace C and C++ for new systems level code. We can hope that will be a good thing. My two cents, Arnold From crossd at gmail.com Tue Oct 1 22:53:46 2024 From: crossd at gmail.com (Dan Cross) Date: Tue, 1 Oct 2024 08:53:46 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: On Mon, Sep 30, 2024 at 4:22 PM Rik Farrow wrote: > This is the 'problem' with C/C++: it's not the language itself so much as the people who are allowed, or forced, to use it. Programmer ability is certainly an issue, but I would suggest that another goes back to what Rob was alluding to: compiler writers have taken too much advantage of UB, making it difficult to write well-formed programs that last. The `realloc` function I mentioned earlier is a good case in point; the first ANSI C standard says this: "If ptr is a null pointer, the realloc function behaves like the malloc function for the specified size. ... If size is zero and ptr is not a null pointer, the object it points to is freed." While the description of `malloc` doesn't say thing about what happens when `size` is 0, perhaps making `realloc(0, NULL)` nominally UB (??), the behavior of `realloc(0, ptr)` is clearly well defined when `ptr` is not nil, and it's entirely possible that programs were written with that well-defined behavior as an assumption. (Worth mentioning is that this language was changed in C99, and implementations started differing from there.) But now, C23 has made `realloc(0, ptr)` UB, regardless of the value of `ptr`, and since compiler writers have given themselves license to take an extremely broad view of what they can do if a program exhibits UB, programs that were previously well-defined with respect to C90 may well stop working properly when compiled with modern compilers. I don't think this is a hypothetical; C programs that appear to be working as expected for years have, and will continue, to suddenly break when compiled with a newer compiler, because the programmer tripped a UB trigger somewhere along the way, likely without even recognizing it. Moreover, I don't believe that there are any non-trivial C programs out there that don't have such timebombs lurking throughout. How could they not, if things that were previously well-defined can become UB in subsequent revisions of the standard? Perhaps I've mentioned it before, but a great example of the surprising nature of UB is the following program: unsigned short mul(unsigned short a, unsigned short b) { return a * b; } Is this tiny function always well-defined? Sadly, no, at least not on most common platforms where `int` is 32 bits and `short` is 16. On such platforms, the "usual arithmetic conversions" will kick in before the multiplication, and the values will be converted to _signed_ ints and _then_ multiplied; the product will then be converted back to `unsigned short`. And while the type conversion process both ways is well-defined, there exist values a,b of type unsigned short so that a*b will overflow a signed 32-bit int (consider 0xffff*0xffff), and signed integer overflow is UB; a compiler would be well within its rights to assume that such overflow can never occur and generate, say, a saturating multiplication instruction if it so chose. This would work, be perfectly legal, and almost certainly be surprising to the programmer. The fix is simple, of course: unsigned short mul(unsigned short a, unsigned short b) { unsigned int aa = a, bb = b; return aa * bb; } But one would have to know to write such a thing in the first place. > Many, if not all, of the people on this list have worked with great programmers, when most programmers are average at best. I saw some terrible things back when doing technical sales support for a startup selling a graphics library with C bindings. I came away convinced that most of the 'programmers' I was training were truly clueless. My sense is that tossing in bad programmers is just throwing gasoline onto a dumpster fire. Particularly when they look to charlatans like Robert Martin or Allen Holub as sources of education and inspiration instead of seeking out proper sources of education. - Dan C. From arnold at skeeve.com Tue Oct 1 23:13:04 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 07:13:04 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240928180138.aygrwqdwrvq3n6xt@illithid> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> Message-ID: <202410011313.491DD4ac421643@freefriends.org> This is long, my apologies. "G. Branden Robinson" wrote: > [ screed omitted ] Branden, as they say, Hindsight is 20-20. But one needs to take into account that Unix and C evolved, and in particular on VERY small machines. IIRC the original Unix PDP-11s didn't even have split I/D spaces. Getting a decent compiler into that small an address space isn't easy (and by now is a lost art). The evolution was gradual and, shall we say "organic", without the pretension and formalisms of a language committee, but simply to meet the needs of the Bell Labs researchers. The value of a high level language for OS work was clear from Multics. But writing a PL/1 compiler from scratch for the tiny PDP-11 address space made no sense. Thus the path from BCPL to B to C. Today, new languages are often reactions to older ones. Java, besides the JVM portability, tried to clean up the syntax of C / C++ and add some safety and modernism (graphics, concurrency). C# was a reaction to (and a way to compete with) Java. Go was very clearly in reaction to current C++, but headed back in the direction of simplicity. Successfully, IMHO. Would the word have been better off if Ada had caught on everywhere? Probably. When I was in grad school studying language design, circa 1982, it was expected to do so. But the language was VERY challenging for compiler writers. C was easy to port, and then Unix along with it. C'est la vie. Larry wrote: > I have a somewhat different view. I have a son who is learning to program > and he asked me about C. I said "C is like driving a sports car on a > twisty mountain road that has cliffs and no guard rails. If you want to > check your phone while you are driving, it's not for you. It requires > your full, focussed attention. So that sounds bad, right? Well, if > you are someone who enjoys driving a sports car, and are good at it, > perhaps C is for you." This goes back to the evolution thing. At the time, C was a huge step up from FORTRAN and assembly. Programmers who moved to C appreciated all it gave them over what they had at the time. C programmers weren't wizards, they were simply using the best available tool. Going from a bicycle to an automobile is a big jump (to continue Larry's analogy). Larry again: > I ran a company that developed a product that was orders of magnitude more > complex than the v7 kernel (low bar but still) all in C and we had *NONE* > of those supposed problems. We were careful to use stuff that worked, > I'm "famous" in that company as the guy was viewed as "that was invented > after 1980 so Larry won't let us use it". Not true, we used mmap and used > POSIX signals, but mostly true. If you stick to the basics, C just works. > And is portable, we supported every Unix (even SCO), MacOS, Windows, and > all the Linux variants from ARM to IBM mainframes. This is also my experience with gawk, which runs on everything from ARM (Linux) to Windows to mac to VMS to z/OS (S/390x). OS issues give me more grief than language issues. > All that said, I get it, you want guard rails. You are not wrong, the > caliber of programmers these days are nowhere near Bell Labs or Sun or > my guys. This is a very important, key point. As more and more people have entered the field, the quality / education / knowledge / whatever has gone down. What was normal to learn and use back in 1983 is now too difficult for many, if not most, people, even good ones, in the field now. The people I work with here (Israel) don't know who Donald Knuth is. Two of the people in my group, over 40, didn't know what Emacs is. Shell scripting seems to be too hard for many people to master, and I see a huge amount of Cargo Cult Programming when it comes to things like scripts and Unix tools. Thus Go and Rust are good things, taking the sharp tools out of the hands of the people who aren't qualified to use them. Same thing Python. But for me, and I think others of my vintage, this state of affairs seems sad. My 4 cents, Arnold From lm at mcvoy.com Tue Oct 1 23:32:31 2024 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 1 Oct 2024 06:32:31 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410011313.491DD4ac421643@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> Message-ID: <20241001133231.GE13777@mcvoy.com> On Tue, Oct 01, 2024 at 07:13:04AM -0600, arnold at skeeve.com wrote: > Would the word have been better off if Ada had caught on everywhere? > Probably. When I was in grad school studying language design, circa 1982, > it was expected to do so. But the language was VERY challenging for > compiler writers. Huh. Rob Netzer and I, as grad students, took cs701 and cs702 at UW Madison. It was the compilers course (701) and the really hard compilers course (702) at the time. The first course was to write a compiler for a subset of Ada and the second on increased the subset to be almost complete. We were supposed to do it on an IBM mainframe because the professor had his own version of lex/yacc there. Rob had a 3b1 and asked if we could do it there if he rewrote the parser stuff. Prof said sure. In one semester we had a compiler, no optimizer and not much in the way of graceful error handling, but it compiled stuff that ran. We did all of Ada other than late binding of variables (I think that was Ada's templates) and threads and probably some other stuff I don't remember. Rob is pretty smart, went on to be a tenured prof at Brown before going back to industry. Maybe he did all the heavy lifting, but I didn't find that project to very challenging. Did I miss something? > This is a very important, key point. As more and more people have > entered the field, the quality / education / knowledge / whatever > has gone down. What was normal to learn and use back in 1983 is > now too difficult for many, if not most, people, even good ones, in > the field now. > > But for me, and I think others of my vintage, this state of affairs > seems sad. 100% agree. A sharp young kid I know is/was working on finding bugs in binaries. He came to me for some insight and I had to understand what he was doing and when I did, I kept saying "just hire people that don't do this stupid stuff" and he kept laughing at me and said it was impossible. I don't consider myself to be that good of a programmer, I can point to dozens of people my age that can run circles around me and I'm sure there are many more. But apparently the bar is pretty low these days and I agree, that's sad. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From halbert at halwitz.org Tue Oct 1 23:36:37 2024 From: halbert at halwitz.org (Dan Halbert) Date: Tue, 1 Oct 2024 09:36:37 -0400 Subject: [TUHS] On computerese In-Reply-To: <7w7caswijz.fsf@junk.nocrew.org> References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> <7w7caswijz.fsf@junk.nocrew.org> Message-ID: <96dd889c-5749-48dc-8ea5-8910f51ca966@halwitz.org> On 10/1/24 00:31, Lars Brinkhoff wrote: > Dan Halbert wrote: >> I had used Emacs at MIT as an undergraduate. Bill would sometimes ask >> me, "how do they do that in Emacs", or ITS, and then riff on a feature >> and put it into vi or whatever. Whether I suggested an "apropos" Unix >> command or someone wanted something like that, or I said, "sounds like >> 'apropos' in Emacs", I don't remember. > I'm curious if you remember any other features that Bill might have > picked up from Emacs or ITS? From you or anyone else. > > Another interesting example would be job control that was done by Jim > Kulp. A lot of the vi visual-mode commands were inspired by emacs, like forward/back words, sentences/statements, paragraphs/functions. I specifically remember explaining the hierarchy of  ctrl-f, meta-f, ctrl-meta-f, etc., and then Bill went off and put in '{' and '}' and similar commands. And the "yank" commands were named after ctrl-Y and other "yank" commands in emacs. Those are on the 2BSD tape. Earl Cohen did the "finger" command quite soon after our class of first year grad students arrived at UCB. It's in 2BSD. I did "more" really early (https://danhalbert.org/more.html), but my very simple version did not get back into the sources, and the reworked "more" that Eric Shienbrood did is in 3BSD but not 2BSD. Dan From arnold at skeeve.com Tue Oct 1 23:47:10 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 07:47:10 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20241001133231.GE13777@mcvoy.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> Message-ID: <202410011347.491DlAsJ423777@freefriends.org> Larry McVoy wrote: > On Tue, Oct 01, 2024 at 07:13:04AM -0600, arnold at skeeve.com wrote: > > Would the word have been better off if Ada had caught on everywhere? > > Probably. When I was in grad school studying language design, circa 1982, > > it was expected to do so. But the language was VERY challenging for > > compiler writers. > > Huh. Rob Netzer and I, as grad students, took cs701 and cs702 at UW Madison. > It was the compilers course (701) and the really hard compilers course (702) > at the time. The first course was to write a compiler for a subset of Ada > and the second on increased the subset to be almost complete. > > We were supposed to do it on an IBM mainframe because the professor had his > own version of lex/yacc there. Rob had a 3b1 and asked if we could do it > there if he rewrote the parser stuff. Prof said sure. > > In one semester we had a compiler, no optimizer and not much in the > way of graceful error handling, but it compiled stuff that ran. We did > all of Ada other than late binding of variables (I think that was Ada's > templates) and threads and probably some other stuff I don't remember. Did you do generics? That and the run time, which had some real-time bits to it (*IIRC*, it's been a long time), as well as the cross object code type checking, would have been real bears. Like many things, the first 90% is easy, the second 90% is hard. :-) > I don't consider myself to be that good of a programmer, I can point to > dozens of people my age that can run circles around me and I'm sure there > are many more. You are undoubtedly better than you give yourself credit for, even if there were people who could run circles around you. I learned a long time ago, that no matter how good you are, there's always someone better than you at something. I decided long ago to not try to compete with Superman. > But apparently the bar is pretty low these days and I agree, that's sad. And it makes it much less fun to be out in the working world. :-( Arnold From lm at mcvoy.com Wed Oct 2 00:01:02 2024 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 1 Oct 2024 07:01:02 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410011347.491DlAsJ423777@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> Message-ID: <20241001140101.GG13777@mcvoy.com> On Tue, Oct 01, 2024 at 07:47:10AM -0600, arnold at skeeve.com wrote: > Larry McVoy wrote: > > > On Tue, Oct 01, 2024 at 07:13:04AM -0600, arnold at skeeve.com wrote: > > > Would the word have been better off if Ada had caught on everywhere? > > > Probably. When I was in grad school studying language design, circa 1982, > > > it was expected to do so. But the language was VERY challenging for > > > compiler writers. > > > > Huh. Rob Netzer and I, as grad students, took cs701 and cs702 at UW Madison. > > It was the compilers course (701) and the really hard compilers course (702) > > at the time. The first course was to write a compiler for a subset of Ada > > and the second on increased the subset to be almost complete. > > > > We were supposed to do it on an IBM mainframe because the professor had his > > own version of lex/yacc there. Rob had a 3b1 and asked if we could do it > > there if he rewrote the parser stuff. Prof said sure. > > > > In one semester we had a compiler, no optimizer and not much in the > > way of graceful error handling, but it compiled stuff that ran. We did > > all of Ada other than late binding of variables (I think that was Ada's > > templates) and threads and probably some other stuff I don't remember. > > Did you do generics? That and the run time, which had some real-time > bits to it (*IIRC*, it's been a long time), as well as the cross > object code type checking, would have been real bears. None of those ring a bell so > Like many things, the first 90% is easy, the second 90% is hard. :-) I guess we did the easy stuff :-( > > I don't consider myself to be that good of a programmer, I can point to > > dozens of people my age that can run circles around me and I'm sure there > > are many more. > > You are undoubtedly better than you give yourself credit for, even > if there were people who could run circles around you. I learned > a long time ago, that no matter how good you are, there's always > someone better than you at something. I decided long ago to not > try to compete with Superman. Funny, I've come to the same conclusion, both in programming and my retirement hobby. There is always someone way better than me, but you are correct, that doesn't mean I'm awful. Just have more to learn. A buddy pointed out that I was probably better than 80% of the people leaving the dock, it's just I fish with a guy who is better than pretty much everyone. > > But apparently the bar is pretty low these days and I agree, that's sad. > > And it makes it much less fun to be out in the working world. :-( As a guy in his 2nd retirement (1st didn't stick) I can tell you I am so happy not having to deal with work stuff. My buddies who are still working tell me stories I find difficult to believe. They all say I'm so politically incorrect that I wouldn't last a week in today's world. If their stories are true, yeah, that's not for me. Weird politics and crappy programmers, count me out. From arnold at skeeve.com Wed Oct 2 00:18:34 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 08:18:34 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20241001140101.GG13777@mcvoy.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> Message-ID: <202410011418.491EIYYp426442@freefriends.org> Closing off the thread... > > Did you do generics? That and the run time, which had some real-time > > bits to it (*IIRC*, it's been a long time), as well as the cross > > object code type checking, would have been real bears. > > None of those ring a bell so > > > Like many things, the first 90% is easy, the second 90% is hard. :-) > > I guess we did the easy stuff :-( Even the easy stuff is good learning. > Funny, I've come to the same conclusion, both in programming and my > retirement hobby. There is always someone way better than me, but > you are correct, that doesn't mean I'm awful. Just have more to > learn. Right. > > > But apparently the bar is pretty low these days and I agree, that's sad. > > > > And it makes it much less fun to be out in the working world. :-( > > As a guy in his 2nd retirement (1st didn't stick) I can tell you I am > so happy not having to deal with work stuff. My buddies who are still > working tell me stories I find difficult to believe. They all say I'm > so politically incorrect that I wouldn't last a week in today's world. > If their stories are true, yeah, that's not for me. > > Weird politics and crappy programmers, count me out. I don't have to deal with the politics, and my team is good, but the company has a lot of crappy code. I am planning to retire quite soon, too. :-) Arnold From luther.johnson at makerlisp.com Wed Oct 2 00:25:04 2024 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Tue, 1 Oct 2024 07:25:04 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20241001140101.GG13777@mcvoy.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> Message-ID: <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> I think because the of the orders of magnitude increase in the demand for programmers, we now have a very large number of programmers with little or no math and science (and computer science doesn't count in the point I'm trying to make here, if that's your only science, you're not going to have the models in your head from other disciplines to give you useful analogs) background, and that's a big change from 40 years ago. So that has had an effect on who is programming, how they think about it, and how languages have been marketed to that programming audience. IMHO. On 10/01/2024 07:01 AM, Larry McVoy wrote: > On Tue, Oct 01, 2024 at 07:47:10AM -0600, arnold at skeeve.com wrote: >> Larry McVoy wrote: >> >>> On Tue, Oct 01, 2024 at 07:13:04AM -0600, arnold at skeeve.com wrote: >>>> Would the word have been better off if Ada had caught on everywhere? >>>> Probably. When I was in grad school studying language design, circa 1982, >>>> it was expected to do so. But the language was VERY challenging for >>>> compiler writers. >>> Huh. Rob Netzer and I, as grad students, took cs701 and cs702 at UW Madison. >>> It was the compilers course (701) and the really hard compilers course (702) >>> at the time. The first course was to write a compiler for a subset of Ada >>> and the second on increased the subset to be almost complete. >>> >>> We were supposed to do it on an IBM mainframe because the professor had his >>> own version of lex/yacc there. Rob had a 3b1 and asked if we could do it >>> there if he rewrote the parser stuff. Prof said sure. >>> >>> In one semester we had a compiler, no optimizer and not much in the >>> way of graceful error handling, but it compiled stuff that ran. We did >>> all of Ada other than late binding of variables (I think that was Ada's >>> templates) and threads and probably some other stuff I don't remember. >> Did you do generics? That and the run time, which had some real-time >> bits to it (*IIRC*, it's been a long time), as well as the cross >> object code type checking, would have been real bears. > None of those ring a bell so > >> Like many things, the first 90% is easy, the second 90% is hard. :-) > I guess we did the easy stuff :-( > >>> I don't consider myself to be that good of a programmer, I can point to >>> dozens of people my age that can run circles around me and I'm sure there >>> are many more. >> You are undoubtedly better than you give yourself credit for, even >> if there were people who could run circles around you. I learned >> a long time ago, that no matter how good you are, there's always >> someone better than you at something. I decided long ago to not >> try to compete with Superman. > Funny, I've come to the same conclusion, both in programming and my > retirement hobby. There is always someone way better than me, but > you are correct, that doesn't mean I'm awful. Just have more to > learn. > > A buddy pointed out that I was probably better than 80% of the people > leaving the dock, it's just I fish with a guy who is better than pretty > much everyone. > >>> But apparently the bar is pretty low these days and I agree, that's sad. >> And it makes it much less fun to be out in the working world. :-( > As a guy in his 2nd retirement (1st didn't stick) I can tell you I am > so happy not having to deal with work stuff. My buddies who are still > working tell me stories I find difficult to believe. They all say I'm > so politically incorrect that I wouldn't last a week in today's world. > If their stories are true, yeah, that's not for me. > > Weird politics and crappy programmers, count me out. > From crossd at gmail.com Wed Oct 2 00:56:13 2024 From: crossd at gmail.com (Dan Cross) Date: Tue, 1 Oct 2024 10:56:13 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> Message-ID: On Tue, Oct 1, 2024 at 10:32 AM Luther Johnson wrote: > I think because the of the orders of magnitude increase in the demand > for programmers, we now have a very large number of programmers with > little or no math and science (and computer science doesn't count in the > point I'm trying to make here, if that's your only science, you're not > going to have the models in your head from other disciplines to give you > useful analogs) background, and that's a big change from 40 years ago. > So that has had an effect on who is programming, how they think about > it, and how languages have been marketed to that programming audience. IMHO. I've found a grounding in mathematics useful for programming, but beyond some knowledge of the physical constraints that the universe places on us and a very healthy appreciation for the scientific method, I'm having a hard time understanding how the hard sciences would help out too much. Electrical engineering seems like it would be more useful, than, say, chemistry or geology. I talk to a lot of academics, and I think they see the situation differently than is presented here. In a nutshell, the way a lot of them look at it, the amount of computer science in the world increases constantly while the amount of time they have to teach that to undergraduates remains fixed. As a result, they have to pick and choose what they teach very, very carefully, balancing a number of criteria as they do so. What this translates to in the real world isn't that the bar is lowered, but that the bar is different. - Dan C. From stuff at riddermarkfarm.ca Wed Oct 2 01:08:06 2024 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Tue, 1 Oct 2024 11:08:06 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> Message-ID: [-->COFF] On 2024-10-01 10:56, Dan Cross wrote (in part): > I've found a grounding in mathematics useful for programming, but > beyond some knowledge of the physical constraints that the universe > places on us and a very healthy appreciation for the scientific > method, I'm having a hard time understanding how the hard sciences > would help out too much. Electrical engineering seems like it would be > more useful, than, say, chemistry or geology. I see this as related to the old question about whether it is easier to teach domain experts to program or teach programmers about the domain. (I worked for a company that wrote/sold scientific libraries for embedded systems.) We had a mixture but the former was often easier. S. > > I talk to a lot of academics, and I think they see the situation > differently than is presented here. In a nutshell, the way a lot of > them look at it, the amount of computer science in the world increases > constantly while the amount of time they have to teach that to > undergraduates remains fixed. As a result, they have to pick and > choose what they teach very, very carefully, balancing a number of > criteria as they do so. What this translates to in the real world > isn't that the bar is lowered, but that the bar is different. > > - Dan C. From lm at mcvoy.com Wed Oct 2 01:20:33 2024 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 1 Oct 2024 08:20:33 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> Message-ID: <20241001152033.GH13777@mcvoy.com> On Tue, Oct 01, 2024 at 10:56:13AM -0400, Dan Cross wrote: > On Tue, Oct 1, 2024 at 10:32???AM Luther Johnson > wrote: > > I think because the of the orders of magnitude increase in the demand > > for programmers, we now have a very large number of programmers with > > little or no math and science (and computer science doesn't count in the > > point I'm trying to make here, if that's your only science, you're not > > going to have the models in your head from other disciplines to give you > > useful analogs) background, and that's a big change from 40 years ago. > > So that has had an effect on who is programming, how they think about > > it, and how languages have been marketed to that programming audience. IMHO. > > I've found a grounding in mathematics useful for programming, but > beyond some knowledge of the physical constraints that the universe > places on us and a very healthy appreciation for the scientific > method, I'm having a hard time understanding how the hard sciences > would help out too much. Electrical engineering seems like it would be > more useful, than, say, chemistry or geology. > > I talk to a lot of academics, and I think they see the situation > differently than is presented here. In a nutshell, the way a lot of > them look at it, the amount of computer science in the world increases > constantly while the amount of time they have to teach that to > undergraduates remains fixed. As a result, they have to pick and > choose what they teach very, very carefully, balancing a number of > criteria as they do so. What this translates to in the real world > isn't that the bar is lowered, but that the bar is different. I really wish that they made students take something like the PDP-11 assembly class - it was really systems architecture, you learned the basic idea of a computer: a CPU, a bus to talk to memory, a bus to talk to I/O, how a stack works, ideally how a context switch works though that kinda blows minds (I personally don't think you are a kernel programmer if you haven't implemented swtch() or at least walked the code and understood all of it). I did all that and developed a mental model of all computers that has helped me over the last 4 decades. Yes, my model is overly simplistic but it still works, even on the x86 craziness. I don't know how you could get to that mental model with x86, x86 is too weird. I don't really know which architecture is close to the simplicity of a PDP-11 today. Anyone? If I were teaching it, I'd just get a PDP-11 simulator and teach on that. Maybe. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Wed Oct 2 01:38:04 2024 From: tuhs at tuhs.org (=?utf-8?b?UGV0ZXIgV2VpbmJlcmdlciAo5rip5Y2a5qC8KSB2aWEgVFVIUw==?=) Date: Tue, 1 Oct 2024 11:38:04 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20241001152033.GH13777@mcvoy.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> <20241001152033.GH13777@mcvoy.com> Message-ID: Each generation bemoans the qualities of following generations. (Perhaps justifiably in this case, but we're acting out a stereotyped pattern.) Having a mental model of a computer is a good idea, but I'd rather not have to teach the details of PDP-11 condition codes (which changed in unexpected ways over time) Now caches loom large, and should such a course provide a mental model of smart phones? [I think it should, and the course should cover secure boot, but that leaves lots less time for assembly language.] On Tue, Oct 1, 2024 at 11:20 AM Larry McVoy wrote: > > On Tue, Oct 01, 2024 at 10:56:13AM -0400, Dan Cross wrote: > > On Tue, Oct 1, 2024 at 10:32???AM Luther Johnson > > wrote: > > > I think because the of the orders of magnitude increase in the demand > > > for programmers, we now have a very large number of programmers with > > > little or no math and science (and computer science doesn't count in the > > > point I'm trying to make here, if that's your only science, you're not > > > going to have the models in your head from other disciplines to give you > > > useful analogs) background, and that's a big change from 40 years ago. > > > So that has had an effect on who is programming, how they think about > > > it, and how languages have been marketed to that programming audience. IMHO. > > > > I've found a grounding in mathematics useful for programming, but > > beyond some knowledge of the physical constraints that the universe > > places on us and a very healthy appreciation for the scientific > > method, I'm having a hard time understanding how the hard sciences > > would help out too much. Electrical engineering seems like it would be > > more useful, than, say, chemistry or geology. > > > > I talk to a lot of academics, and I think they see the situation > > differently than is presented here. In a nutshell, the way a lot of > > them look at it, the amount of computer science in the world increases > > constantly while the amount of time they have to teach that to > > undergraduates remains fixed. As a result, they have to pick and > > choose what they teach very, very carefully, balancing a number of > > criteria as they do so. What this translates to in the real world > > isn't that the bar is lowered, but that the bar is different. > > I really wish that they made students take something like the PDP-11 > assembly class - it was really systems architecture, you learned the > basic idea of a computer: a CPU, a bus to talk to memory, a bus to > talk to I/O, how a stack works, ideally how a context switch works > though that kinda blows minds (I personally don't think you are a > kernel programmer if you haven't implemented swtch() or at least > walked the code and understood all of it). > > I did all that and developed a mental model of all computers that > has helped me over the last 4 decades. Yes, my model is overly > simplistic but it still works, even on the x86 craziness. I don't > know how you could get to that mental model with x86, x86 is too > weird. I don't really know which architecture is close to the > simplicity of a PDP-11 today. Anyone? > > If I were teaching it, I'd just get a PDP-11 simulator and teach > on that. Maybe. > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Wed Oct 2 01:44:12 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Tue, 1 Oct 2024 08:44:12 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410011313.491DD4ac421643@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> Message-ID: <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> > Thus Go and Rust are good things, taking the sharp tools out of the > hands of the people who aren't qualified to use them. Same thing Python. Sounds like boomer mentality... Kids these days... :-) Also sounds like the kind of arguments assembly language programmers presented when *we* were the "kids" trying out "structured programming"! From rminnich at gmail.com Wed Oct 2 01:50:58 2024 From: rminnich at gmail.com (ron minnich) Date: Tue, 1 Oct 2024 08:50:58 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> <20241001152033.GH13777@mcvoy.com> Message-ID: by the way, if you are hankering to do bare metal programming again, and you're done with C, tinygo is great, and it works on 200 or so boards, from the bbc micro on up. tinygo gives you all the nice bits from go, and uses llvm as the backend, so programs can be very small. Tamago is also bare metal go, using the standard Go compiler, and has even flown in space. I had thought Rust and C would always be the only path to very low level programming in tiny environments, but it turned out I was too pessimistic. https://docs.google.com/presentation/d/1nqZicux6SloS8AynBu0B7cJYxw5pKu4IfCzq_vqWccw/edit?usp=sharing It's been years now since I used C on bare metal; it's Rust or Go for me. These languages give me all I ever needed for "first instruction after reset" programming. On Tue, Oct 1, 2024 at 8:38 AM Peter Weinberger (温博格) via TUHS < tuhs at tuhs.org> wrote: > Each generation bemoans the qualities of following generations. > (Perhaps justifiably in this case, but we're acting out a stereotyped > pattern.) > > Having a mental model of a computer is a good idea, but I'd rather not > have to teach the details of PDP-11 condition codes (which changed in > unexpected ways over time) Now caches loom large, and should such a > course provide a mental model of smart phones? [I think it should, and > the course should cover secure boot, but that leaves lots less time > for assembly language.] > > On Tue, Oct 1, 2024 at 11:20 AM Larry McVoy wrote: > > > > On Tue, Oct 01, 2024 at 10:56:13AM -0400, Dan Cross wrote: > > > On Tue, Oct 1, 2024 at 10:32???AM Luther Johnson > > > wrote: > > > > I think because the of the orders of magnitude increase in the demand > > > > for programmers, we now have a very large number of programmers with > > > > little or no math and science (and computer science doesn't count in > the > > > > point I'm trying to make here, if that's your only science, you're > not > > > > going to have the models in your head from other disciplines to give > you > > > > useful analogs) background, and that's a big change from 40 years > ago. > > > > So that has had an effect on who is programming, how they think about > > > > it, and how languages have been marketed to that programming > audience. IMHO. > > > > > > I've found a grounding in mathematics useful for programming, but > > > beyond some knowledge of the physical constraints that the universe > > > places on us and a very healthy appreciation for the scientific > > > method, I'm having a hard time understanding how the hard sciences > > > would help out too much. Electrical engineering seems like it would be > > > more useful, than, say, chemistry or geology. > > > > > > I talk to a lot of academics, and I think they see the situation > > > differently than is presented here. In a nutshell, the way a lot of > > > them look at it, the amount of computer science in the world increases > > > constantly while the amount of time they have to teach that to > > > undergraduates remains fixed. As a result, they have to pick and > > > choose what they teach very, very carefully, balancing a number of > > > criteria as they do so. What this translates to in the real world > > > isn't that the bar is lowered, but that the bar is different. > > > > I really wish that they made students take something like the PDP-11 > > assembly class - it was really systems architecture, you learned the > > basic idea of a computer: a CPU, a bus to talk to memory, a bus to > > talk to I/O, how a stack works, ideally how a context switch works > > though that kinda blows minds (I personally don't think you are a > > kernel programmer if you haven't implemented swtch() or at least > > walked the code and understood all of it). > > > > I did all that and developed a mental model of all computers that > > has helped me over the last 4 decades. Yes, my model is overly > > simplistic but it still works, even on the x86 craziness. I don't > > know how you could get to that mental model with x86, x86 is too > > weird. I don't really know which architecture is close to the > > simplicity of a PDP-11 today. Anyone? > > > > If I were teaching it, I'd just get a PDP-11 simulator and teach > > on that. Maybe. > > -- > > --- > > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Wed Oct 2 02:40:32 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 1 Oct 2024 12:40:32 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410011313.491DD4ac421643@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> Message-ID: On Tue, Oct 1, 2024 at 9:13 AM wrote: > This goes back to the evolution thing. At the time, C was a huge > step up from FORTRAN and assembly. > Certainly it's a step up (and a BIG step up) from assembly. But I'd say C is a step sidewise from Fortran. An awful lot of HPTC programming involves throwing multidimensional arrays around and C is not suitable for that. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Wed Oct 2 02:49:10 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 1 Oct 2024 12:49:10 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410011347.491DlAsJ423777@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> Message-ID: On Tue, Oct 1, 2024 at 10:07 AM wrote: [regarding writing an Ada compiler as a class project] > Did you do generics? That and the run time, which had some real-time > bits to it (*IIRC*, it's been a long time), as well as the cross > object code type checking, would have been real bears. > > Like many things, the first 90% is easy, the second 90% is hard. :-) > > I was in DEC's compiler group when they were implementing Ada for VAX/VMS. It gets very tricky when routine libraries are involved. Just figuring out the compilation order can be a real bear (part of this is the cross object code type checking you mention). >From my viewpoint Ada suffered two problems. First, it was such a large language and very tricky to implement--even more so than PL/I. Second, it had US Government cooties. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Oct 2 05:04:36 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 13:04:36 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> Message-ID: <202410011904.491J4aOY448275@freefriends.org> Dan Cross wrote: > I talk to a lot of academics, and I think they see the situation > differently than is presented here. In a nutshell, the way a lot of > them look at it, the amount of computer science in the world increases > constantly while the amount of time they have to teach that to > undergraduates remains fixed. As a result, they have to pick and > choose what they teach very, very carefully, balancing a number of > criteria as they do so. What this translates to in the real world > isn't that the bar is lowered, but that the bar is different. You also have a lot of self-taught programmers, and graduates of bootcamp programs, getting into programming. From arnold at skeeve.com Wed Oct 2 05:07:04 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 13:07:04 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> Message-ID: <202410011907.491J74wT448406@freefriends.org> Bakul Shah via TUHS wrote: > > > Thus Go and Rust are good things, taking the sharp tools out of the > > hands of the people who aren't qualified to use them. Same thing Python. > > Sounds like boomer mentality... Kids these days... :-) Also sounds like > the kind of arguments assembly language programmers presented when *we* > were the "kids" trying out "structured programming"! It's not that they're intrinsically unqualified. They were never taught, so they don't know what they're doing. I'm unqualified to fly a plane because I never learned or practiced, not because I'm not intelligent enough. Same thing for many of today's programmers and C / C++. From tuhs at tuhs.org Wed Oct 2 05:46:50 2024 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Tue, 1 Oct 2024 15:46:50 -0400 Subject: [TUHS] Fwd: Trove of CSTR's In-Reply-To: References: Message-ID: <36800a31-cea8-4b74-a34b-2069d031945e@case.edu> On 9/28/24 7:38 PM, Warren Toomey via TUHS wrote: > ----- Forwarded message from Poul-Henning Kamp ----- > > I stumbled over this: > > https://www.telecomarchive.com/lettermemo.html > > is the TUHS crew aware of that resource ? This is an incredible resource as well: https://www.telecomarchive.com/bstj.html From 1922 to 1996. -- ``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 rik at rikfarrow.com Wed Oct 2 06:34:26 2024 From: rik at rikfarrow.com (Rik Farrow) Date: Tue, 1 Oct 2024 13:34:26 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410011907.491J74wT448406@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> <202410011907.491J74wT448406@freefriends.org> Message-ID: And my comment about seeing code produced by programmers while doing sales support dates from 1990. This isn't something new, from my perspective. I was working in a small programming shop where there were a handful of excellent programmers, and then sent out to help customers get started using their libraries. That's when I experienced seeing things that still make me cringe. Rik On Tue, Oct 1, 2024 at 12:07 PM wrote: > Bakul Shah via TUHS wrote: > > > > > > Thus Go and Rust are good things, taking the sharp tools out of the > > > hands of the people who aren't qualified to use them. Same thing > Python. > > > > Sounds like boomer mentality... Kids these days... :-) Also sounds like > > the kind of arguments assembly language programmers presented when *we* > > were the "kids" trying out "structured programming"! > > It's not that they're intrinsically unqualified. They were never > taught, so they don't know what they're doing. I'm unqualified to > fly a plane because I never learned or practiced, not because I'm not > intelligent enough. Same thing for many of today's programmers > and C / C++. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Wed Oct 2 10:55:58 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 02 Oct 2024 02:55:58 +0200 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> <202410011907.491J74wT448406@freefriends.org> Message-ID: <20241002005558.TiqDHtEk@steffen%sdaoden.eu> Rik Farrow wrote in : |On Tue, Oct 1, 2024 at 12:07 PM wrote: |> Bakul Shah via TUHS wrote: ... |>> Sounds like boomer mentality... Kids these days... :-) Also sounds like |>> the kind of arguments assembly language programmers presented when *we* |>> were the "kids" trying out "structured programming"! |> |> It's not that they're intrinsically unqualified. They were never |> taught, so they don't know what they're doing. I'm unqualified to |> fly a plane because I never learned or practiced, not because I'm not |> intelligent enough. Same thing for many of today's programmers |> and C / C++. |And my comment about seeing code produced by programmers while doing sales |support dates from 1990. This isn't something new, from my perspective. I |was working in a small programming shop where there were a handful of |excellent programmers, and then sent out to help customers get started |using their libraries. That's when I experienced seeing things that still |make me cringe. Btw the "official Linux firmware" https://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git;a=summary introduced a dependency for the "rdfind" utility i think ~two years ago (it was later made optional) for this code: $verbose "Finding duplicate files" rdfind -makesymlinks true -makeresultsfile false "$destdir" >/dev/null find "$destdir" -type l | while read -r l; do target="$(realpath "$l")" $verbose "Correcting path for $l" ln -fs "$(realpath --relative-to="$(dirname "$(realpath -s "$l")")" "$target")" "$l" done I proposed (because it really drove me mad, i have nothing to do with Linux kernel stuff etc shall you think that) ( cd "$destdir" && find . -type f | xargs cksum | sort | { ls= lf= while read s1 s2 f; do s="$s1 $s2" #$verbose $s $f if [ "$s" = "$ls" ] && cmp "$lf" "$f"; then $verbose 'duplicate '"${lf##*/}" "${f#./*}" rm -f "$f" #ln -s "${lf#./*}" "${f#./*}" ln -s "${lf##*/}" "${f#./*}" else ls=$s lf=$f fi done } ) (as a draft, with only light testing, but it is not far from doing it at maximum) which only uses POSIX default tools etc, but these guys from very big companies (RedHat; the guy who did *that* is from AMD) did not even respond, at least to that. (At times i tried to get rid of rsync dependency of kernel makefile officially, as that can also be done via plain shell tools, they at least answered "what is wrong with rsync".) Maybe because the patch also included - compress="zstd --compress --quiet --stdout" + compress="zstd -T0 --ultra -22 --compress --quiet --stdout" but that only brought the firmware into line with the normal Linux kernel make zstd usage. I will never know. I think what i am trying to say is that maybe "time is money" in addition to anything else. (I never heard about rdfind though. Btw its manual (it has one!) says SEE ALSO md5sum, sha1sum, find, symlinks were cksum is a standard tool. So it is. Everyone its own infrastructure, how large it is; you all only get the binary updates anyway, my Linux distribution compiles from source; and what the mesa library alone has grown in new dependencies that are mostly never needed let alone at runtime, like YAML, that has been done at release-tarball-creation time in the past. At least here.) --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 arnold at skeeve.com Wed Oct 2 15:49:33 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 23:49:33 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> <202410011907.491J74wT448406@freefriends.org> Message-ID: <202410020549.4925nXHf489153@freefriends.org> Rik Farrow wrote: > And my comment about seeing code produced by programmers while doing sales > support dates from 1990. This isn't something new, Also true. In the late 80s I was a sysadmin at Emory U. We had a Vax connected to BITNET with funky hardware and UREP, the Unix RSCS Emulation Program, from the University of Pennsylvania. Every time I had to dive into that code, I felt like I needed a shower afterwards. :-) Arnold From crossd at gmail.com Thu Oct 3 06:42:59 2024 From: crossd at gmail.com (Dan Cross) Date: Wed, 2 Oct 2024 16:42:59 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410020549.4925nXHf489153@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> <202410011907.491J74wT448406@freefriends.org> <202410020549.4925nXHf489153@freefriends.org> Message-ID: On Wed, Oct 2, 2024 at 2:27 AM wrote: > Rik Farrow wrote: > > And my comment about seeing code produced by programmers while doing sales > > support dates from 1990. This isn't something new, > > Also true. In the late 80s I was a sysadmin at Emory U. We had a > Vax connected to BITNET with funky hardware and UREP, the Unix RSCS > Emulation Program, from the University of Pennsylvania. Every time > I had to dive into that code, I felt like I needed a shower afterwards. :-) Uh oh, lest the UPenn alumni among us get angry (high, Ron!) I feel I must point out that UREP wasn't from the University of Pennsylvania, but rather, from The Pennsylvania State University (yes, "The" is part of the name). UPenn (upenn.edu) is an Ivy in Philly; Penn State (psu.edu) is a state school in University Park, which is next to State College (really, that's the name of the town) with satellite campuses scattered around the state. - Dan C. From marc.donner at gmail.com Thu Oct 3 07:54:06 2024 From: marc.donner at gmail.com (Marc Donner) Date: Wed, 2 Oct 2024 17:54:06 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> <202410011907.491J74wT448406@freefriends.org> <202410020549.4925nXHf489153@freefriends.org> Message-ID: RSCS. Sigh. Remote Spooling Communications Subsystem. I suppose I could praise it for its elegant layering of abstractions ... just send a virtual card deck to the virtual card reader on the virtual machine being used by your correspondent. Or I could curse it for its absurdity - really, a virtual card deck? 80 character EBCDIC records. An amazing concept. ===== nygeek.net mindthegapdialogs.com/home On Wed, Oct 2, 2024 at 4:43 PM Dan Cross wrote: > On Wed, Oct 2, 2024 at 2:27 AM wrote: > > Rik Farrow wrote: > > > And my comment about seeing code produced by programmers while doing > sales > > > support dates from 1990. This isn't something new, > > > > Also true. In the late 80s I was a sysadmin at Emory U. We had a > > Vax connected to BITNET with funky hardware and UREP, the Unix RSCS > > Emulation Program, from the University of Pennsylvania. Every time > > I had to dive into that code, I felt like I needed a shower afterwards. > :-) > > Uh oh, lest the UPenn alumni among us get angry (high, Ron!) I feel I > must point out that UREP wasn't from the University of Pennsylvania, > but rather, from The Pennsylvania State University (yes, "The" is part > of the name). UPenn (upenn.edu) is an Ivy in Philly; Penn State > (psu.edu) is a state school in University Park, which is next to State > College (really, that's the name of the town) with satellite campuses > scattered around the state. > > - Dan C. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat Oct 5 07:42:50 2024 From: tuhs at tuhs.org (Jacobson, Doug W [E CPE] via TUHS) Date: Fri, 4 Oct 2024 21:42:50 +0000 Subject: [TUHS] Old troff files (1988-2007) Message-ID: Folks: Long story short, I have a unpublished manuscript that a faculty member in my department wrote late 1980's early 2000's. He did the entire thing in troff, eqn, and pic. The faculty member is still alive. A publisher is interested in the manuscript. I have all of the source files on an old unix machine that still has troff, eqn and pic. It also has groff. This issue is that the pic commands are bracketed by .G1 and .G2 not .PS & .PE. The original machine he would have used would have ran AT&T Sys V on an AT&T 3B20. Below is one of the files. Any thoughts on the .G1 .G2? I can get the files that have only eqn and troff to create postscript, but the .G1/.G2 is not understood by pic. I tried replacing the .G1/.G2 with .PS/PE and it failed. I must be missing another program that uses the .G1/2 Thanks .sp -3.5 .fp 1 Z .fp 2 XI .ps 11 .tl ' ' '1-10' .EQ delim $$ gsize 11 .EN .po 0.9i .vs 15 .G1 frame wid 5.7 ht 6.0 invis coord x 0.2, 100 y -40, +22 log x grid left from -30 to +20 by 10 "" grid left from -40.04 to +19.96 by 10 "" grid left from -39.96 to +20.04 by 10 "" grid left from -39 to +22 by 1 "" grid bot from 0.4 to 40 by *10 "" grid bot from 1 to 100 by *10 "" grid bot from 0.2 to 20 by *10 "" grid bot from 0.3 to 30 by *10 "" grid bot from 0.5 to 50 by *10 "" grid bot from 0.6 to 60 by *10 "" grid bot from 0.7 to 70 by *10 "" grid bot from 0.8 to 80 by *10 "" grid bot from 0.9 to 90 by *10 "" ticks out left from -40 to +20 by 10 ticks out bot from 0.2 to 20 by *10 ticks out bot from 0.4 to 40 by *10 ticks out bot from 1 to 100 by *10 draw solid 0.2 19.93 2 19.93 10 5.97 100 -34.02 new solid 0.2 20.07 2 20.07 10 6.05 100 -33.95 new dotted for i=0.45 to 23 by *1.05 do { w=i*i f=200/sqrt(w*w+104*w+400) next at i,20*log(f) } label left "\u\udB \d\d" label bot "\(*w, rad/s" .G2 .in 2 Fig. 1.4. Graph of the magnitude in dB of $H(s)~=~200 over{s sup 2~+~12^s~+~20}^,$$~s~=~j^omega$. Doug Jacobson University Professor, Dept. Electrical & Computer Engineering Sunil & Sujata Gaitonde Professorship in Cybersecurity Director: ISU Center for Cybersecurity Innovation and Outreach Mail Address: 2520 Osborn Dr, 2215 Coover Hall Iowa State University PH: (515) 294-8307 Fax (515) 294-8432 Office: 371 Durham Hall Center web site: http://www.cyio.iastate.edu/ Personal web site: http://www.dougj.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyndon at orthanc.ca Sat Oct 5 07:50:34 2024 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Fri, 04 Oct 2024 14:50:34 -0700 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: References: Message-ID: Doug, .G1/.G2 are bookmarks for the grap pre-processor. --lyndon From tuhs at tuhs.org Sat Oct 5 07:52:06 2024 From: tuhs at tuhs.org (Jacobson, Doug W [E CPE] via TUHS) Date: Fri, 4 Oct 2024 21:52:06 +0000 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: References: Message-ID: Cool now I need to get grap running :) Doug -----Original Message----- From: Lyndon Nerenberg (VE7TFX/VE6BBM) Sent: Friday, October 4, 2024 4:51 PM To: Jacobson, Doug W [E CPE] ; tuhs at tuhs.org Subject: Re: [TUHS] Old troff files (1988-2007) Doug, .G1/.G2 are bookmarks for the grap pre-processor. --lyndon From tuhs at tuhs.org Sat Oct 5 08:10:59 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Fri, 4 Oct 2024 15:10:59 -0700 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: References: Message-ID: It's in plan9port. https://github.com/9fans/plan9port > On Oct 4, 2024, at 2:52 PM, Jacobson, Doug W [E CPE] via TUHS wrote: > > Cool now I need to get grap running :) > > Doug > > > -----Original Message----- > From: Lyndon Nerenberg (VE7TFX/VE6BBM) > Sent: Friday, October 4, 2024 4:51 PM > To: Jacobson, Doug W [E CPE] ; tuhs at tuhs.org > Subject: Re: [TUHS] Old troff files (1988-2007) > > Doug, .G1/.G2 are bookmarks for the grap pre-processor. > > --lyndon -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Oct 5 09:01:44 2024 From: clemc at ccc.com (Clem Cole) Date: Fri, 4 Oct 2024 19:01:44 -0400 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: References: Message-ID: There part of heirloom troff distribution and are likely to just work on a modern Unix https://n-t-roff.github.io/heirloom/doctools.html Sent from a handheld expect more typos than usual On Fri, Oct 4, 2024 at 5:52 PM Jacobson, Doug W [E CPE] via TUHS < tuhs at tuhs.org> wrote: > Cool now I need to get grap running :) > > Doug > > > -----Original Message----- > From: Lyndon Nerenberg (VE7TFX/VE6BBM) > Sent: Friday, October 4, 2024 4:51 PM > To: Jacobson, Doug W [E CPE] ; tuhs at tuhs.org > Subject: Re: [TUHS] Old troff files (1988-2007) > > Doug, .G1/.G2 are bookmarks for the grap pre-processor. > > --lyndon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Oct 5 09:16:18 2024 From: clemc at ccc.com (Clem Cole) Date: Fri, 4 Oct 2024 19:16:18 -0400 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: References: Message-ID: Btw. The heirloom version of troff is from Solaris SVR4 which should be quite close the version from the 3B20 Sent from a handheld expect more typos than usual On Fri, Oct 4, 2024 at 7:01 PM Clem Cole wrote: > There part of heirloom troff distribution and are likely to just work on a > modern Unix > > https://n-t-roff.github.io/heirloom/doctools.html > > > Sent from a handheld expect more typos than usual > > > On Fri, Oct 4, 2024 at 5:52 PM Jacobson, Doug W [E CPE] via TUHS < > tuhs at tuhs.org> wrote: > >> Cool now I need to get grap running :) >> >> Doug >> >> >> -----Original Message----- >> From: Lyndon Nerenberg (VE7TFX/VE6BBM) >> Sent: Friday, October 4, 2024 4:51 PM >> To: Jacobson, Doug W [E CPE] ; tuhs at tuhs.org >> Subject: Re: [TUHS] Old troff files (1988-2007) >> >> Doug, .G1/.G2 are bookmarks for the grap pre-processor. >> >> --lyndon >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Sat Oct 5 10:14:33 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Fri, 4 Oct 2024 19:14:33 -0500 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: References: Message-ID: <20241005001433.7hukoga5bbbb3ygl@illithid> Hi Doug, At 2024-10-04T21:42:50+0000, Jacobson, Doug W [E CPE] via TUHS wrote: > Folks: > > Long story short, I have a unpublished manuscript that a faculty > member in my department wrote late 1980's early 2000's. He did the > entire thing in troff, eqn, and pic. The faculty member is still > alive. A publisher is interested in the manuscript. I have all of > the source files on an old unix machine that still has troff, eqn and > pic. It also has groff. This issue is that the pic commands are > bracketed by .G1 and .G2 not .PS & .PE. As others noted, those are the characteristic preprocessor tokens used by grap(1). groff(1) says: A free implementation of the grap preprocessor, written by Ted Faber ⟨faber at lunabase.org⟩, can be found at the grap website ⟨http://www.lunabase.org/~faber/Vault/software/grap/⟩. groff supports only this grap. Distributors often have a package of Faber's grap. I'm not aware of any other in circulation. (Happy to be corrected here.) Please contact the groff list, groff at gnu dot org, if you have any problems using it to format these documents and/or to note formatting discrepancies between Unix troff and groff. There will likely be some. I've noted differences between DWB troff and Heirloom troff, so using the latter does not guarantee identical rendering, and moreover DWB/System V troff has some bugs/limitations that Heirloom and/or GNU troffs have fixed, and some of these can affect formatting. Here's a list from groff's tbl(1) man page, for example. GNU tbl enhancements In addition to extensions noted above, GNU tbl removes constraints endured by users of AT&T tbl. • Region options can be specified in any lettercase. • There is no limit on the number of columns in a table, regardless of their classification, nor any limit on the number of text blocks. • All table rows are considered when deciding column widths, not just those occurring in the first 200 input lines of a region. Similarly, table continuation (.T&) tokens are recognized outside a region’s first 200 input lines. • Numeric and alphabetic entries may appear in the same column. • Numeric and alphabetic entries may span horizontally. One can imagine how a 200+-row table could format differently between DWB/System V and GNU tbl, without either being "wrong". Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From peter.martin.yardley at gmail.com Sat Oct 5 14:09:54 2024 From: peter.martin.yardley at gmail.com (Peter Yardley) Date: Sat, 5 Oct 2024 14:09:54 +1000 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: <20241005001433.7hukoga5bbbb3ygl@illithid> References: <20241005001433.7hukoga5bbbb3ygl@illithid> Message-ID: <3064B620-86EA-4F79-A440-536425FFE2D7@gmail.com> This isn’t helpful, but the .G1 .G2 look a lot like Gerber codes used in NC machine tools. Sent from my iPhone > On 5 Oct 2024, at 1:52 pm, G. Branden Robinson wrote: > > Hi Doug, > > At 2024-10-04T21:42:50+0000, Jacobson, Doug W [E CPE] via TUHS wrote: >> Folks: >> >> Long story short, I have a unpublished manuscript that a faculty >> member in my department wrote late 1980's early 2000's. He did the >> entire thing in troff, eqn, and pic. The faculty member is still >> alive. A publisher is interested in the manuscript. I have all of >> the source files on an old unix machine that still has troff, eqn and >> pic. It also has groff. This issue is that the pic commands are >> bracketed by .G1 and .G2 not .PS & .PE. > > As others noted, those are the characteristic preprocessor tokens used > by grap(1). > > groff(1) says: > A free implementation of the grap preprocessor, written by Ted > Faber ⟨faber at lunabase.org⟩, can be found at the grap website > ⟨http://www.lunabase.org/~faber/Vault/software/grap/⟩. groff > supports only this grap. > > Distributors often have a package of Faber's grap. I'm not aware of any > other in circulation. (Happy to be corrected here.) > > Please contact the groff list, groff at gnu dot org, if you have any > problems using it to format these documents and/or to note formatting > discrepancies between Unix troff and groff. There will likely be some. > > I've noted differences between DWB troff and Heirloom troff, so using > the latter does not guarantee identical rendering, and moreover > DWB/System V troff has some bugs/limitations that Heirloom and/or GNU > troffs have fixed, and some of these can affect formatting. > > Here's a list from groff's tbl(1) man page, for example. > > GNU tbl enhancements > In addition to extensions noted above, GNU tbl removes constraints > endured by users of AT&T tbl. > > • Region options can be specified in any lettercase. > > • There is no limit on the number of columns in a table, > regardless of their classification, nor any limit on the number > of text blocks. > > • All table rows are considered when deciding column widths, not > just those occurring in the first 200 input lines of a region. > Similarly, table continuation (.T&) tokens are recognized > outside a region’s first 200 input lines. > > • Numeric and alphabetic entries may appear in the same column. > > • Numeric and alphabetic entries may span horizontally. > > One can imagine how a 200+-row table could format differently between > DWB/System V and GNU tbl, without either being "wrong". > > Regards, > Branden From sjenkin at canb.auug.org.au Sat Oct 5 16:55:46 2024 From: sjenkin at canb.auug.org.au (sjenkin at canb.auug.org.au) Date: Sat, 5 Oct 2024 16:55:46 +1000 Subject: [TUHS] UNIX NEWS, volumes 1-7 out there? Message-ID: In Sept 2019 Warner Losh was looking for copies of the first volumes of UNIX NEWS / Login. Clem Cole noted that the Usenix Archives were also looking. Kurt H Maier, noted he had pages from 1976, Volume 1, Number 4. Jeremy C. Reed pointed to multiple items available online. His email appears in a separate email thread on TUHS. I stumbled on UNIX NEWS Number 1 in the Internet Archive Which is from a near complete Usenix collection of ‘;login' from 1975 to 2000 . 1979 (Volume 4) is missing from the series [ as at Oct 2024 ] I wasn’t able to navigate the Usenix website to find the Archives Clem Cole mentioned, to confirm they also had copies. I also stumbled on a pointer to “John Gilmore’s original scans” from 1975 - 1978, presumably the base for the Usenix / Archive.org set. It’s seems that the call for materials was pretty successful. -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From clemc at ccc.com Sat Oct 5 23:14:27 2024 From: clemc at ccc.com (Clem Cole) Date: Sat, 5 Oct 2024 09:14:27 -0400 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: <20241005001433.7hukoga5bbbb3ygl@illithid> References: <20241005001433.7hukoga5bbbb3ygl@illithid> Message-ID: Branden. Thank you. FWIW I have generally found heirloom to be good enough for rendering most old troff on modern systems such that I can reasonably read the text. But I suspect your detail is useful to know in some cases. As they say YMMR. That said I often use the groff tools kits since it’s what comes with things like brew on my Mac but it burps on certain macros, particularly when I want to render old man pages or doc files from old Unix versions with things like .UX macro (which is a PITA). Thanks again, Clem Sent from a handheld expect more typos than usual On Fri, Oct 4, 2024 at 8:14 PM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > Hi Doug, > > At 2024-10-04T21:42:50+0000, Jacobson, Doug W [E CPE] via TUHS wrote: > > Folks: > > > > Long story short, I have a unpublished manuscript that a faculty > > member in my department wrote late 1980's early 2000's. He did the > > entire thing in troff, eqn, and pic. The faculty member is still > > alive. A publisher is interested in the manuscript. I have all of > > the source files on an old unix machine that still has troff, eqn and > > pic. It also has groff. This issue is that the pic commands are > > bracketed by .G1 and .G2 not .PS & .PE. > > As others noted, those are the characteristic preprocessor tokens used > by grap(1). > > groff(1) says: > A free implementation of the grap preprocessor, written by Ted > Faber ⟨faber at lunabase.org⟩, can be found at the grap website > ⟨http://www.lunabase.org/~faber/Vault/software/grap/⟩. groff > supports only this grap. > > Distributors often have a package of Faber's grap. I'm not aware of any > other in circulation. (Happy to be corrected here.) > > Please contact the groff list, groff at gnu dot org, if you have any > problems using it to format these documents and/or to note formatting > discrepancies between Unix troff and groff. There will likely be some. > > I've noted differences between DWB troff and Heirloom troff, so using > the latter does not guarantee identical rendering, and moreover > DWB/System V troff has some bugs/limitations that Heirloom and/or GNU > troffs have fixed, and some of these can affect formatting. > > Here's a list from groff's tbl(1) man page, for example. > > GNU tbl enhancements > In addition to extensions noted above, GNU tbl removes constraints > endured by users of AT&T tbl. > > • Region options can be specified in any lettercase. > > • There is no limit on the number of columns in a table, > regardless of their classification, nor any limit on the number > of text blocks. > > • All table rows are considered when deciding column widths, not > just those occurring in the first 200 input lines of a region. > Similarly, table continuation (.T&) tokens are recognized > outside a region’s first 200 input lines. > > • Numeric and alphabetic entries may appear in the same column. > > • Numeric and alphabetic entries may span horizontally. > > One can imagine how a 200+-row table could format differently between > DWB/System V and GNU tbl, without either being "wrong". > > Regards, > Branden > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Sun Oct 6 03:45:13 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sat, 05 Oct 2024 11:45:13 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> <202410011907.491J74wT448406@freefriends.org> <202410020549.4925nXHf489153@freefriends.org> Message-ID: <202410051745.495HjDFu829152@freefriends.org> Dan Cross wrote: > On Wed, Oct 2, 2024 at 2:27 AM wrote: > > Rik Farrow wrote: > > > And my comment about seeing code produced by programmers while doing sales > > > support dates from 1990. This isn't something new, > > > > Also true. In the late 80s I was a sysadmin at Emory U. We had a > > Vax connected to BITNET with funky hardware and UREP, the Unix RSCS > > Emulation Program, from the University of Pennsylvania. Every time > > I had to dive into that code, I felt like I needed a shower afterwards. :-) > > Uh oh, lest the UPenn alumni among us get angry (high, Ron!) I feel I > must point out that UREP wasn't from the University of Pennsylvania, > but rather, from The Pennsylvania State University (yes, "The" is part > of the name). UPenn (upenn.edu) is an Ivy in Philly; Penn State > (psu.edu) is a state school in University Park, which is next to State > College (really, that's the name of the town) with satellite campuses > scattered around the state. > > - Dan C. Ooops. My bad. Thanks Dan, for the correction. Either way, the code was awful. :-) Arnold From rich.salz at gmail.com Sun Oct 6 05:44:53 2024 From: rich.salz at gmail.com (Rich Salz) Date: Sat, 5 Oct 2024 15:44:53 -0400 Subject: [TUHS] 30 days of awktober Message-ID: Someone is trying to write something interesting about awk every day of this month. The thread starts here: https://mastodon.mit.edu/@eichin/113240121988228925 -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Sun Oct 6 08:22:07 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 5 Oct 2024 17:22:07 -0500 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: References: <20241005001433.7hukoga5bbbb3ygl@illithid> Message-ID: <20241005222207.eerdrgtsttmx42kb@illithid> Hi Clem, At 2024-10-05T09:14:27-0400, Clem Cole wrote: > Branden. Thank you. FWIW I have generally found heirloom to be > good enough for rendering most old troff on modern systems such that I > can reasonably read the text. I generally get good results with it as well. I frequently compare the behaviors of DWB 3.3 troff and Heirloom troff with 2-3 versions of GNU troff (1.22.4 [2018], 1.23.0 [2023], and bleeding-edge development). Setting aside the issue of extensions (whether to the *roff language, to preprocessors, or to macro packages), I find that Heirloom fixes many DWB bugs. I think GNU troff can boast of slightly better terminal support, although nroff veterans are sometimes scandalized by GNU troff's terminal output driver (grotty(1)) assuming that it's _not_ talking to a Teletype Model 37, but rather a more-or-less ECMA-48 video terminal. To brutally abbreviate the history, for $reasons Unix nroff got frozen in amber in 1978 with respect to terminal support, and continues to live in a world where the termcap and terminfo libraries were never written. Unfortunately, the maintainer of the less(1) pager still presumes (prefers?) that world. A previous groff maintainer observed that few of our users operate paper terminals. (Nevertheless grotty retains support for them with its `-c` option.) Anton Shepelev wrote a summary I find admirably concise and blunt: "`grotty' is not an appendix to a pager, but a program for printing direct to the terminal. Most terminals support those basic ANSI control sequences, and many console programs freely use them. If a pager cannot transparently forward them to the terminal, it is a problem of the pager, not of `grotty', and having a broken -man configuration by default to just to appease `less' is stupid." > That said I often use the groff tools kits since it’s what comes with > things like brew on my Mac but it burps on certain macros, > particularly when I want to render old man pages or doc files from old > Unix versions with things like .UX macro (which is a PITA). Yes. Our ms(7) manual ("ms.ms"), originally by Larry Kollar, concedes its limitations. --- snip --- 7.1. Unix Version 7 ms macros not implemented by groff ms Several macros described in the Unix Version 7 ms documentation are unimplemented by groff ms because they are specific to the requirements of documents produced internally by Bell Laboratories, some of which also require a glyph for the Bell System logo that groff does not sup‐ port. These macros implemented several document type formats (EG, IM, MF, MR, TM, TR), were meaningful only in conjunction with the use of certain document types (AT, CS, CT, OK, SG), stored the postal addresses of Bell Labs sites (HO, IH, MH, PY, WH), or lacked a stable definition over time (UX). To compatibly render historical ms documents using these macros, we advise your documents to invoke the rm request to re‐ move any such macros it uses and then define replacements with an au‐ thentically typeset original at hand.[10] For informal purposes, a sim‐ ple definition of UX should maintain the readability of the document’s substance. ┌───────────────┐ │ .rm UX │ │ .ds UX Unix\" │ └───────────────┘ ─────────── [10] The removal beforehand is necessary because groff ms aliases these macros to a diagnostic macro, and you want to redefine the aliased name, not its target. --- end snip --- The point of the `UX` macro was to abstract away the problem of sticking a footnote at the bottom of the page to acknowledge (or in the Labs' case, announce) the holder of the Unix trade mark on its first occurrence. I suspect the CSRC did not anticipate that the trade mark would ever change hands, let alone how many times... Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From steffen at sdaoden.eu Sun Oct 6 08:23:25 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sun, 06 Oct 2024 00:23:25 +0200 Subject: [TUHS] 30 days of awktober In-Reply-To: References: Message-ID: <20241005222325.imlGrAhy@steffen%sdaoden.eu> Rich Salz wrote in : |Someone is trying to write something interesting about awk every day of |this month. The thread starts here: |https://mastodon.mit.edu/@eichin/113240121988228925 The good thing is that find(1) now has + standardized. Ie his find /tmp --print0 | xargs -0 stat --format "%s %n" can now be find /tmp -exec stat --format "%s %n" {} + And the POSIX core developers mention (APPLICATION USAGE) It should be noted that using find with −print0 to pipe input to xargs −r0 is less safe than using find with −exec because if find −print0 is terminated after it has written a partial pathname, the partial pathname may be processed as if it was a complete pathname. Heh! Other than that, off-topic to this thread i am afraid, but should be posted to another, .. but now that i am here, you know, we all owe thanks to Geoff Clare and Andrey Josey (and Eric Blake of RedHat, but really, the Linux approach to this problem makes me sick, it really should have to work as shown in RFC 2553->3493), as only thanks to these people the BSD socket API is still compatible with ISO C .. at least on POSIX systems! And here is how: In stating these field mapping requirements when a cast operator is applied to the various socket address structures, the standard defines the behavior in circumstances where the behavior is undefined in the ISO C standard. The onus is on implementations to ensure that these mappings are as described in the standard, making use of implementation-specific extensions if necessary, even though this is not stated explicitly. and the solution is On page 386 line 13115 section DESCRIPTION, change: When a pointer to a sockaddr_storage structure is cast as a pointer to a sockaddr structure, the ss_family field of the sockaddr_storage structure shall map onto the sa_family field of the sockaddr structure. When a pointer to a sockaddr_storage structure is cast as a pointer to a protocol-specific address structure, the ss_family field shall map onto a field of that structure that is of type sa_family_t and that identifies the protocol’s address family. to: When a pointer to a sockaddr_storage structure is cast as a pointer to a sockaddr structure, or vice versa, the ss_family field of the sockaddr_storage structure shall map onto the sa_family field of the sockaddr structure. When a pointer to a sockaddr_storage structure is cast as a pointer to a protocol-specific address structure, or vice versa, the ss_family field shall map onto a field of that structure that is of type sa_family_t and that identifies the protocol’s address family. When a pointer to a sockaddr structure is cast as a pointer to a protocol-specific address structure, or vice versa, the sa_family field shall map onto a field of that structure that is of type sa_family_t and that identifies the protocol’s address family. Additionally, the structures shall be defined in such a way that the compiler treats an access to the stored value of the sa_family_t member of any of these structures, via an lvalue expression whose type involves any other one of these structures, as permissible, despite the more restrictive expression rules on stored value access as stated in the ISO C standard. as well as this RATIONALE addition: Note that defining the sockaddr_storage and sockaddr structures using only mechanisms defined in early editions of the ISO C standard may produce aliasing diagnostics when applications use casting between pointers to the various socket address structures. Because of the large body of existing code utilizing sockets in a way that could trigger undefined behavior due to strict aliasing rules, this standard mandates that these structures can alias each other for accessing the sa_family_t member of the structures, so as to preserve well-defined semantics. An implementation's header files may need to use anonymous unions, or even an implementation-specific extension, to comply with the requirements of this standard. I love this standard. --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 g.branden.robinson at gmail.com Sun Oct 6 15:53:20 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sun, 6 Oct 2024 00:53:20 -0500 Subject: [TUHS] Why groff ms doesn't completely support historical documents In-Reply-To: References: <20241005001433.7hukoga5bbbb3ygl@illithid> <20241005222207.eerdrgtsttmx42kb@illithid> Message-ID: <20241006055320.wlo3syvcbma6wzk2@illithid> Someone on the TUHS list mailed me privately, prompting me to write this lengthy apology (in the classical sense) of why groff doesn't make a certain application easier. I have slightly revised my response. This message also may serve as a summary of the challenges that need to be overcome if someone else wants to tackle the job, and potentially contribute it to groff. [person creates PDFs of historical Unix documents (many of which are written using the ms macros) and wishes groff ms made the task easier] I sympathize. I sometimes render historical documents, so I prescribed in groff ms's documentation the approach that I take myself. I decided against trying to support a "-matt" or "-msatt" option in groff because it's flatly impossible to know which definition of `UX` to use. Even a date declaration in the document sheds little light, as we then have to consider the question of whether we want fidelity to the actual state of the mark at the time of that declared date, or to what would have been rendered in the author's environment--and they may have been using an ms that wasn't "up to date" in the same respect. That information, too, is not recorded in the document.[1] Providing all the macros _except_ `UX` didn't seem likely to satisfy users since that's the most important one! It shows up in body text whereas all the others seldom do--if you can live without the cover page then, often, you're golden. Except for `UX`. Finally there is the name collision problem with Berkeley. 4.2BSD and later ms defined `CT` and `TM` macros (aspects of their "thesis mode") and once again there's no declarator within the document to tell you which dialect of ms is in use. This one can be heuristically figured out with pretty good odds, I suspect, but troff works as a filter--what was I going to do, write a preprocessor just for this? (Hmm, maybe grog(1) could do it, and that would be in its wheelhouse. But there's no point until and unless we reimplement support for Berkeley thesis mode in the first place [so that grog has an option argument to report], and that is an undertaking I have demurred.[2]) It seemed like a moderate amount of work for almost zero upside. It's also hard to validate/verify my work. The only historical troffs to which I have access are Seventh Edition Unix troff (1979, before Kernighan) and DWB 3.3 (early 1990s). It's a right pain in the butt to inspect typesetter output on V7 because I have nothing that emulates a C/A/T or translates it to device-independent troff output for a "ditroff"-style device description that Kernighan troff, DWB/Hierloom Doctools troff, or GNU troff could use. And even if I had either of those, they'd have to be vetted to a _high_ degree of quality before they'd be fit for purpose; else I wouldn't know whether I was chasing bugs in the groff ms macros or the C/A/T emulator/translator. So, to summarize, I confine my compatibility efforts to _nroff_ output, and rule the Bell Labs "site" macros out of scope. I feel there is not much more I can do, and have confidence my results, without resources that I'm lacking. I hope this sheds some light on my reasoning. Regards, Branden [1] Still, if someone wants to start, I'd start here. https://minnie.tuhs.org/cgi-bin/utree.pl?file=V10/vol2/ms/tmac.s [2] One person, ever, has requested it, 20 years ago. And I have no specimens of input or corresponding model output rendered by an "authentic" BSD troff [formatter executable PLUS support files] against which to develop a reconstruction. (On the bright side, the Berkeley modifications to the once-encumbered AT&T "tmac.s" are, of themselves, presumably BSD-licensed.) https://savannah.gnu.org/bugs/?64455 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From crossd at gmail.com Sun Oct 6 22:20:55 2024 From: crossd at gmail.com (Dan Cross) Date: Sun, 6 Oct 2024 08:20:55 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410051745.495HjDFu829152@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> <202410011907.491J74wT448406@freefriends.org> <202410020549.4925nXHf489153@freefriends.org> <202410051745.495HjDFu829152@freefriends.org> Message-ID: On Sat, Oct 5, 2024, 1:45 PM wrote: > Dan Cross wrote: > > > On Wed, Oct 2, 2024 at 2:27 AM wrote: > > > Rik Farrow wrote: > > > > And my comment about seeing code produced by programmers while doing > sales > > > > support dates from 1990. This isn't something new, > > > > > > Also true. In the late 80s I was a sysadmin at Emory U. We had a > > > Vax connected to BITNET with funky hardware and UREP, the Unix RSCS > > > Emulation Program, from the University of Pennsylvania. Every time > > > I had to dive into that code, I felt like I needed a shower > afterwards. :-) > > > > Uh oh, lest the UPenn alumni among us get angry (high, Ron!) I feel I > > must point out that UREP wasn't from the University of Pennsylvania, > > but rather, from The Pennsylvania State University (yes, "The" is part > > of the name). UPenn (upenn.edu) is an Ivy in Philly; Penn State > > (psu.edu) is a state school in University Park, which is next to State > > College (really, that's the name of the town) with satellite campuses > > scattered around the state. > > Ooops. My bad. Thanks Dan, for the correction. > > Either way, the code was awful. :-) > Ha, no worries; and I can well believe that the code was awful. I do wonder if a version of it has survived somewhere; I've personally never seen it, but there's very little information about it out there anymore. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Sun Oct 6 22:29:44 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 06 Oct 2024 06:29:44 -0600 Subject: [TUHS] UREP code (was Re: Re: Minimum Array Sizes in 16 bit C (was Maximum)) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> <202410011907.491J74wT448406@freefriends.org> <202410020549.4925nXHf489153@freefriends.org> <202410051745.495HjDFu829152@freefriends.org> Message-ID: <202410061229.496CTird901191@freefriends.org> Dan Cross wrote: > I do wonder if a version of it has survived somewhere; I've personally > never seen it, but there's very little information about it out there > anymore. I don't have it. I think it was licensed software from Penn State. I don't remember a lot of details. It gave a similar experience to that on IBM systems; as your mail travelled point to point you got a message printed on your terminal as to what node it was going through. (Or something like that.) There was also a facility similar to write(1) that let you chat with someone on a remote BITNET site. Overall, it did work. Arnold From jaapna at xs4all.nl Sun Oct 6 22:54:59 2024 From: jaapna at xs4all.nl (Jaap Akkerhuis) Date: Sun, 6 Oct 2024 14:54:59 +0200 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: <20241005222207.eerdrgtsttmx42kb@illithid> References: <20241005001433.7hukoga5bbbb3ygl@illithid> <20241005222207.eerdrgtsttmx42kb@illithid> Message-ID: > On 6 Oct 2024, at 00:22, G. Branden Robinson wrote: > > Unix nroff got frozen > in amber in 1978 with respect to terminal support, and continues to live > in a world where the termcap and terminfo libraries were never written. Nroff did actually read in the output description from, if I remember correctly, /usr/lib/termtab/xxx with the argument -Txxx. these where stripped object files. I have made them for Diable daisy-wheel printers. Some could create bold characters by overprinting and we once had one with two print heads, the second head had an italics daisy-wheel mounted. jaap -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Mon Oct 7 01:11:33 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sun, 6 Oct 2024 10:11:33 -0500 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: References: <20241005001433.7hukoga5bbbb3ygl@illithid> <20241005222207.eerdrgtsttmx42kb@illithid> Message-ID: <20241006151133.fbj6pmujpvuuo47d@illithid> Hi Jaap, At 2024-10-06T14:54:59+0200, Jaap Akkerhuis wrote: > > On 6 Oct 2024, at 00:22, G. Branden Robinson > > wrote: > > > > Unix nroff got frozen in amber in 1978 with respect to terminal > > support, and continues to live in a world where the termcap and > > terminfo libraries were never written. > > Nroff did actually read in the output description from, if I remember > correctly, /usr/lib/termtab/xxx with the argument -Txxx. Yes. When Kernighan refactored V7 troff/nroff for device-independence, he implemented a similar scheme for each. While for troff, this resulted in device and font description files, "DESC" and a motley variety of capitalized one-or-two letter names for fonts, for nroff they were termed "driving tables", a terminological choice that concealed how closely they resembled the troff scheme. Compare, for example: https://github.com/n-t-roff/DWB3.3/blob/master/postscript/devopost/DESC https://github.com/n-t-roff/DWB3.3/blob/master/postscript/devopost/R with: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V10/cmd/troff/tab.37 https://minnie.tuhs.org/cgi-bin/utree.pl?file=V10/cmd/troff/tab.450 ...and the family resemblance seems clear. > these where stripped object files. I have heard tell of a "binary format" for Kernighan troff device and font descriptions but never encountered it. groff never attempted to replicate it and I gather that Plan 9 troff also discarded it. > I have made them for Diable daisy-wheel printers. Some could create > bold characters by overprinting and we once had one with two print > heads, the second head had an italics daisy-wheel mounted. Right. The Diablo features heavily in early '80s Unix documentation. However none of this has much to do, in my opinion, with the _terminal capability databases_ offered by termcap and (later) terminfo. The whole point of these is to _query_ the user's terminal type, not have to be told it with some `-T` option. To my knowledge, no nroff has ever simply looked at "$TERM" and then decided how to format output. Approximately all other Unix software that writes to a terminal behaves that way. nroff didn't, and by God some Unix grognards would have it stay that way.[1][2] Mark Nudelman's less(1) is probably the foremost contributor of inertia here, since man(1) is far and away the leading application of nroff(1), and less(1) the victorious pager program after a long and bloody campaign of attrition. (This isn't a complaint; we could have done worse. most(1) could have won instead.[3]) Lennart Jablonka has contributed a patch to groff to resolve this longevous discrepancy. (It ended up on my slow path for integration because I decided I needed to understand terminfo much better, and that in turn led me to contribute a large volume of man page revisions to ncurses, many of which can be enjoyed(?) in its 6.5 release.[4]) https://savannah.gnu.org/bugs/?63583 Regards, Branden [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=312935 [2] https://unix.stackexchange.com/questions/729124/linux-9-commands-send-ansi-color-sequences-to-monochrome-terminal [3] https://invisible-island.net/ncurses/ncurses-slang.html [4] https://invisible-island.net/ncurses/announce.html https://invisible-island.net/ncurses/man/ Despite his grognard standpoint with respect to grotty(1)'s default use of SGR escape sequences in output, I would emphasize that Thomas Dickey has been a pleasure to work with. It's difficult to imagine the same being true of Alan Curry. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ron at ronnatalie.com Mon Oct 7 02:21:44 2024 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 06 Oct 2024 16:21:44 +0000 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: <20241006151133.fbj6pmujpvuuo47d@illithid> References: <20241005001433.7hukoga5bbbb3ygl@illithid> <20241005222207.eerdrgtsttmx42kb@illithid> <20241006151133.fbj6pmujpvuuo47d@illithid> Message-ID: For years JHU had a KSR37 with a Greek box and nroff drove it direcly sending all those ESC-8 and ESC-9 things. There were some output filters that converted this to things like the Diablo daisy wheels and even the rather crude dot matrix lineprinter we had. Eventually, George Toth, one of our programmers came up with the idea of building a C/A/T simulator. He went to the Naval Research Lab and printed out a full typeface on film from their CAT. He then cut them out and glued them to the front of an oscilliscope, one letter at a time. There was a PDP-11/20 that ran a Scanning Transmission Electron Microscope (at the time one of the few in captivity). He would take the scanning driver cables from the microscope and put them on the X/Y of the oscilliscope and then took the sense wire and put it on a photomultiplier tube that was mounted in a scope camera. He then fired up the (DOS/BATCH) microscope software to tell it to do a scan. He’d then swap the RK05 packs and bring up Minunix and read his scanned character out of the frame buffer. One character at a time he accumulated an entire Roman, Bold, Italic, and Symbol set. He wrote the emulator and we could TROFF through his software to the Versatec lineprinter we had. The chemicals from those printers makes my skin break out just thinking about it. It was the only printer we had at BRL for political reasons for quite a while. It also would eat the ink of the government issued (made oddly by a workshop for the blind) pens. -Ron From leah at vuxu.org Tue Oct 8 00:50:48 2024 From: leah at vuxu.org (Leah Neukirchen) Date: Mon, 07 Oct 2024 16:50:48 +0200 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: <20241005222207.eerdrgtsttmx42kb@illithid> (G. Branden Robinson's message of "Sat, 5 Oct 2024 17:22:07 -0500") References: <20241005001433.7hukoga5bbbb3ygl@illithid> <20241005222207.eerdrgtsttmx42kb@illithid> Message-ID: <87ploc2chj.fsf@vuxu.org> "G. Branden Robinson" writes: > Anton Shepelev wrote a summary I find admirably concise and blunt: > > "`grotty' is not an appendix to a pager, but a program for printing > direct to the terminal. Most terminals support those basic ANSI > control sequences, and many console programs freely use them. If a > pager cannot transparently forward them to the terminal, it is a > problem of the pager, not of `grotty', and having a broken -man > configuration by default to just to appease `less' is stupid." I don't see the problem, less supports -R for the last 25 years... -- Leah Neukirchen https://leahneukirchen.org/ From g.branden.robinson at gmail.com Tue Oct 8 16:45:08 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Tue, 8 Oct 2024 01:45:08 -0500 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: <87ploc2chj.fsf@vuxu.org> References: <20241005001433.7hukoga5bbbb3ygl@illithid> <20241005222207.eerdrgtsttmx42kb@illithid> <87ploc2chj.fsf@vuxu.org> Message-ID: <20241008064508.vtcvijqmedztrfeb@illithid> Hi Leah, At 2024-10-07T16:50:48+0200, Leah Neukirchen wrote: > "G. Branden Robinson" writes: > > Anton Shepelev wrote a summary I find admirably concise and blunt: > > > > "`grotty' is not an appendix to a pager, but a program for printing > > direct to the terminal. Most terminals support those basic ANSI > > control sequences, and many console programs freely use them. If a > > pager cannot transparently forward them to the terminal, it is a > > problem of the pager, not of `grotty', and having a broken -man > > configuration by default to just to appease `less' is stupid." > > I don't see the problem, less supports -R for the last 25 years... Yeah. People's ire seems to rise from the fact that grotty's default is to assume SGR support and less's default is to not interpret SGR. I would prefer that `-R` were less's default; that would better serve the larger proportion of ECMA-48 video terminals using the pager versus those using it with (an emulator of) hardcopy terminals. Whatever transition process needs to commence for that to happen, I think it should. But in the meantime it's no great effort for me (nor for most people) to alias 'less' to 'less -R', write a shell function to do similarly, or just type three more characters. (For those requiring accessibility assistance, shell aliases and functions, programmable key bindings, and similar should serve as they do the merely impatient.) Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tuhs at tuhs.org Tue Oct 8 20:33:35 2024 From: tuhs at tuhs.org (Jacobson, Doug W [E CPE] via TUHS) Date: Tue, 8 Oct 2024 10:33:35 +0000 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: <20241008064508.vtcvijqmedztrfeb@illithid> References: <20241005001433.7hukoga5bbbb3ygl@illithid> <20241005222207.eerdrgtsttmx42kb@illithid> <87ploc2chj.fsf@vuxu.org> <20241008064508.vtcvijqmedztrfeb@illithid> Message-ID: Hello group: BTW:, I love all the comments and discussions this started. Using Groff (eqn+pic) + grap I was able to create a PDF of the book. It took about 8 hours part of which was figuring out the syntax differences. He had divided the book up into a file for each page or two, so 100+ files. I think he did that, so he did not waste paper since he had to print out the pages to see if they looked right, no display to view them. It was not perfect but is good enough for the publisher to review. The book is on filters (EE book) and is full of graphs, circuits, and equations. He used pic to draw the circuits, which was amazing. This was fun to take a forgotten manuscript written by a colleague and with luck maybe getting it published while he is still alive. If the publisher wants to publish it, I'm not sure how they will handle troff files :) Doug -----Original Message----- From: G. Branden Robinson Sent: Tuesday, October 8, 2024 1:45 AM To: Leah Neukirchen Cc: Clem Cole ; Jacobson, Doug W [E CPE] ; tuhs at tuhs.org; groff at gnu.org Subject: Re: [TUHS] Re: Old troff files (1988-2007) Hi Leah, At 2024-10-07T16:50:48+0200, Leah Neukirchen wrote: > "G. Branden Robinson" writes: > > Anton Shepelev wrote a summary I find admirably concise and blunt: > > > > "`grotty' is not an appendix to a pager, but a program for printing > > direct to the terminal. Most terminals support those basic ANSI > > control sequences, and many console programs freely use them. If a > > pager cannot transparently forward them to the terminal, it is a > > problem of the pager, not of `grotty', and having a broken -man > > configuration by default to just to appease `less' is stupid." > > I don't see the problem, less supports -R for the last 25 years... Yeah. People's ire seems to rise from the fact that grotty's default is to assume SGR support and less's default is to not interpret SGR. I would prefer that `-R` were less's default; that would better serve the larger proportion of ECMA-48 video terminals using the pager versus those using it with (an emulator of) hardcopy terminals. Whatever transition process needs to commence for that to happen, I think it should. But in the meantime it's no great effort for me (nor for most people) to alias 'less' to 'less -R', write a shell function to do similarly, or just type three more characters. (For those requiring accessibility assistance, shell aliases and functions, programmable key bindings, and similar should serve as they do the merely impatient.) Regards, Branden From g.branden.robinson at gmail.com Tue Oct 8 20:49:33 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Tue, 8 Oct 2024 05:49:33 -0500 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: References: <20241005001433.7hukoga5bbbb3ygl@illithid> <20241005222207.eerdrgtsttmx42kb@illithid> <87ploc2chj.fsf@vuxu.org> <20241008064508.vtcvijqmedztrfeb@illithid> Message-ID: <20241008104933.snbk6wxt4rpaahfl@illithid> [dropped Clem and Leah from CC] Hi Doug, At 2024-10-08T10:33:35+0000, Jacobson, Doug W [E CPE] wrote: > Using Groff (eqn+pic) + grap I was able to create a PDF of the book. > It took about 8 hours 8-O > part of which was figuring out the syntax differences. Oh, wall clock time including human engagement. That sounds really reasonable! I'm not sure I want to estimate how many hours I've put into revising groff's own documentation. Or ncurses's. Eight hours processing time on a modern machine (without inflooping) would be shocking to me. > He had divided the book up into a file for each page or two, so 100+ > files. I think he did that, so he did not waste paper since he had to > print out the pages to see if they looked right, no display to view > them. No PostScript or PDF preview program? I can think of a few: mupdf, evince, okular. Deri James (groff developer) can probably name a dozen. > It was not perfect but is good enough for the publisher to review. > The book is on filters (EE book) and is full of graphs, circuits, and > equations. He used pic to draw the circuits, which was amazing. This > was fun to take a forgotten manuscript written by a colleague and with > luck maybe getting it published while he is still alive. If the > publisher wants to publish it, I'm not sure how they will handle troff > files :) If you'd care to share it with me in my capacity as groff maintainer, I'd be interested to use it for unofficial regression testing. Alternatively, if you can't find an interested publisher, please consider asking the author (I assume he's also the copyright holder) to release it under a Creative Commons license so the whole world can enjoy. Also, so I can selfishly enjoy the pleasure of pointing to a sophisticated typeset work and saying, "look what groff can do!" ;-) (Just in case people aren't impressed enough with K&R or W. Richard Stevens.) Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tuhs at tuhs.org Tue Oct 8 21:24:52 2024 From: tuhs at tuhs.org (Jacobson, Doug W [E CPE] via TUHS) Date: Tue, 8 Oct 2024 11:24:52 +0000 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: <20241008104933.snbk6wxt4rpaahfl@illithid> References: <20241005001433.7hukoga5bbbb3ygl@illithid> <20241005222207.eerdrgtsttmx42kb@illithid> <87ploc2chj.fsf@vuxu.org> <20241008064508.vtcvijqmedztrfeb@illithid> <20241008104933.snbk6wxt4rpaahfl@illithid> Message-ID: Branden: 8 hours of my time, not computer time. The faculty member started this in 1988, and we (the department) did not have access to much in the way of visual previewing. He was an EE by training, and really latched onto Unix, vi, troff, etc. At the time we were running a series of AT&T 3B2/5, and a 3B20. My wife was sysadmin and I was on the faculty. We had a large number of faculty and staff using troff for editing and publishing. I remember my wife teaching Unix and Troff to faculty. We did have a few of the AT&T graphics terminal (I cannot remember the model number) Another fun thing, I used troff and vi (on a different) system to write my Ph.D. in 1985. I will reach out to you about the files etc. He is the copyright holder. His health is not good, and his family with the help of a former student is the one hoping to get it published. Doug -----Original Message----- From: G. Branden Robinson Sent: Tuesday, October 8, 2024 5:50 AM To: Jacobson, Doug W [E CPE] Cc: tuhs at tuhs.org; groff at gnu.org Subject: Re: [TUHS] Re: Old troff files (1988-2007) [dropped Clem and Leah from CC] Hi Doug, At 2024-10-08T10:33:35+0000, Jacobson, Doug W [E CPE] wrote: > Using Groff (eqn+pic) + grap I was able to create a PDF of the book. > It took about 8 hours 8-O > part of which was figuring out the syntax differences. Oh, wall clock time including human engagement. That sounds really reasonable! I'm not sure I want to estimate how many hours I've put into revising groff's own documentation. Or ncurses's. Eight hours processing time on a modern machine (without inflooping) would be shocking to me. > He had divided the book up into a file for each page or two, so 100+ > files. I think he did that, so he did not waste paper since he had to > print out the pages to see if they looked right, no display to view > them. No PostScript or PDF preview program? I can think of a few: mupdf, evince, okular. Deri James (groff developer) can probably name a dozen. > It was not perfect but is good enough for the publisher to review. > The book is on filters (EE book) and is full of graphs, circuits, and > equations. He used pic to draw the circuits, which was amazing. This > was fun to take a forgotten manuscript written by a colleague and with > luck maybe getting it published while he is still alive. If the > publisher wants to publish it, I'm not sure how they will handle troff > files :) If you'd care to share it with me in my capacity as groff maintainer, I'd be interested to use it for unofficial regression testing. Alternatively, if you can't find an interested publisher, please consider asking the author (I assume he's also the copyright holder) to release it under a Creative Commons license so the whole world can enjoy. Also, so I can selfishly enjoy the pleasure of pointing to a sophisticated typeset work and saying, "look what groff can do!" ;-) (Just in case people aren't impressed enough with K&R or W. Richard Stevens.) Regards, Branden From douglas.mcilroy at dartmouth.edu Tue Oct 8 22:21:54 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 8 Oct 2024 08:21:54 -0400 Subject: [TUHS] groff_man.7.man.in: Some remarks and editorial changes for this man page Message-ID: The titled post reminds me of Ted Dolotta, a guru of PWB Unix, whose eye for editorial detail was unsurpassed. He could spot the difference between italic and roman periods at twenty paces. Bjarni is in good company. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Tue Oct 8 22:24:51 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 8 Oct 2024 08:24:51 -0400 Subject: [TUHS] Fwd: groff_man.7.man.in: Some remarks and editorial changes for this man page In-Reply-To: References: Message-ID: Once again I emailed the wrong list, so here it is again, sent to both, since it touches on both groff and history. Sorry, Doug ---------- Forwarded message --------- From: Douglas McIlroy Date: Tue, Oct 8, 2024 at 8:21 AM Subject: Re: groff_man.7.man.in: Some remarks and editorial changes for this man page To: TUHS main list The titled post reminds me of Ted Dolotta, a guru of PWB Unix, whose eye for editorial detail was unsurpassed. He could spot the difference between italic and roman periods at twenty paces. Bjarni is in good company. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Thu Oct 10 07:02:12 2024 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 09 Oct 2024 21:02:12 +0000 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: References: <20241005001433.7hukoga5bbbb3ygl@illithid> <20241005222207.eerdrgtsttmx42kb@illithid> <20241006151133.fbj6pmujpvuuo47d@illithid> Message-ID: I got a chuckle because apparently an old quote of mine is enshrined in the GROFF documentation (under the debugging section): Standard troff voodoo, just put a power of two backslashes in front of it until it works and if you still have problems add a \c. — Ron Natalie Thanks, G. Branden Robinson, for calling it to my attention. More nroff fun and games: My first job out of college was working on a restricted government project on RSX-11/M. I’d been doing various UNIX and n/troff stuff for years at JHU. The QA people decided to go all PWB on this project using SCCS etc… I knew that Denis Mumaugh at the NSA had written nroff macros to do classification markings automatically. I asked for a copy, but he couldn’t figure out how to get a tape to me. I reimplemented it myself. Originally, I had the idea of processing each marked paragraph into a diversion but that was problematic. I then just output the footer and then “reverse fed” the paper back to the top to add the top classification. Of course, you had to run your nroff via col to get it to print right. I also fixed the line printer spooler to catch classification markings and mark them pages appropriately as well. All this I did while waiting the 11 months for my ‘beyond TS’ clearance to arrive. Seems like everybody on the project failed their polygraph the first time. Examiner must have had a hard seat on the bus from the east coast. This was also the project where I had this exchange: Bernie: What’s all this Bell System crud in the editor? Me: It’s UNIX. It’s all Bell System crud. I walk around to his terminal and see this: $ 1 One Bell System. It works. $ 1 One Bell System. It works. Me: You’re not in the editor, Bernie. After that the /usr/bin/1 command was changed to echo “You’re not in the editor, Bernie.” From tuhs at tuhs.org Thu Oct 10 12:26:38 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 10 Oct 2024 02:26:38 +0000 Subject: [TUHS] BTL Involvement in Publication Imagery? Message-ID: So in the course of AT&T's involvement with UNIX, a number of different images and motifs have graced advertisements and covers of literature, among them: - Letter Blocks (V7 HRW manuals, Release 4.0 Starter Packages) - Criss-crossing grid lines on a black background (Release 5.0/SVR1) - Variations on an image of earth with UNIX superimposed (SVR3/SVR4) - Covers mirroring publication motifs of other AT&T products and literature (SVR2/SVR3) Did the folks actually involved in the production of UNIX have any influence on the choice of design motifs for such materials, or would those sorts of decisions have been largely in the hands of marketing folks several layers removed from the Labs? My understanding is that this sort of visual branding started in the early 80s, with the earliest example of a printed piece of UNIX literature outside of generic Bell Laboratories covers I'm aware of being the "Starter Package" documents featuring UNIX spelled out on four letter blocks in primary colors. Everything I've seen branded predating these 1981 publications is either 8.5/11 pages in a Bell Labs or Western Electric report cover or the form factor of the Release 3.0 manual using generic Bell Labs covers. I'm certainly intrigued if anyone has any recollection of any sort of visual motifs in play prior to 1981. - Matt G. From douglas.mcilroy at dartmouth.edu Fri Oct 11 01:41:34 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 10 Oct 2024 11:41:34 -0400 Subject: [TUHS] BTL Involvement in Publication Imagery? Message-ID: Unix folk were barely involved in the branding or advertising of the system. I recall that we got to proofread and edit the first Unix ad, but essentially nothing later. Nor did we contribute to the cover designs of the 7th edition trade verson or the 8th-10th in-house versions of the manual. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Oct 11 02:07:48 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 10 Oct 2024 16:07:48 +0000 Subject: [TUHS] BTL Involvement in Publication Imagery? In-Reply-To: References: Message-ID: On Thursday, October 10th, 2024 at 8:41 AM, Douglas McIlroy wrote: > Unix folk were barely involved in the branding or advertising of the system. I recall that we got to proofread and edit the first Unix ad, but essentially nothing later. Nor did we contribute to the cover designs of the 7th edition trade verson or the 8th-10th in-house versions of the manual. > Doug Thanks Doug (and Arnold Robbins in another stream)!  Doug I tossed up the cover scans you sent me some time ago here: https://wiki.tuhs.org/doku.php?id=publications:manuals:research The other pages under publications:manuals that I've filled out also have photographs of covers from my bookshelf. I figured what you described was the case, I don't know anything about the "face" of our stuff at work until someone gives me a logo to put on a site or application somewhere, I can't imagine most technical folks give a hoot what mask their products wear when they step out in the world. - Matt G.