<kyamashita>I'm sure people can eventually code golf the finished implementation.
<OriansJ>kyamashita: possibly and the work this week involves building its first compiler
<OriansJ>also, I'm waiting on Janneke's feedback on how I can improve my lisp to better bootstrap his MES compiler
<kyamashita>Software development is still young, I'm sure we'll make the Maxwell's Equations of Software better over time. Right now, making bootstrappable and reproducible software is difficult enough.
<OriansJ>kyamashita: actually it is trivial to do given the constraints of the VM used in Stage0 because it becomes impossible to add any randomness.
<OriansJ>You have a program rom, a source file and a destination file and every single instruction is perfectly deterministic
<kyamashita>But you started the project with that in mind (and thank goodness you did). Not all projects do that, as many patches in the Guix tree indicate.
<OriansJ>kyamashita: sadly true, I honestly can't imagine why people shove things like time stamps and random garbage into their programs
<OriansJ>Yeah, I get malloc is slightly faster than calloc and when file systems didn't support time stamps your build system might need to shove it into the binaries
<OriansJ>but aside from legacy reasons, could there even be an excuse for that behavior anymore?
<kyamashita>I'm not sure, as I am the evern00b. However, I imagine there are plenty of places to stick metadata these days.
<OriansJ>kyamashita: you are absolutely right but how much metadata does one really require in a binary program?
<kyamashita>Maybe projects could supply a "--build-reprodicibly" flag or something like that if they want metadata in the code by default.
<OriansJ>kyamashita: having thought about that for a bit; I don't think there is any valid technical reason, when given a specific compiler, source code and build command that the result shouldn't always be identical. That being said, only defects/variations in the compiler, build command or source code should change the outcome. Since guix allows us to perfectly always use a specific compiler, exact source code and build command, the remaining
<OriansJ>reproducibility bugs have to do with the source code interacting with non-deterministic defects in the tools themselves.
<OriansJ>The places I most find non-deterministic behavior are: floating point, when malloc is used instead of calloc, using randomness from outside sources (say reading from /dev/urandom) or performing fuzzy optimization tricks (the dumbest idea in the history of compilers if you ask me) for a 1-3% performance boost under ideal conditions.
<kyamashita>OriansJ: Interesting that you bring up floating point. I haven't thought about that before.
<OriansJ>kyamashita: haven't you noticed that x86 implicitly converts 32 and 64 bit floats to 80 bits and rounds it back for storage?
<OriansJ>it is a side effect of the design of the x8087 coprocessor
<kyamashita>OriansJ: I read recently about something like that.
<kyamashita>I need to read some CPU and instruction set manuals.
<OriansJ>kyamashita: There are even weirder rounding rules when you get into IEEE floating point support
<efraim>is that why we sometimes have rounding errors in math libraries for non-x86_64 architectures?
<OriansJ>There have been cases where minor variations floating point hardware and ordering make results order of magnitude different.
<OriansJ>efraim: It could definitely be the cause, as floating point is the best performance way to deal with large/tiny numbers
<marusich>I have no idea why, but the result is that programs like youtube-dl won't save files with non-ASCII characters, which is super dumb because my locale is en_US.utf8 and thus it can support all Unicode characters!
<marusich>Does anyone know why something like this might happen? It's very frustrating.
<roptat>also 1.0 is not compatible with the gpl, but the software still has a double license
<marusich>Regarding my earlier statement, it seems this might be some kind of regression in youtube-dl.
<marusich>I still don't quite understand how Python is getting its locale information, but it seems an older version of youtube-dl does not exhibit the problem I'm experiencing, so it must be a regression.
<ofosos1>efraim: it appears to do it, i'm going to have some ice cream :)
<ng0>does someone use gajim here? would you know if there is something not obvious to keep in mind when you install the extensions systemwide with a package manager? is the very obvious thing I fail to see that gajim needs to know about the paths?
<ng0>i started with a "catch them all" package for guix as there's a reported upstream bug for the single extension tarballs
<ng0>because they are not getting picked up I think there mustr be some way to communicate their store path to the parent package, gajim
<piotr>I'm trying to boot from the USB stick. I've followed instructions in the manual. Everything goes smoothly and at the end I get a partition named "gnu-disk-image" with flag "boot". Sounds good. When I mount it it's a classical GNU / Linux root however when I reboot the key isn't recognised by my laptop so I'm unable to install it :'( Any ideas how I could solve that?
<Gamayun>Could just be a funky bios if everything else looks good. I have a netbook that will only recognise images on about half my usb sticks.. :/
<sapientech>trying to use offload facility, got to `guix offload test ~/.machines.scm` but getting: guix offload: error: failed to load SSH private key from '/home/sapientech/.ssh/id_ed25519': Unable to import a key from the file
<sapientech>this is the ssh key i use to connect to the build machine