Re: Gradle build updates

2017-12-12 Thread Cédric Champeau 
@Paul I only kept the `java7Compatible` checks to make it easier to
backport changes. Each branch can now be adjusted as needed.

2017-12-13 7:35 GMT+01:00 Paul King :

> Actually, it looks like you are still using skipIndy but why check for
> java7Compatible when that is out minimum requirement anyway?
>
> On Wed, Dec 13, 2017 at 4:21 PM, Paul King  wrote:
>
>> Should we just delete indy.gradle (obviously not in 2_4_X)? Otherwise the
>> build fails for me when I used an old commandline with -PskipIndy=true.
>>
>> Cheers, Paul.
>>
>> On Mon, Dec 11, 2017 at 9:54 AM, Cédric Champeau <
>> cedric.champ...@gmail.com> wrote:
>>
>>> Hi folks,
>>>
>>> As promised I spent some time reworking the Gradle build. For those
>>> interested, you can take a look at the progress checking out my branch [1].
>>>
>>> You'll notice that the build should be much faster [2], especially after
>>> changes, and it now makes use of the build cache. I also got rid of the
>>> crazy way to build the indy jars, it's now streamlined.
>>>
>>> I'm interested in feedback, since it's a potential breaking change. If
>>> everything goes well, I will backport the changes to the 2.5/2.6 builds (so
>>> please avoid changes there too).
>>>
>>> Thanks a lot,
>>>
>>> [1] https://github.com/melix/groovy-core/commits/cc/rebuild-gradle
>>> [2] https://scans.gradle.com/s/msvk2xi57div2
>>>
>>
>>
>

Re: Gradle build updates

2017-12-12 Thread Paul King 
Actually, it looks like you are still using skipIndy but why check for
java7Compatible when that is out minimum requirement anyway?

On Wed, Dec 13, 2017 at 4:21 PM, Paul King  wrote:

> Should we just delete indy.gradle (obviously not in 2_4_X)? Otherwise the
> build fails for me when I used an old commandline with -PskipIndy=true.
>
> Cheers, Paul.
>
> On Mon, Dec 11, 2017 at 9:54 AM, Cédric Champeau <
> cedric.champ...@gmail.com> wrote:
>
>> Hi folks,
>>
>> As promised I spent some time reworking the Gradle build. For those
>> interested, you can take a look at the progress checking out my branch [1].
>>
>> You'll notice that the build should be much faster [2], especially after
>> changes, and it now makes use of the build cache. I also got rid of the
>> crazy way to build the indy jars, it's now streamlined.
>>
>> I'm interested in feedback, since it's a potential breaking change. If
>> everything goes well, I will backport the changes to the 2.5/2.6 builds (so
>> please avoid changes there too).
>>
>> Thanks a lot,
>>
>> [1] https://github.com/melix/groovy-core/commits/cc/rebuild-gradle
>> [2] https://scans.gradle.com/s/msvk2xi57div2
>>
>
>

Re: Gradle build updates

2017-12-12 Thread Paul King 
Should we just delete indy.gradle (obviously not in 2_4_X)? Otherwise the
build fails for me when I used an old commandline with -PskipIndy=true.

Cheers, Paul.

On Mon, Dec 11, 2017 at 9:54 AM, Cédric Champeau 
wrote:

> Hi folks,
>
> As promised I spent some time reworking the Gradle build. For those
> interested, you can take a look at the progress checking out my branch [1].
>
> You'll notice that the build should be much faster [2], especially after
> changes, and it now makes use of the build cache. I also got rid of the
> crazy way to build the indy jars, it's now streamlined.
>
> I'm interested in feedback, since it's a potential breaking change. If
> everything goes well, I will backport the changes to the 2.5/2.6 builds (so
> please avoid changes there too).
>
> Thanks a lot,
>
> [1] https://github.com/melix/groovy-core/commits/cc/rebuild-gradle
> [2] https://scans.gradle.com/s/msvk2xi57div2
>

Re: [jira] [Commented] (GROOVY-8406) DefaultGroovyMethods missing Array support

2017-12-12 Thread Paul King 
They are in the pull request but not merged yet. I am giving a few
days for any further feedback, then I'll merge.

cheers, Paul.

On Wed, Dec 13, 2017 at 7:51 AM, Nathan Harvey (JIRA)  wrote:
>
> [ 
> https://issues.apache.org/jira/browse/GROOVY-8406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16288323#comment-16288323
>  ]
>
> Nathan Harvey commented on GROOVY-8406:
> ---
>
> Thanks Paul. Yes, I think it should be added for IDE/CompileStatic/user 
> inference. Great list, are these implemented now?
>
>> DefaultGroovyMethods missing Array support
>> --
>>
>> Key: GROOVY-8406
>> URL: https://issues.apache.org/jira/browse/GROOVY-8406
>> Project: Groovy
>>  Issue Type: Improvement
>>Affects Versions: 2.5.0-beta-1
>>Reporter: Nathan Harvey
>>Assignee: Paul King
>>Priority: Minor
>>  Labels: easyfix
>>
>> The methods every, any, and collect support instances of Iterable and 
>> Iterator, but do not include equivalent methods for support arrays.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.14#64029)

Re: Gradle build updates

2017-12-12 Thread Daniel.Sun 

groovy-2.5.0-SNAPSHOT has the same trivial issue(".shelf").

In addition, Groovy Version can not be shown properly(Groovy Version:
#ImplementationVersion#):

C:\Users\Daniel>groovy -v
Groovy Version: #ImplementationVersion# JVM: 1.8.0_121 Vendor: Oracle
Corporation OS: Windows 10


Cheers,
Daniel.Sun






--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: Gradle build updates

2017-12-12 Thread Daniel.Sun 
Thank you,  Cédric  :)

 I tried to build from groovy-2.6.0-SNAPSHOT source code and found a
trivial issue:  apache-groovy-src-2.6.0-SNAPSHOT.zip file contains
"groovy-2.6.0-SNAPSHOT/.shelf", which should be excluded IMO.


Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: Keeping DGM helper methods?

2017-12-12 Thread Daniel.Sun 
+1

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: Gradle build updates

2017-12-12 Thread Cédric Champeau 
Alright folks, I have backported the changes to both 2.5.x and 2.6.x. Let
me know if you see any problem.

Note that I haven't changed the CI builds, but they probably need to, as
there's no reason to differentiate the indy and non indy builds now.


2017-12-12 9:34 GMT+01:00 Daniel.Sun :

> > I have pushed a proper fix.
> The proper fix is much better :)
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

RE: CI builds for Groovy

2017-12-12 Thread eric.milles 
The JDK 8 builds are still not running because the agent is listed as 
disconnected.

Re: CI builds for Groovy

2017-12-12 Thread Cédric Champeau 
done, thanks for the heads up

2017-12-12 16:02 GMT+01:00 :

> The build server mentions insufficient disk space.  Could someone have a
> look?
>
>
>
> *From:* Milles, Eric (TR Technology & Ops)
> *Sent:* Monday, December 11, 2017 10:40 AM
> *To:* dev@groovy.apache.org
> *Subject:* CI builds for Groovy
>
>
>
> Has anyone noticed that there are 40+ pending changes waiting to build in
> TeamCity (Groovy 2.5) and no builds have run for several days?  Same goes
> for 2.4, 2.6, 3.0.
>
>
>
> *Eric Milles*
> Lead Software Engineer
>
> *Thomson Reuters*
>
> Email: eric.mil...@thomsonreuters.com
>
> Phone: 651-848-7040
>
>
>

Keeping DGM helper methods?

2017-12-12 Thread Jochen Theodorou 

Hi all,


If we all agree on using only Indy in Groovy 3, we could get rid of all 
the DGM helper methods. What do you guys think?


bye Jochen

Re: groovy git commit: Refine DgmConverter to gain better IO performance

2017-12-12 Thread Cédric Champeau 
Buffered writing only makes sense if the writes are smaller than the buffer
size, and that you do multiple writes. This is not the case here, so
buffered won't help.

2017-12-12 16:34 GMT+01:00 Daniel.Sun :

> Hi  Cédric,
>
>   > Using a buffered writer is actually slower when you know the bytes
> to write.
>   To be frank, it's hard for me to believe... because
> BufferedOutputStream will keep the bytes to output util the buffer is full,
> so it can reduce the times to access the disk(As we all know, accessing
> disk
> is much slower than accessing memory).
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: groovy git commit: Refine DgmConverter to gain better IO performance

2017-12-12 Thread Daniel.Sun 
Hi  Cédric,

  > Using a buffered writer is actually slower when you know the bytes
to write.
  To be frank, it's hard for me to believe... because
BufferedOutputStream will keep the bytes to output util the buffer is full,
so it can reduce the times to access the disk(As we all know, accessing disk
is much slower than accessing memory).

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

RE: CI builds for Groovy

2017-12-12 Thread eric.milles 
The build server mentions insufficient disk space.  Could someone have a look?

From: Milles, Eric (TR Technology & Ops)
Sent: Monday, December 11, 2017 10:40 AM
To: dev@groovy.apache.org
Subject: CI builds for Groovy

Has anyone noticed that there are 40+ pending changes waiting to build in 
TeamCity (Groovy 2.5) and no builds have run for several days?  Same goes for 
2.4, 2.6, 3.0.

Eric Milles
Lead Software Engineer
Thomson Reuters
Email: eric.mil...@thomsonreuters.com
Phone: 651-848-7040

Re: groovy git commit: Refine DgmConverter to gain better IO performance

2017-12-12 Thread Cédric Champeau 
Why is that more performant ? Using a buffered writer is actually slower
when you know the bytes to write. I don't think it's an improvement. We had
removed buffering in the past for that same reason.

2017-12-12 12:54 GMT+01:00 :

> Repository: groovy
> Updated Branches:
>   refs/heads/master dc30ad7d1 -> 1b248d367
>
>
> Refine DgmConverter to gain better IO performance
>
>
> Project: http://git-wip-us.apache.org/repos/asf/groovy/repo
> Commit: http://git-wip-us.apache.org/repos/asf/groovy/commit/1b248d36
> Tree: http://git-wip-us.apache.org/repos/asf/groovy/tree/1b248d36
> Diff: http://git-wip-us.apache.org/repos/asf/groovy/diff/1b248d36
>
> Branch: refs/heads/master
> Commit: 1b248d367d7e931becdcc47eaffc9073b2851ac2
> Parents: dc30ad7
> Author: sunlan 
> Authored: Tue Dec 12 19:54:35 2017 +0800
> Committer: sunlan 
> Committed: Tue Dec 12 19:54:35 2017 +0800
>
> --
>  .../org/codehaus/groovy/tools/DgmConverter.java | 20 
>  1 file changed, 16 insertions(+), 4 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/groovy/blob/1b248d36/src/main/org/
> codehaus/groovy/tools/DgmConverter.java
> --
> diff --git a/src/main/org/codehaus/groovy/tools/DgmConverter.java
> b/src/main/org/codehaus/groovy/tools/DgmConverter.java
> index ba714bb..5228a93 100644
> --- a/src/main/org/codehaus/groovy/tools/DgmConverter.java
> +++ b/src/main/org/codehaus/groovy/tools/DgmConverter.java
> @@ -29,6 +29,7 @@ import org.objectweb.asm.Label;
>  import org.objectweb.asm.MethodVisitor;
>  import org.objectweb.asm.Opcodes;
>
> +import java.io.BufferedOutputStream;
>  import java.io.File;
>  import java.io.FileOutputStream;
>  import java.io.IOException;
> @@ -93,12 +94,23 @@ public class DgmConverter implements Opcodes {
>  cw.visitEnd();
>
>  final byte[] bytes = cw.toByteArray();
> +
>  File targetFile = new File(targetDirectory + className +
> ".class").getCanonicalFile();
>  targetFile.getParentFile().mkdirs();
> -final FileOutputStream fileOutputStream = new
> FileOutputStream(targetFile);
> -fileOutputStream.write(bytes);
> -fileOutputStream.flush();
> -fileOutputStream.close();
> +
> +BufferedOutputStream bufferedOutputStream = null;
> +try {
> +bufferedOutputStream =
> +new BufferedOutputStream(
> +new FileOutputStream(targetFile));
> +
> +bufferedOutputStream.write(bytes);
> +bufferedOutputStream.flush();
> +} finally {
> +if (null != bufferedOutputStream) {
> +bufferedOutputStream.close();
> +}
> +}
>  }
>
>  GeneratedMetaMethod.DgmMethodRecord.saveDgmInfo(records,
> targetDirectory+"/META-INF/dgminfo");
>
>

Re: Why do we have Jitpack repo?

2017-12-12 Thread Daniel.Sun 
Hi  Cédric,

  I added Jitpack as a repository, but it is no longer used. Feel free
to remove  it.

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: Gradle build updates

2017-12-12 Thread Daniel.Sun 
> I have pushed a proper fix.
The proper fix is much better :)

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Why do we have Jitpack repo?

2017-12-12 Thread Cédric Champeau 
While updating the Gradle build I discovered that we use Jitpack as a
repository.

Does anyone know why? It's a bad practice since it implies source
dependencies which are by nature not reproducible (or, at best, fragile).

Thanks