Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 43848200C6F for ; Tue, 9 May 2017 08:38:34 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 4206D160BB6; Tue, 9 May 2017 06:38:34 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 1318B160BB3 for ; Tue, 9 May 2017 08:38:32 +0200 (CEST) Received: (qmail 3059 invoked by uid 500); 9 May 2017 06:38:32 -0000 Mailing-List: contact users-help@groovy.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@groovy.apache.org Delivered-To: mailing list users@groovy.apache.org Received: (qmail 3049 invoked by uid 99); 9 May 2017 06:38:32 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 May 2017 06:38:32 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id B2BB2C047C for ; Tue, 9 May 2017 06:38:31 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.603 X-Spam-Level: X-Spam-Status: No, score=0.603 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_REPLY=1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id 8TDqRzNqcKDH for ; Tue, 9 May 2017 06:38:28 +0000 (UTC) Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com [209.85.128.170]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 0FB635F36A for ; Tue, 9 May 2017 06:38:28 +0000 (UTC) Received: by mail-wr0-f170.google.com with SMTP id w50so61201649wrc.0 for ; Mon, 08 May 2017 23:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DpU0f5nKYgc6/xqdbKP0QTMhy4cKL2PXHQJKanqHnFg=; b=aJofii8HEHJCctFa3atvim9P//HGCFdGsyYgdJeKyWviM7ISDPlwNzOMaUj9g9K+hz SsKgdWf3OcqSaEN78eIdRrn+JyvYINUzmv2yDDPdga0nA4kncAMtFdaoI7Ak0raasx0f nwOZTQVOze52xcXEtmeLIZU+9WyLC07xxU0/rg57+FAswGqnk0owu1p/k4ub0N5mhZe/ 9hikF+rhQyiMVkJquH4tqvHjHmOvSI3ClJneIfQgdObcU7acu9c6JuqRCZjqFqhEdPHt qFPcgJGS5i3zfSXfipjhKV09btcC0CIQebUyAiSt0k148pm4PJlhXWrPqdE0eZ1RVGkY kQ5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DpU0f5nKYgc6/xqdbKP0QTMhy4cKL2PXHQJKanqHnFg=; b=WbJwrECVg6XphGJwpxd3O4ykfIZZk9LBiUy5Pn5d/Dt2dhBAnqSwx/ypyKO7QLIcAd KUexX6YgOPKKqz2hC95yXh7CFwLRifY3IwvSitZL1IldzOy75y+LwAqgL5XZ0IIRtW+d 7IoLYy7HyukGe/IkuP4cMIe8B0ZJLeTzjG9mzDgP1V0LFUK6kn6mTbd9xf59+Ywi6ppA BXibW2rT5uSqJu8DS0Xpg8DUHud8OJo/+/YBzxp+MDkxvSpCMSPzJTWCI9e/AXP7FOB5 eV/1YygByIWKKem3x/Z3OXMIPDGru1T/lT0LHTY/AIcgML0qcZYL/jlj2JtR9cCfAHSn D1WA== X-Gm-Message-State: AODbwcAFTp5AT7f4drgosLgLK1dV44XSwwd/g+T+f/ZcD3WJppeVEPX2 T+HZrxjAkLZK8JXTyWExeOCu8Hm1GPzn X-Received: by 10.46.8.2 with SMTP id 2mr8668667lji.121.1494311906806; Mon, 08 May 2017 23:38:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.22.12 with HTTP; Mon, 8 May 2017 23:38:26 -0700 (PDT) In-Reply-To: References: <5C676E6359909E478C7B811BDB48CA356C498D@CWWAPP478.windstream.com> From: =?UTF-8?Q?C=C3=A9dric_Champeau?= Date: Tue, 9 May 2017 08:38:26 +0200 Message-ID: Subject: Re: Groovy AOT compilation To: users@groovy.apache.org Cc: Paul King Content-Type: multipart/alternative; boundary=f403045ec68263901b054f119aa0 archived-at: Tue, 09 May 2017 06:38:34 -0000 --f403045ec68263901b054f119aa0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'll let Jochen answer that, I don't recall the reasons why it was a breaking change. I think part of the answer is that Groovy classes implement GroovyObject, but I miss the details, I'm no dynamic expert ;) 2017-05-09 8:34 GMT+02:00 Graeme Rocher : > Would it make sense to have the metaClass field of GroovyObject > initialise lazily? In what circumstance would that be a breaking > change? Concurrency? > > On Tue, May 9, 2017 at 8:25 AM, C=C3=A9dric Champeau > wrote: > > The reason is that even with static compilation, constructors include > > metaclass initialization. This is something that have been bothering me > for > > a long time, and I wish we could rework that, but it's a behavioral > breaking > > change (however, really unlikely to break things in real world). > > > > 2017-05-09 8:16 GMT+02:00 Sergei Egorov : > >> > >> Dear Paolo, > >> > >> Could you please share an example project? I would like to play with i= t > :) > >> > >> > >> Best Regards, > >> Sergei > >> > >> On Tue, May 9, 2017 at 1:04 AM Paolo Di Tommaso > >> wrote: > >>> > >>> That would make sense. However apart of that there's still a lot of > >>> reflection behind the scene even when using StaticCompile. For exampl= e > just > >>> replacing the println statement with a `new Hello()` in the previous > >>> snippet, I'm getting the following errors when trying to compile with > the > >>> AOT compiler: > >>> > >>> > >>> > >>> groovy.lang.MetaClassRegistry$MetaClassCreationHandle. > createWithCustomLookup(Class, > >>> MetaClassRegistry): Method is marked as deleted: > >>> HotSpotMethod > >>> at > >>> groovy.lang.MetaClassRegistry$MetaClassCreationHandle. > createWithCustomLookup(MetaClassRegistry.java:149) > >>> at > >>> groovy.lang.MetaClassRegistry$MetaClassCreationHandle. > create(MetaClassRegistry.java:144) > >>> at > >>> org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock( > ClassInfo.java:259) > >>> at > >>> org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java: > 302) > >>> at Hello.$getStaticMetaClass(Hello.groovy) > >>> at Hello.(Hello.groovy) > >>> at Hello.main(Hello.groovy:5) > >>> at com.oracle.svm.core.JavaMainWrapper.run(stripped:111) > >>> > >>> org.codehaus.groovy.reflection.CachedClass$8.initValue(): Method is > >>> marked as deleted: HotSpotMethod > >>> at > >>> org.codehaus.groovy.reflection.CachedClass$8. > initValue(CachedClass.java:216) > >>> at > >>> org.codehaus.groovy.reflection.CachedClass$8. > initValue(CachedClass.java:214) > >>> at > >>> org.codehaus.groovy.util.LazyReference.getLocked( > LazyReference.java:49) > >>> at org.codehaus.groovy.util.LazyReference.get(LazyReference.java:40) > >>> at > >>> org.codehaus.groovy.reflection.CachedClass. > getMethods(CachedClass.java:274) > >>> at > >>> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass. > initialize(ClosureMetaClass.java:474) > >>> at > >>> org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock( > ClassInfo.java:260) > >>> at > >>> org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java: > 302) > >>> at Hello.$getStaticMetaClass(Hello.groovy) > >>> at Hello.(Hello.groovy) > >>> at Hello.main(Hello.groovy:5) > >>> at com.oracle.svm.core.JavaMainWrapper.run(stripped:111) > >>> > >>> > >>> Here the offending methods are Class.getConstructor(Class[]) and > >>> Class.getInterfaces(). > >>> > >>> Does the MetaClassRegistry mechanism is really needed when using the > >>> Groovy static compilation ? > >>> > >>> > >>> p > >>> > >>> On Tue, May 9, 2017 at 12:29 AM, Paul King wrote= : > >>>> > >>>> That line was added to break a hard-dependency on the groovy-xml > module > >>>> by the core groovy module. With Java 9's "real" modules, we'd > potentially > >>>> want to rework that. I haven't really thought about what we might do > instead > >>>> but welcome to suggestions/ideas/PRs. > >>>> > >>>> Cheers, Paul. > >>>> > >>>> > >>>> On Tue, May 9, 2017 at 6:35 AM, Paolo Di Tommaso > >>>> wrote: > >>>>> > >>>>> Good question. I leave the answer to Groovy core developers, howeve= r > as > >>>>> far as I've understood even when the code is statically compiled, > Groovy > >>>>> still uses reflection in runtime helper methods. For example one of > the > >>>>> first issue I've encountered it's raised by the following line in t= he > >>>>> InvokeHelper.format method that the AOT compiler is unable to > translate to > >>>>> native code > >>>>> > >>>>> Method serialize =3D > >>>>> Class.forName("groovy.xml.XmlUtil").getMethod("serialize", > Element.class); > >>>>> > >>>>> > >>>>> > >>>>> p > >>>>> > >>>>> On Mon, May 8, 2017 at 5:35 PM, Winnebeck, Jason > >>>>> wrote: > >>>>>> > >>>>>> I think a biggest question than AOT compatibility is why does > compile > >>>>>> static still need to do reflection? I thought that was the point > was to > >>>>>> disable it, especially for Android support=E2=80=A6? Unless the is= sue is the > >>>>>> metaclass generation, does compile static still generate > metaclasses? > >>>>>> > >>>>>> > >>>>>> > >>>>>> Jason > >>>>>> > >>>>>> > >>>>>> > >>>>>> From: Paolo Di Tommaso [mailto:paolo.ditommaso@gmail.com] > >>>>>> Sent: Monday, May 08, 2017 11:02 AM > >>>>>> To: users@groovy.apache.org > >>>>>> Subject: Groovy AOT compilation > >>>>>> > >>>>>> > >>>>>> > >>>>>> Dear all, > >>>>>> > >>>>>> > >>>>>> > >>>>>> I just want to share with you my experience with the Java AOT > compiler > >>>>>> a came across a few days ago. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Although they said clearly that it still an experimental project a= nd > >>>>>> it does not support dynamic class loading and most of reflection, = I > turns > >>>>>> out it's possible to compile a basic static Groovy class, eg: > >>>>>> > >>>>>> > >>>>>> > >>>>>> @groovy.transform.CompileStatic > >>>>>> > >>>>>> class Hello { > >>>>>> > >>>>>> > >>>>>> > >>>>>> static void main( String... args ) { > >>>>>> > >>>>>> System.out.println "Hello world!" > >>>>>> > >>>>>> } > >>>>>> > >>>>>> } > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> This mean that it creates a native 5MB binary executable, that can > run > >>>>>> on any machine without the need of the Java VM nor the Groovy > runtime! in 12 > >>>>>> millisecond! cool!! > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Unfortunately the good news stops here. I was unable to successful= ly > >>>>>> compile any other piece of code, which for example uses a Groovy > "println" > >>>>>> method or just instantiate a class. The problem seems to be that, > even > >>>>>> though the code is statically compiled, Groovy uses reflection > behind the > >>>>>> scene to instantiate classes and performs other operations. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Now, I guess this is certainly not a Groovy top priority, however > >>>>>> since there is an on-going discussion around a major Groovy > reengineering to > >>>>>> make it compatible with the upcoming Java 9 module system, I was > wondering > >>>>>> if it would not make sense to include the support for the Java AOT > compiler > >>>>>> as a goal for a future Groovy 3/4 release? > >>>>>> > >>>>>> > >>>>>> > >>>>>> Personally I think it would be an extremely useful feature and a > major > >>>>>> achievement for the project. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> What do you think ? > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Cheers, > >>>>>> > >>>>>> Paolo > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> This email message and any attachments are for the sole use of the > >>>>>> intended recipient(s). Any unauthorized review, use, disclosure or > >>>>>> distribution is prohibited. If you are not the intended recipient, > please > >>>>>> contact the sender by reply email and destroy all copies of the > original > >>>>>> message and any attachments. > >>>>> > >>>>> > >>>> > >>> > > > > > > -- > Graeme Rocher > --f403045ec68263901b054f119aa0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'll let Jochen answer that, I don't recall the re= asons why it was a breaking change. I think part of the answer is that Groo= vy classes implement GroovyObject, but I miss the details, I'm no dynam= ic expert ;)

2017-05-09 8:34 GMT+02:00 Graeme Rocher <graeme.rocher@gmail.com>:
Would it make sense to have= the metaClass field of GroovyObject
initialise lazily? In what circumstance would that be a breaking
change? Concurrency?

On Tue, May 9, 2017 at 8:25 AM, C=C3=A9dric Champeau
<cedric.champeau@gmail.com<= /a>> wrote:
> The reason is that even with static compilation, constructors include<= br> > metaclass initialization. This is something that have been bothering m= e for
> a long time, and I wish we could rework that, but it's a behaviora= l breaking
> change (however, really unlikely to break things in real world).
>
> 2017-05-09 8:16 GMT+02:00 Sergei Egorov <bsideup@gmail.com>:
>>
>> Dear Paolo,
>>
>> Could you please share an example project? I would like to play wi= th it :)
>>
>>
>> Best Regards,
>> Sergei
>>
>> On Tue, May 9, 2017 at 1:04 AM Paolo Di Tommaso
>> <paolo.ditommaso@g= mail.com> wrote:
>>>
>>> That would make sense. However apart of that there's still= a lot of
>>> reflection behind the scene even when using StaticCompile. For= example just
>>> replacing the println statement with a `new Hello()` in the pr= evious
>>> snippet, I'm getting the following errors when trying to c= ompile with the
>>> AOT compiler:
>>>
>>>
>>>
>>> groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createWithCustomLookup(Class,
>>> MetaClassRegistry): Method is marked as deleted:
>>> HotSpotMethod<Class.getConstructor(Class[])>
>>> at
>>> groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createWithCustomLookup(MetaClassRegistry.java:149)
>>> at
>>> groovy.lang.MetaClassRegistry$MetaClassCreationHandle.create(MetaClassRegistry.java:144)
>>> at
>>> org.codehaus.groovy.reflection.ClassInfo.getMetaClas= sUnderLock(ClassInfo.java:259)
>>> at
>>> org.codehaus.groovy.reflection.ClassInfo.getMetaClas= s(ClassInfo.java:302)
>>> at Hello.$getStaticMetaClass(Hello.groovy)
>>> at Hello.<init>(Hello.groovy)
>>> at Hello.main(Hello.groovy:5)
>>> at com.oracle.svm.core.JavaMainWrapper.run(stripped:= 111)
>>>
>>> org.codehaus.groovy.reflection.CachedClass$8.initVal= ue(): Method is
>>> marked as deleted: HotSpotMethod<Class.getInterfaces()= >
>>> at
>>> org.codehaus.groovy.reflection.CachedClass$8.initVal= ue(CachedClass.java:216)
>>> at
>>> org.codehaus.groovy.reflection.CachedClass$8.initVal= ue(CachedClass.java:214)
>>> at
>>> org.codehaus.groovy.util.LazyReference.getLocked(Laz= yReference.java:49)
>>> at org.codehaus.groovy.util.LazyReference.get(LazyRe= ference.java:40)
>>> at
>>> org.codehaus.groovy.reflection.CachedClass.getMethod= s(CachedClass.java:274)
>>> at
>>> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.initialize(ClosureMetaClass.java:474)
>>> at
>>> org.codehaus.groovy.reflection.ClassInfo.getMetaClas= sUnderLock(ClassInfo.java:260)
>>> at
>>> org.codehaus.groovy.reflection.ClassInfo.getMetaClas= s(ClassInfo.java:302)
>>> at Hello.$getStaticMetaClass(Hello.groovy)
>>> at Hello.<init>(Hello.groovy)
>>> at Hello.main(Hello.groovy:5)
>>> at com.oracle.svm.core.JavaMainWrapper.run(stripped:= 111)
>>>
>>>
>>> Here the offending methods are Class.getConstructor(Class[]) a= nd
>>> Class.getInterfaces().
>>>
>>> Does the MetaClassRegistry mechanism is really needed when usi= ng the
>>> Groovy static compilation ?
>>>
>>>
>>> p
>>>
>>> On Tue, May 9, 2017 at 12:29 AM, Paul King <paulk@asert.com.au> wrote:
>>>>
>>>> That line was added to break a hard-dependency on the groo= vy-xml module
>>>> by the core groovy module. With Java 9's "real&qu= ot; modules, we'd potentially
>>>> want to rework that. I haven't really thought about wh= at we might do instead
>>>> but welcome to suggestions/ideas/PRs.
>>>>
>>>> Cheers, Paul.
>>>>
>>>>
>>>> On Tue, May 9, 2017 at 6:35 AM, Paolo Di Tommaso
>>>> <paolo.dit= ommaso@gmail.com> wrote:
>>>>>
>>>>> Good question. I leave the answer to Groovy core devel= opers, however as
>>>>> far as I've understood even when the code is stati= cally compiled, Groovy
>>>>> still uses reflection in runtime helper methods. For e= xample one of the
>>>>> first issue I've encountered it's raised by th= e following line in the
>>>>> InvokeHelper.format method that the AOT compiler is un= able to translate to
>>>>> native code
>>>>>
>>>>>=C2=A0 =C2=A0Method serialize =3D
>>>>> Class.forName("groovy.xml.XmlUtil").get= Method("serialize", Element.class);
>>>>>
>>>>>
>>>>>
>>>>> p
>>>>>
>>>>> On Mon, May 8, 2017 at 5:35 PM, Winnebeck, Jason
>>>>> <= Jason.Winnebeck@windstream.com> wrote:
>>>>>>
>>>>>> I think a biggest question than AOT compatibility = is why does compile
>>>>>> static still need to do reflection? I thought that= was the point was to
>>>>>> disable it, especially for Android support=E2=80= =A6? Unless the issue is the
>>>>>> metaclass generation, does compile static still ge= nerate metaclasses?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Paolo Di Tommaso [mailto:paolo.ditommaso@gmail.com]
>>>>>> Sent: Monday, May 08, 2017 11:02 AM
>>>>>> To: use= rs@groovy.apache.org
>>>>>> Subject: Groovy AOT compilation
>>>>>>
>>>>>>
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>>
>>>>>>
>>>>>> I just want to share with you my experience with t= he Java AOT compiler
>>>>>> a came across a few days ago.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Although they said clearly that it still an experi= mental project and
>>>>>> it does not support dynamic class loading and most= of reflection, I turns
>>>>>> out it's possible to compile a basic static Gr= oovy class, eg:
>>>>>>
>>>>>>
>>>>>>
>>>>>> @groovy.transform.CompileStatic
>>>>>>
>>>>>> class Hello {
>>>>>>
>>>>>>
>>>>>>
>>>>>>=C2=A0 =C2=A0static void main( String... args ) { >>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0System.out.println "Hello = world!"
>>>>>>
>>>>>>=C2=A0 =C2=A0}
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> This mean that it creates a native 5MB binary exec= utable, that can run
>>>>>> on any machine without the need of the Java VM nor= the Groovy runtime! in 12
>>>>>> millisecond! cool!!
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Unfortunately the good news stops here. I was unab= le to successfully
>>>>>> compile any other piece of code, which for example= uses a Groovy "println"
>>>>>> method or just instantiate a class. The problem se= ems to be that, even
>>>>>> though the code is statically compiled, Groovy use= s reflection behind the
>>>>>> scene to instantiate classes and performs other op= erations.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Now, I guess this is certainly not a Groovy top pr= iority, however
>>>>>> since there is an on-going discussion around a maj= or Groovy reengineering to
>>>>>> make it compatible with the upcoming Java 9 module= system, I was wondering
>>>>>> if it would not make sense to include the support = for the Java AOT compiler
>>>>>> as a goal for a future Groovy 3/4 release?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Personally I think it would be an extremely useful= feature and a major
>>>>>> achievement for the project.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> What do you think ?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Paolo
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> This email message and any attachments are for the= sole use of the
>>>>>> intended recipient(s). Any unauthorized review, us= e, disclosure or
>>>>>> distribution is prohibited. If you are not the int= ended recipient, please
>>>>>> contact the sender by reply email and destroy all = copies of the original
>>>>>> message and any attachments.
>>>>>
>>>>>
>>>>
>>>
>



--
Graeme Rocher

--f403045ec68263901b054f119aa0--