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/
KimSangYeon-DGU has joined #mlpack
< kartikdutt18Gitt> Hey @zoq, Sorry I hadn't added space between `-` and `template`, that's why the ci didn't trigger the build. I have got it running now. Also thanks for configuring the pipeline.
< kartikdutt18Gitt> > https://github.com/digantamisra98/Mish -> Official Package Based Implementations, they listed mlpack as well :)
< kartikdutt18Gitt>
< kartikdutt18Gitt> Yay! I think their readme is a bit too "flashy" though.
< jenkins-mlpack2> Project docker mlpack nightly build build #698: UNSTABLE in 3 hr 11 min: http://ci.mlpack.org/job/docker%20mlpack%20nightly%20build/698/
ImQ009 has joined #mlpack
KimSangYeon-DGU has quit [Remote host closed the connection]
YashwantSinghPar has joined #mlpack
< YashwantSinghPar> Hey, do we have any planning regarding cli bindings for cv or hpt?
< jeffin143[m]> Yashwant Singh Parihar (Gitter): I did had and thus I was seeking for stratified cv
< jeffin143[m]> Although not about hpt
< jeffin143[m]> I think so it would be nice addition , I was try to understand , all the constructors of cv
< jeffin143[m]> I guess hpt cli would equally be great addition
< YashwantSinghPar> Yeah without cv
< YashwantSinghPar> It seems one of the important part is missing from the binding
< jeffin143[m]> +1
< rcurtin> YashwantSinghPar: jeffin143[m]: yeah, it would be great to provide CV bindings for sure
< rcurtin> the only issue is, I don't know how we can expose all mlpack's learning algorithms like that... so the interface is difficult
< rcurtin> ideally we would want a general interface, not one where you can only specify a few hardcoded model types and parameters
< jeffin143[m]> Yes
< jeffin143[m]> rcurtin (@freenode_rcurtin:matrix.org): also why do we have custom pointer for the last k ???
< jeffin143[m]> Like there is an if condition , and we cal reset
< PranavReddyP16Gi> @rcurtin here's the link to the entire output:
< PranavReddyP16Gi> https://pastebin.com/9ps9q1PT
< YashwantSinghPar> Can we use a json file to pass the constructor, that can further parsed accordingly.
< rcurtin> YashwantSinghPar: maybe that works for the CLI bindings, sure, I don't know what to do for other languages though (maybe the answer is, we only provide the CLI binding for now)
< rcurtin> PranavReddyP16Gi: thanks. this output is unexpectedly strange; do you have the log from when you configured CMake? (or what options you used when you configured CMake?)
< rcurtin> you might try building from a completely clean build directory, too
< PranavReddyP16Gi> @rcurtin I tried a clean build three times already 😅
< PranavReddyP16Gi> Ill send you the cmake output
< PranavReddyP16Gi> Oh turns out I don't have the cmake log should I try a clean build again?
ImQ009 has quit [Quit: Leaving]
< rcurtin> yes, the log from a clean build would be useful
< PranavReddyP16Gi> @rcurtin this is the CMake build log :
< PranavReddyP16Gi> https://pastebin.com/hPj3txnN
< PranavReddyP16Gi> The exact command I ran was cmake -D DEBUG=ON -D USE_OPENMP=OFF ../
< rcurtin> if you don't need the Python bindings, I would suggest configuring with -DBUILD_PYTHON_BINDINGS=OFF
< PranavReddyP16Gi> @rcurtin I've done that. Should I try Make-ing now?
< rcurtin> yes
KimSangYeon-DGU has joined #mlpack
< PranavReddyP16Gi> @rcurtin I'm getting an error again at the ending:
< PranavReddyP16Gi> https://pastebin.com/UgG3EfrB
< PranavReddyP16Gi> I do think it's a different one from last time though
< rcurtin> > c++: fatal error: Killed signal terminated program cc1plus
< rcurtin> the compiler ran out of RAM
< PranavReddyP16Gi> Oh wow I was not expecting that to be an issue.
< PranavReddyP16Gi> Any @rcurtin thank you so much for the help :)
< rcurtin> sure, probably you can fix it by building with fewer cores (if you did, e.g.,, `make -jX` for some X, try X=1)