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/
favre49 has joined #mlpack
< favre49> Are the notebooks directly available on lab.mlpack.org or do i have to upload them myself?
< favre49> Not sure if its possible (or if its already a feature) , but it would be nice if I could browse all of our example notebooks and use them from lab.mlpack.org itself
kwanikar7 has joined #mlpack
kwanikar7 has quit [Remote host closed the connection]
kwanikar has joined #mlpack
kwanikar has quit [Remote host closed the connection]
kwanikar has joined #mlpack
kwanikar has quit [Remote host closed the connection]
< favre49> nishantkr18[m]: I found that at 50 episodes, it never solved the task for me (I tried like 10 times), but even 75 would sometimes solve it
< nishantkr18[m]> Ok then, let's keep it 50. Thanks for trying out :)
ImQ009 has joined #mlpack
gotadachi has quit [Quit: Leaving...]
< saksham189Gitter> @himanshupathak21061998 can you add a template parameter for the activation function in the RBFN layer?
< saksham189Gitter> Also, I think we should train on MNSIT because that is what is being used in the paper I referenced.
< saksham189Gitter> > when I am compiling it by creating a speperate file by copying same test code I am getting classification error of 0.228 I set the threshold to 0.31
< saksham189Gitter> Can you try testing with a random seed?
gotadachi has joined #mlpack
< HimanshuPathakGi> @saksham189 You mean I have to add functions in separate file and add a template variable to pass the values OK I will try with random seeds
< HimanshuPathakGi> Also can you explain I have add template parameter in forward function or what??
< saksham189Gitter> @himanshupathak21061998 I have commented on the PR. Also I think it would be better to add the other activation functions in a different PR.
< HimanshuPathakGi> Thanks for the help I think we are pretty close to complete this :)
< rcurtin> not looking good :(
< rcurtin> also, serious backlog on the memory and code analysis builds... I think I will plug in some systems at my house and set them up as build slaves too
< rcurtin> zoq: if you had a system you wanted to add, feel free, but don't feel obligated
< rcurtin> which hopefully will abort in-progress builds if a new commit is pushed
< jeffin143[m]> Now I can understand what luxury we were having
< rcurtin> hehe, yeah, it has been many years since I thought about an issue like this :)
< jeffin143[m]> May be numfocus can help ???
< zoq> rcurtin: Sure, no need to bump the electricity bill :)
< rcurtin> actually this looks like a better solution: https://github.com/jenkinsci/ghprb-plugin/issues/379
< zoq> rcurtin: Can you point me to some software I have to install?
< rcurtin> the only systems I can plug in are the ancient ones that used to be (a long! time ago) big.cc.gt.atl.ga.us and similar systems
< rcurtin> zoq: ssh should be sufficient, plus I think a JVM, and the mlpack build dependencies necessary for the job
< zoq> rcurtin: okay, let me do this right now
< rcurtin> once the host is set up, you can add a new node via http://ci.mlpack.org/computer/
< zoq> rcurtin: Did you configured the slave with a public key?
favre49 has quit [Remote host closed the connection]
< zoq> rcurtin: hm, the node is up but looks like no jobs are assigned
< zoq> maybe only new jobs
< zoq> rcurtin: "Execute concurrent builds if necessary" was disabled
< rcurtin> ah, yeah, I was a little scared of enabling that because of what it would do to the load on mlpack.org :-D
< rcurtin> Load average: 10.73 11.31 9.03
< rcurtin> one of the jobs must be building with multiple cores when it shouldn't be :)
< zoq> I guess you could decrease the number of executor for that node?
< rcurtin> yeah, I will probably do that too, down to 2
< zoq> I guess without that option there is no need to add more nodes?
< rcurtin> ahh, there it is, there was a 'make -j4'
< rcurtin> in the static code analysis build
< zoq> :D
< rcurtin> more nodes is certainly helpful, just 2 executors on mlpack.org using one core each will probably fall way behind
< rcurtin> there are only eight builds in the queue now, so it should be cleared in the next couple hours
< zoq> there are some packages that are missing on the new node
< zoq> so some builds will fail
< rcurtin> yeah, I think it will need pvs-studio (I just set that up on master the other day)
< rcurtin> easy enough to add them though based on the error messages :)
< zoq> was missing curl :)
< rcurtin> :)
< rcurtin> thank you for adding that build node, it will really help
< zoq> happy to see more load on that machine
< zoq> Will add another one once I figured how to set this up on freebsd
< rcurtin> awesome
ImQ009 has quit [Quit: Leaving]
< zoq> ahh, cppcheck is missing as well
< rcurtin> hehe, found another -j4 in the pvs-studio invocation
< rcurtin> was wondering why the load average was 15 :)
< zoq> there is one strange issue, that now every jobs waits for every other to complete ...
< rcurtin> what do you mean?
< rcurtin> it seems like all executors are in use now, so I don't see any jobs waiting longer than they should be
< zoq> you can check the log from every job that runs on polar -> "Publish Valgrind results is waiting for a checkpoint on pull-requests mlpack memory #4840"
< rcurtin> oh, strange
< rcurtin> https://github.com/jenkinsci/valgrind-plugin/pull/18 looks like it will fix the valgrind job waiting issue
< rcurtin> I'm not sure how exactly I can use a modified plugin; I'll have to look into it
< zoq> Maybe you can just search for the file and apply the fix not sure.
< rcurtin> yeah, that is probably the easiest thing to do :)
< rcurtin> who knows what will happen if that plugin ever gets upgraded, but, we'll find out...
< zoq> yeah :)
< rcurtin> I guess we'll still have to wait until the build queue is shorter though, because that will require a jenkins restart
< zoq> yes, wondering if it makes sense to disable the python bindings in the memory check job.
< rcurtin> hmm, I guess it makes sense, I suppose if we are only running the memory check on mlpack_test
< rcurtin> I guess we could also disable BUILD_CLI_EXECUTABLES too
< zoq> yes, would save a lot of build time