IRC channel logs

2022-12-21.log

back to list of logs

<oriansj>stikonas: well that was written back when foo[4][5] wouldn't give you the correct answer and bar[3][4] = 'x' would set the wrong bit of memory
<oriansj>So that feature isn't generally used but it does look you did do some testing on it back in November so it is porbably functional
<oriansj>^porbably^probably^
<stikonas>oh, you think it's this recent change, maybe...
<stikonas>well, at some point when I have more time I can test
<stikonas>now I'm getting slowed down in my UEFI work cause I always think that some general improvement in M2-Planet or M2libc would make code nicer...
<stikonas>which is probably good longer term...
<stikonas>a couple of things I have in mind is: 1. getenv function. 2. implement C operator precedence for * / %, + -, << >> operators
<oriansj>stikonas: operator precedence is already there
<stikonas>oriansj: oh but stuff like 2 + 3 * 6 doesnt work, it returns 30
<stikonas>it first adds 2 + 3 to get 5 and then multiplies by 6
<stikonas>it might be that we just need to reorder it a bit
<stikonas>in additive_expr_stub
<stikonas>hmm, no, that's not sufficient
<stikonas>oh, maybe it's not that easy without backtracking...
<stikonas>oh well, it's not a huge deal
<stikonas>getenv should be easy one though
<stikonas>we just need to make sure that envp is store in global variable
<stikonas>oriansj: anyway, maybe let's merge one of my commits that I created for uefi env variables
<oriansj>stikonas: eventually it just gets to the point where one just needs to do a major rewrite of M2-Planet and at that point you might as well call it M3
<stikonas>that's true, which is why after thinking a bit, I decided against 2.
<stikonas>oriansj: https://github.com/oriansj/M2libc/pull/31
<stikonas>perhaps not the most efficient implementation as it basically reads all variables twice
<stikonas>(one to get the number of them, then allocates enough memory for envp and then reads all variables again, this time writing into envp)
<oriansj>merged
<stikonas>thanks
<rickmasters>Fiwix can now build all packages up to Linux and all known intermittent failures/bugs have been fixed!
<rickmasters>Last steps remaining to complete kernel bootstrap are: build Fiwix in live-bootstrap with tcc, launch Fiwix with builder-hex0, launch Linux from Fiwix.
<stikonas[m]>Another huge progress update!
<stikonas[m]>rickmasters: for 1. I guess you need to write kaem file?
<rickmasters>Yeah, I got musl-1.2.3 and curl to build.
<stikonas[m]>Since you said make is not working
<stikonas[m]>Launching new kernels is probably a harder task...
<stikonas[m]>Need to implement something like kexec?
<rickmasters>stickonas[m], yes I'll need to repackage tcc-0.9.27 as tar.gz and build it sooner and write a kaem script to build Fiwix
<rickmasters>stikonas[m]: yes, kexec
<rickmasters>For builder-hex0 I could probably just write a program in C to launch fiwix since there is no memory protection.
<rickmasters>For kexec with Fiwix, there is no /proc/mem or /proc/core so I'll have to do something different than standard kexec
<stikonas[m]>OK, that's not too bad
<stikonas[m]>I was more scared of the first transition
<stikonas[m]>As it is really early and we have almost no tools
<rickmasters>Well, the scary part I haven't mentioned is that I need to create and populate an ext2 file system from user land to boot Fiwix.
<rickmasters>I'm looking at this package: https://github.com/gkostka/lwext4
<stikonas[m]>Oh yes, that is also tricky...
<stikonas[m]>Can we not teach fiwix to read something else instead?
<oriansj>rickmasters: could we just write to new disks the output rather having to do kexec?
<oriansj>(but I trust you know best here)
<rickmasters>oriansj: I'm not sure exactly what you mean. Use non-bootstrapped tools to create the ext2 file system?
<stikonas[m]>I think he only meant reboot instead of kexec
<oriansj>rickmasters: I was actually thinking of builder-hex0 creating a Fiwix disk image and then just shutting down and requiring the user to power on the Fiwix disk image
<oriansj>(if that would make things simpler for you)
<rickmasters>oriansj: I think the kexec part is not too hard really. Probably a lot easier than preparing the disk.
<stikonas[m]>Still, it looks like kexec in builder-hex0 can be done in user land
<stikonas[m]>rickmasters: can't we add e.g. tar support instead of ext2?
<rickmasters>I've looked at the source for Qemu which can boot Fiwix and it's not too bad.
<stikonas[m]>Well, in the end we only need to implement a subset of ext2...
<oriansj>well looking at the lwext4; it appears something easily convertable to M2-Planet's C subset
<oriansj>and it definitely looks like something TCC can build without changes
<stikonas[m]>oriansj, rickmasters: we would have to link gplv2 only code with gplv3 or later
<stikonas[m]>(I think, let me double check)
<stikonas[m]>Oh it's gplv2+, do it's fine
<rickmasters>Wish I could chat more, but I'm off to a christmas party.
<oriansj>So build TCC on builder-hex0; have it build lwext4; which then makes the partition for Fiwix; which then TCC builds, we populate it with everything and then switch over to Fiwix
<oriansj>rickmasters: Have an amazing time ^_^
<rickmasters>oriansj: thanks, and yes, you've got the steps right
<rickmasters>oriansj: I'll also consider alternatives like a simpler file system that Fiwix converts to ext2 on the fly, but its not really designed to do lots of file system work directly from the kernel
<rickmasters>Its all based on syscalls and expects an active process everywhere
<rickmasters>But anyway, gotta go, talk to you guys later
<fossy>stikonas[m]: i never really figured out why that's the case lol
<fossy>rickmasters: that is very exciting!
<fossy>are your changes/patches pushed everywhere?
<fossy>anywhere*
<fossy>BTW, does anyone know, how the hell to escape CFLAGS passed to a configure that includes a -D with spaces? (in this case -D__DATE__=Jan 1 1970) (no i cannot -U__DATE__, it must be set to something)
<fossy>i have tried at least a dozen different escaping combinations that _seem_ like they should work but don't -.-
<AwesomeAdam54321>fossy: Does it work without escaping? The #:configure-flags only accepts a list of strings and not one long one probably so that a string can have spaces without issues
<fossy>no, make passes -D__DATE__=Jan 1 1970 with spaces, so the compiler borks cause 1 and 1970 are separate arguments
<fossy>hmm i passed it to make instead of configure as a make variable and that worked. not complaining
<fossy>technically not a good idea but oh well
<pder>Hi all, I recently ported a bz2 decompression utility similar to ungz in mescc-tools-extra so it builds with M2-Planet. https://github.com/pder/mescc-tools-extra/tree/unbz2
<pder>I used the latest M2-Planet in order to build properly (commit 286964d5f81ee7393)
<fossy>neat! pull request it :D
<pder>I think I will do a draft pull request soon, just needs a little testing. Hoping this might be useful for the kernel bootstrap
<fossy>at minimum, it will make tarballs smaller, which means less ram
<Irvise_>Welp, the Ol Lisp/Scheme creator really took bootstrapping to heart. He has started documenting the VM binary format and a Scheme->binary compiler that he hopes to make portable to other Schemes.
<fossy>/ # python
<fossy>Python 3.11.1 (main, xxx xx xxxx, xx:xx:xx) [GCC 4.7.4] on linux
<fossy>:DDD nearly there, just need to check for reproducibility
<fossy>8 versions from start to end
<fossy>it's really interesting to see how generated code increased, probably from about 200 loc in python 2.0 -> 10-20k in most recent version?
<stikonas[m]>pder: oh and that might save rickmasters tgd need to repackage tcc 0.9.27
<stikonas[m]>fossy: oh nice!
<stikonas[m]>pder: by the way, you can use stuff like i += 1 in unbz2.c
<oriansj>nice work pder, I think that will be helpful ^_^
<oriansj>Irvise_: Nice to hear good news like that.
<oriansj>fossy: oh dear, practicially a big ol blob of generated values. (Seriously do interpreted language tend to accumulate those or what) but glad you got that handled for us ^_^
<stikonas[m]>Yes, 10-20k loc is a lot...
<stikonas[m]>oriansj: compiled languages are usually worse, the whole thing is often written in itself
<oriansj>stikonas[m]: granted, they usually require you to solve the bootstrap the language problem but they don't usually add in a few kloc of "generated code"; which unlike things like psyntax.pp which that entire chain is lost very quickly and most people completely missed it.
<stikonas[m]>Yes, I guess it's easier for generated code to hide in interpreted languages
<oriansj>also interpreted languages rarely are written in themselves; so the temptation to use a feature of that interpreted language in its implementation results in that sort of behavior