IRC Logs for #circuits Wednesday, 2014-04-02

c45ywell better get started :P01:39
prologiclol01:40
prologicwhat are we doing for lunch?01:41
c45yI have noodles today01:44
c45yand more php to write :(01:45
prologickk01:48
Romsterlunch time being late because i was fixing a computer.02:43
*** Ossoleil has joined #circuits08:16
prologicOsso, food for thought... respond when you can09:02
prologicOsso, I have a real use-case for call/wait and have a problem with how it's designed09:02
prologicnamely that you cannot wait/call a specific instance of an event -- only a named event (could by any)09:02
prologicConsider the use-case09:02
prologicYou have a web app, you need to do some CPU bound work.09:02
prologicSo you fire a task() event as a Worker() component configured as a process pool09:03
prologicYou synchronously call the event and yield it's output in your web app's request handler09:03
prologicProblem is, you could have multiple such inbound requests09:03
prologicAll of a sudden you get back the completion of some other "task" event that you didn't expect (you were after then one you called)09:04
prologicThis presents a problem obviously09:04
prologicSo that's the problem.09:05
prologicThere are a number of things I'm thinking about:09:05
prologica) Is there ever a use-case where you want to use call/wait primitives to wait for any event of the given name?09:06
prologicb) Do .call()/.wait() even make sense at all?09:06
prologicb2) Should we move/redesign this semantically so that you "wait" for the completion of an event that is specifically tied to it's "Promise" value returned? e.g: value = self.fire(foo()); yield value.wait(); ...09:07
Ossoleilprologic: sorry I can give a longer answer later but11:14
Ossoleilwe had support for waiting for a particular event instance11:15
OssoleilI don’t know if it is still there or gone11:15
Ossoleilbut in my mind yes I often wanted to wait for a particular instance11:15
prologicOssoleil, ahh12:07
prologicwas this via something like:12:07
prologice = foo()12:07
prologicx = self.fire(e)12:07
prologicyield self.wait(e)12:07
prologic?12:07
Ossoleilyes12:15
Ossoleilactually self.call should do just that12:18
prologictherein lies the problemthen12:30
prologicI believe it doesn't12:30
prologicI will have to develop a test case12:30
prologicso if I'm to understand our design properly12:30
prologicself.wait("foo")12:30
prologicwill wait for the next "foo" event of any instance12:31
prologicwhilst12:31
prologice = foo()12:31
prologicself.wait(e)12:31
prologicwill wait for that specific instance to occur?12:31
Ossoleilyes12:33
Ossoleilit should at least12:33
Ossoleilotherwise I see it as bug because self.call will never work properly12:34
*** Ossoleil has quit IRC16:42
*** spaceone has joined #circuits17:46
prologicOsso, indeed20:12
prologic Osso https://bitbucket.org/circuits/circuits/issue/91/call-wait-and-specific-instnaces-of-events22:56
c45yinteresting instance checking23:01
prologichmm?23:10
Ossooh I see the bug now23:20
Ossois isinstance expensive?23:20
prologicnot sure23:34
prologicit shouldn’t be - it need only check the object’s class and bases23:35
prologicdo we need to develop some benchmarks of call/wait?23:35
prologiccircuits.bench only behchmarks fire()23:35
prologicin events/s and lateency between two events23:35
prologicOsso: you got time to look at this?23:49
c45yprologic: pretty sure times will depend on how deep you nest your classes23:56
c45yas isinstance checks against parents/siblings23:57
prologicc45y: yes of course23:58
prologicso the performance could degrade if you use call/wait heavily with deeply nested event classes23:58
prologicalthough tbh I’m not sure why you would :)23:58
c45yI can't really think of an alternative though either23:58
prologic2 levels deep sure23:58
prologicno me neither23:58
prologicand I’m having trouble getting this right too23:59
prologic:/23:59
c45ywould type checking be sufficient?23:59

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!