IRC channel logs

<nimaje>andydude: why are those delta* functions inside a class? why do you have that ScannerDFA class at all? why did you not combine those delta* functions into one? why use those next* functions instead of iterators/generators? (writing better python should at least half that code size)

<mid-kid>Unrelated to live-bootstrap, but does anyone know how to specify the amount of threads that apache-ant may use?

<mid-kid>I have a problem where ant works on my laptop but not on my new PC

<mid-kid>And I fear that may be related to 8 vs 20 threads

<mid-kid>(it runs out of memory)

<mid-kid>maybe stikonas knows

<mid-kid>(if he doesn't then this might be good information for his bootstrap too)

<stikonas>no, I don't know how to specify ant threads...

<mid-kid>stikonas: what kind of machine do you use to test gentoo-bootstrap?

<stikonas>just my laptop...

<mid-kid>CPU/threads and RAM

<stikonas>current gentoo system

<stikonas>oh, I have 16 threads and 64 GB

<mid-kid>64GB is kinda insane but that rules out one theory

<stikonas>well, RAM is fairly cheap now

<mid-kid>giving up for now, I'll just copy an ant distribution from my laptop

<aggi>mid-kid: not sure if this is what you're looking for https://ant.apache.org/manual/Tasks/parallel.html

<mid-kid>nah the problem doesn't seem to be parallelism - I don't think the ant bootstrap has any, or at least htop is only reporting one thread...

<aggi>tcc -ar implementation is giving me headache; it is introducing further side-effects with static-linking

<andydude>aggi: can I help?

<aggi>probably not andydude;

<aggi>it is difficult to communicate, with git-diff of hundreds of uncommitted changes, against a portage overlay that already is somewhat degrading in quality

<andydude>That sounds like a nightmare

<aggi>in recent days, i had to diff through almost 100 ebuilds, makefile.am and similar, another important lesson learned

<aggi>the handling of static and dynamic linking is problematic with many, unncessarily

<aggi>cyrus-sasl, just a random example

<aggi>situation is, i want to retain a package set of important things, such as mutt mailer, within the stage of what tcc-toolchain is capable of

<aggi>and then, cyrus-sasl ebuild/makefile is soaking hours of time, unexpectedly breaking various dependencies etc etc.

<aggi>just because, tcc -ar behaved slightly different (which was another few hours wasted to spot this iregularity)

<aggi>i think i covered all of those issues with sufficient testing, and, i can emit a complete userspace already with tcc-toolchain

<aggi>the necessary testing and cleanup needs to be done

<aggi>and i will have to decide soon, how to cope with the forced transition away from gentoo-tooling

<aggi>because i see little to no chance to salvage python/portage

<aggi>and since this is lost, i may not need to bother with perl/autotools anymore either, and re-write a few hundred makefiles from scratch

<aggi>and i want to avoid an approach which is rather common, such as spawning a separate build/packaging system atop an existing system-integration procedure

<aggi>(such as netbsd pkgsrc atop some lfs/slackware style base-system), because then this duplicates efforts necessary further

<mid-kid>I think if you want tcc to work with a wider array of software you might need to consider further developing tcc

<aggi>tcc already does work with such, it's rather capable already

<aggi>it just reveals, what issues there are on the GNU/linux/gentoo side, which are wrapped into and hidden behind a dozen layers of complexity in the build/packaging-system

<lanodan>which I think is one of the big reasons why oasis just works around that

<aggi>which made me think, if simple makefiles didn't suffice for most of what oasis accomplished

<lanodan>Probably could use BSD make if you want to go that route, at least bsd.mk sounds like a good way to keep static makefiles yet still have configuration.

<mid-kid>the complexity is there for a reason most of the time imo

<mid-kid>in particular, gentoo and portage have grown into the monsters they are today because hundreds of people have come and gone to scratch their itches and hopefully help other people as well in the process

<mid-kid>can you strip away a ton? sure, but you will undoubtedly disappoint a lot of people as well

<mid-kid>it can always be done better, of course, but reducing for the sake of reducing rarely works out in my experience

<mid-kid>you tend to end up with something which can only serve one use case if any at all

<mid-kid>which can be ok! after all, most of the tools in live-bootstrap only serve the case of building the next thing in the chain

<stikonas>and most of the tools in live-bootstrap are added so that we can rebuild pregenerated files

<mid-kid>but I'm really lost as to what you're aiming for with the tcc project

<aggi>compile-time performance is superb, to name one

<aggi>next, i got a complete system profile sanitized, to avoid c++

<mid-kid>I see

<andydude>I can agree with you that c++ should be avoided, but might I also recommend adding perl5 to that list?

<andydude>lol

<stikonas>restricting to just C doens't really make sense

<andydude>I never said that

<stikonas>I'm not saying that you said that

<aggi>me neither, and i do not refuse c++, i merely do not accept c++ where it doesn't belong

<stikonas>just saying that's what happens if one only allows tcc

<stikonas>but one needs some other c++ compiler then

<mid-kid>making a build system for every single project, and/or patching them, is an angle which you can take if you don't care too much about tracking upstream releases (you'll be forking them in essence)

<andydude>maybe we should focus on t++ then

<aggi>i do not refuse gcc/g++ neihter, but i try to move the necessity to have it into a later stage of bootstrapping

<stikonas>anyway, good compiler performance is there because there are no optimizations

<stikonas>that's not really that hard to achieve

<mid-kid>tbh tcc is way faster than gcc -O0

<stikonas>M2_planet might be even faster

<stikonas>but produces rubbish binaries

<mid-kid>actually I'm not too sure

<mid-kid>seaking of

<stikonas>well, self-hosted M2-Planet might be slower...

<mid-kid>I know chibicc is a compiler similar to tcc which I've actually managed to compile some of my projects with

<stikonas>due to it itself producing bad binaries

<stikonas>well, partially tcc is also fast cause it outputs machine code

<stikonas>and not assembly

<stikonas>so there aren't further steps

<stikonas>but that makes tcc source fairly unreadable

<stikonas>and even without that, tcc is really hard to work with

<stikonas>full of 1 or 2 letter variable names there

<mid-kid>heh

<mid-kid>yeah that's why I suggested chibicc

<mid-kid>the output is garbage

<mid-kid>but the source is readable

<andydude>what if there was a language that was like concatenative, so that each word in that language had a 1-to-1 correspondence with binary

<aggi>"15 packages have failed to build, install, or execute", of a total of ~500, that is with AR=tcc-ar

<aggi>it isn't too bad, and it affects things like sasl/mutt-mailer

<mid-kid>andydude: that's just assembly

<andydude>oh, I was thinking of forth, actually

<mid-kid>I'm not old enough to have dabbled in forth

<andydude>I used to have a powerpc with openfirmware on it, tried to hack the bootloader with forth

<mid-kid>heh

<andydude>most forths these days try to use ANS standard, except perhaps fact factor

<andydude> https://factorcode.org/

<andydude>I wonder if anyone has written a c compiler in factor

<mid-kid>tbh I think mes does the "bootstrapping from a minimalist language" thing well enough

<aggi>it's the only project that i am aware, that accomplished it

<aggi>of

<aggi>to arrive at any gnu/posix

<Googulator>mid-kid: I just wish mes's target language (currently Scheme) used brackets {} instead of parentheses () - not because one is better than the other, but because of the traditions built around them

<Googulator>aligning bracket pairs

<Googulator>if (a) {

<Googulator> x;

<Googulator>} else {

<Googulator> y;

<Googulator>}

<Googulator>vs bunching parens at the end of the line... aaaargh

<Googulator>"But emacs handles balancing parens for you" - yeah, f*** emacs, I don't have or want a Space Cadet keyboard

IRC channel logs

2024-08-17.log