IRC channel logs

2021-04-15.log

back to list of logs

<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>1
<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 :)
<fossy>true
<stikonas>I'll soon have a better way to bootstrap tar
<stikonas>which also simplifies sysa.py a bit
<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>stikonas: -ltcc1?
<fossy>you might need to specify the .a itself as you would a .o
<stikonas>neither -ltcc1 nor specifying .a file worked...
<stikonas>strangely...
<fossy>odd
<stikonas>yeah...
<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.
<xentrac>OriansJ`++
<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
<xentrac>still don't actually — where is it?
<xentrac>or is it not public yet?
<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
<OriansJ`>xentrac: and no it is not public yet
<xentrac>oh, that's why I don't see it then
<xentrac>for CP/M on 8080?
<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
<OriansJ`>so stage0-DOS
<xentrac>but hey, I'm not the one writing the code :)
<xentrac>yeah, stage0-DOS
<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?)
<xentrac>how's your kid doing these days?
<xentrac>the human one, I mean, not stage0
<OriansJ`>xentrac: he loves books and getting into trouble and moving objects 3 times his body weight when we are not looking.
<xentrac>how many books has he eaten?
<OriansJ`>and he is in the 99th percentile for height and weight
<xentrac>you married a giantess?
<OriansJ`>sure why not
<xentrac>often desired, rarely achieved
<OriansJ`>he prefers to turn the pages and hear us read
<xentrac>aww, that's wonderful
<OriansJ`>and while he sleeps I manage to make slight progress on my work.
<OriansJ`>speaking of which xentrac: https://github.com/oriansj/mes-m2 we have an M2-Planet buildable mes-m2 that can run mescc
<OriansJ`>and I am currently trying to get it into shape where GCC can build it (properly) https://github.com/oriansj/mes-m2/tree/GCC
<OriansJ`>the good news is with very few changes GCC can now once again build mes-m2; unfortunately it segfaults quick
<Hagfish>well that's something at least :)
<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.
<Hagfish>love it
<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
<xentrac>OriansJ`: that's wonderful news!
<OriansJ`>xentrac: live-bootstrap now has no generated files from hex0 to GCC-4.9.4 (they bootstrapped bison and flex along the way)
<xentrac>congratulatiosn :)
<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.
<xentrac>yaay!
***Server sets mode: +cnt
<fossy> /go 47
<fossy>oops
<bauen1>etbe: /18
<bauen1>sorry
<gforce_de1977>fossy: stikonas: another day, another PR: bash-5.1-fix: https://github.com/fosslinux/live-bootstrap/pull/104
<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>512 will never be good for us...
<stikonas>it will always cause hash mismatch
<stikonas>extra sleep 3 might help to make it less frequent, but I guess it's still a race
<fossy>agreed with stikonas
<fossy>also really 50%? That's a lot
<fossy>i haven't ever run into this
<stikonas>it's not 50% here..
<fossy>it could be kernel thing
<stikonas>could be...
<stikonas>fossy: by the way, I know what caused libtcc1.a to fail
<fossy>yeah?
<stikonas>it was built with very first tcc
<stikonas>mes-tcc
<stikonas>I'll have a fix later in my PR
<stikonas>but want to finish more things in the evening
<fossy>huh really
<fossy>i thought we rebuilt libtcc1.a
<stikonas>you only rebuild .a in each stage of tcc from old .o
<fossy>ah, right
<fossy>i see
<stikonas>when I added rebuild .c to .o it helped
<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>sure
<fossy>also i don't think that gforce_de1977's 3.18 minikernel is a bad target, the opposite tbh
<stikonas>that's true
<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?
<gforce_de1977>ok: i will change the PR to output a fixed #define
<stikonas>basically 's/512/whatver value we want/'
<gforce_de1977>fossy: stikonas: ok, i'am not happy, but maybe it's ok for you: https://github.com/fosslinux/live-bootstrap/pull/104/commits/73b8319d2527ed0bd774851124e2d2daf01d8600
<gforce_de1977>sorry, mistake
<fossy>perhaps better as .patch?
<gforce_de1977> https://github.com/fosslinux/live-bootstrap/pull/104/commits/54b28e3a8db6eb3f7d8dc2d1f357039d267ec3e4
<gforce_de1977>ok, a patchfile is better, you are right
<gforce_de1977>here with a patchfile: https://github.com/fosslinux/live-bootstrap/pull/104/commits/6163f2a51ac702cedb19d054ae89c3031623826e
<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:
<gforce_de1977># SPDX-FileCopyrightText: 2021 Bastian Bittorf <bb@npl.de>
<gforce_de1977>and
<gforce_de1977>SPDX-FileCopyrightText: 2021 Bastian Bittorf <bb@npl.de>
<stikonas>Also needs SPDX-License-Identifier:
<gforce_de1977>aaaah! got it
<stikonas>SPDX-License-Identifier: GPL-3.0-or-later
<stikonas>(that's license of bash, so let's keep patch the same)
<gforce_de1977>ok, have done it, thank you
<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