<Apteryx>Guile debugging straight from the terminal is even worse, since apparently there is no readline support (yet it's compiled with such support... hmm)
<reepca>Apteryx: welll... not exactly. I've mostly noticed the problem with the REPL created by the various emacs guix commands. Whenever I do M-x run-geiser RET guile RET it tends to go more smoothly (might be coincidental, though). Also, you can load readline as a module - (use-modules (ice-9 readline)) and then (activate-readline).
<Apteryx>reepca: OK. I usually start my Geiser REPL with C-a in my source buffer since it ",uses" it.
<Apteryx>This is a Geiser function: (geiser-mode-switch-to-repl-and-enter)
<Apteryx>I'll try your suggestion to run run-geiser straight.
<eacces>i read the start of The-Store.html then jumped to a conclusion :\\
<Apteryx>Is there a way to have an "optional" pattern in a match?
<Apteryx>I have a sexp where there might or might not be an entry at the end. I'm not sure how to express this.
<reepca>Apteryx: I think the usual way of expressing that would be to have another match clause with the extra option. I don't know if there's a more concise way of doing that, for example using define* syntax.
<reepca>I know in common lisp there was a destructuring-bind that let you use define*-like syntax for pattern matching
<Apteryx>So I added a second sexp pattern with append-separator? missing in the pattern, and where I build the record with append-separator? #f
<bytes83>is there any sample grub configuration (via config.scm) available for reference. I am trying to set up a grub menu entry for my other distro but i keep getting an error
<Apteryx>And what this buys us is that now we can use resolve dependencies for example Emacs using a more normal native search-paths-specification approach; and this has the happy side-effect that Emacs dependencies are honored even at build time (doesn't seem to be used much so far but as we add tests to our Emacs package the problem would have quickly become apparent).
<reepca>bytes83: I'm assuming you've already checked out the menu-entry example in 6.2.12, so could you paste what you've tried so far?
<ng0>[06:19:12] <reepca> Alright, ordering a radeon hd 6450 and if that doesn't work I'll probably write a very strongly-worded letter to that guy on h-node <- that card looks oddly familar. I have to check if this is one of the cards which is broken for me (as in technically, not driver) or if it just looks like one of the cards I have which aren't working
<ng0>okay, it just looks like an NVidia card I have :)
<catonano>what was the command for hhaving Guix download the source of a package ?
<ng0>reepca: could you tell me when oyu have the card if it works?
<efraim_>catonano: 'guix package foo -S' will get you the source with any patches and snippets applied
<jsierles>I just did a fresh install from the 0.13.0 binary tarball. I ran 'guix package -i vim' and it's compiling the whole dependency tree, and vim, from source. Why wouldn't it be using substitutes here?
<jsierles>the third time i tried it, it downloaded from hydra.gnu.org instead of compiling.
<jsierles>is there a programmatic way to fetch all the exports a profile might require? for example export R_LIBS_SITE. I'd like to ensure that along with a manifest, i have all the necessary exports somewhere.
<rekado>jsierles: the exports are written to $out/etc/profile, but you can also get them with “guix package --search-paths”(?)
<jsierles>been waiting a couple minutes. what's the cause of the slowness?
<lfam>The server is almost always heavily loaded, and the hydra software itself is not that efficient in general
<lfam>That's why we created mirror.hydra.gnu.org: to reduce the effect of fetching package subsitutes on hydra.gnu.org. But the mirror doesn't give the web interface to the build farm
<jsierles>right. but this means there's no easy way to check the status of substitutes on that server
<jsierles>just wondering if some local compilation i saw earlier today (of vim) would have been caused by something happening on the substitute server. not too clear on how that works yet.
<lfam>jsierles: Checking if a substitute is available via that web page will be impractical in my opinion, even if the page loaded faster.
<lfam>If a substitute is not available on the mirror, it will return 404 right away. If a substitute is available on the back-end, the mirror will request the back-end to start compressing and sending the substitute to the mirror. So, a few minutes after the initial 404, the mirror might have a substitute available.
<lfam>Personally I'm not so bothered by compiling once in a while. Guix is a build-from-source system with transparent binary substitution, after all :)
<lfam>But it's not practical on some systems to compile
<jsierles>it doesn't bother me exactly - i just like to know what is going to happen
<lfam>I still think the current arrangement is very good, though. It makes updates available quickly to those who are able and willing to build them, and everyone else has to wait, just like on a binary distro.
<jsierles>for all practical purposes, we will have a single store and only need to build/download stuff once
<lfam>Right, so the mirror lacks a subsitute, you might try again in 10 minutes or so in case it's fetched it in the meantime
<jsierles>single shared store that is, across the whole cluster.
<jsierles>lfam: but what happened today was, i ran the same command 3 times in a few minutes, and the third time, it did get a substitute. so just wanted to know if i did something wrong
<jsierles>or if that means the substitute was being rebuilt.
<lfam>You experienced what I described above. The mirror lacked the substitute but it was available on the back-end. So your query triggered the mirror to retrieve the substitute.