IRC channel logs

<civodul>dmd can reboot, power-off, and all that, woo!

<mark_weaver>nice!

<civodul>yeah, not really a distinguishing feature tho

<civodul>:-)

<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!

<civodul> http://www.gnu.org/software/dmd/manual/dmd.html#deco-and-dmd

<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!

<jmd>hi

<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

<civodul>dunno

<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>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> http://vdmvtkitqc3grub6.onion.to , 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

<viric>:)

<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 & libgcc_s.so, 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.

<zacts>brb

<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)

<civodul>:-)

<zacts>lo

<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>(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

IRC channel logs

2013-11-15.log