On 23:34 Tue 22 Mar , Brian Dolbec wrote:
> On Tue, 2011-03-22 at 18:49 +0100, darkdefende@... wrote:
> > Brian Dolbec writes:
> > > Absolutely. But I wanted to get the thought out there. Then
> > > maybe this years code could be designed to be easier to upgrade
> > > it's AI next year.
> > I have never written anything related to AI code generation before
> > so I don't really know how I would design the code to be easily
> > modified to support this. If there any easy rules to follow or do I
> > have know how it works on a very advanced level?
> Neither have I. Nor do I even pretend to know anything about
> implementing this type of thing. But for the purpose of your
> proposal, don't worry about it. I intend to find out more about it.
> As I find out the info needed. I'll make it known. At that point it
> can be decided if a slight change to the design is warranted.
I have some knowledge about machine learning (ML), particularly as it
relates to dimensionality reduction and clustering but also some other
Essentially the idea would be to come up with a training set and a test
set, both with known answers, using ebuilds that are already written.
You "train" your ML tool on the training set to learn how source code
and/or build tools relate to ebuild syntax and dependencies, then "test"
it on the test set to see whether it learned things correctly. Iterate
by fiddling around with settings until things actually work; when they
do, you have a complete backend.
The complexity of that approach is why I suggest a simpler one that
relies on defining the format of various files, since we already know
what autotools syntax looks like, what ebuild syntax looks like, what C
source code looks like, etc. ML approaches are more useful when you
don't know the connection between inputs and outputs, but we do. On the
ebuild side of this syntax-based approach, there would be some potential
integration to another of our ongoing GSoC projects, libbash.
Admin, Summer of Code