public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Paul de Vrieze <pauldv@gentoo.org>
To: gentoo-portage-dev@gentoo.org
Subject: Re: [gentoo-portage-dev] portage-ng concurse entry Was: Updated Portage project page
Date: Fri, 5 Dec 2003 13:26:34 +0100	[thread overview]
Message-ID: <200312051326.47191.pauldv@gentoo.org> (raw)
In-Reply-To: <200312050158.17479.george@gentoo.org>

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2449 bytes --]

On Friday 05 December 2003 10:58, George Shapovalov wrote:
> Sorry for the crosspost, but it looks like this topic is approximately
> equivalently active on either lis, and I did not find the "submission
> instructions" perhaps because its not yet time for design submits :)..

Some words about your page,

Prolog != AI
AI != undeterministic
actually most AI research is into the area of deterministic approaches. Most 
undeterministic behaviour which is not in games (where you want 
undeterministic behaviour) can be found into trying to trying to get a low 
complexity for problems that have natural big complexity. In this way 
undeterministic means that in some cases the tricks don't work and you get 
the big complexity (hell even caching is undeterministic in the same way).

prolog is very good at graph traversal tasks (which is what AI in many cases 
involves and why in AI prolog is used a lot) as the mode of operation is 
basically a depth-first backtracking search algorithm (about 10 lines of 
pseudocode). For that reason I think it is a good candidate for the new and 
improved dependency algorithm.

While prolog is very good for such tasks I don't think it is suited to 
implement the core of portage. This is not because I think prolog is a 
problem, it is because I think that such languages are not suited for 
procedural dispatch, divide, etc. tasks. That is something that C is good at.
However procedural languages are very bad at tree traversal, so I think that 
prolog is also a good option.

Then about caching

While you have a point with your prediction on number of packages, most of 
those packages involve leaf packages. That means that the number of 
dependencies per leaf package will probably not increase. However the amount 
of packages totally not regarded will grow. For this portage should do some 
kind of on-demand loading of packages. I see no need whatsoever to have a 
normal emerge task load in the whole tree and create a graph of that.

I would like portage to remain lean and mean. I do run gentoo on a 16MB 60mhz 
pentium, and I like it. While the cache should also be a module that replaces 
a direct-tree-read module (possibly wrapping it), I think that caching should 
be possible on a configurable level. Not just dumbly load in all ebuilds.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2003-12-05 12:26 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-05  9:58 [gentoo-portage-dev] portage-ng concurse entry Was: Updated Portage project page George Shapovalov
2003-12-05 12:26 ` Paul de Vrieze [this message]
2003-12-05 21:33   ` George Shapovalov
2003-12-06 14:26     ` Paul de Vrieze
2003-12-06 19:35       ` Daniel Robbins
2003-12-06 19:41         ` Jon Portnoy
2003-12-07  0:13           ` [gentoo-portage-dev] ebuild strengths/weaknesses Daniel Robbins
2003-12-07  1:44           ` [gentoo-portage-dev] portage-ng concurse entry Was: Updated Portage project page Jason Stubbs
2003-12-07  2:39             ` George Shapovalov
2003-12-07  3:12               ` Jason Stubbs
2003-12-07  4:50               ` Ray Russell Reese III
2003-12-07  7:27                 ` Daniel Robbins
2003-12-07  7:40               ` Daniel Robbins
2003-12-07  9:11                 ` Kapil Thangavelu
2003-12-07 11:11                   ` Paul de Vrieze
2003-12-08 16:03                 ` [gentoo-portage-dev] portage-ng concurse entry Was: Updated Portage project page, ebuild conversion Sandy McArthur
2003-12-07 11:05         ` [gentoo-portage-dev] portage-ng concurse entry Was: Updated Portage project page Paul de Vrieze
2003-12-07 19:59         ` Philippe Lafoucrière
2003-12-07 20:10           ` Philippe Lafoucrière
2003-12-07 20:12           ` Jeff Smelser
2003-12-07 21:01             ` [gentoo-portage-dev] gpg signing of Manifests Douglas Russell
2003-12-07 21:53               ` Douglas Russell
2003-12-06 23:00       ` [gentoo-portage-dev] portage-ng concurse entry Was: Updated Portage project page George Shapovalov
2003-12-07 11:18         ` Paul de Vrieze
2003-12-05 16:54 ` [gentoo-portage-dev] portage-ng design competition -- not yet Daniel Robbins
2003-12-05 20:35   ` George Shapovalov
2003-12-05 21:59   ` [gentoo-portage-dev] portage-ng wish list Sandy McArthur

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200312051326.47191.pauldv@gentoo.org \
    --to=pauldv@gentoo.org \
    --cc=gentoo-portage-dev@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox