[jira] [Commented] (GROOVY-4606) Exteremely bad performance of .unique() and .unique {closure}
[
https://issues.apache.org/jira/browse/GROOVY-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16299379#comment-16299379
]
Jochen Theodorou commented on GROOVY-4606:
--
The problem with the HashMap idea is, that it works only if equals and hashcode
are defined accordingly. That is not the case in general. For example for
double 0 and BigDecimal 0 being equal in the Groovy sense, but not for a
HashMap.
I guess a better solution would be to have a second, faster unique method, that
does not take coercing into account.
> Exteremely bad performance of .unique() and .unique {closure}
> -
>
> Key: GROOVY-4606
> URL: https://issues.apache.org/jira/browse/GROOVY-4606
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 1.7.5
>Reporter: Maxym Mykhalchuk
> Attachments: UniqueMath.java
>
>
> DefaultGroovyMethods.unique has two inner loops, so its complexity is O(n^2)
> Practically it means that it starts taking ages on collections with 1000 or
> more elements.
> Simply adding elements to a linked hash set would get O(n*log n) performance.
> Will develop my own unique implementation after New Year, and will attach it
> here
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (GROOVY-8421) checkstyle build cleanup
[
https://issues.apache.org/jira/browse/GROOVY-8421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-8421:
--
Labels: contrib (was: )
> checkstyle build cleanup
>
>
> Key: GROOVY-8421
> URL: https://issues.apache.org/jira/browse/GROOVY-8421
> Project: Groovy
> Issue Type: Task
>Reporter: Paul King
>Priority: Minor
> Labels: contrib
>
> For subprojects not containing Java sources, i.e. Groovy only we get warnings
> like:
> {noformat}
> > Task :groovy-groovysh:checkstyleMainReport
> A problem was found with the configuration of task
> ':groovy-groovysh:checkstyleMainReport'. Registering invalid inputs and
> outputs via TaskInputs and TaskOutputs methods has been deprecated and is
> scheduled to be removed in Gradle 5.0.
> - File
> 'C:\Projects\groovy\subprojects\groovy-groovysh\target\reports\checkstyle\checkstyleMain.xml'
> specified for property '$2' does not exist.
> {noformat}
> We should add an appropriate guard or not apply plugin for this case.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GROOVY-8421) checkstyle build cleanup
Paul King created GROOVY-8421:
-
Summary: checkstyle build cleanup
Key: GROOVY-8421
URL: https://issues.apache.org/jira/browse/GROOVY-8421
Project: Groovy
Issue Type: Task
Reporter: Paul King
Priority: Minor
For subprojects not containing Java sources, i.e. Groovy only we get warnings
like:
{noformat}
> Task :groovy-groovysh:checkstyleMainReport
A problem was found with the configuration of task
':groovy-groovysh:checkstyleMainReport'. Registering invalid inputs and outputs
via TaskInputs and TaskOutputs methods has been deprecated and is scheduled to
be removed in Gradle 5.0.
- File
'C:\Projects\groovy\subprojects\groovy-groovysh\target\reports\checkstyle\checkstyleMain.xml'
specified for property '$2' does not exist.
{noformat}
We should add an appropriate guard or not apply plugin for this case.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-4606) Exteremely bad performance of .unique() and .unique {closure}
[
https://issues.apache.org/jira/browse/GROOVY-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16299021#comment-16299021
]
Gareth Harcombe-Minson commented on GROOVY-4606:
Is this still an issue in 2.4.7?
> Exteremely bad performance of .unique() and .unique {closure}
> -
>
> Key: GROOVY-4606
> URL: https://issues.apache.org/jira/browse/GROOVY-4606
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 1.7.5
>Reporter: Maxym Mykhalchuk
> Attachments: UniqueMath.java
>
>
> DefaultGroovyMethods.unique has two inner loops, so its complexity is O(n^2)
> Practically it means that it starts taking ages on collections with 1000 or
> more elements.
> Simply adding elements to a linked hash set would get O(n*log n) performance.
> Will develop my own unique implementation after New Year, and will attach it
> here
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] groovy pull request #:
Github user danielsun1106 commented on the pull request: https://github.com/apache/groovy/commit/c89393104807cc49859f77ab86c62ab3c7e171e8#commitcomment-26387619 I reverted the commit on my fork, the build costs about 12 min https://travis-ci.org/danielsun1106/groovy/builds/319083265?utm_source=github_status_medium=notification ---
[jira] [Updated] (GROOVY-8420) @TypeChecked in 2.4.13 produces incorrect compiler error
[
https://issues.apache.org/jira/browse/GROOVY-8420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Dick updated GROOVY-8420:
Summary: @TypeChecked in 2.4.13 produces incorrect compiler error (was:
2.4.13)
> @TypeChecked in 2.4.13 produces incorrect compiler error
>
>
> Key: GROOVY-8420
> URL: https://issues.apache.org/jira/browse/GROOVY-8420
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.4.13
> Environment: Windows 10, Java 8 Update 152, IntelliJ IDEA Build
> #IC-173.4127.2
>Reporter: Steven Dick
>
> After upgrading to Groovy 2.4.13, the following code no longer compiles in
> Intellij:
> {code:java}
> @TypeChecked
> public class EnhancedDerivedNonUnitisedPrice {
> ...
> public @Nullable BigDecimal getReturnPerc() {
> return null;
> }
> ...
> {code}
> The error is, "Cannot return 'null' from method returning BigDecimal".
> Either removing the {{@TypeChecked}} or adding a cast to {{BigDecimal}}
> resolves the problem.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
