On 1/17/2024 4:47 PM, bart wrote:
> On 18/01/2024 00:25, Kaz Kylheku wrote:
>> On 2024-01-17, bart <bc@freeuk.com> wrote:
>>> On 17/01/2024 22:18, Scott Lurndal wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>> On 17/01/2024 18:47, Kaz Kylheku wrote:
>>>>>> On 2024-01-17, bart <bc@freeuk.com> wrote:
>>>>
>>>>>> A good many scripting languages require a shell in order to build,
>>>>>> such as for runing a ./configure script.
>>>>>
>>>>> Funnily enough, mine don't.
>>>>
>>>> Perhaps you find it humorous.   A posix shell comes with pretty
>>>> much every system used for software development (even windows
>>>> has WSL for serious software development).
>>>
>>> I suspect it's more that it's been browbeaten into having such a system
>>> because so many developers were deliberately, inadvertently or
>>> spitefully building in so many dependencies from the Unix world into
>>> their software and their procedures.
>>
>> You can get shell scripts running on Windows.
>
> You mean via layers like WSL or MSYS2 or CYGWIN? I don't really consider
> that running on Windows.
[...]

Shit happens! ;^o

On 1/18/2024 4:00 AM, David Brown wrote:
> On 17/01/2024 22:00, Chris M. Thomasson wrote:
>> On 1/17/2024 4:43 AM, David Brown wrote:
>>> On 17/01/2024 02:04, Chris M. Thomasson wrote:
>>>> On 1/16/2024 6:06 AM, David Brown wrote:
>>>
>>>>> Well, you don't often write inline assembly - its rare to write it.
>>>>> It's typically the kind of thing you write once for your particular
>>>>> instruction, then stick it away in a header somewhere.  You might
>>>>> use it often, but you don't need to read or edit the code often.[...]
>>>>
>>>> As soon as you use inline assembler in a file, you sort of "need" to?
>>>
>>> Nonsense.
>>
>> If I use inline asm in a file, I at least need to add in comments that
>> this is arch specific code. A macro for the arch also might be in
>> order. So, if the user compiles it on a different arch, well, the
>> inline asm is eluded. Why is that wrong? You never did that before?
>>
>
> There's nothing at all wrong with that.  My disagreement was with your
> suggestion that people using inline assembly (defined in a header
> written by someone else) need to be able to read and/or edit the code.
>

Completely fair enough. Thanks, David! :^)

On 2024-01-18, bart <bc@freeuk.com> wrote:
> On 18/01/2024 04:30, Kaz Kylheku wrote:
>> On 2024-01-18, bart <bc@freeuk.com> wrote:
>
>>> You mean via layers like WSL or MSYS2 or CYGWIN? I don't really consider
>>> that running on Windows.
>>
>> What is it? To the left of Windows? Behind Windows? Under Windows?
>>
>> It doesn't matter which one of these prepositions it is, because in this
>> situation being discussed all those programs are doing is providing an
>> environment for building something.
>
> Let's consider an OS like Android, to avoid a made-up one. (Put aside
> the likelihood that deep inside Android might be a Linux core. Think of
> the glossy-looking consumer OS that everyone knows.)

Android is a Linux-based OS. It has a C library called Bionic.

There is an environment you can install on Android called Termux.

In Termux you get a shell with utilities and numerous common packages.
git, ssh, you name it. You can compile programs like on other Unix-likes.

I ported TXR to Android with Termux in literally minutes, originally.

When Android rolled out pointer tagging, I had to do a few things to
make it work, because it clashes with the NaN-boxing technique used
for representing values. We turn on a build option
CONFIG_NAN_BOXING_STRIP_TAG invented for that, which will strip
the pointer tags from the heaps allocated from malloc, and put
them back when calling free. In between that, we refer to the objects
via tag-free pointers.

In the test suite, a few things have to be done differently on Android.
It is detected like this;

(if (ignerr (dlsym (dlopen "libandroid.so") "AAsset_close"))
:android
( ... else detect other platforms ...))

I.e. if we are able to successfully open a library called
"libandroid.so" and resolve the symbol "AAsset_close", then
we conclude we are running on Android. I probably could have
relied on some clues from the kernel.

In other ways, it's just another Linux.

> Now, somebody brings out some piece of software that only builds under
> Android.
>
> To build it under Linux, requires installing a vast virtual Android OS
> to do that.

There is application software for Android that cannot run on any
other platform. People run this via emulators.

> Would you consider that being able to build 'under Linux'?

Tentatively, yes, if:

- you can prepare the files that need to be built just by
storing them in the host Linux filesystem.

- you can dispatch the build process from Linux, from a script.
(No manual fiddling with the GUI of some emulator, and no
remote logins to an emulator to run anything).

- you can collect the deliverables in the host filesystem.

such that this whole thing can be automated on a Linux build server,
that runs without any manual steps, and which doesn't have to use
networking to connect to any emulated machine to copy anything
in or out.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 18/01/2024 20:47, David Brown wrote:
> On 18/01/2024 16:16, bart wrote:

>> Could you, in good faith, provide sources to that project and say it
>> builds 'under Linux, no problem'. Never mind the considerable
>> dependencies they would need and the significant likelihood of failure.
>>
>
> Dependencies are part of life with computers.  A Windows installation
> without additional software gives you Minesweeper and Wordpad.  How can
> you possibly justify thinking that installing msys2 and mingw-64 for a
> compilation means you are "not building under Windows" while installing
> MSVC means you /are/ "building under Windows"?  The MSVC installation is
> 10 times the size of mingw-64.

Actually I don't consider an MSVC dependency much better that MSYS2 and
WSL. At least WSL works; I haven't had a working MSVC for years.

MSVC/VS/etc is a vast, corporate monstrosity, as is most of Windows
these days.

But you can still do things on a small scale and informally as I do
within a small corner of Windows.

My last analogy didn't work very well, I'll try another one. Suppose you
wanted a product but it only comes in kit form that you have to build
yourself.

It promises it only needs a hammer and a screwdriver. But it turns out
there is one extra thing you need: a massive great factory next door
that contains all the specialist equipment, processes and manpower
needed to complete that job.

Apart from that, then sure: you can assemble this 'at home'.

On 1/16/2024 6:21 PM, Kaz Kylheku wrote:
> On 2024-01-17, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 1/16/2024 5:38 AM, David Brown wrote:
>>> On 16/01/2024 03:18, Chris M. Thomasson wrote:
>>>> On 1/15/2024 3:24 PM, Kaz Kylheku wrote:
>>>>> On 2024-01-15, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>>>>> On 1/15/2024 8:29 AM, David Brown wrote:
>>>>>>> On 15/01/2024 17:04, David Brown wrote:
>>>>>>>> On 15/01/2024 08:40, Kaz Kylheku wrote:
>> [...]
>>> You've mentioned this many times - do you have a reference that gives
>>> the source of this function (at the time when there was an issue), and a
>>> description or report of what you think gcc did wrong?  I am curious as
>>> to whether it was a bug in the code or a bug in gcc (gcc is certainly
>>> not bug-free).
>>>
>>
>> I think I found it David!
>>
>> https://groups.google.com/g/comp.programming.threads/c/Y_Y2DZOWErM/m/nuyEoKq0onUJ
>
> David Schwartz has since been acquired by and merged with David
> Butenhoff, to form David Schwartzenhoff. The new motto is "bigger living
> through slightly less concurrency".
>

The tale of Multi_David! :^D

On 1/15/2024 10:55 AM, bart wrote:
> On 15/01/2024 17:35, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>
>>> You're having a laugh, surely?
>>
>> No.  I'm serious. [DWORD] is useless cruft.
>
> I don't use [DWORD], whatever that means.
>
> Meanwhile %% in front of every register name, f after a label, and ""
> and \n and \t on every line is useful cruft!
>
>>> AT&T is bad enough even without the
>>> travesty of it displayed here:
>>>
>>>                "jmp    2f\n"
>>>                "3:\tmovsx %%bx, %%rbx\n\t"
>>
>> If you don't understand the standard C escapes, you really
>> should go back to read the standard carefluly.
>
> I understand C escape codes. I am asking WHAT THE FUCK ARE THEY DOING IN
> EVERY LINE OF AN ASSEMBLY PROGRAM?
>
> You're doing this on purpose aren't you?
>
>
>>
>>>
>>> What's with the strings, newline and tab escapes? What's that 'f' for?
>>
>> RTFM for the architecture dependent assembler that the compiler
>> driver will end up calling to build the output object file.
>
> So you don't actually know.
>
> Just admit that my approach to inline assembler is better and give it up.

Next time I have to inline asm, I will play this music in my office,
really loud! lol. https://youtu.be/PeYUTbU_iTw

On 1/18/2024 9:42 PM, Chris M. Thomasson wrote:
> On 1/15/2024 10:55 AM, bart wrote:
>> On 15/01/2024 17:35, Scott Lurndal wrote:
>>> bart <bc@freeuk.com> writes:
>>
>>>> You're having a laugh, surely?
>>>
>>> No.  I'm serious. [DWORD] is useless cruft.
>>
>> I don't use [DWORD], whatever that means.
>>
>> Meanwhile %% in front of every register name, f after a label, and ""
>> and \n and \t on every line is useful cruft!
>>
>>>> AT&T is bad enough even without the
>>>> travesty of it displayed here:
>>>>
>>>>                "jmp    2f\n"
>>>>                "3:\tmovsx %%bx, %%rbx\n\t"
>>>
>>> If you don't understand the standard C escapes, you really
>>> should go back to read the standard carefluly.
>>
>> I understand C escape codes. I am asking WHAT THE FUCK ARE THEY DOING
>> IN EVERY LINE OF AN ASSEMBLY PROGRAM?
>>
>> You're doing this on purpose aren't you?
>>
>>
>>>
>>>>
>>>> What's with the strings, newline and tab escapes? What's that 'f' for?
>>>
>>> RTFM for the architecture dependent assembler that the compiler
>>> driver will end up calling to build the output object file.
>>
>> So you don't actually know.
>>
>> Just admit that my approach to inline assembler is better and give it up.
>
> Next time I have to inline asm, I will play this music in my office,
> really loud! lol. https://youtu.be/PeYUTbU_iTw

Start porting my asm to inline asm...

On 1/18/2024 4:00 AM, David Brown wrote:
> On 17/01/2024 22:00, Chris M. Thomasson wrote:
>> On 1/17/2024 4:43 AM, David Brown wrote:
>>> On 17/01/2024 02:04, Chris M. Thomasson wrote:
>>>> On 1/16/2024 6:06 AM, David Brown wrote:
>>>
>>>>> Well, you don't often write inline assembly - its rare to write it.
>>>>> It's typically the kind of thing you write once for your particular
>>>>> instruction, then stick it away in a header somewhere.  You might
>>>>> use it often, but you don't need to read or edit the code often.[...]
>>>>
>>>> As soon as you use inline assembler in a file, you sort of "need" to?
>>>
>>> Nonsense.
>>
>> If I use inline asm in a file, I at least need to add in comments that
>> this is arch specific code. A macro for the arch also might be in
>> order. So, if the user compiles it on a different arch, well, the
>> inline asm is eluded. Why is that wrong? You never did that before?
>>
>
> There's nothing at all wrong with that.  My disagreement was with your
> suggestion that people using inline assembly (defined in a header
> written by someone else) need to be able to read and/or edit the code.
>

Did I necessarily imply that? If so, I apologize.

On 1/18/2024 1:28 PM, Chris M. Thomasson wrote:
> On 1/18/2024 4:00 AM, David Brown wrote:
>> On 17/01/2024 22:00, Chris M. Thomasson wrote:
>>> On 1/17/2024 4:43 AM, David Brown wrote:
>>>> On 17/01/2024 02:04, Chris M. Thomasson wrote:
>>>>> On 1/16/2024 6:06 AM, David Brown wrote:
>>>>
>>>>>> Well, you don't often write inline assembly - its rare to write
>>>>>> it. It's typically the kind of thing you write once for your
>>>>>> particular instruction, then stick it away in a header somewhere.
>>>>>> You might use it often, but you don't need to read or edit the
>>>>>> code often.[...]
>>>>>
>>>>> As soon as you use inline assembler in a file, you sort of "need" to?
>>>>
>>>> Nonsense.
>>>
>>> If I use inline asm in a file, I at least need to add in comments
>>> that this is arch specific code. A macro for the arch also might be
>>> in order. So, if the user compiles it on a different arch, well, the
>>> inline asm is eluded. Why is that wrong? You never did that before?
>>>
>>
>> There's nothing at all wrong with that.  My disagreement was with your
>> suggestion that people using inline assembly (defined in a header
>> written by someone else) need to be able to read and/or edit the code.
>>
>
> Completely fair enough. Thanks, David! :^)

Actually, iirc, my friend Joe Seigh had a nice inline impl of cmpxchg8b
over on comp.programming.threads many moons ago...

On 1/18/2024 9:55 PM, Chris M. Thomasson wrote:
> On 1/18/2024 4:00 AM, David Brown wrote:
>> On 17/01/2024 22:00, Chris M. Thomasson wrote:
>>> On 1/17/2024 4:43 AM, David Brown wrote:
>>>> On 17/01/2024 02:04, Chris M. Thomasson wrote:
>>>>> On 1/16/2024 6:06 AM, David Brown wrote:
>>>>
>>>>>> Well, you don't often write inline assembly - its rare to write
>>>>>> it. It's typically the kind of thing you write once for your
>>>>>> particular instruction, then stick it away in a header somewhere.
>>>>>> You might use it often, but you don't need to read or edit the
>>>>>> code often.[...]
>>>>>
>>>>> As soon as you use inline assembler in a file, you sort of "need" to?
>>>>
>>>> Nonsense.
>>>
>>> If I use inline asm in a file, I at least need to add in comments
>>> that this is arch specific code. A macro for the arch also might be
>>> in order. So, if the user compiles it on a different arch, well, the
>>> inline asm is eluded. Why is that wrong? You never did that before?
>>>
>>
>> There's nothing at all wrong with that.  My disagreement was with your
>> suggestion that people using inline assembly (defined in a header
>> written by someone else) need to be able to read and/or edit the code.
>>
>
> Did I necessarily imply that? If so, I apologize.

Wrt my sync code, alter it and you break it. Don't try to play games
with it. If you do, I am not liable.

On 18/01/2024 20:15, bart wrote:
> On 06/01/2024 07:39, David Brown wrote:
>> On 05/01/2024 19:42, Kaz Kylheku wrote:
>>> On 2024-01-05, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>> When you wrote "in Linux", I wondered if you were being imprecise, but
>>>> in fact that code is in the Linux kernel.
>>>>
>>>> That means the macros aren't directly available to normal C code, but
>>>> you can always copy their definitions (*if* you're using a compiler
>>>> that supports the __builtin_types_compatible_p extension).
>>>
>>> You can always copy their definitions, if you're using a compiler
>>> that doesn't arbitrarily define __GNUC__ without providing the
>>> associated behaviors:
>>>
>>> #ifdef __GNU__
>>>
>>> // define array_size in the Linux kernel way
>>>
>>> #else
>>>
>>> #define arrray_size(x) (sizeof (x)/sizeof *(x))
>>>
>>> #endif
>>>
>>> If you regularly build the code with a compiler that provides GNU
>>> extensions (like as part of your CI), you're covered, even if you're
>>> going to production with something else.
>>>
>>> I use C++ this way in C projects; I have some macro features that
>>> provide extra checks under C++. I get the benefit even if I just
>>> compile the code as C++ only once before every release.
>>>
>>
>> That is a good tactic if your code needs to be used with compilers
>> that don't have such features for static checking (perhaps you are
>> releasing your source code, and can't influence the tools or settings
>> users use). In a way, you are using gcc (or C++) as a linter.
>>
>> I've done this myself when the actual target compiler had little in
>> the way of static checking - I ran gcc in parallel, for a different
>> target (the generated output was ignored), but with lots of warning
>> flags that the real compiler did not support.
>>
>
> This is pretty much how in the past I have suggested people use Tiny C:
> use it for very fast compilation turnaround. Use gcc from time to time
> for better error checking, and for production builds for faster code.

My use was not like that. I used the other compiler because I had no
choice - I would not intentionally use a weaker compiler when a better
one was available, certainly not for something as irrelevant as compile
speed. But gcc does not support all the devices I have used over the years.

And I certainly don't run the weak tool regularly and gcc occasionally -
that defeats the purpose of static error checking, when you want the
results as soon as possible. As I said, I would run them in parallel,
and if I were only going to run one, it would be gcc - the sooner a bug
or potential problem is found, the better. (Thus it makes sense to use
an IDE or advanced editor that checks many things on the fly, as you type.)

If you are running more advanced static analysis tools, such as
clang-analyzer, that can take a long time doing simulated execution and
inter-module analysis, then you might not want to run it for every build.

As a rule of thumb, if the static analysis takes less time than a sip of
coffee, do it on every build. If it takes as long as making coffee, do
it when you are making coffee.

>
> Another is for situations where obtaining the small-footprint Tiny C
> compiler is simpler, or where it can be bundled with your source code.
>

That's very rarely a realistic scenario for anyone, and never has been
for me.

> Yet another is when you have a compiler for another language that
> targets C code. Since the program has already been verified, the C code
> should be correct. Then extensive static checking is not needed; you
> just want a fast backend that doesn't take up 95% of the overall
> compilation time.

I think it is better to say that when someone who has no connection to
the development process, but simply receives the source code ready-made
and fully debugged and tested, they have no need of extensive static
checking. And that's true - any appropriate static checks should have
been made already, so the code should compile warning-free (and
obviously error-free). But usually the build times here are irrelevant
- this person will build once, as part of the installation procedure -
and may run the program many times. So that build should be done with a
good compiler, not a "tiny" compiler, with optimisations enabled. And
it might as well have static error checking enabled as the extra cost in
time is negligible, and it might catch something the developer had not
expected.

If there is a good reason not to use a top quality compiler - such as
lack of support for a particular target, or source code that uses
extensions from a different tool - your hand is forced. If not, then I
simply can't see any realistic circumstance where you would not want to
use the best tools you have available. (And if you have a compiler
better than gcc, use that instead - for at least some uses, icc or clang
can be better than gcc.)

>
> Again, use gcc for a production version for some extra speed, but it is
> not essential to have it.
>
> This is a compiler you've dismissed as a toy.

Yes, TCC is a toy. That does not mean it is not impressive in many
ways, but it has almost no real-world use-cases where gcc would not be
better. There may be circumstances where it is more convenient and good
enough, making it the right choice.

On 18/01/2024 21:21, bart wrote:

>
> AFAIK, if I wanted to supply a program to any Linux user, I can't just
> supply a binary, since every Linux is a bit different and they run on
> more different kinds of processor.
>

As so often, "AFAIK" for you is not very far.

For almost all Linux users, for almost all their programs, they download
and install binaries - they don't compile from source. Compiling from
source as a common method of distributing programs fell out of fashion
some 20 or 30 years ago.

Of course it is an absolutely essential aspect of free and open source
that the source code is available, and you /can/ compile it yourself.
But for the great majority, they don't do that. Intermediaries -
typically Linux distributions - get the source and compile the binaries,
and users download the binaries.

For developers or companies who don't want to distribute source, or who
want to provide the users the convenience of binaries but it's not
appropriate to include the programs in distros, it is normal to provide
only one or two binaries - an x86-64 binary, and sometimes also an
AArch64 binary if that is a likely target.

It can be more complicated if the software has to integrate tightly with
different aspects of the system, but that's usually not an issue for
most software.

> This is where MS Windows reigned supreme.

You mean it is so much more limited?

On 19/01/2024 10:07, David Brown wrote:
> On 18/01/2024 21:21, bart wrote:
>
>>
>> AFAIK, if I wanted to supply a program to any Linux user, I can't just
>> supply a binary, since every Linux is a bit different and they run on
>> more different kinds of processor.
>>
>
> As so often, "AFAIK" for you is not very far.
>
> For almost all Linux users, for almost all their programs, they download
> and install binaries - they don't compile from source.  Compiling from
> source as a common method of distributing programs fell out of fashion
> some 20 or 30 years ago.

That's good news. So I can build an ELF binary on my WSL today, I can
email it to you and you can run it on the nearest Linux machine?

I assume it will only work if that machine happens to be x64 (as that's
what mine is)?

Or will it not work even then?

What are the rules? Do I have to make a version for every variant of
Linux and make it available in the 'apt-get' repository?

> For developers or companies who don't want to distribute source, or who
> want to provide the users the convenience of binaries but it's not
> appropriate to include the programs in distros, it is normal to provide
> only one or two binaries - an x86-64 binary, and sometimes also an
> AArch64 binary if that is a likely target.
>
> It can be more complicated if the software has to integrate tightly with
> different aspects of the system, but that's usually not an issue for
> most software.
>
>
>> This is where MS Windows reigned supreme.
>
> You mean it is so much more limited?

In being able to run EXEs created by anyone on any machine, and being
able to run them on any Windows computer, even years later.

(I think you can still run 32-bit EXEs compiled in the 1990s today.
16-bit EXEs can still run today on a 32-bit Windows.)

On 19/01/2024 12:17, bart wrote:
> On 19/01/2024 10:07, David Brown wrote:
>> On 18/01/2024 21:21, bart wrote:
>>
>>>
>>> AFAIK, if I wanted to supply a program to any Linux user, I can't
>>> just supply a binary, since every Linux is a bit different and they
>>> run on more different kinds of processor.
>>>
>>
>> As so often, "AFAIK" for you is not very far.
>>
>> For almost all Linux users, for almost all their programs, they
>> download and install binaries - they don't compile from source.
>> Compiling from source as a common method of distributing programs fell
>> out of fashion some 20 or 30 years ago.
>
> That's good news. So I can build an ELF binary on my WSL today, I can
> email it to you and you can run it on the nearest Linux machine?

I know little about WSL - I have never used it, and don't have a current
Windows system. But if it is a Linux virtual system, and your elf file
doesn't rely on uncommon shared libraries and doesn't have low-level
interaction with the system (i.e., you'd call it an "application" rather
than a "system utility"), the probably yes, it would work. Copy it to a
USB stick, boot Linux, and try it yourself.

>
> I assume it will only work if that machine happens to be x64 (as that's
> what mine is)?

Obviously.

>
> Or will it not work even then?
>
> What are the rules? Do I have to make a version for every variant of
> Linux and make it available in the 'apt-get' repository?

If you want rules, find a suitable place to look for them or discuss
them. I have no interest in talking more about this here, and I think
I've already said more than most in this group are willing to do. It
doesn't matter what anyone says, you will always twist things to fit
your preconceived ideas that everything Linux-related is terrible in
every way, and that somehow you think it all proves that your own tools
are brilliant and the rest of the world is wrong.

So try google.

>
>
>> For developers or companies who don't want to distribute source, or
>> who want to provide the users the convenience of binaries but it's not
>> appropriate to include the programs in distros, it is normal to
>> provide only one or two binaries - an x86-64 binary, and sometimes
>> also an AArch64 binary if that is a likely target.
>>
>> It can be more complicated if the software has to integrate tightly
>> with different aspects of the system, but that's usually not an issue
>> for most software.
>>
>>
>>> This is where MS Windows reigned supreme.
>>
>> You mean it is so much more limited?
>
> In being able to run EXEs created by anyone on any machine, and being
> able to run them on any Windows computer, even years later.

I run Linux programs on all sorts of machines without recompiling, years
later. Of course the processor family must be compatible if you don't
want to use emulation.

>
> (I think you can still run 32-bit EXEs compiled in the 1990s today.
> 16-bit EXEs can still run today on a 32-bit Windows.)

You can't get new 32-bit Windows systems now - there is no 32-bit
Windows 11, and manufacturers have not been able to sell new machines
with 32-bit Windows 10 for years. If you have to use 16-bit Windows
programs on a modern computer, you can of course use Wine to run it on
Linux.

On 19/01/2024 11:41, David Brown wrote:
> On 19/01/2024 12:17, bart wrote:

> It
> doesn't matter what anyone says, you will always twist things to fit
> your preconceived ideas that everything Linux-related is terrible in
> every way,

That's funny. I find that Linux people always have terrible things to
say about software development using Windows, usually totally unjustified.

The main reason is that on Linux they are reliant on a huge mountain of
dependencies that don't exist on Windows, even when creating supposedly
cross-platform products.

(That there have been many thousands of programs developed on Windows
without that mountain totally passes them by.)

My issues with it are when *I'm* expected to recreate that same mountain
even when building an application supposedly written in C.

> and that somehow you think it all proves that your own tools
> are brilliant and the rest of the world is wrong.

Um no. It's just that I can do without that mountain. If I can do that
on Windows (remember, Windows doesn't equal Visual Studio; that's just
one over-the-top application), I can do it on Linux. And I have done.

So if I can do it, so can anyone. /That/ is what is superior.

What /I/ do is to remove complexity and simplify. What everyone else
does is to add complexity, extra dependencies and extra layers of
software. Apparently it doesn't matter how big that mountain gets.

On 19/01/2024 14:18, bart wrote:
> On 19/01/2024 11:41, David Brown wrote:
>> On 19/01/2024 12:17, bart wrote:
>
>> It doesn't matter what anyone says, you will always twist things to
>> fit your preconceived ideas that everything Linux-related is terrible
>> in every way,
>
> That's funny. I find that Linux people always have terrible things to
> say about software development using Windows, usually totally unjustified.

And feel free to ignore these if you have good reason to believe they
are not fact based. Don't feel free to exaggerate what people say (I
say Linux is better for most development and programming work, other
than when targeting Windows itself - but you /can/ use Windows for many
tasks, and I do use Windows as well as Linux). And don't imagine that
just because you feel someone has said something unjustifiably bad about
X, it means it is appropriate to say something similarly unjustifiably
bad about Y. That's just petty.

>
> The main reason is that on Linux they are reliant on a huge mountain of
> dependencies that don't exist on Windows, even when creating supposedly
> cross-platform products.

You are making stuff up.

People do cross-platform (and I assume by this you just mean "for x86-64
Linux and x86-64 Windows") all the time. /You/ have difficulty with
this kind of thing, but many other developer groups manage. (I'm sure
there are others who have problems too.)

There are no mountains.

What there is, that seems to be a stumbling block for you, is a set of
common utility programs that has been standardised and used on most
serious OS's for decades (since most serious OS's, except for Windows,
aim for POSIX compatibility). These are easily available on Windows
too, and once you install them, they are there and usable. I've had
them on every Windows PC I have used since I had internet access.

I can fully understand how someone who is only familiar with Windows
(and DOS before it) doesn't know about these utilities or where to get
them, and finds them strange at first. It is incomprehensible, however,
to be having the same questions, difficulties and complaints after a
decade or so.

It is also incomprehensible how someone can rant endlessly about
"simplification" and "easy of use" when their claimed solution is to
make non-standard limited duplications of the functionality already
found on other machines.

On 19/01/2024 14:42, David Brown wrote:
> On 19/01/2024 14:18, bart wrote:

> It is also incomprehensible how someone can rant endlessly about
> "simplification" and "easy of use" when their claimed solution is to
> make non-standard limited duplications of the functionality already
> found on other machines.

The programs I write ARE easy to build, using ONLY a compiler.

You don't want to accept that, you'd rather it involved those mountains
of stuff.

Maybe you don't like it because you're rather just type 'make', no
matter much pointless garbage is invoked. Fine, a makefile for most of
my projects would be two lines long.

Happy?

bart <bc@freeuk.com> writes:
>On 19/01/2024 10:07, David Brown wrote:
>> On 18/01/2024 21:21, bart wrote:
>>
>>>
>>> AFAIK, if I wanted to supply a program to any Linux user, I can't just
>>> supply a binary, since every Linux is a bit different and they run on
>>> more different kinds of processor.
>>>
>>
>> As so often, "AFAIK" for you is not very far.
>>
>> For almost all Linux users, for almost all their programs, they download
>> and install binaries - they don't compile from source.  Compiling from
>> source as a common method of distributing programs fell out of fashion
>> some 20 or 30 years ago.
>
>That's good news. So I can build an ELF binary on my WSL today, I can
>email it to you and you can run it on the nearest Linux machine?

That's not what David said. The major distributions offer
repositories containing all supported packages (far more than will
be installed by default), built for that specific distribution.

On 19.01.2024 15:42, David Brown wrote:
> On 19/01/2024 14:18, bart wrote:
>> On 19/01/2024 11:41, David Brown wrote:
>>> On 19/01/2024 12:17, bart wrote:
>>
>>> It doesn't matter what anyone says, you will always twist things to
>>> fit your preconceived ideas that everything Linux-related is terrible
>>> in every way,
>>
>> That's funny. I find that Linux people always have terrible things to
>> say about software development using Windows, usually totally
>> unjustified.
>
> And feel free to ignore these if you have good reason to believe they
> are not fact based. Don't feel free to exaggerate what people say (I
> say Linux is better for most development and programming work, other
> than when targeting Windows itself - but you /can/ use Windows for many
> tasks, and I do use Windows as well as Linux). [...]

There was a time when I dual booted (pre-installed) WinDOS and
Linux. At some point I got aware that it makes no sense, Windows
was - besides its inherent issues - also completely unnecessary
(as could be seen soon); further installs were Linux-only.

It's a phenomenon that the marketing division of MS did so great
a job to mentally bind such a huge community. (There were other
reasons as well (driver support of companies, pre-installed OS
on hardware, gaming focus, or self-enforcing dissemination
feedback processes), but discussion would lead too far here.)

I've often observed uninformed WinDozers just spread uninformed
nonsense. But never in such extreme stubbornness as in this thread.

> [...]
>> [...]

> I can fully understand how someone who is only familiar with Windows
> (and DOS before it) doesn't know about these utilities or where to get
> them, and finds them strange at first. [...]

This is part of the phenomenon.

And as we see nothing helps if folks grew up and didn't leave
that bubble, didn't even dare to have a look outside and try
to grasp what's going on. Yet continuing uninformed rants about
something they never experienced nor understood to a minimum
extent.

We have to accept though that the condition where someone is
making specialized niche-software for a specific platform is
also not fostering susceptive open-mindedness when confronted
with the huge professional IT world.

But I have hope; after issues with Windows I installed Linux
even for my (very old) father, and he has no problems with it
(using browser, email, and a text processor). And my children
installed Linux by themselves, anyway, and they're programming
their academic research tasks on that platform. - No lengthy
stupid discussions as in this thread.

Janis

On 19/01/2024 16:32, Janis Papanagnou wrote:
> On 19.01.2024 15:42, David Brown wrote:
>> On 19/01/2024 14:18, bart wrote:
>>> On 19/01/2024 11:41, David Brown wrote:
>>>> On 19/01/2024 12:17, bart wrote:
>>>
>>>> It doesn't matter what anyone says, you will always twist things to
>>>> fit your preconceived ideas that everything Linux-related is terrible
>>>> in every way,
>>>
>>> That's funny. I find that Linux people always have terrible things to
>>> say about software development using Windows, usually totally
>>> unjustified.
>>
>> And feel free to ignore these if you have good reason to believe they
>> are not fact based. Don't feel free to exaggerate what people say (I
>> say Linux is better for most development and programming work, other
>> than when targeting Windows itself - but you /can/ use Windows for many
>> tasks, and I do use Windows as well as Linux). [...]
>
> There was a time when I dual booted (pre-installed) WinDOS and
> Linux. At some point I got aware that it makes no sense, Windows
> was - besides its inherent issues - also completely unnecessary
> (as could be seen soon); further installs were Linux-only.
>
> It's a phenomenon that the marketing division of MS did so great
> a job to mentally bind such a huge community. (There were other
> reasons as well (driver support of companies, pre-installed OS
> on hardware, gaming focus, or self-enforcing dissemination
> feedback processes), but discussion would lead too far here.)
>
> I've often observed uninformed WinDozers just spread uninformed
> nonsense. But never in such extreme stubbornness as in this thread.
>
>> [...]
>>> [...]
>
>> I can fully understand how someone who is only familiar with Windows
>> (and DOS before it) doesn't know about these utilities or where to get
>> them, and finds them strange at first. [...]
>
> This is part of the phenomenon.
>
> And as we see nothing helps if folks grew up and didn't leave
> that bubble, didn't even dare to have a look outside and try
> to grasp what's going on. Yet continuing uninformed rants about
> something they never experienced nor understood to a minimum
> extent.

It's not me who's in the bubble. How about that giant bubble called 'Linux'?

People who complain about Windows will moan about something that is
missing because Linux has it and Windows doesn't.

My complaints about Linux are not about something missing from Linux
that is in Windows. See the difference?

> We have to accept though that the condition where someone is
> making specialized niche-software for a specific platform is
> also not fostering susceptive open-mindedness when confronted
> with the huge professional IT world.
>
> But I have hope; after issues with Windows

What kinds of issues? Many millions of ordinary people have used
Windows. Not many ordinary people use raw Linux.

> I installed Linux
> even for my (very old) father, and he has no problems with it
> (using browser, email, and a text processor). And my children
> installed Linux by themselves, anyway, and they're programming
> their academic research tasks on that platform. - No lengthy
> stupid discussions as in this thread.

Well, be oblivious to all the issues then. Clearly that giant mountain
of stuff works for you and it works for your kids.

I however can see when someone is using a sledgehammer to crack a nut.

On 19/01/2024 16:03, bart wrote:
> On 19/01/2024 14:42, David Brown wrote:
>> On 19/01/2024 14:18, bart wrote:
>
>> It is also incomprehensible how someone can rant endlessly about
>> "simplification" and "easy of use" when their claimed solution is to
>> make non-standard limited duplications of the functionality already
>> found on other machines.
>
> The programs I write ARE easy to build, using ONLY a compiler.
>
> You don't want to accept that, you'd rather it involved those mountains
> of stuff.

/Please/ stop making stupid, exaggerated and incorrect claims about what
other people want or think.

I don't give a *beep* how easy or hard your programs are to compile -
they are utterly irrelevant to me. I don't have reason to believe they
are very relevant to anyone else either. But even if they were useful
to me, or at least of interest to me, it does not matter to me if they
need a whole range of standard utilities to build - because every system
I have, or ever have had, has the standard utilities.

Why is it so difficult for you to understand the concept of not caring?
It is absurd to suggest I /want/ your programs to need "make" or other
utilities to compile - I *do* *not* *care* if it needs them or not.
There is no advantage or disadvantage to me if it uses make, sed, awk,
bash, date. There is no advantage or disadvantage to me if it does not
need them either. It is irrelevant.

It /would/ be an inconvenience to me if it required some obscure and
rarely used compiler like your own tools. TCC is also pretty obscure,
but Debian has it in it's repositories. Needing an invasive tool that
screws up your system, like MSVC, would also be a pain, as would
anything that required very specific versions of tools. But that would
only matter if your programs were of interest.

And of course I accept that /you/ think it is important that you don't
use tools that everyone else finds convenient and useful. I don't
understand your reasons for that - it seems to be based on a determined
battle to ensure that you fail to get anything you deem to be "Linux
related" to work, combined with a fanaticism about "simple" that
completely misses the point. But I don't think anyone here doubts that
/you/ think this is all desperately important, even though pretty much
no one else cares.

And /please/ stop making an arse of yourself here by calling a dozen
standard utilities "mountains of stuff".

On 19/01/2024 17:12, David Brown wrote:
> On 19/01/2024 16:03, bart wrote:
>> On 19/01/2024 14:42, David Brown wrote:
>>> On 19/01/2024 14:18, bart wrote:
>>
>>> It is also incomprehensible how someone can rant endlessly about
>>> "simplification" and "easy of use" when their claimed solution is to
>>> make non-standard limited duplications of the functionality already
>>> found on other machines.
>>
>> The programs I write ARE easy to build, using ONLY a compiler.
>>
>> You don't want to accept that, you'd rather it involved those
>> mountains of stuff.
>
> /Please/ stop making stupid, exaggerated and incorrect claims about what
> other people want or think.
>
> I don't give a *beep* how easy or hard your programs are to compile -
> they are utterly irrelevant to me.  I don't have reason to believe they
> are very relevant to anyone else either.  But even if they were useful
> to me, or at least of interest to me, it does not matter to me if they
> need a whole range of standard utilities to build - because every system
> I have, or ever have had, has the standard utilities.
>
> Why is it so difficult for you to understand the concept of not caring?
> It is absurd to suggest I /want/ your programs to need "make" or other
> utilities to compile - I *do* *not* *care* if it needs them or not.
> There is no advantage or disadvantage to me if it uses make, sed, awk,
> bash, date.  There is no advantage or disadvantage to me if it does not
> need them either.  It is irrelevant.
>
> It /would/ be an inconvenience to me if it required some obscure and
> rarely used compiler like your own tools.  TCC is also pretty obscure,
> but Debian has it in it's repositories.  Needing an invasive tool that
> screws up your system, like MSVC, would also be a pain, as would
> anything that required very specific versions of tools.  But that would
> only matter if your programs were of interest.
>
> And of course I accept that /you/ think it is important that you don't
> use tools that everyone else finds convenient and useful.  I don't
> understand your reasons for that

Because they don't work. Things like makefiles, even designed to work on
Windows, had a 50% failure rate.

Higher if they originated on Linux.

100% if they originated on Linux and expected to run in that
environment. Your solution here is to replicated that environment even
on Windows.

Then the failure rate is much lower, if I use WSL (but it can still
fail). However that doesn't produce the native binaries I need.

You will say use MSYS2, and here I need to put my foot down - how many
rabbit holes do I have to go down to just to build a C program?

You obviously have a high tolerance of such rabbit holes.

Apparently it is inconceivable to you to have an application written in
C say, that can be compiled either on Linux or Windows using only a C
compiler.

> - it seems to be based on a determined
> battle to ensure that you fail to get anything you deem to be "Linux
> related" to work, combined with a fanaticism about "simple" that
> completely misses the point.  But I don't think anyone here doubts that
> /you/ think this is all desperately important, even though pretty much
> no one else cares.
>
>
> And /please/ stop making an arse of yourself here by calling a dozen
> standard utilities "mountains of stuff".

Half of a Linux system, many thousands of lines of scripting code and
makefiles, to build a project of a few dozen source files, is not a
mountain?

I've been looking at someone's C++ project which is a compiler for what
they call a 'toy' language. There are 33 .cpp files.

One of the dependencies however is something called LLVM. I've
downloaded what appears to be the bundle needed to build this project.

It is 140,000 files. Just unzipping it took 15 minutes.

You guys just don't get it. What /I/ do is the exact opposite of this.

You think it doesn't matter? A number of major language implementations
that are currently using an LLVM backend are thinking of moving away
from LLVM, or offering an alternative, BECAUSE it is so slow and cumbersome.

But I will leave this alone now.

bart <bc@freeuk.com> writes:
>On 19/01/2024 17:12, David Brown wrote:
>> On 19/01/2024 16:03, bart wrote:
>>> On 19/01/2024 14:42, David Brown wrote:
>>>> On 19/01/2024 14:18, bart wrote:
>>>
>>>> It is also incomprehensible how someone can rant endlessly about
>>>> "simplification" and "easy of use" when their claimed solution is to
>>>> make non-standard limited duplications of the functionality already
>>>> found on other machines.
>>>
>>> The programs I write ARE easy to build, using ONLY a compiler.
>>>
>>> You don't want to accept that, you'd rather it involved those
>>> mountains of stuff.
>>
>> /Please/ stop making stupid, exaggerated and incorrect claims about what
>> other people want or think.
>>
>> I don't give a *beep* how easy or hard your programs are to compile -
>> they are utterly irrelevant to me.  I don't have reason to believe they
>> are very relevant to anyone else either.  But even if they were useful
>> to me, or at least of interest to me, it does not matter to me if they
>> need a whole range of standard utilities to build - because every system
>> I have, or ever have had, has the standard utilities.
>>
>> Why is it so difficult for you to understand the concept of not caring?
>> It is absurd to suggest I /want/ your programs to need "make" or other
>> utilities to compile - I *do* *not* *care* if it needs them or not.
>> There is no advantage or disadvantage to me if it uses make, sed, awk,
>> bash, date.  There is no advantage or disadvantage to me if it does not
>> need them either.  It is irrelevant.
>>
>> It /would/ be an inconvenience to me if it required some obscure and
>> rarely used compiler like your own tools.  TCC is also pretty obscure,
>> but Debian has it in it's repositories.  Needing an invasive tool that
>> screws up your system, like MSVC, would also be a pain, as would
>> anything that required very specific versions of tools.  But that would
>> only matter if your programs were of interest.
>>
>> And of course I accept that /you/ think it is important that you don't
>> use tools that everyone else finds convenient and useful.  I don't
>> understand your reasons for that
>
>Because they don't work. Things like makefiles, even designed to work on
>Windows, had a 50% failure rate.

Another number pulled out from your backside.

But then you're just trolling.

On 19/01/2024 19:28, bart wrote:
> On 19/01/2024 17:12, David Brown wrote:

>> And of course I accept that /you/ think it is important that you don't
>> use tools that everyone else finds convenient and useful.  I don't
>> understand your reasons for that
>
> Because they don't work. Things like makefiles, even designed to work on
> Windows, had a 50% failure rate.

And you have statistics to back that up? Other than personal anecdotes,
of course. (And before you get carried away, stack overflow questions
might show a non-zero failure rate, but not a 50% rate.)

Claims made without evidence or reason can be dismissed without evidence
or reason. /You/ have trouble building software - we know that, and no
one's arguing against that.

>
> Apparently it is inconceivable to you to have an application written in
> C say, that can be compiled either on Linux or Windows using only a C
> compiler.

I'll give you /one/ last chance to stop imaging what you think I am
saying and fighting against your ridiculous straw-man arguments.
Whenever you find yourself writing "You seem to think...", "You
want...", "You prefer...", stop and delete the paragraph. You are wrong
every single time.

>
> But I will leave this alone now.
>

OK.

On 19/01/2024 18:05, bart wrote:
> On 19/01/2024 16:32, Janis Papanagnou wrote:

>>
>> And as we see nothing helps if folks grew up and didn't leave
>> that bubble, didn't even dare to have a look outside and try
>> to grasp what's going on. Yet continuing uninformed rants about
>> something they never experienced nor understood to a minimum
>> extent.
>
> It's not me who's in the bubble. How about that giant bubble called
> 'Linux'?

I suppose from inside your bubble, it looks like you are the only
sensible person and everyone else is in the bubble. Everyone is
marching out of step, except you.