[16:57] <sadmac2> ion_: ping
[17:04] <ion_> sadmac: pong
[17:05] <sadmac2> ion_: I just pushed a new version of the state machine
[17:06] <sadmac2> ion_: it has some minor behavioral tweaks, and an example file with a real world demo of sorts
[17:06] <sadmac2> (just a small example of drive mounting. designed to be played with more than just run)
[17:07] <sadmac2> Keybuk: If you want to look at it, its a solution to your infamous mounting scenario
[17:09] <Keybuk> pushed?
[17:09] <sadmac2> Keybuk: git://fedorapeople.org/~sadmac/upstate.git
[17:09] <Keybuk> do you have a description of what it does?
[17:10] <Keybuk> or do I have to learn ruby?
[17:10] <sadmac2> Keybuk: that mailing list post I made still describes the general idea.
[17:10] <Keybuk> I didn't really understand that :p
[17:12] <sadmac2> Keybuk: well shit :D
[17:12] <Keybuk> you need to explain things better for people who can't read your mind :p
[17:13] <sadmac2> Keybuk: its not a matter of mind reading. its a matter of having an unhealthy addiction to category theory ;)
[17:13] <Keybuk> you're the only person on the planet with that :p
[17:13] <sadmac2> the only one that universities let out of their math department basement
[17:14] <sadmac2> Keybuk: well, you have states
[17:14] <Keybuk> those kind of people never tend to leave university
[17:14] <sadmac2> Keybuk: states are 1) a name, 2) a series of parameters in the name=value format
[17:14] <sadmac2> true
[17:14] <Keybuk> can you post to the ML?
[17:15] <Keybuk> I'm doing other things right now, and don't log IRC
[17:15] <sadmac2> Keybuk: good point
[17:15] <Keybuk> (other things including a kernel patch that will make my world truly made of awesome, and solve one of my big upstart problems - which of course means it'll be rejected, but hey :p)
[17:17] <sadmac2> Keybuk: what patch?
[17:18] <Keybuk> 'tis a secret until it goes on lkml
[17:19] <sadmac2> hmm
[17:19] <sadmac2> we just tried waitfd, so....
[17:19] <sadmac2> I'm guessing its that ring buffer dealie
[17:30] <ion_> sadmac: Alright, the example works.
[17:31] <ion_> Now if i only understood it. :-)
[17:32] <sadmac2> ion_: well, the first 3 lines create states
[17:32] <sadmac2> ion_: arguments are:
[17:32] <sadmac2> name
[17:33] <sadmac2> list of events that trigger it
[17:33] <sadmac2> list of dependencies
[17:33] <sadmac2> list of parameters that have to come from something other than dependencies (the event causing the state to come up, or the user if the user is starting it)
[17:34] <sadmac2> that list of parameters can be like [a, b, c] or it can have little sub groups like [a, [b,c], c]
[17:34] <sadmac2> the sub group means "at least one of these"
[17:35] <sadmac2> Event::Epsilon is an event that happens any time it might cause something. So saying a state comes up on Event::Epsilon basically means it comes up whenever it can
[17:36] <sadmac2> Event.new takes 2 arguments, a name of the event, and arguments
[17:36] <sadmac2> for events that we're using for comparison, the arguments can have regex values
[17:37] <sadmac2> so if the state starts on Event.new("Can_Mount", {:mount_str => /.*/}) it means the Can_Mount event will start it provided it has a mount_str argument, and that argument can have any value
[17:37] <sadmac2> ion_: with me?
[17:38] <ion_> Yeah, i think :-)
[17:39] <sadmac2> ion_: try adding and removing stuffs from the events list to make more drives
[17:44] <ion_> I’m not sure i understand the output.
[17:45] <sadmac2> ion_: red states are down, green states are up
[18:15] <sadmac2> Firefox's spell check is british
[18:15] <sadmac2> colors->colours
[18:15] <sadmac2> friggin u
[18:16] <sadmac2> ion_: has it all become wonderously clear now?
[18:20] <ion_> Sorry, no. :-)
[18:23] <sadmac2> ion_: anything I can do to help...
[18:23] <sadmac2> at least until I hit lunch in 5mins :D
[18:32] <Keybuk> sadmac2: how does this solve mounting?
[19:17] <sadmac2> Keybuk: the example demonstrates it
[21:21] <Keybuk> sadmac2: I have to install ruby then?
[21:50] <sadmac2> Keybuk: ah, don't have it?
[21:53]  * sadmac2 notices a glitch in the example
[21:54] <sadmac2> pushed fix
[21:55] <sadmac2> Keybuk: in the new state machine, you have a state for each fstab line, and a state for each device which udev notes to be present, and a mounted state that depends on those two
[21:55] <sadmac2> Keybuk: and the parameters are properly collated depending on which are available
[21:57] <sadmac2> Keybuk: the devicekit_hd state has blkdev, uid, and name properties (or whatever parameters you want to mount on)
[21:57] <sadmac2> Keybuk: and the fstab state has one or more of those 3
[21:57] <sadmac2> Keybuk: the mount state will only take a given pair of them as dependencies if their like-named arguments agree
[22:00] <sadmac2> Keybuk, ion_: http://screwyouenterpriseedition.blogspot.com/2008/12/new-upstart-state-machine.html
[22:00] <sadmac2> part 1 of many
[22:06] <suihkulokki> curious name for blog =)
[22:08] <ion_> sadmac: Thanks, will read.
[22:09] <sadmac2> suihkulokki: I like it
[22:10] <ion_> sadmac: Thanks for using red and green, which are hard to tell apart for some of us. :-P
[22:15] <ion_> sadmac: I suggest making the ‘up’ ones bold.
[22:16] <sadmac2> ion_: not a bad idea. that green doesn't read too well.
[22:19] <suihkulokki> hmm. so say, if we'd have a state "offline()" or more precisely "rfkill()"
[22:19] <suihkulokki> in what case would the state be up or down ?
[22:21] <sadmac2> suihkulokki: we haven't gotten that far yet :)
[22:22] <sadmac2> suihkulokki: the important thing to understand for that part is that they can be up or down, and that this doesn't effect their equivalence relation.
[22:22] <sadmac2> s/relation/class/
[22:22]  * sadmac2 wonders if anyone would have called him on that
[22:40] <Keybuk> ok, so a state has a name, some parameters, and is either up or down
[22:41] <Keybuk> I didn't understand the "mathy idea"
[22:42] <sadmac2> Keybuk: ok, so there are only a certain number of valid values for name
[22:42] <sadmac2> Keybuk: on a given system, you'll have dbus, gnome-session, etc.
[22:42] <sadmac2> Keybuk: hypothetically, though, there's infinite possibilities for the parameters
[22:43] <sadmac2> Keybuk: and a state exists for every one
[22:43] <sadmac2> Keybuk: the point is, we don't talk about whether a state "exists" or not in this paradigm. It always exists. period.
[22:43] <sadmac2> Keybuk: we talk about whether its running.
[22:49] <Keybuk> states are jobs
[22:49] <Keybuk> jobs have any environment
[22:49] <Keybuk> there's no difference between a job not existing and not running
[22:50] <sadmac2> Keybuk: that's what allows us to get away with it :)
[22:50] <Keybuk> ?
[22:50] <sadmac2> Keybuk: the principle is there to make it easier to talk about the workings of the mechanism
[22:50] <Keybuk> so what I just described matches what you were describing?
[22:51] <sadmac2> Keybuk: in a sense. it'd be more accurate to say that what you described was an implementation detail. Like the preface said, I'm just describing behavior.
[22:51]  * Keybuk gives up
[22:53] <sadmac2> Keybuk: you might be thinking too concretely. There's really no such things as jobs for this model :)
[22:54] <sadmac2> Keybuk: this is something you put information into, and you get out a list of things that should be running
[22:54] <sadmac2> and even that depends on you interpeting it that way.
[22:55] <Keybuk> so there's no point me reading anything you write?
[22:55] <Keybuk> fair enough
[22:55]  * Keybuk goes
[22:56] <ion_> Now, now
[22:57] <Keybuk> seriously
[22:58] <Keybuk> we're trying to write a replacement init daemon that's easy for sysadmins to use
[22:58] <Keybuk> the O'Reilly book on Upstart does not need to have "all this book assumes is that you have several PhDs in advanced mathematics and number theory" in the introduction
[23:02] <Keybuk> a sysadmin or distro maintainer will be thinking in terms of jobs
[23:02] <Keybuk> (or at least services and tasks)
[23:02] <Keybuk> so their requirements, dependencies, etc. need to be explained in that language too