IRC Logs for #circuits Monday, 2013-01-28

prologicThis is the unit test I have in mind for namespaces00:07
ronny2prologic, looks good at first glance00:09
prologicany foreseeable issues api-behavior wise?00:11
prologicis it what you expect?00:11
ronny2prologic, im not sure - i sleept a few nights over things, and im a bit in trouble, cause atm every time i try toderive a system completely i end up either at twisted or at plain actors00:15
prologicI'd like you to try with circuits once I implemented namespaces for you :)00:16
ronny2prologic, circuits is on a different level, im not sure how t fits into the base level there00:18
prologicwell for what you're doing (what are you doing?) I'm sort of hoping circuits will fill most of the gap00:18
prologiceven if that means circuits is your base level somewhat00:18
ronny2prologic, the thing is, the message buts abstraction at circuits is already too much abstraction00:19
ronny2what i have in mind is a pure actor model at the base00:20
prologicyeah ok00:21
prologicso help me make it less of an abstraction00:21
prologicwithout breaking it too much00:22
ronny2prologic, i have literally no idea how to make it less of an abstraction without completely breaking it appart00:22
prologicwell I need to know what you need to do00:22
prologicI think you can build an actor model on top of circuits00:23
ronny2prologic, thats true, but then i still get to have all the abstraction circuts has wrt messages00:24
prologicso if we can find some common ground00:24
prologicI believe circuits will greatly benefit your needs in other way00:25
prologicI can see namespaces as the first step00:25
prologicso I'm working on that now00:25
ronny2i'll wire up a very basic messagedispatcher, actor and then a channel and a process on top of it to show it00:27
prologicthat sounds good00:27
prologicthen I'll rewrite it using circuits?00:27
prologicand find the problems?00:27
ronny2prologic, im not sure you will be able to find some00:31
prologicyou think I'll be able to easily build an actor model on top of circuits/ :)00:33
prologicIn any case; know that I'm very interested in helping you - and I'm very interested in how the Actor model works and how it can be implemented.00:39
*** Osso has joined #circuits01:11
ronny2prologic, i implemented the most basic message dispatching, i'll need to build expressing payloads and protocols better before i can wire up the channel/process thing01:50
prologicI'll be happy to see the prototype02:01
ronny2you'll notice that it is very simplicistic02:05
ronny2it'll need protocols, processes and actor-refs to show the full model02:06
ronny2prologic, think you have some kind of gut reaction to it, i'd like to know that one02:18
ronny2prologic, nothing?03:38
prologicsorry just got back from dinner03:38
prologicYou do not have access to this repository.03:38
prologicUse the links at the top to get back.03:38
*** Irinix_Away has joined #circuits03:39
ronny2prologic, now its open03:40
prologicso you really do want an actor model03:43
prologicI hope you don't mind03:44
prologicbut I'm dragging Osso into this conversion03:44
prologicOsso, ping?03:44
prologicI fully believe what you've got there can be fully implemented in circuits right now03:44
prologicwhat's more it'll all just work03:44
prologicyou use channels as namespaces03:44
prologicbuild an Actor component that listen to Handle events (think messages)03:44
prologicand voila03:44
prologicperhaps you could go so far as to prevent the Actor class/component from being able to register any new handlers (just the one)03:45
ronny2prologic, the main idea behind that is always having direct communication03:45
ronny2a message always has exactly one target03:45
ronny2and its directly known03:46
prologicyes ofc03:46
prologicand you can achieve the same thing in circuits03:46
prologicby simply targeting the actor instances03:46
ronny2prologic, now the enxt step i intend to introduce will make a bigger difference - protocols and states03:47
prologicronny2, Osso and I agree03:47
prologicyou can implement Actor model on top of the primitives circuits has already03:47
Ossojust came back from lunch03:47
prologicronny2, I could probably port your code almost directly03:48
prologicreplacing object with Component03:48
prologicreplace some of the apis03:48
prologicand I think you're almost there03:48
ronny2prologic, let me finish protocols and processes on top of it first, i think they make a difference03:49
prologicI don't see how03:49
prologicyou've implemented all the requirements of Actor as far as I can see03:50
prologicexcept the executors03:50
prologicwhich won't make much of a difference ihmo03:50
prologicI think what you call processes03:50
prologicbut I think they'll make little difference03:50
prologiccertainly protocols won't03:50
ronny2protocols wont03:51
ronny2but processes need them to be expressable nicely03:51
prologicif you want03:51
prologicadd simple protocols and processes03:51
prologicand we'll try to port it03:51
mehereI think the usage of components as channel (targets) brings you as close to an actor model as is useful with circuits.03:51
prologicI'm afraid I must go to bed though03:52
prologicback at work tomorrow03:52
prologicbut I'll leave you in Osso's capable hands :)03:52
prologiche knows much about circuits!03:52
prologicmehere does too :)03:52
mehereCircuits is actually aiming at something different.03:52
ronny2mehere, can you explain that?03:52
mehereThe problem that circuits solves it to provide a component model.03:53
mehereOnce have that03:53
meherethe next question always is: how can I configure components.03:53
mehereJava has a long history of using "dependency injection", you know about that?03:54
prologicas I said, I strongly believe you can implement Actor model on top of circuits now03:54
prologicwith components03:54
mehereDependency injection requires the definition and usage of interfaces.03:55
mehereThis kind of introduces a "string coupling", components have to know a lot about each other.03:55
mehereSecond point is, how do I do configuration?03:56
mehereSpring uses an XML file (I don't like that), nowadays Java does a lot with annotations.03:56
mehereComes in the event bus. Basic idea:03:56
mehereComponents just know about events that other components fire. Of course, this requires some "interface" knowledge as well, but03:57
mehereyou don't store associations between components03:57
mehereComponents just listen to what happens on the bus (in circuits: channel) and react to things that look interesting to them.03:58
mehereComponents "pop" into existence and simply take part in the application without any configuration. This is what makes this concept such a great component-organization-concept.03:59
mehereThe capability to filter events and maybe replace them by modified events extends this concept even further.04:00
ronny2mehere, but the problem is, that without explicit association, you cant have 2 components with the same protocol without introducing a new kind of association/grouping04:01
mehereBut note that this is a component level concept, meaning that components can be "large" building blocks.04:01
mehereComponents can consist of several objects. Circuits is a bit misleading there because the classes in the "core" library are all04:02
meherevery small. In an application (e.g. my portal) they become much bigger and you can clearly see the difference between a class and a component.04:02
ronny2i'd like to see a bigger example then04:03
mehereThe actor model is much more low level and usually also involves concurrent execution by the executors.04:03
prologicthere are quite a few bigger examples already04:03
meheresorry, bbl04:03
prologicto names two of my own04:03
prologicoh also04:03
prologicsee I agree with mehere04:04
prologicthe Actor model is lower-level04:04
prologicwhich is why I think circuits can implement Actor04:04
prologicit's only a concurrency model afterall04:04
prologicwhereas circuits is actually a component model04:04
prologicnevermind the async I/O components and other tid bits04:05
ronny2prologic, you can think of an actor as a component that talks in protocols using messages04:05
ronny2prologic, also a reference to an actor is a cappability04:08
prologicyeah that's fine04:09
prologiccircuits has no problems with that04:09
ronny2an actor can create another actor that responds to a subset/filtered set of the protocol and send it as response to a message04:09
prologicthat's no problems either04:09
ronny2(thats the part where direct association is needed)04:09
prologicso your actor would simply spawn new actors inside itself to handle a subset of messages04:10
prologicthat's no problems04:10
prologicthen I suppose when it's done it'll discard them04:10
ronny2prologic, yes04:10
ronny2and it can also be used as a control mechanism04:11
ronny2imagien an actor whose point is to hand out other actors that give limited access to data04:11
ronny2and that the data can only accessed while that actor is active04:12
prologicWithout testing04:12
prologichere's your Actor components04:12
ronny2so once that actor is stopped, the references to it can no longer be used to access data04:12
prologicyeah well that'll be all in the actor model you're implementing04:13
prologiccircuits in this case will provide 2 things (I think):04:13
prologica) a message bus04:13
prologicb) a component model04:13
prologicplus you get for free async I/O worker pools and other nice things which you can wrap in your actors04:14
ronny2i think i now understood my modeling problem04:17
ronny2the message bus can be considered as an actor who owns a set of other actors and multiplexes messages to them according to their specification04:18
prologicin some ways circuits isn't too different from Actor - except that actors typically only respond to a single message type04:19
ronny2ok, then thats where my resistance comes from, for the things i want to have the lower level model04:19
prologiccomponents can spawn other components, can respond to messages, fire off new messages and so on04:20
prologicwhilst I believe we can implement pure Actor on top of circuits04:20
prologicI'm not so sure about implementing what circuits is on top of Actor04:20
prologicyou would loose a lot of the benefits of components I think04:21
ronny2prologic, consider component a specification of a protocol endpoint04:23
ronny2prologic, im fairly certain, that if message multiplexing was separated from component, we'd end up with an actor model04:32
prologicyes you are quite right04:33
mehereHow do you think is message multiplexing currently connected with components?04:33
ronny2mehere, root components handle dispatch, subcomponents defer dispatch to root components04:34
mehereyeah, but the root component is just a fancy helper, if04:35
meherewe didn't use the root component, we'd04:35
meherehave to use a singleton, but then we couldn't have04:35
mehereseveral message busses runnign in parallel, which is a nice thing to have. So every04:36
meherecomponent needs a reference to "its" dispatcher.04:36
mehereEasy way to do this is to use the component tree root, because else04:36
mehereyou somehow have to get a reference to the "proper" dispatcher when you create the component.04:37
mehereActually, I once played with the though of removing the inheritance relationship between Manager and BaseComponent and04:39
meheremaintain the manager as something referenced by the component. While this is a bit clearer04:39
meherefrom a design point of view, it makes usage more inconvenient, because when04:40
meherefiring in a component, you couldn't simply write "" you'd have to04:40
meherewrite "".04:40
mehereThere are some more points that prevented me from really trying this. But conceptually, it would really be better.04:41
ronny2i see04:42
ronny2ok, i think thats my main problem with circuits04:42
ronny2the coupling between multiplexing, dispatch and handling is different from what i would kile to see and be able to use04:43
ronny2hmm, i think if it was possible to have explicitly expressed multiplexed groups, channels and namespaces wouldnt be needed to begin with04:44
mehereDon't you get what you call multiplexed groups by building different04:44
meherecomponent trees and (maybe) exchange04:45
mehereselected messages between them?04:45
ronny2what i call multiplexed group is one component tree04:45
mehereOK then what's the problem? Ig you have a reference to a component in the other tree, you can fire an event there.04:46
ronny2mehere, i cant run more than one tree in a thread for example04:46
ronny2(well, now it works with namespaces, but thats a bit different and actually strange)04:47
mehereOh you can. You just have to create your own main loop that calls "tick" for all your component trees.04:47
ronny2mehere, but is that sane?04:50
prologicor you could just run them all in threads taking advantage of python's cooperative multithreading04:51
prologicat one point we had actually integreated greenlet into circuits too - but decided against it to remain  pure python04:51
prologicand no having thousands of threads is not a problem thanks to mehere - the threads sleep idle if they have nothing to do04:52
prologicright mehere? :)04:52
mehereWhether that's sane I can tell you that only when I know your real use. Besides from following some theoretical concept, I have no idea where you are currently heading.04:52
ronny2prologic, having thousands of os level threads is practically insane04:52
prologicpython threads are _not_ os level threads04:52
prologictehy are not preemptive threads04:52
prologicit's all shared memory04:53
prologicno forking04:53
ronny2prologic, python threadsd are native threads that get stopped with the GIL04:53
prologicinitial expense at startup - sure04:53
mehereAnd even having a thousand OS level threads can be sane for certain server applications.04:53
mehereI think, ronny, that you are heading at something like "Erlang". But if you want to do Erlang, then do Erlang.04:54
mehereThey have an execution model that can be thought of as thousands04:55
mehereof threads but is implemented in sch a way that you don't really need them. But this is really very low level built in stuff.04:55
ronny2erlang has m:n threading04:55
prologicI guess if we re-added (maybe optionally) greenlet to circuits you could do thousands04:55
prologicand start every actor as a greenlet04:56
ronny2i think we are no longer talking about the same things04:56
mehereYes, but this would be a different framework. IMHO this is not what circuits is aiming at.04:56
mehereMaybe have a look at
ronny2i did, it was kinda broken04:57
mehereBut they have it as focus...04:58
OssoI am still missing the reason to have multiple object graphs04:58
mehereMe too04:58
prologicme three04:58
ronny2i want to start the same thing in a different context/configurations04:59
mehereWithout running it concurrently?04:59
prologicI think if you want Actor, do what mehere suggested. Use the code I ported for you, and write a new event loop that ticks over every actor04:59
ronny2mehere, of curse concurrent05:00
Ossoyou can use channels to have multiple configurations exactly like our TCPServers are doing05:00
mehereThen build your two object trees and call tree.start() on each of them.05:00
prologicThere are comments in this example that show exactly how you do that (What Osso just said)05:01
mehereOK, admittedly, if you create a complete component hierarchy, a nuisance is that you have to forward the channel name to all the components that you create (as you do in Bot). Having an additional namespace could make things easier if you say that every component automatically uses the namespace of its parent when inserted into the tree (can explicitly be changed afterwards). But I'm not sure if complicating the API (end the dispatch05:08
mehereer) with namespaces is really worth that benefit.05:08
ronny2i think we wont reach a compromise or common conclusion there05:09
mehere(But I have thought about that in the past, because I practically never use components with their default channel value (unless in very small examples).)05:09
prologic-but- as long as you're always subclassing Actor05:09
prologiceach new instance will always ahve the same channel05:09
prologicmehere, yeah same05:10
prologicI'm always separating components with their own "channel"05:10
prologicfor example in kdb05:11
mehereYes, but if ronny wants two similar object graph with (only) different configurations, he won't use different differently subclassed actors for each.05:11
prologicthere is the client channel and bot channel05:11
prologicno, which is why to accommodate his needs we need to think about namespaces with components inheriting the namespace of their parent05:12
prologicbut hmmm05:12
prologicis this beneficial to all, and what about channel(s) then?05:12
Ossoit's quite easy to have a component that inherits the component it is registered to channel05:13
Ossothen you would not have to pass the channel around05:13
prologicthat is true05:13
mehereIn order to not break the API we could add a keyword argument to .register "inheritChannel=false" and see where this leads us. If register is called with inheritChannel=True, the component would have its channel adjusted.05:16
prologicOsso, like so?05:16
OssoI was thinking that at first but then I thought05:16
prologicnot a bad idea05:16
Ossoif it's a property05:16
prologicI think I quite like mehere's idea05:16
ronny2hmm, im not sure i like where all this is going05:17
Ossoif we want to handle the case where it is changed05:17
Ossothough I am not sure why you would change the channel05:17
mehereI have several TCPServers in my application and of course, each component subtree for handling reads/writes needs its own channel.05:18
prologicmehere, yeah I wouldn't mind a kwarg like that05:19
prologicby convenient05:19
mehereBut of course, its not much different from passing the channel to the constructor (before registering), so its not really something that we *need*05:21
mehereAnd it arises the question of subtrees. Would the channel be forwarded to all components? Maybe it produces more problems than it solves ;-)05:22
ronny2this is something that would need some actual tests to see what the edges are05:23
ronny2i'll continue my experiment05:26
prologicwell I know if we change how the internal message bus works in any way05:37
prologicthings will break :)05:37
prologicexisting apps and what not05:37
ronny2prologic, yes, thats a problem thats __tricky__ to account for05:45
ronny2remdins me - where is that irc bot you use to relay bb messages to the chat?05:46
prologicit ships with some mercurial hook scripts that use xmlrpc to communicate with the bot05:48
prologicwhich then relays to irc05:48
ronny2prologic, that sounds like it cant be integrated with bitbucket web hooks05:50
ronny2at least not by just configuring05:51
ronny2back in a hour05:51
prologicno not exactly05:54
prologicit was written before bitbucket's time05:54
prologichowever you could easily adapt the plugin to suit05:54
prologickdb also has a builtin web server which you could build a handler that listen for bitbucket posts05:54
prologicif you wait a few days05:56
prologicI'll like get this done myself05:56
prologicsince is no more05:56
*** ronny_2 has joined #circuits07:06
*** ronny2 has quit IRC07:10
*** Osso has quit IRC07:45
*** Osso has joined #circuits09:18
*** Osso has quit IRC09:29
*** ronny_2 has quit IRC10:25
*** ronny has joined #circuits14:39
ronnyprologic, the basic design of juggler is simple - all non-db components of the system just listen to db changes and react on them14:41
ronnythats split in roguhtly inbox, that deals with incoming new orders, the management bits dealing with creating tasks and sheduling them14:42
ronnyand finally the worker, that claims tasks and executes them14:42
ronnythe backend bits pretty much work already, including build axis14:42
prologicwhat else is left to do then?14:42
ronnycomplexity for bits, ui, more use cases14:43
ronnywell, and user management :P14:43
prologicyou've already done all the interested bits then14:43
prologicoh well14:43
ronnywell, yeah, that was the bits my thesis was on14:43
ronnyi managed to get it pretty simple and straightforward14:44
ronnymost bits are short functions, the only thigns that are bigger are processes and dealing with them14:44
prologicso hence the investment into it :)14:44
prologicbrb - shower then work time14:44
*** ronny has quit IRC16:37
*** ronny has joined #circuits21:47
*** ronny has quit IRC21:47
*** ronny has joined #circuits21:47
prologicfinally set myself up a blog21:56
ronnyi see22:00
ronnyprologic, i noticed something, for specifying events there is no good syntax in python22:07
prologichow do you mean?22:07
ronnywhen trying to spec out messages and replies for a protocol, it seems its impossible22:07
prologicI don't see how22:08
prologicwe use an Event class as our base class for all events22:08
prologicwe subclass for documentation purposes mostly22:08
ronnyprologic, yes, it gives no real context tho, just event types22:08
prologicand sometimes to place restrictions on what knid of data goes into an event22:08
prologicwell I disagree22:08
ronnyprologic, what im missing is something like structural types in fp22:08
prologicwe actually have context with our events22:08
ronny(for the definition language)22:08
prologicbecause we built them in22:08
prologicyou know ...22:09
prologicit really sounds like you need to write your own programming langauge :)22:09
prologicI've started one called mio22:09
prologicand I have plans to implement Actor based concurrency22:09
ronnyi'd like to avoid that, last time i tried it sucked worse than anything else :P22:09
prologicwith a multi-state vm22:09
ronnyi hope on top of rpython?22:09
prologicwell not sure yet22:10
prologicwe'll see22:10
prologicso far the host language is Python itself22:10
prologicI haven't built a compiler or vm yet22:10
ronnyi see22:10
prologicjust the lexer, parser and evaluator22:10
prologicand runtime22:10
ronnyi strongly suggest rpython and doing a bytecode compiler then :P22:10
prologicyeah I will consider it22:10
prologicI get a jit for free too right?22:11
prologicanyway check it out22:11
prologicit all works and all :)22:11
ronnyprologic, and a gc22:11
prologicand it's all unit tests22:11
prologic2.6 though22:11
prologicI hadn't known/learned tox at the time22:11
ronnywhat is that multi state vm thing?22:12
prologicwell22:12 implements such a thing22:12
prologicand as I understand it22:12
prologicit's a bit like erlang22:12
prologicwhere the vm tries to use all the cores on the machine22:13
prologicIo implements coroutines and multi-state vm22:13
prologicso if you have 4 cores I think it actually started 4 os threads22:13
prologicI think22:13
prologicI actually haven't found any formal def for multi-sate vms22:13
ronnyas far as i read it there, multi state means you can run independent vm's in the same process22:13
prologicI guess circuits is multi-state too :)22:14
prologicwould you be interested in something like mio at all?22:15
prologicmessage passing oo (prototype) langauge22:15
prologicI want to build a compiler to bytecode and vm next22:15
prologicand then start thinking about also adding in first-class async support22:16
ronnyprologic, if you have an actor model why would you need async?22:16
prologicis this actually true?22:18
prologicif you implement actor you don't need any other form of concurrency?22:18
ronnyprologic, there is no blocking, all you get is new messages22:21
ronnyseems like i can only build my experiment on python3,22:26
ronny(nested statemachines for protocol users by using generators and yield from)22:27
prologicyour statement is incorrect22:45
prologicI/O would still block22:45
prologic_unless_ every actor were running in it's own thread or process22:45
prologicactor models I've seen have either a threaded executor or process executor22:45
prologicFor example all socket and file I/O operations on POSIX systems are blocking calls22:46
prologicunless you do async22:46
prologicor thread their calls22:46
ronnyprologic, actors are inherently parallel22:47
ronnyprologic, its part of the model, they run concurrently22:47
prologicyes exactly22:47
prologicevery actor has to be run concurrently22:47
ronnyalso you dont have blocking io with, you get messages for io22:47
prologicusing an M:N style approach like Erlang does would be ideal22:48
prologicumm well22:48 would block22:48
prologicbut because the actor in being run in paralelle22:48
ronnyprologic, in an actor model you dont really have that22:48
prologicthat doesn't matter22:48
ronnybecause a socket would be an actore you send messages to mkae it reply22:48
prologicthere is one thing I don't like about Actor model though22:49
prologicas a general concept22:49
prologicnothing against it's concurrency model22:49
prologicI don't think it would be very convenient22:49
prologicyou'd have to have many many actors just to implement a simple tcp server22:50
prologicbecause actors only handle one message22:50
ronnyactors can handle different messages22:50
ronnyprologic, think of actors as "objects"22:50
prologicI haven't seen a practical example of actors handling different types of messages yet22:51
ronnybecause in the traditional original oop an object does behave like an actor22:51
prologicthis is why I like IO and why I started writing mio22:51
prologicmessage passing22:51
prologicoo (but single inheritence)22:51
prologicand traits22:51
prologicI've implemented all this in mio so far22:52
prologicI still want to implement Actot on top of circuits22:53
prologicjust to prove to you it can be done22:53
prologiccomponents + message passing22:53
prologicis all you need to model most things22:53
prologicI think :)22:53
ronnyprologic, i like thinking of actors as statemachines22:54
ronnywhenever they get a message they transition state to decide how to handle the next message and create messages in that transition22:55
ronnyi just realized that an aweful lot of things are possible with just a basic source/sink protocol22:59
prologicwhen I first started out writing circuits23:00
prologicand before it was Python I wrote a prototype in Java23:00
prologicfor uni you see23:00
prologicit was more of an Actor model back then23:01
prologicbut think23:01
prologicAnd like you say23:01
prologicmessage comes in23:01
prologicit realizes a state change23:01
prologicand a message comes out23:01
prologicunfortunately when I started writing this in Python it didn't quite work as well as I had hoped23:01
prologicprobably due to Python's crappy multithreading support23:02
prologicso the performance sucked23:02
prologicso although circuits is pretty close23:02
prologicit's not perfect because of performance constraints23:02
prologicin an ideal world all components would run concurrently23:03
prologicand then you have Actor23:03
prologicIn the original design23:04
prologicComponents has inputs and outputs23:04
ronnyprologic, yes, but as faras im concerned its enough if the state-transition on message receiving does not block23:04
prologicand Components registered with other components had a specific interface23:05
prologicand they had to be compatible in order to register23:05
prologicFor example:23:05
prologica TCPServer Component could only be registered with another Component that listened to read, connect and close events23:05
ronnyprologic, i would go as far as only have it do the connect23:12
ronnyprologic, on the other hand, what if you consider a TcpServer a source of connections?23:13
prologicwell this is true23:13
ronnyand you just tell it a sink to send those connections to23:13
ronnyand aconnection is a source/sink of bytes23:13
prologicbut remember what I was saying earlier23:13
prologicthe original design was supposed to be more actor like23:13
prologicbut performance characteristics of Python prevented that23:14
prologicI believe you'll discover the same issues youreslf if you keep going down this path :)23:14
ronnyprologic, i wont have threads or green threads per actor23:14
prologicthere are pros and cons to components/actors that react to one thing only or multiple things23:14
ronnyinstead my actors are rellay just state machins, they get inputs, and while doing trainsition they generate outputs23:15
prologicand how will you achieve a high level of concurrency?]23:15
ronnyprologic, a loop? concurrent != parallel23:16
prologicwell hmm23:16
ronnyafter all all my actors can do is a non-blocking transition23:16
ronnythats always quick23:16
prologicI think we're mixing terminology here23:16
ronnyhmm, possible23:17
prologicconcurrent means to occur at the same time23:18
prologicso far your actors are not concurrent if you are just going to do a loop23:18
prologicif I'm not mistaken concurrent and parallel are synonymous23:19
ronnyprologic, do your computer programs on a single cpu machine run concurrent or parallel?23:19
prologicasynchronous means to not be synchronized23:19
prologicwhile synchronous is synonymous with serial23:20
prologicprogram(s) plural?23:20
ronnyyes plural23:20
prologicOn a single cpu/core computer23:21
prologicthey are neither23:21
prologicthey are time sliced and scheduled23:21
prologicthey appear to run concurrently23:21
prologicbut they in fact do not23:21
prologicon a multi-core/multi-cpu computer23:21
prologicyes they can run concurrently or in parallel23:21
ronnyis there any pragmatic difference at what level that timeslicing is implemented?23:22
ronnyfrom my pov there is no practical difference between having threats and having a loop23:23
ronnythe effect can be the same23:23
prologicthis is in fact very true23:24
prologic-however- as I've said23:24
prologicthis will cause you some performance issues23:24
prologicyou need to think about spawning multiple processes23:24
prologicyou will reach a concurrency limit23:24
prologicI'm not sure what it will be23:25
prologicbut you'll hit one nonetheless23:25
prologicthe reason circuits performs as well as it does23:25
prologicis because everything is async23:25
prologicand we cache everything23:25
ronnyi think we are in the terminology missmatch trap23:25
prologicso lookups are probably O(log n)23:25
prologicit's hot here23:26
prologicand I'm beering23:26
prologicso for that I apologize :)23:26
ronnyprologic, my system has all lookups O(1)23:26
prologicwith the added overhead of more actors involved to play the story23:27
prologicbut that's okay23:27
prologicit's a trade off23:27
prologickeep going with action23:27
prologicI want to see this23:27
ronnyi think it'll be fairly reasonable23:27
ronnyand the model will play very well with pypy stm23:28
prologicand let me know when you have a simple benchmark23:28
prologicyeah your statement about circuits not working on pypy because of the stm was incorrect23:28
prologiccircuits won't have a problem with that23:28
prologicand already passes all tests on pypy (with the exception of some bugs in pypy's I/O)23:28
ronnyprologic, do you have log of that statement, i think there is a context missmatch between what both of us understand about it23:29
prologicthere is a log23:30
prologicbut it doesn't matter :)23:30
prologicall good :)23:30
prologicplease lurk about here and keep me informed on your experiment with action23:30
prologicI'm very interested to see the results23:31
prologicno znc? :)23:31
prologicyou once brought this up too - decorators23:32
ronnyno bnc atm23:32
prologicor a functional way to do async (functional programming)23:32
prologicwe (or I) would still like to do that with circuits23:32
prologicto reduce the barrier to entry23:32
prologicI have no idea how to design such an API23:32
prologicnor what it would look like23:32
ronnyi'll know more about my experiments with action23:33
prologicideally I'd like to avoid doing what gevent and others have done (monkey patching)23:33
ronnyprologic, then it needs a complete replica of stdlib functionality23:38
prologicwith identical matching API(s) ?23:51
prologiceg: sockets, file, etc?23:52
ronnyprologic, yes, kind of23:52
ronnyprologic, so its an avoid thing i think23:52

Generated by 2.11.0 by Marius Gedminas - find it at!