| --- Log opened Sun Jun 12 00:00:36 2016 | ||
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has joined #shogun | 11:56 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 11:56 | |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Quit: Leaving.] | 12:01 | |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has joined #shogun | 12:03 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 12:03 | |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Quit: Leaving.] | 12:14 | |
| -!- mizari [~mizari@95-174-213-100.nts.su] has joined #shogun | 12:42 | |
| -!- sanuj [~sanuj@117.203.8.81] has joined #shogun | 13:02 | |
| sanuj | lisitsyn, hey! | 13:04 |
|---|---|---|
| lisitsyn | sanuj: hey there | 13:04 |
| lisitsyn | what's up | 13:04 |
| sanuj | lisitsyn, i keep disturbing you on sundays :P | 13:04 |
| sanuj | i hope you don't mind :D | 13:04 |
| lisitsyn | no worries | 13:04 |
| sanuj | okay, HeikoS had reviewed the tags PR | 13:05 |
| sanuj | he insists we have 100% coverage | 13:05 |
| lisitsyn | let me check | 13:05 |
| sanuj | for unit-tests | 13:05 |
| lisitsyn | yeah I agree, what do you think is not covered? | 13:06 |
| sanuj | any | 13:06 |
| lisitsyn | ah ok | 13:06 |
| sanuj | and he said we can check by a tool also | 13:06 |
| sanuj | let me see the irc logs | 13:06 |
| sanuj | lisitsyn, https://gcc.gnu.org/onlinedocs/gcc/Gcov.html | 13:07 |
| lisitsyn | yeah we can use that | 13:07 |
| sanuj | okay, i'll try it | 13:08 |
| sanuj | i wanted to discuss about swig | 13:08 |
| lisitsyn | I am just not sure how to integrate it into our build process | 13:08 |
| sanuj | lisitsyn, https://github.com/sanuj/shogun/commit/45104a01513eb315f847b5e89815caad11361c29 | 13:09 |
| sanuj | this is working ^ | 13:09 |
| sanuj | we need to finalize names | 13:09 |
| sanuj | like sg.int?? | 13:09 |
| lisitsyn | what changed? | 13:09 |
| lisitsyn | looks exactly as before | 13:09 |
| sanuj | yeah | 13:09 |
| sanuj | i had the wrong path in the env variables | 13:09 |
| sanuj | :D | 13:09 |
| sanuj | to some other shogun | 13:09 |
| lisitsyn | ah ok | 13:10 |
| lisitsyn | this explains | 13:10 |
| sanuj | yeah | 13:10 |
| lisitsyn | sanuj: what is interesting now | 13:10 |
| lisitsyn | is do we really have to set<Type> | 13:10 |
| lisitsyn | or we can overload them | 13:11 |
| sanuj | i'll add %template(TypeInt) Type<int>; | 13:11 |
| @wiking | there's a coverage build (used to) in travis | 13:11 |
| @wiking | but the cmake stuff is still there for it | 13:11 |
| lisitsyn | wiking: ! | 13:11 |
| lisitsyn | yes | 13:11 |
| lisitsyn | true | 13:11 |
| sanuj | coveralls? | 13:11 |
| @wiking | so u can build it locally | 13:11 |
| @wiking | and run it | 13:11 |
| @wiking | yourself | 13:11 |
| lisitsyn | that's cool | 13:12 |
| sanuj | let me check cmake | 13:13 |
| sanuj | lisitsyn, why do we need to overload? | 13:14 |
| lisitsyn | sanuj: do we have to write setInt(IntTag(…), …)? | 13:14 |
| sanuj | no | 13:14 |
| lisitsyn | ahh is it for string ones? | 13:14 |
| sanuj | currently we can write setInt(IntTag(…), …) but i think we want to change that | 13:16 |
| lisitsyn | sanuj: I mean for tag based set/get | 13:16 |
| lisitsyn | we obviously don't want to write the type name twice | 13:17 |
| sanuj | yes :D | 13:17 |
| sanuj | we don't | 13:17 |
| sanuj | oh i see | 13:17 |
| lisitsyn | but we have to rename string ones | 13:18 |
| sanuj | to what? | 13:20 |
| sanuj | lisitsyn, so i need to write multiple set(Tag) in swig which internally calls setInt, setFloat and so on depending on Tag? | 13:22 |
| lisitsyn | sanuj: nah | 13:22 |
| lisitsyn | you don't have to | 13:22 |
| lisitsyn | I mean now we have | 13:22 |
| lisitsyn | set<int>(IntTag) | 13:23 |
| lisitsyn | and set<int>(string) | 13:23 |
| lisitsyn | string one can't infer the type | 13:23 |
| lisitsyn | so it should be setInt(string) | 13:23 |
| lisitsyn | setInt(string, value) to be precise | 13:23 |
| lisitsyn | but set(IntTag) and set(FloatTag) and other ones should work as our target languages support overloading | 13:23 |
| lisitsyn | it is just some methods with the same name but different argument types | 13:24 |
| sanuj | yes okay | 13:24 |
| lisitsyn | sanuj: I guess currently you rename both set<T> | 13:24 |
| lisitsyn | but we have to rename only the string one - lets check if it is possible | 13:25 |
| sanuj | lisitsyn, i haven't renamed anything currently | 13:25 |
| sanuj | just %template | 13:25 |
| lisitsyn | sanuj: isn't %template renaming it? | 13:25 |
| lisitsyn | I mean introducing other name? | 13:25 |
| sanuj | okay | 13:26 |
| lisitsyn | how do you call that in your python example? | 13:26 |
| sanuj | setInt | 13:26 |
| sanuj | but there is %rename also | 13:26 |
| lisitsyn | yeah that's what I mean by renaming :0 | 13:26 |
| lisitsyn | yeap | 13:26 |
| lisitsyn | :) | 13:26 |
| sanuj | i thought you were calling %rename rename | 13:26 |
| sanuj | :D | 13:26 |
| lisitsyn | nonono it is just about the final name you have in python | 13:27 |
| lisitsyn | tag-based methods should not have the type in the name, that's what I mean | 13:27 |
| sanuj | lisitsyn, but if i don't have %template then these template functions won't be accessible in python | 13:27 |
| lisitsyn | sanuj: yes sure | 13:29 |
| lisitsyn | sanuj: that's why you have to %template string get as get<..> | 13:29 |
| lisitsyn | but %template tag get as get | 13:30 |
| sanuj | okay, let me try that | 13:31 |
| sanuj | lisitsyn, i have a doubt | 13:43 |
| sanuj | overloading all set(tag) is fine | 13:43 |
| sanuj | how to differentiate between set(tag) and set(string) in swig | 13:43 |
| lisitsyn | it should be set(tag) and setType(string) | 13:43 |
| sanuj | when i'm doing %template | 13:43 |
| lisitsyn | ah | 13:43 |
| lisitsyn | ok | 13:43 |
| sanuj | lisitsyn, shall i not use %template and instantiate template functions for set(string) manually? | 13:45 |
| lisitsyn | sanuj: in the worst case yes | 13:45 |
| lisitsyn | I am checking swig doc | 13:45 |
| sanuj | actually i will have to do it manually for both set(tag) and set(string) | 13:46 |
| sanuj | i saw the docs | 13:46 |
| lisitsyn | sanuj: I've found this thing | 13:46 |
| lisitsyn | %template(bar) Foo::bar<int>; | 13:46 |
| lisitsyn | %template(bar) Foo::bar<double>; | 13:46 |
| lisitsyn | so overloading will work | 13:46 |
| lisitsyn | that's good :) | 13:47 |
| lisitsyn | next the string things | 13:47 |
| sanuj | yes overloading will work | 13:47 |
| sanuj | but not the string thing | 13:47 |
| lisitsyn | sanuj: ok I think I have a trick | 13:47 |
| sanuj | haha | 13:47 |
| sanuj | tell | 13:47 |
| lisitsyn | template <typename T, typename Q=void> | 13:48 |
| lisitsyn | set(string, ...) | 13:48 |
| lisitsyn | %template (setInt) SGObject::set<int, void> | 13:48 |
| sanuj | this will require changing SGObject.h also | 13:49 |
| sanuj | right? | 13:49 |
| lisitsyn | yeap | 13:49 |
| lisitsyn | just add some dummy template parameter | 13:49 |
| sanuj | yeah this will work | 13:49 |
| lisitsyn | for string ones | 13:49 |
| sanuj | lisitsyn, that template won't be used anywhere in the function | 13:49 |
| lisitsyn | yes | 13:50 |
| lisitsyn | but it allows us to tell one from another | 13:50 |
| sanuj | i just need to template <typename T> --> template<typename T, typename U> | 13:50 |
| lisitsyn | yes with default parameter of void | 13:50 |
| sanuj | lisitsyn, yes i agree | 13:50 |
| sanuj | okay | 13:51 |
| lisitsyn | typename U = void | 13:51 |
| lisitsyn | sanuj: so that you don't have to write the useless parameter in C++ | 13:51 |
| sanuj | yes | 13:51 |
| sanuj | lisitsyn, nice trick :) | 13:51 |
| sanuj | c++ is very powerful | 13:51 |
| lisitsyn | well we're trying to overcome its diffuculties :D | 13:52 |
| sanuj | haha | 13:52 |
| sanuj | lisitsyn, while i'm doing this | 13:53 |
| sanuj | can you check this | 13:53 |
| sanuj | https://github.com/shogun-toolbox/shogun/pull/3246 | 13:53 |
| sanuj | you remember you changed 'some' for an error in neural net cookbook | 13:53 |
| sanuj | it is giving seg fault | 13:54 |
| sanuj | see my 3rd comment in the PR | 13:54 |
| sanuj | i have shown the cpp translation which errors | 13:54 |
| lisitsyn | hmm ok | 13:55 |
| lisitsyn | I am not sure what causing that | 14:03 |
| lisitsyn | sanuj: can you paste some valgrind output later? | 14:03 |
| sanuj | sure | 14:03 |
| sanuj | lisitsyn, http://pastebin.com/u6n5sVrq | 14:05 |
| lisitsyn | oh I see | 14:07 |
| lisitsyn | easy | 14:07 |
| lisitsyn | sanuj: you need %newobject | 14:08 |
| lisitsyn | for methods in NeuralLayers | 14:08 |
| sanuj | oh i see | 14:08 |
| sanuj | i'll send a PR | 14:08 |
| lisitsyn | because they are returning the same object | 14:08 |
| lisitsyn | but not ref'ing it | 14:08 |
| lisitsyn | so your neural layers thing was deleted after the first = | 14:09 |
| sanuj | lisitsyn, i don't understand | 14:17 |
| sanuj | cpp code is ==> return with_layer(new CNeuralLinearLayer(size)); | 14:17 |
| sanuj | so it is returning a new object | 14:18 |
| lisitsyn | no | 14:18 |
| lisitsyn | it returns what with_layer returns | 14:18 |
| lisitsyn | i.e itself | 14:19 |
| sanuj | oh | 14:19 |
| sanuj | return this | 14:19 |
| sanuj | lisitsyn, how does %newobject solve the problem | 14:20 |
| lisitsyn | sanuj: it will call SG_REF | 14:20 |
| sanuj | swig doc says it is for fixing memory leak | 14:20 |
| lisitsyn | so when you reassign reference is not going to zero | 14:21 |
| sanuj | reference will get +1 | 14:21 |
| lisitsyn | yes | 14:21 |
| sanuj | but in current scenario why is it deleting even when we don't call SG_REF | 14:21 |
| lisitsyn | because ref counter goes to zero | 14:22 |
| sanuj | so SG_UNREF is called | 14:22 |
| lisitsyn | yes when you delete \old | 14:22 |
| lisitsyn | 'old' object | 14:22 |
| lisitsyn | which is essentially the same object | 14:22 |
| lisitsyn | because it returns itself | 14:22 |
| sanuj | oh i see | 14:23 |
| sanuj | lisitsyn, but what calls SG_UNREF | 14:23 |
| sanuj | the NeuralLayers destructor? | 14:23 |
| lisitsyn | sanuj: yeah | 14:23 |
| sanuj | by 0x65D7A33: shogun::CNeuralLayers::~CNeuralLayers() (NeuralLayers.cpp:52) | 14:24 |
| sanuj | i see | 14:24 |
| sanuj | lisitsyn, setInt(string) is working | 14:31 |
| lisitsyn | sanuj: using the template trick? | 14:31 |
| sanuj | yes :D | 14:31 |
| lisitsyn | cool | 14:32 |
| sanuj | for get | 14:32 |
| sanuj | get(tag) and get(string, type) | 14:32 |
| sanuj | both should be called tag? | 14:32 |
| sanuj | lisitsyn, and do i rename Type<int> as int | 14:33 |
| sanuj | to allow sg.int | 14:33 |
| sanuj | or maybe sg.Int | 14:33 |
| lisitsyn | sanuj: I am not sure | 14:33 |
| lisitsyn | it could be a bit dangerous for some langs | 14:33 |
| lisitsyn | sanuj: lets keep it IntType | 14:33 |
| sanuj | lisitsyn, TypeInt | 14:33 |
| sanuj | so that Type [tab] displays all Type... shogun supports | 14:34 |
| sanuj | ? | 14:34 |
| lisitsyn | sanuj: makes sense! | 14:34 |
| sanuj | lisitsyn, and for get | 14:34 |
| sanuj | all gets should be called "get"? | 14:34 |
| lisitsyn | sanuj: just the same as with set | 14:35 |
| sanuj | lisitsyn, we have get(tag) and get(string, type) | 14:35 |
| sanuj | we don't have getInt(string) | 14:35 |
| sanuj | it will be getInt(string, typeint) | 14:36 |
| lisitsyn | sanuj: oh lets add it then! :) | 14:36 |
| lisitsyn | sanuj: why did we go with get(string, type)? | 14:36 |
| sanuj | lisitsyn, i took it from aer | 14:36 |
| sanuj | how to have getInt(string) | 14:36 |
| lisitsyn | sanuj: I think we need some symmetry | 14:37 |
| lisitsyn | so getInt setInt | 14:37 |
| sanuj | agree | 14:37 |
| lisitsyn | sanuj: otherwise people would get mad | 14:37 |
| sanuj | haha | 14:37 |
| lisitsyn | and I understand why | 14:37 |
| lisitsyn | it is impossible to remember whether it is getInt and set or setInt and get | 14:37 |
| sanuj | lisitsyn, but how to implement getInt(string) | 14:38 |
| sanuj | oh | 14:38 |
| lisitsyn | template <typename T, typename U=void> | 14:38 |
| lisitsyn | .. | 14:38 |
| lisitsyn | :) | 14:38 |
| sanuj | should be easy | 14:38 |
| sanuj | yes | 14:38 |
| lisitsyn | just the same | 14:38 |
| lisitsyn | you just don't assign it but get it | 14:38 |
| sanuj | lisitsyn, what's the point of keeping get(string, type)? | 14:39 |
| sanuj | if we have getInt(string) | 14:39 |
| lisitsyn | sanuj: I don't have any | 14:40 |
| lisitsyn | looks like we should drop it | 14:40 |
| sanuj | lisitsyn, then there is no point in keeping Type also :D | 14:41 |
| lisitsyn | yeap | 14:41 |
| sanuj | lisitsyn, cool, i'll drop both | 14:42 |
| sanuj | and change unit tests | 14:42 |
| lisitsyn | ok thanks | 14:43 |
| sanuj | lisitsyn, apart from this what all is needed for swig | 14:44 |
| sanuj | and which types to expose via swig | 14:44 |
| lisitsyn | sanuj: well remember the list? | 14:45 |
| lisitsyn | you had in gist | 14:45 |
| lisitsyn | that's what we're going to expose I guess | 14:45 |
| sanuj | haha | 14:45 |
| sanuj | that? | 14:45 |
| lisitsyn | yes | 14:45 |
| sanuj | okay | 14:45 |
| sanuj | lisitsyn, will it work for everything? | 14:45 |
| lisitsyn | sanuj: it should otherwise we're going to fix it ;) | 14:46 |
| sanuj | lisitsyn, okay :) | 14:46 |
| sanuj | lisitsyn, i'm 3 weeks in and have not even touched plugins | 14:59 |
| lisitsyn | sanuj: yeah we're underestimated quite a bit | 15:00 |
| lisitsyn | that's ok we will readjust it | 15:00 |
| lisitsyn | sanuj: we can change the goal of your project to not really convert whole shogun | 15:00 |
| lisitsyn | but implement all the required staff and start the conversion | 15:01 |
| lisitsyn | this will make it feasible | 15:01 |
| sanuj | hmm | 15:03 |
| sanuj | lisitsyn, cookbooks take a lot of time | 15:03 |
| sanuj | from the process of initiating a PR to getting it merged | 15:04 |
| -!- mizari [~mizari@95-174-213-100.nts.su] has quit [Ping timeout: 246 seconds] | 15:04 | |
| -!- besser82 [~besser82@fedora/besser82] has joined #shogun | 15:04 | |
| -!- mode/#shogun [+o besser82] by ChanServ | 15:04 | |
| -!- mizari [~mizari@95-174-213-100.nts.su] has joined #shogun | 15:12 | |
| sanuj | lisitsyn, there? | 15:25 |
| lisitsyn | sanuj: y | 15:25 |
| sanuj | we have Type<T> type() const { return Type<T>(); } | 15:26 |
| sanuj | in tag.h | 15:26 |
| sanuj | lisitsyn, shall i remove this too?? | 15:26 |
| lisitsyn | sanuj: yeah looks like | 15:26 |
| sanuj | okay | 15:26 |
| sanuj | things look clean without Type | 15:28 |
| -!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 258 seconds] | 15:52 | |
| -!- GandalfTheWizard [~Eva@112.10.170.90] has joined #shogun | 16:13 | |
| sanuj | lisitsyn, there? | 16:22 |
| lisitsyn | sanuj: y | 16:22 |
| sanuj | lisitsyn, %newobject with_layer(CNeuralLayer* layer); in NeuralNets.i | 16:23 |
| sanuj | this should fix the problem ? | 16:23 |
| lisitsyn | not sure | 16:23 |
| lisitsyn | probably you'd need %newobject for all layer-returning things | 16:23 |
| lisitsyn | like | 16:23 |
| lisitsyn | with_layer, relu, blabla | 16:24 |
| sanuj | yeah | 16:24 |
| sanuj | but | 16:24 |
| sanuj | it was cpp translation that was segfaulting | 16:24 |
| sanuj | and we are changing swig | 16:24 |
| lisitsyn | oops that's true | 16:24 |
| sanuj | :D | 16:24 |
| sanuj | lisitsyn, another fix then? | 16:24 |
| lisitsyn | seems like | 16:25 |
| sanuj | i tried this and it didn't work | 16:25 |
| sanuj | and then i realized why am i changing swig for this | 16:25 |
| sanuj | :P | 16:25 |
| lisitsyn | yeah yeah sorry my bad | 16:25 |
| sanuj | lisitsyn, no need to say sorry :D | 16:26 |
| lisitsyn | ok I think I need to handle that in some.h | 16:26 |
| sanuj | lisitsyn, are you doing it now? | 16:34 |
| lisitsyn | sanuj: yep | 16:34 |
| sanuj | cool | 16:34 |
| sanuj | i'm trying to run it in python | 16:35 |
| sanuj | lisitsyn, i have added %newobject for all the methods but it still segfaults in python | 16:46 |
| lisitsyn | sanuj: ok this doesn't help | 16:46 |
| lisitsyn | lets see if my patch does | 16:46 |
| lisitsyn | it should be done anyway | 16:47 |
| sanuj | okay | 16:47 |
| sanuj | heiko will want a different patch for this | 16:47 |
| sanuj | lisitsyn, shall i send a separate PR for this even if there is no effect? | 16:47 |
| lisitsyn | sanuj: %newobject? | 16:47 |
| lisitsyn | not sure | 16:47 |
| sanuj | what else might be causing the error in python? | 16:48 |
| sanuj | btw | 16:49 |
| sanuj | this works in python | 16:50 |
| sanuj | lisitsyn, all_layers = layers.input(num_feats).linear(50).softmax(2).done() | 16:50 |
| sanuj | was done like this in the old modular example | 16:50 |
| sanuj | i think ^^ is where it really shines, otherwise no point returning CNeuralLayers* | 16:51 |
| sanuj | but not possible in cookbook | 16:51 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 17:02 | |
| shogun-notifier- | shogun: Sergey Lisitsyn :develop * be31693 / src/shogun/base/some.h,tests/unit/base/Some_unittest.cc: https://github.com/shogun-toolbox/shogun/commit/be31693193e280c91e9346a2f6a9449fc98505ae | 17:02 |
| shogun-notifier- | shogun: Handle self-assignment of some | 17:02 |
| shogun-notifier- | shogun: | 17:02 |
| shogun-notifier- | shogun: Don't do anything when pointer is self-assigned. | 17:02 |
| shogun-notifier- | shogun: This resolves possible crashes then something | 17:02 |
| lisitsyn | sanuj: here you go | 17:02 |
| shogun-notifier- | shogun: with reference 1 is being self-assigned and deleted | 17:02 |
| sanuj | lisitsyn, okay, i'll pull | 17:03 |
| sanuj | lisitsyn, but what do you think about the things i said before | 17:03 |
| sanuj | all_layers = layers.input(num_feats).linear(50).softmax(2).done() | 17:03 |
| lisitsyn | I am not sure I get it | 17:03 |
| sanuj | lisitsyn, this is how these layers were added in python in old modular examples | 17:04 |
| lisitsyn | yes | 17:04 |
| sanuj | if we don't do this, then what is the point of returning CNeuralLayers*? | 17:05 |
| lisitsyn | well we just don't do this in meta examples | 17:05 |
| lisitsyn | due to limitations | 17:05 |
| lisitsyn | this can be changed at some point | 17:05 |
| sanuj | okay | 17:05 |
| sanuj | because if we don't do it in meta examples | 17:05 |
| sanuj | no one will | 17:06 |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has joined #shogun | 17:10 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 17:10 | |
| shogun-buildbot | build #51 of xenial - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/51 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 17:11 |
| shogun-buildbot | build #2910 of bsd1 - libshogun is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2910 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 17:12 |
| sanuj | lisitsyn, get and getInt are working from swig | 17:16 |
| lisitsyn | cool | 17:16 |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Quit: Leaving.] | 17:18 | |
| sanuj | lisitsyn, there is something fishy | 17:18 |
| sanuj | going on | 17:18 |
| sanuj | gk.has("width") | 17:19 |
| sanuj | this also works | 17:19 |
| sanuj | which shouldn't | 17:19 |
| sanuj | because Tag constructor is explicit | 17:19 |
| sanuj | oh ignore ^^ | 17:20 |
| lisitsyn | ok ;) | 17:21 |
| sanuj | lisitsyn, one more thing | 17:23 |
| sanuj | we have | 17:23 |
| sanuj | has(const Tag<T>& tag) | 17:23 |
| sanuj | has_type(const std::string& name) | 17:23 |
| sanuj | shall i convert has_type to hasInt etc | 17:24 |
| sanuj | just like for get and set | 17:24 |
| lisitsyn | sanuj: could you please rename has_type into has | 17:25 |
| lisitsyn | just template it | 17:25 |
| lisitsyn | and then yes | 17:25 |
| lisitsyn | do the same | 17:25 |
| sanuj | yeah that's what i meant | 17:25 |
| lisitsyn | because has_type is not really a good name - makes me think we're talking about the type of object | 17:26 |
| lisitsyn | not the type of parameter | 17:26 |
| sanuj | cool | 17:26 |
| sanuj | lisitsyn, what else to do in swig? | 17:27 |
| sanuj | and can i push the swig changes on my tags PR? | 17:28 |
| lisitsyn | sanuj: yeah please do | 17:29 |
| lisitsyn | sanuj: add more types then | 17:29 |
| sanuj | lisitsyn, all the types from my gist? | 17:30 |
| lisitsyn | sanuj: yes | 17:30 |
| lisitsyn | do some macro | 17:30 |
| lisitsyn | to simplify that | 17:30 |
| lisitsyn | if possible | 17:30 |
| sanuj | okay | 17:30 |
| sanuj | lisitsyn, the neuralnet cookbook is working now | 17:30 |
| sanuj | thanks for your changes :) | 17:31 |
| lisitsyn | good to hear | 17:31 |
| sanuj | and %newobject also worked for python | 17:31 |
| sanuj | i had changed the .i file in the build last time so was not working | 17:31 |
| sanuj | lisitsyn, if i add all the types, it is going to be huge | 17:35 |
| shogun-buildbot | build #453 of deb1 - libshogun - PR is complete: Failure [failed cookbook] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun%20-%20PR/builds/453 blamelist: OXPHOS | 17:42 |
| shogun-buildbot | build #454 of deb1 - libshogun - PR is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun%20-%20PR/builds/454 | 17:42 |
| lisitsyn | sanuj: we have to | 17:47 |
| lisitsyn | you can simplify that somehow | 17:47 |
| lisitsyn | using macroses may be | 17:47 |
| sanuj | yeah | 17:47 |
| -!- mizari [~mizari@95-174-213-100.nts.su] has quit [Quit: Leaving] | 17:53 | |
| shogun-buildbot | build #39 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/39 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 17:55 |
| sanuj | lisitsyn, do i need to have pointers for some classes also as types? | 18:34 |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has joined #shogun | 19:19 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 19:19 | |
| @HeikoS | sanuj: hi | 19:24 |
| sanuj | HeikoS, yo | 19:24 |
| @HeikoS | is the gmm example working now? | 19:24 |
| @HeikoS | in travis? | 19:24 |
| sanuj | you had disabled R right? | 19:24 |
| sanuj | after that it is working | 19:25 |
| @HeikoS | ok | 19:26 |
| sanuj | HeikoS, how was weekend? | 19:26 |
| @HeikoS | sanuj: "is" :) | 19:26 |
| @HeikoS | it is great | 19:26 |
| @HeikoS | and relaxed | 19:26 |
| @HeikoS | and yours? | 19:26 |
| sanuj | haha | 19:26 |
| sanuj | it is about to get over | 19:26 |
| sanuj | here | 19:27 |
| sanuj | mine was also good | 19:27 |
| sanuj | HeikoS, what do you plan to do after PhD? | 19:27 |
| @HeikoS | sanuj: I dont have a plan yet | 19:28 |
| sanuj | you must have thought something before you started your phd | 19:28 |
| sanuj | i'm asking because i need to decide myself | 19:28 |
| sanuj | about research | 19:28 |
| @HeikoS | sanuj: about whether to do a phd or not? | 19:29 |
| sanuj | yeah | 19:29 |
| @HeikoS | its very different | 19:29 |
| @HeikoS | what to do after a phd | 19:29 |
| @HeikoS | and whether to do a phd | 19:29 |
| @HeikoS | I like mine | 19:29 |
| @HeikoS | would reccomend doing one, but also reccomend finding a nice group and a nice topic | 19:30 |
| shogun-notifier- | shogun: Saurabh7 :develop * d2c595b / src/shogun/evaluation/CrossValidation.cpp: https://github.com/shogun-toolbox/shogun/commit/d2c595b4b97ea4673b5e25001173c33c1d4c5b60 | 19:30 |
| shogun-notifier- | shogun: Fix evaluation | 19:30 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * d4dfe2e / src/shogun/evaluation/CrossValidation.cpp: https://github.com/shogun-toolbox/shogun/commit/d4dfe2e048fcfb2c5c8587a2dd23aa6d21973fd9 | 19:30 |
| shogun-notifier- | shogun: Merge pull request #3279 from Saurabh7/xvalfix | 19:30 |
| shogun-notifier- | shogun: | 19:30 |
| shogun-notifier- | shogun: Fix evaluation xval | 19:30 |
| sanuj | yeah | 19:30 |
| @HeikoS | sanuj: when would you start? | 19:30 |
| @HeikoS | did you do a msc? | 19:30 |
| sanuj | nope | 19:31 |
| sanuj | just completed my bachelors | 19:31 |
| @HeikoS | I see | 19:31 |
| @HeikoS | if you are not sure yet | 19:31 |
| @HeikoS | maybe a masters is good | 19:31 |
| sanuj | i'm planing to spend an year in academia doing interns | 19:31 |
| @HeikoS | I found the area I am working in now durin gthat | 19:31 |
| @HeikoS | and after the msc I worked at uni for another year before I started phd | 19:31 |
| sanuj | i see | 19:31 |
| @HeikoS | I think it is good to take time to decide such things | 19:31 |
| sanuj | yes, true | 19:32 |
| @HeikoS | sanuj: thats why I am not in a rush with planning things after phd | 19:32 |
| sanuj | i see | 19:32 |
| @HeikoS | rather do something else or related or a year before I go ahead full speed | 19:32 |
| sanuj | that's why i'm planing to do research interns for an year | 19:32 |
| @HeikoS | yeah very good idea | 19:34 |
| @HeikoS | and cheaper than a msc .) | 19:34 |
| sanuj | yes :) | 19:35 |
| sanuj | and if i get funding then even better | 19:35 |
| sanuj | HeikoS, i think i found a bug in combinedkernel.cpp | 19:36 |
| @HeikoS | sanuj: what is it? | 19:38 |
| shogun-buildbot | build #52 of xenial - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/52 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com> | 19:38 |
| sanuj | HeikoS, can you open the file | 19:38 |
| sanuj | HeikoS, line 79 | 19:38 |
| shogun-buildbot | build #2911 of bsd1 - libshogun is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2911 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com> | 19:38 |
| sanuj | HeikoS, you had asked me to init() combinerkernel without combinedfeatures for the cookbook | 19:39 |
| @HeikoS | opening .... | 19:39 |
| @HeikoS | for (index_t i=0; i<get_num_subkernels(); ++i) | 19:40 |
| sanuj | it fails if we have a custom kernel | 19:40 |
| @HeikoS | thats line 79 | 19:40 |
| sanuj | yes | 19:40 |
| sanuj | because for custom kernel we don't need features to initialize | 19:40 |
| sanuj | so if there are 3 kernel in a combined kernel | 19:40 |
| sanuj | and one of them is a custom kernel | 19:40 |
| sanuj | this will append 3 feature obj to combined feature | 19:41 |
| sanuj | but we would only need 2 | 19:41 |
| sanuj | feature objs | 19:41 |
| sanuj | HeikoS, what do you think? | 19:41 |
| sanuj | i have checked it | 19:42 |
| @HeikoS | the custom kernel has these dummy features | 19:42 |
| sanuj | it fails with error "CombinedKernel: Number of features/kernels does not match - bailing out" | 19:42 |
| @HeikoS | that can be created from other features | 19:42 |
| @HeikoS | I see | 19:42 |
| sanuj | yes | 19:42 |
| @HeikoS | should fix that | 19:42 |
| sanuj | i'll send a PR | 19:42 |
| @HeikoS | sanuj: unit test it | 19:43 |
| sanuj | okay | 19:43 |
| sanuj | HeikoS, and the fix is ==> only append features if kernel is not a custom kernel | 19:44 |
| sanuj | right? | 19:44 |
| @HeikoS | not sure | 19:47 |
| @HeikoS | the features should always match the kernel | 19:47 |
| @HeikoS | It is hard to tell now because I dont quite understand what you are doing, a unit test would be the best thing | 19:48 |
| @HeikoS | that is a use case where we know how the thing should behave internally | 19:48 |
| sanuj | HeikoS, if you see here https://github.com/shogun-toolbox/shogun/pull/3250/files#diff-a103b37f00e07d88a3d3df79bc7d8dbdR21 | 19:49 |
| sanuj | i have 3 kernels and 2 features and it works | 19:49 |
| sanuj | if i put 3 kernels and 3 features it fails | 19:50 |
| sanuj | because of custom kernel | 19:50 |
| @HeikoS | lisitsyn: jo | 19:50 |
| @HeikoS | it should have 3 and 3 each | 19:51 |
| @HeikoS | that is, dummy features for the custom kernel | 19:51 |
| sanuj | okay | 19:51 |
| @HeikoS | OR | 19:51 |
| @HeikoS | you can also add a method inits the same features for all kernels | 19:51 |
| lisitsyn | HeikoS: hej | 19:52 |
| @HeikoS | lisitsyn: were you involved in the multiclass error code stuff? | 19:52 |
| lisitsyn | HeikoS: a little bit | 19:53 |
| lisitsyn | why? | 19:53 |
| @HeikoS | lisitsyn: got a reference? | 19:53 |
| @HeikoS | See the cookbook | 19:53 |
| @HeikoS | OXPHOS needs a reference | 19:53 |
| lisitsyn | ECOC? | 19:53 |
| lisitsyn | http://www.jmlr.org/papers/volume11/escalera10a/escalera10a.pdf | 19:54 |
| lisitsyn | what about this one? | 19:55 |
| @HeikoS | good! | 19:55 |
| lisitsyn | or its references | 19:55 |
| lisitsyn | I mean it is a library and it should reference all the major stuff | 19:55 |
| @HeikoS | yeah perfect | 19:56 |
| lisitsyn | HeikoS: we're going to have all that parameters stuff quite soon | 19:56 |
| @HeikoS | lisitsyn: great | 19:56 |
| @HeikoS | what are the next steps? | 19:56 |
| @HeikoS | cereal can begin then right=? | 19:56 |
| lisitsyn | HeikoS: polish it and start working on plugins | 19:56 |
| @HeikoS | should be much easier | 19:56 |
| lisitsyn | yes | 19:56 |
| @HeikoS | do you plan to remove all SG_ADD calls? | 19:57 |
| lisitsyn | HeikoS: I thought of rewriting SG_ADD a bit so it injects into the new approach | 19:57 |
| lisitsyn | so both old and new getters and setters work | 19:57 |
| @HeikoS | lisitsyn: also good | 19:57 |
| @HeikoS | well old getters | 19:57 |
| @HeikoS | I would all remove | 19:58 |
| @HeikoS | and setters | 19:58 |
| @HeikoS | at least try to | 19:58 |
| @HeikoS | so that we have a unified get/set at least | 19:58 |
| @HeikoS | mostly grep | 19:58 |
| lisitsyn | HeikoS: I think injecting the new thing would be less dangerous | 19:58 |
| @HeikoS | yeah that I would do | 19:58 |
| lisitsyn | it is true but I am a bit scaried | 19:58 |
| @HeikoS | but the getter/setter I mean | 19:58 |
| lisitsyn | at such massive scale bad things happen | 19:58 |
| @HeikoS | mmh yeah | 19:58 |
| sanuj | HeikoS, can you merge https://github.com/shogun-toolbox/shogun/pull/3283 | 19:59 |
| lisitsyn | sanuj: btw do we have to use %newobject after my fix? | 19:59 |
| lisitsyn | I am a bit lost whether it is needed still | 19:59 |
| sanuj | lisitsyn, yes | 19:59 |
| sanuj | for python etc | 19:59 |
| lisitsyn | ok I see | 19:59 |
| sanuj | how will some fix other languages? | 20:00 |
| @HeikoS | lisitsyn: can you merge and check this? | 20:00 |
| lisitsyn | HeikoS: ok | 20:00 |
| lisitsyn | HeikoS: well I started this | 20:00 |
| lisitsyn | HeikoS: there was a bug in 'some' and this builder stuff has to have %newobject | 20:01 |
| @HeikoS | yep | 20:01 |
| sanuj | HeikoS, can i valgrind non cpp stuff? | 20:01 |
| lisitsyn | for sure | 20:01 |
| sanuj | oh didn't know that | 20:01 |
| lisitsyn | you can valgrind any program 'cause it is C or C++ inside anyway :P | 20:02 |
| @HeikoS | sanuj: it wont help though | 20:02 |
| @HeikoS | just realised | 20:02 |
| sanuj | lisitsyn, haha | 20:02 |
| @HeikoS | lisitsyn: any idea how to verify pythons refcounts? | 20:02 |
| lisitsyn | HeikoS: should be some library | 20:03 |
| lisitsyn | well valgrind could help but it would get a little bit of noise | 20:03 |
| sanuj | https://pythonhosted.org/Pympler/muppy.html | 20:04 |
| lisitsyn | python: the good parts | 20:04 |
| lisitsyn | there is a library for everything | 20:04 |
| sanuj | lisitsyn, and good big integer for competitive coding problems :P | 20:05 |
| shogun-notifier- | shogun-data: OXPHOS :master * 3b7d763 / testsuite/meta/classifier/multiclass_ecoc_random.dat: https://github.com/shogun-toolbox/shogun-data/commit/3b7d763409cc5fbfd01b97a96c674898447dda98 | 20:07 |
| shogun-notifier- | shogun-data: eco_random | 20:07 |
| shogun-notifier- | shogun-data: Heiko Strathmann :master * e4159a7 / testsuite/meta/classifier/multiclass_ecoc_random.dat: https://github.com/shogun-toolbox/shogun-data/commit/e4159a7250a2995342e38c870bdc0d0a1e1c1290 | 20:07 |
| shogun-notifier- | shogun-data: Merge pull request #98 from OXPHOS/master | 20:07 |
| shogun-notifier- | shogun-data: | 20:07 |
| shogun-notifier- | shogun-data: integration test data - multi-class_ecoc_random | 20:07 |
| @HeikoS | lisitsyn, sanuj btw | 20:07 |
| @HeikoS | WHY does this neural net stuff always create a new object? | 20:07 |
| @HeikoS | wouldnt it modify itself and return itself? | 20:07 |
| lisitsyn | HeikoS: it doesn't | 20:07 |
| @HeikoS | why do we need newobject then? | 20:08 |
| lisitsyn | HeikoS: I think what happens is that swig unrefs the original object | 20:08 |
| lisitsyn | and then refs the same object | 20:08 |
| lisitsyn | but I am not sure | 20:08 |
| @HeikoS | oh I see | 20:08 |
| lisitsyn | this is what was happening in cpp | 20:08 |
| @HeikoS | like when a method returns self instance | 20:08 |
| lisitsyn | yes | 20:08 |
| @HeikoS | ok | 20:08 |
| @HeikoS | then the patch can be merged I guess | 20:08 |
| @HeikoS | Saurabh7: hi! | 20:09 |
| @HeikoS | sanuj: you mentioned you might have a swig example for using tags? | 20:09 |
| @HeikoS | I can already start thinking how that goes into the meta examples | 20:09 |
| lisitsyn | HeikoS: once swig+tags | 20:09 |
| lisitsyn | yes | 20:09 |
| lisitsyn | exactly | 20:09 |
| sanuj | HeikoS, yes | 20:10 |
| sanuj | we made some changes today | 20:10 |
| sanuj | HeikoS, you remember the gist for base shogun interface | 20:10 |
| @HeikoS | no :) | 20:12 |
| sanuj | let me get that | 20:12 |
| sanuj | HeikoS, https://gist.github.com/sanuj/56f03cd242473137fad851e68fa0f2c1 | 20:12 |
| sanuj | for which you told me to make a tree diagram | 20:13 |
| sanuj | which is still due :P | 20:13 |
| sanuj | so we are doing --> %template(set) CSGObject::set<int>; for all these classes | 20:13 |
| -!- GandalfTheWizard [~Eva@112.10.170.90] has quit [Quit: Leaving.] | 20:13 | |
| shogun-buildbot | build #40 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/40 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com> | 20:16 |
| @HeikoS | sanuj: not sure I am following | 20:19 |
| sanuj | HeikoS, we need to instantiate templates in swig for every type that we want to expose | 20:19 |
| @HeikoS | Ah yes I see | 20:20 |
| @HeikoS | sure | 20:20 |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Quit: Leaving.] | 20:22 | |
| sanuj | going to sleep | 20:24 |
| sanuj | goodnight | 20:24 |
| -!- sanuj [~sanuj@117.203.8.81] has quit [Quit: Leaving] | 20:28 | |
| -!- sonne|osx [~sonne@x4e31fd0a.dyn.telefonica.de] has joined #shogun | 22:08 | |
| -!- sonne|osx [~sonne@x4e31fd0a.dyn.telefonica.de] has quit [Quit: sonne|osx] | 22:34 | |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 23:07 | |
| --- Log closed Mon Jun 13 00:00:37 2016 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!