Date: Mon, 31 Jul 2023 09:34:56 +1000 From: George Michaelson <ggm(a)algebras.org> [...] Execute on read is just awful. But, now we have HTML to track "they read it" through URL fetch. And then the utterly disastrous: JavaScript. It should be *eliminated* from the WWW as the gross security violation it is. "don't run software from strangers",

Erik Fair

On 7/30/23 7:26 PM, Warner Losh wrote: Wasn't that "Java" proper and not "JavaScript"?

Grant. . . .

On Sun, Jul 30, 2023, 5:59 PM Erik E. Fair <fair-tuhs(a)netbsd.org> wrote: Write once, run everywhere.

I've seen some cynical people render it as "write once, run away".

Date: Mon, 31 Jul 2023 09:34:56 +1000 From: George Michaelson <ggm(a)algebras.org> [...] Execute on read is just awful. But, now we have HTML to track "they read it" through URL fetch. And then the utterly disastrous: JavaScript. It should be *eliminated* from the WWW as the gross security violation it is. "don't run software from strangers", Erik Fair

Even simple spew could be dangerous: who remembers "intelligent terminal" transmit-back codes and the mischief those caused?

ASCII Bombs?   Like my Letter Bomb Transport Protocol (LBTP)? https://groups.google.com/g/net.followup/c/OJBALbzTq4w/m/LoxMnbz0bwMJ

It seems to have lost something in the formatting (the leading spaces were all removed).

This is my chief gripe with Python, although on the flip side Python isn't the right language anyway for most scenarios where I use whitespace/indentation to imply structure the language itself can't articulate. It's meant for mainly functional programming as I understand it so the structure does enforce some stylistic practices conducive to good functional programming. Still a shame to force a particular style approach by default rather than just strongly suggest it. What strikes me particularly odd about the Python case is that its not like that space-sensitivity evolved out of the same line of reasoning as the compulsory spacing in FORTRAN, COBOL, etc. It seems mainly to be a way to operate without code blocks, with the "blocks" being implied by indentation rather than braces, parens, or some other delimiter. In UNIX of course we have our own little variation on this problem with make(1) and the need to tab out the rule definition. I seem to recall reading somewhere (perhaps Doug's McIlroy's UPM excerpts) that that Stu Feldman considered undoing that but there were already users who that would've caused trouble for, so make's early, entrenched adoption stymied attempts at the time to rectify this. Anyone with better details feel free to correct me. - Matt G. P.S. This answer can be off list or spin off a separate thread for make junkies, but did any AT&T or BSD revision of make(1) support rule names coming from variables rather than explicitly entered? For instance: $(BIN): $(OBJS) $(CC) $(LDFLAGS) -o $(BIN) $(OBJS) $(LIBS) I used to use this in makefiles but at some point, I think with one of the BSDs, it balked at the idea of a variable rule name and so it fell out of my practice in trying to avoid GNUisms.

It's been a while but I feel like I ran through and tried this on V7, System III, and PDP-11 System V and all of them were unhappy about that construct. I can try and get on the LCMs 3B400 later to see what SVR3 does. I don't remember which of the BSDs (if not multiple) I ran into that issue on initially, but I can't imagine one of the major streams would work that in without the other two wanting to copy their notes.

Maybe an alternative question is if folks are aware of make implementations besides GNU that *do* support that sort of thing.

Not true. It has some neat functional features (list comprehensions) but that's not really its intent.

Maybe it's no worse a fit than "containers" and after all, we're in Kubernetes because of Plan9, right?

On Aug 2, 2023, at 8:24 PM, George Michaelson <ggm(a)algebras.org> wrote: Tail recursion not lazy eval. I wish words meant what I meant "inside" when I think them, not "outside" what they mean when I write them.

On Aug 3, 2023, at 1:32 AM, Rob Pike &lt;robpike(a)gmail.com&gt; wrote: I once inherited maintenance of a critical piece of infrastructure written in exquisitely well written, tested, and documented Python. I mean it, it was really really good. It crashed about once a week and I had to fix it over and over because in those exponentially vast combinations of paths through the code would arise yet another way to turn a string into a list, or something analogous. It was hell. Critical code needs static typing. -rob On Thu, Aug 3, 2023 at 1:56 PM Bakul Shah &lt;bakul(a)iitbombay.org <mailto:bakul@iitbombay.org>> wrote: > python can certainly implement tail call optimization (TCO). Pretty much any language can implement TCO but for some reason people think such programs are harder to debug (and yet they don't similarly complain about loops!). The beauty of Scheme was that it *mandated* tail recursion. > > > On Aug 2, 2023, at 8:24 PM, George Michaelson &lt;ggm(a)algebras.org <mailto:ggm@algebras.org>> wrote: > > > > Tail recursion not lazy eval. > > > > I wish words meant what I meant "inside" when I think them, not > > "outside" what they mean when I write them. >

Python has optional type annotations. There are batch tools (e.g., MyPy) to do type analysis and IDE's also provide help. Example: def greeting(name: str) -> str:     return 'Hello ' + name I found Python to be an enormous improvement over Perl for writing the kinds of things I used to write in Perl, with the Perl book at my side. I currently make my living working on Python for microcontrollers. Neverthless, I am fond of type checking too, and if I were writing a large Python system, I would use type annotations. I have used BCPL too, in the 70's, and we achieved some measure of type safety by careful naming. Dan H. On 8/3/23 10:19, Bakul Shah wrote: > I have not heard such horror stories about Common Lisp (or may be I have forgotten them!). My impression is that python doesn't quite have the kind of {meta,}programming tools Common Lisp has. CL has been used for large critical programs. Perhaps Von Rossum had more experience with statically typed languages than Lisp (because -- pure speculation here -- if he had used CL enough, he would never have designed python :-) > >> On Aug 3, 2023, at 1:32 AM, Rob Pike &lt;robpike(a)gmail.com&gt; wrote: >> >> I once inherited maintenance of a critical piece of infrastructure written in exquisitely well written, tested, and documented Python. I mean it, it was really really good. >> >> It crashed about once a week and I had to fix it over and over because in those exponentially vast combinations of paths through the code would arise yet another way to turn a string into a list, or something analogous. It was hell. >> >> Critical code needs static typing. >> >> -rob >> >> >> On Thu, Aug 3, 2023 at 1:56 PM Bakul Shah &lt;bakul(a)iitbombay.org&gt; wrote: >> >> python can certainly implement tail call optimization (TCO). >> Pretty much any language can implement TCO but for some reason >> people think such programs are harder to debug (and yet they >> don't similarly complain about loops!). The beauty of Scheme was >> that it *mandated* tail recursion. >> >> > On Aug 2, 2023, at 8:24 PM, George Michaelson >> &lt;ggm(a)algebras.org&gt; wrote: >> > >> > Tail recursion not lazy eval. >> > >> > I wish words meant what I meant "inside" when I think them, not >> > "outside" what they mean when I write them. >> >

On Thu, Aug 3, 2023 at 11:21 AM will.senn(a)gmail.com &lt;will.senn(a)gmail.com&gt; wrote:

someone had needed to store a pair of integers, so they used a CONS cell;

needed to be expanded to a triple, so someone converted the single CONS cell into a (proper) list.

raised a condition, which resulted as an ISE in prod. The fix was trivial (change CDR to SECOND in the right place) but it really struck me that if the system were statically typed, this would have been trivially discovered at compile-time.

these are usually hints to the compiler for code generation.

like Rob, I greatly prefer strong, static typing.

Incidentally, C is weakly (you can add a pointer to an integer: the result is another pointer), but statically typed.

On Aug 3, 2023, at 3:05 PM, Dan Cross &lt;crossd(a)gmail.com&gt; wrote: On Thu, Aug 3, 2023 at 11:21 AM will.senn(a)gmail.com &lt;will.senn(a)gmail.com&gt; wrote: Types in programming languages vary across two axes: strong versus weak, and static versus dynamic. Common Lisp is strongly typed: for example, you cannot add an integer to a list, or `cons` something onto a vector (Common Lisp vectors are not lists). Indeed, exactly the former caused a production outage in a large Lisp system I worked on for about a year: someone had needed to store a pair of integers, so they used a CONS cell; after a while, the pair needed to be expanded to a triple, so someone converted the single CONS cell into a (proper) list. Consequently, the function for accessing the second value went from being CDR to CADR (or `SECOND`), but the programmer missed one place: the value of `(cdr foo)`, now a list, was passed to some function that expected a fixnum and tried to add something to it: this, of course, ran afoul of the type system and raised a condition, which resulted as an ISE in prod. The fix was trivial (change CDR to SECOND in the right place) but it really struck me that if the system were statically typed, this would have been trivially discovered at compile-time. On the other axis, Lisps are usually dynamically typed, which in this context, means that the type of a value associated with a symbol may change over time and one matters when the value is actually used. Common Lisp does allow you to declare types in some limited regards; these are usually hints to the compiler for code generation. Conversely, in statically typed languages, the type of every value is known at all times (particularly at compile time). Incidentally, this episode --- along with something similar in a Python program --- really soured me on dynamically-typed languages. The python failure was particularly maddening: it was heavily unit tested (100% coverage) but as soon as we put it out, we immediately got an error report: a type error with processing the arguments to `main` (Google had some non-standard internal libraries for that that were challenging to test). This was highly frustrating: like Rob, I greatly prefer strong, static typing. Incidentally, C is weakly (you can add a pointer to an integer: the result is another pointer), but statically typed. - Dan C. > On August 3, 2023 9:56:22 AM CDT, Dan Halbert &lt;halbert(a)halwitz.org&gt; wrote: >> >> Python has optional type annotations. There are batch tools (e.g., MyPy) to do type analysis and IDE's also provide help. Example: >> >> def greeting(name: str) -> str: >> return 'Hello ' + name >> >> I found Python to be an enormous improvement over Perl for writing the kinds of things I used to write in Perl, with the Perl book at my side. I currently make my living working on Python for microcontrollers. Neverthless, I am fond of type checking too, and if I were writing a large Python system, I would use type annotations. >> >> I have used BCPL too, in the 70's, and we achieved some measure of type safety by careful naming. >> >> Dan H. >> >> On 8/3/23 10:19, Bakul Shah wrote: >> >> I have not heard such horror stories about Common Lisp (or may be I have forgotten them!). My impression is that python doesn't quite have the kind of {meta,}programming tools Common Lisp has. CL has been used for large critical programs. Perhaps Von Rossum had more experience with statically typed languages than Lisp (because -- pure speculation here -- if he had used CL enough, he would never have designed python :-) >> >> On Aug 3, 2023, at 1:32 AM, Rob Pike &lt;robpike(a)gmail.com&gt; wrote: >> >> I once inherited maintenance of a critical piece of infrastructure written in exquisitely well written, tested, and documented Python. I mean it, it was really really good. >> >> It crashed about once a week and I had to fix it over and over because in those exponentially vast combinations of paths through the code would arise yet another way to turn a string into a list, or something analogous. It was hell. >> >> Critical code needs static typing. >> >> -rob >> >> >> On Thu, Aug 3, 2023 at 1:56 PM Bakul Shah &lt;bakul(a)iitbombay.org&gt; wrote: >>> >>> python can certainly implement tail call optimization (TCO). Pretty much any language can implement TCO but for some reason people think such programs are harder to debug (and yet they don't similarly complain about loops!). The beauty of Scheme was that it *mandated* tail recursion. >>> >>>> On Aug 2, 2023, at 8:24 PM, George Michaelson &lt;ggm(a)algebras.org&gt; wrote: >>>> >>>> Tail recursion not lazy eval. >>>> >>>> I wish words meant what I meant "inside" when I think them, not >>>> "outside" what they mean when I write them. >>> >> >> > -- Sent from /e/OS Mail.

On Wed, Aug 02, 2023 at 07:49:18PM -0400, Rich Salz wrote: I've really tried to like python but any language that doesn't has printf as builtin is not for me. Yes, I know about their library printf but it is weird. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat

this isn't to say i think python is the end-all of programming, far from it, but it certainly took a lot of the novice programmer anxiety out of programming for be.

Clem and all, I find python string format syntax to be close enough to printf. E.g., print('%.4f ns, (%.4f, %.4fj)' % (tap[0], tap[1].real, tap[1].imag)) However, the example highlights a shortcoming. While complex numbers are supported by the language, there is no formatting support like '%.5j' ('j' is my made up format char) to directly format a complex number. I work in an RF lab focused on work with hardware and lab gear. Some points in favor of python are (1) lab gear is controlled by SCPI, (2) DSP relies on complex math, and (3) RF propagation modeling is computationally intense. Item (1) is easily performed with python, (2) with python or Matlab/octave, and (3) is 'it depends.' An engineer's friend went from slide rule, to calculator, fortran/c (fortran for numbers, c for hardware), and now python. A laptop with python or matlab is the new 'calculator.' As to (3), if you will use the program for large scenarios, use c or fortran. For small runs or to dovetail results with control of lab gear python fills the bill. (I even went to the slightly insane length of converting a classic prop model from fortran to python for that reason: https://udel.edu/~mm/itm/ ) I agree 110% that python white space formatting is horrible. I can't say many times I took someone else's program, made a quick change, to discover one of us used tabs and the other spaces. Mike Markowski On 8/2/23 10:07 PM, Clem Cole wrote:

That said, as a person who thinks of himself as a professional, when I go in to someone else's code, I adopt their style. It's really rude to not do so. I've written code in GNU C style. Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat

What we've done on my current project is pretty much equivalent to the route Go chose. Go has go fmt; doesn't matter what you personally believe, just run that pre-commit, and you get a consistent style. For Python we use black. Same idea. It's not what everyone would have chosen--in fact, precisely what it does is not what *anyone* on the project, probably, would have chosen--but the fact is, it does something sane and pretty readable, and then there's no fighting over style.

What, we all need something to kick now that we've beaten sendmail?  How about something unix, ideally a decade old?

At the risk of exposing my ignorance and thus being events long long ago in history.... And my mind now old and feeble... 😆 🤣 1. I don't think the 11/45 had split I & d. But I could be wrong. That did not appear until the 11/70 And was in the later generation 11/44 several years later. 2. The kernel determined it by MMU type and managed it solely. The assembler and loader always built the binary object file as the three sections - instructions, data and bss spaces so loading an object file could be done on any platform. Programmers generally did not worry about the underlying hardware 3. I don't recall if a systype style system call was available in v7 to give you a machine type to switch off of. With something like that you could determine memory availability hard limits on the DATA/bss side if you needed to. But that was also easily determined by a allocation failure in malloc/sbrk with an out of memory error. If you really needed to know availability, you could have a start up subroutine that would loop trying to malloc ever decreasing memory sizes until success and until out of available memory error. Then release it all back via free(). Or manage it internally. As I recall however vaguely, there was an attempt to split the kernel into two pieces. One running in kernel mode and one running in supervisor mode in order to double the amount of available instruction and data spaces for the operating system. I recall playing around with what was there trying to get it to work right. I was trying to support over 200 users on a pdp 11/70 at the time running a massive insurance database system. On Thu, Aug 3, 2023, 4:35 PM Will Senn &lt;will.senn(a)gmail.com&gt; wrote: >Does unix (v7) know about the PDP-11 45's split I/D space through >configuration or is it convention and programmer's responsibility to >know and manage what's actually available? > >Will > >On 8/3/23 12:00, Rich Salz wrote: > > What, we all need something to kick now that we've beaten sendmail? > > How about something unix, ideally a decade old? >

2BSD also did split I&D in the kernel (as well as run TCP in supervisor mode to get another I/D space). A lot of the overlays was done in the linker, but it wasn't completely automated. I had to tweak the overlay tables a little as I did the 2.11pl0 work since the early stuff wasn't exactly careful about distributing the hacks to the makefile to make it happen... Warner On Thu, Aug 3, 2023 at 3:10 PM Ronald Natalie &lt;ron(a)ronnatalie.com&gt; wrote: >Having cut my UNIX teeth on the JHU 11/45, I can tell you very much >that it did have split I/D. V6 supported split I/D for user mode >programs. The kernel originally wasn’t split I/D. Version 7, if >I’m recalling properly, did run the kernel split I/D on the 45 and 70. > > > >------ Original Message ------ >From "Kenneth Goodwin" &lt;kennethgoodwin56(a)gmail.com&gt; >To "Will Senn" &lt;will.senn(a)gmail.com&gt; >Cc "The Eunuchs Hysterical Society" &lt;tuhs(a)tuhs.org&gt; >Date 8/3/23, 5:05:31 PM >Subject [TUHS] Re: Split addressing (I/D) space (inspired by the death >of the python... thread) > >>At the risk of exposing my ignorance and thus being events long long >>ago in history.... >>And my mind now old and feeble... >> >>😆 🤣 >> >>1. I don't think the 11/45 had split I & d. >>But I could be wrong. >>That did not appear until the 11/70 >>And was in the later generation 11/44 several years later. >> >>2. The kernel determined it by MMU type and managed it solely. The >>assembler and loader always built the binary object file as the three >>sections - instructions, data and bss spaces so loading an object >>file could be done on any platform. >>Programmers generally did not worry about the underlying hardware >> >>3. I don't recall if a systype style system call was available in v7 >>to give you a machine type to switch off of. >> >>With something like that you could determine memory availability hard >>limits on the DATA/bss side if you needed to. >> >>But that was also easily determined by a allocation failure in >>malloc/sbrk with an out of memory error. >> >>If you really needed to know availability, you could have a start up >>subroutine that would loop trying to malloc ever decreasing memory >>sizes until success and until out of available memory error. >>Then release it all back via free(). Or manage it internally. >> >>As I recall however vaguely, there was an attempt to split the >>kernel into two pieces. One running in kernel mode and one running in >>supervisor mode in order to double the amount of available >>instruction and data spaces for the operating system. I recall >>playing around with what was there trying to get it to work right. >>I was trying to support over 200 users on a pdp 11/70 at the time >>running a massive insurance database system. >> >>On Thu, Aug 3, 2023, 4:35 PM Will Senn &lt;will.senn(a)gmail.com&gt; wrote: >>>Does unix (v7) know about the PDP-11 45's split I/D space through >>>configuration or is it convention and programmer's responsibility to >>>know and manage what's actually available? >>> >>>Will >>> >>>On 8/3/23 12:00, Rich Salz wrote: >>> > What, we all need something to kick now that we've beaten >>>sendmail? >>> > How about something unix, ideally a decade old? >>>

Does unix (v7) know about the PDP-11 45's split I/D space through configuration or is it convention and programmer's responsibility to know and manage what's actually available? Will On 8/3/23 12:00, Rich Salz wrote:

Will its a C Compiler switch (-i) and create 411 files instead of 407. I like to refer to it as the 17th address bit. I was first brought out with the 11/45 (which was SSI/MSI TTL), and the biggest differences between it and the 11/40.  They were both early 1970s and both of these processors were multiple boards. By 1976, the 780 has started and that sucked off most of the HW folks.   A new hire in 1976, Jeff Mitchell supposedly had a bet with Bill Strecker that he could implement an 11 on a single"hex high" CPU board if he got rid of the lights and switches.  He ran out of room to implement seperate I/D, so it became an 11/40 class [and it has an 8008-1 that runs the front panel]. The 11/70 came out between the 11/45 and the 34 and had a number of the STAR folks on it it original but it was also multiple boards.   It was not until 11/44 that DEC was able to make a hex height implementation of the 11 that managed to cram a full 11/70 into that system.   The later J-11 chip set took things beyond the 11/70. If you look at the conf directory in the sys sources for V6, you see m40.s and m45.s - but if you look at the link line of sys/run the 45 does not have -i; but if you look in sys/sys1.c you'll see the in the routine getxfile the support for 0407/0411/0405/0410 files for user mode. If you look at the conf directory in the sys sources for V7, you see mch.s and m45.s  its common and the makefile adds -i ᐧ On Thu, Aug 3, 2023 at 4:35 PM Will Senn &lt;will.senn(a)gmail.com&gt; wrote: Does unix (v7) know about the PDP-11 45's split I/D space through configuration or is it convention and programmer's responsibility to know and manage what's actually available? Will On 8/3/23 12:00, Rich Salz wrote:

For whatever its worth, even with 4M the kernel had started to become a problem for V7 on an 11/70.  Data buffers eat a lot of memory.

ᐧ Adding features and thinking less about what functionality was really needed started to get lost [so now we have Gnu - but I digress].

function, that probably won't be as tunable as printf(3) is.

On 2023-08-03 19:51, John Cowan wrote: I didn't claim that there's never a reason to invent new syntax. My claim was rather that in this case, there isn't. - printf(3) is more powerful than any other existing formatting function that I know of any language --I'm still curious of what's the equivalent of "%+'0#8.5f" in other formatting functions--.

- It is also reasonably fast (at least for such a highly-customizable formatting function), and I'd like to see any system beat that while keeping the customizability.

- It is type-safe, with the right tools.

I can understand the need for less-customizable faster formatting functions for very-high-performance programs, and std::format may fit well there. But other than that, I don't see a reason to invent so many different formatting functions. Of course, one may do that just for fun, in which case I applaud that. But printf(3) is superior to them, IMO.

On 2023-08-03 23:29, Dan Cross wrote: Being in POSIX.1 it's portable to most (all?) current systems. ISO C is a baseline for an implementation. A quality implementation will go beyond that standard (or will be rather useless). POSIX.1 is more of a useful thing.

But yeah, we can remove that "'" to get the idea. Yup; I like go in that sense. [...] I think you mean absl::StrFormat(). It has printf(3)-like syntax, so I can't say say much against it. I don't know the details of how they achieved the claimed 2x ~ 3x performance compared to snprintf(3). I'm curious to know if it's an inherent limitation of snprintf(3), or if it's just that glibc is very unoptimized --which is true anyway, because no-one has really maintained the printf(3) code in a long time--.

It's interesting, because then std::format() is not that miraculous compared to snprintf(3). Isn't a variable format string a security vulnerability? Where do you need it?

On 2023-08-04 18:06, Dan Cross wrote: I guessed you'd mention v*() formatting functions, as that's the only case where a variable format string is indeed necessary (or kind of).

I'll simplify your example to vwarnx(3), from the BSDs, which does less job, but has a similar API regarding our discussion. I'm not sure if you meant vsyslog() uses or its implementation, but I'll cover both (but for vwarnx(3)). Uses: This function (and all v*() functions) will be used to implement a wrapper variadic function, like for example warnx(3). It's there, in the variadic function, where the string /must be/ a literal, and where

the arguments are checked. There's never a good reason to use a non-literal there (AFAIK),

and there are compiler warnings and linters to enforce that. Since those args have been previously checked, you should just pass the va_list pristine to other formatting functions.

Then, as long as libc doesn't have bugs, you're fine.

In the implementation of a v*() function: Do /not/ touch the va_list. Just pass it to the next function. Of course, in the end, libc will have to iterate over it and do the job, but that's not the typical programmer's problem. Here's the libbsd implementation of vwarnx(3), which does exactly that: no messing with the va_list. $ grepc vwarnx ./include/bsd/err.h:63: void vwarnx(const char *format, va_list ap) __printflike(1, 0); ./src/err.c:97: void vwarnx(const char *format, va_list ap) { fprintf(stderr, "%s: ", getprogname()); if (format) vfprintf(stderr, format, ap); fprintf(stderr, "\n"); } Just put a [[gnu::format(printf)]] in the outermost wrapper, which should be using a string literal, and you'll be fine.

Not really. You can do that _only_ if you really want.

If you want to not be able, you can "drop privileges" by adding a few flags to your compiler, such as -Werror=format-security -Werror=format-nonliteral, and add a bunch of linters to your build system for more redundancy, and voila, your project is now safe.

On the subject of "no printf", there is not one, not two, but THREE ways to format strings, easily compounded with print: print("%s %s" % ("hello", "world")) print("{1} {two}".format("hello", two="world")) print(f"{greeting} {populace}") I'm pretty sure the last method (which initially made me vomit, due to

IMO (Like Larry) no printf stinks. But the real killer for my sustain for Python is the use white space and being typeless. My daughter loves it for her cloud development and we argue a bit. But it was the first language she really mastered in college and she never took a competitive languages course so I’m not so sure really had experienced much beyond it for real programs. Maybe I’m just an old fart but between C, Go and Rust I’m pretty good. I do write scripts in Bourne shell and or awk truth be known. On Wed, Aug 2, 2023 at 8:51 PM Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: -- Sent from a handheld expect more typos than usual

We did something sort of like that in Little, all double quoted strings look for ${anything} in the string and evaluates it and prints. Like fstrings, you can do puts("Print 5 + 7 = ${5 + 7}"); We used single quoted strings as pure strings. It's handy and sometimes more readable than printf. http://www.little-lang.org/little.html#String_interpolation On Fri, Aug 04, 2023 at 02:20:06PM -0500, Ed Bradford wrote: for it competitive beyond it and Rust truth be understand it comprehensions) but printf it -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat