IRC channel logs

2020-04-01.log

back to list of logs

<dddddd>Hello, fossy. Which gash are you talking about (repo/branch/commit)?
<dddddd>I cloned https://gitlab.com/janneke/gash
<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
<dddddd> 120 (lambda (port)
<dddddd>Is that it?
<fossy>hm no
<fossy>One second
<dddddd>^ https://git.savannah.nongnu.org/git/gash.git at f22bc5799606
<fossy>oh, line 119 oops
<fossy>that is what it is failing on
<dddddd>OK, what are you executing that fails?
<dddddd>I mean, anything?
<fossy>no script, should just drop to interactive shell
<fossy>running against guixs static ghile
<fossy>guile
<fossy>(on a non guix system)
<fossy>really, im wondering what part of that code dies,
<fossy>does
<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>hm.
<fossy>what does pair? mean
<fossy>this looks suspicously like a bug in kaem
<dddddd>Is a predicate that returns true if its argument is a pair
<fossy>ah
<dddddd>a pair being something like (x . y)
<fossy>Yep
<fossy>ok, thanks dddddd, I think I know where to go from here
<xentrac>:)
<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>just a bit!
<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>dddddd: OMG
<fossy>that was it!!!@
<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
<fossy>force pushes are possible
***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>that's great, OriansJ`
<Hagfish>so what does the bootstrap path look like now (and where are the gaps)?
<OriansJ`>Hagfish: exactly the same: https://github.com/oriansj/talk-notes/blob/master/Current%20bootstrap%20map.pdf
<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
<Hagfish>amazing work, everyone
<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>yeah, cool
<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>nice
<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)
<Hagfish>sure
<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)
<Hagfish>but a POSIX OS...
<Hagfish>i guess tccboot is somewhat similar
<OriansJ`>Hagfish: as in you build the POSIX on knight hardware and write to read-only media
<Hagfish>WORM
<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`>bauen1: not even close to a problem ^_^
<Hagfish>sounds great
<OriansJ`>M2-Planet integrates seemlessly with M1 macro assembly source files
<OriansJ`>(in fact generates M1 output itself)
<bauen1>nice
<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
<bauen1>not really written down
<Hagfish>ah well
<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>OriansJ`: https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html
<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.
<fossy>OriansJ`: ^-^ thanks