[GitHub] groovy pull request #388: Calculating hashcode of IntRange by pairing functi...
Github user upadhyayap commented on a diff in the pull request:
https://github.com/apache/groovy/pull/388#discussion_r75509146
--- Diff: src/main/groovy/lang/IntRange.java ---
@@ -415,4 +415,14 @@ public void step(int step, Closure closure) {
step(step, adapter);
return adapter.asList();
}
+
+@Override
+public int hashCode(){
+int hashCode;
+final int from = this.getFrom();
+final int to = this.getTo();
+
+hashCode = new Integer(((from+to+1)*(from+to))/2).intValue()+to;
--- End diff --
Changed and committed.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] groovy pull request #388: Calculating hashcode of IntRange by pairing functi...
Github user upadhyayap commented on a diff in the pull request:
https://github.com/apache/groovy/pull/388#discussion_r75508864
--- Diff: src/main/groovy/lang/IntRange.java ---
@@ -415,4 +415,14 @@ public void step(int step, Closure closure) {
step(step, adapter);
return adapter.asList();
}
+
+@Override
+public int hashCode(){
+int hashCode;
+final int from = this.getFrom();
+final int to = this.getTo();
+
+hashCode = new Integer(((from+to+1)*(from+to))/2).intValue()+to;
--- End diff --
Correct because hashCode is already an int.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] groovy pull request #388: Calculating hashcode of IntRange by pairing functi...
Github user jwagenleitner commented on a diff in the pull request:
https://github.com/apache/groovy/pull/388#discussion_r75499884
--- Diff: src/main/groovy/lang/IntRange.java ---
@@ -415,4 +415,14 @@ public void step(int step, Closure closure) {
step(step, adapter);
return adapter.asList();
}
+
+@Override
+public int hashCode(){
+int hashCode;
+final int from = this.getFrom();
+final int to = this.getTo();
+
+hashCode = new Integer(((from+to+1)*(from+to))/2).intValue()+to;
--- End diff --
No need to create a new `Integer` here.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (GROOVY-7166) Can't build Groovy project due to too long file name
[
https://issues.apache.org/jira/browse/GROOVY-7166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15428262#comment-15428262
]
Stefán Freyr Stefánsson commented on GROOVY-7166:
-
Well, one thing that might be possibly (or maybe not... I don't know) is to use
some sort of hashing function to create names that are longer than the allowed
limit. It will probably result in butt ugly generated code but still. Again,
just some ideas from the top of my head... more than likely that they are not
good or even impossible to implement. I don't know enough about what's going on
there to be able to say.
My main purpose for the comment was to point people that stumble upon this bug
in the right direction and give them an idea of a workaround if they are using
ecryptfs.
I fully understand that there may be nothing that is practical to do to fix
this.
> Can't build Groovy project due to too long file name
>
>
> Key: GROOVY-7166
> URL: https://issues.apache.org/jira/browse/GROOVY-7166
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.3.7
>Reporter: Marcin Grzejszczak
>Priority: Minor
>
> When I clone groovy-core and execute
> {noformat}
> ./gradlew clean test
> {noformat}
> I get:
> {noformat}
> :compileTestGroovy
> warning: [options] bootstrap class path not set in conjunction with -source
> 1.6
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> 1 warning
> startup failed:
> /home/marcin/repo/groovy-fork/target/test-classes/org/codehaus/groovy/ast/builder/AstBuilderFromSpecificationTest$_testSwitchAndCaseAndBreakStatements_closure31_closure120_closure124_closure128_closure129_closure130_closure131.class
> (File name too long)
> /home/marcin/repo/groovy-fork/target/test-classes/org/codehaus/groovy/ast/builder/AstBuilderFromSpecificationTest$_testForStatementAndClosureListExpression_closure36_closure154_closure156_closure160_closure161_closure162.class
> (File name too long)
> {noformat}
> Executed with JDK7 and JDK8. On Linux Mint.
> _uname -a_ execution result:
> {noformat}
>
> Linux someName 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014
> x86_64 x86_64 x86_64 GNU/Linux
> {noformat}
> A workaround is to move the repository to another folder to shorten the path.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GROOVY-7655) Wrong method is chosen when using super with generics
[
https://issues.apache.org/jira/browse/GROOVY-7655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-7655.
--
Resolution: Fixed
Assignee: Jochen Theodorou
Fix Version/s: 2.5.0-beta-1
2.4.8
after thinking about how to solve the issue for a bit it was actually quite
easy to find a solution. The compiler will now ensure, that methods used with
super will find their mop helper method. This happens regardless of the
signature, so there are still useless methods generated, but still many less
than in 2.3
> Wrong method is chosen when using super with generics
> -
>
> Key: GROOVY-7655
> URL: https://issues.apache.org/jira/browse/GROOVY-7655
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.4
>Reporter: Marius Vaitkus
>Assignee: Jochen Theodorou
> Fix For: 2.4.8, 2.5.0-beta-1
>
> Attachments: generics_extension_test.groovy
>
>
> Given code:
> {code:title=generics_extension_test.groovy}
> interface ParamInterface{}
> class ParamImplementation implements ParamInterface{}
> class ParamExtension extends ParamImplementation {}
> class A {
> def getResult(T a) {
> return "A"
> }
> }
> class B extends A {
> def getResult(T b) {
> return "B"
> }
> }
> class C extends B {
> @Override
> def getResult(ParamExtension b) {
> return super.getResult(b)
> }
> }
> String result = new C().getResult(new ParamExtension())
> assert result == "B"
> {code}
> I get output:
> {code}
> Assertion failed:
> assert result == "B"
>| |
>A false
> at generics_extension_test.run(generics_extension_test.groovy:31)
> {code}
> When calling super method, instead of looking for method in a class one
> hierarchy bellow, groovy goes through complex calculations for finding a
> better method. I debug'ed up to a point in
> groovy.lang.MetaClassImpl#chooseMostSpecificParams
> where it turned out that distance for interface was 2 and distance for class
> that directly extends the method was much bigger, therefore the method from
> class A is chosen instead of method from class B. However, looking
> objectively, it would seem that B.getResult is a much better fit:
> C extends B and B extends A
> parameter hierarchy is shorter (ParamExtension -> ParamImplementation ->
> ParamInterface)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7166) Can't build Groovy project due to too long file name
[
https://issues.apache.org/jira/browse/GROOVY-7166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15428170#comment-15428170
]
Jochen Theodorou commented on GROOVY-7166:
--
Of course we can check if the file name length will exceed a certain limit. But
what will we do with this information? In 2.4, the file names are shorter,
since we changed the pattern for the file generation.
> Can't build Groovy project due to too long file name
>
>
> Key: GROOVY-7166
> URL: https://issues.apache.org/jira/browse/GROOVY-7166
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.3.7
>Reporter: Marcin Grzejszczak
>Priority: Minor
>
> When I clone groovy-core and execute
> {noformat}
> ./gradlew clean test
> {noformat}
> I get:
> {noformat}
> :compileTestGroovy
> warning: [options] bootstrap class path not set in conjunction with -source
> 1.6
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> 1 warning
> startup failed:
> /home/marcin/repo/groovy-fork/target/test-classes/org/codehaus/groovy/ast/builder/AstBuilderFromSpecificationTest$_testSwitchAndCaseAndBreakStatements_closure31_closure120_closure124_closure128_closure129_closure130_closure131.class
> (File name too long)
> /home/marcin/repo/groovy-fork/target/test-classes/org/codehaus/groovy/ast/builder/AstBuilderFromSpecificationTest$_testForStatementAndClosureListExpression_closure36_closure154_closure156_closure160_closure161_closure162.class
> (File name too long)
> {noformat}
> Executed with JDK7 and JDK8. On Linux Mint.
> _uname -a_ execution result:
> {noformat}
>
> Linux someName 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014
> x86_64 x86_64 x86_64 GNU/Linux
> {noformat}
> A workaround is to move the repository to another folder to shorten the path.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] groovy pull request #388: Calculating hashcode of IntRange by pairing functi...
Github user upadhyayap commented on a diff in the pull request:
https://github.com/apache/groovy/pull/388#discussion_r75469060
--- Diff: src/test/groovy/lang/IntRangeTest.groovy ---
@@ -138,4 +138,15 @@ class IntRangeTest extends GroovyTestCase {
assert bs[-1..<-7].toString() == '{0, 5}'
assert bs[20..<-8].toString() == '{2, 3}'
}
+
+void testHashCode(){
--- End diff --
best place to test hashcode is HashMap. Let know if need to check this up
for more range of values.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (GROOVY-7834) Calling hashCode on IntRange iterates through all elements in the range.
[
https://issues.apache.org/jira/browse/GROOVY-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15428041#comment-15428041
]
ASF GitHub Bot commented on GROOVY-7834:
GitHub user upadhyayap opened a pull request:
https://github.com/apache/groovy/pull/388
Calculating hashcode of IntRange by pairing function
https://issues.apache.org/jira/browse/GROOVY-7834?jql=project%20%3D%20GROOVY%20AND%20id%20%3D%20GROOVY-7834
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/upadhyayap/incubator-groovy GROOVY-7834
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/388.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #388
commit da39cc1fda39f61424471cff23df3f13867ab9d3
Author: Anand upadhyay
Date: 2016-08-19T11:43:08Z
Calculating hashcode of IntRange by pairing function
> Calling hashCode on IntRange iterates through all elements in the range.
>
>
> Key: GROOVY-7834
> URL: https://issues.apache.org/jira/browse/GROOVY-7834
> Project: Groovy
> Issue Type: Bug
>Reporter: howard zhang
>
> {code}
> new IntRange(0, Integer.MAX_VALUE-1).hashCode()
> {code}
> The above code takes a few seconds to complete.
> I believe the hashCode method is not overridden and it defaults to
> AbstractList which iterates through all elements. I don't think this should
> be the default behavior.
> http://grepcode.com/file_/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/AbstractList.java/?v=source
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] groovy pull request #388: Calculating hashcode of IntRange by pairing functi...
GitHub user upadhyayap opened a pull request: https://github.com/apache/groovy/pull/388 Calculating hashcode of IntRange by pairing function https://issues.apache.org/jira/browse/GROOVY-7834?jql=project%20%3D%20GROOVY%20AND%20id%20%3D%20GROOVY-7834 You can merge this pull request into a Git repository by running: $ git pull https://github.com/upadhyayap/incubator-groovy GROOVY-7834 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/388.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #388 commit da39cc1fda39f61424471cff23df3f13867ab9d3 Author: Anand upadhyay Date: 2016-08-19T11:43:08Z Calculating hashcode of IntRange by pairing function --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] groovy pull request #387: Calculating IntRange hashcode by pairing function
Github user upadhyayap closed the pull request at: https://github.com/apache/groovy/pull/387 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (GROOVY-7834) Calling hashCode on IntRange iterates through all elements in the range.
[
https://issues.apache.org/jira/browse/GROOVY-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15428035#comment-15428035
]
ASF GitHub Bot commented on GROOVY-7834:
Github user upadhyayap closed the pull request at:
https://github.com/apache/groovy/pull/387
> Calling hashCode on IntRange iterates through all elements in the range.
>
>
> Key: GROOVY-7834
> URL: https://issues.apache.org/jira/browse/GROOVY-7834
> Project: Groovy
> Issue Type: Bug
>Reporter: howard zhang
>
> {code}
> new IntRange(0, Integer.MAX_VALUE-1).hashCode()
> {code}
> The above code takes a few seconds to complete.
> I believe the hashCode method is not overridden and it defaults to
> AbstractList which iterates through all elements. I don't think this should
> be the default behavior.
> http://grepcode.com/file_/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/AbstractList.java/?v=source
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] groovy pull request #387: Calculating IntRange hashcode by pairing function
GitHub user upadhyayap opened a pull request: https://github.com/apache/groovy/pull/387 Calculating IntRange hashcode by pairing function https://issues.apache.org/jira/browse/GROOVY-7834?jql=project%20%3D%20GROOVY%20AND%20id%20%3D%20GROOVY-7834 You can merge this pull request into a Git repository by running: $ git pull https://github.com/upadhyayap/incubator-groovy GROOVY-7834 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/387.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #387 commit ddc925a2d80e0a05c633287497ff1c86678b Author: Anand upadhyay Date: 2016-08-19T11:03:30Z Calculating IntRange hashcode by pairing function --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (GROOVY-7834) Calling hashCode on IntRange iterates through all elements in the range.
[
https://issues.apache.org/jira/browse/GROOVY-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15428005#comment-15428005
]
ASF GitHub Bot commented on GROOVY-7834:
GitHub user upadhyayap opened a pull request:
https://github.com/apache/groovy/pull/387
Calculating IntRange hashcode by pairing function
https://issues.apache.org/jira/browse/GROOVY-7834?jql=project%20%3D%20GROOVY%20AND%20id%20%3D%20GROOVY-7834
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/upadhyayap/incubator-groovy GROOVY-7834
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/387.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #387
commit ddc925a2d80e0a05c633287497ff1c86678b
Author: Anand upadhyay
Date: 2016-08-19T11:03:30Z
Calculating IntRange hashcode by pairing function
> Calling hashCode on IntRange iterates through all elements in the range.
>
>
> Key: GROOVY-7834
> URL: https://issues.apache.org/jira/browse/GROOVY-7834
> Project: Groovy
> Issue Type: Bug
>Reporter: howard zhang
>
> {code}
> new IntRange(0, Integer.MAX_VALUE-1).hashCode()
> {code}
> The above code takes a few seconds to complete.
> I believe the hashCode method is not overridden and it defaults to
> AbstractList which iterates through all elements. I don't think this should
> be the default behavior.
> http://grepcode.com/file_/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/AbstractList.java/?v=source
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7166) Can't build Groovy project due to too long file name
[
https://issues.apache.org/jira/browse/GROOVY-7166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15427994#comment-15427994
]
Stefán Freyr Stefánsson commented on GROOVY-7166:
-
Really? I'm not too familiar with the way groovy gets compiled so I apologize
for the dumb question but is there no mechanism that checks whether the
generated classes have a file name that is too long? Even if you're not using
ecryptfs you will have a 255 character limitation to the filename. How (if at
all) does groovy handle that? Does it just fail? Or is there something else
that would inhibit the creation of a file that has such a long name?
> Can't build Groovy project due to too long file name
>
>
> Key: GROOVY-7166
> URL: https://issues.apache.org/jira/browse/GROOVY-7166
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.3.7
>Reporter: Marcin Grzejszczak
>Priority: Minor
>
> When I clone groovy-core and execute
> {noformat}
> ./gradlew clean test
> {noformat}
> I get:
> {noformat}
> :compileTestGroovy
> warning: [options] bootstrap class path not set in conjunction with -source
> 1.6
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> 1 warning
> startup failed:
> /home/marcin/repo/groovy-fork/target/test-classes/org/codehaus/groovy/ast/builder/AstBuilderFromSpecificationTest$_testSwitchAndCaseAndBreakStatements_closure31_closure120_closure124_closure128_closure129_closure130_closure131.class
> (File name too long)
> /home/marcin/repo/groovy-fork/target/test-classes/org/codehaus/groovy/ast/builder/AstBuilderFromSpecificationTest$_testForStatementAndClosureListExpression_closure36_closure154_closure156_closure160_closure161_closure162.class
> (File name too long)
> {noformat}
> Executed with JDK7 and JDK8. On Linux Mint.
> _uname -a_ execution result:
> {noformat}
>
> Linux someName 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014
> x86_64 x86_64 x86_64 GNU/Linux
> {noformat}
> A workaround is to move the repository to another folder to shorten the path.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] groovy pull request #386: Calculating hashCode of IntRange by pairing functi...
Github user upadhyayap closed the pull request at: https://github.com/apache/groovy/pull/386 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (GROOVY-7834) Calling hashCode on IntRange iterates through all elements in the range.
[
https://issues.apache.org/jira/browse/GROOVY-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15427986#comment-15427986
]
ASF GitHub Bot commented on GROOVY-7834:
Github user upadhyayap closed the pull request at:
https://github.com/apache/groovy/pull/386
> Calling hashCode on IntRange iterates through all elements in the range.
>
>
> Key: GROOVY-7834
> URL: https://issues.apache.org/jira/browse/GROOVY-7834
> Project: Groovy
> Issue Type: Bug
>Reporter: howard zhang
>
> {code}
> new IntRange(0, Integer.MAX_VALUE-1).hashCode()
> {code}
> The above code takes a few seconds to complete.
> I believe the hashCode method is not overridden and it defaults to
> AbstractList which iterates through all elements. I don't think this should
> be the default behavior.
> http://grepcode.com/file_/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/AbstractList.java/?v=source
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-7909) Calling parents method from trait using Parent.super.method() fail depending on trait declaration order
[
https://issues.apache.org/jira/browse/GROOVY-7909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Collin updated GROOVY-7909:
-
Priority: Critical (was: Major)
> Calling parents method from trait using Parent.super.method() fail depending
> on trait declaration order
> ---
>
> Key: GROOVY-7909
> URL: https://issues.apache.org/jira/browse/GROOVY-7909
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.4.7
> Environment: Grails 3.1.9
>Reporter: Sébastien Collin
>Priority: Critical
>
> I'm using trait for multiple inheritance and I faced an issue when compiling
> my project (using Grails 3.1.9, so with the gradle task CompileGroovy).
> My traits are sharing a common method ({{def method()}}) and I'm referencing
> parent's version through ParentClassName.super.method()
> I'm seeing this error:
> {quote}
> > BUG! exception in phase 'semantic analysis' in source unit 'xxx.groovy'
> > ClassNode#getTypeClass for YYY is called before the type class is set
> {quote}
> When testing different cases it seems that this problem appears because
> classes are not compiled in the right order.
> For example, a script with
> {code}
> trait Three implements One, Two {
> def postMake() {
> One.super.postMake()
> Two.super.postMake()
> println "Three"
> }
> }
> trait One {
> def postMake() { println "One"}
> }
> trait Two {
> def postMake() { println "Two"}
> }
> class Four implements Three {
> def make() {
> Three.super.postMake()
> println "All done?"
> }
> }
> Four f = new Four()
> f.make()
> {code}
> will fail, whereas putting Three method after One and Two will succeed.
> Beside, keeping this trait's declaration order but changing method names to
> be unique (and removing {{XXX.super}}) will compile and execute correctly.
> I hope I'm clear enough...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7834) Calling hashCode on IntRange iterates through all elements in the range.
[
https://issues.apache.org/jira/browse/GROOVY-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15427729#comment-15427729
]
Jochen Theodorou commented on GROOVY-7834:
--
which means to ranges with different steppings have the same hashcode...
probably no problem
> Calling hashCode on IntRange iterates through all elements in the range.
>
>
> Key: GROOVY-7834
> URL: https://issues.apache.org/jira/browse/GROOVY-7834
> Project: Groovy
> Issue Type: Bug
>Reporter: howard zhang
>
> {code}
> new IntRange(0, Integer.MAX_VALUE-1).hashCode()
> {code}
> The above code takes a few seconds to complete.
> I believe the hashCode method is not overridden and it defaults to
> AbstractList which iterates through all elements. I don't think this should
> be the default behavior.
> http://grepcode.com/file_/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/AbstractList.java/?v=source
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7906) groovy-2.4.7/bin/startGroovy: line 275: syntax error: bad substitution
[
https://issues.apache.org/jira/browse/GROOVY-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15427724#comment-15427724
]
Jochen Theodorou commented on GROOVY-7906:
--
what I would like to know is actually why in busybox $BASH is set. The failure
happens because the script assumes $BASH is set only if the shell is bash. And
according to the description the shell is not bash
> groovy-2.4.7/bin/startGroovy: line 275: syntax error: bad substitution
> --
>
> Key: GROOVY-7906
> URL: https://issues.apache.org/jira/browse/GROOVY-7906
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.7
> Environment: Alpine linux (=> no bash, busybox only)
>Reporter: Peter B.
>
> running groovy in alpine linux results in:
> {code}
> /tmp/groovy-2.4.7/bin/startGroovy: line 275: syntax error: bad substitution
> {code}
> as a workaround I'm running:
> {code}
> sed -ie '274,275d' /tmp/groovy-2.4.7/bin/startGroovy
> {code}
> prior to invoking groovy
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7166) Can't build Groovy project due to too long file name
[
https://issues.apache.org/jira/browse/GROOVY-7166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15427717#comment-15427717
]
Jochen Theodorou commented on GROOVY-7166:
--
but the only action we would be able to take then is to fail compilation
> Can't build Groovy project due to too long file name
>
>
> Key: GROOVY-7166
> URL: https://issues.apache.org/jira/browse/GROOVY-7166
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.3.7
>Reporter: Marcin Grzejszczak
>Priority: Minor
>
> When I clone groovy-core and execute
> {noformat}
> ./gradlew clean test
> {noformat}
> I get:
> {noformat}
> :compileTestGroovy
> warning: [options] bootstrap class path not set in conjunction with -source
> 1.6
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> 1 warning
> startup failed:
> /home/marcin/repo/groovy-fork/target/test-classes/org/codehaus/groovy/ast/builder/AstBuilderFromSpecificationTest$_testSwitchAndCaseAndBreakStatements_closure31_closure120_closure124_closure128_closure129_closure130_closure131.class
> (File name too long)
> /home/marcin/repo/groovy-fork/target/test-classes/org/codehaus/groovy/ast/builder/AstBuilderFromSpecificationTest$_testForStatementAndClosureListExpression_closure36_closure154_closure156_closure160_closure161_closure162.class
> (File name too long)
> {noformat}
> Executed with JDK7 and JDK8. On Linux Mint.
> _uname -a_ execution result:
> {noformat}
>
> Linux someName 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014
> x86_64 x86_64 x86_64 GNU/Linux
> {noformat}
> A workaround is to move the repository to another folder to shorten the path.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
