IRC channel logs


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.
<mark_weaver>well, I think we should implement it.
<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>OTOH, XDG_CACHE_HOME is too broad
<civodul>can't we put something like <getenv>FC_CACHE_HOME</getenv> in
<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.
<civodul>yes, exactly
<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>
<mark_weaver>civodul: yeah
<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.
<civodul>cool, thanks
*civodul goes off
<civodul>good night/day!
<mark_weaver>if fontconfig doesn't allow this to be done, then we could add the functionality and submit it upstream.
<mark_weaver>but hopefully that won't be necessary.
<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.
<mark_weaver>ah, yes, of course. that might work!
<mark_weaver>yeah, your solution sounds good to me.
<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.
<mark_weaver>I have to go offline for a while. happy hacking!
<supp3r>Really cool project! Congrats!
<a_e>supp3r: Thanks!
<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.
<a_e>Time to go!
<davexunit>someone probably posted this already, but the 0.5 release announcement is on hacker news:
<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.
*mst waves
<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
<solrize>does guile have macros?
<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>solrize: or if you have it installed, (info "(guile) Top") :)
<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>(From (info "(guile) Fly Evaluation").)
<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
<taylanub>Is an "informal term".
<taylanub>mst: Is it Kernel that you were using ?
<mst>taylanub: I ported manuel's wat-js to perl - but Wat is very much a kernel derivative
<taylanub>JS .. Perl ..
*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".)
<taylanub>(*other than another Lisp)
<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
<taylanub>mst: Mind if we move to PM ?
<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>fair enough
<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 think.
<phant0mas>let me check
<phant0mas>I fixed that one
<phant0mas>and which module do I need for patches?
<phant0mas>I get the error with search patch
<phant0mas>the same*
<jmd>I thought that was the one you needed.
<phant0mas>the first warning is gone
<phant0mas>now I have only this one
<phant0mas>let me check probably some mistake I did
<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
<civodul>Hello Guix!
<civodul>folks at #nixos pointed out Guix is on HN:
<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>hmm no?
<civodul>did you post something?
<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>it's not limited to HN though
<civodul>i fail to understand how we reached that point
<civodul>but we clearly have to keep working on improving the situation
<davexunit>a lot of people seem opposed to copyleft.
<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:
<civodul>jmd`: can you send a message?
<civodul>so i can look at it tonight
<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>(dbus, udev, FoobarKit, etc.)
<davexunit>ah I see.
<civodul>and at the app-level we miss of course things like GIMP, Inkscape, Evince, etc.
<civodul>which i use occasionally
<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.
<davexunit>find some low-hanging fruit.
<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.
<davexunit>mark_weaver: that's a good idea.
<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>hi sbp, thanks!
<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
<civodul>oh, what error?
<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>yep, -m 256
<sbp>command history is basically: guix refresh; guix package -s python; guix package -i python
<civodul>ouch, maybe even that is not enough
<sbp>I'll try it again from scratch with 512, sec
<jxself>-m 8192 !!! :)
<sbp>oh yeah, that'll go down well in your next release announcement... :-)
<sbp>"Runs perfectly well on"
*civodul has to go
<sbp>how does nix-base32 differ from base32?
*sbp looks at
<sbp>works with -m 512!
<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>mark_weaver: by "base32" I mean whatever the referrent of "base32" is in "Supported formats: nix-base32, base32, base16" from
<sbp>the difference between the nix-base32 and base32 is not further explicated there, so thanks!
<mark_weaver>I'm not sure, to be honest.
<mark_weaver>you're welcome!
<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)
<sbp>noted, thanks
<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...
<sbp>("there's no reason why nobody should add GNU specific stuff" —
<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>all according to plan, taylanub
<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.
<mark_weaver>the register VM is still a work-in-progress though.
<davexunit>eval at your own risk. :)
<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>ignoring work like
<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>#guile is the place to have this conversation
<sbp>yeah, sorry
<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... :-)
<sbp>heh, heh
<davexunit>sort of forgot I was in #guix for a bit there. apologies for spam.
<mark_weaver>no worries
<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.
<viric>it should not happen
<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.
<mark_weaver>I don't see how that would be relevant.
<sbp>civodul: hey, -m 512 worked. thanks for the tip!
<civodul>sbp: thanks for letting me know
<civodul>now we really need to fix that :-)