***heroux_ is now known as heroux
<zacts>I wish there was a `guile-install` command for guile libraries out-of-the box <zacts>I know ijp has a nice repo for libs <zacts>but a nice command would rock, and having official package repos like emacs now has, would be sweet I'm thinking <zacts>chicken scheme has a chicken-install command <zacts>for chicken modules (aka. eggs in their lingo) <zacts>ACTION slaps his wrist with a grammar police ruler <zacts>although, for stylistic reasons 'were' sounds too dreamy to me <zacts>perhaps I'll use was after all ***mario-go` is now known as mario-goulart
***_zxq9_ is now known as zxq9
<davexunit>did anyone in the guile dev room at FOSDEM happen to catch the (potentially hostile) talk about why the Awesome window manager chose Lua and not Guile? <kwrooijen>I did, but it sounded more like "Why I chose Lua" instead, since Python was also in the list. But I think the answer was that he felt that Guile wasn't mature enough at the time and it was difficult to get set up. And Lua was more accessible to new users. <kwrooijen>At least that's what I've understood from it <peterbrett_work>The vast majority of talks I wanted to go to were in rooms that were so full that there were as many people standing outside as inside...! <davexunit>as an outsider, the talk title seemed a bit antagonistic due to the pairing of Lua and Guile in the same room. <kwrooijen>Yeah I was surprised that the Guile room was completely full during almost all the talks <davexunit>peterbrett_work: yeah I hear every year that FOSDEM has far outgrown its venue. <kwrooijen>Nice talks though, I'm also looking forward to the videos to simply rewatch some of them <davexunit>yeah I'm hoping the videos become available without too much delay. I'm eager to watch all of the guile talks. <civodul>davexunit: the FOSDEM folks are pessimistic about video capture for talks "before lunch time" they say, so don't hold your breath :-/ <civodul>the talk about awesome was not hostile at all, BTW <civodul>it was really interesting to get feedback from someone who's not a PL person, and who's not sold to Lua, Guile, Python, or anything <davexunit>civodul: but that's good to hear about the Awesome talk. <davexunit>civodul: were there any new folks interested in guile or guix as a result of the talks? <davexunit>I was checking twitter for mentions of guile or guix. only saw a few things. <civodul>during the opening we asked people what they were here for <civodul>some of them were interested in Guix, others were using Guile, others were just curious <civodul>FOSDEM spans like 5 or 6 buildings now <kwrooijen>I was there simply because I was interested in Guile, but after these talks I'm completely sold on Guix <civodul>oh, cool, thanks for your feedback :-) <civodul>peterbrett_work: to bad we didn't meet! <peterbrett_work>I spent the whole day queuing (often unsuccessfully) to get into talks that I wanted to attend that were relevant to $dayjob <davexunit>there were several "the future of distros" talks. I wonder how those went. <davexunit>there was, predictably, a large focus on containers aka frozen pizzas <davexunit>but I don't know if those distro talks advocated for or against this. <civodul>there was one corporate talk from RH about that <peterbrett_work>As I was mentioning to wingo a week or so ago, there don't seem to be many projects embedding Guile as deeply as gschem is <civodul>after 37mn, you understood that it was all about stripping the distro and leave applications to Docker <peterbrett_work>I know there were no gschem devs in the Guile room and I'm not sure if any Lilypond devs were there <civodul>peterbrett_work: i think there was one Lilypond person <davexunit>I remember one of their employees giving a lightning talk about it at a small Software Freedom Day event in 2014. <davexunit>but they are using the same fundamental ideas <peterbrett_work>I like the idea of running nicely compartmentalised services etc. managed by systemd <davexunit>and they are bad for both software freedom and sysadmins <civodul>and CoreOS is a toy, if i may (sounds arrogant!) <peterbrett_work>Given that CoreOS is already running on deployments with 100,000s of machines, I think it's gone well beyond a toy. :-) <davexunit>peterbrett_work: its bad for sysadmins because these "containers" are big binary blobs. <peterbrett_work>Unless you as a sysadmin are building the containers, and then using your hardware as an abstracted platform to ensure that the same containers are being run everywhere <davexunit>they are opaque disk images. run many of them, and you have many copies of the same stuff, or maybe some different stuff, but you have no real way to inspect them and maintain them. <davexunit>no one that uses Docker is building their own binaries. <peterbrett_work>Yes, I'm not using Docker, I'm using lightweight systemd-nspawn containers <davexunit>I think it's important to make a distinction between "container" as a virtualization tool and "container" as a big disk image that you "ship" <peterbrett_work>And no, not "no one" — if you talk to anyone who uses containers in environments where reliability matters, they're building their own container images <davexunit>I am a proponent of the former, and an opponent of the latter. <peterbrett_work>Lots of people use them, they find them useful, they arguably have very clear advantages for the people who choose to use them <davexunit>that may be, but Docker, like Windows, is ultimately harmful to user autonomy and control over their computing. <davexunit>Docker is one of those that I increasingly have to use at my day job. <peterbrett_work>Absolutely. But just because they have a different cost function to you doesn't mean their cost function is wrong. <peterbrett_work>ACTION is very aware that Docker is a tool that is far too easy to use badly <civodul>peterbrett_work: what i mean is that the two-partition scheme they use for rollback doesn't sound like a great foundation, nor even a great feature <davexunit>Guix in many ways is technically superior to Docker, CoreOS, etc. <peterbrett_work>civodul: It's sounds like a pretty pragmatic solution that has a good chance of being quite reliable in practice <civodul>dunno, doesn't sound that compelling to me <davexunit>an upgrade system like that must require a reboot right? <peterbrett_work>Don't forget that CoreOS is designed to run on clusters, not individual servers <davexunit>systems can be upgraded transactionally without downtime. <davexunit>we're currently working on making PID 1 smart enough to handle service changes. <peterbrett_work>As far as I can tell, CoreOS and GuixSD are aiming to solve different problems and *that's okay* <davexunit>I do "DevOps" for a day job, and Guix and GuixSD would solve both my dev and ops problems that no other system (besides Nix) I know of can. <davexunit>the reason I am so opposed to CoreOS and the like is that their solutions have a tangible negative effect on the future of GNU/Linux distributions. <peterbrett_work>On a practical note, can I use (parts of) Guix to cross-compile gEDA for Windows? <davexunit>peterbrett_work: hmm, not sure. we don't have a windows port. <davexunit>you could use a guix provided toolchain to compile gEDA, certainly. <peterbrett_work>davexunit: Eh, the mingw32 toolchain in the Fedora repos is perfectly adequate <davexunit>but the results of a gEDA guix package build would not be portable to windows. <peterbrett_work>I was more after a Scheme implementation of a multi-package build manager that can handle building both host and target packages correctly <peterbrett_work>If the worst comes to the worst I will probably just go for the "shell script written in Scheme" approach ;-) <davexunit>ooh, the Scheme and FP workshop will be in Japan this year. <davexunit>sounds like a good excuse to make a trip to Japan. <davexunit>peterbrett_work: date hasn't been announced yet <wingo>ACTION landed prebuilt/ while on the train back from fosdem :) <wingo>currently distchecking a release candidate <wingo>it's cross-compiling .go files for mips as we speak :) <random-nick>how is the module that holds the posix network wrappers called? <wingo>random-nick: sadly, those bindings are all in the root namespace <wingo>or maybe not sadly for you :) <random-nick>well, it's not sadly for me but it's sadly for u in guile <random-nick>also why does the site advertise work on lua support when the last commit on the lua branch is in 2013? :/ <wingo>hoo, this is so great that i can actually distcheck a tarball in some 15 minutes, whee <wingo>gah, guix environment guile doesn't include all the texinfo things you need for distcheck; grumble <davexunit>wingo: yeah, because that guile package builds a tarball. <davexunit>wingo: suggestion! I have been including 'guix.scm' files in my guile projects that have a development package suitable for 'guix environment -l guix.scm'. would you like to add one for guile? <davexunit>that way we would have something that would contain all the autotool/texinfo stuff <wingo>davexunit: yes that would be great! <wingo>what's the deal i wonder with the commit in the package file <wingo>it means you'll never have a repo whose guix.scm actually refers to the HEAD <davexunit>here's what I do: make new commits that add real stuff, then add another commit on top that bumps the dev snapshot to HEAD~ <davexunit>Guix does the same to update the guix-devel package. <wingo>that's not so bad, but it's sufficiently far from what i want that i think i'll pass for now <wingo>i prefer to develop based on profiles that list dependencies. dunno tho <wingo>having to list dependencies in two places is silly tho <wingo>alternately. it would be nice to be able to specify the HEAD of a local git tree to build a package <wingo>i was able to do that at one point but then failed later on <wingo>jeez this is the worst bug report ever <wingo>i don't even know how to reproduce the issue :) <wingo>but if i didn't have to type that damn hash into a file when i just want to build from a local git tree, that would be nice :) <wingo>oh well, it has to fetch texlive from hydra. so much for a prerelease tonight :/ <davexunit>guix environment texlive -- guix build --no-substitutes texlive