IRC channel logs

2023-02-21.log

back to list of logs

<zimoun>rekado, PurpleSym: people using guix-cran hit some issues as “Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS” from libgc and “guix search '' | recsel -C -p location” return unexpected results.
<zimoun>giving a look https://github.com/guix-science/guix-cran-scripts/blob/master/import.scm
<zimoun>I was thinking is it would possible to order differently the packages, instead by alphabetical order, maybe but depth in the graph.
<PurpleSym>zimoun: Which commit and which command return this error?
<zimoun>2a7a025417b4e66d676d5f1e79c667e44c6b8943 + Guix 53e27f8abf1163e29fb5fc17af38b90a67a18138
<zimoun>“guix package -A | grep hello“
<zimoun>‘guix search '' | recsel -C -p location | sort’ and I have only 92 lines.
<zimoun>it is a bug of Guile because guix-cran challenges its capacity. :-)
<rekado>zimoun: thanks for the bioconductor upgrades. I got sick yet again, so I’ll be away from keyboard for a while longer. If you feel confident about the upgrades feel free to push.
<rekado>I built all the CRAN packages I updated as well as pigx (because it needs a good selection of useful R packages), but stopped short of upgrading bioconductor
<zimoun>rekado: I do not have received yet any answer from maintainers. You were in copy, did you receive this email for applying?
<zimoun>No worry! Keep some rest for recovoring.
<PurpleSym>zimoun: I can see the problem, but this seems more of an issue with Guile and no reordering is going to fix that.
<PurpleSym>Both commands eat about 16GB of RAM before death.
<PurpleSym>I’m guessing that Guile cannot (by design) free any memory once it eval’d a package.
<rekado>zimoun: I received the message on Feb 11.
<zimoun>rekado: thanks for confirming.
<zimoun>PurpleSym: yeah it is a bug about Guile. The reording would help in investigating it.
<zimoun>Roughly, we have 20k+ packages and it is ok. The 20k+20k and bang!
<PurpleSym>How would it help?
<zimoun>So I would like to be able to see values in between.
<zimoun>To be able to draw scalability plot
<zimoun>Mem vs number of packages.
<zimoun>Time for “guix pull” vs number of packages
<zimoun>etc.
<zimoun>I already tried to duplicate some packages for other channels but often there is not enough.
<zimoun>Anyway, I do not have time these days to investigate more. :-)
<PurpleSym>zimoun: For that purpose synthetic benchmarks seem more appropriate.
<PurpleSym>It’d be easier to control the number of packages.
<efraim>I have about 8000 packages in https://gitlab.com/Efraim/guix-ietf all in one file if you want to try breaking guix pull
<zimoun>oh thanks