Re: Python recompile

On 15/03/2025 12:03, Muttley@dastardlyhq.com wrote:

On Sat, 15 Mar 2025 11:50:19 +0000
bart <bc@freeuk.com> gabbled:

On 15/03/2025 10:42, Muttley@dastardlyhq.com 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().

So, WTF does that have to do with the subject? I can also ask how what is the equivalent of some random WinAPI funcion on Linux.

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.

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, and how many disk files were generated. Also, how many utility programs were involved to make it possible; a C compiler will be one.
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. But carry on deluding yourself that your current set of tools can do the job as simply or as briskly.
(A CPython sufficient to run hello.py might be 20 times the size of my product, but you will likely be running a more powerful machine with multiple cores. Still, I doubt you could do it even in 2 seconds.)

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.

Here, you don't seem to understand what this is about.