IRC logs of #shogun for Monday, 2013-12-16

--- Log opened Mon Dec 16 00:00:08 2013
-!- virussss [~virussss@193.105.154.57] has joined #shogun00:50
-!- virussss [~virussss@193.105.154.57] has quit [Remote host closed the connection]00:51
shogun-buildbotbuild #554 of nightly_all is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_all/builds/55403:05
shogun-buildbotbuild #649 of nightly_default is complete: Failure [failed notebooks]  Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_default/builds/64904:18
-!- dsockwell [~twgs@199.167.199.97] has quit [Ping timeout: 260 seconds]06:10
-!- dsockwell [~twgs@199.167.199.97] has joined #shogun06:17
-!- Saurabh7 [~Saurabh7@117.200.182.27] has joined #shogun06:58
-!- travis-ci [~travis-ci@ec2-54-205-4-216.compute-1.amazonaws.com] has joined #shogun07:37
travis-ci[travis-ci] it's Saurabh7's turn to pay the next round of drinks for the massacre he caused in Saurabh7/shogun: http://travis-ci.org/Saurabh7/shogun/builds/1550862307:37
-!- travis-ci [~travis-ci@ec2-54-205-4-216.compute-1.amazonaws.com] has left #shogun []07:37
-!- sonne|osx [~sonne@89.204.138.23] has joined #shogun08:10
-!- sonne|osx [~sonne@89.204.138.23] has quit [Quit: sonne|osx]08:26
-!- dsockwell [~twgs@199.167.199.97] has quit [Ping timeout: 240 seconds]09:27
-!- dsockwell [~twgs@199.167.199.97] has joined #shogun09:28
-!- sonne|osx [~sonne@24-134-74-216-dynip.superkabel.de] has joined #shogun09:30
-!- sonne|osx [~sonne@24-134-74-216-dynip.superkabel.de] has quit [Client Quit]09:35
-!- iglesiasg [~iglesiasg@211.Red-83-40-129.dynamicIP.rima-tde.net] has joined #shogun09:42
-!- mode/#shogun [+o iglesiasg] by ChanServ09:42
besser82sonne|work: shall I CC you in shogun-review for fedora?10:16
sonne|workbesser82: why not10:16
sonne|workbesser82: is this with your new cmake magic already or the old one?10:17
besser82sonne|work: I thought you possibly don't want to get spammed ;)10:17
besser82sonne|work: No, actually the 3.0.0 tarball.  Cmake-magic on the way  ;)10:17
sonne|workwell I am good at ignoring things10:17
besser82sonne|work: :D10:17
besser82sonne|work: Which addy shall i use for cc?10:19
sonne|work@shogun-toolbox.org one10:19
besser82sonne|work: allrighty! will do  ;)10:19
besser82sonne|work: Looks like one needs to be registered with redhat-bugzilla be CC'ed  :(10:22
besser82sonne|work: have you any expirience with mono-shogun on ARM?10:25
besser82sonne|work: it's segfaulting in my builds  :(10:25
besser82sonne|work: i suspect mono as the reason...10:26
besser82sonne|work: build.log  --->  http://kojipkgs.fedoraproject.org//work/tasks/6886/6296886/build.log10:27
sonne|workbesser82: this is 3.0?10:28
besser82sonne|work: yes, 3.0.0 release-tarball10:29
sonne|workit looks like the same kind of c# exceptions we are getting now with 3.1dev10:29
besser82sonne|work: is it really caused by 3.1dev or has there been some mono update?10:30
besser82sonne|work: since this happenes for me on ARMv7hl, only.  ix86 / amd64 runs smoothly10:30
sonne|workthen it is different10:31
sonne|workwe have that on x86 / amd64 too10:31
besser82sonne|work: Since the problem is on ARM only, I suspect the mono-stack...10:31
besser82sonne|work: mhhh... but might be related somehow...10:32
besser82sonne|work: you have links to logs?10:32
sonne|workyeah but mono is ultra hard to debug10:33
sonne|workbesser82: http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/2095/steps/test%20csharp%20modular/logs/stdio10:33
besser82sonne|work: that's why we have some mono-guys around @rh / fedora  :-P10:33
besser82sonne|work: this log actually lacks gdb-output  :(10:38
besser82sonne|work: hard to say if there is some relation between them...10:39
sonne|workbesser82: how did you get the gdb output?10:39
besser82sonne|work: ask me sth...10:40
besser82sonne|work: Actually I just run testsuite as usual and the I get the output on the build-worker...10:40
besser82sonne|work: but there is some gdb-plugin for mono, afaik, which gets loaded...10:41
besser82sonne|work: I can ask those rel-eng guys how they do that....10:41
besser82sonne|work: Shall I try to do some scratch-build of recent checkout on them build-workers?10:42
besser82sonne|work: in Koji I mean...  and give you the logs?10:43
sonne|workbesser82: that would be nice - I am totally left in the dark why the mono stuff crashes10:44
besser82sonne|work: I suspect sth like: "previous frame identical to this frame (corrupt stack?)"10:44
besser82sonne|work: So currupted stack or releated...10:45
sonne|workbesser82: it can also be a subtle bug in our typemaps or even swig10:47
-!- Netsplit *.net <-> *.split quits: zxtx10:53
besser82sonne|work: for 3.1dev possibly, but for 3.0.0?10:54
sonne|workyeah there wasn't any change for ages10:54
sonne|workso no10:54
besser82sonne|work: for 3.0.0release I actually suspect problems related to the stack on $ARCH  ;)10:54
-!- Netsplit over, joins: zxtx10:55
* sonne|work too10:55
besser82sonne|work: localy testing my pimped to 3.1dev spec  ;)  If works then I'll upload to Koji in drop-in the url for you  ;)11:20
sonne|work:)11:20
besser82sonne|work: most of the local test is about the scrub of SVM^shit  :-P11:21
besser82sonne|work: Uploading srpm: /home/besser82/rpmbuild/SRPMS/shogun-3.1.0-0.0.1.git20131212.70e774d.fc20.src.rpm11:43
sonne|worklets see...11:44
besser82sonne|work: ul will take ~30 mins.  then I'll c&p the task url11:45
-!- travis-ci [~travis-ci@ec2-50-17-154-93.compute-1.amazonaws.com] has joined #shogun12:30
travis-ci[travis-ci] it's Soeren Sonnenburg's turn to pay the next round of drinks for the massacre he caused in Saurabh7/shogun: http://travis-ci.org/Saurabh7/shogun/builds/1551936812:30
-!- travis-ci [~travis-ci@ec2-50-17-154-93.compute-1.amazonaws.com] has left #shogun []12:30
besser82sonne|work, sonney2k: There goes da builds:  http://koji.fedoraproject.org/koji/taskinfo?taskID=629922512:38
besser82sonne|work, sonney2k: ix86, amd64 && ARMv7hl12:38
-!- Saurabh7 [~Saurabh7@117.200.182.27] has quit [Read error: Connection reset by peer]13:06
besser82iglesiasg, wiking, sonney2k, sonne|work, lisitsyn: btw. I'm wondering whether shogun has a sat-solver for boolean decision-trees?!?13:07
@iglesiasgbesser82, hmm no that I am aware of13:07
besser82iglesiasg, wiking, sonney2k, sonne|work, lisitsyn: or decisions based on a scenario to get the best possible outcome...13:08
besser82iglesiasg, wiking, sonney2k, sonne|work, lisitsyn: ok, next thing to put on my list ;)13:09
@iglesiasghehe13:09
-!- Saurabh7 [~Saurabh7@117.222.15.167] has joined #shogun13:21
sonne|workbesser82: the error really /is/ different14:06
besser82sonne|work: as I actually expected  ;)14:09
besser82sonne|work: 3.1dev has some real problem with the swig_wrapper.cxx i suppose...14:10
sonne|workbut only mono...14:10
sonne|workwhich is pretty weird14:10
sonne|workit seems to be some refcounting issue14:10
besser82sonne|work: mono is somewhat arkward...14:11
besser82sonne|work: Who needs that, btw?!?14:11
besser82sonne|work: I mean is Mono / C# really a good platform for ML stuff?14:11
sonne|workbesser82: since you get it almost for free with swig it is not really us to decide.14:12
besser82sonne|work: I see...14:12
besser82sonne|work: But is it worth the afford fixing that?14:12
sonne|workwhat the 3.1 one? yes the 3.0 one is likely a mono bug so no14:13
besser82sonne|work: btw. SWIG....14:14
sonne|work?14:14
besser82sonne|work: We need to do some serious tracing why it eats memory like chocolate  ;)14:14
sonne|workcould be a bug in swig too but no idea14:14
sonne|workwell I know.14:15
besser82sonne|work: unlikely a bug with swig...14:15
sonne|workit generates a huuuge table with function pointers14:15
sonne|workand these functions are all static wrapper functions that it generates14:15
besser82sonne|work: 3.0 mono runs smoothly with rawhide  ;)14:15
sonne|workon arm too?14:16
besser82sonne|work: but 1.5 Gbytes / make-thread?14:16
besser82sonne|work: no, but arm14:16
sonne|workok14:16
sonne|workyes14:16
sonne|workthe table is big14:16
besser82sonne|work: but that is a bug with mono-stack itself14:16
sonne|workand it is actually 3-4GB even14:16
sonne|workwhen compiling the wrap.cxx14:16
besser82sonne|work: building with -j8 takes ~12 Gbytes of mem  :(14:17
sonne|workno14:17
besser82sonne|work: It does  ;)14:17
besser82sonne|work: i have all modules enabled, but java, R an perl14:17
sonne|workwell if you compile libshogun in parallel it should just take a few hundred M14:17
sonne|workbut if you build the modular interfaces14:17
besser82sonne|work: libshogun, is small14:17
sonne|workand so compile the *_wrap.cxx14:18
sonne|workit will eat ~3GB for each14:18
besser82sonne|work: when SWIG runs mem is melting14:18
sonne|workbut swig is 'just' a gig or so14:19
besser82sonne|work: swig takes ~1.5 G at peak14:19
sonne|workyeah we need d-ptr's that will fix things14:19
besser82sonne|work: :D14:19
sonne|workor sane modules14:19
besser82sonne|work: even better  :D14:19
besser82sonne|work: we need some asian to do that  :-P14:19
besser82sonne|work: `c'mon do math..` *lol*14:20
besser82sonne|work: seems to be a lot of work in fromt of us...14:21
sonne|worknot too much but time is the problem14:21
-!- new_lido [~walid@193.227.20.2] has joined #shogun14:47
-!- new_lido [~walid@193.227.20.2] has quit [Ping timeout: 265 seconds]15:50
-!- Netsplit *.net <-> *.split quits: zxtx16:39
-!- Netsplit over, joins: zxtx16:44
-!- tricksy_ [uid12458@gateway/web/irccloud.com/x-cpwvgvpomaefjgum] has joined #shogun16:51
-!- sonney2k_ [~shogun@7nn.de] has joined #shogun16:52
-!- tricksy [uid12458@gateway/web/irccloud.com/x-nynfpyzawzsrsazp] has quit [Ping timeout: 248 seconds]16:55
-!- sonney2k [~shogun@7nn.de] has quit [Ping timeout: 248 seconds]16:58
-!- Saurabh7 [~Saurabh7@117.222.15.167] has quit [Ping timeout: 252 seconds]17:08
-!- Netsplit *.net <-> *.split quits: adrin, @wiking, shogun-buildbot, zxtx17:19
-!- wiking [~wiking@info2k1.hu] has joined #shogun17:19
-!- Netsplit over, joins: zxtx, adrin, shogun-buildbot17:21
-!- tricksy_ [uid12458@gateway/web/irccloud.com/x-cpwvgvpomaefjgum] has quit [Ping timeout: 264 seconds]17:27
-!- tricksy_ [uid12458@gateway/web/irccloud.com/x-igvpnqxzirxeqnkc] has joined #shogun17:30
-!- intermission [~intermiss@91.210.102.181] has joined #shogun18:19
-!- intermission [~intermiss@91.210.102.181] has quit [Remote host closed the connection]18:19
-!- packdima [~packdima@91.229.248.184] has joined #shogun18:24
-!- packdima [~packdima@91.229.248.184] has quit [Remote host closed the connection]18:26
-!- hammera [~hammera@193.105.154.33] has joined #shogun19:29
-!- hammera [~hammera@193.105.154.33] has quit [Remote host closed the connection]19:30
besser82sonne2k_, wiking, lisitsyn, iglesiasg: looks like shogun-3.1.0-0.1.git20131212.70e774d will be a 0-day feature for FC20, which gets released tomorrow  :D19:31
-!- talanto [~talanto@91.210.101.110] has joined #shogun19:48
-!- talanto [~talanto@91.210.101.110] has quit [Remote host closed the connection]19:50
-!- new_lido [~walid@41.218.181.207] has joined #shogun20:13
@iglesiasgbesser82, nice!20:14
sonney2k_besser82, what?20:14
sonney2k_iglesiasg, any news on the mono issue?20:15
sonney2k_lisitsyn, could you please fill out https://docs.google.com/forms/d/1HfYUE890vdSGXyOyUoqC8AP1PPQ5zdktppo-JsVN5xo/viewform20:18
lisitsynsonney2k_: ah yeah I have answered this guy20:18
sonney2k_lisitsyn, fill out this form20:18
lisitsynyeah sure20:19
sonney2k_lisitsyn, one more request... could you do some multitask/lasso / other domain adaptation notebook over x-mas? It would be good if you work is not lost / hidden too deep within shogun...20:20
lisitsynsonney2k_: yeah I will have like 8 days in january20:21
lisitsynI hope this would work20:21
lisitsynsonney2k_: I am now having the deadlinest week of the year :D20:21
besser82sonney2k_:???20:21
sonney2k_lisitsyn, I know what you mean... same here20:21
sonney2k_besser82, I totally didn't understand what you said20:22
besser82sonney2k_:  Shogun is in Fedora!  ;)20:22
besser82sonney2k_:  http://koji.fedoraproject.org/koji/taskinfo?taskID=630136520:22
sonney2k_lisitsyn, we should really go over each project you did and at least get it documented - same thing for wiking and iglesiasg and myself of course20:22
lisitsynthat's true20:22
sonney2k_currently it really is -> no notebook exists -> it doesn't exist at all!20:22
@iglesiasgsonney2k_, about the mono issue, I have tested it further but found no reason yet20:23
sonney2k_besser82, wow! that was quick!20:23
@iglesiasgsonney2k_, let me show you sth20:23
besser82sonney2k_:  It just a nice side-effect for having it in for Fedoras 10th birthday  ;)20:23
sonney2k_iglesiasg, could you reproduce it at least?20:23
@iglesiasgsonney2k_, yeah, sure20:23
sonney2k_iglesiasg, could you tweet about this?20:23
@iglesiasgsonney2k_, about the error? :D20:23
sonney2k_iglesiasg, I mean shogun -> fedora in FC20?20:23
sonney2k_iglesiasg, :P20:24
@iglesiasgsonney2k_, sure, give me a couple of minutes20:24
@iglesiasgsonney2k_, about the error, so this example for instance is one of them that fail https://github.com/shogun-toolbox/shogun/blob/develop/examples/undocumented/csharp_modular/kernel_gaussian_modular.cs20:24
lisitsynhaha20:24
-!- new_lido [~walid@41.218.181.207] has quit [Ping timeout: 240 seconds]20:24
lisitsynWe have terrible failure here, Cheers20:24
lisitsyngood idea for some twitter account huh20:24
sonney2k_iglesiasg, yeah I know - it fails on the buildbot20:25
@iglesiasgsonney2k_, so even if everything is commented and only the RealFeatures in line 11 are created (so pretty much the program remains init_shogun, create RealFeatures, exit_shogun)20:25
sonney2k_lisitsyn, haha we have it for years :D20:25
@iglesiasgsonney2k_, it crashes!20:25
sonney2k_iglesiasg, hmmhh20:25
sonney2k_iglesiasg, and can you make it even simpler:20:25
lisitsynwe could have a twitter for a bug20:25
sonney2k_iglesiasg, like just x=GaussianKernel()20:25
lisitsynStill crashes20:25
@iglesiasgsonney2k_, init shogun and exit work20:25
lisitsynStill crashes20:25
sonney2k_lisitsyn, go work on your deadline :P20:26
lisitsynsonney2k_: I have no idea how to make it work till this morning lol20:26
sonney2k_iglesiasg, I mean it is pretty obvious sth with refcounting isn't working...20:26
sonney2k_iglesiasg, does it work with just x=GaussianKernel() ?20:27
@iglesiasgsonney2k_, I have just managed to run the c# examples using ctest yet20:27
@iglesiasgsonney2k_, so I have not tried to gdb it and so on yet20:27
sonney2k_iglesiasg, yeah no problem but could you just run that example?20:27
sonney2k_iglesiasg, because here it does *not* crash20:27
@iglesiasgsonney2k_, with ctest or alone?20:28
sonney2k_iglesiasg, ./check.sh20:28
@iglesiasgare you sure it is really running everything with ./check.sh?20:28
@iglesiasgI tried that too20:28
@iglesiasgbut didn't work out so I went for ctest20:28
sonney2k_iglesiasg, yes20:28
@iglesiasgsonney2k_, can you try the minimal example x=GaussianKernel() then?20:29
sonney2k_iglesiasg, *all* examples work here20:30
@iglesiasghm ok20:30
@iglesiasgsonney2k_, what about with ctest in your machine?20:30
sonney2k_iglesiasg, that is why I am asking you to try the minimal one...20:30
@iglesiasgI cannot do it right now20:30
lisitsynone-class svm experience for object recognition anyone?20:31
sonney2k_iglesiasg, what are the cmake options you used?20:32
sonney2k_lisitsyn, same as always YMMV20:32
lisitsynsonney2k_: yeah it appears to be totally useless to know right people :D20:32
lisitsyndoesn't help!20:32
@iglesiasgsonney2k_, CSharpModular=ON CMAKE_BUILD_TYPE=Debug BUILD_EXAMPLES=ON IIRC20:33
@iglesiasgI use ccmake so I tune them in the menu, but those are the important ones I believe20:34
@iglesiasgretweet guys ;)20:38
sonney2k_iglesiasg, it doesn't compile the csharp examples ehre with cmake...20:46
@iglesiasgsonney2k_, what error do you get?20:47
@iglesiasgsonney2k_, have you installed all the packages that are installed in travis?20:47
@iglesiasgsonney2k_, maybe cmake is configured to compile them with another compiler20:53
@iglesiasgsonney2k_, which would make sense with the fact that you can run the examples without problems using ./check.sh20:53
@iglesiasgso as you said the other day, maybe the error just happens with a c# compiler... funny20:53
sonney2k_iglesiasg, seems like it is the mono compiler version that makes a difference20:56
sonney2k_iglesiasg, when I use gmcs it works20:56
sonney2k_when I use dmcs it fails20:57
sonney2k_when I use mcs it works too21:00
@iglesiasgsonney2k_, mmm what is your version of gmcs?21:02
@iglesiasgsonney2k_, I have here 2.10.8.1 and I guess that travis is using the same21:03
sonney2k_iglesiasg, travis is using dmcs21:12
@iglesiasgsonney2k_, aham! Since mono-gmcs is the package installed, I thought gmcs was the compiler21:13
@iglesiasgbut there is some unpacking mono-dmcs in travis log too... so I cannot really tell which one is used really21:14
@iglesiasgit must be in some cmake variable21:14
sonney2k_iglesiasg, when I uninstall gmcs it compiles with cmake21:16
@iglesiasghaha that is an ultimate proof of it then! :)21:18
@iglesiasgsonney2k_, so it fails with ctest in your system too?21:18
sonney2k_iglesiasg, with dmcs21:19
sonney2k_it fails21:19
besser82iglesiasg, sonney2_: for me it segfaults regardless of gmcs or dmcs or mcs...21:20
-!- HeikoS [~heiko@nat-163-63.internal.eduroam.ucl.ac.uk] has joined #shogun21:20
-!- mode/#shogun [+o HeikoS] by ChanServ21:20
lisitsynHeikoS: sonney2k_: iglesiasg: any idea how can one classify a cloud of points?21:21
@HeikoSlisitsyn: ?21:21
@HeikoSwhat do you mean?21:21
@iglesiasglisitsyn, segmentation?21:21
lisitsynsay I have keypoints on image21:21
lisitsynI have some observation that the locations of keypoints tell pretty much21:22
lisitsyniglesiasg: segment what?21:22
@HeikoSuse a kernel on sets21:22
lisitsynHeikoS: like distance?21:22
lisitsynI mean made of some distance?21:23
@HeikoSlisitsyn: there are some more involved things21:23
@HeikoSlike a gaussian like thing on sets21:23
@HeikoSMMD based distances etc21:23
sonney2k_iglesiasg, it seems we have a clash with 'ref' - an internal name in csharp21:23
@HeikoSlisitsyn: happy to chat about it later, but have to go home now, too late already :)21:23
lisitsynHeikoS: alright :D21:23
lisitsynthanks21:23
@HeikoSbye :D21:23
sonney2k_iglesiasg, http://msdn.microsoft.com/en-us/library/14akc2c7.aspx21:24
-!- HeikoS [~heiko@nat-163-63.internal.eduroam.ucl.ac.uk] has quit [Remote host closed the connection]21:24
@iglesiasgsonney2k_, oops21:25
@iglesiasgsonney2k_, if ref was not used before this change https://github.com/shogun-toolbox/shogun/pull/177121:27
@iglesiasgthen it would make perfect sense21:27
@iglesiasgsonney2k_, yep I think that is it21:28
@iglesiasgsonney2k_, SGRefObject ::ref()21:28
@iglesiasgthat method is new21:28
@iglesiasgarrgh not really21:28
@iglesiasgbefore there was SGObject::ref()21:28
@iglesiasgsonney2k_, does it still make sense to you?21:29
@iglesiasganyway, I have to run to the airport now. I will check the logs later, see you!21:29
-!- iglesiasg [~iglesiasg@211.Red-83-40-129.dynamicIP.rima-tde.net] has quit [Quit: Leaving]21:30
sonney2k_seems like ref is never used at all!?21:30
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun21:47
shogun-notifier-shogun: Soeren Sonnenburg :develop * 408843a / src/interfaces/modular/SGBase.i: https://github.com/shogun-toolbox/shogun/commit/408843ae3e63ce02102b94dbe9d0ad790ec106e821:47
shogun-notifier-shogun: add shogun namespace to ref/unref21:47
sonney2k_shogun-buildbot, force build --branch=develop 'deb3 - modular_interfaces'21:47
shogun-buildbotbuild forced [ETA 58m43s]21:47
shogun-buildbotI'll give a shout when the build finishes21:47
shogun-buildbotbuild #2096 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/209622:18
shogun-buildbotbuild #397 of FC19 - libshogun is complete: Success [build successful]  Build details are at http://buildbot.shogun-toolbox.org/builders/FC19%20-%20libshogun/builds/39722:30
sonney2k_besser82, I think I found the issue with csharp!22:38
sonney2k_besser82, it is crashing in the examples when calling 'exit_shogun'22:38
sonney2k_which is supposed to be called when *all* shogun objects are destroyed22:38
sonney2k_now that is not guaranteed22:39
sonney2k_since csharp might free objects later than we do22:39
sonney2k_and voila bumm22:39
sonney2k_I really wonder why the java stuff doesn't have the same problem22:40
shogun-notifier-shogun: Soeren Sonnenburg :develop * 7230f07 / examples/undocumented/ (212 files): https://github.com/shogun-toolbox/shogun/commit/7230f074751a97842170b8a5f9c69fbd9b8287ca22:46
shogun-notifier-shogun: do not call exit_shogun in java / csharp examples22:46
shogun-notifier-shogun:22:46
shogun-notifier-shogun: - calling exit_shogun at the end of a java / csharp example is22:46
shogun-notifier-shogun: dangerous: not all shogun objects might have been freed by the garbage22:46
shogun-notifier-shogun: collector at this stage so calling exit_shogun was observed to destroy22:46
shogun-buildbotbuild #2097 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/2097  blamelist: Soeren Sonnenburg <sonne@debian.org>22:56
besser82sonney2k_: java may have gc-behaviour like mono23:02
besser82sonney2k_: e.g. not doing gc when I demand, but somewhen it thinks it'd be better...23:03
-!- zxtx [~zv@c-98-223-196-32.hsd1.in.comcast.net] has quit [Ping timeout: 240 seconds]23:32
-!- bb_ [458fc8de@gateway/web/freenode/ip.69.143.200.222] has joined #shogun23:33
shogun-buildbotbuild #2098 of deb3 - modular_interfaces is complete: Success [build successful]  Build details are at http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/209823:34
besser82sonney2_, sonne|work, wiking, lisitsyn: there we go ---> https://admin.fedoraproject.org/pkgdb/acls/name/shogun  :D23:37
lisitsynbesser82: good! thanks23:38
besser82lisitsyn: how is your process towards fedora going?  :-P23:39
lisitsynbesser82: I am currently on my way to HELL :D23:39
besser82lisitsyn: Why?  What happened?23:39
lisitsynbesser82: I am overdued with some kind of freelance project23:40
lisitsynand they demanded some kind of working version in 6 hrs23:40
lisitsyn:D23:40
besser82lisitsyn: Need some help?23:40
lisitsynbesser82: if you are computer vision guy yes :)23:40
besser82lisitsyn: not me, but i know a few...23:40
besser82lisitsyn: BSc astro-physic should be enough, i guess...23:41
lisitsynbesser82: haha well pure computer vision task23:41
lisitsynneed ideas basically23:41
lisitsynlet me take a screenshot23:41
besser82kk23:41
lisitsynbesser82: e.g. this one23:43
lisitsynhttps://dl.dropboxusercontent.com/u/10139213/Screenshot%20from%202013-12-17%2002%3A41%3A40.png23:43
bb_wiking following up from saturday can you please elaborate "when u run cmake do you maybe have such a line in CMakeFiles/Makefile.cmake:   "../cmake/spinlock-test-darwin.cpp"23:43
lisitsynbesser82: the task is basically to detect whether it carries anything23:44
besser82lisitsyn: ok.  the screeny is a bit confusing...23:44
lisitsynbesser82: it is a fork loader :)23:44
besser82lisitsyn: ahhh23:44
besser82lisitsyn: so you should determine whether fork is free or loaded, rye?23:45
lisitsynbesser82: yeah23:45
shogun-buildbotbuild #138 of clang34 - undefined behaviour analysis is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20undefined%20behaviour%20analysis/builds/138  blamelist: Soeren Sonnenburg <sonne@debian.org>23:50
-!- travis-ci [~travis-ci@ec2-174-129-61-182.compute-1.amazonaws.com] has joined #shogun23:52
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/1555058723:52
-!- travis-ci [~travis-ci@ec2-174-129-61-182.compute-1.amazonaws.com] has left #shogun []23:52
--- Log closed Tue Dec 17 00:00:10 2013

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