<pabs3>heh "Bootstrappable is like the next step for people who like to do a lot of work" <OriansJ>pabs3: after 4+ years of hard work. I feel that comment <siraben>created a PR that updates blynn-compiler's readme <siraben>I fixed that issue I talked about last week where blynn-compiler wasn't building on macOS, it was because Nix wasn't seeing the system input paramater, I have a branch up (system-arg) fixing this <bauen1>mihi: and if you can avoid having to implement any sort of copy-on-write or address space duplication a "simple and stupid" implementation of a kernel would profit a lot <bauen1>also not handling OOM simplifies things a lot <OriansJ>bauen1: well if it makes your job easier. We are also only doing 1 process at a time (Spawned from kaem) and can tell you exactly how much memory is required ahead of time. <bauen1>OriansJ: i already have virtual and physical memory management done in some form (including malloc for the kernel) so that isn't too big of an issue, time is currently my biggest constraint <OriansJ>bauen1: yours or in terms of kernel syscall? <OriansJ>bauen1: wife, kid, fulltime job and the crazy hours I pour into this. yeah <OriansJ>it would be bad enough if I wasn't also doing a family photo archive project <bauen1>for me it's just starting to study, moving out, the impending doom of my infrastructure crumbeling (who needs backups anyway, taking care of that currently), suddenly having to take care of tech support for some family members, working on the software for a satelite, i could probably make this list even longer <bauen1>there's just so much to do (including way too many interesting things) <OriansJ>bauen1: backups are hard but essential. <bauen1>i mean thanks to corona i have a bit more time than usual, but that also kind of vanished somewhere <siraben>With the updated README, we're in a better shape for any sort of public relations/marketing type of activity <OriansJ>bauen1: people always try to fill their lives for the minutes always tick down. <siraben>Hm, time to try to extend the FFI I think, would be good to expose some C primitives to Haskell especially for timing and files, pder would you also be interested? <bauen1>wasn't that on hackernews just a few hours / days ago ? <siraben>yeah, we're already pretty deep into the project ***xwvvvvwx- is now known as xwvvvvwx
***ChanServ sets mode: +o rekado
<siraben>OriansJ: One thing I read in the Guix blog post was that mescc is written in a few thousand lines of C and can bootstrap to GCC, could M2-Planet be extended to achieve that? <janneke>mescc is a couple thousasnd lines of scheme, mes is a couple thousand lines of c <janneke>it's probably quite doable to compile tinycc with a future m2-planet <deesix>Also, mes-m2 is the attempt to convert mes[.c] to the M2-Planet subset, but it hit some roadblocks AFAIU. <stikonas>there are now so many things bootstrapped and yet there is still like one step missing for quite some time :( <stikonas>well, I guess mes-m2 can't run mescc yet <stikonas>well, I think one of your experimetnal mes branch was compilable with m2planet but wasn't merged... <janneke>yes, i've been planning to release wip-m2 for quite some time now <janneke>i'm doing ARM work right now, done the Hurd before that <janneke>actually, i'm debugging gawk-3.0.0 on ARM :( <deesix>So, is that step missing or not? Is wip-m2 able to run mescc? <janneke>yes it can; it needs to be cleaned-up, integrated in the guix bootsrap, and released <janneke>mes-m2 (the project) is a big operation that seeks to give full guile compatibility and a great speed-up <janneke>two attempts to close the gap, that will hopefully come together somehow in the end; best of both worlds <janneke>the wip-m2 branch in gnu mes is an incremental approach to m2-planet support <deesix>Sorry, I don't get it. In what sense is non-exciting to finish the missing piece? <deesix>I think there're different philosophical implicit points of view in this channel that are confusing me, quite a bit. <janneke>yes right, as a missing piece i think it's very exciting, although it was just a whole lot of boring work <janneke>it just hasn't gotten much attention or traction here <janneke>guess we're all real busy with our own work <xentrac>deesix: yeah, diffferent people have different objectives. OriansJ and I think janneke are most interested in security against Karger-Thompson attacks <mihi>janneke, deesix: mes-m2 can be compiled by m2-planet, but it (the Scheme interpreter) is quite buggy. I have 2 fixes for string->symbol and symbol->string, and currently trying to find out why it segfaults once srfi-13.mes is loaded (loading string-join definition, something in expand-let while parsing the case statement) <mihi>the REPL runs (as of what is committed) but it does not load most of the code that mes loads at startup... <mihi>janneke, is your wip-m2 branch in a better state? :) <janneke>mihi: dunno, i haven't touched in in a while <mihi>I guess I will wrap up my mes-m2 endeavor and have a look at wip-m2 instead :) <fossy>are you saying that right now, today, there is a mes branch (wip-m2) that both 1. Can be compiled by today's m2-planet 2. Runs mescc?!?!?!?! <janneke>not sure about today's m2-planet, i used 1.4.0-12-g30a09a5 <janneke>especially i like to get the mes c library cleaned up <fossy>janneke: omg that is very cool <janneke>i'm using too many "forked" .m2 files (~20) <fossy>so we actually do have a full path from 357 bytes to gcc, abliet a mildly complex one <janneke>but most of the credit goes to OriansJ and his marvellous m2-planet <mihi>janneke, fossy: As far as I know the current guix "boostrap" cheats by using some shell and/or guile for orchestrating the bootstrap. So technically, there is probably still some "plumbing" missing to get a full bootstrap that only uses kaem and stage0. <fossy>mihi: the ideal goal for x86 would be from efi as you hashed out the other day <fossy>and then using Knight for the even lower levels for people who want that <fossy>but what I am trying to accomplish using live-bootstrap is basically that, the stage0, kaem and kernel seeds <deesix>Sorry, this has to be a joke (mind the date, in some places) or there's a serious misunderstanding here. How a >1-year-old branch is solving the last important piece of the puzzle and people is talking for a year about things like M3 or blynn-compiler to get there!? <janneke>dates can be deceptive, amends and all <fossy>deesix: yeah, i'm wondering the same thing, lol <deesix>Some amend only can make the branch newer. Nothing below 34cfd9b850097d6a2241053e3e6faf99756d3702 is >2019-11. <deesix>fossy, I also can relate to your initial questions and surprise. <mihi>deesix, where do you see that commit? I checked wip-m2 branch of mes repo on savannah and that commit is not part of it... <mihi>and git log --pretty=fuller reveals that the commit dates are indeed more recent than the author dates <janneke>i try never to do merges and use wip branches until everyting cleanly rebases on master <janneke>eh, *works and cleanly rebases on master <mihi>so I guess janneke should clarify which repo he was talking about, if we 2 looked at 2 different repos, perhaps there is a third one? <janneke>mihi: gitlab is just my scratch repo <janneke>but 34cfd9b850097d6a2241053e3e6faf99756d3702 looks OK