ruote tmp/log_2011-05-13.html

2011-05-13 10:48:11 utc lbt hi jmettraux ... I'm looking at something like http://pastie.org/1896420
2011-05-13 10:48:50 utc lbt probably need a :count => 1
2011-05-13 10:49:48 utc lbt but also wondering if it would make sense to not cancel each 'get_*_vote' participant on each loop
2011-05-13 10:50:21 utc lbt there's a risk of losing votes if that happens
2011-05-13 10:54:40 utc jmettraux lbt; hello, what are you trying to achieve ?
2011-05-13 10:56:15 utc lbt a community QA process
2011-05-13 10:56:56 utc lbt so the idea is that once the pkg is in testing we get feedback from various channels
2011-05-13 10:57:30 utc lbt then some measurement is made (simplistic >5 + votes, more likely to be weighted and fiddly)
2011-05-13 10:57:36 utc jmettraux ok
2011-05-13 10:57:42 utc lbt then accept/reject
2011-05-13 10:58:03 utc lbt so this is the distribution of feedback tasks
2011-05-13 10:58:29 utc lbt I'd like a stream of votes to come in and be fed into the counting and promotion logic
2011-05-13 10:58:55 utc lbt thoughts included to spawn sub-processes and use listen
2011-05-13 10:59:24 utc lbt or a variance on concurrent_iterator :until =>
2011-05-13 10:59:38 utc lbt but that's actually hard :)
2011-05-13 11:00:56 utc jmettraux cooking something
2011-05-13 11:01:17 utc lbt :)
2011-05-13 11:03:59 utc jmettraux https://gist.github.com/970352 variant where the voting is not "encapsulated" in a participant
2011-05-13 11:05:47 utc jmettraux https://gist.github.com/970355 waiting 1h between the counting sessions
2011-05-13 11:06:51 utc lbt OK - I wanted the process to be the controller
2011-05-13 11:07:18 utc lbt so if I have a new type of vote capture system then I add it in as a potential contributor
2011-05-13 11:09:14 utc jmettraux https://gist.github.com/970358 where the concurrence exits when more than 5 votes
2011-05-13 11:10:20 utc lbt pondering how that one works
2011-05-13 11:11:02 utc jmettraux :count => 1 means that the concurrence is over as soon as 1 branch replies
2011-05-13 11:11:36 utc jmettraux if you make sure that vote :action => 'expose' doesn't reply, only the repeat branch can break the concurrence
2011-05-13 11:11:37 utc lbt so in this case the votes participant would multiplex all the types
2011-05-13 11:12:15 utc jmettraux or you could have a participant for each channel
2011-05-13 11:12:30 utc jmettraux but you'd have to make sure it doesn't reply
2011-05-13 11:13:00 utc lbt how would it reply to the repeat'ed participant ?
2011-05-13 11:13:31 utc lbt the vote result is passed in the wi (remote, no shared db)
2011-05-13 11:13:39 utc jmettraux the repeated participant is something like "count_vote"
2011-05-13 11:13:50 utc lbt and they all reply to that
2011-05-13 11:13:52 utc jmettraux it counts, no
2011-05-13 11:13:54 utc jmettraux it counts, now
2011-05-13 11:14:13 utc jmettraux repeat is over when $f:votecount > 5
2011-05-13 11:14:26 utc lbt what does it count?
2011-05-13 11:14:29 utc jmettraux votes
2011-05-13 11:14:48 utc lbt how do they get back into the process? if none of the channels reply ?
2011-05-13 11:15:00 utc lbt side channel?
2011-05-13 11:15:07 utc jmettraux I don't know your architecture
2011-05-13 11:15:15 utc jmettraux maybe you write votes to a database
2011-05-13 11:15:38 utc lbt the aim was to message pass from each participant via the wi
2011-05-13 11:15:49 utc lbt and have the process consolidate
2011-05-13 11:15:54 utc jmettraux you're mixing things
2011-05-13 11:16:07 utc jmettraux ok
2011-05-13 11:16:12 utc jmettraux now I got it
2011-05-13 11:16:53 utc jmettraux I wouldn't do it like that, but anyway
2011-05-13 11:21:08 utc jmettraux back to the drawing board, back to your initial idea
2011-05-13 11:21:28 utc lbt thinking a little more...
2011-05-13 11:21:50 utc lbt I'll have a lot of processes hanging around ... 1 per package being promoted
2011-05-13 11:24:52 utc jmettraux https://gist.github.com/70fd0cd3c5255f4f98bf it's your idea
2011-05-13 11:25:37 utc jmettraux https://gist.github.com/642b6f0a76db512cc8a9 sorry, this is better
2011-05-13 11:26:33 utc lbt was getting my head into : https://gist.github.com/970372
2011-05-13 11:26:35 utc jmettraux https://gist.github.com/970375 with one more fix
2011-05-13 11:27:44 utc jmettraux https://gist.github.com/970372 indentation makes it hard to understand
2011-05-13 11:28:46 utc lbt it's not done.... was just thinking along those lines ... anyhow won't you have to get used to indentation-driven processes now? ;)
2011-05-13 11:28:51 utc jmettraux https://gist.github.com/970375 has a weakness : it takes breaks from listening, it can thus let votes go without counting
2011-05-13 11:29:24 utc jmettraux true :)
2011-05-13 11:31:41 utc lbt nb "repeat" is not listed in the index box on http://ruote.rubyforge.org/exp/cursor.html
2011-05-13 11:32:02 utc jmettraux true, it's "loop"
2011-05-13 11:32:05 utc jmettraux good point
2011-05-13 11:32:15 utc lbt loop isn't there either
2011-05-13 11:32:56 utc jmettraux lol
2011-05-13 11:32:58 utc jmettraux it's "cursor"
2011-05-13 11:33:09 utc jmettraux sorry
2011-05-13 11:34:25 utc lbt I found it in the cursor page - but it's not an alias - feels like it deserves a page on its own
2011-05-13 11:35:09 utc jmettraux it's a cursor that loops
2011-05-13 11:35:27 utc lbt *nod* it's also not clear if it takes the same ":break_if" as a cursor
2011-05-13 11:36:06 utc jmettraux sorry, I thought the first sentence of the page made it clear
2011-05-13 11:36:55 utc lbt it does - I guess I'd forgotten that line by the bottom of the page
2011-05-13 11:37:32 utc lbt I suggest the page heading => Cursor/Repeat
2011-05-13 11:37:59 utc lbt but that's just feedback :)
2011-05-13 11:38:16 utc lbt anyhow .. thanks for the vote ideas ... I'll look at them in more detail
2011-05-13 11:38:43 utc jmettraux thanks for the documentation feedback
2011-05-13 11:38:49 utc jmettraux trying to fix that
2011-05-13 12:13:25 utc jmettraux pushed a temporary fix http://ruote.rubyforge.org/exp/cursor.html for example
2011-05-13 19:20:54 utc sandbox hey everyone
2011-05-13 19:21:04 utc sandbox is there a way to migrate from one ruote storage system to another?
2011-05-13 21:29:24 utc phaeron anyone awake ? I have an issue with iterator.
2011-05-13 21:30:02 utc phaeron iterator :on_val => '${ev.actions}', :to_var => 'action' do
2011-05-13 21:30:29 utc phaeron seems to deal with actions as a string instead of a list of hashes
2011-05-14 09:07:00 utc jmettraux you should be able to do iterator :on_field => 'ev.actions', :to_var => 'action' do
2011-05-14 09:13:00 utc jmettraux or on a recent version of ruote (2.2.0 at least) iterator :on => '$ev.actions', :to_var => 'action' do