IRC channel logs


back to list of logs

<mark_weaver>time to update guile in core-updates :)
<mark_weaver>ph4n70m4s: 'string-prefix?' would be a bit more appropriate here, but either way...
<civodul>yay for Guile! :-)
<Steap>damn, I got the bastard to compile
<rigelk>civodul: compilation of the hello package failed. Damn it.
<Steap>that libgcrypt thing is always a bit of pain, since it's in a weird location in Debian
<Steap>I think I had to built ligcrypt using a Guix tarball the first time
<Steap>before I could build from the git repo
<rgc>hi, today I was thinking that guix approach to package managing could be used to replace Ruby bundler, Emacs Cask, etc... like using different 'sets' of packages. Is there anything in that direction?
<civodul>Steap: re libgcrypt/debian, we should have --with-libgcrypt-libdir or something like that
<civodul>rgc: what's Emacs Cask?
<civodul>rigelk: could you send the tail of the build log to guix-devel?
<davexunit>rgc: I write ruby for a living, I hate bundler!
<davexunit>the ruby gems situation is awful.
<Steap>civodul: yeah, but it does something even weirder, can't remember the details
<Steap>civodul: it's something like "we'd look in $prefix/libgcrypt/ to find the .so, and it's in $prefix/"
<Steap>or the other way around
<rgc>agree, but it's a problem to solve, not only in ruby. perl, python .... they also have their versions of this application that 'packs' and remembers a set of libraries with their versions
<davexunit>ruby has the other unfortunate problem of needing crazy tools like rvm to manage different versions of ruby on the same machine.
<civodul>Steap: yeah, because we only provide --with-libgcrypt-prefix
<davexunit>rvm takes over your 'cd' command! madness!
<civodul>rgc: there seems to be some overlap with Guix, but nothing specific is being done in that area
<civodul>well Guix has some support to make it easy to build Python/Perl packages, for instance
<civodul>good night/day!
<rgc>davexunit: yup, I also do ruby and all those tools drive me mad ...
<Steap>I have no idea of how to install a Ruby package properly
<davexunit>rgc: do you ever feel that ruby is very poorly integrated with the rest of the operating system? it just *feels* foreign.
<rgc>yup. I came from Perl, and well... they approach these things a bit differently, the language itself. they respect backwards compat a lot more
<davexunit>I like the parts of ruby that were borrowed from lisp, but they didn't go far enough. no first-class functions!
<rgc>although I don't know how other languages do it. Lua is not very good at that either
<davexunit>blocks, procs, lambdas...
<davexunit>I dislike lua as well.
<Steap>who doesn't ?
<rgc>lua is cool. I like it quite a lot. very KISS
<davexunit>game developers.
<rgc>I like that it's very small
<davexunit>I tried to embed lua scripting in a program before I ever knew of Scheme and Guile.
<davexunit>lua's API drove me mad and guile's was quite pleasant.
<Steap>rgc: one nice thing about it is that it allowed non-programmers to program stuff
<Steap>I hear it's widely used in World of Warcraft, for instance
<Steap>people seemed to be able to learn the basics quickly and write scripts that did what they needed
<rgc>davexunit: I only did a *very* basic integration of both lua and guile (same app in fact :p) and guile felt much better
<rgc>but I like the whole lua source is 20k lines. Makes it very hackable
<davexunit>that's true.
<rgc>btw, I recently started hacking a bit on clojure, and lein feels super great (opposed to bundler/rvm/capistrano/foreman/watheverElse)
<davexunit>I haven't used clojure.
<davexunit>it looks fine, but something about it doesn't attract me towards it.
<davexunit>that said, it would be cool to be able to use a lisp professionally and clojure is the best bet in that regard.
<davexunit>unless I made my own business, in which case I would use guile. :)
<mst>davexunit: frankly, perl makes a better lisp than ruby
<mst>since perl actually has proper lexical scoping and function closures
<mst>I had some code at one point that used guile w/call/cc to do co-operative top level logic threads on top of event-driven perl code to do parallel processing without getting myself into event hell
<davexunit>mst: neat. :)
<davexunit>ruby's lack of real lexical scoping also drives me insane.
<mst>plus the Moose metaprotocol steals a bunch of things like method modifiers and sane traits from lisp
<rgc>the fuck, Matt Trout is here!
<mst>people look at me really funny when I say "perl's a lot like ruby, except slightly less pretty but actually good at functional programming and OO"
<davexunit>and then I also write javascript, where I'm happy to have first-class functions and lexical scoping, but am plagued by a ton of other issues.
<mst>heh, yeah, I'm having a lot of fun with angular though
<mst>I'll have more fun once I finish reading the source
<mst>only about 2/3 of the way through so far
<davexunit>mst: I like angular in some ways, but it's also driving me crazy.
<davexunit>I'll say it: dependency injection isn't pleasant at all.
<davexunit>it's just a buzzword for formal arguments.
<mst>I thought that. then I read the source code to src/auto/injector.js and found everything became clear
<mst>angular doesn't really have a DI system so much as it has a dictionary of thunks that are expected to return the relevant object
<davexunit>also, the default way to do the injection is completely insane.
<davexunit>anyway, this is totally off topic for #guix.
<mst>once you realise it's really not being that clever, it makes reasonable sense
<davexunit>(except for the whole rendering a function to a string to inspect the parameter list thing)
<mst>rgc: I have a soft spot for guile-based stuff, given updating was how I first ended up with a PAUSE id :)
<mst>davexunit: all the code I'm working with uses the standard way of an arrayref with a function at the end
<davexunit>mst: I do that as well.
<mst>using the fallback-to-inspection stuff is obviously a terrible idea
<mst>well, at least, given a language that doesn't give you a sane way to do so
<civodul>Hello Guix!
<ph4n70m4s>hello civodul
<ph4n70m4s>normally my hurd's headers recipe have the flag --host=i686-pc-gnu
<ph4n70m4s>but when I try to build them with my sans free gcc I get the error that gcc cannot create executables
<ph4n70m4s>that's why I remove the host flag in the cross-headers recipe
<ph4n70m4s>but then I get the error *** Host configuration must be `MACHINE-gnu' or `MACHINE-VENDOR-gnu'.
<civodul>what command line do you use to build them with the libc-free gcc?
<ph4n70m4s>./pre-inst-env guix build -e '((@@ (gnu packages cross-base) cross-libc/hurd) "i686-pc-gnu")'
<civodul>ph4n70m4s: could you post your current patch to the list?
<civodul>that would be the most convenient for me
<civodul>because it needs a bit of thought, and it's better to have all the info before my eyes
<civodul>are you already done with University BTW?
<ph4n70m4s>I have a lesson at 2 pm...
<ph4n70m4s>and then at 5pm to 9 pm
<civodul>oh, 9PM
<civodul>that's unusual for me :-)
<ph4n70m4s>yeah here we may have 2 hours in the morning 3 in the noon and 2 in the afternoon
<ph4n70m4s>preparing patch
<civodul>note that i'm at work right now, so typically not very responsive
<ph4n70m4s>in the patch you will see all the changes I did
<ph4n70m4s>it's work in progress so it is a mess in some places :P
<ph4n70m4s>sending it now
<civodul>no problem with the mess, it always starts like this, don't worry :-)
<civodul>ph4n70m4s: i forgot to ask for the build log too
<ph4n70m4s>one sec I am sending it
<civodul>perfect, thank you
<civodul>it's important to make it easy to review and comment changes
<civodul>because the recipient is lazy ;-)
<Steap>That's the one and only thing they should teach in Computer Engineering courses.
<civodul>"the person at the other end is lazy"
<viric>I'm lazy
<viric>grmbl. the new gdb still has the bug I proposed a patch for, years ago
<ph4n70m4s>I sent it
<civodul>viric: propose it loudly :-)
<ph4n70m4s>civodul: I have to go to the university
<viric>I think I never answered this: . Too lazy. :)
<Steap>viric: when I was in school, one of my teachers told me "well, I proposed patches to Gnome about 12 years ago"
<Steap>"Still no answer."
<viric>two weeks ago, mediawiki fixed an issue I reported in 2005 :)
<Steap>The best thing is, you always find yourself whining about people not reviewing patches fast enough
<Steap>And then you become the maintainer of a project
<Steap>and you're just taking ages to review the simplest patch :D
<viric>Right. :)
<viric>I barely ever received a patch for any of my projects though. hehe
<Steap>I started maintaining a Python project for work
<Steap>It was almost dead
<Steap>people saw that there was some activity
<Steap>Bug reports and patches falling from the sky
<civodul>Steap: well, that's primarily good news :-)
<Steap>civodul: hell no, now I have to process all that
<Steap>civodul: btw, now that Guile 2.0.10 is out, I imagine it's a matter of a few days before core-updates is merged ?
<civodul>Steap: i think so, yes
<civodul>BTW, we can do the Python thing later in master if need be, no?
<mark_weaver>civodul: is 'file' something that should only be updated in core-updates? there's a security advisory for it.
<mark_weaver>I haven't yet investigated whether there's an upstream tarball with the fix, or if it has to be applied as a patch.
<civodul>mark_weaver: 'file' can be upgraded in master
<civodul>it's a leaf, so no big rebuild
<mark_weaver>what about bzip?
*civodul just pushed 2.0.10 in core-updates :-)
<civodul>mark_weaver: bzip is for master
<civodul>mark_weaver: bzip is for core-updates
<mark_weaver>I have a TODO of things to fix. bzip man1 pages are being installed in share/man1 instead of share/man/man1/
<civodul>eventually we could automate some of these checks in gnu-build-system, for instance
<mark_weaver>(I went looking around my .guix-profile/ for directories in the wrong place, and made a little TODO)
<mark_weaver>s/made a little TODO/added to my big TODO :)
<mark_weaver>a bunch of packages are installing their man pages in man/ instead of share/man: (ncurses, netpbm, bc, cmake, flac, unzip, netcat, screen). any of those for core-updates only?
<mark_weaver>util-macros is installing into share/pkgconfig/ instead of lib/pkgconfig/.
<mark_weaver>some packages are installing in info/ instead of share/info/: (bc, netcat, screen).
<mark_weaver>I hope to find time to do some of these in the next few days.
<civodul>mark_weaver: ncurses is for core-updates (used by Bash)
<mark_weaver>ah, okay, thanks. I'll make sure to do that soon.
<civodul>i'll send an email in case others have things to do before the merge
<mark_weaver>sounds good
<mark_weaver>I'm also unsure of what to do about gnutls and the system-wide trust store. we seem unable to reach consensus on what do to.
<civodul>i thought we had some sort of consensus no?
<civodul>i forgot the details
<Steap>civodul: that would trigger quite a huge re-build
<civodul>Steap: yeah; so it's better in core-updates, but if it doesn't make it, that's OK
<ph4n70m4s>I am back
<ph4n70m4s>sending the prievious config.log
<ph4n70m4s>checking pkg-config for the macro civodul suggested
<bavier>anyone else have trouble with the libvorbis tests?
<bavier>I think it might be a parallelism thing; I tried with #:parallel-tests? #f and could finally build it
<civodul>hey bavier
<civodul>bavier: i don't remember having a problem with that, but a parallel-build issue is always possible
<civodul>all green here:
<bavier>I'll try building it a few more times with parallel tests
<civodul>mark_weaver: BTW, i really appreciate the new SRFI-64 output