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
< rcurtin> Marcus presenting mlpack at the MLOSS 2018 workshop at NeurIPS:
< rcurtin> :)
< zoq> yeah that's me :)
< robertohueso> Happy to see mlpack at NeurIPS :D
cjlcarvalho has quit [Ping timeout: 250 seconds]
vivekp has quit [Ping timeout: 250 seconds]
vivekp has joined #mlpack
vivekp has quit [Ping timeout: 250 seconds]
vivekp has joined #mlpack
ShikharJ_ has joined #mlpack
cjlcarvalho has joined #mlpack
< jenkins-mlpack2> Project docker mlpack nightly build build #148: STILL UNSTABLE in 7 hr 56 min:
< jenkins-mlpack2> Project mlpack - git commit test build #63: UNSTABLE in 33 min:
< jenkins-mlpack2> noreply: Merge pull request #1570 from zoq/ens_transition
< ShikharJ_> rcurtin: Do the merge commit builds need to run their length as well?
< rcurtin> ShikharJ_: what do you mean? I don't think I understand
< ShikharJ_> Basically when you merge a PR, the Travis and AppVeyor builds get initiated. Are they required to run their course as well, or we can cancel them to our wish?
< rcurtin> I guess we could cancel them, but I don't know why we would want to
< rcurtin> maybe I am overlooking why we would want to do that? I don't have a strong opinion, I just don't fully understand I think :)
< ShikharJ_> Guess I see them as a waste of CI resources, a past GSoC mentor I was under was very particular about running CI builds even though they were free.
< ShikharJ_> I got this habit from him maybe.
< rcurtin> I guess so; if we can find some way to be sure that the build is still successful then I don't see the need for the extra build
< rcurtin> but really the big 'waste' to focus on would be the nightly and weekly and monthly matrix builds
< rcurtin> but I feel like those are needed to catch rare random test failures
vivekp has quit [Ping timeout: 250 seconds]
< rcurtin> (actually I am working with some of those now...)
< rcurtin> if you have ideas for how to make things more efficient while still having the same level of guarantee code is working I am all for it :)
< ShikharJ_> I agree, different communities have different needs. It's just that Appveyor takes almost a couple of hours per build, it seems wasteful to build the merge commits there, since we can anyways run the nightly build (or make it bi-nightly).
< ShikharJ_> Working on a Sunday?
davida has quit [Read error: Connection reset by peer]
< ShikharJ_> I'm also seeing a 10% decrease in build time on Appveyor after zoq's ensmallen work got merged, a nice speedup indeed.
< rcurtin> ShikharJ_: yeah, I am at the airport coming home from NeurIPS
< rcurtin> I showed up early to try and catch and earlier flight but it did not work
< rcurtin> so I figured I woild write some code :)
< rcurtin> I actually find the AppVeyor builds useful for Windows, but I notice sometimes the queue gets really long sonce AppVeyor tries to build every commit
< rcurtin> so if I push a commit, then another one, then another one, three builds get queued not just one
< rcurtin> so that is pretty inefficient, since only the last one matters
vivekp has joined #mlpack
ShikharJ_ has quit [Ping timeout: 268 seconds]
< zoq> hm, I think there is some option to autocancel the build
< rcurtin> I set 'auto-cancel branch builds' for travis as well (it was already enabled for PRs)
< rcurtin> I'm looking for the option for appveyor also
< rcurtin> I see that we need to enable the 'rolling builds' option in the appveyor "settings UI" for the mlpack project
< rcurtin> but I don't see any option to get into it. maybe my AppVeyor account doesn't have permission to do that?
< rcurtin> zoq: if you have a second, maybe can you log in and see if you can do it?
< zoq> enabled
< zoq> everyone one from mlpack should be able to set options, if they use the github login
< zoq> I manually updates both of your user settings
< zoq> *updated
< rcurtin> ah, ok, thanks!