| --- Log opened Tue May 31 00:00:19 2016 | ||
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has joined #shogun | 00:24 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 00: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 #shogun | 00:55 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 00:55 | |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Quit: Leaving.] | 01:30 | |
| shogun-buildbot | build #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-buildbot | build #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 #shogun | 02:16 | |
| -!- mode/#shogun [+o besser82] by ChanServ | 02:16 | |
| shogun-buildbot | build #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 #shogun | 03:33 | |
| shogun-buildbot | build #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-buildbot | build #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-buildbot | build #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-buildbot | build #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-buildbot | build #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 #shogun | 09: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 #shogun | 09:52 | |
| -!- sanuj [~sanuj@117.204.240.143] has joined #shogun | 10: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 #shogun | 10:12 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 10:12 | |
| @HeikoS | wiking: jo | 10:21 |
| @HeikoS | lisitsyn: jo | 10:21 |
| lisitsyn | HeikoS: h | 10:21 |
| @HeikoS | lisitsyn: you think its a good idea to fix seeds in the integraiton tests with random output? | 10:21 |
| @HeikoS | or just not test in that case (and rely on unit tests) | 10:21 |
| @HeikoS | lisitsyn: such a test is a bit of a nop | 10:21 |
| @HeikoS | but not sure | 10:21 |
| @HeikoS | what do you think? | 10:21 |
| lisitsyn | not sure I get it | 10:22 |
| @HeikoS | lisitsyn: imagine I have class X | 10:22 |
| lisitsyn | ah | 10:22 |
| @HeikoS | X.classify() is random | 10:22 |
| lisitsyn | yeah ok so you fix a seed when something is random | 10:22 |
| @HeikoS | yeah | 10:22 |
| @HeikoS | but is that a meaningful test? | 10:22 |
| lisitsyn | apart from being possibly not cross-platfom | 10:22 |
| lisitsyn | it should be ok | 10:22 |
| @HeikoS | lisitsyn: no it is | 10:22 |
| @HeikoS | we have our own random generator | 10:22 |
| lisitsyn | okie | 10:22 |
| @HeikoS | wiking: wrote it | 10:22 |
| lisitsyn | then it depends what you check | 10:23 |
| lisitsyn | I am not sure it is a good idea to check exact values | 10:23 |
| lisitsyn | but whether it worked - why not | 10:23 |
| @HeikoS | lisitsyn: so say kmeans centers | 10:24 |
| @HeikoS | yeah thats the thing, is it really a good idea to check exact values in that case? | 10:24 |
| @HeikoS | or just no integration test but rather a unit test that somehow deals with this differently | 10:24 |
| lisitsyn | well I see no danger yet | 10:24 |
| lisitsyn | but for some reason not a fan | 10:25 |
| @HeikoS | lisitsyn: the decision is now | 10:27 |
| @HeikoS | did not do that yet | 10:27 |
| @HeikoS | have to decide | 10:27 |
| lisitsyn | HeikoS: well good test should probably check more reasonable things | 10:28 |
| lisitsyn | like objective of k-means | 10:28 |
| shogun-buildbot | build #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 |
| @HeikoS | lisitsyn: but that is unit | 10:30 |
| @HeikoS | lisitsyn: not integration | 10:30 |
| @HeikoS | right? | 10:30 |
| @HeikoS | lisitsyn: ok then | 10:30 |
| lisitsyn | HeikoS: yeah | 10:30 |
| @HeikoS | lisitsyn: on the other hand | 10:30 |
| shogun-buildbot | build #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 |
| @HeikoS | purpose of integration in some way is "did things change" | 10:30 |
| @HeikoS | lisitsyn: then, lets only store deterministic stuff | 10:31 |
| @HeikoS | thanks | 10:31 |
| lisitsyn | HeikoS: I see value in integration tests | 10:31 |
| @HeikoS | lisitsyn: mmh | 10:31 |
| @HeikoS | lisitsyn: so what would you do? | 10:31 |
| @HeikoS | store or not store? | 10:31 |
| @HeikoS | lisitsyn: its much better now | 10:32 |
| lisitsyn | well probably | 10:32 |
| lisitsyn | we could store | 10:32 |
| @HeikoS | we had the seeds fixed before | 10:32 |
| lisitsyn | but automatically | 10:32 |
| @HeikoS | but also stored things like class instances | 10:32 |
| lisitsyn | like in generated tests | 10:32 |
| @HeikoS | lisitsyn: yeah that is what I talk about | 10:32 |
| lisitsyn | but not manually using 3.142342 | 10:32 |
| @HeikoS | oh yeah sure | 10:32 |
| @HeikoS | it is just that | 10:32 |
| @HeikoS | I am talking about | 10:32 |
| @HeikoS | meta example output | 10:32 |
| lisitsyn | ok then lets keep it | 10:32 |
| lisitsyn | it is cheap | 10:32 |
| @HeikoS | kk | 10:33 |
| -!- sanuj [~sanuj@117.204.240.143] has joined #shogun | 10:34 | |
| sanuj | HeikoS, hi! | 10:34 |
| @HeikoS | sanuj: hi | 10:34 |
| @HeikoS | your did the gmm cookbook right? | 10:34 |
| @HeikoS | you | 10:34 |
| sanuj | yes | 10:35 |
| sanuj | what happened | 10:35 |
| @HeikoS | sanuj: nothing :) | 10:35 |
| @HeikoS | I just want to ask you to do something | 10:35 |
| @HeikoS | that is, put a Math.init_random(0) in the front of it | 10:35 |
| @HeikoS | and then put the generated output as integration test | 10:35 |
| @HeikoS | Saurabh7: hi | 10:36 |
| sanuj | HeikoS, yes, i'll do that | 10:36 |
| Saurabh7 | HeikoS: hi! | 10:36 |
| @HeikoS | Saurabh7: about the x-validation, I would really like to get this out of the way quikly. SO nevermind the locked case for now | 10:36 |
| Saurabh7 | HeikoS: its working | 10:36 |
| @HeikoS | Saurabh7: just the unlocked case, simplest possible | 10:36 |
| @HeikoS | Saurabh7: locked as well?= | 10:37 |
| Saurabh7 | ok i will remove then | 10:37 |
| @HeikoS | Saurabh7: for the PR, remove for now | 10:37 |
| Saurabh7 | HeikoS: yes | 10:37 |
| @HeikoS | want to merge | 10:37 |
| @HeikoS | and then we can incrementally increase complexity | 10:37 |
| Saurabh7 | HeikoS: ok | 10:37 |
| @HeikoS | but I want to keep the patch simple and also merge this very soon | 10:37 |
| Saurabh7 | HeikoS: ok then i remvoe | 10:37 |
| @HeikoS | Saurabh7: great | 10:37 |
| Saurabh7 | unlcoked is working for everything runs folds no leaks | 10:38 |
| Saurabh7 | after teh changes | 10:38 |
| @HeikoS | Saurabh7: great | 10:38 |
| sanuj | HeikoS, for the svr cookbook | 10:39 |
| @HeikoS | Saurabh7: also remove the parallel runs for now, only folds | 10:39 |
| sanuj | you want me to add the objective function | 10:39 |
| @HeikoS | and what we need is a unit test | 10:39 |
| @HeikoS | that compares output of both | 10:39 |
| sanuj | HeikoS, shall i add the one from here http://www.shogun-toolbox.org/doc/en/latest/classshogun_1_1CLibSVR.html#details | 10:39 |
| @HeikoS | Saurabh7: for a single machine, can you add that to the PR and then polish? | 10:39 |
| sanuj | but it's lot of math for a cookbook page i think | 10:40 |
| Saurabh7 | HeikoS: yep | 10:40 |
| @HeikoS | sanuj: yeah thats too much | 10:40 |
| @HeikoS | sanuj: then just leave it as it was, i.e. only write how the final function looks like | 10:40 |
| @HeikoS | There is a link to that doc anyways | 10:40 |
| sanuj | alright | 10:41 |
| sanuj | lisitsyn, hello! | 10:41 |
| lisitsyn | sanuj: hey | 10:41 |
| sanuj | got time? | 10:41 |
| sanuj | wanted to discuss about the hash function | 10:42 |
| lisitsyn | a little bit | 10:42 |
| lisitsyn | yes ok | 10:42 |
| sanuj | lisitsyn, BaseTag has only one member | 10:42 |
| sanuj | i.e. name | 10:42 |
| lisitsyn | yeah probably | 10:42 |
| sanuj | so i use the name to generate the hash | 10:42 |
| sanuj | i read this http://stackoverflow.com/questions/17016175/c-unordered-map-using-a-custom-class-type-as-the-key | 10:42 |
| lisitsyn | yes | 10:42 |
| sanuj | then there will be collision because of same names | 10:43 |
| lisitsyn | yeah I think it makes sense to make them collide | 10:43 |
| lisitsyn | implement *both* operator== and hash | 10:43 |
| lisitsyn | then hash collisions won't cause trouble | 10:44 |
| lisitsyn | but the same name = the same parameter | 10:44 |
| lisitsyn | this sounds reasonable | 10:44 |
| sanuj | lisitsyn, but in whole shogun there can be multiple parameters with the same name | 10:44 |
| sanuj | because the map will be stored in SGObject | 10:44 |
| sanuj | but there are many classes derived from SGObject | 10:45 |
| lisitsyn | ?? :) | 10:45 |
| sanuj | and each class shall have different parameters with the same name | 10:45 |
| lisitsyn | object | 10:45 |
| lisitsyn | not class | 10:45 |
| sanuj | yeah | 10:45 |
| sanuj | object | 10:45 |
| sanuj | sorry | 10:45 |
| lisitsyn | so no problem | 10:45 |
| sanuj | so suppose object A and B | 10:46 |
| lisitsyn | different objects would have the same parameter name | 10:46 |
| sanuj | but the same name parameters will collide | 10:46 |
| lisitsyn | how? | 10:46 |
| sanuj | because same name will generate same hash | 10:47 |
| lisitsyn | yes but how's that bad if you have different objects | 10:47 |
| sanuj | lisitsyn, A("width") B("width") | 10:48 |
| sanuj | can have diff values | 10:48 |
| lisitsyn | yes exactly, what is wrong with that | 10:48 |
| sanuj | lisitsyn, oh i thought that if they have same key(name) then one will overwrite the other | 10:49 |
| lisitsyn | how? :) | 10:49 |
| lisitsyn | different objects | 10:49 |
| sanuj | oh | 10:49 |
| sanuj | now i get it | 10:49 |
| sanuj | :D | 10:49 |
| sanuj | haha | 10:50 |
| lisitsyn | sanuj: as basetag is immutable (you can't change name) | 10:50 |
| sanuj | lisitsyn, then why do we need BaseTag | 10:50 |
| sanuj | lisitsyn, can't we use just name as hash | 10:50 |
| sanuj | as key i mean | 10:50 |
| lisitsyn | sanuj: nah that could be better | 10:50 |
| lisitsyn | essentially the same | 10:51 |
| lisitsyn | but | 10:51 |
| lisitsyn | sanuj: BaseTag is immutable | 10:51 |
| lisitsyn | you can't change its name | 10:51 |
| lisitsyn | just precompute hash in its ctor | 10:51 |
| lisitsyn | compute and store it once | 10:51 |
| lisitsyn | then in hash function just access it | 10:51 |
| sanuj | lisitsyn, i see | 10:51 |
| sanuj | lisitsyn, to compute hash from it's name | 10:52 |
| sanuj | shall i use std::hash? | 10:52 |
| lisitsyn | yes sure | 10:52 |
| lisitsyn | we can change that later if needed | 10:52 |
| lisitsyn | just std hash would suffice | 10:52 |
| sanuj | lisitsyn, okay, so this should happen in BaseTag constructor | 10:53 |
| lisitsyn | yes | 10:53 |
| sanuj | lisitsyn, and one more thing | 10:53 |
| sanuj | lisitsyn, we are making BaseTag immutable by adding const | 10:53 |
| lisitsyn | yes | 10:53 |
| lisitsyn | const everything up there | 10:53 |
| sanuj | can't we do that for string also? | 10:53 |
| lisitsyn | const std::string? | 10:53 |
| sanuj | yeah | 10:53 |
| lisitsyn | yeah why not | 10:54 |
| sanuj | lisitsyn, then why do we need BaseTag | 10:54 |
| sanuj | we could have used name in Tag itself | 10:54 |
| sanuj | just make it const if we want to make it immutable | 10:54 |
| lisitsyn | map<Tag<T>, Any> | 10:54 |
| lisitsyn | which T? | 10:54 |
| lisitsyn | :) | 10:54 |
| sanuj | lisitsyn, map<std::string, Any> | 10:55 |
| lisitsyn | no precomputed hash then | 10:55 |
| lisitsyn | multiple access would lead to recomputing hashes | 10:55 |
| sanuj | lisitsyn, compute hash for tag._name in constructor | 10:55 |
| sanuj | okay | 10:55 |
| sanuj | lisitsyn, i see | 10:56 |
| sanuj | what you mean | 10:56 |
| sanuj | :) | 10:56 |
| sanuj | lisitsyn, 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 |
| lisitsyn | yes | 10:58 |
| sanuj | oh, i finally got it right :) | 10:58 |
| lisitsyn | yeah its getting a bit complex | 10:59 |
| lisitsyn | once we get it to work should look easy | 11:00 |
| sanuj | lisitsyn, yes | 11:00 |
| sanuj | lisitsyn, so just to confirm | 11:01 |
| sanuj | there are 2 members in BaseTag | 11:01 |
| sanuj | _hash | 11:01 |
| sanuj | and _name | 11:01 |
| lisitsyn | sanuj: yeah fair enough | 11:07 |
| sanuj | cool | 11:07 |
| shogun-buildbot | build #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 |
| @HeikoS | Saurabh7: and? | 11:15 |
| Saurabh7 | hey | 11:50 |
| Saurabh7 | HeikoS: removed everything | 11:50 |
| @HeikoS | Saurabh7: hi | 11:50 |
| Saurabh7 | still cant see how we can unit test before and after | 11:51 |
| @HeikoS | Saurabh7: you need to distinguish the case in the code | 11:52 |
| @HeikoS | that is | 11:52 |
| @HeikoS | if (get_global_parallel()->get_num_threads()) == 1) { initialise machine and features in old way } else {the new way} | 11:52 |
| @HeikoS | but that is super simple as all you need to do is to remember whether you have to clone or not | 11:53 |
| @HeikoS | and then change all machine assignments | 11:53 |
| @HeikoS | so if no threads are available, the code does *exactly* the same as before you started editing it | 11:53 |
| Saurabh7 | yes i understand it, didnt knwo about we had get_global_parallel tho | 11:54 |
| Saurabh7 | let me ad quickly | 11:54 |
| @HeikoS | Saurabh7: should be easy | 11:54 |
| Saurabh7 | yes only if else | 11:54 |
| @HeikoS | yep | 11:54 |
| @HeikoS | and then you can set the number of threads to 1 in the unit test | 11:54 |
| @HeikoS | and then back to num_cpus | 11:55 |
| c4goldsw | What time does OXPHOS usually come on? | 12:13 |
| c4goldsw | HeikoS ^ | 12:13 |
| Saurabh7 | c4goldsw: i think shes arnd utc-8 | 12:21 |
| -!- sanuj [~sanuj@117.204.240.143] has quit [Ping timeout: 276 seconds] | 12:21 | |
| c4goldsw | Saurabh7 Thanks | 12:22 |
| -!- sanuj [~sanuj@117.204.240.143] has joined #shogun | 12:38 | |
| @HeikoS | c4goldsw: she is NY time | 12:54 |
| c4goldsw | HeikoS 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 #shogun | 13:07 | |
| -!- mode/#shogun [+o lambday] by ChanServ | 13:07 | |
| @HeikoS | lambday: hi! could you send a PR for the omp parallel thread setter? | 13:07 |
| @HeikoS | Saurabh7: needs to use it | 13:08 |
| @lambday | HeikoS: yeah let me add that.. | 13:08 |
| @lambday | HeikoS: too much rain :( | 13:09 |
| @HeikoS | lambday: ha! indeed | 13:22 |
| @HeikoS | thats why I am currently working from here | 13:22 |
| -!- travis-ci [~travis-ci@ec2-54-224-204-201.compute-1.amazonaws.com] has joined #shogun | 13:30 | |
| travis-ci | it'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/134105657 | 13:30 |
| -!- travis-ci [~travis-ci@ec2-54-224-204-201.compute-1.amazonaws.com] has left #shogun [] | 13:30 | |
| sanuj | HeikoS, regarding Gaussian Kernel cache size | 13:41 |
| sanuj | shall i use the default cache size | 13:41 |
| sanuj | which is 10 | 13:41 |
| @HeikoS | sanuj: yes | 13:48 |
| @HeikoS | thats good | 13:48 |
| sanuj | HeikoS, what is cache size | 13:51 |
| sanuj | is it in bytes? | 13:52 |
| @HeikoS | no I think mbytes | 13:52 |
| @HeikoS | check the code | 13:52 |
| @HeikoS | sanuj: if a kernel cache is used (say kernel computation is very expensive) | 13:52 |
| @HeikoS | and the kernel matrix is huge | 13:52 |
| @HeikoS | i.e. cannnot be stored | 13:52 |
| @HeikoS | the kernel cache is something for in between | 13:52 |
| @HeikoS | not storing the full matrix | 13:53 |
| @HeikoS | but not re-computing everything | 13:53 |
| @HeikoS | only makes sense for very expensiv ekernel functions | 13:53 |
| sanuj | i see | 13: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 #shogun | 14:06 | |
| @HeikoS | Saurabh7: jo | 14:22 |
| @HeikoS | how is it going? | 14:22 |
| @HeikoS | lets get this thing out of the way soon, it shouldnt take that long to write simple test | 14:22 |
| @HeikoS | matter of minutes | 14:22 |
| Saurabh7 | HeikoS: done sending | 14:23 |
| @HeikoS | Saurabh7: ah cool :) | 14:23 |
| Saurabh7 | it was segfaulting for some reason when i assign directly | 14:23 |
| @HeikoS | Saurabh7: did you valgrind it? | 14:25 |
| @HeikoS | null pointer? | 14:25 |
| Saurabh7 | got it i had to disable parallel and ref only when num_thread==1 | 14:26 |
| @HeikoS | not sure I get that, but Ill see in the pr | 14:28 |
| @HeikoS | Saurabh7: I see no | 14:41 |
| @HeikoS | w | 14:41 |
| @HeikoS | I would do the other way around | 14:41 |
| @HeikoS | not put extra REF/UNREF for m_machine | 14:41 |
| @HeikoS | but DO put REF and UNREF for the cloned ones (in case num_threads>1=) | 14:42 |
| Saurabh7 | HeikoS: ah yes you are right | 14:44 |
| @HeikoS | Saurabh7: did you valgrind the unit test? | 14:45 |
| Saurabh7 | HeikoS: not the unit test but similar example | 14:45 |
| @HeikoS | valgrind ./shogun-unit-test --gtest_filter=CrossValidation_multithread.LibSVM_unlocked | 14:46 |
| Saurabh7 | how to ge | 14:46 |
| Saurabh7 | HeikoS: ok :) | 14:46 |
| @HeikoS | Saurabh7: please always do that for such critial use cases :) | 14:46 |
| @HeikoS | run that in the build/tests/unit dir | 14:46 |
| @HeikoS | you can run a make before | 14:46 |
| @HeikoS | (will only compile things needed for the unit tests) | 14:46 |
| @HeikoS | Saurabh7: how many cpu do you have? | 14:48 |
| Saurabh7 | HeikoS: 4 | 14:49 |
| Saurabh7 | but for some reason when i was debugging i see 3 threads with omp | 14:49 |
| @HeikoS | yeah there are some problems with omp setup | 14:50 |
| @HeikoS | https://github.com/shogun-toolbox/shogun/pull/3236/files | 14:50 |
| @HeikoS | this fixes it | 14:50 |
| @HeikoS | we have to wait for that to be merged, otherwise the set_num_threads doesnt affect omp | 14:50 |
| @HeikoS | Saurabh7: ok, there are some minor clean ups | 14:53 |
| @HeikoS | Saurabh7: then rebase against 3236, and then we are done first first step | 14:53 |
| Saurabh7 | HeikoS: ok | 14:56 |
| @HeikoS | Saurabh7: so that is good | 14:57 |
| @HeikoS | Saurabh7: with this stuff in place | 14:57 |
| @HeikoS | can you do a benchmark | 14:57 |
| @HeikoS | for say liblinear? | 14:57 |
| Saurabh7 | HeikoS: yes | 14:59 |
| @HeikoS | Saurabh7: any algorithm that doesnt run multicore on its own | 14:59 |
| @HeikoS | Saurabh7: let me know how it compares | 15:01 |
| @HeikoS | curios | 15:01 |
| @HeikoS | also memory usage is interesting as we clone the features | 15:01 |
| Saurabh7 | clone has overhead with runtime tooo i think | 15:01 |
| Saurabh7 | i profiled this libsvm | 15:01 |
| Saurabh7 | HeikoS: https://gist.github.com/Saurabh7/19637ab52d0d595016ac2820a9e87d4b | 15:02 |
| Saurabh7 | but i will compare lets see | 15:02 |
| @HeikoS | need debug symbols | 15:02 |
| sanuj | lisitsyn, hey | 15:04 |
| @HeikoS | Saurabh7: 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 shogun | 15:10 |
| @HeikoS | Saurabh7: lets benchmark (and test again) once it is merged | 15:10 |
| @HeikoS | Saurabh7: I suggest you start with the LARS in the mean time? | 15:11 |
| Saurabh7 | HeikoS: ok will start with profiling that too | 15:12 |
| Saurabh7 | have a benchmark for taht i think already | 15:12 |
| @HeikoS | Saurabh7: 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 code | 15:12 |
| @HeikoS | Saurabh7: they key routines are the low rank updates of cholesky factors or matrix inverses | 15:13 |
| @HeikoS | arianepaola: hi | 15:13 |
| @HeikoS | arianepaola: what are you up to ? | 15:13 |
| Saurabh7 | HeikoS: i see thanks keeping in mind | 15:13 |
| @HeikoS | Saurabh7: again, share things early, this allows us to proceed much faster :) | 15:14 |
| @HeikoS | Saurabh7: we can continue to incrementaly improve the x-validation over the next days | 15:14 |
| @HeikoS | Saurabh7: would like to add: parallel locked training (not sure how yet) | 15:14 |
| @HeikoS | then parallel runs | 15:14 |
| @HeikoS | and sharing the feature matrix | 15: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 #shogun | 15:20 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 15:20 | |
| sanuj | lisitsyn, there? | 15:25 |
| Saurabh7 | HeikoS: yes i will | 15:25 |
| Saurabh7 | HeikoS: parallel locked works with clone but i think it will be slower | 15:26 |
| @HeikoS | Saurabh7: actually | 15:26 |
| @HeikoS | thining about it | 15:26 |
| @HeikoS | if we clone everything after the locking | 15:27 |
| @HeikoS | then that would easily work in parallel | 15:27 |
| @HeikoS | without being slower in fact | 15:27 |
| Saurabh7 | HeikoS: thats what i did | 15:27 |
| @HeikoS | Saurabh7: locking simply precoimputes the kernel matrix | 15:27 |
| @HeikoS | I see | 15:27 |
| @HeikoS | mmh | 15:27 |
| Saurabh7 | but there we assert CustomKernel == kernel | 15:27 |
| @HeikoS | so then sharing the kernel matrix | 15:27 |
| @HeikoS | is exactly the same as sharing features | 15:27 |
| Saurabh7 | so i made that change | 15:27 |
| @HeikoS | if things are cloned | 15:27 |
| @HeikoS | Saurabh7: assert as in the same pointer? | 15:28 |
| Saurabh7 | HeikoS: yes | 15:28 |
| @HeikoS | Saurabh7: I see | 15:28 |
| Saurabh7 | but clone makes different ones | 15:28 |
| @HeikoS | I see | 15:28 |
| Saurabh7 | for both m_custom_kernel and kernel | 15:28 |
| @HeikoS | ok then | 15:28 |
| Saurabh7 | after lock | 15:28 |
| @HeikoS | maybe re-add it after all | 15:28 |
| Saurabh7 | HeikoS: but i checked the speed too | 15:29 |
| @HeikoS | and? | 15:29 |
| Saurabh7 | parallel was slower this way for some reason | 15:29 |
| @HeikoS | mmh | 15:29 |
| @HeikoS | slower as in? | 15:29 |
| Saurabh7 | parallel locked + clone vs seq locked | 15:29 |
| @HeikoS | Saurabh7: it depends where the kernel matrix is precomputed | 15:30 |
| @HeikoS | well lets do things incremental anyways, let's stay with the simple case for now | 15:30 |
| @HeikoS | it needs benchmarking and testing | 15:30 |
| @HeikoS | and then data sharing | 15:30 |
| @HeikoS | THEN we can do locked case | 15:30 |
| Saurabh7 | precompute happens in CCustomkernel init | 15:30 |
| Saurabh7 | ok | 15:30 |
| @HeikoS | interesting that is is slower | 15:31 |
| Saurabh7 | yup I will make a reproduceable example later | 15:32 |
| Saurabh7 | let u know | 15:32 |
| arianepaola | Hello everyone :-) | 15:35 |
| sanuj | arianepaola, Hi! | 15:35 |
| arianepaola | hi sanuj | 15:35 |
| sanuj | lambday, there? | 15:37 |
| sanuj | HeikoS, there? | 15:38 |
| @lambday | sanuj: yo | 15:40 |
| sanuj | lambday, whatsup :) | 15:41 |
| sanuj | did the rain end? ;) | 15:41 |
| @lambday | sanuj: not really :| | 15:41 |
| sanuj | oh sad | 15:41 |
| @lambday | this whole week it's gonna be rainy | 15:41 |
| @lambday | :'( | 15:41 |
| sanuj | haha | 15:41 |
| sanuj | it's sunny here | 15:41 |
| sanuj | 40 degrees | 15:42 |
| @lambday | haha | 15:42 |
| sanuj | lambday, i wanted to to know how to print private variables in shogun | 15:42 |
| sanuj | for debugging | 15:42 |
| @lambday | sanuj: you want to just test it for your local use or commit it? | 15:43 |
| sanuj | lambday, just want to test it for local use | 15:43 |
| @lambday | sanuj: just use SG_PRINT/SPRINT/cout/printf whatever then :D | 15:43 |
| sanuj | lambday, will that print while i build it or from the unit test? | 15:44 |
| sanuj | oh it will print while i run the unit test | 15:44 |
| sanuj | got it | 15:44 |
| @lambday | yes | 15:44 |
| @HeikoS | sanuj: hi | 15:52 |
| @HeikoS | arianepaola: hi | 15:55 |
| arianepaola | hi HeikoS | 15:57 |
| @HeikoS | arianepaola: how are things going? | 15:57 |
| arianepaola | good | 15:57 |
| @HeikoS | arianepaola: wanted to hear what things you are currently doing and planning to do for the wekk | 15:58 |
| @HeikoS | week | 15:58 |
| arianepaola | I will be looking into the rest of the unit tests required to pass for the debian package | 15:59 |
| arianepaola | I have some linking errors with lapack | 16:00 |
| -!- travis-ci [~travis-ci@ec2-54-146-36-34.compute-1.amazonaws.com] has joined #shogun | 16:00 | |
| travis-ci | it'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/134117813 | 16:00 |
| -!- travis-ci [~travis-ci@ec2-54-146-36-34.compute-1.amazonaws.com] has left #shogun [] | 16:00 | |
| arianepaola | do you have an idea on #3213? | 16:00 |
| arianepaola | this is related to the lapack part in the cmake files | 16:01 |
| @HeikoS | arianepaola: not really, sorry | 16:01 |
| @HeikoS | weird error | 16:01 |
| @HeikoS | btw in terms of building the package | 16:02 |
| @HeikoS | I guess there is quite a few things that can be done even if the tests dont pass yet? | 16:02 |
| @HeikoS | arianepaola: so if you say you are looking into the unit tests, what exactly does that mean? Any particular problems? | 16:04 |
| arianepaola | what wiking suggested in approach of the debian package was to make things more modular by separating libshogun and the modular interfaces | 16:06 |
| -!- sanuj [~sanuj@117.204.240.143] has quit [Ping timeout: 276 seconds] | 16:07 | |
| @HeikoS | arianepaola: yeah thats a god idea, we had that in the past in fact | 16:07 |
| @HeikoS | and does that work easily? | 16:07 |
| arianepaola | and improve the parts that he did on the cmake config branch | 16:07 |
| arianepaola | the lapack error hinders to build the interfaces | 16:08 |
| @HeikoS | arianepaola: on your ubuntu? | 16:08 |
| @HeikoS | arianepaola: well if it blocks, why not continue somewhere else until it is figured out? | 16:09 |
| -!- sanuj [~sanuj@117.204.240.143] has joined #shogun | 16:09 | |
| arianepaola | it is in a vm | 16:09 |
| arianepaola | have tried both 14.04 and 16.04, get the same | 16:09 |
| @HeikoS | wiking is probably on holiday for this long weekend and he will be able to help sorting that out later I guess | 16:09 |
| @HeikoS | e.g. the cookbook you sent is still incomplete | 16:10 |
| -!- OXPHOS [9d8b131c@gateway/web/freenode/ip.157.139.19.28] has joined #shogun | 16:10 | |
| @HeikoS | it would be good to get a few more | 16:10 |
| @HeikoS | python install | 16:10 |
| arianepaola | yes, I was going to work on it today | 16:10 |
| @HeikoS | tons of stuff | 16:10 |
| @HeikoS | no need to get blocked by one thing :) | 16:10 |
| @HeikoS | OXPHOS: good orning :) | 16:10 |
| arianepaola | sure HeikoS :-) | 16:10 |
| OXPHOS | HeikoS: hello :) | 16:11 |
| @HeikoS | OXPHOS: all good? | 16:12 |
| OXPHOS | HeikoS: yes. reading logs - so try to fix seeds for integration tests | 16:14 |
| @HeikoS | OXPHOS: yeah | 16:14 |
| @HeikoS | just adding a single call | 16:14 |
| @HeikoS | in the .sg listing | 16:14 |
| @HeikoS | no need to mention it in the cookbook rst | 16:15 |
| OXPHOS | HeikoS Lemme try | 16:15 |
| OXPHOS | Also 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 |
| OXPHOS | https://gist.github.com/OXPHOS/42f06dfc38325399982faf2f9468b7fa | 16:20 |
| OXPHOS | Do u want to have a look now? HeikoS, lambday, wiking | 16:20 |
| OXPHOS | ^ | 16:20 |
| @HeikoS | OXPHOS: lambday should check | 16:20 |
| OXPHOS | kk | 16:20 |
| -!- travis-ci [~travis-ci@ec2-54-224-204-201.compute-1.amazonaws.com] has joined #shogun | 16:23 | |
| travis-ci | it'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/134139132 | 16:23 |
| -!- travis-ci [~travis-ci@ec2-54-224-204-201.compute-1.amazonaws.com] has left #shogun [] | 16:23 | |
| @lambday | OXPHOS: hey | 16:27 |
| @lambday | checking | 16:27 |
| OXPHOS | lambday: thx! | 16:27 |
| @lambday | OXPHOS: can you please add this in the PR? we can't really comment inline in gist | 16:28 |
| OXPHOS | lambday: sure. So I'll push from the same branch? Or should I open a new PR? it'll be quite different from yesterday's | 16:29 |
| @lambday | OXPHOS: actually, don't bother.. let me have a look and let's discuss here a bit first | 16:30 |
| OXPHOS | lambday: thx. and for the name, I prefer to do BaseDataPtr/CPUDataPtr/GPUDataPtr, instead of BaseVector/CPUVector. Since Matrix will be in | 16:31 |
| @lambday | OXPHOS: CPUVector shouldn't have a ptr to SGVector, maybe just the underlying T* and len? | 16:31 |
| @lambday | or just a reference | 16:32 |
| OXPHOS | lambday: good point | 16:32 |
| @lambday | OXPHOS: how do you plan to put the matrix classes in this? | 16:33 |
| @lambday | OXPHOS: using the same class for both? | 16:33 |
| @lambday | or create a subclass of this C(G)PUDataPtr | 16:34 |
| OXPHOS | lambday: use the same class, and overload constructor | 16:34 |
| @lambday | OXPHOS: 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 vectors | 16:35 |
| @lambday | see the issue? | 16:35 |
| @lambday | if you want to use the similar underlying array structure, | 16:36 |
| @lambday | then maybe we have something like BaseDataPtr (maybe call it BaseMemArray) <-- CPUMemArray <-- CPUVector | CPUMatrix | 16:37 |
| @lambday | CPUMemArray has the underlying array | 16:37 |
| OXPHOS | lambday: I see. | 16:37 |
| @lambday | then CPUVector has an extra field "len", and then CPUMatrix has "num_rows" and "num_cols" | 16:37 |
| @lambday | but 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 |
| @lambday | and make CPUvec CPUmat directly inherit from basememarrya | 16:39 |
| OXPHOS | So the user just send whatever to factory and get a basearray back | 16:40 |
| @lambday | OXPHOS: yes.. factory creates the appropriate instance and returns that instance, casting to base type | 16:41 |
| @lambday | and, basememarray shouldn't be the base class for both matrices and vectors | 16:42 |
| @lambday | then we face the same problem.. | 16:42 |
| @lambday | imagine this | 16:42 |
| @lambday | auto vec = factory(a) // a --> SGVector<T> type | 16:43 |
| @lambday | vec is of BaseVector<T>* type | 16:43 |
| @lambday | if a was SGMatrix<T>, the factory should return BaseMatrix<T>* type or something | 16:43 |
| OXPHOS | lambday: I think I got you - but we can throw error if let's say dot(matrix a, b)? This might be too expensive | 16:45 |
| @lambday | if we get the same base ptr in both the cases, there is no way we can differentiate whether we have a vector or matrix | 16:45 |
| @lambday | OXPHOS: no.. if someone tries to do dot(matrix a, b), this should not even compile :) | 16:45 |
| OXPHOS | lambday: haha okay | 16:45 |
| OXPHOS | so completely separate | 16:46 |
| @lambday | catching these things at compile time is better :) specially the "illegal operations" cases like this | 16:46 |
| @lambday | OXPHOS: yeah.. check SGVector and SGMatrix.. they are totally independent .. | 16:46 |
| @lambday | yes they both depend on SGReferenceData but that is only for the ref-counting | 16:46 |
| OXPHOS | lambday: 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 |
| @lambday | OXPHOS: it is a good idea to use unique_ptr for the opaque ptr.. | 16:48 |
| @lambday | OXPHOS: what errors did you get? | 16:48 |
| OXPHOS | kind of, not known how much space to allocate for the pointer as the struct is incomplete | 16:49 |
| @lambday | OXPHOS: shouldn't be a problem if you allocate in the cpp.. | 16:50 |
| @lambday | there the compiler knows what exactly the struct is.. | 16:50 |
| @lambday | OXPHOS: let me show you something | 16:50 |
| @lambday | OXPHOS: https://github.com/shogun-toolbox/shogun/blob/feature/bigtest/src/shogun/statistical_testing/HypothesisTest.h | 16:51 |
| @lambday | https://github.com/shogun-toolbox/shogun/blob/feature/bigtest/src/shogun/statistical_testing/HypothesisTest.cpp | 16:51 |
| @lambday | OXPHOS: another comment - we probably won't need this thing : https://gist.github.com/OXPHOS/42f06dfc38325399982faf2f9468b7fa#file-linalg-cpp-L21 | 16:52 |
| @lambday | OXPHOS: okay let's try one thing.. the PR you sent, it works, right? | 16:54 |
| @lambday | as in, it does compile and we can run it | 16:54 |
| OXPHOS | lambday: thx! I did similar thing..but now I think I might have screwed up some details, like namespace.. | 16:54 |
| OXPHOS | lambday: yes | 16:54 |
| @lambday | OXPHOS: okay.. next step: make the PR work with the d-ptr.. that compiles and works.. | 16:55 |
| @lambday | baby steps | 16:55 |
| @lambday | first, split the basevector into header and cpp | 16: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 |
| @lambday | when that works, split the CPUvector into header and cpp | 16:56 |
| @lambday | then cpu | 16:56 |
| @lambday | gpu* | 16:56 |
| @lambday | iteratively | 16:56 |
| OXPHOS | lambday: there's nothing to split for base vector? | 16:56 |
| @lambday | if you update the PR itself, it would be easier to see what works and what doesn't | 16:56 |
| @lambday | OXPHOS: well, you can add the instantiations in the cpp :) | 16:57 |
| @lambday | OXPHOS: anyway, not too imp now.. maybe keep the basevector in the header for now | 16:58 |
| @lambday | but split the children | 16:58 |
| OXPHOS | lambday: sure | 16:59 |
| @lambday | OXPHOS: let me know when you update the PR :) | 17:00 |
| @HeikoS | Saurabh7: the parallel thing is merged | 17:00 |
| OXPHOS | lambday: np. thx! | 17:00 |
| @HeikoS | OXPHOS: hey | 17:06 |
| @HeikoS | just looking at the cereal thing you sent | 17:06 |
| OXPHOS | HeikoS: yep | 17:06 |
| @HeikoS | OXPHOS: so that save and load pair seems to work fine | 17:06 |
| @HeikoS | OXPHOS: is the design you have in mind based on having such save/load pairs for all SG* types? | 17:07 |
| @HeikoS | OXPHOS: because currently, all this is done in TParameter.h | 17:07 |
| @HeikoS | OXPHOS: can you maybe clean up this PR? | 17:09 |
| @HeikoS | OXPHOS: so that only the necessary bits of SGVector are there | 17:09 |
| OXPHOS | HeikoS: 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 should | 17:09 |
| OXPHOS | HeikoS: sure | 17:09 |
| @HeikoS | OXPHOS: yeah this is a good idea | 17:09 |
| @HeikoS | OXPHOS: *though* | 17:09 |
| @HeikoS | there is one thing | 17:09 |
| shogun-buildbot | build #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 |
| @HeikoS | this will only work for SG* that have basic types in them | 17:10 |
| OXPHOS | lambday: ((I'm wating for the making | 17:10 |
| @HeikoS | OXPHOS: like int, float etc | 17:10 |
| @HeikoS | there are two more cases | 17:10 |
| @HeikoS | 1.) CSGOBject | 17:10 |
| @HeikoS | that should be easy as we just call CSGOBject::save there | 17:11 |
| @HeikoS | 2.) SG* | 17:11 |
| @HeikoS | an example would be a SGMatrix<SGMatrix> | 17:11 |
| @HeikoS | Shogun can currently serialize this | 17:11 |
| @HeikoS | but I suggest we drop that | 17:12 |
| @HeikoS | and only allow for basic and CSGOBject | 17:12 |
| @HeikoS | then your approach would work | 17:12 |
| OXPHOS | for SGObject, I had kmeans (SGObject?) implemented, which saves a SGVector<> and an int. It worked. | 17:13 |
| OXPHOS | HeikoS: I saw only these two params are serialized (Added to param list) now | 17:14 |
| @HeikoS | yeah sure, that falls under the first cases | 17:14 |
| @HeikoS | OXPHOS: wait | 17:14 |
| @HeikoS | how did you implement that for kmeans? | 17:14 |
| @HeikoS | have a gist? | 17:15 |
| OXPHOS | digging | 17:16 |
| -!- sanuj [~sanuj@117.204.240.143] has quit [Ping timeout: 276 seconds] | 17:16 | |
| OXPHOS | HeikoS: in this ugly PR: https://github.com/shogun-toolbox/shogun/pull/3199/files#diff-40b41b5eecabf9f724506e7e80fe5419 | 17:17 |
| OXPHOS | if you jump to kmeans.h, it's there. | 17:17 |
| @HeikoS | ok | 17:17 |
| @HeikoS | OXPHOS: can you send another PR with just the kmeans thing? and mention that its just to show? | 17:17 |
| @HeikoS | OXPHOS: but ok | 17:18 |
| @HeikoS | reading it | 17:18 |
| @HeikoS | OXPHOS: so the thing here is | 17:18 |
| @HeikoS | OXPHOS: you are implementing the save method explicitly | 17:18 |
| @HeikoS | OXPHOS: so far so good | 17:18 |
| @HeikoS | BUT, the save method is implemented in the base class CSGObject | 17:18 |
| @HeikoS | which means in that code, you dont have access to members directly | 17:19 |
| OXPHOS | HeikoS: Sure. they're all public? | 17:19 |
| @HeikoS | OXPHOS: how would you access them? | 17:19 |
| @HeikoS | the method is in CSGObject.cpp itself | 17:19 |
| @HeikoS | OXPHOS: the only way to access things is through m_parameters | 17:20 |
| OXPHOS | HeikoS: ahh I got it | 17:20 |
| @HeikoS | OXPHOS: so you need to iterate through m_parameters | 17:20 |
| @HeikoS | and the distinguish all the cases | 17:20 |
| @HeikoS | 1.) single (basic & CSGObject=) | 17:21 |
| @HeikoS | 2.) SG* (T=basic or CSGOBject) | 17:21 |
| @HeikoS | OXPHOS: have a look at CSGObject::save_serializable | 17:22 |
| @HeikoS | which calls | 17:22 |
| @HeikoS | TParameter::save | 17:22 |
| @HeikoS | and TParameter::save is the juicy one, where all the cases are at | 17:23 |
| @HeikoS | you need to do something similar to this | 17:23 |
| @HeikoS | and we should simplify on the fly | 17:23 |
| @HeikoS | you will see that this method is pretty much doing the same as you kmeans version, but in the general case | 17:24 |
| OXPHOS | HeikoS: sure. so I shall 1). clean up SGVectorCerealTest and 2). jump to SGObject/parameter? Or try kmeans first? | 17:25 |
| @HeikoS | OXPHOS: not really a point in doing things explicit | 17:26 |
| @HeikoS | as you see, if you can serialize kmean | 17:26 |
| @HeikoS | thats it, you can only serialize that class | 17:26 |
| @HeikoS | but we dont want to do this by hand for all the classes | 17:26 |
| @HeikoS | Also check TSGDataType in DataType.h | 17:26 |
| @HeikoS | there you have these 3 things | 17:27 |
| @HeikoS | primitive type | 17:27 |
| @HeikoS | structure type | 17:27 |
| @HeikoS | container type | 17:27 |
| @HeikoS | so I think the first step is to implement the save method for SGVector using cereal (you got that more or less already) | 17:28 |
| @HeikoS | the next step is to read and understand the existing code a bit | 17:28 |
| @HeikoS | and ask many questions :) | 17:28 |
| @HeikoS | we should also talk to wiking soon on this | 17:29 |
| @HeikoS | I gotta leave now, see you later | 17:29 |
| OXPHOS | HeikoS: right..thx! I'll check closer | 17:29 |
| OXPHOS | HeikoS: too sophisticated. But I guess I have to read through | 17:30 |
| @HeikoS | OXPHOS: dont spend too much time in details | 17:30 |
| @HeikoS | try to understand the TSGDataType thing | 17:30 |
| OXPHOS | kk | 17:30 |
| @HeikoS | its essentially just goes through all the cases | 17:30 |
| @HeikoS | no container, no structure, only primitive | 17:30 |
| @HeikoS | vector/matrix container, no structure, all primitives | 17:31 |
| @HeikoS | and then sparse etc | 17:31 |
| @HeikoS | so check the function calls | 17:31 |
| OXPHOS | okay thx! | 17:32 |
| @wiking | HeikoS: yo | 17:36 |
| @HeikoS | wiking: ah jojo welcome back | 17:36 |
| @HeikoS | wiking: was about to leave, but maybe we should discuss a few things | 17:37 |
| @HeikoS | wiking: how are things? | 17:37 |
| @HeikoS | look what I just found, hahaha http://www.demiurge.technology/ | 17:37 |
| @HeikoS | wiking: lets talk later | 17:38 |
| @HeikoS | really gotta go | 17:38 |
| @HeikoS | ill be back in 2 hrs or so | 17:38 |
| @wiking | ok | 17:38 |
| @wiking | HeikoS: i'm UTC+8 | 17:38 |
| @wiking | so i probably wont be online anyore :( | 17:38 |
| @wiking | so from now on i'm again singapore timezone | 17:38 |
| @wiking | OXPHOS: 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 |
| @HeikoS | wiking: can talk tomorrow then | 17:39 |
| @wiking | kk | 17:40 |
| @wiking | sent you an email | 17:40 |
| @wiking | plz answer that asap | 17:40 |
| shogun-buildbot | build #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 |
| OXPHOS | wiking: I'm good for now. I'll work sth out today and ping you again. :) | 17:41 |
| @wiking | btw | 17:41 |
| @wiking | have we merged the cmake detection to the branch? | 17:41 |
| OXPHOS | wiking: yes | 17:42 |
| @wiking | ah yeah we did cool! | 17:42 |
| @wiking | thnx for doing the squashing | 17:42 |
| -!- sanuj [~sanuj@117.204.240.143] has joined #shogun | 17:42 | |
| OXPHOS | wiking: np. I have an open pr but I'll clean it up first and show you. | 17:42 |
| OXPHOS | lambday: there? unique_ptr still fails. | 17:43 |
| @wiking | src/shogun/lib/CerealTest.h | 17:43 |
| OXPHOS | https://gist.github.com/OXPHOS/89ad25db040852b5ea1add46d122a795 | 17:43 |
| @wiking | thi sis still a test? | 17:43 |
| @wiking | i mean i suppose you are moving this .h somewhere later? | 17:43 |
| @lambday | OXPHOS: let me check | 17:44 |
| OXPHOS | wiking: It's supposed to be in SGVector later. | 17:44 |
| OXPHOS | lambday: thx | 17:44 |
| @wiking | kk | 17:44 |
| OXPHOS | wiking: somehow Math.h or whatever confused current load and this one | 17:44 |
| OXPHOS | during compiling | 17:44 |
| sanuj | lisitsyn, there? | 17:45 |
| lisitsyn | yes | 17:45 |
| @lambday | OXPHOS: try adding the instantiation for int in base? | 17:45 |
| @lambday | as well as for gpuvector? | 17:45 |
| sanuj | lisitsyn, i got the hashing work exactly the way we want in a dummy | 17:45 |
| sanuj | was trying to do it in shogun | 17:45 |
| sanuj | getting an error | 17:45 |
| lisitsyn | what error? | 17:46 |
| OXPHOS | lambday: just to be sure - you mean the template struct GPU_Vector<int32_t> right? | 17:46 |
| @HeikoS | wiking: replied | 17:46 |
| @lambday | OXPHOS: yeah | 17:46 |
| sanuj | lisitsyn, http://pastebin.com/D6di2Ka1 | 17:47 |
| OXPHOS | lambday: it is there..so lemme move base to cpp too | 17:47 |
| @lambday | OXPHOS: let me try this in my machine | 17:47 |
| lisitsyn | sanuj: C++ exception with description "Bad cast toint but the type is shogun::Any::Empty" thrown in the test body. | 17:48 |
| sanuj | lisitsyn, yes | 17:48 |
| sanuj | lisitsyn, happened while doing EXPECT_EQ(gauss_kernel->get(distance), 10); | 17:48 |
| lisitsyn | sanuj: well need to check your code | 17:49 |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Quit: Leaving.] | 17:49 | |
| sanuj | lisitsyn, i'll push it on the pr | 17:49 |
| arianepaola | hi wiking | 17:49 |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has joined #shogun | 17:49 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 17:49 | |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Client Quit] | 17:50 | |
| OXPHOS | lambday: I got the same error even if I had template struct BaseVector<int32_t> and BaseVector in .cpp | 17:52 |
| -!- leagoetz [~leagoetz@nat-221-122.internal.eduroam.ucl.ac.uk] has joined #shogun | 17:55 | |
| @lambday | OXPHOS: works fine here - https://gist.github.com/lambday/123b97bfe6f15f98d0f7d24ce8dd35b5 | 17:56 |
| @lambday | OXPHOS: please paste working code in gist | 17:56 |
| sanuj | lisitsyn, https://github.com/shogun-toolbox/shogun/pull/3221 | 17:57 |
| @lambday | OXPHOS: did it work? | 17:59 |
| lisitsyn | sanuj: you didn't copy the hash | 17:59 |
| lisitsyn | neither in copy ctor, nor in assignment | 17:59 |
| sanuj | lisitsyn, oh, i'll fix it | 18:00 |
| sanuj | missed them by mistake | 18:01 |
| OXPHOS | lambday: on it | 18:01 |
| sanuj | didn't have a copy and assignment constructor in my dummy | 18:01 |
| OXPHOS | lambday: yes.. | 18:03 |
| @lambday | OXPHOS: what was the issue :) | 18:03 |
| OXPHOS | OXPHOS: how..Is there a difference between clang and g++? | 18:04 |
| OXPHOS | lambday:^ | 18:04 |
| @lambday | OXPHOS: I just checked with clang++ and even then it worked! | 18:05 |
| OXPHOS | lambday: Yeah me too..so I'll remove all other stuff and put them back in bit by bit | 18:06 |
| @lambday | OXPHOS: yeah that sounds good | 18:07 |
| -!- travis-ci [~travis-ci@ec2-54-163-137-83.compute-1.amazonaws.com] has joined #shogun | 18:08 | |
| travis-ci | it'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/134158086 | 18:08 |
| -!- travis-ci [~travis-ci@ec2-54-163-137-83.compute-1.amazonaws.com] has left #shogun [] | 18:08 | |
| shogun-buildbot | build #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 #shogun | 18: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 #shogun | 18:59 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 18:59 | |
| @wiking | HeikoS: so how's ccache? | 19:35 |
| @HeikoS | wiking: jo | 19:35 |
| @HeikoS | it is better | 19:36 |
| @HeikoS | BUT still annoys me | 19:36 |
| @HeikoS | that I cannot isolate my unit tests | 19:36 |
| @wiking | what's the output of ccache -s ? | 19:36 |
| @HeikoS | eats like 10s time everytime I check something | 19:36 |
| @HeikoS | 1. relinking of shogun 2. re-linking of unit tests | 19:36 |
| lisitsyn | HeikoS: is it about runtime | 19:36 |
| lisitsyn | or compile time | 19:36 |
| @HeikoS | compiling is fine now due to ccache | 19:36 |
| @HeikoS | even if I switch Debug/Release | 19:36 |
| @HeikoS | cache size 4.0 Gbytes | 19:37 |
| @HeikoS | max cache size 10.0 Gbytes | 19:37 |
| @HeikoS | wiking: so all good with that | 19:37 |
| lisitsyn | is it about running just a few tests? | 19:37 |
| @HeikoS | lisitsyn: no I do that | 19:37 |
| lisitsyn | is it about linking all tests? | 19:37 |
| @HeikoS | it is about the fact that I cannot isolate my stuff: my classes and my tests | 19:37 |
| lisitsyn | plugins | 19:37 |
| lisitsyn | :D | 19:37 |
| @HeikoS | but I think classes will be resoilved with plugiuns | 19:38 |
| @HeikoS | yeah | 19:38 |
| @HeikoS | and unit tests hopefully once the serialization is out | 19:38 |
| @HeikoS | though I dont see that yet tbh | 19:38 |
| @HeikoS | wiking: as we still need to test serialization right? | 19:38 |
| @HeikoS | wiking: 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 ones | 19:39 |
| @HeikoS | that would help | 19:39 |
| @HeikoS | lol my shogun code is 1000x faster than my "clever" python code | 19:40 |
| @HeikoS | lisitsyn: how are the plugins going? | 19:40 |
| lisitsyn | HeikoS: well it is about parameters yet | 19:41 |
| @HeikoS | parameters as in? | 19:41 |
| @HeikoS | btw you should also tell OXPHOS how the serialization will be done once the parameter maps are ready | 19:41 |
| lisitsyn | sure | 19:43 |
| lisitsyn | HeikoS: well sanuj on his way to integrate generic parameters into sgobject | 19:43 |
| lisitsyn | via map | 19:43 |
| lisitsyn | and tags | 19:43 |
| sanuj | lisitsyn, it's working now | 19:43 |
| sanuj | :) | 19:43 |
| lisitsyn | cool | 19:43 |
| sanuj | i'm testing them with T = SGVector | 19:43 |
| @HeikoS | lisitsyn: ah sooo good :) | 19:44 |
| @HeikoS | sanuj: lisitsyn please tell OXPHOS that | 19:44 |
| @HeikoS | because I told her to check Parameter.h | 19:44 |
| -!- lambday [8028b10a@gateway/web/freenode/ip.128.40.177.10] has quit [Quit: Page closed] | 19:44 | |
| sanuj | HeikoS, yes i'll | 19:44 |
| @HeikoS | sanuj: and you have a prototype right? | 19:45 |
| @HeikoS | share it | 19:45 |
| @HeikoS | and tell her that she can already think about cereal on this | 19:45 |
| sanuj | HeikoS, yes but i used aer | 19:45 |
| @HeikoS | thats fine | 19:45 |
| sanuj | The PR is enough for the prototype now | 19:45 |
| @HeikoS | just how the interface is | 19:45 |
| sanuj | I need to add swig interface | 19:45 |
| sanuj | which i will do tomorrow | 19:46 |
| sanuj | which i will do tomorrow | 19:46 |
| sanuj | oh sorry | 19:46 |
| sanuj | lisitsyn, i think sgvector is causing some trouble | 19:49 |
| sanuj | i'll look into this tomorrow | 19:49 |
| lisitsyn | ok | 19:49 |
| sanuj | gotta sleep | 19:49 |
| sanuj | lisitsyn, what time will you be here tomorrow | 19:49 |
| lisitsyn | probably starting from 8-9 UTC | 19:50 |
| sanuj | okay | 19:50 |
| sanuj | goodnight :) | 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 #shogun | 19:58 | |
| travis-ci | it'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/134191379 | 19: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 #shogun | 21:18 | |
| -!- lambday [56a397da@gateway/web/freenode/ip.86.163.151.218] has joined #shogun | 21:18 | |
| -!- mode/#shogun [+o lambday] by ChanServ | 21:18 | |
| OXPHOS | lambday: hey | 21:41 |
| @lambday | OXPHOS: yo | 21:41 |
| OXPHOS | lambday: aha you're still here! | 21:42 |
| OXPHOS | lambday: so I changed the constructor you wrote to GPUVector(int a); | 21:42 |
| OXPHOS | and did int main() { GPUVector<int> vec(5); return 0; } | 21:43 |
| OXPHOS | got 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 |
| @lambday | OXPHOS: as in, vector length 5 | 21:43 |
| @lambday | ? | 21:43 |
| -!- OXPHOS_ [9d8b1501@gateway/web/freenode/ip.157.139.21.1] has joined #shogun | 21: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_ | test | 21:49 |
| -!- lambday [56a397da@gateway/web/freenode/ip.86.163.151.218] has joined #shogun | 21:49 | |
| -!- mode/#shogun [+o lambday] by ChanServ | 21:49 | |
| @lambday | OXPHOS_: works fine here | 21:49 |
| OXPHOS_ | lambday: can I send you the exact scripts I'm trying to run and you try again? | 21:50 |
| @lambday | OXPHOS_: yes.. | 21:51 |
| @lambday | that's what I have been saying :D | 21:51 |
| @lambday | upload/send exact thing :D | 21:51 |
| OXPHOS_ | lambday: my bad .. https://gist.github.com/a70af5c8945befc8915d143e5c5d4b8e.git | 21:53 |
| @lambday | OXPHOS_: you haven't instantiated GPUVector<int> yet | 21:55 |
| @lambday | OXPHOS_: try this: put the main function in a separate file | 21:55 |
| @lambday | instantiate the templates (maybe just for int/double) - put those within shogun namespace | 21:55 |
| @lambday | instantiate the templates (maybe just for int/double) - put those within shogun namespace | 21:57 |
| -!- lambday_ [56a397da@gateway/web/freenode/ip.86.163.151.218] has joined #shogun | 21:58 | |
| -!- mode/#shogun [+o lambday_] by ChanServ | 21:59 | |
| OXPHOS_ | lambday: done. | 21:59 |
| @lambday_ | OXPHOS_: and? | 21:59 |
| OXPHOS_ | lambday: sry 1sec | 22: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 linalg | 22: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 gist | 22:07 |
| @lambday_ | OXPHOS_: works? | 22:07 |
| OXPHOS_ | doesn't seem to help | 22:07 |
| OXPHOS_ | the same error | 22:07 |
| @lambday_ | strange! | 22:08 |
| @lambday_ | let me download your code | 22:08 |
| OXPHOS_ | thx | 22:10 |
| @lambday_ | okay your version has an error.. my version didn't have.. | 22:12 |
| @lambday_ | checking | 22:12 |
| @lambday_ | OXPHOS_: https://gist.github.com/OXPHOS/a70af5c8945befc8915d143e5c5d4b8e#file-linalg-h-L22 | 22:17 |
| @lambday_ | this should be std::unique_ptr<GPUArray> :P | 22:17 |
| OXPHOS_ | ... | 22:18 |
| OXPHOS_ | so sorry about this | 22:18 |
| @lambday_ | OXPHOS_: don't worry | 22:18 |
| @lambday_ | OXPHOS_: make sure it works | 22:18 |
| OXPHOS_ | But in the "real" linalg code the unique_ptr was correct, and it still gave error.. lemme check again | 22:19 |
| @lambday_ | OXPHOS_: yeah... | 22:20 |
| @lambday_ | refactor one class (split into header+cpp), update the PR, repeat | 22:20 |
| @lambday_ | make one changes at a time.. | 22:20 |
| @lambday_ | should work | 22: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.git | 22: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 #shogun | 23:01 | |
| travis-ci | it'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/134233169 | 23: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 one | 23:03 |
| @lambday_ | OXPHOS_: why does the main function has to be within shogun namespace? | 23:04 |
| OXPHOS_ | lambday_: it doesn't | 23:04 |
| @lambday_ | OXPHOS_: https://gist.github.com/OXPHOS/a70af5c8945befc8915d143e5c5d4b8e#file-main-cpp-L2 | 23: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 error | 23: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 there | 23:08 |
| @lambday_ | so make a small change, compile and make sure it still works, commit, repeat | 23:09 |
| OXPHOS_ | I just feel the current working PR and the opaque pointer I'm writing now is too different | 23:09 |
| OXPHOS_ | i mean, if it works, there's no diff | 23:09 |
| OXPHOS_ | but now for some reason it doesn't. so I have only the 'opaque pointer' part | 23: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 first | 23:10 |
| @lambday_ | make sure at least that works | 23:10 |
| @lambday_ | because the original PR works, right? | 23:11 |
| OXPHOS_ | right | 23: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 gpuptr | 23: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 it | 23: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 |
| lisitsyn | I heard raw pointer! | 23:14 |
| @lambday_ | lisitsyn: sleep :P | 23:14 |
| lisitsyn | sorry | 23:14 |
| @lambday_ | lisitsyn: hehehe | 23:14 |
| OXPHOS_ | bugged | 23:14 |
| lisitsyn | raw pointer police | 23:14 |
| OXPHOS_ | lisitsyn: they won't be merged | 23:15 |
| @lambday_ | lisitsyn: don't hate 'em so much.. herb said they are perfectly good :D | 23:15 |
| @lambday_ | OXPHOS_: which one you want me to try? | 23:15 |
| lisitsyn | yes inside some functions | 23:15 |
| @lambday_ | lisitsyn: yes | 23:15 |
| @lambday_ | don't worry she's gonna use unique_ptr :) | 23:15 |
| OXPHOS_ | lambday_: https://gist.github.com/a70af5c8945befc8915d143e5c5d4b8e.git | 23:15 |
| OXPHOS_ | thx | 23:15 |
| OXPHOS_ | now I kinda hate unique_ptr | 23:15 |
| @lambday_ | OXPHOS_: noooooooo :'( | 23:16 |
| lisitsyn | why so | 23:16 |
| @lambday_ | don't hate | 23:16 |
| lisitsyn | you gonna hate everything debugging your pointers :D | 23: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 else | 23: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 error | 23:18 |
| OXPHOS_ | for the moment | 23: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, voila | 23:19 |
| OXPHOS_ | I did g++ -c -std=c++11 -I. main.cpp -lshogun | 23:19 |
| @lambday_ | it didn't work? | 23:20 |
| @lambday_ | interesting | 23: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 check | 23:20 |
| -!- travis-ci [~travis-ci@ec2-54-224-204-201.compute-1.amazonaws.com] has joined #shogun | 23:27 | |
| travis-ci | it'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/134236526 | 23: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 #shogun | 23: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 ago | 23:36 |
| OXPHOS_ | 17h | 23:36 |
| @lambday_ | OXPHOS_: usually it is something stupid like that | 23:37 |
| OXPHOS_ | :( | 23:38 |
| @lambday_ | OXPHOS_: don't worry.. check a bit | 23:38 |
| OXPHOS_ | thx | 23:39 |
| --- Log closed Wed Jun 01 00:00:20 2016 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!