Hi Konrad, Konrad Hinsen <konrad.hin...@cnrs.fr> skribis:
> Konrad Hinsen <konrad.hin...@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’.
