03:33 < Sthita_> I am new to this community.How to i get started in contributing?

17:51 < zoq> Sthita_: Hello, have you seen: http://www.mlpack.org/involved.html.

17:51 < zoq> In case he reads the logs.

18:54 < pvskand> @rcurtin, approximately when can we expect the new release of mlpack with the gsoc 17 works?

18:57 < rcurtin> pvskand: not sure, there is still some amount of work to do, we also have to plan for what features we want to see

18:57 < rcurtin> if you want to help out you are more than welcome to of course :)

18:58 < rcurtin> my thoughts for the things that need to happen (in large strokes) are:

18:59 < rcurtin> - some nice benchmark results showing that mlpack is faster for a handful of common machine learning tasks (I am working on this now)

18:59 < rcurtin> - stable neural network code plus some examples and tutorials

18:59 < rcurtin> - handling any reverse compatibility issues (that have comments like 'this can be removed for mlpack 3.0.0', etc.)

19:00 < rcurtin> - python bindings a little more battle-tested than they are now

19:00 < rcurtin> it would be nice to be able to support non-double matrices in general across mlpack, but I think that is too lofty a goal for 3.0.0

19:01 < rcurtin> I'm not sure if zoq or anyone else has any other ideas of what should get done before, but that seems like a reasonable-ish roadmap for me

19:06 < pvskand> Could you elaborate on : >> stable neural network code plus some examples and tutorials

19:08 < rcurtin> it's not ready for release quite yet, there are some open issues that need to be handled like batch support and so forth

19:10 < rcurtin> zoq would probably have the best idea of what he'd like to see before that's ready

19:15 < pvskand> aah.. okay I have gone through the batch support issue and PR. I understand now

19:20 < zoq> batch support, examples + tutorials, GSoC projects (batchnorm, NTM, RBM, etc.) is what I'd like to finish before 3.0

19:20 < zoq> as rcurtin already said you are welcome to help :)

19:24 < zoq> http://www.mlpack.org/gsocblog/index.html

19:25 < zoq> Not as straightforward as I thought ... the doxygen that comes with Ubuntu 16.04 doesn't include some javascript files (there is an open bug report), building/switching to the latest doxygen version fixed the issue.

19:25 < rcurtin> yeah, the version on mlpack.org uses doxygen 1.8.13

19:26 < rcurtin> so the css/js I built depends on that

19:26 < zoq> right

19:26 < rcurtin> I think you built different js/scripts for the blog stuff though

19:26 < rcurtin> I guess, if you wanted, we could have the blog job execute on mlpack.org

19:26 < rcurtin> and that way we are guaranteed the css is the same version as there

19:28 < rcurtin> anyway it really looks nice, I think it is an improvement because it matches the doxygen output a lot better :)

19:29 < zoq> So remove the blog repo and give 'everyone' write access on the mlpack.org repo?

19:34 < rcurtin> ah, no, I was thinking of adding mlpack.org as a slave to Jenkins, then running the gsoc-blog job specifically on the mlpack.org node and copying the result to the right place

19:34 < zoq> Still have to 'backport' some existing blog posts, so that if someone linked to it, it shows the correct page, already did this for the 2017 summary posts.

19:34 < zoq> ah, yeah, nice idea

19:35 < zoq> that would solve the sandboxed issue: https://stackoverflow.com/questions/34315723/blocked-script-execution-in-url-because-the-documents-frame-is-sandboxed-and

19:36 < rcurtin> yeah, and I don't need apache proxies anymore, I can just use a symlink

19:36 < rcurtin> let me get that set up...

19:49 < rcurtin> zoq: ok, now the gsoc-blog job runs directly on mlpack.org and uses the system doxygen installation

19:49 < rcurtin> now /var/www/www.mlpack.org/gsocblog/ is a symlink directly to /home/jenkins/mb-slave/workspace/gsoc-blog/script/blog/doxygen/

19:50 < zoq> hm, GET http://www.mlpack.org/gsocblog/dynsections.js net::ERR_ABORTED

19:50 < zoq> which contains the toggle function ...

19:50 < zoq> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809525

19:52 < rcurtin> strange, one workaround is just to copy it into place... what do you think?

19:52 < zoq> I solved the issue by building the latest doxygen version, which I guess is the same version as on mlpack.org 1.8.13

19:52 < rcurtin> dynsections.js is properly being built for the mlpack documentation, maybe there is something different in the Doxyfile

19:52 < zoq> sounds fine for me :)

19:53 < zoq> pretty much used the same Doxyfile

19:54 < rcurtin> hmm, I don't see HTML_DYNAMIC_SECTIONS in the Doxyfile

19:54 < rcurtin> we could try enabling it, what do you think? we could also do the same for the default mlpack Doxyfile too

19:57 < zoq> hm, the mlpack.org does provide: http://www.mlpack.org/docs/mlpack-2.2.5/doxygen/dynsections.js

19:57 < zoq> I guess even without HTML_DYNAMIC_SECTIONS

19:58 < zoq> we can just copy the file as you said

19:59 < zoq> but it's definitely strange

20:00 < rcurtin> yeah, the bug seems to indicate that every with HTML_DYNAMIC_SECTIONS = YES, the file may still not be generated

20:00 < rcurtin> so I'll just add it as a part of the build step, we can copy it from docs/mlpack-2.2.5/...

20:00 < zoq> okay

20:14 < rcurtin> http://www.mlpack.org/gsocblog/dynsections.js

20:14 < rcurtin> seems to be in the right place now

20:15 < zoq> Great, thanks for taking care of the issue.

20:16 < rcurtin> sure, I think you have an account on all the necessary systems so if you need to debug further you can do that

20:16 < rcurtin> if not or if it doesn't work let me know

20:18 < zoq> okay