HamletDRC | 2 Apr 08:15 2010
Picon

Re: [groovy-dev] Gradle build and DgmConverter


Regarding the OSGi manifest having a dependency marked optional and version
1.2, whereas the ant build marks the dependency as only optional. 

I think that the new way is correct, and that the old manifest was
incorrect. If we declare that a dependency is optional but that there is no
specific version, that means we are stating our software works with version
1.2, 0.2, and 999.2. That does not seem correct! Having a dependency
_without_ a version number attached seems wrong. 

It is not a backwards compatible change, but then this code is in the 1.8
branch and dependency versions are expected to change between major
releases. 

So I say the new OSGi manifest is correct. 

--
Hamlet

Hans Dockter wrote:
> 
> Regarding the groovy test execution.
> 
> The Gradle build now uses the UberTestCases and fork per test. That brings
> the number of failing tests down to 16.
> 
> - Hans
> 
> --
> Hans Dockter
(Continue reading)

Guillaume Laforge | 2 Apr 15:04 2010

Re: [groovy-dev] Gradle build and DgmConverter

Hi Hans,

What are the failing ones?

Also, as it's not easy to do a diff between two code bases, what are
the differences between your groovy-core on GitHub and the main one in
SVN?
You only added the Gradle build files?

Something handy for Groovy developers is the ability to build the
project bypassing all the tests, or just executing one single test.
Are such options available in that build?

Thanks a lot for helping us with the build, it's very much appreciated!

Guillaume

On Wed, Mar 31, 2010 at 11:47, Hans Dockter <hans@...> wrote:
> Regarding the groovy test execution.
>
> The Gradle build now uses the UberTestCases and fork per test. That brings
> the number of failing tests down to 16.
>
> - Hans
>
> --
> Hans Dockter
> Founder, Gradle
> http://www.gradle.org, http://twitter.com/gradleorg
> CEO, Gradle Inc. - Gradle Training, Support, Consulting
(Continue reading)

Guillaume Laforge | 2 Apr 15:39 2010
Picon

[groovy-dev] Time for a 1.7 maintenance release

Hi,

We've got quite a bunch of fixes and improvements in our Groovy 1.7 branch.
It's time we do a 1.7.2 release, that we're going to target after
Easter, on Wednesday.
If you have something in your pipeline for 1.7, please make sure to
have it in for next week.

Thanks a lot for your attention!

--

-- 
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

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

    http://xircles.codehaus.org/manage_email

Hans Dockter | 2 Apr 17:38 2010

Re: [groovy-dev] Gradle build and DgmConverter

Hi Guillaume,

On Fri, Apr 2, 2010 at 3:04 PM, Guillaume Laforge <glaforge-yCVjj/EcxBJg9hUCZPvPmw@public.gmane.org> wrote:
Hi Hans,

What are the failing ones?

I'm on the road at the moment. I will send you a list when I'm back from my easter holidays.
 

Also, as it's not easy to do a diff between two code bases, what are
the differences between your groovy-core on GitHub and the main one in
SVN?
You only added the Gradle build files?

Yes.


Something handy for Groovy developers is the ability to build the
project bypassing all the tests, or just executing one single test.
Are such options available in that build?

Skipping is a generic service in Gradle. You can skip any task via the -x command line options.

gradle build -x test

BTW: In Gradle we have the concept of lifecycle tasks and worker tasks. The worker tasks only depend on what they really need as input. So 'gradle assemble' will only produce the archives without testing anything. 'gradle build' will build the archives plus executing the tests (to be exact all quality-checks if applied, like checkstyle or codenarc).

It would be a one liner to add a task that just produces the jars without the zip and stuff like that. The Groovy developers just need to express what convenience stuff they would like to have.

I haven't added single test execution yet. Nor have I added coverage. I will do this once I'm back. We are doing the same in the Grails build.

- Hans

--
Hans Dockter
Founder, Gradle
http://www.gradle.org, http://twitter.com/gradleorg
CEO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz


Thanks a lot for helping us with the build, it's very much appreciated!

Guillaume

On Wed, Mar 31, 2010 at 11:47, Hans Dockter <hans-H+GgIF+VKBrzs492ZWNkEA@public.gmane.org> wrote:
> Regarding the groovy test execution.
>
> The Gradle build now uses the UberTestCases and fork per test. That brings
> the number of failing tests down to 16.
>
> - Hans
>
> --
> Hans Dockter
> Founder, Gradle
> http://www.gradle.org, http://twitter.com/gradleorg
> CEO, Gradle Inc. - Gradle Training, Support, Consulting
> http://www.gradle.biz
>
>
>
> On Tue, Mar 30, 2010 at 8:38 PM, Hans Dockter <hans-H+GgIF+VKBrzs492ZWNkEA@public.gmane.org> wrote:
>>
>> I have added the upload to the local and remote Maven repo.
>>
>> That leaves us with the one differing osgi value and the failing tests.
>>
>> Regarding the hardwired paths. I have changed the Gradle output layout to
>> the Ant one. That makes it harder to compare the two builds but it solves
>> the issue. I have still 52 failing tests out of 3962. We don't use the
>> suites at the moment but the Groovy auto detection. That might be one
>> reason.
>>
>> - Hans
>>
>> --
>> Hans Dockter
>> Founder, Gradle
>> http://www.gradle.org, http://twitter.com/gradleorg
>> CEO, Gradle Inc. - Gradle Training, Support, Consulting
>> http://www.gradle.biz
>>
>>
>> On Tue, Mar 30, 2010 at 3:35 PM, Paul King <paulk-V+QuBFElvc30CCvOHzKKcA@public.gmane.org> wrote:
>>>
>>> On 30/03/2010 9:39 PM, Hans Dockter wrote:
>>>>
>>>> The gradle build is almost done.
>>>
>>> Great news! Just commenting on the easy one for now... have to come back
>>> to other things later ...  if no-one else jumps in beforehand.
>>>
>>>> One more issue. This source class is in the groovy.jar:
>>>>
>>>> /org/codehaus/groovy/tools/groovydoc/gstringTemplates/GroovyDocTemplateInfo.java
>>>>
>>>> My guess would be that it is not needed there and just made it because
>>>> of the wildcard:
>>>> org/codehaus/groovy/tools/groovydoc/gstringTemplates/**/*.*
>>>
>>> Yes, the class file needs to be there (which should be picked
>>> up fine as per normal class files) but not the source.
>>> I'll change that in the Ant build in the interim too.
>>>
>>>
>>> Cheers, Paul.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>   http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>
>



--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

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

   http://xircles.codehaus.org/manage_email



Guillaume Laforge | 2 Apr 17:50 2010

Re: [groovy-dev] Gradle build and DgmConverter

Hi,

On Fri, Apr 2, 2010 at 17:38, Hans Dockter <hans <at> gradle.biz> wrote:
[...]
I'm on the road at the moment. I will send you a list when I'm back from my easter holidays.

No worries :-)
 
[...]
Skipping is a generic service in Gradle. You can skip any task via the -x command line options.

gradle build -x test

Neat!
 
[...]
BTW: In Gradle we have the concept of lifecycle tasks and worker tasks. The worker tasks only depend on what they really need as input. So 'gradle assemble' will only produce the archives without testing anything. 'gradle build' will build the archives plus executing the tests (to be exact all quality-checks if applied, like checkstyle or codenarc).

It would be a one liner to add a task that just produces the jars without the zip and stuff like that. The Groovy developers just need to express what convenience stuff they would like to have.

Okay, we can add such things progressively later on.
Nice to know it's going to be easy one-liners solutions!
 
I haven't added single test execution yet. Nor have I added coverage. I will do this once I'm back. We are doing the same in the Grails build.

Okie dokie!


--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
Eric Caspole | 3 Apr 01:21 2010
Picon

[groovy-dev] boolean performance

Hi Groovy people,
I noticed a slowdown in one of my apps when I moved to 1.7.1, and I finally narrowed it down to use of booleans in
my code, more or less in line with this silly test script. When there is explicit use of a boolean, the
function is much slower than with 1.6.7. Otherwise it is good. I can work around this, I was just wondering
if someone who knows the details could comment on it, and if it will get better. It's hard to remember rules
like this.
Thanks,
Eric

####################

  17:52:45 [1130]$ echo ${JAVA_HOME}
/opt/jdk1.6.0_18
  17:53:45 [1131]$ /opt/jdk1.6.0_18/bin/java -version
java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) 64-Bit Server VM (build 16.0-b13, mixed mode)
  17:54:01 [1132]$ 
  17:54:06 [1132]$ time ~/groovy-1.6.7/bin/groovy bench 18
24157817
24157817
24157817
24157817
24157817
bool = 4396, no-var = 4039, no-def-var-bool = 7593, no-def-var-int = 7890 def-var-int = 4642

real    0m29.912s
user    0m37.416s
sys     0m0.272s
  17:54:58 [1133]$ time ~/groovy-1.7.1/bin/groovy bench 18
24157817
24157817
24157817
24157817
24157817
bool = 12074, no-var = 4047, no-def-var-bool = 14319, no-def-var-int = 7992 def-var-int = 4620

real    0m44.414s
user    0m50.972s
sys     0m0.333s

######################

def fibo_r ( n ) {
    boolean done = false;
    if ( n < 2)
      done = true
    return(done ? 1 : fibo_r( n - 2) + fibo_r( n - 1));
}
def fibo ( n ) { 
   r = fibo_r( n); 
   println  r
}

def fubo_r ( n ) { 
    done = false;
    if ( n < 2)
      done = true
    return(done ? 1 : fubo_r( n - 2) + fubo_r( n - 1));
}
def fubo ( n ) { 
   r = fubo_r( n); 
   println  r
}

def febo_r ( n ) { 
    done = 0;
    if ( n < 2)
      done = 1;
    return((done==1) ? 1 : febo_r( n - 2) + febo_r( n - 1));
}
def febo ( n ) { 
   r = febo_r( n); 
   println  r
}

def fabo_r ( n ) { 
    def done = 0;
    if ( n < 2)
      done = 1;
    return((done==1) ? 1 : fabo_r( n - 2) + fabo_r( n - 1));
}
def fabo ( n ) { 
   r = fabo_r( n); 
   println  r
}

def fobo_r ( n ) { 
    return ((n < 2) ? 1 : fobo_r( n - 2) + fobo_r( n - 1));
}
def fobo( n ) { 
   r = fobo_r( n); 
   println  r
}

def p = args[0].toInteger()
def start = System.currentTimeMillis();
fibo(2*p);
def end1 = System.currentTimeMillis();
fobo(2*p);
def end2 = System.currentTimeMillis();
fubo(2*p);
def end3 = System.currentTimeMillis();
febo(2*p);
def end4 = System.currentTimeMillis();
fabo(2*p);
def end5 = System.currentTimeMillis();
println 'bool = ' + (end1 - start) + ', no-var = ' + (end2 - end1) + ', no-def-var-bool = ' + (end3 - end2) + ',
no-def-var-int = ' + (end4 - end3) + ' def-var-int = ' + (end5 - end4)

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

    http://xircles.codehaus.org/manage_email

Jochen Theodorou | 6 Apr 11:49 2010
Picon

Re: [groovy-dev] boolean performance

Eric Caspole wrote:
> I noticed a slowdown in one of my apps when I moved
> to 1.7.1, and I finally narrowed it down to use of booleans in my
> code, more or less in line with this silly test script. When there is
> explicit use of a boolean, the function is much slower than with
> 1.6.7. Otherwise it is good. I can work around this, I was just
> wondering if someone who knows the details could comment on it, and
> if it will get better. It's hard to remember rules like this.

I cannot think of a change that would cause that... strange.

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

Guillaume Laforge | 7 Apr 18:02 2010
Picon

[groovy-dev] [ANN] Groovy 1.7.2 released

Hi all,


The Groovy development team is pleased to announce the release of Groovy 1.7.2, a maintenance release of the 1.7.x stable branch.

For the details of bug fixes, improvements and new features, please have a look at our JIRA release notes:

I've updated the download page with links to the deliverables:

Thanks a lot to all involved, developers as well as users reporting issues improvement ideas, and helping us improve Groovy everyday!

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
Russel Winder | 7 Apr 19:34 2010
Picon

[groovy-dev] Groovy 1.7.2 Windows installer

Joachim,

So as to avoid being told I haven't answered your email about this topic
I'll answer before you ask ;-)

As far as I can tell the Gant 1.9.2 compiled against Groovy 1.7.1 should
work fine with Groovy 1.7.2 and so should be usable for the Groovy 1.7.2
installer which I suspect will not be long in coming out.

If there are any problems I can always release a Gant 1.9.3 compiled
against Groovy 1.7.2.

--

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder <at> ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@...
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Hans Dockter | 8 Apr 00:24 2010

Re: [groovy-dev] Gradle build and DgmConverter

I have updated the Gradle branch to the latest Groovy sources.

The failing tests are:

groovy.execute.ExecuteTest:testExecuteCommandLineProcessAndUseWaitForOrKill
groovy.execute.ExecuteTest:testExecuteCommandLineWithEnvironmentProperties
groovy.lang.GroovySystemTest:testGroovyVersion
org.codehaus.groovy.ant.GroovycTest:testGroovycTest1_ForkGroovy_NoClasspath
org.codehaus.groovy.ant.GroovycTest:testGroovycTest1_ForkGroovy_WithGroovyClasspath
org.codehaus.groovy.ant.GroovycTest:testGroovycTest1_ForkGroovy_WithJavaClasspath
org.codehaus.groovy.ant.GroovycTest:testGroovycTest1_ForkGroovy_WithBothClasspath
org.codehaus.groovy.ant.GroovycTest:testGroovycTest1_Joint_ForkGroovy_NoClasspath
org.codehaus.groovy.ant.GroovycTest:testGroovycTest1_Joint_ForkGroovy_WithGroovyClasspath
org.codehaus.groovy.ant.GroovycTest:testGroovycTest1_Joint_ForkGroovy_WithJavaClasspath
org.codehaus.groovy.ant.GroovycTest:testGroovycTest1_Joint_ForkGroovy_WithBothClasspath
org.codehaus.groovy.ant.GroovycTest:testGroovycTest1_ForkGroovy_NoClasspath_WithJavaHome
org.codehaus.groovy.ant.GroovycTest:testGroovycTest1_ForkGroovy_WithGroovyClasspath_WithJavaHome
org.codehaus.groovy.ant.GroovycTest:testGroovycTest1_ForkGroovy_WithJavaClasspath_WithJavaHome
org.codehaus.groovy.ant.GroovycTest:testGroovycTest1_ForkGroovy_WithBothClasspath_WithJavaHome
org.codehaus.groovy.ast.LineColumnChecker:oneLineDef
groovy.ListTest:testFlattenListWithSuppliedClosure

To run a single test you can type now:

'./gradlew testSingleGroovySystemTest' which will execute the tests with a single include '**/GroovySystemtTest.class'

- Hans

--
Hans Dockter
Founder, Gradle
http://www.gradle.org, http://twitter.com/gradleorg
CEO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz




On Fri, Apr 2, 2010 at 5:50 PM, Guillaume Laforge <glaforge-yCVjj/EcxBJg9hUCZPvPmw@public.gmane.org> wrote:
Hi,

On Fri, Apr 2, 2010 at 17:38, Hans Dockter <hans <at> gradle.biz> wrote:
[...]
I'm on the road at the moment. I will send you a list when I'm back from my easter holidays.

No worries :-)
 
[...]
Skipping is a generic service in Gradle. You can skip any task via the -x command line options.

gradle build -x test

Neat!
 
[...]

BTW: In Gradle we have the concept of lifecycle tasks and worker tasks. The worker tasks only depend on what they really need as input. So 'gradle assemble' will only produce the archives without testing anything. 'gradle build' will build the archives plus executing the tests (to be exact all quality-checks if applied, like checkstyle or codenarc).

It would be a one liner to add a task that just produces the jars without the zip and stuff like that. The Groovy developers just need to express what convenience stuff they would like to have.

Okay, we can add such things progressively later on.
Nice to know it's going to be easy one-liners solutions!
 
I haven't added single test execution yet. Nor have I added coverage. I will do this once I'm back. We are doing the same in the Grails build.

Okie dokie!


--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one


Gmane