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/
< nishantkr18[m]> Hey everyone! I use `cmake -D DEBUG=ON -D PROFILE=ON ../ && make -j4 mlpack_test ` for tests. and yet I'm not able to see the outputs for `Log::Debug`. Am I missing something?
ImQ009 has joined #mlpack
The_LoudSpeaker has quit [Quit: Leaving bye!]
The_LoudSpeaker has joined #mlpack
< KimSangYeon-DGU[> nishantkr18: Hi, mlpack_test program is in `build/bin` directory
< KimSangYeon-DGU[> Ahh, it seems you successfully run the tests, but you can't see the outputs
petris has quit [Quit: No Ping reply in 180 seconds.]
petris has joined #mlpack
< say4n[m]> "nishantkr18" (https://matrix.to/#/@nishantkr18:matrix.org) "-DDEBUG=ON" builds the binary with debug symbols that are used for debugging with a debugger like gdb, lldb etc.
< say4n[m]> Ah wait I got your question wrong, my bad!
< nishantkr18[m]> <KimSangYeon-DGU[ "Ahh, it seems you successfully r"> That is correct
< say4n[m]> So you need to pass the "-g" to the compiler and then also use the "--verbose" flag while executing the "mlpack_test" binary.
< say4n[m]> Pass the "-g" flag via cmake.
< nishantkr18[m]> <say4n[m] "Pass the "-g" flag via cmake."> Alright let me try that
< say4n[m]> Specifically: ```-DCMAKE_CXX_FLAGS="-g" -DCMAKE_C_FLAGS="-g"```
< say4n[m]> And then call the binary with `./mlpack_test ---verbose`
< nishantkr18[m]> I'm tried running `cmake -DCMAKE_CXX_FLAGS="-g" -DCMAKE_C_FLAGS="-g" -DDEBUG=ON -D PROFILE=ON ../ && make -j4 mlpack_test`.
< nishantkr18[m]> And I run the tests using ` bin/mlpack_test -t QLearningTest --log_level=all` because --verbose isn't a recognized argument it seems
< nishantkr18[m]> But still, I see no debug messages..
< nishantkr18[m]> This is weird because I have used `-DDEBUG` before, and it used to work.
< zoq> nishantkr18[m]: set mlpack::Log::Debug.ignoreInput = false; to enable debug messages
< zoq> nishantkr18[m]: Or build with -DTEST_VERBOSE=ON
< nishantkr18[m]> <zoq "nishantkr18: Or build with -DTES"> This worked, thanks :)
say4n[m] is now known as say4n
< say4n> test (ignore this message) :)
< zoq> say4n: Okay :)
< jonpsy[m]> hey guys, sorry to interrupt ya'll but has anyone been ab;e to use tensorflow c++ API?
pie3 has joined #mlpack
favre49 has joined #mlpack
Abhayram_A_Nair has joined #mlpack
Abhayram_A_Nair has quit [Ping timeout: 245 seconds]
< say4n> zoq: Marcus any idea as to why the AppVeyor build is stuck at Queued for ensmallen#149?
< zoq> say4n: I think mlpack/mlpack and mlpack/ensmallen share the same number of parallel builds, so this can take some time :(
< say4n> Ah, gotcha!
< say4n> :)
< zoq> say4n: Also, looks like the memory job is running forever, I'll take a look into the issue, it's not related with the changes you did, so I will run the memory job on the NSGA2 suite first, so that we don't have to wait for a green memory job.
< say4n> Sure!
< say4n> Will I undo the last commit?
< zoq> Let's see if the memory job finishes before the 6 hour timeout.
favre49 has quit [Remote host closed the connection]
< himanshu_pathak[> zoq: It is pretty much similar to my situation I tried to look at but didn't find anything suspicious say4n When I compiled the my code with clang9++ and after that used valgrind you can try same it might be helpful.
< himanshu_pathak[> * zoq: It is pretty much similar to my situation I tried to look at but didn't find anything suspicious say4n I compiled the my code with clang9++ and after that used valgrind you can try same it might be helpful.
< himanshu_pathak[> * zoq: It is pretty much similar to my situation I tried to look at the code but didn't find anything suspicious say4n I compiled the my code with clang9++ and after that used valgrind you can try same it might be helpful.
< himanshu_pathak[> * zoq: It is pretty much similar to my situation I tried to look at the code but didn't find anything suspicious say4n I compiled my code with clang9++ and after that used valgrind you can try same it might be helpful.
< say4n> himanshu_pathak: yeah, locally my build passes and valgrind finds no errors. :)
< himanshu_pathak[> say4n: Yup I was also stuck in the same situation.
ImQ009 has quit [Quit: Leaving]
pie3 has quit [Quit: Leaving]
kuhaku has joined #mlpack
< say4n> zoq: yaay AppVeyor passed! :)
< say4n> Marcus, about valgrind, I think memcheck needs a return code of 0 to successfully terminate the test. What I think is happening is here is that since the exit code on failure in non zero for Catch, valgrind thinks that the program is still running. Also, another puzzling thing is that stdout from the executable being checked is flushed to stdout online when the abort is called due to the timeout.
< say4n> zoq: ^
< jeffin143[m]> say4n: may be you are right
< jeffin143[m]> Let's give a commit and see
< zoq> say4n: Not sure about the exit code, catch2 does return the number of failed tests as return code, but not sure if that's a problem.
< zoq> say4n: Currently running the complete suite, with -a so that it will abort right away once a test failed.
< zoq> say4n: I guess, it just takes a lot of time to run the complete suite.
< zoq> say4n: I did run valgrind on the NSGA suite and all looks good.
< say4n> «say4n: Not sure about the exit code, catch2 does return the number of failed tests as return code, but not sure if that's a problem.»
< say4n> I came across this on a stray SO answer, let me see if I can find anything more on it.
< say4n> «say4n: I did run valgrind on the NSGA suite and all looks good.»
< say4n> Alright! :)
< say4n> «say4n: Currently running the complete suite, with -a so that it will abort right away once a test failed.»
< say4n> Ah, let's see what comes up. Should be some fun debugging session. :))
< zoq> For mlpack we don't run valgrind on the complete test suite, only on tests that are related to the code changes, and I can see that already takes like 3 hours.
< zoq> also using -s to see which tests already passed
< say4n> Whoa! Valgrind's virtualisation is super slow!!
< say4n> «For mlpack we don't run valgrind on the complete test suite, only on tests that are related to the code changes, and I can see that already takes like 3 hours.»
< say4n> Interesting, how do you find out which tests are relevant for a PR?
< zoq> It's a super simple strategy, we check if the file that was changed is included by one of the tests, that will not catch every scenario but yeah I guess it's good enough.
< say4n> Ah that's pretty neat!
< say4n> > that will not catch every scenario
< say4n> Yeah, the alternative would be manually marking what has changed, which is both tedious and error prone!
< say4n> ^ I guess. :)
< zoq> Yeah, pretty sure there is some tool out there that can create some sort of a file dependency graph.
< say4n> Ah! Doing it with only static analysis would be hard, I guess...
< zoq> Right, we run the static analysis job over the entire codebase.
< say4n> That's nifty! :))
< jeffin143[m]> @walragatver:matrix.org: @brim thanks for the review on gsoc evaluation
< jeffin143[m]> I will make sure that I improve more on the styling issues
< jeffin143[m]> It's a habit I generated largely becouse of competitive programming where I am really after speed and just forgot about the neatness
say4n has quit [Quit: authenticating]
say4n has joined #mlpack