Re: About the Phoenix plan for Groovy

2018-04-08 Thread Jochen Theodorou
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

Re: About the Phoenix plan for Groovy

2018-04-08 Thread Daniel.Sun
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 Thread mg
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

2018-04-08 Thread mg
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

2018-04-08 Thread Daniel Sun
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

Re: Determining the registered DGM classes at runtime

2018-04-08 Thread Cédric Champeau
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

Re: About the Phoenix plan for Groovy

2018-04-08 Thread Jochen Theodorou
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

Re: About the Phoenix plan for Groovy

2018-04-08 Thread Cédric Champeau
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

Re: About the Phoenix plan for Groovy

2018-04-08 Thread MG
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

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

2018-04-08 Thread MG
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

Re: About the Phoenix plan for Groovy

2018-04-08 Thread Cédric Champeau
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

Re: About the Phoenix plan for Groovy

2018-04-08 Thread 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 code as Groovy code and tried to compile with STC,

Re: Determining the registered DGM classes at runtime

2018-04-08 Thread Jochen Theodorou
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

Re: About the Phoenix plan for Groovy

2018-04-08 Thread Cédric Champeau
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, >

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

2018-04-08 Thread Paul King
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