IRC channel logs
2025-01-24.log
back to list of logs
<stikonas>thanks. I need to take another look at it too <fossy>Ooh, this is a feature I want <stikonas>couple of years ago only struct pointers allocated with calloc were supported <fossy>this *looks* fine from an overview apart from style things you've pointed out <stikonas>pointer arithmetic is probably the feature I miss the most from M2-Planet now... <stikonas>I guess cause it's quite confusing to everybody new to the code <lrvick>Clearly my best hope for escaping from c, are people really good at c. <lrvick>M2-Planet builds -fast-. If it could eventually replace Mes that would be amazing. Mes solves an important problem but it is very very slow and complex. <stikonas>well, if compilers are good enough, there could be more than one path for bootstrapping <lrvick>True. Multiple independent paths getting the same result can help build confidence in code that is otherwise hard to review or reason about. <lrvick>Exactly why I am pivoting to go even before the first gcc is built so we can have any higher level tooling in go, a -very- independent path. <lrvick>but the path to tinycc is still the most sketchy bit <lrvick>If that other path ZilchOS took to go from tinycc to musl without Mes is vaible, then we are all set for building go even before Mes <lrvick>then maybe implement autogen replacement in go or something insane. tbd! <lrvick>well, hrm, they -start- with tinycc so no getting around mes just yet. Still. Can pivot immediately after mes at least <stikonas>so I don't think you'll actually win that much by following zilchOS path <lrvick>Well if nothing else early busybox lets me drop a -lot- of deps, so might as well take that easier win for a first pass <lrvick>I'll probably understand a lot more non obvious blockers as Idive in <fossy>we don't use mes after we build tinycc in live-bootstrap either.... <fossy>we still use meslibc for a little bit though <fossy>but that's fairly inconsequential <lrvick>Yeah that is why I corrected myself. the ZilchOS path only saves me steps between mes and gcc4+ <lrvick>and for now I will try stikonas suggestion to speed up Mes with concatinating all hhe c files <Googulator>fossy: Guix currently builds GHC 4.08.2 from .hc quasisource files, and then bootstraps up to GHC 7.0 (pending bugfix for glibc regression that breaks gcc 4.9, needed by ghc 6.6) <Googulator>From then on, I have a patch that goes from 7.0 to 7.6, and then to 7.10, on x86-32 only <Googulator>Then, Guix has a full and proper bootstrap path from 7.10 to 9.2 and 9.4, so long as no 32->64-bit changeover is needed <Googulator>Putting all of that together, we can go from the 4.08.2 .hc quasisources (C code generated by an earlier GHC from Haskell source code) all the way up to 9.x on 32-bit x86 <Googulator>On x86-64, the process is currently stuck on needing a cross compilation step - I tried doing that with 7.10 (which, per GHC wiki, is one of the first versions to officially support cross compilation), but ran into problems - I'm hoping 8.x can perform this cross compilation step. <Googulator>(Guix's main branch currently builds 7.10 using prebuilt bootstrap binaries of 7.8; my patch eliminates that on 32-bit x86.) <Googulator>So, if we can build GHC 4.08.2 using MicroHs on 32-bit x86, we can complete the bootstrap chain on that platform. <fossy>oh nice, so we have a chain from 4.08.2 -> 9.4 <homo>Googulator keep in mind if compiling ghc with ghc takes 5 hours, compiling it with microhs takes 355 hours (24 days 19 hours), this is how I calculated: (20 stage0 + 50 stage1 + 1 stage2) * 5 <homo>where stage0 is microhs being 20 times slower than ghc, stage1 is where binary produced by mhs is 50 times slower than it would be by ghc, stage2 is just too ensure reproducible builds, that stage2 and stage1 are bit-by-bit identical <homo>also how is arm and riscv support in ghc 4.08.2? <homo>like if you take 4.08.2 ghc and microhs, how do you realistically make bootstrap on arm and riscv? throw x86 emulator and turn 355 hours into thousands of hours? <homo>solution: never use ghc, pick haskell projects you need and compile them with microhs <homo>also nhc98 is still packaged in guix, but is not bootstrap, this is where it's more realistic to use microhs to bootstrap another haskell compiler <homo>fossy from Lennart's presentation on youtube where somewhere in the middle of video he tells "why not combinators?" and there he measured microhs and ghc performance, I took those numbers and performed basic division to get 20 and 50 <jackdk>can nhc98 bootstrap off either hugs or mhs? <homo>jackdk rekado tried and failed to do it with hugs, but nobody tried with microhs, and it is pointless now if you are not willing to extend nhc98, because: 1. nhc98 is less portable than hugs and microhs; 2. microhs is the biggest language after ghc <homo>in its current state nhc98 is a toy compiler that likely produces faster binaries than microhs, but available on very few platforms and supports very few extentions <Googulator>homo: GHC 7.x stage 1 takes under 5 minutes on my system, and the later stages are actually built with the earlier stage <homo>that's surprisingly fast <Googulator>although the 1st stage will also run slow, since it's using the MicroHs runtime still <Googulator>4.08.2 has about 5x the Haskell code compared to mhs <Googulator>so a GHC build using mhs is about 10x the time of rebuilding mhs with itself <homo>mhs builds itself in like 20 seconds <homo>5 minutes is 300 seconds <homo>still, ghc doesn't support riscv, and there was no arm support in 4.08 and from what I heard is not great in recent ghc releases either <aggi>don't mean to interfere with the GHC conversation <aggi>since i kept focus on tinycc toolchain support for a _complete_ distribution <aggi>would Hasekell related parts that need a c-toolchain be supported with tinycc? <homo>if you can build hugs with tinycc, then you likely can build microhs with tinycc <aggi>that's the question homo, since i didn't try myself yet (tried to keep script interpreter dependencies at a minimum) <homo>the thing is using tinycc it's easier to build microhs than it is to build hugs <homo>also to build hugs you need yacc <aggi>i remember haskell as a dependency of pandoc <aggi>and decided to postpone that one since it didn't block any other task <aggi>currently, i could not retain ghostscript with tinycc neither <aggi>ghostscript and pandoc aren't related, it's just two components relevant to scientific authoring and document format processing <aggi>mupdf didn't make it into the tinycc profile yet, since it conflicted with acceptance criteria <aggi>i could not salvage a TeX implementation yet with tinycc/alternative-toolchain <aggi>this is _not_ tinycc specific, it is just free software smashed against acceptance criteria of alternative toolchain support <homo>aggi I never heard anyone building pandoc without ghc, so if you want to try with microhs, you might need to modify source codes of pandoc and its dependencies, as well as modify source code of hugs to build under tinycc <homo>it shouldn't be a problem to modify hugs, as hugs can build even on something as weird as plan9 <lanodan>Reminded me that 9front ported ghostscript but it's some ancient 8.53 release. <homo>lanodan alladin ghostscript is non-free only because it's illegal to sell it, but I bet it is actually free software to communists <homo>but if you don't mind that your distro is communist and thus is difficult to abuse by for-profit companies that don't want to pay salaries to workers, sure go ahead with alladin ghostscript <matrix_bridge><Andrius Štikonas> I think current version is under GNU AGPLv3