06:55 < stephentu> naywhayare: i'm trying to get travis CI to build mlpack

06:55 < stephentu> stuck on this

06:55 < stephentu> https://travis-ci.org/stephentu/mlpack/builds/50812226#L460

06:55 < stephentu> its the unsupported type error

06:55 < stephentu> so i followed the advice you gave in

06:55 < stephentu> https://github.com/mlpack/mlpack/issues/397

06:55 < stephentu> so basically I sudo cp a custom config.hpp

06:55 < stephentu> which looks like

06:56 < stephentu> https://github.com/stephentu/mlpack/blob/master/.travis/config.hpp

06:56 < stephentu> specifically I make it do #if !defined(ARMA_USE_CXX11) #define ARMA_USE_CXX11

06:57 < stephentu> i'll try ARMA_64BIT_WORD now

06:57 < stephentu> to see if that does anything

07:02 < stephentu> naywhayare: actually that seems to ahve done the trick

07:53 < stephentu> naywhayare: https://travis-ci.org/stephentu/mlpack/builds/50813696

07:53 < stephentu> it appears to be stuck?

07:53 < stephentu> whats this "compiled with debug symbols" at the end

09:13 < awhitesong> naywhayare: not sure if you got this message , ya will surely look into armadillo wrappers. Thanks.

18:37 < naywhayare> stephentu: the build fails with "No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself."

18:37 < naywhayare> but this is more a factor of mlpack_test taking a rather long time

18:38 < naywhayare> if there's some way you can increase the timeout, the test usually takes probably 45min-1hr when compiled in debug mode

18:39 < naywhayare> if not, you can run mlpack_test with verbose output ('--log_level all' or '-l all') and I think that'll be enough output to make travis happy

18:40 < naywhayare> failing that, we can hunt down the tests that are taking over ten minutes and figure out how to make them shorter (which is probably a thing that should happen anyway)

18:42 < stephentu> naywhayare: ya i guess my questionw as, do we actually have tests that take 10 min to run

18:42 < stephentu> i'll bump the timeout and make it more verbose

18:50 < naywhayare> we shouldn't have tests that take more than ten minutes each, but there may be one or two which could probably be refactored to be shorter

18:52 < stephentu> naywhayare: i'm surprised thsi boost test thing doesnt have a way to run test in parallel

18:55 < stephentu> naywhayare: although we could sort of do it by running multiple bin/mlpack_test instances with different filters

20:11 < stephent1> naywhayare: travis CI only gives us 50 min

20:11 < stephent1> to run tests

20:11 < stephent1> so we might need to have a reduced test suite

20:11 < stephent1> or for now we can just test compilation

20:12 < stephent1> oh shit

20:12 < stephent1> naywhayare: i accidentally pushed to the mainstream branch

20:12 < stephent1> all the travis CI stuff

20:12 < stephent1> https://github.com/mlpack/mlpack/commits/master

20:13 < stephent1> should I revert it all or rewrite the history?

20:49 < naywhayare> stephent1: don't worry about it, it's not a problem

20:49 < naywhayare> travis.yml doesn't actually affect anything in mlpack, so I don't think it's a problem

20:49 < naywhayare> entertaining commit messages too :)

20:50 < naywhayare> I personally think that build rules fit better into a separate, auxiliary repository (in svn we used mlpack/conf/ instead of mlpack/trunk/) but I don't think that this makes much sense with git and I'm not sure that's how travis works

22:22 < stephentu> naywhayare: well, you could have a hook in mlpack

22:22 < stephentu> which on commit

22:22 < stephentu> pushes to another repo

22:22 < stephentu> which has the build config

22:24 < stephentu> ok so i think what i will do next is

22:24 < stephentu> write a script that basically greps out all the test suites

22:24 < stephentu> and then we can shard out the test suites using the filtering options of mlpack_test

22:24 < stephentu> unless you have a better idea of how to get a list of all possible test cases

22:25 < stephentu> then we can run the tests in parallel and hopefully get under the 50 minute build time

22:25 < stephentu> (or exclude the tests which dont pass)

22:25 < stephentu> (i mean take too long)

22:32 < naywhayare> I saw that the FastMKS test takes 20 minutes in debug mode when I looked at the Jenkins reports:

22:32 < naywhayare> http://big.cc.gt.atl.ga.us:8080/job/mlpack%20-%20nightly%20matrix%20build/arch=linux-i386,armadillo=armadillo-4.200.0,buildmode=debug/735/testReport/MLPACKTest/

22:33 < naywhayare> wow, and in that case TreeTest took 29 minutes

22:33 < naywhayare> I'll see if there are quick fixes for those tomorrow

23:14 < stephentu> cool

23:14 < stephentu> but ya once we get the test time down we'll have auto travis builds