Re: Optional modules and Groovy 4
+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: [ANNOUNCE] Apache Groovy 3.0.4 Released
Nice work, Paul. 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 safe indexing and ternary expression
The vote for releasing Groovy 3 has passed with at least three +1 from PMC members. In other words, all of changes of Groovy 3 have been reviewed and not incubating any more. As to safe indexing, we have to admit we missed some scenarios to check, so the ambiguities are introduced by accident. But we can tweak it as I proposed and not just disable the feature because of some glitch. Further more, though the new Parrot parser can keep compatible with the old parser at most cases and passes tons of tests, but no one can assure 100% compatibility, so in order to avoid potential issue, we should disable or remove Parrot parser in Groovy 3? No, we will try our best to weak it. Same logic to safe indexing. Also, I think we all understand Groovy is not a toy. At last but not least, I really worry about the future of Groovy programming. If it just chases the steps of Java, it will just be another Java with some existing its own features inherited from Groovy elders, e.g. Guillaume, Jochen, Cedric, Paul, etc. (My 2 cents) 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 safe indexing and ternary expression
Yep ;-) Optional parentheses is nice to DSL but introduces some ambiguities too :-( 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
About eliminating ambiguities safe indexing and ternary expression
Hi all,
Safe indexing has been introduced since Groovy 3.0.0, it is useful but
confuses both parser and users sometimes because it is not a real operator
in order to not breaking existing code as possible as we could. For example,
```
// https://issues.apache.org/jira/browse/GROOVY-9522
def a() { null }
def b() { '' }
a()?[b(), a()].join(','):b() // statement with ambiguities
```
The above statement with ambiguities can be parsed into:
1) safe indexing expression, `a()?[[b(), a()]].join([',': b()])`
2) ternary expression, `a() ? ([b(), a()].join(',')) : b()`
As safe indexing(i.e. `?[`) has same precedence with safe reference(i.e.
`?.`), safe indexing has higher precedence than ternary expression. When
ambiguities appear, the expression with ambiguities will be parsed into safe
indexing. As a result, the potential issue is hard for user to find early
and is ususally found when code has been executed...
So I propose to make safe indexing operator `?[` become a real operator,
i.e. it will be defined in the groovy lexer.
* pros:
1) No ambiguities
2) Better parsing performance
* cons:
1) Breaking some existing ternary expressions without spaces between`?` and
`[`, e.g. `true?[0] : [1]` will be broken, so it has to be rewritten to
`true? [0] : [1]`
As Groovy 3 has been released, I proposed to apply the change to Groovy 4.
Any thoughts?
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: Modernize groovy?
STC has been improved a lot in Groovy 3, thanks to Eric's hard work! For medium-to-large projects, finding bugs early is very important, so I suggest enabling STC by default. As for Groovy itself, it's a great language especially for Java developers, but it is lack of manpower to evolve fast and do some marketing. Luckily, we have OCI sponsor Paul to contribute Groovy part-time, and we have open collective "Friends of Groovy" to gain financial contribution, which can sponsor more contributors to achieve bug fixing or new features, e.g. I wish FoG could sponsor Jochen complete the new MOP and Jochen would accept the suggestion :-) 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: [ANNOUNCE] Apache Groovy 3.0.3 Released
Nice work, Paul. 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: Next releases?
Hi Paul, It's OK to me. 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
Nice catch ;-) 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
Hi Jochen,
> How about unifying the other way around and make 1 and 2 both a method
> call with a closure for meth?
Groovy 3 has already unified them by accident... but some spock code is
broken, so we are trying to find a way to please everyone ;-)
```
modification| expected
{ Instant i, ZoneId z -> i.plusSeconds(1) } | defaultInstant.plusSeconds(1)
```
(See https://issues.apache.org/jira/browse/GROOVY-9484)
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
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
Actually, we have already force some code style... But the code style is not
unified:
2.5.8 parses the following code as a variable and a method call with closure
argument
```
a | meth { p ->
}
```
Let's add a newline. 2.5.8 parses the following code as binary expression
and a closure
```
a | meth
{ p ->
}
```
But 3.0.2 parses the above both code as a variable and a method call with
closure argument.
To be frank, I am inclined to accept the behaviour of 3.0.2, it is unified,
but it breaks some spock code:
```
modification| expected
{ Instant i, ZoneId z -> i.plusSeconds(1) } | defaultInstant.plusSeconds(1)
```
(See https://issues.apache.org/jira/browse/GROOVY-9484)
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
AFAIK, Groovy learned quite a few design ideas from many great language, e.g. Ruby. The optional parentheses feature was inspired by Ruby. The feature makes Groovy more friendly as DSL to users, but ambiguities introduced... Ruby has similar troubles(See the following link) https://stackoverflow.com/questions/26480823/why-does-white-space-affect-ruby-function-calls 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: [ANNOUNCE] Apache Groovy 3.0.2 released
AFAIK, java.lang.Object.clone() is a protected method. If its subclass does not override it and make it public, we will get illegal access warning. 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: mini GEP feedback: GROOVY-9442
As \s is invalid in the strings in the past, the GEP will not break any existing code and can enhance the compatibility with Java. +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 3.0.2 (take 3)
All tests pass, and my smoke tests run well on groovySh and groovy console. +1 (binding) 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.4.19
+1 (binding) 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: bug fix releases ...
Hi Paul, How about enabling indy by default in the 4.0 alpha release? 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: [ANNOUNCE] Apache Groovy 3.0.1 released
Nice work, Paul. 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: I turned off comments at blogs.apache.org
+1 - 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 3.0.1
+1 (binding) All tests pass on my local machine: https://gradle.com/s/bw365vftby2lo The smoke tests run well in the groovyConsole and groovySh of the convenience binary distribution 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: 3.0.0 glitch
Not too bad, we will have a better release soon ;-) 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 3.0.0
+1 (binding) All tests pass on my local machine: https://scans.gradle.com/s/rntcuyeb4mtjc Also, I built the binary distribution from the source distribution successfully: https://gradle.com/s/h25t4se4fqhra At last, I ran smoke tests in the groovySh and groovyConsole of the newly built binary distribution, all of the smoke tests pass, too. 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: 3.0.0 GA release
Hi Paul, Sam and I are trying to tweak rules for better performance and better error messages. We should be able to complete most of easy parts by this weekend, and the hard parts such as handling missing right parenthesis efficiently may be postponed to minor releases of 3.0.x, e.g. 3.0.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: RE: Groovy 3 very slow stub generation
I tried to remove the following error alternative of `rparen`, parsing all groovy source files under nextflow module[1] with 4.0.0-SNAPSHOT takes only "14s". https://github.com/apache/groovy/blob/GROOVY_3_0_0_RC_3/src/antlr/GroovyParser.g4#L1232-L1234 *4.0.0-SNAPSHOT antlr4 parser: 14s* result-4.log <http://groovy.329449.n5.nabble.com/file/t340716/result-4.log> profile-4.zip <http://groovy.329449.n5.nabble.com/file/t340716/profile-4.zip> *4.0.0-SNAPSHOT antlr2 parser: 6s* result-2.log <http://groovy.329449.n5.nabble.com/file/t340716/result-2.log> profile-2.svg <http://groovy.329449.n5.nabble.com/file/t340716/profile-2.svg> Cheers, Daniel.Sun [1] https://github.com/nextflow-io/nextflow/tree/master/modules/nextflow - 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
The current result of parsing all groovy source files under nextflow module[1] with 3.0.0-rc-3 and the distribution built from master. After some rules tweaked, about 39.8% time is saved util now(Formula: (103s - 62s) / 103s = 39.8%). *3.0.0-rc-3 costs 103s* result-3.log <http://groovy.329449.n5.nabble.com/file/t340716/result-3.log> profile-3.svg <http://groovy.329449.n5.nabble.com/file/t340716/profile-3.svg> *4.0.0-SNAPSHOT costs 62s* result-4.log <http://groovy.329449.n5.nabble.com/file/t340716/result-4.log> profile-4.svg <http://groovy.329449.n5.nabble.com/file/t340716/profile-4.svg> Sam and I are still trying to tune the performance of the antlr4 parser. Thanks a lot for your help, Sam :-) Cheers, Daniel.Sun [1] https://github.com/nextflow-io/nextflow/tree/master/modules/nextflow - 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] 03/08: GROOVY-9380: VMPlugin refactor: Coalesce Java5 through Java7 into Java8
Hi Jochen, > but since you decided to move them now I would recommend to do it > "proper". Agreed ;-) > compiler specific static methods out of the VMplugin into the compiler Which classes do you recommend to accept the compiler specific static methods? 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
Hi Paolo, As you can see, Sam and I have been trying to improve the performance of the antlr4 parser recently. I believe the performance could be improved a lot, but antlr4 parser will be slower than antlr2 parser as a whole finally due to the following reasons(including but not limited to): 1) Groovy 3's grammar is more complicated than Groovy 2's 2) Different algorithms used by antlr2 and antlr4, as I said in the previous email > What is the maximum number of lines of code that a source file should > contain to prevent perf degradation? It needs some tests. Let's wait for the tuning result ;-) 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
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: RE: Groovy 3 very slow stub generation
Hi Eric, Thanks a lot for your help. The top time-consuming method `closure` is an internal method of the implementation of antlr4. It's hard for us to change. Luckily, Sam Harwell, the co-author of antlr4, is trying to help us tune the performance of the antlr4 parser, too. But Groovy's grammar is quite complicated and contains some ambiguities, so it's hard to tune... fingers crossed... Also, I have an idea as a workaround: let's initialize the DFA cache by parsing usual code snippets, then serialize the DFA cache into a file, which will be bundled in the groovy-3.0.0.jar. When groovy starts, the file containing the DFA cache will be loaded, thus the performance of parsing can be improved a lot at the first time of parsing. 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
Here is the flame graph for parsing all groovy source files under nextflow module[1] with the distribution built from master. profile.svg <http://groovy.329449.n5.nabble.com/file/t340716/profile.svg> Cheers, Daniel.Sun [1] https://github.com/nextflow-io/nextflow/tree/master/modules/nextflow - 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: jira changes
"help-wanted" could make contributors think the issue is very hard to fix ;-) 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
Here is the flame graph for parsing all groovy source files under nextflow module[1] with 3.0.0-rc-3 profile-3.svg <http://groovy.329449.n5.nabble.com/file/t340716/profile-3.svg> Cheers, Daniel.Sun [1] https://github.com/nextflow-io/nextflow/tree/master/modules/nextflow - 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
Here is the flame graph for parsing all groovy source files under nextflow module[1] with the distribution build from master branch[2] profile.svg <http://groovy.329449.n5.nabble.com/file/t340716/profile.svg> Cheers, Daniel.Sun [1] https://github.com/nextflow-io/nextflow/tree/master/modules/nextflow [2] https://github.com/apache/groovy - 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
LGTM 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
I created a branch to reproduce the performance issue: https://github.com/apache/groovy/commits/nextflow-perf-issue Here is the test: https://github.com/apache/groovy/blob/nextflow-perf-issue/src/test/groovy/bugs/StubGenTest.groovy After you run the test, you will find Parrot parser runs slower at the first time, and will be much faster when run twice, but still slower than antlr2 parser. Any help is appreciated :-) 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
Agreed. If time allowed, I prefer to profile and tune the performance. BTW, if you could do a favor, that would be great. 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
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
Hi Paolo, When stubs are being generated, the first stubs generation will probably miss cache, but the performance of Parrot parser relies on its cache heavily, so it will run faster and faster while cache is filled fuller and fuller, which is the reason why antlr4 recommends NEVER clear its cache. In this case, I suggest enable gradle's build cache, it will run slower at the first time and the subsequent building will be faster. It takes about 81.572s to generate stubs for :nextflow module with Parrot parser for the first time, but IntelliJ IDEA takes more than 5 minutes to build, I think JetBrains team should address the cause. 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
Generating stubs with antlr2 parser is much faster than parsing with antlr2 parser, if we can work out the cause, the performance issue of generating stubs with antlr4 can be solved. Assuming some operations are skipped. Here is the labs branch: https://github.com/apache/groovy/tree/nextflow-perf-issue I wish we could address the issue ASAP, any help would be appreciated ;-) 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
The performance issue can be reproduced by the following script, which is
placed under "nextflow-master\modules\nextflow" directory:
(GenerateStubs.groovy)
```
def ant = new groovy.ant.AntBuilder()
ant.project.baseDir = new File('.')
ant.delete(dir: 'build')
ant.mkdir(dir: 'build')
ant.taskdef(name: 'generateStubs', classname:
'org.codehaus.groovy.ant.GenerateStubsTask')
def b = System.currentTimeMillis()
ant.generateStubs(srcdir: 'src', destdir: 'build')
def e = System.currentTimeMillis()
println "${(e - b) / 1000}s elapsed"
def buildDir = new File(ant.project.baseDir, "build")
println buildDir.list()
```
The steps to reproduce the performance issue:
```
D:\_TEMP\nextflow-master\modules\nextflow>set JAVA_OPTS=-Xms2g -Xmx2g
-Dgroovy.antlr4.cache.threshold=600 -Dgroovy.antlr4=false
D:\_TEMP\nextflow-master\modules\nextflow>groovy GenerateStubs.groovy
[delete] Deleting directory
D:\_TEMP\nextflow-master\modules\nextflow\build
[mkdir] Created dir: D:\_TEMP\nextflow-master\modules\nextflow\build
[generateStubs] Generating 611 Java stubs to
D:\_TEMP\nextflow-master\modules\nextflow\build
[generateStubs] Generated 779 Java stub(s)
7.977s elapsed
[FunctionalTests.java, groovy, misc, nextflow, test]
D:\_TEMP\nextflow-master\modules\nextflow>set JAVA_OPTS=-Xms2g -Xmx2g
-Dgroovy.antlr4.cache.threshold=600 -Dgroovy.antlr4=true
D:\_TEMP\nextflow-master\modules\nextflow>groovy GenerateStubs.groovy
[delete] Deleting directory
D:\_TEMP\nextflow-master\modules\nextflow\build
[mkdir] Created dir: D:\_TEMP\nextflow-master\modules\nextflow\build
[generateStubs] Generating 611 Java stubs to
D:\_TEMP\nextflow-master\modules\nextflow\build
[generateStubs] Generated 779 Java stub(s)
81.572s elapsed
[FunctionalTests.java, groovy, misc, nextflow, test]
D:\_TEMP\nextflow-master\modules\nextflow>
```
I am quite curious about the antlr2 parser result "7.977s" because "57.177s"
cost when we parsed all the groovy source files with antlr2 parser[1]
Cheers,
Daniel.Sun
[1]
http://groovy.329449.n5.nabble.com/Groovy-3-very-slow-stub-generation-tp5762698p5764332.html
-
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
Here is the detailed result: results.zip <http://groovy.329449.n5.nabble.com/file/t340716/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
If you find the performance issue is gone when you disable the Parrot parser
with `-Dgroovy.antlr4=false`, you can try to enable the Parrot parser again
and apply `-Dgroovy.antlr4.cache.threshold=200` shown as follows.
```
compileGroovy {
groovyOptions.fork = true
groovyOptions.forkOptions.jvmArgs +=
["-Dgroovy.antlr4.cache.threshold=200"] // you can try to increase the
threshold if your project contains many Groovy source files.
}
```
The greater the value of threshold is, the longer the cache will be
reused(i.e. not be cleared), but it will require bigger JVM heap.
Note: antlr4 recommends never to clear the cache for better performance, but
Parrot parser will clear the cache to avoid OOME when threshold reaches.
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
FYI.
```
compileGroovy {
groovyOptions.fork = true
groovyOptions.forkOptions.jvmArgs += ["-Dgroovy.antlr4=false"] //
disable the Parrot parser
}
```
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
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: [ANNOUNCE] Apache Groovy 3.0.0-rc-3 released
Nice work, Paul! 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
About native support for lazy constants
Hi all, I read an article[1] about the new features of Java 11 just now, and find "JEP 309: Dynamic Class-File Constants"[2] can help us implement lazy constants elegantly, e.g. `@Lazy static final Object SOME_LAZY_CONST = `. The feature is very useful, so I propose to add *native* support for lazy constants in some future version of Groovy. Any thoughts? Cheers, Daniel.Sun [1] https://javabeginnerstutorial.com/core-java-tutorial/java-11-new-features/ [2] https://openjdk.java.net/jeps/309 - 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: += and -= no longer rejected in assertion statement in Groovy 3
In Java, `int a = 0; assert a+=1` will fail to compile because expecting boolean value, but `int a = 0; assert 0 == (a+=1)` is OK, so I think we forbidden assignments seems not correct... 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 3.0.0-rc-3
All tests pass on my local machine: https://gradle.com/s/auet7ssjbdxns My smoke tests run well in the groovy console and groovy shell, which are built from the source distribution too. +1 (binding) 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.9
+1 (binding) 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.4.18
+1 (binding) 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 the performance of indy
Hi Jochen, > If you want to get the maximum performance then I would suggest to work with the guards instead of falling back to a hashed map. Thanks for your suggestions :-) After we constructed the following "tree" MH with guards, we have to set target to link the MH to the related callsite. > > Guard(String) > / \ > MH(same(String)Guard(Float) >/ \ >MH(same(float)) Guard(Integer) > / \ > MH(same(int))Fallback to select But the "setTarget" may cause poor performance because JVM may do some de-opt shown as GROOVY-8298: ``` "qtp2078714399-360525": running, holding [771bcf60] at java.lang.invoke.MethodHandleNatives.setCallSiteTargetNormal(Native Method) at java.lang.invoke.CallSite.setTargetNormal(CallSite.java:258) at java.lang.invoke.MutableCallSite.setTarget(MutableCallSite.java:154) at org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.doCallSiteTargetSet(Selector.java:909) at org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.setCallSiteTarget(Selector.java:969) at org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:228) at java.lang.invoke.LambdaForm$DMH/1665404403.invokeStatic_L3IL5_L(LambdaForm$DMH) at java.lang.invoke.LambdaForm$BMH/1828868503.reinvoke(LambdaForm$BMH) at java.lang.invoke.LambdaForm$reinvoker/1917025677.dontInline(LambdaForm$reinvoker) at java.lang.invoke.LambdaForm$MH/462773420.guard(LambdaForm$MH) at java.lang.invoke.LambdaForm$MH/1947020920.linkToCallSite(LambdaForm$MH) ``` 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: Upcoming releases: 2.4.18/2.5.9/final 3.0 RC
Hi Paul, I suggest the following PRs could be included in final 3.0 RC. 1) PR#1135[1] for GROOVY-8298 is ready to merge 2) PR#1137[2] for GROOVY-8296 LGTM Cheers, Daniel.Sun [1] https://github.com/apache/groovy/pull/1135 [2] https://github.com/apache/groovy/pull/1137 - 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 the performance of indy
The PR#1135[1] implements the PIC for Groovy indy. As the book "Efficient Polymorphic Calls" said[2], "If a send is megamorphic(invokes many different methods), it cannot be handled efficiently by PICs. Fortunately, such sends are the exception rather than the rule.", so I will not spend more time to improve the performance for the "exception"... Cheers, Daniel.Sun [1] https://github.com/apache/groovy/pull/1135 [2] https://books.google.com.ph/books?id=TRTI80RGWjoC=PA20=PA20=CLR+monomorphic+inline+cache=bl=qAoVAiPOvf=ACfU3U2-kxZVXm7lw8ircNKeAxIwmmdcYw=zh-CN=X=2ahUKEwj21d_HlPjmAhUc8XMBHV4KBhYQ6AEwAnoECAoQAQ#v=onepage=false - 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 the performance of indy
Hi Jochen,
I am still thinking about how to improve indy performance further in
the method overload cases, e.g.
```
def same(String obj) { return obj }
def same(int obj) { return obj }
def same(float obj) { return obj }
for (int i = 0; i < 10; i++) {
[1, 1.0f, '1.0'].each { same(it) }
}
```
If we cache both receiver type and argument types, I find the
performance of this case can be improved a lot, but other cases performance
is reduced quite a bit too... so I am trying 2 levels cache: the 1st level
cache is the current cache for receiver type, its size is fixed as 16 by
default, and I want to add 2nd level cache is for caching argument types,
its size will be fixed as 16 by default too. The 2 caches are seperated, so
receiver types kept in 1st level cache will not be cleared, and 2nd level
cache can provide more hot candidates for better performance.
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 the performance of indy
FYI. https://github.com/apache/groovy/pull/1135#issuecomment-571961230 - 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 the performance of indy
Yep, we are comparing the performance of different version of DYNAMIC Groovy. The percentage formula for "a VS b": (a - b) / b. NOTE: a and b in the formula are scores output by JMH. 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: += and -= no longer rejected in assertion statement in Groovy 3
Hi Marcin, Thanks for your reporting the issue. Would you mind to submit a JIRA ticket to track 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
About the performance of indy
Hi all, The performance of indy has been improved a lot, here is the report[1]: Benchmark indy2 VS indy1 indy2 VS cs CallsiteBench.dispatch_megamorphic 3675% 25.83% CallsiteBench.dispatch_monomorphic 5.72% 188.62% CallsiteBench.dispatch_polymorphic 3000% -17.11% (Note: indy2: the indy with improved performance, indy1: the old indy, cs: the legacy callsite caching used by default now) If nobody rejects the PR1135[2] in 72 hours, I will merge it. As for whether to enable indy by default, it will be another topic... At last, I want to thank Jochen for reviewing PR1135[2] and thank Cédric for helping me solve the Gradle dependency usage issue. Cheers, Daniel.Sun [1] https://github.com/apache/groovy/pull/1135#issuecomment-571961230 [2] https://github.com/apache/groovy/pull/1135 - 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 the indy implementation
Hi Jochen, Thanks for your sharing the history of implementing indy for Groovy :-) I am trying to understand how Groovy supports indy, and I want to implement PIC after I understand the rationale. As you know, it is very important for the performance. As for setting propery in indy, I will try to thrash out the solution... Fingers crossed ;-) 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
About the indy implementation
Hi all,
As Groovy 4 will focus on indy and eliminate the old call sites, I am
trying to walk through the implementation of indy...
Could you tell me why setting property is not supported in indy? It
is in TODO list, or not supported on purpose? Thanks in advance :-)
```
public static Selector getSelector(MutableCallSite callSite, Class
sender, String methodName, int callID, boolean safeNavigation, boolean
thisCall, boolean spreadCall, Object[] arguments) {
CALL_TYPES callType = CALL_TYPES_VALUES[callID];
switch (callType) {
case INIT: return new InitSelector(callSite, sender, methodName,
callType, safeNavigation, thisCall, spreadCall, arguments);
case METHOD: return new MethodSelector(callSite, sender,
methodName, callType, safeNavigation, thisCall, spreadCall, arguments);
case GET:
return new PropertySelector(callSite, sender, methodName,
callType, safeNavigation, thisCall, spreadCall, arguments);
case SET:
throw new GroovyBugError("your call tried to do a property
set, which is not supported.");
case CAST: return new CastSelector(callSite, arguments);
default: throw new GroovyBugError("unexpected call type");
}
}
```
(
https://github.com/apache/groovy/blob/master/src/main/java/org/codehaus/groovy/vmplugin/v7/Selector.java#L132
)
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: 3rc2 regression?
> Another weird line is the reader which uses a writer config Yep. I tried to fix the bytecode issues in the past: https://github.com/apache/groovy/pull/1103 But the PR was not accepted. Also, I have not much spare time to continue, so leave it as it is... 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: 3rc2 regression?
I think the original code has bugs... The hardcoded `4` can not match any
valid ASM API version, so `IllegalArgumentException` will be thrown.
int ASM4 = 4 << 16 | 0 << 8;
int ASM5 = 5 << 16 | 0 << 8;
int ASM6 = 6 << 16 | 0 << 8;
int ASM7 = 7 << 16 | 0 << 8;
4 == ASM7 || 4 == ASM6 || 4 == ASM5 || 4 == ASM4 // yields `false`
/**
* Constructs a new {@link ClassVisitor}.
*
* @param api the ASM API version implemented by this visitor. Must be one
of {@link
* Opcodes#ASM4}, {@link Opcodes#ASM5}, {@link Opcodes#ASM6} or {@link
Opcodes#ASM7}.
* @param classVisitor the class visitor to which this visitor must
delegate method calls. May be
* null.
*/
public ClassVisitor(final int api, final ClassVisitor classVisitor) {
if (api != Opcodes.ASM7 && api != Opcodes.ASM6 && api != Opcodes.ASM5 &&
api != Opcodes.ASM4) {
throw new IllegalArgumentException("Unsupported api " + api);
}
this.api = api;
this.cv = classVisitor;
}
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: 3rc2 regression?
My pleasure. This should be a JVM 8 bug, which is triggered by groovy 3.0.0 rc-2. Maybe we have to submit the bug to OpenJDK team ;-) 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: 3rc2 regression?
I tried to add `-Xverify:none` to groovy test build. As the result shows, Oracle JDK 1.8.0_151 seems to work: https://travis-ci.org/danielsun1106/groovy/jobs/624550691 This could be the only workaround for the JVM bug so far... 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: 3rc2 regression?
https://github.com/danielsun1106/groovy/runs/347173227 JRE version: OpenJDK Runtime Environment (Zulu 8.42.0.23-CA-linux64) (8.0_232-b18) (build 1.8.0_232-b18) crashed too... 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: 3rc2 regression?
Here is the error log: hs_err_pid21040.log <http://groovy.329449.n5.nabble.com/file/t340716/hs_err_pid21040.log> 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: 3rc2 regression?
I tried zulu JDK 1.8.0_232, JVM crashed too... I think you find a bug of JVM
;-)
P.S. the code runs well if no `-Xverify:none` applied.
D:\_TEMP\>java -version
openjdk version "1.8.0_232"
OpenJDK Runtime Environment (Zulu 8.42.0.23-CA-win64) (build 1.8.0_232-b18)
OpenJDK 64-Bit Server VM (Zulu 8.42.0.23-CA-win64) (build 25.232-b18, mixed
mode)
D:\_TEMP\>java -Xverify:none -jar
D:\_DEV\Groovy\groovy\lib\groovy-3.0.0-rc-2.jar -e="new File('.').toPath()"
=== DEBUG MESSAGE: unimplemented bytecode
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_PRIV_INSTRUCTION (0xc096) at pc=0x034d5776,
pid=21040, tid=0x24cc
#
# JRE version: OpenJDK Runtime Environment (Zulu 8.42.0.23-CA-win64)
(8.0_232-b18) (build 1.8.0_232-b18)
# Java VM: OpenJDK 64-Bit Server VM (25.232-b18 mixed mode windows-amd64
compressed oops)
# Problematic frame:
# j org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.()V+0
#
# Failed to write core dump. Minidumps are not enabled by default on client
versions of Windows
#
# An error report file with more information is saved as:
# D:\_TEMP\\hs_err_pid21040.log
#
# If you would like to submit a bug report, please visit:
# http://www.azulsystems.com/support/
#
D:\_TEMP\>
D:\_TEMP\>
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: 3rc2 regression?
I tried my local JDK 1.8.0_222(Corretto) with your code, JVM crashed.. Let me
download zulu JDK 1.8 and have a try...
hs_err_pid19328.log
<http://groovy.329449.n5.nabble.com/file/t340716/hs_err_pid19328.log>
D:\_TEMP\>groovy -v
Groovy Version: 3.0.0-rc-2 JVM: 1.8.0_222 Vendor: Amazon.com Inc. OS:
Windows 10
D:\_TEMP\>java -Xverify:none -jar
D:\_DEV\Groovy\groovy\lib\groovy-3.0.0-rc-2.jar -e="println new
File('.').toPath()"
=== DEBUG MESSAGE: illegal bytecode sequence - method not
verified
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_PRIV_INSTRUCTION (0xc096) at pc=0x032056ed,
pid=19328, tid=0x57d4
#
# JRE version: OpenJDK Runtime Environment (8.0_222-b10) (build
1.8.0_222-b10)
# Java VM: OpenJDK 64-Bit Server VM (25.222-b10 mixed mode windows-amd64
compressed oops)
# Problematic frame:
# j
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.()V+-1034620128
#
# Failed to write core dump. Minidumps are not enabled by default on client
versions of Windows
#
# An error report file with more information is saved as:
# D:\_TEMP\\hs_err_pid19328.log
#
# If you would like to submit a bug report, please visit:
#
#
D:\_TEMP\>
D:\_TEMP\qqqq>
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: 3rc2 regression?
Let me have a try ;-) 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: 3rc2 regression?
I can not reproduce the issue through your code( No error occurred as follows
)...
```
D:\_TEMP\>groovy -v
Groovy Version: 3.0.0-rc-2 JVM: 11.0.3 Vendor: Amazon.com Inc. OS: Windows
10
D:\_TEMP\>java -Xverify:none -jar
D:\_DEV\Groovy\groovy\lib\groovy-3.0.0-rc-2.jar -e="new File('.').toPath()"
D:\_TEMP\>
D:\_TEMP\qqqq>
```
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: 3rc2 regression?
> the jvm uses -Xverify:none (for jruby/asciidoctor), this lead to the issue That says, if `-Xverify:none` is removed, the issue is gone? 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: 3rc2 regression?
Also, `ArrayIndexOutOfBoundsException` should be able to be caught by the
try-catch block and ignored, but it is thrown as your stack trace shown...
It's hard to address the issue by looking into the error log...
```
try {
return (CallSite) constr.newInstance(site, metaClass,
this, params, constr);
} catch (Error e) {
skipCompiled=true;
throw e;
} catch (Throwable e) {
skipCompiled=true;
}
```
(
https://github.com/apache/groovy/blob/GROOVY_3_0_0_RC_2/src/main/java/org/codehaus/groovy/reflection/CachedMethod.java#L295-L302
)
Caused by: java.lang.ArrayIndexOutOfBoundsException: -844304512
at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.
(PojoMetaMethodSite.java)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0 (Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance
(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance (Constructor.java:423)
at org.codehaus.groovy.reflection.CachedMethod.createPojoMetaMethodSite
(CachedMethod.java:296)
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: 3rc2 regression?
I find a static field in PojoMetaMethodSite class, it will be initialized in "", but no subscript operation found either... https://github.com/apache/groovy/blob/GROOVY_3_0_0_RC_2/src/main/java/org/codehaus/groovy/runtime/callsite/PojoMetaMethodSite.java#L40 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: 3rc2 regression?
Hi Romain,
Could you provide us a standalone runnable code sample?
BTW, I find the root cause is `ArrayIndexOutOfBoundsException` thrown
in `PojoMetaMethodSite.`, but it is weird that no `static { ... }`
in the `PojoMetaMethodSite` source code (
)https://github.com/apache/groovy/blob/GROOVY_3_0_0_RC_2/src/main/java/org/codehaus/groovy/runtime/callsite/PojoMetaMethodSite.java
Caused by: java.lang.ArrayIndexOutOfBoundsException: -844304512
at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.
(PojoMetaMethodSite.java)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0 (Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance
(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance (Constructor.java:423)
at org.codehaus.groovy.reflection.CachedMethod.createPojoMetaMethodSite
(CachedMethod.java:296)
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.createCachedMethodSite
(PojoMetaMethodSite.java:162)
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.createPojoMetaMethodSite
(PojoMetaMethodSite.java:151)
at groovy.lang.MetaClassImpl.createPojoCallSite
(MetaClassImpl.java:3476)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.createPojoSite
(CallSiteArray.java:123)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallSite
(CallSiteArray.java:160)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall
(CallSiteArray.java:47)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call
(AbstractCallSite.java:115)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call
(AbstractCallSite.java:119)
at
org.talend.sdk.component.build.documentation.sample.Bundles$_run_closure1.doCall
(Bundles.groovy:100)
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: [ANNOUNCE] Apache Groovy 3.0.0-rc-2 released
Nice work, Paul :-) 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 multiplication
Hi Edmond, How about 86400G * 1000 * 30 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 3.0.0-rc-2
groovySh and groovyConsole run well, my smoke tests pass too. +1 (binding) 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
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
Re: Upcoming releases
Here is the PR "GROOVY-9262: Bump asm to 7.2": https://github.com/apache/groovy/pull/1081 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: Upcoming releases
Hi Jochen, > 2.5 is on ASM 7.1, newest version is 7.2? I think that kind of update is > still a possibility. Paul? Daniel? Yep :-) > Considering GROOVY-9271 I wonder > actually we did not go to 7.2 right away for 2.4... Upgrading to 7.X from 6.X is a big change. Frankly I am not sure if breaking changes will be introduced. 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: [DRAFT] Apache Groovy Board Report for November (reporting on Aug/Sep/Oct)
LGTM :-) 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] Support switch expression in the next version
More concise syntax should be feasible too(statement in parentheses), e.g.
```
def a = 6
def r = (
switch (a) {
case 6: yield 'a'
default: yield 'b'
}
)
assert 'a' == r
```
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] Support switch expression in the next version
Hi Jochen,
> Do we really? If we really want to support it, we should support its
> use-case, which is a Lexer. Writing an efficient lexer in Groovy would
> be way off with switch expressions, because of the transformation to
> Closure and the overhead it involves.
To be frank, I'm not sure if we really want to support it. I think Groovy
should be groovy, but Groovy has to be keep compatibility with Java...
I think Groovy should be able to do better, and it can transform all
statements to expressions, e.g.
1) switch-case
```
def a = 6
def r = #(
switch (a) {
case 6: yield 'a'
default: yield 'b'
}
)
assert 'a' == r
```
2) if-else
```
def a = 6
def r = #(
if (a == 6)
yield 'a'
else
yield 'b'
)
assert 'a' == r
```
3) for
```
def r = #(
for (int i = 0; i < 2; i++) {
if (1 == i) yield i
}
)
assert 1 == r
```
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-dev-site
Nice work, Paul :-) 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] Support switch expression in the next version
Hi Rémi, Thanks for your detailed explaining. Switch expression is useful in some cases, but fallthrough is error prone. I seldom use switch statement, in the past, I widely used it when I wrote lexer/parser by hand. I prefer to use if-else instead, which is much more powerful. Though devil exists in some shapes of switch expression, Groovy may have to support all shapes for compatibility with Java. I am thinking about a general proposal for Groovy. The common way to transform statement to expression with parenthesis expression following `#`, e.g. ``` def a = 6 def r = #( if (a == 6) yield 'a' else yield 'b' ) assert 'a' == r ``` 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] Support switch expression in the next version
It does not matter. Different people have different concerns. Maybe we could do better if time allowed: https://blog.joda.org/2019/11/java-switch-4-wrongs-dont-make-right.html > and Happy Birthday from me, whenever the exact date is G-) Thank you, MG :-) 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] Support switch expression in the next version
This is just a reference implementation, we can tweak it over time. > Now that you have a prototype in hand for conversion to ClosureExpression > with nested SwitchStatement, would it be a good idea to at least try the > SwitchExpression route to see how much effort difference is involved? As Cédric said, he wanted to implement a lot of features but had no time. I can feel that he really likes Groovy. Frankly, same to me, I'm not sure if I have enough time to tweak it in the near future... In order to push the progress of Groovy 3, I sleep for 3~4 hours a day recently... It's 3:30 a.m. in Shanghai... Please call me super man ;-) And the reason why I set aside extra time on features of Groovy 3.X / Groovy 4 is that my birthday is coming, I try to make a "gift" for myself. If you like it too, that's great. If not, it does not matter, I'll keep 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: [VOTE] Support switch expression in the next version
Fix typo: 2nd transformed code in the parser to eliminate the shared variables before instruction selection phase -> 2nd transformed code to eliminate the shared variables before instruction selection phase 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] Support switch expression in the next version
I have 2 ideas in my mind:
1) Implement switch expression from scratch, in other words, we need parse
code into a brand new`SwitchExpression` in AST, then implement flowing type
because we have static groovy, at last generate bytecode. -- need quite a
few work, but it should be able to very close to Java's implementation,
better compatibility.
2) Transform the switch expression to reuse current AST nodes, as a result,
we can reuse almost all backend. -- can not ensure 100% compatibility with
Java's switch expression, but need much less work, and the implementation
should be robust because it is based on mature backend used for years.
We have to trade off pros and crons. For me, I choose the option 2. As for
the potential side effect you mentioned, I think we can transform again in a
later phase if necessary:
The original code:
```
def a = 6
def r = switch (a) {
case 6, 8 -> 'x'
case 9 -> 'y'
default -> 'z'
}
assert 'x' == r
```
1st transformed code in the parser:
```
def a = 6
def r = {->
def result = null
switch (a) {
case 6:
case 8: result = 'x'; break;
case 9: result = 'y'; break;
default: result = 'z'; break;
}
return result
}()
assert 'x' == r
```
2nd transformed code in the parser to eliminate the shared variables before
instruction selection phase:
```
def a = 6
def r = { paramA ->
def result = null
switch (paramA) {
case 6:
case 8: result = 'x'; break;
case 9: result = 'y'; break;
default: result = 'z'; break;
}
return result
}(a)
assert 'x' == r
```
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] Support switch expression in the next version
You know code block is not an expression. The reason to transform switch
expression to switch statement in closure is make switch expression appear
everywhere, e.g.
```
def process(String s) { "Hello, $s" }
def a = 6
def r = process(
switch (a) {
case 6 -> 'a'
default -> 'b'
}
)
assert 'Hello, a' == r
```
P.S. Java's text block looks smarter, but I still like Groovy's raw text
block. When we want to get same result of Java's text block, just call
`groovyText.stripIndent()`, which I think it's more flexible. ( My 2 cents )
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
[VOTE] Support switch expression in the next version
Hi all,
Though Java's switch expression is still in preview phase, Groovy has
followed up its steps in my labs project:
https://github.com/danielsun1106/groovy-parser/tree/switch-expression
As you can see, switch expressions can be parsed and executed. For some edge
cases, We may polish the implementation further.
The rationale is to transform switch expression to switch statement in
closure, e.g.
The original code:
```
def a = 6
def r = switch (a) {
case 6, 8 -> 'x'
case 9 -> 'y'
default -> 'z'
}
assert 'x' == r
```
The transformed code:
```
def a = 6
def r = {->
def result = null
switch (a) {
case 6:
case 8: result = 'x'; break;
case 9: result = 'y'; break;
default: result = 'z'; break;
}
return result
}()
assert 'x' == r
```
Groovy always provides extra friendly features, which cover switch
expression absolutely ;-)
For example:
```
def a = 6
def r = switch (a) {
case 6, 8 : {
// in Java, error occurs as no `yield` found.
// But in Groovy, you can think it as an optional `yield`, which is
a bit similar to optional 'return' in methods
'x'
}
case 9 -> 'y' // `case ... :`(colon) and `case ... ->`(arrow) can
be mixed as you need
default -> 'z'
}
assert 'x' == r
```
Please vote on supporting switch expression in the next version, e.g. Groovy
3.1.0
The vote is open for the next 72 hours and passes if a majority of at least
three +1 PMC votes are cast.
[ ] +1 Support switch expression in the next version
[ ] 0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not support switch expression because...
Here is my vote:
+1 (binding)
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: [apache/groovy] GROOVY-9296: [GEP] Import `TypeChecked`, `CompileStatic` and `Compile… (#1056)
Hi all, I've given up the proposal. Maybe slowing down the steps and fixing existing bugs can please most of users and devs. 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: [apache/groovy] GROOVY-9296: [GEP] Import `TypeChecked`, `CompileStatic` and `Compile… (#1056)
Hi Guillaume, The proposal is to use `@TypeChecked`, `@CompileStatic` and `@CompileDynamic` conveniently. Though we can enable STC via config script or flags, the solutions can not 100% cover the use cases of the proposal. Anyway, no worries. It's just a proposal. If the proposal can not get +1 PMC votes, the feature will not be added to 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: [GEP] Import `TypeChecked`, `CompileStatic` and `CompileDynamic` by default
Hi Guillaume, Here is the idea in my mind, i.e. we can configure the CompilerConfiguration instance to add default imports ;-) ``` def config = new CompilerConfiguration() def imports = new ImportCustomizer() imports.addImports( 'groovy.transform.TypeChecked', 'groovy.transform.CompileStatic', 'groovy.transform.CompileDynamic' ) config.addCompilationCustomizers(imports) ``` 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: [GEP] Import `TypeChecked`, `CompileStatic` and `CompileDynamic` by default
Hi mg, Groovy 3 is already in RC phase, so its features are frozen. New features are targeted to next version. 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
[GEP] Import `TypeChecked`, `CompileStatic` and `CompileDynamic` by default
Hi all,
As static groovy is widely used, importing
`groovy.transform.TypeChecked`, `groovy.transform.CompileStatic` and
`groovy.transform.CompileDynamic` again and again makes user experience not
very good. So I propose to import the classes by default. For example,
After GEP accepted:
```
@CompileStatic
def hello {
println 'hello'
}
```
Before GEP accepted:
```
import groovy.transform.CompileStatic
@CompileStatic
def hello {
println 'hello'
}
```
The target version of the GEP is Groovy 4. Any thoughts?
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: [ANNOUNCE] Apache Groovy 3.0.0-rc-1 released
Nice work, Paul :-) 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 3.0.0-rc-1 (take 2)
We create antlr4 plugin factory via the following code in `Antlr4Util`:
Antlr4PluginFactory antlr4PluginFactory = (Antlr4PluginFactory)
ParserPluginFactory.antlr4(configuration);
The `antlr4` method is `static`, its implementation is to `new
Antlr4PluginFactory` instance, and the method can not be overrided by
`ParserPluginFactory` subclasses.
public static ParserPluginFactory antlr4(CompilerConfiguration
compilerConfiguration) {
return new Antlr4PluginFactory(compilerConfiguration);
}
So I wonder how to reproduce the `java.lang.ClassCastException`...
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 3.0.0-rc-1 (take 2)
The `static` method `antlr4` only creates `Antlr4PluginFactory` instance, so
I wonder how to make it create
`org.codehaus.groovy.control.ParserPluginFactory$1` instance?
public abstract class ParserPluginFactory {
/**
* creates the ANTLR 4 parser
* @return the factory for the parser
*/
public static ParserPluginFactory antlr4(CompilerConfiguration
compilerConfiguration) {
return new Antlr4PluginFactory(compilerConfiguration);
}
...
}
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
