Re: Python recompile

On 16/03/2025 10:06, Muttley@DastardlyHQ.org wrote:

On Sat, 15 Mar 2025 17:51:17 +0000
bart <bc@freeuk.com> wibbled:

On 15/03/2025 16:53, Muttley@dastardlyhq.com 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.

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).
For the last 20 years it has been a personal tool for me for working on hobbyist, experimental language-related projects like compilers, assemblers, linkers, interpreters, IL processors, and necessary support libraries.
I developed for example new module schemes, whole-program compilers, new ILs (intermediate languages) and new binary formats for executables and shared libraries.

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?

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:
    ms file
which is for a statically compiled language with near-instant compilation. I then suggested this example:
    ms qc file
which is equivalent to compiling the whole of CPython, in memory, then running it in memory to run some script. The point, which you now admit, is that it would take forever. But if you do get around to it, look at this further example:
   c:\qx>tim ms mm qq hello
   Hello, World! 16-Mar-2025 11:45:22
   Time: 0.169
This compiles and runs my compiler (mm) from source code, compiles runs the interpreter (qc) from source code, then runs hello.q. It look 1/6th of a second. (tim is a timer.)
This is equivalent to compiling gcc into memory, then using that to compile CPython into memory, then using that to run hello.py.
That is quite astonishing. But the point is to show how fast machines are these days, and how effortless building can be EVEN ON WINDOWS.
But everyone is trying to force makefiles and colossal, Linux-specific configure scripts down my throat.
No one is even prepared to consider simple @ files that I demonstrated in my last post. It has to be complicated, or nothing!

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.

Not usually, but my tools are so fast that it could be (see example above). The point of the example was that the task of building even a substantial program can be NOTHING.
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!

"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?

Well, these are all inputs that can be submitted to a compiler at the same time. Personally, for C, I only use .c files and sometimes .dll files, while most open source projects I want to build only involve C files.
It is still just 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.

 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, anything more than one .c file, and you immediately create some makefile full of gobbledygook?
This would be like using your car to drive anywhere that is not immediately next door, even if it's down the street.
Or, more on point, using a makefile even to write a shopping list. Which is exactly what a compiler needs: a list of files.

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.

I've only been writing compilers since 1979, so you could be right!
Personally I always used project files to list dependences, but those are specific to my private IDE. I wouldn't inflict them, or my tools, on anyone else trying to build my programs.
For that purpose I supply direct build instructions for a one-off build, even if it's just this:
   gcc *.c -o prog.exe
Actually, just yesterday I tried to build someone's small /Windows/ project via the makefile. It failed (missing files), although it may not been intended to be used, or not tested outside the developer's machine.
However, 'gcc *.c' worked!