mlpack IRC logs, 2020-04-07

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

April 2020
--- Log opened Tue Apr 07 00:00:02 2020
06:48 < jeffin143[m]> Has anybody work with .olg files ???
07:12 -!- ImQ009 [~ImQ009@unaffiliated/imq009] has joined #mlpack
07:33 < jenkins-mlpack2> Yippee, build fixed!
07:33 < jenkins-mlpack2> Project docker mlpack nightly build build #665: FIXED in 3 hr 19 min:
07:33 < jenkins-mlpack2> * Marcus Edel: Add command line argument to set the source directory.
07:33 < jenkins-mlpack2> * Marcus Edel: Set the dir parameter.
08:03 -!- rcurtin[m] [rcurtinmat@gateway/shell/] has quit [Ping timeout: 246 seconds]
08:04 -!- UmarGitter[m] [gitterumar@gateway/shell/] has quit [Ping timeout: 246 seconds]
08:04 -!- mtnshhGitter[m] [gittermtns@gateway/shell/] has quit [Ping timeout: 246 seconds]
08:05 -!- NishaGeorgeGitte [gittern17@gateway/shell/] has quit [Ping timeout: 246 seconds]
08:06 -!- mtnshhGitter[m] [gittermtns@gateway/shell/] has joined #mlpack
08:08 -!- UmarGitter[m] [gitterumar@gateway/shell/] has joined #mlpack
08:08 -!- NishaGeorgeGitt4 [gittern17@gateway/shell/] has joined #mlpack
08:08 -!- rcurtin[m] [rcurtinmat@gateway/shell/] has joined #mlpack
08:09 -!- mtnshhGitter[m] [gittermtns@gateway/shell/] has quit [Changing host]
08:09 -!- mtnshhGitter[m] [gittermtns@gateway/shell/] has joined #mlpack
08:57 < metahost> This is amazing: ! Someone managed to get Linux running on the disk controller for a hard disk!!
11:26 < zoq> metahost: Scary at the same time :)
11:48 < rcurtin> metahost: that's awesome, maybe I can do this to all of my hard drives and then hook them up to the Jenkins build farm :-D
11:50 < rcurtin> ok, all the issues in the 3.3.0 milestone are taken care of as of this morning, so I'm finally going to do the 3.3.0 release
11:50 < zoq> nice
11:50 < rcurtin> (and try to figure out how I can automate it better)
12:31 -!- M_slack_mlpack_U [slackml_45@gateway/shell/] has joined #mlpack
13:29 < rcurtin> welp, gitdub has gone crazy again and decided to spam the mailing list with all commits from the last month
13:29 < zoq> :)
14:14 < rcurtin> ok... still tuning my script; it's getting closer to the ensmallen one
14:18 < rcurtin> I think I need to automate the release emails too, I'm not sure... I always spend a long time writing those
14:18 < rcurtin> a generated email doesn't have any human touch though, pretty boring to read (not sure if mine are any better :-D)
15:03 -!- tejasvi[m] [tstomarmat@gateway/shell/] has left #mlpack ["Kicked by : Idle for 30+ days"]
15:06 -!- favre49 [~favre49@] has joined #mlpack
15:07 < favre49> metahost: Wow. Reminds me of this
15:08 -!- mohona[m] [mohonamatr@gateway/shell/] has quit [Quit: Idle for 30+ days]
15:08 -!- harshitaarya[m] [harshitaar@gateway/shell/] has left #mlpack ["Kicked by : Idle for 30+ days"]
15:11 < 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?
15:11 < favre49> Or do you want something like ensmallen, where we can comment or uncomment the code depending on the application
15:17 < rcurtin> favre49: either way is fine with me, it's possible it could even be integrated with a CMake option?
15:18 < 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)
15:18 < 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
15:18 < rcurtin> (otherwise it can be really confusing, if the user isn't aware that the tests are not fully deterministic...)
15:19 < favre49> Yeah, a CMake option is the best in that case
15:20 < rcurtin> sounds good to me :)
15:20 < favre49> Also, where is the code for when the build is triggered, and we pull the pull request?
15:21 < rcurtin> -- you should be able to log in via Github
15:21 < favre49> I guess I don't really need to know that, but it would be helpful for knowing how to generate the diff
15:21 < rcurtin> actually we don't build pull requests directly on Jenkins, that's done on Azure
15:22 < rcurtin> but at least the git commit test once something is merged is done here:
15:22 < favre49> locally I've been using wget but I think `git diff master...branch`
15:22 < rcurtin> if you log in, you can hit 'configure', then scroll down to see the script
15:22 < rcurtin> (the jenkins interface might be a bit overwhelming if you haven't used it before, sorry about that)
15:22 < rcurtin> the key part, which runs the tests, just runs the script `test-support/`, which is in the jenkins-conf/mlpack repository
15:23 < rcurtin> the azure pipelines build will run the tests slightly differently; that information is in the .ci directory in the main mlpack repository
15:23 < rcurtin> (sorry it's kind of complex, things are in many places :))
15:23 < favre49> No that's fine, I've always wanted to tinker with the CI systems, never done it before
15:24 < favre49> I guess if we need to use Jenkins again, we'll need to bring back the pull request building
15:25 < 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.
15:26 < favre49> Oh I figured that part out, I just need to add the git part to it
15:26 < zoq> we use the pull request building plugin, for the style and latex job
15:26 < favre49> I used awk/sed to find the added test cases and run them
15:27 < zoq> Right, but that only works if you modify or add a test.
15:29 < zoq> rcurtin: Nice mail, maybe we can train some ML method to add some sugar on top of a general mail announcement?
15:29 < rcurtin> zoq: we could try it... :)
15:29 < 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
15:30 < 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)
15:30 < zoq> right
15:31 < 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
15:31 < 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.
15:32 < 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 :))
15:32 < rcurtin> *hard part
15:33 < zoq> True, maybe that is something in addition to the other strategy.
15:34 < 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?
15:34 < zoq> Sounds good to me.
15:35 < 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
15:36 < rcurtin> not sure how complex that is, maybe it's irritatingly hard :)
15:36 < rcurtin> still, something is better than nothing, so maybe that part can wait until later :)
15:36 < favre49> only the tests or the source code as well? The latter is the complex part
15:36 < 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
15:37 < favre49> Besides manually creating some sort of lookup table that we would need to change all the time
15:40 < zoq[m]> I did the find out test part, for the static analysis job.
15:40 < favre49> I'll check it out, is it on the mlpack-jenkins repo?
15:41 < zoq[m]> Have to check, but you can open the configuration for the job in the Jenkins ui.
15:42 < rcurtin> that's this job:
15:48 < favre49> Ah thanks, I'll see what I can do
15:50 < rcurtin> sounds good, I can try and explain more if it's helpful, just let me know :)
17:45 -!- favre49 [~favre49@] has quit [Remote host closed the connection]
18:30 < rcurtin> just had a release and already more PRs are merged on the same day? things move fast with this library :-D
18:47 < zoq> preperation for the next release
18:54 < rcurtin> :)
19:23 -!- ImQ009 [~ImQ009@unaffiliated/imq009] has quit [Quit: Leaving]
19:29 < metahost> zoq: :p
19:29 < metahost> rcurtin: more compute! :P
19:30 < metahost> favre49: whoa! You can check out the wiki on "Van Eck phreaking", pretty surreal stuff!
20:36 < 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.
21:50 -!- travis-ci [] has joined #mlpack
21:50 < travis-ci> shrit/examples#27 (makefiles - 5eee8ab : Ryan Curtin): The build passed.
21:50 < travis-ci> Change view :
21:50 < travis-ci> Build details :
21:50 -!- travis-ci [] has left #mlpack []
21:52 -!- travis-ci [] has joined #mlpack
21:52 < travis-ci> shrit/examples#28 (makefiles - b37d4a1 : Omar Shrit): The build passed.
21:52 < travis-ci> Change view :
21:52 < travis-ci> Build details :
21:52 -!- travis-ci [] has left #mlpack []
--- Log closed Wed Apr 08 00:00:03 2020