06:45 < jenkins-mlpack2> Project docker ensmallen nightly build build #23: ABORTED in 2 hr 30 min: http://ci.mlpack.org/job/docker%20ensmallen%20nightly%20build/23/

07:13 < jenkins-mlpack2> Yippee, build fixed!

07:13 < jenkins-mlpack2> Project docker mlpack nightly build build #464: FIXED in 2 hr 59 min: http://ci.mlpack.org/job/docker%20mlpack%20nightly%20build/464/

12:43 < ssk99> Guys, I'm unable to compile the code from source. CMAKE is throwing huge numbers of warnings and errors. First I assumed it was because of the changes in my working repo, but even the official 3.1.1 library isn't compiling.

12:44 < ssk99> These are the warnings and errors I saw in the output while compiling:

12:44 < ssk99> warning: unused but set parameterwarning: unused functionerror: ‘class ens::VanillaUpdate’ has no member named ‘Initialize’ updater.Initialize(learningNetwork.Parameters().n_rowserror: ‘class ens::VanillaUpdate’ has no member named ‘Update’ updater.Update warning: #warning "Using deprecated NumPy API, disable it with "

12:44 < ssk99> "#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp](learningNetwork.Parameters().n_rowswarning: this statement may fall through [-Wimplicit-fallthrough=]warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++

12:45 < ssk99> Sorry about that they came in one line

12:45 < ssk99> warning: unused but set parameter

12:45 < ssk99> warning: unused function

12:45 < ssk99> error: ‘class ens::VanillaUpdate’ has no member named ‘Initialize’ updater.Initialize(learningNetwork.Parameters().n_rows

12:45 < ssk99> error: ‘class ens::VanillaUpdate’ has no member named ‘Update’ updater.Update

12:45 < ssk99> warning: #warning "Using deprecated NumPy API, disable it with " "#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp](learningNetwork.Parameters().n_rows

12:45 < ssk99> warning: this statement may fall through [-Wimplicit-fallthrough=]

12:45 < ssk99> warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++

12:48 < rcurtin> ssk99: right, so I believe I know what's happened here... there was an ensmallen version update that changed some lower-level APIs that parts of mlpack use

12:49 < rcurtin> ensmallen is downloaded automatically during the build process into build/deps/

12:49 < rcurtin> so, you can try removing build/deps/ and see if CMake automatically downloads the new version

12:49 < rcurtin> or, you can just remove the build directory entirely and reconfigure/rebuild

12:49 < rcurtin> (with the git master branch that is)

12:51 < ssk99> rcurtin: is the new ensmallen version 2.10.2? Because cmake did download that library when i ran the cmake ../

12:52 < rcurtin> ssk99: yes, but do that with the git master branch

12:52 < ssk99> Alright, will do. Thanks :)

12:53 < rcurtin> let me know if there is any issue---I think what I suggested should work :)

12:54 < ssk99> Even if what you suggested works, doesn't it mean that the file at https://www.mlpack.org/files/mlpack-3.1.1.tar.gz won't work anymore?

12:54 < rcurtin> ssk99: I think you are right, because it downloads too new of a version of ensmallen

12:54 < rcurtin> but, we'll do a new release shortly and I can fix that by hardcoding the version of ensmallen it downloads

12:55 < ssk99> Ah I see, thanks for the clarification

13:00 < rcurtin> but you're right, when we released mlpack-3.1.1 we didn't realize what breaking changes in ensmallen would do

13:00 < rcurtin> and by we, well, I mean "I", because I wrote that code :)

13:19 < ssk99> rcurtin: Reporting back, so now the library compiles. There are still warnings for deprecated numpy, unused but set parameters and implicit fallthrough but I'm sure you were aware of those already.

13:20 < ssk99> Leaving that aside, when running make all, build_pyx_knn failed. But after completion running make build_pyx_knn was successful. What do you make of that?

13:21 < ssk99> And also, HMMTest/DiscreteHMMGenerateTest and MatrixCompletionTest/UniformMatrixCompletionSDP fail

13:23 < rcurtin> ssk99: we can't fix the deprecated numpy warnings, those are part of Cython

13:24 < rcurtin> if there are any warnings you see that we can fix in our code, you're welcome to open a PR---sometimes different warnings happen with different compilers, so you may be seeing warnings that others aren't

13:24 < rcurtin> I don't have enough details to understand the failure with build_pyx_knn (I'd need to see what the build failure actually was)

13:24 < rcurtin> same with the tests

13:26 < ssk99> rcurtin: should i open an issue for these failures? or is there a better way?

13:28 < rcurtin> ssk99: you can do that, that would be just fine :)

13:29 < rcurtin> we can try and debug it over IRC too---up to you

13:30 < ssk99> IRC sounds good :)

13:31 < ssk99> x86_64-linux-gnu-gcc: internal compiler error: Killed (program cc1plus)Please submit a full bug report,with preprocessed source if appropriate.See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions.error: command 'x86_64-linux-gnu-gcc' failed with exit status 4src/mlpack/methods/neighbor_search/CMakeFiles/build_pyx_knn.dir/build.make:57:

13:31 < ssk99> recipe for target 'src/mlpack/methods/neighbor_search/CMakeFiles/build_pyx_knn' failedmake[2]: *** [src/mlpack/methods/neighbor_search/CMakeFiles/build_pyx_knn] Error 1CMakeFiles/Makefile2:5631: recipe for target 'src/mlpack/methods/neighbor_search/CMakeFiles/build_pyx_knn.dir/all' failedmake[1]: ***

13:31 < ssk99> [src/mlpack/methods/neighbor_search/CMakeFiles/build_pyx_knn.dir/all] Error 2

13:31 < rcurtin> " internal compiler error: Killed"

13:31 < rcurtin> ah you ran out of available RAM :)

13:31 < rcurtin> my guess is your system started swapping and got really, really slow too?

13:31 < rcurtin> I'd suggest building with fewer cores

13:31 < ssk99> How do I insert a newline in IRC '=D

13:32 < rcurtin> hehe, I think a newline is a new message

13:32 < ssk99> So there's no way to dump a multiline comment?

13:32 < rcurtin> well, IRC has length limits on messages too, so it's no problem to send a bunch of messages

13:33 < ssk99> It didn't get really really slow though

13:33 < rcurtin> oh, ok, maybe there is no swap on your system or something :)

13:33 < rcurtin> usually when that happens though, the system will become unusable for a little while as the kernel swaps things in and out of RAM to try and make enough memory

13:33 < ssk99> But shouldn't the make command have failed if the system ran out of RAM?

13:33 < rcurtin> it's ok either way; the fix is just to use fewer cores to compile

13:33 < rcurtin> did you run with 'make -jX'?

13:33 < rcurtin> for some X

13:33 < ssk99> Yep -j12

13:34 < rcurtin> do you have 12 cores on your system?

13:34 < ssk99> Yeah. I ran $nproc and got 12

13:34 < rcurtin> ah, ok

13:34 < ssk99> I read that $nproc was the lower limit and you could go on increasing

13:34 < rcurtin> I wouldn't usually recommend it, usually in my experience just using the number of cores is the right call

13:35 < rcurtin> however, that means you are running 12 steps of the compilation in parallel at once

13:35 < rcurtin> and this is why it runs out of memory :)

13:35 < rcurtin> so I'd suggest trying with a smaller number of cores, and that should fix the memory problem

13:35 < rcurtin> (it may also take slightly longer)

13:35 < ssk99> In any case, why would only that one test fail?

13:35 < rcurtin> "build_pyx_knn" isn't a test, that's a compilation step

13:36 < rcurtin> basically imagine that 12 different processes are trying to compile different files at the same time

13:36 < rcurtin> during this compilation process, they will request for memory to be allocated, and sooner or later there isn't enough memory left

13:36 < rcurtin> so in this case build_pyx_knn is the unlucky one; it can't get any memory and it crashes. if you ran again, it might be a different one that fails

13:36 < ssk99> Oh I stand corrected, another make target failed just now

13:41 < ssk99> I ran with 6 cores this time and it worked out fine. :)

13:41 < rcurtin> awesome, glad it worked :)

13:43 < ssk99> bin/mlpack_test gives 2 failures however

13:43 < ssk99> fatal error: in "HMMTest/DiscreteHMMGenerateTest": critical check arma::norm(hmm.Transition() - hmm2.Transition()) < 0.01 has failed [0.010771949796276921 >= 0.01]

13:43 < ssk99> fatal error: in "MatrixCompletionTest/UniformMatrixCompletionSDP": memory access violation at address: 0x0000001c: no mapping at fault address

13:44 < rcurtin> the HMM test failure is just unlucky; the matrix completion test is a bit more concerning though

13:44 < rcurtin> I'll widen the tolerance for DiscreteHMMGenerateTest in a little bit

13:44 < rcurtin> many of the mlpack tests are necessarily probabilistic---we want to test if the model works, so we choose a tolerance on some random data

13:44 < rcurtin> but that means sometimes it can fail... so we have to work hard to keep the failure probability down

13:45 < ssk99> These 2 failed the last few times too

13:45 < rcurtin> once it's compiled, the random seed is set, so that HMM test will fail as many times as you run it

13:45 < rcurtin> (that's for reproducibility)

13:45 < ssk99> So it might not fail for other random seeds?

13:46 < rcurtin> exactly

13:46 < rcurtin> for the MatrixCompletionTest failure, you're welcome to open an issue for it or try and dig in with gdb and valgrind to figure out where the invalid memory access is if you want a challenge :)

13:47 < ssk99> One PR at a time :D I'm working on getting the move and copy operators for the other trees working

13:47 < rcurtin> :)

13:50 < rcurtin> I'm about to open a PR to fix another test; I'll add the DiscreteHMM test tolerance fix into that also

13:51 < ssk99> Sounds good

17:26 < abernauer> rcurtin: The R consortium is accepting proposals for project grants through October 14th. I am going to write up a proposal.

17:28 < abernauer> They typically accept proposals with broad appeal, but domain specific projects have been accepted in the past.

17:28 < rcurtin> abernauer: sounds good, have you talked with Dirk or James about it?

17:30 < abernauer> No I haven't. Though I will reach out with an email discussing it.

17:39 < rcurtin> yeah, that would probably be helpful

17:41 < abernauer> ok sounds good.

20:35 < KimSangYeon-DGU> Hmm, my local passed NBCTest, I'll test it with about 3,000 seeds randomly generated.

20:39 < KimSangYeon-DGU> Oops, it's my fault. I'll fix it

20:46 < zoq> KimSangYeon-DGU: That's fast.

21:14 < rcurtin> KimSangYeon-DGU: make sure to do `sleep 1` between runs, otherwise if you use math::RandomSeed(std::time(NULL)), std::time(NULL) only changes once per second, so you might run with the same seed many times