[12:37] <Seveas> Keybuk, some stupid suggestions: if it's sent while masked, isn't it just ignored? Do you actually give it a chance to be delivered (eg not looping inside a sighandler)?
[12:38] <Keybuk> the point of masks is to block their delivery, not cause them to be ignored :)
[12:39] <Keybuk> I figured what it was; before setting the handler, I set it to SIG_DFL first just to make things sane
[12:39] <Keybuk> setting a signal to SIG_DFL means it gets handled in the kernel, so the process signal mask doesn't apply
[12:39] <Keybuk> solution: don't reset the signals when being restarted, and voila
[12:39] <Keybuk> signals are "reliable" in that they can be raised, and you will get them if you're listening
[12:40] <Keybuk> however you may just get one, not several, depending on the OS
[12:52] <theCore> I always start to think Unix system programming is hard when I see all the fancy abbrv.
[12:54] <theCore> 96 revision(s) pulled.
[12:55] <theCore> whoa, Keybuk, you seem to work hard
[12:55] <Keybuk> heh
[12:55] <Keybuk> there are scarier stats
[12:56] <theCore> bzr diff -r-96.. | diffstat
[12:56] <theCore> it seems most of your work is centred on test suites
[12:56] <Keybuk> -r 223 was 0.2.7 (edgy version), 179 in libnih
[12:57] <Keybuk> $ bzr diff -r ..223 | diffstat
[12:57] <Keybuk>  62 files changed, 19751 insertions(+)
[12:57] <Keybuk> $  bzr diff -r ..179 | diffstat
[12:57] <Keybuk>  63 files changed, 17881 insertions(+)
[12:57] <Keybuk> -- 
[12:57] <Keybuk> vs.
[12:58] <Keybuk> $ bzr diff -r 223.. | diffstat
[12:58] <Keybuk>  80 files changed, 21029 insertions(+), 10311 deletions(-)
[12:58] <Keybuk> $  bzr diff -r 179.. | diffstat
[12:58] <Keybuk>  66 files changed, 20752 insertions(+), 8230 deletions(-)
[12:59] <Keybuk> a lot of it is test suite, yeah
[12:59] <Keybuk> and all the bugs I've found in the process
[12:59] <Keybuk> getting the code base sane so I can merge in the new stuff
[01:00] <theCore> just a question, does test driven programming worth the effort. It seems to be the norm at Canonical 
[01:00] <theCore> effort. -> effort?
[01:00] <Keybuk> I'm not sure about test-*driven* programming, where you write the tests first, then the code second
[01:01] <Keybuk> I've found it *very* useful for complex algorithms
[01:01] <Keybuk> but find it gets in the way of straight forward bone-playing
[01:01] <Keybuk> I'm certainly a great fan of *tested* programming
[01:03] <theCore> I was thinking writing a test-suite for my small project, a easy-to-use iptables front-end. 
[01:03] <theCore> but, I don't think it will be necessary
[01:04] <theCore> the whole is < 1000 lines, without any fancy algorithm
[01:10] <Keybuk> you should still try and have it tested though
[01:10] <Keybuk> I've found all manner of silly bugs in the simplest of functions by testing it
[01:11] <Keybuk> e.g. "initctl shutdown" tried to send message 1 to the pid of the UPSTART_SHUTDOWN enum entry
[01:13] <theCore> hmm, right. In fact, it could be a good learning experience
[01:14] <theCore> after all, I will probably end-up as a software engineer, so I will to learn how to test my code sooner-or-later
[01:15] <theCore> will need*
[01:17] <theCore> hehe, you're a Lord of the Ring fan?
[01:17] <Keybuk> heh, all the frodo/bilbo references?
[01:17] <theCore> yeah
[01:17] <Keybuk> they're just common english metasyntactic variables
[01:18] <Keybuk> foo/bar/baz/frodo/bilbo/drogo/wibble/wobble/etc.
[01:18] <Keybuk> but yes, also I do like LotR
[01:21] <theCore> also, you got some pretty neat macro in nih/test.h
[01:22] <Keybuk> originally I didn't have any, and the upstart tests were all just written by hand, even down to  printf ("Testing some_function()\n");
[01:22] <Keybuk> I grew them into those macros simply to make it easier
[01:23] <Keybuk> TEST_ALLOC_FAIL is my new favourite; it loops over the enclosed code, counts how many times malloc is called, and then runs the code again causing each one to fail in turn -- so you can test the side-effects of -ENOMEM :p
[01:24] <theCore> yes, I was looking at this one
[01:24] <theCore> TEST_CHILD is neat too
[01:27] <Keybuk> that reminds me, I have a fix for TEST_CHILD to turn it into one statement :p
[01:27] <theCore> hehe
[01:30] <theCore> I always been a bit scared by C's macros, since I saw #define MAX(A, B) (A > B ? A : B) 
[01:31] <Keybuk> that's a tricky one, because it evaluates both A and B twice
[01:31] <theCore> yep
[01:31] <Keybuk> so MAX(a++, b++) will expand to (a++ > b++ ? a++ : b++)
[01:32] <theCore> exactly
[01:32] <theCore> the pleasure of side-effects
[01:32] <Keybuk> so if a was 3 and b was 4, then you'd get 5 as the value, and a would be 4 and b 6
[01:32] <Keybuk> there's a gccish way of writing that
[01:33] <Keybuk> but it only works if you know the types
[01:33] <Keybuk> e.g.
[01:33] <theCore> #define MIN(A,B) ((A) < (B) ? : (A) : (B))
[01:33] <Keybuk> #define maxsize_t(a,b) ({size_t _a = (a), _b = (b); _a > _b ? _a : _b; })
[01:33] <theCore> oh, #define MIN(A,B) (A <? B)
[01:33] <Keybuk> I've never heard of "<?"
[01:34] <theCore> I just learned it
[01:34] <theCore> http://developer.apple.com/documentation/DeveloperTools/gcc-3.3/gcc/Min-and-Max.html
[01:35] <Keybuk> those are C++ extensions only, no?
[01:35] <theCore> I don't know
[01:35] <Keybuk> the only note I can find in the gcc 4.1 manual is
[01:35] <Keybuk>  The G++ minimum and maximum operators (`<?' and `>?') and their
[01:35] <Keybuk> compound forms (`<?=') and `>?=') have been deprecated and will be
[01:35] <Keybuk> removed in a future version.  Code using these operators should be
[01:35] <Keybuk> modified to use `std::min' and `std::max' instead.
[01:36] <theCore> that makes sense
[01:36] <theCore> C++ STL is way more powerful than C's preprocessor
[01:37] <Keybuk> I don't really like C++
[01:37] <Keybuk> if they wanted to make a new language, they should have unbolted it from C
[01:37] <Keybuk> instead they ended up with a hideous half-breed
[01:37] <Keybuk> both Java and C# are far more elegant
[01:37] <theCore> well, it depends of your point of view
[01:38] <Keybuk> the principal thing about C++ that I hate is that it still has header files
[01:38] <theCore> but, I agree that Java and C# are more elegant
[01:38] <Keybuk> which artificially separates your class structure and code
[01:38] <Keybuk> AND by inference, exposes your private information to anyone reading them
[01:39] <Keybuk> they should have dropped the pre-processor, and made cpp files self contained units that could be referenced
[01:41] <theCore> I agree, but I don't think we will ever see a such change in C++
[01:41] <Keybuk> indeed
[01:41] <Keybuk> which is a shame
[01:41] <Keybuk> the obvious bogosity is "#define private public"
[01:47] <theCore> haha
[01:54] <theCore> oh?
[01:54] <theCore> gcc has improved
[01:55] <theCore> the MAX macro works 
[03:27] <_paulfm> hi everyone
[03:33] <_paulfm> Is anyone home? :-)
[03:35] <_paulfm> I am looking for some upstart help... I have just built it on Debian etch (testing)
[03:35] <_paulfm> I am hesitant to do a make install.... Im worried I may hose the init system
[03:35] <_paulfm> If I reconfigure and build.. with the /opt/upstart prefix
[03:36] <_paulfm> how do I start upstart at boot... so my upstart tests get run... but I leave the "regular" init in place
[03:49] <_paulfm> hmmm... nobody home
[04:21] <dns_server> is anyone around that can help me write a script?
[10:57] <popey> moo
[10:57] <popey> hmm - wrong channel :)
[10:58] <AlexExtreme> lol
[11:03] <Keybuk> cows are welcome here
[12:19] <Seveas> cows make good meat
[12:24] <Keybuk> they do indeed
[07:53] <_paulfm> hellooo...doe anyone here use upstart on debian