[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: talk amongst yourselves: "iterated" operations

From: Robert Anderson
Subject: Re: [Gnu-arch-users] Re: talk amongst yourselves: "iterated" operations over configs
Date: 16 Sep 2003 23:27:20 -0700

On Tue, 2003-09-16 at 10:07, Tom Lord wrote:
> Part of the problem, I think, is the absense of a demonstrated itch
> that is proportional to the ambition and generality of the proposed
> family of solutions.   For example, one itch is that:
>       tla catcfg CFG | awk '{print $1}' | xargs tla ....
> is too many commands.
> Well, I can certainly see adding an option to catcfg to limit its
> output:
>       tla catcfg -p CFG | xargs tla ....
> just as a small convenience.

I tend to agree with you, in part.

So first - yeah, that would be a great first start, to see how less
itchy I (we?) get.

> Either that change would be sufficient to scratch the itch or it
> wouldn't.  But if it isn't, why exactly?  Because of the need to type
> "| xargs tla"?  presumably not --- but more likely because the
> simple-minded iteration that xargs will do here isn't sufficient.
> Instead, for this or that command, maybe there will be a need to
> compute changes to the options for each subtree; perhaps there will be
> a need to massage the output one way or another.  The per-command
> details matter a lot here but most of the discussion seems to be
> focussed on the trans-command generalities.
> Command by command, option by option:  what do you want iteration to
> do and why?
> If you have good answers to that, and a general pattern emerges other
> than one covered by `| xargs tla', then that may be a good case for an
> iteration command.

I see one possible pattern.  For concreteness, I'll discuss some
thinking around whats-missing.

Rather than specifying a branch name as you proposed before, I think the
analogous iterated command takes two configs, rather than two versions:

$ tla iteratecfg config-a whats-missing config-b

What does that do?  It iterates over the destdirs in config-a and
applies whats-missing within each of those, using the corresponding
version for each destdir in config-b.  Example:

$ more configs/config-a
./src1 cat--branch--1.0
./src2 othercat--branch--1.0

$ more configs/config-b
./src1 cat--branch-b--1.0
./src2 catinthehat--main--1.2

($ tla buildcfg config-a) at some prior pt

$ tla iteratecfg config-a whats-missing config-b

Now, with respect to your questions about output:  I think the model
provided by xargs -i is a reasonable one with just the right amount of
simplicity and explicitness:

$ tla iteratecfg config-a whats-missing config-b
tla whats-missing --dir ./src1 cat--branch-b--1.0
tla whats-missing --dir ./src2 catinthehat--main--1.2

That's it (with warnings about non-common destdirs, and reminders of the
triviality of common versions for a given destdir, etc.).  The argument
massaging consists of using config-b as a metasyntactic variable which
gets replaced by the corresponding version for each iterate.

> I'm just very skeptical of leaping into the idea of implementing a
> simple-minded subtree iterator.  It feels more to me like it would be
> implementing a _symbol_ of the features we _vaguely_ want than it
> would feel like implementing _tools_ which provide features we
> _certainly_ want.

I agree, but it certainly helps to try something to figure out if you
want it or not.  But, don't get me wrong - I don't want to send you in
particular off on wild goose chases.  But I don't think -p on catcfg is
a wild goose chase.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]