<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 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!
<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>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: 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.
<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".)
<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>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