defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138)
thread.o:(PyThread_init_thread) in archive /usr/local/lib/libpython3.13.a
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:140 (Python/thread_pthread.h:140)
thread.o:(PyThread_init_thread) in archive /usr/local/lib/libpython3.13.a
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:141 (Python/thread_pthread.h:141)
thread.o:(PyThread_init_thread) in archive /usr/local/lib/libpython3.13.a
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138)
thread.o:(do_start_joinable_thread) in archive /usr/local/lib/libpython3.13.a
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:140 (Python/thread_pthread.h:140)
thread.o:(do_start_joinable_thread) in archive /usr/local/lib/libpython3.13.a
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:141 (Python/thread_pthread.h:141)
thread.o:(do_start_joinable_thread) in archive /usr/local/lib/libpython3.13.a
defined in /usr/local/lib/libpython3.13.a(thread.o)
referenced by thread_pthread.h:290 (Python/thread_pthread.h:290)
thread.o:(do_start_joinable_thread) in archive /usr/local/lib/libpython3.13.a
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138)
thread.o:(PyThread_get_thread_ident_ex) in archive /usr/local/lib/libpython3.13.a
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:140 (Python/thread_pthread.h:140)
thread.o:(PyThread_get_thread_ident_ex) in archive /usr/local/lib/libpython3.13.a
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:141 (Python/thread_pthread.h:141)
thread.o:(PyThread_get_thread_ident_ex) in archive /usr/local/lib/libpython3.13.a
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138)
thread.o:(PyThread_get_thread_ident) in archive /usr/local/lib/libpython3.13.a
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:140 (Python/thread_pthread.h:140)
thread.o:(PyThread_get_thread_ident) in archive /usr/local/lib/libpython3.13.a
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:141 (Python/thread_pthread.h:141)
thread.o:(PyThread_get_thread_ident) in archive /usr/local/lib/libpython3.13.a
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138)
thread.o:(PyThread_get_thread_native_id) in archive /usr/local/lib/libpython3.13.a
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:140 (Python/thread_pthread.h:140)
thread.o:(PyThread_get_thread_native_id) in archive /usr/local/lib/libpython3.13.a
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:141 (Python/thread_pthread.h:141)
thread.o:(PyThread_get_thread_native_id) in archive /usr/local/lib/libpython3.13.a
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138)
thread.o:(PyThread_allocate_lock) in archive /usr/local/lib/libpython3.13.a
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:140 (Python/thread_pthread.h:140)
thread.o:(PyThread_allocate_lock) in archive /usr/local/lib/libpython3.13.a
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:141 (Python/thread_pthread.h:141)
thread.o:(PyThread_allocate_lock) in archive /usr/local/lib/libpython3.13.a
defined in /usr/local/lib/libpython3.13.a(thread.o)
referenced by thread_pthread.h:441 (Python/thread_pthread.h:441)
thread.o:(PyThread_allocate_lock) in archive /usr/local/lib/libpython3.13.a
Compilation failed unexpectedly.Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol '_PyRuntime'; recompile with -fPIC
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <[email protected]> gabbled:
First off, this isn't really on-topic for comp.lang.c, as it is a question >>regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
No? Then its a perfectly valid post.
First off, this isn't really on-topic for comp.lang.c, as it is a question >regarding a linker, interacting
with the results of various options given to a specific compiler.
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <[email protected]> gabbled:
First off, this isn't really on-topic for comp.lang.c, as it is a question >>regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol '_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138)
thread.o:(PyThread_init_thread) in archive /usr/local/lib/libpython3.13.a
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <[email protected]> gabbled:
First off, this isn't really on-topic for comp.lang.c, as it is a question >>>regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
comp.lang.c is about using the C programming language. Linkers are >independent of the programming language, and can be used to link
together programs written in many different languages. The subject line
and the text of the error messages indicate that it's a Python program,
so why would a group devoted to C be in any way appropriate?
In comp.lang.c The Doctor <[email protected]> wrote:
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol '_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138)
thread.o:(PyThread_init_thread) in archive /usr/local/lib/libpython3.13.a
This is real world question and as such is considered off-topic
in comp.lang.c.
In comp.lang.c The Doctor <[email protected]> wrote:
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol '_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138)
thread.o:(PyThread_init_thread) in archive /usr/local/lib/libpython3.13.a
This is real world question and as such is considered off-topic
in comp.lang.c. However, you could try '-no-pie' to the compiler.
On 3/2/25 12:54, Waldek Hebisch wrote:
In comp.lang.c The Doctor <[email protected]> wrote:
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol >'_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138)
thread.o:(PyThread_init_thread) in archive >/usr/local/lib/libpython3.13.a
This is real world question and as such is considered off-topic
in comp.lang.c. However, you could try '-no-pie' to the compiler.
Real world questions about the C programming language are entirely
on-topic here. Note, however, that many questions posted here are not
about C itself, but about the quirks of particular implementations of C.
You can get better answers to such questions by asking in forums
specific to the relevant implementation, and helpful people will remind
your of that. It's a misunderstanding of those redirections to conclude
that c.l.c is not for real world questions.
However Python is NOT an implementation of C, not even by the loosest >reasonable interpretation, so why should it be discussed here?.
In article <vq2j3n$v2fk$[email protected]>,
James Kuyper <[email protected]> wrote:
On 3/2/25 12:54, Waldek Hebisch wrote:
In comp.lang.c The Doctor <[email protected]> wrote:
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol >>'_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138) >>>>>>> thread.o:(PyThread_init_thread) in archive >>/usr/local/lib/libpython3.13.a
This is real world question and as such is considered off-topic
in comp.lang.c. However, you could try '-no-pie' to the compiler.
Real world questions about the C programming language are entirely
on-topic here. Note, however, that many questions posted here are not
about C itself, but about the quirks of particular implementations of C. >>You can get better answers to such questions by asking in forums
specific to the relevant implementation, and helpful people will remind >>your of that. It's a misunderstanding of those redirections to conclude >>that c.l.c is not for real world questions.
However Python is NOT an implementation of C, not even by the loosest >>reasonable interpretation, so why should it be discussed here?.
Note the C error!
--
Member - Liberal International This is [email protected] Ici [email protected]
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism ;
Ontario vote for the Liberals - The best Anti-Trump option!
In article <vq2j3n$v2fk$[email protected]>,
James Kuyper <[email protected]> wrote:
On 3/2/25 12:54, Waldek Hebisch wrote:
In comp.lang.c The Doctor <[email protected]> wrote:'_PyRuntime'; recompile with -fPIC
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol
/usr/local/lib/libpython3.13.adefined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138) >>>>>>> thread.o:(PyThread_init_thread) in archive
This is real world question and as such is considered off-topic
in comp.lang.c. However, you could try '-no-pie' to the compiler.
Real world questions about the C programming language are entirely
on-topic here. Note, however, that many questions posted here are not
about C itself, but about the quirks of particular implementations of C.
You can get better answers to such questions by asking in forums
specific to the relevant implementation, and helpful people will remind
your of that. It's a misunderstanding of those redirections to conclude
that c.l.c is not for real world questions.
However Python is NOT an implementation of C, not even by the loosest
reasonable interpretation, so why should it be discussed here?.
Note the C error!
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <[email protected]> gabbled:
First off, this isn't really on-topic for comp.lang.c, as it is a question >>>regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
comp.lang.c is about using the C programming language. Linkers are >independent of the programming language, and can be used to link
together programs written in many different languages. The subject line
and the text of the error messages indicate that it's a Python program,
so why would a group devoted to C be in any way appropriate?
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <[email protected]> gabbled:
First off, this isn't really on-topic for comp.lang.c, as it is a question >>>regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
That wouldn't even make sense. What you want is a group like
the comp.unix hierarchy (for ld, as a tool), or gnu.gcc.help
(or even gnu.misc.discuss), or even comp.programming.
Your issue isn't a C language or C usage issue, it's a
"What options do I give this particular compiler in order
to satisfy the requirements of this particular linker?" issue.
On Sun, 2 Mar 2025 12:30:53 -0500
James Kuyper <[email protected]> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <[email protected]> gabbled:
First off, this isn't really on-topic for comp.lang.c, as it is a question >>>> regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text.
together programs written in many different languages. The subject line
and the text of the error messages indicate that it's a Python program,
so why would a group devoted to C be in any way appropriate?
If you'd taken 2 seconds to look at it you'd realise the issue was building the Python source code which is written in C. That sounds like a C issue to me.
On 03/03/2025 08:13, [email protected] wrote:
On Sun, 2 Mar 2025 12:30:53 -0500
James Kuyper <[email protected]> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text.
And without people to write it and buildings in which to work it
wouldn't even be that, so by your argument everything from
demographics to urban planning would be topical here.
It's an old argument, but it has never been a good one.
If you'd taken 2 seconds to look at it you'd realise the issue was building >> the Python source code which is written in C. That sounds like a C issue to >me.
Then you have very gullible ears. Building the Python source is
an issue for a specific compiler group.
On Mon, 3 Mar 2025 08:31:16 +0000
Richard Heathfield <[email protected]> wibbled:
On 03/03/2025 08:13, [email protected] wrote:
On Sun, 2 Mar 2025 12:30:53 -0500
James Kuyper <[email protected]> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text.
And without people to write it and buildings in which to work it
wouldn't even be that, so by your argument everything from
demographics to urban planning would be topical here.
It's an old argument, but it has never been a good one.
Really?
So if a compiler gives an error thats not a C problem?
Go ask a
group for the specific compiler?
What a load of narrow minded BS.
Its not as if these groups get hundreds of
messages a day and the amount needs to be cut down.
If you'd taken 2 seconds to look at it you'd realise the issue was building >>> the Python source code which is written in C. That sounds like a C issue to >> me.
Then you have very gullible ears. Building the Python source is
No idea what gullible ears is supposed to mean.
an issue for a specific compiler group.
So which group would that be then?
On Mon, 3 Mar 2025 08:31:16 +0000
Richard Heathfield <[email protected]> wibbled:
On 03/03/2025 08:13, [email protected] wrote:
On Sun, 2 Mar 2025 12:30:53 -0500
James Kuyper <[email protected]> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text.
And without people to write it and buildings in which to work it
wouldn't even be that, so by your argument everything from
demographics to urban planning would be topical here.
It's an old argument, but it has never been a good one.
Really? So if a compiler gives an error thats not a C problem? Go ask a
group for the specific compiler?
What a load of narrow minded BS. Its not as if these groups get hundreds of messages a day and the amount needs to be cut down.
If you'd taken 2 seconds to look at it you'd realise the issue was building >>> the Python source code which is written in C. That sounds like a C issue to >> me.
Then you have very gullible ears. Building the Python source is
No idea what gullible ears is supposed to mean.
an issue for a specific compiler group.
So which group would that be then?
On 03/03/2025 10:44, [email protected] wrote:
No idea what gullible ears is supposed to mean.
I'm sorry. I'll dial back the rhetoric for you.
Building Python source not C question. Capisce?
So which group would that be then?
No idea. But we're crossposted to comp.lang.python, who may be
willing to give you a hint.
On 03/03/2025 10:44, [email protected] wrote:
On Mon, 3 Mar 2025 08:31:16 +0000
Really? So if a compiler gives an error thats not a C problem? Go ask a
group for the specific compiler?
The errors reported by the OP were like this:
ld: error: relocation R_X86_64_32 cannot be used against symbol
'_PyRuntime'; recompile with -fPIC
'ld' is a program that can be used to link programs in any language.
The problem appears to be do with generating position independent code
since these days linkers like to generate programs that can loaded at an >arbitrary address in high memory.
I can't see anything to do with C here, other than the source in
question may have been written in C.
I expect however you'd be OK with this forum being full of everyday >development issues associated with a million different applications, but >which just happen to be written in C, or which are partly in C.
On usenet? That is pretty much dead.
On Sun, 2 Mar 2025 12:30:53 -0500
James Kuyper <[email protected]> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <[email protected]> gabbled:
First off, this isn't really on-topic for comp.lang.c, as it is a question >>>> regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text.
together programs written in many different languages. The subject line
and the text of the error messages indicate that it's a Python program,
so why would a group devoted to C be in any way appropriate?
If you'd taken 2 seconds to look at it you'd realise the issue was building the Python source code which is written in C.
James Kuyper <[email protected]> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <[email protected]> gabbled:
First off, this isn't really on-topic for comp.lang.c, as it is a question >>>>regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
comp.lang.c is about using the C programming language. Linkers are >>independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text.
together programs written in many different languages. The subject line
and the text of the error messages indicate that it's a Python program,
so why would a group devoted to C be in any way appropriate?
If you'd taken 2 seconds to look at it you'd realise the issue was building >the Python source code which is written in C. That sounds like a C issue to me.
On Mon, 3 Mar 2025 12:20:35 +0000
bart <[email protected]> wibbled:
On 03/03/2025 10:44, [email protected] wrote:
On Mon, 3 Mar 2025 08:31:16 +0000
Really? So if a compiler gives an error thats not a C problem? Go ask a
group for the specific compiler?
The errors reported by the OP were like this:
ld: error: relocation R_X86_64_32 cannot be used against symbol
'_PyRuntime'; recompile with -fPIC
'ld' is a program that can be used to link programs in any language.
The problem appears to be do with generating position independent code
since these days linkers like to generate programs that can loaded at an
arbitrary address in high memory.
I can't see anything to do with C here, other than the source in
question may have been written in C.
Yes, thats kind of the point. You wouldn't get these errors if it was written in Java or C#.
[snip]
On usenet? That is pretty much dead.
Not dead but certainly not buzzing yet
I presume thats how you like it given
you don't want any "everyday development issues" relating to C mentioned here.
Or are you another one who thinks usenet should be for the exclusive discussion
of high brow issues only of interest to you?
On 3/3/25 10:22, James Kuyper wrote:
If it were a C problem, then the C source code that produced the problemWhy is this group so intolerant?
should have been shown. It's hard to debug code that you can't see.
On 3/3/25 10:22, James Kuyper wrote:...
On 03/03/2025 08:13, [email protected] wrote:
Why is this group so intolerant?That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
On 3/3/25 11:24, geodandw wrote:
On 3/3/25 10:22, James Kuyper wrote:....
On 03/03/2025 08:13, [email protected] wrote:
Why is this group so intolerant?That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem >>> should have been shown. It's hard to debug code that you can't see.
Because what you call intolerance, we call topicality. When you post a >message to a group where it is on-topic, the message gets seen and
On 03/03/2025 08:13, [email protected] wrote:
Without compilers and linkers a C program would just be a load of text.
Without computers, keyboards and monitors most C programs wouldn't be
much use, either. That doesn't make a malfunctioning computer monitor a
C problem. And it doesn't make a linkage problems a C problem either.
If it were a C problem, then the C source code that produced the problem >should have been shown. It's hard to debug code that you can't see.
On Mon, 3 Mar 2025 11:39:58 -0500
James Kuyper <[email protected]> wibbled:
On 3/3/25 11:24, geodandw wrote:
On 3/3/25 10:22, James Kuyper wrote:....
On 03/03/2025 08:13, [email protected] wrote:
Why is this group so intolerant?That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem >>>> should have been shown. It's hard to debug code that you can't see.
Because what you call intolerance, we call topicality. When you post a
message to a group where it is on-topic, the message gets seen and
Only an arrogant idiot would think that errors on linking object files generated by a C compiler are not relevant in a C language group.
On Mon, 3 Mar 2025 11:39:58 -0500
James Kuyper <[email protected]> wibbled:
On 3/3/25 11:24, geodandw wrote:
On 3/3/25 10:22, James Kuyper wrote:....
On 03/03/2025 08:13, [email protected] wrote:
Why is this group so intolerant?That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem >>>> should have been shown. It's hard to debug code that you can't see.
Because what you call intolerance, we call topicality. When you post a
message to a group where it is on-topic, the message gets seen and
Only an arrogant idiot would think that errors on linking object files generated by a C compiler are not relevant in a C language group.
On 3/2/25 12:54, Waldek Hebisch wrote:
In comp.lang.c The Doctor <[email protected]> wrote:
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol '_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138)
thread.o:(PyThread_init_thread) in archive /usr/local/lib/libpython3.13.a
This is real world question and as such is considered off-topic
in comp.lang.c. However, you could try '-no-pie' to the compiler.
Real world questions about the C programming language are entirely
on-topic here. Note, however, that many questions posted here are not
about C itself, but about the quirks of particular implementations of C.
You can get better answers to such questions by asking in forums
specific to the relevant implementation, and helpful people will remind
your of that. It's a misunderstanding of those redirections to conclude
that c.l.c is not for real world questions.
However Python is NOT an implementation of C, not even by the loosest reasonable interpretation, so why should it be discussed here?.
On 3/3/25 10:22, James Kuyper wrote:
On 03/03/2025 08:13, [email protected] wrote:Why is this group so intolerant?
On Sun, 2 Mar 2025 12:30:53 -0500
James Kuyper <[email protected]> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <[email protected]> gabbled:
First off, this isn't really on-topic for comp.lang.c, as
it is a question
regarding a linker, interacting
with the results of various options given to a specific
compiler.
Is there a comp.lang.c.linker group?
comp.lang.c is about using the C programming language.
Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load
of text.
Without computers, keyboards and monitors most C programs
wouldn't be
much use, either. That doesn't make a malfunctioning computer
monitor a
C problem. And it doesn't make a linkage problems a C problem
either.
together programs written in many different languages. The
subject line
and the text of the error messages indicate that it's a
Python program,
so why would a group devoted to C be in any way appropriate?
If you'd taken 2 seconds to look at it you'd realise the issue
was building
the Python source code which is written in C.
The indentations of the first message cross-posted to
comp.lang.c and
comp.lang.c++ suggest that it was the latest in a series of
earlier
messages posted somewhere else (comp.lang.python?). Those earlier
messages might have contained additional information. If that
information was relevant, it should have been included when the
message
was first cross-posted to comp.lang.c or comp.lang.c++. You
might be
right about it being "Python source code ... written in C", but
nothing
in the messages that were posted here makes that obvious.
That sounds like a C issue to me.
If it were a C problem, then the C source code that produced
the problem
should have been shown. It's hard to debug code that you can't
see.
In comp.lang.c James Kuyper <[email protected]> wrote:
However Python is NOT an implementation of C, not even by the loosest
reasonable interpretation, so why should it be discussed here?.
The question is about C implementation. Namely, the bible for
this group, that is C standard requires C implementation to
produce executables.
Why is this group so intolerant?
In comp.lang.c James Kuyper <[email protected]> wrote:
On 3/2/25 12:54, Waldek Hebisch wrote:
In comp.lang.c The Doctor <[email protected]> wrote:
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol '_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138) >>>>>>> thread.o:(PyThread_init_thread) in archive /usr/local/lib/libpython3.13.a
This is real world question and as such is considered off-topic
in comp.lang.c. However, you could try '-no-pie' to the compiler.
Real world questions about the C programming language are entirely
on-topic here. Note, however, that many questions posted here are not
about C itself, but about the quirks of particular implementations of C.
You can get better answers to such questions by asking in forums
specific to the relevant implementation, and helpful people will remind
your of that. It's a misunderstanding of those redirections to conclude
that c.l.c is not for real world questions.
However Python is NOT an implementation of C, not even by the loosest
reasonable interpretation, so why should it be discussed here?.
The question is about C implementation.
The question is about C implementation. Namely, the bible for
this group, that is C standard requires C implementation to
produce executables. And making executable from C sources
it at core of the OP question. Fact that compiling this source
is supposed to produce Python interpreter or maybe some
supporting shared library is irrelevant here.
One could call the problem "Linux problem". Namely, many
(maybe all) Linux distribution modify(ed) gcc so that creating
position independent executables is the default and to
prevent this one need '-no-pie' at final stage. And to
generate position independent executable all code has to
be compiled as position independent code which needs '-fPIC'
option. Similarly, if OP is trying to create shared
library, then on Linux all code inluded in the shared
librayr must be compiled as position independent code,
that is using '-fPIC'.
Dismissing this as linker problem misses important
points:
- linking is considerd part of C implementation
- '-fPIC' is option for compiler proper
- '-no-pie' is handled by the compiler driver
And frankly, making executables or shared library from
C code is real world thing that C programmer want to do
and non-programmers would not do.
James Kuyper <[email protected]> writes:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <[email protected]> gabbled:
First off, this isn't really on-topic for comp.lang.c, as it is a question >>>> regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
together programs written in many different languages. The subject line
and the text of the error messages indicate that it's a Python program,
so why would a group devoted to C be in any way appropriate?
Frankly, I'd rather read about issues in the linker here than the interminable useless arguments about the precision and accuracy of
fmod, which belong elsewhere (such as email), or pointless musings
about the halting problem.
In comp.lang.c James Kuyper <[email protected]> wrote:
On 3/2/25 12:54, Waldek Hebisch wrote:
In comp.lang.c The Doctor <[email protected]> wrote:
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol '_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138) >>>>>>> thread.o:(PyThread_init_thread) in archive /usr/local/lib/libpython3.13.a
This is real world question and as such is considered off-topic
in comp.lang.c. However, you could try '-no-pie' to the compiler.
Real world questions about the C programming language are entirely
on-topic here. Note, however, that many questions posted here are not
about C itself, but about the quirks of particular implementations of C.
You can get better answers to such questions by asking in forums
specific to the relevant implementation, and helpful people will remind
your of that. It's a misunderstanding of those redirections to conclude
that c.l.c is not for real world questions.
However Python is NOT an implementation of C, not even by the loosest
reasonable interpretation, so why should it be discussed here?.
The question is about C implementation. Namely, the bible for
this group, that is C standard requires C implementation to
produce executables. And making executable from C sources
it at core of the OP question. Fact that compiling this source
is supposed to produce Python interpreter or maybe some
supporting shared library is irrelevant here.
One could call the problem "Linux problem". Namely, many
(maybe all) Linux distribution modify(ed) gcc so that creating
position independent executables is the default and to
prevent this one need '-no-pie' at final stage. And to
generate position independent executable all code has to
be compiled as position independent code which needs '-fPIC'
option. Similarly, if OP is trying to create shared
library, then on Linux all code inluded in the shared
librayr must be compiled as position independent code,
that is using '-fPIC'.
Dismissing this as linker problem misses important
points:
- linking is considerd part of C implementation
- '-fPIC' is option for compiler proper
- '-no-pie' is handled by the compiler driver
And frankly, making executables or shared library from
C code is real world thing that C programmer want to do
and non-programmers would not do.
OP uses some build system and fixing his problem presumably
needs changes to build system. And reasonably build system
may be cosidered of topic here.
However, fact that compilation
proper and final linking must use consitent options is
real world C problem. I appreciate that many years ago
comp.lang.c regulars decided that they do not want to answer
such real world question. However, do you want to tell OP
"pretend that your main program is in Fortran and ask your
question in comp.lang.fortran"? FYI, similar questions were
asked and answered in comp.lang.fortran without questioning
topicality. So clearly, the only thing which makes such
question of topic here is past deliberate decision to exclude
them.
On 3/3/25 12:19, Richard Heathfield wrote:
On 03/03/2025 16:24, geodandw wrote:
Why is this group so intolerant?
Why are you so intolerant of other people's wish to keep this
group topical?
A. Because
On 3/3/25 11:39, James Kuyper wrote:
On 3/3/25 11:24, geodandw wrote:Even if it is topicality, whey people rude and insulting to others in
On 3/3/25 10:22, James Kuyper wrote:...
On 03/03/2025 08:13, [email protected] wrote:
Why is this group so intolerant?That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem >>>> should have been shown. It's hard to debug code that you can't see.
Because what you call intolerance, we call topicality. When you post a
message to a group where it is on-topic, the message gets seen and
responded to by people who are more likely to understand and be
interested in the contents of the message, and can give you better
answers to any questions you have. When you post to the wrong group,
they will be less interested in the message and less capable of giving
good answers to it.
However, if you're not interested in getting good answers to your
questions, and it doesn't bother you that your messages are going to
people not interested in the topic of your message, by all means post to
any group you choose. This isn't a moderated group - no one can stop you
from posting here.
this group?
James Kuyper <[email protected]> wibbled:
On 3/3/25 11:24, geodandw wrote:
On 3/3/25 10:22, James Kuyper wrote:....
On 03/03/2025 08:13, [email protected] wrote:
Why is this group so intolerant?That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem >>>> should have been shown. It's hard to debug code that you can't see.
Because what you call intolerance, we call topicality. When you post a >>message to a group where it is on-topic, the message gets seen and
Only an arrogant idiot would think that errors on linking object files >generated by a C compiler are not relevant in a C language group.
On 3/3/25 14:15, Richard Heathfield wrote:
Clearly you have no objection to intolerance as long as it's you doing it. >>Disliking intolerance is not intolerance.
In comp.lang.c James Kuyper <[email protected]> wrote:
On 3/2/25 12:54, Waldek Hebisch wrote:
In comp.lang.c The Doctor <[email protected]> wrote:
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol
'_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138)
thread.o:(PyThread_init_thread)
in archive /usr/local/lib/libpython3.13.a
This is real world question and as such is considered off-topic in
comp.lang.c. However, you could try '-no-pie' to the compiler.
Real world questions about the C programming language are
entirely on-topic here. Note, however, that many questions
posted here are not about C itself, but about the quirks of
particular implementations of C. You can get better answers to
such questions by asking in forums specific to the relevant
implementation, and helpful people will remind your of that.
It's a misunderstanding of those redirections to conclude that
c.l.c is not for real world questions.
However Python is NOT an implementation of C, not even by the loosest
reasonable interpretation, so why should it be discussed here?.
The question is about C implementation. Namely, the bible for
this group, that is C standard requires C implementation to
produce executables.
On 3/3/25 14:15, Richard Heathfield wrote:
On 03/03/2025 18:33, geodandw wrote:Disliking intolerance is not intolerance.
On 3/3/25 12:19, Richard Heathfield wrote:
On 03/03/2025 16:24, geodandw wrote:
<snip>
Why is this group so intolerant?
Why are you so intolerant of other people's wish to keep this
group topical?
A. Because
[...reason...]
Clearly you have no objection to intolerance as long as it's
you doing it.
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol '_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138)
thread.o:(PyThread_init_thread) in archive /usr/local/lib/libpython3.13.a
On 3/3/25 12:19, Richard Heathfield wrote:
On 03/03/2025 16:24, geodandw wrote:
On 3/3/25 10:22, James Kuyper wrote:
That sounds like a C issue to me.Why is this group so intolerant?
If it were a C problem, then the C source code that produced the
problem
should have been shown. It's hard to debug code that you can't see.
Why are you so intolerant of other people's wish to keep this group
topical?
A. Because the problem is apparently using the right options on the
compiler, which seems like a C question to me.
B.Because some people in this group are arrogant. rude, and
insulting..If the shoe fits, wear it.
On 03/03/2025 17:56, [email protected] wrote:
On Mon, 3 Mar 2025 11:39:58 -0500
James Kuyper <[email protected]> wibbled:
On 3/3/25 11:24, geodandw wrote:
On 3/3/25 10:22, James Kuyper wrote:....
On 03/03/2025 08:13, [email protected] wrote:
Why is this group so intolerant?That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem >>>>> should have been shown. It's hard to debug code that you can't see.
Because what you call intolerance, we call topicality. When you post a
message to a group where it is on-topic, the message gets seen and
Only an arrogant idiot would think that errors on linking object files
generated by a C compiler are not relevant in a C language group.
If the problem could be solved by understanding C better, it would be >relevant. But the problem has nothing to do with the C /code/ in
question, nor the C language. It's a matter of the build process for
For the obligatory car metaphor, imagine a group dedicated to learning
to drive and driving techniques. A post about a particular make of car
would be off-topic, but perhaps okay on occasion. The OP's post here is >asking for the best way to avoid roadworks on the Bath to Reading road.
On 03/03/2025 16:56, [email protected] wrote:
On Mon, 3 Mar 2025 11:39:58 -0500
James Kuyper <[email protected]> wibbled:
On 3/3/25 11:24, geodandw wrote:
On 3/3/25 10:22, James Kuyper wrote:....
On 03/03/2025 08:13, [email protected] wrote:
Why is this group so intolerant?That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem >>>>> should have been shown. It's hard to debug code that you can't see.
Because what you call intolerance, we call topicality. When you post a
message to a group where it is on-topic, the message gets seen and
Only an arrogant idiot would think that errors on linking object files
generated by a C compiler are not relevant in a C language group.
James Kuyper has been posting here for decades, and has helped
many hundreds, or more likely thousands, of C programmers to
better understand the C language. A genuine language expert, he
deserves to be treated better than to be called an arrogant
idiot, especially when the abuser has no discernible track record
of having ever helped anyone with high quality C advice.
That may be because "Muttley" doesn't seem even to know what the
C language /is/.
On 03/03/2025 17:24, geodandw wrote:
Why is this group so intolerant?
These groups (comp.lang.c and comp.lang.c++ - it's a long time since I
looked at comp.lang.python, but I expect things are similar there) are
very tolerant of most posters, but there are few people who seem to
delight in annoying people and spreading their own confusion.
The posts here are mostly trying to give the OP what little help they
can, and then direct him towards better sources of information - or they
are trolls by an anonymous coward who regularly changes his nom de
guerre because he is killfiled by so many people.
On Mon, 3 Mar 2025 17:25:27 +0000
Richard Heathfield <[email protected]> wibbled:
On 03/03/2025 16:56, [email protected] wrote:
On Mon, 3 Mar 2025 11:39:58 -0500
James Kuyper <[email protected]> wibbled:
On 3/3/25 11:24, geodandw wrote:
On 3/3/25 10:22, James Kuyper wrote:....
On 03/03/2025 08:13, [email protected] wrote:
That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem >>>>>> should have been shown. It's hard to debug code that you can't see. >>>>> Why is this group so intolerant?
Because what you call intolerance, we call topicality. When you post a >>>> message to a group where it is on-topic, the message gets seen and
Only an arrogant idiot would think that errors on linking object files
generated by a C compiler are not relevant in a C language group.
James Kuyper has been posting here for decades, and has helped
Oh well, in that case I bow down in front of his magnificence, he must not
be contradicted!
many hundreds, or more likely thousands, of C programmers to
better understand the C language. A genuine language expert, he
deserves to be treated better than to be called an arrogant
idiot, especially when the abuser has no discernible track record
of having ever helped anyone with high quality C advice.
That may be because "Muttley" doesn't seem even to know what the
C language /is/.
Compilation is a fundamental part of the process of programming in C whether you and Kuyper like it or not.
On 04/03/2025 08:32, [email protected] wrote:
Oh well, in that case I bow down in front of his magnificence, he must not >> be contradicted!
James would be the first to say that he should be contradicted
when he is mistaken.
Here, he is not mistaken. You are.
Compilation is a fundamental part of the process of programming in C whether >> you and Kuyper like it or not.
Quoth K&R in "The C Programming Language":
Just how to run this program depends on the system you are using.
As a specific example, on the UNIX operating system you must
On Mon, 3 Mar 2025 18:28:20 +0100
David Brown <[email protected]> wibbled:
On 03/03/2025 17:24, geodandw wrote:
Why is this group so intolerant?
These groups (comp.lang.c and comp.lang.c++ - it's a long time since I >>looked at comp.lang.python, but I expect things are similar there) are
very tolerant of most posters, but there are few people who seem to
delight in annoying people and spreading their own confusion.
The posts here are mostly trying to give the OP what little help they
can, and then direct him towards better sources of information - or they >>are trolls by an anonymous coward who regularly changes his nom de
guerre because he is killfiled by so many people.
"Troll" here being the snowflake definition of the word - ie "someone I disagree with but am unable to counter his arguments to any great extent"
On 04/03/2025 09:23, [email protected] wrote:
because plenty of compilation issues are caused by code issues.
Undoubtedly true, and equally undoubtedly irrelevant in this
case. Were it relevant, the OP would by now have shown us the
problem code.
Or are you claiming those don't count as part of development?
Not at all. Your keyboard's shift key is part of development too,
but that isn't enough to make it topical in comp.lang.c.
K&R would also claim that the function parameter type definitions have to
follow the prototype. Luckily that hasn't been the case since 1989.
Is it, then, your claim that K&R are mistaken or outdated and
that compilation no longer depends on the system you are using
and has now become a language attribute? Can you hear the
chuckles yet?
If you think you can defend your claim by showing where the
language standard supports your extraordinarily wobbly position,
by all means have a crack at it. Show us why you're right.
On Tue, 4 Mar 2025 08:56:57 +0000
Richard Heathfield <[email protected]> wibbled:
On 04/03/2025 08:32, [email protected] wrote:
Oh well, in that case I bow down in front of his magnificence, he must not >>> be contradicted!
James would be the first to say that he should be contradicted
when he is mistaken.
Here, he is not mistaken. You are.
No, I'm not,
because plenty of compilation issues are caused by code issues.
Or are you claiming those don't count as part of development?
Compilation is a fundamental part of the process of programming in C whether
you and Kuyper like it or not.
Quoth K&R in "The C Programming Language":
*yawn*
Just how to run this program depends on the system you are using.
As a specific example, on the UNIX operating system you must
Blah blah.
K&R would also claim that the function parameter type definitions have to follow the prototype. Luckily that hasn't been the case since 1989.
On Tue, 4 Mar 2025 09:57:16 +0000
Richard Heathfield <[email protected]> wibbled:
On 04/03/2025 09:23, [email protected] wrote:
because plenty of compilation issues are caused by code issues.
Undoubtedly true, and equally undoubtedly irrelevant in this
case. Were it relevant, the OP would by now have shown us the
problem code.
So what you're saying is you can't troubleshoot linking problems.
Do you
get someone else to compile your code for you?
Or are you claiming those don't count as part of development?
Not at all. Your keyboard's shift key is part of development too,
but that isn't enough to make it topical in comp.lang.c.
Oh dear, if stuck go in circles, posted comparisons conveniently ignored.
K&R would also claim that the function parameter type definitions have to >>> follow the prototype. Luckily that hasn't been the case since 1989.
Is it, then, your claim that K&R are mistaken or outdated and
Is K&R outdated? Hmm, let me think about that for a nanosecond...
that compilation no longer depends on the system you are using
and has now become a language attribute? Can you hear the
chuckles yet?
Wtf has the language standard got to do with anything?
Originally, people /politely/ pointed out that the post was
off-topic, and the OP was unlikely to get good help here.
Indeed, I don't think anyone has been other than polite to the OP.
But there have been two people in this thread who have perhaps
been rude, arrogant and insulting - insisting that /they/ know
better than the regulars about what is topical and not topical
for the group. Those posters have not in any way been helpful,
On 04/03/2025 08:12, David Brown wrote:
<snip>
Originally, people /politely/ pointed out that the post was
off-topic, and the OP was unlikely to get good help here.
Indeed, I don't think anyone has been other than polite to the OP.
But there have been two people in this thread who have perhaps
been rude, arrogant and insulting - insisting that /they/ know
better than the regulars about what is topical and not topical
for the group. Those posters have not in any way been helpful,
What did you expect from them? A demonstration of competence?
On 04/03/2025 10:03, [email protected] wrote:
On Tue, 4 Mar 2025 09:57:16 +0000
Richard Heathfield <[email protected]> wibbled:
On 04/03/2025 09:23, [email protected] wrote:
because plenty of compilation issues are caused by code issues.
Undoubtedly true, and equally undoubtedly irrelevant in this
case. Were it relevant, the OP would by now have shown us the
problem code.
So what you're saying is you can't troubleshoot linking problems.
No, that's not what I'm saying. Do learn to read. What I'm saying
is that the OP would be better served by posting the problem
statement in a group more closely related to the actual problem.
We may, I trust, presume that the Python source he is building is
production code that has successfully been built before by other
people? If so, then it's not a language issue, and that is enough
to put it beyond comp.lang.c's brief.
get someone else to compile your code for you?
I tell the compiler to do it. Don't you?
Oh dear, if stuck go in circles, posted comparisons conveniently ignored.
Your inability to comprehend analogies does not stop them from
being valid illustrations of the gaping holes in your "argument"
(such as it is).
Is K&R outdated? Hmm, let me think about that for a nanosecond...
So it *is* your claim that...
that compilation no longer depends on the system you are using
and has now become a language attribute? Can you hear the
chuckles yet?
Laughing my socks off. Time to plonk, perhaps?
Wtf has the language standard got to do with anything?
Yep; time to plonk.
Bye-bye.
On Tue, 4 Mar 2025 10:25:01 +0000
Richard Heathfield <[email protected]> wibbled:
On 04/03/2025 10:03, [email protected] wrote:
On Tue, 4 Mar 2025 09:57:16 +0000
Richard Heathfield <[email protected]> wibbled:
On 04/03/2025 09:23, [email protected] wrote:
because plenty of compilation issues are caused by code issues.
Undoubtedly true, and equally undoubtedly irrelevant in this
case. Were it relevant, the OP would by now have shown us the
problem code.
So what you're saying is you can't troubleshoot linking problems.
No, that's not what I'm saying. Do learn to read. What I'm saying
Sounds like it to me.
is that the OP would be better served by posting the problem
statement in a group more closely related to the actual problem.
Well do feel free to suggest which group might be appropriate for C compilation
issues.
We may, I trust, presume that the Python source he is building is
production code that has successfully been built before by other
people? If so, then it's not a language issue, and that is enough
to put it beyond comp.lang.c's brief.
There's zero logical connection there. People experience similar issues all the time with C, should they all be denied help?
Originally, people /politely/ pointed out that the post was
off-topic, and the OP was unlikely to get good help here. Indeed, I
don't think anyone has been other than polite to the OP.
But there have been two people in this thread who have perhaps been
rude, arrogant and insulting - insisting that /they/ know better than
the regulars about what is topical and not topical for the group.
Those posters have not in any way been helpful, and are just a waste
of bandwidth for everyone else.
On 04/03/2025 11:19, [email protected] wrote:
Well do feel free to suggest which group might be appropriate for C >compilation
issues.
It wasn't a C compilation issue. That is, not a syntax error, not a type >error, and no violation of the language rules.
I've also pointed out several times (but have been conveniently ignored)
that the same error could be invoked with other languages too.
Another favourite is telling people things are off-topic. (But when it
suits them, there are long sub-threads which are wildly off-topic, not
even to do with computers, but which are deemed to be entertaining. I
guess linker errors are just not interesting enough!)
Compilation is a fundamental part of developing in C.
At the risk of sounding intolerant, I suggest that the discussion not be crossposted comp.lang.python.
On Tue, 4 Mar 2025 09:57:16 +0000
Richard Heathfield <[email protected]> wibbled:
On 04/03/2025 09:23, [email protected] wrote:
because plenty of compilation issues are caused by code issues.
Undoubtedly true, and equally undoubtedly irrelevant in this
case. Were it relevant, the OP would by now have shown us the
problem code.
So what you're saying is you can't troubleshoot linking problems. Do you
get someone else to compile your code for you?
A compiler is a compiler, a linker is a linker. Troubleshooting both is part of the development process of any competent C dev. But we know already you don't consider that to be the case because its beyond your abilities.
On Tue, 4 Mar 2025 12:27:17 +0000
bart <[email protected]> wibbled:
On 04/03/2025 11:19, [email protected] wrote:
Well do feel free to suggest which group might be appropriate for C >>compilation
issues.
It wasn't a C compilation issue. That is, not a syntax error, not a type >>error, and no violation of the language rules.
Linking is part of the compilation process.
On 2025-03-04, [email protected] <[email protected]> wrote:
On Tue, 4 Mar 2025 09:57:16 +0000
Richard Heathfield <[email protected]> wibbled:
On 04/03/2025 09:23, [email protected] wrote:
because plenty of compilation issues are caused by code issues.
Undoubtedly true, and equally undoubtedly irrelevant in this
case. Were it relevant, the OP would by now have shown us the
problem code.
So what you're saying is you can't troubleshoot linking problems. Do you
get someone else to compile your code for you?
Python is not "your code" for any value of "your" referring to any
regular here in comp.lang.c.
A compiler is a compiler, a linker is a linker. Troubleshooting both is part >> of the development process of any competent C dev. But we know already you >> don't consider that to be the case because its beyond your abilities.
Troubleshooting an open source package build problem is often a complex problem that in most cases requires direct access to the environment
where the problem is happening.
It's actually a case of porting. When Python does not build in some OS
distro with certain compilers, that's a kind of porting challenge.
On 04/03/2025 08:32, [email protected] wrote:...
On Mon, 3 Mar 2025 17:25:27 +0000
Richard Heathfield <[email protected]> wibbled:
James Kuyper has been posting here for decades, and has helped
Oh well, in that case I bow down in front of his magnificence, he must not >> be contradicted!
James would be the first to say that he should be contradicted
when he is mistaken.
And that's the point. The OP needs a local expert - i.e. someone
who has specific experience of building Python with the OP's
specific compiler.
K&R go on (on p25): "If the source program appears in several
files, you may have to say more to compile and load it than if it
all appears in one, but that is an operating system matter, not a
language attribute."
The CPython source bundle doesn't come with any makefiles. The first
step appears to be to run a 35,000-line 'configure' script. Part of its
job appears to be generate the necessary makefiles.
On Windows, CPython must be built via MSVC, not gcc.
That involving installing VS20xx, a 6GB download, which itself first
needed a 4GB .NET update. Then I needed GIT. Then SVN. Then MSBUILD
tools. Then something else...
Whatever I fixed, it always found something else to fail on. After
several hours and a lot of downloads, I gave up.
On Tue, 4 Mar 2025 18:16:25 +0000, bart wrote:
The CPython source bundle doesn't come with any makefiles. The first
step appears to be to run a 35,000-line 'configure' script. Part of its
job appears to be generate the necessary makefiles.
This is the usual GNU Autotools thing. The source from which the configure script is generated is configure.ac; you will see it makes heavy use of m4 macros.
On Windows, CPython must be built via MSVC, not gcc.
That involving installing VS20xx, a 6GB download, which itself first
needed a 4GB .NET update. Then I needed GIT. Then SVN. Then MSBUILD
tools. Then something else...
Whatever I fixed, it always found something else to fail on. After
several hours and a lot of downloads, I gave up.
If only there were a Windows equivalent to “apt-get build-dep” ...
I maintain my own scripting language. Building it from source - on
Windows - takes 70ms:
The tolerance of people on comp.lang.python ...
On 2025-03-04, Loris Bennett <[email protected]> wrote:
At the risk of sounding intolerant, I suggest that the discussion not be
crossposted comp.lang.python.
You did not do it in the best way. The way this suggestion is performed
is like this, using a built-in Usenet mechanism:
1. Keep the Newsgroups: line as-is.
1. a) Unless it contains a ridiculous number of newsgroups,
in which case consider killfiling the thread rather
than adding to it, or else trim out obviously
ridiculous newsgroup choices to get it down to three or four.
2. Add a header called "Followup-To:" to your posting which lists
the newsgroups where you would like replies to article to be
directed.
3. Mention in the article of the body that you're doing this,
for example:
"I think this discussion doesn't belong in comp.lang.python, so
I'm setting Followup-To accordingly to omit that group."
Followup-To is exactly that: a suggestion. Users agents can (and do)
prompt the user whether they want to honor Followup-To or ignore it.
Followup-To is much better than just removing newsgroups from the
Newsgroups line, because doing so fragments the thread without
warning.
Kaz Kylheku <[email protected]> writes:
On 2025-03-04, Loris Bennett <[email protected]> wrote:
At the risk of sounding intolerant, I suggest that the discussion not be >>> crossposted comp.lang.python.
You did not do it in the best way. The way this suggestion is performed
is like this, using a built-in Usenet mechanism:
1. Keep the Newsgroups: line as-is.
1. a) Unless it contains a ridiculous number of newsgroups,
in which case consider killfiling the thread rather
than adding to it, or else trim out obviously
ridiculous newsgroup choices to get it down to three or four.
2. Add a header called "Followup-To:" to your posting which lists
the newsgroups where you would like replies to article to be
directed.
3. Mention in the article of the body that you're doing this,
for example:
"I think this discussion doesn't belong in comp.lang.python, so
I'm setting Followup-To accordingly to omit that group."
Thank you for the information - I had not been aware of this possibility.
Followup-To is exactly that: a suggestion. Users agents can (and do)
prompt the user whether they want to honor Followup-To or ignore it.
Yes, my UA, Gnus, did indeed prompt me.
Followup-To is much better than just removing newsgroups from the
Newsgroups line, because doing so fragments the thread without
warning.
But will there be any difference for the newsgroup which has been
removed? If the follow-up suggestion is adhered to, the thread will
just end in the same way it would if the group had been removed from the
list of newsgroups, won't it?
The CPython source bundle doesn't come with any makefiles. The first
step appears to be to run a 35,000-line 'configure' script. Part of its
On Wed, 5 Mar 2025 01:20:07 +0000, bart wrote:
I maintain my own scripting language. Building it from source - on
Windows - takes 70ms:
How wonderful. Does it offer Python-style features?
No, it offers my-style features, that is, things I find useful:
p.x = 100
p.z = 200
You've inadvertently created a new member 'z' (it will be an attribute) >on-the-fly. Or this:
def F():
....
F = 42
It is ridiculously and dangerously dynamic.
But will there be any difference for the newsgroup which has been
removed? If the follow-up suggestion is adhered to, the thread will
just end in the same way it would if the group had been removed from the
list of newsgroups, won't it?
Frankly any build system that has a 35K configure file needs revisiting.
No package is so complex as to require that much setup.
On 05/03/2025 02:20, Lawrence D'Oliveiro wrote:
On Wed, 5 Mar 2025 01:20:07 +0000, bart wrote:
I maintain my own scripting language. Building it from source - on
Windows - takes 70ms:
How wonderful. Does it offer Python-style features?
No, it offers my-style features, that is, things I find useful:
[long list of features]
On Wed, 5 Mar 2025 09:10:21 -0000 (UTC), Muttley wrote:
Frankly any build system that has a 35K configure file needs revisiting.
No package is so complex as to require that much setup.
Feel free to “revisit” it, and let us know what can be dropped.
The code doesn’t write itself, you know.
On Wed, 5 Mar 2025 11:46:08 +0000 bart <[email protected]> wibbled:
def F():
....
F = 42
It is ridiculously and dangerously dynamic.
Python people would say thats a feature, not a bug.
On 05/03/2025 22:08, Lawrence D'Oliveiro wrote:
On Wed, 5 Mar 2025 09:10:21 -0000 (UTC), Muttley wrote:
Frankly any build system that has a 35K configure file needs
revisiting. No package is so complex as to require that much setup.
Feel free to “revisit” it, and let us know what can be dropped.
Pretty much all of it? Most of it seems to be about determining system characteristics, something you don't need to repeat for every
application you build on /the same machine/.
Besides, what is the point of determining whether a C implementation
supports 'stdio.h' for example?
In any case, the configure script is not run for every incremental
build, but there is nothing to stop the C implementation changing or
being deleted in the meantime.
The code doesn’t write itself, you know.
The configure file doesn't write the application code.
bart <[email protected]> writes:
On 05/03/2025 02:20, Lawrence D'Oliveiro wrote:
On Wed, 5 Mar 2025 01:20:07 +0000, bart wrote:
I maintain my own scripting language. Building it from source - on
Windows - takes 70ms:
How wonderful. Does it offer Python-style features?
No, it offers my-style features, that is, things I find useful:
[long list of features]
My understanding is that it is missing the two most important
features of a programming language:
(1) a user manual that defines and documents the language
(2) an available implementation so that other people can
use it to write programs
* Compile-time enumerations, and parallel tables of enums and data
* Jump-table-based 'switch' (this requires those named consts or enums)
* Built-in Support for C-style data types, including C-style structs and homogeneous array types
* Built-in FFI for C-style APIs
* Character constants: 'A' and 'ABCDEFGH' (Python needs 'ord("A")')
* Static local variables within functions
* Built-in maths functions and constants like 'pi'
* Expression-based macros
The first step appears to be to run a 35,000-line 'configure' script.
On 3/3/25 10:22, James Kuyper wrote:
On 03/03/2025 08:13, [email protected] wrote:Why is this group so intolerant?
On Sun, 2 Mar 2025 12:30:53 -0500
James Kuyper <[email protected]> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <[email protected]> gabbled:
First off, this isn't really on-topic for comp.lang.c, as it is a question
regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text.
Without computers, keyboards and monitors most C programs wouldn't be
much use, either. That doesn't make a malfunctioning computer monitor a
C problem. And it doesn't make a linkage problems a C problem either.
together programs written in many different languages. The subject line >>>> and the text of the error messages indicate that it's a Python program, >>>> so why would a group devoted to C be in any way appropriate?
If you'd taken 2 seconds to look at it you'd realise the issue was building >>> the Python source code which is written in C.
The indentations of the first message cross-posted to comp.lang.c and
comp.lang.c++ suggest that it was the latest in a series of earlier
messages posted somewhere else (comp.lang.python?). Those earlier
messages might have contained additional information. If that
information was relevant, it should have been included when the message
was first cross-posted to comp.lang.c or comp.lang.c++. You might be
right about it being "Python source code ... written in C", but nothing
in the messages that were posted here makes that obvious.
That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
geodandw <[email protected]> wrote:
On 3/3/25 10:22, James Kuyper wrote:
On 03/03/2025 08:13, [email protected] wrote:Why is this group so intolerant?
On Sun, 2 Mar 2025 12:30:53 -0500Without computers, keyboards and monitors most C programs wouldn't be
James Kuyper <[email protected]> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <[email protected]> gabbled:
First off, this isn't really on-topic for comp.lang.c, as it is a questionIs there a comp.lang.c.linker group?
regarding a linker, interacting
with the results of various options given to a specific compiler. >>>>>>
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text. >>>
much use, either. That doesn't make a malfunctioning computer monitor a
C problem. And it doesn't make a linkage problems a C problem either.
together programs written in many different languages. The subject line >>>>> and the text of the error messages indicate that it's a Python program, >>>>> so why would a group devoted to C be in any way appropriate?
If you'd taken 2 seconds to look at it you'd realise the issue was building
the Python source code which is written in C.
The indentations of the first message cross-posted to comp.lang.c and
comp.lang.c++ suggest that it was the latest in a series of earlier
messages posted somewhere else (comp.lang.python?). Those earlier
messages might have contained additional information. If that
information was relevant, it should have been included when the message
was first cross-posted to comp.lang.c or comp.lang.c++. You might be
right about it being "Python source code ... written in C", but nothing
in the messages that were posted here makes that obvious.
That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem >>> should have been shown. It's hard to debug code that you can't see.
Members of this group are quite likely old (only old people remember Usenet it seems), maybe even retired. Old people are often a bit set in their way (correcting your grammar all the time, trying to force their political
views on you, etc. etc.)
Also, programming tends to attract people that can handle highly formalized thinking, and thus also people who have OCD to a higher or lower degree. Think of them as if they were Sheldon. They probably don‘t see that their musings about topicality of your question won’t help you at all, they have simply hijacked your thread to discuss about whether linker problems are topical in this newsgroup (they could have done this in a separate thread).
I have to admit that this thread turned out to be the most interesting
since a long time, although not for OP. It’s like the ramblings of an old man that you asked about help with your spark plugs and he ends up talking about his experiences during WWII. Don‘t take offense, nod politely, and find someone who’s actually going to help you ;-)
IIRC, there are two different ways of compiling code, position dependent or position independent (PIC). Apparently you cannot mix these two kinds of
code into a single executable. So if you are using a library that has been compiled with PIC turned on, you’ll have to compile your code the same way. There should be a command line parameter/IDE setting to do so, depending on your toolchain.
On Wed, 5 Mar 2025 14:12:41 -0000 (UTC), Muttley wrote:
On Wed, 5 Mar 2025 11:46:08 +0000 bart <[email protected]> wibbled:
def F():
....
F = 42
It is ridiculously and dangerously dynamic.
Python people would say thats a feature, not a bug.
Consider that, in Python, functions and classes are themselves first-class >objects. Function and class definitions are not declarations, they are >special forms of assignment statement; while the function code is
generated at compile time, the actual creation of function and class
objects happens at runtime. If the function/class definition is executed
On 06/03/2025 06:35, Stuart Redmann wrote:
I have to admit that this thread turned out to be the most interesting
since a long time, although not for OP. It’s like the ramblings of an old >> man that you asked about help with your spark plugs and he ends up talking >> about his experiences during WWII. Don‘t take offense, nod politely, and >> find someone who’s actually going to help you ;-)
Firstly, you're talking to the wrong guy. The OP - the person who
actually needs the help - is long gone. Muttley is just the
juvenile delinquent from round the corner who likes to drop
litter in the old folks' yards.
the old folks' gardens, the very best help that Muttley could
have offered the OP is to direct him to a group that's a better
fit for the question. Or... hey... if he's so set on turning up
his noise to annoy everyone *anyway*, why not just use the air
time to answer the question himself?
On Wed, 5 Mar 2025 11:46:08 +0000, bart wrote:
* Compile-time enumerations, and parallel tables of enums and data
Python doesn’t have enumerations as a language primitive; instead, they
are implemented in a library module, written in pure Python -- it doesn’t do anything you can’t do in your own code. But it supports arbitrary attributes attached to enum instances, and subclassing of enums.
* Jump-table-based 'switch' (this requires those named consts or enums)
Does it do switched expressions? You can do those in Python.
* Character constants: 'A' and 'ABCDEFGH' (Python needs 'ord("A")')
Python also has “\u” and “\U” for Unicode.
* Built-in maths functions and constants like 'pi'
Complex arithmetic? <https://docs.python.org/3/library/cmath.html>
Hyperbolic functions? Gamma/log-gamma? <https://docs.python.org/3/library/math.html>
There’s a reason why we don’t want to build all these into the core language, since there are so many of them that are needed nowadays.
* Expression-based macros
Really only necessary if your language is not dynamic enough.
I notice no mention of coroutines or iterators. Those are quite useful nowadays.
On Tue, 4 Mar 2025 18:16:25 +0000
bart <[email protected]> wibbled:
The CPython source bundle doesn't come with any makefiles. The first
step appears to be to run a 35,000-line 'configure' script. Part of its
Frankly any build system that has a 35K configure file needs revisiting.
No package is so complex as to require that much setup. OS specific code should be dealt with some appropriate ifdefs in the source and libraries
and linking should be a few 10s of lines.
Back in the day packages used to hve different preprepared Makefiles for
each system they could build on and IME that tended to work a lot better
than configure scripts that tried to figure things out on the fly.
Compilation and runtime are the same thing in Python arn't they? Can you precompile code? I'm not an expert on the language to any extent though I
can write simple code in it.
In comp.lang.c [email protected] wrote:
On Tue, 4 Mar 2025 18:16:25 +0000
bart <[email protected]> wibbled:
The CPython source bundle doesn't come with any makefiles. The first
step appears to be to run a 35,000-line 'configure' script. Part of its
Frankly any build system that has a 35K configure file needs revisiting.
No package is so complex as to require that much setup. OS specific code
should be dealt with some appropriate ifdefs in the source and libraries
and linking should be a few 10s of lines.
Back in the day packages used to hve different preprepared Makefiles for
each system they could build on and IME that tended to work a lot better
than configure scripts that tried to figure things out on the fly.
I remember times when source package came with README file saying
edit this and that to configure for your system. Typically one
had to edit Makefile and possibly something like config.h. For
me it worked quite well. But those times are gone. Most people
now do not know essential information about system they use, so
are unable to provide sensible values. And modern programs are
bigger and more complicated, so such hand editing is too much work
for rare people capable of doing this.
Per platform Makefile-s do not scale when one wants to support
multiple system and multiple configurations (there is exponential
growth of possible combinations). And even of single configuration
for supposedly single system like Linux there are troubles.
In one project there was someting like 20 Makefile.linux_x files
where x represented one Linux flavour. Yet regularly somebody
would come and say: "build fails on my Linux x.y.z". If enough
information was provided new Makefile was added, or possibly
some similar Makefile was modified to cover more cases.
Those troubles mostly vanished when project switched to configure
script. Now there is about 1500 lines of hand written code
in configure machinery (biggest is 933 lines long configure.ac)
and 8564 lines long generated configure script. Most build
troubles is now gone or diagnosed early.
Writing "diagnosed early" I mean that most user errors are
detected quite early. For example, a lot of people try to
compile program without having a C compiler. And when they
have compiler they fail to install needed libraries (there
is list which says what is needed but people fail to follow
instructions).
It is certainly silly when generated configure file is much
bigger than actual program code. This happens frequently
when lazy or brainwashed folks use automake (which apparently
puts all checks that it knows into generated configure.ac).
But Python have reasons to check for a lot of things, so
the size is somewhat reasonable.
Compilation and runtime are the same thing in Python arn't they?
So, why doesn't the configuration script itself have a configuration
script? Will the language used in the script run on EVERY Linux and Unix system?
I remember times when source package came with README file saying edit
this and that to configure for your system. Typically one had to edit Makefile and possibly something like config.h. For me it worked quite
well. But those times are gone. Most people now do not know essential information about system they use, so are unable to provide sensible
values. And modern programs are bigger and more complicated, so such
hand editing is too much work for rare people capable of doing this.
Per platform Makefile-s do not scale when one wants to support multiple system and multiple configurations (there is exponential growth of
possible combinations).
I am 47, kind of old?
On 05/03/2025 23:36, Tim Rentsch wrote:
bart <[email protected]> writes:
On 05/03/2025 02:20, Lawrence D'Oliveiro wrote:
On Wed, 5 Mar 2025 01:20:07 +0000, bart wrote:
I maintain my own scripting language. Building it from source - on
Windows - takes 70ms:
How wonderful. Does it offer Python-style features?
No, it offers my-style features, that is, things I find useful:
[long list of features]
My understanding is that it is missing the two most important
features of a programming language:
(1) a user manual that defines and documents the language
(2) an available implementation so that other people can
use it to write programs
The 1990s version, where it supported a substantial application, had a 350-page manual. That one was used by other people to create add-on products.
But it's now a personal tool and I only have reference material for my
own use.
On 06/03/2025 02:28, Lawrence D'Oliveiro wrote:
Does it do switched expressions? You can do those in Python.
Do you mean 'match case'?
Python also has “\u” and “\U” for Unicode.
I have this:
println "\u20AC" # string (shows €)
println '\u20AC' # integer println '\u20AC':"m" # shows €
(interpret as multibyte char)
With \v used for 6-digit hex codes. But the encoding with these is UTF8,
so this is stored as a 3-byte sequence, or taking up 24 bits of an
integer.
Actually, my language started off as a DSL for my 3D graphics apps so it
had a lot of special purpose types built-in.
So if p and q were 3D points, m was a transformation matrix, and e/f
were edges (lines, arcs, circles) then:
(p + q)/2 # was the midpoint of pq
m * p # transformed the point p
intersect(e, f) # return points of interesections of e and f
I've played around with closures, generators and iterators. I decided
they were too clunky in my implementation and a poor fit for my product
and style of coding.
bart <[email protected]> writes:
On 05/03/2025 23:36, Tim Rentsch wrote:
bart <[email protected]> writes:
On 05/03/2025 02:20, Lawrence D'Oliveiro wrote:
On Wed, 5 Mar 2025 01:20:07 +0000, bart wrote:
I maintain my own scripting language. Building it from source - on >>>>>> Windows - takes 70ms:
How wonderful. Does it offer Python-style features?
No, it offers my-style features, that is, things I find useful:
[long list of features]
My understanding is that it is missing the two most important
features of a programming language:
(1) a user manual that defines and documents the language
(2) an available implementation so that other people can
use it to write programs
The 1990s version, where it supported a substantial application, had a
350-page manual. That one was used by other people to create add-on
products.
But it's now a personal tool and I only have reference material for my
own use.
If you post some links where I can download a current user
manual and a current compiler or interpreter, I will gladly
withdraw my comment.
Otherwise, I stand by my comment, and see no reason to
consider your alleged environment as anything other than
fiction-ware.
On 06/03/2025 19:21, Waldek Hebisch wrote:
In comp.lang.c [email protected] wrote:
On Tue, 4 Mar 2025 18:16:25 +0000
bart <[email protected]> wibbled:
The CPython source bundle doesn't come with any makefiles. The firstFrankly any build system that has a 35K configure file needs revisiting. >>> No package is so complex as to require that much setup. OS specific code >>> should be dealt with some appropriate ifdefs in the source and libraries >>> and linking should be a few 10s of lines.
step appears to be to run a 35,000-line 'configure' script. Part of its >>>
Back in the day packages used to hve different preprepared Makefiles for >>> each system they could build on and IME that tended to work a lot better >>> than configure scripts that tried to figure things out on the fly.
I remember times when source package came with README file saying
edit this and that to configure for your system. Typically one
had to edit Makefile and possibly something like config.h. For
me it worked quite well. But those times are gone. Most people
now do not know essential information about system they use, so
are unable to provide sensible values. And modern programs are
bigger and more complicated, so such hand editing is too much work
for rare people capable of doing this.
Per platform Makefile-s do not scale when one wants to support
multiple system and multiple configurations (there is exponential
growth of possible combinations). And even of single configuration
for supposedly single system like Linux there are troubles.
In one project there was someting like 20 Makefile.linux_x files
where x represented one Linux flavour. Yet regularly somebody
would come and say: "build fails on my Linux x.y.z". If enough
information was provided new Makefile was added, or possibly
some similar Makefile was modified to cover more cases.
Those troubles mostly vanished when project switched to configure
script. Now there is about 1500 lines of hand written code
in configure machinery (biggest is 933 lines long configure.ac)
and 8564 lines long generated configure script. Most build
troubles is now gone or diagnosed early.
Writing "diagnosed early" I mean that most user errors are
detected quite early. For example, a lot of people try to
compile program without having a C compiler. And when they
have compiler they fail to install needed libraries (there
is list which says what is needed but people fail to follow
instructions).
It is certainly silly when generated configure file is much
bigger than actual program code. This happens frequently
when lazy or brainwashed folks use automake (which apparently
puts all checks that it knows into generated configure.ac).
But Python have reasons to check for a lot of things, so
the size is somewhat reasonable.
So, why doesn't the configuration script itself have a configuration
script? Will the language used in the script run on EVERY Linux and Unix system?
If so, why doesn't the same apply to the main language of the
application? (Why isn't the application written in that language!)
I've also seen a project where the configuration program was a C file,
one which didn't need any special options, whose output was used to
build the main app.
Again, why can't the main app be made to work like the small one?
I've played with projects that had nearly 20 different makefiles, none
of which was right for my own compiler. It is a ridiculous situation.
bart <[email protected]> writes:
On 05/03/2025 23:36, Tim Rentsch wrote:
bart <[email protected]> writes:
On 05/03/2025 02:20, Lawrence D'Oliveiro wrote:
On Wed, 5 Mar 2025 01:20:07 +0000, bart wrote:
I maintain my own scripting language. Building it from source - on >>>>>> Windows - takes 70ms:
How wonderful. Does it offer Python-style features?
No, it offers my-style features, that is, things I find useful:
[long list of features]
My understanding is that it is missing the two most important
features of a programming language:
(1) a user manual that defines and documents the language
(2) an available implementation so that other people can
use it to write programs
The 1990s version, where it supported a substantial application, had a
350-page manual. That one was used by other people to create add-on
products.
But it's now a personal tool and I only have reference material for my
own use.
If you post some links where I can download a current user
manual and a current compiler or interpreter, I will gladly
withdraw my comment.
Otherwise, I stand by my comment, and see no reason to
consider your alleged environment as anything other than
fiction-ware.
On Thu, 6 Mar 2025 08:42:03 -0000 (UTC), Muttley wrote:
Compilation and runtime are the same thing in Python arn't they?
No, the code is actually compiled to bytecode, like Java and Perl do, and >UCSD Pascal did before all of them.
In comp.lang.c [email protected] wrote:
On Tue, 4 Mar 2025 18:16:25 +0000
bart <[email protected]> wibbled:
The CPython source bundle doesn't come with any makefiles. The first
step appears to be to run a 35,000-line 'configure' script. Part of its
Frankly any build system that has a 35K configure file needs revisiting.
No package is so complex as to require that much setup. OS specific code
should be dealt with some appropriate ifdefs in the source and libraries
and linking should be a few 10s of lines.
Back in the day packages used to hve different preprepared Makefiles for
each system they could build on and IME that tended to work a lot better
than configure scripts that tried to figure things out on the fly.
I remember times when source package came with README file saying
edit this and that to configure for your system. Typically one
had to edit Makefile and possibly something like config.h. For
me it worked quite well. But those times are gone. Most people
now do not know essential information about system they use, so
are unable to provide sensible values. And modern programs are
Per platform Makefile-s do not scale when one wants to support
multiple system and multiple configurations (there is exponential
growth of possible combinations). And even of single configuration
detected quite early. For example, a lot of people try to
compile program without having a C compiler. And when they
It is certainly silly when generated configure file is much
bigger than actual program code. This happens frequently
On Thu, 6 Mar 2025 19:21:45 -0000 (UTC)
[email protected] (Waldek Hebisch) wibbled:
In comp.lang.c [email protected] wrote:
On Tue, 4 Mar 2025 18:16:25 +0000
bart <[email protected]> wibbled:
The CPython source bundle doesn't come with any makefiles. The firstFrankly any build system that has a 35K configure file needs revisiting. >>> No package is so complex as to require that much setup. OS specific code >>> should be dealt with some appropriate ifdefs in the source and libraries >>> and linking should be a few 10s of lines.
step appears to be to run a 35,000-line 'configure' script. Part of its >>>
Back in the day packages used to hve different preprepared Makefiles for >>> each system they could build on and IME that tended to work a lot better >>> than configure scripts that tried to figure things out on the fly.
I remember times when source package came with README file saying
edit this and that to configure for your system. Typically one
had to edit Makefile and possibly something like config.h. For
Header files should never have to be manually edited unless the person who wrote the code didn't know wtf they were doing. #ifdef exists for a reason and if thats not enough makefiles can always manually concat stuff into a header.
me it worked quite well. But those times are gone. Most people
now do not know essential information about system they use, so
are unable to provide sensible values. And modern programs are
Those sorts of people should just install prepackaged binaries, not be building
from source.
On 07/03/2025 09:53, [email protected] wrote:
Note that if downloadeding pre-built binaries, you will usually have a >separate binary file for each platform. The same here: a separate C file
per platform.
On Thu, 6 Mar 2025 11:15:39 +0000, bart wrote:
On 06/03/2025 02:28, Lawrence D'Oliveiro wrote:
Does it do switched expressions? You can do those in Python.
Do you mean 'match case'?
That’s a generalization of the concept, but it’s a statement, not an expression.
Python also has “\u” and “\U” for Unicode.
I have this:
println "\u20AC" # string (shows €)
println '\u20AC' # integer println '\u20AC':"m" # shows € >> (interpret as multibyte char)
With \v used for 6-digit hex codes. But the encoding with these is UTF8,
so this is stored as a 3-byte sequence, or taking up 24 bits of an
integer.
I forgot about \N:
>>> print("\N{LATIN SMALL LETTER T}\N{LATIN SMALL LETTER E}\N{LATIN SMALL LETTER S}\N{LATIN SMALL LETTER T}")
test
On Fri, 7 Mar 2025 14:00:13 +0000
bart <[email protected]> wibbled:
On 07/03/2025 09:53, [email protected] wrote:
Note that if downloadeding pre-built binaries, you will usually have a
separate binary file for each platform. The same here: a separate C file
per platform.
Not sure why you think that makes things simpler. Just means you could end
up with 10x the number of files unless you have a different source package for each platform.
IIRC, there are two different ways of compiling code, position dependent or position independent (PIC). Apparently you cannot mix these two kinds of
code into a single executable. So if you are using a library that has been compiled with PIC turned on, you’ll have to compile your code the same way.
There should be a command line parameter/IDE setting to do so, depending on your toolchain
When imports are being compiled automatically to .pyc files,
their statements are being executed; like if you have a top-level print('hello'), you will see the hello output, and you will see
a .pyc file in __pycache__ for that file. Was that hello printed
after the .pyc file was produced, or during? I suspect during.
On Thu, 6 Mar 2025 21:22:19 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wibbled:
On Thu, 6 Mar 2025 08:42:03 -0000 (UTC), Muttley wrote:
Compilation and runtime are the same thing in Python arn't they?
No, the code is actually compiled to bytecode, like Java and Perl do,
and UCSD Pascal did before all of them.
If that bytecode never sees a file (though apparently it can be written
to a pyc file), how is it any different to a normal interpreter simply creating a parse tree ...
Per platform Makefile-s do not scale when one wants to support multiple system and multiple configurations (there is exponential growth of
possible combinations). And even of single configuration for supposedly single system like Linux there are troubles.
In one project there was someting like 20 Makefile.linux_x files where x represented one Linux flavour. Yet regularly somebody would come and
say: "build fails on my Linux x.y.z". If enough information was
provided new Makefile was added, or possibly some similar Makefile was modified to cover more cases.
My view is that building from source should be made as simple as
possible. As easy as compiling hello.c.
So, how about Linux? Here I don't believe in using conditional code, so
there is a special source version for Linux, let's say it's qu.c:
* No configure scripts
* No makefiles
* No #ifdef blocks
* No header files (in fact virtually no macros in the source file)
* Virtually no compiler options, except what are mandatory. Users can
add -O, -o and -s options if they want.
* And the entire distribution for your platform is a single C file
On Thu, 6 Mar 2025 19:21:45 -0000 (UTC), Waldek Hebisch wrote:
Per platform Makefile-s do not scale when one wants to support multiple
system and multiple configurations (there is exponential growth of
possible combinations). And even of single configuration for supposedly
single system like Linux there are troubles.
In one project there was someting like 20 Makefile.linux_x files where x
represented one Linux flavour. Yet regularly somebody would come and
say: "build fails on my Linux x.y.z". If enough information was
provided new Makefile was added, or possibly some similar Makefile was
modified to cover more cases.
Can you offer more details on the project in question? I ask because
there are things that can be done in GNU Makefiles to deal more
dynamically with environmental differences in some simpler cases,
without resorting to a full-on meta-build system like Autotools or
CMake, and perhaps the maintainers of this project aren’t aware of
that.
Here’s a simple example, building an extension module for Python:
CFLAGS=-g $(shell python3-config --includes) -fPIC -Wall -Wno-switch -Wno-parentheses
gxscript_lexer.so : gxscript_lexer.o
$(CC) $^ $(shell python3-config --ldflags) -shared -o $@
gxscript_lexer.o : gxscript_lexer.c
clean :
rm -f gxscript_lexer.so gxscript_lexer.o
rm -rf __pycache__
.PHONY : clean
Note how it uses the “python3-config” command to figure out the right flags (including file/directory locations) for compilation and
linking. So it doesn’t have to know that the libraries are in /usr/lib
on one system, and /usr/local/lib on another.
bart <[email protected]> writes:
[...]
I just (well, nearly 2 hours ago!) downloaded the sources for gcc. It
was 0.75GB in all, 142,000 files, 5,500 folders. There are 84,000 .c
files, and 4,600 .h files.
It took something over 90 MINUTES to unzip, using a SSD.
Whatever you downloaded, it wasn't (just) the sources for gcc.
The latest release of gcc (14.2.0) has 58503 .c files and 4131
.h files, and the gcc project does not make it available as a
.zip file. When you say "the sources for gcc", I presume you're
referring to some software package that includes gcc. Why didn't
you mention that?
On my system, unpacking gcc-14.2.0.tar.gz and gcc-14.2.0.tar.xz took
15 and 20 seconds, respectively. I created a zip file; unzipping
it took 23 seconds.
Whatever is wrong with your system, I suggest it's not topical here.
The gcc maintainers are not particularly interested in supporting
Windows
surprising that building it from source on Windows is awkward.
Complaining about it here is not useful.
I've never tried to build gcc on Windows without using some Unix-like emulation layer, so I can't help you with that (not that you asked).
I don't know whether it's possible.
On 07/03/2025 20:15, Keith Thompson wrote:
bart <[email protected]> writes:
[...]
I just (well, nearly 2 hours ago!) downloaded the sources for gcc. It
was 0.75GB in all, 142,000 files, 5,500 folders. There are 84,000 .c
files, and 4,600 .h files.
It took something over 90 MINUTES to unzip, using a SSD.
Whatever you downloaded, it wasn't (just) the sources for gcc.
The latest release of gcc (14.2.0) has 58503 .c files and 4131
.h files, and the gcc project does not make it available as a
.zip file. When you say "the sources for gcc", I presume you're
referring to some software package that includes gcc. Why didn't
you mention that?
It was from here:
https://github.com/gcc-mirror/gcc
The ZIP file is the one you get on the '<> Code' pulldown menu. You get
that on every project, whether it targets Windows or not.
So how does 'python3-config' know where this stuff is?
bart <[email protected]> writes:
On 07/03/2025 20:15, Keith Thompson wrote:
bart <[email protected]> writes:
[...]
I just (well, nearly 2 hours ago!) downloaded the sources for gcc. ItWhatever you downloaded, it wasn't (just) the sources for gcc.
was 0.75GB in all, 142,000 files, 5,500 folders. There are 84,000 .c
files, and 4,600 .h files.
It took something over 90 MINUTES to unzip, using a SSD.
The latest release of gcc (14.2.0) has 58503 .c files and 4131
.h files, and the gcc project does not make it available as a
.zip file. When you say "the sources for gcc", I presume you're
referring to some software package that includes gcc. Why didn't
you mention that?
It was from here:
https://github.com/gcc-mirror/gcc
The ZIP file is the one you get on the '<> Code' pulldown menu. You
get that on every project, whether it targets Windows or not.
I've no idea where the official gcc source code resides. Googling
'github cpython' worked for that product; this was the first hit for
'github gcc'.
So you just assumed that's official.
Someone else has already replied and told you where the official gcc
source code resides.
You assumed it's on GitHub. It isn't. Not everything is. The GNU
project does its own hosting. Somebody apparently decided to set up a
mirror on GitHub, but I wouldn't rely on it. And it might not be up to
date with the official gcc git (not GitHub) repository (though it
appears that it is).
That zip file is the latest version on the "master" branch, *not* a
release. It isn't necessarily stable. But if your goal in downloading
and extracting it was to make a point yet again about how difficult it
is for you, I suppose that doesn't matter.
If you wanted the gcc sources for a given release, it would be better to download a .tar.gz or .tar.xz file from an official mirror, which you
can find via gcc.gnu.org. GitHub's zip download feature just gives you
a snapshot of the repo, *not* an official release. A build procedure
that works with an official tarball might not work with a git snapshot,
for reasons I won't go into here.
[...]
The gcc maintainers are not particularly interested in supporting
Windows
And yet gcc exists on Windows.
Yes.
The big thing everybody lauds gcc for is the range of targets it
supports. But not supporting that obscure target called Win64-x64 is
fine!
It's fine with me. If it's not fine with you, complaining about it here
is unproductive and off topic. (And a "target" is the system for which
gcc generates code, not necessarily the system on which gcc runs.)
bart <[email protected]> wrote:
On 06/03/2025 19:21, Waldek Hebisch wrote:
In comp.lang.c [email protected] wrote:
On Tue, 4 Mar 2025 18:16:25 +0000
bart <[email protected]> wibbled:
The CPython source bundle doesn't come with any makefiles. The first >>>>> step appears to be to run a 35,000-line 'configure' script. Part of its >>>>Frankly any build system that has a 35K configure file needs revisiting. >>>> No package is so complex as to require that much setup. OS specific code >>>> should be dealt with some appropriate ifdefs in the source and libraries >>>> and linking should be a few 10s of lines.
Back in the day packages used to hve different preprepared Makefiles for >>>> each system they could build on and IME that tended to work a lot better >>>> than configure scripts that tried to figure things out on the fly.
I remember times when source package came with README file saying
edit this and that to configure for your system. Typically one
had to edit Makefile and possibly something like config.h. For
me it worked quite well. But those times are gone. Most people
now do not know essential information about system they use, so
are unable to provide sensible values. And modern programs are
bigger and more complicated, so such hand editing is too much work
for rare people capable of doing this.
Per platform Makefile-s do not scale when one wants to support
multiple system and multiple configurations (there is exponential
growth of possible combinations). And even of single configuration
for supposedly single system like Linux there are troubles.
In one project there was someting like 20 Makefile.linux_x files
where x represented one Linux flavour. Yet regularly somebody
would come and say: "build fails on my Linux x.y.z". If enough
information was provided new Makefile was added, or possibly
some similar Makefile was modified to cover more cases.
Those troubles mostly vanished when project switched to configure
script. Now there is about 1500 lines of hand written code
in configure machinery (biggest is 933 lines long configure.ac)
and 8564 lines long generated configure script. Most build
troubles is now gone or diagnosed early.
Writing "diagnosed early" I mean that most user errors are
detected quite early. For example, a lot of people try to
compile program without having a C compiler. And when they
have compiler they fail to install needed libraries (there
is list which says what is needed but people fail to follow
instructions).
It is certainly silly when generated configure file is much
bigger than actual program code. This happens frequently
when lazy or brainwashed folks use automake (which apparently
puts all checks that it knows into generated configure.ac).
But Python have reasons to check for a lot of things, so
the size is somewhat reasonable.
So, why doesn't the configuration script itself have a configuration
script? Will the language used in the script run on EVERY Linux and Unix
system?
Depends on meaning of EVERY, Linux and Unix. If you mean just
Linux kernel, then it was possible to set up Linux kernel +
system without normal shell. Since there is no shell, shell
script will not run. IIUC first version of Unix from Bell Labs
had significantly different shell, incompatible with modern ones.
But if we take normal Linux distributions or for example
Android or Unices that are not long obsolete then mostly yes.
I wrote mostly because shell code generated by Autoconf macros
is very portable. There is good chance that what automake
produces is very portable too. However, when using hand
written configure.ac there is hand written shell code inside.
In the case I mention above it is probably about 400-500 lines
of hand written shell code. Such hand written code is as portable
as its author make it. Which sometimes means quite unportable.
In this case all I can say that nobody reported any trouble
with shell code.
If so, why doesn't the same apply to the main language of the
application? (Why isn't the application written in that language!)
You like benchmarks, so try some benchmarks of speed of shell
programs. Or believe me that for computational problems shell
programs are dog slow (of order of 100 times slower than normal
interpreted languages like Python).
Portable shell programs may be rather verbose and ugly (I hope
you agree that typical configure script are verbose and
and ugly).
Despite of the above, historically there were applications
written as shell programs. In open source world they
were not frequent but existed.
I've also seen a project where the configuration program was a C file,
one which didn't need any special options, whose output was used to
build the main app.
Yes, that is a possiblity. Some time ago I was thinking about
similar thing. Basically, configure scripts are slow, ugly and
long due to limitations of shell and need to work with "any"
shell. Could we write resonably small "better shell" to
execute simpler version of configure script?
I am not sure
if this would work well, basically pre-computations are easy
to do in C code, but typical configure must do several tests
and this means using various system interfaces. System
interfaces vary from system to system and detecting
available system interfaces is part of configure job.
One could try to depend on Posix interfaces, they are
available on many systems. But shell is part of Posix
and may be availble on systems which do not provide
Posix interface at C level. So it is not clear if C based
configuration program would simplify things.
Again, why can't the main app be made to work like the small one?
Modern applications depend on libraries. Let me mention a dll
for Windows that I created many years ago. My own code was
about 2000 (wc) lines of code, part of it numeric code that
provided main functionality (image transformation), rest was
glue code to the libraries. Input data came from .tiff files
and I used libtiff to read them. I needed some geometry code
which I found on the net. I needed linear equation solver,
that I got from Lapack. So there were 4 libraries (3 that
I used directly and libjpeg used by libtiff), and most
code in "my" dll actually came from the other libraries.
In this dll was doing rather special thing used as a part
of bigger process. In modern times application like gimp
connects several things of similar complexity. There is
a lot of image formats, so many libraries just to read and
write graphic files. I did not look at gimp build process,
but at configure stage is must verify if all needed libraries
(probably tens if not more) are present. Libraries need to be
in sufficiently new versions and export needed functionality
(libraries frequently may be compiled skipping part of
functionality). I am pretty sure that parts of gimp are
optional, that is you may include or skip them. And some
other projects may wish to use parts of gimp, so build
probaly created quite a few of libraries (that is separate
things that need to be linked).
In modern times applications are supposed to be internationalized.
That is various messages should appear in selected language.
Normal practise in modern times is to have separate build
step to expract english messages from source files and
create connetion to translations. That alone means that
build is more complex than simply compiling C files.
[email protected] (Scott Lurndal) writes:
bart <[email protected]> writes:[...]
It was from here:
https://github.com/gcc-mirror/gcc
The ZIP file is the one you get on the '<> Code' pulldown menu. You get >>>that on every project, whether it targets Windows or not.
You're downloading the entire flippin' GIT repository. Every version of
gcc. You surely don't want that.
No, he downloaded a zip of the current version. He'd get the entire
repo only if he did a "git clone".
(Downloading a zip of the current version is a GitHub feature, not a git feature.)
The big thing everybody lauds gcc for is the range of targets itfine!
supports. But not supporting that obscure target called Win64-x64 is
On 07/03/2025 14:09, [email protected] wrote:
On Fri, 7 Mar 2025 14:00:13 +0000
bart <[email protected]> wibbled:
On 07/03/2025 09:53, [email protected] wrote:
Note that if downloadeding pre-built binaries, you will usually have a
separate binary file for each platform. The same here: a separate C file >>> per platform.
Not sure why you think that makes things simpler. Just means you could end >> up with 10x the number of files unless you have a different source package >> for each platform.
Sure, because downloading the source code for all conceivable platforms
is so simple!
I haven't started to look at what's involved in building it for Windows >Actually I haven't got a clue how to go about it. Neither do I know how
long it might take.
Is this what you mean by 'simpler'?
bart <[email protected]> writes:
[...]
You do know this was just an example of a ginormous application with
an overwhelming number of source files? Any app could have done
really.
Yes, gcc has a lot of source files. I don't think anyone here would
have disagreed with that. There was no need to go into details (with incomplete information) or tell us how slow something is on your
system.
On Fri, 7 Mar 2025 18:02:23 +0000
bart <[email protected]> gabbled:
On 07/03/2025 14:09, [email protected] wrote:
On Fri, 7 Mar 2025 14:00:13 +0000
bart <[email protected]> wibbled:
On 07/03/2025 09:53, [email protected] wrote:
Note that if downloadeding pre-built binaries, you will usually have a >>>> separate binary file for each platform. The same here: a separate C
file
per platform.
Not sure why you think that makes things simpler. Just means you
could end
up with 10x the number of files unless you have a different source
package
for each platform.
Sure, because downloading the source code for all conceivable
platforms is so simple!
Huh?
I haven't started to look at what's involved in building it for
Windows Actually I haven't got a clue how to go about it. Neither do I
know how long it might take.
Is this what you mean by 'simpler'?
Err, no idea what you're talking about. Perhaps you didn't read what I
wrote properly. The simple solution is to have a single package for all OSs
which has a load of ifdefs in the code itself and the user doesn'thave to
do anything except pick the correct makefile or for windows project file.
On 08/03/2025 07:19, Keith Thompson wrote:
bart <[email protected]> writes:
[...]
You do know this was just an example of a ginormous application with
an overwhelming number of source files? Any app could have done
really.
Yes, gcc has a lot of source files. I don't think anyone here would
have disagreed with that. There was no need to go into details (with
incomplete information) or tell us how slow something is on your
system.
Jesus, what is your problem?
My idea is similar to supplying binaries, but replacing each binary file
with one C source file. This now needs a C compiler to turn into a
binary, but nothing else. No configure, no makefiles, virtually no
special options, no special compiler needed and no special version.
which has a load of ifdefs in the code itself and the user doesn'thave to
do anything except pick the correct makefile or for windows project file.
I suspect you either haven't done much building of open source software
on Windows, or were remarkably lucky.
On Sat, 8 Mar 2025 14:09:17 +0000
bart <[email protected]> gabbled:
My idea is similar to supplying binaries, but replacing each binary
file with one C source file. This now needs a C compiler to turn into
a binary, but nothing else. No configure, no makefiles, virtually no
special options, no special compiler needed and no special version.
So instead of just typing "make" the user has to know how to invoke the compiler, possibly with certain switches set. Not sure how thats any
better.
which has a load of ifdefs in the code itself and the user doesn'thave to
do anything except pick the correct makefile or for windows projectfile.
I suspect you either haven't done much building of open source
software on Windows, or were remarkably lucky.
True. I've done a small amount of C/C++ dev on Windows but these days I wouldn't touch it with a 10 foot pole and rubber gloves.
GCC contains support for x86-64 using the mingw-w64 runtime
library, available from https://www.mingw-w64.org/downloads/. This
library should be used with the target triple x86_64-pc-mingw32.
On Fri, 07 Mar 2025 12:15:42 -0800
Keith Thompson <[email protected]> wrote:
GCC contains support for x86-64 using the mingw-w64 runtime
library, available from https://www.mingw-w64.org/downloads/. This
library should be used with the target triple x86_64-pc-mingw32.
The gcc compiler that I use on Windows most of the time has different tripple: x86_64-w64-mingw32
It is a native Window program for AMD64 (a.k.a. x86_64) architecture
that generates likewise objects/exe.
I am not sure about the meaning of the 3rd part of the triple.
Have you ever played around with vcpkg? Works pretty darn good with
MSVC:
On 3/8/2025 10:15 AM, bart wrote:
'MinGW' supposedly 'Minimalist Gnu on Windows'. In that case I wouldn't
like to see the full-scale one..
cygwin is okay, well it's been a while since I used it... :^)
https://www.cygwin.com
What Make does is take a mountain of complexity called a 'makefile',
which is special kind of arcane language, and tries to run it. It might
work, it might fail immediately, or it might grind away for several
minutes and then it stops.
On Sat, 8 Mar 2025 13:13:07 -0800, Chris M. Thomasson wrote:
On 3/8/2025 10:15 AM, bart wrote:
'MinGW' supposedly 'Minimalist Gnu on Windows'. In that case I
wouldn't like to see the full-scale one..
cygwin is okay, well it's been a while since I used it... :^)
https://www.cygwin.com
Cygwin is clever. They managed to get poll/select working on pipes,
which is something Microsoft still cannot manage on native Windows.
cygwin is very slow.
For me the speed and UI convinience are far more important than better emulation of obscure POSIX features which is probably important only for programs that I would not want to run regardless.
On 08/03/2025 15:51, [email protected] wrote:
On Sat, 8 Mar 2025 14:09:17 +0000
bart <[email protected]> gabbled:
My idea is similar to supplying binaries, but replacing each binary
file with one C source file. This now needs a C compiler to turn into
a binary, but nothing else. No configure, no makefiles, virtually no
special options, no special compiler needed and no special version.
So instead of just typing "make" the user has to know how to invoke the
compiler, possibly with certain switches set. Not sure how thats any
better.
I've just typed 'make' in a Windows prompt. Nothing happens ('command
not recognised'). That's a good start!
So according to you, this should be a piece of piss. OK, I'll try it:
On Sat, 8 Mar 2025 16:46:14 +0000
bart <[email protected]> wibbled:
On 08/03/2025 15:51, [email protected] wrote:
On Sat, 8 Mar 2025 14:09:17 +0000
bart <[email protected]> gabbled:
My idea is similar to supplying binaries, but replacing each
binary file with one C source file. This now needs a C compiler
to turn into a binary, but nothing else. No configure, no
makefiles, virtually no special options, no special compiler
needed and no special version.
So instead of just typing "make" the user has to know how to
invoke the compiler, possibly with certain switches set. Not sure
how thats any better.
I've just typed 'make' in a Windows prompt. Nothing happens
('command not recognised'). That's a good start!
I'm not particularly interested in windows development. Microsoft
seems to have made it as complicated as possibly with its ridiculous overcomplicated project files. From a unix POV all I want to do if
I'm building a package from source is to type "make" after selecting
the correct makefile.
So according to you, this should be a piece of piss. OK, I'll try
it:
I'm not really interested in your straw men.
On Sun, 9 Mar 2025 01:26:26 +0200, Michael S wrote:
cygwin is very slow.
I’m sure it is. ;)
For me the speed and UI convinience are far more important than
better emulation of obscure POSIX features which is probably
important only for programs that I would not want to run
regardless.
Unfortunately select/poll are a key part of efficient event-driven programming. In the 1990s (the heyday of Windows NT) they tried to
handle all of this with threads, only to discover that, unless you
were doing something heavily CPU-bound, the programming complexity
just wasn’t worth it.
Yes, it does not work directly with anonymous files. But anonymous
file can be treated as a special version of named pipe and then it
does work.
On Sun, 9 Mar 2025 08:47:28 -0000 (UTC)
[email protected] wrote:
On Sat, 8 Mar 2025 16:46:14 +0000
bart <[email protected]> wibbled:
On 08/03/2025 15:51, [email protected] wrote:
On Sat, 8 Mar 2025 14:09:17 +0000
bart <[email protected]> gabbled:
My idea is similar to supplying binaries, but replacing each
binary file with one C source file. This now needs a C compiler
to turn into a binary, but nothing else. No configure, no
makefiles, virtually no special options, no special compiler
needed and no special version.
So instead of just typing "make" the user has to know how to
invoke the compiler, possibly with certain switches set. Not sure
how thats any better.
I've just typed 'make' in a Windows prompt. Nothing happens
('command not recognised'). That's a good start!
I'm not particularly interested in windows development. Microsoft
seems to have made it as complicated as possibly with its ridiculous
overcomplicated project files. From a unix POV all I want to do if
I'm building a package from source is to type "make" after selecting
the correct makefile.
So according to you, this should be a piece of piss. OK, I'll try
it:
I'm not really interested in your straw men.
Pay attention that all this slow, complicated 'configure' business
didn't originate on Windows. It was invented in order to cover variety
of Unixen. Which (variety) no longer exists, but religious 'free
software' people like to pretend that it is still relevant and continue
to use configure.
On Fri, 7 Mar 2025 14:00:13 +0000, bart wrote:
My view is that building from source should be made as simple as
possible. As easy as compiling hello.c.
For nontrivial open-source projects, that cannot be done without some help from the operating system. We have already seen, from your struggles with
the Python source, how proprietary OSes like Microsoft Windows seem to go
out of their way to make things difficult for users to build things.
The whole design of Unix from the beginning was not to impose artificial distinctions between “users” and “programmers”. Indeed, *nix systems allow
for a whole spectrum of usage patterns with different levels of automation
in them, from point-and-click GUIs, through scripting languages, to full-
on compile-link build workflows.
So, how about Linux? Here I don't believe in using conditional code, so
there is a special source version for Linux, let's say it's qu.c:
That’s bad. Now you have to maintain two parallel sets of source.
* No configure scripts
* No makefiles
* No #ifdef blocks
* No header files (in fact virtually no macros in the source file)
* Virtually no compiler options, except what are mandatory. Users can
add -O, -o and -s options if they want.
* And the entire distribution for your platform is a single C file
All at the expense of requiring more work from the human developers/ maintainers.
Those of us who are accustomed to *nix systems consider the computer as a tool to lift the burden of the hard work from us, not to make more work
for us.
Seems like Microsoft Windows inculcates a different attitude ...
On Sat, 8 Mar 2025 16:46:14 +0000, bart wrote:
What Make does is take a mountain of complexity called a 'makefile',
which is special kind of arcane language, and tries to run it. It might
work, it might fail immediately, or it might grind away for several
minutes and then it stops.
All too common with Windows, I’m afraid.
I remember when the LibreOffice project was set up as a fork from the moribund OpenOffice, there was a blog post reporting on initial progress, from Michael Meeks I think it was, saying that the Windows build still suffered from mysterious intermittent failures, such that retrying the
build would usually succeed.
That kind of thing is unheard of on proper *nix systems.
select/poll is the one way to do event-driven programming.
There are other ways.
In particular, under Windows you can
simultaneously wait for multiple objects with API that is called...
Surprise! WaitForMultipleObjects.
If it's not enough, I would guess that if one wants ultimate
scalability, one can force named pipes into working with I/O completion ports, which is as scalable as one could wish.
Cygwin is clever. They managed to get poll/select working on pipes,
which is something Microsoft still cannot manage on native Windows.
cygwin is very slow.
And user interface is significantly inferior
relatively to msys2/mingw64. Or at least it was in 2018 which happens
to be the version of cygwin that I am using regularly as part of
Altera/Intel Nios2 SDK.
For me the speed and UI convinience are far more important than better emulation of obscure POSIX features which is probably important only
for programs that I would not want to run regardless.
On Sun, 9 Mar 2025 02:30:37 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wrote:
On Sun, 9 Mar 2025 01:26:26 +0200, Michael S wrote:
=20
cygwin is very slow. =20=20
I=E2=80=99m sure it is. ;)
=20
For me the speed and UI convinience are far more important than=20
better emulation of obscure POSIX features which is probably
important only for programs that I would not want to run
regardless. =20
Unfortunately select/poll are a key part of efficient event-driven=20
programming. In the 1990s (the heyday of Windows NT) they tried to
handle all of this with threads, only to discover that, unless you
were doing something heavily CPU-bound, the programming complexity
just wasn=E2=80=99t worth it.
select/poll is the one way to do event-driven programming.
There are other ways. In particular, under Windows you can
simultaneously wait for multiple objects with API that is called...
Surprise! WaitForMultipleObjects.
select/poll is the one way to do event-driven programming.
There are other ways.
In particular, under Windows you can simultaneously wait for
multiple objects with API that is called... Surprise!
WaitForMultipleObjects.
Yes, it does not work directly with anonymous files. But anonymous file
can be treated as a special version of named pipe and then it does work.
It's more likely that they don't even think about it.
They only get vocal when it is necessary to build on a non-Unix
environment and complain that it is rubbish because all that baggage is missing.
Pay attention that all this slow, complicated 'configure' business
didn't originate on Windows.
It was invented in order to cover variety of Unixen. Which (variety)
no longer exists, but religious 'free software' people like to
pretend that it is still relevant and continue to use configure.
On Sun, 9 Mar 2025 12:16:56 +0000, bart wrote:
It's more likely that they don't even think about it.
Feel free to supply the thinking you think (heh) is missing. It’s all Open Source, after all.
They only get vocal when it is necessary to build on a non-Unix
environment and complain that it is rubbish because all that baggage is
missing.
No, you were the one complaining about not being able to get a build to
work on Windows.
And this for a package which is known to build on
Windows.
On 3/8/2025 6:30 PM, Lawrence D'Oliveiro wrote:
On Sun, 9 Mar 2025 01:26:26 +0200, Michael S wrote:
cygwin is very slow.
I’m sure it is. ;)
For me the speed and UI convinience are far more important than
better emulation of obscure POSIX features which is probably
important only for programs that I would not want to run
regardless.
Unfortunately select/poll are a key part of efficient event-driven
programming. In the 1990s (the heyday of Windows NT) they tried to
handle all of this with threads, only to discover that, unless you
were doing something heavily CPU-bound, the programming complexity
just wasn’t worth it.
IOCP on WinNT 4.0. Well, I used to use it a lot. Worked well. Way back
in early 2000's.
https://learn.microsoft.com/en-us/windows/win32/fileio/i-o-completion-ports
On 3/8/2025 2:59 PM, Lawrence D'Oliveiro wrote:
On Sat, 8 Mar 2025 13:14:00 -0800, Chris M. Thomasson wrote:
Have you ever played around with vcpkg? Works pretty darn good with
MSVC:
Only mentions about 2500 library dependencies that they will manage for
you.
I suppose that’s all that’s available on Windows ...
Better than zero? ;^D
On 3/9/2025 6:39 PM, Lawrence D'Oliveiro wrote:
On Sun, 9 Mar 2025 16:50:22 -0700, Chris M. Thomasson wrote:
IOCP on WinNT 4.0. Well, I used to use it a lot. Worked well. Way backSame limitation: note they mention named pipes, but not unnamed ones.
in early 2000's.
https://learn.microsoft.com/en-us/windows/win32/fileio/i-o-completion-ports >>
No pipes. Sockets.
Now, iirc, the client version limited IOCP to only four? in flight, concurrent, TransmitFile calls at a time? The server version did no
do that...
On Sun, 9 Mar 2025 08:47:28 -0000 (UTC)
[email protected] wrote:
So according to you, this should be a piece of piss. OK, I'll try
it:
I'm not really interested in your straw men.
Pay attention that all this slow, complicated 'configure' business
didn't originate on Windows. It was invented in order to cover variety
of Unixen. Which (variety) no longer exists, but religious 'free
portable between 4 operation systems and 2 CPU architectures that still
I think nobody does. There's always been some sort of mystique
surrounding 'gcc' on Windows.
'MinGW' supposedly 'Minimalist Gnu on Windows'. In that case I wouldn't
like to see the full-scale one..
On 08/03/2025 15:51, [email protected] wrote:
On Sat, 8 Mar 2025 14:09:17 +0000
bart <[email protected]> gabbled:
My idea is similar to supplying binaries, but replacing each binary
file with one C source file. This now needs a C compiler to turn into
a binary, but nothing else. No configure, no makefiles, virtually no
special options, no special compiler needed and no special version.
So instead of just typing "make" the user has to know how to invoke the
compiler, possibly with certain switches set. Not sure how thats any
better.
I've just typed 'make' in a Windows prompt. Nothing happens ('command
not recognised'). That's a good start!
If I look at my gcc binaries, there's a program called
'mingw32-make.exe'. Maybe that's the one. However, build instructions
call for 'make' so it will immediately fail.
What Make does is take a mountain of complexity called a 'makefile',
which is special kind of arcane language, and tries to run it. It might
work, it might fail immediately, or it might grind away for several
minutes and then it stops.
Why I am aiming for is to be able to just type:
gcc prog.c
But apparently that won't do. Some smart-arses will point out that
that's more typing than 'make'. Others, less smart, don't actually know
how to directly invoke a compiler like this.
Now, it's been a while since I've argued about makefiles and all their
woes. But maybe things have changed. If I copy that file above to
'make.exe', and navigate to a folder full of Lua source files, I see it
also has this:
c:\luac>dir make*
02/02/2024 13:18 7,722 Makefile
So according to you, this should be a piece of piss. OK, I'll try it:
c:\luac>make
makefile:103: target 'AIX' given more than once in the same rule
makefile:117: target 'FreeBSD' given more than once in the same rule
Guessing `uname`
make[1]: Entering directory 'c:/luac'
makefile:103: target 'AIX' given more than once in the same rule
makefile:117: target 'FreeBSD' given more than once in the same rule
make[1]: *** No rule to make target '`uname`'. Stop.
make[1]: Leaving directory 'c:/luac'
make: *** [makefile:101: guess] Error 2
That went well! Maybe this is the wrong one, and I've been messing about
with these files. So I download a fresh Lua versiom as a .tar.gz file
and install it. Yes, there were in fact two makefiles, one in a higher directory level:
c:\ll\lua-5.4.7>dir
13/06/2024 22:16 <DIR> .
08/03/2025 16:15 <DIR> ..
13/06/2024 22:16 <DIR> doc
08/05/2024 21:47 3,150 Makefile
13/06/2024 22:16 151 README
13/06/2024 22:15 <DIR> src
I now follow the instructions from here:
https://www.lua.org/download.html and do this:
c:\ll\lua-5.4.7>make all test
make[1]: Entering directory 'c:/ll/lua-5.4.7/src'
makefile:101: target 'AIX' given more than once in the same rule
makefile:115: target 'FreeBSD' given more than once in the same rule
.....
make[2]: Leaving directory 'c:/ll/lua-5.4.7/src'
make[1]: *** [makefile:99: guess] Error 2
make[1]: Leaving directory 'c:/ll/lua-5.4.7/src'
make: *** [makefile:55: guess] Error 2
Oh dear, that hasn't worked either.
Or I could just build Lua the easy way:
c:\ll\lua-5.4.7\src>del luac.c
c:\ll\lua-5.4.7\src>gcc *.c -o lua
c:\ll\lua-5.4.7\src>lua
Lua 5.4.7 Copyright (C) 1994-2024 Lua.org, PUC-Rio
>
This works! No crappy makefiles needed. Here I happened to know it
involves compiling 33 of the 34 C files supplied (luac.c is for embedded
I think).
The makefiles are full of useless dependency info. Lua is a small
program, and I just want to use it, not develop it.
Pay attention that all this slow, complicated 'configure' business
didn't originate on Windows. It was invented in order to cover variety
of Unixen. Which (variety) no longer exists, but religious 'free
software' people like to pretend that it is still relevant and continue
to use configure.
On Sun, 9 Mar 2025 11:28:07 +0200, Michael S wrote:
select/poll is the one way to do event-driven programming.
Yes it is.
There are other ways.
But you just said ...
In particular, under Windows you can simultaneously wait for
multiple objects with API that is called... Surprise! WaitForMultipleObjects.
So, just select/poll under another name, then.
It really is “the one
way to do event-driven programming”. Only with the usual Windows
approach of added clunkiness.
Yes, it does not work directly with anonymous files. But anonymous
file can be treated as a special version of named pipe and then it
does work.
I don’t think that makes sense. Otherwise the problem wouldn’t exist.
On Thu, 6 Mar 2025 19:21:45 -0000 (UTC), Waldek Hebisch wrote:
Per platform Makefile-s do not scale when one wants to support multiple
system and multiple configurations (there is exponential growth of
possible combinations). And even of single configuration for supposedly
single system like Linux there are troubles.
In one project there was someting like 20 Makefile.linux_x files where x
represented one Linux flavour. Yet regularly somebody would come and
say: "build fails on my Linux x.y.z". If enough information was
provided new Makefile was added, or possibly some similar Makefile was
modified to cover more cases.
Can you offer more details on the project in question? I ask because
there are things that can be done in GNU Makefiles to deal more
dynamically with environmental differences in some simpler cases,
without resorting to a full-on meta-build system like Autotools or
CMake, and perhaps the maintainers of this project aren’t aware of
that.
Similar to poll(), yes. Not so similar to super-ugly select(). I hope
that Unix people stopped using select in new programs two or more
decades ago.
On Mon, 10 Mar 2025 15:20:00 +0200
Michael S <[email protected]> wibbled:
Similar to poll(), yes. Not so similar to super-ugly select(). I hope
that Unix people stopped using select in new programs two or more
decades ago.
Nothing wrong with select if you're not multiplexing hundreds of file >descriptors. Does the job.
bart <[email protected]> wrote:
I think nobody does. There's always been some sort of mystique
surrounding 'gcc' on Windows.
'MinGW' supposedly 'Minimalist Gnu on Windows'. In that case I wouldn't
like to see the full-scale one..
"Minimalist" is not about size of the compiler. Rather, it is
about possible support routines. For "hosted implementation" C
mandates presence of C library and there is a lot of functions
not in C standard, but included in libraries of C compilers.
There is also question of operating system support, complicated
by fact that Windows is different than other systems. Cygwin
solved those issues by offering Posix emulation and a sizable
collection os libraries. MinGW is minimalist in the sense
that it provides very little own libraries and mainly uses
what is provide by Windows.
To put it differenly, you could compile program in one computer
and get relatively small program which runs OK on different
Windows machines because libraries it needs are already present.
This is quite different compared to Cygwin, where you need to
install Cygwin libraries before normal Cygwin program can run
(I write about normal programs because actual compiler in
Cygwin and Mingw used to be the same and with some tweaks one
could use Cygwin compiler to produce MinGW execuatbles).
On 10/03/2025 10:58, Waldek Hebisch wrote:
bart <[email protected]> wrote:
I think nobody does. There's always been some sort of mystique
surrounding 'gcc' on Windows.
'MinGW' supposedly 'Minimalist Gnu on Windows'. In that case I wouldn't
like to see the full-scale one..
"Minimalist" is not about size of the compiler. Rather, it is
about possible support routines. For "hosted implementation" C
mandates presence of C library and there is a lot of functions
not in C standard, but included in libraries of C compilers.
There is also question of operating system support, complicated
by fact that Windows is different than other systems. Cygwin
solved those issues by offering Posix emulation and a sizable
collection os libraries. MinGW is minimalist in the sense
that it provides very little own libraries and mainly uses
what is provide by Windows.
I still don't get this stuff.
I get the impression that a port of gcc to Windows is not simply about >building C programs, but building C programs that use a lot of features
from Linux.
If so, then that's the wrong approach. There are various lesser
compilers which know nothing about mingw or posix of anything of the
sort. (For example, lccwin32, DMC, PellesC, I think Tiny C; I can't
speak for MSVC.)
bart <[email protected]> writes:
On 10/03/2025 10:58, Waldek Hebisch wrote:
bart <[email protected]> wrote:
I think nobody does. There's always been some sort of mystique
surrounding 'gcc' on Windows.
'MinGW' supposedly 'Minimalist Gnu on Windows'. In that case I wouldn't >>>> like to see the full-scale one..
"Minimalist" is not about size of the compiler. Rather, it is
about possible support routines. For "hosted implementation" C
mandates presence of C library and there is a lot of functions
not in C standard, but included in libraries of C compilers.
There is also question of operating system support, complicated
by fact that Windows is different than other systems. Cygwin
solved those issues by offering Posix emulation and a sizable
collection os libraries. MinGW is minimalist in the sense
that it provides very little own libraries and mainly uses
what is provide by Windows.
I still don't get this stuff.
Sure you do. You just like to complain.
I get the impression that a port of gcc to Windows is not simply about
building C programs, but building C programs that use a lot of features >>from Linux.
C was written for Unix.
A large amount of existing C requires
unix semantics. It would be pointless to port gcc to windows without supporting the vast majority of existing C code.
[email protected] writes:
On Mon, 10 Mar 2025 15:20:00 +0200
Michael S <[email protected]> wibbled:
Similar to poll(), yes. Not so similar to super-ugly select(). I hope >>>that Unix people stopped using select in new programs two or more
decades ago.
Nothing wrong with select if you're not multiplexing hundreds of file >>descriptors. Does the job.
The primary constraint for select(2) is not the _number_ of files
that can be selected amongst (although that _is_ a constraint),
but rather the largest file descriptor number is limited by the
select(2) bitmap interface (FD_SETSIZE not only defines the number
of file descriptors that can be passed, but also the highest
valued file descriptor that can be passed). poll(2) has no
such limits.
bart <[email protected]> wrote:
Oh dear, that hasn't worked either.
Hmm, it AFAICS worked. That is you wanted build failure and you
got build failure.
Of course you are an export on building
Windows programs and have your tricks. In this case a simple
one, like not having MinGW tools in the patch probably will do.
This works! No crappy makefiles needed. Here I happened to know it
involves compiling 33 of the 34 C files supplied (luac.c is for embedded
I think).
Not reading instructions help in writing newsgroup post. If you
read documentation you would see that build process is supposed to
build 3 related products: Lua library, Lua interpreter and Lua
compiler (whatever the last things means). The is explicit list
of files giving you the Lua library. Link it with one extra file
(that is 'lua.c') and you get Lua interpteter. Link the library
with 'luac.c' and you get the compiler.
Documentation also mention explicit targets, like 'make mingw'.
But you probably arranged things so that it fails too.
The makefiles are full of useless dependency info. Lua is a small
program, and I just want to use it, not develop it.
AFAICS you want something to compile with your compiler and
claim that make fails. When I needed to build programs on
Windows make usually worked. Of course, I had ....
You miss important point of sources: having sources and free
licence means that anybody can develop program further.
In
particular people can do simple customization or bug fixes.
So if I find program useful, it is my decision if I want
to do work needed to keep it running on my system or port to
a different system. I case of binaries it is usually unfeasible
to fix bugs or port it (people use emulators, but this has
limitations). And if program is useful enough there is good
chance that sombody else already did the work.
BTW: I did have trouble with some Windows sources, and main
trouble was that source was incomplete or missed some needed
changes.
That is trouble was due to people who did not care
about distributing sources (but should have cared, as those cases
were Windows adaptions of GPL-ed things).
On 10/03/2025 10:58, Waldek Hebisch wrote:
bart <[email protected]> wrote:
I think nobody does. There's always been some sort of mystique
surrounding 'gcc' on Windows.
'MinGW' supposedly 'Minimalist Gnu on Windows'. In that case I wouldn't
like to see the full-scale one..
"Minimalist" is not about size of the compiler. Rather, it is
about possible support routines. For "hosted implementation" C
mandates presence of C library and there is a lot of functions
not in C standard, but included in libraries of C compilers.
There is also question of operating system support, complicated
by fact that Windows is different than other systems. Cygwin
solved those issues by offering Posix emulation and a sizable
collection os libraries. MinGW is minimalist in the sense
that it provides very little own libraries and mainly uses
what is provide by Windows.
I still don't get this stuff.
I get the impression that a port of gcc to Windows is not simply about building C programs, but building C programs that use a lot of features
from Linux.
If so, then that's the wrong approach. There are various lesser
compilers which know nothing about mingw or posix of anything of the
sort. (For example, lccwin32, DMC, PellesC, I think Tiny C; I can't
speak for MSVC.)
To put it differenly, you could compile program in one computer
and get relatively small program which runs OK on different
Windows machines because libraries it needs are already present.
This is quite different compared to Cygwin, where you need to
install Cygwin libraries before normal Cygwin program can run
(I write about normal programs because actual compiler in
Cygwin and Mingw used to be the same and with some tweaks one
could use Cygwin compiler to produce MinGW execuatbles).
I'm not interested in whatever Cygwin or Mingw are about. If I were to
use libraries not part of the OS, then it would be ones like SDL2 to get interesting things done. Not try and emulate bits of Linux that I'd
never heard of.
On 10/03/2025 17:25, Scott Lurndal wrote:
Or do you believe Windows programmers should use Visual Basic or C#?
On 10/03/2025 11:45, Waldek Hebisch wrote:
bart <[email protected]> wrote:
Oh dear, that hasn't worked either.
Hmm, it AFAICS worked. That is you wanted build failure and you
got build failure.
In last year's thread I did an experiment with I think 5 projects, and
most failed to build using the provided tools.
On 2025-03-10, Scott Lurndal <[email protected]> wrote:
[email protected] writes:
On Mon, 10 Mar 2025 15:20:00 +0200
Michael S <[email protected]> wibbled:
Similar to poll(), yes. Not so similar to super-ugly select(). I hope >>>>that Unix people stopped using select in new programs two or more >>>>decades ago.
Nothing wrong with select if you're not multiplexing hundreds of file >>>descriptors. Does the job.
The primary constraint for select(2) is not the _number_ of files
that can be selected amongst (although that _is_ a constraint),
but rather the largest file descriptor number is limited by the
select(2) bitmap interface (FD_SETSIZE not only defines the number
of file descriptors that can be passed, but also the highest
valued file descriptor that can be passed). poll(2) has no
such limits.
Indeed!
I think it would be fair to say that select was designed with
these assumptions:
1. The program's open file descriptors will be tightly clustered
next to zero, with few gaps.
2. The program will be polling almost all of those descriptors.
Fwiw, I only used IOCP with Sockets. ;^o
Nothing wrong with select if you're not multiplexing hundreds of file descriptors. Does the job.
Similar to poll(), yes. Not so similar to super-ugly select(). I
hope that Unix people stopped using select in new programs two or
more decades ago.
But WaitForMultipleObjects can do things that poll can not, like
waiting on semaphore or on event or on thread (for completion, which
POSIX people, in their eternal fondness for idiotic names call
'join').
As to "the one way", you yourself mentioned substantially different way
in your post here several weeks ago - stackless co-routines. Even if
ends up the same under the hood, it appears quite different from
perspective of application programmer.
I don't know where was a catch. As a matter of fact, cygwin people
found solution, so the problem was soluble.
lol! IOCP is not all that bad... :^) They have an interesting
function:
https://learn.microsoft.com/en-us/windows/win32/api/ioapiset/nf-ioapiset-getqueuedcompletionstatusex
On 3/10/2025 2:36 PM, Lawrence D'Oliveiro wrote:
On Mon, 10 Mar 2025 15:20:00 +0200, Michael S wrote:
Similar to poll(), yes. Not so similar to super-ugly select(). I
hope that Unix people stopped using select in new programs two or
more decades ago.
Seems like WaitForMultipleObjects is more similar to select() than
poll(), though: it has a fixed limit (MAXIMUM_WAIT_OBJECTS) on the
number of objects you can wait on at once.
But WaitForMultipleObjects can do things that poll can not, like
waiting on semaphore or on event or on thread (for completion, which
POSIX people, in their eternal fondness for idiotic names call
'join').
[...]
For some damn reason I am remembering that the array that WaitForMultipleObjects waits on should be "shifted" or even randomized
per call in a server loop that is using EVENTS. IIRC, this was way back
in late 90's and early 2000's.
Amazingly, it still doesn't caution the programmer against the
issue this can cause and the doesn't recommend permuting the array.
On 3/10/2025 2:42 PM, Lawrence D'Oliveiro wrote:
On Mon, 10 Mar 2025 14:09:13 -0700, Chris M. Thomasson wrote:
lol! IOCP is not all that bad... :^) They have an interesting
function:
https://learn.microsoft.com/en-us/windows/win32/api/ioapiset/nf-ioapiset-getqueuedcompletionstatusex
It’s a blocking call:
This function associates a thread with the specified completion
port. A thread can be associated with at most one completion port.
did you notice the timeout parameter?
So, no nondeterministic event-loop handling for you ...
For some damn reason I am remembering that the array that WaitForMultipleObjects waits on should be "shifted" or even randomized
per call in a server loop that is using EVENTS. IIRC, this was way back
in late 90's and early 2000's.
You mean, more work in not needing to create makefiles, or work out dependency graphs, or generate configure scripts, or enumerate compiler options?
Have you considered how much effort could be saved by keeping things
simple?
People have enough trouble with their own dependencies, without having
to worry about a sprawling directory tree of a library they want to incorporate.
I see it as generating unnecessary work. /You/ would never understand
that until you realise that building your project first involves
running 35,000 lines of gobbledygook in a language not supported by your machine.
Your view is that that 35Kloc *must* be absolutely essential, mine is
that at least 99% of it is pointless.
On 07/03/2025 01:07, Waldek Hebisch wrote:
bart <[email protected]> wrote:
If so, why doesn't the same apply to the main language of the
application? (Why isn't the application written in that language!)
You like benchmarks, so try some benchmarks of speed of shell
programs. Or believe me that for computational problems shell
programs are dog slow (of order of 100 times slower than normal
interpreted languages like Python).
That wasn't a serious suggestion. But why not have a language that can
run anywhere? A compiler is a program that reads in some files and
writes one or more output files - you can't get anything more portable!
I've also seen a project where the configuration program was a C file,
one which didn't need any special options, whose output was used to
build the main app.
Yes, that is a possiblity. Some time ago I was thinking about
similar thing. Basically, configure scripts are slow, ugly and
long due to limitations of shell and need to work with "any"
shell. Could we write resonably small "better shell" to
execute simpler version of configure script?
You'd still have to sell me on the need for a configuration script at all.
I accept that sometimes scripting is needed to orchestrate certain
builds or to perform installation, but such programs would be 2-3
magnitudes smaller than that 35Kloc monstrosity.
Again, why can't the main app be made to work like the small one?
Modern applications depend on libraries. Let me mention a dll
for Windows that I created many years ago. My own code was
about 2000 (wc) lines of code, part of it numeric code that
provided main functionality (image transformation), rest was
glue code to the libraries. Input data came from .tiff files
and I used libtiff to read them. I needed some geometry code
which I found on the net. I needed linear equation solver,
that I got from Lapack. So there were 4 libraries (3 that
I used directly and libjpeg used by libtiff), and most
code in "my" dll actually came from the other libraries.
In this dll was doing rather special thing used as a part
of bigger process. In modern times application like gimp
connects several things of similar complexity. There is
a lot of image formats, so many libraries just to read and
write graphic files. I did not look at gimp build process,
but at configure stage is must verify if all needed libraries
(probably tens if not more) are present. Libraries need to be
in sufficiently new versions and export needed functionality
(libraries frequently may be compiled skipping part of
functionality). I am pretty sure that parts of gimp are
optional, that is you may include or skip them. And some
other projects may wish to use parts of gimp, so build
probaly created quite a few of libraries (that is separate
things that need to be linked).
Some DLLS will be part of the OS. Some are easy to obtain by the user.
Some could be bundled.
However my apps (those mentioned below) would not fail if one was
missing; only if specific functions from a DLL were needed. (I think I
only needed one, to do with JPEG handling).
If I was still making apps, I would not have a dependency of an elusive library. One such is GMPxxx.DLL; that was so difficult to source, or
even to build from source code (yes it has its own 30Kloc configure
file!) that I found it easier to create my own library.
In modern times applications are supposed to be internationalized.
That is various messages should appear in selected language.
Normal practise in modern times is to have separate build
step to expract english messages from source files and
create connetion to translations. That alone means that
build is more complex than simply compiling C files.
Actually my 1990s apps were internationalised (working in English,
French, German, Dutch). A dictionary of translations was provided by distributors. There was some scripting to help with that, but the script language was built-in to the app.
It was all taken care of. No need for makefiles or any stuff like that. Supporting a different language didn't need a new build; just a data file.
So, what you are saying is that some software that is developed using
one particular environment, regarding its tools, resources, and testing,
may fail on an alien environment.
On 09/03/2025 21:54, Lawrence D'Oliveiro wrote:
And this for a package which is known to build on Windows.
It has been known to. But as I showed it doesn't always work.
But, when I eliminate the makefile nonsense, it often does work, more
simply and more quickly.
On 10/03/2025 10:58, Waldek Hebisch wrote:
bart <[email protected]> wrote:
I think nobody does. There's always been some sort of mystique
surrounding 'gcc' on Windows.
'MinGW' supposedly 'Minimalist Gnu on Windows'. In that case I wouldn't
like to see the full-scale one..
"Minimalist" is not about size of the compiler. Rather, it is
about possible support routines. For "hosted implementation" C
mandates presence of C library and there is a lot of functions
not in C standard, but included in libraries of C compilers.
There is also question of operating system support, complicated
by fact that Windows is different than other systems. Cygwin
solved those issues by offering Posix emulation and a sizable
collection os libraries. MinGW is minimalist in the sense
that it provides very little own libraries and mainly uses
what is provide by Windows.
I still don't get this stuff.
I get the impression that a port of gcc to Windows is not simply about building C programs, but building C programs that use a lot of features
from Linux.
If so, then that's the wrong approach. There are various lesser
compilers which know nothing about mingw or posix of anything of the
sort. (For example, lccwin32, DMC, PellesC, I think Tiny C; I can't
speak for MSVC.)
To put it differenly, you could compile program in one computer
and get relatively small program which runs OK on different
Windows machines because libraries it needs are already present.
This is quite different compared to Cygwin, where you need to
install Cygwin libraries before normal Cygwin program can run
(I write about normal programs because actual compiler in
Cygwin and Mingw used to be the same and with some tweaks one
could use Cygwin compiler to produce MinGW execuatbles).
I'm not interested in whatever Cygwin or Mingw are about.
If I were to
use libraries not part of the OS, then it would be ones like SDL2 to get interesting things done. Not try and emulate bits of Linux that I'd
never heard of.
On 3/10/2025 4:21 PM, Lawrence D'Oliveiro wrote:
On Mon, 10 Mar 2025 14:45:51 -0700, Chris M. Thomasson wrote:
On 3/10/2025 2:42 PM, Lawrence D'Oliveiro wrote:
It’s a blocking call:
This function associates a thread with the specified completion
port. A thread can be associated with at most one completion
port.
did you notice the timeout parameter?
That leads to busy-waiting.
It can be blocking ...
On 10/03/2025 11:45, Waldek Hebisch wrote:
bart <[email protected]> wrote:
Oh dear, that hasn't worked either.
Hmm, it AFAICS worked. That is you wanted build failure and you
got build failure.
In last year's thread I did an experiment with I think 5 projects, and
most failed to build using the provided tools.
In the case of Lua, there was an additional complication in that one lot
of online sources was incomplete (missing the top directory layer).
However what was provided still had a makefile, to confuse matters.
But even with the full sources, there was a catch - see below.
Of course you are an export on building
Windows programs and have your tricks. In this case a simple
one, like not having MinGW tools in the patch probably will do.
It will nearly always do. In the case of LIBJPEG, there are 5 binaries
to build including the two main ones (encode and decode). Each of those comprises 8 .c files, plus they share 46 other .c files.
The official makefile (the fallback one as there were lots!), built
those 46 into a .a archive, but which was then /statically/ linked into
each executable, so it didn't save any space.
I had to get it working once via the makefile, and arrange to capture
the shell commands used in order to determine all this.
From those, I was able to create two @ files so that I could build only
using a compiler. Each file simply lists the 54 files that are needed,
and is 4% the size of the makefile. (They can also use a shared @ file
to avoid repeating the shared files.)
Using tcc, each program builds from source in 0.3 seconds using such a
list, even though 46 source files are processed twice.
This works! No crappy makefiles needed. Here I happened to know it
involves compiling 33 of the 34 C files supplied (luac.c is for embedded >>> I think).
Not reading instructions help in writing newsgroup post. If you
read documentation you would see that build process is supposed to
build 3 related products: Lua library, Lua interpreter and Lua
compiler (whatever the last things means). The is explicit list
of files giving you the Lua library. Link it with one extra file
(that is 'lua.c') and you get Lua interpteter. Link the library
with 'luac.c' and you get the compiler.
I always build lua.exe. I mentioned that luac.c was for embedded, or something.
Documentation also mention explicit targets, like 'make mingw'.
But you probably arranged things so that it fails too.
Actually, looking at the docs more carefully, it seems the makefiles
only work for Linux.
For Windows you are on you own. But at least it does list the files
involved.
However, I thought the point of 'make' was that you just typed 'make'
and it goes and builds your program with no further input. Here, the
makefile could have provided a helpful message saying that Windows was
not supported.
The makefiles are full of useless dependency info. Lua is a small
program, and I just want to use it, not develop it.
AFAICS you want something to compile with your compiler and
claim that make fails. When I needed to build programs on
Windows make usually worked. Of course, I had ....
So they usually worked after you fixed all the problems? OK!
You miss important point of sources: having sources and free
licence means that anybody can develop program further.
There are two things you may want to do when building sources:
(1) You want to do further development as you say
(2) You simply want to build a working binary and have no interest in anything else.
Those two requirements are utterly different, yet most developers who
provide sources ignore that, and simply provide the entire directory
tree and a hundred other things that might be needed for (1).
For (2):
* You don't need a sprawling directory tree; files can be flattened into
one folder
* (You don't need separate files; they can be flattened into one file
via various tools and scripts. In my case, I do that via a transpiler.
For C, this provides the opportunity for whole-program optimisation.)
* You don't need makefiles with tons of dependency info. This stuff is
for incremental compilation, but here we are only building once, so it
has to be done from scratch anyway. It is not time-critical.
* You might still need to orchestrate the building of multiple binaries,
or to install the result, but for this there are better scripting
languages than 'make'. Even C will do, for which the user will already
have a compiler. (IMV installation is a quite different process from building.)
* If this is for a known platform, then the process can be streamlined further
Examples of (2) for me are GMP and LIBFFI libraries which are a
nightmare to build on Windows.
In
particular people can do simple customization or bug fixes.
So if I find program useful, it is my decision if I want
to do work needed to keep it running on my system or port to
a different system. I case of binaries it is usually unfeasible
to fix bugs or port it (people use emulators, but this has
limitations). And if program is useful enough there is good
chance that sombody else already did the work.
BTW: I did have trouble with some Windows sources, and main
trouble was that source was incomplete or missed some needed
changes.
You really want to fix things in gcc for example by messing with the
source files? I think we establshed that there were at least 79,000 .c
files. (Better set aside the rest of the decade to get familiar with it!)
That is trouble was due to people who did not care
about distributing sources (but should have cared, as those cases
were Windows adaptions of GPL-ed things).
I provide source code for reason (2) above. This is likely to be
amalgamated into one file, or transpiled to one C file
For (1), I can provide original source files, but building source in my personal language is problematical. For a start, you need a binary to
get started, but people don't like binaries because of AV issues or lack
of trust.
(They generally work for mainstream products on Windows; presumably the providers are whitelisted by MS, even if they are not in the MS Store.)
On 3/10/2025 8:07 PM, Lawrence D'Oliveiro wrote:
On Mon, 10 Mar 2025 19:01:16 -0700, Chris M. Thomasson wrote:
On 3/10/2025 4:21 PM, Lawrence D'Oliveiro wrote:
On Mon, 10 Mar 2025 14:45:51 -0700, Chris M. Thomasson wrote:
On 3/10/2025 2:42 PM, Lawrence D'Oliveiro wrote:
It’s a blocking call:
This function associates a thread with the specified
completion port. A thread can be associated with at most one >>>>>> completion port.
did you notice the timeout parameter?
That leads to busy-waiting.
It can be blocking ...
Yes, we already covered that.
So, that's that. There is no busy wait.
On 3/10/2025 8:07 PM, Lawrence D'Oliveiro wrote:
Surely events relevant to entries in the list should be
serviced in the order they arrive, not in the order in which the
entries happen to occur in the list. There is no other reasonable way
to do it.
Well, it just the way WFMO is implemented.
On Mon, 10 Mar 2025 15:11:14 -0000 (UTC), Muttley wrote:
Nothing wrong with select if you're not multiplexing hundreds of file
descriptors. Does the job.
But it still requires allocating a fixed-length bit array hundreds of
bytes in size, even if you are only concerned with one or two FDs. And if
the numbers of those FDs lie beyond the upper limit of the array, you’re >stuffed.
[email protected] writes:
On Mon, 10 Mar 2025 15:20:00 +0200
Michael S <[email protected]> wibbled:
Similar to poll(), yes. Not so similar to super-ugly select(). I hope >>>that Unix people stopped using select in new programs two or more
decades ago.
Nothing wrong with select if you're not multiplexing hundreds of file >>descriptors. Does the job.
The primary constraint for select(2) is not the _number_ of files
that can be selected amongst (although that _is_ a constraint),
but rather the largest file descriptor number is limited by the
select(2) bitmap interface (FD_SETSIZE not only defines the number
of file descriptors that can be passed, but also the highest
valued file descriptor that can be passed). poll(2) has no
such limits.
On Sun, 9 Mar 2025 15:37:35 +0000, bart wrote:
So, what you are saying is that some software that is developed
using one particular environment, regarding its tools, resources,
and testing, may fail on an alien environment.
No, actually that software is able to build and run nicely on every
single environment it has been ported to ... except one.
On 11/03/2025 00:57, Lawrence D'Oliveiro wrote:
On Sun, 9 Mar 2025 22:59:22 +0000, bart wrote:
On 09/03/2025 21:54, Lawrence D'Oliveiro wrote:
And this for a package which is known to build on Windows.
It has been known to. But as I showed it doesn't always work.
No, you weren’t able to get it to work.
A build process should be foolproof. You seem to be moving from
'Windows is rubbish' to 'the person trying to build it is an idiot'.
What excuse will you come up with next?
I suppose it is inconceivable that the build process is
over-elaborate, highly error prone and over-dependent on third-party
tools?
The CPython build for Windows, /10 years ago/ (I guess it wouldn't
have gotten any simpler!) involved VS, MSVC, MS Build Tools, GIT, SVN
and a bunch of stuff I can't even remember. It still didn't work.
Clearly others have the skills to
make it work.
But, when I eliminate the makefile nonsense, it often does work,
more simply and more quickly.
Prove it: do it with the Python build.
Sure, just tell me the C files that comprise each binary, and ensure
all .c and .h files are supplied.
This the bit that the supplied build process makes near-impossible to
do in a straightforward way.
For /my/ interpreted language, ON WINDOWS (the OS you seem to think
it incapable of building any software), it is built from source as
follows:
Start with these TWO files:
c:\demo>dir
07/03/2025 21:00 402,432 mm.exe
11/03/2025 11:33 865,928 qq.ma
Compile one with the other:
c:\demo>mm qq
Compiling qq.m to qq.exe
Now there are THREE files:
c:\demo>dir
07/03/2025 21:00 402,432 mm.exe
11/03/2025 11:34 567,808 qq.exe
11/03/2025 11:33 865,928 qq.ma
The new one is the interpreter. Neat, yes? I doubt you can get much
simpler and more effortless than this.
However, this is me making the effort to make it so. AFAICS nobody
over at Linux-land is trying make things simpler; they're making
things bigger and more complicated instead by adding extra layers.
Hint: the ability to type 'make' (one character less than 'mm qq') to
start a build process involving 1000s of files, 100s of directories,
10s of 1000s of lines of scripts, dozens of specialist utilities,
taking several minutes to complete, with myriad failure points, is
NOT what I would count as simpler.
On Sun, 9 Mar 2025 22:59:22 +0000, bart wrote:
On 09/03/2025 21:54, Lawrence D'Oliveiro wrote:
And this for a package which is known to build on Windows.
It has been known to. But as I showed it doesn't always work.
No, you weren’t able to get it to work.
make it work.
But, when I eliminate the makefile nonsense, it often does work, more
simply and more quickly.
Prove it: do it with the Python build.
On Sun, 9 Mar 2025 15:37:35 +0000, bart wrote:
So, what you are saying is that some software that is developed using
one particular environment, regarding its tools, resources, and testing,
may fail on an alien environment.
No, actually that software is able to build and run nicely on every single environment it has been ported to ... except one.
On Mon, 10 Mar 2025 17:12:06 GMT
[email protected] (Scott Lurndal) wibbled:
[email protected] writes:
On Mon, 10 Mar 2025 15:20:00 +0200
Michael S <[email protected]> wibbled:
Similar to poll(), yes. Not so similar to super-ugly select(). I hope >>>>that Unix people stopped using select in new programs two or more >>>>decades ago.
Nothing wrong with select if you're not multiplexing hundreds of file >>>descriptors. Does the job.
The primary constraint for select(2) is not the _number_ of files
that can be selected amongst (although that _is_ a constraint),
but rather the largest file descriptor number is limited by the
select(2) bitmap interface (FD_SETSIZE not only defines the number
of file descriptors that can be passed, but also the highest
valued file descriptor that can be passed). poll(2) has no
such limits.
File descriptors get reused on every version of *nix I've ever programmed
on so unless you have hundreds of descriptors open at any one time thats not >going to be a problem.
On Tue, 11 Mar 2025 11:43:50 +0000
Hint: the ability to type 'make' (one character less than 'mm qq') to
start a build process involving 1000s of files, 100s of directories,
10s of 1000s of lines of scripts, dozens of specialist utilities,
taking several minutes to complete, with myriad failure points, is
NOT what I would count as simpler.
It is far more complicated than yours if all the person wants is an exe.
It is simpler than your process if the person has higher ambitions.
Like fixing bugs or adding features.
I suppose that you achieved build simplicity by means of amalgamation.
Do you provide your potential users with de-amalgamation tool, just to
giv'em a minimal chance?
[email protected] writes:
On Mon, 10 Mar 2025 17:12:06 GMT
[email protected] (Scott Lurndal) wibbled:
[email protected] writes:
On Mon, 10 Mar 2025 15:20:00 +0200
Michael S <[email protected]> wibbled:
Similar to poll(), yes. Not so similar to super-ugly select(). I hope >>>>>that Unix people stopped using select in new programs two or more >>>>>decades ago.
Nothing wrong with select if you're not multiplexing hundreds of file >>>>descriptors. Does the job.
The primary constraint for select(2) is not the _number_ of files
that can be selected amongst (although that _is_ a constraint),
but rather the largest file descriptor number is limited by the
select(2) bitmap interface (FD_SETSIZE not only defines the number
of file descriptors that can be passed, but also the highest
valued file descriptor that can be passed). poll(2) has no
such limits.
File descriptors get reused on every version of *nix I've ever programmed >>on so unless you have hundreds of descriptors open at any one time thats not >>going to be a problem.
$ man dup2
There are very few reasons to favor select over poll in new code.
To build open source projects, I'm happy to use an existing C compiler.
I'm NOT happy about bending over backwards to use CYGWIN, MSYS2 or WSL because the developers insist on forcing their Linux dependencies down
my throat.
Developers can do what they like. But they shouldn't inflict their
choices on other people, especially those using other OSes.
bart <[email protected]> wrote:
On 10/03/2025 10:58, Waldek Hebisch wrote:
bart <[email protected]> wrote:
I think nobody does. There's always been some sort of mystique
surrounding 'gcc' on Windows.
'MinGW' supposedly 'Minimalist Gnu on Windows'. In that case I wouldn't >>>> like to see the full-scale one..
"Minimalist" is not about size of the compiler. Rather, it is
about possible support routines. For "hosted implementation" C
mandates presence of C library and there is a lot of functions
not in C standard, but included in libraries of C compilers.
There is also question of operating system support, complicated
by fact that Windows is different than other systems. Cygwin
solved those issues by offering Posix emulation and a sizable
collection os libraries. MinGW is minimalist in the sense
that it provides very little own libraries and mainly uses
what is provide by Windows.
I still don't get this stuff.
I get the impression that a port of gcc to Windows is not simply about
building C programs, but building C programs that use a lot of features
from Linux.
You apparently do not get fact that people want tools to
automate various routine tasks.
And people do not want
to reinvent the wheel, they prefer to use code written
by others.
Folks at Bell Labs had several good ideas
and shared them with others. Those ideas are not limited
to Linux or Unix, you can look at old "Software tools in ..."
books to understand what I am talking about. MinGW
_distribution_ bundles several tools. This allows you
to compile programs when build process uses those tools.
You can also use the tools for your purpose. Aparently
you have very strong "not invented here" syndrom and
insist on usig your own tools.
That is fine, as long
as you keep this to yourselfs. But refusing other
folks right to use tools they want to use is not
fair.
Or, to put it differently, when you refuse
the tools _you_ need to do by hand needed work.
You may be able to extract from work of others
something that fits your taste (like list of files
to compile), but that is your business.
If so, then that's the wrong approach. There are various lesser
compilers which know nothing about mingw or posix of anything of the
sort. (For example, lccwin32, DMC, PellesC, I think Tiny C; I can't
speak for MSVC.)
You may be able to do some things using just a C compiler.
But requesting people to do other things by hand is as
wise as requesting them to code in assembler
may be converted to binary faster than C, and with enough
effort resulting binary will run faster than result of
C compilation :). Another thing are libraries and
bigger applications. Some folks want "true Windows look
and feel", some say that proper Windows DLL must be
compiled by MSVC
(otherwise is lack some features that
they consider essential). But there are people who
had to or wanted to use Windows, but also wanted to
use Unix applications. Cygwin was addressed to such
folks: it allows you to compile substantial Unix
application so that it runs on Windows. If you have
no interest in such applications, than fine, Cygwin
is probably not for you. Today WSL may be better
for such a goal, but in the past Cygwin provided
easiest way to port Unix application to Windows.
If easy port was the goal and application was
substantial, then Cygwin usually was right choice.
To put it differenly, you could compile program in one computer
and get relatively small program which runs OK on different
Windows machines because libraries it needs are already present.
This is quite different compared to Cygwin, where you need to
install Cygwin libraries before normal Cygwin program can run
(I write about normal programs because actual compiler in
Cygwin and Mingw used to be the same and with some tweaks one
could use Cygwin compiler to produce MinGW execuatbles).
I'm not interested in whatever Cygwin or Mingw are about.
Oh, so you do not want to know. In such case why you started
discussing it?
If I were to
use libraries not part of the OS, then it would be ones like SDL2 to get
interesting things done. Not try and emulate bits of Linux that I'd
never heard of.
I mentioned one case: about 90% of code in "my" library was
provided in fact by other libraries. So using code provided
by other saved me a lot of work, turning something that
otherwise could be multiyear job into reasonably small effort.
To use the libraries I had to work out build process, thanks
to tools it was very easy.
MinGW bundle is a good way to build such libraries. Having
only a C compiler may be too little.
On 11/03/2025 15:06, David Brown wrote:
On 11/03/2025 15:24, bart wrote:
To build open source projects, I'm happy to use an existing C
compiler. I'm NOT happy about bending over backwards to use CYGWIN,
MSYS2 or WSL because the developers insist on forcing their Linux
dependencies down my throat.
Developers can do what they like. But they shouldn't inflict their
choices on other people, especially those using other OSes.
I have not paid a lot of attention to this thread. But I am curious
here - who do you think is /forcing/ you to compile their code?
OK, tell me where to get ready-made DLLs for GMP and LIBFFI that I can
can use on Windows. If that's not possible then there is no choice
(other than not to use them at all, which is what I do).
Why do you think it is appropriate for /you/ to demand that people
writing open source projects (often as voluntary work) should go out
of their way to make /your/ life easier?
It would make everyone's life easier. Especially those who struggle to
build that stuff on Windows.
Windows is getting an unfairly bad reputation for building applications;
why do you think that is?
It's almost like the people on Linux
deliberately keep their build systems Linux-centric just to maintain
that myth!
Why are you trying to inflict /your/ choices on them?
Windows is getting an unfairly bad reputation for building applications;
why do you think that is? It's almost like the people on Linux
deliberately keep their build systems Linux-centric just to maintain
that myth!
Open source developers presumably want people to use their programs,
even those working on Windows. And I mentioned elsewhere that 70% of
desktop systems and laptops use Windows. So why alienate those people?
On 11/03/2025 15:24, bart wrote:
To build open source projects, I'm happy to use an existing C
compiler. I'm NOT happy about bending over backwards to use CYGWIN,
MSYS2 or WSL because the developers insist on forcing their Linux
dependencies down my throat.
Developers can do what they like. But they shouldn't inflict their
choices on other people, especially those using other OSes.
I have not paid a lot of attention to this thread. But I am curious
here - who do you think is /forcing/ you to compile their code?
Why do
you think it is appropriate for /you/ to demand that people writing open source projects (often as voluntary work) should go out of their way to
make /your/ life easier?
Why are you trying to inflict /your/ choices
on them?
It is very strange to me that you feel open source developers should bow
to your preferences and famously restricted build requirements.
If someone wants to write software that only works on Windows, that's
their choice. If I want to use it on Linux, I may have to re-write
parts of it, or use Wine, or Mono, or perhaps be unable to use it at
all. That's fair enough. The same applies if I - or anyone else - want
to use software written for Linux on Windows. It doesn't matter if
making the code cross-platform or independent of a particular library,
header or tool would have been a big job or a small job. I have no
right to complain that an open source project is hard for me to build on
my chosen system - and neither do you.
On 11/03/2025 17:23, bart wrote:
On 11/03/2025 15:06, David Brown wrote:
On 11/03/2025 15:24, bart wrote:
To build open source projects, I'm happy to use an existing C
compiler. I'm NOT happy about bending over backwards to use CYGWIN,
MSYS2 or WSL because the developers insist on forcing their Linux
dependencies down my throat.
Developers can do what they like. But they shouldn't inflict their
choices on other people, especially those using other OSes.
I have not paid a lot of attention to this thread. But I am curious
here - who do you think is /forcing/ you to compile their code?
OK, tell me where to get ready-made DLLs for GMP and LIBFFI that I can
can use on Windows. If that's not possible then there is no choice
(other than not to use them at all, which is what I do).
So do you think that those projects are /forcing/ you to use their code?
Are the folks who wrote GMP responsible for /your/ insistence on
using /their/ code, without using additional tools or libraries? You
want to use what probably amounts to hundreds of person-years of
specialised work, for free, and you are not willing to go to the effort
of downloading and installing a few other bits of /free/ software first,
in order to be able to follow freely available instructions found online?
And you blame the GMP and LIBFFI for all this? They are, after all,
holding a gun to your head and insisting that you use their software
while viscously and maliciously refusing to re-write their code to
remove traces of code that rely on the platforms they use themselves.
Or maybe it is now /my/ responsibility to find these dll's for you?
Well, you are in luck :
<https://packages.msys2.org/packages/mingw-w64-ucrt-x86_64-gmp> <https://packages.msys2.org/packages/mingw-w64-ucrt-x86_64-libffi>
The compressed tarballs include the dlls.
OK, tell me where to get ready-made DLLs for GMP and LIBFFI that I
can can use on Windows.
On 11/03/2025 17:09, David Brown wrote:
On 11/03/2025 17:23, bart wrote:
On 11/03/2025 15:06, David Brown wrote:
On 11/03/2025 15:24, bart wrote:
To build open source projects, I'm happy to use an existing C
compiler. I'm NOT happy about bending over backwards to use
CYGWIN, MSYS2 or WSL because the developers insist on forcing
their Linux dependencies down my throat.
Developers can do what they like. But they shouldn't inflict
their choices on other people, especially those using other OSes.
I have not paid a lot of attention to this thread. But I am
curious here - who do you think is /forcing/ you to compile their
code?
OK, tell me where to get ready-made DLLs for GMP and LIBFFI that I
can can use on Windows. If that's not possible then there is no
choice (other than not to use them at all, which is what I do).
So do you think that those projects are /forcing/ you to use their
code? Are the folks who wrote GMP responsible for /your/ insistence
on using /their/ code, without using additional tools or libraries?
You want to use what probably amounts to hundreds of person-years
of specialised work, for free, and you are not willing to go to the
effort of downloading and installing a few other bits of /free/
software first, in order to be able to follow freely available
instructions found online?
And you blame the GMP and LIBFFI for all this? They are, after
all, holding a gun to your head and insisting that you use their
software while viscously and maliciously refusing to re-write their
code to remove traces of code that rely on the platforms they use themselves.
Or maybe it is now /my/ responsibility to find these dll's for you?
Well, you are in luck :
<https://packages.msys2.org/packages/mingw-w64-ucrt-x86_64-gmp> <https://packages.msys2.org/packages/mingw-w64-ucrt-x86_64-libffi>
The compressed tarballs include the dlls.
I downloaded a couple of large files, including mingw64-x86_64-gmp-6.3.0-1-src.tar, but found no trace of any DLL
files.
(But I'm pleased that the GMP configure script hasn't grown beyond
30583 lines. When they manage 0 lines, let me know.)
Meanwhile here is the library *I* had to use instead:
https://github.com/sal55/langs/tree/master/bignum
There are 4 files:
bignum.c Source codeI
bignum.h Header provides the API
bignum.dll Prebuilt binary
pid.c Demo to show it works
You can build bignum.c into the .dll yourself (sorry, I don't have a 40,000-line configure script or massive makefile for that, you'll
have to figure it out yourself!), or compile it into your application.
The demo (shows digits of pi) is built like this:
tcc pid.c bignum.dll
This is what simplicity looks like.
(GMP now includes 'minigmp', which is one-file version plus headers. Performance is roughly on a par with my library.
However my library uses decimal representation, and includes
arbitrary precision floating point.)
Oh, and it's open source and is in public domain.
<snip rest of your post>
Performance is roughly on a par with my library.
On 11/03/2025 17:09, David Brown wrote:
On 11/03/2025 17:23, bart wrote:
On 11/03/2025 15:06, David Brown wrote:
On 11/03/2025 15:24, bart wrote:
To build open source projects, I'm happy to use an existing C
compiler. I'm NOT happy about bending over backwards to use CYGWIN,
MSYS2 or WSL because the developers insist on forcing their Linux
dependencies down my throat.
Developers can do what they like. But they shouldn't inflict their
choices on other people, especially those using other OSes.
I have not paid a lot of attention to this thread. But I am curious
here - who do you think is /forcing/ you to compile their code?
OK, tell me where to get ready-made DLLs for GMP and LIBFFI that I
can can use on Windows. If that's not possible then there is no
choice (other than not to use them at all, which is what I do).
So do you think that those projects are /forcing/ you to use their
code? Are the folks who wrote GMP responsible for /your/ insistence
on using /their/ code, without using additional tools or libraries?
You want to use what probably amounts to hundreds of person-years of
specialised work, for free, and you are not willing to go to the
effort of downloading and installing a few other bits of /free/
software first, in order to be able to follow freely available
instructions found online?
And you blame the GMP and LIBFFI for all this? They are, after all,
holding a gun to your head and insisting that you use their software
while viscously and maliciously refusing to re-write their code to
remove traces of code that rely on the platforms they use themselves.
Or maybe it is now /my/ responsibility to find these dll's for you?
Well, you are in luck :
<https://packages.msys2.org/packages/mingw-w64-ucrt-x86_64-gmp>
<https://packages.msys2.org/packages/mingw-w64-ucrt-x86_64-libffi>
The compressed tarballs include the dlls.
I downloaded a couple of large files, including mingw64-x86_64-gmp-6.3.0-1-src.tar, but found no trace of any DLL files.
(But I'm pleased that the GMP configure script hasn't grown beyond 30583 lines. When they manage 0 lines, let me know.)
Meanwhile here is the library *I* had to use instead:
https://github.com/sal55/langs/tree/master/bignum
On 11/03/2025 01:33, Waldek Hebisch wrote:
You apparently do not get fact that people want tools to automate
various routine tasks.
What routine task is this? I'm talking exclusively about turning a bunch
of source files in some language (here it is C) into an executable
binary.
However, what I'm arguing about is that this simple task has become unnecessarily elaborate on OSes like Linux, by introducing makefiles, OS-specific scripts, and OS-specific utilities.
If scripts are going to be used, then use them at the developer site
only, and make the script generate the streamlined set of files for the particular platform of interest.
It should not rely on anything that is not native to the target
platform.
To build open source projects, I'm happy to use an existing C compiler.
I'm NOT happy about bending over backwards to use CYGWIN, MSYS2 or WSL because the developers insist on forcing their Linux dependencies down
my throat.
On Mon, 10 Mar 2025 21:38:35 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wrote:
the numbers of those FDs lie beyond the upper limit of the array, you’re >>stuffed.
Any descriptor created that had a value greater than select() could cope
with would break a lot of old code so although I have no proof, I'd bet
money on the kernel/libc authors taking this into account when
allocating user space descriptor values.
The above gmp DLL is 666KB
On 11/03/2025 18:47, bart wrote:
<https://packages.msys2.org/packages/mingw-w64-ucrt-x86_64-gmp>
<https://packages.msys2.org/packages/mingw-w64-ucrt-x86_64-libffi>
The compressed tarballs include the dlls.
I downloaded a couple of large files, including mingw64-x86_64-
gmp-6.3.0-1-src.tar, but found no trace of any DLL files.
You downloaded the source tarballs, and are surprised to find they
contain source files - not binaries? Did the abbreviation "src" not
give you a clue?
Try the link that is labelled "File:" - it is the msys2/mingw-w64
tarball with libgmp-10.dll and all the other files shown in the list at
the bottom of the page, under "Files:".
Meanwhile here is the library *I* had to use instead:
https://github.com/sal55/langs/tree/master/bignum
It is not exactly comparable, is it?
If all you need is some simple arithmetic done in a naïve school long multiplication way, then the code is fine.
Your code is a reasonably
clear and straightforward implementation of that. If you have no need
of more than that, there is little point in going for something as
powerful as GMP - it is probably faster to write such code than it is to learn how to use GMP.
On Tue, 11 Mar 2025 17:47:24 +0000
bart <[email protected]> wrote:
Performance is roughly on a par with my library.
You can not appreciate performance of performace of GMP until you use
it with BIG numbers. Not 100 or 1,000 digits, although for 1,000
digits it likely beats your library by a good margin. Try to multiply
numbers with 100,000 or more digits. Then you will see really massive difference.
As to floating-point, GMP used to have it, but long ago decided that it
is out of scope. Support for floating-point is still here for historical reasons, but for new software they recommend to use MPFR.
On 11/03/2025 17:09, David Brown wrote:
On 11/03/2025 17:23, bart wrote:
<https://packages.msys2.org/packages/mingw-w64-ucrt-x86_64-gmp>
<https://packages.msys2.org/packages/mingw-w64-ucrt-x86_64-libffi>
The compressed tarballs include the dlls.
I downloaded a couple of large files, including >mingw64-x86_64-gmp-6.3.0-1-src.tar, but found no trace of any DLL files.
On 11/03/2025 15:06, David Brown wrote:
On 11/03/2025 15:24, bart wrote:
To build open source projects, I'm happy to use an existing C
compiler. I'm NOT happy about bending over backwards to use CYGWIN,
MSYS2 or WSL because the developers insist on forcing their Linux
dependencies down my throat.
Developers can do what they like. But they shouldn't inflict their
choices on other people, especially those using other OSes.
I have not paid a lot of attention to this thread. But I am curious
here - who do you think is /forcing/ you to compile their code?
OK, tell me where to get ready-made DLLs for GMP and LIBFFI that I can
can use on Windows.
It would make everyone's life easier.
Windows is getting an unfairly bad reputation for building applications;
What choices are those? To have to supply, with a multi-MB source
download, a text file listing the files I have to submit to the compiler?
Would it really be that onerous? Such a file would also work on Linux
and save everyone a lot of time.
On Tue, 11 Mar 2025 14:24:15 +0000, bart wrote:
On 11/03/2025 01:33, Waldek Hebisch wrote:
You apparently do not get fact that people want tools to automate
various routine tasks.
What routine task is this? I'm talking exclusively about turning a bunch
of source files in some language (here it is C) into an executable
binary.
Interesting that you don’t see an app build as a “routine task”.
Think of how often, while developing a program in (at least partly) a compiled a language, you have to go through
edit → build → run → crash
ad nauseam.
This is why we have makefiles, because usually the whole source does not
need to be recompiled each time, only the parts that have changed since
the last run.
However, what I'm arguing about is that this simple task has become
unnecessarily elaborate on OSes like Linux, by introducing makefiles,
OS-specific scripts, and OS-specific utilities.
And yet all that automation makes it quite easy to build quite complex
apps on Linux. You were the one who had trouble on Windows.
If scripts are going to be used, then use them at the developer site
only, and make the script generate the streamlined set of files for the
particular platform of interest.
Funny, that’s how Autotools works (generating the configure script from
the much more human-readable configure.ac source), and yet you were complaining about what an unreadable blob it produced.
It should not rely on anything that is not native to the target
platform.
Unfortunately that rules out developing for Windows completely, since
there is essentially nothing development-related that is native to
Windows. Everything has to be added on.
To build open source projects, I'm happy to use an existing C compiler.
I'm NOT happy about bending over backwards to use CYGWIN, MSYS2 or WSL
because the developers insist on forcing their Linux dependencies down
my throat.
Beggars can’t be choosers. As long as you don’t have the skills or patience to actually contribute to such development, you have to accept
what you get.
bart <[email protected]> writes:
On 11/03/2025 15:06, David Brown wrote:
On 11/03/2025 15:24, bart wrote:
To build open source projects, I'm happy to use an existing C
compiler. I'm NOT happy about bending over backwards to use CYGWIN,
MSYS2 or WSL because the developers insist on forcing their Linux
dependencies down my throat.
Developers can do what they like. But they shouldn't inflict their
choices on other people, especially those using other OSes.
I have not paid a lot of attention to this thread. But I am curious
here - who do you think is /forcing/ you to compile their code?
OK, tell me where to get ready-made DLLs for GMP and LIBFFI that I can
can use on Windows.
Why do you think anybody owes you anything? The developers of those libraries, mostly working for free, make the source available for
for free. They are required to make -your- life easy.
Here's a thought - why don't you write your own multiprecision
library and release it as open source?
Highly doubtful, most projects are far more complex than your
simple single-source file world.
Windows is getting an unfairly bad reputation for building applications;
Because we've used it, and it sucks?
What choices are those? To have to supply, with a multi-MB source
download, a text file listing the files I have to submit to the compiler?
Pretty much every open source project out there, particularly those with large source-bases actually provide a text file listing the files you
need to compile. It's called "Makefile".
A "traditional" server loop would block on IOCP (aka INFINITE).
Also, waiting for say 5 minutes for IO and timing out so the server
loop in the worker threads can examine other things can be
beneficial as well.
On 11/03/2025 18:17, Michael S wrote:
But both are magnitudes slower than the full GMP, at least with
bigger precision. (The dlls you linked didn't work; the one that
David Brown vaguely linked to, which I eventually found, did work.)
However I needed all these years ago.
On 11/03/2025 20:37, Lawrence D'Oliveiro wrote:
On Tue, 11 Mar 2025 14:24:15 +0000, bart wrote:
On 11/03/2025 01:33, Waldek Hebisch wrote:
You apparently do not get fact that people want tools to automate
various routine tasks.
What routine task is this? I'm talking exclusively about turning a bunch >>> of source files in some language (here it is C) into an executable
binary.
Interesting that you don’t see an app build as a “routine task”.
Think of how often, while developing a program in (at least partly) a
compiled a language, you have to go through
edit → build → run → crash
ad nauseam.
This is why we have makefiles, because usually the whole source does not
need to be recompiled each time, only the parts that have changed since
the last run.
That has never, ever been a problem.
Are they? The GMP DLL I finally saw is only 660KB, roughly 70Kloc.
That is not huge.
Have you ever used IOCP before?
BTW, I think that tcc is doing damage to itself by refusal to support
ucrt variant of Microsoft's C RTL.
IOCP works fine ...
Why do you think anybody owes you anything? The developers of
[open source] libraries, mostly working for free, make the source
available for for free. They are required to make -your- life
easy.
On 3/11/2025 8:12 PM, Lawrence D'Oliveiro wrote:
On Tue, 11 Mar 2025 20:04:30 -0700, Chris M. Thomasson wrote:
IOCP works fine ...
But not with pipes.
Never tried them with pipes, only sockets.
Do you really think that many Linux-originated Open Source projects that
can not be built easily on Windows/Msys2 are easy to build on such OSes like:
1. zOS (it is certified UNIX, but somehow I am not sure that it's
enough)
2. VMS
3. iOS (it has BSD-derived kernel, but somehow I am not sure that it's enough)
4. Android (it has Linux kernel, but somehow I am not sure that it's
enough. Although do expect that rate of success would be higher than in
cases 1,2 and 3).
There are two main environments A and B, and it manages to build on A, because the build process depends entirely on shell commands, utilities
and libraries that are exclusive to A.
BTW see: https://gs.statcounter.com/os-market-share/desktop/worldwide
On Tue, 11 Mar 2025 08:34:43 -0000 (UTC), Muttley wrote:
On Mon, 10 Mar 2025 21:38:35 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wrote:
the numbers of those FDs lie beyond the upper limit of the array, you’re >>>stuffed.
Any descriptor created that had a value greater than select() could cope
with would break a lot of old code so although I have no proof, I'd bet
money on the kernel/libc authors taking this into account when
allocating user space descriptor values.
You really want to bet money? From
<https://manpages.debian.org/select(2)>:
BUGS
POSIX allows an implementation to define an upper limit,
advertised via the constant FD_SETSIZE, on the range of file
descriptors that can be specified in a file descriptor set. The
Linux kernel imposes no fixed limit, but the glibc implementation
makes fd_set a fixed-size type, with FD_SETSIZE defined as 1024,
and the FD_*() macros operating according to that limit.
Default settings on my current system:
ldo@theon:~> prlimit -n
RESOURCE DESCRIPTION SOFT HARD UNITS
NOFILE max number of open files 1024 524288 files
How much are you going to pay?
On 3/11/2025 9:23 AM, bart wrote:
On 11/03/2025 15:06, David Brown wrote:
On 11/03/2025 15:24, bart wrote:
To build open source projects, I'm happy to use an existing C
compiler. I'm NOT happy about bending over backwards to use
CYGWIN, MSYS2 or WSL because the developers insist on forcing
their Linux dependencies down my throat.
Developers can do what they like. But they shouldn't inflict
their choices on other people, especially those using other OSes.
I have not paid a lot of attention to this thread. But I am
curious here - who do you think is /forcing/ you to compile their
code?
OK, tell me where to get ready-made DLLs for GMP and LIBFFI that I
can can use on Windows. If that's not possible then there is no
choice (other than not to use them at all, which is what I
do).[...]
FWIW, vcpkg can build them all for you and optionally integrate them directly into MSVC.
On 11/03/2025 22:18, bart wrote:
I needed support for big numbers in my interpreter. My product is
well-integrated, and represents 5% of the 250KB interpreter size. The
above gmp DLL is 666KB so is a poor match.
Out of curiosity - how often are such big numbers needed and used with
your interpreter, excluding demos to show how to use big numbers? 64-bit arithmetic is enough for the huge majority of purposes outside of cryptography and mathematics, and 128-bit arithmetic covers almost all
of the rest. Your code is not suitable for cryptography or mathematics.
So what is it used for? And could it have been handled much more
simply by using 128-bit fixed sizes?
On 11/03/2025 20:20, David Brown wrote:
On 11/03/2025 18:47, bart wrote:
<https://packages.msys2.org/packages/mingw-w64-ucrt-x86_64-gmp>
<https://packages.msys2.org/packages/mingw-w64-ucrt-x86_64-libffi>
The compressed tarballs include the dlls.
I downloaded a couple of large files, including mingw64-x86_64-
gmp-6.3.0-1-src.tar, but found no trace of any DLL files.
You downloaded the source tarballs, and are surprised to find they
contain source files - not binaries? Did the abbreviation "src" not
give you a clue?
You said the 'tarballs include the dlls'. I associate tarballs with
source code, so I was mildly surprised, but I looked anyway. The other
file was mingw-packages.master.zip, but it would have taken forever to
unzip the lot looking for one file that probably wasn't there.
Try the link that is labelled "File:" - it is the msys2/mingw-w64
tarball with libgmp-10.dll and all the other files shown in the list
at the bottom of the page, under "Files:".
So: https://mirror.msys2.org/mingw/ucrt64/mingw-w64-ucrt-x86_64-gmp-6.3.0-2-any.pkg.tar.zst, obviously.
Meanwhile here is the library *I* had to use instead:
https://github.com/sal55/langs/tree/master/bignum
It is not exactly comparable, is it?
No. Mine was available when I needed it a decade or so ago. GMP dlls
were everywhere, mostly on dodgy-looking sites but every one was
different. Then you had the job of finding a matching gmp.h file.
If all you need is some simple arithmetic done in a naïve school long
multiplication way, then the code is fine.
I needed support for big numbers in my interpreter. My product is well-integrated, and represents 5% of the 250KB interpreter size. The
above gmp DLL is 666KB so is a poor match.
On 12/03/2025 10:37, David Brown wrote:
On 11/03/2025 22:18, bart wrote:
I needed support for big numbers in my interpreter. My product is
well-integrated, and represents 5% of the 250KB interpreter size. The
above gmp DLL is 666KB so is a poor match.
Out of curiosity - how often are such big numbers needed and used with
your interpreter, excluding demos to show how to use big numbers?
64-bit arithmetic is enough for the huge majority of purposes outside
of cryptography and mathematics, and 128-bit arithmetic covers almost
all of the rest. Your code is not suitable for cryptography or
mathematics. So what is it used for? And could it have been handled
much more simply by using 128-bit fixed sizes?
How often are big numbers used in Python? There, its integer type transparently overflows into a big integer when needed (so C-style
algorithms that rely on being masked to 64 bits won't work).
In my language you have to explicitly request the bignum type. It is
used mainly for recreational code. Or sometimes to get accurate
reference results to compare against when working with 64-bit ints and floats.
(How big is a 128-bit range for example? I can just do 'print 2L**128'.)
I did have 128-bit support in my implementation language once, better
than gcc's in C since it also supported literals, and Print. I did think about using that instead of, or as well as, bignums. Maybe as the
default int type instead of 64 bits.
But, as you say, real needs beyond 64 bits are rare. When it is needed,
then they can be arbitrary large (forget 2**128, what about 2**1000000?
Or you want to look at Fibonacci numbers beyond fib(92) which is the
limit with int64).
In the end I dropped 128-bit numbers, because the only use-case, apart
from bragging about it, was supporting 128 bits in the self-hosted
compiler.
On 12/03/2025 12:14, bart wrote:
On 12/03/2025 10:37, David Brown wrote:
On 11/03/2025 22:18, bart wrote:
I needed support for big numbers in my interpreter. My product is
well-integrated, and represents 5% of the 250KB interpreter size.
The above gmp DLL is 666KB so is a poor match.
Out of curiosity - how often are such big numbers needed and used
with your interpreter, excluding demos to show how to use big
numbers? 64-bit arithmetic is enough for the huge majority of
purposes outside of cryptography and mathematics, and 128-bit
arithmetic covers almost all of the rest. Your code is not suitable
for cryptography or mathematics. So what is it used for? And could >>> it have been handled much more simply by using 128-bit fixed sizes?
How often are big numbers used in Python? There, its integer type
transparently overflows into a big integer when needed (so C-style
algorithms that rely on being masked to 64 bits won't work).
I'd imagine they are not often used, as a proportion of Python users,
and that 128-bit integers would be more than good enough in most situations. However, Python /is/ used in mathematics work, and big
numbers are useful there. And Python numbers are, like everything in Python, objects - each number is already a memory allocation, a struct,
a reference to a shared object. There's a lot of overhead even for a
simple integer. That means there is little extra cost for having the possibility of big numbers if the user wants them. Similarly, the rest
of Python is so large that the incremental cost for using shared GMP libraries (which are likely already installed on many systems) is minor.
And of course Python is used by millions - including people who
regularly need large integers. Your interpreter is used by you.
So again, how often do /you/ need big numbers in /your/ language?
(I'm not sure what you are talking about with "C-style algorithms that
rely on being masked to 64-bits". Are you suggesting that if badly
written C code is translated directly into bad Python code, it might not work?)
In the end I dropped 128-bit numbers, because the only use-case, apart
from bragging about it, was supporting 128 bits in the self-hosted
compiler.
Whereas in your interpreted language, the only reason for having
anything bigger than 64-bits seems to be for bragging about it. If you think that is worth the effort, that's fine - I've nothing against doing something like this for the fun of it. But it seems strange to get so worked up about how the GMP authors are forcing you to use dependencies
you don't want, and forcing you to write your own bignum code, when all
you really want is to be able to tell your users - you alone - that you support bignums so that you can calculate 2 ^ 128 and fib(92). It's a
lot of effort, and a lot of aggravation, for extremely little use.
On 12/03/2025 12:14, bart wrote:
On 12/03/2025 10:37, David Brown wrote:
On 11/03/2025 22:18, bart wrote:
I needed support for big numbers in my interpreter. My product is
well-integrated, and represents 5% of the 250KB interpreter size.
The above gmp DLL is 666KB so is a poor match.
Out of curiosity - how often are such big numbers needed and used
with your interpreter, excluding demos to show how to use big
numbers? 64-bit arithmetic is enough for the huge majority of
purposes outside of cryptography and mathematics, and 128-bit
arithmetic covers almost all of the rest. Your code is not
suitable for cryptography or mathematics. So what is it used
for? And could it have been handled much more simply by using
128-bit fixed sizes?
How often are big numbers used in Python? There, its integer type transparently overflows into a big integer when needed (so C-style algorithms that rely on being masked to 64 bits won't work).
I'd imagine they are not often used, as a proportion of Python users,
and that 128-bit integers would be more than good enough in most
situations. However, Python /is/ used in mathematics work, and big
numbers are useful there. And Python numbers are, like everything in Python, objects - each number is already a memory allocation, a
struct, a reference to a shared object. There's a lot of overhead
even for a simple integer. That means there is little extra cost for
having the possibility of big numbers if the user wants them.
Similarly, the rest of Python is so large that the incremental cost
for using shared GMP libraries (which are likely already installed on
many systems) is minor.
And of course Python is used by millions -
including people who regularly need large integers. Your interpreter
is used by you.
So again, how often do /you/ need big numbers in /your/ language?
(I'm not sure what you are talking about with "C-style algorithms
that rely on being masked to 64-bits". Are you suggesting that if
badly written C code is translated directly into bad Python code, it
might not work?)
In my language you have to explicitly request the bignum type. It
is used mainly for recreational code. Or sometimes to get accurate reference results to compare against when working with 64-bit ints
and floats.
(How big is a 128-bit range for example? I can just do 'print
2L**128'.)
I did have 128-bit support in my implementation language once,
better than gcc's in C since it also supported literals, and Print.
I did think about using that instead of, or as well as, bignums.
Maybe as the default int type instead of 64 bits.
But, as you say, real needs beyond 64 bits are rare. When it is
needed, then they can be arbitrary large (forget 2**128, what about 2**1000000? Or you want to look at Fibonacci numbers beyond fib(92)
which is the limit with int64).
In the end I dropped 128-bit numbers, because the only use-case,
apart from bragging about it, was supporting 128 bits in the
self-hosted compiler.
Whereas in your interpreted language, the only reason for having
anything bigger than 64-bits seems to be for bragging about it. If
you think that is worth the effort, that's fine - I've nothing
against doing something like this for the fun of it. But it seems
strange to get so worked up about how the GMP authors are forcing you
to use dependencies you don't want, and forcing you to write your own
bignum code, when all you really want is to be able to tell your
users - you alone - that you support bignums so that you can
calculate 2 ^ 128 and fib(92). It's a lot of effort, and a lot of aggravation, for extremely little use.
On 12/03/2025 16:32, Michael S wrote:
As already said by Bart, it is a bit of fun.
To me it sounds like sufficient reason.
Fun - or learning - are always perfectly good reasons for doing almost anything in programming as far as I am concerned (baring things like
writing malware for fun). And I can entirely appreciate the fun in
writing a bignum library, or supporting it in an interpreted language.
But I have trouble seeing the fun in endless complaints, blaming GMP
authors for not making Bart's life easier, insisting on limiting
everything in his build environment for no good reason, and all the rest
of it. Maybe Bart /does/ find that fun.
On 12/03/2025 14:58, David Brown wrote:
On 12/03/2025 12:14, bart wrote:
On 12/03/2025 10:37, David Brown wrote:
On 11/03/2025 22:18, bart wrote:
I needed support for big numbers in my interpreter. My product is
well-integrated, and represents 5% of the 250KB interpreter size.
The above gmp DLL is 666KB so is a poor match.
Out of curiosity - how often are such big numbers needed and used
with your interpreter, excluding demos to show how to use big
numbers? 64-bit arithmetic is enough for the huge majority of
purposes outside of cryptography and mathematics, and 128-bit
arithmetic covers almost all of the rest. Your code is not suitable
for cryptography or mathematics. So what is it used for? And
could it have been handled much more simply by using 128-bit fixed
sizes?
How often are big numbers used in Python? There, its integer type
transparently overflows into a big integer when needed (so C-style
algorithms that rely on being masked to 64 bits won't work).
I'd imagine they are not often used, as a proportion of Python users,
and that 128-bit integers would be more than good enough in most
situations. However, Python /is/ used in mathematics work, and big
numbers are useful there. And Python numbers are, like everything in
Python, objects - each number is already a memory allocation, a
struct, a reference to a shared object. There's a lot of overhead
even for a simple integer. That means there is little extra cost for
having the possibility of big numbers if the user wants them.
Similarly, the rest of Python is so large that the incremental cost
for using shared GMP libraries (which are likely already installed on
many systems) is minor. And of course Python is used by millions -
including people who regularly need large integers. Your interpreter
is used by you.
So again, how often do /you/ need big numbers in /your/ language?
(I'm not sure what you are talking about with "C-style algorithms that
rely on being masked to 64-bits". Are you suggesting that if badly
written C code is translated directly into bad Python code, it might
not work?)
It might be code like this where the top bits of left-shifts disappear:
z = ((Q[i]<<41)>>1)+((Q[i]<<39)>>1)+(carry>>1);
In the end I dropped 128-bit numbers, because the only use-case,
apart from bragging about it, was supporting 128 bits in the
self-hosted compiler.
Whereas in your interpreted language, the only reason for having
anything bigger than 64-bits seems to be for bragging about it. If
you think that is worth the effort, that's fine - I've nothing against
doing something like this for the fun of it. But it seems strange to
get so worked up about how the GMP authors are forcing you to use
dependencies you don't want, and forcing you to write your own bignum
code, when all you really want is to be able to tell your users - you
alone - that you support bignums so that you can calculate 2 ^ 128 and
fib(92). It's a lot of effort, and a lot of aggravation, for
extremely little use.
I see. So the real reason for your apparently friendly interest comes to light. It is just to trash everything I do and to be as condescending as hell.
On Wed, 12 Mar 2025 15:58:56 +0100
David Brown <[email protected]> wrote:
On 12/03/2025 12:14, bart wrote:
On 12/03/2025 10:37, David Brown wrote:
On 11/03/2025 22:18, bart wrote:
I needed support for big numbers in my interpreter. My product is
well-integrated, and represents 5% of the 250KB interpreter size.
The above gmp DLL is 666KB so is a poor match.
Out of curiosity - how often are such big numbers needed and used
with your interpreter, excluding demos to show how to use big
numbers? 64-bit arithmetic is enough for the huge majority of
purposes outside of cryptography and mathematics, and 128-bit
arithmetic covers almost all of the rest. Your code is not
suitable for cryptography or mathematics. So what is it used
for? And could it have been handled much more simply by using
128-bit fixed sizes?
How often are big numbers used in Python? There, its integer type
transparently overflows into a big integer when needed (so C-style
algorithms that rely on being masked to 64 bits won't work).
I'd imagine they are not often used, as a proportion of Python users,
and that 128-bit integers would be more than good enough in most
situations. However, Python /is/ used in mathematics work, and big
numbers are useful there. And Python numbers are, like everything in
Python, objects - each number is already a memory allocation, a
struct, a reference to a shared object. There's a lot of overhead
even for a simple integer. That means there is little extra cost for
having the possibility of big numbers if the user wants them.
Similarly, the rest of Python is so large that the incremental cost
for using shared GMP libraries (which are likely already installed on
many systems) is minor.
Default Python integer is not GMP. GMP can be used from Python and
doing it is much easier than using GMP from C, but it is not transparent
to programmer.
We discussed it relatively recently on comp.lang.c++. See Message-ID: <[email protected]> and following short sub-thread.
And of course Python is used by millions -
including people who regularly need large integers. Your interpreter
is used by you.
So again, how often do /you/ need big numbers in /your/ language?
(I'm not sure what you are talking about with "C-style algorithms
that rely on being masked to 64-bits". Are you suggesting that if
badly written C code is translated directly into bad Python code, it
might not work?)
Huh?
In C default modulo arithmetic on unsigned numbers is 100% standard and
is used in plenty of well-written C code.
Whereas in your interpreted language, the only reason for having
anything bigger than 64-bits seems to be for bragging about it. If
you think that is worth the effort, that's fine - I've nothing
against doing something like this for the fun of it. But it seems
strange to get so worked up about how the GMP authors are forcing you
to use dependencies you don't want, and forcing you to write your own
bignum code, when all you really want is to be able to tell your
users - you alone - that you support bignums so that you can
calculate 2 ^ 128 and fib(92). It's a lot of effort, and a lot of
aggravation, for extremely little use.
As already said by Bart, it is a bit of fun.
To me it sounds like sufficient reason.
I also feel it is wrong to paint Windows as a poor machine for
development, simply because it is not a Unix clone.
On Wed, 12 Mar 2025 17:12:34 +0000, bart wrote:
I also feel it is wrong to paint Windows as a poor machine for
development, simply because it is not a Unix clone.
The fact that Windows developers themselves are unable to improve the situation is all the justification we need.
On 13/03/2025 00:08, Lawrence D'Oliveiro wrote:
On Wed, 12 Mar 2025 17:12:34 +0000, bart wrote:
I also feel it is wrong to paint Windows as a poor machine for
development, simply because it is not a Unix clone.
The fact that Windows developers themselves are unable to improve the
situation is all the justification we need.
Improve what situation?
Unix based developers insist of using some nonsense called XYZZY for
all their projects, which only works on Unix, and Windows is at
fault for not immediately implementing XYZZY too?
On Thu, 13 Mar 2025 00:33:27 +0000, bart wrote:
On 13/03/2025 00:08, Lawrence D'Oliveiro wrote:
On Wed, 12 Mar 2025 17:12:34 +0000, bart wrote:
I also feel it is wrong to paint Windows as a poor machine for
development, simply because it is not a Unix clone.
The fact that Windows developers themselves are unable to improve the
situation is all the justification we need.
Improve what situation?
The one you’ve been complaining about.
Unix based developers insist of using some nonsense called XYZZY for
all their projects, which only works on Unix, and Windows is at
fault for not immediately implementing XYZZY too?
It’s their fault for wanting to run the Unix software, instead of developing their own.
On 3/10/2025 2:55 PM, Kaz Kylheku wrote:
I tried to email you back but it got kicked back.
On 3/11/2025 11:50 PM, Lawrence D'Oliveiro wrote:
On Tue, 11 Mar 2025 21:22:22 -0700, Chris M. Thomasson wrote:
On 3/11/2025 8:12 PM, Lawrence D'Oliveiro wrote:
On Tue, 11 Mar 2025 20:04:30 -0700, Chris M. Thomasson wrote:
IOCP works fine ...
But not with pipes.
Never tried them with pipes, only sockets.
The Python developers have tried. They ended up creating two event loop
implementations on Windows, neither of which quite covers all the bases
<https://docs.python.org/3/library/asyncio-eventloop.html#event-loop-implementations>.
For some damn reason, I don't think you have tried IOCP with sockets,
pipes, ect, even Linux AIO?
The reason for half the UBs is because some operation is badly defined
on whacko architecture which accounts for 0.00001% of machines.
But here qq.m is the lead module of several dozen comprising the
project, plus there are embedded support files.
Tim Rentsch <[email protected]> wrote:
bart <[email protected]> writes:
On 05/03/2025 23:36, Tim Rentsch wrote:
bart <[email protected]> writes:
[long list of features]
My understanding is that it is missing the two most important
features of a programming language:
(1) a user manual that defines and documents the language
(2) an available implementation so that other people can
use it to write programs
The 1990s version, where it supported a substantial application,
had a 350-page manual. That one was used by other people to
create add-on products.
But it's now a personal tool and I only have reference material
for my own use.
If you post some links where I can download a current user
manual and a current compiler or interpreter, I will gladly
withdraw my comment.
Otherwise, I stand by my comment, and see no reason to
consider your alleged environment as anything other than
fiction-ware.
Bart has a project on github. In the past he provides part
of source code for his languages. More precisely, he provided
generated C source code for C compiler, generated C source
code for implementation of his "dynamic" Q language, and
source for compiler of his M language (in Q). So, those
things existed and run times were consitent with what he
claimed. AFAICS parts of source we missing, and it seems
that he later removed the sources from github.
Here however is a summary of these fictional tools:
https://github.com/sal55/langs/blob/master/CompilerSuite.md
If you think you know something the Python developers overlooked in
their Windows implementation, feel free to tell us about it.
Yet when it comes to *building* software, which is just another kind of application, then apparently only Unix-like exists.
On 11/03/2025 01:33, Waldek Hebisch wrote:
bart <[email protected]> wrote:
On 10/03/2025 10:58, Waldek Hebisch wrote:
bart <[email protected]> wrote:
I think nobody does. There's always been some sort of mystique
surrounding 'gcc' on Windows.
'MinGW' supposedly 'Minimalist Gnu on Windows'. In that case I wouldn't >>>>> like to see the full-scale one..
"Minimalist" is not about size of the compiler. Rather, it is
about possible support routines. For "hosted implementation" C
mandates presence of C library and there is a lot of functions
not in C standard, but included in libraries of C compilers.
There is also question of operating system support, complicated
by fact that Windows is different than other systems. Cygwin
solved those issues by offering Posix emulation and a sizable
collection os libraries. MinGW is minimalist in the sense
that it provides very little own libraries and mainly uses
what is provide by Windows.
I still don't get this stuff.
I get the impression that a port of gcc to Windows is not simply about
building C programs, but building C programs that use a lot of features
from Linux.
You apparently do not get fact that people want tools to
automate various routine tasks.
What routine task is this? I'm talking exclusively about turning a bunch
of source files in some language (here it is C) into an executable binary.
This task can be done with a program called a 'compiler'.
However, what I'm arguing about is that this simple task has become unnecessarily elaborate on OSes like Linux, by introducing makefiles, OS-specific scripts, and OS-specific utilities.
This is done even on smaller, simple applications, and also on those
that are supposedly cross-platform that are to be built on the target.
If scripts are going to be used, then use them at the developer site
only, and make the script generate the streamlined set of files for the particular platform of interest.
It should not rely on anything that is not native to the target platform.
And people do not want
to reinvent the wheel, they prefer to use code written
by others.
What wheels are these that are being reinvented? I'm simply arguing for
using either 2 or 4 wheels, not 18!
And I'm not suggesting reinventing those 2/4 either, just using the ones
I have on my OS.
Folks at Bell Labs had several good ideas
and shared them with others. Those ideas are not limited
to Linux or Unix, you can look at old "Software tools in ..."
books to understand what I am talking about. MinGW
_distribution_ bundles several tools. This allows you
to compile programs when build process uses those tools.
You can also use the tools for your purpose. Aparently
you have very strong "not invented here" syndrom and
insist on usig your own tools.
That's another aspect of it which is not that relevant, other than it
shows just how simple things could be.
To build open source projects, I'm happy to use an existing C compiler.
I'm NOT happy about bending over backwards to use CYGWIN, MSYS2 or WSL because the developers insist on forcing their Linux dependencies down
my throat.
(Those developers also seem to think that the only alternative to MSYS2, configure scripts etc is to use the monstrosity that is MS Visual Studio
and all it comprises.)
If an application is written in C, then a C compiler should suffice.
That is fine, as long
as you keep this to yourselfs. But refusing other
folks right to use tools they want to use is not
fair.
Developers can do what they like. But they shouldn't inflict their
choices on other people, especially those using other OSes.
Or, to put it differently, when you refuse
the tools _you_ need to do by hand needed work.
You may be able to extract from work of others
something that fits your taste (like list of files
to compile), but that is your business.
Fine. In that case tell me what the files are! Lua actually does this
(but it's not obvious, it's also unexpected since the majority of apps
are unhelpful in such matters).
When I tried to build A68G, the whole build process, under VirtualBox
Linux, took 5 minutes. I couldn't build under Windows because of a 30,000-line bash script.
However, with some effort, I was able to isolate the C files needed, and fortunately there was no synthesised code. Given that list of 12 files
(!) building the app on Windows took my compiler one second.
If so, then that's the wrong approach. There are various lesser
compilers which know nothing about mingw or posix of anything of the
sort. (For example, lccwin32, DMC, PellesC, I think Tiny C; I can't
speak for MSVC.)
You may be able to do some things using just a C compiler.
But requesting people to do other things by hand is as
wise as requesting them to code in assembler
What things, what assembly? I'm talking about building a program written
in a HLL using an existing compiler.
That seems reasonable enough, yes?
The only info needed is the list of files to submit to said compiler.
(assembler
may be converted to binary faster than C, and with enough
effort resulting binary will run faster than result of
C compilation :). Another thing are libraries and
bigger applications. Some folks want "true Windows look
and feel", some say that proper Windows DLL must be
compiled by MSVC
Any C compiler for Windows can generate DLL files.
(otherwise is lack some features that
they consider essential). But there are people who
had to or wanted to use Windows, but also wanted to
use Unix applications. Cygwin was addressed to such
folks: it allows you to compile substantial Unix
application so that it runs on Windows. If you have
no interest in such applications, than fine, Cygwin
is probably not for you. Today WSL may be better
for such a goal, but in the past Cygwin provided
easiest way to port Unix application to Windows.
If easy port was the goal and application was
substantial, then Cygwin usually was right choice.
As I understand it, POSIX is about 80 header files, of which ~30 are the standard C headers, leaving 50 POSIX headers that do not exist on Windows.
If your Linux app uses those headers, and you want to port it to
Windows, then you have problems to solve.
But I would question whether the apps I want to build need all that. How
does POSIX figure in the GMP library for example?
Why does so much code use open() for example instead of the standard
fopen()?
So, not only are people relying the Linux eco-system for the build
process, but they are also needlessly using POSIX-specific headers.
C is supposed to be that famous portable HLL, but in developer's minds, 'portable' seems to mean working only on any Unix-like system!
(My language, not C, has a std library that includes some OS
functionality. But those are wrapped in a set of functions that reside
in one OS-specific module, that provides the same API across Windows and Linux.
For example, the function 'os_getdllinst' is implemented on top of 'LoadLibrary' on Windows, and 'dlopen' on Linux.
What I don't do is directly use LoadLibrary, and insist that people
running it on Linux have to install some emulation library to provide
that Windows functionality. Which wouldn't work anyway as it would also
work with .dll files rather than .so files.
You see the kind of thought I put into this stuff? I wish others would
do the same! Instead of being so 'provincial'.)
To put it differenly, you could compile program in one computer
and get relatively small program which runs OK on different
Windows machines because libraries it needs are already present.
This is quite different compared to Cygwin, where you need to
install Cygwin libraries before normal Cygwin program can run
(I write about normal programs because actual compiler in
Cygwin and Mingw used to be the same and with some tweaks one
could use Cygwin compiler to produce MinGW execuatbles).
I'm not interested in whatever Cygwin or Mingw are about.
Oh, so you do not want to know. In such case why you started
discussing it?
Because it comes up everwhere that gcc is used on Windows?
I started by saying I didn't know exactly what Mingw was. I used to
think it was the compiler, and indeed obtaining gcc used to involve
visiting sites where 'mingw' or 'mingw64' names figured heavily.
Some of my gcc files also have 'mingw32' in them; I don't know why:
c:\tdm\bin>fc gcc.exe x86_64-w64-mingw32-gcc.exe
Comparing files gcc.exe and X86_64-W64-MINGW32-GCC.EXE
FC: no differences encountered
Apparently it is to do with some boring functions discussed in parallel subthreads.
If I were to
use libraries not part of the OS, then it would be ones like SDL2 to get >>> interesting things done. Not try and emulate bits of Linux that I'd
never heard of.
I mentioned one case: about 90% of code in "my" library was
provided in fact by other libraries. So using code provided
by other saved me a lot of work, turning something that
otherwise could be multiyear job into reasonably small effort.
Sure. Then just provide the binaries which somebody (or even some
script) can build once, on a machine where everything is known to work.
This suits Windows which has famous binary compatibility. (If there is a 32-bit version of Windows 11, it can probably still run my 1990s 16-bit binaries!)
To use the libraries I had to work out build process, thanks
to tools it was very easy.
Thanks to tools designed to work within a labyrinthine build
environment, working within such an environment.
Purely as an exercise, could you have produced a minimal viable bundle
of source files, compiler (or recommendation for one), readme and what
ever else was necessary, that would work in an alien environment? Say, Windows.
MinGW bundle is a good way to build such libraries. Having
only a C compiler may be too little.
All I can say is that if /I/ produce software expressed in C, then you
need a C compiler to run it.
I have no idea how the Python dev's use IOCP with sockets.
On Tue, 11 Mar 2025 20:52:19 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wibbled:
How much are you going to pay?
Nothing, because who knows what libc will do if the descriptor exceeds
that soft limit.
bart <[email protected]> wrote:
But I would question whether the apps I want to build need all that. How
does POSIX figure in the GMP library for example?
Well, GMP needs some way to signal division by 0. Which in principle
do not require system stuff, but maybe they use something to
do it nicer.
bart <[email protected]> wrote:
On 11/03/2025 01:33, Waldek Hebisch wrote:
bart <[email protected]> wrote:
On 10/03/2025 10:58, Waldek Hebisch wrote:
bart <[email protected]> wrote:
I think nobody does. There's always been some sort of mystique
surrounding 'gcc' on Windows.
'MinGW' supposedly 'Minimalist Gnu on Windows'. In that case I
wouldn't like to see the full-scale one..
"Minimalist" is not about size of the compiler. Rather, it is
about possible support routines. For "hosted implementation" C
mandates presence of C library and there is a lot of functions
not in C standard, but included in libraries of C compilers.
There is also question of operating system support, complicated
by fact that Windows is different than other systems. Cygwin
solved those issues by offering Posix emulation and a sizable
collection os libraries. MinGW is minimalist in the sense
that it provides very little own libraries and mainly uses
what is provide by Windows.
I still don't get this stuff.
I get the impression that a port of gcc to Windows is not simply
about building C programs, but building C programs that use a lot
of features from Linux.
You apparently do not get fact that people want tools to
automate various routine tasks.
What routine task is this? I'm talking exclusively about turning a
bunch of source files in some language (here it is C) into an
executable binary.
This task can be done with a program called a 'compiler'.
You ignore fact that people are developing programs. And developement
is much more than "turning a bunch of source files into an
executable". GPL says "The source code for a work means the preferred
form of the work for making modifications to it". And that nicely
captures the idea: sources are in form that is convenient for
developer and may require several steps before one gets the
executable.
However, what I'm arguing about is that this simple task has become unnecessarily elaborate on OSes like Linux, by introducing
makefiles, OS-specific scripts, and OS-specific utilities.
There is not much OS-specific in "Linux tools". 'make' is
problematic on zOS, because files have no timestamps there,
but most normal OS-es have timestamps (and IIUC even zOS
has USS where timestamps are available). You need ability
to invoke a program from a different program, exact form
of this is OS-dependent, but ability is there in any
semi-reasonable general purpose OS. You need ability
to get exit status of a program, again exact form is
OS-dependent but ability is there.
FYI, is started using "Linux tools" on MS-DOS, before I
heard about Linux. And tools are widely available,
IIUC classic zOS is problematic, but I think that USS
is OK. Some systems may be prone to breakage, when
there is small number of _active_ users and nobody bothers
to timely report real problems.
Coming back to developement, in many cases it is desirable
to generate some C files. C preprocessor can do some
transformations, but is may be convenient to transform
source in a way hard to do via proprocessor. Also,
this is C group, but big programs frequently have parts
in different languages, an then it is good to have
language-neutral tools. Simple tools to transform
or generate files are 'sed' and 'awk'. Some people
use 'perl' or 'python' for such purpose and in principle
there is much more possiblities.
More specialised are compiler-writing tools like 'bison'
and 'flex'. You can write a parser by hand, but using
'bison' one does not need to know much to write working
parser. 'flex' helps in writing scanners, but IMO
is quite useful for text processing task (its support
for regular expressions is nicer than Perl or Python
offer, and speed frequently is much better too).
Users beside binary need also documentation. In principle
documentation could be provided as plain text, but there
is now tendency to offer nicely formatted documentation
and to offer multiple formats. Which means that there is
need for formatting tools. Old ones are Texinfo and TeX.
And some moment there was push towards SGML and formats
like DocBook. This needs appropriate tools. Some people
now prefer tools like 'sphinx' (which needs Python with
several extention packages). There is 'doxygen' which
extract information from source files and presents nicely
formated info about API (I am not a fan of 'doxygen' but
is seems to be widely used).
Beside building program and documentation one wants some
automatic way of running tests. And people want to
automate more tasks, for example removal of generated
files or installation.
Automation requires some scripting language. For authors
of free programs important point is free availability
(preferably with sources) of choosen language. That
ruled out things like MS Basic or 'command.com' (and
'command.com' is quite limited). Unix shell was
available as port of OS on Unix systems and quite early
there were free ports of Unix shell to other systems.
So there were natural preference to Unix shell, simply
because of wide availability. Similarly with other
classic Unix tools. One can argue that those classic
tools are now dated, but there is stong inertia in
action: tools are widely used, widely availeble, there
is knowldege how to use them so people keep using them.
When one thinks about possible replacements, it is not an
easy job. Namely, Unix tools evolved and are designed
to work together. Different tool either must cooperate
nicely with existing tools, which forces similar
behaviour to current tools, or must provide replacement
for the whole toolkit which is much more complicated
than replacing a single tool.
When you look at bloat, I expect competing tools to be
much more bloated than classic Unix tools. Namely,
Unix tools were designed to be simple and power comes
from possibility to compose them. It is hard to
imagine way of composing tools that is both simple
and offers more possibilities than Unix way. So
one can have simpler/smaller tools but less powerful.
Or one can increase fuctionality of each tools separately
(to some degree this is happening with Unix tools), but
this increases complexity of each tool. One can try
to make one tool that replaces the whole toolkit, but
experiance suggest that such a single tool would be
much more complicated. To summarize, more powerful
tools are likely to be more complicated, hence more
bloated than classic Unix tools. Given that classic
Unix tools are quite small compared to modern systems
(they can be implemented in few megabytes of code)
incentive to make smaller tools is rather low.
This is done even on smaller, simple applications, and also on
those that are supposedly cross-platform that are to be built on
the target.
You can have basic toolkit running on rather wide set of systems.
So this is not a big burden for recipients, in particuar since
the same toolkit may be used to build many programs.
If scripts are going to be used, then use them at the developer
site only, and make the script generate the streamlined set of
files for the particular platform of interest.
Current free software ecosystem is colaborative work of many people.
In particular, there are people creating binary packages and if
all you want is running binary you may be better off getting a
package from them. Now, people creating binaries want to do
this in an automated way. For them having to give a list of files
to compiler each time when they build a package is too mach work.
They have scripts that fetch sources from the net, check checksums
(to verify authenticity), run 'configure' and 'make'. They are
willing to install tools which are needed for this work.
It should not rely on anything that is not native to the target
platform.
Why not? You already admited that one need a compiler. While
a bunch of tiny tools should be a blocker?
And people do not want
to reinvent the wheel, they prefer to use code written
by others.
What wheels are these that are being reinvented? I'm simply arguing
for using either 2 or 4 wheels, not 18!
And I'm not suggesting reinventing those 2/4 either, just using the
ones I have on my OS.
Well, one trouble is that things you have on your preferred OS are
not free, one can not use them legally on a different OS. And when
it comes to developement tools what cames with basic install of
your OS seem to be quite limited. No law prevents you from installing
free tools and that is simplest solution.
Alternative is extra work for developers to reproduce what tool do
within program, that would be reinventing the wheel. Or some
intermedate stages between binary and source, which require extra
work and there seem to be small interest in such things (say
hundreds of people among milions using free software).
Folks at Bell Labs had several good ideas
and shared them with others. Those ideas are not limited
to Linux or Unix, you can look at old "Software tools in ..."
books to understand what I am talking about. MinGW
_distribution_ bundles several tools. This allows you
to compile programs when build process uses those tools.
You can also use the tools for your purpose. Aparently
you have very strong "not invented here" syndrom and
insist on usig your own tools.
That's another aspect of it which is not that relevant, other than
it shows just how simple things could be.
To build open source projects, I'm happy to use an existing C
compiler. I'm NOT happy about bending over backwards to use CYGWIN,
MSYS2 or WSL because the developers insist on forcing their Linux dependencies down my throat.
As I explained they want to use tools. Some tools may be problematic,
but I see no reason to reject base tools. For most programs you do
not need to CYGWIN or WSL. Concerning MSYS2, IIUC they reuse small
part of Cygwin to support developement tools. If for some reason
you find this problematic, you may invest some time in making
the tools more pure, that is using native Windows calls instead
of Posix emulation provided by Cygwin. Some of this was done
to improve performance, but for people using MSYS2 performance
seem to be OK and clearly using native calls Windows calls on
Windows means that there need to be special variant for Windows
which adds extra work, so they have little motivation to remove
all traces of Cygwin. If you are concerned about bloat, then
you should take into account that base tools can be quite
small (of order of few megabytes for whole toolkit).
If you object using tools that behave the same on Linux and
Windows, then really developers insist on this. Simply,
using common tools is basic survival strategy. Otherwise
they would have to spend effort on incompatible "Windows
native toolkit" which would fragment developement effort.
Using no tools may work for very simple projects, but
means too much extra work in other cases.
Extra remark: in one case I asked people using a program
on Windows which way is most convenient for them. Rather
old answer was "And Linux" (which was a package allowing
to run Linux binaries on Windows), modern answer was WSL.
You see, people were interested in shortest way to get
running program, not about purity of approach.
(Those developers also seem to think that the only alternative to
MSYS2, configure scripts etc is to use the monstrosity that is MS
Visual Studio and all it comprises.)
You see, people that use Windows also want to use tools. And
when they do not like or can not use simpler tools they go to
Visual Studio.
If an application is written in C, then a C compiler should suffice.
That is fine, as long
as you keep this to yourselfs. But refusing other
folks right to use tools they want to use is not
fair.
Developers can do what they like. But they shouldn't inflict their
choices on other people, especially those using other OSes.
Well, I use Linux and can maintain X based GUI. Since I do
not have Windows I can not create native Windows GUI. And
while there were several significant contributors to the
program (some working on Windows), nobody volunteered to
create Windows GUI. So ATM for this program the only way
to get GUI on Windows is to use Cygwin and X library provided
by Cygwin or run Linux version under WSL. AFAIK related
approach was used by several commercial vendors providing
both Unix and Windows versions of their programs: they used
X based GUI, on Windows linked with commercial X library and
connected to available X server. So, simply since "cost" of
providing native GUI is too high, programs used X based GUI.
I do not know why you develop software. For me significant
part is fun, in particular that I can do "interesting"
things with moderate effort. But all that fun disappears
if somebody want we to do a lot of work for no good
reason (beyond "I want it that way"). There were cases
when I wanted things some way and spent effort to make
them work that way. I do not complain that other
developers did not want to do work for me.
Or, to put it differently, when you refuse
the tools _you_ need to do by hand needed work.
You may be able to extract from work of others
something that fits your taste (like list of files
to compile), but that is your business.
Fine. In that case tell me what the files are! Lua actually does
this (but it's not obvious, it's also unexpected since the majority
of apps are unhelpful in such matters).
When I tried to build A68G, the whole build process, under
VirtualBox Linux, took 5 minutes. I couldn't build under Windows
because of a 30,000-line bash script.
IME shell scripts usually were no problem, except for possibly
requiring some patience (they run significantly slower than on
Linux). In one case 'configure' script was really problematic,
that is for about 2 weeks Windows NT 4.0 kept crashing, guy
wanting to compile program restarted Windows, 'configure' made
some progress and then Windows crashed again. After 2 weeks
the guy gave up, run configure on Linux (I think it was the
same hardware), 'configure' needed 2 hours on Linux, but
went fine. Then some extra hours to compile the program.
Note that there were _system_ crashes running otherwise ordinary
program. However, Windows now seem to be much more reliable,
so I do not expect trouble like this. And the mentioned 'configure'
script on Linux run exceptionally long.
However, with some effort, I was able to isolate the C files
needed, and fortunately there was no synthesised code. Given that
list of 12 files (!) building the app on Windows took my compiler
one second.
If so, then that's the wrong approach. There are various lesser
compilers which know nothing about mingw or posix of anything of
the sort. (For example, lccwin32, DMC, PellesC, I think Tiny C; I
can't speak for MSVC.)
You may be able to do some things using just a C compiler.
But requesting people to do other things by hand is as
wise as requesting them to code in assembler
What things, what assembly? I'm talking about building a program
written in a HLL using an existing compiler.
That seems reasonable enough, yes?
The only info needed is the list of files to submit to said
compiler.
If thats to the only needed info than Makefile.in (thing used as
a template for Makefile) should contain something like:
SRCS = file1.c file2.c fileN.c
and list of files would be easy to extract from Makefile.in
(just look for list of files). But usually there is more to
this, like compiler flags, generated headers, etc. And the
list of files usually depends on OS and possibly other
factors.
(assembler
may be converted to binary faster than C, and with enough
effort resulting binary will run faster than result of
C compilation :). Another thing are libraries and
bigger applications. Some folks want "true Windows look
and feel", some say that proper Windows DLL must be
compiled by MSVC
Any C compiler for Windows can generate DLL files.
I am not an expert on Windows features. But one things was
that they wanted "components". Another was exception handling.
So "just a DLL" was too little for them.
(otherwise is lack some features that
they consider essential). But there are people who
had to or wanted to use Windows, but also wanted to
use Unix applications. Cygwin was addressed to such
folks: it allows you to compile substantial Unix
application so that it runs on Windows. If you have
no interest in such applications, than fine, Cygwin
is probably not for you. Today WSL may be better
for such a goal, but in the past Cygwin provided
easiest way to port Unix application to Windows.
If easy port was the goal and application was
substantial, then Cygwin usually was right choice.
As I understand it, POSIX is about 80 header files, of which ~30
are the standard C headers, leaving 50 POSIX headers that do not
exist on Windows.
If your Linux app uses those headers, and you want to port it to
Windows, then you have problems to solve.
But I would question whether the apps I want to build need all
that. How does POSIX figure in the GMP library for example?
Well, GMP needs some way to signal division by 0. Which in principle
do not require system stuff, but maybe they use something to
do it nicer.
GMP need memory allocation, which can be done via
'malloc' but also my be dan via system calls.
On Wed, 12 Mar 2025 08:11:45 -0000 (UTC), Muttley wrote:
On Tue, 11 Mar 2025 20:52:19 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wibbled:
How much are you going to pay?
Nothing, because who knows what libc will do if the descriptor exceeds
that soft limit.
But you said “I'd bet money on the kernel/libc authors taking this into >account when allocating user space descriptor values”. But they didn’t -- >otherwise we *would* know what libc would do, and you yourself have
admitted that we don’t. Therefore you have lost the bet. QED.
On 14/03/2025 09:32, Michael S wrote:
.... a 405-line article, of which 387 lines were >chevron-quoted.
Learn to snip! Furrfu FCOL etc etc.
On Fri, 14 Mar 2025 00:37:48 -0000 (UTC)
[email protected] (Waldek Hebisch) wrote:
GMP need memory allocation, which can be done via
'malloc' but also my be dan via system calls.
=20
I am pretty sure that they don't use system calls.
On Fri, 14 Mar 2025 09:54:07 +0000
Richard Heathfield <[email protected]> wrote:
On 14/03/2025 09:32, Michael S wrote:
.... a 405-line article, of which 387 lines were >chevron-quoted.
Learn to snip! Furrfu FCOL etc etc.
I know, I know. I mean, *after* I hit 'Send' button, I know.
On Fri, 14 Mar 2025 01:47:02 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wibbled:
On Wed, 12 Mar 2025 08:11:45 -0000 (UTC), Muttley wrote:
On Tue, 11 Mar 2025 20:52:19 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wibbled:
How much are you going to pay?
Nothing, because who knows what libc will do if the descriptor exceeds
that soft limit.
But you said “I'd bet money on the kernel/libc authors taking this into >>account when allocating user space descriptor values”. But they didn’t -- >>otherwise we *would* know what libc would do, and you yourself have >>admitted that we don’t. Therefore you have lost the bet. QED.
You can't lose a bet if the race hasn't even started. Someone would need to exam
ine the
libc code and check. I have better things to do.
bart <[email protected]> wrote:
This task can be done with a program called a 'compiler'.
You ignore fact that people are developing programs.
And developement
is much more than "turning a bunch of source files into an executable".
GPL says "The source code for a work means the preferred form of
the work for making modifications to it". And that nicely captures
the idea: sources are in form that is convenient for developer
and may require several steps before one gets the executable.
FYI, is started using "Linux tools" on MS-DOS, before I
heard about Linux. And tools are widely available,
IIUC classic zOS is problematic, but I think that USS
is OK. Some systems may be prone to breakage, when
there is small number of _active_ users and nobody bothers
to timely report real problems.
Coming back to developement, in many cases it is desirable
to generate some C files. C preprocessor can do some
transformations, but is may be convenient to transform
source in a way hard to do via proprocessor. Also,
this is C group, but big programs frequently have parts
in different languages, an then it is good to have
language-neutral tools. Simple tools to transform
or generate files are 'sed' and 'awk'. Some people
use 'perl' or 'python' for such purpose and in principle
there is much more possiblities.
More specialised are compiler-writing tools like 'bison'
and 'flex'. You can write a parser by hand, but using
'bison' one does not need to know much to write working
parser. 'flex' helps in writing scanners, but IMO
is quite useful for text processing task (its support
for regular expressions is nicer than Perl or Python
offer, and speed frequently is much better too).
Users beside binary need also documentation. In principle
documentation could be provided as plain text,
but there
is now tendency to offer nicely formatted documentation
(they can be implemented in few megabytes of code)
incentive to make smaller tools is rather low.
platform.It should not rely on anything that is not native to the target
Why not? You already admited that one need a compiler. While
a bunch of tiny tools should be a blocker?
And I'm not suggesting reinventing those 2/4 either, just using the ones
I have on my OS.
Well, one trouble is that things you have on your preferred OS are
not free, one can not use them legally on a different OS.
it comes to developement tools what cames with basic install of
your OS seem to be quite limited. No law prevents you from installing
free tools and that is simplest solution.
Alternative is extra work for developers to reproduce what tool do
within program, that would be reinventing the wheel.
Or some
intermedate stages between binary and source, which require extra
work and there seem to be small interest in such things (say
hundreds of people among milions using free software).
Otherwise
they would have to spend effort on incompatible "Windows
native toolkit" which would fragment developement effort.
Using no tools may work for very simple projects, but
means too much extra work in other cases.
(Those developers also seem to think that the only alternative to MSYS2,
configure scripts etc is to use the monstrosity that is MS Visual Studio
and all it comprises.)
You see, people that use Windows also want to use tools.
If an application is written in C, then a C compiler should suffice.
That is fine, as long
as you keep this to yourselfs. But refusing other
folks right to use tools they want to use is not
fair.
Developers can do what they like. But they shouldn't inflict their
choices on other people, especially those using other OSes.
Well, I use Linux and can maintain X based GUI. Since I do
not have Windows I can not create native Windows GUI. And
while there were several significant contributors to the
program (some working on Windows), nobody volunteered to
create Windows GUI. So ATM for this program the only way
to get GUI on Windows is to use Cygwin and X library provided
by Cygwin or run Linux version under WSL.
I do not know why you develop software.
For me significant
part is fun, in particular that I can do "interesting"
things with moderate effort. But all that fun disappears
if somebody want we to do a lot of work for no good
reason (beyond "I want it that way").
went fine. Then some extra hours to compile the program.
C is supposed to be that famous portable HLL, but in developer's minds,
'portable' seems to mean working only on any Unix-like system!
All general purpose OS-es that I know provide files and some
form of 'open'. Of course, that needs system specific headers.
On systems providing POSIX headers one can just use POSIX, for
others do whatever given system need to be done.
(My language, not C, has a std library that includes some OS
functionality. But those are wrapped in a set of functions that reside
in one OS-specific module, that provides the same API across Windows and
Linux.
For example, the function 'os_getdllinst' is implemented on top of
'LoadLibrary' on Windows, and 'dlopen' on Linux.
What I don't do is directly use LoadLibrary, and insist that people
running it on Linux have to install some emulation library to provide
that Windows functionality. Which wouldn't work anyway as it would also
work with .dll files rather than .so files.
You see the kind of thought I put into this stuff? I wish others would
do the same! Instead of being so 'provincial'.)
Your library stuff is nice. I am not sure why you find 'open'
troubling? AFAIR it was available in C libraries of DOS and
Windows compilers that I used (IIRC there was some part talking
about '_open' which was supposed to be more official interface,
but one could make plain 'open' to work).
to getTo put it differenly, you could compile program in one computer
and get relatively small program which runs OK on different
Windows machines because libraries it needs are already present.
This is quite different compared to Cygwin, where you need to
install Cygwin libraries before normal Cygwin program can run
(I write about normal programs because actual compiler in
Cygwin and Mingw used to be the same and with some tweaks one
could use Cygwin compiler to produce MinGW execuatbles).
I'm not interested in whatever Cygwin or Mingw are about.
Oh, so you do not want to know. In such case why you started
discussing it?
Because it comes up everwhere that gcc is used on Windows?
I started by saying I didn't know exactly what Mingw was. I used to
think it was the compiler, and indeed obtaining gcc used to involve
visiting sites where 'mingw' or 'mingw64' names figured heavily.
Some of my gcc files also have 'mingw32' in them; I don't know why:
c:\tdm\bin>fc gcc.exe x86_64-w64-mingw32-gcc.exe
Comparing files gcc.exe and X86_64-W64-MINGW32-GCC.EXE
FC: no differences encountered
Apparently it is to do with some boring functions discussed in parallel
subthreads.
The 'x86_64-w64-mingw32' part is so called target triple, it
specifies on which system binaries produced by the compiler
are supposed to run. 'mingw' really means using Microsoft
libraries. I am not sure what _exactly_ this combination
means, it could mean 32-bit code which can only be run on
64-bit Windows. Or 64-bit code that uses library confusingly
named 'mingw32'.
If I was really interested I could try to build on Linux
gcc with such a target and look what it produces, but
I do not thing we are interested enough in the answer to
do this.
If I were to
use libraries not part of the OS, then it would be ones like SDL2
interesting things done. Not try and emulate bits of Linux that I'd
never heard of.
I mentioned one case: about 90% of code in "my" library was
provided in fact by other libraries. So using code provided
by other saved me a lot of work, turning something that
otherwise could be multiyear job into reasonably small effort.
Sure. Then just provide the binaries which somebody (or even some
script) can build once, on a machine where everything is known to work.
This suits Windows which has famous binary compatibility. (If there is a
32-bit version of Windows 11, it can probably still run my 1990s 16-bit
binaries!)
To use the libraries I had to work out build process, thanks
to tools it was very easy.
Thanks to tools designed to work within a labyrinthine build
environment, working within such an environment.
Purely as an exercise, could you have produced a minimal viable bundle
of source files, compiler (or recommendation for one), readme and what
ever else was necessary, that would work in an alien environment? Say,
Windows.
IIRC I produced a CDROM containg sources and MinGW, installing it
on Windows and running 'make' would recompile my library from
sources. I do not remember exactly, but I think that it would only recompile "my" files and simply link in libraries that I used.
If you mean source bundle for everything, then there were 6
general libraries involved: libz (compression, needed by
libtiff), libjpeg (needed by libtiff), libtiff, lapack,
BLAS (needed by lapack), hull (geometry code). Each had its
own Makefile. lapack and BLAS needed fortran compiler.
I am not sure if I tried to build the libraries on Windows,
but I think that possibly with small tweaks to Makefiles it
would work (using MinGW compiler + tools). I write about tweaks
as libtiff needed to run a program, but probably did not provide
an '.exe' extention.
On 14/03/2025 00:37, Waldek Hebisch wrote:
bart <[email protected]> wrote:
Instead, the expectation seems to be that the user of the build-machine
has EVERYTHING the developer has, even if poorly justified.
What I'm suggesting goes in the middle. A minimal, streamlined set of >sources, possibly amalgamated (which helps if the user wants to
incorporate this product into their own), with a minimal set of
dependencies.
Before I started working with microprocessors on basically bare systems,
I used DEC and ICL computers. There I never used any such tools. There
were compilers, and there were linkers.
While on 1980s PC-style machines, programs were typically not huge. I
used my own fast compilers and fast loaders (to combine object files
into one program).
bart <[email protected]> writes:
On 14/03/2025 00:37, Waldek Hebisch wrote:
bart <[email protected]> wrote:
Instead, the expectation seems to be that the user of the build-machine
has EVERYTHING the developer has, even if poorly justified.
The expection is that the end-user trying to build the package
has all the necessary prerequisites. Not "EVERYTHING the developer has".
What I'm suggesting goes in the middle. A minimal, streamlined set of
sources, possibly amalgamated (which helps if the user wants to
incorporate this product into their own), with a minimal set of
dependencies.
Why on earth would a developer do this just to make -your- life
easier? Nobody else is complaining endlessly about it.
On Fri, 14 Mar 2025 09:54:07 +0000
Richard Heathfield <[email protected]> wrote:
On 14/03/2025 09:32, Michael S wrote:
.... a 405-line article, of which 387 lines were >chevron-quoted.
Learn to snip! Furrfu FCOL etc etc.
I know, I know. I mean, *after* I hit 'Send' button, I know.
After all no one (according to you) was complaining about grappling with
100 discrete files.
bart <[email protected]> writes:
While on 1980s PC-style machines, programs were typically not huge. I
used my own fast compilers and fast loaders (to combine object files
into one program).
The last thing a Unix programmer would want is to use a 1980s PC,
then or now.
<snip 1000 lines>
on a 1980s machine with floppy disks! Possibly a week.)(I would love to know how long such a build process would have taken
On 14/03/2025 19:04, bart wrote:
After all no one (according to you) was complaining about grappling with
100 discrete files.
100 discrete files helps 100 developers not to step on each other's toes.
And most of those 100 .o's won't need to be recompiled on every make.
It's quicker and easier.
On 14/03/2025 19:04, bart wrote:
After all no one (according to you) was complaining about grappling
with 100 discrete files.
100 discrete files helps 100 developers not to step on each other's toes.
And most of those 100 .o's won't need to be recompiled on every make.
It's quicker and easier.
On 14/03/2025 19:37, Richard Harnden wrote:
On 14/03/2025 19:04, bart wrote:
After all no one (according to you) was complaining about grappling
with 100 discrete files.
100 discrete files helps 100 developers not to step on each other's toes.
And most of those 100 .o's won't need to be recompiled on every make.
It's quicker and easier.
That may be true about the people who /develop/ this sqlite3 product.
But this is a file created to ease deployment by people who want to /
use/ it.
I don't know why nobody in this group can grasp that concept even though
I've explained it a hundred times. For example, I have a transpiler
product that turns a 50-module project in my language into a single, easy-to-build C source file.
But everyone makes the same point about it being hard to manage. No one
is even going to look inside it!
bart <[email protected]> writes:
On 14/03/2025 18:00, Scott Lurndal wrote:[...]
bart <[email protected]> writes:
What I'm suggesting goes in the middle. A minimal, streamlined set ofWhy on earth would a developer do this just to make -your- life
sources, possibly amalgamated (which helps if the user wants to
incorporate this product into their own), with a minimal set of
dependencies.
easier? Nobody else is complaining endlessly about it.
Perhaps you'd like to answer the question I posed about why bother
with distributing software as binaries if building from source is so
effortless.
Nobody said it was "effortless". You made that up.
I can install a binary software package on my computer without
needing a compiler, and it typically takes a few seconds because
someone else has done the work of building it. I happen to have
a compiler, but not everyone does. If I have the sources, I can
probably install a newer version than my OS makes available, and
perhaps I can choose some configuration options. And yes, it's a
bit more effort.
Or maybe, why single file amalagamations like sqlite3.c
exist. After all no one (according to you) was complaining about
grappling with 100 discrete files.
Think about why single file amalgamations like sqlite3.c are so
rare. There isn't much demand for them.
I think that SQLite3 is
designed with portability in mind far more than most software is.
Presumably its developers expend considerable effort to keep it
that way, effort that developers of other software probably don't
feel the need to expend.
For most software packages, building them from source is reasonably
easy. I don't care how big that the "configure" script is, because
99.9% of the time I don't even look at it. It takes some time to
run, and sure, that could probably be streamlined, but I typically go
off and do other things while it's running.
I'm aware that it's not
so easy in your environment.
On 3/13/2025 6:48 PM, Lawrence D'Oliveiro wrote:
On Thu, 13 Mar 2025 16:45:28 -0700, Chris M. Thomasson wrote:
I have no idea how the Python dev's use IOCP with sockets.
They can’t figure out a way to support file I/O notifiers (of the kind
commonly used with event loops) with it. If you know of a way to do it,
please tell us.
Well, usually, iirc, been a while, when GQCSEX returns we take the WSAOVERLAPPED and convert it to our extended structure. Basically
similar to how Linux uses offsetof to extend node structures, or on
Windows CONTAINING_RECORD, then we can use that to pass into a function called on_read, on_write, on_accept, on_connect, ect... type of
functions.
On 14/03/2025 21:15, bart wrote:
On 14/03/2025 19:37, Richard Harnden wrote:
On 14/03/2025 19:04, bart wrote:
After all no one (according to you) was complaining about grappling
with 100 discrete files.
100 discrete files helps 100 developers not to step on each other's
toes.
And most of those 100 .o's won't need to be recompiled on every make.
It's quicker and easier.
That may be true about the people who /develop/ this sqlite3 product.
But this is a file created to ease deployment by people who want to /
use/ it.
This is a newsgroup populated by developers.
Users won't be going anywhere near a compiler - they'll get shipped the binary.
Learn to snip!
On 3/14/2025 2:20 PM, Lawrence D'Oliveiro wrote:
Does that require explicitly queuing a read or a write operation?
Well, I still don't know how Python is implementing things.
Keep in mind that successful IOCP means the completion of an io action
has occurred, or an error has been raised. It could be a new connection,
a buffer was sent, data has been read. That is the C (completion) in
IOCP, see?
bart <[email protected]> writes:
On 14/03/2025 20:04, Keith Thompson wrote:
bart <[email protected]> writes:
On 14/03/2025 18:00, Scott Lurndal wrote:[...]
bart <[email protected]> writes:
Nobody said it was "effortless". You made that up.What I'm suggesting goes in the middle. A minimal, streamlined set of >>>>>> sources, possibly amalgamated (which helps if the user wants toWhy on earth would a developer do this just to make -your- life
incorporate this product into their own), with a minimal set of
dependencies.
easier? Nobody else is complaining endlessly about it.
Perhaps you'd like to answer the question I posed about why bother
with distributing software as binaries if building from source is so
effortless.
No response to that?
You misrepresent what others have said, and don't reply when it's
pointed out.
If you can cite someone here actually saying that building from source
is "effortless", I'll retract this statement.
I can install a binary software package on my computer without
needing a compiler, and it typically takes a few seconds because
someone else has done the work of building it. I happen to have
a compiler, but not everyone does. If I have the sources, I can
probably install a newer version than my OS makes available, and
perhaps I can choose some configuration options. And yes, it's a
bit more effort.
A 'bit more effort' is an understatement. It needs more
dependencies. It will take much longer. And it's more likely to fail.
So I suggested an intermediate compromise that is suited for when your
aim /isn't/ to work on the product yourself.
If I understand correctly, you want one build system for developer and
a simpler one for end users. Is that accurate?
By all means feel free to make such a thing. But having two different
build systems means they both have to be maintained. It makes it more
likely that something works correctly for the developers and fails for
end users.
And it's useful only for end users who build from source. I do that,
but most users don't. Even in my case, the vast majority of the
software on my system is installed from pre-built binaries via the OS's package management system. For a more typical user, it's likely that
all of it is.
So in a sense the simpler build system you want already exists: copying binary files to where they need to be.
As I showed, it is very easy when you dump the 'convoluted' build system!
Great. Show us how you can "dump the 'convoluted' build system" for,
say, GNU coreutils.
Think also about how much arbitrary cruft a developer may accumulate,
not just over the lifetime of one project, but longer term, and whether
it is fair to inflict /that/ on the poor sod who has to duplicate the
exact environment.
On 14/03/2025 21:35, Richard Harnden wrote:
Users won't be going anywhere near a compiler - they'll get shipped the
binary.
Why not? Apparently all they have to is type 'make'.
100 discrete files helps 100 developers not to step on each other's
toes.
This kind of thing does not scale to having thousands of connections
open at once.
Yawn. Of course it does! 50,000 concurrent connections way back in early 2000's.
Every single post arguing against me implies that it is effortless: that
is, all you have to do is type 'make'.
NO ONE wants to admit to building can be a difficult process.
It needs more dependencies. It will take much longer. And it's more
likely to fail.
There is a way to tell IOCP to do a so-called "zero byte
receive" where it does not use any non-paged memory for the receive
buffer because it's zero. Then when IOCP completes it means you are guaranteed a non-blocking receive call, pretty nice!
On Fri, 14 Mar 2025 09:54:07 +0000, Richard Heathfield wrote:
Learn to snip!
I do that, and then the other person claims that I snipped out something important that made their point seem completely the opposite to what I thought it was.
Of course, they are never able to point to the part that was so
important ...
I remember having a timeout thread that would see if a connection was in
a stale condition.
There /is/ no build system speak of. Compiling any program even of 100 >modules is this invocation:
mm prog # prog.m is the lead module
Or you can forget about building completely, and just run direct from
source code:
mm -r prog # (via native code)
mm -i prog # (interpreted)
If there's a simpler way to compile or run source code, I'd like to know
what it is!
C is a little different because the language doesn't allow for automatic >discovery of modules. But the extra info needed is simple: a list of files.
On Fri, 14 Mar 2025 23:16:06 +0000, bart wrote:
Every single post arguing against me implies that it is effortless: that
is, all you have to do is type 'make'.
NO ONE wants to admit to building can be a difficult process.
You don’t have to take anybody’s word for it. Spend a few weeks doing some
builds and development on a Linux system for yourself. The difference
between Windows and Linux is like night and day.
On Sat, 15 Mar 2025 10:18:49 +0000
bart <[email protected]> gabbled:
There /is/ no build system speak of. Compiling any program even of 100
modules is this invocation:
mm prog # prog.m is the lead module
So whats the equivalent of fork() in your language then and how does it
work
on Windows?
Or you can forget about building completely, and just run direct from
source code:
mm -r prog # (via native code)
mm -i prog # (interpreted)
If there's a simpler way to compile or run source code, I'd like to
know what it is!
python3 <filename>
C is a little different because the language doesn't allow for
automatic discovery of modules. But the extra info needed is simple: a
list of files.
Finding dynamic libraries is job of the linker and loader, not the C
compiler
bart <[email protected]> writes:
Here however is a summary of these fictional tools:
https://github.com/sal55/langs/blob/master/CompilerSuite.md
I'm not interested in the tools. What I am asking to see is
the language.
On 15/03/2025 10:42, [email protected] wrote:
So whats the equivalent of fork() in your language then and how does it
work
on Windows?
I've no idea, but this is little to do with a language, or how it is built.
How does it work in C on Windows? Whatever it ends up calling, any
language including mine can do the same.
If there's a simpler way to compile or run source code, I'd like to
know what it is!
python3 <filename>
This is running a scripting language. Build processes are associated
Still, I'll play along:
When you can do:
gcc -run python.c hello.py
then come back and we'll talk. That is, doing a fresh compilation of
Python from source code, and doing it fast enough that you can do it >everytime you want to run a Python program.
Finding dynamic libraries is job of the linker and loader, not the C
compiler
Who's talking about dynamic libraries? If your C program consists of 100 >different modules, this is about finding out what the other 99 modules
are, given the first one.
On Sat, 15 Mar 2025 11:50:19 +0000
bart <[email protected]> gabbled:
On 15/03/2025 10:42, [email protected] wrote:
So whats the equivalent of fork() in your language then and how does
it work
on Windows?
I've no idea, but this is little to do with a language, or how it is
built.
So major API functions have nothing to do with a language. Well that is strictly
true but unless your language is a toy that does nothing beyond simple operations and has no I/O or OS interaction of any sort then you're
going to
have to provide some libraries with it or no one will have the slightest interest in it.
How does it work in C on Windows? Whatever it ends up calling, any
It doesn't, that was kind of the point. win32 can't do fork().
When you can do:
gcc -run python.c hello.py
then come back and we'll talk. That is, doing a fresh compilation of
Python from source code, and doing it fast enough that you can do it
everytime you want to run a Python program.
You do realise its utterly trivial to create a script or even an alias
under
*nix that will compile and run in one go. You declaration that being
able to
do both with one command is some kind of quantum leap in functionality is laughable.
Who's talking about dynamic libraries? If your C program consists of
100 different modules, this is about finding out what the other 99
modules are, given the first one.
The C proprocessor has built in search paths to find headers and you can
pass
it others if you want. There's also nothing stopping you doing a
#include "something.c"
if you want an inefficient build. Most people however don't like rebuilding from scratch everytime there's a code change in a single module, hence makefiles.
On 15/03/2025 12:03, [email protected] wrote:
It doesn't, that was kind of the point. win32 can't do fork().
So, WTF does that have to do with the subject? I can also ask how what
You do realise its utterly trivial to create a script or even an alias
under
*nix that will compile and run in one go. You declaration that being
able to
do both with one command is some kind of quantum leap in functionality is
laughable.
OK. Try it with CPython: start with no CPython executable, just the
source files. You want to be able to run hello.py with one command that
will build CPython from source and run it.
Tell me how long it took to write the script, how long it took to run,
My example didn't need a script; it ran in 0.1 seconds, and generated
zero files. It needed one tool, the compiler.
Yes it is a 'quantum' leap compared with how things are usually done.
if you want an inefficient build. Most people however don't like rebuilding >> from scratch everytime there's a code change in a single module, hence
makefiles.
Here, you don't seem to understand what this is about.
On Sat, 15 Mar 2025 13:39:39 +0000
bart <[email protected]> gabbled:
On 15/03/2025 12:03, [email protected] wrote:
It doesn't, that was kind of the point. win32 can't do fork().
So, WTF does that have to do with the subject? I can also ask how what
Umm, you're trying to promote your language.
Might be helpful if it did
something fucking useful. Or is it just a toy?
You do realise its utterly trivial to create a script or even an
alias under
*nix that will compile and run in one go. You declaration that being
able to
do both with one command is some kind of quantum leap in
functionality is
laughable.
OK. Try it with CPython: start with no CPython executable, just the
source files. You want to be able to run hello.py with one command
that will build CPython from source and run it.
Something like this I imagine:
alias hello="cd cpython;make;bin/python hello.py"
Tell me how long it took to write the script, how long it took to run,
10 secs and no idea.
scratch?
My example didn't need a script; it ran in 0.1 seconds, and generated
zero files. It needed one tool, the compiler.
So what language is your compiler written in? Does it magically just
work or
does it have to be built first?
Yes it is a 'quantum' leap compared with how things are usually done.
How exactly?
if you want an inefficient build. Most people however don't like
rebuilding
from scratch everytime there's a code change in a single module,
hence makefiles.
Here, you don't seem to understand what this is about.
I understand that everytime I ask you something relevant your answer is
the equivalent of "Look! Squirrel!"
On 15/03/2025 02:30, Lawrence D'Oliveiro wrote:
On Fri, 14 Mar 2025 23:16:06 +0000, bart wrote:
Every single post arguing against me implies that it is effortless:
that is, all you have to do is type 'make'.
NO ONE wants to admit to building can be a difficult process.
You don’t have to take anybody’s word for it. Spend a few weeks doing
some builds and development on a Linux system for yourself. The
difference between Windows and Linux is like night and day.
Spend a few weeks using my language.
On Sat, 15 Mar 2025 10:18:49 +0000, bart wrote:
On 15/03/2025 02:30, Lawrence D'Oliveiro wrote:
On Fri, 14 Mar 2025 23:16:06 +0000, bart wrote:
Every single post arguing against me implies that it is effortless:
that is, all you have to do is type 'make'.
NO ONE wants to admit to building can be a difficult process.
You don’t have to take anybody’s word for it. Spend a few weeks doing >>> some builds and development on a Linux system for yourself. The
difference between Windows and Linux is like night and day.
Spend a few weeks using my language.
What can it do that the wide variety of languages already available on
*nix systems can’t do?
On Sat, 15 Mar 2025 21:59:55 +0000, bart wrote:
On 15/03/2025 21:47, Lawrence D'Oliveiro wrote:
On Sat, 15 Mar 2025 10:18:49 +0000, bart wrote:
On 15/03/2025 02:30, Lawrence D'Oliveiro wrote:
On Fri, 14 Mar 2025 23:16:06 +0000, bart wrote:
Every single post arguing against me implies that it is effortless: >>>>>> that is, all you have to do is type 'make'.
NO ONE wants to admit to building can be a difficult process.
You don’t have to take anybody’s word for it. Spend a few weeks doing >>>>> some builds and development on a Linux system for yourself. The
difference between Windows and Linux is like night and day.
Spend a few weeks using my language.
What can it do that the wide variety of languages already available on
*nix systems can’t do?
People keep changing the subject. You were talking about building and
development on Linux vs Windows, rather than the benefits of a
particular language.
Then why did you suggest using your language in the first place?
On 15/03/2025 21:47, Lawrence D'Oliveiro wrote:
On Sat, 15 Mar 2025 10:18:49 +0000, bart wrote:
On 15/03/2025 02:30, Lawrence D'Oliveiro wrote:
On Fri, 14 Mar 2025 23:16:06 +0000, bart wrote:
Every single post arguing against me implies that it is effortless:
that is, all you have to do is type 'make'.
NO ONE wants to admit to building can be a difficult process.
You don’t have to take anybody’s word for it. Spend a few weeks doing >>>> some builds and development on a Linux system for yourself. The
difference between Windows and Linux is like night and day.
Spend a few weeks using my language.
What can it do that the wide variety of languages already available on
*nix systems can’t do?
People keep changing the subject. You were talking about building and development on Linux vs Windows, rather than the benefits of a
particular language.
On 14/03/2025 18:00, Scott Lurndal wrote:
bart <[email protected]> writes:
While on 1980s PC-style machines, programs were typically not huge. I
used my own fast compilers and fast loaders (to combine object files
into one program).
The last thing a Unix programmer would want is to use a 1980s PC,
then or now.
<snip 1000 lines>
This is one of the lines you snipped:
on a 1980s machine with floppy disks! Possibly a week.)(I would love to know how long such a build process would have taken
The context is a project like GMP and its 35,000 of script which is the
first hurdle. The end result is an approx 0.5MB library, which is not
that far off being a plausible piece of software for those 1980s PCs.
I'm guessing that it would have taken an unreasonably long time on such
a machine. Ergo, it would be considered hopelessly inefficient.
So, it sounds like you're either completely missing the point, or
choosing to ignore it. Which is that the build task in this case is too
long and slow in proportion to the task.
On 3/14/2025 10:56 PM, Lawrence D'Oliveiro wrote:
On Fri, 14 Mar 2025 19:33:59 -0700, Chris M. Thomasson wrote:
I remember having a timeout thread that would see if a connection was in >>> a stale condition.
That’s one of those things that is really easier done without threads.
Well, any more insight on that comment?
I wonder, do you any examples of a project which can be built using ONLY
a C compiler, and a set of source files?
On 3/15/25 22:59, bart wrote:
I wonder, do you any examples of a project which can be built using
ONLY a C compiler, and a set of source files?
There's no example of a project like that, because nobody do that.
On 14/03/2025 19:37, Richard Harnden wrote:
On 14/03/2025 19:04, bart wrote:
After all no one (according to you) was complaining about grappling
with 100 discrete files.
100 discrete files helps 100 developers not to step on each other's toes.
And most of those 100 .o's won't need to be recompiled on every make.
It's quicker and easier.
That may be true about the people who /develop/ this sqlite3 product.
But this is a file created to ease deployment by people who want to
/use/ it.
I don't know why nobody in this group can grasp that concept even though
I've explained it a hundred times. For example, I have a transpiler
product that turns a 50-module project in my language into a single, easy-to-build C source file.
But everyone makes the same point about it being hard to manage. No one
is even going to look inside it!
On 15/03/2025 16:53, [email protected] wrote:
Umm, you're trying to promote your language.
No. I was responding to somebody saying how great Linux is to build
software (where you have to run huge configure scripts) and how rubbish >Windows was.
I gave an example of how simple building something was /on Windows/
without any support whatsoever other than a compiler.
Might be helpful if it did
something fucking useful. Or is it just a toy?
Is there any conceivable answer I can give where you're not just going
to give a smart-arse reply?
Something like this I imagine:
alias hello="cd cpython;make;bin/python hello.py"
I guess you need to clear the existing version first or it will do nothing.
Tell me how long it took to write the script, how long it took to run,
10 secs and no idea.
So you haven't tried it. OK, if you don't want to do so, then from your
vast experience of these things, how long do you think it would take to
build CPython from scratch, and would be it viable to do that each time
you evoked it?
I may have mentioned it 50 times; I doubt there's any point in a 51st time.
I understand that everytime I ask you something relevant your answer is
the equivalent of "Look! Squirrel!"
I understand that you keep misunderstanding everything and spouting
random rubbish.
"C is a little different because the language doesn't allow for
automatic discovery of modules. But the extra info needed is simple: a
list of files."
What this means is that a C compiler must be told all the C source files
that make up a program; it can't work it out for itself.
So you have to give it a list of files, but this simple requirement has
blown up into over-complex and error prone build systems.
On Sun, 16 Mar 2025 08:42:40 +0100, tTh wrote:
On 3/15/25 22:59, bart wrote:
I wonder, do you any examples of a project which can be built using
ONLY a C compiler, and a set of source files?
There's no example of a project like that, because nobody do that.
One source file, yes <https://gitlab.com/ldo/slow_dbus_server>. I even include the necessary compiler command in the header comments.
More than one source file -- things get fiddly without at least a simple Makefile to keep it tidy.
least a simple
Makefile to keep it tidy.
On Sat, 15 Mar 2025 17:51:17 +0000
bart <[email protected]> wibbled:
On 15/03/2025 16:53, [email protected] wrote:
Umm, you're trying to promote your language.
No. I was responding to somebody saying how great Linux is to build
software (where you have to run huge configure scripts) and how rubbish
Windows was.
Some linux software has huge configure scripts. Well written software doesn't need them.
I gave an example of how simple building something was /on Windows/
without any support whatsoever other than a compiler.
Building can be made as hard or as easy as the author can be bothered to make it regardless of the OS>
Might be helpful if it did
something fucking useful. Or is it just a toy?
Is there any conceivable answer I can give where you're not just going
to give a smart-arse reply?
Well does it do anything useful? You seem rather dismissive of including any kind of OS API with it rendering it effectively useless except as an academic exercise.
So you haven't tried it. OK, if you don't want to do so, then from your
You plucked cpython out your arse and expect me to go download and build it? Are you fucking kidding me, you think I have nothing better to do with my time?
vast experience of these things, how long do you think it would take to
build CPython from scratch, and would be it viable to do that each time
you evoked it?
Not sure why you seem think a language could be built from scratch before
you use it. Does your compiler have to be built from scratch each time you want to compile something with it? No, didn't think so.
"C is a little different because the language doesn't allow for
automatic discovery of modules. But the extra info needed is simple: a
list of files."
You haven't even defined modules properly. Do you mean other C source files, compiled .o files, .so files, .a files or something else?
What this means is that a C compiler must be told all the C source files
that make up a program; it can't work it out for itself.
For a start a C compiler only compiles one file at a time and secondly I wouldn't want it to try and second guess what modules I want it to build with. I've already explained why previously. You seem to live in a simple world of simple programs with no system specific dependencies.
So you have to give it a list of files, but this simple requirement has
blown up into over-complex and error prone build systems.
Only by people who don't know what they're doing.
bart <[email protected]> wrote:
On 14/03/2025 19:37, Richard Harnden wrote:
On 14/03/2025 19:04, bart wrote:
After all no one (according to you) was complaining about grappling
with 100 discrete files.
100 discrete files helps 100 developers not to step on each other's toes. >>>
And most of those 100 .o's won't need to be recompiled on every make.
It's quicker and easier.
That may be true about the people who /develop/ this sqlite3 product.
But this is a file created to ease deployment by people who want to
/use/ it.
I don't know why nobody in this group can grasp that concept even though
I've explained it a hundred times. For example, I have a transpiler
product that turns a 50-module project in my language into a single,
easy-to-build C source file.
But everyone makes the same point about it being hard to manage. No one
is even going to look inside it!
Do you realize that your amalgamation destroys most of C
modularization?
On 16/03/2025 10:06, Waldek Hebisch wrote:
bart <[email protected]> wrote:
On 14/03/2025 19:37, Richard Harnden wrote:
On 14/03/2025 19:04, bart wrote:
After all no one (according to you) was complaining about grappling
with 100 discrete files.
100 discrete files helps 100 developers not to step on each other's toes. >>>>
And most of those 100 .o's won't need to be recompiled on every make.
It's quicker and easier.
That may be true about the people who /develop/ this sqlite3 product.
But this is a file created to ease deployment by people who want to
/use/ it.
I don't know why nobody in this group can grasp that concept even though >>> I've explained it a hundred times. For example, I have a transpiler
product that turns a 50-module project in my language into a single,
easy-to-build C source file.
But everyone makes the same point about it being hard to manage. No one
is even going to look inside it!
Do you realize that your amalgamation destroys most of C
modularization?
Do you realise that you're reinforcing the point I made?
The fact is, IT DOESN'T MATTER!
Creating a binary also destroys modularisation; so what?
bart <[email protected]> wrote:
On 16/03/2025 10:06, Waldek Hebisch wrote:
bart <[email protected]> wrote:
On 14/03/2025 19:37, Richard Harnden wrote:
On 14/03/2025 19:04, bart wrote:
After all no one (according to you) was complaining about grappling >>>>>> with 100 discrete files.
100 discrete files helps 100 developers not to step on each other's toes. >>>>>
And most of those 100 .o's won't need to be recompiled on every make. >>>>> It's quicker and easier.
That may be true about the people who /develop/ this sqlite3 product.
But this is a file created to ease deployment by people who want to
/use/ it.
I don't know why nobody in this group can grasp that concept even though >>>> I've explained it a hundred times. For example, I have a transpiler
product that turns a 50-module project in my language into a single,
easy-to-build C source file.
But everyone makes the same point about it being hard to manage. No one >>>> is even going to look inside it!
Do you realize that your amalgamation destroys most of C
modularization?
Do you realise that you're reinforcing the point I made?
The fact is, IT DOESN'T MATTER!
Creating a binary also destroys modularisation; so what?
Have you read what I wrote? To remaind you, just after the
quoted statement I wrote:
: In C there is no conflict between static
: objects at file scope in different files, even is they use
: the same name. In single file there may be conflict.
: Avoiding such conflicts is an extra developement effort.
Creating binary from multiple file preserves this property,
so one should rather say that creating binary respects
modularisation. Amalgamation on source level does not.
On 16/03/2025 08:02, Lawrence D'Oliveiro wrote:
More than one source file -- things get fiddly without at least a
simple Makefile to keep it tidy.
You've never heard of an '@' file?
Every single makefile I've seen seems to be the opposite of tidy.
On 16/03/2025 10:06, [email protected] wrote:
Well does it do anything useful? You seem rather dismissive of including any >> kind of OS API with it rendering it effectively useless except as an academic
exercise.
I first used it as an in-house product over 40 years ago. It was used >internally in my company that developed hardware, for writing test
software. Later it was used to make commercial low-end CAD products,
which included integrated scripting languages.
Basically, it could do anything C could do, but more comfortably (I
never managed to switch to C and prefered my product).
You plucked cpython out your arse and expect me to go download and build it? >> Are you fucking kidding me, you think I have nothing better to do with my >time?
EXACTLY!
It was actually YOU who brought up the Python example, because you
thought that:
python file.py
for a scripting language with a lead module file.py was a fair
comparison with my product being able to do the same with:
It's instant, like turning on a light switch. But using your normal
Linux tools would be more like first building a fire, then using that to >drive a steam-powered generator!
Only by people who don't know what they're doing.
I've only been writing compilers since 1979, so you could be right!
However, 'gcc *.c' worked!
On Sun, 16 Mar 2025 12:06:20 +0000
bart <[email protected]> wibbled:
On 16/03/2025 10:06, [email protected] wrote:
Well does it do anything useful? You seem rather dismissive of including any
kind of OS API with it rendering it effectively useless except as an academic
exercise.
I first used it as an in-house product over 40 years ago. It was used
internally in my company that developed hardware, for writing test
software. Later it was used to make commercial low-end CAD products,
which included integrated scripting languages.
Basically, it could do anything C could do, but more comfortably (I
never managed to switch to C and prefered my product).
Anything C could do so long as you don't include all the standard C libraries in "anything".
You plucked cpython out your arse and expect me to go download and build it?
Are you fucking kidding me, you think I have nothing better to do with my >> time?
EXACTLY!
It was actually YOU who brought up the Python example, because you
thought that:
python file.py
for a scripting language with a lead module file.py was a fair
comparison with my product being able to do the same with:
You asked how to run a program in another language with 2 words.
I gave you
an example. FWIW python does internally compile the code down to some intermediate language before it runs it.
It's instant, like turning on a light switch. But using your normal
Linux tools would be more like first building a fire, then using that to
drive a steam-powered generator!
So how would your compiler know what libraries to link with? I imagine its not a problem if you don't bother with libraries in the first place.
Only by people who don't know what they're doing.
I've only been writing compilers since 1979, so you could be right!
I'd find another hobby given no one has heard of any language you've written.
However, 'gcc *.c' worked!
Yes, you can use that old school method and sometimes it does work and leave an a.out there, but more often that not different modules require different compilation parameters and it all goes tits up. And thats assuming you don't get multiple definition errors when it tries to link.
On Mon, 17 Mar 2025 14:25:46 +0000
bart <[email protected]> wibbled:
On 17/03/2025 12:07, [email protected] wrote:
Anything C could do so long as you don't include all the standard C libraries
in "anything".
Another mysterious remark. You seem to consider it your job to put down
anything I do or say!
So, what do the standard C libraries have to do with anything here?
They're generally the interface to the OS on *nix. No idea about windows.
where mm is a compiler. That itself was in the context of build tools on
Linux which usually involve makefiles, shell scripts and other
OS-specific junk, which was touted to be far superior to the Windows
experience.
So presumably your amazing build system checks the current module build dates and doesn't rebuild stuff that it doesn't have to?
On 17/03/2025 12:07, [email protected] wrote:
Anything C could do so long as you don't include all the standard C libraries
in "anything".
Another mysterious remark. You seem to consider it your job to put down >anything I do or say!
So, what do the standard C libraries have to do with anything here?
where mm is a compiler. That itself was in the context of build tools on >Linux which usually involve makefiles, shell scripts and other
OS-specific junk, which was touted to be far superior to the Windows >experience.
So how would your compiler know what libraries to link with? I imagine its >> not a problem if you don't bother with libraries in the first place.
What, within my language? They are either specified via the module
scheme which lists the source files and libraries used, or infered from
the FFI declarations needed. This is from my scripting language for example:
importdll sdl2 =
func "SDL_OpenAudio"(ref sdl_audiospec desired, obtained=nil)i32
...
end
On Mon, 17 Mar 2025 14:25:46 +0000
bart <[email protected]> wibbled:
On 17/03/2025 12:07, [email protected] wrote:
Anything C could do so long as you don't include all the standard C libraries
I don't know how .dll works in windows, but on *nix there are a couple of >different compiled object types: ".o" are compiled code meant to be merged >together to create a binary. ".so" are compiled code which can either be stub >linked to the code itself at linktime , or dynamically loaded by the code >itself at runtime. Which are you talking about?
[email protected] writes:
On Mon, 17 Mar 2025 14:25:46 +0000
bart <[email protected]> wibbled:
On 17/03/2025 12:07, [email protected] wrote:
Anything C could do so long as you don't include all the standard C >libraries
I don't know how .dll works in windows, but on *nix there are a couple of >>different compiled object types: ".o" are compiled code meant to be merged >>together to create a binary. ".so" are compiled code which can either be stub >>linked to the code itself at linktime , or dynamically loaded by the code >>itself at runtime. Which are you talking about?
The 'd' in 'dll' should be sufficiently explanatory.
On 17/03/2025 16:32, [email protected] wrote:
On Mon, 17 Mar 2025 14:25:46 +0000
bart <[email protected]> wibbled:
On 17/03/2025 12:07, [email protected] wrote:
Anything C could do so long as you don't include all the standard C >libraries
in "anything".
Another mysterious remark. You seem to consider it your job to put down
anything I do or say!
So, what do the standard C libraries have to do with anything here?
They're generally the interface to the OS on *nix. No idea about windows.
I think you can assume that the tool I used was up to the job
So presumably your amazing build system checks the current module build dates
and doesn't rebuild stuff that it doesn't have to?
Why would it matter? I can compile code at one million lines every two >seconds, and my largest project is 50K lines - do the math.
I find it astonishing that even with machines at least a thousand times >faster than I've used in the past, you have to resort to tricks to avoid >compilation.
On Mon, 17 Mar 2025 17:10:59 +0000
bart <[email protected]> wibbled:
On 17/03/2025 16:32, [email protected] wrote:
On Mon, 17 Mar 2025 14:25:46 +0000libraries
bart <[email protected]> wibbled:
On 17/03/2025 12:07, [email protected] wrote:
Anything C could do so long as you don't include all the standard C
I think you can assume that the tool I used was up to the job
in "anything".
Another mysterious remark. You seem to consider it your job to put down >>>> anything I do or say!
So, what do the standard C libraries have to do with anything here?
They're generally the interface to the OS on *nix. No idea about windows. >>
I'm assuming nothing since all we have is your word for it.
So presumably your amazing build system checks the current module build dates
and doesn't rebuild stuff that it doesn't have to?
Why would it matter? I can compile code at one million lines every two
seconds, and my largest project is 50K lines - do the math.
You'll have to excuse me if I take that figure with a large packet of salt unless the code does nothing particularly complicated.
I find it astonishing that even with machines at least a thousand times
faster than I've used in the past, you have to resort to tricks to avoid
compilation.
Why not?
for a test file of nearly 1M lines.
On 18/03/2025 10:59, bart wrote:
for a test file of nearly 1M lines.
Any sane shop would reject a source file that long.
It's unmaintainable.
On 18/03/2025 10:59, bart wrote:
for a test file of nearly 1M lines.
Any sane shop would reject a source file that long.
It's unmaintainable.
On 18/03/2025 09:53, [email protected] wrote:
You'll have to excuse me if I take that figure with a large packet of salt >> unless the code does nothing particularly complicated.
If you don't believe my figures, try Tiny C on actual C programs.
Tiny C is single pass, mine does multiple passes so is a little slower.
What the code does is not that relevant:
c:\cx\big>tim tcc fann4.c
Time: 0.855
c:\cx\big>dir fann4.exe
18/03/2025 10:44 10,491,904 fann4.exe
So tcc can generate 12MB per second in this case, for a test file of
nearly 1M lines.
What you should find harder to believe is this figure:
c:\cx\big>tim gcc fann4.c
Time: 50.571 (44.2 on subsequent build)
On 18/03/2025 09:53, [email protected] wrote:
On Mon, 17 Mar 2025 17:10:59 +0000
bart <[email protected]> wibbled:
On 17/03/2025 16:32, [email protected] wrote:
On Mon, 17 Mar 2025 14:25:46 +0000libraries
bart <[email protected]> wibbled:
On 17/03/2025 12:07, [email protected] wrote:
Anything C could do so long as you don't include all the standard C
I think you can assume that the tool I used was up to the job
in "anything".
Another mysterious remark. You seem to consider it your job to put down >>>>> anything I do or say!
So, what do the standard C libraries have to do with anything here?
They're generally the interface to the OS on *nix. No idea about windows. >>>
I'm assuming nothing since all we have is your word for it.
So presumably your amazing build system checks the current module build dates
and doesn't rebuild stuff that it doesn't have to?
Why would it matter? I can compile code at one million lines every two
seconds, and my largest project is 50K lines - do the math.
You'll have to excuse me if I take that figure with a large packet of salt >> unless the code does nothing particularly complicated.
If you don't believe my figures, try Tiny C on actual C programs.
Tiny C is single pass, mine does multiple passes so is a little slower.
What the code does is not that relevant:
c:\cx\big>tim tcc fann4.c
Time: 0.855
c:\cx\big>dir fann4.exe
18/03/2025 10:44 10,491,904 fann4.exe
So tcc can generate 12MB per second in this case, for a test file of
nearly 1M lines.
What you should find harder to believe is this figure:
c:\cx\big>tim gcc fann4.c
Time: 50.571 (44.2 on subsequent build)
c:\cx\big>dir a.exe
18/03/2025 10:51 9,873,707 a.exe
Since it can only manage 0.2MB per second for the same quality of code.
How about making such compilers faster first before resorting to
makefile tricks?
Here is my C compiler on the same task:
c:\cx\big>tim bcc fann4
Time: 1.624
c:\cx\big>dir fann4.exe
18/03/2025 10:55 6,842,368 fann4.exe
Throughput is only 4MB/second, but it is generating a smaller executable.
I find it astonishing that even with machines at least a thousand times
faster than I've used in the past, you have to resort to tricks to avoid >>> compilation.
Why not?
You're missing the point. I mentioned a throughput of 500Klps above;
divide that by 1000, and it means a machine from 40 years was able to
build programs at 500 lines per second, which seems plausible.
So what do you think is a more realistic figure for today's machines:
20Klps for an unoptimised build? (The gcc test managed 22Klps.) That
would mean a compilation speed of 20 lines per second on an early 80s
PC, which is ludicrous.
Something is badly wrong.
bart <[email protected]> wrote:
Actually 20 lines per per second would be not bad. Early Turbo
Pascal was considerd very fast and IIRC did 8000 lines per minute,
that is about 130 lines per second.
Modern machines are more than 1000 faster than early PC-s, probably
closer to 10000 faster. If you belive in Dhrystones, slow RISCV
board is doing 1820.7 DMIPS, slow Atom 2952 DMIPS, And Zen at about
3 GHz 30501 DMIPS. VAX in 1 DMIPS and is quite a bit faster
than early PC-s.
OTOH, compiler are bad case for modern machines. gcc folks
observed that gcc execution time correlates better with
databases than with compute intensive programs. In particular
there are a lot of cache misses which are costly on modern
machines.
bart <[email protected]> wrote:
Actually 20 lines per per second would be not bad. Early Turbo
Pascal was considerd very fast and IIRC did 8000 lines per minute,
that is about 130 lines per second.
Something is badly wrong.
People want compilers to do more work. The idea is to write
simple program without doing various speed-enhancing tricks
and still get good execution time. Look at functions below.
'aref' guarantees that all access are in bounds. But at
-O2 gcc compiled code for 'my_sum' is the same as code with
no bound checking. Simply, compiler can prove that all array
accesses are in bound, so it can safely remove checking
code. How good is code from your compiler (assuming that
source code is checking all array accesses)?
On 13/03/2025 21:52, Tim Rentsch wrote:
bart <[email protected]> writes:
Here however is a summary of these fictional tools:
https://github.com/sal55/langs/blob/master/CompilerSuite.md
I'm not interested in the tools. What I am asking to see is
the language.
I'm working on a document that summaries the features.
On Tue, 18 Mar 2025 16:27:00 -0000 (UTC)
[email protected] (Waldek Hebisch) wrote:
bart <[email protected]> wrote:
Actually 20 lines per per second would be not bad. Early Turbo
Pascal was considerd very fast and IIRC did 8000 lines per minute,
that is about 130 lines per second.
Modern machines are more than 1000 faster than early PC-s, probably
closer to 10000 faster. If you belive in Dhrystones, slow RISCV
board is doing 1820.7 DMIPS, slow Atom 2952 DMIPS, And Zen at about
3 GHz 30501 DMIPS. VAX in 1 DMIPS and is quite a bit faster
than early PC-s.
Not sure how VAX compares to early PCs in general, but if my deem
memories of casual 1st hand experience are worth anything then I'd dare
to say that compiling Pascal program on 780/11 with VMS Pascal was at
least 10 times slower than doing the same on PC/AT clone with Turbo
Pascal
bart <[email protected]> writes:
On 13/03/2025 21:52, Tim Rentsch wrote:
bart <[email protected]> writes:
Here however is a summary of these fictional tools:
https://github.com/sal55/langs/blob/master/CompilerSuite.md
I'm not interested in the tools. What I am asking to see is
the language.
I'm working on a document that summaries the features.
I expect some people will find it interesting reading. It is
almost certainly worth writing, assuming there is an interested
audience.
My interest is seeing a definition of the language, including
at least a complete syntax, and some sort of description of
the semantics for each construct, especially those that look
or behave differently than familiar constructs in mainstream
languages.
Being concise or terse is okay; I don't need to
read a belabored explanation of, for example, how function
calls work, if they work the same way that function calls in
C work. But it is important, in this example, to say that
function arguments are always evaluated left-to-right (if
indeed that is the case),
On 19/03/2025 07:14, Tim Rentsch wrote:
bart <[email protected]> writes:
On 13/03/2025 21:52, Tim Rentsch wrote:
bart <[email protected]> writes:
Here however is a summary of these fictional tools:
https://github.com/sal55/langs/blob/master/CompilerSuite.md
I'm not interested in the tools. What I am asking to see is
the language.
I'm working on a document that summaries the features.
I expect some people will find it interesting reading. It is
almost certainly worth writing, assuming there is an interested
audience.
I don't know if you've seen the thread I made, where I posted a
link to it. So any suggestions now are a little late.
The evidence is that no one is interested in this kind of language
now.
On Tue, 18 Mar 2025 11:48:41 +0000 Richard Harnden <[email protected]d> wrote:
Any sane shop would reject a source file that long.
It's unmaintainable.
Second, huge "source" files tend to be computer-generated. So they are
only source from POV of back-end compiler. From the POV of humans they
are intermediate products. So, there are no concerns of maintainability.
You have machines now that are 1000 times faster than what I was using,
and yet compilation time is still be an issue unless you use all these tricks?
Beggars can’t be choosers. As long as you don’t have the skills or
patience to actually contribute to such development, you have to accept
what you get.
Have you actually tried it? I mean what I suggested in taking a
project, and extracting the most basic steps. Like the invocation of gcc above. You might start questioning all this pointless complexity
yourself.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 714 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 141:11:20 |
| Calls: | 12,087 |
| Files: | 14,998 |
| Messages: | 6,517,442 |