| --- Log opened Wed Sep 11 00:00:54 2013 | ||
| -!- travis-ci [~travis-ci@ec2-54-234-113-13.compute-1.amazonaws.com] has joined #shogun | 00:25 | |
| travis-ci | [travis-ci] it's Fernando Iglesias'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/11210278 | 00:25 |
|---|---|---|
| -!- travis-ci [~travis-ci@ec2-54-234-113-13.compute-1.amazonaws.com] has left #shogun [] | 00:25 | |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 00:53 | |
| -!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has quit [Quit: Ex-Chat] | 01:31 | |
| -!- hushell [~hushell@8-92.ptpg.oregonstate.edu] has quit [Ping timeout: 245 seconds] | 01:45 | |
| -!- hushell [~hushell@c-98-232-178-161.hsd1.or.comcast.net] has joined #shogun | 02:04 | |
| -!- sonne|osx_ [~sonne@f053034179.adsl.alicedsl.de] has joined #shogun | 03:20 | |
| -!- sonne|osx [~sonne@f053039166.adsl.alicedsl.de] has quit [Ping timeout: 245 seconds] | 03:22 | |
| -!- sonne|osx_ is now known as sonne|osx | 03:22 | |
| -!- zxtx [~zv@rrcs-76-79-81-162.west.biz.rr.com] has quit [Ping timeout: 260 seconds] | 03:58 | |
| -!- pickle27 [~Kevin@199.119.128.114] has quit [Quit: Leaving] | 04:33 | |
| -!- foulwall [~zhengyang@114.255.40.22] has quit [Remote host closed the connection] | 06:08 | |
| -!- foulwall [~zhengyang@114.255.40.22] has joined #shogun | 07:02 | |
| -!- sonne|osx [~sonne@f053034179.adsl.alicedsl.de] has quit [Quit: sonne|osx] | 07:25 | |
| -!- sonne|osx [~sonne@82.113.106.106] has joined #shogun | 08:20 | |
| sonne|osx | shogun-buildbot: force build --branch=develop 'deb3 - modular_interfaces' | 08:29 |
| shogun-buildbot | build forced [ETA 33m29s] | 08:29 |
| shogun-buildbot | I'll give a shout when the build finishes | 08:29 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 08:44 | |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * 8dc2b37 / src/shogun/base/DynArray.h: https://github.com/shogun-toolbox/shogun/commit/8dc2b37940f62e210eeba0d198c862ac3b3f78d0 | 08:44 |
| shogun-notifier- | shogun: fix potential memory leak in dynarray | 08:44 |
| -!- sonne|osx [~sonne@82.113.106.106] has quit [Quit: sonne|osx] | 08:45 | |
| shogun-buildbot | build #1776 of deb3 - modular_interfaces is complete: Failure [failed test libshogun] Build details are at http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/1776 | 09:00 |
| @wiking | sonney2k: https://travis-ci.org/shogun-toolbox/shogun/builds/11225734 | 09:11 |
| -!- lisitsyn [~lisitsyn@fb2-lo1.global63.net] has quit [Ping timeout: 245 seconds] | 09:14 | |
| -!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has joined #shogun | 09:18 | |
| sonne|work | wiking: ahh ok | 09:24 |
| -!- lisitsyn [~lisitsyn@fb2-lo1.global63.net] has joined #shogun | 09:27 | |
| shogun-buildbot | build #2088 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/2088 blamelist: Soeren Sonnenburg <sonne@debian.org> | 09:36 |
| -!- lisitsyn [~lisitsyn@fb2-lo1.global63.net] has quit [Quit: Leaving.] | 09:39 | |
| -!- travis-ci [~travis-ci@ec2-54-234-113-13.compute-1.amazonaws.com] has joined #shogun | 09:44 | |
| 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/11225734 | 09:44 |
| -!- travis-ci [~travis-ci@ec2-54-234-113-13.compute-1.amazonaws.com] has left #shogun [] | 09:44 | |
| @wiking | sonne|work: i have a question. yesterday i've discovered some error in a unit test when i've compiled with thread-sanitizer: basically there's a class which has a SGVector and in it's constructor the init function did this: vector.resize_vector(0) this broke the unit test. unfortunately the error was a meaningless execption. but if i changed that line to vector = SGVector<type>(); then the error disappeared. ideas why this could be? and why it only happ | 09:50 |
| @wiking | thoralf: ^ if u are around | 09:50 |
| -!- lisitsyn [~lisitsin@mxs.kg.ru] has joined #shogun | 09:52 | |
| sonne|work | wiking: the correct fix is SGVEctor<type>() | 10:12 |
| sonne|work | wiking: the other is actually a BUG!! | 10:12 |
| @wiking | ok i get that | 10:13 |
| @wiking | but why only comes out if i enable thread-sanitizing? :D | 10:13 |
| @wiking | even more, what type of bug is that? :D | 10:13 |
| @wiking | i mean actually then it's good to have that buildbot running (thread analysis) as this bug was not catch any other way.... :P | 10:14 |
| sonne|work | wiking: well the resize(0) basically frees the memory of the sgvector I guess accidentally | 10:14 |
| @wiking | so this already justifies that bot's existing :P | 10:15 |
| @wiking | sonne|work: btw -fPIC should be always set for gmock/gtest libraries right? | 10:16 |
| sonne|work | wiking: only on PIC architecturs like AMD64 | 10:17 |
| sonne|work | wiking: on x86 it is not necessary | 10:17 |
| sonne|work | (probably the only exception) | 10:17 |
| @wiking | sonne|work: but if we 'always' have it that doesn't hurt, right? | 10:17 |
| sonne|work | wiking: except that you get a gazillion of warnings | 10:22 |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Quit: buildmaster reconfigured: bot disconnecting] | 10:45 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun | 10:45 | |
| @wiking | sonne|work: woah man | 10:46 |
| @wiking | we have like kazillions of bugs | 10:46 |
| @wiking | :))) | 10:46 |
| -!- besser82 [~besser82@77-22-24-208-dynip.superkabel.de] has joined #shogun | 10:50 | |
| -!- besser82 is now known as Guest73782 | 10:50 | |
| -!- Guest73782 [~besser82@77-22-24-208-dynip.superkabel.de] has quit [Client Quit] | 10:50 | |
| -!- besser82|laptop [~besser82@77-22-24-208-dynip.superkabel.de] has joined #shogun | 10:50 | |
| -!- besser82|laptop [~besser82@77-22-24-208-dynip.superkabel.de] has quit [Changing host] | 10:50 | |
| -!- besser82|laptop [~besser82@fedora/besser82] has joined #shogun | 10:50 | |
| -!- besser82|laptop is now known as besser82 | 10:53 | |
| -!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has joined #shogun | 10:59 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 10:59 | |
| @iglesiasg | good morning guys | 11:00 |
| @wiking | ok so what are the non PIC archs? | 11:00 |
| shogun-notifier- | shogun: Viktor Gal :develop * c83de51 / / (5 files): https://github.com/shogun-toolbox/shogun/commit/c83de5161c335d036440afd066fae0ca6108b931 | 11:08 |
| shogun-notifier- | shogun: Fix TSAN flags and add ENABLE_ASAN and ENABLE_MSAN cmake targets | 11:08 |
| shogun-notifier- | shogun: Viktor Gal :develop * 07dc7a4 / / (4 files): https://github.com/shogun-toolbox/shogun/commit/07dc7a45d01bd81b53a2411f15632a0bb5590cf4 | 11:08 |
| shogun-notifier- | shogun: Fix header protector in CanberraMetric | 11:08 |
| shogun-notifier- | shogun: Fix initialization of SGVector in WeightedMajorityVote | 11:08 |
| shogun-notifier- | shogun: Fix malloc dealloc mismatch in CombinedDotFeatures_unittest | 11:08 |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Quit: buildmaster reconfigured: bot disconnecting] | 11:09 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun | 11:09 | |
| @wiking | shogun-buildbot: force build --branch=develop 'clang34 - thread analysis' | 11:10 |
| shogun-buildbot | build forced [ETA 6m14s] | 11:10 |
| shogun-buildbot | I'll give a shout when the build finishes | 11:10 |
| shogun-buildbot | build #2089 of deb1 - libshogun is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/2089 blamelist: Viktor Gal <viktor.gal@maeth.com> | 11:15 |
| -!- travis-ci [~travis-ci@ec2-54-234-43-199.compute-1.amazonaws.com] has joined #shogun | 11:16 | |
| 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/11228787 | 11:16 |
| -!- travis-ci [~travis-ci@ec2-54-234-43-199.compute-1.amazonaws.com] has left #shogun [] | 11:16 | |
| shogun-buildbot | build #2090 of deb1 - libshogun is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/2090 blamelist: Viktor Gal <viktor.gal@maeth.com> | 11:16 |
| @wiking | oh damn :( | 11:16 |
| shogun-notifier- | shogun: Viktor Gal :develop * 8334b1e / / (3 files): https://github.com/shogun-toolbox/shogun/commit/8334b1eb2306aca190bfaba9817d44dc10601219 | 11:21 |
| shogun-notifier- | shogun: only set SANITIZER_FLAGS if it is set | 11:21 |
| shogun-buildbot | build #3 of clang34 - thread analysis is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20thread%20analysis/builds/3 | 11:23 |
| @wiking | yeey new bugs | 11:24 |
| shogun-buildbot | build #2091 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/2091 blamelist: Viktor Gal <viktor.gal@maeth.com> | 11:35 |
| -!- van51 [~van51@athedsl-410351.home.otenet.gr] has joined #shogun | 11:52 | |
| van51 | hello guys | 11:52 |
| @wiking | yo | 11:52 |
| van51 | sonne|work: I am doing the demo backend and I have a question | 11:53 |
| van51 | sonne|work: I was thinking of de-serializing a SVM since training it would take too much time | 11:53 |
| van51 | sonne|work: but even de-serializing takes about ~20secs | 11:54 |
| van51 | sonne|work: can we have a different thread load it upon a new request or something? | 11:55 |
| sonne|work | van51: before serializing it please clear out all features etc | 11:56 |
| sonne|work | van51: then loading should take <1s | 11:56 |
| sonne|work | van51: store it as ascii to see yourself | 11:56 |
| @wiking | sonne|work: do you know how this is possible: for (i=0; i<n; i++) | 11:57 |
| @wiking | 1 Assuming 'i' is >= 'n' | 11:57 |
| sonne|work | van51: and then I would also load it just once on startup. foulwall did this | 11:57 |
| sonne|work | too | 11:57 |
| sonne|work | wiking: no way | 11:57 |
| @wiking | sonne|work: static analyzer still manages :D | 11:58 |
| @wiking | ok i'll ask around in llvm channel | 11:58 |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * 498a280 / src/shogun/base/DynArray.h: https://github.com/shogun-toolbox/shogun/commit/498a28007e1b618f5e063ef4acef4c58fb4e9322 | 12:00 |
| shogun-notifier- | shogun: Revert "fix potential memory leak in dynarray" | 12:00 |
| shogun-notifier- | shogun: | 12:00 |
| shogun-notifier- | shogun: This reverts commit 8dc2b37940f62e210eeba0d198c862ac3b3f78d0. | 12:00 |
| sonne|work | wiking: there is no memory leak - static analyzer is wrong | 12:00 |
| sonne|work | there is a corner case where realloc can return NULL when it fails | 12:01 |
| @wiking | sonne|work: ok i'll try to find out how we can supress that error | 12:01 |
| sonne|work | but the array pointer stays the same | 12:01 |
| sonne|work | so we should not overwrite the array pointer - because then we cannot delete it | 12:01 |
| sonne|work | wiking: regarding the for loop - maybe i is incremented? | 12:01 |
| @wiking | sonne|work: within the loop no | 12:02 |
| sonne|work | wiking: then valgrind it? | 12:02 |
| sonne|work | wiking: ohh btw when doing valgrind disable optimizations otherwise it may not be 100% accurate | 12:02 |
| @wiking | sonne|work: yes i did that | 12:03 |
| @wiking | sonne|work: btw that loop condition can be true | 12:03 |
| @wiking | if n = 0 | 12:03 |
| sonne|work | ok | 12:03 |
| sonne|work | if n == 0 ? | 12:03 |
| @wiking | for(i=0; i< n; i++) where n = 0 | 12:03 |
| sonne|work | or n= 0? | 12:03 |
| @wiking | so there it can happen that i >= n | 12:03 |
| sonne|work | ahh >= yes | 12:03 |
| @wiking | sonne|work: i guess an assert( n > 0) should fix that | 12:04 |
| sonne|work | wiking: yes | 12:04 |
| sonne|work | no way i<n should not enter the loop | 12:04 |
| sonne|work | I mean the for loop is never taken | 12:05 |
| @wiking | sonne|work: although here it did not | 12:05 |
| @wiking | http://buildbot.shogun-toolbox.org/static_analysis/2013-09-10-1/report-c8589a.html#EndPath | 12:05 |
| @wiking | sonne|work: mmm any ideas about this | 12:05 |
| @wiking | i have ASSERT(totdoc > 0); | 12:05 |
| @wiking | and then it say | 12:06 |
| @wiking | 1) Loop condition is true. Entering loop body | 12:07 |
| @wiking | 2_ Assuming 'j' is >= 'totdoc' | 12:07 |
| @wiking | how the fuck is that possible? | 12:07 |
| @wiking | ah ok | 12:07 |
| @wiking | totdoc = 1 | 12:07 |
| @wiking | then first loop ok | 12:07 |
| sonne|work | van51: OK? | 12:07 |
| @wiking | second time it's 1 | 12:07 |
| sonne|work | van51: or alternatively get the bias term and w vector and create a linearmachine just with them and serialize it | 12:08 |
| van51 | sonne|work: yeah I got the idea.. I'm testing | 12:08 |
| van51 | sonne|work: couldn't w be the bottleneck? | 12:08 |
| van51 | sonne|work: that specific svm was consifering a hash size of 20 bits | 12:09 |
| @wiking | sonne|work: ok maybe there we should just do an if kernel_cache.activenum > 0 | 12:11 |
| sonne|work | van51: 2**20*8 | 12:11 |
| sonne|work | 8388608 | 12:11 |
| sonne|work | so 8MB | 12:11 |
| sonne|work | no | 12:11 |
| sonne|work | van51: how big is the file that you have | 12:11 |
| @wiking | shogun-buildbot: force build --branch=develop 'clang34 - thread analysis' | 12:12 |
| shogun-buildbot | build forced [ETA 6m14s] | 12:12 |
| shogun-buildbot | I'll give a shout when the build finishes | 12:12 |
| van51 | sonne|work: ~ 100Mb | 12:12 |
| van51 | sonne|work: so I guess I didn't remove the features | 12:12 |
| -!- iglesiasg_ [~iglesias@s83-179-44-135.cust.tele2.se] has joined #shogun | 12:17 | |
| -!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has quit [Ping timeout: 276 seconds] | 12:17 | |
| thoralf | <wiking> thoralf: if u r around would be great <-- Now? ;) | 12:18 |
| @wiking | thoralf: so ... basically we've managed to figure out what was there going on... | 12:19 |
| @wiking | thoralf: there was a vector.resize_vector(0); in the init part... | 12:19 |
| @wiking | and that caused troubles | 12:19 |
| @wiking | thoralf: it's just bad that the error was not more informative.... but at least it found the bug | 12:20 |
| thoralf | wiking: Hope it was not in my code? ;) | 12:20 |
| @wiking | thoralf: nono it was mine | 12:20 |
| @wiking | thoralf: i'm just waiting for the new analysis output | 12:20 |
| @wiking | let's see what it finds this time | 12:20 |
| thoralf | wiking: In the beginning I've seen that in general sgvector(0) *might* be a problem, because vector=NULL etc. Interesting border cases. But it wasn't broken, so I didn't touch. ;) | 12:21 |
| thoralf | wiking: BTW., we once had an issue with "SGVector v();" vs. "SGVector v(0);" vs. "SGVector v;" - we found out that v() was bad, since leaving v uninitialized. Do you know why? | 12:23 |
| @wiking | ok new tsan analysis will be out soon | 12:23 |
| @wiking | thoralf: no idea :( | 12:23 |
| shogun-buildbot | build #4 of clang34 - thread analysis is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20thread%20analysis/builds/4 | 12:25 |
| @wiking | yey errors | 12:25 |
| lisitsyn | "SGVector v()" is a pointer to function that returns SGVector | 12:26 |
| -!- travis-ci [~travis-ci@ec2-54-227-133-66.compute-1.amazonaws.com] has joined #shogun | 12:27 | |
| 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/11229156 | 12:27 |
| -!- travis-ci [~travis-ci@ec2-54-227-133-66.compute-1.amazonaws.com] has left #shogun [] | 12:27 | |
| thoralf | lisitsyn: Wow, thanks. At least it sounds more plausible than anything I could think about. ;) | 12:28 |
| lisitsyn | thoralf: I don't think it makes sense to write SGVector v(); | 12:28 |
| thoralf | lisitsyn: I've been writing it accidently, but afterwards it didn't even look wrong. :) | 12:29 |
| lisitsyn | thoralf: this also happens when you want some std::vector<int> v(10); | 12:30 |
| lisitsyn | and then you decide oh I don't need capacity anymore | 12:30 |
| lisitsyn | and you get compile error :) | 12:31 |
| thoralf | Hehe, that's exactly what I did. :) | 12:31 |
| thoralf | "Just remove that 0 to save space" ;) | 12:31 |
| lisitsyn | thoralf: it is good interview question | 12:33 |
| lisitsyn | if C++ programmer never had issue with that () | 12:33 |
| thoralf | lisitsyn: Oh yes. | 12:33 |
| lisitsyn | he/she is probably not enough experienced | 12:33 |
| lisitsyn | just haven't written enough code yet | 12:34 |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Quit: buildmaster reconfigured: bot disconnecting] | 12:34 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun | 12:34 | |
| @wiking | shogun-buildbot: force build --branch=develop 'clang34 - undefined behaviour analysis' | 12:34 |
| shogun-buildbot | build #0 forced | 12:34 |
| shogun-buildbot | I'll give a shout when the build finishes | 12:34 |
| lisitsyn | wiking: undefined behaviour analysis?! ;D | 12:35 |
| @wiking | lisitsyn: you'll see | 12:35 |
| @wiking | it's like 1000+ lines of error | 12:35 |
| lisitsyn | wiking: shogun must be aircraft control software now | 12:35 |
| thoralf | Another one would be to tell something about: (int32_t)*(int32t) - (int64_t) | 12:35 |
| thoralf | Had this a few days ago. :) | 12:35 |
| lisitsyn | thoralf: well even (float) - (float) is full of surprises :) | 12:36 |
| lisitsyn | wiking: I think we lack just one step now | 12:36 |
| thoralf | Full of undefined behaviour? :) | 12:36 |
| lisitsyn | infrastructure-wise | 12:36 |
| @wiking | lisitsyn: what? :) | 12:36 |
| lisitsyn | wiking: we need to buy some outsourcing company that writes code | 12:37 |
| @wiking | :DDD | 12:37 |
| lisitsyn | all the other things are here already | 12:37 |
| @wiking | welll fuck this shit | 12:37 |
| @wiking | if we do a release | 12:37 |
| @wiking | let's do it right | 12:37 |
| @wiking | :) | 12:37 |
| @wiking | especially if it's 3.0 | 12:37 |
| @wiking | i mean i know that we had some really shitty releases in the past | 12:38 |
| @wiking | lisitsyn: basically the agenda of the next meeting should be | 12:38 |
| lisitsyn | wiking: you deserve to be chief engineering officer :D | 12:38 |
| @wiking | lisitsyn: fix all the analysis errors... or suppress them if they are irrelevant | 12:38 |
| thoralf | Is there a date for the release? | 12:39 |
| @wiking | thoralf: we wanted end of this month | 12:39 |
| @wiking | thoralf: imo it wont happened | 12:39 |
| @wiking | there's just too much stuff | 12:39 |
| thoralf | wiking: Are you doing shogun full-time? ;) | 12:39 |
| @wiking | lisitsyn: clang 3.4 release will be really cool with all this sanitizing options + openmp | 12:39 |
| @wiking | seems like | 12:40 |
| @wiking | :D | 12:40 |
| thoralf | 60h/week in your country? ;) | 12:40 |
| @wiking | heheh | 12:41 |
| lisitsyn | wiking: what's your plan? | 12:41 |
| @wiking | lisitsyn: for? | 12:41 |
| lisitsyn | wiking: your time-wise | 12:41 |
| shogun-buildbot | build #0 of clang34 - undefined behaviour analysis is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20undefined%20behaviour%20analysis/builds/0 | 12:41 |
| @wiking | okeeey | 12:41 |
| @wiking | let's check tht fucking error of this one | 12:41 |
| @wiking | ah this was worse before | 12:42 |
| @wiking | cool:) | 12:42 |
| lisitsyn | wiking: I mean how long are you going to work on that more than full-time? :) | 12:42 |
| @wiking | heheheh | 12:42 |
| @wiking | lisitsyn: release | 12:42 |
| @wiking | lisitsyn: Serialization.liblinear search for this in here: http://buildbot.shogun-toolbox.org/builders/clang34%20-%20undefined%20behaviour%20analysis/builds/0/steps/test/logs/stdio | 12:42 |
| lisitsyn | wiking: oh | 12:43 |
| @wiking | hehe ok one more bot is needed | 12:46 |
| @wiking | shall i just put all the sanitizing task into one buildbot task? | 12:46 |
| thoralf | lisitsyn: "until release" -> shifting the release just became more attractive :D | 12:46 |
| @wiking | ok | 12:47 |
| @wiking | i think it's time to merge serialutest branch | 12:47 |
| @wiking | :DDDD | 12:47 |
| @wiking | will be heaps of fucking fun | 12:47 |
| shogun-notifier- | shogun: Viktor Gal :feature/SerialUTests * 59466a8 / tests/unit/io/SerializationJSON_unittest.cc.jinja2: https://github.com/shogun-toolbox/shogun/commit/59466a831acc0f0573787da7eee15868fdae4883 | 12:50 |
| shogun-notifier- | shogun: Disable json serial utest temporarily | 12:50 |
| shogun-buildbot | build #2092 of deb1 - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/2092 | 12:54 |
| @wiking | lisitsyn: what ya reckon: rebase + merge or just merge the branch? | 12:55 |
| lisitsyn | wiking: just merge it I think | 12:55 |
| shogun-buildbot | build #59 of FC19 - modular_interfaces is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/FC19%20-%20modular_interfaces/builds/59 blamelist: Soeren Sonnenburg <sonne@debian.org> | 12:56 |
| shogun-buildbot | build #72 of FCRH - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/FCRH%20-%20libshogun/builds/72 | 12:56 |
| -!- sekon [~harish@li291-152.members.linode.com] has joined #shogun | 12:57 | |
| sekon | Hello, does shogun implement the C4.5 algorithm ? | 12:58 |
| @wiking | sekon: no not yet... neither c5.0 | 12:58 |
| besser82 | sekon: sry, then i was mistaking ;) | 12:59 |
| @wiking | besser82: how's the package creation going? | 12:59 |
| besser82 | wiking: pretty straight forward ;) | 12:59 |
| @wiking | oh fuck ... clang just doesn't wnat to compile some unit tests... | 13:00 |
| besser82 | wiking: clang is a pita ;) | 13:00 |
| @wiking | besser82: is it done? | 13:00 |
| besser82 | wiking: currently waiting for NLopt and ColPack to be reviewed for fedora.... | 13:00 |
| @wiking | besser82: ah but it works without those :) | 13:01 |
| besser82 | wiking: yes, but it will miss some features then afaik... | 13:01 |
| @wiking | yesh some for sure | 13:01 |
| @wiking | :) | 13:01 |
| sekon | wiking: thanks for the quick reply | 13:01 |
| besser82 | wiking: so when they are ready to be imported, I'm far enough to submit SHOGUN-rpm for review ;) | 13:02 |
| @wiking | ah ok | 13:02 |
| -!- sekon [~harish@li291-152.members.linode.com] has left #shogun [] | 13:02 | |
| besser82 | wiking: is it possible to have the data-set-tarball to be versioned to the corresponding shogung version for upcoming release? | 13:02 |
| shogun-notifier- | shogun: Viktor Gal :feature/SerialUTests * a0a0712 / .travis.yml,tests/unit/io/SerializationJSON_unittest.cc.jinja2: https://github.com/shogun-toolbox/shogun/commit/a0a07125038664bbb6888d4eed05a1c3e6b28f11 | 13:03 |
| shogun-notifier- | shogun: Maybe we ran out of mem when compiling the big autogen utests? | 13:03 |
| @wiking | besser82: yeah possible | 13:03 |
| besser82 | wiking: would you be so nice to do so? | 13:03 |
| @wiking | besser82: somebody will do it for sure :) | 13:03 |
| @wiking | it's a small price for an rpm ;) | 13:04 |
| besser82 | wiking: would be a lot less work for on maintaining the whole thing ;) | 13:04 |
| @wiking | heh | 13:04 |
| @wiking | i never fucking watch again travis log html: https://api.travis-ci.org/jobs/11231308/log.txt?deansi=true | 13:05 |
| @wiking | :D | 13:05 |
| besser82 | wiking: since i can run the build with testsuite in one step, without need to lookup which data-set version is needed ;) | 13:05 |
| thoralf | wiking: is watching travis log sth like space-night on TV? | 13:11 |
| thoralf | wiking: Sit there and watch? :) | 13:11 |
| -!- travis-ci [~travis-ci@ec2-54-234-43-199.compute-1.amazonaws.com] has joined #shogun | 13:16 | |
| 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/11230042 | 13:16 |
| -!- travis-ci [~travis-ci@ec2-54-234-43-199.compute-1.amazonaws.com] has left #shogun [] | 13:16 | |
| shogun-buildbot | build #1777 of deb3 - modular_interfaces is complete: Failure [failed install test python_modular] Build details are at http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/1777 blamelist: Soeren Sonnenburg <sonne@debian.org> | 13:17 |
| shogun-buildbot | build #1150 of rpm1 - libshogun is complete: Failure [failed compile] Build details are at http://buildbot.shogun-toolbox.org/builders/rpm1%20-%20libshogun/builds/1150 blamelist: Soeren Sonnenburg <sonne@debian.org> | 13:18 |
| thoralf | What to do with unit-test that produces output? I just tested some error handling and it messes the screen output with stuff like "[ERROR] ..." | 13:21 |
| thoralf | I think the [ERROR] might be confusing for those who are watching unit test output. :) | 13:22 |
| sonne|work | besser82: the data .tgz is versioned already | 13:44 |
| sonne|work | wiking: ^ | 13:44 |
| sonne|work | in NEWS there is data version ... | 13:45 |
| besser82 | sonne|work: i know, but my question was about having the version of data.tgz == SHOGUN-ver :) | 13:45 |
| sonne|work | van51: look in the ascii file or create a new linear machine with the w & b from the old one and serialize that | 13:47 |
| sonne|work | besser82: no doesn't make sense | 13:48 |
| sonne|work | besser82: if we keep the data the same why should we upload a new .tgz with a different version name? | 13:48 |
| -!- Tuxa [808337b4@gateway/web/freenode/ip.128.131.55.180] has joined #shogun | 13:50 | |
| besser82 | sonne|work: in this case, I'd like to ask at least for a tag on gh, please? | 13:50 |
| sonne|work | besser82: for data you mean? We kind of always have this since data is a git submodule in shogun already | 13:51 |
| besser82 | sonne|work: my question is more about the following reason: In fedora I need to run testsuite during pkg-build and the need for a manual lookup of the correct data will make spec maintainance more time-consuming | 13:53 |
| besser82 | sonne|work: when having a tag on gh for the data repo, which points to the corect commit this would be lot of easier for me, since i just need to specifiy this tag as souce for srpm ;) | 13:54 |
| besser82 | sonne|work: I think of a tag which is the same version as shogun's version.... | 13:55 |
| sonne|work | besser82: I guess a download symlink would do the same job right? | 13:55 |
| sonne|work | besser82: you only need some easy to grasp url right? | 13:56 |
| besser82 | sonne|work: yes, that would be fine as well ;) | 13:56 |
| besser82 | sonne|work: sure | 13:56 |
| besser82 | sonne|work: the perfect would be $url_to_download_loc/shogun-data-%{version}.tar* sth. ;) | 13:57 |
| van51 | can someone have a look at this PR: https://github.com/shogun-toolbox/shogun/pull/1569 ? | 14:05 |
| van51 | and we can discuss it there or here :) | 14:05 |
| van51 | lisitsyn: ^ | 14:07 |
| van51 | lisitsyn: since the class was written by you and you would know better | 14:07 |
| @wiking | ok | 14:11 |
| @wiking | here weeee gooo | 14:11 |
| shogun-notifier- | shogun: Viktor Gal :develop * 45ad889 / tests/unit/ (5 files): https://github.com/shogun-toolbox/shogun/commit/45ad889864df9ae6b10627b805bd8b30a59e1aa4 | 14:12 |
| shogun-notifier- | shogun: Refactor autogenerated clone_unittest | 14:12 |
| shogun-notifier- | shogun: Add autogenerated unit tests for all the supported serialisation | 14:12 |
| shogun-notifier- | shogun: backends | 14:12 |
| shogun-notifier- | shogun: Viktor Gal :develop * 1e9118f / tests/unit/CMakeLists.txt: https://github.com/shogun-toolbox/shogun/commit/1e9118f41bd6d31b9c77cbc1bddc14d1d13a22c5 | 14:12 |
| shogun-notifier- | shogun: Refactor autogenerated unit test creation in cmake | 14:12 |
| shogun-notifier- | shogun: one will have to add manually the generation command | 14:12 |
| shogun-notifier- | shogun: this way we support more flexible autogeneration | 14:12 |
| shogun-notifier- | shogun: Viktor Gal :develop * 3455976 / tests/unit/CMakeLists.txt: https://github.com/shogun-toolbox/shogun/commit/34559761f6bbbe53caa86a2ab04e2752b75e2582 | 14:12 |
| shogun-notifier- | shogun: Run unit testing with --only-on-failure when executing from ctest | 14:12 |
| shogun-notifier- | shogun: The number of log line in travis is limited to 10000 and the | 14:12 |
| shogun-notifier- | shogun: ever growing unit tests are eating up the lines, hence only print | 14:12 |
| shogun-notifier- | shogun: the failed unit tests when running it from ctest | 14:12 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * b2ca266 / src/shogun/features/streaming/generators/GaussianBlobsDataGenerator.cpp: https://github.com/shogun-toolbox/shogun/commit/b2ca26607677d92d0f7ccf8a324c0b680d81768d | 14:12 |
| shogun-notifier- | shogun: fixed uninitialised memory bug | 14:12 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 6c4cbf8 / src/shogun/classifier/ (2 files): https://github.com/shogun-toolbox/shogun/commit/6c4cbf830f918abb0b050b339a8668ac434ba25d | 14:12 |
| shogun-notifier- | shogun: fixed uninitialized memory bugs and changed SG_REF order in setter | 14:12 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 58ff468 / src/shogun/multiclass/MCLDA.cpp: https://github.com/shogun-toolbox/shogun/commit/58ff468a24e44ec520e1f5a233574866be68bdda | 14:12 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 2a84601 / tests/unit/CMakeLists.txt: https://github.com/shogun-toolbox/shogun/commit/2a84601c7fd8c6fee3ea4410c54e333913729f95 | 14:12 |
| shogun-notifier- | shogun: activate hdf5 since it works | 14:12 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 2741b0c / src/shogun/ (7 files): https://github.com/shogun-toolbox/shogun/commit/2741b0c8c10e49012fa51a6485387f2f506ba51a | 14:12 |
| shogun-notifier- | shogun: removed spaces from parameter names that are registered | 14:12 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * e11517f / src/shogun/base/Parameter.cpp: https://github.com/shogun-toolbox/shogun/commit/e11517f0012428b96614094cd3a56ddcf20342af | 14:12 |
| shogun-notifier- | shogun: only allow alnum and underscore for registered parameter names | 14:12 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 9759434 / tests/unit/io/SerializationXML_unittest.cc.jinja2: https://github.com/shogun-toolbox/shogun/commit/97594343003d94a63293737877a0135a2dbeee01 | 14:12 |
| shogun-notifier- | shogun: introduce accuracy for xml serialization equal tests | 14:12 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * a022433 / tests/unit/CMakeLists.txt: https://github.com/shogun-toolbox/shogun/commit/a0224338eabf701264a66dfd9b0551de00b8871a | 14:12 |
| shogun-notifier- | shogun: activate XML serialization since it works | 14:12 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * e48b2b4 / tests/unit/io/ (2 files): https://github.com/shogun-toolbox/shogun/commit/e48b2b43c7667f12e6538e9808e21aaeeeb6c8fd | 14:12 |
| shogun-notifier- | shogun: added accuracy for template classes | 14:12 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 0610fb9 / tests/unit/io/SerializationJSON_unittest.cc.jinja2: https://github.com/shogun-toolbox/shogun/commit/0610fb952688155bcf938f386c45ac693e175ac0 | 14:12 |
| shogun-notifier- | shogun: json seems to have a low accuracy | 14:12 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 92f01a9 / tests/unit/CMakeLists.txt: https://github.com/shogun-toolbox/shogun/commit/92f01a96b686120c2c158928b20326101df07e8f | 14:12 |
| shogun-notifier- | shogun: activate json since most things are working | 14:12 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 3602ec7 / src/shogun/io/SerializableJsonFile.cpp: https://github.com/shogun-toolbox/shogun/commit/3602ec74749d86ec71d6af711a969d34b71f16c2 | 14:12 |
| shogun-notifier- | shogun: replace warning by error since otherwise shogun runs into uninitialized memory problems | 14:12 |
| shogun-notifier- | shogun: src/shogun/structure/Factor.cpp | 14:12 |
| shogun-notifier- | shogun: Viktor Gal :develop * 5fb7089 / .travis.yml: https://github.com/shogun-toolbox/shogun/commit/5fb7089ea44422d32bfa5aab97c30e7ebd6566a3 | 14:12 |
| shogun-notifier- | shogun: Speed up ctest on travis | 14:12 |
| @wiking | let the fun beging | 14:12 |
| @wiking | :) | 14:13 |
| Tuxa | hello everyone! I'm new in machine learning and shogun and I tryed to implement a one-class classification (event: is a person getting up from a bed?). The code works, but the classification is pretty bad :(. can somebody take a look on my code please? feature_fustor.cpp: http://pastebin.com/gNyShp49 feature_fusor.h: http://pastebin.com/MQegiPw1 typedefs: http://pastebin.com/CEGE0y0n | 14:14 |
| @wiking | *begin | 14:14 |
| shogun-buildbot | build #2093 of deb1 - libshogun is complete: Failure [failed compile] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/2093 blamelist: Viktor Gal <viktor.gal@maeth.com> | 14:23 |
| shogun-buildbot | build #2094 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/2094 blamelist: Viktor Gal <viktor.gal@maeth.com> | 14:24 |
| shogun-buildbot | build #2096 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/2096 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Viktor Gal <viktor.gal@maeth.com> | 14:34 |
| -!- Tuxa [808337b4@gateway/web/freenode/ip.128.131.55.180] has quit [Quit: Page closed] | 14:34 | |
| -!- Tuxa [808337b4@gateway/web/freenode/ip.128.131.55.180] has joined #shogun | 14:34 | |
| @wiking | Tuxa: why do u use combinedkernel when u dont use actually any kernel? | 14:43 |
| @wiking | ah ok i haven't seen the header | 14:43 |
| @wiking | so u always use gaussians | 14:43 |
| thoralf | wiking: Something for the compiler-/valgrind-guy https://github.com/shogun-toolbox/shogun/pull/1570 :) | 14:53 |
| @wiking | cool cool | 14:54 |
| @wiking | i'll merge it as soon as i have back the unit tests running | 14:54 |
| thoralf | wiking: Okay, then I'll write some more documentation into the file. 2 minutes. ;) | 14:55 |
| lisitsyn | van51: ok let me see | 14:58 |
| lisitsyn | van51: yes makes sense | 14:59 |
| shogun-notifier- | shogun: van51 :develop * 57a5b4a / src/shogun/machine/LinearMulticlassMachine.h: https://github.com/shogun-toolbox/shogun/commit/57a5b4a7e7cda3b2c9c07a721766d96dab466539 | 14:59 |
| shogun-notifier- | shogun: Fix set_features for every machine in LinearMulticlassMachine | 14:59 |
| shogun-notifier- | shogun: Sergey Lisitsyn :develop * bc7abf7 / src/shogun/machine/LinearMulticlassMachine.h: https://github.com/shogun-toolbox/shogun/commit/bc7abf7fd822fbd3c4e6cca2fbf0daef646f86b6 | 14:59 |
| shogun-notifier- | shogun: Merge pull request #1569 from van51/feature/multiclass_serial | 14:59 |
| shogun-notifier- | shogun: | 14:59 |
| shogun-notifier- | shogun: Fix set_features for every machine in LinearMulticlassMachine | 14:59 |
| van51 | lisitsyn: travis was unhappy about something in python_modular.. not sure if it had anything to do with this | 15:00 |
| Tuxa | @wiking: ist it bad to always use gaussians? should i use other kernel types? | 15:00 |
| Tuxa | *is | 15:02 |
| van51 | lisitsyn: anyway, thanks for the merge :) | 15:02 |
| lisitsyn | van51: oops | 15:03 |
| shogun-buildbot | build #2097 of deb1 - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/2097 | 15:03 |
| shogun-buildbot | build #2098 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/2098 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 15:05 |
| lisitsyn | van51: looks like serialization | 15:07 |
| shogun-buildbot | build #60 of FC19 - modular_interfaces is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/FC19%20-%20modular_interfaces/builds/60 blamelist: van51 <vangelis_51@hotmail.com> | 15:07 |
| van51 | lisitsyn: should I do something? | 15:08 |
| lisitsyn | van51: I don't think your commit caused that | 15:09 |
| van51 | lisitsyn: ok then, I won't argue :) | 15:09 |
| shogun-buildbot | build #1151 of rpm1 - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/rpm1%20-%20libshogun/builds/1151 | 15:12 |
| shogun-buildbot | build #2095 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/2095 blamelist: Viktor Gal <viktor.gal@maeth.com> | 15:14 |
| -!- iglesiasg_ [~iglesias@s83-179-44-135.cust.tele2.se] has quit [Ping timeout: 276 seconds] | 15:18 | |
| sonne|work | van51: was that the issue? I mean that is why it was that big? | 15:19 |
| van51 | sonne|work: the machines that were trained with the multiclass linear machine kept their features, despite a call to set_features(NULL) | 15:20 |
| van51 | sonne|work: I'm guessing that's why, yeah | 15:21 |
| shogun-notifier- | shogun: Viktor Gal :develop * dfd8373 / tests/unit/io/ (3 files): https://github.com/shogun-toolbox/shogun/commit/dfd837373b1fb2dda72d82a3324d528b13e145ce | 15:39 |
| shogun-notifier- | shogun: Disable bound to fail serialization unit tests | 15:39 |
| shogun-notifier- | shogun: issue #1573 #1572 #1571 #1464 | 15:39 |
| sonne|work | van51: so how big is it now? | 15:41 |
| shogun-buildbot | build #1778 of deb3 - modular_interfaces is complete: Failure [failed install test python_modular] Build details are at http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/1778 blamelist: van51 <vangelis_51@hotmail.com> | 15:42 |
| shogun-buildbot | build #2099 of deb1 - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/2099 | 15:52 |
| van51 | sonne|work: I am training a new one atm, but by removing the features/labels from an older one it 's around 70Mb | 15:58 |
| sonne|work | van51: still too big, did you have a look in the ascii file? | 15:59 |
| van51 | sonne|work: yea | 16:00 |
| sonne|work | and? | 16:00 |
| sonne|work | only the w in there or what else? | 16:00 |
| van51 | sonne|work: it's because of the 5 w's probably | 16:00 |
| sonne|work | ahh 5 languages yes sure | 16:01 |
| sonne|work | you used multiclassocas right? | 16:01 |
| van51 | sonne|work: multiclassliblinear | 16:01 |
| sonne|work | or that same thing :) | 16:01 |
| @wiking | sonne|work: what should b the chmod for buidlsave being able to write to /usr/lib/x86_64-linux-gnu/octave/site/oct/api-v48+/x86_64-pc-linux-gnu | 16:02 |
| @wiking | ? | 16:02 |
| sonne|work | wiking: not chmod chown buildslave usr/lib/x86_64-linux-gnu/octave/site/oct/api-v48+/x86_64-pc-linux-gnu -R | 16:02 |
| shogun-buildbot | build #61 of FC19 - modular_interfaces is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/FC19%20-%20modular_interfaces/builds/61 blamelist: Viktor Gal <viktor.gal@maeth.com> | 16:02 |
| -!- Tuxa [808337b4@gateway/web/freenode/ip.128.131.55.180] has quit [Quit: Page closed] | 16:26 | |
| -!- van51 [~van51@athedsl-410351.home.otenet.gr] has quit [Quit: Leaving.] | 16:29 | |
| shogun-buildbot | build #1779 of deb3 - modular_interfaces is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/1779 | 16:42 |
| @wiking | yeye | 16:42 |
| @wiking | shogun-buildbot: force build --branch=develop 'clang34 - undefined behaviour analysis' | 16:44 |
| shogun-buildbot | build #1 forced | 16:44 |
| shogun-buildbot | I'll give a shout when the build finishes | 16:44 |
| shogun-buildbot | build #1 of clang34 - undefined behaviour analysis is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20undefined%20behaviour%20analysis/builds/1 | 16:51 |
| @wiking | lisitsyn: here? | 16:53 |
| @wiking | shogun-buildbot: force build --branch=develop 'clang34 - static analysis' | 16:56 |
| shogun-buildbot | build #10 forced | 16:56 |
| shogun-buildbot | I'll give a shout when the build finishes | 16:56 |
| lisitsyn | wiking: yes | 16:57 |
| @wiking | lisitsyn: /usr/include/eigen3/Eigen/src/Core/util/Memory.h:789:19: runtime error: load of misaligned address 0x00000537a66b for type 'const int', which requires 4 byte alignment | 16:58 |
| @wiking | 0x00000537a66b: note: pointer points here 73 65 5d 00 47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 41 75 74 68 65 6e 74 69 63 41 4d 44 00 41 4d | 16:58 |
| lisitsyn | wiking: hehe | 16:59 |
| @wiking | even better | 16:59 |
| @wiking | /home/buildslave/clang34_-_undefined_behaviour_analysis/build/src/shogun/base/Parameter.cpp:3634:18: runtime error: member access within address 0x00000b4a1b40 which does not point to an object of type 'SGSparseVector<char>' | 16:59 |
| @wiking | 0x00000b4a1b40: note: object is of type 'shogun::SGSparseVector<double>' | 16:59 |
| @wiking | 00 00 00 00 b0 70 97 55 43 7f 00 00 10 1f 4a 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | 16:59 |
| @wiking | ^~~~~~~~~~~~~~~~~~~~~~~ | 16:59 |
| @wiking | vptr for 'shogun::SGSparseVector<double>' | 16:59 |
| lisitsyn | wiking: no idea what's happening here :D | 17:03 |
| @wiking | well it's the undefined behaviour sanitizer shit :) | 17:05 |
| @wiking | lisitsyn: -fsanitize=vptr: Use of an object whose vptr indicates that it is of the wrong dynamic type, or that its lifetime has not begun or has ended | 17:07 |
| shogun-buildbot | build #10 of clang34 - static analysis is complete: Failure [failed analyse] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20static%20analysis/builds/10 | 17:17 |
| -!- sonne|osx [~sonne@82.113.121.127] has joined #shogun | 17:20 | |
| sonne|osx | wiking: I've checked the static clang analysis for a couple of more items | 17:25 |
| sonne|osx | so far all were false positives | 17:25 |
| @wiking | sonne|osx: really? even the ones for Parameter.cpp? | 17:27 |
| @wiking | and thiese ones are for sure not false positives | 17:28 |
| @wiking | sonne|osx: Argument with 'nonnull' attribute passed null | 17:28 |
| sonne|osx | wiking: I didn't check those but div by zero memleak and some nonnull | 17:28 |
| @wiking | http://buildbot.shogun-toolbox.org/static_analysis/2013-09-11-1/report-d7bc07.html#EndPath | 17:28 |
| @wiking | this ascii file really can get null parameter for strncpy | 17:28 |
| @wiking | in CAsciiFile::append_item | 17:29 |
| sonne|osx | wiking: once I am done fixing the examples AsciiFile will be removed anyway | 17:29 |
| @wiking | ok | 17:30 |
| @wiking | sonne|osx: this is not false positive either http://buildbot.shogun-toolbox.org/static_analysis/2013-09-11-1/report-422c86.html#EndPath | 17:31 |
| @wiking | and same here for sparsefeatures | 17:31 |
| @wiking | http://buildbot.shogun-toolbox.org/static_analysis/2013-09-11-1/report-bddce3.html#EndPath | 17:31 |
| sonne|osx | what is supposed to be null here? | 17:32 |
| sonne|osx | param? | 17:32 |
| sonne|osx | wiking: ^ | 17:32 |
| @wiking | which one? | 17:33 |
| sonne|osx | http://buildbot.shogun-toolbox.org/static_analysis/2013-09-11-1/report-422c86.html#EndPath | 17:33 |
| @wiking | sonne|osx: hdf5 case param can be nul | 17:33 |
| @wiking | yes | 17:33 |
| sonne|osx | wiking: how? | 17:33 |
| @wiking | read_string_begin_wrapped | 17:33 |
| @wiking | go there | 17:33 |
| @wiking | as a second step | 17:34 |
| @wiking | read_scalar_wrapped(type, NULL); | 17:34 |
| @wiking | hence param = NULL | 17:34 |
| @wiking | and kaboom there u go | 17:34 |
| sonne|osx | ahh I see | 17:34 |
| sonne|osx | ok then | 17:34 |
| @wiking | in sparse case it's even more obvious | 17:35 |
| @wiking | actually there i think it's always null | 17:35 |
| @wiking | as tmp_feat_after is initialized as NULL | 17:35 |
| @wiking | and never set | 17:35 |
| @wiking | (the setter line is commented out) | 17:36 |
| @wiking | //tmp_feat_after=((CSparsePreprocessor<ST>*) get_preproc(i))->apply_to_feature_vector(tmp_feat_before, tmp_len); | 17:36 |
| sonne|osx | OK I will have a look later again then | 17:37 |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * b2a174e / examples/undocumented/python_modular/ (2 files): https://github.com/shogun-toolbox/shogun/commit/b2a174e81aead41492b5c8e44d156876d47fdb5e | 17:38 |
| shogun-notifier- | shogun: CSVFile conversion | 17:38 |
| -!- sonne|osx [~sonne@82.113.121.127] has quit [Quit: sonne|osx] | 17:39 | |
| @wiking | oooh goodie | 17:44 |
| shogun-buildbot | build #1701 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/1701 blamelist: Soeren Sonnenburg <sonne@debian.org> | 17:49 |
| shogun-buildbot | build #62 of FC19 - modular_interfaces is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/FC19%20-%20modular_interfaces/builds/62 blamelist: Soeren Sonnenburg <sonne@debian.org> | 17:49 |
| -!- travis-ci [~travis-ci@ec2-54-227-133-66.compute-1.amazonaws.com] has joined #shogun | 17:52 | |
| travis-ci | [travis-ci] it's Sergey Lisitsyn'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/11235371 | 17:52 |
| -!- travis-ci [~travis-ci@ec2-54-227-133-66.compute-1.amazonaws.com] has left #shogun [] | 17:52 | |
| shogun-notifier- | shogun: Viktor Gal :develop * 8b86afc / .travis.yml: https://github.com/shogun-toolbox/shogun/commit/8b86afcf9f94f04f1216a894c17fe43115b83e80 | 18:21 |
| shogun-notifier- | shogun: Travis: turn off coveralls and lower the concurent make jobs to 2 | 18:21 |
| shogun-notifier- | shogun: otherwise we are sometimes running into weird (most probably out of | 18:21 |
| shogun-notifier- | shogun: memory) behaviour of the compiler | 18:21 |
| -!- van51 [~van51@athedsl-410351.home.otenet.gr] has joined #shogun | 18:23 | |
| shogun-buildbot | build #63 of FC19 - modular_interfaces is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/FC19%20-%20modular_interfaces/builds/63 blamelist: Viktor Gal <viktor.gal@maeth.com> | 18:33 |
| shogun-buildbot | build #1702 of bsd1 - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/1702 | 18:33 |
| @wiking | did we have problems with StreamingHashedDocFeaturesTest.example_reading | 18:36 |
| @wiking | ? | 18:36 |
| @wiking | lately? | 18:36 |
| van51 | wiking: nope and there shouldn't be | 18:38 |
| van51 | wiking: what's wrong with it? | 18:39 |
| @wiking | van51: http://pastebin.com/HbkShJD9 | 18:40 |
| @wiking | it's the same for StreamingHashedDenseFeaturesTest.dot | 18:40 |
| thoralf | wiking: InputParser and ParseBuffer are weird. | 18:45 |
| thoralf | wiking: Thy're used in streamingsparsefeatures as well and quite tricky to use. | 18:45 |
| thoralf | wiking: But I think I already fixed the most problematic parts. | 18:46 |
| @wiking | seems there's still something wrong | 18:47 |
| thoralf | wiking: Maybe it helps: have a look on get_next_feature | 18:48 |
| thoralf | wiking: Creating a sparse vector from what parser returns. | 18:48 |
| thoralf | wiking: Assigning it manually to a new vector. | 18:49 |
| thoralf | wiking: But the memory is still references (and reused) in parse. | 18:49 |
| thoralf | wiking: It was the same pattern everywhere - i fixed it but creating a vector with refcounting=false to prevent freeing it on two places. | 18:50 |
| thoralf | CStreamingHashedDocDotFeatures::get_next_example() looks like having the same problem, CStreamingHashedDenseFeatures<ST>::get_next_example() as well | 18:51 |
| -!- besser82 [~besser82@fedora/besser82] has quit [Remote host closed the connection] | 18:51 | |
| thoralf | CStreamingHashedSparseFeatures<ST>::get_next_example() is different, but *may* also be affected. | 18:52 |
| thoralf | Everywhere the same: Creating a vector from data which is "owned" and reused by the Parser/ring buffer | 18:52 |
| thoralf | CStreamingHashedSparseFeatures is okay. | 18:55 |
| thoralf | van51: This one looks strange "index_t n_idx = vec.features[i].feat_index + vec.features[i].feat_index;" <-- HashedSparseFeatures | 18:57 |
| thoralf | van51: Why "+"? | 18:57 |
| van51 | thoralf: where is this? | 18:57 |
| thoralf | van51: HashedSparseFeatures::hash_vector | 18:57 |
| van51 | thoralf: I just wanted to create a virtual new index to has afterwards | 19:00 |
| van51 | hash* | 19:00 |
| thoralf | van51: But then index 0 is mapped to 0 again, mapped index 1 becomes 2? | 19:00 |
| thoralf | van51: Why not ndim+feat_index? | 19:01 |
| thoralf | van51: So it's not easy to predict the collisions of "linear" hashed features and quadratic. ;) | 19:01 |
| thoralf | van51: So a priori linear and quadratic features do not collide. | 19:02 |
| thoralf | van51: In your case I can say: every second linear feature has a collision with a quadratic feature. ;) | 19:03 |
| van51 | thoralf: let me have a look | 19:03 |
| van51 | thoralf: why? | 19:03 |
| van51 | thoralf: there is also the seed there as a paremeter | 19:04 |
| thoralf | van51: Oh right, did not see this! But you cannot use a different seed in every iteration. | 19:05 |
| van51 | thoralf: maybe for index=0 it is as you are saying | 19:05 |
| van51 | thoralf: it's the same value + seed per feature though, so the same feature among examples will be mapped to the same bin | 19:07 |
| thoralf | van51: Please talk to someone who's better with this. But: (1) I think you should fix a seed in advance and use it for all indices (2) the "virtual" quadratic indices should not collide with the "linear" indices. | 19:07 |
| thoralf | (before hashing) | 19:08 |
| thoralf | Just to make sure to have no systematic collisions. | 19:08 |
| thoralf | better with this (than me ;)) | 19:08 |
| @wiking | thoralf: if i gdb this.... i exactly get what it says. current_example->fv is 0x0 | 19:08 |
| van51 | thoralf: I had someone have a look at the code, but I 'll contact him again and ask him to look at this specifically :) | 19:09 |
| thoralf | van51: Yeah, just to make sure. And please tell me if I was wrong. | 19:09 |
| van51 | thoralf: sure | 19:10 |
| thoralf | wiking: Errr. I need more context. First of all, you think your problems may be related to what I wrote? | 19:12 |
| @wiking | gdb) p current_example->fv | 19:12 |
| @wiking | $3 = { | 19:12 |
| @wiking | <shogun::SGReferencedData> = { | 19:12 |
| @wiking | _vptr$SGReferencedData = 0x0, | 19:12 |
| @wiking | m_refcount = 0x0 | 19:12 |
| @wiking | }, | 19:12 |
| @wiking | members of shogun::SGVector<char>: | 19:12 |
| @wiking | vector = 0x0, | 19:12 |
| @wiking | vlen = 0 | 19:12 |
| @wiking | } | 19:12 |
| @wiking | InputParser.h:533 + StreamingHashedDocFeaturesTest.example_reading | 19:12 |
| thoralf | which line in the unit test? | 19:14 |
| @wiking | just a se | 19:14 |
| @wiking | imho StreamingHashedDocDotFeatures.cpp:156 | 19:15 |
| @wiking | as it's in another thread | 19:15 |
| @wiking | so i might be wrong | 19:15 |
| @wiking | StreamingHashedDocDotFeatures_unittest.cc:54 | 19:15 |
| @wiking | 10 0x0000000103c94d6c in shogun::CStreamingHashedDocDotFeatures::get_next_example (this=0x10744e560) at StreamingHashedDocDotFeatures.cpp:156 | 19:15 |
| @wiking | #11 0x00000001000b51b7 in StreamingHashedDocFeaturesTest_example_reading_Test::TestBody (this=0x10744c0b0) at StreamingHashedDocDotFeatures_unittest.cc:54 | 19:15 |
| @wiking | this is the part of the stack of thread 1 | 19:15 |
| thoralf | wiking: line 122, line 131 | 19:16 |
| @wiking | there's label in it | 19:16 |
| @wiking | but the vector is 0x0 | 19:17 |
| thoralf | wiking: sparsevector assignment | 19:17 |
| thoralf | wiking: Sparse vector will be cleared after the loop. | 19:17 |
| thoralf | wiking: Destroying internal memory of the parser. | 19:17 |
| thoralf | wiking: try setting sparsevectors.features == NULL bfefore the iteration end. | 19:17 |
| thoralf | wiking: If it changes something, it's "my" probelm. | 19:18 |
| @wiking | thoralf: which src we are talking about now? | 19:19 |
| @wiking | StreamingHashedDocDotFeatures_unittest.cc i guess | 19:19 |
| thoralf | tests/unit/features/StreamingHashedDocDotFeatures_unittest.cc | 19:19 |
| thoralf | wiking: you're debugging in dot_tests | 19:20 |
| thoralf | wiking: since line 156 belongs to this file | 19:20 |
| thoralf | s/file/test/ | 19:20 |
| van51 | thoralf: I email-ed them.. when I hear back, I'll let you know :) | 19:21 |
| thoralf | wiking: I'm guessing that "get_vector()" is evil. ;) | 19:21 |
| thoralf | van51: Who is your mentor, if I may ask? | 19:22 |
| van51 | thoralf: ofc you can, it was Olivier Chapelle and Benoit Rostykus | 19:22 |
| @wiking | thoralf: wait i dont see what does this have to do with that null pointer thing ? :) | 19:23 |
| van51 | thoralf: along with sonney | 19:23 |
| thoralf | CStreamingHashedDocDotFeatures(doc_collection) | 19:23 |
| thoralf | SGSparseVector<float64_t> example = feats->get_vector(); | 19:24 |
| thoralf | feats is CStreamingHashedDocDotFeatures | 19:24 |
| @wiking | thoralf: but this happens in CInputParser<T>::main_parse_loop | 19:25 |
| thoralf | wiking: Well, just an educated guess because almost all get_vector() implementations are problematic. | 19:25 |
| thoralf | wiking: feats->get_vector() returns pointers to memory shared with input parser | 19:25 |
| thoralf | s/shared with/owned by/ | 19:25 |
| thoralf | Took me a week. Just commend everything between (1) this f***ing get_vector() and (2) finalize_example out. ;) | 19:26 |
| thoralf | If it doesn't help, it's not the problem I'm talking about ;) | 19:26 |
| @wiking | oh woah | 19:27 |
| @wiking | editing unit test file | 19:27 |
| @wiking | does not trigger recompilation | 19:27 |
| thoralf | I know ;) | 19:27 |
| @wiking | ah oooh nooo | 19:27 |
| thoralf | Told you ;) | 19:27 |
| @wiking | wrong shell | 19:27 |
| @wiking | :)) | 19:27 |
| thoralf | lol | 19:27 |
| @wiking | it does | 19:27 |
| thoralf | wiking: Wait, but adding unit test files does not trigger, right? | 19:28 |
| @wiking | yes that's another story | 19:29 |
| @wiking | thoralf: ok no... i've added example.features = NULL;StreamingHashedDocDotFeatures_unittest.cc | 19:30 |
| @wiking | i mean example.features = NULL; | 19:30 |
| @wiking | to StreamingHashedDocDotFeatures_unittest.cc:71 | 19:30 |
| @wiking | but it's the same | 19:30 |
| @wiking | i'm saying that thre's a problem within get_next_example | 19:30 |
| thoralf | wiking: they're related. Since get_next_example prepares everything for get_vector. | 19:31 |
| thoralf | But it should not be triggered when get_vector is not called. | 19:31 |
| thoralf | At least it wasn't in streaming sparse features | 19:31 |
| @wiking | the vector is 0x0 | 19:32 |
| thoralf | Weird. | 19:33 |
| @wiking | non the less there's more shit | 19:34 |
| @wiking | soooo it's ok ;) | 19:34 |
| shogun-buildbot | build #1781 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/1781 blamelist: Viktor Gal <viktor.gal@maeth.com> | 19:35 |
| thoralf | wiking: I digged into it - and the tmp vector (with the "foreign" memory) is finally passed into ctokenizer. | 19:38 |
| thoralf | What about SGVector<char> foo = tmp.clone(); current_vector = converter->apply(foo); | 19:38 |
| thoralf | in get_next_example | 19:38 |
| thoralf | Oooor: Changing "SGVector<char> tmp;" to "SGVector<char> tmp(0,false);" | 19:40 |
| thoralf | So at least nobody tries to free this beast. ;) | 19:41 |
| -!- van51 [~van51@athedsl-410351.home.otenet.gr] has quit [Quit: Leaving.] | 19:48 | |
| -!- travis-ci [~travis-ci@ec2-23-23-8-204.compute-1.amazonaws.com] has joined #shogun | 19:50 | |
| 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/11242248 | 19:50 |
| -!- travis-ci [~travis-ci@ec2-23-23-8-204.compute-1.amazonaws.com] has left #shogun [] | 19:50 | |
| thoralf | wiking: Are you still on the problem? If not, how can I trigger it? It's so tempting. ;) | 19:50 |
| -!- sonne|osx [~sonne@f053034179.adsl.alicedsl.de] has joined #shogun | 19:53 | |
| -!- lisitsyn1 [~lisitsyn@fb2-lo1.global63.net] has joined #shogun | 19:56 | |
| shogun-buildbot | build #1780 of deb3 - modular_interfaces is complete: Failure [failed compile csharp_modular] Build details are at http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/1780 blamelist: Soeren Sonnenburg <sonne@debian.org> | 20:06 |
| -!- lisitsyn2 [~lisitsyn@fb2-lo1.global63.net] has joined #shogun | 20:17 | |
| -!- lisitsyn1 [~lisitsyn@fb2-lo1.global63.net] has quit [Ping timeout: 264 seconds] | 20:20 | |
| -!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has quit [Ping timeout: 264 seconds] | 20:36 | |
| -!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has joined #shogun | 20:57 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 20:57 | |
| -!- vgorbati [~vgorbati@91.216.173.29] has joined #shogun | 20:59 | |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 21:21 | |
| lisitsyn2 | iglesiasg: but you have commit rights ;) | 21:34 |
| @iglesiasg | lisitsyn2, I think the button to merge it didn't appear | 21:35 |
| lisitsyn2 | iglesiasg: hmm strange | 21:35 |
| lisitsyn2 | I am lisitsyn2 haha | 21:35 |
| @iglesiasg | lisitsyn2, but anyway it was nothing important, I just like being annoying :P | 21:36 |
| -!- lisitsyn2 is now known as actual_lisitsyn | 21:36 | |
| -!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has joined #shogun | 21:46 | |
| -!- vgorbati [~vgorbati@91.216.173.29] has quit [Quit: vgorbati] | 21:52 | |
| -!- thoralf_ [~thoralf@24-134-83-14-dynip.superkabel.de] has joined #shogun | 21:53 | |
| thoralf_ | Hey there | 21:53 |
| thoralf_ | wiking: Did you dive deeper into your hashed features problem? | 21:54 |
| -!- vgorbati [~vgorbati@91.216.173.29] has joined #shogun | 21:59 | |
| -!- vgorbati [~vgorbati@91.216.173.29] has quit [Client Quit] | 22:00 | |
| -!- HeikoS [~heiko@213.190.120.70] has joined #shogun | 22:15 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 22:15 | |
| thoralf_ | Hey Heiko | 22:18 |
| @HeikoS | thoralf_: good evening! | 22:19 |
| -!- HeikoS [~heiko@213.190.120.70] has quit [Ping timeout: 264 seconds] | 22:29 | |
| -!- HeikoS [~heiko@dab-crx1-h-30-10.dab.02.net] has joined #shogun | 22:30 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 22:30 | |
| thoralf_ | Does anyone know if it's possible to do Bundle Methods with Line Search in shogun? | 22:34 |
| -!- HeikoS [~heiko@dab-crx1-h-30-10.dab.02.net] has left #shogun [] | 22:34 | |
| thoralf_ | I only see BMRM, Proximal BMRM, etc. | 22:35 |
| thoralf_ | NCBM looks like having line search (there is at least a switch for that) and a switch telling convex true/false. | 22:36 |
| -!- HeikoS1 [~heiko@213.190.120.70] has joined #shogun | 22:37 | |
| thoralf_ | HeikoS1: Can you say something about Bundle Methods? ;) | 22:39 |
| HeikoS1 | thoralf_: no idea about them, sorry | 22:39 |
| HeikoS1 | sorry my connection dropped before, did you say anything? | 22:40 |
| thoralf_ | No, you didn't | 22:40 |
| thoralf_ | except "good evening" | 22:40 |
| HeikoS1 | ok :) | 22:41 |
| HeikoS1 | greeting from Reykjavik btw | 22:41 |
| thoralf_ | HeikoS1: Cool :) | 22:42 |
| thoralf_ | HeikoS1: Where are you going to? How long are you staying? | 22:42 |
| HeikoS1 | https://sites.google.com/site/lgm2013ice/ I come home Sunday night | 22:43 |
| thoralf_ | Been there last year and made a round trip on my own :) | 22:43 |
| HeikoS1 | sweet | 22:44 |
| HeikoS1 | I hope to have some time | 22:44 |
| HeikoS1 | my luggage was lost on the flight so today I had to stay in waiting for it | 22:44 |
| HeikoS1 | but going for some food now and exploring the town a bit by night | 22:44 |
| thoralf_ | Have fun and don't eat anything you don't know. Could be a big surprise. ;) | 22:46 |
| HeikoS1 | thoralf_: I like surprises :) | 22:46 |
| HeikoS1 | thoralf_: I might be back later, see you! | 22:46 |
| thoralf_ | Rotten shark? ;) | 22:46 |
| -!- HeikoS1 [~heiko@213.190.120.70] has quit [Quit: Leaving.] | 22:49 | |
| -!- thoralf_ [~thoralf@24-134-83-14-dynip.superkabel.de] has quit [Quit: Konversation terminated!] | 23:00 | |
| -!- hushell [~hushell@c-98-232-178-161.hsd1.or.comcast.net] has quit [Ping timeout: 260 seconds] | 23:40 | |
| -!- actual_lisitsyn [~lisitsyn@fb2-lo1.global63.net] has quit [Ping timeout: 245 seconds] | 23:55 | |
| --- Log closed Thu Sep 12 00:00:55 2013 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!