IRC Logs for #circuits Sunday, 2014-08-10

prologicblubberdiblub, hi05:13
blubberdiblubhi prologic05:13
prologicwe removed that component a while ago in circuits 3.005:13
prologicyou must be using 2.1.0?05:13
blubberdiblubah i see. yes, i'm using the package that is in ubuntu05:14
prologicyeah I recommend you upgrade to 3.0.0.dev05:14
prologicpip install circuits==3.0.0.dev05:14
prologicI think should work :)05:14
prologicor better yet (since we release very slowly)05:14
blubberdiblubyeah, i already have a virtualenv with that05:14
prologicpip install hg+
prologicthe reason we removed and
prologicwas well because they were just wrappers around some std. lib stuff05:15
prologicnamely ConfigParser and Logger05:15
prologicbut weren't async at all05:15
blubberdiblubok, so i could use that instead05:15
prologicdo whatever logging you want :)05:16
prologicbut for debugging, etc05:16
prologiccircuits does have Debugger()05:16
prologicuse to trace events and display uncaught exceptions05:16
blubberdiblubyeah, i'm using that, but i'd like a less intrusive logging and only of selected stuff, that's why i was trying to log stuff myself05:17
prologicDebugger is not designed for that purpose obviously05:19
prologicit's for "debugging" your app :)05:19
prologicit's trivial to write a logger that participates in the circuits event bus and listens to log events, etc05:19
prologicwhat would be even better is if it actually did the logging asynchronously05:19
prologicif you come up with a good design05:20
prologicwe'll accept it :)05:20
blubberdiblubbtw, i have an idea to extend the "yield" functionality of event handlers that would make certain kinds of handlers more readable, more maintainable and more performant05:21
blubberdiblubright now, i have a component that extracts packets of a protocol (minecraft specifically) out of a tcp stream, which is a quite convoluted handler, because you get data bits that are not necessarily at minecraft packet boundaries. if i had a way to "event = yield" to get the next event instead of having to return, the handler would get _a lot_ simpler05:23
blubberdiblubobviously, you cannot just "event = yield", because it would clash with the existing yield functionality, but something like "event = yield SPECIAL_VALUE" would work05:25
blubberdiblubor even "arg1, arg2, ... = yield SPECIAL_VALUE" and "event, arg1, arg2, ... = yield SPECIAL_VALUE"05:27
blubberdiblubit's some kind of wishful thinking ;)05:32
prologicI see05:41
prologicwhat if we could also multiplex coroutines?05:41
prologicso that a05:42
prologicresult = yield
prologicinside foo's event handler05:42
prologicwould in fact start a new coro05:42
prologicso they don't collide?05:42
prologiccall/wait (using Python's generators and yield) work quite well05:42
prologicbtut ehy do have a couple of limitations right now05:42
blubberdiblubbasically, i'd like to become
blubberdiblubit's not really shorter in this case (i spent some time streamlining it, yesterday), but note the absence of the ready handler to initialize the state. actually, i don't need to save any state outside of the handler06:03
blubberdibluband the flow is much clearer in the second case. it's just alternating between reading the varint size of the packet and the packet data itself, in a loop06:03
prologicexcept that in any event-driven/async system08:21
prologicyou don't want to block like this :)08:21
prologicif it were me I'd probably split this read handler up a bit08:26
prologicand make more use of states08:26
prologicfor instance with the http protocol parser we use in circuits.web08:27
prologicwe create a parser object per connected client08:27
prologicand feed in data to it's buffer until it reaches a valid request state08:27
prologicthen we fire a request event08:27
prologicthat's the basic pattern08:28
*** sapiosexual has quit IRC08:43
blubberdiblubprologic, but the idea is not to block. the idea is when yielding with the SPECIAL_VALUE (or rather WAIT_FOR_NEXT_EVENT), control is handed back to the framework, the framework sees the special value as return value from send(), takes note that the handler is within a generator and is waiting for the next event and then goes on doing it's business (event loop). then whenever another event gets fired that matches this handler, it sees the no09:45
blubberdiblubte it took earlier that it is in WAIT_FOR_NEXT_EVENT state and hands the arguments (and/or event) to the generator.send() function, instead of the handler entry09:45
blubberdiblubwell, i hope you get my point ;)09:46
blubberdiblubthe point is to write clearer coroutines with less boilerplate and less unnecessary external state while still being asynchronous / event based09:50
prologicI see what you're describine here10:05
prologicin theory we could use the .send() function here10:06
prologicof generators10:06
prologiccan you come up with a poc?10:06
blubberdiblubyou mean like a patched circuits plus some working example code that demonstrates the concept?10:11
*** ninkotech__ has quit IRC10:32
*** ninkotech__ has joined #circuits10:32
*** ninkotech__ has quit IRC10:45
*** Osso has joined #circuits10:52
prologicblubberdiblub, yes :)10:54
prologicbare in mind though10:55
prologicdon't break too much (or at all if you can help it)10:55
prologicas circuits is been around for a while and we're at 3.010:55
prologicwe take backwards compatibility very seriously :)10:55
prologicbut yeah a proof of concept be good10:55
prologicto see how it all works in practice10:55
prologicbasically in circuits the way we use yield in python10:55
prologicis to create control flows10:56
prologicin an otherwise event-driven/async system10:56
blubberdiblubyes, that's the idea10:59
*** koobs has quit IRC11:03
prologicI came across some libraires/frameworks the other day11:40
prologicquite new11:40
prologicit seems circuits has had somewhat of a positive influence on similar event-driven/async libraries/frameworks11:40
prologicthis one in particular used fnmatch to match events with event handlers11:41
prologican interesting idea11:41
prologicbut I wonder how much it would impact performance :)11:41
*** Osso has quit IRC14:02
*** anunnaki1 has joined #circuits15:34
*** anunnaki1 has quit IRC15:35
*** techdragon has quit IRC16:23
*** koobs has joined #circuits22:57

Generated by 2.11.0 by Marius Gedminas - find it at!