<davexunit>ooh I just heard talks of interaction between Guix and directory.fsf.org :D ***tadni_` is now known as tadni_
<davexunit>I was the only one in the guix channel for awhile, from my perspective <tadni_>davexunit: Free node is evidently getting ddos'd again. <davexunit>I'm trying to figure out how guix runs the test suite, but the Makefile is confusing me. <tadni_>Netsplits in #emacs are nuts currently! ***DusXMT_ is now known as DusXMT
<philed>Is %base-file-systems something introduced in guix 0.7? <philed>I'm a total beginning playing around with my config, but can't seem to find where this variable is defined. <Ulrar>You might be able to answer to philed <Ulrar>13:23:18 philed | Is %base-file-systems something introduced in guix 0.7? <philed>Ulrar: So to answer my own question: yes. %base-file-systems was introduced in guix 0.7. I just need to figure out why I'm not pulling the latest guix from my installation. <civodul>philed: it turns out that Guix 0.7 cannot contain a package of Guix 0.7, only of a previous version <civodul>so that's what happened in 0.7: 0.7 refers an older snapshot, which didn't have %base-file-systems <civodul>the solution is to run "guix pull", and then run 'guix reconfigure' from there <philed>civodul: I've tried "guix pull", and then "guix system reconfigure config.scm", and I still get complaints that %base-file-systems in unbound. :( <civodul>philed: does the config use (gnu system file-systems)? <civodul>also, was it the same user account that did "guix pull" and "guix reconfigure"? <philed>Yeah. I should add, I've grepped my profile for %base-file-systems and come up with nothing. <philed>My current version of guix is 0.7, but when I do "guix package -i guix", it only installs 0.6. <civodul>philed: you should grep ~/.config/guix/latest instead <civodul>this is where "guix pull" puts its stuff <civodul>jxself: do you have any clue about "sound hdaudioC0D0: No codec parser is available"? <philed>civodul: Ack. I don't even have that directory. I might start again. <philed>civodul: By the way, do you mostly do all this stuff in a non-root account? <davexunit>oh and morning to jxself! I didn't see your message. <jxself>Do you have that same message as civodul? <civodul>mark_wea` reported having the same issue <civodul>philed: yes, but reconfigure must be done as root (or "sudo") <davexunit>jxself: I didn't see that error personally, but I noticed that my sound wasn't working. I never dug into the logs to find out why. <jxself>It might be interesting to do so. :) <davexunit>since at the time it was a rather minor concern, all things considered. :) <DusXMT>Hmm, strangely, my sound card worked out of the box <DusXMT>Alsa mixer calls it C-Media CMI8738 <DusXMT>I don't know if it's any good or not, just the cheapest one I got ahold of as the sound on my motherboard didn't work at all <DusXMT>Does patch-shebang also fix shebangs of scripts which start with /usr/bin/env ? <mark_wea`>jxself: on my Libreboot X60, sound doesn't work when I first boot into standalone guix. I need to do this after boot to get sound working: rmmod snd_hda_intel && modprobe snd_hda_codec_analog && modprobe snd_hda_intel <DusXMT>What can the following error possibly mean? guix build: error: build failed: illegal name: `.-builder' <DusXMT>I'm an idiot, I never supplied it with an url. If anyone gets the above error, then you'ce been looking too hard, ignoring the obvious <DusXMT>Probably, I haven't heared of it, but I bet it reffers to exactly this. <jxself>mark_weaver: But that doesn't work for civodul? <jxself>It'd at least be helpful if everyone's problems behaved the same way. :) <DusXMT>Is there any easy way to recursively delete files/directories in a (snippet in a package? <mark_weaver>jxself: I don't know if it works for civodul or not. he said he would try it, but I haven't yet heard a report. *paroneayea reading the guix docs <paroneayea>the store monad thing has lead me to get interest enough to read up on monads <paroneayea>the whole "carrying around a context in a functional manner" is exactly a problem I've been dealing with lately... except my solution was just to pass around a "context" object to each function with various variables attached ;p *paroneayea taking a pretty lazy saturday of reading up on things :) <philed>paroneayea: IMHO, monads only become cool as an abstraction. Carrying around contexts is something we've always been doing. But the stuff in your standard monad library in Haskell showed me what I'd been missing. <tadni_>paroneayea: Sounds fun. I need to get moving in an hour and mow two lawns... then probably relax and update my blog and maybe start packaging clisp. :^P <paroneayea>philed: yeah... well, I'm not convinced *yet* that using monads will make the things I want to do less heavy :) <paroneayea>there seems to be a lot of overhead involved, just moved elsewhere? <philed>There's a lot of overhead involved in "monadification." <philed>That is, converting ordinary code to binds and joins, or even just do-notation. <philed>I've only ever used them in earnest in statically typed languages. I'm somewhat sceptical of their utility in dynamically typed languages, but maybe my forays into Guile will convince me otherwise. :) <paroneayea>I guess my real question was "is there an easier way to carry around a context", and it seems like "well monads are another way, but if everything else is fine, I wouldn't say 'easier'" <paroneayea>at least.... for the considerations I'm working on :) <philed>I like dynamic scoping for a nice intermediary. <mark_weaver>DusXMT: delete-file-recursively. see gmsh in gnu/packages/maths.scm for an example <paroneayea>philed: hm, I think that may have problems of its own in an async environment :) <philed>paroneayea: Ah yes, in that case, specialising monads is cool. <mark_weaver>philed: dynamic scoping has other problems, notably that it doesn't play well with lazy evaluation <mark_weaver>having said that, dynamic scoping is often the best solution we know of for many cases. <paroneayea>mark_weaver: the best solution we know of for making the port of emacs to guile pretty tricky? :) <philed>mark_weaver: Do you have any references to articles that discuss the issue in detail? <philed>I've only enjoyed dynamic scoping in CL, at a time when I didn't have a clue about lazy evaluation. <mark_weaver>philed: no, but it's a well-known problem with dynamic scoping. <philed>Well, we were talking about carrying around contexts, and monads, and when you are doing things with monads, you typically force an evaluation order, which isn't going to play nicely with what you expect of laziness. I'm guessing it's still a problem. <mark_weaver>lazy streams also force an evaluation order, and yet they obviously play well with laziness. <mark_weaver>the problem is that when you delay evaluation of an expression (ultimately using 'lambda'), and then the promise is later forced, it's not clear what portions of the dynamic environment should come from when the lambda was evaluated, and what portions should come from the code that forced the promise. <mark_weaver>for example, suppose you have a dynamic variable that specifies how much precision to use for inexact math operations. <mark_weaver>you want to run some computation with high precision, so you set the associated dynamic variable. <mark_weaver>but now, suppose that one of the things that code does is to consult some lazy streams. now, the code that computes some more elements of that lazy stream will run at high precision, which is not what you wanted. <mark_weaver>in a system where lazy evaluation is used, dynamic environment settings tend to leak to code that you didn't have any way to anticipate. *mark_weaver goes afk for a while <philed>mark_weaver: Thanks for the explanation. ***JamesJRH_ is now known as JamesJRH