IRC channel logs

2020-12-16.log

back to list of logs

<OriansJ>ok; that was fixed. M2-Planet for x86 is ready for your testing again pder
<Hagfish> https://news.ycombinator.com/item?id=25434842
<Hagfish>Google have made a Rust library that has build dependencies on Perl, and Go, and a C++ toolchain
<pabs3>theres a Rust library that uses a Python script to generate part of its Rust code, checks that generated Rust code into git and the crates.io package discards the Python script
<pabs3>developers these days huh :)
<nimaje>afaiu that are dependencies of the bundled boringssl and not the rust lib, not sure what the dependencies of the rust lib are besides boringssl and rust
<nimaje>well, that doesn't seem to matter as it seems the only way to build that is to build the bundled boringssl with it
<siraben>OriansJ: could you update mescc-tools-seed as well?
<OriansJ>siraben: yes but I was hoping to get all of the architectures working with signed/unsigned compares first
<siraben>I see. I forget, but this is needed for blynn-compiler to work properly again?
<OriansJ>siraben: it is for pder to remove a hack from vm.c
<OriansJ>Hagfish: could be worse; it could depend upon itself and be forever unbootstrappable
<OriansJ>pabs3: sounds like someone took the wrong lesson from SICP.
<pabs3>SICP?
<siraben>Structure and Interpretation of Computer Programs
<siraben>It's amazing
<siraben> https://www.youtube.com/watch?v=-J_xL4IGhJA&list=PLE18841CABEA24090
<OriansJ>siraben: one bit is the use of programs to generate programs
<OriansJ>which is fine
<OriansJ>the problem is hiding the program that did the generation.
<siraben>Ah yes
<siraben>Curiously, Ben Lynn says that the blobs in the beginning were generated by a program but I'm not sure if he shows that program
<OriansJ>for example the bison functionality that gio had to solve that depended upon itself in the exact same commit; along with generated output for building, so people largely missed it but we hit it hard
<OriansJ>siraben: it is why the blobs need to either be eliminated entirely or generated from something we can easily read and trust
<siraben>RIght.
<OriansJ>right now; unwinding his engineering choices to get something M2-Planet can bootstrap was been the priority but those blobs must be addressed before it goes into mescc-tools-seed
<OriansJ>if there are guile primitives I need to add to mes-m2 to make it happen; I'll do the work
<OriansJ>or if we need to write a C program that does the conversion; we can get that working.
<OriansJ>but we need a solid plan to deal with all of the blobs; either on a one by one basis or with one big program.
<OriansJ>AMD64 support for unsigned compares is now up.
<OriansJ>up next is armv7l and AArch64 and then it will be done
<OriansJ>wait a second. armv7 allows big endian programs to run on little endian operating system?
<OriansJ>???
<OriansJ>Does it mean big endian instruction encoding or just data?
<OriansJ>because if it is instruction encoding; a major clean upcould be done for armv7b
<fossy>What
<OriansJ>fossy: to which?
<OriansJ>armv7l unsigned compares are up and running
<OriansJ>good night; hopefully either yt or deesix pick up the AArch64 piece which should be trivial
<xentrac>yay, congratulations!
<fossy>OriansJ: how weird
<fossy>the arm stuff
<fossy>thats why I went what
<pder>OriansJ, thanks for fixing that unsigned compare issue. I was able to revert my hack after updating x86_defs.M1, and it worked perfectly
<pder>I also updated the Haskell files up to the virtually stage to eliminate the need for that script filter based on a fix that siraben made. Those three lines needed a few tweaks in the later stages, so you may want to review my changes.
<siraben>pder: I'll take a look as well
<pder>siraben: thanks, I'm just barely understanding the Haskell syntax, so feel free to fix anything or reformat
<siraben>pder: which branch did you push your changes to?
***yt_` is now known as yt_
<yt_>OriansJ: fossy: in Armv7, endianness is a processor mode bit, so can be set by the OS on a per process basis. However, it doesn't affect the instruction byte-order, which is always little-endian.
<yt_>deesix: OriansJ: I'll have a quick look at the unsigned comparisons for AArch64 this evening. I did them earlier this week for MesCC so should be easy enough.
<OriansJ>pder: looks good, merged
<OriansJ>yt_: thank you
<OriansJ>I guess that makes sense and explains why little endian dominated; supporting multiple endianess inside of a single binary is a massive pain with little benefit; as the ELF header and data would have to be big endian but all of the immediates and offsets would have to be little endian.
<siraben>pder: hm, i need to think a bit more about how i'm changing the files, I'm not sure why it's not working past loinely
<siraben>OriansJ: it appears the commit you merged is causing the CI to hang
<siraben> https://github.com/oriansj/blynn-compiler/runs/1563686577
<siraben>Does it complete on your machine?
<siraben> https://github.com/pder/blynn-compiler/runs/1561591341
<siraben>It appears that it failed on pder's branch as well after 6 hours
<siraben>I should set a timeout on the builds
<pder>siraben, have you updated to the latest M2-Planet. That should fix the hang problem building lonely or patty
<siraben>pder: i'll bump the version of mescc-tools-seed then
<siraben>hopefully the submodule is updated
<siraben>ah it's still lagged behind
<pder>if you bootstrap M2-Planet from mescc-tools-seed you will need to update the x86_defs.M1 file in x866
<pder>x86
<siraben>it's good time to split the CI into two jobs as well, one using mescc-tools-seed and one using m2-planet
<siraben>s/good/probably a good
<pder>siraben, how do these tests get triggered? Is it everytime someone pushes to master?
<siraben>pder: yes in any branch of any fork, and any PR
<siraben>it costs nothing to me as it is free for public projects
<siraben>the CI isn't perfect of course so I'll adjust it as we go along
<siraben>hopefully less failures and more distributed testing (building blynn-compiler on different platforms) occurs
<siraben>pder: I made a modest PR https://github.com/pder/blynn-compiler/pull/2
<siraben>OriansJ: build fixed by basing blynn-compiler off m2-planet, https://github.com/oriansj/blynn-compiler/pull/8
<pder>OriansJ: I updated mescc-tools-seed by updating the M2-Planet submodule and updating the x86 and AMD64_defs.M1 files https://github.com/oriansj/mescc-tools-seed/pull/20
<pder>siraben: if you build from my master branch in mescc-tools-seed, the resulting M2-Planet and other tools should allow the blynn-compiler to finish without errors
<siraben>pder: thanks, I'll try it out
<OriansJ>siraben: still waiting for the AArch64 patch for M2-Planet before I make it merge the latest version of M2-Planet into mescc-tools-seed as I was going to do an M2-Planet release as it is a significant change in behavior
<OriansJ>siraben: your pull request has been merged
<siraben>OriansJ: thanks.
<siraben>Also ensures builds longer than 10 minutes will time out
<OriansJ>pder: I'll merge your pull but next time please remember to update the checksums too.
<OriansJ>and pder your pull request has been merged
<OriansJ>when I have more time I'll fix the AArch64 checksums too
<pder>OriansJ: ok, will do. Is that the SHA256SUMS file in each arch directory?
<Hagfish>there's been so much great work happening here recently, well done everyone
<Hagfish>are there any other big milestones that might happen by the end of the year (if things continue at this rate)?
<yt_>OriansJ: sorry about the delay, looking at AArch64 unsigned comparisons now