Return-Path: 
 <dev-return-52095-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@www.apache.org
Received: (qmail 26862 invoked from network); 20 Oct 2003 10:43:10 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 20 Oct 2003 10:43:10 -0000
Received: (qmail 77634 invoked by uid 500); 20 Oct 2003 10:43:07 -0000
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 77595 invoked by uid 500); 20 Oct 2003 10:43:07 -0000
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@ant.apache.org>
List-Subscribe: <mailto:dev-subscribe@ant.apache.org>
List-Help: <mailto:dev-help@ant.apache.org>
List-Post: <mailto:dev@ant.apache.org>
List-Id: "Ant Developers List" <dev.ant.apache.org>
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Delivered-To: mailing list dev@ant.apache.org
Received: (qmail 77571 invoked from network); 20 Oct 2003 10:43:06 -0000
Received: from unknown (HELO london.cellectivity.com) (212.18.242.163)
  by daedalus.apache.org with SMTP; 20 Oct 2003 10:43:06 -0000
content-class: urn:content-classes:message
Subject: RE: Macrodef and parallel in a recursive situation
Date: Mon, 20 Oct 2003 11:43:06 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-ID: <747F247264ECE34CA60E323FEF0CCC0C5D08D0@london.cellectivity.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Thread-Topic: Macrodef and parallel in a recursive situation
Thread-Index: AcOW6GFXyrul9SZtTgWd1dRH3WxLDwADjdow
From: "Jose Alberto Fernandez" <jalberto@cellectivity.com>
To: "Ant Developers List" <dev@ant.apache.org>
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Peter,=20

sounds great. How does your implementation using threadLocal
works when going across <ant> or <antcall>? Just curious.

Jose Alberto

> -----Original Message-----
> From: peter reilly [mailto:peter.reilly@corvil.com]=20
> Sent: 20 October 2003 09:59
> To: Ant Developers List
> Subject: Re: Macrodef and parallel in a recursive situation
>=20
>=20
> I have written the code to support local properties.
> While I was doing this, I realized that the attributes
> of a macrodef could/should be local properties as well,=20
> removing some of the issues seen last week (use of attribute=20
> in a bsf script and support of parallel/recursive).
>=20
> The following shows it in using a new task called local.
>=20
> <project name=3D"local">
>   <property name=3D"prop1" value=3D"a global value"/>
>   <target name=3D"test1">
>     <local name=3D"prop1" value=3D"a local value"/>
>     <echo>prop1 is "${prop1}"</echo>
>   </target>
>   <target name=3D"test2" depends=3D"test1">
>     <echo>prop1 is "${prop1}"</echo>
>   </target>
> </project>
>=20
> This ant test2 generates the following:
>=20
> test1:
> prop1 is "a local value"
>=20
> test2:
> prop1 is "a global value"
>=20
> Each taskcontainer sets up a new local scope:
>=20
>   <target name=3D"sequential">
>     <local name=3D"prop2" value=3D"in target"/>
>     <sequential>
>       <local name=3D"prop2" value=3D"in sequential"/>
>       <echo>prop2 is "${prop2}"</echo>
>     </sequential>
>     <echo>prop2 is "${prop2}"</echo>
>   </target>
>=20
> will generate the following:
> sequential:
> prop2 is "in sequential"
> prop2 is "in target"
>=20
> The value part of <local> is optional, and  the local
> property may be set by a subsequent <property>, <property>
> will only set it if the value is not set.
>=20
>   <target name=3D"notset">
>     <local name=3D"prop3"/>
>     <echo>prop3 is "${prop3}"</echo>
>     <property name=3D"prop3" value=3D"is set"/>
>     <property name=3D"prop3" value=3D"is set again"/>
>     <echo>prop3 is "${prop3}"</echo>
>   </target>
>=20
> will generate the following:
> notset:
> prop3 is "${prop3}"
> prop3 is "is set"
>=20
> prop3 is still a local variable and will not be seen outside=20
> the target.
>=20
> The local properties are thread local so the following works=20
> as expected:
>   <target name=3D"parallel">
>     <local name=3D"prop4"/>
>     <parallel>
>       <sequential>
>         <property name=3D"prop4" value=3D"thread1"/>
>         <echo>t1: prop4 is "${prop4}"</echo>
>       </sequential>
>       <sequential>
>         <property name=3D"prop4" value=3D"thread2"/>
>         <echo>t2: prop4 is "${prop4}"</echo>
>       </sequential>
>       <sequential>
>         <property name=3D"prop4" value=3D"thread3"/>
>         <echo>t3: prop4 is "${prop4}"</echo>
>       </sequential>
>     </parallel>
>   </target>
>=20
> parallel:
> t2: prop4 is "thread2"
> t1: prop4 is "thread1"
> t3: prop4 is "thread3"
>=20
> Use with macrodef.
> -----------------
>=20
> Attributes may now be implemented as local properties, which=20
> means that they will be seen as normal properties by ant=20
> tasks - including script.
>=20
>   <target name=3D"macro">
>     <macrodef name=3D"callscript">
>       <attribute name=3D"x"/>
>       <sequential>
>         <script language=3D"beanshell">
>           System.out.println("x is '" +=20
> project.getProperty("x") + "'");
>         </script>
>       </sequential>
>     </macrodef>
>=20
>     <callscript x=3D"this is x"/>
>   </target>
>=20
> will generate:
> macro:
> x is 'this is x'
>=20
> Macrodef does not do the attribute substitutions so the following
>   <target name=3D"macro2">
>     <macrodef name=3D"callscript">
>       <attribute name=3D"x"/>
>       <sequential>
>         <script language=3D"beanshell">
>           System.out.println("x is '${x}'");
>         </script>
>       </sequential>
>     </macrodef>
>=20
>     <callscript x=3D"this is x"/>
>   </target>
> will generate:
> macro2:
> x is '${x}'
> as <script/> does not do property expansion.
>=20
> A variation of the recurive macrodef last week may be done by:
>   <target name=3D"recur">
>     <macrodef name=3D"recur">
>       <attribute name=3D"thread"/>
>       <attribute name=3D"current"/>
>       <sequential>
>         <antcontrib:if>
>           <equals arg1=3D"0" arg2=3D"${current}"/>
>           <then>
>             <echo message=3D"Thread: ${thread} done"/>
>           </then>
>           <else>
>             <antcontrib:math
>               datatype  =3D "int"
>               operand1  =3D "${current}"
>               operation =3D "-"
>               operand2  =3D "1"
>               result    =3D "current"
>               />
>             <echo message =3D "T: ${thread}, C: ${current}" />
>             <sleep seconds=3D"1"/>
>             <recur current =3D "${current}" thread  =3D "${thread}" />
>           </else>
>         </antcontrib:if>
>       </sequential>
>     </macrodef>
>    =20
>     <parallel>
>       <recur thread=3D"1" current=3D"5"/>
>       <recur thread=3D"2" current=3D"6"/>
>       <recur thread=3D"3" current=3D"2"/>
>     </parallel>
>   </target>
>=20
> The output is:
> recur:
> T: 3, C: 1
> T: 1, C: 4
> T: 2, C: 5
> T: 3, C: 0
> T: 1, C: 3
> T: 2, C: 4
> Thread: 3 done
> T: 1, C: 2
> T: 2, C: 3
> T: 1, C: 1
> T: 2, C: 2
> T: 1, C: 0
> T: 2, C: 1
> Thread: 1 done
> T: 2, C: 0
> Thread: 2 done
>=20
>=20
>=20
> I realize that it is late in the day to get this
> into ant1.6, but I think that it will make macrodef
> much more usefull and easy to port current antcalls.
>=20
> The changes are quite small (mostly to PropertyHelper).
>=20
> Peter
>=20
> On Saturday 18 October 2003 16:22, Jose Alberto Fernandez wrote:
> > > From: peter reilly [mailto:peter.reilly@corvil.com]
> > >
> > > I think that we may need a thread local variable to
> > > handle parallel.
> > >
> > > This would mean some deep messing with the Property handling.
> >
> > I do not see how thread locals would help here. I guess the=20
> question=20
> > is whether tasks in parallel should be able to modify the global=20
> > properties in the frame, or should the changes be local to the=20
> > parallel branch (and somehow joined at the end of execution).
> >
> > That would mean each parallel computation branch is independent. I=20
> > guess I am suggesting the second type of implementation=20
> proposed for=20
> > <local-property> to be used instead for <parallel>. I think=20
> that would=20
> > be a much more efficient way to do it. So here is how it would work:
> >
> > 1) Add new attribute independent (default false) to <parallel>.
> >
> > 2) When independent is true, each thread will use a cloned project=20
> > frame for its execution. So all properties and reference=20
> manipulation=20
> > will be independent of each other. When the thread ends, any new=20
> > properties added in the cloned frame, will be added to the original=20
> > parent frame, following the common rules for setting=20
> properties. Which=20
> > means that the first thread that finish will win on setting the=20
> > property, if another thread ends later and tries to set the same=20
> > variable, it will loose. For references, we need to copy=20
> any changes=20
> > and due to its semantics all threads will contribute as they end.
> >
> > 3) When independent is false, parallel works as today (for backward=20
> > compatibility), all threads see each others changes.
> >
> > This rules seem easy programable without big changes to CORE.
> >
> > I would still like having <local-property> which could be=20
> implemented=20
> > as per the first description proposed below.
> >
> > Jose Alberto
> >
> > > Peter
> > >
> > > On Friday 17 October 2003 17:57, Jose Alberto Fernandez wrote:
> > > > > From: peter reilly [mailto:peter.reilly@corvil.com]
> > > > >
> > > > > I would rather have Jose's idea of a <local-property/> task.
> > > > >
> > > > > This could be used outside of macrodef.
> > > > >
> > > > > The only problem is the implementation.
> > > >
> > > > Indeed, there is an easy implementation but will not solve
> > >
> > > the case of
> > >
> > > > <parallel>, because the local definition would really be a
> > >
> > > temporary
> > >
> > > > global one:
> > > >
> > > > public class LocalProperty extends Sequential {
> > > >   private String property;
> > > >   private String oldValue;
> > > >
> > > >   public setName(String i_property){property =3D i_property;}
> > > >
> > > >   public void execute() {
> > > >     if (property =3D=3D null) throw new BuildException("name
> > >
> > > attribute is
> > >
> > > > mandatory");
> > > >     try {
> > > >       oldValue =3D getProject().getProperty(property);
> > > >       getProject().setProperty(property, null); // This=20
> may need=20
> > > > changes to core
> > > >       super.execute();
> > > >     }
> > > >     finally {
> > > >       // This is using the deprecated setProperty method
> > > >       // that actually changes the properties even if set
> > > >       getProject().setProperty(property, oldValue);
> > > >     }
> > > >   }
> > > > }
> > > >
> > > > Here we just change the property value on the project
> > >
> > > frame, for the
> > >
> > > > duration of the task. And put the old value back before=20
> we leave.
> > > >
> > > > The problem with this simple implementation is that all the
> > >
> > > parallel
> > >
> > > > branches will see the change, which is exactly what we were
> > >
> > > trying to
> > >
> > > > avoid. To do it
> > > > right, we would need to create a new execution frame that
> > >
> > > would be use
> > >
> > > > in the
> > > > "super" call.
> > > >
> > > > But if we do that (which is like what <ant> or=20
> <antcall> do), what=20
> > > > happens if the user defines properties other than the
> > >
> > > local-property
> > >
> > > > inside the code?
> > > > Somehow, we would need to find them and propagate them back
> > >
> > > to the frame
> > >
> > > > above
> > > > upon exit.
> > > >
> > > >   <local-property name=3D"x">
> > > >    <property name=3D"y" value=3D"myY"/>
> > > >   <local-property>
> > > >   <echo message=3D"${y}"/>
> > > >
> > > > [echo] myY
> > > >
> > > > Doable, but not that easy anymore.
> > > >
> > > > What do you guys think?
> > > >
> > > > Jose Alberto
> > > >
> > > > > Peter
> >
> >=20
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>=20
>=20

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org