IRC channel logs
2022-12-08.log
back to list of logs
<drakonis>oriansj: mzig should be minizig or some german pun <oriansj>drakonis: yep; my son likes to watch PBSkids and that takes up a big chunk of bandwidth <oriansj>drakonis: but I assume whoever does that work will probably name it anything they like and we will probably just be glad someone is ontop of that <drakonis>although i think what zig's community is doing is actually quite beneficial for them <drakonis>plus its probably best to write an alternate implementation that's based off the hypothetical post 1.0 spec <oriansj>it would have been better if they just froze the C++ implementation, called it 1.0 and required everything up until 2.0 to be buildable by it <drakonis>to be fair, its still ways from being complete <drakonis>plus it would definitely come back and bit the community back <oriansj>but if you can't write basic code it isn't v1.0 and if you can't stand slightly ugly code; then there are other issues. <drakonis>they're working on these, though you can indeed write basic code with it <oriansj>and I can grant you with upgrades it can look even prettier and even run faster <drakonis>but it's not fully stable yet, there arent any guarantees existing code will build in future versions yet <oriansj>but unless you want people chasing a list of point releases (or commits) then you need to compromise a little <drakonis>the worst mistake the community can make is freezing too soon <drakonis>because it will inevitably signal droves of new users to try it and suffer <drakonis>the standard library is still a bit thin and not entirely well documented yet <oriansj>well there is a big difference between zig developers having to put up with an older version's limitations and the users of the zig language having to put up with an older version's limitations <drakonis>they release new versions on a semi yearly basis <drakonis>so it doesn't take too long for new ones to come out <drakonis>i foresee two to three releases before 1.0 <oriansj>I foresee potential issues but I am just hoping we can avoid that <drakonis>ah, there's going to be a blog post about the stage1 changes <pabs3>(NickH is the maintainer of the in-progress Debian zig package) <pabs3>ah, mzig already mentioned above <stikonas>still it looks like they are not going to work on alternative implementation <oriansj>sounds about right; less work for them <oriansj>So they value bootstrapping but not if they have to do the work. I think that kinda is a polite way of saying they aren't going to help us but good luck. <Hagfish>i don't know if this article has been discussed before, but i just found it linked from a recent Vitalik blog post: <Hagfish>"The building techniques used on Jingu may seem low-tech, but even something as simple as wooden post-and-beam construction sits atop a large pyramid of enabling technologies. ... <Hagfish>But the most important technology at Jingu is social - it’s the transfer of skills and techniques from one generation to the next, ensuring the temples and artifacts can continue to be reproduced accurately." <Hagfish>i'd like to imagine that the decisions and values being made and discussed in this chatroom will live on, in some form, for another 1000 years <Irvise_>Hi, I have one question regarding TCC. Is there an IRC room to discuss it or can it be done here? It relates to boostrapping. <stikonas[m]>No guarantees that I can answer but maybe somebody can <Irvise_>It is just a quick thing. There is a very small Scheme implementation called Otus Lisp. It uses alloca instead of malloc so that they don't actually have to free memory explicitly. <Irvise_>That is all fine and dandy and it can be compiled with TCC in x86 and most likely in arm* too. <Irvise_>The problem is that TCC does not implement alloca in RISC-V. <Irvise_>From what I have seen, it is not too complex to implement, but it should be done in asm. Is this something that a TCC developper would be willing to take a look at? <Irvise_>Btw, I am running my first live-bootstrap build. <stikonas[m]>Hard to tell whether tcc developer would implement, I guess they would accept a patch though <Irvise_>(It seems, sadly, that Otus Lisp does require a binary to be compiled... So it is not fully bootstrappable...) <Irvise_>I am in the final stages to choose a Scheme implementation for the GNAT bootstrap. Final candidates are Chibi, Ol and TR7. With Ol having that major issue. <Irvise_>I would like it to be compiled as soon as possible in the chain. I saw that GCC 4 is now being compiled before doing the "full" GCC4.7. <Irvise_>Quite a few things have changed since the last time I took a look at the live-bootstrap chain :) <stikonas[m]>That is because 1. we don't need C++ until much later. 2. Stable tcc can't build GCC 4.7.4 <Irvise_>Yup, I am using the mob branch. It works quite fine in RISC-V :) Though there are some issues and it does not seem to support 32bit RISC-V. <Irvise_>Though I heard that they wanted to make a stable release from the mob branch. <Irvise_>There may be a flag that allows it to target 32bit. But the files are all marked riscv-64. <oriansj>there is also a chance RISC-V (32bit) might not get enough support to get off the ground as RISC-V (64bit) seems to be the one getting all the attention from developers lately <Irvise_>Yes... Even the Linux world does not really care about 32bit riscv... Only things like buildroot can generate images for 32bit Linux. All other major distros already target 64bit... <oriansj>Irvise_: could the binary be compiled from another scheme? <Irvise_>oriansj: I started a conversation with the developer a couple of days ago. We will see. It is serialised FASL format, so not your normal raw binary, but still... <oriansj>thank you for starting that conversation, we need less language bootstrapping nightmares <stikonas[m]>Indeed. Still, I'm not convinced that we need gnat or Ol early in bootstrap chain. One can of course make it buildable early but that does not mean that we'll build it early in live-bootstrap <Irvise_>stikonas: I want that to be a possiblity, not an obligation :) <Irvise_>The reason is that GNAT has always needed GNAT. The newer the GNAT we have to compile, the worse it gets, as it uses newer language features. So if we could build GCC 4.0 or GCC 4.7 that would be great. And we could use the live-bootstrap environment/chain to do that. <Irvise_>I know that is not your goal, but I want to make that possible for us. <oriansj>Irvise_: there are many possiblitie we can create, some are just easiest done in guix <Irvise_>Btw, I also helped Easy-ISLisp be compilable with TCC and made ncurses optional, so theoretically, that could also be used very early in the chain, even if that is not the case. <Irvise_>oriansj: I understand, but we would like to try and if we cannot or if it is just too much, then we can always fall-back. <Irvise_>Also, Easy-ISLisp runs on risc-v too compiled with TCC/mob. <oriansj>Irvise_: proposals with working code and no blobs work best but ulimately stikonas and fossy decide what does or does note show up in live-bootstrap <oriansj>as they are responsible for keeping it working <oriansj>stikonas: your M2libc and M2-Planet patches have finally been reviewed and merged (spawn took me a bit) <Irvise_>Sure, I will not try to get it in unless it is deemed worthy or benefitial. Also, the project has not really even started, so it is years into the future :) <oriansj>Irvise_: depends upon how interesting and fun others find it. It might even take you far less than you previously thought <oriansj>I originally thought hex0 to gcc would take a decade and we did it in 5 years. <oriansj>guile was done way faster than I could have imagined <oriansj>and with the amazing progress by stikonas and rickmasters what looked like what could take the rest of my life might actually be achieved in the next couple years <oriansj>then we have the adventure of bootstrapping hardware and then reality ;-p <Irvise_>Yes, we still have not promoted the idea of a bootstrapping compiler. I want to wait before we have the bases figured out and then we can hope that other people may want to join :) <Irvise_>Also, you all are quite commited and prolific, I do tend to check on progress and you are really hammering it :D <Irvise_>A couple of lines before there is: SHA256 of old file: 0 <Irvise_>SHA256 of new file: 34a54d5191775c1bd37be6cfd3f09e831e072555dc3a2e51f4a2c4b0f8ada5cc <stikonas[m]>The question is whether it is due to your system, some date non-reproducibility or something else <stikonas[m]>Though for sure live-bootstrap will break hard in 2038 <Irvise_>I just did a git clone and took the vmlinux binary out of Debian-32bit. I am on x86_64 <Irvise_>I used the ./rootfs.py --qemu approach. <rickmasters>stikonas: I started a build right after the report from Irvise_ and I have reproduced the exact same failure on ca-certificates-3.78 <rickmasters>given the recent rework on checksums this might be a regression. I'm building against recent commits to see if I can find a regression. <stikonas[m]>I think at some point I tried to manually run live-bootstrap with future date to catch up some of those issues <rickmasters>stikonas[m]: Are you referring to the year 2038 problem or the ca-certificates? <rickmasters>So you think the ca-certificates issue is related to the current date? <rickmasters>Interesting: there are two certs not valid after "Thu Dec 08 11:10:28 2022" in /usr/src/ca-certificates-3.78/build/nss-3.78/certdata.txt <rickmasters>stikonas[m]: looks like two certs expired 4 hours ago if that's UTC <stikonas[m]>We might need to ignore checksum on that package then... <Irvise_>Oh, so did I really hit a bug where some certs expired? <stikonas>as for what goes into live-bootstrap, the idea was to build new gcc and linux there. We've got GCC covered and now rickmasters is working to bootstrap the Linux kernel. Which mostly means getting to C only GCC and Linux as quickly as possible as any extra package might be causing us various issues before we boot into linux <stikonas>and if we really need early GCC for bootstrapping GNAT (which I agree might make bootstrapping GNAT easier) then it might be easier to build older GCC on the new Linux system <Irvise_>stikonas: regarding GNAT. GNAT has always needed GNAT. No older GCC is able to compile GNAT... The story of GNAT is very convoluted... I know this sounds crazy, but GNAT already required GNAT when it was first added to the GCC tree. Binaries were shipped to allow third-parties to compile/use it. <stikonas>yes, this I understand. I was saying if older GNAT is easier to bootstrap, i.e. it might be using simpler ada constructs... <Irvise_>stikonas: most likely. We are going to try with GCC 4.7, if not, 4.0. If not, even older. You can guess why we target those versions first :) <stikonas>"This means that new Zig language features had to be implemented twice". That's just not true... M2-Planet has been gaining many new features and we don't have to update cc_* compiler <muurkha>it's only true if you want to use them in the compiler <nimaje>they could freeze their stage0 to some subset and maybe update that from time to time <drakonis>isnt m2-planet written almost entirely in C? <stikonas>drakonis: m2-planet is written in fairly restricted subset of C, but it support far more, somewhat closer to C89 <stikonas>but there are some differences from C (at least for now) <stikonas>so pointer + 1 adds 1 byte to it rather than sizeof(pointer) <stikonas>which is probably the biggest imcompatibility, the others are mostly the case of missing features 