--- Log opened Sat Oct 15 00:00:51 2011 | ||
-!- blackburn [~blackburn@188.168.4.209] has quit [Quit: Leaving.] | 00:16 | |
-!- blackburn [~blackburn@188.168.5.120] has joined #shogun | 10:43 | |
blackburn | sonney2k: I think we should release 1.0.0.1 or so? | 10:43 |
---|---|---|
blackburn | or 1.0.1 | 10:43 |
blackburn | cause 1.0.0 is too bad to package | 10:44 |
CIA-3 | shogun: Sergey Lisitsyn * rdb0d2a4 / examples/undocumented/python_modular/graphical/lle_auto_k.py : Fixed lle_auto_k python graphical example - http://git.io/OF7GEw | 10:47 |
shogun-buildbot | build #214 of ruby_modular is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/ruby_modular/builds/214 | 11:08 |
@sonney2k | blackburn, but we changed too much didn't we? | 13:30 |
blackburn | sonney2k: in comparison to what? | 13:31 |
@sonney2k | I think we need to get octave_modular examples to work too | 13:31 |
@sonney2k | there are 2 still crashing | 13:31 |
blackburn | yeah we should get all the things work | 13:31 |
blackburn | and release 1.0.1 | 13:31 |
blackburn | and then start packaging again | 13:31 |
blackburn | 1.0.0 have some critical things (like arpack compile error reported today again) | 13:32 |
@sonney2k | I would call it 1.1 | 14:07 |
@sonney2k | but I would prefer that we have osx/ cygwin working too before we release | 14:07 |
@sonney2k | note that you changed preprocessors completely (converters ...) | 14:07 |
@sonney2k | so it is certainly no longer a bugfix release | 14:07 |
@sonney2k | the alternative of course is to do a 1.0.1 with lots of small install / bugfixes only | 14:08 |
@sonney2k | but that is quite some work too (figuring out all the missing patches + testing) | 14:12 |
@sonney2k | so I prefer a 1.1 release | 14:12 |
@sonney2k | blackburn, btw I tried to do the .cxx splitting | 14:12 |
@sonney2k | it is easy when splitting the file in two halves to compile just the first halve | 14:12 |
@sonney2k | but the second *uh* *oh* | 14:13 |
@sonney2k | this cries for some automated magic | 14:13 |
@sonney2k | with putting defines or so in headers; repeat static functions; extern other used globabl functions | 14:13 |
blackburn | sorry was away | 14:30 |
blackburn | sonney2k: that's a lot of work to do.. (about .cxx) | 14:33 |
@sonney2k | blackburn, yes I know... | 21:32 |
@sonney2k | but I guess it cannot really be avoided | 23:10 |
@sonney2k | maybe a python helper script can do the job | 23:11 |
@sonney2k | I might underestimate its complexity though... | 23:11 |
@sonney2k | I would probably proceed by defining some list of function/struct/... names, and a dictionary of function/struct// names with the name as key and the content as value | 23:12 |
@sonney2k | and then annotate things with static / whatever | 23:12 |
blackburn | sonney2k: I guess yes, you underestimate | 23:13 |
@sonney2k | and then try to traverse the file in order and add header files for functions that are defined non-static | 23:13 |
@sonney2k | and put them all in the .h | 23:13 |
@sonney2k | and for static ones put them in both | 23:13 |
@sonney2k | blackburn, how do you know | 23:14 |
@sonney2k | ? | 23:14 |
blackburn | just think so | 23:14 |
@sonney2k | I mean it would be nice to have a splitcpp.py anyways or? | 23:15 |
blackburn | sure, I hope this can be done | 23:15 |
@sonney2k | I mean swig uses no templates | 23:15 |
@sonney2k | it is more C style | 23:15 |
blackburn | template<typename T> class SwigValueWrapper { | 23:16 |
blackburn | ??? | 23:16 |
@sonney2k | so all it can do are functions/structs/classes/defines | 23:16 |
@sonney2k | heh | 23:16 |
@sonney2k | indeed | 23:16 |
blackburn | sonney2k: do you know virtual can't be inlined? | 23:17 |
@sonney2k | no | 23:17 |
@sonney2k | where can I find that info? | 23:18 |
blackburn | http://stackoverflow.com/questions/733737/are-inline-virtual-functions-really-a-non-sense | 23:18 |
@sonney2k | so they are inlined most of the time | 23:20 |
blackburn | I don't know exactly | 23:21 |
@sonney2k | well if the type is know which it is when we do e.g. CGaussianKernel k | 23:22 |
@sonney2k | k->get_name() | 23:22 |
blackburn | sonney2k: well that's not a serious trouble anyway | 23:22 |
blackburn | we have a lot of other overhead | 23:22 |
@sonney2k | I don't think we have much overhead | 23:23 |
@sonney2k | actually close to no overhead :) | 23:23 |
blackburn | okay, in means of large-scale | 23:23 |
blackburn | calling another function one more time is not that bad | 23:24 |
blackburn | sonney2k: had you throwed away that python buffer integration? | 23:25 |
@sonney2k | I never wrote it | 23:25 |
@sonney2k | bug #1 is now memory requirements for me | 23:26 |
@sonney2k | for compiling | 23:26 |
blackburn | I mean did you stop working on it? | 23:26 |
blackburn | well yes it is much more important now | 23:27 |
@sonney2k | for now yes, bugs have highest prio as well as user reports | 23:27 |
@sonney2k | then wrapper splitting somehow | 23:27 |
@sonney2k | and then new features | 23:27 |
blackburn | av3ngr suffered with strange bug | 23:27 |
blackburn | I've recommended to clean git, etc | 23:28 |
blackburn | nothing helped | 23:28 |
@sonney2k | yeah but I have no idea for that either. no one has this... | 23:29 |
@sonney2k | anyway bed time | 23:29 |
blackburn | oh | 23:29 |
blackburn | okay | 23:29 |
blackburn | wrote some question to you and erased :D | 23:29 |
blackburn | I probably will try to do some MKL with images classification | 23:30 |
blackburn | as my bachelor's 'work' | 23:30 |
@sonney2k | not sure if MKL is that useful ... | 23:31 |
blackburn | sonney2k: that's bad | 23:35 |
blackburn | sonney2k: well that was a question, do you know any success of MKL? | 23:36 |
--- Log closed Sun Oct 16 00:00:56 2011 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!