<acheam>
but the fact that you put ed after vi in the editor priority list is a disgrace
<acheam>
ed is the one true editor
<acheam>
also /root/.ash_history seems like a weird backup esp if you want this to be shell-agnostic, but I see how it would work for fixing your issue
<acheam>
and I also dont see how you would know where else to look if HISTFILE isnt set
<kyxor>
noocsharp: sh > make I prefer something closer to a real programming language than a stub like make.
<kyxor>
acheam: thanks for feedback, I'll address all those issues with next iteration
<kyxor>
does ffmppeg 5.0 suck? they broke the old api, and the new does not give me much hope. Did anyone benchmark test it, I have a feeling it has to be slower now
<kyxor>
well, once I rewrite nextfvp to support new api I would be able to do an accurate comparison. I kinda looked into it already but it's not finished yet
<phoebos>
you would hope a programming language isn't necessary to get the instructions required to compile your code
<phoebos>
make is designed for building projects
<testuser[m]>
Pozix make is shit
<testuser[m]>
Once ur project gets larger
<testuser[m]>
U need atleast gnu make
<testuser[m]>
larger as in vendoring some dependencies and stuff or platform specific code
<phoebos>
yes but kyxor's project is one file
<testuser[m]>
Yeah
<testuser[m]>
I was just saying generally
<testuser[m]>
I use it for small stuff too
<phoebos>
kyxor: why define p as an alias to printf?
<illiliti>
imho: use posix make for small projects and muon for large projects
illiliti has quit [Read error: Connection reset by peer]
<dilyn>
it's my favorite kind of problem to debug:)
<testuser[m]>
Just find where they're called and stub it
<kyxor>
phoebos: I usually define p like that cause it's fast to type, when I do printf debugging saves time
<kyxor>
phoebos: to run make you need shell, to run any program for that matter you need shell. therefore shell is fundamentally smaller form factor than make
<kyxor>
I mean 1 file project may not even need build.sh, probably cc file.c -o exe can do the job too
<kyxor>
it's just there so CLFAGS work and other extra flags for compiler so I don't have to retype them
<kyxor>
correction: you don't necessarily need full shell to run programs, but you must have some process there to fork off from, and usually shell is the first citizen
<phoebos>
i'm not saying there's a system with make but not sh, but if that's your reasoning, spinning up another shell is probably more expensive than parsing a makefile
<kyxor>
this can be easily proven by bench testing, however the difference would be so small that it's practically nothing
<kyxor>
fine look:
<kyxor>
sh vs make just running the command with no arguments
<kyxor>
sh : refs: 4,939,550
<kyxor>
make : refs: 5,205,699
<kyxor>
and don't forget that sh had to source my .rc as well while make is doing nothing but look for files with Make* names
<kyxor>
maybe posix make might be a bit quicker, but in real were are talking 0.0000001s difference :)
<kyxor>
generally make was a mistake, look what it led to: because make was so trash they had to make even more trash on top of it like auto* hell, cmake, bison, configure, meson and god knows how many more to come
<kyxor>
this is what happens when everyone gets on with the bad or incomplete idea
<kyxor>
trying to fix problems they created themselves... I stay true to the real thing which is: cc file.c -o out
<kyxor>
everything else is just extra
<testuser[m]>
kyxor: only autohell and configure build on top of make, cmake is just a generator it can do ninja files aswell and meson also uses ninja files
<kyxor>
Look at this, why can't I compile my linux kernel with cc file.c -o out ? okay it may take a few days given how bloated it is but still what is the limitation
<kyxor>
why did they had to make LTO a thing when instead could just make the damn thing compile in one translation unit
<testuser[m]>
Nothjng
<kyxor>
they could even use #define to toggle the translation unit
<kyxor>
it's just a few things to keep in mind when organizing C code and files
<kyxor>
it's possible to have it organized in such a way that going from one to the other is trivial, like in nextvi I can go back to the old way of parallel make and traslation units without having to change a single line of code except rearrange the #includes
<kyxor>
I could even do it with 1 sed command probably
<kyxor>
Instead of focusing so much on making programs work they should spend most of their time making program modifiable
<kyxor>
what good is it if to make one small but important change I have to go and modify a million things
<kyxor>
Instead of making the kernel impossible to crash they should focus on making the kernel better explain what's going on and why it crashed so that the masses could actually fix the problems themselves. So that a 5 year old could understand it...
<dilyn>
seems irresponsible to let a five year old debug a kernel oops
<kyxor>
Most of the design decisions in software eng. make no sense. Things are being used just because of some misunderstood "best practice" nonsense
<kyxor>
dilyn: he must be a prodigy
<kyxor>
now I wonder how much ram would it take to compile kernel in one unit. 1M loc probably would take 2GB of memory, so with debloated config should be doable