Open in new window / Try shogun cloud
--- Log opened Wed Sep 11 00:00:54 2013
-!- travis-ci [~travis-ci@ec2-54-234-113-13.compute-1.amazonaws.com] has joined #shogun00: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/1121027800: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 #shogun02:04
-!- sonne|osx_ [~sonne@f053034179.adsl.alicedsl.de] has joined #shogun03:20
-!- sonne|osx [~sonne@f053039166.adsl.alicedsl.de] has quit [Ping timeout: 245 seconds]03:22
-!- sonne|osx_ is now known as sonne|osx03: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 #shogun07:02
-!- sonne|osx [~sonne@f053034179.adsl.alicedsl.de] has quit [Quit: sonne|osx]07:25
-!- sonne|osx [~sonne@82.113.106.106] has joined #shogun08:20
sonne|osxshogun-buildbot: force build --branch=develop 'deb3 - modular_interfaces'08:29
shogun-buildbotbuild forced [ETA 33m29s]08:29
shogun-buildbotI'll give a shout when the build finishes08:29
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun08:44
shogun-notifier-shogun: Soeren Sonnenburg :develop * 8dc2b37 / src/shogun/base/DynArray.h: https://github.com/shogun-toolbox/shogun/commit/8dc2b37940f62e210eeba0d198c862ac3b3f78d008:44
shogun-notifier-shogun: fix potential memory leak in dynarray08:44
-!- sonne|osx [~sonne@82.113.106.106] has quit [Quit: sonne|osx]08:45
shogun-buildbotbuild #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/177609:00
@wikingsonney2k: https://travis-ci.org/shogun-toolbox/shogun/builds/1122573409: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 #shogun09:18
sonne|workwiking: ahh ok09:24
-!- lisitsyn [~lisitsyn@fb2-lo1.global63.net] has joined #shogun09:27
shogun-buildbotbuild #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 #shogun09: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/1122573409:44
-!- travis-ci [~travis-ci@ec2-54-234-113-13.compute-1.amazonaws.com] has left #shogun []09:44
@wikingsonne|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 happ09:50
@wikingthoralf: ^ if u are around09:50
-!- lisitsyn [~lisitsin@mxs.kg.ru] has joined #shogun09:52
sonne|workwiking: the correct fix is SGVEctor<type>()10:12
sonne|workwiking: the other is actually a BUG!!10:12
@wikingok i get that10:13
@wikingbut why only comes out if i enable thread-sanitizing? :D10:13
@wikingeven more, what type of bug is that? :D10:13
@wikingi mean actually then it's good to have that buildbot running (thread analysis) as this bug was not catch any other way.... :P10:14
sonne|workwiking: well the resize(0) basically frees the memory of the sgvector I guess accidentally10:14
@wikingso this already justifies that bot's existing :P10:15
@wikingsonne|work: btw -fPIC should be always set for gmock/gtest libraries right?10:16
sonne|workwiking: only on PIC architecturs like AMD6410:17
sonne|workwiking: on x86 it is not necessary10:17
sonne|work(probably the only exception)10:17
@wikingsonne|work: but if we 'always' have it that doesn't hurt, right?10:17
sonne|workwiking: except that you get a gazillion of warnings10:22
-!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Quit: buildmaster reconfigured: bot disconnecting]10:45
-!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun10:45
@wikingsonne|work: woah man10:46
@wikingwe have like kazillions of bugs10:46
@wiking:)))10:46
-!- besser82 [~besser82@77-22-24-208-dynip.superkabel.de] has joined #shogun10:50
-!- besser82 is now known as Guest7378210: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 #shogun10:50
-!- besser82|laptop [~besser82@77-22-24-208-dynip.superkabel.de] has quit [Changing host]10:50
-!- besser82|laptop [~besser82@fedora/besser82] has joined #shogun10:50
-!- besser82|laptop is now known as besser8210:53
-!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has joined #shogun10:59
-!- mode/#shogun [+o iglesiasg] by ChanServ10:59
@iglesiasggood morning guys11:00
@wikingok 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/c83de5161c335d036440afd066fae0ca6108b93111:08
shogun-notifier-shogun: Fix TSAN flags and add ENABLE_ASAN and ENABLE_MSAN cmake targets11:08
shogun-notifier-shogun: Viktor Gal :develop * 07dc7a4 / / (4 files): https://github.com/shogun-toolbox/shogun/commit/07dc7a45d01bd81b53a2411f15632a0bb5590cf411:08
shogun-notifier-shogun: Fix header protector in CanberraMetric11:08
shogun-notifier-shogun: Fix initialization of SGVector in WeightedMajorityVote11:08
shogun-notifier-shogun: Fix malloc dealloc mismatch in CombinedDotFeatures_unittest11:08
-!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Quit: buildmaster reconfigured: bot disconnecting]11:09
-!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun11:09
@wikingshogun-buildbot: force build --branch=develop 'clang34 - thread analysis'11:10
shogun-buildbotbuild forced [ETA 6m14s]11:10
shogun-buildbotI'll give a shout when the build finishes11:10
shogun-buildbotbuild #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 #shogun11: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/1122878711:16
-!- travis-ci [~travis-ci@ec2-54-234-43-199.compute-1.amazonaws.com] has left #shogun []11:16
shogun-buildbotbuild #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
@wikingoh damn :(11:16
shogun-notifier-shogun: Viktor Gal :develop * 8334b1e / / (3 files): https://github.com/shogun-toolbox/shogun/commit/8334b1eb2306aca190bfaba9817d44dc1060121911:21
shogun-notifier-shogun: only set SANITIZER_FLAGS if it is set11:21
shogun-buildbotbuild #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/311:23
@wikingyeey new bugs11:24
shogun-buildbotbuild #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 #shogun11:52
van51hello guys11:52
@wikingyo11:52
van51sonne|work: I am doing the demo backend and I have a question11:53
van51sonne|work: I was thinking of de-serializing a SVM since training it would take too much time11:53
van51sonne|work: but even de-serializing takes about ~20secs11:54
van51sonne|work: can we have a different thread load it upon a new request or something?11:55
sonne|workvan51: before serializing it please clear out all features etc11:56
sonne|workvan51: then loading should take <1s11:56
sonne|workvan51: store it as ascii to see yourself11:56
@wikingsonne|work: do you know how this is possible: for (i=0; i<n; i++)11:57
@wiking1 Assuming 'i' is >= 'n'11:57
sonne|workvan51: and then I would also load it just once on startup. foulwall did this11:57
sonne|worktoo11:57
sonne|workwiking: no way11:57
@wikingsonne|work: static analyzer still manages :D11:58
@wikingok i'll ask around in llvm channel11:58
shogun-notifier-shogun: Soeren Sonnenburg :develop * 498a280 / src/shogun/base/DynArray.h: https://github.com/shogun-toolbox/shogun/commit/498a28007e1b618f5e063ef4acef4c58fb4e932212: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|workwiking: there is no memory leak - static analyzer is wrong12:00
sonne|workthere is a corner case where realloc can return NULL when it fails12:01
@wikingsonne|work: ok i'll try to find out how we can supress that error12:01
sonne|workbut the array pointer stays the same12:01
sonne|workso we should not overwrite the array pointer - because then we cannot delete it12:01
sonne|workwiking: regarding the for loop - maybe i is incremented?12:01
@wikingsonne|work: within the loop no12:02
sonne|workwiking: then valgrind it?12:02
sonne|workwiking: ohh btw when doing valgrind disable optimizations otherwise it may not be 100% accurate12:02
@wikingsonne|work: yes i did that12:03
@wikingsonne|work: btw that loop condition can be true12:03
@wikingif n = 012:03
sonne|workok12:03
sonne|workif n == 0 ?12:03
@wikingfor(i=0; i< n; i++) where n = 012:03
sonne|workor n= 0?12:03
@wikingso there it can happen that i >= n12:03
sonne|workahh >= yes12:03
@wikingsonne|work: i guess an assert( n > 0) should fix that12:04
sonne|workwiking: yes12:04
sonne|workno way i<n should not enter the loop12:04
sonne|workI mean the for loop is never taken12:05
@wikingsonne|work: although here it did not12:05
@wikinghttp://buildbot.shogun-toolbox.org/static_analysis/2013-09-10-1/report-c8589a.html#EndPath12:05
@wikingsonne|work: mmm any ideas about this12:05
@wikingi have ASSERT(totdoc > 0);12:05
@wikingand then it say12:06
@wiking1) Loop condition is true. Entering loop body12:07
@wiking2_ Assuming 'j' is >= 'totdoc'12:07
@wikinghow the fuck is that possible?12:07
@wikingah ok12:07
@wikingtotdoc = 112:07
@wikingthen first loop ok12:07
sonne|workvan51: OK?12:07
@wikingsecond time it's 112:07
sonne|workvan51: or alternatively get the bias term and w vector and create a linearmachine just with them and serialize it12:08
van51sonne|work: yeah I got the idea.. I'm testing12:08
van51sonne|work: couldn't w be the bottleneck?12:08
van51sonne|work: that specific svm was consifering a hash size of 20 bits12:09
@wikingsonne|work: ok maybe there we should just do an if kernel_cache.activenum > 012:11
sonne|workvan51: 2**20*812:11
sonne|work838860812:11
sonne|workso 8MB12:11
sonne|workno12:11
sonne|workvan51: how big is the file that you have12:11
@wikingshogun-buildbot: force build --branch=develop 'clang34 - thread analysis'12:12
shogun-buildbotbuild forced [ETA 6m14s]12:12
shogun-buildbotI'll give a shout when the build finishes12:12
van51sonne|work: ~ 100Mb12:12
van51sonne|work: so I guess I didn't remove the features12:12
-!- iglesiasg_ [~iglesias@s83-179-44-135.cust.tele2.se] has joined #shogun12: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
@wikingthoralf: so ... basically we've managed to figure out what was there going on...12:19
@wikingthoralf: there was a vector.resize_vector(0); in the init part...12:19
@wikingand that caused troubles12:19
@wikingthoralf: it's just bad that the error was not more informative.... but at least it found the bug12:20
thoralfwiking: Hope it was not in my code? ;)12:20
@wikingthoralf: nono it was mine12:20
@wikingthoralf: i'm just waiting for the new analysis output12:20
@wikinglet's see what it finds this time12:20
thoralfwiking: 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
thoralfwiking: 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
@wikingok new tsan analysis will be out soon12:23
@wikingthoralf: no idea :(12:23
shogun-buildbotbuild #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/412:25
@wikingyey errors12:25
lisitsyn"SGVector v()" is a pointer to function that returns SGVector12:26
-!- travis-ci [~travis-ci@ec2-54-227-133-66.compute-1.amazonaws.com] has joined #shogun12: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/1122915612:27
-!- travis-ci [~travis-ci@ec2-54-227-133-66.compute-1.amazonaws.com] has left #shogun []12:27
thoralflisitsyn: Wow, thanks.  At least it sounds more plausible than anything I could think about. ;)12:28
lisitsynthoralf: I don't think it makes sense to write SGVector v();12:28
thoralflisitsyn: I've been writing it accidently, but afterwards it didn't even look wrong. :)12:29
lisitsynthoralf: this also happens when you want some std::vector<int> v(10);12:30
lisitsynand then you decide oh I don't need capacity anymore12:30
lisitsynand you get compile error :)12:31
thoralfHehe, that's exactly what I did. :)12:31
thoralf"Just remove that 0 to save space" ;)12:31
lisitsynthoralf: it is good interview question12:33
lisitsynif C++ programmer never had issue with that ()12:33
thoralflisitsyn: Oh yes.12:33
lisitsynhe/she is probably not enough experienced12:33
lisitsynjust haven't written enough code yet12:34
-!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Quit: buildmaster reconfigured: bot disconnecting]12:34
-!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun12:34
@wikingshogun-buildbot: force build --branch=develop 'clang34 - undefined behaviour analysis'12:34
shogun-buildbotbuild #0 forced12:34
shogun-buildbotI'll give a shout when the build finishes12:34
lisitsynwiking: undefined behaviour analysis?! ;D12:35
@wikinglisitsyn: you'll see12:35
@wikingit's like 1000+ lines of error12:35
lisitsynwiking: shogun must be aircraft control software now12:35
thoralfAnother one would be to tell something about: (int32_t)*(int32t) - (int64_t)12:35
thoralfHad this a few days ago. :)12:35
lisitsynthoralf: well even (float) - (float) is full of surprises :)12:36
lisitsynwiking: I think we lack just one step now12:36
thoralfFull of undefined behaviour? :)12:36
lisitsyninfrastructure-wise12:36
@wikinglisitsyn: what? :)12:36
lisitsynwiking: we need to buy some outsourcing company that writes code12:37
@wiking:DDD12:37
lisitsynall the other things are here already12:37
@wikingwelll fuck this shit12:37
@wikingif we do a release12:37
@wikinglet's do it right12:37
@wiking:)12:37
@wikingespecially if it's 3.012:37
@wikingi mean i know that we had some really shitty releases in the past12:38
@wikinglisitsyn: basically the agenda of the next meeting should be12:38
lisitsynwiking: you deserve to be chief engineering officer :D12:38
@wikinglisitsyn: fix all the analysis errors... or suppress them if they are irrelevant12:38
thoralfIs there a date for the release?12:39
@wikingthoralf: we wanted end of this month12:39
@wikingthoralf: imo it wont happened12:39
@wikingthere's just too much stuff12:39
thoralfwiking: Are you doing shogun full-time? ;)12:39
@wikinglisitsyn: clang 3.4 release will be really cool with all this sanitizing options + openmp12:39
@wikingseems like12:40
@wiking:D12:40
thoralf60h/week in your country? ;)12:40
@wikingheheh12:41
lisitsynwiking: what's your plan?12:41
@wikinglisitsyn: for?12:41
lisitsynwiking: your time-wise12:41
shogun-buildbotbuild #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/012:41
@wikingokeeey12:41
@wikinglet's check tht fucking error of this one12:41
@wikingah this was worse before12:42
@wikingcool:)12:42
lisitsynwiking: I mean how long are you going to work on that more than full-time? :)12:42
@wikingheheheh12:42
@wikinglisitsyn: release12:42
@wikinglisitsyn: Serialization.liblinear search for this in here: http://buildbot.shogun-toolbox.org/builders/clang34%20-%20undefined%20behaviour%20analysis/builds/0/steps/test/logs/stdio12:42
lisitsynwiking: oh12:43
@wikinghehe ok one more bot is needed12:46
@wikingshall i just put all the sanitizing task into one buildbot task?12:46
thoralflisitsyn: "until release" -> shifting the release just became more attractive :D12:46
@wikingok12:47
@wikingi think it's time to merge serialutest branch12:47
@wiking:DDDD12:47
@wikingwill be heaps of fucking fun12:47
shogun-notifier-shogun: Viktor Gal :feature/SerialUTests * 59466a8 / tests/unit/io/SerializationJSON_unittest.cc.jinja2: https://github.com/shogun-toolbox/shogun/commit/59466a831acc0f0573787da7eee15868fdae488312:50
shogun-notifier-shogun: Disable json serial utest temporarily12:50
shogun-buildbotbuild #2092 of deb1 - libshogun is complete: Success [build successful]  Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/209212:54
@wikinglisitsyn: what ya reckon: rebase + merge or just merge the branch?12:55
lisitsynwiking: just merge it I think12:55
shogun-buildbotbuild #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-buildbotbuild #72 of FCRH - libshogun is complete: Success [build successful]  Build details are at http://buildbot.shogun-toolbox.org/builders/FCRH%20-%20libshogun/builds/7212:56
-!- sekon [~harish@li291-152.members.linode.com] has joined #shogun12:57
sekonHello, does shogun implement the C4.5 algorithm ?12:58
@wikingsekon: no not yet... neither c5.012:58
besser82sekon: sry, then i was mistaking ;)12:59
@wikingbesser82: how's the package creation going?12:59
besser82wiking: pretty straight forward ;)12:59
@wikingoh fuck ... clang just doesn't wnat to compile some unit tests...13:00
besser82wiking: clang is a pita ;)13:00
@wikingbesser82: is it done?13:00
besser82wiking: currently waiting for NLopt and ColPack to be reviewed for fedora....13:00
@wikingbesser82: ah but it works without those :)13:01
besser82wiking: yes, but it will miss some features then afaik...13:01
@wikingyesh some for sure13:01
@wiking:)13:01
sekonwiking: thanks for the quick reply13:01
besser82wiking: so when they are ready to be imported, I'm far enough to submit SHOGUN-rpm for review ;)13:02
@wikingah ok13:02
-!- sekon [~harish@li291-152.members.linode.com] has left #shogun []13:02
besser82wiking: 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/a0a07125038664bbb6888d4eed05a1c3e6b28f1113:03
shogun-notifier-shogun: Maybe we ran out of mem when compiling the big autogen utests?13:03
@wikingbesser82: yeah possible13:03
besser82wiking: would you be so nice to do so?13:03
@wikingbesser82: somebody will do it for sure :)13:03
@wikingit's a small price for an rpm ;)13:04
besser82wiking: would be a lot less work for on maintaining the whole thing ;)13:04
@wikingheh13:04
@wikingi never fucking watch again travis log html: https://api.travis-ci.org/jobs/11231308/log.txt?deansi=true13:05
@wiking:D13:05
besser82wiking: since i can run the build with testsuite in one step, without need to lookup which data-set version is needed ;)13:05
thoralfwiking: is watching travis log sth like space-night on TV?13:11
thoralfwiking: Sit there and watch? :)13:11
-!- travis-ci [~travis-ci@ec2-54-234-43-199.compute-1.amazonaws.com] has joined #shogun13: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/1123004213:16
-!- travis-ci [~travis-ci@ec2-54-234-43-199.compute-1.amazonaws.com] has left #shogun []13:16
shogun-buildbotbuild #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-buildbotbuild #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
thoralfWhat 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
thoralfI think the [ERROR] might be confusing for those who are watching unit test output. :)13:22
sonne|workbesser82: the data .tgz is versioned already13:44
sonne|workwiking: ^13:44
sonne|workin NEWS there is data version ...13:45
besser82sonne|work: i know, but my question was about having the version of data.tgz == SHOGUN-ver :)13:45
sonne|workvan51: look in the ascii file or create a new linear machine with the w & b from the old one and serialize that13:47
sonne|workbesser82: no doesn't make sense13:48
sonne|workbesser82: 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 #shogun13:50
besser82sonne|work: in this case, I'd like to ask at least for a tag on gh, please?13:50
sonne|workbesser82: for data you mean? We kind of always have this since data is a git submodule in shogun already13:51
besser82sonne|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-consuming13:53
besser82sonne|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
besser82sonne|work: I think of a tag which is the same version as shogun's version....13:55
sonne|workbesser82: I guess a download symlink would do the same job right?13:55
sonne|workbesser82: you only need some easy to grasp url right?13:56
besser82sonne|work: yes, that would be fine as well ;)13:56
besser82sonne|work: sure13:56
besser82sonne|work: the perfect would be $url_to_download_loc/shogun-data-%{version}.tar* sth. ;)13:57
van51can someone have a look at this PR: https://github.com/shogun-toolbox/shogun/pull/1569 ?14:05
van51and we can discuss it there or here :)14:05
van51lisitsyn: ^14:07
van51lisitsyn: since the class was written by you and you would know better14:07
@wikingok14:11
@wikinghere weeee gooo14:11
shogun-notifier-shogun: Viktor Gal :develop * 45ad889 / tests/unit/ (5 files): https://github.com/shogun-toolbox/shogun/commit/45ad889864df9ae6b10627b805bd8b30a59e1aa414:12
shogun-notifier-shogun: Refactor autogenerated clone_unittest14:12
shogun-notifier-shogun: Add autogenerated unit tests for all the supported serialisation14:12
shogun-notifier-shogun: backends14:12
shogun-notifier-shogun: Viktor Gal :develop * 1e9118f / tests/unit/CMakeLists.txt: https://github.com/shogun-toolbox/shogun/commit/1e9118f41bd6d31b9c77cbc1bddc14d1d13a22c514:12
shogun-notifier-shogun: Refactor autogenerated unit test creation in cmake14:12
shogun-notifier-shogun: one will have to add manually the generation command14:12
shogun-notifier-shogun: this way we support more flexible autogeneration14:12
shogun-notifier-shogun: Viktor Gal :develop * 3455976 / tests/unit/CMakeLists.txt: https://github.com/shogun-toolbox/shogun/commit/34559761f6bbbe53caa86a2ab04e2752b75e258214:12
shogun-notifier-shogun: Run unit testing with --only-on-failure when executing from ctest14:12
shogun-notifier-shogun: The number of log line in travis is limited to 10000 and the14:12
shogun-notifier-shogun: ever growing unit tests are eating up the lines, hence only print14:12
shogun-notifier-shogun: the failed unit tests when running it from ctest14:12
shogun-notifier-shogun: Heiko Strathmann :develop * b2ca266 / src/shogun/features/streaming/generators/GaussianBlobsDataGenerator.cpp: https://github.com/shogun-toolbox/shogun/commit/b2ca26607677d92d0f7ccf8a324c0b680d81768d14:12
shogun-notifier-shogun: fixed uninitialised memory bug14:12
shogun-notifier-shogun: Heiko Strathmann :develop * 6c4cbf8 / src/shogun/classifier/ (2 files): https://github.com/shogun-toolbox/shogun/commit/6c4cbf830f918abb0b050b339a8668ac434ba25d14:12
shogun-notifier-shogun: fixed uninitialized memory bugs and changed SG_REF order in setter14:12
shogun-notifier-shogun: Heiko Strathmann :develop * 58ff468 / src/shogun/multiclass/MCLDA.cpp: https://github.com/shogun-toolbox/shogun/commit/58ff468a24e44ec520e1f5a233574866be68bdda14:12
shogun-notifier-shogun: Heiko Strathmann :develop * 2a84601 / tests/unit/CMakeLists.txt: https://github.com/shogun-toolbox/shogun/commit/2a84601c7fd8c6fee3ea4410c54e333913729f9514:12
shogun-notifier-shogun: activate hdf5 since it works14:12
shogun-notifier-shogun: Heiko Strathmann :develop * 2741b0c / src/shogun/ (7 files): https://github.com/shogun-toolbox/shogun/commit/2741b0c8c10e49012fa51a6485387f2f506ba51a14:12
shogun-notifier-shogun: removed spaces from parameter names that are registered14:12
shogun-notifier-shogun: Heiko Strathmann :develop * e11517f / src/shogun/base/Parameter.cpp: https://github.com/shogun-toolbox/shogun/commit/e11517f0012428b96614094cd3a56ddcf20342af14:12
shogun-notifier-shogun: only allow alnum and underscore for registered parameter names14:12
shogun-notifier-shogun: Heiko Strathmann :develop * 9759434 / tests/unit/io/SerializationXML_unittest.cc.jinja2: https://github.com/shogun-toolbox/shogun/commit/97594343003d94a63293737877a0135a2dbeee0114:12
shogun-notifier-shogun: introduce accuracy for xml serialization equal tests14:12
shogun-notifier-shogun: Heiko Strathmann :develop * a022433 / tests/unit/CMakeLists.txt: https://github.com/shogun-toolbox/shogun/commit/a0224338eabf701264a66dfd9b0551de00b8871a14:12
shogun-notifier-shogun: activate XML serialization since it works14:12
shogun-notifier-shogun: Heiko Strathmann :develop * e48b2b4 / tests/unit/io/ (2 files): https://github.com/shogun-toolbox/shogun/commit/e48b2b43c7667f12e6538e9808e21aaeeeb6c8fd14:12
shogun-notifier-shogun: added accuracy for template classes14:12
shogun-notifier-shogun: Heiko Strathmann :develop * 0610fb9 / tests/unit/io/SerializationJSON_unittest.cc.jinja2: https://github.com/shogun-toolbox/shogun/commit/0610fb952688155bcf938f386c45ac693e175ac014:12
shogun-notifier-shogun: json seems to have a low accuracy14:12
shogun-notifier-shogun: Heiko Strathmann :develop * 92f01a9 / tests/unit/CMakeLists.txt: https://github.com/shogun-toolbox/shogun/commit/92f01a96b686120c2c158928b20326101df07e8f14:12
shogun-notifier-shogun: activate json since most things are working14:12
shogun-notifier-shogun: Heiko Strathmann :develop * 3602ec7 / src/shogun/io/SerializableJsonFile.cpp: https://github.com/shogun-toolbox/shogun/commit/3602ec74749d86ec71d6af711a969d34b71f16c214:12
shogun-notifier-shogun: replace warning by error since otherwise shogun runs into uninitialized memory problems14:12
shogun-notifier-shogun: src/shogun/structure/Factor.cpp14:12
shogun-notifier-shogun: Viktor Gal :develop * 5fb7089 / .travis.yml: https://github.com/shogun-toolbox/shogun/commit/5fb7089ea44422d32bfa5aab97c30e7ebd6566a314:12
shogun-notifier-shogun: Speed up ctest on travis14:12
@wikinglet the fun beging14:12
@wiking:)14:13
Tuxahello 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/CEGE0y0n14:14
@wiking*begin14:14
shogun-buildbotbuild #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-buildbotbuild #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-buildbotbuild #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 #shogun14:34
@wikingTuxa: why do u use combinedkernel when u dont use actually any kernel?14:43
@wikingah ok i haven't seen the header14:43
@wikingso u always use gaussians14:43
thoralfwiking: Something for the compiler-/valgrind-guy https://github.com/shogun-toolbox/shogun/pull/1570 :)14:53
@wikingcool cool14:54
@wikingi'll merge it as soon as i have back the unit tests running14:54
thoralfwiking: Okay, then I'll write some more documentation into the file.  2 minutes. ;)14:55
lisitsynvan51: ok let me see14:58
lisitsynvan51: yes makes sense14:59
shogun-notifier-shogun: van51 :develop * 57a5b4a / src/shogun/machine/LinearMulticlassMachine.h: https://github.com/shogun-toolbox/shogun/commit/57a5b4a7e7cda3b2c9c07a721766d96dab46653914:59
shogun-notifier-shogun: Fix set_features for every machine in LinearMulticlassMachine14:59
shogun-notifier-shogun: Sergey Lisitsyn :develop * bc7abf7 / src/shogun/machine/LinearMulticlassMachine.h: https://github.com/shogun-toolbox/shogun/commit/bc7abf7fd822fbd3c4e6cca2fbf0daef646f86b614:59
shogun-notifier-shogun: Merge pull request #1569 from van51/feature/multiclass_serial14:59
shogun-notifier-shogun:14:59
shogun-notifier-shogun: Fix set_features for every machine in LinearMulticlassMachine14:59
van51lisitsyn: travis was unhappy about something in python_modular.. not sure if it had anything to do with this15:00
Tuxa@wiking: ist it bad to always use gaussians? should i use other kernel types?15:00
Tuxa*is15:02
van51lisitsyn: anyway, thanks for the merge :)15:02
lisitsynvan51: oops15:03
shogun-buildbotbuild #2097 of deb1 - libshogun is complete: Success [build successful]  Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/209715:03
shogun-buildbotbuild #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
lisitsynvan51: looks like serialization15:07
shogun-buildbotbuild #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
van51lisitsyn: should I do something?15:08
lisitsynvan51: I don't think your commit caused that15:09
van51lisitsyn: ok then, I won't argue :)15:09
shogun-buildbotbuild #1151 of rpm1 - libshogun is complete: Success [build successful]  Build details are at http://buildbot.shogun-toolbox.org/builders/rpm1%20-%20libshogun/builds/115115:12
shogun-buildbotbuild #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|workvan51: was that the issue? I mean that is why it was that big?15:19
van51sonne|work: the machines that were trained with the multiclass linear machine kept their features, despite a call to set_features(NULL)15:20
van51sonne|work: I'm guessing that's why, yeah15:21
shogun-notifier-shogun: Viktor Gal :develop * dfd8373 / tests/unit/io/ (3 files): https://github.com/shogun-toolbox/shogun/commit/dfd837373b1fb2dda72d82a3324d528b13e145ce15:39
shogun-notifier-shogun: Disable bound to fail serialization unit tests15:39
shogun-notifier-shogun: issue #1573 #1572 #1571 #146415:39
sonne|workvan51: so how big is it now?15:41
shogun-buildbotbuild #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-buildbotbuild #2099 of deb1 - libshogun is complete: Success [build successful]  Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/209915:52
van51sonne|work: I am training a new one atm, but by removing the features/labels from an older one it 's around 70Mb15:58
sonne|workvan51: still too big, did you have a look in the ascii file?15:59
van51sonne|work: yea16:00
sonne|workand?16:00
sonne|workonly the w in there or what else?16:00
van51sonne|work: it's because of the 5 w's probably16:00
sonne|workahh 5 languages yes sure16:01
sonne|workyou used multiclassocas right?16:01
van51sonne|work: multiclassliblinear16:01
sonne|workor that same thing :)16:01
@wikingsonne|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-gnu16:02
@wiking?16:02
sonne|workwiking: not chmod chown buildslave  usr/lib/x86_64-linux-gnu/octave/site/oct/api-v48+/x86_64-pc-linux-gnu -R16:02
shogun-buildbotbuild #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-buildbotbuild #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/177916:42
@wikingyeye16:42
@wikingshogun-buildbot: force build --branch=develop 'clang34 - undefined behaviour analysis'16:44
shogun-buildbotbuild #1 forced16:44
shogun-buildbotI'll give a shout when the build finishes16:44
shogun-buildbotbuild #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/116:51
@wikinglisitsyn: here?16:53
@wikingshogun-buildbot: force build --branch=develop 'clang34 - static analysis'16:56
shogun-buildbotbuild #10 forced16:56
shogun-buildbotI'll give a shout when the build finishes16:56
lisitsynwiking: yes16:57
@wikinglisitsyn: /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 alignment16:58
@wiking0x00000537a66b: 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 4d16:58
lisitsynwiking: hehe16:59
@wikingeven better16: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
@wiking0x00000b4a1b40: 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 0016:59
@wiking              ^~~~~~~~~~~~~~~~~~~~~~~16:59
@wiking              vptr for 'shogun::SGSparseVector<double>'16:59
lisitsynwiking: no idea what's happening here :D17:03
@wikingwell it's the undefined behaviour sanitizer shit :)17:05
@wikinglisitsyn: -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 ended17:07
shogun-buildbotbuild #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/1017:17
-!- sonne|osx [~sonne@82.113.121.127] has joined #shogun17:20
sonne|osxwiking: I've checked the static clang analysis for a couple of more items17:25
sonne|osxso far all were false positives17:25
@wikingsonne|osx: really? even the ones for Parameter.cpp?17:27
@wikingand thiese ones are for sure not false positives17:28
@wikingsonne|osx: Argument with 'nonnull' attribute passed null17:28
sonne|osxwiking: I didn't check those but div by zero memleak and some nonnull17:28
@wikinghttp://buildbot.shogun-toolbox.org/static_analysis/2013-09-11-1/report-d7bc07.html#EndPath17:28
@wikingthis ascii file really can get null parameter for strncpy17:28
@wikingin CAsciiFile::append_item17:29
sonne|osxwiking: once I am done fixing the examples AsciiFile will be removed anyway17:29
@wikingok17:30
@wikingsonne|osx: this is not false positive either http://buildbot.shogun-toolbox.org/static_analysis/2013-09-11-1/report-422c86.html#EndPath17:31
@wikingand same here for sparsefeatures17:31
@wikinghttp://buildbot.shogun-toolbox.org/static_analysis/2013-09-11-1/report-bddce3.html#EndPath17:31
sonne|osxwhat is supposed to be null here?17:32
sonne|osxparam?17:32
sonne|osxwiking: ^17:32
@wikingwhich one?17:33
sonne|osxhttp://buildbot.shogun-toolbox.org/static_analysis/2013-09-11-1/report-422c86.html#EndPath17:33
@wikingsonne|osx: hdf5 case param can be nul17:33
@wikingyes17:33
sonne|osxwiking: how?17:33
@wikingread_string_begin_wrapped17:33
@wikinggo there17:33
@wikingas a second step17:34
@wikingread_scalar_wrapped(type, NULL);17:34
@wikinghence param = NULL17:34
@wikingand kaboom there u go17:34
sonne|osxahh I see17:34
sonne|osxok then17:34
@wikingin sparse case it's even more obvious17:35
@wikingactually there i think it's always null17:35
@wikingas tmp_feat_after is initialized as NULL17:35
@wikingand never set17: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|osxOK I will have a look later again then17:37
shogun-notifier-shogun: Soeren Sonnenburg :develop * b2a174e / examples/undocumented/python_modular/ (2 files): https://github.com/shogun-toolbox/shogun/commit/b2a174e81aead41492b5c8e44d156876d47fdb5e17:38
shogun-notifier-shogun: CSVFile conversion17:38
-!- sonne|osx [~sonne@82.113.121.127] has quit [Quit: sonne|osx]17:39
@wikingoooh goodie17:44
shogun-buildbotbuild #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-buildbotbuild #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 #shogun17: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/1123537117: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/8b86afcf9f94f04f1216a894c17fe43115b83e8018:21
shogun-notifier-shogun: Travis: turn off coveralls and lower the concurent make jobs to 218:21
shogun-notifier-shogun: otherwise we are sometimes running into weird (most probably out of18:21
shogun-notifier-shogun: memory) behaviour of the compiler18:21
-!- van51 [~van51@athedsl-410351.home.otenet.gr] has joined #shogun18:23
shogun-buildbotbuild #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-buildbotbuild #1702 of bsd1 - libshogun is complete: Success [build successful]  Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/170218:33
@wikingdid we have problems with StreamingHashedDocFeaturesTest.example_reading18:36
@wiking?18:36
@wikinglately?18:36
van51wiking: nope and there shouldn't be18:38
van51wiking: what's wrong with it?18:39
@wikingvan51: http://pastebin.com/HbkShJD918:40
@wikingit's the same for StreamingHashedDenseFeaturesTest.dot18:40
thoralfwiking: InputParser and ParseBuffer are weird.18:45
thoralfwiking: Thy're used in streamingsparsefeatures as well and quite tricky to use.18:45
thoralfwiking: But I think I already fixed the most problematic parts.18:46
@wikingseems there's still something wrong18:47
thoralfwiking: Maybe it helps: have a look on get_next_feature18:48
thoralfwiking: Creating a sparse vector from what parser returns.18:48
thoralfwiking: Assigning it manually to a new vector.18:49
thoralfwiking: But the memory is still references (and reused) in parse.18:49
thoralfwiking: 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
thoralfCStreamingHashedDocDotFeatures::get_next_example() looks like having the same problem, CStreamingHashedDenseFeatures<ST>::get_next_example() as well18:51
-!- besser82 [~besser82@fedora/besser82] has quit [Remote host closed the connection]18:51
thoralfCStreamingHashedSparseFeatures<ST>::get_next_example() is different, but *may* also be affected.18:52
thoralfEverywhere the same: Creating a vector from data which is "owned" and reused by the Parser/ring buffer18:52
thoralfCStreamingHashedSparseFeatures is okay.18:55
thoralfvan51: This one looks strange "index_t n_idx = vec.features[i].feat_index + vec.features[i].feat_index;" <-- HashedSparseFeatures18:57
thoralfvan51: Why "+"?18:57
van51thoralf: where is this?18:57
thoralfvan51: HashedSparseFeatures::hash_vector18:57
van51thoralf: I just wanted to create a virtual new index to has afterwards19:00
van51hash*19:00
thoralfvan51: But then index 0 is mapped to 0 again, mapped index 1 becomes 2?19:00
thoralfvan51: Why not ndim+feat_index?19:01
thoralfvan51: So it's not easy to predict the collisions of "linear" hashed features and quadratic. ;)19:01
thoralfvan51: So a priori linear and quadratic features do not collide.19:02
thoralfvan51: In your case I can say: every second linear feature has a collision with a quadratic feature. ;)19:03
van51thoralf: let me have a look19:03
van51thoralf: why?19:03
van51thoralf: there is also the seed there as a paremeter19:04
thoralfvan51: Oh right, did not see this!  But you cannot use a different seed in every iteration.19:05
van51thoralf: maybe for index=0 it is as you are saying19:05
van51thoralf: it's the same value + seed per feature though, so the same feature among examples will be mapped to the same bin19:07
thoralfvan51: 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
thoralfJust to make sure to have no systematic collisions.19:08
thoralfbetter with this (than me ;))19:08
@wikingthoralf: if i gdb this.... i exactly get what it says. current_example->fv is 0x019:08
van51thoralf: 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
thoralfvan51: Yeah, just to make sure.  And please tell me if I was wrong.19:09
van51thoralf: sure19:10
thoralfwiking: Errr.  I need more context.  First of all, you think your problems may be related to what I wrote?19:12
@wikinggdb) p current_example->fv19:12
@wiking$3 = {19:12
@wiking  <shogun::SGReferencedData> = {19:12
@wiking    _vptr$SGReferencedData = 0x0,19:12
@wiking    m_refcount = 0x019:12
@wiking  },19:12
@wiking  members of shogun::SGVector<char>:19:12
@wiking  vector = 0x0,19:12
@wiking  vlen = 019:12
@wiking}19:12
@wikingInputParser.h:533 + StreamingHashedDocFeaturesTest.example_reading19:12
thoralfwhich line in the unit test?19:14
@wikingjust a se19:14
@wikingimho StreamingHashedDocDotFeatures.cpp:15619:15
@wikingas it's in another thread19:15
@wikingso i might be wrong19:15
@wikingStreamingHashedDocDotFeatures_unittest.cc:5419:15
@wiking10 0x0000000103c94d6c in shogun::CStreamingHashedDocDotFeatures::get_next_example (this=0x10744e560) at StreamingHashedDocDotFeatures.cpp:15619:15
@wiking#11 0x00000001000b51b7 in StreamingHashedDocFeaturesTest_example_reading_Test::TestBody (this=0x10744c0b0) at StreamingHashedDocDotFeatures_unittest.cc:5419:15
@wikingthis is the part of the stack of thread 119:15
thoralfwiking: line 122, line 13119:16
@wikingthere's label in it19:16
@wikingbut the vector is 0x019:17
thoralfwiking: sparsevector assignment19:17
thoralfwiking: Sparse vector will be cleared after the loop.19:17
thoralfwiking: Destroying internal memory of the parser.19:17
thoralfwiking: try setting sparsevectors.features == NULL bfefore the iteration end.19:17
thoralfwiking: If it changes something, it's "my" probelm.19:18
@wikingthoralf: which src we are talking about now?19:19
@wikingStreamingHashedDocDotFeatures_unittest.cc i guess19:19
thoralftests/unit/features/StreamingHashedDocDotFeatures_unittest.cc19:19
thoralfwiking: you're debugging in dot_tests19:20
thoralfwiking: since line 156 belongs to this file19:20
thoralfs/file/test/19:20
van51thoralf: I email-ed them.. when I hear back, I'll let you know :)19:21
thoralfwiking: I'm guessing that "get_vector()" is evil. ;)19:21
thoralfvan51: Who is your mentor, if I may ask?19:22
van51thoralf: ofc you can, it was Olivier Chapelle and Benoit Rostykus19:22
@wikingthoralf: wait i dont see what does this have to do with that null pointer thing ? :)19:23
van51thoralf: along with sonney19:23
thoralfCStreamingHashedDocDotFeatures(doc_collection)19:23
thoralfSGSparseVector<float64_t> example = feats->get_vector();19:24
thoralffeats is CStreamingHashedDocDotFeatures19:24
@wikingthoralf: but this happens in CInputParser<T>::main_parse_loop19:25
thoralfwiking: Well, just an educated guess because almost all get_vector() implementations are problematic.19:25
thoralfwiking: feats->get_vector() returns pointers to memory shared with input parser19:25
thoralfs/shared with/owned by/19:25
thoralfTook me a week.  Just commend everything between (1) this f***ing get_vector() and (2) finalize_example out. ;)19:26
thoralfIf it doesn't help, it's not the problem I'm talking about ;)19:26
@wikingoh woah19:27
@wikingediting unit test file19:27
@wikingdoes not trigger recompilation19:27
thoralfI know ;)19:27
@wikingah oooh nooo19:27
thoralfTold you ;)19:27
@wikingwrong shell19:27
@wiking:))19:27
thoralflol19:27
@wikingit does19:27
thoralfwiking: Wait, but adding unit test files does not trigger, right?19:28
@wikingyes that's another story19:29
@wikingthoralf: ok no... i've added example.features = NULL;StreamingHashedDocDotFeatures_unittest.cc19:30
@wikingi mean example.features = NULL;19:30
@wikingto StreamingHashedDocDotFeatures_unittest.cc:7119:30
@wikingbut it's the same19:30
@wikingi'm saying that thre's a problem within get_next_example19:30
thoralfwiking: they're related.  Since get_next_example prepares everything for get_vector.19:31
thoralfBut it should not be triggered when get_vector is not called.19:31
thoralfAt least it wasn't in streaming sparse features19:31
@wikingthe vector is 0x019:32
thoralfWeird.19:33
@wikingnon the less there's more shit19:34
@wikingsoooo it's ok ;)19:34
shogun-buildbotbuild #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
thoralfwiking: I digged into it - and the tmp vector (with the "foreign" memory) is finally passed into ctokenizer.19:38
thoralfWhat about  SGVector<char> foo = tmp.clone();  current_vector = converter->apply(foo);19:38
thoralfin get_next_example19:38
thoralfOooor: Changing "SGVector<char> tmp;" to "SGVector<char> tmp(0,false);"19:40
thoralfSo 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 #shogun19: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/1124224819:50
-!- travis-ci [~travis-ci@ec2-23-23-8-204.compute-1.amazonaws.com] has left #shogun []19:50
thoralfwiking: 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 #shogun19:53
-!- lisitsyn1 [~lisitsyn@fb2-lo1.global63.net] has joined #shogun19:56
shogun-buildbotbuild #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 #shogun20: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 #shogun20:57
-!- mode/#shogun [+o iglesiasg] by ChanServ20:57
-!- vgorbati [~vgorbati@91.216.173.29] has joined #shogun20:59
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout]21:21
lisitsyn2iglesiasg: but you have commit rights ;)21:34
@iglesiasglisitsyn2, I think the button to merge it didn't appear21:35
lisitsyn2iglesiasg: hmm strange21:35
lisitsyn2I am lisitsyn2 haha21:35
@iglesiasglisitsyn2, but anyway it was nothing important, I just like being annoying :P21:36
-!- lisitsyn2 is now known as actual_lisitsyn21:36
-!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has joined #shogun21:46
-!- vgorbati [~vgorbati@91.216.173.29] has quit [Quit: vgorbati]21:52
-!- thoralf_ [~thoralf@24-134-83-14-dynip.superkabel.de] has joined #shogun21:53
thoralf_Hey there21:53
thoralf_wiking: Did you dive deeper into your hashed features problem?21:54
-!- vgorbati [~vgorbati@91.216.173.29] has joined #shogun21:59
-!- vgorbati [~vgorbati@91.216.173.29] has quit [Client Quit]22:00
-!- HeikoS [~heiko@213.190.120.70] has joined #shogun22:15
-!- mode/#shogun [+o HeikoS] by ChanServ22:15
thoralf_Hey Heiko22:18
@HeikoSthoralf_: 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 #shogun22:30
-!- mode/#shogun [+o HeikoS] by ChanServ22: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 #shogun22:37
thoralf_HeikoS1: Can you say something about Bundle Methods? ;)22:39
HeikoS1thoralf_: no idea about them, sorry22:39
HeikoS1sorry my connection dropped before, did you say anything?22:40
thoralf_No, you didn't22:40
thoralf_except "good evening"22:40
HeikoS1ok :)22:41
HeikoS1greeting from Reykjavik btw22:41
thoralf_HeikoS1: Cool :)22:42
thoralf_HeikoS1: Where are you going to?  How long are you staying?22:42
HeikoS1https://sites.google.com/site/lgm2013ice/ I come home Sunday night22:43
thoralf_Been there last year and made a round trip on my own :)22:43
HeikoS1sweet22:44
HeikoS1I hope to have some time22:44
HeikoS1my luggage was lost on the flight so today I had to stay in waiting for it22:44
HeikoS1but going for some food now and exploring the town a bit by night22:44
thoralf_Have fun and don't eat anything you don't know.  Could be a big surprise. ;)22:46
HeikoS1thoralf_:  I like surprises :)22:46
HeikoS1thoralf_: 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