<atheia>I've literally just started experimenting as a result of your messages
<atheia>For me, as long as the modules I want to use are part of the geiser load path, C-c C-m works to provide access to the procedures imported by that module and the procedures defined in that module.
<atheia>So I've just added some convenience keybindings to my projectile hydra (both great emacs packages) that from now on allow me to a) add the given project that I'm working on to Geiser's load path b) load the current buffer as a module in Geiser and switch to the REPL
<rekado>I have access to the procedures but they don't seem to have access to procedures in other modules.
<thomasd>And what if one wanted to use (I hardly dare say it out loud) intel compilers?
<efraim>I assume you'd have to package it yourself
<thomasd>Probably one would have to (somehow) wrap the intel compilers in a Guix package. It's probably a bit opposed to Guix' goals, but quite a few HPC uses might be interested.
<thomasd>I started to wonder after I read a comment by the author of Spack, that systems like Guix don't help the user to create their own variations of packages. I'm thinking it's not actually that hard.
<efraim>its not too hard to copy elements from an existing package if you don't know how to make the modification
<efraim>its much easier to "repeat the build steps" if the whole process is just `guix package -u'
<efraim>I need to send some of my packages upstream, it turns out I have 16 packages locally
<rekado>thomasd: do you mean replacing the compiler for every package?
<thomasd>not necessarily for every package, but perhaps for a number of them
<rekado>we have "guix build --with-input=PACKAGE=REPLACEMENT", which could be extended to also replace implicit inputs.
<rekado>right now overriding the inputs that are added by the build system is not possible on the command line.
<rekado>but you could write a procedure or a macro that takes a package and replaces any one input with another.
<thomasd>specifically with intel and their math libraries, I believe you can run into issues combining libraries built with intel and packages built with GNU, I believe. For such scenarios, it would be nice if you could semi-automatically define variations on existing packages.
<efraim>i guess you could replace gcc in the gnu-build-system with intel's compiler
<rekado>or create a new build system and then define a macro to override the build system for a given package.
<efraim>that'd be better, if you changed everything with gnu-build-system you'd have to fix the bootstrap process
<thomasd>Yes, defining such a build system sounds like a robust solution.
<eus>quiliro: However, for an unknown reason, during some binary substitute downloads, my wireless connection lost the capability to resolve hostname.
<eus>quiliro: Due to "--fallback" option, guix tried to build from source. Building from source ended up with failure.
<eus>quiliro: Finally just today, after "guix pull", I did "guix system init /mnt/etc/config.scm /mnt". Without "--fallback" option, whenever the DNS resolution failed, I simply repeated "guix system init /mnt/etc/config.scm /mnt" until all of the substitutes got downloaded.
<atheia>Also, in theory, from a newbie experience: Normally a stable release guarantees a usable system -> a newbie will not be faced with some substitute not being available for their architecture or some such.
<quiliro>alezost: i can see the whole screen covered with different packages
<alezost>yes, the question is: are these packages going to be downloaded or built. You can pipe that command to see its full output: "guix system build --dry-run --no-grafts /mnt/etc/lightweight-desktop.scm | less"
<alezost>if most packages would be built, it means something is wrong on your side. If only several packages would be built (and most downloaded) then it's likely that hydra doesn't have these substitutes
<quiliro>and i can see gcc compiling some packages
<alezost>quiliro: ok, to make it clear: hydra often does not provide substitutes for the latest packages (because they have not been built yet). It's your choice to decide if you will build them locally or not. (I usually prefer to wait until hydra build what I need)
<quiliro>alezost: i choose to use the substitutes for all packages even if there are new packages that have no substitutes
<quiliro>but i do not understand why it is compiling if i do not use --fallbaack
<quiliro>read the spacefm developer's blog about systemd
<lfam>I also like how simple the services files are compared to sysvinit shell scripts — you don't need to be an experienced Unix or GNU / Linux person to write them.
<adfeno>As for the guix-daemon Upstart service, I'm reading some answers that say that one can simply use the export command as one does normally.
<lfam>I'm not surprised that all the major distros decided to use it. And, by making the switch, they are more prepared to switch again if Red Hat does something terrible, although I don't really see a danger there.
<quiliro>lfam: the manual sugest so in "proceeeding with installation", section 7.1.4
<lfam>On the other hand, we are using our own init / service manager, the Shepherd, so we are blissfully free of this debate :)
<adfeno>On guix-daemon Upstart service file again...
<adfeno>... Now I see a possible issue: The part which talks about export the specific locale variable for Guix uses $HOME inside... when evaluated by guix-daemon, will it take $HOME as "/root"? Or as "/home/user"?
<lfam>It should be root, since root runs the guix-daemon