On Tue, 24 Sep 2024 04:11:46 -0700 (Seattle), Relf wrote:

> Too many "svg" elements presume your background is white, never black.

Actually I think the background starts out transparent.

> And it assumes that its container is approximately line height,
> or something reasonable like that, never anything else.

This is spelled out in the top-level “width” and “height” attributes.

On 2024-09-24, rbowman <bowman@montana.com> wrote:

> On Tue, 24 Sep 2024 18:24:05 GMT, Charlie Gibbs wrote:
>
>> Once I got network programming figured out, I wrote my own library of
>> functions that set everything up the way I want it (including SSH and
>> TLS). Sure, you have to watch your step sometimes, but it's not quite
>> as bad as people make it out to be.
>
> I saw no reason to reinvent the OpenSSL wheel particularly if you need
> FIPS compliance.

My libraries call OpenSSL, but let me establish a connection
(with or without TLS) with a single call.

--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut

On 9/24/24 3:17 AM, Lawrence D'Oliveiro wrote:
> On Tue, 24 Sep 2024 02:45:16 -0400, 186282@ud0s4.net wrote:
>
>> Still have my K&R 'C' book ...
>
> Would hope you have caught up with C99, at least.

Ummm ... STILL mostly stick to the Original Product.
Can't go wrong.

>> Oh, "network programming" is HARD ...
>
> Not that hard. Some of us do it every day.

Yea, but not so MANY of you in the world ...

It's a relatively rare/important skill.

A pre-threaded bi-di TCP daemon does not require
THAT much code these days, but the routines that
code invokes are *complicated*. Do NOT wanna go
to THAT level.

> <https://gitlab.com/ldo/ssl_try_python/>
>
>> Wrote a FORTRAN app just a couple of years ago ...
>
> Did you use a suitably recent version of Fortran, namely Fortran 90 at
> least? It’s quite a decent language these days.

F77

Adequate for the purpose.

It was a 'decent' language even then. More 'friendly'
now, but be careful how much 'solid'/'simple' you trade
for "friendly".

NOT sure if there are still NATIVE F77 compilers for
Linux. Things like gFortran - just 'C' translators -
may as well just do it in 'C' to begin with.

I *think* there are still native F77 compilers for
Linux - but quick searches don't name them anymore.
Maybe 'flang-16' ... but it's reputed to be missing
some stuff. Good old 8-bit compilers ... Intel 'fixed'
THAT. DO have an old core2-quad box that still runs
8-bit however.

On 9/24/24 6:16 AM, Pancho wrote:
> On 9/24/24 08:17, Lawrence D'Oliveiro wrote:
>> On Tue, 24 Sep 2024 02:45:16 -0400, 186282@ud0s4.net wrote:
>>
>>> Still have my K&R 'C' book ...
>>
>> Would hope you have caught up with C99, at least.
>>
>>> Oh, "network programming" is HARD ...
>>
>> Not that hard. Some of us do it every day.
>>
>> <https://gitlab.com/ldo/ssl_try_python/>
>>
>>> Wrote a FORTRAN app just a couple of years ago ...
>>
>> Did you use a suitably recent version of Fortran, namely Fortran 90 at
>> least? It’s quite a decent language these days.
>
> We can all do network programming. The art is making it secure and
> resilient.
>
> Not the kind of thing you want a sloppy application developer like me
> going anywhere near, which is why I choose to avoid it whenever
> possible, and to use services that hide the complexity, as far as possible.

Very accurate - THESE days the 'security' stuff kinda
outranks everything else. Vlad's boyz will just POUND
yer code looking for ANY tiny crack. If they can't get
in then they'll make it crash just for spite.

YOUR code, the LIBS, the DRIVERS - SO many places for
problems. Kinda scary. Frankly the whole foundation of
the Net and 'secure' anything is highly in doubt now.
"AI" can try EVERY attack option, smartly, quickly.

Maybe Sears needs to publish a new catalog ? Paper
form and a money order via snail mail .........

Like REALLY .......

On 9/24/24 4:01 AM, D wrote:
>
>
> On Tue, 24 Sep 2024, 186282@ud0s4.net wrote:
>
>> On 9/21/24 8:03 AM, Farley Flud wrote:
>>> Rust is laughable garbage.
>>>
>>> Some jerk at Mozilla cobbles some shit together and it ends
>>> up impressing his co-workers, all network "programmers" who
>>> are the lowest of the low.
>>
>>  Look ... 'Rust' is really no better, or worse, than
>>  a LOT of existing computer languages. If you LIKE
>>  its vibe, USE it. If not, DON'T
>>
>>  Python wasn't always popular. Took time to build
>>  a real following.
>>
>>  Me, I'd rather use 'C' ... which was a brand new
>>  language when I got into computers - it was the
>>  Cool New Thing on PDP-11s. However the syntax IS,
>>  and especially can be MADE, a bit obscure. More
>>  'obvious', 'self-documenting' langs DO have an
>>  advantage.
>>
>>  Still have my K&R 'C' book - and stick pretty
>>  much TOO it. I'd also rec "Algorithms in 'C'"
>>  by Sedgewick. STILL consult that.
>>
>>  But my #1 fave is still Pascal. Poetry  :-)
>>  Thank you professor Wirth !
>>
>>  Oh, "network programming" is HARD ... those people
>>  are NOT the "lowest of the low" by any means. The
>>  whole Modern World depends on them.
>>
>>  But then you're just trying to start flames,
>>  aren't you ? Try being more productive.
>>
>>  Hey, want "Real Computing" ? Try FORTRAN
>>  or COBOL. THOSE were the foundation and
>>  persist to this day. Wrote a FORTRAN app
>>  just a couple of years ago - mostly to vex
>>  the New Guys. Also a short COBOL app, that
>>  oughtta REALLY give 'em the shits !  :-)
>>
>
> Messages like this give me the vibe of an old distinguished professor
> writing. These types of messages tend to completely melt the troll in
> me. ;)

Well, I *was* the Old Guy ... and noted that those
moving in to be my replacements knew almost SHIT
about programming/systems. THEIR 'fix' is to go
Office-365 Online stuff. That way they don't need
to KNOW dick except how to pay the bill - and
nothing is THEIR fault.

I came in when you could hardly buy ANY software,
or appropriate hardware for that matter. Spent a
lot of time with a soldering iron and 8051/PIC/logic
chips to get the Desired Results. Such fun using
DDL to expand interrupt-pin functionality. DigiKey
and Tandy got a LOT of money from me :-)

THEN you had to be a jack-of-all-trades, NOW you
just Charge It to M$ and hope for the best. That's
what "IT" means now. NOT for the best. Vlad's boyz
WILL destroy it and the world will STOP.

On Wed, 25 Sep 2024 01:44:52 -0400, 186282@ud0s4.net wrote:

> On 9/24/24 3:17 AM, Lawrence D'Oliveiro wrote:
>
>> Would hope you have caught up with C99, at least.
>
> Ummm ... STILL mostly stick to the Original Product. Can't go wrong.

Shame.

>> Did you use a suitably recent version of Fortran, namely Fortran 90 at
>> least? It’s quite a decent language these days.
>
> F77

Shame.

On Wed, 25 Sep 2024 02:28:15 -0400, 186282@ud0s4.net wrote:

> Well, I *was* the Old Guy ... and noted that those moving in to be my
> replacements knew almost SHIT about programming/systems.

Well, now you seem to be the one whose knowledge is, shall we say, judging
from your other comments on this thread, tending towards obsolescence?

On Wed, 25 Sep 2024 01:44:52 -0400, 186282@ud0s4.net wrote:

> On 9/24/24 3:17 AM, Lawrence D'Oliveiro wrote:
>> On Tue, 24 Sep 2024 02:45:16 -0400, 186282@ud0s4.net wrote:
>>
>>> Still have my K&R 'C' book ...
>>
>> Would hope you have caught up with C99, at least.
>
> Ummm ... STILL mostly stick to the Original Product.
> Can't go wrong.

Hopefully you've moved past K&R style function definitions. afak they will
still compile though. C99 added some things I use like // comments and
declaring variable close to where they're used rather than a laundry list
at the top of the function. With the exception of the implied int which
always was sloppy form, C99 didn't rock the boat like Python 3.

On 2024-09-25, rbowman <bowman@montana.com> wrote:

> On Wed, 25 Sep 2024 01:44:52 -0400, 186282@ud0s4.net wrote:
>
>> On 9/24/24 3:17 AM, Lawrence D'Oliveiro wrote:
>>
>>> On Tue, 24 Sep 2024 02:45:16 -0400, 186282@ud0s4.net wrote:
>>>
>>>> Still have my K&R 'C' book ...
>>>
>>> Would hope you have caught up with C99, at least.
>>
>> Ummm ... STILL mostly stick to the Original Product.
>> Can't go wrong.
>
> Hopefully you've moved past K&R style function definitions. afak they will
> still compile though.

#ifdef PROTOTYPE
int foo(char *bar, BOOL baz)
#else
int foo(bar,baz) char *bar; BOOL baz;
#endif

There. Best of both worlds. I don't know how long it's been since
I used a compiler that doesn't support prototypes, but I'm ready...

--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut

On 9/25/24 2:48 AM, Lawrence D'Oliveiro wrote:
> On Wed, 25 Sep 2024 02:28:15 -0400, 186282@ud0s4.net wrote:
>
>> Well, I *was* the Old Guy ... and noted that those moving in to be my
>> replacements knew almost SHIT about programming/systems.
>
> Well, now you seem to be the one whose knowledge is, shall we say, judging
> from your other comments on this thread, tending towards obsolescence?

Um ... don't really think it's "obsolete" - it's
the good old core stuff. However, once Russia
and China/NK are done, those super-wonderful
online biz apps may be what's obsolete - maybe
REAL soon now given the trends. I get the
feeling there's a whole new cadre of lawyers
who will specialize in data/function stolen
or corrupted by 'online' biz apps. That'll
be fun .....

'Online' is a way so your supposed IT people
aren't RESPONSIBLE. It's a sort of career/
legal DODGE - plus know-nothing "IT" people
can get CRAP salaries :-)

IMHO, keep your OWN data farm. your OWN router
and firewalls, use apps installed ON yer own
PCs, do your OWN (multi-) backup pgms. Do NOT
use any all-system update or remote-admin tricks.
This is MUCH harder for Vlad's boyz to destroy.

On 9/24/24 8:52 PM, Charlie Gibbs wrote:
> On 2024-09-24, rbowman <bowman@montana.com> wrote:
>
>> On Tue, 24 Sep 2024 18:24:05 GMT, Charlie Gibbs wrote:
>>
>>> Once I got network programming figured out, I wrote my own library of
>>> functions that set everything up the way I want it (including SSH and
>>> TLS). Sure, you have to watch your step sometimes, but it's not quite
>>> as bad as people make it out to be.
>>
>> I saw no reason to reinvent the OpenSSL wheel particularly if you need
>> FIPS compliance.
>
> My libraries call OpenSSL, but let me establish a connection
> (with or without TLS) with a single call.

I was fooling with TCP/UDP client-server stuff and
at SOME point realized I was re-inventing FTP :-)

On Wed, 25 Sep 2024 00:52:17 GMT, Charlie Gibbs wrote:

> My libraries call OpenSSL, but let me establish a connection (with or
> without TLS) with a single call.

I suppose you can do anything with a single call, if you pack enough
arguments into it ...

On 9/28/24 3:38 AM, Lawrence D'Oliveiro wrote:
> On Wed, 25 Sep 2024 00:52:17 GMT, Charlie Gibbs wrote:
>
>> My libraries call OpenSSL, but let me establish a connection (with or
>> without TLS) with a single call.
>
> I suppose you can do anything with a single call, if you pack enough
> arguments into it ...

Heh heh ... yea ... LOVE those compound lines with x.y.z.a.b.c() ...
SO comprehensible :-)

I've used openSSL most for encrypting individual files.
The proper params can be found, a TAD different for
Winders. Encrypt first, THEN send to the 'cloud' or
whatever. NEVER allow an unencrypted copy online
for a millisecond.

OpenSSL is good because it's FAST. GPG is good, maybe
a tad better in theory, but for individual files the
start-up time is WAY too long. GPG is best for a FEW
files, perhaps big ZIPs.

OpenSSL can also be used, is intended to be used, for
'live' connections. Depending on your needs/intent
this can be very important. I tended to avoid that,
but my needs aren't YOUR needs.

Again, as for "Rust" - it's good for what it's good for.
To ME it just looks like the umpteenth pointless re-write
of 'C' - so I'll just stick with 'C'.

If you want biz reports and checks printed - COBOL !

On Sun, 29 Sep 2024 01:11:54 -0400, 186282@ud0s4.net wrote:

> On 9/28/24 3:38 AM, Lawrence D'Oliveiro wrote:
>
>> I suppose you can do anything with a single call, if you pack enough
>> arguments into it ...
>
> Heh heh ... yea ... LOVE those compound lines with x.y.z.a.b.c() ...
> SO comprehensible :-)

I have occasionally found method-chaining to be useful, particularly with
graphics APIs, e.g.

(draw
.close_path()
.set_source_colour(bg_colour)
.fill_preserve()
.set_line_width(line_thickness)
.set_source_colour(fg_colour)
.stroke()
)

> If you want biz reports and checks printed - COBOL !

Could never handle proportional fonts and nice text layouts, though.
Python deals with those sorts of things better.

On 9/29/24 1:38 AM, Lawrence D'Oliveiro wrote:
> On Sun, 29 Sep 2024 01:11:54 -0400, 186282@ud0s4.net wrote:
>
>> On 9/28/24 3:38 AM, Lawrence D'Oliveiro wrote:
>>
>>> I suppose you can do anything with a single call, if you pack enough
>>> arguments into it ...
>>
>> Heh heh ... yea ... LOVE those compound lines with x.y.z.a.b.c() ...
>> SO comprehensible :-)
>
> I have occasionally found method-chaining to be useful, particularly with
> graphics APIs, e.g.
>
> (draw
> .close_path()
> .set_source_colour(bg_colour)
> .fill_preserve()
> .set_line_width(line_thickness)
> .set_source_colour(fg_colour)
> .stroke()
> )

I've occasionally done that with Python.

HOWEVER, the FUTURE readability suffers considerably.

IMHO, write code so YOU can go back to it like five
years later and actually grasp what you did and why.
Overly-complex code, and 'feature creep' RUIN pgms.

>> If you want biz reports and checks printed - COBOL !
>
> Could never handle proportional fonts and nice text layouts, though.
> Python deals with those sorts of things better.

Yep. However there's still tons of COBOL out there
doing it's boring things.

TODAY I'd say write in Python or plain-Jane 'C'.

PASCAL is also very good and readable ... but not
as many use it anymore. A pity. I do, often.

Has anyone found a Modula-3 compiler for Linux
that actually WORKS ? Just wondering. The
supposed existing offerings SUCK and you can't
compile a three-liner without a zillion complicated
errors popping up. Too old to start tracking down
all that shit.

On 2024-09-30, 186282@ud0s4.net <186283@ud0s4.net> wrote:

> I've occasionally done that with Python.
>
> HOWEVER, the FUTURE readability suffers considerably.
>
> IMHO, write code so YOU can go back to it like five
> years later and actually grasp what you did and why.
> Overly-complex code, and 'feature creep' RUIN pgms.

Yup. Be generous with comments, and write them in plain
English, not some cryptic set of abbreviations that nobody
else would understand. And remember that those comments
aren't necessarily for someone else - they're for you
six months from now, when you've forgotten why you wrote
what you did.

--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut

On Mon, 30 Sep 2024 05:52:35 GMT, Charlie Gibbs wrote:

> Be generous with comments ... [etc etc]

.... and remember they’re supposed to explain *why* the code does
something, not just repeat *what* it does.

You’re talking to someone who has code in his collection going back over
40 years. I learned the lessons of comments long ago.

Fun fact: I was reworking an old perpetual-calendar program I first wrote
back in 1980, to use Fortran 90, a few months ago. And I found a bug in my
algorithm that never showed up in any years from the 20th century, but did
manifest itself in the 21st century.

On Mon, 30 Sep 2024 06:03:29 -0000 (UTC), Lawrence D'Oliveiro wrote:

> Fun fact: I was reworking an old perpetual-calendar program I first
> wrote back in 1980, to use Fortran 90, a few months ago. And I found a
> bug in my algorithm that never showed up in any years from the 20th
> century, but did manifest itself in the 21st century.

Y2K rides again... I think in many cases the problem was recognized in
the '70s and '80s but nobody expected the code to last decades.

On 9/30/24 1:52 AM, Charlie Gibbs wrote:
> On 2024-09-30, 186282@ud0s4.net <186283@ud0s4.net> wrote:
>
>> I've occasionally done that with Python.
>>
>> HOWEVER, the FUTURE readability suffers considerably.
>>
>> IMHO, write code so YOU can go back to it like five
>> years later and actually grasp what you did and why.
>> Overly-complex code, and 'feature creep' RUIN pgms.
>
> Yup. Be generous with comments, and write them in plain
> English, not some cryptic set of abbreviations that nobody
> else would understand. And remember that those comments
> aren't necessarily for someone else - they're for you
> six months from now, when you've forgotten why you wrote
> what you did.

All my work had more comments than code ... almost
every line explained and 'concept' stuff above
every function.

However 5+ years on, STILL kinda difficult to
get the whole groove sometimes. This is not
so good, but it seems COMMON.

On 9/30/24 3:21 AM, rbowman wrote:
> On Mon, 30 Sep 2024 06:03:29 -0000 (UTC), Lawrence D'Oliveiro wrote:
>
>> Fun fact: I was reworking an old perpetual-calendar program I first
>> wrote back in 1980, to use Fortran 90, a few months ago. And I found a
>> bug in my algorithm that never showed up in any years from the 20th
>> century, but did manifest itself in the 21st century.
>
> Y2K rides again... I think in many cases the problem was recognized in
> the '70s and '80s but nobody expected the code to last decades.

Very true - and TROUBLESOME.

We all think in the NOW. With effort we can think
a FEW years ahead. But a whole new century or
something similar ... TOO MUCH WORK to future-
proof. We'll "get back to it", sometime ......

On 30 Sep 2024 07:21:49 GMT, rbowman wrote:

> On Mon, 30 Sep 2024 06:03:29 -0000 (UTC), Lawrence D'Oliveiro wrote:
>
>> Fun fact: I was reworking an old perpetual-calendar program I first
>> wrote back in 1980, to use Fortran 90, a few months ago. And I found a
>> bug in my algorithm that never showed up in any years from the 20th
>> century, but did manifest itself in the 21st century.
>
> Y2K rides again...

No, it wasn’t that. I had a full four digits for the year number (even
back then, I had this hazy premonition ...). The bug actually manifested
itself from 2004 onwards.

Here’s the patch that fixed the Fortran-90 version:

diff --git a/calend.f90 b/calend.f90
index e172fd5..dcbfdc3 100644
--- a/calend.f90
+++ b/calend.f90
@@ -48,14 +48,12 @@ contains
idx = idx + 1
res = mod(yr, divs(idx))
yr = yr / divs(idx)
- if (res == 0) then
+ if (flip_leap .and. res == 0) then
+ leap = .not. leap
rem = rem - l
else
flip_leap = .false.
end if
- if (flip_leap) then
- leap = .not. leap
- end if
if (yr == 0) &
exit
rem = rem + yr * l

On Mon, 30 Sep 2024 03:40:49 -0400, 186282@ud0s4.net wrote:

> ... but it seems COMMON.

.... sorry, I thought you were making a Fortran joke ...

On 9/30/24 3:56 AM, Lawrence D'Oliveiro wrote:
> On Mon, 30 Sep 2024 03:40:49 -0400, 186282@ud0s4.net wrote:
>
>> ... but it seems COMMON.
>
> ... sorry, I thought you were making a Fortran joke ...

Almost :-)

On Mon, 30 Sep 2024 03:43:16 -0400, 186282@ud0s4.net wrote:

> On 9/30/24 3:21 AM, rbowman wrote:
>> On Mon, 30 Sep 2024 06:03:29 -0000 (UTC), Lawrence D'Oliveiro wrote:
>>
>>> Fun fact: I was reworking an old perpetual-calendar program I first
>>> wrote back in 1980, to use Fortran 90, a few months ago. And I found a
>>> bug in my algorithm that never showed up in any years from the 20th
>>> century, but did manifest itself in the 21st century.
>>
>> Y2K rides again... I think in many cases the problem was recognized in
>> the '70s and '80s but nobody expected the code to last decades.
>
> Very true - and TROUBLESOME.
>
> We all think in the NOW. With effort we can think a FEW years ahead.
> But a whole new century or something similar ... TOO MUCH WORK to
> future- proof. We'll "get back to it", sometime ......

It won't be my problem but my bet is there will be a flurry of activity in
2037...

186282@ud0s4.net <186283@ud0s4.net> wrote at 07:43 this Monday (GMT):
> On 9/30/24 3:21 AM, rbowman wrote:
>> On Mon, 30 Sep 2024 06:03:29 -0000 (UTC), Lawrence D'Oliveiro wrote:
>>
>>> Fun fact: I was reworking an old perpetual-calendar program I first
>>> wrote back in 1980, to use Fortran 90, a few months ago. And I found a
>>> bug in my algorithm that never showed up in any years from the 20th
>>> century, but did manifest itself in the 21st century.
>>
>> Y2K rides again... I think in many cases the problem was recognized in
>> the '70s and '80s but nobody expected the code to last decades.
>
> Very true - and TROUBLESOME.
>
> We all think in the NOW. With effort we can think
> a FEW years ahead. But a whole new century or
> something similar ... TOO MUCH WORK to future-
> proof. We'll "get back to it", sometime ......

Then, people ignore the problem until it's right there.
For instance, the 2038 problem I'm betting will be ignored until 2035.
--
user <candycane> is generated from /dev/urandom