IRC logs of #shogun for Wednesday, 2016-06-08

--- Log opened Wed Jun 08 00:00:30 2016
@lambday	OXPHOS: yeah	00:26
@lambday	OXPHOS: looks okay	00:29
OXPHOS	lambday: cool thx	00:29
@lambday	OXPHOS: although the results don't really make much sense.. we gotta figure out what's wrong..	00:30
@lambday	OXPHOS: I mean, why did the eigen3 one change?	00:30
@lambday	OXPHOS: looks okay	00:30
OXPHOS	u mean the sg_linalg eigien3?	00:31
@lambday	OXPHOS: direct eigen3 : Average time: 6.598 us, sg_linalg (eigen3) : Average time: 470743.685 us	00:31
@lambday	no direct eigen3 changed	00:31
OXPHOS	it might be my laptop..	00:31
@lambday	OXPHOS: did you have -O3 on?	00:31
OXPHOS	clang++ -O3 yes	00:32
OXPHOS	4.655 us this time	00:32
OXPHOS	and I repeated - 1.269 us	00:33
@lambday	what I fail to get is that, why is sg_linalg eigen3 version this much slow!	00:34
OXPHOS	me too..I'm done with squash	00:35
OXPHOS	it's easier to test with benchmark file merged. So I don't have to switch branches..	00:36
@lambday	OXPHOS: yeah let me merge that	00:36
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun		00:38
shogun-notifier-	shogun: OXPHOS :feature/linalg_refactor * 48725f2 / benchmarks/linalg_refactor_benchmark.cpp: https://github.com/shogun-toolbox/shogun/commit/48725f22460a7b69df32798f8ca1d2f164723966	00:38
shogun-notifier-	shogun: CPU and GPU dot	00:38
shogun-notifier-	shogun: Soumyajit De :feature/linalg_refactor * ca09094 / benchmarks/linalg_refactor_benchmark.cpp: https://github.com/shogun-toolbox/shogun/commit/ca09094ba2be17faf1c77829eb6f26613e576b4e	00:38
shogun-notifier-	shogun: Merge pull request #3247 from OXPHOS/linalg_benchmark	00:38
shogun-notifier-	shogun:	00:38
shogun-notifier-	shogun: Linalg benchmark	00:38
OXPHOS	lambday:	00:38
OXPHOS	thx	00:38
@lambday	OXPHOS: okay now we need to clean up the other patch a bit	00:39
@lambday	once that is merged, then maybe even I can play with it	00:39
@lambday	we need to make sure that it is not show as shit	00:39
@lambday	slow*	00:39
@lambday	OXPHOS: let me comment on the other patch	00:40
OXPHOS	lambday: sure	00:40
@lambday	OXPHOS: BTW general comments - follow the coding style (newlines, indentations etc)	00:40
OXPHOS	np	00:40
@lambday	lisitsyn: can we use c++11 things directly already?	00:41
@lambday	without checking any #ifdefs?	00:41
@lambday	OXPHOS: also, maybe change the filename/classname from LinalgRefactor to SGLinalg or something	00:42
@lambday	refactor is not a very good name to have in things	00:43
OXPHOS	okay yep	00:43
@lambday	SGLinalg or Linalg whatever..	00:43
@lambday	I mean, it shouldn't have refactor	00:43
@lambday	OXPHOS: also, add BSD style header to all the new files :)	00:44
OXPHOS	Yeah i wanna distinguish with current linalg namespace. SGLinalg will definitely work	00:44
@lambday	OXPHOS: copy it from https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/statistics/HypothesisTest.h	00:45
@lambday	OXPHOS: cool!	00:45
OXPHOS	got it	00:45
OXPHOS	lambday: I tried directly call sg_linalg->get_cpu_backend()->dot(A, B); with CPUVector A, B in benchmark	00:50
OXPHOS	basically no type convert	00:50
OXPHOS	it still takes the same time as I use basevector and call sg_linalg->dot	00:50
@lambday	OXPHOS: I see..	00:52
OXPHOS	But then CPUBackend.dot() is the same as direct eigen3 call	00:53
@lambday	OXPHOS: so if CPUBackend is on heap, we get this error	00:53
@lambday	oops, not error, I mean the shitty performance	00:53
OXPHOS	yes	00:53
@lambday	weird!	00:53
OXPHOS	it's on heap	00:54
OXPHOS	and the vector and vlen in CPUVector are wrapped the same as the vector and vlen in SGVector	00:54
@lambday	yeah	00:55
@lambday	OXPHOS: commented a bit..	01:02
@lambday	OXPHOS: let's clean this up and get this merged	01:02
OXPHOS	lambday: sure. it may take a while..	01:04
@lambday	OXPHOS: yeah don't worry	01:04
@lambday	OXPHOS: oh I forgot.. maybe few things should be made const	01:04
@lambday	let me check again	01:05
OXPHOS	lambday: the GPU vector	01:05
OXPHOS	I cannot use GPUVector	01:05
OXPHOS	because it already exists	01:06
@lambday	OXPHOS: you can.. we had CGPUVector :)	01:06
@lambday	this one doesn't have the 'C'	01:06
OXPHOS	haha alright	01:07
@lambday	done	01:13
OXPHOS	lambday: thanks so much!	01:14
@lambday	OXPHOS: good job with the benchmark and the patch :)	01:15
@lambday	OXPHOS: now we just need to examine about how to make it fast	01:15
OXPHOS	lambday: thx! it took me so long.	01:16
OXPHOS	yeah it doesn't look slow	01:16
@lambday	OXPHOS: don't worry.. once we get the basics right, rest are just mostly copy-paste	01:17
OXPHOS	:D	01:17
@lambday	I mean, adding other methods	01:17
@lambday	apart from dot	01:17
OXPHOS	yeah they're basically the same	01:18
OXPHOS	as before	01:19
@lambday	yea	01:20
@lambday	but sg_linalg->get_cpu_backend()->dot(A, B); is slow whereas CPUBackend.dot() is the same as direct eigen3 call (!!)	01:20
* lambday wonders		01:20
@lambday	:/	01:21
-!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Quit: buildmaster reconfigured: bot disconnecting]		01:21
-!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun		01:21
@lambday	I mean, yes it is two methods calls instead of just one	01:22
@lambday	but I wonder whether something like	01:23
@lambday	auto global_cpu_backend = sg_linalg->get_cpu_backend();	01:23
@lambday	for (iterations)	01:23
@lambday	global_cpu_backend->dot(A, B);	01:23
@lambday	would be any faster!	01:23
OXPHOS	ha	01:24
@lambday	OXPHOS: also, in the actual code, we directly use the m_cpubackend thing	01:25
@lambday	get thing should be basically free	01:25
@lambday	maybe inline them?	01:26
@lambday	anyway	01:26
@lambday	just thinking out loud	01:26
OXPHOS	it's easy to test	01:26
OXPHOS	I can just have a CPUBackend instance in Data and pass it to BENCHMARK	01:27
@lambday	yeah..	01:27
@lambday	keep one on stack and another on heap	01:27
@lambday	just the cpu backends	01:27
@lambday	and compare their performances	01:27
@lambday	it's important that we figure this out :)	01:27
@lambday	otherwise no one will ever use it :(	01:27
OXPHOS	noooooooo	01:28
OXPHOS	lambday: not helping. I have a CPUBackend instance and a unique_ptr <CPUBackend> in Data structure and passed them to the tests separately	01:34
OXPHOS	4e6 us	01:34
OXPHOS	the same as sg_linalg->set_cpu_backend()->dot()	01:34
@lambday	OXPHOS: the one on stack is fast?	01:37
OXPHOS	lambday: no..the same	01:38
OXPHOS	2.5% difference	01:39
@lambday	hah	01:39
OXPHOS	all extremely slow	01:39
@lambday	OXPHOS: okay.. now put CPUVector on stack instead and then run the previous benchmark	01:42
@lambday	I mean, directly calling CPUBackend::dot(CPUVector) without using ptrs	01:43
OXPHOS	I did?	01:43
@lambday	OXPHOS: oh the vector was also on stack	01:44
@lambday	okay let me try something	01:44
OXPHOS	oh wait	01:44
OXPHOS	no I didn't	01:44
OXPHOS	lambday: i didn't	01:45
@lambday	OXPHOS: okay	01:48
OXPHOS	lambday: CPUVector and CPUBackend both on stack, still the same results	01:50
@lambday	OXPHOS: cool..	01:51
@lambday	OXPHOS: I'm checking what might go wrong	01:51
OXPHOS	lambday: thx. it's kinda late in London right?	01:53
@lambday	OXPHOS: yeah	01:54
@lambday	00:52	01:54
@lambday	OXPHOS: will let you know if I find something interesting..	01:54
@lambday	looking forward to the cleaned up patch :)	01:54
OXPHOS	lambday: sure!	01:55
@wiking	yo	02:06
@lambday	wiking: yo	02:17
@lambday	OXPHOS: turns out, if you keep the implementation for CPUBackend::dot in the header itself (basically, get rid of the cpp), then compiler can inline things and it is just as fast	02:19
@lambday	OXPHOS: and I guess same goes for GPUBackend::dot	02:20
@lambday	OXPHOS: sorry that I asked you to move those in cpp	02:20
@lambday	ah wait	02:20
@wiking	mmm what? :)	02:20
OXPHOS	lol	02:20
@wiking	why dont you just use 'inline'	02:21
@wiking	if you really wanna inline	02:21
-!- lambday_ [6d9941c0@gateway/web/freenode/ip.109.153.65.192] has joined #shogun		02:22
-!- mode/#shogun [+o lambday_] by ChanServ		02:22
-!- lambday was kicked from #shogun by lambday_ [lambday]		02:22
@lambday_	hah	02:22
@lambday_	without the cpp, GPUbackend won't work as we designed it to, right?	02:23
OXPHOS	lambday_ you can kick people!	02:23
@lambday_	OXPHOS: brwahahahaha	02:23
OXPHOS	the old linalg are all in .h I guess .cpp is for GPU purpose	02:23
@wiking	you want to be able to have opaques :)	02:24
@lambday_	wiking: yeah	02:24
@wiking	but then again if inline is your problem just inline the function.	02:24
@wiking	explicitly	02:24
@lambday_	wiking: but that would make the header dependent on the backend lib directly, isn't it	02:28
@lambday_	for making things inline, it should be in the header itself	02:29
@wiking	lambday_: what?:	02:29
@wiking	you can inline a function	02:29
@wiking	in cpp	02:30
@lambday_	for making things inline, it should be in the header itself	02:30
@wiking	again	02:31
@wiking	class A { inline void a(); }	02:31
@wiking	then inline void A:a() {}	02:31
@wiking	should work	02:31
@lambday_	wiking: really? didn't know that!	02:31
@wiking	i mean you save there a simple function call	02:32
@wiking	which in case of c	02:32
@wiking	is quite low the overhead	02:32
@lambday_	wiking: I don't think this inlining works	02:32
@wiking	+ stack stuff	02:32
@wiking	lambday_: check c++ standard	02:33
@lambday_	wiking: well, actually I have been playing with this thing.. tried two different versions.. one with inlined and another in cpp..	02:33
@wiking	but it's up to the compiler	02:33
@wiking	to take it in consideration	02:33
@lambday_	seems like there is quite a lot of difference	02:33
@wiking	it's a constant time	02:33
@wiking	right?	02:33
@lambday_	wiking: let me show you the results	02:33
@lambday_	wiking: I don't think this inlining works	02:34
@wiking	unless you dot product like vectors of size 2	02:34
@wiking	lambday_: again	02:34
@wiking	read what i write	02:34
@wiking	02:32 <@wiking> but it's up to the compiler	02:34
@wiking	02:32 <@wiking> to take it in consideration	02:34
@wiking	if you really want to have inlining	02:35
@wiking	use macros	02:35
@wiking	"just a suggestion not compulsion. Compiler may or may not inline the functions you marked as inline. It may also decide to inline functions not marked as inline at compilation or linking time"	02:35
@lambday_	wiking: functions that are defined in the header have higher chances to get inlined..	02:36
@lambday_	wiking: but anyway the point was	02:36
@lambday_	inlining makes a huge difference in the test case I was working on	02:37
@lambday_	it's not a constant overhead	02:37
@wiking	but it should be	02:37
@wiking	:)	02:37
@lambday_	maybe it's because it calls eigen dot.. which is super optimized if inlined	02:37
@wiking	then you are measuring something wrong	02:37
@wiking	+ if you inline functions a lot	02:38
@wiking	you gonna be trashing the memory a lot	02:38
@wiking	=> lot of page faults	02:38
@lambday_	wiking: I understand that.. but nonetheless the test-case is important	02:39
@lambday_	let me show you the files..	02:39
@wiking	yes but it something wrong	02:39
@wiking	unless of course	02:41
@wiking	you pass not a reference but the vector itself	02:41
@wiking	for the dot	02:41
@wiking	because then the stack copy is gonna be function of the input	02:41
@wiking	btw in most of the cases inline is being used in the wrong way in shogun :0	02:45
@wiking	things like this marked as inline is totally unnecessary:	02:46
@wiking	inline LIBLINEAR_REGRESSION_TYPE get_liblinear_regression_type()	02:46
@wiking	{	02:46
@wiking	return m_liblinear_regression_type;	02:46
@wiking	}	02:46
@lambday_	wiking: check (a) https://gist.github.com/lambday/774e12056299f461a4c64837298bea95 and (b) https://gist.github.com/lambday/492b40fed33e45670dd8794c9bff2bf3	02:46
@wiking	since it's defined & declared in the class	02:46
@wiking	that is automatically inline	02:46
@wiking	d	02:46
@lambday_	wiking: true	02:47
@lambday_	wiking: but I could use your inputs on this one	02:47
@wiking	what is but?	02:48
@wiking	sorry man	02:48
@wiking	but please try to get some sleep :)	02:48
@wiking	what's your compiler flags on this	02:49
@wiking	whats your compiler?	02:49
@lambday_	wiking: -O3	02:49
@lambday_	g++	02:49
@lambday_	both	02:49
@wiking	version?	02:49
@wiking	just for fun change to clang++	02:49
@lambday_	g++ -O3 -std=c++11 dot_test.cpp -I. -I/usr/include/eigen3 -lshogun -lhayai_main -o benchmark	02:50
@wiking	and btw what's your arch?	02:50
@lambday_	fedora 22 x86_64	02:51
@wiking	i asked arch	02:51
@wiking	not distro	02:51
@wiking	is it like i5 or i7 or wtf?	02:51
@lambday_	oh i5	02:51
@lambday_	clang gives similar results for the inlined one	02:52
@wiking	can you copy the flags from /proc/cpuinfo	02:52
@lambday_	checking the non-inlined version	02:52
@lambday_	fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flex	02:52
@lambday_	Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz	02:53
@lambday_	wiking: same result for clang :)	02:54
@lambday_	also, neither g++ nor clang++ inlines when we define it in the cpp and not the header	02:55
@wiking	do you know how to check the the binary for inlining?	02:55
@wiking	i.e objdump -D ...	02:55
@wiking	or there's a gcc option	02:56
@wiking	-Winline maybe?	02:56
@wiking	but yeah best is to check the difference	02:56
@wiking	between the assembler output	02:57
@lambday_	wiking: I can try objdump	02:57
@wiking	or you can do -S for gcc	02:57
@wiking	and check the assembly	02:57
@wiking	its the same as objdump	02:57
@wiking	btw how do you know it's not inlined?	02:57
@wiking	"<@lambday_> also, neither g++ nor clang++ inlines when we define it in the cpp and not the header"	02:57
@wiking	?	02:57
@lambday_	wiking: because the compiler msg says this	02:58
@lambday_	./dot.h:22:11: warning: inline function 'shogun::linalg::CPUBackend::dot<double>' is not defined [-Wundefined-inline]	02:58
@lambday_	that was for clang	02:58
@lambday_	similar msg was there for gcc	02:58
@lambday_	wiking: I can try objdump	02:58
@wiking	can you send me plz the 2 binaries somehow	02:59
@lambday_	./dot.h:22:11: warning: inline function ‘T shogun::linalg::CPUBackend::dot(const shogun::SGVector<ST>&, const shogun::SGVector<ST>&) const [with T = double]’ used but never defined	02:59
@lambday_	wiking: okay	02:59
@lambday_	mailing those to you	02:59
@lambday_	does gmail allow us to attach binaries	03:01
@wiking	dunno	03:03
shogun-buildbot	build #1016 of nightly_none is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_none/builds/1016 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Viktor Gal <vigsterkr@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com>, Sergey Lisitsyn <lisitsyn.s.o@gmail.com>, Viktor Gal <viktor.gal@maeth.com>	03:04
@lambday_	wiking: check mail	03:04
@wiking	lambday_: can you try to define the in the declaration	03:05
@wiking	of the dot function	03:05
@wiking	extern inline dot...	03:05
@wiking	and what's the output size	03:08
@wiking	of that binary	03:08
@wiking	because it's actually tooo funny	03:08
@wiking	that the 'non-inlined' one is bigger than the inline one	03:08
@lambday_	wiking: yeah I too noticed that.. not sure why that is	03:09
@wiking	so what's the output for that?	03:14
@lambday_	wiking: output for?	03:18
@lambday_	oh extern	03:18
@lambday_	how can I specify a storage class to a method?	03:19
@wiking	?	03:19
@lambday_	In file included from dot.cpp:1:0: ./dot.h:22:66: error: storage class specified for ‘dot’ extern inline T dot(const SGVector<T>& a, const SGVector<T>& b) const;	03:19
@lambday_	so either I am too sleepy and I did something wrong here.. or it's not possible	03:20
@wiking	mmm c++	03:20
@lambday_	wiking: you want to force inlining while staying in the cpp :D	03:21
@wiking	noup	03:21
@wiking	i'm just wondering	03:21
@wiking	what is the diff	03:21
@lambday_	wiking: let me know if you find anything in the binaries	03:21
@lambday_	wiking: I'm off for tonight	03:22
@lambday_	bottom line is, there is a difference and it is huge..	03:22
@wiking	mm	03:22
@lambday_	if I can't find why that is, then the design if gonna be wrong (again)	03:22
@wiking	i reckon it's measuring wrong	03:22
@lambday_	is*	03:22
@wiking	this is really smell a lot of bullshit	03:23
@wiking	that your overhead is not constant	03:23
@wiking	have you changed the size of the input?	03:23
OXPHOS	lambday_ i guess today is too long for you	03:23
@wiking	like data to be 10000 instead of 1000000	03:23
@lambday_	wiking: checking	03:24
@lambday_	OXPHOS: haha yeah	03:24
@lambday_	oh fuck it's 2:23	03:25
@lambday_	wiking: I can try testing this with google benchmark tool if you want	03:25
@lambday_	but I am pretty sure that won't gonna change the results..	03:25
@lambday_	maybe examining the binaries in details is the only way	03:26
@lambday_	anyway I'm off for tonight	03:26
@lambday_	see you tomorrow	03:26
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout]		03:38
shogun-buildbot	build #14 of clang - thread analysis is complete: Failure [failed compile] Build details are at http://buildbot.shogun-toolbox.org/builders/clang%20-%20thread%20analysis/builds/14 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Viktor Gal <vigsterkr@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com>, Sergey Lisitsyn <lisitsyn.s.o@gmail.com>, Viktor Gal	03:44
shogun-buildbot	<viktor.gal@maeth.com>	03:44
shogun-buildbot	build #13 of clang - undefined behaviour analysis is complete: Failure [failed compile] Build details are at http://buildbot.shogun-toolbox.org/builders/clang%20-%20undefined%20behaviour%20analysis/builds/13 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Viktor Gal <vigsterkr@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com>, Sergey Lisitsyn	03:48
shogun-buildbot	<lisitsyn.s.o@gmail.com>, Viktor Gal <viktor.gal@maeth.com>	03:48
-!- lambday_ [6d9941c0@gateway/web/freenode/ip.109.153.65.192] has quit [Ping timeout: 250 seconds]		03:57
shogun-buildbot	build #15 of memleak - valgrind is complete: Failure [failed memory check] Build details are at http://buildbot.shogun-toolbox.org/builders/memleak%20-%20valgrind/builds/15 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Viktor Gal <vigsterkr@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com>, Sergey Lisitsyn <lisitsyn.s.o@gmail.com>, Viktor Gal	05:29
shogun-buildbot	<viktor.gal@maeth.com>	05:29
shogun-buildbot	build #1146 of nightly_default is complete: Failure [failed test notebooks] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_default/builds/1146 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Viktor Gal <vigsterkr@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com>, Sergey Lisitsyn <lisitsyn.s.o@gmail.com>, Viktor Gal	06:14
shogun-buildbot	<viktor.gal@maeth.com>	06:14
-!- OXPHOS [9d8b131c@gateway/web/freenode/ip.157.139.19.28] has quit [Quit: Page closed]		07:49
-!- deepak_ [a32f0de7@gateway/web/freenode/ip.163.47.13.231] has joined #shogun		08:22
-!- sanuj [~sanuj@117.203.8.78] has joined #shogun		08:29
-!- deepak_ [a32f0de7@gateway/web/freenode/ip.163.47.13.231] has quit [Ping timeout: 250 seconds]		08:31
-!- arianepaola [~ariane@unaffiliated/arianepaola] has quit [Read error: Connection reset by peer]		08:46
-!- arianepaola [~ariane@unaffiliated/arianepaola] has joined #shogun		08:52
-!- deepak_ [a32f0de7@gateway/web/freenode/ip.163.47.13.231] has joined #shogun		08:54
sanuj	wiking, there?	09:04
@wiking	yes	09:08
@wiking	barely but yes	09:08
sanuj	wiking, i'm converting some public members to protected in neuralnetwork.h	09:15
sanuj	added setters/getters for them	09:16
sanuj	got this error while building: http://pastebin.com/EH7GTqGD	09:16
sanuj	wiking, do i need to change something in SWIG also?	09:16
sanuj	lisitsyn, maybe you can help if wiking is busy	09:17
sanuj	lisitsyn, and could you please comment in the tags PR	09:17
sanuj	for any.h doc	09:17
@wiking	lemme check	09:18
@wiking	10 mins tops ..	09:18
sanuj	wiking, okay	09:18
sanuj	lisitsyn, https://github.com/shogun-toolbox/shogun/pull/3221	09:18
@wiking	sanuj: yesah	09:35
@wiking	it seems those getters setters you wanna access from public	09:35
sanuj	wiking, what change in SWIG	09:36
sanuj	wiking, those are already public	10:19
-!- deepak_ [a32f0de7@gateway/web/freenode/ip.163.47.13.231] has quit [Quit: Page closed]		10:22
@wiking	which?	10:25
@wiking	i mean it says that they are protected	10:25
sanuj	wiking, the variables are protected	10:25
sanuj	but the functions are public	10:25
@wiking	/home/sanuj/Projects/shogun_cb/buildpy/src/interfaces/python_modular/modshogunPYTHON_wrap.cxx:565043:21: error: within this context if (arg1) (arg1)->dropout_hidden = arg2;	10:27
@wiking	there's that statement	10:27
@wiking	/home/sanuj/Projects/shogun_cb/src/shogun/neuralnets/NeuralNetwork.h:642:12: error: ‘float64_t shogun::CNeuralNetwork::dropout_hidden’ is protected	10:27
sanuj	yes	10:27
@wiking	so?	10:28
sanuj	float64_t shogun::CNeuralNetwork::dropout_hidden is protected	10:28
sanuj	wiking, but set_dropout_hidden() is public	10:28
@wiking	but it doesn't use set_dropout_hidden(asdf)	10:28
@wiking	it callse	10:28
@wiking	(arg1)->dropout_hidden	10:28
@wiking	= arg2;	10:28
sanuj	wiking, why is it doing that?	10:29
sanuj	can't i have protected members to work with swig?	10:29
@wiking	you can of course	10:29
sanuj	this is how the function looks	10:30
sanuj	void set_dropout_hidden(float64_t _dropout_hidden)	10:30
sanuj	{	10:30
sanuj	this->dropout_hidden = _dropout_hidden;	10:30
sanuj	}	10:30
sanuj	wiking, the error is in here in line 22 http://pastebin.com/qNfHAmwT	10:33
sanuj	first i thought this is because of inline functions	10:33
sanuj	but now i have removed inline but still getting the same error	10:34
@wiking	therea are a lot of protected memebers tahta re exposed via swig	10:35
sanuj	wiking, yes, so what's the problem here?	10:36
@wiking	sanuj: could you be a bit more autonomous	10:36
@wiking	it's a simple compiler error	10:36
@wiking	i'll try my best but atm i dont have a machine where i could do anything	10:37
sanuj	wiking, okay	10:37
@wiking	do you have this code somewhere avaialble online?	10:38
sanuj	i'll open a pr if you want	10:38
@wiking	dont need to be a pr	10:39
@wiking	you can just push it to your own repo's branch and gimme the name	10:39
sanuj	okay	10:39
sanuj	https://github.com/sanuj/shogun/commit/cdbe259939fd33561ed4cf728103c415ae65b503	10:46
-!- sanuj [~sanuj@117.203.8.78] has quit [Ping timeout: 276 seconds]		11:13
lisitsyn	ok heree	11:19
-!- sanuj [~sanuj@117.204.255.138] has joined #shogun		12:47
-!- lambday [6d9941c0@gateway/web/freenode/ip.109.153.65.192] has joined #shogun		13:07
-!- mode/#shogun [+o lambday] by ChanServ		13:07
-!- HeikoS [~heiko@nat-223-130.internal.eduroam.ucl.ac.uk] has joined #shogun		13:12
-!- mode/#shogun [+o HeikoS] by ChanServ		13:12
-!- lambday [6d9941c0@gateway/web/freenode/ip.109.153.65.192] has quit [Ping timeout: 250 seconds]		13:16
-!- GandalfTheWizard [~Eva@112.10.170.58] has quit [Quit: Leaving.]		13:17
-!- lambday [6d9941c0@gateway/web/freenode/ip.109.153.65.192] has joined #shogun		13:36
-!- mode/#shogun [+o lambday] by ChanServ		13:36
@HeikoS	wiking: jojo	13:50
@wiking	HeikoS: yo	14:05
@HeikoS	wiking: yo	14:06
@HeikoS	just sent email	14:06
@HeikoS	lambday, lisitsyn ^	14:06
@wiking	where to?	14:06
@HeikoS	maeth.com	14:06
@HeikoS	shall i forward?	14:06
lisitsyn	I've got it	14:07
@wiking	nono reading	14:07
@HeikoS	cool	14:08
@wiking	apple with oranges	14:08
@wiking	that's the problem with that benchmark nothing else :)	14:08
@wiking	but i had a system crash this morning	14:08
@wiking	my laptop went into an infinite loop of restarts	14:08
@HeikoS	ui	14:09
@HeikoS	nice one	14:09
@HeikoS	and now you are on phone? :D	14:09
@wiking	so i'm happy that i've managed to backup my data	14:09
@wiking	between 150 restarts	14:09
@wiking	:)	14:09
@HeikoS	uh yeah	14:09
@HeikoS	reminds me	14:09
@HeikoS	should do that as well	14:09
@HeikoS	ok so how to measure this better?	14:09
@HeikoS	in comparable way	14:09
@lambday	wiking: well, it's not exactly apples and oranges.. they both do the same thing :)	14:12
@lambday	wiking: point is, we gotta figure out "why" it is slow	14:12
@wiking	but man	14:12
@wiking	have you checked the asm code?	14:12
@wiking	bazdmeg nem hiszem el hogy mindig ilyen kurva okos mindenki	14:13
@wiking	MINDIG BAZDMEG	14:13
@lambday	wiking: that's what I was hoping that you can help a bit with	14:13
@wiking	ELOSZOR NEZEL MAR BAZDMEG UTANA ANNAK HOGY MI A FASZOMROL BESZELSZ	14:13
@wiking	^googl translate taht plz	14:13
@wiking	becuase i'm fucking tired	14:13
@wiking	of statements like this	14:13
@HeikoS	wiking: ??	14:14
@HeikoS	dude speak english	14:14
@lambday	wiking: see I have no intention of making any statement here.. the results speak	14:14
@lambday	oxphos was getting a similar thing in her machine	14:15
@wiking	no day dont speak	14:15
@wiking	because you are not comparing	14:15
@wiking	the right things	14:15
@wiking	bazdmeg	14:15
@wiking	faszom	14:15
@wiking	look at the objdump	14:15
@wiking	you generate the code	14:15
@wiking	into everything	14:15
@wiking	yes of course since the fucking main you have the whole objcet	14:15
@wiking	obviously that you will be faster	14:15
@wiking	when your whole code is in main()	14:16
@lambday	wiking: that's not what this was	14:17
@HeikoS	wiking: what about you do a mini benchmark?	14:17
@wiking	which?	14:17
@wiking	objdump it fuck	14:17
@wiking	look at the generated asm	14:17
@HeikoS	wiking: because this way of doing it is sooo inefficient	14:17
@HeikoS	just show how to do it right	14:17
@wiking	orr jsut gcc -S -it	14:18
@wiking	orr jsut gcc -S it	14:18
@lambday	okay..	14:18
@lambday	cool..	14:18
@wiking	if you generate the whole code into the benchmark function	14:19
@lambday	so I should do it for g++, and then clang++ ?	14:19
@wiking	no you dont care about that	14:19
@wiking	you just care atm the diff between the 2 generated code	14:20
@HeikoS	wiking: so what about a better benchmark?	14:22
@HeikoS	or other way of comparing?	14:22
@HeikoS	we need gist and numbers	14:23
@lambday	HeikoS: wiking: lisitsyn: so here is why (after checking the objdump)	14:30
@lambday	in the file where the whole thing is header only, it doesn't even create any code for CPUBackend::dot (can't find the symbol there at all), just inlines it..	14:31
@wiking	lambday: the rpoblem is that if you go with this	14:31
@lambday	and in the other case, there is a code	14:31
@wiking	libshogun will be fucking crazy	14:31
@wiking	and not only that (size wise)	14:31
@wiking	you'll have serious problems once this is plugin-ized	14:32
lisitsyn	header only would make any plugin contain all linalg :D	14:32
@lambday	wiking: that's what it does when you include a <Eigen/Eigen> in your cpp	14:32
@wiking	yeah but eigen you wanna include	14:32
@wiking	in every plugin?	14:32
@wiking	i mean yeah in a way	14:32
@wiking	but wasn't the idea of linalg backend was	14:33
@wiking	to have a centralized thing doing dot?	14:33
@wiking	because i thought we wanna have n different type of linalg plugins	14:33
@wiking	that implement various linalg backends	14:33
@wiking	plugins = shared library	14:33
@lambday	I won't use a centralized dot if it's fucking slow! I'd rather stick to Eigen	14:33
@wiking	hahaha	14:34
@wiking	fucking slow :)	14:34
@wiking	i mean sorry man but you dont even grasp the amount of time it takes	14:34
@wiking	but anyhow	14:34
@wiking	you could go around this easier	14:34
@lambday	wiking: how?	14:36
lisitsyn	wait wait	14:36
lisitsyn	blas is not header only	14:36
lisitsyn	with all these overheads we could have	14:36
lisitsyn	and yet it is as fast as eigen	14:36
-!- c4goldsw [c1a99ae1@gateway/web/cgi-irc/kiwiirc.com/ip.193.169.154.225] has joined #shogun		14:37
@lambday	lisitsyn: well, when relying on different backends, how can you guarantee that? we're not a linalg library, we're a meta library	14:37
@lambday	of course different backends do things differently in their most optimized way	14:37
lisitsyn	lambday: just one level of indirection?	14:38
lisitsyn	how can that make it slower?	14:38
@lambday	lisitsyn: it's not just that.. I could only look at a small portion of these 15k lines of assembly files	14:39
@lambday	but when I searched for the symbol in the header only file, it wasn't there	14:39
@wiking	but having generated code into the code (everywhere) like a macro	14:42
@wiking	is always gonna be faster	14:42
@wiking	obfiously	14:42
@wiking	but is this actually feasible for us?	14:42
lisitsyn	why could that be much faster?	14:43
lisitsyn	it gets much faster when something is being exploited	14:43
lisitsyn	like const, alignment or so	14:43
@wiking	yeah but we dont align yet any vectors	14:43
lisitsyn	but the overhead of calling virtual function is negligible comparing to multiplying thousands of numbers	14:43
@wiking	yeah but the thing is that we keep calling a virt function	14:44
@wiking	like 100k times	14:44
@wiking	although it's a constant time	14:45
@wiking	it'll add up	14:45
@wiking	of course depends on your input size	14:45
lisitsyn	ah ok	14:45
-!- c4goldsw [c1a99ae1@gateway/web/cgi-irc/kiwiirc.com/ip.193.169.154.225] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]		14:54
-!- c4goldsw [c1a99ae1@gateway/web/cgi-irc/kiwiirc.com/ip.193.169.154.225] has joined #shogun		15:04
shogun-buildbot	build #412 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/412 blamelist: arianepaola	15:16
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun		15:17
shogun-notifier-	shogun: Heiko Strathmann :develop * bf15b80 / examples/meta/generator/targets/java.json: https://github.com/shogun-toolbox/shogun/commit/bf15b80d2331315063c0eba66f5e3cc18ce267f7	15:17
shogun-notifier-	shogun: explicit imports; fix problem of ambiguous Math reference	15:17
shogun-notifier-	shogun: Heiko Strathmann :develop * 561e030 / examples/meta/generator/targets/r.json: https://github.com/shogun-toolbox/shogun/commit/561e03077a337946169edbacea66a4994a4a9b24	15:17
shogun-notifier-	shogun: fix r static method call copy paste error	15:17
shogun-notifier-	shogun: Heiko Strathmann :develop * 20020f7 / examples/meta/generator/targets/java.json: https://github.com/shogun-toolbox/shogun/commit/20020f72a79de815c6a7fa4044b9dc52b86aff38	15:17
shogun-notifier-	shogun: import modshogun again in meta examples	15:17
shogun-notifier-	shogun: Heiko Strathmann :develop * bac2321 / examples/meta/ (5 files): https://github.com/shogun-toolbox/shogun/commit/bac2321c49b1a01ec2614284e3824df406df0c03	15:17
shogun-notifier-	shogun: remove nose tests for generator, we got those covered by the meta examples now	15:17
shogun-notifier-	shogun: Heiko Strathmann :develop * 19e364a / examples/meta/ (7 files): https://github.com/shogun-toolbox/shogun/commit/19e364a1070b36cc8bbf262b5da97db485e4d672	15:17
shogun-notifier-	shogun: Merge pull request #3251 from karlnapf/develop	15:17
shogun-notifier-	shogun:	15:17
shogun-notifier-	shogun: meta examples: fixes for java & R	15:17
c4goldsw	wiking ping	15:19
@wiking	pong	15:19
c4goldsw	hahahaha I was just thinking that	15:19
shogun-buildbot	build #413 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/413 blamelist: arianepaola	15:20
c4goldsw	I was just browsing through CDenseFeatures and I noticed that there was no constructor for SGVectors, though there is one for SGMatrix	15:20
c4goldsw	Why would this be the case?	15:20
c4goldsw	Just curious.	15:20
@wiking	what do you mean there was no ctrs for SGVectors?	15:21
sanuj	hey lisitsyn	15:22
sanuj	got time?	15:22
lisitsyn	will get soon but not yet	15:22
c4goldsw	wiking: http://imgur.com/hp1mc0S	15:23
sanuj	lisitsyn, okay when you get time, can you please comment on my tags PR for documentation in any?	15:23
shogun-buildbot	build #414 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/414	15:23
lisitsyn	sanuj: sure	15:24
sanuj	lisitsyn, thanks	15:24
c4goldsw	wiking: there's only one more constructor below that which has no parameters	15:24
@wiking	c4goldsw: next time you can link to a line on github	15:24
@wiking	but yeah of course	15:24
@wiking	Features always a collection of vectors	15:25
c4goldsw	^ much better way, will remember.	15:25
@wiking	and in case the collection = 1	15:25
@wiking	then it's a 1 vector matrix	15:25
@wiking	:)	15:25
c4goldsw	Ah, okay.	15:25
@wiking	got it?	15:25
c4goldsw	Yes, thank you.	15:25
@wiking	mw	15:26
@wiking	nw	15:26
c4goldsw	?	15:27
c4goldsw	wiking what does that mean?	15:27
shogun-buildbot	build #42 of xenial - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/42 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>	15:28
@wiking	no worries	15:30
shogun-buildbot	build #2904 of bsd1 - libshogun is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2904 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>	15:30
c4goldsw	Got it	15:30
Saurabh7	hello	15:31
Saurabh7	wiking: its not good if i pass eigen things ?	15:31
@wiking	noup	15:31
Saurabh7	private methods	15:31
@wiking	pass the vector	15:31
@wiking	only thing is that what happens if tomorrow we say we want another linalg library	15:32
@wiking	not eigen	15:32
@wiking	?	15:32
@wiking	then we'll have to dig into this	15:32
@wiking	and fix it	15:32
@wiking	right?	15:32
Saurabh7	okie yes	15:32
shogun-buildbot	build #43 of xenial - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/43 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>	15:32
Saurabh7	hmm how do I deal with transpose then	15:33
@wiking	well as lisitsyn told yesterday	15:33
@wiking	.transpose() actually will not literally transpose the matrix in eigen	15:33
c4goldsw	wiking before I start working away, I want to make sure I have the right idea - I'm just templating the classes that use CDenseFeature so that we won't have to cast everything to float64_t, yes?	15:36
@wiking	mmm	15:37
@wiking	so basically the grep expression i gave u yesterday	15:38
@wiking	there	15:38
@wiking	you need to make sure	15:38
@wiking	that those implementation can work	15:38
@wiking	with CDenseFeature<float32_t> at least	15:38
@wiking	just take any of those classe as a guinea pig	15:38
@wiking	and we can do that iteratively there	15:38
@wiking	send in a pr and we'll see if you get it right	15:39
@wiking	and once that is done properly in one class	15:39
@wiking	we can move on and fix the rest	15:39
c4goldsw	Yes, but I can do that with templates, no?	15:39
@wiking	yeah	15:40
c4goldsw	Great.	15:40
c4goldsw	All is clear then.	15:40
sanuj	wiking, you are from hungary?	15:42
@wiking	yes	15:42
sanuj	okay	15:42
Saurabh7	map.transpose().col(i)	15:46
Saurabh7	this will still access a row of col major matrix ?	15:46
@wiking	should	15:46
Saurabh7	wiking: then I have to transpose the SGMatrix itself in memory	15:46
Saurabh7	at the beginning	15:47
@wiking	but wait why?	15:47
Saurabh7	need to loop over the rows of matrix	15:47
Saurabh7	dot products	15:47
Saurabh7	map_X.col(i_max_corr).dot(map_X.col(active_set[i]))	15:48
shogun-buildbot	build #2897 of deb3 - modular_interfaces is complete: Failure [failed examples and unit tests] Build details are at http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/2897 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>	15:49
Saurabh7	wiking: ^	15:49
Saurabh7	there is performance drop	15:52
@wiking	where? :)	15:54
@wiking	where is performance hidign? :)	15:54
Saurabh7	trying to understand that :)	15:56
Saurabh7	https://gist.github.com/Saurabh7/ab36961c51cd5e69213096527b4d2810	15:56
Saurabh7	when i run this with my branch version	15:56
Saurabh7	and map.transpose().col(i)	15:56
Saurabh7	latter is slow	15:57
sanuj	wiking, i have a question about combinedkernel	15:58
@wiking	tell me	15:58
sanuj	wiking, is cleanup() supposed to remove the kernels present in a combinedkernel object?	15:59
sanuj	currently it does this for every kernel	15:59
sanuj	CKernel* k = get_kernel(k_idx);	15:59
sanuj	k->cleanup();	15:59
sanuj	SG_UNREF(k);	15:59
@wiking	remove?	16:00
@wiking	no	16:00
@wiking	cleanup	16:00
@wiking	no?	16:00
-!- c4goldsw [c1a99ae1@gateway/web/cgi-irc/kiwiirc.com/ip.193.169.154.225] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]		16:01
@HeikoS	sanuj: it is just a wrapper	16:02
@HeikoS	that calls cleanup on all sub-kernels	16:02
@HeikoS	Saurabh7: jo	16:03
Saurabh7	HeikoS: hi!	16:03
Saurabh7	HeikoS: updated almost all things in LARS	16:04
@HeikoS	Saurabh7: cool	16:06
@HeikoS	will check them soon	16:06
@HeikoS	anything exciting happened?	16:06
shogun-buildbot	build #33 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/33 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>	16:08
sanuj	okay	16:09
sanuj	sorry, had to make a phone call	16:09
Saurabh7	HeikoS: the comparison is always a bit fishy, I have tried to make it as fair as possible	16:09
sanuj	HeikoS, yeah, i saw the function	16:11
-!- HeikoS [~heiko@nat-223-130.internal.eduroam.ucl.ac.uk] has quit [Ping timeout: 258 seconds]		16:12
sanuj	wiking, if i want to reuse kernels in combinedkernels with new features then shall i do combinedkernel->get_kernel(0)->init(....)?	16:12
-!- OXPHOS [9d8b131c@gateway/web/freenode/ip.157.139.19.28] has joined #shogun		16:23
-!- sanuj [~sanuj@117.204.255.138] has quit [Ping timeout: 276 seconds]		16:24
-!- HeikoS [~heiko@untrust-out.swc.ucl.ac.uk] has joined #shogun		16:31
-!- mode/#shogun [+o HeikoS] by ChanServ		16:31
-!- arianepaola [~ariane@unaffiliated/arianepaola] has quit [Read error: Connection reset by peer]		17:02
-!- arianepaola [~ariane@unaffiliated/arianepaola] has joined #shogun		17:06
-!- arianepaola [~ariane@unaffiliated/arianepaola] has quit [Client Quit]		17:07
-!- arianepaola [~ariane@unaffiliated/arianepaola] has joined #shogun		17:08
arianepaola	hello everyone :-)	17:08
arianepaola	wiking and HeikoS I will be working today on updating the PRs that you have provided feedback.	17:10
-!- lambday [6d9941c0@gateway/web/freenode/ip.109.153.65.192] has quit [Ping timeout: 250 seconds]		17:11
@HeikoS	arianepaola: hi there!	17:12
@HeikoS	thanks for that, will check them soon	17:12
arianepaola	hi HeikoS	17:13
arianepaola	HeikoS: thanks!	17:13
@wiking	oooooooooooooooooooooooooooooooooooooooooookey	17:18
@wiking	sorry wrong window	17:19
-!- sonne\|osx [~sonne@x4e33f692.dyn.telefonica.de] has joined #shogun		17:23
arianepaola	haha wiking	17:23
@HeikoS	arianepaola: dont mind wiking shouting around, he does that	17:23
@HeikoS	arianepaola: I just read your email	17:24
@HeikoS	thanks for the reply	17:24
arianepaola	HeikoS: I remember last month, when he fall asleep on the keyboard and flooded the IRC logs :-)	17:24
arianepaola	HeikoS: sure	17:24
@HeikoS	arianepaola: We will discuss a bit internally and will get back to you on this	17:25
@HeikoS	but I also wanted to catch you in IRC on this	17:25
@HeikoS	so see, the main thing for us in GSoC is that we see constant progress on the projects	17:26
@HeikoS	with daily discussions and PRs	17:26
@HeikoS	and in particular active code development	17:26
@HeikoS	so if this is not so visible, our alarm goes on	17:27
@HeikoS	(we are actually required to ensure this from the GSoC program)	17:27
arianepaola	yes HeikoS	17:28
@HeikoS	arianepaola: we really want our project to be successful	17:28
@HeikoS	now the thing is	17:29
@HeikoS	there is an agreement between students and organisations and google	17:29
@HeikoS	which is: you work full-time on this	17:29
@HeikoS	and then you are paid	17:29
@HeikoS	now	17:31
@HeikoS	lets move to pm then	17:31
arianepaola	ok	17:31
OXPHOS	HeikoS: hey got time to check the cookbook PR?	18:06
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout]		18:17
@HeikoS	OXPHOS: not yet, but I merged something to "fix" the java problems	18:19
@HeikoS	(which broke all examples, fixing soon)	18:19
OXPHOS	HeikoS: oh I thought we're good to go	18:21
OXPHOS	so I'll wait	18:21
-!- sanuj [~sanuj@117.204.255.138] has joined #shogun		18:44
arianepaola	hi sanuj	18:53
sanuj	arianepaola, hi!	18:53
arianepaola	sanuj: did you get to try ninja instead of make?	18:54
sanuj	arianepaola, yeah, it's fast	18:55
arianepaola	:-)	18:55
sanuj	i increased my ccache size to 10 gb	18:55
sanuj	that also increased it	18:55
sanuj	:)	18:55
arianepaola	wow	18:55
arianepaola	anyway better than compiling everything	18:56
sanuj	yeah	18:56
-!- lambday [6d9941c0@gateway/web/freenode/ip.109.153.65.192] has joined #shogun		19:12
-!- mode/#shogun [+o lambday] by ChanServ		19:12
@lambday	OXPHOS: heya	19:14
@lambday	OXPHOS: could you just rename the directory 'linalgrefactor' to something else? maybe move it all inside `'linalgg'	19:15
@lambday	OXPHOS: we can merge your patch then	19:16
@lambday	%s/linalgg/linalg/g	19:16
@lambday	OXPHOS: also, please add documentation (even if just 1 line) to each class and each member :)	19:17
@lambday	lisitsyn: HeikoS: do we still need to put a c++11 guard around things?	19:18
@HeikoS	lambday: yes	19:18
lisitsyn	lambday: no idea	19:18
lisitsyn	:D	19:18
@lambday	ok	19:18
@HeikoS	yet we do	19:18
@lambday	OXPHOS: ^	19:18
@HeikoS	I wish I had some time	19:18
@HeikoS	lambday: so linalg is c++11 only atm right?	19:19
@HeikoS	but it always was so thats ok	19:19
@lambday	HeikoS: it doesn't have to be.. it's just the usage of unique_ptr at this monent	19:19
@HeikoS	we will change soon	19:19
@lambday	OXPHOS: maybe you can use shogun::Unique instead of std::unique_ptr for the sg_linalg?	19:19
@lambday	lisitsyn: can we please have the API for shogun::Unique similar to that of std::unique_ptr :D	19:26
lisitsyn	what do you miss?	19:26
@lambday	lisitsyn: get() maybe	19:27
lisitsyn	why?	19:27
@lambday	so we can pass the ptr around, keeping the ownership with somebody else	19:27
lisitsyn	doesn't sound defensive enough ;)	19:28
lisitsyn	what do you need pointer to?	19:28
@lambday	thinking.	19:28
sanuj	lisitsyn, thanks for the comments :)	19:29
@lambday	lisitsyn: how do I pass that thing as a param?	19:30
@lambday	ref?	19:30
lisitsyn	yes	19:30
lisitsyn	you can't copy it	19:30
@lambday	yeah that makes sense..	19:30
@lambday	lisitsyn: if you have a moment, can you please comment on this : https://github.com/shogun-toolbox/shogun/pull/3230/files	19:32
lisitsyn	ahh one more things	19:32
lisitsyn	lambday: unique always creates object	19:33
lisitsyn	so it won't work for abstract classes	19:33
@lambday	lisitsyn: ah	19:33
lisitsyn	lambday: well we can patch it	19:33
lisitsyn	;)	19:33
@lambday	lisitsyn: wait, how do I set things inside an obj?	19:33
lisitsyn	->	19:33
@lambday	ah no	19:34
@lambday	okay I see..	19:34
@lambday	no I meant that what if I just need to set something to an obj that takes a unique	19:34
@lambday	but then realized that it would be stupid	19:34
@lambday	it's shared by definition	19:35
lisitsyn	yes	19:35
@lambday	lisitsyn: so setters should always use `some'	19:36
lisitsyn	yeap	19:36
@lambday	lisitsyn: cool.. then the only thing I'd miss is to use a ptr to an abstract class	19:37
@lambday	not sure whether get() would ever be required	19:38
lisitsyn	it could be useful.. not sure	19:38
@lambday	okay	19:41
@lambday	another thing, I have a T*, I want to create a unique from it	19:41
@lambday	lisitsyn: okay another thing. maybe having a function like for some would be useful.. that takes ctor args	19:44
lisitsyn	yeah it's just not the same unique I was thinking about	19:44
@lambday	lisitsyn: this one always calls the no-arg ctor	19:45
lisitsyn	ok got it	19:45
lisitsyn	lambday: have to go now I will thnik how to patch it	19:45
sanuj	lisitsyn, wanted to ask you one things	19:45
sanuj	thing*	19:45
@lambday	lisitsyn: okay thanks man	19:45
lisitsyn	sanuj: yes?	19:45
sanuj	lisitsyn, this is my code of setters/getters	19:46
sanuj	https://github.com/sanuj/shogun/commit/cdbe259939fd33561ed4cf728103c415ae65b503	19:46
sanuj	this works when i only build cpp	19:46
sanuj	unit tests pass	19:46
sanuj	but when i build with pythonmodular =0n	19:46
lisitsyn	.. what when you build? :)	19:47
lisitsyn	sorry have to go will answer once get back home	19:47
sanuj	lisitsyn, here is the error http://pastebin.com/EH7GTqGD	19:48
sanuj	lisitsyn, i'm going to sleep	19:48
@HeikoS	lisitsyn: https://github.com/shogun-toolbox/shogun/pull/3244/files	19:48
sanuj	will check logs for your answer	19:48
-!- sanuj [~sanuj@117.204.255.138] has quit [Remote host closed the connection]		19:50
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun		19:59
shogun-notifier-	shogun: Heiko Strathmann :develop * d866849 / examples/meta/generator/targets/java.json: https://github.com/shogun-toolbox/shogun/commit/d8668498db42736637fe31c2c590130c014c1065	19:59
shogun-notifier-	shogun: import all ever used classes rather than only interfaced ones	19:59
@HeikoS	OXPHOS: hi	20:00
@HeikoS	try another rebase	20:00
@HeikoS	I fixed the last problem	20:00
shogun-notifier-	shogun: Ariane Paola Gomes :develop * 0250454 / src/shogun/distance/TanimotoDistance.h: https://github.com/shogun-toolbox/shogun/commit/0250454a4d77c848713a2ec66593aa840680f8e4	20:01
shogun-notifier-	shogun: Fixes #3261 Error in LaTeX formula for TanimotoDistance.	20:01
shogun-notifier-	shogun: Heiko Strathmann :develop * 207d620 / src/shogun/distance/TanimotoDistance.h: https://github.com/shogun-toolbox/shogun/commit/207d6205618d0b98fab0285aaa14e6dc70fdb8f4	20:01
shogun-notifier-	shogun: Merge pull request #3262 from arianepaola/fix_3261	20:01
shogun-notifier-	shogun:	20:01
shogun-notifier-	shogun: Fixes #3261 Error in LaTeX formula for TanimotoDistance.	20:01
@HeikoS	arianepaola: hey	20:03
@HeikoS	can I suggest something	20:04
arianepaola	hi HeikoS	20:04
@HeikoS	many of the cookbooks you sent have similar (minor) issues that need to be addressed	20:04
@HeikoS	I will only comment on the first	20:04
@HeikoS	and then you will know how to generalise to the others	20:04
arianepaola	ok	20:04
arianepaola	that's fine	20:05
@HeikoS	(that is also a reason why we wanted to get them coming continuously rahter than one batch)	20:05
@HeikoS	also they are blocking travis quite a bit	20:05
@HeikoS	So I suggest to close them, you can store them locally, and then send them one after another?	20:05
@HeikoS	that is, only send a new one once old is merged?	20:05
@HeikoS	would that be ok=?	20:05
arianepaola	hmm, any other way to leave them open, or reopen the PR?	20:07
arianepaola	e.g. close now, but not delete the PR and then reopen?	20:07
@HeikoS	arianepaola: thats good as well	20:07
@HeikoS	you will need to change similar things on all of them	20:07
@HeikoS	but please dont change all at once	20:07
@HeikoS	just the one I comment on	20:07
arianepaola	ok	20:08
@HeikoS	and then the next one you send, you can put these things in directly, and I comment on different things (or merge directly)	20:08
@HeikoS	just to get this more efficient for you	20:08
@HeikoS	because iterating over one already is a lot of work,	20:08
@HeikoS	you dont wanna apply all the changes to all, and then change again, see what I mean?	20:08
arianepaola	ok	20:08
arianepaola	so, what I can do now is closing the PRs, but they do not get deleted right?	20:09
shogun-buildbot	build #44 of xenial - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/44 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>	20:09
@HeikoS	arianepaola: they dont	20:09
arianepaola	then I can updated more changes over time and push or even force push to my user	20:09
@HeikoS	(I think)	20:09
@HeikoS	yep	20:09
arianepaola	and then reopen the PR	20:09
@HeikoS	I just commented on the first distance one	20:09
arianepaola	will try closing and reopening one ow	20:10
arianepaola	ok	20:10
@HeikoS	will ignore the others for now	20:10
arianepaola	sure	20:10
@HeikoS	and comment on subsequence thing you sent a while ago	20:10
arianepaola	yes	20:10
shogun-buildbot	build #2905 of bsd1 - libshogun is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2905 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Ariane Paola Gomes <arianepaola@users.noreply.github.com>	20:11
arianepaola	HeikoS: just checked	20:11
arianepaola	See https://github.com/shogun-toolbox/shogun/pull/3263	20:11
arianepaola	I can reopen, close, reopen :-)	20:11
@HeikoS	cool :)	20:12
OXPHOS	HeikoS, lambday: hey im back	20:12
OXPHOS	went out for lunch caught middle in the rain. i hate rain	20:13
shogun-buildbot	build #45 of xenial - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/45 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Ariane Paola Gomes <arianepaola@users.noreply.github.com>	20:13
OXPHOS	never thought about visiting london	20:13
shogun-notifier-	shogun: Ariane Paola Gomes :develop * 64d24e0 / cmake/FindSphinx.cmake: https://github.com/shogun-toolbox/shogun/commit/64d24e0b11bca092b0c385938b0490ce34f57380	20:16
shogun-notifier-	shogun: Fixes #3231 Cookbook generation error using Sphinx from PyPI.	20:16
shogun-notifier-	shogun: Heiko Strathmann :develop * d270764 / cmake/FindSphinx.cmake: https://github.com/shogun-toolbox/shogun/commit/d270764950be326a42282999094a5d02537d3677	20:16
shogun-notifier-	shogun: Merge pull request #3232 from arianepaola/fix_3231	20:16
shogun-notifier-	shogun:	20:16
shogun-notifier-	shogun: Fixes #3231 Cookbook generation error using Sphinx from PyPI.	20:16
@HeikoS	OXPHOS: haha dont come here then	20:17
shogun-notifier-	shogun: Ariane Paola Gomes :develop * de6e23a / examples/meta/generator/parse.py: https://github.com/shogun-toolbox/shogun/commit/de6e23ab620d2d2b6ee624a679bb5289c79a3957	20:18
shogun-notifier-	shogun: Fixes #3254 Cookbook generation crashes using empty meta example files.	20:18
shogun-notifier-	shogun: Heiko Strathmann :develop * eb74aaa / examples/meta/generator/parse.py: https://github.com/shogun-toolbox/shogun/commit/eb74aaa98185681cf74f1ad34d54a679642d4e7a	20:18
shogun-notifier-	shogun: Merge pull request #3256 from arianepaola/fix_3254	20:18
shogun-notifier-	shogun:	20:18
shogun-notifier-	shogun: Fixes #3254 Cookbook generation crashes using empty meta example files.	20:18
shogun-buildbot	build #704 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/704 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>	20:19
shogun-buildbot	build #705 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/705	20:20
shogun-notifier-	shogun: Ariane Paola Gomes :develop * 20b2844 / examples/meta/generator/targets/cpp.json: https://github.com/shogun-toolbox/shogun/commit/20b28443b228d2ecffcb6eb6dfbd4b4f81a2c1d6	20:22
shogun-notifier-	shogun: Make RealDistance type available within cookbooks.	20:22
shogun-notifier-	shogun: Heiko Strathmann :develop * 8616159 / examples/meta/generator/targets/cpp.json: https://github.com/shogun-toolbox/shogun/commit/8616159902ab2537cb145ba09ab1fdca91241219	20:22
shogun-notifier-	shogun: Merge pull request #3260 from arianepaola/feature/cookbook_type_realdistance	20:22
shogun-notifier-	shogun:	20:22
shogun-notifier-	shogun: Make RealDistance type available within cookbooks.	20:22
shogun-notifier-	shogun: Ariane Paola Gomes :develop * 547fbef / doc/cookbook/source/index.rst: https://github.com/shogun-toolbox/shogun/commit/547fbef9a353ca5d291ec9f9eec782134c4be5ad	20:24
shogun-notifier-	shogun: Adds Distance listing for Cookbook generation.	20:24
shogun-notifier-	shogun: Heiko Strathmann :develop * 01efdce / doc/cookbook/source/index.rst: https://github.com/shogun-toolbox/shogun/commit/01efdceb0017ccecbd23c9ee4dc3812af98a9759	20:24
shogun-notifier-	shogun: Merge pull request #3263 from arianepaola/feature/cookbook_index_add_distance	20:24
shogun-notifier-	shogun:	20:24
shogun-notifier-	shogun: Adds Distance listing for Cookbook generation.	20:24
@HeikoS	Saurabh7: jo	20:27
@HeikoS	so, now some time to check stuff	20:27
arianepaola	HeikoS: The crash happens earlier when parsing the files: https://github.com/shogun-toolbox/shogun/pull/3255	20:27
@HeikoS	arianepaola: I see,	20:28
@HeikoS	ok then, remove mine, add yours	20:28
@HeikoS	can you add the rel_dir before the filename?	20:28
arianepaola	e.g. when there is an error in the json file. it is good to know	20:28
@HeikoS	like	20:28
OXPHOS	lambday: may i ask the idea for unique_ptr now? use unique or some or add C++11 flag?	20:28
@HeikoS	classifier/linera_svm.sg	20:28
@HeikoS	arianepaola: ah wait this prints json?	20:29
arianepaola	yes	20:29
@HeikoS	output is	20:29
@HeikoS	Translating file python.json	20:29
@HeikoS	arianepaola: what is the output locally when you do "make meta_examples"	20:30
@HeikoS	mine is	20:30
@HeikoS	Generating examples from meta-language	20:30
@HeikoS	Translating gaussian_processes/gaussian_process_regression.sg	20:30
@HeikoS	Translating regression/kernel_ridge_regression.sg	20:30
@HeikoS	...	20:30
arianepaola	I also get this output	20:31
OXPHOS	lambday: or just use sg.unique for init.cpp and keep others the same?	20:31
arianepaola	in addition, if I have an error, e.g in the cpp.json	20:31
arianepaola	it shows this, that the file cannot be parsed	20:31
@lambday	OXPHOS: hey.. well, you can just keep the std:: as well	20:32
@lambday	OXPHOS: but then you have to guard your code with the c++11 macros	20:32
@lambday	OXPHOS: oh one more thing..	20:32
@HeikoS	arianepaola: only if error?	20:33
@HeikoS	or always?	20:33
@HeikoS	PR to me seems always	20:33
arianepaola	always	20:33
@HeikoS	what about you put a try around it	20:33
@HeikoS	and in case of an exception, you print	20:33
arianepaola	ok	20:33
arianepaola	good	20:33
@HeikoS	and then print the usual stack trace	20:34
@HeikoS	keeping the output cleaner	20:34
@lambday	OXPHOS: can you please make m_cpubackend and m_gpubackend to shared_ptrs?	20:34
@lambday	since those can be set from outside	20:34
@lambday	OXPHOS: inside SGLinalg class	20:35
shogun-buildbot	build #2898 of deb3 - modular_interfaces is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/2898	20:35
OXPHOS	lambday: yes!!!!	20:35
@lambday	OXPHOS: cool! thanks	20:35
OXPHOS	lambday: may i ask, if shogun fully supports c++11, is there any advantage to have our own smart pointers like some and unique?	20:36
@lambday	OXPHOS: good question. well, I'm not sure!	20:37
@lambday	maybe it will help us with modular interfaces..	20:37
@lambday	also, as long as we have the SG_REF/UNREFs, it makes sense to use our internal things	20:38
OXPHOS	(smash them all	20:39
OXPHOS	i said nothing	20:39
@HeikoS	OXPHOS: hehe ;)	20:40
@HeikoS	this is your project	20:41
@HeikoS	smashing things	20:41
@HeikoS	and making them nice	20:41
@HeikoS	OXPHOS: btw http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces	20:41
@HeikoS	java meta examples work again	20:41
@HeikoS	and now static methods also will work	20:41
@HeikoS	and Math	20:41
OXPHOS	HeikoS: cool thanks!	20:43
@HeikoS	OXPHOS: you can also tell sanukj	20:43
arianepaola	HeikoS: thanks for merging and comments	20:43
@HeikoS	sanuk	20:43
@HeikoS	arianepaola: welcome, let me know how it goes	20:44
arianepaola	ok	20:44
OXPHOS	HeikoS: also the other two cookbooks are failing because of the gmm. themselves are actually fine.	20:44
@HeikoS	OXPHOS: link?	20:44
OXPHOS	HeikoS: https://github.com/shogun-toolbox/shogun/pull/3242	20:45
OXPHOS	HiekoS: the other one needs some polish	20:45
@HeikoS	checking	20:45
@HeikoS	OXPHOS: any idea why the gmm fails?	20:46
OXPHOS	HeikoS: yes	20:48
@HeikoS	works locally for me	20:48
OXPHOS	what?	20:48
@HeikoS	anyways, Ill just merge as the fail is unrelated :)	20:48
OXPHOS	because gmm integration test dataset is merged and pulled	20:48
@HeikoS	its probalby order of data merge	20:49
@HeikoS	yeah	20:49
OXPHOS	but gmm is not updated	20:49
shogun-notifier-	shogun: OXPHOS :develop * edc55d7 / / (4 files): https://github.com/shogun-toolbox/shogun/commit/edc55d70307b8d051eca83e167ce1ff117e78b7c	20:49
shogun-notifier-	shogun: cookbook page	20:49
shogun-notifier-	shogun: Heiko Strathmann :develop * 83970a7 / / (4 files): https://github.com/shogun-toolbox/shogun/commit/83970a7188a8f6aeaa9c1afa4f5ad9a0da080b66	20:49
shogun-notifier-	shogun: Merge pull request #3242 from OXPHOS/cookbook_mcll	20:49
shogun-notifier-	shogun:	20:49
shogun-notifier-	shogun: cookbook - multiclass_linearmachine	20:49
@HeikoS	tada	20:49
shogun-buildbot	build #34 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/34 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Ariane Paola Gomes <arianepaola@users.noreply.github.com>	20:49
@HeikoS	OXPHOS: ok done	20:50
@HeikoS	I'm off for today!	20:50
@HeikoS	see you all	20:50
arianepaola	bye HeikoS	20:50
@HeikoS	bye :)	20:51
shogun-buildbot	build #46 of xenial - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/46 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Ariane Paola Gomes <arianepaola@users.noreply.github.com>	20:51
OXPHOS	HeikoS: thx bye!	20:51
shogun-buildbot	build #2906 of bsd1 - libshogun is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2906 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Ariane Paola Gomes <arianepaola@users.noreply.github.com>	20:53
-!- HeikoS [~heiko@untrust-out.swc.ucl.ac.uk] has quit [Ping timeout: 272 seconds]		20:55
shogun-buildbot	build #708 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/708 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, OXPHOS <engelzora@gmail.com>	20:56
OXPHOS	lambday: /** Not implemented copy constructor / Unique(const Unique&); /* Not implemented assignment operator */ Unique& operator=(const Unique& other);	21:09
@lambday	OXPHOS: you're not allowed to copy it	21:09
OXPHOS	lambday: I don't think I can separate the declare and definition of a unique..	21:09
@lambday	OXPHOS: yeah not possible	21:09
@lambday	(for now)	21:10
OXPHOS	lambday: but in init.cpp they're separate	21:10
OXPHOS	most of the cases they're..	21:10
@lambday	OXPHOS: well, keep it as it is then	21:11
@lambday	just guard the entire thing with cxx11 check	21:11
OXPHOS	lambday: kk	21:11
@lambday	OXPHOS: but do make the members inside SGLinalg shared ptrs	21:11
@lambday	you won't need to use that std::move thing	21:12
OXPHOS	lambday: so glad to know that!	21:12
@lambday	xD	21:12
shogun-buildbot	build #3781 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/3781 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, OXPHOS <engelzora@gmail.com>	21:23
shogun-buildbot	build #35 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/35 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Ariane Paola Gomes <arianepaola@users.noreply.github.com>	21:30
OXPHOS	lambday: hey I just pushed https://github.com/shogun-toolbox/shogun/pull/3230	22:50
arianepaola	bye everyone, until tomorrow :-)	23:19
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout]		23:49
--- Log closed Thu Jun 09 00:00:32 2016

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