IRC channel logs

<fossy>AHH I JUST had an idea

<fossy>Dumb me was trying to kexec a I386 kernel from an x86_64 kernel

<xentrac>haha

<xentrac>you'd think there'd be a way to do that...

***mephista is now known as spicy_icecream

<stikonas>fossy: for now CI doesn't run reuse linter?

<fossy>stikonas: I add that next

<fossy>I will*

<stikonas>thanks. No rush!

<stikonas>just asked...

<OriansJ>vagrantc: The failure to build on kfreebsd would be resolved if you picked up 2eac6fae82e7be0c2b61490c046aa7e88017b5ae (or updated to master)

<gforce_d11977>stikonas: fossy: hopefully that works for you now: https://github.com/bittorf/live-bootstrap/commit/5aaa1d8efc2bc5315fd2d17b4aff28e21dece05f

<stikonas>gforce_d11977: maybe instead of grepping for two spaces " " just use http://en.wikipedia.org/wiki/Special:Search?go=Go&search=:space:

<stikonas>?

<stikonas>[:space:]

<stikonas>altbhough, it's a very minor comment...

<stikonas>in our file we'll have two spaces anyway

<gforce_d11977>stikonas: ok, added [[:space:]][[:space:]]

<stikonas>but do we need to spaces?

<stikonas>well, if you want, OK...

<stikonas>I was thinking that it's either " " or "\t" and http://en.wikipedia.org/wiki/Special:Search?go=Go&search=:space: would match both

<gforce_d11977>stikonas: as far as i read [[:blank:]] is "spacebar" and TAB... and [[:space:]] is only one keystroke on spacebar

<gforce_d11977>but using this special regex syntax has the advantage, that it is more implicit in sourcecode/better to read

<gforce_d11977> https://github.com/bittorf/live-bootstrap/commit/b6212493404a61b4713a3e307f44dd38997d431b

<pder> https://github.com/fosslinux/live-bootstrap/pull/34

<pder>I added a rebuild of coreutils against musl adding more utils needed for configure scripts

<xentrac>gforce_d11977: do you mean less implicit?

<stikonas>pder: nice! I'll take a look in the evening

<stikonas>although, one quick comment: pass2.mk needs license/copyright statement

<stikonas>so that reuse linter is happy

<xentrac> https://github.com/cksystemsteaching/selfie is an interesting bootstrapping system based on RISC-V written in this subset of C: https://github.com/cksystemsteaching/selfie/blob/master/semantics.md

<xentrac>mostly-subset

<xentrac>oh I guess https://github.com/cksystemsteaching/selfie/blob/master/grammar.md is a better page for the C* subset

<gforce_d11977>xentrac: maybe I use the wrong english term: wanted to say: when using '[[:space:]]' in sourcodes, this emphasizes the fact

<xentrac>gforce_d11977: I think that's more explicit, less implicit

<gforce_d11977>xentrac: thanks, you are right, i mixed it up - sorry

<xentrac>no worries, didn't mean to make you feel bad, just wanted to understand

<pder>I wonder if anyone here has any ideas about this strange bug. First here is the output: https://paste.debian.net/1184756/

<pder>I dont know if this is limited to tcc or musl or what. Piping the output of tcc -E file.c to cat truncates the output

<pder>But it only appears to do this with the musl version of tcc. tcc-mes works ok

<gforce_d11977>pder: are you using the chroot of 'live-bootsprap' or what is your setup?

<pder>Yes, this is with live-bootstrap, but the issue happens in and outside the chroot

<gforce_d11977>....ok?! strange

<gforce_d11977>xentrac: selfie is interesting, but it does not solve the problem of bootstrapping NOR compiling a c-compiler, or am I wrong?

<xentrac>well, it doesn't tackle the initial stages of bootstrapping in which you don't have a C* compiler

<xentrac>but it does tackle the problem of needing a kernel

<xentrac>the RISC-U machine it defines is maybe *too* minimal in the sense that it provides the ECALL system-call instruction, but not the SRET/MRET instruction to return from a system call, nor the page table stuff

<xentrac>puck: condolences on being K-lined

<xentrac>also it omits AUIPC so you can't do PIC except by bending over backwards

<xentrac>but of its 14 instructions the multiply and divide instructions are probably not really necessary, so you could probably cut it to 11, then add a couple back in. I need to study it

<gforce_d11977>sectorforth is a 16-bit x86 Forth that fits in a 512-byte boot sector: https://github.com/cesarblum/sectorforth

<gforce_d11977>but i have no clue, if thes makes any sense 8-)

<xentrac>it does make sense :)

<xentrac>I haven't tried reading sectorforth though

<gforce_d11977>also impressive: a BASIC including editor and debugger in 512 byte/runnable in qemu: https://github.com/nanochess/bootBASIC

<xentrac>sectorforth might be a more practical way of doing initial machine bringup than the three-instruction Forth or Óscar Toledo G.'s bootOS

<xentrac>but I think that even though, as Bernd Paysan points out in the 1996 thread, you *can* implement all your integer operations in terms of 0=, +, and NAND...

<xentrac>that probably isn't very practical

<xentrac>here's how Bernd defines 1:

<xentrac>: -1 ( x -- x 0 ) DUP DUP NAND DUP DUP NAND NAND ;

<xentrac>: 1 -1 DUP + DUP NAND ;

<xentrac>so you'd probably end up writing machine-specific assembly pretty quickly with sectorforth's 8-instruction Forth, just as with the three-instruction Forth (where that's the whole point)

<fossy>stikonas: it was on my todo list anyay :)

<xentrac>my own attempt to do a minimal interactive Forth was about three times larger: https://github.com/kragen/tokthr

<xentrac>and actually usable Forths seem to start around 4K

IRC channel logs

2021-02-09.log