[04:46] *** jlei_ has joined #kamaelia

[06:10] *** vmlemon__ has joined #kamaelia

[06:10] *** vmlemon__ is now known as vmlemon_

[06:30] < Lawouach_> morning

[06:30] < jlei_> hi

[08:21] *** mhrd-afk is now known as mhrd

[08:21] < mhrd> morning

[08:30] < mhrd> wrt multicast bind-vs-connect; I'm actually not entirely clear myself ... I based my code on some by MS- ... he's your man on this :)

[08:36] *** mhrd has parted #kamaelia

[08:43] *** mhrd has joined #kamaelia

[09:17] *** vmlemon__ has joined #kamaelia

[09:17] *** vmlemon__ is now known as vmlemon_

[09:20] < vmlemon_> Hi

[09:31] *** orphans has joined #kamaelia

[10:39] *** Davbo has joined #kamaelia

[10:39] < Davbo> Another exam done

[10:39] < Davbo> 1 more to go

[10:50] *** bcarlyon|laptop has joined #kamaelia

[11:05] *** vmlemon__ has joined #kamaelia

[11:05] *** vmlemon__ is now known as vmlemon_

[11:20] *** Uraeus has joined #kamaelia

[11:33] *** bcarlyon|laptop has joined #kamaelia

[11:56] *** MS- has joined #kamaelia

[11:56] < MS-> (back)

[11:57] < MS-> (for a bit)

[11:57] < MS-> 900 spams due to a day out for work.

[11:57] < MS-> 10/11 hours travelling on trains

[11:57] < MS-> < /grumble>

[12:01] < orphans> hey MS-

[12:04] < Lawouach_> 'lo

[12:06] < orphans> afternoon Lawouach

[12:16] < orphans> hum, pretty sure the answer to this is going to be no: is there any way to have a passthrough link where you get to mess around with the data before it gets passed on?

[12:16] < orphans> or is it an extra inboxes and outboxes job?

[12:17] < Davbo> Afternoon all

[12:19] < orphans> hey Davbo

[12:25] < Davbo> Got a bit of free time today between revision MS-, trying to draw from second window onto the second

[12:25] < Davbo> not sure what's going on though

[12:25] < Davbo> commited if you could have a look sometime :-)

[12:30] < Lawouach_> orphans: you got it right

[12:31] < Lawouach_> you can't have both at the same time

[12:31] < Lawouach_> passthrough earns its name :)

[12:32] < orphans> k, cool. bah, lack of def link(in, out, kindaSortaPassThroughWithABitOfFudgingAround):

[12:32] < orphans> :)

[12:33] *** orphans breaks paradigms

[12:34] < mhrd> There's also Kamaelia.Util.PureTransformer if you just want to apply a function to data going through

[12:34] < Lawouach_> PureTransformer, hmm, does it come with the pretty lady like in the movie?

[12:34] < Lawouach_> if not just move along

[12:36] < orphans> tbh more inboxes and outboxes make more sense

[12:40] < mhrd> orphans: ooi whats the context here?

[12:42] < orphans> getting the UDP stuff working with CSA (slightly different to your version)

[12:43] < orphans> I've altered it so that if you're doing sendto you give CSA a (msg, (address, port)) tuple - it lets you do stuff like TargettedPeer where you don't know the address and port before you make the CSA

[12:45] < orphans> but for PostboxPeer you need to be able to append the (address, port) tuple to the message somehow - hence fudging with the message on it's way through

[12:48] < orphans> I'm also making some of the code a bit more generic - it seems crazy having the same 300 loc in TCPClient, MulticastTransceiver and all of the UDP components

[12:48] *** Lawouach_ can only welcome such idea :)

[12:49] < orphans> so yeah, I'm knee deep in code :)

[12:49] < orphans> think I'm over the worst of it though...

[12:50] < orphans> < = lunch

[13:02] < vmlemon> Hi

[13:03] < MS-> "is there any way to have a passthrough link where you get to mess around with the data before it gets passed on?"

[13:03] < MS-> No, you need a component for that.

[13:03] < MS-> Kamaelia.Util.PureTransformer might be what you want though

[13:03] < MS-> Davbo: (for logs) I'll take a look later today

[13:04] < MS-> Probably worth mentioning that passthrough these days actually collapses the boxes into one

[13:04] < MS-> And given the underlying implementation of normal components uses a list as the concrete storage

[13:04] < MS-> As soon as you send() the message it's instantly recv()able

[13:05] < MS-> "but for PostboxPeer you need to be able to append the (address, port) tuple to the message somehow"

[13:06] < MS-> Pipeline(

[13:06] < MS-> Datasource(),

[13:06] < MS-> PureTransformer(lambda X: (X, (address,port))),

[13:06] < MS-> dataSink()

[13:06] < MS-> )

[13:06] < MS-> "I'm also making some of the code a bit more generic - it seems crazy having the same 300 loc in TCPClient, MulticastTransceiver and all of the UDP components"

[13:07] < MS-> If you have the functionality known to work correctly in all cases in all 3 components, then it makes sense to consolidate (if the consolidation makes sense)

[13:07] < MS-> If you don't know if it works correctly, then doing that before you know it does is unwise

[13:07] < MS-> Since otherwise you have 3 different areas where a bug will show itself up if you consolidate

[13:07] < MS-> Which means 3 completely different sets of symptoms

[13:07] < MS-> for the same cause

[13:08] < MS-> (kinda the problem with unrestricted use or overuse of inheritance in general)

[13:08] < MS-> (and a risk for something like Kamaelia by definition too)

[13:09] < MS-> in other news, I have a working webcam component

[13:10] < MS-> Which is quite neat :)

[13:11] < MS-> Currently spits out only RGB pygame surfaces, since that what the underlying lib does.

[13:11] < MS-> So I've put in a request for YUV (or will extend the bindings to dump that)

[13:11] < MS-> so that the dirac components can be used there

[13:11] < Lawouach_> cool

[13:13] < vmlemon> o.O http://www.newscientist.com/article/mg15420771.600-frog-defies-gravity.html

[13:17] < MS-> http://news.bbc.co.uk/1/hi/sci/tech/959453.stm

[13:18] < MS-> http://www.hfml.science.ru.nl/froglev.html

[13:18] < MS-> http://www.hfml.ru.nl/pics/Movies/frog.mpg

[13:19] < vmlemon> Hah, "Three accident and emergency doctors from Glasgow picked up an Ig for their work on the dangers posed by collapsing toilets."

[13:21] *** Chong- has joined #kamaelia

[13:21] < Chong-> Afternoon, all

[13:22] < vmlemon> Hi Chong-

[13:22] < Chong-> hey vmlemon

[13:24] < Chong-> vmlemon : have you tried Fedora 9?

[13:24] < vmlemon> Not yet

[13:24] < vmlemon> Is it any good?

[13:24] < Chong-> I have not too :-) so not sure

[13:25] < mhrd> orphans: if I understand what you're trying to achieve: rather than fiddling with inboxes and outboxes, the solution I've found works well is to make a wrapper; for example:

[13:25] < mhrd> suppose NewCSA is a CSA that accepts (dest,payload) tuples:

[13:26] < mhrd> def FixedDestCSA(dest):

[13:26] < mhrd> .. return Pipeline(

[13:26] < mhrd> .. PureTransformer(lambda: payload: (dest, payload)),

[13:26] < mhrd> .. NewCSA(),

[13:26] < mhrd> .. )

[13:27] < mhrd> Iirc we named that kind of thing a Prefab

[13:27] < mhrd> def NonFixedDestCSA(): return NewCSA()

[13:39] < MS-> Yep, prefab

[13:55] < orphans> cheers MS- and mhrd, all looks interesting and good. I've gotta go out for a couple of hours, but this evening I'll post something up the the list about the changes and commit it so you can see whether I'm horribly abusing inheritance.

[13:55] < orphans> (it's quite possible...)

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

[14:11] *** Davbo reads logs

[14:11] < Davbo> thanks MS- :-)

[14:11] < Davbo> Just come back to it now

[14:11] < Davbo> maybe i can work it out

[14:17] < Davbo> ah

[14:17] < Davbo> tuples are breaking when I send them through the ProcessGraphline MS-

[14:18] < MS-> "commit it so you can see whether I'm horribly abusing inheritance." - if you think you may be, you probably are

[14:18] < MS-> in what way?

[14:18] < MS-> Do you have a trivial example/testcase ?

[14:18] < Davbo> passing through ('circle',) then getting it to print it simply prints circle

[14:18] < Davbo> >>> x = ("test",)

[14:18] < Davbo> >>> print x

[14:18] < Davbo> ('test',)

[14:18] < Davbo> not like that

[14:19] < Davbo> it's breaking them up, if that makes sense

[14:19] < MS-> No, not really. Need a test case :-)

[14:20] < Davbo> circle = ("circle",)

[14:20] < Davbo> self.send(circle, "outbox")

[14:20] < Davbo> Which arrives in WINDOW2's inbox and it prints it but just prints "circle", seemingly going tuple -> string

[14:21] < Davbo> so I can't catch it with if isinstance(event, tuple): - I don't like this method but I'm testing things out still as you know

[14:23] < MS-> No, that's not a test case

[14:28] < mhrd> Davbo: can you commit a piece of code and tell us what to type and what output it will generate?

[14:29] < Davbo> Yes, of course

[14:30] < MS-> https://kamaelia.svn.sourceforge.net/svnroot/kamaelia/trunk/Sketches/MPS/pprocess/dk_bug_report_maybe.py

[14:30] < MS-> All the tests in that work

[14:33] < MS-> WINDOW1 = MagnaDoodle(bgcolour=(100,100,172),position=(0,0) ),

[14:33] < MS-> WINDOW2 = MagnaDoodle(bgcolour=(172,100,100),position=(200,0) ),

[14:33] < MS-> ("WINDOW1", "outbox") : ("WINDOW2", "inbox")

[14:33] < MS-> window1 forwards events to window2

[14:33] < MS-> window 1 is blue

[14:33] < MS-> window 2 is red

[14:33] *** j_baker has joined #kamaelia

[14:34] < MS-> In window 1, type "c"

[14:34] < MS-> Then draw

[14:34] < Davbo> Sorry I'm back

[14:34] < Davbo> let me just commit

[14:34] < MS-> In window 2, I get an error

[14:34] < MS-> if event.type == pygame.MOUSEBUTTONDOWN:

[14:34] < MS-> AttributeError: 'str' object has no attribute 'type'

[14:34] < MS-> However, I've got loads of tracing going

[14:34] < MS-> which shows this:

[14:34] < MS-> pwc:- SEND (('circle', (90, 95), 47.507894080878813), 'inbox') TO __main__.MagnaDoodle_6 . . self.put msg ('circle', (90, 95), 47.507894080878813) boxname inbox

[14:35] < MS-> Which is inside the processwrap component as it's in the process of being slung into the thread

[14:35] < Davbo> Okay, so: as MS- says if you press "c" in window1 (blue) and draw a circle

[14:36] < MS-> Davbo: this isn't really the best of test cases

[14:36] < Davbo> it'll complain and not do what's inside the block for handling tuples

[14:37] < Davbo> I'll just make a test component to clarify

[14:37] < MS-> pwc:- SEND (('circle', (69, 80), 79.649231006959511), 'inbox') TO __main__.MagnaDoodle_6 . . self.put msg ('circle', (69, 80), 79.649231006959511) boxname inbox

[14:37] < MS-> . SENT

[14:37] < MS-> HERE 'circle'

[14:37] < MS-> Is very strange

[14:38] < MS-> Since it's clearly showing ('circle', (69, 80), 79.649231006959511) to be sent

[14:38] < Davbo> Yeah

[14:38] < Davbo> I have a theory though MS-

[14:39] < MS-> I have a better one

[14:39] < Davbo> oh

[14:39] < Davbo> k

[14:39] < Davbo> :(

[14:39] < Davbo> ;-)

[14:39] < Davbo> Go ahead.

[14:39] < MS-> oh hold on

[14:39] < MS-> you go ahead first

[14:39] < Davbo> lol

[14:39] < MS-> I'm not so sure

[14:39] < Davbo> Well I had the problem with strings where the first letter was only being sent

[14:39] < Davbo> and now this with tuples

[14:40] < Davbo> that would mean only variable[0] is being sent, right?

[14:40] < MS-> close

[14:40] < MS-> I think it's to do with something else

[14:40] *** vmlemon__ has joined #kamaelia

[14:40] *** vmlemon__ is now known as vmlemon_

[14:41] < Davbo> >>> x = "this"

[14:41] < Davbo> >>> x[0]

[14:41] < Davbo> 't'

[14:41] < Davbo> >>> x= (1,5,3)

[14:41] < Davbo> >>> x[0]

[14:41] < Davbo> 1

[14:41] < Davbo> surely not coincidental

[14:41] < MS-> No, it's not

[14:41] < MS-> I completely and utterly missed it because I'm blind

[14:41] < MS-> It's to do with an optimisation of events handling in pygame

[14:42] < Davbo> hmm?

[14:42] < MS-> The event handler in pygame doesn't just send on event at a time

[14:42] < MS-> it sends a list of them

[14:42] < MS-> eg bunchs (lists) of mouse move events in one go

[14:42] < Davbo> I see

[14:42] < MS-> as a result that's why it has the following:

[14:42] < MS-> for event in self.recv("inbox"):

[14:43] < MS-> And *that's* where you code is going wrong :-)

[14:43] *** Davbo thought that was strange

[14:43] < MS-> It's shorthand for

[14:43] < MS-> Or rather this:

[14:43] < MS-> while self.dataReady("inbox"):

[14:43] < MS-> for event in self.recv("inbox"):

[14:43] < MS-> is shorthand for

[14:44] < Davbo> ahhh

[14:44] < Davbo> I get it

[14:44] < MS-> while self.dataReady("inbox"):

[14:44] < MS-> events = self.recv("inbox")

[14:44] < MS-> for event in events:

[14:44] < Davbo> Yeah

[14:44] < Davbo> Argh

[14:44] < Davbo> :-)

[14:44] < MS-> problem is "events" isn't what you want there

[14:44] < MS-> simplest solution:

[14:44] < MS-> doublebracket

[14:44] < MS-> ["clear"] --> [["clear"]]

[14:45] < MS-> Better solution: different inbox

[14:45] < Davbo> other boxes working now?

[14:45] < MS-> oh yes that

[14:45] < MS-> No

[14:45] < MS-> current solution would be to double bracket then

[14:46] < MS-> (I can't believe its this late in the day - been exhausted all day)

[14:46] < MS-> Stupid amounts of travelling yesterday

[14:46] < Davbo> Where you go?

[14:47] < Davbo> I had an exam at 9am this morning was up at 7:30 for the first time in moths

[14:47] < Davbo> s/moths/months

[14:47] < MS-> London & back yesterday. Wasn't worth it IMO, but they said it was mandatory at the last minute so I went

[14:47] < MS-> Trains were completely bust yesterday though

[14:48] < MS-> I left early and didn't get home until midnight

[14:48] < MS-> (6 hours of so for a 2-3 hour journey, more changes than normal etc)

[14:49] < Davbo> Ouch.

[14:49] < Davbo> On the bright-side (for me) there was a question on Pipelining in my exam

[14:49] < MS-> heh

[14:49] < Davbo> :-)

[14:50] < Davbo> (Instruction Pipelining though :-))

[14:50] < MS-> I remember one of my exam networking exam questions back from when I was at uni, which is still rather amusing (esp given where I work now)

[14:51] < MS-> "Imagine you are designing a system for putting Radio on the internet, outline the protocols and approach you would take, and what practical considerations you would take into account."

[14:51] < Davbo> What was the question?

[14:51] < Davbo> Ah

[14:51] < MS-> Or something like that

[14:51] < Davbo> Hehehe

[14:52] < MS-> I remember saying then that multicast wasn't really an option because it wouldn't get deployed

[14:52] < MS-> And it still isn't

[14:52] < MS-> So I suggested a self splitting distributed system

[14:52] < vmlemon_> The answer being "Write Kamaelia"? ;)

[14:53] < MS-> Something like this: https://kamaelia.svn.sourceforge.net/svnroot/kamaelia/trunk/Sketches/MPS/LUGRadio/SimpleSwarm.py

[14:53] < MS-> vmlemon_: turns out to be the answer ;)

[14:53] < MS-> Didn't know that then :)

[14:54] < MS-> Though then I still had the goal that kamaelia _currently_ looks like the best bet of answering

[14:54] < Davbo> Thanks for helping me out with that problem btw MS-

[14:55] < Davbo> I'll try doublebracketing now

[14:57] < Davbo> YAY :D

[14:59] < j_baker> MS-: There's a section in the python cookbook about zipping python files into a single executable on Unix using a shell script. Have you tried that? It seems kinda hackish to me.

[15:02] < Lawouach_> j_baker: why?

[15:02] < Lawouach_> I mean what are you doing?

[15:02] < Lawouach_> just curious :)

[15:03] < j_baker> Just trying to package my app up. It would be nice to have a toolchain that will work for Linux and OS X instead of using py2app and something else for Linux.

[15:03] < Davbo> MS-: Check the latest commit when you get chance :-)

[15:05] < Davbo> (and anyone else, just draw on the blue magnadoodle :-))

[15:07] < vmlemon_> Sounds exciting ;)

[15:08] < Davbo> It probably isn't, i'm just overly enthusiastic about my project ;-)

[15:08] < MS-> j_baker: I actually quite like that idea for distribution of code which has plugins on adesktop

[15:08] < MS-> Oh hold on, I've chatted about that before AAAAAAAAAAAAAAAAAAAAges back

[15:08] < MS-> It was based on reading something by effbot

[15:09] < MS-> It's something he's been doing for a while

[15:09] < vmlemon_> "Kamaelia Speak and Spell", anyone?

[15:10] < j_baker> I hadn't thought about that. It would be pretty easy to add code to it, wouldn't it?

[15:11] < MS-> Davbo: Looks alive

[15:11] < j_baker> Hold on, got to reboot.

[15:11] < MS-> vmlemon_: Oh that's not a bad idea actually

[15:12] < MS-> Oh, that's really tempting

[15:12] < MS-> That's quite simle to do as well

[15:12] < MS-> (I already have speech synthesis on two platforms you see)

[15:16] *** j_baker has joined #kamaelia

[15:16] < Davbo> I'm really happy with how well this works MS-

[15:16] < MS-> Davbo: Cool :-)

[15:16] < MS-> You've also written a multiprocess/multicore friendly desktop application

[15:17] < MS-> That's pretty rare at the moment :)

[15:17] < MS-> The hard part had nothing to do with multicore/multiprocess either

[15:17] < MS-> j_baker: http://tinyurl.com/47oaqt

[15:17] < MS-> From this thread : http://groups.google.com/group/comp.lang.python/browse_frm/thread/9b1d2e3780c2322c/0dcdc1d26fd64335?lnk=st&q=Python+Webstart+%3F#0dcdc1d26fd64335

[15:18] < MS-> I took a copy of effbot's mail message back then, but hadn't done anything with it and had nearly forgotten about it

[15:22] < j_baker> I'll have to try it out. It would be very helpful to be able to make just one executable for both Linux and the Mac. And that could also make installing wsgi apps fairly easy.

[15:22] *** Lawouach_ doesn't understand the concept of executable for Python usually

[15:22] < j_baker> Now I just have to worry about windows.

[15:23] < Lawouach_> I think I'm missing entirely what j_baker is doing and I should shut it :)

[15:24] < j_baker> Basically, you zip all your python files up and your pycs, then concatenate it with a shell script that runs python, unzips the code, and then runs a module within it as the main file.

[15:25] < j_baker> Now that I read that, that sounds a lot like cx_freeze.

[15:28] < Davbo> MS-: I might come back to it later, and make a start with another window / tool / colour selector. My exam on Friday is "the big Maths exam" so need to do plenty revisin'

[15:37] < Davbo> So i'll leave it at that for now, and go back to revising hyperbolics, imaginary numbers and all that fun stuff

[15:38] < j_baker> Wow... I am so glad I'm not you. What math class is that for?

[15:39] *** j_baker isn't good at "real" math

[15:40] < Davbo> They call it "Continuous Foundations" basically, what they want us to know before the second year

[15:40] < Davbo> There is a load of stuff in it though

[15:42] < Davbo> It's all pure maths then suddenly changes to probability and statistical stuff, like Gaussian distribution :-(

[15:46] < MS-> """Lawouach_ doesn't understand the concept of executable for Python usually

[15:46] < MS-> I think I'm missing entirely what j_baker is doing and I should shut it :)"""

[15:46] < vmlemon_> Hah

[15:46] < j_baker> Hmmmm... so it's kind of like calculus meets statistics meets discrete math? I kind of like that idea. Just get it all out of the way in one class, Davbo.

[15:47] < MS-> AIUI, the aim is an application that joe blogs can download and install, and run like they can any P2P or IM client

[15:47] < MS-> It then acts as their personal webserver which integrates with intermediaries to help them serve their local stuff to the world

[15:47] < MS-> even if they're behind a NAT and couldn't open a port if they tried

[15:47] < MS-> essentially

[15:48] < Lawouach_> crazy stuff

[15:48] < MS-> as well as able to download and install/run widgets locally

[15:48] < MS-> The widgets being essentially wsgi apps

[15:48] < Davbo> The upshot of it all is, we end up with a huge amount of stuff to remember. but the actual questions on the exam are never as difficult as the more focused exams (although they cover the whole syllabus )

[15:49] < MS-> I'd be amused if we could provide a hosting facility for google appengine apps, to allow them to be downloaded and run locally

[15:49] < MS-> But I think walking might be a good idea first

[15:49] < Davbo> That sounds cool though MS-

[15:50] < j_baker> Yeah, what MS- said. :) There's also a lead in to Prism there as well.

[15:50] < vmlemon_> Didn't someone do a similar thing with the official SD, ages ago?

[15:50] < vmlemon_> *SDK

[15:51] < j_baker> Which official SDK?

[15:51] < MS-> google gears

[15:51] < MS-> Not the same though

[15:51] < vmlemon_> The actual GAE one

[15:52] < MS-> Oh, I see

[15:57] < j_baker> MS- is there a place in the Kamaelia tree that I should put any WSGI apps that I write? Or should they stay outside the tree?

[15:58] < j_baker> Like should I put them under support, or just leave them in my sketches directory or under Apps? Or does it matter? :)

[15:59] < MS-> For the moment I would leave them under Apps until you have stuff working

[15:59] < MS-> under /Sketches rather

[15:59] < MS-> then migrate them to /Apps when you've got a clear idea of the requirements you'll have for them

[16:00] < MS-> I suspect that a common structure would be

[16:00] < MS-> moin.d

[16:00] < MS-> django.d

[16:00] < MS-> another.d

[16:00] < MS-> and inside each .d directory

[16:00] < MS-> put their required things

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

[16:00] < MS-> Putting them in .d's as well means that you can zip them up etc and then figure out how you want that to work

[16:02] < j_baker> Oh, I see. That's a pretty good idea. It eliminates all the having to put stuff in site-packages.

[16:19] < MS-> OK,

[16:19] < MS-> j_baker:

[16:19] < MS-> ~/tmp> find

[16:19] < MS-> .

[16:19] < MS-> ./demo

[16:19] < MS-> ./demo/gameover.py

[16:19] < MS-> ./demo/greet.py

[16:19] < MS-> ./demo/__init__.py

[16:19] < MS-> ~/tmp> more demo/__init__.py

[16:19] < MS-> print "Hello"

[16:19] < MS-> ~/tmp> more demo/greet.py

[16:19] < MS-> def greet():

[16:19] < MS-> print "hello world"

[16:19] < MS-> ~/tmp> more demo/gameover.py

[16:19] < MS-> def gameover():

[16:19] < MS-> print "game over"

[16:20] < MS-> ~/tmp> zip -r demo.zip demo/

[16:20] < MS-> adding: demo/ (stored 0%)

[16:20] < MS-> adding: demo/gameover.py (deflated 8%)

[16:20] < MS-> adding: demo/greet.py (stored 0%)

[16:20] < MS-> adding: demo/__init__.py (stored 0%)

[16:20] < MS-> ~/tmp> mv demo X

[16:20] < MS-> ~/tmp> ls

[16:20] < MS-> X/ demo.zip

[16:20] < MS-> ~/tmp> python

[16:20] < MS-> Python 2.5.1 (r251:54863, Jan 10 2008, 18:01:57)

[16:20] < MS-> [GCC 4.2.1 (SUSE Linux)] on linux2

[16:20] < MS-> Type "help", "copyright", "credits" or "license" for more information.

[16:20] < MS-> >>> import sys

[16:20] < MS-> >>> sys.path.append("demo.zip")

[16:20] < MS-> >>> import demo

[16:20] < MS-> Hello

[16:20] < MS-> >>> demo

[16:20] < MS-> < module 'demo' from 'demo.zip/demo/__init__.py'>

[16:21] < MS-> >>> demo.greet.greet()

[16:21] < MS-> Traceback (most recent call last):

[16:21] < MS-> File "< stdin>", line 1, in < module>

[16:21] < MS-> AttributeError: 'module' object has no attribute 'greet'

[16:21] < MS-> >>> import demo.greet

[16:21] < MS-> >>> demo.greet.greet()

[16:21] < MS-> hello world

[16:21] < MS-> >>> demo.gameover

[16:21] < MS-> Traceback (most recent call last):

[16:21] < MS-> File "< stdin>", line 1, in < module>

[16:21] < MS-> AttributeError: 'module' object has no attribute 'gameover'

[16:21] < MS-> >>> import demo.gameover

[16:21] < MS-> >>> demo.gameover

[16:21] < MS-> < module 'demo.gameover' from 'demo.zip/demo/gameover.py'>

[16:21] < MS-> >>> demo.gameover.gameover()

[16:21] < MS-> game over

[16:21] < MS-> Should be sufficient to see usage

[16:21] < MS-> and limitations

[16:23] < j_baker> That's seriously awesome. I'd have never guessed that python would be able to unzip a file then import it automagically.

[16:23] < MS-> Also:

[16:23] < MS-> >>> import sys

[16:23] < MS-> >>> sys.path.append("demo.zip")

[16:23] < MS-> >>> import demo

[16:23] < MS-> Hello

[16:23] < MS-> hello world

[16:23] < MS-> (if you change the __init__.py to:

[16:23] < MS-> ~/tmp/demo> more __init__.py

[16:23] < MS-> print "Hello"

[16:23] < MS-> import greet

[16:23] < MS-> greet.greet()

[16:24] < MS-> Inside the zipfile it can find stuff :)

[16:25] < MS-> I did wonder if you'd realised that detail :)

[16:25] < Davbo> that's cool.

[16:25] < j_baker> And then all you have to do is concatenate it with a shell script that will run python with one of the modules within as __main__.

[16:26] < j_baker> I saw the code to build the shell script, but I wasn't sure exactly how it was importing things within the shell script without explicitly unzipping it first.

[16:26] < MS-> ~/tmp> env PYTHONPATH=demo.zip python -c "import demo"

[16:26] < MS-> Hello

[16:26] < MS-> hello world

[16:29] < MS-> Discovery of the day - largish is in the OED

[16:29] < vmlemon_> Hah

[16:30] < MS-> That makes me happy, since that means one could cake a largish cake whilst beering beer, which is zactly correct.

[16:30] < vmlemon_> o.O

[16:30] < MS-> and they're all valid words & usages

[16:31] < MS-> And would drive many pedants nuts :-D

[16:31] < j_baker> English is such a weird language.

[16:31] < Davbo> Like: Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo

[16:31] < Davbo> Always confuses me

[16:32] < MS-> orphans: connecting and binding are not the same thing at all

[16:32] < MS-> a connect on a UDP socket also means something like odd

[16:32] < MS-> (multicast is a mode for a UDP socket)

[16:39] *** MS- finds the layout being used by orphans confusing

[16:39] < Davbo> I'm off to get something to eat, back later. Thanks for the help earlier MS-

[16:40] < MS-> yw

[16:42] *** bcarlyon|laptop has joined #kamaelia

[16:59] < Lawouach> MS-: in which way do you find his layout confusing?

[17:04] < MS-> I'm creating a branch to show more what I was expecting

[17:05] < MS-> I think what's probably confusing is that it creates local trunk/branch/tags areas

[17:05] < MS-> when in fact there's carte blanche to use /branches for that

[17:06] < MS-> you'll see the difference in a mo

[17:06] < MS-> lots of checkin messages along the lines of "for discussion"

[17:06] < MS-> I intend to delete the branch later

[17:07] < Lawouach> okay

[17:07] < Lawouach> I understand

[17:07] < Lawouach> It wasn't clear for me neither whether we could use it

[17:07] < Lawouach> thanks for clarifying

[17:09] < MS-> Please assume that anything except /trunk/Code is _probably_ fair game

[17:09] < Lawouach> cool

[17:09] < MS-> /branches/private_< your initials>< anything> and /trunk/Sketches/< your initials> *especially* so

[17:09] < MS-> :)

[17:11] < MS-> The approach taken by orphans though is easier to integrate with already running/installed kamaelia code bases of course

[17:11] < MS-> So that's why I view as "for discussion" :-)

[17:11] < MS-> both approaches have advantages

[17:13] < Lawouach> Yeah I had suggested he'd followed that layout but didn't consider using the overall repository :)

[17:17] < MS-> It is unusual I admit

[17:18] < MS-> Or rather uncommon, though v useful to be able to have carte blanche

[17:18] < MS-> When I spoke about working this way at pycon uk last year, someone pointed out that this was a way of hacking subversion to be useable in a way similar to a distributed version control systems

[17:18] < MS-> hmm, which version of pyrex are you using orphans?

[17:19] < MS-> Gah, the pyportmidi people don't say

[17:21] < MS-> Ah, missing dependency: -lporttime

[17:22] < j_baker> http://jason.baker.pastebin.com/m461c36f0 < - Could someone tell me why line 5 isn't working or even what it does exactly? I'm guessing it's checking the python version somehow, but sh is sheer gibberish to me sometimes. :)

[17:24] < j_baker> (other than that it works perfectly though)

[17:25] < j_baker> Or better yet, tell me where I can find it out on my own. :)

[17:26] *** mhrd has joined #kamaelia

[17:28] < orphans> euargh

[17:28] *** orphans catches up

[17:30] *** MS- finds http://portmedia.wiki.sourceforge.net/portmidi

[17:31] < orphans> MS-, connecting vs binding - yeah, I understand the difference OK now, just wondering why mhrd's code used the safeConnect method to bind. I think it's just a convenient quick hack, but I'm not certain. Would the socket errors from both be the same?

[17:31] < MS-> where's the code?

[17:32] < orphans> Sketches/MH/RTP/MultiCastTransceiver.py

[17:34] < MS-> https://kamaelia.svn.sourceforge.net/svnroot/kamaelia/trunk/Sketches/MH/RTP/Multicast_transceiver.py ?

[17:35] < orphans> yeah, sorry

[17:35] < orphans> was doing it from memory

[17:35] < orphans> line 223

[17:36] < MS-> Ah, I see that's a hack of the TCPClient code

[17:36] < orphans> yeah - that's what I though

[17:36] < orphans> s/though/thought

[17:37] < orphans> would the right way be to run safeConnect, then safeBind (non-existant at the moment afaik), then get the CSA and link it all up?

[17:37] < MS-> I think many of the exceptions caught and handled there aren't relevant

[17:38] < MS-> Well, the difference between bind and connect on UDP and bind and connect on TCP is worth noting

[17:38] < orphans> ok, I thought that might be the case

[17:38] < orphans> uh huh

[17:38] < MS-> bind on both means "I'm listening for messages on this port"

[17:38] < orphans> yup

[17:38] < MS-> You can actually do this with TCP as well, it's just very rare

[17:39] < MS-> (on a client that is)

[17:39] < MS-> ie define your client to make an outgoing connection _from_ port < some number>

[17:39] < MS-> But with UDP, being connectionless

[17:40] < MS-> You don't have that - so when you send messages, defining where they're coming from is really useful if you want a reply :)

[17:40] < MS-> With TCP, you just connect

[17:40] < MS-> Which gives the same effect

[17:40] < orphans> yeah, cool

[17:40] < MS-> in a way from a *client* perspective tcp's connect and udp's bind are very very similar

[17:41] < MS-> a .connect for a udp socket just says "use these default parameters for who to sent to"

[17:41] < MS-> rather than anything going out the network

[17:41] < MS-> it's very rarely used IME

[17:41] < orphans> people just use sendto

[17:41] < MS-> Generally

[17:42] < MS-> My guess is that matt kept that structure to encourage the likelihood of refactoring later on

[17:42] < MS-> If it became appropriate

[17:42] < orphans> Matt is actually using sendto in that

[17:42] < MS-> (which is after all actually where the CSA came from)

[17:43] < MS-> Yes, I also note that matt doesn't use connect for UDP either, which is cool :)

[17:43] *** vmlemon_ has joined #kamaelia

[17:43] < orphans> ok, so do you think it'd be overkill to have TCPClient, UDP and Multicast all inheriting from a base class?

[17:44] < orphans> 'cause it seems to me that the code would be pretty similar in all cases (althought that might be because they are all based upon TCPClient)

[17:44] < MS-> I think for the moment, don't merge them

[17:45] < MS-> The UDP code looks more complex than it has to be .

[17:45] < orphans> in what way?

[17:45] < MS-> Multicast at present is also alot simpler

[17:45] < MS-> well compare it with the current code

[17:45] < MS-> https://kamaelia.svn.sourceforge.net/svnroot/kamaelia/trunk/Code/Python/Kamaelia/Kamaelia/Internet/UDP.py

[17:45] < MS-> And also: https://kamaelia.svn.sourceforge.net/svnroot/kamaelia/trunk/Code/Python/Kamaelia/Kamaelia/Internet/Multicast_transceiver.py

[17:45] < orphans> from what I understand the problem with that is on recv you use 100% CPU

[17:46] < orphans> I thought that was why mhrd changed Multicast to use the CSA

[17:46] < MS-> Yes, but that's more a matter of the fact that those don't use the selctor service

[17:46] < MS-> No, I think it was an *easy* way for Matt to use the selector service

[17:46] < MS-> Not quite the same thing :)

[17:46] < orphans> ahh, right

[17:47] < orphans> so really the UDP code shouldn't use CSA, and go direct to the selector service?

[17:47] < MS-> Yes

[17:47] < orphans> or is that still up for grabs?

[17:47] < mhrd> yep - I cannabalised existing code to get there quick; plus it provided some assurance of having vaguely decent error condition handling from the outset

[17:47] < orphans> ok, I didn't really get that up til now :)

[17:47] < MS-> mhrd: Because you knew it'd been used/tested extensively :)

[17:47] < mhrd> indeed :)

[17:47] < orphans> I now see why it'd be bad to just merge the three

[17:48] < mhrd> MS-: a UDP sender I can see has no need to use the selector; but a UDP receiver/transciever surely has a good case for doing so?

[17:48] < orphans> :)

[17:48] < MS-> mhrd: All 3 have a good case for doing so

[17:49] < MS-> I just think it may be simpler just to do it inside the UDP sender/reciever/transcievers themselves

[17:49] < MS-> And then make multicast a toggle

[17:49] < MS-> You'd probably just end up with a UDP transceiver with a multicast toggle at a guess

[17:49] *** mhrd looks up "java ini file parser" on google and has to sift through hits mostly consisting of people saying "use this thing that doesn't quite work; or google for it"

[17:50] < orphans> so my next move should be making a simple UDP receiver using the selector service, expand that into a seperate transceiver, and whack in a toggle to set the multicast options?

[17:50] < MS-> orphans: What library is porttime from, and where can I download a version that will install?

[17:51] < MS-> Yes - also derive from the existing UDP & multicast code

[17:51] < orphans> it's from portaudio/midi - is there a suse package?

[17:51] < orphans> MS-, yeah, cool

[17:51] < MS-> rpm -qa|grep portaudio

[17:51] < MS-> portaudio20-20.0-0.pm.1

[17:51] < MS-> portaudio-19-175

[17:51] < MS-> portaudio-devel-19-222.pm.1

[17:51] < MS-> portaudio20-devel-20.0-0.pm.1

[17:52] < MS-> ~> rpm -ql portaudio20-20.0-0.pm.1|grep porttime

[17:52] < MS-> ~> rpm -ql portaudio-19-175|grep porttime

[17:52] < orphans> man I wish they did sensible releases

[17:52] < orphans> eww, perhaps not...

[17:53] < orphans> I really don'l like having to use pyportmidi much

[17:53] < orphans> can you try rpm -ql portaudio20-20.0-0.pm.1|grep ptlinux?

[17:54] < MS-> empty

[17:54] < orphans> eesh

[17:55] < MS-> found a 3 versions (3 distros back) old version of portmidi

[17:56] < orphans> fwiw this is why I prefer OSC

[17:56] < orphans> partly

[17:58] < orphans> erm, I'm not really sure what to suggest

[17:58] < orphans> I think the pyportmidi tarball has a compiled version in, but that's really really ugly I know

[17:58] < MS-> oh, now it just hates me

[17:59] < MS-> # ls /usr/lib/libporttime.so.0*

[17:59] < MS-> /usr/lib/libporttime.so.0 /usr/lib/libporttime.so.0.0.0

[17:59] *** vmlemon__ has joined #kamaelia

[17:59] < MS-> python setup.py build

[17:59] < MS-> ...

[17:59] < MS-> gcc -pthread -shared build/temp.linux-i686-2.5/pypm.o -L./linux -L/usr/lib -lportmidi -lporttime -lasound -lpthread -lpython2.5 -o build/lib.linux-i686-2.5/pypm.so

[17:59] < MS-> /usr/lib/gcc/i586-suse-linux/4.2.1/../../../../i586-suse-linux/bin/ld: cannot find -lporttime

[17:59] < MS-> IT'S LYING

[17:59] < orphans> symlink to libporttime.so?

[17:59] < MS-> (I have run ldconfig btw)

[18:00] < MS-> oh that's a thought

[18:00] *** vmlemon__ is now known as vmlemon_

[18:01] < MS-> Yay

[18:01] < orphans> :)

[18:02] < MS-> Ohh, you can throw the ball around

[18:02] < MS-> That's fun

[18:02] < MS-> :)

[18:02] < MS-> Is that all it does right now?

[18:03] < MS-> (just checking)

[18:03] < MS-> (I don't have an appropriate midi device atm)

[18:03] < orphans> it does that and sends out OSC messages as you go

[18:04] < orphans> that's one of the things on my todo list - I need to write a doc to say how you get sound out to test it easily

[18:07] < orphans> mm, seems the music gods really don't like suse - might be a bit more installing from tarballs for you I'm afraid MS-

[18:07] < MS-> I've got most stuff installed BTW

[18:07] < MS-> "packman" is really good for most thigs

[18:07] < MS-> and I've got that set up as a repository

[18:08] < MS-> Most things are just point and click (For *once* that was also the case with vlc & mplayer after moving to 10.3)

[18:08] < MS-> OK, I've created a branch:

[18:08] < MS-> https://kamaelia.svn.sourceforge.net/svnroot/kamaelia/branches/private_MPS_JT

[18:08] < MS-> which is primarily so that I can say. "i was thinking something more like this"

[18:09] < MS-> as opposed to "use this branch" since I do intend deleting it

[18:09] < MS-> You can find out what's where by doing svn diff -r4168:HEAD

[18:09] < MS-> svn diff -r4168:HEAD |grep Index

[18:09] < MS-> is perhaps more human friendly

[18:09] < MS-> Index: Apps/Kamaelia-Jam/App/Jam.py

[18:09] < MS-> Index: Apps/Kamaelia-Jam/DistBuild/setup.py.src

[18:09] < MS-> Index: Apps/Kamaelia-Jam/DistBuild/Jam.build.sh

[18:09] < MS-> Index: Apps/Kamaelia-Jam/Doc/INSTALL

[18:09] < MS-> Index: Apps/Kamaelia-Jam/Doc/README

[18:10] < MS-> Index: Apps/Kamaelia-Jam/Dependencies/pyportmidi-0.0.4-2.5.zip

[18:10] < MS-> Index: Apps/Kamaelia-Jam/Dependencies/portmidi-20041117-0.pm.1.i586.rpm

[18:10] < MS-> Index: Apps/Kamaelia-Jam/Dependencies/InstallingPortmidi

[18:10] < MS-> Index: Apps/Kamaelia-Jam/Dependencies/pyOSC-0.3.4b-4996.tar.gz

[18:10] < MS-> Index: Apps/Kamaelia-Jam/Dependencies/README

[18:10] < MS-> Index: Apps/Kamaelia-Jam/MANIFEST.in

[18:10] < MS-> Index: Kamaelia/Kamaelia/Apps/__init__.py

[18:10] < MS-> Index: Kamaelia/Kamaelia/Apps/Jam/Protocol/__init__.py

[18:10] < MS-> Index: Kamaelia/Kamaelia/Apps/Jam/Protocol/Osc.py

[18:10] < MS-> Index: Kamaelia/Kamaelia/Apps/Jam/__init__.py

[18:10] < MS-> Index: Kamaelia/Kamaelia/Apps/Jam/Internet/UDP.py

[18:10] < MS-> Index: Kamaelia/Kamaelia/Apps/Jam/Internet/__init__.py

[18:10] < MS-> Index: Kamaelia/Kamaelia/Apps/Jam/UI/__init__.py

[18:10] < MS-> Index: Kamaelia/Kamaelia/Apps/Jam/UI/XYPad.py

[18:10] < MS-> Index: Kamaelia/Kamaelia/Apps/Jam/UI/StepSequencer.py

[18:10] < MS-> Index: Kamaelia/Kamaelia/Apps/Jam/Util/MusicTiming.py

[18:10] < MS-> Index: Kamaelia/Kamaelia/Apps/Jam/Util/SendQuantizer.py

[18:10] < MS-> Index: Kamaelia/Kamaelia/Apps/Jam/Util/__init__.py

[18:10] < MS-> Index: Kamaelia/setup.py

[18:10] < MS-> To use that to build a packaged distribution

[18:10] < MS-> cd to : Apps/Kamaelia-Jam/DistBuild/

[18:11] < MS-> and run Jam.build.sh

[18:11] < MS-> That'll create a tarball, including the external dependencies

[18:11] < MS-> (may or may not be what you want)

[18:11] < MS-> That can install the axon, kamaelia, jam parts using python setup.py install

[18:12] < orphans> ok, cool. Is that definitely preferred to Lawouach's suggested layout then?

[18:12] < MS-> Not sure, depends on you guys really

[18:13] < MS-> I'd like to be able to do this approach for packaging for all apps labelled "Kamaelia : Foo"

[18:13] < MS-> But that's to do with packaging, not dev

[18:13] < orphans> uh huh

[18:14] < MS-> It may be that you find it easier to do what you're doing and then use that to patch the Kamaelia distro at DistBuild time

[18:14] < MS-> So that you can distribute without including Axon & Kamaelia easily

[18:14] < MS-> The currently approach is "nice" to the extent it's easy

[18:14] < MS-> but nasty in that it clobbers someone's kamaelia install

[18:15] < MS-> In a way, the ideal is to have an automated way of going from what you have

[18:15] < MS-> to the list of files/mappings above

[18:15] < MS-> and then to automate that

[18:15] < MS-> since it's easier to add extra stuff automatically than it is to pick stuff out

[18:16] < orphans> yeah

[18:16] < MS-> So it's for thought/discussion really

[18:16] < orphans> thoughts: packaging is hard :)

[18:17] < MS-> I can see 3 levels of download myself:

[18:17] < MS-> * "Just the stuff I wrote for this App"

[18:17] < MS-> * "The stuff I wrote for this App, and the rest of Kamaelia/Axon"

[18:17] < MS-> * Everything in 2 + most obvious dependencies

[18:17] < MS-> Yeah, packaging isn't simple

[18:17] < MS-> OK, I have to go afk

[18:17] < MS-> biab

[18:17] < orphans> k, ta for all that MS-

[18:36] *** bcarlyon|laptop has joined #kamaelia

[18:43] *** mhrd is now known as mhrd-afk

[18:47] < Lawouach> MS-: why Kamaelia/Kamaelia/Apps/ Vs Apps/Kamaelia-Jam/App/

[18:47] < Lawouach> I don't understand the layout above

[18:48] < j_baker> Using that method for making an executable that MS- and I discussed, I got an executable that's 5 kb. And that's WITH the .pycs and .svns and the entire Kamaelia and Axon libraries.

[18:49] < Lawouach> not bad :)

[18:49] < j_baker> Plus it should work without any installation on any unix.

[19:15] < MS-> Lawouach_: You mean whats the rationale for:

[19:15] < MS-> Kamaelia/Kamaelia/Apps/

[19:15] < MS-> Apps/Kamaelia-Jam/

[19:15] < MS-> on the branch ?

[19:15] < Lawouach> yes

[19:15] < Lawouach> I don't see what they represent

[19:16] < MS-> Apps/Kamaelia-Jam/ revolves around the packaging essentially of the non-component bits

[19:16] < MS-> Whereas Kamaelia/Kamaelia/Apps/ contains components

[19:16] < MS-> Excluding dependencies, Apps/Kamaelia-Jam contains this:

[19:17] < MS-> Index: Apps/Kamaelia-Jam/App/Jam.py

[19:17] < MS-> Index: Apps/Kamaelia-Jam/DistBuild/setup.py.src

[19:17] < MS-> Index: Apps/Kamaelia-Jam/DistBuild/Jam.build.sh

[19:17] < MS-> Index: Apps/Kamaelia-Jam/Doc/INSTALL

[19:17] < MS-> Index: Apps/Kamaelia-Jam/Doc/README

[19:17] < MS-> Index: Apps/Kamaelia-Jam/MANIFEST.in

[19:17] < MS-> Out of these, Apps/Kamaelia-Jam/DistBuild/Jam.build.sh is used for building a correct setup.py file, so that python setup.py sdist works

[19:17] < MS-> Whereas the other files, excluding __init__.py files are these:

[19:18] < MS-> Index: Kamaelia/Kamaelia/Apps/Jam/Protocol/Osc.py

[19:18] < MS-> Index: Kamaelia/Kamaelia/Apps/Jam/Internet/UDP.py

[19:18] < MS-> Index: Kamaelia/Kamaelia/Apps/Jam/UI/XYPad.py

[19:18] < MS-> Index: Kamaelia/Kamaelia/Apps/Jam/UI/StepSequencer.py

[19:18] < MS-> Index: Kamaelia/Kamaelia/Apps/Jam/Util/MusicTiming.py

[19:18] < MS-> Index: Kamaelia/Kamaelia/Apps/Jam/Util/SendQuantizer.py

[19:18] < MS-> Which are all components

[19:18] < Lawouach> Okay although I've usually seen mainly configure.py as a name rather than a .sh

[19:18] < MS-> You're lucky it wasn't a perl script :-)

[19:18] < MS-> ;)

[19:18] < Lawouach> true :)

[19:19] < MS-> (I think the one perl script there was went a long time ago (!) :-) )

[19:19] < Lawouach> I'll be honest I'm still confused but I'll be interested in seeing it working just to clarify things in my head.

[19:19] < MS-> Well, it means that orphans code is automatically scavengable by everyone else

[19:20] < MS-> eg, in some other random code I could write

[19:20] < MS-> import Kamaelia.Apps.Jam.UI,XYPad

[19:20] < MS-> because it defaults to working together

[19:20] < MS-> rather than apart

[19:21] < Lawouach> how's that different from the layout he had put in place?

[19:21] < Lawouach> AFAIK I could do that import too

[19:21] < MS-> Yes, you could, but it relates to packaging - this will mean that Kamaelia < apps> really are a part of kamaelia

[19:22] < MS-> After all from my perspective, these apps are really just a sneaky way of getting lots of components to scavenge into the main tree

[19:22] < Lawouach> okay

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

[19:23] < MS-> Which you guys do is up to you BTW, I'm just looking to try and find a way of doing things such that we get the benefits that CPAN have had for years

[19:23] < MS-> And I think one way of managing that is to have this altenate namespace of Kamaelia.Apps

[19:23] < MS-> which is either inside the tree or outside

[19:23] < MS-> in terms of dev

[19:24] < Lawouach> I'm not against your layout as I can understand the rational

[19:24] < Lawouach> It's just rather uncommon in the Python world

[19:24] < MS-> Yeah, one part is very clearly packaging, the other is library

[19:24] < MS-> Yes, I know.

[19:25] < MS-> I've probably worth with Perl as long as I worked with python, and I do still like perl, and like the way it handles packaging far better than python packages do

[19:25] < MS-> s/worth/worked/

[19:25] < MS-> The *result* when it comes to distribution will currently be this:

[19:26] < MS-> ~/kamaelia/branches/private_MPS_JT/Apps/Kamaelia-Jam/dist> tar zxf Kamaelia-Jam-0.0.0.tar.gz

[19:26] < MS-> ~/kamaelia/branches/private_MPS_JT/Apps/Kamaelia-Jam/dist> cd Kamaelia-Jam-0.0.0/

[19:26] < MS-> ~/kamaelia/branches/private_MPS_JT/Apps/Kamaelia-Jam/dist/Kamaelia-Jam-0.0.0> python setup.py install

[19:26] < MS-> Which is the usual python dance

[19:26] < MS-> It's just how to get there is slightly different

[19:27] < MS-> I think that it can be improved further though, based on the ideas you asked orphans to work on

[19:27] < MS-> ie such that we could have 3 levels of package

[19:27] < MS-> "just the app please, I have Kamaelia, Axon & everything else"

[19:28] < MS-> "The app, Axon & Kamaelia please, I'll figure out the rest"

[19:28] < MS-> "Oh, just give me as many dependencies as you can, I'm a lazy goit and just want it to work"

[19:28] < MS-> This packaging defaults to the second

[19:29] < MS-> Much of the python world does "here's just the app, you figure the rest out", and that strikes me as a little odd in our case

[19:29] < MS-> *shrug* It's just the latest iteration

[19:30] < MS-> I'm sure I'll look back at this approach at some point and cringe

[19:30] < Lawouach> :)

[19:35] < MS-> It'd be interesting to see what a half way house might look like

[19:44] *** bcarlyon|laptop has joined #kamaelia

[20:33] *** vmlemon_ has joined #kamaelia

[20:50] < MS-> Anyone want to build a simulator ? http://www.computer50.org/mark1/prog98/ssemref.html

[20:54] *** j_baker has joined #kamaelia

[21:09] *** j_baker_ is now known as j_baker

[21:17] < j_baker> MS- or mhrd-afk: I'm trying to understand the WaitComplete message. If I understand what's happening properly, when the scheduler receives a WaitComplete, it creates a new microprocess?

[21:18] < j_baker> If that's what is happening, does the new microprocess have access to the old microprocess's boxes (since this seems to be happening at the microprocess level rather than the component level).

[21:23] < MS-> j_baker: Look at Kamaelia-Grey

[21:23] < MS-> What you pass in is a generator.

[21:23] < MS-> That is then used as the generator for the microprcess rather than a new main() being started

[21:23] < MS-> That means whatever generator you pass in has access to whatever that generator has access to

[21:23] < MS-> if that generator looks like

[21:23] < MS-> def foo(self):

[21:23] < MS-> ...

[21:24] < MS-> then that generator foo has access to self

[21:24] < MS-> which is the component, and hence has access to the same attributes

[21:24] < MS-> ie the generator may change, but the object remains the same

[21:25] < MS-> Too many waitcompletes in a piece of code tend to imply the code needs changing BTW, IMO

[21:25] < MS-> Though it can be very useful for getting something going

[21:25] < j_baker> Well, there are a lot of them in the AIM code. I was wondering if that was what was causing it to lock up.

[21:26] < j_baker> I'll have to play around with it. It would at least be nice to have a timeout if it doesn't connect.

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

[21:56] *** vmlemon__ has joined #kamaelia

[22:13] *** bcarlyon|laptop has joined #kamaelia

[23:02] *** vmlemon_ has joined #kamaelia

[23:25] *** vmlemon_ has joined #kamaelia

[23:33] < MS-> Interesting: http://basiscraft.com/

[23:50] *** bcarlyon|ubuntu has joined #kamaelia