mircea_popescu: diana_coman, im pleased to report i buried your guy under enough material to last him the month lulz.
mircea_popescu will now go happily to bed, having permanently ruined everyone's shit.
diana_coman: mircea_popescu: ahahaha, that's not hard at all; but good for him anyway, thank you.
ave1: goodafternoon, reading logs...
ave1: I tried to make significant time available all week, but failed. And that's probably also the problem. I first want to have x hours available and then talk. Should go the other way, first talk then just go with it.
ave1: As to ownership, I can own gcc 4.9 and would like to work with trinque et. al. on this. The problem here is limited time, so my primary input can be information/communication at this point.
ave1: I.e. for including / making it part of the OS.
ave1: I was genesing it, and will continue to do so. But with feedback in the loop. So, for example, gcc comes with an old STL html documentation tree, can this be dropped? (I would say yes)
ave1: Also, which languages to keep? c/c++/fortran/ada?
BingoBoingo suspects it may be a bit early to cut entire languages out, but... this is not an area I'm very informed in.
mircea_popescu: ave1, it seems to me we probably want both c and c++ for systems reasons, portions of the kernel / toolset still are in c iirc ; and probably ada since we were doing work on it. fortran possibly not
mircea_popescu: re documentation, it's an iffy proposition dropping any, seeing how little there actually is ; then again it's an iffy proposition keeping any, seeing how dubiously unreliable it can get. what's it bother as it stands ?
ave1: just the number of files and space plus that the STL documention is everywhere and looks generated from something (i.e. mainly clean-up)
ave1: BingoBoingo: main candidates to slash would be "go" and "java"
ave1: mircea_popescu: I used to do some work with Fortran, but not anymore so that could go.
ave1: is everywhere -> is available everywhere
ave1: and has been updated in the meantime
ave1: The version in gcc looks outdated. I can keep it for now, I agree that dropping documentation is moving in the wrong documentation (even if it is outdated)
ave1: O, and proposal for drop also had something to do with 5 images in there. I'll just drop those, the documentation can still be read without these.
BingoBoingo: ave1: Ah. Are the languages separated enough that an arrangement like ave1 signs a remove-java.vpatch and in the odd case someone wants to turn their system into a nintendo they can do a nintendoist signs a dead end restore java.vpatch? Or are the langs far too intermingled for these cuts to be some clean.
ave1: Good point, I don't know yet. I was think to remove these before the genesis as the whole thing ways in at 300mb or so. Plus, java and go don't even work as is.
BingoBoingo: I don't expect GCC is even the place folks would want to run these languages if they were nintendo-izing, but I do wonder how much of a rats nest gcc is.
mircea_popescu: i really don't see the problem with taking anything besides c/cpp/ada out
ave1: Before or after genesis. In past for other packages this has been 'before'. But it would help to not carry around a number of mb in the genesis.
ave1: Come to think about it, it is probably better to first estimate the mbs and complexity involved before even contemplating this question.
diana_coman: fwiw I'd rather go with only c/cpp/ada in genesis and then if someone else wants fortran/whatevers, let them patch it on top.
ossabot: Logged on 2019-11-17 14:02:37 ave1: Before or after genesis. In past for other packages this has been 'before'. But it would help to not carry around a number of mb in the genesis.
ave1: As for current status, I have a big patch file that works as part of the build scripts. So the genesis is feasible. I could also put the build scripts (and other dependencies) in the genesis but this would need to be discussed in light of the OS setup.
trinque: ave1: I have zero use for anything other than c, c++, ada.
trinque: much, *much* more important than cutting those out is getting deterministic binary output.
trinque: right now I've already got a musltronic gcc, so what'd make me care very much about yours is ^
trinque: diana_coman: btw you'll notice items filling in at trinque.org/src over the course of the day.
mircea_popescu: ave1, probably some selection of the build scripts is a good idea. even if we end up changing them later, afaik for all the hate nobody builds shit any other way atm
trinque: 4.9.4's the one used in cuntoo
mircea_popescu: as to fixed binary output...i expect that'll take a whole lot of doing, there's mucho "intelligence" baked in even that comparatively early gcc ver
trinque: even a bit of analysis in that direction would be super userful.
trinque: iirc ave1 was already going down that path.
mircea_popescu: it's not even clear to me, to take this as far in theory as it goes, that once we have a literal by-hand re-written compiler it'll be absolutely deterministic. at some point it becomes a question of "branch binaries by X or carry Y spare MB with each binary"
mircea_popescu: so imo the only sane way to approach that sadness is by progressively limiting variance in binaries.
mircea_popescu: but yes, getting an ever clearer grasp of the shenanigans is central.
mircea_popescu: i understand the abstract appeal of, "look here, hash1=hash2". but what this means is things such as "it is not possible to have a timestamp. AT ALL." sure, in many cases timestamps are abused / fucking stupid. but this is not "many cases", this is AT ALL.
BingoBoingo: ^Time period this particular pest operated is a bit interesting. August 2015 - November 2017...