<OriansJ>yt_: sometimes all the time we have is 15minutes a day but after 4 years it all makes a meaningful difference. <OriansJ>but given the choice of slow progress or no progress. I'd rather live in a better world in 20 years than never. <yt_>OriansJ: you have more patience than I can claim for myself :-) <yt_>janneke: I've started turning my half-finished aarch64 port of mes/mescc into some small-ish patches, which I'm currently hosting here: https://github.com/snnw/mes/tree/wip-aarch64 how do you prefer this stuff to be upstreamed into mes? if you're willing to take the patches, that is <xentrac>OriansJ: interesting, sapphire gate oxide sounds pretty great <xentrac>03:06 < remexre> (which involves M4, so I haven't dug into it...) <xentrac>m4 is one of those things that is very powerful and versatile but just too error-prone to be really practical <stikonas>but at least m4 is really easy to bootstrap :) <xentrac>yeah. actually do you know about ratfor? <xentrac>Kernighan and Plauger published a book in 1976 <xentrac>they'd been using Unix as a daily driver since 1971, and they knew that it had a bunch of advances over the state of the art in terms of whipupitude, manipulexity, and just what you could do at all on a 16-bit machine <stikonas>hmm, I thought I haven't heard about ratfor, but somehow my browser history remembers better... <xentrac>they were doing stuff on their PDP-11 that normally required a large system like the 36-bit GE-365 and GE-645 mainframes <xentrac>using what they called a "software tools" approach, later summarized as "tiny tools, loosely coupled" <xentrac>and they thought it would be cool if more people could use this approach, but their tools were written in a weird language called "C" Dennis Ritchie had written in 01972-3 which at that point only ran on the PDP-11 and only under Unix <xentrac>so they decided to write a book presenting this approach in an understandable manner that people could use on their own machines <xentrac>the popular programming languages at that point were COBOL, BASIC, FORTRAN 66, and PL/I. LISP was a kind of ivory-tower thing most people couldn't use in practice and it was too slow anyway <xentrac>PL/I was an IBM thing, although Burroughs had a PL/I, and at Bell Labs they'd written their own "Early PL/I" as part of the Multics project <xentrac>but even a lot of IBM systems didn't support PL/I <xentrac>so that left COBOL and FORTRAN 66, neither of which was an acceptable choice <xentrac>(I'm reconstructing this; I haven't talked to anybody involved about it) <xentrac>so they wrote the Software Tools book in RATFOR, which was a simple macro processor that added things like compound statements and, IIRC, strings <xentrac>in Software Tools they presented, among other things, grep, ed, uniq, and RATFOR itself <xentrac>and, in one of the last chapters, m4 <xentrac>although I think they didn't use that name for it, and in all cases the version presented was fairly minimal <xentrac>that was the 1976 book, though they'd published an article in SPE in 1975, and I think they were using RATFOR for other things as well from 1974 <xentrac>so they were trying to solve, fairly precisely, the problem of bootstrapping an m4 implementation without having a working Unix system, or even C <xentrac>hopefully that clarifies why I thought this was relevant :) <xentrac>ah, I was mistaken about the strings; Ratfor doesn't add strings to FORTRAN <xentrac>(it does, however, add quoted strings, which it converts to standard Hollerith strings) <stikonas>argh, need one more iteration before I can push my coreutils PR... <stikonas>coreutils actually worked, but grep build script after that had a typo... <stikonas>fossy: I've pushed update to coreutils PR <pabs3>does bootstrappable participate in the outreach programs like GSoC & Outreachy? (it is getting close to that time of year) <fossy>we aren't an organization, so there's no easy way to do that <fossy>i beleive Guix does though and I think they have hosted bootstrapping related GSoC projects in the pased <pabs3>ah. just noticed repro builds are now discussing what they plan to do. they are part of Conservancy for the org bit <vagrantc>hrm. more mescc-tools locale related test suite errors: + '[' 'test/test8/proof: goed' = 'test/test8/proof: OK' ']' <vagrantc>i'm guessing goed ~= OK in whatever localte that was <vagrantc>this time through trickery of the LANGUAGE environment variable... apparently? ***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado
<stikonas>fossy: have you seen my message regarding src dirs? <stikonas>fossy: well, I was asking do we really need those empty sysa/*/src/ dirs? <stikonas>instead of creating them in either rootfs <stikonas>well, either rootfs.sh mkdir and copy from /sources/ or 2) skip /sources/ and just wget everything into the right place in get_file <fossy>stikonas: we could create them in rootfs.sh <fossy>i think maybe just skip /sources is the best option <stikonas>although, in that case we need to adjust .gitignore <OriansJ>LANGUAGE=nl_BE:nl just breaks a bunch of tests <OriansJ>it even breaks M2-Planet, mes-m2 and stage0 tests <OriansJ>but export LANGUAGE=C fixes it right up <OriansJ>just need to add that variable to EVERY SINGLE TEST <OriansJ>unless someone has a smarter idea which requires me to do less work? <deesix>OriansJ, tests of M2-Planet are not affected by locale. I don't see it breaking due to LANGUAGE. What do you see breaking? There's the sha256.sh script taking care of that. <deesix>gforce_de1977, that's not M2-Planet. <malina>goed moet bent in de Nederlandse of Belgische taal, dat is , vrieser of vlaamser , denk ik. <deesix>So, mescc-tools also has the script to call with LANG=C, but it seems it's not really working. One interesting thing in the log is that it's set on a different line, not with the call. <deesix>++ sha256sum -c test/test8/proof.answer <deesix>In the script there's LANG=C sha256sum -c "$1" <gforce_de1977>deesix: thats it! on another line it can only work with export VAR=foo <deesix>Yeah, but why two lines when the original is just one? <deesix>There's no weird chat between the assigment and the command. If this is the shell, half of the world would break. <deesix>OriansJ, in my 'TMP' branch of M2-Planet you can find three commits completing this round of the M2libc switch, on per supported arch. Let me know if you're OK with them. We're not using M2libc/bootstrappable.h yet and test1000 is also out of this round. <deesix>OriansJ, the manpage talks about some files that I guess we're about to deprecate (and then remove). <stikonas>fossy: did you have some problems with externs and tcc? <fossy>Variable externs a broken, need to redeclare in some places <stikonas>although, maybe first a small patch adding more coreutils <yt_>deesix: it's great to see the progress you're making on the test suite! <pder>stikonas: ive been working on getting ls working in coreutils. Will need to patch mes-libc because qsort is broken <fossy>pder: hm, you'll need to recompile mes libc in that case <fossy>We have no form for patching at the time mes libc is compiled <stikonas>but yeah, ls is one of the biggest missing pieces in coreutils... <pder>Yeah, I mean lib/stdlib/qsort.c needs a fix that should go upstream <stikonas>on some other news, I still can't get yacc to build lex :( <stikonas>maybe I'll push yacc out and somebody else can try to review/fix... <pder>Also had to change a call to strcoll to strcmp <pder>Started looking at perl, but perl wanted ls and awk <stikonas>pder: but that's if you use Configure script? <pder>Yes, that was all I tried <deesix>yt_, glad you like it; on the bumpy road to unification, then party :) <xentrac>heirloom-awk presumably will work with heirloom-yacc <stikonas>well, if we can get heirloom-lex, then we can go all the way to bison/flex and bash/awk, so we don't really need heirloom-awk <stikonas>anyway, I've tried to use proper defines instead of CFLAG defines for wide string functions->string functions and I don't think it makes any difference... still the same behaviour <yt_>ccccccljuvvbvjelbfhvivtfifhtuhibtfduegbgrnjg <deesix>yt_, I looked at it briefly. Catched my eye the infamous EI_OSABI (new ELF files use 03 because some BSD), but I don't know how relevant is for mes right now. <deesix>That line and the next one give me nightmares :P <yt_>deesix: I don't think mes supports any of the BSDs? but if you want to make a PR to fix the ELF headers I'll bring it along <yt_>and if you want to give it a spin and let me know how far it gets for you, that'd be super helpful too <OriansJ>deesix: starting to review the commits shortly <OriansJ>yt_: mes previosly had some BSD work done but it looks it was never carried to completion. <deesix>OriansJ, was it some porting or just trying to run something under linux emulation? <OriansJ>deesix: I think it was Linux emulation under netBSD <OriansJ>as I don't believe any attempts were made to support *BSD syscalls natively as they don't usually have ABI <deesix>yt_, I'm not familiar with mes at all. I guess it's a good way to start looking at it. I'll try it one of these days (weekend, I guess). <stikonas>fossy, pder: ok, I've also got mknod working <yt_>deesix: nice, I should be around