Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Python recompile
Date: Mon, 17 Mar 2025 14:25:46 +0000
Organization: A noiseless patient Spider
Lines: 154
Message-ID: <vr9bd9$adgu$1@dont-email.me>
References: <vq1qas$j22$1@gallifrey.nk.ca> <vqeu5c$3imil$1@dont-email.me>
 <vqeun4$3iqbq$1@dont-email.me> <vqfcbe$3lkkc$1@dont-email.me>
 <871pv861ht.fsf@nosuchdomain.example.com> <20250308192940.00001351@yahoo.com>
 <vqi1ge$8jg8$1@dont-email.me> <vqmgjv$3a2il$1@paganini.bofh.team>
 <vqn4dn$1eb9s$1@dont-email.me> <vqo3ss$3hkas$1@paganini.bofh.team>
 <vqph2e$203bs$2@dont-email.me> <vqvtop$cpvn$1@paganini.bofh.team>
 <vr1nkh$1miii$1@dont-email.me> <G8_AP.37556$D_V4.24121@fx39.iad>
 <vr1uk1$1sb5s$1@dont-email.me> <874izvjs4m.fsf@nosuchdomain.example.com>
 <vr27td$22vgq$2@dont-email.me> <87senfi7ii.fsf@nosuchdomain.example.com>
 <vr2dbm$2995t$1@dont-email.me> <vr2onl$2hjmt$3@dont-email.me>
 <vr3k67$3a5r2$1@dont-email.me> <vr3li9$3bqnp$1@dont-email.me>
 <vr3php$3di63$2@dont-email.me> <vr3qa3$3fua7$1@dont-email.me>
 <vr3vup$3jjoq$1@dont-email.me> <vr4ba0$3tj6e$1@dont-email.me>
 <vr4emj$3vejc$1@dont-email.me> <vr67qo$1inip$1@dont-email.me>
 <vr6ert$1ob25$1@dont-email.me> <vr93a6$3i2s$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 17 Mar 2025 15:25:46 +0100 (CET)
Injection-Info: dont-email.me; posting-host="541bd4f0a9e2c86fbe37685adcd5adaa";
	logging-data="341534"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/uIRPc2TqYLfTKMHhiTOkk"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:tJKqOSZXbFrNRmGitzsmhuKI0fY=
Content-Language: en-GB
In-Reply-To: <vr93a6$3i2s$1@dont-email.me>
Bytes: 7516

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