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

>>
>>> Of course I could put in a flexible format specifier. But it would rapidly turn into
>>> a scripting laugage in its onw right. In which case you might as well use Python.
>>
>> Indeed. You program already looks like that.
>>
> No it doesn't. There's a very simple xml list of resources, and one or two attributes
> to control the output. It's nothing like a script. However to be fair I do suggest diving
> into the source if you want to customise it. The users will be C programmers, after
> all.
>>>
>>> There is an "international" tag so you can do this
>>> <international name = "hello">
>>> <string language = "english">Hello</string>
>>> <string language = "french">Bonjour</string>
>>> <utf8 language = "chinese"> [utf8 here] </utf8>
>>> </international>
>>>
>>> Then it creates a C-callable function which is passed the languafe and returns
>>> thr right string.
>>>
>>
>> That's a horrendous interface for everyone involved. It is hideous for
>> the programmer writing the XML (like all XML is). It is terrible for
>> the translators, who want to work with strings in the common language
>> (usually English) and their own language. It is horrible to use in the
>> application code. It would be a mess to maintain in source code
>> repositories.
>>
>> Seriously, I'm not sure how you could make it worse. Perhaps you could
>> insist that the translation strings are all held in a MS Excel format
>> spreadsheet?
>>
>> Did you even think about how people were supposed to use it, or how
>> international programs are developed?
>>
> You might be right about that. We considered internationalisation at
> work (we make tools for artists), but the customers said they were
> happy with English, and it was such a bag of worms that we rejected
> the idea. So I've no experience. Part of the reason for discussing it here
> is that other people might have such experience.

Just think about it a little. You know a language or two other than
English - put yourself in the position of a translator who does not
understand C and is not a programmer. Would you want to face that XML crap?

> You can't really support Unicode but not support internationalisation,
> however.

Of course you can. It is only the opposite that will cause you
difficulties.

On Tuesday, 8 August 2023 at 17:38:59 UTC+1, David Brown wrote:
>
> Windows is a huge mess, unsuitable for serious development work. That's
> why so many people (including lots at Microsoft) prefer *nix systems for
> development.
>
There are two of us at work doing essentially the same job. My colleague does
all his work on Windows, whilst I use the Mac. The main reason I use the Mac is
that my machine is an Apple-manufactured computer and Windows is a dual
boot. Every so often Windows takes it into its head that the keyboard is American,
and all the special symbols you need for programming switch keys. It's
irritating.
But he swears that the Visual Studio IDE is better than Xcode.

Our customers are about 50:50 split between Mac and Windows.

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.
But it's unmaintainable. We produce graphical tools, so we have plenty of
resources that need to be embedded in the programs.. But we don't have a
pipeline set up with make dependencies. You could fiddle with such a system until
it worked. But it would fall over at the slightest stress.
> >>
> >>> Of course I could put in a flexible format specifier. But it would rapidly turn into
> >>> a scripting laugage in its onw right. In which case you might as well use Python.
> >>
> >> Indeed. You program already looks like that.
> >>
> > No it doesn't. There's a very simple xml list of resources, and one or two attributes
> > to control the output. It's nothing like a script. However to be fair I do suggest diving
> > into the source if you want to customise it. The users will be C programmers, after
> > all.
> >>>
> >>> There is an "international" tag so you can do this
> >>> <international name = "hello">
> >>> <string language = "english">Hello</string>
> >>> <string language = "french">Bonjour</string>
> >>> <utf8 language = "chinese"> [utf8 here] </utf8>
> >>> </international>
> >>>
> >>> Then it creates a C-callable function which is passed the languafe and returns
> >>> thr right string.
> >>>
> >>
> >> That's a horrendous interface for everyone involved. It is hideous for
> >> the programmer writing the XML (like all XML is). It is terrible for
> >> the translators, who want to work with strings in the common language
> >> (usually English) and their own language. It is horrible to use in the
> >> application code. It would be a mess to maintain in source code
> >> repositories.
> >>
> >> Seriously, I'm not sure how you could make it worse. Perhaps you could
> >> insist that the translation strings are all held in a MS Excel format
> >> spreadsheet?
> >>
> >> Did you even think about how people were supposed to use it, or how
> >> international programs are developed?
> >>
> > You might be right about that. We considered internationalisation at
> > work (we make tools for artists), but the customers said they were
> > happy with English, and it was such a bag of worms that we rejected
> > the idea. So I've no experience. Part of the reason for discussing it here
> > is that other people might have such experience.
> Just think about it a little. You know a language or two other than
> English - put yourself in the position of a translator who does not
> understand C and is not a programmer. Would you want to face that XML crap?
> > You can't really support Unicode but not support internationalisation,
> > however.
> Of course you can. It is only the opposite that will cause you
> difficulties.
>
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.
As I said, if as a side effect the Baby X resource compiler is useful to
non-Baby X porgrammers, then that's great. But the focus is on having
a good tool which will help unleash the potential of Baby X.

But for version 1.3 I could well shift focus to meeting the needs of non-
Baby X programmers. I know that more people download the resource
compiler than download Baby X, which suggest that there is a need there.

And whilst there are competitors to Baby X, there isn't a close competitor
to the resource compiler which I have seen.

On Tuesday, August 8, 2023 at 7:38:59 PM UTC+3, David Brown wrote:
> On 08/08/2023 17:09, Bart wrote:
> > On 08/08/2023 15:27, David Brown wrote:
>
>
> >
> > > But if you don't like make, try one of the dozens of alternatives. Or
> > > write a batch file. Or make your own build program - it's not hard, at
> > > least for a simple arrangement.
> >
> > You're misunderstanding something - I don't need nor want 'make'. It's
> > is just an obstacle to building any software that others use without
> > thinking.
> /You/ are misunderstanding something. If you need to do something, and
> there are tools easily available that let you do it, but you refuse to
> use those tools, then you can't expect any sympathy from others.
>
> gcc is a compiler (or a driver program, or a collection of compilers,
> depending on what part of it you are talking about). It was not built
> to spoon-feed lazy or ignorant developers. And it does not contain a
> build tool.
> >
> > > Don't forget that compilers are also usually intended for developers.
> >
> > But you must agree that the needs of an end-user are different? And
> > simpler. No real need to do tons of testing or analysis: that has
> > already been done.
> >
> Yes, I agree.
> > So a streamlined build process and a streamlined compiler will work
> > better with fewer failure points.
> >
> Yes. So use a build tool.
> >
> > I have tried to build CPython on Windows. But it doesn't use gcc in that
> > case, it used MSVC.
> >
> > The process involved first updating .NET, then downloading VS 2017 (a
> > 90-minute install), then GIT, then SVN, then MS Build Tools, and then it
> > failed on something else, by which time, several hours and 10GB of
> > downloads later, I gave up.
> >
> > Over-complex build systems GO WRONG.
> >
> CPython is a huge project, unsuitable for amateurs to build. That's why
> almost nobody builds it themselves.
>
> Windows is a huge mess, unsuitable for serious development work. That's
> why so many people (including lots at Microsoft) prefer *nix systems for
> development.
>
> You are combining a massive project with a shitty OS and a totally
> incompetent developer, and expecting things to go smoothly. It's hardly
> a fair test.
> > The first obstacle in using 'make' with gcc 10.3.0 is, there IS no
> > make.exe! (There is mingw32-make.exe which you have to rename or copy.)
> gcc never has, and never will, ship with any version of "make".
>
> You might have acquired them together from some third-party packaging
> system. If you don't like the way that packaging was done, take it up
> with them. Maybe ask for a refund.
> >
> > 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?)
> >
> gcc never has, and never will, ship with any version of "make".
>
> Look, you /know/ this stuff. You've been told countless times. This is
> why people call you a troll - you can't be /that/ stupid.
> > The next one is, how does 'make' know what C compiler I want to use? At
> > one point I had half a dozen.
> Clearly these "computah" things are a bit advanced for you. May I
> recommend an iPad? Or a TV? Because now I am sure you are trolling.

In context of your own remark of few posts above: "(remember, gcc originates
in a world where people can happily write "make prog" to get the same effect
- saving a keystroke!)" I find Bart's question perfectly legitimate.

On 08/08/2023 16:55, Michael S wrote:
> On Tuesday, August 8, 2023 at 2:05:48 PM UTC+3, Bart wrote:

>> *I* can just write:
>>
>> println a, b, 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.
>
> What does it do?
> I'd guess, it prints a, b and c, each in default format corresponding
to respective
> types, each on the separate line?
> In theory it's nice to have something like that in the language. But
in practice I very
> rarely need thing printed like that, one per line and in default
format. One number
> instead of three would be a little more common, by just a little.

'Print' is one of the most variable features across languages.

What is common however is that there is no more than one newline per
print invocation. And where it ends in 'ln', typically there is a verson
without 'ln' that does not add the newline.

So what's left is whether each item is separated from others /in that
item list/ by a space. In mine it is, otherwise it wouldn't give a
useful output when a, b, c are numbers, as they would run into each other.

Getting rid of the space requires knowing how, but if stuck, doing
'print a; print b; print c' will do it.

The most common use of print in my programs is for debugging. Which
means large numbers get created, live for short periods then are removed.

You can imagine that in C that involves a lot of typing; paying heed to
the exact types is an extra burden.

The equivalent of:

print =i, =a[i], =p

in C would be /something like/ this as it depends on the types involved:

printf("I=%lld A[I]=%s, P=%p\n", i, a[i], p);

>> I can even just do 'print clock()'!
>
> Now you hit a real point.
> But on the second thought I realize that

I can call C's clock() from my languages. There, it needs to be declared
via the FFI with a concrete return type. On my platform, that appears to
be (pause while I go and look) a 32-bit signed int.

(That in turn was obtained from C headers for my platform, where clock_t
is defined as 'long', which on Windows is a 32-bit int; phew! And that
was a simple case; I have seen clock_t defined on top of SIX layers of
typedefs and macros.)

The end result is that I can just do 'print clock()'. The C user still
has that headache. In practice you might try casting the value to 64
bits or to floating point.

> I don't know what default format I'd want in this case.

What do you mean by format? You can't choose the type; it is what it is.
If you mean whether it is decimal or hex, or the width and so on, that
that is different matter

My objection is that the type is opaque, but you know to know it to
determine whether the format is based around d, u, or f, and how many
l's if any are needed.

FWIW, for a hex value in a field of 10 characters, centre-justified and
padded with *, I would write 'print clock():"h 10 jc p*"'. But this is a
different language feature.

Michael S <already5chosen@yahoo.com> writes:
>On Tuesday, August 8, 2023 at 7:38:59=E2=80=AFPM UTC+3, David Brown wrote:
>> On 08/08/2023 17:09, Bart wrote:=20
>> > On 08/08/2023 15:27, David Brown wrote:=20
>>=20
>>=20
>> >=20
>> > > But if you don't like make, try one of the dozens of alternatives. O=
>r=20
>> > > write a batch file. Or make your own build program - it's not hard, =
>at=20
>> > > least for a simple arrangement.=20
>> >=20
>> > You're misunderstanding something - I don't need nor want 'make'. It's=
>=20
>> > is just an obstacle to building any software that others use without=20
>> > thinking.
>> /You/ are misunderstanding something. If you need to do something, and=20
>> there are tools easily available that let you do it, but you refuse to=20
>> use those tools, then you can't expect any sympathy from others.=20
>>=20
>> gcc is a compiler (or a driver program, or a collection of compilers,=20
>> depending on what part of it you are talking about). It was not built=20
>> to spoon-feed lazy or ignorant developers. And it does not contain a=20
>> build tool.
>> >=20
>> > > Don't forget that compilers are also usually intended for developers.=
>=20
>> >=20
>> > But you must agree that the needs of an end-user are different? And=20
>> > simpler. No real need to do tons of testing or analysis: that has=20
>> > already been done.=20
>> >
>> Yes, I agree.
>> > So a streamlined build process and a streamlined compiler will work=20
>> > better with fewer failure points.=20
>> >
>> Yes. So use a build tool.
>> >=20
>> > I have tried to build CPython on Windows. But it doesn't use gcc in tha=
>t=20
>> > case, it used MSVC.=20
>> >=20
>> > The process involved first updating .NET, then downloading VS 2017 (a=
>=20
>> > 90-minute install), then GIT, then SVN, then MS Build Tools, and then i=
>t=20
>> > failed on something else, by which time, several hours and 10GB of=20
>> > downloads later, I gave up.=20
>> >=20
>> > Over-complex build systems GO WRONG.=20
>> >
>> CPython is a huge project, unsuitable for amateurs to build. That's why=
>=20
>> almost nobody builds it themselves.=20
>>=20
>> Windows is a huge mess, unsuitable for serious development work. That's=
>=20
>> why so many people (including lots at Microsoft) prefer *nix systems for=
>=20
>> development.=20
>>=20
>> You are combining a massive project with a shitty OS and a totally=20
>> incompetent developer, and expecting things to go smoothly. It's hardly=
>=20
>> a fair test.
>> > The first obstacle in using 'make' with gcc 10.3.0 is, there IS no=20
>> > make.exe! (There is mingw32-make.exe which you have to rename or copy.)
>> gcc never has, and never will, ship with any version of "make".=20
>>=20
>> You might have acquired them together from some third-party packaging=20
>> system. If you don't like the way that packaging was done, take it up=20
>> with them. Maybe ask for a refund.
>> >=20
>> > gcc 13.2 comes with make.exe, so they learnt something! (I wonder at=20
>> > what point they decided that actually providing 'make.exe' was a good=
>=20
>> > idea?)=20
>> >
>> gcc never has, and never will, ship with any version of "make".=20
>>=20
>> Look, you /know/ this stuff. You've been told countless times. This is=20
>> why people call you a troll - you can't be /that/ stupid.
>> > The next one is, how does 'make' know what C compiler I want to use? At=
>=20
>> > one point I had half a dozen.
>> Clearly these "computah" things are a bit advanced for you. May I=20
>> recommend an iPad? Or a TV? Because now I am sure you are trolling.
>
>In context of your own remark of few posts above: "(remember, gcc originate=
>s
> in a world where people can happily write "make prog" to get the same effe=
>ct
> - saving a keystroke!)" I find Bart's question perfectly legitimate.
>

The short answer, RTFM.

A slightly longer answer, make _doesn't_ know what C compiler you
want to use. You tell it which C compiler you want to use. Some
make installations include a set of default rules. These default
rules issue shell commands using the standard 'cc' or 'c++' names,
however the user can easily override them either by:

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

2) Setting the shell PATH variable to select the desired version of 'cc' or 'c++'
before invoking make.

PATH=/nfs/compilers/x86_64/gcc/11.3.0/bin:$PATH make

On 08/08/2023 17:15, Michael S wrote:
> On Tuesday, August 8, 2023 at 5:16:14 PM UTC+3, Bart wrote:

>> 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:
>>
>> 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!)
>
> Sounds like gcc under mingw64/msys64.
> It uses old Microsoft's DLLs (from Visulat Studio 2013 or something like that)
> for C RTL. For many tasks it's o.k. but for few others slow or problematic
> in a different ways.
> So, you can't blame 'C' or gcc for this particular slowness.
> You can't even blame Microsoft, because C RTL supplied with their less
> ancient compilers prints integers much faster.
> And you can't blame mingw64 maintainers because they are mostly
> volunteering.

I tried the same program under WSL. That was a very fast terminal
update, but I'm redirecting the output to a file.

That got down after a few runs to 2.8 seconds. (Or 2.84 real + 0.7 user;
on Windows elapsed time was 3.2 seconds.)

The point is that Richard Damon was blaming the crudeness of printf on C
being a lower level language; that has nothing to do with it. A large
part is binary to text conversion that needs doing in any language, and
the same for sending that text to the output.

You can have a lower-level language, and have a Print X feature where
the compiler knows the type of X.

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.

On Tuesday, August 8, 2023 at 8:32:21 PM UTC+3, Scott Lurndal wrote:
> Michael S <already...@yahoo.com> writes:
> >On Tuesday, August 8, 2023 at 7:38:59=E2=80=AFPM UTC+3, David Brown wrote:
> >> On 08/08/2023 17:09, Bart wrote:=20
> >> > On 08/08/2023 15:27, David Brown wrote:=20
> >>=20
> >>=20
> >> >=20
> >> > > But if you don't like make, try one of the dozens of alternatives. O=
> >r=20
> >> > > write a batch file. Or make your own build program - it's not hard, =
> >at=20
> >> > > least for a simple arrangement.=20
> >> >=20
> >> > You're misunderstanding something - I don't need nor want 'make'. It's=
> >=20
> >> > is just an obstacle to building any software that others use without=20
> >> > thinking.
> >> /You/ are misunderstanding something. If you need to do something, and=20
> >> there are tools easily available that let you do it, but you refuse to=20
> >> use those tools, then you can't expect any sympathy from others.=20
> >>=20
> >> gcc is a compiler (or a driver program, or a collection of compilers,=20
> >> depending on what part of it you are talking about). It was not built=20
> >> to spoon-feed lazy or ignorant developers. And it does not contain a=20
> >> build tool.
> >> >=20
> >> > > Don't forget that compilers are also usually intended for developers.=
> >=20
> >> >=20
> >> > But you must agree that the needs of an end-user are different? And=20
> >> > simpler. No real need to do tons of testing or analysis: that has=20
> >> > already been done.=20
> >> >
> >> Yes, I agree.
> >> > So a streamlined build process and a streamlined compiler will work=20
> >> > better with fewer failure points.=20
> >> >
> >> Yes. So use a build tool.
> >> >=20
> >> > I have tried to build CPython on Windows. But it doesn't use gcc in tha=
> >t=20
> >> > case, it used MSVC.=20
> >> >=20
> >> > The process involved first updating .NET, then downloading VS 2017 (a=
> >=20
> >> > 90-minute install), then GIT, then SVN, then MS Build Tools, and then i=
> >t=20
> >> > failed on something else, by which time, several hours and 10GB of=20
> >> > downloads later, I gave up.=20
> >> >=20
> >> > Over-complex build systems GO WRONG.=20
> >> >
> >> CPython is a huge project, unsuitable for amateurs to build. That's why=
> >=20
> >> almost nobody builds it themselves.=20
> >>=20
> >> Windows is a huge mess, unsuitable for serious development work. That's=
> >=20
> >> why so many people (including lots at Microsoft) prefer *nix systems for=
> >=20
> >> development.=20
> >>=20
> >> You are combining a massive project with a shitty OS and a totally=20
> >> incompetent developer, and expecting things to go smoothly. It's hardly=
> >=20
> >> a fair test.
> >> > The first obstacle in using 'make' with gcc 10.3.0 is, there IS no=20
> >> > make.exe! (There is mingw32-make.exe which you have to rename or copy.)
> >> gcc never has, and never will, ship with any version of "make".=20
> >>=20
> >> You might have acquired them together from some third-party packaging=20
> >> system. If you don't like the way that packaging was done, take it up=20
> >> with them. Maybe ask for a refund.
> >> >=20
> >> > gcc 13.2 comes with make.exe, so they learnt something! (I wonder at=20
> >> > what point they decided that actually providing 'make.exe' was a good=
> >=20
> >> > idea?)=20
> >> >
> >> gcc never has, and never will, ship with any version of "make".=20
> >>=20
> >> Look, you /know/ this stuff. You've been told countless times. This is=20
> >> why people call you a troll - you can't be /that/ stupid.
> >> > The next one is, how does 'make' know what C compiler I want to use? At=
> >=20
> >> > one point I had half a dozen.
> >> Clearly these "computah" things are a bit advanced for you. May I=20
> >> recommend an iPad? Or a TV? Because now I am sure you are trolling.
> >
> >In context of your own remark of few posts above: "(remember, gcc originate=
> >s
> > in a world where people can happily write "make prog" to get the same effe> >ct
> > - saving a keystroke!)" I find Bart's question perfectly legitimate.
> >
> The short answer, RTFM.
>

I sort of remember your 1st answer from RTFM that I did 30+ years ago.
But that was 30+ years ago and even then people that read manuals were
in minority.

> A slightly longer answer, make _doesn't_ know what C compiler you
> want to use. You tell it which C compiler you want to use. Some
> make installations include a set of default rules. These default
> rules issue shell commands using the standard 'cc' or 'c++' names,
> however the user can easily override them either by:
>
> 1) Using a make variable in the rule for '.c' -> '.o' and setting the
> variable to the name of the compiler:
>
> CC=bcc
> ...

It does not work on msys2 bash shell. However 'export CC=bcc' does work.
I didn't try it on Linux yet.

> %.o: %.c
> @$(QUIET) || echo " COMPILE $<"
> $(HUSHCOMPILE)$(CC) $(CFLAGS) -MMD -MP -o $@ -c $<
>
> 2) Setting the shell PATH variable to select the desired version of 'cc' or 'c++'
> before invoking make.
>
> PATH=/nfs/compilers/x86_64/gcc/11.3.0/bin:$PATH make

Touching PATH sounds like too big a hammer that could too easily
break something else.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>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.
>But it's unmaintainable.

To you, perhaps. Probably because you don't understand it.

The linux kernel is but one large application that uses make, and it
works well, and is quite maintainable. Far more so that CMake which
still suffers from portability issues (i.e. it's not always available).

> We produce graphical tools, so we have plenty of
>resources that need to be embedded in the programs.. But we don't have a
>pipeline set up with make dependencies. You could fiddle with such a system until
>it worked. But it would fall over at the slightest stress.

That's not been my experience with make (several operating systems, hypervisors,
SoC simulators, large internal webservers, certification authority production certificate
generation systems (Verisign) et. alia.). Properly designed makefiles are a joy
to work with.

On 08/08/2023 17:38, David Brown wrote:
> On 08/08/2023 17:09, Bart wrote:
> CPython is a huge project, unsuitable for amateurs to build. That's why
> almost nobody builds it themselves.

I was following a suggestion on comp.lang.python that it was a piece of
cake to build. They were wrong.

> Windows is a huge mess, unsuitable for serious development work. That's
> why so many people (including lots at Microsoft) prefer *nix systems for
> development.

That is more likely because so many upcoming people who have used it in
academia can't manage outside of Linux. Then learn. (That's why you keep
saying.)

> You are combining a massive project

When I did this (2012?), CPython was a few 100Kloc of C code (I can't
remember exactly), hardly that massive.

> with a shitty OS and a totally
> incompetent developer, and expecting things to go smoothly. It's hardly
> a fair test.

Why do you think the Windows build process didn't use gcc?

> gcc never has, and never will, ship with any version of "make".

Then I'm puzzled. You advocate using 'make' to build everything.

Now you are keen to point out that gcc doesn't come with 'make' and
shouldn't.

So where the hell does it come from, then? And why do programs designed
to build on Windows depend on a tool that doesn't exist?

And why do you insist on my using a build tool I don't have? One which
never seems to be feature in the list of prerequisites for building any
project.

> Look, you /know/ this stuff. You've been told countless times. This is
> why people call you a troll - you can't be /that/ stupid.

>> The next one is, how does 'make' know what C compiler I want to use?
>> At one point I had half a dozen.
>
> Clearly these "computah" things are a bit advanced for you. May I
> recommend an iPad? Or a TV? Because now I am sure you are trolling.
>

You really can't see beyond 'make' can you, or that anybody can possibly
do without it.

I've been coding without using make for many decades, a lot of that
professionally and /successfully/.

I've also been devising languages with fast development turnarounds that
do not rely on such tools.

My C compiler doesn't need make, where it wouldn't work anyway, since it
doesn't generate object files. And actually, it has mini-build system of
its own, built-in.

SO WHY ARE YOU INSISTING ON FORCING MAKE (AND IT SOUNDS LIKE LINUX TOO)
DOWN PEOPLE'S THROATS AND REFUSING TO ADMIT ANY OTHER POSSIBILITIES?

Even more bizarre considering your statement that I oughtn't by rights
have make on my machine anyway.

And then you call people computer illiterate and incompetent for
prefering different tools from you.

Maybe you're the troll after all.

Fucking cheek.

On 08/08/2023 17:46, David Brown wrote:
> On 08/08/2023 18:04, Malcolm McLean wrote:

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

This project should be applauded for having one of the simplest sets of
build instructions for this size of project.

Five stars for using/needing 'make'.

On 08/08/2023 17:47, Malcolm McLean wrote:
> On Tuesday, 8 August 2023 at 17:38:59 UTC+1, David Brown wrote:
>>
>> Windows is a huge mess, unsuitable for serious development work. That's
>> why so many people (including lots at Microsoft) prefer *nix systems for
>> development.
>>
> There are two of us at work doing essentially the same job. My colleague does
> all his work on Windows, whilst I use the Mac. The main reason I use the Mac is
> that my machine is an Apple-manufactured computer and Windows is a dual
> boot. Every so often Windows takes it into its head that the keyboard is American,
> and all the special symbols you need for programming switch keys. It's
> irritating.
>
> But he swears that the Visual Studio IDE is better than Xcode.
>
> Our customers are about 50:50 split between Mac and Windows.

In the 1990s, my customers were split 999:1 between Windows and Mac.

(I didn't directly support Macs, but apparently its Windows emulator
worked well enough.)

Potential Linux clients (there was the odd one or two) were given short
shrift. It just wasn't worthwhile supporting.

Michael S <already5chosen@yahoo.com> writes:
>On Tuesday, August 8, 2023 at 8:32:21=E2=80=AFPM UTC+3, Scott Lurndal wrote=
>:
>> Michael S <already...@yahoo.com> writes:=20
>> >On Tuesday, August 8, 2023 at 7:38:59=3DE2=3D80=3DAFPM UTC+3, David Brow=
>n wrote:=20
>> >> On 08/08/2023 17:09, Bart wrote:=3D20=20
>> >> > On 08/08/2023 15:27, David Brown wrote:=3D20=20
>> >>=3D20=20
>> >>=3D20=20
>> >> >=3D20=20
>> >> > > But if you don't like make, try one of the dozens of alternatives.=
> O=3D=20
>> >r=3D20=20
>> >> > > write a batch file. Or make your own build program - it's not hard=
>, =3D=20
>> >at=3D20=20
>> >> > > least for a simple arrangement.=3D20=20
>> >> >=3D20=20
>> >> > You're misunderstanding something - I don't need nor want 'make'. It=
>'s=3D=20
>> >=3D20=20
>> >> > is just an obstacle to building any software that others use without=
>=3D20=20
>> >> > thinking.=20
>> >> /You/ are misunderstanding something. If you need to do something, and=
>=3D20=20
>> >> there are tools easily available that let you do it, but you refuse to=
>=3D20=20
>> >> use those tools, then you can't expect any sympathy from others.=3D20=
>=20
>> >>=3D20=20
>> >> gcc is a compiler (or a driver program, or a collection of compilers,=
>=3D20=20
>> >> depending on what part of it you are talking about). It was not built=
>=3D20=20
>> >> to spoon-feed lazy or ignorant developers. And it does not contain a=
>=3D20=20
>> >> build tool.=20
>> >> >=3D20=20
>> >> > > Don't forget that compilers are also usually intended for develope=
>rs.=3D=20
>> >=3D20=20
>> >> >=3D20=20
>> >> > But you must agree that the needs of an end-user are different? And=
>=3D20=20
>> >> > simpler. No real need to do tons of testing or analysis: that has=3D=
>20=20
>> >> > already been done.=3D20=20
>> >> >=20
>> >> Yes, I agree.=20
>> >> > So a streamlined build process and a streamlined compiler will work=
>=3D20=20
>> >> > better with fewer failure points.=3D20
>> >> >=20
>> >> Yes. So use a build tool.
>> >> >=3D20=20
>> >> > I have tried to build CPython on Windows. But it doesn't use gcc in =
>tha=3D=20
>> >t=3D20=20
>> >> > case, it used MSVC.=3D20=20
>> >> >=3D20=20
>> >> > The process involved first updating .NET, then downloading VS 2017 (=
>a=3D=20
>> >=3D20=20
>> >> > 90-minute install), then GIT, then SVN, then MS Build Tools, and the=
>n i=3D=20
>> >t=3D20=20
>> >> > failed on something else, by which time, several hours and 10GB of=
>=3D20=20
>> >> > downloads later, I gave up.=3D20=20
>> >> >=3D20=20
>> >> > Over-complex build systems GO WRONG.=3D20=20
>> >> >=20
>> >> CPython is a huge project, unsuitable for amateurs to build. That's wh=
>y=3D=20
>> >=3D20=20
>> >> almost nobody builds it themselves.=3D20=20
>> >>=3D20=20
>> >> Windows is a huge mess, unsuitable for serious development work. That'=
>s=3D=20
>> >=3D20=20
>> >> why so many people (including lots at Microsoft) prefer *nix systems f=
>or=3D=20
>> >=3D20=20
>> >> development.=3D20=20
>> >>=3D20=20
>> >> You are combining a massive project with a shitty OS and a totally=3D2=
>0=20
>> >> incompetent developer, and expecting things to go smoothly. It's hardl=
>y=3D=20
>> >=3D20=20
>> >> a fair test.=20
>> >> > The first obstacle in using 'make' with gcc 10.3.0 is, there IS no=
>=3D20
>> >> > make.exe! (There is mingw32-make.exe which you have to rename or cop=
>y.)
>> >> gcc never has, and never will, ship with any version of "make".=3D20=
>=20
>> >>=3D20=20
>> >> You might have acquired them together from some third-party packaging=
>=3D20=20
>> >> system. If you don't like the way that packaging was done, take it up=
>=3D20
>> >> with them. Maybe ask for a refund.
>> >> >=3D20=20
>> >> > gcc 13.2 comes with make.exe, so they learnt something! (I wonder at=
>=3D20=20
>> >> > what point they decided that actually providing 'make.exe' was a goo=
>d=3D=20
>> >=3D20=20
>> >> > idea?)=3D20=20
>> >> >=20
>> >> gcc never has, and never will, ship with any version of "make".=3D20=
>=20
>> >>=3D20=20
>> >> Look, you /know/ this stuff. You've been told countless times. This is=
>=3D20
>> >> why people call you a troll - you can't be /that/ stupid.
>> >> > The next one is, how does 'make' know what C compiler I want to use?=
> At=3D=20
>> >=3D20
>> >> > one point I had half a dozen.
>> >> Clearly these "computah" things are a bit advanced for you. May I=3D20
>> >> recommend an iPad? Or a TV? Because now I am sure you are trolling.=20
>> >
>> >In context of your own remark of few posts above: "(remember, gcc origin=
>ate=3D=20
>> >s=20
>> > in a world where people can happily write "make prog" to get the same e=
>ffe=3D
>> >ct=20
>> > - saving a keystroke!)" I find Bart's question perfectly legitimate.=20
>> >
>> The short answer, RTFM.=20
>>=20
>
>I sort of remember your 1st answer from RTFM that I did 30+ years ago.
>But that was 30+ years ago and even then people that read manuals were=20
>in minority.
>
>> A slightly longer answer, make _doesn't_ know what C compiler you=20
>> want to use. You tell it which C compiler you want to use. Some=20
>> make installations include a set of default rules. These default=20
>> rules issue shell commands using the standard 'cc' or 'c++' names,=20
>> however the user can easily override them either by:=20
>>=20
>> 1) Using a make variable in the rule for '.c' -> '.o' and setting the=20
>> variable to the name of the compiler:=20
>>=20
>> CC=3Dbcc=20
>> ...=20
>
>It does not work on msys2 bash shell. However 'export CC=3Dbcc' does work.
>I didn't try it on Linux yet.

The entire fragment was intended to be in a make file (or in my typical
case, the variable assignment is in Makefile and the rule is in Makefile.rules
which is included by the Makefile).

You've discovered that make will honor environment variables, and
as you point out that to include the shell variables in the make
application environment requires either:

1) exporting them from the shell (sh/ksh/bash/mksh) or
2) specifying them on the same line as the command:

$ CC=bcc make

>Touching PATH sounds like too big a hammer that could too easily=20
>break something else.

Using PATH properly is a fundamental aspect of Unix/Linux systems, and it is
quite commonly used to select sets of tools based on the project.

On 2023-08-08, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> Bart's right about make. If it actually worked properly we wouldn't
> need CMake.

But, firstly, CMake doesn't do away with make; it generates Makefiles!

Make implementations like GNU Make are of a lot better quality and
better at doing what they are designed to than CMake is at doing
its job.

It's a poor design with a poor input language.

That doesn't mean you can easily replace what it does with Make;
that's not the argument.

But you definitely should replace what it does with something else.

Frankly, I'd rather separately maintain a .BAT file and a .sh file to
build some C or C++ code on Windows and Unix, as a sequence of
boiler-plate compiler commands, than use CMake.

On 08/08/2023 16:49, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 08/08/2023 15:34, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 08/08/2023 15:05, Scott Lurndal wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>>> On 08/08/2023 12:11, David Brown wrote:
>>>>>
>>>>>> It is one stupid decision in one compiler that nobody has bothered to
>>>>>> fix. At least give it an option to override, but in a form where you
>>>>>> don't need to provide a file name. Example:
>>>>>>
>>>>>> gcc -new prog.c
>>>>>
>>>>> This would violate the POSIX option guidelines.
>>>>>
>>>>> gcc -o new prog.c
>>>>>
>>>>> is far superior in every way.
>>>>
>>>> That doesn't do the same thing. I want the output to be prog.exe, but I
>>>> don't want to have to write 'prog' twice.
>>>
>>> That's your problem, not ours.
>>>
>>> Besides, filename suffixes for executables is silly.
>>
>> It would certainly be a problem for Linux, since it would mean typing it
>> every time:
>>
>> gcc.exe hello.c -hello
>>
>> So, OF COURSE you will claim that they are silly anyway!
>
> Actually, they (file suffixes) have been a security problem since day one
> on Windows.
>
> I've been using C since 1979,
>
> $ cc -o ls ls.c
>
> has been a useful paradigm for a half century; if you don't like it, that's
> your problem.
>
> Note that the vast majority of real production C code consists of multiple
> source files (hundreds in some cases, often in multiple languages and
> sometimes compiling C code generated (e.g. lex, yacc) by other utilities);
> it is unlikely that even you would manually type a compilation command line
> with hundreds of source files.
>

99% of my invocations of C compilers are with single files.

These include test fragments (I work with compilers), code posted on
forums, benchmarks and self-contained libraries.

Where there are multiple C modules, I used to use my IDE where a project
file listed the modules.

I no longer support C there [except for my C compiler], so now I use a
command line invocation with an @ file that lists the files and options.
Sometimes I might use a batch file.

Listing and scripting is trivial to do when you have full information
about the structure of a product. But usually such information is buried
in a makefile behind arcane syntax.

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

I won't say what, if anything, you should do about it.

--
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:
[...]
> Virtually any integer which represents a value rather than a collection of bits
> can be represented exactly by a double.
> So
> printf("%g\n", (double) x);
> should do what you want, regardless of the type of x.

If x is 1000001, the output is "1e+06". I don't consider that
acceptable. Nor do I want to have to stop and think whether the values
I'm printing *might* be too big to be stored in a double without losing
information.

If I don't know the type of x, I might use:
printf("%jd\n", (intmax_t)x);
or
printf("%ju\n", (uintmax_t)x);
(Or I might use [unsigned] long long if I happen to know the value fits
in 64 bits.)

--
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 */

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.

It will need at least 13 hex digits: 13 for 52 mantissa bits, and there
will usually be an implicit '1' bit.

This is the test I used now:

#include <stdio.h>
int main(void) {
double x=1/700.0;

printf("%16llX\n", *(long long*)&x);
printf("%lA\n", x);
}

Output using msvcrt.dll is:

3F5 767DCE434A9B1
0X1.767DCEP-10

Quite a bit of precision is missing. The output using online gcc is:

3F5 767DCE434A9B1
0X1.767DCE434A9B1P-10

(I've lined up the numbers in each case and added a space after the
first 3 digits of the %X output, which are the sign and exponent)

It is possible that the "1." part of some of these outputs is intended
to isolate that implicit bit, so that the remaining 13 digits represent
the mantissa. But then some versions didn't do that.

I would have prefered also that %A showed all trailing zero digits as
well, so that it is obvious they exist, but with x=1/128.0 for example
they are trimmed:

3F8 0000000000000
0X1P-7

(When I need exact representations of an IEEE754 value, I normally use
the type-punning approach and write the 16 hex digits of the uint64_t
pattern.)

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

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.

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.

> We produce graphical tools, so we have plenty of
> resources that need to be embedded in the programs.. But we don't have a
> pipeline set up with make dependencies. You could fiddle with such a system until
> it worked. But it would fall over at the slightest stress.

No, you are simply wrong here. The fact that you are unqualified to
develop advanced makefiles, and unfamiliar with the tool's capabilities,
does not make it fragile.

>>> You might be right about that. We considered internationalisation at
>>> work (we make tools for artists), but the customers said they were
>>> happy with English, and it was such a bag of worms that we rejected
>>> the idea. So I've no experience. Part of the reason for discussing it here
>>> is that other people might have such experience.
>> Just think about it a little. You know a language or two other than
>> English - put yourself in the position of a translator who does not
>> understand C and is not a programmer. Would you want to face that XML crap?
>>> You can't really support Unicode but not support internationalisation,
>>> however.
>> Of course you can. It is only the opposite that will cause you
>> difficulties.
>>
> 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.)

> As I said, if as a side effect the Baby X resource compiler is useful to
> non-Baby X porgrammers, then that's great. But the focus is on having
> a good tool which will help unleash the potential of Baby X.
>
> But for version 1.3 I could well shift focus to meeting the needs of non-
> Baby X programmers. I know that more people download the resource
> compiler than download Baby X, which suggest that there is a need there.
>
> And whilst there are competitors to Baby X, there isn't a close competitor
> to the resource compiler which I have seen.
>

Bart <bc@freeuk.com> writes:
> 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' ?
[...]

Sure, some languages have "print" as a built-in operation.

C and C++ both build their I/O operations on top of language
features. (And those features, particularly variadic functions,
are influenced by the needs of flexible I/O.) That means that the
same mechanism that prints a value to standard output can be used to
print a value to stderr, to convert it to a string, to send it to
a system log with a timestamp and a priority implicitly prepended
to each message, and so on. (And in C++, you can use the same
mechanism to print or serialize values of any type if you write
code to do the formatting.)

You can also specify, in a more or less clean way, how the value
should be formatted: hex vs. decimal, left vs. right justification,
padding with '0' vs. ' ', scientific notation, upper vs. lower
case, etc.). (I have issues with how C++ does that, but I won't
get into that here.)

It's trickier to use, but it's *much* more flexible than a built-in
"print" statement is likely to be, which I'd say is a good tradeoff
for a systems programming language.

--
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:
[...]
> 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.)

--
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 */

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.

Its behavior depends on the exact version of Windows your program
is running on.

The %A conversion specifier might not be there at all if the program
is run on some older Windows.

Microsoft's Raymond Chen explains it best in this 2014 article:

https://devblogs.microsoft.com/oldnewthing/20140411-00/?p=1273

"Windows is not a Microsoft Visual C/C++ Run-Time delivery channel"

Microsoft has since developed a library that *is* for application use.
Starting in Windows 10, there is something called the
"Universal C Run-Time". It's sort of Microsoft's answer to finally
provide the equivalent of a Unix Libc.

This run time is also available for installation for older Windows
going back to Vista and Server 2008. See here:

https://www.microsoft.com/en-ca/download/details.aspx?id=50410

Unless you need to run on older Windows than Vista, it's better
to use this Universal C Run Time than wrongly relying on the
MSVCRT.DLL internal library.

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

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!

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

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

It must be a peculiar world on *nix where on the one hand, /everything/
you can possibly need is provided, yet on the another, a C compiler like
gcc (or is it really cc?) exists in isolation.

In my world, my complete C implementation is these two files:

c:\demo>dir

06/08/2023 18:19 965,120 bcc.exe
17/03/2023 12:44 691,456 msvcrt.dll
2 File(s) 1,656,576 bytes

bcc.exe is my product and includes system headers plus windows.h inside
it. It turns multiple .c files into .i, .s or .exe files (.obj and .dll
outputs currently shelved).

It does everything you need.

msvcrt.dll is part of Windows and normally lives in c:\windows\system32.

It's a bit simpler, yes? But presumably a valid implementation, if not
exactly conformant.

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

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.

--
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 */