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

[06:40] < Lawouach_> morning

[06:41] *** Lawouach_ is listening to Pulp - Common People to start the day :)

[07:33] *** mhrd-afk is now known as mhrd

[07:45] *** Trun has joined #kamaelia

[07:45] < Trun> hi

[07:49] *** Chong- has joined #kamaelia

[08:00] < Lawouach_> hello Trun

[08:00] < Lawouach_> hi Chong-

[08:01] < mhrd> hi Trun, Chong-, et al

[08:01] < Trun> hi

[08:01] < Trun> Lawouach: I've been trying to start from zero writing a test for the simple component you pointed

[08:02] < Trun> the Echoer: http://rafb.net/p/qedlke78.html

[08:02] < Trun> but I tend to just move towards the same interface again and again

[08:03] < Trun> I wrote last night some documentation of an example of this interface

[08:03] < Trun> in the way Michael documented one of the examples on r4826

[08:03] < mhrd> is the test code you've written in svn? I'd be interested to take a peek

[08:04] < Trun> nope, it's here: http://pablo.ordunya.com/test_Echoer.py

[08:04] < mhrd> Sorry I've not replied to your mailing list question yet - been kinda busy

[08:04] < Trun> don't worry :-)

[08:04] < mhrd> shove it in svn - its a good checkpoint and makes it easier for me/others to pull down and get working :)

[08:05] < mhrd> you can always make a subdir in your sketches folder - eg 'experiments' if you want to keep it separate from other code you're working on

[08:05] < Trun> well, I'm working without svn access, should I send it to the list with subject "[PATCH] Adding example of a testing interface"

[08:05] < Chong-> morning, Lawouach_, Lawouach_ and Trun

[08:05] < Trun> ?

[08:06] < mhrd> Trun: oops - sorry - I forgot. Apologies

[08:06] < Chong-> s/Lawouach_/mhrd

[08:06] < Chong-> sorry :-)

[08:06] < mhrd> Chong- : heh, np

[08:07] < Chong-> mhrd: thanks :-)

[08:08] < mhrd> Trun: I'm not sure - ask MS- - in the meantime, pastebin will suit me fine :)

[08:08] < mhrd> (or ask Lawouach_ )

[08:08] < mhrd> KamTestCase defined in a separate source file?

[08:09] < Trun> yep, KamTestCase is in the branch "branches_PO_Test"

[08:09] < Trun> yes, pastebin is probably far cleared

[08:10] < mhrd> "but I tend to just move towards the same interface again and again" ... for KamTestCase or for test_Echoer ?

[08:10] < Trun> the point of this example was to show the ideas behind the interface, rather than the implementation itself (I probably change both, the problem is that right now I'm always moving forward that interface)

[08:10] < Trun> for KamTestCase

[08:11] < Trun> like "something that has initialization -setUp-, finalization -tearDown-, that you provide messages to its inboxes 'in real time' through some kind of method

[08:11] < mhrd> "in real time" ?

[08:11] < Trun> and you get the output from the component also 'in real time'

[08:11] < Trun> I mean, the component is executing in background

[08:12] < mhrd> I can see that makes test cases more concise

[08:12] < Trun> so, you the component is actually running when you send the messages (they are safely sent through a "Source")

[08:12] < mhrd> the lack of determinacy could cause issues for some kinds of tests though ... I'll see fi I can dig out a concrete example

[08:14] *** bcarlyon|laptop has joined #kamaelia

[08:17] < Trun> yep, the first iteration I worked on was intended to be more "deterministic", being based on "steps of the scheduler" rather than on "time past"

[08:20] < mhrd> /trunk/Code/Python/Kamaelia/Test/Util/test_RateControl.py ...tests timing behaviour, albeit does it with a mock 'time' module ... so might be able to be made to work in your system.

[08:20] < Trun> but in a mentor meeting ( http://yeoldeclue.com/logs/kamaelia2008-06-10_log.html [14:06] to [14:12] ) I was suggested to define the expectations in terms of time instead of in terms of steps

[08:20] *** Trun looks at test_RateControl

[08:20] < Lawouach_> Personally the interface you designed suit me well

[08:20] < Lawouach_> Your test_Echoer.py is nicely commented and laid out

[08:21] < Lawouach_> that's really a good start

[08:21] *** mhrd reads logs Trun identified

[08:22] < Lawouach_> Trun: You'll notice that it's already easier for us to comment and help you ;)

[08:23] < Trun> ( Lawouach_: the comments are based on comments added by Michael to another example... my original comments were really bad, so I used his much clearer format )

[08:23] < Trun> Lawouach_: yep, thanks :-)

[08:23] < mhrd> I think I've decided that I provisionally disagree with MS-

[08:23] < mhrd> :)

[08:23] < Lawouach_> I'm not sure about the time based decision.

[08:24] < mhrd> maybe we need both? :)

[08:24] < Lawouach_> mhrd: ditto

[08:24] < Lawouach_> I cann his rational but I don't think that ought to impact the test interface

[08:24] < Lawouach_> can see

[08:24] < Lawouach_> meh

[08:26] < Trun> mhrd: what do you mean by "a mock 'time' module"?

[08:26] < mhrd> My concerns are that time based testing is non deterministic - eg. if your machine gets heavily loaded suddenly, the test can fail. However, there are one or two attempts at thread-safety tests in axon which I put in the Axon test suite, which do work like that

[08:27] < mhrd> A class with the same methods/attributes as the 'time' module. It is then plugged in in place of the normal 'time' module

[08:27] < Lawouach_> Trun: why is there a return in the main() method of the Echo component? You don't want to read more than one message?

[08:27] < Lawouach_> mhrd: I agree.

[08:28] < mhrd> Also (though I admit I'm not sure if I can find any examples) - I can think of cases where you want to test things at a precise moment in time - eg. making sure messages arriving at the inbox of the Carousel are not lost when teh carousel swaps out its child component for a new one

[08:28] < Trun> is not it the same that what it's done in http://rafb.net/p/qedlke78.html ?

[08:28] < Trun> I mean, once I get a control message, I finish the main method. In http://rafb.net/p/qedlke78.html it breaks the loop and then it finishes the main method

[08:28] < Lawouach_> Trun: there i no return in mine ;)

[08:29] < Lawouach_> oh my bad

[08:29] < Lawouach_> you changed the order of your box handling

[08:29] < Lawouach_> that's fine then

[08:29] < Lawouach_> forget about it :)

[08:30] < Lawouach_> mhrd: I agree. However, Trun, what did you mean by "step" testing?

[08:30] < Lawouach_> What does "step" reffer to?

[08:31] < Trun> I was thinking in running iterations of the scheduler

[08:32] < Trun> (hold on, I have a piece of code for that)

[08:32] < mhrd> maybe it would be possible to put some kind of wrapper between the scheduler and the component under test, so you could count (or even control) when it gets executed?

[08:32] < mhrd> (no idea how to do that :) )

[08:33] < Lawouach_> I guess i'm missing the underlying issue here.

[08:33] < Lawouach_> As far as I know, once a component is wrapped in a Handle() the .get() is blocking isn't it?

[08:33] < mhrd> iirc, yes

[08:35] < Trun> http://kamaelia.svn.sourceforge.net/viewvc/kamaelia/branches/private_PO_Tests/Kamaelia/Kamaelia/Testing/KamTestCaseOld.py?revision=4786&view=markup

[08:35] < Trun> in the line 225

[08:35] < Trun> to 261

[08:35] < Lawouach_> Trun: what is the rational of that piece of code?

[08:36] < Trun> in lines 231-233 I started running a scheduler

[08:36] < Lawouach_> I still don't understand the issue you're trying to solve here.

[08:36] < Lawouach_> why? :)

[08:36] < Trun> yep, sorry :-)

[08:36] < Trun> the idea of this code

[08:36] < Trun> is to make the testing "deterministic"

[08:37] < Trun> for that, I tried to have "the control of the scheduler"

[08:37] < Trun> so in that first version of the testing framework, I tried to be able to say

[08:37] < mhrd> aah, that code is trying to second guess how many steps/iterations of the scheduler will be needed to ensure that every currently active component is run?

[08:38] < Trun> "hey, component under test, you will get this input at 'step' "

[08:38] < Trun> "then you will get this other input at this other 'step' "

[08:38] < Trun> mhrd: yep

[08:38] < Trun> "then I run during N 'steps', and if you have not finished I assert that something has failed"

[08:39] < Trun> "finally, I get the stored messages and I check the expectations"

[08:39] < mhrd> the main() generator in the scheduler is, basically:

[08:39] < mhrd> def main():

[08:39] < mhrd> . for c in activeComponents:

[08:39] < mhrd> . c.next()

[08:39] < mhrd> . yield 1

[08:39] < mhrd> oops, bad indentation...

[08:40] < mhrd> the main() generator in the scheduler is, basically:

[08:40] < mhrd> def main():

[08:40] < mhrd> . for c in activeComponents:

[08:40] < mhrd> . . c.next()

[08:40] < mhrd> . . yield 1

[08:40] *** Chong- has joined #kamaelia

[08:41] < Lawouach_> I understand the assumption you've made but I wonder if that meets the way a real Kamaelia based application would be working.

[08:41] < Lawouach_> Afterall unit test is about to simulate *real life* use cases

[08:41] < Lawouach_> Otherwise it's just a sandbox with no little added value.

[08:43] < mhrd> I also consider it a way to validate specific assertions about the behaviour of a component - eg. asserting that a timer component will have certain properties.

[08:43] < Trun> I see, but then what are you thinking on when you talked about a "not time based" version?

[08:43] < mhrd> ... which then makes me more confident about using it later for real life stuff

[08:44] < Lawouach_> mhrd: I'm not sure which way you're arguing for ;)

[08:44] < mhrd> Trun: is that a q for me or Lawouach_ ? :)

[08:44] < Trun> for Lawouach_ (sorry, not used to IRC :-D )

[08:44] < mhrd> Lawouach_ : heh. I have to say, I've not really seriously considered what the benefits might be of teh 'time based' approach - I'd never realised ti could make teh test code x100 cleaner :)

[08:45] < Lawouach_> Trun: I don't know yet :)

[08:45] < mhrd> I'm arguing for an approach where your test can step through the execution of the component(s) under test

[08:46] < Trun> mhrd: do you mean something like:

[08:47] < Trun> 1. add input (optional)

[08:47] < Trun> 2. move N steps to the future

[08:47] < Trun> 3. add new input / check outputs

[08:47] < mhrd> yep

[08:47] < Trun> (loop 2-3 some times)

[08:47] < mhrd> ie. X = MyComponent.main()

[08:47] < mhrd> do something

[08:47] < mhrd> X.next()

[08:47] < mhrd> test something

[08:47] < mhrd> X.next()

[08:47] < mhrd> test something else

[08:47] < mhrd> X.next()

[08:47] < Trun> I see

[08:48] < Trun> but dealing with the scheduler so as to interact with children components, etc.?

[08:48] < mhrd> yes

[08:48] < Trun> I see

[08:48] < mhrd> as I said, I think I'm disagreeing with MS- :)

[08:49] < Trun> anyway, the time based idea would still be interesting as a more "realistic" way to test certain components, right?

[08:49] < mhrd> and I do really like the simplicity of the example you pastebin'ed

[08:49] < Trun> I mean, as you said maybe the testing framework should support both ways

[08:49] < mhrd> possibly yes

[08:50] < mhrd> I'd still worry a little about the indeterminacy of the time based approach. It would be great if it could be emulated somehow as a layer around the stepping approach.

[08:50] < Lawouach_> alright

[08:50] < Lawouach_> I like the .next() interface but I admit I can see the simplicity of the approach you've chosen in your pastebin example

[08:50] < Lawouach_> Both would probably be needed

[08:51] < Trun> ok, should I sum this up in an e-mail to the list?

[08:51] < mhrd> Lawouach_ - I herald you resolver of disagreements :-)

[08:51] < mhrd> Trun: good idea

[08:52] < Trun> ok :-)

[08:52] < mhrd> you have any thoughts about this? I'm just saying what I think, which is not necessarily what you should do :)

[08:52] < Trun> my first idea was using a "deterministic" way, to make the tests independent from the context (machine, other processes running, etc.)

[08:53] < Trun> since I thought that tests should be as deterministic as possible

[08:54] < Trun> but when suggested by MS- and had some code done, I also liked the time based approach

[08:55] < Trun> I find it more "realistic" and easier to interact with (it may seem closer to a debugger, like 'now I add this', and actually at that point that message is added)

[08:55] < Trun> but for instance, the test in the pastebin can't test if the Echoer uses a "while" or a "if" when gathering information from 'inbox'

[08:56] < Trun> if you provide two messages in a step and a producerFinished, you will see both messages being forwarded

[08:57] < Trun> because the two messages may be sent in a different step

[08:57] < mhrd> actually thats a good example - its hard to test the behaviour at point of shutdown. eg. testing an assertion that the compnoent will finish off processing any pending data

[08:58] < Trun> yep, so I like the idea of supporting both approaches

[08:59] < mhrd> I suspect MS- may disagree with me over whether the precision of that kind of behaviour (at shutdown) really matters. I'm pretty sure I've built systems where I've needed it.

[08:59] < Trun> btw, are you comfortable with the approach of being integrated in a "unittest.TestCase"-like way?

[08:59] < mhrd> But I've tended to get more worried about shutdown behaviour than MS- in the past :)

[08:59] < Trun> I mean, maybe something else should be built for that or this way may be fine?

[09:00] < mhrd> integrating like that looks pretty clean - nice to keep the familiar style of API, irrespective of whether the actual implementation subclasses it directly or not

[09:00] < Trun> ok

[09:01] < Trun> thank you very much for this feedback :-)

[09:01] < Trun> I'm taking a coffee and I come back to write the e-mail to the list

[09:01] < mhrd> sounds like a few small examples (test cases !) might be useful to demo where/what potential issues there might be

[09:02] < Trun> yep

[09:02] < mhrd> Trun: cool - its been helpful for me too - haven't really thought properly about these issues before

[09:03] < mhrd> also most of the tests I've written have been ones for the internals of Axon - for which the emphasis is going to be slightly different

[09:21] *** matthew-p has parted #kamaelia

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

[09:34] < orphans> morning all

[09:36] < Lawouach_> hi mate

[09:36] < orphans> how's it going?

[09:36] < Lawouach_> good but feeling tired today

[09:37] < orphans> today I've already managed to get locked out of my house for about two hours :)

[09:37] < orphans> feeling bright and fresh after that

[09:39] < Lawouach_> I bet :)

[09:43] < orphans> eesh, how much time do we spend "interacting" Lawouach_? This student survey is a nightmare :)

[09:44] < Lawouach_> I filled mine this morning

[09:44] < Lawouach_> I've put from 0-5

[09:45] < Lawouach_> We may spend more time but not always not on the project

[09:45] < Lawouach_> anyway I'm not gonna give you the answers

[09:45] < Lawouach_> :p

[09:45] < orphans> heh, damn you :)

[09:45] *** Lawouach_ edits his review

[09:45] < Lawouach_> :)

[09:46] < orphans> I can has google money?

[09:47] < Lawouach_> :)

[09:47] *** Lawouach_ puts Oceansize on

[09:48] < Lawouach_> If you want to albums that'll rock you: Amplifier by Amplifier and Effloresce by Oceansize

[09:48] < Lawouach_> LOUD :)

[09:49] < orphans> mm, I think I know Oceansize, but I couldn't place the music

[09:49] < Lawouach_> prog-rock I guess

[09:49] < Lawouach_> Both bands are from Manchester BTW

[09:50] < orphans> ahh, yeah - they've toured with Biffy and Mclusky

[10:01] < Chong-> Hi Trun, just replied to your question in the list. Some of them may not fit your framework. If so, just ignore them :-)

[10:05] < Trun> thanks for the that, Chong- :-)

[10:06] < Chong-> Trun: my pleasure :-)

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

[10:15] < orphans> survey in - that took far too long :)

[10:15] < MS-> Hey Trun - just a note -please make sure that you forward the daily 2-3 paragraph status updates we agreed :) Doesn't have to be long or detailed, but you'll probably get useful feedback if you do :)

[10:16] < Trun> MS-: oh, ok

[10:16] < MS-> Just along the lines of "done this, planning to do this (not necessarily something you can do in 24 hours, just what you're planning :), and anything else arising" :)

[10:16] < MS-> Think of it like blogging

[10:16] < MS-> :)

[10:17] < MS-> It *does* have an RSS feed after all ;-) :-D

[10:17] < MS-> [08:03] < Trun> I wrote last night some documentation of an example of this interface

[10:17] < MS-> [08:03] < Trun> in the way Michael documented one of the examples on r4826

[10:18] < MS-> That should be forwarded to the list....

[10:18] < Trun> ok, may I first finish answering to the thread discussion and send an e-mail about the discussion I had with Matt and Sylvain this morning?

[10:18] < MS-> Yeah, sure

[10:18] < MS-> This is just "adding to the list" ;-)

[10:18] < MS-> :)

[10:18] < MS-> Now that I can see what you're doing I can make "helpful" suggestions :)

[10:18] < Trun> yep, I'm going to send a (short) e-mail regarding that discussion

[10:19] < MS-> [08:05] < Trun> well, I'm working without svn access, should I send it to the list with subject "[PATCH] Adding example of a testing interface"

[10:19] < MS-> Fantastic idea :)

[10:19] < Trun> < MS-> This is just "adding to the list" ;-) --> ok :-)

[10:20] < MS-> Just trying to break a habit that's all. The best way we can achieve that is but encouraging use of things that break that habit ;) :-)

[10:20] < MS-> [08:23] < mhrd> I think I've decided that I provisionally disagree with MS-

[10:20] < MS-> heheh cool

[10:21] *** MS- wonders what mhrd disagreed with

[10:23] < mhrd> I like the clarity of writing tests like that - where you can treat the system as something running in the background; but I worry about the lack of determinacy - makes it hard to validate assertions for certain kinds of behaviour - eg. at time of shutdown (see [09:56] to [09:59] )

[10:23] < MS-> Tests like what?

[10:24] *** MS- misses the context

[10:24] < MS-> Do you mean Axon.background()

[10:24] < MS-> ?

[10:24] < mhrd> eg. I might assert that if a component receives a shutdown message it will guarantee to finish processing any data remaining in its "inbox" inbox before terminating

[10:25] < MS-> I think I'm missing what the conversation is about

[10:25] < mhrd> I've been pretty remiss and not really written any tests for that kind of thing, but I think I ought to in future

[10:25] < MS-> :)

[10:26] < mhrd> """09:21 Trun but in a mentor meeting ( http://yeoldeclue.com/logs/kamaelia2008-06-10_log.html [14:06] to [14:12] ) I was suggested to define the expectations in terms of time instead of in terms of steps"""

[10:27] < mhrd> which by my understanding, and Trun's (on the basis of what he has written) means that you run a compnoent in a backgrounded scheduler then use something like the Axon.Handle mechanism to read/write from it

[10:27] < mhrd> +ve: very nice clear succinct test code

[10:28] < mhrd> -ve: can't see how I'd test/validate assertions for specific behaviour under some precise conditions - eg. the shutdown one I just described.

[10:29] < mhrd> I think I currently agree with Lawouach_ that what might be cool would be to be able to test both

[10:29] < mhrd> (excuse - phone)

[10:29] < mhrd> < /phone>

[10:30] *** mhrd ought to produce some short examples that demonstrate in the context of some existing components that make these kinds of assertions in their docs

[10:30] < MS-> Ah, I think you're treating that as either/or

[10:30] < MS-> I prefer this AND that

[10:30] < MS-> Rather than this OR that

[10:30] < MS-> :)

[10:30] < mhrd> OR rather than XOR?

[10:30] < MS-> yep :)

[10:30] < mhrd> cool

[10:30] < mhrd> I'm happy then

[10:31] < mhrd> :)

[10:31] < orphans> anyone ever used ctypes before?

[10:31] < MS-> 99% kamaelia is more OR than XOR :)

[10:31] < MS-> yep, it's great for causing a segfault

[10:31] < MS-> >:-)

[10:31] < orphans> not a good thing for definite?

[10:31] < MS-> (that's about my limit BTW)

[10:31] < MS-> Oh, no it's a fantastic thing

[10:31] < MS-> But you have to be careful how you use it, that's all

[10:32] < MS-> with great power, etc

[10:32] < orphans> mhm

[10:33] < orphans> context: don't know whether you saw last night's discussion with Lawouach_ about whether to include MIDI support. I reckon it's maybe worthwhile but the python library is horribly packaged, hard to install etc etc

[10:34] < orphans> but I've just found a new lib which wraps PortMidi using ctypes which looks a lot cleaner and easier to distribute

[10:34] < Lawouach> orphans: rather then technical limitations, I'd rather have a point of view based on the value to the project.

[10:35] < Lawouach> orphans: just as a FYI, more than once in your developer life you'll go back to your manager and will tell him "it's not technically easy to achieve" and he/she'll turn back and reply "I don't care, the customer wants it so we'll deliver it"

[10:35] < Lawouach> :)

[10:35] < Lawouach> So you have to convince me based on whether or not it adds reall value to the project.

[10:35] < MS-> BTW, Trun, you don't "not have access to svn", I'm just your checkin-bot at the moment. Unlike the svn binary though I'll probably ask awkward questions, that's all

[10:36] < Trun> MS-: ok :)

[10:36] < MS-> I still view /Sketches/PO as your area, you just now have a "customer service representative" now instead of just talking to a machine

[10:36] < MS-> "Hi, my name's michael, I'll be your server for today, how may I help you?" :)

[10:37] < orphans> Lawouach, ok, in that case I think I've made my mind up to go for it - I don't think it's too hard to write the code to get jam working with it (should be relatively trivial), and there's definite value there for the project

[10:37] < MS-> We could probably get kamaelia bot to do that actually...

[10:37] < MS-> ;)

[10:37] < MS-> :)

[10:37] < Lawouach> orphans: cool

[10:37] < Lawouach> That's fine by me. You make the commitment ;)

[10:37] < orphans> Lawouach, my main reservations were technical, so if we're ignoring them then I reckon it can't hurt to give it a go :)

[10:37] < Lawouach> Sounds fair.

[10:39] *** MS- has to disappear for a while.

[10:39] < MS-> biab

[10:39] *** MS- has parted #kamaelia

[11:55] *** Davbo has joined #kamaelia

[12:22] *** Chong- has joined #kamaelia

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

[13:23] *** Davbo is filling in the mid-term student survey for SoC

[13:46] < Davbo> 22. What advice would you give to future would-be Summer of Code mentoring organizations? (required)

[13:46] *** Davbo ponders

[13:46] *** mhrd has parted #kamaelia

[13:47] *** mhrd has joined #kamaelia

[14:21] < Chong-> *Students who receive a positive evaluation but fail to complete the midterm survey will also be dropped from the program and no further payments made to them.*

[14:22] < Chong-> So, please remember to fill it in before Monday, July 14th at 19:00 UTC (12 noon Pacific time) :-)

[14:25] < Davbo> Yeah, mhrd you should have one to do for me I believe :-) (friendly reminder) "Your mentor has not yet started the midterm survey."

[14:35] *** mhrd rummages

[14:36] < mhrd> don't worry - will be sorted in good time :)

[14:51] *** mhrd has parted #kamaelia

[14:52] *** mhrd has joined #kamaelia

[15:06] < Lawouach_> my god YUI documentation is patchy

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

[16:07] *** Chong- has joined #kamaelia

[16:57] *** Trun has joined #kamaelia

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

[18:43] < Lawouach> http://news.bbc.co.uk/2/hi/technology/7495085.stm < -- :/

[18:47] < Lawouach> via reddit http://www.evolus.vn/Pencil/Home.html < -- nice

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

[19:03] < j_baker> Sigh... it looks like my country isn't the only one in its telecoms' pockets, Lawouach. :/

[19:04] < j_baker> http://arstechnica.com/articles/culture/fisa-compromise.ars

[19:05] < j_baker> "What? You helped the government wiretap our citizens without any legal reason to? No problem! We'll just give you immunity. And make it easier for you to do semi-legal wiretaps."

[19:05] < Lawouach> that's crazy

[19:35] < vmlemon> Anyone saw the Vodafone Greece wiretapping incident that lead to someone committing suicide?

[20:47] < Lawouach> kde4 sucks so bad on Ubuntu for now

[21:08] < aa_> Lawouach: I think kde4 is not ready yet

[21:08] < aa_> Lawouach: it's certainly broken :)

[21:08] < Lawouach> it's clumsy

[21:09] < Lawouach> On the other hand I'm using Qt4 quite happily

[21:09] < Lawouach> very stable, fast and memory-friendly

[21:14] < aa_> yeah qt4 has been around for years though

[21:15] < aa_> I thing kde4 will be ready at like 4.3 or something

[21:15] < aa_> maybe 4.2.99999