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/
< kartikdutt18Gitt> Hey zoq, at least a work-around solution is using for loops to train instead of terminating based on callbacks. However I still get `nans` in the MSE of predictions.
< jenkins-mlpack2> Yippee, build fixed!
< jenkins-mlpack2> Project docker mlpack nightly build build #662: FIXED in 3 hr 15 min: http://ci.mlpack.org/job/docker%20mlpack%20nightly%20build/662/
ImQ009 has joined #mlpack
favre49 has joined #mlpack
< favre49> zoq: I see you have a nes-scripts repo. Is that usable? Or is it worth trying to implement tiles support in the Kautenja gym implementation?
< favre49> I've looked into other implementations and tests, but there isn't anything too promising. The most complicated one I can see is a predator-prey model from SharpNEAT
favre49 has quit [Remote host closed the connection]
toluschr has joined #mlpack
toluschr has left #mlpack []
< zoq> favre49: We could use the nes-scripts, but I thought this we already have the gym interface it might be cool to do it with gym. Let me know what you think.
< zoq> kartikdutt18Gitt: Yes, will have to take a closer look at the issue, seems RNN related only.
< kartikdutt18Gitt> Hmm, Just looked at the notebooks you pushed. They look great, also namespaces are working. Do you mind if I try your mnist example with ensmallen callbacks for training?
< zoq> kartikdutt18Gitt: Will test it later.
< kartikdutt18Gitt> Ohk great.
< zoq> kartikdutt18Gitt: Ahh, if you liek to test it out, please feel free, you can use the lab.mlpack.org instance.
< kartikdutt18Gitt> Will do, Will test them and get back to you. Thanks a lot.
< zoq> kartikdutt18Gitt: Thanks!
< PrinceGuptaGitte> I did `cmake ../` again, but it still gave this error
< zoq> PrinceGuptaGitte: Maybe start with a clean build, e.g. remove the build folder?
< PrinceGuptaGitte> ok, I'll try that. Thanks
< PrinceGuptaGitte> That worked, thanks. I'll try this next time I'll get something like this.
< zoq> PrinceGuptaGitte: Btw. most of the time I just to make, without make install, prevents to rebuild the complete codebase once I changed something.
< PrinceGuptaGitte> Thanks I'll keep that in mind.
lupulo has joined #mlpack
< jeffin143[m]> rcurtin (@freenode_rcurtin:matrix.org): I think we should go with the release
< jeffin143[m]> Binding are ready and also shuffle split
< jeffin143[m]> Passed the build
< rcurtin> jeffin143[m]: awesome, yeah, I think we are just about ready. I'll put in some more time tonight
ImQ009 has quit [Quit: Leaving]
< zoq> rcurtin: The minimal Julia version is set to: 1.3.0, but the latest version in debian buster is 1.0.3, so I was wondering if there is anything we need that's not in 1.0.3?
< zoq> Also, I can't build mlpack if libstb-dev is installed.
< zoq> multiple definition of `stbiw__linear_to_rgbe(unsigned char*, float*)'; CMakeFiles/mlpack.dir/core/data/load_image.cpp.o:load_image.cpp:(.text+0x19da0): first defined here
< zoq> Have to figure out what happens, running on a fresh debian:buster-slim docker image.
< zoq> Okay, turns out the version that comes with debian buster has: void stbiw__linear_to_rgbe, but it should be static void stbiw__linear_to_rgbe.
< zoq> So anything < v1.10 probably fails.
< zoq> Nice, no define to get the version ...
< rcurtin> zoq: wow, that's frustrating!
< rcurtin> for Julia, the Debian Julia packages don't really work right anyway, so I'm pretty sure everyone just downloads from julialang.org
< rcurtin> the distribution is such that I doubt anyone other than me and Julia's build farm will build with -DBUILD_JULIA_BINDINGS=ON
< zoq> One solution I can think of, is to parse the header in the cmake file.
< zoq> rcurtin: Hm, I did run some simple examples with 1.0.3, and they seem to work just fine.
< zoq> But easy to switch to a newer version.
< zoq> I was just confused because the LTS version is 1.0.5 or something like that.
< rcurtin> yeah, I think everything runs fine with as far back as Julia 0.7.0
< rcurtin> but the packaging scripts (not used if the build is only used locally) depend.on packages that are new to Julia 1.3.0
< rcurtin> I don't fully understand the STB error, let me see if I can reproduce it after I finish making dinner :)
< zoq> It's just because the method has to be static void and not void.
< zoq> rcurtin: So, this sounds like if I'm lazy I could also adjust: https://github.com/mlpack/mlpack/blob/master/src/mlpack/bindings/julia/CMakeLists.txt#L5
< rcurtin> yeah, actually, that did originally say 0.7.0; birm suggested updating it to 1.3.0 since that was the version of Julia we were testing with
< rcurtin> I'm ambivalent---I think it's okay to change that back to 0.7.0
< rcurtin> as far as I understand, in the Julia community, basically nobody uses an old version---1.4.0 came out a few weeks ago and I am "behind the times" on 1.3.1 because I haven't upgraded
< rcurtin> very different than what I'm used to :)
< rcurtin> anyway, if you want to change it back to 0.7.0 I'd be fine with it
< zoq> If that's just for packaging, I think maybe revert that change is a good idea, lowers the burden for non Julia Experts :)
< rcurtin> sure, let's do that then :)