Re: [kamaelia-list] Dropping Legacy Python Support?
I'm also using 2.7+ everywhere I've got Kamaelia based code running. -- | Matt Hammond | Senior Research Engineer, BBC R&D, Centre House, London | http://www.bbc.co.uk/rd/ On 24 Oct 2013, at 13:07, Michael wrote: > Hi, > > > For various reasons - primarily because I needed it - we didn't use some > "new" features of python - because I still had machines kicking about running > some very old versions of python - which for very boring reasons weren't > upgraded. > > Dropping them though and deciding that kamaelia will only support python 2.7 > from now on would have a number of fringe benefits from a maintenance > perspective. Sooner or later I'll write myself a (or find a decent) > replacement for Kamaelia which uses better syntactic sugar/etc, and I'll > probably want to reuse kamaelia code then. (It all works after all, but could > be nicer :) > > Anyway, I suspect the answer is "no", but asking anyway, is anyone using > anything older than python 2.7 these days? (I know I haven't for a long > while, but worth asking the q). > > I'm not going to get around to changing things for a long while to come yet > being realistic, but at least asking the question now means that's one things > less to worry about. > > Going to 2.7 also means 3.x changes are an awful lot simpler too. > > Regards, > > > Michael > > -- > You received this message because you are subscribed to the Google Groups > "kamaelia" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to kamaelia+unsubscr...@googlegroups.com. > To post to this group, send email to kamaelia@googlegroups.com. > Visit this group at http://groups.google.com/group/kamaelia. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "kamaelia" group. To unsubscribe from this group and stop receiving emails from it, send an email to kamaelia+unsubscr...@googlegroups.com. To post to this group, send email to kamaelia@googlegroups.com. Visit this group at http://groups.google.com/group/kamaelia. For more options, visit https://groups.google.com/groups/opt_out.
Re: [kamaelia-list] Threaded component message handling
Nice. If you aren't rejigging inboxes and outboxes or linkages on the fly at runtime, then I think you do stand a good chance that that kind of design will work reliably. The code that implements linkages and boxes (realsink etc) was not design to be thread safe on its own; though it is possible that it might be given certain operations (e.g. sending messages by one thread while another changes a linkage). There will be some interesting determinism issues though - it could be conceivable that you could have a threaded component that unlinks an inbox only to find messages are still arriving in it (but then does that matter?) Other one to watch out for would be size limited inboxes and the blocking semantics. regards Matt -- | Matt Hammond | Senior Research Engineer, BBC R&D, Centre House, London | http://www.bbc.co.uk/rd/ On 16 Oct 2013, at 13:53, Jim Easterbrook wrote: > I've been experimenting with Axon's threaded components. Currently incoming > messages are delivered to the wrapper, which forwards them to the thread at > its next scheduler slot. I've written a "threadedsink" class to replace the > "realsink" class used when creating an inbox. It's based on Queue.Queue - the > append method puts a message on the queue and wakes up the thread directly, > without the wrapper component getting involved. > > Similarly, the threaded component's "send" method can check to see if the > receiving inbox's sink is a "threadedsink" object, and if so append the > outgoing message directly. Otherwise the usual threaded component out queue > is used. > > These two changes give me much better performance with pipelines of threaded > components. Messages flow from one component to the next without the > scheduler having to do anything. > > Note that I haven't given much thought to what happens if links are made or > unmade while messages are flowing. That's something I try and avoid doing. > (Turn the water off before disconnecting the hose.) > -- > Jim Easterbrook > Senior Research Engineer > > BBC Research & Development South Lab > BBC Centre House > 56 Wood Lane > London W12 7SB > > Phone: +44 303 040 9705 > Mobile: +44 7590 307002 > FAX:+44 20 8811 8815 > > -- > You received this message because you are subscribed to the Google Groups > "kamaelia" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to kamaelia+unsubscr...@googlegroups.com. > To post to this group, send email to kamaelia@googlegroups.com. > Visit this group at http://groups.google.com/group/kamaelia. > For more options, visit https://groups.google.com/groups/opt_out. > > __ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > __ -- You received this message because you are subscribed to the Google Groups "kamaelia" group. To unsubscribe from this group and stop receiving emails from it, send an email to kamaelia+unsubscr...@googlegroups.com. To post to this group, send email to kamaelia@googlegroups.com. Visit this group at http://groups.google.com/group/kamaelia. For more options, visit https://groups.google.com/groups/opt_out.
Re: [kamaelia-list] Spelling mistake in DVB Descriptors
Well spotted. Have corrected trunk (r7221) cheers Matt On Thu, 16 Dec 2010 15:26:51 -, Terence wrote: While having a look at the DVB descriptors (http://www.kamaelia.org/ Components/pydoc/Kamaelia.Support.DVB.Descriptors.html) I found the following mistake : 0x81 : "Magazine/Report/Domentary" I think the last word should be documentary :) Regards -- | Matt Hammond | Research Engineer, BBC R&D, Centre House, London | http://www.bbc.co.uk/rd/ -- 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.
Re: [kamaelia-list] Backplane notifications
Quick thought from me:
Another way to do it might be to take the same kind of approach as the
carousel component - by having a 'publishondemand' component that you
provide with a factory function for creating your system when it is
required to service subscribers. When the last subscriber unsubscribes,
the publishondemand component would send a shutdown message to the
component it created.
I guess, from the developer using it, it would look like this:
def dataSrcFactory():
return MyComponentThatPublishesToTheBackplane()
Backplane("MYBACKPLANE")
PublishOnDemand("MyBackPlane", dataSrcFactory)
This would, likely, require modifications to Backplane to implement it.
Matt
> On 02/12/2010 15:29, Michael Sparks wrote:
>>
>> What sort of interface would you want ? Something like this?
>>
>> Pipeline(
>> Backplane("MYBACKPLANE"),
>> MyComponentThatGetsNotificationsWhenNewClients(),
>> )
>>
>> That in itself leads rather naturally to:
>>
>> Pipeline(
>> SendNotificationsToBackplane(),
>> Backplane("MYBACKPLANE"),
>> MyComponentThatGetsNotificationsWhenNewClients(),
>> )
>>
>> Or:
>>
>> Pipeline(
>> Backplane("MYBACKPLANE"),
>> BackplaneMonitor(),
>> circular = True,
>> )
>>
>> (Which would enable BackplaneMonitor to shutdown the Backplane)
>
> I hadn't really thought about notifications being an outbox of the
> backplane component itself. That could fit my use, as there is just one
> component that wants to receive notifications of subscriber changes -
> the pipeline that's publishing to the backplane.
>
> I was (loosely) thinking more of a special subscriber that doesn't
> receive data published to the backplane, but receives 'events' relating
> to the backplane. Having created a backplane, any component in the
> system could create one of these event subscribers. This starts to look
> like a backplane itself though. Would we want notifications of new event
> subscribers?
>
>> You could have a notification of:
>> * New subscriber
>> * New publisher
>> * Back to zero subscribers
>> * Back to zero publishers
>>
>> (Publishers are actually harder, but should be doable safely now given
>> the existence of the STM code)
>>
>> I'm not sure what notifications you might want to send to the
>> backplane itself though either. (suggestions/comments welcome)
>
> Really I just need 'subscriber change' with a parameter telling me how
> many subscribers there are now.
> --
> Jim Easterbrook
> Senior Research Engineer
>
> BBC Research & Development South Lab
> BBC Centre House
> 56 Wood Lane
> London W12 7SB
>
> Phone: +44 303 040 9705
> Mobile: +44 7590 307002
> FAX:+44 20 8811 8815
>
> --
> 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.
>
>
--
| Matt Hammond
|
| [anything you like unless it bounces] 'at' matthammond 'dot' org
--
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.
Re: [kamaelia-list] Answered one of my questions
I tried this again, and found it hadn't changed much in the past couple of years. It still needs a scrolling mechanism, iirc arrow keys do this? a way to limit the amount of nested detail, The nesting in Kamaelia is not strict containment. A component created by another component is free to connect to other components not created by the same 'parent'. For example, a TCP Client or server will create ConnectedSocketAdaptor components to handle the individual socket connections. These might appear nested, but they use teh CAT service to instantiate a globally shared Selector component which they all *directly* communicate with. Similarly, when you use the backplane publish-subscribe model, the publish and subscribe components are locating the backplane component and directly forming linkages with it. Some thoughts: maybe if a visualiser has a concept of having 'focus' directed at one or more components, then detail could be limited by restricting the 'distance' from that component that is visible. Eg. if you have a pipeline: a->b->c->d->e and you are focused on 'c' with a distance of "1 linkage" then you will only see b->c->d. Passthrough linkages ought to be treated as a chain of distinct linkages. Could also limit detail by treating inboxes and outboxes named with a preceeding '_' (eg '_csa') as a special case: unless the component that owns those boxes has focus, then nothing linked to those boxes is visible. a clearer way to see what is flashing when data moves from one component to the next, For that to be useful, I guess what's actually needed is a kind of logger and stepping playback mechanism, or break-point stepping mode? The extra fun complication here is that, with the current design, the introspection component is part of the system being introspected. So if data flow is logged, then the data generated by the logging should also be logged, and then the data that generates should be logged too ... you get the idea :-) Not sure how to deal with that. and a cleanup mechanism when components go away. Components should disappear when they shut down. If they don't disappear then that usually implies they're still running. This might be because they weren't sent a shutdownMicroprocess or producerFinished message to their "control" inbox. I am going to try and find a volunteer to help with this task. It would be incredibly useful to also have a running audit trail of what messages were sent/received by components, in another window, while the visualizer is running. This combined with a cleaner visual will be so powerful. That would be extremely useful and also quite cool to see working :-) Matt -- | Matt Hammond | Research Engineer, BBC R&D, Centre House, London | http://www.bbc.co.uk/rd/ -- 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.
Re: [kamaelia-list] Answered one of my questions
On Tue, 28 Sep 2010 00:21:43 +0100, Gloria W wrote: So scratch the first question. My other question still stands: How do I write data back to the TCP socket client? Kamaelia doesn't directly give me access to a connected socket descriptor. I could dig for it and expose it, but there must be a better way. Hi Gloria, the clue in in the description of FastRestartSingleServer's inboxes and outboxes: from Kamaelia.Internet.SingleServer import FastRestartSingleServer FastRestartSingleServer.Outboxes['outbox'] 'Any data received from the first connection accepted is sent to this outbox' FastRestartSingleServer.Inboxes['inbox'] 'Data received on this inbox is sent to the first client who connects' So to send data back to the client, send it to the 'inbox' inbox of the FastRestartSingleServer. Like many other components, it is providing a service. Don't make assumptions about descriptors, etc ... see how the component describes how it should be interacted with. You can also try: from Kamaelia.Internet import SingleServer help(SingleServer) Matt -- | Matt Hammond | Research Engineer, BBC R&D, Centre House, London | http://www.bbc.co.uk/rd/ -- 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.
Re: [kamaelia-list] Kamaelia.Chassis.Carousel and threaded components
On Wed, 11 Aug 2010 10:54:56 +0100, Jim Easterbrook wrote: I'm just thinking about a possible use for a Carousel. Suppose I have a pipeline of three components, A, B & C. I'd like B to be able to change dynamically, so make it a Carousel that loads one of several possible children. Those children are threaded components. As I understand it, when I want to change component B, the Carousel tells its child to terminate, then waits for it to do so, then unlinks its inboxes and outboxes, then creates the new child. If the child is a threaded component, its inbox is a queue which may still have messages in it when the child terminates. Those messages are then lost and won't find their way through the pipeline. Would it be better if the carousel cut off the child's inboxes before telling it to terminate? The child could then process anything remaining in its inbox queue before terminating. We'd still need a way to suspend component A while switching to the new component B though. Ideally no messages leaving A would be lost, all would find their way to C via one or other of B's children. Interesting point. Sounds plausible. Wouldn't help with the situation where the child terminates of its own volition - rather than in response to having been sent a shutdown/producer-finished message - since the carousel would have no way of knowing that it has to disconnect the inbox until it is too late. Matt -- | Matt Hammond | Research Engineer, BBC R&D, Centre House, London | http://www.bbc.co.uk/rd/ -- 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.
Re: [kamaelia-list] Nifty uses and features.
On Wed, 11 Aug 2010 11:18:09 +0100, Sylvain Hellegouarch wrote: On Wed, Aug 11, 2010 at 12:16 PM, Matt Hammond wrote: The attraction to me if the simplicity of use and the lower overheads compared to using a threaded component to send timing signalling. With the understanding of blocking the whole Python process (hence the scheduler) by not using a thread for the timer. It doesn't block the scheduler. It uses the python Timer class, which uses a thread. When the timer times-out, the component is re-awoken, if paused. Damn, that'll teach in reading the code more properly. I assumed it was a time.sleep(...). Sorry for that. No problem. You are right though that a mixin is not the right solution. My view is that the downside of what I've done compared to your approach is that it is effectively a modification to Axon, rather than building the functionality on top of the existing features. Matt -- | Matt Hammond | Research Engineer, BBC R&D, Centre House, London | http://www.bbc.co.uk/rd/ -- 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.
Re: [kamaelia-list] Nifty uses and features.
The attraction to me if the simplicity of use and the lower overheads compared to using a threaded component to send timing signalling. With the understanding of blocking the whole Python process (hence the scheduler) by not using a thread for the timer. It doesn't block the scheduler. It uses the python Timer class, which uses a thread. When the timer times-out, the component is re-awoken, if paused. Matt -- | Matt Hammond | Research Engineer, BBC R&D, Centre House, London | http://www.bbc.co.uk/rd/ -- 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.
Re: [kamaelia-list] Nifty uses and features.
On Wed, 11 Aug 2010 10:18:50 +0100, Sylvain Hellegouarch wrote: I'm usually not a massive fans of mixins as I find they recreate what is the core nature of Axon: composability. If I was using my threaded monitor above, I'd have something like: Pipeline(ThreadedMonitor(), TestComponent(),PassItOn(),ConsoleEchoer()).run() Where TestComponent wouldn't be a mixing anymore. To me this avoids hiding the fact the TestComponent is a timer. Instead it states that it requires a timer which is a different view. Its a mix-in because I was lazy and didn't want to branch Axon and modify the Component class directly :-) The attraction to me if the simplicity of use and the lower overheads compared to using a threaded component to send timing signalling. Matt -- | Matt Hammond | Research Engineer, BBC R&D, Centre House, London | http://www.bbc.co.uk/rd/ -- 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.
Re: [kamaelia-list] Re: threadedcomponent's main function not starting
+1 former On Wed, 11 Aug 2010 10:26:24 +0100, Michael Sparks wrote: On Aug 11, 4:40 am, Joesan wrote: Hi Matt & Michael, The yield thing was the exact problem. Thank you! Guess we missed it in the documentation. Cool. 2 thoughts: * Put an error handler in to catch the case that main() is a generator and tell the user what they're doing wrong. * Put an error handler in to catch the case that main() is a generator and make it do what the user expects. I'm tempted to do the latter, but my instinct is for the former. Michael. -- | Matt Hammond | Research Engineer, BBC R&D, Centre House, London | http://www.bbc.co.uk/rd/ -- 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.
Re: [kamaelia-list] Dynamic Graphline components?
Hi all, Yes, forgot to mention that that TimerMixin experiment would break if mixed-in with a threadedcomponent - in which situation using time.sleep() is far simpler and less heavyweight. *if* it were to become core functionality of Kamaelia, then I'd envisage it being added to Component; and similar methods providing equivalent functionality being added to threadedcomponent. Have just done another little experiment and made the mix-in work for both components and threadedcomponents. http://code.google.com/p/kamaelia/source/browse/trunk/Sketches/MH/TimerMixIn2.py It is not very clean - since the mix-in now has explicit knowledge about what it is mixing into. But as mentioned before - the time.sleep() method is probably better for threadedcomponents; plus if this were included in Kamaelia, it would be better placed in core Axon, where some changes to Component and ThreadedComponent would be made to allow it to be coded more cleanly. regards Matt -- | Matt Hammond | Research Engineer, BBC R&D, Centre House, London | http://www.bbc.co.uk/rd/ -- 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.
Re: [kamaelia-list] Dynamic Graphline components?
On Wed, 11 Aug 2010 05:09:37 +0100, Gloria W wrote: 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. Yes :-) 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. Yes, forgot to mention that that TimerMixin experiment would break if mixed-in with a threadedcomponent - in which situation using time.sleep() is far simpler and less heavyweight. 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. :) I'm not sure I fully understand what you are suggesting. I've tried putting it in a pipeline with a threadedcomponent, and that seems to work fine: http://code.google.com/p/kamaelia/source/browse/trunk/Sketches/MH/TimerMixIn.py On the other hand, maybe you are making the point that this mixin doesn't work when mixed-in with threadedcomponent? Which I 100% agree with. *if* it were to become core functionality of Kamaelia, then I'd envisage it being added to Component; and similar methods providing equivalent functionality being added to threadedcomponent. -- | Matt Hammond | Research Engineer, BBC R&D, Centre House, London | http://www.bbc.co.uk/rd/ -- 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.
Re: [kamaelia-list] threadedcomponent's main function not starting
Hi Joesan, Very difficult to make suggestions unless we can actually see a sample of the code in question. Please post a sample of your code - particularly of the threadedcomponent - if you can. Hazarding a guess: have you remembered to *not* use yield statements inside the main() method of the threadedcomponent? Matt > We started working with kamaelia recently at work and we're having > trouble right now working with threadedcomponents. We have several > regular components which are added as child components to one big > "master" component. We now need to add in a another component who > will run it's main function in a separate thread, so we created a new > threadedcomponent, and added that as another child component. The new > component gets created just fine but for some reason it seems it's > main function is never actually called. I can't figure out why since > aside from being a "threadedcomponent" instead of a regular one, > everything else is pretty much the same. We even tried explicitly > calling activate() for the threaded component (though this wasn't > necessary with any of the other components). > > Any ideas on why this isn't working? > > PS - This may not have any effect on anything, but we're not using > graphline right now and are calling link several times to actually > link together the mailboxes of various components. Could this keep > the threadedcomponent's main from starting? > > -- > 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. > > -- | Matt Hammond | | [anything you like unless it bounces] 'at' matthammond 'dot' org -- 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.
Re: [kamaelia-list] Nifty uses and features.
>> An unrelated question: What is the best way to set a timer inside of a >> component? I am using the threaded Timer, but it is problematic inside >> of >> the component, it only fires once and cannot be restarted without error. >> It >> looks like it's underlying thread handling is botching up the top level >> thread processing. > You might want to look at an old code of mine which allowed to reset a > timer: > > http://trac.defuze.org/browser/tags/headstock-0.3.3/headstock/lib/monitor.py > > Still a threaded component mind you. Gloria, Sylvain: you both got me thinking. Have just committed a little experiment: http://code.google.com/p/kamaelia/source/browse/trunk/Sketches/MH/TimerMixIn.py Would be interested to hear what you think. Feel free to try it out. The bottom half of the file is an example usage. Matt -- | Matt Hammond | | [anything you like unless it bounces] 'at' matthammond 'dot' org -- 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.
Re: [kamaelia-list] Nifty uses and features.
I am having a similar epiphany now that I found the coordinating
assistance tracker (under Axon). This is precisely what I need: a
dynamic way to register and de-register available components that aren't
linked to each other. This can also be used to handle global data.
Nifty! The documentation in the code is superb.
You might also find these interesting: backplanes, and the 'experimental'
RegisterService/ToService/Subscribe components. They also use the
coordinating-assistant-tracker to enable some common types of task.
http://www.kamaelia.org/Components/pydoc/Kamaelia.Util.Backplane.html
As the webpage says: "Backplanes provide a way to 'publish' data under a
name, enabling other parts of the system to 'subscribe' to it on the fly,
without having to know about the actual component(s) the data is coming
from." Examples there are hopefully self explanatory. There's also a
currently-broken 'cookbook' entry on the subject.
http://www.kamaelia.org/Components/pydoc/Kamaelia.Experimental.Services.html
This 'experimental' set of components makes it easier to use the
Coordinating Assistant Tracker. The docs are less clear atm, so here's a
quick explanation. Although they are labelled as experimental, they
haven't in practice changed for quite some time. The docs are slightly out
of date - "SubscribeTo" should be "Subscribe", and "ConnectTo" should be
"ToService"
Take any component and pass it to RegisterService(); then you can connect
to its inbox using the ToService component, eg:
RegisterService("MyService", ComponentWaitingForInput(), "inbox")
Pipeline(
ComponentOutputtingStuff(),
ToService("MyService")
)
In addition, suppose you write a component that is able to dynamically
connect to the inboxes of other components and send them data they need.
If you arrange that it is controlled by sending it messages of the form:
[ "ADD", app_specific_field, (component, inbox_name) ]
[ "REMOVE", app_specific_field, (component, inbox_name) ]
Then if you register this component using RegisterService() then you can
use the "Subscribe" component to easily connect to that service:
RegisterService("MyService", MyServiceProvidingComponent, "inbox")
Pipeline(
Subscribe("MyService", "notifications only please"),
MyComponentThatWantsToReceiveNotifications()
)
The app-specific-field is a means to allow you to pass parameters when
subscribing to the service - eg. a list of the things you are interested
in receiving from the component (for 'add') or a list of things you no
longer wish to receive (for 'remove')
The DVB DemuxerService component is an example that acts like this:
http://www.kamaelia.org/Components/pydoc/Kamaelia.Device.DVB.DemuxerService.html
There's an example of its use here:
http://www.kamaelia.org/Components/pydoc/Kamaelia.Device.DVB.Receiver.html
--
| Matt Hammond
| Research Engineer, BBC R&D, Centre House, London
| http://www.bbc.co.uk/rd/
--
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.
Re: [kamaelia-list] Dynamic Graphline components?
On Mon, 09 Aug 2010 08:24:37 +0100, Matt Hammond wrote: *Michael: the relevant cookbook page appears to be borked atm: http://www.kamaelia.org/Cookbook.html Oops - that should be: http://www.kamaelia.org/Cookbook.html.html/Carousels.html Matt -- | Matt Hammond | Research Engineer, BBC R&D, Centre House, London | http://www.bbc.co.uk/rd/ -- 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.
Re: [kamaelia-list] Dynamic Graphline components?
Sounds like you want to write a custom component that creates child components, links them up, unlinks them, creates new ones etc. How to create ... and destroy links: http://www.kamaelia.org/Docs/Axon/Axon.Component.html#20 How to create a child component, and how to detect when it has finished, and then remove it: http://www.kamaelia.org/Docs/Axon/Axon.Component.html#21 If you want these actions to happen in response to particular messages coming from one of the child components, then to do that your component should create an inbox, in the usual way, and link it up to the appropriate outbox of the component(s) that will be sending those messages. If what you are after doing is swapping out a single component and replacing it with a new one, then the Carousel component might help you: http://www.kamaelia.org/Components/pydoc/Kamaelia.Chassis.Carousel.html When you create a carousel, you provide it with a function for creating new child components. When a message is sent to the "next" inbox of the Carousel, your function is called, and is passed the message as its argument. The new component that your function returns is activated as a child of the component and wired up such that the inbox and outbox of the Carousel component go straight to the inbox and outbox of the new child. If there was already a child, then it is sent a message to its control inbox to tell it to shut down, then its linkages are removed, before activating and linking in the new child. The Carousel also has a 'requestNext' outbox that sends out a message whenever the child terminates. You can therefore use this to trigger the creation of a new component. *Michael: the relevant cookbook page appears to be borked atm: http://www.kamaelia.org/Cookbook.html Hope this helps Matt On Mon, 09 Aug 2010 04:32:33 +0100, Gloria W wrote: Hi Michael et al, I am pleased to say that I finally have a freelance contract where I can make great use of Kamaelia. I am really happy about transitioning my personal Kamaelia work from toy to tool. This is exciting. The license change helps greatly. I have a situation where I want to use a Graphline, but the components are dynamic. They can become invalid, and new ones can be required, in realtime. Am I forced to add them as subcomponents? Is using __setattr__ in this capacity considered a kludge? How do I add and remove linkages? Should I destroy and recreate the Graphline object each time, instead of all of this manipulation? If so, is this slow/inefficient? Many thank yous, and I'm really happy to be back here. Gloria -- | Matt Hammond | Research Engineer, BBC R&D, Centre House, London | http://www.bbc.co.uk/rd/ -- 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.
[kamaelia-list] Re: Tuning
I'm not sure I'm afraid - that code is old, so might no longer be fully
compatible with the dvb3 bindings that kamaelia now uses.
My suggestion would be to take the source code for DVB_Multiplex:
http://code.google.com/p/kamaelia/source/browse/trunk/Code/Python/Kamaelia/Kamaelia.Device/DVB/Core.py
... and take your own copy to modify. Then locate the "tune_dvb" function
and add to it the code needed to set the SEC voltage. See if it works.
regards
Matt
On Sat, 21 Nov 2009 00:10:26 -, luca72 wrote:
> hello i have make this:
>
> import dvb3
> scheda = dvb3.frontend.Frontend(0)
> parametri = dvb3.frontend.QPSKParameters(frequency=11977,
> inversion=2 , symbol_rate=27500, fec_inner=9)
> demuxer = dvb3.dmx.Demux(0, blocking = 0)
> pid = 1296
> demuxer.set_pes_filter( pid,
> dvb3.dmx.DMX_IN_FRONTEND,
> dvb3.dmx.DMX_OUT_TS_TAP,
> dvb3.dmx.DMX_PES_OTHER,
> dvb3.dmx.DMX_IMMEDIATE_START )
>
> pol = 'v'
> if pol =='v':
> scheda.set_voltage(13)
>
> segnal = scheda.read_signal_strength()
> print 'segnale = ' + str(segnal)
> status = scheda.read_status()
> print 'status = ' + str(status)
> ber_= scheda.read_ber()
> print 'ber = ' +str(ber_)
> snr_ = scheda.read_snr()
> print'snr = ' + str(snr_)
> front_end = scheda.get_frontend()
> print'frontend = ' +str(front_end)
>
> I have no error i have the ber = 0
> the signal that go from 0 to max 2500
>
> Do you have any idea.
> Idon' find the commandfor close the dvb3.frontend.Frontend(0) can you
> hel me?
>
> Thanks
>
> Luca
>
> On 20 Nov, 11:17, "Matt Hammond" wrote:
>> Maybe better to look at a layer closer to the python. See:
>>
>>
>> http://code.google.com/p/kamaelia/source/browse/trunk/Code/Python/Bin...
>>
>> Teh QPSKParameters class is filled from the 'frequency' parameter and
>> the 'feparams' you provide. You therefore need to specify:
>>
>> inversion
>> symbol_rate
>> fec_inner
>>
>> in the feparams dict you are creating.
>>
>> Ignore my earlier mesasge where I incorrectly assumed you were trying
>> to tune to the BBC freesat service! Use the symbol rate and frequency
>> that you have been using. Hein suggests the FEC you need is 3/4. You
>> can probably set inversion to auto - or at worst just try all three
>> options.
>>
>> The old code Michael attached to an earlier email seems to indicate
>> that to set the polarisation, other stuff needs doing - to do with SEC
>> voltages (I've no idea what they are). You could try taking you own
>> copy of the DVB_Multiplex.py and adding the code to set the
>> polarisation?
>>
>> Matt
>>
>>
>>
>> On Fri, 20 Nov 2009 10:00:24 -, luca72 wrote:
>> > Thanks
>> > I try to explain what i need to do using python.
>>
>> > The base data are:
>> > DVB-S
>> > Frequency 11977
>> > pid 1296 Sky Italy ECM pid
>> > Polarization Horizontal
>> > symbol rate 27500
>>
>> > If i understand right at first i have to setup the front end is it
>> > correct?
>> > Locking dvb-3 api for dvb-s frontend i have the follow params:
>>
>> > struct dvb_frontend_parameters {
>> > uint32_t frequency; /* (absolute) frequency in Hz for
>> > QAM/OFDM */
>> > /* intermediate frequency in kHz for
>> > QPSK */
>> > fe_spectral_inversion_t inversion;
>> > union {
>> > struct dvb_qpsk_parameters qpsk;
>> > struct dvb_qam_parameters qam;
>> > struct dvb_ofdm_parameters ofdm;
>> > } u;
>> > };
>>
>> > For satellite QPSK frontends you have to use the QPSKParameters member
>> > defined by
>>
>> > struct dvb_qpsk_parameters {
>> > uint32_tsymbol_rate; /* symbol rate in Symbols per
>> > second */
>> > fe_code_rate_t fec_inner;/* forward error correction (see
>> > above) */
>> > };
>>
>> > freq = 119.77
>> > feparams = {"symbol_rate" : 27500,
>> > }
>>
>> > I stop just here i heve made no more code because i have the error,
>> > so i don't continue.
>>
>> > Now my idea is ,today when i'm at home i wr
Re: [kamaelia-list] Re: Tuning
ntil I see the full file you're >> *currently* >> editting and the *current* sourcefile, I have no chance of >> reconstructing >> exactly what's happening. >> >> In order to allow me to help you, I simply need that information. >> >> Once again, regarding this: >> >> > PS:I think that i'm your nightmare (sorry) >> >> Please let me put your mind at rest - someone (anyone) taking the time >> to >> report back and try using code that hasn't been tested in the scenario >> you're >> using it, is not a nightmare, it's closer to a dream scenario - since >> it's >> useful feedback. >> >> At present I think, that the current code is not configuring the >> satellite >> frontend before passing in the fe.params. It looks like with DVB-T & -C >> you >> can more or less "just use it", whereas with DVB-S the setting of >> horizontal >> matters. This quite possibly requires a change to our code as well as >> yours, >> hence me asking for information which you may feel repetitious, however >> what >> I'm simply doing is trying to see precisely what's changing in the >> system as >> a whole :-) >> >> Thanks for persevering! :-) >> >> Regards, >> >> Michael. >> --http://yeoldeclue.com/bloghttp://twitter.com/kamaelianhttp://www.kamaelia.org/Home > > -- > > 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=. > > -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ -- 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=.
Re: [kamaelia-list] Re: Tuning
> The file frontend.pyx could not be opened. > The debugged program raised the exception unhandled IOError > "(22, 'Invalid argument')" > File: frontend.pyx, Line: 364 I think these two errors are becuase the wrong set of parameters are being specified. See my email from about half an hour ago. Those frequency, and symbol rate values may be correct, but the software displaying them may not have scaled the values to the correct units - eg. is it specifying symbols per second or kilo-symbols per second or mega-symbols per second? Matt > On 19 Nov, 23:29, Michael Sparks wrote: >> On Thursday 19 November 2009 21:41:15 luca72 wrote: >> >> > i make a little change but i get another error: >> >> Could you post the whole file into a pastebin ? >> >> eghttp://pastebin.com/ >> >> Along with the full trace back? >> >> One thing that does look wrong to me is given this: >> >> * Frequency 11977 >> * pid 1296 >> * Horizontal >> * 27500 >> >> Shouldn't translate as: >> freq = 119.77 >> .. >> DVB_Multiplex(freq, [0x1296] >> >> That should be: >> freq = 11977 >> ... >> DVB_Multiplex(freq, [1296], ... >> >> The numbers look higher than DVB-T because DVB-S does work at a higher >> frequency. >> >> It will be easier to help with a copy of the full file & traceback in a >> pastebin though. >> >> Regards, >> >> Michael. >> --http://yeoldeclue.com/bloghttp://twitter.com/kamaelianhttp://www.kamaelia.org/Home > > -- > > 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=. > > > -- | Matt Hammond | | [anything you like unless it bounces] 'at' matthammond 'dot' org -- 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=.
Re: [kamaelia-list] Re: Tuning
Just found this link:
http://www.bbc.co.uk/reception/info/sat_frequencies.shtml
Confirms that the FEC value should be FEC_5_6 - leaving only the three
inversion options to try.
Also noticed that the symbol rate that page specifies is different to the
one you're using: 22 Msymbol/s, not 27.5 Ksymbol/s - might be worth trying
that too once you're no longer getting error messages about 'invalid
paramters'.
Note the 'service ids' listed on that page are not the same thing as the
PIDs on which the channels are broadcast.
So, revised suggestion:
feparams = {
"symbol_rate" : 22*100,
"inversion" : dvb3.frontend.INVERSION_AUTO,
"fec_inner" : dvb3.frontend.FEC_5_6
}
> I'm not hugely familiar with DVB-S so anything I'm about to suggest might
> be wrong(!) ...
>
> If I remember right, DVB-S is QPSK modulation based.
>
> Looking at:
>
> http://code.google.com/p/kamaelia/source/browse/trunk/Code/Python/Bindings/python-dvb3/dvb3/cfrontend.pxd#169
>
> ...I reckon the feparams you need to specify are therefore:
> "frequency"
> "inversion"
> "symbol_rate"
> "fec_inner"
>
> The Tuner will know what kind of device (DVB-S, DVB-C, DVB-T) it is using
> so will treat your feparams accordingly.
>
> 27500 sounds like the symbol rate. I've no idea about the other
> parameters. You can try the 'auto' flags for the other two. If you're
> lucky, your dvb-s card might support that:
> INVERSION_AUTO
> FEC_AUTO
>
> eg:
> feparams = {
> "symbol_rate" : 27500,
> "inversion" : dvb3.frontend.INVERSION_AUTO,
> "fec_inner" : dvb3.frontend.FEC_AUTO
> }
>
>
>
> Matt
>
>> i make a little change but i get another error:
>> from Kamaelia.Device.DVB.Core import DVB_Multiplex
>> from Kamaelia.Chassis.Pipeline import Pipeline
>> from Kamaelia.File.Writing import SimpleFileWriter
>>
>> import dvb3
>>
>>
>> freq = 119.77
>> feparams = {"symbol_rate" : 27500,
>>
>>
>> }
>>
>> and i get the following error
>>
>> The file frontend.pyx could not be opened.
>>
>> and after i gat :
>> The debugged program raised the exception unhandled IOError
>> "(22, 'Invalid argument')"
>> File: frontend.pyx, Line: 364
>>
>> Can you hel me?
>>
>> Thanks
>>
>> Luca
>>
>> On 19 Nov, 22:07, luca72 wrote:
>>> Thanks Michael for your help, but at my first test i get problems
>>> usual:
>>> so i explain my test
>>> i have this data i have to log ECM and store it in file:
>>>
>>> Frequency 11977
>>> pid 1296
>>> Horizzontal
>>> 27500
>>>
>>> So i start just to write :
>>>
>>> from Kamaelia.Device.DVB.Core import DVB_Multiplex
>>> from Kamaelia.Chassis.Pipeline import Pipeline
>>> from Kamaelia.File.Writing import SimpleFileWriter
>>>
>>> import dvb3
>>>
>>> freq = 119.77
>>> feparams = {
>>> "constellation" : dvb3.frontend.QPSK,
>>>
>>> }
>>>
>>> Pipeline(
>>> DVB_Multiplex(freq, [0x1296],feparams), # BBC Multiplex 1,
>>> whole transport stream
>>> SimpleFileWriter("prova"),
>>> ).run()
>>>
>>> I get the error :
>>> The debugged program raised the exception unhandled TypeError
>>> "'constellation' is an invalid keyword argument for this function"
>>> File: /usr/local/lib/python2.6/dist-packages/Kamaelia/Device/DVB/
>>> Core.py, Line: 210
>>>
>>> Thanks Luca
>>>
>>> On 19 Nov, 10:20, Michael Sparks wrote:
>>>
>>> > On Thursday 19 November 2009 07:25:56 luca72 wrote:
>>>
>>> > > Thanks for the linkd page, in the example there are dvb-t example
>>> but
>>> > > i con also use for dvb-s making some change is it correct?
>>>
>>> > You'll be pleased to hear that the dvb bindings were first used with
>>> a
>>> DVB-S
>>> > card. Most current testing has been with DVB-T, but they should still
>>> work
>>> > with DVB-S. (We've made changes to support DVB-C as well when a patch
>>> came
>>> > our way BTW :)
>>>
>>> > Michael
>>> > --http://yeoldeclue.com/bloghttp://twitter.com/kamaelia
Re: [kamaelia-list] Re: Tuning
I'm not hugely familiar with DVB-S so anything I'm about to suggest might
be wrong(!) ...
If I remember right, DVB-S is QPSK modulation based.
Looking at:
http://code.google.com/p/kamaelia/source/browse/trunk/Code/Python/Bindings/python-dvb3/dvb3/cfrontend.pxd#169
...I reckon the feparams you need to specify are therefore:
"frequency"
"inversion"
"symbol_rate"
"fec_inner"
The Tuner will know what kind of device (DVB-S, DVB-C, DVB-T) it is using
so will treat your feparams accordingly.
27500 sounds like the symbol rate. I've no idea about the other
parameters. You can try the 'auto' flags for the other two. If you're
lucky, your dvb-s card might support that:
INVERSION_AUTO
FEC_AUTO
eg:
feparams = {
"symbol_rate" : 27500,
"inversion" : dvb3.frontend.INVERSION_AUTO,
"fec_inner" : dvb3.frontend.FEC_AUTO
}
Matt
> i make a little change but i get another error:
> from Kamaelia.Device.DVB.Core import DVB_Multiplex
> from Kamaelia.Chassis.Pipeline import Pipeline
> from Kamaelia.File.Writing import SimpleFileWriter
>
> import dvb3
>
>
> freq = 119.77
> feparams = {"symbol_rate" : 27500,
>
>
> }
>
> and i get the following error
>
> The file frontend.pyx could not be opened.
>
> and after i gat :
> The debugged program raised the exception unhandled IOError
> "(22, 'Invalid argument')"
> File: frontend.pyx, Line: 364
>
> Can you hel me?
>
> Thanks
>
> Luca
>
> On 19 Nov, 22:07, luca72 wrote:
>> Thanks Michael for your help, but at my first test i get problems
>> usual:
>> so i explain my test
>> i have this data i have to log ECM and store it in file:
>>
>> Frequency 11977
>> pid 1296
>> Horizzontal
>> 27500
>>
>> So i start just to write :
>>
>> from Kamaelia.Device.DVB.Core import DVB_Multiplex
>> from Kamaelia.Chassis.Pipeline import Pipeline
>> from Kamaelia.File.Writing import SimpleFileWriter
>>
>> import dvb3
>>
>> freq = 119.77
>> feparams = {
>> "constellation" : dvb3.frontend.QPSK,
>>
>> }
>>
>> Pipeline(
>> DVB_Multiplex(freq, [0x1296],feparams), # BBC Multiplex 1,
>> whole transport stream
>> SimpleFileWriter("prova"),
>> ).run()
>>
>> I get the error :
>> The debugged program raised the exception unhandled TypeError
>> "'constellation' is an invalid keyword argument for this function"
>> File: /usr/local/lib/python2.6/dist-packages/Kamaelia/Device/DVB/
>> Core.py, Line: 210
>>
>> Thanks Luca
>>
>> On 19 Nov, 10:20, Michael Sparks wrote:
>>
>> > On Thursday 19 November 2009 07:25:56 luca72 wrote:
>>
>> > > Thanks for the linkd page, in the example there are dvb-t example
>> but
>> > > i con also use for dvb-s making some change is it correct?
>>
>> > You'll be pleased to hear that the dvb bindings were first used with a
>> DVB-S
>> > card. Most current testing has been with DVB-T, but they should still
>> work
>> > with DVB-S. (We've made changes to support DVB-C as well when a patch
>> came
>> > our way BTW :)
>>
>> > Michael
>> > --http://yeoldeclue.com/bloghttp://twitter.com/kamaelianhttp://www.kama...
>
> --
>
> 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=.
>
>
>
--
| Matt Hammond
|
| [anything you like unless it bounces] 'at' matthammond 'dot' org
--
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=.
[kamaelia-list] Re: Axon.ThreadedComponent.threadedcomponent and internal queues
> On Thursday 08 October 2009 15:23:12 Matt Hammond wrote: >> """ >> >> > Deliveries to a given single inbox will be in-order. But I don't think >> > you can guarantee delivery is in order when considering, as a whole, a >> > sequence of messages sent to two or more inboxes. >> >> """ > > I completely missed that comment. Yes. Easily done ... and it seems I missed: > Incidentally, my plan is as I noted yesterday to do directly delivery - > but > isn't an immediate solution. (The Axon2 rewrite is starting down that > path) Sounds like an excellent plan :-) Matt -- | Matt Hammond | | [anything you like unless it bounces] 'at' matthammond 'dot' org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@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 -~--~~~~--~~--~--~---
[kamaelia-list] Re: Axon.ThreadedComponent.threadedcomponent and internal queues
If I understand correctly, what you point out is what I meant by:
"""
> Deliveries to a given single inbox will be in-order. But I don't think you
> can guarantee delivery is in order when considering, as a whole, a
> sequence of messages sent to two or more inboxes.
"""
But your example is probably a clearer way to express this.
My references to guaranteed in-order delivery was intended to refer to the
context of messages flowing through a single inbox-outbox linkage. Though
I don't think I stated this very explicitly. Apologies - that was likely
the victim of a last minute C+P job on the email and me not taking the
time to read the final result sufficiently carefully.
Matt
> On Thursday 08 October 2009 13:45:08 Matt Hammond wrote:
>> Yes, its
>> purpose when I coded it was to ensure queues are flushed.
>
> It does not guarantee in order delivery though, when you chain 2 threaded
> components together
>
> Specifically, given this sequence of messages being *logically* sent:
>
> ProducerThread
> ( 1, "outbox")
> ( 2, "outbox")
> ( 3, "outbox")
>
> ( 4, "outbox")
> ( 5, "outbox")
> ( 6, "outbox")
>
> ( 7, "outbox")
> ( 8, "outbox")
> ( producerFinished, "signal")
>
> Note that I've divided those into 3 chunks of messages.
> These get appended to outqueues in that order. Due to the way this
> loop...
>
> for box in self.outboxes:
>
> ... works this ensures that these will get sent to the actual outboxes as
> follows:
> ( 1, "outbox")
> ( 2, "outbox")
> ( 3, "outbox")
>
> ( 4, "outbox")
> ( 5, "outbox")
> ( 6, "outbox")
>
> ( 7, "outbox")
> ( 8, "outbox")
> ( producerFinished, "signal")
>
> This arrives in the inboxes of the recipient:
> ( 1, "inbox")
> ( 2, "inbox")
> ( 3, "inbox")
>
> ( 4, "inbox")
> ( 5, "inbox")
> ( 6, "inbox")
>
> ( 7, "inbox")
> ( 8, "inbox")
> ( producerFinished, "control")
>
> Now we hit the problem point. We hit this loop:
> for box in self.inboxes:
>
> This causes this delivery order - control box, then inbox. This comes in
> fits
> and starts - due to timeslice interleaving:
>{ no control messages }
> ( 1, "inbox")
> ( 2, "inbox")
> ( 3, "inbox")
>
>{ no control messages }
> ( 4, "inbox")
> ( 5, "inbox")
> ( 6, "inbox")
>
> ( producerFinished, "control")
> ( 7, "inbox")
> ( 8, "inbox")
>
> The consumer then exits early. This is because order is not guaranteed in
> this
> way by the implementation. It's a rather subtle bug, one only really
> visible
> if you are connecting two threads together.
>
>
> Michael.
> --
> http://yeoldeclue.com/blog
> http://twitter.com/kamaelian
> http://www.kamaelia.org/Home
>
> >
>
--
| Matt Hammond
|
| [anything you like unless it bounces] 'at' matthammond 'dot' org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"kamaelia" group.
To post to this group, send email to kamaelia@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
-~--~~~~--~~--~--~---
[kamaelia-list] Re: Axon.ThreadedComponent.threadedcomponent and internal queues
> Threaded components are more interesting, because of the internal inqueues > and outqueues you've identified. > > Deliveries to a given single inbox will be in-order. But I don't think you > can guarantee delivery is in order when considering, as a whole, a > sequence of messages sent to two or more inboxes. Maybe a solution to this would be an optimisation of ThreadedComponent so that somehow it arranges for inbox deliveries to be made immediately into the inqueues, rather than waiting for _localmain to collect them and push them into the queues? Matt -- | Matt Hammond | | [anything you like unless it bounces] 'at' matthammond 'dot' org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@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 -~--~~~~--~~--~--~---
[kamaelia-list] Re: Axon.ThreadedComponent.threadedcomponent and internal queues
My hurried two cents:
Ignoring threaded component behaviour for a moment. Axon delivers messages
to the destination component immediately. So if you send a message(s) to
the "inbox" inbox of a component, then a message to the "control" inbox of
the same component; then if that component notices the message in its
"control" inbox, then it is guaranteed that the messages sent, earlier, to
its "inbox" inbox will already be there. Ie. (in the current
implementation at least) message delivery is guaranteed in-order.
Threaded components are more interesting, because of the internal inqueues
and outqueues you've identified.
Deliveries to a given single inbox will be in-order. But I don't think you
can guarantee delivery is in order when considering, as a whole, a
sequence of messages sent to two or more inboxes.
> A simple solution I've found is to add a sync() statement to the producer:
>
> class ProducerT(Axon.ThreadedComponent.threadedcomponent):
> def main(self):
> for i in range(1000):
> self.send(i, 'outbox')
> self.sync()
> self.send(producerFinished(), 'signal')
>
> After doing this I get 1000 messages every time.
>
> Now my questions. Is this a "proper" use of the sync() method? Its
> documentation doesn't say anything about flushing internal queues - is
> that what it actually does? Is there a better way of doing what I'm
> after that's guaranteed to work in all circumstances?
This is good as far as I'm concerned :-) The sync, behaviourally, achieves
a very similar effect to shoving a yield statement in a normal component.
- it ensures that other components get a slice of execution time before
the producerFinished() signal is sent. Tho it might not always be
necessary (see below).
It does cause queues to be flushed. And the documentation (I wrote) is
poor in that it does not explicitly state what actually happens (or what
is guaranteed from the perspective of a component writer). Yes, its
purpose when I coded it was to ensure queues are flushed.
The sync() call essentially does a synchronous RPC from the thread back to
the main thread of execution, so yes, in principle all messages pending at
inboxes ought to be pushed into the inqueues going to the thread.
However, even inserting self.sync() calls doesn't eliminate all race
conditions: a fresh message could arrive at the "control" inbox just after
sync() returns, and be delivered first (before any other messages pending
at the "inbox" inbox) meaning the thread might still miss them. Hmm.
I guess something like this might be a hacky inelegant work around (not
tested):
class MyConsumer(Axon.ThreadedComponent.threadedcomponent):
def main(self):
self.count=0
while 1:
dealWithInbox()
if self.dataReady("control"):
msg = self.recv('control')
if isinstance(msg, producerFinished):
shutdownMsg = msg
break
else:
self.pause()
yield 1
self.sync() # force final deliveries
dealWithInbox() # clear out any leftovers
self.send(shutdownMsg, "signal")
def dealWithInbox(self):
msg = self.recv('inbox')
self.count += 1
Matt
--
| Matt Hammond
|
| [anything you like unless it bounces] 'at' matthammond 'dot' org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"kamaelia" group.
To post to this group, send email to kamaelia@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
-~--~~~~--~~--~--~---
[kamaelia-list] Re: Autoloading Components based on Imports
> So some questions arise: >1. Good idea or not? >2. Really? Could be viewed as bad mojo & messing about one step too > far. >3. If OK, should it be static? ie the list of what gets imported and >handles what dealt with by a table lookup in Kamaelia/__init__.py ? >4. Or should it go "OK, I was imported here, I'll rummage around in all > my >subdirectories, in this overall order" >5. Do 3, then 4, if the name wasn't found in 3. >6. The other way round ? >7. Do we allow extra search paths for the case of 4 ? (think sys.path > for >modules) >8. How about allowing extra lookup tables to be added in the case of 3? >9. lots more possibilities. I can see it would be much less verbose and that is a *good* thing! If nothing else, from writing examples in documentation, where brevity is highly desireable, adding all those import statements can be tedious and ugly. I would also worry about the situation where two or more components share the same (leaf) name. Eg: Kamaelia.Chassis.Pipeline Kamaelia.Experimental.Chassis.Pipeline There are also other components which, although they do not clash now, look likely to later, eg: Kamaelia.Audio.Codec.PyMedia.Decoder.Decoder I suppose I'm asking, will someone's code break X months/years later when more components are added to teh repository with the same name? This concern therefore makes me worry this could be a short term gain which causes future difficulties. But maybe this is still a good idea and the solution is to develop a stricter component naming policy? (and retrospectively rename existing components to fit it) Another perspective: If one of the problems this is trying to solve is disagreement over where a component should be located in the hierarchy; this could be solved by symlinking - ie. let the component be in both places in the hierarchy where it is believed to make sense. However, I guess this could end up being highly confusing! I can see it would make sense if you consider the hierarchy as a hierarchical classification scheme, rather than a packaging/encapulsation thing - eg. more like categories on Ebay than packages in java. -- | Matt Hammond | | [anything you like unless it bounces] 'at' matthammond 'dot' org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@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 -~--~~~~--~~--~--~---
[kamaelia-list] Re: Beginner question - shutting down a pipeline from within
I'm guessing that by saying "is no longer a component that can play
nicely" you mean that it wont' be shutdown-able through its control &
signal boxes:
The approach I'd personally take would be to manually wire up the
components in a graphline. I'd wire the inbox-outbox path pass through
just like for a Pipeline. I'd also do the same for the control-signal path
but instead of starting at component A and ending at D I'd start at C and
end at A.
What does this mean in practice:
EITHER: C shuts down. The shutdown message propagates to D, then to A then
to B then to the "signal" outbox of the graphline.
OR: A shutdown message arrives at the "control" inbox of the graphline.
This is routed to the "control" inbox of C. The shutdowns then propagate
to D, then to A then to B then to the "signal" outbox of the graphline.
def mySystem:
return Graphline(
A = ComponentA(),
B = ComponentB(),
C = ComponentC(),
D = ComponentD(),
linkages = {
# inbox-outbox path
("self","inbox") : ("A","inbox"),
("A","outbox") : ("B","inbox"),
("B","outbox") : ("C","inbox"),
("C","outbox") : ("D","inbox"),
("D","outbox") : ("self","outbox"),
# control-signal path
("self", "control") : ("C", "control"),
("C", "signal") : ("D", "control"),
("D", "signal") : ("A", "control"),
("A", "signal") : ("B", "control"),
("B", "signal") : ("self", "signal"),
})
mySystem().run()
I guess if this is a pattern you end up using often, and/or there are alot
more than 4 components in the pipeline, you could make a more generic
function that does this wiring. You could even use two Pipelines to save
the bother of having to wire up each link in the chain individually:
def mySystem2(firstSetOfComponents, secondSetOfComponents):
return Graphline(
FIRST = Pipeline(*firstSetOfComponents),
SECOND = Pipeline(*secondSetOfComponents),
linkages = {
# inbox-outbox path
("self","inbox") : ("FIRST","inbox"),
("FIRST","outbox") : ("SECOND","inbox"),
("SECOND","outbox") : ("self","outbox"),
# control-signal path
("self", "control") : ("SECOND", "control"),
("SECOND", "signal") : ("FIRST", "control"),
("FIRST", "signal") : ("self", "signal"),
})
mySystem2(
[
ComponentA(),
ComponentB(),
], [
ComponentC(),
ComponentD(),
]
).run()
mySystem().run()
Hope this helps.
Matt
>
> Apologies if I've missed something obvious in the documentation, but
> I'm having difficulty coming up with an elegant way of doing this:
>
> I have a pipeline of (say) four components A, B, C & D. The normal way
> to shut this down from outside is to send producerFinished to A's
> control inbox. This propagates down the line and all is well.
>
> As well as this I'd like one of the components (say C) to be able to
> decide that the pipeline's work is done and it should close down. I've
> been doing this by having C send producerFinished to its signal
> outbox, and (using Graphline) link D's signal outbox to A's control
> inbox. This is nasty, not least because my pipeline is no longer a
> component that can play nicely with other components in a larger
> system.
>
> Is there a better way to do this? All ideas welcome.
>
> Jim
>
> >
>
--
| Matt Hammond
|
| [anything you like unless it bounces] 'at' matthammond 'dot' org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"kamaelia" group.
To post to this group, send email to kamaelia@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
-~--~~~~--~~--~--~---
[kamaelia-list] Re: The tutorial went pretty well, I was told.
Hi Gloria, Congratulations - thats really good to hear! And glad you're sticking around :-) Are any video/audio/notes/slides from your talk? Matt > > Hi all, > I did the Kamaelia tutorial today at PyCon. I spent a lot of time > walking through existing examples. I also generated epydocs from the > code, and showed people the great unit tests and sample code, as well as > comments in the code. People seemed to have the same reaction as when I > first saw Kamaelia. The code is almost too simple, and you feel like you > really don't understand what's happening until you open the hood and > look inside. We looked inside, then popped back out, and everyone seemed > to enjoy it. We also used pdb to walk through code until the run() was > executed, and threads were kicked off. It was really useful. I hope some > of the attendees join this group. > Thanks for all of your help. I will be using Kamaelia for my own open > source project, so I will still be active on the list, and asking many > questions, I am sure. > Later, > Gloria > > > > -- | Matt Hammond | | [anything you like unless it bounces] 'at' matthammond 'dot' org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@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 -~--~~~~--~~--~--~---
[kamaelia-list] Re: Fortune cookie introspector
> Every introspective process suffers from these problems, so no biggie > for the time being. I think being able to make the display window > bigger, and scroll it, matters most right now. Check the '--help' command line option info, and try the arrow keys :-) Matt -- | Matt Hammond | | [anything you like unless it bounces] 'at' matthammond 'dot' org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@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 -~--~~~~--~~--~--~---
[kamaelia-list] Re: Fortune cookie introspector
> Oh, wow...that is so damned cool.
:-)
> It seems like these few lines give you introspection into any Kamaelia
> process:
>
> from Kamaelia.Util.Introspector import Introspector
> from Kamaelia.Visualisation.Axon.AxonVisualiserServer import
> AxonVisualiser
>
> # Start the introspector and connect to a local visualiser
> Pipeline(
> Introspector(),
> TCPClient("127.0.0.1", 1500),
> ).activate()
Yep :-)
> And clicking on nodes/connectors reports out to the console.
>
> This is so great. Wow.
There are some caveats and shortcomings that need to be borne in mind:
* scalability - the more complex the system, the more blobs and the
slower the visualisation gets - it can grind to a near halt pretty quick.
This is mainly due to the maths overhead on the physics engine dictating
the blobs movement. As it slows, it will start skipping frames, so you
may miss something if it is fleeting.
* no abstraction - you see *everything* - so you get to see just how many
additional components simple-server creates for its own use.
* heisenberg effect - you affect the system you are measuring. That
TCPClient the Introspector is using to get its data out to the visualiser
will be using network sockets, the Selector component (a component that
is shared between all components using TCP sockets - its basically a
wrapper around the unix select() call). Hence, also, the fact that the
introspector component itself will appear within the introspection.
Really glad you like it tho :-)
Matt
--
| Matt Hammond
|
| [anything you like unless it bounces] 'at' matthammond 'dot' org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"kamaelia" group.
To post to this group, send email to kamaelia@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
-~--~~~~--~~--~--~---
[kamaelia-list] Re: Fortune cookie introspector
> I am looking at this nifty code from the Examples dir: > http://pastebin.com/m72f62d06 > Can you tell me what the introspector is doing here? I can't see how it > is connected to the SimpleServer. > I see that the last Pipeline is just a client call, sent to the console. > But the purpose and value of the Introspector here is confusing. The Introspector is a bit of a special component - these days it is actually part of Axon (the core system that implements the whole Components, Inboxes, Outboxes, etc business): http://www.kamaelia.org/Docs/Axon/Axon.Introspector.html It is part of Axon because it rummages around inside the Axon scheduler (ie. introspects) to find out the state of the system (what components there are and how they are wired together). It sends this information out of its "outbox" outbox in the form of commands describing how to construct a topology of nodes and linkages that mirrors what it has introspected. Kamaelia contains some topology visualising components that understand these commands and can generate an animated graphical display using pygame. You should find an app in Kamaelia/Tools/AxonVisualiser.py that will accept these commands on a TCP socket ... hence putting the introspector in a pipeline with a TCPClient() - so it can connect to a running AxonVisualiser.py and send the data to it. It has nothing to do with the SimpleServer - because the idea is that the Introspector is something (nearly) completely separate in the system that is observing what is going on. The SimpleServer is part of the system under observation. Run up the AxonVisualiser: $> python AxonVisualiser.py --port=1500 Leave it running, then run the fortune cookie system. You'll see blobs appear. More info here: http://www.kamaelia.org/AxonVisualiser Matt -- | Matt Hammond | | [anything you like unless it bounces] 'at' matthammond 'dot' org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@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 -~--~~~~--~~--~--~---
[kamaelia-list] Re: Question re: default socket connections deep within Kamaelia
onent:
class SerialPortTransciever(component):
Graphline(
CHAT = ChatProtocol(),
TXRX = SerialPortTransciever(),
linkages = {
("CHAT", "oubox") : ("TXRX", "inbox"),
("TXRX", "oubox") : ("CHAT", "inbox"),
}
).run()
> Sorry if my questions are fuzzy. I am trying to stop thinking in twistd,
> where I had to do some very raw protocol handling in various spots of my
> interface.
> Because of my development history, I am so used to dealing with protocol
> directly that it took me a while to do this paradigm shift.
Its no problem. It is a rather different way to write code to what many
people are used to. I'm really glad you've stuck with it and kept asking
questions - rather than never asking anything and moving onto something
else!
cheers
Matt
--
| Matt Hammond
|
| [anything you like unless it bounces] 'at' matthammond 'dot' org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"kamaelia" group.
To post to this group, send email to kamaelia@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
-~--~~~~--~~--~--~---
[kamaelia-list] Re: Question re: default socket connections deep within Kamaelia
Hi Gloria, > And ServerCore seems to be two components linked together, while the > first example is a derivative component. I'm not sure what you mean by this. Can you explain? > I cannot see where an outbox is determined to default to stdout, like > the first example, or a remote console, like the second example. Where > in the stack is this presumed and defaulted? Neither example has any outbox that is "determined to default to stdout". The console output in the first example is generated by the 'print' statement(s) in it. The second example creates a new class derived from the ServerCore class. This new class uses the ChatClient function as its protocol. One of those pipelines will be created every time a client connects (because ServerCore calls the ChatClient function, which returns a new instance of that pipeline). This is then wired up to communicate with the client. This behaviour is described here: http://www.kamaelia.org/Components/pydoc/Kamaelia.Chassis.ConnectedServer.html Hopefully those docs should clear it up. In short, its not "presumed or defaulted" - its what the ServerCore component does. In case this is a cause of confusion, doing this: class ChatServer(ServerCore): protocol = ChatClient ChatServer(port=1501).run() ...achieves basically the same thing as doing this: ChatServer(protocol=ChatClient, port=1501).run() Matt -- | Matt Hammond | | [anything you like unless it bounces] 'at' matthammond 'dot' org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@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 -~--~~~~--~~--~--~---
[kamaelia-list] Re: Making self.pause() for generator components mirror self.pause() for threads components
> On Wednesday 04 March 2009 00:04:13 Matt Hammond wrote: >> The timeout feature is there, to my mind, because it provide a >> convenient >> way to provide basic timing facilities, very nearly for free (since the >> threading.Event() object it uses to pause has an optional timeout >> argument >> already built in) >> >> In my understanding, there is therefore no difference between >> self.pause() >> for generator based components and threaded components, except from the >> fact that the pause-ing will not happen in a generator based component >> until the next yield statement is reached. > > This second paragraph disagrees with the first. Apologies - you are correct - a lack of accuracy on my part! More precise 2nd stab: The possible things that may cause a threaded component to re-awaken, when paused, are the same as that for a generator based component (with the addition of the timeout, if specified) A threaded component will be awoken by box related activity (new messages arriving, send messages being collected by a recipient) just as a generator based component would be. Matt -- | Matt Hammond | | [anything you like unless it bounces] 'at' matthammond 'dot' org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@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 -~--~~~~--~~--~--~---
[kamaelia-list] Re: Making self.pause() for generator components mirror self.pause() for threads components
> The upshot is that pause() tells the scheduler "please don't call me again > unless there's a new message in an inbox OR a message is taken from an > outbox". ... OR if a child component terminates :-) > For threaded components it means the same thing. However, since a threaded > component can genuinely sleep, if it doesn't ever bother checking its > inboxes > for messages, it will sleep for ever. As a result, for threaded > components, > it adds an optional timeout argument to say "sleep for this long". Whilst > this was added for practicality reasons, it does mean that self.pause() > has a > different meaning for generator components from threaded ones. When a ThreadedComponent calls self.pause() to go to sleep, it will be woken by messages arriving at an inbox, or being taken from an outbox. See lines 483-504 and 541 in ThreadedComponent.py: http://code.google.com/p/kamaelia/source/browse/trunk/Code/Python/Axon/Axon/ThreadedComponent.py#483 http://code.google.com/p/kamaelia/source/browse/trunk/Code/Python/Axon/Axon/ThreadedComponent.py#541 The timeout feature is there, to my mind, because it provide a convenient way to provide basic timing facilities, very nearly for free (since the threading.Event() object it uses to pause has an optional timeout argument already built in) In my understanding, there is therefore no difference between self.pause() for generator based components and threaded components, except from the fact that the pause-ing will not happen in a generator based component until the next yield statement is reached. > Now there's two ways that self.pause(timeout=delay) could gain the same > meaning for generator components. One is to change the scheduler to become > time aware. The other is for it to wrap up a call to "PausingService" that > will awaken you after a minimum of delay has passed. > > Personally I prefer the latter, but this raises two issues: > * By changing the scheduler we change Axon/Kamaelia in a more > fundamental > way. Not necessarily the correct way. Certainly in a way that makes > it > harder to hack on and modify. > * The latter approach would mean that we're either using a component > *inside Axon* itself. This goes against Axon's spirit to an extent, > but >is the simpler, and probably more robust solution. > > I would also suggest that the return value of self.pause() be something > that > is yieldable. I like the idea of self.pause() returning something you have to yield - to my mind that sorts the potential confusion that can surround the way that the self.pause() doesn't take effect until the next yield statement. I agree that the latter approach feels simpler and possibly cleaner; but maybe at the expense of scope for performance optimisation (without later going back and working out how to change the scheduler). However, we don't seem to have that many applications where performance is that critical anyway. However, generalising a bit, what would be nice to add to the scheduler would be finer grained control over what can and cannot cause a component's generator to be woken from a paused state. For example, many components have no interest in being awoken when a message is taken from their outbox (because they do not support sending to size-limited destinations). If you could say something like (but not necessarily exactly like) this: yield self.pause(timeout=0.001) or this: yield self.pause(ignoreOutboxes=["outbox","signal"]) or this: yield self.pause(timeout=0.001, ignoreAllOutboxes=true) then, as a component writer, I'd find that a quite nice extra level of optimisation I could choose to incrementally add to my components. No idea how it should be implemented though. However I think I'm making the point that perhaps there's scope for a more general mechanism which *would* be appropriate to incorporate into the scheduler. My gut feeling is that whatever is returned by self.pause(...) would be some kind of object/function that the scheduler would call. This object/function contains the intelligence needed to enqueue some kind of timeout event, or to block/disable other sources of events. Matt -- | Matt Hammond | | [anything you like unless it bounces] 'at' matthammond 'dot' org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@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 -~--~~~~--~~--~--~---
[kamaelia-list] Re: Small mod to console example doesn't work?
ave more
>> questions and comments.
>> Thanks again for this.
>> Gloria
>>> On Mar 2, 8:36 pm, Gloria W wrote:
>>>
>>>> Matt, thanks for this response. It took me a while to get through it
>>>> and
>>>> make sure I understood each point. I appreciate it, comments are
>>>> below.
>>>>
>>>
>>> No problem.
>>>
>>> I've just realised another way to achieve the same effect that is
>>> probably simpler!
>>>
>>> There *is* a component that is all about getting things done in an
>>> order: the Seq component (The name is a homage to the OCCAM language):
>>>
>>> http://www.kamaelia.org/Components/pydoc/Kamaelia.Chassis.Seq.html
>>>
>>> With Seq, you provide a list of components. Seq goes through the list,
>>> starting with the first component. It activates it and wires up its
>>> inboxes and outboxes so that they're mapped to the Seq component's
>>> inboxes and outboxes (just like the Carousel does). When that
>>> component finishes, it then unwires it and moves onto the next in the
>>> list. It therefore effectively runs them *in sequence* one after the
>>> other.
>>>
>>> We've got two steps: displaying the initial message, then taking user
>>> input. Both steps need their output to be displayed. So we'll create a
>>> Seq componet, Pipeline'd into a console echoer:
>>>
>>> from Kamaelia.Chassis.Seq import Seq
>>>
>>> Pipeline(
>>> Seq( ... args to be determined! ... ),
>>> ConsoleEchoer()
>>> ).run()
>>>
>>> We can use a OneShot component (see
>>> http://www.kamaelia.org/Components/pydoc/Kamaelia.Util.OneShot.html
>>> ) to send that initial message, so that it gets sent to the
>>> ConsoleEchoer and displayed. OneShot, rather conveniently, then
>>> immediately terminates; so the Seq component will move onto the next
>>> component in its list. That next component can be the Pipeline of a
>>> ConsoleReader, sending its output into MyComponent.
>>>
>>> So what we have is:
>>>
>>> from Kamaelia.Chassis.Seq import Seq
>>> from Kamaelia.Util.OneShot import OneShot
>>>
>>> Pipeline(
>>> Seq(
>>> OneShot("initial message to be displayed"),
>>> Pipeline(
>>> ConsoleReader(),
>>> MyComponent()
>>> )
>>> ),
>>> ConsoleEchoer()
>>> ).run()
>>>
>>> In this case, MyComponent doesn't need to bother to send the initial
>>> message itself, as it did in the suggestion I previously made.
>>>
>>> So what happens here? Well, when the system starts running, initially
>>> the Seq component selects the first item in its list - the OneShot
>>> component. So, what actually ends up getting wired up is something
>>> like this:
>>>
>>> Pipeline(
>>> OneShot("initial message to be displayed"),
>>> ConsoleEchoer()
>>> )
>>>
>>> Its not actually exactly like that, because the OneShot is still
>>> contained within the Seq component - but because all the inboxes and
>>> outboxes are mapped to that of the Seq component, it is roughly
>>> equivalent.
>>>
>>> Then when the OneShot component has sent its message and terminated,
>>> the Seq component swaps it out and replaces it with the next thing in
>>> its list - the pipeline of a ConsoleReader and MyComponent. So the way
>>> the system is wired up suddenly switches to something akin to this:
>>>
>>> Pipeline(
>>> Pipeline(
>>> ConsoleReader(),
>>> MyComponent()
>>> ),
>>> ConsoleEchoer()
>>> )
>>>
>>> Again, the inner pipeline is, in reality, contained within the Seq
>>> component, but it behaves roughly like it is shown.
>>>
>>>
>>>
>>>
>>> Matt
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> >
>
>
> >
--
| Matt Hammond
| Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK
| http://www.bbc.co.uk/rd/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"kamaelia" group.
To post to this group, send email to kamaelia@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
-~--~~~~--~~--~--~---
[kamaelia-list] Re: Small mod to console example doesn't work?
"ready")
while not self.doShutdown():
if self.dataReady("inbox"):
data = self.recv("inbox")
# let's echo what we received...
self.send(data, 'outbox')
if not self.anyReady():
self.pause()
yield 1
Note the 'yield' statements - which give other components a chance to run
- giving the ConsoleEchoer a chance to display that initial message.
Remember that we don't control the precise order in which components
execute: if we sent the initial message and the ready message without a
yield in between, we might be unlucky, and the Carousel might get executed
first!
We cannot use a simple pipeline now, since we need to also wire up the
"ready" outbox of MyComponent to the Carousel's "next" inbox. A Pipeline
only wires up the standard "inbox" and "control" inboxes and "outbox" and
"signal" outboxes. So we'll use a Graphline instead, where we specify each
linkage explicitly:
from Kamaelia.Chassis.Carousel import Carousel
from Kamaelia.Chassis.Graphline import Graphline
Graphline(
READER = Carousel(makeConsoleReader),
MYCOMP = MyComponent(),
OUTPUT = ConsoleEchoer(),
linkages = {
# main flow of data:
("READER", "outbox") : ("MYCOMP", "inbox"),
("MYCOMP", "outbox") : ("OUTPUT", "inbox"),
# the 'ready' message:
("MYCOMP", "ready") : ("READER", "next"),
# the 'signal' and 'control' boxes used for shutdown:
("READER", "signal") : ("MYCOMP", "control"),
("MYCOMP", "signal") : ("OUTPUT", "control"),
}
).run()
So what should happen when this runs?
1) The components are created and wired up as shown above.
2) They all start executing.
2a) The Carousel and ConsoleEchoer only do stuff in response to messages
they receive, so they sit there waiting. Only MyComponent really starts
doing anything significant
3) MyComponent sends out its "initial message" out of its "outbox". The
ConsoleEchoer receives this and displays the message on the console
4) MyComponent sends a message out of its "ready" outbox, and it is
received at the "next" inbox of the Carousel.
4a) The Carousel uses the makeConsoleReader() function we wrote to create
a ConsoleReader component. It gets wired up so that it uses the outboxes
and inboxes of the Carousel.
4b) The ConsoleReader component also gets activated, and so its main()
method starts running. It therefore displays its prompt for user input
5) When the user enters input, the ConsoleReader sends out of its "outbox"
to the "inbox" of MyComponent.
Hmm, more long winded than I originally hoped this would be. Hope it helps
though.
Matt
--
| Matt Hammond
| Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK
| http://www.bbc.co.uk/rd/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"kamaelia" group.
To post to this group, send email to kamaelia@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
-~--~~~~--~~--~--~---
[kamaelia-list] Re: Submitting my own console writer for review.
On Mon, 02 Mar 2009 06:30:09 -, Steve wrote: > 7) No line continuation \ is needed inside a multiline """ comment > """. You are correct - it is not necessary - but it helps with the parsing done for the automatically generated component reference documentation on the website. Iirc, without it you effectively get a blank, empty line at the start of the doc string. The currently employed algorithm for stripping the indentation gets confused by it. Hmm, thats a bit rubbish really - I ought to sort it out :-) Matt -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@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 -~--~~~~--~~--~--~---
[kamaelia-list] Re: Improving reference documentation
For me this highlights a difficulty with making a component generic (and therefore more useful) vs knowing where to find the component for the task at hand: I've found the name of the module "ConnectedServer" a little mystifying until now. your explanation about how it could be used for non TCP server based tasks, plus what you've said here means it now makes sense for me. I imagine others have had similar difficulty when asking the question "where do I find a component for building a TCP server?". The name "ConnectedServer" is definitely the most logical descriptive choice. However, combined with its location in Kamaelia.Chassis, it doesn't feel like the natural place to look for building a TCP server. I have a suggestion: Maybe what we need is a slightly stripped back properly generic ConnectedServer module (ie. similar to what it is now, but without the TCP server specificness); then a specialisation of it in Kamaelia.Internet that more closely resembles how it currently stands. I'd imagine this Kamaelia.Internet.Server (or whatever you call it) component would be a prefab, or subclass, of the Kamaelia.Chassis.ConnectedServer component. Only problem I can see with moving towards my suggestion would be maintaining backwards compatibility. Perhaps that could be solved by coming up with a new name for the "properly generic" ConnectedServer module in Kamaelia.Chassis - ummm, eg. Kamaelia.Chassis.ConnectionServer and later marking the existing Kamaelia.Chassis.ConnectedServer with prominent deprecation warnings. Matt On Wed, 14 Jan 2009 10:55:34 -, Michael Sparks wrote: > > On Wednesday 14 January 2009 02:36:30 Jason Baker wrote: >> -= >> -Simple Server Chassis >> -= >> + >> +SimpleServer and ServerCore Chassis >> + > > I've rewritten that part of the file, calling it "Connected Servers" > instead, > to be a) consistent with the filename b) consistent with the fact that > neither > SimpleServer nor ServerCore are actually limited to TCP based servers. > (It'd > be a little bit of a pain at present to do some other sorts, but doable) > > > Michael. -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@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 -~--~~~~--~~--~--~---
[kamaelia-list] Improving reference documentation
Hi, sorry I've been a bit quiet for a bit! So I'm thinking of making up for it by spending some time improving the component reference docs in Kamaelia ( http://www.kamaelia.org/Components ). I've got a few questions: First up: Any particular components that stand out to anyone as lacking documentation? I'm not promising to take any notice of anyone's suggestions, but I'll bear them in mind ;-) Next: Kamaelia.Apps contains a fair few components and prefabs. However, being app specific, I'm unsure if they're appropriate to "component reference" documentation. Should I bother doing these? Should I make reference to the apps to which they belong? Would documenting them just serve to confuse (since presumably they are of limited reusability, being app specific) Finally, a more complicated one: Some source files are completely undocumented, or appear confusingly sparse - particularly those that provide support or helper functions that are neither components nor prefabs. Eg. much of Kamaelia.Support. I'm thinking in some of those cases it may be useful to have documentation for those items. For example: Kamaelia.Visualisation.Axon.PComponent is a class that must be plugged into the topology visualiser to render blobs that visually represent kamaelia components. This already contains some helpful docstrings, but they don't make it into the reference docs. I see two possiblities at the moment: 1) Allow the docs to include these things - since they're useful. 2) Leave things as they stand, because this is a "component reference" and they are not components. My gut feeling is that (2) might be favouring purity over usefulness; however would (1) necessitate changing the name from "component reference" to something else to avoid confusion? If we plump for (1) then I'd propose implementing it by adding another tagging line to each source file, specifying what symbols should be documented - like we already do for components and prefabs: __kamaelia_components__ = [ a, b, c ] __kamaelia_prefabs__ = [ p, q, r ] perhaps simply calling this extra one 'other': __kamaelia_other__ = [ x, y, z ] Any ideas? Matt -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@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 -~--~~~~--~~--~--~---
[kamaelia-list] Re: Running Kamaelia in the non-main thread
On Wed, 17 Dec 2008 17:46:48 -, Sylvain Hellegouarch wrote: > > Rasjid a écrit : >> Posted a longer message to the list yesterday, but its seems to have >> been lost. Just wanting to confirm that Kamaelia works well even when >> not running in the main thread. I think what I want is LikeFile >> (http://www.kamaelia.org/Cookbook/LikeFile). One of my interests in >> writing custom protocols that need to be embedded in other frameworks, >> such as Windows COM or under Mozilla's XPCOM, or just with a GUI >> toolkit like wxWidgets. I have worked a bit with Twisted, but got >> discouraged when it appeared that Twisted *really* wanted to be >> running in the main thread. (This was over a year ago so perhaps >> things have changed - but I still think that Kamaelia will fit my >> brain better.) >> > > > Just to confirm that Kamaelia has no trouble at all running in a thread > different from the main one. I've also recently used a small kamaelia subsystem running in an ancilliary thread. believe I did indeed use Likefile, although there have been a few changes recently which may have replaced Likefile with a similar, but better engineered alternative (I'm afraid I can't remember details right now - sorry!) Matt -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@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 -~--~~~~--~~--~--~---
[kamaelia-list] Re: One to Many with Graphline?
On Thu, 20 Nov 2008 10:31:42 -, Michael Sparks <[EMAIL PROTECTED]>
wrote:
> As well as this though, your message has made me think "hmm, maybe
> there should be something that looks like a graphline (a chassis) that
> does
> the same sort of thing as a splitter", and so I'll probably take that up
> in a
> different message :-)
It might be quite fun to add fanning out support to Graphline.
Aside from that though, I thought trying to do a one-to-many fanout should
have caused Axon to throw a BoxAlreadyLinkedToDestination exception to
point out that you're not allowed to do it. However it seems it doesn't,
and this seems to be because python doesn't complain if you specify the
same key multiple times in a declaration:
>>> {("A","outbox"):("B","inbox"), ("A","outbox"):("C","inbox")}
{('A', 'outbox'): ('C', 'inbox')}
Matt
--
| Matt Hammond
| Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK
| http://www.bbc.co.uk/rd/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"kamaelia" group.
To post to this group, send email to kamaelia@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/kamaelia?hl=en
-~--~~~~--~~--~--~---
[kamaelia-list] Re: signal & control on Components
On Wed, 19 Nov 2008 03:42:09 -, Joseph Heck <[EMAIL PROTECTED]> wrote: > With the tidbit at > http://www.kamaelia.org/Docs/Axon/Axon.Component.html#14, it wasn't > clear if that was a signal based thing or if I wanted to implement > that I'd need to include my own checking code in the component. Apologies: I've just realised that I misunderstood what you were asking! Yes you need to include your own checking code. The code example given there is NOT functionality built into the component. It is an example of the kind of thing you would have to write when writing your own component. I've updated the docs to hopefully clarify this: http://code.google.com/p/kamaelia/source/browse/trunk/Code/Python/Axon/Axon/Component.py#214 The online compiled docs should be automatically updated with this change by tomorrow. Matt -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~--~~~~--~~--~--~---
[kamaelia-list] Re: signal & control on Components
On Wed, 19 Nov 2008 09:21:24 -, Matt Hammond <[EMAIL PROTECTED]> wrote: > In terms of how Axon actually implements it at the moment: If a > component dies, and is registered as the child of another component (its > parent), then internal notification callbacks ensure that the scheduler > is instructed to wake that parent component up. More specifically, the _callOnCloseDown attribute in the implementation of the Component baseclass: http://www.kamaelia.org/Docs/Axon/Axon.Component.html#17 Matt -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~--~~~~--~~--~--~---
[kamaelia-list] Re: signal & control on Components
On Wed, 19 Nov 2008 03:42:09 -, Joseph Heck <[EMAIL PROTECTED]> wrote: > The first is the linkage of children components to "parents". Is the > termination of a child component waking up the parent something that > happens in the base Component class with signals? > > With the tidbit at > http://www.kamaelia.org/Docs/Axon/Axon.Component.html#14, it wasn't > clear if that was a signal based thing or if I wanted to implement > that I'd need to include my own checking code in the component. It is not done via inboxes/outboxes of any kind. In terms of how Axon actually implements it at the moment: If a component dies, and is registered as the child of another component (its parent), then internal notification callbacks ensure that the scheduler is instructed to wake that parent component up. Matt -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~--~~~~--~~--~--~---
[kamaelia-list] Re: [Kamaelia-commits] FAILED: Kamaelia documentation automatic generation for website
On Mon, 03 Nov 2008 09:07:48 -, Michael <[EMAIL PROTECTED]> wrote: > On Monday 03 November 2008 04:05:16 [EMAIL PROTECTED] > wrote: >> AttributeError: 'Test_Graphline' object has no attribute 'assertFalse' > > Intriguing error. Almost certainly due to python version. Confirmed: http://www.python.org/doc/2.3.3/lib/testcase-objects.html Matt -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~--~~~~--~~--~--~---
[kamaelia-list] Re: Bug in new website page layout
Suggestion (as requested!):
change the 'pre' block in /newcss.css:
pre {
font-size: 80%;
overflow: auto;
padding: 0.5em;
background-color: #FFF7bf;
}
This adds scrollbars if the contents is too wide.
Only the 'overflow' property is is actually necessary for this change. The
'padding' and 'background-color' properties, I think, just make it a
little nicer :-)
Matt
On Tue, 28 Oct 2008 16:51:06 -, Michael Sparks <[EMAIL PROTECTED]>
wrote:
>
> On Tuesday 28 October 2008 16:17:12 Matt Hammond wrote:
>> As an example: look at the large formatted example of output data
>>
>> under the "Behaviour" heading on this page:
>>
>>
>> http://www.kamaelia.org/Components/pydoc/Kamaelia.Device.DVB.Parse.ParseNe
>> tworkInformationTable.html
>
> Suggestions as to how to fix this welcome :)
> (CSS changes or template changes)
>
>
> Michael
--
| Matt Hammond
| Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK
| http://www.bbc.co.uk/rd/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"kamaelia" group.
To post to this group, send email to kamaelia@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/kamaelia?hl=en
-~--~~~~--~~--~--~---
[kamaelia-list] Bug in new website page layout
Hi, Just noticed a bug with the new page layout (tested in Opera 9.61 and Firefox 3 on Ubuntu 8.04). If "" formatted sections of text are wider than the column width then the RHS gets cropped - making examples/samples partially unreadable in some cases. As an example: look at the large formatted example of output data under the "Behaviour" heading on this page: http://www.kamaelia.org/Components/pydoc/Kamaelia.Device.DVB.Parse.ParseNetworkInformationTable.html cheers Matt -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~--~~~~--~~--~--~---
[kamaelia-list] Re: private_CL_Topology3DCore ready for review
Actually, just realised: is this functionality needed at all? I built a 'freeze()' and 'unfreeze()' pair of methods into particles. As best I understand, these achieve exactly the effect you require. freeze() causes an internal flag 'static' to be set to true. The 'update()' method of the particle class takes this flag into account: def update(self, laws): ... if self.static: self.velocity = [0 for x in self.velocity] else: self.velocity = laws.dampening(self.ptype, self.velocity) self.pos = map(_add, self.pos, self.velocity) If True, then it does not update the particle's position, and zeroes its velocity - thereby freezing it. Matt On Tue, 28 Oct 2008 14:14:33 -, Matt Hammond <[EMAIL PROTECTED]> wrote: > > Perhaps that functionality should be directly incorporated into > ParticleSystem.py, rather than as an extra subclass? The implementation > changes look quite minor, and its quite easy to see how the behavior can > be made to gracefully degrade back to the existing behaviour. > > I'm also not clear how that list gets updated during runtime - as you > begin to drag/rotate a particle and as you end. I get the impression you > rely on the list being a shared data structure (shared between the > particle sytem and whatever is updating it?) That feels a bit like a side > effect that could easily trip someone up when making future modifications > to ParticleSystem[X]. Perhaps better to add methods to change the list, > or > make the list a visible attribute of the object? > > > Matt > > On Tue, 28 Oct 2008 13:36:11 -, Chong <[EMAIL PROTECTED]> > wrote: > >> >> Hi Michael, >> >> It extends ParticleSystem with the support of allowing some particles >> not subject to physics laws. When rotating selected particles, I do >> not doInteractions to these selected particles so that their movement >> is only controlled by rotation and other particles move accordingly >> with respect to the physics laws. For more details, please see its >> documentation. >> >> Cheers, >> Chong >> >> On Oct 27, 8:50 pm, Michael Sparks <[EMAIL PROTECTED]> wrote: >>> On Monday 27 October 2008 02:54:16 Chong wrote: >>> >>> > Kamaelia/Kamaelia/Support/Particles/ParticleSystemX.py >>> >>> Can you explain this file some more? The name is particularly cryptic. >>> >>> Michael >>> --http://www.kamaelia.org/Home >> > > > > -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~--~~~~--~~--~--~---
[kamaelia-list] Re: private_CL_Topology3DCore ready for review
Perhaps that functionality should be directly incorporated into ParticleSystem.py, rather than as an extra subclass? The implementation changes look quite minor, and its quite easy to see how the behavior can be made to gracefully degrade back to the existing behaviour. I'm also not clear how that list gets updated during runtime - as you begin to drag/rotate a particle and as you end. I get the impression you rely on the list being a shared data structure (shared between the particle sytem and whatever is updating it?) That feels a bit like a side effect that could easily trip someone up when making future modifications to ParticleSystem[X]. Perhaps better to add methods to change the list, or make the list a visible attribute of the object? Matt On Tue, 28 Oct 2008 13:36:11 -, Chong <[EMAIL PROTECTED]> wrote: > > Hi Michael, > > It extends ParticleSystem with the support of allowing some particles > not subject to physics laws. When rotating selected particles, I do > not doInteractions to these selected particles so that their movement > is only controlled by rotation and other particles move accordingly > with respect to the physics laws. For more details, please see its > documentation. > > Cheers, > Chong > > On Oct 27, 8:50 pm, Michael Sparks <[EMAIL PROTECTED]> wrote: >> On Monday 27 October 2008 02:54:16 Chong wrote: >> >> > Kamaelia/Kamaelia/Support/Particles/ParticleSystemX.py >> >> Can you explain this file some more? The name is particularly cryptic. >> >> Michael >> --http://www.kamaelia.org/Home > > -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~--~~~~--~~--~--~---
[kamaelia-list] Re: private_MPS_ImprovedGraphlineShutdown ready for merge
Hi all, Michael and I chatted on IRC this evening about this and came up with what seems a sensible way to "complete" the shutdown behaviour - so that shutdown messages would be passed on. See IRC logs http://edit.kamaelia.org/logs/kamaelia2008-10-27_log.html from 21:40 onwards I've just checked in the mods to achieve this. The behaviour of Graphline (in this branch) wrt shutdown should now be this: (pseudocode courtesy of Michael): while not self.childrenDone(): if no component-has-linkage-to-graphline's control_ pass on messages from our control to appropriate sub-component's control if message is shutdown, set shutdown flag # then after loop if no component-has-linkage-to-graphline's signal_ if shutdown flag set: pass on shutdownMicroprocess else: pass on producerFinished This feels reasonably clean and simple IMO. It ensures a graphline passes on a shutdown message (so it plays nicely when part of a pipeline) yet also steps back and defers to the author of the graphline when the author seems to be trying to implement their own shutdown handling linkages: * If the "control" inbox is wired up, it will not try to pass on incoming shutdown messages to *any* subcomponents (with or without un-linked "control" inboxes) * If the "signal" outbox is wired up, it will not try to generate or pass on any shutdown messages out of its "signal" outbox. If the author has not wired up the graphline's "signal" outbox, then the graphline ensures that, once all subcomponents have terminated, it sends its own shutdown message: either a shutdownMicroprocess (if it noticed the graphline receiving one on its "control" inbox) or a producerFinished if the subcomponents appear to have shut down of their own accord. If the author does not bother to wire up the graphline's "control" and "signal" boxes; then graphline takes over and ensures that: shutdown messages that it receives are propagated to all its subcomponents; and that the shutdown message is also passed on. I reckno this therefore means the graphline will behave roughly as you would expect any other component to behave - shuttting down and passing on shutdown messages as appropriate. I've fleshed out /Kamaelia/Examples/UsingChasses/Graphline/DemoShutdown.py (in the branch) to show some of these cases. I'm thinking I'll probably refactor them as a new graphline test suite - since that big pile of code is probably not suitable as an example/demo! I've not tested these mods against many of our apps/sketches yet. I'd appreciate any further testing, comments or review of this. cheers Matt -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~--~~~~--~~--~--~---
[kamaelia-list] Re: private_MPS_ImprovedGraphlineShutdown ready for merge
y > > What does it do? >It extended Graphline slightly such that, when a message is received > on >the Graphline's "control" inbox, that the message is copied to all >subcomponents' "control" inbox, as long as they don't already have >anything linking there already. >If a shutdown message is sent to the graphline, the graphline will now >terminate normally, after having passed on that message to > subcomponents. > > To merge (if happy) > > cd trunk/Code/Python > svn merge -r5426:HEAD > ../../../branches/private_MPS_ImprovedGraphlineShutdown . > svn ci . > > ... or just say "Looks good here" :-) > > If there's no volunteer for merging/reviewing this, or I get a "looks > good > here" I'll merge this. I would really appreciate a review/comments > though. > > Regards, > > > Michael. -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~--~~~~--~~--~--~---
[kamaelia-list] Re: private_MPS_ImprovedGraphlineShutdown ready for merge
I'm happy to review this and merge it (either this evening or tomorrow evening) Matt On Mon, 27 Oct 2008 01:13:16 -, Michael Sparks <[EMAIL PROTECTED]> wrote: > > Hi, > > > As per the discussion here: >* http://groups.google.com/group/kamaelia/msg/861f641833a40238 > > I've implemented "graphline passes on control messages to all > subcomponents > that don't have anything linked to control". A demo using this facility > can be > found here: > > http://kamaelia.googlecode.com/svn/branches/private_MPS_ImprovedGraphlineShutdown/Kamaelia/Examples/UsingChassis/Graphline/DemoShutdown.py > > The output from that is this: > __main__.Waiter_6 waiting > __main__.Waiter_7 waiting > __main__.Waiter_8 waiting > sent 1! > __main__.Waiter_6 shutting down having recieved: > > __main__.Waiter_8 shutting down having recieved: > > __main__.Waiter_7 shutting down having recieved: passedon > sent 2! > > This strikes me as a nice, simple, useful extension from the current > situation, and so I think this is ready for merge. > > Branch: private_MPS_ImprovedGraphlineShutdown > Branch point: 5426 > > To assist with review: > >cd branches/private_MPS_ImprovedGraphlineShutdown >svn diff -r5426:HEAD > > Modified Files: > Index: Kamaelia/Kamaelia/Chassis/Graphline.py > > New files > Index: Kamaelia/Examples/UsingChassis/Graphline/DemoShutdown.py > > What does it do? >It extended Graphline slightly such that, when a message is received > on >the Graphline's "control" inbox, that the message is copied to all >subcomponents' "control" inbox, as long as they don't already have >anything linking there already. >If a shutdown message is sent to the graphline, the graphline will now >terminate normally, after having passed on that message to > subcomponents. > > To merge (if happy) > > cd trunk/Code/Python > svn merge -r5426:HEAD > ../../../branches/private_MPS_ImprovedGraphlineShutdown . > svn ci . > > ... or just say "Looks good here" :-) > > If there's no volunteer for merging/reviewing this, or I get a "looks > good > here" I'll merge this. I would really appreciate a review/comments > though. > > Regards, > > > Michael. -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~--~~~~--~~--~--~---
[kamaelia-list] Re: [Kamaelia-announce] RELEASED : Kamaelia 0.6.0, Axon 1.6.0 (yes, finally! :-)
> Filtering.py RawAudioMixer.py > Codec/PyMedia/ > Decoder.py Encoder.py > PyMedia/ > Input.py Output.py Resample.py > Chassis/ > Carousel.py ConnectedServer.py Graphline.py Pipeline.py > Prefab.py > Codec/ > Dirac.py RawYUVFramer.py Speex.py > Device/ > DVB/ > Core.py DemuxerService.py EIT.py NowNext.py PSITables.py > Receiver.py Tuner.py > File/ > BetterReading.py ReadFileAdaptor.py Reading.py UnixProcess.py > Internet/ > ConnectedSocketAdapter.py Selector.py SingleServer.py > TCPClient.py TCPServer.py UDP.py > Protocol/ > EchoProtocol.py FortuneCookieProtocol.py Framing.py > SimpleReliableMulticast.py > HTTP/ > ErrorPages.py HTTPClient.py HTTPHelpers.py HTTPParser.py > HTTPResourceGlue.py HTTPServer.py IcecastClient.py > MimeTypes.py > Torrent/ > TorrentClient.py TorrentMaker.py TorrentPatron.py > TorrentService.py > UI/ > GraphicDisplay.py > OpenGL/ > Button.py Movement.py SimpleTranslationInteractor.py > OpenGLComponent.py > Pygame/ > Button.py Display.py Image.py KeyEvent.py Multiclick.py > Ticker.py VideoOverlay.py > Util/ > Backplane.py Chooser.py Chunkifier.py ChunkNamer.py Clock.py > Comparator.py ConsoleEcho.py Console.py DataSource.py Fanout.py > Filter.py Introspector.py MarshallComponent.py Marshalling.py > NullSink.py PassThrough.py PureTransformer.py RateFilter.py > Splitter.py Stringify.py UnseenOnly.py > Visualisation/ > Axon/ > AxonVisualiserServer.py ExtraWindowFurniture.py > PComponent.py > PhysicsGraph/ > TopologyViewer.py TopologyViewerServer.py chunks_to_lines.py > GridRenderer.py lines_to_tokenlists.py RenderingParticle.py > > Kamaelia/Experimental/Services.py > Kamaelia/Automata/Behaviours.py > > Kamaelia/Support/ > Deprecate.py > DVB/ > CRC.py Descriptors.py > Data/ > bitfieldrec.py Experimental.py Repository.py > Particles/ > SpatialIndexer.py > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > Kamaelia-announce mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/kamaelia-announce -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~--~~~~--~~--~--~---
[kamaelia-list] Re: Kamaelia 0.6.0 and Axon 1.6.0 Detailed Release notes now done
Well done - mammoth change list there - must have taken you ... quite a while! Axon Release Note Bug: """ Components can now be awoken when a component *leaves* an outbox again. """ ... should be "when a message *leaves* an outbox" ? Matt On Sat, 18 Oct 2008 15:30:57 +0100, Michael Sparks <[EMAIL PROTECTED]> wrote: > > Hi all, > > > I've now done the detailed release notes for Kamaelia 0.6.0 and Axon > 1.6.0 > > The combined release notes are here: > * http://www.kamaelia.org/ReleaseNotes060 > > The Axon 1.6.0 release notes are here: > * http://www.kamaelia.org/ReleaseNotesAxon160 > > Any feedback welcome - especially summaries of the release changes... > > As will be very clear from the notes this represents a signifcant > increase in > functionality, and tools, and also represents extensive improvements in > documentation. > > :) > > > Michael. -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~--~~~~--~~--~--~---
[kamaelia-list] Re: Kamealia and DVB-C
On Sun, 19 Oct 2008 19:45:03 +0100, Michael Sparks <[EMAIL PROTECTED]> wrote: >> I was wondering if the DVB modules of Kamaelia can also be used for >> DVB-C transmissions? > > It should be, the DVB component we use rely on the python-dvb3 bindings Seconded. It should stand a fair chance of working. Let us know if you hit any problems - we might be able to work with you to fix them relatively quickly. Matt -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~--~~~~--~~--~--~---
[kamaelia-list] Re: [Kamaelia-commits] FAILED: Axon documentation automatic generation for website
Looks like just a spurious fault - no further problems on Sunday or today. Matt On Sat, 27 Sep 2008 04:00:38 +0100, <[EMAIL PROTECTED]> wrote: > This is an automated email reporting a failure. > > Log of output: > -- > > --- > Building: Build of 'Axon' documentation > --- > > Updating source code svn checkout... > svn: PROPFIND request failed on '/svn/trunk/Code/Python/Axon' > svn: PROPFIND of '/svn/trunk/Code/Python/Axon': Could not resolve > hostname `kamaelia.googlecode.com': Host not found > (http://kamaelia.googlecode.com) > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > Kamaelia-commits mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/kamaelia-commits -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~--~~~~--~~--~--~---
[kamaelia-list] Re: [Kamaelia-commits] SF.net SVN: kamaelia:[5003] trunk/Sketches/MH/pop3proxy/pop3proxy.py
On Fri, 05 Sep 2008 10:09:12 +0100, Michael Sparks <[EMAIL PROTECTED]> wrote: > On Friday 05 September 2008 09:54:27 Matt Hammond wrote: >> On Thu, 04 Sep 2008 23:29:53 +0100, Michael Sparks <[EMAIL PROTECTED]> >> wrote: >> > On Thursday 04 September 2008 23:14:16 [EMAIL PROTECTED] >> > wrote: >> >> Basic completely transparent proxy to start with (not exactly rocket >> >> science!) >> > >> > being picky, it's a passthrough, not transparent one :-) >> > >> > /me continues hiding. >> >> Good point. Noted :-) > > It's a nice example though of how to make such a beast, I may nab that. Feel free. Matt -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~--~~~~--~~--~--~---
[kamaelia-list] Re: [Kamaelia-commits] SF.net SVN: kamaelia:[5003] trunk/Sketches/MH/pop3proxy/pop3proxy.py
Good point. Noted :-) On Thu, 04 Sep 2008 23:29:53 +0100, Michael Sparks <[EMAIL PROTECTED]> wrote: > On Thursday 04 September 2008 23:14:16 [EMAIL PROTECTED] > wrote: >> Basic completely transparent proxy to start with (not exactly rocket >> science!) > > being picky, it's a passthrough, not transparent one :-) > > /me continues hiding. > > > Michael. -- | Matt Hammond | Research Engineer, FM&T, BBC, Kingswood Warren, Tadworth, Surrey, UK | http://www.bbc.co.uk/rd/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~--~~~~--~~--~--~---
