[07:23] *** Uraeus has joined #kamaelia

[10:13] < MS-> having a lazy day

[10:24] < vmlemon> Hi

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

[13:04] *** vmlemon has joined #kamaelia

[13:25] *** vmlemon has joined #kamaelia

[13:30] *** vmlemon has joined #kamaelia

[19:21] < ronny> MS-: got any kamaelia+gtk examples?

[19:31] < MS-> Sorry, I haven't - but aa_ has one.

[19:32] < MS-> I'm actually debugging Axon.Handle at the moment, since that should be the preferred mechanism for talking to gtk from kamaelia

[19:32] < MS-> But there seems to be a bug in Axon.Handle, which is rather annoying.

[19:33] < MS-> Once I have that debugged, then I'll put up a hello world of using GTK & kamaelia

[19:40] < ronny> hmk

[19:41] < ronny> MS-: any plans to support the glib mainloop as base of io watching/sheduling?

[19:42] < MS-> Well, given I don't currently use glib myself, that would be a bit of a leap :-) However...

[19:42] < MS-> the scheduler can be run as follows:

[19:42] < MS-> (grabbing something to c&p)

[19:42] < MS-> OK, a number of older pieces of kamaelia code do this:

[19:42] < MS-> scheduler.run.runThreads()

[19:43] < MS-> That final method runThreads()

[19:43] < MS-> Has this as its body:

[19:43] < MS-> def runThreads(self,slowmo=0):

[19:43] < MS-> for i in self.main(slowmo,canblock=True): pass

[19:44] < MS-> Clearly that means you could drive the scheduler yourself from another mainloop - eg glib's mainloop

[19:44] < MS-> should you wish to do so

[19:44] < MS-> But the preferred technique (IMO) would be to run the axon scheduler in the background, and then communicate with axon components running in the background using axon.handle

[19:45] < MS-> The scheduler will happily run in a non-foreground thread you see

[19:46] < MS-> cf http://kamaelia.googlecode.com/svn/trunk/Code/Python/Axon/Examples/Handles

[19:47] < MS-> There's an issue there which I'm currently investigating which I think is due to me being rather OTT recently in cleaning up component shutdown (!)

[19:49] < MS-> (both those examples work fine for example)

[19:51] < MS-> That said, I have a minimal example for debugging now. I'd suggest asking that question again in a couple of days :)

[19:51] Reply: Hi, I'm a bot. I've been put here to answer faq's and log the channel.

[19:51] Reply: I've not really been configured yet, so I won't do much here yet :-)

[19:53] < MS-> kamlogbot: poke

[19:53] Reply: Not the eye! Not the eye!

[20:03] < ronny> hmm, there are some possible painfull loopholes i see about stuff like WaitForData

[20:03] < ronny> i need to do some diggin before i can tell if there is a good way not to do polling all the time

[20:03] *** MS- nods

[20:04] < MS-> If I used GTK I could probably tell you what the best way of doing that was, but it's not been an area I've needed to look into

[20:34] < MS-> OK, there was a small race hazard exercised by Axon.background and threaded components, which is now resolved cleanly. Probably handful of similar issues in Axon.Handle to deal with, but that was step

[20:34] < MS-> #1

[20:34] < MS-> :)

[21:12] < ronny> MS-: will do some light diging when im not learning for my exams, and some deep digging after my exam on 23.07.

[21:12] < MS-> cool :)

[21:14] < MS-> woah. unexpected event. gtk appears to kill regular python threads?

[21:15] < MS-> Yes, it does

[21:15] < MS-> that's plain evil

[21:15] < ronny> MS-: what? it shouldnt do that

[21:15] < ronny> MS-: we do use regular python threads in tonns of places in pida, seems fine there

[21:16] < aa_> threads_init called?

[21:16] < MS-> http://pastebin.org/1243

[21:17] < MS-> When run, you get this behaviour:

[21:17] < MS-> http://pastebin.org/1244

[21:17] < aa_> MS-: when using threads with gtk you need to call gtk.gdk.threads_init()

[21:17] < MS-> At the point the window appears, no more "running" messages are displayed

[21:17] < MS-> aa_: That's plain evil :)

[21:18] < aa_> MS-: that initializes the multithreaded bits

[21:18] < aa_> MS-: call it once, and yes its evil

[21:18] < MS-> Ahh much better

[21:18] < MS-> cool

[21:18] < MS-> I thought it was a bug in Axon

[21:20] < MS-> OK, http://pastebin.org/1245 works as I'd expect

[21:20] < ronny> aa_: is it really necessary if no other thread writes on the gui?

[21:22] < MS-> well, http://pastebin.org/1243 freezes every background thread, http://pastebin.org/1245 doesn't

[21:22] < MS-> That's useful to know

[21:23] < MS-> That's actually quite nice. I thought it was an axon bug and it actually a GTK foible.

[21:23] < MS-> aa_: Thank you :-)

[21:23] < ronny> hmm, aa_ ftw :)

[21:24] < MS-> Well, a day you learn something is a good day :)

[21:25] < aa_> ronny: it's absolutely necessary

[21:29] < ronny> aa_: i think it also kills some kittens if one calls it twice

[21:30] < MS-> And doing this also fixes all the other bits I thought were axon bugs

[21:36] < MS-> OK, this is a minimal version that shows how to send a message to a kamaelia component when a button is clicked in GTK: http://pastebin.org/1249

[21:36] < MS-> That component happens to forward a message over a network connection to a server, which in this case logs the event

[21:37] < MS-> That server looks like this: http://pastebin.org/1250

[21:38] < MS-> and that's the example on pages 58-60 of the tutorial notes :-)

[21:38] < MS-> I didn't cover that in the session because I thought Axon.Handle was borked

[21:41] < MS-> yay, really pleased with that. That's a good nights work

[21:45] < ronny> ++

[21:50] < ronny> night

[21:51] < MS-> night

[22:32] < MS-> OK, I'm off to sleep

[22:32] < MS-> I've rummaged around inside filterpype now properly and discovered 2 things:

[22:33] < MS-> a) it really is a python-style co-routine system rather than based on genuine co-routine ideas

[22:33] < MS-> that means it's inherently push based (as noted in it's own source) and limited to "push only" topologies in practice

[22:34] < MS-> Also, this means that filters in its system are all pushing control flow as well as data flow

[22:34] < MS-> meaning that multiple flows in a single system would be hard at best to implement

[22:34] < MS-> if possible at all

[22:34] < MS-> It's actually significantly more limited and limiting than I gave it credit for in the session where it was being described.

[22:36] < MS-> That also explains, as a result, why most of the actual filters in the system are almost all largely written in callback style (meaning it could be done in a nicer way as well...)

[22:36] < MS-> since otherwise, someone working with it risks breaking it's execution structure quite hard

[22:37] < MS-> It also explains the fundamental misunderstanding of kamaelia that was made by the authors of it, when combined with their misunderstanding of how unix pipelines actually work in practice

[22:38] < MS-> That said, they've produced an interesting solution to a real world problem that they had, even if their talk didn't get that over well.

[22:43] < MS-> This does open up the intriguing thought that it should be possible to convert (or assimilate) all the filterpype filters as kamaelia components and make them more useful in the process.

[22:44] < MS-> Not something for the moment, but something for another day maybe.

[22:45] < MS-> Interestingly they get close conceptually to some aspects

[22:45] < MS-> seeing stuff like this:

[22:45] < MS-> self.send_on(packet.clone(), 'branch')

[22:45] < MS-> self.send_on(packet, 'main')

[22:46] < MS-> BUT, this isn't an asynchronous send_on

[22:47] < MS-> since it actually passes control to the next filter named branch, rather than sends it a message

[22:47] < MS-> which eventually returns

[22:47] < MS-> and then it calls the other branch

[22:48] < MS-> So I don't know if it would be even vaguely wise to wrap their filters as components :-/

[22:49] < MS-> Anyway, interesting. The amount of interest there did make me think that it might be worth offering talks & (better) tutorial next time round, with different focusses for those with different interests.

[22:49] < MS-> anyway, sleep

[22:49] < MS-> night