[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: “Reproducible research articles, from source code to PDF”

From: Ludovic Courtès
Subject: Re: “Reproducible research articles, from source code to PDF”
Date: Mon, 22 Jun 2020 09:38:23 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hi Konrad,

Konrad Hinsen <> skribis:

> Konrad Hinsen <> writes:
>> Sounds fine. I am not much of a hackathon expert, so I don't propose
>> myself for organizing this, but I can make a preselection of suitable
>> submissions to the ReScience challenge (no proprietary software etc.)
>> with comments about the specific challenges.
> Here is my list of candidate projects. There are three general
> categories:
> 1) Package old software that is of sufficiently wide interest
>    (i.e. add to guix-past)
>     - g77 (used in
>     - SciPy ecosystem from 2007 (at least Python, NumPy, matplotlib)
>       (used in

Makes sense.

> 2) Package highly specialized research software
>    These programs are too specialized for the Guix distribution, so
>    "packaging" means writing a guix.scm. The long-term goal is to learn how
>    to make this kind of packaging easier, to the point that scientists are
>    willing to do it themselves. This means it must be doable with minimal
>    Guile competence, ideally by modifying templates provided by experts.
>    I have picked four cases, listed by increasing level of difficulty:
>    a)
>    A rather standard Fortran code, with only the popular BLAS and LAPACK
>    libraries as dependencies. Instructions are given for manual
>    compilation.
>    b)
>    A medium-sized Fortran program with a Makefile.
>    c)
>    A mixed C-Fortran code from 2008, built with autotools. Looks simple,
>    but the author did not succeed in compiling it on a modern machine
>    because it requires the abandoned g77 compiler.
>    d)
>    A medium-sized Fortran library with a Makefile. Tricky because it adds
>    its own wrappers around the Fortran compiler.

That’s going to be less fun but I agree it’s important to do something
for this use case.

> 3) Fully automated reproductions of results (typically figures)
>    There is only one case (other than Ludo's which already uses Guix):
>    -
>    A fully reproducible reproduction of two Open Source simulation software
>    packages (C/C++), based on Debian and its debuerreotype system. The
>    challenge is to demonstrate how Guix can do it better!

Heh, nice!  <> is

Thanks for sharing this overview, I guess we have enough on our plate now!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]