01:38 < rcurtin> robertohueso: I'm looking at the subspace tree implementation and wondering if the best way to do this might be to store µ, U, Λ, and d in a StatisticType

01:38 < rcurtin> and actually for the splitting mechanism, it looks like Dongryeol suggests the kd-tree strategy

01:39 < rcurtin> which would mean that all you'd need is a custom StatisticType... if I am understanding right...

07:40 < jenkins-mlpack2> Project docker mlpack nightly build build #362: STILL UNSTABLE in 3 hr 26 min: http://ci.mlpack.org/job/docker%20mlpack%20nightly%20build/362/

12:18 < Aryan> Hello!

12:19 < Aryan> Can someone guide me on how i can contribute?

12:23 < zoq> Aryan: Hello there, https://www.mlpack.org/community.html should provide the information you asked for; see the getting involved section

13:27 < Jeffin143> rcurtin , zoq : do you use cmd-line to review pull request, i mean comment and reply ?

13:28 < zoq> Jeffin143: No I use the webinterface.

13:33 < Jeffin143> zoq : ok :)

13:37 < xiaohong> Hi, if I want to rebuild the CI, I just use the command `@mlpack-jenkins`, right?

13:41 < zoq> xiaohong: Hey, that only works for jenkins jobs (style, static, memory, latex). I can restart the travis build for you.

13:42 < xiaohong> zoq: Okay, I am not sure why the last CI test is failed, I am trying to rebuild it. Can you help me restart it?

13:44 < zoq> the PPO PR?

13:48 < xiaohong> No, it is the pendulum PR.

13:48 < xiaohong> https://github.com/mlpack/mlpack/pull/1931

13:49 < xiaohong> The test 126/142 Test #140: RadicalMainTest ..................***Failed 0.99 sec is failed.

13:52 < zoq> ahh, I see you can ignore the failing test, there is an open PR which should make the test more stable.

14:10 < xiaohong> zoq: Ok, thank you for your clarification.

19:55 < gmanlan> zoq: you there?

19:55 < zoq> yes

19:56 < gmanlan> qq: did you have the chance to work on the website distribution list table?

19:58 < zoq> yes, I made some progress, but there is still some work left to do, I think I can finish the rest, early next week.

19:59 < gmanlan> ok that sounds good - if at some point you believe it's getting complicated or overwhelming, please don't worry - we can try an intermediate solution first if needed

19:59 < gmanlan> I would like to wrap up the new website next week if possible, so we can iterate over it with new-smaller PRs for the improvements

20:01 < zoq> Agreed, if you like we can just go with the current solution and I can open a PR later.

20:01 < gmanlan> ok - will wait until earlier next week, and then we see from there

20:02 < gmanlan> thanks zoq

20:02 < zoq> okayy, sounds good

20:02 < gmanlan> rcurtin: you know the website scripts better than me, could you please send me/show me an already "processed" doxygen package to "paste" into the website so I can work on formatting?

20:06 < rcurtin> gmanlan: oh, right! I forgot I was going to do that

20:07 < rcurtin> hang on

20:07 < gmanlan> np :)

20:11 < rcurtin> https://www.ratml.org/misc/mlpack-doc.tar.gz

20:11 < rcurtin> this directory contains all the preprocessed doxygen output in doc/; basically, this is what gets generated and dropped into the doc/ directory before Jekyll builds the whole website

20:12 < rcurtin> there are two pieces here: each doc/mlpack-x.y.z/ directory contains the Doxygen documentation (after postprocessing, which we can change as we need) in doxygen/ and the Markdown bindings as the .md files

20:12 < gmanlan> excellent, thanks! - and the CSS for doxygen is being read from the base jekyll site right?

20:13 < rcurtin> some of the .md files are not meant to be viewed by users; the ones that users see (or will find links to) are cli_documentation.md and python_documentation.md (and more as more languages are added)

20:13 < rcurtin> sort of... Doxygen also contains its own CSS in the doxygen/ directory that may need some modification

20:14 < gmanlan> got it, thanks rcurtin

20:14 < gmanlan> please keep that .tar.gz there for a while, I may need to download it again later

20:19 < rcurtin> yeah, I won't move it, I'll probably have forgotten about it by tomorrow :)

20:28 < gmanlan> :)

21:24 < sreenik[m]> rcurtin: What namespaces are okay with mlpack's design conventions? What I am currently using are mlpack::ann, mlpack and std. Also to mention, I have purposefully avoided using arma.

21:44 < rcurtin> sreenik[m]: doesn't matter much to me, but what's the context?

21:44 < rcurtin> we shouldn't have any 'using namespace' directives in .hpp files

21:44 < rcurtin> but that's the only real restriction that I see

21:44 < rcurtin> (if you use a 'using' directive in a header file, if someone includes mlpack then they are automatically 'using' that namespace too, which may break their code depending...)

21:44 < sreenik[m]> Yes, I was talking about .hpp files only

21:45 < sreenik[m]> Oh yes, that solves it :)

21:46 < rcurtin> :)

21:55 < travis-ci> robertohueso/mlpack#20 (mc_kde_error_bounds - 719c8bf : Roberto Hueso Gomez): The build was broken.

21:55 < travis-ci> Change view : https://github.com/robertohueso/mlpack/compare/32f536fb78a0...719c8bfa92f9

21:55 < travis-ci> Build details : https://travis-ci.org/robertohueso/mlpack/builds/548397455