Re: About the Phoenix plan for Groovy

On 08.04.2018 03:58, Daniel Sun wrote: Hi all, I have a plan named "Phoenix" to share. As we all know, STC is buggy, one of reasons is that STC lacks tests during development. So I make a plan to let STC mature enough: 1) Make the Parrot parser be able to parse pure Java source to Groovy

Re: About the Phoenix plan for Groovy

Hi Jochen, > To me this means: to be able to compile like Java, you have to be > able > to turn flow typing off. Thanks for your reminding :-) > You really want > to go with bit-by-bit equality? I do not care about how to generating same bytecode as Java's but I want the sam

Re: About the Phoenix plan for Groovy

It seems Daniel has a point here: Knowing the whole landscape of bugs in the static compiler cannot be a bad thing in itself, right ? And it might prohibit fixing one bug reported by a Groovy user through a quick fix, when it is actually part of a bigger problem. I would however keep bugs found

Re: About the Phoenix plan for Groovy

It seems Daniel has a point here: Knowing the whole landscape of bugs in the static compiler cannot be a bad thing in itself, right ? And it might prohibit fixing one bug reported by a Groovy user through a quick fix, when it is actually part of a bigger problem. I would however keep bugs found

Re: About the Phoenix plan for Groovy

Hi mg, I just do not like the feeling that we walk in an endless road ;-) The Phoenix plan will be a long road, but we can see the end of it. I will enhance the Parrot parser to support Java grammar as a dialect at first, a journey of a thousand miles begins with single step :-)

Re: About the Phoenix plan for Groovy

2018-04-08 3:58 GMT+02:00 Daniel Sun : > Hi all, > > I have a plan named "Phoenix" to share. As we all know, STC is buggy, > one of reasons is that STC lacks tests during development. It's interesting you put test coverage as one reason that the STC is buggy, but the only reason you mentio

Re: Determining the registered DGM classes at runtime

2018-04-06 22:42 GMT+02:00 Jochen Theodorou : > ah sorry, I was not explaining right... > > I was going to suggest something similar to what you probably already have > found, which is StaticTypeCheckingSupport.EXTE > NSION_METHOD_CACHE.getExtensionMethods(ClassLoader) > but for some reason I do n

Re: About the Phoenix plan for Groovy

Hi Cédric, At first we all admit your effort on STC is great :-) I usually try to use STC for better performance, but sadly I have to turn to dynamic mode sometimes. Recently I wrote a hadoop example in Java, then copied the Java code as Groovy code and tried to compile with STC,

Re: Determining the registered DGM classes at runtime

On 08.04.2018 18:51, Cédric Champeau wrote: 2018-04-06 22:42 GMT+02:00 Jochen Theodorou >: ah sorry, I was not explaining right... I was going to suggest something similar to what you probably already have found, which is StaticTypeCheckingSupport.EXTE

Re: About the Phoenix plan for Groovy

2018-04-08 19:31 GMT+02:00 Daniel.Sun : > Hi Cédric, > >At first we all admit your effort on STC is great :-) > >I usually try to use STC for better performance, but sadly I have to > turn to dynamic mode sometimes. Recently I wrote a hadoop example in Java, > then copied the Java

Re: About the Phoenix plan for Groovy

On 08.04.2018 20:46, Cédric Champeau wrote: [...] Honestly I don't have much time to work on Groovy. And if I had, the generics STC bugs would be the last thing I'd like to get my hands into. The ClassNode infrastructure was retrofitted to introduce generics back in 1.5, but since it was for dy

Re: About the Phoenix plan for Groovy

I'm not sure how the API would look like either, but clearly the "reflection approach" is not enough since it better represents runtime types than compile time types. Just getting the relationships between the things is hard to get today. We probably need something better for synthetic union/inters

@Newify(classNamePattern=/[A-Z].*/) - Questions

I am working on an implementation of @Newify classNamePattern support, which should allow Groovy to optionally support object creation (ctor calls) without the need for the "new" keyword on a global level, as in Python or Kotlin (https://issues.apache.org/jira/browse/GROOVY-8490) without negati

Re: About the Phoenix plan for Groovy

Hi Daniel, On 08.04.2018 16:32, Daniel.Sun wrote: Hi mg, I just do not like the feeling that we walk in an endless road ;-) I totally get that, I feel the same way. I would also like to take the opportunity to thank you for your continuing efforts and upbeat attitude :-) The P

[RESULT][VOTE] Release Apache Groovy 2.5.0-rc-1

Thanks everyone. The vote has passed with 3 binding +1 votes and two additional +1 votes. I'll proceed with next steps. Cheers, Paul. On Sun, Apr 8, 2018 at 1:31 AM, John Wagenleitner < john.wagenleit...@gmail.com> wrote: > +1 (binding) > > > On Thu, Apr 5, 2018, 9:14 AM Paul King wrote: > >> >

[ANNOUNCE] Apache Groovy 2.5.0-rc-1 released

Dear community, The Apache Groovy team is pleased to announce version 2.5.0-rc-1 of Apache Groovy. Apache Groovy is a multi-faceted programming language for the JVM. Further details can be found at the http://groovy.apache.org website. This is a pre-release of a new version of Groovy. We greatly