IRC channel logs
2021-09-17.log
back to list of logs
<zimoun>efraim: about #50582 and Julia Documenter, you sent only 2 over 4 patches. Is it expected? <efraim>I think the other 2 finally sent, and I sent another email with the 4 patches attached <zimoun>ah, ok sorry for the noise. I fall in the trap of emacs-debbugs thread. ;-) <efraim>it was giving me trouble before with actually accepting the emailed patches <civodul>so i'm trying Spack (!) in a container, just to see <civodul>and it's stuck in a loop, stat'ing spack/compilers/*.py <civodul>but i think that's because it wants a compiler in its environment <zimoun>civodul I get this «SWH vault: failure: Internal Server Error. This incident will be reported.» when trying to fallback instead of Savannah. Oups! <civodul>zimoun: oh! you might want to let'em know on #swh-devel <civodul>or try again in a few minutes, in case they're restarting services or something <civodul>any Spack user here? don't be shy :-) <zimoun>civodul, it is ~24h that I am trying. :-) <civodul>oh, perhaps give them the URL so they can test <zimoun>yeah work in progress on #swh-devel :-) <civodul>ok, on an HPC cluster with CentOS (the very target of Spack), i got as far as... <civodul>"configure: error: C compiler cannot create executables" <civodul>on the cluster, i did it the "normal way" though <civodul>but it apparently picked a compiler that doesn't compile or something <civodul>i guess i'll keep using Guix, after all <rekado_>I heard Guix is a fork of Nix, and it does not work on actual hardware. Have you tried Nix instead? <civodul>i heard Nix is not as convenient as CONDA though, especially for bioinfo (i'm not into bioinfo, but still) <zimoun>i head Conda is not as convenient as Modulefiles though, especially for non-python stuff <civodul>right, and modules can do -mtune=native, which makes software blazingly fast! <rekado_>we’ve had real trouble with a group here that stubbornly refused to use Guix. And when they started because they couldn’t build the thing manually they mixed that one Guix package with a whole bunch of Conda and artisanal hand compiled packages. <civodul>handcrafted vs. industrial packages, in a way <civodul>i can imagine the pain that ensued for everyone involved <rekado_>for months they would get really angry, blame all problems on Guix, and then suddenly asked us to ‘fix Guix’, because the compiler doesn’t work. <rekado_>we first heard from them when they demanded we fix Guix. <rekado_>it was then that I bought some new tools for the garden and lost myself in a daydream of leaving computers behind for good. <civodul>look, you're blaming computers when the real issue is elsewhere: users <rekado_>We’ll probably offer short monthly Guix intros again. <civodul>do you plan to be around on the 27th? <rekado_>I get the desire to not admit to have been defeated by software and its quirks. But the impulse to blame something you don’t understand is something I hope to eradicate with these intros. <civodul>often, people would need more general intros to GNU/Linux, the shell, and all that <rekado_>we used to combine these trainings, but it was too much. <rekado_>the participants were not able to remember the important bits, because everything was too new and foreign <rekado_>so this time I’d like to focus on just the basics, together with some important reminders (don’t try to mix things, don’t use LD_LIBRARY_PATH, etc) <civodul>rekado_: yeah, focusing on do's and don'ts may be more efficient <civodul>someone told me being put off by the fact that the Guix manual "tries to explain things", as opposed to just giving copy/pastable recipes <zimoun>Read somewhere « I installed these compilers with "apt install" on debian11, the exact version is: intel-oneapi-compiler-dpcpp-cpp 2021.3.0-3350 » Arf, source version is different from binary version… <civodul>i'm writing a post on "packages", pip, CONDA, etc. and using PyTorch as an example <zimoun>civodul, you are demoing Guix-HPC on Fri., 12th. Cool! You are everywhere. :-) *civodul has too many commitments <civodul>i was hoping they'd wait before making it public because i'm not going to use Zoom <dstolfa>civodul: i like the post, it reads well. i just wish there was an easy way to get this message out to the public and have it show up in places <zimoun>civodul: haha! Good luck… I got as an answer: it works on linux too via webbrowser, so what is the issue?!? BTW, Univ. Paris officially recommands to use Zoom for meeting. Pffeww! <civodul>dstolfa: thanks for the quick feedback! <civodul>re getting this message out, i think we'll just have to repeat ourselves <civodul>and to join forces with others projects that share the same goals, such as Debian <civodul>they have been saying this for decades, in fact <dstolfa>civodul: yeah. i also thing we could maybe try and get these things out to hackernews and lobsters as an initial thing, but maybe we could do a better job at bringing it up during discussions at our respective workplaces/universities so people think about these issues and naturally run into guix <zimoun>dstolfa, yeah! Except, people think about these issues but then avoid to fix them because it changes too much their current habits. As civodul said earlier today: «often, people would need more general intros to GNU/Linux, the shell, and all that» <drakonis>hn itself is starting to ride the wave right now <drakonis>to entice the average hn/lobsters reader, the posts would require something extra <drakonis>as they're most likely going to ask themselves why would they prefer to use guix over nix or anything else <civodul>notice that it's not about Guix vs. Nix <civodul>but there are hints in the intro, when referring to bootstrapping, etc. <drakonis>but it has acquired most of the mindshare recently <civodul>"most of"--CONDA acquired more of the mindshare, no? ;-) <civodul>right, we've been saying for ages that we should do a Nix vs. Guix post <civodul>actually, we reach that conclusion every time a HN thread goes in that direction <civodul>drakonis: i thought you were talking about this post in particular <drakonis>what would such a post entail anyways? explain the differences between nix/nixos/nixlang and guix/guix system/guile? <drakonis>rather, wouldn't it be better to explain how guile can be used to do more without needing to hand off to shell or extra language dependencies <drakonis>that said, to entice the average user, there's not much of a requirement to entice the average user beyond providing a kitchen sink of packages and services at this point <drakonis>its pretty much just lots of packages and services plus being up to date with frictionless development environments <drakonis>ah yes, almost forgot, hardware enablement is also a thing they want <drakonis>civodul: if you'd like to draft a guix vs nix post, i could get you up to speed to some recent changes <civodul>this kind of comparison is not just technical though <drakonis>i'm also going to get onto the philosophical differences with how the ecosystem works nowadays <civodul>actually you may be in a better position than myself to write such a post :-) <drakonis>haha, i might try to write something and get it proofread <drakonis>i should link to guix-explorer as an example of how guix's guile libraries can be reused <drakonis>hmm, it should be correct to say that invoking guix libraries is analogue to nix-shell, yeah? <civodul>drakonis: it depends, but in general it's not quite analogous <civodul>one can access everything from Scheme in Guix (or almost) <civodul>whereas in Nix you'd need a mixture of Nix, C++, Perl, Bash, Python, C, and whatnot <drakonis>almost everything, except when its necessary to interface with C i suppose <drakonis>i'm asking about it because one of the main departures since guix came into existence is that nix-env is no longer encouraged for usage <drakonis>these days its only useful if you're not running nixos and even then, its highly limited <drakonis>anyways, its been a little while since i've last written markdown, so pardon any mistakes <drakonis>i'll definitely need some help with thickening the post, as writing isnt my strong suit <rekado_>civodul: ‘our users can see the source code that correspond[+s] to the code’ <rekado_>‘that those binaries correspond to the source code they [-pretend][+claim] to match.’ <rekado_>(unless that’s meant as a sarcastic play on ‘few’) <rekado_>I needed three attempts to understand this sentence: ‘Not providing those libraries or providing a variant that is not binary-compatible with what `libtorch_cpu.so` expects is the end of the game.’ <rekado_>‘end of the game’ –> ‘Game Over’, ah! Took me a while to make the connection. <rekado_>I’d also suggest to update the URLs to specific commits instead of just ‘…/master/…’ because the contents will eventually change (while the blog post won’t). <rekado_>‘if some of the packaging implicit assumptions are not met’ –> ’if some of the implicit packaging assumptions are not met’? <rekado_>‘deploy a [-software] complex software stack’ <rekado_>this sounds like something is missing: ‘—look what’s inside and which may not be immediately obvious.’ <rekado_>‘It[+’s] a step backwards several years in the past,’ <rekado_>perhaps it would be good to reiterate at the end that pytorch can now be installed via Guix <rekado_>you show that it can be installed with pip in seconds; might as well mention that now it can be installed in a verifyable and reproducible fashion with Guix, also in mere seconds.