<stikonas>fossy: so for modern python build system uses python? <fossy>stikonas: parser uses some ASDL thing (not familar with it) and the parser is written in pytnonm <oriansj>how interesting we keep finding bootstrapping problems which other projects somehow managed to ignore. <pabs3>Hagfish: where is the apt quote from? <fossy>oriansj: pregenerated files are often ignored <pabs3>often they are even committed to git, or present on packaging sites like crates.io or npm <Hagfish>pabs3: the quote about apt/npm was from a HN discussion (about one of the various recent supply-chain attacks npm has had) <stikonas>but at this stage live bootstrap managed to bootstrap enough software, so that previously unknown pre-generated files should be getting less of a problem <oriansj>fossy: fair however, one would hope projects like NixOS and Guix would atleast look. Otherwise we might find and fix quite a few more bootstrapping blobs. <oriansj>but I guess the rejection of pregenerated blobby text files, might be a cultural shift that still needs to occur in the larger community. <stikonas>well, that's probably the consequence of top-down approach to bootstrapping that NixOS and Guix uses <oriansj>stikonas: and the rate of package addition (doesn't allow much for introspection and review) <stikonas>(since mes-m2 switched to non-bootstrap mode) <oriansj>depends if we want M2-Planet to use size_t and ssize_t in the bootstrap subset as bootstrap mode is to emulate cc_* type support ***smartin1 is now known as smartin
<oriansj>as I know there are a few places where size_t is the correct C type per the standard but it works just fine with int or unsigned. <stikonas>unsigned should work as long as unsigned is at least 16-bit which it is <oriansj>yep and for some of the input ranges int will work as well. So not required at all (just didn't want to break mes-m2 or blynn-compiler by dropping type support) <oriansj>but now we have typedef in M2-Planet, it is less of an issue <oriansj>and once mes-m2 is free of bootstrap-mode and blynn-compiler (I can do that this weekend) is as well <oriansj>just wish testing bylnn-compiler with M2-Planet wasn't so slow <oriansj>also siraben didn't we want ultimately make M2-Planet support enough C features to stick closer to the upstream master? <stikonas>well, at the very least we can now use #defines instead of // CONSTANT in blynn-compiler <stikonas>I'm not actually sure what might be the next best improvement in M2-Planet... <oriansj>so a functions folder isn't needed anymore <oriansj>stikonas: probably support for foo[a][b]=c; <stikonas>one thing that is not working as C99 requires are logical AND or OR (we use bitwise AND/OR instead of those). But I think mes only uses them for 0 and 1 True/False (unlike !) <stikonas>so I think we can live without proper logical operations for now <oriansj>yeah, it would require a bit more complex of a code change <stikonas>upstream mes also uses "a.b" quite a bit <stikonas>yeah... I guess one would have to calculate correct offsets to store structs on stack but should be doable <oriansj>(we just can't use it internally as cc_* doesn't support it) <stikonas>yes. Well, that's true for almost every tool in the bootstrap chain <stikonas>we don't really need to use it internally, calloc + -> works just fine internally <stikonas>btw, live-bootstrap is now switched to newer stage0-posix and mes-m2, so doesn't use bootstrap mode anymore <stikonas>so I guess it's just blynn-compiler that uses bootstrap-mode <stikonas>well, and blood-elf, M1 internally in stage0-posix <oriansj>but they don't use size_t or ssize_t as if I remember correctly <stikonas>I tried with those size_t and ssize_t removed and stage0-posix builds just fine <riv>what are you working on? <oriansj>making blynn-compiler no longer need --bootstrap-mode so that we can strip it down in M2-Planet <stikonas>that's because M2-Planet now has some preprocessor support, so blynn-compiler can be closer to upstream... <oriansj>or with luck (and possibly a few new functions be part of upstream) <stikonas>well, preprocessor support is not that new now. But it did get a bit better recently <Hagfish>the fact that live-bootstrap doesn't need a bootstrap mode is particularly cool (although almost ironic) :) <oriansj>Hagfish: well bootstrap-mode is more about catching changes in M2-Planet that are not supported by cc_* <oriansj>and was kinda used as an ad-hoc M2-Planet legacy mode when preprocessor support was added by yt <oriansj>which was also around the same time that M2libc started and FILE became a real struct rather than an int <Hagfish>i mean i guess that works, but that does seem like a severe limitation <oriansj>Hagfish: well yes, no buffering and a raw 1byte read syscall and 1byte write syscall are trivial to implment and provided the minimal functionality needed. Buffering and bigger blocks of write and only a single read syscall for an entire file really speed things up <Hagfish>yeah, it's amazing what goes on between the edges of "possible" and "easy" <oriansj>well also layers of abstraction really expand easy into the hard problem space. <oriansj>Doing a C preprocessor in assembly => hell nope <oriansj>doing it in the limited C subset of cc_* => actually not that bad <oriansj>although part of me hoped the blynn-compiler path got more love, because then we could do a scheme in haskell, the haskell in C and the C as a scheme program for MesCC; <oriansj>but eh, doing a haskell is hard and M2-Planet needed to get better first <Hagfish>i thought the purpose of this project was to get rid of cycles in build systems ;) <siraben>oriansj: if M2-Planet had more C features it would be easier to stick to blynn's work <oriansj>There is a difference between 3 language starting points than a cicular dependency <siraben>It's still a viable path but I or others would need to sit down and actually do it (the Scheme interpreter in Haskell) <oriansj>siraben: absolutely, and with the new preprocessor, we certainly are much closer than ever. <siraben>I haven't seen a better bootstrapped and feature-rich Haskell as this one <oriansj>also nice to see the potential for NixOS to pick up live-bootstrap; even if it means I have a great deal more work to do first <oriansj>and blynn-compiler has be updated to use latest mescc-tools, M2libc and the latest M2-Planet in non-bootstrap-mode <oriansj>and it should be much work to make it work on non-x86 hosts <oriansj>although I think I broke the github build thing <oriansj>probably needed to update the nix package definitions or something <oriansj>I'll leave that for someone else (as they will also need to replace mescc-tools-seed with stage0-posix) <stikonas>well, it might be nice to have alternative paths (m2-planet->haskell->scheme->mescc) but I suspect it might be easier to just improve M2-Planet to the point where we can build mes (possibly a bit simplified) <stikonas>mes-m2 fork already showed that this is possible, but it was probably a bit too invasive to land upstream <oriansj>stikonas: well yes, of course as M2-Planet grows features; it gets closer to being able to directly build TCC itself as well <oriansj>unfortunately there is no tool that says: here are the list of language features needed to build this set of source code. <stikonas[m]>I did check a bit what mes needs... Mesclib is actually not too bad, but mes itself uses more complicated preprocessor functions with . <stikonas[m]>In any case, before TCC can be built, almost surely mes would be built first <oriansj>well bitslices and C style function pointers are the 2 big ones if I remember correctly. <oriansj>but that isn't something impossible to clear out either; should we go the mescc->modified TCC route <oriansj>but right now, it isn't needed because we have mes-m2 working and it is good enough <oriansj>and I don't think anyone wants to responsible for a TCC fork or getting TCC to adopt simpler bootstrap requirements. <stikonas[m]>Well, TCC were reluctant to accept janneke's patches <stikonas[m]>And instead wanted bootstrap compiler to be improved <oriansj>hence why I suggested such work would likely turn into a long term project by itself. <Hagfish>"I think with that behavior [i.e. npm client handling platform-specific binaries] in place we could safely change defaults [to prevent scripts running on npm install] in a Semver Major." <Hagfish>that's probably a net win, but we'd have to see how the ecosystem adapts to those changes <oriansj>well it depends on how many people want to address these issues vs just shipping enough to get their bosses off their ass <Hagfish>the trick is to incentivise bosses to care about security (but unfortunately that's even harder than getting them to care about things which claim to benefit security) <oriansj>Hagfish: nope that only leads to checkbox security and believe me when I say it drains what security resources that might be there away from real security work. <oriansj>and that isn't even mentioning the snake oil security people who make bank with false promises <oriansj>real security is always the absolute last thing they will try after all other possible options have been exhusted. <oriansj>and it isn't even the hard things either. There are major systems by major vendors sold as security products that store passwords as plain text; don't encrypt network traffic and fail to even checksum updates <oriansj>its like "Industry leading security product", baked in password of badgers for a hidden root account that you can't disable or change the password to. <oriansj>clicking cancel 16 times in a row logs you in as root and oh just press down and hold that backspace key for a couple of seconds to bypass all boot security protections. <oriansj>And I'm responsible for the security of this shit (which oh by the way is proprietary with support contracts that somehow doesn't actually do any good in getting support for real security issues. <oriansj>Oh and your phone company sold a copy of your location history to anyone willing to pay $17/year for it