Re: Python recompile

On 17/03/2025 12:07, Muttley@DastardlyHQ.org wrote:

On Sun, 16 Mar 2025 12:06:20 +0000
bart <bc@freeuk.com> wibbled:

On 16/03/2025 10:06, Muttley@DastardlyHQ.org 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".

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?
My language literally could anything, and in those days it had to, as 80% of what you take for granted now, provided from the OS or endless free libraries, you had to write yourself.

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.

You responded to this comment of mine:
"There /is/ no build system speak of. Compiling any program even of 100 modules is this invocation: mm prog"
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.
I showed an example of an effortless build /on Windows/.

I gave you
an example. FWIW python does internally compile the code down to some
intermediate language before it runs it.

A fairer comparison is building a significant 100-module C program on Linux, and even better is trying to use that exact same process to build the same app on Windows (which is exactly what many open-source cross-platform apps expect you to do).
That's where it starts to fall down, and this longer than expected subthread started. If the process was much simpler and more OS-neutral in the first place, even if not quite as sweet as my example, it would be much smoother.

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.

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
So it knows it needs to use sdl2.dll when an attempt is made to call that function.
In either case, the information needed is inside the source files.

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.

Huh? Not all languages need to be famous or mainstream. Mine were in-house tools, in an era where software tools were not instant free downloads.
I probably haven't heard of anything you've done either.

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.

So, you can also enumerate the 10 or so files needed. The requirements are really very simple. Besides, the makefile in this case also used *.c! I've shown it below.
(Probably it didn't work because it's specfic to MS' CL and LINK tools, and I'd used gcc. Another reason why compiler-neutral build info is better, where possible.)
-----------------------
CCFLAGS=/nologo /std:c11 /TC /W4 /Zi /wd4201 /wd4996
LINKFLAGS=/nologo /subsystem:console /defaultlib:msvcrt.lib /defaultlib:legacy_stdio_definitions.lib /defaultlib:Kernel32.lib
EXENAME=minic
OBJDIR=obj
BINDIR=bin
all:
IF NOT EXIST $(OBJDIR) MKDIR $(OBJDIR)
IF NOT EXIST $(BINDIR) MKDIR $(BINDIR)
cl $(CCFLAGS) src\*.c /Fo.\$(OBJDIR)\ /Fe$(EXENAME).exe
IF EXIST *.exe MOVE *.exe $(BINDIR)
IF EXIST *.idb MOVE *.idb $(BINDIR)
IF EXIST *.ilk MOVE *.ilk $(BINDIR)
IF EXIST *.pdb MOVE *.pdb $(BINDIR)
test:
python tests/run_tests.py
test_file:
python tests/run_tests.py --file $(FILE)
asm:
nasm -f win64 tmp.asm -o tmp.obj
link /nologo /subsystem:console /entry:main tmp.obj ucrt.lib vcruntime.lib legacy_stdio_definitions.lib