Re: [groovy-dev] groovy-examples.pom needs update?

Added a snapshot repo to the examples pom. At least it builds
now until we find a more permanent repo. Shouldn't be a huge
issue as we don't re-publish the examples pom.

Paul.

Guillaume Laforge wrote:
> Hi Hamlet,
> 
> On Tue, Jan 27, 2009 at 5:54 PM, Hamlet D'Arcy <hamletdrc@...> wrote:
>> I'm sorry, but I'm really bad at Maven type stuff.
>>
>> Clearly, pom.xml needs to reference the Equinox dependency. Reading
>> the Internet leads me to believe this should work:
>>
>>        <dependency>
>>            <groupId>org.eclipse.osgi</groupId>
>>            <artifactId>osgi</artifactId>
>>            <version>3.4.1</version>
>>            <scope>compile</scope>
>>        </dependency>
>>
>>
>> But this doesn't seem to be in the maven repository at
>> http://repo1.maven.org/maven2
>>
>> Does Groovy host it's own repository?
> 
> Well, there's the Codehaus repository itself (where you can find the

Re: [groovy-dev] groovy-examples.pom needs update?

Thanks a lot Paul!

2009/2/1 Paul King <paulk@...>:
>
> Added a snapshot repo to the examples pom. At least it builds
> now until we find a more permanent repo. Shouldn't be a huge
> issue as we don't re-publish the examples pom.
>
> Paul.
>
> Guillaume Laforge wrote:
>>
>> Hi Hamlet,
>>
>> On Tue, Jan 27, 2009 at 5:54 PM, Hamlet D'Arcy <hamletdrc@...> wrote:
>>>
>>> I'm sorry, but I'm really bad at Maven type stuff.
>>>
>>> Clearly, pom.xml needs to reference the Equinox dependency. Reading
>>> the Internet leads me to believe this should work:
>>>
>>>       <dependency>
>>>           <groupId>org.eclipse.osgi</groupId>
>>>           <artifactId>osgi</artifactId>
>>>           <version>3.4.1</version>
>>>           <scope>compile</scope>
>>>       </dependency>
>>>
>>>
>>> But this doesn't seem to be in the maven repository at

Re: [groovy-dev] class cache in ResolveVisitor

Ok, I committed the change to trunk.

There's a single test the fails, but it fails with our without the 
change.  It tests date arithmetic and seems unrelated:

Testcase: testDurationArithmetic took 0.015 sec
         FAILED
A week and a month absolute duration should be the same as the 
difference between two dates that far apart
  expected:<3020400000> but was:<3024000000>
         at 
groovy.time.DurationTest.testDurationArithmetic(DurationTest.groovy:27)

Best,
Martin

Jochen Theodorou wrote:
> Martin C. Martin schrieb:
>> Hi all,
>>
>> ResolveVisitor will look for classes on the classpath by calling 
>> ClassLoader.loadClass().  For performance, it maintains a cache of the 
>> resulting Classes.
>>
>> Why are the classes cached, rather than the resulting ClassNode?  Is 
>> there any reason for the redirect of two labels, which both refer to 
>> the same Class, should go to different instances of ClassNode which 
>> wrap the same Class?
>>
>> If not, should I try changing the cache to cache the ClassNode 

Re: [groovy-dev] class cache in ResolveVisitor

Martin C. Martin schrieb:
> Ok, I committed the change to trunk.
> 
> There's a single test the fails, but it fails with our without the 
> change.  It tests date arithmetic and seems unrelated:
> 
> Testcase: testDurationArithmetic took 0.015 sec
>         FAILED
> A week and a month absolute duration should be the same as the 
> difference between two dates that far apart
>  expected:<3020400000> but was:<3024000000>
>         at 
> groovy.time.DurationTest.testDurationArithmetic(DurationTest.groovy:27)

yes, this test is quite annoying... there is a issue were it fails for 
someone every time. For me it fails never... very strange.

Anyway.... do you have the impression that the build is faster now?

bye blackdrag

--

-- 
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-dev] class cache in ResolveVisitor

Jochen Theodorou wrote:
> Martin C. Martin schrieb:
>> Ok, I committed the change to trunk.
>>
>> There's a single test the fails, but it fails with our without the 
>> change.  It tests date arithmetic and seems unrelated:
>>
>> Testcase: testDurationArithmetic took 0.015 sec
>>         FAILED
>> A week and a month absolute duration should be the same as the 
>> difference between two dates that far apart
>>  expected:<3020400000> but was:<3024000000>
>>         at 
>> groovy.time.DurationTest.testDurationArithmetic(DurationTest.groovy:27)
> 
> yes, this test is quite annoying... there is a issue were it fails for 
> someone every time. For me it fails never... very strange.

I think the test has to do with daylight saving.  For the next week the 
test will fail in the U.S., since one month from now is 28*24 hours 
ahead; one week from now is 7*24 hours ahead; but one week and one month 
from now is into daylight saving, and so is only (28+7)*24 - 1 hours 
from now.

The test tries to adjust for daylight saving, so maybe the above is 
confused.  The the difference between expected & actual above is 1 hour.

> Anyway.... do you have the impression that the build is faster now?

Re: [groovy-dev] class cache in ResolveVisitor

Re: [groovy-dev] class cache in ResolveVisitor

> Jochen Theodorou wrote:
> yes, this test is quite annoying... there is a issue were it 
> fails for someone every time. For me it fails never... very
> strange.

Currently it fails in quite a number of time zones:
http://jira.codehaus.org/browse/GROOVY-3325

--

-- 
Cheers,
Alex

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-dev] class cache in ResolveVisitor

Because Jochen said:

 > Which doesn't mean you shouldn't check that out... creating much more
 > ClassNodes than needed is also a memory thing, and since the compiler
 > ssems to use more memory than in the past it is nice to reduce that
 > again a little, even if it is only for a bit.

Best,
Martin

Alex Tkachman wrote:
> So why was the change if we don't know if it is faster or slower?
> 
> On Sun, Feb 1, 2009 at 6:03 PM, Martin C. Martin 
> <martin@...
<mailto:martin@...>> wrote:
> 
> 
> 
>     Jochen Theodorou wrote:
> 
>         Martin C. Martin schrieb:
> 
>             Ok, I committed the change to trunk.
> 
>             There's a single test the fails, but it fails with our
>             without the change.  It tests date arithmetic and seems
>             unrelated:
> 
>             Testcase: testDurationArithmetic took 0.015 sec
>                    FAILED
>             A week and a month absolute duration should be the same as
>             the difference between two dates that far apart
>              expected:<3020400000> but was:<3024000000>
>                    at
>             groovy.time.DurationTest.testDurationArithmetic(DurationTest.groovy:27)
> 
> 
>         yes, this test is quite annoying... there is a issue were it
>         fails for someone every time. For me it fails never... very strange.
> 
> 
>     I think the test has to do with daylight saving.  For the next week
>     the test will fail in the U.S., since one month from now is 28*24
>     hours ahead; one week from now is 7*24 hours ahead; but one week and
>     one month from now is into daylight saving, and so is only (28+7)*24
>     - 1 hours from now.
> 
>     The test tries to adjust for daylight saving, so maybe the above is
>     confused.  The the difference between expected & actual above is 1 hour.
> 
> 
>         Anyway.... do you have the impression that the build is faster now?
> 
> 
>     Sorry, but I don't have a good sense of how long it took before the
>     change, or after it for that matter.
> 
>     Best,
>     Martin
> 
> 
>     ---------------------------------------------------------------------
>     To unsubscribe from this list, please visit:
> 
>       http://xircles.codehaus.org/manage_email
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-dev] class cache in ResolveVisitor

Re: [groovy-dev] class cache in ResolveVisitor

Ok, makes sense, looks like I misunderstood Jochen's comment.  Does 
someone want to investigate the memory impact of this change?  Or should 
I just back it out?  Or leave it in?

Best,
Martin

Alex Tkachman wrote:
> I mean "check that out" doesn't mean "do and commit" but as I understand 
> means "do, measure and commit if improved". The reason I ask is that I 
> know that piece of code quite well and think that it is better either 
> not to touch it or rewrite. Just opinion
> 
> On Sun, Feb 1, 2009 at 6:34 PM, Martin C. Martin 
> <martin@...
<mailto:martin@...>> wrote:
> 
>     Because Jochen said:
> 
>      > Which doesn't mean you shouldn't check that out... creating much more
>      > ClassNodes than needed is also a memory thing, and since the compiler
>      > ssems to use more memory than in the past it is nice to reduce that
>      > again a little, even if it is only for a bit.
> 
>     Best,
>     Martin
> 
>     Alex Tkachman wrote:
> 
>         So why was the change if we don't know if it is faster or slower?
> 
>         On Sun, Feb 1, 2009 at 6:03 PM, Martin C. Martin
>         <martin@... <mailto:martin@...>
>         <mailto:martin@...
>         <mailto:martin@...>>> wrote:
> 
> 
> 
>            Jochen Theodorou wrote:
> 
>                Martin C. Martin schrieb:
> 
>                    Ok, I committed the change to trunk.
> 
>                    There's a single test the fails, but it fails with our
>                    without the change.  It tests date arithmetic and seems
>                    unrelated:
> 
>                    Testcase: testDurationArithmetic took 0.015 sec
>                           FAILED
>                    A week and a month absolute duration should be the
>         same as
>                    the difference between two dates that far apart
>                     expected:<3020400000> but was:<3024000000>
>                           at
>                  
>          groovy.time.DurationTest.testDurationArithmetic(DurationTest.groovy:27)
> 
> 
>                yes, this test is quite annoying... there is a issue were it
>                fails for someone every time. For me it fails never...
>         very strange.
> 
> 
>            I think the test has to do with daylight saving.  For the
>         next week
>            the test will fail in the U.S., since one month from now is 28*24
>            hours ahead; one week from now is 7*24 hours ahead; but one
>         week and
>            one month from now is into daylight saving, and so is only
>         (28+7)*24
>            - 1 hours from now.
> 
>            The test tries to adjust for daylight saving, so maybe the
>         above is
>            confused.  The the difference between expected & actual above
>         is 1 hour.
> 
> 
>                Anyway.... do you have the impression that the build is
>         faster now?
> 
> 
>            Sorry, but I don't have a good sense of how long it took
>         before the
>            change, or after it for that matter.
> 
>            Best,
>            Martin
> 
> 
>          
>          ---------------------------------------------------------------------
>            To unsubscribe from this list, please visit:
> 
>              http://xircles.codehaus.org/manage_email
> 
> 
> 
> 
>     ---------------------------------------------------------------------
>     To unsubscribe from this list, please visit:
> 
>       http://xircles.codehaus.org/manage_email
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email