| --- Log opened Tue Jun 18 00:00:50 2013 | ||
| -!- nube [~rho@49.244.111.202] has joined #shogun | 00:03 | |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 00:04 | |
| -!- nube [~rho@49.244.111.202] has quit [Ping timeout: 248 seconds] | 00:11 | |
| hushell | iglesiasg: python modular is okay now, but java failed... | 00:50 |
|---|---|---|
| iglesiasg | hushell: oh, do we have java examples with SO? :D | 00:51 |
| iglesiasg | didn´t know about that | 00:51 |
| iglesiasg | hushell: what is the test that fails? | 00:51 |
| hushell | iglesiasg: https://travis-ci.org/shogun-toolbox/shogun/jobs/8177867 | 00:52 |
| hushell | do you have any idea why this happened? | 00:52 |
| iglesiasg | mmmm that looks weird | 00:53 |
| iglesiasg | hushell: no, no idea really | 00:53 |
| iglesiasg | I would say it is not your patch's fault though | 00:53 |
| hushell | :) the java modular was okay before I modifying python examples | 00:53 |
| hushell | maybe the travis machine got a problem | 00:53 |
| iglesiasg | yes, it should be that | 00:54 |
| iglesiasg | did you update the PR then? | 00:54 |
| hushell | I just update the python examples | 00:54 |
| hushell | Let's wait Nico's reply for the m_loss | 00:54 |
| iglesiasg | hushell: yeah sure | 00:55 |
| iglesiasg | hushell: any idea why there are two different commits in the PR? | 00:55 |
| iglesiasg | this one looks a bit weird | 00:56 |
| iglesiasg | https://github.com/hushell/shogun/commit/dfa323f58d35a55b4108c91c5bf2b605316ff232 | 00:56 |
| hushell | I used the commit --amend | 00:56 |
| iglesiasg | it seems Soumyahit changes got in there | 00:56 |
| hushell | maybe I should do reset --soft | 00:57 |
| iglesiasg | I don't really understand how his changes got in there :D | 00:59 |
| -!- lisitsyn [~lisitsyn@83.234.169.173] has left #shogun [] | 01:00 | |
| iglesiasg | anyway in the overall diff of the PR they don't appear | 01:01 |
| iglesiasg | so if you are struggling to fix that we can probably just merge it, I don't think it should be a big issue | 01:01 |
| hushell | now I made them one commit :) | 01:02 |
| iglesiasg | hushell: ah nice you fix it already :) | 01:02 |
| iglesiasg | thanks! | 01:02 |
| hushell | all these happend because I don't git rebase :( | 01:02 |
| hushell | learning from pain | 01:02 |
| hushell | iglesiasg: Thanks again for the tips! | 01:03 |
| iglesiasg | hushell: you are welcome :) | 01:03 |
| iglesiasg | we have all screwed with git so many times, I have specially done it many many times :D | 01:03 |
| hushell | :D Shogun makes me know how to use git | 01:05 |
| iglesiasg | yes, that's pretty good actually! | 01:05 |
| iglesiasg | hushell: what's the plan now, heading already towards the factor graph? | 01:06 |
| hushell | iglesiasg: yep, I have started factor graph, but things will going a bit slow, cause I need to go to Seatle for 2 days | 01:07 |
| hushell | iglesiasg: How is your project going? | 01:07 |
| iglesiasg | hushell: good! | 01:08 |
| iglesiasg | I am meeting Georg tomorrow around here at 10am CET, I will be able to start harcdore coding soon :) | 01:09 |
| iglesiasg | but it will probably be slow this week as well for me | 01:09 |
| iglesiasg | I am coming back to Sweden tomorrow | 01:09 |
| iglesiasg | and this week is sort of big festivity there | 01:10 |
| hushell | So you done with your holidays | 01:10 |
| hushell | why you go back to school? | 01:10 |
| iglesiasg | hehe I was not in Spain for holidays actually, I came to finish my degree here | 01:11 |
| iglesiasg | hushell: no, it is called midsommar, the longest day of the year | 01:11 |
| hushell | my place still cold at night :( | 01:12 |
| iglesiasg | :( | 01:13 |
| hushell | Sweden should be even colder I guess | 01:14 |
| iglesiasg | well now in summer, providing that it is not raining, is normally nice weather | 01:14 |
| hushell | people should wait for few weeks for celebrating | 01:14 |
| iglesiasg | something around 20-25 ºC | 01:14 |
| hushell | like spring even better than summer :) | 01:15 |
| iglesiasg | yeah | 01:15 |
| iglesiasg | it is too hot for me now in Spain | 01:15 |
| hushell | and you have graduated, enjoy the time ! | 01:15 |
| hushell | :D I remember the weather in Barcelona last year, pretty hot | 01:16 |
| iglesiasg | hehe | 01:16 |
| iglesiasg | it tends to be warmer in Madrid (where I come from) | 01:16 |
| hushell | I support Real Madrid :) | 01:16 |
| iglesiasg | in Barcelona the weather the sea tends to make the weather sort of less warm | 01:16 |
| iglesiasg | but here it gets crazy | 01:17 |
| iglesiasg | hushell: nice! I am Real Madrid supporter too! :) | 01:17 |
| iglesiasg | now I like you more :P | 01:17 |
| hushell | hahahaaaa | 01:17 |
| hushell | I was very sad in Bacelona, can't really celebrate too much in bar | 01:18 |
| iglesiasg | haha | 01:18 |
| iglesiasg | when were you there? Was there any Real Madrid - Barcelona or so? | 01:18 |
| hushell | I did my master's in UAB | 01:19 |
| hushell | for one year | 01:19 |
| iglesiasg | aaaah ok! | 01:19 |
| hushell | but I went to Madrid for once | 01:19 |
| iglesiasg | so did you learn some Spanish? | 01:19 |
| hushell | so hard for me :) | 01:19 |
| iglesiasg | did you like Madrid? | 01:19 |
| hushell | so much!!! | 01:19 |
| hushell | but I didnt get a change to watch a match at Bernabeu. probably make this up next year | 01:20 |
| iglesiasg | :) | 01:20 |
| iglesiasg | cool | 01:20 |
| iglesiasg | did you visit Bernabeu anyway? | 01:21 |
| iglesiasg | I was there a couple of weeks ago | 01:21 |
| hushell | yep I visited there last year this time | 01:21 |
| hushell | Ancelotti is coming, a lot of expectation for next season | 01:22 |
| hushell | maybe we shouldn't talk too much football here haha | 01:23 |
| iglesiasg | hahaha a little bit of noise in the logs shouldn't hurt too much :) | 01:24 |
| iglesiasg | but yes, I am looking forward to seeing a new trainer (I didn't like Mourinho specially) | 01:25 |
| iglesiasg | and I am curious about this guy they mean to incorporate, Bale | 01:25 |
| hushell | I don't like C. Ronaldo too, let Bale come instead :) | 01:26 |
| iglesiasg | c'mon! How can you not like Ronaldo!?! | 01:27 |
| iglesiasg | hehe | 01:27 |
| hushell | too selfish I guess | 01:27 |
| iglesiasg | IMHO it is just appearence | 01:28 |
| hushell | in this sense, Ozil much better | 01:28 |
| iglesiasg | good player too, indeed | 01:28 |
| hushell | but I agree CR made many important goals | 01:28 |
| hushell | especially games with Barca last season | 01:29 |
| hushell | I was happy about that | 01:29 |
| iglesiasg | :) | 01:30 |
| iglesiasg | lot of talk going on now around Messi | 01:30 |
| hushell | about the tax evasion? | 01:31 |
| iglesiasg | yes | 01:31 |
| hushell | is it true? | 01:31 |
| iglesiasg | yes | 01:31 |
| hushell | omg, but I think they will never put him to jail | 01:32 |
| iglesiasg | he is probably not really guilty anyway. I mean, it is not the player who decides where the money is going | 01:32 |
| iglesiasg | they have other people doing that job | 01:32 |
| iglesiasg | yeah, I bet he won't go to jail. He will probably have to pay a big fine I think | 01:33 |
| hushell | I see, if I were him, I have no idea where the money going | 01:33 |
| hushell | little case for him | 01:34 |
| hushell | iglesiasg: I am going to do some exercises right now, have a good night! | 01:35 |
| iglesiasg | hushell: good night! talk to you in the morning :) | 01:35 |
| hushell | iglesiasg: see you | 01:35 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 01:53 | |
| shogun-notifier- | shogun: hushell :develop * 8288d99 / / (15 files): https://github.com/shogun-toolbox/shogun/commit/8288d99c5dc97bf041fbf69a047c308593e4a939 | 01:53 |
| shogun-notifier- | shogun: Removed m_loss from CStructuredOutputMachine | 01:53 |
| shogun-notifier- | shogun: Fernando Iglesias :develop * 3ff28a7 / / (15 files): https://github.com/shogun-toolbox/shogun/commit/3ff28a7854de8c8ffcd0b077d87a756adc74b5c8 | 01:53 |
| shogun-notifier- | shogun: Merge pull request #1174 from hushell/develop | 01:53 |
| shogun-notifier- | shogun: | 01:53 |
| shogun-notifier- | shogun: Removed m_loss from CStructuredOutputMachine | 01:53 |
| -!- iglesiasg [d58f3226@gateway/web/freenode/ip.213.143.50.38] has quit [Quit: Page closed] | 02:06 | |
| shogun-buildbot | build #947 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/947 blamelist: hushell <hushell@hushell-U510.(none)> | 02:08 |
| shogun-buildbot | build #948 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/948 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 02:09 |
| -!- nube [~rho@49.244.81.95] has joined #shogun | 02:18 | |
| -!- nube [~rho@49.244.81.95] has quit [Ping timeout: 246 seconds] | 02:22 | |
| -!- nube [~rho@49.126.230.83] has joined #shogun | 02:47 | |
| -!- nube [~rho@49.126.230.83] has quit [Quit: Leaving.] | 03:53 | |
| -!- zxtx [~zv@rrcs-74-62-200-195.west.biz.rr.com] has quit [Ping timeout: 256 seconds] | 04:41 | |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 04:53 | |
| -!- nube [~rho@116.90.239.3] has joined #shogun | 05:29 | |
| -!- nube [~rho@116.90.239.3] has quit [Ping timeout: 276 seconds] | 05:34 | |
| -!- nube [~rho@116.90.239.3] has joined #shogun | 05:42 | |
| -!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has joined #shogun | 07:05 | |
| -!- foulwall [~foulwall@2001:da8:215:503:70af:908a:2f4b:1f27] has joined #shogun | 07:12 | |
| -!- foulwall_ [~foulwall@li379-21.members.linode.com] has joined #shogun | 07:13 | |
| -!- foulwall [~foulwall@2001:da8:215:503:70af:908a:2f4b:1f27] has quit [Remote host closed the connection] | 07:14 | |
| -!- foulwall_ [~foulwall@li379-21.members.linode.com] has quit [Remote host closed the connection] | 07:51 | |
| -!- foulwall [~foulwall@2001:da8:215:503:4d40:8c59:6d30:e247] has joined #shogun | 07:57 | |
| -!- iglesiasg [~iglesias@193.147.49.157] has joined #shogun | 08:39 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 08:39 | |
| -!- sonne|work [~sonnenbu@sams-office-nat.tomtomgroup.com] has left #shogun [] | 08:47 | |
| -!- lisitsyn [~lisitsin@mxs.kg.ru] has joined #shogun | 08:55 | |
| -!- patrickp [~patrickp@84-75-165-165.dclient.hispeed.ch] has joined #shogun | 08:56 | |
| @iglesiasg | patrickp, hushell hey guys, good morning | 08:58 |
| patrickp | hi hushell and iglesiasg | 08:58 |
| patrickp | hushell: thanks for the pr last night, great work | 08:58 |
| @iglesiasg | hushell, yeah! nicely done :) | 08:59 |
| @iglesiasg | hushell, patrickp I have one hour more or less to discuss, then I will be around here with Georg and maybe lisitsyn discussing about the LMNN project :) | 09:00 |
| lisitsyn | iglesiasg: yes I am here | 09:00 |
| patrickp | sure, thanks a lot for taking the time to discuss with us! | 09:00 |
| @iglesiasg | patrickp, with pleasure! | 09:00 |
| patrickp | one question: what's the state of CKernelStructuredOutputMachine? Is it just an abstract class for now? | 09:01 |
| @iglesiasg | patrickp, yes | 09:02 |
| @iglesiasg | there is no KernelStructuredOutputMachine implemented so far apart from that class | 09:02 |
| @iglesiasg | that I added a bit for consistency, when I created the LinearStructuredOutputMachine | 09:02 |
| patrickp | is there a point in keeping it? I mean if somebody feels eager to implement it, one could always go back in the git history | 09:03 |
| patrickp | what's the policy of shogun w.r.t. this? | 09:03 |
| @iglesiasg | patrickp, any particular reason why you would like to drop it? | 09:04 |
| hushell | good morning, patrickp and iglesiasg | 09:04 |
| patrickp | also, I find the name LinearStructuredOutputMachine very misleading, in the end all all SVMs are linear (in some space) | 09:04 |
| @iglesiasg | aham | 09:04 |
| lisitsyn | patrickp: that's kind of conventional here | 09:04 |
| lisitsyn | we have KernelMachine and LinearMachine | 09:05 |
| patrickp | I see, cool, then I don't want to mess with that :) | 09:05 |
| lisitsyn | patrickp: our linear is linear like <w,x> in original or explicit space | 09:05 |
| hushell | and seems there is a new branch for latent machines | 09:05 |
| patrickp | lisitsyn: yes, I understand that, it's just that the kernelized version is in some sense also linear (in the primal), but that's just a detail. Never mind | 09:06 |
| lisitsyn | patrickp: yes sure I understand - though we can't make them all linear | 09:07 |
| lisitsyn | implementation-wise I mean | 09:07 |
| patrickp | hushell: not sure you got this: thanks for your PR, great work | 09:08 |
| lisitsyn | bahh have you heard goldbach's conjecture is proven? | 09:08 |
| patrickp | lisitsyn: It's totally fine with me, I was just thinking primal vs. dual machine might be a more natural name | 09:08 |
| hushell | patrickp: I got it! You are welcome. This just the 1st step | 09:08 |
| patrickp | sure | 09:08 |
| lisitsyn | patrickp: oh that's nice suggestion | 09:09 |
| @iglesiasg | I think so too | 09:09 |
| hushell | I updated a new work plan, https://docs.google.com/document/d/1xkJ1N4nV3rJrDJwvp4IdKwGStlmBDbcJdcALarL1tV8/edit#heading=h.44b5ay8ssuhp | 09:09 |
| patrickp | lisitsyn: but probably very intrusive :) | 09:09 |
| patrickp | hushell: I think removing surrogate_loss should be your next mini-pr, or does anybody feel strongly about keeping it? | 09:10 |
| lisitsyn | patrickp: sed uber alles | 09:10 |
| @iglesiasg | yeah, and we would probably lose consistency between SVMs and other machines/classifiers for which primal/dual does not make sense | 09:10 |
| lisitsyn | but yes lets not change that | 09:10 |
| patrickp | iglesiasg: that's probably a good point too | 09:10 |
| @iglesiasg | patrickp, let's see what nico says about the surrogate_loss | 09:10 |
| -!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has quit [Ping timeout: 260 seconds] | 09:11 | |
| @iglesiasg | lisitsyn, http://arxiv.org/abs/1303.4649 this one? | 09:11 |
| patrickp | sure, let's wait a few days, if no answer, or positive, let's remove it | 09:11 |
| hushell | patrickp: I am going to make the factor graph as main task this week | 09:11 |
| @iglesiasg | lisitsyn, haha all integers greater than 362 -- that sounds funny I think :D | 09:11 |
| lisitsyn | iglesiasg: yes | 09:11 |
| lisitsyn | iglesiasg: pure math is so pure | 09:12 |
| @iglesiasg | lisitsyn, I can see you have been studying hard for you philosophy exam :P | 09:12 |
| patrickp | hushell: ambitious first week | 09:12 |
| lisitsyn | iglesiasg: ahh no that's wrong paper | 09:12 |
| lisitsyn | iglesiasg: http://arxiv.org/abs/1305.2897 this one | 09:12 |
| lisitsyn | iglesiasg: yes that's why I failed | 09:13 |
| @iglesiasg | lisitsyn, oh have you already done it? I am sorry :( | 09:13 |
| patrickp | hushell: I know it's not the most rewarding to cleanup the interface, so yeah, try to both at the same time. Probably also gives you an indication where the framework has some weaknesses. | 09:14 |
| lisitsyn | iglesiasg: hah not really failed but can be considered so | 09:14 |
| hushell | patrickp: I mean what I have mentioned in email and last PR | 09:14 |
| patrickp | hushell: sure | 09:14 |
| hushell | patrickp: That's true. The best way to understand it is to modify it | 09:15 |
| patrickp | hushell: any thoughts on moving init_opt, get_num_aux to the machines? | 09:15 |
| @iglesiasg | patrickp, I am not sure if that makes complete sense | 09:16 |
| patrickp | ok, I haven't looked too much into the code, why not? | 09:16 |
| @iglesiasg | patrickp, say I am using the PrimalMosekSOSVM for label sequence learning with the HMSVMModel | 09:17 |
| @iglesiasg | then it could make sense to have some auxiliary labels that ensure smoothness of the functions used to model the observations | 09:17 |
| @iglesiasg | better than ensure, enforce | 09:17 |
| patrickp | let me try to understand this a bit better from the code | 09:18 |
| @iglesiasg | I think this would not make sense in other structured model, say the MulticlassModel or the upcoming one with the factor graph | 09:18 |
| hushell | iglesiasg: but init_opt and risk can be moved to machine classes, isn't it? | 09:18 |
| @iglesiasg | hushell, I am not sure about risk since I have not used it that much | 09:18 |
| patrickp | well, risk might be something we want to keep, but I have to check | 09:19 |
| patrickp | not sure what exactly the use case is | 09:19 |
| @iglesiasg | regarding init_opt I feel a bit like for get_num_aux | 09:19 |
| hushell | risk() only depends on m_features, so if we move m_features to machine classes ... | 09:19 |
| patrickp | and probably the labels, no? | 09:19 |
| @iglesiasg | intuitively I think it makes sense to move the risk | 09:20 |
| hushell | for init_opt(), in multiclass case, it creates a identity matrix while used regularization | 09:20 |
| hushell | I am not sure other places | 09:20 |
| hushell | for multiclass, I think it should be bound with a solver | 09:21 |
| @iglesiasg | IIRC init_opt does quite a bit of things in the HMSVM | 09:21 |
| @iglesiasg | although I doubt it is well designed | 09:21 |
| hushell | let me check :) I just read the main code | 09:22 |
| hushell | iglesiasg: yes, it uses labels features etc for initialization | 09:24 |
| hushell | but in StructuredOutputMachine, we have a reference to structured model | 09:24 |
| @iglesiasg | hushell, what I mean is that init_opt might do things that make sense for the HM-SVM but not for other models | 09:25 |
| @iglesiasg | might do, or is actually doing | 09:25 |
| @iglesiasg | then I see it better bound to the model rather than the machine | 09:25 |
| hushell | my opinion is making StructuredModel as simple as possible | 09:25 |
| @iglesiasg | ok | 09:26 |
| patrickp | hushell: I second that :) | 09:26 |
| @iglesiasg | how would you do these sort of differnt initializations for different models if init_opt is bound to the machine? | 09:26 |
| patrickp | in the optimization: what's the implication of these aux vars? | 09:26 |
| @iglesiasg | patrickp, they are part of the weight vector | 09:26 |
| patrickp | but that means they also have some corresponding elements in phi, no? | 09:27 |
| @iglesiasg | phi = joint feature vector right? | 09:27 |
| patrickp | yes | 09:27 |
| hushell | iglesiasg: I see what you concern, different models may have different initialization | 09:27 |
| @iglesiasg | I normally say psi, just wanted to ensure :) | 09:27 |
| @iglesiasg | patrickp, let me think of it a moment | 09:27 |
| patrickp | normally: psi = the difference of the phis, phi = feature map | 09:28 |
| patrickp | there are of course scenarios, where you want to impose some constraints on the weight vector, that is true | 09:29 |
| @iglesiasg | patrickp, aham ok | 09:29 |
| @iglesiasg | patrickp, according to CHMSVMModel::get_dim() they don't have corresponding elements in phi | 09:29 |
| patrickp | i see, so it's really optimization constraints | 09:29 |
| @iglesiasg | indeed | 09:30 |
| patrickp | hmm, ok, but then maybe we just have a function in all the models that returns the constraints on the weights? | 09:31 |
| hushell | iglesiasg: what are the A B C in the init_opt? | 09:31 |
| patrickp | in general this is a nop, but for HMSVM this actually returns the constraints, in some to be specified format | 09:31 |
| @iglesiasg | hushell, C is the regularization, A and B are the Ax <= B in the constraints of the QP | 09:32 |
| hushell | iglesiasg: ok I saw it in Mosek.h | 09:32 |
| @iglesiasg | patrickp, that would make sense. When you say returns the constraints, you don't mean just the number of them as get_num_aux currently does, do you? | 09:33 |
| @iglesiasg | but also what constraints in the weight vector they actually represent | 09:33 |
| patrickp | no, more something along the lines of your C, A and B | 09:33 |
| @iglesiasg | aham ok | 09:33 |
| patrickp | but these are a bit QP centric, not sure whether there is a better way though to express them | 09:34 |
| patrickp | my concern is anyway, that probably many solvers/machines would have a hard time taking care of the constraints | 09:34 |
| @iglesiasg | yes, I agree | 09:35 |
| hushell | Let's make it clear, init_opt() uses features and labels for constructing / initializing the QP, then it depends on how we would like to design StructuredModel | 09:36 |
| @iglesiasg | I think it would be difficult to handle in other solver that does not solve the QP explicitily as the PrimalMosekSOSVM | 09:36 |
| hushell | if we want to keep features and labels in StructuredModel, we could keep init_opt here | 09:36 |
| hushell | otherwise it is better to move it to StructuredOutputMachine | 09:36 |
| patrickp | sorry, i realize this was a bit ambiguous: it seems that these constraints are about the weight vector. I think this is a model property and hence should be kept in there. | 09:37 |
| patrickp | Now about the implementation: many solvers (say SGD etc) will need special modifications to actually take care of these constraints | 09:38 |
| patrickp | iglesiasg: in hmsvm, do you modify the regularization at all, or is it only about the Ax <= b | 09:39 |
| @iglesiasg | patrickp, there is also a small change in the regularization | 09:39 |
| @iglesiasg | different regularization strength is used for different parts of the vector | 09:39 |
| patrickp | as in: still l2, but different lambda for each component? | 09:40 |
| @iglesiasg | yes | 09:40 |
| @iglesiasg | still l2 | 09:40 |
| hushell | iglesiasg: HMSVM implemented this paper? http://cs.brown.edu/~th/papers/AltTsoHof-ICML2003.pdf | 09:40 |
| @iglesiasg | my lambda is what I called C | 09:40 |
| @iglesiasg | hushell, yes | 09:41 |
| hushell | iglesiasg: Great job! | 09:41 |
| @iglesiasg | hushell, the implementation is based on the hmsvm matlab implementation http://mloss.org/software/tags/hmsvm/ | 09:41 |
| @iglesiasg | so our implementation is a bit different | 09:42 |
| patrickp | ok, so it seems to me that these constraints would be very difficult to handle in all the solvers. | 09:42 |
| @iglesiasg | in the paper they only account for discrete observations | 09:42 |
| @iglesiasg | we have also something to use continuous observations | 09:42 |
| @iglesiasg | patrickp, yes probably | 09:42 |
| @iglesiasg | patrickp, I would very like being able to disable or enable them. For instance, I am afraid the HMSVMModel right now is only usable with the PrimalMosekSOVM | 09:43 |
| * iglesiasg AFK, brb in 5 minutes max | 09:43 | |
| patrickp | so how about this: we keep a method get_additional_constraints() which in some way returns the number of constraints and the A,B,C matrices | 09:44 |
| hushell | iglesiasg: for python, I saw it can be trained by bmrm | 09:44 |
| patrickp | the solvers will then call this function, and decide whether they just error (because they can not handle constraints) or take care of the constraints | 09:45 |
| * iglesiasg back | 09:47 | |
| -!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has joined #shogun | 09:48 | |
| @iglesiasg | patrickp, when you say that it returns the A,B,C you mean the part that is related to the aux constraints | 09:49 |
| @iglesiasg | not the whole A,B,C or? | 09:49 |
| patrickp | yes, for A and B yes | 09:49 |
| patrickp | for C I'm not sure | 09:49 |
| -!- foulwall [~foulwall@2001:da8:215:503:4d40:8c59:6d30:e247] has quit [Remote host closed the connection] | 09:50 | |
| @iglesiasg | ok, and when are these terms initialized in the model, in the constructor or so? | 09:50 |
| patrickp | if i understood correctly: C is the regularization "matrix", so you might want to define this yourself in some situations | 09:50 |
| @iglesiasg | yes | 09:50 |
| patrickp | well, I think we would just have the solver call that special constraint function before doing any work | 09:51 |
| patrickp | if it supports the constraints, say PrimalMosek machine, then it modifies the A,B,C that it would normally use | 09:52 |
| @iglesiasg | ok | 09:52 |
| @iglesiasg | I think it makes sense | 09:52 |
| patrickp | like this we would implement the constraint function in the parent SOModel as returning no constraints whatsoever | 09:53 |
| hushell | patrickp: another related fundemental question, shall we keep features and labels in model? | 09:53 |
| patrickp | and only in HMSVM, we would need to implement this | 09:53 |
| @iglesiasg | patrickp, it sounds good | 09:54 |
| hushell | maybe Factor graph we also need some auxilary variables | 09:54 |
| patrickp | hushell: I would strongly vote for moving them into the machine, but you know the code better than me by now. It just seems the wrong place to have any observations. | 09:54 |
| patrickp | i mean for multi class SOSVM, you know that dim = K*d, for factor graph with the templates we will also be able to infer this without the data | 09:55 |
| hushell | yes, I agree that model should be independent of data and observations | 09:55 |
| @iglesiasg | patrickp, in the hmsvm it might be a bit more involved to do this change | 09:56 |
| @iglesiasg | although I agree with moving features and labels to the machine only | 09:56 |
| hushell | so ideally, we only need user to implement these functions: joint_feat_vector(), argmax(), loss() | 09:57 |
| hushell | all data labels related things move to machine | 09:57 |
| hushell | Am I right? | 09:57 |
| -!- zeller [~zeller@embln.embl.de] has joined #shogun | 09:57 | |
| patrickp | yes, exactly, and after today's discussion, if the user feels like it, he can also implement a constraint generator | 09:57 |
| patrickp | yes, you're right :) | 09:57 |
| @iglesiasg | hi zeller ! | 09:58 |
| zeller | hi fernando! | 09:58 |
| hushell | constraint generator you mean for the case HMSVM | 09:58 |
| @iglesiasg | zeller, lisitsyn : maybe we should move to another chat room so this does not get too confusing with patrickp and hushell's conversation :) | 09:59 |
| lisitsyn | heh sure | 09:59 |
| patrickp | exactly, there might be other models, too. like a sub modular binary model | 09:59 |
| zeller | alrigt | 09:59 |
| lisitsyn | join #lmnn-sucks | 09:59 |
| @iglesiasg | lisitsyn, zeller I have just joined #lmnn | 09:59 |
| lisitsyn | :D | 09:59 |
| @iglesiasg | haha ok | 09:59 |
| @iglesiasg | lmnn-sucks then | 09:59 |
| lisitsyn | oh well | 09:59 |
| lisitsyn | okay | 09:59 |
| lisitsyn | :D | 09:59 |
| hushell | Thanks :D | 09:59 |
| patrickp | hushell: does that roughly make sense? | 10:00 |
| hushell | yes! now I see the big picture | 10:00 |
| hushell | but for the hmsvm may need more eforts to change the current structure | 10:01 |
| patrickp | hushell: next steps: 1. (when we hear back from nico) remove the surrogate loss, 2. resolve the init_opt, aux_vars_* mess. Probably boils down to implementing a constraint generator in model, defaults to do nothing. 3. move labels and features to machine only | 10:01 |
| hushell | I think I can make it this week | 10:01 |
| patrickp | I agree, hmsvm, seems tricky | 10:01 |
| patrickp | but I think in the end it is important that the class design doesn't get too complicated just because of one particular application | 10:02 |
| patrickp | if you can get that fixed this week that would be incredible :), but I see that these are a lot of changes | 10:03 |
| hushell | to make things a bit clear before coding, the constraint generator need to output A B C? | 10:03 |
| patrickp | one last concern i have with the current design is CResults, but I have to understand this a bit better before commenting on it | 10:04 |
| patrickp | hushell: well, I don't fully understand HMSVM just yet. But from iglesiasg 's descriptions the init_opt etc boil down to having specific constraints on the weight vector. | 10:05 |
| patrickp | which as far as I can say is equivalent to specifying an A, B and C | 10:05 |
| hushell | they just keep results in a class: esult = m_model->argmax(m_w, i); | 10:05 |
| hushell | yes, anyway just initialize the QP | 10:06 |
| patrickp | I'd say ideally the signature is something like this: bool constraints(A,B,C) | 10:06 |
| hushell | I will think about how to clean this up | 10:06 |
| patrickp | so, return a bool whether there are any special constraints | 10:07 |
| patrickp | in the machines we would then always call that function and check that it has no special constraints | 10:07 |
| patrickp | if it has we error | 10:07 |
| hushell | this function defined in model? | 10:07 |
| patrickp | yes | 10:07 |
| patrickp | that's a model assumption, I'd say | 10:08 |
| hushell | okay, like a back door | 10:08 |
| hushell | :) | 10:08 |
| patrickp | :) | 10:08 |
| patrickp | which change do you think is easier: features+labels or init_opt? | 10:09 |
| patrickp | I'd start with the easier one | 10:09 |
| hushell | I agree | 10:09 |
| hushell | I am still not fully sure how should modify init_opt, maybe after read HMSVM I get a better sense | 10:10 |
| patrickp | sure, that seems like a difficult one, I would also need to look into the specifics | 10:10 |
| hushell | anyway, all these stuff should be done this week | 10:10 |
| patrickp | :), you're ambitious! | 10:11 |
| hushell | :) according to the plan, we have more difficult things later | 10:11 |
| patrickp | yes, but with these you can start from scratch, this is sometimes easier :) | 10:12 |
| hushell | I hope so | 10:12 |
| pickle27 | lisitsyn, made some good progress tonight! | 10:12 |
| patrickp | and I think the other tasks are achievable | 10:12 |
| lisitsyn | pickle27: oh nice! what's going on? | 10:12 |
| pickle27 | lisitsyn, I started working on a basic main program to test the various methods | 10:13 |
| lisitsyn | pickle27: tomorrow is the interview day for you right? | 10:13 |
| hushell | patrickp: hmm, I need to go to Seatle for 2 days, maybe the next PR will be on Friday | 10:13 |
| pickle27 | I basically borrowed the scikit-learn ICA example but re-wrote it for shogun and my work | 10:13 |
| patrickp | hushell: sure, that's fine. let me know if you have questions | 10:13 |
| pickle27 | so I have a basic synthetic test case ready to go | 10:13 |
| hushell | patrickp: I will keep in touch | 10:14 |
| pickle27 | lisitsyn, well technically tomorrow because its 2 AM here but its really the day after tomorrow | 10:14 |
| hushell | patrickp: How is your visa? | 10:14 |
| lisitsyn | pickle27: hah yes sure | 10:14 |
| patrickp | hushell: still waiting :) | 10:14 |
| pickle27 | lisitsyn, anyways I'm heading to sleep | 10:15 |
| pickle27 | later! | 10:15 |
| lisitsyn | pickle27: sure, see you later! | 10:15 |
| -!- pickle27 [~Kevin@S0106002191dec7e8.cg.shawcable.net] has quit [Quit: Leaving] | 10:15 | |
| patrickp | alright, I'm leaving now, hushell, lisitsyn and iglesiasg thanks for the discussion! | 10:16 |
| lisitsyn | patrickp: I was not really into it sorry! :) | 10:17 |
| lisitsyn | patrickp: see you | 10:17 |
| @iglesiasg | patrickp, thank you! see you | 10:17 |
| -!- patrickp [~patrickp@84-75-165-165.dclient.hispeed.ch] has quit [Quit: patrickp] | 10:17 | |
| hushell | patrickp: see you, have a good day | 10:17 |
| -!- Yantlittle [b74040fc@gateway/web/freenode/ip.183.64.64.252] has joined #shogun | 10:50 | |
| Yantlittle | excuse me, how can i get the combined parameters after running "best_combination=grid_search.select_model(print_state)" ? | 10:51 |
| -!- hushell [~hushell@c-24-21-141-32.hsd1.or.comcast.net] has quit [Quit: WeeChat 0.3.7] | 10:54 | |
| -!- HeikoS [~heiko@nat-180-225.internal.eduroam.ucl.ac.uk] has joined #shogun | 11:38 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 11:38 | |
| -!- iglesiasg [~iglesias@193.147.49.157] has quit [Quit: Saliendo] | 11:40 | |
| Yantlittle | excuse me, how can i get the combined parameters after running "best_combination=grid_search.select_model(print_state)" ? | 11:44 |
| -!- van51 [~van51@athedsl-408350.home.otenet.gr] has joined #shogun | 11:47 | |
| @HeikoS | Yantlittle: combined parameters? | 11:47 |
| @HeikoS | of a kernel? | 11:47 |
| @HeikoS | Yanlittle, you can for example print the parameter tree | 11:48 |
| @HeikoS | or you can apply them to the machine and then read out the parameters | 11:48 |
| Yantlittle | i applied it to a classifier, and the C i can get, but i didn't know how to get the kernel's width | 11:49 |
| @HeikoS | Yantlittle: is it a combined kernel? | 11:49 |
| @HeikoS | or is it a single one? | 11:50 |
| Yantlittle | it is a chi2kernel | 11:50 |
| Yantlittle | a single kernel | 11:50 |
| @HeikoS | Yantlittle: then its easy, apply the best parameters to the underlying machine | 11:50 |
| @HeikoS | and then call get_kernel() of the machine | 11:50 |
| @HeikoS | cast it to the proper type | 11:50 |
| @HeikoS | using obtain_from_generic of the target class | 11:50 |
| @HeikoS | (does type checking) | 11:50 |
| @HeikoS | and then call get_width() on the kernel | 11:51 |
| Yantlittle | get_kernel() is no problem and the next step, how to cast it to the proper type ? | 11:52 |
| -!- zeller [~zeller@embln.embl.de] has left #shogun [] | 11:53 | |
| @HeikoS | is it a Gaussian? | 11:53 |
| Yantlittle | Chi2Kernel | 11:53 |
| @HeikoS | I see, do you know that for sure? (can it be another one or did you only add kernels of this type? | 11:53 |
| Yantlittle | i'm sure. | 11:54 |
| @HeikoS | ok then you can simple do a manual c-style cast | 11:54 |
| @HeikoS | (or dynamic cast) | 11:54 |
| Yantlittle | i just grid search the c and the width | 11:54 |
| @HeikoS | chi_kernel = (Chi2Kernel*) machine->get_kernel() | 11:54 |
| @HeikoS | oh which interface? | 11:54 |
| Yantlittle | python modular | 11:54 |
| @HeikoS | ah I see | 11:55 |
| @HeikoS | then let me write a quick patch for you, since I think its currently not possible from there .... | 11:55 |
| @HeikoS | lisitsyn: do we have a kernel factory that does casts or do we have to add the obtain_from_generic for every single one? | 11:57 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 12:01 | |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 5e55448 / src/shogun/kernel/Chi2Kernel.cpp,src/shogun/kernel/Chi2Kernel.h: https://github.com/shogun-toolbox/shogun/commit/5e554488562defc8f35a9a11c914e2f248bbffdf | 12:01 |
| shogun-notifier- | shogun: added get_width and obtain_from_generic | 12:01 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 8d73e86 / src/shogun/kernel/Chi2Kernel.cpp,src/shogun/kernel/Chi2Kernel.h: https://github.com/shogun-toolbox/shogun/commit/8d73e8652aa2cd121de7b9b4544fdff52e16ff1f | 12:01 |
| shogun-notifier- | shogun: Merge pull request #1175 from karlnapf/develop | 12:01 |
| shogun-notifier- | shogun: | 12:01 |
| shogun-notifier- | shogun: added get_width and obtain_from_generic for Chi2 kernel | 12:01 |
| @HeikoS | Yantlittle: I have added this to the development branch | 12:01 |
| @HeikoS | you can do CChi2Kernel.obtain_from_generic(any_kernel) which returns the proper type, then call get_width | 12:01 |
| Yantlittle | i need to rebuild the shogun? | 12:02 |
| @HeikoS | Yantlittle: yes unfortunately, but only make, not configure | 12:03 |
| @HeikoS | just do a git pull and then make -j 4 | 12:03 |
| @HeikoS | make install | 12:03 |
| Yantlittle | i know now i used the shogun 2.1.0 .. | 12:03 |
| @HeikoS | oh | 12:04 |
| @HeikoS | I see, yes you have to checkout the development branch | 12:04 |
| -!- nube [~rho@116.90.239.3] has quit [Quit: Leaving.] | 12:07 | |
| Yantlittle | i reinstall the shogun may be it's better | 12:07 |
| @HeikoS | Yantlittle: let me know how it goes | 12:08 |
| Yantlittle | ok | 12:08 |
| @HeikoS | lisitsyn, wiking do we have a general solution for this casting problem? Its dull to add these methods for every class | 12:08 |
| @HeikoS | wiking: how are the unit tests going, please give this some priority, otherwise your bagging might crash | 12:08 |
| -!- lambday [67157c4c@gateway/web/freenode/ip.103.21.124.76] has joined #shogun | 12:09 | |
| -!- van51 [~van51@athedsl-408350.home.otenet.gr] has left #shogun ["PART #gsoc-gr :QUIT :Leaving."] | 12:14 | |
| lisitsyn | re | 12:14 |
| lisitsyn | HeikoS: our usability ueber alles | 12:15 |
| lisitsyn | :D | 12:15 |
| lisitsyn | HeikoS: where is the master btw? | 12:16 |
| @HeikoS | lisitsyn: dont know :) | 12:16 |
| @HeikoS | lisitsyn: the obtain_from_generic are the same for any kind of object | 12:16 |
| @HeikoS | every class should have that automagically | 12:16 |
| lisitsyn | HeikoS: oh we need TO THINK HARD to obtain a solution for that.. | 12:16 |
| @HeikoS | can you do some # magic | 12:16 |
| @HeikoS | :) | 12:16 |
| shogun-buildbot | build #949 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/949 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 12:17 |
| lisitsyn | HeikoS: casting is indeed wrong | 12:18 |
| lisitsyn | HeikoS: what is even worse no magic is appliable here I think | 12:18 |
| @HeikoS | lisitsyn: why not, code is always the same | 12:18 |
| @HeikoS | use dynamic cast | 12:18 |
| shogun-buildbot | build #950 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/950 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 12:18 |
| -!- van51 [~van51@athedsl-408350.home.otenet.gr] has joined #shogun | 12:18 | |
| @HeikoS | not these enums | 12:18 |
| @HeikoS | I dont like them anyways ;) | 12:18 |
| lisitsyn | HeikoS: no I mean if we go for casting everything we get a lot of casts | 12:19 |
| lisitsyn | too many | 12:19 |
| lisitsyn | kernel, distance etc | 12:19 |
| lisitsyn | everywhere | 12:19 |
| @HeikoS | so? | 12:19 |
| @HeikoS | every class has to get a method where we just have to replace the class name | 12:19 |
| lisitsyn | HeikoS: don't you think it is a sign of something bad? | 12:21 |
| lisitsyn | HeikoS: well I have a solution in my mind | 12:21 |
| lisitsyn | HeikoS: good there is no master around there | 12:22 |
| lisitsyn | template<typename T> | 12:24 |
| lisitsyn | class A | 12:24 |
| lisitsyn | { | 12:24 |
| lisitsyn | static T* from(CSGObject* sgo) { return dynamic_cast<T>(sgo); } | 12:24 |
| lisitsyn | } | 12:24 |
| lisitsyn | class B : public A<B> | 12:24 |
| lisitsyn | { | 12:24 |
| lisitsyn | } | 12:24 |
| lisitsyn | HeikoS: ^ | 12:24 |
| lisitsyn | CRTP | 12:24 |
| lisitsyn | I don't know how is it applicable to swig | 12:26 |
| lisitsyn | but that's how static polymorphism is reached | 12:26 |
| Yantlittle | x.obtain_from_generic(x).get_width() it says no attribute get_width. | 12:30 |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Ping timeout: 264 seconds] | 12:32 | |
| -!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has joined #shogun | 12:33 | |
| lisitsyn | Yantlittle: Chi2Square.obtain_from_generic(x).get_width() | 12:34 |
| votjakovr | HeikoS: hi! Maybe it's a good idea to ask Oliver about real life application of GPC. What do you think about that? I remember he talked something about using log poisson in bio applications, so probably he has some suggestions | 12:39 |
| Yantlittle | no chi2square | 12:40 |
| lisitsyn | Yantlittle: oh sorry | 12:40 |
| lisitsyn | Chi2Kernel :D | 12:40 |
| Yantlittle | i have used this command the same error | 12:41 |
| @HeikoS | lisitsyn: sounds good to me :) haha | 12:41 |
| @HeikoS | Yantlittle: let me check... | 12:42 |
| @HeikoS | votjakovr: very good idea, I will write him a mail | 12:45 |
| @HeikoS | Yantlittle: it is the static method of Chi2Kernel | 12:45 |
| @HeikoS | that should work | 12:45 |
| @HeikoS | try printing Chi2Square.obtain_from_generic(x).get_name() | 12:46 |
| @HeikoS | to see what instance that is | 12:46 |
| Yantlittle | Chi2Kernel.obtain_from_generic(x).get_name() result : 'Chi2Kernel' | 12:47 |
| @HeikoS | Yantlittle: and then get_width() is not available?? | 12:47 |
| @HeikoS | ok there might be another problem, let me check | 12:48 |
| @HeikoS | votjakovr: how is the GP baseclass business going? | 12:48 |
| Yantlittle | Chi2Kernel.obtain_from_generic(x).get_width() Traceback (innermost last): File "<stdin>", line 1, in <module> AttributeError: 'Kernel' object has no attribute 'get_width' | 12:48 |
| lisitsyn | HeikoS: ha obtain from generic returned kernel | 12:48 |
| @HeikoS | well thats weird since | 12:49 |
| @HeikoS | static CChi2Kernel* obtain_from_generic(CKernel* kernel); | 12:49 |
| @HeikoS | lisitsyn: any ideas? | 12:49 |
| lisitsyn | HeikoS: don't knwo | 12:49 |
| @HeikoS | Yantlittle: could you post your code on gist? | 12:50 |
| @HeikoS | lisitsyn: it would be great to have this automagically, already the 5th time somebody asks about that | 12:51 |
| lisitsyn | HeikoS: CRTP is the solution | 12:51 |
| Yantlittle | wait a moment | 12:52 |
| @HeikoS | lisitsyn: lets try it! :) | 12:52 |
| votjakovr | HeikoS: working on it... | 12:52 |
| lisitsyn | HeikoS: not now though | 12:53 |
| @HeikoS | lisitsyn: okay ;) | 12:53 |
| Yantlittle | https://gist.github.com/anonymous/5804425 here | 12:59 |
| @HeikoS | Yantlittle: checking ... | 13:06 |
| @HeikoS | lisitsyn: my current shogun cannot compile | 13:08 |
| @HeikoS | how with you? | 13:08 |
| lisitsyn | HeikoS: under windows now | 13:09 |
| lisitsyn | let me try | 13:10 |
| @HeikoS | lisitsyn: had some git issues maybe it was that | 13:11 |
| @HeikoS | Yantlittle: sorry for the wait, will check asap | 13:11 |
| @HeikoS | lisitsyn: look like it works now, there were some old files messing thigns up | 13:14 |
| @HeikoS | ah git I love you | 13:14 |
| lisitsyn | HeikoS: that's not git ;) | 13:16 |
| @HeikoS | lisitsyn: it was, related to my failures yesterday ;) | 13:16 |
| lisitsyn | I see | 13:17 |
| lambday | HeikoS: lisitsyn something is wrong with GCDEBUG :-/ | 13:23 |
| lambday | https://gist.github.com/lambday/5804469 | 13:23 |
| @HeikoS | lambday: weird, have you tried SG_DEBUG instead? | 13:24 |
| lambday | HeikoS: yes that's working | 13:24 |
| lambday | but not GC | 13:24 |
| @HeikoS | lambday: could you fill in a bug report then with the example code and assign it to sören? | 13:24 |
| lambday | no idea why! | 13:24 |
| lisitsyn | lambday: whoop | 13:24 |
| lambday | HeikoS: alright | 13:25 |
| lambday | lisitsyn: any clue? :( | 13:25 |
| lisitsyn | lambday: no I don't know | 13:25 |
| lisitsyn | lambday: it happens *only* with gcdebug right? | 13:25 |
| lambday | ya tested with the rest | 13:26 |
| lambday | HeikoS: by filing a bug report, you mean creating an issue, right? (never done this before) | 13:32 |
| Yantlittle | is there any problem? | 13:44 |
| lambday | how do I put a label on an issue? :-/ | 13:46 |
| Yantlittle | now shogun can be used under windows? | 13:51 |
| -!- nube [~rho@49.244.125.191] has joined #shogun | 13:52 | |
| @HeikoS | lambday: yes issue | 14:37 |
| @HeikoS | Yantlittle: sorry I was out for lunch, checking now | 14:37 |
| @HeikoS | (now that shogun is compiled here) | 14:37 |
| @HeikoS | Yantlittle: I dont get this error here, may it be that you haven't re-installed shogun=? | 14:40 |
| @HeikoS | kernel=Chi2Kernel(10, width) | 14:40 |
| @HeikoS | print Chi2Kernel.obtain_from_generic(kernel).get_width() | 14:40 |
| @HeikoS | this works | 14:40 |
| lambday | HeikoS: yes I created one.. not sure how to put label or assign anyone though | 14:43 |
| @HeikoS | just create the issue then,Ill do the rest | 14:44 |
| lambday | HeikoS: https://github.com/shogun-toolbox/shogun/issues/1176 | 14:44 |
| @HeikoS | assigned | 14:47 |
| lambday | HeikoS: :) | 14:49 |
| lambday | HeikoS: I'm writing the classes one by one... CJobResult, CScalarResult and CVectorResult finished... | 14:49 |
| @HeikoS | lambday: very nice | 14:50 |
| lambday | HeikoS: next I'll write the aggregator base class, and then something for the direct log of dense | 14:50 |
| @HeikoS | sounds good | 14:50 |
| lambday | then modify operator and engines.. | 14:50 |
| lambday | HeikoS: one stupid question - say, I test the whole thing and commit each of these classes one by one... is it possible that I push it all to my fork and send PR one per each commit? | 14:51 |
| @HeikoS | canÄt you just send the ones that are done before starting new ones? | 14:52 |
| @HeikoS | if not, you can create some local branches to manage that | 14:52 |
| @HeikoS | if this is all too annoying, just send the full thing | 14:52 |
| lambday | HeikoS: that would be a bit problematic for reviewing :( I understand.. okay I'll send PRs for the ones that are already done | 14:54 |
| lambday | HeikoS: sending one now then.. check if the documentation you wanted me to fix seems okay :) | 14:54 |
| @HeikoS | lambday: yep | 14:55 |
| @HeikoS | lambday: its very good to push things as soon as they are working | 14:55 |
| @HeikoS | no need in piling stuff up | 14:55 |
| @HeikoS | small steps are better | 14:55 |
| lambday | HeikoS: yes :) | 14:56 |
| lambday | just sent.. | 14:56 |
| lambday | brb | 14:58 |
| -!- van51 [~van51@athedsl-408350.home.otenet.gr] has quit [Quit: Leaving.] | 14:59 | |
| @HeikoS | lambday: is there a reason why you put everything in .h files only? | 15:03 |
| lambday | HeikoS: no.. its just, they are too small.. | 15:03 |
| lambday | I wasn't sure if I should make separate cpp for these | 15:04 |
| @HeikoS | lambday: yeah make one, otherwise one has to recompile all dependent classes if implementation is changed | 15:04 |
| lambday | HeikoS: okay.. changing then.. the base class in .h is fine though, right? | 15:05 |
| @HeikoS | yep | 15:05 |
| @HeikoS | lambday: ah wait | 15:06 |
| @HeikoS | in fact | 15:06 |
| @HeikoS | the results can stay in h | 15:06 |
| @HeikoS | I confused something | 15:06 |
| lambday | HeikoS: since these had just one get_result method, so I thought it would be okay | 15:06 |
| @HeikoS | thought there was an aggregator class also | 15:06 |
| @HeikoS | but there isnt | 15:06 |
| @HeikoS | so its fine | 15:06 |
| lambday | HeikoS: hmm.. okay then | 15:06 |
| @HeikoS | rest is fine, I would remove the init flag, but thats up to you | 15:07 |
| lambday | HeikoS: that I put in case someone uses the no-arg constructor and then tries get_results with it.. that gives error.. so thought a warning would be nice.. but ya.. looks unnecessary :-/ | 15:08 |
| @HeikoS | lambday: why should that happen? | 15:08 |
| lambday | ideally, should not! | 15:09 |
| @HeikoS | this means that the job returns new BlaResult() | 15:09 |
| @HeikoS | but if someone does that, its kind of weird anyways | 15:09 |
| @HeikoS | so my point is, thats a development error then, no user error | 15:09 |
| lambday | HeikoS: yup | 15:09 |
| @HeikoS | so we do not need to protect users from that | 15:09 |
| lambday | yeah its better to drop that | 15:09 |
| Yantlittle | hey, it's strange, i reinstall shogun again now it work!!! what's the warning "oid shogun::CMulticlassStrategy::register_parameters(): MulticlassStrategy::CMulticlassStrategy(): register parameters!" | 15:11 |
| lambday | HeikoS: changed | 15:13 |
| @HeikoS | merged :) | 15:14 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 15:14 | |
| shogun-notifier- | shogun: lambday :develop * b019018 / src/shogun/ (4 files): https://github.com/shogun-toolbox/shogun/commit/b019018843af6218904f04bfb28a7af25105cfc8 | 15:14 |
| shogun-notifier- | shogun: CJobResult added, CDenseMatrixOperator documentation extended | 15:14 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * dae693c / src/shogun/ (4 files): https://github.com/shogun-toolbox/shogun/commit/dae693c9d4accaf9bdbbc9475b05a2ac35b8766c | 15:14 |
| shogun-notifier- | shogun: Merge pull request #1177 from lambday/feature/log_determinant | 15:14 |
| shogun-notifier- | shogun: | 15:14 |
| shogun-notifier- | shogun: CJobResult added, CDenseMatrixOperator documentation extended | 15:14 |
| lisitsyn | HeikoS: ooh man again template classes! | 15:16 |
| @HeikoS | lisitsyn: whats the alternative here? | 15:16 |
| lisitsyn | HeikoS: I don't see any | 15:17 |
| @HeikoS | we need two versions of the same thing | 15:17 |
| @HeikoS | complex and float64 | 15:17 |
| lisitsyn | HeikoS: just crying because of increased compile time | 15:17 |
| shogun-buildbot | build #951 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/951 blamelist: lambday <heavensdevil6909@gmail.com> | 15:18 |
| Yantlittle | ...when I run classifier=MulticlassLibSVM(), there is a warning "RuntimeWarning:void --shogun::CMulticlassOneVsOneStrategy::register_parameters" did any body know what's the problem? | 15:19 |
| lambday | lisitsyn: not many classes will be template for our purpose :( just 4-5 more | 15:19 |
| lisitsyn | lambday: 5 template classes is equal to 70 new classes for swig :) | 15:21 |
| lambday | :( :( no other way :( | 15:21 |
| @HeikoS | lisitsyn: well we dont need them all | 15:22 |
| lisitsyn | HeikoS: I am eager to find some alternative | 15:22 |
| @HeikoS | lambday, lisitsyn when adding interfaces, we will only add Real and Complex for now | 15:22 |
| lisitsyn | HeikoS: opencv guys solved it their own way | 15:22 |
| @HeikoS | lisitsyn: in fact, we dont even need to interface them since only internals | 15:22 |
| @HeikoS | so no problem here | 15:23 |
| lisitsyn | HeikoS: I want to get rid of template classes everywher | 15:23 |
| lisitsyn | :D | 15:23 |
| lambday | HeikoS: yes.. | 15:23 |
| @HeikoS | use java :D | 15:23 |
| lisitsyn | HeikoS: how java helps here? | 15:24 |
| @HeikoS | no templates | 15:24 |
| lisitsyn | well but generics? | 15:24 |
| @HeikoS | doent help here at all | 15:24 |
| @HeikoS | just a stupid comment ;) | 15:24 |
| @HeikoS | generics are not templates | 15:24 |
| @HeikoS | they work differently | 15:24 |
| lambday | in runtime? | 15:24 |
| @HeikoS | lets not get into this, I take my comment back ;) | 15:25 |
| lisitsyn | HeikoS: I hope you didn't tell me what generics are ;) | 15:25 |
| @HeikoS | lambday: btw http://www.ucl.ac.uk/roulette | 15:26 |
| @HeikoS | public | 15:26 |
| lambday | aaah! :D let me check | 15:26 |
| lambday | I'm gonna be famous among my friends :D | 15:27 |
| @HeikoS | yeah :) | 15:27 |
| lisitsyn | HeikoS: german visa is here! | 15:27 |
| lambday | HeikoS: by the way, in the next meeting, do we have to give a write up or just have to say what we're planning to do? (as in, in irc chat) | 15:28 |
| @HeikoS | lisitsyn: yeah :) | 15:28 |
| @HeikoS | lambday: just very informal | 15:28 |
| @HeikoS | irc | 15:28 |
| lisitsyn | HeikoS: thankfully with no need to visit embassy | 15:28 |
| @HeikoS | it good to prepare something, but not too much or too sophisticated | 15:28 |
| @HeikoS | lisitsyn: nice! | 15:28 |
| lisitsyn | HeikoS: if they take me to mentor summit I'll start messing with usa visa in august | 15:29 |
| lambday | alright.. I will start then.. if I write something up I'll mail you | 15:29 |
| lisitsyn | otherwise I am out :D | 15:29 |
| lisitsyn | HeikoS: btw we could share the same plane london - sfo | 15:30 |
| @HeikoS | lisitsyn: good luck with that | 15:30 |
| @HeikoS | lisitsyn: yea, I havent booked flights yet, so lets talk about that then | 15:30 |
| @HeikoS | lambday: just a few sentences | 15:30 |
| lambday | HeikoS: okie | 15:30 |
| lisitsyn | HeikoS: well I can't book before anything is decided so unclear | 15:30 |
| @HeikoS | overview of what you are doing, what are the plans for upcoming weeks, what the real life exaple is | 15:30 |
| lisitsyn | HeikoS: but still I'd probably have to flight through heathrow | 15:31 |
| @HeikoS | but for that, you can share the ozone link and say we compute likelihoods in *massive* Gaussian Markov Random Field models | 15:31 |
| @HeikoS | lisitsyn: yep that might be | 15:31 |
| @HeikoS | lisitsyn: or you go the other way round the globe? | 15:31 |
| lisitsyn | HeikoS: haha hah | 15:31 |
| lisitsyn | you should check da map! | 15:31 |
| lisitsyn | ;) | 15:32 |
| @HeikoS | maybe ;) | 15:33 |
| shogun-buildbot | build #952 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/952 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 15:39 |
| shogun-buildbot | build #1108 of deb2 - static_interfaces is complete: Failure [failed test octave_static] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb2%20-%20static_interfaces/builds/1108 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 15:40 |
| lambday | error!! | 15:43 |
| @HeikoS | lambday: dont worry | 15:53 |
| @HeikoS | its perceptron stuff | 15:53 |
| @wiking | errorSKI | 15:53 |
| @HeikoS | wiking: hi! :) | 15:53 |
| @wiking | yo | 15:53 |
| @HeikoS | wiking: ready to be harrassed about unit tests for cloning? :D | 15:53 |
| @wiking | heheheh | 15:54 |
| @wiking | i'm on a trip back home since 22:30 last night | 15:54 |
| @wiking | atm i'm waiting for my transfer at dusseldorf airport ;) | 15:54 |
| @HeikoS | wiking: ah nice | 15:54 |
| @HeikoS | greetings to Germany! :) | 15:54 |
| @wiking | i'm destroyed :) | 15:54 |
| @HeikoS | wiking: no excuses! | 15:54 |
| @HeikoS | !!!!!!!! | 15:54 |
| @HeikoS | :D | 15:54 |
| @wiking | still need like 1.5 hours to catch the next flight | 15:55 |
| @HeikoS | all best for your trip ! | 15:55 |
| @wiking | and then around 19:30 i arrive | 15:55 |
| @wiking | and then i should still catch a train at 22:30 :P | 15:55 |
| @wiking | that should arrive around 2:30am | 15:55 |
| @wiking | :D | 15:55 |
| @wiking | hence this is a nice 28 hours trip :P | 15:55 |
| @HeikoS | man | 15:58 |
| @HeikoS | too much | 15:58 |
| @wiking | heheh yeah | 15:59 |
| @wiking | i did this sorts of things but not within eu :P | 15:59 |
| @wiking | when i first flew to australia it was like 35 hours :P | 15:59 |
| Yantlittle | ... | 16:00 |
| Yantlittle | welcome to china | 16:01 |
| @HeikoS | Yantlittle: any luck with the get_width() ? | 16:26 |
| -!- lisitsyn [~lisitsin@mxs.kg.ru] has quit [Ping timeout: 248 seconds] | 16:45 | |
| -!- lisitsyn [~lisitsin@mxs.kg.ru] has joined #shogun | 16:57 | |
| -!- van51 [~van51@athedsl-408350.home.otenet.gr] has joined #shogun | 17:03 | |
| Yantlittle | yeah it can get the width. but when run the classifier=MulticlassLibSVM(), it says runtime warning. what's the meaning ? | 17:14 |
| Yantlittle | excuse me . | 17:16 |
| @HeikoS | whats the exact warning? | 17:23 |
| Yantlittle | RuntimeWarning: void shogun::CMulticlassStrategy::register_parameters(): MulticlassStrategy::CMulticlassStrategy(): register parameters! | 17:25 |
| Yantlittle | shogun 2.1.0 have not the warning . | 17:28 |
| @HeikoS | Yantlittle: dont worry about this one, its internal stuff | 17:29 |
| Yantlittle | ok. | 17:30 |
| -!- lisitsyn [~lisitsin@mxs.kg.ru] has quit [Quit: Leaving.] | 17:35 | |
| -!- Yantlittle [b74040fc@gateway/web/freenode/ip.183.64.64.252] has quit [Quit: Page closed] | 17:56 | |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 18:14 | |
| votjakovr | HeikoS: i think we probably need to reorganize file hierarchy, since we'll use inference methods, mean functions, likelihood models, etc not only for regression | 18:30 |
| @HeikoS | votjakovr: I agree | 18:31 |
| @HeikoS | votjakovr: suggestions? | 18:31 |
| @HeikoS | I suggest the following: add a gp folder in shogun/machine/ | 18:31 |
| @HeikoS | which contains all the base class stuff | 18:32 |
| @HeikoS | and then have a gp subfolder in each classifier and regression, where we put the implementations | 18:32 |
| @HeikoS | so all the mean functions, and base classes go to machine/gp | 18:33 |
| @HeikoS | the regression specific inference methods/likelihoods go to regression/gp | 18:33 |
| @HeikoS | the classification specific inference methods/likelihoods etc go to classifier/gp | 18:34 |
| @HeikoS | votjakovr: let me know what you think | 18:34 |
| @HeikoS | votjakovr: also I would rename the Inference method ExactInferenceMethod ->ExactRegressionInferenceMethod | 18:36 |
| @HeikoS | in fact I would call it ExactRegressionInference (without method) | 18:36 |
| @HeikoS | and then LaplacianInferenceMethod ->LaplacianRegressionInference | 18:36 |
| votjakovr | HeikoS: and what about inference methods, which are used both classification and regression? | 18:37 |
| @HeikoS | votjakovr: those parts should be pulled out as base classes and put under machine/gp | 18:37 |
| @HeikoS | so if they contain regression/classification specific parts, these go into subclasses | 18:38 |
| @HeikoS | so for example Laplace could be | 18:38 |
| @HeikoS | LaplaceApproximation (base class) | 18:38 |
| @HeikoS | with subclasses LaplacianRegressionInference and LaplacianClassificationInference | 18:38 |
| @HeikoS | votjakovr: but actually, it might be not even necessary since inference methods just compute posterior of GP | 18:39 |
| @HeikoS | votjakovr: so lets change it a little bit | 18:40 |
| @HeikoS | inference methods also go to machine/gp | 18:40 |
| @HeikoS | for both classification and regresseion | 18:40 |
| @HeikoS | and the likelihoods also go to machine/gp | 18:40 |
| @HeikoS | just the GP subclasses go to classifier/ and regression | 18:40 |
| @HeikoS | I think thats better | 18:40 |
| @HeikoS | and inference methods dont have base classes (apart from CInferenceMethod) but rather check whether they can deal with the provided likelihood | 18:41 |
| @HeikoS | do you think thats sensible? | 18:41 |
| votjakovr | HeikoS: i think, that for user it's better to locate all stuff (inference methods, likelihoods, etc) somewhere in one place (machine/gp/ or probably simple gp/), but classifiers and regression should be in classifier/ and regression/ dirs | 18:46 |
| votjakovr | HeikoS: base class (GPMachine) should be in machine/ | 18:47 |
| @HeikoS | votjakovr: yep, thats the last thing I said :) | 18:47 |
| @HeikoS | yes, that sounds good | 18:47 |
| @HeikoS | then add a directory machine/gp/ for all the stuff | 18:48 |
| @HeikoS | votjakovr: that works well, later on, we will have multiclass | 18:48 |
| @HeikoS | go into multiclass folder | 18:48 |
| @HeikoS | we will document all this later on .... | 18:48 |
| votjakovr | HeikoS: ah yep :) | 18:49 |
| votjakovr | HeikoS: it should be very useful to describe shogun dirs | 18:50 |
| @HeikoS | votjakovr: I agree, we will produce documentation later, dont worry about that for now | 18:50 |
| @HeikoS | just document the classes properly :) | 18:50 |
| @HeikoS | votjakovr: it might also be sensible to add an enum to the likelihoods and inference methods, which tell whether something can be used with regression/classification/multiclass or combinations of them | 18:53 |
| @HeikoS | so that the GP machines later can check whether their members are legal | 18:54 |
| votjakovr | HeikoS: but now we can check this by type of inference or likelihood | 18:57 |
| @HeikoS | votjakovr: we could for example add a method bool supports_regression()=0; which has to be implemented | 18:58 |
| @HeikoS | same for classification and multiclass | 18:58 |
| @HeikoS | and the GP machine then calls this method as a check | 18:58 |
| @HeikoS | votjakovr: they dont have to be pure virtual even | 19:02 |
| @HeikoS | just add virtual bool supports_regression() { return false; } to all base class of inference and overload in implementations | 19:03 |
| @HeikoS | same for classification | 19:03 |
| @HeikoS | votjakovr: see what I mean? | 19:04 |
| votjakovr | HeikoS: make something like apply_...() methods for machines | 19:05 |
| votjakovr | HeikoS: but for supports_...() | 19:05 |
| @HeikoS | votjakovr: I am not following you | 19:05 |
| @HeikoS | apply_ have to be implemented for the GP sub-classes | 19:06 |
| @HeikoS | depending on what the machine can do | 19:06 |
| @HeikoS | but since we pass inference methods to the GP machine, it is possible to pass say a regression inference method to a classification GP machine, we want to avoid that. That is why the classification GP machine then can call inference_method->supports_classification() and gets a false. Then, an error can be thrown | 19:07 |
| votjakovr | HeikoS: Ah, yep, i'll do that :) | 19:08 |
| @HeikoS | votjakovr: ok nice, how long do you think it will take you? | 19:08 |
| @HeikoS | votjakovr: I really would like to finish this re-factoring stuff asap so that we can start coding the classification things | 19:08 |
| votjakovr | HeikoS: probably 1-2 days, i'll also need to check all examples, tests, etc... I'd also like to start classification, but we need to deal with re-factoring stuff first | 19:13 |
| @HeikoS | votjakovr: I agree that this should be finished first. The refactoring should be done fairly quickly, doesnt take more than a few hours. Checking examples and tests is crucial too, but again its only moving stuff around so shoudnt take too long. | 19:14 |
| votjakovr | HeikoS: Ok, i'll try to quickly finish it :) | 19:16 |
| @HeikoS | votjakovr: nice :) let me know the status from time to time | 19:16 |
| @HeikoS | votjakovr: I warned you, 24h google surveillance after GSoC start ;) | 19:17 |
| votjakovr | HeikoS: i'm just curious, how do they do that? | 19:19 |
| @HeikoS | votjakovr: they use nano-robots in your brain to measure how many thoughts are about c++ | 19:20 |
| @HeikoS | votjakovr: all in real time | 19:20 |
| votjakovr | HeikoS: :D | 19:20 |
| -!- lisitsyn [~lisitsyn@83.234.169.173] has joined #shogun | 19:28 | |
| votjakovr | HeikoS: yep, you're right, i'll do that much quickly | 19:37 |
| @HeikoS | votjakovr: nice, keep me updated then! | 19:38 |
| @HeikoS | votjakovr: would be great if its done tomorrow and we can talk a little bit about logit Laplace classifier | 19:42 |
| votjakovr | HeikoS: Ok | 19:44 |
| lisitsyn | HeikoS: did you put yourself to the waiting list? | 19:49 |
| @HeikoS | votjakovr: btw on the IRC meeting, you should mention that you unit-tested most of the framework, and that it did not really work before, and that you made the structure much simpler yet flexible | 19:50 |
| lisitsyn | of mentor summit | 19:50 |
| @HeikoS | lisitsyn: yes accident, told carol to ignore | 19:50 |
| lisitsyn | HeikoS: oops it seems she forgot | 19:50 |
| lisitsyn | she just contacted me and soeren | 19:50 |
| lisitsyn | I'll tell her you and soeren are going to be registered and I am on the waiting list | 19:50 |
| @HeikoS | lisitsyn: strange, she replied to me, let me forward you the mail | 19:51 |
| @HeikoS | lisitsyn: check your mail | 19:51 |
| lisitsyn | HeikoS: may be it is someone else? | 19:52 |
| lisitsyn | :D | 19:52 |
| votjakovr | HeikoS: oh yep, i'll do that | 19:54 |
| lisitsyn | HeikoS: I told she about your accidental filling the form | 19:54 |
| lisitsyn | but asked to tell us if it is someone else | 19:55 |
| lisitsyn | HeikoS: we didn't plan any other attendees did we? | 19:55 |
| @HeikoS | nope | 19:55 |
| lisitsyn | HeikoS: I told that the plan is she soeren, you + me | 19:55 |
| lisitsyn | ehm | 19:55 |
| @HeikoS | lisitsyn: told her :) | 19:56 |
| lisitsyn | HeikoS: oops | 19:56 |
| lisitsyn | :D | 19:56 |
| lisitsyn | HeikoS: my language gets broken w/o much sleep | 19:56 |
| lisitsyn | HeikoS: anyway | 19:56 |
| lisitsyn | HeikoS: that's strange absense of the master | 19:58 |
| @HeikoS | lisitsyn: well .... | 19:59 |
| @HeikoS | lisitsyn: we should soon talk about the workshop | 19:59 |
| @HeikoS | possibly tomorrow before evening | 20:00 |
| @HeikoS | since I am away afterwards | 20:00 |
| lisitsyn | HeikoS: oh that's benoit rostykus | 20:00 |
| lisitsyn | :D | 20:00 |
| lisitsyn | HeikoS: surprising? | 20:03 |
| lisitsyn | :D | 20:03 |
| @HeikoS | lisitsyn: what? | 20:04 |
| lisitsyn | HeikoS: the two persons on the waiting list is | 20:04 |
| lisitsyn | me and benoit rostykus | 20:04 |
| @HeikoS | who is that? | 20:04 |
| lisitsyn | HeikoS: lol | 20:05 |
| @HeikoS | random guy? | 20:05 |
| lisitsyn | HeikoS: no, kind of mentor of van51 | 20:05 |
| @HeikoS | lisitsyn: really? | 20:05 |
| @HeikoS | I see | 20:05 |
| @HeikoS | well yeah sören said, apply to the list | 20:05 |
| lisitsyn | HeikoS: maybe he did notify soeren about that | 20:06 |
| votjakovr | btw will you make a video from workshop? | 20:07 |
| lisitsyn | votjakovr: german video yeah | 20:07 |
| lisitsyn | ;) | 20:07 |
| votjakovr | lisitsyn: haha :D | 20:08 |
| votjakovr | i'm looking forward to watch it | 20:10 |
| lisitsyn | HeikoS: could you please register as a participant to avoid carol's confusion? | 20:10 |
| @HeikoS | lisitsyn: sure where? | 20:22 |
| lisitsyn | HeikoS: ehmm I thought you know! :D let me find | 20:22 |
| @HeikoS | lisitsyn, votjakovrno we will probably talk in english | 20:22 |
| -!- nube [~rho@49.244.125.191] has quit [Quit: Leaving.] | 20:23 | |
| @HeikoS | votjakovr: btw if you want, you can contribute an example that I present at the workshop (for regression) | 20:23 |
| lisitsyn | HeikoS: probably? | 20:23 |
| lisitsyn | ;) | 20:23 |
| lisitsyn | HeikoS: pm'ed you | 20:25 |
| @HeikoS | lisitsyn: done, thanks :) | 20:26 |
| votjakovr | HeikoS: wow, cool! I'll think about that | 20:27 |
| @HeikoS | votjakovr: like a big example (interactive) with modelselection and sparse regression | 20:27 |
| -!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has quit [Ping timeout: 240 seconds] | 21:03 | |
| -!- HeikoS [~heiko@nat-180-225.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.] | 21:26 | |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 21:46 | |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * 1f705d4 / src/configure: https://github.com/shogun-toolbox/shogun/commit/1f705d4baba8f87fa007b220191f229edf9b539a | 21:46 |
| shogun-notifier- | shogun: require json-c version >=11 | 21:46 |
| shogun-notifier- | shogun: | 21:46 |
| shogun-notifier- | shogun: in version 0.10 json_object_get_int is b0rken causing shogun | 21:46 |
| shogun-notifier- | shogun: serialization / tests to fail | 21:46 |
| -!- lisitsyn [~lisitsyn@83.234.169.173] has quit [Quit: Leaving.] | 21:51 | |
| shogun-buildbot | build #1121 of bsd1 - libshogun is complete: Failure [failed test_1] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1121 blamelist: Soeren Sonnenburg <sonne@debian.org> | 21:59 |
| shogun-buildbot | build #953 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/953 blamelist: Soeren Sonnenburg <sonne@debian.org> | 22:04 |
| shogun-buildbot | build #1109 of deb2 - static_interfaces is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb2%20-%20static_interfaces/builds/1109 | 22:06 |
| -!- travis-ci [~travis-ci@ec2-54-242-24-102.compute-1.amazonaws.com] has joined #shogun | 22: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/8210341 | 22:32 |
| -!- travis-ci [~travis-ci@ec2-54-242-24-102.compute-1.amazonaws.com] has left #shogun [] | 22:32 | |
| -!- lambday [67157c4c@gateway/web/freenode/ip.103.21.124.76] has quit [] | 22:46 | |
| -!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has left #shogun ["Fallen asleep!"] | 22:50 | |
| -!- zxtx [~zv@rrcs-74-62-200-195.west.biz.rr.com] has joined #shogun | 22:53 | |
| -!- van51 [~van51@athedsl-408350.home.otenet.gr] has quit [Quit: Leaving.] | 23:09 | |
| --- Log closed Wed Jun 19 00:00:51 2013 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!