[12:26] <Keybuk> http://codebrowse.launchpad.net/~keybuk/upstart/main/revision/scott%40netsplit.com-20070620222502-rqg8aiw9kzt3h8t7?start_revid=scott%40netsplit.com-20070620222502-rqg8aiw9kzt3h8t7
[12:26] <Keybuk> ^ event expression trees have landed
[04:26] <Keybuk> heh
[04:26] <Keybuk> I had planned, this morning, to get rid of job->cause entirely
[04:26] <Keybuk> and so far I've been distracted by shiny new compiz-fusion features
[04:46] <ion_> I upgraded from beryl to compiz+compcomm recently.
[04:47] <ion_> Theres an interesting bug, which i havent got around to investigating yet.
[04:47] <thom> Keybuk: honestly, i'm shocked. :P
[04:48] <ion_> When i switch from a desktop to another using any largedesktop plugin, it seems to work fine, unless im switching from/to a desktop with Firefox as the active window. When that is the case, the movement is really jerky.
[05:04] <AlexExtreme> that's why i don't use compiz/beryl/whatever :)
[05:04] <AlexExtreme> when you're trying to do something, it's just too easy to get distracted with bouncing windows
[05:22] <AlexExtreme> sorry for the disconnects, my IRC bouncer is acting up
[05:25] <Keybuk> heh, silly things
[05:27] <AlexExtreme> there, that was the last one
[05:27] <Keybuk> which bouncer do you use?
[05:28] <AlexExtreme> bip
[05:28] <AlexExtreme> http://bip.berlios.de
[05:28] <ion_> alex: Whether the windows bounce depends on your configuration. :-)
[05:28] <AlexExtreme> ion_: of course ;)
[05:29] <ion_> The nicest thing is that when switching to another desktop, the windows dont need to be repainted. That makes it a lot faster on this 500 MHz machine.
[05:30] <ion_> *Even* when using a transition effect.
[05:30] <AlexExtreme> yep
[05:30] <AlexExtreme> I first tried compiz on a 700Mhz box when it was first released, it was quite fast
[05:32] <Keybuk> CPU speed shouldn't affect compiz
[05:33] <Keybuk> that's kinda the point <g>
[05:33] <Keybuk> fancy effects aside, the entire point is to offload all the boring screen management to the GPU
[05:33] <Keybuk> so more CPU resource is free
[05:34] <ion_> Indeed.
[05:35] <ion_> I meant that even showing the transition effect takes less time than having one of the bit more bloated programs repaint its window on this box.
[05:37] <Keybuk> true
[05:38] <Keybuk> in fact, in theory, the transition is free
[05:38] <ion_> Yeah.
[05:38] <Keybuk> because it's done using spare GPU capacity, rather than taxing the CPU
[05:39] <Keybuk> I do use some funny metasyntactic names
[05:39] <Keybuk> clearly for this test, I really wanted a name I wasn't likely to accidentally use later
[05:39] <Keybuk> so instead of foo, bar, baz
[05:39] <Keybuk> or frodo or bilbo
[05:39] <Keybuk> or wibble, wobble, waggle, wiggle, etc.
[05:39] <Keybuk> I used ...
[05:39] <Keybuk> biscuit
[05:39] <ion_> Hehe
[07:18] <Keybuk> there's one thing about specs that always bites
[07:18] <Keybuk> you always forget something, and have to retcon it when you write the code
[07:18] <Keybuk> e.g. the spec for replacing cause with event expressions
[07:18] <Keybuk> I had completely forgotten that a job is allowed to abort the stop in pre-stop
[07:20] <ion_> Looking up retcon from dictionary.com just spoiled a TV show. :-)
[07:20] <ion_> Not that id want to watch the show in question.
[07:21] <AlexExtreme> :)
[07:22] <Keybuk> retcon. v. to pretend the spec always said that ;)
[07:22] <ion_> :-)
[07:22] <AlexExtreme> :)
[07:29] <Keybuk> there's another state transition I forgot
[07:38] <AlexExtreme> why is it that every time i need to go somewhere it starts raining?
[07:38] <Keybuk> the weather here has marginally improved over the last few days
[07:39] <AlexExtreme> yeah, *marginally*, i.e. not raining constantly, just showers every 20 minutes ;)
[07:39] <Keybuk> EGBB 211720Z 16010KT 9999 -SHRA FEW020CB SCT030 16/13 Q1007
[07:41] <Keybuk> tomorrow's TAF is pretty mad
[07:41] <Keybuk> EGBB 211624Z 220024 17010KT 9999 SCT025 BECMG 0205 11005KT PROB40 TEMPO 0210 7000 -RA BKN008 PROB30 TEMPO 1022 7000 SHRA BKN020CB PROB30 TEMPO 1120 3000 +TSRA BKN014CB BECMG 2124 4000 BR
[07:41] <AlexExtreme> what's that from?
[07:41] <Keybuk> metoffice aviation forecast
[07:41] <Keybuk> EGBB = Birmingham International Airport
[07:41] <AlexExtreme> ah
[07:42] <AlexExtreme> you're near birmingham?
[07:42] <Keybuk> 40% probability of light rain in the morning,
[07:42] <Keybuk> 30% probability of showers in the afternoon
[07:42] <Keybuk> and 30% probability of heavy thunderstorms in afternoon
[07:42] <Keybuk> in Birmingham yeah
[07:43] <AlexExtreme> cool, not too far from here
[07:43] <Keybuk> that somewhat explains why we've been experiencing equally dire weather ;)
[07:43] <AlexExtreme> :)
[07:45] <Keybuk> http://codebrowse.launchpad.net/~keybuk/upstart/main/revision/scott%40netsplit.com-20070621173820-45cqbuufjbcft1sn?start_revid=scott%40netsplit.com-20070621173820-45cqbuufjbcft1sn
[07:45] <Keybuk> ^ \o/
[07:47] <Keybuk> actually, the current METAR isn't bad at all; perfectly flyable in fact
[07:48] <AlexExtreme> :)
[07:50] <Keybuk>  * If a job fails to reach its goal, all appropriate blocked events are marked as failed. Nodes with a FALSE value, and children of those nodes, are not considered since they have not caused the job to fail.
[07:50] <Keybuk> Urgh
[07:50] <Keybuk> I haven't worked out how to implement *that* yet
[07:50] <Keybuk> deciding which events in the expression tree to mark as failed
[07:50] <Keybuk> it's supposed to be "those that contributed to it starting in the first place"
[07:52] <AlexExtreme> Keybuk: would you mind greatly if I copied the nih linked list code to my project? i'd rather not link against libnih since i'm trying to keep the dependencies on this lib i'm writing to only libc
[07:52] <AlexExtreme> of course i'd add credits in the header (it's GPL, btw)
[07:52] <Keybuk> not at all
[07:52] <AlexExtreme> thanks
[07:52] <Keybuk> though you'd need nih_alloc as well, unless you modify it
[07:53] <AlexExtreme> k
[07:53] <Keybuk> (modify is easy enough, it's just nih_list_new, nih_list_entry_new, nih_list_destructor and nih_list_free)
[07:54] <AlexExtreme> yep
[09:27] <Keybuk> why do I only ever discover problems half way through an implementation?
[09:40] <Keybuk> today's problem:
[09:40] <Keybuk>   instance
[09:40] <Keybuk>   from tty-added
[09:40] <Keybuk>   until tty-removed $TTY
[09:40] <Keybuk>   respawn
[09:40] <Keybuk>   exec /sbin/getty $TTY 38400
[09:40] <Keybuk> nice and simple
[09:40] <Keybuk> what happens if
[09:40] <Keybuk>  a) the same tty gets added
[09:40] <Keybuk>  b) the tty gets removed, and another tty is added while the job is stopping
[10:22] <wasabi> I vote for proper lock/abort files. :0
[10:22] <wasabi> The instance gets spawned twice, but some nice chap tests to see if the instance is already spawned.
[10:24] <Keybuk> wouldn't it be nice if upstart took care of this for you? :p
[10:24] <wasabi> I don't really think so.
[10:25] <Keybuk> why not?
[10:25] <wasabi> got me.
[10:26] <wasabi> instance could be "unique per parameters"
[10:28] <Keybuk> yeah, which is interesting
[10:28] <Keybuk> but then do you restart the instance, or do you wait to create a new instance? :P
[10:29] <wasabi> Well, what happens if a start evnet happens twice in any non-instanced job
[10:29] <wasabi> Basically nothing.
[10:35] <Keybuk> indeed
[10:35] <Keybuk> need to think on this a bit
[10:48] <Keybuk> EGBB 212020Z 15006KT CAVOK 14/11 Q1008
[10:48] <Keybuk> CAVOK!
[10:48] <Keybuk> *cries*