<fossy><bauen1> also regarding the spdx copyright headers, how many line changes constitues a change that would need me to add my own name with SPDX-FileCopyrightText: ? <fossy>any change is sufficient. spdx is not "who has done the most work", you can see that in git, its just a total sum of all licensing info <xentrac>there do exist uncopyrightable lines of code :) <stikonas>I'll soon have a better way to bootstrap tar <stikonas>fossy: do you remember how to use libtcc1.a? <stikonas>somehow I can't build stuff with it, but using libtcc1.o works <fossy>you might need to specify the .a itself as you would a .o <stikonas>neither -ltcc1 nor specifying .a file worked... <stikonas>well, maybe I'll just specify libtcc1.o from old build dir <OriansJ`>gef: we don't pick winners before the race. What ever architecture attracts enough developers and resources to complete first wins. Personally I am betting on knight because it is fun to program (so much so that all of the steps to M2-Planet are already done on bare-metal. I just need to provide FPGA and gate-level designs to enable others to make their own hardware. <OriansJ`>right now x86 has the most active developers and the fewest pieces remaining. <vagrantc>a remarkable correlation to widely available hardware, perhaps :) <xentrac>it would be awesome to see a Verilog Knight :) <xentrac>what do you enjoy most about programming it? <xentrac>aside from, obviously, not slicing your immediate operands into apparently random chunks of bits that are then placed in apparently random places in the instruction word, as in RISC-V ;) <OriansJ`>xentrac: It was going to be my next project after I get mes-m2 gets ported to M2libc but it got bumped for stage0-cpm work to make the x86 bare-metal bootstrap even closer. <xentrac>oh interesting, I hadn't seen stage0-cpm <OriansJ`>xentrac: as for what I like the most about knight's ISA is how everything does exactly what you expect without having to guess. No side-effects or implicit registers <xentrac>there's a lot more CP/M hardware out there than Knight, but nobody ever said 8080 was a pleasant instruction set <OriansJ`>xentrac: I was thinking CP/M for 8086 as it would only require me to replace the syscalls and be done. <xentrac>for 8086 I'd think FreeDOS would be a better choice than CP/Mish <xentrac>but hey, I'm not the one writing the code :) <xentrac>just thinking you'd probably spend less time debugging FreeDOS than debugging CP/Mish <OriansJ`>xentrac: I'll look into it when I get the free time for it ^_^ <xentrac>(I don't think CP/Mish has even been ported to the 8086, has it?) <OriansJ`>xentrac: he loves books and getting into trouble and moving objects 3 times his body weight when we are not looking. <OriansJ`>and he is in the 99th percentile for height and weight <OriansJ`>he prefers to turn the pages and hear us read <OriansJ`>and while he sleeps I manage to make slight progress on my work. <OriansJ`>the good news is with very few changes GCC can now once again build mes-m2; unfortunately it segfaults quick <OriansJ`>now just to figure out what exactly is causing the segfault and fixing it <OriansJ`>because once that is done, the transistion to M2libc and porting to AArch64, armv7l and knight will be rather easy <Hagfish>will the porting to each of those arches be the same amount of work as each other? <OriansJ`>Hagfish: once we get the posix primitives into M2libc, then the ports become instant. <OriansJ`>I just need to get the GCC build of mes-m2 to stop segfaulting and run mescc <Hagfish>yeah, it's a bit weird that it's segfaulting <Hagfish>i'm not sure what sort of techniques can prevent code from segfaulting on gcc (but working under other compilers?) <OriansJ`>It is probably something stupid I did and I haven't realized it yet. I'm hoping janneke will take a look and point out the obvious <Hagfish>i guess there aren't any relevant warnings that gcc produces during compilation <OriansJ`>Hagfish: well there are warnings that I haven't fixed yet <OriansJ`>(I only had so many hours of effort available thus far) <Hagfish>ah, okay, so there might be a trail of clues left to follow <OriansJ`>90% of the changes are just changing fdputs to fputs and fdputc to fputc <Hagfish>i guess that means doing a find and replace, rather than trying to override/redefine them <OriansJ`>So it should be a priority task for anyone to wants mes-m2 to run on architectures other than just x86 <OriansJ`>xentrac: live-bootstrap now has no generated files from hex0 to GCC-4.9.4 (they bootstrapped bison and flex along the way) <OriansJ`>janneke did the finishing piece by getting mes.c into a form that M2-Planet could build (after I abandoned it) and able to run MesCC; so that path ultimately won. <OriansJ`>now I am just trying to get it into a form that I can port to the other architectures and maintain long-term. <OriansJ`>but I know I'm not that great at debugging mes.c (as evidenced by my months of failing to port mes.c to M2-Planet) <OriansJ`>so this is going to just be an exercise in frustration until I get the GCC branch operational and hence why I put out a plea for help sorting out the last few segfaults in the GCC branch of mes-m2. ***Server sets mode: +cnt
<stikonas>gforce_de1977: I want to think a bit more about the fix... It might be better to just replace 512 with 64K in builtins/psize.sh <stikonas>extra sleep 3 might help to make it less frequent, but I guess it's still a race <fossy>also really 50%? That's a lot <fossy>i haven't ever run into this <stikonas>fossy: by the way, I know what caused libtcc1.a to fail <stikonas>but want to finish more things in the evening <fossy>i thought we rebuilt libtcc1.a <stikonas>you only rebuild .a in each stage of tcc from old .o <gforce_de1977>fossy: about 160 builds from 312 are failing because of this, i can reproduce it <fossy>gforce_de1977: using another kernel? <stikonas>well, in principle it's good that there is a way to make rare intermittent issues more frequent <fossy>also i don't think that gforce_de1977's 3.18 minikernel is a bad target, the opposite tbh <gforce_de1977>i can try another kernel, will make a new mass-run this night with kernel 5.11.14 and report <stikonas>but maybe adjust your PR to edit psize.sh? <stikonas>basically 's/512/whatver value we want/' <gforce_de1977>so the patch is a oneliner: printf '%s\n' '#define PIPESIZE 65536' <stikonas>gforce_de1977: you need to add a license to patch file <gforce_de1977>fossy: i dont understand, we the reuse-linter fails, do you? i tried: <stikonas>SPDX-License-Identifier: GPL-3.0-or-later <stikonas>(that's license of bash, so let's keep patch the same) <stikonas>that's what linter was picking up, second # SPDX-FileCopyrightText: 2021 Bastian Bittorf is not visible to linter, although, if you want you can keep it ***sm2n_ is now known as sm2n