--- Log opened Wed Aug 15 00:00:17 2012 | ||
shogun-buildbot | build #355 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/355 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 00:12 |
---|---|---|
shogun-buildbot | build #284 of deb2 - static_interfaces is complete: Failure [failed test cmdline_static] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb2%20-%20static_interfaces/builds/284 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 00:14 |
@sonney2k | blackburn, yes | 01:04 |
blackburn | sonney2k: I forgot what I wanted to say, so nevermind :D | 01:05 |
@sonney2k | hah | 01:05 |
@sonney2k | did you get the bb happy? | 01:05 |
blackburn | no, not yet | 01:05 |
blackburn | there are a DUALLIBQPBMRMSOMCSVM | 01:05 |
-!- cwidmer [45c9b18c@gateway/web/freenode/ip.69.201.177.140] has joined #shogun | 01:05 | |
blackburn | bug | 01:06 |
@sonney2k | wow now everything crashes | 01:06 |
blackburn | sonney2k: it was hard but I managed to carry out all these crashes | 01:06 |
blackburn | believe me it is hard to break everything :D | 01:06 |
@sonney2k | blackburn, from experience I think you are joking :D | 01:08 |
blackburn | I will fix cmdline static | 01:09 |
blackburn | python modular won't be fixed before our SO guys negotiate anything | 01:09 |
@sonney2k | grmpf | 01:29 |
-!- cwidmer [45c9b18c@gateway/web/freenode/ip.69.201.177.140] has quit [Quit: Page closed] | 02:27 | |
CIA-21 | shogun: Sergey Lisitsyn master * rf7116ba / src/shogun/lib/malsar/malsar_clustered.cpp : Restored termination check in clustered MTL - http://git.io/VK8TsA | 02:33 |
shogun-buildbot | build #356 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/356 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 03:02 |
-!- blackburn [~blackburn@109.226.80.43] has quit [Quit: Leaving.] | 03:03 | |
shogun-buildbot | build #285 of deb2 - static_interfaces is complete: Failure [failed test cmdline_static] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb2%20-%20static_interfaces/builds/285 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 03:04 |
shogun-buildbot | build #55 of nightly_none is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_none/builds/55 | 03:06 |
shogun-buildbot | build #64 of nightly_default is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/64 | 03:39 |
shogun-buildbot | build #51 of nightly_all is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_all/builds/51 | 04:08 |
-!- gsomix_ [~gsomix@88.200.214.210] has joined #shogun | 08:17 | |
-!- gsomix_ [~gsomix@88.200.214.210] has quit [Client Quit] | 08:17 | |
-!- uricamic [~uricamic@2001:718:2:1634:88c4:9daf:4b80:763c] has joined #shogun | 08:43 | |
-!- n4nd0 [~nando@98.Red-2-137-39.dynamicIP.rima-tde.net] has joined #shogun | 09:06 | |
uricamic | n4nd0: hi | 09:17 |
n4nd0 | hi uricamic | 09:17 |
n4nd0 | how are you doing? | 09:17 |
uricamic | good, how are you? | 09:17 |
n4nd0 | I am fine too | 09:18 |
n4nd0 | enjoying my last days in Spain | 09:18 |
uricamic | I installed mosek, but shogun configuration script haven't found it, is there something what shall I do to help it? | 09:18 |
n4nd0 | I am coming back to Sweden on Friday | 09:18 |
uricamic | nice :) | 09:18 |
n4nd0 | yes | 09:18 |
n4nd0 | I didn't change anything in the configure script to detect mosek (soeren told me not to worry about it) | 09:19 |
n4nd0 | although Sergey added something | 09:19 |
n4nd0 | what I do is just to run ./configure | 09:19 |
n4nd0 | and later to add manually a couple of changes for mosek in the file .config | 09:19 |
n4nd0 | I can tell you about them if you want | 09:19 |
uricamic | I see, I was confused because there is info in configuration output that MOSEK was not found | 09:20 |
n4nd0 | mmm ok | 09:20 |
n4nd0 | that must be probably what Sergey added | 09:20 |
uricamic | I wanted to try your python example, because I have figured out, that my example crashes on exit | 09:20 |
n4nd0 | but I don't know whether it works | 09:20 |
n4nd0 | all right | 09:21 |
n4nd0 | then just do these modifications | 09:21 |
uricamic | and I have tried to run valgrind on it and pointed out some lines in MulticlassSOLabels so I just wanted to compare with your example if it will aslo be the case | 09:21 |
n4nd0 | aham ok | 09:21 |
n4nd0 | I am sure that the HMSVM doesn't leak memory | 09:22 |
n4nd0 | but it might be that the Multiclass example does because now that I think of it I didn't check this with valgrind, have to do that soon! | 09:22 |
n4nd0 | uricamic: did you get the mail? | 09:22 |
n4nd0 | I have just forwarded you the same instructions I sent to Nico some time ago to build with MOSEK | 09:23 |
uricamic | yes, thx. And if you run your python multiclass example does it exit normally? | 09:23 |
uricamic | in my case everything works nicely, but on exit it crashes with segmentation fault. | 09:24 |
uricamic | I can send you valgrind output on that | 09:24 |
n4nd0 | uricamic: we are talking about so_multiclass.py right? | 09:25 |
uricamic | yep | 09:26 |
uricamic | but I have run valgrind so far only on so_multiclass_BMRM.py | 09:26 |
uricamic | since I have not yet managed to get so_multiclass.py working with MOSEK yet | 09:26 |
n4nd0 | but you are right | 09:27 |
n4nd0 | something explodes in that example | 09:27 |
n4nd0 | I get a *** glibc detected *** python: free(): invalid pointer: 0x09e33d38 *** | 09:27 |
n4nd0 | once I started with hm-svm I never tried compatibility with the multiclass thing with the new changes :( | 09:27 |
n4nd0 | sorry about that | 09:28 |
n4nd0 | let me see | 09:28 |
uricamic | https://gist.github.com/c8e5335419f15ada9f89 | 09:28 |
n4nd0 | mmm | 09:28 |
n4nd0 | let me try with the libshogun example | 09:28 |
n4nd0 | C++ traces are far more readable... | 09:28 |
uricamic | it is ok, I was just trying to figure out what is wring, since I have never written anything in python :) | 09:29 |
n4nd0 | ok :) | 09:29 |
n4nd0 | the error appears in the C++ example too, which is good | 09:30 |
uricamic | really? | 09:31 |
uricamic | because for me my C++ example worked fine | 09:31 |
n4nd0 | my so_multiclass.cpp had a *** glibc detected *** ./so_multiclass: free(): invalid pointer: 0x09d25fc8 *** | 09:31 |
uricamic | I see, I haven't checked the C++ example with valgrind yet, but at least it haven't produced any segfault on running | 09:34 |
uricamic | n4nd0: btw what do you mean by C++ traces? | 09:35 |
n4nd0 | like the gist you sent me | 09:35 |
n4nd0 | valgrind detects lot of things with python programs | 09:35 |
n4nd0 | just because of the python language | 09:35 |
n4nd0 | (one can either use a suppresions file or re-compile python with some flags) | 09:35 |
uricamic | I see | 09:36 |
n4nd0 | so those are normally hard to read | 09:36 |
uricamic | ok | 09:36 |
n4nd0 | however, C++ ones are cleaner | 09:36 |
uricamic | yep, sure | 09:36 |
uricamic | And finally the last thing concerning the merging of risk function and structured models :) | 09:37 |
n4nd0 | sure, tell me | 09:38 |
uricamic | I think there have just been some misunderstanding at the beginning of GSoC or we only forgot our original intentions | 09:38 |
uricamic | I remember that at the beginning, we have been discussing the risk function and I have told you, that the risk function consists of argmax with loss and building psi vectors | 09:39 |
n4nd0 | ok | 09:39 |
uricamic | but because we had to submit some code already, this divergence happened :) | 09:39 |
n4nd0 | all right | 09:40 |
n4nd0 | so then | 09:40 |
uricamic | but then somehow, we forgot that we wanted to put it back together | 09:40 |
n4nd0 | is it possible to do a generic risk function in StructuredModel right? | 09:40 |
n4nd0 | there is no need to re-define in multiclass model, hm-svm, etc | 09:40 |
n4nd0 | because the parts that change are argmax, loss, and psi | 09:41 |
n4nd0 | or? | 09:41 |
uricamic | it is, but I guess sometimes, the risk function can be written more efficiently, so there should still be possibility to redefine it | 09:41 |
n4nd0 | sure | 09:41 |
n4nd0 | virtual method :D | 09:41 |
uricamic | yep :) | 09:41 |
n4nd0 | ok | 09:41 |
n4nd0 | let's do that then | 09:41 |
uricamic | that was the intention of possibility to pass some user data to the risk function | 09:41 |
n4nd0 | mm I don't understand that | 09:42 |
n4nd0 | can you explain me more what do you mean with user data to the risk function? | 09:42 |
uricamic | because you can e.g. precompute a lot of things because it is done in each iteration of BMRM again | 09:42 |
n4nd0 | I see | 09:43 |
uricamic | sure for example in one of my applications of SO-SVM for facial landmark detection, the computation of risk is quite complex, I mean time demanding | 09:43 |
n4nd0 | ok | 09:43 |
n4nd0 | and what do you there then? | 09:43 |
uricamic | but if u have a computer with a lot of memory, you can save a lot of computations by precomputing some matrix multiplications | 09:43 |
uricamic | in this particular example I now can afford to precompute loss for all examples | 09:44 |
-!- n4nd0 [~nando@98.Red-2-137-39.dynamicIP.rima-tde.net] has quit [Quit: leaving] | 09:44 | |
-!- n4nd0 [~nando@98.Red-2-137-39.dynamicIP.rima-tde.net] has joined #shogun | 09:45 | |
uricamic | and also precompute all psi vectors in the last term of evaluation of risk | 09:45 |
n4nd0 | ok | 09:45 |
n4nd0 | uricamic: I have to go now | 09:46 |
uricamic | moreover we have done lately some experiments with incompletely annotated examples, which also needs some other things to be passed to risk function | 09:46 |
uricamic | n4nd0: ok, see ya | 09:46 |
n4nd0 | uricamic: I have not managed to detect what is wrong with the multiclass model, why that glibc appears | 09:46 |
n4nd0 | but I'll come back to this tonight | 09:46 |
uricamic | ok | 09:46 |
n4nd0 | bye! | 09:46 |
-!- n4nd0 [~nando@98.Red-2-137-39.dynamicIP.rima-tde.net] has quit [Client Quit] | 09:46 | |
-!- heiko [~heiko@host86-179-59-65.range86-179.btcentralplus.com] has joined #shogun | 09:58 | |
wiking | uricamic: mmm waht was now the consensus for the risk function? :) | 11:54 |
wiking | pure virtual or virtual? :) | 11:54 |
-!- heiko1 [~heiko@host86-185-9-87.range86-185.btcentralplus.com] has joined #shogun | 13:20 | |
uricamic | wiking: I guess virtual | 13:20 |
-!- heiko [~heiko@host86-179-59-65.range86-179.btcentralplus.com] has quit [Ping timeout: 260 seconds] | 13:21 | |
wiking | okei | 14:58 |
uricamic | wiking: and have you seen yesterday the message about change in risk function? | 14:59 |
uricamic | that insted of void the retrun type should be flaot64_t ? | 14:59 |
wiking | uricamic: ah yeah | 15:11 |
wiking | i saw that | 15:11 |
wiking | but what should be the value? | 15:11 |
wiking | i mean it represents what? | 15:11 |
uricamic | instead of passing argument R which is there just to store the result of the value of risk function it will return this value | 15:11 |
wiking | ah ok | 15:12 |
wiking | so R gets out from the function args | 15:12 |
uricamic | i.e. R will pop out from the argument list and instead of it this value will be returned | 15:12 |
wiking | okok | 15:12 |
uricamic | yep, exactly | 15:12 |
wiking | i'll do that change | 15:12 |
wiking | first i'll do a change in latentlabels | 15:12 |
wiking | and then i'll send in the new patch for the risk as well | 15:12 |
uricamic | so it requires also to change 2 lines in each libbmrm.cpp, libppbm.cpp and libp3bm.cpp | 15:13 |
uricamic | ok, thanks | 15:13 |
wiking | yeps | 15:13 |
wiking | no worries | 15:13 |
uricamic | thank you very much, for this inconveniences | 15:13 |
wiking | no no it's cool | 15:14 |
wiking | on the end it'll help me as well | 15:14 |
uricamic | in the end everything will be probably nicely merged together :) | 15:15 |
wiking | hehehe yeah i'm hoping that i can do something similar with latent and structured model ;) | 15:16 |
wiking | we'll see how that'll end up | 15:16 |
wiking | btw libbmrm.cpp, libppbm.cpp and libp3bm.cpp are all solving the same minimization problem right? | 15:16 |
wiking | just in a different way? | 15:16 |
uricamic | yep | 15:17 |
uricamic | well, more or less | 15:17 |
wiking | okok | 15:17 |
uricamic | in libppbm and libp3bm is added proximal term to the function that is optimized | 15:18 |
uricamic | i.e. instead of just minimizing \lambda/2 || w ||^2 + R(w) | 15:19 |
uricamic | we are minimizing \lambda/2 || w ||^2 + \alpha || w - w_t ||^2 + R(w) | 15:20 |
uricamic | and the difference between libppbm and libp3bm is that libp3bm uses multiple cutting plane models | 15:20 |
uricamic | but when number of cp models is set to 1, then those two are identical | 15:21 |
-!- uricamic [~uricamic@2001:718:2:1634:88c4:9daf:4b80:763c] has quit [Quit: Leaving.] | 17:44 | |
-!- blackburn [~blackburn@109.226.80.43] has joined #shogun | 18:51 | |
wiking | blackburn: ! | 19:09 |
blackburn | wiking: ! | 19:09 |
wiking | blackburn: merge :) | 19:13 |
blackburn | ok | 19:15 |
blackburn | be back in 15 minutes | 19:16 |
CIA-21 | shogun: iglesias master * rccc31d9 / (8 files in 2 dirs): * doc fixes and less warnings - http://git.io/5nO2Ew | 19:50 |
CIA-21 | shogun: Sergey Lisitsyn master * r09b33ad / (8 files in 2 dirs): Merge pull request #716 from iglesias/so - http://git.io/PSwwhQ | 19:50 |
CIA-21 | shogun: Viktor Gal master * r5689042 / (11 files in 5 dirs): Redesign LatentLabels This way LatentLabels not only store actually the h_i (latent labels) but as well as in a general way store the actual y_i (labels). - http://git.io/kj8cGw | 19:59 |
CIA-21 | shogun: Sergey Lisitsyn master * reee036e / (11 files in 5 dirs): Merge pull request #718 from vigsterkr/latent - http://git.io/quttLA | 19:59 |
blackburn | wiking: around? | 20:00 |
shogun-buildbot | build #357 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/357 blamelist: iglesias <fernando.iglesiasg@gmail.com> | 20:32 |
shogun-buildbot | build #286 of deb2 - static_interfaces is complete: Failure [failed test cmdline_static] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb2%20-%20static_interfaces/builds/286 blamelist: iglesias <fernando.iglesiasg@gmail.com>, Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 20:35 |
CIA-21 | shogun: Sergey Lisitsyn master * r42f6150 / data : Updated data - http://git.io/N2m4gQ | 20:40 |
-!- naywhaya1e [~ryan@spoon.lugatgt.org] has joined #shogun | 20:40 | |
-!- zxtx [~zv@c-24-18-130-24.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds] | 20:44 | |
-!- Netsplit *.net <-> *.split quits: naywhayare | 20:45 | |
-!- gsomix [~gsomix@178.45.80.114] has joined #shogun | 20:58 | |
gsomix | good evening | 20:59 |
-!- gsomix_ [~gsomix@109.169.131.21] has joined #shogun | 21:00 | |
shogun-buildbot | build #358 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/358 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 21:00 |
-!- gsomix [~gsomix@178.45.80.114] has quit [Read error: Connection reset by peer] | 21:02 | |
shogun-buildbot | build #347 of deb1 - libshogun is complete: Failure [failed git] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/347 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com>, Viktor Gal <viktor.gal@maeth.com> | 21:03 |
@sonney2k | gsomix_, hey there! | 21:09 |
@sonney2k | gsomix_, how is 0-copy? | 21:09 |
gsomix_ | sonney2k, there is one small problem. I need overload free_feature_matrix in swig. now I'm trying resolve. :) | 21:11 |
-!- gsomix_ is now known as gsomix | 21:12 | |
@sonney2k | gsomix, hmmhh indeed IIRC blackburn also did nasty things when preprocessing freatures (freeing the feature matrix) | 21:13 |
@sonney2k | gsomix, is there a way in python to 'own' the numpy array? | 21:13 |
-!- heiko1 [~heiko@host86-185-9-87.range86-185.btcentralplus.com] has quit [Quit: Leaving.] | 21:14 | |
gsomix | sonney2k, own? what do you mean? I just get internal buffer from numpy array and keep it. | 21:15 |
@sonney2k | gsomix, so you Py_INCREF? | 21:17 |
@sonney2k | or how do you ensure that this buffer is still valid later? | 21:18 |
gsomix | yep, automatically in PyObject_GetBuffer | 21:18 |
@sonney2k | ok | 21:18 |
gsomix | and decref in ReleaseObject. | 21:18 |
gsomix | only one problem - refcount in DenseFeatures. | 21:18 |
gsomix | *ReleaseBuffer | 21:19 |
gsomix | I need something like SGMatrix with refcount=2, because buffer is external | 21:20 |
gsomix | and I need overload free_feature_matrix for proper behavior | 21:20 |
@sonney2k | gsomix, why do you need to overload free_feature_matrix? | 21:25 |
gsomix | hm, waaaaaait... | 21:25 |
@sonney2k | isn't increasing the refcount in SGMatrix sufficient? | 21:25 |
@sonney2k | gsomix, ^ | 21:35 |
gsomix | nope. hm, but how can I increase refcount? | 21:36 |
gsomix | I just create new SGMatrix with numpy array's buffer | 21:36 |
@sonney2k | gsomix, why not? | 21:37 |
gsomix | sonney2k, hack? I just don't need to free buffer in DenseFeatures (free_feature_matrix or destructor). | 21:39 |
gsomix | maybe it's sufficient, but it's hack. | 21:40 |
@sonney2k | gsomix, the buffer is not freed | 21:41 |
@sonney2k | gsomix, just the refcount is decreased | 21:41 |
@sonney2k | gsomix, or do you want to call ReleaseBuffer? | 21:42 |
gsomix | I need to call ReleaseBuffer. | 21:42 |
gsomix | I figured out one solution. | 21:47 |
@sonney2k | gsomix, ? | 21:47 |
gsomix | I can to keep one more copy of new SGMatrix in Py_buffer object, that I getting from numpy array. | 21:48 |
gsomix | refcount++ | 21:48 |
@sonney2k | gsomix, for refcounts it is easy - you just make the ref/unref functions public in SGReferencedData | 21:48 |
@sonney2k | that is even better :D | 21:48 |
gsomix | sonney2k, public? are you sure? :) | 21:48 |
gsomix | sonney2k, so what do you prefer? | 21:49 |
@sonney2k | but for ReleaseBuffer you would have to either modify dense features to store the py object (awful :( or register some kind of callback function | 21:50 |
@sonney2k | like void release_buffer() :D | 21:50 |
@sonney2k | gsomix, yours! | 21:50 |
gsomix | ok | 21:50 |
@sonney2k | gsomix, ok with the callback idea? or do you have any other? | 21:55 |
gsomix | at this moment - other, but I'm not sure. need to experiment. | 21:56 |
gsomix | thanks! :) | 21:56 |
gsomix | sonney2k, ah! | 21:57 |
blackburn | sonney2k: he needs an LHC to check that | 21:57 |
gsomix | after all I need to overload free_feature_matrix. I need to call ReleaseBuffer in this method | 21:58 |
gsomix | blackburn, pffff. I have sent curiosity for checking some my shogun's ideas. :) | 22:00 |
gsomix | *Curiosity | 22:00 |
@sonney2k | gsomix, so ok with the release_buffer callback idea? | 22:04 |
gsomix | I don't know, why I need this callback func. | 22:04 |
gsomix | because ReleaseBuffer don't free buffer's memory. | 22:06 |
gsomix | it seems I'm a little misunderstood or confused. | 22:06 |
gsomix | :) | 22:06 |
@sonney2k | gsomix, how do you call ReleaseBuffer? | 22:09 |
@sonney2k | or better where is it called? | 22:09 |
gsomix | sonney2k, in destructor and free_feature_matrix. | 22:10 |
@sonney2k | gsomix, of DenseFeatures you mean? | 22:10 |
gsomix | yep | 22:10 |
@sonney2k | but you can you make DenseFeatures to be aware of that - I mean it knows nothing about python or anything | 22:10 |
gsomix | I can overload destructor and free_feature_matrix in swig | 22:11 |
@sonney2k | gsomix, how? | 22:11 |
gsomix | mmm, builtin and little hack | 22:12 |
gsomix | I have overload destructor already | 22:12 |
@sonney2k | gsomix, I think it is sufficient to overload free_feature_matrix | 22:12 |
@sonney2k | since that is called in destructor | 22:12 |
gsomix | yep =____= | 22:12 |
gsomix | hehe, I'm stupid | 22:13 |
@sonney2k | ok - then it is all good | 22:13 |
@sonney2k | gsomix, do it and PR it! | 22:13 |
gsomix | aha | 22:13 |
-!- zxtx [~zv@c-67-170-78-150.hsd1.wa.comcast.net] has joined #shogun | 22:24 | |
-!- blackburn [~blackburn@109.226.80.43] has quit [Quit: Leaving.] | 22:37 | |
-!- blackburn [~blackburn@109.226.80.43] has joined #shogun | 22:37 | |
-!- blackburn1 [~blackburn@109.226.78.36] has joined #shogun | 22:39 | |
-!- blackburn [~blackburn@109.226.80.43] has quit [Ping timeout: 245 seconds] | 22:41 | |
-!- blackburn [~blackburn@62.106.106.114] has joined #shogun | 22:42 | |
-!- blackburn1 [~blackburn@109.226.78.36] has quit [Ping timeout: 272 seconds] | 22:46 | |
-!- blackburn [~blackburn@62.106.106.114] has quit [Quit: Leaving.] | 23:19 | |
gsomix | sonney2k, around? | 23:20 |
@sonney2k | gsomix, yes? | 23:38 |
gsomix | sonney2k, what do you think about runtime hack? I can only to modify DenseFeatures method's table in init (runtime) section of module. | 23:39 |
gsomix | is it awful? | 23:41 |
@sonney2k | gsomix, for free_feature_matrix you mean? | 23:51 |
gsomix | yep | 23:51 |
@sonney2k | gsomix, I think it is already hacky anyways - so just do it :D | 23:51 |
gsomix | sonney2k, btw, did you read Levi "Hackers: heroes of computer revolution"? :) | 23:57 |
--- Log closed Thu Aug 16 00:00:17 2012 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!