IRC logs of #shogun for Tuesday, 2017-02-21

« Monday, 2017-02-20 Index Wednesday, 2017-02-22 »
--- Log opened Tue Feb 21 00:00:34 2017
-!- HeikoS [~heiko@host-92-0-178-129.as43234.net] has joined #shogun00:33
-!- mode/#shogun [+o HeikoS] by ChanServ00:33
@wikingCaBa, ENABLE_COLPACK should still work01:24
@wikingand as well you can have ENABLE_PROTOBUF01:24
@wiking*use01:24
CaBawiking: well i just uninstalled both protobuf and colpack :P01:24
@wikinganyhow01:25
@wikingyou can use those01:25
@wikingonly thing is01:25
@wikingthat those options are autogenerated01:25
CaBawiking: did you manage to use protobuf / colpack from homebrew with shogun?01:25
@wikingmmm01:25
@wikinglemme see what i have insalled01:26
@wikingi have both installed01:26
@wikingso i guess yes01:26
@wikingi managed to compile01:26
CaBahmmm01:34
CaBastrange01:34
CaBanever worked for me01:34
CaBamaybe you have other versions at /usr/lib?01:35
CaBaanyways. are they important? :D01:35
CaBacalling it a day :) good night guys01:39
@wikingCaBa, mmm protobuf is up to you if you want to use it as a serialization format02:02
@wikingcolpack is used in GP stuff02:02
-!- lambday [31cf349d@gateway/web/freenode/ip.49.207.52.157] has joined #shogun03:47
-!- mode/#shogun [+o lambday] by ChanServ03:47
-!- kesslerfrost [~textual@49.44.51.223] has joined #shogun04:21
-!- kesslerfrost [~textual@49.44.51.223] has quit [Quit: kesslerfrost]04:41
-!- kesslerfrost [~textual@2405:204:10c:bcef:a5ba:77b9:b976:b69f] has joined #shogun04:44
-!- kesslerfrost [~textual@2405:204:10c:bcef:a5ba:77b9:b976:b69f] has quit [Quit: kesslerfrost]05:13
@sukeyIssue #3647 "Build fails" assigned to: lambday by lambday - https://github.com/shogun-toolbox/shogun/issues/364705:36
@wikingHeikoS, ping me when you are around05:44
@sukeyPull Request #3648 "[INCOMPLETE] fix travis and buildbot errors due to bigtest merge"  opened by lambday - https://github.com/shogun-toolbox/shogun/pull/364805:49
@sukeyPull Request #3635 "LinalgRefactor - Memory Transfer Mutex"  synchronized by OXPHOS - https://github.com/shogun-toolbox/shogun/pull/363506:52
-!- lambday_ [c40f170a@gateway/web/freenode/ip.196.15.23.10] has joined #shogun06:55
-!- mode/#shogun [+o lambday_] by ChanServ06:55
@sukeyPull Request #3641 "add tests for KNN and fix an error in KDTree solver"  synchronized by MikeLing - https://github.com/shogun-toolbox/shogun/pull/364107:13
-!- HeikoS [~heiko@host-92-0-178-129.as43234.net] has quit [Ping timeout: 260 seconds]07:26
@sukeyIssue #3644 "New Linalg library cannot compile with Eigen 3.3.x"- https://github.com/shogun-toolbox/shogun/issues/364407:34
@sukeyPull Request #3641 "add tests for KNN and fix an error in KDTree solver"  synchronized by MikeLing - https://github.com/shogun-toolbox/shogun/pull/364107:47
@sukeyPull Request #3641 "add tests for KNN and fix an error in KDTree solver"  synchronized by MikeLing - https://github.com/shogun-toolbox/shogun/pull/364109:26
-!- HeikoS [~heiko@host-92-0-178-129.as43234.net] has joined #shogun10:47
-!- mode/#shogun [+o HeikoS] by ChanServ10:47
@HeikoSwiking: jojo10:48
@wikingok so cloud is ready10:49
@wikinglemme know when u have 20 mins to see how it works10:49
@HeikoSwiking: I have now10:49
@wikingok10:50
@wikinggoogle hangout?10:50
@wikingbutlemme make a coffee first10:50
@sukeyWiki page: GSoC_2017_applications edited on shogun-toolbox/shogun by karlnapf10:50
@HeikoSkk10:50
@HeikoSsame here then :)10:50
@HeikoSgive me 5 a few mins10:50
@HeikoSwe can also discuss tomorrow meting with gunnar and sfc email10:50
@HeikoSi put the zepelin thing into applied projects10:50
@HeikoSmaybe somebody has a cool idea10:50
@wikingk10:51
@wikingcool10:51
@wikinglambday ping?11:26
@wiking ComputationManager.cpp11:26
@wikingC:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xlocale(341): warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc [C:\projects\shogun\build\src\shogun\libshogun.vcxproj]11:26
@wikingC:\projects\shogun\src\shogun\statistical_testing\internals\ComputationManager.cpp(62): error C3016: 'i': index variable in OpenMP 'for' statement must have signed integral type [C:\projects\shogun\build\src\shogun\libshogun.vcxproj]11:26
@wikinglambday lambday_11:26
@wikingthe MSVC11:27
@wikingcompilation is really fucking broken11:27
CaBamorning11:28
@lambday_wiking: yo11:28
@lambday_errr11:29
@wikingdid you rebase before merging this?11:29
@lambday_yeah I did11:29
@lambday_the error is in my code... which is not compatible with MSVC it seems.. will fix it'11:29
@lambday_wiking: btw how do I check Windows build status? you told me earlier but I totally forgot11:30
@wikingman11:30
@wikingbut how the fuk is it possible11:30
@wikingthat you didn't see11:30
@wikingthe error?11:30
@wikingthe big red for the compilation?11:30
@wikingit's there11:30
@wikingpart of travis11:30
@wikingnext to it11:30
@wikingjust click n the link11:30
@wiking +for (size_t i=0; i<data_array.size(); ++i)11:34
@wikingSIZE-T11:34
@wikingsince when we have size_t in shogun11:34
@wikinglambday ?11:34
@lambday_wiking: data_array is std::vector, isn't it?11:34
@wikingbut fuck11:34
@wikingwe are not using size_t11:34
@wiking...11:34
@wikingman11:34
@wikingthis code doesn't follow11:34
@wikingany shogun internal variables11:34
@wikingright?11:35
@wikingi mean this code is find11:35
@wiking*fine11:35
@wikingif it's not part of shogun11:35
@lambday_wiking: well, these are internal parts, not open to any interfaces any way..11:35
@wikingbut still11:35
@wikingconst index_t blocksize_at(size_t i) const;11:35
@wikingeverywhere11:36
@wikingsize_t11:36
@wikingshall we start a feature branch11:36
@wikingthat fixes the this branch?11:36
@lambday_wiking: these were to make it compatible with std::vector.. all these things are called internally11:36
@wikingbecause then others can help out11:36
@wikingin working resolving the problem11:36
@lambday_wiking: let me get back to fixing these issues in a couple of hours.. if it feels like too much work, then maybe a new feature branch would be good11:37
@wikingcan you tell us11:39
@wikingwhat ar eyou working on now11:39
@wikingso we dont do double work11:39
@wikingbecause HeikoS and me we can NOW work11:39
@lambday_wiking: at this moment I cannot work.. from my work laptop at office.. if you want to fix it, please feel free..11:39
@lambday_wiking: will be back home in a couple of hours..11:40
@wikingk we'll starte a feature branch11:40
@wikingand work on it11:40
@lambday_cool.. let me know11:40
@HeikoSwiking, lambday ok let us not do the guarding for now, as we might require c+11 for the coming release (this week)11:46
@HeikoS(so no work being spent right now on adding guards11:46
@HeikoS)11:46
@sukeyNew branch feature/Cpp11 created on shogun-toolbox/shogun12:15
@sukeyNew Commit "Merge pull request #3646 from karlnapf/feature/clone_refactor12:15
@sukeypull cloning all parameterers out to a seperate method" to shogun-toolbox/shogun by vigsterkr: https://github.com/shogun-toolbox/shogun/commit/ce652852c504edfad450a68e8b664702fcbd0b9c12:15
@wikingHeikoS, lambday ok so lets collect these c++11 related stuff into the feature/Cpp1112:15
@wikingbranch12:15
@HeikoSwiking: swig issue12:21
@wikingyes12:21
@wiking?12:21
@HeikoSswig2 will go?12:21
@wikingyes12:21
@HeikoSkk12:21
@HeikoSlambday ^12:21
@wikingsince it doesnt' support c++1112:21
@HeikoSgood12:21
@sukeyPull Request #3648 "[INCOMPLETE] fix travis and buildbot errors due to bigtest merge"  closed by karlnapf - https://github.com/shogun-toolbox/shogun/pull/364812:24
@wikingHeikoS, type this12:24
@wikinginto your console12:24
@wikingld.gold -version12:24
@HeikoSwiking: and then?12:25
@wikingcommand found12:25
@wikingor you get a version?12:25
@HeikoSGNU gold (GNU Binutils for Ubuntu 2.26.1) 1.1112:25
@wikingok cool12:25
@wikingso this case12:25
@wikinglinking the shogun-unit-test12:26
@wikingshould be a bit faster for you12:26
@wikingthan previously12:26
@wiking;)12:26
@HeikoSsince when=?12:26
@wikingmmm12:26
@wiking~1 week12:26
@HeikoSwiking: cool12:28
@HeikoS!12:28
-!- lambday_ [c40f170a@gateway/web/freenode/ip.196.15.23.10] has quit [Quit: Page closed]12:42
-!- mikeling [uid89706@gateway/web/irccloud.com/x-askancxenzczzoti] has joined #shogun13:15
mikelingwhat should I do if I want to use string as label in KNN? like I want to use KNN to classify alphabet('A', 'B', 'C'....)13:17
mikelingwhat kind of label I should use?13:18
@sukeyNew Commit "Make c++11 features a hard requirement for shogun" to shogun-toolbox/shogun by vigsterkr: https://github.com/shogun-toolbox/shogun/commit/cc9e896d1c6c6f681e7d7d2fa21976f429a76cb213:18
@wiking HeikoS ^13:18
@HeikoSmikeling: give every letter an integer13:19
mikelingHeikoS: I see, thank you :)13:19
@HeikoSmikeling: we have some notebook where KNN is used for digit classificaiton that is essentially the same13:20
@wikingHeikoS, and now let's have the rest fixed13:21
@HeikoSwiking: im in gdb13:21
@wiking:>13:21
@wikingHeikoS, ok sorry now i have to go back to finish up with the docker image13:25
@HeikoSwiking: sure13:28
@HeikoSwiking: im on reset_stream test failure with l13:28
@wiking:>13:29
@lambdayHeikoS: check inactive branches in travis : feature/bigtest...13:29
@HeikoSso there we go13:29
@HeikoSline 749 of InputParser13:30
@HeikoSon my machine bails13:31
@lambdayHeikoS: the bugfix PR I sent doesn't have anything to do with Cpp11... shall I keep this PR to develop then?13:35
@lambday(once I fix some other issues)13:35
@HeikoSlambday: you remove lines in there13:35
@HeikoSlambday: oh the feature branch is for both cpp11 and fixingf13:35
@lambdayHeikoS: okay13:35
@HeikoSlambday: so what does the PR do?13:36
@HeikoSI dont see that?13:36
@HeikoSI mean I get the includes13:36
@HeikoSbut the streaming stuff I dont get13:36
@HeikoSlambday: ^13:37
@lambdayHeikoS: (1) add #include <numeric> in a few unit tests that causes compilation fail in my gcc - these were required for std::iota (2) added a #ifdef check before I assert anything directly with ref_count().. this was causing a failure in buildbot..13:37
@HeikoSlambday: sure I get those as I said13:37
@HeikoSso you can push that commit to the feature branch already13:38
@wikingcherry pick those13:38
@wikingeasy13:38
@wikingput it in the feature branch13:38
@lambdayHeikoS: couldn't work on the streaming stuff as nothing works locally anymore.. so as discussed, I just reverted back my changes to keep just viktor's patch there and see whether that fixes the issue...13:38
@HeikoSlambday: but why revert the changes?13:39
@HeikoSI guess you did them for a reason no?13:39
@HeikoSas well as the unit test13:39
@HeikoSit wasnt there before so I guess you added it after finding a bug?13:39
@HeikoSand I mean the test has to pass, looking at it13:39
@HeikoSlambday: resetting the stream after streaming a few data should be possible13:40
@lambdayHeikoS: yeah I added it after finding a bug.. but then a couple of things changed in that as viktor added std::thread there.. had a merge conflict as well.. hence was just trying to see whether his changes were enough to kill the bug..13:41
@HeikoSlambday: ok so lets not remove things, but fix the test13:41
@lambdayHeikoS: but since I couldn't test anything locally, I abused travis for that13:41
@lambdayhence the INCOMPLETE in the title :D13:41
@HeikoSlambday: now youre on laptop?13:41
@lambdayHeikoS: yes13:41
@HeikoSok so I am just ddd-ing the test13:42
@HeikoSit is the reset call that is the problem13:42
@wikingcan i ask an intimate question13:42
@wikinghow did this ever passed any CI in the feature branch?13:43
@lambdayHeikoS: yeah... resetting should be possible even when all the examples are streamed.. it should simply reset to the first example..13:43
@lambdayotherwise dense feature based streaming will not work13:43
@HeikoSlambday: yes exactly13:43
@HeikoSis there any assumptions on reset_stream() call wiking?13:44
@wikingwhat i dont even know what you are talking about?13:44
@wiking:)13:44
@HeikoSwiking: on dont worry ;)13:44
@HeikoSlambday:  open this13:45
@HeikoSreset13:45
@HeikoSStreamingDenseFeatures::reset_stream13:45
@HeikoSline 6513:45
@HeikoSso there the parser is exited, and then restarted13:45
@HeikoSand the exit thing fails13:45
@lambdayHeikoS: yeah13:45
@HeikoSso why can't we exit it?13:46
@lambdaywhat does valgrind say?13:46
@HeikoSparse_thread.reset() fails13:46
@lambdaythat's the c++11 version13:47
@lambdaywhy would that fail13:47
@HeikoSvalgrind tells me that as well13:48
@HeikoSProcess terminating with default action of signal 6 (SIGABRT)13:48
@lambdaywait parse_thread is a stack variable?13:48
@lambdaywait13:48
@lambdayoh ok that's a shared_ptr thing13:48
@lambdayso maybe shared_ptr::reset won't do it13:49
@HeikoShttp://en.cppreference.com/w/cpp/memory/shared_ptr/reset13:49
@lambdayHeikoS: so what does it say? invalid delete or something?13:50
@HeikoSlambday: are you reproducing this?13:50
@HeikoSpasted above13:50
@lambdayHeikoS: can't... doesn't work here :(13:50
@HeikoSlambday: what doesnt work?13:50
@lambdayHeikoS: nothing that requires threading13:50
@HeikoS??13:50
@lambdaygotta look into it13:51
@HeikoSthats c++1113:51
@lambdayHeikoS: yeah I know.. trying it again now13:51
@lambdayHeikoS: internally all these std::thread uses pthread or winthread (or whatever) I presume..13:52
@HeikoSthink it might be this: http://stackoverflow.com/questions/3413166/when-does-a-process-get-sigabrt-signal-613:52
@HeikoSthe thread example13:52
@lambdayHeikoS: detatch?13:53
@HeikoS==27265==    by 0x1A963EE: std::thread::~thread() (thread:151)13:53
@HeikoSpart of valgrind stacktrace13:53
@HeikoSso whats up with your config?13:53
@HeikoShere we go: http://en.cppreference.com/w/cpp/thread/thread/~thread13:54
@HeikoSthats where the std::terminate call comes from13:54
@lambdayHeikoS: so it's the dtor call that gives the error?13:55
@HeikoSreproduce13:55
@HeikoSthe stack trace13:55
@HeikoSbut yes13:55
@HeikoSI mean no13:55
@HeikoSit is as I wrote above13:56
@HeikoSso this seems some bug in the input parser thread handling13:56
@lambdayHeikoS: yeah13:56
@lambdaystd::thread13:56
@lambdayif we had the streaming parser unit test there in develop, it would have been caught13:59
@wikingbut after the rebase?14:01
@wikingi mean i wonder why it wasn't caught after you've guys rebased the feature branch14:01
@wikingprior merging14:01
@lambdaywiking: yeah we were in a hurry cause this thing have been sitting there for a long time.. screwed up a few things.. but good that we'll fix it now as it became an issue14:02
@wikingwell14:02
@wikingyou know that14:02
@HeikoSwiking: it seems pthread_cancel and ~thread are a bit different14:02
@wikingthis is sub standard14:02
@wikingcompared to what we ask from the students14:02
@wiking:)14:02
@lambdaywiking: agreed.. no arguments there :(14:03
@HeikoSso this thing is a bug14:03
@HeikoSand previously, we just didnt have any test for it14:03
@HeikoSso lets fix it and move on14:03
@lambdaydebug mode takes forever to compile14:05
@lambdayargh14:05
@HeikoSccache14:05
@lambdayHeikoS: yeah but the cache is filled with release things :/14:05
@lambdayit must be caching these things now14:05
@HeikoSI never compile release locally14:05
@wikingccache -M 10G14:05
@wikingthat's the first thing you do14:06
@lambdayHeikoS: I do when I use perf to profile14:06
@wikingand then you'll have both of the things cached14:06
@lambdaywiking: 10G is what I have... just upgraded the OS a week back so everything is brand new14:06
@wikingcopy cache14:06
@wiking:)14:06
@HeikoSwiking: only works if you dont compile feature branches ;)14:07
@HeikoSI have 10G but sometimes have to wait still14:07
@HeikoSbut anyways14:07
@wikingyeah well that's c++ for ya14:07
@wiking:>14:07
@HeikoSwiking: modules will help14:07
@wikingyep should14:07
@HeikoSannoying to have compile all of the eigen3 stuff for fixing thread issues14:08
@wikingmmm14:08
@wikingbu that should really not trigger14:08
@wikingbranch new compilation14:08
@wikingi.e. ccache should catch it14:08
@wikingbtw ninja + ccache is really a speedup14:08
@HeikoSlambday: hows the compile going?14:11
@HeikoSlambday: keep in mind you can disable libshogun examples and meta examples14:11
-!- travis-ci [~travis-ci@ec2-54-163-161-247.compute-1.amazonaws.com] has joined #shogun14:12
travis-ciit's Viktor Gal's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/20378279214:12
-!- travis-ci [~travis-ci@ec2-54-163-161-247.compute-1.amazonaws.com] has left #shogun []14:12
@wikinglet's see what failed :)14:13
@wikingok only 132 - unit-StreamingDenseFeaturesTest (OTHER_FAULT)14:13
@wikingwhich i guess you guys are working on now14:14
@wikinglemme see msvc14:14
@lambdayHeikoS: yeah compilation is done.. some error with linking.. checking now14:14
@HeikoSwiking: yep14:14
@HeikoSthere is also the two disabled ones14:15
@wikinglambday, so14:15
@wiking#pragma omp parallel for14:15
@wikingfor (size_t i=0; i<blocks.size(); ++i)14:15
@wiking:)14:15
@wikingthis is foobar14:15
@wiking OpenMP 2.0 C/C++ API specification (pdf), section 2.4.114:15
@wikingso please follow standards14:16
@lambdaywiking: lol you sound like a lawyer.. yeah my bad..14:16
@wikinglambday, yeah man14:16
@wikingbecause i spend countless time14:16
@wikingto get this in shape14:16
@wikingand it's really fucking hard14:16
@wikingto get support for an os14:17
@wikingthat you dont have14:17
@wikinghence my frustration14:17
@lambdaywiking: yeah good that msvc caught it.. otherwise gcc/clang simply lets it go14:17
@lambdayand it's hard to check everything at standard beforehand unless a compiler complains.. but now we have 3 different compilers running14:18
@HeikoSwiking: you have comments on this : http://stackoverflow.com/questions/4760687/cancelling-a-thread-using-pthread-cancel-good-practice-or-bad14:18
@wikingmmm14:19
@wikingwhy dont you use an atomic_flag?14:19
@wikingnow that you have full c++11 support14:19
@HeikoShttp://en.cppreference.com/w/cpp/thread/thread/~thread14:19
@HeikoSin the InputParser patch you did14:19
@HeikoSyou call thread destructor14:19
@HeikoSwhere previously there was pthread_cancel14:20
@wikingmmm is it joinable?14:20
@HeikoSmust be14:20
@HeikoSotherwise there wouldnt be an exception14:20
@HeikoSso there is CInputParser<T>::end_parser()14:20
@HeikoSI just wonder whether we can call that before the exit_parser() and then it is good14:21
@HeikoSin the reset implementation14:21
@wikingmm where the dtor?14:21
@wikingah you mean parse_thread.reset();14:21
@HeikoSyep14:21
@wikingand what is the stacktrace?14:22
@HeikoSill paste14:22
@lambdayHeikoS: good lord.. works finally now.. can see the error14:23
@HeikoSlambday: good14:23
@HeikoShttps://gist.github.com/karlnapf/6c6fea39c7c4b98fffe10383657eb8c714:24
@HeikoSwiking, lambday ^14:24
@lambdayHeikoS: lol man I see a very different error here14:25
@wikingHeikoS, why valgrind? :)14:25
@HeikoSwiking: was interested in something else14:26
@HeikoSbut dont worry have gdb open as well14:26
@lambdayHeikoS: https://gist.github.com/lambday/4dc6bc9e0b8355d61069c2e0fabf634914:26
@wikingmadonna14:27
@wiking../src/shogun/statistical_testing/internals/mmd/PermutationMMD.h:190:51: error: use of overloaded operator '[]' is ambiguous (with operand types 'SGVector<float64_t>' (aka 'SGVector<double>') and 'size_t' (aka 'unsigned long'))14:27
@wikingwtf14:27
@wikinghow did this ever fucking compiled14:27
-!- goksinen_ [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun14:29
@lambdaywiking: what's wrong with SG_SDEBUG("Kernel(%d): p_value=%f\n", k, result[k]);14:29
@wikingsee14:29
@wikingthat's the error14:29
@wikingthere14:29
@wikingsize_t14:29
@wikingagain14:29
@wiking:)14:29
@HeikoSwiking: you got any idea about this thread cancel thing?14:30
@wikingHeikoS, yeah i wanted to help14:30
@wikingbut i cannot evne compile this code on my machine14:30
@wikingsee one sample of the error14:31
@wikingbut i have like 100+ errors14:31
@lambdaywiking: what should we do about these errors? size_t is there to iterate over std::vector otherwise it gives a ton of warnings.. but then cannot use it as index in SGVector.. so cast it every time?14:32
@wikinghttps://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/statistical_testing/internals/mmd/PermutationMMD.h#L97-L11614:32
@wikingi dont know what this does14:32
@wikingbut if ou have to go down14:32
@wiking4 levels of a for nestedness14:32
@wikingthere's clearly14:32
@wikingsomething wrong with the design14:32
@wiking(my 2 cents)14:32
-!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds]14:32
@lambdaywiking: makes sense when the outer loop is usually 10-20..14:33
@wikingno14:33
@wikingit does not14:33
@wikingnot because14:33
@wikingit's functionally14:33
@wikingmaybe right14:33
@wikingit's because this is untracable14:33
@wikingby anybody else who wants to touch this code14:34
@wikingif you have to have 4 for loops14:34
@wikingnested14:34
@wikingthen you should cut this up14:34
@lambdaywiking: unwrap?14:34
@wikingdo you really think that anybody14:34
@wikingwho looks at this code14:34
@wikingwith have 0 commend14:34
@wiking0 comments14:34
@wikingcan do anything else14:35
@wikingbut14:35
@wikinggdb14:35
@wikingn14:35
@wikingn14:35
@wikingn14:35
@wikingn14:35
@wikingn14:35
@wikings14:35
@wikings14:35
@wikings14:35
@wikingn14:35
@wikingn14:35
@wikinghttps://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/statistical_testing/internals/mmd/PermutationMMD.h#L21514:36
@lambdaywiking: well I have some optimization things planned for these.. this entire thing was done in 3 months.. so the priority was to get it merged first.. once it works, will do some modification14:36
@wikingand what happens when null_samples.size() =0 ?14:36
@wikingjust go and do lalala?14:36
@wikingi mean this is just 2 seconds14:37
@wikinglooking at this codebase14:37
@wikingi'm sorry man14:37
@HeikoScan we pls fix the thread bug?14:38
@wikingHeikoS, i'm trying to compile the code :14:38
@wiking:D14:38
@HeikoSso here is a problem I have with the cmake build atm14:40
@HeikoSI change InputParser.h14:40
@HeikoSI make14:40
@HeikoSand then the changes are not executed when running unit tests14:40
@HeikoSgdb shows the right source but the execution is the unchanged file14:42
@HeikoSsigh14:42
@HeikoSwiking: removing the shogun-unit-test bin doesnt help14:44
@wikingdunno14:45
@wikingHeikoS, mmm it actually should just14:46
@wikingrelink14:46
@HeikoSremoving libshogun.so* also didnt help14:46
@HeikoSjust deleted build dir14:46
@wikingmmm i dont think that's good solution :)14:48
@HeikoSnope14:49
@HeikoSnot sure what is going on there14:50
@wikingHeikoS, LIBSHOGUN_HEADERS14:50
@wikingadd_library(libshogun OBJECT ${LIBSHOGUN_SRC} ${CMAKE_CURRENT_BINARY_DIR}/lib/config.h)14:50
@wikingadd it there14:50
@HeikoSfile?14:50
@wikingsrc/shogun/CMakeLists.txt14:50
@HeikoSkk14:50
@wikingline 3314:50
@lambdayHeikoS: fixed the bug... turns out, adding a parse_thread->join(); before the parse_thread.reset() in the InputParser::exit_parser() does it for you :)14:51
@lambdaybefore calling dtor, threads must be joined or detatched14:52
@HeikoSlambday: yeah was trying to do that as well but then realised I never executed the new code14:52
@HeikoSI am not sure that is a solution14:52
@lambdayHeikoS: why14:52
@HeikoSrather call end_parser() before exit_parser in the reset_stream method14:52
@lambdayHeikoS: from the stack overflow link you pasted:14:52
@lambdayThere's another simple cause in case of c++.  std::thread::~thread{     if((joinable ())         std::terminate (); } i.e. scope of thread ended but you forgot to call either  thread::join(); or  thread::detach();14:52
@lambdayHeikoS: well, end parser does the join for you14:53
@lambdayso that is the solution14:53
@HeikoSpls dont do it in InputParser.h14:54
@HeikoSor if you do it, document it clearly14:54
@HeikoSwiking: how should the line look like?14:54
@wikingwhat link?14:55
@wikingline14:55
@wikingadd that thing to it14:55
@wiking${LIBSHOGUN_HEADERS}14:55
@lambdayHeikoS: yeah I am changing it in Streaming things where this exit parser thing is called14:55
@HeikoSthe file is streaming/InputParser.h14:56
@HeikoSwiking: FILE(GLOB_RECURSE LIBSHOGUN_HEADERS *.${EXT_SRC_HEADER})14:59
@HeikoSthat should catch it14:59
@wiking dont know what are you talking about exactly14:59
@wikingtold you14:59
@wikingadd ${LIBSHOGUN_HEADERS} to line 3314:59
@wikingok so this whole story with size_t is going to be super funny15:00
@wikingbecause do to that neither msvc15:00
@wikingnor osx will work15:00
@wikingand that is a lot of fucking code there15:00
@HeikoSwiking: kk worked15:01
@wikingman we were about 1 step15:01
@wikingfrom releasing15:01
@wiking....15:01
@wikingin fact only fucking octave was failing15:02
@sukeyPull Request #3649 "Fixed the reset_stream bug caused by InputParser::exit_parser"  opened by lambday - https://github.com/shogun-toolbox/shogun/pull/364915:02
@wikinglambday, could you just put that15:03
@wikinginto the feature branch15:03
@wikingplease15:03
@lambdayHeikoS: sent a PR with just this fix.. will send another15:03
@sukeyPull Request #3649 "Fixed the reset_stream bug caused by InputParser::exit_parser"  closed by vigsterkr - https://github.com/shogun-toolbox/shogun/pull/364915:03
@wikingno need for a pr15:03
@lambdaywiking: okay cool15:03
@wikingjust directly push it into the feature branch15:03
@wikingfeature branch + pr is again15:03
@wikingfoobar15:03
@sukeyNew Commit "Fixed the reset_stream bug caused by InputParser::exit_parser15:03
@sukey  The method exit_parser calls the destructor of the std::thread15:03
@sukey  object (assuming C++11 is present). A thread join or detatch15:03
@lambdaydone15:03
@sukey  must be performed before this. So, added a check before calling15:04
@sukey  exit_parser in StreamingDenseFeatures and StreamingVwFeatures15:04
@sukey  whether the parser is in running state. If it is, then added a15:04
@sukey  call to end_parser() before calling exit_parser(), which does15:04
@sukey  the thread join." to shogun-toolbox/shogun by lambday: https://github.com/shogun-toolbox/shogun/commit/abd674c74f3c1eb970de7121c01767ea5e7980fc15:04
@HeikoSlambday: otherwise it is two travis runs15:05
@lambdayHeikoS: yeah I understand that.. wanted to keep a snapshot but I guess my commit message captures most of it15:05
@wiking?15:06
@wikingedes jo istenem15:06
@HeikoS?15:06
@HeikoScommit is there15:06
@wikinglooking at this where to start with15:07
@wikingyeah man15:07
@wikingyou dont see15:07
@wikingthe heaps of errors15:07
@wikingthat is in front of me15:07
@wikingi had osx fixed15:07
@wiking:)15:07
@wikingnow it's like ....15:07
@wikinglambday, for future reference http://wesmckinney.com/blog/avoid-unsigned-integers/15:08
@HeikoSgotta go, see you guys15:12
@lambdayHeikoS: see you15:13
@lambdayHeikoS: will merge other fixes to the develop branch15:13
@lambdayHeikoS: did you push anything?15:13
@HeikoSlambday: other fixes? develop branch?15:13
@lambdayoops.. feature branch15:13
@HeikoSah yeah15:13
@HeikoSyou had the numeric things15:13
@HeikoSand then size_t15:13
@lambdaywiking is working on it I guess15:13
@wikingno15:13
@wikingthat's why too much of a code15:14
@wikingi'm not touching that15:14
@wikingauto t_7=m_sum_y*m_sum_xy*2/m_n_y/m_n_y/(m_n_y-1)/m_n_x;15:14
@lambdaywiking: alright I'll do it15:14
@wikingthings like this15:14
@wikingyou do realise15:14
@wikingthat z=  1/m_n_y15:14
@wikingand then do *z15:14
@wikingis much faster right?15:14
@lambdaywiking: most of the compiler optimizer does it already I guess15:14
@wikingnoup15:14
@wikingit does not15:15
@wikingauto t_3=m_sum_x*m_sum_xy*2/m_n_x/m_n_x/(m_n_x-1)/m_n_y;15:15
@wiking:)15:15
@wikingespecially with beauties like this15:15
@wikingyou are asking for a / operand15:15
@wikingnot a *15:15
@lambdaywiking: yeah I trusted the optimzier to take care of this.. no worries.. will create the temporaries.. it's way faster15:15
@wikingmm15:16
@wikingthis was way too early15:16
@wikingto merge this15:16
@wikingcould have waited 1 more release15:16
@lambdaywiking: well, people have been asking for it for a long time.. apparently they couldn't switch to the feature branch properly.. so as more and more people start to use these things, we'll work on optimizations15:17
@wikingit's not about optimisation15:17
@lambdaywiking: plus arthur's students may also use this thing15:17
@wikingit's about portable code15:17
@wikingthat compiles15:17
@wikingthis is not jvm15:17
@wikingnor python15:17
@sukeyNew Commit "Re-enable the failing linear time mmd unit tests15:18
@wikingi'm really pissed because i worked more than a month to get shogun into a releasable state15:18
@sukeyThis reverts commit 1560b3b39e214be4cd066c6ca4005496dc9a3354." to shogun-toolbox/shogun by karlnapf: https://github.com/shogun-toolbox/shogun/commit/216060d95c72e10f703ac7f3a85f33a7e0c8c69b15:18
@lambdaywell, we should have checked the msvc15:18
@wikingmuch more than that15:18
@HeikoSremember I merged15:18
@HeikoSnot lambday15:18
@wikingi dont care who merged it15:19
@wikingit's fucked15:19
@HeikoSyep, lets fix it15:19
@wikingand its a lot of hushus fixing15:19
@wikingnow15:19
@wikingi mean man15:19
@wikingdo you get it that i cannot compile the code15:19
@wikinglocally15:19
@wikingeven if i want to fix other shit15:19
@wikingi have to go back t-k15:19
@wikingin the develop15:19
@wikingto fix stuff15:19
@HeikoScan you paste compile errors? I can help lambday15:20
@lambdaywiking: your gcc/clang doesn't compile this or vc++?15:20
@wikingneither15:20
@wikingHeikoS, already did15:21
@HeikoSkk15:21
@wikinghttp://pastebin.com/VbChRuha15:22
@lambdaywiking: cool thanks..15:23
@wikingthis could be still fixed15:23
@lambdaywill fix these15:23
@wikingbut15:23
@wikingi mean defining15:23
@wikingbut the problem comes with size_t + omp15:23
@wikinghence they should be fixed at once15:23
@lambdaywiking: looks like all of these errors are caused by size_t15:25
@wikingyep15:25
@lambdaywiking: can I check it somewhere whether the vc++ thing compiles it or not? in the feature branch I mean15:26
@HeikoSlambday: there is a badge15:26
@HeikoSlambday: do you acutally re-allocate sizes of the vectors you are using? otherwise why not just use SGVector if they are fixed sizes?15:26
@lambdayHeikoS: yeah.. re-allocating15:27
@HeikoSlambday: https://ci.appveyor.com/project/vigsterkr/shogun/history15:27
@lambdayHeikoS: cool thanks15:28
@HeikoSlambday: where do they grow/shrink?15:28
@HeikoScan you point me to the code?15:28
@lambdayHeikoS: let me check15:28
@HeikoSPermutationMMD.h:22615:29
@wikingmmm15:29
@wikinglambday, btw15:29
@wikingusing std::vector15:29
@wikingand such15:29
@wikingis a bit foobar15:29
@wikingif you are not passing15:29
@wikingshogun's allocator15:29
@wikingright? :)15:30
@wikingi mean just to be code correct here15:30
@lambdaywiking: no I haven't used shogun's allocator15:30
@HeikoSall these calls are quite straight forward to do with SGVector I think, so maybe just change them to that?15:30
@wikingyep that' what i mean15:30
@HeikoSif there is just a few of these calls easiest15:30
@wikinglambday, there's a good reason shogun has wrapped all the allocator's internally15:31
@wikingnota bene15:31
@wikingjemalloc15:31
@wikingvs malloc of linux15:31
@lambdayHeikoS: what about the resize call? when calling the permutation thing over and over again..15:32
@HeikoSSGVector.h has resize_vector15:32
@HeikoSyou can make that a method of SGVector15:33
@HeikoSuses realloc etc15:33
@HeikoSwith that, it is pretty minimal to get rid of the std::vector, just grepped for resize calls, there are not too many15:34
@lambdayHeikoS: yep.. just thought std::vector does it a lot efficiently.. but will have to benchmark that then..15:34
@wikinglambday, not at all15:34
@HeikoSwhy?15:34
@HeikoSrealloc15:34
@HeikoSwhat else is there to do?15:34
@wikinglambday, especially if you cannot change the allocator of std::vector15:35
@wikingi mean if you dont change it15:35
@HeikoSThe best way I think is to avoid resizing at all (especially in loops)15:35
@wikingin that case SGVector could be much faster15:35
@HeikoSbut I think if you just resize once in the beginning, then it doesnt even matter15:35
@HeikoSso thats a fix with few changes to the code15:36
@HeikoSIll be afk for an hour now15:36
@lambdaywill benchmark it.. maybe use a custom allocator with std::vector and see..15:38
@wikinglambday, https://locklessinc.com/benchmarks_allocator.shtml15:38
@lambdayif SGVector is just as fast, then will use that15:38
@wikinglambday, many people did it already15:38
@wikingno need for t+1 memory allocator benchmarks15:38
@wikinglambday, you are missing the point here15:39
@lambdaywiking: yeah I meant between SGvector and std::vector15:39
@wikingthe idea is shogun is15:39
@wikingthat your memory allocator backend15:39
@wikingis changable15:39
@wikingand not just the system's malloc15:39
@wikingnow you can plug std::vector to be using15:40
@wikingthe custom malloc15:40
@wikingbut that needs some extra work15:40
@lambdaywiking: yeah using shogun's SG_MALLOC in std::vector.. that's what I was thinking of doing15:40
@wikingbut again15:40
@wikingi dont know what you think15:40
@wikingwhat sorts of magic is in15:40
@wikingstl's vector15:41
@wikingregarding resize15:41
-!- HeikoS [~heiko@host-92-0-178-129.as43234.net] has quit [Ping timeout: 260 seconds]15:41
@lambdaywiking: saw in some cppcon video I think.. or some article.. some guys said that their custom vector class is not as fast as stl.. so maybe best way to be sure is to check how we are doing in Shogun15:42
@wikingmmm15:42
@wikingyou realise15:42
@wikingthat that depends15:42
@wiking"some guys said that their custom vector class is not as fast as stl'15:42
@wikingwhich stl implementation?15:42
@wiking:)15:42
@lambdaywiking: haha yeah.. that's why I said.. gotta check.. the committee won't let it be slower in future at least15:45
@wikingwhich committee?15:45
@lambdayc++15:45
@lambdaystl15:45
@wikingi mean there are a lot of stl implementations out there15:45
@wikingand nobody has any control over it15:45
@wikingmaximum it's interface15:45
@lambdaygcc and clang guys15:45
@wikingand?15:45
@wikingyou do realise15:46
@wikingthat there are millions of fork15:46
@wikingof compilers15:46
@wikingjust from gcc itself15:46
@wikingwhere the implementation is different15:46
@wikingand not to talk about some other custom compilers15:46
@lambdaypoint is - things aren't getting slower..15:46
@wiking?15:46
@wikinghow would you assure that?15:46
@wikingi dont see how can you assure that some operation wouldn't get slower15:47
@lambdayhard to argue with that.. I cannot prove that things will never be slower..15:48
@wikingi mean sorry15:48
@wikingbut this is pretty much up to an implementaiton15:48
@wikingthings are slower and faster15:48
@wikingthe goal is to get things faster15:48
@wikingbut obviously15:48
@wikingthis has been many many times not the case15:48
@wiking(see various notable stories of gcc15:48
@wikingwhen 5.0 was way slower than 4.x branch15:48
@wiking(in the produced code)15:48
@lambdayI am missing the point here.. as long as it's internal code and doesn't screw up swig, why shouldn't we use it, as long as it is faster NOW in 2-3 major compilers that we love and support?15:50
@lambdayI am not claiming that it is faster, but if it was15:51
@wikingbecause15:51
@wikingit's A) not following anything that has to do with shogun15:51
@wikingwhich is fine15:51
@wikingbut why do we merge it?15:51
@wikingb) it doesn't work :)15:51
@lambdayb) can be fixed, right?15:51
@wikingdunno dont even wanna think about it to be honest15:51
@wikingbut15:52
@wikingthen please make sure15:52
@wikingthat the allocators15:52
@wikingare actually overridable15:52
@wikingi mean if it's about creating15:52
@wiking2 arrays15:52
@wikingof size 1015:52
@wikingit's ok doesn't matter15:52
@wikingbut in this case15:52
@wikingthis seems like a lot of mumbo jumbo on the memory allocator backend15:53
@lambdayokay so for now I'll simply switch to SGVector for std::vector and SGMatrix for std::vector<std::vector>...15:53
@wikingyeah i mean15:53
@wikingstd::vector<std::vector>15:54
@wikingis15:54
@lambdayif later in my perf alloc/dealloc comes as hotspot, then I'll change15:54
@wikingkiiindof15:54
@wikingsuspectable15:54
@wikingthat is going to be slower than sgmatrix15:54
@wiking:)15:54
@lambdayit's contiguous :) ..15:55
@lambdayanyway dw I'll change these15:55
@lambdayusing std::vector was anyway a premature optimization attempt15:56
@wikingbtw for codes like this15:57
@wikingfor (size_t k=0; k<kernel_mgr.num_kernels(); ++k)15:58
@wiking{15:58
@wikingauto kernel=kernel_mgr.kernel_at(k);15:58
@wiking15:58
@wikingyou are obviously iterating through in order.... so if this is the usual/or most used case15:58
@wikingand push_back16:00
@wikingmmm so yeah16:00
@wikingdeque like struct woudl be maaaybe a better option16:00
@wikingright?16:00
@lambdaywiking: maybe.. but the golden rule that I know is, use vector whenever possible.. least overhead.. push_back is not that bad if we call reserve first16:01
@wiking?16:01
@lambdaybut yeah will surely check whether this needs modification16:01
@wikingwhere have u read this golden rule?16:01
@wikingleast overhead?16:02
@wiking :)16:02
@wikingmmm interesting concepts16:02
@lambdaybjarne :)16:02
@lambdaycppcon 2014, 2015, 2016.. herb sutter16:02
@wikingi mean if you use push_back for insertation16:02
@wikingthen i would not use a vector16:02
@wikingwhy do you need the random access then?16:02
@wikinganyhow16:03
@wikingjust a thought16:03
@lambdaytrue.. so v.reserve(some_size) saves a lot of time ... chandler carruth showed a benchmark on that16:03
@lambdaywill perf it all dw :D16:03
@lambdayonce I get this thing compiled and merged properly16:03
@sukeyPull Request #3650 "Port DistanceMachine and Inference to use OpenMP"  opened by abhinavrai44 - https://github.com/shogun-toolbox/shogun/pull/365016:28
-!- travis-ci [~travis-ci@ec2-54-163-161-247.compute-1.amazonaws.com] has joined #shogun16:44
travis-ciit's lambday's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/20381245416:44
-!- travis-ci [~travis-ci@ec2-54-163-161-247.compute-1.amazonaws.com] has left #shogun []16:44
-!- HeikoS [~heiko@host-92-0-178-129.as43234.net] has joined #shogun16:52
-!- mode/#shogun [+o HeikoS] by ChanServ16:52
@HeikoSlambday: jo16:52
@HeikoSbcak16:52
@HeikoSback16:52
-!- kesslerfrost [~textual@49.44.51.53] has joined #shogun17:02
-!- HeikoS [~heiko@host-92-0-178-129.as43234.net] has quit [Ping timeout: 260 seconds]17:15
-!- HeikoS [~heiko@host-92-0-178-129.as43234.net] has joined #shogun17:25
-!- mode/#shogun [+o HeikoS] by ChanServ17:25
-!- travis-ci [~travis-ci@ec2-54-221-60-16.compute-1.amazonaws.com] has joined #shogun17:29
travis-ciit's Heiko Strathmann's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/20381766217:29
-!- travis-ci [~travis-ci@ec2-54-221-60-16.compute-1.amazonaws.com] has left #shogun []17:29
-!- kesslerfrost [~textual@49.44.51.53] has quit [Ping timeout: 260 seconds]17:32
@sukeyIssue #1265 "An alternative to dropping the modelselection framework" closed by karlnapf - https://github.com/shogun-toolbox/shogun/issues/126517:52
@sukeyNew Commit "removing permutation test for linear time MMD17:54
@sukeyIt does not make sense to run this as there is the Gaussian approximation of the null distribution. Removing unit tests (were buggy), changing default behaviour, and throwing an error if used," to shogun-toolbox/shogun by karlnapf: https://github.com/shogun-toolbox/shogun/commit/6c73ef0aceb2dd1b3ae7c97feb803c667c53c6c517:54
-!- kesslerfrost [~textual@2405:204:81:c3:4cfa:62ef:18bd:e9d8] has joined #shogun18:38
-!- mikeling [uid89706@gateway/web/irccloud.com/x-askancxenzczzoti] has quit [Quit: Connection closed for inactivity]18:39
-!- kesslerfrost [~textual@2405:204:81:c3:4cfa:62ef:18bd:e9d8] has quit [Ping timeout: 240 seconds]18:45
-!- travis-ci [~travis-ci@ec2-54-80-105-186.compute-1.amazonaws.com] has joined #shogun18:55
travis-ciit's Heiko Strathmann's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/20387821218:55
-!- travis-ci [~travis-ci@ec2-54-80-105-186.compute-1.amazonaws.com] has left #shogun []18:55
CaBaHeikoS: ping19:04
@HeikoSCaBa: pong19:07
CaBaHeikoS: never mind, i think i found my problem...19:28
CaBaHeikoS: had some memory pain, my ::clone() impl from yesterday doesn't SG_REF the clone though...19:29
@HeikoSthats imporatnt :)19:43
@HeikoSbtw you have mac right?19:43
@HeikoScan you do me a fav?19:43
@HeikoSCaBa: could you pull a feature branch and build it, then paste compile errors somewhere?19:44
CaBasure19:44
@sukeyNew Commit "get rid of size_t ambiguity19:44
@sukeyVia replacing key quantities with index_t, and some hard casting. WIP" to shogun-toolbox/shogun by karlnapf: https://github.com/shogun-toolbox/shogun/commit/c7230c5a0919403bf5a48522d8089fe66275dca619:44
@HeikoSCaBa: this one19:45
@HeikoSfeature/Cpp1119:45
CaBaHeikoS: https://gitlab.unique-internet.de/snippets/1219:51
CaBaHeikoS: this is clang though. no openmp. i'll hit a gcc build in a sec19:51
@sukeyNew Commit "get rid of size_t ambiguity and openmp loop std violations19:52
@sukeyVia replacing key quantities with index_t, and some hard casting. WIP" to shogun-toolbox/shogun by karlnapf: https://github.com/shogun-toolbox/shogun/commit/25b469ca78d1227668d46b5c0e85c3f578aa634319:52
@HeikoSCaBa: I cannot open this paste19:52
CaBaoops19:52
@HeikoSno clang is good19:52
@HeikoSI just pushed again19:52
CaBaHeikoS: now you can19:53
CaBaHeikoS: should i pull and rebuild?19:53
@HeikoSwait ill fix these things first and then19:53
@HeikoSok again pls :)19:54
@sukeyNew Commit "get rid of size_t ambiguity and openmp loop std violations19:54
@sukeyVia replacing key quantities with index_t, and some hard casting." to shogun-toolbox/shogun by karlnapf: https://github.com/shogun-toolbox/shogun/commit/36c672eff0f199ff8efd1368eef74f7c0d5951e219:54
@HeikoSCaBa: and?19:57
CaBabuilding19:57
@HeikoSCaBa: so no early fail?19:58
@HeikoSphew :)19:58
CaBalinking19:58
@HeikoSah so it compiled great19:58
CaBayep, did.19:58
@HeikoSthanks!19:59
@HeikoSim off then for today19:59
CaBaHeikoS: np, schönen feierabend19:59
-!- travis-ci [~travis-ci@ec2-54-163-161-247.compute-1.amazonaws.com] has joined #shogun19:59
travis-ciit's Heiko Strathmann's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/20392097819:59
-!- travis-ci [~travis-ci@ec2-54-163-161-247.compute-1.amazonaws.com] has left #shogun []19:59
-!- HeikoS [~heiko@host-92-0-178-129.as43234.net] has quit [Ping timeout: 260 seconds]20:18
-!- HeikoS [~heiko@host-92-0-178-129.as43234.net] has joined #shogun20:24
-!- mode/#shogun [+o HeikoS] by ChanServ20:24
-!- HeikoS [~heiko@host-92-0-178-129.as43234.net] has quit [Ping timeout: 260 seconds]20:30
-!- HeikoS [~heiko@host-92-0-178-129.as43234.net] has joined #shogun20:33
-!- mode/#shogun [+o HeikoS] by ChanServ20:33
-!- HeikoS [~heiko@host-92-0-178-129.as43234.net] has quit [Ping timeout: 260 seconds]20:43
-!- travis-ci [~travis-ci@ec2-54-80-105-186.compute-1.amazonaws.com] has joined #shogun20:52
travis-ciit's Heiko Strathmann's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/20392155720:52
-!- travis-ci [~travis-ci@ec2-54-80-105-186.compute-1.amazonaws.com] has left #shogun []20:52
-!- Saurabh7_ [Saurabh7@gateway/shell/panicbnc/x-hgvqtjoqeqsvjmky] has quit [Ping timeout: 255 seconds]21:38
-!- Saurabh7_ [Saurabh7@gateway/shell/panicbnc/x-womzakxhpdtxgptp] has joined #shogun21:41
@sukeyIssue #3651 "LibSVM train() error. (with BinaryLabels)" opened by mcavdar - https://github.com/shogun-toolbox/shogun/issues/365121:46
-!- lambday [31cf349d@gateway/web/freenode/ip.49.207.52.157] has quit [Ping timeout: 260 seconds]21:47
@sukeyIssue #3651 "LibSVM train() error. (with BinaryLabels)"- https://github.com/shogun-toolbox/shogun/issues/365121:50
-!- HeikoS [~heiko@host-92-0-178-129.as43234.net] has joined #shogun22:17
-!- mode/#shogun [+o HeikoS] by ChanServ22:17
@sukeyPull Request #3441 "Fix ROC evaluation to properly access binary labels"  synchronized by lkuchenb - https://github.com/shogun-toolbox/shogun/pull/344122:51
@sukeyNew Commit "use CMath::gcd rather than C++17 and std::function" to shogun-toolbox/shogun by karlnapf: https://github.com/shogun-toolbox/shogun/commit/ff0f8f771d8898eaf4840065fc988ffb7dba026d23:13
-!- HeikoS [~heiko@host-92-0-178-129.as43234.net] has quit [Ping timeout: 255 seconds]23:20
@sukeyNew Commit "Be consistent with the override marker23:27
@sukeyinclude missing numeric header23:27
@sukeymake the libshogun target depend on headers as well" to shogun-toolbox/shogun by vigsterkr: https://github.com/shogun-toolbox/shogun/commit/ed5f712d3ba1b2ca76fa53a1c87106bb99333d7523:27
-!- HeikoS [~heiko@host-92-0-178-129.as43234.net] has joined #shogun23:36
-!- mode/#shogun [+o HeikoS] by ChanServ23:36
@HeikoSwiking: jojo23:37
@wikingho23:37
@HeikoSwiking: so travis was fine23:37
@HeikoSand windows should be fine with my last push23:37
@HeikoSI'll go to bed soon, see you for the meeting then23:39
@wikingok23:43
@wikingwhen everything is green23:43
@wikingi'll merge this23:43
-!- HeikoS [~heiko@host-92-0-178-129.as43234.net] has quit [Ping timeout: 240 seconds]23:46
--- Log closed Wed Feb 22 00:00:35 2017
« Monday, 2017-02-20 Index Wednesday, 2017-02-22 »

Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!