IRC channel logs

2021-12-06.log

back to list of logs

***Server sets mode: +nt
<rekado>what can we do about openblas?
<rekado>building optional stuff dependent on whether the build CPU supports certain extensions is problematic
<rekado>this all ends up in the big .so and leads to differences that a challenger cannot attribute to CPU features
<rekado>(this screws up our reproducibility analysis in an upcoming paper)
<rekado>r-minimal keeps a lot of references in lib/R/etc/Makeconf and lib/R/bin/libtool.
<rekado>I wonder if we can remove them.
<rekado>at least the line in Makeconf can be removed.
<rekado>not sure about compiler_lib_search_path compiler_lib_search_dirs sys_lib_search_path_spec in R's libtool
*rekado prepares two patches to reduce extraneous references
<zimoun>hi!
<civodul>o/
<civodul> https://ngyro.com/pog-reports/2021-11-30/ is 404
<civodul>what happened?
<zimoun>I do not know. samplet is probably doing some maintenance.
<zimoun>all is 404, e.g., https://ngyro.com/pog-reports/2021-10-20/
<zimoun>ah, what does it mean double backquoting ’``(’? For instance petsc-openmpi.
<zimoun>Then replaced by ’#~`(’. So I am lost. :-)
<rekado>the double quasiquote is because of substitute-keyword-arguments
<rekado>we want to return an expression that begins with quasiquote.
<rekado>but we also want to use quasiquotation itself.
<zimoun>rekado, ah I see. Thanks for explaning.
<rekado>I think the gexp syntax does make things look a bit more intimidating.
<rekado>I wonder if we could simplify this, e.g. by always reading the value of the arguments field as a gexp
<rekado> https://github.com/NixOS/nixpkgs/pull/116274
<rekado>uutils is written in Rust
<rekado>I cannot comprehend why one would like to replace GNU coreutils with something new that's been written in Rust at this fundamental level.
<zimoun>I do not know. What I find confusing is the mix of #~ with backquote. As in petsc, native-inputs backquote, arguments #~, but the package veusz in the same file uses backquote in arguments. It adds a level of complexity, and let the feeling of automagic thing; especially for non-lispers.
<rekado>do the nix folks not bootstrap rust?
<zimoun>«There should be one-- and preferably only one --obvious way to do it.»
<zimoun>«Although that way may not be obvious at first unless you're Dutch.»
<rekado>#~ is only used whenever you want to use #$ inside the expression
<zimoun>I know. It does not change the issue of confusion. :-)
<rekado>that's why I wonder: can we hoist #~ up to the top of the expression? And then use it implicitly by modifying the DSL?
<rekado>we now have a gexp for the values *inside* the keyword list
<rekado>it could instead be a gexp that evaluates to a keyword list
<zimoun>from what I guess understanding, I would say this instead looks better. :-)
*zimoun read dictionnary for 'hoist' :-)
<rekado>also known from: https://en.wikipedia.org/wiki/Hoist_with_his_own_petard
<civodul>rekado: re gexps, i find that (list #:flags #~(...)) is marginally nicer than `(#:flags ,#~(...))
<civodul>the ,#~ sequence is just too much
<civodul>but then i don't think we can make all of the keyword values gexps
<civodul>there are exceptions
<civodul>so uutils is the name of the Coreutils rewrite in Rust?
<rekado>the value of the "arguments" field is always quoted. Could it be always gexp-quoted? By default?
<civodul>it's not always quoted
<rekado>yes, uutils is the name of the coreutils rewrite
<rekado>oh, sometimes we have substitute-keyword-arguments
<civodul>right
<civodul>so i can't think of an easy way out
<rekado>new syntax!
<civodul>#?(...) which would expand to (quote-dwim ...)
<rekado>pretty much
<rekado>or (bikeshed ...)
<civodul>:-)
<civodul>back to Rust, i'm very much concerned about this trend
<civodul>seems to me we might quickly have two separate worlds: GNU/Linux, and an ever-expanding Rust/Linux
<rekado>the trend to rewrite in Rust, or the trend to pour out the GPL baby with the C bathwater?
<civodul>heh, both!
<civodul>it looks like a struggle for hegemony, as opposed to bringing something to the free OS table
<rekado>I really don't mind Rust; obviously I don't like the poor bootstrapping situation, the lack of support for other architectures, the lack of version-to-version stability, and the lack of dynamic linking --- but I don't actually mind the "rewrite in rust" meme per se.
<rekado>for many people it seems that the mere fact that something *other* than C is used *is* a gift to the free OS table.
<civodul>heh
<rekado>it does seem like GNU is being erased
<rekado>but maybe that's ... not as bad as it may seem
<civodul>Python/Perl did displace C, but that was more in a collaborative spirit, i think
<civodul>concretely, i think maintaining a free curated distro could quickly become next to impossible if more developers follow librsvg's lead
<rekado>isn't that just a Guix problem, though?
<efraim>I don't think I've actually ever checked with anyone from Debian how they handle librsvg
*rekado ---> bike
<civodul>i mean, every distro has to import 200+ packages just to build librsvg, right?
<civodul>so even if we ignore bootstrapping issues, it can't be just a Guix problem
<civodul>or to put it differently, distros will be pressured to give up on curation, unbundling, bootstrapping, and other forms of QA work
<zimoun>civodul: well, arguments not always quoted? We can do stats, but it appears to me almost surely quoted or backquoted. And for small corner cases as substitute-keyword-arguments, it is not unified. Bikeshedding about syntax, all this adds complexity and we often hear: «I need to learn Guile for packaging» (see Café Guix ;-))
<civodul>zimoun: i'm open to solutions, i'm just saying it's not this simple :-)
<zimoun>civodul: new syntax! #? ;-)
<efraim>looks like debian uses the bundled crates, with some static libraries removed https://sources.debian.org/src/librsvg/2.50.7+dfsg-2/debian/changelog/#L291 https://sources.debian.org/src/librsvg/2.50.7+dfsg-2/debian/copyright/
<zimoun>civodul: about Rustify. Bah, drifting and going offtopic, it just looks like how the World is going these days for almost everything: create a big black box ready for consumption, sell it at all cost saying it is “better” than the rest, define “better” as own direct ’interests’ for creators, hide what “better” implies for future, loop.
*civodul nods
<civodul>efraim: oh see, they've already given up
<efraim>I'll see if I can track down some mailing list posts where they discuss it
***zimoun` is now known as zimoun
<PurpleSym>You mean pissed emails like this one? https://lists.debian.org/debian-devel/2018/11/msg00035.html
<civodul>ah but that was 2018
<civodul>Rust portability issues are "solved" now, putting aside bootstrapping
<civodul>(i think?)
<zimoun>What is the status of GCC-rust?
<civodul>i don't know exactly but it seems to be pretty good
<efraim>PurpleSym: haha, yeah, I guess like that. I meant more in the gnome group who owns librsvg in Debian
*efraim is still on mobile
<rekado>what do you think about this patch: https://issues.guix.gnu.org/52333
<rekado>I'm not sure about nbconvert, but I think the change is an improvement
<PurpleSym>rekado: Will python-nbconvert work though? I believe that latex-union is actually a runtime dependency. (Otherwise pdf export won’t work.)
<rekado>PurpleSym: I don't know how to test this.
<rekado>the texlive-union is a native input, so that's already wrong.
<rekado>crap. I downloaded some example notebook https://raw.githubusercontent.com/jupyter/notebook/master/docs/source/examples/Notebook/Notebook%20Basics.ipynb and ran "jupyter nbconvert --to pdf Notebook\ Basics.ipynb"
<rekado>doesn't work as expected
<rekado>says "I can't find the format file `xelatex.fmt'!"
<rekado>will try again with texlive-tiny
<rekado>okay, I'll retract the patch for nbconvert :-/