1 |
On Mon, 2011-03-21 at 20:27 -0500, Donnie Berkholz wrote: |
2 |
> On 16:56 Mon 21 Mar , Brian Dolbec wrote: |
3 |
> > There is an app called shogun-toolbox http://www.shogun-toolbox.org/ |
4 |
> > |
5 |
> > that is designed specifically for machine learning. It has many |
6 |
> > interface capabilities including python (which they state has the most |
7 |
> > complete documentation). There is also many examples for it's use. |
8 |
> > |
9 |
> > I personally don't know nearly enough about it to know what modeling |
10 |
> > methods might be suitable or even if there is one suitable for this |
11 |
> > type of model. But I think should be investigated. Implemented this |
12 |
> > would have the potential to increase it's success rate over time, |
13 |
> > reducing developer load even more. |
14 |
> |
15 |
> This sounds like something that might be beyond a GSoC project to |
16 |
> develop a standalone code base. It would probably work better next year |
17 |
> as an enhancement, if this year's project to build an initial working |
18 |
> application worked out well. |
19 |
|
20 |
Absolutely. But I wanted to get the thought out there. Then maybe this |
21 |
years code could be designed to be easier to upgrade it's AI next year. |
22 |
|
23 |
|
24 |
> |
25 |
> What I would do instead is a "smart" detection using things like |
26 |
> flex/bison/pybison. You could first detect the buildsystem type |
27 |
> (autotools/cmake/distutils/etc) based on file existence. Then you would |
28 |
> parse the build files using the syntax described for your lexical |
29 |
> analyzer/parser to build a basic understanding of what build-time |
30 |
> options are available and offer them as USE flags. You could also do |
31 |
> similar things to detect dependencies by understanding their syntax in |
32 |
> the source code. |
33 |
> |
34 |
|
35 |
Yes there are several areas that a machine learning system could be |
36 |
beneficial in this whole process. Some of which are listed as other |
37 |
project ideas this year. |
38 |
|
39 |
-- |
40 |
Brian Dolbec <brian.dolbec@×××××.com> |