[05:56] <Keybuk> heh
[05:56] <Keybuk> so I explained the c-e-c problem to a friend, and it broke him
[05:56] <AlexExtreme> :)
[05:57] <Keybuk> though he was a sufficient teddy bear for me to figure out two interesting things
[05:57] <Keybuk> 1)
[05:57] <Keybuk> states are more interesting than just discreet
[05:57] <Keybuk> e.g. if you define a state for tty-added...tty-removed for a common NAME, then there are several questions you can answer
[05:57] <Keybuk> a) does tty1 exist?
[05:57] <Keybuk> b) does any tty exist?
[05:57] <Keybuk> c) what is the list of ttys that exist?
[05:58] <Keybuk> it turns out that all of these are interesting
[05:58] <Keybuk> getty is run for each tty that exists
[05:58] <Keybuk> but something requiring a network is running if any non-lo network interface is up
[06:00] <ion_> Perhaps upstart should grow a scheme interpreter after all. ;-)
[06:01] <Keybuk> and the fhs filesystem question can be answers with list-of-mounted-paths is a superset of list-of-required-paths
[06:02] <ion_> make states scheme procedures, with a nice API for common things. :-)
[06:02] <Keybuk> this really does make states first class again
[06:03] <Keybuk> so a job would end up having event predicates and state predicates
[06:03] <Keybuk> 2)
[06:03] <Keybuk> states don't need to behave like jobs
[06:03] <Keybuk> "pre-start"/"post-stop" scripts for states are all very well and pretty
[06:03] <Keybuk> but in reality, they're not needed
[06:03] <Keybuk> since you can just tie a job to the state, and define the scripts there
[06:04] <ion_> True...
[06:04] <ion_> But having them in the same file is nice.
[06:05] <ion_> OTOH, you could make them separate, implicitly creating an anonymous job for each state, to which the scripts are added.
[06:07] <Keybuk> I think it makes it more difficult if they're conceptually the same thing
[06:13] <ion_> Perhaps add an expr stanza for scheme expressions, which could be used by any job. State would be just a job with no process; there would be no distinction from the codes point of view.
[06:20] <Keybuk> the interesting thing about states is the operations on them
[06:20] <Keybuk> state-is-true state args...
[06:20] <Keybuk> any-state-is-true state
[06:21] <Keybuk> stats-that-are-true state is-subset-of other list
[06:21] <Keybuk> etc,
[10:30] <Keybuk> ho-hum
[10:31] <kylem> ?
[10:31] <Keybuk> brain hurts
[10:32] <kylem> stop poking at it
[10:32] <Keybuk> heh
[10:33] <Keybuk> trying to define an elegant language (and internal combustion) for when jobs should be running
[10:37] <ion_> How about this? /etc/event.d/tty on tty-added $TTY ... tty-removed $TTY; instance would define a job, which also functions as a state. Other jobs/states could query whether tty is running, but they could also query whether an instance (with a certain $TTY) is running.
[10:38] <ion_> In the tty-added $TTY ... tty-removed $TTY expression, the first $TTY (before ...) would be an assignment and the second $TTY (after ...) would be a comparison.
[10:38] <Keybuk> a job with
[10:38] <Keybuk> instance
[10:38] <Keybuk> start on tty-added
[10:39] <Keybuk> stop on tty-removed $TTY
[10:39] <Keybuk> would be equivalent
[10:39] <ion_> True. :-)
[10:40] <Keybuk> so you'd end up with two basic stanzas
[10:40] <Keybuk> start on/stop on, which define an event or combination of events that start or stop the job
[10:40] <Keybuk> start on tty-added or serial-port-added
[10:40] <Keybuk> etc.
[10:40] <ion_> Anyway, that would answer to a) does tty1 exist? b) does any tty exist? c) what is the list of ttys that exist?, wouldnt it?
[10:40] <Keybuk> you'd also need a second "when" stanza, that defined the other states that must be true
[10:41] <Keybuk> (or maybe while)
[10:41] <Keybuk> e.g.
[10:41] <Keybuk> instance
[10:41] <Keybuk> start on tty-added tty[1-6] 
[10:42] <Keybuk> stop on tty-removed $TTY
[10:42] <Keybuk> while user-can-login
[10:42] <Keybuk> where there's a seperate /etc/?/user-can-login
[10:43] <ion_> /etc/job /etc/state? /etc/job.d /etc/state.d?
[10:44] <Keybuk> the reason this doesn't feel right to me is that you can't have different pairs of start/stop
[10:44] <Keybuk> like the tty or serial-port combo
[10:44] <Keybuk> you can't match the stops to the starts
[10:54] <Keybuk> :-/
[10:56] <ion_> on tty-added tty[1-6]  until tty-removed \1 or serial-port-added * until serial-port-removed \1
[10:56] <ion_> Or $1
[10:59] <Keybuk> the problem there is how do you stop them doing:
[10:59] <Keybuk> foo until bar until baz
[11:02] <ion_> Change
[11:02] <ion_>     | cmplx_expr 'until' cmplx_expr
[11:02] <ion_> to
[11:02] <ion_>     | event 'until' event
[11:05] <Keybuk> but then you can't do (event or event) until event
[11:05] <Keybuk> which might be useful
[11:05] <Keybuk> and how do you define:
[11:05] <Keybuk>   any (tty-added until tty-removed $TTY)
[11:09] <ion_> expr_no_until : event | expr_no_until 'and' expr_no_until | expr_no_until 'or' expr_no_until | '(' expr_no_until ')' ; expr : expr_no_until | expr_no_until 'until' expr_no_until ;
[11:10] <ion_> Correction:
[11:10] <ion_> expr_no_until : event | expr_no_until 'and' expr_no_until | expr_no_until 'or' expr_no_until | '(' expr_no_until ')' ; expr : event | expr 'and' expr | expr 'or' expr | '(' expr ')' | expr_no_until 'until' expr_no_until ;
[11:12] <ion_> For any (tty-added * until tty-removed $1), create job (state) instance; on tty-added * until tty-removed $1 and check whether it is running.
[11:14] <Keybuk> whether any instance is running?
[11:14] <ion_> Yes.
[11:15] <Keybuk> that gets quite expensive if used a lot, no?
[11:17] <ion_> Disconnect state names from the filenames, and make it possible to assign a number of state expressions to variables in a single file?
[11:19] <ion_> state tty-exists = any (tty-added tty[1-6]  until tty-removed $1)
[11:20] <ion_> state foo = tty-exists and writable-filesystem