From steffen at sdaoden.eu Sun Jun 1 08:00:11 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sun, 01 Jun 2025 00:00:11 +0200 Subject: [COFF] [TUHS] Wikipedia anecdotes - LLM generalizations [was On the unreliability of LLM-based search results In-Reply-To: References: <769a9c94-055d-4bdd-a921-3e154c3b492f@infinitecactus.com> <71936198-93c1-41bc-8a5f-41d95969da0c@technologists.com> <20250528145211.xBdhDA8m@steffen%sdaoden.eu> <0b4b5f13-9e45-4107-9904-86f6f238983f@case.edu> Message-ID: <20250531220011.OK6aDwFS@steffen%sdaoden.eu> Adam Thornton wrote in : |One could make a really good case right about now that: | |a) Vladimir Putin is doing his best to put the band back together, and Sorry, sorry to come back on a computer list. I stop thereafter. But, one can only press thumbs that it all gets through without further escalation; the desired block formation has resulted, at quite a price, but the river is still floating. If _there_ a really radical establishment would arise, though, and i mean really really (really!), if it were only the military, you know, there would be plenty of (pro) Russian(s) to protect in Transnistria; they had to sit in the cold without heating this winter, until a solution was found after months (and i *guess* and *bet* it is a very expensive and other-side-favouring solution); and their voted head is imprisoned, for, you know, in any case, much much less than a jumbo. You know; PJ Harvey sings On Battleship Hill's Caved in trenches A hateful feeling Still lingers Even now eighty years later So all that can be said is. Nothing changed, all the faults and idiocies happen over and over again. This is not "we have a liftoff", but we are plain as stupid as we always have been. (Btw. In this house where i work we have a middle-age Ukrainian Woman living here for many years, and a twin refugee couple. Thirty meters aways there is a German/Ukrainian (married) couple with lots of young children. More Ukrainians, Russians and Polish, all around here. And i always said i admire the men, and there are plenty, who deprive themselves from *that* government, even if "their country is calling" them. I only wish it would worked out that way for me, personally and environmentally, would i have lived during WWII. And the opposite for WWI.) |b) Republicans are acting as extremely willing Russian assets, so therefore |c) Associating them with the red of Soviet Communism is pretty accurate. The entire AI thing yet escaped me. I never looked and tested AI. I remember, on TUHS, and i think it was Steve Johnson who pretty much enthusiastically talked about "thousands of 8-bit processors" which understand a computer game "only by looking at the pixels" so good that after several hours they "beat the milk out of" it. From memory. That was fascinating, and my mind was busy looping over that on that evening, fwiw. I now have read that the Chinese approach they talk about uses that "8-bit" approach with the elder hardware that they are allowed to use, whereas the western guys use that super hardware, but nonetheless decline. Maybe that was what Steve Johnson was talking about. There are surely useful tasks for AI, when it is driven with green energy, and after is has been fully understood. Before that it is just another race that is raced at whatever cost there may be. The price is payed by the environment, and the grand children, but no longer further down the line. That is possibly the good thing about it. Exactly as said by the Club of Rome in 1972, and at least ever since also by the Catholic Church. As can be seen by reading the introductional words of Pope Franziskus "Laudati Si". De facto all this thread, and this entire email, is only about "structural disfunctioning" .. "that is unsuitable to guarantee respect for the environment". --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 als at thangorodrim.ch Mon Jun 2 01:23:57 2025 From: als at thangorodrim.ch (Alexander Schreiber) Date: Sun, 1 Jun 2025 17:23:57 +0200 Subject: [COFF] [TUHS] Wikipedia anecdotes - LLM generalizations [was On the unreliability of LLM-based search results In-Reply-To: <20250531220011.OK6aDwFS@steffen%sdaoden.eu> References: <769a9c94-055d-4bdd-a921-3e154c3b492f@infinitecactus.com> <71936198-93c1-41bc-8a5f-41d95969da0c@technologists.com> <20250528145211.xBdhDA8m@steffen%sdaoden.eu> <0b4b5f13-9e45-4107-9904-86f6f238983f@case.edu> <20250531220011.OK6aDwFS@steffen%sdaoden.eu> Message-ID: On Sun, Jun 01, 2025 at 12:00:11AM +0200, Steffen Nurpmeso wrote: > > There are surely useful tasks for AI, when it is driven with green > energy, and after is has been fully understood. What is currently being sold as "AI" is mostly LLM (Large Language Models), which are - to grossly simplify things - massive brute-force pattern matching engines. There are plenty of use cases where a well setup pattern matching engine is exactly what you need. My favourite example: SBB (Swiss Railways) uses "AI" (an in-house trained pattern matching model) to sift through the massive incoming stream of noise recordings from rail mounted vibration sensors, to identify (by matching known qualified patterns) those caused by damaged train carriage wheels. Additional support infrastructure then identifies train, carriage, wheel and notifies the owner/operator to fix the wheel - before gets worse and does more damage to the rails. There are lots of similar tasks where pattern matching engines are a great fit (e.g. optical QC on finished surfaces during manufacturing). If you try to use pattern matching engines for tasks that require knowledge, thinking, understanding (in short: a trained human mind), then you will be sorely disappointed while drowining in - potentially even superficially plausible sounding - bullshit (See Harry Frankfurt, "On Bullshit"). > Before that it is just another race that is raced at whatever cost > there may be. The price is payed by the environment, and the The current forecasts of both the use and the costs (some claim that we need to feed 90% of all power production to data centers eventually, which is clearly .. ill advised) of "AI" are looking wildly exaggerated. > grand children, but no longer further down the line. That is > possibly the good thing about it. Exactly as said by the Club of > Rome in 1972, and at least ever since also by the Catholic Church. Club of Rome did not see a lot of scientific developments coming that enabled growth way beyond their expectations. But then, predicting the future is never a sure business. That said, cheerfully burning down the planet for short-term profit is not exactly a sustainable business model, to put it politely. Kind regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison From steffen at sdaoden.eu Mon Jun 2 23:14:30 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 02 Jun 2025 15:14:30 +0200 Subject: [COFF] [TUHS] Wikipedia anecdotes - LLM generalizations [was On the unreliability of LLM-based search results In-Reply-To: References: <769a9c94-055d-4bdd-a921-3e154c3b492f@infinitecactus.com> <71936198-93c1-41bc-8a5f-41d95969da0c@technologists.com> <20250528145211.xBdhDA8m@steffen%sdaoden.eu> <0b4b5f13-9e45-4107-9904-86f6f238983f@case.edu> <20250531220011.OK6aDwFS@steffen%sdaoden.eu> Message-ID: <20250602131430.yQGXjEmw@steffen%sdaoden.eu> Alexander Schreiber wrote in : |On Sun, Jun 01, 2025 at 12:00:11AM +0200, Steffen Nurpmeso wrote: |> There are surely useful tasks for AI, when it is driven with green |> energy, and after is has been fully understood. | |What is currently being sold as "AI" is mostly LLM (Large Language |Models), which are - to grossly simplify things - massive brute-force |pattern matching engines. | |There are plenty of use cases where a well setup pattern matching engine |is exactly what you need. My favourite example: SBB (Swiss Railways) |uses "AI" (an in-house trained pattern matching model) to sift through |the massive incoming stream of noise recordings from rail mounted |vibration sensors, to identify (by matching known qualified patterns) |those caused by damaged train carriage wheels. Additional support |infrastructure then identifies train, carriage, wheel and notifies |the owner/operator to fix the wheel - before gets worse and does |more damage to the rails. That is possibly a great thing. I can assure everybody that Swiss freight trains pass by here in the many dozens / hundreds each day, and they are very well maintained. Most often they are quieter than even the much light German passenger trains. (Yes, there was that judgement in 2015 that the German (freight) trains have to become silent by December 2020, before that it was sheer unbelievable, especially during braking. And i still can recall the female DB speaker saying "und die Zeit brauchen wir auch" "and that time we really need". Unfortunately now the brakes are a bit more silent, but wheel imbalance and wheel bearings have massively increased (again).) I say possibly because i could imagine sensors in the locomotive should be capable to detect vibration irregularies? Not that i know. But vibrations is understated given the hammerings. Does this really need sound recordings? Interesting. |There are lots of similar tasks where pattern matching engines are |a great fit (e.g. optical QC on finished surfaces during manufacturing). | |If you try to use pattern matching engines for tasks that require |knowledge, thinking, understanding (in short: a trained human mind), |then you will be sorely disappointed while drowining in - potentially |even superficially plausible sounding - bullshit (See Harry Frankfurt, |"On Bullshit"). | |> Before that it is just another race that is raced at whatever cost |> there may be. The price is payed by the environment, and the | |The current forecasts of both the use and the costs (some claim that |we need to feed 90% of all power production to data centers eventually, |which is clearly .. ill advised) of "AI" are looking wildly exaggerated. I also do not use cryptocurrencies btw. I .. have heard Microsoft wants to buy a turned off nuclear plant to reactivate it, only for training AI? They also meddle within the "small nuclear plants" scene. I am thus against it. |> grand children, but no longer further down the line. That is |> possibly the good thing about it. Exactly as said by the Club of |> Rome in 1972, and at least ever since also by the Catholic Church. | |Club of Rome did not see a lot of scientific developments coming that |enabled growth way beyond their expectations. But then, predicting |the future is never a sure business. I would think at the 50th anniversary of the publication there was a profound review, and the pretty well got it. That was the great thing on Gore's campaign, in between the lines of that duel he mentioned it. With favouring "technology", of course, which i never believed will outgrow the bad effects. Not with that overall mental state, anyway. |That said, cheerfully burning down the planet for short-term profit |is not exactly a sustainable business model, to put it politely. Thank you. |Kind regards, | Alex. |-- |"Opportunity is missed by most people because it is dressed in overalls and | looks like work." -- Thomas A. Edison --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 stuff at riddermarkfarm.ca Mon Jun 9 03:59:08 2025 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Sun, 8 Jun 2025 13:59:08 -0400 Subject: [COFF] Article on bellmac-32 in Spectrum Message-ID: <83cb9923-527b-41da-2c16-e45d496d2d9d@riddermarkfarm.ca> From https://spectrum.ieee.org/bellmac-32-ieee-milestone "The group wrote its own version of Unix, with real-time capabilities to ensure that the new chip design was compatible with industrial automation and similar applications." Would that be in the archives? S From coff at tuhs.org Mon Jun 9 06:47:34 2025 From: coff at tuhs.org (segaloco via COFF) Date: Sun, 08 Jun 2025 20:47:34 +0000 Subject: [COFF] Article on bellmac-32 in Spectrum In-Reply-To: <83cb9923-527b-41da-2c16-e45d496d2d9d@riddermarkfarm.ca> References: <83cb9923-527b-41da-2c16-e45d496d2d9d@riddermarkfarm.ca> Message-ID: On Sunday, June 8th, 2025 at 10:59 AM, Stuff Received wrote: > From https://spectrum.ieee.org/bellmac-32-ieee-milestone > > "The group wrote its own version of Unix, with real-time capabilities to > ensure that the new chip design was compatible with industrial > automation and similar applications." > > Would that be in the archives? > > S If I had to assume this is probably related to DMERT and UNIX/RT. I'm unaware of any surviving code, but I have tossed some manuals up on my archive.org page for a few 2000's-era releases of the UNIX-RTR Generics for the 5ESS switches of the time. https://archive.org/details/5ess-switch-unix-rtr-operating-system-reference-manual-issue-10 Unfortunately I haven't secured any code from later UNIX-RTR releases either, just installation and maintenance curricula with some manuals and such thrown in. There is some early MERT stuff bumping around the archive but it predates the BellMAC-32/WE32000 and 3B by several years. - Matt G. From als at thangorodrim.ch Mon Jun 9 23:01:57 2025 From: als at thangorodrim.ch (Alexander Schreiber) Date: Mon, 9 Jun 2025 15:01:57 +0200 Subject: [COFF] [TUHS] Wikipedia anecdotes - LLM generalizations [was On the unreliability of LLM-based search results In-Reply-To: <20250602131430.yQGXjEmw@steffen%sdaoden.eu> References: <71936198-93c1-41bc-8a5f-41d95969da0c@technologists.com> <20250528145211.xBdhDA8m@steffen%sdaoden.eu> <0b4b5f13-9e45-4107-9904-86f6f238983f@case.edu> <20250531220011.OK6aDwFS@steffen%sdaoden.eu> <20250602131430.yQGXjEmw@steffen%sdaoden.eu> Message-ID: On Mon, Jun 02, 2025 at 03:14:30PM +0200, Steffen Nurpmeso wrote: > Alexander Schreiber wrote in > : > |On Sun, Jun 01, 2025 at 12:00:11AM +0200, Steffen Nurpmeso wrote: > |> There are surely useful tasks for AI, when it is driven with green > |> energy, and after is has been fully understood. > | > |What is currently being sold as "AI" is mostly LLM (Large Language > |Models), which are - to grossly simplify things - massive brute-force > |pattern matching engines. > | > |There are plenty of use cases where a well setup pattern matching engine > |is exactly what you need. My favourite example: SBB (Swiss Railways) > |uses "AI" (an in-house trained pattern matching model) to sift through > |the massive incoming stream of noise recordings from rail mounted > |vibration sensors, to identify (by matching known qualified patterns) > |those caused by damaged train carriage wheels. Additional support > |infrastructure then identifies train, carriage, wheel and notifies > |the owner/operator to fix the wheel - before gets worse and does > |more damage to the rails. > > That is possibly a great thing. I can assure everybody that Swiss > freight trains pass by here in the many dozens / hundreds each > day, and they are very well maintained. Most often they are > quieter than even the much light German passenger trains. Ah, but there is a difference: Swiss (SBB & Co.) passenger trains are very quiet by design - because they carry passengers (aka "cargo that can complain"). Swiss cargo trains are slowly getting there as the rolling stock is replaced, but they were _not_ designed to be quiet, as cargo tends not to complain. > I say possibly because i could imagine sensors in the locomotive > should be capable to detect vibration irregularies? Won't work, because a sensor in the locomotive will have a hard time recording noise from the end of the train that might be 100+m away. The setup described about grabs a vibration recording of every wheel as it passes the rail-mounted sensor and (with the help of other data sources) the system then can identify the train/carriage/wheel. > Not that > i know. But vibrations is understated given the hammerings. Does > this really need sound recordings? Interesting. Well, it's vibration recording .. which is what sound is, just at possibly a different frequency range that what humans hear. Kind regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison From steffen at sdaoden.eu Tue Jun 10 01:30:29 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 09 Jun 2025 17:30:29 +0200 Subject: [COFF] [TUHS] Wikipedia anecdotes - LLM generalizations [was On the unreliability of LLM-based search results In-Reply-To: References: <71936198-93c1-41bc-8a5f-41d95969da0c@technologists.com> <20250528145211.xBdhDA8m@steffen%sdaoden.eu> <0b4b5f13-9e45-4107-9904-86f6f238983f@case.edu> <20250531220011.OK6aDwFS@steffen%sdaoden.eu> <20250602131430.yQGXjEmw@steffen%sdaoden.eu> Message-ID: <20250609153029.hJtGx5K6@steffen%sdaoden.eu> Alexander Schreiber wrote in : |On Mon, Jun 02, 2025 at 03:14:30PM +0200, Steffen Nurpmeso wrote: |> Alexander Schreiber wrote in |> : |>|On Sun, Jun 01, 2025 at 12:00:11AM +0200, Steffen Nurpmeso wrote: |>|> There are surely useful tasks for AI, when it is driven with green |>|> energy, and after is has been fully understood. ... |>|There are plenty of use cases where a well setup pattern matching engine |>|is exactly what you need. My favourite example: SBB (Swiss Railways) |>|uses "AI" (an in-house trained pattern matching model) to sift through |>|the massive incoming stream of noise recordings from rail mounted |>|vibration sensors, to identify (by matching known qualified patterns) |>|those caused by damaged train carriage wheels. Additional support |>|infrastructure then identifies train, carriage, wheel and notifies |>|the owner/operator to fix the wheel - before gets worse and does |>|more damage to the rails. |> |> That is possibly a great thing. I can assure everybody that Swiss |> freight trains pass by here in the many dozens / hundreds each |> day, and they are very well maintained. Most often they are |> quieter than even the much light German passenger trains. | |Ah, but there is a difference: Swiss (SBB & Co.) passenger trains |are very quiet by design - because they carry passengers (aka |"cargo that can complain"). Swiss cargo trains are slowly getting |there as the rolling stock is replaced, but they were _not_ designed |to be quiet, as cargo tends not to complain. Ah -- trains have an inside? Interesting. Hmmm, talking at least a decade. SBB and also, i hate private companies, BLS. Mostly i guess chemicals via tank wagons, and containers, lots of containers from an Austrian haulier. I mean, it is only snippets of time, when i am wandering in between, so numbers are scaled at bit, but from impressions of all day and night times. Here pass by quite a lot, Swedish double-deckers, French TGV (they renamed them, but slow german crawling..), German DB ICE of all sorts, of course, but still normal ICs with mostly 2nd class, for me it is Schnellzug and Eilzug but that cannot be helped, wonderful Austrian trains with two red locomotives (great ones which still aimed in record breaking performance, and deliver for the quarter of a century), and in between them dove gray waggons with red roof -- i love these trains, i think four times a day, surely good cake and coffee within, their Nightjets. BASF trains with Diesel and not FuelCell technology; we are back. And lots and lots and lots of private freight train companies which surely do not pay enough for being able to use the rails, just for the sake of allowing "competition" .. at the cost of the people, effectively. And for ruining the name of the DB, which actually pays for it. Tax payers that is. Loudest passenger train thinkable is by the way FlixTrain who seems to run generators or what at one pair, but their bearings and wheels scream to heaven "i have to live a long life" or what. They surely spend not enough for using the rails, let alone for the ear pain i have to suffer when that shit passes. Whatever. Luckily they pass by quick and do not brake, i cannot comment on their brakes. Swiss freight trains run smoothly and to a very large extend very silent, and they break silent, too. (Squealing happens at times, for practically anything. All the development for isolation, aka decoupling, and materials technology aside.) So, that is that. |> I say possibly because i could imagine sensors in the locomotive |> should be capable to detect vibration irregularies? | |Won't work, because a sensor in the locomotive will have a hard time |recording noise from the end of the train that might be 100+m away. Mostly americans on this list i presume, and they still remember the Wild West listen-at-the-rails trick, for whatever purpose. Our rail bus with its diesel engine btw does not use engine bearings. "Boy the rail hums" quite a bit in advance. So to say. |The setup described about grabs a vibration recording of every wheel |as it passes the rail-mounted sensor and (with the help of other data |sources) the system then can identify the train/carriage/wheel. Well, .. sure. I mean, in summertime i would consider talking the job for an hour at weekdays, but i need tea, and i surely would not be as exact. For freight trains in particular, they are put together at classification yards, often at little hills so that they start rolling after some initial moment. You know. In Germany we say (or used to say, when we were still Germans) "Where there is a will, there is a Way". Something like that.. |> Not that |> i know. But vibrations is understated given the hammerings. Does |> this really need sound recordings? Interesting. | |Well, it's vibration recording .. which is what sound is, just at possibly |a different frequency range that what humans hear. It seems to me in rails it ranges further than in the air. |Kind regards, | Alex. |-- |"Opportunity is missed by most people because it is dressed in overalls and | looks like work." -- Thomas A. Edison --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 coff at tuhs.org Mon Jun 23 09:40:30 2025 From: coff at tuhs.org (Warren Toomey via COFF) Date: Mon, 23 Jun 2025 09:40:30 +1000 Subject: [COFF] C with Improvements :-) Message-ID: I love C; I think it's a great language. But there are things I wish were different in C, and I wish it had less undefined behaviour. I've been having fun designing a language called 'alic' to do the above. I feel proud enough to mention it here. Have a look at the doc which compares it to C, if you are interested: https://github.com/DoctorWkt/alic/blob/main/docs/overview.md Rather than talk about alic, reply with what you like/hate about your favourite language! Cheers, Warren From dave at horsfall.org Mon Jun 23 11:25:22 2025 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 23 Jun 2025 11:25:22 +1000 (EST) Subject: [COFF] C with Improvements :-) In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025, Warren Toomey via COFF wrote: [...] > Rather than talk about alic, reply with what you like/hate about your > favourite language! This will probably get me tarred and feathered, but I have a couple of gripes about C: Declaration of pointers: these days I prefer to write int* p; instead of int *p to make it clear that "p" is a pointer to an int. Heck, I've even seen such nonsense as this (fixed width font required!): int *a; int b; to make the names line up. And OK, not syntactical, but I loathe the dangling "{" as typified by K&R: if (...) { ... } All the arguments I've seen for this style are utterly specious, especially the one about saving a line on the screen; if so then why not move the "}" up to the end of the preceding statement and save another precious line? -- Dave From lm at mcvoy.com Mon Jun 23 11:37:27 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 22 Jun 2025 18:37:27 -0700 Subject: [COFF] C with Improvements :-) In-Reply-To: References: Message-ID: <20250623013727.GK3104@mcvoy.com> On Mon, Jun 23, 2025 at 11:25:22AM +1000, Dave Horsfall wrote: > On Mon, 23 Jun 2025, Warren Toomey via COFF wrote: > > [...] > > > Rather than talk about alic, reply with what you like/hate about your > > favourite language! > > This will probably get me tarred and feathered, but I have a couple of > gripes about C: > > Declaration of pointers: these days I prefer to write > > int* p; > > instead of > > int *p Dave, you are not alone, I do the same thing. So you can't do int* p, i; you have to do int* p; int i; And I think it is much more clear. This is sort of my high horse but I pushed my people for 18 years to make the code more clear. I told people over and over, you write once or twice, you read many, many times. So if it is really hard to write code clearly, but it is really easy to read? Do that. For what it is worth, when I manage to get someone to read the BitKeeper source, the reaction is that is really good C code. I'm proud of that. --lm From peter.martin.yardley at gmail.com Mon Jun 23 11:52:02 2025 From: peter.martin.yardley at gmail.com (Peter Yardley) Date: Mon, 23 Jun 2025 11:52:02 +1000 Subject: [COFF] C with Improvements :-) In-Reply-To: References: Message-ID: <71781470-BC96-4AFE-8DD5-5065A44F726F@gmail.com> Yes, I hate the dangling brace I line my braces up with the associated code block … if (…) { blah blah blah; } And I always put my variable declarations on separate lines. > On 23 Jun 2025, at 11:25 am, Dave Horsfall wrote: > > On Mon, 23 Jun 2025, Warren Toomey via COFF wrote: > > [...] > >> Rather than talk about alic, reply with what you like/hate about your >> favourite language! > > This will probably get me tarred and feathered, but I have a couple of > gripes about C: > > Declaration of pointers: these days I prefer to write > > int* p; > > instead of > > int *p > > to make it clear that "p" is a pointer to an int. Heck, I've even seen > such nonsense as this (fixed width font required!): > > int *a; > int b; > > to make the names line up. > > And OK, not syntactical, but I loathe the dangling "{" as typified by K&R: > > if (...) { > ... > } > > All the arguments I've seen for this style are utterly specious, > especially the one about saving a line on the screen; if so then why not > move the "}" up to the end of the preceding statement and save another > precious line? > > -- Dave .1.3.6.1.4.1.8852.4.2 Peter Yardley peter.martin.yardley at gmail.com From lm at mcvoy.com Mon Jun 23 12:06:21 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 22 Jun 2025 19:06:21 -0700 Subject: [COFF] C with Improvements :-) In-Reply-To: <71781470-BC96-4AFE-8DD5-5065A44F726F@gmail.com> References: <71781470-BC96-4AFE-8DD5-5065A44F726F@gmail.com> Message-ID: <20250623020621.GL3104@mcvoy.com> On Mon, Jun 23, 2025 at 11:52:02AM +1000, Peter Yardley wrote: > Yes, > > I hate the dangling brace I line my braces up with the associated code block ??? > > if (???) > { > blah blah blah; > } I personally hate that, not sure if you are demonstrating how not to do it or what? I do if (whatever) stmt; or if (whatever that is more complex) { stmt; stmt; stmt; } I also do if ((whatever is complex) || (or even more complex) || (something that wouldn't fit in 80 columns) { stmt; stmt; stmt; } I've mapped ^A in vi to be that 4 space indent, for 4 decades. The if (whatever) { stmt; } is, I believe, GNU style and it just sucks. GNU C is awful. But when I did the df/du/ls -h stuff I wrote it in that style, it's their house, you abide by their rules. Fun fact, Stallman hated me so much he rewrote that stuff so I wasn't in their version history. From g.branden.robinson at gmail.com Mon Jun 23 13:06:03 2025 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sun, 22 Jun 2025 22:06:03 -0500 Subject: [COFF] C with Improvements :-) In-Reply-To: <20250623020621.GL3104@mcvoy.com> References: <71781470-BC96-4AFE-8DD5-5065A44F726F@gmail.com> <20250623020621.GL3104@mcvoy.com> Message-ID: <20250623030603.ssy6ameym2nclfhf@illithid> At 2025-06-22T19:06:21-0700, Larry McVoy wrote: > The > > if (whatever) > { > stmt; > } > > is, I believe, GNU style and it just sucks. Sort of. Official GNU style is like that, but uses 2 spaces instead of four.[1] Fortunately for me I seldom bump my head into this issue in groff maintenance because that project started life in C++ early on (ca. 1989), and I guess was exempted from the GNU Coding Standards due to the different implementation language. It mostly looks like Stroustrup's style. C++ was pretty young back then. James Clark was a brave guy. I've cracked the whip on groff's code style in other ways.[2] > GNU C is awful. But when I did the df/du/ls -h stuff I wrote it in > that style, it's their house, you abide by their rules. Fun fact, > Stallman hated me so much he rewrote that stuff so I wasn't in their > version history. That could also have been the case if you didn't execute copyright assignment paperwork. However, GNU is no longer militant about that.[3] Regards, Branden [1] https://www.gnu.org/prep/standards/standards.html#Formatting [2] Here are some recurring themes in my commit messages. * Mark as `static` symbols that don't need external linkage. * Mark as `const` objects that shouldn't change. * Spell null character using the C/C++ language literal for expressing it. * Spell null pointer constant the idiomatic C++98 way (`0`) instead of as `NULL`. * Reorder equality comparisons to avoid inadvertent lvalue assignment. * Explicitly compare value of pointer type to null pointer literal instead of letting it pun down to a Boolean. Except for the `const` one, you got all of these for free (or enforced by the compiler) in Ada 83. C's typing is so weak that I have started calling it B++ for the sake of starting arguments^Wdiscussions. Rust's "let mut", making you say "mut"(able) was a good idea. Good for concurrency. Here's another recent gripe. * Rename `none` enumeration constant to `none_tag` for conformity with other constants in the same (anonymous) enum. C++ enums weren't name-spaced or properly type-checked until C++11, and C's still aren't. (Ada had proper sum types back in 1983.) Here's a GNU Coding Standards prescription I back 100%: "When you split an expression into multiple lines, split it before an operator, not after one." I haven't made up my mind which style I prefer for operator overloads in C++. `operator+` looks ugly and `operator +` looks misleading. Maybe both suck, because C++ sucks. Overloading bit shifting operators to implement stream I/O was a repellent choice, combining an early, somewhat understandable showboating enthusiasm for a powerful language feature with C programmers' elitist preference for inscrutable sigils. "foo< From peter.martin.yardley at gmail.com Mon Jun 23 17:40:35 2025 From: peter.martin.yardley at gmail.com (Peter Yardley) Date: Mon, 23 Jun 2025 17:40:35 +1000 Subject: [COFF] C with Improvements :-) In-Reply-To: <20250623020621.GL3104@mcvoy.com> References: <71781470-BC96-4AFE-8DD5-5065A44F726F@gmail.com> <20250623020621.GL3104@mcvoy.com> Message-ID: <4641ABCE-84BA-48F1-9A9C-26132EE3F9AB@gmail.com> Hi, I just had a quick search of C coding styles and found where I picked up that style … https://en.wikipedia.org/wiki/Indentation_style Whitesmiths. I spent some of my early career tutoring students in embedded programming classes using C and assembler. We used the Whitesmiths cross compiler for the 8080. I ported bits of a C library from somewhere, prolly fragrantly disregarding copyright, and we had students writing C code on Intel development boards. Interrupts, basic device drivers, semaphores and in the end a basic real time executive. > On 23 Jun 2025, at 12:06 pm, Larry McVoy wrote: > > On Mon, Jun 23, 2025 at 11:52:02AM +1000, Peter Yardley wrote: >> Yes, >> >> I hate the dangling brace I line my braces up with the associated code block ??? >> >> if (???) >> { >> blah blah blah; >> } > > I personally hate that, not sure if you are demonstrating how not to do it or > what? > > I do > > if (whatever) stmt; > > or > if (whatever that is more complex) { > stmt; > stmt; > stmt; > } > > I also do > > if ((whatever is complex) || (or even more complex) || > (something that wouldn't fit in 80 columns) { > stmt; > stmt; > stmt; > } > > I've mapped ^A in vi to be that 4 space indent, for 4 decades. > > The > > if (whatever) > { > stmt; > } > > is, I believe, GNU style and it just sucks. GNU C is awful. But when I > did the df/du/ls -h stuff I wrote it in that style, it's their house, > you abide by their rules. Fun fact, Stallman hated me so much he rewrote > that stuff so I wasn't in their version history. .1.3.6.1.4.1.8852.4.2 Peter Yardley peter.martin.yardley at gmail.com From douglas.mcilroy at dartmouth.edu Mon Jun 23 23:29:42 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Mon, 23 Jun 2025 09:29:42 -0400 Subject: [COFF] C with Improvements :-) Message-ID: > Overloading bit shifting operators to implement stream I/O was a repellent choice Without commenting on this judgement, I can tell how the convention came about in a casual conversation. I was perhaps the earliest serious experimenter with C++ overloading, for a constructive solid geometry package in which arithmetic operators were overloaded for matrices and vectors, and boolean operators were overloaded for union and intersection of geometric objects. I've forgotten how object subtraction (e.g. to drill a hole) was represented. Sadly, the symbol vocabulary for overloading was fixed, which meant that two vector products (dot and cross) vied for one operator. Joe Condon put me onto an interesting analog of quotient and remainder in 3D. The quotient. of two vectors, q=a/b is the ratio of the projection of a onto b to b and the remainder r=a%b is the component of a perpendicular to b, The usual quotient-remainder formula holds::a = q*b + r. Once, while discussing some detail of overloading, Bjarne remarked that he'd like to find an attractive notation for stream IO, which printf certainly is not. << and >> immediately popped into my mind. They've been in the language ever since. Equally casually, there was no discussion about the set of operator symbols, so C++ did not come up with a convention for symbol syntax, such as that of Haskell. Doug From stuff at riddermarkfarm.ca Tue Jun 24 02:18:07 2025 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Mon, 23 Jun 2025 12:18:07 -0400 Subject: [COFF] C with Improvements :-) In-Reply-To: <20250623020621.GL3104@mcvoy.com> References: <71781470-BC96-4AFE-8DD5-5065A44F726F@gmail.com> <20250623020621.GL3104@mcvoy.com> Message-ID: On 2025-06-22 22:06, Larry McVoy wrote (in part): > I do > > if (whatever) stmt; > > or > if (whatever that is more complex) { > stmt; > stmt; > stmt; > } > > I also do > > if ((whatever is complex) || (or even more complex) || > (something that wouldn't fit in 80 columns) { > stmt; > stmt; > stmt; > } +1 (That was in our company coding style, too.) S. From steffen at sdaoden.eu Tue Jun 24 06:44:04 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 23 Jun 2025 22:44:04 +0200 Subject: [COFF] C with Improvements :-) In-Reply-To: References: Message-ID: <20250623204404.b4zsgQdh@steffen%sdaoden.eu> Warren Toomey via COFF wrote in : |I love C; I think it's a great language. But there are things I wish |were different in C, and I wish it had less undefined behaviour. | |I've been having fun designing a language called 'alic' to do the above. |I feel proud enough to mention it here. Have a look at the doc which |compares it to C, if you are interested: |https://github.com/DoctorWkt/alic/blob/main/docs/overview.md | |Rather than talk about alic, reply with what you like/hate about |your favourite language! Sequence point stuff; i like alic's Argument values are evaluated from left to right. Maze of long argument lists; i like alic's you can name arguments to a function. Bit enumerations (i heard ringing newest clang has something). And extended (bit) enumerations, where a subclass / "superclass user" wants to reuse bit space in some "upper class bit carrier": ie, its first value must start after the highest bit/value of the enum it builds upon. But when to stop? On one-before signed max, 32-bit / 64-bit? Error on excess. Exceptions? It was a mess in C++; i had a base exception class with optional (compile-time) documentation string, and also debug-only file name and line number info. The doc string was optionally (compile-time) passed via a translation macro. What a preprocessor mess! (The sizeof() was always the same. That is 32 byte on 64-bit to init, without language support; i dreamed of carry-flag set or something, on error. All x86 by then.) To mention that FreeBSD just recently added (compile-time) support for descriptive error strings in the kernel, beyond the usual errno. I would assume this can end up as a tremendous debugging help for developers, but also users. Too many things end up as EINVAL, etc. Exceptions could be the better concept. Finally{} i remember a article series conclusion from German Linux Magazine, about 20++ years ago. Btw when i see "array index access is always checked" i am sure i will add a vector class etc with unchecked access, for the prevalent (imho) case that i know i will not excess boundaries. Or at maximum !NDEBUG assertions. I hate unwanted optimizations. Loops that get unrolled, non-inline functions that get inlined, code that gets entirely removed (leading to solutions like explicit_bzero(3)), also the usual "Who's afraid of a big bad optimizing compiler?" stuff. On the other hand __attribute__()ing like grazy is also nuts. I like the ({ block; }) extension of GNU C; i used it for translations for example, you can inject a block in the right hand side of an assignment, like 'char const *x = _("xy");'. It surely can be overused, but that thing can lead to visually better code, and that i can grasp more easily when iterating it. alic has {} blocks in for(;;) i had seen. I do not understand why they all go grazy over lambda's and callable blocks, but such an easy right hand side block there still not is. Simply being able to create {} blocks on a right hand side is easy. Btw i like the difference in between -> and .. But it is ok. If you then come to indirections like "object ***oppp" you drifted to the twilight zone anyhow. (Or not.) For translations the C++ << I/O thing was a terrible misfit. I like the new-style "{fmt2#config} {fmt1#config}" things --- good decision to not use va_list etc i think!, but if i would create a language, providing a random-access array would then be it, without consumation that is, you know? For example va_count(), va_arg(u32, IDX). One could get away with va_pop() or va_shift() if you want a consuming iterator. Languages possibly should support simple documentation text blocks that their tools then could dump in some generic format, yaml alike, or json alike, or whatever. Plain text. You know. Everybody could take that output and do whatever with it, without having to write a language-specific parser. I use doxygen now, it fails for EXPORT BITENUM(u32,su_idec_state) su_idec(...); how can it be made clear otherwise what it is, and what exact integer should be used. It also requires anything to be tagged, but i often want "fun1;fun2;fun3; DOCU FOR ALL" (or DOCU first). Around Y2K+ there was a free software string C++ library which did so, using TeX commands inside the DOC. Output looked good. I cannot find it on the internet, i think his name was Sauter. These are absolutely fascinating projects of yours, both, compiler, and language! How can you all do such great projects, in my friend nosh and cleanup circles i hardly find time to read the emails. (But even if not, operating systems, compilers, languages, .. wow!) Journeys -- i likely will find easier access than i ever could with Knuth's web writings. --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) | |During summer's humble, here's David Leonard's grumble | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure | |Farewell, dear collar bear From g.branden.robinson at gmail.com Tue Jun 24 07:01:48 2025 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Mon, 23 Jun 2025 16:01:48 -0500 Subject: [COFF] C with Improvements :-) In-Reply-To: References: Message-ID: <20250623210148.25et3dituozijb2i@illithid> Hi Doug, At 2025-06-23T09:29:42-0400, Douglas McIlroy wrote: > > Overloading bit shifting operators to implement stream I/O was a > > repellent choice > > Without commenting on this judgement, I can tell how the convention > came about in a casual conversation. > > I was perhaps the earliest serious experimenter with C++ overloading, > for a constructive solid geometry package in which arithmetic > operators were overloaded for matrices and vectors, and boolean > operators were overloaded for union and intersection of geometric > objects. I've forgotten how object subtraction (e.g. to drill a hole) > was represented. Sadly, the symbol vocabulary for overloading was > fixed, which meant that two vector products (dot and cross) vied for > one operator. Joe Condon put me onto an interesting analog of quotient > and remainder in 3D. The quotient. of two vectors, q=a/b is the ratio > of the projection of a onto b to b and the remainder r=a%b is the > component of a perpendicular to b, The usual quotient-remainder > formula holds::a = q*b + r. Thanks for throwing considerable light on what prompted my heat. I think your point about the overloadable symbol vocabulary being fixed is a salient one, and puts a burden on overloading from a language design and readability perspective that might not be sustainable. However, I may be biased...while I'm accepting of function overloading, I've never seen an implementation of operator overloading that pleased me. I tell myself it's because I just haven't met the right language yet, and that once I do I can thus claim an objective stance, but maybe I'm just personally allergic to operator overloading. I already think it's a bad idea to have "/" represent both integer and floating-point division, and just within the past week we fixed a groff bug--that I introduced--arising from the ambiguity.[1] (You guessed it--Ada doesn't do this.) If I were doing what Warren's done and devising my own riff on C, then apart from stealing shamelessly from Ada, I'd use keywords for all integer math operations: "add", "sub", "mul", "div", "mod" (and maybe Ada's "rem", too). To any C jockeys inclined to whine, I'd point out that these are strongly reminiscent of the assembly language mnemonics into which the operations will translate anyway, which _should_ harmonize with their mantra that they program "close to the metal". That would reserve the arithmetic operator symbols for floating-point operations, which is good because it's familiar from handheld calculators (or, to update my superannuated notions, calculator apps on handheld phones). Your story about needing to assign distinct operators to two different sorts of "product" is, I think, a strong one against operator overloading. When programming we must cope with sundry varieties of mathematical structures. I remember being intrigued when I learned that the inner product (dot product) generalizes to a wide variety of spaces[2] but the cross product does not. The cross product is meaningful only in a 3-space. (Maybe one with an orthonormal basis to boot; I haven't thought about this stuff in 10+ years.) It seems that a lot of what we call "mathematical maturity" amounts to awareness that much of what we were taught to assume as true in primary or secondary school, or even most of an undergraduate program outside the math department, was a fib.[3] In that sense, we have Bolyai and Lobachevsky, and later Gödel, among other celebrated thinkers, to thank for maturing us. > Once, while discussing some detail of overloading, Bjarne remarked > that he'd like to find an attractive notation for stream IO, which > printf certainly is not. << and >> immediately popped into my mind. > They've been in the language ever since. Oh, no! I have you to blame? :-O Almost anything looks better than printf (anything but Fortran's "FORMAT"), and that may have been unfortunate. > Equally casually, there was no discussion about the set of operator > symbols, so C++ did not come up with a convention for symbol syntax, > such as that of Haskell. I won't claim expertise with Haskell (I've yet to use it in anger), but what exposure I've had to it suggests a carefully thought out language. Our profession seems reluctant to accept new languages with that property. We prefer JavaScript and PHP. :-| Regards, Branden [1] https://lists.gnu.org/archive/html/groff-commit/2025-06/msg00110.html [2] "inner product spaces", natch ;-) [3] One reason I'm so enthusiastic about linear algebra as a subject--I think we should teach it to everyone, not even joking--is that delivers a lot of benefit to one's critical thinking even as its prerequisites are modest; all you really need is introductory algebra and none of its weirder topics. With that small armamentarium you can start learning how to reason about huge classes of problems, and to do so in a "mature" way: that is, no longer accepting models that are handed down on stone tablets, but devising one's own, explicitly articulating one's assumptions, seeing what properties result, and comparing them critically to the phenomenon under study. You start with easy things like, "did I select the correct number of (independent) variables to model this problem?", and it gets more fun from there. Recognizing when a problem _can't_ be modeled in a linear space is a benefit that can't be overstated. But only familiarity with linear algebra can equip you to make that judgment. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jnc at mercury.lcs.mit.edu Tue Jun 24 07:17:32 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 23 Jun 2025 17:17:32 -0400 (EDT) Subject: [COFF] C with Improvements :-) Message-ID: <20250623211732.B790618C075@mercury.lcs.mit.edu> > From: Dave Horsfall > This will probably get me tarred and feathered, but I have a couple of > gripes about C Your points are not about C's semantics, and only sort of about C's syntax; they are more formatting. In fact, it would be really easy to write something to switch a module betweeen your preferred formatting, and 'standard' (for the local value of 'standard') formatting. A minor comment about your first point. I was just reading some old code of mine, and ran across a procedure declaration of the form: foo(string, special) char *string, special; Your preferred form (_without_ changing C's _formal_ syntax) that puts the indirection level with the type has the problems that i) it would make the declaration above potentially confusing (unless one mentally edits the line back to 'classic' C formatting as one reads it; is 'special' a 'char', or a 'pointer to char'; the 'classic' form is quite clear about that); ii) one can only list a single variable per line without changing C's syntax. E.g. (in standard C) if you want to have two pointers declared on one line one would have to say (in standard C): char* ptra, *ptrb; In short, there are good reasons to associate the indirection level with the variable (standard C), and not with the type (yours). Although I gather that you'd probably like to change C's formal syntax, to associate the indirection level with the type, not with the variable. So one could say: char* ptra, ptrb; One could no longer, though, say: char *string, special; One change I would have made to C, in the past, was to add valof/resultis (from BCPL; lacking in C). That's because C macros that return values _have_ to use _only_ expressions (e.g. ((expr0) ? expr1 : expr2)), not more complex code like 'case' (which valof/resultis would let you do). Of course, modern compilers do optimizations that make that a lot less necessary. The thing I would still add to C is condition handling (although I have written assembler packages that added a very efficient one to C without changing the C language; and JTW and someone did a less capable one entirely in C - mine had unwind protects). Explaining why condition handlers are a good thing I don't have the time/energy to do right now, but I can explain it if people want to hear it. Noel From norman at oclsc.org Tue Jun 24 11:08:04 2025 From: norman at oclsc.org (Norman Wilson) Date: Mon, 23 Jun 2025 21:08:04 -0400 (EDT) Subject: [COFF] [TUHS] Texas UNIX Users Conference 1981 Message-ID: This note gets a bit COFF-y; please redirect any replies to that list. USENIX Summer 1981, in Austin TX. First USENIX conference I ever attended, and the first to which I travelled by train-- mostly. I was somewhat shy about travelling in those days, but my Caltech colleague Mark Bartelt talked me into going, and suggested going by train. Except by the time I booked the trip there was space available only from Los Angeles to San Antonio and back, not onward from San Antonio to Austin. But in those days I did a bit of cycle touring, often in the company of my friend Brian Foster. Brian was also a co-worker at the time, and was interested in attending too. So we decided to travel together by train (in coach) to San Antonio, arriving around 05h30, and spent the rest of that day cycling, mostly up the frontage roads beside I-35, to Austin. After the conference we cycled back, mostly at night, which was somewhat spooky (I remember seeing a thunderstorm off on the horizon but we didn't get rained on) but saved us a second dose of sunburn. They checked into a motel for a day and a night until the return train came through at 02h55. I have gone by train to nearly every other conference I've attended since, but never again have I cycled. It was a fun ride but a harder one than expected. In those days of paper mapes, we visited the Caltech geography department and plotted out what looked like a fairly smooth route, with a slow but steady climb. The topo map we used had a resolution of 50' altitude. Evidently the constant, sometimes steep hills between San Antonio and Austin are all no more than 49' tall. It was a good conference too. One memory that sticks in my head was Jim Joyce using Tinker Toys as a metaphor for connecting Unix tools together. Norman Wilson Toronto ON From crossd at gmail.com Tue Jun 24 22:07:16 2025 From: crossd at gmail.com (Dan Cross) Date: Tue, 24 Jun 2025 08:07:16 -0400 Subject: [COFF] C with Improvements :-) In-Reply-To: References: Message-ID: On Mon, Jun 23, 2025 at 9:36 AM Douglas McIlroy wrote: > > Overloading bit shifting operators to implement stream I/O was a repellent choice > > Without commenting on this judgement, I can tell how the convention > came about in a casual conversation. Thank you for this interesting historical note, Doug. Personally, I've never found the `<<` or `>>` syntax troubling when using C++ IO streams, and the type safety is a notable improvement over printf/scanf et al. What I _do_ find troubling is that the stream itself is a stateful, mutable object, so to perform any sort of non-trivial formatting, one has to inject special control messages into the stream using the same syntax; these do compose (usually), but they're persistent, are overly verbose, and cumbersome to use in practice. Here, the concision of printf's "little language" of formatting verbs is superior, and far more readable. It seems obvious in retrospect that C++ would have been better off if augmented with a small hierarchy of "formatting objects" that encoded the various formatting directives, exposing a printf-like language, as a constructor argument, along with the datum. The stream would consume these for the purposes of formatting that specific datum, but then discard them, as opposed to holding onto whatever state they induced. Google eventually did something like this, which kinda-sorta made it out in the `absl::StrFormat` library, but it took far too long (and Google, for many years, explicitly forbade using iostreams in C++ code for dubious reasons). More recent languages have introduced happy mediums. I personally like the way that Rust handles this; `println!` is a macro, and interprets the format string at compile time, ensuring whatever it specifies matches its arguments vis types, visibility, safety, etc. But at the call site, it resembles the concision of printf via a small formatting language. - Dan C. > I was perhaps the earliest serious experimenter with C++ overloading, > for a constructive solid geometry package in which arithmetic > operators were overloaded for matrices and vectors, and boolean > operators were overloaded for union and intersection of geometric > objects. I've forgotten how object subtraction (e.g. to drill a hole) > was represented. Sadly, the symbol vocabulary for overloading was > fixed, which meant that two vector products (dot and cross) vied for > one operator. Joe Condon put me onto an interesting analog of quotient > and remainder in 3D. The quotient. of two vectors, q=a/b is the ratio > of the projection of a onto b to b and the remainder r=a%b is the > component of a perpendicular to b, The usual quotient-remainder > formula holds::a = q*b + r. > > Once, while discussing some detail of overloading, Bjarne remarked > that he'd like to find an attractive notation for stream IO, which > printf certainly is not. << and >> immediately popped into my mind. > They've been in the language ever since. > > Equally casually, there was no discussion about the set of operator > symbols, so C++ did not come up with a convention for symbol syntax, > such as that of Haskell. > > Doug