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/
< rcurtin[m]1> today I learned that it's quite easy to set up a Linux container running on an android phone! :) now I have a fully working native arm64 environment
< zoq> rcurtin[m]1: hehe, that is cool, what phone are you currently using?
< rcurtin[m]1> well it has been a really bad technology week for me... so last week I was using a pixel 3, but the camera had a hardware failure, and now I have a pixel 4a 5g (both running LineageOS of course :))
< rcurtin[m]1> when I get home, I will hook up the pixel 3 permanently to Jenkins
< rcurtin[m]1> I also discovered that my chromebook is too slow to participate in large zoom meetings at my company... and that is kind of a big problem... so now I have a generic Lenovo laptop (Yogi 7i)
< zoq> hehe, sounds like you are upgrading your entire setup, new PC, new Laptop new Phone.
< zoq> Is the phone a reasonable build machine?
< zoq> How long does it take to run the ensmallen tests?
ImQ009 has joined #mlpack
zoq[m] has quit [Quit: Idle for 30+ days]
< ShubhamAbhangGit> I had a question. I have built mlpack from github code without installing it. I have exported `LD_LIBRARY_PATH` and `PYTHONPATH`. But when I quit the session and again start, i have to export them again. So do i have to export them every time I start a new session??
< ShubhamAbhangGit> (edited) ... again start, i ... => ... again start it, i ...
< rcurtin[m]1> zoq: it built the ensmallen tests pretty quickly, but I don't know how long they took to run because I failed to plug in my laptop, so when I came back this morning the results were lost 😃 now I'll try again...
< rcurtin[m]1> Shubham Abhang (Gitter): yeah, those are environment variables that need to be set in your shell session. you could, if you wanted, add them to your `.bashrc` or something like that
< ShubhamAbhangGit> and one more, how can we use mlpack in c++ program without installing it. Because mlpack header files are stored in /usr/local/include after `sudo make install`, right?
< ShubhamAbhangGit> (edited) ... make install`, right? => ... make install.
< rcurtin[m]1> depending on how you configure it at build time, yes; you can install to `/usr/include/` too (but I would not recommend that)
< rcurtin[m]1> if you want to compile a program using mlpack but without installing mlpack, add `-I/path/to/mlpack/build/include/` and `-L/path/to/mlpack/build/lib/` to the options that you pass to the compiler
mehulkc[m] has quit [Quit: Idle for 30+ days]
< jenkins-mlpack2> Project mlpack - git commit test build #655: UNSTABLE in 1 hr 2 min: http://ci.mlpack.org/job/mlpack%20-%20git%20commit%20test/655/
gtank___ has quit [Ping timeout: 258 seconds]
gtank___ has joined #mlpack
< ShubhamAbhangGit> thank you :)
zoq[m] has joined #mlpack
< rcurtin[m]1> ensmallen tests on the pixel 3:
< rcurtin[m]1> and still didn't manage to reproduce the bug I am trying to :(
< rcurtin[m]1> now let's see how long mlpack takes
< zoq> rcurtin[m]1: Not too bad, looks like this could be a nice build node :)
ImQ009 has quit [Quit: Leaving]
< rcurtin[m]1> well I think it takes like 3min on a desktop to run the ensmallen tests :)
< shrit[m]> it took like 5 hours?
< rcurtin[m]1> yeah, quite long, I am wondering if something is wrong, like maybe I have to set `OMP_NUM_THREADS` or there is some contention or something
< shrit[m]> That is strange, Pixel have very good processor though, I agree, there might be a configuration issue
< shrit[m]> it only ran one one core?
< rcurtin[m]1> not sure---I haven't dug into it at all yet
< rcurtin[m]1> it built the tests quite quickly though
< shrit[m]> RPI did not build the tests
< shrit[m]> I added 2GB of swap, I will try to rebuild the test for mlpack
< shrit[m]> is this is pass, I will build ensmallen and ran the tests
< shrit[m]> * if this is pass, I will build ensmallen and ran the tests
< shrit[m]> * I added 2GB of swap, I will try to run the test for mlpack
< rcurtin[m]1> 👍️
< shrit[m]> @zoq it did not just consume the memory, but it the tests is eating up 1.5GB of the swap
< shrit[m]> especially the AKFN one
< shrit[m]> it passes now
< zoq> shrit[m]: So it works with 1 GB RAM + 2 GB SWAP?
< shrit[m]> Yes
< rcurtin[m]1> I'm surprised, I would have expected if the tests are using swap at all that they would take forever
< zoq> shrit[m]: Okay, I'll setup the node later.
< zoq> Wondering if it also works if we just skip the akfn test?
< shrit[m]> it was the single cover tree test.
< shrit[m]> It is possible to avoid it, also it is failing
< rcurtin[m]1> if you want, feel free to open an issue for it, and we can discuss strategies for fixing the memory usage for that test if it is a problem
< shrit[m]> If we can reduce the memory, that would be great
< shrit[m]> I will open an issue for this one
< zoq> I think you can skip a test with ./mlpack_test [.testname]
< shrit[m]> Also the AKNN is using 1GB ram + 1GB swap
< shrit[m]> I think these are related to boost variant right?
< rcurtin[m]1> approximate KNN shouldn't be using boost::variant; it depends on whether that is tree-based KNN or LSH
< rcurtin[m]1> neither of those use boost::variant, but tree-based KNN can be memory intensive to build the tree (depending on the type of tree)
< shrit[m]> I see,