--- Log opened Wed Apr 03 00:00:18 2013 | ||
-!- FSCV [~FSCV@187.210.54.166] has quit [Read error: No route to host] | 00:13 | |
-!- FSCV [~FSCV@187.210.54.166] has joined #shogun | 00:15 | |
-!- FSCV [~FSCV@187.210.54.166] has quit [Quit: Leaving] | 00:23 | |
-!- heiko [~heiko@027fc803.bb.sky.com] has quit [Quit: Leaving.] | 01:04 | |
-!- heiko [~heiko@027fc803.bb.sky.com] has joined #shogun | 01:09 | |
-!- heiko [~heiko@027fc803.bb.sky.com] has quit [Client Quit] | 01:10 | |
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 01:23 | |
-!- hoijui [~hoijui@dslb-088-075-046-171.pools.arcor-ip.net] has joined #shogun | 01:53 | |
-!- hoijui [~hoijui@dslb-088-075-046-171.pools.arcor-ip.net] has quit [Client Quit] | 01:57 | |
shogun-buildbot_ | build #342 of nightly_default is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/342 | 04:20 |
---|---|---|
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 06:10 | |
shogun-notifier- | shogun: Soeren Sonnenburg :master * 7d9539b / tests/integration/python_static/test_all.sh,tests/integration/blacklist: https://github.com/shogun-toolbox/shogun/commit/7d9539bb89c83ead12e7455601da71d74536876d | 06:10 |
shogun-notifier- | shogun: disable broken HMM in tests for now | 06:10 |
shogun-buildbot_ | build #856 of deb2 - static_interfaces is complete: Failure [failed test python_static] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb2%20-%20static_interfaces/builds/856 blamelist: Soeren Sonnenburg <sonne@debian.org> | 06:24 |
shogun-buildbot_ | build #982 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/982 blamelist: Soeren Sonnenburg <sonne@debian.org> | 07:00 |
shogun-notifier- | shogun: Soeren Sonnenburg :master * 2c1d6f0 / tests/integration/blacklist: https://github.com/shogun-toolbox/shogun/commit/2c1d6f022c8c1216bbb724df91ffa038e5073780 | 08:21 |
shogun-notifier- | shogun: really blacklist HMM | 08:21 |
blackburn | sonney2k: I don't remember, I have a feeling it is broken since 1.0 | 08:26 |
shogun-buildbot_ | build #857 of deb2 - static_interfaces is complete: Failure [failed test octave_static] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb2%20-%20static_interfaces/builds/857 blamelist: Soeren Sonnenburg <sonne@debian.org> | 08:27 |
@sonney2k | blackburn, I hardly recall but IMHO for 1.0 we fixed all old tests (like we do now?) | 08:28 |
@sonney2k | blackburn, ^ hurray | 08:28 |
@sonney2k | now we are at octave_static! | 08:28 |
blackburn | sonney2k: heh | 08:28 |
@sonney2k | blackburn, actually it is only failing w/ svmsgd and other linear methods that use sparse features | 08:30 |
@sonney2k | b'cause python static doesn't support sparse features! | 08:30 |
@sonney2k | svmsgd & etc seem to be working but infact they just return | 08:30 |
shogun-notifier- | shogun: Soeren Sonnenburg :master * 573b475 / tests/integration/ (4 files): https://github.com/shogun-toolbox/shogun/commit/573b475142a7e8a837eb36c34b9494ed8dc124b8 | 08:37 |
shogun-notifier- | shogun: add blacklist support to all interfaces' integration tests | 08:37 |
@sonney2k | blackburn, so only svmsgd stuff & svmlin stuff are broken | 08:39 |
@sonney2k | and it seems we have a train time limit on this stuff | 08:39 |
@sonney2k | of 0.5 secs... | 08:39 |
@sonney2k | might all be crap... | 08:39 |
@sonney2k | lets better compare directly with svmsgd | 08:39 |
shogun-buildbot_ | build #858 of deb2 - static_interfaces is complete: Failure [failed test octave_static] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb2%20-%20static_interfaces/builds/858 blamelist: Soeren Sonnenburg <sonne@debian.org> | 08:47 |
sonne|work | blackburn: how about we blacklist all the failing stuff and add these as entry tasks? | 08:52 |
blackburn | sonne|work: like HMM? :D | 08:52 |
sonne|work | I mean time is pressing a bit and it is not so difficult to compare the sgd executable directly with what shogun's sgd produces | 08:52 |
sonne|work | ok HMM is something I have to do | 08:52 |
sonne|work | but it is a matter of git bisect | 08:52 |
sonne|work | it worked including tests at some point | 08:53 |
sonne|work | so it not difficult to find out which commit broke things | 08:53 |
shogun-buildbot_ | build #983 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/983 blamelist: Soeren Sonnenburg <sonne@debian.org> | 09:02 |
shogun-notifier- | shogun: Soeren Sonnenburg :master * e43606f / tests/integration/blacklist: https://github.com/shogun-toolbox/shogun/commit/e43606f9efc783cf4728d03ba4241f4224161a35 | 09:02 |
shogun-notifier- | shogun: blacklist failing SGD/SVMLin tests | 09:02 |
shogun-buildbot_ | build #984 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/984 blamelist: Soeren Sonnenburg <sonne@debian.org> | 09:17 |
shogun-buildbot_ | build #859 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/859 | 09:28 |
shogun-notifier- | shogun: Soeren Sonnenburg :master * a1a3884 / tests/integration/blacklist: https://github.com/shogun-toolbox/shogun/commit/a1a388408a0bff950856fa4d582448b79c23b4f3 | 09:37 |
shogun-notifier- | shogun: blacklist Fisher/TOP kernels | 09:37 |
shogun-buildbot_ | build #985 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/985 blamelist: Soeren Sonnenburg <sonne@debian.org> | 09:46 |
shogun-notifier- | shogun: Soeren Sonnenburg :master * 9b34a5a / tests/integration/ (2 files): https://github.com/shogun-toolbox/shogun/commit/9b34a5a16644ddd466d2e41e2d684bcdccbcbaec | 09:55 |
shogun-notifier- | shogun: blacklist support for octave/python_modular integration tests | 09:55 |
blackburn | sonne|work: http://tapkee-bootstrap.herokuapp.com/ bootstrap appears to be easy | 09:55 |
sonne|work | blackburn: bootstrap? | 09:59 |
sonne|work | what do you mean? | 09:59 |
sonne|work | the ML method? | 09:59 |
blackburn | sonne|work: http://twitter.github.com/bootstrap/ | 09:59 |
sonne|work | ok | 10:00 |
sonne|work | it should be :D | 10:00 |
-!- escorciav [ba574947@gateway/web/freenode/ip.186.87.73.71] has joined #shogun | 10:02 | |
-!- escorciav [ba574947@gateway/web/freenode/ip.186.87.73.71] has left #shogun [] | 10:02 | |
-!- sumit [73f91219@gateway/web/freenode/ip.115.249.18.25] has joined #shogun | 10:07 | |
-!- heiko [~heiko@027fc803.bb.sky.com] has joined #shogun | 10:18 | |
shogun-buildbot_ | build #986 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/986 blamelist: Soeren Sonnenburg <sonne@debian.org> | 10:20 |
-!- blackburn [~blackburn@46.20.65.51] has quit [Quit: Leaving.] | 10:22 | |
-!- escorciav [ba574947@gateway/web/freenode/ip.186.87.73.71] has joined #shogun | 10:26 | |
escorciav | Hi, could someone help me with some doubts about latent svm code? | 10:27 |
sonne|work | escorciav: wiking is your man - he wrote that stuff! | 10:34 |
escorciav | Thanks, I'm new with IRC. How can I contact to wiking? | 10:35 |
escorciav | or wiking means that I need to read a Wiki | 10:36 |
escorciav | ??? | 10:36 |
escorciav | I click "query" on wiking user in the right tab, please let me know If I'm using bad the IRC chat | 10:41 |
escorciav | Thanks for your reply @sonne|work | 10:41 |
sonne|work | escorciav: no he would respond if he was available... | 10:42 |
escorciav | I have 3-5 questions, you recommend me to post all my question or wait for wiking request. I'm Sorry, if I'm bother you with my silly complains. | 10:47 |
-!- n4nd0 [~nando@n186-p150.kthopen.kth.se] has joined #shogun | 10:48 | |
sonne|work | escorciav: well post them - if we see wiking around we will make him talk to you or you write him an email (CC'ing the mailinglist) | 10:48 |
sonne|work | n4nd0: gooood morning ! | 10:48 |
n4nd0 | sonne|work: hey! good morning :) | 10:48 |
n4nd0 | I am finally back again! | 10:48 |
sonne|work | no plane crashes or other incidents | 10:49 |
n4nd0 | sonne|work: no, not really | 10:49 |
sonne|work | (except that we still have snow in berlin) | 10:49 |
n4nd0 | haha lot of snow here in Sweden too | 10:49 |
n4nd0 | I found none in Italy though :D | 10:49 |
escorciav | Thanks @sonne|work, I can wait 2-3 hour in IRC. | 10:50 |
n4nd0 | I have seen some commits with fixes for the kernels, the tests are fine now? | 10:50 |
sonne|work | n4nd0: the kernels were actually more or less fine | 10:51 |
sonne|work | n4nd0: what didn't work with oligokernel is that you wrote sth like OligoStringKernel(k=3, width=50) | 10:52 |
sonne|work | and keyword arguments are not supported by seig | 10:52 |
sonne|work | swig | 10:52 |
sonne|work | but somehow it silently ignored this! | 10:52 |
sonne|work | and just used the default constructor | 10:52 |
n4nd0 | ouch, my bad. Sorry about that | 10:52 |
sonne|work | no IMHO this is a bug... | 10:52 |
n4nd0 | I see there is only one HMM test failing now | 10:53 |
n4nd0 | but it seems it is already blacklisted | 10:54 |
shogun-buildbot_ | build #987 of deb3 - modular_interfaces is complete: Failure [failed test octave_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/987 blamelist: Soeren Sonnenburg <sonne@debian.org> | 10:54 |
-!- heiko [~heiko@027fc803.bb.sky.com] has left #shogun [] | 10:55 | |
-!- tom__ [2eda6d58@gateway/web/freenode/ip.46.218.109.88] has joined #shogun | 11:11 | |
tom__ | hi all! | 11:11 |
n4nd0 | hey tom__ | 11:11 |
tom__ | I have a question about CAlphabet::translate_from_single_order method. who'is interested ? :p | 11:12 |
sonne|work | n4nd0: we now only have to fix the octave_modular stuff | 11:13 |
sonne|work | that should be rather easy | 11:13 |
sonne|work | tom__: shoot! | 11:13 |
sonne|work | tom__: I wrote that stuff but a decade back | 11:13 |
-!- tom__ [2eda6d58@gateway/web/freenode/ip.46.218.109.88] has quit [Ping timeout: 245 seconds] | 11:17 | |
-!- sumit [73f91219@gateway/web/freenode/ip.115.249.18.25] has quit [Ping timeout: 245 seconds] | 11:17 | |
n4nd0 | sonne|work: why do this cannot create instance errors appear in octave_modular? | 11:17 |
-!- blackburn [~lisitsin@mxs.kg.ru] has joined #shogun | 11:17 | |
n4nd0 | Some names that have changed in the code and not updated in the tests? | 11:17 |
sonne|work | n4nd0: one needs to check the scripts | 11:18 |
sonne|work | n4nd0: we have an obsolete test suite | 11:18 |
n4nd0 | sonne|work: I am going to build for octave modular and see | 11:18 |
sonne|work | which however is the only way to still do tests for static interfaces | 11:18 |
sonne|work | and interfaces != python_modular | 11:18 |
sonne|work | so when you go to shogun/tests/integration/octave_modular | 11:19 |
sonne|work | you will see some handcrafted .m scripts that run the tests | 11:19 |
sonne|work | these might need an update for all the changes we had with e.g. labels | 11:19 |
sonne|work | $ grep Label *.m | 11:20 |
sonne|work | classifier.m:lab=Labels(classifier_labels); | 11:20 |
sonne|work | regression.m:lab=Labels(regression_labels); | 11:20 |
sonne|work | no wonder... | 11:20 |
n4nd0 | ok | 11:21 |
sonne|work | n4nd0: would be cool if you have time to fix this | 11:29 |
sonne|work | the tests should work then | 11:29 |
n4nd0 | sonne|work: yes, let me take a look. I am building atm. | 11:29 |
sonne|work | ok | 11:29 |
sonne|work | good thing is that you don't have to recompile you only need to change these scripts | 11:29 |
sonne|work | recompile again I mean | 11:30 |
n4nd0 | it will be faster then | 11:30 |
blackburn | escorciav: may be n4nd0 and I can help you somehow? | 11:34 |
blackburn | sonne|work: n4nd0: have any of you tried -Og in gcc 4.8.0? | 11:35 |
n4nd0 | blackburn: mm no, let me check. Another level of optimization? | 11:35 |
blackburn | n4nd0: yes debug - no optimization at all | 11:36 |
blackburn | should be fast | 11:36 |
blackburn | but probably just as fast as clang :D | 11:36 |
blackburn | monster gcc is damn slow | 11:36 |
blackburn | sonney2k: I was thinking about swig problems and etc | 11:36 |
n4nd0 | hehe, the idea sounds nice in any case | 11:36 |
blackburn | I consider one anti-pattern as a solution actually | 11:37 |
blackburn | it is called 'string typization' you know | 11:37 |
-!- escorciav [ba574947@gateway/web/freenode/ip.186.87.73.71] has left #shogun [] | 11:37 | |
blackburn | get("width") | 11:37 |
sonne|work | haha | 11:37 |
sonne|work | you are arriving at the static interfaces :) | 11:37 |
blackburn | sonne|work: no | 11:37 |
blackburn | sonne|work: let me explain | 11:38 |
blackburn | remember that idea I hade | 11:38 |
blackburn | had* | 11:38 |
blackburn | svm.parameter("width") | 11:38 |
blackburn | etc | 11:38 |
blackburn | and actually we *already* use it in modelselection | 11:38 |
blackburn | the only problem is that it won't work as I just realized :D | 11:38 |
blackburn | setters could work but not the getters | 11:39 |
-!- escorciav [ba574947@gateway/web/freenode/ip.186.87.73.71] has joined #shogun | 11:39 | |
-!- escorciav [ba574947@gateway/web/freenode/ip.186.87.73.71] has left #shogun [] | 11:39 | |
sonne|work | blackburn: they could too if you pass stuff by reference | 11:39 |
blackburn | what is declaration of such get? | 11:39 |
blackburn | ???& get(string name) | 11:39 |
sonne|work | void getFoo(string name, type& value) | 11:40 |
blackburn | how would it look like in python? | 11:40 |
sonne|work | getFoo("width") | 11:40 |
blackburn | and it would return type? | 11:40 |
sonne|work | type | 11:41 |
sonne|work | yes | 11:41 |
blackburn | how does it dispatch the type? | 11:41 |
blackburn | but it won't work for java | 11:42 |
sonne|work | actually it doesn't help at all | 11:43 |
blackburn | sonne|work: I hate writing getters | 11:43 |
blackburn | :D | 11:43 |
sonne|work | for getFoo(string name, type& value) to be wrapped the function with the type needs to be declared | 11:43 |
-!- lambday [0e8b614f@gateway/web/freenode/ip.14.139.97.79] has joined #shogun | 11:45 | |
blackburn | sonne|work: I have an idea how would it look like in C++ but not in other interfaces | 11:45 |
blackburn | sonne|work: I'd like to review the API for shogun 3.0 | 11:51 |
blackburn | some ideas haunt me and I just have to realize them | 11:52 |
blackburn | sonne|work: just like any other software initial API can appear bad but later you realize how to do that properly - I think that's time | 11:53 |
sonne|work | I don't mind - git has branches you know :D | 11:54 |
blackburn | sonne|work: reviewing API means discussion of API | 11:55 |
sonne|work | so think of sth and then we can discuss | 11:55 |
sonne|work | I don't currently know how to do it 'better' | 11:56 |
blackburn | sonne|work: first is modelselection | 11:56 |
sonne|work | agreed | 11:56 |
sonne|work | but I think we were all happy with what you proposed | 11:56 |
blackburn | sonne|work: then we have to think about preprocessor chains | 11:56 |
blackburn | all that append_preprocessor etc should be reviewed | 11:57 |
blackburn | it should look easier | 11:57 |
blackburn | next is unite label+features | 11:57 |
sonne|work | blackburn: but label & features -> unsupervised doesn't make sense | 11:59 |
sonne|work | blackburn: better do the same with combined kernels/ features we do for preprocessors | 11:59 |
blackburn | sonne|work: labels are optional | 11:59 |
-!- heiko [~heiko@nat-180-85.internal.eduroam.ucl.ac.uk] has joined #shogun | 12:16 | |
blackburn | sonne|work: http://divshot.github.com/geo-bootstrap/#forms | 12:21 |
n4nd0 | no idea what is going on with my compiler, I have tried three times to build shogun with octave-modular | 12:29 |
n4nd0 | c++: internal compiler error: Killed (program cc1plus) | 12:29 |
n4nd0 | Please submit a full bug report, | 12:29 |
n4nd0 | with preprocessed source if appropriate. | 12:29 |
blackburn | n4nd0: you met out of memory probably | 12:34 |
n4nd0 | but the memory tracer didn't show that | 12:35 |
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 12:55 | |
n4nd0 | I cannot believe it, I just can't build with octave_modular it seems | 12:56 |
-!- blackburn [~lisitsin@mxs.kg.ru] has quit [Quit: Leaving.] | 13:26 | |
-!- blackburn [~lisitsin@mxs.kg.ru] has joined #shogun | 13:32 | |
-!- heiko [~heiko@nat-180-85.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.] | 13:38 | |
-!- heiko [~heiko@nat-180-85.internal.eduroam.ucl.ac.uk] has joined #shogun | 13:40 | |
sonne|work | n4nd0: try to compile with --disable-optimization | 13:42 |
heiko | sonne|work, blackburn any comments on the nu-svr extension in the PR? | 13:42 |
sonne|work | nu svr is kind of useless IMHO | 13:43 |
sonne|work | IIRC it was much slower doing the optimization | 13:43 |
sonne|work | because it started with non-zero alphas | 13:43 |
sonne|work | but I might err... | 13:43 |
heiko | sonne|work: it is slower | 13:43 |
heiko | noticed that | 13:43 |
heiko | but people may want to have it anyway, like the guy on the mailing list? | 13:44 |
heiko | so why not offer both? we do that for SVC also | 13:44 |
sonne|work | heiko: if it doesn't break any of our tests why not | 13:44 |
sonne|work | btw, why do you have C end nu in your example? | 13:44 |
n4nd0 | sonne|work: I was compiling with disable-optimization already. It seems my system is not using swap memory although I think I did a partition for that. I have to check how to fix this. | 13:44 |
heiko | sonne|work: it doesnt, is there anything else I need to do except for passing this through to the LibSVR | 13:45 |
sonne|work | n4nd0: how much memory do you have? for octave modular you will need 3-4GB | 13:45 |
n4nd0 | 4GB | 13:45 |
sonne|work | n4nd0: then close all applications! | 13:45 |
sonne|work | and compile again | 13:46 |
n4nd0 | I had just this terminal running irssi and a couple of tabs in the browser | 13:46 |
n4nd0 | I think I should better take a look and make use of the swap | 13:46 |
-!- sumit [73f91219@gateway/web/freenode/ip.115.249.18.25] has joined #shogun | 13:47 | |
sonne|work | heiko: I don't understand? why should libsvm need a C if you have a nu? | 13:47 |
sonne|work | IIRC you need some size of the epsilon tube and the nu | 13:47 |
sonne|work | err no the tube got estimated too | 13:48 |
sonne|work | so just nu right? | 13:48 |
sonne|work | n4nd0: btw please twitter that we applied at GSoC | 13:49 |
sonne|work | n4nd0: octave modular compiles on our buildbot (also only 4GB memory) | 13:49 |
sonne|work | so it should work just fine | 13:49 |
n4nd0 | I guess the OS needs also some memory | 13:50 |
n4nd0 | the buildbot probably doesn't have a graphical OS while I am running one | 13:50 |
n4nd0 | it could make sense | 13:50 |
-!- sumit_ [73f91219@gateway/web/freenode/ip.115.249.18.25] has joined #shogun | 13:50 | |
heiko | sonne|work: nu replaces the epsilon in svr | 13:51 |
heiko | but there remains a C in the opt. problem | 13:51 |
heiko | if I remember correctly | 13:51 |
-!- sumit [73f91219@gateway/web/freenode/ip.115.249.18.25] has quit [Ping timeout: 245 seconds] | 13:53 | |
sonne|work | no it replaces C & epsilon | 13:53 |
heiko | sonne|work: oh, I better do some reading then :) | 13:55 |
sonne|work | I am not sure either | 13:55 |
sonne|work | for sure nu-svm no C | 13:56 |
heiko | sonne|work: I thinnk the C remais | 13:56 |
heiko | svr is different | 13:56 |
heiko | in svc I agree | 13:56 |
sonne|work | ahh ok so the nu just controls percentage of errors then | 13:56 |
heiko | sonne|work, yes | 13:57 |
heiko | Training ?-Support Vector Regression: Theory and Algorithms | 13:57 |
heiko | contains a comparison | 13:57 |
blackburn | heiko: I am not sure what to comment :) | 13:57 |
sonne|work | so it has some mapping to epsilon | 13:57 |
heiko | blackburn: I did not build the libsvm wrapper so I wasnt sure whether its just enough to pass the different solver type to libsvm | 13:58 |
heiko | sonne|work, blackburn, ok will merge then ... | 13:58 |
sonne|work | ok then | 13:58 |
sonne|work | heiko: well if you compare with libsvm's nu-svr and results are the same then why not | 13:59 |
n4nd0 | sonne|work, heiko, blackburn : retweet guys | 13:59 |
heiko | sonne|work, compare? I am using libsvr | 13:59 |
heiko | you mean calling it directly? | 13:59 |
-!- ZeThomas [~thomaspr@2a02:2c40:100:a000:1c78:deb5:6522:b5ca] has joined #shogun | 14:00 | |
heiko | yes, I planned to do this, also for libsvr itself, so that we have a unit test that checks the output for a simple case | 14:00 |
blackburn | n4nd0: may be tweet it from ShogunToolbox? | 14:00 |
n4nd0 | mm, that would require me to remember the pass :D | 14:01 |
n4nd0 | found it | 14:01 |
ZeThomas | hey blackburn, I'm still struggling with the implementation of my own kernel | 14:02 |
blackburn | ZeThomas: hey | 14:02 |
blackburn | ask me | 14:02 |
sonne|work | ZeThomas: or read the excellent tutorial ;) | 14:02 |
ZeThomas | I recompiled with the appropriate flags set, and I think I kind of got it figured out | 14:02 |
ZeThomas | sonne|work, where's this tutorial? | 14:03 |
sonne|work | http://www.shogun-toolbox.org/doc/en/current/developer_tutorial.html | 14:03 |
sonne|work | how to implement your own kernel | 14:03 |
blackburn | sonne|work: no, directors | 14:03 |
sonne|work | ReverseLinearKernel | 14:03 |
blackburn | ZeThomas: that's for shogun internal C++ stuff | 14:03 |
n4nd0 | tweet done | 14:03 |
sonne|work | directors ahh | 14:03 |
ZeThomas | ah ok, I got already scared by the amount of C on that page :) | 14:04 |
blackburn | ZeThomas: yeah that was the naming in 1976 | 14:04 |
blackburn | ZeThomas: ah btw I forgot to ask you - is your dataset big? | 14:04 |
ZeThomas | not yet, but I can be | 14:05 |
blackburn | if your kernel takes significant time and kernel matrix can fit into the memory it is better to use CustomKernel still | 14:05 |
blackburn | but if you have >10000 training vectors directors is the only way I see | 14:06 |
ZeThomas | blackburn: oh, so for small datasets CustomKernel is better? | 14:06 |
blackburn | ZeThomas: yeah sorry I didn't mention that | 14:07 |
ZeThomas | blackburn: np, but I can still implement it through DirectorKernel right, for scaleability | 14:08 |
blackburn | ZeThomas: yes | 14:08 |
blackburn | ZeThomas: so have you got any problems with implementing it? | 14:08 |
ZeThomas | ok, so this is my basic set-up, don't know if it's any good: http://pastebin.com/P4771fNP | 14:08 |
blackburn | ZeThomas: looks legit | 14:10 |
ZeThomas | so I then do kernel.init(trainset, trainset); svm = SVMLight(C, kernel, labels); svm.train() | 14:10 |
ZeThomas | this works | 14:10 |
ZeThomas | but if after, I do kernel.set_rhs(testset); rhs = kernel.get_rhs(); svm.apply(rhs) | 14:11 |
blackburn | ohh | 14:11 |
blackburn | no need to do apply(rhs) | 14:12 |
blackburn | I think that's enough to just svm.apply() | 14:12 |
ZeThomas | ok, because this throws an error: terminate called after throwing an instance of 'Swig::DirectorMethodException' | 14:12 |
lambday | heiko: hi | 14:13 |
heiko | lambday: hi! | 14:13 |
blackburn | ZeThomas: yeah that should not happen but directors are so experimental | 14:13 |
ZeThomas | oh ok, it works with apply() | 14:14 |
lambday | heiko: I modified the code as blackburn suggested and committed.. could you please have a look? | 14:14 |
lambday | it works both for new and older eigen | 14:14 |
ZeThomas | blackburn: cool, thanks a lot for the help! | 14:14 |
heiko | lambday: sure | 14:14 |
blackburn | ZeThomas: you are welcome | 14:14 |
ZeThomas | blackburn: btw is there a huge performance increase when using CustomKernel for smaller datasets? | 14:15 |
lambday | heiko: for older eigen, I used SparseLLT, which does not use permutation and is a lot slower.. | 14:15 |
heiko | lambday: okay, mmh | 14:15 |
blackburn | ZeThomas: yeah it may be significant if your kernel is slow | 14:16 |
heiko | so can one do the permutation by hand in this case? | 14:16 |
lambday | but if its >= 3.1.0, it uses simplicialLLT which performs amd | 14:16 |
lambday | and a lot faster | 14:16 |
lambday | heiko: that I haven't tried | 14:16 |
heiko | lambday: thats good! | 14:16 |
ZeThomas | blackburn: so I should consider implementing it through that right now? train data is at a measly 1000 max | 14:17 |
heiko | lambday: the whole point is to do the permutation, if this is not done, there is no way of computing the logdet for large matrices | 14:17 |
blackburn | ZeThomas: oh then I'd rather precompute everything | 14:17 |
lambday | heiko: for the unit test, I used a 1000x1000 sparse matrix, using simplicialLLT, it takes 112 ms in my machine, but using SparseLLT it takes around 7400 ms | 14:17 |
heiko | lambday: is it hard to compute the permutation and apply it by hand? | 14:17 |
heiko | lambday: that sounds reasonable | 14:17 |
heiko | problem is more the memory | 14:17 |
ZeThomas | blackburn: so you mean compute the upper triangular, and populate that in my CustomKernel object? | 14:18 |
lambday | heiko: yes.. | 14:18 |
-!- sumit_ [73f91219@gateway/web/freenode/ip.115.249.18.25] has quit [Ping timeout: 245 seconds] | 14:18 | |
blackburn | ZeThomas: yes | 14:18 |
lambday | heiko: I need to check the older eigen sparse module.. | 14:19 |
ZeThomas | blackburn: and then the whole matrix of k(x,y) for x \in train and y \in test? | 14:19 |
heiko | lambday: the gsoc projects will probably need those permutations at some point anyway ... | 14:19 |
blackburn | heiko: lambday: I use SimplicialLDLT in eigen >3.1.0 and SimplicialCholesky in eigen <3.1.0 | 14:19 |
heiko | lambday: there is a class for the permutation | 14:19 |
blackburn | ZeThomas: yes exactly | 14:19 |
blackburn | ZeThomas: two matrices | 14:19 |
lambday | heiko: yes... ordering | 14:19 |
ZeThomas | blackburn: ok, I see... final question: it's ok though to overwrite the initial gram matrix by this second one, in the same object? or would you advise against that? | 14:20 |
heiko | lambday: http://eigen.tuxfamily.org/dox-devel/classEigen_1_1AMDOrdering.html | 14:21 |
heiko | doenst sound too hard, does it? :) | 14:21 |
blackburn | ZeThomas: I don't think you will be able to overwrite it | 14:22 |
heiko | lambday: I think it should be fine if you just put that in front of the sparse LLT cholesky | 14:22 |
ZeThomas | blackburn: how do I set it then, in my kernel? | 14:22 |
lambday | heiko: yes.. simplicialLLT uses this class before computing.. but I am not sure if it was there in eigen <3.1.0.. | 14:23 |
lambday | heiko: let me check | 14:23 |
heiko | lambday: ah now I see | 14:23 |
heiko | this class might not have existed | 14:23 |
lambday | heiko: yes that's the problem | 14:23 |
heiko | blackburn: can't we ask users for eigen3.1? :D | 14:23 |
lambday | heiko: eigen >= 3.1.0 uses ordering by default | 14:23 |
lambday | I checked the source | 14:23 |
blackburn | ZeThomas: you create CustomKernel from your matrix | 14:24 |
lambday | heiko: that would save a lot of pain :D | 14:24 |
heiko | lambday: ok good, so lets find out where the ordering came in | 14:24 |
blackburn | ZeThomas: you can just svm.set_kernel(CustomKernel(train_matrix)) | 14:24 |
blackburn | then train and svm.set_kernel(CustomKernel(test_matrix)) | 14:24 |
blackburn | and then apply() | 14:24 |
ZeThomas | blackburn: so a new kernel object then, and replace the kernel in the svm | 14:24 |
blackburn | yes that would be simplest I think | 14:24 |
heiko | lambday, blackburn we could just output a runtime warning if this method is called without the permutation | 14:24 |
ZeThomas | blackburn: ah, okay, i see | 14:25 |
lambday | heiko: umm... yes | 14:25 |
blackburn | heiko: I don't know - it is still in 12.04 LTS | 14:25 |
heiko | blackburn: so maybe just make it madatory? | 14:25 |
blackburn | 3.0.? | 14:25 |
blackburn | 3.0.x | 14:25 |
heiko | ah | 14:25 |
heiko | so better not | 14:25 |
blackburn | heiko: that's pretty hard requirement | 14:26 |
heiko | blackburn: agree | 14:26 |
heiko | lambday: so pls have a look whether the ordering class is in 3.0.x | 14:26 |
blackburn | heiko: what is the issue with ordering? | 14:26 |
lambday | heiko: okay let me check | 14:26 |
heiko | if yes, include it in the code, if not, just put a warning "sparse Cholesky is computed without reordering - might take long or run out of memory. Install Eigen >3.1 in order to use reordering ..." | 14:27 |
heiko | something like that | 14:27 |
heiko | lambday: SG_SWARNING("CStatistics::log_det(): Blablablla") | 14:28 |
lambday | heiko: alright.... | 14:28 |
heiko | lambday: code is great work btw! | 14:28 |
lambday | heiko: thanks man... you and blackburn are so helpful... | 14:29 |
heiko | blackburn: just knows everything :D | 14:29 |
lambday | heiko: hey good news seems there is a Amd.h in my older eigen... not sure it its 3.0.x... let me check | 14:30 |
lambday | heiko: yes its there in 3.0.6.. I'm trying to use it then | 14:40 |
heiko | lambday: great! make sure that you also somehow test it to produce the same results as your other test | 14:41 |
lambday | heiko: alright... :) | 14:42 |
lambday | heiko: as blackburn said, we could have used SimplicialCholesky for eigen < 3.1.0 instead but we need the the access the diagonal.. in SimplicialCholesky I am not sure if we can do that... m_diag is protected and there is no get method | 14:51 |
heiko | lambday: what about the ordering class then? | 14:52 |
lambday | heiko: I just checked, the older version uses amd in simplicialCholesky class... | 14:53 |
heiko | ok good | 14:53 |
lambday | with permutation and all... | 14:53 |
heiko | so if there is a way to access the diagonal we can use this one | 14:53 |
heiko | should be possible | 14:53 |
lambday | heiko: but SimplicialCholesky doesn't profide a matrixL sort of method that SimplicialLLT does... | 14:54 |
lambday | heiko: yes | 14:54 |
heiko | lambday: if it doesnt give its diagonal, maybe just steal the code | 14:55 |
heiko | to permute etc | 14:55 |
lambday | heiko: ummm... steal the code? as in? | 14:56 |
heiko | lambday: just do the permutation by hand as they do it in eigen | 14:56 |
lambday | there is another way.. | 14:56 |
heiko | that is? | 14:56 |
lambday | heiko: yes yes... that is the another way that I was saying :D | 14:57 |
heiko | ok | 14:57 |
lambday | heiko: let me try... | 14:57 |
heiko | lambday: have a try | 14:57 |
heiko | if it turns out to be too annoying, well go with the warning | 14:58 |
lambday | heiko: hmm... | 14:58 |
n4nd0 | sonne|work: it finally compiled | 15:00 |
sonne|work | n4nd0: hurray | 15:01 |
sonne|work | what did you do? | 15:01 |
n4nd0 | sonne|work: my OS with a couple of terminals and chromium with a few tabs runs with 0.7GB. During compilation the peak has been 3.7GB RAM and 1.3GB swap | 15:01 |
sonne|work | yeah | 15:01 |
n4nd0 | isn't a bit too much?? :) | 15:02 |
-!- ZeThomas [~thomaspr@2a02:2c40:100:a000:1c78:deb5:6522:b5ca] has quit [Quit: Leaving] | 15:04 | |
sonne|work | n4nd0: yes it is | 15:09 |
sonne|work | this is due to swig & massive use of templates (in shogun & octave) | 15:09 |
n4nd0 | sonne|work: so no real way to cut it down if we want to keep templates? | 15:12 |
sonne|work | n4nd0: well yes - if we could implement a splitcpp program | 15:15 |
sonne|work | or enhance swig such that it splits this huge file into say 10 files | 15:16 |
sonne|work | then compile time would go down and so would memory usage | 15:16 |
n4nd0 | no idea what splitcpp is | 15:16 |
sonne|work | n4nd0: a program that would split up any .cpp file into multiple small ones | 15:17 |
sonne|work | sacrificing static functions | 15:17 |
n4nd0 | aham | 15:17 |
sonne|work | something to be written | 15:17 |
n4nd0 | static functions or inline? | 15:17 |
n4nd0 | why would split in several files sacrifice static? | 15:17 |
n4nd0 | gtg now, see you later | 15:22 |
-!- n4nd0 [~nando@n186-p150.kthopen.kth.se] has quit [Quit: leaving] | 15:22 | |
sonne|work | http://www.lazycplusplus.com/download.html | 15:31 |
sonne|work | maybe that thing can help us... | 15:31 |
blackburn | sonne|work: how? | 15:33 |
sonne|work | http://www.hwaci.com/sw/mkhdr/ | 15:33 |
blackburn | sonne|work: I can't get what ist the help of generating header | 15:34 |
sonne|work | blackburn: we need to split up the wrapper file to multiple files | 15:34 |
sonne|work | so we need .h's for function / class definitions | 15:34 |
sonne|work | and functions in different file | 15:35 |
sonne|work | s | 15:35 |
blackburn | so divide .cpp | 15:35 |
blackburn | and generate headers? | 15:35 |
sonne|work | blackburn: if you look at the *wrap.cxx you will see that it contains a huge jump table at the end | 15:37 |
sonne|work | all these entries are function pointers to some static (local) functions | 15:38 |
sonne|work | so if we would make these functions non-static | 15:38 |
sonne|work | split up the file somehow | 15:38 |
blackburn | I see | 15:38 |
sonne|work | and have one .cpp with that jump table | 15:38 |
sonne|work | that would include all the function *definitions* | 15:39 |
sonne|work | we would be fine | 15:39 |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 15:49 | |
shogun-notifier- | shogun: Soeren Sonnenburg :master * 2e9367e / tests/integration/octave_modular/ (2 files): https://github.com/shogun-toolbox/shogun/commit/2e9367e561366376486135abf464f8d6a2155c8c | 15:49 |
shogun-notifier- | shogun: use binary/regression labels in octave integration tests | 15:49 |
-!- blackburn [~lisitsin@mxs.kg.ru] has quit [Quit: Leaving.] | 16:11 | |
-!- lambday [0e8b614f@gateway/web/freenode/ip.14.139.97.79] has quit [Ping timeout: 245 seconds] | 16:17 | |
-!- ahcorde [5813e5d6@gateway/web/freenode/ip.88.19.229.214] has joined #shogun | 16:24 | |
shogun-buildbot_ | build #988 of deb3 - modular_interfaces is complete: Failure [failed test octave_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/988 blamelist: Soeren Sonnenburg <sonne@debian.org> | 16:27 |
-!- sumit [73f91219@gateway/web/freenode/ip.115.249.18.25] has joined #shogun | 16:32 | |
-!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has quit [Ping timeout: 256 seconds] | 16:37 | |
-!- sumit [73f91219@gateway/web/freenode/ip.115.249.18.25] has quit [Quit: Page closed] | 16:42 | |
-!- travis-ci [~travis-ci@ec2-50-19-59-96.compute-1.amazonaws.com] has joined #shogun | 16:48 | |
travis-ci | [travis-ci] it's Soeren Sonnenburg's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/6017082 | 16:48 |
-!- travis-ci [~travis-ci@ec2-50-19-59-96.compute-1.amazonaws.com] has left #shogun [] | 16:48 | |
-!- ZeThomas [~thomaspr@2a02:2c40:100:a000:1c78:deb5:6522:b5ca] has joined #shogun | 17:02 | |
ZeThomas | I'm getting this weird behaviour from shogun lately (2.1.0 - python-modular --enable-swig-directors) | 17:06 |
ZeThomas | Most of the time it stops after a random number of iterations when I run my tests, without output, just "exit code 139" | 17:07 |
ZeThomas | and this one time I then get this: http://pastebin.com/JsLAFTFY | 17:08 |
@sonney2k | ZeThomas, looks like you are getting random memory corruptions | 17:17 |
ZeThomas | sonney2k, how is this caused? | 17:18 |
@sonney2k | no idea | 17:20 |
shogun-notifier- | shogun: Soeren Sonnenburg :master * 8587385 / tests/integration/octave_modular/ (3 files): https://github.com/shogun-toolbox/shogun/commit/858738543784ee7e269f4cff00bf50df6a20800c | 17:20 |
shogun-notifier- | shogun: a couple of fixes for the tests | 17:20 |
@sonney2k | hard to debug | 17:20 |
ZeThomas | so there's nothing I can do about this? | 17:23 |
@sonney2k | ZeThomas, show us the code / a minimal example to reproduce this | 17:25 |
ZeThomas | ok, on it | 17:25 |
-!- ahcorde [5813e5d6@gateway/web/freenode/ip.88.19.229.214] has quit [Ping timeout: 245 seconds] | 17:26 | |
ZeThomas | here you go: http://pastebin.com/1GwtYEC7 | 17:29 |
ZeThomas | oh, and test_learner_fraction basically calls learner.test([...]) with random shuffles of the data | 17:32 |
ZeThomas | I'm running it now with a different learner, that uses features and the LinearKernel, and that seems to work fine | 17:33 |
ZeThomas | so it's because of my CustomKernel? | 17:33 |
shogun-notifier- | shogun: Soeren Sonnenburg :master * 395b4dc / tests/integration/octave_modular/ (5 files): https://github.com/shogun-toolbox/shogun/commit/395b4dce2b1dd6208e0c8c2a37f9ad29e0522486 | 17:36 |
shogun-notifier- | shogun: fix further octave modular tests | 17:36 |
@sonney2k | ZeThomas, wait you cannot derive from CustomKernel | 17:37 |
@sonney2k | only from DirectorKernels | 17:37 |
@sonney2k | there is no way of overloading shogun's custom kernel | 17:37 |
ZeThomas | oh | 17:37 |
@sonney2k | I wonder why swig didn't complain | 17:37 |
@sonney2k | ZeThomas, all of the core of shogun is in C++ | 17:37 |
@sonney2k | for speed | 17:37 |
@sonney2k | so we only allow very few classes named Director* to be overloaded from python | 17:38 |
ZeThomas | ok, I see | 17:38 |
@sonney2k | sry, gtg | 17:38 |
ZeThomas | so what is the best strategy then to do? | 17:38 |
-!- travis-ci [~travis-ci@ec2-50-19-59-96.compute-1.amazonaws.com] has joined #shogun | 17:47 | |
travis-ci | [travis-ci] it's Soeren Sonnenburg's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/6019432 | 17:47 |
-!- travis-ci [~travis-ci@ec2-50-19-59-96.compute-1.amazonaws.com] has left #shogun [] | 17:47 | |
-!- travis-ci [~travis-ci@ec2-107-22-45-48.compute-1.amazonaws.com] has joined #shogun | 17:57 | |
travis-ci | [travis-ci] it's Soeren Sonnenburg's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/6019800 | 17:57 |
-!- travis-ci [~travis-ci@ec2-107-22-45-48.compute-1.amazonaws.com] has left #shogun [] | 17:57 | |
-!- ZeThomas [~thomaspr@2a02:2c40:100:a000:1c78:deb5:6522:b5ca] has quit [Quit: Leaving] | 18:06 | |
shogun-buildbot_ | build #989 of deb3 - modular_interfaces is complete: Failure [failed test octave_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/989 blamelist: Soeren Sonnenburg <sonne@debian.org> | 18:08 |
shogun-buildbot_ | build #990 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/990 blamelist: Soeren Sonnenburg <sonne@debian.org> | 18:13 |
-!- sumit [73f91219@gateway/web/freenode/ip.115.249.18.25] has joined #shogun | 19:40 | |
-!- blackburn [~blackburn@83.234.54.216] has joined #shogun | 19:59 | |
-!- sumit [73f91219@gateway/web/freenode/ip.115.249.18.25] has quit [Ping timeout: 245 seconds] | 20:34 | |
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 20:36 | |
-!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 20:55 | |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 21:00 | |
shogun-notifier- | shogun: Soeren Sonnenburg :master * 680c8c6 / / (5 files): https://github.com/shogun-toolbox/shogun/commit/680c8c6455b0832a03ec5d73db96b669feb21976 | 21:00 |
shogun-notifier- | shogun: fix remaining octave_modular tests and use same default values in | 21:00 |
shogun-notifier- | shogun: LAKernel no matter what constructor is used | 21:00 |
@sonney2k | n4nd0, cross you fingers | 21:00 |
n4nd0 | sonney2k: crossed, together with toes | 21:00 |
@sonney2k | n4nd0, if that all works all that is left to do is switch to the new development model and put the workshop on the website front page and announce it properly | 21:08 |
@sonney2k | then finger & toes crossed if GSoC happens w/ us we can fully concentrate on that | 21:09 |
@sonney2k | n4nd0, if you have time please try to get versioning into the shogun website... | 21:11 |
n4nd0 | sonney2k: versioning for the articles I understand | 21:20 |
n4nd0 | the thing of storing a history of the changes | 21:20 |
shogun-buildbot_ | build #696 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/696 blamelist: Soeren Sonnenburg <sonne@debian.org> | 21:22 |
shogun-notifier- | shogun: Heiko Strathmann :master * 40cf905 / tests/unit/features/DataGenerators_unittest.cc: https://github.com/shogun-toolbox/shogun/commit/40cf905896f0df62fc8f20234fef0494b17d8f40 | 21:38 |
shogun-notifier- | shogun: lowered accuracy a bit since test failed locally | 21:38 |
shogun-notifier- | shogun: Heiko Strathmann :master * 6cbec42 / src/shogun/classifier/svm/LibSVM.cpp,src/shogun/classifier/svm/LibSVM.h: https://github.com/shogun-toolbox/shogun/commit/6cbec422f3ec8876d746e6bb4ed71d7afca50be9 | 21:38 |
shogun-notifier- | shogun: cleaner handling of solver type | 21:38 |
shogun-notifier- | shogun: Heiko Strathmann :master * b5ca129 / src/shogun/regression/svr/LibSVR.cpp,src/shogun/regression/svr/LibSVR.h: https://github.com/shogun-toolbox/shogun/commit/b5ca129990ecc05f55795ef404a74911b6914dbb | 21:38 |
shogun-notifier- | shogun: added the possibility to use nu-svr | 21:38 |
shogun-notifier- | shogun: Heiko Strathmann :master * f5c2be0 / examples/undocumented/libshogun/ (2 files): https://github.com/shogun-toolbox/shogun/commit/f5c2be04631be209c7430acbb1454862bf556723 | 21:38 |
shogun-notifier- | shogun: added simple example for libsvr | 21:38 |
shogun-notifier- | shogun: Heiko Strathmann :master * e422c66 / examples/undocumented/libshogun/regression_libsvr.cpp: https://github.com/shogun-toolbox/shogun/commit/e422c6660128c577cf0ad548c7e4d570040620a2 | 21:38 |
shogun-notifier- | shogun: slightly midified example to usee NU-SVR | 21:38 |
shogun-notifier- | shogun: Heiko Strathmann :master * 630d41e / src/shogun/regression/svr/LibSVR.h: https://github.com/shogun-toolbox/shogun/commit/630d41ec2c89ec80b0f716908e3dd6b94b001dca | 21:38 |
shogun-notifier- | shogun: updated class documentation for libsvr | 21:38 |
shogun-notifier- | shogun: Heiko Strathmann :master * c71a337 / src/shogun/regression/svr/LibSVR.cpp,src/shogun/regression/svr/LibSVR.h: https://github.com/shogun-toolbox/shogun/commit/c71a337d6d985d74110f0a6577fd81f53dbac7a2 | 21:38 |
shogun-notifier- | shogun: minor documentation/copyright update | 21:38 |
shogun-notifier- | shogun: Heiko Strathmann :master * c14e37a / src/NEWS: https://github.com/shogun-toolbox/shogun/commit/c14e37a3e273b43b491a64de5008f610c992a4c8 | 21:38 |
shogun-notifier- | shogun: mention nu-svr in the news | 21:38 |
shogun-notifier- | shogun: Heiko Strathmann :master * da3bb9c / src/shogun/regression/svr/LibSVR.cpp: https://github.com/shogun-toolbox/shogun/commit/da3bb9c0ef2b0eff637c8abb6875eeabd59fc4e7 | 21:38 |
shogun-notifier- | shogun: fixed a copy/paste bug | 21:38 |
-!- heiko [~heiko@nat-180-85.internal.eduroam.ucl.ac.uk] has left #shogun [] | 21:40 | |
-!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has quit [Ping timeout: 255 seconds] | 21:49 | |
-!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 21:51 | |
shogun-buildbot_ | build #991 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/991 | 21:55 |
shogun-buildbot_ | build #697 of cyg1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/697 | 21:58 |
-!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] | 22:13 | |
-!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 22:27 | |
-!- heiko [~heiko@027fc813.bb.sky.com] has joined #shogun | 23:12 | |
shogun-notifier- | shogun: Heiko Strathmann :master * ad6f2b6 / src/shogun/statistics/ (2 files): https://github.com/shogun-toolbox/shogun/commit/ad6f2b6946551183f22693e31eaeb9864da9338b | 23:19 |
shogun-notifier- | shogun: removed python_modular compile warning | 23:19 |
shogun-notifier- | shogun: Heiko Strathmann :master * 43e954f / src/shogun/statistics/ (2 files): https://github.com/shogun-toolbox/shogun/commit/43e954fca0cb15a2cc8858d756db0522c5da87b9 | 23:19 |
shogun-notifier- | shogun: Merge pull request #963 from karlnapf/master | 23:19 |
shogun-notifier- | shogun: | 23:19 |
shogun-notifier- | shogun: fix a warning | 23:19 |
--- Log closed Thu Apr 04 00:00:19 2013 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!