On 02.02.2024 08:16, Malcolm McLean wrote:
>
> In Perl you have an implict variable called $_. Some Perl statements
> will operate on $_ without it actually being specified, and you then
> have to reference $_ exoictitly to obtain the result. It's highly
> confusing for anyone used to a conventional language with only one type
> of named varibales. And that's one of the main decisions which makes
> Perl hard to read.

Yes, I remember that '$_', and even though I'm not the typical Perl
programmer (I told you about my only few contacts with Perl) it was
not the least confusing to me. I think, what also generally holds,
that if you want to use some tool you should at least make yourself
familiar with its basic concepts. (This appears to be a quite common
view, despite here we often see complaints complaints from folks with
only basic or no knowledge about the objects of their complain.)
But Perl is also a large language, and it needs some time to learn
or master it. But $_ seemed to me to be some basic thing.

That said, now consider in comparison (e.g.) Ksh that has also a
variable '_' (with value '$_'); and the contents of Ksh's '_' is
even depending on the runtime context!

>
> However often you can write slightly less idiomatic Perl code which
> doesn't make use of this feature, and then it's clearer. Or you can lay
> the code out so that all the places where $_ are used in the same way
> are together and make it a bit easier to work out what is going on.
> There are thing you can do and Perl doesn't have to look like a
> confusing mess.

Yes. Quite typical for many scripting languages. Sometimes there's
even some desire to produce short, cryptic, "clever", forms of code.

Janis

On 02.02.2024 00:57, Malcolm McLean wrote:
>
> The difference is that the syntax for redirecting output in the UNIX
> shell is ony of the slightest use if you happen to run that particular
> type of system.

Hasn't DOS adopted the basic redirections as well?
And hasn't it even tried to mimic pipes?

Of course redirection and its specific syntaxes are depending on
the supporting OS. So what?

In Unix they developed a terse version at a time where on other
OSes you need to "formulate novels" to invoke such features.
And that version was good enough to have been adopted by other
tools. And it's also simple enough that many users use these in
their programming contexts effectively (and without complaints).

> [...] And whilst pipes are a concept, they are no way
> comparable in depth and fundamental importance to the concept of
> functions of functions.
>
> The point is the two are not comparable. [...]

Of course. This point sounds completely reasonable to me.

So the confusion was only about some inappropriate statement that
had been used. (I seem to recall, and think I commented on that.)

Janis

On 02/02/2024 08:51, David Brown wrote:
> On 01/02/2024 23:38, Malcolm McLean wrote:
>> I'm sure you're capable of going through the exercise and then you
>> might gain a bit of insight on how to design such software systems.
>> And, no, arguing that you'd go for a monolithic program doesn't
>> necessarily mean that you are a "quivering jelly" at the thought of
>> writing several simpler ones. And in fact to start you off I actually
>> mentioned a few advantages of the pipeline approach.
>
> I am perfectly aware of the advantages and disadvantages of monolithic
> approaches.
>
Well it's kind of poroof of the pudding. Ben has several programs
connected by piplines and asked me what I thought of the design. I said
I'd go for a monolithinc approach. You criticised mem giving no reason
ither than that my oreferred approach was monolithic. So any reasonable
erson would assume that you think that a monolithic approach is in and
of itself bad.

When invited to list the advantages and disadvantages if either, you
refused to do so. I am sure that you are capable of doing this, and you
are basically right. But you haven't actually done so. And it's proof of
the pudding.

Thne fact is there is case for `Ben's approach, there's a case for my
approach, and maybe Ben's case is better. I've no objection to anyone
weighing in on that. But fundamentally you do not understand what it
means to offer an argument or how to make a case.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 02/02/2024 14:28, Malcolm McLean wrote:
> On 02/02/2024 08:51, David Brown wrote:
>> On 01/02/2024 23:38, Malcolm McLean wrote:
>>> I'm sure you're capable of going through the exercise and then you
>>> might gain a bit of insight on how to design such software systems.
>>> And, no, arguing that you'd go for a monolithic program doesn't
>>> necessarily mean that you are a "quivering jelly" at the thought of
>>> writing several simpler ones. And in fact to start you off I actually
>>> mentioned a few advantages of the pipeline approach.
>>
>> I am perfectly aware of the advantages and disadvantages of monolithic
>> approaches.
>>
> Well it's kind of poroof of the pudding. Ben has several programs
> connected by piplines and asked me what I thought of the design. I said
> I'd go for a monolithinc approach. You criticised mem giving no reason
> ither than that my oreferred approach was  monolithic. So any reasonable
> erson would assume that you think that a monolithic approach is in and
> of itself bad.

No, they would not.

But I don't think, based on your postings, you count as a "reasonable
person".

>
> When invited to list the advantages and disadvantages if either, you
> refused to do so. I am sure that you are capable of doing this, and you
> are basically right. But you haven't actually done so. And it's proof of
> the pudding.
>
> Thne fact is there is case for `Ben's approach, there's a case for my
> approach, and maybe Ben's case is better. I've no objection to anyone
> weighing in on that. But fundamentally you do not understand what it
> means to offer an argument or how to make a case.
>

I know exactly what it means. But I know when it is pointless, when the
person on the other side pays not the slightest attention to what is
being said and instead wanders off in their own little world with their
own little ideas and their own independent terminology.

What would be the point in giving reasons for anything, when you won't
read them? Why should I give arguments, when you will "counter" them by
telling us that grass is blue, using your own definition for "blue"?
I've put a lot of effort into trying to explain things to you - enough
is enough. I get more intelligent responses talking to my cat.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Fri, 02 Feb 2024 02:15:05 GMT, Scott Lurndal wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>>On Wed, 31 Jan 2024 23:25:25 +0000, Malcolm McLean wrote:
>>>
>>>Fun fact: one of the names for hex 7F was “rubout”.
>>
>> Additional fun fact. Rubout was the legend on the keycap on the ASR-33
>> used to rub out the prior character (the A in ASR means it has the
>> reader/punch). On paper tape, it means ignore the prior character.
>
>No, you had to overpunch the character to be ignored. Did that key
>automatically backspace the tape for you, or did you have to do it
>manually?

1) either way worked, depending on the software reading the tape
2) there was a button on the pt unit that backed up one character.

On 02/02/2024 14:47, David Brown wrote:
> On 02/02/2024 14:28, Malcolm McLean wrote:
>> On 02/02/2024 08:51, David Brown wrote:
>>> On 01/02/2024 23:38, Malcolm McLean wrote:
>>>> I'm sure you're capable of going through the exercise and then you
>>>> might gain a bit of insight on how to design such software systems.
>>>> And, no, arguing that you'd go for a monolithic program doesn't
>>>> necessarily mean that you are a "quivering jelly" at the thought of
>>>> writing several simpler ones. And in fact to start you off I
>>>> actually mentioned a few advantages of the pipeline approach.
>>>
>>> I am perfectly aware of the advantages and disadvantages of
>>> monolithic approaches.
>>>
>> Well it's kind of poroof of the pudding. Ben has several programs
>> connected by piplines and asked me what I thought of the design. I
>> said I'd go for a monolithinc approach. You criticised mem giving no
>> reason ither than that my oreferred approach was  monolithic. So any
>> reasonable erson would assume that you think that a monolithic
>> approach is in and of itself bad.
>
> No, they would not.
>
> But I don't think, based on your postings, you count as a "reasonable
> person".
>
>>
>> When invited to list the advantages and disadvantages if either, you
>> refused to do so. I am sure that you are capable of doing this, and
>> you are basically right. But you haven't actually done so. And it's
>> proof of the pudding.
>>
>> Thne fact is there is case for `Ben's approach, there's a case for my
>> approach, and maybe Ben's case is better. I've no objection to anyone
>> weighing in on that. But fundamentally you do not understand what it
>> means to offer an argument or how to make a case.
>>
>
> I know exactly what it means.  But I know when it is pointless, when the
> person on the other side pays not the slightest attention to what is
> being said and instead wanders off in their own little world with their
> own little ideas and their own independent terminology.
>
> What would be the point in giving reasons for anything, when you won't
> read them?  Why should I give arguments, when you will "counter" them by
> telling us that grass is blue, using your own definition for "blue"?
> I've put a lot of effort into trying to explain things to you - enough
> is enough.  I get more intelligent responses talking to my cat.
>
>
OK so here's how it went.

>> On 31/01/2024 23:36, Ben Bacarisse wrote:
>>>
>> An example where it's really useful not to care: I have a suite of
tools
>>> for doing toy cryptanalysis. Some apply various transformations and/or
>>> filters to byte streams and others collect and output (on stderr)
>>> various statistics. Plugging them together in various pipelines is
very
>>> handy when investigating an encrypted text. The output is almost
always
>>> "binary" in the sense that there would be not point in looking at on a
>> terminal.
>>
>> According to you, these tools are poorly designed. I don't think so.
>> How would you design them? Endless input and output file names to be
>> juggled and tidied up afterwards?
>>
> I'd write a monolithic program.

[David Brown]
It's very strange to me to see people that consider themselves
programmers talk about having multiple small functions to do specific
tasks and combining them into bigger functions to solve bigger problems,
yet are reduced to quivering jellies at the thought of multiple small
programs to do specific tasks that can be combined to solve bigger tasks.

Do you think the C standard library would be improved by a single
function "flubadub" that takes 20 parameters and can calculate
logarithms, print formatted text, allocate memory and write it all to a
file?

So Ben describes his system, then asks how I woud design to to remove
the pipelines (they don't actually seem to be binary pipelines, which is
what I was objecting to, but Ben says that because of the type of data
they pass they are as good as. Let that pass.) Would I create a lot of
temporary intermediate files? That would be one approach. But my answer
is no I wouldn't, I'd merge the programs into one monolithic program.
Then you wouldn't need either intermediate files or pipelines.

Now that shoukd be regarded as an entirely reasonable, unexceptional
answer to the question. Of course you can say "actually you are only
pretending to be reasonable. You're concocting a post hoc justification
for not having pipelines. You wouldn't really do that." And maybe
there's something in that. I represent and stand for hope, charity, and
reason, and always try to express these values. But I'm not pure reason.
I do have my human failings. However bascially it's an answer. And I go
on to discuss the pros and cons.

Now lets look at your contribution. It's unnecessarily contentious. It's
insulting. And whilst it does make a point, it's a rather silly one and
not really addressing the issue, which is about communications. And it
does seem that you think "distributed good, monolithic bad". You might
not exacty say it in as many words. But it's hard to see how someone
wouldn't gain that impression.

But of course you do have a reasonable degree of intelligence, and you
can easily be brought to see that monolithic systems have their
advantages as well as their disadvantages. You know that really already.
You've just blinded yourself to it through pure contentiousness.

Try to see these things.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 01.02.2024 21:09, Keith Thompson wrote:
>> [...] I would use semicolons instead:
>>
>> $ if file /tmp/garage.jpg | grep JPEG > /dev/null ; then echo "it is a jpeg" ; fi
>> it is a jpeg
>>
>> (I might also use "grep -q" rather than redirecting to /dev/null.)
>
> And probably also avoid multi-line code (to prevent the ^J confusion)
>
> file /tmp/garage.jpg | grep -q JPEG && echo "it is a jpeg"

Sure, that works, but I usually find the "if" form clearer. (It's not
multi-line.)

In C code or in a shell script, I'd write a similar "if" statement
across multiple lines. In an interactive shell, I commonly write
complex commands lie that on one line. YMMV.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 02/02/2024 01:13, Lawrence D'Oliveiro wrote:
> On Wed, 31 Jan 2024 23:25:25 +0000, Malcolm McLean wrote:
>
>> In ASCII, 0 means NUL, or "ignore".
>
> Fun fact: one of the names for hex 7F was “rubout”. On seven-track paper
> tape, if you made a mistake typing your program, intead of throwing away
> the tape and starting again, you could go back and punch out all the holes
> at that position to produce a “rubout” character. The meaning was “ignore
> this character”.

Also, over-punching all seven holes ment there was never any possibility
of it ever getting misread as anything else.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On 01/02/2024 15:07, Janis Papanagnou wrote:
>> On 01.02.2024 14:26, Malcolm McLean wrote:
>>> On 01/02/2024 13:02, Janis Papanagnou wrote:
>>>> Well, not necessarily. Let's leave the typical use case for a moment...
>>>>
>>>> It might also be analyzed and converted to a digitally represented
>>>> formula, say some TeX code, or e.g. like the formal syntax that the
>>>> lilypond program uses.
>>>>
>>> And ultimately converted to a non binary form. A list of 1s and 0s is
>>> seldom any use to the final consumer of the data.
>> No, I was speaking about an application that creates lilypond _input_,
>> which is a formal language to write notes, e.g. for evaluation by the
>> lilypond software, but not excluding other usages.
>>
>>>
>>>>> The two problems with hex
>>>>> dumps are that you've got to do mental arithmetic to convert 8 bit hex
>>>>> values into 16 or 32 bit fields,
>>>>
>>>> Hmm.. - have you inspected the man pages of the tools?
>>>>
>>> I just ran "man xxd". The man page contains this statement.
>>>
>>> The tool's weirdness matches its creator's brain. Use entirely at your
>>> own risk. Copy files. Trace it. Become a wizard.
>> This statement repelled you? (Can't help you here.)
>>
>>>> At least for 'od' I know it's easy per option...
>>>> od -c file # characters (or escapes and octals)
>>>> od -t x1 file # hex octets
>>>> od -t x2 file # words (two octets)
>>>> od -c -t x1 file # characters and octets
>>>>
>>> So a JPEG file starts with
>>> FF D8
>>> FF E0
>>> hi lo (length of the FF E0 segment)
>>>
>>> So we want the output
>>>
>>> FF D8 FF E0 [1000] to check that the segment markers are correct and FF
>>> E0 segment is genuinely a thousand bytes (or whatever it is). This isn't
>>> easy to achieve with a hex dump utility.
>> I don't know binary format details about jpg, so I cannot help you here.
>>
> JPEG is an extremely common binary file format and JPEG files will be found
> on most general purpose computers.

No. The loose term "JPEG file" usually refers to a file encoded using
either the JFIF or EXIF standard. Prior to the introduction of EXIF,
the loose term was used to refer only to JFIF files.

JPEG is the name for the image encoding usually carried in JFIF (or
EXIF) format files, but since you are actually discussing the file
format, you should probably use the right name for it: JFIF.

> All you need to know for the purposes of the discussion is that the first
> four bytes are segment identifiers and must have the values I gave,

My laptop contains lots of "JPEG files" that start FF D8 FF E1.

> So how would you achieve that in a convenient and non-error prone way?

One way is to use od like this:

$ od --endian=big -N6 -t x1u2 x.jpg
0000000 ff d8 ff e0 00 10
65496 65504 16
0000006

--
Ben.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On 31/01/2024 23:36, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On 30/01/2024 07:27, Tim Rentsch wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>
>>>>> On 29/01/2024 20:10, Tim Rentsch wrote:
>>>>>
>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> I've never used standard output for binary data.
>>>>>>> [...] it strikes me as a poor design decision.
>>>>>>
>>>>>> How so?
>>>>>
>>>>> Because the output can't be inspected by humans, and because it might
>>>>> have unusual effects if passed though systems designed to handle
>>>>> human-readable text.
>> Maybe you are not used to a system where it's trivial to inspect such
>> data. When "some_prog" produces data that are not compatible with the
>> current terminal settings, "some_prog | hd" shows a hex dump instead.
>> The need to do this does not make "some_prog" poorly designed. It may
>> simply mean that the output is /intended/ for further processing.
>>
>>> For instance in some systems designed to receive
>>>>> ASCII text, there is no distinction between the nul byte and "waiting
>>>>> for next data byte". Obviously this will cause difficuties if the data
>>>>> is binary.
>>>>> Also many binary formats can't easily be extended, so you can pass one
>>>>> image and that's all. While it is possible to devise a text format
>>>>> which is similar, in practice text formats usually have enough
>>>>> redundancy to be easily extended.
>>>>>
>>>>> So it's harder to correct errors, more prone to errors, and harder to
>>>>> extend.
>>>> Your reasoning is all gobbledygook. Your comments reflect only
>>>> limitations in your thinking, not any essential truth about using
>>>> standard out for binary data.
>>>>
>>> I must admit that it's nothing I have ever done or considered doing.
>>>
>>> However standard output is designed for text and not binary ouput.
>> What is your evidence? stdout was just designed for output (as far as I
>> can tell) and, anyway, what is the distinction you are making between
>> binary and text? iconv --from ACSII --to EBCDIC-UK will produce
>> something that is "logically" text on stdout, but it might look like
>> binary to you.
>> An example where it's really useful not to care: I have a suite of tools
>> for doing toy cryptanalysis. Some apply various transformations and/or
>> filters to byte streams and others collect and output (on stderr)
>> various statistics. Plugging them together in various pipelines is very
>> handy when investigating an encrypted text. The output is almost always
>> "binary" in the sense that there would be not point in looking at on a
>> terminal.
>> According to you, these tools are poorly designed. I don't think so.
>> How would you design them? Endless input and output file names to be
>> juggled and tidied up afterwards?
>>
> I'd write a monolithic program.
> Load the encryoted text into memory, and then pass it to subroutines to do
> the various analyses.
> You can of course process it, and then pass the processed output to other
> programs. And that does have a point if the program which is acceoting the
> processed outout is doing something which has no necessary connection to
> cryptanalysis. So for example a program to produce a pie chart from a list
> of letter frequencies. But if it's transforming the encrypted text in
> intricate and specialised ways, then analysing the transformed text in
> other specialised and intricate ways, then firstly you've probably
> introduced coupling and dependency between the two programs, and secondly
> you're probably at some point going to want to modify the second program in
> the pipeline to look at the raw data.

I don't think you understand the design at all. What coupling? And why
would I modify the program to inspect the data when there are several
inspection program that can be inserted before or after to do just that?

I've commented elsewhere on why I think a monolithic program is not a
good design, so I won't repeat that here. I just don't understand any
of your objections to my design. Specifically, you don't address the
fact that you claim it's wrong simply because the data going to stdout
are binary. Have you abandoned that generic criticism? Is there why
you split the thread with two replies?

--
Ben.

bart <bc@freeuk.com> writes:

> On 31/01/2024 23:36, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On 30/01/2024 07:27, Tim Rentsch wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>
>>>>> On 29/01/2024 20:10, Tim Rentsch wrote:
>>>>>
>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> I've never used standard output for binary data.
>>>>>>> [...] it strikes me as a poor design decision.
>>>>>>
>>>>>> How so?
>>>>>
>>>>> Because the output can't be inspected by humans, and because it might
>>>>> have unusual effects if passed though systems designed to handle
>>>>> human-readable text.
>> Maybe you are not used to a system where it's trivial to inspect such
>> data. When "some_prog" produces data that are not compatible with the
>> current terminal settings, "some_prog | hd" shows a hex dump instead.
>> The need to do this does not make "some_prog" poorly designed. It may
>> simply mean that the output is /intended/ for further processing.
>>
>>> For instance in some systems designed to receive
>>>>> ASCII text, there is no distinction between the nul byte and "waiting
>>>>> for next data byte". Obviously this will cause difficuties if the data
>>>>> is binary.
>>>>> Also many binary formats can't easily be extended, so you can pass one
>>>>> image and that's all. While it is possible to devise a text format
>>>>> which is similar, in practice text formats usually have enough
>>>>> redundancy to be easily extended.
>>>>>
>>>>> So it's harder to correct errors, more prone to errors, and harder to
>>>>> extend.
>>>> Your reasoning is all gobbledygook. Your comments reflect only
>>>> limitations in your thinking, not any essential truth about using
>>>> standard out for binary data.
>>>>
>>> I must admit that it's nothing I have ever done or considered doing.
>>>
>>> However standard output is designed for text and not binary ouput.
>> What is your evidence? stdout was just designed for output (as far as I
>> can tell) and, anyway, what is the distinction you are making between
>> binary and text? iconv --from ACSII --to EBCDIC-UK will produce
>> something that is "logically" text on stdout, but it might look like
>> binary to you.
>> An example where it's really useful not to care: I have a suite of tools
>> for doing toy cryptanalysis. Some apply various transformations and/or
>> filters to byte streams and others collect and output (on stderr)
>> various statistics. Plugging them together in various pipelines is very
>> handy when investigating an encrypted text. The output is almost always
>> "binary" in the sense that there would be not point in looking at on a
>> terminal.
>> According to you, these tools are poorly designed. I don't think so.
>> How would you design them? Endless input and output file names to be
>> juggled and tidied up afterwards?
>
> I think they're poorly designed too.

I am curious to read your reasoning...

> From the POV of interactive console programs, they /are/ poor. But the
> mistake is thinking that they are actual programs or commands, when really
> they are just filters. They are not designed to be standalone
> commands.

So it's a bad design, not because of the nature of the data ("binary"
vs. "text") but because you claim a filter is not a command? Where does
that notion come from?

--
Ben.

On 2024-02-02, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> I've commented elsewhere on why I think a monolithic program is not a
> good design, so I won't repeat that here.

All the programs I use are some kind of "lithic"; not so much mono-
as neo-.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Fri, 2 Feb 2024 10:57:46 +0000, bart wrote:

> On 02/02/2024 04:57, Lawrence D'Oliveiro wrote:
>
>> On Thu, 1 Feb 2024 12:50:36 +0000, bart wrote:
>>
>>> For all I know, this is the usenet equivalent of Mornington Crescent
>>> ...
>> You can’t get far in C without knowing POSIX. C on Windows is, let’s
>> face it, a crippled language.
>
> It sounds like you're the one who would be crippled without your beloved
> POSIX.

Given your ongoing tales of woe, wrestling cross-platform C code to behave
nicely on Windows, I wouldn’t change places for the world.

On Fri, 2 Feb 2024 07:18:51 +0000, Malcolm McLean wrote:

> On 02/02/2024 04:57, Lawrence D'Oliveiro wrote:
>
>> On Thu, 1 Feb 2024 12:50:36 +0000, bart wrote:
>>
>>> For all I know, this is the usenet equivalent of Mornington Crescent
>>> ...
>>
>> You can’t get far in C without knowing POSIX. C on Windows is, let’s
>> face it, a crippled language.
>
> My program Crossword Designer is a Windows program and is written
> entirely in C.

As the saying goes about teaching a bear to dance, it’s not that the bear
dances badly, but that it can be persuaded to dance at all.

On 02/02/2024 21:40, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On 01/02/2024 15:07, Janis Papanagnou wrote:
>>> On 01.02.2024 14:26, Malcolm McLean wrote:
>>>> On 01/02/2024 13:02, Janis Papanagnou wrote:
>>>>> Well, not necessarily. Let's leave the typical use case for a moment...
>>>>>
>>>>> It might also be analyzed and converted to a digitally represented
>>>>> formula, say some TeX code, or e.g. like the formal syntax that the
>>>>> lilypond program uses.
>>>>>
>>>> And ultimately converted to a non binary form. A list of 1s and 0s is
>>>> seldom any use to the final consumer of the data.
>>> No, I was speaking about an application that creates lilypond _input_,
>>> which is a formal language to write notes, e.g. for evaluation by the
>>> lilypond software, but not excluding other usages.
>>>
>>>>
>>>>>> The two problems with hex
>>>>>> dumps are that you've got to do mental arithmetic to convert 8 bit hex
>>>>>> values into 16 or 32 bit fields,
>>>>>
>>>>> Hmm.. - have you inspected the man pages of the tools?
>>>>>
>>>> I just ran "man xxd". The man page contains this statement.
>>>>
>>>> The tool's weirdness matches its creator's brain. Use entirely at your
>>>> own risk. Copy files. Trace it. Become a wizard.
>>> This statement repelled you? (Can't help you here.)
>>>
>>>>> At least for 'od' I know it's easy per option...
>>>>> od -c file # characters (or escapes and octals)
>>>>> od -t x1 file # hex octets
>>>>> od -t x2 file # words (two octets)
>>>>> od -c -t x1 file # characters and octets
>>>>>
>>>> So a JPEG file starts with
>>>> FF D8
>>>> FF E0
>>>> hi lo (length of the FF E0 segment)
>>>>
>>>> So we want the output
>>>>
>>>> FF D8 FF E0 [1000] to check that the segment markers are correct and FF
>>>> E0 segment is genuinely a thousand bytes (or whatever it is). This isn't
>>>> easy to achieve with a hex dump utility.
>>> I don't know binary format details about jpg, so I cannot help you here.
>>>
>> JPEG is an extremely common binary file format and JPEG files will be found
>> on most general purpose computers.
>
> No. The loose term "JPEG file" usually refers to a file encoded using
> either the JFIF or EXIF standard. Prior to the introduction of EXIF,
> the loose term was used to refer only to JFIF files.
>
> JPEG is the name for the image encoding usually carried in JFIF (or
> EXIF) format files, but since you are actually discussing the file
> format, you should probably use the right name for it: JFIF.
>
>> All you need to know for the purposes of the discussion is that the first
>> four bytes are segment identifiers and must have the values I gave,
>
> My laptop contains lots of "JPEG files" that start FF D8 FF E1.
>

Which is of course exactly the sort of problem we are talking about.

The users will say "I've got a JPEG file on my machine and it doesn't
work". And obviously you will assume that the JPEGs are in the same
format that all the other customers are using. So tech support will go
through with them "Is it in the right directory? Have you selected
"JPEG"? Did you press "Load"? It still doesn't work, and they have to
escalate to the programmers.
And it's only when you actually get the binaries that you realise why it
isn't working.
>> So how would you achieve that in a convenient and non-error prone way?
>
> One way is to use od like this:
>
> $ od --endian=big -N6 -t x1u2 x.jpg
> 0000000 ff d8 ff e0 00 10
> 65496 65504 16
> 0000006
>
Yes, that's what we want. Hex and decimal fields. Now we can see what's
wrong. In the example, we were expecting a thousand bytes, and in fact
it's sixteen. So obviously someone somewhere is very mistaken about what
the segment should hold.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On 01/02/2024 13:24, Tim Rentsch wrote:
>
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> You admit this with "not tested". Says it all. '"Understandig Unix" is
>>> an intellectually useless achievement. You might have to do it if you
>>> have to use the system and debug and trouble shoot. But it's nothing
>>> to be proud about.
>>
>> You're an idiot. As usual trying to have a useful discussion
>> with you has turned out to be a complete waste of time.
>
> Some things are interesting in themselves and worth talking about at
> lenght. Like how Haskell builds up functions of functions. Other
> things really aren't. And how to set up a Unix pipeline is one of
> those that really aren't (unless actually faced with a such a system
> and with a practical need to do it).
>
> I think you have the intelligence to understand this, if you'd just
> understand where I am coming from. This arrogant and dismissive
> attitude does not become you.

The arrogance and dismissive attitude is on your side, not
mine. I don't think everyone is an idiot. Just you.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 1/24/24 16:11, Kaz Kylheku wrote:
>
>> On 2024-01-24, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>
>>> On 1/24/24 03:10, Janis Papanagnou wrote:
>>>
>>>> On 23.01.2024 23:37, Kalevi Kolttonen wrote:
>>>>
>>>>> [...] I am
>>>>> pretty sure that not all computer languages
>>>>> provide guarantees about the order of evaluation.
>>>>
>>>> What?!
>>>
>>> Could you explain what surprises you about that statement? As quoted,
>>> it's a general statement which includes C: "Except as specified later,
>>> side effects and value computations of subexpressions are unsequenced."
>>
>> Pretty much any language has to guarantee *something* about
>> order of evaluation, somewhere.
>
> Not the functional languages, I believe - but I've only heard about such
> languages, not used them.
>
>> Like for instance that calculating output is not possible before a
>> needed input is available.
>
> Oddly enough, for a long time the C standard never said anything about
> that issue. I argued that this was logically necessary, and few people
> disagreed with that argument, but I couldn't point to wording in the
> standard to support that claim.
>
> That changed when they added support for multi-threaded code to C in
> C2011. That required the standard to be very explicit about which things
> could happen simultaneously in different threads, and which things had
> to occur in a specified order. All of the wording about "sequenced" was
> first introduced at that time. [...]

The timing may have been the same, but the motivation for the
new language about sequencing actually occurred much earlier.
For quite a long time before C11, and IIRC even before C99,
the ISO C committee was looking for a formal model to describe
the sequencing rules. There were proposals for various formal
models, none of which were thought to suffice. So it wasn't
just adding threading to C that prompted adding better language
regarding sequencing rules.

On 2/2/2024 5:43 PM, Lawrence D'Oliveiro wrote:
> On Fri, 2 Feb 2024 10:57:46 +0000, bart wrote:
>
>> On 02/02/2024 04:57, Lawrence D'Oliveiro wrote:
>>
>>> On Thu, 1 Feb 2024 12:50:36 +0000, bart wrote:
>>>
>>>> For all I know, this is the usenet equivalent of Mornington Crescent
>>>> ...
>>> You can’t get far in C without knowing POSIX. C on Windows is, let’s
>>> face it, a crippled language.
>>
>> It sounds like you're the one who would be crippled without your beloved
>> POSIX.
>
> Given your ongoing tales of woe, wrestling cross-platform C code to behave
> nicely on Windows, I wouldn’t change places for the world.

vcpkg is not all that bad. :^)

On Sat, 3 Feb 2024 12:47:29 -0800, Chris M. Thomasson wrote:

> On 2/2/2024 5:43 PM, Lawrence D'Oliveiro wrote:
>
>> Given your ongoing tales of woe, wrestling cross-platform C code to
>> behave nicely on Windows, I wouldn’t change places for the world.
>
> vcpkg is not all that bad. :^)

I’m sure vcpkg, winget, nuget, chocolatey, anaconda and all the rest of
them are not all that bad, at least not individually.

Having to use more than one of them, on the same system, would be where it
starts to go downhill ...

On 2/4/2024 2:36 PM, Lawrence D'Oliveiro wrote:
> On Sat, 3 Feb 2024 12:47:29 -0800, Chris M. Thomasson wrote:
>
>> On 2/2/2024 5:43 PM, Lawrence D'Oliveiro wrote:
>>
>>> Given your ongoing tales of woe, wrestling cross-platform C code to
>>> behave nicely on Windows, I wouldn’t change places for the world.
>>
>> vcpkg is not all that bad. :^)
>
> I’m sure vcpkg, winget, nuget, chocolatey, anaconda and all the rest of
> them are not all that bad, at least not individually.
>
> Having to use more than one of them, on the same system, would be where it
> starts to go downhill ...

Pick one that works for your current setup, and use it. Fair enough?

On Sun, 4 Feb 2024 15:26:02 -0800, Chris M. Thomasson wrote:

> On 2/4/2024 2:36 PM, Lawrence D'Oliveiro wrote:
>
>> On Sat, 3 Feb 2024 12:47:29 -0800, Chris M. Thomasson wrote:
>>
>>> On 2/2/2024 5:43 PM, Lawrence D'Oliveiro wrote:
>>>
>>>> Given your ongoing tales of woe, wrestling cross-platform C code to
>>>> behave nicely on Windows, I wouldn’t change places for the world.
>>>
>>> vcpkg is not all that bad. :^)
>>
>> I’m sure vcpkg, winget, nuget, chocolatey, anaconda and all the rest of
>> them are not all that bad, at least not individually.
>>
>> Having to use more than one of them, on the same system, would be where
>> it starts to go downhill ...
>
> Pick one that works for your current setup, and use it. Fair enough?

But their application areas only partially overlap, if at all. What if the
package you want is only available in a different, incompatible format?

This is all part of the fragmentation of Windows development.

On 2/4/2024 5:49 PM, Lawrence D'Oliveiro wrote:
> On Sun, 4 Feb 2024 15:26:02 -0800, Chris M. Thomasson wrote:
>
>> On 2/4/2024 2:36 PM, Lawrence D'Oliveiro wrote:
>>
>>> On Sat, 3 Feb 2024 12:47:29 -0800, Chris M. Thomasson wrote:
>>>
>>>> On 2/2/2024 5:43 PM, Lawrence D'Oliveiro wrote:
>>>>
>>>>> Given your ongoing tales of woe, wrestling cross-platform C code to
>>>>> behave nicely on Windows, I wouldn’t change places for the world.
>>>>
>>>> vcpkg is not all that bad. :^)
>>>
>>> I’m sure vcpkg, winget, nuget, chocolatey, anaconda and all the rest of
>>> them are not all that bad, at least not individually.
>>>
>>> Having to use more than one of them, on the same system, would be where
>>> it starts to go downhill ...
>>
>> Pick one that works for your current setup, and use it. Fair enough?
>
> But their application areas only partially overlap, if at all. What if the
> package you want is only available in a different, incompatible format?

Shit happens.

> This is all part of the fragmentation of Windows development.

Make it work! ;^)

On Tue, 30 Jan 2024 17:25:31 +0100, David Brown
<david.brown@hesbynett.no> wrote:

> On 30/01/2024 16:49, Malcolm McLean wrote:
[nonsense as usual]
> Mixing binary data with formatted text data is very unlikely to be
> useful. fwrite() is perfectly good for writing binary data - it would
> make no sense to have some awkward printf specifier to do this. (What
> would the specifier even be? It would need to take two items of data -
> a pointer and a length - and thus be very different from existing
> specifiers.)
>
"%.*s" takes length and pointer, which IMO is not VERY different.

It does stop (prematurely?) if the data/buffer contains \0 .

[snip rest]

On Wed, 31 Jan 2024 06:10:56 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:

> On Tue, 30 Jan 2024 20:29:17 +0100, David Brown wrote:
>
> > stdout and stdin were apparently available in FORTRAN in the 1950's.
>
> There was a convention that channel 5 was the card reader, and 6 was the
> line printer.
>
and 7 the card punch, at least from FIV/66 up. Data you expected to
reprocess, like a Unix filter's stdout, would go to 7, and data you
wanted a human to see, like stderr, to 6.

> When interactive systems came along later, this became channel 5 for
> keyboard input, and 6 for terminal output.
>
and 7 got lost -- the same way that ssh -t (and docker -t) loses the
distinction between stdout and stderr, it's all just output

> What happened to channels 1, 2, 3 & 4? Don’t know.