Re: Gradle build updates
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
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
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: Extension method upgrades
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
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? >