[06:52] *** Lawouach_ has joined #kamaelia

[06:52] < Lawouach_> morning all

[07:59] < aa_> that bug chong was having is in xscreensaver, and its fixed in later ubuntu

[08:10] < MS-> morning

[08:10] < MS-> aa_: Ahh, cool

[09:13] *** ian_brasil has joined #kamaelia

[09:29] < MS-> Gosh, a language that really does look like line noise (and isn't a joke language) : http://www.vector.org.uk/archive/v214/sudoku.htm

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

[09:32] < vmlemon_> Hi

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

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

[11:19] < vmlemon_> Hi

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

[12:36] < MS-> Trying to understand this clojure program...

[12:36] < MS-> http://pastebin.com/m69744d5b

[12:37] < MS-> Quite why lisp people think the brackets are a pain, I don't understand

[12:37] < MS-> For example, it turns out that this:

[12:37] < MS-> (def world      (apply vector             (map (fn [_]                    (apply vector (map (fn [_] (ref (struct cell 0 0)))                                       (range dim))))                  (range dim))))

[12:37] < MS-> means this (in python)

[12:38] < MS-> world = [ [cell(0,0) for x in xrange(dim) ] for y in xrange(dim) ]

[12:39] < MS-> or

[12:40] < MS-> world = [[None]*5]*5

[12:40] < MS-> for i in range(5):

[12:40] < MS-> for j in range(5):

[12:40] < MS-> world[i][j] = cell(0,0)

[12:44] < MS-> trying to follow what 58-70 does right now

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

[13:13] *** eikenberry has joined #kamaelia

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

[13:37] < eikenberry> MS-. Where'd that clojure program come from. Looks like a nice example.

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

[14:16] < MS-> eikenberry: I found it underneath this: http://clojure.blip.tv/file/812787

[14:17] < MS-> I haven't had the time/patience to sit through that 2.5 hour presentation yet

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

[14:49] < eikenberry> MS-. Thanks.

[14:59] < MS-> yw

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

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

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

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

[17:13] *** Davbo has joined #kamaelia

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

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

[17:51] < vmlemon_> Hi

[17:53] < MS-> evening

[17:55] *** vmlemon_ doesn't think that UMTS is doing his phone's battery any good, considering that the underspec temporary replacement charger's had it...

[17:55] < vmlemon_> Still, it's certainly fast

[17:57] < vmlemon_> Thanks for committing the hacky file appender by the way

[17:57] < vmlemon_> (Probably my 2nd code contribution to a project)

[17:59] *** vmlemon_ assumes that it's changed in positive ways since I chucked it over the wall, and into the Kamaelia melting pot ;)

[18:03] < vmlemon_> Well, it's technically the 5th or 6th contribution, if you count the changes I submitted for an IRC bot

[18:43] < MS-> Yep, it's changed a fair amount

[18:51] *** vmlemon has joined #kamaelia

[19:04] *** Davbo has joined #kamaelia

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

[19:16] < vmlemon_> Hi

[19:41] < Davbo> Hey all

[19:42] *** Davbo finally gets to write some Python for University work

[19:42] < aa_> yay!

[19:42] *** Davbo is happy :-)

[19:42] *** aa_ had to write all his "university" work in java so the lecturorers/tutors could understand it :)

[19:43] < aa_> but then that really was not a good "university"

[19:43] < Davbo> They'd probably understand the Python code better than the Java in most cases

[19:43] < Davbo> even if they're not "python programmers"

[19:44] < aa_> I think they used to mark the assignments with regular expressions

[19:44] < Davbo> Wow.

[19:44] < Davbo> just...wow.

[19:44] < aa_> well, I am being mean

[19:44] < aa_> but have you ever had the feeling your tutors are holding you back?

[19:44] < Davbo> all the time, i just ignore it and do things my way

[19:45] < Davbo> generally argue it out

[19:45] < aa_> ah yes, the arguments

[19:48] < Davbo> I asked my "Systems Analysis and Design" lecturer if he'd read Kent Beck's book on TDD, ended up in an argument where he basically ended it saying "Well Kent Beck developed that on a project that failed" and laughed at me..

[19:49] < Davbo> This same lecturer has a book about the "Discovery Method" which is the biggest waste of time I've ever seen

[19:50] < Davbo> but since none of the students know the alternatives they just go along with it

[19:50] < aa_> that infuriates me

[19:51] < aa_> my "mathematics for computer science teacher" was the worst

[19:51] < aa_> he also had his own book

[19:51] < aa_> and he would insist on us using his title

[19:51] < aa_> Dr Dupee

[19:51] < aa_> (which of course was a huge mistake, because I insisted on him using my title. Which is also "Dr")

[19:52] < Davbo> Haha

[19:52] < aa_> that was a messy afternoon ;)

[19:52] < Davbo> well played, well played. :-)

[19:53] < aa_> especially good because he refused to believe me, and tried to make a big thing of it

[19:53] *** aa_ sighs

[19:53] < aa_> still it beat having a real job, I'll say that much

[19:56] < Davbo> I'm terrified of finishing Uni, no idea what I'll end up doing

[19:57] < aa_> Davbo: want to be a developer?

[19:57] < Davbo> I'm not sure really

[19:58] < Davbo> I enjoy it so will most likely give it a go after uni

[20:01] < Davbo> it would have to be in the right environment though

[20:01] < aa_> well, you might have to do a couple of years worth of wok you don't enjoy

[20:02] < aa_> I was quite lucky, I got a pygtk job right away on the strength of my open source work

[20:02] *** Lawouach has joined #kamaelia

[20:03] < Davbo> I like the idea of working for some crazy high risk start-up, but I think they're few and far between over here.

[20:03] < aa_> yeah

[20:03] < aa_> I have an idea for a start up

[20:03] < Davbo> i don't think you really get the chance of that sort of thing when you get older though

[20:04] < aa_> just not sure what to do with it

[20:04] < Davbo> and you know, have to be responsible

[20:04] < aa_> very much so

[20:04] < aa_> I have responsibilities

[20:04] < aa_> and the current economic climate is not exactly helpful

[20:04] < Davbo> idea's are cheap in this industry though aa_, unless it's a particularly good idea ;-)

[20:05] < aa_> Davbo: it's a Nobel prize-winning idea :)

[20:05] < aa_> I could be wrong, of course!

[20:05] < aa_> I once thought providing men with hormones to allow them to breast-feed was a good idea too.

[20:05] < Davbo> well investing in tech start-ups is probably safer than the banks or stock market aa_

[20:06] < aa_> hah, possibly true

[20:07] < Davbo> I could just go for it after university and try to get some venture capital ;-)

[20:08] < aa_> you may as well try

[20:08] < aa_> as you say, nothing to lose

[20:10] < Davbo> "This time next year we'll be millionaires"

[20:12] < Davbo> Oh I recall my best argument with a lecturer now, he was complaining about open source in reference to a commercial plug-in for Eclipse.....good times.

[20:12] *** Rigolo has joined #kamaelia

[20:12] < Rigolo> good evening

[20:12] < Davbo> Evenin' Rigolo

[20:12] < Rigolo> mmm let me see if I can get a proper window for irssi ... be right back

[20:13] *** Rigolo has joined #kamaelia

[20:13] < Rigolo> that is better :-)

[20:14] < Rigolo> okee ... now letś see what I needed to do in order to get kamalia working with dvb-c

[20:18] < Davbo> Ah I spotted something about that on the list, I assume that was either you or you've seen it Rigolo?

[20:18] < Rigolo> I've seen it ....

[20:19] < Rigolo> I worked on it last night with MS- .. but then it was late ... and I needed the trunk version of Kamaelia

[20:19] *** Davbo nods

[20:19] < Rigolo> so I did a clean reinstall of mythbuntu 8.10 beta .. and using that now

[20:19] < Rigolo> Just compiled Pyrex 0.9.3.1

[20:19] < Rigolo> no move to python-dvb3

[20:19] < Rigolo> now I mean

[20:22] < Rigolo> mmmm probably forgot some other packages ....

[20:23] < Rigolo> Pyrex worked ... doing a python setup.py install for python-dvb3 did not ....

[20:26] < Davbo> I don't know much about dvb I'm afraid

[20:26] < Davbo> What does it complain about when you try to install it?

[20:27] < Rigolo> lotś of errors ... too much to mention

[20:27] < Rigolo> so probably a package that I also need

[20:27] < Rigolo> mmm let met guess ... gettext I guess :-)

[20:27] < Rigolo> I will just check what I did yesterday

[20:27] < Rigolo> then it worked

[20:29] < Rigolo> python2.5-dev

[20:29] < Rigolo> mm i mean ....

[20:29] < Rigolo> python2.5-dev

[20:29] < Rigolo> mmm weird copy thing again

[20:29] < Rigolo> sudo apt-get install python-all python-all-dev python-dev python2.5-dev

[20:30] < Rigolo> that is more like it

[20:30] < Davbo> what you did yesterday?

[20:30] < Davbo> Did you have it working yesterday?

[20:31] < Rigolo> I installed python-pyrex from the standard repositories .. but python-dvb3 does not work with that latest version

[20:31] < Rigolo> but it was installed .. and then I uninstalled only that package .

[20:31] < Rigolo> but the dependecies remaind ...

[20:31] < MS-> Rigolo: Pyrex worked ... doing a python setup.py install for python-dvb3 did not ....

[20:31] < MS-> Have you got the linux kernel headers installed ? IIRC the dvb3 headers get pulled in from there

[20:31] < Rigolo> so now I just installed them

[20:32] < Rigolo> and now python-dvb3 installed :-)

[20:32] < Rigolo> headers are standard on mythbuntu

[20:32] < Rigolo> good evning MS- ... btw :-)

[20:33] < MS-> Rigolo: Indeed - evening :)

[20:33] < Davbo> Evenin' MS-, hopefully you can be of more use than me! :-)

[20:33] < MS-> Davbo: "Well Kent Beck developed that on a project that failed" - well, there's also Fred Brooks "The Mythical Man Month"

[20:34] < Rigolo> 16 new updated packages since this morning 9 ... must be almost ready for a release I guess .. ubunut 8.10

[20:34] < MS-> Rigolo: cool

[20:34] < MS-> Davbo: Whilst being one of the most cited computing books of all time it's actually interesting if you stop and think about it

[20:34] < MS-> Davbo: How can you know that adding more people to a *failing* project doesn't help, unless you've repeatedly tried it?

[20:34] < MS-> Davbo: and therefore had multiple failed projects :-)

[20:35] < Rigolo> MS-: that is why they are most likely consultants .... :-)

[20:35] < Rigolo> MS .. btw ..if you get a new kernel .. do you need to recompile pything-dvb3 each time?

[20:36] < MS-> Not normally no, it's just due to the headers

[20:36] < Davbo> interesting MS-, I'll have a look in the library for that one

[20:37] < Rigolo> okee ...

[20:37] < Rigolo> going to a co of svn right now .. and install the svn version

[20:37] < MS-> Davbo:: do you mean this: http://www.dcs.shef.ac.uk/~ajhs/discovery/ ?

[20:37] < MS-> Rigolo: k

[20:38] < Davbo> Yeah that's what we have to follow :-(

[20:38] < MS-> Davbo: It's the only relevant link I've seen from this: http://www.google.com/search?q=%22Discovery+Method%22

[20:38] < Davbo> it has some good point sthough

[20:38] < MS-> Sounds like it's his local pet approach

[20:38] < MS-> (which isn't necessarily a bad thing)

[20:39] < Davbo> not really, he tries to promote it everywhere

[20:40] < Davbo> he's part of the OPEN Consortium or something and they developed it together

[20:40] < Rigolo> got rev 5447 right here ....

[20:40] < MS-> Rigolo: k

[20:41] < MS-> Davbo: I'm not so sure - I've never heard of it, and he's been promoting it for 14 years?

[20:41] < Davbo> It's just *that* good.

[20:41] < MS-> (and I actively take an interest in that sort of thing)

[20:41] < Davbo> ;-)

[20:42] < Rigolo> MS ... when I do a new checkout .. can I just do a sudo python setup.py install again? or should I first do a uninstall or something like that?

[20:42] < Davbo> I'm not sure really MS-, but he really tries to pedal that book on us

[20:45] < MS-> Rigolo: Yes, you can just do an install over the top

[20:46] < MS-> Davbo: Is there a good reference to his method there?

[20:46] < Rigolo> MS-: okee .. got the trunk version .. and Axon also from svn

[20:47] < Rigolo> going to make that same change that I did yesterday to Capturesingle...

[20:48] < MS-> k

[20:50] < Rigolo> MS-: you have a typo in line 275 of DVB/Core.py :-)

[20:50] < Rigolo> sefl.card = card ...

[20:50] < MS-> ta

[20:51] < MS-> fixed

[20:52] < Rigolo> File "/usr/lib/python2.5/site-packages/Kamaelia/Device/DVB/Core.py", line 290, in main

[20:52] < Rigolo> tune_DVB(fe, self.freq, self.feparams)

[20:52] < Rigolo> File "/usr/lib/python2.5/site-packages/Kamaelia/Device/DVB/Core.py", line 216, in tune_DVB

[20:52] < Rigolo> if fe.t == dvb3.frontend.OFDMParameters:

[20:52] < Rigolo> AttributeError: 'frontend.Frontend' object has no attribute 't'

[20:53] < MS-> hm. Well, it was worth a try...

[20:53] < MS-> OK, will add in something else, and ask you to test it - I don't have my DVB hardware handy

[20:55] < Rigolo> no problem ... ready when you are

[20:55] < MS-> OK, I've added in a print dir(fe) statement above that line

[20:55] < MS-> since I thought it would be something else

[20:55] < Rigolo> ['__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', 'diseqc_recv_slave_reply', 'diseqc_reset_overload', 'diseqc_send_burst', 'diseqc_send_master_cmd', 'enable_high_lnb_voltage', 'fileno', 'get_event', 'get_frontend', 'get_info', 'read_ber', 'read_signal_strength', 'read_snr', 'read_status', 'read_uncorrected_blocks', 'set_blocking',

[20:56] < MS-> I probably should've also done

[20:56] < Rigolo> that was what you were looking for right?

[20:57] < MS-> OK, added in a couple of extra lines to dump out a touch more detail

[20:58] < Rigolo> ['__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', 'diseqc_recv_slave_reply', 'diseqc_reset_overload', 'diseqc_send_burst', 'diseqc_send_master_cmd', 'enable_high_lnb_voltage', 'fileno', 'get_event', 'get_frontend', 'get_info', 'read_ber', 'read_signal_strength', 'read_snr', 'read_status', 'read_uncorrected_blocks', 'set_blocking',

[20:58] < MS-> OK, def get_event(self):

[20:58] < Rigolo> < type 'frontend.Frontend'>

[20:58] < MS-> is a method of

[20:58] < Rigolo> < type 'frontend.Frontend'>

[20:58] < MS-> that :)

[20:59] < MS-> OK, is fd there...

[20:59] < MS-> no

[20:59] < MS-> hm

[20:59] < MS-> You see that "t" is defined here:

[20:59] < MS-> cdef class Frontend:

[20:59] < MS-> cdef int fd

[20:59] < MS-> cdef object t

[21:00] < MS-> So if the t isn't visible the fd wouldn't be either

[21:00] < MS-> despite both being used like this:

[21:00] < MS-> self.fd = open(filename, flags)

[21:00] < MS-> self.t = QPSKParameters

[21:00] < MS-> So that does indeed track

[21:01] *** MS- thinks

[21:01] *** Rigolo waits ...

[21:01] < Rigolo> (and builds a one line svn up and install command)

[21:02] < MS-> Wondering how to get at self.t

[21:04] *** mhrd-afk has joined #kamaelia

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

[21:04] < Rigolo> isńt that t coming from cfrontend?

[21:04] < Rigolo> looking at the source of frontend.pyx

[21:07] < MS-> OK, I've added in a method to frontend.pyx, so that needs rebuilding

[21:07] < MS-> and also changed DVB/Core.py to use that new method

[21:07] < Rigolo> mmm okee .. but I got python-dvb3 as a tarball .. not from svn

[21:08] < Rigolo> so should I get the svn version now?

[21:08] < MS-> I see

[21:08] < MS-> svn co http://kamaelia.googlecode.com/svn/trunk/Code/Python/Bindings/python-dvb3

[21:08] < MS-> cd python-dvb3

[21:08] < MS-> sudo python setup.py install

[21:09] < Rigolo> not a force .. because I now have that tarball?

[21:09] < Rigolo> and that was version 0.0.5 .. and i just looked at the code ..and it still says version 0.0.4(correct?)

[21:10] < Rigolo> okee .. version 0.0.5 in setup.py now :-)

[21:10] < MS-> ~/code.google/kamaelia/trunk/Code/Python/Bindings/python-dvb3> grep version setup.py

[21:10] < MS-> name="python-dvb3", version="0.0.5",

[21:10] < Rigolo> but __init__.py says 0.0.4

[21:12] < MS-> so it does

[21:12] < Rigolo> does it harm?

[21:12] < MS-> I didn't realise a version had gone in there

[21:12] < MS-> no, no harm, but useful to know

[21:12] < MS-> since someone may look for it

[21:12] < Rigolo> okee ..

[21:13] < Rigolo> no need to add a --force?

[21:13] < MS-> nope

[21:13] < Rigolo> okee

[21:13] < Rigolo> done .. build

[21:13] < Rigolo> kamaelia also right?

[21:14] < Rigolo> File "/usr/lib/python2.5/site-packages/Kamaelia/Device/DVB/Core.py", line 295, in main

[21:14] < Rigolo> tune_DVB(fe, self.freq, self.feparams)

[21:14] < Rigolo> File "/usr/lib/python2.5/site-packages/Kamaelia/Device/DVB/Core.py", line 231, in tune_DVB

[21:14] < Rigolo> fe.set_frontend(params)

[21:14] < Rigolo> File "frontend.pyx", line 446, in frontend.Frontend.set_frontend

[21:14] < Rigolo> File "frontend.pyx", line 364, in frontend.raise_ioerror

[21:14] < Rigolo> TypeError: exceptions must be strings, classes, or instances, not exceptions.IOError

[21:16] < MS-> not

[21:16] < Rigolo> you set the dvb card number fixed to card 0 right?

[21:16] < MS-> defaults to card 0

[21:17] < Rigolo> okee .. so that is good

[21:17] < MS-> It's clearly doing something as well

[21:18] < MS-> Since it would've failed before then

[21:18] < Rigolo> some steps further down the line yes ...

[21:18] *** MS- nods

[21:18] < MS-> OK, what's the error

[21:18] < MS-> let's see

[21:18] < MS-> fet = fe.get_dvbtype()

[21:18] < MS-> is giving us fe.t

[21:18] < Rigolo> going to check my dvb hardware .. see if I can record using czap and cat to eliminate error there

[21:18] < MS-> which means it's either going down: if fet == dvb3.frontend.OFDMParameters:

[21:19] < MS-> or it's using whatever class is stored directly

[21:19] < MS-> else:

[21:19] < MS-> build_params = fet

[21:19] < MS-> params = build_params( **feparams )

[21:19] < MS-> We identified yesterday that it would need to go down that latter side

[21:19] < MS-> and therefore that's working, or else that would have failed

[21:19] < Rigolo> it should yes ...

[21:20] < MS-> Ah, this is handy:

[21:20] < MS-> The failure is here:

[21:20] < MS-> def set_frontend(self, parameters):

[21:20] < MS-> global cfrontend

[21:20] < MS-> cdef cfrontend.dvb_frontend_parameters p

[21:20] < MS-> if pack_parameters(&p, parameters) == 0:

[21:20] < MS-> raise ParameterError, "Incorrect parameter type"

[21:20] < MS-> if ioctl(self.fd, cfrontend.FE_SET_FRONTEND, &p) == -1:

[21:20] < MS-> raise_ioerror() # < -------------------------- line 446

[21:21] < MS-> Which means the correct paramter type is being used

[21:21] < MS-> which is good

[21:21] < MS-> ha! that means there's two problems here

[21:21] < mhrd> Rigolo: what tuning parameters are you passing?

[21:21] < MS-> 1) the parameters being passed are wrong

[21:21] < mhrd> s/tuning/fe/

[21:21] < mhrd> (hi btw)

[21:21] < MS-> 2) the handling of the errors is borked :)

[21:22] < MS-> mhrd: hiya

[21:22] < Rigolo> feparams = {

[21:22] < Rigolo> "inversion" : dvb3.frontend.INVERSION_AUTO,

[21:22] < Rigolo> "symbol_rate" : 6875000,

[21:22] < Rigolo> "fec_inner" : dvb3.frontend.FEC_AUTO,

[21:22] < Rigolo> "modulation" :dvb3.frontend.QAM_64,

[21:22] < Rigolo> }

[21:22] < Rigolo> Pipeline(

[21:22] < Rigolo> DVB_Multiplex(618, [88, 89], feparams), # Nederland 1

[21:22] < Rigolo> 618 will be expanded to 618000000

[21:22] < Rigolo> 88 and 89 are the PIDs

[21:22] < mhrd> 618 MHz?

[21:22] < Rigolo> yes ... dvb-c

[21:22] < mhrd> k

[21:23] < MS-> Ooooooh

[21:23] < Rigolo> http://www.digitalekabeltelevisie.nl/techniek/tvhome.shtml

[21:24] < MS-> I was mistakenly under the impression of jow this worked:

[21:24] < MS-> params = dvb3.frontend.OFDMParameters(

[21:24] < MS-> frequency = frequency * 1000 * 1000,

[21:24] < MS-> **feparams

[21:24] < MS-> )

[21:24] < Rigolo> there is a list of transport streams .. and services in them .. and what freq they are on for my network 9003

[21:24] < Rigolo> mmm so if I include frequency in my feparams ... :-)

[21:24] < mhrd> yep

[21:24] < mhrd> (hopefully)

[21:24] < Rigolo> because of the else .. it does not multiply :-)

[21:25] < MS-> OK, updated the logic

[21:25] < MS-> in DVB/Core.py

[21:25] < Rigolo> mmm okee .. I was going to include the frequency in my feparams ...

[21:25] < MS-> mhrd: The confusion was caused because DVB-C doesn't use dvb3.frontend.OFDMParameters

[21:26] < mhrd> MS- : yep, I see

[21:26] < MS-> Rigolo: I've done the arguably more appropriate fix

[21:26] < Rigolo> as always :-)

[21:26] < MS-> mhrd: Replying to your mail on the list

[21:26] < Rigolo> I need to wait untill my scan is finished ... otherwise my card0 is busy :-)

[21:26] < MS-> basically it boils down to "i agree"

[21:26] < MS-> :)

[21:26] < mhrd> MS- : ta, thought I'd float here in case you wanted to discuss :)

[21:27] < mhrd> cool -short discussion then :)

[21:27] < Rigolo> should have done that scan on card1

[21:27] < Rigolo> going to update svn kamaelia already

[21:28] < Rigolo> version 5454 .. nice number .. must work now :-)

[21:29] < Rigolo> your prints are still in the code .. and I see no errors yes :-)

[21:29] < Rigolo> and I see a Nederland1.ts file in my home dir :-)

[21:29] < Rigolo> did a ctrl-c to stop recording ...

[21:29] < Rigolo> let's see if I can play it back

[21:30] < MS-> woo

[21:30] < MS-> mhrd: There's a few edge cases, but I think they're clear

[21:30] < Rigolo> I can see the stream ....

[21:31] < Rigolo> no sounds .. but that is because sound is not yet setup on my test desktop :-)

[21:31] < mhrd> MS-, Rigolo: cool :-)

[21:31] < Rigolo> it is ....

[21:31] < Rigolo> so that also means I can use the NIT parsers etc .. right?

[21:32] < MS-> You have pictures?

[21:32] < Rigolo> must be .. because dvb/core.py was changed ...

[21:32] < Rigolo> yes ...

[21:32] < MS-> Fantastic! :-D

[21:32] < MS-> wooooo :-D !

[21:32] < Rigolo> so .. you can say you support dvb-c also now ...

[21:32] < mhrd> Rigolo: possibly. they were taken from the DVB-SI spec, so so long as the service is compliant, it may work. They've only ever been tested on DVB-T though!

[21:32] < mhrd> "ETSI EN 300 468" iirc

[21:33] < MS-> So, the bindings are now known to work with DVB-T, DVB-S and DVB-C, and the components with DVB-T and DVB-C :-)

[21:33] < Rigolo> mhrd: mmm compliant is something my provider does not always understand :-)

[21:33] < Rigolo> Ms .. only some components :-)

[21:33] < Rigolo> let's have a look at those parser tomorrow ...

[21:34] < Rigolo> midnight again :-)

[21:34] < mhrd> I suppose I mean that I've never checked if 300 468 is a spec for any DVB service, or only DVB-T ... will be interested to hear how you get on

[21:34] < mhrd> someone's tested with DVB-S ?

[21:34] < MS-> Rigolo: Thanks for the feedback, I'll tidy the code up a touch & add the notes to the new release notes

[21:34] < MS-> mhrd: the bindings were originally built using DVB-S by A&Mi

[21:34] < Rigolo> MS-: next step ... update the bidings to the latest version of pyrex ...

[21:35] < mhrd> aah

[21:35] < Rigolo> would be handy for really easy installation etc

[21:36] < Rigolo> so I will look at the parsers tomorrow .. because I can use them to create correct tuning files and other handy things like populating mythtv tables

[21:38] < MS-> cool

[21:38] < MS-> mhrd: I'm hitting a quandry regarding passing on of signals.

[21:39] < mhrd> oh?

[21:40] < MS-> I'll post my reply as is, and you'll see my thinking

[21:40] < mhrd> k

[21:40] < MS-> sent

[21:40] < mhrd> ta

[21:40] < MS-> basically in principle I agree with your point

[21:40] < MS-> s

[21:40] < MS-> that if we do control, why not signal

[21:40] < MS-> Your example provides a clear case for it as well

[21:41] < MS-> And I think the quandry comes from 2 locations

[21:41] < MS-> since a graphline deals with things inside and outside

[21:41] < MS-> from outside, producerFinished should not kill the graphline

[21:41] < MS-> from outside shutdown* should kill the graphline since it's a "shutdown now" message

[21:42] < MS-> it switching to a "shutting down waiting for dieing children" mode though is appropriate for the debugging reason you mention

[21:42] < MS-> It's more the what do you mean by the subcomponent's outbox "signal"

[21:43] < MS-> subcomponents' even

[21:43] < mhrd> yeah :)

[21:44] < MS-> There is a case for doing what this does:

[21:44] < MS-> ~> ( echo one; echo two; echo three) | wc -l

[21:44] < MS-> 3

[21:44] < MS-> which is to take unwired outputs and pass them to the outside world

[21:45] < MS-> But that feels like a major behavioural change for pipeline & graphline

[21:45] < mhrd> quickie: just to clear up misinterpretation: the behaviour I was suggesting was that, if no linkages are specified that go to the graphline's "signal" outbox, then when graphline receivies a shutdown msg, it'll do this:

[21:45] < MS-> Would be a useful *extra* chasis though

[21:45] *** MS- listens

[21:45] < mhrd> 1) send shutdown to "control " inbox of all children whose control inboxes are not wired to anything

[21:46] < mhrd> 2) send shutdown out if graphline's own "signal" outbox

[21:46] < mhrd> if I understood your reply to my email correctly, I think you misunderstood ... does this clarify?

[21:47] < MS-> 1) is currently done, yes?

[21:47] < mhrd> yes

[21:47] < MS-> 2) is something that (ironically) I was doing during testing :)

[21:47] < mhrd> lol

[21:47] < MS-> So I agree :)

[21:48] < MS-> and then shifted the shutdown into the "right" place

[21:48] < mhrd> its a good point about producerFinished vs shutdown though

[21:48] < MS-> I think passing on producerFinished when all the children have finished is a good idea

[21:49] < mhrd> you could make a case to say that if the author wants specific producerFinished behaviour, then they should choose to wire the 'control'-'signal' boxes manually, so shutdown is controlled/preedicatable

[21:50] *** mhrd ponders MS-'s suggestion ... it feels a little like imposing behaviour, but I can't think of any good counter examples :-)

[21:51] < MS-> OK, how about

[21:51] < MS-> in the absence of any message being passed on by a child component, in it's dying gasp a graphline puffs out a producerFinished message if no-one else announces their passing ?

[21:52] < MS-> passing on == passing on outside

[21:52] < mhrd> when you put it like that, it doesn't sound so bad :-)

[21:52] < MS-> Well, it's communication vs documentation ;)

[21:52] < MS-> That's the problem here, context

[21:52] < mhrd> *slightly* more complex to implement: graphline would need to intercept the outgoing msg iiuc

[21:53] < MS-> OK, an outgoing message would go out via signal

[21:54] < MS-> ah, actually *yes*

[21:54] < MS-> If the outgoing message is going out via signal

[21:54] < MS-> then someone has done this:

[21:54] < MS-> ("FOO", "signal") : ("self", "signal")

[21:54] < MS-> which means whether or not they send a message, we don't intefere

[21:54] < MS-> UNLESS

[21:55] < MS-> we were sent a shutdownMicroprocess, which we pass on

[21:55] < MS-> But, if linkages doesn't contain:

[21:55] < MS-> ("FOO", "signal") : ("self", "signal")

[21:55] < MS-> then unless we send a message (even producerFinished)

[21:56] < MS-> then the graphline & all it's components would shutdown without telling anyone

[21:56] < MS-> This leads me to suggest that

[21:57] < MS-> if OUTSIDE sends GRAPHLINE any-message-not-shutdownMicroprocess:

[21:57] < MS-> pass that onto appropriate sub-components

[21:57] < MS-> if OUTSIDE sends GRAPHLINE :

[21:57] < MS-> pass that onto appropriate sub-components

[21:57] < MS-> switch to shutdown mode

[21:57] < MS-> pass on shutdownMicroprocess when done

[21:58] < MS-> If no message from outside:

[21:58] < MS-> if subcomponents all exit:

[21:58] < MS-> if pass-through-linkage-for-signal:

[21:58] < MS-> just exit quietly

[21:59] < MS-> if no-pass-through-linkage-for-signal:

[21:59] < MS-> pass on producerFinished to GRAPHLINE-signal

[21:59] < mhrd> umm .. no indentation showing in IRC :-)

[21:59] < MS-> Oh

[21:59] *** mhrd suggests prefixing all lines with a non-space char, eg '.' :-)

[22:00] < MS-> http://pastebin.com/m3137106c

[22:00] < MS-> :)

[22:00] < mhrd> lol

[22:00] < MS-> if OUTSIDE sends GRAPHLINE :

[22:00] < MS-> should be

[22:00] < MS-> if OUTSIDE sends GRAPHLINE shutdown-message:

[22:01] < MS-> updated: http://pastebin.com/m743eb75d

[22:02] < mhrd> I'd suggest that if pass-through-linkage-for-signal: never send any shutdown messages out of graphline's "signal" outbox, because the graphline's author has expressed the intention to handle shutdown themselves ?

[22:02] < mhrd> (logic feels simpler too)

[22:04] *** mhrd ponders

[22:04] < MS-> You mean don't pass on the shutdownMicroprocess if we receive it in that scenario?

[22:05] < mhrd> yep ... if graphline receives a shutdown msg on its "control" inbox, don't pass it on out of graphline's "signal" outbox

[22:06] < mhrd> only pass it to subcomponents whose "control" inbox is not wired up to anything (as per what this branch adds, functionality wise)

[22:07] < mhrd> if, on the other had, there are no linkages to the graphline's "signal" outbox; then we do everything you suggest:

[22:07] < mhrd> shutdownMicroprocess msgs get passed on imediately

[22:07] < MS-> ie so this would happen:

[22:07] < mhrd> producerFinished would be held back until all subcomponents have terminated

[22:07] *** mhrd listens

[22:09] < MS-> if from OUTSIDE, get shutdownMicroprocess:

[22:09] < MS-> ____pass on to subcomponents

[22:09] < MS-> ____break out of loop (as per current branch)

[22:09] < MS-> ____if no-component-links-to-graphline's signal

[22:09] < MS-> ________ pass on shutdownMicroprocess via graphline's signal

[22:09] < MS-> where as the alternative is:

[22:09] < MS-> if from OUTSIDE, get NOT-shutdownMicroprocess:

[22:09] < MS-> ___pass on to subcomponente

[22:10] < MS-> Overall logic I suppose is this:

[22:10] < MS-> while not self.childrenDone():

[22:10] < MS-> ____always pass on messages from our control to appropriate sub-component's control

[22:11] < MS-> ____if message is shutdown, set shutdown flag and break out of loop

[22:11] < MS-> then after loop

[22:12] < MS-> if no component-has-linkage-to-graphline's signal_

[22:12] < MS-> ___if shutdown flag set:

[22:12] < MS-> ______pass on shutdownMicroprocess

[22:12] < MS-> ___else:

[22:12] < MS-> ______pass on producerFinished

[22:12] < MS-> I think that's the whole think

[22:12] < MS-> s/think/thing/

[22:13] < MS-> http://pastebin.com/m7d4d2ba0 - if easier to read there

[22:13] < mhrd> I think that behaviour would pretty much make sense to me ... both as a user of a component based on a graphline, and as someone writing a graphline

[22:14] < mhrd> only bit I'd not be sure about is whether that producerFinsihed message should be sent after all chidlren have terminated

[22:14] < mhrd> or immediately, as shown in the logic you just described.

[22:14] < MS-> producerFinsihed message is after all have terminated

[22:15] < MS-> if message is shutdown, set shutdown flag and break out of loop

[22:15] < MS-> means shutdownMicroprocess

[22:15] < MS-> You can easily argue it (and you did and I agreed)

[22:15] < MS-> that it could/should be

[22:15] < MS-> if message is shutdown, set shutdown flag

[22:15] < MS-> doh :)

[22:15] < mhrd> :)

[22:16] < MS-> I think that means this:

[22:16] < MS-> http://pastebin.com/m3b5541e9

[22:16] < MS-> Actually that's probably a good idea.

[22:16] < mhrd> yes

[22:17] < MS-> If we keep the graphline alive & waiting

[22:17] < mhrd> (that was a "yes" to "I think that means this:" :-) )

[22:17] < MS-> we can actually add in debugging support to get graphlines to tell us when they're dying

[22:17] < mhrd> good point - better introspection

[22:17] < MS-> and they have children that refuse to die

[22:17] < MS-> yep

[22:17] < MS-> It's also not a huge change

[22:18] < MS-> if isinstance(msg, shutdownMicroprocess) or (msg==shutdownMicroprocess):

[22:18] < MS-> # print "oooh, we got a you must shutdown message, okeydokey, doing so"

[22:18] < MS-> break

[22:18] < mhrd> I think what you suggest covers all cases that I can think of

[22:18] < MS-> becomes a message#

[22:18] < MS-> s/message/flag/

[22:18] < MS-> I think it also allows existing systems to operate cleanly as well

[22:19] < mhrd> yep - I really didn't like the idea that if I had wired up "control" "signal" paths myself, that the graphline might decide to unilaterally inject extra msgs

[22:19] < MS-> (mind you with a version of 0.6, I'm not *too* worried about that if it improves the system, as this would)

[22:19] *** MS- nods

[22:19] < MS-> Oh, that's a point

[22:19] < mhrd> you want me to add the change? (will probably test tomorrow evening ... bed soon)

[22:20] < MS-> I don't actually check for passthrough INBOUND

[22:20] < mhrd> ooh

[22:20] < MS-> which should equally be avoid being touched

[22:20] < MS-> If you're willing to do the changes please feel free. When you're done I'll review and merge

[22:21] < MS-> But no rush :)

[22:21] < mhrd> hmm, iirc because of the way the boxes are implemented, you'll never receive a msg on "control" if a passthrough is wired

[22:21] < mhrd> (the message will skip straight pass the graphline's "control" inbox)

[22:21] < mhrd> probably better to make that logic explicit tho

[22:21] *** MS- nods

[22:21] *** mhrd gets coding

[22:22] < MS-> no rush :)

[22:22] < MS-> thanks ! :)

[22:22] < mhrd> np - good to spend some time pondering these kinds of semantic pedantry :-D

[22:23] < MS-> indeed :)

[22:23] < MS-> It feels simpler as well as a resul

[22:23] < MS-> t

[22:24] < mhrd> cool

[22:34] *** Lawouach has joined #kamaelia

[22:38] *** mhrd spots a (independent) bug and fixes first

[22:40] < MS-> k

[22:41] < mhrd> Q: components (object) can be used as dict keys in python can't they?

[22:43] < MS-> yes

[22:46] < mhrd> (too much Java recently)

[22:46] < MS-> heh

[22:53] < MS-> btw, I'm pondering this: http://www.computer.org/portal/site/micro/menuitem.5b23ac137537a1b5084840898bcd45f3/index.jsp?&pName=micro_level1&path=micro/content&file=cfpmayjun09.xml&xsl=article.xsl&;jsessionid=JBR5NhrXpk0cPlThrvbVlDsYsBTpyXn9YmhfNgv8qZXsQTyYHRXz!-325771431

[22:53] < MS-> http://tinyurl.com/6ouzvw

[23:09] < MS-> watching the checkins

[23:09] < MS-> The nice thing about these changes is that they're *much* cleaner with regard to shutdown behaviour, potentially making testing simpler :-D

[23:10] < mhrd> ok, last checkin done now

[23:11] < mhrd> will reply to the email thread so others know whats up

[23:13] < MS-> cool

[23:39] *** mhrd -> bed