[04:25] *** Lawouach_ has joined #kamaelia

[07:12] *** vmlemon_ has joined #kamaelia

[08:08] *** vmlemon_ has joined #kamaelia

[08:54] *** Uraeus has joined #kamaelia

[08:56] *** Uraeus_ has joined #kamaelia

[09:06] *** Uraeus__ has joined #kamaelia

[10:36] *** vmlemon_ has joined #kamaelia

[10:46] *** MS- has joined #kamaelia

[10:47] < MS-> For those who may note have seen it, the kamaelia videos are now available on blip.tv

[10:47] < Lawouach_> cool

[10:47] < MS-> Details: http://groups.google.com/group/kamaelia/msg/ff6bcad3804106fa

[10:48] < MS-> Process of transcoding here:

[10:48] < MS-> http://yeoldeclue.com/cgi-bin/blog/blog.cgi?rm=viewpost&nodeid=1246925071

[10:48] < Lawouach_> I saw that on planetpython yeah

[10:48] < MS-> I thought that a nice way of answering lots of incoming questions :)

[10:49] < vmlemon_> Heh, http://holgr.com/blog/2009/07/07/about-licenses-photos-and-online-mobs/

[10:49] < vmlemon_> Classy

[11:11] < MS-> OK, uploading from work is a MUCH better idea overall.

[11:12] < MS-> 783.80 kB/s

[11:33] < MS-> aa_: your tutorial is now fully uploaded to blip.tv. I'll let you know when it's transcoded.

[11:33] < MS-> At some point though, I'll sit down and re-record it, since as you noted it's not very photo-genic

[11:33] < MS-> Though if walked through with a camera it would probably work well.

[11:47] < Lawouach_> arggh

[11:48] < Lawouach_> Selector component has some very hurtful pauses

[11:48] < Lawouach_> way too long for high load

[11:49] < Lawouach_> it took me some time but finally traced it down to a nasty self.payse(0.5) in the Selector component

[11:50] < Lawouach_> on my local machine using the loopback I'm not on a 15ms for a ping/pong message (XMPP) when I used to be at 110ms

[11:50] < Lawouach_> purely due to that pause

[11:51] < MS-> really?

[11:52] < Lawouach_> yeap

[11:52] < Lawouach_> look line around 339 of the selector component

[11:52] < MS-> you mean inside here:

[11:52] < aa_> MS-: wow thanks

[11:53] < MS-> elif not self.anyReady():

[11:53] < MS-> aa_: You're welcome

[11:53] < Lawouach_> MS-: yes

[11:53] *** aa_ is having one of those stamped on his iphone costing 400 quid days

[11:53] < Lawouach_> I've switched from 0.5 to 0.01

[11:54] < Lawouach_> and I have much better results

[11:54] < MS-> That's really weird

[11:54] < Lawouach_> why is that?

[11:55] < MS-> well, that branch should only be entered if there's nothing to call select on.

[11:55] < MS-> and if there's no data in an inbox

[11:55] < MS-> Oh.

[11:55] < MS-> I wonder

[11:56] < MS-> Logic is

[11:56] < MS-> if len(readers) + len(writers) + len(exceptionals) > 0:

[11:56] < MS-> #do select stuff

[11:56] < MS-> elif not self.anyReady():

[11:56] < MS-> # no readers, writers, or anything - wait a few moments just in case

[11:56] < MS-> But, I'm wondering what's up with the pause

[11:58] < MS-> It *should* wake up instantly

[11:58] < Lawouach_> hang on

[11:58] < MS-> (even reading Axon.ThreadedComponent)

[11:58] < Lawouach_> I'm wondering as well if I'm correct here

[11:58] < Lawouach_> grumble

[11:58] < Lawouach_> shouldn't be changing more than one parameter at a time

[11:58] < Lawouach_> let me start over

[11:58] < Lawouach_> sorry

[11:59] < MS-> np

[11:59] < Lawouach_> BTW, http://pastebin.ca/1486905

[11:59] < Lawouach_> I've added a couple of print statements in Microprocess

[11:59] < Lawouach_> they are quite valuable to find out which component takes time

[11:59] < Lawouach_> a lot of traces but that's helping nonetheless

[12:00] *** MS- nods

[12:00] < Lawouach_> just GYI ;)

[12:00] < Lawouach_> FYI

[12:00] < MS-> There's somewhere in sketches a component that will tell you which component is taking up time btw

[12:00] < MS-> ie a bit like top

[12:01] < Lawouach_> handy

[12:01] < MS-> http://kamaelia.googlecode.com/svn/trunk/Sketches/MH/Introspection/Profiling.py

[12:05] < Lawouach_> right

[12:05] < Lawouach_> actually found the culprit

[12:05] < MS-> Really ought to add that Profiler into core somewhere sensible

[12:05] < MS-> Probably into Axon itself

[12:06] < Lawouach_> nope

[12:06] < MS-> Or with the introspection components

[12:06] < Lawouach_> not even a pb with my code nor yours

[12:06] < Lawouach_> I'm using ejabberd

[12:06] < MS-> And that's the problem ?

[12:06] < Lawouach_> and there is a throughput limitor

[12:06] < Lawouach_> which by default is rather low

[12:06] < Lawouach_> too low

[12:06] < MS-> Ah.

[12:06] < Lawouach_> by increasing it a bit I'm having normal results

[12:07] < Lawouach_> sigh :)

[12:07] < MS-> So the bug is the code is sufficiently capable, it's hitting limits in a seperate system ?

[12:08] < Lawouach_> yes

[12:08] < Lawouach_> the code actually runs fine

[12:08] < MS-> I can live with that sort of bug :)

[12:08] < Lawouach_> eh eh :)

[12:08] < Lawouach_> I'm actually pusing teh whole stack rather hard

[12:08] < Lawouach_> and I'm rather pleased with the performances I see from it

[12:08] < Lawouach_> at least in the constraints I have

[12:08] < MS-> That is useful to do and nice to hear :)

[12:12] < Lawouach_> no doubt

[12:12] < Lawouach_> It's funny "no doubt" would be an exception to the "no TERM+s" rule?

[12:12] < Lawouach_> like "no worries"

[12:12] < Lawouach_> or is my English wrong again?

[12:13] < MS-> I'm not sure I understand the ''' "no TERM+s" rule'''

[12:13] < MS-> :)

[12:13] < MS-> I've yet to see a situation where your english is wrong for what it's worth :)

[12:13] < Lawouach_> thanks

[12:14] < Lawouach_> Well, I've always heard things like "no worries" rather than "no worry"

[12:14] < Lawouach_> where the term following "no" is plural

[12:14] < Lawouach_> not singular

[12:14] < MS-> Ah, I see

[12:15] < MS-> I think you're right, most things can be plural or would be plural there

[12:15] < MS-> but you wouldn't say "no doubts"

[12:15] < Lawouach_> fair enough

[12:15] < Lawouach_> we have exceptions too

[12:16] < Lawouach_> in fact we often say "The exception makes up the rule"

[12:16] < MS-> English has everyone's exceptions

[12:16] < Lawouach_> eh eh

[12:16] < MS-> Like i after e except after c is patently false

[12:16] < Lawouach_> I've learnt that yeap

[12:16] < MS-> I gave up on it years ago, and then decided to play with grep and /usr/dict/words

[12:16] < MS-> and felt rather justified at getting it wrong :)

[12:18] < Lawouach_> heehee

[12:19] < MS-> well, I just failed the UK citizenship test

[12:19] < MS-> http://www.ukcitizenshiptest.co.uk/ - 12 out of 24

[12:20] < Lawouach_> let's see

[12:20] < Lawouach_> darn it's slow

[12:21] < Lawouach_> right we'll see later, once I've managed to respond the first question

[12:21] < Lawouach_> ahem

[12:23] < MS-> heh :)

[12:23] < MS-> I got the first question wrong :)

[12:30] < Lawouach_> :)

[12:31] < Lawouach_> I'm doing some various tests against ejabberd and my XMPP lib

[12:32] *** MS- nods

[12:32] < MS-> I suspected that was the case

[12:32] < Lawouach_> I'm setting one XMPP service using headstock

[12:32] < Lawouach_> :)

[12:32] < MS-> I'd be interested in reading a summary of that at some point.

[12:32] < Lawouach_> a XMPP component as per the spec is a service which acts as an extension of the server

[12:33] < Lawouach_> so if you send a message/stanza to that service, the servers forwards it to the component

[12:33] < Lawouach_> usually they are written in erlang and loaded as part of ejabberd

[12:33] < Lawouach_> but you can write them in anything as long as you follow XEP 114

[12:33] < MS-> service as in XMPP service or service as in kamaelia service ?

[12:33] < Lawouach_> which headstock does

[12:33] < MS-> Ah, OK

[12:33] < Lawouach_> XMPP service

[12:33] < MS-> cool

[12:33] < Lawouach_> yes

[12:34] < Lawouach_> well by stressing with 200 clients, I'm reaching between 15000 and 20000 messages per second

[12:34] < Lawouach_> XMPP messages

[12:34] < MS-> Through what sort of hardware ?

[12:34] < MS-> That sounds good :)

[12:35] < Lawouach_> not too shaby for some code that hasn't been really optimised yet

[12:35] < Lawouach_> well the hardware is good

[12:35] < MS-> Indeed :)

[12:35] < Lawouach_> 4 cores

[12:35] < Lawouach_> 4Gb of RAM

[12:35] < MS-> Is any of the code using multiple cores ?

[12:36] < Lawouach_> well I think yes

[12:36] < MS-> cool

[12:36] < Lawouach_> i'm actually starting 4 Python processes using a bash script

[12:36] < Lawouach_> each running 50 XMPP clients in its own Axon scheduler

[12:36] < MS-> Ah :)

[12:36] < MS-> That will always work too :)

[12:36] < Lawouach_> :p

[12:37] < MS-> bash is underrated

[12:37] < Lawouach_> I actually managed around 25000 stanza/s

[12:37] < Lawouach_> indeed

[12:38] < MS-> I have no real basis for comparison, but those do sound like good numbers

[12:38] < Lawouach_> well I don't have yet basis for comparison either

[12:38] < Lawouach_> I need to write the same piece of service in erlang

[12:38] < Lawouach_> that'd be the reference

[12:39] < MS-> I'm certain that that would show that kamaelia still has some way to go.

[12:40] < Lawouach_> well i'm sure we could get better performances if I was to clean up my code and optimise it a bit, coupled with a better scheduler would help as well

[12:40] < Lawouach_> I think Kamaelia has plenty to go

[12:42] *** MS- nods

[12:42] < MS-> Now, if the GIL was removed and threadedchassis was implemented though, then that would open up a much nicer model for coding for multicore

[12:43] < Lawouach_> yeah well i'll bet on bash for now then

[12:43] < Lawouach_> :)

[12:45] *** salmon_ has joined #kamaelia

[12:45] < MS-> Indeed :)

[12:50] *** eikenberry_ is now known as eikenberry

[13:36] < Lawouach_> oh Kamaelia.org is down

[13:58] < MS-> is it?

[13:58] *** MS- looks

[13:58] < MS-> OK, host itself is up

[13:58] *** MS- is logged into it

[13:58] < MS-> (132.185.142.2)

[13:58] < MS-> As is the machine that serves its DNS

[13:59] < MS-> local lookup here (on a different network from either) succeeds

[13:59] < MS-> http://downforeveryoneorjustme.com/www.kamaelia.org

[13:59] < MS-> says

[13:59] < MS-> It's just you. http://www.kamaelia.org is up.

[14:31] *** Lawouach has joined #kamaelia

[14:31] < Lawouach> back

[14:31] *** Davbo has joined #kamaelia

[14:32] < Lawouach> don't know if this is just me but the sound isn't synchronised on the first blip video

[14:32] < MS-> It seems to be like that with the transcoding on blip. The original video is synced, but something blip have done is wierd.

[14:32] < Lawouach> :/

[14:36] < MS-> yep, just replaying it here, and the AV is synced, but the flash isn't

[14:36] < MS-> (ie replaying the .avi file and that's synced, but the flash file isn't)

[14:37] < MS-> Though intriguing, retrying playing back with mplayer rather than ffplay shows a desync

[14:37] < MS-> With the video getting ahead

[14:39] < MS-> Very odd

[14:54] < MS-> Wonder why one video will play in sync with one player and *not* in sync with another

[15:12] < MS-> retrying with mencoder, now that I know what options result in blip.tv not exploding

[15:13] < MS-> If that works OK, I'll come back and redo the tutorials

[15:13] < MS-> I suspect ffmpeg is doing something "wrong"

[15:14] < MS-> Probably need a longer chunk thinking about it

[15:18] *** Davbo_ has joined #kamaelia

[15:34] < MS-> first test-sync test seems pretty good

[15:34] < MS-> testing with a longer chunk of video now

[15:34] < MS-> http://blip.tv/file/2330630 is the first test

[15:35] < Davbo_> http://www.reddit.com/r/Python/comments/8yysl/kamaelia_an_intuitive_approach_to_concurrency/

[15:35] < Davbo_> if it gets many more upvotes you need to expect a spike in traffic MS-

[15:35] < MS-> :)

[15:35] < Davbo_> just a warning :)

[15:36] < MS-> That machine was being used for uploading video to blip earlier - ~800KBytes/s

[15:36] *** Davbo_ has upvoted

[15:36] < MS-> If it breaks beyond that, that's fine :)

[15:36] < Davbo_> hehe

[15:40] *** eikenberry upvoted

[15:42] *** MS- fixes the source & SVN text

[15:42] < MS-> ;)

[15:43] < MS-> Also added a link right next to the download section to the europython tutorial notes

[15:44] < MS-> thanks for upvoting :)

[15:48] < MS-> Davbo_: You may be gratified to hear btw that I used your paint program to show that kamaelia supports multiple processes last week :)

[15:49] < MS-> ie as a concrete example of something that *must* be using multiple processes

[15:52] < Davbo_> pleased to hear it, I'm going to write a prototype of what I'm working on over summer in Kamealia to see if its better than the existing threaded method

[15:52] < Davbo_> can't really say much about it unfortunately

[15:53] < Davbo_> might be a nice use case though

[15:54] < MS-> That's fine. If it's useful, that's what matters (to me). If it helps that's good. if it doesn't that's useful to know

[15:57] < MS-> Don't forget BTW, that you "own" the namespace Kamaelia.Apps.DK

[15:59] < MS-> I think the av sync in this works quite well: http://blip.tv/file/2330727

[16:00] < MS-> OK, I'm happy with that

[16:00] < MS-> That's much better. Plan then: do the keynotes, then redo the tutorials, then the sessions, then the lightning talks

[16:00] < MS-> back later

[16:00] < MS-> (tram)

[16:01] *** MS- has parted #kamaelia

[18:14] *** MS- has joined #kamaelia

[18:14] < MS-> back

[19:12] < aa_> ms, anyone written a two-way rpc for kamaelia?

[19:12] < aa_> MS-: ^^

[19:12] < MS-> json-rpc

[19:12] < MS-> Yes, they have. I ought to put it into Kamaelia.Apps.

[19:12] < MS-> Thanks for reminding me :)

[19:13] < aa_> MS-: where is it, does rasjid hang out here?

[19:14] < MS-> He mailed it through a little while before europython, whilst I was rapidly doing lost of stuff.

[19:14] < MS-> He's posted to the list a couple of times.

[19:14] < MS-> And offered to contribute it

[19:14] < aa_> MS-: I have to convince everyone to let me remove dbus from pida

[19:15] < aa_> and replace it with something based on kamaelia

[19:15] < aa_> I think we have ronny convinced

[19:15] < MS-> :-)

[19:15] < aa_> so go on, cough up the code please :P

[19:20] < aa_> MS-: how do you serialize messages?

[19:21] < MS-> I didn't write it - rasjid did

[19:21] < MS-> I suspect as json messages

[19:22] < MS-> hold on, I'll check it in

[19:26] < MS-> http://code.google.com/p/kamaelia/source/detail?r=6203

[19:26] < aa_> awesome and tidy code

[19:27] < MS-> http://code.google.com/p/kamaelia/source/browse/trunk/Sketches/Contrib/jsonrpc/ - perhaps a better view

[19:27] < MS-> :-)

[19:29] < MS-> I need to shift the components into a namespace in Kamaelia.Apps.JsonRpc though

[19:29] < MS-> Since that'd allow reuse of any parts of the code in other applications easier

[19:29] < MS-> But it's really cool :)

[19:30] < aa_> seems there are two versions, one is bd

[19:31] < aa_> you know if the bd one supports async signal-type things?

[19:31] < MS-> "The bdjsonrpc.py file is the main code"

[19:31] < MS-> "It uses jsonrpc.py which is currently Roland Koebler's code"

[19:31] < aa_> oh

[19:32] < MS-> FWIW, I don't know, but I'm happy to give the code a home

[19:32] < MS-> I think it should be useable in an async way

[19:33] < MS-> But even if it can't directly, I suspect that K should make it easier to decouple.

[19:34] < MS-> I'll forward you rasjid's mails

[19:36] < MS-> (just checking that I'm not forwarding anything I shouldn't before sending)

[19:38] < MS-> OK, sent

[19:48] < aa_> thanks

[20:01] *** salmon_ has joined #kamaelia

[21:09] < MS-> aa_: Nearly finished packaging up Rasjid's code btw

[21:20] < MS-> OK, packaged up, installable tar ball here:

[21:20] < MS-> http://www.kamaelia.org/release/Kamaelia-JsonRPC-0.0.1.tar.gz

[21:20] < MS-> And details sent to the mailing list

[22:08] *** MS- has parted #kamaelia