06:41 < pvskand> While running mlpack_knn --help I am getting the following error: mlpack_knn: symbol lookup error: /usr/local/lib/libmlpack.so.2: undefined symbol: arma_H5T_NATIVE_LLONG

06:41 < pvskand> Is this a problem in armadillo?

11:50 < rajiv_> Hello, I subscribed to the mlpack mailing list and recieved a mail "Welcome to MLPack(Digest Mode). But, when I tried mailing mlpack@lists.mlpack.org, I recieved a mail "Only list members can post to the list.". But, my email exists in the list. What should I do?

12:18 < zoq> rajiv_: Hello, that's strange did you use the same mail as you subscribed?

12:28 < rcurtin> pvskand: that's an interesting one; did you happen to update (or remove) libhdf5 from your system in the time since you have built armadillo?

12:29 < rcurtin> those symbols are for the armadillo hdf5 wrapper, so I suspect either armadillo has been upgraded/replaced with a version that doesn't have HDF5 support enabled, or possibly the underlying hdf5 library and also the armadillo library have changed, or something...

12:30 < rcurtin> in any case a reconfigure/rebuild of mlpack is likely to fix it, but I am happy to help dig and figure out exactly what it was that happened

12:30 < pvskand> <rcurtin> : Let me check and get back to you.

12:32 < rcurtin> sure, no hurry, let me know what you find

12:47 < zoq> rcurtin: seconds :)

12:58 < pvskand> <rcurtin> : which version of armadillo do you have?

13:00 < rcurtin> zoq: ha, I guess we were both thinking about it at the same time :)

13:01 < rcurtin> pvskand: not sure, it depends definitely on which system I am using that day :)

13:01 < rcurtin> typically I'll just install libarmadillo-dev from apt, but other times I want to test with a specific version so I'll build it in a specific directory then configure mlpack with -DARMADILLO_INCLUDE_DIR and -DARMADILLO_LIBRARY set to the location of the custom Armadillo

13:31 < rajiv_> Hi Marcus, as I recieved a welcome message, my email id has to be right

13:37 < zoq> rajiv_: Okay, I can't look into the settings, perhaps rcurtin could.

13:43 < rajiv_> Ohk... Thanks! It would be great if this issue is resolved. BTW, can I ask you about GSoC here?

13:43 < rcurtin> let me take a look in a minute, hang on

13:47 < rcurtin> rajiv_: I responded to your email, I hope it helps

13:51 < rcurtin> ok, I have more details on when masterblaster and all of the build systems will be moved; the schedule is currently that they will ship out the systems on 2/9 (next friday)

13:52 < rcurtin> the systems should be received in Tucson by the following Monday (2/12) and the team there is supposed to install them with high priority

13:53 < zoq> okay, so minimal downtime

13:53 < zoq> sounds good

14:06 < rcurtin> yeah, hopefully they are actually to get it back online fast

14:07 < rcurtin> next week I will do a "reboot test" to make sure the systems come up cleanly

14:07 < rcurtin> $ uptime

14:07 < rcurtin> 06:07:17 up 162 days, 13:49, 2 users, load average: 0.00, 0.00, 0.00

14:07 < rcurtin> I guess I have a bad habit of letting systems go a long time without a reboot

14:07 < zoq> same here

14:13 < rcurtin> luckily with all the benchmarking systems I have iLO and iDRAC access so if they don't boot back up I have a console I can access

14:16 < zoq> Does iDRAC come as an extra card? Maybe they provide this as a standard on the board itself.

14:20 < rcurtin> I think it's on the board itself, but I'm not sure---iDRAC is the dell version, and I have actually never seen or touched the 5 dell servers (slake, savannah, scrooloos, gekko, skyfish)

14:21 < rcurtin> for the Sun systems (aunty, collector, ironbar) it's built into the motherboard (but Sun calls it something else, I think ILOM?); it's just an extra NIC you can put on the network

14:21 < rcurtin> so the way Symantec has these systems configured currently is that the 9 management ports (iLO/iDRAC/ILOM) are on the internal network and can only be accessed through the Symantec VPN

14:21 < rcurtin> which is fine, I can only imagine that there are tons of security flaws in the management software and putting them on the open internet would be a disaster...

14:22 < zoq> yeah, sounds absolutely reasonable

14:32 < pvskand> <rcurtin>: I recompiled armadillo and mlpack and mlpack_knn -h has worked but bin/mlpack_test -t KNNTest isn't working

14:33 < pvskand> It says mlpack_test: command not found. This is strange!

14:39 < rcurtin> pvskand: did you just do 'make'?

14:39 < rcurtin> you have to specify to build the test (since it takes so long): 'make mlpack_test' (or 'make test' which builds then runs the test)

14:39 < rcurtin> if you have multiple cores definitely use 'make -jX' where X is the number of cores, that will speed things up

15:58 < rcurtin> pvskand: I left a few messages, you should check the logs if you haven't already :)

15:58 < pvskand> <rcurtin> : Yes I have checked them. I will let you know. :)

16:14 < pvskand> Yup working now :)

16:33 < ImQ009> Hmm, mlpack really doesn't like to be included along with Windows SDK

16:33 < ImQ009> I get flooded with macro redefinitions such as M_PI

16:42 < rcurtin> pvskand: great to hear

16:43 < rcurtin> ImQ009: the only thing I can think that would cause that issue is if including the following code after including the Windows SDK also causes the issue:

16:43 < rcurtin> #define _USE_MATH_DEFINES

16:43 < rcurtin> #include <cmath>

16:44 < ImQ009> Defining "_MATH_DEFINES_DEFINED" helps

16:45 < ImQ009> But still gotta use a pragma to suppress 'possible loss of data' warnings :P

16:46 < ImQ009> rcurtin, I have Windows SDK, Qt and mlpack. All of each I think are defining those macros. So yeah, kind of a pain

16:50 < rcurtin> ImQ009: the cmath behavior seems reasonable to me: http://www.cplusplus.com/forum/general/102410/

16:50 < rcurtin> so I am surprised that Windows (presumably) is defining M_PI and not _MATH_DEFINES_DEFINED

16:50 < rcurtin> if you like, we can patch prereqs.hpp to only define _USE_MATH_DEFINES when M_PI is not defined

16:50 < rcurtin> and that would fix the issue

16:51 < rcurtin> the 'possible loss of data' warnings are tricky; if I remember right these are all arma::uword -> size_t conversions, but arma::uword and size_t should actually be the same thing (unsigned 64 bit integer)

16:51 < rcurtin> so the warning is actually misleading I think

16:51 < ImQ009> Yeah, I've read the issue about it on github

16:51 < ImQ009> It is tricky indeed

16:51 < rcurtin> (assuming a reasonably recent version of Armadillo, which uses 64-bit indices by default)

18:51 < ImQ009> Hmm

18:51 < ImQ009> I'm having trouble extracting the last row (dimension) of a loaded dataset. I just get "requested size is not compatible with column vector layout"

18:52 < ImQ009> What I'm doing is: "arma::mat dataset; mlpack::data::Load("path.csv", dataset); arma::vec labels = dataset.row(dataset.n_rows - 1);'

18:53 < ImQ009> If I understand correcly the last dimension (in my case, labels) should be in the last row of the matrix

18:55 < ImQ009> I can transpose it and then get the columns

18:55 < ImQ009> Sorry if this is a simple question, I'm not familiar with this. :/

19:00 < ImQ009> Yeah, this is actually an Armadillo question. I'll find a better place to ask such questions, sorry

19:06 < ImQ009> I suppose it's because the returned row view is not contiguous in memory, so I can't make it to a vector. So I HAVE to transpose

19:45 < rcurtin> ImQ009: yeah, exactly

19:45 < rcurtin> Armadillo is column-major, so the points for a particular column are contiguous in memory

19:45 < rcurtin> however, you can do this:

19:45 < rcurtin> arma::rowvec labels = dataset.row(dataset.n_rows - 1);

19:46 < rcurtin> that will do an actual extraction of the row values from the non-contiguous 'dataset' matrix, but no transpose is needed

20:00 < ImQ009> rcurtin, oh, I see. I initially though it didn't work either at first, because I had tried it before and I was still getting the exception. But it turns out it was, because I was trying to do vec = rowvec

20:01 < ImQ009> Eitherway, thanks for assistance.

20:10 < rcurtin> sure, glad to help :)

23:25 < travis-ci> mlpack/mlpack#3813 (master - a16363a : Marcus Edel): The build has errored.

23:25 < travis-ci> Change view : https://github.com/mlpack/mlpack/compare/119c410c56a1...a16363a9c9cf

23:25 < travis-ci> Build details : https://travis-ci.org/mlpack/mlpack/builds/336308192