[09:51] <Keybuk> KDesk: hi
[09:53] <keesj> Morning
[09:55] <keesj> today is d-day for me and my upstart state machine...
[09:57] <keesj> my goals is to get events queued so I can emit multiple events to a task scripts and be able to handle then all
[09:58] <keesj> something like http://www.paste-it.net/public/tf5a413/ 
[09:59] <keesj> but I guess "start" should be renamed to "queued start"
[10:02]  * Keybuk still doesn't know what you're doing
[10:07] <keesj> I have one upstart "job" that acts like a state machine its' called change_handler and listens to many external event (emit usb_detected stuff like that) , that state machine is used to support swiching between different "runlevels" (boot|mass_storage|main_app)
[10:07] <Keybuk> the built-in one doesn't work for you?
[10:07] <keesj> next to that I have emtpy state_boot state_mass_storage,,, jobs and services that depend on those state jobs
[10:08] <keesj> and all the change_handler does is determin the currently running state and the event and stop one state and start a different state
[10:09] <keesj> built-in state machine?
[10:13] <Keybuk> well, pretty much the point of upstart is that it does that kind of thing internally
[10:15] <keesj> well I do use it a lot for simple service depenencies but that is not enough
[10:17] <keesj> (trying to explain why..)
[10:20] <keesj> well it's also what the sysv replacement does
[10:24] <keesj> would it help if I send a mail to the mailing list explaining the problems I have?
[10:24] <Keybuk> sure
[10:25] <keesj> I really boils down to the http://upstart.ubuntu.com/getting-started.html on bounce example not wokring 
[10:26] <Keybuk> it doesn't?
[10:27] <keesj> no
[10:28] <Keybuk> I don't see a bug about that anywhere
[10:29] <keesj> well it's not like there is a definitive list of the syntax of the files so I would know what to expect to be honest
[10:30] <Keybuk> http://upstart.ubuntu.com/wiki/Stanzas
[10:30] <keesj> This page corresponds to upstart 0.3.9. The syntax and job control mechanisms is greatly improved in 0.5.0. 
[10:31] <Keybuk> ...if only it were a wiki ;)
[10:32] <keesj> I did edit some parts of that 
[10:33] <keesj> on that page the console also had non existent options 
[10:35] <Keybuk> seriously though, if something isn't working, then a bug should be filed
[10:37] <keesj> ok suppose the on bounce would work and would take 5 seconds to run and I emit 5 bounce withing one second , what should the behaviour be?
[10:37] <Keybuk> depends on what you do in bounce
[10:37] <Keybuk> you either want just one running at a time
[10:37] <Keybuk> so use the default behaviour
[10:37] <Keybuk> you want one running for each bounce
[10:37] <Keybuk> so add "instance ..." to your job
[10:38] <Keybuk> or you want one running at a time, but if bounce occurs while it's running, it needs to be run again (but only once no matter how many bounces occur)
[10:38] <Keybuk> so instance and exec watershed
[10:39] <keesj> if I would like a single instance to be run 5 times would that be possibe?
[10:39] <Keybuk> sure, in 0.3.x just add "instance" to the job
[10:41] <keesj> I am on 0.5
[10:41] <keesj> 0.5.1 even
[10:42] <Keybuk> that's a bit more tricky, you need to add something to the bounce to instance on
[10:42] <Keybuk> which is a bug in 0.5
[10:42] <Keybuk> well, more of a misdesign
[10:46] <keesj> hm. can you explain a little more?
[10:46] <Keybuk> in 0.5, you have to have something to define the limits of the instance
[10:47] <Keybuk> it doesn't let them be unlimited
[10:47] <Keybuk> so in the bounce example, you'd have to include (for example) a BOUNCENUM variable that changed for each one
[10:47] <Keybuk> then the job could have instance $BOUNCENUM in it
[10:48] <keesj> but woudl that run the jobs in parallel?
[10:49] <Keybuk> yes
[10:51] <keesj> what I reall woudl like is that this task gets executed 5 time
[10:56] <Keybuk> that works in 0.3 and will work again by 0.10
[10:56] <keesj> writing the mail..
[10:59] <Jc2k> wg 8
[11:00] <Keybuk> bah, that one's less fun than "win"
[11:21] <keesj> I guess what needs doing for the Stanzas is to Create 2 pages one for 3.8 and one for 0.5
[12:29] <keesj> https://lists.ubuntu.com/archives/upstart-devel/2007-March/000241.html tels that "on EVENT" was removed
[12:29] <Keybuk> yes, in all versions of upstart since 0.2, "on" has been identical to "start on"
[12:52] <keesj> I am trying to implement some hack/proof of concept for the handler. From my current understanding what needs to happen is that I need to block events to a jobs instance while it is running as handler
[12:53] <keesj> so increasing the blocker on start and decreasing it on stop when that job is defined as ... "handler"
[13:01] <Keybuk> I'm not sure what you mean by "block events"
[13:04] <Keybuk> jobs don't "receive" events
[13:04] <Keybuk> but they can have their state changed by them
[13:04] <keesj> what I want to happen (I guess) is that in event_poll (in event.c) the event gets skipped because there are "bockers"
[13:04] <keesj> blockers
[13:05] <Keybuk> then it would be missed
[13:05] <keesj> and would be removed from the queue?
[13:05] <Keybuk> right
[13:05] <Keybuk> events can be held in the queue while things are processing them
[13:06] <Keybuk> but that's after job states have been changed
[13:11] <keesj> do you understand the difference between "my" state machine and the upstart states?(I think that mainly the logic to perform a state change is put in a script)
[13:21] <Keybuk> no
[14:32] <Keybuk> I shall read the mails later ;)
[20:03] <sadmac2> Keybuk: around?
[20:03] <Keybuk> briefly
[20:03] <Keybuk> what's up?
[20:04] <sadmac2> Keybuk: was anyone working on the dbus properties code?
[20:04] <Keybuk> me
[20:04] <Keybuk> right now
[20:04] <Keybuk> that depends on variant code
[20:04] <Keybuk> which is what I'm trying to figure out
[20:04] <sadmac2> Keybuk: ok. I'll leave that to you then
[20:04] <sadmac2> Keybuk: variant code?
[20:05] <Keybuk> properties use variants
[20:05] <Keybuk> right, bbl