| --- Log opened Tue Nov 26 00:00:40 2013 | ||
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 00:18 | |
| @iglesiasg | good night guys | 00:53 |
|---|---|---|
| -!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has quit [Quit: Ex-Chat] | 00:53 | |
| -!- new_lido_ is now known as new_lido_afk | 02:27 | |
| -!- new_lido_afk is now known as new_lido_ | 02:31 | |
| -!- sonne|osx_ [~sonne@f053041026.adsl.alicedsl.de] has joined #shogun | 03:02 | |
| -!- sonne|osx [~sonne@f053040204.adsl.alicedsl.de] has quit [Ping timeout: 272 seconds] | 03:05 | |
| -!- sonne|osx_ is now known as sonne|osx | 03:05 | |
| shogun-buildbot_ | build #533 of nightly_all is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_all/builds/533 | 03:24 |
| -!- new_lido_ [~walid@41.218.174.238] has quit [Ping timeout: 245 seconds] | 03:41 | |
| -!- new_lido [~walid@41.218.174.238] has quit [Ping timeout: 272 seconds] | 03:42 | |
| -!- new_lido [~walid@41.218.180.228] has joined #shogun | 03:53 | |
| -!- Boeke [~alex@24-179-114-25.dhcp.oxfr.ma.charter.com] has joined #shogun | 04:27 | |
| Boeke | hey can any one tell me the best way to open a hdf5 file with shogun is there still a direct method? | 04:28 |
| Boeke | like HDF5File | 04:28 |
| -!- new_lido [~walid@41.218.180.228] has quit [Ping timeout: 264 seconds] | 04:42 | |
| Boeke | I suppose it is also important to say that I am using the python modular interface. | 04:44 |
| shogun-buildbot_ | build #629 of nightly_default is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_default/builds/629 | 05:18 |
| -!- Boeke [~alex@24-179-114-25.dhcp.oxfr.ma.charter.com] has quit [Quit: Leaving] | 07:18 | |
| -!- sonne|osx [~sonne@f053041026.adsl.alicedsl.de] has quit [Quit: sonne|osx] | 07:35 | |
| -!- sonne|osx [~sonne@89.204.130.48] has joined #shogun | 08:22 | |
| sonne|osx | shogun-buildbot_: force build --branch=develop nightly_all | 08:22 |
| shogun-buildbot_ | build forced [ETA 10m57s] | 08:22 |
| shogun-buildbot_ | I'll give a shout when the build finishes | 08:22 |
| shogun-buildbot_ | build #534 of nightly_all is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_all/builds/534 | 08:28 |
| -!- besser82|laptop [~besser82@fedora/besser82] has joined #shogun | 08:33 | |
| -!- besser82 is now known as Guest31030 | 08:34 | |
| -!- besser82|laptop is now known as besser82 | 08:34 | |
| sonne|osx | hey besser82 ! | 08:36 |
| -!- Guest31030 [~besser82@fedora/besser82] has quit [Ping timeout: 252 seconds] | 08:36 | |
| sonne|osx | long time no see | 08:36 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 08:36 | |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * 48815d9 / src/interfaces/modular/SGBase.i: https://github.com/shogun-toolbox/shogun/commit/48815d95135c517304722919d2b20ef0c9753876 | 08:36 |
| shogun-notifier- | shogun: for java / c# add dummies for serialization for SGRefObject | 08:36 |
| besser82 | sonne|osx: Yes, those business duties you know?!? :D | 08:37 |
| sonne|osx | besser82: I managed to get protobuf to work in the meantime so you can do sth else or do it besser82 :) | 08:37 |
| besser82 | sonne|osx: I'm going to push your requested cmake changes today ;) | 08:37 |
| sonne|osx | better I mean ;) | 08:37 |
| besser82 | sonne|osx: like possibly improving protobuf && enabling build of modules from pre-compiled / existing libshogun.so | 08:38 |
| sonne|osx | cooooool! | 08:38 |
| sonne|osx | external would be graet | 08:39 |
| sonne|osx | then i could get the debs towork | 08:39 |
| * sonne|osx off train | 08:40 | |
| -!- sonne|osx [~sonne@89.204.130.48] has quit [Quit: sonne|osx] | 08:40 | |
| besser82 | sonne|work: btw. is testsuite failing on 32-Bits arches for you, too? | 08:42 |
| besser82 | sonne|work: on Fedora && RHEL ~10 test are repeatedly failing with ppc / ix86 / armv7h | 08:43 |
| besser82 | sonne|work: x86_64 (amd64) and ppc64 are running fine... | 08:43 |
| shogun-buildbot_ | build #1423 of rpm1 - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/rpm1%20-%20libshogun/builds/1423 blamelist: Soeren Sonnenburg <sonne@debian.org> | 09:01 |
| -!- new_lido [~walid@41.218.175.226] has joined #shogun | 09:05 | |
| shogun-buildbot_ | build #358 of FC19 - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/FC19%20-%20libshogun/builds/358 | 09:09 |
| shogun-buildbot_ | build #352 of FCRH - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/FCRH%20-%20libshogun/builds/352 | 09:11 |
| sonne|work | besser82: back | 09:24 |
| sonne|work | besser82: which ones? | 09:24 |
| besser82 | sonne|work: sry, been afk... just a momemt | 09:28 |
| shogun-buildbot_ | build #2057 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/2057 blamelist: Soeren Sonnenburg <sonne@debian.org> | 09:28 |
| besser82 | sonne|work: http://ur1.ca/g3lld <--- reproducible on all 32-Bit arches, but HDF5 which fails on 64-Bits, too... | 09:31 |
| besser82 | sonne|work: does hdf5 need inet-connectivity? | 09:32 |
| besser82 | sonne|work: the test I mean... | 09:32 |
| sonne|work | besser82: the mldata one yes - so disable it - it is downloading some data set from mldata.org. | 09:32 |
| besser82 | sonne|work: kk, will do so ;) thx | 09:33 |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has joined #shogun | 09:33 | |
| sonne|work | besser82: the others seem to be numerical differences like 1E-15 evaluates to 1.0000000000000001e-15. | 09:34 |
| besser82 | sonne|work: like precision-difference for 64 vs. 32 bits? | 09:36 |
| besser82 | sonne|work: or related to other problems? | 09:36 |
| sonne|work | besser82: yeah I guess so but I better investigate further. I need to run this on some legacy machine to be sure - the differences were really minor but still | 09:37 |
| besser82 | sonne|work: I can reproduce that in x86 VM and chroot... | 09:38 |
| besser82 | sonne|work: bare metal (Pentium4), too... | 09:39 |
| sonne|work | thoralf: hey good morning! thanks for the patch! do you recall if iglesiasg agreed that we don't need serialization for output? | 09:39 |
| thoralf | sonne|work: The problem with m_output also applies to StructuredLabels::m_labels :( | 09:41 |
| thoralf | sonne|work: See my commend. | 09:41 |
| thoralf | t | 09:41 |
| sonne|work | don't get shogun mails at work... | 09:41 |
| * sonne|work checks the PR | 09:42 | |
| sonne|work | thoralf: nargh | 09:42 |
| thoralf | Yes. | 09:43 |
| thoralf | Didn't see that in advance, sorry. | 09:43 |
| sonne|work | thoralf: this would rather mean we need some 'cheap' serialization too | 09:43 |
| thoralf | Hmm. | 09:43 |
| sonne|work | thoralf: not your fault - fernando didn't see it coming either | 09:44 |
| thoralf | sonne|work: Okay, SG_ADD is for serialization, right? So why wo we have to initialize this at object creation? Maybe just call all these SG_ADDs only when serializing? | 09:45 |
| sonne|work | thoralf: in principle yes but we need this for deep_copy of objects / equals too | 09:45 |
| thoralf | I see. | 09:46 |
| thoralf | Maybe introducing a SG_ADD_UNSERIALIZABLE(...) to add arbitrary variables? | 09:46 |
| thoralf | Would be a hack, since it moves the problem to runtime... | 09:47 |
| -!- new_lido [~walid@41.218.175.226] has quit [Read error: Connection reset by peer] | 09:48 | |
| sonne|work | thoralf: we have the other overhead like the io / parallel etc objects | 09:53 |
| sonne|work | thoralf: but I agree it would be nice to say have some extra class that you just plug in | 09:54 |
| sonne|work | and then you get serialization | 09:55 |
| -!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has joined #shogun | 09:55 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 09:55 | |
| sonne|work | thoralf: it really was never meant to be efficient in that respect | 09:56 |
| sonne|work | thoralf: the assumption was that any SGObject is huge anyway | 09:56 |
| sonne|work | as in holds a huge matrix or vector or sth | 09:56 |
| sonne|work | while it is true we could reduce SGObject memory footprint a bit | 09:56 |
| sonne|work | I just don't think that the RealNumber approach for more than debugging is the right way(tm) | 09:57 |
| sonne|work | you should rather have some aggregated structure | 09:57 |
| sonne|work | say RealNumbers or RealVector(s) | 09:57 |
| sonne|work | and then have stuff working on this | 09:57 |
| sonne|work | iglesiasg: hey! | 09:58 |
| sonne|work | iglesiasg: seen thoralf's comments? | 09:58 |
| @iglesiasg | hey there | 09:58 |
| @iglesiasg | yeah, I am following the conversation | 09:58 |
| thoralf | Hey iglesiasg - didn't see you sneaking in ;) | 09:58 |
| @iglesiasg | hehehe | 09:58 |
| sonne|work | lisitsyn: any ideas why http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/2057/steps/examples%20and%20unit%20tests/logs/stdio is happening | 09:58 |
| sonne|work | lisitsyn: location: class org.shogun.SGRefObject | 09:59 |
| sonne|work | this.save_serializable(tmpFile); | 09:59 |
| sonne|work | lisitsyn: I did add SERIALIZABLE_DUMMY(shogun::SGRefObject); | 09:59 |
| sonne|work | lisitsyn: but it is not used?! any ideas? | 09:59 |
| thoralf | sonne|work: Well, maybe we simply could have subclasses of StructuredLabels for each label type. As labels usually don't live alone. | 10:00 |
| sonne|work | thoralf: sounds better - iglesiasg? | 10:00 |
| sonne|work | iglesiasg: any thoughts? | 10:00 |
| @iglesiasg | I understand this is how it is done right now, isn't it? | 10:01 |
| @iglesiasg | these subclasses would be the current Sequence, RealNumber, FactorGraph, etc | 10:01 |
| @iglesiasg | well, without etc, I think there are no more than those :D | 10:01 |
| thoralf | iglesiasg: No. Dropping these "Data" classes and putting them into the "Labels" classes. | 10:01 |
| thoralf | Drop RealNumber and create RealSOLabels | 10:02 |
| thoralf | extending StructuredLabels | 10:02 |
| thoralf | Because objects (in shogun) are too expensive to have millions of them. | 10:02 |
| @iglesiasg | there is a MulticlassSOLabels, SequenceLabels and so that extend StructuredLabels | 10:02 |
| thoralf | iglesiasg: But they internally create an object for every label. | 10:03 |
| @iglesiasg | ok | 10:03 |
| -!- zxtx [~zv@ool-2f110054.dyn.optonline.net] has quit [Ping timeout: 264 seconds] | 10:03 | |
| @iglesiasg | thoralf, so how would they look like now? | 10:03 |
| -!- sonne|work [~sonnenbu@24-134-74-216-dynip.superkabel.de] has left #shogun [] | 10:04 | |
| -!- sonne|work [~sonnenbu@24-134-74-216-dynip.superkabel.de] has joined #shogun | 10:04 | |
| thoralf | I'm just wondering if it would be possible (with finite effort) to refactor the SO labels... Maybe by just making StructuredLabels an interface and each Labels class implementing it's own (efficient) structures. | 10:05 |
| thoralf | e.g. RealSoLabels only dealing with SGVector<float> internally. | 10:05 |
| @iglesiasg | ok, I think it should be possible | 10:07 |
| @iglesiasg | however, I think that the type of each label should still have the same superclass | 10:07 |
| @iglesiasg | the current StructuredData | 10:07 |
| thoralf | Ehrm. I was just trying to avoid StructuredData. ;) | 10:09 |
| -!- zxtx [~zv@ool-2f110054.dyn.optonline.net] has joined #shogun | 10:11 | |
| -!- naywhayare [~ryan@spoon.lugatgt.org] has quit [Ping timeout: 260 seconds] | 10:12 | |
| @iglesiasg | hehe ok | 10:13 |
| thoralf | sonne|work: Btw., why did we make SGDynamicRefObjectArray a SGRefObject instead of CSGObject? | 10:13 |
| sonne|work | iglesiasg: please think this through thoroughly - we don't want to waste time here | 10:13 |
| thoralf | sonne|work: SGDynamicRefObjectArray could by a CSGObject | 10:14 |
| @iglesiasg | sonne|work, sure | 10:14 |
| sonne|work | thoralf: well it didn't support serialization anyway | 10:14 |
| sonne|work | doesn't | 10:14 |
| @iglesiasg | thoralf, but I don't think I see the problem we are trying too solve. Last week we talked about the overhead introduced because StructuredData extended CSGObject, fine. | 10:15 |
| @iglesiasg | thoralf, if StructuredData does not extend it, what is the new problem such that you would like to get rid of StructuredData? | 10:15 |
| thoralf | That we lose serialization/equals/copy on StructuredLabels, because it's StructuredData entries do not support these operations. | 10:16 |
| @iglesiasg | Got it then | 10:17 |
| thoralf | I think we could either abort the refactoring here or push it further. | 10:18 |
| @iglesiasg | I am trying to think how would the SO framework look like if there was no StructuredData base class | 10:19 |
| thoralf | Depends on how easy it would be to do solve it. | 10:19 |
| @iglesiasg | thoralf, how would for instance the argmax be defined in the CStructuredModel? | 10:21 |
| @iglesiasg | In case there is no StructuredData base class. | 10:21 |
| @iglesiasg | The function signature. | 10:22 |
| thoralf | Good point. | 10:22 |
| @iglesiasg | A completely different approach | 10:24 |
| @iglesiasg | We not separate CSGObject? | 10:24 |
| thoralf | Parse error ;) | 10:24 |
| @iglesiasg | I believe that the part that gives the overhead is mainly due to model selection and cross validation stuff | 10:24 |
| -!- naywhayare [~ryan@spoon.lugatgt.org] has joined #shogun | 10:25 | |
| thoralf | iglesiasg: Yes. | 10:28 |
| thoralf | We have four different parameter objects in CSGObject: m_parameters, m_model_selection_parameters, m_gradient_parameters, m_parameter_map | 10:29 |
| @iglesiasg | maybe these guys should be moved to another class then | 10:29 |
| thoralf | parameter/parameter_map are neede for serialization/clone/deep_copy/equals. | 10:29 |
| @iglesiasg | is the overhead too large if only parameter/parameter_map are kept? | 10:29 |
| thoralf | But at least m_model_selection_parameters and m_gradient_parameters are not obvious. | 10:29 |
| @iglesiasg | If it is, then this approach has no sense whatsoever. | 10:30 |
| thoralf | Well, the overhead is mainly introduced by these 4 guys. | 10:30 |
| thoralf | So avoiding two of them would be a good deal ;) | 10:30 |
| thoralf | Looks like they could be extracted easily from CSGObject. | 10:33 |
| @iglesiasg | I suggest to send a mail to Heiko in any case, I think he did that so may point out something to take into account | 10:39 |
| thoralf | Of course. | 10:42 |
| thoralf | But I think this is getting too complicated to be fixed easily. | 10:42 |
| thoralf | sonne|work: Agree that we stop working on the issue here? Too many complications everywhere... | 10:43 |
| thoralf | Too many dependencies. | 10:44 |
| thoralf | And iglesiasg, thanks for your time. | 10:44 |
| -!- naywhayare [~ryan@spoon.lugatgt.org] has quit [Ping timeout: 264 seconds] | 10:46 | |
| -!- naywhayare [~ryan@spoon.lugatgt.org] has joined #shogun | 10:54 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has quit [Quit: Konversation terminated!] | 10:58 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has joined #shogun | 10:59 | |
| @iglesiasg | thoralf, no problem at all :) | 11:02 |
| sonne|work | iglesiasg: the right fix is not trying to squeeze every byte out of sgobject - it was never intended to be a cheap object. | 11:03 |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has quit [Client Quit] | 11:03 | |
| sonne|work | iglesiasg: I mean there is a reason why we have a CLabels class and not one CLabel object and then an array of them | 11:04 |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has joined #shogun | 11:04 | |
| sonne|work | iglesiasg: so please think about how we can use aggregated structures and return e.g. multiple things in argmax | 11:05 |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has quit [Client Quit] | 11:08 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has joined #shogun | 11:09 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has quit [Client Quit] | 11:13 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has joined #shogun | 11:14 | |
| @iglesiasg | void* | 11:18 |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has quit [Client Quit] | 11:18 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has joined #shogun | 11:19 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has quit [Client Quit] | 11:24 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has joined #shogun | 11:24 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has quit [Client Quit] | 11:29 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has joined #shogun | 11:29 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has quit [Client Quit] | 11:34 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has joined #shogun | 11:34 | |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 11:36 | |
| -!- zxtx [~zv@ool-2f110054.dyn.optonline.net] has quit [Ping timeout: 245 seconds] | 11:37 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has quit [Client Quit] | 11:39 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has joined #shogun | 11:39 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has quit [Client Quit] | 11:44 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has joined #shogun | 11:44 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has quit [Client Quit] | 11:49 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has joined #shogun | 11:49 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has quit [Client Quit] | 11:54 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has joined #shogun | 11:54 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has quit [Ping timeout: 246 seconds] | 12:00 | |
| -!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has quit [Quit: Ex-Chat] | 12:52 | |
| -!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 252 seconds] | 13:03 | |
| -!- besser82 [~besser82@77-22-24-6-dynip.superkabel.de] has joined #shogun | 13:43 | |
| -!- besser82 [~besser82@77-22-24-6-dynip.superkabel.de] has quit [Changing host] | 13:43 | |
| -!- besser82 [~besser82@fedora/besser82] has joined #shogun | 13:43 | |
| -!- lisitsyn [~lisitsyn@80.252.20.67] has quit [Ping timeout: 248 seconds] | 13:46 | |
| -!- zxtx [~zv@ool-2f110054.dyn.optonline.net] has joined #shogun | 13:47 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has joined #shogun | 13:56 | |
| thoralf | Hey. | 13:56 |
| -!- zxtx [~zv@ool-2f110054.dyn.optonline.net] has quit [Ping timeout: 272 seconds] | 14:01 | |
| thoralf | sonne|work: Hmm. Iglesias said (void*), that's true, but suppose we're having an array of (void*) in StructuredLabels, how would we compare these? | 14:01 |
| thoralf | (compare/serialize/...) | 14:03 |
| -!- zxtx [~zv@ool-2f110054.dyn.optonline.net] has joined #shogun | 14:13 | |
| sonne|work | thoralf: I didn't yet understand what is wrong with a typed data container... | 14:17 |
| thoralf | sonne|work: Well, as soon we put something into StructuredLabels, which is *not* CSGObject, we'll have this serialization problem. Right? | 14:21 |
| sonne|work | thoralf: well SGVector/SGMatrix/Sparse*/String* etc works of course | 14:21 |
| thoralf | Out of the box or with custom code? | 14:22 |
| sonne|work | thoralf: out of the box | 14:22 |
| thoralf | sonne|work: How does it work? | 14:22 |
| -!- lisitsyn [~lisitsin@mxs.kg.ru] has joined #shogun | 14:23 | |
| thoralf | No SG_ADD methods in SGVector. | 14:23 |
| sonne|work | thoralf: SG_ADD(&my_vector, "bla", "bla", MS_NOT_AVAILABLE); | 14:23 |
| sonne|work | SG_ADD(&my_matrix, "bla", "bla", MS_NOT_AVAILABLE); | 14:23 |
| sonne|work | etc | 14:23 |
| thoralf | Well, in this case we could simply write "SG_ADD((CSGObject**)&m_outputs, "outputs", "Structured outputs", MS_NOT_AVAILABLE);" in StructuredLabels/MAPInference and we're done? | 14:25 |
| thoralf | Without casting it to CSGObject**? | 14:25 |
| sonne|work | thoralf: if m_outputs is SGVector or so yes | 14:26 |
| thoralf | It is not. | 14:26 |
| sonne|work | thoralf: what is it? | 14:29 |
| thoralf | m_output is no SGVector | 14:29 |
| sonne|work | thoralf: but what then? | 14:29 |
| thoralf | I'm trying to figure out what's neccessary to get this SG_ADD back on m_outputs/m_labels... e.g. DynamicRefObjectArray* or StructuredData* | 14:32 |
| thoralf | I still don't understand this magic. | 14:32 |
| sonne|work | thoralf: which class is this you are talking about - I haven't used the SO framework nor am I the architect so no idea | 14:33 |
| sonne|work | thoralf: in any case there is no magiv | 14:33 |
| sonne|work | c | 14:33 |
| sonne|work | thoralf: you just SG_ADD() variables you want to register | 14:33 |
| thoralf | Can these variables be of any type? | 14:34 |
| lisitsyn | any of supported ;) | 14:34 |
| thoralf | lol | 14:34 |
| sonne|work | thoralf: and all you can do is add CSGObject data types and the SG{Vector,Matrix,SparseMatrix} types and scalars like bool / int32_t etc | 14:34 |
| sonne|work | lisitsyn: ahh you there - seen my question above? | 14:35 |
| lisitsyn | sonne|work: no, let me read llogs | 14:35 |
| lisitsyn | sonne|work: uhm what question sorry? | 14:35 |
| sonne|work | (09:59:04 AM) sonne|work: lisitsyn: any ideas why http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/2057/steps/examples%20and%20unit%20tests/logs/stdio is happening | 14:36 |
| sonne|work | (09:59:16 AM) sonne|work: lisitsyn: location: class org.shogun.SGRefObject | 14:36 |
| sonne|work | (09:59:16 AM) sonne|work: this.save_serializable(tmpFile); | 14:36 |
| sonne|work | (09:59:37 AM) sonne|work: lisitsyn: I did add SERIALIZABLE_DUMMY(shogun::SGRefObject); | 14:36 |
| sonne|work | (09:59:45 AM) sonne|work: lisitsyn: but it is not used?! any ideas? | 14:36 |
| lisitsyn | hmm interesting | 14:37 |
| sonne|work | lisitsyn: we refactored SGObject so that it derives from SGRefObject which in turn only does the refcounting | 14:37 |
| lisitsyn | sonne|work: yeah I was following it a bit | 14:38 |
| sonne|work | lisitsyn: so it makes sense to be able to expose any SGRefObject to the modular interfaces (since we only need ref/unref) | 14:38 |
| lisitsyn | sonne|work: quite strange it didn't work | 14:39 |
| sonne|work | thoralf: clear now? | 14:40 |
| thoralf | sonne|work: Well, yes. But seems unsolvable (within finite time). | 14:43 |
| lisitsyn | sonne|work: can't see why it fails | 14:44 |
| sonne|work | lisitsyn: hmmh I don't see it either | 14:44 |
| sonne|work | thoralf: you know more about the framework than me - what is the current requirement? | 14:44 |
| lisitsyn | sonne|work: may be SGBase.i:313? | 14:45 |
| lisitsyn | the class is referenced before extended | 14:45 |
| lisitsyn | I don't know if that could cause it | 14:45 |
| -!- Saurabh7 [~Saurabh7@115.248.130.148] has joined #shogun | 14:46 | |
| sonne|work | lisitsyn: could be no idea - try it | 14:46 |
| -!- Saurabh7 [~Saurabh7@115.248.130.148] has quit [Client Quit] | 14:46 | |
| -!- Boeke [~alex@24-179-114-25.dhcp.oxfr.ma.charter.com] has joined #shogun | 14:47 | |
| sonne|work | Boeke: what was your question again? | 14:47 |
| sonne|work | Boeke: ahh yes HDF5 | 14:48 |
| sonne|work | Boeke: just use HDF5File | 14:48 |
| @wiking | lisitsyn: eigen is fucking awesome | 14:48 |
| lisitsyn | wiking: yeah eigen is ok ;) | 14:49 |
| lisitsyn | what makes you that excited? | 14:49 |
| Boeke | yeah ok. I can't load it I am going to go back and see if I can't do what I did last time I had a problem loafing a module. | 14:49 |
| thoralf | sonne|work: No real requirement? We tried to refactor StructuredData, but it didn't work out. ;) | 14:50 |
| thoralf | sonne|work: My requirement was: Use less memory, but that's already solved. You said, we should refactor StructuredData. ;) | 14:51 |
| @wiking | lisitsyn: well that it has all the modules for sparsesuite as well | 14:51 |
| @wiking | lisitsyn: and cholmod already has support for gpu based factorization | 14:52 |
| Boeke | So the error I get is vague and different from last time | 14:53 |
| Boeke | ImportError: cannot import name HDF5File | 14:53 |
| lisitsyn | wiking: viennacl is interesting in that part | 14:53 |
| @wiking | lisitsyn: yeah i've checked yesterday | 14:54 |
| lisitsyn | with good interfacing with eigen | 14:54 |
| @wiking | lisitsyn: it has one factorizer (incomplete cholesky) for sparse matrices | 14:54 |
| @wiking | or no | 14:55 |
| @wiking | http://viennacl.sourceforge.net/doc/namespaceviennacl_1_1linalg_1_1detail.html#ae72d75fd519eaf00742aeaf86abb1d3a | 14:55 |
| lisitsyn | wiking: they have interesting thing with these 'tags' | 14:56 |
| lisitsyn | to designate algorithm to be used | 14:56 |
| sonne|work | Boeke: but hdf5 got detected by cmake? | 14:56 |
| @wiking | so actually i'm going to go with having the factorization algo as a template module | 14:56 |
| @wiking | lisitsyn: as if u have viennacl then u might want to do opencl based factorizatio | 14:57 |
| lisitsyn | wiking: what do you do and why? ;) | 14:57 |
| @wiking | lisitsyn: well currently a KKT equation solver | 14:57 |
| @wiking | lisitsyn: the idea is that it could be used by other optimizers | 14:58 |
| lisitsyn | is it lacked currently? | 14:58 |
| lisitsyn | ;) | 14:58 |
| lisitsyn | I have no idea about that | 14:58 |
| @wiking | but i'll use it in my own qp solver | 14:58 |
| @wiking | lisitsyn: well the thing is that htis is always reimplemented eveyrwhere | 14:58 |
| @wiking | *everywhere | 14:58 |
| lisitsyn | I see | 14:58 |
| @wiking | and of course it's never super optimized | 14:58 |
| Boeke | oh no I realized I needed hdf5 after I installed. I am new to 9 gig data sets. | 14:59 |
| @wiking | lisitsyn: and since matrix factorization is heavily used in this tasks... i thought that it would be good to have the factorization methods as a plugin | 15:00 |
| Boeke | I guess I need to uninstall and reinstall again right? | 15:01 |
| @wiking | Boeke: reinstall should be fine | 15:01 |
| @wiking | as it'll overwite your previous install | 15:02 |
| Boeke | ok thanks | 15:02 |
| Boeke | cmake is throwing a lot of errors trying to add custom rules to things that already have them | 15:17 |
| @wiking | eh | 15:17 |
| @wiking | try to rm -rf build | 15:17 |
| @wiking | and then create build dir and rerun cmake | 15:17 |
| @wiking | should help with such problems | 15:17 |
| Boeke | ok | 15:17 |
| Boeke | I still encounter that error | 15:25 |
| -!- sonne|work [~sonnenbu@24-134-74-216-dynip.superkabel.de] has quit [Read error: Connection reset by peer] | 15:32 | |
| -!- sonne|work1 [~sonnenbu@24-134-74-216-dynip.superkabel.de] has joined #shogun | 15:33 | |
| @wiking | voila http://gigaom.com/2013/11/26/docker-goes-broader-supporting-more-linux-distros-out-of-the-box/ | 15:45 |
| @wiking | Boeke: can u pastebin that error plz | 15:45 |
| @wiking | http://blog.docker.io/2013/11/docker-0-7-docker-now-runs-on-any-linux-distribution/ | 15:45 |
| @wiking | http://blog.docker.io/2013/11/docker-0-7-docker-now-runs-on-any-linux-distribution/ | 15:46 |
| Boeke | ok I will try | 15:46 |
| @wiking | Boeke: if u really need shogun out of box just use our docker image | 15:47 |
| @wiking | Boeke: otherwise just copy-paste us somehow your erro | 15:47 |
| @wiking | r | 15:47 |
| Boeke | http://pastebin.com/1SbsG0SV | 15:50 |
| @wiking | oooh | 15:50 |
| @wiking | Boeke: did u use shogun before 3.0? | 15:50 |
| Boeke | yes | 15:51 |
| @wiking | ok that all makes sense now | 15:51 |
| @wiking | :) | 15:51 |
| @wiking | Boeke: so in /home/alex/shogun-3.0.0/src/interfaces/python_modular | 15:52 |
| @wiking | delete those files that the cmake is complaining about | 15:52 |
| Boeke | ok | 15:52 |
| @wiking | i.e. Machine.i Multiclass_includes.i Distance.i | 15:52 |
| @wiking | etc | 15:52 |
| @wiking | and rerun in your build dir the cmake | 15:52 |
| besser82 | sonne|work, wiking, lisitsyn, thoralf: any objections moving the generation of documented examples from external-script to cmake-internal? So the documented examples are actually generated out of source-tree? | 16:00 |
| besser82 | same for config.h / version.h, too? | 16:01 |
| thoralf | And class_list.cpp? ;) | 16:01 |
| @wiking | besser82: no | 16:01 |
| @wiking | besser82: go ahead | 16:01 |
| besser82 | thoralf: class_list.cpp is autogenerated? | 16:01 |
| thoralf | besser82: Yes. | 16:02 |
| @wiking | besser82: the only problem you'll have with the examples that it depends on the data submodule | 16:02 |
| thoralf | class_list.cpp.py | 16:02 |
| @wiking | besser82: and it's hardcoded in the examples (the path) | 16:02 |
| @wiking | besser82: it's like ../data/<datafilename> | 16:02 |
| @wiking | besser82: so that'll need to be generated somehow within the build dir | 16:03 |
| thoralf | besser82: Yields to problems some times, if you're building release/debug versions alternately. | 16:03 |
| @wiking | besser82: yes class_list is generated as well | 16:03 |
| besser82 | wiking: setting up a symlink isn't the problem ;) | 16:03 |
| @wiking | besser82: yeah i know i'm just saying that it should be in the right 'level' :P | 16:04 |
| besser82 | wiking: ;) | 16:04 |
| @wiking | besser82: that goes really for all the examples (libshogun, *_modular etc) | 16:04 |
| -!- zxtx [~zv@ool-2f110054.dyn.optonline.net] has quit [Read error: Operation timed out] | 16:04 | |
| besser82 | wiking: Seen it ;) | 16:04 |
| besser82 | wiking, thoralf: anything else being autogenerated? | 16:05 |
| @wiking | besser82: noup... just in unit tests | 16:05 |
| @wiking | besser82: but those are generated within the build dir | 16:05 |
| besser82 | wiking: so actually with cmake magic, rye? | 16:05 |
| @wiking | so that should be alright | 16:05 |
| besser82 | wiking: any objections to alter the generation of the modules in a way they will properly use ccache? | 16:09 |
| besser82 | wiking: like speeding rebuilds somewhat insane ;) | 16:09 |
| sonne|work1 | besser82: no we like long compile times! | 16:10 |
| @wiking | besser82: well we use already ccache | 16:10 |
| @wiking | besser82: both for modular interfaces and libshogun | 16:10 |
| @wiking | i.e. ccache and ccache-swig | 16:11 |
| @wiking | if of course ccache or ccache-swig is available | 16:11 |
| @wiking | so i dont see how that could be still cached...? | 16:11 |
| @wiking | or in another way | 16:11 |
| besser82 | wiking: I'm using ccache,too; but builds still take ~10 minutes for me :( | 16:12 |
| besser82 | wiking: so there must be a solution :-P | 16:12 |
| @wiking | besser82: well ccache is being prepended for each compilation if aavailable | 16:12 |
| -!- iglesiasg [~iglesias@2001:6b0:1:1041:e4ea:290f:b6ca:d6e] has joined #shogun | 16:13 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 16:13 | |
| @wiking | hence i really dont see how that can be still changed to be faster | 16:13 |
| @iglesiasg | thoralf, they there! | 16:13 |
| thoralf | Hey iglesiasg | 16:13 |
| besser82 | wiking: but infact a lot of files of the modules are with the same name | 16:13 |
| besser82 | wiking: that shreds most of ccache afaik.... | 16:14 |
| @iglesiasg | thoralf, I have been thinking about the SO refactoring. Let me ask you | 16:14 |
| besser82 | iglesiasg: hi! | 16:14 |
| @wiking | besser82: yes but the thing is that the swig file for all the interfaces a monolithic file... | 16:14 |
| thoralf | iglesiasg: Go ahead. :) | 16:14 |
| @wiking | besser82: modshogun.i | 16:14 |
| @iglesiasg | thoralf, if there is no StructuredData class, how will serialization be supported? | 16:14 |
| @iglesiasg | besser82, sup! | 16:15 |
| @wiking | besser82: and that is being ccached | 16:15 |
| thoralf | iglesiasg: I've been thinking about that, but I don't know. | 16:15 |
| @iglesiasg | thoralf, ok, I see | 16:15 |
| thoralf | iglesiasg: With my current PR it wouldn't work any more. ;) | 16:15 |
| @iglesiasg | thoralf, because I guess the argmax issue we talked about before could be fixed by using void* somewhere | 16:16 |
| besser82 | wiking: let me investigate some optimization possibilities | 16:16 |
| thoralf | iglesiasg: Yeah, but still: StructuredLabels must contain something that can be serialized. | 16:17 |
| besser82 | wiking: i possibly may find some.... | 16:17 |
| @iglesiasg | thoralf, exactly | 16:17 |
| thoralf | iglesiasg: Either array of CSGObject or SGVector or SGMatrix, whatever | 16:17 |
| @iglesiasg | thoralf, yes. However, SGVector and SGMatrix are just designed to contain primitive data types | 16:17 |
| @iglesiasg | which makes sense to me | 16:17 |
| thoralf | iglesiasg: Currently this is unsolved - independently of the argmax | 16:17 |
| thoralf | iglesiasg: I know. | 16:18 |
| @wiking | besser82: note that we had problems with previously trying to separate swig files into modules.... this is why we have now one monolitic swig file (modshogun.i) | 16:18 |
| @iglesiasg | thoralf, but I still don't understand why can't we have a lightweight CSGObject | 16:18 |
| sonne|work1 | iglesiasg: we could but it doesn't fix the problem | 16:18 |
| besser82 | wiking: mhh.... | 16:19 |
| @iglesiasg | sonne|work1, why not? | 16:19 |
| thoralf | iglesiasg: I already tried - have a look at SGRefObject. | 16:19 |
| besser82 | wiking: lemme try... | 16:19 |
| thoralf | iglesiasg: There are many dependencies on every thing implemented in CSGObject. | 16:19 |
| @wiking | besser82: if we could use swig modules we could use ccache on those... but at last we tried it was not possible, as the modular interfaces were just crashing | 16:19 |
| sonne|work1 | iglesiasg: you still have a comparably huge overhead for just storing one float | 16:20 |
| thoralf | iglesiasg: We could outsource gradient/model selection stuff as well, but I think thats all. | 16:20 |
| sonne|work1 | iglesiasg: the right fix would be to use an object that contains not just 1 float but say a vector or matrix of floats | 16:20 |
| thoralf | sonne|work1: But SO works differently - it should be able to handle arbitrary outputs. | 16:20 |
| @iglesiasg | sonne|work1, thoralf, however, I still think that the idea of storing a float as a structured label does not really represent what the SO stuff is usef for | 16:21 |
| thoralf | sonne|work1: Trees, sequences, sets, etc. | 16:21 |
| sonne|work1 | thoralf: arbitrary outputs composed of basic data types | 16:21 |
| @iglesiasg | what I mean is that we should not aim at designing the structured labels so that they are efficient when CStructuredLables is basically an array of floats | 16:21 |
| thoralf | sonne|work1: Of course, but still: How would you represent a class that can hold arbitrary combinations of basic types? | 16:23 |
| sonne|work1 | thoralf: how many of these class instances do you expect? | 16:24 |
| sonne|work1 | normally I would say CSGObject | 16:24 |
| sonne|work1 | butif #instances is too big you need some aggregated labels for efficiency reasons | 16:25 |
| @iglesiasg | thoralf, wiking, you guys have experience with SVMStruct code, don't you? | 16:25 |
| thoralf | iglesiasg: Yes. | 16:25 |
| @iglesiasg | thoralf, how do they solve this issue we are facing here? | 16:25 |
| @iglesiasg | IIRC, in the doc it is claimed that you can pretty much implement your own labels as you want and still use their solvers | 16:26 |
| thoralf | iglesiasg: You can define your own struct to represent your outputs, then compile it. ;) | 16:26 |
| @iglesiasg | but internally, in the ssvm solver for instance, this struct must be handled somehow | 16:27 |
| thoralf | iglesiasg: And you have to implement all stuff that deals with your data type. | 16:27 |
| @iglesiasg | I don't think I am making my point very clear.... argh | 16:27 |
| thoralf | We need a whiteboard. ;) | 16:28 |
| thoralf | Feels like a big misunderstanding. ;) | 16:28 |
| @iglesiasg | hehehe | 16:29 |
| -!- lisitsyn [~lisitsin@mxs.kg.ru] has quit [Quit: Leaving.] | 16:29 | |
| @iglesiasg | thoralf, let me try to explain | 16:29 |
| @iglesiasg | thoralf, so SVMStruct supports any data type the user may define | 16:29 |
| @iglesiasg | thoralf, agree? | 16:29 |
| thoralf | Yes, but it doesn't have any overhead like additional attributes you didn't define. | 16:30 |
| @iglesiasg | agree | 16:30 |
| @iglesiasg | then it must be that the user defined struct does not extend any internal SVMStruct class | 16:30 |
| @iglesiasg | thoralf, good so far? | 16:31 |
| thoralf | Yes. | 16:31 |
| @iglesiasg | All right. | 16:31 |
| thoralf | And that's the main difference to shogun, btw. | 16:31 |
| thoralf | The implementation is similar, except that svmstruct does not provide serialization, etc. | 16:32 |
| @iglesiasg | Then, how do the signatures of the functions that use this user defined data look like? | 16:32 |
| @iglesiasg | Because these functions must be used somewhere in their code for sure | 16:32 |
| thoralf | loss(label *ytrue, label *ypred); | 16:32 |
| @iglesiasg | all right | 16:33 |
| thoralf | iglesiasg: SVMstruct only handles one implemented type at a time. | 16:33 |
| thoralf | You need another type? Recompile. | 16:33 |
| @iglesiasg | Aham! | 16:33 |
| thoralf | It's the C-way. Not real C++. ;) | 16:33 |
| @iglesiasg | We cannot afford doing that unfortunately | 16:34 |
| sonne|work1 | thoralf: but you surely could do that in C too | 16:35 |
| thoralf | sonne|work1: Is there a way to implement custom comparator/serialization functions for StructuredLabels? | 16:35 |
| @iglesiasg | sonne|work1, do you mean without the need to recompile? | 16:35 |
| thoralf | (an easy way preferably ;)) | 16:35 |
| sonne|work1 | iglesiasg: yes | 16:36 |
| @iglesiasg | sonne|work1, I'd say that you can do that in C using void* | 16:36 |
| sonne|work1 | iglesiasg: well you can fake classes by handing over structs that contain function pointers... | 16:37 |
| sonne|work1 | that is how the linux kernel guys do it | 16:37 |
| thoralf | Pseudo-Objective-C. Loving it. ;) | 16:37 |
| @iglesiasg | thoralf, the only thing I can think about now is to make a new StructuredData base class that supports everything we need (serialization, lightweight, hopefully ref count like the one in SGObject) | 16:37 |
| @iglesiasg | thoralf, but that sounds pretty crazy :D | 16:37 |
| sonne|work1 | iglesiasg: but that is not efficient right? | 16:38 |
| @iglesiasg | sonne|work1, efficient in terms of the time/effort if may take? | 16:38 |
| sonne|work1 | iglesiasg: efficient memory overhead | 16:38 |
| @iglesiasg | sonne|work1, why not? Ref count would probably include little overhead, but I don't see how serialization would include any overhead | 16:40 |
| thoralf | iglesiasg: The SG_ADD stuff introduces the overhead at object creating. | 16:40 |
| thoralf | creation | 16:40 |
| @iglesiasg | thoralf, what does SG_ADD do internally? | 16:41 |
| @iglesiasg | ref count stuff, model selection stuff, both? | 16:41 |
| sonne|work1 | well we could say we have one SerializationFramework class | 16:41 |
| sonne|work1 | and all SGObjects have that as a member | 16:41 |
| sonne|work1 | which is null usually | 16:42 |
| sonne|work1 | but only when we do a serialization (load/save/comparison) | 16:42 |
| sonne|work1 | the object gets created | 16:42 |
| thoralf | sonne|work1: Sounds pretty good. | 16:42 |
| thoralf | Lazy initialization. | 16:42 |
| sonne|work1 | this certainly makes sense (has some other issue - like you serialize and suddenly it eats memory like hell) | 16:44 |
| sonne|work1 | but no idea if this is the right approach - I would rather use some aggregated labels | 16:45 |
| @iglesiasg | how would these aggregated labels look like? | 16:46 |
| thoralf | sonne|work1: The easiest way would be to have skinny StructuredData objects. Nothing more than structs. | 16:46 |
| sonne|work1 | iglesiasg: e.g. not a real number but a vector - for multiple labels | 16:47 |
| thoralf | sonne|work1: So basically structs+refcounting. Minimal overhead. | 16:47 |
| sonne|work1 | thoralf: but we don't have that because we want serialization of ? | 16:48 |
| thoralf | sonne|work1: That brings us back to my above question: Is there a way to implement custom comparator/serialization functions for StructuredLabels? ;) | 16:49 |
| thoralf | StructuredLabels taking care of it's own stuff. So we can implement StructuredData as skinny as possible. | 16:50 |
| sonne|work1 | thoralf: nah sounds more difficult than the optimized SGObject | 16:51 |
| @iglesiasg | CSGObject::equals is virtual so why not | 16:51 |
| @iglesiasg | about serialization idk | 16:51 |
| @iglesiasg | where is the serialization code btw? | 16:52 |
| sonne|work1 | iglesiasg: SGObject.cpp and Parameter* | 16:52 |
| @iglesiasg | load_serializable I see | 16:53 |
| @iglesiasg | and save, etc | 16:53 |
| @iglesiasg | all right, I have to run to a lab session now, see you later | 16:54 |
| -!- iglesiasg [~iglesias@2001:6b0:1:1041:e4ea:290f:b6ca:d6e] has quit [Quit: Ex-Chat] | 16:55 | |
| -!- sonne|osx [~sonne@89.204.138.171] has joined #shogun | 17:19 | |
| * sonne|osx sighs | 17:21 | |
| Boeke | Hi cmake is working but can't find "HDF5_DIR: The directory containing a Cmake configuration file for HDF5." | 17:24 |
| sonne|osx | Boeke: please paste the output of cmake ... do you have hdf5 developer files installed? | 17:28 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 17:29 | |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * 3761d82 / src/interfaces/modular/SGBase.i: https://github.com/shogun-toolbox/shogun/commit/3761d82ef03ab45aa237d2e9412babaf9471ac4a | 17:29 |
| shogun-notifier- | shogun: add dummy before doing ref / unref magic | 17:29 |
| Boeke | I do have the dev files installed. Cmake doesn't throw any errors I could generate and exit | 17:30 |
| Boeke | I just don't think that will get HPF5File installed. | 17:31 |
| @wiking | Boeke: can u copy paste the whole output of cmake somewhere | 17:33 |
| @wiking | ? | 17:33 |
| Boeke | cmake or ccmake ? | 17:34 |
| sonne|osx | Boeke: cmake in the beginning gives you an overview what optional features you have installed | 17:34 |
| Boeke | ok | 17:34 |
| sonne|osx | Boeke: please paste that so we know hdf5 is among the detected libs | 17:34 |
| Boeke | I will do that | 17:34 |
| -!- sonne|osx [~sonne@89.204.138.171] has quit [Quit: sonne|osx] | 17:40 | |
| Boeke | http://pastebin.com/HCD8FF5K | 17:43 |
| Boeke | so it did find HDF5 | 17:43 |
| @wiking | yes | 17:44 |
| Boeke | ok ccmake can't find the directory but cmake knows the package is there. If I generate a make file with ccmake will it know I have HDF5? | 17:47 |
| @wiking | what? | 17:49 |
| @wiking | u might want to read this: https://github.com/shogun-toolbox/shogun/blob/develop/README_cmake.md | 17:49 |
| shogun-buildbot_ | build #1424 of rpm1 - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/rpm1%20-%20libshogun/builds/1424 | 17:51 |
| Boeke | ok will do | 17:52 |
| besser82 | wiking: Where do I find this `modshogun.i`-swig-file? | 17:58 |
| @wiking | besser82: src/interfaces/modular | 17:59 |
| @wiking | there are all the common swig .i files | 17:59 |
| shogun-buildbot_ | build #320 of precise - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/precise%20-%20libshogun/builds/320 blamelist: Soeren Sonnenburg <sonne@debian.org> | 18:00 |
| besser82 | wiking: Thanks! As I suspected ;) | 18:00 |
| besser82 | wiking: And there lies the source of shredding the ccache ;) | 18:01 |
| besser82 | wiking: lot's of inlining and such.... | 18:01 |
| besser82 | wiking: with basically the same filenames, but different behaviour depending on what's defined.... | 18:02 |
| besser82 | wiking: that is what shreds the ccaches and make compiling that slow.... | 18:03 |
| besser82 | wiking: or (at least) recompiling... | 18:03 |
| -!- Saurabh7 [~Saurabh7@115.248.130.148] has joined #shogun | 18:07 | |
| @wiking | besser82: yes but u cannot simply run swig on those files alone | 18:07 |
| @wiking | besser82: i.e. you cannot use ccache-swig | 18:07 |
| -!- lisitsyn [~lisitsyn@80.252.20.67] has joined #shogun | 18:17 | |
| -!- lisitsyn [~lisitsyn@80.252.20.67] has quit [Quit: Leaving.] | 18:17 | |
| shogun-buildbot_ | build #2058 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/2058 blamelist: Soeren Sonnenburg <sonne@debian.org> | 18:18 |
| -!- zxtx [~zv@ool-2f110054.dyn.optonline.net] has joined #shogun | 18:20 | |
| -!- zxtx [~zv@ool-2f110054.dyn.optonline.net] has quit [Ping timeout: 245 seconds] | 18:26 | |
| -!- travis-ci [~travis-ci@ec2-54-235-6-45.compute-1.amazonaws.com] has joined #shogun | 18:28 | |
| 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/14553487 | 18:28 |
| -!- travis-ci [~travis-ci@ec2-54-235-6-45.compute-1.amazonaws.com] has left #shogun [] | 18:28 | |
| besser82 | wiking: I know... but there could be some possibility for a huge speed gain | 19:10 |
| Boeke | Hi I got it working. I really appreciate your help and patience with my low level of understanding. Thanks | 19:11 |
| -!- thoralf_ [~thoralf@91-65-142-97-dynip.superkabel.de] has joined #shogun | 19:13 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has quit [Ping timeout: 246 seconds] | 19:16 | |
| -!- lisitsyn [~lisitsyn@80.252.20.67] has joined #shogun | 19:20 | |
| -!- Saurabh7 [~Saurabh7@115.248.130.148] has quit [Quit: Leaving] | 19:24 | |
| @wiking | besser82: again how? | 19:26 |
| besser82 | wiking: I'm not sure,yet... trying to find a solution... | 19:27 |
| -!- sonne|osx [~sonne@f053041026.adsl.alicedsl.de] has joined #shogun | 19:32 | |
| sonne|osx | lisitsyn: didn't help! | 19:36 |
| -!- Saurabh7 [~Saurabh7@115.248.130.148] has joined #shogun | 19:43 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has joined #shogun | 19:53 | |
| -!- thoralf_ [~thoralf@91-65-142-97-dynip.superkabel.de] has quit [Ping timeout: 245 seconds] | 19:56 | |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 20:29 | |
| @wiking | besser82: yeah the solution would be to do swig modules | 20:41 |
| @wiking | but we had problems with that | 20:41 |
| -!- lisitsyn [~lisitsyn@80.252.20.67] has quit [Ping timeout: 245 seconds] | 21:45 | |
| -!- lisitsyn [~lisitsyn@80.252.20.67] has joined #shogun | 21:48 | |
| -!- sonne|osx [~sonne@f053041026.adsl.alicedsl.de] has quit [Quit: sonne|osx] | 22:23 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has quit [Quit: Konversation terminated!] | 22:37 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has joined #shogun | 22:38 | |
| -!- thoralf [~thoralf@91-65-142-97-dynip.superkabel.de] has quit [Client Quit] | 22:39 | |
| -!- thoralf_ [~thoralf@91-65-142-97-dynip.superkabel.de] has joined #shogun | 22:39 | |
| -!- thoralf_ [~thoralf@91-65-142-97-dynip.superkabel.de] has quit [Quit: Konversation terminated!] | 23:54 | |
| --- Log closed Wed Nov 27 00:00:42 2013 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!