IRC Logs for #circuits Friday, 2013-05-10

*** EasyMac_ has joined #circuits00:58
*** Romster has quit IRC02:07
*** Romster has joined #circuits02:16
*** Romster has quit IRC02:16
*** Romster has joined #circuits02:16
*** EasyMac_ has quit IRC02:38
*** koobs has quit IRC05:48
*** koobs has joined #circuits05:55
*** koobs has quit IRC05:56
*** koobs has joined #circuits05:56
*** Osso has joined #circuits07:41
*** Osso has quit IRC07:43
*** Osso has joined #circuits07:49
prologicheya Osso08:09
prologicso we all like the new logo then?08:09
prologichello! indeed :008:09
prologicbeen busy?08:09
prologicI've been sick for a week08:09
Ossooh no :(08:10
prologicso new logo?08:16
*** Romster has quit IRC08:22
*** Romster has joined #circuits08:23
*** Romster has quit IRC08:23
*** Romster has joined #circuits08:23
Ossoworks for me prologic :)08:47
prologicgood good :)08:47
prologicwe need to get 2.2 out the door :)08:47
prologicfew tasks left08:47
OssoI got dragged by the train of life08:48
prologicsame :)08:49
prologicI'm just saying08:49
prologicalso telling myself!08:49
Ossoyeah I have more free time cause my girlfriend is away08:49
Ossobut I have many projects I have started grr08:49
OssoI had an idea08:49
Ossowe never found a good way to make promise objects08:50
OssoI was thinking what we really wanted was a bit like a shortcut08:51
prologicwell we just haven't implemtned promoses properly08:51
prologicit's sort of half arsed :)08:51
Ossoyou would give it parameters and it is called when the promise is ready08:52
prologicwe need to rework promises08:52
prologicand work in more meta-programming08:52
Ossof(promise, arg1, arg2) and in the background it binds a handler somewhere08:52
prologicpossibly employing data descriotors08:52
Ossoand boom08:52
prologicso that things just work seamlessly08:52
prologicI think it's all very possible08:52
prologicwe just have to do it08:52
prologicbetter promises would make doing async things in circuits very nice ihmo08:53
OssoI think so too08:53
prologicthere was a guy in here the other day (check th logs) ricohet I think08:54
prologiche is using circuits to interface with Asterisk08:54
prologicI gave him a few pointers08:54
prologicbut there are a few things he brought up08:54
prologicpriority events08:54
prologiche has a need for them08:55
prologicand I thought we could probably easily add them without breaking anything08:55
*** Romster has quit IRC08:55
prologiche also menntioned something about marking events of the same type as obsolete08:56
prologicbut I pointed out that this could simply be done by a high priority handler listening to all events08:56
prologicand filtering out unwanted events08:56
*** Romster has joined #circuits08:57
*** Romster has quit IRC08:57
*** Romster has joined #circuits08:57
Ossobut we already have priorities on events08:59
prologicyes handlers08:59
Ossowhat is a priority event ?08:59
prologicnot events :)08:59
prologican event that is processed before others08:59
prologicthe type of queue we use atm08:59
prologicis a FIFO queue08:59
prologicwhat he needs is for us to use a prioritied queue08:59
Ossook right I see08:59
Ossomakes sense08:59
prologicusing an optional keyword arg on fire/call08:59
prologicI might give it a shot and see how it turns out09:00
prologicI believe a heapq can be used easily for this09:00
prologicby storing tuples09:00
prologic(priority, event_object)09:00
OssoI can see why he wants obsolete events, a sort of singleton but for events09:00
prologicexcept that this can be done in application logic09:01
prologicvia a high priority handler as I said09:01
Ossobut that's not very efficient09:02
prologicno I agree it's not09:02
prologicbut not overly inefficient09:02
Ossoyou want to go through the whole event queue to check for duplicates?09:02
prologicyeah either way it would be O(n) complexity09:03
Ossoinstead internally we can do it more efficiently by storing event types counts09:04
prologicdo you think we should try to incorporate that into the core too09:04
prologicas well as prioritized events09:04
Ossoprioritised events definitely09:21
Ossonot sure about the other09:22
OssoI feel you write the equivalent using ticks somehow09:22
prologichmm we got rid of that :)09:22
prologicyou'd write the equivilent like09:22
prologicdef _on_all_events(self, event, *args, **kwargs):09:22
prologic   if event.obsolete>09:22
prologic      set a flag for the type09:22
prologic      return False09:22
prologic   if special_flag:09:22
prologic     return Flase09:22
prologicprolly a bti more complicated09:22
prologicbut yeah09:22
prologicyou have to keep track of event types09:22
Ossowe definitely still have ticks09:22
Ossothe whole generate_event thing09:22
prologicoh yes ofc09:22
prologicbut the name/handler-type "@ticks" is gone09:22
Ossoyes sure09:22
prologicin favor of an internal mechanism that constantly fires GenerateEvents :)09:22
prologicwhich I've come to like :)09:22
Ossobut I think that when you want your event to obsolete09:22
Ossoyou actually want an event generator09:22
prologicwhere your event generator (handler)09:22
prologicconsumes all of the events of the system09:22
prologicand regenerates a new stream of events?09:22
prologicok explain :)09:22
Ossook give me 1s09:22
*** irclogger_ has quit IRC09:29
*** irclogger__ has joined #circuits09:29
prologicOsso, hmm11:45
prologicdon't quite understand from that code11:46
prologicmissing a few important bits?11:46
prologicthe situation ricochet described to me is this:11:46
prologicyou fire a bunch of prioritized events into the system11:46
prologicas the queue fills up between cycles (ticks)11:46
prologicthere may be one or more events of the same type11:47
prologicone of those may have an "obsolete" mark11:47
prologicwhere the system drops the others in favor of the one event that superceded the rest11:47
Ossoit is not for the prioritised events11:57
Ossoit's for the obsolete events11:57
Ossooh yeah what you said11:57
Ossoseen in this case11:57
Ossoinstead of firing an event you set a variable to true11:58
Ossoyou can set it many time to true11:58
Ossoyou still get only one event11:58
prologicah ic11:58
prologichow about this as an idea instead11:58
prologica singleton event type11:58
prologicmuch like where we have derived events11:58
prologicand literal events11:58
prologicwhereby only one such event type can exist in the queue at any point in time11:59
prologicso you'd do:11:59
prologicclass Foo(UniqueEvent):11:59
prologic   """My Unique Foo Event"""11:59
prologicand somewhere11:59
prologiceach repeated firing of Foo() within a single cycle (tick)11:59
prologicwill only result in Foo being in the queue at most once (1 time)12:00
Ossoyes certainly but!12:00
prologicgo on :)12:00
Ossowe have to do all this event queue checking12:00
Ossoand that part is performance critical12:00
prologicI think this adds prioritized events12:04
prologicnot if we keep a mapping of event types in the system through each cycle12:04
prologicO(1) lookup of type -> count12:04
prologicDoes this sufficiently test prioritized events?12:25
OssoI don't think it'll work properly12:32
Ossothe test I mean12:32
Ossoit'll run while it is still sending events12:32
Ossoso potentially the one with priority will run before the one with priority 1012:32
prologicoh that's true12:33
prologicfire is not atomic12:33
prologicunless I do it by hand12:33
prologicwith a non-running system12:33
prologicand tick it manually12:33
prologicI could just simplify this test a whole lot12:34
prologicThere we go:12:48
prologicOsso, have a look at that12:48
prologiccorrectly passes the test now12:48
prologicin the way I think it should12:48
prologicand I solved sort stability12:48
prologicthat is12:48
prologictwo events added with the same priority are processed in-order12:49
Ossowhy are the (event, channel) grouped togther?12:50
prologicwhat's more important12:51
prologicit doesn't seem to affect performanec at all12:51
prologicumm I guess they don't have to be12:52
prologicI was just following heapq's docs12:52
prologic3 item tuple for sort stability12:52
prologic(pri, cnt, task)12:52
prologicnow circuits can be used as both a queue and stack12:55
prologicor anything in between12:55
Ossogood good12:58
prologicwhat should the default priority be?13:00
prologic0 doesn't make much sense to me13:00
prologicif everything has 0 priority13:00
prologicthen hmm13:00
prologicthinking maybe default priority should be sys.maxint13:00
prologicThis is what we need to incorporate intou circuits.core.value13:47
prologicWe probably should make all of the API in Value all private/internal API13:47
prologicthey're not useful outside I don't think13:47
prologicthen we can start to do things like:13:47
prologicx =
prologicy =
prologicand later on13:47
prologicreturn x + y13:47
prologicWhat we can do with this pattern is incorporate Promise pattern into it as well13:48
prologicso that if x is not yet ready13:48
prologicthe call to any of it's methods (proxied) are queued13:49
prologicor we create a dynamic handler13:49
prologicwhichever works best13:49
Ossowhy does not 0 make sense ?13:50
OssoI don't think we need any kind of proxying13:55
Ossoyou want to be called at the right, when the promise is available13:55
Ossoso you don't a proxy13:55
Ossoif you just want to wait inline you can just use .call13:56
prologicproxying allows us to hide away the vslue14:15
prologicso its just x + y14:16
prologicinstead of x.vale + y.value14:16
prologicalso with the most recent chamges, all tests on all platforms seem to be passong again14:17
prologicthe fix i made to tests/ seems to have fixed a lot of race conditions14:17
Ossogreat :)14:42
*** Osso has quit IRC17:59
*** jgiorgi has joined #circuits23:27
*** jgiorgi has quit IRC23:27
*** jgiorgi has joined #circuits23:27

Generated by 2.11.0 by Marius Gedminas - find it at!