15:14 < zoq> naywhayare: Oh big is back, new switch?

15:20 < naywhayare> zoq: new switch, same problem... 143.215.128.x is still mostly inaccessible :(

15:25 < zoq> So I guess it's not a hardware issue ...

15:27 < naywhayare> yeah, it must be a misconfiguration in the switch or something like that

15:28 < naywhayare> not much I can do... :-\

20:09 < naywhayare> stephentu: something I noticed is that chol(..., "lower") isn't available until Armadillo 4.600.x

20:10 < naywhayare> I'm not the biggest fan of this, but I'm thinking of #ifdef'ing for Armadillo < 4.600 and then doing "covLower = arma::chol(covariance).t()"

20:10 < naywhayare> I'm not seeing any other way to refactor that easily

20:11 < stephentu_> oh

20:11 < naywhayare> ah, I think you missed the first message

20:11 < naywhayare> that or it's sitting at your home :)

20:11 < stephentu_> probably

20:11 < naywhayare> 20:09 < naywhayare> stephentu: something I noticed is that chol(..., "lower") isn't available until Armadillo 4.600.x

20:11 < stephentu_> #ircfail

20:11 < naywhayare> :)

20:11 < stephentu_> ya ok

20:11 < stephentu_> so i think we should just arma::chol(cov).t() always

20:11 < stephentu_> no need to ifdef

20:12 < naywhayare> hm, let me ensure that that is as fast as chol(cov, "lower")

20:12 < stephentu_> when i set up travis CI

20:12 < stephentu_> we can have a matrix of builds

20:12 < stephentu_> and build against like major versions of arma

20:12 < naywhayare> that's what I have set up in Jenkins :)

20:12 < naywhayare> I think with Travis the issue is going to be having enough horsepower to test all the builds

20:13 < naywhayare> pretty sure we have to pay them for more than 1 simultaneous build (if I understood their terms right)

20:14 < stephentu_> oh right

20:14 < stephentu_> well it'll still be nice to have at least another sanity check for pull reqs

20:14 < naywhayare> yes, definitely

20:15 < stephentu_> does mlpack have any $?

20:15 < naywhayare> honestly testing against the oldest supported version might be the best way to test reverse compatibility

20:15 < naywhayare> nope

20:15 < naywhayare> I have access to all manner of old computers and systems via Georgia Tech, but no cash

20:15 < naywhayare> GSoC pays a bit to the mentors, but we've traditionally just given that to the mentors

20:16 < naywhayare> when I graduate, I'll probably have a few bucks I'm willing to invest into mlpack, although I am looking for a company that will be interested in investing money and time into mlpack too

20:17 < naywhayare> also, it looks like chol().t() doesn't evaluate at compile time to chol(cov, "lower")

20:17 < naywhayare> so I think I'll just do the #ifdef thing for now

20:19 < stephentu_> cool thanks for doing the benchmarking also

20:20 < naywhayare> yeah, I noticed that it was slower on my desktop system

20:20 < naywhayare> so I dug further into it on a dedicated system for benchmarking and couldn't reproduce it

20:20 < naywhayare> so I shrugged and figured that maybe something else I was doing on the desktop was causing weird results

20:34 < zoq> I think mlpack's build farm (jenkins) offers way more features which is great. Anyway it's not correct that you have to pay travis to run simultaneous builds. If you create a build matrix travis automatically runs different configurations on 'different' vm's.

20:36 < naywhayare> ah, okay, I looked closer and I see it's "fair use"

20:36 < naywhayare> for the free plan

20:36 < naywhayare> so I suppose that Travis just throws open-source jobs into a giant queue and then builds them when they get around to it

20:37 < naywhayare> from somewhere in the documentation: "Please take into account that Travis CI is an open source service and we rely on worker boxes provided by the community. So please only specify an as big matrix as you actually need."

20:38 < naywhayare> so maybe we should go with a minimal build matrix for travis... i.e. debug/release, two or three versions of armadillo, and i386/x86_64 (maybe i386 isn't necessary, but I've found a lot of bugs like that)

20:44 < zoq> Under the hood they are using docker. If I remember right they have the capacity to start the build in less less than 10 seconds. The build is limited in runtime, so maybe we can't run all test in time. Really nice people, I've met some from the travis team. I'm not sure if we really need a matrix build if we just check if the pull request is okay.

20:46 < naywhayare> yeah; I don't mind just checking if the PR builds and accepting based on that

20:46 < naywhayare> then if there are Armadillo compatibility issues, I can work those out after the nightly matrix build pretty easily

20:56 < zoq> Sounds good, I just wanted to clarify that you can test different configuration simultaneously.

20:57 < naywhayare> yeah, thanks for pointing that out

20:57 < naywhayare> I must have misunderstood last time I read the website

20:57 < naywhayare> I think ideally I'd love to pay (or donate since it's open-source?) Travis CI to manage the build matrices and everything, and then maybe keep some systems set aside for benchmarking purposes

21:02 < naywhayare> (just have to find the money first I suppose...)

21:03 < zoq> Yeah I would like that: http://love.travis-ci.com/

21:08 < naywhayare> wow, only 40 physical servers; I would have expected a lot more

21:11 < zoq> I think most of the projects don't need much time to build and to run all tests.