mlpack IRC logs, 2020-04-04

Logs for the day 2020-04-04 (starts at 0:00 UTC) are shown below.

April 2020
--- Log opened Sat Apr 04 00:00:58 2020
03:59 < 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.
07:29 < jenkins-mlpack2> Yippee, build fixed!
07:29 < jenkins-mlpack2> Project docker mlpack nightly build build #662: FIXED in 3 hr 15 min:
08:51 -!- ImQ009 [~ImQ009@unaffiliated/imq009] has joined #mlpack
10:03 -!- favre49 [~favre49@] has joined #mlpack
10:13 < 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?
10:14 < 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
10:40 -!- favre49 [~favre49@] has quit [Remote host closed the connection]
10:43 -!- toluschr [] has joined #mlpack
15:16 -!- toluschr [] has left #mlpack []
16:30 < 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.
16:31 < zoq> kartikdutt18Gitt: Yes, will have to take a closer look at the issue, seems RNN related only.
16:37 < 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?
16:38 < zoq> kartikdutt18Gitt: Will test it later.
16:38 < kartikdutt18Gitt> Ohk great.
16:38 < zoq> kartikdutt18Gitt: Ahh, if you liek to test it out, please feel free, you can use the instance.
16:39 < kartikdutt18Gitt> Will do, Will test them and get back to you. Thanks a lot.
16:45 < zoq> kartikdutt18Gitt: Thanks!
17:09 * PrinceGuptaGitte sent a long message: < >
17:10 < PrinceGuptaGitte> I did `cmake ../` again, but it still gave this error
17:10 < zoq> PrinceGuptaGitte: Maybe start with a clean build, e.g. remove the build folder?
17:10 * PrinceGuptaGitte sent a long message: < >
17:11 < PrinceGuptaGitte> ok, I'll try that. Thanks
17:12 < PrinceGuptaGitte> That worked, thanks. I'll try this next time I'll get something like this.
17:13 < zoq> PrinceGuptaGitte: Btw. most of the time I just to make, without make install, prevents to rebuild the complete codebase once I changed something.
17:14 < PrinceGuptaGitte> Thanks I'll keep that in mind.
18:03 -!- lupulo [] has joined #mlpack
18:40 < jeffin143[m]> rcurtin ( I think we should go with the release
18:40 < jeffin143[m]> Binding are ready and also shuffle split
18:40 < jeffin143[m]> Passed the build
19:51 < rcurtin> jeffin143[m]: awesome, yeah, I think we are just about ready. I'll put in some more time tonight
20:14 -!- ImQ009 [~ImQ009@unaffiliated/imq009] has quit [Quit: Leaving]
22:19 < 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?
22:26 < zoq> Also, I can't build mlpack if libstb-dev is installed.
22:26 < 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
22:27 < zoq> Have to figure out what happens, running on a fresh debian:buster-slim docker image.
22:53 < 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.
22:57 < zoq> Here is the commit:
22:58 < zoq> So anything < v1.10 probably fails.
23:06 < zoq> Nice, no define to get the version ...
23:23 < rcurtin> zoq: wow, that's frustrating!
23:24 < rcurtin> for Julia, the Debian Julia packages don't really work right anyway, so I'm pretty sure everyone just downloads from
23:24 < rcurtin> the distribution is such that I doubt anyone other than me and Julia's build farm will build with -DBUILD_JULIA_BINDINGS=ON
23:25 < zoq> One solution I can think of, is to parse the header in the cmake file.
23:26 < zoq> rcurtin: Hm, I did run some simple examples with 1.0.3, and they seem to work just fine.
23:26 < zoq> But easy to switch to a newer version.
23:27 < zoq> I was just confused because the LTS version is 1.0.5 or something like that.
23:28 < rcurtin> yeah, I think everything runs fine with as far back as Julia 0.7.0
23:29 < 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
23:29 < rcurtin> I don't fully understand the STB error, let me see if I can reproduce it after I finish making dinner :)
23:30 < zoq> It's just because the method has to be static void and not void.
23:33 < zoq> rcurtin: So, this sounds like if I'm lazy I could also adjust:
23:52 < 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
23:52 < rcurtin> I'm ambivalent---I think it's okay to change that back to 0.7.0
23:52 < 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
23:52 < rcurtin> very different than what I'm used to :)
23:52 < rcurtin> anyway, if you want to change it back to 0.7.0 I'd be fine with it
23:54 < zoq> If that's just for packaging, I think maybe revert that change is a good idea, lowers the burden for non Julia Experts :)
23:55 < rcurtin> sure, let's do that then :)
--- Log closed Sun Apr 05 00:00:59 2020