Re: Gradle build updates

[Daniel.Sun]

Amazing! The build of master costs only about 15 min now(about 25 min in the
past).

Cédric, you help us save a lot of time, thanks a lot!

Cheers,
Daniel.Sun



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

Re: Building Groovy

[MG]

Just came across this as an example where using Groovy 2.4.6 
invokedynamic seems to have been much slower than the older callsite 
caching mechanism: 
https://www.linkedin.com/pulse/how-make-groovy-fast-java-david-e-jones 
(https://dzone.com/articles/how-to-make-groovy-as-fast-as-java)


Quote:
"While Groovy has performance options that allow you to keep your code 
dynamically typed I never had good results with them. For Moqui 
Framework using the Indy compiler and runtime (for Java invokedynamic) 
actually made it significantly slower!
The best option for code that needs to run fast is the @CompileStatic 
annotation. When you apply this annotation you can't use Groovy features 
that depend on dynamic typing, but fortunately most of the more useful 
features still work just fine."


I can totally understand the pull to get rid of large, old code parts - 
but if this holds for more projects, I expect it will not go down well 
with (dynamic) Groovy users...

mg


On 21.11.2017 17:38, Jochen Theodorou wrote:



Am 21.11.2017 um 08:28 schrieb Paul King:
The "double" build is because of indy vs non-indy (one wipes out the 
other) because of some assumptions that keep other parts of the build 
simple. Could no doubt be streamlined given some TLC.


Last I checked there were different performance characteristics 
between indy/non-indy. We haven't gotten around to working out the 
best path forward yet that will give us one set of jars without 
losing performance in some scenarios. Again, just needs some time 
dedicated to it.


I don't see the old callsite caching still working properly in a Java9 
world, so it is time to cut loose


bye Jochen

Re: Extension method upgrades

[Jochen Theodorou]

On 17.12.2017 23:23, Nathan Harvey wrote:
[...]

I am not familiar with the concept of static categories, can you explain the
difference between that and extension methods? I think we should clear up
the terminology.


the idea is basically to have what we have now for extension methods and 
categories, but reduce the scope to a lexical one. And for this there 
have been two ways thought of, where one way is something like an static 
import of the category methods (so there would be an import statement 
for them basically) and the other way is to change the use-command to be 
able to maximally reduce the scope. Of course this means there will be 
no service required. Thus it would not cause the problem you have imho.



My main focus with this post is removing the step of isolating extension
methods to a separate dependency, as this creates numerous problems. One
large one I haven't mentioned yet is the inability to test the methods
within the same project as they are declared, for example. Anyway there are
obviously a number of ways to achieve this.


Would you be fine with a class level annotation?

bye Jochen

Re: Package specific syntax

[Daniil Ovchinnikov]

I’d love `@PackageScope` to be removed (or deprecated) in favor of `package` 
keyword. In this case I woudn’t have to scan for it.

—

Daniil Ovchinnikov
JetBrains
jetbrains.com
“Drive to develop”

> On 15 Dec 2017, at 16:36, mg  wrote:
> 
> Hi Daniil,
> 
> thank you for explaining that, as most devs with regards to IDEs I am a user 
> and have little insight in the challenges of its inner workings.
> 
> I have never had the need to use @PackageScope, but the problem I see is that 
> the annotation (in typical Groovy style), can do more than a keyword, due to 
> it supporting parameters to restrict its applicability to e.g. class fields 
> only - so I guess you would have to scan for @PackageScope in any case...
> 
> Cheers,
> mg
> 
> 
>  Ursprüngliche Nachricht 
> Von: Daniil Ovchinnikov 
> Datum: 15.12.17 14:13 (GMT+01:00)
> An: MG 
> Betreff: Re: Package specific syntax
> 
> Each annotation requires resolution, which slows the IDE. With a keyword we 
> can get visibility of members instantly, for example for showing appropriate 
> icon in Project View.
> 
> We need to resolve _all_ annotations and check if there are annotation 
> collectors just to find that given member doesn’t have @PackageScope. 
> At this point all we need to know is whether containing class of a given 
> member has @PackageScope, and we start to resolve all annotations of a class 
> and so on.
> 
> —
> 
> Daniil Ovchinnikov
> JetBrains
> jetbrains.com 
> “Drive to develop”
> 
>> On 14 Dec 2017, at 04:11, MG > > wrote:
>> 
>> Why is a keyword better than an annotation from an IDE developer's 
>> perspective (considering Groovy already has tons of annotations which more 
>> complex semantics than @PackageScope) ?
>> 
>> 
>> On 13.12.2017 23:14, Daniil Ovchinnikov wrote:
>>> This is the best way from IDE perspective.
>>> 
>>> —
>>> 
>>> Daniil Ovchinnikov
>>> JetBrains
>>> jetbrains.com 
>>> “Drive to develop"
>>> 
 On 14 Dec 2017, at 01:03, Nathan Harvey >>> > wrote:
 
 In Java,  methods and fields use package scope by default. In Groovy, they
 use public. In order to make something package scope, you have to use the
 @PackageScope annotation. This makes code look a bit messy but also doesn't
 seem very intuitive. What if the "package" keyword was able to be applied,
 in exactly the same way as "public" and "private" are? 
 
 Example:
 package void foo() {}
 
 
 
 --
 Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html 
 
>>> 
>> 
> 

Re: Extension method upgrades

[Nathan Harvey]

I think Groovy's extension methods are not more clean than Kotlin's. Having
to isolate them to an external dependency helps consolidate them, I suppose,
but that doesn't change much for readability within usages - you still have
to Ctrl+Click or similar to find out where a method originates. 

I am not familiar with the concept of static categories, can you explain the
difference between that and extension methods? I think we should clear up
the terminology.

My main focus with this post is removing the step of isolating extension
methods to a separate dependency, as this creates numerous problems. One
large one I haven't mentioned yet is the inability to test the methods
within the same project as they are declared, for example. Anyway there are
obviously a number of ways to achieve this.



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

Re: Gradle build updates

[Cédric Champeau]

Alright folks, I have completed most of what I wanted to do. The
performance of the build is now much better. I have backported everything
to the 2.5 and 2.6 branches, and also updated CI.

> So is it still possible to produce the groovy-all.jar and
groovy-all-sources.jar from the SDK zip?

The "all" sources is still produced. But there's no all jar anymore.

2017-12-13 17:53 GMT+01:00 :

> So is it still possible to produce the groovy-all.jar and
> groovy-all-sources.jar from the SDK zip?
>