Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Wed, 20 Nov 2024 23:29:44 +0000
Organization: A noiseless patient Spider
Lines: 99
Message-ID: <vhlrd9$ai84$1@dont-email.me>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>
 <vg3b98$3cc8q$1@dont-email.me> <vg5351$3pada$1@dont-email.me>
 <vg62vg$3uv02$1@dont-email.me> <vgd3ro$2pvl4$1@paganini.bofh.team>
 <vgdc4q$1ikja$1@dont-email.me> <vgdt36$2r682$2@paganini.bofh.team>
 <vge8un$1o57r$3@dont-email.me> <vgpi5h$6s5t$1@paganini.bofh.team>
 <vgtsli$1690f$1@dont-email.me> <vhgr1v$2ovnd$1@paganini.bofh.team>
 <vhic66$1thk0$1@dont-email.me> <vhj45b$2spff$1@paganini.bofh.team>
 <vhj9pj$23f7v$1@dont-email.me> <vhks9u$34hfo$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 21 Nov 2024 00:29:45 +0100 (CET)
Injection-Info: dont-email.me; posting-host="c40e301dd0b1f9597074e8098c15fd77";
	logging-data="346372"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18bdm00CKIPkwQiWO6cB96I"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Q/7lcj2ZoejFNgxKbYuOdreNDLY=
In-Reply-To: <vhks9u$34hfo$1@paganini.bofh.team>
Content-Language: en-GB
Bytes: 5867

On 20/11/2024 14:38, Waldek Hebisch wrote:
> Bart <bc@freeuk.com> wrote:

>> Either you're developing using interpreted code, or you must have some
>> means of converting source code to native code, but for some reason you
>> don't use 'compile' or 'build' to describe that process.
>>
>> Or maybe your REPL/incremental process can run for days doing
>> incremental changes without doing a full compile.
> 
> Yes.
> 
>> It seems quite mysterious.
> 
> There is nothing misterious here.  In typed system each module has
> a vector (one dimensional array) called domain vector containg amoung
> other references to called function.  All inter-module calls are
> indirect ones, they take thing to call from the domain vector.  When
> module starts execution references point to a runtime routine doing
> similar work to dynamic linker.  The first call goes to runtime
> support routine which finds needed code and replaces reference in
> the domain vector.
> 
> When a module is recompiled references is domain vectors are
> reinitialized to point to runtimne.  So searches are run again
> and if needed pick new routine.
> 
> Note that there is a global table keeping info (including types)
> about all exported routines from all modules.  This table is used
> when compileing a module and also by the search process at runtime.
> 
> The effect is that after recompilation of a single module I have
> runnuble executable in memory including code of the new module.
> If you wonder about compiling the same module many times: system
> has garbage collector and unused code is garbage collected.
> So, when old version is replaced by new one the old becomes a
> garbage and will be collected in due time.

This sounds an intriguing kind of system to implement.

That is, where program source, code and data structures are kept 
resident, individual functions and variables can be changed, and any 
other functions that might be affected are recompiled, but no others.

This has some similarities to what I was doing in the 1990s with 
hot-loadable and -modifible scripts. So a lot more dynamic than the 
stuff I do now.

The problem is that my current applications are simply too small for it 
to be worth the complexity. Most of them build 100% from scratch in 
under 0.1 seconds, especially if working within a resident application 
(my timings include Windows process start/end overheads.)

If I was routinely working with programs that were 10 times the scale 
(so needing to wait 0.5 to 1 seconds), then it might be something I'd 
consider. Or I might just buy a faster machine; my current PC was pretty 
much the cheapest in the shop in 2021.

> The other system is similar in principle, but there is no need
> for runtime search and domain vectors.
> 
>> I might run my compiler hundreds of times a day (at 0.1 seconds a time,
>> 600 builds would occupy one whole minute in the day!). I often do it for
>> frivolous purposes, such as trying to get some output lined up just
>> right. Or just to make sure something has been recompiled since it's so
>> quick it's hard to tell.
>>
>>>
>>> I know.  But this is not what I do.  Build produces mutiple
>>> artifacts, some of them executable, some are loadable code (but _not_
>>> in form recogized by operating system), some essentially non-executable
>>> (like documentation).
>>
>> So, 'build' means something different to you. I use 'build' just as a
>> change from writing 'compile'.
> 
> Build means creating new fully-functional system.  That involves
> possibly multiple compilations and whatever else is needed.

I would call that something else, perhaps based around 'Make' (nothing 
to do with Linux 'make' tools).

Here is the result of such a process for one of my 1999 apps:

  G:\m7>dir
  10/03/1999  00:57            45,056 M7.DAT
  17/10/2002  19:22           370,288 M7.EXE
  11/10/2021  21:05             7,432 M7.INI
  17/10/2002  19:27           705,376 M7.PCA
  10/03/1999  00:59             8,541 M7CMD.INI

The PCA files contains a few dozen scripts (at that time, they were 
compiled to bytecode). This was a distribution layout, created a batch 
file, and ending up a floppy, or ater FTP-ed to a web-site.

This is not routine building of either than M7.EXE program unit, or 
those scripts which are compiled independently from inside M7.EXE.