[01:14] *** zaheer_ has joined #kamaelia

[02:54] *** zaheer__ has joined #kamaelia

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

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

[06:50] < Lawouach_> morning all

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

[08:25] *** zaheer__ is now known as zaheerm

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

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

[11:01] < orphans> Lawouach, ping?

[11:02] < orphans> or Lawouach_, why not :)

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

[11:05] < Lawouach> pong

[11:05] < vmlemon_> Hi

[11:05] < Lawouach> I'm going back to work in a few minutes, I'll ping you back from there orphans

[11:05] < orphans> k, tis just a quick silly question - no rush

[11:06] < Lawouach> ask it anyway and I'll reply when I'm back :)

[11:06] < Lawouach> should be in 30mns or so

[11:11] < orphans> k - should I be looking for a shutdownMicroprocess or a producerFinished or both for closing components generally? I think (for something like the OSC component) I should be only looking for shutdownMicroprocess, as two different producers may be connected to the one inbox, and so it'll shut down before you really want it to. Quite a lot of components I've seen shutdown on both though. Why is that, and what should I be do

[11:11] < orphans> ing?

[11:11] < orphans> long :D

[11:11] < orphans> s/do ing/doing

[11:21] < orphans> < = off to get lunch

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

[11:31] < Lawouach_> back

[11:32] < Lawouach_> orphans: It's a tricky one I can't really help with because the closing down of components is still slightly unclear in my mind.

[11:32] < Lawouach_> The problem is that Axon is quite unclear as to whethe ror not it propagates both messages down to each children and children of children

[11:33] < Lawouach_> I've put that aside until recently but I think i'll have to look at it more with headstock.

[11:33] < Lawouach_> The doc says you can ovewrite _closeDownComponent() and return a shutdownMicroprocess

[11:34] < Lawouach_> When I look at the code inside Axon it's unclear what happens next

[11:34] < Lawouach_> Maybe ms-away or mhrd-afk could clarify

[11:36] < Lawouach_> I think it's a matter of perspective

[11:37] < Lawouach_> When a component receives a producrFinished, it knows that a component that was linked to its control notifies that it has nothing more to do. It did its job.

[11:38] < Lawouach_> A shutdownMicroprocess means that another component notifies the receiving one it has shutdown, likely on error or because it was requested to.

[11:38] < vmlemon> o.O 06:36 < dre^> you should really consider switching to a non-fossil based midnight working fuel

[11:38] < Lawouach_> This could lead the receiving component to shutdown as well if it considers this was an error the sending component terminated unexpectedly.

[11:39] < Lawouach_> In other words, use producrFinished when things terminates as expected and shutdownMicroprocess otherwise.

[11:39] < Lawouach_> That's my take on it.

[11:40] < orphans> Lawouach, ok, cool. What messages should I be looking for to shut down the component though?

[11:41] < Lawouach_> Again it depends on your perspective.

[11:41] < orphans> From the docs I kinda get the impression that a shutdownMicroprocess is "shut down or else", and a producerFinished is "maybe shutdown in a, b and c happen"

[11:41] < orphans> s/in/if

[11:42] < Lawouach_> That's what I said :)

[11:42] < orphans> yeah, cool :)

[11:42] < orphans> are there any specifics to what a b and c are though?

[11:42] < Lawouach_> When you know the use cases in which your component can be terminated (out of its main function) then producrFinished

[11:42] < orphans> or is it up to the component really

[11:42] < Lawouach_> Otherwise shutdown

[11:42] < Lawouach_> It is up to the component indeed

[11:43] < Lawouach_> If you take a TCPClient component, it makes sense that it shutdowns when the peer closed the connection down unexpedtely

[11:43] < Lawouach_> But if the peer sent a message informing TCPClient it will close down the connection, then producrFinished would sound correct

[11:43] < Lawouach_> It's a matter of context and perspective.

[11:43] < Lawouach_> What you receive and what you want to send

[11:44] < orphans> yeah, I think I get it - it's quite a fine distinction

[11:44] < Lawouach_> One of your child may die aburptly and you may receive a shutdown. But you could still consider it ok and send a producrFinished later on.

[11:44] < orphans> uh huh

[11:45] < Lawouach_> And don't be fooled, this is actually a critical distinction that can have a very big impact on how your application will behave

[11:45] < orphans> right, I'll work from that and see how it all pans out :) Cheers Lawouach_

[11:46] < Lawouach_> np

[11:49] < ms-away> "Maybe ms-away or mhrd-afk could clarify"

[11:49] *** ms-away reads

[11:49] < Lawouach_> Ta

[11:50] < ms-away> shutdownMicroprocess means "die, die now"

[11:50] < ms-away> producerFinished means "OK, I'm done"

[11:51] < ms-away> That's the crux of it

[11:52] < ms-away> Regarding this:

[11:52] < ms-away> "two different producers may be connected to the one inbox"

[11:52] < Lawouach_> But that's where it's interesting to notice that the former gets a status from another component when the former gives a direct order

[11:53] < Lawouach_> It's subtle

[11:53] < ms-away> Yes, it is.

[11:53] < ms-away> The problem is really related to what happens in a pipe

[11:53] < ms-away> producerFinished is like "OK, no more data is coming on stdin"

[11:54] < ms-away> shutdownMicroprocess is equivalent (really) to receiving a message saying

[11:54] < ms-away> gah

[11:54] < ms-away> recieving the result of a "kill -< sigspec> < pid>"

[11:55] < orphans> yeah, that makes sense. So following the analogy something like grep stops when it receives producerFinished, whereas something like less lives on

[11:55] < orphans> and that kinda thing determines whether your component wants to shutdown on a producerFinished

[11:55] < ms-away> (such as SIGPIPE)

[11:56] < ms-away> orphans: Yep

[11:56] < ms-away> The topology visualiser is another good example

[11:56] < Lawouach_> Interestingly there is no way for a component to say "I was killed" in such case. producerFinished doesn't seem right in such case.

[11:57] < ms-away> Lawouach_: well, you could, but generally components just pass the shutdownMicroprocess on

[11:57] < ms-away> But there isn't (for example) support inside the scheduler to inject the equivalent of a SIGPIPE (ie broken pipe) to the "next" component in a chain

[11:58] < ms-away> maybe there should be

[11:58] < ms-away> It'd be interesting to see which usecases it simplified

[11:58] < ms-away> (if it did :) )

[12:00] < ms-away> I think chained shutdown in an automatic fashion (which is related) is at present an open issue.

[12:01] < ms-away> Since the last thing we want is (for example) a broken TCP connection in a proxy causing the entire system to shutdown. (clearly an example of going too far)

[12:02] < ms-away> Likewise, if there was an exception that caused a TCP connection to die, auto-shutdown pass on would be really useful, so it's not obvious.

[12:02] *** ms-away suspects that someone has already solved this before

[12:02] *** ms-away really ought to given mascot & erlang a proper look at some point

[12:03] < ms-away> (mascot's model is closer to kamaelia than erlang IIRC though)

[12:03] < Lawouach_> Well

[12:03] < Lawouach_> the CSA does uses Ipc.socketShutdown in place

[12:04] < Lawouach_> It seems Kamaelia had to bring a set of per-use-case "something wrong happened" messages

[12:04] < Lawouach_> So in essence the problem was dealt with but not in a generic kind of way like producerFinished and shutdownMicroprocess

[12:05] < ms-away> Well

[12:05] < ms-away> class socketShutdown(producerFinished):

[12:05] < ms-away> """Message to indicate that the network connection has been closed."""

[12:05] < ms-away> pass

[12:05] < ms-away> The problem is though that that's not really sufficient either (having looked at it)

[12:06] < ms-away> on private_MPS_HalfCloseSupport there's also support been going in for a little while

[12:06] < ms-away> which needs to diffrentiate between these:

[12:06] < ms-away> def shutdownSending(self):

[12:06] < ms-away> self.socket.shutdown(socket.SHUT_WR)

[12:06] < ms-away> self.connectionSENDLive = False

[12:06] < ms-away> def shutdownReceiving(self):

[12:06] < ms-away> self.socket.shutdown(socket.SHUT_RD)

[12:06] < ms-away> self.connectionRECVLive = False

[12:07] < ms-away> def shutdownBoth(self):

[12:07] < ms-away> self.socket.shutdown(socket.SHUT_RDWR)

[12:07] < ms-away> self.connectionRECVLive = False

[12:07] < ms-away> self.connectionSENDLive = False

[12:07] < ms-away> So the CSA is a pretty useful pathological case of these sorts of things

[12:07] < ms-away> for many things, receiving from the socket is find

[12:07] < ms-away> gah

[12:08] < ms-away> for many things producerFinished & shutdown are fine

[12:08] < Lawouach_> indeed

[12:08] < ms-away> But yes, domain specific things are needed too sometimes

[12:08] < ms-away> I suspect the codebase is getting to the size where it's going to become clear what the separation really needs to be as well.

[12:10] < Lawouach_> Well I'm feeling still really not ease with the way I shutdown my XMPP client. I'm using shutdownMicroprocess but I'm not sure it is propagated correctly to all my components.

[12:10] *** ms-away nods

[12:10] < Lawouach_> That makes me uneasy for long running processes.

[12:10] < ms-away> That's the kind of statement that worries me

[12:10] < Lawouach_> I feel I don't control it :)

[12:11] < Lawouach_> Too bad I haven't comitted my code I would have shown you what i do

[12:11] < ms-away> *shrug*

[12:11] < Lawouach_> Anyway this is the one single area where I can't really be sure of what is going on under the hood.

[12:11] < Lawouach_> I think this will be a problem with GSoC applications this year.

[12:12] < ms-away> It's probably because its the one area that has the largest area of uncertainty at present

[12:12] < ms-away> I'm sure it will.

[12:12] < Lawouach_> heh :)

[12:12] < ms-away> There's some headaches that I expect to have, but then they say necessity is the mother of invention :)

[12:12] < ms-away> It's certainly aleady changed the topology visualiser after all

[12:15] < Lawouach_> :)

[12:48] *** ms-away thanks Lawouach_ for making me see something I hadn't read right

[13:02] < Lawouach_> I believe I can fly.

[13:02] < Lawouach_> I believe I can touch the skyyyyyyyyyyyyyyyyyyyy

[13:03] < vmlemon> Really? ;)

[13:03] < vmlemon> Have you tried it?

[13:03] < vmlemon> ;)

[13:04] < Lawouach_> I wouldn't say I believe now would I?

[13:05] *** vmlemon hands Lawouach_ a pair of (knitted) wax wings ;)

[13:06] < ms-away> I know I can fly.

[13:06] < ms-away> Just requires a plane

[13:06] < ms-away> :)

[13:06] < vmlemon> So much easier

[13:06] < Lawouach_> So British. The easy way out.

[13:07] < vmlemon> Does the Chunnel count? Although it doesn't fly

[13:33] < ms-away> vmlemon: Depends on whether you use the Chunnel as a canon or not

[13:33] < ms-away> If you do, then probably, but it'd be the oddest route to scotland that I've come across

[13:33] < ms-away> :)

[13:37] < vmlemon> Hah

[13:37] < vmlemon> I haven't used it, but can you even get to Scotland (or Wales) on the Chunnel?

[13:38] < Lawouach_> You can't get to Scotland. There's a wall somewhere in the middle.

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

[15:14] < Lawouach_> http://www.25hoursaday.com/weblog/2008/05/21/NoteToWeb20CompaniesEarlyAdoptersAreNotTheMassMarket.aspx

[15:15] < Lawouach_> I can't agree more with Dare's opinion here.

[15:15] < Lawouach_> Not always the case :)

[15:20] < vmlemon_> kamaeliabot: dance

[15:20] Reply: does the macarena

[15:38] < Lawouach_> http://highscalability.com/how-i-learned-stop-worrying-and-love-using-lot-disk-space-scale < -- one article that wouldn't fit the University's mindset :)

[15:41] < Lawouach_> well at least my teachers would have killed the guy

[15:41] < Lawouach_> Like some of my previous bosses

[15:58] *** Davbo has joined #kamaelia

[16:02] < Davbo> Afternoon all

[16:09] < Davbo> If anyone else is like me and reads: http://www.penny-arcade.com/ - they'll be happy to know that the Penny Arcade game is out today :)

[16:09] Reply: Hm?

[16:09] < Davbo> On Linux too :)

[16:10] < Davbo> www.playgreenhouse.com

[16:10] < Davbo> rare you see a game on Linux, unfortunately

[16:13] < Lawouach> back

[16:24] < ms-away> That link on big table is useful Lawouach - ta

[16:25] < ms-away> I've been trying to explain that to someone, and the focus there is useful

[16:29] < Lawouach> eh eh

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

[17:48] *** ms-away finds a way of reducing someone else's code from >400 lines down to 10 lines

[17:49] < vmlemon_> By taking out all the newlines? ;)

[17:50] < ms-away> No, by recognising the inherent duplication in their code could be sidestepped :)

[17:51] < vmlemon_> Aah

[17:52] < ms-away> [off

[17:53] < vmlemon_> Sounds fun

[17:53] < ms-away> Yeah.

[17:53] < ms-away> Like a brick wall

[17:54] < vmlemon_> Does that include using 3rd party code/frameworks to do the job?

[17:54] < ms-away> Oh like you wouldn't believe

[17:55] < ms-away> I think the amusing aspect here is I've essentially optimised out all their types :-)

[17:55] < ms-away> Since I don't need them :)

[17:59] *** vmlemon_ contemplates trying to make something that somewhat resembles a Linux distribution on top of QNX...

[17:59] < vmlemon_> Albeit without the Linux bit

[18:05] < j_baker> ms-away: I think I've finalized the Logger. I think it's been simplified a lot from what I originally intended to do.

[18:06] < vmlemon_> (Nothing against Linux, but I'm up for a challenge ;))

[18:49] < ms-away> j_baker: Cool

[18:50] < ms-away> I'll take a look later this evening hopefully :)

[18:50] < j_baker> I posted a little bit more detail about it on the list.

[18:50] < ms-away> I just saw :)

[18:52] < j_baker> Btw, is there necessarily such thing as committing too much? I've probably made several commits for the logger just today.

[18:52] < ms-away> If you go OTT I'll mention it.

[18:52] < ms-away> Personally I don't think so, but I can see how to make it OTT :)

[18:53] < j_baker> Ok, just wanted to make sure I wasn't annoying anyone with a ton of commit emails. :)

[18:53] < ms-away> Probably an issue when the updates can be measured as a frame rate :)

[18:53] < j_baker> lol

[19:08] < j_baker> So does anyone here have an opinion on what a good email client for Linux is? (it has to support exchange)

[19:13] < ms-away> kmail

[19:13] < ms-away> If you want to use it with exchange and need the calendaring, then you'll want to use Kontact which uses kmail for the mail component

[19:14] < ms-away> And the calendaring messages will get passed through to korganiser

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

[19:26] < j_baker> Works for me. I'm using KDE on this computer.

[19:39] < ms-away> I was using KDE when all the zealots were still upset by it

[19:39] < ms-away> :)

[19:43] < j_baker> "But it's too pretty!"

[19:46] < ms-away> Nah, they were upset that someone used a license that wasn't the GPL, essentially.

[19:47] < ms-away> Which is a little harsh, but IMO true

[19:59] *** mhrd-home has joined #kamaelia

[20:03] < vmlemon_> The Qt thing?

[20:04] < vmlemon_> (Trolltech's QPL license)

[20:04] < mhrd-home> greetings

[20:04] < vmlemon_> Nout wrong with KDE or Qt

[20:04] < vmlemon_> Hi mhrd-home

[20:04] < vmlemon_> They look much better than GNOME and GTK in my opinion

[20:05] < vmlemon_> GTK screams "Motif Reincarnated" to me, for some reason

[20:07] < mhrd-home> wrt shutdown signal discussion earlier today ...

[20:07] < mhrd-home> my view is similar to MS-'s ... the producerFinished and shutdownMicroprocess messages are like signals

[20:09] < mhrd-home> personally, I've treated shutdownMicroprocess as a request to "stop immediately" (an instruction) ...

[20:09] < mhrd-home> and producerFinished as "the data has dried up" (informational) aka "stdin has closed" ...

[20:10] < mhrd-home> the majority of components we've written have been for the purposes of taking in data, processing it, then passing it on ...

[20:11] < mhrd-home> in which case the behaviour that has made sense to me is to react to both messages by stopping (and passing the message on out of the "signal" outbox)

[20:11] < mhrd-home> however in the case of a producerFinished message - also finishing processing any pending data (eg. waiting at an inbox) first

[20:12] < mhrd-home> the recent change to TopologyViewer is the first component that, to me, made sense to *not* stop on receiving a producerFinished message

[20:12] < ms-away> There could be others of course :)

[20:12] < ms-away> (hi btw :) )

[20:13] < mhrd-home> For systems I've built using Kamaelia; I've come to view wiring up the "control"->"signal" paths as the way to control the shutdown process - eg. in a few cases purposely putting in splitters or other component to ensure shutdown msgs get to the right place

[20:13] < mhrd-home> ms-away: indeed (and hi :-) )

[20:14] < mhrd-home> if I've wanted to deviate from the 'usual' behaviour I've described, then I've put in different wiring, or even filtering for the "control"->"signal" path

[20:14] < ms-away> Yep

[20:14] < mhrd-home> < /braindump>

[20:14] < ms-away> ditto

[20:14] < mhrd-home> (that said, sometimes its ended up rather messy :-) )

[20:15] < mhrd-home> however I do kinda like it (the ability to purposely author the shutdown process) ... but perhaps thats because I've gotten used to it :)

[20:17] < ms-away> Quite possibly

[20:17] < ms-away> I think that any changes would be syntactic sugar to assist it, rather than replace it

[20:17] < vmlemon_> I'm not too familiar with Kamaelia, but isn't there some sort of "Safe Landing"/clean shutdown component to assist with that sort of stuff? Or is it something that the developer has to take care of entirely by themselves?

[20:17] < ms-away> A bit like the Backplane code is at the end of the day just a splitter

[20:18] < ms-away> vmlemon_: I'm not sure what that would do if it existed, but it's an interesting idea

[20:18] < mhrd-home> ditto

[20:19] < vmlemon_> I assume that it would introspect the Kamaelia system, and see what's running, and then signal it to stop in sequence before safely stopping the app

[20:19] < vmlemon_> (similar in concept to SysV init shutdowns)

[20:20] *** mhrd-home wonders what it would be like if Axon trapped exceptions in components and initiated some kind of controlled termination of the component; maybe sending out an exception msg (subclass of shutdownMicroprocess perhaps)

[20:20] < vmlemon_> Although it would probably need cooperation from components

[20:23] < mhrd-home> vmlemon_ : you thinking of handling error conditions? or getting the system to stop cleanly when it has finished doing whatever its doing? (or am I barking up the wrong tree? :-) )

[20:24] < vmlemon_> Essentially getting the whole app and components it uses to stop cleanly in sequence

[20:24] < vmlemon_> Although it's just an idle brainfart/musing, so you can ignore it at will ;)

[20:24] < ms-away> "(similar in concept to SysV init shutdowns)"

[20:24] < ms-away> Hm, that's an interesting idea

[20:25] < ms-away> and potentially applicable

[20:25] < ms-away> maybe not directly, but it *is* interesting

[20:25] < mhrd-home> how do SysV init shutdowns work ooi? just sending kill signals to the tasks?

[20:25] < ms-away> I'll have a ponder :)

[20:25] < ms-away> cheers :)

[20:25] < ms-away> mhrd-home: essentially, yes

[20:26] < ms-away> But in a defined order base on the run level information encoded into the file names

[20:26] < ms-away> (essentially)

[20:26] < vmlemon_> Yay, my half-ISO st

[20:27] < vmlemon_> *still boots after gluing additional chunks of the file to it

[20:27] < ms-away> :)

[20:27] < Lawouach> One thing Axon doesn't deal well with is KeyboardInterrupt exceptions.

[20:27] < Lawouach> It'd be really nice indeed that we could handle such signals

[20:28] < mhrd-home> slightly related - some mechanism to collect/detect/react to signals would be interesting (eg. a CAT service for collecting signals)

[20:28] < mhrd-home> snap :)

[20:28] < vmlemon_> I ended up downloading it onto a shell server, splitting it into 3 100MB chunks (well 2 100MB ones, and I think 1 45MB chunk), and then breaking the 2nd part of the ISO into 2MB parts (after moving the other two onto a USB drive over FTP)

[20:29] < vmlemon_> It sounds confusing, but it seems to work

[20:29] < vmlemon_> Seeing as I only have a crappy connection at home

[20:29] < ms-away> The STM code opens up interesting options in these areas BTW, since it really is a threadsafe way of sharing values.

[20:33] *** vmlemon_ wonders if it'll now copy over the help files that it seemingly skipped without giving a warning, seeing as they're probably stored in other segments of the ISO

[20:43] *** vmlemon__ has joined #kamaelia

[20:45] *** vmlemon__ is now known as vmlemon_

[21:39] < ms-away> interesting:

[21:39] < ms-away> http://nodebox.net/perception/?cake&depth=l

[21:44] *** ms-away has backed up everything from sourceforge

[21:44] < ms-away> (website related)

[21:44] < ms-away> Now doing secondary backup

[21:46] < ms-away> Looks like that could take a while

[21:46] < vmlemon_> Ugh, "Last week, I published a post on the "iPod of film cameras." Lucky for me, the post didn't include an image of an iPod Classic. That's because Apple has just trademarked the iPod shape. I cannot, for obvious reasons, show you the shape directly, so instead, allow me to show you its various subcomponents. It is up to you, dear reader, to perform the requisite mental assembly:"

[21:46] < ms-away> heh

[21:47] < ms-away> delightful

[21:47] < ms-away> Was it magenta as well

[21:47] < ms-away> ?

[21:47] < vmlemon_> (http://bp2.blogger.com/_swGyNR8UhGg/SCmr18eU2kI/AAAAAAAAALM/yrv5mMSGX_Y/s400/ipod_pieces.gif being the image it refers to)

[21:47] < vmlemon_> Hah, it was neither magenta, or knitted ;)

[21:47] < vmlemon_> Found it at http://onqpl.blogspot.com/2008/05/using-robots-to-address-serious-kneed.html

[21:49] < vmlemon_> Article on it at http://blog.wired.com/gadgets/2008/05/apple-trademark.html (it has the obligatory magenta mention, too) ;)

[21:50] < ms-away> Rather surreal

[21:50] *** vmlemon_ never knew it would come to that

[21:51] < vmlemon_> Hah, "Sensenon: In 2001 Australia adopted new patent laws, and just to show how flawed they were, a lawyer filed and received a patent for the wheel simply by renaming it a "circular transportation facilitation device"!" (one of the comments)

[21:52] *** mhrd-home decides to finish adding docs to his dvb fixes branch then mark it ready for merge (otherwise I'll end up rolling lots of new stuff in and bloating it)

[21:53] *** ms-away continues waiting for the download he's doing to finish

[21:53] < ms-away> Patenting the wheel ?!

[21:53] < vmlemon_> A so-called "Innovation Patent"

[21:53] < ms-away> Seems true: http://news.bbc.co.uk/1/hi/world/asia-pacific/1418165.stm

[21:54] < vmlemon_> I remember reading something a while ago about Ford forcing a motoring hobbyist group to stop producing calendars with photos of their cars on due to some weird trademark related thing, ages ago

[21:54] < ms-away> " The new innovation patent can be prepared without professional help and only requires claimants to show "innovation", not "invention"."

[21:54] < ms-away> That's scary

[21:54] < ms-away> Yeah, I've heard about the car thing before

[21:54] < vmlemon_> I think the fact that they mentioned "Ford" a load of times on the calendar despite it being unofficial didn't help, either

[21:56] < ms-away> Probably

[21:57] < vmlemon_> Still makes me wonder why it's possible to trademark the physical characteristics of an object, though

[21:57] < vmlemon_> I can see why someone would want to patent one that's non-trivial/non-obvious depending on how it's constructed, although I wouldn't think of trademarking something like that

[22:00] *** vmlemon_ would consider something like a cube, or the wheel to be trivial, and perfectly obvious for those purposes...

[22:21] < ms-away> OK, http://edit.kamaelia.org/and http://132.185.142.2/ should now be different

[22:23] < j_baker> I get a 404 with the first and a fish message with the second.

[22:24] < vmlemon_> Tried removing the "/and"?

[22:24] < vmlemon_> (looks like a typo)

[22:25] < j_baker> Ah. Get a giant cat.

[22:25] < vmlemon_> Yay

[22:28] < vmlemon_> Fish message with the IP address

[22:28] < vmlemon_> Big cat with the first URL

[22:35] < ms-away> cool

[22:35] < ms-away> ta

[22:39] *** vmlemon_ wonders if the cat's favourite food is trout ala creme ;)

[22:51] < vmlemon_> Night

[22:52] < mhrd-home> night vmlemon_

[22:54] < ms-away> http://edit.kamaelia.org/Home

[22:55] < ms-away> (not yet edittable, but getting there)

[22:56] < ms-away> Pretty good start for this evening IMO

[22:58] *** mhrd-home takes a look....

[23:00] < mhrd-home> yay, wiki editing again :-)

[23:00] < ms-away> Shouldn't actually save ... :)

[23:00] < mhrd-home> oh :-( :-)

[23:00] < mhrd-home> well its a good start :)

[23:01] < ms-away> Indeed

[23:01] < ms-away> I'm in the process of trying to put an ad-hoc patch on to re-enable editting

[23:05] < ms-away> OK, http://edit.kamaelia.org/cgi-bin/Wiki/edit/Components?mode=edit is partway there

[23:05] < ms-away> requires username/password to edit

[23:05] < ms-away> which is wiki/wiki

[23:05] *** sadrul has joined #kamaelia

[23:05] < ms-away> (for now)

[23:05] < ms-away> But doesn't redirect to right places (yet)

[23:12] < ms-away> OK, wiki re-enabled

[23:12] < ms-away> The edit link requires a username/password of wiki/wiki

[23:12] < ms-away> It's primarily there to keep out spammers

[23:12] < ms-away> among other people...

[23:17] *** ms-away changed the topic to wiki here: http://edit.kamaelia.org/Wiki u/p : wiki/wiki | Next weekly meeting 4pm 22nd May 2008 | Don't ask to ask, just ask (channel is logged: http://yeoldeclue.com/logs/ )

[23:17] < ms-away> But I can find out :)

[23:18] < mhrd-home> google knows :)

[23:18] < mhrd-home> (or more to the point, if google doesn't, then does anyone?!)

[23:19] < ms-away> My logs will know :)

[23:19] < ms-away> (server logs)

[23:20] < ms-away> Last time crawled was may 4th by google

[23:21] < ms-away> Interestingly msn's bot seems rather incapable.

[23:21] < ms-away> So the answer is yes, but not often

[23:21] < ms-away> So that gives me time to change the way the logs are served.

[23:22] < ms-away> (specifically to spit out an HTTP 404 status)

[23:22] < ms-away> indeed

[23:22] < ms-away> For the moment it's fine

[23:22] < mhrd-home> cool

[23:23] < ms-away> Since this isn't (yet) pushing out to kamaelia.sourceforge.net

[23:23] < ms-away> And not advertised anywhere yet

[23:23] < mhrd-home> indeed

[23:23] < ms-away> But it will mean I can start evolving the site better now

[23:24] < ms-away> since aside from anything else, there won't be files I can't change the permissions of (!)

[23:24] < ms-away> (sf is a very very odd place to host a wiki/etc)

[23:24] < mhrd-home> branch private_MH_20080518_DvbFixes now ready for merge (have posted to list). The list of changed files looks scary, but most a one or two line changes, or mods to docstrings

[23:24] < ms-away> Cool

[23:25] < mhrd-home> editing the site again will be cool :)

[23:25] < ms-away> indeed

[23:25] < ms-away> Nice thing is it also actually feels nippier

[23:26] < mhrd-home> heh, dare I say, it'd be hard to make hosting much slower than sf's :-)

[23:26] < ms-away> True

[23:27] < mhrd-home> doesn't change the fact that improved nippiness will be extremely welcome :)

[23:27] < ms-away> true

[23:28] < ms-away> Will be particularly nippy at work :)

[23:29] < ms-away> coderate -> code_rate ?

[23:29] < ms-away> seems an odd change?

[23:30] < mhrd-home> turns out it always was code_rate

[23:30] < mhrd-home> we were mistyping it all this time

[23:31] < mhrd-home> it just so happened the hauppauge boxes had sensible defaults when it wasn't specified

[23:31] < mhrd-home> but the usb sticks didn't - and therefore showed up the problem

[23:31] < ms-away> ah

[23:32] < ms-away> def notLocked(fe):

[23:32] < ms-away> ...

[23:32] < ms-away> return (fe.read_status() & dvb3.frontend.FE_HAS_LOCK) == 0

[23:32] < ms-away> ?

[23:33] < mhrd-home> ?

[23:33] < mhrd-home> is that not in there?

[23:34] < ms-away> Ah, was just checking it was correct

[23:34] < ms-away> and just found mail

[23:34] < ms-away> saying it is :)

[23:34] < mhrd-home> yes it is

[23:34] < mhrd-home> :)

[23:35] *** sadrul has joined #kamaelia

[23:36] < ms-away> ReassemblePSITables.py appears to have a major change

[23:37] < mhrd-home> yes - mentioned in email; can explain more

[23:37] < mhrd-home> test code used to validate it in trunk

[23:38] < ms-away> seen the comment in the mail now :)

[23:39] < ms-away> I think in future it would've been preferable to do all the coderate -> code_rate changes in one changeset

[23:39] < ms-away> I take it

[23:39] < ms-away> - e = [ord(data[i]) for i in range(0,12) ]

[23:39] < ms-away> + e = [ord(data[i]) for i in range(0,3) ]

[23:39] < ms-away> is to do with parsing TV-A EIT tables ?

[23:40] < ms-away> + DVB_Multiplex(754-754+505.8, [640, 641], feparams), # BBC NEWS 24

[23:40] < ms-away> is confusing :)

[23:40] < ms-away> Index: Python/Kamaelia/Examples/DVB_Systems/SingleChannelTransportStreamCapture.py

[23:41] < mhrd-home> no - thats another bugfix (which I've just noticed I've somehow forgotten to mention in the email) ...

[23:41] < mhrd-home> (the "e = ....")

[23:41] < mhrd-home> "BBC NEWS 24" ... ah, because it has been rebranded?

[23:41] < ms-away> no the : 754-754+505.8

[23:42] < mhrd-home> oh, I've no idea where thats come from !

[23:42] *** mhrd-home removes it

[23:42] < ms-away> heh

[23:43] < ms-away> :)

[23:44] < mhrd-home> the "e = ..." fix was r3964 :

[23:44] < ms-away> BTW, the content_types stuff is interesting

[23:44] < mhrd-home> oops, no its not

[23:45] < mhrd-home> hmm, yes ... Im thinking I ought to take that out completely and reserve it for another branch when I actually need that data

[23:45] < mhrd-home> s/I'm thinking/I'm starting to think/

[23:46] < ms-away> ?

[23:46] < ms-away> Ah, I see - it's extra functionality rather than bugfixes ?

[23:46] < mhrd-home> yeah

[23:46] < mhrd-home> sorry - its only just clocked that I could actually take it out

[23:47] < ms-away> Is it actually usable at present?

[23:47] < ms-away> (with minimal runnable test cases?)

[23:47] < mhrd-home> yes

[23:47] < mhrd-home> I've run all ParseXXXX.py examples

[23:47] < mhrd-home> which exercise the full set

[23:47] *** sadrul1 has joined #kamaelia

[23:48] < ms-away> k

[23:48] < mhrd-home> hmm, svn log doesn't seem to show some of my more recent revisions (today) :-(

[23:49] < mhrd-home> hmm, now it does (after having done an svn blame)

[23:49] < mhrd-home> I'm even more confused now

[23:49] < mhrd-home> anyway ...

[23:49] < mhrd-home> the "e = [ .... ]" mods are another bugfix: r4017 : """Impoved robustness of table section structure parsing code - tests with TOT picked up

[23:49] < mhrd-home> exception condition if fed a table section that was shorter than expected (eg. from

[23:49] < mhrd-home> a PID that contains more than one table type, such as pid 0x14)

[23:49] < mhrd-home> """

[23:50] < ms-away> OK, code looks reasonable. I'm sure you've tested it, so I'm not about to second guess

[23:50] < mhrd-home> the mod extracts the minimum needed to check its the correct table before extracting more

[23:50] < ms-away> Leaving the TVA is fine IMO

[23:50] < mhrd-home> cool - thanks

[23:50] < ms-away> leaving (in) the TVA stuff is fine rather

[23:50] < ms-away> would be nice otherwise, but so would a lottery win :-D

[23:51] < mhrd-home> interestingly, I'm suspecting the thing that caused me to notice r4017 *might* have been the ReassemblePSITables.py parsing fixes

[23:52] < ms-away> :)

[23:53] < ms-away> OK, read through the diff

[23:53] < ms-away> now just doing this:

[23:53] < ms-away> svn merge --dry-run -r3961:HEAD ../../branches/private_MH_20080518_DvbFixes .

[23:53] < mhrd-home> (the fix was likely to cause more table sections to be received where table sections are small - eg. for simple tables like the TOT (Time Offset Table) - which is where I spotted it

[23:53] < mhrd-home> k

[23:53] < ms-away> No complaints from that, yay

[23:53] < mhrd-home> if you want longer to check ... I'm not in *this*much of a hurry :)

[23:55] < ms-away> Oh I've gone through it line by line :)

[23:55] < ms-away> The new docs and module/package level docs are nice :)

[23:55] < mhrd-home> well, you're quicker at that than I am :)

[23:55] < mhrd-home> ta

[23:55] < mhrd-home> by an order of magnitude :)

[23:56] < ms-away> heh

[23:56] < ms-away> I'm used to going through patches :)

[23:57] < mhrd-home> anyway, I'll bid you goodnight (blimey is that the time?)

[23:57] < mhrd-home> thanks for looking at this so quickly

[23:59] < ms-away> indeed

[23:59] < ms-away> night

[23:59] < ms-away> :)

[23:59] *** mhrd-home has parted #kamaelia