Open in new window / Try shogun cloud
--- Log opened Tue May 31 00:00:19 2016
-!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has joined #shogun00:24
-!- mode/#shogun [+o HeikoS] by ChanServ00:24
-!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Quit: Leaving.]00:48
-!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has joined #shogun00:55
-!- mode/#shogun [+o HeikoS] by ChanServ00:55
-!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Quit: Leaving.]01:30
shogun-buildbotbuild #2889 of bsd1 - libshogun is complete: Failure [failed configure]  Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2889  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, OXPHOS <engelzora@gmail.com>01:32
shogun-buildbotbuild #27 of xenial - libshogun is complete: Failure [failed compile]  Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/27  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, OXPHOS <engelzora@gmail.com>01:35
-!- besser82 [~besser82@fedora/besser82] has joined #shogun02:16
-!- mode/#shogun [+o besser82] by ChanServ02:16
shogun-buildbotbuild #18 of FC23 - libshogun - aarch64 is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.org/builders/FC23%20-%20libshogun%20-%20aarch64/builds/18  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, OXPHOS <engelzora@gmail.com>02:28
-!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 244 seconds]02:36
-!- mizari [~mizari@95-174-213-100.nts.su] has joined #shogun03:33
shogun-buildbotbuild #10 of clang - thread analysis is complete: Failure [failed compile]  Build details are at http://buildbot.shogun-toolbox.org/builders/clang%20-%20thread%20analysis/builds/10  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Sanuj <sanuj.sharma.in@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com>, OXPHOS <engelzora@gmail.com>03:45
shogun-buildbotbuild #9 of clang - undefined behaviour analysis is complete: Failure [failed compile]  Build details are at http://buildbot.shogun-toolbox.org/builders/clang%20-%20undefined%20behaviour%20analysis/builds/9  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Sanuj <sanuj.sharma.in@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com>, OXPHOS <engelzora@gmail.com>03:49
shogun-buildbotbuild #10 of memleak - valgrind is complete: Failure [failed memory check]  Build details are at http://buildbot.shogun-toolbox.org/builders/memleak%20-%20valgrind/builds/10  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Sanuj <sanuj.sharma.in@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com>, OXPHOS <engelzora@gmail.com>06:19
-!- mizari [~mizari@95-174-213-100.nts.su] has quit [Ping timeout: 244 seconds]06:22
shogun-buildbotbuild #1012 of nightly_none is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_none/builds/1012  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Sanuj <sanuj.sharma.in@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com>, OXPHOS <engelzora@gmail.com>06:31
shogun-buildbotbuild #1141 of nightly_default is complete: Failure [failed test notebooks]  Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_default/builds/1141  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Sanuj <sanuj.sharma.in@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com>, OXPHOS <engelzora@gmail.com>07:45
-!- c4goldsw [5da420e6@gateway/web/cgi-irc/kiwiirc.com/ip.93.164.32.230] has joined #shogun09:35
-!- c4goldsw [5da420e6@gateway/web/cgi-irc/kiwiirc.com/ip.93.164.32.230] has quit [Client Quit]09:38
-!- c4goldsw [5da420e6@gateway/web/cgi-irc/kiwiirc.com/ip.93.164.32.230] has joined #shogun09:52
-!- sanuj [~sanuj@117.204.240.143] has joined #shogun10:00
-!- sanuj [~sanuj@117.204.240.143] has quit [Ping timeout: 272 seconds]10:06
-!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has joined #shogun10:12
-!- mode/#shogun [+o HeikoS] by ChanServ10:12
@HeikoSwiking: jo10:21
@HeikoSlisitsyn: jo10:21
lisitsynHeikoS: h10:21
@HeikoSlisitsyn: you think its a good idea to fix seeds in the integraiton tests with random output?10:21
@HeikoSor just not test in that case (and rely on unit tests)10:21
@HeikoSlisitsyn: such a test is a bit of a nop10:21
@HeikoSbut not sure10:21
@HeikoSwhat do you think?10:21
lisitsynnot sure I get it10:22
@HeikoSlisitsyn: imagine I have class X10:22
lisitsynah10:22
@HeikoSX.classify() is random10:22
lisitsynyeah ok so you fix a seed when something is random10:22
@HeikoSyeah10:22
@HeikoSbut is that a meaningful test?10:22
lisitsynapart from being possibly not cross-platfom10:22
lisitsynit should be ok10:22
@HeikoSlisitsyn: no it is10:22
@HeikoSwe have our own random generator10:22
lisitsynokie10:22
@HeikoSwiking: wrote it10:22
lisitsynthen it depends what you check10:23
lisitsynI am not sure it is a good idea to check exact values10:23
lisitsynbut whether it worked - why not10:23
@HeikoSlisitsyn: so say kmeans centers10:24
@HeikoSyeah thats the thing, is it really a good idea to check exact values in that case?10:24
@HeikoSor just no integration test but rather a unit test that somehow deals with this differently10:24
lisitsynwell I see no danger yet10:24
lisitsynbut for some reason not a fan10:25
@HeikoSlisitsyn: the decision is now10:27
@HeikoSdid not do that yet10:27
@HeikoShave to decide10:27
lisitsynHeikoS: well good test should probably check more reasonable things10:28
lisitsynlike objective of k-means10:28
shogun-buildbotbuild #2890 of bsd1 - libshogun is complete: Failure [failed configure]  Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2890  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, OXPHOS <engelzora@gmail.com>10:28
@HeikoSlisitsyn: but that is unit10:30
@HeikoSlisitsyn: not integration10:30
@HeikoSright?10:30
@HeikoSlisitsyn: ok then10:30
lisitsynHeikoS: yeah10:30
@HeikoSlisitsyn: on the other hand10:30
shogun-buildbotbuild #28 of xenial - libshogun is complete: Failure [failed compile]  Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/28  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, OXPHOS <engelzora@gmail.com>10:30
@HeikoSpurpose of integration in some way is "did things change"10:30
@HeikoSlisitsyn: then, lets only store deterministic stuff10:31
@HeikoSthanks10:31
lisitsynHeikoS: I see value in integration tests10:31
@HeikoSlisitsyn: mmh10:31
@HeikoSlisitsyn: so what would you do?10:31
@HeikoSstore or not store?10:31
@HeikoSlisitsyn: its much better now10:32
lisitsynwell probably10:32
lisitsynwe could store10:32
@HeikoSwe had the seeds fixed before10:32
lisitsynbut automatically10:32
@HeikoSbut also stored things like class instances10:32
lisitsynlike in generated tests10:32
@HeikoSlisitsyn: yeah that is what I talk about10:32
lisitsynbut not manually using 3.14234210:32
@HeikoSoh yeah sure10:32
@HeikoSit is just that10:32
@HeikoSI am talking about10:32
@HeikoSmeta example output10:32
lisitsynok then lets keep it10:32
lisitsynit is cheap10:32
@HeikoSkk10:33
-!- sanuj [~sanuj@117.204.240.143] has joined #shogun10:34
sanujHeikoS, hi!10:34
@HeikoSsanuj:  hi10:34
@HeikoSyour did the gmm cookbook right?10:34
@HeikoSyou10:34
sanujyes10:35
sanujwhat happened10:35
@HeikoSsanuj: nothing :)10:35
@HeikoSI just want to ask you to do something10:35
@HeikoSthat is, put a Math.init_random(0) in the front of it10:35
@HeikoSand then put the generated output as integration test10:35
@HeikoSSaurabh7: hi10:36
sanujHeikoS, yes, i'll do that10:36
Saurabh7HeikoS: hi!10:36
@HeikoSSaurabh7: about the x-validation, I would really like to get this out of the way quikly. SO nevermind the locked case for now10:36
Saurabh7HeikoS: its working10:36
@HeikoSSaurabh7: just the unlocked case, simplest possible10:36
@HeikoSSaurabh7: locked as well?=10:37
Saurabh7ok i will remove then10:37
@HeikoSSaurabh7: for the PR, remove for now10:37
Saurabh7HeikoS: yes10:37
@HeikoSwant to merge10:37
@HeikoSand then we can incrementally increase complexity10:37
Saurabh7HeikoS: ok10:37
@HeikoSbut I want to keep the patch simple and also merge this very soon10:37
Saurabh7HeikoS: ok then i remvoe10:37
@HeikoSSaurabh7: great10:37
Saurabh7unlcoked is working for everything runs folds no leaks10:38
Saurabh7after teh changes10:38
@HeikoSSaurabh7: great10:38
sanujHeikoS, for the svr cookbook10:39
@HeikoSSaurabh7: also remove the parallel runs for now, only folds10:39
sanujyou want me to add the objective function10:39
@HeikoSand what we need is a unit test10:39
@HeikoSthat compares output of both10:39
sanujHeikoS, shall i add the one from here http://www.shogun-toolbox.org/doc/en/latest/classshogun_1_1CLibSVR.html#details10:39
@HeikoSSaurabh7: for a single machine, can you add that to the PR and then polish?10:39
sanujbut it's lot of math for a cookbook page i think10:40
Saurabh7HeikoS: yep10:40
@HeikoSsanuj: yeah thats too much10:40
@HeikoSsanuj: then just leave it as it was, i.e. only write how the final function looks like10:40
@HeikoSThere is a link to that doc anyways10:40
sanujalright10:41
sanujlisitsyn, hello!10:41
lisitsynsanuj: hey10:41
sanujgot time?10:41
sanujwanted to discuss about the hash function10:42
lisitsyna little bit10:42
lisitsynyes ok10:42
sanujlisitsyn, BaseTag has only one member10:42
sanuji.e. name10:42
lisitsynyeah probably10:42
sanujso i use the name to generate the hash10:42
sanuji read this http://stackoverflow.com/questions/17016175/c-unordered-map-using-a-custom-class-type-as-the-key10:42
lisitsynyes10:42
sanujthen there will be collision because of same names10:43
lisitsynyeah I think it makes sense to make them collide10:43
lisitsynimplement *both* operator== and hash10:43
lisitsynthen hash collisions won't cause trouble10:44
lisitsynbut the same name = the same parameter10:44
lisitsynthis sounds reasonable10:44
sanujlisitsyn, but in whole shogun there can be multiple parameters with the same name10:44
sanujbecause the map will be stored in SGObject10:44
sanujbut there are many classes derived from SGObject10:45
lisitsyn?? :)10:45
sanujand each class shall have different parameters with the same name10:45
lisitsynobject10:45
lisitsynnot class10:45
sanujyeah10:45
sanujobject10:45
sanujsorry10:45
lisitsynso no problem10:45
sanujso suppose object A and B10:46
lisitsyndifferent objects would have the same parameter name10:46
sanujbut the same name parameters will collide10:46
lisitsynhow?10:46
sanujbecause same name will generate same hash10:47
lisitsynyes but how's that bad if you have different objects10:47
sanujlisitsyn, A("width") B("width")10:48
sanujcan have diff values10:48
lisitsynyes exactly, what is wrong with that10:48
sanujlisitsyn, oh i thought that if they have same key(name) then one will overwrite the other10:49
lisitsynhow? :)10:49
lisitsyndifferent objects10:49
sanujoh10:49
sanujnow i get it10:49
sanuj:D10:49
sanujhaha10:50
lisitsynsanuj: as basetag is immutable (you can't change name)10:50
sanujlisitsyn, then why do we need BaseTag10:50
sanujlisitsyn, can't we use just name as hash10:50
sanujas key i mean10:50
lisitsynsanuj: nah that could be better10:50
lisitsynessentially the same10:51
lisitsynbut10:51
lisitsynsanuj: BaseTag is immutable10:51
lisitsynyou can't change its name10:51
lisitsynjust precompute hash in its ctor10:51
lisitsyncompute and store it once10:51
lisitsynthen in hash function just access it10:51
sanujlisitsyn, i see10:51
sanujlisitsyn, to compute hash from it's name10:52
sanujshall i use std::hash?10:52
lisitsynyes sure10:52
lisitsynwe can change that later if needed10:52
lisitsynjust std hash would suffice10:52
sanujlisitsyn, okay, so this should happen in BaseTag constructor10:53
lisitsynyes10:53
sanujlisitsyn, and one more thing10:53
sanujlisitsyn, we are making BaseTag immutable by adding const10:53
lisitsynyes10:53
lisitsynconst everything up there10:53
sanujcan't we do that for string also?10:53
lisitsynconst std::string?10:53
sanujyeah10:53
lisitsynyeah why not10:54
sanujlisitsyn, then why do we need BaseTag10:54
sanujwe could have used name in Tag itself10:54
sanujjust make it const if we want to make it immutable10:54
lisitsynmap<Tag<T>, Any>10:54
lisitsynwhich T?10:54
lisitsyn:)10:54
sanujlisitsyn, map<std::string, Any>10:55
lisitsynno precomputed hash then10:55
lisitsynmultiple access would lead to recomputing hashes10:55
sanujlisitsyn, compute hash for tag._name in constructor10:55
sanujokay10:55
sanujlisitsyn, i see10:56
sanujwhat you mean10:56
sanuj:)10:56
sanujlisitsyn, by using BaseTag as key, we are storing the hash in BaseTag as a member so it's only computed once (in the constructor)?10:57
lisitsynyes10:58
sanujoh, i finally got it right :)10:58
lisitsynyeah its getting a bit complex10:59
lisitsynonce we get it to work should look easy11:00
sanujlisitsyn, yes11:00
sanujlisitsyn, so just to confirm11:01
sanujthere are 2 members in BaseTag11:01
sanuj_hash11:01
sanujand _name11:01
lisitsynsanuj: yeah fair enough11:07
sanujcool11:07
shogun-buildbotbuild #19 of FC23 - libshogun - aarch64 is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.org/builders/FC23%20-%20libshogun%20-%20aarch64/builds/19  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, OXPHOS <engelzora@gmail.com>11:09
@HeikoSSaurabh7: and?11:15
Saurabh7hey11:50
Saurabh7HeikoS: removed everything11:50
@HeikoSSaurabh7: hi11:50
Saurabh7still cant see how we can unit test before and after11:51
@HeikoSSaurabh7: you need to distinguish the case in the code11:52
@HeikoSthat is11:52
@HeikoSif (get_global_parallel()->get_num_threads()) == 1) { initialise machine and features in old way } else {the new way}11:52
@HeikoSbut that is super simple as all you need to do is to remember whether you have to clone or not11:53
@HeikoSand then change all machine assignments11:53
@HeikoSso if no threads are available, the code does *exactly* the same as before you started editing it11:53
Saurabh7yes i understand it, didnt knwo about we had get_global_parallel tho11:54
Saurabh7let me ad quickly11:54
@HeikoSSaurabh7: should be easy11:54
Saurabh7yes only if else11:54
@HeikoSyep11:54
@HeikoSand then you can set the number of threads to 1 in the unit test11:54
@HeikoSand then back to num_cpus11:55
c4goldswWhat time does OXPHOS usually come on?12:13
c4goldswHeikoS ^12:13
Saurabh7c4goldsw: i think shes arnd utc-812:21
-!- sanuj [~sanuj@117.204.240.143] has quit [Ping timeout: 276 seconds]12:21
c4goldswSaurabh7 Thanks12:22
-!- sanuj [~sanuj@117.204.240.143] has joined #shogun12:38
@HeikoSc4goldsw: she is NY time12:54
c4goldswHeikoS Ah, good to know.  I won't have to stay up late then.12:56
-!- lambday [8028b10a@gateway/web/freenode/ip.128.40.177.10] has joined #shogun13:07
-!- mode/#shogun [+o lambday] by ChanServ13:07
@HeikoSlambday: hi! could you send a PR for the omp parallel thread setter?13:07
@HeikoSSaurabh7: needs to use it13:08
@lambdayHeikoS: yeah let me add that..13:08
@lambdayHeikoS: too much rain :(13:09
@HeikoSlambday: ha! indeed13:22
@HeikoSthats why I am currently working from here13:22
-!- travis-ci [~travis-ci@ec2-54-224-204-201.compute-1.amazonaws.com] has joined #shogun13:30
travis-ciit's Heiko Strathmann's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/13410565713:30
-!- travis-ci [~travis-ci@ec2-54-224-204-201.compute-1.amazonaws.com] has left #shogun []13:30
sanujHeikoS, regarding Gaussian Kernel cache size13:41
sanujshall i use the default cache size13:41
sanujwhich is 1013:41
@HeikoSsanuj: yes13:48
@HeikoSthats good13:48
sanujHeikoS, what is cache size13:51
sanujis it in bytes?13:52
@HeikoSno I think mbytes13:52
@HeikoScheck the code13:52
@HeikoSsanuj: if a kernel cache is used (say kernel computation is very expensive)13:52
@HeikoSand the kernel matrix is huge13:52
@HeikoSi.e. cannnot be stored13:52
@HeikoSthe kernel cache is something for in between13:52
@HeikoSnot storing the full matrix13:53
@HeikoSbut not re-computing everything13:53
@HeikoSonly makes sense for very expensiv ekernel functions13:53
sanuji see13:55
-!- c4goldsw [5da420e6@gateway/web/cgi-irc/kiwiirc.com/ip.93.164.32.230] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]14:02
-!- mizari [~mizari@95-174-213-100.nts.su] has joined #shogun14:06
@HeikoSSaurabh7: jo14:22
@HeikoShow is it going?14:22
@HeikoSlets get this thing out of the way soon, it shouldnt take that long to write  simple test14:22
@HeikoSmatter of minutes14:22
Saurabh7HeikoS: done sending14:23
@HeikoSSaurabh7: ah cool :)14:23
Saurabh7it was segfaulting for some reason when i assign directly14:23
@HeikoSSaurabh7: did you valgrind it?14:25
@HeikoSnull pointer?14:25
Saurabh7got it i had to disable parallel and ref only when num_thread==114:26
@HeikoSnot sure I get that, but Ill see in the pr14:28
@HeikoSSaurabh7: I see no14:41
@HeikoSw14:41
@HeikoSI would do the other way around14:41
@HeikoSnot put extra REF/UNREF for m_machine14:41
@HeikoSbut DO put REF and UNREF for the cloned ones (in case num_threads>1=)14:42
Saurabh7HeikoS: ah yes you are right14:44
@HeikoSSaurabh7: did you valgrind the unit test?14:45
Saurabh7HeikoS: not the unit test but similar example14:45
@HeikoSvalgrind ./shogun-unit-test --gtest_filter=CrossValidation_multithread.LibSVM_unlocked14:46
Saurabh7how to ge14:46
Saurabh7HeikoS:  ok :)14:46
@HeikoSSaurabh7: please always do that for such critial use cases :)14:46
@HeikoSrun that in the build/tests/unit dir14:46
@HeikoSyou can run a make before14:46
@HeikoS(will only compile things needed for the unit tests)14:46
@HeikoSSaurabh7: how many cpu do you have?14:48
Saurabh7HeikoS: 414:49
Saurabh7but for some reason when i was debugging i see 3 threads with omp14:49
@HeikoSyeah there are some problems with omp setup14:50
@HeikoShttps://github.com/shogun-toolbox/shogun/pull/3236/files14:50
@HeikoSthis fixes it14:50
@HeikoSwe have to wait for that to be merged, otherwise the set_num_threads doesnt affect omp14:50
@HeikoSSaurabh7: ok, there are some minor clean ups14:53
@HeikoSSaurabh7: then rebase against 3236, and then we are done first first step14:53
Saurabh7HeikoS: ok14:56
@HeikoSSaurabh7: so that is good14:57
@HeikoSSaurabh7: with this stuff in place14:57
@HeikoScan you do a benchmark14:57
@HeikoSfor say liblinear?14:57
Saurabh7HeikoS: yes14:59
@HeikoSSaurabh7: any algorithm that doesnt run multicore on its own14:59
@HeikoSSaurabh7: let me know how it compares15:01
@HeikoScurios15:01
@HeikoSalso memory usage is interesting as we clone the features15:01
Saurabh7clone has overhead with runtime tooo i think15:01
Saurabh7i profiled this libsvm15:01
Saurabh7HeikoS: https://gist.github.com/Saurabh7/19637ab52d0d595016ac2820a9e87d4b15:02
Saurabh7but i will compare lets see15:02
@HeikoSneed debug symbols15:02
sanujlisitsyn, hey15:04
@HeikoSSaurabh7: ok cool. So we need to wait for the other patch to be merged before you can tell openml to only use 1 thread from shogun15:10
@HeikoSSaurabh7: lets benchmark (and test again) once it is merged15:10
@HeikoSSaurabh7: I suggest you start with the LARS in the mean time?15:11
Saurabh7HeikoS: ok will start with profiling that too15:12
Saurabh7have a benchmark for taht i think already15:12
@HeikoSSaurabh7: to get familiar with the code, it might be good to write a few unit tests (or extend existing ones) and then eigen3-ize the code15:12
@HeikoSSaurabh7: they key routines are the low rank updates of cholesky factors or matrix inverses15:13
@HeikoSarianepaola: hi15:13
@HeikoSarianepaola: what are you up to ?15:13
Saurabh7HeikoS: i see thanks keeping in mind15:13
@HeikoSSaurabh7: again, share things early, this allows us to proceed much faster :)15:14
@HeikoSSaurabh7: we can continue to incrementaly improve the x-validation over the next days15:14
@HeikoSSaurabh7: would like to add: parallel locked training (not sure how yet)15:14
@HeikoSthen parallel runs15:14
@HeikoSand sharing the feature matrix15:14
-!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Quit: Leaving.]15:19
-!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has joined #shogun15:20
-!- mode/#shogun [+o HeikoS] by ChanServ15:20
sanujlisitsyn, there?15:25
Saurabh7HeikoS: yes i will15:25
Saurabh7HeikoS: parallel locked works with clone but i think it will be slower15:26
@HeikoSSaurabh7: actually15:26
@HeikoSthining about it15:26
@HeikoSif we clone everything after the locking15:27
@HeikoSthen that would easily work in parallel15:27
@HeikoSwithout being slower in fact15:27
Saurabh7HeikoS:  thats what i did15:27
@HeikoSSaurabh7: locking simply precoimputes the kernel matrix15:27
@HeikoSI see15:27
@HeikoSmmh15:27
Saurabh7but there we assert CustomKernel == kernel15:27
@HeikoSso then sharing the kernel matrix15:27
@HeikoSis exactly the same as sharing features15:27
Saurabh7so i made that change15:27
@HeikoSif things are cloned15:27
@HeikoSSaurabh7: assert as in the same pointer?15:28
Saurabh7HeikoS: yes15:28
@HeikoSSaurabh7: I see15:28
Saurabh7but clone makes different ones15:28
@HeikoSI see15:28
Saurabh7for both m_custom_kernel and kernel15:28
@HeikoSok then15:28
Saurabh7after lock15:28
@HeikoSmaybe re-add it after all15:28
Saurabh7HeikoS: but i checked the speed too15:29
@HeikoSand?15:29
Saurabh7parallel was slower this way for some reason15:29
@HeikoSmmh15:29
@HeikoSslower as in?15:29
Saurabh7parallel locked + clone  vs seq locked15:29
@HeikoSSaurabh7:  it depends where the kernel matrix is precomputed15:30
@HeikoSwell lets do things incremental anyways, let's stay with the simple case for now15:30
@HeikoSit needs benchmarking and testing15:30
@HeikoSand then data sharing15:30
@HeikoSTHEN we can do locked case15:30
Saurabh7precompute happens in CCustomkernel init15:30
Saurabh7ok15:30
@HeikoSinteresting that is is slower15:31
Saurabh7yup I will make a reproduceable example later15:32
Saurabh7let u know15:32
arianepaolaHello everyone :-)15:35
sanujarianepaola, Hi!15:35
arianepaolahi sanuj15:35
sanujlambday, there?15:37
sanujHeikoS, there?15:38
@lambdaysanuj: yo15:40
sanujlambday, whatsup :)15:41
sanujdid the rain end? ;)15:41
@lambdaysanuj: not really :|15:41
sanujoh sad15:41
@lambdaythis whole week it's gonna be rainy15:41
@lambday:'(15:41
sanujhaha15:41
sanujit's sunny here15:41
sanuj40 degrees15:42
@lambdayhaha15:42
sanujlambday, i wanted to to know how to print private variables in shogun15:42
sanujfor debugging15:42
@lambdaysanuj: you want to just test it for your local use or commit it?15:43
sanujlambday, just want to test it for local use15:43
@lambdaysanuj: just use SG_PRINT/SPRINT/cout/printf whatever then :D15:43
sanujlambday, will that print while i build it or from the unit test?15:44
sanujoh it will print while i run the unit test15:44
sanujgot it15:44
@lambdayyes15:44
@HeikoSsanuj: hi15:52
@HeikoSarianepaola: hi15:55
arianepaolahi HeikoS15:57
@HeikoSarianepaola: how are things going?15:57
arianepaolagood15:57
@HeikoSarianepaola: wanted to hear what things you are currently doing and planning to do for the wekk15:58
@HeikoSweek15:58
arianepaolaI will be looking into the rest of the unit tests required to pass for the debian package15:59
arianepaolaI have some linking errors with lapack16:00
-!- travis-ci [~travis-ci@ec2-54-146-36-34.compute-1.amazonaws.com] has joined #shogun16:00
travis-ciit's Heiko Strathmann's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/13411781316:00
-!- travis-ci [~travis-ci@ec2-54-146-36-34.compute-1.amazonaws.com] has left #shogun []16:00
arianepaolado you have an idea on #3213?16:00
arianepaolathis is related to the lapack part in the cmake files16:01
@HeikoSarianepaola: not really, sorry16:01
@HeikoSweird error16:01
@HeikoSbtw in terms of building the package16:02
@HeikoSI guess there is quite a few things that can be done even if the tests dont pass yet?16:02
@HeikoSarianepaola: so if you say you are looking into the unit tests, what exactly does that mean? Any particular problems?16:04
arianepaolawhat wiking suggested in approach of the debian package was to make things more modular by separating libshogun and the modular interfaces16:06
-!- sanuj [~sanuj@117.204.240.143] has quit [Ping timeout: 276 seconds]16:07
@HeikoSarianepaola: yeah thats a god idea, we had that in the past in fact16:07
@HeikoSand does that work easily?16:07
arianepaolaand improve the parts that he did on the cmake config branch16:07
arianepaolathe lapack error hinders to build the interfaces16:08
@HeikoSarianepaola: on your ubuntu?16:08
@HeikoSarianepaola: well if it blocks, why not continue somewhere else until it is figured out?16:09
-!- sanuj [~sanuj@117.204.240.143] has joined #shogun16:09
arianepaolait is in a vm16:09
arianepaolahave tried both 14.04 and 16.04, get the same16:09
@HeikoSwiking is probably on holiday for this long weekend and he will be able to help sorting that out later I guess16:09
@HeikoSe.g. the cookbook you sent is still incomplete16:10
-!- OXPHOS [9d8b131c@gateway/web/freenode/ip.157.139.19.28] has joined #shogun16:10
@HeikoSit would be good to get a few more16:10
@HeikoSpython install16:10
arianepaolayes, I was going to work on it today16:10
@HeikoStons of stuff16:10
@HeikoSno need to get blocked by one thing :)16:10
@HeikoSOXPHOS: good orning :)16:10
arianepaolasure HeikoS :-)16:10
OXPHOSHeikoS: hello :)16:11
@HeikoSOXPHOS: all good?16:12
OXPHOSHeikoS: yes. reading logs - so try to fix seeds for integration tests16:14
@HeikoSOXPHOS: yeah16:14
@HeikoSjust adding a single call16:14
@HeikoSin the .sg listing16:14
@HeikoSno need to mention it in the cookbook rst16:15
OXPHOSHeikoS Lemme try16:15
OXPHOSAlso here's a gist for opaque pointer of Vector wrapper class, I can open a separate PR for now but it'll be overlapped with the currently one finally.16:19
OXPHOShttps://gist.github.com/OXPHOS/42f06dfc38325399982faf2f9468b7fa16:20
OXPHOSDo u want to have a look now? HeikoS, lambday, wiking16:20
OXPHOS^16:20
@HeikoSOXPHOS: lambday should check16:20
OXPHOSkk16:20
-!- travis-ci [~travis-ci@ec2-54-224-204-201.compute-1.amazonaws.com] has joined #shogun16:23
travis-ciit's Heiko Strathmann's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/13413913216:23
-!- travis-ci [~travis-ci@ec2-54-224-204-201.compute-1.amazonaws.com] has left #shogun []16:23
@lambdayOXPHOS: hey16:27
@lambdaychecking16:27
OXPHOSlambday: thx!16:27
@lambdayOXPHOS: can you please add this in the PR? we can't really comment inline in gist16:28
OXPHOSlambday: sure. So I'll push from the same branch? Or should I open a new PR? it'll be quite different from yesterday's16:29
@lambdayOXPHOS: actually, don't bother.. let me have a look and let's discuss here a bit first16:30
OXPHOSlambday: thx. and for the name, I prefer to do BaseDataPtr/CPUDataPtr/GPUDataPtr, instead of BaseVector/CPUVector. Since Matrix will be in16:31
@lambdayOXPHOS: CPUVector shouldn't have a ptr to SGVector, maybe just the underlying T* and len?16:31
@lambdayor just a reference16:32
OXPHOSlambday: good point16:32
@lambdayOXPHOS: how do you plan to put the matrix classes in this?16:33
@lambdayOXPHOS: using the same class for both?16:33
@lambdayor create a subclass of this C(G)PUDataPtr16:34
OXPHOSlambday: use the same class, and overload constructor16:34
@lambdayOXPHOS: maybe using the same class is not the best idea.. one can then pass a matrix to a method that is supposed to work only with vectors16:35
@lambdaysee the issue?16:35
@lambdayif you want to use the similar underlying array structure,16:36
@lambdaythen maybe we have something like BaseDataPtr (maybe call it BaseMemArray) <-- CPUMemArray <-- CPUVector | CPUMatrix16:37
@lambdayCPUMemArray has the underlying array16:37
OXPHOSlambday: I see.16:37
@lambdaythen CPUVector has an extra field "len", and then CPUMatrix has "num_rows" and "num_cols"16:37
@lambdaybut doesn't matter.. I'd rather just keep two different ptrs for the data for vectors and matrices and remove the CPUMemArray class in between..16:39
@lambdayand make CPUvec CPUmat directly inherit from basememarrya16:39
OXPHOSSo the user just send whatever to factory and get a basearray back16:40
@lambdayOXPHOS: yes.. factory creates the appropriate instance and returns that instance, casting to base type16:41
@lambdayand, basememarray shouldn't be the base class for both matrices and vectors16:42
@lambdaythen we face the same problem..16:42
@lambdayimagine this16:42
@lambdayauto vec = factory(a) // a --> SGVector<T> type16:43
@lambdayvec is of BaseVector<T>* type16:43
@lambdayif a was SGMatrix<T>, the factory should return BaseMatrix<T>* type or something16:43
OXPHOSlambday: I think I got you - but we can throw error if let's say dot(matrix a, b)? This might be too expensive16:45
@lambdayif we get the same base ptr in both the cases, there is no way we can differentiate whether we have a vector or matrix16:45
@lambdayOXPHOS: no.. if someone tries to do dot(matrix a, b), this should not even compile :)16:45
OXPHOSlambday: haha okay16:45
OXPHOSso completely separate16:46
@lambdaycatching these things at compile time is better :) specially the "illegal operations" cases like this16:46
@lambdayOXPHOS: yeah.. check SGVector and SGMatrix.. they are totally independent ..16:46
@lambdayyes they both depend on SGReferenceData but that is only for the ref-counting16:46
OXPHOSlambday: sure! also, I saw people use unique_ptr for opaque pointer. But it failed for me. We're suppose to switch to smart pointer for this right?16:48
@lambdayOXPHOS: it is a good idea to use unique_ptr for the opaque ptr..16:48
@lambdayOXPHOS: what errors did you get?16:48
OXPHOSkind of, not known how much space to allocate for the pointer as the struct is incomplete16:49
@lambdayOXPHOS: shouldn't be a problem if you allocate in the cpp..16:50
@lambdaythere the compiler knows what exactly the struct is..16:50
@lambdayOXPHOS: let me show you something16:50
@lambdayOXPHOS: https://github.com/shogun-toolbox/shogun/blob/feature/bigtest/src/shogun/statistical_testing/HypothesisTest.h16:51
@lambdayhttps://github.com/shogun-toolbox/shogun/blob/feature/bigtest/src/shogun/statistical_testing/HypothesisTest.cpp16:51
@lambdayOXPHOS: another comment - we probably won't need this thing : https://gist.github.com/OXPHOS/42f06dfc38325399982faf2f9468b7fa#file-linalg-cpp-L2116:52
@lambdayOXPHOS: okay let's try one thing.. the PR you sent, it works, right?16:54
@lambdayas in, it does compile and we can run it16:54
OXPHOSlambday: thx! I did similar thing..but now I think I might have screwed up some details, like namespace..16:54
OXPHOSlambday: yes16:54
@lambdayOXPHOS: okay.. next step: make the PR work with the d-ptr.. that compiles and works..16:55
@lambdaybaby steps16:55
@lambdayfirst, split the basevector into header and cpp16:55
@lambday(you don't need to add all the template instantiations.. just add float64_t for now.. if it works with that, all other primitive types would work)16:56
@lambdaywhen that works, split the CPUvector into header and cpp16:56
@lambdaythen cpu16:56
@lambdaygpu*16:56
@lambdayiteratively16:56
OXPHOSlambday: there's nothing to split for base vector?16:56
@lambdayif you update the PR itself, it would be easier to see what works and what doesn't16:56
@lambdayOXPHOS: well, you can add the instantiations in the cpp :)16:57
@lambdayOXPHOS: anyway, not too imp now.. maybe keep the basevector in the header for now16:58
@lambdaybut split the children16:58
OXPHOSlambday: sure16:59
@lambdayOXPHOS: let me know when you update the PR :)17:00
@HeikoSSaurabh7: the parallel thing is merged17:00
OXPHOSlambday: np. thx!17:00
@HeikoSOXPHOS: hey17:06
@HeikoSjust looking at the cereal thing you sent17:06
OXPHOSHeikoS: yep17:06
@HeikoSOXPHOS: so that save and load pair seems to work fine17:06
@HeikoSOXPHOS: is the design you have in mind based on having such save/load pairs for all SG* types?17:07
@HeikoSOXPHOS: because currently, all this is done in TParameter.h17:07
@HeikoSOXPHOS: can you maybe clean up this PR?17:09
@HeikoSOXPHOS: so that only the necessary bits of SGVector are there17:09
OXPHOSHeikoS: yes. if I understood correctly, save method in TParameter.h will fall back to the original type. So If SG*type works, all other class should17:09
OXPHOSHeikoS: sure17:09
@HeikoSOXPHOS: yeah this is a good idea17:09
@HeikoSOXPHOS: *though*17:09
@HeikoSthere is one thing17:09
shogun-buildbotbuild #2891 of bsd1 - libshogun is complete: Failure [failed configure]  Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2891  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, lambday <heavensdevil6909@gmail.com>17:10
@HeikoSthis will only work for SG* that have basic types in them17:10
OXPHOSlambday: ((I'm wating for the making17:10
@HeikoSOXPHOS: like int, float etc17:10
@HeikoSthere are two more cases17:10
@HeikoS1.) CSGOBject17:10
@HeikoSthat should be easy as we just call CSGOBject::save there17:11
@HeikoS2.) SG*17:11
@HeikoSan example would be a SGMatrix<SGMatrix>17:11
@HeikoSShogun can currently serialize this17:11
@HeikoSbut I suggest we drop that17:12
@HeikoSand only allow for basic and CSGOBject17:12
@HeikoSthen your approach would work17:12
OXPHOSfor SGObject, I had kmeans (SGObject?) implemented, which saves a SGVector<> and an int. It worked.17:13
OXPHOSHeikoS: I saw only these two params are serialized (Added to param list) now17:14
@HeikoSyeah sure, that falls under the first cases17:14
@HeikoSOXPHOS: wait17:14
@HeikoShow did you implement that for kmeans?17:14
@HeikoShave a gist?17:15
OXPHOSdigging17:16
-!- sanuj [~sanuj@117.204.240.143] has quit [Ping timeout: 276 seconds]17:16
OXPHOSHeikoS: in this ugly PR: https://github.com/shogun-toolbox/shogun/pull/3199/files#diff-40b41b5eecabf9f724506e7e80fe541917:17
OXPHOSif you jump to kmeans.h, it's there.17:17
@HeikoSok17:17
@HeikoSOXPHOS: can you send another PR with just the kmeans thing? and mention that its just to show?17:17
@HeikoSOXPHOS: but ok17:18
@HeikoSreading it17:18
@HeikoSOXPHOS: so the thing here is17:18
@HeikoSOXPHOS: you are implementing the save method explicitly17:18
@HeikoSOXPHOS: so far so good17:18
@HeikoSBUT, the save method is implemented in the base class CSGObject17:18
@HeikoSwhich means in that code, you dont have access to members directly17:19
OXPHOSHeikoS: Sure. they're all public?17:19
@HeikoSOXPHOS: how would you access them?17:19
@HeikoSthe method is in CSGObject.cpp itself17:19
@HeikoSOXPHOS: the only way to access things is through m_parameters17:20
OXPHOSHeikoS: ahh I got it17:20
@HeikoSOXPHOS: so you need to iterate through m_parameters17:20
@HeikoSand the distinguish all the cases17:20
@HeikoS1.) single (basic & CSGObject=)17:21
@HeikoS2.) SG* (T=basic or CSGOBject)17:21
@HeikoSOXPHOS: have a look at CSGObject::save_serializable17:22
@HeikoSwhich calls17:22
@HeikoSTParameter::save17:22
@HeikoSand TParameter::save is the juicy one, where all the cases are at17:23
@HeikoSyou need to do something similar to this17:23
@HeikoSand we should simplify on the fly17:23
@HeikoSyou will see that this method is pretty much doing the same as you kmeans version, but in the general case17:24
OXPHOSHeikoS: sure. so I shall 1). clean up SGVectorCerealTest and 2). jump to SGObject/parameter? Or try kmeans first?17:25
@HeikoSOXPHOS:  not really a point in doing things explicit17:26
@HeikoSas you see, if you can serialize kmean17:26
@HeikoSthats it, you can only serialize that class17:26
@HeikoSbut we dont want to do this by hand for all the classes17:26
@HeikoSAlso check TSGDataType in DataType.h17:26
@HeikoSthere you have these 3 things17:27
@HeikoSprimitive type17:27
@HeikoSstructure type17:27
@HeikoScontainer type17:27
@HeikoSso I think the first step is to implement the save method for SGVector using cereal (you got that more or less already)17:28
@HeikoSthe next step is to read and understand the existing code a bit17:28
@HeikoSand ask many questions :)17:28
@HeikoSwe should also talk to wiking soon on this17:29
@HeikoSI gotta leave now, see you later17:29
OXPHOSHeikoS: right..thx! I'll check closer17:29
OXPHOSHeikoS: too sophisticated. But I guess I have to read through17:30
@HeikoSOXPHOS: dont spend too much time in details17:30
@HeikoStry to understand the TSGDataType thing17:30
OXPHOSkk17:30
@HeikoSits essentially just goes through all the cases17:30
@HeikoSno container, no structure, only primitive17:30
@HeikoSvector/matrix container, no structure, all primitives17:31
@HeikoSand then sparse etc17:31
@HeikoSso check the function calls17:31
OXPHOSokay thx!17:32
@wikingHeikoS: yo17:36
@HeikoSwiking: ah jojo welcome back17:36
@HeikoSwiking: was about to leave, but maybe we should discuss a few things17:37
@HeikoSwiking: how are things?17:37
@HeikoSlook what I just found, hahaha http://www.demiurge.technology/17:37
@HeikoSwiking: lets talk later17:38
@HeikoSreally gotta go17:38
@HeikoSill be back in 2 hrs or so17:38
@wikingok17:38
@wikingHeikoS: i'm UTC+817:38
@wikingso i probably wont be online anyore :(17:38
@wikingso from now on i'm again singapore timezone17:38
@wikingOXPHOS: since i've got a lot of unread emails (as well from you) do you have a preference of list of pr/issues you want me to check on?17:39
@HeikoSwiking: can talk tomorrow then17:39
@wikingkk17:40
@wikingsent you an email17:40
@wikingplz answer that asap17:40
shogun-buildbotbuild #29 of xenial - libshogun is complete: Failure [failed compile]  Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/29  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, lambday <heavensdevil6909@gmail.com>17:41
OXPHOSwiking: I'm good for now. I'll work sth out today and ping you again. :)17:41
@wikingbtw17:41
@wikinghave we merged the cmake detection to the branch?17:41
OXPHOSwiking: yes17:42
@wikingah yeah we did cool!17:42
@wikingthnx for doing the squashing17:42
-!- sanuj [~sanuj@117.204.240.143] has joined #shogun17:42
OXPHOSwiking: np. I have an open pr but I'll clean it up first and show you.17:42
OXPHOSlambday: there? unique_ptr still fails.17:43
@wiking src/shogun/lib/CerealTest.h17:43
OXPHOShttps://gist.github.com/OXPHOS/89ad25db040852b5ea1add46d122a79517:43
@wikingthi sis still a test?17:43
@wikingi mean i suppose you are moving this .h somewhere later?17:43
@lambdayOXPHOS: let me check17:44
OXPHOSwiking: It's supposed to be in SGVector later.17:44
OXPHOSlambday: thx17:44
@wikingkk17:44
OXPHOSwiking: somehow Math.h or whatever confused current load and this one17:44
OXPHOSduring compiling17:44
sanujlisitsyn, there?17:45
lisitsynyes17:45
@lambdayOXPHOS: try adding the instantiation for int in base?17:45
@lambdayas well as for gpuvector?17:45
sanujlisitsyn, i got the hashing work exactly the way we want in a dummy17:45
sanujwas trying to do it in shogun17:45
sanujgetting an error17:45
lisitsynwhat error?17:46
OXPHOSlambday: just to be sure - you mean the template struct GPU_Vector<int32_t> right?17:46
@HeikoSwiking: replied17:46
@lambdayOXPHOS: yeah17:46
sanujlisitsyn, http://pastebin.com/D6di2Ka117:47
OXPHOSlambday: it is there..so lemme move base to cpp too17:47
@lambdayOXPHOS: let me try this in my machine17:47
lisitsynsanuj: C++ exception with description "Bad cast toint but the type is shogun::Any::Empty" thrown in the test body.17:48
sanujlisitsyn, yes17:48
sanujlisitsyn, happened while doing EXPECT_EQ(gauss_kernel->get(distance), 10);17:48
lisitsynsanuj: well need to check your code17:49
-!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Quit: Leaving.]17:49
sanujlisitsyn, i'll push it on the pr17:49
arianepaolahi wiking17:49
-!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has joined #shogun17:49
-!- mode/#shogun [+o HeikoS] by ChanServ17:49
-!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Client Quit]17:50
OXPHOSlambday: I got the same error even if I had template struct BaseVector<int32_t> and BaseVector in .cpp17:52
-!- leagoetz [~leagoetz@nat-221-122.internal.eduroam.ucl.ac.uk] has joined #shogun17:55
@lambdayOXPHOS: works fine here - https://gist.github.com/lambday/123b97bfe6f15f98d0f7d24ce8dd35b517:56
@lambdayOXPHOS: please paste working code in gist17:56
sanujlisitsyn, https://github.com/shogun-toolbox/shogun/pull/322117:57
@lambdayOXPHOS: did it work?17:59
lisitsynsanuj: you didn't copy the hash17:59
lisitsynneither in copy ctor, nor in assignment17:59
sanujlisitsyn, oh, i'll fix it18:00
sanujmissed them by mistake18:01
OXPHOSlambday: on it18:01
sanujdidn't have a copy and assignment constructor in my dummy18:01
OXPHOSlambday: yes..18:03
@lambdayOXPHOS: what was the issue :)18:03
OXPHOSOXPHOS: how..Is there a difference between clang and g++?18:04
OXPHOSlambday:^18:04
@lambdayOXPHOS: I just checked with clang++ and even then it worked!18:05
OXPHOSlambday: Yeah me too..so I'll remove all other stuff and put them back in bit by bit18:06
@lambdayOXPHOS: yeah that sounds good18:07
-!- travis-ci [~travis-ci@ec2-54-163-137-83.compute-1.amazonaws.com] has joined #shogun18:08
travis-ciit's Heiko Strathmann's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/13415808618:08
-!- travis-ci [~travis-ci@ec2-54-163-137-83.compute-1.amazonaws.com] has left #shogun []18:08
shogun-buildbotbuild #20 of FC23 - libshogun - aarch64 is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.org/builders/FC23%20-%20libshogun%20-%20aarch64/builds/20  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, lambday <heavensdevil6909@gmail.com>18:28
-!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Quit: buildmaster reconfigured: bot disconnecting]18:30
-!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun18:31
-!- leagoetz [~leagoetz@nat-221-122.internal.eduroam.ucl.ac.uk] has quit []18:42
-!- OXPHOS [9d8b131c@gateway/web/freenode/ip.157.139.19.28] has quit [Ping timeout: 250 seconds]18:50
-!- mizari [~mizari@95-174-213-100.nts.su] has quit [Quit: Leaving]18:53
-!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has joined #shogun18:59
-!- mode/#shogun [+o HeikoS] by ChanServ18:59
@wikingHeikoS: so how's ccache?19:35
@HeikoSwiking: jo19:35
@HeikoSit is better19:36
@HeikoSBUT still annoys me19:36
@HeikoSthat I cannot isolate my unit tests19:36
@wikingwhat's the output of ccache -s ?19:36
@HeikoSeats like 10s time everytime I check something19:36
@HeikoS1. relinking of shogun 2. re-linking of unit tests19:36
lisitsynHeikoS: is it about runtime19:36
lisitsynor compile time19:36
@HeikoScompiling is fine now due to ccache19:36
@HeikoSeven if I switch Debug/Release19:36
@HeikoScache size                           4.0 Gbytes19:37
@HeikoSmax cache size                      10.0 Gbytes19:37
@HeikoSwiking: so all good with that19:37
lisitsynis it about running just a few tests?19:37
@HeikoSlisitsyn: no I do that19:37
lisitsynis it about linking all tests?19:37
@HeikoSit is about the fact that I cannot isolate my stuff: my classes and my tests19:37
lisitsynplugins19:37
lisitsyn:D19:37
@HeikoSbut I think classes will be resoilved with plugiuns19:38
@HeikoSyeah19:38
@HeikoSand unit tests hopefully once the serialization is out19:38
@HeikoSthough I dont see that yet tbh19:38
@HeikoSwiking: as we still need to test serialization right?19:38
@HeikoSwiking: another thought I had about this was if we had two unit test binaries: one with automatically generated tests for all shogun classes (serialization, clone, etc) and one for the manually written ones19:39
@HeikoSthat would help19:39
@HeikoSlol my shogun code is 1000x faster than my "clever" python code19:40
@HeikoSlisitsyn: how are the plugins going?19:40
lisitsynHeikoS: well it is about parameters yet19:41
@HeikoSparameters as in?19:41
@HeikoSbtw you should also tell OXPHOS how the serialization will be done once the parameter maps are ready19:41
lisitsynsure19:43
lisitsynHeikoS: well sanuj on his way to integrate generic parameters into sgobject19:43
lisitsynvia map19:43
lisitsynand tags19:43
sanujlisitsyn, it's working now19:43
sanuj:)19:43
lisitsyncool19:43
sanuji'm testing them with T = SGVector19:43
@HeikoSlisitsyn: ah sooo good :)19:44
@HeikoSsanuj: lisitsyn please tell OXPHOS that19:44
@HeikoSbecause I told her to check Parameter.h19:44
-!- lambday [8028b10a@gateway/web/freenode/ip.128.40.177.10] has quit [Quit: Page closed]19:44
sanujHeikoS, yes i'll19:44
@HeikoSsanuj: and you have a prototype right?19:45
@HeikoSshare it19:45
@HeikoSand tell her that she can already think about cereal on this19:45
sanujHeikoS, yes but i used aer19:45
@HeikoSthats fine19:45
sanujThe PR is enough for the prototype now19:45
@HeikoSjust how the interface is19:45
sanujI need to add swig interface19:45
sanujwhich i will do tomorrow19:46
sanujwhich i will do tomorrow19:46
sanujoh sorry19:46
sanujlisitsyn, i think sgvector is causing some trouble19:49
sanuji'll look into this tomorrow19:49
lisitsynok19:49
sanujgotta sleep19:49
sanujlisitsyn, what time will you be here tomorrow19:49
lisitsynprobably starting from 8-9 UTC19:50
sanujokay19:50
sanujgoodnight :)19:50
-!- sanuj [~sanuj@117.204.240.143] has quit [Remote host closed the connection]19:51
-!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Quit: Leaving.]19:56
-!- travis-ci [~travis-ci@ec2-54-224-204-201.compute-1.amazonaws.com] has joined #shogun19:58
travis-ciit's Heiko Strathmann's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/13419137919:58
-!- travis-ci [~travis-ci@ec2-54-224-204-201.compute-1.amazonaws.com] has left #shogun []19:58
-!- OXPHOS [9d8b1501@gateway/web/freenode/ip.157.139.21.1] has joined #shogun21:18
-!- lambday [56a397da@gateway/web/freenode/ip.86.163.151.218] has joined #shogun21:18
-!- mode/#shogun [+o lambday] by ChanServ21:18
OXPHOSlambday: hey21:41
@lambdayOXPHOS: yo21:41
OXPHOSlambday: aha you're still here!21:42
OXPHOSlambday: so I changed the constructor you wrote to GPUVector(int a);21:42
OXPHOSand did int main() {     GPUVector<int> vec(5);     return 0; }21:43
OXPHOSgot error:  error: no matching function for call to 'std::unique_ptr<shogun::GPUVector<int>, std::default_delete<shogun::GPUVector<int> > >::unique_ptr(std::unique_ptr<shogun::GPUVector<int>::GPUArray, std::default_delete<shogun::GPUVector<int>::GPUArray> >)'21:43
@lambdayOXPHOS: as in, vector length 521:43
@lambday?21:43
-!- OXPHOS_ [9d8b1501@gateway/web/freenode/ip.157.139.21.1] has joined #shogun21:45
-!- lambday [56a397da@gateway/web/freenode/ip.86.163.151.218] has quit [Ping timeout: 250 seconds]21:48
-!- OXPHOS [9d8b1501@gateway/web/freenode/ip.157.139.21.1] has quit [Ping timeout: 250 seconds]21:48
OXPHOS_test21:49
-!- lambday [56a397da@gateway/web/freenode/ip.86.163.151.218] has joined #shogun21:49
-!- mode/#shogun [+o lambday] by ChanServ21:49
@lambdayOXPHOS_: works fine here21:49
OXPHOS_lambday: can I send you the exact scripts I'm trying to run and you try again?21:50
@lambdayOXPHOS_: yes..21:51
@lambdaythat's what I have been saying :D21:51
@lambdayupload/send exact thing :D21:51
OXPHOS_lambday: my bad .. https://gist.github.com/a70af5c8945befc8915d143e5c5d4b8e.git21:53
@lambdayOXPHOS_: you haven't instantiated GPUVector<int> yet21:55
@lambdayOXPHOS_: try this: put the main function in a separate file21:55
@lambdayinstantiate the templates (maybe just for int/double) - put those within shogun namespace21:55
@lambdayinstantiate the templates (maybe just for int/double) - put those within shogun namespace21:57
-!- lambday_ [56a397da@gateway/web/freenode/ip.86.163.151.218] has joined #shogun21:58
-!- mode/#shogun [+o lambday_] by ChanServ21:59
OXPHOS_lambday: done.21:59
@lambday_OXPHOS_: and?21:59
OXPHOS_lambday: sry 1sec22:00
-!- lambday [56a397da@gateway/web/freenode/ip.86.163.151.218] has quit [Ping timeout: 250 seconds]22:01
OXPHOS_lambday_: okay I updated the gist. Now I have the same error I had for the dot linalg22:02
@lambday_OXPHOS_: the instantiations have to be within the namespace :)22:04
@lambday_i.e., inside namespace shogun { .... }22:05
OXPHOS_I just threw the .cpp in namespace shogun{...} and updated the gist22:07
@lambday_OXPHOS_: works?22:07
OXPHOS_doesn't seem to help22:07
OXPHOS_the same error22:07
@lambday_strange!22:08
@lambday_let me download your code22:08
OXPHOS_thx22:10
@lambday_okay your version has an error.. my version didn't have..22:12
@lambday_checking22:12
@lambday_OXPHOS_: https://gist.github.com/OXPHOS/a70af5c8945befc8915d143e5c5d4b8e#file-linalg-h-L2222:17
@lambday_this should be std::unique_ptr<GPUArray> :P22:17
OXPHOS_...22:18
OXPHOS_so sorry about this22:18
@lambday_OXPHOS_: don't worry22:18
@lambday_OXPHOS_: make sure it works22:18
OXPHOS_But in the "real" linalg code the unique_ptr was correct, and it still gave error.. lemme check again22:19
@lambday_OXPHOS_: yeah...22:20
@lambday_refactor one class (split into header+cpp), update the PR, repeat22:20
@lambday_make one changes at a time..22:20
@lambday_should work22:20
OXPHOS_lambday_: do you want me to pull a new PR even if it doesn't work for me now?22:35
OXPHOS_lambday_: sorry a huge mistake. I didn't run main.cpp for the test case.22:40
OXPHOS_lambday_: https://gist.github.com/a70af5c8945befc8915d143e5c5d4b8e.git22:43
OXPHOS_ error: invalid application of 'sizeof' to incomplete type 'shogun::GPUVector<int>::GPUArray'   static_assert(sizeof(_Tp)>0,22:43
-!- travis-ci [~travis-ci@ec2-54-224-204-201.compute-1.amazonaws.com] has joined #shogun23:01
travis-ciit's Heiko Strathmann's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/13423316923:01
-!- travis-ci [~travis-ci@ec2-54-224-204-201.compute-1.amazonaws.com] has left #shogun []23:01
@lambday_OXPHOS_: no it's better to update the existing PR for this one23:03
@lambday_OXPHOS_: why does the main function has to be within shogun namespace?23:04
OXPHOS_lambday_: it doesn't23:04
@lambday_OXPHOS_: https://gist.github.com/OXPHOS/a70af5c8945befc8915d143e5c5d4b8e#file-main-cpp-L223:05
OXPHOS_lambday_: yeah I know.. I just did copy-paste. will this harm anything? I'll change it now.23:07
@lambday_OXPHOS_: I don't think it will compile :/23:07
OXPHOS_done. still the same error23:08
@lambday_OXPHOS_: anyway.. what do you mean by opening a new PR?23:08
@lambday_OXPHOS_: the current PR works, no?23:08
@lambday_whatever stuff that is there23:08
@lambday_so make a small change, compile and make sure it still works, commit, repeat23:09
OXPHOS_I just feel the current working PR and the opaque pointer I'm writing now is too different23:09
OXPHOS_i mean, if it works, there's no diff23:09
OXPHOS_but now for some reason it doesn't. so I have only the 'opaque pointer' part23:09
@lambday_OXPHOS_: the opaque ptr gists that we have been discussing is more or less a proof of concept thing.. the actual stuff has to go inside the PR :)23:10
OXPHOS_yes..but it still doesn't work..23:10
@lambday_OXPHOS_: before making the opaque ptr change in the original PR you had, split the files first23:10
@lambday_make sure at least that works23:10
@lambday_because the original PR works, right?23:11
OXPHOS_right23:11
@lambday_so, split the file...23:11
@lambday_works? good.. no? check what went wrong..23:11
OXPHOS_okay I didn't take that as a step. will do.23:11
@lambday_then make use of the dptr in the gpuptr23:11
@lambday_hehe don't worry the about the steps.. since you said it doesn't work.. I am just saying that doing things in small steps help us find out what is actually going wrong..23:12
@lambday_and how to pinpoint the source of it23:13
@lambday_:)23:13
OXPHOS_sure. the raw pointer worked for me and I'll put it back for now. can you try the updated gist if you have time?23:13
lisitsynI heard raw pointer!23:14
@lambday_lisitsyn: sleep :P23:14
lisitsynsorry23:14
@lambday_lisitsyn: hehehe23:14
OXPHOS_bugged23:14
lisitsynraw pointer police23:14
OXPHOS_lisitsyn: they won't be merged23:15
@lambday_lisitsyn: don't hate 'em so much.. herb said they are perfectly good :D23:15
@lambday_OXPHOS_: which one you want me to try?23:15
lisitsynyes inside some functions23:15
@lambday_lisitsyn: yes23:15
@lambday_don't worry she's gonna use unique_ptr :)23:15
OXPHOS_lambday_: https://gist.github.com/a70af5c8945befc8915d143e5c5d4b8e.git23:15
OXPHOS_thx23:15
OXPHOS_now I kinda hate unique_ptr23:15
@lambday_OXPHOS_: noooooooo :'(23:16
lisitsynwhy so23:16
@lambday_don't hate23:16
lisitsynyou gonna hate everything debugging your pointers :D23:16
@lambday_OXPHOS_: well, this is the previous code, with just main function, right?23:16
@lambday_or did you change anything else?23:16
OXPHOS_they're too "smart"23:16
OXPHOS_lambday_: I changed g++. nothing else23:17
@lambday_OXPHOS_: so this doesn't work with g++ ?23:17
OXPHOS_lambyday_: no I mean last time though I had main.cpp I was still running linalg.cpp... that's why there's no error23:18
OXPHOS_for the moment23:18
OXPHOS_I didn't change linalg.h / linalg.cpp. Just add a main function.23:18
@lambday_so why doesn't it work? you compile linalg.cpp, you compile main.cpp, you link both objects, voila23:19
OXPHOS_I did g++ -c -std=c++11 -I. main.cpp -lshogun23:19
@lambday_it didn't work?23:20
@lambday_interesting23:20
OXPHOS_got the error: invalid application of 'sizeof' to incomplete type 'shogun::GPUVector<int>::GPUArray'   static_assert(sizeof(_Tp)>0,23:20
@lambday_okay let me check23:20
-!- travis-ci [~travis-ci@ec2-54-224-204-201.compute-1.amazonaws.com] has joined #shogun23:27
travis-ciit's Heiko Strathmann's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/13423652623:27
-!- travis-ci [~travis-ci@ec2-54-224-204-201.compute-1.amazonaws.com] has left #shogun []23:27
@lambday_OXPHOS_: yeah there is an error.. let me check why..23:33
-!- sonne|osx [~sonne@x5ce5a1c4.dyn.telefonica.de] has joined #shogun23:34
OXPHOS_lambday_: is it the same one? I shouldn't be glad about this, but kinda..relieved..23:34
@lambday_OXPHOS_: yeah same error (downloaded your gist) :)23:35
OXPHOS_lambday_: Hope it's not caused by a stupid typo again..I did see that error from 15h ago23:36
OXPHOS_17h23:36
@lambday_OXPHOS_: usually it is something stupid like that23:37
OXPHOS_:(23:38
@lambday_OXPHOS_: don't worry.. check a bit23:38
OXPHOS_thx23:39
--- Log closed Wed Jun 01 00:00:20 2016