IRC logs of #shogun for Thursday, 2016-06-16

--- Log opened Thu Jun 16 00:00:42 2016
@wiking	yes	00:26
-!- HeikoS_mobile [~Mutter@host-92-0-162-192.as43234.net] has joined #shogun		00:30
HeikoS_mobile	wiking: hi	00:30
HeikoS_mobile	Around?	00:30
@wiking	sort of	00:31
HeikoS_mobile	Cool	00:32
HeikoS_mobile	Thanks for the link about cache	00:32
HeikoS_mobile	One thing that I don't get though is	00:32
HeikoS_mobile	And I just wanted to quickly ask	00:32
HeikoS_mobile	We do t want to copy data around	00:33
HeikoS_mobile	If it is cpu memory	00:33
HeikoS_mobile	That is constructing this vector thing from existing memory	00:33
HeikoS_mobile	Should not copy	00:33
HeikoS_mobile	But if sgvector is not aligned, that seems hard	00:33
@wiking	that needs alignment obviously	00:34
HeikoS_mobile	I see	00:34
@wiking	its actually a 'bug' that it's not aligned	00:34
HeikoS_mobile	Then all good	00:34
@wiking	it causes us performance issues	00:34
HeikoS_mobile	Yes	00:34
HeikoS_mobile	But then that's a different story	00:34
lisitsyn	whats the matter	00:35
lisitsyn	why do you care about alignment?	00:35
lisitsyn	:D	00:35
@wiking	lisitsyn: no vodka :D	00:35
lisitsyn	shetz	00:35
HeikoS_mobile	So should be done in a separate effort	00:35
lisitsyn	mazdgar	00:35
lisitsyn	bazdmeg	00:35
@wiking	BAAAZDMEEEEEEEEEEEEEEEG!	00:35
HeikoS_mobile	lisitsyn: !!!!	00:35
lisitsyn	HeikoS_mobile: !!!!!!!!	00:35
HeikoS_mobile	OXPHOS: see above for alignment	00:35
HeikoS_mobile	lisitsyn: say it!	00:35
lisitsyn	sorry	00:36
HeikoS_mobile	Ah yes	00:36
lisitsyn	I am very sorry!	00:36
HeikoS_mobile	:D	00:36
HeikoS_mobile	More	00:36
lisitsyn	excuse me!	00:36
HeikoS_mobile	I do excuse you sir	00:36
lisitsyn	what a pleasure	00:36
HeikoS_mobile	You are forgiven	00:36
HeikoS_mobile	Not forgotten	00:36
lisitsyn	forwhatever!	00:37
HeikoS_mobile	My phone tells me I can send photos	00:37
lisitsyn	to irc?	00:37
lisitsyn	good luck doing that!	00:37
lisitsyn	MIME!	00:37
lisitsyn	wiking: MIME!	00:37
HeikoS_mobile	Uploading	00:37
HeikoS_mobile	Haha	00:37
HeikoS_mobile	http://i.imgur.com/veBwlVv.jpg	00:37
lisitsyn	oh I see	00:38
@wiking	hhahaha	00:38
HeikoS_mobile	Ah feature of irc client on phone	00:38
@wiking	base64 it here :	00:38
@wiking	:>	00:38
HeikoS_mobile	Checkout my veg bed	00:38
lisitsyn	YEAHSZ	00:38
lisitsyn	bazdmeg it heere uusing base64	00:38
lisitsyn	we can read it	00:38
HeikoS_mobile	Haha	00:38
@wiking	:>	00:39
HeikoS_mobile	No I can put it in matrix format	00:39
@wiking	ok i'm back to sleep	00:39
lisitsyn	hdf5 is ok	00:39
@wiking	(6:37am here)	00:39
lisitsyn	wiking: bazdmeg night	00:39
lisitsyn	am I polite?	00:39
HeikoS_mobile	Too early	00:39
@wiking	yeah too early	00:39
@wiking	fuck this shit :D	00:39
HeikoS_mobile	I am going to bed now	00:39
@wiking	lisitsyn: yeah actually you are too polite :)	00:39
@wiking	bazdmeg	00:39
lisitsyn	lucky you have to work now	00:39
@wiking	:>	00:39
HeikoS_mobile	Scheiße	00:39
lisitsyn	hahah scheisse!	00:39
lisitsyn	bazdmeg!	00:39
HeikoS_mobile	Arbeit nervt	00:40
HeikoS_mobile	Ok bis später	00:40
lisitsyn	bis bald!	00:40
-!- HeikoS_mobile [~Mutter@host-92-0-162-192.as43234.net] has quit [Quit: Mutter: www.mutterirc.com]		00:43
-!- HeikoS_mobile [~Mutter@host-92-0-162-192.as43234.net] has joined #shogun		00:44
-!- HeikoS_mobile [~Mutter@host-92-0-162-192.as43234.net] has quit [Remote host closed the connection]		00:46
-!- wiking_ [~wiking@info2k1.hu] has joined #shogun		01:05
-!- rcurtin_ [~ryan@knife.lugatgt.org] has joined #shogun		01:08
-!- CaBa_ [~Diu7saig@lounge.imp.fu-berlin.de] has joined #shogun		01:09
-!- lisitsyn_ [~lisitsyn@37.139.2.75] has joined #shogun		01:12
-!- Netsplit .net <-> .split quits: rcurtin, @wiking, lisitsyn, CaBa		01:14
-!- lisitsyn_ is now known as lisitsyn		01:14
-!- rcurtin_ is now known as rcurtin		01:34
-!- besser82 [~besser82@fedora/besser82] has joined #shogun		01:39
-!- mode/#shogun [+o besser82] by ChanServ		01:39
-!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 244 seconds]		02:15
-!- GandalfTheWizard [~Eva@112.10.170.90] has joined #shogun		03:10
-!- wiking_ is now known as wiking		03:20
-!- wiking [~wiking@info2k1.hu] has quit [Changing host]		03:20
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun		03:20
-!- mode/#shogun [+o wiking] by ChanServ		03:20
Saurabh7	hah is that heikos garden, mine is so similar	04:53
@wiking	Saurabh7: plz push that little commit to that other branch (lars)	05:01
@wiking	so finally we can merge that as well plz	05:01
@wiking	coz now we are having this error but i dont wanna touch it until we dont merge the latest changes for lars	05:02
@wiking	last couple of builds we are getting this error: http://buildbot.shogun-toolbox.org/builders/trusty%20-%20libshogun%20-%20viennacl/builds/723/steps/compile/logs/stdio	05:02
@wiking	Saurabh7: %	05:02
@wiking	^	05:02
Saurabh7	wiking: i pushed	05:03
@wiking	ok cool!	05:04
@wiking	lets see what travis says and then we merge	05:04
Saurabh7	wiking: I am using Linalg in another test	05:04
Saurabh7	but its not in implementation	05:04
Saurabh7	of lars	05:04
Saurabh7	so I shouldnt be guarding it right ?	05:04
@wiking	noup	05:05
Saurabh7	or just replace the linalg ?	05:05
@wiking	i think now this error is actually more about	05:05
Saurabh7	yes its the guard	05:05
@wiking	that we've switched to eigen implementation	05:05
Saurabh7	i think	05:05
@wiking	and now when using viennacl	05:05
@wiking	things are not so smooth	05:05
Saurabh7	wiking: its complaining about the test i think ,	05:06
Saurabh7	trusty has c++11 ?	05:06
@wiking	yep	05:06
Saurabh7	error is about linalg::mean i was using in the test	05:07
@wiking	we dont have linalg::mean implemented in viennacl backend?	05:08
@wiking	mmm seems like :)	05:10
@wiking	i can find MeanEigen3.h	05:10
Saurabh7	yep looks like not	05:11
Saurabh7	anyways i replaced it with eigen .mean() in the pr	05:11
@wiking	mmm that is not ideal )	05:11
@wiking	i.e. not good :(	05:11
@wiking	because we should use the backend	05:11
@wiking	that user wants	05:12
Saurabh7	its just in the unittest	05:12
Saurabh7	mean of labels	05:12
Saurabh7	but yeah	05:12
@wiking	yeah but you see	05:12
@wiking	it's good to have such things in unittest	05:12
@wiking	because otherwise we would never catch this :)))	05:12
@wiking	so if it's not a big problem	05:12
@wiking	can you amend your last commit	05:12
@wiking	to actually use src/shogun/mathematics/linalg/internal/implementation/MeanEigen3	05:13
@wiking	float64_t mean=linalg::mean(lab);	05:13
@wiking	and not the map_labels.mean()	05:13
@wiking	i know it sounds stupid	05:13
@wiking	but i rather have a failing buildbot	05:13
@wiking	that reminds us that we need to fix something	05:13
@wiking	than put things under the rug	05:13
Saurabh7	no its fine, lemme change	05:13
@wiking	thnx	05:13
@wiking	i'll kill this travis	05:14
@wiking	ok killed it	05:15
Saurabh7	done	05:23
@wiking	thnx	05:24
@wiking	lets see what travis says	05:24
@wiking	and then merge	05:24
shogun-buildbot	build #20 of memleak - valgrind is complete: Failure [failed memory check] Build details are at http://buildbot.shogun-toolbox.org/builders/memleak%20-%20valgrind/builds/20 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Viktor Gal <vigsterkr@gmail.com>, Ariane Paola Gomes <arianepaola@users.noreply.github.com>, OXPHOS <engelzora@gmail.com>	05:25
shogun-buildbot	build #1022 of nightly_none is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_none/builds/1022 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Viktor Gal <vigsterkr@gmail.com>, Ariane Paola Gomes <arianepaola@users.noreply.github.com>, OXPHOS <engelzora@gmail.com>	05:29
@wiking	lisitsyn: mmm our generated examples are still leaking :)	05:43
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun		05:50
shogun-notifier-	shogun: Viktor Gal :develop * 63b3ba0 / tests/unit/kernel/Kernel_unittest.cc: https://github.com/shogun-toolbox/shogun/commit/63b3ba010fd008a75bc441f2d07cdbdf1c23eef2	05:50
shogun-notifier-	shogun: Fix memory leak in kernel unittest	05:50
shogun-buildbot	build #724 of trusty - libshogun - viennacl is complete: Failure [failed compile] Build details are at http://buildbot.shogun-toolbox.org/builders/trusty%20-%20libshogun%20-%20viennacl/builds/724 blamelist: Viktor Gal <viktor.gal@maeth.com>	05:51
shogun-buildbot	build #1152 of nightly_default is complete: Failure [failed test notebooks] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_default/builds/1152 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Viktor Gal <vigsterkr@gmail.com>, Ariane Paola Gomes <arianepaola@users.noreply.github.com>, OXPHOS <engelzora@gmail.com>	06:15
shogun-notifier-	shogun: Saurabh7 :develop * 74d4482 / / (2 files): https://github.com/shogun-toolbox/shogun/commit/74d44821014fbe5de4c2d75748479228e8167ef5	06:40
shogun-notifier-	shogun: replace lapack calls and update test	06:40
shogun-notifier-	shogun: Viktor Gal :develop * 5a78062 / / (2 files): https://github.com/shogun-toolbox/shogun/commit/5a7806282bdb060e4ed66fdfbe743c751508e929	06:40
shogun-notifier-	shogun: Merge pull request #3288 from Saurabh7/larsfix	06:40
shogun-notifier-	shogun:	06:40
shogun-notifier-	shogun: replace lapack calls	06:40
@wiking	Saurabh7: ok good :)	06:40
@wiking	now this is done as well \o/	06:40
@wiking	Saurabh7: what's your next step?	06:41
shogun-buildbot	build #725 of trusty - libshogun - viennacl is complete: Failure [failed compile] Build details are at http://buildbot.shogun-toolbox.org/builders/trusty%20-%20libshogun%20-%20viennacl/builds/725 blamelist: Viktor Gal <vigsterkr@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com>	06:41
Saurabh7	wiking: great thanks !	06:43
Saurabh7	looking at cart right now	06:43
Saurabh7	some functions need to be polished	06:43
@wiking	heheh definitely	06:44
Saurabh7	wiking: makes sense to use eigen there too ?	06:47
@wiking	why not? :)	06:47
Saurabh7	for example look at this https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/multiclass/tree/CARTree.cpp#L944	06:48
Saurabh7	ok then	06:48
@wiking	i mean i woudl be most happy to use linalg+eigen :)	06:48
@wiking	Saurabh7: ok so total_weight = linalg.sum(weighted_lab_classes)	06:48
@wiking	right?	06:48
Saurabh7	yep	06:49
@wiking	while gini	06:49
Saurabh7	dot	06:49
@wiking	is sum(weighted_lab_classes*weighted_lab_classes)	06:49
@wiking	ah yeah true	06:49
@wiking	i'm an idiot	06:49
@wiking	:))	06:49
@wiking	yeah it's a simple dot product	06:49
Saurabh7	:)	06:49
@wiking	mmm do we have linalg::dot?	06:49
@wiking	because if yes please use that	06:49
Saurabh7	yes its there	06:50
@wiking	instead of direct eigen calls	06:50
Saurabh7	isnt it being modified ?	06:50
Saurabh7	or the api remains same ?	06:50
Saurabh7	OXPHOS: ^	06:50
@wiking	yeah it is changing but none the less	06:50
@wiking	when we do the new thing	06:50
@wiking	(what OXPHOS working on)	06:50
@wiking	we'll change it here as well	06:50
@wiking	if the api changes	06:50
@wiking	the importnat thing is that you use linalg:: stuff as much as you can	06:51
@wiking	because that way one can laverage the gpu	06:51
@wiking	if one has gpu backend	06:51
Saurabh7	yep true	06:51
Saurabh7	but current linalg dot has some performance issues with eigen backend :)	06:52
@wiking	OXPHOS: are you still here?	06:52
OXPHOS	not sure whether linalg::dot will take SGVector in the future..I'd say no	06:52
@wiking	Saurabh7: dont worry aobut that... that's gonna be fixed	06:52
OXPHOS	everything needs to be wrapped with Vector	06:52
@wiking	OXPHOS: so back to your Vector question	06:53
@wiking	so the idea there was	06:53
@wiking	that that thing should be working	06:53
@wiking	regardless whether you have viennacl or not	06:53
@wiking	you just have a backend	06:53
@wiking	right?	06:53
@wiking	and the backend is just a pointer	06:53
@wiking	(in the future to a shared library)	06:53
@wiking	you dont care whether it is GPUBackend implemented by viennacl	06:53
@wiking	or magma	06:54
@wiking	or cuda	06:54
@wiking	you just care that if the vector is on the gpu	06:54
@wiking	and if there's a gpub backend registered	06:54
@wiking	then you do the operation	06:54
OXPHOS	oh right	06:54
@wiking	and this should be done runtime	06:54
@wiking	not compile time	06:54
@wiking	your #ifdef HAVE_VIENNACL will do compile time stuff	06:54
OXPHOS	I thought throwing everything in .cpp would solve the problem	06:54
@wiking	noup	06:55
@wiking	i mean yes but no	06:55
@wiking	:)))	06:55
@wiking	this vector implementation is just the linalg interface	06:55
@wiking	that handles the thing around the various linalg backends	06:55
@wiking	that should always work	06:55
@wiking	and commpile	06:55
@wiking	in it's full extent	06:55
@wiking	meaning the whole gpu thing should be there	06:56
OXPHOS	but how I can completely avoid that? I still need to initialize it at some time	06:56
@wiking	initialize what and where exactly?	06:56
@wiking	i mean in the beginning you only have	06:56
@wiking	1 default (eigen based) cpu backend	06:56
@wiking	the gpu backend is nullptr	06:57
@wiking	the user can set that	06:57
@wiking	(or of course we should start having support for a config file) so that one can set that fixed via a config file	06:57
OXPHOS	like, if somehow I already have a Vector with GPUVector (transfer maybe). And the Vector copy constructor needs to transfer the GPU part	06:57
@wiking	yeah	06:58
@wiking	your gpubackend	06:58
OXPHOS	Heiko mentioned today the GPU backend must be registered before compiling	06:58
@wiking	has to have a copy function	06:58
@wiking	ARGH FUCK	06:58
@wiking	where did he write this	06:58
@wiking	why would be this true?!!?!	06:58
@wiking	jesus	06:58
@wiking	this goes against anything we wanna achieve here	06:58
OXPHOS	.. let me check. maybe i understood wrong	06:58
@wiking	anyhow	06:58
@wiking	you gpu backend	06:58
@wiking	should be the one who knows how to copy things	06:59
@wiking	from a cpu to gpu	06:59
@wiking	because you shouldn't care of the type of the gpu backend	06:59
@wiking	if it's cuda, viennacl or magma or jesusGPU	06:59
@wiking	for you it's just	06:59
@wiking	gpubackend->whateverLinalgMethod()	06:59
@wiking	and it should have	06:59
@wiking	a transfer_to_gpu() transfer_to_cpu method	06:59
@wiking	because the particular gpu backend	07:00
@wiking	will know how to do these things	07:00
@wiking	a) efficiently	07:00
OXPHOS	gpu backend - so Vector.transfer_to_gpu() should call gpu_backend.transfer_to_gpu()	07:00
@wiking	yes	07:00
@wiking	but i fucking hate this vector	07:00
@wiking	this is the biggest bullshit invention	07:00
@wiking	dunno where this idea came from	07:00
@wiking	but it's taking everything the wrong way	07:01
OXPHOS	yeah unfortunately it seems the three of you have different ideas about the design..	07:01
@wiking	yeah	07:01
@wiking	leave this thing	07:01
@wiking	i'll write an email	07:01
@wiking	because everybody is doing something super smart	07:01
@wiking	when it's so fucking simple	07:01
@wiking	anyhow	07:01
@wiking	can you finish stuff with cereal?	07:01
OXPHOS	now the prototype is working	07:02
@wiking	ok	07:02
@wiking	well that should be extended	07:02
OXPHOS	i was checking out the parameter/save stuff	07:02
@wiking	to every class right?	07:02
OXPHOS	and now should read tag stuff	07:02
OXPHOS	yes	07:02
OXPHOS	not sure about how smart pointer will affect this..I really hope there's smart pointer when I was working with that shared ref_count stuff a while ago	07:03
@wiking	mmm	07:03
@wiking	you should not care about smart_ptr	07:03
@wiking	we have ref_count object	07:03
@wiking	that thing will be changed	07:04
@wiking	or will wrap actually smart_ptr	07:04
OXPHOS	yes i mean for the latest update the Vector and SGVector shares the same memory...and all the transfer and release stuff	07:04
OXPHOS	i added some methods but it might just be me not getting the right way to do so	07:05
OXPHOS	but i'll try. u'r right ref_count should work for serialization	07:05
OXPHOS	and I also I'll be in China from Jun 19th - July 19th	07:06
OXPHOS	maybe we'll have more overlapped working time..	07:06
@wiking	https://github.com/shogun-toolbox/shogun/pull/3277/files/3baae8059acbc6fcf0423d2ef67dfd1b27c890b0#diff-4e89c8ea6b0b57d1f78952d268054c52R188	07:07
@wiking	why is this there actually	07:07
@wiking	?	07:07
OXPHOS	T const * Vector<T>::data() const?	07:07
OXPHOS	it's already gone	07:07
OXPHOS	no?	07:07
@wiking	no	07:07
@wiking	+	07:07
@wiking	+#ifdef HAVE_VIENNACL	07:07
@wiking	+m_gpu_impl->transferToCPU(m_data.get()); // Assume the transfer won't change the length of the vector	07:07
@wiking	+#endif	07:08
@wiking	why do you need to guard this	07:08
@wiking	?	07:08
@wiking	or this	07:08
@wiking	https://github.com/shogun-toolbox/shogun/pull/3277/files/3baae8059acbc6fcf0423d2ef67dfd1b27c890b0#diff-4e89c8ea6b0b57d1f78952d268054c52R160	07:08
@wiking	why do you create on runtime	07:08
@wiking	a gpu backend?	07:09
OXPHOS	The first one was already gone	07:10
OXPHOS	is	07:10
@wiking	where?	07:10
@wiking	just refreshed	07:10
@wiking	we are talking about https://github.com/shogun-toolbox/shogun/pull/3277	07:10
@wiking	right?	07:10
OXPHOS	yes now it's the 8th commit	07:10
OXPHOS	yours is 6th..	07:11
OXPHOS	but i do still have #ifdef	07:11
@wiking	same idea	07:11
@wiking	https://github.com/shogun-toolbox/shogun/pull/3277/files#diff-4e89c8ea6b0b57d1f78952d268054c52R161	07:11
@wiking	why is the linalg backend created	07:11
@wiking	when you call move_to_GPU	07:11
@wiking	how do you know	07:12
@wiking	which gpu linalg backend you wanna use	07:12
@wiking	or create?	07:12
@wiking	you should not care about these things	07:12
@wiking	it should be either there	07:12
@wiking	or nullptr	07:12
@wiking	and you just call m_gpu_impl	07:12
@wiking	to transfer shit	07:13
OXPHOS	Yeah..I know now. you want to have the GPUImpArray wrapped in GPUBackend	07:13
OXPHOS	but now it's wrapped by Vector	07:13
@wiking	no	07:13
@wiking	i want a simple fucking interface:)	07:13
@wiking	nothing else	07:13
@wiking	and a very simple logic	07:13
@wiking	this is waaaaaaaaaaaaaaaaaaaaay too fucking complicated	07:13
@wiking	for no reason	07:13
@wiking	but dont worry	07:14
@wiking	i sent out an email to the parties	07:14
@wiking	to clear up things in everybody's head	07:14
@wiking	and let's hope by the time you wake up	07:14
@wiking	you'll have something useful info	07:15
@wiking	because i see you refactor code	07:15
@wiking	like 10 times	07:15
OXPHOS	haha yeah..learned a lot	07:15
Saurabh7	runtime goes form 3 sec->8 sec with linalg :)	07:36
Saurabh7	wiking: ^	07:36
Saurabh7	should I use eigen for benchamrk then, or how do i check	07:37
-!- OXPHOS [9d8b131c@gateway/web/freenode/ip.157.139.19.28] has quit [Quit: Page closed]		07:50
Saurabh7	ha passing const ref for sgvector makes so much difference	07:57
@wiking	Saurabh7: :)	08:08
@wiking	yeah no need for copy on stack ;)	08:08
@wiking	does the current linalg::dot takes non-const values?	08:08
Saurabh7	yes it does	08:09
@wiking	well you have 2 options	08:09
@wiking	a) go with the eigen implementation but then you add // FIXME: use linalg::dot when performance is fixed	08:09
Saurabh7	ye could do that	08:10
@wiking	b) use linalg method	08:10
-!- sanuj [~sanuj@117.204.251.87] has joined #shogun		09:27
sanuj	hey lisitsyn	09:29
sanuj	wiking, there?	09:32
@wiking	yes	09:37
@wiking	sort of	09:37
sanuj	wiking, can you merge this https://github.com/shogun-toolbox/shogun/pull/3281	09:38
sanuj	heiko forgot to merge last night	09:38
sanuj	i need this for my mkl cookbook	09:38
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout]		09:40
-!- HeikoS_mobile [~Mutter@host-92-0-162-192.as43234.net] has joined #shogun		10:02
HeikoS_mobile	wiking: any ideas how to get that test coverage thing on travis up again? Stopped a while ago	10:03
HeikoS_mobile	The one that shows the badge	10:03
sanuj	hey HeikoS_mobile	10:04
HeikoS_mobile	arianepaola: jo!	10:04
sanuj	can you merge PRs from phone	10:04
sanuj	svm cookbook	10:04
HeikoS_mobile	arianepaola: please don't forget the cookbooks	10:04
HeikoS_mobile	sanuj: not on phone	10:04
HeikoS_mobile	But will come back later	10:04
sanuj	aaah okay	10:04
-!- besser82 [~besser82@fedora/besser82] has joined #shogun		10:12
-!- mode/#shogun [+o besser82] by ChanServ		10:12
@wiking	http://www.speedtest.net/result/5407787979.png	10:13
@wiking	hah	10:13
@wiking	finally internet arrived	10:13
lisitsyn	okie I am in my uber haha	10:13
lisitsyn	sanuj: whats up	10:14
-!- sanuj [~sanuj@117.204.251.87] has quit [Ping timeout: 244 seconds]		10:16
-!- besser82_ [~besser82@fedora/besser82] has joined #shogun		10:28
-!- mode/#shogun [+o besser82_] by ChanServ		10:28
-!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 258 seconds]		10:31
-!- besser82_ [~besser82@fedora/besser82] has quit [Ping timeout: 250 seconds]		10:32
-!- HeikoS_mobile [~Mutter@host-92-0-162-192.as43234.net] has quit [Remote host closed the connection]		10:35
-!- besser82_ [~besser82@fedora/besser82] has joined #shogun		10:50
-!- mode/#shogun [+o besser82_] by ChanServ		10:50
-!- sanuj [~sanuj@117.204.251.87] has joined #shogun		11:06
-!- besser82_ is now known as besser82		11:09
-!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 244 seconds]		12:09
sanuj	lisitsyn, one question	12:24
-!- HeikoS [~heiko@nat-240-8.internal.eduroam.ucl.ac.uk] has joined #shogun		12:33
-!- mode/#shogun [+o HeikoS] by ChanServ		12:33
@wiking	HeikoS: wazza sorry	12:36
@wiking	had to work on my internet connection	12:36
@HeikoS	wiking: jojojo	12:36
@HeikoS	wiking: whats up	12:36
@HeikoS	two things to quickly chat	12:36
@HeikoS	1.) linalg -- whats going on?	12:36
@HeikoS	2.) test coverage, a way to actiuvate that again?	12:37
@wiking	HeikoS: sent an email... would be good to discuss	12:37
@wiking	in an email	12:37
@HeikoS	ok	12:37
@HeikoS	checking	12:37
@wiking	becuase that has better history	12:37
@wiking	and more exact	12:37
@wiking	than here	12:37
@HeikoS	agreed	12:38
sanuj	yes test coverage please	12:38
sanuj	HeikoS, merge this PR too https://github.com/shogun-toolbox/shogun/pull/3281	12:38
-!- c4goldsw [c1a99ae1@gateway/web/cgi-irc/kiwiirc.com/ip.193.169.154.225] has joined #shogun		12:54
@HeikoS	wiking: replied	13:00
@HeikoS	sanuj: merged	13:09
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun		13:09
shogun-notifier-	shogun: Sanuj :develop * c4ab6ff / / (18 files): https://github.com/shogun-toolbox/shogun/commit/c4ab6ffb384ea563327f64612b659033e9e21f13	13:09
shogun-notifier-	shogun: add kernel svm cookbook	13:09
shogun-notifier-	shogun: Heiko Strathmann :develop * 5ea6f14 / / (18 files): https://github.com/shogun-toolbox/shogun/commit/5ea6f145430a184bd18463324c4478b8f1d59234	13:09
shogun-notifier-	shogun: Merge pull request #3281 from sanuj/cookbook_svm	13:09
shogun-notifier-	shogun:	13:09
shogun-notifier-	shogun: add kernel svm cookbook	13:09
sanuj	HeikoS, thanks	13:09
@HeikoS	wiking: ok point 1 solved	13:10
shogun-buildbot	build #726 of trusty - libshogun - viennacl is complete: Failure [failed compile] Build details are at http://buildbot.shogun-toolbox.org/builders/trusty%20-%20libshogun%20-%20viennacl/builds/726 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Sanuj <sanuj.sharma.in@gmail.com>	13:10
@HeikoS	wiking: any comment on test coverage?	13:10
@HeikoS	wtf if wrong with trusty?	13:10
-!- 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]		13:26
-!- dennyjoo_ [~dennyjooo@223.206.62.16] has joined #shogun		13:32
-!- dennyjoo_ [~dennyjooo@223.206.62.16] has quit [Client Quit]		13:33
@wiking	HeikoS: fired a bug... we dont have linalg::mean for vinnacl backend	13:38
@wiking	HeikoS: yeah you've got it! so lets make sure that things happen that way from now on	13:39
@wiking	HeikoS: lemme get the test covarge thing	13:39
@wiking	many things has happend in the last 3 hours...	13:39
@HeikoS	wiking: ok cool, Ill make sure they go this way	13:47
@HeikoS	wiking: thanks for the coverage	13:47
@HeikoS	sanuj: we will have coverage for travis soon hopefully, so then you can use that	13:47
sanuj	okay	13:47
sanuj	i'm currently working on swig interface	13:48
@HeikoS	sanuj: good	13:48
@HeikoS	wiking: btw about alignment	13:52
@HeikoS	I want to postpone that	13:52
@HeikoS	once linalg is done, we can do this for all SG*	13:52
@HeikoS	but easier to leave that out for now	13:52
@HeikoS	to avoid further compliucations	13:53
-!- lambday [8028b10a@gateway/web/freenode/ip.128.40.177.10] has joined #shogun		13:58
-!- mode/#shogun [+o lambday] by ChanServ		13:58
@wiking	HeikoS: wtf is so complicated about that alignment?	14:02
@HeikoS	nothing	14:02
@wiking	i mean it's just the size of memory	14:02
@wiking	if you copy	14:02
@HeikoS	but need to change SGVector	14:02
@wiking	it's the same size	14:02
@wiking	why?	14:03
@wiking	if you copy that to SGVector	14:03
@wiking	it'll be the same	14:03
@wiking	bazdmeg	14:03
@wiking	ne idegesits	14:03
@wiking	do it!	14:03
@HeikoS	no	14:03
@wiking	https://www.youtube.com/watch?v=ZXsQAXx_ao0	14:03
@HeikoS	its not a good idea at this point	14:03
@wiking	it is a very good idea	14:03
@HeikoS	we can easily do that after linalg is done	14:03
@wiking	oxphos learned about it	14:03
@wiking	lambday: knows it	14:03
@wiking	DO IT!	14:03
@HeikoS	i dont agree	14:03
@HeikoS	it is an additional complexity that distract from main task	14:04
@wiking	what is a ocmplexity	14:04
@HeikoS	and there is no problem with doing it after	14:04
@wiking	there's even a typdef for that	14:04
@wiking	nobody needs to do anything about it	14:04
@wiking	i have given the line	14:04
@HeikoS	then it can be done after	14:04
@wiking	that works for any T	14:04
@wiking	that's all	14:04
@HeikoS	yeah all good	14:04
@wiking	but then wtf?	14:04
@HeikoS	but one thing at a time	14:04
@wiking	lets not be pyton developer	14:04
@wiking	s	14:05
@HeikoS	look	14:05
@HeikoS	lets just do it after	14:05
@wiking	i dont look	14:05
@wiking	i do	14:05
@HeikoS	in a second pr	14:05
@wiking	:)	14:05
@wiking	no	14:05
@wiking	in a same pr	14:05
@wiking	but then again	14:05
@wiking	let oxphos decide it	14:05
@wiking	ok?	14:05
@wiking	if she says she is ok with it	14:05
@wiking	let her do it	14:05
@wiking	if she says she is not	14:05
@HeikoS	come to gs	14:05
@wiking	then let her not do it	14:05
@HeikoS	shogun-gs	14:05
sanuj	lisitsyn, there?	14:16
lisitsyn	sanuj: y	14:17
sanuj	lisitsyn, %template(TagKernel) Tag<Some<CKernel> >;	14:17
sanuj	this is visible in python now ^	14:17
sanuj	but what is one supposed to do with this in python?	14:17
lisitsyn	oh cool	14:17
lisitsyn	well classifier.setKernel(kernel)	14:17
lisitsyn	setKernel("kernel", kernel)	14:18
sanuj	lisitsyn, but will it work for a gaussian kernel	14:18
lisitsyn	not yet	14:18
sanuj	okay	14:18
sanuj	lisitsyn, so now do i do the same for all the classes in my list?	14:18
lisitsyn	yeah I think so	14:18
lisitsyn	sanuj: meanwhile I'll check	14:18
lisitsyn	how to spawn Some<CKernel> from CGaussianKernel	14:19
sanuj	okay	14:19
sanuj	lisitsyn, i also tried this	14:19
sanuj	%template(TagGaussKernel) Tag<CGaussianKernel>;	14:19
sanuj	worked	14:19
sanuj	but	14:19
@HeikoS	Saurabh7: can you update me a bit on what shappening?	14:19
sanuj	when i added %template(setGaussKernel) CSGObject::set<CGaussianKernel, void>;	14:19
sanuj	lisitsyn, it gives Segfault when i import modshogun in python	14:20
lisitsyn	sanuj: well it is not needed anyway	14:20
-!- arianepaola [~ariane@unaffiliated/arianepaola] has quit [Read error: Connection reset by peer]		14:20
lisitsyn	CGaussianKernel*	14:20
lisitsyn	it could work if you used CGausianKernel*	14:20
lisitsyn	ohhhh	14:20
lisitsyn	maybe we should focus on pointers for now	14:20
lisitsyn	sanuj: could you try	14:20
lisitsyn	%template(TagKernel) Tag<CKernel*>;	14:20
lisitsyn	this way	14:20
sanuj	okay	14:21
sanuj	i will try	14:21
sanuj	i had proposed this earlier but u told to use some	14:21
sanuj	lisitsyn, if this works then we don't need some<CKernel>?	14:21
lisitsyn	yeah	14:22
lisitsyn	yet	14:22
sanuj	okay, let me try	14:22
-!- arianepaola [~ariane@unaffiliated/arianepaola] has joined #shogun		14:27
sanuj	lisitsyn, CKernel* works as good as some<Ckernel>	14:29
arianepaola	hello everyone :-)	14:30
sanuj	arianepaola, hey	14:30
arianepaola	hi sanuj	14:30
@wiking	arianepaola: hey! how's cookbooks going/the refactor of the deb packages for the modular interfaces?	14:30
arianepaola	hi wiking	14:32
arianepaola	if cmake is not an option for the packages, what can I use?	14:33
@wiking	mmm let me show u	14:33
@wiking	ahhhahahahahah	14:35
@wiking	maaaaaaaaaaaaaaaaaaaaan	14:35
@wiking	google code is dead :)	14:35
@wiking	sonney2k: ping	14:35
arianepaola	? https://code.google.com/archive/d/code.google.com	14:35
arianepaola	wiking: maybe it got archived	14:36
@wiking	there as this http://bollin.googlecode.com/svn/shogun/trunk/debian/source/	14:36
@wiking	and this http://bollin.googlecode.com/svn/python-shogun/trunk/debian	14:36
arianepaola	only 404	14:37
@wiking	yep	14:37
@wiking	and soembody said that no thing can disappear on internet :)	14:37
arianepaola	https://code.google.com/archive/p/shogun-toolbox/source/default/source	14:37
@wiking	it doesn't have the debian direcotry	14:38
arianepaola	hmm, it's missing the files	14:38
@wiking	tha contained the rules	14:38
arianepaola	it is probably just a matter of time when google deletes the archives also, as the github export tool is no longer available	14:40
@wiking	arianepaola: trying to get it from sonney2k :) maybe he has it archived somewhere :)	14:42
arianepaola	I have tried to see ubuntu and debian package archives that have the source, it is also not there	14:42
@wiking	funny	14:43
@wiking	the patches are cached https://webcache.googleusercontent.com/search?q=cache:aT0AXb9AnJYJ:https://bollin.googlecode.com/svn/shogun/trunk/debian/patches/+&cd=4&hl=en&ct=clnk&gl=sg&client=firefox-b-ab	14:43
arianepaola	yeah but 404	14:43
-!- GandalfTheWizard [~Eva@112.10.170.90] has quit [Quit: Leaving.]		14:48
sanuj	lisitsyn, shall i just make everything pointer instead of some<> now?	14:52
@wiking	lisitsyn: have u seen that problem still with the generated examples?	14:53
lisitsyn	wiking: no what problem?	15:15
lisitsyn	sanuj: yes	15:15
sanuj	lisitsyn, cool	15:15
sanuj	lisitsyn, i need to write unit-tests for any also	15:16
@wiking	lisitsyn: still leaks	15:16
lisitsyn	wiking: woah	15:16
lisitsyn	really?	15:16
lisitsyn	oh a bit different now	15:17
@wiking	yep	15:24
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout]		16:09
-!- sanuj [~sanuj@117.204.251.87] has quit [Ping timeout: 240 seconds]		16:13
-!- OXPHOS [9d8b131c@gateway/web/freenode/ip.157.139.19.28] has joined #shogun		16:20
OXPHOS	lambday, wiking, HeikoS, ping	16:25
-!- besser82 [~besser82@fedora/besser82] has joined #shogun		16:27
-!- mode/#shogun [+o besser82] by ChanServ		16:27
-!- sanuj [~sanuj@117.204.251.87] has joined #shogun		16:40
-!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 240 seconds]		16:53
-!- GandalfTheWizard [~Eva@112.10.170.90] has joined #shogun		17:12
-!- [Chris] [~Chris]@interferon.am10.uni-tuebingen.de] has quit [Ping timeout: 276 seconds]		17:12
-!- GandalfTheWizard [~Eva@112.10.170.90] has quit [Quit: Leaving.]		17:27
@HeikoS	lisitsyn: around?	17:42
lisitsyn	HeikoS: yes	17:42
@HeikoS	lisitsyn: qeustion	17:42
@HeikoS	eigen3	17:42
@HeikoS	if I do Map<> ...	17:42
@HeikoS	does this have a runtime cost?	17:42
@HeikoS	i.e. does it create a new object	17:43
lisitsyn	yes but on stack	17:43
@HeikoS	(that wraps the memory)	17:43
lisitsyn	negligible	17:43
@HeikoS	so it is not somehow compile time magic?	17:43
lisitsyn	HeikoS: well some temporary object on stack	17:43
@HeikoS	cool thanks!	17:43
@HeikoS	like SGVector right?	17:43
lisitsyn	HeikoS: yeah	17:44
@HeikoS	lisitsyn: but passing SGVector by value is sometimes slow no?	17:44
@HeikoS	like when it is done in an interface in a loop?	17:44
lisitsyn	HeikoS: would be curious to check why	17:45
@HeikoS	kk	17:45
@HeikoS	but it should not	17:45
lisitsyn	HeikoS: ahh refcounting!	17:45
@HeikoS	i.e. pass by value with sgvector is ok?	17:45
lisitsyn	Map doesn't do that I think	17:45
@HeikoS	I see	17:45
Saurabh7	HeikoS: hihi	17:47
@HeikoS	Saurabh7: jo	17:47
@HeikoS	updates please :)	17:47
Saurabh7	HeikoS: I was trying chaning this same thing	17:48
Saurabh7	with CART	17:48
Saurabh7	4 vectos being passed to one method all by value	17:48
Saurabh7	makes quite some diff when I do const ref	17:48
lisitsyn	HeikoS: Map doesn't have copy ctor	17:48
@HeikoS	Saurabh7: cool	17:48
@HeikoS	benchmarks=?	17:48
@HeikoS	send a PR with that!	17:48
Saurabh7	ok starting jsut with that ?	17:49
Saurabh7	ok i will include one more thing	17:49
Saurabh7	HeikoS: I started a minimal PR	18:08
@HeikoS	ok	18:09
Saurabh7	outputs are just for idea now, not presentable yet	18:09
arianepaola	HeikoS: hi	18:09
Saurabh7	i will add it to benchmark framework too, along with finishing up lars one	18:09
arianepaola	I saw your message	18:09
sanuj	lisitsyn, do you know what might be the reason for this error?	18:10
Saurabh7	HeikoS: https://github.com/shogun-toolbox/shogun/pull/3293	18:10
sanuj	modshogunPYTHON_wrap.cxx:31328:32: error: template argument 1 is invalid	18:10
sanuj	shogun::Tag< CStringKernel * > *arg2 = 0 ;	18:10
sanuj	lisitsyn, ^	18:10
lisitsyn	you miss some includes	18:10
lisitsyn	I guess	18:10
sanuj	okay	18:10
sanuj	lisitsyn, can i include stringkernel in sgbase.i?	18:11
arianepaola	HeikoS: do you know the best way to ping sonney2k? the original debian sources vanished from google code	18:11
lisitsyn	I guess so	18:11
@wiking	Saurabh7: so we are still slow :P	18:12
@HeikoS	arianepaola: email, cc me	18:12
@wiking	Saurabh7: but good improvement	18:13
@wiking	arianepaola: i've written him an email	18:13
@wiking	so we'll hear back from him	18:13
arianepaola	wiking: thanks :-)	18:13
@wiking	Saurabh7: where do we loose the most still?	18:13
Saurabh7	wiking: yes, need to hunt something else	18:13
Saurabh7	the refcount vanihsed from perf report tho	18:13
Saurabh7	which is good	18:14
@wiking	Saurabh7: do you maybe use valgrind's callgrind to debug/	18:14
@wiking	or gprof?	18:14
Saurabh7	ok	18:15
@wiking	i mean do you use any of these tools to profile the code?	18:15
@wiking	if not it's really worth to try	18:15
Saurabh7	wiking: i used callgrind too sometimes	18:15
@wiking	as that'll tell you where is the most time 'wasted'	18:15
Saurabh7	i used perf here	18:16
Saurabh7	ok i run with callgrind	18:16
Saurabh7	will*	18:16
sanuj	lisitsyn, template <class ST> class CStringKernel : public CKernel	18:44
sanuj	the error was because it's a template	18:44
lisitsyn	ah ok	18:45
sanuj	lisitsyn, what type to use?	18:45
sanuj	and i don't understand why it is a template	18:45
lisitsyn	uhmmm you better skip it for now	18:45
sanuj	okay	18:45
lisitsyn	sanuj: strings are not only char strings in shogun	18:45
sanuj	alright	18:46
-!- besser82 [~besser82@fedora/besser82] has joined #shogun		18:48
-!- mode/#shogun [+o besser82] by ChanServ		18:48
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun		18:50
shogun-notifier-	shogun: lambday :feature/translational_invariant_kernel * 8798d99 / / (3 files): https://github.com/shogun-toolbox/shogun/commit/8798d99d4e9ed6bda784f19b03939a151bdbb568	18:50
shogun-notifier-	shogun: Added shift invariant kernel class.	18:50
shogun-notifier-	shogun: lambday :feature/translational_invariant_kernel * 6c56709 / / (7 files): https://github.com/shogun-toolbox/shogun/commit/6c567091534a9e15e5979b166c421eefbb4fe206	18:50
shogun-notifier-	shogun: Refactored GaussianKernel as a subclass of ShiftInvariantKernel	18:50
@lambday	argh!	18:52
@lambday	sorry about the mess up	18:52
@lambday	wanted to push to my fork!	18:52
sanuj	lisitsyn, same thing is happening for sparsekernel	18:52
lisitsyn	sanuj: yeah skip it then	18:53
@lambday	lisitsyn: yo	18:53
lisitsyn	lambday: hey	18:53
@lambday	lisitsyn: what should I do to undo the last commit to upstream? I still want it in my fork so that I can do a PR later	18:53
lisitsyn	can you push -f?	18:54
@lambday	reset --soft?	18:54
@lambday	lisitsyn: yeah	18:54
lisitsyn	lambday: git reset HEAD^1	18:55
lisitsyn	git push -f	18:55
@lambday	wrote "upstream" instead of "origin" by mistake and it's fucked up!	18:55
@lambday	lisitsyn: so that does a soft reset, right?	18:55
lisitsyn	yeah	18:55
@lambday	cool!	18:55
lisitsyn	moves your HEAD one commit back	18:55
lisitsyn	then you push so that your head becomes upstream head	18:56
@lambday	what do I to get my HEAD back to the sha	18:56
@lambday	(for my PR later?)	18:56
lisitsyn	you need your commit in other branch?	18:56
@lambday	yeah the feature/.. branch that I am working on	18:57
lisitsyn	you can apply it using cherry-pick	18:57
lisitsyn	just copy-paste its sha1	18:57
lisitsyn	it would apply commit by sha1 on top of your head	18:58
@lambday	lisitsyn: alright let me try that	18:58
@lambday	ah actually I pushed it to a feature branch	19:00
lisitsyn	lolz!	19:04
lisitsyn	:)	19:04
@lambday	lisitsyn: brain not working anymore! :D thinking something, typing something else!	19:06
@lambday	lisitsyn: anyway that cherry pick worked.. thanks :)	19:06
@lambday	lisitsyn: btw changed it to shift invariant kernel..	19:07
lisitsyn	lambday: oh :) cool	19:07
lisitsyn	shorter is better!	19:08
@lambday	yep	19:08
sanuj	lisitsyn, modshogunPYTHON_wrap.cxx:38202:16: error: ‘CVwConditionalProbabilityTree’ is not a member of ‘shogun’	19:32
sanuj	shogun::Tag< shogun::CVwConditionalProbabilityTree * > *arg2 = 0 ;	19:32
-!- ptizoom [~christian@host-92-21-231-167.as13285.net] has quit [Remote host closed the connection]		19:35
-!- sanuj [~sanuj@117.204.251.87] has quit [Remote host closed the connection]		19:42
-!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 258 seconds]		20:07
-!- besser82 [~besser82@fedora/besser82] has joined #shogun		20:32
-!- mode/#shogun [+o besser82] by ChanServ		20:32
OXPHOS	lambday: any updates :)	20:33
@lambday	OXPHOS: hey!	20:34
@lambday	OXPHOS: yeah quite a few!	20:34
@lambday	OXPHOS: me and HeikoS were trying to draft something concrete based on what we discussed	20:35
@lambday	OXPHOS: will share with you soon!	20:35
OXPHOS	lambday: aah okay thx! ;)	20:35
@lambday	meanwhile, I think you can work on cereal and other stuffs for the time being?	20:35
OXPHOS	sure!	20:36
-!- lambday [8028b10a@gateway/web/freenode/ip.128.40.177.10] has quit [Ping timeout: 250 seconds]		20:44
lisitsyn	haha	21:06
lisitsyn	oh now I realize	21:06
lisitsyn	HeikoS: houston	21:06
lisitsyn	we have a problem	21:06
lisitsyn	so we used auto too much in meta examples	21:07
lisitsyn	so that we missed we still get some raw pointers out there	21:07
@HeikoS	lisitsyn: jojo	21:48
@HeikoS	ouch	21:48
@HeikoS	lisitsyn: solutions?	21:48
lisitsyn	HeikoS: yes	21:48
lisitsyn	wrap it	21:48
@HeikoS	I think we can change that	21:48
@HeikoS	wrap?	21:48
lisitsyn	result_of(lda->apply_binary(..));	21:48
lisitsyn	this is how I called it	21:49
@HeikoS	nah	21:49
@HeikoS	for examples?	21:49
lisitsyn	yes	21:49
@HeikoS	that illustrate how nice and easy it is to use shogun?	21:49
lisitsyn	yes	21:49
lisitsyn	:D	21:49
lisitsyn	the only way	21:49
lisitsyn	otherwise we live with leaks	21:49
@HeikoS	lisitsyn: could also modidy the meta grammar	21:49
@HeikoS	to UNREF everything at the end?	21:50
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout]		21:50
@HeikoS	so the auto extracts raw pointerß	21:50
lisitsyn	yes	21:50
lisitsyn	well auto is auto	21:50
lisitsyn	in our case it is ptr	21:50
@HeikoS	and some?	21:50
@HeikoS	is ignored?	21:50
lisitsyn	we create objects with some	21:50
lisitsyn	but our api	21:50
lisitsyn	like apply_binary	21:50
lisitsyn	returns pointers	21:50
lisitsyn	nothing to do with that	21:51
@HeikoS	oh I see	21:51
lisitsyn	we either wrap it in examples	21:51
@HeikoS	so I need to unref these	21:51
lisitsyn	or patch whole shogun	21:51
@HeikoS	what about using SG_UNREF?	21:51
lisitsyn	HeikoS: we don't really know what to unref	21:51
@HeikoS	why?	21:52
@HeikoS	everything?	21:52
lisitsyn	HeikoS: not possible	21:52
lisitsyn	you don't know which order	21:52
lisitsyn	it is like toposort of objects	21:52
lisitsyn	it is much worse than some wrapper believe me :D	21:53
@HeikoS	mmh	21:53
lisitsyn	because user would have to worry in which order to unref something	21:53
@HeikoS	SGREF everything in order it was created	21:53
@HeikoS	context free grammar type of thing	21:53
@HeikoS	stack	21:53
@HeikoS	no good	21:53
@HeikoS	?	21:53
lisitsyn	why?	21:53
lisitsyn	then unref twice?	21:53
lisitsyn	I mean how does that help	21:54
@HeikoS	SG_REF everything that is created with new	21:54
@HeikoS	and UNREF it later	21:54
@HeikoS	and unref everything that was returned	21:54
@HeikoS	no?	21:54
lisitsyn	we can unref everything that was returned but in some cases we would get some crazy shit	21:54
lisitsyn	like unrefing result unrefs something else	21:54
@HeikoS	but thats bugs	21:54
@HeikoS	I would just REG everything	21:55
@HeikoS	so after every	21:55
@HeikoS	auto foo = bar	21:55
@HeikoS	SG_REF(foo)	21:55
@HeikoS	and at the end, SG_UNREF(foo) for all foos	21:55
@HeikoS	in opposite order	21:55
lisitsyn	how is that better than wrapping method call?	21:55
lisitsyn	;)	21:55
@HeikoS	that was initial idea	21:55
@HeikoS	because it ressembles more what wiring shogun examples is like	21:56
lisitsyn	if you wrap it you don't care about memory at all	21:56
@HeikoS	ok	21:56
@HeikoS	you convinced me	21:56
@HeikoS	do it :)	21:56
lisitsyn	lets come up with some shorter name	21:56
lisitsyn	HeikoS: the thing is that it is temporary	21:56
lisitsyn	we drop it once all API has no pointers	21:56
lisitsyn	HeikoS: the(lda->apply())	21:57
lisitsyn	:D	21:57
lisitsyn	what about this naming?	21:57
@HeikoS	mmmh	21:57
@HeikoS	what about pointer_wrapper_that_we_have_to_add_but_will_remove_soon	21:57
lisitsyn	pointer_wrapper_that_we_have_to_add_but_will_remove_soon(lda->apply_binary(features));	21:57
lisitsyn	looks good	21:58
lisitsyn	lets do it	21:58
lisitsyn	:D	21:58
@HeikoS	hehe :D	21:58
@HeikoS	if it is temporary	21:58
@HeikoS	I would prefer SG_REF / SG_UNREF	21:59
@HeikoS	ref_wrapper?	21:59
@HeikoS	wrapper?	21:59
lisitsyn	wrap	21:59
@HeikoS	wrap(lda->apply())	21:59
lisitsyn	wrap(lda->apply());	21:59
lisitsyn	yeah	21:59
@HeikoS	like burrito(lda->apply())	21:59
lisitsyn	no	21:59
lisitsyn	well I know what this does	21:59
lisitsyn	maybe	21:59
lisitsyn	:D	21:59
lisitsyn	taco	21:59
lisitsyn	burrito	21:59
@HeikoS	hehe	21:59
@HeikoS	taco	21:59
lisitsyn	ok what about	21:59
@HeikoS	no wrap is ok	22:00
lisitsyn	cocacola(lda->apply());	22:00
lisitsyn	I mean we can earn a bit	22:00
lisitsyn	with ads	22:00
lisitsyn	pepsi wraps it	22:00
lisitsyn	and cocacola unwraps it	22:00
@HeikoS	hehe	22:00
lisitsyn	and then we rename ref() unref() to pringles and cheetos	22:00
@HeikoS	ok I gotta run, thanks for figuring this out!	22:00
lisitsyn	get rich or die tryin'	22:00
lisitsyn	!	22:00
lisitsyn	ok see you	22:00
@HeikoS	sg(lda->apply())	22:01
@HeikoS	also ok	22:01
@HeikoS	but wrap is my facv	22:01
@HeikoS	fav	22:01
@HeikoS	bye	22:01
-!- HeikoS [~heiko@nat-240-8.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.]		22:01
arianepaola	bye everyone, until tomorrow	22:04
lisitsyn	see you	22:06
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun		22:09
shogun-notifier-	shogun: Sergey Lisitsyn :develop * dea533a / examples/meta/generator/targets/cpp.json,src/shogun/base/some.h: https://github.com/shogun-toolbox/shogun/commit/dea533a53c3c63da32cb7bd84cd606c5b58e65b6	22:09
shogun-notifier-	shogun: Add wrapper function to capture pointers	22:09
shogun-notifier-	shogun:	22:09
shogun-notifier-	shogun: This resolves memory leaks in generated examples.	22:09
shogun-notifier-	shogun:	22:09
shogun-notifier-	shogun: The function is to be deleted once we finish our API	22:09
lisitsyn	ok lets see how it goez	22:09
lisitsyn	shogun-buildbot: help	22:09
shogun-buildbot	Get help on what? (try 'help <foo>', 'help <foo> <bar>, or 'commands' for a command list)	22:09
lisitsyn	shogun-buildbot: commands	22:09
shogun-buildbot	buildbot commands: commands, dance, destroy, force, hello, help, last, list, mute, notify, shutdown, source, status, stop, unmute, version, watch	22:09
shogun-buildbot	build #727 of trusty - libshogun - viennacl is complete: Failure [failed compile] Build details are at http://buildbot.shogun-toolbox.org/builders/trusty%20-%20libshogun%20-%20viennacl/builds/727 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com>	22:10
lisitsyn	shogun-buildbot: force "memleak valgrind"	22:10
shogun-buildbot	try 'force build [--branch=BRANCH] [--revision=REVISION] [--props=PROP1=VAL1,PROP2=VAL2...] <WHICH> <REASON>'	22:10
lisitsyn	shogun-buildbot: force build "memleak - valgrind"	22:10
shogun-buildbot	The build has been queued, I'll give a shout when it starts	22:10
shogun-buildbot	build #21 forced	22:11
shogun-buildbot	I'll give a shout when the build finishes	22:11
-!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 252 seconds]		22:38
-!- OXPHOS [9d8b131c@gateway/web/freenode/ip.157.139.19.28] has quit [Quit: Page closed]		23:09
--- Log closed Fri Jun 17 00:00:43 2016

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