IRC channel logs

2021-01-23.log

back to list of logs

<zimoun>something slow in ’inferior-eval-with-store’
<civodul>inferior-package->manifest-entry doesn't call it
<rekado>uhm, I’m not very familiar with ‘perf timechart’. I see two Guix … oh… it’s *still* rendering that huge SVG…
<zimoun>true :-) But still, I bet it is about socket. ;-)
<rekado>with my vlist patch inferior-package->manifest-entry doesn’t recompute the same thing twice
<rekado>and I can also build the profile from that manifest
<rekado>(it’s just once I use that Guix in the GWL that weird things happen, but this could be because I’m tired)
<rekado> https://elephly.net/downies/perf.svg
<rekado>I don’t know what to make of this
<rekado>I’ll revisit this tomorrow.
*rekado —> zzzZ
<rekado>thanks for all your comments and help!
<zimoun>Same here. Good night!
*civodul is head-down on Guix-Jupyter
<civodul>just added Picture Language support :-)
<rekado_>oh, neat! :)
<civodul> http://web.fdn.fr/~lcourtes/tmp/guile-picture-language.gif
<civodul>TBH, i still prefer using it in Geiser :-)
<civodul>you don't see function signatures in Jupyter, unlike Geiser, for instance
***nckx[2] is now known as nckx
<rekado_>civodul: looks great!
<rekado_>Guix is mentioned here: https://academic.oup.com/gigascience/article/10/1/giaa140/6092773
<rekado_>I’m totally stumped by this inferior problem
<rekado_>my brain isn’t willing to think
<rekado_>so I’m just staring at the puzzling output in utter bewilderment.
<rekado_>lowering the very same profile using the very same Guix has very different behaviors dependent on whether it’s the GWL doing it or ‘guix repl’
<rekado_>the GWL wants to rebuild the world
<civodul>rekado_: nice that they cite your work!
<civodul>re inferior, are you observing a performance issue, or is it that it's building a different derivation?
<civodul>(or both :-))
<civodul>do you have a snippet to reproduce the issue?
<rekado_>I just heard that a certain reviewer of that paper asked them to put in references to Guix and PiGx :)
<rekado_>so… that inferior thing…
<rekado_>I’m observing a performance problem, which is why I patched (guix inferior) to memoize inferior-package->manifest-entry.
<rekado_>the patched Guix seems to work fine with my test case that I previously used to demonstrate the performance problem.
<rekado_>from 14+ seconds down to under a second
<civodul>ah good!
<civodul>would be nice to see which bit of memoization really makes a difference
<civodul>but we can see that later
<rekado_>but when I build the GWL with that patched Guix as its input it doesn’t even reach the point that I was experimenting with — much earlier, the first moment I’m building a profile, it downloads lots of tarballs for binutils, gcc, etc.
<rekado_>so … yeah, I guess it’s building a different derivation for some reason.
<rekado_>I haven’t been able to let it tell me more, though
<rekado_>that’s going to be my next step: use gexp->derivation and friends instead of the higher-level lower-object to have it print the derivation name first.
<rekado_>and then compare them
<civodul>or just add the thing that prints derivation names before building?
<civodul>build-notifier from (guix ui), i think it's called
<rekado_>oh, there’s a thing…? I’ll check!
<rekado_>(guix ui) is full of surprises!
<rekado_>(it’s huge!)
<civodul>it's a bit of a kitchen sink!
<civodul>so (with-build-handler (build-notifier ...) ...)
<civodul>and it'll be automatically called when the body wants to build something
<rekado_>sweet!
<rekado_>I’ve been meaning to work on massaging the GWL output a bit anyway, so I might as well look at this now :)
<civodul>heh
<civodul>hopefully you can copy what the (guix scripts ...) modules do
<rekado_>I’m already spelunking derivation file references
<rekado_>here’s gcc-core-mesboot0 and it as all the same inputs, but the field containing the builder, module-import, and the patch differs
<rekado_>the store item name of the patch file differs, but it’s the same file
<rekado_>and that’s the only difference in the builder as well: it’s just the store name of that patch
<rekado_>wild
<rekado_>so… one of these patch files is a hardlink (21 links on that file), whereas my bad one is a symlink that points to my custom Guix
<rekado_>/gnu/store/8qjkdfhqg17rrq7xsjkgz139m5l7sawi-gcc-boot-2.95.3.patch -> /gnu/store/ikrkyfkqg81cp4zrmg9w5zx7znahp3q7-guix-git.caa7fd4/share/guile/site/3.0/gnu/packages/patches/gcc-boot-2.95.3.patch
<rekado_>that’s the patched Guix that I built!
<rekado_>so!
<rekado_>I guess it’s not safe to use package transformations on the ‘guix’ package itself
<civodul>oh?
<rekado_>this is my really convoluted guix.scm to set up my GWL environment: https://elephly.net/paste/1611442130.scm.html
<rekado_>there’s a ‘latest-guix’
<rekado_>the rest of that file is just to ensure that I’m not dealing with that incompatibility in bytecode between version 3.0.2 (which is used by most guile-* packages) and 3.0.5 (which is used by ‘guix’)
<civodul>hmm how can it become a symlink?
<civodul>interesting
<rekado_>a genuine bug?
<civodul>looks like it
<rekado_>I can’t believe it wasn’t something obviously silly that I did.
<civodul>but maybe you can avoid package transformations and just change the 'source' field of 'guix' in this case?
<rekado_>yes, probably