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/
< jeffin143[m]>
Has anybody work with .olg files ???
< favre49>
rcurtin[m]: I started writing the script for the random seed CI testing, and I was wondering if we could just add the seed-setting code to the global config directly?
< favre49>
Or do you want something like ensmallen, where we can comment or uncomment the code depending on the application
< rcurtin>
favre49: either way is fine with me, it's possible it could even be integrated with a CMake option?
< rcurtin>
one of the things that matters is that by default, we should ensure the same seed is used (regardless of what that seed is)
< rcurtin>
this is so that a user who runs mlpack_test and sees a failure will also see it the second time they run it
< rcurtin>
(otherwise it can be really confusing, if the user isn't aware that the tests are not fully deterministic...)
< favre49>
Yeah, a CMake option is the best in that case
< rcurtin>
sounds good to me :)
< favre49>
Also, where is the code for when the build is triggered, and we pull the pull request?
< favre49>
locally I've been using wget but I think `git diff master...branch`
< rcurtin>
if you log in, you can hit 'configure', then scroll down to see the script
< rcurtin>
(the jenkins interface might be a bit overwhelming if you haven't used it before, sorry about that)
< rcurtin>
the key part, which runs the tests, just runs the script `test-support/runTestBins.sh`, which is in the jenkins-conf/mlpack repository
< rcurtin>
the azure pipelines build will run the tests slightly differently; that information is in the .ci directory in the main mlpack repository
< rcurtin>
(sorry it's kind of complex, things are in many places :))
< favre49>
No that's fine, I've always wanted to tinker with the CI systems, never done it before
< favre49>
I guess if we need to use Jenkins again, we'll need to bring back the pull request building
< zoq>
Maybe the work I did on the static analysis job is helpful? For the job, I tried to infer the test case for a specific commit.
< favre49>
Oh I figured that part out, I just need to add the git part to it
< zoq>
we use the pull request building plugin, for the style and latex job
< favre49>
I used awk/sed to find the added test cases and run them
< zoq>
Right, but that only works if you modify or add a test.
< zoq>
rcurtin: Nice mail, maybe we can train some ML method to add some sugar on top of a general mail announcement?
< rcurtin>
zoq: we could try it... :)
< rcurtin>
favre49: zoq: we originally avoided using Jenkins for all PR builds because it's a vulnerability---basically we're executing whatever code in a PR that someone opens
< rcurtin>
(on azure this isn't a problem, it's all sandboxed; but on Jenkins this isn't currently the case, some builds don't run inside docker containers)
< zoq>
right
< favre49>
zoq: Ah you're right, that didn't cross my mind... Should be able to fix it but the problem is if someone makes a single, small change to a test case (like a style change) it'll run a 1000 times
< zoq>
I was wondering if we could tell mlpack-jenkins to run a specific test like 100 times, that might be an option as well.
< rcurtin>
that's another option, mlpack-jenkins can watch for a message with specific names of test cases to run (we would just need to make sure we remember to run it, which is maybe the hard port :))
< rcurtin>
*hard part
< zoq>
True, maybe that is something in addition to the other strategy.
< favre49>
Yeah, we can have it run a 100 times for new or modified test cases and have this in case there is a change to the pre-existing code?
< zoq>
Sounds good to me.
< rcurtin>
it would be cool if we could have jenkins-mlpack (or something?) post a message of which tests are modified, to see if they need to be run again
< rcurtin>
not sure how complex that is, maybe it's irritatingly hard :)
< rcurtin>
still, something is better than nothing, so maybe that part can wait until later :)
< favre49>
only the tests or the source code as well? The latter is the complex part
< favre49>
The only idea I can think of is to find all the places where the changed file is included and run the tests there
< favre49>
Besides manually creating some sort of lookup table that we would need to change all the time
< zoq[m]>
I did the find out test part, for the static analysis job.
< favre49>
I'll check it out, is it on the mlpack-jenkins repo?
< zoq[m]>
Have to check, but you can open the configuration for the job in the Jenkins ui.
< rcurtin>
sounds good, I can try and explain more if it's helpful, just let me know :)
favre49 has quit [Remote host closed the connection]
< rcurtin>
just had a release and already more PRs are merged on the same day? things move fast with this library :-D
< zoq>
preperation for the next release
< rcurtin>
:)
ImQ009 has quit [Quit: Leaving]
< metahost>
zoq: :p
< metahost>
rcurtin: more compute! :P
< metahost>
favre49: whoa! You can check out the wiki on "Van Eck phreaking", pretty surreal stuff!
< PrinceGuptaGitte>
Hi sreenik, remember the structure of for Layer names we talked about with Ryan on the video call. I implemented it and it's working fine. Can you please tell me what other problems were faced due to which it wasn't implemented that way? I can't really find any right now.
travis-ci has joined #mlpack
< travis-ci>
shrit/examples#27 (makefiles - 5eee8ab : Ryan Curtin): The build passed.