Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-soc
Navigation:
Lists: gentoo-soc: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-soc@g.o
From: Donnie Berkholz <dberkholz@g.o>
Subject: Re: [SOC Ebuild generator project] Introduction and C&C
Date: Wed, 23 Mar 2011 08:45:41 -0500
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 
areas.

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.

-- 
Thanks,
Donnie

Donnie Berkholz
Admin, Summer of Code
Gentoo Linux
Blog: http://dberkholz.com
Attachment:
pgpxMtc7lCx80.pgp (PGP signature)
Replies:
Re: [SOC Ebuild generator project] Introduction and C&C
-- darkdefende
References:
[SOC Ebuild generator project] Introduction and C&C
-- darkdefende
Re: [SOC Ebuild generator project] Introduction and C&C
-- Fabian Groffen
Re: [SOC Ebuild generator project] Introduction and C&C
-- darkdefende
Re: [SOC Ebuild generator project] Introduction and C&C
-- Fabian Groffen
Re: [SOC Ebuild generator project] Introduction and C&C
-- darkdefende
Re: [SOC Ebuild generator project] Introduction and C&C
-- Brian Dolbec
Re: [SOC Ebuild generator project] Introduction and C&C
-- Donnie Berkholz
Re: [SOC Ebuild generator project] Introduction and C&C
-- Brian Dolbec
Re: [SOC Ebuild generator project] Introduction and C&C
-- darkdefende
Re: [SOC Ebuild generator project] Introduction and C&C
-- Brian Dolbec
Navigation:
Lists: gentoo-soc: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: [SOC Ebuild generator project] Introduction and C&C
Next by thread:
Re: [SOC Ebuild generator project] Introduction and C&C
Previous by date:
Portage Webinterface
Next by date:
Re: GSoC - Package statistics


Updated Jun 12, 2012

Summary: Archive of the gentoo-soc mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.