01:12 < rcurtin> abernauer: typically when I've had any problems like that, the issue has been simply that I've been accessing the wrong memory location, or that I'm trying to access memory that was already freed

01:12 < rcurtin> (i.e., I got the address of some Python memory and tried to use it from C++, but the Python garbage collector had already cleaned it up; or, vice versa)

01:13 < rcurtin> are you sure that you need to be doing anything with overloaded functions? for the other languages, for the sake of simplicity, I just wrap all the CLI functionality as standalone non-overloaded functions with different names

04:27 < abernauer> rcurtin: I will follow up with a more detailed description of the problem in the morning. Going to sleep on the problem.

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

11:37 < xiaohong> Hi, I accidentally find that I write the normal distribution is similar with the DiagonalGaussianDistribution. Can anyone explain the parameter of covariance ?

12:38 < rcurtin> xiaohong: with the DiagonalGaussianDistribution, the covariance is just a diagonal matrix, so we represent it as an arma::vec... if I remember right :)

12:39 < xiaohong> So we compact the covariance matrix as vector ?

12:39 < rcurtin> right, all non-diagonal entries are 0

16:17 < abernauer> rcurtin: So, to actually allow compiled code to be callable in R you need to register the symbol names in the .so in a C array, i.e., register the entry points in C cause R is conceptually a C program.

16:27 < abernauer> For each function interface this requires you to pass 3 arguments to each C array entry: one a character string for the function name in R, two a C name or C++ which is an address of the code, three the number of arguments the code or function expects.

16:28 < rcurtin> abernauer: ah, right. so in this case probably naming all functions differently is useful so that there is no chance of getting the wrong overload :)

16:28 < rcurtin> also, by the way, I am fighting with the Julia bindings today, and I think you are using Rcpp so you shouldn't have to worry about this, but if you are passing back and forth a very small matrix,

16:29 < rcurtin> Armadillo will use locally preallocated memory, meaning that if you pass it back to R (or Julia in my case), its ownership can't be transferred to the other language (if that makes sense)

16:29 < rcurtin> if what I'm saying doesn't make sense or you aren't worrying about Armadillo pointers directly, then it's probably not relevant. I am sure Rcpp has to consider this case

16:33 < abernauer> Ok . Yeah I looked at the Julia Bindings a bit and there seems to be more overlap between R and Julia vs Python. The ccall interface in Julia is similar to the .Call() foreign function I am using in R which is built in the language. .

16:37 < rcurtin> awesome, hope the code was helpful then :)

16:37 < rcurtin> I have to get some lunch---back later

18:26 < abernauer> rcurtin: I wasn't using Rcpp. Rcpp will generate those interfaces, for you. The casting to type (DL_FUNC) for the C++ function name failed.

18:56 < rcurtin> abernauer: I see. maybe it is useful to use Rcpp or RcppArmadillo here, but honestly I have no idea---Dirk or James would have a better idea. I have not ever used either (and I am basically clueless with R)

19:04 < abernauer> Yeah will revisit that approach. The only potential added complexity, I would anticipate is dealing with tricky template programming. Rcpp uses template metaprogramming to transfer objects between R and C++.

19:06 < mayank_agarwal> Hey! I am Mayank and I would love to start contributing. What do you think is the best approach to start? From a quick scan , I think I should look into CMake but it might take time xD

19:08 < abernauer> mayank_agarwal: The community page on the mlpack site has good guidelines. Building mlpack from source is a good first step.

19:10 < zoq> mayank_agarwal: Personally, I would start with the tutorials, and maybe see if there is some interesting issue on GitHub, if not perhaps there is a method that could be improved. CMake is an interesting topic, but not necessarily relevant for further contributions.

19:11 < mayank_agarwal> Alright. Thanks for the advise. Will get to it!

19:21 < rcurtin> abernauer: actually we should be able to avoid all template metaprogramming altogether---if you just wrap each CLI function in its own standalone C function, then there is never any need to consider templated functions, since all we are doing is calling mlpackMain() for each mlpack method

20:29 < abernauer> Yeah that sounds right. Already encountering some issues with scope though and input parameters with Rcpp. Typically need to be in the global namespace to meld with Rcpp.

23:57 < Yashwants19> Hi rcurtin: If you have some time please review PR of bindings for linear SVM and go- bindings.

23:57 < Yashwants19> Thank You