verne.freenode.net changed the topic of #mlpack to: http://www.mlpack.org/ -- We don't respond instantly... but we will respond. Give it a few minutes. Or hours. -- Channel logs: http://www.mlpack.org/irc/
< rcurtin>
zoq: where is the functionality you mentioned in benchmarks#52 where the setup won't be rebuilt unless something in libraries/ changes?
< rcurtin>
I'm not seeing that, to me it seems like every build will call 'make setup', which will always run
mikeling has joined #mlpack
govg has quit [Ping timeout: 246 seconds]
govg has joined #mlpack
mentekid has quit [Quit: Leaving.]
govg has quit [Ping timeout: 258 seconds]
govg has joined #mlpack
govg has quit [Ping timeout: 240 seconds]
shikhar has joined #mlpack
govg has joined #mlpack
chenzhe has joined #mlpack
govg has quit [Ping timeout: 240 seconds]
< zoq>
rcurtin: I was lazy so the script is in the "pull-requests benchmarks benchmark" jenkins shell block.
govg has joined #mlpack
chenzhe has quit [Ping timeout: 246 seconds]
shikhar has quit [Quit: WeeChat 1.4]
govg has quit [Ping timeout: 240 seconds]
shikhar has joined #mlpack
vivekp has quit [Ping timeout: 246 seconds]
vivekp has joined #mlpack
vivekp has quit [Ping timeout: 245 seconds]
vivekp has joined #mlpack
travis-ci has joined #mlpack
< travis-ci>
mlpack/mlpack#2435 (master - 167e43c : Marcus Edel): The build was fixed.
< jenkins-mlpack>
Ryan Curtin: Use correct types in program.
aashay has joined #mlpack
chenzhe has quit [Ping timeout: 240 seconds]
< rcurtin>
zoq: I see what you mean, that is a nice little way to avoid rebuilding the whole benchmark libraries :)
< rcurtin>
I'm working on getting the databases set correctly, so that I can hit 'build' on each benchmark job and then it will deploy the updates to the mlpack.org sql table
< zoq>
rcurtin: Couldn't we just use a temporary database for all libs and once the benchmarks finished we merge the release database with the temporary. Mysql should handle the write lock for us.
< rcurtin>
hm, I guess doing that you would set up an sql server on each of the 5 benchmark hosts, and then set up an additional job to sync the 5 benchmark sql DBs with the one on mlpack.org?
< zoq>
I was thinking to use the same mlpack.org sql server for all benchmark jobs.
< rcurtin>
oh, I see what you mean
< rcurtin>
yeah
< rcurtin>
does the benchmark system write to the SQL server each time a single benchmark (i.e. on one method and dataset) is completed?
< rcurtin>
if that's the case I definitely agree, I will make a temporary database
< zoq>
yes, I guess we have to see if we run in some timeouts, but that should not be the case.