<OriansJ>ok; that was fixed. M2-Planet for x86 is ready for your testing again pder <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. <siraben>Structure and Interpretation of Computer Programs <OriansJ>siraben: one bit is the use of programs to generate programs <OriansJ>the problem is hiding the program that did the generation. <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 <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>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 <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 <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. <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>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>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 <pder>if you bootstrap M2-Planet from mescc-tools-seed you will need to update the x86_defs.M1 file in x866 <siraben>it's good time to split the CI into two jobs as well, one using mescc-tools-seed and one using m2-planet <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 <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 <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>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