*davexunit is having some trouble with monads <davexunit>I have 3 procedures that I have lifted into the store monad. 1 sets build options, 1 prints what is going to be built, and the other builds derivations. <davexunit>I want apply them sequentially. however, I haven't figured out how to do it with bind. <fefe>bavier: I think yesterday you asked if someone was interested in imake. I am: I like xfig which requires it to be built. <civodul>it's pleasant to see all this come into place <Ulrar>Ha, reminds me I have one to finish <civodul>mark_weaver: i've made you and davexunit admins on Savannah, in an attempt to increase the admin bus factor ;-) <alezost>civodul: sorry, I didn't run tests before sending a patch with new condition types. I've found (thanks to "make check") that condition types couldn't be placed into (guix profiles) because (guix ui) would have to export it, but (guix ui) is already exported in (guix profiles). <alezost>So what would be a better place for those condition types? (guix ui) itself? Perhaps (guix packages)? <civodul>one possibility would be to move show-manifest-transaction to (guix ui), and thus remove #:use-module (guix ui) from (guix profiles) <civodul>that would be consistent, because show-what-to-build is already in (guix ui) <civodul>so could you make that additional patch? <alezost>civodul: ok, so I'll send 2 patches later: 1. move ‘show-manifest-transaction’ to (guix ui) and 2. add new condition types to (guix profiles) <alezost>civodul: thanks, I'll test it better this time <alezost>civodul: show-manifest-transaction depends on <manifest-entry> record, so it can be just moved :-( <civodul>alezost: could you just change it to use the normal accessors instead of 'match'? <civodul>well, actually <manifest-entry> is exported, so you *could* copy it as is <alezost>civodul: sorry, I didn't get it: all manifest stuff stays in (guix profiles), so I can't use accessors in (guix ui). Do you mean to duplicate <manifest-entry> record in (guix ui)??? <alezost>civodul: oh, wait I've understood: now I can export (guix profiles) inside (guix ui). Silly me :-) <civodul>alezost: no, i mean just #:use-module (guix profiels) in (guix ui) *civodul goes afk for a couple of hours <alezost>civodul: yes, i meant use-module, not export ***drewc1 is now known as drewc
<civodul>davexunit: i've add you as an admin on sv.gnu.org, FYI ;-) <mark_weaver>civodul: is 'acl' a package that can be changed in master, or only core-updates? <mark_weaver>I'm afraid that our acl package is completely broken <mark_weaver>we don't install libacl (that requires a separate make target "install-lib") <mark_weaver>also, there's an error that happens during the build because of calls to /bin/sh, but for some reason that error is ignored. <mark_weaver>civodul: more generally, is there an easiest way to see the list of packages that would have to be rebuilt if we change package X ? <civodul>mark_weaver: yes, run "guix refresh -l acl", IIRC <civodul>but i suspect it gets it wrong for core packages, which acl is <mark_weaver>civodul: acl only installs executables that fail for lack of libacl :-( <civodul>well, let's fix that in core-updates then <mark_weaver>I think it's just that when users run guix on top of another system, the host provides a libacl to link with, maybe. <mark_weaver>or maybe it's just that most of us don't use acls :) <mark_weaver>"make install-lib" is needed, and I suspect that's not new. <civodul>i don't use ACLs, but the goal was to make it possible <mark_weaver>the only reason I noticed is that emacs 24.4 will have acl support, so I added "acl" as an input, but noticed that it failed to find the library. <bavier>civodul: I was considering reformulating "guix refresh -l" in terms bags. I think that would take care of the dependency tracking of core packages. <civodul>bavier: i was about to suggest it :-) <civodul>i just tried "guix refresh -l cmake" and it said "nothing" <civodul>mark_weaver: i'm ok with the CMake patch bavier posted; the only thing is that MIPS is still lagging behind <mark_weaver>oh, you mean just that the build machine isn't able to keep up? <civodul>but that'll always be the case as long as there's just one MIPS machine <mark_weaver>at some point, we might want to consider having a "stable" branch that has less churn. <mark_weaver>and here I'm no so much thinking about fewer rebuilds, but rather something that only security updates and other minimal fixes are applied to, for basing production systems on. <civodul>yes, we'll need a 'stable' branch, but perhaps it's too early still <civodul>well it's never to early for stability, but maybe too much burden at this point <civodul>mark_weaver: alezost hit another nasty circular reference issue :-( <civodul>we must really do something in Guile about it <civodul>the problem is that we're stuck with older versions in Guix anyway *davexunit is thinking about writing an package importer that pulls metadata from directory.fsf.org <davexunit>I have 3 monadic procedures to call in sequence, the first 2 only have side-effects, printing to the screen <davexunit>I'm not sure how to apply them in sequence easily <civodul>do the first 2 actually access the store? <davexunit>I've lifted set-build-options-from-command-line and show-what-to-build into the store monad <civodul>i think (store-lift show-what-to-build) already appears a couple of times :-) <civodul>for some reason, i sometimes fail to deduplicate things <davexunit>I see the identifier '%' used in mlet*, is that a convention for procedures whose return value doesn't matter? <civodul>i think that was just to avoid a clash with '_' == 'gettext' <civodul>i wanted to rewrite mlet to really bind nothing when there's a literal '_' <davexunit>but yeah, I really don't care about the return value for those first 2 functions. I guess I just bind them anyway? <civodul>i thought about adding 'mbegin' too, but that seemed only marginally useful <civodul>anyway there's room for improvement, so perhaps with your fresh eye you'll have better ideas <davexunit>I guess it would be nice to have a form where I could evaluate monadic procedures in sequence and discard their return values. <davexunit>though I don't really know how to discard the return value in a monad. <civodul>but do you typically discard all of them, or just some? <davexunit>well in this case I'm actually discarding all of them. I thought it was just 2/3, but I also don't need the value from built-derivations <davexunit>maybe the result of the form would be the result of the last procedure? <davexunit>(this is what I get for not seriously studying monads before this) <civodul>so it will be (mbegin %store-monad (do-foo) (do-bar)) <davexunit>I'm going to rebase my branch on master so I can use it. and then hopefully have a preliminary version of 'guix environment' to send to the list. <paroneayea>davexunit: maybe another reason for me to start contributing to guix: maybe I can figure out how monads work? :) <davexunit>haha. yeah I'm using this as a practical introduction to monads. <davexunit>it's really interesting, but confusing at first. <davexunit>but so are most useful computer science topics. <davexunit>actually, monads are just too confusing. let's rewrite this in nodejs. *davexunit forks guix on github *davexunit names his fork "package-awesome" <davexunit>the kids like software projects with "awesome" in the title these days <davexunit>that one doesn't fit the trend, though it has 'awesome' in the name <paroneayea>similarly, freedeb's apartment is named "Fort Awesome", but predates the trend by several years :)