--- Log opened Wed Jul 31 00:00:54 2013 | ||
-!- FSCV [~FSCV@216-230-229-167-colo.oplink.net] has joined #shogun | 00:02 | |
-!- lisitsyn [~lisitsyn@213.87.131.211] has quit [Read error: Connection reset by peer] | 00:10 | |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * 3c689be / src/shogun/mathematics/Math.h: https://github.com/shogun-toolbox/shogun/commit/3c689be2c6946095298a0963bd275e2f350430c1 | 00:23 |
---|---|---|
shogun-notifier- | shogun: define M_PI if not available | 00:23 |
-!- travis-ci [~travis-ci@ec2-23-22-148-84.compute-1.amazonaws.com] has joined #shogun | 00:31 | |
travis-ci | [travis-ci] it's Viktor Gal'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/9664622 | 00:31 |
-!- travis-ci [~travis-ci@ec2-23-22-148-84.compute-1.amazonaws.com] has left #shogun [] | 00:31 | |
shogun-buildbot | build #1128 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1128 blamelist: Soeren Sonnenburg <sonne@debian.org> | 00:41 |
-!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has joined #shogun | 00:42 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 00:42 | |
-!- FSCV [~FSCV@216-230-229-167-colo.oplink.net] has quit [Quit: Leaving] | 00:54 | |
shogun-notifier- | shogun: Viktor Gal :feature/CMake * 8ff0791 / / (9 files): https://github.com/shogun-toolbox/shogun/commit/8ff0791e0d026e8144d83d00bad38ae698955355 | 00:58 |
shogun-notifier- | shogun: Define CPack components,preliminary CPack settings | 00:58 |
shogun-notifier- | shogun: Fix FindOctave cmake script | 00:58 |
-!- travis-ci [~travis-ci@ec2-23-22-148-84.compute-1.amazonaws.com] has joined #shogun | 01:04 | |
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/9668761 | 01:04 |
-!- travis-ci [~travis-ci@ec2-23-22-148-84.compute-1.amazonaws.com] has left #shogun [] | 01:04 | |
@iglesiasg | wiking: hey! So feature/cmake is ready to start trying it out? | 01:04 |
@wiking | iglesiasg: it was already ready before | 01:10 |
@wiking | but yeah | 01:10 |
@wiking | although it's not rebased yet | 01:10 |
@iglesiasg | wiking: I just played around with ccmake and I am building right now! | 01:10 |
@wiking | and it was branched quite some time ago | 01:10 |
@wiking | yeah cool | 01:10 |
@wiking | let me know wha's happening | 01:10 |
@iglesiasg | wiking: I thought it was very WIP before and could not be yet used | 01:11 |
@wiking | noup | 01:13 |
@wiking | libshogun + python_modular was working already before the WS | 01:13 |
@iglesiasg | wiking: I see, cool | 01:13 |
@iglesiasg | wiking: out of curiosity, why do you think rebase will cause problems? | 01:13 |
@wiking | iglesiasg: i've tried yesterday | 01:14 |
@wiking | :P | 01:14 |
@wiking | had to abort it | 01:14 |
@wiking | although i havent really checked how serious that manual merge would be | 01:14 |
@wiking | buuut it wasnt working automatically | 01:14 |
@wiking | so i just postponed it | 01:14 |
@iglesiasg | got it | 01:14 |
@wiking | as there's still some stuff to be done | 01:14 |
@iglesiasg | such as? | 01:15 |
@wiking | make tests target | 01:16 |
@wiking | that's completely missing | 01:16 |
@wiking | as well as matlab static | 01:16 |
@wiking | and kind of like that's it | 01:16 |
@iglesiasg | wiking: btw I got this at the beginning, but it continued | 01:16 |
@iglesiasg | [ 1%] Generating version header | 01:16 |
@iglesiasg | fatal: Not a valid object name master | 01:16 |
@wiking | mmm yeah i saw that on travis as well | 01:17 |
@wiking | no fucking idea wtf is that | 01:17 |
@iglesiasg | wiking: it is working good here | 01:33 |
@iglesiasg | just tried libshogun for the moment | 01:33 |
-!- travis-ci [~travis-ci@ec2-23-22-148-84.compute-1.amazonaws.com] has joined #shogun | 01:34 | |
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/9670226 | 01:34 |
-!- travis-ci [~travis-ci@ec2-23-22-148-84.compute-1.amazonaws.com] has left #shogun [] | 01:34 | |
-!- travis-ci [~travis-ci@ec2-23-22-148-84.compute-1.amazonaws.com] has joined #shogun | 01:39 | |
travis-ci | [travis-ci] it's Viktor Gal'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/9671355 | 01:39 |
-!- travis-ci [~travis-ci@ec2-23-22-148-84.compute-1.amazonaws.com] has left #shogun [] | 01:39 | |
@iglesiasg | good night! | 02:29 |
-!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has quit [Quit: Leaving] | 02:45 | |
shogun-buildbot | build #1438 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/1438 blamelist: Soeren Sonnenburg <sonne@debian.org> | 03:22 |
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 03:58 | |
-!- gsomix [~gsomix@95.67.160.18] has quit [Quit: Leaving] | 03:59 | |
-!- zxtx [~zv@rrcs-76-79-81-162.west.biz.rr.com] has quit [Ping timeout: 264 seconds] | 04:00 | |
shogun-buildbot | build #474 of nightly_default is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/474 | 04:59 |
-!- foulwall [~user@110.17.4.161] has joined #shogun | 05:14 | |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 05:27 | |
shogun-notifier- | shogun: Viktor Gal :feature/CMake * 8afb189 / .travis.yml: https://github.com/shogun-toolbox/shogun/commit/8afb1899bc1dedf39fdc819ed07c77648cde1427 | 05:27 |
shogun-notifier- | shogun: travis: add headers pkg of octave | 05:27 |
-!- travis-ci [~travis-ci@ec2-174-129-100-76.compute-1.amazonaws.com] has joined #shogun | 05:37 | |
travis-ci | [travis-ci] it's Viktor Gal'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/9676827 | 05:37 |
-!- travis-ci [~travis-ci@ec2-174-129-100-76.compute-1.amazonaws.com] has left #shogun [] | 05:37 | |
@wiking | sonney2k: ideas: https://travis-ci.org/shogun-toolbox/shogun/jobs/9676836 ?? | 05:38 |
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 08:27 | |
-!- foulwall [~user@110.17.4.161] has quit [Remote host closed the connection] | 08:51 | |
-!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has joined #shogun | 09:00 | |
-!- az_de [82954e22@gateway/web/freenode/ip.130.149.78.34] has joined #shogun | 10:27 | |
-!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has joined #shogun | 10:28 | |
-!- lisitsyn [~lisitsin@mxs.kg.ru] has joined #shogun | 10:30 | |
-!- lisitsyn1 [~lisitsin@mxs.kg.ru] has joined #shogun | 10:48 | |
-!- lisitsyn [~lisitsin@mxs.kg.ru] has quit [Ping timeout: 264 seconds] | 10:51 | |
lisitsyn1 | http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/41159.pdf | 10:59 |
-!- van51 [~van51@ppp-94-66-58-79.home.otenet.gr] has joined #shogun | 11:00 | |
-!- van511 [~van51@athedsl-225195.home.otenet.gr] has joined #shogun | 11:04 | |
-!- van51 [~van51@ppp-94-66-58-79.home.otenet.gr] has quit [Ping timeout: 264 seconds] | 11:06 | |
-!- van511 is now known as van51 | 11:07 | |
az_de | quit | 11:29 |
-!- az_de [82954e22@gateway/web/freenode/ip.130.149.78.34] has left #shogun [] | 11:29 | |
van51 | I'm having some trouble with cmake | 11:36 |
van51 | I'm getting stuff like "/shogun/mathematics/eigen3.h:17:24: fatal error: Eigen/Eigen: No such file or directory compilation terminated." | 11:37 |
van51 | while with make it is doing ok | 11:37 |
van51 | maybe I'm using it wrong | 11:38 |
van51 | if someone has an idea let me know :) | 11:38 |
-!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has joined #shogun | 11:43 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 11:43 | |
@iglesiasg | good morning! | 11:43 |
van51 | iglesiasg: hi! | 11:44 |
van51 | iglesiasg: you used cmake yesterday, right? | 11:47 |
@iglesiasg | van51: yeah! | 11:47 |
@iglesiasg | van51: I compiled libshogun with it | 11:48 |
@iglesiasg | everything went pretty smooth | 11:48 |
van51 | iglesiasg: I'm getting some errors, like clapack.h: No such file or directory :S | 11:48 |
@iglesiasg | van51: I see | 11:49 |
van51 | iglesiasg: while with the other way it was fine | 11:49 |
@iglesiasg | van51: can you take a look with ccmake maybe what is recognized in your system? | 11:49 |
@iglesiasg | van51: I had for instance to set the gmock path by hand using ccmake | 11:50 |
van51 | iglesiasg: and how did you do that? | 11:53 |
van51 | iglesiasg: I can't really tell if something is off tbh :) | 11:53 |
@iglesiasg | van51: let me check about lapack in particular | 11:53 |
@iglesiasg | van51: all right, this is a doubt I always have but I think arpack and lapack are actually the same | 11:54 |
@iglesiasg | van51: so go to the directory <your shogun root dir>/build | 11:54 |
@iglesiasg | van51: and do ccmake .. | 11:55 |
@iglesiasg | van51: not the two cs, what do you see? | 11:55 |
@iglesiasg | not -> note* | 11:55 |
van51 | iglesiasg: <shogun>/build or <shogun>/src? | 11:56 |
@wiking | van51: https://github.com/shogun-toolbox/shogun/issues/1166 | 11:56 |
@iglesiasg | van51: I build with cmake from shogun/build | 11:56 |
@wiking | please add here your error | 11:56 |
@wiking | otherwise i cannot help u | 11:57 |
@wiking | cmake needs testing | 11:57 |
@wiking | and i just test it on travis and my own machine | 11:57 |
@wiking | so maybe some things are not yet working smoothly on other systems | 11:57 |
@iglesiasg | wiking: here libshogun worked fine too, I am to test python_modular now | 11:57 |
van51 | maybe I need to initialize something? because I don't see a build directory | 11:58 |
@wiking | iglesiasg: that should work too as i've tested that intensively | 11:58 |
@iglesiasg | van51: yeah sure, mkdir build | 11:58 |
@wiking | van51: # Instructions: | 11:58 |
@wiking | # $ mkdir build | 11:58 |
@wiking | # $ cd build | 11:58 |
@wiking | # $ cmake .. | 11:58 |
@wiking | # $ make | 11:58 |
@iglesiasg | van51: sorry, I didn't mention that | 11:58 |
@wiking | as it says | 11:58 |
@wiking | in the beginning of the main cmakelists.txt | 11:58 |
@wiking | anyhow i'm back to finish up some of the cmake shit | 11:58 |
@iglesiasg | van51: with cmake you normally do those steps wiking just copied from the CMakelist.txt | 11:58 |
@wiking | hopefull i'll have make tests within some hours | 11:59 |
@wiking | if u really need help | 11:59 |
@iglesiasg | wiking: all right, I will go with another interface too as well then | 11:59 |
@wiking | with cmake | 11:59 |
@wiking | iglesiasg: yeah test other interfaces plz | 11:59 |
@wiking | python should really work | 11:59 |
@wiking | van51: if u got really really stuck or something is not working add your comment to that bug | 11:59 |
@wiking | that way i know what i should fix | 11:59 |
@wiking | i'm now not looking at irc that reguraly | 12:00 |
@wiking | as i really want to finish up this one | 12:00 |
van51 | wiking: ok! if I don't manage to do something I will comment there | 12:00 |
-!- HeikoS [~heiko@nat-182-213.internal.eduroam.ucl.ac.uk] has joined #shogun | 12:32 | |
-!- mode/#shogun [+o HeikoS] by ChanServ | 12:32 | |
thoralf | HeikoS: Hey. | 12:32 |
thoralf | HeikoS: I'm unable to add a label to my ticket. Maybe you have got the permissions to do so? | 12:33 |
thoralf | https://github.com/shogun-toolbox/shogun/issues/1332 | 12:33 |
@HeikoS | thoralf: yeah I can do this | 12:34 |
@HeikoS | thoralf: sorry for not getting back, NIPS reviews got in :=) | 12:34 |
@HeikoS | thoralf: labelled | 12:34 |
thoralf | HeikoS: That's okay. Issues are patient. ;) | 12:34 |
@sonney2k | wiking, use a recent octave! octave and clang don't work well together | 12:36 |
@sonney2k | shogun-buildbot, force build cyg1 - libshogun --branch=develop | 12:37 |
shogun-buildbot | no such builder 'cyg1' | 12:37 |
thoralf | HeikoS: My eclipse (kepler) does not work any more... it dies with a java.lang.StackOverflowError, even after clean shogun-checkout and removing caches/workspaces/etc. | 12:37 |
thoralf | HeikoS: Ever seen this on shogun? | 12:37 |
@sonney2k | shogun-buildbot, force build 'cyg1 - libshogun' --branch=develop | 12:37 |
shogun-buildbot | build forced [ETA 16m09s] | 12:37 |
shogun-buildbot | I'll give a shout when the build finishes | 12:37 |
lisitsyn1 | hahah stackoverflow | 12:37 |
lisitsyn1 | really? | 12:37 |
-!- lisitsyn1 is now known as lisitsyn | 12:37 | |
thoralf | lisitsyn: Yes. :) | 12:37 |
lisitsyn | what a programmers | 12:37 |
thoralf | lisitsyn: The logfile is 100KiB big. | 12:38 |
thoralf | (for one crash) | 12:38 |
lisitsyn | thoralf: that's okay | 12:38 |
lisitsyn | I used to dig into 10MB logs :D | 12:38 |
thoralf | lisitsyn: I won't dig... imagine I would do so, then I am fixing eclipse to fix my shogun problems to fix my ML problems. | 12:39 |
thoralf | lisitsyn: What's next? Fixing Java? | 12:39 |
lisitsyn | thoralf: yeah indeed you don't have to | 12:40 |
lisitsyn | thoralf: I mean 100kb is not the thing to crash anything | 12:41 |
lisitsyn | recursion or something like that | 12:41 |
thoralf | lisitsyn: No, 100kb is the stack trace. ;) | 12:41 |
lisitsyn | thoralf: then you know what happened | 12:41 |
thoralf | lisitsyn: Yes. Recusion. ;) | 12:41 |
thoralf | Recursion | 12:41 |
lisitsyn | HeikoS: your evaluations are the only to go | 12:42 |
lisitsyn | ;) | 12:42 |
@HeikoS | lisitsyn: ok I will do them today | 12:44 |
@HeikoS | wanted yesterday but had too many meetings | 12:44 |
@sonney2k | HeikoS, bad excuse ... takes 2 minutes | 12:45 |
@sonney2k | hurray all builds except cyg1 are green since last night! | 12:45 |
@HeikoS | sonney2k: okok Ill do them now | 12:45 |
lisitsyn | HeikoS: sonney2k: have you decided anything on doc camp thing? | 12:46 |
@sonney2k | lisitsyn, on travis transfer_multitask_clustered_logistic_regression.py is still failing - any updates on that? | 12:46 |
@HeikoS | sonney2k, lisitsyn we should write a good applicatoin, but not recycle the one from last year, we should have amore clear vision what we will get | 12:46 |
lisitsyn | sonney2k: if you can live with removing it for now - lets do that | 12:47 |
lisitsyn | it takes a lot of time to compare with matlab impl I made it from | 12:48 |
@sonney2k | lisitsyn, I would prefer you fixing it and adding a test | 12:48 |
lisitsyn | HeikoS: I think it should be something like that 'X for hackers' or whatever | 12:48 |
lisitsyn | sonney2k: I am afraid I won't be able to do that next days | 12:49 |
@sonney2k | lisitsyn, when? | 12:49 |
lisitsyn | sonney2k: I have time this weekend for sure | 12:49 |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 12:50 | |
shogun-notifier- | shogun: Roman Votyakov :develop * 4c15b21 / src/NEWS: https://github.com/shogun-toolbox/shogun/commit/4c15b214f5753e96c8c2da12ad3c8d3154d1d36a | 12:50 |
shogun-notifier- | shogun: update news | 12:50 |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * f7d66ef / src/NEWS: https://github.com/shogun-toolbox/shogun/commit/f7d66ef1c7d49115b42509b86c1498506dbda7b0 | 12:50 |
shogun-notifier- | shogun: Merge pull request #1337 from votjakovr/feature/numerical_integration | 12:50 |
shogun-notifier- | shogun: | 12:50 |
shogun-notifier- | shogun: Update news | 12:50 |
@iglesiasg | hi sonney2k! how is it going? | 12:50 |
@wiking | iglesiasg: mmm | 12:51 |
@wiking | iglesiasg: travis gave me this | 12:51 |
@iglesiasg | sonney2k: I saw that the SGMatrixList patch fixed the problem in the buildbot, however valgrind still complains about python examples here :S | 12:51 |
@iglesiasg | sonney2k: let me know if you want to have a look at the trace | 12:51 |
@wiking | https://travis-ci.org/shogun-toolbox/shogun/jobs/9676836 | 12:51 |
@wiking | iglesiasg: what is your distrib? | 12:52 |
@iglesiasg | wiking: linux mint | 12:52 |
@wiking | iglesiasg: do you have the HEAD of the feature/CMake? | 12:52 |
@wiking | commit 8ff0791e0d026e8144d83d00bad38ae698955355 | 12:53 |
shogun-buildbot | build #1129 of cyg1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1129 | 12:53 |
@wiking | iglesiasg: since there's a fix for octave detection | 12:53 |
@wiking | try to do a git pull on that branch | 12:53 |
@wiking | and rerun cmake | 12:53 |
@HeikoS | sonney2k, lisitsyn done | 12:54 |
@sonney2k | lisitsyn, ok then this weekend is what we could still bear but we really need it then | 12:54 |
@sonney2k | HeikoS, thanks!! | 12:54 |
@sonney2k | iglesiasg, w/o traces you could say anything :P | 12:55 |
@sonney2k | man all green | 12:55 |
@HeikoS | sonney2k, wiking we should enable valgrind to break the unit tests at some point, same for the libshogun examples | 12:56 |
@HeikoS | thoralf: ^ | 12:56 |
lisitsyn | sonney2k: ok I'll either fix it or remove ti | 12:56 |
@wiking | HeikoS: yeah we should... :) no time sorry want to finish cmake ;P | 12:56 |
@HeikoS | wiking: yeah dont worry | 12:56 |
@wiking | sonney2k: what is a good octave version? :) | 12:56 |
@iglesiasg | sonney2k: http://pastebin.com/A0996D3g | 12:56 |
@HeikoS | wiking: just to keep in mind :) | 12:56 |
@sonney2k | wiking, the latest and greatest but I am not sure any works with clang yet | 12:57 |
@iglesiasg | sonney2k: that is for structure_plif_hmsvm_bmrm.py | 12:57 |
@sonney2k | wiking, try it with g++ rather | 12:57 |
thoralf | HeikoS: I'm valgrinding every code I write - if I find something, I'll fix it. | 12:57 |
@sonney2k | van51, hey how is it going? | 12:57 |
@wiking | sonney2k: 3.2? | 12:57 |
@wiking | sonney2k: as this is what we have by default on travis :( | 12:57 |
@sonney2k | wiking, would work with gnu | 12:57 |
@sonney2k | wiking, no way with clang | 12:57 |
@iglesiasg | wiking: I just saw you made a commit 8h ago for octave package, I was missing that one | 12:58 |
@wiking | sonney2k: ok will switch in travis | 12:58 |
@wiking | iglesiasg: cool try that one | 12:58 |
@wiking | iglesiasg: u using gcc? | 12:58 |
@iglesiasg | wiking: my bad I didn't check it first | 12:58 |
@iglesiasg | wiking: yeah, I think that one is set by default, I have clang too | 12:58 |
@wiking | iglesiasg: ok try with gcc | 13:00 |
@wiking | lets see if it fails for u | 13:00 |
@wiking | sonney2k: http://pastebin.com/97H5iXc9 | 13:02 |
@wiking | sonney2k: ideas? | 13:02 |
@wiking | i have jblas 1.2 | 13:04 |
@wiking | 1.2.0 to b precise | 13:04 |
shogun-buildbot | build #1130 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1130 blamelist: Soeren Sonnenburg <sonne@debian.org> | 13:05 |
@iglesiasg | wiking: same error after rebase | 13:06 |
@wiking | iglesiasg: did you: rm -rf build | 13:06 |
@wiking | because if u just rebased | 13:06 |
@wiking | and rerun cmake | 13:06 |
@wiking | you might have some cached values there | 13:06 |
@wiking | so just rm -rf build && mkdir build etc... | 13:07 |
@iglesiasg | wiking: I didn't, thanks! trying atm | 13:08 |
@iglesiasg | wiking: still the same, unfortunately | 13:09 |
@wiking | mmm | 13:11 |
@wiking | well have fun with the FindOctave.cmake script ;) | 13:11 |
@sonney2k | iglesiasg, the bug is with ParameterMapElement being stored in a Dynarray... | 13:14 |
@sonney2k | HeikoS, ^ | 13:14 |
@sonney2k | iglesiasg, so this is sth else | 13:14 |
@sonney2k | HeikoS, do you need ParameterMapElement to be virtual? | 13:16 |
@HeikoS | sonney2k: I did not write that | 13:16 |
@sonney2k | HeikoS, any ideas who did? | 13:16 |
@sonney2k | HeikoS, what is this for? | 13:17 |
@HeikoS | of wow | 13:17 |
@HeikoS | I wrote it | 13:17 |
@HeikoS | no idea let me check | 13:17 |
@HeikoS | sonney2k: ah thats migration | 13:17 |
@sonney2k | HeikoS, if it would work as a CSGObject one could use DYnamicObjectArray | 13:17 |
@HeikoS | sonney2k: I want to drop that anyways | 13:17 |
@HeikoS | migration is useless | 13:17 |
@HeikoS | what problem does it cause? | 13:18 |
@sonney2k | HeikoS, errm but this means we have no serialization | 13:18 |
@HeikoS | sonney2k: no | 13:18 |
@HeikoS | sonney2k: why that? | 13:18 |
@HeikoS | sonney2k: migration never worked so when did we have serialization? | 13:18 |
@sonney2k | HeikoS, because when you save data with one version of shogun you won't be able to load it in the next | 13:18 |
@HeikoS | sonney2k: I think it is way better to just ignore new elements | 13:18 |
@HeikoS | sonney2k: since that is what usually changes, new members are added | 13:19 |
@sonney2k | HeikoS, and renames are done... | 13:19 |
@HeikoS | sonney2k: nobody used the migration framework for something else ever | 13:19 |
@HeikoS | sonney2k: we cannot support that, it is too much hassle | 13:19 |
@HeikoS | sonney2k: check the code and you will see, it is horrible | 13:20 |
@HeikoS | and it is also horrible to use | 13:20 |
@HeikoS | so I dont know about that | 13:20 |
-!- travis-ci [~travis-ci@ec2-23-22-48-223.compute-1.amazonaws.com] has joined #shogun | 13:20 | |
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/9686791 | 13:20 |
-!- travis-ci [~travis-ci@ec2-23-22-48-223.compute-1.amazonaws.com] has left #shogun [] | 13:20 | |
@HeikoS | we are open-source so why support old formats, companies can do that but I think we cannot | 13:20 |
-!- foulwall [~user@110.17.4.161] has joined #shogun | 13:20 | |
@HeikoS | or re-write parameter framework with migration in mind | 13:20 |
@sonney2k | HeikoS, well if you cannot maintain it then we better drop it | 13:21 |
@HeikoS | sonney2k: strongest reason to drop it is that it is not used | 13:21 |
@sonney2k | it is only a convenience for users | 13:21 |
@HeikoS | sonney2k: and that it doesnt really work | 13:21 |
@HeikoS | yeah, I mean it would be nice to have | 13:21 |
@HeikoS | but not in the way it is currently done | 13:21 |
@HeikoS | sonney2k: and I would also drop the integration tests for that reason | 13:22 |
@sonney2k | HeikoS, no way | 13:22 |
@HeikoS | sonney2k: since they always break and are hard to replace | 13:22 |
@HeikoS | rather unit test results | 13:22 |
@sonney2k | HeikoS, they are worth more than the unit tests | 13:22 |
@HeikoS | sonney2k: currently yes, in a year, I would say no | 13:22 |
@sonney2k | HeikoS, currently unit tests work but lots and lots of integration tests are broken | 13:22 |
@sonney2k | and I mean really not working | 13:22 |
@HeikoS | they dont test the correct thing | 13:22 |
@sonney2k | HeikoS, what is the correct thing then? | 13:23 |
@HeikoS | to assert correct results | 13:23 |
@sonney2k | if not checking that we have corerct results | 13:23 |
@HeikoS | the integration tests include that, but so much more useless stuff | 13:23 |
@HeikoS | so they kind of block development | 13:23 |
@HeikoS | since you always have to update them | 13:23 |
@HeikoS | I would prefer if all integration tests were replaced by simple unit tests and then the examples would be changed to be more illustrative | 13:24 |
@HeikoS | this way we have the same testing power, easier development and examples that are useful rather than being abused for testing | 13:24 |
@sonney2k | HeikoS, what? | 13:24 |
-!- az_de [82954e22@gateway/web/freenode/ip.130.149.78.34] has joined #shogun | 13:24 | |
@HeikoS | sonney2k: some work involved but thats what I would find ideal | 13:24 |
@sonney2k | HeikoS, with the same argument unit tests block development | 13:25 |
@sonney2k | HeikoS, and examples | 13:25 |
@HeikoS | sonney2k: no | 13:25 |
@sonney2k | you always need to update them | 13:25 |
@HeikoS | sonney2k: if you change a class, say add a member the unit tests dont break | 13:25 |
@HeikoS | sonney2k: they just assert correct mathematical results | 13:25 |
@HeikoS | which are invariant of the implementation (more or less) | 13:25 |
@HeikoS | but all class changes dont affect them | 13:25 |
@sonney2k | HeikoS, same with integration tests | 13:26 |
@HeikoS | sonney2k: no, the tests break if you add a member | 13:26 |
@sonney2k | no | 13:26 |
@HeikoS | take for example labels | 13:26 |
@sonney2k | only if you add sth to the serialization framework | 13:26 |
@sonney2k | and then it is actually good | 13:26 |
@HeikoS | sonney2k: yeah | 13:26 |
@wiking | sonney2k: wtf is the purpose of .scrub_docstrings.py? | 13:26 |
@sonney2k | because you want that tested too | 13:26 |
@HeikoS | sonney2k: thats why we dont do that, we have all these warnings: add parameters | 13:26 |
@HeikoS | and parameters are not added since they break the tests | 13:26 |
@HeikoS | which is annoying | 13:26 |
@sonney2k | HeikoS, but that is bullshit | 13:27 |
@HeikoS | and doesnt help detecting errors at all | 13:27 |
@sonney2k | we can just check if everything is still fine | 13:27 |
@sonney2k | then run generator.py <changed_file.py> | 13:27 |
@sonney2k | and commit the new data | 13:27 |
@HeikoS | sonney2k: most developers (including me) have problems updating them | 13:27 |
@HeikoS | and it is very annoying | 13:27 |
@HeikoS | see my point is just: if we replace them, we have the same test power | 13:28 |
@HeikoS | but minus all the hassle | 13:28 |
@sonney2k | well maybe giving you a script doing that would help | 13:28 |
@sonney2k | it is just 3 lines of git commit -a / push / commit push | 13:28 |
@sonney2k | 4 | 13:28 |
@HeikoS | sonney2k: but what do we gain from the serialisation stays fixed test? | 13:28 |
@wiking | sonney2k HeikoS we can create a pre-commit hook ;) | 13:28 |
@sonney2k | HeikoS, we gain that the *whole* pipeline is tested | 13:28 |
@sonney2k | HeikoS, unit tests don't cover bigger stuff | 13:29 |
@HeikoS | sonney2k: why is that helpful? | 13:29 |
@HeikoS | for example? | 13:29 |
@sonney2k | HeikoS, because several small units may work | 13:29 |
@sonney2k | but their integration might not be well tested | 13:29 |
@HeikoS | for example? | 13:29 |
@sonney2k | HeikoS, everyone in industry is doing that | 13:29 |
@HeikoS | most integration test do not test bigger stuff | 13:29 |
@sonney2k | HeikoS, what for example? | 13:29 |
@HeikoS | example of such a situation where the big thing cannot be tested by unit tests? | 13:30 |
@HeikoS | sonney2k: I would rather test that all steps of the pipeline work correctly than testing the final byte-result | 13:30 |
@HeikoS | because then you know what broke if something breaks | 13:31 |
@HeikoS | also in shogun we dont have large parts of framework parts interacting with each other | 13:31 |
@HeikoS | rather multiple small algorithms | 13:31 |
-!- foulwall` [~user@110.17.4.161] has joined #shogun | 13:31 | |
@sonney2k | HeikoS, sure that is what unit tests are for | 13:31 |
@HeikoS | sonney2k: I agree with you that integration tests are useful if you have such big frameworks, but we dont, look at our integration tests, they can all be replaced units | 13:32 |
@HeikoS | sonney2k: for example all these kernels | 13:32 |
@sonney2k | HeikoS, yeah but why would one do that? You need to write an example per algorithm anyways | 13:33 |
@sonney2k | and you get a test *for free* | 13:33 |
@sonney2k | and it is very readable to users and a test | 13:33 |
@HeikoS | sonney2k: I think they are causing more trouble than they are useful | 13:33 |
@HeikoS | (given that they are replaced by units) | 13:33 |
-!- foulwall [~user@110.17.4.161] has quit [Ping timeout: 268 seconds] | 13:34 | |
@HeikoS | sonney2k: also they dont tell you what is wrong when they fail, just THAT its wrong | 13:34 |
@sonney2k | so far I have seen them only to detect bugs we would not have detected | 13:34 |
@sonney2k | HeikoS, yeah but you can then just run tester.py -d and you get a shell where you can investigate the objects that are different | 13:34 |
@HeikoS | sonney2k: its so much easier to get a failing assertion | 13:35 |
@sonney2k | HeikoS, I guess you didn't notice that GaussianProcessRegression was no longer working since your last commit did you? | 13:35 |
@sonney2k | HeikoS, the integration test failed and so I could have a look and fix it | 13:35 |
@HeikoS | what failed? | 13:35 |
@HeikoS | the python example or the test? | 13:35 |
@sonney2k | GaussianProcessRegression was no longer available | 13:35 |
@sonney2k | in modular interfaces | 13:35 |
@HeikoS | so the example failed | 13:35 |
@HeikoS | not the test | 13:35 |
@sonney2k | the integration test | 13:36 |
@sonney2k | the example works | 13:36 |
@HeikoS | running the examples is good | 13:36 |
@HeikoS | why does it work if the class is not available? | 13:36 |
@sonney2k | if eigen3 is not available the example will give an OK | 13:36 |
@HeikoS | and if it is available? | 13:36 |
@HeikoS | if eigen is not available the integration test cannot be ran | 13:37 |
@sonney2k | should fail but didn't check | 13:37 |
@sonney2k | HeikoS, you can look up the failure yourself in travis | 13:37 |
@HeikoS | these type of api-interface problems can be detected by running the examples | 13:37 |
@HeikoS | no need for comparing serialised objects for that | 13:37 |
@sonney2k | in addition it is also a good test for serializtion | 13:38 |
@HeikoS | sonney2k: yep agree, but that will be handled by automatic unit tests soon in a way better way (all classes etc) | 13:38 |
@HeikoS | like clone and equals | 13:38 |
thoralf | HeikoS: What happens if someone add members to the serialization (i.e. the parameters i guess?) | 13:38 |
@HeikoS | thoralf: the integration test breaks | 13:39 |
thoralf | HeikoS: No, technically. | 13:39 |
@HeikoS | it is been written to the file upon save, so gives a different binary object on disc | 13:39 |
thoralf | And the binary objects will be compared? | 13:40 |
@HeikoS | yes | 13:40 |
thoralf | Uh. | 13:40 |
@HeikoS | thoralf: we want to replace this by an equals instead | 13:40 |
thoralf | Is there a text-representation to compare with diff? | 13:40 |
@HeikoS | thoralf: yes | 13:40 |
@sonney2k | HeikoS, so back to my original question: we can drop the parametermap* class right? | 13:40 |
thoralf | So why don't do this? | 13:40 |
@HeikoS | sonney2k: migration will stop working immediately | 13:41 |
@sonney2k | thoralf, we do this | 13:41 |
@HeikoS | sonney2k: So I would rather discuss this a bit more | 13:41 |
@HeikoS | sonney2k: see my git issues on dropping migration | 13:41 |
thoralf | sonney2k: HeikoS just told you're comparing the binary. | 13:41 |
@sonney2k | thoralf, no on travis you see a ascii diff of what has changed | 13:41 |
@sonney2k | so you could see that a variable is added/removed/changed | 13:41 |
@sonney2k | also when sth crashes | 13:42 |
@sonney2k | you will get a gdb backtrace | 13:42 |
@HeikoS | sonney2k: I would only drop migration if integration is changed, because otherwise its too painful to change things | 13:42 |
@HeikoS | sonney2k: but I dont know, I would like to discuss this with others also before actually dropping things | 13:42 |
@HeikoS | sonney2k: so rather not drop now but after GSoC or so | 13:42 |
@sonney2k | HeikoS, but didn't you just say that migration is not used? | 13:43 |
* sonney2k gets confused | 13:43 | |
@HeikoS | sonney2k: I think so, but not sure, its deep down in the parameter framework so dropping classes can be dangerous | 13:43 |
@sonney2k | I mean yes integration tests fail as soon as some variable name is changed/added/removed/meaning is changed/ | 13:44 |
@HeikoS | There are some add calls on the migration maps done by some classes | 13:44 |
thoralf | HeikoS: Is there a way to recover if a parameter was added? Lets say: "load serialization; apply default parameters; save serialization"? | 13:44 |
@HeikoS | thoralf: thats what migration does | 13:44 |
@sonney2k | thoralf, yes that would work | 13:44 |
@sonney2k | thoralf, also the other way around if some parameter is missing it will just not be loaded | 13:44 |
@HeikoS | thoralf: but we would need a person working full time on that to be able to maintain it, its hard stuff to do | 13:44 |
thoralf | HeikoS: Okay, missed that. Too much text in this thread now. ;) | 13:44 |
@HeikoS | ok back to NIPS :) | 13:45 |
@sonney2k | HeikoS, thoralf migration rather does the conversion - so you could *reanme* a variable and it could still work | 13:45 |
@sonney2k | or you could change its meaning | 13:45 |
@sonney2k | and add some code to load older revisions | 13:45 |
@HeikoS | sonney2k: or type or even more things | 13:45 |
@sonney2k | HeikoS, I need a short term fix then | 13:46 |
@HeikoS | sonney2k: I think its too ambitios | 13:46 |
@HeikoS | sonney2k: whats the problem? | 13:46 |
@HeikoS | sonney2k: the parameter stuff does not to be mapped with swig btw | 13:46 |
@sonney2k | ParameterMapElement is in a DynArray | 13:46 |
@sonney2k | and since it has virtual methods -> malloc/realloc -> kaboom | 13:46 |
@sonney2k | so either drop these methods or make it a derivative of CSGObject | 13:47 |
@sonney2k | and use DynamicObjectArray | 13:47 |
@HeikoS | sonney2k: why did that pop up now? | 13:47 |
@HeikoS | and not before? | 13:47 |
@sonney2k | no idea | 13:47 |
@HeikoS | what fails? | 13:48 |
@sonney2k | or maybe I am misinterpreting the error | 13:48 |
shogun-buildbot | build #1131 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1131 blamelist: Roman Votyakov <votjakovr@gmail.com> | 13:48 |
@HeikoS | sonney2k: I did not change anythjing in there | 13:48 |
@sonney2k | HeikoS, iglesias posted it here http://pastebin.com/A0996D3g | 13:48 |
thoralf | sonney2k: Now I'm confused. According to HeikoS it's a lot of work, but you're suggesting it can be done automatically. Yes/no/maybe? ;) | 13:49 |
thoralf | i.e. 4 lines of shell code | 13:50 |
@sonney2k | thoralf, what? | 13:50 |
@sonney2k | thoralf, what do you mean? | 13:50 |
thoralf | sonney2k: The migration of serialized examples. | 13:50 |
@HeikoS | sonney2k: what code caused this? | 13:50 |
@HeikoS | sonney2k: I am pretty sure this can be solved without dropping the class | 13:50 |
@sonney2k | thoralf, errm I am still not following | 13:51 |
@sonney2k | HeikoS, running the *structur*py examples | 13:51 |
@HeikoS | sonney2k: since when is this? | 13:52 |
@sonney2k | thoralf, let me explain a bit more | 13:52 |
@HeikoS | what patch broke them? | 13:52 |
@sonney2k | HeikoS, no idea. I did dig to several bugs until this one popped out | 13:52 |
@sonney2k | thoralf, we have examples/*/python_modular | 13:52 |
@sonney2k | thoralf, these are written in a way that these are functions returning some stuff | 13:53 |
@HeikoS | sonney2k: this is probably some add call to the migration map, but it worked before, so should not be solved this way | 13:53 |
@sonney2k | thoralf, so a function can be called with certain parameters and the returned result is pickled to disk by a generator.py script to create reference data. if among this stuff are shogun objects these are serialized with shogun's framework | 13:54 |
@sonney2k | thoralf, now when we run integration tests with tester.py the example is run again and results are compared with the serialized stuff | 13:55 |
@sonney2k | HeikoS, which way? | 13:55 |
thoralf | sonney2k: Yes, and HeikoS point is that it's hard to maintain the serialized stuff. Right? | 13:55 |
@sonney2k | thoralf, well one just has to run generator.py <example.py> and then git commit in shogun-data & push and git add data in shogun and push | 13:56 |
@HeikoS | sonney2k: dropping parameter map, too risky for now, and I dont have time to go into it and fix/drop things properly currently, so I propose we do this after GSoC in a clean way and fix this bug in anther way, for exampling by finding our what caused it | 13:56 |
@HeikoS | thoralf: migration is hard to maintain, one needs full time people for that | 13:56 |
@sonney2k | HeikoS, not sure what you are referring to - watching that stuff is changed in a compatible way or code? | 13:58 |
@sonney2k | or both? | 13:58 |
@HeikoS | sonney2k: fixing the bug without dropping parameter map | 13:58 |
@HeikoS | drop migration after gsoc | 13:58 |
@HeikoS | (since dropping it might break things) | 13:58 |
@HeikoS | (and currently too overloaded to deal with that) | 13:59 |
@sonney2k | yeah no that was I mean wrt what you said to thoralf | 13:59 |
@HeikoS | sonney2k: ah sorry | 14:00 |
@HeikoS | what? :) | 14:00 |
@HeikoS | whats the question? | 14:00 |
@sonney2k | HeikoS, thatmigration is hard to maintain, one needs full time people for that | 14:01 |
@sonney2k | HeikoS, so for watching that stuff is changed in a compatible way or code? | 14:01 |
@sonney2k | <sonney2k> or both? | 14:01 |
@HeikoS | sonney2k: yeah, its beyond our manpower, if we had some full time developers, we could do that, like a company | 14:01 |
@HeikoS | sonney2k: no the idea of loading older file formats | 14:01 |
@HeikoS | aka migration | 14:01 |
@sonney2k | I just don't understand what requires the manpower here | 14:01 |
thoralf | HeikoS: But which part requires the man power? | 14:02 |
@sonney2k | yeah that is my question | 14:02 |
@wiking | CMAKE! | 14:02 |
@wiking | fucking hell | 14:02 |
@wiking | :D | 14:02 |
@HeikoS | re-writing the parameter framework in such way that migration is easy ;) | 14:02 |
@sonney2k | wiking, :D | 14:02 |
@HeikoS | wiking: haha :) | 14:02 |
@wiking | this conversation that you have | 14:02 |
@wiking | here for the last 30 mins | 14:02 |
@wiking | is fucking pointless | 14:02 |
@wiking | there are far more urgent things | 14:02 |
@wiking | and there are real concrete problems | 14:02 |
@sonney2k | wiking, I only wanted to fix a bug | 14:02 |
@HeikoS | actually, yes | 14:02 |
@wiking | would be great if you could concentrate on that | 14:02 |
thoralf | wiking: Yeah. ;) | 14:02 |
@wiking | sonney2k: get it... but still this is too mcuh | 14:03 |
@wiking | sonney2k: for a bugfix | 14:03 |
@HeikoS | sonney2k: so pls fix it without dropping things for now, I will take care of that later | 14:03 |
@wiking | so | 14:03 |
@sonney2k | HeikoS, yes yes yes! | 14:03 |
@wiking | how the fuck can happen this | 14:03 |
@HeikoS | sonney2k: since it worked before, that must be possible | 14:03 |
@sonney2k | HeikoS, yes yes yes ...sir! | 14:03 |
@wiking | Users/wiking/shogun/examples/undocumented/java_modular/classifier_averaged_perceptron_modular.java:24: set_feature_matrix(org.shogun.RealMatrix) in org.shogun.RealFeatures cannot be applied to (org.jblas.DoubleMatrix) feats_train.set_feature_matrix(traindata_real); | 14:03 |
@wiking | did i fuckup something in the modular generation? | 14:03 |
@sonney2k | wiking, I recall seeing things like this (2 years ago) | 14:05 |
@sonney2k | so no clue | 14:05 |
@wiking | iglesiasg: can u test some of the examples of python_modular with the cmake generated python_modular? | 14:05 |
@wiking | you'll have to do that by hand, as the make tests is not working yet | 14:05 |
@wiking | iglesiasg: if there's any errors just paste it into the common cmake bug | 14:06 |
@sonney2k | foulwall`, did you manage to put the data into a .zip? | 14:06 |
@iglesiasg | wiking: so cmake for python modular, make and then in src make check-tests? | 14:06 |
@sonney2k | wiking, btw are you only working on the Cmakefiel.txt? | 14:07 |
@wiking | iglesiasg: nonono as said that will not work | 14:07 |
@wiking | sonney2k: yes indeed | 14:07 |
@sonney2k | wiking, I mean if so you should just do that in develop | 14:07 |
@sonney2k | you cannot break a build until we switch | 14:07 |
@wiking | sonney2k: need a rebase still in that branch | 14:07 |
@iglesiasg | wiking: well I don't get why not, I can sudo make install and the make check-tests should use the python that is intalled in the system, or?? | 14:07 |
@wiking | iglesiasg: cmake with python_modular | 14:07 |
@wiking | iglesiasg: dude.... | 14:08 |
@wiking | iglesiasg: make check-tests is based on ./configure shit | 14:08 |
@iglesiasg | wiking: all right :) | 14:08 |
@wiking | so just fucking try to run a python_modular example | 14:08 |
@sonney2k | iglesiasg, which example fails again? | 14:09 |
@iglesiasg | wiking: lol much coffee this morning? :P | 14:09 |
@sonney2k | iglesiasg, AdReNALiN!! | 14:09 |
@wiking | and make it sure that it try to use the python_modular that is generated/installed by cmake ;) | 14:09 |
@wiking | iglesiasg: yeah + no food | 14:09 |
@wiking | iglesiasg: i'm on this shit since 5am | 14:09 |
@wiking | i want to finish | 14:09 |
@wiking | since it's really near | 14:09 |
@sonney2k | wiking, do it! | 14:09 |
@iglesiasg | sonney2k: the valgrind trace above was for structure_plif_hmsvm_bmrm.py | 14:09 |
@sonney2k | wiking, and merge it dammit | 14:09 |
@wiking | i have to go away now for 1 hour | 14:09 |
@wiking | bbl | 14:10 |
@wiking | iglesiasg: if u have some output let me know via the bug | 14:10 |
@wiking | iglesiasg: dont want to browse the irclog | 14:10 |
@wiking | iglesiasg: just paste it to github | 14:10 |
@iglesiasg | wiking: will do | 14:10 |
@wiking | thjnx heaps | 14:11 |
@wiking | sonney2k: your c++11 checker in ./configure only supports gcc | 14:12 |
@wiking | sonney2k: but no worries i've fucking nailed it in cmake | 14:12 |
@wiking | :P | 14:13 |
@sonney2k | wiking, no it should also work with clang | 14:13 |
@sonney2k | and any other comp | 14:13 |
@wiking | sonney2k: no it wont | 14:13 |
@wiking | sonney2k: as -stdlib=libc++ is missing from the compiler flags | 14:13 |
@wiking | and w/o that it'll die with clang | 14:13 |
@wiking | wont find <atomic> | 14:14 |
@sonney2k | wiking, errm but it is unsing cxx_check so that should be in there | 14:14 |
@wiking | lisitsyn: your spinlock checker with cmake fails on travis.... cannot find it... | 14:15 |
@sonney2k | iglesiasg, I don't that error | 14:16 |
@iglesiasg | sonney2k: what? | 14:16 |
@sonney2k | iglesiasg, I just ran valgrind python structure_plif_hmsvm_bmrm.py | 14:17 |
@iglesiasg | sonney2k: mmm that's funny | 14:18 |
@sonney2k | I see some leaks but these are rather due to pytnon not calling exit_shogun() | 14:18 |
@iglesiasg | sonney2k: I run that yesterday night with the last commit message being "define M_PI if not available" | 14:19 |
@sonney2k | iglesiasg, weird... same version here | 14:19 |
@sonney2k | van51, any updates or still asleep? | 14:20 |
@sonney2k | or beaching :) | 14:20 |
van51 | sonney2k: hey I was waiting for you guys to finish :) | 14:20 |
@iglesiasg | sonney2k: what about structure_discrete_*? | 14:20 |
van51 | sonney2k: I have sent a PR for normalization in the converter | 14:20 |
van51 | sonney2k: I think it's fine | 14:20 |
van51 | sonney2k: even on the webspam they give very close results | 14:21 |
@sonney2k | van51, did it give the same results? | 14:21 |
van51 | sonney2k: w/o normalization y | 14:21 |
van51 | sonney2k: but the converter normalizes every dimension of the vector | 14:21 |
van51 | sonney2k: while the dense dot normalizes the end result | 14:21 |
van51 | sonney2k: so there must be rounding errors or something | 14:21 |
@sonney2k | van51, yeah sure but it should be the same up to flaoting point precision issues | 14:22 |
@sonney2k | van51, well you could just compare things - get the feature vector from dotfeatures and the converted one | 14:22 |
@sonney2k | they must be exactly the same | 14:22 |
van51 | sonney2k: I have added a test case doing that | 14:22 |
van51 | sonney2k: but by using the dot product | 14:23 |
@sonney2k | iglesiasg, no leaks or anything | 14:23 |
@sonney2k | iglesiasg, with that script... | 14:23 |
@sonney2k | van51, dot is not a good way for comparison though there will be minimimal pertubations | 14:24 |
@sonney2k | as in 1e-14 or so | 14:24 |
@sonney2k | van51, did you compute the linear kernel for that? what was the deviation? | 14:24 |
@sonney2k | iglesiasg, maybe you should check again then | 14:25 |
@iglesiasg | sonney2k: yeah | 14:26 |
@iglesiasg | sonney2k: I will make an issue in case they keep on appearing | 14:27 |
@sonney2k | iglesiasg, and assign it to yourself :D | 14:28 |
@sonney2k | ohh nice strong winds - sea I am coming | 14:30 |
van51 | sonney2k: they gave the same results | 14:31 |
van51 | sonney2k: I'm trying to reach my remote machine to copy the results but I can't :/ | 14:31 |
van51 | sonney2k: also by tonight I will have a PR for "quadratic" support in the hashedDoc class | 14:32 |
van51 | sonney2k: what I'm doing actually is a k-skip ngram strategy | 14:32 |
-!- van51 [~van51@athedsl-225195.home.otenet.gr] has quit [Read error: Connection reset by peer] | 15:29 | |
-!- van51 [~van51@athedsl-225195.home.otenet.gr] has joined #shogun | 15:31 | |
-!- az_de [82954e22@gateway/web/freenode/ip.130.149.78.34] has quit [] | 15:39 | |
-!- van51 [~van51@athedsl-225195.home.otenet.gr] has quit [Remote host closed the connection] | 15:46 | |
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 15:50 | |
-!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has quit [Quit: Leaving] | 15:54 | |
-!- van51 [~van51@athedsl-225195.home.otenet.gr] has joined #shogun | 15:59 | |
-!- van51 [~van51@athedsl-225195.home.otenet.gr] has quit [Quit: Leaving.] | 16:07 | |
-!- pickle27 [~Kevin@d67-193-243-174.home3.cgocable.net] has joined #shogun | 16:18 | |
-!- iglesiasg [~iglesias@2001:6b0:1:1da0:8c2b:7874:f378:ae37] has joined #shogun | 16:34 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 16:34 | |
@iglesiasg | sonney2k, around? | 16:34 |
@iglesiasg | sonney2k, the valgrind errors still remain. Just created an issue, let me know about it | 16:42 |
-!- van51 [~van51@athedsl-225195.home.otenet.gr] has joined #shogun | 16:53 | |
@wiking | iglesiasg: any luck? | 16:59 |
@iglesiasg | wiking, yes, I run a few examples without any trouble | 16:59 |
@wiking | iglesiasg: cool thnx then i can add that to the tests straight away | 16:59 |
@wiking | iglesiasg: can u tell me what's the output on your machine of spinlock check with cmake | 17:26 |
@wiking | ? | 17:26 |
@iglesiasg | wiking, yes, sure | 17:26 |
@iglesiasg | wiking, is it enough with the entry that can be read with ccmake? | 17:26 |
@wiking | noup | 17:27 |
@wiking | just run a cmake .. | 17:27 |
@wiking | it should be there | 17:28 |
@wiking | regardless of your cmake state | 17:28 |
@iglesiasg | wiking, all right, give me a second. I am with the uni laptop right now and didn't have hear a copy of the repo to play with cmake | 17:28 |
@iglesiasg | wiking, -- Spinlock support found | 17:29 |
@iglesiasg | I guess that is not very useful | 17:30 |
@iglesiasg | or maybe it is, you tell me :) | 17:30 |
@wiking | yep | 17:30 |
@wiking | that's what i needed | 17:30 |
@iglesiasg | wiking, I am going to try octave here too. Let's see what happens | 17:30 |
@HeikoS | votjakovr: I think evaluate_log_probabilities should be renamed to something that contains "predictive distribution" | 17:30 |
@wiking | iglesiasg: cool | 17:31 |
@HeikoS | votjakovr: since it is a bit misleading | 17:31 |
votjakovr | HeikoS: yep, i agree | 17:32 |
votjakovr | HeikoS: btw is it ok for example: https://dl.dropboxusercontent.com/u/21557917/plot.png | 17:33 |
@HeikoS | votjakovr: very nice! for what is that? | 17:34 |
@HeikoS | gotta go, will be back in 15 | 17:34 |
votjakovr | HeikoS: this is python example for laplace logit/probit classifiers | 17:35 |
@iglesiasg | wiking, we have a new hint: octave 3.2 here was correctly detected | 17:35 |
@wiking | iglesiasg: ok that's something | 17:38 |
@wiking | but now try to build it | 17:38 |
@wiking | i had problems there | 17:38 |
@iglesiasg | wiking, already 25% done | 17:38 |
@iglesiasg | wiking, is there an option to explicitly desactivate doxygen generation? | 17:39 |
-!- van51 [~van51@athedsl-225195.home.otenet.gr] has quit [Quit: Leaving.] | 17:44 | |
@iglesiasg | wiking, make worked fine, make install afterwards too but octave_modular examples fail | 17:44 |
@iglesiasg | wiking, init_shogun undefined | 17:44 |
@iglesiasg | wiking, I noticed this when running make install | 17:44 |
@iglesiasg | /usr/local/lib/lua/liboctave_modular.so | 17:45 |
@iglesiasg | to me it looks weird that liboctave appears inside a lua dir, but who knows | 17:45 |
pickle27 | iglesiasg: lisitsyn my PR is up to date with the style changes | 17:50 |
@wiking | iglesiasg: woah | 17:50 |
@wiking | iglesiasg: ok make install is not working well | 17:50 |
@wiking | iglesiasg: we need there somekind of a magice | 17:50 |
@wiking | to figure out the octave install dir | 17:50 |
@iglesiasg | wiking, so the lua thing is not normal | 17:51 |
@wiking | of course not | 17:51 |
@wiking | but i didn't have the patients for that | 17:51 |
@wiking | so that still need to be fixed | 17:51 |
@wiking | in the cmake | 17:51 |
@iglesiasg | wiking, all right | 17:51 |
@iglesiasg | pickle27, nice, let's check that everything is fine with travis and then we can merge | 17:52 |
@iglesiasg | pickle27, so you solved finally the bugs you mentioned in the original implementation? | 17:52 |
@iglesiasg | gtg, see you later | 17:53 |
-!- iglesiasg [~iglesias@2001:6b0:1:1da0:8c2b:7874:f378:ae37] has quit [Quit: Ex-Chat] | 17:53 | |
@wiking | heheh great bug comment "yes Jedi is fixed now" | 18:03 |
@wiking | :D | 18:03 |
lisitsyn | gsomix! | 18:04 |
lisitsyn | sonney2k: gsomix don't want money :D | 18:05 |
lisitsyn | ohh hushell you too, please submit your gsoc thing | 18:05 |
lisitsyn | ahhh | 18:05 |
lisitsyn | you all | 18:05 |
lisitsyn | :D | 18:05 |
lisitsyn | wiking: what is jedi? | 18:05 |
@HeikoS | votjakovr: very nice, could you make that a non-graphical one too? | 18:06 |
@HeikoS | in fact, I think you dont need to show all the inference methods at once, but just one and then offer replacement lines to switch | 18:06 |
@HeikoS | this way, this can also be extended with EP | 18:07 |
@wiking | lisitsyn: ica realted afaik | 18:13 |
votjakovr | HeikoS: ok, btw what do you think about plotting predictive distribution? i mean, we can choose the line, say y = 0, and plot mean and 95% confidence intervals on predictive distribution | 18:19 |
lisitsyn | wiking: AH :D | 18:21 |
lisitsyn | I thought some software but now I recall | 18:21 |
@HeikoS | votjakovr: but didnt you plot the predictive distribution in the example? | 18:21 |
lisitsyn | funny because I am ehm co-mentoring that project | 18:21 |
votjakovr | HeikoS: i did it:) i mean we can plot confidence | 18:22 |
@HeikoS | votjakovr: ah I see, I think the way you did it is fine, just include a colorbar and mark the decision surface :) | 18:23 |
votjakovr | HeikoS: oh, ok. i'd just like to use mean and variance | 18:29 |
votjakovr | HeikoS: there is p(y=1) on the plot | 18:30 |
@HeikoS | votjakovr: ok | 18:30 |
@HeikoS | votjakovr: remember that these examples should be simple to demonstrate api usage. No fancy plotting involved | 18:30 |
@HeikoS | votjakovr: the cool stuff should go into your ipython notebook example, and there you should do as many cool things as possible : | 18:31 |
@HeikoS | :) | 18:31 |
votjakovr | HeikoS: ok | 18:32 |
@HeikoS | votjakovr: you know, just to find out how things work (the current examples) | 18:33 |
@HeikoS | votjakovr: and the fancy ones: to show off with your cool framework :) to explain how things work, to compare etc etc | 18:33 |
@HeikoS | but fancy examples later, now some simple and then EP :) | 18:33 |
votjakovr | HeikoS: ok, btw didn't you see my "warnings" PR? | 18:34 |
votjakovr | HeikoS: i've fixed some of them | 18:35 |
@HeikoS | votjakovr: I did, sorry, busy day. I will have a look soon | 18:35 |
@HeikoS | Thanks a lot for that! | 18:35 |
votjakovr | HeikoS: alright :) | 18:36 |
-!- thoralf [~thoralf@enki.zib.de] has quit [Quit: Konversation terminated!] | 18:51 | |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 18:54 | |
shogun-notifier- | shogun: Viktor Gal :feature/CMake * 68044ee / / (29 files): https://github.com/shogun-toolbox/shogun/commit/68044ee7c150ebc78c6d842d31fd7a72b9c0db19 | 18:54 |
shogun-notifier- | shogun: Add C++11 cmake detection scripts | 18:54 |
shogun-notifier- | shogun: Fix lua modular installation directory | 18:54 |
shogun-notifier- | shogun: Viktor Gal :feature/CMake * 0ec5151 / .travis.yml: https://github.com/shogun-toolbox/shogun/commit/0ec5151d391ff2e1c0ae48318066234f1050295f | 18:54 |
shogun-notifier- | shogun: Travis: use gcc for octave_modular compilation | 18:54 |
lisitsyn | wiking: you're doing great stuff with cmake | 18:56 |
@wiking | mmm soon soon | 18:56 |
@wiking | i though this fucking tests should go faster | 18:56 |
@wiking | i'm having problem reseting the compiler flags at one point in cmake :S | 18:57 |
hushell | lisitsyn: submitted :) | 19:13 |
hushell | lisitsyn: Thanks for reminder | 19:14 |
-!- travis-ci [~travis-ci@ec2-23-22-12-85.compute-1.amazonaws.com] has joined #shogun | 19:51 | |
travis-ci | [travis-ci] it's Viktor Gal'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/9701078 | 19:51 |
-!- travis-ci [~travis-ci@ec2-23-22-12-85.compute-1.amazonaws.com] has left #shogun [] | 19:51 | |
-!- foulwall` [~user@110.17.4.161] has left #shogun ["ERC Version 5.3 (IRC client for Emacs)"] | 19:59 | |
-!- van51 [~van51@athedsl-225195.home.otenet.gr] has joined #shogun | 20:06 | |
-!- gsomix [~gsomix@109.169.241.214] has joined #shogun | 20:09 | |
gsomix | good evening | 20:10 |
gsomix | just returned from big city | 20:10 |
gsomix | *just have | 20:10 |
-!- lisitsyn [~lisitsin@mxs.kg.ru] has quit [Quit: Leaving.] | 20:10 | |
-!- foulwall [~user@110.17.4.161] has joined #shogun | 20:41 | |
-!- lisitsyn [~lisitsyn@213.87.128.66] has joined #shogun | 20:43 | |
foulwall | sonney2k , I solved javascript zip extracting, but got some little bug on display the pic, I'm trying to solve it | 20:43 |
shogun-notifier- | shogun: Roman Votyakov :develop * 1559b33 / examples/undocumented/python_modular/graphical/classifier_gaussian_process_binary_classification.py: https://github.com/shogun-toolbox/shogun/commit/1559b338a2ee9410bd1885fe0363ba7c99d04f28 | 20:55 |
shogun-notifier- | shogun: add very basic python graphical example of GP binary classification | 20:55 |
shogun-notifier- | shogun: Heiko Strathmann :develop * ba3603f / examples/undocumented/python_modular/graphical/classifier_gaussian_process_binary_classification.py: https://github.com/shogun-toolbox/shogun/commit/ba3603fff4043639ef841db490646ae4f45f07f3 | 20:55 |
shogun-notifier- | shogun: Merge pull request #1340 from votjakovr/feature/gp_binary_classification | 20:55 |
shogun-notifier- | shogun: | 20:55 |
shogun-notifier- | shogun: Added very basic python graphical example of GP binary classification | 20:55 |
@HeikoS | votjakovr: hey, you might like this here: https://github.com/shogun-toolbox/shogun/pull/1341 | 21:04 |
@HeikoS | votjakovr: I use that for my research and it is massively based on your work ! :) | 21:05 |
@HeikoS | going home now, bye! | 21:05 |
-!- HeikoS [~heiko@nat-182-213.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.] | 21:05 | |
@wiking | lisitsyn: wazzzaaaaaaaaaaaaa | 21:07 |
lisitsyn | wiking: hey! | 21:07 |
lisitsyn | wiking: any help with cmake? I have some power left - just got home | 21:08 |
@wiking | lisitsyn: so here i am | 21:09 |
@wiking | lisitsyn: libshogun examples | 21:09 |
@wiking | lisitsyn: trying to add all the .cpps as a new add_executable | 21:09 |
@wiking | which would all be good | 21:09 |
@wiking | apart from the fact that i cannot clear the compiler flags | 21:09 |
lisitsyn | wiking: ahh yeah | 21:09 |
lisitsyn | could be a problem | 21:10 |
shogun-buildbot | build #1132 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1132 blamelist: Roman Votyakov <votjakovr@gmail.com> | 21:10 |
@wiking | which means it's trying to compile the stuff like this | 21:10 |
@wiking | /usr/bin/c++ -DDSFMT_MEXP=19937 -DHAVE_ARPACK -DHAVE_CXX11_ATOMIC -DHAVE_DOXYGEN -DHAVE_EIGEN3 -DHAVE_HDF5 -DHAVE_LAPACK -DHAVE_LARGEFILE -DHAVE_LGAMMAL -DHAVE_LOG2 -DHAVE_POWL -DHAVE_PTHREAD -DHAVE_PYTHON -DHAVE_SQRTL -DHAVE_SSE2 -DHAVE_XML -DLOFASZ -DSFMT_MEXP=19937 -DSHOGUN -DSWIG_TYPE_TABLE=shogun -DUSE_BIGSTATES -DUSE_BOOL -DUSE_BZIP2 -DUSE_CHAR -DUSE_FLOAT32 -DUSE_FLOAT64 -DUSE_GLPK -DUSE_GZIP -DUSE_HMMCACHE -DUSE_INT32 -DUSE_INT64 -DUSE_LZMA -D | 21:10 |
@wiking | and obviously this is not what should happen | 21:10 |
lisitsyn | wiking: http://www.cmake.org/pipermail/cmake/2010-April/036664.html | 21:10 |
lisitsyn | wiking: what about that? | 21:10 |
@wiking | reading | 21:11 |
@wiking | lisitsyn: yeah tried that | 21:12 |
@wiking | it appends to the list | 21:12 |
lisitsyn | argh | 21:12 |
@wiking | Additional flags to use when compiling this target's sources. | 21:13 |
@wiking | The COMPILE_FLAGS property sets additional compiler flags used to build sources within the target. Use COMPILE_DEFINITIONS to pass additional preprocessor definitions. | 21:13 |
@wiking | see 'additional' | 21:13 |
-!- van51 [~van51@athedsl-225195.home.otenet.gr] has quit [Quit: Leaving.] | 21:13 | |
lisitsyn | wiking: yes yes got it | 21:13 |
@wiking | lisitsyn: so of course there's a way around | 21:14 |
lisitsyn | wiking: how? | 21:14 |
@wiking | but that requires a minor refactoring of this fucking thing | 21:14 |
@wiking | lisitsyn: well create a custom cmake variable and store all the compiler flags and definitions in that | 21:15 |
lisitsyn | wiking: and add them each time? | 21:15 |
@wiking | yes | 21:15 |
lisitsyn | would be ok I think | 21:15 |
@wiking | so for the target that requires all those shit | 21:15 |
@wiking | then do the set_target_properties | 21:16 |
@wiking | otherwise dont | 21:16 |
@wiking | which would be 'all the current targets apart the libshogun-examples target' | 21:16 |
@wiking | i hope u feel the irony | 21:16 |
@wiking | i.e. for one fucking target we have to redo now everything :) | 21:16 |
lisitsyn | wiking: hah yes | 21:17 |
@wiking | apart from this if u wanna help | 21:17 |
pickle27 | wiking: lisitsyn is it neccessary to use cmake for the examples? | 21:17 |
@wiking | pickle27: well it would be good | 21:17 |
lisitsyn | pickle27: what else? | 21:17 |
@wiking | pickle27: since then we can package them as well | 21:17 |
pickle27 | I seem to recall opencv uses cmake for the lib and a reg makefile for the examples | 21:17 |
@wiking | pickle27: fuck ocv :D | 21:18 |
@wiking | lisitsyn: so what i was saying | 21:18 |
lisitsyn | wiking: yes? | 21:18 |
@wiking | lisitsyn: can u find out how we can add to ctest non-binary tests | 21:18 |
@wiking | lisitsyn: e.g. a python test or a java test? | 21:18 |
@wiking | if u know what i mean | 21:18 |
@wiking | because until now i was doing | 21:19 |
lisitsyn | wiking: yeah I'll check | 21:19 |
@wiking | add_executable(targetname srcs) | 21:19 |
@wiking | add_test(<whatevertestname targetname) | 21:19 |
@wiking | but i dont know if for example we can do this | 21:19 |
lisitsyn | wiking: yes that's the common way | 21:19 |
@wiking | like | 21:19 |
@wiking | add_custom_target(OUTPUT? whatever COMMAND PYTHON_EXECUTABLE pythonscript.py ...) | 21:20 |
@wiking | and then | 21:20 |
@wiking | add_test(<wtf> whatever) | 21:20 |
lisitsyn | okay I'll try to do that locally | 21:21 |
@wiking | lisitsyn: nono | 21:21 |
@wiking | here's your friend | 21:22 |
@wiking | http://cmake.org/cmake/help/v2.8.8/cmake.html#command:add_test | 21:22 |
@wiking | lisitsyn: can u test the more advanced add_test macro? | 21:22 |
@wiking | add_test(NAME <name> [CONFIGURATIONS [Debug|Release|...]] [WORKING_DIRECTORY dir] COMMAND <command> [arg1 [arg2 ...]]) | 21:22 |
@wiking | this should do it | 21:22 |
@wiking | see COMMAND there | 21:22 |
lisitsyn | yeah that's what I wanted to do | 21:22 |
@wiking | but would be great if u could test it | 21:22 |
@wiking | thnx | 21:22 |
@wiking | let me know how's that working out | 21:22 |
lisitsyn | alright | 21:23 |
@wiking | in the meanwhile i'll do the fucking refactoring :) | 21:23 |
@wiking | as i was googling about this for a long time now (i.e. 3 hours) w/o success -- reseting compiler flags | 21:23 |
@sonney2k | foulwall, why javascript zip extracting? why not on the server side serve a file inside a zip? | 21:31 |
votjakovr | sonney2k: hi! please have a look at my "silence warnings" PR | 21:38 |
@sonney2k | votjakovr, did already | 21:39 |
@sonney2k | votjakovr, is this for clang warnings? | 21:40 |
votjakovr | sonney2k: yep | 21:41 |
shogun-notifier- | shogun: Kevin :develop * b9771de / / (5 files): https://github.com/shogun-toolbox/shogun/commit/b9771de1a416572f9a5e236c172854e1648da662 | 21:41 |
shogun-notifier- | shogun: added QDiag and Jedi AJD methods | 21:41 |
shogun-notifier- | shogun: Kevin :develop * 42b7d5b / tests/unit/mathematics/ajd/JADiagOrth_unittest.cc: https://github.com/shogun-toolbox/shogun/commit/42b7d5b82a905c7ab3407523324a1a3dd1087431 | 21:41 |
shogun-notifier- | shogun: added JADiagOrth unit test | 21:41 |
shogun-notifier- | shogun: Kevin :develop * 4625e4e / / (9 files): https://github.com/shogun-toolbox/shogun/commit/4625e4ecd8da9cb114cee08fbc276419890a6345 | 21:41 |
shogun-notifier- | shogun: fixed Jedi, added Jedi unit test and some cleanup to all the ajd headers | 21:41 |
shogun-notifier- | shogun: Kevin :develop * e33f051 / src/shogun/ (7 files): https://github.com/shogun-toolbox/shogun/commit/e33f051a95d3ddd8808f25526766936b61c1fb1c | 21:41 |
shogun-notifier- | shogun: coding style fixes in AJD | 21:41 |
shogun-notifier- | shogun: Kevin :develop * b6b17e6 / src/shogun/mathematics/ajd/ (6 files): https://github.com/shogun-toolbox/shogun/commit/b6b17e6f8948001b310b3910cdd3a11664ec4c31 | 21:41 |
shogun-notifier- | shogun: ajd double -> float64_t | 21:41 |
shogun-notifier- | shogun: Kevin :develop * 380249f / tests/unit/mathematics/ajd/ (5 files): https://github.com/shogun-toolbox/shogun/commit/380249f55101e9d61903bd170efc36e7eb08a1e5 | 21:41 |
shogun-notifier- | shogun: coding style changes in ajd unit tests | 21:41 |
shogun-notifier- | shogun: Kevin :develop * ee75cd5 / src/shogun/mathematics/ajd/FFDiag.cpp,src/shogun/mathematics/ajd/Jedi.cpp: https://github.com/shogun-toolbox/shogun/commit/ee75cd50962df9e5edaf9d213712af9d2331d096 | 21:41 |
shogun-notifier- | shogun: ajd updated to cpp style loops | 21:41 |
shogun-notifier- | shogun: Sergey Lisitsyn :develop * fc13467 / / (18 files): https://github.com/shogun-toolbox/shogun/commit/fc13467a125e150f9f2106f95a3bcef6aea82048 | 21:41 |
shogun-notifier- | shogun: Merge pull request #1326 from pickle27/develop | 21:41 |
shogun-notifier- | shogun: | 21:41 |
shogun-notifier- | shogun: added QDiag and Jedi AJD methods | 21:41 |
shogun-buildbot | build #1133 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1133 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 21:44 |
-!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has quit [Ping timeout: 245 seconds] | 21:45 | |
shogun-buildbot | build #1134 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1134 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com>, Kevin <kevinhughes27@gmail.com> | 21:57 |
shogun-notifier- | shogun: Roman Votyakov :develop * d864ec6 / src/shogun/ (7 files): https://github.com/shogun-toolbox/shogun/commit/d864ec61d49d8887f24256da2a17dcac51178d06 | 22:03 |
shogun-notifier- | shogun: silence some warnings | 22:03 |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * 67344b1 / src/shogun/ (7 files): https://github.com/shogun-toolbox/shogun/commit/67344b147f4a58ef8fbdf7b23065e08c27e87fcf | 22:03 |
shogun-notifier- | shogun: Merge pull request #1336 from votjakovr/develop | 22:03 |
shogun-notifier- | shogun: | 22:04 |
shogun-notifier- | shogun: Fix various errors and warnings detected by clang. | 22:04 |
@sonney2k | votjakovr, excellent patch! | 22:04 |
@sonney2k | votjakovr, more of that kind please :) | 22:04 |
votjakovr | sonney2k: thank you :) ok, i'll keep going | 22:05 |
-!- lisitsyn1 [~lisitsyn@213.87.128.66] has joined #shogun | 22:08 | |
-!- lisitsyn [~lisitsyn@213.87.128.66] has quit [Read error: Connection reset by peer] | 22:08 | |
-!- travis-ci [~travis-ci@ec2-23-20-234-231.compute-1.amazonaws.com] has joined #shogun | 22:12 | |
travis-ci | [travis-ci] it's Heiko Strathmann'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/9705804 | 22:12 |
-!- travis-ci [~travis-ci@ec2-23-20-234-231.compute-1.amazonaws.com] has left #shogun [] | 22:12 | |
@wiking | lisitsyn1: ok i think i'm almost there ;) | 22:13 |
@wiking | good that i wrote modular interface handling modular in cmake ;P | 22:13 |
lisitsyn1 | wiking: well it works when you just write the command here | 22:13 |
lisitsyn1 | I just tried | 22:14 |
@wiking | cool | 22:15 |
lisitsyn1 | wiking: though we'd have to use sth like $PYTHON | 22:15 |
lisitsyn1 | not just python blabla.py | 22:15 |
lisitsyn1 | I guess | 22:15 |
@wiking | tyeye of course | 22:15 |
@wiking | but that's handled by FindPythonInterperter | 22:16 |
@wiking | that defines ${PYTHON_EXECUTABLE} | 22:16 |
@wiking | so that's all cool | 22:16 |
@wiking | same with java and csharp... | 22:16 |
@wiking | as well as ruby and the others | 22:16 |
lisitsyn1 | add_test(NAME shit COMMAND "${PYTHON_EXECUTABLE} ${TEST_SCRIPT}") | 22:16 |
lisitsyn1 | essentially that's it I think | 22:17 |
@wiking | cool | 22:17 |
@wiking | good | 22:17 |
lisitsyn1 | may be some paths stuff | 22:17 |
@wiking | yeye that's alright ;) | 22:17 |
lisitsyn1 | wiking: can I help with anything else here then? | 22:17 |
@wiking | i'm in the last stage of this refactoring | 22:17 |
@wiking | yes it worked! \o/ | 22:17 |
@wiking | ok this is cooool | 22:17 |
@wiking | cmake is really amazing ;) | 22:17 |
@wiking | lisitsyn1: have i told you that i've created a .dmg osx package | 22:18 |
@wiking | of shogun | 22:18 |
lisitsyn1 | wiking: yeah with cpack | 22:18 |
@wiking | a native osx package :) | 22:18 |
@wiking | and it was just out of box | 22:18 |
lisitsyn1 | I am lame with osx | 22:18 |
@wiking | no worries | 22:18 |
@wiking | it's just that after this | 22:18 |
lisitsyn1 | how native it is? | 22:18 |
@wiking | totally | 22:18 |
lisitsyn1 | like deb for debian? | 22:18 |
@wiking | the package is created by the native package maker of osx | 22:18 |
lisitsyn1 | so you just download it | 22:19 |
-!- lisitsyn1 is now known as lisitsyn | 22:19 | |
@wiking | double click | 22:19 |
lisitsyn | double click or whatever | 22:19 |
@wiking | and tada | 22:19 |
lisitsyn | and it is here | 22:19 |
@wiking | yes yes | 22:19 |
lisitsyn | :D | 22:19 |
lisitsyn | okay it would make Heiko happy | 22:19 |
@wiking | cd /Users/wiking/shogun/build/examples/undocumented/libshogun && /usr/bin/c++ -g -o CMakeFiles/basic_minimal.dir/basic_minimal.cpp.o -c /Users/wiking/shogun/examples/undocumented/libshogun/basic_minimal.cpp | 22:19 |
@wiking | so now i have this ;P | 22:19 |
@wiking | ah shit i have to fix unit-test flags | 22:20 |
@wiking | just a sec | 22:20 |
@wiking | ok that's not generated yet with all the compiler flags | 22:20 |
@wiking | lisitsyn: yeah i mean after this we can setup our own repos for rpm, deb | 22:20 |
@wiking | and just fucking upload there the nightlies | 22:21 |
lisitsyn | wiking: is there exe? | 22:21 |
@wiking | lisitsyn: ? | 22:21 |
@wiking | you mean if we could use MSVC? | 22:21 |
@wiking | :) | 22:21 |
lisitsyn | wiking: some setup.exe for poor windows users? | 22:21 |
@wiking | lisitsyn: yes yes | 22:21 |
@wiking | NSIS | 22:21 |
@wiking | generator | 22:21 |
lisitsyn | I feel sorry people use windows but .exe stuff would be cool still | 22:22 |
@wiking | lisitsyn: http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack | 22:23 |
@wiking | lisitsyn: check the screenshots | 22:23 |
@wiking | ;) | 22:23 |
@wiking | i've already defined the components | 22:24 |
@wiking | so that's done ;P | 22:24 |
@wiking | make package creates libshogun libshogun_headers and <whatever>_modular_interface packages | 22:24 |
@wiking | or of course a monolitic tar.gz/bz2 | 22:25 |
@wiking | couldnt test it yet on a deb machine | 22:25 |
@wiking | as i dont have access to it now | 22:25 |
@wiking | anyhow we should have sooooonish the make tests ;P | 22:25 |
@wiking | lisitsyn: ah if u wanna play around: find some cool cmake scripts on github and elsewhere to detect compiler flags | 22:26 |
@wiking | you know for optimizations | 22:26 |
@wiking | like is sse2 available et | 22:26 |
@wiking | etc | 22:26 |
lisitsyn | wiking: okay I am on it | 22:26 |
lisitsyn | wiking: well | 22:26 |
@wiking | for sure there's heaps | 22:26 |
lisitsyn | sse | 22:26 |
lisitsyn | I would just let compiler decide | 22:27 |
@wiking | and i've even saw a cpuid.c based cmake script | 22:27 |
lisitsyn | really | 22:27 |
lisitsyn | compilers are ok already | 22:27 |
lisitsyn | they know what cpu it is | 22:27 |
lisitsyn | wiking: I think we should drop that thing at all | 22:27 |
@wiking | so go with the | 22:27 |
@wiking | -native | 22:27 |
@wiking | -march=native ? | 22:27 |
-!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has joined #shogun | 22:27 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 22:27 | |
lisitsyn | wiking: yeah I'd do that | 22:27 |
@wiking | kk | 22:27 |
@iglesiasg | hello hello | 22:27 |
lisitsyn | wiking: I'll check what native skips | 22:28 |
@wiking | mmm i wonder what detection i still miss then from ./configure | 22:28 |
@wiking | ok cool i'll finish now the unit testing | 22:28 |
lisitsyn | sonney2k: do you think we need these CPU deals? | 22:28 |
lisitsyn | iglesiasg: hey | 22:28 |
@wiking | and then go back to make tests | 22:28 |
@wiking | lisitsyn: ah there's one task... octave_modular | 22:28 |
@wiking | lisitsyn: where the fuck the created modular interface binary should be installed | 22:29 |
@wiking | and how we can find that out from cmake :P | 22:29 |
lisitsyn | oh okay | 22:29 |
lisitsyn | let me check that | 22:29 |
-!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has left #shogun ["Fallen asleep!"] | 22:31 | |
@wiking | lisitsyn: what do u think about having gmock/gtest in cmake with http://www.cmake.org/cmake/help/v2.8.8/cmake.html#module%3aExternalProject | 22:42 |
@wiking | ? | 22:42 |
lisitsyn | wiking: let me recall how I did that in tapkee | 22:43 |
@wiking | although i should somehow enable the case where one has already the gmock/gtest localhost... so one does not really need to have internet connection for having unit testing | 22:45 |
lisitsyn | wiking: I wasn't very satisfied with gtest finder btw | 22:46 |
lisitsyn | I found a few finders and they all were a bit weird | 22:47 |
@wiking | lisitsyn: ah yeah they are shit | 22:47 |
@wiking | i didnt even bothered | 22:47 |
@wiking | lisitsyn: but as u can see with ExternalProject we can just tell cmake to download the src from code.google.com | 22:50 |
lisitsyn | wiking: yes | 22:50 |
lisitsyn | wiking: what about trying some default location or user defined dir | 22:51 |
lisitsyn | else download | 22:51 |
@wiking | yeah something like that | 22:53 |
@sonney2k | wiking, lisitsyn yeah -march=native but IIRC we needed -msse2 -msse3 -msse or so too - better check | 22:54 |
@wiking | sonney2k: what about -fvectorize-tree? | 22:54 |
lisitsyn | wiking: sonney2k: we should revise flags not included to O3 | 22:54 |
@sonney2k | and also warning flags | 22:55 |
@sonney2k | some of these don't exist on some compilers | 22:55 |
@wiking | sonney2k: although that is enabled in clang in -O3 | 22:56 |
shogun-buildbot | build #1135 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1135 blamelist: Soeren Sonnenburg <sonne@debian.org>, Roman Votyakov <votjakovr@gmail.com> | 22:56 |
@wiking | lisitsyn: gcc -v -Q -O3 -march=native --help=target | 22:58 |
@wiking | lisitsyn: all the sse instructions are enabled that are available for my cpu | 22:59 |
lisitsyn | wiking: well all SSEs and AVX | 22:59 |
lisitsyn | and mtune is correct | 22:59 |
lisitsyn | not all SSEs though | 23:00 |
lisitsyn | SSE5 | 23:00 |
lisitsyn | :D | 23:00 |
lisitsyn | what is SSE5 | 23:00 |
@wiking | dunno | 23:00 |
lisitsyn | is it supported by any processor? | 23:00 |
lisitsyn | ah whatever | 23:00 |
lisitsyn | wiking: anyway I see most of the things are here already | 23:00 |
lisitsyn | so not sure it makes a lot of sense | 23:00 |
lisitsyn | to tune stuff | 23:00 |
@wiking | lisitsyn: ok let's go with "-march=native" | 23:01 |
@wiking | and if somebody has a better idea | 23:01 |
@wiking | he can contribute | 23:01 |
@wiking | lisitsyn sonney2k do we want that in DEBUG mode as well? | 23:01 |
@wiking | or let's go on with the DISABLE_OPTIMIZATION option and then we won't have that | 23:01 |
@sonney2k | wiking, we also need support for generic cpu flags as in -O2 and no further tuning | 23:02 |
@sonney2k | wiking, I would always keep -g | 23:02 |
lisitsyn | wiking: I guess that's done through custom targets | 23:02 |
lisitsyn | like release debug | 23:02 |
@wiking | lisitsyn: no not really ;) | 23:02 |
@wiking | lisitsyn: one has to do that | 23:02 |
@wiking | lisitsyn: realase by default won't have -g i think | 23:03 |
lisitsyn | wiking: we can change it | 23:03 |
@wiking | and realase will have -O(something) | 23:03 |
@wiking | lisitsyn: yep indeed | 23:03 |
@wiking | but this "-march=native" should be possible to disable | 23:03 |
@wiking | so i'll add a cmake variable | 23:03 |
@wiking | DISABLE_OPTIMIZATIONS | 23:03 |
@wiking | or something like that | 23:03 |
@sonney2k | wiking, please make it have -g always | 23:03 |
@wiking | sonney2k: o | 23:04 |
@wiking | k | 23:04 |
@sonney2k | if someone wants to strip of symbols he can do it later with strip | 23:04 |
@sonney2k | iglesiasg, I figured that doing | 23:05 |
@sonney2k | model = TwoStateModel.simulate_data(num_examples, example_length, num_features, num_noise_features) | 23:05 |
@sonney2k | sosvm = DualLibQPBMSOSVM(model, model.get_labels(), 5000.0) | 23:05 |
@sonney2k | is enough to trigger the issue | 23:05 |
@iglesiasg | sonney2k: oh, I see | 23:06 |
@iglesiasg | sonney2k: did you see if it also appears in libshogun interface? | 23:06 |
@sonney2k | iglesiasg, no didn't | 23:06 |
@wiking | is this broken | 23:07 |
@wiking | classifier_nearest_centroid.cpp | 23:07 |
@wiking | ? | 23:07 |
@wiking | seems so | 23:07 |
-!- pickle27 [~Kevin@d67-193-243-174.home3.cgocable.net] has quit [Quit: Leaving] | 23:09 | |
@sonney2k | iglesiasg, any ideas how this is possible? | 23:18 |
@wiking | sonney2k lisitsyn would u mind if test would be built by make command? | 23:19 |
lisitsyn | wiking: why? | 23:19 |
@wiking | one one could disable example build | 23:19 |
@wiking | lisitsyn: http://stackoverflow.com/questions/733475/cmake-ctest-make-test-doesnt-build-tests | 23:20 |
@wiking | coz it's tricky ;) | 23:20 |
@wiking | although i can add that trick... | 23:20 |
@iglesiasg | sonney2k: not really, this was actually the party I studied and fixed something last week | 23:21 |
@iglesiasg | sonney2k: it seems I have to check it further | 23:21 |
lisitsyn | wiking: crazy! | 23:21 |
@sonney2k | iglesiasg, I mean doing | 23:22 |
@wiking | lisitsyn: indeed | 23:22 |
@sonney2k | CTwoStateModel* tsm = new CTwoStateModel(); | 23:22 |
@sonney2k | CHMSVMModel* model = tsm->simulate_data(100,250,10,2); | 23:22 |
@sonney2k | CStructuredLabels* labels = model->get_labels(); | 23:22 |
@sonney2k | CDualLibQPBMSOSVM* sosvm = new CDualLibQPBMSOSVM(model, labels, 5000.0); | 23:22 |
@sonney2k | vs | 23:22 |
@sonney2k | model = TwoStateModel.simulate_data(num_examples, example_length, num_features, num_noise_features) | 23:22 |
@sonney2k | sosvm = DualLibQPBMSOSVM(model, model.get_labels(), 5000.0) | 23:22 |
@sonney2k | should not make a difference | 23:22 |
@iglesiasg | sonney2k: aah ok that the issue doesn't appear in C++ | 23:23 |
@iglesiasg | sonney2k: I read as you didn't check that | 23:23 |
@sonney2k | iglesiasg, sure I did | 23:23 |
@sonney2k | iglesiasg, but it does not appear | 23:23 |
@sonney2k | there | 23:23 |
@sonney2k | but just python | 23:23 |
@iglesiasg | understood | 23:23 |
@sonney2k | but why??? | 23:24 |
@iglesiasg | it shouldn't matter indeed | 23:24 |
@iglesiasg | sonney2k: do you find weird the model.get_labels() thing? | 23:24 |
@iglesiasg | instead of doing something like | 23:24 |
@iglesiasg | Labels labels = model.get_labels() | 23:24 |
@iglesiasg | DualLibQPBMSOSVM(model, labels, 5000.0) | 23:25 |
@iglesiasg | arggh, labels = model.get_labels() | 23:25 |
@wiking | lisitsyn: so it's either the trick or the default stuff... i think on some level having the example built by default will somehow make people aware if there was really something going wrong with the modifications | 23:27 |
lisitsyn | wiking: yeah | 23:29 |
lisitsyn | may be it makes sense to build everything | 23:29 |
@wiking | lisitsyn: i mean if u disalbe BUILD_EXAMPLES variable in cmake then one can turn it off ;) | 23:32 |
lisitsyn | yeah | 23:32 |
@wiking | but i'll leave that option turned ON by default | 23:32 |
-!- zxtx [~zv@rrcs-76-79-81-162.west.biz.rr.com] has joined #shogun | 23:35 | |
@wiking | ok i don't know how to make make test more verbose | 23:36 |
lisitsyn | wiking: what verbosity? | 23:40 |
@wiking | ok no worries i've figured it out | 23:44 |
@wiking | woah output looks cool | 23:45 |
lisitsyn | wiking: like ctest -VV? | 23:45 |
@wiking | lisitsyn: http://pastebin.com/zTXTpJHW | 23:45 |
@wiking | solution for more verbose log: http://stackoverflow.com/questions/5709914/using-cmake-how-do-i-get-verbose-output-from-ctest | 23:47 |
lisitsyn | wiking: ctest can also send reports and etc | 23:47 |
lisitsyn | no idea if we can use it | 23:48 |
@wiking | lisitsyn: yeah i saw | 23:48 |
@wiking | well at least we have the option for it | 23:48 |
@wiking | none the less | 23:48 |
@wiking | it's working | 23:48 |
@wiking | ;) | 23:48 |
@wiking | lisitsyn: do u know how to group ctest? | 23:48 |
lisitsyn | wiking: group? | 23:48 |
@wiking | so that i have like libshogun-example and then under that i have the various tests | 23:48 |
lisitsyn | ahh | 23:49 |
lisitsyn | no I don't know how this is done | 23:49 |
@wiking | nevermind it's good like this | 23:49 |
@wiking | i'll add all the example runs with ctest | 23:49 |
@wiking | as well as integration test | 23:50 |
-!- lisitsyn [~lisitsyn@213.87.128.66] has left #shogun [] | 23:51 | |
--- Log closed Thu Aug 01 00:00:56 2013 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!