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/
rahulbshrestha has joined #mlpack
< rahulbshrestha>
Hello everyone.
< rahulbshrestha>
Is it a good idea to contact one of the mentors directly regarding a project idea?
< zoq>
rahulbshrestha: Hello, better to ask questions on public channels.
rahulbshrestha has quit [Quit: Connection closed]
< zoq>
shrit[m]: arm64 build node added (viking)
< shrit[m]>
great
< shrit[m]>
How much RAM do we have
< shrit[m]>
because now it is still fighting with emst too
< zoq>
I might need to add some packages.
< zoq>
32GB
< shrit[m]>
Great, thanks
< shrit[m]>
I will give it a try tomorrow, I would like to see if the RPI is going to survive 🍓
< zoq>
hehe, hopefully
< shrit[m]>
It still at fastmsk after 4 hours
ImQ009 has joined #mlpack
< shrit[m]>
zoq: I have started mlpack_tests on viking, let us see if this passes
< shrit[m]>
Basically it did not finish the fastmsk test on the raspberry pi
< zoq>
Yeah, and it run for 9+ hours.
< shrit[m]>
Exactly, we should consider reducing the memory footprint of the tests a little bit
< zoq>
shrit[m]: What OS did you run on the rpi?
< shrit[m]>
Ubuntu
< zoq>
20.04?
< shrit[m]>
Ubuntu 20
< shrit[m]>
Ubuntu 20.04.2
< zoq>
Ah, I see, let me install that one.
< shrit[m]>
there is an already preinstalled image on ubuntu website
< zoq>
unning the tests now
< shrit[m]>
thanks
< shrit[m]>
already at fastmsk
< jeffin143[m]>
zoq: hi , seem so you haven't visited the variant one ?
< jeffin143[m]>
Need any help
< zoq>
jeffin143[m]: I'm working on it locally, some of the converted layers are missing some pieces which I'm slowely putting together.
< jeffin143[m]>
Naah I saw the merge conflicts
< jeffin143[m]>
Scared that it would be tough if you are latezoq
< jeffin143[m]>
So I thought , we should at least solve merge conflicts
< zoq>
jeffin143[m]: Yeah, trying to solve the merge conflicts and the issues I see locally over the weekend so we have at least a functional build again.
< zoq>
Afterwards, it would be easier for others to integrate the converted layers.
< zoq>
If that makes sense.
< shrit[m]>
There are still several std::bad_alloc in the tests, which is strange.
< shrit[m]>
I do understand why this is happen if there is 32GB of available RAM
< zoq>
Good question, looks like there is also little space left on the device now.
< shrit[m]>
disk Space or RAM ?
< zoq>
disk space
< shrit[m]>
but should not affect the `std::bad_alloc` right ?
< zoq>
shrit[m]: Don't so, but let me change that anyways.
< ShubhamAbhangGit>
if we changed one file only, How can we build the specific code again, instead of whole code using `make`?
< zoq>
ShubhamAbhangGit: If you run make again it will only build changed files.
< ShubhamAbhangGit>
I am messing around with one file to understand the code base. But everytime I use make, it is building whole thing again.
< zoq>
Are you running "make install"?
< ShubhamAbhangGit>
No
< ShubhamAbhangGit>
just `make`
< ShubhamAbhangGit>
or `make -j8`
< zoq>
hm, what file are you working on, it will also rebuild everything that includes that file, so if it's core it will rebuild a bunch of files.
< zoq>
Ohh yeah, that will trigger some files; so what you could do is to disable building the tests if you don't need them?
< zoq>
with cmake -DBUILD_TESTS=OFF ..
< zoq>
Also you can just build one executable e.g. make mlpack_pca
< ShubhamAbhangGit>
can we do that in this case?
< zoq>
build only one executable?
< ShubhamAbhangGit>
> `zoq on Freenode` with cmake -DBUILD_TESTS=OFF ..
< ShubhamAbhangGit>
I earlier had python bindings on and R bindings off (` cmake -D BUILD_PYTHON_BINDINGS=ON -D BUILD_R_BINDINGS=OFF ..`), do I need mention these tags again?
< ShubhamAbhangGit>
> `zoq on Freenode` build only one executable?
< ShubhamAbhangGit>
yess
< zoq>
The bindings are disabled by default at least if you build using the latest master branch, so you have to enable the bindings you are interested in, but you don't have to disable the bindings.
< zoq>
Also, yes you should be able to build only one executable.
< ShubhamAbhangGit>
ohh got you.
< ShubhamAbhangGit>
Thank you.
< zoq>
Hope that will reduce the build time.
< ShubhamAbhangGit>
yeah disabling the tests is helping.
< AlexNguyenGitter>
@zoq I'm looking at our GSOC 2021 page, at the reinforcement learning section. In the "rainbow" paper, I see that using noisy linear layers in the network is a further upgrade, can I try this? Also, I see that our rl library has already had dueling network and categorical dqn. The only things we are missing for the rainbow are distributional value learning, noisy layer, and n-step learning, right?
< shrit[m]>
@zoq it is still stuck at fastmsk test. I wonder if it consume the 32GB memory
< zoq>
AlexNguyenGitter: You are right, if you like the idea please feel free to put something together :)
< zoq>
shrit[m]: 98% free memory, wondering if it's the same if we build native on the system.
< zoq>
shrit[m]: One core is at 100%
ImQ009 has quit [Quit: Leaving]
< shrit[m]>
Thats mean there is an issue with fastmsk
< zoq>
shrit[m]: currently building mlpack on the machine
< rcurtin[m]1>
the fastmks tests also build cover trees; maybe there is some issue with cover tree construction on arm64 or something?
< rcurtin[m]1>
seems like lots of arm64 issues lately... ensmallen test failures, mlpack test failures too... and I can't seem to reproduce any of them 😭
< zoq>
rcurtin[m]1: I'll build ensmallen on the machine afterwards as well, maybe we are lucky and I can reproduce the issue.
< shrit[m]>
it is a persisting issue, knowing that I have no clue where it is originated
< rcurtin[m]1>
hopefully all of these issues are related to the same underlying problem :)
< shrit[m]>
I was thinking of executing the main CLI program related to fastmsk and sees if we can produce the issue in the main program
< rcurtin[m]1>
yes, you could use `test_data_3_1000.csv`, for instance