Since I wanted to "sit" on  some IRC channels here at Mashed and rather than flit channels or waste screen estate I decided to do a short hack to listen to the channel. As a hack for mashed, it does the following things:

• It's IRC bot
• It joins 3 channels - #kamtest, #kamaelia & #mashed
• It listens to the channel

Anything that anyone says is then spoken (via espeak) by the bot. ie speech synth.

You can find the code here:

• https://kamaelia.svn.sourceforge.net/svnroot/kamaelia/trunk/Sketches/MPS/IRCSpeakerBot.py

As per my previous post, the Kamaelia 0.6.0 release candidate #6 is available and can be downloaded from http://edit.kamaelia.org/release/

Going to BBC Mashed? Want to go? (a few are tickets left) Interested in one of these : {Kamaelia, Python, Concurrency, Multicore, DVB, Building network systems, Pygame Based Systems, Audio/video based} ? If so, please come along to the talk! If there's a clash, don't worry, I'm starting a page called GetMashed which will contain at least some starting points which I'll cover. (It's not the same as seeing it for yourself though :)

The talk is at the start of the weekend intended to get you started with all of those things. As well as the session itself, a new release of Kamaelia is in the works with the first Beta/Release Candidate made available to an unsuspected world. What's going in the release?

• Well, the usual slew of extra components and bug fixes
• A variety of new tools - from video shot change detection, through to SMTP greylisting
• Multiprocess & hence multicore support (experimental at this stage, but so far so good :) )

And a large number of extra components - this is actually a lot more than I originally expected/anticipated. However they're divided into two halves - new components and components from applications merged into the repository. (the latter means that you can take parts of random Kamaelia applications and embed them in other random Kamaelia applications. As a result: New Components:

• Kamaelia.
• Chassis
• Seq
• Codec
• WAV, YUV4MPEG
• Device
• DVB
• SoftDemux
• Parse
• ParseEventInformationTable, ParseNetworkInformationTable, ParseProgramAssociationTable, ParseProgramMapTable, ParseServiceDescriptionTable, ParseTimeAndDateTable, ParseTimeOffsetTable, PrettifyTables, ReassemblePSITables
• Experimental
• Chassis, ERParsing
• File
• MaxSpeedFileReader, UnixProcess2
• Internet
• TimeOutCSA
• Protocol
• MimeRequestComponent, RecoverOrder, SDP
  
• AIM
• AIMHarness, ChatManager, LoginHandler, OSCARClient
• HTTP
• Handlers
• Minimal, Handlers/SessionExample, UploadTorrents
• IRC
• IRCClient
• RTP
• NullPayloadPreFramer, NullPayloadRTP, RTCPHeader, RTPHeader, RtpPacker, RTP
• Util
• Tokenisation
• Simple
• Collate, FirstOnly, Max, OneShot, PromptedTurnstile, RangeFilter, RateChunker, SequentialTransformer, Sync, TagWithSequenceNumber, TwoWaySplitter
• UI
• Pygame
• Text, VideoSurface
• Video
• CropAndScale, DetectShotChanges, PixFormatConversion
• Visualisation
• ER
• ERLaws, ERVisualiserServer, ExtraWindowFurniture, PAttribute, PEntity, PISA, PRelation
• XML
• SimpleXMLParser
  

Components merged in from Apps:

• Kamaelia
• Apps
• Compose
  
• BuildViewer, CodeGen, PipeBuild, PipelineWriter, GUI
• GUI
• ArgumentsPanel, BuilderControlsGUI, TextOutputGUI
• IRCLogger
• Support
• Show
• GraphSlides
• Whiteboard
• Audio, Canvas, CheckpointSequencer, CommandConsole, Entuple, Options, Painter, Palette, Router, Routers, SingleShot, TagFiltering, Tokenisation, TwoWaySplitter, UI
  

All of this also totally ignores the new examples & new Kamaelia based apps.
Also a new website is coming soon, but time ran out :-)

So given all that, session details:

What: How to get started hacking with Kamaelia  - making concurrency fun, easy & useful
When: 12:15 - 12:45, 21 June 2008
Where: Garden Table area at Top West Hall, Alexandra Palace, London
Who: Me - Michael Sparks :-)
Why: To help people get started with hacking Kamaelie
How: One part presentation, two parts tutorial, lightning talk style and a note of "this is what I look like, come find me!"

More detail:

How to get started hacking with Kamaelia - making concurrency fun, easy & useful with Michael Sparks

Kamaelia is an open source project from BBC R&D. It makes prototyping new and interesting systems simple. Kamaelia systems are naturally concurrent and transform easily into production quality, maintainable systems.

It is useful for things from 3D systems through building PVRs through video playback, through shot change detection, through P2P distribution (live and bit torrent), through whiteboards, handwriting/gesture recognition, speech generation, and games systems, and back through DVB on both the reception side and broadcast side, and lots more not mentioned...

This talk will introduce Kamaelia, helping you get started - complete with a new release to boot!

• Website: http://edit.kamaelia.org/Developers/
• Introduction: http://edit.kamaelia.org/NewIntroduction
• Toybox: http://edit.kamaelia.org/Components
• Cookbook: http://edit.kamaelia.org/Cookbook
• Get Mashed with Kamaelia

Discussion Thread in the forum

(12:15 - 12:45) - 21 Jun 08
Garden Table area at Top West Hall

Download iCalendar: How to get started hacking with Kamaelia

GET MASHED (Link Kamaelia site)

I'm considering looking at how to do this, since it looks doable, but wonder if anyone has any experience of actually doing this, even partially. It's a very similar problem, it seems, to running a TV using solar power when camping, so it's not that strange a scenario. I've come to the conclusion that one way of doing this is as follows:

• Use a cheap/old/low power laptop
• Buy a car battery - or perhaps a 12V 100Ah battery
• Use a 60W solar panel (or similar) to charge the 100Ah battery
• Use a car cigarette light connector based power adapter to connect laptop to battery

The issue there is the 60W solar panel is expensive right now, and I'm wondering if there's a way of reducing this figure down lower - if anyone has experience of doing this. I'm also not sure it's sufficient - I suspect it has to be higher rated than that.

I'd be interested in hearing from anyone who's tried doing this.

The Small-Scale Experimental Machine, known as SSEM, or the "Baby", was designed and built at The University of Manchester, and made its first successful run of a program on June 21st 1948. It was the first machine that had all the components now classically regarded as characteristic of the basic computer. Most importantly it was the first computer that could store not only data but any (short!) user program in electronic memory and process it at electronic speed. -- http://www.computer50.org/

We're planning a new release of Kamaelia for that day, which also co-incides with BBC Mashed (aka BBC hackday 2). The new release should include, among other things, our multicore support, basic software transactional memory, generator, thread, process based components, a variety of example applications, a revamped website (yes, it needs a lick of paint) as well as a large number of new components from improved DVB support, better pygame tools, etc.

How are you planning on celebrating the 60th anniversary ?

:-)

As discussed before, Kamaelia now has multicore support in subversion in the form of ProcessPipeline and ProcessGraphlines, meaning taking any Kamaelia system and making it multicore is a matter of simply pre-pending "Process" to the pipeline set up. That's pretty cool - especially if you're aware of what our normal cookbook code looks like. The question I've really got is where to merge this on the mainline. Given how useful this would be, it strikes me that like ThreadedComponent & LikeFile and Introspection, this ought to live in Axon. However, like Introspection, it probably also ought to be used from inside the Kamaelia Namespace.

As a result, it seems to make sense to do this - Put the core code in:

Axon.Processes

But put the ProcessPipeline & ProcessGraphline component in:

Kamaelia.Chassis.Process

So that you would use them as:

from Kamaelia.Chassis.Process import ProcessPipeline, ProcessGraphline

I'm pretty sure that's a pretty good idea - since it allows updates to the implementation that these use without affecting the interface.
That said, people will probably search for Multicore as well, so is it worth the naming actually being this:

from Kamaelia.Chassis.Multicore import ProcessPipeline, ProcessGraphline

... or simply having that available as an alias ?

Fundamentally this would still be used in the same way as previously described:

from Kamaelia.Chassis.Multicore import ProcessPipeline # this or
from Kamaelia.Chassis.Process import ProcessPipeline   # this?

ProcessPipeline(
                Textbox(position=(20, 340), # Open first pygame window
                                 text_height=36,
                                 screen_width=900,
                                 screen_height=400,
                                 background_color=(130,0,70),
                                 text_color=(255,255,255)),
                TextDisplayer(position=(20, 90), # Open second pygame window
                                        text_height=36,
                                        screen_width=400,
                                        screen_height=540,
                                        background_color=(130,0,70),
                                        text_color=(255,255,255))
                )

But the naming affects where you go hunting for the functionality.

My personal preference is for the former (Kamaelia.Chassis.Process), though I can see user friendliness in naming something based on what people are likely to hunt for being attractive.
Used without care, multiprocess usage would probably hurt performance - since messages between components in separate processes are pickled objects, but generally speaking, we all know you'd take that into account, wouldn't you...?

Thoughts?

New faces bring new ideas. As part of Google Summer of Code this year I asked upfront our students why they didn't want to use the mailing lists the project uses on sourceforge (since it was clear they didn't) - preferring private mails and IRC (as a project we tend to prefer IRC generally nyway). The response we got was unaminous around the fact they didn't want to subscribe due to SF lists being highly spammy, and requested we move over to google groups - so they could also gain better web access and RSS feeds. It was the one answer I hadn't thought of or expected :-)

So I chatted with the other members of the community and they all pretty much agreed, but they hadn't thought of saying anything (which strikes me as a bizarre version of the Bystander Effect :-).

Anyhow, as a result, I've shifted our list over and the new faces on the block are running rampant there, which is really cool. Not only that but it's encouraging students from previous years to start popping their heads back up (so far only on private mail, but I think they can be teased out further), which is really neat :)

Sometimes it's the little details you take for granted that you completely miss...

I just thought it worth sharing in case other people think it's worth asking their new colleagues for any suggestions for making their communities more accessible :-)

People have used the comment or new post feature of my blog recently to leave some useful comments. Rather than have them as top level posts though, I'll drop them as replies to this post. In summary though:

• I had a complaint/bug report from Steve (no surname) about the dates in my RSS feed (which should now be fixed), about double escaping of entities (which is also hopefully fixes). Steve also made a comment saying that he wished he didn't have to enter HTML manually. This strikes me as odd, because I'm typing this using Dojo's editor widget, so I guess that failed disgracefully on his machine. I've seen that on a few machines, but Dojo's generally got the most browser friendly wysiwyg editor, so I'm not sure what's up there.
• I had a request whether Kamaelia's latest release is available for windows as a special bundle. The answer to that really is "it's python, so it should work, but we tend to develop under linux & Mac OS X so you may find some niggles". I certainly haven't created an installer for windows. All that said, we are overdue doing a new release, and /trunk is far and away recommended. Even so, that needs updating as well with recent developments... :-)
• Finally, another anonymous poster made the following comment:
• Came across this today and thought you might be interested in it Michael:
  
  Concurrency/message passing Newsqueak [video.google.com]

Not tested this, but this looks really interesting/promising. The AR Toolkit is really cool, and this appears to be linux & mac os x bindings for it. (Means that using this people should be able to access a webcam easily from both of those OSs using python...)

• http://mgldev.scripps.edu/projects/pyartk/index.html
• http://mgldev.scripps.edu/projects/pyartk/docs.html

We're getting some commons questions regarding GSOC, which boil down to "how do I write a successful application". I've taken the common starting point and generalised my comments, questions and suggestions in the hope of helping those in the crunch. This will also go on the Kamaelia website linked from the GSOC pages. As such this is written on the assumption the reader is someone interested in putting in a GSOC application.

> I want to write a simple kamaelia based [....] for Google Summer of Code,

That's a very clear, definite, good statement. It's incredibly simple to get a hold of, so the questions really arise around "what sort of look/feel do you want to have", and "how do you want the [...] to work" and "how do you want communication between [...] to work" as well as "how do you plan to maintain persistent information as well as dynamic (maybe shared) state". (if any)

If you've sent existing code, this helps a lot with evaluating your idea, especially if it relates directly to your idea. Really, this boosts your application likelihood of acceptance dramatically.

Some general points:

• You need a mechanism for handling initialisation of the system and activities using the system.
• You may need to think about the transition from initialisation to the normal operation. (eg login vs logged in)
• You'll need to think how you manage global state (managing the model)
• You'll need to think how you manage specific state (managing interactions)
• You may need to think about file/definition formats
• If the system is multiuser, with interactions, you'll need to define that mechanism. That could be a protocol, use a pre-existing protocol, or just a mechanism for forwarding internal messages.
• You may want to consider user to user interactions vs global vs localised (eg talking in a room)
• You will need to think how existing components can assist you.

Regarding how you go about development, some points:

• First of all think "what's the simplest possible version that would work?" (single windows GUI, single web page, single screen, single ...)
• Then consider how you extend it in each of the possible directions you're thinking of going, growing organically. (this makes it easier to track your development)
• Consider something really cool as a possible next step, after all, things may be simpler than you expect.

> The system will [...] and [...] and [...] and put [...] and [...] into a [......]

Consider some of the of the implications for each thing you suggest. Do components already exist that can support it? (eg {SQL, webcam, ardunio, twistedintergration} components don't *at present* exist, but would be useful). Recognising what's missing from the component set and how your project helps grow the project is important. Both for us, and for you (since creating components is kinda the point of these projects :). You'll need to think ho your new components will operate and how they'll be used. However DON'T overengineer or think "I'll do this in case someone needs it". If you don't need it, leave it out. If you need it, put it in. You can however sometimes make your life easier by generalisation. Tease these aspects out in your application.

Finally, you need to put the whole thing into the application template covering the various areas we need to assess the project:

• Short one line of what the task is designed to achieve/create.
• A practical, clear result of what will be possible as a result of achieving this task. This is best described in the case of a user story.
• The context in which this task sits. Has this task any history? Is it the result of any previous tasks - either within the project or outside.
• What benefits will be gained by working on this task, and achieving its goals? Speculative as well as certained/realistically expected benefits are valid here.

Regarding the actual application template which is here:

• http://kamaelia.sourceforge.net/SummerOfCode2006Template (yes, this is the same template :-)
  

Some key things:

• We expect you to divide the project deliverables up into two categories "will deliver" and "given sufficient time".
• The Project Details section is where you get to describe lots of the things I raise in terms of questions above. The application character count limit though is worth bearing in mind. (ie detailed, but not too ott maybe)
• Project Schedule is really a guestimate of what you think you will have done by when. It will probably be wrong, but by listing it we can see if you're way ahead of schedule (which can be good - if you have a project with lots of scope for growth - which you do), or if you're really behind, in which case we can re-evaluate the schedule if its for good reasons.
  Key things to think of:
• What do you think you will have done by the mid term evals. For that think "what will I get done by July".
• What do you have confidence of getting done between then and mid-august.

Finally, bear in mind we won't be able to take all applicants, but want to take good applications. If you follow this advice you have a much better chance of success.