Re: Reproducible environments

Hi Pjotr, First of all, thanks for your explanations! > At this point (correct me if I am wrong), the route to take is to > checkout a commit of the Guix source tree (with packages). The SHA > value is captured on Hydra in the build itself. That is the only way > to fully reproduce GUIX as a

Reproducible environments

Hi everyone, I am exploring the use of Guix for reproducible environments in scientific computing. My goals are very similar to those described in the paper "Reproducible and User-Controlled Software Environments in HPC with Guix". Section 4.1 of that paper says that a given environment,

Viewing the Guix manual in Emacs under Guix

Hi everyone, I have just set up a virtual machine for test-driving Guix as a software development and deployment tool in scientific computing. I found the Guix SD to be a bit too minimal for my needs, so I started from a minimal Debian 8 system and added the Guix package manager. I haven't

Problem with Hydra?

Today's "guix pull" ended with an error when downloading a file from Hydra, which I then confirmed using wget: $ wget https://mirror.hydra.gnu.org/nar/96fy8dgs9p818zi63ypqw83xp10myi5a-psutils.tar.gz --2017-01-10 16:59:26--

Re: Problem with Hydra?

Hi Ludovic, The problem is that mirror.hydra.gnu.org was serving a zero-length file. This is fixed now. Indeed - I am up to date again! Thanks, Konrad.

Re: I can not run 'guix pull', how to deal with

On 07/05/2017 11:36, Ludovic Courtès wrote: guix pull: error: build failed: some substitutes for the outputs of derivation `/gnu/store/d1qkv7x8ayi75qjlg7d5j5g1h7y4fl5p-make-boot0-4.2.1.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source

Re: How do I fix a messed-up Guix?

On 16/05/2017 15:02, Konrad Hinsen wrote: I ended up rolling back until my profile no longer contained "guix" (I have no idea how I could ever produce such a profile), so now I am completely stuck. Any idea for getting out of this mess? I forgot two details: - I tried building pyt

How do I fix a messed-up Guix?

Hi everyone, since ¨guix pull" failed (see a recent message), I tried various ideas for getting back to a useable guix installation: - Build from a git checkout. Unfortunately, I cannot do "guix environment guix" anymore (like "guix pull", it tries to download python-2.7.12 and fails due

Re: How do I fix a messed-up Guix?

Hi Julien, You could probably use the other user's guix version. Copy ~otheruser/.config/guix/latest to your own user's .config/guix, and try to guix pull from that. That won't mess with the other user's profile. Thanks, that helped, though not directly: the other user didn't have

NFS mounts

Hi Guixers, does anyone have an example of a system configuration that mounts an NFS share at boot time? It seems that this requires some extra services and also some additional packages (to have mount.nfs for example). Konrad.

Re: NFS mounts

Hi Ludo, > Indeed, the initrd would need an extra package, like this: ... > Can you try if it works? I will! However, I am almost sure that this is not sufficient. For a first test, I installed nfs-utils for manually mounting my NFS share. It fails because the daemon rpc.statd is not running. I

Re: Guix on macOS

On 13/10/2017 14:55, Ludovic Courtès wrote: At the same time, one could hope that, if freedom is not enough, the nifty features of GuixSD, GNOME, the GNU toolchain, etc. would be enough of an incentive to switch. But hey, it’s complicated! There are those nasty real-world constraints,

Re: Guix on macOS

On 13/10/2017 14:55, Ludovic Courtès wrote: If macOS had a similar feature, that’d be perfect: we wouldn’t have anything to do. Perhaps Docker-for-Mac actually provides something close to that? I really don’t know. Docker for Mac uses the macOS user-space virtualization facilities (via

Re: Guix on macOS

On 12/10/2017 05:29, Chris Marusich wrote: But before I begin, I wanted to know: has anyone done this already? Is there interest? Interest, yes, from at least one more person: me. But I suspect this is a really big effort, in particular to boostrap the whole system based on Apple's XCode,

Re: NFS mounts

Hi Ludo, > Indeed, the initrd would need an extra package, like this: > > diff --git a/gnu/system/linux-initrd.scm b/gnu/system/linux-initrd.scm ... > Can you try if it works? It compiles, and I can boot the new configuration without any trouble. Next, I added an NFS filesystem:

Adding a network interface

Dear Guixers, I have started to play with GuixSD in a virtual machine, but I quickly got stuck. My starting point is the supplied "bare bones" setup, which works fine with only trivial modifications such as the disk device name and the user accounts to be created. My virtual machine has two

Re: Scope of support for Guix on other distros

On 02/10/2017 11:18, David Seaward wrote: To what extent is support for other distros a priority for the Guix project? In other words, explicitly planning to make Guix available as an alternate installation source on non-Guix-SD distros. That's already possible right now. Go to the download

Re: Adding a network interface

Hi Ricardo, Thanks for your reply! > This works for me. I have configured berlin.guixsd.org with two network > interfaces by simply providing static-networking-service twice. I’m not > removing any services from %base-services: > > (services (cons* … > (static-networking-service

Re: Changing HTTP proxy settings in GuixSD

Hi Chris, > That error looks suspicious. Perhaps you already know this, but it > probably means that the string "mirror.hydra.gnu.org" wound up being > used where a procedure should probably have been used instead. For > example, in your Guile REPL, you can reproduce this kind of error like >

Building from a local source code checkout

Hi everyone, For debugging package definitions, it would be really nice to be able to build a package from a checkout of the original project source code, rather than having to make a tarball for each modification of that source code. Is this possible somehow? The manual suggests that a

Re: Building from a local source code checkout

Hi Ludo, >> For debugging package definitions, it would be really nice to be able >> to build a package from a checkout of the original project source >> code, rather than having to make a tarball for each modification of >> that source code. Is this possible somehow? > > You should be able to

Re: Changing HTTP proxy settings in GuixSD

Hi Ludo, > I’ll update the ‘guix’ package soon so that this change is available to > daemon-side code such as ‘guix substitute’. In the meantime you can run > the daemon from a checkout: > > sudo -E ./pre-inst-env guix-daemon … That works fine - thanks! Konrad.

Re: NFS mounts

Hi Ludo, > By default, file systems are automatically mounted at boot time. To > avoid that, you must add: > > (mount? #f) That works well indeed. But I actually want that NFS filesystem mounted at boot time, ideally (not strictly required though). Of course, the real problem is that I

Re: Changing HTTP proxy settings in GuixSD

Hi Ludo, A quick workaround would be to do something along these lines: # herd stop guix-daemon # http_proxy=… guix-daemon --build-users-group=guixbuild # guix system reconfigure config.scm where config.scm has the relevant proxy configuration of in ‘guix-configuration’. Would that

Re: NFS mounts

l...@gnu.org (Ludovic Courtès) writes: >> Of course, the real problem is that I cannot mount it at all because >> rpc.statd is missing. > > Ooh, got it. Well we could (ab)use the ‘dependencies’ field of > ‘file-system’ to introduce a dependency on the rpc.statd daemon startup. Is there a

Re: Building Docker images of GuixSD

Hi Chris, I've run GuixSD in a Docker container and returned to tell the tale! Congratulations! And thanks for exploring all this. > Is this helpful? Is it worth polishing up and maintaining? I'm not > entirely sure, and I'd like to know what you think. I think it is useful, mainly for

Re: GNU Guix & GuixSD 0.14.0 released

On 07/12/2017 13:45, Ludovic Courtès wrote: We are pleased to announce the release of GNU Guix & GuixSD 0.14.0, representing 5,192 commits by 88 people over 6 months. Congratulations and thanks to all contributors! The more I use Guix, the more I appreciate its qualities, but also the

Re: Building from a local source code checkout

Hi Carlo, > On 20 December 2017 9:19:00 pm AEDT, Konrad Hinsen > <konrad.hin...@fastmail.net> wrote: >> > guix build python-activepapers >>--with-source=~/Development/python-activepaper >>guix build: error: lstat: No such file or directory: >>"~/

Re: Dealing with language bindings for libraries.

On 09/05/2018 17:21, Fis Trivial wrote: An ideal scenario would be the one that we can specify multiple outputs for one packages, each output corresponds to one language binding, and we can specify different dependencies and build system for each output. Is there any chance we can do that in

Re: Dealing with language bindings for libraries.

On 09/05/2018 20:00, Julien Lepiller wrote: We already have such a case: capstone and python-capstone. There is no redundancy since python-capstone knows how to load the shared library created in the capstone package. So we have two packages, with the same My situation is a bit different. The

Re: “Tarballs, the ultimate container image format”

On 17/05/2018 07:53, Chris Marusich wrote: Great article! Thank you for sharing it. The manual is nice, but I have to admit, I enjoy reading these blog posts quite a bit, too. It's nice to read a brief article that's focused on introducing a specific aspect of Guix, with cross-references for

Re: Python 2 retirement — what should Guix do?

Leo Famulari writes: > I wonder, what should Guix do? > > Personally, I think our set of Python packages is relatively hard to > maintain. There is a lot of brittle code in there. I'd be happy to drop > our policy that Python libraries have both Python 2 and 3 packages by > default. I expect

Changing HTTP proxy settings in GuixSD

Hi everyone, I wonder if anyone else has had the problem I describe below and knows a solution. I am running GuixSD in a virtual machine on a laptop that I use in different network environments. One of them requires the use of a HTTP proxy, direct accesses being blocked. As a consequence,

Re: Hacks to install Guix packages without root

On 26/10/2017 23:46, Ricardo Wurmus wrote: How about an extension of “guix pack” that will rewrite the /gnu/store references to a user-provided directory before bundling things up in a tarball? I’d *really* like to be able to just use the tarball bundle “guix pack” produces by default, but

Re: NFS mounts

Hi Ludo, > Could you test it in a VM, pass “console=ttyS0” as a kernel argument, > and “-serial stdio” so that we see all the messages on the console? It took a while, but here it is. My config.scm is attached as well. Konrad. config.scm Description: Binary data guixsd-console.log

Re: [RFC] A simple draft for channels

On 24/01/2018 13:33, n...@n0.is wrote: In my honest opinion: No. We can not prevent this. All we can do is to provide a list of *official* channels. Beyond that I don't think we should try to regulate what's in an unofficial channel and what's allowed. +1 The best option in my opinion is to

Re: Can we speed it up? Prev: compiling guix is too slow?

Pjotr Prins writes: >> I wonder if anyone has analyzed the dependency graphs of software >> packages (not necessarily for Guix, some big distribution like >> Debian would be more interesting), with the goal if identifying good >> splits based on simple criteria. > >

Re: Can we speed it up? Prev: compiling guix is too slow?

On 05/02/2018 08:34, Pjotr Prins wrote: compiled yet). Or generate a meta list for a source tree. Or subcategorize packages so only those packages get included that are asked for (assuming there are no deeper dependencies). For example, few people need the bioinformatics packages. We could have

Re: Use guix to distribute data & reproducible (data) science

Hi everyone, zimoun writes: > From my point of view, there is 2 kind of datasets: > a- the ones which are part of the software, e.g., used to pass the > tests. Therefore, they are usually small, not always; > b- the ones which are applied to the software and somehow

Re: Do you use packages in Guix to run neural networks?

On 14/02/2018 05:43, Fis Trivial wrote: Sorry for bothering with a completely unrelated topic. I'm curious do you train neural network with packages in Guix? Or did you packaged related libraries yourself? My needs are modest, all I use is the multilayer perceptron from scikit-learn, which

Why don't "guix pack" and "guix environment" accept manifests?

Hi everyone, Today I tried to convert one of my Guix profiles into a Docker image, and naively tried guix pack -f docker -m my-manifest.scm Now I know it doesn't work, but I wonder if there is a good reason or if this is just not implemented? The same question applies to "guix

Re: Use guix to distribute data & reproducible (data) science

Hi, > In other words, on the paper, what are the benefits of a management of > some piece of data in the store ? For example for the applications of > weights of a trained neural network; or of the positions of the atoms in > protein structure. Provenance tracking. In a complex data processing

Re: Use guix to distribute data & reproducible (data) science

Hi George, myg...@gmail.com writes: >> The three missing pieces are: >> >> - Dealing with measurements, which might involve interacting with >>experimental equipment or databases. Moreover, since data from >>such sources can change, its hash in the store must be computed >>from the

Re: Building from a local source code checkout

l...@gnu.org (Ludovic Courtès) writes: > I agree the matching-name constraint can be annoying. The alternative > would be allow the user to (optionally?) specify the name of the package > whose source is being changed, as in: > > guix build python-activepapers \ >

Re: Outreachy'18

On 06/03/2018 20:34, Reshu Singh wrote: I am trying to install GUIX for ubuntu using sh script. I have named the script "guix-install.sh".I created the sh file in nano and ran using bash guix-install.sh Encountering an error "guix-install.sh: line 249: /home/reshu/.guix-profile/etc/profile:

Re: installing python 2 and python 3 in the same profile

Ricardo Wurmus writes: > It is an unnecessary restriction to *prevent* users from installing > Python 2 and 3 interpreters into the same profile. Any errors we see I agree. But the current question is not if we should allow people to shoot themselves into the foot, but how

Re: installing python 2 and python 3 in the same profile

On 10/03/2018 09:34, Pjotr Prins wrote: It still works with ad-hoc environments, but manifests containing both Python versions cannot be instantiated any more. This is too strict, because we know that these two variants don’t cause conflicts. That is not my experience. Any mix is a problem.

Re: installing python 2 and python 3 in the same profile

On 14/03/2018 12:39, Hartmut Goebel wrote: Am 13.03.2018 um 22:52 schrieb Ludovic Courtès: 2. Use different package names when we know things can be parallel-installed: “python2” vs. “python” (I’m talking about the package name, not its version string.) That’s what distros

Re: installing python 2 and python 3 in the same profile

Ludovic Courtès writes: > Yes. OTOH we use the “python2-” prefix for 2.x packages and “python-” > for 3.x packages. Indeed. What a mess! >> This does of course raise the question of how this will evolve in the >> long run, but since so many bad decisions were already taken, I am

Re: Meetup in Paris, Dec. 10th!

Am 11.10.18 um 15:55 schrieb Ludovic Courtès: I’ve booked a room at Inria’s offices in Paris for the Dec. 10 gathering I proposed a while back, see: Great! At what time does it start? A couple of notes: the room capacity is 16 but I’ll look for a larger There's actually plenty of space

Re: Meetup in Paris, Dec. 10th?

Am 27.09.18 um 14:01 schrieb Ludovic Courtès: Some of us will be in Paris, France, for the Reproducible-Build Summit¹, December 11–13. I was wondering if people would be willing to gather, say, the day before the summit (December 10) to discuss Guix things and/or have hack sessions. Who’s in?

Re: the upcoming Great Python2 Purge™

On 26/12/2018 10:38, Efraim Flashner wrote: We're now about a year out from the official EOL for python2 (Jan 1, 2020). So far we've been not adding python2 variants of packages that are new unless they're actually needed for something. Do we want to start removing python2 packages when updating

Re: Happy birthday!

On 23/11/2018 14:41, Ludovic Courtès wrote: Today, it’s been six years already! Let's have a party then: (define-public guix-birthday-cake   (package     (name "guix-birthday-cake")     (synopsis "A birthday cake for Guix")     (build-system birthday-cake)     (arguments

Re: the upcoming Great Python2 Purge™

Hi Ricardo, > Konrad, going forward it might be reasonable to keep copies of required > Python 2 packages in your channel. We aren’t going to remove Python 2 > packages now, but in the future we may not be able to fix unmaintained > packages and may have to remove them. "My channel" doesn't

Re: the upcoming Great Python2 Purge™

Efraim Flashner writes: > I checked 'guix refresh -l python2' and I got a list of the python2-* > packages which are leaf packages. I'm not suggesting that we right now > get rid of them, but it seems to me something worth keeping an eye on. Please be careful with "leaf packages". The leaves of

Re: the upcoming Great Python2 Purge™

Hi Ricardo, >> "My channel" doesn't exist (because I haven't yet found the time to >> figure out how to set up and manage a channel, although it's been on my >> to-do list for a while). > > I’d be happy to assist. Thanks! I might come back to that offer when I find at least enough time to figure

Re: Lightning talk at IPFS camp

Hi Pierre, > I'm going to the IPFS camp (https://camp.ipfs.io/) on June 27th and I've > been asked to give a (5 minute) lightning talk about IPFS & Guix. Yaik! :) That sounds like a great opportunity. Guix and IPFS are in my humble opinion two of the most interesting ongoing projects in the

Re: Lightning talk at IPFS camp

Ludovic Courtès writes: > (They could have chosen Guile instead of a custom Lisp, but that’s an > “implementation detail”. :-)) >From my reading of the whitepaper, no. They have pretty strict constraints on their language because they send live code updates to running instances and want to be

Re: Lightning talk at IPFS camp

Ludovic Courtès writes: > Hey! > > I stumbled upon this: > > https://github.com/ipfs/package-managers#readme And I just stumbled on this one: https://github.com/ipfs/roadmap Quote: 2019 Priority We will be focusing our efforts into a single (lazer focus) priority.  Package

Re: Lightning talk at IPFS camp

Am 03.06.19 um 18:19 schrieb Pronaip: - All data comes with provenance tracking: - computations are tracked via Guix - human input is logged (interactivity) or version controlled unless you vision of the distant future somehow also includes most social problems having been

Re: Lightning talk at IPFS camp

Pierre Neidhardt writes: >> - A unified way to refer to stuff (I am thinking of IPLD here) >> No more tarballs, git commits, etc. CIDs everywhere. > > Do you have a concrete use case? I was thinking of the Guix package definitions. In the long run, assuming IPFS turns out to

Re: Lightning talk at IPFS camp

Pierre Neidhardt writes: >> I was thinking of the Guix package definitions. In the long run, >> assuming IPFS turns out to be reliable enough, we could put all source >> into IPFS with a CID reference, rather then today's many ways to >> download source files. > > There would be nothing special

Re: Down with PYTHONPATH!

Hi Pjotr, > It would be interesting to see how others solve this problem. > Including Nix and Conda. Conda uses the same approach as Python's virtualenv: create a seperate Python installation made up mainly of linke to files shared with other such installations. We could probably do something

Re: Down with PYTHONPATH!

Hi Ludo, > How does virtualenv work, if not by setting PYTHONPATH? It creates a new filetree corresponding to a complete new Python installation, and the uses soft links to share most of the actual files with the parent installation. > Setting up an environment all about augmenting the search

Re: syslogd can't be started when running Guix in Docker

Maxim Cournoyer writes: > I'm happy to read you could successfully make it work! It's strange > that you had that issue though! By now I have a system that starts all services without failure. I got there by increasing the timeout to 30 s everywhere (compared to the default value of 5). Perhaps

Re: syslogd can't be started when running Guix in Docker

On 03/07/2019 10:12, Konrad Hinsen wrote: All this suggests that perhaps the problem is not with syslogd, but with shepherd wrongly concluding that syslogd failed. Looks like I will have to dig a bit more into shepherd :-( My hypothesis turned out to be correct: increasing the timeout

Increasing the timeout for shepherd services

Hi everyone, When running Guix in a docker image, I get systematic failures for starting several services: syslogd, nscd, openssh. It turns out that in all these cases the daemons are started, but so slowly that shepherd declares a failure before they are fully operational. I managed to fix this

Re: Increasing the timeout for shepherd services

Hi Ludo, > ‘read-pid-file’ in the Shepherd has a hard-coded default value of 5 > seconds. You can change it for each service, but there’s currently no > way to change the default value globally. That's what I did: change it for each service. > The patch below adds a SRFI-39 parameter in the

Re: syslogd can't be started when running Guix in Docker

Ludovic Courtès writes: > Do you observe similar slowness with other Docker images—e.g., Debian > images? No. But I don't observe any slowness with Guix either. Once it's up and running, performance is normal (except for the known problem with access to macOS file systems). It's only the daemon

syslogd can't be started when running Guix in Docker

Hi everyone, I am exploring the possibility of running Guix under macOS via Docker. First I ran 'guix system docker-image` on a minimal system configuration, which I then transferred to the Mac and started. Overall it works admirably well. There are however a few services that don't work, in

Re: 01/01: services: Add ‘/usr/bin/env’ special file.

Hi Ricardo and everyone else, Using a custom script with a /usr/bin/env shebang is pretty common. You don’t need to be a power user for that, and certainly not a *Guix* power user. I definitely agree with this. In my work environment, it is very common for people to distribute shell or

Re: How to reference external program used in shell-scripts?

Ricardo Wurmus writes: > Hartmut Goebel writes: > >> Anyway: IMHO missing "dynamic binding" is one of the major drawbacks of >> functional deployment, as it requires updating (and esp. downloading) >> much more packages compared to a rpm/deb based system. > > At the same time static binding is

Re: Let’s merge ‘core-updates’!

Hi Ludo, Please try to upgrade your system and your user profile to see if anything’s wrong for you (I did that a few days ago and I’m happy!). It mostly works fine for me, except that the build of next-gtk-webkit fails (which works fine on master). The cause is: make[2]: Entering

Re: syslogd can't be started when running Guix in Docker

Hi Ludo, >> A more fundamental question is whether I will be able to do useful work >> with this setup. It is well known that host file access from Docker on >> macOS is slow, but I didn't realize how slow it is until I compiled Guix >> in... four hours. On the same machine booted to Linux, it's

Re: Profiles/manifests-related command line interface enhancements

Pierre Neidhardt writes: > I'm actually surprised you find it surprising! :) > I can think of Simon, maybe Konrad(?) and myself who mentioned it > before. Yes, me too. I could add to Pierre's list of use cases, but I prefer to shift the discussion to a higher level. What we have been

Re: Profiles/manifests-related command line interface enhancements

Hi Ludo, > I agree this is an important use case. It seems to me that the problem > here is being able to aggregate more than just packages. Yes, it's a bit more than that. We'd probably have to look at a couple of use cases to see what the most general content would be. > The Web application

Re: Profiles/manifests-related command line interface enhancements

Pierre Neidhardt writes: > By the way, the same should be possible from the installer: > > - Specify which channels you want to use. > - Specify which config.scm you want to use. Indeed, the config.scm > might rely on channels. > > This way, the Guix installation process would boil down to

Re: Profiles/manifests-related command line interface enhancements

Hi Simon, >> I can of course share a manifest file by putting it in a public >> repository. But that isn't necessarily the best way. > > From my opinion, it is not the problem of Guix. Guix should not force > a practise, as good it should be. The way the users share manifests is > the problem of

Re: A better XML, config is code (was Re: Profiles/manifests-related command line...)

Hi Giovanni, > The real question is: a configure file is code or data? IMHO is code, Code is data with execution semantics, so "code" is a subset of "data". I'd reformulate the question as: should configuration data be literal data, or the result of a computation? The second opton is more

Re: Profiles/manifests-related command line interface enhancements

Ludovic Courtès writes: > To me it’s not entirely clear that a unified command would be easier to > use for newcomers. For example, I’m not fond of “guix profile” as a Indeed. It's also not clear to me if a single command line package for beginners and power users is the best way to go. Maybe

Re: Profiles/manifests-related command line interface enhancements

Hi Ludo, > I’d like to think that writing Guile declarations for the OS config, > manifest, etc. is not just for “power users”. After all people, or > rather “computer-savvy” people in a broad sense, write JSON, YAML, > custom config files etc. routinely, and I don’t think the typical config >

Re: guix pull failed after 8 hours

Hi Ludo and Chris, > Could it be that those old systems were talking to hydra.gnu.org and > thus not getting any substitutes? > > https://lists.gnu.org/archive/html/info-guix/2019-06/msg1.html That's what happened to me on my oldest Guix installation (hosted on Ubuntu). I had done regular

Re: Profiles/manifests-related command line interface enhancements

Hi Andy, > I wrote this for that purpose: > > > https://www.gnu.org/software/guile/manual/html_node/Sandboxed-Evaluation.html Right, I had found this when searching for something. It seems to solve a couple of problems that I don't quite understand, but not so much those I do (file/network

Re: Profiles/manifests-related command line interface enhancements

Hi Hartmut, > This becomes even messier if we would implement a "guix develop" > command, which is yet just another version of environment/profile. Yes, I worry also about making more of a mess by implementing special-purpose variants. > And adding another dimension: spawning a sub-shell

Re: Profiles/manifests-related command line interface enhancements

Hi Simon, > I am not sure to see which feature is missing. My main point is that the future evolution of functionality (and user interfaces) in this space should take into account usage scenarii, rather than adding features in an ad-hoc fashion. I can of course share a manifest file by putting

Re: Profiles/manifests-related command line interface enhancements

Hi Ludo, > I think having ephemeral + persistent and declarative + imperative is > cool—I’d call that “flexible” rather than “messy”. :-) I agree. What's messy is how the concepts map to commands. How many Guix users understand that profiles are persistent environments, or environments

Re: Profiles/manifests-related command line interface enhancements

Hi Ludo, > Of course, using a general-purpose language upfront also comes at a > price, as you note. But I think that what it has to offer to users > outweighs the costs, and that’s a lesson learned from Emacs. Just to > say I’m not willing to replace ‘config.scm’ with ‘config.yaml’, if >

Re: Python 2 end-of-life?

Hi Simon, > What do you do? Well, me, personally, I continue to do most of my research using Python 2 because I cannot afford to port everything to Python 3. And since I do only number crunching, meaning nothing with security implications, I am not particularly worried. > Do we deprecate the

Re: On DSLs

Hi Ludo, >> For better illustration, I'll try to rewrite my own manifests in the >> way I'd like to be able to write them. That's probably more useful >> than theory (a tough statement to make for a theoretician ;-) > > Agreed! Just to be clear: I actually intend to implement some infrastructure

Re: On DSLs

Hi Julien, > Could this discussion be saved in the cookbook for instance? I'd like > to have this kind of discussion on the approach of guix and ideas > behind it somewhere more accessible than the ML archive. Does it make > sense? I think it makes sense to archive summaries of such discussions.

Re: Feedback from JRES in Dijon

Hi Bengt, > BTW3, Konrad, > That was a nice presentation -- are the tools you used to prepare it and > present it > available as libre packages? (I'm not insisting you answer ;-) That's LaTeX with the Beamer package, plus Inkscape for the graphics. It's all in Guix. A bit of history: for many

Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

On 16/12/2019 23:09, Ludovic Courtès wrote: So in a more algorithmic manner: 1. if ad-hoc and inputs-of is present at the same invocation: fail hard. (With an error like incompatible options present) 2. if only ad-hoc is present, then print a deprecation warning (yes, we could make this

Re: Feedback from JRES in Dijon

Hi Ludo, >> I am working on an article (ultimately for "Computing in Science and >> Engineering") that takes up some of those subjects and illustrates them >> using Guix. It would be nice to get feedback from the Guix community >> early, to make sure I don't do something stupid. So I could do a

Re: Feedback from JRES in Dijon

Hi Julien and Pierre, > So they are doing physical simulation (fluid dynamics), so they don't > (can't) get the same result when running the same experiment > twice. They wart replicability, that is, even if the results are > different, they are close enough to each other that you have to draw >

Re: Feedback from JRES in Dijon

Hi Simon, > If I might, one the best presentation [1] -- that I am aware of -- on > this. Sorry in French. Thanks for the marketing :-) > [1] > https://webcast.in2p3.fr/video/les-enjeux-et-defis-de-la-recherche-reproductible >

Re: Feedback from JRES in Dijon

Hi Bengt, >> [1] >> https://webcast.in2p3.fr/video/les-enjeux-et-defis-de-la-recherche-reproductible >> https://aramis.resinfo.org/wiki/lib/exe/fetch.php?media=pleniaires:aramis_keynote_enjeux-et-defis-recherche-reproductible_konrad_hinsen.pdf >> > > Is [1] available as a libre video download?

Re: On DSLs

Hi Simon, > Out of curiosity, do you have examples about YAML or JSON with an > interpreter running it? I just encountered an example: GitHub actions. Cheers, Konrad.

Re: “Guix Profiles in Practice”

Pierre Neidhardt writes: > "Thompson, David" writes: > >> if it's a good idea. Probably not. So, I wonder if maybe a new >> subcommand, say 'guix develop', could address this common development >> use-case while allowing 'guix environment' to continue being the swiss >> army knife that it is.

Re: “Guix Profiles in Practice”

On 27/10/2019 12:30, Pierre Neidhardt wrote: Another talk could be about programming Guix from the REPL. Guix as a DSL if you will. Anyone interested in doing a talk about that? I would be very interested if someone could explain how they hack with Geiser: I'm still frustrated with it on a

Re: “Guix Profiles in Practice”

Hi Pierre, >> Jumping to symbol definitions, for example, or access to documentation. > > I can jump to definition with no problem. Is your load path set > properly? After inspection... no. At least not in all my Guix installations. It does work fine with the right path. > Access to the manual

  1   2   3   >