<zimoun>in your real world example, do you use quasiquoting, unquoting and friend? I am reading PEG parser so I was thinking… I mean what is the advantage of the wisp reader macro over a parser? Except the wisp is here and the parser is dreaming with the invisible pink unicorn. <rekado_>zimoun: I don’t use quoting and unquoting, because all of the process payloads are shell scripts. <rekado_>they could be S-expressions but that’s a little too verbose. <rekado_>with wisp we have all of Guile at our disposal <rekado_>we don’t have to design any language features <rekado_>we just have a different reader that supports both indentation sensitive syntax and S-expressions (even in the same file) <rekado_>we also get proper source properties, which is necessary for good error reporting ***ChanServ sets mode: +o civodul
***civodul changes topic to 'GNU Guix in high-performance computing | this channel, it is logged: http://logs.guix.gnu.org/guix-hpc | https://hpc.guix.info'
***ChanServ sets mode: -o civodul
<zimoun>really cool the “platform” at PlaFRIM :-) What is funny: back in 2013, instead of going in Chile I hesitated to apply for resilient iterative linear solvers with HiePACS’s folks. So life seems to have its own fixed points: instead of watching seminar about CI+Guix applied to solvers, I would be watching seminar about reproducible solvers with CI+Guix. :-) <civodul>the $GUIX_RULE he mentions is a loooong list of packages and transformation options <zimoun>I am thinking if GWL could be used to describe a “runner” feeding a Guix CI. <zimoun>It was quick so maybe it does not make sense. Basically, one idea is: GWL could replace ’gitlab-ci.yml’ Another is: replace the “run.sh” by a GWL workflow description and GWL produces this “run.sh” script. <zimoun>civodul: have you tried the tool used between the session to informally discuss during the breaks? <zimoun>civodul, my conclusion of the training: mixed feelings about tools on the Zay machine and their impact. <civodul>a participant mentioned "not picturing themself having Guix on their cluster" <civodul>perhaps the symptom of an image problem? <zimoun>yeah Spack, modules, ect. and how they are preparing the future of the Numrical Sciences (well, what I think the future should be :-)) <zimoun>to be honnest, since a MD in my lab is using Guix on Ubuntu and find it so awesome, I am really confident about usability (modulo corner cases and improvements). They even creates new R packages. :-) <zimoun>Well, after lunch, I am going to send you and Konrad the email we discussed months ago. Definitively, we have to organize a training/webseminar/user-feedback for French folks. Let’s make it! :-) <civodul>BTW, i liked the bit where the Jean-Zay person said that they disabled SSH port forward "for obvious security reasons", and thus, to allow users to run Jupyter, they developed a whole web frontend to essentially forward Jupyter <rekado_>civodul: hmm, “not picturing themself having Guix on their cluster” sounds like there is a perceived complexity in setting it up and maintaining it. <rekado_>or worse: the perception that it’s somehow “icky”. <rekado_>hard to say what exactly that could mean <rekado_>one thing that I think we™ should push hard is root-less installation <rekado_>that’s one bullet shot against Guix every time Spack and the lot make their pitch <rekado_>Singularity folks do that too when they advertise their setuid thing <zimoun>is it possible to share store with root-less install? <rekado_>the store is in the container, the daemon accesses it <rekado_>the only question is about the applications installed into the store; accessing them from the outside of the container would not work. <rekado_>applications to be executed outside of the container would need runtime remapping of /gnu/store to wherever/it/was/unpacked/gnu/store <zimoun>maybe I miss something, but to be able to share the store, whatever how it is accessed, you need a special user or group able to write in it. So you need root access to create at least this user or group. <civodul>rekado_: yes, there must be a perceived complexity in setting it up and using it, or perhaps it's a vague feeling that "it's not for HPC" <civodul>the Spack talk at the workshop talked at length about ISA optimizations, package cutomizations, etc. <zimoun>However, we talked about “sharing” store (via IPFS or whatever), so if each user store is readable by the world, instead of downloading from other user2 to add in user1 store, the download could be a symlink. And it ends with a forest of symlinks. :-) <zimoun>Maybe Guix is perceived as a bit “complicated” (unusual compared to habits) for CPU and there is not so much work on the GPU side, so it is also perceived as “complicated” (prepared the ground) for GPU. <zimoun>Well, I feel Modulefiles as C99, Spack as C++2003 and Guix as Haskell 98. :-) <rekado_>zimoun: if it happens inside the container then you can be whatever user you want to be. <zimoun>but the container needs root access to write, no? <rekado_>try “guix pack -RR -S bin=/bin” and unpack the result on any recent GNU system. The resulting binary just works, no matter where you unpack it. <rekado_>that’s because the executables are wrapped in a binary that essentially virtualizes file system access. <zimoun>that does not change, to be able to share between all the users, whatever what, you need a special user or group. So you need root access to create at least this user or group. But maybe I am missing something… <rekado_>there’s no need for a special user; the daemon socket just needs to be accessible by all users. <zimoun>but the daemon should be launched by root or a special user, right? <zimoun>hum, miscommunication I guess. :-) Well, I am just saying that it is not possible to install Guix for multi-users with shared store without having root access of the host machine. Somehow, there is always something requiring root privilege–for instance configuring the container on the host. And from my opinion, the target for multi-user machine is not root-less but ease the installation by (re)using common configuration <nixo_>Hi! Out of curiosity I wanted to try gwl (on guix), but there are a few things on the manual that I can't get to work <nixo_>Like: guix workflow web -p 8088 prints failed to load '8088': No such file or directory <nixo_>oh I guess it's still not released (after 0.2.1) <civodul>nixo_: it seems rekado_ has been making a lot of changes lately, so you might want to try --with-branch=master (literally or conceptually :-)) <nixo_>guix build --with-branch=gwl=master gwl: guix build: error: the source of gwl@0.2.1 is not a Git reference <nixo_>I'll have to do it conceptually instead <rekado_>nixo_: that’s right, there are quite a few changes in progress <rekado_>I’m still working on the next release <rekado_>--with-branch=master won’t work, because … well, a *lot* has changed <rekado_>it’s currently even depending on unreleased changes to Guix (memoized inferiors) <rekado_>at around the time of FOSDEM I’ll have a release ready <rekado_>and by the end of this week everything should be in order for a channel <rekado_>I want to add gwl-devel to a channel that is part of the repository <nixo_>Thank! No hurry for the next release, I'll wait :) <rekado_>… but right now I need to make some progress with my from-scratch kalimba build (from apple wood cut from the garden) <rekado_>thanks for your interest in the GWL! <rekado_>I hope I’ll be able to soon release something worth playing with :) *rekado_ —> to the basement <civodul>rekado_: re memoized inferior-package->manifest-entry, let's synchronize one of these days to see what to keep and all <nixo_>almost forgot to ask, is the example at tutorial #5 supposed to work with -c? I get /bin/sh: /tmp/file.txt: No such file or directory <rekado_>yes, this works. But probably not with 0.2.1 <rekado_>well, I’m currently working on exactly that <rekado_>once the files have been created in the container, they need to be copied out <rekado_>and that’s where we currently get undesirable nesting <rekado_>I just looked it up: the example has already been changed and the website contents need to be pushed <zimoun>rekado_: cool, I did not know what a kalimba is. Building your instrument for the next release song. ;-) <nixo_>rekado_: thanks for working on it