| --- Log opened Fri Jun 10 00:00:03 2016 | ||
| --- Day changed Fri Jun 10 2016 | ||
| @lambday | OXPHOS: well, ENABLE_GPULIB thing has to go.. | 00:00 |
|---|---|---|
| @lambday | OXPHOS: now we have register_backend thing | 00:00 |
| OXPHOS | but users will have another input ENABLE_GPU_CALCULATION, to ask Shogun to choose from any GPULIB if there is any | 00:00 |
| OXPHOS | ha | 00:00 |
| @lambday | if there are two gpu backends, users can only register one | 00:00 |
| @lambday | whichever is registered, that is enabled - that should be the principle | 00:01 |
| OXPHOS | will shogun throw errors if user try to register two? | 00:01 |
| OXPHOS | these will all be in cmake right | 00:02 |
| @lambday | OXPHOS: well, we should decide that a bit carefully.. say, for a part of his application, he wants to use viennacl.. so he registers that.. then in some later part of the code he wants to use CUDA.. so he registers that | 00:03 |
| @lambday | umm.. not sure about that | 00:03 |
| @lambday | OXPHOS: shouldn't it be from code itself? | 00:03 |
| @lambday | cmake would just find supported libs | 00:03 |
| @lambday | well, no.. maybe you have a point | 00:04 |
| OXPHOS | lambday: well if it can be changed..guess a global variable would work? | 00:04 |
| @lambday | OXPHOS: global variable for what? | 00:04 |
| OXPHOS | gpubackend | 00:05 |
| @lambday | OXPHOS: we already have that inside sg_linalg.m_gpubackend, no? | 00:05 |
| @lambday | that's pretty global :D | 00:05 |
| OXPHOS | lambday: yeah you'r right. It is actually global because of sg_linalg. So since there's only one SGLinalg, there IS only one GPUBackend at one time | 00:06 |
| @lambday | OXPHOS: in my mind, registering backend was about setting this m_gpubackend.. | 00:06 |
| @lambday | OXPHOS: but not sure whether a cmake option could be set.. | 00:06 |
| @lambday | something like, if cmake finds any supported gpu backend, that thing gets registered automatically.. | 00:07 |
| @lambday | so if there are multiple, there has to be a priority - which one to use as default | 00:07 |
| @lambday | but the user should always be able to change this using sg_linalg.register_gpu_backend | 00:07 |
| OXPHOS | there's a problem with current m_gpubackend | 00:09 |
| @lambday | OXPHOS: which is? | 00:09 |
| OXPHOS | it can be named whatever | 00:09 |
| @lambday | huh? | 00:09 |
| OXPHOS | like whatever library you try to register , it'll stay the same | 00:10 |
| lisitsyn | unique! | 00:10 |
| lisitsyn | ok let me try to fix it | 00:10 |
| @lambday | but you changed it to shared ptr, no? | 00:10 |
| OXPHOS | juj? | 00:10 |
| OXPHOS | huh? | 00:10 |
| OXPHOS | i mean | 00:10 |
| @lambday | lisitsyn: haha sleeping tiger woke up :D | 00:11 |
| lisitsyn | JA | 00:11 |
| OXPHOS | now GPUBackend.dot() is now #ifdef HAVE_VIENNACL, do blabla; #elif HAVE_CUDA, do blabla | 00:11 |
| @lambday | hah my Indian language background always makes me read things exactly as they are spelled :D | 00:11 |
| @lambday | if someone says ja, I actually ja instead of ha xD | 00:12 |
| @lambday | I actually read** | 00:12 |
| OXPHOS | jo | 00:12 |
| @lambday | jabit, jou see | 00:12 |
| @lambday | surprisingly, j = h, and j = y | 00:12 |
| @lambday | sanskrit doesn't have that :D | 00:13 |
| OXPHOS | wow | 00:13 |
| @lambday | hah my Indian language background always makes me read things exactly as they are spelled :D | 00:13 |
| OXPHOS | jeah i know there're several languages(?) in India | 00:14 |
| OXPHOS | never know the difference :) | 00:14 |
| @lambday | OXPHOS: neither do we :D | 00:14 |
| OXPHOS | jajaja | 00:14 |
| @lambday | I myself know like 3 of them | 00:14 |
| @lambday | hah my Indian language background always makes me read things exactly as they are spelled :D | 00:14 |
| @lambday | well, 2.67 to be exact | 00:15 |
| OXPHOS | coooool | 00:15 |
| OXPHOS | I have a friend from India who only speaks English | 00:15 |
| @lambday | I know, right? B-) | 00:15 |
| @lambday | OXPHOS: he's lying | 00:15 |
| @lambday | she's lying? :/ | 00:16 |
| @lambday | ah english needs a gender neutral pronoun | 00:16 |
| OXPHOS | really - she said English is her first language - might not be the only one | 00:17 |
| OXPHOS | we distinguish that in Chinese also. only in written. weird | 00:17 |
| @lambday | OXPHOS: I am yet to see an Indian (who stayed in India) whose first language is English.. | 00:18 |
| OXPHOS | I'll question her next time;) | 00:19 |
| @lambday | OXPHOS: just ask which part of India she's from and I'll tell you her native language ;) | 00:19 |
| @lambday | (almost) every state has a different one | 00:20 |
| OXPHOS | so you all speak english | 00:20 |
| OXPHOS | born bilingual | 00:21 |
| OXPHOS | but anyway - it doesn't matter how many gpubackend you try to register now, they will be the SAME one | 00:22 |
| OXPHOS | because the switch between backends is dependent on #ifdef HAVE_GPULIB, which is set at cmake | 00:23 |
| @lambday | OXPHOS: no! there can be multiple of those.. but at a given point there can be only one | 00:23 |
| @lambday | see what I mean? | 00:23 |
| @lambday | so thing to keep in mind - make register_gpu_backend() and register_cpu_backend() thread safe | 00:24 |
| @lambday | OXPHOS: ^ | 00:24 |
| @lambday | very important! | 00:24 |
| OXPHOS | i see | 00:24 |
| OXPHOS | BUT say you're now (supposed to be) using ViennaCL gpubackend and you want to switch to CUDA, how can you do that? | 00:26 |
| @lambday | also, I am trilingual actually.. hindi, bengali and english.. a bit punjabi.. can understand gujarati, assamese, oriya, marathi.. xD | 00:26 |
| @lambday | OXPHOS: sg_linalg.register_gpu_backend(new CUDABackend()) or something | 00:27 |
| lisitsyn | I am half lingual | 00:27 |
| lisitsyn | :D | 00:27 |
| @lambday | ah I see what you mean | 00:27 |
| @lambday | OXPHOS: so the pimpl allows you to have only one impl at a time due to those ifdefs | 00:28 |
| OXPHOS | you speak C++, python, bash ... | 00:28 |
| @lambday | OXPHOS: when lisitsyn was born, his first words here `std::cout << "hello world!" << std::endl;' | 00:28 |
| lisitsyn | do you know what's the best interview question on sed? | 00:28 |
| OXPHOS | lol | 00:29 |
| OXPHOS | no | 00:29 |
| lisitsyn | do you know some sed? | 00:29 |
| @lambday | lisitsyn: you're asking or you're about to tell yourself? | 00:29 |
| lisitsyn | THEN | 00:29 |
| lisitsyn | if he/she knows reject | 00:29 |
| lisitsyn | because he is going to write everything in sed | 00:29 |
| lisitsyn | :D | 00:29 |
| lisitsyn | object relational mapping? sounds like a good sed task | 00:29 |
| @lambday | lisitsyn: haha xD | 00:30 |
| OXPHOS | whaaaaat | 00:30 |
| OXPHOS | i can guess the point.. | 00:31 |
| OXPHOS | lambday: yeah i think so.. I mean it is "static" actually. there's no CUDABackend(). there's only one GPUBackend() which can work with whatever GPUlibrary Shogun can use. | 00:31 |
| OXPHOS | not whatever the users wants to work with | 00:31 |
| @lambday | OXPHOS: yeah I see.. so it doesn't support multiple backends yet.. | 00:32 |
| @lambday | maybe we should support them later | 00:32 |
| OXPHOS | yes I think this is another branch | 00:33 |
| @lambday | OXPHOS: not too hard to change that.. basically what we have to do is to make GPUBackend a base class.. and provide different impls like ViennaCLBackend, CUDABackend etc.. | 00:33 |
| @lambday | but that's not the focus for now | 00:33 |
| OXPHOS | agree | 00:34 |
| OXPHOS | lambday: we were talking about the GPU_CALCULATION stuff.. so I'll leave it there for now? | 00:34 |
| @lambday | maybe we'll never support naked cuda.. | 00:34 |
| @lambday | :D | 00:34 |
| @lambday | OXPHOS: I didn't fully get what you wanted to do with this macro :( | 00:35 |
| @lambday | why would this be needed again? | 00:35 |
| OXPHOS | let's say shogun support GPULIB1 and 2. The user has GPULIB1 and 2. The user registered GPULIB1. but for some reason, he doesn't want to use GPUBackend for calculation | 00:36 |
| @lambday | OXPHOS: this problem will be solved **if** we allow them to register different backends.. | 00:37 |
| @lambday | as long as that is not supported, this is not possible | 00:37 |
| OXPHOS | okay so i can just use HAVE_VIENNACL for now | 00:37 |
| @lambday | OXPHOS: yeah that should be fine.. | 00:38 |
| OXPHOS | not fancy :) | 00:38 |
| @lambday | haha | 00:38 |
| @lambday | well it's easy to change that you see. | 00:38 |
| OXPHOS | agree | 00:39 |
| @lambday | (a) make GPUBackend an abstract base class (b) provide a subclass ViennaCLBackend as a concrete impl.. do the ifdefs there | 00:39 |
| @lambday | not in the header though | 00:40 |
| @lambday | so ViennaCLBackend would be what you have as GPUBackend for now | 00:40 |
| @lambday | pimpl.. and throws error if no viennacl is found | 00:41 |
| @lambday | actually you know what, I like this idea! | 00:41 |
| OXPHOS | metoo | 00:42 |
| @lambday | so sg_linalg.m_gpubackend would be of type shared_ptr<GPUBackend>, and when the user registers, he does sg_linalg.register_gpu_backend(new ViennaCLBackend()) | 00:42 |
| OXPHOS | very "engineering" | 00:42 |
| @lambday | now if that bastard doesn't have viennacl in the first place, we fail him in the constructor itself | 00:43 |
| @lambday | but it all has to be pimpl | 00:43 |
| @lambday | lisitsyn: ^ could you please comment? | 00:44 |
| @lambday | OXPHOS: his brain is doing something `unique' at this moment I can imagine | 00:45 |
| OXPHOS | lambday: raw pointer | 00:45 |
| OXPHOS | see whether this works ;) | 00:45 |
| @lambday | tag him | 00:45 |
| @lambday | then it will xD | 00:45 |
| OXPHOS | lol | 00:46 |
| OXPHOS | so i can do now a. refactor gpubackend class; b. add other SGVector methods; c. add BaseMatrix/CPUMatrix/GPUMatrix.. | 00:46 |
| OXPHOS | any priority? | 00:46 |
| @lambday | OXPHOS: what do you mean by other SGVector methods | 00:47 |
| @lambday | ? | 00:47 |
| OXPHOS | like sum/mean | 00:47 |
| @lambday | as in mean(), l2norm() etc? | 00:47 |
| @lambday | I see | 00:47 |
| @lambday | yeah so I'll say, b, c, a | 00:48 |
| @lambday | but if lisitsyn replies quickly, then maybe a next if you want | 00:48 |
| @lambday | ;) | 00:48 |
| @lambday | lisitsyn: CAnIdea* idea = new CAnIdea(); | 00:49 |
| OXPHOS | jaja | 00:49 |
| OXPHOS | yes the tons of methods in linalg should all be migrated someday | 00:50 |
| @lambday | OXPHOS: we only have a few there ;) | 00:52 |
| @lambday | OXPHOS: we gotta add many more | 00:52 |
| OXPHOS | lambday: the kilograms of methods ;) | 00:53 |
| @lambday | OXPHOS: hah one problem with making GPUBackend an abstract class is that we gotta make the methods virtual.. which is not possible since those are templates | 01:01 |
| @lambday | OXPHOS: maybe it is not as straightforward as I thought.. | 01:01 |
| @lambday | so let's not worry about that now | 01:02 |
| @lambday | maybe we can use Any :/ | 01:03 |
| @lambday | yeah Any would work.. the calls are going through SGLinalg anyway.. so in that we just to recall_type | 01:04 |
| @lambday | cool! | 01:05 |
| -!- lambday [6d9941c0@gateway/web/freenode/ip.109.153.65.192] has quit [Ping timeout: 250 seconds] | 01:11 | |
| -!- lambday [6d9941c0@gateway/web/freenode/ip.109.153.65.192] has joined #shogun | 01:13 | |
| -!- mode/#shogun [+o lambday] by ChanServ | 01:13 | |
| -!- lambday [6d9941c0@gateway/web/freenode/ip.109.153.65.192] has quit [Ping timeout: 250 seconds] | 01:17 | |
| -!- OXPHOS [9d8b1501@gateway/web/freenode/ip.157.139.21.1] has quit [Ping timeout: 250 seconds] | 01:36 | |
| -!- mizari [~mizari@95-174-213-100.nts.su] has joined #shogun | 03:22 | |
| -!- sonne|work [~sonnenbu@88.134.176.135] has quit [Quit: Leaving.] | 08:40 | |
| -!- sonne|work [~sonnenbu@88.134.176.135] has joined #shogun | 08:41 | |
| -!- sanuj [~sanuj@59.91.134.74] has joined #shogun | 08:41 | |
| -!- sanuj [~sanuj@59.91.134.74] has quit [Ping timeout: 260 seconds] | 09:03 | |
| -!- sanuj [~sanuj@59.91.134.74] has joined #shogun | 09:33 | |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has joined #shogun | 09:39 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 09:39 | |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Client Quit] | 09:40 | |
| @wiking | Saurabh7: here? | 10:36 |
| Saurabh7 | wiking: yes | 10:40 |
| Saurabh7 | hi | 10:40 |
| @wiking | Saurabh7: ok so | 10:42 |
| @wiking | would it be hard to extends for example | 10:42 |
| @wiking | the LARS (or any other benchmarks) with mem usage? | 10:42 |
| Saurabh7 | wiking: not sure, how would you check for this one ? | 10:43 |
| Saurabh7 | if you point me somewher i can do | 10:43 |
| Saurabh7 | how done till now | 10:43 |
| Saurabh7 | havent* | 10:43 |
| Saurabh7 | btw for lars I used a bufer matrix to acces active columns runtiem went form 18 -> 12 | 10:44 |
| Saurabh7 | I am extending it for inactive colmns too, it should go lower | 10:45 |
| @wiking | \p/ | 10:45 |
| @wiking | ok i'll try to put together a small howto | 10:45 |
| @wiking | for measuring mem usage of things | 10:45 |
| @wiking | ok? | 10:45 |
| @wiking | because actually that'd be interesting as well | 10:45 |
| Saurabh7 | yes definetly | 10:45 |
| Saurabh7 | wiking: I used this for kmeans once https://pypi.python.org/pypi/memory_profiler | 10:49 |
| Saurabh7 | I can try this dunno if its reliable | 10:50 |
| @wiking | :S | 10:56 |
| -!- HeikoS_mobile [~Mutter@82-132-215-195.dab.02.net] has joined #shogun | 10:58 | |
| HeikoS_mobile | wiking: jo | 10:59 |
| Saurabh7 | HeikoS_mobile: hi | 11:04 |
| HeikoS_mobile | Saurabh7: Ho | 11:05 |
| HeikoS_mobile | I'm on phone in train | 11:05 |
| Saurabh7 | HeikoS_mobile: I used yesterdays idea to remove loops, got good gains | 11:05 |
| HeikoS_mobile | So limited typing | 11:05 |
| HeikoS_mobile | Really? | 11:05 |
| HeikoS_mobile | Great!! | 11:05 |
| Saurabh7 | yes | 11:05 |
| HeikoS_mobile | Got some numbers? | 11:05 |
| HeikoS_mobile | Before/after? | 11:06 |
| Saurabh7 | yesyes | 11:06 |
| Saurabh7 | let me put in the thread ? | 11:06 |
| Saurabh7 | Now I ahve to use it for inactive columns aswell | 11:06 |
| Saurabh7 | that will remove teh last loop | 11:06 |
| HeikoS_mobile | Cool | 11:06 |
| HeikoS_mobile | Memcpy is fast :) | 11:07 |
| Saurabh7 | HeikoS_mobile: Didnt ahve to use memcpy | 11:07 |
| sanuj | HeikoS_mobile, hey | 11:08 |
| sanuj | HeikoS_mobile, when will you have your laptop? we need to merge some PRs today..... | 11:09 |
| -!- HeikoS_mobile [~Mutter@82-132-215-195.dab.02.net] has quit [Quit: Mutter: www.mutterirc.com] | 11:10 | |
| -!- HeikoS_mobile [~Mutter@82-132-215-195.dab.02.net] has joined #shogun | 11:17 | |
| -!- besser82 [~besser82@fedora/besser82] has joined #shogun | 11:20 | |
| -!- mode/#shogun [+o besser82] by ChanServ | 11:20 | |
| sanuj | HeikoS_mobile, hey | 11:21 |
| -!- HeikoS_mobile [~Mutter@82-132-215-195.dab.02.net] has quit [Remote host closed the connection] | 11:23 | |
| -!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 260 seconds] | 11:27 | |
| -!- HeikoS_mobile [~Mutter@82-132-215-195.dab.02.net] has joined #shogun | 11:31 | |
| HeikoS_mobile | sanuj: will merge things later today | 11:31 |
| sanuj | HeikoS_mobile, okay! | 11:32 |
| HeikoS_mobile | Saurabh7: can you send me an email with the numbers? Sorry I have a laggy connection | 11:32 |
| HeikoS_mobile | There is still a proven with r and static calls unfortunately, I might just disable it for now if I can't fix | 11:32 |
| -!- HeikoS_mobile [~Mutter@82-132-215-195.dab.02.net] has quit [Remote host closed the connection] | 11:35 | |
| -!- sanuj [~sanuj@59.91.134.74] has quit [Ping timeout: 264 seconds] | 12:02 | |
| -!- sanuj [~sanuj@117.203.17.165] has joined #shogun | 12:15 | |
| sanuj | hey lisitsyn | 12:56 |
| sanuj | got time? | 12:56 |
| arianepaola | hello everyone | 13:46 |
| @wiking | hihi | 13:55 |
| arianepaola | hi wiking | 13:57 |
| arianepaola | wiking: did you check the gist, I sent yesterday | 13:58 |
| @wiking | mmm sorry remember i'm utc+8 | 13:59 |
| @wiking | so i think i've missed it | 13:59 |
| arianepaola | no problem | 14:00 |
| arianepaola | I will check in the logs | 14:00 |
| @wiking | can you paste again? | 14:00 |
| @wiking | https://gist.github.com/anonymous/c3dfeb456656dd3b468fd7bc91b02058 | 14:00 |
| @wiking | right? | 14:00 |
| @wiking | \p/ | 14:01 |
| arianepaola | wiking: when you have time, check this gist https://gist.github.com/anonymous/c3dfeb456656dd3b468fd7bc91b0205818:15 | 14:01 |
| arianepaola | wiking: the setup.py in the PR overloads functionality from distutils to bootstrap the cmake configuration process and the compilation18:17 | 14:01 |
| arianepaola | wiking: the gist just deals with the Python related content in lib. you can test it building shogun manually and then in the build dir: python setup.py bdist | 14:01 |
| arianepaola | arianepaola^^ HeikoS: if you want to check also | 14:01 |
| @wiking | this looks awseom | 14:01 |
| @wiking | great | 14:01 |
| @wiking | what happens on sdist? :) | 14:01 |
| arianepaola | it packs the files | 14:02 |
| @wiking | but anyhow this is great stuff! | 14:02 |
| arianepaola | but you can specify with MANIFEST.in | 14:02 |
| @wiking | because actually we can add to the repo a setup.py.in | 14:02 |
| @wiking | right? | 14:02 |
| @wiking | that cmake can generate the right one | 14:02 |
| arianepaola | in the logs, starting 14:41 http://www.shogun-toolbox.org/irclogs/%23shogun.2016-06-09.log.html | 14:02 |
| @wiking | (see version) | 14:02 |
| @wiking | i'm just wondering what would be the best way to distribute the setup.py | 14:03 |
| arianepaola | the PR with the cmake bootstrap overwrites distutils classes and this gist uses minimal of setuptools to make it work | 14:03 |
| arianepaola | so I have to test line by line and see where each one breaks | 14:03 |
| @wiking | and not hardcode the version and stuff in it | 14:03 |
| arianepaola | just put setup.py in the repo | 14:03 |
| @wiking | yep but then what do we do with VERSION | 14:03 |
| @wiking | now it's hardcoded | 14:04 |
| @wiking | ideally it shouldn't be :) | 14:04 |
| @wiking | mmm we could use the regexp | 14:04 |
| @wiking | that cmake uses | 14:04 |
| @wiking | to get the version, right? | 14:04 |
| arianepaola | for the version I had this question yesterday: | 14:04 |
| arianepaola | arianepaolalisitsyn: hi, I have a question regarding src/shogun/lib/versionstring.h | 14:04 |
| arianepaola | arianepaolalisitsyn: is there a way to check if we are using git source? e.g. will the version change for a Release version? | 14:04 |
| arianepaola | arianepaolaI want only to append the info from #define VERSION_REVISION 0x83970a7 when it is a development version | 14:04 |
| arianepaola | if setuptools does not complain, reading the file and a regular expression matching the version should work | 14:05 |
| arianepaola | it depends on when setuptools gets the version, e.g. variable content passed | 14:06 |
| arianepaola | I think at the end when bdist, but then we have to check for sdist | 14:06 |
| @wiking | cmake/version.cmake | 14:06 |
| @wiking | so as you can see | 14:07 |
| @wiking | if there's no .git | 14:07 |
| @wiking | then we use NEWS info | 14:07 |
| @wiking | to fill out those macros | 14:07 |
| arianepaola | yes | 14:08 |
| arianepaola | then the result goes in src/shogun/lib/versionstring.h, right? | 14:08 |
| @wiking | yes | 14:09 |
| arianepaola | regarding cmake generating the setup.py | 14:09 |
| arianepaola | setup.py bootstraps cmake | 14:10 |
| arianepaola | so if it should generate from setup.py.in, it would be: cmake -> setup.py -> cmake -> make -> package | 14:10 |
| arianepaola | if it works to read the versionstring, without setuptools complaining | 14:10 |
| arianepaola | setup.py -> cmake -> make -> package | 14:10 |
| arianepaola | wiking: other idea for version passing to setuptools is to pass the return of a method to version | 14:13 |
| arianepaola | wiking: this method then can check if cmake was run already or not, then run build, for the build step it will just check if cmake was configure to avoid double work | 14:14 |
| @wiking | mmm | 14:15 |
| @wiking | yeah this is a bit problematic :S | 14:15 |
| @wiking | or just we keep rolling the static version line there in setup.py | 14:15 |
| @wiking | when we do a release | 14:15 |
| @wiking | ? | 14:15 |
| @wiking | :) | 14:15 |
| @wiking | bit ugly because you need to do then the double the work | 14:16 |
| @wiking | but i think reading file + regex for a version | 14:16 |
| @wiking | should be ok from setuptools or? | 14:16 |
| arianepaola | yes | 14:17 |
| arianepaola | but it depends when setuptools fills in the version | 14:17 |
| arianepaola | so probably it will be versio = get_shogun_version() | 14:17 |
| arianepaola | get_shogun_version(): | 14:18 |
| arianepaola | if ran_cmake: return parse_version_string() | 14:18 |
| arianepaola | else: run_cmake() + return parse_version_string() | 14:19 |
| arianepaola | ^^ wiking: something like this should work | 14:19 |
| arianepaola | wiking: but hey, only setuptools knows :-) | 14:20 |
| arianepaola | I am going to work on this part now | 14:20 |
| @wiking | thnx | 14:21 |
| @wiking | cool | 14:21 |
| @wiking | good work keep up with it! | 14:21 |
| arianepaola | I will update the gist | 14:21 |
| sanuj | lisitsyn, there? | 15:17 |
| lisitsyn | sanuj: yeap | 15:17 |
| sanuj | lisitsyn, can you have a look at this https://github.com/sanuj/shogun/commit/45104a01513eb315f847b5e89815caad11361c29 | 15:18 |
| sanuj | this is not working for python | 15:18 |
| lisitsyn | I can't guess anything from what you said :D | 15:19 |
| sanuj | lisitsyn, any tag and get/set are not visible in python | 15:20 |
| sanuj | any, tag* | 15:20 |
| sanuj | it build succesfully (without errors) but above things are not visible in python | 15:23 |
| sanuj | like if i do | 15:23 |
| lisitsyn | ok ok interesting | 15:23 |
| sanuj | lisitsyn, what do you think am I missing? | 15:25 |
| lisitsyn | sanuj: comparing to other template swig things | 15:27 |
| lisitsyn | it looks correct | 15:28 |
| sanuj | lisitsyn, how to debug this? | 15:28 |
| sanuj | lisitsyn, this was working with my prototype | 15:28 |
| lisitsyn | sanuj: are you sure there is nothing in logs? | 15:35 |
| lisitsyn | warnings anything? | 15:35 |
| sanuj | lisitsyn, oh i think i exported the wrong path | 15:36 |
| sanuj | let me check | 15:36 |
| lisitsyn | and please show me how you call that | 15:36 |
| sanuj | lisitsyn, sorry :D | 15:38 |
| sanuj | it was the wrong path | 15:38 |
| sanuj | lisitsyn, call what? | 15:38 |
| arianepaola | wiking: what do you think? https://gist.github.com/arianepaola/96c9255ec9594a1140fd5d655dbada13 | 15:41 |
| sanuj | lisitsyn, got time to chat about some details? | 15:41 |
| arianepaola | wiking: it gets the version now, but strangely it stopped packaging the rest of the modules | 15:42 |
| -!- OXPHOS` [9d8b131c@gateway/web/freenode/ip.157.139.19.28] has joined #shogun | 16:24 | |
| OXPHOS` | wiking: there? | 16:42 |
| -!- HeikoS_mobile [~Mutter@82-132-230-6.dab.02.net] has joined #shogun | 16:49 | |
| HeikoS_mobile | sanuj: Saurabh7: back soon | 16:50 |
| HeikoS_mobile | Saurabh7: where are the new times? Couldn't find | 16:50 |
| sanuj | HeikoS_mobile, will be back in 20 mins | 16:51 |
| -!- sanuj [~sanuj@117.203.17.165] has quit [Quit: Leaving] | 16:53 | |
| @wiking | yes | 16:55 |
| @wiking | soert of | 16:55 |
| -!- HeikoS_mobile_ [~Mutter@82-132-230-6.dab.02.net] has joined #shogun | 16:58 | |
| -!- HeikoS_mobile [~Mutter@82-132-230-6.dab.02.net] has quit [Ping timeout: 276 seconds] | 16:58 | |
| -!- HeikoS_mobile_ [~Mutter@82-132-230-6.dab.02.net] has quit [Remote host closed the connection] | 17:01 | |
| -!- sanuj [~sanuj@117.203.17.165] has joined #shogun | 17:24 | |
| arianepaola | wiking: what do you think? https://gist.github.com/arianepaola/96c9255ec9594a1140fd5d655dbada13 | 17:28 |
| -!- lambday [6d9941c0@gateway/web/freenode/ip.109.153.65.192] has joined #shogun | 17:30 | |
| -!- mode/#shogun [+o lambday] by ChanServ | 17:30 | |
| @wiking | looks good | 17:38 |
| @wiking | OXPHOS`: ping | 17:40 |
| @wiking | arianepaola: but we should use maybe rather NEWS to do the regex | 17:40 |
| @wiking | as the version string into the versionstring.h is being generated from there | 17:41 |
| OXPHOS` | wiking: hey | 17:41 |
| OXPHOS` | wiking: for the comments in linalg | 17:41 |
| OXPHOS` | do you mean we don't have to distinguish CPU/GPU Vector? | 17:42 |
| arianepaola | wiking: versionstring.h is probably less error prone, as cmake runs anyway before | 17:42 |
| @wiking | arianepaola: yeah but in this case you wouldnt need to have cmake run prior to this | 17:51 |
| @wiking | OXPHOS`: i was just wondering what is the reason for distinguishing | 17:52 |
| OXPHOS` | wiking: Yeah actually I can't think of any now.. | 17:54 |
| arianepaola | wiking: I thought that also, but it is needed for the module content | 17:54 |
| arianepaola | package_dir and adata_files | 17:55 |
| arianepaola | can only be generated after running cmake | 17:55 |
| arianepaola | wiking: leading to a chicken or the egg problem | 17:56 |
| @wiking | OXPHOS`: ok then | 17:59 |
| -!- HeikoS [~heiko@nat-173-117.internal.eduroam.ucl.ac.uk] has joined #shogun | 18:01 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 18:01 | |
| @HeikoS | Saurabh7: hi! | 18:01 |
| @HeikoS | sanuj: hi! | 18:01 |
| @HeikoS | arianepaola: hi! | 18:01 |
| @HeikoS | OXPHOS`: hi! | 18:01 |
| sanuj | HeikoS, yooooo!! | 18:01 |
| @HeikoS | now back on computer | 18:01 |
| @HeikoS | with some time | 18:02 |
| arianepaola | hi HeikoS | 18:02 |
| @HeikoS | arianepaola: hi! how are things going on your side? | 18:02 |
| arianepaola | good | 18:02 |
| sanuj | HeikoS, https://github.com/shogun-toolbox/shogun/pull/3276 | 18:02 |
| arianepaola | https://gist.github.com/arianepaola/96c9255ec9594a1140fd5d655dbada13 | 18:02 |
| OXPHOS` | hello HeikoS | 18:03 |
| @HeikoS | OXPHOS`: hi how are things going? | 18:03 |
| arianepaola | HeikoS: the mini version can detect now the shogun version. somehow it is now missing the module files, that I am looking into. the previous gist included them. | 18:04 |
| arianepaola | HeikoS: then I can merge it with the cmake bootstrapping code | 18:04 |
| @HeikoS | arianepaola: cool about the version, checking the gist atm | 18:04 |
| @HeikoS | yeah cool | 18:04 |
| @HeikoS | what do you mean by module files? | 18:04 |
| arianepaola | HeikoS: see at the end the output of this one: https://gist.github.com/anonymous/c3dfeb456656dd3b468fd7bc91b02058 | 18:05 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 18:05 | |
| shogun-notifier- | shogun: Sanuj :develop * de25478 / / (10 files): https://github.com/shogun-toolbox/shogun/commit/de254787049bb72acaa9b8689927803e4231f09f | 18:05 |
| shogun-notifier- | shogun: add setters/getters in nn and autoencoders | 18:05 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * d7ac736 / / (10 files): https://github.com/shogun-toolbox/shogun/commit/d7ac7366dc8e55ebb917ddf45e930b252396a180 | 18:05 |
| shogun-notifier- | shogun: Merge pull request #3276 from sanuj/nn_cleanup | 18:05 |
| shogun-notifier- | shogun: | 18:05 |
| shogun-notifier- | shogun: add setters/getters in nn and autoencoders | 18:05 |
| sanuj | wohoo merged | 18:05 |
| OXPHOS` | HeikoS I updated the logistic regression: https://github.com/shogun-toolbox/shogun/pull/3244 | 18:06 |
| OXPHOS` | and the kmeans https://github.com/shogun-toolbox/shogun/pull/3183 | 18:06 |
| arianepaola | HeikoS: e.g. dist-packages/modshogun.py _modshogun.so and then shogun/Classifier ... IO ... Loss .. Structure | 18:06 |
| @HeikoS | arianepaola: I see | 18:06 |
| @HeikoS | arianepaola: so these guys are not yet packaged into the archive | 18:07 |
| shogun-buildbot | build #709 of trusty - libshogun - viennacl is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/trusty%20-%20libshogun%20-%20viennacl/builds/709 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Sanuj <sanuj.sharma.in@gmail.com> | 18:07 |
| arianepaola | HeikoS: they are (see the other gist). | 18:07 |
| @HeikoS | sanuj: whats up with this gmm failure? | 18:07 |
| shogun-buildbot | build #3782 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/3782 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Sanuj <sanuj.sharma.in@gmail.com> | 18:07 |
| arianepaola | HeikoS: the strange thing is that it seems to change based on the cwd | 18:07 |
| sanuj | HeikoS, we need to merge this to fix the gmm failure https://github.com/shogun-toolbox/shogun/pull/3239 | 18:08 |
| arianepaola | even though I get the same files | 18:08 |
| @HeikoS | arianepaola: strange indeed | 18:08 |
| @HeikoS | arianepaola: I guess google can help? | 18:08 |
| arianepaola | check: | 18:08 |
| arianepaola | >>> glob.glob('install/lib/*/dist-packages')[0] | 18:08 |
| arianepaola | 'install/lib/python2.7/dist-packages' | 18:08 |
| arianepaola | >>> glob.glob('install/lib/libshogun*') | 18:08 |
| arianepaola | ['install/lib/libshogun.so.17', 'install/lib/libshogun.so.17.2', 'install/lib/libshogun.so'] | 18:08 |
| arianepaola | >>> glob.glob('build/install/lib/*/dist-packages')[0] | 18:08 |
| arianepaola | 'build/install/lib/python2.7/dist-packages' | 18:08 |
| arianepaola | >>> glob.glob('build/install/lib/libshogun*') | 18:08 |
| arianepaola | ['build/install/lib/libshogun.so.17', 'build/install/lib/libshogun.so.17.2', 'build/install/lib/libshogun.so'] | 18:08 |
| sanuj | HeikoS, but R fails | 18:09 |
| @HeikoS | arianepaola: got any ideas what to do about this=? | 18:09 |
| arianepaola | HeikoS: google not really, but it has to do how setuptools does get cwd | 18:09 |
| arianepaola | I am trying to reproduce and overwrite it | 18:10 |
| shogun-notifier- | shogun: Sanuj :develop * 2549c77 / examples/meta/src/clustering/gmm.sg: https://github.com/shogun-toolbox/shogun/commit/2549c778674b95cdabab0b44aa64229fec532ec3 | 18:10 |
| shogun-notifier- | shogun: init math for gmm cookbook integration data | 18:10 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 78b25b8 / examples/meta/src/clustering/gmm.sg: https://github.com/shogun-toolbox/shogun/commit/78b25b8fc14e4ab828917cf3c2a7db520939e748 | 18:10 |
| shogun-notifier- | shogun: Merge pull request #3239 from sanuj/cookbook_gmm | 18:10 |
| shogun-notifier- | shogun: | 18:11 |
| shogun-notifier- | shogun: init math for gmm cookbook integration data | 18:11 |
| @HeikoS | arianepaola: ok cool | 18:11 |
| -!- HeikoS [~heiko@nat-173-117.internal.eduroam.ucl.ac.uk] has left #shogun [] | 18:11 | |
| -!- HeikoS [~heiko@nat-173-117.internal.eduroam.ucl.ac.uk] has joined #shogun | 18:11 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 18:11 | |
| arianepaola | I am checking the source a thttps://github.com/pypa/setuptools | 18:11 |
| @HeikoS | arianepaola: good idea | 18:11 |
| sanuj | HeikoS, R was failing for ^^^ | 18:11 |
| @HeikoS | sanuj: I know | 18:11 |
| sanuj | okay | 18:11 |
| @HeikoS | I will deactivate it now | 18:11 |
| @HeikoS | and see how to fix it | 18:11 |
| @HeikoS | some problem that I dont entirely understand | 18:12 |
| arianepaola | HeikoS: seems there is find_packages, I will give it a try and see how that goes | 18:12 |
| @HeikoS | but we need these static methods in there, otherwise it is a blocker | 18:12 |
| shogun-buildbot | build #710 of trusty - libshogun - viennacl is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/trusty%20-%20libshogun%20-%20viennacl/builds/710 | 18:12 |
| @HeikoS | ha! ^ | 18:12 |
| shogun-buildbot | build #3783 of deb1 - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/3783 | 18:12 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * ee8f2a5 / examples/meta/CMakeLists.txt: https://github.com/shogun-toolbox/shogun/commit/ee8f2a53caa9327df437875bb2bfbc2718bc0523 | 18:14 |
| shogun-notifier- | shogun: temporarily disable R meta examples | 18:14 |
| sanuj | HeikoS, can you review this https://github.com/shogun-toolbox/shogun/pull/3221 | 18:14 |
| sanuj | it is merge ready | 18:14 |
| @HeikoS | sanuj: OXPHOS` I pushed a commit that disables R meta examples | 18:15 |
| sanuj | reviewed by lisitsyn and lambday | 18:15 |
| @HeikoS | sanuj: will check soon | 18:15 |
| sanuj | if you have some changes, i can do and squash the commits | 18:15 |
| sanuj | HeikoS, cool! | 18:15 |
| @lambday | HeikoS: hey | 18:16 |
| @HeikoS | lambday: yo! | 18:16 |
| @lambday | sanuj: hello | 18:16 |
| @HeikoS | Im in the office now btw | 18:16 |
| @HeikoS | lambday: I guess youre home? | 18:16 |
| @lambday | HeikoS: yeah I stayed at home | 18:16 |
| sanuj | and HeikoS this is the updated mkl cookbook https://github.com/shogun-toolbox/shogun/pull/3250 | 18:16 |
| sanuj | fails for R and Ruby | 18:16 |
| @HeikoS | lambday: cool, how is xvalidation going? | 18:16 |
| arianepaola | HeikoS: does Shogun build Python 3 modules? As I am working around the limitation of lacing PEP420 support in setuptools (they added this for Python >3.3 https://github.com/pypa/setuptools/issues/97) | 18:17 |
| sanuj | please look at the errors once, if you want me to check on local then I'll install R and ruby on my laptop | 18:17 |
| @HeikoS | sanuj: give me a sec, too many things at once atm :) ping me on this in 30 mins | 18:17 |
| sanuj | lambday, yooo | 18:17 |
| sanuj | HeikoS, sure :) | 18:17 |
| @HeikoS | arianepaola: I think it does | 18:17 |
| sanuj | btw you work in office? and not in a lab? | 18:17 |
| OXPHOS` | HeikoS: cool! then the kmeans is ready to merge then | 18:17 |
| @HeikoS | arianepaola: seehttp://buildbot.shogun-toolbox.org/builders/deb4%20-%20python3 | 18:17 |
| arianepaola | thanks | 18:17 |
| @HeikoS | sanuj: same thing :) | 18:18 |
| arianepaola | I will make it work on Python2 first and then check what fails for 3 | 18:18 |
| @HeikoS | arianepaola: you can check the config and output logs there | 18:18 |
| @HeikoS | arianepaola: yeah good approach | 18:18 |
| @HeikoS | unfortunately, python2->python3 is not trivial | 18:18 |
| @HeikoS | dont know who the hell decided that | 18:18 |
| @HeikoS | but its such a shot in the knee | 18:18 |
| @HeikoS | for Python | 18:18 |
| @HeikoS | really a shame | 18:18 |
| @HeikoS | but well | 18:18 |
| @HeikoS | (and they didnt even speed it up) | 18:19 |
| arianepaola | At least it is not so bad as Swift 2.0 -> 2.1 -> 2.3 -> 3 | 18:19 |
| arianepaola | * 2.1 -> 2.2 | 18:19 |
| shogun-buildbot | build #47 of xenial - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/47 blamelist: Sanuj <sanuj.sharma.in@gmail.com> | 18:19 |
| @HeikoS | dont know about that, what happened there? | 18:19 |
| arianepaola | HeikoS: they change their mind every time -> https://github.com/apple/swift-evolution | 18:20 |
| @lambday | HeikoS: not much yet. wondering whether I should do the translational invariant thing first or just test the way I did for multi kernel MMD for max MMD kernel selection | 18:20 |
| @HeikoS | arianepaola: omg scary | 18:20 |
| @HeikoS | lambday: I can you explain more? | 18:20 |
| -!- HeikoS [~heiko@nat-173-117.internal.eduroam.ucl.ac.uk] has left #shogun [] | 18:21 | |
| -!- HeikoS [~heiko@nat-173-117.internal.eduroam.ucl.ac.uk] has joined #shogun | 18:21 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 18:21 | |
| @lambday | HeikoS: yo.. | 18:21 |
| @HeikoS | lambday: yo again :) | 18:21 |
| shogun-buildbot | build #2907 of bsd1 - libshogun is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2907 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Sanuj <sanuj.sharma.in@gmail.com> | 18:21 |
| sanuj | why do these things fail | 18:21 |
| @lambday | HeikoS: so for the max MMD thing, I kinda did a hack.. going through the distance matrix once and computing the kernel function(s) on it | 18:22 |
| sanuj | last to last one was for lda unit tests | 18:22 |
| @lambday | without having adding the classes yet that we discussed about | 18:22 |
| @HeikoS | sanuj: check the build ihstory | 18:22 |
| @HeikoS | there is another problem | 18:22 |
| @HeikoS | not because of the recent merge | 18:23 |
| @HeikoS | lambday: I guess the best way would be to prototype first using ad-hoc distance precomputation | 18:23 |
| @HeikoS | lambday: and then build your internals around that | 18:23 |
| shogun-buildbot | build #48 of xenial - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/48 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 18:23 |
| @HeikoS | lambday: then once it works, put the translation invariant stuff into shogun | 18:23 |
| @lambday | HeikoS: alright | 18:24 |
| sanuj | btw i just remembered something | 18:30 |
| @lambday | OXPHOS`: yo | 18:31 |
| @lambday | so we can have everything in a single Vector class, right? | 18:31 |
| sanuj | lambday, did you tell heiko how my name is pronounced :P | 18:31 |
| @lambday | which we'll pass around as const ref instead of a shared ptr | 18:31 |
| @lambday | OXPHOS`: and make it use a forward declared gpuarray.. | 18:32 |
| @lambday | so none of these things will be in the header of Vector, but in the cpp.. and then in GPUBackend, you just use that.. | 18:32 |
| @lambday | sanuj: haha yeah | 18:32 |
| sanuj | :D | 18:33 |
| OXPHOS` | lambday: I guess so..what's that about gpuarray? I feel gpuarray doesn't need any change | 18:33 |
| @lambday | OXPHOS`: things to think about : when you want to get a gpu vector from the factory, you set the ongpu flag true | 18:34 |
| @lambday | OXPHOS`: nah.. | 18:34 |
| @lambday | OXPHOS`: gpuarray is fine | 18:34 |
| OXPHOS` | lambday: sure | 18:35 |
| arianepaola | wiking and HeikoS: seems it is the where='.' in https://github.com/pypa/setuptools/blob/04d10ff025e1cbef7ec93a2008c930e856045c8a/setuptools/__init__.py#L36 | 18:37 |
| arianepaola | where is undocumented | 18:37 |
| -!- besser82 [~besser82@fedora/besser82] has joined #shogun | 18:38 | |
| -!- mode/#shogun [+o besser82] by ChanServ | 18:38 | |
| @HeikoS | arianepaola: well spotted! | 18:38 |
| @HeikoS | arianepaola: cool ,so will that fix it? | 18:42 |
| arianepaola | hmm | 18:43 |
| arianepaola | it includes the submodules and modshogun.py, but it is not including _modshogun.so that was included before | 18:44 |
| arianepaola | as package data | 18:44 |
| arianepaola | wiking and HeikoS: see https://gist.github.com/arianepaola/96c9255ec9594a1140fd5d655dbada13 | 18:47 |
| arianepaola | now it is about getting _modshogun.so back in | 18:48 |
| -!- OXPHOS` [9d8b131c@gateway/web/freenode/ip.157.139.19.28] has quit [Ping timeout: 250 seconds] | 18:48 | |
| -!- travis-ci [~travis-ci@ec2-54-167-192-169.compute-1.amazonaws.com] has joined #shogun | 18:52 | |
| 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/136739770 | 18:52 |
| -!- travis-ci [~travis-ci@ec2-54-167-192-169.compute-1.amazonaws.com] has left #shogun [] | 18:52 | |
| @HeikoS | sanuj: hi | 18:58 |
| @HeikoS | what was the discussion about the spaces? | 18:58 |
| @HeikoS | I am just looking at the tag PR | 18:58 |
| sanuj | HeikoS, lisitsyn told me to keep spaces | 18:58 |
| @HeikoS | ok | 18:58 |
| sanuj | x = y and not x=y | 18:58 |
| @HeikoS | lisitsyn: can you remind me why? | 18:58 |
| -!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 272 seconds] | 18:58 | |
| @HeikoS | and also, we should update our style guidelines then | 18:59 |
| @HeikoS | not that it really matters :) | 18:59 |
| sanuj | HeikoS, he likes it | 18:59 |
| -!- besser82 [~besser82@fedora/besser82] has joined #shogun | 19:00 | |
| -!- mode/#shogun [+o besser82] by ChanServ | 19:00 | |
| shogun-buildbot | build #36 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/36 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Sanuj <sanuj.sharma.in@gmail.com> | 19:07 |
| @HeikoS | sanuj: question: | 19:11 |
| @HeikoS | why all these changes in classes | 19:11 |
| sanuj | yes those changes are necessary | 19:11 |
| @HeikoS | Can't we do that in another patch? | 19:11 |
| @HeikoS | why? | 19:11 |
| sanuj | because SGObject has a method called "set" | 19:11 |
| @HeikoS | uh | 19:11 |
| sanuj | so compiler errors | 19:11 |
| @HeikoS | I see | 19:11 |
| @HeikoS | ok I will stop moaning about them then | 19:11 |
| @HeikoS | https://github.com/shogun-toolbox/shogun/pull/3221/files#diff-28b7c17af706eb436507478ea6a7f957R561 | 19:12 |
| @HeikoS | sanuj: why is this needed? | 19:12 |
| @HeikoS | the parameter combination? | 19:12 |
| @HeikoS | no set in there | 19:12 |
| sanuj | HeikoS, oh, i had removed use namespace std from that file | 19:13 |
| @HeikoS | sanuj: why? | 19:13 |
| sanuj | i can reverse these changes | 19:13 |
| @HeikoS | sanuj: yeah please only do changes that are necessary | 19:14 |
| @HeikoS | and send other ones in a separate patch | 19:14 |
| @HeikoS | makes it easier to track down things | 19:14 |
| sanuj | HeikoS, alright | 19:14 |
| sanuj | yeah i'll reverse those | 19:14 |
| @HeikoS | sanuj: finished reviewing | 19:15 |
| @HeikoS | sanuj: can you make sure everything is unit test covered? | 19:15 |
| @HeikoS | and I mean really everything? | 19:15 |
| @HeikoS | all the code you added | 19:15 |
| @HeikoS | since this is critical | 19:15 |
| sanuj | HeikoS, can you stress on which parts are missing in the unit tests | 19:16 |
| sanuj | any | 19:16 |
| @HeikoS | lisitsyn: sanuj, lambday one thing I would also like to see is how fast this stuff is. Can we run a little benchmark? Maybe even compare to the old parameter system? | 19:16 |
| @HeikoS | sanuj: you need you use a took to check this | 19:16 |
| lisitsyn | hey | 19:16 |
| sanuj | HeikoS, class CTaxonomy : public CSGObject | 19:17 |
| sanuj | ^^ necessary | 19:17 |
| @HeikoS | sanuj: ok then | 19:17 |
| @HeikoS | http://buildbot.shogun-toolbox.org/builders/coverity%20analysis/builds/101 | 19:17 |
| @HeikoS | check this | 19:17 |
| @HeikoS | generated a report of test coverage | 19:17 |
| @HeikoS | we want 100% in all tag based codes | 19:17 |
| @HeikoS | since it is so low level | 19:17 |
| @HeikoS | sanuj: you can run the same tool locally | 19:17 |
| sanuj | HeikoS, agree | 19:17 |
| @HeikoS | ah wait is that the right build | 19:18 |
| @HeikoS | checking | 19:18 |
| @HeikoS | https://coveralls.io/github/shogun-toolbox/shogun | 19:18 |
| @HeikoS | sanuj: actually | 19:18 |
| @HeikoS | this might contain it already | 19:18 |
| @HeikoS | ah no | 19:19 |
| sanuj | HeikoS, coveralls? | 19:19 |
| @HeikoS | it stopped | 19:19 |
| @HeikoS | have to ask wiking | 19:20 |
| sanuj | okay | 19:20 |
| @HeikoS | wiking: is there a way to check code coverage of a PR without having to run something? | 19:20 |
| @HeikoS | wiking: I want to make sure that sanuj 's tag patch is 100% covered | 19:20 |
| @HeikoS | usually, coveralls should do it, but it stopped updating, not sure why | 19:22 |
| sanuj | HeikoS, the PR is against shogun/tags | 19:22 |
| sanuj | and not shogun/develop | 19:22 |
| @HeikoS | sanuj: that should be ok | 19:22 |
| sanuj | okay | 19:22 |
| @HeikoS | check https://coveralls.io/github/shogun-toolbox/shogun | 19:22 |
| @HeikoS | has feature branches | 19:22 |
| @HeikoS | sanuj: you can also run a tool locally | 19:22 |
| @HeikoS | but lets say what viktor says first | 19:22 |
| @HeikoS | we should get that going again actually | 19:23 |
| @HeikoS | https://github.com/eddyxu/cpp-coveralls | 19:23 |
| @HeikoS | I think it is very easy to check this | 19:24 |
| @HeikoS | http://gcc.gnu.org/onlinedocs/gcc/Gcov.html | 19:24 |
| @HeikoS | this is it | 19:25 |
| @HeikoS | just run shogun-unit-test binary with it | 19:25 |
| @HeikoS | and turn optimization off before that | 19:25 |
| @HeikoS | well, just follow the readme | 19:25 |
| sanuj | HeikoS, yes i will | 19:25 |
| sanuj | i have a few doubts | 19:25 |
| @HeikoS | sanuj: let me know how it goes I will be around for a bit so can help you | 19:25 |
| sanuj | HeikoS, you want to only hide std::string demangledType() from SWIG? | 19:26 |
| sanuj | and not the whole of any class? | 19:26 |
| @HeikoS | sanuj: ah yes, sorry | 19:28 |
| @HeikoS | I just made this one comment | 19:28 |
| @HeikoS | but basically saying, please hide everything from swig | 19:28 |
| sanuj | HeikoS, can't hide any from swig | 19:28 |
| @HeikoS | SWIG just needs to see the get/set methods in CSGObject | 19:28 |
| @HeikoS | and of course the necessary type definitions | 19:28 |
| @HeikoS | uh that actually makes me think | 19:28 |
| @HeikoS | do we need to change the typemaps? | 19:29 |
| sanuj | HeikoS, btw this is a small piece of swig which works with tags in shogun https://github.com/sanuj/shogun/commit/45104a01513eb315f847b5e89815caad11361c29 | 19:29 |
| sanuj | HeikoS, i don't know much about swig typemaps | 19:29 |
| @HeikoS | when you say works with swig/shogun | 19:29 |
| @HeikoS | can you provide a listing that accesses things via SWIG and tags? | 19:30 |
| @HeikoS | an example? | 19:30 |
| sanuj | yes i can do that | 19:30 |
| sanuj | this is another branch originating from my tags branch | 19:30 |
| @HeikoS | cool show me | 19:30 |
| @HeikoS | this will answer the question I had | 19:30 |
| shogun-notifier- | shogun: Ariane Paola Gomes :develop * 58628bc / examples/meta/generator/targets/cpp.json: https://github.com/shogun-toolbox/shogun/commit/58628bc098563a5b68db9de8d8f452e8954f8a85 | 19:31 |
| shogun-notifier- | shogun: Make DenseDistance type available within cookbooks. | 19:31 |
| shogun-notifier- | shogun: Ariane Paola Gomes :develop * 73b6246 / examples/meta/generator/targets/cpp.json: https://github.com/shogun-toolbox/shogun/commit/73b62465ed13490634d0496de83d238ab35148ca | 19:31 |
| shogun-notifier- | shogun: Added RealDenseDistance type. | 19:31 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 567ce21 / examples/meta/generator/targets/cpp.json: https://github.com/shogun-toolbox/shogun/commit/567ce211290c66c7502a14db0db335ca9edd6d5f | 19:31 |
| shogun-notifier- | shogun: Merge pull request #3258 from arianepaola/feature/cookbook_type_densedistance | 19:31 |
| shogun-notifier- | shogun: | 19:31 |
| sanuj | HeikoS, you need an example of all the features in tags PR in swig right? | 19:31 |
| shogun-notifier- | shogun: Make RealDenseDistance type available within cookbooks. | 19:31 |
| sanuj | like in python? | 19:31 |
| @HeikoS | yep | 19:31 |
| sanuj | okay | 19:31 |
| sanuj | HeikoS, i need you to review one more PR :D | 19:32 |
| sanuj | https://github.com/shogun-toolbox/shogun/pull/3250 | 19:32 |
| sanuj | mkl cookbook | 19:32 |
| @HeikoS | I am going through all PRs atm | 19:32 |
| @HeikoS | getting there :) | 19:32 |
| sanuj | okay | 19:32 |
| sanuj | i need to sleep now | 19:34 |
| sanuj | will update these tomorrow | 19:34 |
| sanuj | HeikoS, will you be available this weekend? | 19:34 |
| @HeikoS | sanuj: probably a bit | 19:35 |
| @HeikoS | sanuj: ok | 19:35 |
| @HeikoS | sleep well | 19:35 |
| @HeikoS | arianepaola: there? | 19:35 |
| sanuj | goodnight :) | 19:35 |
| arianepaola | hey HeikoS | 19:35 |
| @HeikoS | arianepaola: so for the cookbooks | 19:35 |
| @HeikoS | they also serve as integraiton test | 19:35 |
| @HeikoS | when you run make test locally | 19:35 |
| @HeikoS | every cpp meta example outputs a serialized file | 19:36 |
| @HeikoS | with all the results of the meta exampe | 19:36 |
| @HeikoS | we then have an integration tester program that compares the output against a reference file | 19:36 |
| -!- sanuj [~sanuj@117.203.17.165] has quit [Quit: Leaving] | 19:36 | |
| @HeikoS | so when I say the cookbook needs integration testing data, then I mean that you need to copy this file into your data repo and send a patch there | 19:36 |
| @HeikoS | then update the data version in the cookbook pr | 19:37 |
| @HeikoS | all described in the readme as well | 19:37 |
| arianepaola | ok | 19:37 |
| @HeikoS | you can see whether it worked by checking the cpp travis build and see whether your new example is in the integration testing list | 19:37 |
| @HeikoS | arianepaola: looks like this: https://travis-ci.org/shogun-toolbox/shogun/jobs/136520038#L4034 | 19:37 |
| shogun-buildbot | build #49 of xenial - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/49 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 19:38 |
| @HeikoS | for it to be there, I first need to merge the data file | 19:38 |
| @HeikoS | but as said, all in the readme | 19:38 |
| arianepaola | yes | 19:39 |
| arianepaola | I will add the integration test data | 19:39 |
| @HeikoS | arianepaola: ask me if you have troubles with this | 19:39 |
| @HeikoS | should be really quic | 19:39 |
| shogun-buildbot | build #2908 of bsd1 - libshogun is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2908 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 19:39 |
| @HeikoS | k | 19:39 |
| -!- travis-ci [~travis-ci@ec2-54-147-45-105.compute-1.amazonaws.com] has joined #shogun | 19:41 | |
| 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/136742178 | 19:41 |
| -!- travis-ci [~travis-ci@ec2-54-147-45-105.compute-1.amazonaws.com] has left #shogun [] | 19:41 | |
| @HeikoS | yessss | 19:42 |
| arianepaola | k | 19:44 |
| arianepaola | wiking and HeikoS: the _modshogun.so module cannot be installed as normal module and needs to be injected into the package structure | 20:03 |
| arianepaola | data_files=[(os.path.join('lib', glob.glob('install/lib/*/dist-packages')[0].split(os.sep)[-2], glob.glob('install/lib/*/dist-packages')[0].split(os.sep)[-1]), [glob.glob('install/lib/*/dist-packages/_modshogun.so')[0]])] | 20:03 |
| @HeikoS | arianepaola: what does injected here mean? | 20:03 |
| @HeikoS | ah | 20:03 |
| arianepaola | HeikoS: easy peasy | 20:03 |
| arianepaola | haha | 20:03 |
| @HeikoS | peasy easy ;) | 20:04 |
| arianepaola | I will clean that line up | 20:04 |
| @HeikoS | cool | 20:04 |
| arianepaola | it is reconstructing from the lowest directory e.g. dist-packages going its way up pythonx.x -> lib and then putting it into the package at a lower directory (package is /usr/local) | 20:04 |
| @HeikoS | okok | 20:05 |
| arianepaola | so it injects it at lib and python resolves itself then | 20:05 |
| @HeikoS | ah man | 20:05 |
| @HeikoS | messy | 20:05 |
| @HeikoS | but ok | 20:05 |
| @HeikoS | I think thats a fair solve | 20:05 |
| arianepaola | it will produce: /usr/local/lib/python2.7dist-packages with modshogun.py, _modshogun.so, shogun and its submodules | 20:06 |
| @HeikoS | arianepaola: I guess that was the last blocker wasnt it= | 20:10 |
| @HeikoS | ? | 20:10 |
| @HeikoS | for the python install thing | 20:11 |
| arianepaola | it seems so | 20:11 |
| arianepaola | the cmake bootstrapping relies on distutils as that part is not possible to do with setuptools | 20:11 |
| arianepaola | I will include the module injection into the gist, test it and start to include changes from the PR | 20:12 |
| arianepaola | hopefully without any distutils issues and will update the PR today | 20:12 |
| shogun-buildbot | build #877 of deb4 - python3 is complete: Failure [failed install test python modular] Build details are at http://buildbot.shogun-toolbox.org/builders/deb4%20-%20python3/builds/877 blamelist: Ariane Paola Gomes <arianepaola@users.noreply.github.com> | 20:14 |
| shogun-buildbot | build #50 of xenial - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/50 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Ariane Paola Gomes <arianepaola@users.noreply.github.com> | 20:16 |
| @HeikoS | cool | 20:17 |
| @HeikoS | ! | 20:17 |
| @HeikoS | looking forward to see that | 20:17 |
| @HeikoS | wiking: will be happy as well I guess :) | 20:17 |
| @HeikoS | I have to go now, but will check back tomorrow | 20:18 |
| shogun-buildbot | build #2909 of bsd1 - libshogun is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2909 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Ariane Paola Gomes <arianepaola@users.noreply.github.com> | 20:18 |
| @HeikoS | to merge things :) | 20:18 |
| shogun-buildbot | build #37 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/37 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 20:18 |
| shogun-buildbot | build #465 of CentOS7 - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/CentOS7%20-%20libshogun/builds/465 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Ariane Paola Gomes <arianepaola@users.noreply.github.com> | 20:19 |
| arianepaola | thanks HeikoS | 20:20 |
| @HeikoS | arianepaola: see you! | 20:20 |
| -!- HeikoS [~heiko@nat-173-117.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.] | 20:20 | |
| -!- travis-ci [~travis-ci@ec2-54-167-192-169.compute-1.amazonaws.com] has joined #shogun | 20: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/136759016 | 20:23 |
| -!- travis-ci [~travis-ci@ec2-54-167-192-169.compute-1.amazonaws.com] has left #shogun [] | 20:23 | |
| shogun-buildbot | build #878 of deb4 - python3 is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/deb4%20-%20python3/builds/878 | 20:49 |
| shogun-buildbot | build #38 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/38 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Ariane Paola Gomes <arianepaola@users.noreply.github.com> | 20:57 |
| -!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 272 seconds] | 21:29 | |
| arianepaola | wiking and HeikoS, please check https://gist.github.com/arianepaola/96c9255ec9594a1140fd5d655dbada13 | 22:27 |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 22:31 | |
| -!- sonne|osx [~sonne@x4db3b8d3.dyn.telefonica.de] has joined #shogun | 23:18 | |
| -!- sonne|osx [~sonne@x4db3b8d3.dyn.telefonica.de] has quit [Quit: sonne|osx] | 23:46 | |
| --- Log closed Sat Jun 11 00:00:35 2016 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!