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