Re: Suggested method for returning a string from a C program?

On 24/03/2025 16:17, Muttley@DastardlyHQ.org wrote:

On Mon, 24 Mar 2025 16:02:57 +0000
bart <bc@freeuk.com> wibbled:

On 24/03/2025 15:00, Muttley@DastardlyHQ.org wrote:

real 0m0.815s
user 0m0.516s
sys 0m0.252s

>
>
So, your throughput is a whopping 9.5K lines/second?

 On a tired laptop with multiple files it seems pretty good to me.
 

Build time is 1/15th of a second, for about 30K lines (so 450Klps). But
I also want to compile this via C, to take advantage of gcc's superior
optimiser. So first I transpile to C (that's also under 70ms):

 I'll paraphrase someone elses point - who fucking cares? If you need lightning
fast compilation because you're constantly rebuilding your shit code to see if
it'll even compile never mind work then that says a lot about you as a dev.
The thinking/writing to compilation time ratio I imagine with most devs would
probably be a minimum of 100 - 1, possibly much larger.

If a build takes 0.1 seconds, then 100 times that is 10 seconds. I don't build that often on average, so I must do more thinking between compilations than you guys!
And more work: even if I compile 1000 times a day, that is less than two minutes.
It's funny actually that you are in favour of the incremental builds that makefiles help with. All about breaking things down into smaller steps ...
... EXCEPT when it comes to edit-run cycles. There you're in favour of bunching lots of changes together, and doing one big build followed by testing a dozen different things on that new version. (As though this was the 1960s and you only got one batch compilation per night.)
I guess doing lots of small, incremental edit-run-test cycles, that test one detail at a time, goes out the window?
What exactly is wrong with it?