[04:15] <Keybuk> *yawn*
[08:04] <AlexExtreme> oh?
[08:06] <Keybuk> so the problem I've been having is trying to understand how to define when a job is running
[08:06] <Keybuk> and also define for instance jobs when instances are spawned and destroyed
[08:07] <Keybuk> which involves quite complex combinations of events
[08:08] <Keybuk> and I've been increasingly wondering whether events are the right things to track, and whether we should instead deal with states
[08:08] <Keybuk> e.g. rather than "initctl emit tty-added tty1", you'd "initctl set tty-exists tty1 true" or something
[08:08] <Keybuk> (since then jobs would become just lists of and/or around states)
[08:09] <Keybuk> but after some thought, I've decided against that
[08:10] <Keybuk> because we are really receiving events, and trying to fob off turning them into states to the emitter is a bit crap
[08:10] <AlexExtreme> right
[08:11] <Keybuk> so having decided that upstart should still receive events
[08:11] <Keybuk> that means upstart has to deal with turning events into states
[08:12] <Keybuk> and so far I've been trying to define these states through Job
[08:12] <Keybuk> this, I think, is wrong
[08:13] <Keybuk> instead I think we should make State a first class
[08:13] <Keybuk> and have a way to describe a State, with reference to one or more Events
[08:14] <Keybuk> which means Job would just make reference to a State in which it was running
[08:15] <Keybuk> then instance jobs could optionally just have two State *, one for when instances exist, and the other for when those instances are running
[08:15] <Keybuk> e.g. the getty job
[08:16] <Keybuk> instances exist for each state tty-added ... tty-removed for a unique $TTY
[08:16] <Keybuk> and those instances are *running* for the "user can login" state (defined elsewhere)
[08:17] <Keybuk> this makes Job rather simpler
[08:20] <AlexExtreme> sounds good
[08:20] <Keybuk> in fact, I'm considering splitting Job up a bit more, so that the dealing with instances and replacement jobs is at a higher level clas
[08:20] <Keybuk> at the very least, we'd have Job -> State -> Event
[08:21] <Keybuk> and we have a good grip above on how to define State
[08:21] <ion_> Sounds good indeed.
[08:21] <Keybuk> it's a combination of periods of events
[08:22] <Keybuk> each item has an Event to be matched, and a pointer to the the EventEmission that matched it
[08:23] <Keybuk> events on the right-side of the period should be able to reference the emission in the left-side
[08:23] <Keybuk> e.g.  tty-added tty[1-6]  -> tty-removed $TTY
[08:24] <Keybuk> this therefore implies that the state has a value at any given time
[08:26] <Keybuk> which is the environment of any left side not cancelled out by a right side
[08:28] <Keybuk> so we can pass that on to the job
[08:36] <Keybuk> once the rhs is filled, we can discard the emission on the left since that needs to happen again
[08:37] <Keybuk> so we actually just need three pointers, start_event, stop_event and emission
[08:37] <Keybuk> and not bother retaining the emission for the stop event, since that just cancels the start one
[08:38] <Keybuk> we then just need boolean things
[08:38] <Keybuk> AND, OR, NOT for those structures
[08:38] <Keybuk> and AND and OR for the start/stop event trees
[08:39] <ion_> Fever ftw.
[08:44] <Keybuk> the thing causing me difficulty is
[08:44] <Keybuk> - telling a job which events happened in the tree
[08:44] <Keybuk> - positional arguments
[08:47] <Keybuk> any thoughts?
[08:48] <AlexExtreme> nope, sorry. my brain isn't working too good today
[08:48] <AlexExtreme> i'll have a think about it though
[08:49] <Keybuk> the only thing I could come up with was
[08:49] <Keybuk> - walk the tree in-order
[08:50] <Keybuk> - for each open state, push the event name into the list, and its positional arguments
[08:50] <Keybuk> - then pop the first event name, place in UPSTART_EVENT
[08:50] <Keybuk> so UPSTART_EVENT is the first event at the top of the tree
[08:50] <Keybuk> $1..$n are the arguments to that event
[08:50] <Keybuk> followed by "--" followed by the name of the next event, and that ones positional arguments
[08:52] <Keybuk> quite programming intensive
[08:52] <Keybuk> but I suspect it won't be a problem, since the only things caring will probably be tasks or state-based instances
[08:52] <Keybuk> and those will have only one or two events in their list
[08:54] <Keybuk> so for most people, $UPSTART_EVENT and $1...$n will be sufficient
[08:54] <Keybuk> e.g.
[08:54] <Keybuk> block-device-added ... block-device-removed $1 or partition-added ... partition-removed $1
[09:02] <Keybuk> sounds ok?
[09:03] <AlexExtreme> yes
[09:18] <Keybuk> we'd probably end up needing separate files to define states in
[09:18] <Keybuk> maybe just /etc/upstart.conf or something
[09:18] <Keybuk> and obviously name them
[09:20] <Keybuk> and since jobs are now tied to states, not events, we'll have to rename /etc/event.d :p
[09:22] <AlexExtreme> rename it? shit. :p oh well, i suppose i can rebuild my entire upstart repo... ;)
[09:22] <Keybuk> lol
[09:22] <Keybuk> it's always been a temporary name
[09:23] <AlexExtreme> how about 'upstart.d' ? :)
[09:23] <AlexExtreme> jobs.d?
[09:23] <Keybuk> I'd been trying to avoid using "upstart"'s name in its config files
[09:23] <Keybuk> it may be inevitable though
[09:23] <Keybuk> I wanted /etc/init.d ... but someone already used that
[09:23] <AlexExtreme> i would say init.d
[09:23] <AlexExtreme> heh
[09:24] <AlexExtreme> but it's used already ;)
[09:25] <Keybuk> likewise /etc/rc.d
[09:25] <Keybuk> (but then rc.d is kinda old)
[09:25] <AlexExtreme> frugalware still uses rc.d for it's sysv stuff (but we were originally based on slackware, so... ;))
[09:29] <AlexExtreme> hmm :) there's a response from Mike Saunders (an LXF writer) on that post you made @ your blog
[09:29] <Keybuk> yeah I saw
[09:30] <Keybuk> I disagree with him
[09:30] <Keybuk> I think that the point of printed magazines is to have a single line of opinion
[09:30] <Keybuk> an editorial direction
[09:30] <AlexExtreme> me too
[09:30] <Keybuk> otherwise what do they give us that the online press doesn't?
[09:30] <AlexExtreme> right
[09:30] <AlexExtreme> there's one thing that's been annoying me with LXF recently
[09:31] <Keybuk> what's that?
[09:31] <AlexExtreme> they've been reviewing beta releases as the final product, and only mentioning in small print that it's the beta
[09:39] <Keybuk> their time-to-print seems extraordinarily long
[09:39] <Keybuk> I've noticed that before with them
[09:39] <Keybuk> their NEWS is amazingly out of date
[09:40] <AlexExtreme> yeah
[09:42] <Keybuk> could have /etc/service.d /etc/task.d and /etc/state.d
[09:42] <Keybuk> bit overkill though
[09:42] <AlexExtreme> yeah
[09:43] <Keybuk> why is it always ".d" anyway?
[09:43] <AlexExtreme> i prefer a central location rather than files dotted in a few directories over the place
[09:43] <AlexExtreme> dunno, i've always wondered that
[09:44] <Keybuk> difficult to google for ;)
[09:46] <Keybuk> it seems to have stemmed from when a file was turned into a directory
[09:46] <Keybuk> /etc/rc -> /etc/rc.d
[09:46] <AlexExtreme> probably the .d stands for directory
[09:47] <Keybuk> and it vaguely implies that if you concatenated all the files together, it's equivalent to just having a single file
[09:47] <Keybuk> which means that the /etc/event.d use would be "invalid"
[09:47] <Keybuk> since the name matters
[09:47] <Keybuk> but then the same is true for /etc/pam.d
[09:48] <AlexExtreme> and dbus' system.d
[09:48] <Keybuk> we do need to separate out jobs and states though
[09:49] <Keybuk> maybe
[09:50] <AlexExtreme> btw, will the replacement-initscripts spec *definitely* get implemented for gutsy?
[09:51] <Keybuk> no
[09:51] <Keybuk> it's strongly possible though
[09:51] <Keybuk> the only thing standing in the way is this complex event config problem
[09:52] <AlexExtreme> well, if you need any help with that just ask, i'll try to help with decisions if i can
[09:54] <Keybuk> see above ;)
[09:54] <AlexExtreme> :)