--- Log opened Tue Aug 07 00:00:17 2012 | ||
-!- kyle__ [~kyle@173-165-60-19-Illinois.hfc.comcastbusiness.net] has joined #shogun | 00:02 | |
kyle__ | I was trying to jump into shogun, but all the docs I can find for octave/matlab usage are examples. Is there anyplace that spells out what feature types are available? Etc? | 00:07 |
---|---|---|
blackburn | kyle__: hello | 00:08 |
shogun-buildbot_ | build #265 of deb3 - modular_interfaces is complete: Failure [failed test libshogun] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/265 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 00:08 |
blackburn | kyle__: are you using modular interface? | 00:10 |
shogun-buildbot_ | build #220 of deb2 - static_interfaces is complete: Failure [failed test libshogun] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb2%20-%20static_interfaces/builds/220 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 00:11 |
kyle__ | blackburn: I just built the static one. | 00:12 |
blackburn | kyle__: check that then http://shogun-toolbox.org/doc/en/current/static_tutorial.html | 00:13 |
blackburn | but actually I'd recommend to use modular if possible | 00:13 |
kyle__ | Is the static one considered depricated or something? | 00:14 |
kyle__ | Or just not as full featured? | 00:15 |
blackburn | kyle__: it works but it is not actually extended with time | 00:16 |
kyle__ | Ah ok. | 00:16 |
kyle__ | Sadly I only found shogun while working on a final for a machine learning class. Right now I mostly just want to use it to run some kernel-based svms against a dataset that choked both matlab and octave with the methods we were given. | 00:17 |
kyle__ | (final is over, I'm just too damned stubborn) | 00:17 |
-!- gsomix [~gsomix@80.234.52.32] has quit [Ping timeout: 256 seconds] | 00:20 | |
blackburn | kyle__: if you consider using python it could worth it - we all are using it | 00:21 |
kyle__ | blackburn: I might for my own use (more of a ruby fellow myself, but py is good). | 00:21 |
blackburn | kyle__: ruby as well | 00:21 |
blackburn | kyle__: static is pretty ugly to use with all these commands | 00:22 |
blackburn | but it is kind of legacy | 00:22 |
kyle__ | blackburn: if I use the module I don't have to do the sg('set_kernel' | 00:22 |
blackburn | no, just objects | 00:22 |
kyle__ | sg('init... blah blah blah blah? | 00:22 |
kyle__ | OMFG. I'm rebuilding now. | 00:22 |
blackburn | http://shogun-toolbox.org/doc/en/current/ruby_modular_examples.html like that | 00:22 |
blackburn | kyle__: something like kernel = GaussianKernel() and so on | 00:23 |
kyle__ | That's georgous. | 00:23 |
kyle__ | (compared to the little octave script I've got going on it now) | 00:23 |
blackburn | probably we should strong that modular is better than static somewhere | 00:24 |
blackburn | :) | 00:24 |
kyle__ | Yea. | 00:27 |
kyle__ | thanks, I'm off | 01:01 |
-!- kyle__ [~kyle@173-165-60-19-Illinois.hfc.comcastbusiness.net] has left #shogun [] | 01:01 | |
shogun-buildbot_ | build #52 of nightly_default is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/52 | 03:42 |
-!- blackburn [~blackburn@109.226.80.43] has quit [Quit: Leaving.] | 03:50 | |
-!- av3ngr [av3ngr@nat/redhat/x-lfobrminomteysop] has joined #shogun | 04:26 | |
-!- av3ngr [av3ngr@nat/redhat/x-lfobrminomteysop] has quit [Quit: That's all folks!] | 05:04 | |
-!- uricamic [~uricamic@2001:718:2:1634:6597:d9ab:da69:d0d7] has joined #shogun | 07:36 | |
-!- n4nd0 [~nando@92.Red-2-137-9.dynamicIP.rima-tde.net] has joined #shogun | 08:44 | |
-!- Netsplit *.net <-> *.split quits: shogun-buildbot_, octopine | 09:43 | |
-!- K0stIa [~kostia@2001:718:2:1634:4a5b:39ff:fe99:cc49] has joined #shogun | 10:06 | |
-!- Netsplit over, joins: shogun-buildbot_, octopine | 10:11 | |
-!- alexlovesdata [~binder@goldenezahl.ml.tu-berlin.de] has joined #shogun | 10:30 | |
@sonney2k | yay! blackburn, broke the build again! | 11:23 |
-!- K0stIa [~kostia@2001:718:2:1634:4a5b:39ff:fe99:cc49] has left #shogun [] | 11:43 | |
n4nd0 | uricamic: around? | 12:40 |
-!- blackburn [~blackburn@109.226.80.43] has joined #shogun | 12:44 | |
alexlovesdata | n4nd0: you called the wrong ghost and got blackburn | 12:47 |
blackburn | sonney2k: I know I did | 12:48 |
blackburn | :) | 12:48 |
uricamic | n4nd0: yep | 12:49 |
n4nd0 | uricamic: I wanted to ask you a couple of details about using your bundle methods with the HM-SVM model | 12:57 |
uricamic | n4nd0: sure | 12:57 |
n4nd0 | so | 12:57 |
n4nd0 | I need to do a risk function right? | 12:57 |
uricamic | I think for that you will need the new version of risk function, which supports user data | 12:57 |
uricamic | yep | 12:58 |
n4nd0 | do you know something about the risk function for the hm-svm? | 12:58 |
uricamic | I am now finishing the last algorithm, got some compile problems, but when I will resolve them, I can submit PR just with the support for new risk functions | 12:58 |
n4nd0 | ok | 12:59 |
uricamic | nothing particular, but I guess you just need to do dynamic programming in the risk function | 12:59 |
uricamic | but definitely you will need the user data in the risk function | 12:59 |
n4nd0 | what do you mean with user data? | 13:00 |
n4nd0 | I understand that I need to provide that function | 13:00 |
uricamic | in the current version there are just features and labels, but you need something more probably, no? | 13:00 |
n4nd0 | well you need an structured model too | 13:00 |
uricamic | yep, you need to create that function, but in the recently merged version, there is just a structure for data, that you want to pass to a risk function and in that structure there is just a pointer to features and labels, nothing more | 13:01 |
uricamic | in the new version, there is a class CRIskData from which u can inherit new one, like CHMRiskData and provide all things u will need inside that risk function | 13:02 |
n4nd0 | the structured model is not just a function, it is a class | 13:02 |
uricamic | so, for example it will be sufficient for u, to just provide the pointer to the model class | 13:03 |
uricamic | or maybe u will need something more, but when u will do this in the upcoming version, it will be simply implementable | 13:03 |
n4nd0 | aham ok | 13:04 |
n4nd0 | I thought that the risk function was going to be a part of the structured model too | 13:04 |
n4nd0 | as the argmax, or the loss function | 13:04 |
n4nd0 | apart from that | 13:05 |
n4nd0 | uricamic: what are the changes I should expect using the bundle methods wrt the cutting plane algorithm I am using right now? | 13:06 |
uricamic | n4nd0: it could be, now it is standalone, it is hard to say, if it would be better to have it as a part of structured model | 13:07 |
n4nd0 | I guess that the bundle methods are faster | 13:07 |
n4nd0 | what about prediction results? | 13:07 |
uricamic | basically the risk function is calling argmax on the features with loss function applied, to find the most violated constrain | 13:08 |
uricamic | what u mean by prediction results? | 13:08 |
n4nd0 | let's say I train an HM-SVM using the PrimalMosekSOSVM | 13:08 |
n4nd0 | it takes 10 minutes to train | 13:08 |
n4nd0 | 90% accuracy in train data and 80% in test data | 13:09 |
n4nd0 | just to put some numbers | 13:09 |
uricamic | ok | 13:09 |
n4nd0 | what should I expect using a bundle methods? | 13:09 |
uricamic | well, depends on how fast the risk function implementation will be, I guess | 13:09 |
n4nd0 | and about accuracy? | 13:10 |
uricamic | with BMRM u can setup desired precision (gap between primal and dual solution) and the Proximal-Point BMRM is faster then the standard BMRM (even faster with some initial weight vector W) | 13:11 |
uricamic | it depends on the data, of course, but if it is possible, u can end up with 100% accuracy on train data | 13:11 |
n4nd0 | uricamic: ok, thank you | 13:12 |
n4nd0 | gtg now, bye! | 13:12 |
uricamic | the new algorithm in BMRM area basically just reduces the number of iterations needed to converge to epsilon solution, and usually the risk computation is the bottleneck of iterations | 13:13 |
uricamic | n4nd0: you are welcome | 13:13 |
-!- n4nd0 [~nando@92.Red-2-137-9.dynamicIP.rima-tde.net] has quit [Quit: leaving] | 13:13 | |
CIA-18 | shogun: Sergey Lisitsyn master * r3af3329 / (4 files in 2 dirs): Fixes for slep based multitask - https://github.com/shogun-toolbox/shogun/commit/3af3329a6e73f030fbd0465e87c5a4c028508e74 | 13:26 |
shogun-buildbot_ | build #162 of bsd1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/162 | 13:36 |
-!- blackburn [~blackburn@109.226.80.43] has quit [Quit: Leaving.] | 13:55 | |
shogun-buildbot_ | build #266 of deb3 - modular_interfaces is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/266 | 14:01 |
shogun-buildbot_ | build #221 of deb2 - static_interfaces is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb2%20-%20static_interfaces/builds/221 | 14:07 |
-!- pluskid [~pluskid@111.120.20.27] has joined #shogun | 15:01 | |
-!- n4nd0 [~nando@92.Red-2-137-9.dynamicIP.rima-tde.net] has joined #shogun | 15:06 | |
-!- pluskid [~pluskid@111.120.20.27] has quit [Ping timeout: 252 seconds] | 15:47 | |
-!- pluskid [~pluskid@66.85.151.216] has joined #shogun | 15:48 | |
-!- gsomix [~gsomix@80.234.30.75] has joined #shogun | 16:07 | |
-!- yoo [2eda6d52@gateway/web/freenode/ip.46.218.109.82] has joined #shogun | 16:49 | |
-!- yoo [2eda6d52@gateway/web/freenode/ip.46.218.109.82] has quit [Client Quit] | 16:50 | |
-!- pluskid [~pluskid@66.85.151.216] has quit [Quit: Leaving] | 17:36 | |
-!- uricamic [~uricamic@2001:718:2:1634:6597:d9ab:da69:d0d7] has quit [Quit: Leaving.] | 17:39 | |
-!- n4nd0 [~nando@92.Red-2-137-9.dynamicIP.rima-tde.net] has quit [Quit: leaving] | 17:58 | |
CIA-18 | shogun: Heiko Strathmann master * r646d8d8 / (12 files in 4 dirs): Merge pull request #690 from karlnapf/master (+10 more commits...) - https://github.com/shogun-toolbox/shogun/commit/646d8d8d50f75205e1b8810691563c2c55838c08 | 18:14 |
-!- heiko [~heiko@host86-178-85-194.range86-178.btcentralplus.com] has joined #shogun | 18:14 | |
-!- alexlovesdata [~binder@goldenezahl.ml.tu-berlin.de] has left #shogun [] | 18:38 | |
-!- blackburn [~blackburn@109.226.80.43] has joined #shogun | 18:42 | |
CIA-18 | shogun: Soeren Sonnenburg master * rd5bbf37 / (18 files in 9 dirs): Merge pull request #679 from pluskid/multiclass (+41 more commits...) - https://github.com/shogun-toolbox/shogun/commit/d5bbf37e16fa71a68ea3e517dc2291878a63e9b8 | 19:19 |
@sonney2k | gsomix, are you alive? | 19:21 |
gsomix | sonney2k, yep. | 19:21 |
gsomix | I have problem in Labels. | 19:25 |
gsomix | There is same problem in SGVector. | 19:25 |
gsomix | valgrind doesn't help me... | 19:26 |
@sonney2k | gsomix, how is that different to what you have done with dense features? | 19:26 |
@sonney2k | I mean SGVector / SGMatrix don't really differ | 19:26 |
gsomix | sonney2k, in DenseFeatures I use get_feature_matrix. in labels - get_labels().vector. that's all. | 19:28 |
gsomix | I'm stuck on this. | 19:29 |
@sonney2k | gsomix, but densefeatures returns just SGMatrix: SGMatrix<ST> get_feature_matrix(); | 19:30 |
gsomix | nope, there is ST* CDenseFeatures<ST>::get_feature_matrix | 19:31 |
@sonney2k | gsomix, you shouldn't use that | 19:31 |
gsomix | why? | 19:31 |
gsomix | and what about ref count? | 19:32 |
@sonney2k | it will just give you the SGMatrix.matrix | 19:32 |
blackburn | sonney2k: any idea how to do the ref increase trick? | 19:45 |
shogun-buildbot_ | build #268 of deb3 - modular_interfaces is complete: Failure [failed test ruby_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/268 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 19:48 |
CIA-18 | shogun: Heiko Strathmann master * r2a05bce / src/shogun/statistics/QuadraticTimeMMD.h : doc update - https://github.com/shogun-toolbox/shogun/commit/2a05bce78de42bfe8feaa1ec6c4978a17015973a | 19:48 |
CIA-18 | shogun: Heiko Strathmann master * r7d70763 / src/shogun/statistics/LinearTimeMMD.h : doc update - https://github.com/shogun-toolbox/shogun/commit/7d7076350f0e9580a08dfa9e575fbbd1738e7131 | 19:48 |
CIA-18 | shogun: Heiko Strathmann master * r946feed / (5 files): -added documentation - https://github.com/shogun-toolbox/shogun/commit/946feedfed242c92a6b11a6b6e8f88816c9c0c1e | 19:48 |
CIA-18 | shogun: Heiko Strathmann master * ra345a5d / (7 files): Merge pull request #691 from karlnapf/master - https://github.com/shogun-toolbox/shogun/commit/a345a5d4c6aa92156140c02d21f8621427c72aa1 | 19:48 |
shogun-buildbot_ | build #165 of bsd1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/165 blamelist: Chiyuan Zhang <pluskid@gmail.com> | 19:52 |
blackburn | haha | 19:52 |
blackburn | okay | 19:53 |
shogun-buildbot_ | build #166 of bsd1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/166 | 19:55 |
shogun-buildbot_ | build #173 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/173 blamelist: Chiyuan Zhang <pluskid@gmail.com> | 20:04 |
shogun-buildbot_ | build #269 of deb3 - modular_interfaces is complete: Failure [failed compile java_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/269 blamelist: Soeren Sonnenburg <sonne@debian.org>, Chiyuan Zhang <pluskid@gmail.com> | 20:09 |
-!- heiko [~heiko@host86-178-85-194.range86-178.btcentralplus.com] has left #shogun [] | 20:18 | |
shogun-buildbot_ | build #174 of cyg1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/174 | 20:19 |
shogun-buildbot_ | build #270 of deb3 - modular_interfaces is complete: Failure [failed compile python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/270 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 20:20 |
CIA-18 | shogun: Sergey Lisitsyn master * r71a7c9c / src/shogun/evaluation/CrossValidation.h : Added get mean to CVResult - https://github.com/shogun-toolbox/shogun/commit/71a7c9ce9b040e2280aa884233ffe6891c5350da | 20:23 |
-!- n4nd0 [~nando@92.Red-2-137-9.dynamicIP.rima-tde.net] has joined #shogun | 20:28 | |
-!- n4nd0 [~nando@92.Red-2-137-9.dynamicIP.rima-tde.net] has quit [Client Quit] | 20:32 | |
shogun-buildbot_ | build #271 of deb3 - modular_interfaces is complete: Failure [failed compile python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/271 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 20:34 |
-!- zxtx [~zv@c-71-227-187-90.hsd1.wa.comcast.net] has joined #shogun | 20:35 | |
-!- gsomix_ [~gsomix@178.45.40.178] has joined #shogun | 21:15 | |
-!- gsomix [~gsomix@80.234.30.75] has quit [Ping timeout: 265 seconds] | 21:18 | |
-!- ckwidmer [8ca3fe9d@gateway/web/freenode/ip.140.163.254.157] has joined #shogun | 21:47 | |
gsomix_ | sonney2k, it seems I have find solution. ?) | 22:09 |
gsomix_ | *have found | 22:10 |
gsomix_ | good night guys | 22:10 |
blackburn | sonney2k: have you heard just anything about so called 'pussy riot' thing? | 22:20 |
blackburn | some guys state everybody in germany knows :) | 22:21 |
-!- n4nd0 [~nando@92.Red-2-137-9.dynamicIP.rima-tde.net] has joined #shogun | 22:30 | |
n4nd0 | blackburn: hey | 22:31 |
blackburn | hey there | 22:31 |
n4nd0 | let me ask you something | 22:31 |
n4nd0 | why in SGVector we have two operators [] | 22:31 |
n4nd0 | one that returns a const T& | 22:31 |
n4nd0 | and another T& | 22:31 |
n4nd0 | it says that one is for read only access | 22:31 |
blackburn | that's kinda convention - you const is called when you do only read | 22:31 |
n4nd0 | and the other for read and write | 22:31 |
n4nd0 | but I don't really get how that works | 22:32 |
blackburn | hmm | 22:32 |
blackburn | a[3] = 4.0; | 22:32 |
blackburn | is non const | 22:32 |
blackburn | b = a[5]; | 22:32 |
blackburn | is const | 22:32 |
n4nd0 | I thought that one cannot defined two methods that are just different on the return type | 22:32 |
n4nd0 | why not use the non const always? it works for both cases | 22:33 |
n4nd0 | I am just wondering ... :) | 22:33 |
blackburn | n4nd0: I am unsure about that | 22:35 |
n4nd0 | blackburn: ok, it is not really relevant though, I think | 22:35 |
n4nd0 | mainly curiosity | 22:35 |
blackburn | n4nd0: actually I think it helps with optimizations | 22:36 |
n4nd0 | that's the only raeson I came up with | 22:37 |
n4nd0 | blackburn: that maybe the const case can be done faster than the non-cost or so | 22:37 |
blackburn | n4nd0: a[i] + b[j] could be done faster if you assume it is const | 22:38 |
blackburn | I think so :D | 22:39 |
n4nd0 | ok | 22:40 |
blackburn | n4nd0: or not, I don't know | 22:40 |
blackburn | n4nd0: anyway consts are helpful sometimes for optimizer | 22:41 |
n4nd0 | ok | 22:42 |
n4nd0 | sonney2k: around? | 23:28 |
@sonney2k | n4nd0, yes? | 23:42 |
@sonney2k | blackburn, I think we can drop the const one | 23:42 |
blackburn | sonney2k: are you sure it is useless? | 23:42 |
@sonney2k | if we don't want to do extra stuff in that case | 23:42 |
@sonney2k | blackburn, yes const is totally useless | 23:43 |
blackburn | sonney2k: I think it is ok to have it there | 23:43 |
@sonney2k | except for telling us that we should not modify the element | 23:43 |
blackburn | sonney2k: there is an matlab issue in the mailing list I am afraid I can't afford to resolve | 23:44 |
-!- n4nd0 [~nando@92.Red-2-137-9.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 23:45 | |
@sonney2k | blackburn, do you have an idea what issue gsomix_ is having? | 23:46 |
blackburn | sonney2k: he sleeps already btw | 23:46 |
blackburn | yes but probably he found the way already | 23:46 |
blackburn | sonney2k: first he was messing with get_labels and get_feature_matrix stuff | 23:46 |
blackburn | I suggested to increase ref counter with a trick but we actually have to decrease it too | 23:47 |
@sonney2k | blackburn, in sgvector you mean? | 23:47 |
blackburn | yeah | 23:47 |
@sonney2k | why do you have to increase / decrease it manually? | 23:47 |
blackburn | sonney2k: if I understand correctly we need to steal a pointer | 23:48 |
blackburn | and to store it in the pyobject | 23:48 |
* sonney2k *argh* heiko again managed to screw up the build by inserting a zero length unicode space! | 23:48 | |
-!- n4nd0 [~nando@119.Red-2-137-47.dynamicIP.rima-tde.net] has joined #shogun | 23:48 | |
n4nd0 | I hate the internet connection here ... | 23:49 |
n4nd0 | sonney2k: did my messages before arrived? | 23:49 |
n4nd0 | arrive* | 23:49 |
@sonney2k | and I totally forgot how I fixed it last time | 23:49 |
@sonney2k | n4nd0, no | 23:49 |
blackburn | sonney2k: lol | 23:50 |
n4nd0 | shit | 23:50 |
n4nd0 | I have got to work the HM-SVM + PLiFs | 23:51 |
n4nd0 | but I still keep the implementation I did at the beginning, the one that just works for discrete observations | 23:51 |
@sonney2k | n4nd0, yes makes sense | 23:51 |
n4nd0 | the user could choose between those using a boolean member (use_plifs) | 23:51 |
n4nd0 | sonney2k: so, does it make sense to keep it? | 23:52 |
@sonney2k | or even some other way where you have a HM SVM w/o and with plifs | 23:52 |
@sonney2k | n4nd0, yes sure! | 23:52 |
n4nd0 | ok | 23:52 |
n4nd0 | since the PLiFs work for both discrete and real data, I doubted it | 23:52 |
@sonney2k | n4nd0, well you could argue that your plif has just 1 support point and then it would be equal to what you have | 23:53 |
n4nd0 | mmm I don't understand what you mean | 23:54 |
n4nd0 | I know that using PLiFs with integer data, if the supporting points coincide with the possible values of the observations | 23:55 |
CIA-18 | shogun: Sergey Lisitsyn master * r91bbe7e / src/shogun/lib/slep/slep_solver.cpp : Restored mystery objective calculation code in slep - https://github.com/shogun-toolbox/shogun/commit/91bbe7e71d7b1f81a6feec0dd9952c40656a35fc | 23:55 |
n4nd0 | then it is the same to use the PLiFs or not | 23:56 |
n4nd0 | sonney2k: did you mean that? | 23:56 |
n4nd0 | anyhow, time to sleep now | 23:57 |
@sonney2k | n4nd0, hmmhh maybe it is not even possible to get this to be equivalent | 23:57 |
n4nd0 | good night guys! | 23:57 |
@sonney2k | because plif weights are learned | 23:57 |
n4nd0 | yes | 23:58 |
@sonney2k | it could turn any integer to be 'muted' | 23:58 |
n4nd0 | mmm what I meant is | 23:58 |
@sonney2k | so I meant if you had just one support point | 23:58 |
n4nd0 | tell me | 23:58 |
@sonney2k | that this then is just a factor in front of the integers | 23:58 |
@sonney2k | but then it can still rescale all of them in that state | 23:58 |
n4nd0 | ahm ok | 23:59 |
@sonney2k | maybe it is the same in the discrete HM-SVM and the plif-hm-svm (that will learn a weight for that and the plif) | 23:59 |
@sonney2k | but I don't know for sure | 23:59 |
--- Log closed Wed Aug 08 00:00:10 2012 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!