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

["Ludovic Courtès" <ludovic.courtes@inria.fr>]

Hi Konrad,

Konrad Hinsen <konrad.hinsen@cnrs.fr> skribis:

> Konrad Hinsen <konrad.hinsen@cnrs.fr> 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 https://github.com/ReScience/submissions/issues/41)
>     - SciPy ecosystem from 2007 (at least Python, NumPy, matplotlib)
>       (used in https://github.com/ReScience/submissions/issues/14)

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) https://github.com/ReScience/submissions/issues/42
>
>    A rather standard Fortran code, with only the popular BLAS and LAPACK
>    libraries as dependencies. Instructions are given for manual
>    compilation.
>
>    b) https://github.com/ReScience/submissions/issues/36
>
>    A medium-sized Fortran program with a Makefile.
>
>    c) https://github.com/ReScience/submissions/issues/41
>
>    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) https://github.com/ReScience/submissions/issues/20
>
>    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):
>
>    - https://github.com/ReScience/submissions/issues/39
>
>    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!  <https://github.com/debuerreotype/debuerreotype> is
interesting.

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

Ludo’.