Re: Groovy as a JVM-less Bash-Script/Perl/Python alternative ?

[Paolo Di Tommaso]

I maintain a quite popular project for scientific data analysis pipelines
 and, yes, both startup time and
memory footprint are usually reported as two minor but annoying groovy
drawbacks.

Being able to run Groovy on GraalVM would surely bring massive
improvements. At this regard, I saw almost no interest in this community on
the possibility to have a groovy interpreter/compiled based on the new Truffle
subsystem , which it
has already proved to be able to deliver a minimal footprint and high
performance with dynamically typed lang such Ruby
, R ,
Python , and others
.

I think this should be a possibility to be taken in consideration.

p

On Thu, Aug 6, 2020 at 1:29 AM Paul King  wrote:

> Re: quick startup time: also consider GroovyServ[1]. It pre-dates the
> gradle daemon, but is a similar concept some folks might be familiar with.
>
> Re: Bundling a JVM: it is certainly doable but we'd likely do that in the
> broader community outside ASF unless someone else solves the GPL licensing
> issue on most JVM artifacts.
>
> Re: GraalVM: that is something we want to make easier for Groovy 4 but in
> the first instance tackling a subset of Groovy (e.g. CompileStatic code)
> rather than the arbitrary scripts I'd envisage for scripting.
>
> Re: Groovy for OS scripting: this has certainly been an area which Groovy
> has historically excelled in compared to other JVM alternatives. There is
> no doubt scope for improving things though. It might pay to see if there is
> anything we can learn from initiatives like JBang[2] which seem very active
> recently.
>
> Cheers, Paul.
>
> [1] https://kobo.github.io/groovyserv/
> [2] https://github.com/jbangdev/jbang
>
> On Thu, Aug 6, 2020 at 1:04 AM MG  wrote:
>
>> In my opinion the reason why Bash-Script/Perl/Python are the predominant
>> Linux script languages is, because all or most of them come preinstalled on
>> every Linux distribution, and because they run standalone with minimal
>> startup time and memory fotprint.
>> One of the great things about Grooy is, that it is "one language for
>> everything", and as a dynamic language with a concise and C-based (i.e.
>> widely used/understood) syntax, good File support, String interpolation and
>> powerful closures, it is well suited to be used as a modern Script
>> language.
>>
>> However Groovy is dependent on an existing Java installation (of the
>> correct version).
>>
>> Since JVM based applications are, in my experience, often massively
>> disliked by people outside of the JVM community (e.g. sys admins), I have
>> been wondering whether Groovy could/should supply a precompiled, memory
>> footprint optimized, standalone version that runs without a JVM, so that it
>> could be used for Linux (Windows) scripting the same as
>> Bash-Script/Perl/Python are, and if GraalVM could be the principal way to
>> do it (https://www.graalvm.org/docs/reference-manual/native-image/)
>>  ?
>>
>> Thoughts ?
>> mg
>>
>>
>>
>>

Re: [PROPOSAL]Support conditional return

[Paolo Di Tommaso]

It's not much easier a conditional expression (or even the elvis operator)?

```
def m() {
def r = callSomeMethod()
return r != null ? r : theDefaultResult
}
```


On Sat, Jul 25, 2020 at 8:56 PM Daniel Sun  wrote:

> Hi all,
>
>  We always have to check the returning value, if it match some
> condition, return it. How about simplifying it? Let's see an example:
>
> ```
> def m() {
> def r = callSomeMethod()
> if (null != r) return r
>
> return theDefaultResult
> }
> ```
>
> How about simplifying the above code as follows:
> ```
> def m() {
> return? callSomeMethod()
> return theDefaultResult
> }
> ```
>
> Futhermore, we could make the conditional return more general:
> ```
> def m() {
> return(r -> r != null) callSomeMethod() // we could do more checking,
> e.g. r > 10
> return theDefaultResult
> }
> ```
>
> Any thoughts?
>
> Cheers,
> Daniel Sun
>

Re: next releases

[Paolo Di Tommaso]

This issue causes a horrible experience with IntelliJ and groovy code
annotated for bytecode generation with (e.g. Grails GORM, Micronaut, etc).

https://issues.apache.org/jira/projects/GROOVY/issues/GROOVY-9209




On Thu, Jul 2, 2020 at 12:41 AM Paul King  wrote:

>
> Hi everyone,
>
> I'd like to do another 2.5 and 3 release late this week or early next week.
> Time to work on any bug fixes that you want included or let me know if the
> timing doesn't work.
>
> Thanks, Paul.
>
>

JsonSlurper support for Path

[Paolo Di Tommaso]

Hi all,

I've just realised that JsonSluper does not have a parse method for a Path
parameter.

Would you consider a PR to add the support for it?


Cheers,
Paolo

Re: About eliminating ambiguities of method call with closure argument

[Paolo Di Tommaso]

I see, then I agree that it's not a big issue.

I was confused because I saw that Gradle supports that syntax. Not
understanding how they can, then?



Cheers, p

On Wed, Apr 1, 2020 at 3:30 PM Paul King  wrote:

> Groovy 2.5 and earlier don't support this form. But yes, if any Groovy 3
> DSLs were created in the last few weeks (or longer if we count betas/RCs)
> and they used this form, then they would break.
>
> Cheers, Paul.
>
> On Wed, Apr 1, 2020 at 10:56 PM Paolo Di Tommaso <
> paolo.ditomm...@gmail.com> wrote:
>
>> Arriving late to this thread, therefore not sure it has already
>> discussed, but have you taken in consideration that changing the method
>> call argument interpretation for the case 1, eg.
>>
>> meth
>> { p ->
>> }
>>
>> it will break all DSL in which the user scripts use this form? Just
>> thinking Gradle for example.
>>
>>
>> Cheers,
>> Paolo
>>
>>
>> On Mon, Mar 30, 2020 at 3:06 PM MG  wrote:
>>
>>> I see, that's a though one, then, if one wants people to be able to put
>>> heir braces where they want*...
>>>
>>> I have turned this back and forth in my mind, and I think the current
>>> Groovy 2.5.x behavior is actually a good/practical compromise, even though
>>> it might appear confusing at first in some cases.
>>>
>>> Rationale:
>>>
>>> *Alternative case 1: Having a the closure on a new line always being
>>> separate from the previous line*
>>>
>>> This would prohibit Groovy code where a closure is used like a block
>>> construct (a very powerful Groovy pattern imho) to be written as (e.g.):
>>>
>>> void myDatabaseProcessingMethod() {
>>>  // The closure following the next line will be passed as parameter
>>> to the forEachResultSetRow method
>>> sqe.forEachResultSetRow("select * from PERSON")
>>>  {
>>> // many lines of result row processing
>>> }
>>>
>>> // Note: Forcing people to write this with a line-continuation
>>> character to me would make no sense, e.g.:
>>> sqe.forEachResultSetRow("select * from PERSON") \
>>>  {
>>> // many lines of result row processing
>>> }
>>> }
>>>
>>> forcing people to put opening brackets on the same line as the
>>> forEachResultSetRow call, thereby potentially breaking their coding style.
>>>
>>> *Alternative case 2: Having a the closure on a new line always being
>>> bound to the previous line*
>>>
>>> This would force Spock (and maybe other DSL) users to use a semicolon at
>>> the end of line 1 in your example, which is a breaking change. It also
>>> could lead to silently failing code.
>>>
>>>
>>> *Conclusion*
>>>
>>> So I would keep the Groovy 2.5.x behavior, but if I absolutely had to
>>> choose one of the above options, I would go with the opposite of what you
>>> propose, and always bind the closure to the previous line, since otherwise
>>> there would be no acceptable way for the closure-as-block-construct pattern
>>> to be able to support having the block construct start on its own line (I
>>> don't see putting in a line continuation character as a viable solution
>>> here), whereas for DSLs putting in a semicolon in these cases would imho be
>>> OK (legacy breaking changes/silently failing code put aside).
>>>
>>> (The only other ideas I have is to support making the parsing behavior
>>> switchable, enabling one of the above behaviors through e.g. an
>>> "@ParseSpock" annotation (with always binding to the previous line being
>>> the default behavior), or by allowing a DSL/library developer to qualify
>>> whether a closure parameter can be bound from the next line or not; but 1)
>>> I have no idea if that is even technically feasible, and 2) I doubt we
>>> would want to go down that route.)
>>>
>>> Cheers,
>>> mg
>>>
>>> *Note: I have put opening braces on the same line since programming C in
>>> the 80s, so personally have no problem with this :-)
>>>
>>>
>>>
>>> On 29/03/2020 04:25, Daniel.Sun wrote:
>>>
>>> Hi MG,
>>>
>>>  Understood. Some spock code care the differences, e.g. the following
>>> code
>>> ```
>>>  modification| expected
>>>  { Instant i, ZoneId z -> i.plusSeconds(1) } | defaultInstant.plusSeconds(1)
>>> ```
>>>
>>> is expected to parsed as 2 binary expressions:
>>>
>>> ```
>>>  modification| expected
>>> ```
>>> and
>>> ```
>>>  { Instant i, ZoneId z -> i.plusSeconds(1) } | defaultInstant.plusSeconds(1)
>>> ```
>>>
>>>
>>> Cheers,
>>> Daniel.Sun
>>>
>>>
>>>
>>> -
>>> Apache Groovy committer & PMC member
>>> Blog: http://blog.sunlan.me
>>> Twitter: @daniel_sun
>>>
>>> --
>>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>>
>>>
>>>

Re: About eliminating ambiguities of method call with closure argument

[Paolo Di Tommaso]

Arriving late to this thread, therefore not sure it has already discussed,
but have you taken in consideration that changing the method call argument
interpretation for the case 1, eg.

meth
{ p ->
}

it will break all DSL in which the user scripts use this form? Just
thinking Gradle for example.


Cheers,
Paolo


On Mon, Mar 30, 2020 at 3:06 PM MG  wrote:

> I see, that's a though one, then, if one wants people to be able to put
> heir braces where they want*...
>
> I have turned this back and forth in my mind, and I think the current
> Groovy 2.5.x behavior is actually a good/practical compromise, even though
> it might appear confusing at first in some cases.
>
> Rationale:
>
> *Alternative case 1: Having a the closure on a new line always being
> separate from the previous line*
>
> This would prohibit Groovy code where a closure is used like a block
> construct (a very powerful Groovy pattern imho) to be written as (e.g.):
>
> void myDatabaseProcessingMethod() {
>  // The closure following the next line will be passed as parameter to
> the forEachResultSetRow method
> sqe.forEachResultSetRow("select * from PERSON")
>  {
> // many lines of result row processing
> }
>
> // Note: Forcing people to write this with a line-continuation
> character to me would make no sense, e.g.:
> sqe.forEachResultSetRow("select * from PERSON") \
>  {
> // many lines of result row processing
> }
> }
>
> forcing people to put opening brackets on the same line as the
> forEachResultSetRow call, thereby potentially breaking their coding style.
>
> *Alternative case 2: Having a the closure on a new line always being bound
> to the previous line*
>
> This would force Spock (and maybe other DSL) users to use a semicolon at
> the end of line 1 in your example, which is a breaking change. It also
> could lead to silently failing code.
>
>
> *Conclusion*
>
> So I would keep the Groovy 2.5.x behavior, but if I absolutely had to
> choose one of the above options, I would go with the opposite of what you
> propose, and always bind the closure to the previous line, since otherwise
> there would be no acceptable way for the closure-as-block-construct pattern
> to be able to support having the block construct start on its own line (I
> don't see putting in a line continuation character as a viable solution
> here), whereas for DSLs putting in a semicolon in these cases would imho be
> OK (legacy breaking changes/silently failing code put aside).
>
> (The only other ideas I have is to support making the parsing behavior
> switchable, enabling one of the above behaviors through e.g. an
> "@ParseSpock" annotation (with always binding to the previous line being
> the default behavior), or by allowing a DSL/library developer to qualify
> whether a closure parameter can be bound from the next line or not; but 1)
> I have no idea if that is even technically feasible, and 2) I doubt we
> would want to go down that route.)
>
> Cheers,
> mg
>
> *Note: I have put opening braces on the same line since programming C in
> the 80s, so personally have no problem with this :-)
>
>
>
> On 29/03/2020 04:25, Daniel.Sun wrote:
>
> Hi MG,
>
>  Understood. Some spock code care the differences, e.g. the following
> code
> ```
>  modification| expected
>  { Instant i, ZoneId z -> i.plusSeconds(1) } | defaultInstant.plusSeconds(1)
> ```
>
> is expected to parsed as 2 binary expressions:
>
> ```
>  modification| expected
> ```
> and
> ```
>  { Instant i, ZoneId z -> i.plusSeconds(1) } | defaultInstant.plusSeconds(1)
> ```
>
>
> Cheers,
> Daniel.Sun
>
>
>
> -
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
>
>

Re: [VOTE] Release Apache Groovy 2.5.10

[Paolo Di Tommaso]

I think just hit this issue:

java.lang.ClassCastException: org.codehaus.groovy.ast.stmt.ReturnStatement
cannot be cast to org.codehaus.groovy.ast.stmt.BlockStatement
at
org.codehaus.groovy.classgen.FinalVariableAnalyzer.fallsThrough(FinalVariableAnalyzer.java:480)
at
org.codehaus.groovy.classgen.FinalVariableAnalyzer.visitSwitch(FinalVariableAnalyzer.java:344)


The complete stack trace is at this link .


p


On Thu, Mar 5, 2020 at 11:07 AM Paul King  wrote:

> Thanks Vaidotas,
>
> This only affects switches which are the last statement of the enclosing
> method (or script) and which have a case statement containing only a break
> statement and no other statements.
> There are some simple workarounds too: add any statement in the case or
> add any statement after the switch.
> While certainly not ideal for this regression to sneak through, since its
> scope is limited and workarounds simple, my current thinking is to proceed
> with the release and add a known issue to the release notes.
> There are some other important changes in the release which would be good
> not to hold up but we should plan for a 2.5.11 release shortly.
> Users can examine any known issues and decide whether it will likely
> impact them or whether they should wait until the next release.
>
> Cheers, Paul.
>
>
> On Thu, Mar 5, 2020 at 7:15 PM Vaidotas Valuckas 
> wrote:
>
>> Hello,
>>
>> I found a regression in a fix to GROOVY-9424 that breaks compilation of
>> switch statements in certain cases.
>> Commented on https://issues.apache.org/jira/browse/GROOVY-9424 with
>> details.
>>
>>
>> Kind regards,
>> Vaidotas
>>
>> On 2020/03/03 13:35:11, Paul King  wrote:
>> > Here is the real content!>
>> >
>> > >
>> >
>> > Dear development community,>
>> >
>> > I am happy to start the VOTE thread for a Groovy 2.5.10 release!>
>> >
>> > This release includes 12 bug fixes/improvements as outlined in the>
>> > changelog:>
>> >
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12346773>
>>
>> >
>> > Tag:>
>> >
>> https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_5_10>
>>
>> > Tag commit id: fb068ef1829a98bc989eb438fe3e299071c17b5d>
>> >
>> > The artifacts to be voted on are located as follows (r38368).>
>> > Source release:
>> https://dist.apache.org/repos/dist/dev/groovy/2.5.10/sources>
>> > Convenience binaries:>
>> > https://dist.apache.org/repos/dist/dev/groovy/2.5.10/distribution>
>> >
>> > Release artifacts are signed with a key from the following file:>
>> > https://dist.apache.org/repos/dist/dev/groovy/KEYS>
>> >
>> > Please vote on releasing this package as Apache Groovy 2.5.10.>
>> >
>> > Reminder on ASF release approval requirements for PMC members:>
>> > http://www.apache.org/legal/release-policy.html#release-approval>
>> > Hints on validating checksums/signatures (but replace md5sum with>
>> > sha256sum):>
>> > https://www.apache.org/info/verification.html>
>> >
>> > The vote is open for the next 72 hours and passes if a majority of at
>> least>
>> > three +1 PMC votes are cast.>
>> >
>> > [ ] +1 Release Apache Groovy 2.5.10>
>> > [ ]  0 I don't have a strong opinion about this, but I assume it's ok>
>> > [ ] -1 Do not release Apache Groovy 2.5.10 because...>
>> >
>> > Here is my vote:>
>> >
>> > +1 (binding)>
>> >
>> > On Tue, Mar 3, 2020 at 11:33 PM Paul King  wrote:>
>> >
>> > >>
>> > >>
>> >
>>
>

Re: RE: Groovy 3 very slow stub generation

[Paolo Di Tommaso]

What is the maximum number of lines of code that a source file should
contain to prevent perf degradation?



On Fri, Jan 31, 2020 at 8:16 PM Daniel.Sun  wrote:

> I find antlr4 parser parses *big* files much slower than antlr2 parser,
> unfortunately nextflow project contains quite a few big files...
>
> One of reasons is antlr2 uses LL(k) and antlr4 uses ALL. As we know, LL(k)
> will look ahead *limited* count of tokens, but ALL will look ahead
> *unlimited* count of tokens...
>
> I am trying to tweak rules to reduce looking ahead, but we have to admit
> that Groovy's grammar contains ambiguities, one of main reasons is
> parenthesis-less... As a user, I like it, but as a developer, I hate it...
>
> Cheers,
> Daniel.Sun
>
>
>
> -
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: Roadmap for Groovy 4

[Paolo Di Tommaso]

My vote goes for fixing the override for `equals` and `toString` methods
for collection classes

https://issues.apache.org/jira/browse/GROOVY-9003


Cheers,
Paolo



On Wed, Jan 22, 2020 at 3:16 AM Paul King  wrote:

>
> Hi folks,
>
> With Groovy 3 final release approaching we should think a bit more about
> our roadmap for Groovy 4. At the moment, there are a few Jiras and ad-hoc
> discussions that have taken place but it's a little hard to find it all.
> I've created a draft release notes here:
>
> http://groovy-lang.org/releasenotes/groovy-4.0.html
>
> Feel free to suggest changes. We can spawn off any additional Jiras and
> GEPs as needed.
>
> There will also be some knock on for tools and related libraries, e.g. we
> are still finessing Groovy 3.0 to work well with the next release of Spock
> and as one other example, Codenarc uses groovy.util.XmlSlurper but that
> changes to groovy.xml.XmlSlurper under Groovy 4, so will need to change
> (both XmlSlurper classes are in Groovy 3). So, there will no doubt be more
> we can do to make life easier for tool support or we can spawn off issues
> for those respective projects if needed as well.
>
> And finally, thanks for all your great contributions as we start this new
> year.
>
> Cheers, Paul.
>
>

Re: RE: Groovy 3 very slow stub generation

[Paolo Di Tommaso]

This sounds great!

On Sun, Jan 19, 2020 at 7:48 PM Daniel.Sun  wrote:

> Hi Paolo,
>
>  I'm thinking about how to solve the performance issue:
>
> 1) Improve the performance of Parrot parser even if the groovy code is
> parsed for the first time
> 2) Generate stubs in parallel
>
> Cheers,
> Daniel.Sun
>
>
>
> -
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: RE: Groovy 3 very slow stub generation

[Paolo Di Tommaso]

Hi,

Using "-Dgroovy.antlr4=false", it takes 38s, therefore, it is similar to
groovy 2.5.

When setting both "-Dgroovy.antlr4.cache.threshold=200" or
"-Dgroovy.antlr4.cache.threshold=600", it is slow: 1m 41s the first, and 1m
48s the second.


p

On Fri, Jan 17, 2020 at 10:11 PM Daniel.Sun  wrote:

> Here is the detailed result:
> results.zip 
>
>
> Under Windows, we can set the JVM option by:
> set JAVA_OPTS=-Xms2g -Xmx2G -Dgroovy.antlr4.cache.threshold=600
>
> then run `groovy Parse.groovy 2` or `groovy Parse.groovy 4`
>
> Cheers,
> Daniel.Sun
>
>
>
> -
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: Groovy 3 very slow stub generation

[Paolo Di Tommaso]

Hi Daniel,

Groovy 2.5.8: https://gradle.com/s/eqjp6767u5n2o
Groovy 3.0.0: https://gradle.com/s/orr64x7ilfwpu

Regarding the slow IntelliJ build, sure I'll report to them however I saw
clearly it stuck on the Groovy stub generation, and it works fine with the
prior version. Therefore it makes me think there's something wrong with the
groovy compilation.


Thanks,
Paolo


On Fri, Jan 17, 2020 at 7:59 AM Daniel.Sun  wrote:

> Hi Paolo,
>
> > The gradle build with groovy 2.5.8 compiles in 34 seconds
> > The gradle build with groovy 3.0.0-rc-3 takes 1m 46s
>  Could you share the build-scan reports?
>
> > The build with IntelliJ more than 5 minutes, which makes it unusable :(
>  As for the performance issue of intellij IDEA, I suggest you to open a
> ticket in Jetbrains's bug tracker[1]  ;-)
>
> Cheers,
> Daniel.Sun
> [1] https://youtrack.jetbrains.com/issues
>
>
>
> -
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: Groovy 3 very slow stub generation

[Paolo Di Tommaso]

Hi Daniel,

I've made the test you suggested:

   - The gradle build with groovy 2.5.8 compiles in 34 seconds
   - The gradle build with groovy 3.0.0-rc-3 takes 1m 46s
   - The build with IntelliJ more than 5 minutes, which makes it unusable :(


p

On Mon, Nov 18, 2019 at 4:04 PM Daniel.Sun  wrote:

> Hi Paolo,
>
>   Please do experiment through the following steps:
> 1)  In your command line(e.g. under Windows OS, type `cmd` to open it), run
> `gradlew compileGroovy --no-build-cache` to compile with 3.0.0-rc-1 and
> 2.5.x
> 2)  Compare the time cost by 3.0.0-rc-1 and 2.5.x
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: Groovy 3 very slow stub generation

[Paolo Di Tommaso]

Hi Daniel,

No, I'm not delegating the build to Gradle. The compilation is done via
IntelliJ. let me know if there's something that I can test.


Cheers,
Paolo


On Mon, Nov 18, 2019 at 2:11 PM Daniel.Sun  wrote:

> Hi Paolo,
>
>   If you build your project with `gradlew compileGroovy
> --no-build-cache`(assuming you are using gradle), it still takes much more
> time when using 3.0.0-rc-1 than 2.5.x?
>
>If yes, it is probably a groovy issue, otherwise it could be an
> intellij IDEA issue.
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Groovy 3 very slow stub generation

[Paolo Di Tommaso]

Dear all,

I was giving a trying compiling a medium size project
 with Groovy 3
rc1 with IntelliJ. Though the compilation is successful, the stub
generation process is insanely slow. It took more than 5 minutes to compile
the project while with groovy 2.5 the same project compiles in a few
seconds.


Did anybody notice the same problem? Is this expected?


Cheers,
Paolo

Re: Groovy 4 planning

[Paolo Di Tommaso]

It sounds a good plan!

My suggestion is to improve as much as possible the support for native
compilation, see for example this thread
. There's a lot of
excitement in the JVM world at this regard and losing the train can be
problematic to keep groovy on the edge.

Regarding lang enhancements, I would love in Groovy 4 to have raw strings
 and see solved the
problem with the override of equals method for collection
 objects.


Best,
Paolo

On Fri, May 24, 2019 at 4:27 PM Milles, Eric (TR Tech, Content & Ops) <
eric.mil...@thomsonreuters.com> wrote:

> My quick list for Groovy 4:
>
>- invoke dynamic by default
>- incorporate subprojects/parser-antlr4 into root project and drop
>antlr2 parser
>- pattern matching / switch expressions (if not already part of Groovy
>3)
>- improved instanceof flow typing:
>https://issues.apache.org/jira/browse/GROOVY-8687,
>https://issues.apache.org/jira/browse/GROOVY-8412,
>https://issues.apache.org/jira/browse/GROOVY-8411
>- some annotations copied from property to getters/setters:
>https://issues.apache.org/jira/browse/GROOVY-8897
>- unqualified enum constants in switch:
>https://issues.apache.org/jira/browse/GROOVY-8444
>- libraries are modules
>- modulepath support
>
>
>
> > What do people think about changing our maven coordinates with Groovy 4
> from org.codehaus.groovy to org.apache.groovy?
>
> Sounds good in theory.  Would you also repackage all "org.codehaus.*"
> sources?  Would you publish redirects in maven central so users could still
> get conflict management for other deps that pull in groovy?
>
> 
>   xmlns="http://maven.apache.org/POM/4.0.0;
>
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>
>   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>
>   http://maven.apache.org/xsd/maven-4.0.0.xsd;>
>
>
>   4.0.0
>
>
>   org.codehaus.groovy
>
>   groovy
>
>   4.0.0
>
>
>   
>
> 
>
>   org.apache.groovy
>
>   groovy
>
>   4.0.0
>
> 
>
>   
>
> 
>
>
> Eric M.
>
>

Re: Failing joint build

[Paolo Di Tommaso]

Ah! Basically, the identity operator has been fixed for classes
implementing the Comparable interface. This is definitely a good news!


p

On Mon, May 20, 2019 at 7:55 AM Paul King  wrote:

> Possibly this in 2.5.7?
> https://issues.apache.org/jira/browse/GROOVY-7954
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> <#m_-145782387168439430_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Mon, May 20, 2019 at 3:30 PM Paolo Di Tommaso <
> paolo.ditomm...@gmail.com> wrote:
>
>> Just to confirm the build fixed, though some tests failing due to changes
>> in the snapshot version.
>>
>> Is there any change related to identity and Comparable interface coming
>> in Groovy 2.5.8?
>>
>>
>> Cheers,
>> Paolo
>>
>>
>> On Sun, May 19, 2019 at 10:19 AM Paolo Di Tommaso <
>> paolo.ditomm...@gmail.com> wrote:
>>
>>> Damn! you are right. The deps overriding should have gone in
>>> `allprojects` block.
>>>
>>> Thanks for having spotted that and updated the building environment.
>>>
>>>
>>> Cheers,
>>> Paolo
>>>
>>>
>>> On Sun, May 19, 2019 at 2:42 AM Paul King  wrote:
>>>
>>>> It seems repeatable locally.
>>>>
>>>> On Sun, May 19, 2019 at 10:17 AM Paul King  wrote:
>>>>
>>>>> It looks like the gradle build needs some further work:
>>>>>
>>>>> [00:44:08] : [:nf-commons:compileGroovy] 00:44:08.057 [DEBUG]
>>>>> [org.gradle.api.internal.tasks.compile.NormalizingGroovyCompiler] Java
>>>>> compiler arguments: -source 1.8 -target 1.8 -d
>>>>> /var/teamcity/buildagent-jdk8/work/1d76058f36ec5c31/modules/nf-commons/build/classes/groovy/main
>>>>> -g -sourcepath  -proc:none -XDuseUnsharedTable=true -classpath ...[other
>>>>> jars]...:/var/teamcity/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy/2.5.6/6936e700f0fb1b50bac0698ada4347a769d40199/groovy-2.5.6.jar:...[other
>>>>> jars]...
>>>>> /var/teamcity/buildagent-jdk8/work/1d76058f36ec5c31/modules/nf-commons/src/main/nextflow/util/QuoteStringTokenizer.groovy
>>>>> /var/teamcity/buildagent-jdk8/work/1d76058f36ec5c31/modules/nf-commons/src/main/nextflow/util/CsvParser.groovy
>>>>> ...[other source files]...
>>>>>
>>>>> In some places I can see the Groovy version being overridden by the
>>>>> CI_GROOVY_VERSION value of 2.5.8-SNAPSHOT:
>>>>>
>>>>> [00:43:18] : [Step 1/1] 00:43:16.617 [QUIET] [system.out] >>
>>>>> Overriding org.codehaus.groovy:groovy:2.5.6 with version: 2.5.8-SNAPSHOT
>>>>>
>>>>> But in other places it seems not the case.
>>>>>
>>>>> Cheers, Paul.
>>>>>
>>>>>
>>>>> On Sat, May 11, 2019 at 6:52 PM Paolo Di Tommaso <
>>>>> paolo.ditomm...@gmail.com> wrote:
>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> I'm renewing my plea to fix the Nextflow joint build
>>>>>> <http://ci.groovy-lang.org/viewType.html?buildTypeId=JointBuilds_Nextflow_Groovy25xJointBuild>.
>>>>>> This would have helped to early detect and prevent bugs such as
>>>>>> GROOVY-9115 <https://issues.apache.org/jira/browse/GROOVY-9115>.
>>>>>>
>>>>>>
>>>>>> Thanks, Paolo
>>>>>>
>>>>>>
>>>>>> On Mon, Feb 4, 2019 at 3:36 PM Paolo Di Tommaso <
>>>>>> paolo.ditomm...@gmail.com> wrote:
>>>>>>
>>>>>>> I'm raising again this issue. No way to fix it?
>>>>>>>
>>>>>>>
>>>>>>> p
>>>>>>>
>>>>>>> On Fri, Jan 11, 2019 at 12:51 PM Paul King 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I get 2.5.6-SNAPSHOT as the version when I use locally built
>>>>>>>> snapshots. I presume it is something specific to the Nextflow build but
>>>>>>>> haven't had time to check yet.
>>>>>>>>
>>>>>>>> On Fri, Jan 11, 2019 at 6:25 PM Paolo Di Tommaso <
>>>>>>>> paolo.ditomm...@gmail.com&

Re: Failing joint build

[Paolo Di Tommaso]

Just to confirm the build fixed, though some tests failing due to changes
in the snapshot version.

Is there any change related to identity and Comparable interface coming in
Groovy 2.5.8?


Cheers,
Paolo


On Sun, May 19, 2019 at 10:19 AM Paolo Di Tommaso 
wrote:

> Damn! you are right. The deps overriding should have gone in `allprojects`
> block.
>
> Thanks for having spotted that and updated the building environment.
>
>
> Cheers,
> Paolo
>
>
> On Sun, May 19, 2019 at 2:42 AM Paul King  wrote:
>
>> It seems repeatable locally.
>>
>> On Sun, May 19, 2019 at 10:17 AM Paul King  wrote:
>>
>>> It looks like the gradle build needs some further work:
>>>
>>> [00:44:08] : [:nf-commons:compileGroovy] 00:44:08.057 [DEBUG]
>>> [org.gradle.api.internal.tasks.compile.NormalizingGroovyCompiler] Java
>>> compiler arguments: -source 1.8 -target 1.8 -d
>>> /var/teamcity/buildagent-jdk8/work/1d76058f36ec5c31/modules/nf-commons/build/classes/groovy/main
>>> -g -sourcepath  -proc:none -XDuseUnsharedTable=true -classpath ...[other
>>> jars]...:/var/teamcity/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy/2.5.6/6936e700f0fb1b50bac0698ada4347a769d40199/groovy-2.5.6.jar:...[other
>>> jars]...
>>> /var/teamcity/buildagent-jdk8/work/1d76058f36ec5c31/modules/nf-commons/src/main/nextflow/util/QuoteStringTokenizer.groovy
>>> /var/teamcity/buildagent-jdk8/work/1d76058f36ec5c31/modules/nf-commons/src/main/nextflow/util/CsvParser.groovy
>>> ...[other source files]...
>>>
>>> In some places I can see the Groovy version being overridden by the
>>> CI_GROOVY_VERSION value of 2.5.8-SNAPSHOT:
>>>
>>> [00:43:18] : [Step 1/1] 00:43:16.617 [QUIET] [system.out] >> Overriding
>>> org.codehaus.groovy:groovy:2.5.6 with version: 2.5.8-SNAPSHOT
>>>
>>> But in other places it seems not the case.
>>>
>>> Cheers, Paul.
>>>
>>>
>>> On Sat, May 11, 2019 at 6:52 PM Paolo Di Tommaso <
>>> paolo.ditomm...@gmail.com> wrote:
>>>
>>>> Hi guys,
>>>>
>>>> I'm renewing my plea to fix the Nextflow joint build
>>>> <http://ci.groovy-lang.org/viewType.html?buildTypeId=JointBuilds_Nextflow_Groovy25xJointBuild>.
>>>> This would have helped to early detect and prevent bugs such as
>>>> GROOVY-9115 <https://issues.apache.org/jira/browse/GROOVY-9115>.
>>>>
>>>>
>>>> Thanks, Paolo
>>>>
>>>>
>>>> On Mon, Feb 4, 2019 at 3:36 PM Paolo Di Tommaso <
>>>> paolo.ditomm...@gmail.com> wrote:
>>>>
>>>>> I'm raising again this issue. No way to fix it?
>>>>>
>>>>>
>>>>> p
>>>>>
>>>>> On Fri, Jan 11, 2019 at 12:51 PM Paul King  wrote:
>>>>>
>>>>>> I get 2.5.6-SNAPSHOT as the version when I use locally built
>>>>>> snapshots. I presume it is something specific to the Nextflow build but
>>>>>> haven't had time to check yet.
>>>>>>
>>>>>> On Fri, Jan 11, 2019 at 6:25 PM Paolo Di Tommaso <
>>>>>> paolo.ditomm...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi devs,
>>>>>>>
>>>>>>> Sorry if I insist on this, it may be that version string has not
>>>>>>> been updated on the 2.5.6 snapshot and therefore it's failing?
>>>>>>>
>>>>>>>
>>>>>>> p
>>>>>>>
>>>>>>> On Mon, Jan 7, 2019 at 8:16 PM Paolo Di Tommaso <
>>>>>>> paolo.ditomm...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Daer maintainers,
>>>>>>>>
>>>>>>>> The Nextflow joint build
>>>>>>>> <http://ci.groovy-lang.org/project.html?projectId=JointBuilds_Nextflow=projectOverview>
>>>>>>>> is failing with this error message.
>>>>>>>>
>>>>>>>> System.getenv('CI_GROOVY_VERSION') == GroovySystem.getVersion()
>>>>>>>>|   |   |
>>>>>>>>2.5.6-SNAPSHOT  |   2.5.5
>>>>>>>>false
>>>>>>>>10 differences (28% similarity)
>>>>>>>>2.5.(6-SNAPSHOT)
>>>>>>>>2.5.(5-)
>>>>>>>>
>>>>>>>>
>>>>>>>> It looks the Groovy runtime version is not matching the declared
>>>>>>>> version by the `CI_GROOVY_VERSION` env var.
>>>>>>>>
>>>>>>>> Could you please give it a look.
>>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Paolo
>>>>>>>>
>>>>>>>>

Re: Failing joint build

[Paolo Di Tommaso]

Damn! you are right. The deps overriding should have gone in `allprojects`
block.

Thanks for having spotted that and updated the building environment.


Cheers,
Paolo


On Sun, May 19, 2019 at 2:42 AM Paul King  wrote:

> It seems repeatable locally.
>
> On Sun, May 19, 2019 at 10:17 AM Paul King  wrote:
>
>> It looks like the gradle build needs some further work:
>>
>> [00:44:08] : [:nf-commons:compileGroovy] 00:44:08.057 [DEBUG]
>> [org.gradle.api.internal.tasks.compile.NormalizingGroovyCompiler] Java
>> compiler arguments: -source 1.8 -target 1.8 -d
>> /var/teamcity/buildagent-jdk8/work/1d76058f36ec5c31/modules/nf-commons/build/classes/groovy/main
>> -g -sourcepath  -proc:none -XDuseUnsharedTable=true -classpath ...[other
>> jars]...:/var/teamcity/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy/2.5.6/6936e700f0fb1b50bac0698ada4347a769d40199/groovy-2.5.6.jar:...[other
>> jars]...
>> /var/teamcity/buildagent-jdk8/work/1d76058f36ec5c31/modules/nf-commons/src/main/nextflow/util/QuoteStringTokenizer.groovy
>> /var/teamcity/buildagent-jdk8/work/1d76058f36ec5c31/modules/nf-commons/src/main/nextflow/util/CsvParser.groovy
>> ...[other source files]...
>>
>> In some places I can see the Groovy version being overridden by the
>> CI_GROOVY_VERSION value of 2.5.8-SNAPSHOT:
>>
>> [00:43:18] : [Step 1/1] 00:43:16.617 [QUIET] [system.out] >> Overriding
>> org.codehaus.groovy:groovy:2.5.6 with version: 2.5.8-SNAPSHOT
>>
>> But in other places it seems not the case.
>>
>> Cheers, Paul.
>>
>>
>> On Sat, May 11, 2019 at 6:52 PM Paolo Di Tommaso <
>> paolo.ditomm...@gmail.com> wrote:
>>
>>> Hi guys,
>>>
>>> I'm renewing my plea to fix the Nextflow joint build
>>> <http://ci.groovy-lang.org/viewType.html?buildTypeId=JointBuilds_Nextflow_Groovy25xJointBuild>.
>>> This would have helped to early detect and prevent bugs such as
>>> GROOVY-9115 <https://issues.apache.org/jira/browse/GROOVY-9115>.
>>>
>>>
>>> Thanks, Paolo
>>>
>>>
>>> On Mon, Feb 4, 2019 at 3:36 PM Paolo Di Tommaso <
>>> paolo.ditomm...@gmail.com> wrote:
>>>
>>>> I'm raising again this issue. No way to fix it?
>>>>
>>>>
>>>> p
>>>>
>>>> On Fri, Jan 11, 2019 at 12:51 PM Paul King  wrote:
>>>>
>>>>> I get 2.5.6-SNAPSHOT as the version when I use locally built
>>>>> snapshots. I presume it is something specific to the Nextflow build but
>>>>> haven't had time to check yet.
>>>>>
>>>>> On Fri, Jan 11, 2019 at 6:25 PM Paolo Di Tommaso <
>>>>> paolo.ditomm...@gmail.com> wrote:
>>>>>
>>>>>> Hi devs,
>>>>>>
>>>>>> Sorry if I insist on this, it may be that version string has not been
>>>>>> updated on the 2.5.6 snapshot and therefore it's failing?
>>>>>>
>>>>>>
>>>>>> p
>>>>>>
>>>>>> On Mon, Jan 7, 2019 at 8:16 PM Paolo Di Tommaso <
>>>>>> paolo.ditomm...@gmail.com> wrote:
>>>>>>
>>>>>>> Daer maintainers,
>>>>>>>
>>>>>>> The Nextflow joint build
>>>>>>> <http://ci.groovy-lang.org/project.html?projectId=JointBuilds_Nextflow=projectOverview>
>>>>>>> is failing with this error message.
>>>>>>>
>>>>>>> System.getenv('CI_GROOVY_VERSION') == GroovySystem.getVersion()
>>>>>>>|   |   |
>>>>>>>2.5.6-SNAPSHOT  |   2.5.5
>>>>>>>false
>>>>>>>10 differences (28% similarity)
>>>>>>>2.5.(6-SNAPSHOT)
>>>>>>>2.5.(5-)
>>>>>>>
>>>>>>>
>>>>>>> It looks the Groovy runtime version is not matching the declared
>>>>>>> version by the `CI_GROOVY_VERSION` env var.
>>>>>>>
>>>>>>> Could you please give it a look.
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Paolo
>>>>>>>
>>>>>>>

Re: Failing joint build

[Paolo Di Tommaso]

Hi guys,

I'm renewing my plea to fix the Nextflow joint build
<http://ci.groovy-lang.org/viewType.html?buildTypeId=JointBuilds_Nextflow_Groovy25xJointBuild>.
This would have helped to early detect and prevent bugs such as GROOVY-9115
<https://issues.apache.org/jira/browse/GROOVY-9115>.


Thanks, Paolo


On Mon, Feb 4, 2019 at 3:36 PM Paolo Di Tommaso 
wrote:

> I'm raising again this issue. No way to fix it?
>
>
> p
>
> On Fri, Jan 11, 2019 at 12:51 PM Paul King  wrote:
>
>> I get 2.5.6-SNAPSHOT as the version when I use locally built snapshots. I
>> presume it is something specific to the Nextflow build but haven't had time
>> to check yet.
>>
>> On Fri, Jan 11, 2019 at 6:25 PM Paolo Di Tommaso <
>> paolo.ditomm...@gmail.com> wrote:
>>
>>> Hi devs,
>>>
>>> Sorry if I insist on this, it may be that version string has not been
>>> updated on the 2.5.6 snapshot and therefore it's failing?
>>>
>>>
>>> p
>>>
>>> On Mon, Jan 7, 2019 at 8:16 PM Paolo Di Tommaso <
>>> paolo.ditomm...@gmail.com> wrote:
>>>
>>>> Daer maintainers,
>>>>
>>>> The Nextflow joint build
>>>> <http://ci.groovy-lang.org/project.html?projectId=JointBuilds_Nextflow=projectOverview>
>>>> is failing with this error message.
>>>>
>>>> System.getenv('CI_GROOVY_VERSION') == GroovySystem.getVersion()
>>>>|   |   |
>>>>2.5.6-SNAPSHOT  |   2.5.5
>>>>false
>>>>10 differences (28% similarity)
>>>>2.5.(6-SNAPSHOT)
>>>>2.5.(5-)
>>>>
>>>>
>>>> It looks the Groovy runtime version is not matching the declared
>>>> version by the `CI_GROOVY_VERSION` env var.
>>>>
>>>> Could you please give it a look.
>>>>
>>>>
>>>> Cheers,
>>>> Paolo
>>>>
>>>>

Re: 2.5.7 regression with references?

[Paolo Di Tommaso]

Just got a weird compilation error always using Path arguments.

https://issues.apache.org/jira/browse/GROOVY-9115


p

On Fri, May 10, 2019 at 6:38 PM Romain Manni-Bucau 
wrote:

> Sure, the class is there:
> https://github.com/Talend/component-runtime/blob/component-runtime-1.1.9/sample-parent/documentation-sample/_src/build/Bundles.groovy#L71
>  and
> the reference issue is at the line before.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le ven. 10 mai 2019 à 18:35, Milles, Eric (TR Tech, Content & Ops) <
> eric.mil...@thomsonreuters.com> a écrit :
>
>> There were some anon. inner fixes in 2.5.7.  Can you show a small example
>> of the AIC you are seeing an error for?
>>
>>
>> --
>> *From:* Romain Manni-Bucau 
>> *Sent:* Friday, May 10, 2019 11:11 AM
>> *To:* dev@groovy.apache.org
>> *Subject:* 2.5.7 regression with references?
>>
>> Hi guys,
>>
>> using anonymous classes with 2.5.7 does not handle references properly
>> compared to 2.5.6:
>>
>> error I get:
>>
>> static java.nio.file.Files.copy() is applicable for argument types:
>> (sun.nio.fs.UnixPath, Reference)
>>
>> Code implements a new SimpleFileVisitor() {...} inline and uses a
>> reference defined before the class (~final in java).
>>
>> Is it known?
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> 
>> |  Blog
>> 
>>  |
>> Old Blog
>> 
>> | Github
>> 
>>  |
>> LinkedIn
>> 
>>  |
>> Book
>>
>> 
>>
>

Re: Welcome Daniel Sun to Apache Groovy PMC

[Paolo Di Tommaso]

Well done and congrats!


p

On Mon, May 6, 2019 at 4:39 PM Søren Berg Glasius  wrote:

> Congratulations Daniel. You help make Groovy shine!
>
> Best regards / Med venlig hilsen,
> Søren Berg Glasius
>
> Hedevej 1, Gl. Rye, 8680 Ry, Denmark
> Mobile: +45 40 44 91 88, Skype: sbglasius
> --- Press ESC once to quit - twice to save the changes.
>
>
> On Mon, 6 May 2019 at 13:15, Paul King  wrote:
>
>>
>> The Apache Groovy PMC has invited Daniel Sun to join the PMC and he has
>> accepted. You all probably know Daniel for his wonderful efforts on the
>> Parrot parser but he has been contributing in many other areas as well
>> recently. We look forward to many future contributions too! Welcome Daniel!
>>
>> Cheers, Paul.
>>
>>

Re: Which issue do you MOST want to fix

[Paolo Di Tommaso]

Dear community,

Regarding important issues to fix in Groovy 3.0, I would raise your
attention to the problem that currently Groovy does not allow the
overriding of the toString and equals methods for custom collection object
i.e. Set, List, Map.

I've raised several times this problem in the past and though the community
agreed that this is an important limitation, there was not consensus on the
solution. Groovy 3.0 could be a good opportunity to have this problem
solved. I've opened an issue including a possible solution.

https://issues.apache.org/jira/browse/GROOVY-9003

Hope you will take in consideration for the next Groovy major release.

Cheers,
Paolo


On Mon, Feb 18, 2019 at 6:32 AM Basil Peace  wrote:

> Hi, Daniel!
>
> Nice to hear that!
> Thanks.
>
> --
> Best regards,
> Basil Peace
>
>
> 17.02.2019, 07:08, "Daniel.Sun" :
> > Hi Basil,
> >
> >   We plan to re-write Groovydoc from scratch to gain better
> maintenance
> > and fix all the existing issues. It is targeted to Groovy 3.0.0.
> >
> > Cheers,
> > Daniel.Sun
> >
> > -
> > Apache Groovy committer
> > Blog: http://blog.sunlan.me
> > Twitter: @daniel_sun
> >
> > --
> > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>

Re: About polish the generics type syntax for closure

[Paolo Di Tommaso]

Nice!

On Wed, Feb 13, 2019 at 2:50 AM Daniel Sun  wrote:

> Hi all
>
>I've been developing a project with Groovy 3. When I try to specify
> the generics type for closure, I have to use annotation..., which is quite
> verbose... e.g.
> ```
> public  V withSql(@ClosureParams(value= SimpleType.class,
> options="groovy.sql.Sql") Closure closure)
> ```
>
>I propose make the above code groovier, e.g.
> ```
> public  V withSql(Closure V> closure)
> ```
>
>Any thoughts?
>
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: Failing joint build

[Paolo Di Tommaso]

I'm raising again this issue. No way to fix it?


p

On Fri, Jan 11, 2019 at 12:51 PM Paul King  wrote:

> I get 2.5.6-SNAPSHOT as the version when I use locally built snapshots. I
> presume it is something specific to the Nextflow build but haven't had time
> to check yet.
>
> On Fri, Jan 11, 2019 at 6:25 PM Paolo Di Tommaso <
> paolo.ditomm...@gmail.com> wrote:
>
>> Hi devs,
>>
>> Sorry if I insist on this, it may be that version string has not been
>> updated on the 2.5.6 snapshot and therefore it's failing?
>>
>>
>> p
>>
>> On Mon, Jan 7, 2019 at 8:16 PM Paolo Di Tommaso <
>> paolo.ditomm...@gmail.com> wrote:
>>
>>> Daer maintainers,
>>>
>>> The Nextflow joint build
>>> <http://ci.groovy-lang.org/project.html?projectId=JointBuilds_Nextflow=projectOverview>
>>> is failing with this error message.
>>>
>>> System.getenv('CI_GROOVY_VERSION') == GroovySystem.getVersion()
>>>|   |   |
>>>2.5.6-SNAPSHOT  |   2.5.5
>>>false
>>>10 differences (28% similarity)
>>>2.5.(6-SNAPSHOT)
>>>2.5.(5-)
>>>
>>>
>>> It looks the Groovy runtime version is not matching the declared version
>>> by the `CI_GROOVY_VERSION` env var.
>>>
>>> Could you please give it a look.
>>>
>>>
>>> Cheers,
>>> Paolo
>>>
>>>

Re: Status of GPars

[Paolo Di Tommaso]

Indeed. Gpars is an amazing and super reliable piece of software.

I would be happy to contribute to keep it building and running.


Cheers,
Paolo


On Mon, Feb 4, 2019 at 3:16 PM Paul King  wrote:

> Thanks for all your efforts Russel, GPars wouldn't have become the very
> useful library it is today without your efforts.
>
> You are right though that things have changed. I'll try to find time to
> see what still builds with a view to doing a new release (with perhaps much
> functionality pruned).
>
> Cheers, Paul.
>
>
> On Sun, Feb 3, 2019 at 4:55 AM Russel Winder  wrote:
>
>> Hi,
>>
>> I have come to the decision to stop working on GPars. I have done very
>> little
>> over the last year anyway, there has been no interest at all from the
>> Groovy
>> community, and I am not doing much with Groovy or even the JVM these days
>> –
>> except perhaps some Kotlin for writing the DLanguage CLion plugin.
>>
>> Clearly the GPars organisation is there on GitHub, with multiple owners,
>> as is
>> the source code. So there is no threat to the code, other than it is
>> moribund
>> and other solutions are overtaking it. In particular Quasar, Kotlin
>> Coroutines, and Project Loom, are likely the future for much of the stuff
>> in
>> GPars. GPars still has features not available elsewhere on the JVM, but
>> it has
>> lost all momentum as a project.
>>
>> --
>> Russel.
>> ===
>> Dr Russel Winder  t: +44 20 7585 2200
>> 41 Buckmaster Roadm: +44 7770 465 077
>> London SW11 1EN, UK   w: www.russel.org.uk
>>
>>

Re: [PROPOSAL]Provide an option to generate stubs in in-momery file system for better compiling performance

[Paolo Di Tommaso]

Could IDEs like Intellij benefit from this?


p

On Fri, Jan 18, 2019 at 7:53 PM Daniel.Sun  wrote:

> Fix the PR link:  https://github.com/apache/groovy/pull/855
>
>
>
> -
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: [PROPOSAL]Provide an option to generate stubs in in-momery file system for better compiling performance

[Paolo Di Tommaso]

This would be indeed very useful. The current join compilation tend to be
time consuming.

p

On Fri, Jan 18, 2019 at 9:44 AM Daniel Sun  wrote:

> Hi all,
>
> [Background]
>Groovy's joint compiler will generate a lot of stubs for groovy
> source files, many of the stubs are useless and written to disk and clean
> later. When project contains a lot of groovy source files, the performance
> of compiling is not good.
>
> [Proposal]
>   I propose to add an option(e.g. `groovy.generate.stubs.in.memory`)
> to
> generate stubs in in-momery file system[1]. We can get the generated stub
> files from the the in-memory file system with `StandardJavaFileManager`[2]
> .
> Here is the `JavaCompiler` usage[3].
>
> [Benefits]
>  We can avoid writing lots of stub files to disk and subsequent
> cleaning, in addition, reading stub files from memory will be much faster
> than reading from disk.
>
>
>   Any thoughts?
>
> Cheers,
> Daniel.Sun
> [1] https://github.com/google/jimfs
> [2]
>
> https://docs.oracle.com/javase/7/docs/api/javax/tools/StandardJavaFileManager.html
> [3]
>
> https://github.com/danielsun1106/SmartASMifier/blob/master/SmartASMifier.groovy#L81-L88
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: Failing joint build

[Paolo Di Tommaso]

Hi devs,

Sorry if I insist on this, it may be that version string has not been
updated on the 2.5.6 snapshot and therefore it's failing?


p

On Mon, Jan 7, 2019 at 8:16 PM Paolo Di Tommaso 
wrote:

> Daer maintainers,
>
> The Nextflow joint build
> <http://ci.groovy-lang.org/project.html?projectId=JointBuilds_Nextflow=projectOverview>
> is failing with this error message.
>
> System.getenv('CI_GROOVY_VERSION') == GroovySystem.getVersion()
>|   |   |
>2.5.6-SNAPSHOT  |   2.5.5
>false
>10 differences (28% similarity)
>2.5.(6-SNAPSHOT)
>2.5.(5-)
>
>
> It looks the Groovy runtime version is not matching the declared version
> by the `CI_GROOVY_VERSION` env var.
>
> Could you please give it a look.
>
>
> Cheers,
> Paolo
>
>

Failing joint build

[Paolo Di Tommaso]

Daer maintainers,

The Nextflow joint build

is failing with this error message.

System.getenv('CI_GROOVY_VERSION') == GroovySystem.getVersion()
   |   |   |
   2.5.6-SNAPSHOT  |   2.5.5
   false
   10 differences (28% similarity)
   2.5.(6-SNAPSHOT)
   2.5.(5-)


It looks the Groovy runtime version is not matching the declared version by
the `CI_GROOVY_VERSION` env var.

Could you please give it a look.


Cheers,
Paolo

Re: DGM for first or default

[Paolo Di Tommaso]

ouch.. true! if so:

list ? list.first() : defaultValue


p








On Thu, Oct 18, 2018 at 7:07 PM ocs@ocs  wrote:

> Myself, I am not a huge fan of adding not-often-needed functionalities
> (and actually would add almost none of those discussed lately);
> nevertheless...
>
> On 18 Oct 2018, at 6:48 PM, Paolo Di Tommaso 
> wrote:
>
> -1, it can be easily done as:
> list.first() ?: defaultValue
>
>
> ... this won't work in case the first object is a Groovy False (e.g., an
> empty string, or a plethora of others).
>
> All the best,
> OC
>
>
>
> p
>
> On Thu, Oct 18, 2018 at 6:45 PM Daniel.Sun  wrote:
>
>> +0 from me.
>> P.S. we should add similar DGM for `last` too?
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>>
>> -
>> Daniel Sun
>> Apache Groovy committer
>> Blog: http://blog.sunlan.me
>> Twitter: @daniel_sun
>>
>> --
>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>
>
>

Re: DGM for first or default

[Paolo Di Tommaso]

-1, it can be easily done as:

list.first() ?: defaultValue


p

On Thu, Oct 18, 2018 at 6:45 PM Daniel.Sun  wrote:

> +0 from me.
> P.S. we should add similar DGM for `last` too?
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: upcoming Groovy 2.5.3 release

[Paolo Di Tommaso]

Is there an ETA for Groovy 2.5.3 ?


p

On Sat, Sep 15, 2018 at 3:30 AM Daniel.Sun  wrote:

> Building yaml is supported too now.
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Groovy 3.0 breaking changes

[Paolo Di Tommaso]

Dear all,

Currently Groovy breaks the polymorphism contract for the `equals` and
`toString` methods for objects implementing List, Set, Map interfaces. For
example:

class Mylist extends ArrayList {
  Mylist(Collection c) { super(c) }
  @Override boolean equals(Object o) { throw new
UnsupportedOperationException () }
  @Override int hashCode() { throw new UnsupportedOperationException () }
  @Override String toString() { return 'CUSTOM STRING' }
}

def l = new Mylist([1,2,3])
assert l.toString() == 'CUSTOM STRING'
assert "$l" == '[1, 2, 3]'

def q = new Mylist([1,2,3])
assert l.equals(q)
assert l == q


In the above snippet the `toString` is *not* invoked when interpolated in a
GString, also  the `equals` method not invoked, not even when it's
explicitly referenced.

A similar problem for the `equals` method exists when a class implements
the `Comparable` interface. For example:

class Foo implements Comparable {
  private int x
  Foo(int x) { this.x=x }
  @Override int compareTo(Foo o) { throw new
IllegalArgumentException('SHOULD INVOKE EQUALS!') }
  @Override  boolean equals(Object o) { return this.x == o.x }
}

assert new Foo(1).equals(new Foo(1))  // OK
assert new Foo(1) == new Foo(1)   // throws IllegalArgumentException:
SHOULD INVOKE EQUALS!


In this case the `==` operator uses `compareTo` instead of the `equals`
method.


I know there are historical reasons behind each of them, however they
represent really nasty inconstancies and cause of a lot of problems. I hope
that Groovy 3.0 is planning to solve these problems or at least give a
mechanism to implement a proper behaviour.


Cheers,
Paolo

Groovy 2.5.3-SNAPSHOT join build error

[Paolo Di Tommaso]

The Nextflow joint build is failing with the latest snapshot version.

http://ci.groovy-lang.org/viewLog.html?buildId=52435

Since I'm not replicate these errors I'm wondering if there's been any
critical change in the latest 2.5.3-SNAPSHOT version.


Cheers,
Paolo

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Paolo Di Tommaso]

I fear this thread is going off topic, however the groovy support for raw
strings was already discussed in another thread some weeks ago.

http://groovy.329449.n5.nabble.com/About-raw-string-and-enhanced-try-with-resource-td5750413.html


Cheers, p


p

On Tue, Sep 11, 2018 at 1:16 PM Jochen Theodorou  wrote:

>
>
> Am 11.09.2018 um 12:16 schrieb Paolo Di Tommaso:
> > I mean that Java.next’s syntax for raw strings does not support variable
> > interpolation. My understanding is that groovy won't either.
>
> we have actually 4 multiline string variants, of which 1 is not
> supporting variable interpolation
> http://groovy-lang.org/syntax.html#_string_summary_table
>
> What the Java version does and we not, is having no interpolation for
> escapes. We have the dollar-slashy-string to have a different escape
> symbol, but without escapes (raw strings) is nothing we have.
>
> And actually I don't think we need raw string literals in Groovy at
> all... but that might be because I do not see good use for them beyond
> regular expressions, and for those we have a solution in Groovy already.
>
> bye Jochen
>

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Paolo Di Tommaso]

I mean that Java.next’s syntax for raw strings does not support variable
interpolation. My understanding is that groovy won't either.


p



On Tue, Sep 11, 2018 at 12:08 PM Andres Almiray  wrote:

> You mean Java.next’s syntax for raw strings as Groovy already has two
> versions.
>
> Sent from my primitive Tricorder
>
> On 11 Sep 2018, at 11:57, Paolo Di Tommaso 
> wrote:
>
> Raw strings would be a great addition to groovy, but as the name implies
> there shouldn't be any string interpolation with them.
>
>
> p
>
> <http://twitter.com/glaforge>
>>
>

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Paolo Di Tommaso]

Raw strings would be a great addition to groovy, but as the name implies
there shouldn't be any string interpolation with them.


p

On Tue, Sep 11, 2018 at 11:49 AM Guillaume Laforge 
wrote:

> Yeah, I know.
> It was more of a joke than a serious suggestion.
> And indeed, it would make things even more confusing.
>
> On Tue, Sep 11, 2018 at 11:46 AM Andres Almiray 
> wrote:
>
>> Backquoted strings may become multiline strings in Java.next, akin to our
>> triple single-quote strings.
>> Using ` at this time before Java.next releases multiline support would be
>> a problem for sure.
>>
>> Cheers,
>> Andres
>>
>> ---
>> Java Champion; Groovy Enthusiast
>> JCP EC Associate Seat
>> http://andresalmiray.com
>> http://www.linkedin.com/in/aalmiray
>> --
>> What goes up, must come down. Ask any system administrator.
>> There are 10 types of people in the world: Those who understand binary,
>> and those who don't.
>> To understand recursion, we must first understand recursion.
>>
>> On Tue, Sep 11, 2018 at 11:31 AM, Guillaume Laforge 
>> wrote:
>>
>>> Javascript's  `backquoted ${str}` are immutable.
>>> So changing the embedded variable str won't change the value of the
>>> templated string.
>>> As if we didn't have enough variants of strings ;-) perhaps we should
>>> support that one too :-)
>>>
>>> On Tue, Sep 11, 2018 at 11:20 AM Jochen Theodorou 
>>> wrote:
>>>


 Am 11.09.2018 um 01:59 schrieb MG:
 > Hi Jochen,
 >
 > could you be more precise about where you see the problem(s) in your
 > example:
 >
 > 1) That Wrapper is not an immutable class, and you can therefore
 change
 > its state after creation ?
 > 2) That GString $-expressions (outside of "${-> ...}") do not capture
 > the expression, but the result of evaluating the expression (which
 > oftentimes will be an Object referece) ?
 > 3) That GString is not immediately evaluated to its String
 representation ?
 > 4) ... ?

 The problem is user expectations. Many do not expect GString to be
 mutable, since they do not use it as a templating solution or something
 compareable. I think we should offer something here. That does not have
 to be GString in syntax at all.

 Or we align more with Javascript tempalating and make GString immutable.

 bye Jochen

>>>
>>>
>>> --
>>> Guillaume Laforge
>>> Apache Groovy committer & PMC Vice-President
>>> Developer Advocate @ Google Cloud Platform
>>>
>>> Blog: http://glaforge.appspot.com/
>>> Twitter: @glaforge 
>>>
>>
>>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Twitter: @glaforge 
>

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Paolo Di Tommaso]

I would like to raise a flag here.

Stated the Groovy documentation a Gstring can be resolved both in a eager
and lazy manner:

def number = 1 def eagerGString = "value == ${number}"def lazyGString
= "value == ${ -> number }"
assert eagerGString == "value == 1" assert lazyGString ==  "value == 1"

number = 2 assert eagerGString ==  "value == 1"assert lazyGString ==
"value == 2"



http://groovy-lang.org/syntax.html#_special_case_of_interpolating_closure_expressions

The example you are reporting should *already* be reasolved eagerly and I
can agree that it can be confusing.

However the ability to resolve a GString lazily it's a very important
Groovy feature for DSL builders. Wipe it out would have a serious impact
(read destroy) on existing frameworks that rely on that feature.


Cheers,
Paolo

Re: Nextflow joint build

[Paolo Di Tommaso]

Green! thanks.

p

On Sun, Aug 26, 2018 at 10:27 AM Paul King  wrote:

> Should be fixed.
>
> On Sun, Aug 26, 2018 at 5:39 PM Paolo Di Tommaso <
> paolo.ditomm...@gmail.com> wrote:
>
>> Dear maintainers,
>>
>> Since Nextflow has migrated to Groovy 2.5.x, could you please remove the
>> 2.4.x CI build?
>>
>>
>> http://ci.groovy-lang.org/viewType.html?buildTypeId=JointBuilds_Nextflow_Groovy24xJointBuild
>>
>>
>> Also it seems the CI build for version 2.5.x is stuck to some old
>> snapshot and reports an issue already solved.
>>
>>
>> http://ci.groovy-lang.org/viewType.html?buildTypeId=JointBuilds_Nextflow_Groovy25xJointBuild
>>
>> Could you please update it so that the variable `CI_GROOVY_VERSION`
>> points to the latest 2.5.x SNAPSHOT ?
>>
>>
>> Thanks,
>> Paolo
>>
>>

Nextflow joint build

[Paolo Di Tommaso]

Dear maintainers,

Since Nextflow has migrated to Groovy 2.5.x, could you please remove the
2.4.x CI build?

http://ci.groovy-lang.org/viewType.html?buildTypeId=JointBuilds_Nextflow_Groovy24xJointBuild


Also it seems the CI build for version 2.5.x is stuck to some old snapshot
and reports an issue already solved.

http://ci.groovy-lang.org/viewType.html?buildTypeId=JointBuilds_Nextflow_Groovy25xJointBuild

Could you please update it so that the variable `CI_GROOVY_VERSION` points
to the latest 2.5.x SNAPSHOT ?


Thanks,
Paolo

Re: Groovy 2.5.0 static compilation problems

[Paolo Di Tommaso]

Hi all,

I've created an issue for the compile static error reported.

https://issues.apache.org/jira/browse/GROOVY-8640


Cheers,
p


On Thu, Jun 7, 2018 at 10:33 AM, Daniel.Sun  wrote:

> It is fix in 2.5.1 and should be available in SNAPSHOT too.
> As you can see, the test in the relevant fix passes, so I suggest you clone
> and build from source code by yourself.
>
> Cheers,
> Daniel.Sun
>
>
>
> -
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Groovy 2.5.0 static compilation problems

[Paolo Di Tommaso]

Dear all,

I'm still getting some weird static problems with groovy 2.5.0 and
2.5.0-SNAPSHOT


* First one:

No such property: instanceId for class: java.util.List  @ line 889,
column 16.
   return response.reservation.getInstances() *. instanceId


This looks caused by GROOVY-8595 which is marked resolved but I'm still
getting it. Is it included in the 2.5.0-SNAPSHOT  ?



* Second one:

[Static type checking] - Cannot set read-only property: dynamic @ line 123,
column 53.
{ if (it instanceof Closure) dynamic |=
 ^
is given by a piece of code as show below:

@CompileStatic
class Foo {

boolean dynamic

}

@CompileStatic
class Bar extends Foo  {

boolean isDynamic() { dynamic }

def f() {
def value = []
value.each { if (it instanceof Closure) dynamic |= true }
}
}


* Third one:

[Static type checking] - Cannot find matching method
java.lang.Integer#compareTo(java.lang.Object). Please check if the declared
type is correct and if the method exists. @ line 304, column 59.
   line=reader.readLine()) && c++https://github.com/nextflow-io/nextflow/blob/e6079575c74a320d61d1e794a24db77baa2890c9/src/main/groovy/nextflow/cli/CmdLog.groovy#L304>
and you can replicate the issue with these commands:

git clone g...@github.com:nextflow-io/nextflow.git && cd nextflow
CI_GROOVY_VERSION=2.5.0-SNAPSHOT make compile




Cheers,
Paolo

Re: [DISCUSS] Renumber Groovy 2.6 to 2.9

[Paolo Di Tommaso]

> But seriously, a project release in 2018 that supports Java 7 is
extraordinary. The future is JDK 11, not 7 :)

I definitely agree, what's the rationale of supporting Java 7? The new Java
release train is putting a lot of pressure on the fast adoption of latest
Java versions. IMO it would be much better to focus on Java 9
compatibility.


p

On Tue, May 22, 2018 at 9:41 AM, Cédric Champeau 
wrote:

> 2.99 or alike doesn't make sense. What if you have to release a bug fix
> release. 2.99.1? That's nasty :)
>
> I'm very much in favor of dropping 2.6 altogether because it's confusing
> as possible. We don't have 2.5 yet, and we already have alphas for 3.0.
> This mean we would live with 3 "live" branches for a while (2.5.x, 2.6.x
> and 3.x), which is too much overhead for my brain, and probably too much
> hassle for the maintainers of Groovy. I reckon that people wanted to have
> the ability to try the new parser on JDK 7. But seriously, a project
> release in 2018 that supports Java 7 is extraordinary. The future is JDK
> 11, not 7 :)
>
> Le mar. 22 mai 2018 à 09:33, mg  a écrit :
>
>> Good point.
>>
>> This is one reason why - under the given constraints - Russel's 2.99.x or
>> my 2.97.x would be better choices than 2.9.x
>> (once you get beyond "this is not how things are done").
>>
>> Also consider what happens if, for some reason, the current 2.5.x branch
>> was to continue beyond 2.5.x (without switching to 2.6.x === 3.0-- , i.e.
>> without breaking changes).
>> Then you would have to skip 2.6.x , and go directly to 2.7.x, which would
>> be much more confusing...
>>
>> The key sentence here is "under the given constraints". In a perfect,
>> clean-room-world we would not be having this discussion...
>>
>>
>>  Ursprüngliche Nachricht 
>> Von: Thibault Kruse 
>> Datum: 22.05.18 06:31 (GMT+01:00)
>> An: dev@groovy.apache.org, pa...@asert.com.au
>> Betreff: Re: [DISCUSS] Renumber Groovy 2.6 to 2.9
>>
>> If you go with 2.9 now, and for unforseeable reasons the 2.x branch
>> continues, you will have 2.6, 2.7, 2.8 and then the prematurely added
>> 2.9.
>> What would you think about any other project versioning like that?
>> Even with a given explanation, it looks weird and chaotic.
>>
>> On Tue, May 22, 2018 at 11:12 AM, Paul King  wrote:
>> > 2.6/3.0-- has only undergone alpha releases. The fact that 2.7/2.8 are
>> > missing and that people stop to think is a good thing.
>> > We are planning breaking changes for 3 (and hence 2.6/3.0--). With
>> semantic
>> > versioning, 2.6/3.0-- should not have such changes.
>> > So it really should be versions 3 and 4 but since we are going to drop
>> > support for 2.6/3.0-- straight away, it hardly seems worthy
>> > of a dedicated whole version. I think 2.9 is a good compromise version
>> > number.
>> >
>> > Dropping it altogether is another option but if you remember it was
>> > non-committer contributors that wanted this change and did
>> > most of the (original at least) contributions. We've done all the work,
>> I
>> > say let's just release as 2.9 and then drop it. If outside
>> > contributors want to continue bug fixes on it, so be it.
>> >
>> > Cheers, Paul.
>> >
>> > On Tue, May 22, 2018 at 1:12 AM, John Wagenleitner
>> >  wrote:
>> >>
>> >> My opinion is that it should be left as 2.6. Since 2.6 has already
>> >> undergone several pre-releases I think it will may be more confusing to
>> >> re-number now. Renumbering may also give the impression that a 2.7 or
>> 2.8
>> >> might be coming or at least make some wonder what happened to those
>> >> versions.
>> >>
>> >> On Sat, May 19, 2018 at 8:58 PM Paul King  wrote:
>> >>>
>> >>>
>> >>> Hi,
>> >>>
>> >>> I was wondering what people thought about renumbering Groovy 2.6 to
>> 2.9.
>> >>> It is only a subtle change but I think better conveys that it isn't a
>> >>> small step up
>> >>> from 2.5 but rather something just a bit short of 3.
>> >>>
>> >>> Thoughts?
>> >>>
>> >>> Cheers, Paul.
>> >>>
>> >
>>
>

Re: About raw string and enhanced try-with-resource

[Paolo Di Tommaso]

No. There's an important difference: raw strings do not escape any special
character ie. backlashes, dollars, back-ticks, etc.

This is very useful for DSLs when it's required to embed a piece of foreign
code (think for example Bash) into a string. With groovy multi-line string
you still need to escape a lot stuff, making very difficult for the user to
handle it.


p



On Tue, May 15, 2018 at 12:21 PM, Jesper Steen Møller 
wrote:

>
> > On 15 May 2018, at 12.14, Daniel.Sun  wrote:
> > [..]
> >As you said, Groovy has many string(e.g. 'xxx', "xxx", '''xxx''',
> > """xxx""", /xxx/, $/xxx/$). but they can not cover the function of raw
> > string...
> >
>
> Isn't '''tripple-single-quoted''' basically the same as the raw string
> (only with a different delimiter?)
>
> -Jesper
>
>

Re: [VOTE] Release Apache Groovy 2.5.0-rc-1

[Paolo Di Tommaso]

Hi Paul, I've just tried locally with the lasted snapshot
(2.5.0-20180405.201629-991) and I'm getting the same error as in the CI
server.

Anyhow I assume you have the situation under control, therefore I retire my
-1


Thanks,
Paolo


On Thu, Apr 5, 2018 at 6:28 PM, Paul King <pa...@asert.com.au> wrote:

> Hi Paolo, for some reason your build isn't getting the latest snapshots.
> If you run locally, it will still fail but with a known issue related to
> final variable analysis which is on my list for rc-2.
>
> Cheers, Paul.
>
> On Fri, Apr 6, 2018 at 2:23 AM, Paolo Di Tommaso <
> paolo.ditomm...@gmail.com> wrote:
>
>> The nextflow joint build is still failing badly.
>>
>> http://ci.groovy-lang.org/viewType.html?buildTypeId=JointBui
>> lds_Nextflow_Groovy25xJointBuild
>>
>>
>> it's a -1 (tho not binding)
>>
>>
>> p
>>
>> On Thu, Apr 5, 2018 at 6:13 PM, Paul King <pa...@asert.com.au> wrote:
>>
>>>
>>> Dear development community,
>>>
>>> I am happy to start the VOTE thread for a Groovy 2.5.0-rc-1 release!
>>>
>>> This release includes 18 bug fixes/improvements as outlined in the
>>> changelog:
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
>>> ctId=12318123=12342817
>>>
>>> Tag: https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag
>>> ;h=refs/tags/GROOVY_2_5_0_RC_1
>>> Tag commit id: 1c709fc51ffb1b1ab78d8c66dfc4aa2da523c0b9
>>>
>>> The artifacts to be voted on are located as follows (r26192).
>>> Source release: https://dist.apache.org/repos/
>>> dist/dev/groovy/2.5.0-rc-1/sources
>>> Convenience binaries: https://dist.apache.org/repos/
>>> dist/dev/groovy/2.5.0-rc-1/distribution
>>>
>>> Release artifacts are signed with a key from the following file:
>>> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>>>
>>> Please vote on releasing this package as Apache Groovy 2.5.0-rc-1.
>>>
>>> Reminder on ASF release approval requirements for PMC members:
>>> http://www.apache.org/legal/release-policy.html#release-approval
>>> Hints on validating checksums/signatures (but replace md5sum with
>>> sha256sum):
>>> https://www.apache.org/info/verification.html
>>>
>>> The vote is open for the next 72 hours and passes if a majority of at
>>> least three +1 PMC votes are cast.
>>>
>>> [ ] +1 Release Apache Groovy 2.5.0-rc-1
>>> [ ]  0 I don't have a strong opinion about this, but I assume it's ok
>>> [ ] -1 Do not release Apache Groovy 2.5.0-rc-1 because...
>>>
>>> Here is my vote:
>>>
>>> +1 (binding)
>>>
>>>
>>
>

Re: [VOTE] Release Apache Groovy 2.5.0-rc-1

[Paolo Di Tommaso]

The nextflow joint build is still failing badly.

http://ci.groovy-lang.org/viewType.html?buildTypeId=JointBuilds_Nextflow_Groovy25xJointBuild


it's a -1 (tho not binding)


p

On Thu, Apr 5, 2018 at 6:13 PM, Paul King  wrote:

>
> Dear development community,
>
> I am happy to start the VOTE thread for a Groovy 2.5.0-rc-1 release!
>
> This release includes 18 bug fixes/improvements as outlined in the
> changelog:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12318123=12342817
>
> Tag: https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=
> tag;h=refs/tags/GROOVY_2_5_0_RC_1
> Tag commit id: 1c709fc51ffb1b1ab78d8c66dfc4aa2da523c0b9
>
> The artifacts to be voted on are located as follows (r26192).
> Source release: https://dist.apache.org/repos/dist/dev/groovy/2.5.0-rc-1/
> sources
> Convenience binaries: https://dist.apache.org/repos/
> dist/dev/groovy/2.5.0-rc-1/distribution
>
> Release artifacts are signed with a key from the following file:
> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>
> Please vote on releasing this package as Apache Groovy 2.5.0-rc-1.
>
> Reminder on ASF release approval requirements for PMC members:
> http://www.apache.org/legal/release-policy.html#release-approval
> Hints on validating checksums/signatures (but replace md5sum with
> sha256sum):
> https://www.apache.org/info/verification.html
>
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ ] +1 Release Apache Groovy 2.5.0-rc-1
> [ ]  0 I don't have a strong opinion about this, but I assume it's ok
> [ ] -1 Do not release Apache Groovy 2.5.0-rc-1 because...
>
> Here is my vote:
>
> +1 (binding)
>
>

Re: [RFE] Methods as expressions

[Paolo Di Tommaso]

I tend to agree. Also in Kotlin it tends a bit more readable because the
function return type is postponed.

IMO little is added by the proposed syntax extension.


p

On Tue, Mar 20, 2018 at 12:20 PM, mg  wrote:

> Am having a migraine right now so hard to concentrate / think straight but
> it seems all that syntax does is getting rid of a single character ?
>
> Integer truth() { 42 }
>
> could then be written as
>
> Integer truth() = 42
>
>
> or
>
> String hello(String name) { "Hello $name" }
>
> String hello(String name) = Hello $name"
>
> (why did you use a return keyword in your sample ?)
>
> I dont see an improvement in readability here - the main "advantage" is
> that curly braces are annoying to input on non-US keyboard layouts ;-)
>
> mg
>
>
>
>  Ursprüngliche Nachricht 
> Von: Cédric Champeau 
> Datum: 20.03.18 11:41 (GMT+01:00)
> An: dev@groovy.apache.org
> Betreff: [RFE] Methods as expressions
>
> Hi,
>
> One of the Kotlin features I really like is the short-hand notation for
> simple expression methods:
>
> class Foo {
> fun truth(): Integer = 42
> }
>
> For example, in Groovy, you write:
>
> @Controller("/") class HelloController {
>
> @Get("/hello/{name}")
> String hello(String name) {
> return "Hello $name"
> }
> }
>
>
> but we could write:
>
> @Controller("/")
> class HelloController {
> @Get("/hello/{name}")
> String hello(String name) = "Hello $name"
> }
>
>
> It's more concise and makes the "functional style" more readable. Is this
> something Groovy users would appreciate?
>
>

Re: [GEP]Lazy evaluation for Groovy 3

[Paolo Di Tommaso]

Frankly I found this confusing, it looks to me that the same concept can be
implemented just using a closure.


p

On Sat, Mar 17, 2018 at 9:08 AM, Daniel.Sun  wrote:

> Hi Guillaume,
>
> I planed to generate proxy for lazy evaluation, so even if the reference of
> object is accessed, evaluation will not be triggered either, which is
> different from @Lazy
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: Upcoming RC release for 2.5.0

[Paolo Di Tommaso]

I've double checked this and the compilation fails also locally using
`2.5.0-SNAPSHOT`.

I've managed to compile successfully using `2.5.0-beta-3` instead.


Cheers,
Paolo


On Tue, Mar 6, 2018 at 2:29 PM, Paul King <pa...@asert.com.au> wrote:

> I temporarily set CI_GROOVY_VERSION for that joint build to 2.5.0-beta-3
> but it seems to have been set to 2.4.13 regardless. Do you get the same
> errors locally as we are seeing on the CI server?
>
>
> On Tue, Mar 6, 2018 at 10:51 PM, Paolo Di Tommaso <
> paolo.ditomm...@gmail.com> wrote:
>
>> The nextflow joint build is failing badly with the current snapshot :
>>
>> http://ci.groovy-lang.org/viewLog.html?buildId=47703=bui
>> ldResultsDiv=JointBuilds_Nextflow_Groovy25xJointBuild#
>>
>> It seems it's unable static compiled classes are unable to resolve
>> extension methods such the ones defined in this class
>> <https://github.com/nextflow-io/nextflow/blob/af3ce867c54f48ea1af227df4f657aeec1da92ed/subprojects/nxf-commons/src/main/nextflow/extension/Bolts.groovy#L53>
>> .
>>
>>
>> p
>>
>> On Tue, Mar 6, 2018 at 12:41 PM, Paul King <pa...@asert.com.au> wrote:
>>
>>>
>>> I am hoping to do the first RC release of 2.5.0 late this week or next
>>> week. The plan being for a release in time for or during Greach. I still
>>> have a bunch of bugs on my list to be fixed before then, so I can't narrow
>>> it down more than that at this stage. Please work on any changes you want
>>> in for the release and any testing is greatly appreciated.
>>>
>>> Cheers, Paul.
>>>
>>>
>>
>

Re: Upcoming RC release for 2.5.0

[Paolo Di Tommaso]

The nextflow joint build is failing badly with the current snapshot :

http://ci.groovy-lang.org/viewLog.html?buildId=47703=buildResultsDiv;
buildTypeId=JointBuilds_Nextflow_Groovy25xJointBuild#

It seems it's unable static compiled classes are unable to resolve
extension methods such the ones defined in this class

.


p

On Tue, Mar 6, 2018 at 12:41 PM, Paul King  wrote:

>
> I am hoping to do the first RC release of 2.5.0 late this week or next
> week. The plan being for a release in time for or during Greach. I still
> have a bunch of bugs on my list to be fixed before then, so I can't narrow
> it down more than that at this stage. Please work on any changes you want
> in for the release and any testing is greatly appreciated.
>
> Cheers, Paul.
>
>

Re: Groovy Champions proposal feedback

[Paolo Di Tommaso]

I this proposal +1

On Fri, Mar 2, 2018 at 10:57 AM, Daniel Sun  wrote:

> +1
>
> Maybe adding a specific year will be better, e.g. Apache Groovy Community
> Award 2018
>
> Revoking championship may make champions disappointed...
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

[Paolo Di Tommaso]

I agree that groovy should continue to be compatible with java syntax as
long as possible.


Cheers,
Paolo


On Thu, Mar 1, 2018 at 5:28 PM, Guillaume Laforge 
wrote:

> 1) Very useful :-)
> 2) I think we should continue the compatibility with Java, like we're
> doing for Groovy 3, and add that syntax when it's finalized.
> 3) It's too early to think about the implementation, let's wait till the
> syntax is crystalized first!
>
> But yeah, I like the idea of supporting it.
> (and we could potentially support it before the Java version containing it
> is released)
>
> Guillaume
>
>
> On Thu, Mar 1, 2018 at 4:39 PM, Jesper Steen Møller 
> wrote:
>
>> Hi list
>>
>> Java 11 (or perhaps 12) might see a new functionality known as switch
>> expressions (https://bugs.openjdk.java.net/browse/JDK-8192963).
>>
>> While the current Groovy implicit return functionality works with the
>> switch statement as-is, the switch* expression* is a more general
>> construct, basically it is to the conditional operator (a ? b : c) what the
>> switch *statement* is to if/then/else-if/else. An example:
>>
>> int numLetters = switch (day) {
>> case MONDAY, FRIDAY, SUNDAY -> 6;
>> case TUESDAY -> 7;
>> case THURSDAY, SATURDAY -> 8;
>> case WEDNESDAY -> 9;
>> };
>>
>> with
>>
>> case LABEL -> expression;
>>
>> essentially sugar for
>>
>> case LABEL: break expression;
>>
>> As I see it: It could add utility to the Groovy language, and adopting it
>> would keep up the the Java-compatibility gap, which I think is a valuable
>> gateway-drug to discovering the joys of Groovy. The "break 
>> syntax isn't pretty, but the arrows look fine and incur no syntax
>> compatibility problem, as far as I can see.
>>
>> Now, this being Groovy, the cases should surely support the extended
>> "isCase"-support, as described so well here:
>> http://mrhaki.blogspot.dk/2009/08/groovy-goodness-switch-statement.html
>>
>> So, three questions remain:
>> 1) Useful or not?
>> 2) This Java compatibility - is it still a thing? I remember a similar
>> proposal a little while back, but this would align better with Java.
>> 3) This could be implemented using existing AST's if we *really* want
>> to, but it would be clumsy. This AST transformer compatibility - is it
>> still a thing?
>>
>> -Jesper
>>
>>
>>
>>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge  / Google+
> 
>

Re: Add a marker interface to bypass Collections and Maps formatting

[Paolo Di Tommaso]

I want to report an update on the status of this issue. In the conversation
in the GitHub pull request <https://github.com/apache/groovy/pull/566> I
was requested to perform a benchmark to evaluate  the impact of this
change.

The results are showed below:

Benchmark(size)   Mode  CntScore
Error   Units
ListBench.equalsDefaultGroovy 1  thrpt   15  2320508.042 ±
84277.415  ops/ms
ListBench.equalsDefaultGroovy10  thrpt   15  2329172.399 ±
69070.211  ops/ms
ListBench.equalsDefaultGroovy   100  thrpt   15  2354738.681 ±
64525.890  ops/ms
ListBench.equalsDefaultGroovy  1000  thrpt   15  2358917.549 ±
46171.873  ops/ms
ListBench.equalsDefaultGroovy   100  thrpt   15  2377102.274 ±
48227.814  ops/ms
ListBench.equalsWithAnnotation1  thrpt   15  2213530.048 ±
93671.364  ops/ms
ListBench.equalsWithAnnotation   10  thrpt   15  2277729.772 ±
89214.824  ops/ms
ListBench.equalsWithAnnotation  100  thrpt   15  2256582.572 ±
85712.999  ops/ms
ListBench.equalsWithAnnotation 1000  thrpt   15  2266409.619 ±
45408.683  ops/ms
ListBench.equalsWithAnnotation  100  thrpt   15  2197481.973 ±
127202.807  ops/ms
ListBench.equalsWithInterface 1  thrpt   15  2155416.804 ±
80496.840  ops/ms
ListBench.equalsWithInterface10  thrpt   15  2061873.464 ±
211658.982  ops/ms
ListBench.equalsWithInterface   100  thrpt   15  2106467.218 ±
89659.046  ops/ms
ListBench.equalsWithInterface  1000  thrpt   15  2219947.677 ±
87623.149  ops/ms
ListBench.equalsWithInterface   100  thrpt   15  2092834.055 ±
165819.668  ops/ms
ListBench.equalsDefaultGroovy 1   avgt   15   ≈ 10⁻⁶
ms/op
ListBench.equalsDefaultGroovy10   avgt   15   ≈ 10⁻⁶
ms/op
ListBench.equalsDefaultGroovy   100   avgt   15   ≈ 10⁻⁶
ms/op
ListBench.equalsDefaultGroovy  1000   avgt   15   ≈ 10⁻⁶
ms/op
ListBench.equalsDefaultGroovy   100   avgt   15   ≈ 10⁻⁶
ms/op
ListBench.equalsWithAnnotation1   avgt   15   ≈ 10⁻⁶
ms/op
ListBench.equalsWithAnnotation   10   avgt   15   ≈ 10⁻⁶
ms/op
ListBench.equalsWithAnnotation  100   avgt   15   ≈ 10⁻⁶
ms/op
ListBench.equalsWithAnnotation 1000   avgt   15   ≈ 10⁻⁶
ms/op
ListBench.equalsWithAnnotation  100   avgt   15   ≈ 10⁻⁶
ms/op
ListBench.equalsWithInterface 1   avgt   15   ≈ 10⁻⁶
ms/op
ListBench.equalsWithInterface10   avgt   15   ≈ 10⁻⁶
ms/op
ListBench.equalsWithInterface   100   avgt   15   ≈ 10⁻⁶
ms/op
ListBench.equalsWithInterface  1000   avgt   15   ≈ 10⁻⁶
ms/op
ListBench.equalsWithInterface   100   avgt   15   ≈ 10⁻⁶
ms/op


The benchmark code is available at this link
<https://github.com/apache/groovy/compare/master...pditommaso:jmh-list-equals-benchmark>.
These numbers suggest that checking the class annotation in the
`DefaultGroovyMethods.equals` method adds an overhead of ~5%, doing the
same with a marker interface ~10%.


What do you think ?


p



On Fri, Jan 26, 2018 at 3:21 PM, Paolo Di Tommaso <paolo.ditomm...@gmail.com
> wrote:

> I agree. The name @GroovyOverride sounds a good option.
>
>
>
> Cheers,
> Paolo
>
>
> On Thu, Jan 25, 2018 at 11:53 PM, MG <mg...@arscreat.com> wrote:
>
>> This looks like something that might be useful in certain scenarios. A
>> "perfect fix" would always be better, but since that might be some time off
>> (2019 being optimistic - some of the things I want Groovy to improve in
>> date back to at least 2006)...
>>
>> My only question would be, if it would perhaps make sense to introduce a
>> more generically named annotation (@AutomatismOverride, @GroovyOverride,
>> @Configuration,...), that would allow overriding/fine-tuning many of
>> Groovy's automatisms through different parameters, to avoid an
>> annotation-explosion over time ?
>>
>> mg
>>
>>
>> On 23.01.2018 09:25, Paolo Di Tommaso wrote:
>>
>> Hi all,
>>
>> I want to take the opportunity to renew my proposal and PR to add an
>> annotation that allows the override of the Groovy default formatting for
>> certain classes.
>>
>> https://github.com/apache/groovy/pull/566
>>
>>
>> To quickly remind you what the problem is, Groovy provides a nice default
>> formatting for some classes i.e. String, Map, and Collection data
>> structures which is good. But it makes impossible to override it by
>> sub-classes that implements their own toString method. The same problem for
>> the `equals` method. This makes difficult to handle some specific use
>> cases, leaving bytecode manipulation as the only alternative.
>>
>>
>> My proposal is to add an annotation named @IgnoreDefaultEqualsAndT

Re: Java raw string literals

[Paolo Di Tommaso]

I may agree that double back-tick is not nice, however the rationale of
this choice is that this syntax is meant to enable *raw* string literals
i.e. a string for which is not required to escape the content of *any*
character. In this context it makes sense. They are created exactly how
they are typed.

I have a few of use cases in which this would be very useful (think bash
scripts that can contain slashes, bash-slashes, dollar chars, back-ticks,
etc).


p

On Sat, Feb 24, 2018 at 5:43 PM, Daniel.Sun  wrote:

> Double backticks look a bit ugly IMO... I prefer the same way to escape,
> i.e.
> use \ to escape.
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: Java raw string literals

[Paolo Di Tommaso]

The proposal mention double back-ticks for a string containing a back-tick,
eg

``can`t``   // a string containing 'c', 'a', 'n', '`' and 't'


See http://openjdk.java.net/jeps/8196004


Also they are collecting users feedback, have a look at this link
.


p


On Sat, Feb 24, 2018 at 11:14 AM, Daniel Sun 
wrote:

> >  the main difference of the new Java proposal is that the Raw string
> literals do not perform any escape of special characters e.g.
> `hello\nworld`
> would *not* contain a new-line character but exactly back-slash followed by
> a `n`.
>
> OK. We should avoid escaping too in Groovy. I wonder whether raw string
> supports escaping backtick? e.g. `I\`m Daniel`
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: Java raw string literals

[Paolo Di Tommaso]

Hi,

It's true that's still a draft proposal, but considering the new fast Java
release train I think it's worth to start to think about.

Then, yes, Groovy has a plenty of string syntaxes single and double triple
quote, slashy strings, slashy dollar strings, etc.

However the main difference of the new Java proposal is that the Raw string
literals do not perform any escape of special characters e.g.
`hello\nworld` would *not* contain a new-line character but exactly
back-slash followed by a `n`.

This is handy in some use cases and therefore fill a gap in the groovy
(rich) strings syntaxes.



Cheers,
Paolo




On Fri, Feb 23, 2018 at 10:33 PM, Jochen Theodorou <blackd...@gmx.org>
wrote:

> On 23.02.2018 21:31, Paolo Di Tommaso wrote:
>
>> Hi people,
>>
>> I was wondering if there any plan to include in the new parrot parser the
>> support the new Java raw string literals.
>>
>> http://openjdk.java.net/jeps/8196004
>>
>>
>> Thoughts?
>>
>
> we have """ and we have ''', so there is no functional gap to close by
> this and it is not new for us either. I would therefore maybe wait a bit
> and see how this JEP develops. Do you have any information about the state
> of this?
>
> byye Jochen
>

Java raw string literals

[Paolo Di Tommaso]

Hi people,

I was wondering if there any plan to include in the new parrot parser the
support the new Java raw string literals.

http://openjdk.java.net/jeps/8196004


Thoughts?


Cheers,
Paolo

Re: Upcoming releases

[Paolo Di Tommaso]

The current 2.5 snapshot is producing an error in the nextflow joint build.
It seems due to a false positive variable uninitialised check:


[03:16:26][:compileGroovy] Note: /var/teamcity/buildagent-jdk8/
work/fcd731bd66de729d/src/main/groovy/nextflow/sort/BigSort.java uses
unchecked or unsafe operations.
[03:16:26][:compileGroovy] Note: Recompile with -Xlint:unchecked for
details.
[03:16:30][:compileGroovy] startup failed:
[03:16:30][:compileGroovy] /var/teamcity/buildagent-jdk8/
work/fcd731bd66de729d/src/main/groovy/nextflow/processor/TaskProcessor.groovy:
941: The variable [str] may be uninitialized
[03:16:30][:compileGroovy] . At [941:24]  @ line 941, column 24.
[03:16:30][:compileGroovy]exitCode = str.isInteger() ?
str.toInteger() : null
[03:16:30][:compileGroovy]   ^
[03:16:30][:compileGroovy]
[03:16:30][:compileGroovy] 1 error
[03:16:30][:compileGroovy]


See more here
.
The source is here
.
Let me know if you want to open an issue for this.


Cheers,
Paolo


On Tue, Feb 6, 2018 at 8:19 AM, Paul King  wrote:

>
> I am planning to prepare a 2.5.0-beta-3 release towards the end of this
> week and 2.4.14 not long after. Now's a good time to let us know if there
> is something critical you need for those releases.
>
> I am expecting 2.5.0-beta-3 to be the last beta for 2.5.0 and while there
> are a couple of things we are still planning to finish for 2.5.0, I am
> expecting the next release to kick off the RC release(s), so a final
> release shouldn't be too far away!
>
> Thanks, Paul.
>
>

Re: Upcoming releases

[Paolo Di Tommaso]

I renew my plea for this PR

https://github.com/apache/groovy/pull/566


Cheers,
Paolo




On Tue, Feb 6, 2018 at 9:11 AM, Mario Garcia  wrote:

> That's good News :)
>
> 2018-02-06 8:19 GMT+01:00 Paul King :
>
>>
>> I am planning to prepare a 2.5.0-beta-3 release towards the end of this
>> week and 2.4.14 not long after. Now's a good time to let us know if there
>> is something critical you need for those releases.
>>
>> I am expecting 2.5.0-beta-3 to be the last beta for 2.5.0 and while there
>> are a couple of things we are still planning to finish for 2.5.0, I am
>> expecting the next release to kick off the RC release(s), so a final
>> release shouldn't be too far away!
>>
>> Thanks, Paul.
>>
>>
>

Re: Add a marker interface to bypass Collections and Maps formatting

[Paolo Di Tommaso]

I agree. The name @GroovyOverride sounds a good option.



Cheers,
Paolo


On Thu, Jan 25, 2018 at 11:53 PM, MG <mg...@arscreat.com> wrote:

> This looks like something that might be useful in certain scenarios. A
> "perfect fix" would always be better, but since that might be some time off
> (2019 being optimistic - some of the things I want Groovy to improve in
> date back to at least 2006)...
>
> My only question would be, if it would perhaps make sense to introduce a
> more generically named annotation (@AutomatismOverride, @GroovyOverride,
> @Configuration,...), that would allow overriding/fine-tuning many of
> Groovy's automatisms through different parameters, to avoid an
> annotation-explosion over time ?
>
> mg
>
>
> On 23.01.2018 09:25, Paolo Di Tommaso wrote:
>
> Hi all,
>
> I want to take the opportunity to renew my proposal and PR to add an
> annotation that allows the override of the Groovy default formatting for
> certain classes.
>
> https://github.com/apache/groovy/pull/566
>
>
> To quickly remind you what the problem is, Groovy provides a nice default
> formatting for some classes i.e. String, Map, and Collection data
> structures which is good. But it makes impossible to override it by
> sub-classes that implements their own toString method. The same problem for
> the `equals` method. This makes difficult to handle some specific use
> cases, leaving bytecode manipulation as the only alternative.
>
>
> My proposal is to add an annotation named @IgnoreDefaultEqualsAndToString
> (or maybe @OverrideEqualsAndToString) to bypass the Groovy formatting and
> allow the invocation of sub-classes `toString` and `equals` methods.
>
> I agree that's a sub-optional solution, however no better solutions have
> been proposed for the current and future releases.
>
>
>
> Cheers,
> Paolo
>
>
>
> On Sun, Jun 25, 2017 at 8:35 PM, Paolo Di Tommaso <
> paolo.ditomm...@gmail.com> wrote:
>
>> Dear all,
>>
>> Groovy still does not provide a mechanism to override the `toString` and
>> `equals` methods for custom Collection and Map objects. This is a serious
>> limitation in some use cases.
>>
>> I'm proposing with the following pull request to introduce a marker
>> annotation that allows a custom object to use the `toString` and `equals`
>> as expected.
>>
>> https://github.com/apache/groovy/pull/566
>>
>>
>> Any comment or improvement is welcome.
>>
>>
>> Cheers,
>> Paolo
>>
>>
>> On Thu, Jun 2, 2016 at 1:38 AM, Paul King <pa...@asert.com.au> wrote:
>>
>>> I am +1 on improving how we handle formatting for lists and maps. My
>>> default position would be -1 on an implementation that smells like it
>>> might be "yet another hack" that we have to maintain long term. The
>>> main reason being that we are trying to streamline method selection
>>> for our revised MOP (I know not much is happening in that space right
>>> now) and it would be nicer if once that is done, the "inconsistent"
>>> results you mention could be handled in an easy to understand way.
>>> Having said that, if I get time to look into it further and can't
>>> think of a better way to approach it long term, then I could easily be
>>> moved to at least a -0.
>>>
>>> Cheers, Paul.
>>>
>>> On Tue, May 31, 2016 at 7:36 PM, Paolo Di Tommaso
>>> <paolo.ditomm...@gmail.com> wrote:
>>> > Hello guys,
>>> >
>>> > No feedback on this? Would you take in consideration a PR for this
>>> proposal?
>>> >
>>> >
>>> > Thanks,
>>> > Paolo
>>> >
>>> >
>>> > On Sat, May 28, 2016 at 6:26 PM, Paolo Di Tommaso
>>> > <paolo.ditomm...@gmail.com> wrote:
>>> >>
>>> >> Hi all,
>>> >>
>>> >> Groovy implements a built-in formatting strategy for collection and
>>> map
>>> >> objects that is surely nicer and more useful than the one provided by
>>> the
>>> >> default Java implementation for these classes.
>>> >>
>>> >> However there are use cases in which custom collection or map classes
>>> need
>>> >> to implement their own formatting rule.
>>> >>
>>> >> Currently in Groovy this is quite painful and may lead to inconsistent
>>> >> results. Take in consideration the following example:
>>> >>
>>> >> class MyList extends ArrayList {
>>>

Re: upcoming releases

[Paolo Di Tommaso]

Eventually this PR in 2.5-beta-3

https://github.com/apache/groovy/pull/566


Cheers,
Paolo


On Mon, Nov 6, 2017 at 7:00 PM,  wrote:

> And https://issues.apache.org/jira/browse/GROOVY-8289 is causing us a lot
> of pain in the debugger and appears to have a simple solution.
>

Re: New syntax explosion

[Paolo Di Tommaso]

I tend to agree as well. It should be avoid to overload the language with
cryptic operators only because the new parser allows them, even more when a
not too verbose alternative already exists.

The only that makes sense IMO are:

"!in"
"iinstanceof"
"a ?= b"

For the switch I would wait to have it implement in Java, to avoid to have
to support two eventually different syntaxes.


Best,
Paolo




On Thu, Oct 5, 2017 at 9:35 PM, Keith Suderman  wrote:

> I'm glad I'm not the only.  I've been keeping silent because I'm just a
> stodgy old fart that doesn't like change, but it does seem like there have
> been several syntax changes with little to no discussion, at least here on
> the dev list, and no pressing use cases to justify the changes.  If a
> certain construct is anticipated in Java it makes sense to be forward
> looking and provided something similar, otherwise my concern is that syntax
> will be introduced that will be incompatible with future changes to Java.
>
> Cheers,
> Keith
>
>
> On Oct 5, 2017, at 2:47 PM, Graeme Rocher  wrote:
>
> I agree. I'm not keen on if/switch on the right hand side of
> assignments at all and a??.b.c is very obscure
>
> On Thu, Oct 5, 2017 at 8:01 PM,   wrote:
>
> Before Groovy 2.6 and 3.0 are released, will there be a review of the
> syntax
> additions for inclusion in the final release?  I get "!in" and
> "!instanceof".  However, I'm am getting the feeling of "Kitchen Sink" or
> "just because we can" on recent additions to the parser.  I'm not seeing
> any
> of the new syntax adding something I can't get already with reasonably
> succinct code:
>
>
>
> `foo?['bar']` is just `foo?.getAt('bar')`
>
>
>
> `a === b` is just `a.is(b)`
>
>
>
> `a ?= b` is just `if (!a) a = b`
>
>
>
> `a??.b.c.` is just `a?.b?.c`
>
>
>
> 'def a = if (x) b else c` is just `def a = x ? b : c`
>
>
>
> `def a = switch (x) { case 'b': b; break; case 'c': c; break; }` (or
> whatever has been proposed) is just `def a = { switch(x) { ... } )()`
>
>
>
> These last two really bother me because statements and expressions have a
> distinct meaning in the language and now the meaning is blurred quite
> completely.  Why is all of this new syntax necessary?  Isn't it enough to
> have support for Java array init and lambdas now?
>
>
>
>
>
> All these new syntax options are making it difficult to entice fellow Java
> programmers around the office into using Groovy because it is Java plus a
> *few* very convenient additons.  I almost want to be able to turn off some
> of these additions so the compiler errors on them.
>
>
>
> Eric Milles
> Lead Software Engineer
>
> Thomson Reuters
>
> Email: eric.mil...@thomsonreuters.com
>
> Phone: 651-848-7040 <(651)%20848-7040>
>
>
>
>
>
> --
> Graeme Rocher
>
>
> --
> Keith Suderman
> Research Associate
> Department of Computer Science
> Vassar College, Poughkeepsie NY
> suder...@cs.vassar.edu
>
>
>
>
>

Re: Upcoming releases

[Paolo Di Tommaso]

If possible it would be nice to include GROOVY-8220
 and eventually this PR
.


Thanks,
Paolo


On Tue, Sep 12, 2017 at 9:33 AM, Guillaume Laforge 
wrote:

> +1!
>
> On Tue, Sep 12, 2017 at 9:27 AM, Paul King  wrote:
>
>>
>> Hi,
>>
>> I was planning to release 2.5.0-beta-2 probably first thing next week.
>> If you have any upcoming changes that you want in the release, please
>> get them in now or let me know if that time frame causes a problem.
>>
>> It will depend on whether we get much feedback on the beta but I would
>> anticipate moving towards the first RC release in the next month or two.
>> It would be good to get that release out the door so we can increase
>> focus on 2.6/3! :-)
>>
>> Cheers, Paul.
>>
>>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge  / Google+
> 
>

Re: Groovy using Graal

[Paolo Di Tommaso]

I've seen some presentations and Graal looks impressive. It seems Oracle is
investing a lot on it, already having other languages running on it.

IMO Groovy would be benefit a lot being able to run on Graal.



p


On Tue, Sep 5, 2017 at 2:44 AM, Paul King  wrote:

> Sounds like it might be useful for Groovy 4+.
>
>
> On 5 Sep. 2017 5:09 am, "Jochen Theodorou"  wrote:
>
>> Hi all,
>>
>> since Graal is now available in JDK9 by default I was wondering if we
>> should go into a path for deep integration with Graal if we can take
>> advantage of it.
>>
>> In the past I was quite partial to this because of the licensing of Graal
>> itself. I know from before it was GPL with or without classpath extension.
>> But even with classpath extension I was not feeling well about depending on
>> it and the trouble users would have go through to setup an optional Graal
>> part.
>>
>> Well, now since it is part of JDK9 those troubles are of the past. Now
>> everyone has a ready to use Graal afaik. And we do no longer have to
>> distribute it. That means we can consider really depending on it, like we
>> depend on the Java platform itself.
>>
>> How do others think?
>>
>> bye Jochen
>>
>

Re: Nextflow joint build running on hold version

[Paolo Di Tommaso]

OK, now the `CI_GROOVY_VERSION` is correctly defined, however this still
does not solve the issue.

I've added a test to verify that the SNAPSHOT version is correctly used by
the build and it turns out that it is not. It just uses the groovy runtime
define in the project not the one specified by the `CI_GROOVY_VERSION`.

Condition not satisfied:

System.getenv('CI_GROOVY_VERSION') == GroovySystem.getVersion()
   |   |   |
   2.4.13-SNAPSHOT |   2.4.11
   false
   10 differences (33% similarity)
   2.4.1(3-SNAPSHOT)
   2.4.1(1-)



This is also explain why the 2.5.x build was compiling successfully, while
it doesn't on my local build.

Nextflow uses a Gradle build in which this snippet
<https://github.com/nextflow-io/nextflow/commit/93934de17e3e84c1cb690c3ec2931b38f2edb8ee>
, contributed by Cédric Champeau, is supposed to override the project
groovy libraries with the latest snapshot.

Frankly it's not clear to me how that snippet is supposed to work, thus I
don't know if it's problem with the CI server configuration or with my
build file.


Any suggestion is welcome.


Cheers,
Paolo




On Mon, Jun 26, 2017 at 12:55 PM, Paul King <pa...@asert.com.au> wrote:

> Now set to 2.4.13-SNAPSHOT
>
> On Sun, Jun 25, 2017 at 11:03 PM, Paolo Di Tommaso <
> paolo.ditomm...@gmail.com> wrote:
>
>> Upgrading the Nextflow project to latest Groovy version (2.4.12) I got
>> several errors related to this issue:
>>
>> https://issues.apache.org/jira/browse/GROOVY-8237
>>
>>
>> I was a bit surprised because the joint build in the community Team-City
>> server is reporting all tests green:
>>
>> http://ci.groovy-lang.org/viewType.html?buildTypeId=JointBui
>> lds_Nextflow_Groovy24xJointBuild
>>
>>
>> When running in the CI server the groovy deps are overridden by this
>> snippet
>> <https://github.com/nextflow-io/nextflow/commit/93934de17e3e84c1cb690c3ec2931b38f2edb8ee>
>> in gradle build file and the groovy version is provided by the
>> `CI_GROOVY_VERSION  ` env variable.
>>
>> Looking in the log that variable looks outdated:
>>
>> [03:21:46] : [Step 1/1] Overriden Groovy dependency to use 2.4.4-SNAPSHOT
>>
>>
>> Would it be possible to update the config to have NF compiled against the
>> latest snapshot ?
>>
>>
>> Thanks you,
>> Paolo
>>
>>
>

Re: Add a marker interface to bypass Collections and Maps formatting

[Paolo Di Tommaso]

Dear all,

Groovy still does not provide a mechanism to override the `toString` and
`equals` methods for custom Collection and Map objects. This is a serious
limitation in some use cases.

I'm proposing with the following pull request to introduce a marker
annotation that allows a custom object to use the `toString` and `equals`
as expected.

https://github.com/apache/groovy/pull/566


Any comment or improvement is welcome.


Cheers,
Paolo


On Thu, Jun 2, 2016 at 1:38 AM, Paul King <pa...@asert.com.au> wrote:

> I am +1 on improving how we handle formatting for lists and maps. My
> default position would be -1 on an implementation that smells like it
> might be "yet another hack" that we have to maintain long term. The
> main reason being that we are trying to streamline method selection
> for our revised MOP (I know not much is happening in that space right
> now) and it would be nicer if once that is done, the "inconsistent"
> results you mention could be handled in an easy to understand way.
> Having said that, if I get time to look into it further and can't
> think of a better way to approach it long term, then I could easily be
> moved to at least a -0.
>
> Cheers, Paul.
>
> On Tue, May 31, 2016 at 7:36 PM, Paolo Di Tommaso
> <paolo.ditomm...@gmail.com> wrote:
> > Hello guys,
> >
> > No feedback on this? Would you take in consideration a PR for this
> proposal?
> >
> >
> > Thanks,
> > Paolo
> >
> >
> > On Sat, May 28, 2016 at 6:26 PM, Paolo Di Tommaso
> > <paolo.ditomm...@gmail.com> wrote:
> >>
> >> Hi all,
> >>
> >> Groovy implements a built-in formatting strategy for collection and map
> >> objects that is surely nicer and more useful than the one provided by
> the
> >> default Java implementation for these classes.
> >>
> >> However there are use cases in which custom collection or map classes
> need
> >> to implement their own formatting rule.
> >>
> >> Currently in Groovy this is quite painful and may lead to inconsistent
> >> results. Take in consideration the following example:
> >>
> >> class MyList extends ArrayList {
> >>  String toString() {
> >> this.join('-')
> >>   }
> >> }
> >>
> >> def x = new MyList()
> >> x << 1 << 2 << 3
> >>
> >> println x.toString()
> >> println x
> >> println "$x"
> >>
> >> Which prints:
> >>
> >> 1-2-3
> >> [1, 2, 3]
> >> [1, 2, 3]
> >>
> >> Both the second and third `println` use the Groovy built-in formatting
> >> method and there's no easy way to override this behaviour. Also there's
> not
> >> a clear reason why the first and the second print return a different
> output.
> >>
> >> The only options I've found is to define `MyList` with a @Delegate
> without
> >> implementing the `List` interface. But this leads to other weird side
> >> effects. The remaining possibility is to use some bytecode manipulation
> to
> >> bypass the default Groovy formatting, but it looks to me a really
> >> overkilling solution for such problem.
> >>
> >> For this reason a would like to propose to introduce a mechanism that
> >> would allow custom collection and map classes to bypass the default
> >> formatting method. This should not be too difficult. The current Groovy
> >> built-in formatting is implemented by formatList and formatMap methods.
> >>
> >> It would be enough to add a marker interface (or an annotation) that
> when
> >> applied to a class it would be used to by-pass the logic in the
> formatList
> >> and formatMap methods and simply return the string provided by the
> object
> >> `toString` method.
> >>
> >>
> >> I could easily contribute this patch however I would know the opinion of
> >> the Groovy core committers. In particular:
> >>
> >> 1) What name should have this marker interface? groovy.lagn.Something?
> >> 2) Are formatList and formatMap methods the right place to add this
> logic?
> >> 3) A similar problem exists also when using the `equals` (and hashCode?)
> >> method for collections and maps. Should this mechanism be extended also
> to
> >> this case?
> >>
> >>
> >>
> >> Best,
> >> Paolo
> >>
> >>
> >
>

Nextflow joint build running on hold version

[Paolo Di Tommaso]

Upgrading the Nextflow project to latest Groovy version (2.4.12) I got
several errors related to this issue:

https://issues.apache.org/jira/browse/GROOVY-8237


I was a bit surprised because the joint build in the community Team-City
server is reporting all tests green:

http://ci.groovy-lang.org/viewType.html?buildTypeId=JointBuilds_Nextflow_
Groovy24xJointBuild


When running in the CI server the groovy deps are overridden by this snippet

in gradle build file and the groovy version is provided by the
`CI_GROOVY_VERSION  ` env variable.

Looking in the log that variable looks outdated:

[03:21:46] : [Step 1/1] Overriden Groovy dependency to use 2.4.4-SNAPSHOT


Would it be possible to update the config to have NF compiled against the
latest snapshot ?


Thanks you,
Paolo

Re: Nextflow joint build

[Paolo Di Tommaso]

This is one of the issue:

https://issues.apache.org/jira/browse/GROOVY-8220


 It looks like that 2.5 branch has a lot of regressions with CompileStatic
.. is that possible?


Cheers,
Paolo

On Tue, Jun 6, 2017 at 10:29 PM, Paolo Di Tommaso <paolo.ditomm...@gmail.com
> wrote:

> What exactly 2.5.0-SNAPSHOT represent?
>
> All Nextflow tests are green on the joint built using Groovy
> <http://goog_1294521008>2.5 <http://goog_1294521008>.0-SNAPSHOT but it
> can't even compile it locally when using 2.5.0-beta-1
>
>
> p
>
> On Wed, Apr 5, 2017 at 6:42 PM, Paolo Di Tommaso <
> paolo.ditomm...@gmail.com> wrote:
>
>> Interesting, all nextflow tests are green with 2.5.0-SNAPSHOT but I'm
>> getting several failures with 2.5.0-alpha-1
>>
>> p
>>
>>
>> On Wed, Apr 5, 2017 at 9:18 AM, Paolo Di Tommaso <
>> paolo.ditomm...@gmail.com> wrote:
>>
>>> Thanks!
>>>
>>> p
>>>
>>> On Tue, Apr 4, 2017 at 11:12 PM, Paul King <pa...@asert.com.au> wrote:
>>>
>>>> Done.
>>>>
>>>> On Tue, Apr 4, 2017 at 10:56 PM, Paolo Di Tommaso <
>>>> paolo.ditomm...@gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Is is possible to update the Nextflow joint build so that it's tested
>>>>> against Groovy 2.4.x and 2.5.x (instead 2.3.x and 2.4.x).
>>>>>
>>>>> http://ci.groovy-lang.org/project.html?projectId=JointBuilds
>>>>> _Nextflow=1
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Paolo
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Nextflow joint build

[Paolo Di Tommaso]

What exactly 2.5.0-SNAPSHOT represent?

All Nextflow tests are green on the joint built using Groovy
<http://goog_1294521008>2.5 <http://goog_1294521008>.0-SNAPSHOT but it
can't even compile it locally when using 2.5.0-beta-1


p

On Wed, Apr 5, 2017 at 6:42 PM, Paolo Di Tommaso <paolo.ditomm...@gmail.com>
wrote:

> Interesting, all nextflow tests are green with 2.5.0-SNAPSHOT but I'm
> getting several failures with 2.5.0-alpha-1
>
> p
>
>
> On Wed, Apr 5, 2017 at 9:18 AM, Paolo Di Tommaso <
> paolo.ditomm...@gmail.com> wrote:
>
>> Thanks!
>>
>> p
>>
>> On Tue, Apr 4, 2017 at 11:12 PM, Paul King <pa...@asert.com.au> wrote:
>>
>>> Done.
>>>
>>> On Tue, Apr 4, 2017 at 10:56 PM, Paolo Di Tommaso <
>>> paolo.ditomm...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Is is possible to update the Nextflow joint build so that it's tested
>>>> against Groovy 2.4.x and 2.5.x (instead 2.3.x and 2.4.x).
>>>>
>>>> http://ci.groovy-lang.org/project.html?projectId=JointBuilds
>>>> _Nextflow=1
>>>>
>>>>
>>>> Thanks,
>>>> Paolo
>>>>
>>>>
>>>
>>
>

Re: Nextflow joint build

[Paolo Di Tommaso]

No hurry. Some failures are caused by this issue:

https://issues.apache.org/jira/browse/GROOVY-8144

Others I still need to investigate.


p

On Thu, Apr 6, 2017 at 4:28 AM, Paul King <pa...@asert.com.au> wrote:

> What errors are you getting?
>
> I'm on holidays, so only have my travel laptop with windows and limited
> bandwidth to update my ubuntu vms. On windows there were over 100 failed
> tests even on 2.4.10.
>
> Cheers, Paul.
>
> On Thu, Apr 6, 2017 at 2:42 AM, Paolo Di Tommaso <
> paolo.ditomm...@gmail.com> wrote:
>
>> Interesting, all nextflow tests are green with 2.5.0-SNAPSHOT but I'm
>> getting several failures with 2.5.0-alpha-1
>>
>> p
>>
>>
>> On Wed, Apr 5, 2017 at 9:18 AM, Paolo Di Tommaso <
>> paolo.ditomm...@gmail.com> wrote:
>>
>>> Thanks!
>>>
>>> p
>>>
>>> On Tue, Apr 4, 2017 at 11:12 PM, Paul King <pa...@asert.com.au> wrote:
>>>
>>>> Done.
>>>>
>>>> On Tue, Apr 4, 2017 at 10:56 PM, Paolo Di Tommaso <
>>>> paolo.ditomm...@gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Is is possible to update the Nextflow joint build so that it's tested
>>>>> against Groovy 2.4.x and 2.5.x (instead 2.3.x and 2.4.x).
>>>>>
>>>>> http://ci.groovy-lang.org/project.html?projectId=JointBuilds
>>>>> _Nextflow=1
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Paolo
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Nextflow joint build

[Paolo Di Tommaso]

Thanks!

p

On Tue, Apr 4, 2017 at 11:12 PM, Paul King <pa...@asert.com.au> wrote:

> Done.
>
> On Tue, Apr 4, 2017 at 10:56 PM, Paolo Di Tommaso <
> paolo.ditomm...@gmail.com> wrote:
>
>> Hi,
>>
>> Is is possible to update the Nextflow joint build so that it's tested
>> against Groovy 2.4.x and 2.5.x (instead 2.3.x and 2.4.x).
>>
>> http://ci.groovy-lang.org/project.html?projectId=JointBuilds
>> _Nextflow=1
>>
>>
>> Thanks,
>> Paolo
>>
>>
>

Nextflow joint build

[Paolo Di Tommaso]

Hi,

Is is possible to update the Nextflow joint build so that it's tested
against Groovy 2.4.x and 2.5.x (instead 2.3.x and 2.4.x).

http://ci.groovy-lang.org/project.html?projectId=JointBuilds_Nextflow=1


Thanks,
Paolo

Re: Negative relational operators for Groovy 3

[Paolo Di Tommaso]

+1


On Fri, Nov 18, 2016 at 1:58 PM, Jochen Theodorou  wrote:

>
> I think !instanceof and !in are ok. The others... not sure here. Right now
> a=b, which means !< is >=. And in this case I
> actually prefer >=.
>
> bye Jochen
>

Re: What Christmas gifts for us? ;)

[Paolo Di Tommaso]

Both of them !!

:)

On Tue, Nov 1, 2016 at 1:14 PM, Remi Forax  wrote:

> or a photo of Guillaume dress as Father Chrismas :)
>
> Rémi
>
> - Mail original -
> > De: "Daniel.Sun" 
> > À: d...@groovy.incubator.apache.org
> > Envoyé: Mardi 1 Novembre 2016 12:23:55
> > Objet: What Christmas gifts for us? ;)
>
> > Dear Groovy Core Team,
> >
> >  There are about 55 days before Christmas's coming, what gifts are
> you
> > going to give us?  ;)
> >
> >  The first release of Groovy 2.5.0 beta? and with what features?
> >
> > Best Regards,
> > Daniel.Sun
> >
> >
> >
> > --
> > View this message in context:
> > http://groovy.329449.n5.nabble.com/What-Christmas-
> gifts-for-us-tp5736437.html
> > Sent from the Groovy Dev mailing list archive at Nabble.com.
>

Re: Custom operator for Groovy 3

[Paolo Di Tommaso]

Hi Daniel,

I haven't had realised the need of the backtick characters to define and
use custom operators. Still useful though much less *sexy* IMO.



Cheers,
Paolo

On Sun, Oct 30, 2016 at 10:30 AM, Daniel.Sun 
wrote:

> Hi Paolo,
>
> Here are some example code. As you see, the special character(`) is
> required to define the custom operator:
>
> // Custom operators should be declared first, then use.
> // It can be declared in the class or script, but it must be declared
> static.
> class A {
> static "`>?`"(int a, int b) {
> return Math.max(a, b);
> }
> }
>
> static "` return Math.min(a, b);
> }
>
> // Notice: the custom operator has higher priority to avoid parentheses in
> most cases
> assert 2 == 1 `>?` 2
> assert 1 == 1 ` assert 7 == (1 + 3) `>?` (2 + 5)
> assert 9 == 1 + 3 `>?` 2 + 5
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/Custom-operator-for-Groovy-3-tp5736388p5736394.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.
>

Re: Custom operator for Groovy 3

[Paolo Di Tommaso]

This sounds a cool feature for DSL writers. What characters are eligible
for custom operators?


Cheers,
Paolo


On Sun, Oct 30, 2016 at 8:02 AM, 孙 岚  wrote:

> Hi all,
>
>  The new parser support defining custom operator now. The initial
> implementation is on the customOperator branch of groovy-parser(
> https://github.com/danielsun1106/groovy-parser/tree/customOperator).
>
>   Some examples can be found at https://github.com/
> danielsun1106/groovy-parser/blob/c3259607c4ee0cda6e5619bed35d06
> 74e26f78aa/src/test/resources/core/CustomOperator_01x.groovy
>
>In order to make the custom operator have more priorities, the
> custom operators have lower priority by default, and the priority can be
> changed by using parentheses.
>
>Any thoughts?
>
> Cheers,
> Daniel.Sun
>
>
>

Re: Serious memory leak in groovy 2.4.7?

[Paolo Di Tommaso]

I've noticed a similar problem recently.


p

On Wed, Sep 28, 2016 at 9:23 PM, Jeff Adamson  wrote:

> Using GroovyShell to evaluate expressions appears to leak permgen space in
> 2.4.7 when run with oracle java 7 jvm.
>
> Should I open a bug report or is there an existing one I can link to?
>
> Using groovy 2.4.7: this script causes perm-gen error in java 1.7. After
> approx 24 thousand evaluate calls it slows for a while due to GC overhead,
> then expands perm space and usage rises again until failing OOM ~41k calls
> and 7 minutes.
> Using groovy 2.4.6: failure is same as 2.4.7 after 4.5 minutes
> Using groovy 2.4.0: increases perm-gen usage after a couple minutes, it
> does reclaim a large chunk and seems to attain a steady state of usage.
> completing in 5 minutes.
> Using groovy 2.3.9: perm-gen has a steady-state memory usage pattern for
> entire run without any slowdowns over 7.5 minutes
> Using groovy 1.8.9: same as 2.3.9.
>
> =
> long sleep = 0;
> String scriptText = "println this.binding.variables; return true;";
>
> for (int trial = 0; trial < 100; trial ++) {
> Thread.sleep(sleep);
> for (int i = 0; i < 1000; i++) {
>
> Map bind = new HashMap();
> bind.put("bindingObject", "a binding object "+i);
>
> Object result = null;
> System.out.println("Run "+trial+"."+i);
>
> GroovyShell shell = new GroovyShell(new Binding(bind));
> result = shell.evaluate(scriptText);
>
> System.out.println(trial+"."+i+" result:"+result);
> System.out.println();
> }
> }
> 
>
> $ export JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-i386
> $ groovy -version
> Groovy Version: 2.4.7 JVM: 1.7.0_111 Vendor: Oracle Corporation OS: Linux
> $ groovy groovyOOM.groovy
> 
> Run 41.381
> Caught: java.lang.OutOfMemoryError: PermGen space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError:
> PermGen space
> at sun.misc.Unsafe.defineClass(Native Method)
> at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:63)
>
> *(See attached file: Screenshot from 2016-09-28 13:38:22.png)*
>
>
>
>
>
> Regards,
> Jeff Adamson
>

Add a marker interface to bypass Collections and Maps formatting

[Paolo Di Tommaso]

Hi all,

Groovy implements a built-in formatting strategy for collection and map
objects that is surely nicer and more useful than the one provided by the
default Java implementation for these classes.

However there are use cases in which custom collection or map classes need
to implement their own formatting rule.

Currently in Groovy this is quite painful and may lead to inconsistent
results. Take in consideration the following example:

class MyList extends ArrayList {
 String toString() {
this.join('-')
  }
}

def x = new MyList()
x << 1 << 2 << 3

println x.toString()
println x
println "$x"

Which prints:

1-2-3
[1, 2, 3]
[1, 2, 3]

Both the second and third `println` use the Groovy built-in formatting
method and there's no easy way to override this behaviour. Also there's not
a clear reason why the first and the second print return a different
output.

The only options I've found is to define `MyList` with a @Delegate without
implementing the `List` interface. But this leads to other weird side
effects. The remaining possibility is to use some bytecode manipulation to
bypass the default Groovy formatting, but it looks to me a really
overkilling solution for such problem.

For this reason a would like to propose to introduce a mechanism that would
allow custom collection and map classes to bypass the default formatting
method. This should not be too difficult. The current Groovy built-in
formatting is implemented by formatList

and formatMap

methods.

It would be enough to add a marker interface (or an annotation) that when
applied to a class it would be used to by-pass the logic in the formatList
and formatMap methods and simply return the string provided by the object
`toString` method.


I could easily contribute this patch however I would know the opinion of
the Groovy core committers. In particular:

1) What name should have this marker interface? groovy.lagn.Something?
2) Are formatList and formatMap methods the right place to add this logic?
3) A similar problem exists also when using the `equals` (and hashCode?)
method for collections and maps. Should this mechanism be extended also to
this case?



Best,
Paolo