IRC channel logs


back to list of logs

<efraim>gnurl- has this been failing to build for anyone else?
<efraim>test 46 keeps on failing for me
<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
<davexunit>that's what I've been reading
<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>yup :(
<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>here. i was thinking
<next_step>well, maybe a good approach is to choose one or 2 reference devices
<next_step>and get guixsd working really well on them
<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>its probably good to start small
<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
<next_step>asus c201?
<next_step>nope, that uses Rockchip RK3288?
<next_step>but its a good machine
<efraim>yeah, realized i put 3266 instead of 3288
<next_step>that's actually what i had in mind
<next_step>oh ok
<efraim>the real problem with all the arm chromebooks is the tiny storage
<next_step>yeah, that sucks, maybe an SD card
<next_step>could be a decent compromise
<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
<next_step>is it not running celeron?
<next_step>oh no
<next_step>the newest does sport a rockchip
<next_step>the screen might be a tad small though
<efraim>yeah, its only 10.1"
<next_step>microSDs are pretty decent
<next_step>and you can easily get 64 or 128 GB
<next_step>so it could be doable
<next_step>64GB SD is about $30
<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
<next_step>a non-soldered ssd
<next_step>its cheaper
<next_step>just to use an off-the-shelf connector
<efraim>got a straightforward no answer:
<next_step>is that something that can be trusted?
<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 ram thing is not surprising
<next_step>but 4gb is ok
<next_step>the bottleneck is the ssd as you pointed out
<efraim> / on the eMMC, /gnu/store and /home on the sdcard
<next_step>thats probably a nice setup
<next_step>i'd tend to assume both the flip and the c201
<next_step>are very similar hardware wise
<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
<mark_weaver>lfam: does that make sense?
<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 already
<next_step>davexunit: for ELPA
<davexunit>as long as the gem archive indeed has the corresponding source code
<next_step>i see there are some packages
<davexunit>yeah, those too.
<next_step>wouldn't an adapter of some sorts work better
<next_step>automatic generation of packages perhaps?
<davexunit>but we do write importers to generate most boilerplate
<davexunit>'guix import --help' to see all the available ones
<next_step>aha ok
<next_step>sorry for the lame question, im still quite newb
<davexunit>no problem
<davexunit>a ruby gem, for example, can't specify the non-ruby examples, so packagers have to be sure to add them.
<next_step>i see
<davexunit>non-ruby dependencies*
<davexunit>some gems need gcc, libxml2, etc. to build
<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
<next_step>and that always annoys me
<next_step>its hard to find things
<next_step>if i want to see the code
<next_step>in their repos
<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's setup information written up anywhere? would love to run my own hydraa
<efraim> i think
<davexunit>codemac: I don't think we do. our setup is a bit "artisinal" right now
<davexunit>since it doesn't run guixsd
<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
<sprang>I wonder how libre-friendly these machines will be?
<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?
<davexunit>rekado-: that sounds reasonable
<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