ChanServ changed the topic of #mlpack to: "mlpack: a fast, flexible machine learning library :: We don't always respond instantly, but we will respond; please be patient :: Logs at http://www.mlpack.org/irc/
travis-ci has joined #mlpack
< travis-ci> mlpack/mlpack#8132 (master - 31f693b : Ryan Curtin): The build passed.
travis-ci has left #mlpack []
aghinsa has joined #mlpack
aghinsa has quit [Client Quit]
rcurtin has joined #mlpack
inopassword has joined #mlpack
inopassword has left #mlpack []
khizirsiddiqui has joined #mlpack
< khizirsiddiqui> rcurtin: Sorry for the late reply, without adding dir to `LD_LIBRARY_PATH` and directly running `./mlpack_adaboost --help` from bin directory gives the similar error:
< khizirsiddiqui> `./mlpack_adaboost: symbol lookup error: ./mlpack_adaboost: undefined symbol: _ZN6mlpack8adaboost13AdaBoostModel12PredictProbaERKN4arma3MatIdEERNS2_3RowImEERS4_`
khizirsiddiqui has quit [Ping timeout: 260 seconds]
funkypopsicle[m] has quit [Ping timeout: 248 seconds]
funkypopsicle[m] has joined #mlpack
Sergobot has quit [Ping timeout: 240 seconds]
Sergobot has joined #mlpack
< rcurtin> khizirsiddiqui: trhat's particularly strange and I wouldn't expect that. but, anyway, if you've found a way to work around it, maybe it isn't worth worrying about :)
abernauer has joined #mlpack
< abernauer> rcurtin: Have you encountered core dumps caused by armadillo while working on the python or julia bindings?
< rcurtin> abernauer: yes, usually this was a result of trying to access invalid memory, or more likely when both C++ *and* the other language were trying to free the allocated armadillo memory
< rcurtin> for R, I wouldn't expect that to happen, as I imagine one could just use RcppArmadillo for all the wrangling of matrices back and forth from R
< abernauer> Yeah with the latter approach mentioned there was a lot of template meta-programming to deal with, so I pivoted to using C wrappers. Also the C wrapper approach was more consistent with the mlpack code base.
< rcurtin> I'd strongly suggest using Rcpp and RcppArmadillo, as those are completely stable and well-known codebases already, so I feel that we would be less likely to run into bugs once we got it working that way
< abernauer> Ok back to that approach.
< rcurtin> yeah, sorry if it makes it a little harder with the template metaprogramming, but I do think it's the better way
< rcurtin> I'm happy to try and help debug where I'm able, plus Dirk should be able to provide some input if you're using Rcpp and RcppArmadillo directly
< rcurtin> you might want to try, outside of the mlpack context, just something simple first, like taking a matrix in R, passing it to C++, adding 1 to all the elements, then passing it back to R and making sure that the elements are indeed different
< rcurtin> then, maybe you could make this a little more complex, and take the R matrix, pass it to C++, then create a *new* matrix in C++ that has all the elements doubled (or something), and pass it back to R and confirm that the right matrix is received back
< rcurtin> those are basically the underlying necessities for the mlpack bindings
< abernauer> Sounds fine.
abernauer has quit [Remote host closed the connection]
< akhandait[m]> Does this build error seem familiar to anyone? I am using latest ensmallen and mlpack.
< rcurtin> akhandait[m]: hmm, strange, looks like an issue with the version of STB on your system
< rcurtin> but you can just work around it by disabling the STB support in CMake:
< rcurtin> cmake -DDOWNLOAD_STB_IMAGE=OFF ../ (then you'll probably have to remove your build directory and reconfigure)
< rcurtin> is there a copy of stb_image.h and/or stb_image_write.h somewhere on your system? like in /usr/include or /usr/local/include?
< akhandait[m]> rcurtin: Thanks :)
< akhandait[m]> Disabling the STB support seems to have worked, it's building without any errors now.
< akhandait[m]> I guess till I figure out what's wrong with it, this will suffice.
< akhandait[m]> I searched for those files, the only copies are in mlpack/build/deps/stb/, none in /usr/
< zoq> akhandait[m]: What compiler do you use?
< akhandait[m]> zoq: GCC 5.4.0
< zoq> Okay, thanks, let's see if I can replicate the issue on a docker.
< akhandait[m]> Thanks for taking the efforts :). Do you have all the config settings or do you need anything else?
< zoq> Probably enough, will ping you if I need anything else, I can extract the armadillo version from the log.
< zoq> Os might be interesting.