IRC logs of #shogun for Monday, 2019-04-08

« Sunday, 2019-04-07 Index Tuesday, 2019-04-09 »
--- Log opened Mon Apr 08 00:00:27 2019
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun00:29
-!- mode/#shogun [+o wiking] by ChanServ00:29
-!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection]00:36
-!- wiking [~wiking@c-185-45-237-122.customer.ggaweb.ch] has joined #shogun00:45
-!- wiking [~wiking@c-185-45-237-122.customer.ggaweb.ch] has quit [Changing host]00:45
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun00:45
-!- mode/#shogun [+o wiking] by ChanServ00:45
-!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection]02:48
-!- wiking [~wiking@c-185-45-237-122.customer.ggaweb.ch] has joined #shogun03:56
-!- wiking [~wiking@c-185-45-237-122.customer.ggaweb.ch] has quit [Changing host]03:56
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun03:56
-!- mode/#shogun [+o wiking] by ChanServ03:56
-!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 252 seconds]04:00
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun07:18
-!- mode/#shogun [+o wiking] by ChanServ07:19
-!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection]07:36
-!- Moatman [~Moatman@pool-96-255-151-151.washdc.fios.verizon.net] has quit [Remote host closed the connection]07:43
-!- wiking_ [~wiking@c-185-45-237-122.customer.ggaweb.ch] has joined #shogun07:58
-!- wiking_ [~wiking@c-185-45-237-122.customer.ggaweb.ch] has quit [Remote host closed the connection]08:45
-!- wiking [~wiking@ict-networks-195-176-113-034.fwd-v4.ethz.ch] has joined #shogun09:49
-!- wiking [~wiking@ict-networks-195-176-113-034.fwd-v4.ethz.ch] has quit [Changing host]09:49
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun09:49
-!- mode/#shogun [+o wiking] by ChanServ09:49
-!- gf712 [90520840@gateway/web/freenode/ip.144.82.8.64] has joined #shogun10:14
@wikinghah gf712 we have a slight problem https://github.com/openml/openml-python/pull/64711:11
@wiking:)11:11
@wikingthis is instead of my pr :)))11:11
@wikingbut at least there's a way now and that can be directly added to this repo... one would hope11:13
-!- geektoni [c1cdd24a@gateway/web/freenode/ip.193.205.210.74] has joined #shogun11:14
gf712wiking: let me have a look at the new master branch11:21
@wikingk11:21
gf712they added stubs and everything :p11:21
gf712wiking: it does look pretty similar11:23
@wikingyeah11:23
gf712should be able to get something working with that today11:23
@wikingand its pretty annoying11:23
@wikingthat all the commits are not taken from me11:23
@wikingso it's kind of like11:23
@wikingfu11:23
@wiking:)11:23
gf712yea..11:23
@wikingbut whatever11:24
gf712we can always just write a shogun version and connect directly to the rest api :p11:24
gf712there is an issue with running regressors btw11:25
gf712as in, it doesn't support it11:25
gf712so I had to add some checks for shogun, need to checks if they fixed it11:25
@wiking:>>11:28
@wikingdunno if i should comment anything on this11:28
@wikingbut this is pretty lame imo11:28
gf712yup, very lame...11:39
gf712wiking: need some help with memory management with swig btw11:40
@wikingsup sup11:40
gf712I don't understand an error I am getting, where swig is calling the destructor of an object11:40
gf712but then get a a bad access error11:40
gf712I think me using unique ptr in class members might be messing up something11:41
gf712have you had any issues with that?11:41
@wikingmmmm11:44
@wikingnot really11:44
@wikingbut i mean if you dont expose unique_ptr to swig11:45
@wikingit shouldn't be a problem or?11:45
gf712no, it shouldn't...11:45
gf712the destructor seems to be called properly11:45
@wikingyou can lldb the swig11:45
@wikinginterface cxx as well11:45
gf712but then in the swig wrapper11:45
@wikingwhat happens there11:45
gf712delete arg1;11:45
@wiking?11:45
gf712causes an error11:45
@wikingarg1 is nullptr?11:46
gf712no11:46
@wikinginvalid mem?11:46
gf712it points to the object11:46
gf712but it seems like the object is in protected memory?11:46
gf712p arg111:47
gf712(shogun::GridParameters *) $0 = 0x0000000100694c5011:47
gf712it's clearly there11:47
@wikingp *arg1 ?11:47
@wikingso i mean when you try to reference that mem region11:47
gf712yea I can get it too11:47
@wikingmmmm11:47
@wikingthat is even weirder11:48
gf712but the size of the maps is huge11:48
@wikingcoz then there should be no problems11:48
@wikingah11:48
@wikingmmmmm11:48
gf712which makes no sense11:48
@wikingmaybe then the problem is actually somewhere else :)))11:48
gf712it seems like it is pointing at the wrong thing11:48
@wikingmaybe there was a buffer overflow somewhere and that messed up your mem11:48
gf712but from the debug messages everything is fine...11:48
@wikingbut you actually see the error here11:49
gf712hmmm11:49
@wikingi've head this b411:49
gf712let me print out the map sizes11:49
@wiking*had11:49
gf712you think there might be some recursion going on?11:49
@wikingthat actually some memory corruption caused a total different bug11:49
gf712and that causes an overflow?11:49
gf712ah ok11:49
@wikingbut the memory fuckup11:49
@wikinghappened somewhere else11:49
@wiking:)11:49
@wikingso first11:50
@wikingcan you run the same code11:50
@wikingi mean essentially the same thing in c++11:50
@wikingand run valgrind on it11:50
@wikingjust to see if everything is ok on the c codebase11:50
@wiking(you can do the printf story as well, but this is more pragmatic)11:50
@wiking;)11:50
@wiking:>11:50
gf712yea, let me check valgrind11:51
@wikingah fuck11:51
gf712talking about that11:51
@wikinggo on donbot11:51
@wikingas macaos will not work11:51
@wiking:)11:51
@wikingor idk11:52
@wikingmaybe it is fixed11:52
gf712valgrind in latest macOS don't work11:52
@wikingyeah11:52
@wikinggo to donbot11:52
gf712ah11:52
@wikingi haven't tried valgrind like 5 years now on macos11:52
@wiking:D11:52
@wikingas for me it's default that it doesn't work11:52
@wikingyou can use instruments though11:52
@wikingit has memleak and stuff11:52
@wikinguses dtrace11:52
@wikingpretty awesome11:52
@wiking:)11:52
gf712ah ok, I only ever use memcheck11:54
@wikingmemcheck?11:54
@wikinginstruments is part of Xcode11:54
gf712oh right11:54
@wikingyou should have it as you can compile stuff11:54
@wiking:D11:54
gf712I got it the other day for CoreML stuff :p11:54
@wiking:DDDDD11:54
gf712got this 6gb beast11:54
gf712which of course wants to update again11:55
gf712wiking: just ran Valgrind on a local linux machine and there is an issue with unique_ptr and CSGObject11:56
gf712:(11:56
@wikingque?12:02
@wikingwhat?12:02
@wikingcan you pastebin it plz12:02
-!- gf712_ [8028b351@gateway/web/freenode/ip.128.40.179.81] has joined #shogun12:08
gf712_wiking: https://pastebin.com/m3bvz7cu12:08
@wikingits about sqrtdiag_lhs and sqrtdiag_rhs i guess12:12
@wikingmmm does this happen with develop as is ?12:13
@wikingi guess so12:15
gf712need to check12:16
gf712but I am not sure if it could be an issue with wrapping it in a unique_ptr?12:16
gf712I think using the raw pointer working fine12:16
gf712worked12:16
@wikingwhat's wrapped in unique_ptr?12:18
gf712the CSGObject12:20
gf712basically I clone it12:20
gf712and keep it a unique_ptr12:20
gf712maybe should just stick to raw pointers..12:20
gf712wiking: m_parent = std::unique_ptr<CSGObject>(model->clone());12:23
@wikingmmmm12:25
@wikingand you clone that? :)12:25
gf712yea, I mean I could move12:25
gf712the r value12:25
gf712but I don't want to take over ownership12:26
gf712because I don't want the user to do something funky12:26
gf712and then gridsearch gets confused :/12:26
@wikingyeah12:27
@wikingok wait12:27
@wikingthe obj that contains m_parent12:28
@wikingis not an SGObject or?12:28
gf712no12:28
gf712it doesn't inherit from anything12:28
gf712ah I think I found an issue12:29
gf712when the ptr is destroyed it seems to call the SGObject destructor, which is virtual?12:30
gf712ah no12:30
gf712nvm12:30
gf712ok, I get it now12:32
gf712shouldn't clone it12:32
gf712because that creates a CSGObject12:33
gf712and not the derived class12:33
gf712when I tried to debug I noticed that I was calling pure virtual functions from CSGObject12:34
-!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection]13:14
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun13:23
-!- mode/#shogun [+o wiking] by ChanServ13:23
-!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 244 seconds]13:28
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun13:42
-!- mode/#shogun [+o wiking] by ChanServ13:42
-!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection]13:45
-!- wiking [~wiking@c-185-45-237-122.customer.ggaweb.ch] has joined #shogun13:49
-!- wiking [~wiking@c-185-45-237-122.customer.ggaweb.ch] has quit [Changing host]13:49
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun13:49
-!- mode/#shogun [+o wiking] by ChanServ13:49
-!- amarisch [c3b0705b@gateway/web/freenode/ip.195.176.112.91] has joined #shogun13:58
-!- amarisch [c3b0705b@gateway/web/freenode/ip.195.176.112.91] has quit [Client Quit]13:59
-!- amarisch [c3b0705b@gateway/web/freenode/ip.195.176.112.91] has joined #shogun14:03
-!- geektoni [c1cdd24a@gateway/web/freenode/ip.193.205.210.74] has quit [Quit: Page closed]14:19
gf712wiking: how are %newobject instances garbage collected? how does it differ between sgobject and non sgobject?14:20
gf712I think the issue I am having is there14:20
-!- amarisch [c3b0705b@gateway/web/freenode/ip.195.176.112.91] has quit [Ping timeout: 256 seconds]14:26
-!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection]16:24
-!- wiking [~wiking@c-185-45-237-122.customer.ggaweb.ch] has joined #shogun16:27
-!- wiking [~wiking@c-185-45-237-122.customer.ggaweb.ch] has quit [Changing host]16:27
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun16:27
-!- mode/#shogun [+o wiking] by ChanServ16:27
-!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 250 seconds]16:34
-!- gf712_ [8028b351@gateway/web/freenode/ip.128.40.179.81] has quit [Quit: Page closed]16:58
-!- gf712 [90520840@gateway/web/freenode/ip.144.82.8.64] has quit [Ping timeout: 256 seconds]17:04
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun18:18
-!- mode/#shogun [+o wiking] by ChanServ18:18
-!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 268 seconds]21:14
-!- besser82 [~besser82@fedora/besser82] has joined #shogun21:23
-!- mode/#shogun [+o besser82] by ChanServ21:23
-!- durovo [~durovo@99.b3.3da9.ip4.static.sl-reverse.com] has quit [Read error: Connection reset by peer]21:57
-!- durovo2 [~durovo@99.b3.3da9.ip4.static.sl-reverse.com] has joined #shogun21:57
--- Log closed Tue Apr 09 00:00:28 2019
« Sunday, 2019-04-07 Index Tuesday, 2019-04-09 »

Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!