Michael Sparks wrote: > Hi Gloria, > > > As noted elsewhere I've been playing catch up a bit here... > > On Saturday 11 April 2009 20:50:21 Gloria W wrote: > >> Hi Michael, >> >> Attached are my PyCon 2009 slides for the Kamaelia toturial I gave. >> > > This is really helpful. The actual video taken at the time is now up at > the pycon video website here: > > Part one: (1 hour) > * http://pycon.blip.tv/file/2022798/ > Part two: (18 minutes) > * http://pycon.blip.tv/file/2022853/ > > Incidentally, I love the fact that this tutorial is helping underprivileged > kids - that's fantastic :-D > It was originally how I bribed my friend Alex to be my assistant. But in actuality, she would have done it anyway :) > Downside of the video though is that I think that this is missing about > an hour and quarter from the middle of your tutorial - that said it's really > really cool to see :-) > That stinks. I know they had an audio problem, and did not want to interrupt me to fix it. Oh well, life goes on. > >> The >> first hour was spent reviewing current concurrency solutions, from >> simple xargs bash, to subprocess, to the Python 2.6 processing module, a >> bit about Twisted, some code samples, etc. >> > > I really liked this. Setting context like this is important, and actually > starting off with bash is great. In a way, as I think I've mentioned before, > kamaelia is kinda based on the idea "if only you could do more bash like > stuff with normal code" - largely because I use bash a lot as well :) > 8) I teach a class in parts of Europe called Bash Crash. It's an 8 page crash course in bash, with exercises. I grew up with the command line, starting with Minix 22 years ago (yikes! has it really been that long?), then csh, tsh and ksh, etc. I still sincerely believe that people should become proficient in a some shell, simply because it's it's incredibly useful for concurrency and many other functions.
Not sure if you've seen this, but someone wrote a tetris game entirely in zsh! http://slackwiki.org/ZSH Wow! > >> The rest of the time was >> spent going through Kamaelia basics, showing examples of different >> component types, looking at the epydocs (I ran httpd on my laptop, and >> exposed the epydoc output generated from your code. I asked people to >> look at it while we reviewed code), and writing small examples on the >> fly. The slides do not properly represent the free-form coding and >> review we did. I hope the tutorial is somewhere online. >> > > I liked what I saw - for maybe obvious reasons I'd never thought of > attaching PDB to various kamaelia systems - and I was rather suprised > at how clean it worked out - making me think that a PDB chassis would > be interesting to have. (Not sure how that'd work out but being able to > trace specific components would probably be quite interesting - especially > given you could potentially wrap components on the fly with an appropriate > console.). > Oh wow...a pdb chassis...wow. I guess you'd have to add a bit of control code to allow the end user to determine which thread/component they could interactively interrupt and step through. And the questions abound about if/how you'd pass debugger control from one thread to another...but wouldn't that be neat, even if it only followed one thread at a time. The very first interactive thread debugger (at least the first one I have seen not implemented in hardware). That would really rock, especially if you could stop and restart execution, and control the order of execution, of multiple threads/components to test a race condition. Nifty! > >> One person who attended is a scientist who does data modeling for cancer >> research. She wants to try to use Kamaelia to distribute this this, and >> I offered to help set her up if she can get scrubbed data to pass my >> way. I have CC'd her on this email. If she is able to get scrubbed >> data, I'd love to post it to the list and have us all think about how to >> help he effective distribute the computations and other data operations. >> > > That would be great. That part of the discussion is missing from the video > (it jumps from the end of looking at the slides/presentation tool/graphline > to the end of looking at introspecting the dining philosophers example). > Damn it, there is a lot missing there. > >> At PyCon I also spoke to the game developers who wrote EVE, about >> Kamaelia vs. Stackless, and they gave me some charts comparing >> performance of the two tools, and said they chose Stackless because of >> the performance. I still like the Kamaelia interface and overall >> paradigm much better, and wanted to ask you about this. Is the >> performance problem predominantly in the scheduler, and under what >> circumstances would we see it? >> > > Well, some benchmarking was recently done by Steve Wittber, who has been > working on a library called "fibra" for a while, since his library grew what > he > calls "tubes" which are kinda equivalent to kamaelia linkages and stackless's > channels. > > Without beating about the bush, he benchmarked Fibra, Kamaelia, Stackless > and plain old threads. The good news is all 3 of us beat plain old threads > hands down. The unsuprising news is that stackless was the hands down > winner - for reasons I'll come back to, and the "bad" news was that Fibra > was 10 times faster than Kamaelia... (according to this benchmark) > > [snip of really vital data] > > However, as noted, this particular benchmark is very much an abberation of > the way Kamaelia generally operates. Whilst we do have a lot of message > passing, it's not generall excessive, and often network or device overheads > tend to dominate. > Thanks for elaborating on this, I greatly appreciate it. Speaking with others at PyCon, we do agree that Kamaelia wins hands-down in terms of ease of use for a concurrency tool. It's great to hear that speed issues are directly related to end user design inefficiency in message passing. [snip PHP ReST replacement for Drupal framework] >> That being said, I'm looking at the HTTP server request header code, and >> I'm going to write a CRUD component for it, detecting >> GET/POST/PUT/DELETE from the request header. I am tempted to write it as >> a graphline, accepting the four different inputs, issuing a response >> header and body output. Does this sound correct to you? >> > > It sounds reasonable, but it's a little late here, and I've seen there's a > follow > up and will play further catchup tomorrow :-) > Thanks. That thread discusses a protocol implementation in Kamaelia, but not the ReST implementation itself, so any ideas you may have in this respect would be great to hear. > >> Thanks again, and please excuse the rambling. >> > > You're welcome, and many thanks for giving the tutorial. I found it > extremely interesting to listen to and have made a bunch of notes > regarding how to improve the project docs, splitting things up, a clearer > idea about the sorts of examples that would be useful etc. > > One thing I do find amusing was the repeated "criticism" (and I use the term > loosely!), that Kamaelia can be hard because it appears to be too simple to > work. My immediate thought regarding that was "well, why would I create > a system that makes my life harder?", and as you say it's a good problem > to have. > It was great to see the same blank stare in the crowd that I saw on my own face, after the first example. It is just one of those reactions to a new, great paradigm. It takes a while to believe, and then finally see how such a model can be this clean and encapsulated. > However, the more I thought about it and listened the more I realised also > that this is actually a crucial problem that the examples need to overcome. > True. I think there simply aren't enough examples "in the middle" in terms of difficulty and demonstrable use of the model. > As a result, I've decided that at some point soon, I'll put together a > relatively large example regarding a complex useful application which was > put together in a day (about 8 hours really), but exercises a large > collection of components, preferably from the ground up. > That would be wonderful. It would be very helpful, I think, to demonstrate how a new device interface, say PySerial, PyUSB, or whatever, is properly placed in the model: Where the files are placed to make them accessible through the devices module, and how it's properly wrapped in a component to make use of an inbox and outbox, etc. This would be great, IMHO. > Specifically I'm actually thinking of this application: > > * http://www.kamaelia.org/SpeakAndWrite > > ... which is designed to assist a small child to learn to read and write. > (I had a specific small child in mind - who loves it incidentally. Writing > words on a tablet PC, and getting yes/no & what you wrote said back to > you is _really_ fun if you're 5 :) > It looks really awesome, and gives me ideas about a possible implementation of Upstage in Kamaelia, using Festival for voice control of characters, and Flash for animation. Not sure if this was in the tutorial, but: http://upstage.org.nz/blog/ I went to NZ last year and made friends with these people. It's currently in Twisted, and I'd love to somehow get the time, energy and developers to rewrite it in Kamaelia. This is used as an educational tool throughout the world, and was funded by the Australian gov't. It's interesting, very complex, and should be easier to modify and enhance, in my opinion. Twisted is killing it's progress as open source, since only one guy knows it well enough to maintain it, and is a busy college student. Whaddayasay we do an Upstage implementation as a complex example? The only hairiness is the Flash interface, but we can pluck that straight out of the existing source code. I bet it would not be that horrible, and would be the size of about one tenth of the existing Twisted code. * big stupid, hopeful grin * Thanks again, this is great fun! Gloria --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
