IRC channel logs

2022-02-10.log

back to list of logs

<zimoun>gi!
<zimoun>*hi :-)
<civodul>o/
<zimoun>thanks for the --news patch… I will give a look today, I hope. :-)
<civodul>heh, no rush!
*rekado_ tries to package torch for R
*zimoun says rekado_ is so adventurous :-)
<rekado_>it built just fine but then when I want to use it with ‘library(torch)’ it says ‘Failed to install Torch, manually run install_torch().’
<rekado_>it tries to write stuff to /gnu/store/…-r-torch-0.6.0/site-library/torch//deps
<rekado_>how disappointing
<civodul>blech
<civodul>that uses pytorch under the hood?
<civodul>if you have "module" users around you, now's a good time to try https://gitlab.inria.fr/guix-hpc/guix-modules
<rekado_>it uses just libtorch.so
<rekado_>maybe in the future we could build it without all the Python stuff.
<civodul>i think it's mostly C++ stuff though
<rekado_>I see
<rekado_>looks like I’ll have to use a more recent version of pytorch
<rekado_>I’ll try upgrading
<civodul>from 1.10.0 to 1.10.2, it should hopefully be easy
<zimoun>how can I generate an environment with musl instead of glibc for testing stuff? Basically, I would like to compare ’-lm’ where the maths lib comes from glibc vs musl.
<civodul>you could try --with-c-toolchain maybe
<zimoun>but I need to define a new toolchain, using make-gcc-toolchain eventually.
<civodul>s/eventually/possibly/ :-)
<civodul>yes, i don't think we have such a toolchain yet
<zimoun>From Collins dictionary, «eventually means in the end, especially after a lot of delays, problems, or arguments». So, that’s a good use, no? It is not something that «might happen» possibly but make-gcc-toolchain is something I have to use, at the end; from my understanding about “how to build a toolchain”, no?
<civodul>could be, i thought you meant "éventuellement"
<zimoun>Thanks for correcting. It helps me to improve. :-)
<civodul>:-)
<zimoun>rekado_: I am a bit lost with GCC. gcc-4.7 use gnu-build-system so after the core-update merge, then it uses the recent C toolchain (gcc@10 and glibc@2.33) and it would use a previous toolchain (from commencement I guess)
<zimoun>civodul: is it possible to build say gcc-4.7 using gcc-toolchain@7 at the CLI level? I fail to find the way…
<civodul>it should be "guix build gcc@4.7 --with-c-toolchain=gcc@4.8=gcc-toolchain@7", but i didn't try
<zimoun>hehe! Nope! 1/ gcc@4.7 is hidden and 2/ gcc@4.8=gcc-toolchain@7 raises the error «ERROR: In procedure string-append:»
<rekado_>crap, r-torch needs pytorch 1.9.0. I just finished building 1.10.2…
<rekado_>oh well, the upgrade built fine so I’ll push that and add a variant for r-torch.
<civodul>1.9.x is in the Git history
<rekado_>ah, great
<zimoun>civodul, with my “new” desktop machine using “unknown” Intel CPU, I am not able to build gcc-core-messbot0 for instance.
***Noisytoot_ is now known as Noisytoot
<civodul>zimoun: oh? could you report a bug?
<mbakke>zimoun: you are probably hitting https://issues.guix.gnu.org/41264
<mbakke>TL;DR: the guix bootstrap does not work on certain NVMe drives(!)
<zimoun>ah yeah, it looks similar. But the error seems different before or after the gexp new style.
<civodul>oh, that NVMe story rings a bell
<civodul>it's terrible
<zimoun>The Good is Guix is really really faster on it. ;-)
<civodul>that gives an idea of our involvement in programmed obsolescence
<zimoun>that’s The Ugly. ;-)
<civodul>i've spent a fair amount of the last 10 days on these issues...
<zimoun>The Bad (NVMe bug) or The Ugly (slow and programmed obsolescence) or both?