[00:06] *** sadrul1 is now known as sadrul

[00:51] *** ms-away sleeps

[00:51] < ms-away> (having created 3 branches for merge focussed on specific functionality)

[06:30] *** vmlemon_ has joined #kamaelia

[06:51] *** PJ_Coudert has joined #kamaelia

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

[07:30] < vmlemon_> Hi

[07:39] < vmlemon_> kamaeliabot: dance

[07:39] Reply: does the macarena

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

[08:00] *** Lawouach_ has joined #kamaelia

[08:00] < Lawouach_> morning

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

[08:36] < mhrd> hi Lawouach_, vmlemon_, ...

[08:51] *** orphans has joined #kamaelia

[08:58] < Lawouach_> http://mail.python.org/pipermail/web-sig/2008-May/003401.html < -- a fairly dense thread regarding WSGI and async' design

[08:59] < Lawouach_> Might be interesting for j_baker's work

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

[09:38] *** edh has joined #kamaelia

[09:42] *** Uraeus has joined #kamaelia

[11:15] *** vmlemon_ has joined #kamaelia

[11:15] < vmlemon_> Hi

[12:26] *** Davbo has joined #kamaelia

[12:27] < Davbo> Anyone know MS's Gmail? I know that gets to him faster, send it in [off] please :)

[12:27] Reply: Hm?

[12:27] < Davbo> Shh kamaeliabot

[12:27] < Davbo> oh got it

[12:28] < Davbo> ignore me :)

[12:29] < Davbo> Hopefully I'll be back later in time for the meeting

[12:30] < Davbo> if not i've ignore MS my done/todo/blocked

[12:30] < Davbo> blah

[12:30] < Davbo> emailed

[12:30] < Davbo> s/ignore/emailed - Don't ignore MS :P

[12:35] < Davbo> Got to rush, bye.

[12:42] < orphans> anyone have any idea why Text.py from private_MPS_JL_PygameText doesn't exit? Both components get out of their mainloop, and a shutdownMicroprocess signal is propagated, but it stays resolutely open

[13:18] *** vmlemon_ has joined #kamaelia

[13:43] < j_baker> Thank you for posting that Lawouach. That is interesting.

[13:43] < mhrd> orphans: what stays open?

[13:43] < mhrd> the PygameDisplay() component will need to be shut down too if thats what you mean

[13:44] < mhrd> the Axon scheduler only terminates once there are *no* running components left

[13:45] < mhrd> if you want to see whats going on, try plugging in the components in /trunk/Sketches/MH/Introspection/Profiling.py ...

[13:45] < orphans> mhrd, how do you shutdown the pygame display?

[13:45] < mhrd> pipeline( FormattedProfiler(10.0,1.0), ConsoleEchoer() ).activate()

[13:46] *** orphans forgot about the profiler :)

[13:46] < mhrd> hmm ... for most compnoents - you'd have to arrange a way to send a shutdownMicroprocess signal to it ... but I suspect we may have never quite gotten round to adding the necessary code to PygameDisplay to handle those msgs

[13:47] < mhrd> ... you can always try adding it in if you want

[13:47] < orphans> sounds fun :)

[13:51] < orphans> yeah - there's no way out for the pygame display

[13:51] < orphans> I'll give it a go at adding that in when I have a minute

[13:51] < orphans> cheers mhrd

[13:52] < j_baker> mhrd: If a parent component dies, do its children not also die?

[13:53] < mhrd> no

[13:53] < mhrd> the parent-child relationship is not one of strict encapsulation

[13:54] < j_baker> I see. Perhaps that was part of the reason I was having so much problem with getting things to shut down. :)

[13:54] < mhrd> aah! ...

[13:54] < mhrd> it exists mainly as a metaphor to allow you to compartmentalise a system

[13:54] < mhrd> there is, for example, nothing to stop a child component being wired up to another component somewhere else in the system ...

[13:55] < mhrd> from a practical perspective, the only support Axon provides is that it will wake up a parent if one of its children dies (see the internals of Pipeline or Graphline to see that in action)

[13:56] < mhrd> you can also see it if you run an introspection using the Axon visualiser - you can see that, from Axon's perspective, the graph of component linkages is flat ...

[13:56] < mhrd> http://kamaelia.sourceforge.net/AxonVisualiser.html

[13:56] < j_baker> I see. That makes sense.

[13:57] < mhrd> in http://kamaelia.sourceforge.net/screenshots/AxonVisualiser_navelgaze.gif ... K.V.A.AVS.AVS_15 is a Pipeline component. The orange linkages represent where it has forwarded its own inboxes/outboxes to the start and end of the pipeline of components it has instantiated

[13:59] < mhrd> when thinking in parent/child terms, you can represent the same structure like this: http://kamaelia.sourceforge.net/images/pipeline1_inside.gif (from http://kamaelia.sourceforge.net/Cookbook/Pipelines )

[13:59] < j_baker> Ok. That helps out a lot.

[14:00] < mhrd> cool

[14:03] < mhrd> if you run the axon visualiser with the --navelgaze option yourself, the labels on the components should be a little more intelligible, thanks to MS :-)

[14:09] < mhrd> as discussed over the past few days (see logs) shutdown is something we generally don't handle amazingly well (orphans - also answers your mailing list q)

[14:14] *** Uraeus has joined #kamaelia

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

[14:29] *** vmlemon_ has joined #kamaelia

[14:32] *** vmlemon_ has joined #kamaelia

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

[14:34] < vmlemon_> Yay, trying to enable logging on the IRC client I'm testing crashes it

[14:39] < vmlemon_> kamaeliabot: dance

[14:39] Reply: does the macarena

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

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

[14:43] < MS-> (afternoon)

[14:43] < mhrd> hi

[14:45] < vmlemon_> Hi, MS-

[14:52] < j_baker> hello MS-

[14:52] < MS-> um, bit of an emergency

[14:52] < MS-> sorry

[14:58] *** Chong- has joined #kamaelia

[15:00] *** Trun has joined #kamaelia

[15:04] *** vmlemon__ has joined #kamaelia

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

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

[15:09] < MS-> RIght back

[15:09] < MS-> Give me a couple of minutes

[15:09] < MS-> Need to sort something out

[15:10] < MS-> (That was a little bit of a drama)

[15:10] < orphans> :o

[15:10] < vmlemon_> Ouch

[15:11] *** mhrd gets cup of tea (back in < 5mins)

[15:11] < j_baker> Good luck with that MS-.

[15:12] < vmlemon_> Yay

[15:12] < MS-> Ok, just grabbing a coffee to have with meeting - start at 4:20 - we'll be done by 5 anyway :)

[15:13] < vmlemon_> "Next Week on #Kamaelia..." ;)

[15:15] *** mhrd back

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

[15:18] < Lawouach_> heya

[15:19] < MS-> heya

[15:19] < MS-> back

[15:20] < vmlemon_> Do you think BBC 1 would screen it? ;)

[15:21] < vmlemon_> Hi Lawouach

[15:21] < MS-> OK, meeting time :)

[15:21] < MS-> ==============================================

[15:21] < MS-> START OF WEEKLY IRC KAMAELIA MEETING, 20050522

[15:21] < MS-> ==============================================

[15:21] < MS-> 1. Note of Agenda

[15:21] < MS-> -----------------

[15:21] < MS-> 1. Note of Agenda

[15:21] < MS-> 2. Participants

[15:21] < MS-> 3. Activity Reports

[15:21] < MS-> 4. Discussion items (max 3 or 4)

[15:21] < MS-> 4.1 Branches & Merging

[15:21] < MS-> 4.2 Website/Tools update

[15:21] < MS-> 4.3 Next Release : June 21st

[15:22] < MS-> 5. Date/Time of next weekly meeting

[15:22] < MS-> Thursday 29th May 2008, 4pm UK time

[15:22] < MS-> Any extra agenda items?

[15:22] < mhrd> s/20050522/20080522/

[15:22] < MS-> oh yes

[15:22] < MS-> :)

[15:22] < MS-> Thought it looked odd for some reason

[15:22] < j_baker> So this is a retro meeting? :P

[15:22] < mhrd> just a little delayed :)

[15:22] *** orphans parties like it's 2005

[15:22] < MS-> I'll take that as no extras

[15:23] < j_baker> none for me

[15:23] < MS-> 2. Participants

[15:23] < MS-> ---------------

[15:23] < MS-> Participants: MS-, mhrd, Lawouach, Chong-, j_baker, orphans, Trun

[15:23] < MS-> AWWL: Davbo

[15:23] < MS-> Also present: vmlemon_, zaheerm, Uraeus, sadrul, jle, edh, bcarlyon|ubuntu_

[15:23] < MS-> 3. Activity Reports

[15:23] < MS-> -------------------

[15:23] < MS-> Everyone ready?

[15:23] < MS-> go :)

[15:23] < MS-> DONE: Pruned /branches somewhat, merged various branches, got edit.kamaelia.org up & ran mentoring sessions, confirmed DVB working, answered various q's on list

[15:23] < MS-> TODO: Continue getting website ready, and extracting branches for merge, and cleaning up /branches

[15:23] < MS-> BLOCKED: On leave mon/tue/wed next week, so may be out of contact from Sat-> Thur

[15:23] < mhrd> DONE: More DVB stuff (various fixes, enhancements, docs); assisted GSoCers

[15:23] < mhrd> TODO: more DVB stuff (see blocked #2)

[15:23] < mhrd> BLOCKED: project work; "mashed" (bbc backstage) stuff

[15:23] < orphans> DONE: More documentation of components, make xy pad more flexible, fixes to text widgets before merging

[15:23] < orphans> TODO: Yet more documentation, sort out basic timing code, rearrange Sketches/JT to set up program structure

[15:23] < orphans> BLOCKED: Exams

[15:23] < Trun> DONE: Mainly improvements in KamPlanet (especially kamaelia-related problems I had)

[15:23] < Trun> TODO: Complete (finish) KamPlanet; Look at [/Code/Python/Kamaelia/Tests and /Tests, selector, PygameDisplay]; Closer look more at Backplane; Start KamPlanet tests

[15:23] < MS-> DK:

[15:23] < Trun> BLOCKED: None

[15:23] < MS-> DONE: Got 2 MagnaDoodle.py working together using

[15:23] < MS-> ProcessPipeline(), also implemented simple scaling

[15:23] < MS-> circle tool.

[15:23] < MS-> TODO: Change the MagnaDoodles to output events onto a Graphline

[15:23] < MS-> so they communicate with each other, then make a new

[15:23] < Chong-> Done: blue/pink relaiton TopologyView

[15:23] < j_baker> DONE: Added more WSGI support

[15:23] < MS-> window with 3 button controls for line, circle erase.

[15:24] < MS-> Make these controls only act on "Window 1", then introduce

[15:24] < MS-> a 3rd window and get them working on a Backplane.

[15:24] < MS-> Once this is done, add colour!

[15:24] < MS-> BLOCKED: None really, apart from exams and revision. :-)

[15:24] < Chong-> To do: picture particles, extend TopologyView (update), Hierarchical Topology

[15:24] *** MS- reads

[15:24] < j_baker> TODO: Finish up WSGI support, finish up logger

[15:24] < Chong-> Blocked: none

[15:24] < j_baker> BLOCKED: None atm

[15:25] < MS-> cool

[15:25] < MS-> any q's from anyone to anyone?

[15:26] < MS-> if not moving on in

[15:26] < MS-> 5

[15:26] < MS-> 4

[15:26] < MS-> 3

[15:26] < MS-> k

[15:26] < MS-> 4. Discussion items (max 3 or 4)

[15:26] < MS-> --------------------------------

[15:26] < MS-> 4.1 Branches & Merging

[15:26] < MS-> ^^^^^^^^^^^^^^^^^^^^^^

[15:26] < MS-> OK, so there's been a fair few of this this week :)

[15:26] < MS-> Overall, this seems pretty good.

[15:27] < MS-> There will be more branches popping up as I ready stuff for merge - ala the 3 branches from last night

[15:27] < mhrd> I might be able to look at one or two of those, but possibly not until saturday

[15:27] < MS-> It would be really nice to have volunteers to merge as well :)

[15:27] < MS-> mhrd: Cheers

[15:28] < MS-> orphans has offered to review one

[15:28] < MS-> have you offered to merge that branch as well?

[15:28] < MS-> :)

[15:28] < orphans> MS-, yeah, sure - it's pretty much ready I think

[15:28] < MS-> cool

[15:28] < orphans> would someone mind having a very quick look over my changes just to make sure I've not done anything horrible :)

[15:29] *** orphans not that confident yet

[15:29] < MS-> You can also do this if you like:

[15:29] < MS-> svn merge --dry-run < rest of args>

[15:29] < MS-> orphans: Yeah, I understand

[15:29] < MS-> I'll take a look and feedback :)

[15:29] *** mhrd confused - orphans reviewing someone else's branch, or merging his own?

[15:29] < orphans> MS-, k, cheers

[15:30] < MS-> mhrd: reviewing the branch I made last night which is merging Jinna's code onto Trunk

[15:30] < mhrd> k

[15:30] < j_baker> Fyi, my branch isn't ready for merge yet. :)

[15:30] < MS-> It's been in my scratch branch for a long while and works nicely/is useful

[15:30] < MS-> j_baker: cool

[15:30] < MS-> One of the things that people tend to not be used to is merging

[15:31] < MS-> so Ideally I'd like merging to be a quid-pro-quo thing rather than a single bottleneck

[15:31] < MS-> ie if someone merges one of yours, you offer to merge one :)

[15:31] < MS-> Seems only fair :)

[15:32] < MS-> Does need to be reviewed by me/matt or Lawouach IMO first though :)

[15:32] < MS-> I'm guessing that silence == consensus

[15:32] < MS-> 4.2 Website/Tools update

[15:32] < MS-> ^^^^^^^^^^^^^^^^^^^^^^^^

[15:32] *** mhrd happy

[15:32] < Chong-> yep

[15:33] < MS-> http://edit.kamaelia.org/Developers/ is up

[15:33] < MS-> the edit button works

[15:33] < MS-> So does http://edit.kamaelia.org/UserPreferences

[15:33] < MS-> To set your name

[15:33] < MS-> but for some reason page tags don't - I'll check why

[15:34] < j_baker> I would like to point out the SVN web link still doesn't work. :)

[15:34] < MS-> There's been lots of good comments as to how to improve it, and some of the things you can fix now

[15:34] < MS-> So, please update things you want to

[15:35] < orphans> j_baker, fixed on the SVN page, just not in the sidebar yet :)

[15:35] < j_baker> I see.

[15:35] < orphans> MS-, can we edit the sidebar?

[15:35] < MS-> http://edit.kamaelia.org/WebsiteSuggestions

[15:36] < MS-> orphans: At present no, but asap.

[15:36] < orphans> cool

[15:36] < Chong-> MS-: how can we log in?

[15:36] < MS-> That URL is the best one to edit to add notes about how to improve the website

[15:37] < Chong-> I see. thanks.

[15:37] < MS-> At present you also manually link things

[15:37] < vmlemon_> The content from edit. is mirrored to the SF Wiki, and vice-versa

[15:37] < MS-> mhrd: Yep, I'll deal with that

[15:37] < vmlemon_> ?

[15:37] < MS-> The content will be mirrored to SF wiki

[15:38] < MS-> But at present that isn't in place yet

[15:38] < MS-> But will go in

[15:38] < vmlemon_> Aah

[15:38] < MS-> sooner rather than later

[15:39] < mhrd> cool - thanks for re-enabling editing MS-

[15:39] < MS-> Any questions, suggestions and comments welcome, though preferably on the page mentioned above

[15:40] *** MS- wonders if there's anything else on that front at this stage?

[15:40] < MS-> I'm guessing not?

[15:40] *** vmlemon_ has changed IRC clients on his phone, and is still getting to grips with the new one :(

[15:40] *** mhrd happy

[15:40] *** MS- waits for a moment

[15:41] *** j_baker has nothing to add

[15:41] < MS-> 4.3 Next Release : June 21st

[15:41] < MS-> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[15:42] < MS-> OK, this is pushing on somewhat. For the next release I have the following specific aims at this point:

[15:42] < MS-> * Merge as much of private_MPS_Scratch onto trunk

[15:42] < Chong-> Anything we can help to do, MS-?

[15:42] < MS-> * Website update

[15:42] < MS-> Chong-: review and merge of branches

[15:42] < MS-> (review includes running code if you have the hardware of course)

[15:42] < Chong-> np.

[15:42] < MS-> * Packaging up of all the major Kamaelia apps

[15:43] < mhrd> I'm hoping to have a few more DVB components or example ready before then which I'd hope can make it into the release too (all a bit dependent on how much time I can devote to that tho)

[15:43] < MS-> * Release notes

[15:43] < MS-> * Detailed changelog

[15:43] < MS-> * Documentation review

[15:43] < MS-> mhrd: Yep - The time issue is just one of those things

[15:44] < mhrd> cool. if I can't get things done in time, I just won't put them forward for inclusion.

[15:44] < MS-> k

[15:44] < MS-> Regarding release planning, I'll suggest we use this page: http://edit.kamaelia.org/ReleaseJune2008

[15:45] < mhrd> heh, was about to suggest something like that

[15:45] < MS-> So all the things people were discussing last week which culminated "we really need a wiki for this"... well there it is :)

[15:45] < Chong-> MS-: Any allocation of 'review and merge of branches' to me?

[15:46] < MS-> Chong-: I'd prefer people to take a look at see what's needing merging and taking from there

[15:46] < MS-> At present there's two branches not "owned" for review & merge

[15:46] < MS-> private_MPS_JL_AIMSupport/

[15:46] < MS-> private_MPS_JL_IRCSupport/

[15:46] < MS-> The smaller of the two is the latter

[15:47] < MS-> The former would benefit from testing on a Mac

[15:47] < MS-> since I believe there to be an issue on mac os X with the code there

[15:47] < MS-> But haven't had a chance to review

[15:47] < Chong-> I have no mac so I will take the second one.

[15:47] < j_baker> I'll try my hand at the first one

[15:47] < vmlemon_> Has the new site been tested against the Hype-O-Meter(R), yet? ;)

[15:47] < MS-> j_baker: Much appreciated :)

[15:47] < mhrd> yay, no merging for me :)

[15:47] < MS-> vmlemon_: I have some plans :)

[15:48] < Lawouach_> meh a colleague had written his own command line parser rather than using optparse

[15:48] < Lawouach_> and guess what

[15:48] < Lawouach_> it's buggy

[15:48] < Lawouach_> sigh

[15:48] < Lawouach_> how do I tell him it was a bad move?

[15:48] < mhrd> ooh, never knew that existed!

[15:49] < MS-> svn rm < hiscode.py>

[15:49] < MS-> svn ci < hiscode.py>

[15:50] < j_baker> But what if he's using git?!

[15:50] < MS-> j_baker: In which case you revert to the baseball bat

[15:50] < Lawouach_> :)

[15:51] < Lawouach_> svn kha

[15:51] < Lawouach_> which stands for Kick His Ass

[15:51] < MS-> OK, I think we're happy there, I'll note branch merge ownerships on the webpage (or someone else can :) )

[15:51] *** MS- moves on

[15:51] < vmlemon_> And CVS? (AKA Crappy Version Control) ;)

[15:51] < MS-> 5. Date/Time of next weekly meeting

[15:51] < MS-> -----------------------------------

[15:51] < MS-> Thursday 29th May 2008, 4pm UK time

[15:51] < MS-> Note: "mentor time" (with me) for Monday/Tues is scrapped next week

[15:51] < MS-> due to long weekend, since I won't be around. Can either

[15:51] < MS-> make up on the Friday, or skip a week.

[15:52] < MS-> (could well be disappearing for the weekend - not actually planned yet)

[15:53] < Chong-> MS-: I will go to the Bath show next week, so I cannot take meeting, either.

[15:53] < MS-> Is that OK with everything?

[15:53] < MS-> k

[15:53] < MS-> s/everything/everyone/

[15:53] < orphans> cool by me :)

[15:53] < j_baker> I'm good. I may do the meeting on Fri, but I'll just play it by ear.

[15:53] *** Chong- happy

[15:53] < Trun> you mean May 30th, right?

[15:53] < MS-> Trun: yep.

[15:54] < MS-> if you can you can/if you can't you can't

[15:54] < Trun> I'm out that day

[15:54] < MS-> np

[15:55] < MS-> OK, given that there's no major shouts beyond that and can be organised outside the meeting

[15:55] < MS-> ============================================

[15:55] < MS-> END OF WEEKLY IRC KAMAELIA MEETING, 20080522

[15:55] < MS-> ============================================

[15:55] < MS-> Cheers :)

[15:56] < Lawouach_> burp

[15:58] < Lawouach_> anyhow

[15:59] < Lawouach_> back to home

[16:34] < Lawouach> back

[16:38] < MS-> hiya

[17:12] *** MS- posts minutes to the list

[17:40] < j_baker> MS- or mhrd: if a component is not a threaded component, is there any reason not to call its stop() method?

[17:42] < MS-> .stop() in that scenario is like a kill(9)

[17:43] < j_baker> So in other words, the main problem is that the component won't be notified it's about to be stopped?

[17:43] < MS-> Essentially.

[17:43] < MS-> It also breaks the model of "only talking to the component over it's boxes"

[17:43] < MS-> But being able to do .stop() is a nice thing

[17:44] < MS-> and the direction the system is moving in, but not all the components know that right now

[17:46] < mhrd> looking at the present state of Axon: the scheduler won't know about the stoppage immediately, but looks like it will pick it up next time it tries to run that component

[17:47] < vmlemon_> o.O "File too big. Limit is approx 2048 kbytes."

[17:47] < mhrd> you mean 2gigs?

[17:48] < j_baker> That would still happen more quickly than sending a shutdownMicroprocess message though, wouldn't it mhrd?

[17:49] < mhrd> "more quickly"?

[17:49] < vmlemon_> Hmm, I guess so, although it's the exact error vi gives here...

[17:50] < mhrd> 2^31 (signed 32 bit int) conveniently comes out as 2 gigs; hence the 2gig limit on fat32 iirc

[17:50] < vmlemon_> Interesting

[17:51] < mhrd> j_baker: performance wise: perhaps. if what you actually mean is its more "guaranteed" to stop the component/microprocess then yes

[17:51] < j_baker> Yeah. That's what I meant.

[17:51] < vmlemon_> I don't think QNX has a max file size limit, although the vi it comes with obviously does...

[17:52] < mhrd> pretty much all file systems have some kind of limit; its just with some (like zfs,xfx) its ridiculously large, even by modern standards ;-)

[17:53] < vmlemon_> Good point

[17:57] < vmlemon_> At least they claim that ZFS can store more data than could possibly fit on all the HDDs in the world, or some other limit

[17:58] < mhrd> we're safe for now :)

[18:19] *** vmlemon_ has joined #kamaelia

[18:23] < j_baker> Is there any reason why python would quit printing exception tracebacks? Right now, if I run something in python and it hits an exception, it stops and doesn't print anything.

[18:36] < mhrd> exception in a thread?

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

[18:38] *** vmlemon_ has joined #kamaelia

[18:39] *** j_baker has joined #kamaelia

[19:19] *** vmlemon__ has joined #kamaelia

[19:21] *** vmlemon__ is now known as vmlemon_

[19:50] *** MS- notes he's afk all day (literally :-( :-( :-( (6am -> 10pm in all likelihood) ) tomorrow

[20:06] *** MS- sees why j_baker asked the question earlier

[20:07] < j_baker> :)

[20:07] < j_baker> Are you talking about the GC component?

[20:07] < MS-> yes

[20:07] < MS-> For specific cases, the approach is valid

[20:07] < j_baker> I was just posting on the board about that.

[20:08] < MS-> But for the general case, it's as problematic as the "orphaned component" idea

[20:08] < MS-> Since your definition of an orphaned component isn't actually necessarily a broken component

[20:09] < MS-> ie a component with no links in or out is not necessarily OK to kill/harvest

[20:10] < MS-> Likewise, item.stop() is part of a slippery slope which is not as valid as it seems

[20:10] < MS-> Again, this is also inherently dangerous:

[20:10] < MS-> + self.link((self, '_internal-signal'), (item, 'control'))

[20:10] < j_baker> Right. I don't think it's going to replace control/signal inboxes at all. But I do think there are times when you just want to be able to kill a group of components easily.

[20:10] < MS-> + self.send(shutdownMicroprocess(), item)

[20:10] < MS-> + self.unlink(item)

[20:11] < j_baker> Would there be a better way of doing that? I couldn't think of any better way.

[20:11] < MS-> Agreed, and when you have to do it, you do find ways of doing that, but generally speaking the best components emerge from a collection of good designs.

[20:11] < MS-> and working systems

[20:11] < MS-> rather than the other way round

[20:11] < MS-> I'm not saying "don't do this"

[20:11] < MS-> What I am saying is "there may well be unexpected issues here"

[20:12] < j_baker> That's understandable. I figured if nothing else, it will be useful to at least test to make sure the core of a component works before you start messing with the control/signal boxes.

[20:12] < j_baker> (since that's been a problem with testing components for me)

[20:13] < MS-> In a testing environment you have a very restricted usecase

[20:13] < MS-> So it could well be useful in that case

[20:13] < MS-> (I'm not really a believer in absolutes and prefer "hypothesise, test, refine" over "I'm right do it this way")

[20:14] < MS-> But sometimes some things jump out at me as "this looks risky and maybe doing too much or something risky" - cf

[20:14] < MS-> http://cerenity.org/cgi-bin/blog/blog.cgi?rm=viewpost&nodeid=1113136192

[20:15] < j_baker> So do you know of any ways it could be improved. I was thinking the item.stop() should only be used in testing at least until you said that it was the way things were heading.

[20:15] < j_baker> But I'm curious if you have any better ideas about sending the shutdown message.

[20:15] < MS-> I think compromising about using it during testing is a good idea.

[20:16] < MS-> The reason is because .stop() can happen at any time point, causing potentially vicious shutdown cases for the component

[20:16] < MS-> So for testing, that's perfect :)

[20:16] < MS-> Since you *do* want that sort of problem

[20:16] < MS-> But ideally for shutdown, you do want to give things the time to do it properly

[20:17] < MS-> For example if the component has handshaking with another

[20:17] < MS-> Ah, yes, this is a good example

[20:17] < MS-> Consider a component that was used to implement a TCP stack

[20:18] < MS-> The setup has particular setup sequence, and a particular shutdown sequence

[20:18] < MS-> If the shutdown sequence is bypassed, then unless the server set the reuseable socket flag

[20:18] < MS-> then the socket is then essentially locked for a certain period

[20:19] < MS-> (normally 60 seconds)

[20:19] < MS-> This does cause problems in the real world - you can send a server a HUP message

[20:19] < MS-> "Hang Up"

[20:19] < MS-> which can be used for a variety of things, but often is equivalent to sending a shutdownMicroprocess message

[20:20] < MS-> since it allows the server to close connections

[20:20] < MS-> and close the listener socket cleanly

[20:20] < MS-> meaning the restart can be instantaneous afterwards

[20:20] < MS-> However, if you kill -9 a server that's not using the reusable socket option, then you end up that problem

[20:21] < j_baker> Well, for the most part I was thinking the item.stop() would be most useful if say I need to make a Producer that does nothing but emit something.

[20:21] < MS-> And it's caused by the independent thing closing down, but not performing a shutdown handshake

[20:21] < MS-> Yeah, but that's not sufficient

[20:21] < MS-> If the transport is expected to be lossy

[20:21] < MS-> and the message has to get through

[20:22] < MS-> then you have to deal with the fact that you have to do this

[20:22] < MS-> FIN, FIN_ACK, ACK

[20:22] < MS-> A: "I'm shutting down"

[20:22] < MS-> B: "You're shutting down? OK, I'm shutting down too"

[20:22] < MS-> A: "Cool, I've shutdown"

[20:23] < MS-> If the third message goes missing, B could resend and get a TCP_RESET (which would confirm the shutdown)

[20:23] < MS-> But the point is there is *time* between those 3 messages for transit

[20:24] < MS-> Using .stop() forces the shutdown to be just

[20:24] < j_baker> Well, I do also see how that could cause problems other than that. Suppose an item has something waiting in one of its inboxes when it receives the stop()

[20:24] < MS-> A: "I'm shutting down"

[20:24] < MS-> Which is a problem

[20:24] < MS-> So, as I say for testing purposes, it's fine.

[20:25] < MS-> (and could encourage some interesting best practice)

[20:25] < MS-> So for example - Trun's project may benefit from it

[20:25] < MS-> since Trun's project is about building a testing framework

[20:26] < MS-> But be aware for real world systems, it could cause more problems than you might think

[20:26] < MS-> *could*

[20:26] < MS-> As I say though, this is hypothesis stage

[20:26] < j_baker> Suppose that for a real world system, you didn't rely on the stop method though?

[20:26] < MS-> Next logical steps are test & refine

[20:26] < MS-> For all existing real world systems we don't rely on the stop method

[20:28] < j_baker> Right, so suppose you used it to send the shutdownMicroprocess() message in such a system. Would that still cause problems?

[20:28] < MS-> I can see scenarios where it would be problematic, yes.

[20:29] < MS-> However, that doesn't mean it's a bad idea in the general case. It may mean that it needs careful thought

[20:29] < MS-> As to when/how it's used

[20:30] < MS-> I've gotten used to trusting my gut instinct over the years, and this is one area where it tells me that this has potentially nasty areas

[20:30] < j_baker> Are the problems caused by my method of doing that or do they come from the general idea of shutting things down at once? (sorry, not trying to be argumentative or pedantic. I'm just trying to understand where the problems are.)

[20:30] < MS-> Are you asking ...

[20:31] < MS-> Is this:

[20:31] < MS-> + if not box_found:

[20:31] < MS-> + if not isinstance(item, threadedcomponent):

[20:31] < MS-> + item.stop()

[20:31] < MS-> + print 'stopping a component!'

[20:31] < MS-> + else:

[20:31] < MS-> + raise 'Threaded component does not have a control inbox!'

[20:31] < MS-> the problem (the way you're using .stop() )

[20:31] < MS-> or are you asking is

[20:31] < MS-> item.stop() a bad idea ?

[20:32] < MS-> It probably helps if I note that .stop() was originally expected to be used as

[20:32] < MS-> self.stop()

[20:32] < j_baker> I'm not really focusing on item.stop(). That can be something that I can note that is just for test cases or for toy components.

[20:32] < MS-> rather than some_component_I_can_see.stop()

[20:32] < MS-> I'm not getting you're question then :)

[20:32] < j_baker> There's two ways it can shut a component down.

[20:33] < j_baker> If it has a control inbox, it will connect to it and send a shutdownMicroprocess() message.

[20:33] < j_baker> Otherwise, it will call the stop() method.

[20:34] < j_baker> I do remember you saying that there were also problems with the way it sends the shutdownMicroprocess() message. I'm trying to understand if you feel it's something that can be refined or if you feel the problem is with the idea in general.

[20:34] < MS-> Ah, that does also assume that the component actually listens to message on the control box :)

[20:34] < MS-> I think it's worth remembering what you're dealing with here

[20:35] < MS-> The scheduler doesn't schedule components

[20:35] < MS-> It schedules microprocesses

[20:35] < MS-> In the past there were 2 sorts of microprocess schedules

[20:35] < MS-> scheduled

[20:35] < MS-> and today there are also two sorts of microprocess scheduled

[20:35] < MS-> (2 different sets)

[20:36] < MS-> shutdownMicroprocess can only be sent to a component

[20:36] < MS-> and a component can choose to implement itself such that it ignores that message

[20:36] < MS-> Next point

[20:36] < MS-> .stop() is *not* a component level method

[20:36] < MS-> it's a microprocess level method

[20:37] < MS-> and it's purpose isn't really to enable someone to kill a microprocess

[20:37] < MS-> it's purpose is to allow a microprocess to signifiy to the scheduler "I'm going to sleep, don't wake me up"

[20:38] *** Davbo has joined #kamaelia

[20:38] < MS-> It's part of a legacy API at *that* level, but one that has started to drift

[20:38] < Davbo> Evenin' folks

[20:38] < MS-> (Davbo: hi)

[20:38] < MS-> It started to drift because Lawouach wanted a way to shutdown the system cleanly, so

[20:39] < MS-> what happened was this

[20:39] < Davbo> Sorry about earlier, didn't want to be rude watching presentations and take out my laptop for the meeting

[20:39] < j_baker> Hello Davbo

[20:39] *** Davbo realises he's interrupting something

[20:39] < MS-> the scheduler (which is a microprocess) was changed such that if *it's* .stop() method was called

[20:40] < MS-> that the scheduler (which only deals with microprocesses, not components as far as its concerned)

[20:40] < MS-> would then loop through all it's components and call *their* .stop() methods

[20:40] < MS-> This doesn't mean the system as a whole guarantees clean shutdown - since it can't

[20:41] < MS-> But it does give a much cleaner way of doing an "application abort"

[20:41] < MS-> However using it in a generic component would be pretty nasty.

[20:42] < Davbo> So, how is everyone?

[20:42] < MS-> I'm fine, yourself? (tired)

[20:42] < MS-> So, when I say the system is moving in that direction, it's because the

[20:42] < MS-> scheduler can expect in certain scenarios to be able to call a .stop() method on a component

[20:42] < j_baker> Not too bad Davbo.

[20:43] < Davbo> Tired too, sat watching presentations for 3 hours

[20:43] < MS-> in a similar way to the way the scheduler can expect to call a .main() method on a microprocess

[20:43] < MS-> BUT, the key thing to note is that it's not a clean shutdown

[20:44] < MS-> It's much like a "kill -9" than a "kill " or "kill -HUP"

[20:44] < MS-> Does this mean it's an open issue and extra work is needed there? Yes.

[20:44] < MS-> Does it mean you can't manage shutdown? No.

[20:44] < MS-> It's just a bit harder than we'd all like at present.

[20:45] < MS-> So my suggestion is, given my caveats and warnings - keep trying what you're trying and see how it turns out :)

[20:45] < j_baker> I suppose like you said, it's all theoretical and there's not really any way to know what's happening.

[20:46] < j_baker> Or what could or couldn't go wrong.

[20:46] *** mhrd-home has joined #kamaelia

[20:46] < MS-> Unless you actually try stuff and find out.

[20:47] < j_baker> Instead of linking, sending a message, then unlinking, is it possible to just send a message to a component? Or do you think a splitter would be best?

[20:48] < Davbo> MS-: For those of us that are new to open source development. Could you maybe explain (or link an explanation) of what's required from a "review" of a branch before it's merged?

[20:48] < MS-> I'm really not sure. Since it naturally interrupts things it's unclear which is best. Generally I've used a splitter (specifically http://edit.kamaelia.org/Components/pydoc/Kamaelia.Util.Fanout.html )

[20:48] < MS-> to do that

[20:48] < Davbo> Or could someone point me in the right direction

[20:49] < j_baker> Ok, I'll just have to play around with it some, MS-.

[20:49] < MS-> j_baker: Cool :-)

[20:49] < j_baker> At least I have something to make testing easier on me. :)

[20:49] < MS-> Just wanted to let you know there may be issues :)

[20:49] < MS-> Definitely

[20:49] < MS-> If it works out for testing that'd be very useful

[20:50] < Davbo> s/those of us that are new to open source development/ me :-)

[20:50] < MS-> Davbo: It's not really specific to open source, it's more a matter of how good development happens whether or not it's open source :)

[20:50] < MS-> What it boils down to is looking for problems

[20:50] < MS-> :)

[20:51] < MS-> In practice, reviewing a branch normally means reviewing changes and looking for issues

[20:51] < Davbo> When we program things at university we cite who "checked" things for people, is it a simple matter of that. ie. look through the code, trace it and check inputs/outputs/logic

[20:51] < MS-> It's essentially that sort of thing, but in the case of a branch you're looking at diffs

[20:51] < MS-> when you're used to diffs, it gets quicker

[20:52] < Davbo> oh

[20:52] *** Davbo reads http://svnbook.red-bean.com/en/1.0/re09.html

[20:52] < Davbo> :P

[20:53] < mhrd-home> you can think of it from the perpective of someone contributing a set of changes to something you've built ...

[20:53] < mhrd-home> you'd want to look through it and try to understand what it does; and have a think to see if it might cause some unintended problems

[20:53] < Davbo> Right, I see

[20:53] < mhrd-home> you'd also want to think about whether it does things in a way you think is reasonable

[20:53] < mhrd-home> :)

[20:53] < MS-> This includes running tests (if existing) running the code (if you have the hardware)

[20:54] < MS-> sanity checking it, and if appropriate sanity checking the code style

[20:54] < MS-> ls

[20:54] < Davbo> okay, you guys are much more experienced so when I see "Okay I reviewed it" or something on the mailing list it seemed very definite as though there was a protocol to is

[20:54] < Davbo> s/is/it

[20:54] < MS-> (just getting a diff)

[20:55] < MS-> The thing to bear in mind is that often there will be a conversation about specific points on IRC

[20:55] < MS-> like for example I reviewed matt's branch last night

[20:55] < mhrd-home> indeed

[20:55] < MS-> The way I actually did that was like this:

[20:56] < MS-> svn diff -r< ver>:HEAD > diff.txt

[20:56] < Davbo> Yeah that's kinda what i was just looking at

[20:56] < MS-> I then open up the diff in a text editor

[20:56] < MS-> and first look for common changes

[20:56] < MS-> For example coderate_HP -> code_rate_HP

[20:57] < MS-> If I don't understand the change I query it

[20:57] < Davbo> right

[20:57] < MS-> If matt wasn't on IRC I would've collated the queries in a mail

[20:57] < Davbo> makes sense

[20:57] < MS-> But he was

[20:57] < MS-> :)

[20:57] < Davbo> Thanks MS-, mhrd-home

[20:57] < mhrd-home> np

[20:58] < MS-> There's more :)

[20:58] < MS-> Just doing a diff to get what I do next

[20:59] < MS-> The diff itself isn't just a file

[20:59] < MS-> It actually consist of file delimiters

[20:59] < MS-> and "hunks"

[20:59] < MS-> which mark specific changes

[20:59] < Davbo> umm, like what?

[21:00] *** MS- loosk for a pastebin

[21:00] < MS-> finds one

[21:00] < Davbo> I test on MagnaDoodle after

[21:00] < MS-> http://pastebin.com/m63f15314

[21:00] < Davbo> (but wouldn't i need to know the revision number for when i changed MagnaDoodle?)

[21:01] < MS-> We'll come back to that :)

[21:01] < MS-> If you scroll down to the source, you'll find that that pastebin has actually mangled the diff

[21:02] < MS-> great

[21:02] < Davbo> uhh :(

[21:02] < MS-> Oh the irony

[21:02] < Davbo> The Diff pastebin mangles diff's ?

[21:02] < Davbo> intriguing

[21:03] < Davbo> are the + marking a new line of code?

[21:04] < MS-> There - here: http://thwackety.com/paste.html

[21:04] < MS-> Yes, the diff pastebin mangled the diff

[21:04] < Davbo> okay, ty MS-

[21:04] < MS-> Files affected are clear

[21:04] < Davbo> so this marks changes between 3961 and 3988

[21:04] < Davbo> i guess

[21:04] < MS-> For each file, yes

[21:06] < MS-> That diff is a little mangled due to copy and paste as well but is clearer

[21:06] < MS-> New lines are marked +

[21:06] < MS-> deleted are marked -

[21:06] < MS-> But the bit that speeds things up

[21:06] < MS-> Are the lines labelled

[21:06] < MS-> @@ -38,8 +38,8 @@

[21:06] < MS-> and

[21:06] < MS-> @@ -176,11 +176,10 @@

[21:06] < Davbo> yeah i see

[21:06] < MS-> Since they're complete hunks

[21:07] < MS-> So

[21:07] < MS-> If you skim through a large diff quickly

[21:07] < MS-> and see lots of

[21:07] < MS-> stuff like

[21:07] < MS-> - "coderate_HP" : dvb3.frontend.FEC_3_4,

[21:07] < MS-> - "coderate_LP" : dvb3.frontend.FEC_3_4,

[21:07] < MS-> + "code_rate_HP" : dvb3.frontend.FEC_3_4,

[21:07] < MS-> + "code_rate_LP" : dvb3.frontend.FEC_3_4,

[21:07] < MS-> You realise "ah, so *that's* what the change is"

[21:07] < Davbo> uh-huh

[21:07] < MS-> When I'm happy with that

[21:08] < MS-> I then go through the diff and delete all the hunks that match that

[21:08] < MS-> Once you get used to it you get used to skimming for pattens and deleting hunks leaving some specific questions regarding style etc

[21:09] < Davbo> hmm right

[21:09] < MS-> Also, deleting from the diff gives you something really handy - you can "put the diff down"

[21:09] < MS-> and "pick it back up later" knowing what you have/haven't reviewed

[21:09] < Davbo> so delete all the things from the diff that you're alright with?

[21:10] < Davbo> and work your way through

[21:10] < MS-> Yep

[21:10] < Davbo> Okay, I see :)

[21:10] < MS-> That also means it's very clear at the end to be able to say "this I'm not happy with"

[21:10] < Davbo> and just send them the diff

[21:10] < vmlemon_> I've probably missed something, but how would you apply several diffs to a single component with various disparate changes in each?

[21:10] < MS-> And if you end up with something empty - either by asking q's along the way or its fine

[21:10] < MS-> then that's fine

[21:11] < Davbo> and then, merge?

[21:11] < MS-> vmlemon_: The diffs are generated by svn - the changes are already in the code

[21:11] < vmlemon_> Aah

[21:11] < MS-> Davbo: yep

[21:11] *** vmlemon_ was referring to manually made diffs, although he was just curious...

[21:12] < mhrd-home> I tend to use a clean checkout of trunk, merge into it, then try it out (clean install, run examples, etc) as my final check

[21:12] < MS-> I also tend to do a

[21:12] < MS-> svn merge --dry-run

[21:12] < MS-> first

[21:12] < MS-> to check it'd merge

[21:12] < Davbo> oh cool

[21:13] < Davbo> is --dry-run a common modifier?

[21:13] < MS-> It's specific to svn

[21:14] < Davbo> i meant like, can you do it on other svn commands?

[21:15] < MS-> Maybe, but not with commit for example

[21:15] < Davbo> Say, if one was paranoid about breaking things.

[21:15] < Davbo> ah

[21:15] < Davbo> Oh back to the point from before

[21:15] < MS-> Well, that's the thing - you can't break this irretrievanly

[21:15] < mhrd-home> doesn't seem to be common - "svn help < cmd>" reveals all

[21:16] < MS-> even

[21:16] < MS-> svn rm < branch>

[21:16] < MS-> svn co < branch>

[21:16] < MS-> can be undone

[21:16] < Davbo> how can i see which revisions had changes to MagnaDoodle or anything for that matter

[21:16] < Davbo> just the logs?

[21:16] < MS-> ah yes

[21:17] < MS-> Did you svn copy it in?

[21:17] < mhrd-home> svn blame < sourcefile> will list revision numbers and authors against each line

[21:17] < Davbo> yeah

[21:17] < MS-> cool

[21:17] < MS-> ~/kamaelia/trunk/Sketches/DK> svn log --stop-on-copy

[21:17] < Davbo> Hah mhrd-home (is that a joke?)

[21:17] < MS-> nope

[21:17] < mhrd-home> see for yourself

[21:18] < MS-> in cvs it used to be called "cvs annotate"

[21:18] < MS-> But blame is more appropriate

[21:18] < Davbo> hahaha

[21:18] < Davbo> awesome

[21:18] < MS-> ~/kamaelia/trunk/Sketches/DK> svn log --stop-on-copy|tac|tail -2|head -1

[21:18] < MS-> Gives you the specific version number for the branch

[21:19] < Davbo> I see

[21:20] < Davbo> evidently svn log has to parse a lot before it gets there

[21:21] < MS-> Sorry svn log --stop-on-copy|tac|tail -2|head -1 is wrong

[21:21] < MS-> (late)

[21:21] < MS-> But the --stop-on-copy thing is what you want :)

[21:21] < MS-> ~/kamaelia/trunk/Sketches/DK> svn diff -r3937:HEAD MagnaDoodle.py

[21:21] < MS-> Will show you what you're done :-)

[21:22] < MS-> And it's also why I asked you to do an svn copy

[21:22] < Davbo> I see

[21:22] < MS-> since it also makes it easier for *me* to see what's changed

[21:22] < Davbo> Yeah

[21:22] < Davbo> that's cool

[21:24] < Davbo> Again, thanks MS-, mhrd-home

[21:24] < Davbo> I'll get there eventually :)

[21:24] < MS-> this is what GSOC is really about

[21:24] < Davbo> & stop pestering you two

[21:24] < Davbo> ;-)

[21:27] < mhrd-home> it really is np

[21:27] < mhrd-home> :)

[21:30] < Davbo> I got 62/100 on the stupid Java assembly thing

[21:31] < Davbo> 2.1, pretty good

[21:40] < Davbo> Hopefully you'll get my contributor agreement tomorrow MS-, long weekend and all.

[21:40] < Davbo> Will take you ages to get through your email on tuesday :)

[21:40] < MS-> cool

[21:41] < MS-> I'm out of the office tomorrow (work), and then on leave, back thursday - so won't get it till then at the soonest

[21:41] < MS-> congrats on the result

[21:41] < Davbo> Ah, oh yes

[21:41] < Davbo> the meeting got changed right

[21:42] < MS-> Probably worth looking at the minutes :)

[21:42] < MS-> It's either scrapped or can be on friday

[21:42] < MS-> I may or may not be going away

[21:42] < Davbo> Yeah have done, just forgot to sort something out with you

[21:42] < MS-> hasn't actually been decided yet

[21:43] < Davbo> Well if it's Friday I suggest we scrap and just go with it on Monday

[21:43] < Davbo> Assuming the following monday is okay

[21:43] < MS-> seems sensible to me

[21:44] < Davbo> Okay :)

[21:56] *** MS- changed the topic to Release Wiki here: http://edit.kamaelia.org/ReleaseJune2008 u/p : wiki/wiki | Next weekly meeting 4pm 29th May 2008 | Don't ask to ask, just ask (channel is logged: http://yeoldeclue.com/logs/ )

[21:57] < MS-> please feel free to update the release/release discussion page

[21:57] < MS-> with things you want to add in/sort out

[21:58] *** Davbo wonders if he would be too enthusiastic to review something from your branch (MS-) for merging

[21:59] < MS-> I have to extract the feature out to a branch first

[21:59] < Davbo> Could I review the stuff i'm using (MultiProcess.py)

[21:59] < MS-> You're welcome to try doing that yourself if you like, in a similar way I've extracted some of Jinnas stuff

[22:00] < MS-> The multiprocess stuff would be *extremely* useful

[22:00] < MS-> since you're actually using it

[22:00] < MS-> You'd need to think of an answer to this question:

[22:00] < MS-> http://yeoldeclue.com/cgi-bin/blog/blog.cgi?rm=viewpost&nodeid=1209413487

[22:00] < MS-> "Where to put our Multicore support in the Kamaelia tree?"

[22:00] < Davbo> Ah

[22:01] < Davbo> I see

[22:01] < MS-> And that's very much a matter of opinion

[22:01] < MS-> and something worth doing :-)

[22:01] < MS-> It would also mean looking at the changes to the scheduler as well

[22:01] < MS-> which is an important detail

[22:01] < MS-> (it's minor btw)

[22:01] < Davbo> umm

[22:02] < Davbo> I wanna try

[22:02] < Davbo> Does it matter if I can't get my head round it#?

[22:02] < MS-> Depends on what you can't get your head round :)

[22:02] < Davbo> Well if I make a diff then leave in what i don't understand and post to the ML someone could explain :-)

[22:03] < MS-> You're probably well placed to think "where does this code made sense"

[22:03] < MS-> (ie "where to put the file currently called MultiProcess.py")

[22:04] < MS-> ~/kamaelia/branches/private_MPS_Scratch/Axon> svn diff -r3813:3827 Axon/

[22:05] < MS-> is the main changeset needed I think

[22:05] < Davbo> right

[22:05] < MS-> That's the change set that keeps the print statements in used during debugging

[22:05] < Davbo> uh-huh

[22:06] < MS-> OK, I need sleep

[22:06] < MS-> I have a stupidly early train tomorrow :-/

[22:06] < MS-> cya :)

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

[22:07] < vmlemon_> Night

[22:17] < Davbo> Heh, the spell checker in WordPress highlights blog as a typo

[22:17] < Davbo> s/typo/spelling error

[22:19] < j_baker> night MS-

[22:19] < j_baker> It probably uses the PHP spellchecking library Davbo.

[22:20] < Davbo> yeah, i'm pretty sure it does. But it still makes me giggle :-)

[22:23] < j_baker> Indeed.

[22:23] < Davbo> undermines their whole thing, it's not even a real word! ;-)

[22:32] < vmlemon_> o.O "Maybe I'll make a new one with a bunny in it so people can be bunny-free if they want. It's all about freedom, right?"

[22:34] < vmlemon_> Let me guess, it also thinks "WordPress" isn't a word/is spelt incorrectly, too?

[23:09] < Davbo> Anyone got thoughts on http://www.davbo.org/blog/2008/05/22/kamaelia-multicore-support/ ?

[23:12] *** Davbo isn't sure if he actually makes a valid point

[23:12] < mhrd-home> my gut feeling is that you're probably right, thoguh I'm not sure 'process' is quite the right word

[23:15] < Davbo> Ah.

[23:15] < mhrd-home> a name like "multicore" implies to me something a little more finegrained and quite low level

[23:16] < Davbo> Yeah

[23:16] < mhrd-home> "process" feels better - since its effects at that kind of level

[23:16] < mhrd-home> actually "multicore" implie to me that it would be something to do with managing multiple cores in some way

[23:16] < Davbo> essentially it's process manipulation, nothing to do with multicore

[23:16] < mhrd-home> I suppose I'm thinking "process", "fork", "thread"

[23:17] < mhrd-home> Davbo: yep

[23:17] < Davbo> if you have multicore there's an advantage there but it's upto the OS

[23:17] < Davbo> i was trying to point out that there's more to it than just multicore support

[23:18] < Davbo> Say if i had a grid of computers at my disposal all networked up and wanted to split the workload, it would be cool if we could handle that

[23:19] < mhrd-home> also this component is presumably useful on non multicore systems (eg. dual CPU, or even single CPU, eg. hyperthreaded)

[23:19] < mhrd-home> s/useful/immediately useful/

[23:19] < Davbo> I edit my post :-)

[23:19] < Davbo> needed to order my thoughts a bit

[23:20] < mhrd-home> feels like something worth posting on the mailing list too (even if its just a link to your post)

[23:20] < Davbo> yeah will do

[23:20] < Davbo> ty mhrd-home. needed to talk it through a bit

[23:21] < mhrd-home> np

[23:47] < Davbo> fyi mhrd-home: http://groups.google.com/group/kamaelia/browse_thread/thread/35b4e7f4c9459773

[23:57] < mhrd-home> cool

[23:58] *** mhrd-home finally gets some code working so calls it a night

[23:58] < mhrd-home> cya tomorrow I guess :)