--- Log opened Wed Jul 24 00:00:44 2013 | ||
-!- nube1 [~rho@36.252.126.80] has quit [Ping timeout: 246 seconds] | 00:22 | |
* iglesiasg ZZZzzzZZ | 00:36 | |
@iglesiasg | good night! | 00:36 |
---|---|---|
-!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has quit [Quit: Leaving] | 00:37 | |
-!- nube [~rho@36.253.40.168] has joined #shogun | 00:37 | |
-!- nube [~rho@36.253.40.168] has quit [Ping timeout: 256 seconds] | 00:42 | |
-!- FSCV [~FSCV@50.7.50.60] has quit [Quit: Leaving] | 01:04 | |
-!- van51 [~van51@athedsl-399972.home.otenet.gr] has left #shogun ["QUIT :Leaving."] | 01:30 | |
-!- nube [~rho@36.253.146.74] has joined #shogun | 01:48 | |
-!- nube [~rho@36.253.146.74] has quit [Ping timeout: 264 seconds] | 02:27 | |
-!- nube [~rho@36.253.129.33] has joined #shogun | 02:31 | |
-!- hushell [~hushell@8-92.ptpg.oregonstate.edu] has quit [Ping timeout: 268 seconds] | 02:52 | |
shogun-buildbot | build #402 of nightly_all is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_all/builds/402 | 03:08 |
-!- nube1 [~rho@36.253.255.182] has joined #shogun | 03:47 | |
-!- nube [~rho@36.253.129.33] has quit [Ping timeout: 264 seconds] | 03:49 | |
-!- nube1 [~rho@36.253.255.182] has quit [Ping timeout: 246 seconds] | 03:55 | |
-!- nube [~rho@49.244.110.25] has joined #shogun | 03:58 | |
-!- Yanglittle [b74040fc@gateway/web/freenode/ip.183.64.64.252] has joined #shogun | 04:04 | |
Yanglittle | excuse me, how to use the kernel_normalizer in the python_modular? | 04:04 |
Yanglittle | excuse me, how to use the kernel_normalizer in the python_modular? | 04:06 |
shogun-buildbot | build #467 of nightly_default is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/467 | 04:26 |
-!- nube [~rho@49.244.110.25] has quit [Quit: Leaving.] | 04:35 | |
-!- foulwall [~user@2001:da8:215:503:5dac:765e:def8:c0d3] has joined #shogun | 05:18 | |
-!- nube [~rho@116.90.239.13] has joined #shogun | 05:43 | |
-!- nube [~rho@116.90.239.13] has quit [Quit: Leaving.] | 06:02 | |
-!- nube [~rho@116.90.239.13] has joined #shogun | 06:06 | |
-!- foulwall [~user@2001:da8:215:503:5dac:765e:def8:c0d3] has quit [Remote host closed the connection] | 06:11 | |
-!- nube [~rho@116.90.239.13] has quit [Ping timeout: 246 seconds] | 06:19 | |
-!- nube [~rho@116.90.239.13] has joined #shogun | 06:59 | |
-!- nube [~rho@116.90.239.13] has quit [Read error: Connection reset by peer] | 07:24 | |
-!- nube [~rho@116.90.239.13] has joined #shogun | 07:26 | |
gsomix | good morning | 07:42 |
-!- hushell [~hushell@c-24-21-169-136.hsd1.or.comcast.net] has joined #shogun | 07:48 | |
-!- gsomix_ [~gsomix@109.169.225.10] has joined #shogun | 08:44 | |
-!- gsomix [~gsomix@80.234.25.58] has quit [Ping timeout: 246 seconds] | 08:47 | |
-!- foulwall [~user@2001:da8:215:503:f4eb:f5fe:de2f:75f7] has joined #shogun | 09:19 | |
-!- nube [~rho@116.90.239.13] has quit [Quit: Leaving.] | 09:28 | |
-!- nube1 [~rho@116.90.239.3] has joined #shogun | 09:28 | |
-!- lambday [67157d36@gateway/web/freenode/ip.103.21.125.54] has joined #shogun | 09:34 | |
-!- nube1 [~rho@116.90.239.3] has quit [Ping timeout: 248 seconds] | 10:18 | |
-!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has joined #shogun | 10:28 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 10:28 | |
-!- lambday [67157d36@gateway/web/freenode/ip.103.21.125.54] has quit [Ping timeout: 250 seconds] | 10:30 | |
-!- van51 [~van51@athedsl-399972.home.otenet.gr] has joined #shogun | 10:35 | |
-!- nube [~rho@116.90.239.13] has joined #shogun | 10:36 | |
thoralf | Hey GUIs | 10:43 |
thoralf | err guys ;) | 10:43 |
-!- nube [~rho@116.90.239.13] has quit [Quit: Leaving.] | 10:46 | |
@iglesiasg | hehe hi thoralf! | 10:47 |
thoralf | iglesiasg:) | 10:47 |
-!- nube [~rho@116.90.239.3] has joined #shogun | 10:48 | |
-!- foulwall [~user@2001:da8:215:503:f4eb:f5fe:de2f:75f7] has quit [Remote host closed the connection] | 11:01 | |
-!- foulwall [~user@2001:da8:215:503:f4eb:f5fe:de2f:75f7] has joined #shogun | 11:01 | |
thoralf | sonney2k: Didn't get java_modular running and found out, jblas is missing. Could configure check the jblas dependency? | 11:21 |
thoralf | sonney2k: I missed, that it already checks the dependecy. | 11:36 |
@sonney2k | thoralf, I totally feel like a UI now :D | 11:55 |
thoralf | :) | 11:55 |
@sonney2k | van51, any updates on quadratic? | 11:55 |
hushell | iglesiasg: hi | 11:56 |
@iglesiasg | hey hushell | 11:56 |
van51 | sonney2k: not yet, I'm working on it | 11:56 |
van51 | sonney2k: I'm trying to minimize the number of calls to murmurhash | 11:56 |
@sonney2k | gsomix_, are you reworking the line reader? | 11:56 |
hushell | iglesiasg: did you run the recent unit test of SGObject.clone_equals_Mosek? | 11:56 |
thoralf | sonney2k: I fixed check-examples for the other interfaces as well: https://github.com/shogun-toolbox/shogun/pull/1243 | 11:56 |
hushell | iglesiasg: I got errors like this: [ RUN ] SGObject.clone_equals_Mosek | 11:57 |
hushell | Program received signal SIGSEGV, Segmentation fault. | 11:57 |
hushell | 0x00007ffff3fc794b in MSK_deleteenv () from /usr/local/lib/libmosek64.so.6.0 | 11:57 |
thoralf | sonney2k: I think it's ready to merge, as soon as travis is done. | 11:57 |
van51 | sonney2k: I've sent a PR btw, check it when you have time pls | 11:57 |
@iglesiasg | hushell: oh. No, I didn't run it | 11:57 |
@iglesiasg | hushell: in what line does it crash? | 11:57 |
hushell | iglesiasg: this test case is generated automatically | 11:58 |
thoralf | sonney2k: I made several changes to isolate trivial changes in the diff. Shouldn't be a big deal. | 11:58 |
@iglesiasg | hushell: yes, I think it is what heiko and/or wiking were working on recently | 11:58 |
hushell | you can check unit/base/clone_unittest.cc | 11:59 |
@iglesiasg | hushell: I guess they didn't try with Mosek install and maybe that's why | 11:59 |
@iglesiasg | hushell: I don't have mosek install in this machine either so I cannot try right now | 11:59 |
hushell | they created 753 tests... | 11:59 |
hushell | iglesiasg: okay, I'll skip it right now | 12:00 |
@iglesiasg | hushell: it would be nice if it could be fixed actually | 12:01 |
@iglesiasg | I can try to have a look at it some time this week | 12:01 |
@iglesiasg | I will write a github issue so we don't forget | 12:01 |
@sonney2k | van51, I guess you can just store the hash in an array (which you have to allocate and free each time) | 12:02 |
@sonney2k | thoralf, yeah sounds good | 12:02 |
van51 | sonney2k: yes that's the only thing I can think of as well | 12:02 |
@sonney2k | hushell, that is a bug iglesiasg should fix :) | 12:02 |
@sonney2k | van51, lets hope malloc overhead is not so bad :) | 12:03 |
hushell | sonney2k: we can wait Heiko install Mosek :) | 12:03 |
thoralf | sonney2k: Disclaimer: Couldn't get r_modular and perl_modular running -- they were already broken before my intervention | 12:03 |
thoralf | sonney2k: Didn't touch ruby_modular and csharp_modular, since I don't have (and want to) install all dependencies. | 12:04 |
gsomix_ | sonney2k, yep | 12:07 |
gsomix_ | sonney2k, I'll update PR at evening | 12:07 |
@sonney2k | thoralf, bah so I have to do it | 12:08 |
@sonney2k | hushell, I guess Heiko doesn't like to be a hero too often :D | 12:09 |
@sonney2k | hushell, besides it is iglesiasg's code so his duty :) | 12:09 |
@iglesiasg | sonney2k: all right, I got it :) I said I would take a look at it this week | 12:10 |
@iglesiasg | sonney2k: I don't even have mosek installed here right now | 12:10 |
@sonney2k | iglesiasg, I don't know anyone who has :P | 12:10 |
@iglesiasg | sonney2k: I created the issue some minutes ago and assigned it to me | 12:10 |
@iglesiasg | sonney2k: well hushell should have it if he has gotten the error | 12:11 |
@sonney2k | ...except hushell :) | 12:11 |
hushell | sonney2k: yeah I have it right now | 12:11 |
@iglesiasg | sonney2k: I talked about it with Nico during the workshop, I would really like to get rid of the Mosek thing | 12:11 |
@iglesiasg | sonney2k: keep the solver but use something different instead of Mosek for the QP | 12:11 |
hushell | iglesiasg: we can try LBFGS for doing this | 12:12 |
@sonney2k | iglesiasg, yeah would be great. Otherwise it is just dead code *not* covered by any tests | 12:12 |
@iglesiasg | hushell: no idea what that is, let me check | 12:12 |
@iglesiasg | hushell: nonlinear optimization? | 12:13 |
@iglesiasg | hushell: why non linear? | 12:13 |
@iglesiasg | ah wait that is BFGS | 12:13 |
@iglesiasg | I guess the L stands for linear | 12:13 |
@iglesiasg | Limited-memory BFGS, maybe not then | 12:14 |
hushell | iglesiasg: should be L-BFGS my bad | 12:14 |
hushell | iglesiasg: I remember I saw it somewhere in shogun, someone ported liblbfgs | 12:15 |
@iglesiasg | hushell: aham I see! | 12:15 |
hushell | ok in the optimization | 12:16 |
-!- lisitsyn [~lisitsin@mxs.kg.ru] has joined #shogun | 12:16 | |
lisitsyn | ha I broke through the shitty connection | 12:16 |
@iglesiasg | hushell: what I am wondering is that what I am solving with Mosek is a quadratic program. It reads that BFGS is for nonlinear optimization, so I am not sure whether it can be applied for QP | 12:17 |
@sonney2k | iglesiasg, what exactly do you need? a general qp or sth simpler like in libqp? | 12:18 |
@sonney2k | http://cmp.felk.cvut.cz/~xfrancv/libqp/html/ | 12:19 |
@iglesiasg | sonney2k: we already faced this issue this year, libqp was not enough | 12:19 |
@sonney2k | ^ iglesiasg is that sufficient? | 12:19 |
@sonney2k | iglesiasg, I don't remember what you need in addition | 12:19 |
@iglesiasg | sonney2k: let me have a look an refresh it | 12:19 |
@iglesiasg | sonney2k: IIRC it was something related to block constraints | 12:19 |
hushell | iglesiasg: I know some people using L-BFGS for SSVM, this package is the most common one http://www.di.ens.fr/~mschmidt/Software/minFunc.html | 12:19 |
@iglesiasg | sonney2k: ok, I remember now | 12:20 |
@iglesiasg | sonney2k: the problem is pretty similar to "QP task with box constraints and a single linear equality constraint" | 12:20 |
@iglesiasg | sonney2k: but we have a x^T a <= b | 12:20 |
-!- nube [~rho@116.90.239.3] has quit [Ping timeout: 240 seconds] | 12:20 | |
hushell | iglesiasg: this is also related to what I am going to do next, using SGD for SSVM | 12:20 |
@sonney2k | that is what libqp does | 12:20 |
@iglesiasg | sonney2k: it does x^T a = b, we need <= | 12:21 |
@iglesiasg | hushell: yep | 12:21 |
@sonney2k | iglesiasg, look at the homepage it seems to also do <= | 12:21 |
@iglesiasg | sonney2k, hushell : Nico suggested that one could actually used SGD to solve this QP too | 12:21 |
@iglesiasg | sonney2k: do you mean the <= in the first part: "QP task with simplex constraints"? | 12:22 |
@sonney2k | yeah | 12:22 |
@iglesiasg | sonney2k: well, but the constraints are different in there | 12:22 |
@iglesiasg | sonney2k: simplex constraints, no box constraints | 12:22 |
@sonney2k | ahh misread you need dot with a | 12:23 |
@iglesiasg | sonney2k: I am no optimization expert, but I think with the first ones you cannot couple constraints among the variables of x | 12:23 |
@iglesiasg | all right, then | 12:23 |
@sonney2k | iglesiasg, an sgd style solution should be very easy to do | 12:23 |
hushell | iglesiasg: you mean in dual form this constraint is no longer exist | 12:24 |
@sonney2k | iglesiasg, it was x^T 1 <=b anyway | 12:24 |
@iglesiasg | sonney2k: it should be very easy to implement but the tuning can get hard :) | 12:24 |
@iglesiasg | sonney2k: yeah sure but our a is not 1 always :) | 12:24 |
@iglesiasg | mmm what was the a... | 12:25 |
@iglesiasg | IIRC we get one constraint for each margin violator | 12:25 |
@iglesiasg | and our x looks like: x = [w slacks] | 12:26 |
@iglesiasg | so I think the a was basically ones, zeroes and one -1 | 12:26 |
@iglesiasg | ones for w, a -1 for the example that gives the constraint, zeros in the rest | 12:27 |
@iglesiasg | hushell: to solve it with SGD I think we don't need to go to the dual, right? | 12:28 |
@iglesiasg | hushell: we need to write the constrained as unconstrained | 12:28 |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 12:29 | |
shogun-notifier- | shogun: lambday :develop * 665709d / tests/unit/base/clone_unittest.cc.py: https://github.com/shogun-toolbox/shogun/commit/665709daf9cab6de012025d952a35a96366ba6ee | 12:29 |
shogun-notifier- | shogun: failing SNPStringKernel added to clone ignore list to pass all unit-tests | 12:29 |
shogun-notifier- | shogun: lambday :develop * 5b20d7f / tests/unit/mathematics/logdet/LogDetEstimator_unittest.cc: https://github.com/shogun-toolbox/shogun/commit/5b20d7f18816513616f7275166cf9d19ab6a891f | 12:29 |
shogun-notifier- | shogun: reduced time and accuracy for log-det estimator unit-test | 12:29 |
shogun-notifier- | shogun: lambday :develop * 0197f6a / src/shogun/mathematics/logdet/ (2 files): https://github.com/shogun-toolbox/shogun/commit/0197f6acc1c9bc299dc29e7fb1aa82940d5217e6 | 12:29 |
shogun-notifier- | shogun: removed unnecessary template instantiation | 12:29 |
shogun-notifier- | shogun: lambday :develop * 8ecc2dc / tests/unit/base/clone_unittest.cc.py: https://github.com/shogun-toolbox/shogun/commit/8ecc2dc6f2a1bb6bdc0715a24a03f514c764cd04 | 12:29 |
shogun-notifier- | shogun: added failing weighted degree position string kernel to ignore list | 12:29 |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * c76a576 / / (4 files): https://github.com/shogun-toolbox/shogun/commit/c76a5766667d8c2ba0f82540aef3166dc7149149 | 12:29 |
shogun-notifier- | shogun: Merge pull request #1284 from lambday/feature/log_determinant | 12:29 |
shogun-notifier- | shogun: | 12:29 |
shogun-notifier- | shogun: SNPStringKernel added to clone-test ignore list, few changes in log-det | 12:29 |
@iglesiasg | sonney2k: Nico also suggested talking to vojtech and see if libqp could be extended to cover this problem | 12:30 |
hushell | iglesiasg: yes, but usually people work with dual form and optimize with SGD | 12:30 |
@iglesiasg | hushell: aham! | 12:30 |
hushell | iglesiasg: we can try both actually | 12:30 |
@iglesiasg | hushell: do you know why? | 12:30 |
hushell | iglesiasg: not very clear, I need to check the papers, but maybe the dual form has simpler constraints | 12:34 |
hushell | iglesiasg: we can have deep discussion when comes to the point | 12:34 |
shogun-buildbot | build #1518 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1518 blamelist: lambday <heavensdevil6909@gmail.com> | 12:35 |
hushell | I have to go to sleep now, Sorry for my absense of the mid-term meeting, I was not able to get connected | 12:35 |
@iglesiasg | hushell: sure. I have the intuition that structured learning would be very inefficient in the dual though | 12:36 |
hushell | Sorry guys, I will summarize my work in my next weekly report if you are interested in | 12:36 |
@iglesiasg | hushell: well not in general, bundle methods in the dual are fast. But the algorithm implemented in the PrimalMosekSOSVM I think it would be worse in the dual | 12:36 |
@iglesiasg | worse as slower | 12:36 |
shogun-buildbot | build #1519 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1519 blamelist: Soeren Sonnenburg <sonne@debian.org> | 12:37 |
@sonney2k | van51, I looked at the code it looks correct now! One thing - maybe it might make sense to do the hashing trick in some function I mean the | 12:38 |
@sonney2k | uint32_t h_idx = CHash::MurmurHash3((uint8_t* ) &vec.features[i].feat_index, sizeof (index_t), | 12:38 |
@sonney2k | vec.features[i].feat_index); | 12:38 |
@sonney2k | h_idx = h_idx % dim; | 12:38 |
@sonney2k | this thing somewhere in a static function that you use across all hashingdotfeatures | 12:38 |
van51 | sonney2k: true. | 12:38 |
van51 | sonney2k: will do! | 12:39 |
@sonney2k | van51, if you see other common patterns - reduce code duplication where possible | 12:39 |
@sonney2k | van51, I am merging now though do it later | 12:39 |
van51 | sonney2k: in the same PR or in a new one? | 12:39 |
van51 | sonney2k: cool :D | 12:39 |
hushell | iglesiasg: what do you mean worse, I think they are equivalent in the sense KKT conditions are satisfied | 12:39 |
@iglesiasg | hushell: worse as that it would be much slower | 12:40 |
shogun-notifier- | shogun: van51 :develop * 50fe540 / / (13 files): https://github.com/shogun-toolbox/shogun/commit/50fe540e8c961f8d7d57a7e5b30f40d8f994ac35 | 12:40 |
shogun-notifier- | shogun: Changed behavior in Hashed numerical classes | 12:40 |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * fa5d7c4 / / (13 files): https://github.com/shogun-toolbox/shogun/commit/fa5d7c46ac30933af1f74915cc7616d64f8be71a | 12:40 |
shogun-notifier- | shogun: Merge pull request #1282 from van51/develop | 12:40 |
shogun-notifier- | shogun: | 12:40 |
shogun-notifier- | shogun: Corrected behavior of Hashed numerical classes | 12:40 |
@iglesiasg | hushell: let me try to elaborate | 12:40 |
@sonney2k | gsomix_, to avoid misunderstandings how are you doing it now? | 12:41 |
shogun-buildbot | build #1520 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1520 blamelist: van51 <vangelis_51@hotmail.com> | 12:43 |
@sonney2k | thoralf, currently the buildbot installs stuff somewhere and then runs the make check-examples etc | 12:43 |
@iglesiasg | hushell: it is about the evaluation of the loss, in the dual you need to go over all the non-zero dual variables to compute the loss for one example. The number of non-zero dual variables is the order of n | 12:44 |
@sonney2k | so it would be rather useful to have that at least for the test still | 12:44 |
@iglesiasg | hushell: and that is in general, not even for structured learning. In structured learning there are several dual variables for each data points, so it takes even more computations | 12:45 |
hushell | iglesiasg: yes, this is the number of violated constraints basically | 12:45 |
@iglesiasg | hushell: yes | 12:45 |
shogun-buildbot | build #1521 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1521 blamelist: Soeren Sonnenburg <sonne@debian.org> | 12:45 |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * 4964cbb / tests/unit/mathematics/Complex_unittest.cc: https://github.com/shogun-toolbox/shogun/commit/4964cbbf69e48e398c79a0fc295c137e575f5550 | 12:46 |
shogun-notifier- | shogun: make complex a bit more tolerant | 12:46 |
@sonney2k | foulwall, any updates on the readme / the ocr demo? | 12:46 |
hushell | iglesiasg: let's talk based on the BMRM paper : http://users.cecs.anu.edu.au/~chteo/pub/TeoLeSmoVis07.pdf | 12:46 |
@iglesiasg | hushell: I don't have full understanding of this behaviour though. This is something Patrick explained some months ago | 12:46 |
hushell | IIRC, primalMosek is solving eq.10, and BMRM solve eq.12 using libqp | 12:47 |
shogun-buildbot | build #1517 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1517 blamelist: lambday <heavensdevil6909@gmail.com> | 12:47 |
hushell | iglesiasg: okay, I think also too late for me to discuss this in detail | 12:48 |
hushell | iglesiasg: we can find another time to figure out how to solve the particular QP efficiently | 12:49 |
@iglesiasg | hushell: hehe sure. Let's talk again about it when the moment to get Mosek to a better life arrives :) | 12:49 |
-!- nube [~rho@49.244.94.101] has joined #shogun | 12:49 | |
@iglesiasg | hushell: good night! | 12:49 |
hushell | iglesiasg: night, btw I updated the PR | 12:49 |
@iglesiasg | hushell: cool, I check right away | 12:49 |
hushell | iglesiasg: okay, CU | 12:50 |
-!- hushell [~hushell@c-24-21-169-136.hsd1.or.comcast.net] has quit [Quit: WeeChat 0.3.7] | 12:50 | |
@sonney2k | shogun-buildbot, force build 'deb1 - libshogun' | 12:52 |
shogun-buildbot | build forced [ETA 15m38s] | 12:52 |
shogun-buildbot | I'll give a shout when the build finishes | 12:52 |
shogun-buildbot | build #1522 of deb1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1522 | 12:52 |
@sonney2k | van51, btw another good test for the hashing dense / sparse would be to compare it directly with the dense features. for sufficiently large bitsize all the ops should be the same. | 12:53 |
@sonney2k | shogun-buildbot, dance | 12:53 |
shogun-buildbot | <(^.^<) | 12:53 |
shogun-buildbot | <(^.^)> | 12:53 |
shogun-buildbot | (>^.^)> | 12:53 |
shogun-buildbot | (7^.^)7 | 12:53 |
shogun-buildbot | (>^.^<) | 12:53 |
@sonney2k | man a little bit of green again! | 12:53 |
@iglesiasg | so sweet :) | 12:54 |
* sonney2k goes to see some blue | 12:54 | |
@sonney2k | cya | 12:54 |
@iglesiasg | have fun! | 12:54 |
shogun-buildbot | build #745 of rpm1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/rpm1%20-%20libshogun/builds/745 blamelist: Soeren Sonnenburg <sonne@debian.org> | 12:54 |
thoralf | sonney2k: "thoralf, bah so I have to do it" <-- I didn't break them. I just couldn't change them. | 12:57 |
thoralf | sonney2k: "thoralf, currently the buildbot installs stuff somewhere and then runs the make check-examples etc" <-- I don't understand. With my changes, check-examples relies on the compiled libraries from the source directory. Not the target location. | 12:58 |
@sonney2k | lamday, HeikoS ... http://www.shogun-toolbox.org/buildbot/builders/rpm1%20-%20libshogun/builds/745/steps/compile/logs/stdio | 12:58 |
thoralf | sonney2k: So, calling "make install" does not hurt, but has no effect on check-examples either. | 12:59 |
shogun-buildbot | build #1058 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1058 blamelist: Soeren Sonnenburg <sonne@debian.org> | 12:59 |
thoralf | sonney2k: Did I miss something? | 13:01 |
shogun-buildbot | Hey! build deb1 - libshogun #1523 is complete: Success [build successful] | 13:01 |
shogun-buildbot | Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1523 | 13:01 |
shogun-buildbot | build #1262 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1262 blamelist: Soeren Sonnenburg <sonne@debian.org> | 13:03 |
-!- HeikoS [~heiko@nat-185-60.internal.eduroam.ucl.ac.uk] has joined #shogun | 13:10 | |
-!- mode/#shogun [+o HeikoS] by ChanServ | 13:10 | |
@iglesiasg | hi HeikoS | 13:16 |
@HeikoS | iglesiasg: hi! | 13:16 |
@iglesiasg | HeikoS: I am having a look at CMosek, and yeah the attributes does not seem to be initialized | 13:16 |
shogun-buildbot | build #1381 of deb3 - modular_interfaces is complete: Failure [failed compile python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1381 blamelist: Soeren Sonnenburg <sonne@debian.org> | 13:16 |
@iglesiasg | HeikoS: but I am actually thinking that this class does not really need to be a CSGObject | 13:17 |
@HeikoS | iglesiasg: yes that usually the reason | 13:17 |
@HeikoS | iglesiasg: doesnt matter, it is now :) | 13:17 |
@HeikoS | iglesiasg: if you initialise all members in the std constructor, the bug will probably go | 13:17 |
@HeikoS | iglesiasg: is mosek hard to install? | 13:17 |
lisitsyn | I'd say easy | 13:17 |
@iglesiasg | HeikoS: in the header Mosek.h I need to include some Mosek header | 13:17 |
@HeikoS | lisitsyn: have you seen the two bug reports? | 13:18 |
@HeikoS | its not in ubuntu repo | 13:18 |
lisitsyn | HeikoS: not yet | 13:18 |
lisitsyn | HeikoS: of course it is not | 13:18 |
@HeikoS | iglesiasg: so could you fix the init bug? | 13:18 |
lisitsyn | HeikoS: it is proprietary $hit | 13:18 |
@iglesiasg | HeikoS: yeah, sure | 13:18 |
lisitsyn | HeikoS: https://github.com/shogun-toolbox/shogun/issues/1265 ha! | 13:19 |
@iglesiasg | HeikoS: but I think it would be a better idea not making it a CSGObject | 13:19 |
shogun-notifier- | shogun: Sergey Lisitsyn :develop * b94061e / src/shogun/classifier/FeatureBlockLogisticRegression.cpp: https://github.com/shogun-toolbox/shogun/commit/b94061edad77a196439b7ac3299c5748456c6188 | 13:22 |
shogun-notifier- | shogun: Fixed group lasso indices check. Fixes #1286 | 13:22 |
@HeikoS | iglesiasg: maybe, but lets dont change things, too much work ;) | 13:27 |
@HeikoS | lisitsyn: do you like that idea? | 13:27 |
@HeikoS | lisitsyn: unit test the group lasso! | 13:27 |
@HeikoS | at least this bit you fixed | 13:28 |
lisitsyn | HeikoS: ok will try rather soon | 13:28 |
@HeikoS | lisitsyn: because these bugs are evil, scare away people | 13:28 |
@HeikoS | lisitsyn: and the guy is a potential user :) | 13:28 |
@HeikoS | good oportunity to make things better for lasso | 13:29 |
lisitsyn | HeikoS: about setters/getters | 13:29 |
lisitsyn | HeikoS: I think in python we can do some magic to cast objects | 13:29 |
@HeikoS | iglesiasg: btw, valgrind this program to find uninitialised memory for Mosek# | 13:29 |
lisitsyn | but in e.g. java we are going to use something like | 13:29 |
lisitsyn | svm.parameter("C").as_float() | 13:29 |
@HeikoS | iglesiasg: https://gist.github.com/anonymous/6069772 | 13:30 |
lisitsyn | HeikoS: I don't know if people would like that | 13:30 |
@HeikoS | lisitsyn: I dont know about the whole model selectoin framework anymore | 13:30 |
@iglesiasg | HeikoS: all right, thank you | 13:30 |
@HeikoS | lisitsyn: its so complicated to use and maintain | 13:30 |
@HeikoS | lisitsyn: and soooo easy to emulate: a double loop for SVMs with Gaussian kernel | 13:30 |
@iglesiasg | HeikoS: I am going to prepare a Mosek installation in Shogun | 13:30 |
@HeikoS | so I am currently more for dropping it | 13:30 |
@HeikoS | lisitsyn: have you seen my issue on this? | 13:30 |
lisitsyn | HeikoS: drop? | 13:31 |
@HeikoS | lisitsyn: yes, just keep x-validation | 13:31 |
-!- travis-ci [~travis-ci@ec2-50-16-34-49.compute-1.amazonaws.com] has joined #shogun | 13:31 | |
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/9427950 | 13:31 |
-!- travis-ci [~travis-ci@ec2-50-16-34-49.compute-1.amazonaws.com] has left #shogun [] | 13:31 | |
lisitsyn | HeikoS: that's a great issue | 13:32 |
lisitsyn | HeikoS: this gets me back to thoughts that we've got to seriously change something | 13:32 |
@HeikoS | lisitsyn: this one is easy | 13:32 |
@HeikoS | just drop it | 13:33 |
@HeikoS | lisitsyn: not many things depend on it | 13:33 |
@HeikoS | only GPs | 13:33 |
lisitsyn | HeikoS: no I mean in general | 13:33 |
@HeikoS | lisitsyn: I would rather write modelselection stuff for the machines individually | 13:33 |
lisitsyn | I'd drop most of code yes | 13:33 |
@HeikoS | grid-search is easy so we dont need that | 13:33 |
@HeikoS | lisitsyn: yes, agree, so this is a good place to start maybe | 13:33 |
@HeikoS | lisitsyn: just thinking whether this block things | 13:33 |
@HeikoS | lisitsyn: for example, more intelligent search algorithms for model-selection | 13:33 |
@HeikoS | lisitsyn: cannot be done anymore then | 13:34 |
@HeikoS | lisitsyn: but I think its infeasible to implement those anyway | 13:34 |
lisitsyn | HeikoS: I have a feeling this should not be done in C++ | 13:34 |
@HeikoS | lisitsyn: yeah exactly | 13:34 |
@HeikoS | maybe we can do this via swig in python at some point or so | 13:34 |
lisitsyn | either we raise the level of abstraction | 13:34 |
lisitsyn | in C++ code | 13:34 |
@HeikoS | since its not even time dependent | 13:34 |
@HeikoS | lisitsyn: yep agreed, | 13:34 |
lisitsyn | or we use something more high-level | 13:34 |
@HeikoS | Ill talk with Roman on how to modify the GP stuff that is based on model-selection | 13:35 |
@HeikoS | lisitsyn: I totally agree | 13:35 |
lisitsyn | HeikoS: the problem is that we don't use high-level C++ | 13:35 |
@HeikoS | lisitsyn: maybe write some thoughts in the issue, to document them | 13:35 |
@HeikoS | we often forget what we talked about :) | 13:35 |
lisitsyn | HeikoS: yeah will try to formulate | 13:35 |
@HeikoS | lisitsyn: cool! | 13:35 |
@HeikoS | I have to do some work now, see you all later today | 13:36 |
lisitsyn | HeikoS: well we are in search of some common point | 13:36 |
@HeikoS | lisitsyn: yep, lets do a documented discussion in the issue | 13:36 |
@HeikoS | then other people also can read about it and tell what they think | 13:36 |
lisitsyn | HeikoS: we have more resources than we use | 13:36 |
@HeikoS | lisitsyn: ? | 13:36 |
lisitsyn | HeikoS: well if it was more high-level | 13:37 |
lisitsyn | we could spend less time etc | 13:37 |
lisitsyn | I mean 8 gsocers + some of us | 13:37 |
lisitsyn | that's a lot | 13:37 |
@HeikoS | lisitsyn: yeah, its a big thing though | 13:37 |
lisitsyn | this could change the world | 13:37 |
thoralf | ;) | 13:37 |
lisitsyn | but we do something low-level | 13:37 |
@HeikoS | lisitsyn: could you formalise this in an issue? | 13:38 |
@HeikoS | lisitsyn: Id really like to document all these ideas to have proper discussions | 13:38 |
lisitsyn | HeikoS: yeah a bit later as I have to arbeit too | 13:38 |
@HeikoS | was very useful at c-base meeting | 13:38 |
@HeikoS | lisitsyn: arbeit arbeit brot brot banane :) | 13:38 |
@HeikoS | lisitsyn: ok see you later then | 13:38 |
lisitsyn | arbeit macht frei haha | 13:38 |
@HeikoS | lisitsyn: ouch! | 13:38 |
lisitsyn | HeikoS: hah yes not very correct I guess but that's just the language | 13:39 |
thoralf | HeikoS: lisitsyn is not required to be german-PC ;) | 13:39 |
@HeikoS | thoralf: well .... whatever | 13:39 |
@HeikoS | see you! :) | 13:39 |
shogun-buildbot | build #1524 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1524 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 13:42 |
lisitsyn | thoralf: that's a curious thing one can't say some things just because of its usage earlier | 13:42 |
thoralf | lisitsyn: it's called self-censorship | 13:43 |
thoralf | lisitsyn: I know I wasn't responsible for this - but we learned in school to avoid this. Overwise we could be offended by others, who practice more PC-aware speaking. | 13:45 |
lisitsyn | thoralf: yes sure - I just mean it has nothing to do with the meaning | 13:45 |
thoralf | lisitsyn: Yes. | 13:46 |
lisitsyn | like hidden agenda | 13:46 |
lisitsyn | thoralf: I mean it is not 'kill all X' or whatever so I find it weird | 13:47 |
-!- Yanglittle [b74040fc@gateway/web/freenode/ip.183.64.64.252] has quit [Quit: Page closed] | 13:47 | |
lisitsyn | thoralf: although I agree this should be avoided and now feel cumbersome :D | 13:49 |
lisitsyn | thoralf: but again I feel this agenda should be gone | 13:50 |
thoralf | lisitsyn: I think every "nation" has similar "overloaded" words. | 13:50 |
lisitsyn | thoralf: russians exalt stalin still | 13:50 |
thoralf | Uh. | 13:51 |
thoralf | Yeah, only one example. Religion is another source for good examples. :) | 13:51 |
lisitsyn | thoralf: oh that's the thing I am totally PC-uncompliant | 13:51 |
lisitsyn | :D | 13:51 |
thoralf | Hmm, having a std::istringstream - do you know how to check the status? i.e. if I'm trying to cast an "token" to "int32" and it fails? | 13:54 |
-!- travis-ci [~travis-ci@ec2-50-16-34-49.compute-1.amazonaws.com] has joined #shogun | 13:54 | |
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/9428262 | 13:54 |
-!- travis-ci [~travis-ci@ec2-50-16-34-49.compute-1.amazonaws.com] has left #shogun [] | 13:54 | |
lisitsyn | thoralf: there should be some methods to check if it is ok | 13:54 |
-!- FSCV [~FSCV@187.210.54.166] has joined #shogun | 13:54 | |
thoralf | std::istringstream iss (line); int32_t number; iss >> number; <-- This fails, but I can't detect. :( | 13:55 |
lisitsyn | thoralf: well just catch it then | 13:55 |
lisitsyn | it is an exceptional case right? | 13:55 |
thoralf | lisitsyn: It fails as-in the integer is not correct in case of an overflow. But it does not raise anything. | 13:56 |
thoralf | lisitsyn: Just return status false. | 13:56 |
lisitsyn | thoralf: no way! should throw something | 13:56 |
lisitsyn | or return | 13:56 |
thoralf | lisitsyn: But eof also gives false. | 13:56 |
lisitsyn | thoralf: | 13:57 |
lisitsyn | http://www.cplusplus.com/reference/istream/istream/operator%3E%3E/ | 13:57 |
lisitsyn | thoralf: check failbit | 13:57 |
thoralf | lisitsyn: Thanks. | 13:57 |
thoralf | lisitsyn: I already read lot of stackoverflow stuff, but you're way smarter than stackoverflow. :D | 13:57 |
lisitsyn | thoralf: I am overflown already! | 13:58 |
lisitsyn | :D | 13:58 |
thoralf | lisitsyn: iss.eof(), iss.good(), iss.bad(), iss.fail() | 14:02 |
thoralf | lisitsyn: failbit tells which bit is actually the fail bit. ;) | 14:02 |
thoralf | lisitsyn: But not if it failed. | 14:02 |
lisitsyn | thoralf: but if it is not set it is not failed right? | 14:05 |
thoralf | lisitsyn: Its always set. | 14:06 |
lisitsyn | what's the default then? | 14:06 |
thoralf | lisitsyn: Just kind of a constant. | 14:06 |
lisitsyn | thoralf: anyway | 14:06 |
lisitsyn | thoralf: (ss >> n).fail() | 14:06 |
lisitsyn | thoralf: I guess that | 14:06 |
lisitsyn | I'd go further and just | 14:07 |
thoralf | iss.eofbit 2, iss.failbit 4, iss.badbit 1 | 14:07 |
lisitsyn | if (!(iss >> n).good()) { panic } | 14:07 |
lisitsyn | thoralf: ^ something like that I think? | 14:07 |
shogun-notifier- | shogun: Fernando Iglesias :develop * 3c84872 / src/shogun/labels/MulticlassLabels.h: https://github.com/shogun-toolbox/shogun/commit/3c848725b8cf42a8ec2774e651a564c1f9e6d26b | 14:08 |
shogun-notifier- | shogun: Fix MulticlassLabels doc, returned SGVector needs not be cleaned up | 14:08 |
shogun-notifier- | shogun: Fernando Iglesias :develop * de7b308 / src/shogun/labels/MulticlassLabels.h: https://github.com/shogun-toolbox/shogun/commit/de7b308e9f6e927d74c599feb58c8212f30e0d1f | 14:08 |
shogun-notifier- | shogun: Merge pull request #1288 from iglesias/docfix | 14:08 |
shogun-notifier- | shogun: | 14:08 |
shogun-notifier- | shogun: Fix MulticlassLabels doc, returned SGVector needs not be cleaned up | 14:08 |
thoralf | (ss >> n).fail() <-- Whats the return value of (ss >> n)? | 14:09 |
lisitsyn | thoralf: stream | 14:11 |
lisitsyn | with some state | 14:11 |
lisitsyn | any << or >> return stream | 14:12 |
lisitsyn | to allow stuff like | 14:12 |
lisitsyn | iss << 1 << 2 << 3; | 14:12 |
thoralf | I see, yes. | 14:13 |
thoralf | this is int32_max + 1 as a string: "2147483648" | 14:14 |
thoralf | iss >> number; casts to 2147483647 | 14:14 |
thoralf | No error. | 14:14 |
thoralf | Nothing helps. | 14:14 |
shogun-buildbot | build #746 of rpm1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/rpm1%20-%20libshogun/builds/746 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 14:15 |
-!- travis-ci [~travis-ci@ec2-54-224-203-225.compute-1.amazonaws.com] has joined #shogun | 14: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/9428454 | 14:16 |
-!- travis-ci [~travis-ci@ec2-54-224-203-225.compute-1.amazonaws.com] has left #shogun [] | 14:16 | |
thoralf | lisitsyn: I can't check on "ss", I really need to call what you told: (ss >> n).fail() | 14:17 |
lisitsyn | thoralf: that's different stream | 14:19 |
lisitsyn | ss >> n produces a new stream | 14:19 |
lisitsyn | its state differs | 14:19 |
@iglesiasg | what is the rpm build? red hat packet? | 14:19 |
lisitsyn | iglesiasg: ye | 14:19 |
lisitsyn | s | 14:19 |
lisitsyn | no | 14:19 |
lisitsyn | :D | 14:19 |
@iglesiasg | ? | 14:20 |
lisitsyn | I thought you are asking what is rpm | 14:20 |
lisitsyn | :D | 14:20 |
@iglesiasg | haha | 14:20 |
@iglesiasg | I mean in our buildbot | 14:20 |
lisitsyn | iglesiasg: that's redhat build but I think there is no package | 14:20 |
@iglesiasg | lisitsyn: aham got it | 14:21 |
-!- s3b4 [59e3a2e9@gateway/web/freenode/ip.89.227.162.233] has joined #shogun | 14:21 | |
@iglesiasg | hi s3b4! | 14:21 |
s3b4 | hi fernando | 14:21 |
s3b4 | right, i'd like to help you reproduce this seg fault i'm seeing | 14:22 |
@iglesiasg | s3b4: so how does the example fail? | 14:22 |
s3b4 | azureuser@test-py:~/shogun-develop/examples/documented/python_modular$ python st ructure_discrete_hmsvm_bmrm.py Discrete HMSVM BMRM Segmentation fault (core dumped) | 14:22 |
s3b4 | and that's it | 14:23 |
s3b4 | i'm not sure where to find the core dump on this machine, if that would help | 14:23 |
shogun-buildbot | build #1263 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1263 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 14:23 |
@iglesiasg | s3b4: it would help it we could use gdb, valgrind or similar | 14:24 |
@iglesiasg | s3b4: but since you are running it from python that may make things a bit harder, do you think we can try running the C++ example? | 14:24 |
s3b4 | never used them. i can spend say an hour on this now. any pointers for me to start? | 14:25 |
@iglesiasg | s3b4: if you are using python, your machine should be ready as well to run the C++ example | 14:25 |
@iglesiasg | s3b4: one second, let me try it in my machine first | 14:25 |
s3b4 | so how does that go? | 14:25 |
@iglesiasg | s3b4: cd to shogun/examples/undocumented/libshogun | 14:26 |
@iglesiasg | s3b4: g++ -lshogun so_multiclass_BMRM.cpp | 14:27 |
shogun-buildbot | build #1525 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1525 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 14:27 |
shogun-buildbot | build #1059 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1059 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 14:27 |
s3b4 | that would be too easy :-) the compilation log is full of undefined references; is there no make for the undocumented examples? | 14:28 |
s3b4 | there is, and i'm runnign it now | 14:29 |
@iglesiasg | s3b4: yeah, you can do make-check-examples | 14:29 |
@iglesiasg | all right | 14:29 |
@iglesiasg | s3b4: in the meantime let's try to gdb the python program too | 14:30 |
@iglesiasg | s3b4: gdb python and then in the gdb console run structure_discrete_hmsvm_bmrm.py | 14:31 |
-!- foulwall [~user@2001:da8:215:503:f4eb:f5fe:de2f:75f7] has quit [Remote host closed the connection] | 14:54 | |
shogun-buildbot | build #1382 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1382 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 15:07 |
-!- nube [~rho@49.244.94.101] has quit [Ping timeout: 264 seconds] | 15:19 | |
-!- travis-ci [~travis-ci@ec2-23-20-210-220.compute-1.amazonaws.com] has joined #shogun | 15:23 | |
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/9430992 | 15:23 |
-!- travis-ci [~travis-ci@ec2-23-20-210-220.compute-1.amazonaws.com] has left #shogun [] | 15:23 | |
-!- foulwall [~user@2001:da8:215:c252:d56f:94fe:80b7:bdac] has joined #shogun | 16:04 | |
-!- foulwall [~user@2001:da8:215:c252:d56f:94fe:80b7:bdac] has quit [Ping timeout: 264 seconds] | 16:15 | |
-!- lambday [67157c36@gateway/web/freenode/ip.103.21.124.54] has joined #shogun | 16:32 | |
lambday | HeikoS: hi | 16:33 |
lambday | HeikoS: checked your comments | 16:33 |
lambday | HeikoS: so, we'll be having 2 failing unit-tests if I remove those | 16:33 |
@iglesiasg | lisitsyn, sonney2k, wiking, HeikoS: around? | 16:43 |
lisitsyn | iglesiasg: yes for a few more minutes | 16:44 |
@iglesiasg | lisitsyn: good, take a look if you can at this a moment please | 16:45 |
@iglesiasg | https://gist.github.com/iglesias/6071253 | 16:45 |
@iglesiasg | so I am running in my machine the same program that s3b4 is doing | 16:45 |
@iglesiasg | from the same commit in github | 16:45 |
@iglesiasg | here it runs completely fine, but it crashes in his machine | 16:46 |
@iglesiasg | that is gdb output of the crash (sorry for the bad formatting) | 16:46 |
@iglesiasg | lisitsyn: any idea why can it crash there and run fine here if it is the same version of Shogun? | 16:46 |
lisitsyn | iglesiasg: no can't say much about it | 16:47 |
@iglesiasg | lisitsyn: I am clueless about it. Any idea how to gather more useful info? | 16:49 |
@iglesiasg | I valgrind the example here and there was no invalid read/write | 16:49 |
lisitsyn | iglesiasg: valgrind would be more useful probably | 16:50 |
@iglesiasg | lisitsyn: yeah, let's valgrind the example in his machine too | 16:51 |
lisitsyn | will get back quite soon! | 16:52 |
@iglesiasg | all right | 16:52 |
-!- s3b4 [59e3a2e9@gateway/web/freenode/ip.89.227.162.233] has quit [Quit: Page closed] | 17:06 | |
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 17:08 | |
@iglesiasg | see you later guys | 17:10 |
-!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has quit [Quit: Leaving] | 17:10 | |
-!- lambday [67157c36@gateway/web/freenode/ip.103.21.124.54] has quit [Ping timeout: 250 seconds] | 17:12 | |
-!- lambday [67157c36@gateway/web/freenode/ip.103.21.124.54] has joined #shogun | 17:34 | |
lambday | HeikoS: sonney2k lisitsyn : why its necessary for all template classes to pass for all ptypes in class_list.cpp? | 17:35 |
lambday | for many classes, say LinearOperator, we won't be needing bool, char, etc... but still we gotta instantiate them :( | 17:36 |
lambday | results in huge compile time :( | 17:37 |
lambday | is it feasible that we check what explicit instantiations are declared in corresponding h/cpp.. and check only for those? | 17:38 |
-!- lambday [67157c36@gateway/web/freenode/ip.103.21.124.54] has quit [Ping timeout: 250 seconds] | 17:56 | |
-!- pickle27 [~Kevin@d67-193-243-174.home3.cgocable.net] has joined #shogun | 18:09 | |
@HeikoS | lisitsyn: around? | 18:10 |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 18:14 | |
shogun-notifier- | shogun: Fernando Iglesias :develop * 13c90ba / src/ (7 files): https://github.com/shogun-toolbox/shogun/commit/13c90baca9fabe01a5ae009cca67c8cf1517f3e8 | 18:14 |
shogun-notifier- | shogun: Modifications so LMNN can be used from interfaces. | 18:14 |
shogun-notifier- | shogun: Fernando Iglesias :develop * 5e950b1 / src/shogun/distance/CustomMahalanobisDistance.cpp: https://github.com/shogun-toolbox/shogun/commit/5e950b17455c55b15e8682982c692b1bea399a47 | 18:14 |
shogun-notifier- | shogun: Use static_cast instead of dynamic_cast to save runtime in custom Mahalanobis distance | 18:14 |
shogun-notifier- | shogun: Fernando Iglesias :develop * 04e7a81 / src/ (8 files): https://github.com/shogun-toolbox/shogun/commit/04e7a816b03c1252fa54ce6988b8a84f64c43c7b | 18:14 |
shogun-notifier- | shogun: Merge pull request #1289 from iglesias/feature/lmnn | 18:14 |
shogun-notifier- | shogun: | 18:14 |
shogun-notifier- | shogun: Feature/lmnn | 18:14 |
-!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has joined #shogun | 18:19 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 18:19 | |
shogun-buildbot | build #747 of rpm1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/rpm1%20-%20libshogun/builds/747 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 18:21 |
@iglesiasg | hi guys | 18:21 |
shogun-buildbot | build #1060 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1060 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 18:25 |
@iglesiasg | HeikoS, do you know something about this error? http://www.shogun-toolbox.org/buildbot/builders/rpm1%20-%20libshogun/builds/747/steps/compile/logs/stdio | 18:26 |
@iglesiasg | it seems to be in the logdet framework | 18:26 |
-!- lambday [67157d36@gateway/web/freenode/ip.103.21.125.54] has joined #shogun | 18:27 | |
@iglesiasg | another user got it before too in ubuntu 12.04 | 18:27 |
lambday | HeikoS: hi | 18:27 |
@HeikoS | iglesiasg: yeah thats lambday s latest patch | 18:27 |
@iglesiasg | lambday, or maybe you know about it even better :) | 18:27 |
@HeikoS | lambday: could you re-include the templates again? | 18:27 |
lambday | which templates? | 18:27 |
@HeikoS | lambday: also the unit test fails for the faster runtime thing sometimes | 18:27 |
@HeikoS | lambday: the ones you removed in the last patch | 18:27 |
@HeikoS | add them again for now | 18:27 |
@HeikoS | we first need a machanism to avoid testing them | 18:28 |
lambday | okay but | 18:28 |
lambday | alright | 18:28 |
lambday | shit I wrote many more things but I didn't realize I got dc | 18:28 |
@HeikoS | lambday: I know compile time, but that can be fixed later | 18:28 |
lambday | anyway here they are | 18:28 |
@HeikoS | current it breaks the tests | 18:28 |
lambday | secondly, say a child class does not define a parent abstract method and stays abstract, but class_list can't find that :( we gotta keep writing that pure virtual signature in each one of them.. we can create a separate list of abstract classes and attach which method(s) makes it abstract, and check if a classs' [21:25] <lambday> parent belong to that list and the current .h doesn't define that, we add it to it [21:25] <lambday> iter | 18:28 |
lambday | HeikoS: alright | 18:28 |
lambday | but why does it break! | 18:29 |
lambday | :-/ | 18:29 |
shogun-buildbot | build #1264 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1264 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 18:29 |
@HeikoS | lambday: if you want something to be virtual and also be recognised as virtual, you have to keep the =0 signature | 18:29 |
lambday | yes I did that | 18:29 |
@HeikoS | lambday: just add them once again, we can figure that later ;) | 18:29 |
@HeikoS | lambday: http://www.shogun-toolbox.org/buildbot/builders/rpm1%20-%20libshogun/builds/747/steps/compile/logs/stdio | 18:29 |
lambday | HeikoS: alright | 18:29 |
lambday | HeikoS: its not because of that | 18:31 |
lambday | Its because I split the template thing into two lines :( | 18:31 |
lambday | I think | 18:31 |
@HeikoS | lambday: ah | 18:32 |
@HeikoS | ok then | 18:32 |
@HeikoS | what cool | 18:32 |
@HeikoS | just make sure the build works again :) | 18:32 |
lambday | HeikoS: sending the patch | 18:32 |
@HeikoS | lambday: thanks a lot! | 18:32 |
lambday | HeikoS: alright | 18:32 |
lambday | HeikoS: no problem :) | 18:32 |
shogun-buildbot | build #1527 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1527 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 18:33 |
-!- FSCV [~FSCV@187.210.54.166] has quit [Quit: Leaving] | 18:37 | |
lambday | HeikoS: please have a look | 18:38 |
@HeikoS | lambday: no PR here yet | 18:39 |
lambday | umm | 18:39 |
lambday | HeikoS: https://github.com/shogun-toolbox/shogun/pull/1291 | 18:40 |
@HeikoS | lambday: the unit test also sometimes fails | 18:40 |
@HeikoS | could you run the thing locally a large number of times and then set the error to the maximum error obtained? | 18:40 |
shogun-notifier- | shogun: lambday :develop * a726e43 / src/shogun/mathematics/logdet/ (2 files): https://github.com/shogun-toolbox/shogun/commit/a726e43a4e8e95622e877374757b9ef0c5d4a7e2 | 18:40 |
shogun-notifier- | shogun: fixed multi line template declaration error | 18:40 |
shogun-notifier- | shogun: Heiko Strathmann :develop * 85d86a4 / src/shogun/mathematics/logdet/ (2 files): https://github.com/shogun-toolbox/shogun/commit/85d86a4c0caa6afd6619ab2cd5e9c5e6a6032fa9 | 18:40 |
shogun-notifier- | shogun: Merge pull request #1291 from lambday/feature/log_determinant | 18:40 |
shogun-notifier- | shogun: | 18:40 |
shogun-notifier- | shogun: fixed multi line template declaration error | 18:40 |
lambday | HeikoS: yes.. I'll fix a lower accuracy.. running 10k times as you said | 18:41 |
@HeikoS | lambday: but not in the test though :) | 18:41 |
lambday | HeikoS: lol yes :D | 18:41 |
@HeikoS | so set the test to n iterations | 18:41 |
@HeikoS | then you locally run 100000*n and choose the largest error you got | 18:41 |
@HeikoS | (+ some small offset) | 18:41 |
lambday | HeikoS: alright | 18:41 |
lambday | HeikoS: shall I remove SNP and WeightedDegree from the clone test too? they failed in the clone test | 18:43 |
@HeikoS | lambday: please rather try to fix them :) | 18:43 |
@HeikoS | lambday: or let me do it | 18:44 |
@HeikoS | lambday: but this blacklist is for other things (framework issues) | 18:44 |
@HeikoS | lambday: these classes can currently not be tested automatically | 18:44 |
lambday | HeikoS: oh alright | 18:44 |
@HeikoS | due to issues in the way we treat generics | 18:44 |
lambday | got it | 18:44 |
-!- travis-ci [~travis-ci@ec2-23-20-210-220.compute-1.amazonaws.com] has joined #shogun | 18:46 | |
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/9439610 | 18:46 |
-!- travis-ci [~travis-ci@ec2-23-20-210-220.compute-1.amazonaws.com] has left #shogun [] | 18:46 | |
lambday | HeikoS: I removed those and added a comment | 18:47 |
gsomix_ | good evening | 18:55 |
-!- gsomix_ is now known as gsomix | 18:55 | |
lambday | HeikoS: SNP clone gives segfaults | 18:55 |
naywhayare | anybody here going to the GSoC mentor summit in October? | 18:56 |
@HeikoS | naywhayare: hi yes | 18:56 |
@HeikoS | lambday: let me check | 18:56 |
naywhayare | HeikoS: I will be there also, perhaps we will run into each other :) | 18:57 |
@HeikoS | naywhayare: cool! yeah lets meet then | 18:57 |
@HeikoS | naywhayare: which organisation were you again? | 18:57 |
naywhayare | HeikoS: mlpack | 18:57 |
@HeikoS | ah yes | 18:57 |
naywhayare | :) | 18:57 |
@HeikoS | the speed kmeans paper :) | 18:58 |
naywhayare | I ran into a guy who works on Shark at ICML, I think he said he would be at the summit too | 18:58 |
naywhayare | I completely forgot his name but I remember what he looks like... | 18:58 |
@HeikoS | I am really looking forward to meet everyone | 18:58 |
naywhayare | :) | 18:59 |
naywhayare | I don't think any scikit-learn guys will be there; scikit-learn wasn't in GSoC this year -- I'm not sure why | 19:00 |
lisitsyn | I am curious if there is a chance to get there too | 19:00 |
lisitsyn | naywhayare: they are but under PSF I think | 19:00 |
@HeikoS | naywhayare: dont know, I think one of our student also applied to them ... | 19:00 |
@HeikoS | lisitsyn: would be cool if you joined us | 19:01 |
@HeikoS | lisitsyn: but this time you will have to talk more :D | 19:01 |
lisitsyn | HeikoS: oh cooome ooon | 19:01 |
@HeikoS | naywhayare: we had our workshop recently, where everyone met, this was really nice | 19:01 |
naywhayare | ah yeah, there scikit is under PSF | 19:01 |
lisitsyn | I have been hearing that basically every day since our workshop | 19:01 |
@HeikoS | lisitsyn: haha | 19:02 |
@HeikoS | you deserve it ;) | 19:02 |
lisitsyn | oh well then I would not like to join that meeting | 19:02 |
@HeikoS | lisitsyn: ah come on, I am just joking | 19:02 |
@HeikoS | of course you should join us | 19:02 |
shogun-buildbot | build #1529 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1529 blamelist: lambday <heavensdevil6909@gmail.com> | 19:02 |
@HeikoS | will be nice | 19:02 |
@HeikoS | I am really afraid of my computer melting with all these shogun compiles | 19:03 |
-!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has joined #shogun | 19:03 | |
@HeikoS | votjakovr: hi! | 19:03 |
@HeikoS | lambday: what is the exact name of the class that fails? | 19:04 |
lambday | SNPStringKernel | 19:04 |
lambday | and another one | 19:04 |
@HeikoS | thx | 19:04 |
votjakovr | HeikoS: hi! i've finished posterior approximation stuff and tested with probit likelihood | 19:05 |
@HeikoS | lambday: yep there is uninit memory | 19:05 |
@HeikoS | votjakovr: nice! | 19:05 |
@HeikoS | votjakovr: could you do logit likelihood next for it? | 19:05 |
lambday | WeightedDegreePositionStringKernel | 19:05 |
shogun-buildbot | build #1383 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1383 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 19:07 |
@HeikoS | votjakovr: send the pr! :) | 19:12 |
votjakovr | HeikoS: i've just sent | 19:14 |
lambday | HeikoS: sending the patch with the changes for clone-test blacklist.. will add the log-det reduced accuracy after testing | 19:14 |
gsomix | it seems "thunderstorm" is the most frequent news from my village | 19:19 |
gsomix | so, thundrestorm! | 19:19 |
shogun-buildbot | build #1530 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1530 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 19:19 |
@HeikoS | lambday: thanks! I just fixed the memory errors | 19:21 |
@HeikoS | lambday: let me know if you find more | 19:21 |
lambday | HeikoS: okay :) currently checking the log-det thing | 19:21 |
shogun-notifier- | shogun: Heiko Strathmann :develop * 11b9afe / src/shogun/kernel/string/ (2 files): https://github.com/shogun-toolbox/shogun/commit/11b9afed867ed10aaf8f47c54d7a1782e90b2248 | 19:22 |
shogun-notifier- | shogun: fixed two uninitialised memory bugs | 19:22 |
shogun-notifier- | shogun: Heiko Strathmann :develop * 97cd7af / src/shogun/kernel/string/ (2 files): https://github.com/shogun-toolbox/shogun/commit/97cd7af19655332aa91db5a7ea2dc08185478b05 | 19:22 |
shogun-notifier- | shogun: Merge pull request #1295 from karlnapf/develop | 19:22 |
shogun-notifier- | shogun: | 19:22 |
shogun-notifier- | shogun: fixed two uninitialised memory bugs | 19:22 |
@HeikoS | votjakovr: I put some comments in the PR | 19:26 |
@HeikoS | votjakovr: I will merge anyway, but could you change them before doing other things? | 19:27 |
@HeikoS | thanks :) | 19:27 |
@HeikoS | votjakovr: oh you already answered, sorry didnt yee | 19:27 |
shogun-notifier- | shogun: lambday :develop * af2cab3 / tests/unit/base/clone_unittest.cc.py: https://github.com/shogun-toolbox/shogun/commit/af2cab3d8212519dc1dcb0e5b1dc30bef51d6ac2 | 19:28 |
shogun-notifier- | shogun: removed buggy classes from clone-test | 19:28 |
shogun-notifier- | shogun: Heiko Strathmann :develop * 6cfc86f / tests/unit/base/clone_unittest.cc.py: https://github.com/shogun-toolbox/shogun/commit/6cfc86fd0b72082f7aa1177c8fb607e11495a41f | 19:28 |
shogun-notifier- | shogun: Merge pull request #1294 from lambday/feature/log_determinant | 19:28 |
shogun-notifier- | shogun: | 19:28 |
shogun-notifier- | shogun: removed buggy classes from clone-test | 19:28 |
shogun-buildbot | build #1061 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1061 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 19:32 |
-!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has quit [Ping timeout: 264 seconds] | 19:32 | |
-!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has joined #shogun | 19:33 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 19:33 | |
shogun-buildbot | build #748 of rpm1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/rpm1%20-%20libshogun/builds/748 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 19:33 |
@HeikoS | votjakovr: do you know btw why this is: | 19:34 |
@HeikoS | LaplacianInferenceMethod.cpp | 19:34 |
@HeikoS | if (eigen_W.minCoeff() < 0) | 19:34 |
@HeikoS | line 389 | 19:34 |
@HeikoS | this block where the matrix is inverted directly | 19:34 |
@HeikoS | why is that done | 19:35 |
@HeikoS | eigen_L then stores an inverted matrix rather than a cholesky | 19:35 |
shogun-buildbot | build #749 of rpm1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/rpm1%20-%20libshogun/builds/749 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, lambday <heavensdevil6909@gmail.com> | 19:37 |
votjakovr | HeikoS: hmm, it was there before... | 19:38 |
-!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has quit [Ping timeout: 257 seconds] | 19:38 | |
@HeikoS | votjakovr: yeah I know, just wondering for what that is | 19:38 |
@HeikoS | votjakovr: thanks for the patch btw | 19:39 |
@HeikoS | votjakovr: this might be used in our current NIPS paper here :) | 19:39 |
votjakovr | HeikoS: btw gpml uses same trick | 19:39 |
@HeikoS | votjakovr: for the inversion? | 19:39 |
@HeikoS | or for the thing I commented? | 19:40 |
votjakovr | HeikoS: yep, there is switch between Cholesky and LU decomposition mode in GPML | 19:40 |
@HeikoS | votjakovr: I see, ok then leave it, maybe comment it and say that its done as in GPML and maybe even copy the comment the guys made in there | 19:41 |
@HeikoS | votjakovr: how about the logit classifier? you said its done? | 19:41 |
shogun-buildbot | build #1062 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1062 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, lambday <heavensdevil6909@gmail.com> | 19:41 |
shogun-buildbot | build #1265 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1265 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 19:41 |
-!- lisitsyn [~lisitsin@mxs.kg.ru] has quit [Quit: Leaving.] | 19:42 | |
shogun-buildbot | build #1531 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1531 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 19:42 |
votjakovr | HeikoS: yep, but i need to debug a little bit and i'll send a PR with numerical integration and logit tomorrow | 19:43 |
@HeikoS | votjakovr: ok cool! | 19:43 |
@HeikoS | votjakovr: btw did you already have a look at the ipython notebooks? | 19:43 |
@HeikoS | lots of possibilities there for GP stuff | 19:43 |
@HeikoS | lots of potential | 19:43 |
@HeikoS | scikit learn GPs are not as cool as ours, so if we manage to document things well, they will probably be used by many people | 19:44 |
@HeikoS | votjakovr: in fact, a collegue here just started using the regression framework and some things you did | 19:44 |
votjakovr | HeikoS: cool :) i'll have a look at it | 19:46 |
votjakovr | HeikoS: about approximation stuff, sorry, i was in hurry a little bit... I'll do like you suggested | 19:48 |
-!- van51 [~van51@athedsl-399972.home.otenet.gr] has quit [Quit: Leaving.] | 19:48 | |
@HeikoS | votjakovr: dont worry, I think it is a bit faster when you dont do the identity stuff | 19:48 |
@HeikoS | votjakovr: I have another suggestion btw: | 19:49 |
@HeikoS | votjakovr: so currently, the likelihood evaluation gets a vectors of latent functions | 19:49 |
@HeikoS | votjakovr: but sometimes, one wants to evaluate the likelihood for some fixed y for many many fs | 19:50 |
@HeikoS | so it would be cool to have a inline C method for that | 19:50 |
@HeikoS | so that one doesnt need to call it multiple times | 19:50 |
@HeikoS | see what I mean? | 19:50 |
shogun-buildbot | build #1266 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1266 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, lambday <heavensdevil6909@gmail.com> | 19:52 |
votjakovr | HeikoS: yep :) | 19:52 |
@HeikoS | votjakovr: would you add that (returns a matrix rather than a vector | 19:53 |
@HeikoS | (and unit test that results are the same) | 19:53 |
@HeikoS | votjakovr: I think it only needs to be done in base likelihood class | 19:53 |
votjakovr | HeikoS: but currently we can't call method for evaluating the likelihood from there, since it is pure virtual | 19:56 |
@HeikoS | ah damn.... | 19:56 |
@HeikoS | mmh | 19:56 |
@HeikoS | any idea how to solve this? would be annoying to re-write it everytime | 19:56 |
shogun-buildbot | build #1384 of deb3 - modular_interfaces is complete: Failure [failed compile python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1384 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, lambday <heavensdevil6909@gmail.com> | 19:56 |
-!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has joined #shogun | 19:57 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 19:57 | |
votjakovr | HeikoS: hmm, make it not pure virtual :) | 20:03 |
@HeikoS | votjakovr: sounds good, go for it, maybe just add SG_NOTIMPLEMENTED then | 20:12 |
votjakovr | HeikoS: ok | 20:14 |
@iglesiasg | hi pickle27 | 20:19 |
@iglesiasg | pickle27, I am taking a look at the PR | 20:19 |
pickle27 | okay! | 20:19 |
@iglesiasg | pickle27, is there already some unit test for Jade? | 20:20 |
pickle27 | yeah there is one already | 20:21 |
@iglesiasg | pickle27, cool | 20:22 |
pickle27 | iglesiasg: the unit test was being wierd before but I think it should be good now, otherwise I'll take a look into it | 20:23 |
pickle27 | but then again there were bugs in Jade before so | 20:23 |
@iglesiasg | I see | 20:23 |
pickle27 | iglesiasg: is Travis up? | 20:24 |
pickle27 | we can wait and see what it says | 20:24 |
@iglesiasg | pickle27, It didn't start in your pull request for some reason indeed | 20:25 |
votjakovr | pickle27: hi! I've run valgrind on the unit tests and it reported me memory leaks in Jade_unittest.cc and SOBI_unittest.cc, please check it. | 20:28 |
pickle27 | hmmm | 20:28 |
pickle27 | okay | 20:28 |
pickle27 | will do | 20:28 |
pickle27 | can you pastebin the output | 20:28 |
pickle27 | votjakovr: ^ | 20:28 |
votjakovr | pickle27: ok, please wait a minute | 20:29 |
-!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has quit [Ping timeout: 264 seconds] | 20:36 | |
pickle27 | iglesiasg: how do I print a matrix with SGDebug? | 20:36 |
votjakovr | pickle27: http://pastebin.com/Nu1EtfUA and http://pastebin.com/USsdpLMm | 20:42 |
pickle27 | votjakovr: thanks | 20:42 |
@iglesiasg | pickle27, sorry I missed your question | 20:44 |
@iglesiasg | pickle27, did you write it before I commented about that in github or? | 20:44 |
pickle27 | before, so its all good | 20:44 |
pickle27 | Those were the debug prints I was using to get it working and I just thought why delete these? | 20:45 |
pickle27 | so I just ifdef'd them out | 20:45 |
pickle27 | but they aren't key so if you're okay with them as is I say we leave them otherwise I'll just take them out | 20:45 |
@iglesiasg | pickle27, as you prefer | 20:47 |
pickle27 | iglesiasg: okay, have you finished going through? I'll push those changes | 20:47 |
@iglesiasg | pickle27, I guess between DEBUG_JADE is better than nothing | 20:47 |
@iglesiasg | pickle27, it might help people that wants to understand the code | 20:48 |
@iglesiasg | pickle27, sure, go ahead | 20:48 |
pickle27 | iglesiasg: done | 20:49 |
@iglesiasg | pickle27, no idea what's up with travis | 20:51 |
@iglesiasg | pickle27, we will have to merge without it | 20:51 |
@iglesiasg | pickle27, did you run unit tests? for what interfaces are you compiling, libshogun and python_modular maybe? | 20:51 |
pickle27 | yeah those 2, I haven't ran the unit tests but I can | 20:55 |
pickle27 | iglesiasg: unit tests in general aren't running on my machine right now | 20:59 |
pickle27 | I think I need to make clean them | 20:59 |
@iglesiasg | pickle27, aren't running as they fail? | 21:01 |
@iglesiasg | pickle27, just try the ones that are related to your patch if so | 21:01 |
@iglesiasg | something like make to build all of them | 21:01 |
@iglesiasg | when they start running you ctrl+c it | 21:01 |
@iglesiasg | and then | 21:01 |
@iglesiasg | ./shogun-unit-test --filter_test=Jade* | 21:02 |
@iglesiasg | I getting the name of the flag wrong probably, check it in the help of the executable if so | 21:02 |
-!- hushell [~hushell@8-92.ptpg.oregonstate.edu] has joined #shogun | 21:03 | |
@iglesiasg | hi hushell | 21:03 |
hushell | hi iglesiasg | 21:03 |
pickle27 | kk | 21:03 |
@iglesiasg | hushell, I am merging the PR. Let's see if everything is fine, otherwise there is no problem, we modify the test later :) | 21:03 |
@iglesiasg | hushell, for some reason travis is not firing in the pull requests now | 21:03 |
hushell | iglesiasg: I see, I am waiting for travis compiling the PR | 21:04 |
@iglesiasg | hushell, but it didn't even start, right? | 21:04 |
@iglesiasg | hushell, I don't see anything in here | 21:04 |
hushell | yes, I committed 40 mins ago | 21:05 |
shogun-notifier- | shogun: hushell :develop * 41c0b5f / / (12 files): https://github.com/shogun-toolbox/shogun/commit/41c0b5f3aa1a8a1a8ebdaa29733cbc2eb540fdbc | 21:05 |
shogun-notifier- | shogun: Factor Graph | 21:06 |
shogun-notifier- | shogun: Fernando Iglesias :develop * 532ab10 / / (12 files): https://github.com/shogun-toolbox/shogun/commit/532ab10a2fd4a2c04b9402123264400ab9170215 | 21:06 |
shogun-notifier- | shogun: Merge pull request #1224 from hushell/develop | 21:06 |
shogun-notifier- | shogun: | 21:06 |
shogun-notifier- | shogun: Factor Graph | 21:06 |
hushell | iglesiasg: you just merged it? | 21:06 |
-!- pickle27 [~Kevin@d67-193-243-174.home3.cgocable.net] has quit [Quit: Leaving] | 21:08 | |
-!- pickle27 [~Kevin@d67-193-243-174.home3.cgocable.net] has joined #shogun | 21:08 | |
hushell | a short question, for a vector I want to return in the argument, is it better to use SGVector<>& ? I am not sure the case pointer is inside a class | 21:08 |
@iglesiasg | hushell, yep | 21:09 |
@iglesiasg | hushell, use SGVector better please | 21:09 |
hushell | iglesiasg: but sometimes it doesn't work | 21:09 |
@iglesiasg | hushell, an SGVector is basically an int32_t for the length and a T* for the data | 21:09 |
pickle27 | iglesiasg: what was the filter line again? I ctrl L irc and the logs are behind lol | 21:09 |
@iglesiasg | pickle27, can you do ./shogun-unit-test -h? | 21:10 |
@iglesiasg | pickle27, it is one of the first options, --filter sth | 21:10 |
pickle27 | k | 21:10 |
@iglesiasg | pickle27, I never compiled test in the computer I am now so I cannot check it, sorry | 21:11 |
pickle27 | iglesiasg: np | 21:11 |
@iglesiasg | hushell, how that it doesn't work? | 21:11 |
@iglesiasg | pickle27, did you find out? | 21:11 |
pickle27 | yeah I see the option | 21:12 |
hushell | iglesiasg: e.g. CFactor::compute_gradients() I have to use SGVector<float64_t>& parameter_gradient | 21:12 |
pickle27 | just trying to get it to work now | 21:12 |
@iglesiasg | pickle27, what's the name of your test? | 21:12 |
@iglesiasg | hushell, the problem is that SGVector<float64_t>& won't work in target interfaces, just C++ | 21:12 |
hushell | iglesiasg: otherwise nothing returned, this probably this parameter_gradient is passed to anther function inside | 21:12 |
pickle27 | iglesiasg: the file name? | 21:13 |
@iglesiasg | pickle27, yeah that's enough | 21:13 |
hushell | structure/Factor.cpp | 21:13 |
pickle27 | Jade_unittest.cc | 21:13 |
@iglesiasg | pickle27, then something like | 21:13 |
@iglesiasg | pickle27, ./shogun-unit-test --filter=Jade* | 21:13 |
@iglesiasg | should make it | 21:13 |
pickle27 | yeah I just got it | 21:14 |
@iglesiasg | where --filter is the option you have looked up :) | 21:14 |
pickle27 | iglesiasg: it ran | 21:14 |
pickle27 | wait | 21:14 |
pickle27 | it ran but filter didn't work yet | 21:14 |
@iglesiasg | ? | 21:14 |
hushell | :D I got confused talking together with pickle27 at the same time | 21:14 |
@iglesiasg | hushell, hehe yeah sorry :S | 21:15 |
hushell | iglesiasg: not a problem :D | 21:15 |
pickle27 | iglesiasg: k unit test needs some work | 21:16 |
shogun-buildbot | build #1063 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1063 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 21:16 |
hushell | iglesiasg: so you mean a function with argument SGVector& will not working for other languages | 21:16 |
@iglesiasg | hushell, exactly | 21:17 |
@iglesiasg | hushell, I came to know this the hard way a few months ago | 21:17 |
hushell | iglesiasg: next PR will be smaller :) | 21:17 |
shogun-buildbot | build #750 of rpm1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/rpm1%20-%20libshogun/builds/750 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 21:18 |
votjakovr | pickle27: i ran Jade unit-test with valgrind --leak-check=full ./shogun-unit-test --gtest_filter=CJade*. It might be useful | 21:18 |
@iglesiasg | hushell, :) | 21:18 |
hushell | iglesiasg: okay then I need to figure out how to deal with the return arugment problem, not using & | 21:18 |
pickle27 | votjakovr: thanks, I looked at your valgrind logs and it didn't help much | 21:19 |
@iglesiasg | hushell, It should be totally fine to return SGVector | 21:19 |
@iglesiasg | man I love cyg1 buildbot saying "Error: no C++ compiler detected - cannot do anything" | 21:19 |
gsomix | iglesiasg, "won't work in target interfaces, just C++" << strange | 21:23 |
@iglesiasg | gsomix, really? | 21:24 |
@iglesiasg | gsomix, I had some problems already with methods accepting things with & | 21:24 |
@iglesiasg | gsomix, they didn't work in python_modular | 21:24 |
gsomix | swig just should transform reference to pointer in generated code | 21:24 |
gsomix | maybe we just need another typemap for this case | 21:25 |
gsomix | I'll check. | 21:25 |
@iglesiasg | gsomix, yes, a typemap can fix it maybe. At the moment it didn't work though | 21:25 |
pickle27 | iglesiasg: I fixed the unit test and pushed | 21:26 |
shogun-buildbot | build #1267 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1267 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 21:26 |
@iglesiasg | pickle27, all good now then? | 21:27 |
pickle27 | iglesiasg: I think so | 21:27 |
shogun-buildbot | build #1534 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1534 blamelist: hushell <hushell@hushell-U510.(none)> | 21:27 |
pickle27 | there is the possible leak the votjakovr found but | 21:27 |
@iglesiasg | gsomix, I remember I changed some SGMatrix const & to SGMatrix const, because it didn't work with the reference | 21:28 |
pickle27 | it all runs and passes the test | 21:28 |
@HeikoS | votjakovr: there are some issues with swig :( | 21:28 |
@HeikoS | votjakovr: I think we will have to move all GP stuff to one directory | 21:28 |
@iglesiasg | gsomix, I am not sure though if it is just with SGVector/SGMatrix or also with other types like int and so | 21:28 |
votjakovr | HeikoS: yep, i know | 21:28 |
@HeikoS | votjakovr: ah well, annoying, since it was just all moved | 21:29 |
gsomix | iglesiasg, but I have one question. what's going with reference counting on while passing SGVector<>&? | 21:29 |
@HeikoS | votjakovr: I suggest move everything to machine/gp? | 21:29 |
gsomix | iglesiasg, ok. | 21:29 |
@HeikoS | votjakovr: could you do that? | 21:29 |
@iglesiasg | gsomix, I never thought of that actually | 21:29 |
@iglesiasg | pickle27, you didn't see that leak in your valgrind? | 21:30 |
@HeikoS | votjakovr: and then add all classes in interfaces/modular/Machine.i and Machine_includes.i and remove them in the other files? | 21:30 |
pickle27 | iglesiasg: I do but there isn't really any other output from valgrind so Im confused | 21:30 |
pickle27 | Im swithcing something with my SGNDArray | 21:30 |
pickle27 | I think that might be it | 21:31 |
@HeikoS | votjakovr: I think this should solve all problems | 21:32 |
@HeikoS | votjakovr: or should I quickly do it? | 21:32 |
votjakovr | HeikoS: hmm... why don't move to gp/? | 21:32 |
@HeikoS | votjakovr: since its machine based and we need things in swig from machine (I think at least) | 21:33 |
votjakovr | HeikoS: ok | 21:34 |
votjakovr | HeikoS: btw i've updated my PR | 21:34 |
lambday | HeikoS: regarding log-det unit-test, with 500 Gaussian samples after running 100,000 times, max difference I get is 1.9944846621, shall I just put it 2.0 ? | 21:35 |
@iglesiasg | all right, I am off now. See you later if so | 21:36 |
-!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has quit [Quit: Leaving] | 21:36 | |
@sonney2k | HeikoS, lambday any clues why this fails http://www.shogun-toolbox.org/buildbot/builders/rpm1%20-%20libshogun/builds/750/steps/compile/logs/stdio ? | 21:37 |
lambday | sonney2k: checking | 21:37 |
@sonney2k | lambday, thx | 21:38 |
lambday | sonney2k: I just fixed it and sent a patch.. merged already | 21:39 |
lambday | sonney2k: still it gives this error? | 21:39 |
@HeikoS | lambday: yep | 21:40 |
@HeikoS | sonney2k: hey do you have a suggestion how to do GPs with swig? | 21:41 |
@HeikoS | like in which folder to put stuff | 21:41 |
@HeikoS | currently it is located in many folders some regression some classification etc | 21:41 |
pickle27 | votjakovr: I found the leak but I don't understand it | 21:41 |
@HeikoS | sonney2k: but we seem to get issues with swig | 21:41 |
pickle27 | its the call to delete my SGNDArray | 21:41 |
@HeikoS | sonney2k: and there are also these things in machine.i | 21:41 |
@HeikoS | and GPs are inheriting from machine | 21:41 |
@HeikoS | sonney2k: so where to put them, does it matter, doesnt it matter? etc | 21:42 |
@sonney2k | man you guys have been chatty! | 21:45 |
@sonney2k | I can hardly read all the logs PR comments | 21:45 |
-!- travis-ci [~travis-ci@ec2-75-101-178-60.compute-1.amazonaws.com] has joined #shogun | 21:46 | |
travis-ci | [travis-ci] it's Heiko Strathmann's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/9441946 | 21:46 |
-!- travis-ci [~travis-ci@ec2-75-101-178-60.compute-1.amazonaws.com] has left #shogun [] | 21:46 | |
@sonney2k | HeikoS, yeah makes sense to put the regression part in regression and classification in classification | 21:47 |
@HeikoS | votjakovr: ok so then lets leave it as it is and figure out the swig issues :) | 21:47 |
@HeikoS | votjakovr: so ill try to do that | 21:48 |
gsomix | sonney2k, so, LineReader class + Parsers, right? | 21:48 |
gsomix | sonney2k, good evening | 21:48 |
votjakovr | HeikoS: Ok :) | 21:48 |
votjakovr | HeikoS: btw, please, check my PR, i've updated it | 21:49 |
shogun-notifier- | shogun: Roman Votyakov :develop * a3e4f75 / / (4 files): https://github.com/shogun-toolbox/shogun/commit/a3e4f75c554321adb6bd9593e5e09067223acd9d | 21:49 |
shogun-notifier- | shogun: add posterior approximation mean and covariance for Laplacian inference method | 21:49 |
shogun-notifier- | shogun: Heiko Strathmann :develop * 1099384 / / (4 files): https://github.com/shogun-toolbox/shogun/commit/10993840452cc46f1ebbf51291a4af2febd598f1 | 21:49 |
shogun-notifier- | shogun: Merge pull request #1293 from votjakovr/feature/gp_refactoring | 21:49 |
shogun-notifier- | shogun: | 21:49 |
shogun-notifier- | shogun: add posterior approximation mean and covariance for Laplacian inference method | 21:49 |
@HeikoS | :) | 21:49 |
votjakovr | :) | 21:49 |
@sonney2k | HeikoS, what swig issues? | 21:49 |
@HeikoS | sonney2k: classes not found etc | 21:49 |
@sonney2k | gsomix, yes Parser would be your old Reader class | 21:49 |
@HeikoS | its a bit painfull since its spread in machine/regression/classifier | 21:50 |
@sonney2k | HeikoS, w/ swig the order of includes matters | 21:50 |
gsomix | sonney2k, ok, that's right. :) | 21:50 |
gsomix | sonney2k, preparing PR, need test some stuff. | 21:50 |
@sonney2k | HeikoS, you need to include classes that are dependencies first! | 21:50 |
@sonney2k | lambday, what is this template<class T, class ST=T> ? | 22:00 |
@sonney2k | in shogun/mathematics/logdet/IterativeShiftedLinearFamilySolver.h | 22:00 |
-!- lambday [67157d36@gateway/web/freenode/ip.103.21.125.54] has quit [Ping timeout: 250 seconds] | 22:03 | |
shogun-buildbot | build #1536 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1536 blamelist: Roman Votyakov <votjakovr@gmail.com> | 22:07 |
shogun-buildbot | build #1385 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1385 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 22:07 |
-!- travis-ci [~travis-ci@ec2-75-101-178-60.compute-1.amazonaws.com] has joined #shogun | 22:09 | |
travis-ci | [travis-ci] it's Heiko Strathmann's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/9442095 | 22:09 |
-!- travis-ci [~travis-ci@ec2-75-101-178-60.compute-1.amazonaws.com] has left #shogun [] | 22:09 | |
-!- zxtx [~zv@rrcs-76-79-81-162.west.biz.rr.com] has joined #shogun | 22:22 | |
shogun-buildbot | build #1537 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1537 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 22:24 |
-!- van51 [~van51@athedsl-399972.home.otenet.gr] has joined #shogun | 22:34 | |
-!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has left #shogun ["Fallen asleep!"] | 23:07 | |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * a059a1f / src/shogun/mathematics/logdet/ (2 files): https://github.com/shogun-toolbox/shogun/commit/a059a1ffb9e4052bdd52c01b84ed301a33d44a76 | 23:18 |
shogun-notifier- | shogun: drop default type to hopefully fix compile error | 23:18 |
shogun-notifier- | shogun: van51 :develop * 63ae07c / / (3 files): https://github.com/shogun-toolbox/shogun/commit/63ae07cbe4b0ffb05de7d029e969d29e1e21cdf8 | 23:20 |
shogun-notifier- | shogun: Quadratic support in HashedDenseFeatures | 23:20 |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * f0af8bf / / (3 files): https://github.com/shogun-toolbox/shogun/commit/f0af8bf45c00b983abb88ecb153d1afef81cb099 | 23:20 |
shogun-notifier- | shogun: Merge pull request #1292 from van51/feature/quadratic | 23:20 |
shogun-notifier- | shogun: | 23:20 |
shogun-notifier- | shogun: Quadratic support in HashedDenseFeatures | 23:20 |
van51 | ah cool :D | 23:21 |
van51 | sonney2k: do you have in mind another collection I could test the hasheddocfeatures on? | 23:22 |
@sonney2k | van51, collection? | 23:22 |
@sonney2k | van51, dataset you mean? | 23:22 |
van51 | sonney2k: yes | 23:23 |
van51 | sonney2k: document collection I meant to say | 23:23 |
@sonney2k | van51, I still would want you to do the language detection thing | 23:23 |
@sonney2k | van51, but for this you need to do some wikipeidia harvesting | 23:23 |
van51 | sonney2k: that would be to get documents from wikipedia right? | 23:23 |
@sonney2k | van51, yes | 23:23 |
van51 | sonney2k: I can get the documents from another language, right? | 23:24 |
@sonney2k | so for each supported language download say 10000 text documents | 23:24 |
@sonney2k | randomly | 23:24 |
van51 | programming language* | 23:24 |
@sonney2k | van51, sure some wget / python whatever | 23:24 |
van51 | sonney2k: ok then :) | 23:25 |
@sonney2k | I would prepare the final data similar to webspam then label with 0...<n_langs> | 23:25 |
@sonney2k | and 0 terminated documents | 23:25 |
@sonney2k | van51, btw did you do finish the evaluations for webspam? | 23:26 |
van51 | sonney2k: should I strip the html completely? | 23:26 |
@sonney2k | van51, yeah | 23:26 |
@sonney2k | just plain text | 23:26 |
@sonney2k | van51, I guess n-grams will work best again | 23:26 |
van51 | sonney2k: yea I finished it | 23:26 |
van51 | there was a link in the email | 23:26 |
van51 | let me fetch it again | 23:26 |
@sonney2k | van51, svmocas with eps 1e-2? | 23:26 |
@sonney2k | van51, let me check | 23:26 |
@sonney2k | van51, please also run it with liblinear eps 1e-2 | 23:27 |
van51 | sonney2k: here : https://dl.dropboxusercontent.com/u/23851310/webspam_results.pdf | 23:27 |
@sonney2k | van51, found it reading... | 23:27 |
van51 | sonney2k: ok I'll leave it running tonight | 23:27 |
@sonney2k | sonney2k, liblinear might be faster | 23:30 |
@sonney2k | van51, T^ | 23:30 |
shogun-buildbot | build #751 of rpm1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/rpm1%20-%20libshogun/builds/751 blamelist: van51 <vangelis_51@hotmail.com> | 23:30 |
@sonney2k | van51, interesting that C=1 gave even better results | 23:31 |
@sonney2k | van51, I can only guess that the train/test data split that you used gives different results auROC wise... 99.9 vs 99.6 seems quite a bit though | 23:32 |
@sonney2k | hope it is not train error :) | 23:32 |
van51 | sonney2k: nope it's test error | 23:33 |
van51 | sonney2k: do you want to chck the example? | 23:33 |
van51 | sonney2k: I'm worried I may have missed something | 23:33 |
@sonney2k | van51, I read the example code already | 23:33 |
@sonney2k | didn't see a mistake | 23:33 |
van51 | well the language detection will also be a nice indicator | 23:34 |
@sonney2k | van51, but it is worrying that for 5000 examples with hashing you are as good as the spectrum kernel on 100k examples | 23:34 |
shogun-buildbot | build #752 of rpm1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/rpm1%20-%20libshogun/builds/752 blamelist: Soeren Sonnenburg <sonne@debian.org> | 23:34 |
@sonney2k | van51, true | 23:35 |
shogun-buildbot | build #1064 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1064 blamelist: van51 <vangelis_51@hotmail.com> | 23:36 |
shogun-buildbot | build #1065 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1065 blamelist: Soeren Sonnenburg <sonne@debian.org> | 23:37 |
shogun-buildbot | build #1538 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1538 blamelist: Soeren Sonnenburg <sonne@debian.org> | 23:37 |
shogun-buildbot | build #1268 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1268 blamelist: van51 <vangelis_51@hotmail.com> | 23:39 |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * 73cb5a2 / src/shogun/machine/gp/InferenceMethod.h: https://github.com/shogun-toolbox/shogun/commit/73cb5a238f58e10afa8fa5694af530103c04dea0 | 23:39 |
shogun-notifier- | shogun: fix doxygen doc | 23:39 |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * 07e8f7c / src/shogun/mathematics/Math.h: https://github.com/shogun-toolbox/shogun/commit/07e8f7ce467a61b565b3f6694fb976465cb27047 | 23:39 |
shogun-notifier- | shogun: drop std cmath compile workaround | 23:39 |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * ad88090 / src/configure: https://github.com/shogun-toolbox/shogun/commit/ad8809008204fb70cd82a6ed137b30b771edd09c | 23:43 |
shogun-notifier- | shogun: drop C warning option -Werror-implicit-function-declaration from compile flags | 23:43 |
gsomix | sonney2k, hey, can you help me? | 23:45 |
@sonney2k | gsomix, wasup? | 23:48 |
gsomix | sonney2k, I have strange errors in unit-tests. and just curious, is it only in my repo? http://pastebin.com/u2DyVu35 | 23:49 |
shogun-buildbot | build #1269 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1269 blamelist: Soeren Sonnenburg <sonne@debian.org> | 23:49 |
-!- travis-ci [~travis-ci@ec2-75-101-178-60.compute-1.amazonaws.com] has joined #shogun | 23:51 | |
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/9445183 | 23:51 |
-!- travis-ci [~travis-ci@ec2-75-101-178-60.compute-1.amazonaws.com] has left #shogun [] | 23:51 | |
shogun-buildbot | build #1386 of deb3 - modular_interfaces is complete: Failure [failed compile python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1386 blamelist: Soeren Sonnenburg <sonne@debian.org>, van51 <vangelis_51@hotmail.com> | 23:51 |
gsomix | trying to reconfigure/recompile | 23:51 |
-!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has joined #shogun | 23:58 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 23:58 | |
@sonney2k | gsomix, hmmhh then just run your test with the filter thing | 23:58 |
@iglesiasg | hushell, it seems the evaluate_energy_param_data test is still failing on travis | 23:59 |
--- Log closed Thu Jul 25 00:00:46 2013 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!