Re: executing task for each file in file set

[as...@ufl.edu]

=> On Mon, 11 Jun 2001 17:56:31 -0700 (PDT), Roger Vaughn <ro...@yahoo.com> said:

>>> Say we'd add foreach to the core - and I'm more and more leaning towards
>>> it (making myself a heretic, I guess 8-) - and we already have those many
>>> cases where we successfully anticipated the need for iterations like
>>> javac, execon, apply and in the future anton, javaon.  What can we do to
>>> make user chose the "right" thing?


Having now read the requirements doc for ant2, I think that keeping foreach
out of the core, but anticipating that those who want it will grab it, is the
best way to present the 'right' way without being draconian.  I, for one,
would drop out of the debate were that decided.


> First we had <exec>.  Then came <execon>, i.e. exec for each member of a
> fileset.  Now we see anton, javaon, etc. in the future.  But is this the start
> of a trend: exec/execon, ant/anton, chmod/chmodon, delete/deleteon,
> echo/echoon, etc.?  (Yes, I know some of these deal with filesets natively -
> I'm simply making a point.)

> Are we now going to have individual and iterating versions of every task?

I assert that tasks should, where this is sane, operate on a list of items.
This list may only contain one item.


> It would seem to make far more sense to me to extract the iteration code into
> its own construct, and keep the individual tasks pure.  This would seem to
> involve far less code, simpler maintenance, and more flexibility in the build
> files.

It also formally forces task writers to accept heinous inefficiencies when it
is appropriate to operate on filesets.

foreach (distfiles)  add one file to a tar ... ? 

Viewing builds as functional transformations on filesets is a powerful
abstraction.  I think we should still phrase things in that idiom wherever
practicable, (which I still say is everywhere) but let people use the more
complex (IMHO), but evidently more comprehensible, iterative idiom when they
feel the need.


- Allen S. Rout

Re: executing task for each file in file set

[Roger Vaughn <ro...@yahoo.com>]

--- Stefan Bodewig <bo...@apache.org> wrote:
> I think execon is there to stay and if it just was because of the
> parallel attribute.
> 
> Whether execon and foreach could and should be based on the same code
> (I'm not talking copy-paste here 8-) is a completely different issue.

Fair enough - I'm not trying to argue for the removal of execon, not at all -
it just appears that the pattern may begin to proliferate into other tasks
where it doesn't make as much sense, when foreach might solve those other cases
more cleanly.

I think we're starting to argue about how much we agree with each other. ;-)

roger


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

Re: executing task for each file in file set

[Stefan Bodewig <bo...@apache.org>]

Roger Vaughn <ro...@yahoo.com> wrote:

> --- Stefan Bodewig <bo...@apache.org> wrote:

>> <exec> is not a single file version, it is a no-file version which
>> happens to work on files in certain circumstances:
> 
> Still, that doesn't invalidate my point, and in fact, I believe it
> reinforces it.  Since exec has no natural association with *any*
> files, application of a set of files to an exec task is better
> handled by a helper - execon today, but perhaps foreach later.

I think execon is there to stay and if it just was because of the
parallel attribute.

Whether execon and foreach could and should be based on the same code
(I'm not talking copy-paste here 8-) is a completely different issue.

Stefan

Re: executing task for each file in file set

[Roger Vaughn <ro...@yahoo.com>]

--- Stefan Bodewig <bo...@apache.org> wrote:
> I'm not sure we have this distinction yet.  If it's in the
> distribution, it is in the core.

Sorry, I was making the distinction of invasiveness - is it a purely pluggable
task or does it affect the non-task source?

> > Exec, however, does *not*.  In fact, the internal representation of
> > execon is equivalent to "foreach f in fileset, exec x(f)."
> 
> You know my argument 8-)

Yep.  Crossed postings.  :-)

> <exec> is not a single file version, it is a no-file version which
> happens to work on files in certain circumstances:
> 
> <exec executable="/usr/games/fortune" />

Boy, you're good at this argument stuff.  ;-)  Still, that doesn't invalidate
my point, and in fact, I believe it reinforces it.  Since exec has no natural
association with *any* files, application of a set of files to an exec task is
better handled by a helper - execon today, but perhaps foreach later.

roger


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

Re: executing task for each file in file set

[Stefan Bodewig <bo...@apache.org>]

Roger Vaughn <ro...@yahoo.com> wrote:

> Someone on the list has already written a foreach task - it's not
> part of the *core*, but including it in the distro would be helpful.

I'm not sure we have this distinction yet.  If it's in the
distribution, it is in the core.

>> > Are we now going to have individual and iterating versions of
>> > every task?

> --- asr@ufl.edu wrote:

>> I assert that tasks should, where this is sane, operate on a list
>> of items.  This list may only contain one item.
> 
> I agree.  This does *not*, however, include tasks such as exec, ant,
> echo, etc.

Well, it could apply to ant - and then we'd merge anton and ant.

> Exec, however, does *not*.  In fact, the internal representation of
> execon is equivalent to "foreach f in fileset, exec x(f)."

You know my argument 8-)

> The point on the table is that Ant is evolving so that it contains
> *two* copies of many tasks - a single file version ala exec,

<exec> is not a single file version, it is a no-file version which
happens to work on files in certain circumstances:

<exec executable="/usr/games/fortune" />

Stefan

Re: executing task for each file in file set

[Roger Vaughn <ro...@yahoo.com>]

--- asr@ufl.edu wrote:
> Having now read the requirements doc for ant2, I think that keeping foreach
> out of the core, but anticipating that those who want it will grab it, is the
> best way to present the 'right' way without being draconian.  I, for one,
> would drop out of the debate were that decided.

Someone on the list has already written a foreach task - it's not part of the
*core*, but including it in the distro would be helpful.

> > First we had <exec>.  Then came <execon>, i.e. exec for each member of a
> > fileset.  Now we see anton, javaon, etc. in the future.  But is this the
> start
> > of a trend: exec/execon, ant/anton, chmod/chmodon, delete/deleteon,
> > echo/echoon, etc.?  (Yes, I know some of these deal with filesets natively
> -
> > I'm simply making a point.)
> 
> > Are we now going to have individual and iterating versions of every task?
> 
> I assert that tasks should, where this is sane, operate on a list of items.
> This list may only contain one item.

I agree.  This does *not*, however, include tasks such as exec, ant, echo, etc.

> It also formally forces task writers to accept heinous inefficiencies when it
> is appropriate to operate on filesets.
> 
> foreach (distfiles)  add one file to a tar ... ? 

Now that's absurd.  I can't think of any reason why the Ant authors would do
such a thing, nor would I even think to ask it.  Tar naturally operates on a
set of input files, as do javac and many other tasks.

Exec, however, does *not*.  In fact, the internal representation of execon is
equivalent to "foreach f in fileset, exec x(f)."  How then, is representing
this explicitly in the build file less efficient?

The point on the table is that Ant is evolving so that it contains *two* copies
of many tasks - a single file version ala exec, and a fileset version ala
execon.  That fileset code will get replicated (and therefore must be
maintained) in several places - execon, anton, etc.  How does it not make sense
to isolate the common iteration code in its own construct?

> Viewing builds as functional transformations on filesets is a powerful
> abstraction.  I think we should still phrase things in that idiom wherever
> practicable, (which I still say is everywhere) but let people use the more
> complex (IMHO), but evidently more comprehensible, iterative idiom when they
> feel the need.

Yes, but transformation of filesets is not sufficient.  Large system builds
must contend with much more than just transforming files into other files.  The
large number of requests for iteration on this list proves that it is a needed,
understood feature.  Why then the extreme resistance?  Not one person has yet
even attempted to explain why iteration is "bad", though several have tried to
offer alternatives.

I also fail to see how iteration is complex.  I use loops every day, no
problems.

Part of make's failing was the fact that we frequently needed to resort to
incomprehensible hacks to express simple concepts.  Do we want to repeat that
in Ant?  Iteration is simple, understood, and needed.  Now what's wrong with
that?

roger


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/