<dddddd>Hello, fossy. Which gash are you talking about (repo/branch/commit)? <dddddd>The most recent commit fc1b2fac0bdd doesn't have gash/gash.scm (and also fails to ./configure after ./autogen.sh --> configure: error: Gash is missing; please install it.) <dddddd>master seems quite old, but has that file with 120 being `(with-readline-completion-function completion thunk)` <fossy>dddddd: I am talking about the Savannah gash, tip of master <fossy>that is what it is failing on <dddddd>OK, what are you executing that fails? <fossy>no script, should just drop to interactive shell <fossy>running against guixs static ghile <fossy>really, im wondering what part of that code dies, <fossy>and what it could be trying to open that dosent exist <fossy>because it is trying to open "" I guess it will be something to so with the environment that I havent set <fossy>oh, I am using --init-mode with kaem <dddddd>I guess it's a problem with the arguments. <dddddd>(pair? files) is true, so something is there <dddddd>Because, IFAIU, files is '() by default, and (pair? '()) is false. <fossy>this looks suspicously like a bug in kaem <dddddd>Is a predicate that returns true if its argument is a pair <dddddd>a pair being something like (x . y) <fossy>ok, thanks dddddd, I think I know where to go from here <dddddd>That part of the code tries to open the file in the car of the pair, which I guess it should be a script filename <fossy>janneke: which is the "correct" gash? your one in gitlab, or Savannah? <dddddd>Glad to help, fossy. Take all with a grain of salt... This is the first time I look that code. <fossy>Well same, but Im sure you know more scheme than me <dddddd>hmm, I'm not sure if this is the actual problem, fossy, but trailing spaces in a line of the script (kaem.run for example) is considered an arg (as in argc of the called program is 2 instead of 1). <fossy>yeah, im going to make kaem not do that <dddddd>great! this is both in master and gash-smallscript (so not introduced in the new branch) <fossy>I did test with master just to make sure <fossy>please note gash-smallscript is a WIP ***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado
<janneke>fossy: savannah is the canonical, correct gash <janneke>both samplet and myself may push some hacking @gitlab; the whole gash-geesh merger and the utils split-off lived there ***DKordic is now known as S-Jack
<OriansJ`>fossy: I finally finished reviewing and I'll be making kaem a submodule of mescc-tools shortly. Just making a few minor changes to keep the workflow consistent with mescc-tools ***edef is now known as edeg
***edeg is now known as edf0
***edf0 is now known as edef
<OriansJ`>fossy: kaem is now a submodule of mescc-tools with integration into the standard "make clean test" build cycle <OriansJ`>test13 was incomplete so I provided an approximate solution which is close to what bash does. <Hagfish>so what does the bootstrap path look like now (and where are the gaps)? <OriansJ`>dddddd is currently finishing slow-utils (but it is good enough to release today if I remember correctly) <OriansJ`>janneke will be pulling out the mes.c binary and mescc-tools from guix; so that there will only be the guile (static binary) in the guix bootstrap. Then the only remaining piece is mes-m2; once completed will slot right where guile is and the entire bootstrap (on top of a POSIX) is done. <OriansJ`>Then bauen1 will be finishing their POSIX, we will convert it to be buildable via M2-Planet; thus reducing the trust only to the hardware and from there it is all metal level work <OriansJ`>We will still have to find someone to do i686&/AMD64 in FPGA and then a bunch of libresilicon work which will be really fun. <Hagfish>will the POSIX have to be compiled on a trusted machine (or use something like DDC), or is there some way to check that it matches the source? <OriansJ`>Hagfish: if something can be built via M2-Planet, we can do the build on bare metal <Hagfish>is that still an open research question, or are there examples of things like that? <OriansJ`>and the bare metal will be something that I'll ensure everyone will be able to verify (via FPGA or Libresilicon or TTL) <OriansJ`>Hagfish: if you look at stage0, you'll see all of the steps from hex0 to M2-Planet on bare-metal (simulated in software of course) <OriansJ`>Hagfish: as in you build the POSIX on knight hardware and write to read-only media <OriansJ`>or floppy disks with the WRITE tag set to off <Hagfish>yeah, assuming you trust the disk controller to honour that <Hagfish>some sort of serial connection could work too, i guess <Hagfish>i guess i'm just not sure of the relative difficulty of building something like m2-planet and building something like a POSIX OS <Hagfish>isn't that the hard part of bootstrapping :P <OriansJ`>figuring everything out? I find that the fun part <OriansJ`>well the difficulty of building something like M2-Planet is just having a C compiler as powerful as cc_x86.s; which honestly is a simple program to write in assembly. Having a POSIX OS buildable via M2-Planet is just an incremental process of removing non-standard C constructs until M2-Planet is able to build everything; as we have a great deal of support for inline assembly in M2-Planet <bauen1>OriansJ`: the amount of inline assembly in my kernel is quite minimal (and can probably be removed completely) <bauen1>there are however ~200 loc that require an assembler <OriansJ`>M2-Planet integrates seemlessly with M1 macro assembly source files <Hagfish>bauen1: do you have a checklist of things that still need to be done on it? <OriansJ`>So it just becomes the trivial task of converting from your preferred assembly to M1 and that shouldn't take very long at all <Hagfish>i personally find checklists very satisfying :) <bauen1>currently working on setting up user code with a seperate page directory, after that is elf loading and then implementing syscalls <Hagfish>i have a vague idea of those things :) <bauen1>does M2 support '__attribute(section("...")))' ? <OriansJ`>bauen1: no but I'd have to know what that even means in terms of assembly code before I could add it. <bauen1>basically emit the data into a seperate elf section <bauen1>which i currently use to know what data needs to be mapped into user space <OriansJ`>for that I'd need to figure out how to get M1 to generate seperate elf-sections for hex2 <bauen1>i guess it's just a convenience, i just needed a way to have a page aligned start and end address with everything important (and nothing else) inbetween <OriansJ`>bauen1: we can also hide those details inside of a function in a seperate .c source file and do something different for M2-Planet <OriansJ`>but that is just the sort of things we will have to engineer a proper solution to in the long run. <OriansJ`>as I can keep adding features and functionality to M2-Planet+mescc-tools pretty easily <OriansJ`>but generally if we take the time to make everything as simple and clear as possible; such things generally are not needed.