<g_bor[m]>mbakke: My github repo is not uptodate either, it's one week old. Does it help?
<brendyn>I wish to add more input method stuff. Is it reasonable to merge anthy.scm, ibus.scm and fcitx.scm into a single input-methods.scm ?
<OriansJ>brendyn: well the number of packages per .scm isn't a meaningful question; as the point of seperate .scm files is to allow one to better organize pieces to enable others to know where to go to get the changes they want done. So when multiple programs share a single thought, then they should be grouped together. Otherwise it probably better to keep them seperate
<brendyn>OriansJ: well there is an upper bound because large files cause compilation overhead, and having many small files also would
<brendyn>and it's quite arbitrary how things have been sorted to date
<OriansJ>brendyn: I don't believe that is correct. Unless one overhead for opening a file handle is huge
<brendyn>OriansJ: python.scm was split precisely because of this reason
<OriansJ>brendyn: I thought that had to do with too many unrelated packages being clumped together just because they depended on python
<OriansJ>As for compilation times, there is not difference between 1 huge file, 4 medium file or 1000 small files or 100000 tiny files; especially for languages where cat *.scm > ../temp.scm doesn't break the program
<OriansJ>Source code is for human understanding and organization and incidentally for machines to compile and run
<OriansJ>brendyn: compilation is cheap if you don't do optimizations (M2-Planet compiled by GCC can easy compile 6+MLoc/s)
<brendyn>OriansJ: We are using guile, so what gcc does is irrelevant
<OriansJ>brendyn: yes I know we are using guile but the point isn't about gcc or guile or any particular language. The point is that compilation is cheap, optimization is expensive.
<OriansJ>Turning off optmizations for things that run rarely but are expensive to optimize are where the biggest benefits for improving the build and not reducing the user experience. It requires understanding the performance profile of the code involved and performing basic experiments with the code involved. For example compare the runtime and compiletime differences between icecat with PGO turned on and off; asking yourself is it truely
<OriansJ>justified on any system except a central distribution model.
<OriansJ>It is one avenue which we have failed to take advantage of; we could incrementally add support for various levels of optimization into our package definitions and allow the users to indicate their preference (fast local compile or expensive compile for centralized servers). That way those using --fallback have to wait 8 hours for a package to be built and then installed.
<OriansJ>Is it possible for guix system init file.scm /mnt/ to also setup the first generation of user packages? I know the packages section can be used to install global packages but I am wondering about is there a section for configuring specific users to have seperate packages be installed in their profiles on system initialization?
<pkill9>basically, the modules you would load with modprobe when they're not built into the kernel
<infandum>Hi all, I'm interested in putting GuixSD on my computer. I have a question though: I know GuixSD is beta -- I am fine with this fact, but is the upgrade path simple from version to version? Especially when it leaves beta, can I follow that same upgrade path? If not, is the path well documented?
<vagrantc>it's pretty much a rolling release, so it's constantly upgrading
<infandum>Okay, perfect, as I'm on arch right now.
<infandum>If I use a custom kernel, will that be automatically updated?
<infandum>Or would that have to be manually updated with each release?
<vagrantc>the concept of a release in guix seems more like a somewhat tested snapshot than what i would call a release
<vagrantc>if you're using a custom kernel, you'll updated it when you update it
<vagrantc>linux-libre gets updated with most upstream point releases, from what i've observed
<infandum>guix import seems to support nix repositories -- does that mean I can install packages from the nix repositories?
<vagrantc>it basically just creates a package definition in the guix syntax for packages, it might need additional tweaking to actually do anything
<infandum>vagrantc: So, for instance, it converts a PKGBUILD in arch to a guix recipe kinda thing?
<vagrantc>other than nix, it's pretty hard to draw parallels with other packaging formats ... it's pretty fundamentally different
<infandum>Last question: I'm big into Haskell. I understand that many Haskell people go for NixOS, but I'm also big into emacs and having a whole system in a lispy functional language. I prefer Haskell, but the Nix language to me doesn't seem as feature full as Guile. With this in mind, should I still use GuixSD as a Haskell person or is NixOS better for someone like me?
<kmicu>infandum: we have Haskellers here too. The real question is whether you prefer GNU and ethics in your software :)?
<efraim>I'm not sure how much guix still supports importing nix package definitions, I don't its been tested in some time
<infandum>efraim: Are they all like that? Is guix import with cran and bioconductor up to date?
<efraim>infandum: yeah those are definately in use
<efraim>i think its just the nix one that might not be working
<Thra11>pkill9: A kernel module foo.c will usually have a corresponding CONFIG_FOO option (defined in a Kconfig file), which needs to be set to 'y' (builtin) or 'm' (module) for the module to be built. I believe guix allows you to extend an existing linux definition by specifying/overriding "extra-options".