IRC channel logs


back to list of logs

<zimoun>Hehe! After my short demo about Guix and GWL, people in the other building are interested \o/ Let sow or scatter. ;-)
<rekado_>yay :)
<civodul>zimoun: well done!
<ndeck>zimoun: not surprised ! you sell it well ;)
*rekado_ feels the heat
<rekado_>as soon as my schedule clears up a little I’ll get back to hacking on the GWL
<zimoun>ndeck: hehe! :-) Do not miss <> ;-)
<ndeck>Great ! I'll try to attend, it is at the same time as the "doctoral school annual days"...
<zimoun>rekado_: about GWL, among the issues you mentioned yesterday, I think we should try to address where the big fixed-outputs live and the content-addressing of the intermediate results, as we discussed several times. :-)
<rekado_>zimoun: yes. I don’t know how to move forward here, to be honest.
<rekado_>we want to avoid having to copy lots of files
<rekado_>we also want to avoid having to compute hashes for huge files
<rekado_>but perhaps that’s not actually that big of a problem and we should just compute hashes already
<rekado_>I would like to have a central registry of files and their hashes; doesn’t need to be a copy of these files
<rekado_>so what’s currently presenting itself as a cache really isn’t
<rekado_>we only need to have a registry with pointers to intermediate result files and their hashes.
<zimoun>I think an abstraction between package and process is missing.
<rekado_>could you please elaborate?
<zimoun>well, my mind is not really clear. I should re-read the past discussion which leads to process instead of package. And I will drop an email to gwl-devel. :-)
*rekado_ hacks on GWL now
<rekado_>I’m running the first test since a few weeks and I see suboptimal behavior: git-minimal is built and I don’t know why.
<rekado_>I’m guessing that this is needed to use the inferior
<rekado_>hmm, or maybe I’m just ending up with a wrong derivation because of some store settings
<zimoun>rekado_: what do you mean by “store settings”?
<rekado_>I don’t know actually
<rekado_>I’m using run-with-store to compute the process scripts
<rekado_>this happens inside an inferior
<rekado_>if only I could let Guix tell me why it wants to build this git-minimal derivation…
<rekado_>it’s all because of applying lower-object to the scripts (which are program-file values)
<rekado_>and that’s because the profile they describe needs to be built
<rekado_>but I wonder why it doesn’t tell me the derivation of that profile – instead it shows me the derivation for git-minimal
<zimoun>hum, I have no clue.
<civodul>rekado_: git-minimal... could it be for a fixed-output derivation?
<civodul>a git-fetch origin
<rekado_>good idea
<rekado_>but more generally I’d like to be able to see more about *why* Guix does things.
<rekado_>it certainly knows, but it won’t tell me
<rekado_>the only package it is supposed to install is bash-minimal
<civodul>i wonder how it could better answer "why"
<civodul>the answer to "why" is always "because it's needed", but probably you'd like to see the path from what you want to that thing
<rekado_>here I’m not even asking it to build anything
<rekado_>all I do is (mapm/accumulate-builds lower-object scripts)
<civodul>but grafting means that this could trigger builds/downloads
<rekado_>disabling grafting circumvents this
<civodul>did you install the "build handler" that calls show-what-to-build?
<rekado_>this is wrapped in (with-build-handler (build-notifier #:verbosity 2) (run-with-store …))
<civodul>all good
<rekado_>I’ll have to think a little more about what to do about grafts here.
<zimoun>arf, I gave a look at VSCode since an intern will arrive next week (let him the choice with Emacs). I do not understand all the hype… it appears to me more complicated and less powerful than Emacs. Well, once you get the buffer manipulation mindset, everything appears more complicated. ;-)
<civodul>you're biased :-)
<civodul>(but i agree with you, even if i haven't even tried)
<zimoun>hehe! :-) Have a nice week-end
<rekado_>I have never used VSCode, but have watched my colleagues use Atom and RStudio
<rekado_>they didn’t do anything that Emacs couldn’t do, but they could do these things in Atom / RStudio but not in Emacs.
<rekado_>and I think that’s because Emacs is not only the overflowing kitchen sink, but also has a thick foamy layer of bubbly dish soap that makes it hard to see just how deep that kitchen sink is.
<rekado_>defaults matter
<civodul>i like that analogy :-)
<civodul>but yes you're right, and that explains the success of Spacemacs & co.
<civodul>also: kill/yank
<civodul>(i have yet to see/hear "yank" in real English)