<yt_>I've tested the bootstrap up to mes-m2, but not tested any of the conditional inclusion in anger, so it might still be a bit buggy. <yt_>and thanks to deesix for spotting some of the M2-Planet compatibility issues in an earlier draft. <stikonas>ok, I think copying mes's config.h will be much easier than fixing escaping in kaem.c <fossy>wait what it shouldn't eat the next character <fossy>just copy it for now and i'll fix kaem.c <fossy>it is meant to just eat the \ <stikonas>fossy: yeah, I'm already testing the copy stuff, should soon be done <stikonas>fossy: I'm also removing the "second" pass of mes build because now we actually build the first one with M2-Planet, so the mescc build is already the second pass. And I checked it's a fixed point anyway, file hash already matches <stikonas>this is with just kaem :), no other shell at all <Hagfish>as a slight distraction, i see that last month the results of the 2020 "Underhanded Solidity Code Contest" were announced <Hagfish>see if you can spot the trick on line 65 of this file from the winning entry: <fossy>stikonas: thanks very much! i'll have tcc done probably today, debugging a compilation error with mes, but since mes dosen't give line numbers have to use MES_DEBUG=5... which is quite slow <fossy>janneke: there is no way for mescc to give me line numbers for compiling, right? <stikonas>fossy: I've pushed an updated PR but I can only test it tomorrow, going to bed now <fossy>stikonas[m]: completely fine, no rush at all <OriansJ>yt_: looking at your C preprocessor code changes now <OriansJ>we can be stricter on input in M2-Planet than C requires yt. So we can require no whitespace between "#" and "if" <OriansJ>yt_: just a thought but wouldn't it be easier if the C preprocessor was a seperate program, so that it wouldn't as limited by cc_*'s limitations and could get correct signed behavior? <xentrac>typedef does not canonically belong to the preprocessor <xentrac>(forgive me if that's stating the obvious) <pder>This eliminates the need for IO redirection. Instead the input and output files are arguments to each compiler command <OriansJ>xentrac: you are absolutely right and it appears my eyes dropped a token when parsing the sample output <OriansJ>honestly it is a little odd seeing M2-Planet become slowly a full and proper C compiler. <OriansJ>all I need is someone to drop a patch so that struct token* f; f = f + 1; behaves identically to C and It'll basically have all the things people complain about solved. <OriansJ>xentrac: I haven't done it yet but it is basically the only thing that would need to be changed. <OriansJ>Then I can just extend yt_'s macro work to include #define and we can either output CONSTANT or remove the need for it entirely (I think output CONSTANT is probably a better plan) <deesix>I think yt_ is already working on that. <OriansJ>deesix: yeah I just merged yt_'s preprocessor work <OriansJ>need to run astyle -A1tSxejz2fpUxV on it but consistent formating is easy to fix. <deesix>I mean, more capable preprocessor: """I think I do want nested expansion [...] I'll probably leave out varargs, but that should be easy to add later""" and some other plans. <siraben>pder: thanks for your work on removing shell redirection <siraben>So what's the plan to do it in Haskell later? <OriansJ>well piece by piece M2-Planet is getting closer to what is required to compile TCC directly. <siraben>OriansJ: overall, M2-Planet C code should be able to be compiled by TCC/GCC right? <OriansJ>siraben: M2-Planet code is standard C code <OriansJ>the only bit is the trick with // to work around the pointer + 1 behavior difference and CONSTANT to provide for the lack of #define support <OriansJ>but what I am saying is as M2-Planet grows C primitives, it heads towards constaining the full subset required to build TCC directly. <pder>siraben: the changes I made to remove the shell redirection breaks the getArgs stuff I see in precisely. For example, you cant do "./bin/precisely comb" <OriansJ>It honestly isn't a huge task either. I just have made it harder for myself by sticking to 1 file input and 1 file output standard to make running these steps on bare metal easier. <pder>It would be nice to get this working properly in Haskell since it has some methods in the FFI to get the arg count and args <pder>Because I simply expect argv[1] and argv[2] to be the input and output file. <pder>If you look at line 2046 of precisely.hs main = getArgs >>= \case <pder>I thought that we could add better command line handling in Haskell there to specify input, output files, and any other flags <siraben>What sort of arguments would you like to see? <OriansJ>probably should fuzz yt_'s work to catch the painful bugs <pder>siraben, I guess if we could still handle the exist "comb", "lamb", "type" as well as specify input and output files <siraben>Ah right, those args dump the bytecode/lambda calculus/types IIRC <deesix>OriansJ, what do you use for fuzzing? <pder>Do you know what we would want to add to the ffi? <siraben>Anything useful and IO-related could be added to the FFI <pder>Also, can you tell if precisely can be run interactively? <siraben>OriansJ: don't you have to compile with afl-gcc to properly exhaust the code execution paths? <OriansJ>siraben: yes you do but that is fine as I am just using it on a machine for generating of the test cases <OriansJ>when it finds a case, I download and verify then fix. Upload the new code and restart the fuzzer on the dedicated fuzzing machine <OriansJ>(saves my laptop battery life when I am unplugged) <siraben>pder: interactively as in a REPL like in GHCi? <siraben>It doesn't do any interpretation, so if we added a REPL we could get the type and compiled output <siraben>I think because of some earlier stage mutually, it has to parse the whole input <siraben>pder: what would you want from an interactive precisely? <pder>any features you feel like are missing? <siraben>Not really, it's just a matter now of settling on a prelude to include so people don't have to redeclare half of GHC's prelude to get anything done <pder>Yeah, I think it would definitely be nice if hello.hs could just be main = putStrLn "hello, world!" <siraben>Since blynn isn't that active on GitHub, I'll email him again re modules <siraben>I think he'd be pleased to know his work is being used <siraben>pder: How's learning Haskell by the way? <pder>Its been passive lately. Ive watched a few videos and read some tutorials, but havent written anything yet <siraben>No rush, it can take some time for it to sink in, like Lisp <pder>I would certainly like to understand more of how blynn-compiler is bootstrapped. Some of it feels like magic <OriansJ>pder: well that is why the bootstrap bit needs to have a lot of magic forcefully removed. <OriansJ>even if it means I have to write something annoying. <siraben>Yes, the only magic left is the rewrite of the first four stages into one, readable stage in lisp <pder>I would not know how to verify generated/parenthetically for correctness <pder>siraben, could you write it in scheme that could run on mes? <OriansJ>pder: we never verify the generated files as being correct. <OriansJ>not unless someone wishes to work on a proof for the generated output's correctness <siraben>i will make a binary.scm doing the same thing <pder>so would that scheme output bytecode that runs on bin/vm? <siraben>That branch I have replaces stringy with lispy, then binary with binary.lisp <OriansJ>then we just need to audit the binary.lisp and boom trusted bootstrap for Haskell <siraben>I'm glad Ben Lynn didn't use anything more than ANSI C otherwise none of this would have been possible <siraben>Too many fancy implementations out there, which hurts bootstrapping <pder>yeah, the only thing missing ended up involving 64 bit types, but that shouldnt matter <pder>no long long in M2-Planet <OriansJ>pder: well more no need to generate binaries more than 2GB in size yet <OriansJ>I could add it with just 5 lines for AMD64 and AArch64 but on 32bit platforms it is more of a problem <OriansJ>if nothing else; M2-Planet should know when to stop adding features and let the users pick up a much better linker, assembler, C compiler and C preprocessor that actually complies fully to the C standard. <OriansJ>although I am far more excited to see the scheme interpreter writte in blynn-compiler's subset of Haskell. <OriansJ>if it is good enough it can be a drop in replacement for both guile and mes.c <pder>I wonder if Haskell might have some other uses for writing tools that would be awkward to do in C <xentrac>yeah, there are a lot of things that are a lot easier in Haskell <OriansJ>or probably for problems that better map to the Haskell solution space than the hand written C solution space. <OriansJ>also it would be funny to say the secret to bootstrapping GCC was to write a Lisp in Haskell to run a C compiler written in scheme. <OriansJ>since we have almost bootstrapped that haskell and janneke did write the C compiler in scheme. <OriansJ>all that remains is a proper scheme written in haskell and then we can make everyone's lives so much easier for long term maintaince of Gnu Mes <OriansJ>for if we do it right, it'll be able to run guix and that lisp written in haskell becomes the root binary of guix forever. <OriansJ>but I do tend to dream quite bold in regards to this project. <OriansJ>just wished I knew of a less ugly way to make all M2-Planet tests completely parallel in nature. <OriansJ>because the changes would be a little tedious but then make -j 42 would build all the tests at the same time and the build with tests for M2-Planet would be done in 1 second <OriansJ>and cleared out some possible segfaults from cc_macro.c <OriansJ>now to hope not too many new segfaults show up from fuzzing before I wake up <Hagfish>parallel builds in less than a second would be pretty epic <Hagfish>that sounds it could be a fun challenge that motivates someone new who hears about this project <Hagfish>i'm not sure what sort of skill set or background someone would have to have to come up with an elegant and suitable way of achieving that <gforce_d11977>good morning, i'am puzzled: OriansJ writes, that M2-Planet can maybe in the nearer future build TCC directly, but on the other side everybody looks to blynn-compiler? 8-))) lets see what the next weeks are showing us...everything looks very promising <fossy>gforce_d11977: different paths essentially <siraben>gforce_d11977: I see active, promising work on both paths <siraben>ultimately the goal is not only we get to GCC, but we have different ways to get there and would be able to evaluate the tradeoffs of each approach <fossy>i'm pretty happy that we have a m2-platet -> tcc bridge <fossy>but it's still pretty jankyish <siraben>is that without help from guile yet? <fossy>siraben: yes, janneke ported mes to m2-planet some time ago <fossy>and still is to some extent but it better <gforce_d11977>but maybe i'am doing it in a wrong way. i will try to share my 'way' this week <fossy>gforce_d11977: no stable release or master branch has support for building mes using M2-Planet <siraben>fossy: oh i see, is there a lot of work until we don't need guile at all? <fossy>siraben: well, we don't technically need guile at all (see my live-bootstrap, we only use kaem and hex0 (after stikonas' pr) <fossy>but guix seems to be stuck on guile for quite a while <siraben>fossy: could you link to live-bootstrap? <siraben>i'd also like to replicate this in Nix, I only have up to mescc-tools-seed, m2, kaem, mescc-tools package at the moment <siraben>Nix should reduce its bootstrapping as well, IMO, but the bootstrapping process isn't well documented <fossy>siraben: what does nix use to build packages? <fossy>right, Guix uses Guile as a driver, live-bootstrap uses kaem, what's the "driver" in nix? <siraben>Pure, dynamically typed, lazy functional language <qyliss>Isn't bash more like the driver? <qyliss>Nix generates bash scripts that build packages <fossy>qyliss: well, are the generated scripts human-readable? <qyliss>well, to some extent but not really <siraben>Nix expressions result in a derivation which drives the build <qyliss>but the Nix language isn't being interpreted at build time <fossy>so is there any way to extend that down to th ebootstrap, or do we need an extra seed for nix so that it can create a derviation? <qyliss>Nix probably needs a shell to bootstrap <qyliss>Although it does actually bundle one <fossy>well we have kaem which is probably not sufficently complex <qyliss>It comes with a staticly-linked busybox <siraben>I just ran `nix show-derivation $(nix-instantiate '<nixpkgs>' -A hello) | ix` <qyliss>So probably should just use that <siraben>This is on macOS, so the dylibs are specific to macOS <qyliss>Since Nix having an embedded shell is the equivalent to Guix's build-type scheme interpreting <fossy>the things i'm trying to fill with live-bootstrap: 1. *strictly* minimal seeds, meaning hex0 kaem and kernel (which is very hard to fufill with a linux distribution) 2. strictly human-readable source code (no pre-generated configure scripts!) 3. kernel bootstrap path (not done by guix) 4. extensible, configurable automation (guix does that pretty well) 5. lots of possible final states <fossy>oh, ofc, 6. complete reproducibility on all systems 7. everything post-bios <gforce_d11977>fossy: i just tried your 'live-bootstrap', but my self-built kernel complains about a missing /sbin/init - what is your proposal? <siraben>fossy: how would I run live-bootstrap without needing qemu? <siraben>something like how mescc-tools-seed works on Linux <fossy>gforce_d11977: i must apologise for not having a readme yet, it is in the workds. <fossy>this will be because you have not run git submodule update --init --recursive <fossy>siraben: comment out the qemu line and use the generated initramfs <fossy>and the kernel of your providing <fossy>until we have a bootstrap kernel <fossy>yes, i know there is a leak from the host system into the first initramfs <siraben>ah cool, will it print to console or display in the screen? <fossy>whatever you tell the kernel to do? <fossy>the ideal goal for the seed would be a small floppy image containing only seeds that loads all the source code from a usb or cd-rom or something <siraben>what about just running it without an initramfs? <siraben>or does that assume too much from the host system <fossy>siraben: do you mean basically running all the scripts without an initramfs? <gforce_d11977>fossy: i'am also working on a very similar approach: i want to include all sources in a .xz compressed initrd <fossy>gforce_d11977: do you have a link? i like collaboration! <fossy> gforce_d11977: what do you have in sysa/mescc-tools-seed? <fossy>siraben: i tried that with gcc-seed, it utterly failed <fossy>everything after tinycc relies soo much on the host system <gforce_d11977>fossy: i will publish the link soonish here (tonight or tomorrow), it needs still a lot cosmetics, sorry about that <fossy>so many hardcoded paths etcetc <fossy>its just way to hard to ensure reproducibility <fossy>and that seeds are not being leaked through <fossy>if an initramfs is not used it's not really being bootstrapped anyways <siraben>Ok right, have to get the reproducibility all the way <fossy>gforce_d11977: so does live-bootstrap tbh :D <fossy>gforce_d11977: how are you managing teh creation of the initramfs? <gforce_d11977>another thing what comes to my mind: how do we solve the problem of making the first hex0.bin executable? for now i include a static 'chmod' binary in my initrd <fossy>it is put into the initramfs executable for me <fossy>but this is something i will solve when i solve the generation of the initramfs <gforce_d11977>fossy: i have a script which downloads all the files to 'step1', 'step2', 'stepN' folders and pipes that to cpio <fossy>is there any automation involved? <gforce_d11977>fossy: for now it only bootstraps till mes-m2 (i'am so eager to have tcc...) <gforce_d11977>fossy: for now i include a static busybox (with ash, mount, chmod) <janneke>the blynn compiler, is that written in M2? <xentrac>The beautiful monks of the crying witch. <fossy>you may like to investigate kaem, the bootstrap shell <fossy>janneke: well, not quite ask siraben about the details but basically <gforce_d11977>fossy: for now I avoid kaem, maybe later...i want to have a 'prompt' so that i can interact with the stuff that was built <gforce_d11977>(and having a posix-shell with only builtins (no external commands) is OK to me...) <fossy>maybe i'll add a repl into kaem eventually <gforce_d11977>fossy: i even started to make a c-ish compiler in posix shell, but stopped for now... 8-) <fossy>gio_ is here! i really like asmc as well, it works very very well <siraben>it would be possible to skip the C step and write vm.c in assembly, since the "C code generation" is really just pasting various bits together with a large int array <stikonas>fossy: I've now tested my updated PR, it seems to work <stikonas>and actually I don't mind completely removing last Hello test but maybe when tcc is added (when tcc will be testing that mes executable) ***gio_ is now known as gio
<OriansJ>Hagfish: currently the only thing preventing totally parallel tests is the fact that AMD64, AArch64, x86, armv7l, knight-native and knight-posix use the same temp files for the same test. eg one can already fully parallel AMD64 tests but when one does ./test/test1000/hello-amd64.sh and ./test/test1000/hello-aarch64.sh at the same time they both use the same files. So in that case one needs instead of outputting to the generic <OriansJ>test/test1000/cc.M1 but instead to a test/test1000/cc-$arch.M1 and duplicating that same tweak for all steps. Then none of the steps will write to the same output files at the same time. (then simply tweak the cleanup scripts to pick up the additional mess) boom done. <OriansJ>it isn't hard, just a little tedious but creates for a great hey I did this sort of thing. <OriansJ>gforce_d11977: you can use kaem-optional-seed as your /sbin/init ; you just need to add a kaem.run to where it'll read it and run the mescc-tools-seed build script. Then it can spawn the newly built kaem as your shell (after fossy add support for a REPL) or gash <OriansJ>shortest way to express my strategy: Novelty first search with a bias towards expanding the number of possible future paths to solution. besides I'd bet money that janneke never thought a haskell compiler would show up lower in the bootstrap path than GCC. <janneke>given that haskell doesn't have a proper bootstrap story, i wonder who could predict that <janneke>let's not forget that we don't have a path from the haskell compiler to GCC yet <OriansJ>and if we go for full r7rs-small compatibility in the lisp written in Haskell; then Gnu Mes becomes a Haskell interpreter for scheme with a C compiler written in scheme able to bootstrap the blynn-compiler haskell interpreter <OriansJ>also it would allow us to drop guile from the guix bootstrap entirely <OriansJ>it'll become once you have Gnu Mes, you are bootstrapped. <Hagfish>that solution to the parallel test suite doesn't sound too bad. what about putting the arch name in the directory instead of the filename? <OriansJ>Hagfish: could be done that way too but it just requires someone to do the tedious changes. <gforce_d11977>OriansJ: fossy: when REPL in kaem is ready, i can simply switch, but these are "long hanging fruits" <OriansJ>gforce_d11977: there are always lots of low hanging fruits because they are great entry points for other programmers to step in and start feeling productive. <gforce_d11977>OriansJ: hope this was not meant as a sidekick to me 8-) you are right <OriansJ>siraben: although if doing it from scratch is more fun; do that instead. ^_^ <OriansJ>gforce_d11977: I encourage people to do what they think is fun or interesting. Choose what makes you happy ^_^ <siraben>OriansJ: it would take a lot of effort to make it work in blynn-compiler <siraben>I'm planning on porting mine github.com/siraben/r5rs-denot which doesn't use much fancy features <siraben>Also, it can be verified by comparing against the R5RS language spec <vancz>maybe after nothing-up-my-sleeve numbers we can have nothing-up-my-sleeve compilers <vancz>(someone find a bootstrap source in the digits of pi?) <stikonas>while it almost certainly (certainly not proven) exists somewhere in the decimal expansion of pi (just like any other random subsequence), finding it is impossible <stikonas>well, almost all real numbers share this property <stikonas>well, if it's 300 byte sequence, that's probably ~750 digit sequency you are looking for <malina>as "almost certainly" as finding that every irrational number is really rational. <stikonas>so you'll have to check about 10^750 digits before finding the right place <stikonas>that is way more than age of universe in plank time * number of subatomic particles in visible universe <malina>no, any sequence has a 10^-750 chance of holding a 300 byte sequence then, assuming a non weighted sequence, something PI isn't.. <malina>so the chances are even less. so as Stikonas says. not very likely ,) <malina>although I am not much of science's boogeymen like claims like "planck seconds * molecules in the visible universe'" . cute despite claims of making good estimates <malina>they are just as likely to be so off, it is totally non-sequitur <stikonas>anyway, I was just saying no computer will ever find that sequence <stikonas>unless somebody writes much shorter bootstrap sequence <xentrac>stikonas: there might exist an efficient pi-specific search algorithm <malina>I know people might _think_ I come across as this or that but I am far more benign than it seems. ,x <Hagfish>maybe you should change your nick then? <Hagfish>anyway, if you wanted the bootstrap sequence to appear in pi, it might be simpler to design a CPU whose machine code happens to make the digits of pi a valid bootstrap program <xentrac>afaik it's an open question whether pi is simply normal in any base <stikonas>Hagfish: yeah, that would be eaiser to design CPU that way. Might be even not too hard <stikonas>xentrac: yes, but you'll just choose opcode values to match what you already have in the sequence <stikonas>that will obviously be very artificial arch.... <malina>who should change their nick Hagfish ? <malina>if me, ye I can grasp that if my nick was hag fish, but mine is malina. It shouldn't be too malignant at all for normal people. I know it's irc but I still rate normal people over the freaks. ,x <xentrac>here, we rate freaks over normal people <xentrac>that's why we can do things normal people can't <xentrac>go back to swilling Budweiser and yellingat your TV, malina <xentrac>malina: we freaks have no reason to put up with your bullshit. fuck off <rain1>hope things are going well for you! <vancz>;PP <stikonas> so you'll have to check about 10^750 digits before finding the right place <yt_>OriansJ: thanks for the super quick review. the quick turnaround time on patches honestly is one of the best things about contributing to this project: doing cool things and then seeing those included within hours is fantastic <Hagfish>malina: if you are more benign than it seems, perhaps you should change your name to benina :) <Hagfish>xentrac: i appreciate you standing up for the freaks :) but please try to be civil in expressing your objection to malina. treat this as a teaching opportunity, that we can all learn from <malina>hag fish! I see your point now :D <Hagfish>"hag" and "fish" are two separate words, but "hagfish" is itself a single word (just in case you weren't aware) <malina>is Budweiser an American thing? I'd go for Orval if I were to enjoy ales, me thinks. <malina>you sound kinda just as passive aggressive as the muted one. I don't think there are spaces allowed in irc names, yes? So to be fair, contracted nicks don't always entail intentions of making two words into one <Hagfish>absolutely, your parsing of it was completely understandable <malina>my tab will make sure your nick is usually used Hagfish , even if I would by chance type out hag fish, instead of hagfish ^^. <Hagfish>please don't interpret my words as passive aggressive though <Hagfish>if your tab completion removes spaces, that's quite clever <malina>well, it just seems so, but it's just the classic people blowing up , it's irc ,I'm used to it. no worries. moving on, so this schema, is used other places than guix or was it developed for guix specfically? <Hagfish>there was talk that debian could use it for their bootstrapping efforts, but i guess it depends which distros are most motivated to do the work to make use of it <malina>from past days and seeing you guys at it, I see it being related to mescc which is scheme dependent yes? <malina>well, IF the path of least resistance is to use .scm to bootstrap , then I don't mind as much bringing it in as that, although I _should_ of course spend the time to replicate whatever .scm has done to glue the m2-planet <=> ...<=> tcc....gcc.... <Hagfish>it would be nice if wget let you specify a hash <malina>cheers rain1 Hagfish , yes that would be a nice feature. I work a lot on these things in my package manager. and of course almost a decade ago, I wanted to incorporate 'kademlia' into my backend. As I say, guix is kinda my 'rival' in the sense, I see most of the stuff I think about, appear in guix. Which is a good thing, in the sense, better that than somehting awfully proprietary ,p <malina>I just fixed LFS sources yesterday to use b2sums at the very elast instead of md5sums, they can be stubborn :p but ye, to update their sums, I was doing wget $url -O- | b2sum ... <malina>IF I get time, I might see if I might patch something to do something a la, that idea in that link Hagfish . very nice feature request. shame it was closed down. <rain1>i did this with my LFS system, hash everything downloaded :D <malina>OH, rain1 have I seen you in #lfs perhaps? <malina>if yo uhave been there in the past 4 years you might have come across me there, although I am often away for months. <malina>yes, I use b3sum in my system rain1, after years of sha35 (sha3-512) <malina>my package formats break so much, which is why I don't offer my distro to people.. I woud only have "oh why is this broken", and then I would be on support 24/7 instead of actually devving along :D <rain1>mny prob is all software is constantly updating and i can't possibly keep up <rain1>and figure out which versions are compatable which <malina>I know :) that's what I lament about always.. _time_. luckily bug time isn't bad, but 'being current' is. and the backlog on 'features' which is what I _really_ want to do has suffered immensely sigh. <malina>will show me the compile error and it doesn't take too long to patch stuff. I feel my distro is top tier, so i don't worry abotu bugs too much. it's more features, which I lag behind in years now, being solo :( but ye, lfs is a desolate passion. :D <malina>rain1, your paste, is it for 32 bit btw or 64 bit machine? <rain1>im on a 64 bit machine but this builds 32 bit mescc I think, that is the only arch available <rain1>let me check the tinycc binary <malina>but running your paste as-is, it didn't find: <stikonas>mes pre-inst-env is only available after configure <malina>I will see if , I forgot ot actually double vet the thing. :) <stikonas>when mescc runs pre-inst-env will already exist <stikonas>in any case, you can build mes without it... <malina>I built this 2 days ago the first bit, but minute the wip scm guix stuff came into play i thougth, none of this I know, at all. <rain1>but maybe MES_PREFIX is enough <stikonas>it was a bit harder to get everything in live-bootstrap, but I think, it's now close too <stikonas>kaem is a bit more limitted and buggy than bash... <rain1>it was originally just to run a sequence of commands, not sure if it grew <stikonas>yeah, but even sequence of commands was tricky... <rain1>but i suppose once we have mes we can probably run gash? anyone know if that is true <stikonas>e.g. mescc needed to run command containing quotes <stikonas>tar/gzip/bzip/xz implementation in guile <stikonas>that's basically where guix bootstrap starts <stikonas>anyway, bash is probably not that hard to compile once you have tcc <rain1>is that going to be the next thing? <rain1>or maybe the C impl. of these tools can be built with tcc? <stikonas>fossy is still writing tcc compilation script <stikonas>I tried with bash to test but can be easily done in kaem <stikonas>something like for f in *.c; do $CC -c $f; done <fossy>stikonas: yeah im getting there <fossy>MES_DEBUG=5 FTW for finding compilation errors <fossy>stikonas: can you plz let me know if you find any other kaem bugs. it is still qutie buggy yes <stikonas>does bash introduce dependency on pipes in bootstrapped kernel <stikonas>so probably need to build kernel first later... <stikonas>although that doesn't mean that we have to do it right now <fossy>correct we can add in that step later if we want <fossy>unfortunatley the output of so much info to stdout in MES_DEBUG=5 makes the process much slower... i think theres only 1 remaining compilation error <fossy>then to make sure it works with ur branch <stikonas>rain1: I think fossy is trying to avoid configure <fossy>the only thing we need to make from configure is config.h <stikonas>but at least once we have bash it will be easier to debug live environement... <stikonas>I was doing most of the testing outside of it <fossy>if i have issues in live environment for now i have been putting a busybox.static inside it and adding /busybox.static sh to the end <stikonas>I also tried running it inside chroot but it had some problems... <stikonas>somehow PATH failed to find cp in kaem scripts <stikonas>by the way, I think cp has some bug, in my kaem script to build mes-m2 it prints one header file to output... <fossy>that's what happens if it cant write to the result for some reason <fossy>i wrote it in 2 hrs to fill the current need for it, it is most likely buggy <stikonas>so maybe mes/include/linux/x86/syscall.h is not installed <fossy>normally the target directory dosen't exists <stikonas>otherwise you won't be able to build tcc... <stikonas>once we have coreutils and bash, life will be easier :) <stikonas>and maybe even eventually bootstrap to some source based distros like guix or gentoo... <fossy>yeah my first goal is void linux because 1. that's what i use 2. i know how to bootstrap it very well <fossy>we can launch off easily to other distros too <fossy>guix is a target too because of guile dep <Hagfish>so you could use mes to build void to build mes? and check that the hashes are the same? like turtles all the way down :) <fossy>stikonas: we need python late in the bootstrap anyway, glibc has a version too <stikonas>yeah, that's why I was thinking that gentoo shouldn't be too hard <stikonas>python can probably be compiled easily with gcc <fossy>the hard part is now, it's really easy once we get to gcc... <civodul>yeah it's great that they're spreading the word and showing how important it is <Hagfish>well done "foxboron" for submitting that <Hagfish>upvotes if you have them, friends :) <malina>stikonas, I think the bootstrapping is meant? to be more universal, so posix, not just gnu. and so on, trying t buikd too many coeutils,bash, and so on might make life easier but it should be for Gnu/Linux. This does have enough importance to also cover a broder set. <malina>and lol foxboron, ye, he sees himself as superior superrrace guy, haha. ironic I see his name in that, but since you ask, I will upvote <pder>./compile test/queens.hs && ./queens <stikonas>once you have build one thing you can easily build everything else <malina>had a small confrontation then he blurted out he thinks Norwegians were superior humans and I guess next thing would have been us waving nazi flags lol. <bauen1>arguably adding pipes (in some half-assed way at least) to a kernel that already has a vfs, a concept of processes and a concept of file descriptors <bauen1>is not too hard or code intensive <bauen1>but that does kind of depend on how "complete" pipes would need to be <fossy>bauen1: is myunix the latest iteration fo your project? <stikonas>but does bash require it? or can it run without pipes in the kernel (with reduced functionality) <fossy>stikonas: i believe it is required <bauen1>fossy: currently at the stage where it can run some simple userspace and has a syscall layer but still lacks the conecept of processes <fossy>hm... Mes C Library will have ability for pipes <fossy>but if we don't use them it's fine <stikonas>well, in principle once you have tcc you can build linux... <stikonas>the smaller bootstrap kernel is the better <bauen1>i would like to point out that having the initial kernel support enough i/o that you can run a minimal text editor is also somewhat important <fossy>yes if you're doing it manually <stikonas>if you are doing manually, stage0 monitor should be good enough :) <fossy>ya, someone here was looking at stage0 monitor in x86_64 efi <bauen1>stikonas: i could envision a scenario where you have a very minimal x86 mono-tasking kernel (maybe even without userspace seperation) written in assembly (or an alternative), that supports the very basics necessary to get to the point where you can build a more capable kernel, e.g. myunix and reboot <fossy>well that's basically my plan but use myunix or something similar as the bootstrap kernel for now <stikonas>but yeah, myunix would still be smaller than linux kernel <bauen1>i did think about just adding kernel module support to myunix, it wouldn't be terribly hard, so you could have the core written in a simpler C, so you boot with just a tmpfs, and start compiling until you can load the file systemd driver and what not <fossy>bauen1: while i wait for my toolchain to compile, maybe you can give me stome numbers; what is the size of the myunix kernel <bauen1>fossy: stikonas: it can be compiled using gnu binutils and tinycc, i'm pretty sure with a few patches to tinycc it could link the kernel too <bauen1>fossy: 776kb is the size of the kernel i have lying around, no idea how that was compile though <fossy>configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+. <bauen1>might be a lot of "dead space" too <fossy>should i just install those on hose <bauen1>i think you can pass gcc configure an option to have them build it in-tree if you really want to <bauen1>fossy: also make sure you're on the staging branch for more progress <bauen1>fossy: and if in doubt look at .gitlab-ci.yml <stikonas>fossy: I've just pushed udpate to PR, it finished building successfully now and no output <bauen1>but yeah, i didn't spend any time for half a year on this, already so many things i would do differently <bauen1>fossy: by the way, if you want to have nightmares, look at the Makefile code ;) it does allow you to build the entire toolchain, kernel and userspace in parallel where possiible ... <bauen1>huh looks like i don't actually have much changes left locally, so the most interesting parts should be up on git <bauen1>but yes, i think i'll rip out the last few commits and setup a seperate musl fork and use submodules <fossy>-Os: 127424 kernel/kernel.elf <bauen1>fossy: if you compile with tinycc the code will be a lot less optimal