IRC channel logs
2013-12-12.log
back to list of logs
<a_e>Your solution forces the user to modify environment variables; my solution works out of the box, but only with the default profile. <mark_weaver>hmm, again that seems suboptimal, if we want to support multiple profiles. <mark_weaver>well, the user already has to set many environment variables in Guix in order for things to work properly. <mark_weaver>also, what happens when something tries to use fonts during a build, where $HOME is set to /homeless-shelter ? <mark_weaver>anyway, I admit that setting $XDG_CACHE_HOME to an immutable directory is probably not right either. <a_e>And in both cases, we would need to execute "fc-cache" after installing a profile, which is not yet implemented. <civodul>i agree that it would be best to avoid doing something specific to the default profile <a_e>For fonts during builds, we used a dirty trick: fontconfig has gs-fonts as an input and a path to them is hard-coded into the configuration file. So at least the ghostscript fonts are always available. <civodul>can't we put something like <getenv>FC_CACHE_HOME</getenv> in fontconfig.cf? <mark_weaver>I think the ideal solution would be to change that first <cachedir> entry to something that depends on an environment variable: one that we can recommend that users set to an immutable directory in the profile. <a_e>We also need a solution for the <dir> that points to .guix-profile/share/fonts. <mark_weaver>there's one entry that uses an environment variable: "<cachedir prefix="xdg">fontconfig</cachedir>". I wonder what other values of 'prefix' are supported. <civodul>so <cachedir><getenv>FC_SOMETHING</getenv></cachedir> <civodul>a_e: but if the XML file allows us to specify env vars like this, it's even better <a_e>I am reading the doc. <mark_weaver>if fontconfig doesn't allow this to be done, then we could add the functionality and submit it upstream. <a_e>As far as I can tell, only xdg is allowed; <a_e>it stands for XDG_DATA_HOME in the <dir> and for XDG_CACHE_HOME in the <cachedir> context. <a_e>What we could do is to create a configuration file inside the user profile, set the environment variable FONTCONFIG_FILE to this file and execute fc-cache. <a_e>Then the user would also have to set FONTCONFIG_FILE. <mark_weaver>hmm. when a profile is created, does it know where in the user's directory the symlink will be put? <mark_weaver>the relevant code is in fontconfig-2.10.93/src/fcxml.c, line 2032, in the FcParseCacheDir function. <a_e>The profile does not need to know about symlinks. When creating the cache, we can use the absolute path for FC_CONFIGFILE. The user could use a relative path starting with $HOME/.guix-profile. <a_e>Right, line 2032. Good catch! <a_e>We just need something like post-install hooks. <mark_weaver>I think guix/guix/build/union.scm is the relevant code that needs to be made smarter. <a_e>Once the profile is created and it contains fontconfig, then we need to write the configuration file into the profile, run fc-cache (but only _after_ installing all fonts also) and warn the user about setting FC_CONFIGFILE. <mark_weaver>we need something there to merge share/info/dir files as well, and probably a bunch of other things too. it should be extensible. <a_e>It will not be easy to determine the order in which things need to be executed. <a_e>If the post-install of one package should be executed after that of another one. <a_e>This looks a lot like the logic of init scripts to me... <mark_weaver>I don't think it's quite right to think of these as "post-install" scripts. every time a profile is created, these things will have to be run for everything in the profile, even for packages that weren't just installed. <a_e>You could interpret every profile creation as an installation of all its packages. <a_e>But we mean the same thing, maybe "post-install" is indeed not a good terminology. <a_e>Still, my original icecat problem is not solved! <a_e>fc-list lists all my ghostscript and truetype fonts now. <a_e>But in icecat, preferences->Content->Default font still lists only the gs fonts. <mark_weaver>maybe run icecat within strace and see where it's looking? <a_e>Good point. I was still working with a modifed environment. <a_e>It looks at the fontconfig cache files. <a_e>It looks into the gs and truetype font directories. <a_e>And in the end, it opens a gs font. <a_e>Actually, it does work! Nice! <a_e>At least, I can choose fonts in icecat. Difficult to tell whether they are used, as most css define their own font nowadays. <a_e>strace shows it opens the font. Very good! <a_e>The icecat start page is a good tester, as it uses just the default font. <a_e>So if anyone feels like reading the thai wikipedia, I would recommend to install freefont-ttf (and to run "fc-cache -r"). <a_e>It also works for georgian, but not for chinese and japanese. <evbogue>I'm installing Guix on Arch (ahem, GNU)/Linux right now. Let's see if it works! No questions yet. <solrize>what's the relation (if any) between the guix and nixos projects? why the fork? *gzg tries to figure out how to get a graphical environment going in the VM. There doesn't seem to be xinitrc in the repo -- and that is where his knowledge more-or-less extends. <gzg>Ah, looks like I just need to write a .xsession file? Xinitrc, looks pretty much just a comestic script. <taylanub>solrize: Guix (the package manager) is just a Guile front-end to Nix. That in itself is probably not a fork-worthy difference, but isn't the only thing Guix has to offer either (there's more Guile-integrated tools; DMD the init system comes to mind); I guess we could say the main point of Guix is to be a GNU+Linux distro distributed by FSF/GNU. <mst>I'd point out that guile-instead-of-the-nix-language is actually the reason I'm here <mst>pure functional build system: good <mst>pure functional build system I can metaprogram with lisp macros: really interesting <taylanub>Guile is mainly a Scheme implementation, and supports syntax-rules and syntax-case hygienic macros. <mst>and of course so long as you have eval you can build unhygeinic macros <taylanub>I think someone did or was planning to port Racket's syntax-parse .. not sure. <mst>albeit it's not -really- something you need very often <taylanub>mst: I think there's different types of unhygienicity ... <mst>IME it's a nice security blanket that I know I could build unhygeinic macros ... which means I know I'm not screwed if syntax-* *can't* do it, but then while I'm trying to prove it can't I always figure out how to <solrize>how does eval work in guile? you have to pass the environment? <mst>though I'm a trifle rusty, having been using an fexpr based lisp a lot recently <taylanub>For instance `quote' is an unhygienic construct because it uses the source-form of its operands instead of their local semantical meaning within the language. <taylanub> -- Scheme Procedure: eval exp module_or_state <solrize>hmm i thought hygienic just meant it didn't capture any free variables at the call site <taylanub>solrize: I'm not sure if there's an agreed-upon concise meaning, but the meaning I was using is "is agnostic towards the source-form of its operands, only concerned with their otherwise language-tied meaning" or so .. not sure how to better phrase *taylanub checks J. Shutt's dissertation, it always uses super-precise definitions and cites their origin. <taylanub>H.P. Barendregt, "Introduction to the lambda calculus", Nieuw Archief voor Wisenkunde 2 4 (1984), pp. 337-372 <mst>taylanub: I ported manuel's wat-js to perl - but Wat is very much a kernel derivative *taylanub 's stomach turns :P <mst>would you be happier if I implemented it in C? <mst>(I'm pretty sure there's also a wat implemenation in python now) <taylanub>If you were going for a "serious" implementation that wants to be efficient and all, C would be an obvious choice, otherwise I don't get why one would implement a new Lisp in any high-level language than another Lisp. <taylanub>(Using a vague definition of "high-level" that means "higher than C".) <solrize>i saw something like that in haskell <mst>taylanub: I guess if you're interested in lisp only as a theoretical tool that makes perfect sense <mst>I'm interested in lisp in production, which means that being able to write top level code in an fexpr based lisp but still leverage existing ecosystems is important <mst>then again, people regularly accuse me of writing perl code that looks more like lisp than perl <taylanub>Oh, so a Wat written in JS/Perl/Python gets to use libraries of those languages ? In that case it would make sense. <mst>right, my implementation auto-wraps even <mst>so I can write, in perl, $wat->eval([ 'set!', 'foo', sub { ... } ]); <mst>then inside wat [ foo 1 2 ] to call the subroutine <mst>fundamentally, I find perl a much more comfortably language to write grungy systems-level I/O and etc. heavy stuff in <mst>and lisp a much more comfortable language to write high level logic in <mst>so I figured why not have both :) <mst>(in fact, most of a decade ago, I maintained the perl<->guile bindings for a bit ;) <mst>taylanub: that make a bit more sense? <taylanub>Sure. I just didn't expect anyone to actually try and use Kernel "in production." Are you using it for anything serious already ? <mst>I have a prolog-style dependency solver built in it ... that desperately needs an optimisation pass <mst>it'll probably be another few months before it's in production, as such <mst>taylanub: also, it being fexpr based has this really lovely thing where throwing a function call over the wire to a different system kinda just works <taylanub>mst: I don't understand the correlation... <mst>being operative rather than applicative means I don't need a special form to mark something as "don't evaluate this here, I'm sending it across the wire" <taylanub>Oh, but that's just the same as quoting it, no ? <mst>I think you're missing the point. the point is that I don't have to quote it. it just works. <taylanub>And the moment you want to insert the result of some evaluation into the output stream, I imagine it would actually be more cumbersome in Kernel than with quasiquotation. <taylanub>mst: I don't see a significant difference between (remote-eval foo) and (remote-eval 'foo) :) <taylanub>BTW I wonder if we should move to a different channel ? <mst>yeah, that's because you're not thinking complicated enough <mst>I mean ... you could make the same argument about macros versus function calls <mst>but as soon as you go beyond the simplest cases, having the same syntax for calling both is really nice <mst>if you prefer; I was assuming we'd shut up if a relevant conversation started, but either way :) <taylanub>I know some people like to read back-logs of channels they're in. <mst>I've been IRC-ing on too many channels long enough I just page past the bits that don't interest me <phant0mas>guys how do I tell guix to apply a patch in a recipe? <jmd> (patches (list (search-patch "my.patch"))))) <jmd>In the (source ...) list <phant0mas>why am I getting the warning "warning: possibly unbound variable `search-patch'" <jmd>There's some module you need to use. <jmd> #:use-module (gnu packages) <jmd>I thought that was the one you needed. <phant0mas>"warning: possibly unbound variable `patches" <jmd>phant0mas: Post your code. Maybe there is something wrong with it. <phant0mas>jmd: going to a lesson right now, I will post it the moment i come back <davexunit>I posted this yesterday but no one seemed to be here. :( <davexunit>it *was* on the front page for awhile, but it is no longer. <jmd>Aren't all items on the front page, at least for a while? <civodul>the comments there are often terrible <jmd>civodul: Did you get a chance to look at that problem with the libxml2 cross compilation? <civodul>i don't remember seeing libxml2-related issues <civodul>(but note that i'm at work currently) <davexunit>HN users are typically not friendly towards GNU <civodul>i fail to understand how we reached that point <civodul>but we clearly have to keep working on improving the situation <civodul>it's like some find it more subversive to be against copyleft <jmd`>Well it's not libxml specific. I've seen the problem in other places too: <jmd`>(assoc-ref inputs "libc") returns #f when cross-compiling. <jmd`>Sure. I don't need an immediate solution. just nice to know if I'm doing something wrong or what. <davexunit>I wonder if the situation can be improved at all. :/ <civodul>jmd`: ah right, i'll check that later, but do ping me if you don't hear from me <davexunit>does anyone develop guix by working from a minimal base system and use guix for everything/ <davexunit>I was wondering if a minimal install of parabola or something would be a good choice to start living in Guix. <civodul>davexunit: yeah i'm using it for as much as possible <civodul>and now it covers the majority of my daily use, i think <davexunit>civodul: I would like to do that so I can more easily figure out what I want to package. <davexunit>it will be really easy to notice the holes when I don't have anything to fall back on. <civodul>that's the approach i would recommend :-) <civodul>then currently there are holes for all the "Linux plumbing" things <civodul>because we typically use those from the underlying distro <civodul>and at the app-level we miss of course things like GIMP, Inkscape, Evince, etc. <davexunit>I'd like to keep my debian testing install around, maybe I'll make another small partition for guix development. <davexunit>I will likely focus on the application level. <jmd>civodul: Evince is there isn't it? <mark_weaver>another approach, if you need only find the application-level holes, is to set your PATH so that it _only_ has $HOME/.guix-profile/, and similarly for the other vars. <mark_weaver>admittedly, this approach is not quite as good in some ways, but it does mean that you don't have to go back and forth between two systems. <civodul>yeah Evince is there, but there are problems with GLib's schema thing <sbp>congratulations on the 0.5 release. I'm trying to the system demo in QEMU at the moment <sbp>doing some simple stuff... refresh, search, install <civodul>the demo image is still basic, but i think it's going in the right direction :-) <sbp>yeah. got a build error trying to install python <sbp>still, looking promising <sbp>guix package: error: build failed: substituter 'substitute-binary' died unexpectedly <civodul>did you run with "-m 256", so QEMU provides more RAM? <civodul>'substitute-binary' eats an insane amount of memory ATM <sbp>command history is basically: guix refresh; guix package -s python; guix package -i python <sbp>I'll try it again from scratch with 512, sec <sbp>oh yeah, that'll go down well in your next release announcement... :-) <sbp>how does nix-base32 differ from base32? <sbp>though, when I run python3 it complains that it can't open /dev/urandom — heh <mark_weaver>if by "base32" you mean that specified in RFC 4648, then I know of two differences: there's a different mapping from 5-bit values to characters, and the order in which bits are taken from the bytes is reversed (RFC 4648 starts with the most-significant bit, and nix starts with the least-significant). <mark_weaver>I don't know why these changes were made; we inherited this design choice from Nix. <sbp>the difference between the nix-base32 and base32 is not further explicated there, so thanks! <sbp>I don't suppose any Guile specific extensions are being relied on? <sbp>so it would be possible to substitute in another R6RS compliant Scheme? <mark_weaver>many guile extensions are relied upon, and everywhere the guile module syntax is used, not r6rs. trying to get it running on any other scheme would be a big job. <mark_weaver>(every single file would require non-trivial changes) <taylanub>Perhaps Guix should be advertised as using "Guile Scheme" for its package description language, not "Scheme". <sbp>yeah, that'd help. Scheme extensions are confusing enough even when they are documented <sbp>one of these days somebody will add Hurd stuff to Guile... <mark_weaver>yeah, Guile bindings for the Hurd would be a very good thing. <sbp>instant lisp machine, just add GNU <taylanub>The kernel, the package manager, hopefully soon Emacs .. it feels like Guile really is slowly sneaking into everything GNU, starting from the biggest parts. :) *davexunit laughs maniacally <davexunit>"just add GNU" - that's a pretty cute phrase right there. <sbp>then all that's left is to make Guile faster than SBCL, and win <davexunit>sbp: guile will *eventually* have native compilation. <davexunit>in the short tem, the new VM in 2.2 will bring much better performance. <sbp>oh, there's a VM coming? hmm <mark_weaver>yeah, we recently made a rather large step toward that goal, with the landing of the new register-based VM in git. <sbp>and it's register-based? <sbp>is it much like the Lua VM? <sbp>the performance from the LuaJIT is *insane* <mark_weaver>guile 2.0.x uses a stack-based VM. in the master branch (which will become Guile 2.2.x), it's a register VM. <sbp>I should performance test this. thanks! <davexunit>sbp: I have no benchmarks, but I think LuaJIT will beat the new Guile VM by a good margin. <sbp>sure, I mean LuaJIT actually outperforms SBCL on some benchmarks. it's that good. but it'll be interesting at least to see how the Guile RVM beats the SVM won't it? I mean, does it work 2x faster? 1.2x? 20x? <sbp>nice to get a rough gauge to see how things are going <sbp>I benchmarked a crapload of Scheme and CL implementations recently <sbp>just some naïve tests, but Guile didn't come out of that very well <mark_weaver>performance has not traditionally been Guile's strength, but it's been getting better, and we are aiming for native compilation in the next year or two. <sbp>ugh, more of this stack FUD <sbp>still, nevermind. as long as the new version is faster, can't really complain <sbp>thanks for the link! <sbp>mark_weaver: will there be a JIT? <sbp>also, check out the Quad-Colour mark and sweep algo that was devised for LuaJIT: <sbp>worst thing about Lua/LuaJIT: their VM spec isn't stable! you can't target the VM! <sbp>not only that, but LuaJIT uses a different VM to Lua. you can't run one's bytecode on the other <mark_weaver>I'd like to hear what wingo has to say about your claim that his blog post contains "stack FUD". <sbp>now I'll join it and not say anything because I already said it all here... :-) <davexunit>sort of forgot I was in #guix for a bit there. apologies for spam. <jmd>One thing I don't understand about guix: <jmd>If I say "guix build foo" and it so happens that foo depends on bar... <jmd>So bar gets built, followed by foo. <jmd>But if the build of foo fails for any reason, it seems that the built bar is not saved in the store. <jmd>It gets rebuilt, next time I try the command. <mark_weaver>jmd: that's not been my experience. if I ask to build foo which depends on bar, once bar is built, it's in the store, and stays there even if foo fails. <mark_weaver>I really don't see how it could be any other way. you can't even start to build foo until bar is in the store. <jmd>Oh maybe my daemon is still running with --no-substitutes. <sbp>civodul: hey, -m 512 worked. thanks for the tip!