| 1 |
On 23:34 Tue 22 Mar , Brian Dolbec wrote: |
| 2 |
> On Tue, 2011-03-22 at 18:49 +0100, darkdefende@×××××.com wrote: |
| 3 |
> > Brian Dolbec writes: |
| 4 |
> > > Absolutely. But I wanted to get the thought out there. Then |
| 5 |
> > > maybe this years code could be designed to be easier to upgrade |
| 6 |
> > > it's AI next year. |
| 7 |
> > |
| 8 |
> > I have never written anything related to AI code generation before |
| 9 |
> > so I don't really know how I would design the code to be easily |
| 10 |
> > modified to support this. If there any easy rules to follow or do I |
| 11 |
> > have know how it works on a very advanced level? |
| 12 |
> |
| 13 |
> Neither have I. Nor do I even pretend to know anything about |
| 14 |
> implementing this type of thing. But for the purpose of your |
| 15 |
> proposal, don't worry about it. I intend to find out more about it. |
| 16 |
> As I find out the info needed. I'll make it known. At that point it |
| 17 |
> can be decided if a slight change to the design is warranted. |
| 18 |
|
| 19 |
I have some knowledge about machine learning (ML), particularly as it |
| 20 |
relates to dimensionality reduction and clustering but also some other |
| 21 |
areas. |
| 22 |
|
| 23 |
Essentially the idea would be to come up with a training set and a test |
| 24 |
set, both with known answers, using ebuilds that are already written. |
| 25 |
You "train" your ML tool on the training set to learn how source code |
| 26 |
and/or build tools relate to ebuild syntax and dependencies, then "test" |
| 27 |
it on the test set to see whether it learned things correctly. Iterate |
| 28 |
by fiddling around with settings until things actually work; when they |
| 29 |
do, you have a complete backend. |
| 30 |
|
| 31 |
The complexity of that approach is why I suggest a simpler one that |
| 32 |
relies on defining the format of various files, since we already know |
| 33 |
what autotools syntax looks like, what ebuild syntax looks like, what C |
| 34 |
source code looks like, etc. ML approaches are more useful when you |
| 35 |
don't know the connection between inputs and outputs, but we do. On the |
| 36 |
ebuild side of this syntax-based approach, there would be some potential |
| 37 |
integration to another of our ongoing GSoC projects, libbash. |
| 38 |
|
| 39 |
-- |
| 40 |
Thanks, |
| 41 |
Donnie |
| 42 |
|
| 43 |
Donnie Berkholz |
| 44 |
Admin, Summer of Code |
| 45 |
Gentoo Linux |
| 46 |
Blog: http://dberkholz.com |
Archives