[02:17] <Keybuk> sadmac2: interesting.
[02:18] <Keybuk> btw, you pretty much read my mind on the sub-job thing
[02:18] <Keybuk> and action thing
[02:18] <Keybuk> even down to the whitespace separation ;)
[02:19] <Keybuk> I've wanted to see if it were possible to do all the pre-stop/post-stop scripts as sub-jobs for a while
[02:19] <Keybuk> so let me think on your mail for a day and see where I can poke holes ;)
[02:27] <Keybuk> this is kinda where I was going with pre-stop the other day
[02:28] <Keybuk> I thought that, exactly as you suggest, that
 exec <command>
 script
[02:28] <Keybuk> ...
[02:28] <Keybuk> end script
[02:28] <Keybuk> would define actions
[02:28] <Keybuk> and I'd also add <argument> signal <signalname or number>
[02:28] <Keybuk> where <argument> could probably be anything
[02:29] <Keybuk> thus "job <argument>" would be a state, just as job was
[02:29] <Keybuk> and "job <argument>" would be an event too
[02:29] <Keybuk> so "job pre-start" becomes a state and event (while job's pre-start action is running)
[02:29] <Keybuk> and "job post-stop" likewise
[02:29] <Keybuk> I figured that events would still block their states
[02:30] <Keybuk> I didn't get as far as figuring out how it'd know to run pre-start and post-stop at the right times though
[02:30] <Keybuk> my thought was you'd have <argument> on/while ...
[02:30] <Keybuk> so
[02:31] <Keybuk> reload signal HUP
[02:31] <Keybuk> reload daily
[02:31] <Keybuk> or something
[02:33] <Keybuk> the competing syntax, of course, being
[02:33] <Keybuk> define reload
[02:33] <Keybuk>   signal HUP
[02:33] <Keybuk>   daily
[02:33] <Keybuk> end define
[02:33] <Keybuk> or job or action or whatever
[11:46] <Ng> out of curiosity, is there an upstart form of the "reload" sysv concept?
[13:03] <Keybuk> Ng: not yet
[13:03] <Ng> ok :)
[14:17] <ion> Neat http://testape.com/webtty_page.php
[14:19] <sadmac2> ion: what the hell?
[14:59] <Keybuk> ion: your don't-fsck-twice patch introduced a bug ;)
[14:59] <Keybuk> now it doesn't retry to mount filesystems
[15:00] <ion> Agh
[15:02] <Keybuk> should probably call device_ready() in that if block
[18:16] <Keybuk> sadmac: did you see my replies last night btw?
[18:16] <sadmac2> Keybuk: on IRC? yes
[18:16] <Keybuk> cool
[18:17] <Keybuk> was just brain dumping in return
[18:17] <Keybuk> will reply to your mail proper later
[18:17] <sadmac2> cool
[18:18] <sadmac2> Keybuk: so I'm implementing a PEG in libnih after ion's recommendation. As parser styles go it feels the most right for libnih, and rolling our own makes sense since all the others are kind of vaporwareish.
[18:19] <Keybuk> I don't really understand that bit ;)
[18:19] <Keybuk> but I look forwards to seeing the results
[18:19] <sadmac2> ok then :)
[18:19] <Keybuk> if it can do clang-style "your problem is here ^~~~~~~" type things, that would be k-rad-awesome
[18:19] <sadmac2> I saw 2 or 3 of the things that were in C, but none of them were in source control.
[18:19] <sadmac2> yeah, there should be a way
[18:23] <sadmac2> I'm trying to implement it very minimalistically right now. I want enough of it in place that I can go back and finish what I was doing, and then I can polish it.
[18:24] <sadmac2> since this is all happening on an interrupt (attempt to alter parse_job.c caused SIGREWRITE)
[18:45] <ion> Why not base your work on the project we looked at yesterday?
[18:47] <sadmac2> ion: ...straight up stealing the code is something I hadn't considered...
[18:47] <sadmac2> open source is cool like that.
[18:53] <ion> A PEG parser should be able to point out the precise problematic byte by keeping track of the furthest position it ever reached in the input stream.
[18:53] <ion> (btw)
[18:54] <sadmac2> ion: exactly
[18:54] <sadmac2> ion: which it would more or less have to keep track of anyway for normal operation
[18:56] <sadmac2> ion: you can actually get primitive error handling right away just by doing error <- "start" WS "on" "WS" /.*/ { send_error ("unexpected crap after start on") } as the lowest priority rule in the set.
[18:57] <ion> True
[18:58] <sadmac2> and that also gives you the benefit of actually pushing an error token like in yacc, which means you can keep parsing and find more syntax errors.
[18:59] <ion> Yeah
[19:33] <PuffTheMagic> what is the difference between "initctl jobs' and "initctl events"
[19:45] <sadmac2> PuffTheMagic: one shows events, one shows changes in jobs
[20:45] <PuffTheMagic> well arent jobs events?
[20:45] <PuffTheMagic> what is the definition of a job
[20:45] <sadmac2> PuffTheMagic: jobs are not events
[20:46] <sadmac2> PuffTheMagic: a job is an object that exists in a state. an event is a point in time.
[21:00] <Keybuk> (this is the primary reason why the config files moved from /etc/event.d in later Upstart releases, it confused people)
[21:04] <PuffTheMagic> ok i get it