David Brown <david.brown@hesbynett.no> writes:
>On 17/01/2024 07:11, Janis Papanagnou wrote:
>> On 16.01.2024 19:03, David Brown wrote:
>>>
>>> [...], because they know that Norwegians are superior to Swedes in every way...
>>
>> I just wanted to reply on that but then I saw your email address... :-)
>>
>
>I'm Scottish by origin, but have lived in Norway for about 30 years. So
>I am a Norwegian by practice (and citizenship) rather than birth.
>
>(Norway and Sweden view each other as "brother" countries, with very
>close ties and cooperation, but also good-natured rivalry and occasional
>teasing.)

And at various times in the past they've been one country (c.f. United Kingdoms).

On 17/01/2024 17:33, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 17/01/2024 07:11, Janis Papanagnou wrote:
>>> On 16.01.2024 19:03, David Brown wrote:
>>>>
>>>> [...], because they know that Norwegians are superior to Swedes in every way...
>>>
>>> I just wanted to reply on that but then I saw your email address... :-)
>>>
>>
>> I'm Scottish by origin, but have lived in Norway for about 30 years. So
>> I am a Norwegian by practice (and citizenship) rather than birth.
>>
>> (Norway and Sweden view each other as "brother" countries, with very
>> close ties and cooperation, but also good-natured rivalry and occasional
>> teasing.)
>
> And at various times in the past they've been one country (c.f. United Kingdoms).
>

Norway and Sweden have always been separate countries (since they became
countries). They were in a union, with Norway dominated and ruled by
Sweden, but they were still different countries.

The Ununited Kingdom, on the other hand, is in some aspects one country,
in other aspects four different countries (with a whole bunch of
complicated bits), and in many aspects a complete mess.

(I should stop there - this is no place to risk getting into politics.)

David Brown <david.brown@hesbynett.no> writes:
>On 17/01/2024 17:33, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 17/01/2024 07:11, Janis Papanagnou wrote:
>>>> On 16.01.2024 19:03, David Brown wrote:
>>>>>
>>>>> [...], because they know that Norwegians are superior to Swedes in every way...
>>>>
>>>> I just wanted to reply on that but then I saw your email address... :-)
>>>>
>>>
>>> I'm Scottish by origin, but have lived in Norway for about 30 years. So
>>> I am a Norwegian by practice (and citizenship) rather than birth.
>>>
>>> (Norway and Sweden view each other as "brother" countries, with very
>>> close ties and cooperation, but also good-natured rivalry and occasional
>>> teasing.)
>>
>> And at various times in the past they've been one country (c.f. United Kingdoms).
>>
>
>Norway and Sweden have always been separate countries (since they became
>countries). They were in a union, with Norway dominated and ruled by
>Sweden, but they were still different countries.

Note the plural kingdoms above.

"United Kingdoms of Sweden and Norway, and known as the United Kingdoms"

On 17/01/2024 15:51, bart wrote:
> On 17/01/2024 13:25, David Brown wrote:
>> On 16/01/2024 23:42, bart wrote:
>>> On 16/01/2024 17:46, David Brown wrote:
>>>> On 16/01/2024 16:15, bart wrote:
>>>
>>>> void swap_lots(const uint32_t * restrict in, uint32_t * restrict
>>>> out, uint32_t n) {
>>>>      while (n--) {
>>>>          *out++ = swapEndian32(*in++);
>>>>          *out++ = swapEndian32(*in++);
>>>>          *out++ = swapEndian32(*in++);
>>>>          *out++ = swapEndian32(*in++);
>>>>      }
>>>> }
>>>
>>> What's 'n' here? Are 4n bytes being transformed, or 16n?
>>
>> In this case, 4n 32-bit words.  It's just example code to demonstrate
>> a point, not to be a particularly useful function in reality.
>>
>>>
>>>>> My function would be this on x64 (although I don't support bswap):
>>>>>
>>>>>     fun swapends64(u64 x)u64 = assem mov rax, [x]; bswap rax; end
>>>>>
>>>>
>>>> And how efficient would your "swap_lots" function be?
>>>
>>> How do you measure efficiency? This task seems memory-bound anyway.
>>>
>>
>> That will depend on the sizes, cache, etc., as well as the target.
>> The target I was using here is a Cortex M7 - with data in
>> tightly-coupled memory that runs at core speed, it would not be memory
>> bound.
>>
>> Efficiency is measured in clock cycles.  (It can also be measured in
>> code size, but that's usually not as important.  If it were, we would
>> not be doing manual loop unrolling here.)
>>
>>> Using exactly that function (I now support 'bswap'), I can process a
>>> 100M-element u64 array (0.8GB) in .35 seconds, or 2.3GB/second.
>>>
>>
>> On what target?  Do you have an ARM Cortex-M microcontroller for
>> testing this?
>
> I have an RPi4 somewhere; I only know it has a 64-bit ARM chip. ARM
> processor and architecture models are mystery to me. My tests were done
> on some AMD Ryzen device, probably bottom of the range.

The ARM processors on a Pi are much more like a PC processor than an ARM
microcontroller (even though the M7 I use mostly is 600 MHz).

>
> (x64 processors are a bit of a mystery too! I just have little interest
> beyond whether it's x64 or ARM64; I don't come across anything else.)
>
>> Using a built-in bswap function kind of defeats the point of using
>> inline assembly.
>
> I didn't support 'bswap' at all. I first has to add it to my assembler,
> then roll that out to the backend of my compiler.
>
> This was necessary both to be able to use it in inline assembler, and
> for the compiler backend to be able to deal with that instruction,
> whatever had generated it.
>
> So I wanted to know whether building it to the language in would be
> worth doing, performance-wise (probably not). Although there are other
> advantages of having it as an operator, since it could be used in-place
> as 'bswap:=A[i]', and here it would be able to choose 32- and 64-bit
> variations.
>
> But it also highlighted issues with my inline assembler within macros
> used to emulate inline functions, such as this:
>
>     macro byteswap(x) = assem mov rax, [x] ...
>
> 'x' can only be a simple variable at the invocation, not an arbitrary
> expression like 'A[i]'. This suggested an enhancement:
>
>    assem (expr) ...
>
> which first evaluates the expression to a known register.

This sounds like you are taking inspiration from the discussion and
making your language support more of gcc's inline assembly features!

> (I could just
> do 'expr; assem ...' which /probably/ does the same, but it's risky.)
>
> So doing the exercise helped in determining what might be a suitable
> compromise. Although it would need explicit forms for 32- vs 64-bit
> operations.
>
> ('assem(expr) ...' is also partway to doing what gcc asm{} does in
> creating an interface, but retaining the same syntax.)
>
>>   gcc has __builtin_bswap32 too, or it can be written manually in C
>> and optimised by the compiler to "rev" instructions.  The point is a
>> demonstration of how gcc's inline assembly can work with the optimiser
>> for surrounding code, not how fast your PC can swap endianness!
>
> It showed that using an actual function call, and not unrolling loops,
> wasn't that slow, not on my PC.
>

It showed that - unsurprisingly - running this on a huge block of data
is determined by cache and memory speed. It probably doesn't make much
difference to your timings if "bswap" returned its argument untouched.

Thus you missed the point about optimising code. (You did, however,
show that optimising code is not always important - if the code itself
is not the bottleneck, optimising it won't help.)

On 17.01.2024 14:17, David Brown wrote:
> On 17/01/2024 07:11, Janis Papanagnou wrote:
>> On 16.01.2024 19:03, David Brown wrote:
>>>
>>> [...], because they know that Norwegians are superior to Swedes in
>>> every way...
>>
>> I just wanted to reply on that but then I saw your email address... :-)
>
> I'm Scottish by origin, but have lived in Norway for about 30 years. So
> I am a Norwegian by practice (and citizenship) rather than birth.

By birth, or whatever; I think we are what we feel to be. :-)

>
> (Norway and Sweden view each other as "brother" countries, with very
> close ties and cooperation,

Yes, that's also how these countries are seen from other places.
I've been a couple times in SE, and once in NO; I like these
countries.

Also with respect to computer languages; I was amazed by Simula,
originating from the NCC in Oslo/NO, and I had a compiler that
had been developed in Lund/SE, where I could even talk to one
of the developers in the 1980's.)

> but also good-natured rivalry and occasional teasing.)

Within DE there's rivalry even between Bavaria and Prussia. ;-)
(Not seriously but mainly also only some teasing. Historically,
though, it had been a much more serious conflict.)

Janis

On 17.01.2024 14:10, David Brown wrote:
>
> Of course different people have different styles and needs. For my own
> use, I vastly prefer to write the code as cleanly as possible and let
> the optimiser generate code roughly like Duff's Device if that's the
> most efficient. [...]

Of course. And I agree. My comment might have sounded more positive
than these tricks deserve. I just wanted to emphasize that by using
code patterns we can often circumvent language deficiencies. And
that C can anyway hardly be considered a cleanly designed language.
(*duck* :-)

>
>> (But we're here in a C newsgroup and complaints make no sense.)
>
> Hey - without complaints, this newsgroup would be almost empty :-)

Well, here our expectations (maybe) differ. ;-)

Frankly, this thread is pathological! (I've never seen such before.)

I feel really bad about opening that subject (which had already been
answered after a dozen replies!) - and then it became off-topic, and
gigantic, with what, 350 posts?, and a lot of them like tapeworms,
and all the repetitions, and whatnot.

But I'm new in this NG, so I'll better silence for now...

Janis

On 2024-01-17, bart <bc@freeuk.com> wrote:
> On 12/01/2024 16:50, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 12/01/2024 13:40, David Brown wrote:
>>>> On 12/01/2024 00:20, bart wrote:
>>>
>>> But with 'as', it just sits there. I wonder what it's waiting for; for
>>> me to type in ASM code live from the terminal?
>>
>> It does that so you can pipe the assembler source code in to the
>> assembler.
>>
>> $ cat file.s | as
>>
>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>>
>> or, if you want, you can type in the assembler source directly.
>>
>> Or you can save it in a file and supply the file argument to the command.
>>
>> None of which your stuff supports, which makes it useless to me.
>
> I had a spare 15 minutes so I got my scripting language to do this:
>
> csource:=(
> "#include <stdio.h>",
> "int main(void) {",
> " puts(""Fahrenheit 451"");",
> "}")
>
> csource -> mcc -> aa -> run
>
> 'mcc' turns a source string (or a list of strings as here) into a string
> containing assembly code.
>
> 'aa' turns an assembly string into a string containing binary PE data.
>
> 'run' runs that PE data. Output is:
>
> Fahrenheit 451
>
> Those 3 functions are 40-50 lines. Here's another invocation:

Scott's script is just that one line; just the external commands are
called. It doesn't require function wrappers around external commands.

We have a ton of useful scripting languages; yet the shell is not
going away for process control tasks.

The only reason to use the shell for larger coding tasks that go
beyonod process control is that is that it's the only language you can
rely on being installed.

A good many scripting languages require a shell in order to build,
such as for runing a ./configure script.

Those projects aren't doing that in order to amuse the user with
irony; boostrapping always proceeds from what we have available, to what
we would like to ultimately use.

--
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 17/01/2024 18:47, Kaz Kylheku wrote:
> On 2024-01-17, bart <bc@freeuk.com> wrote:

>> csource -> mcc -> aa -> run
>>
>> 'mcc' turns a source string (or a list of strings as here) into a string
>> containing assembly code.
>>
>> 'aa' turns an assembly string into a string containing binary PE data.
>>
>> 'run' runs that PE data. Output is:
>>
>> Fahrenheit 451
>>
>> Those 3 functions are 40-50 lines. Here's another invocation:
>
> Scott's script is just that one line; just the external commands are
> called.

So was my invocation. Scott's example didn't provide source code, it
comes from a file, as did my second example.

> It doesn't require function wrappers around external commands.
>
> We have a ton of useful scripting languages; yet the shell is not
> going away for process control tasks.
>
> The only reason to use the shell for larger coding tasks that go
> beyonod process control is that is that it's the only language you can
> rely on being installed.

One big problem is that it tends to be OS-specific so is not
cross-platform. So you can't run .BAT files on Linux, and you can't run
.. files (that is, Linux shell scripts) on Windows. (File extensions
would be mighty useful here!)

Real scripting languages can work across OSes and also come with their
own libraries. Linux shell seems to require most of Linux to function.

> A good many scripting languages require a shell in order to build,
> such as for runing a ./configure script.

Funnily enough, mine don't.

My scripting language builds with this one command on Windows (and
without invoking dozens of other processes; just itself):

mm qq

When I was testing it on Linux, I could build it on Linux from original
sources using:

./mu qq

(This used a C intermediate file and needed a C installation. 'mu' is a
binary that could itself be built with a command like: cc mu.c ...)

I'm not suggesting mine is used, just saying it is possible to have a
cross-platform language on a small scale and that can be built using a
minimal tool-set.

Certainly one that is sufficient for the minor scripting tasks we're
taking about.

(As for Bash, is it a language running in a permanent REPL loop, or is
it more of an application?)

On 1/17/2024 4:28 AM, David Brown wrote:
> On 17/01/2024 02:08, Chris M. Thomasson 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
>>
>
> Looking at the start of that thread:
>
> int trylock()
> {
>     int res;
>     res = pthread_mutex_trylock(&mutex);
>     if (res == 0)
>         ++acquires_count;
>     return res;
> }
>
> It is perfectly reasonable for a pre-C11 C compiler to change that to:
>
> int trylock()
> {
>     int res;
>     res = pthread_mutex_trylock(&mutex);
>     int x = acquires_count;
>     if (res == 0)
>         ++x;
>     acquires_count = x;
>     return res;
> }
>
> That's the way C was defined, prior to C11 support for multithreading
> environments.  The compiler could assume that it alone had full control
> over all data, unless it was defined as volatile.  So to make this code
> "correct" (according to the user's hopes) in pre-C11, "acquires_count"
> must be volatile.
>
> C11 disabled such optimisations, because they could introduce data races
> that did not exist before.  But C11 was not around at that time.  So
> having this optimisation was not a gcc bug - unless POSIX precluded such
> optimisations and gcc was used in a POSIX-compatibility mode.  (I don't
> know the details of POSIX requirements.)

Iirc, I think that GCC was being used for POSIX where _POSIX_VERSION /
_POSIX2_C_VERSION was defined. The main point is that made it unusable
wrt pthread_mutex_trylock(). -pthread

This is one of the reasons why I was implementing my sync code in
externally assembled files, at the time.

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?

>
> How often do you use headers from the standard library, or third party
> libraries, or other code?  All the time, I'd assume.  How often do you
> read through these headers?  Very rarely.  How often do you edit them?
> Never.
>
> You do not need to read code of any kind, in order to use it.
>
> Some kinds of code can be considered advanced, or ugly, or hard to
> comprehend.  inline assembly often falls into that category, as do
> complicated macros, and some of the more cryptic corners of C++.  That
> code should be written by someone who knows what they are doing, tested
> well, the interface described, and then the code is hidden away.  Most
> other people using the code never see it, and might not understand it
> even if they did.
>
>
> It is entirely reasonable to structure your headers like this:
>
>     // Return x + (y * z)
>     static inline int madd(int x, int y, int z);
>
>     ...
>
>     // Implementation details
>     static inline int madd(int x, int y, int z) {
>         asm (...
>
>
>
>

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).

Your scripting language isn't available on any of them.

>(As for Bash, is it a language running in a permanent REPL loop, or is
>it more of an application?)

It's an executable, just like everything else on unix/linux.

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.

> Your scripting language isn't available on any of them.
>
>> (As for Bash, is it a language running in a permanent REPL loop, or is
>> it more of an application?)
>
> It's an executable, just like everything else on unix/linux.

So, it's code, just like on every computer.

That's useful to know, thanks.

bart <bc@freeuk.com> writes:
> On 17/01/2024 22:18, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
[...]
>>> (As for Bash, is it a language running in a permanent REPL loop, or is
>>> it more of an application?)
>> It's an executable, just like everything else on unix/linux.
>
> So, it's code, just like on every computer.
>
> That's useful to know, thanks.

bash.exe (or just "bash" on non-Windows systems), cmd.exe, and
powershell.exe are all similar applications. They implement different
languages.

All are optimized for interactive use, reading and executing one-line
commands typed on a keyboard into a (probably virtual) text terminal.
All are also interpreters for scripting/programming languages, and can
be used to execute a script stored in a file. bash is an enhanced
shell based on earlier Unix shells.

bash happens to be implemented in C. I don't know how cmd.exe and
PowerShell are implemented.

--
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 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. Macs support then
natively.

The availability of the shell language is better than any other;
the places where it doesn't run out of the box are not many.

Also, no operating system that is still in wide use has a better
command language.

We could imagine, say, writing the build scripting of a project in the
batch file language of CMD.EXE, and making that work on all the
platforms: Mac, GNU Linuxes, Solaris, OpenBSD, Android/Termux what
have you.

For all the inconvenience of having to install that interpreter first,
we would then have to contend with a comically poor quality language.
It's worse than some CS freshman's semester project.

Shell has multiple implementations. At one point I tested the ./configure
script of my TXR project with Bash, Zsh, Dash, Ash, public domain Ksh,
as well as some POSIX shells of some proprietary Unixes like Solaris's
POSIX shell.

Though the shell language is quirky, it is well specified and understood
to the point that fairly complex code can be written that works across
multiple implementations.

As far as Windows goes, nobody actually builds my program for Windows
other than me. I provide a GUI installer. That's what you do for
Windows. How your stuff builds on Windows is almost immaterial.

The only people building your FOSS stuff from code are (1) maintainers
of FOSS distros, who always use environments with shells and make, etc;
and (2) a few enthusiast users who build for themselves, also in such
environments. Anyone who has something to do on Windows gets your
installer.

--
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 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.

> Macs support then
> natively.
>
> The availability of the shell language is better than any other;
> the places where it doesn't run out of the box are not many.
>
> Also, no operating system that is still in wide use has a better
> command language.

Yes, I have an idea what you mean by better. Something that gives low
priority to user-friendliness and that is bristling with advanced
features that mean loads of gotchas.

I'm not sure what happened on my journey with computers that I'm totally
oblivious to shells, other than they provide the most basic commands to
manipulate files and launch programs.

> We could imagine, say, writing the build scripting of a project in the
> batch file language of CMD.EXE, and making that work on all the
> platforms: Mac, GNU Linuxes, Solaris, OpenBSD, Android/Termux what
> have you.
>
> For all the inconvenience of having to install that interpreter first,
> we would then have to contend with a comically poor quality language.
> It's worse than some CS freshman's semester project.

What language do you have in mind? (Bear in mind that this is exactly
what I've long thought about C.)

>
> Shell has multiple implementations. At one point I tested the ./configure
> script of my TXR project with Bash, Zsh, Dash, Ash, public domain Ksh,
> as well as some POSIX shells of some proprietary Unixes like Solaris's
> POSIX shell.

I wonder why any other scripting languages exist? Why does TXR? What's
missing from Bash (and why are there so many variations)?

I can tell you that mine came into being as an add-on scripting language
for my applications. I think it was about 15 years before it became an
independent language.

> Though the shell language is quirky, it is well specified and understood
> to the point that fairly complex code can be written that works across
> multiple implementations.
>
> As far as Windows goes, nobody actually builds my program for Windows
> other than me. I provide a GUI installer. That's what you do for
> Windows.

How do you get past AV software?

> How your stuff builds on Windows is almost immaterial.
>
> The only people building your FOSS stuff from code are (1) maintainers
> of FOSS distros, who always use environments with shells and make, etc;
> and (2) a few enthusiast users who build for themselves, also in such
> environments. Anyone who has something to do on Windows gets your
> installer.

On 2024-01-18, bart <bc@freeuk.com> 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.

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.

That something itself doesn't require that shell environment in its
own installation.

>> Macs support then
>> natively.
>>
>> The availability of the shell language is better than any other;
>> the places where it doesn't run out of the box are not many.
>>
>> Also, no operating system that is still in wide use has a better
>> command language.
>
> Yes, I have an idea what you mean by better. Something that gives low
> priority to user-friendliness and that is bristling with advanced
> features that mean loads of gotchas.

In fact, a lot of the gotchas are gratuitous with respect to the
features. But there is a way to do things correctly if you understand
how command lines are expanded.

I can write a piece of shell code where I know what it's going to do
just about anywhere. It's harder than it needs to be, or at least
sometimes, and you have to know more than you should. The code isn't
something to be crazy about.

But I feel that with things like the Microsoft .BAT language, for
instance, you cannot hit the same quality target, no matter how much you
know.

Microsoft's PowerShell language is a lot better (if I believe what
others say). It's not widely installed though. You'd be better off
relying on Python from that perspective.

>> We could imagine, say, writing the build scripting of a project in the
>> batch file language of CMD.EXE, and making that work on all the
>> platforms: Mac, GNU Linuxes, Solaris, OpenBSD, Android/Termux what
>> have you.
>>
>> For all the inconvenience of having to install that interpreter first,
>> we would then have to contend with a comically poor quality language.
>> It's worse than some CS freshman's semester project.
>
> What language do you have in mind? (Bear in mind that this is exactly
> what I've long thought about C.)

That batch file one in the previous paragraph.

>> Shell has multiple implementations. At one point I tested the ./configure
>> script of my TXR project with Bash, Zsh, Dash, Ash, public domain Ksh,
>> as well as some POSIX shells of some proprietary Unixes like Solaris's
>> POSIX shell.
>
> I wonder why any other scripting languages exist? Why does TXR? What's
> missing from Bash (and why are there so many variations)?

A heck of a lot is missing from shells, but what's not missing is that
they are there on the majority of today's platforms.

It's a bootstrap step.

It's like asking, what's missing from the BIOS (or any other boot
environment) that we need to boostrap into an OS? If the OS is so
great, why is there still the boot firmware when the machine fires up,
and not just the OS?

Boostrapping: going from something we have that doesn't meet all our
needs, into something we want.

But there is also the fact that nearly all scripting languages "suck"
for the simple use case of coordinating commands.

Also, I don't know of any non-shell scripting language that has mature
POSIX job control. POSIX job control is a set of C APIs and their
behavior geared toward implementing the interactive job control features
of a job control shell. In a job control shell, you can move commands
between foreground and background. The shell acts as a traffic cop,
controlling moving those jobs between those states. Background jobs have
limited access to the terminal. They can be suspended or executing.

>> As far as Windows goes, nobody actually builds my program for Windows
>> other than me. I provide a GUI installer. That's what you do for
>> Windows.
>
> How do you get past AV software?

For some AV to identify your installer as a threat, it has to be a false
positive. I ran into that only once before.

--
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 04:30, Kaz Kylheku wrote:
> On 2024-01-18, bart <bc@freeuk.com> wrote:

> Microsoft's PowerShell language is a lot better (if I believe what
> others say). It's not widely installed though. You'd be better off
> relying on Python from that perspective.

All I know about PowerShell is that instead of typing 'prog' to run the
'prog.exe' you've just created, you have to do '.\prog' just like you
have to do './prog' in Linux.

Plus it has a gazillion options, accessed from diverse places, so you
can spend half your time just trying to get a consistent background
colour. MS really know how to go to town on such things.

(When I tried it just now, the colour of the text I was typing was the
same colour as the background. That makes things interesting.)

>> How do you get past AV software?
>
> For some AV to identify your installer as a threat, it has to be a false
> positive. I ran into that only once before.

With TXR Win64 installer, Windows Defender stopped me from running the
program (until I clicked 'more info' then there was an option to 'run
anyway').

Often, ZIPs are just ignored. (Even gmail will not have them as
attachments.).

More typically, you can get an actual EXE file, but it's treated as
suspicious by AV and may be quarantined.

This is why these days, if somebody wants to run a binary EXE, I make it
available as a C source file.

Since if they have experience of compiling programs from source, they
will already know how to run such programs without AV interference.

(Also, their AV will be familiar with the EXE patterns from their C
compiler; the EXEs my compiler creates may look alien.)

Note that a new Windows machine will stop you running /any/ executable
that is not verified from Microsoft Store or wherever (not even their
own cmd.exe), until you change a non-reversible setting.

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.

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.)

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.

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

(Let's not go into whether the resulting binary can run outside of Android.)

For that matter (this might have been a better example), would you
consider a project that builds using a massive Visual Studio
installation to compiler 'under Linux' if you could somehow run run VS
within Linux?

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.

Remember also that on Windows you want to end up with EXEs and DLLs that
run under actual Windows. Not ELF and SO files.

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

> On 16.01.2024 19:03, David Brown wrote:
>> [...], because they know that Norwegians are superior to Swedes in
>> every way...
>
> I just wanted to reply on that but then I saw your email address... :-)

A Finn smirking from the sidelines.
--
/* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

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.

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

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.

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.

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:
>
>> Microsoft's PowerShell language is a lot better (if I believe what
>> others say). It's not widely installed though. You'd be better off
>> relying on Python from that perspective.
>
> All I know about PowerShell is that instead of typing 'prog' to run the
> 'prog.exe' you've just created, you have to do '.\prog' just like you
> have to do './prog' in Linux.

I don't know anything about PowerShell. In the case of the POSIX-like
shells, this is just a consequence of the . directory not being listed
in the PATH variable, which is an end-user configuration matter.

If you care about the convenience of just typing "prog", more than
about the security aspect, you can just add . to your PATH.

> Plus it has a gazillion options, accessed from diverse places, so you
> can spend half your time just trying to get a consistent background
> colour. MS really know how to go to town on such things.

Looks like you have nowhere to run. Don't like Unix; and the Mirosoft's
next generation shell is too complex.

> With TXR Win64 installer, Windows Defender stopped me from running the
> program (until I clicked 'more info' then there was an option to 'run
> anyway').

Yes; what good would the name "Defender" be if you cold just download
a random executable and run it without any prompt?

If you get an installer signed by Microsoft, you can get around that.

> This is why these days, if somebody wants to run a binary EXE, I make it
> available as a C source file.

But they need a C compiler EXE to compile it.

This is a complete non-starter for applications which are complex
and don't target programmers.

Even programmers won't use a program on Windows that they have to figure
out how to compile for Windows.

> Since if they have experience of compiling programs from source, they
> will already know how to run such programs without AV interference.

OK, now I understand why you need C compiling to be dead easy.

You'd like to ship .c files to Windows users.

--
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 19:40, Kaz Kylheku wrote:
> 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:
>>
>>> Microsoft's PowerShell language is a lot better (if I believe what
>>> others say). It's not widely installed though. You'd be better off
>>> relying on Python from that perspective.
>>
>> All I know about PowerShell is that instead of typing 'prog' to run the
>> 'prog.exe' you've just created, you have to do '.\prog' just like you
>> have to do './prog' in Linux.
>
> I don't know anything about PowerShell. In the case of the POSIX-like
> shells, this is just a consequence of the . directory not being listed
> in the PATH variable, which is an end-user configuration matter.
>
> If you care about the convenience of just typing "prog", more than
> about the security aspect, you can just add . to your PATH.
>
>> Plus it has a gazillion options, accessed from diverse places, so you
>> can spend half your time just trying to get a consistent background
>> colour. MS really know how to go to town on such things.
>
> Looks like you have nowhere to run. Don't like Unix; and the Mirosoft's
> next generation shell is too complex.

As you know by now, I expect very little of shell programs.

I also only use a tiny corner of Windows. Remember I used to be quite
adept at using 8-bit machines with 64KB of memory and running off floppies.

>> This is why these days, if somebody wants to run a binary EXE, I make it
>> available as a C source file.
>
> But they need a C compiler EXE to compile it.

It's either that or run my EXE.

> This is a complete non-starter for applications which are complex
> and don't target programmers.

So how are those applications distributed on Linux?

>
> Even programmers won't use a program on Windows that they have to figure
> out how to compile for Windows.

That would be me too, everytime I want try out someone's project or use
some library.

At least I make the process as simple as it can be without using a
binary: my generated C code needs 3 files from Tiny C which come to
235KB, and one C source file. It should build in a fraction of a second.

But of course, you have to pick holes in that!

"It's far too complicated". "Supply a binary instead".

Whether someone will accept my binaries is up to them. But since my
programs are related to languages, such people will be fairly technical.

(I also have other choices: I can supply the bulk of an application in a
special binary format of my own. That then only needs a 12KB actual EXE
to launch, that should be easier to get past the AV. Or it can be an
800-line C program to be compiled locally.)

In the distant past when I had lots of non-technical customers then of
course we supplied binaries. But no one was worried about viruses then.

>> Since if they have experience of compiling programs from source, they
>> will already know how to run such programs without AV interference.
>
> OK, now I understand why you need C compiling to be dead easy.
>
> You'd like to ship .c files to Windows users.

Windows users who are programmers interested in different languages. Or
who want to learn the simplest way of distributing an application which
is one step away from binary.

And there's a bonus: the same 'dead easy' way also works on Linux.

But I've lost track of what you're objecting to:

* If I supply a binary executable, is that good or bad from your POV?

* If I supply a one-file C version that be trivially compiled locally
into a binary, is that good or bad?

* Is the only thing acceptable to you, to supply a C version in 178
source files in 34 nested directories, together with a collection of
'configure' files and makefiles, and that will only build in a Linux
environment?

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.

This is where MS Windows reigned supreme.

On 18/01/2024 16:16, bart 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.)

(It is not a "likelihood" - it is a fact. Android is Linux with a
particular set of libraries, gui and apps.)

>
> Now, somebody brings out some piece of software that only builds under
> Android.
>
OK.

> To build it under Linux, requires installing a vast virtual Android OS
> to do that.
>
> Would you consider that being able to build 'under Linux'?
>

That's a rather speculative and hypothetical idea that is very different
from using mingw-64 to configure and compile software on Windows. After
all, with mingw-64 / msys2, the resulting binary runs on Windows, not
Linux. I use mingw-64 compiled binaries on Windows all the time, and
they don't need even anything installed on the target system (except
sometimes a few dll's, just like any Windows program). You do need some
supporting basic programs in order to /build/ mingw-64 binaries - at
least gcc, make, and perhaps some utilities like bash and sed. (Or you
can install a mingw-64 target compiler on Linux and cross-compile -
building the Windows binaries under Linux.) But yes, these are all
programs build for Windows and running under Windows. They are not hard
to install or harder to run compared to running them on anything else.

WSL is more of a virtual machine, but it is well integrated into Windows.

My daily work is building software with cross-compilers. Sometimes I
build "under Linux", using Linux elf binaries like "make" and
"arm-none-eabi-gcc". Sometimes I build "under Windows", using Windows
exe files like "make.exe" and "arm-none-eabi-gcc.exe". In each case,
there is a large tree full of toolchain programs, headers, target
library files, etc., to support it - far bigger than my "msys2"
installation (which is not needed for these builds). I consider it
"building under Linux" or "building under Windows", because I am running
those OS's and running programs for those OS's.

> (Let's not go into whether the resulting binary can run outside of
> Android.)
>
> For that matter (this might have been a better example), would you
> consider a project that builds using a massive Visual Studio
> installation to compiler 'under Linux' if you could somehow run run VS
> within Linux?
>

Yes.

> 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.

You are drawing completely arbitrary lines without any justification.

> Remember also that on Windows you want to end up with EXEs and DLLs that
> run under actual Windows. Not ELF and SO files.
>
>
>

On 1/18/2024 11:15 AM, 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:
[...]
>> 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.[...]
> 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.

I do not mind if you take my code and tell me that is has an issue with
a compiler that I have not tried it on. You did this to my experimental
cipher code. Guess what, it compiles and works on many compilers now
because of your comments. So, thanks again.