<khinsen>efraim At the time of the split, many packages left the choice between Numeric and numarray as a build-time choice. If we want to support both paths, we have to agree on some naming scheme for the packages.
<bonz060>civodul: Yeah. What I had in mind doesn't really align to the scientific reproducibility theme. So I'm poring over the issue list for something I think I can do. From what I see on https://gitlab.inria.fr, external members need to request an external a/c. I could send e-mail patches though
<bonz060>Also, perhaps the channel op could set the topic for ^^ to point to the pad
<civodul>bonz060: sure, patches by email work fine
<khinsen>zimoun PurpleSym All compilers still support Fortran 77. It's a subset of later versions of the standard.
<khinsen>zimoun PurpleSym The reason why g77 matters is for C-Fortran interfacing. That's undefined by the Fortran 77 standard, so every compiler has its own conventions and code written for g77 doesn't work with other compilers.
<PurpleSym>Yeah, that’s what the reproduction paper is saying as well.
<khinsen>zimoun Ahhh... thank... got it. I was asking for email@example.com, but it's firstname.lastname@example.org Compiling now!
<khinsen>zimoun PurpleSym What I find interesting in this paper is that it's a two-level reproduction failure. The application code doesn't work with gfortran, AND g77 cannot be compiled under Debian. That's where a fully recursive build-from-source approach as with Guix really shines. I don't know how hard it is to get g77 packaged, but at least it should
<khinsen>be possible, whereas with other distributions you cannot even consider it.
<rekado>civodul: I see that you recommend specification->package to be used in some cases. I think that’s a good idea and I’ve been meaning to switch my channels to using that instead of plain variable references.
<rekado>Should *all* additions to guix-past use specification->package or are there criteria to help decide
<khinsen>bonz060 I am working on adding NumPy and numarray to the Python 2.4 in guix-past. Would you be interested in doing Python 2.5? We could then sync and add numarray and NumPy to Python 2.5 as well.
<civodul>i guess it would also make sense to use only specification->package, but it's a bit cumbersome and error-prone
<zimoun>Is it expected that "guix environment --container --ad-hoc hello -- which ls" returns nothing. I was expecting an error. What could be wrong on my machine?
<khinsen>Policy question to everyone: what do you think of putting the release date of packages in guix-past into the synopsis and/or description? The idea is to facilitate finding the version that was current when a paper was published.
<khinsen>I was kicked out and probably missed the latest news... I am taking a lunch break, after finishing numarray (just a cleanup of the code from guix-bioinformatics). Will tackle NumPy after lunch.
<zimoun>PurpleSym: from my old memories, files with .f77 or .f90 was compiled with gfotran with the norm 77 resp. 90. But I do not remember what for .f. And I remmeber an option like -x f77 but I am not sure.
<civodul>paul-g: for PIV, it's up to you: you can add it to Guix-Past, or you can create a separate repo if you think it's too arcane or whatever
<civodul>but i guess quite a few things will be arcane in Guix-Past, so it's okay
<paul-g>civodul: the author describes the code as obsolete in the ReScience paper.
<bonz060>When doing package dev, do you run create a container, and then when inside it, continue your work. I think I'm inefficient at this. I've created another profile where I'm installing things and testing things out abit manually. What's your "efficient" workflow?
<khinsen>paul-g civodul I vote for addition to guix-past. Even if the code itself is of limited interest, it can serve as inspiration for others who would like to package old stuff.
<civodul>khinsen: it can still serve as inspiration if it's in another repo, though
<civodul>no strong opinion, but perhaps longer-term we'll have to clarify the scope of Guix-Past
<paul-g>khinsen civodul: ok, I will use Guix-Past for the PIV code.
<khinsen>zimoun It's not uncommon for people to keep several BLAS libraries around, e.g. with different performance characteristics. That's why each implementation has a distinct name, even if the APIs are the same.
<civodul>bonz060: don't worry about the pace, but feel welcome to ask for guidance if you stumble upon issues
<zimoun>bavier1, civodul: I do not know if my memories are accurate enough. But I have vaporous remembering of playing with update-alternatives on Debian switch from atlas, openblas and probably netlib blas for some perfomance comparisons. Maybe the configuration tools was smart enough to figure out which implemetation... well, I do not know.
<zimoun>PurpleSym: yeah. Well, I have not read all the paper and I thought that the code linked to the submission would be easier. :-)
<khinsen>efraim rekado civodul I doubt I'll add anything more today, as I have to leave in 15 minutes for another meeting. If you want to merge my branch, go ahead. I will explore the Python compilation issue later.
<zimoun>rekado, khinsen: yes but it will not apply to the dependencies, so you have issues.
<PurpleSym>zimoun: From what I read in the paper the code in this new repository received some fixes/changes.
<khinsen>zimoun Thanks, that's good to know. For my subject that shouldn't be an issue.
<zimoun>khinsen: give a look to packge-with-python2
<khinsen>zimoun That's a different issue - my problem is compiling Python 2.4.6 itself.
<zimoun>khinsen, for rewritte with another "compiler" all the dependencies. To be exact package-with-explicit-python
<zimoun>you can write package-with-explicit-gcc and then provide the version toolchain you want and so recompile everything with old GCC
<rekado>logs are now available at logs.guix.gnu.org
<bonz060>I'm trying to build matplotlib but it's failing because: https://paste.debian.net/1155059/. From `less setupext.py`, I think my sys.platform should just be `linux`, but I can see the error spews: `linux5 is not in the list of basedir`. Any ideas?
<bonz060>I do not want to add a `linux5` somewhere, because the point of guix-past is to work on all future platforms