Re: What the... static compile by default

[MG]

Hi Daniel,

On 12.05.2018 15:51, Daniel.Sun wrote:

Hi mg,

   I am trying to reduce the time on smart phone and computer to relax
eyes :)


That sounds like a good idea :-)
(Have you already tried reducing the blue component on every display ? I 
do that with every monitor - at first the image looks yellow 
tinted/dark, but our brain adjusts to this quite quickly and yellow 
becomes white (unless the brain has something to compare it too ;-) )



As for Groovy, I plan to support raw string[1] introduced by Java11
since no similar thing in Groovy.


Definitely a good feature for Groovy to have, imho :-)


Some days ago I discussed it with
Guillaume, and I will start a VOTE thread to collect three +1 from PMC
members before working on the new feature. In addition, I am going to fix
STC issues and improve type infer,


That sounds great.
Don't know where we are discussion-wise on this topic, but maybe it 
would make sense that I work on var/final actually having the assigned 
RHS type in parallel to you (as time allows)... - thoughts (apart from 
"flow typing gives you the same thing", for which I believe I have 
already given examples showing that it is not ;-) ) ?



some of which are really hard to fix...
no wonder they have not been fixed for a long time. Apart from STC, I am
going to implement native method/constructor reference for better
performance(as you know, current method/constructor reference is based on
method closure).


Don't know what Paul/Jochen think about this, but I would like to have 
that :-)



Many things on my TODO list... After all of the thing are completed, I want
to add a new DSL(something similar to LINQ in C#) to Groovy, it can be a
subproject of Groovy or just my personal project...


My vote for Subproject of Groovy - it would definitely make Groovy even 
more attractive (I admit I am happy with functional type method 
chaining, I mostly used Linq under C# for group-by operations, but I 
know many people love it), and it has a bigger chance of drawing in 
other interested developers :-)
I am not sure, but from my experience, maybe we could do things a 
differently from the way C# does them, and (optionally?) keep more of 
the Linq representation, instead of completely turning it into an AST 
representation ? I remember that it was a hard problem (see re-linq 
project) to turn that AST representation back into e.g. SQL - which 
seemed silly, since Linq is modelled after SQL, and is therefore very 
similar syntax-wise...


Cheers,
mg

Re: What the... static compile by default

[Russel Winder]

On Sat, 2018-05-12 at 06:08 -0700, Daniel.Sun wrote:
> Hi Russel, 
> 
>  Yep. Eye drops can relieve my pain. It have to take a bit long time to
> recover...
> 

Good that the drops deal with the pain.

Relax as much as possible to make the recovery time as short as possible.
 
-- 
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


signature.asc
Description: This is a digitally signed message part

Re: What the... static compile by default

[Daniel.Sun]

My pleasure :-)

Cheers,
Daniel.Sun




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

Re: What the... static compile by default

[Jeff Scott Brown]

On 12 May 2018, at 0:57, Daniel.Sun wrote:

> Hi all,
>
>   Thanks for your kind words. As the commit log shows, I'm back and
> trying to fix some STC issues after having a rest.

This is very good news indeed.

Thank you for your contributions!



JSB
--
Jeff Scott Brown
OCI Partner and Principal Software Engineer
OCI Grails Practice Lead

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

Re: What the... static compile by default

[Daniel.Sun]

Hi mg,

  I am trying to reduce the time on smart phone and computer to relax
eyes :)

  As for Groovy, I plan to support raw string[1] introduced by Java11
since no similar thing in Groovy. Some days ago I discussed it with
Guillaume, and I will start a VOTE thread to collect three +1 from PMC
members before working on the new feature. In addition, I am going to fix
STC issues and improve type infer, some of which are really hard to fix...
no wonder they have not been fixed for a long time. Apart from STC, I am
going to implement native method/constructor reference for better
performance(as you know, current method/constructor reference is based on
method closure). 
Many things on my TODO list... After all of the thing are completed, I want
to add a new DSL(something similar to LINQ in C#) to Groovy, it can be a
subproject of Groovy or just my personal project...

Cheers,
Daniel.Sun
[1] http://openjdk.java.net/jeps/326




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

Re: What the... static compile by default

[Daniel.Sun]

Hi Russel, 

 Yep. Eye drops can relieve my pain. It have to take a bit long time to
recover...

Cheers,
Daniel.Sun



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

Re: What the... static compile by default

[Russel Winder]

On Fri, 2018-05-11 at 22:57 -0700, Daniel.Sun wrote:
[…]
> 
>   P.S. Recently I'm suffering from conjunctivitis...
> 
Daniel,

Hopefully medics have given you something to relieve the itching and pain, and
that it clears up quickly.

-- 
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


signature.asc
Description: This is a digitally signed message part

Re: What the... static compile by default

[Jochen Theodorou]

On 11.05.2018 20:34, Sven Reimers wrote:

Hi all,

Apache NetBeans is already using gitbox ... works very well for us.


is there any page where I can see what it offers without setting it up? 
The link given in this thread here so far is not suitable.


bye Jochen

Re: What the... static compile by default

[Daniel.Sun]

Yep. merging request is annoying and will cost us more time if conflicts
exist.

Cheers,
Daniel.Sun




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

Re: What the... static compile by default

[Daniel.Sun]

Hi all,

  Thanks for your kind words. As the commit log shows, I'm back and
trying to fix some STC issues after having a rest.

  P.S. Recently I'm suffering from conjunctivitis...

Cheers,
Daniel.Sun



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

Re: What the... static compile by default

[Sven Reimers]

Hi all,

Apache NetBeans is already using gitbox ... works very well for us.

Sven

Remko Popma  schrieb am Fr., 11. Mai 2018, 18:06:

> https://gitbox.apache.org/setup/
>
> On Sat, May 12, 2018 at 12:59 AM, Mario Garcia 
> wrote:
>
>> Remko Could you add a link to Gitbox ?
>>
>> El vie., 11 may. 2018 a las 17:52, Remko Popma ()
>> escribió:
>>
>>> Over at Log4j we just decided to migrate from git-wip-us to gitbox
>>> 
>>> .
>>>
>>> Using gitbox will allow our projects to integrate better with GitHub
 including the ability to merge PRs directly from the site and the ability
 to push commits to GitHub and have them be automatically mirrored back to
 Apache.
>>>
>>>
>>> This may be interesting for Groovy also.
>>> We haven't made the move yet so I can't give you feedback from
>>> first-hand experience.
>>>
>>> Remko
>>>
>>>
>>> On Sat, May 12, 2018 at 12:32 AM, Mario Garcia 
>>> wrote:
>>>
 *About Static Compilation changes:*

 I've used the way it's documented in the official documentation, and I
 agree with Cedric, I don't like having a system property. I see more
 benefits using the compiler configuration file:

- Configuration is more fine grained (apply to all, apply to some
classes, apply to some packages...)
- All compilation configuration can be found in one place. Having
more than one place to do this could be error prone, and harder to 
 maintain.
- System properties are normally used when the process should vary
depending on the environment. In this case, I'm wondering why I would 
 want
to compile my code statically in one environment but dynamically in
another. Maybe there is a case for that, but to me is weird.

 *About Daniel response:*

 I'm so sad to hear that Daniel. In the past few years I've been hearing
 only amazing things coming from your contributions.  Like someone has
 mentioned, Groovy 3 wouldn't be the same without you. I really hope you
 could reconsider your decision and keep contributing to Groovy.

 *About doing commits on master:*

 Reading the "Contributing code" section, at groovy-lang.org it seems
 everybody should be creating a local branch and to a MR afterwards over the
 remote version of that local branch. So  (again, reading the
 documentation)  nobody should be adding commits to master directly.

 I think merge requests are essential. I'm reading Jochen is saying that
 this is not very straight forward with Github. Could anyone please explain
 why ? Knowing the pains may help finding the solution.

 My two cents
 Mario

 El vie., 11 may. 2018 3:42, Thibault Kruse 
 escribió:

> It seems a bit weird to leave this thread dangling after the dramatic
> entry scene.
>
> The activity on master branch seems to indicate some changes were
> decided:
>
> danielsun1106 committed 2 days ago : Revert "GROOVY-8543: Support
> setting compileStatic by default via sys…
> danielsun1106 committed 18 hours ago : GROOVY-7204: Static type
> checking and compilation fail when multiple …
> danielsun1106 committed 14 hours ago : Simplify finding generics
> implementation class
>
> However, the meta-concern by Cedric was not addressed it seems. Why is
> anyone directly working on the master branch of groovy?
> Is there a technical reason for this, rather than using feature
> branches, code reviews, and merge approvals?
> Or is it just that nobody would have time to review in a timely
> fashion anyway, so it's either that or zero progress?
>
>
> On Tue, May 8, 2018 at 7:43 AM, MG  wrote:
> > On 07.05.2018 17:54, Cédric Champeau wrote:
> >>
> >> I'd typically very much prefer a custom file extension for example.
> >
> >
> > That would be my preferred way to give anyone a simple mean to
> choose static
> > compilation as the default for a Groovy file. Afair the counter
> argument
> > was, that Groovy compiles any file with any extension in dynamic
> mode by
> > default, so this might be a breaking change if someone has used the
> picked
> > extension for his files. Groovy 3.0 might be the right spot to
> introduce
> > something like this, since there will be breaking changes anyway...
> >
> >> That said, since I'm not contributing code anymore (my last
> contribution
> >> was rewriting most of the build, which I hope was helpful),
> >
> >
> > Any improvement/speedup of the Gradle build was _definitely_
> appreciated :-)
> >
> >> 

Re: What the... static compile by default

[Remko Popma]

https://gitbox.apache.org/setup/

On Sat, May 12, 2018 at 12:59 AM, Mario Garcia  wrote:

> Remko Could you add a link to Gitbox ?
>
> El vie., 11 may. 2018 a las 17:52, Remko Popma ()
> escribió:
>
>> Over at Log4j we just decided to migrate from git-wip-us to gitbox
>> 
>> .
>>
>> Using gitbox will allow our projects to integrate better with GitHub
>>> including the ability to merge PRs directly from the site and the ability
>>> to push commits to GitHub and have them be automatically mirrored back to
>>> Apache.
>>
>>
>> This may be interesting for Groovy also.
>> We haven't made the move yet so I can't give you feedback from
>> first-hand experience.
>>
>> Remko
>>
>>
>> On Sat, May 12, 2018 at 12:32 AM, Mario Garcia 
>> wrote:
>>
>>> *About Static Compilation changes:*
>>>
>>> I've used the way it's documented in the official documentation, and I
>>> agree with Cedric, I don't like having a system property. I see more
>>> benefits using the compiler configuration file:
>>>
>>>- Configuration is more fine grained (apply to all, apply to some
>>>classes, apply to some packages...)
>>>- All compilation configuration can be found in one place. Having
>>>more than one place to do this could be error prone, and harder to 
>>> maintain.
>>>- System properties are normally used when the process should vary
>>>depending on the environment. In this case, I'm wondering why I would 
>>> want
>>>to compile my code statically in one environment but dynamically in
>>>another. Maybe there is a case for that, but to me is weird.
>>>
>>> *About Daniel response:*
>>>
>>> I'm so sad to hear that Daniel. In the past few years I've been hearing
>>> only amazing things coming from your contributions.  Like someone has
>>> mentioned, Groovy 3 wouldn't be the same without you. I really hope you
>>> could reconsider your decision and keep contributing to Groovy.
>>>
>>> *About doing commits on master:*
>>>
>>> Reading the "Contributing code" section, at groovy-lang.org it seems
>>> everybody should be creating a local branch and to a MR afterwards over the
>>> remote version of that local branch. So  (again, reading the
>>> documentation)  nobody should be adding commits to master directly.
>>>
>>> I think merge requests are essential. I'm reading Jochen is saying that
>>> this is not very straight forward with Github. Could anyone please explain
>>> why ? Knowing the pains may help finding the solution.
>>>
>>> My two cents
>>> Mario
>>>
>>> El vie., 11 may. 2018 3:42, Thibault Kruse 
>>> escribió:
>>>
 It seems a bit weird to leave this thread dangling after the dramatic
 entry scene.

 The activity on master branch seems to indicate some changes were
 decided:

 danielsun1106 committed 2 days ago : Revert "GROOVY-8543: Support
 setting compileStatic by default via sys…
 danielsun1106 committed 18 hours ago : GROOVY-7204: Static type
 checking and compilation fail when multiple …
 danielsun1106 committed 14 hours ago : Simplify finding generics
 implementation class

 However, the meta-concern by Cedric was not addressed it seems. Why is
 anyone directly working on the master branch of groovy?
 Is there a technical reason for this, rather than using feature
 branches, code reviews, and merge approvals?
 Or is it just that nobody would have time to review in a timely
 fashion anyway, so it's either that or zero progress?


 On Tue, May 8, 2018 at 7:43 AM, MG  wrote:
 > On 07.05.2018 17:54, Cédric Champeau wrote:
 >>
 >> I'd typically very much prefer a custom file extension for example.
 >
 >
 > That would be my preferred way to give anyone a simple mean to choose
 static
 > compilation as the default for a Groovy file. Afair the counter
 argument
 > was, that Groovy compiles any file with any extension in dynamic mode
 by
 > default, so this might be a breaking change if someone has used the
 picked
 > extension for his files. Groovy 3.0 might be the right spot to
 introduce
 > something like this, since there will be breaking changes anyway...
 >
 >> That said, since I'm not contributing code anymore (my last
 contribution
 >> was rewriting most of the build, which I hope was helpful),
 >
 >
 > Any improvement/speedup of the Gradle build was _definitely_
 appreciated :-)
 >
 >> I'm happy to step down and let you work as you wish.
 >
 >
 > This is tricky: One cannot agree with just any direction someone who
 invests
 > the time to advance Groovy wants to take it too, that would be taking
 > Doocracy too far, imho, and might lead 

Re: What the... static compile by default

[Mario Garcia]

Remko Could you add a link to Gitbox ?

El vie., 11 may. 2018 a las 17:52, Remko Popma ()
escribió:

> Over at Log4j we just decided to migrate from git-wip-us to gitbox
> 
> .
>
> Using gitbox will allow our projects to integrate better with GitHub
>> including the ability to merge PRs directly from the site and the ability
>> to push commits to GitHub and have them be automatically mirrored back to
>> Apache.
>
>
> This may be interesting for Groovy also.
> We haven't made the move yet so I can't give you feedback from first-hand
> experience.
>
> Remko
>
>
> On Sat, May 12, 2018 at 12:32 AM, Mario Garcia 
> wrote:
>
>> *About Static Compilation changes:*
>>
>> I've used the way it's documented in the official documentation, and I
>> agree with Cedric, I don't like having a system property. I see more
>> benefits using the compiler configuration file:
>>
>>- Configuration is more fine grained (apply to all, apply to some
>>classes, apply to some packages...)
>>- All compilation configuration can be found in one place. Having
>>more than one place to do this could be error prone, and harder to 
>> maintain.
>>- System properties are normally used when the process should vary
>>depending on the environment. In this case, I'm wondering why I would want
>>to compile my code statically in one environment but dynamically in
>>another. Maybe there is a case for that, but to me is weird.
>>
>> *About Daniel response:*
>>
>> I'm so sad to hear that Daniel. In the past few years I've been hearing
>> only amazing things coming from your contributions.  Like someone has
>> mentioned, Groovy 3 wouldn't be the same without you. I really hope you
>> could reconsider your decision and keep contributing to Groovy.
>>
>> *About doing commits on master:*
>>
>> Reading the "Contributing code" section, at groovy-lang.org it seems
>> everybody should be creating a local branch and to a MR afterwards over the
>> remote version of that local branch. So  (again, reading the
>> documentation)  nobody should be adding commits to master directly.
>>
>> I think merge requests are essential. I'm reading Jochen is saying that
>> this is not very straight forward with Github. Could anyone please explain
>> why ? Knowing the pains may help finding the solution.
>>
>> My two cents
>> Mario
>>
>> El vie., 11 may. 2018 3:42, Thibault Kruse 
>> escribió:
>>
>>> It seems a bit weird to leave this thread dangling after the dramatic
>>> entry scene.
>>>
>>> The activity on master branch seems to indicate some changes were
>>> decided:
>>>
>>> danielsun1106 committed 2 days ago : Revert "GROOVY-8543: Support
>>> setting compileStatic by default via sys…
>>> danielsun1106 committed 18 hours ago : GROOVY-7204: Static type
>>> checking and compilation fail when multiple …
>>> danielsun1106 committed 14 hours ago : Simplify finding generics
>>> implementation class
>>>
>>> However, the meta-concern by Cedric was not addressed it seems. Why is
>>> anyone directly working on the master branch of groovy?
>>> Is there a technical reason for this, rather than using feature
>>> branches, code reviews, and merge approvals?
>>> Or is it just that nobody would have time to review in a timely
>>> fashion anyway, so it's either that or zero progress?
>>>
>>>
>>> On Tue, May 8, 2018 at 7:43 AM, MG  wrote:
>>> > On 07.05.2018 17:54, Cédric Champeau wrote:
>>> >>
>>> >> I'd typically very much prefer a custom file extension for example.
>>> >
>>> >
>>> > That would be my preferred way to give anyone a simple mean to choose
>>> static
>>> > compilation as the default for a Groovy file. Afair the counter
>>> argument
>>> > was, that Groovy compiles any file with any extension in dynamic mode
>>> by
>>> > default, so this might be a breaking change if someone has used the
>>> picked
>>> > extension for his files. Groovy 3.0 might be the right spot to
>>> introduce
>>> > something like this, since there will be breaking changes anyway...
>>> >
>>> >> That said, since I'm not contributing code anymore (my last
>>> contribution
>>> >> was rewriting most of the build, which I hope was helpful),
>>> >
>>> >
>>> > Any improvement/speedup of the Gradle build was _definitely_
>>> appreciated :-)
>>> >
>>> >> I'm happy to step down and let you work as you wish.
>>> >
>>> >
>>> > This is tricky: One cannot agree with just any direction someone who
>>> invests
>>> > the time to advance Groovy wants to take it too, that would be taking
>>> > Doocracy too far, imho, and might lead to a Groovy which is much worse
>>> than
>>> > it could be.
>>> > In this particular case I am torn: I think we could definitely live
>>> with the
>>> > system property, I don't feel there is a large probability that it will
>>> > break 

Re: What the... static compile by default

[Remko Popma]

Over at Log4j we just decided to migrate from git-wip-us to gitbox

.

Using gitbox will allow our projects to integrate better with GitHub
> including the ability to merge PRs directly from the site and the ability
> to push commits to GitHub and have them be automatically mirrored back to
> Apache.


This may be interesting for Groovy also.
We haven't made the move yet so I can't give you feedback from first-hand
experience.

Remko


On Sat, May 12, 2018 at 12:32 AM, Mario Garcia  wrote:

> *About Static Compilation changes:*
>
> I've used the way it's documented in the official documentation, and I
> agree with Cedric, I don't like having a system property. I see more
> benefits using the compiler configuration file:
>
>- Configuration is more fine grained (apply to all, apply to some
>classes, apply to some packages...)
>- All compilation configuration can be found in one place. Having more
>than one place to do this could be error prone, and harder to maintain.
>- System properties are normally used when the process should vary
>depending on the environment. In this case, I'm wondering why I would want
>to compile my code statically in one environment but dynamically in
>another. Maybe there is a case for that, but to me is weird.
>
> *About Daniel response:*
>
> I'm so sad to hear that Daniel. In the past few years I've been hearing
> only amazing things coming from your contributions.  Like someone has
> mentioned, Groovy 3 wouldn't be the same without you. I really hope you
> could reconsider your decision and keep contributing to Groovy.
>
> *About doing commits on master:*
>
> Reading the "Contributing code" section, at groovy-lang.org it seems
> everybody should be creating a local branch and to a MR afterwards over the
> remote version of that local branch. So  (again, reading the
> documentation)  nobody should be adding commits to master directly.
>
> I think merge requests are essential. I'm reading Jochen is saying that
> this is not very straight forward with Github. Could anyone please explain
> why ? Knowing the pains may help finding the solution.
>
> My two cents
> Mario
>
> El vie., 11 may. 2018 3:42, Thibault Kruse 
> escribió:
>
>> It seems a bit weird to leave this thread dangling after the dramatic
>> entry scene.
>>
>> The activity on master branch seems to indicate some changes were decided:
>>
>> danielsun1106 committed 2 days ago : Revert "GROOVY-8543: Support
>> setting compileStatic by default via sys…
>> danielsun1106 committed 18 hours ago : GROOVY-7204: Static type
>> checking and compilation fail when multiple …
>> danielsun1106 committed 14 hours ago : Simplify finding generics
>> implementation class
>>
>> However, the meta-concern by Cedric was not addressed it seems. Why is
>> anyone directly working on the master branch of groovy?
>> Is there a technical reason for this, rather than using feature
>> branches, code reviews, and merge approvals?
>> Or is it just that nobody would have time to review in a timely
>> fashion anyway, so it's either that or zero progress?
>>
>>
>> On Tue, May 8, 2018 at 7:43 AM, MG  wrote:
>> > On 07.05.2018 17:54, Cédric Champeau wrote:
>> >>
>> >> I'd typically very much prefer a custom file extension for example.
>> >
>> >
>> > That would be my preferred way to give anyone a simple mean to choose
>> static
>> > compilation as the default for a Groovy file. Afair the counter argument
>> > was, that Groovy compiles any file with any extension in dynamic mode by
>> > default, so this might be a breaking change if someone has used the
>> picked
>> > extension for his files. Groovy 3.0 might be the right spot to introduce
>> > something like this, since there will be breaking changes anyway...
>> >
>> >> That said, since I'm not contributing code anymore (my last
>> contribution
>> >> was rewriting most of the build, which I hope was helpful),
>> >
>> >
>> > Any improvement/speedup of the Gradle build was _definitely_
>> appreciated :-)
>> >
>> >> I'm happy to step down and let you work as you wish.
>> >
>> >
>> > This is tricky: One cannot agree with just any direction someone who
>> invests
>> > the time to advance Groovy wants to take it too, that would be taking
>> > Doocracy too far, imho, and might lead to a Groovy which is much worse
>> than
>> > it could be.
>> > In this particular case I am torn: I think we could definitely live
>> with the
>> > system property, I don't feel there is a large probability that it will
>> > break anything. On the other hand, using the existing mechanism, or
>> > introducing a static compilation source file extension, or a compiler
>> switch
>> > seem to me to be the better choices - but maybe Daniel can explain why
>> he
>> > went with the property approach ?-)

Re: What the... static compile by default

[Mario Garcia]

*About Static Compilation changes:*

I've used the way it's documented in the official documentation, and I
agree with Cedric, I don't like having a system property. I see more
benefits using the compiler configuration file:

   - Configuration is more fine grained (apply to all, apply to some
   classes, apply to some packages...)
   - All compilation configuration can be found in one place. Having more
   than one place to do this could be error prone, and harder to maintain.
   - System properties are normally used when the process should vary
   depending on the environment. In this case, I'm wondering why I would want
   to compile my code statically in one environment but dynamically in
   another. Maybe there is a case for that, but to me is weird.

*About Daniel response:*

I'm so sad to hear that Daniel. In the past few years I've been hearing
only amazing things coming from your contributions.  Like someone has
mentioned, Groovy 3 wouldn't be the same without you. I really hope you
could reconsider your decision and keep contributing to Groovy.

*About doing commits on master:*

Reading the "Contributing code" section, at groovy-lang.org it seems
everybody should be creating a local branch and to a MR afterwards over the
remote version of that local branch. So  (again, reading the
documentation)  nobody should be adding commits to master directly.

I think merge requests are essential. I'm reading Jochen is saying that
this is not very straight forward with Github. Could anyone please explain
why ? Knowing the pains may help finding the solution.

My two cents
Mario

El vie., 11 may. 2018 3:42, Thibault Kruse 
escribió:

> It seems a bit weird to leave this thread dangling after the dramatic
> entry scene.
>
> The activity on master branch seems to indicate some changes were decided:
>
> danielsun1106 committed 2 days ago : Revert "GROOVY-8543: Support
> setting compileStatic by default via sys…
> danielsun1106 committed 18 hours ago : GROOVY-7204: Static type
> checking and compilation fail when multiple …
> danielsun1106 committed 14 hours ago : Simplify finding generics
> implementation class
>
> However, the meta-concern by Cedric was not addressed it seems. Why is
> anyone directly working on the master branch of groovy?
> Is there a technical reason for this, rather than using feature
> branches, code reviews, and merge approvals?
> Or is it just that nobody would have time to review in a timely
> fashion anyway, so it's either that or zero progress?
>
>
> On Tue, May 8, 2018 at 7:43 AM, MG  wrote:
> > On 07.05.2018 17:54, Cédric Champeau wrote:
> >>
> >> I'd typically very much prefer a custom file extension for example.
> >
> >
> > That would be my preferred way to give anyone a simple mean to choose
> static
> > compilation as the default for a Groovy file. Afair the counter argument
> > was, that Groovy compiles any file with any extension in dynamic mode by
> > default, so this might be a breaking change if someone has used the
> picked
> > extension for his files. Groovy 3.0 might be the right spot to introduce
> > something like this, since there will be breaking changes anyway...
> >
> >> That said, since I'm not contributing code anymore (my last contribution
> >> was rewriting most of the build, which I hope was helpful),
> >
> >
> > Any improvement/speedup of the Gradle build was _definitely_ appreciated
> :-)
> >
> >> I'm happy to step down and let you work as you wish.
> >
> >
> > This is tricky: One cannot agree with just any direction someone who
> invests
> > the time to advance Groovy wants to take it too, that would be taking
> > Doocracy too far, imho, and might lead to a Groovy which is much worse
> than
> > it could be.
> > In this particular case I am torn: I think we could definitely live with
> the
> > system property, I don't feel there is a large probability that it will
> > break anything. On the other hand, using the existing mechanism, or
> > introducing a static compilation source file extension, or a compiler
> switch
> > seem to me to be the better choices - but maybe Daniel can explain why he
> > went with the property approach ?-)
> >
> > Cheers,
> > mg
> >
> >
> >
>

Re: What the... static compile by default

[Jochen Theodorou]

Am 11.05.2018 um 03:42 schrieb Thibault Kruse:
[...]

However, the meta-concern by Cedric was not addressed it seems. Why is
anyone directly working on the master branch of groovy?
Is there a technical reason for this, rather than using feature
branches, code reviews, and merge approvals?


working with merge requests is actually tedious in the apache world, 
since you cannot simply merge on github. If we want that kind of 
workflow we should do this through a gerrit at apache. I don't think we 
have a gitlab there.



Or is it just that nobody would have time to review in a timely
fashion anyway, so it's either that or zero progress?


no in a timely fashion imho, especially if the merge request is 
something complicated.


bye Jochen

Re: What the... static compile by default

[Thibault Kruse]

It seems a bit weird to leave this thread dangling after the dramatic
entry scene.

The activity on master branch seems to indicate some changes were decided:

danielsun1106 committed 2 days ago : Revert "GROOVY-8543: Support
setting compileStatic by default via sys…
danielsun1106 committed 18 hours ago : GROOVY-7204: Static type
checking and compilation fail when multiple …
danielsun1106 committed 14 hours ago : Simplify finding generics
implementation class

However, the meta-concern by Cedric was not addressed it seems. Why is
anyone directly working on the master branch of groovy?
Is there a technical reason for this, rather than using feature
branches, code reviews, and merge approvals?
Or is it just that nobody would have time to review in a timely
fashion anyway, so it's either that or zero progress?


On Tue, May 8, 2018 at 7:43 AM, MG  wrote:
> On 07.05.2018 17:54, Cédric Champeau wrote:
>>
>> I'd typically very much prefer a custom file extension for example.
>
>
> That would be my preferred way to give anyone a simple mean to choose static
> compilation as the default for a Groovy file. Afair the counter argument
> was, that Groovy compiles any file with any extension in dynamic mode by
> default, so this might be a breaking change if someone has used the picked
> extension for his files. Groovy 3.0 might be the right spot to introduce
> something like this, since there will be breaking changes anyway...
>
>> That said, since I'm not contributing code anymore (my last contribution
>> was rewriting most of the build, which I hope was helpful),
>
>
> Any improvement/speedup of the Gradle build was _definitely_ appreciated :-)
>
>> I'm happy to step down and let you work as you wish.
>
>
> This is tricky: One cannot agree with just any direction someone who invests
> the time to advance Groovy wants to take it too, that would be taking
> Doocracy too far, imho, and might lead to a Groovy which is much worse than
> it could be.
> In this particular case I am torn: I think we could definitely live with the
> system property, I don't feel there is a large probability that it will
> break anything. On the other hand, using the existing mechanism, or
> introducing a static compilation source file extension, or a compiler switch
> seem to me to be the better choices - but maybe Daniel can explain why he
> went with the property approach ?-)
>
> Cheers,
> mg
>
>
>

Re: What the... static compile by default

[MG]

On 07.05.2018 17:54, Cédric Champeau wrote:

I'd typically very much prefer a custom file extension for example.


That would be my preferred way to give anyone a simple mean to choose 
static compilation as the default for a Groovy file. Afair the counter 
argument was, that Groovy compiles any file with any extension in 
dynamic mode by default, so this might be a breaking change if someone 
has used the picked extension for his files. Groovy 3.0 might be the 
right spot to introduce something like this, since there will be 
breaking changes anyway...


That said, since I'm not contributing code anymore (my last 
contribution was rewriting most of the build, which I hope was helpful),


Any improvement/speedup of the Gradle build was _definitely_ appreciated :-)


I'm happy to step down and let you work as you wish.


This is tricky: One cannot agree with just any direction someone who 
invests the time to advance Groovy wants to take it too, that would be 
taking Doocracy too far, imho, and might lead to a Groovy which is much 
worse than it could be.
In this particular case I am torn: I think we could definitely live with 
the system property, I don't feel there is a large probability that it 
will break anything. On the other hand, using the existing mechanism, or 
introducing a static compilation source file extension, or a compiler 
switch seem to me to be the better choices - but maybe Daniel can 
explain why he went with the property approach ?-)


Cheers,
mg

Re: What the... static compile by default

[Paul King]

Hi Daniel,

I am very keen for you to maintain your involvement in Groovy. There is no
way we'd have Groovy 3 in it's current form without your involvement. I
also find your enthusiasm contagious and a welcome addition to the
community.

Cheers, Paul.

>> On 2018/05/07 14:59:09, "Daniel.Sun"  wrote:
> >>>
> >>> Hi Cédric,
> >>>
> >>>   Feel free to remove any code.
> >>>   To be honest, I am really tired.
> >>>   Bye Groovy community.
> >>>
> >>> Cheers,
> >>> Daniel.Sun
>

Re: What the... static compile by default

[Graeme Rocher]

Hi Cedric,

I don't think anybody wants anybody to step down (whether that be you,
Daniel or whoever) and you make valid points about processes that
could be improved. I would however encourage you to re-read your
original email to understand how it may impact others. Maybe adjust
the tone of your emails since this is not the first email of that
nature. Starting off being the bad cop and usage of phrases like "when
the heck" it came across as aggressive and I can understand why Daniel
and possibly others would feel discouraged. I know however your
intention is good and maybe it is a language thing. We all want the
best for Groovy at the end of the day.

Cheers

On Mon, May 7, 2018 at 5:54 PM, Cédric Champeau
 wrote:
> Hi Daniel and sorry you are "tired". Maybe the tone I used was
> inappropriate?, but it wasn't directed at you personally. I'm quite
> surprised to see some things like that happening on master without any
> discussion on the MLs. Maybe that's because I expect too much from the
> developers of Groovy, but I strongly think we owe better to the community,
> and in particular code quality. In that area, we don't have _any_ peer
> review. Everybody works on master, and I think that's a bad idea. Things
> like this happen, but we have to realize that Groovy is used by tens of
> thousands of developers, so any choice we make has consequences. So, if we
> had peer reviews, questions like this wouldn't happen. Should you want to
> introduce a feature, it wouldn't go to master without a review from another
> committer/PMC. Same for Paul, and same for me. I think it's too easy to push
> to master today, and this bites us.
>
> So to come back to the original topic of this thread, I never saw that
> ticket, and, for one, don't read every ticket out there, I mostly have time
> to follow discussions on the MLs. So I can react when I see something that
> looks wrong to me. Here, I don't have the impression that the ticket even
> comes to any conclusion, it just "happened". I still think the approach is
> incorrect, I'd typically very much prefer a custom file extension for
> example. And if it's just for internal testing, the compiler configuration
> already has everything we need without having to rely on a system property.
> We have to realize that adding a property without testing it in combination
> with other flags is a problem too.
>
> That said, since I'm not contributing code anymore (my last contribution was
> rewriting most of the build, which I hope was helpful), I'm happy to step
> down and let you work as you wish. I mostly want to make sure Groovy goes in
> the right direction. If I'm a blocker, I have no problem with that.
>
> 2018-05-07 17:40 GMT+02:00 Jeff Scott Brown :
>>
>>
>>
>> On 2018/05/07 14:59:09, "Daniel.Sun"  wrote:
>>>
>>> Hi Cédric,
>>>
>>>   Feel free to remove any code.
>>>   To be honest, I am really tired.
>>>   Bye Groovy community.
>>>
>>> Cheers,
>>> Daniel.Sun
>>>
>> }
>>
>> Daniel,
>>
>> Please reconsider.  I think the tone at the beginning of this thread was
>> unfortunate and I expect that has contributed to your frustration.
>>
>> Your contributions are very much appreciated by the community and you
>> should be proud of the work you are doing with Groovy.  It would be a real
>> shame to lose your enthusiasm and contributions to this great language and
>> great ecosystem.  I mean that sincerely.
>>
>> Let me know whatever I can do to help.
>>
>> Thanks for all of your great work.  Well done sir!
>>
>>
>>
>>
>> JSB
>> --
>> Jeff Scott Brown
>> OCI Partner and Principal Software Engineer
>> OCI Grails Practice Lead
>>
>> Autism Strikes 1 in 166
>> Find The Cause ~ Find The Cure
>> http://www.autismspeaks.org/
>
>



-- 
Graeme Rocher

Re: What the... static compile by default

[mg]

Hi Daniel,
is that a quote of someone who has left the project at some point or you 
yourself talking ? If it is you: I get your frustation and - don't go :-)
Technically, would a "compile static" compiler switch be a compromise, or has 
this alteady been ruled out (if the switch had the lowest priority, it should 
not collide with all the existing ways to apply @CompileStatic to Groovy code) ?
Cheers,mg
 Ursprüngliche Nachricht Von: "Daniel.Sun" <sun...@apache.org> 
Datum: 07.05.18  16:59  (GMT+01:00) An: d...@groovy.incubator.apache.org 
Betreff: Re: What the... static compile by default 
Hi Cédric,

  Feel free to remove any code.
  To be honest, I am really tired. 
  Bye Groovy community.

Cheers,
Daniel.Sun




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

Re: What the... static compile by default

[mg]

Hi Daniel,
is that a quote of someone who has left the project at some point or you 
yourself talking ? If it is you: I get your frustation and - don't go :-)
Technically, would a "compile static" compiler switch be a compromise, or has 
this alteady been ruled out (if the switch had the lowest priority, it should 
not collide with all the existing ways to apply @CompileStatic to Groovy code) ?
Cheers,mg
 Ursprüngliche Nachricht Von: "Daniel.Sun" <sun...@apache.org> 
Datum: 07.05.18  16:59  (GMT+01:00) An: d...@groovy.incubator.apache.org 
Betreff: Re: What the... static compile by default 
Hi Cédric,

  Feel free to remove any code.
  To be honest, I am really tired. 
  Bye Groovy community.

Cheers,
Daniel.Sun




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

Re: What the... static compile by default

[Sergio del Amo Caballero]

Daniel, please note your contribution to Groovy has not gone without
notice. Personally, I am very grateful for the work you have done.
Moreover, I am grateful for the enthusiasm towards twitter you have shown
in every email and tweet. It has been awesome and contagious.  I hope you
stay in the Groovy Community because without any doubt you make it better.

Sergio del Amo

On 7 May 2018 at 16:59, Daniel.Sun  wrote:

> Hi Cédric,
>
>   Feel free to remove any code.
>   To be honest, I am really tired.
>   Bye Groovy community.
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>



-- 
Sergio del Amo Caballero
http://softamo.com
http://sergiodelamo.es
http://www.sergiodelamo.com
Sigueme en twitter: http://twitter.com/sdelamo
Hazte fan en facebook: http://www.facebook.com/sergiodelamocaballero
email: sergio.del...@softamo.com
Tfno: +34 949 31 48 86 / +34 630442973

Re: What the... static compile by default

[Cédric Champeau]

Hi Daniel and sorry you are "tired". Maybe the tone I used was
inappropriate?, but it wasn't directed at you personally. I'm quite
surprised to see some things like that happening on master without any
discussion on the MLs. Maybe that's because I expect too much from the
developers of Groovy, but I strongly think we owe better to the community,
and in particular code quality. In that area, we don't have _any_ peer
review. Everybody works on master, and I think that's a bad idea. Things
like this happen, but we have to realize that Groovy is used by tens of
thousands of developers, so any choice we make has consequences. So, if we
had peer reviews, questions like this wouldn't happen. Should you want to
introduce a feature, it wouldn't go to master without a review from another
committer/PMC. Same for Paul, and same for me. I think it's too easy to
push to master today, and this bites us.

So to come back to the original topic of this thread, I never saw that
ticket, and, for one, don't read every ticket out there, I mostly have time
to follow discussions on the MLs. So I can react when I see something that
looks wrong to me. Here, I don't have the impression that the ticket even
comes to any conclusion, it just "happened". I still think the approach is
incorrect, I'd typically very much prefer a custom file extension for
example. And if it's just for internal testing, the compiler configuration
already has everything we need without having to rely on a system property.
We have to realize that adding a property without testing it in combination
with other flags is a problem too.

That said, since I'm not contributing code anymore (my last contribution
was rewriting most of the build, which I hope was helpful), I'm happy to
step down and let you work as you wish. I mostly want to make sure Groovy
goes in the right direction. If I'm a blocker, I have no problem with that.

2018-05-07 17:40 GMT+02:00 Jeff Scott Brown :

>
>
> On 2018/05/07 14:59:09, "Daniel.Sun"  wrote:
>
>> Hi Cédric,
>>
>>   Feel free to remove any code.
>>   To be honest, I am really tired.
>>   Bye Groovy community.
>>
>> Cheers,
>> Daniel.Sun
>>
>> }
>
> Daniel,
>
> Please reconsider.  I think the tone at the beginning of this thread was
> unfortunate and I expect that has contributed to your frustration.
>
> Your contributions are very much appreciated by the community and you
> should be proud of the work you are doing with Groovy.  It would be a real
> shame to lose your enthusiasm and contributions to this great language and
> great ecosystem.  I mean that sincerely.
>
> Let me know whatever I can do to help.
>
> Thanks for all of your great work.  Well done sir!
>
>
>
>
> JSB
> --
> Jeff Scott Brown
> OCI Partner and Principal Software Engineer
> OCI Grails Practice Lead
>
> Autism Strikes 1 in 166
> Find The Cause ~ Find The Cure
> http://www.autismspeaks.org/
>

Re: What the... static compile by default

[Jeff Scott Brown]

On 2018/05/07 14:59:09, "Daniel.Sun"  wrote:

Hi Cédric,

  Feel free to remove any code.
  To be honest, I am really tired.
  Bye Groovy community.

Cheers,
Daniel.Sun


}

Daniel,

Please reconsider.  I think the tone at the beginning of this thread was 
unfortunate and I expect that has contributed to your frustration.


Your contributions are very much appreciated by the community and you 
should be proud of the work you are doing with Groovy.  It would be a 
real shame to lose your enthusiasm and contributions to this great 
language and great ecosystem.  I mean that sincerely.


Let me know whatever I can do to help.

Thanks for all of your great work.  Well done sir!




JSB
--
Jeff Scott Brown
OCI Partner and Principal Software Engineer
OCI Grails Practice Lead

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

Re: What the... static compile by default

[Graeme Rocher]

I hope you don't get discouraged Daniel, you are doing amazing work in
the community and currently you and Paul are the main contributors /
drivers of the project.

Cerdic - whilst I am sure you mean well I gotta say I disagree with
your approach to raising issues on the mailing list. There was already
a JIRA comments thread on the issue (GROOVY-8543) debating the value
of the system property and it would likely have been removed without
all this fuss, what is the point of openly discouraging folks who are
actually making a contribution to Groovy?

My 2 cents.


On Mon, May 7, 2018 at 4:59 PM, Daniel.Sun  wrote:
> Hi Cédric,
>
>   Feel free to remove any code.
>   To be honest, I am really tired.
>   Bye Groovy community.
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html



-- 
Graeme Rocher

Re: What the... static compile by default

[Daniel.Sun]

Hi Cédric,

  Feel free to remove any code.
  To be honest, I am really tired. 
  Bye Groovy community.

Cheers,
Daniel.Sun




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

Re: What the... static compile by default

[Thibault Kruse]

Git blame seems to indicate April 13th 2018, and it seems to be
related to this ticket:
https://issues.apache.org/jira/browse/GROOVY-8543

On Mon, May 7, 2018 at 11:05 PM, Cédric Champeau
 wrote:
> Hi folks,
>
> Sorry to be the bad cop again, but when the heck did this land into core:
>
> https://github.com/apache/groovy/blob/5443e87882f9b88169876f6d043ed54b5ae9023b/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L943-L988
>
> As much as I love static compilation, this should never have landed into
> master, at least not without an agreement. I strongly believe enabling
> static compilation by default using a system property is a bad thing. We
> already have an official, supported mechanism for this, which is documented
> [1], so adding one silently is not very nice. I reckon lots of users want to
> have static compilation by default, but I don't think a system property is
> the way to go.
>
> [1]
> http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default