IRC channel logs
2025-01-19.log
back to list of logs
<homo>I have good news: Lennart agrees to accept patches to bootstrap microhs from hugs only under condition that those patches don't remove pattern guards <stikonas>homo: for somebody unfamiliar with haskell, how capable is microhs? <stikonas>I'm assuming it's more powerful than hugs but still far behind ghc <homo>stikonas your assumption is correct, but that is exactly the reason to bootstrap microhs, as it gives slightly more than 50 ghc-specific extensions <homo>microhs demands only 2 extensions that hugs doesn't have - bang patterns and pattern guards (I was wrong earlier, hugs only has guards, but not pattern guards), Lennart doesn't mind patching out bang patterns, but ideally I would figure out yacc and imperative code and extend hugs myself <stikonas>I just wanted to have a bit more context on where we would be if this works <homo>in patches that I sent the runtime crash is caused by "get" function from src/MicroHs/StateIO.hs , I had to overplace Debug.Trace to figure that out <stikonas>also microhs is maintained unlike hugs, so presumably it could support more extensions in the future <homo>in terms of language I don't know any haskell implementation bigger than microhs (aside from ghc), so this is a big step forward <homo>yes, microhs is actively developed, before I started trying to bootstrap a new language extension got implemented <homo>however, in terms of base library we are going backward, but eventually Lennart wants microhs to use base from ghc <homo>microhs's base library is incomplete that is <homo>also worth mentioning microhs is 20 times slower than ghc and produces 50 times slower binaries than ghc, and it's unlikely to change because microhs relies on combinators virtual machine <tmg1|michelson>ie more specifically: when ant-bootstrap attempts to run it gets com.sun.tools.javac.Main is not on the classpath. <tmg1|michelson>but it gets it when it's bootstrapping in its 'build' stage (ie after 'check for optional packages') <homo>stikonas btw, on very positive note microhs supports circular module dependencies, but doesn't use them :) <stikonas>tmg1|michelson: are you running it on guix or trying to reproduce it somewhere else? <homo>I heard hugs can't support circular module dependencies by design, so supporting those requires major rewrite, which is nobody willing to do <stikonas>migth be a bit closer to your distro than guix with its magic... <tmg1|michelson>stikonas: hrm defining those environment variables actually did seem to get further <homo>actually microhs develops so quickly that the day I started patching is the day conflicting changes were committed, and then another day I submit patches is the day some another conflicting change was committed <tmg1|michelson>aha figured out why ant isn't building. gnu classpath 0.93 hangs on File.createTempFile(), always for some reason. <aggi>continued bundling packages for i586-tcc-linux-musl.. looking for a few missing utils absent in busybox, blkid etc. <aggi>it's practically impossible to salvage some recent util-linux with linux-2.4 <aggi>provides an interesting insight into api and abi breakage too <aggi>at least mounting NFS works again, linux-2.4 didn't have FUSE, and it's shfs implementation cannot map uid/gid ownerships <aggi>from a practical standpoint, a few pieces shouldn't be missed, when moving back onto linux-2.4 <aggi>the old thinkpad was a real steal, 30Euros and by coincidence it's a perfrect match for linux-2.x, spares me the hazzle to backport ethernet and similar drivers all at once <aggi>but the linux-2.4 kernel doesn't fully cover all devices yet, booting on some hp t620 thin client, it hasn't got ethernet <aggi>i'll probably choose some broadly available usb-dongle to provide some general purpose options for ethernet and wlan, and backport a handfull of drivers for those "only" <aggi>the new years eve hackathon was rather productive nonetheless; can't believe yet myself i succeeded salvage a complete development host with tinycc/linux24/musl <aggi>a few things are flaky still, since everything was compiled in a cross-development setup <aggi>and i didn't notice any relevant runtime performance degradation with tinycc compiled binaries yet <aggi>if you got a single core 1GHz, 1GiB RAM and a little usb flash memory, things should work, easily <aggi>since it's ~500 packages full review and cleanup takes a little while, since i hacked a few if/else into ebuild scripts to keep the system profile compatible with other cross-targets other than x86/linux24/tinycc <aggi>it's a hundred dirty little patches and hacks, i try to keep cleanly separated for re-integration, since python/portage cannot be supported with tinycc <aggi>and i have to keep an eye on several pacakge trees then: recent portage/upstream, my own tree that is fully forked already and manually re-synced, the bootstrappable tree, and the final system integration that i try to converge with bootstrappable by re-writing packaging <stikonas>argh, still something is wrong and stage0-posix doesn't work with this M2libc :( <stikonas>on aarch64 I'm getting ./AArch64/artifact/hex2_linker-1.M1:569 :Received invalid other; SET_X2_FROM_X1 <stikonas>we need to add "DEFINE SET_X2_FROM_X1 e20301aa" to M2libc <oriansj>amd64 seems to ran fine in stage0-posix if we only update the M2libc <stikonas>yeah, I'll not grab the latest M2-Planet yet <stikonas>and the problem with M2-Planet was that gtker added extern to a file <oriansj>plus cc_* has a handful of weird C behaviors which can break 100% valid C code <oriansj>extern is fine if it is in a header file (because we don't pass header files with extern to cc_*) <stikonas>(thogh at least my review found one crash...) <oriansj>well enums was another of the C language features needed for M2-Planet to build TCC and I can't blame anyone for wanting it <oriansj>once it and bitslices are done, we are probably only a few hundred lines of C away from M2-Planet being able to directly build TCC <stikonas>though perhaps I'm not 100% happy with how global_token->s is replaced there <stikonas>maybe separate variable would have been nicer <oriansj>well all of the remaining C features could be done in 2 dozen lines of code or Less <oriansj>but it'll break the universal FUNCTION pointer logic, which means one would have to add *PROPER* C function pointer support (which requires defined arguments to work) <oriansj>hence why I said a few hundred lines of C away (not impossible just requires *REALLY GOOD* tests and careful work) <stikonas>my userspace qemu is randomly crashing somehow, but I guess that's qemu bug <oriansj>wouldn't be the first qemu bug we have found <stikonas>yeah, I had some issues with newer qemu versions on riscv64 too <stikonas>anyway, I do have both aarch64 and riscv64 hardware <stikonas>so I can natively update most of the checksums <oriansj>yeah, I am limited to x86, AMD64, armv7l and AArch64 native. <stikonas>I used to have armv7l but not anymore... <oriansj>and I hope to revisit the PowerPC port of stage0-posix when I regain enough free time to actually get all the way to cc_* for PowerPC <stikonas>ok, I think I have a fix for that extern thingy <oriansj>another fun feature which would not be a hard add would be is smart locals (no need to worry about variable declarations inside of loops) and it would make the stack clean up at the end of functions just a simple move (which would speed up the resulting binaries and make them smaller) <stikonas>oh yeah, that is another thing we a remissing <oriansj>stikonas: I really should give you M2libc permissions <stikonas>in principle review from you would be good, but you are often busy these days <stikonas>but maybe if I do PRs, fossy can then review <oriansj>yeah, having a 4 year old who is in the 100 percentile is not easy. <oriansj>and honestly I would hate if live-bootstrap's progress ever got stalled on me <stikonas>for some reason I've recently started getting some spam in fossy's name :D <stikonas>some spammers started sending me emails "Hi fosslinux, ..." <oriansj>lets just hope the crypto bros who send death threats ran out of steam and don't ever come back out of the woodwork. That shit killed soo much of my motivation. <rkeene>Why would they care about bootstrapping ? <stikonas>it's not a new thing, it was even a few years ago <jackdk>The people who care about crypto for better reasons than just scamming have a very direct incentive to produce and use high-assurance software, so there's a subgroup that gets drawn to things like Haskell, Nix, and bootstrapping