[00:24] <Keybuk> I'm going to make a change to the state machine before that
[00:24] <Keybuk> that won't take long to do, mostly just updating test cases
[00:34] <sadmac> cool
[01:37] <Keybuk> https://lists.ubuntu.com/archives/upstart-devel/2008-March/000589.html
[14:20] <Keybuk> http://upstart.ubuntu.com/wiki/ExpandEventVariables
[14:20] <Keybuk> http://upstart.ubuntu.com/wiki/NamedInstances
[14:20] <Keybuk> yay for writing specs after implementing them
[14:26] <ion_> keybuk: Hehe
[14:31] <Keybuk> I need to get a shuttle or some other super-lightweight computer
[14:31] <Keybuk> it's very silly having an entire server here just for local DNS
[14:34] <Keybuk> . o O { why don't I just install a lightweight DNS cache on the OpenWRT box }
[14:36] <ion_> I’ve been planning to replace a PC runninhg OpenBSD with a Via Epia, Soekris or something like that for years. But all my money seems to go to other stuff than computers. :-)
[14:54] <Keybuk> is funny, sometimes you write a spec and realise in doing so that it's pointless
[14:54] <Keybuk> e.g. http://upstart.ubuntu.com/wiki/MandatoryJobEnvironment
[14:58] <ion_> :-)
[18:05]  * Keybuk gets the creeping feeling he'll need libdbus-nih (or libnih-dbus)
[18:06] <ion_> Heh
[21:21] <Keybuk> I love autoconf
[21:21] <Keybuk> it's a great improvement on everything that's been written since
[21:22] <ion_> ...
[21:22] <ion_> :-D
[21:23] <Keybuk> I added a libnih-dbus.la to libnih
[21:24] <Keybuk> obviously, this can only be built if dbus development stuff is on the disk
[21:24] <Keybuk> so autoconf checks for that
[21:24] <Keybuk> if you have dbus, you get libnih-dbus
[21:24] <Keybuk> if you don't, you don't
[21:24] <Keybuk> obviously, you might want to suppress generating it; so you can configure --without-dbus or --with-dbus=no
[21:24] <Keybuk> then it won't get built anyway
[21:24] <Keybuk> or you might want to force generating it, just in case; so you can configure --with-dbus
[21:25] <Keybuk> if it doesn't exist, configure will exit with an error
[21:25] <Keybuk> that's just at the configure library
[21:25] <Keybuk> applications like upstart will want to force dbus support since they always need it
[21:25] <ion_> Alright
[21:25] <Keybuk> so upstart has NIH_INIT([dbus]) in its configure.ac
[21:25] <Keybuk> that acts as if --with-dbus was always specified, failing if it doesn't exist
[21:26] <Keybuk> except it doesn't check the configure arguments (--without-dbus does nothing) and even doesn't show up the existance of that in the --help output
[21:26] <Keybuk> I *love* autoconf
[21:28] <ion_> Have you pushed that anywhere?
[21:28] <Keybuk> not yet
[21:28] <Keybuk> why?
[21:29] <ion_> No reason, just looked at nih intending to look at the changes out of curiosity.
[21:29] <Keybuk> haven't actually written the dbus stuff yet :)
[21:29] <ion_> Ah, right. :-)
[21:29] <Keybuk> I made dinner instead
[21:30] <Keybuk> then mucked around with autoconf ;)
[22:04] <Keybuk> gotta love the way half your desktop vanishes if you restart dbus
[22:04] <ion_> Hehe, yeah. :-P
[22:05] <ion_> irssi manages to restart itself preserving IRC connections, without forking even.
[22:05] <ion_> Handy for upgrades.
[22:13] <Keybuk> funny, I've hit the first dbus stumble already
[22:13] <Keybuk> and I've only just got as far as the damned bus connection
[22:13] <Keybuk> sometimes I think that fd.o/gnome/etc. people are utter morons
[22:13] <ion_> What’s the problem?
[22:14] <ion_> With dbus, that is. :-)
[22:14] <Keybuk> dbus calls exit() if the socket is closed :p
[22:14] <ion_> Ouch. :-)
[22:17] <Keybuk> happily it sets that *right in the middle* of the dbus_bus_get function
[22:18] <ion_> :-P
[22:50] <Keybuk> hmm
[22:50] <Keybuk> 090606 24012KT 9999 SCT025 PROB30 TEMPO 1117 26015G25KT 6000 SHRA SHGS SCT020CB
[22:50] <Keybuk> somebody likes me
[22:51] <Keybuk> weather starts to turn nasty just 30 minutes after my flying lesson is due to end
[23:03] <Amaranth> having upstart exit when dbus goes away is bad, no? :)
[23:04] <Keybuk> indeed
[23:04] <Keybuk> it's similar to that moronic abort() if malloc() returns NULL in glib
[23:05] <Amaranth> g_try_malloc
[23:05] <Keybuk> "oh, bother, I can't be arsed to deal with errors - let's just go away"
[23:05] <Keybuk> Amaranth: and how do you tell all the various glib internals that malloc to use that instead of g_malloc()?
[23:05] <Amaranth> I understand the thought process that led to that in glib
[23:05] <Keybuk> there were thought processes?
[23:05] <Amaranth> If you're out of memory something _really_ bad has happened
[23:05] <Keybuk> not true at all
[23:06] <Keybuk> it's utterly the wrong way to view it
[23:06] <Amaranth> well, glib is meant for use with desktop things
[23:06] <Keybuk> if you're out of memory, you can't do what you were trying to do
[23:06] <Keybuk> desktop things shouldn't vanish
[23:06] <Keybuk> not without explanation
[23:06] <Keybuk> not without a change to save their state
[23:06] <Keybuk> etc.
[23:06] <Amaranth> they will anyway, oom killer
[23:06] <Keybuk> right now, if you open a large file in inkscape, half the desktop apps vanish
[23:06] <Keybuk> oom killer is smart enough to normally kill the application using the most memory :p
[23:07] <Amaranth> got me there
[23:07] <Keybuk> in fact, not only half the desktop apps
[23:07] <Keybuk> but half of the underlying daemon stoo
[23:07] <Amaranth> although iirc handling malloc failure adds like 30-50% more code to your project
[23:07] <Amaranth> so i guess people are lazy :)
[23:07] <Keybuk> out of memory turns from a "damn, come back in a moment" problem to a fatal problem
[23:07] <Keybuk> I disagree
[23:07] <Keybuk> upstart handles every single malloc error
[23:07] <Keybuk> and its code isn't huge as a result
[23:07] <Keybuk> you either retry because it's important
[23:08] <Keybuk> or you return a natural error progression that will abort the current operation
[23:08] <Amaranth> how many times do you retry?
[23:08] <Keybuk> you need that latter anyway since other things might go wrong
[23:08] <Keybuk> always
[23:08] <Keybuk> there are two solutions to out of memory:
[23:08] <Keybuk> 1) block until there is memory
[23:08] <Keybuk> 2) fail the current operation
[23:08] <Keybuk> if you try and start a job in upstart, and it runs out of memory, it will return you an "Out of memory" error
[23:08] <Keybuk> and the job will not be started
[23:09] <Keybuk> and the state will remain clean
[23:09] <Amaranth> that reminds me, whatever happened to the kernel sending a signal when memory is running low
[23:09] <Keybuk> never heard of that one
[23:10] <Amaranth> was thinking someone could setup a policy to stop certain services and throw out caches when that happens
[23:10] <Amaranth> really?
[23:10] <Amaranth> http://kerneltrap.org/Linux/Signaling_When_Out_of_Memory
[23:11] <Amaranth> i only remember that because of SIGSEEDAMNITITOLDYOUSO
[23:11] <Keybuk> heh
[23:12] <Keybuk> never got implemented
[23:12] <Amaranth> shame
[23:13] <Amaranth> so is the malloc thing the reason why you have libnih?
[23:13] <Keybuk> no
[23:13] <ion_> Additionally, libnih doesn’t have the general suckage glib has. :-)
[23:13] <Keybuk> it's just the first of many, Many, MANY things I hate about glib
[23:19] <Keybuk> ... gint
[23:19] <Keybuk> the main loop has a well known race-condition which upstream refuse to fix
[23:20] <Keybuk> the entire API is massively bulky and bloated
[23:20] <Keybuk> g_very_long_function_names_since_nobody_cares_about_fitting_into_eighty_columns_these_days
[23:20] <Amaranth> hehe
[23:21] <Amaranth> i dunno, i use it from vala :)
[23:21] <Keybuk> io channel support that assumes you always deal in streams
[23:21] <Keybuk> inconsistent error reporting/handling
[23:22] <Amaranth> but gobject
[23:22] <Keybuk> random reimplementations of functions that are in libc (!!)
[23:22] <Keybuk> gobject is pain
[23:22] <Keybuk> gthread is so useless it's beyond a joke
[23:22] <Amaranth> pain to write but gobject-introspection lets you do cool things
[23:22] <Keybuk> gmobile is a bad wrapper around libltdl
[23:22] <Keybuk> mobile?  
[23:22] <Keybuk> gmodule!
[23:23] <Keybuk> you don't *need* to do those cool things in C
[23:23] <Keybuk> if you want that kind of thing, you should use C# or Python or some other high level language
[23:23] <Amaranth> no, those cool things are "autogenerated bindings for every language"
[23:23] <Keybuk> and how bad are those bindings normally? :)
[23:23] <Keybuk> ever tried using, say, python-gtk ?
[23:24] <Keybuk> Python's own help() function can crash Python!
[23:24] <Amaranth> those aren't autogenerated :P
[23:24] <Amaranth> all of the gnomey bindings in vala are autogenerated, seems to come out alright
[23:24] <Amaranth> well, except glib, have to do that one by hand
[23:26] <Keybuk> heh
[23:26] <Keybuk> tbh, the main reason for libnih is just ... nih
[23:27] <Keybuk> it's mostly cribbed from my "copy and paste" library of code, I just libraryfied it
[23:27] <Keybuk> I like the nih_alloc pattern
[23:27] <Keybuk> so it follows that I like a standard library of functions that follow the same general pattern