Man, such a burst of activity on Kamaelia. Did it get coverage somewhere? :-)
BTW: Working on the 1.0 of Dendrite still (Axon for D). I was doing really well until some smart ass mentioned that it seemed cool, but did it work on multi-core systems. Like a fool I mused aloud that a flow-based programming system should work pretty transparently multicore. Hahahaha! (You should read that and imagine one of those Hollywood shots where they show the guys face laughing maniacally, then cut to the same laugh but outside his house, then over the city, then the world :-) So for good measure I decided to write a batched, non-locking, intercore FIFO and refactor the whole damn thing (again!). It's a good exercise, but it really cuts into my Left 4 De^h^h^h^h^h^h^h^h^h piano practice time. The funny part is I snagged the algorithm from some goofs over at Homeland Security who use it for snooping on their neighbors. Good news is my FIFO is approaching around 50 M messages a sec across the core/thread divide. Considering that the message might be the handle to a buffer or object and the effective transfer rate could be much higher. Now the re-factor on Dendrite has created the following set of Handlers, one-per actual core / thread: core: Detects multi-core / NUMA topology and creates a core object for every other physical core. It then creates the other handlers for the current core and mostly gets out of the way. io: io event loop that dispatches io events and virtual processor assertions. the dendrite co-routine scheduler and the lua engine are virtual processors. when nothing is asserted, dendrite goes to sleep (like I should be doing). sched: flow-based component creator and scheduler. still simple round-robin. postoffice: mailbox creator, link manager and messaging core. handles local and inter-core messages. tracker: pub/sub observer registration and transmission. components and handlers can register to listen to some part of the event tree. That about covers it. I have a few support components to boot the thing up. Namely a Console, CLI and Commander component. They pretty much do what you would expect them to do. Console creates edited line messages and sends them out. CLI takes the messages and passes them through the Lua command engine. The Lua engine determines if it's a script or not. If it's not, it creates a command object and sends it out. If it is, it runs it on the Lua virtual processor. Commander (cmd) takes command objects, executes them and manages the undo stack. The Command is then routed to the proper handler for execution. Pretty much cut and dried command/memento pattern there. The GUI menu commands will be routed through the same mechanism. I'm so buried in this stuff I hope to pop out of the sub-task stack and come back to the real reason I built it -- evolutionary AI simulation and experimentation. ...and my employer expects me to work on his stuff too. don't they understand I'm building SkyNet? How insensitive! As you can see, I'm getting punch drunk sleepy. Have a good night all. I imagine our friends in the UK are just having tea and running off to work (if they're not on holiday or something). l8rz eris On Tue, Aug 10, 2010 at 10:09 PM, Gloria W <strang...@comcast.net> wrote: > On 08/10/2010 10:38 PM, Michael Sparks wrote: > >> [giant snip] >> > Many many thank yous. I understood everything you posted, and it is very > close to what I had in mind to write, only cleaner :) It is great to be back > here. I spent the afternoon reading code comments, and it felt like > attending a well organized, fantastic course. The analogy with the shell > operations strikes me as brilliant every time I see it. > > With this really fascinating startup project I am working on, I also have > the added complexity of having weighted values which may determine which > component is executed based on probabilities. It would be wonderful to have > a third type of topology, to accompany the PAR and SEQ, called WGT or PROB, > or something, which will run the component with the highest weighted value. > I know, I could write it myself, but it would be awesome to just have it all > :) > > Finally, I've been doing a fair amount of time related work using kamaelia >> recently, and I'm very much of the opinion that using time.sleep inside a >> threaded component is by far and away the most simple thing to do. >> >> Hope that all helps, >> > The timer solution makes sense. I wrote timer code which looks almost > exactly like Matt's timer class. I pass it through a series of components, > where one happens to be a threadedcomponent, and it breaks. This solution is > fool-proof. > > Matt: Please try this with your code, self.link() it to a chain of > components where one is threaded, or run the entire chain with a > scheduler.run.runThreads() call, and let me know what you see. My code is > very very similar to yours and fails after the timer is fired. I cannot > cancel the timer, I cannot control it at all, as if I have lost control of > the thread. A thread inside a thread is just craziness. :) > > You both rock. Never stop. > Gloria > > > > -- > You received this message because you are subscribed to the Google Groups > "kamaelia" group. > To post to this group, send email to kamae...@googlegroups.com. > To unsubscribe from this group, send email to > kamaelia+unsubscr...@googlegroups.com<kamaelia%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/kamaelia?hl=en. > > -- You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamae...@googlegroups.com. To unsubscribe from this group, send email to kamaelia+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en.
