| --- 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/634 | 04:05 |
|---|---|---|
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 06:45 | |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * 9a6ce87 / src/interfaces/modular/SGBase.i: https://github.com/shogun-toolbox/shogun/commit/9a6ce877edacdf9a29d683f3011914e62508b93c | 06:45 |
| shogun-notifier- | shogun: include SGRefObject before SGObject for swig | 06:45 |
| -!- travis-ci [~travis-ci@ec2-54-237-116-165.compute-1.amazonaws.com] has joined #shogun | 07: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/14756218 | 07: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 #shogun | 08:58 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 08:58 | |
| @iglesiasg | good morning guys | 08: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 #shogun | 09:11 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 09:11 | |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * a93cb3b / src/ (5 files): https://github.com/shogun-toolbox/shogun/commit/a93cb3b9136f8072472067ac57828992bf6d8d77 | 09:27 |
| shogun-notifier- | shogun: drop SERIALIZABLE_DUMMY | 09:27 |
| @sonney2k | iglesiasg, moin! | 09:27 |
| @iglesiasg | sonney2k, you were right with your first comment here https://github.com/shogun-toolbox/shogun-web/pull/39 | 09:55 |
| @iglesiasg | sonney2k, it seems that the html files have to be inside the templates directory | 09:55 |
| @sonney2k | iglesiasg, could be worse .. so maybe you just create some extra dir inside the template dir? | 09:56 |
| @iglesiasg | sonney2k, yep | 09:56 |
| @iglesiasg | sonney2k, instead of static/md2html, we use templates/md2html and done | 09:57 |
| @sonney2k | ok | 10:04 |
| @sonney2k | lisitsyn, F%$*$Y%(*! | 10:05 |
| @sonney2k | lisitsyn, how did you ever get the %typemap(javainterfaces) to do *anything* | 10:05 |
| lisitsyn | sonney2k: why? | 10:05 |
| @sonney2k | I dont' see in any class any java.io.Externalizable | 10:05 |
| lisitsyn | sonney2k: what do you mean? | 10:06 |
| lisitsyn | #ifdef SWIGJAVA%typemap(javainterfaces) SGObject "java.io.Externalizable" | 10:07 |
| @sonney2k | lisitsyn, yes I am not seeing any implements Externalizable or so | 10:07 |
| lisitsyn | sonney2k: public void writeExternal(java.io.ObjectOutput out) throws java.io.IOException { | 10:08 |
| lisitsyn | ?? :) | 10:08 |
| @sonney2k | lisitsyn, there also is no writeExternal or anything | 10:10 |
| @sonney2k | I guess I killed it all now | 10:10 |
| @sonney2k | lisitsyn, you wrote that stuff so help me! | 10:10 |
| @sonney2k | http://stackoverflow.com/questions/5477747/cant-figure-out-how-to-make-swig-java-force-a-proxy-class-to-implement-an-inter | 10:10 |
| lisitsyn | sonney2k: what's going on? :D | 10:11 |
| @sonney2k | and here the guy does just | 10:11 |
| @sonney2k | %typemap(javainterfaces) Foo "SomeInterface" | 10:11 |
| @sonney2k | struct Foo { | 10:11 |
| @sonney2k | }; | 10:11 |
| @sonney2k | and it is then adding a public class Foo extends SomeBase implements SomeInterface { | 10:11 |
| lisitsyn | yeah | 10:11 |
| lisitsyn | and what? | 10:11 |
| @sonney2k | so why in 3$#$ hell does it now work with CSGObject now | 10:11 |
| lisitsyn | *not* work? | 10:12 |
| @sonney2k | %typemap(javaimports) CSGObject | 10:12 |
| @sonney2k | %{ | 10:12 |
| @sonney2k | import org.shogun.SerializableFile; | 10:12 |
| @sonney2k | import org.shogun.SerializableAsciiFile; | 10:12 |
| @sonney2k | %} | 10:12 |
| @sonney2k | I don't see in any .java file these imports | 10:12 |
| @sonney2k | lisitsyn, *not* == no implements! | 10:12 |
| lisitsyn | uhm | 10:13 |
| -!- travis-ci [~travis-ci@ec2-54-226-95-169.compute-1.amazonaws.com] has joined #shogun | 10: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/14758523 | 10:14 |
| -!- travis-ci [~travis-ci@ec2-54-226-95-169.compute-1.amazonaws.com] has left #shogun [] | 10:14 | |
| @sonney2k | ahh | 10:14 |
| @sonney2k | lisitsyn, namespaces! | 10:14 |
| lisitsyn | hahaha | 10:14 |
| @sonney2k | maybe shogun::CSGObject | 10:14 |
| * sonney2k tries | 10:14 | |
| lisitsyn | ah so now I get it | 10:14 |
| lisitsyn | it was SWIGCLASS | 10:14 |
| lisitsyn | yeah it must be namespace | 10:14 |
| lisitsyn | we have stupid java externalization btw without buffering and file based | 10:15 |
| @sonney2k | lisitsyn, better stupid than none | 10:15 |
| @sonney2k | I hope besser82 finishes his cmake stuff | 10:15 |
| @sonney2k | I would want to give the swig stuff an overhaul | 10:15 |
| @iglesiasg | sonney2k, django template question | 10:16 |
| @sonney2k | so that we have java stuff only in certain files | 10:16 |
| @sonney2k | and not the mess we have now in SGBase / modshogun.i | 10:16 |
| @sonney2k | lisitsyn, yes works :D | 10:17 |
| @sonney2k | public class SGObject extends SGRefObject implements java.io.Externalizable { | 10:17 |
| @sonney2k | lisitsyn, I think I fixed things now for real | 10:17 |
| @iglesiasg | sonney2k, 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 breaks | 10:17 |
| @sonney2k | lisitsyn, do you know why we always have a import java.io.Serializable; in there? | 10:18 |
| @sonney2k | iglesiasg, 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/ed592ee8942ecaf9e5bb9e8844a3953924ca8af7 | 10:20 |
| shogun-notifier- | shogun: add namespace to get Externalizable to work for real | 10:20 |
| @iglesiasg | sonney2k, ahhh I am such an idiot | 10:21 |
| lisitsyn | sonney2k: where do we have it? | 10:21 |
| @iglesiasg | I just needed to remove the {{ }} and it works | 10:21 |
| @sonney2k | iglesiasg, :) | 10:24 |
| @sonney2k | lisitsyn, what? | 10:24 |
| @sonney2k | lisitsyn, for each object we want this serialization right | 10:24 |
| @sonney2k | lisitsyn, 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 #shogun | 11: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/14759141 | 11:03 |
| -!- travis-ci [~travis-ci@ec2-54-242-242-147.compute-1.amazonaws.com] has left #shogun [] | 11:03 | |
| lisitsyn | sonney2k: hmm no | 11:16 |
| lisitsyn | I don't remember that | 11:16 |
| @iglesiasg | sonney2k, when is the shogun repo updated in the machine that contains shogun-web? | 11:25 |
| -!- zxtx [~zv@ool-2f110054.dyn.optonline.net] has joined #shogun | 11: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 |
| @sonney2k | iglesiasg, when wiking or me do make release | 11:58 |
| @iglesiasg | sonney2k, I see | 11:59 |
| @iglesiasg | sonney2k, maybe it is better to get the md files from the urls as I did then? | 11:59 |
| @iglesiasg | sonney2k, this is regaring the second comment in https://github.com/shogun-toolbox/shogun-web/pull/39 | 12:00 |
| @sonney2k | iglesiasg, I think it is better to assume a shogun install somewhere | 12:04 |
| @iglesiasg | sonney2k, but then the md files in the website won't be the same ones as in the repo, right? | 12:05 |
| @iglesiasg | they won't be synced until the make release is done again | 12:05 |
| @iglesiasg | I understand that make release is done once in a blue moon or so | 12:05 |
| @sonney2k | iglesiasg, ahh indeed | 12:06 |
| @sonney2k | so we should point it to the buildbot's shogun checkout then and run it at nightly_default | 12:06 |
| @iglesiasg | I am not sure | 12:07 |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * ba0a597 / src/interfaces/modular/SGBase.i: https://github.com/shogun-toolbox/shogun/commit/ba0a597a2b32dd3456403bc8c705aa83e47f2dae | 12:08 |
| shogun-notifier- | shogun: make ref/unref known *before* including the class | 12:08 |
| @sonney2k | iglesiasg, how would you determine which *.md files exist? | 12:08 |
| @sonney2k | if you have the source code dir I could e.g. call your update function with all the .md file names | 12:08 |
| @iglesiasg | sonney2k, can we do a sort of os.walk in github.com/shogun-toolbox/shogun/develop/? | 12:09 |
| @iglesiasg | does that even make sense? :D | 12:09 |
| @sonney2k | iglesiasg, heh hardly - lets better do that on the local buildbot :D | 12:10 |
| @iglesiasg | aham! maybe GitHub API has some method to do that | 12:10 |
| @iglesiasg | I think that is very likely | 12:10 |
| @iglesiasg | something to get all the files in the repo with some extension | 12:10 |
| @iglesiasg | let me check that | 12:10 |
| @sonney2k | iglesiasg, I mean we coudl do update_md.py `find /path/to/shogun -name '*.md'` | 12:10 |
| @sonney2k | and done | 12:10 |
| @sonney2k | no need for magic | 12:10 |
| @sonney2k | shogun-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 finishes | 12:11 |
| @sonney2k | man please don't fail me | 12:11 |
| @iglesiasg | sonney2k, mm I don't follow the update_md.py `find /path/to/shogun -name '*.md'` idea | 12: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 #shogun | 12: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/14761264 | 12: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 #shogun | 12: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/2066 | 12:50 |
| -!- besser82 [~besser82@2a02:8108:8840:1800:e8b:fdff:fe16:bb33] has joined #shogun | 12:58 | |
| -!- besser82 [~besser82@2a02:8108:8840:1800:e8b:fdff:fe16:bb33] has quit [Changing host] | 12:58 | |
| -!- besser82 [~besser82@fedora/besser82] has joined #shogun | 12:58 | |
| besser82 | sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: Hey Folks!!! | 12:59 |
| @iglesiasg | Hi besser82 ! | 12:59 |
| besser82 | sonney2k, 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 |
| besser82 | sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: like missing headers for that bundled stuff.... | 13:02 |
| besser82 | sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: how do we want to solve that? | 13:02 |
| besser82 | sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: two proposals from me: | 13:02 |
| besser82 | sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: a) installing the headers from `bundled stuff` inside some private location, like %{_includedir}/shogun/... | 13:04 |
| besser82 | sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: b) remove that bundling crap and requires these stuff to be present when building libshogun | 13:04 |
| besser82 | sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: Other thoughts / ideas / proposals ??? Or shall we vote amoung these two possibilities? | 13:05 |
| lisitsyn | I admit I don't really understand the issue | 13:06 |
| besser82 | lisitsyn: What is unclear to you? Please be more verbose and I'll try to explain... | 13:07 |
| lisitsyn | besser82: why these headers are missing? | 13:07 |
| besser82 | lisitsyn: because from the bundled stuff there is static-libs build and linked into libshogun... | 13:10 |
| besser82 | lisitsyn: 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 |
| lisitsyn | besser82: ah get it | 13:11 |
| lisitsyn | besser82: so the reason is that we have some 3rd party headers used in our headers right? | 13:12 |
| besser82 | lisitsyn: right, and those 3rd-party headers are not present, when libshogun is build with bundling... | 13:13 |
| besser82 | lisitsyn: if i build with linking against system's stuff this ain't an issue | 13:14 |
| besser82 | lisitsyn: 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 |
| besser82 | lisitsyn: 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 |
| besser82 | sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: ^^^ a good example to reproduce is interfacing shogun's eigen-based stuff from C++ | 13:20 |
| @iglesiasg | besser82, uhm I see, I don't understand though why it happens | 13:22 |
| @iglesiasg | I understand that it won't be possible to use Eigen stuff directly, but why not Shogun stuff that employs Eigen? | 13:23 |
| @iglesiasg | besser82, we are talking about compile-time errors btw, right? | 13:24 |
| besser82 | iglesiasg: yes compile-time errors, when interfacing libshogun from c++ | 13:27 |
| besser82 | iglesiasg: as i said this doesn't happen always and in every header, but in some there is.... | 13:28 |
| @iglesiasg | besser82, can it be due to something done wrong bundling? | 13:29 |
| besser82 | iglesiasg: actually, no... | 13:37 |
| besser82 | iglesiasg: it happenes with current develop/HEAD as well... | 13:38 |
| besser82 | iglesiasg: and all my tracing leads to the problem of missing headers from bundled 3rd party-stuff... | 13:38 |
| @iglesiasg | besser82, I meant in bundling Eigen | 13:41 |
| besser82 | iglesiasg: How do you mean that in detail? | 13:41 |
| besser82 | iglesiasg: try sth like creating an instance of `IterativeSolverIterator` inside some external code... | 13:44 |
| @iglesiasg | besser82, when bundle_eigen is ON | 13:45 |
| @iglesiasg | something must be done in the cmake | 13:45 |
| @iglesiasg | I am wondering whether there could be something wrong done there causing the error you have found | 13:45 |
| besser82 | iglesiasg: the error is either caused by bundling eigen3 or by not installing eigen3-headers when it get's bundled.... | 13:46 |
| besser82 | iglesiasg: that is just _ONE_ example of problems | 13:47 |
| besser82 | iglesiasg: there are acutally more, but those I'm currently tracing down and will report on them later... | 13:48 |
| besser82 | iglesiasg: I actually expect a whole lot more... | 13:48 |
| besser82 | sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: ^^^ / Another solution would be to split up shogun's headers like public-interface / internal(build-time)-interface... | 13:51 |
| besser82 | sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: if that applies somehow... | 13:51 |
| @wiking | besser82: bundling stays | 13:52 |
| @wiking | besser82: and no install within shogun | 13:52 |
| besser82 | wiking: ?!? | 13:52 |
| @wiking | besser82: well then we need to start with the d-ptrs | 13:52 |
| lisitsyn | besser82: I see one problem with that 2) thing | 13:52 |
| lisitsyn | if we make assumption headers are in system | 13:52 |
| lisitsyn | we may find a lot of troubles this way | 13:53 |
| lisitsyn | e.g. shogun compiled with eigen 3.1.2 | 13:53 |
| lisitsyn | and used with eigen 3.1.5 | 13:53 |
| lisitsyn | or whatever | 13:53 |
| besser82 | lisitsyn: that stuff to resolve with cmake's configure-stage.... | 13:53 |
| besser82 | lisitsyn: like `FindPackage(eigen3 3.2 REQUIRED) | 13:54 |
| @wiking | besser82: but what if u r in the meanwhile (after installing shogun) intall eigen 3.2 | 13:54 |
| @wiking | so you have on your system eigen 3.2 | 13:54 |
| @wiking | but you've installed shogun with a bundled eigen | 13:54 |
| besser82 | wiking: then code interfacing libshogun would build fine, but binary is broken :( | 13:55 |
| besser82 | wiking: if the system-ver && shogun-bundled-eigen-ver don't match... | 13:55 |
| @wiking | yep | 13:56 |
| @wiking | besser82: hence we could go with d-ptrs where this can be hidden | 13:56 |
| besser82 | wiking: but d-ptr doesn't cure everything i assume... | 13:56 |
| besser82 | ... brb ... ---> lunch ;) | 13:57 |
| @wiking | well all these dependency problems can be cured | 13:57 |
| @wiking | as then we would not ever include stuff in our public headers | 13:57 |
| @wiking | that is not directly part of shogun | 13:57 |
| @wiking | this way even if we include eigen | 13:58 |
| @wiking | that would be in some private class | 13:58 |
| -!- iglesiasg [~iglesiasg@206.Red-83-61-168.dynamicIP.rima-tde.net] has quit [Ping timeout: 246 seconds] | 13:58 | |
| @wiking | which never would be exposed to the public header | 13:58 |
| @wiking | so all those ifdef HAVE would be within the private classes | 13:58 |
| -!- iglesiasg [~iglesiasg@206.Red-83-61-168.dynamicIP.rima-tde.net] has joined #shogun | 14:01 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 14:01 | |
| besser82 | wiking: sounds good ;) | 14:22 |
| besser82 | wiking: but what to do until?!? | 14:23 |
| besser82 | sonney2k, 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 |
| besser82 | sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: That would make building the lang-interfaces from existing libshogun even quicker && easier | 14:41 |
| besser82 | sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: Any objections? | 14:42 |
| besser82 | sonney2k, sonne|work, iglesiasg, lisitsyn, wiking: That stuff can be easily removed / disabled when having those d-ptr-stuff implemented... | 14:44 |
| @wiking | besser82: nothing... | 14:45 |
| besser82 | wiking: nothing, what???? *puzzled* No objections? | 14:45 |
| @wiking | third_party and then we'll see if we ever get to the point of having dptrs | 14:50 |
| -!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 252 seconds] | 14:53 | |
| -!- besser82 [~besser82@77-20-95-52-dynip.superkabel.de] has joined #shogun | 14:53 | |
| -!- besser82 [~besser82@77-20-95-52-dynip.superkabel.de] has quit [Changing host] | 14:53 | |
| -!- besser82 [~besser82@fedora/besser82] has joined #shogun | 14:53 | |
| besser82 | wiking: Allrighty, then ;) I can dooooooooooooo it :D | 14:56 |
| besser82 | wiking: that d-ptr stuff... If I'm done witth this cmake && SVM^bright, I can start implementing d-ptr to shogun ;) | 14:57 |
| @wiking | besser82: well that's going to be a common effort | 15:02 |
| @wiking | i.e. feature branch | 15:02 |
| @wiking | with a lot of discussion in the meanwhile | 15:02 |
| @wiking | that cannot be done by 1 person | 15:02 |
| @wiking | not because of some resource limitation | 15:02 |
| @wiking | more because it has to be agreed by everybody | 15:03 |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 15:08 | |
| besser82 | wiking: 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 #shogun | 15: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 #shogun | 16:47 | |
| shogun-notifier- | shogun: Soeren Sonnenburg :feature/CMakeImproved * e47602f / src/interfaces/modular/SGBase.i: https://github.com/shogun-toolbox/shogun/commit/e47602f2e9ac3e65f7c5797cf9efe8977e1354e2 | 16:47 |
| shogun-notifier- | shogun: change order of includes to fix compile error | 16:47 |
| shogun-notifier- | shogun: Soeren Sonnenburg :feature/CMakeImproved * 5844f48 / / (14 files): https://github.com/shogun-toolbox/shogun/commit/5844f480a1b588e5fccfef90d1df096579467d19 | 16:47 |
| shogun-notifier- | shogun: don't include SGStringList in SGObject.h | 16:47 |
| shogun-notifier- | shogun: Soeren Sonnenburg :feature/CMakeImproved * 9a6ce87 / src/interfaces/modular/SGBase.i: https://github.com/shogun-toolbox/shogun/commit/9a6ce877edacdf9a29d683f3011914e62508b93c | 16:47 |
| shogun-notifier- | shogun: include SGRefObject before SGObject for swig | 16:47 |
| shogun-notifier- | shogun: Soeren Sonnenburg :feature/CMakeImproved * a93cb3b / src/ (5 files): https://github.com/shogun-toolbox/shogun/commit/a93cb3b9136f8072472067ac57828992bf6d8d77 | 16:47 |
| shogun-notifier- | shogun: drop SERIALIZABLE_DUMMY | 16:47 |
| shogun-notifier- | shogun: Soeren Sonnenburg :feature/CMakeImproved * ed592ee / src/interfaces/modular/SGBase.i: https://github.com/shogun-toolbox/shogun/commit/ed592ee8942ecaf9e5bb9e8844a3953924ca8af7 | 16:47 |
| shogun-notifier- | shogun: add namespace to get Externalizable to work for real | 16:47 |
| shogun-notifier- | shogun: Soeren Sonnenburg :feature/CMakeImproved * ba0a597 / src/interfaces/modular/SGBase.i: https://github.com/shogun-toolbox/shogun/commit/ba0a597a2b32dd3456403bc8c705aa83e47f2dae | 16:47 |
| shogun-notifier- | shogun: make ref/unref known *before* including the class | 16:47 |
| -!- travis-ci [~travis-ci@ec2-54-226-95-169.compute-1.amazonaws.com] has joined #shogun | 17: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/14768179 | 17:32 |
| -!- travis-ci [~travis-ci@ec2-54-226-95-169.compute-1.amazonaws.com] has left #shogun [] | 17:32 | |
| @sonney2k | besser82, I will be around later in the evening... | 18:25 |
| @sonney2k | why oh why is csharp failing now | 18:27 |
| @sonney2k | besser82, I actually don't see the issue you see - shogun doesn't include any external libs from its headers | 18:57 |
| besser82 | sonney2k: actually it does ---> shogun/mathematics/linalg/linsolver/IterativeSolverIterator.h | 18:59 |
| besser82 | sonney2k: one example | 18:59 |
| @sonney2k | besser82, then this needs to be fixed in this example | 18:59 |
| besser82 | sonney2k: then you will need to do some predeclaration for eigen3 :( | 19:00 |
| besser82 | sonney2k: there actually a lot more stuff like this for ColPack, ARPREC, etc... | 19:00 |
| @sonney2k | besser82, where? | 19:01 |
| @sonney2k | all bugs | 19:01 |
| @sonney2k | I am pretty sure we don't need lapack / atlas pthreads etc | 19:01 |
| besser82 | sonney2k: are you sure those are bugs??? | 19:02 |
| @sonney2k | yes | 19:03 |
| besser82 | e.g. in that named header there is stuff used being declared in eigen3-headers | 19:03 |
| @sonney2k | besser82, you cannot require people to having installed all the deps developer files shogun has as build deps | 19:03 |
| besser82 | i don't | 19:03 |
| @sonney2k | besser82, so yes all bugs | 19:04 |
| besser82 | sonney2k: but how should we solve? | 19:04 |
| @sonney2k | besser82, where do we have to solve it | 19:04 |
| @sonney2k | we just don't use external libs in .h's | 19:04 |
| besser82 | sonney2k: lemme probe all headers for stuff like that | 19:04 |
| besser82 | sonney2k: me and wiking agree to have those headers installed along shogun in a %{includedir}/shogun/third_party/ | 19:05 |
| @sonney2k | and of course d-ptr's solve it for all cases and we want to do them anyway | 19:05 |
| @sonney2k | besser82, not needed | 19:05 |
| besser82 | sonney2k: as a quick thing until we have d-ptr implemented?!? | 19:06 |
| besser82 | sonney2k: since we are going to have them, we can solve this temporary like that | 19:06 |
| @sonney2k | besser82, well no it works except for one example right? | 19:06 |
| besser82 | sonney2k: include/shogun/mathematics/linalg/ratapprox/tracesampler/ProbingSampler.h | 19:07 |
| besser82 | include/shogun/mathematics/JacobiEllipticFunctions.h | 19:07 |
| besser82 | sonney2k: are the next ones | 19:07 |
| besser82 | sonney2k: include/shogun/mathematics/lapack.h | 19:07 |
| besser82 | sonney2k: more to come.... | 19:07 |
| besser82 | sonney2k: that's not just fixing up 1 or 2 headers.... :( | 19:08 |
| besser82 | sonney2k: btw. we have another issue, but that's another case.... | 19:08 |
| besser82 | sonney2k: multi-lib incompatibility with shogun/lib/config.h and others | 19:08 |
| besser82 | sonney2k: like one cannot install iX86 and amd64 within the same OS | 19:09 |
| besser82 | sonney2k: and other arches, too, i suppose | 19:09 |
| besser82 | sonney2k: but that's only stuff we have to deal with as pkg-maintainers in debian / FC / RHEL | 19:10 |
| besser82 | sonney2k: but we would need to get that multilib stuff addressed, too... | 19:11 |
| besser82 | sonney2k:???? | 19:17 |
| besser82 | sonney2k: I so far found ~150 headers including stuff which is _not_ stdlib nor common build-essential... | 19:18 |
| besser82 | sonney2k: depending on shogun's build-config that would be: hdf5, eigen3, libxml, json, atlas / clapack / lapack, arprec, locales, colpack | 19:21 |
| besser82 | sonney2k: and possibly some more requirements | 19:22 |
| -!- some_student [~some_stud@pool-72-70-88-143.nycmny.east.verizon.net] has joined #shogun | 19:40 | |
| some_student | Hey 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_student | Only installing the python modular package as well | 19:46 |
| -!- iglesiasg [~iglesiasg@206.Red-83-61-168.dynamicIP.rima-tde.net] has joined #shogun | 19:47 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 19:47 | |
| besser82 | some_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_student | Appreciate the timely response! Thanks for the tip | 19:48 |
| @iglesiasg | wiking may be able to help as well | 19:49 |
| @wiking | some_student: yeah that has been fixed in the develop branch of shogun | 19:52 |
| @wiking | some_student: basically clang 3.3 has some funky things going on because of switching to libc++ from libstdc++ | 19:53 |
| some_student | oo okay, so if I just grab the dev branch and build it should be good? | 19:55 |
| @wiking | indeed | 19:55 |
| @wiking | that person that uses maven to build an ant project should be hanged | 19:56 |
| some_student | Awesome! Thanks so much for the quick respsonse! Where is your dev branch located by the way? | 19:57 |
| @wiking | some_student: git clone https://github.com/shogun-toolbox/shogun.git | 19:58 |
| @wiking | some_student: should work as 10.9 has by default git installed :P | 19:58 |
| some_student | haha 10.9 is a godsend with default installations this time around. Thanks for the link | 19:59 |
| @wiking | nw | 19:59 |
| @sonney2k | besser82, sorry had to sing like 100 x-mas carols until the kids were ok with me leaving | 20:11 |
| @sonney2k | besser82, 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 | |
| @sonney2k | besser82, what I meant was that you don't need third party libs installed but only headers - quite the opposite of what I said above | 20:12 |
| @sonney2k | but still we should really get rid of all third party deps when you link against libshogun / compile w/ shogun headers | 20:13 |
| @sonney2k | besser82, anyways it would be nice if we could get your cmake stuff merged rather soonish | 20:14 |
| @sonney2k | I would want to do some more cleanups in the modular/*.i dir | 20:15 |
| @sonney2k | and yay all the c# examples work on my machine | 20:22 |
| @sonney2k | wiking, any clues how to run the csharp examples on fatbot? | 20:35 |
| @sonney2k | wiking, if I just do ctest --output-on-failure -j2 -R csharp | 20:35 |
| @sonney2k | wiking, it says No tests were found!!! | 20:36 |
| @sonney2k | ahh wrong dir | 20:37 |
| @sonney2k | build/buil | 20:37 |
| -!- some_student [~some_stud@pool-72-70-88-143.nycmny.east.verizon.net] has joined #shogun | 20:43 | |
| some_student | Hey 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 |
| besser82 | sonney2k: :D Christmas with them kids ;) | 20:48 |
| besser82 | sonney2k: `Advent` actually ;) | 20:48 |
| besser82 | sonney2k: CMake stuff is nearly finished, first PR to come during tomorrow ;) | 20:48 |
| besser82 | sonney2k: btw. you aren't blocked cleaning that modular*/*.i stuff ;) | 20:49 |
| @wiking | some_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 python | 20:49 |
| besser82 | sonney2k: I know how to rebase my branch upon develop ;) | 20:50 |
| @sonney2k | some_student, wiking I had that very same issue too - be extra cautious which python version is used and adjust PYTHON_PATH accordingly | 20:52 |
| @sonney2k | some_student, pretty annoying .... | 20:53 |
| @sonney2k | besser82, well did you do any cleanups in the .i files? | 20:53 |
| @sonney2k | besser82, I mean I don't know exactly how ccache for swig works | 20:54 |
| @sonney2k | besser82, but maybe it is possible to speed things up a bit | 20:54 |
| @sonney2k | shogun-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 finishes | 20:54 |
| besser82 | sonney2k: actually if ccache is properly configure it will be used by swig as well | 20:59 |
| besser82 | sonney2k: yes, i did some mods to those *.i, but nothing really large | 20:59 |
| besser82 | sonney2k: actually moving defines to SHOGUN_-scope, e.g. USE_FEATURE ---> SHOGUN_USE_FEATURE | 21:00 |
| besser82 | sonney2k: and making sure config.h is picked up properly | 21:00 |
| @sonney2k | besser82, we have a couple of defines in there that are JAVA/ etc specific | 21:02 |
| besser82 | sonney2k: i know, seen them | 21:02 |
| @sonney2k | besser82, so some objects get functions attached | 21:02 |
| @sonney2k | for python / java etc | 21:02 |
| besser82 | sonney2k: right | 21:02 |
| besser82 | sonney2k: afaik there is some ifdef / ifndef around inlined code and such | 21:03 |
| besser82 | sonney2k: so what's the punch-line? | 21:04 |
| @sonney2k | besser82, I think ccache won't work due to these lang specific defines at all | 21:05 |
| besser82 | sonney2k: it does ;) | 21:05 |
| @sonney2k | maybe we should have one different modshogun.i or / SGBase.i per language | 21:05 |
| besser82 | sonney2k: not really | 21:06 |
| @sonney2k | besser82, then caching would work - I mean if we change one .i file | 21:06 |
| besser82 | sonney2k: tht's correct, but i already took care of that ;) | 21:06 |
| @sonney2k | besser82, lets get your thing merged first and then discuss again after I did some experiments with it :) | 21:07 |
| besser82 | sonney2k: actually some of those .i-files are autogenerated by cmake now | 21:07 |
| besser82 | sonney2k: and testsuite passes so far | 21:08 |
| besser82 | sonney2k: by the .i-files are not that much relevant, the way the modules are build actually | 21:09 |
| besser82 | sonney2k: there could be much more speed gain when we would SWIG && CC every .i-file seperately, and get the object linked together... | 21:10 |
| besser82 | sonney2k: but so far, like wiking said, modules are just crashing with such a setup | 21:10 |
| besser82 | sonney2k: that would be subject to more and deeper investigation.... | 21:11 |
| besser82 | sonney2k: but I can dooooooooo it ;) after merge | 21:11 |
| besser82 | sonney2k: recently there is a _real_ speedup when re-compiling from ccaches even for the modules ;) | 21:12 |
| besser82 | sonney2k: the whole stack now rebuilds within a minute, if there were no changes.... | 21:13 |
| besser82 | sonney2k: changes actually slow down the rebuild a bit, but not as far as build time are now | 21:14 |
| besser82 | sonney2k: depending on the impact of the actual change there is rebuild-times of ~3 - 5 minutes when ccaches are present | 21:15 |
| some_student | wiking, 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 |
| @sonney2k | besser82, 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/2068 | 21:17 |
| besser82 | sonney2k: allrighty ;) | 21:17 |
| besser82 | some_student: try -DPYTHON_INCLUDE_PATH=%{path to your python headers} on the cmake commandline | 21:19 |
| besser82 | some_student: %{path to your python headers} should point to the include-dir of the python-install you want to use python-shogun with | 21:20 |
| besser82 | some_student: I hope that will help you ;) | 21:21 |
| some_student | besser82: Looks promising, trying now! Figured I was missing something! thank you all :) | 21:23 |
| besser82 | some_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 #shogun | 21:26 | |
| -!- sonne|osx [~sonne@f053038072.adsl.alicedsl.de] has quit [Quit: sonne|osx] | 21:37 | |
| some_student | besser82: 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 |
| besser82 | some_student: mhhhh.... sounds odd... | 21:46 |
| some_student | I know.. I keep ls'ing the directory as a sanity check and its definitely there | 21:47 |
| besser82 | some_student: are both python version the same or different? | 21:47 |
| some_student | both are the same to my knowledge | 21:49 |
| besser82 | some_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 |
| besser82 | some_student: if pathes do have whitespaces try to wrap them into "" | 21:51 |
| some_student | no 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 |
| besser82 | Good n8, folks! :D | 22:20 |
| -!- besser82 [~besser82@fedora/besser82] has quit [Quit: freedom, friends, features, first ---> fedoraproject.org] | 22:20 | |
| some_student | besser82: 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 much | 22:25 |
| -!- some_student [~some_stud@pool-72-70-88-143.nycmny.east.verizon.net] has quit [Quit: irc2go] | 22:25 | |
| @iglesiasg | time to bed, good night people | 23: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 #shogun | 23:38 | |
| Boeke | Hi does anyone have an idea why HDF5File fails to open a hdf5 file that h5py can open | 23:39 |
| Boeke | Specifically 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 |
| Boeke | never mind sorry | 23:52 |
| --- Log closed Mon Dec 02 00:00:49 2013 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!