IRC channel logs

<ullbeking>OriansJ: there should be some cheaper ones coming on the market soon-ish, i think

<stikonas>fossy: I mostly have gzip (was testing on my normal system for now). Mostly works but for now I need to pre-patch one file

<stikonas>(or alternatively patch needs to be bootstrapped)...

<yt_>janneke: global array works https://paste.debian.net/1180392/

<yt_>code is here until I get a chance to clean it up and make a PR https://github.com/snnw/M2-Planet/commit/2af46c1efc413f70dabb4d607ba14893b20385a5

<yt_>janneke: I had to adapt your test case a bit because it only compiles in --bootstrap-mode, while this feature is going into non-bootstrap mode

<yt_>if you want to test it as is though, you can disable the bootstrap_error check in the M2-Planet source

<ullbeking>currently tending to household chores, biab

<yt_>and that's it from me for today, good night!

<OriansJ>ullbeking: having to deal with my overly active 10 Month old son here; really slows down development some days

<OriansJ>but life work living never comes easy.

<ullbeking>goodnight yt_ !

<ullbeking>OriansJ: where are you located?

<OriansJ>ullbeking: Michigan

<OriansJ>you?

<ullbeking>London, UK

<ullbeking>I remember Michigan fondly because I saw the most beautiful sunset of my life there

<OriansJ>ullbeking: The UK is where I met a musician who wrote a song for me and included in their album

<ullbeking>OriansJ: whoa!! is it online? which musician?

<ullbeking>i love music

<OriansJ>let me look

<OriansJ>yep: https://www.youtube.com/watch?v=6tfId0RTTng

<stikonas>fossy: is your tcc configured to find crt1.o, etc or do I need to pass some command line args to it?

<OriansJ>ullbeking: I was the drunk guy in the song and dealing with the death of my fiance in a car crash; while burying myself in contract work and drinking.

<stikonas>ok, sed and gzip are now done

<OriansJ>yt_: I updated mescc-tools-seed; could you update the AArch64 arch when you get a chance.

<fossy>stikonas: yes it'c ofnigured to find crt*

<fossy>lol when recompiling the libc i ran into an issue with too many objects

<fossy>so i had to create some unified source files lmao

<fossy>stikonas: how much patching needs to be done? is it possibel to be done using a simple search and replace?

<fossy>(i'm thinking of making a very simple M2-Planet program that searches for a string and replaces it wtih another, no regex or anything, just to bootstrap here)

<fossy>now, while i wait for that to buiild again

<stikonas>fossy: I've dealt with patching already

<stikonas>fossy: that's why I did sed and then gzip

<stikonas>this worked: sed -i 165,174d util.c

<stikonas>and sed was easy, it just worked

<ullbeking>OriansJ: i just put the song on now, and then i'll go to bed with my wife

<stikonas>fossy: so once you push tcc, I'll try to integrate it with live-bootstrap

<stikonas>fossy: do you need to do those string replacements for tcc?

<stikonas>if not, then you can just use sed

<fossy>stikonas: there are no string replacements required for tcc; so, we don't need anything liek what i outlined

<fossy>stikonas: how about we integrate sed and gzip once i push tcc, but soonish we put tar in between?

<fossy>so sed -> tar -> gzip

<fossy>so that we we can distribute gzip as a .tar

<fossy>and then everythin after gzip as a .tar.gz

<stikonas>yeah, sed->tar->gzip would be nicer

<stikonas>it's just that I haven't done tar yet

<stikonas>well, you can look at tar :)

<stikonas>I can push sed and gzip once I test it

<stikonas>for now it builds on my main system using kaem and tcc. Hopefully it still works when isolated in qemu

<fossy>yeah i will look at tar 1ce i finish tcc

<fossy>ONE_SOURCE=1 is so nice

<fossy>reduced number of commands signfiicantly

<stikonas>for tcc?

<stikonas>so you do catm into one file and then -DONE_SOURCE=1?

<fossy>stikonas: not even, tcc has ONE_SOURCE=1 inbuilt, where it #includes everything

<fossy>so you just have to compile tcc.c instead of everything

<stikonas>oh ok...

<stikonas>yeah, I can see it in the source...

<stikonas>fossy: by the way, I think I'm done with diffutils too

<stikonas>at least cmp and diff, but that should be enough

<stikonas>anyway, I'm going to bed soon

<stikonas>so will look at your tcc stuff tomorrow

<ullbeking>i've just been browsing tcc, and whoa it's a groovy project!!

<ullbeking>i wonder if there's a c++ equivalent

<stikonas>probably no, c++ is much more complex language...

<fossy>stikonas[m]: pushed

<stikonas[m]>OK, I'll check in the morning

<stikonas[m]>Thanks

<stikonas[m]>fossy, you can also update mescc-tools-seed instead if checking out revision if mescc-tools

<fossy>stikonas[m]: oh yes

<OriansJ>as I did update both M2-Planet and mescc-tools in mescc-tools-seed (just need yt to update the AArch64 bit)

<fossy>stikonas[m]: no, not currently possible, M2-Planet --bootstrap-mode breaks everything badly (mescc-tools-extra works when --bootstrap-mode is added but blynn-compilier is very broken)

<OriansJ>I guess I am going to have to fix that if I broke it

<OriansJ>but first it looks like M2-Planet #if is behaving wrong

<OriansJ>well I made a fix and it is currently running ./bin/crossly precisely.hs generated/precisely.c (which will be a few minutes before it is done assuming everything is working again)

<malina>sorry, OriansJ but would u mind if I ask a 'quick' offtopic Question?

<malina>I mean it's relevant to hashsumming and what we are doign but not directly.

<malina>(else, I can ask tomorrow sometime when or if people are not busy).

<ullbeking>HOLY MOLY

<ullbeking>i just discovered the Forth subproject ( https://bootstrapping.miraheze.org/wiki/Forth ) and this looks amazing!

<OriansJ>malina: what is your checksumming question?

<malina>OriansJ, I think iam figuring it out. It wa sjust erm I have from LFS 2 bootscript tar.xz which contain the same files, (with b2sums verification), but the archives were givign different sums. I haven't seen it before.

<malina>I suspect though it is probably somehting to do with me in a pseudo broken state atm. due to not done a proper rebuild . I just wondered if you guys would know how to do an analysis or what is most likely the cause. (both handle fine and open fine but one is 150ish bytes larger so obviously will have diff checksum). I guess I just got a bit like WTH as it is from same source, same name , same content,

<OriansJ>malina: servers can serve anything they want; that is why trusted checksums from a trusted source is a critical step (ideally seperate from the server which could be hijacked and showing you the wrong checksum)

<malina>so was 10 mns ago wondering if it would most likely be tar or xz or so which might be borked.

<OriansJ>unlikely unless built with a borked C compiler

<malina>yes, it's luckily a 'small ' package with onyl a few source files bootscripts for lfs), I was just helping thm change to b2sums instead of md5sums. I doubt it is nefarious, which is why I wanted ot ask you in here, since you guys are fairly use

<malina>ye, I htink it is

<malina>that OriansJ . I had a perfectly working system until some weeks ago when I started messing around , and even used icc for stuff and I think I somehow have introduced something really shite lol :/

<malina>right. thanks. tomorrow I will compare the contents , size, and byte for byte and make sure it's just a broken _whatever_

<OriansJ>there is a big reason why guix includes --roll-back

<malina>ye, i am a gimp and just made a /recovery/

<OriansJ>also there are whitespace attacks thanks to unicode; So having sin take a look wouldn't be a bad idea if you are paranoid of potential attacks.

<malina>with my old packages of the 200 I had built o s and just reinstalled :D about 20 times, but I been doing this insanity for 4 years now and have built 10000 packages or os, it's a good way for me to stay on top of hings. I did have a perfect system though and was silly to not maybe

<malina>yes, OriansJ , I was htinking if maybe a trained eye could indeed ocnfirm my own notions. I can send them by all means to someone

<malina>I am 99% sure it's just a weird broken system, because the md5sums don't match.. or anythign, HAD that happeend, THEN I would be paranoid. and since b2sums are claiming the contents were the same, then it's probabl an appended broken encoding byte. (indeed I get sometimes a broken encoding here in irc client) . I just am susprised the package format still unpacks, and why does eveyrhitng else work/sum nicely. ANyway, sorry for the

<malina>noise/.distracton/OT

<OriansJ>don't trust your eyes but what you can know for certain. https://github.com/oriansj/stage0/blob/master/High_level_prototypes/sin.c

<malina>in all the past 4 years , I haven't come across things directly suspicious, except of course the fact external binaries or things like google being able to install root owned binaries in system, work on silent pathicng, and add drm stuff to kernel so it's easier to 'call' home ecnrypted, but beyond these things, its' not something.. literally it just all the sums were FINE except that one package. however, I now realise, it's

<malina>autogenerted from xsl and that IS definitely broke atm.

*malina smacks head

<malina>(ya, every file is same). my bad. although seeing a recent fix in iconv in glibc, I recall when packaging npm a while back, it segfaulted on a png. I kept that file because it wasn't "usual". that was indeed somethign iffy, and npm is closed source. piggybacked from arch, which also had a backdoor in cairodock in 2013. not sure if that was upstream or their user hwo did though. right. night night.

<siraben>OriansJ: is that a reimplementation of stage0 in C?

<siraben>where can I find the 357 byte seed rendered in C?

<gforce_d11977>siraben: https://github.com/bittorf/GNU-mes-documentation-attempt/tree/main/step00

<gforce_d11977>8-)

<siraben>gforce_d11977: thanks

<fossy>stikonas[m]: tcc 0.9.27 is also up

<gforce_d11977>fossy: can you please try and report if method-2 is working for you?

<gforce_d11977>fossy: https://github.com/bittorf/GNU-mes-documentation-attempt

<stikonas[m]>fossy: thanks, I'll take a look soonish

<stikonas[m]>In the meantime you can merge my old pr

<stikonas>fossy: mescc-tools rename broke live-bootstrap

<stikonas>Unable to open for reading file: ../mescc-tools/functions/numerate_number.c

<stikonas>oh, I need submodule --init

<stikonas>ignore that...

<rain1>i always forget that submodule stuff!

<rain1>i wonder why git pull doesn't just do it by default

<stikonas>I think there is pull --recursive

<stikonas>but yeah, I would have liked it automatically too

<fossy>stikonas: yeah same tbh

<fossy>i'll look into git hooks at some point

<fossy>stikonas: any idea why your precisely PR is conflicting files

<fossy>idgit

<fossy>ok, mergedish

<fossy>read: i fked it up then fixed it

<fossy>gforce_d11977: i tried it

<fossy>i get this

<fossy>/init: ./init.user: line 457: ls: not found

<fossy>after mes-m2

<gforce_d11977>fossy: thank you! thats ok, this part is just not implemented yet

<stikonas>oh yeah, submodule conflict

<stikonas>fossy: although, there are now even further updates to go.sh

<stikonas>probably worth merging them too...

<siraben>OriansJ: for some reason the newer mescc-tools-seed is causing the blynn-compiler build to time out

<siraben>I will increase the timeout to 30 min

<siraben>but that's getting quite long, up from when it used to be under 20

<stikonas>fossy: something is still bad with that blynn-compiler merge

<fossy>stikonas: oh

<stikonas> https://github.com/fosslinux/live-bootstrap/commits/master/sysa/blynn-compiler.kaem

<stikonas>I don't see any changes

<stikonas>maybe I'll make a new PR...

<stikonas>because we need to grab OriansJ's fixes too...

<fossy>what do we need the fixes for?

<stikonas>bootstrap mode?

<fossy>yeah just do that and then ill merge that

<fossy>i haven't enabled that yet

<stikonas>oh ok...

<fossy>it also breaks mescc-tools-extra

<stikonas>then we don't need that yet

<fossy>yeah

<stikonas>I still don't understand what happened with current merge

<fossy>me neither :|

<stikonas>somehow your merge commit removes all my changes

<fossy>which makes 0 sense

<stikonas>actually, simples thing is to cherry pick that commit

<fossy>ok i just cherry-picked it onyo master

<stikonas>that is already in the tree

<fossy>lmao

<stikonas>yeah

<fossy>same though

<stikonas>fossy: where do you want to store tarballs? For now I download them with wget into tarballs folder

<stikonas>and I guess we don't need to commit them into repo

<stikonas>to avoid blowing repo size

<fossy>stikonas: probably git lfs

<stikonas>argh, sed.c failed to compiled inside qemu :(

<stikonas>need to investigate

<OriansJ>siraben: the problem is CONSTANT CELL_SIZE needs to be moved below #define CELL_SIZE as it appears the M2-Planet built M2-Planet isn't doing the correct thing for some reason that Ineed to figure out. The timeout shouldn't need to be increased

<OriansJ>but I'll verify the work around for blynn-compiler first and then try to figure it out.

<siraben>OriansJ: Thanks, then i'll update the PR accordingly

<OriansJ>gforce_d11977: hex0 in shell would be: sed 's/[;#].*$//g' $input_file | xxd -r -p > $output_file

<OriansJ>although siraben if it looks like an M2-Planet regression you might want to use mescc-tools-seed commit 0e6d8d6d3f261b550af1768b767f66b30fd07854 as it has the fixes janneke needed and was working last week

<OriansJ>Why is it my luck every time I start working on macros does everything always sideways?

<OriansJ>^always^always goes^

<gforce_d11977>OriansJ: i will add this as a hint, but will do not want to use 'sed' or 'xxd' in the early stages (no external commands, only shell builtins)

<OriansJ>gforce_d11977: fair

<OriansJ>haven't heard from markjenkinsznc in a bit; hope he had a good holiday

<gforce_d11977>OriansJ: https://github.com/bittorf/GNU-mes-documentation-attempt/commit/95947c56a4fa1387edb8f0166e7cd76bee1a0bd2

<gforce_d11977>OriansJ: but now i have to do some real work 8-) see you later guys

<yt_>OriansJ: the CELL_SIZE problem sounds like something I caused :-(

<OriansJ>yt_: honestly I am starting to think the word macro is cursed; because everytime it shows up in my projects, things always go sideways for reasons I can't explain

<yt_>OriansJ: I like to think it's a reason we can't explain *yet*

<OriansJ>FORTH -> works fine; adds FORTH macros -> nothing works right. mes-m2 ->works fine; adds basic define macros -> everything is >.<; M2-Planet -> works fine; adds basic C macros -> everything breaks

<OriansJ>I'm honestly tempted to break your macro work into a seperate program call it M2-Saturn or something

<OriansJ>With the goal of making it a standalone C preprocessor capable of being leveraged by anyone who doesn't want to have to deal with C macros in their C compiler

<yt_>OriansJ: that's fair enough. I thought I could get away with not rebuilding the lexer, which is why I made it part of M2-Planet

<OriansJ>plus it'll give much more freedom to make changes without worrying about impact on M2-planet

<gforce_d11977>i have an interesting crash running mes-m2 (see vid at the very end: https://asciinema.org/a/ic9BCv49f5z9wegrVQ0CLZ1IF)

<xentrac>well, yes, macro systems are difficult to get right

<xentrac>macro systems are programming on nightmare mode ;)

<siraben>OriansJ: macros can be hard to get right, it's really substitution like in lambda calculus but finnicky

<siraben>having a separate macro expander would be great

<OriansJ>M2-Mesoplanet

<gforce_d11977>OriansJ: M2-Pluto 8-)))

<OriansJ>Macro Expander Saving Our m2-PLANET

<gforce_d11977>OriansJ: go for it!

<OriansJ>yt you'll get full push access to it as it is your baby

<OriansJ>invite sent

<yt_>OriansJ: thanks. the usual delay before I can contribute to the new repository applies, I'm afraid

<xentrac>siraben: how many years did it take to get a correct explanation of when you need α-renaming to correctly do β-reduction?

<xentrac>I have this crazy idea that it was like 15 years or something!

<yt_>OriansJ: would it be possible to bump M2-Planet in mescc-tools-seed just one commit further? I'm worried we've landed on a commit where --bootstrap-mode is known to be broken

<siraben>xentrac: I don't do α-renaming when I implement lambda-calculus, usually I create closures or convert to de Bruijn indices

<siraben>Hmm, I forget when I actually understood that but Types and Programming Languages explains it clearly.

<OriansJ>yt_: you mean 2af46c1?

<yt_>a8551f2f in M2-Planet, I think

<xentrac>sure, but historically de Bruijn indices came even later than correct α-renaming, didn't they?

<yt_>(as in, a8551f2f makes --bootstrap-mode sane again in the presence of #define and // lines)

<OriansJ>yt_: that would be one commit back

<xentrac>(you can reasonably think of creating closures as a form of α-renaming; it's just that the thing you're renaming *to* isn't made of text)

<rain1>yes

<OriansJ>mescc-tools-seed is on 09acd62

<rain1>and barendrecht convention of making every name completely unique

<rain1>and there is the higher order approach where you just make the hard parts someone elses problem

<yt_>OriansJ: master in M2-Planet is 09acd62 yes. the submodule hash in mescc-tools-seed for M2-Planet seems to be 6f2cebc which is one commit behind a8551f2

<OriansJ>yt_: I'll give it a whack

<yt_>OriansJ: thanks!

<OriansJ>looks like I have to do a minor mes-m2 revert but oh well

<siraben>rain1: xentrac: you may be interested in how blynn-compiler works, it's through a semantic translation of lambda calculus described by Oleg Kiselyov in 2019

<siraben>Actually quite efficient, Ben Lynn did a benchmark and his compiler produced programs that outperformed Miranda's (an older dialect of Haskell)

<siraben>They both compile to combinators, but Miranda's translation is more inefficient

<siraben>Paper: https://okmij.org/ftp/tagless-final/ski.pdf

<xentrac>I don't think it's accurate to describe Miranda as an older dialect of Haskell

<xentrac>it's sort of like describing the λ-calculus as an older dialect of Miranda

<siraben>Oops yeah, predecessor

<xentrac>Oleg's server is ECONNREFUSED, but is this the spineless tagless paper?

<xentrac>no, you said 2019

<xentrac>got it from https://web.archive.org/web/20201023204623/https://okmij.org/ftp/tagless-final/ski.pdf

<xentrac>this is lovely, thanks :)

<xentrac>I've done compiling to SKI-combinators myself when I was reading Peyton Jones's book

<xentrac> http://canonical.org/~kragen/sw/sk.html

<OriansJ>yt_: commit is up; please double check and fix the AArch64 please

<OriansJ>siraben: Hopefully this gets things working for you (Sorry for the breakage)

<xentrac>I think I need to sleep before I can understand this paper. Oleg is a high-information-content guy even when I'm at my best

<yt_>OriansJ: bootstraps fine on AArch64, I'll have the changes up in a second

<yt_>OriansJ: I guess now mes-m2 has to switch to non-bootstrap mode to get rid of the hack

<OriansJ>yt_: the hack involves // /* and // */ to hide a #if block from M2-Planet

<yt_>OriansJ: I mean, if you use M2-Planet in non-bootstrap mode now, #if __MESC__ works without the hack

<OriansJ>yt_: that is correct; but until M2libc is done and able to provide a proper FILE type; --bootstrap-mode is kinda stuck on for mes-m2

<yt_>OriansJ: that makes sense

<OriansJ>Just alot of balls in the air right now

<OriansJ>and I got it into a sorta working state https://github.com/oriansj/M2-Mesoplanet (still have a bit to strip out)

<deesix>It seems to me that the --bootstrap-mode thing is starting to be used for too many things and meaning nothing (as in it means too many things). I though it was just for M2-Planet test1000...

<OriansJ>deesix: well that is entirely my fault

<OriansJ>we wouldn't need it for anything but test1000 if I had M2libc operational

<OriansJ>I just haven't taken the time to work on M2libc in a couple days and am just falling behind on getting it up to speed

<OriansJ>once I get yt's mescc-tools-seed updates for AArch64; that will be off my plate for a couple days. I'll just backburner mes-m2 being broken for a little bit and try to get M2libc "done enough"

<deesix>One step at a time, too many balls in the air indeed.

<OriansJ>well writing a scheme, A C compiler, a C library, supporting all of their bootstraps and raising a child has never been considered easy work.

<OriansJ>oh and a Haskell compiler

<OriansJ>and a shell

<gforce_d11977>OriansJ: raising a child alone is hard enough 8-)

<OriansJ>and he is a 10month old who is openning combination locks

<yt_>OriansJ: AArch64 changes are up: https://github.com/oriansj/mescc-tools-seed/pull/24

<yt_>sorry for the delay, I kept distracting myself XD

<OriansJ>yt_: it is ok, my son is constantly pulling at my attention ^_^

<OriansJ>thank you yt_

<yt_>OriansJ: no problem

<yt_>OriansJ: so I'm trying to write a test which needs to compile in non-bootstrap mode, for the global array change. would it already make sense to add M2libc in its current form as a submodule of M2-Planet, so tests can start depending on it?

<OriansJ>yt_: well my goal is to get AMD64 and armv7l working today; then I can make it a submodule in M2-Planet and start migrating the tests over to it

<OriansJ>I was hoping you'd help get the AArch64 bit working and I'd deal with the knight bits later

<yt_>OriansJ: I can definitely help with moving tests over

<OriansJ>well we could just let AArch64 be broken in M2libc for a little bit I guess.

<yt_>OriansJ: sure, I can carry fixes locally for a bit, then upstream them when I can

<OriansJ>yt_: ok I've pushed M2libc as a submodule to M2-Planet with x86 "working"

<OriansJ>You can update the x86 tests to no longer need --bootstrap-mode (except test1000 which will need it)

<OriansJ>while I work on getting AMD64 working, then armv7l

<OriansJ>oh yt_ you might need to know: M2-Planet --architecture amd64 -f /Linux/unistd.h -f stdlib.c -f x86/Linux/fcntl.h -f stdio.c -f foo.c -o foo.M1 --debug && blood-elf -f foo.M1 -o foo-footer.M1 && M1 --architecture x86 --little-endian -f x86/x86_defs.M1 -f x86/libc-full.M1 -f foo.M1 -f foo-footer.M1 -o foo.hex2 && hex2 --architecture x86 --little-endian --base-address 0x10000 -f x86/ELF-i386-debug.hex2 -f foo.hex2 -o foo

<OriansJ>the important changed bit is x86/libc-full.M1

<yt_>OriansJ: thanks, I'm starting with the simpler tests first, it'll be a while until I need libc-full.M1 I guess

<markjenkinsznc>Thanks OriansJ, things haven't been going super, but maybe by Feb I'll be able to hobby code again

<OriansJ>which replaces libc-core.M1 for those tests that need to deal with STDIN, STDOUT, or STDERR (it just adds a single call to the C function __init_io

<yt_>OriansJ: I see, that makes sense

<OriansJ>markjenkinsznc: well we worry with COVID and all going around. And I hope things get better for you

<OriansJ>yt_: we can pull libc-full.M1 when I figure out how to add initialized structs to M2-Planet to remove the need for that function

<markjenkinsznc>I'll waste no time when the province of Manitoba offers me Moderna or Pfizer's vaccine

<markjenkinsznc>Waste no time thinking about them I mean

<markjenkinsznc>Blessed to be working from home with a solid job during all this and living in a wealthy country that has contracts more more vaccines than people

<OriansJ>good. Lost 2 coworkers to COVID last year; don't want to lose any friends to it.

<deesix>I guess the changes for the tests have to wait until the dust settles.

<OriansJ>deesix: see too many things going on at the same time

<deesix>The sha thing ate my time yesterday, sadly without satisfying results. The unification would be helpful for the M2libc introduction.

<mihi>congrats fossy et al. for live-bootstrap project. I ran commit 1ebbd69c79a4a6e4a156e3238ad80757ee0fa16c of it (in a chroot instead of a VM), and apart from /after/bin not being in $PATH it ran through and built everything. However, I'm unable to (inside chroot) compile a hello world with resulting tcc binary, complaining about undefined symbol '__fixdfdi'. Anything special I need to link or #define to make it work?

<mihi>same result with compiling 'int main() {}'

<rain1>Cool to do the bootstrap inside qemu with minimal tools

<yt_>deesix, OriansJ: if you want I can help review the parallelised tests changes

<yt_>seeing I've got my hands dirty in updating tests anyway

<gforce_d11977>mihi: fossy: i still could not start a live-bootstrap - what are the indented commands to get it running? (after clone --recursive ...)

<yt_>OriansJ: guess who just ran face first into the __init_io thing XD

<OriansJ>you did ^_^

<yt_>OriansJ: I did XD

<yt_>OriansJ: but good new is, I've got M2-Planet test0008 passing with M2libc (and no --bootstrap-mode) on AArch64

<OriansJ>nice

<mihi>gforce_d11977, In rootfs.sh I replaced the QEMU "line" by 'PATH=/after/bin:$PATH chroot . /init'

<mihi>then I ran the thing and waited some time :)

<OriansJ>good because I just got AMD64 kinda operational

<gforce_d11977>mihi: ok, will try...

<mihi>gforce_d11977, you may want to remove the umount too so that the results are not lost

<OriansJ>and when you are ready yt_ M2-Planet's submodule for M2libc has been updated for you when you are ready to do that work too.

<OriansJ>Now to get to work on armv7l

<yt_>OriansJ: would you mind testing the x86/amd64 changes once I send the PR? I can test on AArch64 and then make equivalent changes to the test files for x86 and AMD64, but there is always a chance I miss something

<OriansJ>siraben, pder: later today when M2-Planet tests have cleared out any major bugs in M2libc, I'll be able to remove the copy/paste libc-core.M1 and co from blynn-compiler and add M2libc as a submodule

<yt_>OriansJ: I mean, I can test that it all compiles, but I can't check that the resulting binary is working

<OriansJ>yt_: I always test before pushing

<OriansJ>So if there are problems I'll take a look

<yt_>OriansJ: great, thanks

<siraben>OriansJ: sounds good to me, thanks

<OriansJ>hopefully we can clear out all problems I caused blynn-compiler today

<deesix>yt_, thanks. The first draft was fine in x86 and AMD64 but we haven't testted it on AArch64. That's one thing you can check if you want, let me link it to you. But I think that, as a moving target as they're now... applying the changes would stress everyone's workflow.

<OriansJ>well right now I am here figuring out how to do armv7l right

*yt_ hides, knows nothing about armv7l XD

<ullbeking>good evening all

<ullbeking>just popping in to say hi

<ullbeking>then i'm off to play with my daughter

<deesix>o/

<OriansJ>yt_: well I just need to do a little testing on my armv7l system and we should be off and to the races

<yt_>OriansJ: awesome! I've got the first few changes to the M2-Planet tests up https://github.com/oriansj/M2-Planet/pull/13

<yt_>I've left out the updates to test0008/hello-aarch64.sh because they need the missing pieces in AArch64 M2libc

<OriansJ>yt_: I'll try to figure those pieces out

<OriansJ>ooh that is not good

<OriansJ>test/test0008/hello-amd64.sh segment fault

<yt_>OriansJ: oh! I forgot to do libc-core -> libc-full for amd64

<OriansJ>feel free to fix it up

<yt_>OriansJ: on it

<OriansJ>I can do git reset HEAD~1 and remerge

<yt_>OriansJ: should be fixed now

<OriansJ>in the middle of getting AArch64 probably working (can't actually test so just being careful)

<siraben>Maybe this is how we bootstrap Rust https://github.com/Rust-GCC/gccrs

<siraben>GCC → rustc directly

<rain1>woah

<qyliss>wow

<qyliss>I wonder what stage it's at

<rain1>that other rust bootstrap just got ditched

<rain1>mrustc

<qyliss>ditched by whom?

<rain1>ah i misread, i thought guix switched to using that

<civodul>Guix uses mrustc indeed: https://guix.gnu.org/en/blog/2018/bootstrapping-rust/

<civodul>using GCC would be sweet

<OriansJ>assuming it can be bootstrapped not depending on Rust

<OriansJ>yt_: test passes great now

<OriansJ>I've updated M2libc with a blind AArch64 version of write and read, and had M2-Planet update that submodule. could you please test to see how badly I screwed up?

<gforce_d11977>mihi: fossy: running live-bootstrap in a chroot @0ee601747109de3f310876b6d856a199fb85b4d8 worked here also including tcc... (around 45 minutes here)

<stikonas>live-bootstrap in chroot always fails for me...

<stikonas>somehow things like cp are not found in PATH...

<stikonas>also chmod is missing, so somehow it's ignored when in qemu

<OriansJ>yt_: so did I screw up AArch64's read and write too badly?

<yt_>OriansJ: sorry, was afk. will have a look now

<stikonas>rain1: siraben: I also used mrustc to bootstrap rust...

<stikonas>I have Gentoo overlay for that...

<stikonas>it works, but if of course slow...

<OriansJ>yt_: Thank you

<yt_>OriansJ: I believe AArch64 is still missing a libc-full.M1

<OriansJ>knew I was forgetting something

<yt_>let me push my test0008 changes for AArch64 so you can see if it compiles at least

<OriansJ>I am currently trying to fix fgets because clearly I did something wrong

<siraben>stikonas: Oh, that's great!

<stikonas>siraben: there are some problems outside guix though. mrustc->1.19 is hard on modern systems (except for guix), mrustc->1.29 worked for me on amd64 but not on arm64 (so on arm64 I just cross-compiled)

<stikonas>(1.19 needs old openssl)

<yt_>OriansJ: AArch64 test update is here: https://github.com/snnw/M2-Planet/commit/81ea5bc9c89bcf3faf4aa9a7627ce72889d517e1

<OriansJ>yt_: I made a stabing guess at what libc-full.M1 for AArch64 needs (probably wrong)

<OriansJ>and just pushed to M2libc

<OriansJ>see if that takes care of your needs yt

<OriansJ>and checking on that commit right now

<yt_>OriansJ: I think we have a winner

<OriansJ>although your checksums for test0008 didn't match with the new M2libc

<yt_>OriansJ: I think that might be due to me using my (unpushed) copy of M2libc

<OriansJ>So feel free to do a git commit --amend to fix that while I do a git commit with the new upgraded M2libc

<yt_>OriansJ: okay will do

<OriansJ>I'll update the x86 and AMD64 checksums in my commit as they should change with the revised M2libc

<yt_>OriansJ: pushed and PR'd: https://github.com/oriansj/M2-Planet/pull/14

<yt_>that also includes the x86 and AMD64 checksums, but they should now match yours

*yt_ crosses fingers

<OriansJ>yt_: you did it

<OriansJ>great job

<OriansJ>I gotta eat breakfast; it is nearly 1

<OriansJ>thank you yt_

<OriansJ>be back later

<yt_>OriansJ: woo! good progress before breakfast :D

<yt_>enjoy!

<malina>AH no wonder I was wtfing yest, cleaning up and rerunning worked now and got tcc up !!!!! :D

<malina>and now the magic trick suddenly became OH so REAL :D nice one , very nice indeed!

<malina>an amazing feat about this is also how little time it takes

<Hagfish>great to hear you've got to tcc!

<stikonas>well, I still haven't got sed after tcc...

<stikonas>injecting busybox binary now for some interactive debugging

<malina>ya great stuff. thanks (for this) . I justhave to do another run to make sure my system tcc wasn't being pulled in by any chance

<yt_>OriansJ: I caught a bug in fflush/fputc. fflush writes one byte too many, and fputc leaves an initial null byte, so together fputc('A', stdout) does write(1, "A\0", 2)

<yt_>write(1, "\0A", 2) even

<stikonas>malina: that's why live-bootstrap is there. It definitely avoids anything from the system

<malina>sounds like something in my bug yest in the archives, think xslt conversion or so added a bogus byte somewhere in still somehow in a way tar and xz didn't mind. Scary actually,

<yt_>and this makes for hilarious scenes, because diff will silently ignore the extra null bytes!

<malina>stikonas, ye I , mean I haven't got time to sit with only this and fully go into intrinsics, so I keep just an eye here and peruse the code a bit here and there but I still am behinf. BUT

<malina> https://sourceware.org/legacy-ml/libc-alpha/2016-02/msg00274.html

<malina>someone was flaunting it in musl just yest, not related as such but interesting nonetheless, that sometimes it's not _just_ the c lib creating potential bugs

<OriansJ>yt_: I'll fix that shortly

<yt_>OriansJ: thank you]

<yt_>(seriously, something is weird with emacs, inserting random characters sometimes)

<OriansJ>yt_: actually I think the problem is in fputc

<malina>that's just me controlling your hacked keyboard unit. I am trying to type rm -rf /home/* whilst you are working!

<yt_>OriansJ: I think you'll find a mistake in both fflush and fputc :)

<yt_>(I'd post a patch, but you know my reasons)

<OriansJ>fair; just very distracted lately

<yt_>OriansJ: no worries, just trying to help :)

<yt_>OriansJ: I'm going to have to punt on test0021. M2libc doesn't have getcwd yet

<OriansJ>yt_: fair; I'm trying to get M2libc gcc compatible to make development and testing easier

<OriansJ>but for some reasons GCC doing return {fd = 10, bufmode = 1, bufpos = 0, file_pos = 0, buflen = 1310720, buffer = 0x7ffff7cb1010 ""} results in {fd = 10, bufmode = 1, bufpos = 0, buflen = 0, buffer = 0x140000 <error: Cannot access memory at address 0x140000>}

<OriansJ>looks like I'll have to write gcc compatible assembly versions for testing -_-

<OriansJ>I think I'll go play with my son for a bit instead

<mihi>stikonas, I guess you are seeing the same problems as me when using chroot. I believe the issue lies in kaem, which gets started with a full environment in chroot but an empty one when /init. when kaem 1 sets PATH and launches kaem 2, the path lookup inside kaem 2 happens still with the old $PATH, yet the $PATH seen by subprocesses is the new one. I worked around it by 'PATH=/after/bin:$PATH chroot . /init' so

<mihi>PATH is correct from the beginning.

<yt_>OriansJ: (no rush, for when you get back) there is a bug in fseek with SEEK_END. the offset is substracted from the end of the buffer, but the offset will be negative in that case, so it'll access outside of the buffer

<mihi>in fact, the same happens when kaem sets any variable twice, the first one is still used inside kaem but the second one in (non-kaem) subprocesses.

<OriansJ>yt_: fseek fixed

<OriansJ>bbl

<stikonas>mihi: oh thanks, I'll try that

<stikonas>will be easier to debug my issue in chroot

<mihi>I'm working on a patch to kaem to fix the env problem. Seems that in live-bootstrap there are 2 different kaem versions submoduled. Who wants the patch/PR?

<stikonas>ok, seems to work, thanks again

<stikonas>mihi: isn't one small and written in assembly

<stikonas>and the other is written in C and more powerful

<stikonas>(but unfortunately they share the same name)

<mihi>I mean, there are twice the same repo submoduled :)

<mihi>only at different revisions

<stikonas>oh...

<stikonas>well, report it to fossy :)

<mihi>ah probably because mescc-tools-seed still needs the old one

<stikonas>the one from mescc-tools-seed can be udpated

<stikonas>or maybe submit PR...

<stikonas>I think I actually mentioned it to fossy this morning

<stikonas>just need to fetch latest version of mescc-tools-seed

<mihi>anyway my fix does not work. It fixed 'echo ${PATH}' but not the lookup

<stikonas>anyway, that workaround seems to work

<stikonas>I'll try to see if I can figure out how to link sed

<fossy> the latest version of mescc tools seed was broken with blynn, mescc-tools-extra and wip-m2

<stikonas>oh, I think there is now a fix in blynn

<stikonas> https://github.com/oriansj/blynn-compiler

<stikonas>actually, for now we don't really need blynn-compiler...

<stikonas>fossy: I'll soon try to figure out this from chroot shell, but maybe you have any quick ideas. liking sed results in (undefined symbol '__fixdfdi')

<fossy>uhhhh

<fossy>thats a tcc problem

<stikonas>yeah...

<fossy>most likely libtcc1.a

<fossy>wait I know

<stikonas>hmm, I actually used different tcc yesterday...

<fossy>I am still using the mes libtcc1

<stikonas>it was 0.2.26 I think...

<fossy>0.9.26?

<stikonas>yesterday when I was writing kaem file

<fossy>Ill have a fix for that in a second

<stikonas>and it was on my main system, so now in qemu

<fossy>Weird it didnt run into that problem compiling libc

<stikonas>s/now/not/

<stikonas>fossy: so my linking command was tcc -o /after/bin/sed alloca.o getopt1.o getopt.o regex.o sed.o utils.o -L /after/lib -ltcc1

<mihi>stikonas, fossy, exactly the same error I get from linking my one-line hello world with bin/tcc (see log above)

<stikonas>ok, so it was fossy not testing his tcc work :D

<stikonas>although, one would think that rebuilding compiler itself is more than sufficient

<mihi>stikonas, fossy, OriansJ: pull request for you to review: https://github.com/oriansj/mescc-tools/pull/15

<stikonas>looking

<yt_>OriansJ: both fixes verified, thanks!

<yt_>OriansJ: one more though: fgetc doesn't check for EOF properly for stdin

<fossy>yeah, because it recompiles the libc and libtcc. i have no idea why it wasn't working then lol

<fossy>build is nearly done, if this works then i'll push and then tcc will most likely work

<fossy>stikonas: BTW, with that command, we do have libgetopt.a in /after/lib

<fossy>but idk if that would work in replacement for getopt*.o

<fossy>stikonas: mihi my preliminary tests seem to say that my most recent commit to live-bootstrap should fix your problem

<stikonas>ok, then push :)

<stikonas>hmm, I wonder if I need -L /after/lib...

<stikonas>because you do pass CONFIG_TCC_LIBPATHS= there

<stikonas>so maybe it will just work

<fossy>if you need that there's another bug i need to fix

<stikonas>probably not...

<stikonas>that's something I was adding after linking failed

<mihi>fossy, should it be sufficient to recompile libtcc1 with those two lines inside my existing chroot? Because it is not (tcc segfaults afterwards when trying to link). I'm going to bed now so probably I'll retry the whole process tomorrow or whenever I find time.

<fossy>mihi: ugh

<fossy>stikonas: for now, please comment out all of the tcc 0.9.27 stuff.. it seems to be broken

<stikonas>ok...

<fossy>just use 0.9.26 for now

<stikonas>ok, let me try to build it

<stikonas>ok, running, will take about 30 min to build

<yt_>OriansJ: PR is up for M2libc tests in M2-Planet for AArch64 https://github.com/oriansj/M2-Planet/pull/15

<stikonas>fossy: hmm, same problem with tcc 0.9.26...

<stikonas>by the way, I've pushed the branch I'm testing although haven't opened PR yet...

<stikonas> (https://github.com/stikonas/live-bootstrap/tree/gzip)

IRC channel logs

2021-01-10.log