IRC channel logs


back to list of logs

<civodul>dmd can reboot, power-off, and all that, woo!
<civodul>yeah, not really a distinguishing feature tho
<mark_weaver>it's good to see some progress on it though.
*gzg hates when sites default to non-static binary tarballs.
<gzg>I hate that I can't seemingly have my expression grab from Slim's actual website and flee to sourceforge for this.
<civodul>yeah, some packages have this sort of problem
<jxself>civodul: Can it do those with a delay specified?
<jxself>Reboot & power off & such?
<civodul>not yet
<civodul>there's no stand-alone 'shutdown' command yet
<jxself>I could just do sleep 2h first though, so not really an important thin probbably.
<civodul>now it's just 'deco stop dmd', 'deco power-off dmd', etc.
<civodul>well it'd be cool to have a real 'shutdown' command like the one people are used to
<gzg>civodul: What does "deco" even stand for? :^P
<civodul>"deamon control"
<civodul>yeah it took me a while too
<gzg>civodul: Ah!
<jxself>What is the diff between 'stop' and 'power-off'? The later is clear but is stop supposed to reboot? Seems an off thing to call it.
<jxself>er; odd
*jxself reads up on ACPI
<gzg>Oh yeah, Slim was the expression I got this little spew "CMake Error at /nix/store/b2gji5mkk6wc4qkdi4bw8ssd5nmnl7s5-cmake-2.8.12/share/cmake-2.8/Modules/FindX11.cmake:427 (message): Could not find X11" and was looking for the right configure flag. It's kind-of coming back to me!
<civodul>jxself: 'deco stop dmd' stops dmd; before it would panic, now it reboots
<jxself>Ah, dmd reboots - not the machine rebooting, I see.
<civodul>(each service has a 'stop' action)
<civodul>no, the machine reboots
<civodul>it's PID 1, so when it quits, the kernel panics
<civodul>so instead i chose to make it reboot, which makes more sense than quitting when we're PID 1
<civodul>good night/day!
<civodul>Hello Guix!
<gzg>civodul: Hey! Almost finished with SLiM, but Guix doesn't seem to automatically copy slim's conf file where it needs to be (currently attempts /etc/slim.conf.). Also, started on Bluez.
<civodul>gzg: nice!
<civodul>gzg: perhaps /etc/slim.conf is hardcoded somewhere?
<jmd>I wonder if the guix build environment, should be revealed by config.guess ?
<jmd>This way, guix built packages would have a build triplet like i686-pc-guix
<gzg>civodul: What do we do if something is dual-licensed? Libical states "You may choose the terms of either: * The Mozilla Public License (MPL) v1.0 or * The GNU Library General Public License (LGPL) v2.1".
<gzg>civodul: Also, I'll look into where slim.conf's export is set, probably sometime later today.
<civodul>jmd: no, because it's just normal linux-gnu
<civodul>gzg: you could have a list of licenses
<gzg>civodul: Just literally something like (license `(lgpl2.1 mpl2.0))?
<civodul>gzg: (license (list lgpl2.1 mpl2.0))
<civodul>i think there are already occurrences of that somewhere
<civodul>also add a comment to say that it's dual-licensed, at the user's discretion
<gzg>civodul: Ah, Kay.
<gzg>civodul: Okay, it's nearly 04:00 here, heading to bed -- I'll likely pop in-here later today and try to finish off slim. Peace. o/
*gzg is AFK.
<civodul>good night!
<jmd>So far as I can tell, guix-daemon doesn't actually do what daemons should (the way that Stevens describes). Would a patch be accepted?
<civodul>of course! :-)
<civodul>what doesn't it do that it should do?
<jmd>It doesn't fork, detatch itself from the terminal, become its session leader, cd to / ...
<jmd>At least I don't think it does - I haven't looked in detail.
<civodul>no you're right
<civodul>i'm not sure if it's necessary
<jmd>It depends how people are going to use it.
<civodul>it's going to be started by the init system
<civodul>like in the demo image
<jmd>It might help me find out why mine keeps crashing.
<civodul>feel free to email bug-guix@ with all the details if you want
<civodul>backtrace, how to reproduce, etc.
<civodul>so 'make check' didn't pass i suppose?
<viric>jmd: enable core dumps
<jmd>I think it did. I can't be absolutely sure that I ran make check
<viric>core dumps are your friend.
<civodul>'make check' too :-)
<viric>Where I worked previously, I used core dumps often... and I was laughted at.
<viric>as if I used tech from the 70s
<viric>the new tech was to start all again in gdb, and tell the people to reproduce the problem.
<jmd>What did they use? Crstall balls.
<viric>if they couldn't reproduce it, it wasn't a problem.
<jmd>It might take hours to reproduce. Or eternity.
<viric>exactly. it means it is not a problem.
<civodul>good strategy from the developer's POV
<jmd>I know that kind of workplace.
<viric>well, some people like to develop features, and don't like fixing bugs.
<viric>I like most fixing bugs :) but I was quite alone in that.
<jmd>I once spent 3 months developing a whole new suite of test procedures in responce to concerns about quality. But they were soon abandoned because "too many products failed compared to when using the old procedures".
<viric>exactly. It's like the frustration caused by phredom's system
<viric> , out of tor
<viric>jmd: or the famous thousands of segfaults found in all debian programs
<jmd>Debian is not that bad!
<viric>that had to become thousands of bug reports
<jmd>I thought my daemon was crashing. I was wrong. It is exiting quite normally. Why should that be?
<mark_weaver>jmd: I think that shouldn't happen.
<mark_weaver>well, so much for the backtrace idea :-(
<mark_weaver>civodul: fyi, jmd reports that when he tries to build his pspp with guix, he sees "guix package: error: Connection reset by peer" and the daemon exits normally (without crashing).
<mark_weaver>s/pspp/pspp package/
<civodul>hmm, weird
<civodul>i hope we can get more details
*civodul struggles with gcc in core-updates
<civodul>maybe i'll commit what i have so far
<zacts>still having gcc problems?
<civodul>well i'm patching the spec strings
<civodul>problem is it takes several hours to check if i got it right
<civodul>probably i'm not being very smart either
<mark_weaver>at some point, it might be worth working on improving the debugging experience, somehow.
<mark_weaver>e.g., you could set up builds not in a chroot, but in the normal environment where everything is installed, and where you could modify a few files and then type "make" to rebuild more efficiently... get that working, and then do the pure builds again from scratch.
<mark_weaver>also, I wonder if it would be possible to set up ccache for use with guix, at least for "impure" builds during debugging.
<civodul>what i typically do in non-trivial cases is build with --keep-failed, and then hack from there
<civodul>does ccache have any benefit on an SSD?
<mark_weaver>I would expect so, because it eliminates the compilation step entirely if the same thing is compiled more than once.
<mark_weaver>I guess it works by looking up the preprocessed input in a hash table, or something along those lines.
<mark_weaver>If we could convince ourselves that it doesn't introduce impurities, I suspect it could improve the performance of guix builds quite significantly, although I guess it gets dicey when you're debugging the toolchain builds itself.
<mark_weaver>(obviously we need to preserve purity above all else, especially the importance of our security goals)
<mark_weaver>s/the/given the/
<civodul>yeah, dunno
<viric>what happens with gcc?
<civodul>pthread_cancel &, see? :-)
<civodul>the infamous thing
<civodul>with GCC 4.7 our "lib" spec adds gcc's libs to the RUNPATH
<civodul>i'm just trying to preserve that
<civodul>actually i was trying to make it smarter
<mark_weaver>maybe you should hold off on making it smarter until you get the basics working? dunno.
<civodul>yeah :-)
<civodul>i'll be more conservative
<zacts>civodul: how long have you hacked scheme?
<civodul>we're almost there, really :-)
<civodul>zacts: good question
<civodul>i'd say 8 years?
<zacts>wow, cool
<zacts>have you read SICP?
<civodul>yes, but only lately i think
<civodul>so i browsed it ;-)
<zacts>oh, cool. what would you recommend for a newbie?
<civodul>SICP of course :-)
<zacts>I want to eventually work on guile scheme projects, and learn comp sci at the same time.
<zacts>other than SICP..
<mark_weaver>SICP is what created my love for scheme in the first place, around a dozen years ago I think.
<zacts>I'm working on remembering all of my math from highschool for SICP
<civodul>i had a very "bottom-up" approach to Scheme
<civodul>i came to it from the GNU extensibility idea
<civodul>and then discovered the beauty of the thing
<civodul>and i keep discovering it ;-)
<mark_weaver>zacts: the little schemer, the seasoned schemer, and the reasoned schemer are good books.
<civodul>the Reasoned Schemer is great
<civodul>one of the few computer books i have
<civodul>but it's not about getting started with Scheme
<zacts>I remember how to do geometric proofs, but not mathematical induction
<zacts>I can remember only the basics of complex numbers
<zacts>I'm just getting started in school again, college.
<zacts>I took a college math class a few years ago, I have to review everything because I forgot it all.
<mark_weaver>well, you don't need to know much about complex numbers to read SICP, but it certainly is true that it assumes a reasonably strong math background, and yet the math isn't needed to learn programming.
<mark_weaver>(it's just that SICP was aimed at MIT engineering students)
<mark_weaver>so SICP probably isn't a good fit for you.
<mark_weaver>(oops, he left)
<zacts>I will be taking more math classes soon. actually, that will be my main study point for a while is mathematics
<mark_weaver>zacts: I wrote while you were away:
<mark_weaver>well, you don't need to know much about complex numbers to read SICP, but it certainly is true that it assumes a reasonably strong math background, and yet the math isn't needed to learn programming.
<mark_weaver>(it's just that SICP was aimed at MIT engineering students)
<mark_weaver>so SICP probably isn't a good fit for you.
<zacts>@ least not right now
<zacts>maybe in a year or so I'll be ready for it
<zacts>but that is a lot of time in between that I could be learning scheme stuff
<zacts>I own the little schemer books, and need to read them.
<zacts>but I was thinking of starting with HTdP
<zacts>and PLAI
<zacts>then apply it to real projects like guix / guilemacs / etc..
<mark_weaver>HTdP is probably a good way to learn programming, but the language it teaches (racket) has diverged quite a bit from standard scheme, for better or worse.
<zacts>oh interesting
<zacts>I don't know what to do then.. HTdP would probably be a good start, then I would eventually want to learn standard scheme.
<zacts>the current scheme standard isn't large is it?
<zacts>I could possibly take what I learn from HTdP and read the scheme reference and standard?
<mark_weaver>yes, it could be done.
<zacts>I think I'll start with that. I will then have the goal of reading SICP in about 1 - 1 1/2 years from now
<zacts>(after which I will have completed several college math courses)
<zacts>for now, I'll just add simple packages to guix
<zacts>and test guix builds
<zacts>also coursera offers an HTDP course, I'll do that this next semester.
<zacts>civodul: mark_weaver do you know other languages besides (scheme)?
<zacts>and what other projects have you worked on?
<mark_weaver>zacts: I'd love to talk about this, but right now is not a good time.
<zacts>ah ok, sorry
<mark_weaver>I have just a few minutes before I have to leave, and I'm hoping to have civodul's attention (on #guile) for a few more minutes if possible :)
<zacts>and maybe I should transfer this to #scheme