<efraim>gnurl- has this been failing to build for anyone else? <davexunit>does anyone here have a recommendation for a good linear algebra C library? <davexunit>my needs are quite simple: efficient 4x4 matrix-matrix multiplication and matrix-vector multiplication. <davexunit>I ask here because we have some bioinformaticians in attendance ;) <davexunit>currently using GSL, maybe that's "good enough" <bavier>davexunit: for 4x4 matrix operations GSL is probably overkill <bavier>it would eventually call out to BLAS library <bavier>which would still be overkill for 4x4 <bavier>I think GCC would be able to optimise a simple triple-nested loop fairly well <davexunit>this is for a guile application, and I'm considering just writing a small C extension to ship with it. <davexunit>but I'd rather just use an existing library. <davexunit>but I can't find one that is small and targeted at 3D graphics. <bavier>davexunit: I was thinking GLM, but it's C++ <davexunit>I'm hesitant to ship C code with my primarily Guile code because it makes it that much harder for others to use my stuff, but I feel like I have no other good option. <bavier>davexunit: what about a C extension would make it harder for others to use? Just curious, as I've little experience with that part of Guile, though I had always thought C extensions were one of its features. <davexunit>it's no longer pure guile, so now they need a C compiler to build things. <bavier>many take such a thing for granted I suppose <next_step>we had a nice chat yesterday about ARM, libreboot and guix <next_step>well, maybe a good approach is to choose one or 2 reference devices <next_step>some ARM distros like arch arm do this and enjoy decent success <next_step>if one goes for these quite exotic architectures <next_step>on the other hand some nice freedom respecting laptops are hard to comeby <next_step>so it'd be nice to have guixsd running on something free and easy to buy <efraim>last I checked rockchip cpus are in the mainline kernel, I believe there is a chromebook using the rockchip 3266 that looked ok <efraim>yeah, realized i put 3266 instead of 3288 <efraim>the real problem with all the arm chromebooks is the tiny storage <efraim>everything is compiled in /tmp, so that would have to be on good storage <efraim>there's also the asus chromebook flip for an extra $100 <efraim>Q&A on amazon suggests that you may be able to replace the ssd <efraim>might want to take that with a grain of salt, asus rep also said you can download steam <next_step>well, there's not much info around regarding these rockchip machines <next_step>i'd bet its not so unlikely for them to have <efraim>its asus's online rep, so not really <efraim>they did mention in another question that the ram is soldered on <next_step>the bottleneck is the ssd as you pointed out <efraim> / on the eMMC, /gnu/store and /home on the sdcard <next_step>i'd tend to assume both the flip and the c201 <next_step>so supporting one would bring the other almost for free ***davi_ is now known as Guest4668
<lfam>Can someone take a look at this warning I got when installing a WIP package definition? <lfam>It's warning about a collision in the store? <DusXMT>lfam: not in the store, but in your profile <DusXMT>it should be harmless in most cases <lfam>I'm just trying to understand it. It doesn't seem to be a hash collision. So is it a package name collision? <DusXMT>lfam: lib/perl5/5.16.1/x86_64-linux/perllocal.pod is in both git-2.4.3 and irssi-0.8.15, and when creating links for the packages into your profile, it needs to pick one of the two to put it in <mark_weaver>lfam: building a profile involves producing a union of all the /gnu/store directories in the profile <mark_weaver>and sometimes two store directories have the same file in the same relative subdirectory <alezost>lfam: it means that both "irssi" and "git" have a file with the same name (lib/perl5/5.16.1/x86_64-linux/perllocal.pod) <mark_weaver>a simpler example of a collision that might occur is this: if you install both 'emacs' and 'emacs-no-x', they both contain bin/emacs <mark_weaver>so if you try to install both of those in the same profile, then the question arises: which one should be put in ~/.guix-profile/bin/emacs ? <mark_weaver>and in this case, the question is, which file should be put in ~/.guix-profile/lib/perl5/5.16.1/x86_64-linux/perllocal.pod <lfam>Yeah, that's basically what I thought, I just wanted to make sure I really get it. <lfam>So, there are two binaries in the store. They have the same name and are both supposed to be able to satisfy the same dependencies, but they are different byte-for-byte (just checked this). <lfam>And I believe (based on guix/build/union.scm:89) that the resolution technique is to pick the first one? <mark_weaver>lfam: it is indeed currently based on the order that the packages are listed in the manifest <mark_weaver>when using the command line "guix package -i <package>", the most-recently installed package takes precedence <mark_weaver>In "guix package -I a b c", c takes precedence over both b and a and anything installed previously. <mark_weaver>I don't remember offhand how this relates to manifests written by hand <mark_weaver>lfam: you're certainly right that union-build gives precedence to store items earlier in the 'inputs' list. <mark_weaver>and I guess that probably corresponds to packages earlier in the manifest <mark_weaver>but I don't know that we intend to keep that policy, or even to document it. really, we should work to avoid conflicts. <next_step>what's the policy for packages from "secondary" package managers, like ELPA or ruby gems? <davexunit>next_step: we package things from rubygems.org already <davexunit>as long as the gem archive indeed has the corresponding source code <next_step>wouldn't an adapter of some sorts work better <davexunit>but we do write importers to generate most boilerplate <davexunit>'guix import --help' to see all the available ones <next_step>sorry for the lame question, im still quite newb <davexunit>a ruby gem, for example, can't specify the non-ruby examples, so packagers have to be sure to add them. <davexunit>so we have to write recipes that include them <next_step>well, guix has one thing that seems silly but makes it much simpler than nix <next_step>nix puts packages inside folders with odd categories <davexunit>I find their ad-hoc language problematic in general, which is why I hack on guix instead. <next_step>well, scheme is much more friendly / powerful <next_step>their DSL should have been implemented on top of another language <codemac>wow - I've been running guix a long time not realizing the difference between `guix pull` and `guix package -i guix`. I had only ever ran the first. today is looking like a noob kinda day. <codemac>is hydra.gnu.org's setup information written up anywhere? would love to run my own hydraa <davexunit>codemac: I don't think we do. our setup is a bit "artisinal" right now <davexunit>the packaging work has been done for Hydra now though I think <davexunit>so in the near future we could have a reproducible config for it <mark_weaver>yeah, our current hydra required a lot of manual tweaking, and is a mixture of trisquel and guix and some manually installed packages with custom mods <mark_weaver>obviously we'd like for it to be running GuixSD with a reproducible config <anthk_>thanks to GUIX I have a more up to date MESA on my trisquel setup, and flightgear runs faster. Thanks to everyone, this is amazing <rekado->for Friscobaldi (a graphical Lilypond editor) I need libpoppler-qt4, which is installed by poppler only when qt4 is among the inputs. <rekado->I think it would be bad to add a qt4 dependency to all those innocent poppler-using applications. <rekado->would it be preferred if I created a poppler-qt4 package inheriting from poppler? <mark_weaver>rekado-: sounds good to me. I agree we should avoid making dependencies on Qt ***exio4 is now known as hacker
<bavier>I'm surprised we don't have denemo packaged yet