Open in new window / Try shogun cloud
--- Log opened Sun Dec 01 00:00:47 2013
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout]00:56
-!- zxtx [~zv@ool-2f110054.dyn.optonline.net] has quit [Ping timeout: 260 seconds]01:31
shogun-buildbot_build #634 of nightly_default is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_default/builds/63404:05
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun06:45
shogun-notifier-shogun: Soeren Sonnenburg :develop * 9a6ce87 / src/interfaces/modular/SGBase.i: https://github.com/shogun-toolbox/shogun/commit/9a6ce877edacdf9a29d683f3011914e62508b93c06:45
shogun-notifier-shogun: include SGRefObject before SGObject for swig06:45
-!- travis-ci [~travis-ci@ec2-54-237-116-165.compute-1.amazonaws.com] has joined #shogun07:35
travis-ci[travis-ci] it's Soeren Sonnenburg's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/1475621807:35
-!- travis-ci [~travis-ci@ec2-54-237-116-165.compute-1.amazonaws.com] has left #shogun []07:35
shogun-buildbot_build #2063 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/2063  blamelist: Soeren Sonnenburg <sonne@debian.org>07:38
-!- iglesiasg [~iglesiasg@206.Red-83-61-168.dynamicIP.rima-tde.net] has joined #shogun08:58
-!- mode/#shogun [+o iglesiasg] by ChanServ08:58
@iglesiasggood morning guys08:58
-!- iglesiasg [~iglesiasg@206.Red-83-61-168.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer]09:10
-!- iglesiasg [~iglesiasg@206.Red-83-61-168.dynamicIP.rima-tde.net] has joined #shogun09:11
-!- mode/#shogun [+o iglesiasg] by ChanServ09:11
shogun-notifier-shogun: Soeren Sonnenburg :develop * a93cb3b / src/ (5 files): https://github.com/shogun-toolbox/shogun/commit/a93cb3b9136f8072472067ac57828992bf6d8d7709:27
shogun-notifier-shogun: drop SERIALIZABLE_DUMMY09:27
@sonney2kiglesiasg, moin!09:27
@iglesiasgsonney2k, you were right with your first comment here https://github.com/shogun-toolbox/shogun-web/pull/3909:55
@iglesiasgsonney2k, it seems that the html files have to be inside the templates directory09:55
@sonney2kiglesiasg, could be worse .. so maybe you just create some extra dir inside the template dir?09:56
@iglesiasgsonney2k, yep09:56
@iglesiasgsonney2k, instead of static/md2html, we use templates/md2html and done09:57
@sonney2kok10:04
@sonney2klisitsyn, F%$*$Y%(*!10:05
@sonney2klisitsyn, how did you ever get the %typemap(javainterfaces) to do *anything*10:05
lisitsynsonney2k: why?10:05
@sonney2kI dont' see in any class any java.io.Externalizable10:05
lisitsynsonney2k: what do you mean?10:06
lisitsyn#ifdef SWIGJAVA%typemap(javainterfaces) SGObject "java.io.Externalizable"10:07
@sonney2klisitsyn, yes I am not seeing any implements Externalizable or so10:07
lisitsynsonney2k: public void writeExternal(java.io.ObjectOutput out) throws java.io.IOException {10:08
lisitsyn?? :)10:08
@sonney2klisitsyn, there also is no writeExternal or anything10:10
@sonney2kI guess I killed it all now10:10
@sonney2klisitsyn, you wrote that stuff so help me!10:10
@sonney2khttp://stackoverflow.com/questions/5477747/cant-figure-out-how-to-make-swig-java-force-a-proxy-class-to-implement-an-inter10:10
lisitsynsonney2k: what's going on? :D10:11
@sonney2kand here the guy does just10:11
@sonney2k%typemap(javainterfaces) Foo "SomeInterface"10:11
@sonney2kstruct Foo {10:11
@sonney2k};10:11
@sonney2kand it is then adding a public class Foo extends SomeBase implements SomeInterface {10:11
lisitsynyeah10:11
lisitsynand what?10:11
@sonney2kso why in 3$#$ hell does it now work with CSGObject now10:11
lisitsyn*not* work?10:12
@sonney2k%typemap(javaimports) CSGObject10:12
@sonney2k%{10:12
@sonney2kimport org.shogun.SerializableFile;10:12
@sonney2kimport org.shogun.SerializableAsciiFile;10:12
@sonney2k%}10:12
@sonney2kI don't see in any .java file these imports10:12
@sonney2klisitsyn, *not* == no implements!10:12
lisitsynuhm10:13
-!- travis-ci [~travis-ci@ec2-54-226-95-169.compute-1.amazonaws.com] has joined #shogun10:14
travis-ci[travis-ci] it's Soeren Sonnenburg's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/1475852310:14
-!- travis-ci [~travis-ci@ec2-54-226-95-169.compute-1.amazonaws.com] has left #shogun []10:14
@sonney2kahh10:14
@sonney2klisitsyn, namespaces!10:14
lisitsynhahaha10:14
@sonney2kmaybe shogun::CSGObject10:14
* sonney2k tries10:14
lisitsynah so now I get it10:14
lisitsynit was SWIGCLASS10:14
lisitsynyeah it must be namespace10:14
lisitsynwe have stupid java externalization btw without buffering and file based10:15
@sonney2klisitsyn, better stupid than none10:15
@sonney2kI hope besser82 finishes his cmake stuff10:15
@sonney2kI would want to give the swig stuff an overhaul10:15
@iglesiasgsonney2k, django template question10:16
@sonney2kso that we have java stuff only in certain files10:16
@sonney2kand not the mess we have now in SGBase / modshogun.i10:16
@sonney2klisitsyn, yes works :D10:17
@sonney2kpublic class SGObject extends SGRefObject implements java.io.Externalizable {10:17
@sonney2klisitsyn, I think I fixed things now for real10:17
@iglesiasgsonney2k, I have in a variable called fname the name of an html file, I can see that doing {{ fname }}. But when I want to include the html doing something like {% include {{fname}} %} it breaks10:17
@sonney2klisitsyn, do you know why we always have a import java.io.Serializable; in there?10:18
@sonney2kiglesiasg, I guess that won't work - maybe you better just generate the templates like {% include real_filename %}10:19
shogun-notifier-shogun: Soeren Sonnenburg :develop * ed592ee / src/interfaces/modular/SGBase.i: https://github.com/shogun-toolbox/shogun/commit/ed592ee8942ecaf9e5bb9e8844a3953924ca8af710:20
shogun-notifier-shogun: add namespace to get Externalizable to work for real10:20
@iglesiasgsonney2k, ahhh I am such an idiot10:21
lisitsynsonney2k: where do we have it?10:21
@iglesiasgI just needed to remove the {{ }} and it works10:21
@sonney2kiglesiasg, :)10:24
@sonney2klisitsyn, what?10:24
@sonney2klisitsyn, for each object we want this serialization right10:24
@sonney2klisitsyn, any idea why you did it for *any* type before not just SGObject?10:28
shogun-buildbot_build #2064 of deb3 - modular_interfaces is complete: Failure [failed test python modular test ruby modular test java modular test csharp modular test lua modular test octave modular test r modular]  Build details are at http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/2064  blamelist: Soeren Sonnenburg <sonne@debian.org>10:46
-!- travis-ci [~travis-ci@ec2-54-242-242-147.compute-1.amazonaws.com] has joined #shogun11:03
travis-ci[travis-ci] it's Soeren Sonnenburg's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/1475914111:03
-!- travis-ci [~travis-ci@ec2-54-242-242-147.compute-1.amazonaws.com] has left #shogun []11:03
lisitsynsonney2k: hmm no11:16
lisitsynI don't remember that11:16
@iglesiasgsonney2k, when is the shogun repo updated in the machine that contains shogun-web?11:25
-!- zxtx [~zv@ool-2f110054.dyn.optonline.net] has joined #shogun11:30
shogun-buildbot_build #2065 of deb3 - modular_interfaces is complete: Failure [failed test python modular test ruby modular test java modular test csharp modular test lua modular test octave modular test r modular]  Build details are at http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/2065  blamelist: Soeren Sonnenburg <sonne@debian.org>11:46
@sonney2kiglesiasg, when wiking or me do make release11:58
@iglesiasgsonney2k, I see11:59
@iglesiasgsonney2k, maybe it is better to get the md files from the urls as I did then?11:59
@iglesiasgsonney2k, this is regaring the second comment in https://github.com/shogun-toolbox/shogun-web/pull/3912:00
@sonney2kiglesiasg, I think it is better to assume a shogun install somewhere12:04
@iglesiasgsonney2k, but then the md files in the website won't be the same ones as in the repo, right?12:05
@iglesiasgthey won't be synced until the make release is done again12:05
@iglesiasgI understand that make release is done once in a blue moon or so12:05
@sonney2kiglesiasg, ahh indeed12:06
@sonney2kso we should point it to the buildbot's shogun checkout then and run it at nightly_default12:06
@iglesiasgI am not sure12:07
shogun-notifier-shogun: Soeren Sonnenburg :develop * ba0a597 / src/interfaces/modular/SGBase.i: https://github.com/shogun-toolbox/shogun/commit/ba0a597a2b32dd3456403bc8c705aa83e47f2dae12:08
shogun-notifier-shogun: make ref/unref known *before* including the class12:08
@sonney2kiglesiasg, how would you determine which *.md files exist?12:08
@sonney2kif you have the source code dir I could e.g. call your update function with all the .md file names12:08
@iglesiasgsonney2k, can we do a sort of os.walk in github.com/shogun-toolbox/shogun/develop/?12:09
@iglesiasgdoes that even make sense? :D12:09
@sonney2kiglesiasg, heh hardly - lets better do that on the local buildbot :D12:10
@iglesiasgaham! maybe GitHub API has some method to do that12:10
@iglesiasgI think that is very likely12:10
@iglesiasgsomething to get all the files in the repo with some extension12:10
@iglesiasglet me check that12:10
@sonney2kiglesiasg, I mean we coudl do update_md.py `find /path/to/shogun -name '*.md'`12:10
@sonney2kand done12:10
@sonney2kno need for magic12:10
@sonney2kshogun-buildbot_, force build --branch=develop 'deb3 - modular_interfaces'12:11
shogun-buildbot_build forced [ETA 47m10s]12:11
shogun-buildbot_I'll give a shout when the build finishes12:11
@sonney2kman please don't fail me12:11
@iglesiasgsonney2k, mm I don't follow the update_md.py `find /path/to/shogun -name '*.md'` idea12:12
-!- zxtx [~zv@ool-2f110054.dyn.optonline.net] has quit [Ping timeout: 252 seconds]12:43
-!- travis-ci [~travis-ci@ec2-54-242-242-147.compute-1.amazonaws.com] has joined #shogun12:47
travis-ci[travis-ci] it's Soeren Sonnenburg's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/1476126412:47
-!- travis-ci [~travis-ci@ec2-54-242-242-147.compute-1.amazonaws.com] has left #shogun []12:47
-!- zxtx [~zv@ool-2f110054.dyn.optonline.net] has joined #shogun12:48
shogun-buildbot_build #2066 of deb3 - modular_interfaces is complete: Failure [failed test csharp modular]  Build details are at http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/206612:50
-!- besser82 [~besser82@2a02:8108:8840:1800:e8b:fdff:fe16:bb33] has joined #shogun12:58
-!- besser82 [~besser82@2a02:8108:8840:1800:e8b:fdff:fe16:bb33] has quit [Changing host]12:58
-!- besser82 [~besser82@fedora/besser82] has joined #shogun12:58
besser82sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: Hey Folks!!!12:59
@iglesiasgHi besser82 !12:59
besser82sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: During refactoring that cmake-stuff and doing some basic sanity-checks i found some _really_ problematic issue:  When we bundle stuff like Eigen3, ColPack, ARPREC,...  there's problems when building some cxx-code interfacing libshogun  :(13:01
besser82sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: like missing headers for that bundled stuff....13:02
besser82sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: how do we want to solve that?13:02
besser82sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: two proposals from me:13:02
besser82sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: a) installing the headers from `bundled stuff` inside some private location, like %{_includedir}/shogun/...13:04
besser82sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: b) remove that bundling crap and requires these stuff to be present when building libshogun13:04
besser82sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: Other thoughts / ideas / proposals ??? Or shall we vote amoung these two possibilities?13:05
lisitsynI admit I don't really understand the issue13:06
besser82lisitsyn: What is unclear to you?  Please be more verbose and I'll try to explain...13:07
lisitsynbesser82: why these headers are missing?13:07
besser82lisitsyn: because from the bundled stuff there is static-libs build and linked into libshogun...13:10
besser82lisitsyn: there are headers which get referenced by shogun's headers, but actually are not installed and are only present somewhere in build-tree underneath `third_party/...`13:11
lisitsynbesser82: ah get it13:11
lisitsynbesser82: so the reason is that we have some 3rd party headers used in our headers right?13:12
besser82lisitsyn: right, and those 3rd-party headers are not present, when libshogun is build with bundling...13:13
besser82lisitsyn: if i build with linking against system's stuff this ain't an issue13:14
besser82lisitsyn: by not present i refer to not present for system outside shogun's build-tree....13:15
shogun-buildbot_build #2067 of deb3 - modular_interfaces is complete: Failure [failed test csharp modular]  Build details are at http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/2067  blamelist: Soeren Sonnenburg <sonne@debian.org>13:17
shogun-buildbot_build #328 of precise - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.org/builders/precise%20-%20libshogun/builds/328  blamelist: Soeren Sonnenburg <sonne@debian.org>13:17
besser82lisitsyn: shogun itself will build without problems, but when it comes to interfacing shogun-with-bundled-libs from own C++-code there are situations when `pop goes the weasel`  :(13:17
besser82sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: ^^^  a good example to reproduce is interfacing shogun's eigen-based stuff from C++13:20
@iglesiasgbesser82, uhm I see, I don't understand though why it happens13:22
@iglesiasgI understand that it won't  be possible to use Eigen stuff directly, but why not Shogun stuff that employs Eigen?13:23
@iglesiasgbesser82, we are talking about compile-time errors btw, right?13:24
besser82iglesiasg: yes compile-time errors, when interfacing libshogun from c++13:27
besser82iglesiasg: as i said this doesn't happen always and in every header, but in some there is....13:28
@iglesiasgbesser82, can it be due to something done wrong bundling?13:29
besser82iglesiasg: actually, no...13:37
besser82iglesiasg: it happenes with current develop/HEAD as well...13:38
besser82iglesiasg: and all my tracing leads to the problem of missing headers from bundled 3rd party-stuff...13:38
@iglesiasgbesser82, I meant in bundling Eigen13:41
besser82iglesiasg: How do you mean that in detail?13:41
besser82iglesiasg: try sth like creating an instance of `IterativeSolverIterator` inside some external code...13:44
@iglesiasgbesser82, when bundle_eigen is ON13:45
@iglesiasgsomething must be done in the cmake13:45
@iglesiasgI am wondering whether there could be something wrong done there causing the error you have found13:45
besser82iglesiasg: the error is either caused by bundling eigen3 or by not installing eigen3-headers when it get's bundled....13:46
besser82iglesiasg: that is just _ONE_ example of problems13:47
besser82iglesiasg: there are acutally more, but those I'm currently tracing down and will report on them later...13:48
besser82iglesiasg: I actually expect a whole lot more...13:48
besser82sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: ^^^ /  Another solution would be to split up shogun's headers like public-interface  /  internal(build-time)-interface...13:51
besser82sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: if that applies somehow...13:51
@wikingbesser82: bundling stays13:52
@wikingbesser82: and no install within shogun13:52
besser82wiking: ?!?13:52
@wikingbesser82: well then we need to start with the d-ptrs13:52
lisitsynbesser82: I see one problem with that 2) thing13:52
lisitsynif we make assumption headers are in system13:52
lisitsynwe may find a lot of troubles this way13:53
lisitsyne.g. shogun compiled with eigen 3.1.213:53
lisitsynand used with eigen 3.1.513:53
lisitsynor whatever13:53
besser82lisitsyn: that stuff to resolve with cmake's configure-stage....13:53
besser82lisitsyn: like `FindPackage(eigen3 3.2 REQUIRED)13:54
@wikingbesser82: but what if u r in the meanwhile (after installing shogun) intall eigen 3.213:54
@wikingso you have on your system eigen 3.213:54
@wikingbut you've installed shogun with a bundled eigen13:54
besser82wiking: then code interfacing libshogun would build fine, but binary is broken  :(13:55
besser82wiking: if the system-ver && shogun-bundled-eigen-ver don't match...13:55
@wikingyep13:56
@wikingbesser82: hence we could go with d-ptrs where this can be hidden13:56
besser82wiking: but d-ptr doesn't cure everything i assume...13:56
besser82... brb ...  ---> lunch  ;)13:57
@wikingwell all these dependency problems can be cured13:57
@wikingas then we would not ever include stuff in our public headers13:57
@wikingthat is not directly part of shogun13:57
@wikingthis way even if we include eigen13:58
@wikingthat would be in some private class13:58
-!- iglesiasg [~iglesiasg@206.Red-83-61-168.dynamicIP.rima-tde.net] has quit [Ping timeout: 246 seconds]13:58
@wikingwhich never would be exposed to the public header13:58
@wikingso all those ifdef HAVE would be within the private classes13:58
-!- iglesiasg [~iglesiasg@206.Red-83-61-168.dynamicIP.rima-tde.net] has joined #shogun14:01
-!- mode/#shogun [+o iglesiasg] by ChanServ14:01
besser82wiking: sounds good  ;)14:22
besser82wiking: but what to do until?!?14:23
besser82sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: I'd propose to install all needed, bundled headers into  `%{_includedir}/shogun/third_party`, then.  That's an easy job with cmake and all needed include-dirs can be populated by shogun.pc / ShogunConfig.cmake, when interfacing libshogun from other C++.14:40
besser82sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: That would make building the lang-interfaces from existing libshogun even quicker && easier14:41
besser82sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: Any objections?14:42
besser82sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: That stuff can be easily removed / disabled when having those d-ptr-stuff implemented...14:44
@wikingbesser82: nothing...14:45
besser82wiking: nothing, what???? *puzzled*  No objections?14:45
@wikingthird_party and then we'll see if we ever get to the point of having dptrs14:50
-!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 252 seconds]14:53
-!- besser82 [~besser82@77-20-95-52-dynip.superkabel.de] has joined #shogun14:53
-!- besser82 [~besser82@77-20-95-52-dynip.superkabel.de] has quit [Changing host]14:53
-!- besser82 [~besser82@fedora/besser82] has joined #shogun14:53
besser82wiking: Allrighty, then  ;)  I can dooooooooooooo it  :D14:56
besser82wiking: that d-ptr stuff...  If I'm done witth this cmake && SVM^bright, I can start implementing d-ptr to shogun  ;)14:57
@wikingbesser82: well that's going to be a common effort15:02
@wikingi.e. feature branch15:02
@wikingwith a lot of discussion in the meanwhile15:02
@wikingthat cannot be done by 1 person15:02
@wikingnot because of some resource limitation15:02
@wikingmore because it has to be agreed by everybody15:03
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout]15:08
besser82wiking: allrighty  ;)  It was just an offer  ;)15:11
-!- iglesiasg [~iglesiasg@206.Red-83-61-168.dynamicIP.rima-tde.net] has quit [Quit: Leaving]15:13
-!- new_lido [~walid@105.200.193.157] has joined #shogun15:34
-!- new_lido [~walid@105.200.193.157] has quit [Ping timeout: 245 seconds]15:48
-!- lisitsyn [~lisitsyn@188-122-234-71.clients.tlt.100megabit.ru] has quit [Quit: Leaving.]16:20
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun16:47
shogun-notifier-shogun: Soeren Sonnenburg :feature/CMakeImproved * e47602f / src/interfaces/modular/SGBase.i: https://github.com/shogun-toolbox/shogun/commit/e47602f2e9ac3e65f7c5797cf9efe8977e1354e216:47
shogun-notifier-shogun: change order of includes to fix compile error16:47
shogun-notifier-shogun: Soeren Sonnenburg :feature/CMakeImproved * 5844f48 / / (14 files): https://github.com/shogun-toolbox/shogun/commit/5844f480a1b588e5fccfef90d1df096579467d1916:47
shogun-notifier-shogun: don't include SGStringList in SGObject.h16:47
shogun-notifier-shogun: Soeren Sonnenburg :feature/CMakeImproved * 9a6ce87 / src/interfaces/modular/SGBase.i: https://github.com/shogun-toolbox/shogun/commit/9a6ce877edacdf9a29d683f3011914e62508b93c16:47
shogun-notifier-shogun: include SGRefObject before SGObject for swig16:47
shogun-notifier-shogun: Soeren Sonnenburg :feature/CMakeImproved * a93cb3b / src/ (5 files): https://github.com/shogun-toolbox/shogun/commit/a93cb3b9136f8072472067ac57828992bf6d8d7716:47
shogun-notifier-shogun: drop SERIALIZABLE_DUMMY16:47
shogun-notifier-shogun: Soeren Sonnenburg :feature/CMakeImproved * ed592ee / src/interfaces/modular/SGBase.i: https://github.com/shogun-toolbox/shogun/commit/ed592ee8942ecaf9e5bb9e8844a3953924ca8af716:47
shogun-notifier-shogun: add namespace to get Externalizable to work for real16:47
shogun-notifier-shogun: Soeren Sonnenburg :feature/CMakeImproved * ba0a597 / src/interfaces/modular/SGBase.i: https://github.com/shogun-toolbox/shogun/commit/ba0a597a2b32dd3456403bc8c705aa83e47f2dae16:47
shogun-notifier-shogun: make ref/unref known *before* including the class16:47
-!- travis-ci [~travis-ci@ec2-54-226-95-169.compute-1.amazonaws.com] has joined #shogun17:32
travis-ci[travis-ci] it's Soeren Sonnenburg's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/1476817917:32
-!- travis-ci [~travis-ci@ec2-54-226-95-169.compute-1.amazonaws.com] has left #shogun []17:32
@sonney2kbesser82, I will be around later in the evening...18:25
@sonney2kwhy oh why is csharp failing now18:27
@sonney2kbesser82, I actually don't see the issue you see - shogun doesn't include any external libs from its headers18:57
besser82sonney2k: actually it does ---> shogun/mathematics/linalg/linsolver/IterativeSolverIterator.h18:59
besser82sonney2k: one example18:59
@sonney2kbesser82, then this needs to be fixed in this example18:59
besser82sonney2k: then you will need to do some predeclaration for eigen3  :(19:00
besser82sonney2k: there actually a lot more stuff like this for ColPack, ARPREC, etc...19:00
@sonney2kbesser82, where?19:01
@sonney2kall bugs19:01
@sonney2kI am pretty sure we don't need lapack / atlas pthreads etc19:01
besser82sonney2k: are you sure those are bugs???19:02
@sonney2kyes19:03
besser82e.g. in that named header there is stuff used being declared in eigen3-headers19:03
@sonney2kbesser82, you cannot require people to having installed all the deps developer files shogun has as build deps19:03
besser82i don't19:03
@sonney2kbesser82, so yes all bugs19:04
besser82sonney2k: but how should we solve?19:04
@sonney2kbesser82, where do we have to solve it19:04
@sonney2kwe just don't use external libs in .h's19:04
besser82sonney2k: lemme probe all headers for stuff like that19:04
besser82sonney2k: me and wiking agree to have those headers installed along shogun in a %{includedir}/shogun/third_party/19:05
@sonney2kand of course d-ptr's solve it for all cases and we want to do them anyway19:05
@sonney2kbesser82, not needed19:05
besser82sonney2k: as a quick thing until we have d-ptr implemented?!?19:06
besser82sonney2k: since we are going to have them, we can solve this temporary like that19:06
@sonney2kbesser82, well no it works except for one example right?19:06
besser82sonney2k: include/shogun/mathematics/linalg/ratapprox/tracesampler/ProbingSampler.h19:07
besser82include/shogun/mathematics/JacobiEllipticFunctions.h19:07
besser82sonney2k: are the next ones19:07
besser82sonney2k: include/shogun/mathematics/lapack.h19:07
besser82sonney2k: more to come....19:07
besser82sonney2k: that's not just fixing up 1 or 2 headers....  :(19:08
besser82sonney2k: btw. we have another issue, but that's another case....19:08
besser82sonney2k: multi-lib incompatibility with shogun/lib/config.h and others19:08
besser82sonney2k: like one cannot install iX86 and amd64 within the same OS19:09
besser82sonney2k: and other arches, too, i suppose19:09
besser82sonney2k: but that's only stuff we have to deal with as pkg-maintainers in debian / FC / RHEL19:10
besser82sonney2k: but we would need to get that multilib stuff addressed, too...19:11
besser82sonney2k:????19:17
besser82sonney2k: I so far found ~150 headers including stuff which is _not_ stdlib nor common build-essential...19:18
besser82sonney2k: depending on shogun's build-config that would be: hdf5, eigen3, libxml, json, atlas / clapack / lapack, arprec, locales, colpack19:21
besser82sonney2k: and possibly some more requirements19:22
-!- some_student [~some_stud@pool-72-70-88-143.nycmny.east.verizon.net] has joined #shogun19:40
some_studentHey everybody, I'm having trouble compiling shogun 3.0.0 on Max OS X 10.9, when running 'make' I get an 'expression not assignable error' for the file shogun/io/SerializableAsciiReader00.cpp:95-96:34. Any thoughts?19:45
some_studentOnly installing the python modular package as well19:46
-!- iglesiasg [~iglesiasg@206.Red-83-61-168.dynamicIP.rima-tde.net] has joined #shogun19:47
-!- mode/#shogun [+o iglesiasg] by ChanServ19:47
besser82some_student: Hi!  Unfortunately I cannot help with that, because I don't own a mac.  But sonney2k has one i think...19:47
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout]19:47
some_studentAppreciate the timely response! Thanks for the tip19:48
@iglesiasgwiking may be able to help as well19:49
@wikingsome_student: yeah that has been fixed in the develop branch of shogun19:52
@wikingsome_student: basically clang 3.3 has some funky things going on because of switching to libc++ from libstdc++19:53
some_studentoo okay, so if I just grab the dev branch and build it should be good?19:55
@wikingindeed19:55
@wikingthat person that uses maven to build an ant project should be hanged19:56
some_studentAwesome! Thanks so much for the quick respsonse! Where is your dev branch located by the way?19:57
@wikingsome_student: git clone https://github.com/shogun-toolbox/shogun.git19:58
@wikingsome_student: should work as 10.9 has by default git installed :P19:58
some_studenthaha 10.9 is a godsend with default installations this time around. Thanks for the link19:59
@wikingnw19:59
@sonney2kbesser82, sorry had to sing like 100 x-mas carols until the kids were ok with me leaving20:11
@sonney2kbesser82, with the external stuff I would rather want to do the d-ptr business (or you start doing some first iteration - it is a loong process anyway)20:12
-!- some_student [~some_stud@pool-72-70-88-143.nycmny.east.verizon.net] has quit [Quit: irc2go]20:12
@sonney2kbesser82, what I meant was that you don't need third party libs installed but only headers - quite the opposite of what I said above20:12
@sonney2kbut still we should really get rid of all third party deps when you link against libshogun / compile w/ shogun headers20:13
@sonney2kbesser82, anyways it would be nice if we could get your cmake stuff merged rather soonish20:14
@sonney2kI would want to do some more cleanups in the modular/*.i dir20:15
@sonney2kand yay all the c# examples work on my machine20:22
@sonney2kwiking, any clues how to run the csharp examples on fatbot?20:35
@sonney2kwiking, if I just do ctest --output-on-failure -j2 -R csharp20:35
@sonney2kwiking, it says No tests were found!!!20:36
@sonney2kahh wrong dir20:37
@sonney2kbuild/buil20:37
-!- some_student [~some_stud@pool-72-70-88-143.nycmny.east.verizon.net] has joined #shogun20:43
some_studentHey everybody, I just download your developer branch on github trying to install 3.0.0 for Mac OS X 10.9, python modular interface. When I "import modshogun", I get a segfault. I think its because during compilation ranlib sent me the error: 'file: libshogun.a(SomeShogunFileName.cpp.o) has no symbols' for a bunch of files.. Any thoughts?20:47
besser82sonney2k: :D  Christmas with them kids  ;)20:48
besser82sonney2k: `Advent` actually  ;)20:48
besser82sonney2k: CMake stuff is nearly finished, first PR to come during tomorrow  ;)20:48
besser82sonney2k: btw. you aren't blocked cleaning that modular*/*.i  stuff  ;)20:49
@wikingsome_student: no it's not because of that... make sure that u r compiling the python modular iface with the right python lib/headers. this happened to me when i had system's python 2.7 but i was trying to use the generated modshogun from macport's python20:49
besser82sonney2k: I know how to rebase my branch upon develop  ;)20:50
@sonney2ksome_student, wiking I had that very same issue too - be extra cautious which python version is used and adjust PYTHON_PATH accordingly20:52
@sonney2ksome_student, pretty annoying ....20:53
@sonney2kbesser82, well did you do any cleanups in the .i files?20:53
@sonney2kbesser82, I mean I don't know exactly how ccache for swig works20:54
@sonney2kbesser82, but maybe it is possible to speed things up a bit20:54
@sonney2kshogun-buildbot_, force build --branch=develop 'deb3 - modular_interfaces'20:54
shogun-buildbot_build forced [ETA 47m10s]20:54
shogun-buildbot_I'll give a shout when the build finishes20:54
besser82sonney2k: actually if ccache is properly configure it will be used by swig as well20:59
besser82sonney2k: yes, i did some mods to those *.i, but nothing really large20:59
besser82sonney2k: actually moving defines to SHOGUN_-scope, e.g. USE_FEATURE ---> SHOGUN_USE_FEATURE21:00
besser82sonney2k: and making sure config.h is picked up properly21:00
@sonney2kbesser82, we have a couple of defines in there that are JAVA/ etc specific21:02
besser82sonney2k: i know, seen them21:02
@sonney2kbesser82, so some objects get functions attached21:02
@sonney2kfor python / java etc21:02
besser82sonney2k: right21:02
besser82sonney2k: afaik there is some ifdef / ifndef around inlined code and such21:03
besser82sonney2k: so what's the punch-line?21:04
@sonney2kbesser82, I think ccache won't work due to these lang specific defines at all21:05
besser82sonney2k: it does  ;)21:05
@sonney2kmaybe we should have one different modshogun.i or / SGBase.i per language21:05
besser82sonney2k: not really21:06
@sonney2kbesser82, then caching would work - I mean if we change one .i file21:06
besser82sonney2k: tht's correct, but i already took care of that ;)21:06
@sonney2kbesser82, lets get your thing merged first and then discuss again after I did some experiments with it :)21:07
besser82sonney2k: actually some of those .i-files are autogenerated by cmake now21:07
besser82sonney2k: and testsuite passes so far21:08
besser82sonney2k: by the .i-files are not that much relevant, the way the modules are build actually21:09
besser82sonney2k: there could be much more speed gain when we would SWIG && CC every .i-file seperately, and get the object linked together...21:10
besser82sonney2k: but so far, like wiking said, modules are just crashing with such a setup21:10
besser82sonney2k: that would be subject to more and deeper investigation....21:11
besser82sonney2k: but I can dooooooooo it  ;)  after merge21:11
besser82sonney2k: recently there is a _real_ speedup when re-compiling from ccaches even for the modules  ;)21:12
besser82sonney2k: the whole stack now rebuilds within a minute, if there were no changes....21:13
besser82sonney2k: changes actually slow down the rebuild a bit, but not as far as build time are now21:14
besser82sonney2k: depending on the impact of the actual change there is rebuild-times of ~3 - 5 minutes when ccaches are present21:15
some_studentwiking, sonney2k: By PYTHON_PATH, im assuming you guys mean a bash variable.. I pointed it to correct python installation, to no avail.. cmake is telling me it found SWIG, pythonLibs, pythonInterp, and NumPy. How can I see where shogun is looking for python? or am I just doing it wrong?21:16
@sonney2kbesser82, ok so lets see then :)21:16
shogun-buildbot_build #2068 of deb3 - modular_interfaces is complete: Failure [failed test csharp modular]  Build details are at http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/206821:17
besser82sonney2k: allrighty  ;)21:17
besser82some_student: try -DPYTHON_INCLUDE_PATH=%{path to your python headers} on the cmake commandline21:19
besser82some_student: %{path to your python headers} should point to the include-dir of the python-install you want to use python-shogun with21:20
besser82some_student: I hope that will help you  ;)21:21
some_studentbesser82: Looks promising, trying now! Figured I was missing something! thank you all :)21:23
besser82some_student: you're welcome  :D  If it won't work, check back to see if we can resolve that issue  ;)21:24
-!- sonne|osx [~sonne@f053038072.adsl.alicedsl.de] has joined #shogun21:26
-!- sonne|osx [~sonne@f053038072.adsl.alicedsl.de] has quit [Quit: sonne|osx]21:37
some_studentbesser82: So I followed your advice, and pointed it to my local python install, header directory.. but then when compiling it couldnt find Python.h, even though Python.h is definitely in the directory I pointed it in.. any thoughts?21:45
besser82some_student: mhhhh.... sounds odd...21:46
some_studentI know.. I keep ls'ing the directory as a sanity check and its definitely there21:47
besser82some_student: are both python version the same or different?21:47
some_studentboth are the same to my knowledge21:49
besser82some_student: try`-DPYTHON_LIBRARY=%{path to libpython.so}` and `-DPYTHON_INCLUDE_DIR=%{path to dir having the Python.h belonging to that lib}`, perhaps that might help...21:50
besser82some_student:  if pathes do have whitespaces try to wrap them into ""21:51
some_studentno whitespaces, and I'm running everything from the top, and I just realized that some relevant packages are outdated so I'm updating those. Will try the python lib as well tho!21:53
besser82Good n8, folks!  :D22:20
-!- besser82 [~besser82@fedora/besser82] has quit [Quit: freedom, friends, features, first ---> fedoraproject.org]22:20
some_studentbesser82: you are my hero. It was the python_library arguement that needed to be tweaked. I wish you didn't just leave so I could let you know how awesome you are! Seriously. thank you so much22:25
-!- some_student [~some_stud@pool-72-70-88-143.nycmny.east.verizon.net] has quit [Quit: irc2go]22:25
@iglesiasgtime to bed, good night people23:14
-!- iglesiasg [~iglesiasg@206.Red-83-61-168.dynamicIP.rima-tde.net] has quit [Quit: Leaving]23:14
-!- Boeke [~alex@24-179-114-25.dhcp.oxfr.ma.charter.com] has joined #shogun23:38
BoekeHi does anyone have an idea why HDF5File fails to open a hdf5 file that h5py can open23:39
BoekeSpecifically it gives the error "SystemError: [ERROR] In file /home/alex/shogun-3.0.0/src/shogun/io/HDF5File.cpp line 61: Could not open file '/home/alex/features1.h5'"23:41
Boekenever mind sorry23:52
--- Log closed Mon Dec 02 00:00:49 2013