On 9/27/24 1:43 PM, Charlie Gibbs wrote:
On 2024-09-27, 186282@ud0s4.net <186283@ud0s4.net> wrote:
I always liked ascii-delimited multi-value records.
Hey, you can actually READ them. They are also VERY
easy and cheap for microcontrollers and such to
create on the fly.
Yes, I got into them early - and found it was a short easy
step to CSV, so now my stuff can be read by the people in
spreadsheet land. I have, however, had to put a fair amount
of effort into what I call "Excel-proofing" my data, since
our favourite Redmond software company loves meddling with it.
ISO 8601 does a good job of sidestepping Excel's obsession
with turning dates into month/day/year format, for instance.
I ran into ascii-delimited MV records when I did
some things with the PICK system long back. These
were largely 'text' records ... 10000 was "10000",
not any binary rep. As such, the 'high' ascii vals
were used as record/field/subfield/subsubfield
delimiters (this was before unicode). On old PCs
you could directly view the delims - those funky
graphics-like characters so handy for making
text/terminal forms.
However I'd been doing a number of microcontroller-
based dataloggers and found that building up
ascii-delimited was really THE easiest way of
storing lots of sensor values. You just keep
tacking-stuff onto the end of the string and
save it when done. No more exotic structure or
logic required.
<Temp1><subfield-mark><Temp2><field-mark><Humid1>
<subfield-mark><Humid2><subfield-mark><Humid3>
<field-mark>" etc until you've done all the
various kinds of sensors and then you stick a
<record-mark> at the end. Human-readable.
Revelation DB system used ascii-255 as the record
mark, 254 as the field marks and worked backwards
from there, thus allowing about 127 levels of
sub-sub values though nobody EVER used THAT many.
Machine-reading is straight-up. Some kinds of
EDITING can get peculiar however because you
want some kind of 'intent' defined - 'data
dictionaries' are a common approach. DBs
generally use hashing to facilitate getting
to a given record quickly.
ANYWAY, those became my go-to kind of record
keeping for many projects and I wrote little
related functions in a number of langs.
I've noted that some people think that because
their high-level lang has a function for dealing
with strings and such means it's better/faster
but the TRUTH is that most langs are writ in 'C'
and those functions are just handy, disguised,
'C'. Just because you don't SEE 'strtok()' does
not mean it isn't ACTUALLY used.
Final note, FORTRAN is *still* good for most
uses. It's fairly clear, un-fancy, and well-tuned
and people added enough to it over the years so
there's hardly any task you can't do with it.
Still didn't find a native FORTRAN compiler for
modern Linux though ... I suspect when Intel
nixxed 8-bit code it broke most of them. Such
a pity ... and 8-bits WERE enough for a lot
of little things and SO nicely compact.
…