On 08/08/2023 23:58, Kaz Kylheku wrote:
> On 2023-08-08, Bart <bc@freeuk.com> wrote:
>> On 08/08/2023 22:51, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 08/08/2023 01:59, Keith Thompson wrote:
>>> [...]
>>>>> bcc is your implementation, right?
>>>>
>>>> It's my compiler, but it uses msvcrt.dll to do the print. tcc uses the
>>>> same library with the same output. Both seem to use a default of 6
>>>> places after the ".", whether hex or decimal.
>>> [SNIP]
>>>
>>> To summarize, your implementation (bcc) uses msvcrt.dll to provide
>>> the implementation of the printf function, and that implementation
>>> implements "%a" and "%A", but does so incorrectly. That's a bug in
>>> that particular version of msvcrt.dll (and in your implementation).
>>>
>>> (The output is likely enough to distinguish between adjacent
>>> floating-point values (I haven't verified that), but not enough to
>>> represent the value exactly, which is what the standard requires.)
>>
>> This is actually something I hadn't considered. If the purpose of %A is
>> a 100% accurate representation of the whole number, then those 7 digits
>> shown by msvcrt.dll are not enough, and it is wrong.
>
> MSVCRT.DLL is a system library you're not supposed to use.

And yet, nearly every other program uses it. Including gcc.exe of mingw:

Entry: 168014
Lookup RVA: 168290
Time Date Stamp: 0
Fwd Chain: 0
Name RVA: 169B14
Name: msvcrt.dll <------------------------
Import Addr RVA: 1688D0
Import:16929C 38 __C_specific_handler
Import:1692B4 40 ___lc_codepage_func
Import:1692CA 43 ___mb_cur_max_func
Import:1692E0 52 __getmainargs
....

And tcc.exe. And every program compiled with that gcc imports
msvcrt.dll, even if it uses its own libraries too.

They can't get rid of it because too many things would stop working.

On 2023-08-08, Bart <bc@freeuk.com> wrote:
> On 08/08/2023 23:58, Kaz Kylheku wrote:
> > On 2023-08-08, Bart <bc@freeuk.com> wrote:
> >> On 08/08/2023 22:51, Keith Thompson wrote:
> >>> Bart <bc@freeuk.com> writes:
> >>>> On 08/08/2023 01:59, Keith Thompson wrote:
> >>> [...]
> >>>>> bcc is your implementation, right?
> >>>>
> >>>> It's my compiler, but it uses msvcrt.dll to do the print. tcc uses the
> >>>> same library with the same output. Both seem to use a default of 6
> >>>> places after the ".", whether hex or decimal.
> >>> [SNIP]
> >>>
> >>> To summarize, your implementation (bcc) uses msvcrt.dll to provide
> >>> the implementation of the printf function, and that implementation
> >>> implements "%a" and "%A", but does so incorrectly. That's a bug in
> >>> that particular version of msvcrt.dll (and in your implementation).
> >>>
> >>> (The output is likely enough to distinguish between adjacent
> >>> floating-point values (I haven't verified that), but not enough to
> >>> represent the value exactly, which is what the standard requires.)
> >>
> >> This is actually something I hadn't considered. If the purpose of %A is
> >> a 100% accurate representation of the whole number, then those 7 digits
> >> shown by msvcrt.dll are not enough, and it is wrong.
> >
> > MSVCRT.DLL is a system library you're not supposed to use.
>
> And yet, nearly every other program uses it. Including gcc.exe of mingw:

Yes; by doing that, they are perpetrating a poor practice.

It's a good reason to stay away from the MinGW project.

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

David Brown <david.brown@hesbynett.no> writes:
[...]
> That is a hopeless attitude to take. You are simply guaranteeing that
> people will not use it for internationalisation - or that they will
> hate the tool when they try to use it. Targeting hobby users is not
> an excuse for bad design. I would suggest you remove all traces of
> internationalisation until you have found a way to make it work. (And
> drop the XML format while you are at it - a simple one line, one
> command text format would be vastly easier for everyone.)
[...]

If you're going to do internationalization, I suggest using some
standard format to store the messages.

GNU gettext uses a plain-text ".po" format.

There's also an ISO standard format called XLIFF which is, for
better or worse, XML-based.
https://en.wikipedia.org/wiki/XLIFF

XLIFF is probably used widely enough that there are tools that let
users treat the XML files as opaque binaries.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Bart <bc@freeuk.com> writes:
>
>You know, I'd like to see what a bare gcc installation looks like, as I
>don't think I've seen one yet!
>
snip

>(Let me guess: it will have no system headers, no assembler, and no
>linker. You then start to question exactly what 'gcc' is, and what it
>can do.)

You can download the sources yourself, if you like.

https://gcc.gnu.org/gcc-13/

It is rather easy to build.

Bart <bc@freeuk.com> writes:
> On 08/08/2023 23:46, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> gcc 13.2 comes with make.exe, so they learnt something! (I wonder at
>>> what point they decided that actually providing 'make.exe' was a good
>>> idea?)
>>
>> No, gcc 13.2 does not come with make.exe. gcc and make are separate
>> packages.
>>
>> Who exactly are "they"? (I think I know who you're referring to.
>> I think you do too. What I'm curious about is why you chose to
>> omit that piece of information.)
>
> You know, I'd like to see what a bare gcc installation looks like, as
> I don't think I've seen one yet!

Because gcc by itself is not useful. It's part of a C implemention.

But you know that.

> As they can be anything up to 1GB.
>
> (Let me guess: it will have no system headers, no assembler, and no
> linker. You then start to question exactly what 'gcc' is, and what it
> can do.)

Those are good questions to ask. Some of us have tried to answer them
for you, but you don't listen.

> The 13.2 version I think might be from this page:
> https://www.mingw-w64.org/downloads/

Ok. I thought you were using TDM-GCC. In any case, if you think that
that page just provides gcc then you haven't read it:

The heart of the Mingw-w64 project is headers and support libraries
to run the output of GCC on Windows. Since Mingw-w64 is neither the
home of GCC nor of binutils, several sets of installation packages
which combine them are available.

[...]

> This is to demonstrate that C implementations can exist in different forms.

I'm surprised that you admit that.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

scott@slp53.sl.home (Scott Lurndal) writes:
> Bart <bc@freeuk.com> writes:
>>
>>You know, I'd like to see what a bare gcc installation looks like, as I
>>don't think I've seen one yet!
>>
> snip
>
>>(Let me guess: it will have no system headers, no assembler, and no
>>linker. You then start to question exactly what 'gcc' is, and what it
>>can do.)
>
> You can download the sources yourself, if you like.
>
> https://gcc.gnu.org/gcc-13/
>
> It is rather easy to build.

It's fairly easy to build on Unix-like systems; less so on Windows
without some Unix-like emulation layer.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

> On Tuesday, 8 August 2023 at 15:39:21 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > I used CMake for the Baby X resource compiler. It worked on Windows
>> > and Mac. But it broke on Linux when Ben tested it.
>> Maybe you were able to conclude that, but I only reported compile
>> errors. That may have been the fault of CMake, but you never said what
>> the problem was, only to say that "linux" included <stdint.h>.
>>
> The MP3 decoder included a few standard headers, then typedefed
> types like uint8_t, to match <stdint.h>. It works fine on Windows and Mac
> because the standard headers don't define those types.

What do you really mean here? It can't be what you wrote. Windows and
Mac don't define those types but then /no/ OS defines them. OSes don't
define C types. A C implementation will provide a header that defines
them, but they will be defined only if the program includes that header.
There are C implementation for Windows and Mac that provide <stdint.h>.
I would be surprised if the implementation you are using on Windows and
on Mac don't.

> But on Linux,
> they obviously include <stdint.h>, whch I believe they are allowed to
> do, and so the code broke.

Who is "they"? Originally you said that Linux included the file, which
was obviously a shorthand for something, but I could not tell what. I
remember asking at the time. You didn't say.

One reading is that "they" are the authors of the MP3 decoder. By that
reading, "they" have broken code because it both defines the types and
includes <stdint.h>. That seems unlikely though.

--
Ben.

On 09/08/2023 01:52, Keith Thompson wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Bart <bc@freeuk.com> writes:
>>>
>>> You know, I'd like to see what a bare gcc installation looks like, as I
>>> don't think I've seen one yet!
>>>
>> snip
>>
>>> (Let me guess: it will have no system headers, no assembler, and no
>>> linker. You then start to question exactly what 'gcc' is, and what it
>>> can do.)
>>
>> You can download the sources yourself, if you like.
>>
>> https://gcc.gnu.org/gcc-13/
>>
>> It is rather easy to build.
>
> It's fairly easy to build on Unix-like systems; less so on Windows
> without some Unix-like emulation layer.

That link is not very specific. I ended up here as the nearest thing
that looked like sources:

https://mirrorservice.org/sites/sourceware.org/pub/gcc/releases/gcc-13.2.0/

I downloaded one of these. There were 124,000 files across 5400 folders,
totalling 700MB.

Other than 75,000 .h and .c files, there were 100s of files with
extensions .cpp, .hpp, .py, .m4 and .awk among many others.

I think Scott was having a laugh when he said it was easy to build. I
wouldn't a clue where to start.

But I also don't believe these are the sources code to the basic gcc
compiler, unless the basic compiler is 500MB.

This was a good exercise however, it reminded me of why I do what I do.

The sources for my C compiler /and/ standard headers /plus/ my windows.h
can be represented as one 1.2MB file in one folder. It can be compiled
to an executable in 0.09 seconds.

(I'd like to know what you guys consider hard to build.)

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> The problem with the hex-binary form of C is that the representation
>>>>> of the significant figures varies according to exponent.
>>>>
>>>> No necessarily. An implementation can choose to be consistent. In
>>>> fact, it would take some effort not to be consistent in this regard.
>>>> Different implementation may choose different representations of the
>>>> same number, but for a single implementation I would expect the
>>>> digits to be the same regardless of the exponent.
>>>
>>> I understand what you're saying here, and agree with it.
>>>
>>> However, there is a subtle point that deserves mentioning. If a
>>> 'double' value is printed using %a, and the same value is
>>> converted to a 'long double' and printed using %La, in most cases
>>> the digits (and exponents) of the outputs will be different.
>>
>> That does indeed happen in the libc printf I'm using. I am almost
>> tempted to look at the code to see why that is done. Maybe there is an
>> obvious reason for it, but I can't think of one off the top of my head.
>
> It happens because of the formats of double and long double. For
> most non-zero values (and not inf or NaN), a double has 52 bits
> of significand plus an implied '1' at the top, giving 53 bits
> overall. Converting to long double gives 64 bits of significand
> only now the high-order '1' is explicit (ie, 64 bits overall).
> So double has one bit for the leading digit (always 1) plus 13
> groups of four bits, whereas long double has four bits for the
> leading digit (always between 8 and F) plus 15 groups of four
> bits.

I'd forgotten that Intel long doubles use bit 63 explicitly. So you are
saying it's just for simplicity -- just dump the nibbles. You make it
sound almost inevitable, but compatible output, with a leading "0x1.",
could have been generated. However, there's a lot of sense in just
dumping the nibbles. For one thing, you get the hex values you'd see
for if you were to examine memory in a debugger.

> If you see a %a output whose leading digit is between 8 and F,
> probably what was done is the double value was converted to a
> long double, so the long double value could just be funneled
> through the code for the long double case.

I was wondering why an implementation would do that. Of course, you
then loose the advantage of getting the hex digits you'd see in memory.

--
Ben.

On 8/8/23 10:16 AM, Bart wrote:
> On 08/08/2023 13:22, Richard Damon wrote:
> > On 8/8/23 7:05 AM, Bart wrote:
> >> On 08/08/2023 03:21, Richard Damon wrote:
> >>  > On 8/7/23 8:28 PM, Bart wrote:
> >>  >> My view is that C's print-format system is not fit for purpose. The
> >>  >> formatting is OK, it is needing to specify types that is the
> problem.
> >>  >
> >>  > which is EXACTLY the arguement that got us the C++ stream <<
> operator.
> >> That feature is so bad it makes using printf preferable! Is it really
> >> that hard to just be able to write 'print x' ?
> >>
> >>  > If you want to do that in C, you can, just define a generic "print"
> >>  > function that defines version for each fundamental type, and call
> >> that.
> >>  >
> >>  > You don't seem to understand that C is based on the assumption that
> >> the
> >>  > programmer actually knows what he is doing, not hiding behind a
> >> mass of
> >>  > abstractions.
> >>
> >> You don't get my point. The programmer might not know for sure the
> >> type of a complex expression, and certainly does not want to keep
> >> updating dozens of printf formats across the codebase as global
> >> declarations change.
> >
> > Then they are using the wrong tool.
>
> What tool did you have in mind? Do you mean that an IDE will tell you
> the types of the expressions, or write the format codes for you?

IF you actually want to output expressions that you don't know the type,
you need something that supports that. Maybe C++, maybe Python, maybe
something else like that.

It seems you have one tool in your box, so everything is a nail.

>
> That strikes me as the same argument that you can use CDECL to get round
> abstruse C type specs. If the tool can do it, why doesn't the compiler?
> Or the language.

Except the issue you are describing isn't handled by CDECL. That
generally needs the fully expressed type, and you complaint seems to be
a type that has been hidden via typedefs and the like.

So CDECL doesn't do what you want.

>
> > C is designed to be used when you know, at least in general, what you
> > are working with.
> >
> >>
> >> Right now I don't know how to print a clock() result for example, and
> >> to keep inventing special formats like %zu is crass.
> >>
> >> *I* can just write:
> >>
> >>      println a, b, c
> >
> > So, why don't you?
>
> I do. It's lovely. The question is, why are a million users of C denied
> that?

Because that isn't C. If you want basic, you know where to find it.

Note, "println" like that can't do a lot of things that printf can do
when properly used, so it becomes the problem of just using the right tool.

>
> > is the problem that you don't know how to translate that into C?
> >
> >>
> >> So can a dozen other languages (even from the 1960s!). I can change
> >> the types of a, b, c, and it still works. I can print c, b, a and it
> >> still works.
> >>
> >> I can even just do 'print clock()'!
> >>
> >> In C YOU CAN'T DO THAT. You need to dig up the types of each
> >> expression and apply the right format. In this VERY simple case, it
> >> MIGHT be:
> >
> > Because C is a lower level, and targeted to be more efficiet, than those
> > other languages.
>
> Sorry, but that is rubbish. My 'M' language is also low level, but
> somehow manages to have a proper print. And it's not dead slow either:

And I bet it only runs on x86 processors?

>
> A loop which prints the numbers up to 10 million (redirected to a file
> to remove display overheads), takes 1.8 seconds in my language, and 3.2
> seconds using gcc 13.2 -O3. bcc/tcc take 2.4 seconds.
>
> (My library is faster, despite the int->text code being unoptimised,
> because of buffering. But then maybe gcc's printf is also buffered
> internally. Which one is cheating more? I know mine won in this case!)

Maybe you used the wrong C library to do that.

Also, since you have shown that you format routines don't meet the full
functionality of C's, that will give it an advantage.

>
>
> >>
> >>      printf("%lld " PRId64 " %s", a, b, c);
> >>
> >> But now you have an extra maintenance headache.
> >>
> >> (In all cases, printing gets untidy when you need to do necessary
> >> formatting, but only C incorporates types into the formatting.)
> >>
> >>
> >>  >> It gets tricky when using sprintf say from another language,
> which is
> >>  >> then transpiled to actual C.
> >>  >
> >>  > And why doesn't that other language implement a better print
> >>  > functionality itself?
> >>
> >> It does, but ultimately it needs to do I/O, and I've been using C's
> >> printf for that since the mid-90s, because it was simpler than using
> >> WinAPI. I've since forgotten how do it with WinAPI.
> >
> > So, your problem is that you aren't willing to do the work yourself.
>
> What problem is this? I've been implementing 'proper' PRINT in languages
> since as far back as 1981.

Then why are you complaining that the C printf doesn't meet your
requireents?

>
> At some point, nearly 20 years later, I switched from OS to C functions
> for low-level I/O, for consoles or files. For Printing to printers,
> images, windows and strings, I still handled that.

So?

You added a layer of abstraction, so maybe you programs can run on more
targets.

>
> > So again, the problem is you are using the wrong tool or your language
> > is incomplete.
>
> The problem is that you don't have a clue what the problem is.

No, I fully understand it.

>
> There is no tool, and no feature in my language (other than turning it
> into C), that will fix the problem that C's 'char*' is so unique.

Why is C's char* being unique a problem?

It still sounds like the problem is you don't understand what C is
doing, so you are misusing it.

>
> Usually you can ignore that if using C's library purely via a binary
> interface, but if generating C code, you will see issues. The solutions
> are ugly and ungainly.

But "intermediary" output is almost always "ugly", that is part of the
nature of machine generated code. If you "compilation" is any good, no
one needs to look at it.

>
> Try it and see!
>
> > But to use C as a portable assembler, you need to use it as an
> > assembler, and that means understanding the nature of the "assembly
> > language".
>
> An assembly language which has a million more rules, special cases  and
> UBs than any real assembler!

Your thinking about the wrong machine. Remember, in C, the machine you
need to be thinking about is the "abstract machine" defined by the standard.

>
> In x64 assembly, I can write a floating point value to a 64-bit memory
> location, and read it back as an integer, with no issues:
>
>      movq [fred], xmm0
>      mov rax, [fred]
>
> C makes that undefined - maybe.

So?

>
> > IF you are concerned about efficient outputing of valuse, you build a
> > family of generic "print" functions that use the right version for the
> > type given, and let the complier figure it out. Just means you can't put
> > everything in one statement. (but this is intermediary code, so doesn't
> > really need to be totally readable).
>
> This is exactly what I do behind the scenes of my language. And another
> reason why I sometimes use 'printf', since it produces long sequences of
> function calls which obscure minimal test code.
>
> The advantage of printf also is that it is outside my language, so its
> implementation code doesn't intrude.
>

And if the doesn't meet your requirements, don't use it.

One big aspect of printf, is you need to know the "type" of each
arguement you give it. If you do, it works well, if you don't you just
can't use it.

You seem to think this is a bug instead of its design decision.

Bart <bc@freeuk.com> writes:
[...]
> But I also don't believe these are the sources code to the basic gcc
> compiler, unless the basic compiler is 500MB.

gcc officially stands for "GNU Compiler Collection". (It was originally
"GNU C Compiler", but it was changed when support for other languages
was added.)

It includes compilers for a number of languages, including C, C++, Ada,
Fortran, Objective-C, Go, and Modula-2.

Since you've downloaded the sources, the libffi directory may or may not
be of some interest to you (see libffi/README.md).

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

> On Tuesday, 8 August 2023 at 18:32:21 UTC+1, Scott Lurndal wrote:
>>
>> 1) Using a make variable in the rule for '.c' -> '.o' and setting the
>> variable to the name of the compiler:
>>
>> CC=bcc
>> ...
>> %.o: %.c
>> @$(QUIET) || echo " COMPILE $<"
>> $(HUSHCOMPILE)$(CC) $(CFLAGS) -MMD -MP -o $@ -c $<
>>
> Exactly,
> Bart is right.

You are deliberately ignoring the context. Bart wants gcc prog.c to
write to prog, but in the computer world I inhabit, you do that with
make prog. No makefile needed. No mess. This is annoying to Bart
because he hates make almost as much as he hates C, so he adds another
twist -- what about all the compilers I have installed? Well, on my
system (hardly a special one) the answer for make-haters is, say,

CC=tcc make prog

Now you can put CC=tcc into a one-line makefile or say "export CC=tcc"
if you plan to do a lot of tcc builds but I expect even that will result
in a lot of fainting and clutching at pearls with the horrid complexity
of it all.

--
Ben.

On Wednesday, 9 August 2023 at 03:04:19 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> > On Tuesday, 8 August 2023 at 18:32:21 UTC+1, Scott Lurndal wrote:
> >>
> >> 1) Using a make variable in the rule for '.c' -> '.o' and setting the
> >> variable to the name of the compiler:
> >>
> >> CC=bcc
> >> ...
> >> %.o: %.c
> >> @$(QUIET) || echo " COMPILE $<"
> >> $(HUSHCOMPILE)$(CC) $(CFLAGS) -MMD -MP -o $@ -c $<
> >>
> > Exactly,
> > Bart is right.
>
> You are deliberately ignoring the context. Bart wants gcc prog.c to
> write to prog, but in the computer world I inhabit, you do that with
> make prog. No makefile needed. No mess.
>
I never knew that. On my Apple it works.
The advantage of a.out as the executable name is that 99% of your builds
as a developer are test builds. It it's called "a.out" it's less likely to be
accidentally used as a finished program.
>
> This is annoying to Bart
> because he hates make almost as much as he hates C, so he adds another
> twist -- what about all the compilers I have installed? Well, on my
> system (hardly a special one) the answer for make-haters is, say,
>
> CC=tcc make prog
>
> Now you can put CC=tcc into a one-line makefile or say "export CC=tcc"
> if you plan to do a lot of tcc builds but I expect even that will result
> in a lot of fainting and clutching at pearls with the horrid complexity
> of it all.
>
The problem with make is not that it lacks functionality. It's that when
a makefile falls over it's too hard to fix.

On Tuesday, 8 August 2023 at 23:26:47 UTC+1, David Brown wrote:
> On 08/08/2023 19:04, Malcolm McLean wrote:
> > On Tuesday, 8 August 2023 at 17:46:15 UTC+1, David Brown wrote:
> >> On 08/08/2023 18:04, Malcolm McLean wrote:
> >>> On Tuesday, 8 August 2023 at 16:18:49 UTC+1, David Brown wrote:
> >>>> On 05/08/2023 14:08, Malcolm McLean wrote:
> >>>>
> >>>>> This is the problem of course. The Baby X API expects data in a certain format.
> >>>>> So all the API functions which operate on images take a 32 bit RGBA buffer
> >>>>> as an "unsigned char *", and the dimensions as two ints. But another API might
> >>>>> use an opaque "IMAGE" structure. Or another system might have 16 bit r5g5b5a1
> >>>>> images.
> >>>>
> >>>> It would make a lot of sense to have a program that took data in common
> >>>> standardised uncompressed forms (like .wav, .bmp) and generated data in
> >>>> whatever format suits Baby X.
> >>>>
> >>> "Data" means, "that which is given". People programming applications are given
> >>> resources in many formats. They might steal a PNG from the web, get a JPEG
> >>> commissioned from a paid artist, knock up their own SVG.
> >>> Now of course it's possible to convert all these into a common format like PNG
> >>> which is powerful enough to hold all thse formats without loss. But you've lost
> >>> the link with the original data. So when the artist comes back with a second
> >>> version of the JPEG, you've got to run ImageMagick again. And I don't have
> >>> ImageMagick installed on the Mac I'm writing this on (there's a program called
> >>> sips which does similar things).
> >>> A resouce pipeline with lots of stages, each one requiring a separate third party
> >>> program, is quite fragile. It works for as long as your Linux machine is all set up
> >>> with the dependencies, which will be the case for the duration of the project.
> >>> But if you archive it, and dust it off years later, will things still be intact? And
> >>> will you know which are the intermediate files, and which are the original data?
> >> It looks like there is someone else in this group who could benefit from
> >> understanding "make" and/or other build tools. And if you can't use a
> >> Mac for development, scrap the expensive toy and install a usable
> >> system. (Of course, you /can/ use a Mac for development - you just need
> >> to know how to use your tools.)
> >>
> > Bart's right about make. If it actually worked properly we wouldn't need CMake.
> "make" works perfectly well for its purpose. CMake is a different tool,
> doing a different job. In fact, CMake generates makefiles for use by
> "make" (as well as project files for MSVC, and other types of build
> system). CMake is a higher level tool. ("make" can, in combination
> with compilers like gcc, do a fair amount of higher level work as well,
> such as tracking dependencies and files automatically.)
>
CMake is an alternative to make. It can generate make files, in fact that's the
default. Which means that if you ship a project with a CMake script, you
wouldn't normally provide a make file. CMake found a niche largely because
make files are too difficult to use. The other reason is that the big IDEs
rejected makefiles as their format for describing how to build projects.
>
> One thing that "make" is particularly good at is chains of processes.
> It is straightforward to say that "picture.o" is compiled from
> "picture.c" which is resource-compiled from "picture.bmp" which is
> converted from "picture.jpg". I sometimes have that kind of thing in
> makefiles for building documentation, where the graphics files I want to
> add to my LaTeX documents might need conversions or manipulations from
> the originals.
>
> > But it's unmaintainable.
>
> Not for people who are familiar with it.
>
Many programmers might start a new project only once every two years. And
it might not be their job to write the makefile. So they are not going to be very
familiar with make. Maintainable software needs to be maintainable by people
who don't have a deep familarity with it. I can debug Cmake scripts despite
not really knowing the CMake language, because it's close enough to a normal
procedural programming language for someone who can program but doesn't
know CMake specifically to follow along.
>
> Certainly complicated makefiles are harder to deal with than simple
> ones. It's a powerful tool with many features, and takes time and
> effort to learn. But complicated ones can reduce maintenance - my
> makefiles do not need modification as files are added or removed from a
> project, or dependencies on headers change - it is all handled
> automatically.
>
> > Baby X is mainly for small hobby type programs. It's easier to use than
> > the raw X11 interface, and it's far lighter weight than Qt or GTK. It also
> > ports to Windows. So most of the users will be bedroom programmers
> > who will set up the internationalisation strings themselves, rather than
> > employing professional translators.
> That is a hopeless attitude to take. You are simply guaranteeing that
> people will not use it for internationalisation - or that they will hate
> the tool when they try to use it. Targeting hobby users is not an
> excuse for bad design. I would suggest you remove all traces of
> internationalisation until you have found a way to make it work. (And
> drop the XML format while you are at it - a simple one line, one command
> text format would be vastly easier for everyone.)
>
It works. The question is whether it's a good approach to the problem.
As I said, the user of Baby X will be mostly hobby programmers. So the
emphasis is on making things easy to use. Adding alternative translations
under an <international> tag is easy to do.

However I fully accept that there might be a far better approach. Keith
Thompson has made some constructive suggestions.

XML has some advantages over an ad-hoc line-based format. The parser needs
work as it's currently too basic. But XML should be familiar to most programmers.

On 08/08/2023 19:53, Scott Lurndal wrote:
> Properly designed makefiles are a joy
> to work with.
>

They are a joy to work with, yes. But they can be less joyful to write
sometimes, and debugging is rarely easy. However, you rarely have to
write them in practice - usually for a new project, I take an existing
makefile (or set of makefiles) and change details such as project name,
compiler, flags, etc., and we are off. I am not sure if I have started
a new makefile from scratch since my first one many decades ago!

On 09/08/2023 02:58, Richard Damon wrote:
> On 8/8/23 10:16 AM, Bart wrote:
>> > Then they are using the wrong tool.
>>
>> What tool did you have in mind? Do you mean that an IDE will tell you
>> the types of the expressions, or write the format codes for you?
>
> IF you actually want to output expressions that you don't know the type,
> you need something that supports that. Maybe C++, maybe Python, maybe
> something else like that.
>
> It seems you have one tool in your box, so everything is a nail.

So, by 'tool' you mean a different language?

>> I do. It's lovely. The question is, why are a million users of C
>> denied that?

> Because that isn't C. If you want basic, you know where to find it.

So, the answer isn't a different language? I'm confused!

What tool did you have in mind if I wanted to print stuff easily in C?

>
> Note, "println" like that can't do a lot of things that printf can do
> when properly used, so it becomes the problem of just using the right
tool.

99% of the print statements I write (not 99% of the ones that are
permanent parts of source code) are temporary debug statements. Their
formatting needs are minimal.

In my syntax, I would most commonly write 'println =a,=b' where the '='
adds a label to the output, which might look like:

A=100 B=100

>> Sorry, but that is rubbish. My 'M' language is also low level, but
>> somehow manages to have a proper print. And it's not dead slow either:
>
> And I bet it only runs on x86 processors?

The very first version ran on Z80 8-bit processors. The current one
generates native code for x64 for Windows.

I can run my programs also on ARM devices and/or on Linux but it needs
to use intermediate C code (which is where all the problems of C come
into play).

My first compiler though was for a language that wasn't mine; it
generated native code for the 36-bit PDP10 processor. I can't remember
the Print facilities of that language, except that it wouldn't have used
format codes!

>>
>> A loop which prints the numbers up to 10 million (redirected to a file
>> to remove display overheads), takes 1.8 seconds in my language, and
>> 3.2 seconds using gcc 13.2 -O3. bcc/tcc take 2.4 seconds.
>>
>> (My library is faster, despite the int->text code being unoptimised,
>> because of buffering. But then maybe gcc's printf is also buffered
>> internally. Which one is cheating more? I know mine won in this case!)
>
> Maybe you used the wrong C library to do that.

So tell me how to get gcc 10.3 /or/ gcc 13.2 faster, as I don't know
how. I mean, that is not my problem.

> Also, since you have shown that you format routines don't meet the full
> functionality of C's, that will give it an advantage.

What functionality are you thinking of? I can do nearly everything that
printf can, and when it can't, I can just call printf.

>> There is no tool, and no feature in my language (other than turning it
>> into C), that will fix the problem that C's 'char*' is so unique.
>
> Why is C's char* being unique a problem?

Because in language X, strings and string literals are sequences of
unsigned bytes. If transpiling to C, how do you represent string
literals of X for example?

Writing "ABC" will create a term that in C has type char*, not unsigned
char*, which can cause problems used with string objects that are
declared as unsigned char*.

If you cast every string literal as (unsigned char*)"ABC", then it will
cause problems in calling C functions like puts(), which take a char*
parameter.

If you declare, in the generated C, your own version of puts that takes
unsigned char*, then a compiler like gcc will complain that it is an
incorrect prototype for a standard function.

This is about where I'm at. But further, there will be innumerable other
functions in myriad libraries that take char* arguments.

> It still sounds like the problem is you don't understand what C is
> doing, so you are misusing it.

The problem is C's bizarre plain 'char' type, which like some quantum
particle, although it necessarily has to be signed or unsigned, you're
not allowed to assume either one or the other in any program. So there
are three classes of char types.

> Your thinking about the wrong machine. Remember, in C, the machine you
> need to be thinking about is the "abstract machine" defined by the
> standard.

I have my own model in mind of the machine I want to write for. It more
or less identical to the actual physical machines most of us use.

But C doesn't allow that because /its/ model has to be a single one that
has to work on every conceivable architecture past, present and future,
including the DeathStation 9000.

Which is not that practical of course that's why there is so much UB and
so much that is vaguely defined. (stdint.h is a bolted-on concession,
but that works poorly.)

That is of no interest to those of us with language X which we want to
run on machine Y, but do not support direcly so need to go through C.

> One big aspect of printf, is you need to know the "type" of each
> arguement you give it. If you do, it works well, if you don't you just
> can't use it.
>
> You seem to think this is a bug instead of its design decision.

It's designed that way so it's not a bug, but it's just poor:

int i=1234;

printf("i = %s", i);

Or even printf("%s").

Crash.

Sure, a few decades on, /some/ compilers will detect that mismatch (even
though they're not supposed to know the workings of library routines),
but that's just a poor sticking plaster fix.

My simple C compiler can't detect it. (It does have the %? format which
adapts to the actual type used in the argument, but that won't work
anywhere else.)

> Try to explain how you would change C so that printf could be more
> forgiving on the type given to it without totally changing how the
> language works.

As I said, I played with "%?" format (and also "%=?") so that you can write:

void* a=&a;
double b=34.5;
char* c="Bart";
uint64_t d=-1;

printf("%=? %=? %=? %=?\n", a, b, c, d);

Output is:

A=000000000080FF18 B=34.500000 C=Bart D=18446744073709551615

It doesn't solve all the problems in all cases, and sometimes you need
to use a proper format (eg, you might want hex output for 'd'), but it
covers most of my casual uses of printf.

At least it's something; what have /you/ done alone those lines?

And you can do this:

printf("%=? %=? %=? %=?\n", d, b, c, a);

Reverse the item order, but you don't need to edit the format string.
Output now is:

D=18446744073709551615 B=34.500000 C=Bart A=000000000080FF18

That is amazing, I can do what most languages from the 1970s were
capable of!

On 09/08/2023 03:04, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Tuesday, 8 August 2023 at 18:32:21 UTC+1, Scott Lurndal wrote:
>>>
>>> 1) Using a make variable in the rule for '.c' -> '.o' and setting the
>>> variable to the name of the compiler:
>>>
>>> CC=bcc
>>> ...
>>> %.o: %.c
>>> @$(QUIET) || echo " COMPILE $<"
>>> $(HUSHCOMPILE)$(CC) $(CFLAGS) -MMD -MP -o $@ -c $<
>>>
>> Exactly,
>> Bart is right.
>
> You are deliberately ignoring the context. Bart wants gcc prog.c to
> write to prog, but in the computer world I inhabit, you do that with
> make prog.

This is a good example of double standards.

I've complained in the past about having to supply the .c extension to a
/C/ compiler.

Now here make does not need an extension. And make presumably can build
any source code of any language?

How does it know then to deal with prog.c and not prog.cpp or prog.ftn?

How does it know that it has to produce (on Windows) prog.exe?

Wasn't there a huge subthread about people not wanting gcc to
double-guess the name of the executable, even for a single module, so
that a.out or a.exe would be the most acceptable result?

And yet, that is considered common-sense with 'make'? Hmmm....

Besides, there are issues here; make will not supply the -lm flag when
it is needed for example.

And if you do 'make prog' a second time, it will not run the compiler
again. (Sometimes, you are timing how long the compilation takes! Or
maybe there's a time-stamp inside the program.)

Or you need to compile first with -O0 and then when -O3.

> because he hates make almost as much as he hates C, so he adds another
> twist -- what about all the compilers I have installed? Well, on my
> system (hardly a special one) the answer for make-haters is, say,
>
> CC=tcc make prog
>
> Now you can put CC=tcc into a one-line makefile or say "export CC=tcc"
> if you plan to do a lot of tcc builds but I expect even that will result
> in a lot of fainting and clutching at pearls with the horrid complexity
> of it all.

When comparing different compilers I might do:

bcc prog
tcc prog.c
gcc prog.c
gcc prog.c -O3

dmc prog.c in the past
lcc prog.c
cl prog.c

(All of these produce prog.exe - except gcc which produces a.exe,
obviously, because that's the most useful choice, right?!)

So how does make help here?

On 09/08/2023 11:22, Bart wrote:
> On 09/08/2023 03:04, Ben Bacarisse wrote:
> > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >
> >> On Tuesday, 8 August 2023 at 18:32:21 UTC+1, Scott Lurndal wrote:
> >>>
> >>> 1) Using a make variable in the rule for '.c' -> '.o' and setting the
> >>> variable to the name of the compiler:
> >>>
> >>> CC=bcc
> >>> ...
> >>> %.o: %.c
> >>> @$(QUIET) || echo " COMPILE $<"
> >>> $(HUSHCOMPILE)$(CC) $(CFLAGS) -MMD -MP -o $@ -c $<
> >>>
> >> Exactly,
> >> Bart is right.
> >
> > You are deliberately ignoring the context.  Bart wants gcc prog.c to
> > write to prog, but in the computer world I inhabit, you do that with
> > make prog.
>
> This is a good example of double standards.
>
> I've complained in the past about having to supply the .c extension to a
> /C/ compiler.
>
> Now here make does not need an extension. And make presumably can build
> any source code of any language?
>
> How does it know then to deal with prog.c and not prog.cpp or prog.ftn?
>
> How does it know that it has to produce (on Windows) prog.exe?
>
> Wasn't there a huge subthread about people not wanting gcc to
> double-guess the name of the executable, even for a single module, so
> that a.out or a.exe would be the most acceptable result?
>
> And yet, that is considered common-sense with 'make'? Hmmm....
>
> Besides, there are issues here; make will not supply the -lm flag when
> it is needed for example.
>
> And if you do 'make prog' a second time, it will not run the compiler
> again. (Sometimes, you are timing how long the compilation takes! Or
> maybe there's a time-stamp inside the program.)
>
> Or you need to compile first with -O0 and then when -O3.
>
> > because he hates make almost as much as he hates C, so he adds another
> > twist -- what about all the compilers I have installed?  Well, on my
> > system (hardly a special one) the answer for make-haters is, say,
> >
> >    CC=tcc make prog
> >
> > Now you can put CC=tcc into a one-line makefile or say "export CC=tcc"
> > if you plan to do a lot of tcc builds but I expect even that will result
> > in a lot of fainting and clutching at pearls with the horrid complexity
> > of it all.
>
> When comparing different compilers I might do:
>
>    bcc prog
>    tcc prog.c
>    gcc prog.c
>    gcc prog.c -O3
>
>    dmc prog.c           in the past
>    lcc prog.c
>    cl prog.c
>
> (All of these produce prog.exe - except gcc which produces a.exe,
> obviously, because that's the most useful choice, right?!)
>
> So how does make help here?
>
>

It just does it ...

$ >test_c++.cpp
$ make test_c++
g++ test_c++.cpp -o test_c++

$ >test_c.c
$ make test_c
cc test_c.c -o test_c

On 09/08/2023 11:05, Bart wrote:

> And you can do this:
>
> printf("%=? %=? %=? %=?\n", d, b, c, a);
>
> Reverse the item order, but you don't need to edit the format string.
> Output now is:
>
> D=18446744073709551615 B=34.500000 C=Bart A=000000000080FF18

Oops, I forgot to reverse b and c. But it still applies the correct
formats and labels. Make that mistake with normal printf and ... boom!

Actually I can try it, using this line with b and c in the wrong order:

printf("D=%llu C=%s B=%f A=%p\n", d, b, c, a);

With bcc, tcc and gcc, it compiles OK, but crashes.

Isn't gcc supposed to warn about this? Maybe there's some option to do
it, but I don't know what it is. Lot's of people will not know.

The weird thing is that with online gcc/Clang, it compiles and runs and
produces:

D=18446744073709551615 C=Bart B=34.500000 A=0x7ffd33e16bf0

C and B are shown correctly, even though they're in the wrong order! How
is that possible? Switching them has no effect.

It seems to rearrange the inner arguments to match the format codes.

(I think I know what's going on: the online compilers run on Linux,
presumably on x64, with a different ABI.

When it looks for the arg matching "%s", it's picking up the value of c,
the next argument from a GP register, since b is in a floating point
register, and vice versa.

That doesn't happen on Win64 ABI as register assignments are different.)

Here is the full program:

#include <stdio.h>
#include <stdint.h>

int main(void) {
void* a=&a;
double b=34.5;
char* c="Bart";
uint64_t d=-1;

printf("D=%llu C=%s B=%f A=%p\n", d, b, c, a);
}

On 09/08/2023 11:36, Richard Harnden wrote:
> On 09/08/2023 11:22, Bart wrote:
>> On 09/08/2023 03:04, Ben Bacarisse wrote:
>>  > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>  >
>>  >> On Tuesday, 8 August 2023 at 18:32:21 UTC+1, Scott Lurndal wrote:
>>  >>>
>>  >>> 1) Using a make variable in the rule for '.c' -> '.o' and setting
>> the
>>  >>> variable to the name of the compiler:
>>  >>>
>>  >>> CC=bcc
>>  >>> ...
>>  >>> %.o: %.c
>>  >>> @$(QUIET) || echo " COMPILE $<"
>>  >>> $(HUSHCOMPILE)$(CC) $(CFLAGS) -MMD -MP -o $@ -c $<
>>  >>>
>>  >> Exactly,
>>  >> Bart is right.
>>  >
>>  > You are deliberately ignoring the context.  Bart wants gcc prog.c to
>>  > write to prog, but in the computer world I inhabit, you do that with
>>  > make prog.
>>
>> This is a good example of double standards.
>>
>> I've complained in the past about having to supply the .c extension to
>> a /C/ compiler.
>>
>> Now here make does not need an extension. And make presumably can
>> build any source code of any language?
>>
>> How does it know then to deal with prog.c and not prog.cpp or prog.ftn?
>>
>> How does it know that it has to produce (on Windows) prog.exe?
>>
>> Wasn't there a huge subthread about people not wanting gcc to
>> double-guess the name of the executable, even for a single module, so
>> that a.out or a.exe would be the most acceptable result?
>>
>> And yet, that is considered common-sense with 'make'? Hmmm....
>>
>> Besides, there are issues here; make will not supply the -lm flag when
>> it is needed for example.
>>
>> And if you do 'make prog' a second time, it will not run the compiler
>> again. (Sometimes, you are timing how long the compilation takes! Or
>> maybe there's a time-stamp inside the program.)
>>
>> Or you need to compile first with -O0 and then when -O3.
>>
>>  > because he hates make almost as much as he hates C, so he adds another
>>  > twist -- what about all the compilers I have installed?  Well, on my
>>  > system (hardly a special one) the answer for make-haters is, say,
>>  >
>>  >    CC=tcc make prog
>>  >
>>  > Now you can put CC=tcc into a one-line makefile or say "export CC=tcc"
>>  > if you plan to do a lot of tcc builds but I expect even that will
>> result
>>  > in a lot of fainting and clutching at pearls with the horrid
>> complexity
>>  > of it all.
>>
>> When comparing different compilers I might do:
>>
>>     bcc prog
>>     tcc prog.c
>>     gcc prog.c
>>     gcc prog.c -O3
>>
>>     dmc prog.c           in the past
>>     lcc prog.c
>>     cl prog.c
>>
>> (All of these produce prog.exe - except gcc which produces a.exe,
>> obviously, because that's the most useful choice, right?!)
>>
>> So how does make help here?
>>
>>
>
> It just does it ...
>
> $ >test_c++.cpp
> $ make test_c++
> g++     test_c++.cpp   -o test_c++
>
> $ >test_c.c
> $ make test_c
> cc     test_c.c   -o test_c

That doesn't address my points.

Here file name are different. So:

* What happens if there is both test.c and test.cpp?

* What happens if first you want compiler X for test.c and then you want
compiler Y for test.c?

On 2023-08-09, Bart wrote:
> On 09/08/2023 03:04, Ben Bacarisse wrote:
> > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >
> >> On Tuesday, 8 August 2023 at 18:32:21 UTC+1, Scott Lurndal wrote:
> >>>
> >>> 1) Using a make variable in the rule for '.c' -> '.o' and setting the
> >>> variable to the name of the compiler:
> >>>
> >>> CC=bcc
> >>> ...
> >>> %.o: %.c
> >>> @$(QUIET) || echo " COMPILE $<"
> >>> $(HUSHCOMPILE)$(CC) $(CFLAGS) -MMD -MP -o $@ -c $<
> >>>
> >> Exactly,
> >> Bart is right.
> >
> > You are deliberately ignoring the context. Bart wants gcc prog.c to
> > write to prog, but in the computer world I inhabit, you do that with
> > make prog.
>
> This is a good example of double standards.
>
> I've complained in the past about having to supply the .c extension to a
> /C/ compiler.
>
> Now here make does not need an extension. And make presumably can build
> any source code of any language?

'make(1)' is a tool for automating builds. When you write a makefile,
you supply various targets, such as "clean" or "install", etc.

Your target then has the necessary (chain of) commands to complete the
build (or do another task -- such as deleting all the intermediate
object files with a "clean" target, or copying binaries to
/usr/local/bin for the "install" target).

>
> How does it know then to deal with prog.c and not prog.cpp or prog.ftn?

Because you wrote your makefile target such that it's dealing with
"prog.c" and not prog.cpp or prog.ftn. Make isn't intelligent in the
case of changing file extensions or similar. For example, renaming
"prog.c" to "prog.cpp" will result in 'file not found' errors when make
is trying to run the defined 'gcc prog.c -o prog' command.

>
> How does it know that it has to produce (on Windows) prog.exe?

It doesn't, unless you have a "_forWin" target that names the output
"prog.exe".

> [...]
> And if you do 'make prog' a second time, it will not run the compiler
> again. (Sometimes, you are timing how long the compilation takes! Or
> maybe there's a time-stamp inside the program.)

Make is written to save compile time. Why bother re-compiling half a
dozen supporting files when all I did was patch out a bug in 'main()'?

>
> Or you need to compile first with -O0 and then when -O3.

So run the two compilations as part of the same target (unless you mean
to say you want two different targets with two different sets of options
for some reason).

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On Wednesday, August 9, 2023 at 2:50:32 AM UTC+3, Kaz Kylheku wrote:
> On 2023-08-08, Bart <b...@freeuk.com> wrote:
> > On 08/08/2023 23:58, Kaz Kylheku wrote:
> > > On 2023-08-08, Bart <b...@freeuk.com> wrote:
> > >> On 08/08/2023 22:51, Keith Thompson wrote:
> > >>> Bart <b...@freeuk.com> writes:
> > >>>> On 08/08/2023 01:59, Keith Thompson wrote:
> > >>> [...]
> > >>>>> bcc is your implementation, right?
> > >>>>
> > >>>> It's my compiler, but it uses msvcrt.dll to do the print. tcc uses the
> > >>>> same library with the same output. Both seem to use a default of 6
> > >>>> places after the ".", whether hex or decimal.
> > >>> [SNIP]
> > >>>
> > >>> To summarize, your implementation (bcc) uses msvcrt.dll to provide
> > >>> the implementation of the printf function, and that implementation
> > >>> implements "%a" and "%A", but does so incorrectly. That's a bug in
> > >>> that particular version of msvcrt.dll (and in your implementation).
> > >>>
> > >>> (The output is likely enough to distinguish between adjacent
> > >>> floating-point values (I haven't verified that), but not enough to
> > >>> represent the value exactly, which is what the standard requires.)
> > >>
> > >> This is actually something I hadn't considered. If the purpose of %A is
> > >> a 100% accurate representation of the whole number, then those 7 digits
> > >> shown by msvcrt.dll are not enough, and it is wrong.
> > >
> > > MSVCRT.DLL is a system library you're not supposed to use.
> >
> > And yet, nearly every other program uses it. Including gcc.exe of mingw:
> Yes; by doing that, they are perpetrating a poor practice.
>
> It's a good reason to stay away from the MinGW project.
> --
> TXR Programming Language: http://nongnu.org/txr
> Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
> Mastodon: @Kazi...@mstdn.ca

Mingw64 provides ucrt64 build environment.
I tried it few minutes ago, it appears to work fine.
So, one can chose perpetrating a poor practice with MinGW, but one
does not have to. For those interested, MinGW provides supposedly better
alternative.

Personally, I use msys2/mingw64 for cross-development and for experimentation,
so I care very little about distribution of compiled binaries on Windows platform.
But may be now, after seeing that ucrt build environment works, I'd start to
use it for experimentation instead of "classic" MinGW64 since I see no downsides.

On 09/08/2023 05:23, Malcolm McLean wrote:
> On Tuesday, 8 August 2023 at 23:26:47 UTC+1, David Brown wrote:
>> On 08/08/2023 19:04, Malcolm McLean wrote:
>>> On Tuesday, 8 August 2023 at 17:46:15 UTC+1, David Brown wrote:
>>>> On 08/08/2023 18:04, Malcolm McLean wrote:
>>>>> On Tuesday, 8 August 2023 at 16:18:49 UTC+1, David Brown wrote:
>>>>>> On 05/08/2023 14:08, Malcolm McLean wrote:
>>>>>>
>>>>>>> This is the problem of course. The Baby X API expects data in a certain format.
>>>>>>> So all the API functions which operate on images take a 32 bit RGBA buffer
>>>>>>> as an "unsigned char *", and the dimensions as two ints. But another API might
>>>>>>> use an opaque "IMAGE" structure. Or another system might have 16 bit r5g5b5a1
>>>>>>> images.
>>>>>>
>>>>>> It would make a lot of sense to have a program that took data in common
>>>>>> standardised uncompressed forms (like .wav, .bmp) and generated data in
>>>>>> whatever format suits Baby X.
>>>>>>
>>>>> "Data" means, "that which is given". People programming applications are given
>>>>> resources in many formats. They might steal a PNG from the web, get a JPEG
>>>>> commissioned from a paid artist, knock up their own SVG.
>>>>> Now of course it's possible to convert all these into a common format like PNG
>>>>> which is powerful enough to hold all thse formats without loss. But you've lost
>>>>> the link with the original data. So when the artist comes back with a second
>>>>> version of the JPEG, you've got to run ImageMagick again. And I don't have
>>>>> ImageMagick installed on the Mac I'm writing this on (there's a program called
>>>>> sips which does similar things).
>>>>> A resouce pipeline with lots of stages, each one requiring a separate third party
>>>>> program, is quite fragile. It works for as long as your Linux machine is all set up
>>>>> with the dependencies, which will be the case for the duration of the project.
>>>>> But if you archive it, and dust it off years later, will things still be intact? And
>>>>> will you know which are the intermediate files, and which are the original data?
>>>> It looks like there is someone else in this group who could benefit from
>>>> understanding "make" and/or other build tools. And if you can't use a
>>>> Mac for development, scrap the expensive toy and install a usable
>>>> system. (Of course, you /can/ use a Mac for development - you just need
>>>> to know how to use your tools.)
>>>>
>>> Bart's right about make. If it actually worked properly we wouldn't need CMake.
>> "make" works perfectly well for its purpose. CMake is a different tool,
>> doing a different job. In fact, CMake generates makefiles for use by
>> "make" (as well as project files for MSVC, and other types of build
>> system). CMake is a higher level tool. ("make" can, in combination
>> with compilers like gcc, do a fair amount of higher level work as well,
>> such as tracking dependencies and files automatically.)
>>
> CMake is an alternative to make.

It is a "meta-build" tool, aimed at a higher level than make, and which
generates scripts or control files for various uses - makefiles, MSVC
project files, and others. For some kinds of project, that might be a
good choice - sometimes it makes sense to separate the tasks of
calculating dependencies and settings, and actually controlling the
build. But since on many platforms CMake depends on make, it is not an
alternative. And CMake is not flexible enough for many uses - when I
have looked at it, it was not remotely flexible enough to do the kinds
of things I do with make. Many people use CMake, so it must have
merits, but it is not a replacement for make.

> It can generate make files, in fact that's the
> default. Which means that if you ship a project with a CMake script, you
> wouldn't normally provide a make file. CMake found a niche largely because
> make files are too difficult to use. The other reason is that the big IDEs
> rejected makefiles as their format for describing how to build projects.

Every IDE of any quality can handle projects that are built using
external makefiles. An IDE that won't run "make" at the press of a
hotkey is as useful as an IDE that can't handle ASCII format test files.

But if you have an external manually written makefile, that is not
project management - so usually you also then have to make an IDE
project to describe the source files, include search paths, pre-defined
macros, etc. That can be a duplicate of work (though good makefiles
find the source files and dependencies mostly automatically), and
duplication can lead to mistakes.

The norm AFIK for build systems controlled by IDEs is make - they
generate makefiles automatically based on your project settings, dialog
boxes for choosing compiler flags, etc. Such systems can work
reasonably well, though a well-made manual makefile is often much better
at calculating dependency information for large projects.

Some IDEs may generate CMake files, then run CMake, then make - I have
(unsurprisingly) not used all IDEs.

CMake, as far as I understand it, is popular when you want a project to
build on Linux with gcc and Windows with MSVC - that is its niche.

>>
>> One thing that "make" is particularly good at is chains of processes.
>> It is straightforward to say that "picture.o" is compiled from
>> "picture.c" which is resource-compiled from "picture.bmp" which is
>> converted from "picture.jpg". I sometimes have that kind of thing in
>> makefiles for building documentation, where the graphics files I want to
>> add to my LaTeX documents might need conversions or manipulations from
>> the originals.
>>
>>> But it's unmaintainable.
>>
>> Not for people who are familiar with it.
>>
> Many programmers might start a new project only once every two years. And
> it might not be their job to write the makefile. So they are not going to be very
> familiar with make. Maintainable software needs to be maintainable by people
> who don't have a deep familarity with it. I can debug Cmake scripts despite
> not really knowing the CMake language, because it's close enough to a normal
> procedural programming language for someone who can program but doesn't
> know CMake specifically to follow along.

People need to know how to use their tools. Within any development
group, you need people who can handle the different parts of the
development process. Sometimes people can do it all, sometimes there
are specialists in the group. So someone might be an expert at git,
someone at make, different programmers can handle different languages,
and others are good at design, documentation, testing, and all the other
aspects of software development. Anyone who thinks that "understands C"
is the be-all and end-all of making and maintaining a software project
in C is doomed to failure.

So if you are part of a development team, and your team is rejecting
"make" on the basis of "it's too hard to understand", your development
team is in a /lot/ of trouble. New management - or at least training
for the management - should be number one priority until the job is run
by people that understand about using the best tools for the job, and
training people in the jobs that need done. (Of course, if CMake really
is a better choice for your project, that's fine - make is not the only
tool in the box.)

>>
>> Certainly complicated makefiles are harder to deal with than simple
>> ones. It's a powerful tool with many features, and takes time and
>> effort to learn. But complicated ones can reduce maintenance - my
>> makefiles do not need modification as files are added or removed from a
>> project, or dependencies on headers change - it is all handled
>> automatically.
>>
>>> Baby X is mainly for small hobby type programs. It's easier to use than
>>> the raw X11 interface, and it's far lighter weight than Qt or GTK. It also
>>> ports to Windows. So most of the users will be bedroom programmers
>>> who will set up the internationalisation strings themselves, rather than
>>> employing professional translators.
>> That is a hopeless attitude to take. You are simply guaranteeing that
>> people will not use it for internationalisation - or that they will hate
>> the tool when they try to use it. Targeting hobby users is not an
>> excuse for bad design. I would suggest you remove all traces of
>> internationalisation until you have found a way to make it work. (And
>> drop the XML format while you are at it - a simple one line, one command
>> text format would be vastly easier for everyone.)
>>
> It works.

On Wednesday, August 9, 2023 at 4:59:01 AM UTC+3, Richard Damon wrote:
> On 8/8/23 10:16 AM, Bart wrote:
> > On 08/08/2023 13:22, Richard Damon wrote:
> > > On 8/8/23 7:05 AM, Bart wrote:
> > >> On 08/08/2023 03:21, Richard Damon wrote:
> > >> > On 8/7/23 8:28 PM, Bart wrote:
> > >> >> My view is that C's print-format system is not fit for purpose. The
> > >> >> formatting is OK, it is needing to specify types that is the
> > problem.
> > >> >
> > >> > which is EXACTLY the arguement that got us the C++ stream <<
> > operator.
> > >> That feature is so bad it makes using printf preferable! Is it really
> > >> that hard to just be able to write 'print x' ?
> > >>
> > >> > If you want to do that in C, you can, just define a generic "print"
> > >> > function that defines version for each fundamental type, and call
> > >> that.
> > >> >
> > >> > You don't seem to understand that C is based on the assumption that
> > >> the
> > >> > programmer actually knows what he is doing, not hiding behind a
> > >> mass of
> > >> > abstractions.
> > >>
> > >> You don't get my point. The programmer might not know for sure the
> > >> type of a complex expression, and certainly does not want to keep
> > >> updating dozens of printf formats across the codebase as global
> > >> declarations change.
> > >
> > > Then they are using the wrong tool.
> >
> > What tool did you have in mind? Do you mean that an IDE will tell you
> > the types of the expressions, or write the format codes for you?
>
> IF you actually want to output expressions that you don't know the type,
> you need something that supports that. Maybe C++, maybe Python, maybe
> something else like that.
>
> It seems you have one tool in your box, so everything is a nail.
>
> >
> > That strikes me as the same argument that you can use CDECL to get round
> > abstruse C type specs. If the tool can do it, why doesn't the compiler?
> > Or the language.
>
> Except the issue you are describing isn't handled by CDECL. That
> generally needs the fully expressed type, and you complaint seems to be
> a type that has been hidden via typedefs and the like.
>
> So CDECL doesn't do what you want.
>
> >
> > > C is designed to be used when you know, at least in general, what you
> > > are working with.
> > >
> > >>
> > >> Right now I don't know how to print a clock() result for example, and
> > >> to keep inventing special formats like %zu is crass.
> > >>
> > >> *I* can just write:
> > >>
> > >> println a, b, c
> > >
> > > So, why don't you?
> >
> > I do. It's lovely. The question is, why are a million users of C denied
> > that?
>
> Because that isn't C. If you want basic, you know where to find it.
>
> Note, "println" like that can't do a lot of things that printf can do
> when properly used, so it becomes the problem of just using the right tool.
>
> >
> > > is the problem that you don't know how to translate that into C?
> > >
> > >>
> > >> So can a dozen other languages (even from the 1960s!). I can change
> > >> the types of a, b, c, and it still works. I can print c, b, a and it
> > >> still works.
> > >>
> > >> I can even just do 'print clock()'!
> > >>
> > >> In C YOU CAN'T DO THAT. You need to dig up the types of each
> > >> expression and apply the right format. In this VERY simple case, it
> > >> MIGHT be:
> > >
> > > Because C is a lower level, and targeted to be more efficiet, than those
> > > other languages.
> >
> > Sorry, but that is rubbish. My 'M' language is also low level, but
> > somehow manages to have a proper print. And it's not dead slow either:
>
> And I bet it only runs on x86 processors?
>
>
> >
> > A loop which prints the numbers up to 10 million (redirected to a file
> > to remove display overheads), takes 1.8 seconds in my language, and 3.2
> > seconds using gcc 13.2 -O3. bcc/tcc take 2.4 seconds.
> >
> > (My library is faster, despite the int->text code being unoptimised,
> > because of buffering. But then maybe gcc's printf is also buffered
> > internally. Which one is cheating more? I know mine won in this case!)
>
> Maybe you used the wrong C library to do that.
>

Then what would you suggest for right library ?
I tested four very popular options - old MS DLL, modern MS DLL, modern
MS static lib (on x86-64 Windows) and modern glibc .so (on x86-64 Linux).
They all were slow, 2-3 times slower than simple unoptimised C code posted
below. MS static lib the least bad of the slow lot.

int int_to_str(char* dst, int ix)
{ if (ix == 0) {
dst[0] = '0';
dst[1] = 0;
return 1;
}

char* beg = dst;
unsigned ux = ix;
if (ix < 0) {
*dst++ = '-';
ux = -ix;
}
char* tsd = dst;
do {
unsigned nxt = ux / 10;
*tsd++ = (char)(ux - nxt*10 + '0');
ux = nxt;
} while (ux != 0);
*tsd = 0;
int ret = (int)(tsd - beg);

--tsd;
while (tsd > dst) {
char a = *dst;
char b = *tsd;
*tsd = a;
*dst = b;
--tsd;
++dst;
}

return ret;
}

And my estimate is that with sufficient effort this unoptimized code can
be improved at least by another factor of 3, but quite possible even 5.

> Also, since you have shown that you format routines don't meet the full
> functionality of C's, that will give it an advantage.
>

Yes, I think it is a big part of the problem. printf interface is very flexible
which turns even good implementations into non-competitive with what
can be easily achieved with simpler API as one of Bart's.
Alternatives with simpler interfaces, e.g. itoa() exist, but not in Standard.

> >
> >
> > >>
> > >> printf("%lld " PRId64 " %s", a, b, c);
> > >>
> > >> But now you have an extra maintenance headache.
> > >>
> > >> (In all cases, printing gets untidy when you need to do necessary
> > >> formatting, but only C incorporates types into the formatting.)
> > >>
> > >>
> > >> >> It gets tricky when using sprintf say from another language,
> > which is
> > >> >> then transpiled to actual C.
> > >> >
> > >> > And why doesn't that other language implement a better print
> > >> > functionality itself?
> > >>
> > >> It does, but ultimately it needs to do I/O, and I've been using C's
> > >> printf for that since the mid-90s, because it was simpler than using
> > >> WinAPI. I've since forgotten how do it with WinAPI.
> > >
> > > So, your problem is that you aren't willing to do the work yourself.
> >
> > What problem is this? I've been implementing 'proper' PRINT in languages
> > since as far back as 1981.
>
> Then why are you complaining that the C printf doesn't meet your
> requireents?
>
> >
> > At some point, nearly 20 years later, I switched from OS to C functions
> > for low-level I/O, for consoles or files. For Printing to printers,
> > images, windows and strings, I still handled that.
>
> So?
>
> You added a layer of abstraction, so maybe you programs can run on more
> targets.
>
> >
> > > So again, the problem is you are using the wrong tool or your language
> > > is incomplete.
> >
> > The problem is that you don't have a clue what the problem is.
>
> No, I fully understand it.
>
> >
> > There is no tool, and no feature in my language (other than turning it
> > into C), that will fix the problem that C's 'char*' is so unique.
>
> Why is C's char* being unique a problem?
>
> It still sounds like the problem is you don't understand what C is
> doing, so you are misusing it.
>
> >
> > Usually you can ignore that if using C's library purely via a binary
> > interface, but if generating C code, you will see issues. The solutions
> > are ugly and ungainly.
>
> But "intermediary" output is almost always "ugly", that is part of the
> nature of machine generated code. If you "compilation" is any good, no
> one needs to look at it.
>
> >
> > Try it and see!
> >
> > > But to use C as a portable assembler, you need to use it as an
> > > assembler, and that means understanding the nature of the "assembly
> > > language".
> >
> > An assembly language which has a million more rules, special cases and
> > UBs than any real assembler!
>
> Your thinking about the wrong machine. Remember, in C, the machine you
> need to be thinking about is the "abstract machine" defined by the standard.
>
> >
> > In x64 assembly, I can write a floating point value to a 64-bit memory
> > location, and read it back as an integer, with no issues:
> >
> > movq [fred], xmm0
> > mov rax, [fred]
> >
> > C makes that undefined - maybe.
>
> So?
>
> >
> > > IF you are concerned about efficient outputing of valuse, you build a
> > > family of generic "print" functions that use the right version for the
> > > type given, and let the complier figure it out. Just means you can't put
> > > everything in one statement. (but this is intermediary code, so doesn't
> > > really need to be totally readable).
> >
> > This is exactly what I do behind the scenes of my language. And another
> > reason why I sometimes use 'printf', since it produces long sequences of
> > function calls which obscure minimal test code.
> >
> > The advantage of printf also is that it is outside my language, so its
> > implementation code doesn't intrude.
> >
>
> And if the doesn't meet your requirements, don't use it.
>
> One big aspect of printf, is you need to know the "type" of each
> arguement you give it. If you do, it works well, if you don't you just
> can't use it.
>
> You seem to think this is a bug instead of its design decision.
>
> Try to explain how you would change C so that printf could be more
> forgiving on the type given to it without totally changing how the
> language works.
>
> Remember, "printf" isn't something special in the language, and you can
> write your own equivalent function, which would need to be able to work
> just the same.

On 09/08/2023 01:24, Keith Thompson wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> [...]
>> You can't really support Unicode but not support internationalisation,
>> however.
> [...]
>
> An application could show all its application-defined messages in
> English, but still handle and display arbitrary text in any language.
> A word processor that uses English for all its messages and commands
> can still be used to write a novel in French.
>

And some words in English need non-ASCII characters to be spelt
correctly, such as naïve or café. People's names might have non-ASCII
characters - how is Mr. π·r² going to write his name in an application
that does not support Unicode?

And a Mongolian only application would want Unicode, but would not
support internationalisation.

Yes, Unicode is useful without internationalisation of an application.