04:06 < robbb08> hey, is the image loading PR completed?

06:04 < ShikharJ> Toshal: Are you there?

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

11:28 < xiaohong> Hi, can anyone share ideas how to debug the unit test when tunes the parameter?

11:29 < xiaohong> What I do is to print the output, but it seems inefficient.

11:31 < zoq> xiaohong: For fintuning or to find an issue?

11:31 < xiaohong> Currently I am finding an issue,

11:32 < zoq> xiaohong: gdb should be helpful here, that way you can step through the code.

11:32 < zoq> xiaohong: https://github.com/cs01/gdbgui might be interesting as well, nice to have a gui from time to time.

11:33 < xiaohong> How can I debug one test at a time?

11:33 < xiaohong> such as ./bin/mlpack_test -t PPOTEST

11:35 < zoq> xiaohong: ./bin/mlpack_test -t PPOTEST/TESTCASE or what I also do is to write an exta file with a main and link against mlpack

11:37 < xiaohong> Oh, sorry that I didn't make it clear. I mean how to use gdb when tests one test case.

11:40 < zoq> xiaohong: gdb --args executablename arg1 arg2 arg3

11:40 < zoq> xiaohong: Or write an extra executable with a single main.

11:50 < xiaohong> So we treat `mlpack_test` as executable program, and then pass the arguments, right?

11:51 < zoq> right

12:03 < xiaohong> zoq: Thanks ~ I am using this to debug now.

12:10 < zoq> xiaohong: Okay, great

12:11 < zoq> robbb08: It's not merged yet, but you can use the code from the PR.

13:25 < jeffin143> Rcurtin , zoq : I know m being stupid , but is there any way to seperate the bindings to others repo means , mlapck/cli or Mlpack/Julia , I know since it is dependent on the c++ code underhood , but isn't

13:26 < jeffin143> It possible by any means , and if yes why didn't we try

13:36 < rcurtin> jeffin143: it always made more logical sense to me to keep it together; there are lots of inter-dependencies between the mlpack codebase and the automatic binding codebase

13:36 < rcurtin> I see what you mean about splitting it all up, and maybe it could be done with submodules, but I think it would be really complex

13:37 < rcurtin> by the way I will finally merge #1876 today :) it took me forever to get mlpack-bot to approve it...

13:48 < jeffin143> The reason I was , we could keep the repo size smaller

13:50 < rcurtin> the repo size is already going to be huge pretty much no matter what we do because of all the history, unfortunately...

13:51 < rcurtin> as far as code size goes, the bindings/ directory is less than 1MB, so that shouldn't be too bad

13:52 < jeffin143> Also rcurtin , I had some doubts,. Suppose I have file with lot of includes, and I use only single function from each includes, then is it viable to

13:53 < jeffin143> Create a file with those function alone and just include one particular file Apne

13:53 < jeffin143> Alone*

13:53 < jeffin143> Would it give speed bump up..???

13:59 < rcurtin> yes, it could, but there can be maintenance issues like this---if you're including an upstream library, but you've manually written a smaller file to include with the same definitions,

13:59 < rcurtin> then if the upstream library updates or something like this, the signatures you have written in the smaller file could go out of date and this could cause problems

14:00 < rcurtin> last time I profiled it, the time the compiler spent just on parsing includes was like ~40% of the compilation time, so any speedups we can get there would definitely help

14:02 < jeffin143> Ok , if we do it before everytime we compile , so what I mean everytime before we compile , I will run a script which wile make a single file and then just include that in the code , so suppose it take 20% of time to do all that stuff , then can we handle the upstream case..?

14:03 < jeffin143> Since we are doing this all the time..???

14:03 < jeffin143> So even if the library gets updated , the function we include in the file we again get updated

14:04 < jeffin143> I am just throwing up random thoughts :) , not mean in terms of implementation , but I just wanna see what are your views

14:26 < rcurtin> sorry, stepped out for a little while

14:27 < rcurtin> you could try auto-generating the right header file, but the only problem is that it may not help *that* much, especially for templated functions, where the implementation must also be available in header files

14:27 < rcurtin> so I definitely don't want to discourage you or anything---try it and see if you can get it to work

14:27 < rcurtin> compilation time is definitely a problem, but it's really hard to fix

17:00 < Toshal> ShikharJ: I am here.

17:00 < Toshal> Anything serious.

17:07 < Toshal> zoq: ShikharJ: sakshamB: After thinking for sometime. I am thinking to implement bias visitor instead of a visitor for weights without bias. I am thinking in this way because there are more layers which have non-bias terms than which have bias terms. Let me know what you think.

20:38 < zoq> Toshal: Makes sense to me, I think it works both ways, but if you prefer the bias visitor solution let's go with that.

21:49 < sakshamB> Toshal: I am not sure if I would get the dimensions of the weights from this.