[GitHub] commons-lang issue #182: Add maven dependency for JMH framework.

[kinow]

Github user kinow commented on the issue:

https://github.com/apache/commons-lang/pull/182
  
Tried running the following to test the pull request:

```
$ mvn clean install
$ mvn test -Pbenchmark -e -X
```

And it kept failing with:

```
[INFO] BUILD FAILURE
[INFO] 

[INFO] Total time: 9.718 s
[INFO] Finished at: 2017-02-22T20:00:57+13:00
[INFO] Final Memory: 32M/486M
[INFO] 

[ERROR] Failed to execute goal 
org.codehaus.mojo:exec-maven-plugin:1.5.0:exec (benchmark) on project 
commons-lang3: Command execution failed. Process exited with an error: 1 (Exit 
value: 1) -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
goal org.codehaus.mojo:exec-maven-plugin:1.5.0:exec (benchmark) on project 
commons-lang3: Command execution failed.
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Command 
execution failed.
at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:302)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 20 more
Caused by: org.apache.commons.exec.ExecuteException: Process exited with an 
error: 1 (Exit value: 1)
at 
org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:404)
at 
org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:166)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:764)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:711)
at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:289)
... 22 more
```

Tried playing with dependency versions and settings, using Commons CSV as 
example (which works for me, as long as manually install one maven dependency 
as per pom.xml comment) with no luck.

Will give it another try tomorrow at work.

```
$ mvn -v
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-11T05:41:47+13:00)
Maven home: /opt/maven
Java version: 1.8.0_121, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-62-generic", arch: "amd64", family: "unix"
```



---
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] commons-lang issue #241: Fix spacing between enum constants

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/241
  

[![Coverage 
Status](https://coveralls.io/builds/10267870/badge)](https://coveralls.io/builds/10267870)

Coverage remained the same at 94.53% when pulling 
**d8e601fd179514715d719b966fd0fe9b8f5de424 on Abrasha:fix/enum-spaces** into 
**4bd982d1a1df87724682c17c39bf27b5cbe389be on apache:master**.



---
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] [Comment Edited] (CRYPTO-135) CryptoOutputStream is always blocking

[Dapeng Sun (JIRA)]

[ 
https://issues.apache.org/jira/browse/CRYPTO-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15877240#comment-15877240
 ] 

Dapeng Sun edited comment on CRYPTO-135 at 2/22/17 1:48 AM:


Thank [~vanzin] for filing this issue, I think we should fix it.

[~junjie] Do you have any comments?


was (Author: dapengsun):
Thank [~vanzin] for file this issue, I think we should fix it.

[~junjie] Do you have any comments?

> CryptoOutputStream is always blocking
> -
>
> Key: CRYPTO-135
> URL: https://issues.apache.org/jira/browse/CRYPTO-135
> Project: Commons Crypto
>  Issue Type: Bug
>  Components: Stream
>Affects Versions: 1.1.0
>Reporter: Marcelo Vanzin
>
> CRYPTO-125 described a bug where not all data written to the 
> CryptoOutputStream would make it to the underlying channel if that channel 
> was non-blocking.
> The fix added in that bug makes CryptoOutputStream blocking by doing a busy 
> loop. This makes it a poor match (not to say unusable) for applications that 
> use non-blocking channels, since it will turn non-blocking streams into 
> blocking streams that waste a lot of CPU.
> Instead, CryptoOutputStream should correctly implement non-blocking semantics 
> in its implementation of WritableByteChannel.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CRYPTO-135) CryptoOutputStream is always blocking

[Dapeng Sun (JIRA)]

[ 
https://issues.apache.org/jira/browse/CRYPTO-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15877240#comment-15877240
 ] 

Dapeng Sun commented on CRYPTO-135:
---

Thank [~vanzin] for file this issue, I think we should fix it.

[~junjie] Do you have any comments?

> CryptoOutputStream is always blocking
> -
>
> Key: CRYPTO-135
> URL: https://issues.apache.org/jira/browse/CRYPTO-135
> Project: Commons Crypto
>  Issue Type: Bug
>  Components: Stream
>Affects Versions: 1.1.0
>Reporter: Marcelo Vanzin
>
> CRYPTO-125 described a bug where not all data written to the 
> CryptoOutputStream would make it to the underlying channel if that channel 
> was non-blocking.
> The fix added in that bug makes CryptoOutputStream blocking by doing a busy 
> loop. This makes it a poor match (not to say unusable) for applications that 
> use non-blocking channels, since it will turn non-blocking streams into 
> blocking streams that waste a lot of CPU.
> Instead, CryptoOutputStream should correctly implement non-blocking semantics 
> in its implementation of WritableByteChannel.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (CONFIGURATION-647) INI removable delimiter spaces

[green (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15877029#comment-15877029
 ] 

green edited comment on CONFIGURATION-647 at 2/21/17 11:44 PM:
---

Don't really have much time, but I made something. Is that alright? See 
java.patch Attachment.


was (Author: green):
Don't really have much time, but I made something. Is that alright?

> INI removable delimiter spaces
> --
>
> Key: CONFIGURATION-647
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-647
> Project: Commons Configuration
>  Issue Type: Improvement
>  Components: Format
>Affects Versions: 2.x
>Reporter: green
>Priority: Minor
>  Labels: INI, delimiter, remove, spaces, store, write
> Attachments: java.patch
>
>
> org.apache.commons.configuration2.INIConfiguration.write creates INI files 
> with spaces around the '=' delimiter. Older software which is not expecting 
> extra spaces can break. Would be great if delimiter spaces were configurable. 
> Thx!



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CONFIGURATION-647) INI removable delimiter spaces

[green (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

green updated CONFIGURATION-647:

Attachment: java.patch

Don't really have much time, but I made something. Is that alright?

> INI removable delimiter spaces
> --
>
> Key: CONFIGURATION-647
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-647
> Project: Commons Configuration
>  Issue Type: Improvement
>  Components: Format
>Affects Versions: 2.x
>Reporter: green
>Priority: Minor
>  Labels: INI, delimiter, remove, spaces, store, write
> Attachments: java.patch
>
>
> org.apache.commons.configuration2.INIConfiguration.write creates INI files 
> with spaces around the '=' delimiter. Older software which is not expecting 
> extra spaces can break. Would be great if delimiter spaces were configurable. 
> Thx!



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876969#comment-15876969
 ] 

Gilles commented on NUMBERS-10:
---

I assume that you refer to the handling of a {{Complex}} NaN (and not to the 
class as a whole).
If you do not have a better alternative, then, of course, keep the same design 
decision.

A question is whether such a NaN is useful in actual code, beyond signalling a 
failure.
I mean, are there algorithms that can recover when passed such a {{Complex}} 
instance?
If not, I wonder whether it would not be better to throw an exception.
Alternatively, we should explore the cost and benefit of handling this NaN 
instance as is done with an 
[Optional|https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html] 
value.

> Revamp "Complex" representation ?
> -
>
> Key: NUMBERS-10
> URL: https://issues.apache.org/jira/browse/NUMBERS-10
> Project: Commons Numbers
>  Issue Type: Wish
>Reporter: Gilles
>  Labels: API, design, review
> Fix For: 1.0
>
> Attachments: CartesianRepresentation.java, Complex.java, 
> MixedRepresentation.java, PolarRepresentation.java
>
>
> This is a proposal to enhance the internal representation of complex numbers.
> The purpose is to allow usage of both cartesian and polar representations, 
> with the aim that calculations are performed (transparently) with the one 
> that will be more accurate and/or faster. 
> The API would certainly be improved, from
> {code}
> final Complex c1 = Complex.valueOf(1, 2);
> final Complex c2 = ComplexUtils.polar2Complex(2, 7);
> final Complex r = c1.add(c2);
>  {code}
> with the current code, to
> {code}
> final Complex c1 = Complex.createCartesian(1, 2);
> final Complex c2 = Complex.createPolar(2, 7);
> final Complex r = c1.add(c2);
> {code}
> Please refer to the attached files (they are self-documenting, but of course, 
> Javadoc must be added if the proposal is validated).
> Would there be merit in pursuing in that direction?
> Or is there any show-stopper?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (NUMBERS-10) Revamp "Complex" representation ?

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876128#comment-15876128
 ] 

Gilles edited comment on NUMBERS-10 at 2/21/17 10:59 PM:
-

I'm starting to move this along -- had some hold-ups.

The following is in the commons-math Complex documentation. Is this a behavior 
that needs to be changed? It looks well thought out to me. 
{noformat}
/**
 * Representation of a Complex number, i.e. a number which has both a
 * real and imaginary part.
 * 
 * Implementations of arithmetic operations handle {@code NaN} and
 * infinite values according to the rules for {@link java.lang.Double}, i.e.
 * {@link #equals} is an equivalence relation for all instances that have
 * a {@code NaN} in either real or imaginary part, e.g. the following are
 * considered equal:
 * 
 *  {@code 1 + NaNi}
 *  {@code NaN + i}
 *  {@code NaN + NaNi}
 * 
 * Note that this contradicts the IEEE-754 standard for floating
 * point numbers (according to which the test {@code x == x} must fail if
 * {@code x} is {@code NaN}). The method
 * {@link org.apache.commons.numbers.core.Precision#equals(double,double,int)
 * equals for primitive double} in class {@code Precision} conforms with
 * IEEE-754 while this class conforms with the standard behavior for Java
 * object types.
 *
 */
{noformat}



was (Author: ericbarnhill):
I'm starting to move this along -- had some hold-ups.

The following is in the commons-math Complex documentation. Is this a behavior 
that needs to be changed? It looks well thought out to me. 

/**
 * Representation of a Complex number, i.e. a number which has both a
 * real and imaginary part.
 * 
 * Implementations of arithmetic operations handle {@code NaN} and
 * infinite values according to the rules for {@link java.lang.Double}, i.e.
 * {@link #equals} is an equivalence relation for all instances that have
 * a {@code NaN} in either real or imaginary part, e.g. the following are
 * considered equal:
 * 
 *  {@code 1 + NaNi}
 *  {@code NaN + i}
 *  {@code NaN + NaNi}
 * 
 * Note that this contradicts the IEEE-754 standard for floating
 * point numbers (according to which the test {@code x == x} must fail if
 * {@code x} is {@code NaN}). The method
 * {@link org.apache.commons.numbers.core.Precision#equals(double,double,int)
 * equals for primitive double} in class {@code Precision} conforms with
 * IEEE-754 while this class conforms with the standard behavior for Java
 * object types.
 *
 */




> Revamp "Complex" representation ?
> -
>
> Key: NUMBERS-10
> URL: https://issues.apache.org/jira/browse/NUMBERS-10
> Project: Commons Numbers
>  Issue Type: Wish
>Reporter: Gilles
>  Labels: API, design, review
> Fix For: 1.0
>
> Attachments: CartesianRepresentation.java, Complex.java, 
> MixedRepresentation.java, PolarRepresentation.java
>
>
> This is a proposal to enhance the internal representation of complex numbers.
> The purpose is to allow usage of both cartesian and polar representations, 
> with the aim that calculations are performed (transparently) with the one 
> that will be more accurate and/or faster. 
> The API would certainly be improved, from
> {code}
> final Complex c1 = Complex.valueOf(1, 2);
> final Complex c2 = ComplexUtils.polar2Complex(2, 7);
> final Complex r = c1.add(c2);
>  {code}
> with the current code, to
> {code}
> final Complex c1 = Complex.createCartesian(1, 2);
> final Complex c2 = Complex.createPolar(2, 7);
> final Complex r = c1.add(c2);
> {code}
> Please refer to the attached files (they are self-documenting, but of course, 
> Javadoc must be added if the proposal is validated).
> Would there be merit in pursuing in that direction?
> Or is there any show-stopper?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] commons-lang pull request #240: Remove redundant semicolons from enums

[Abrasha]

Github user Abrasha commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/240#discussion_r102318517
  
--- Diff: src/test/java/org/apache/commons/lang3/EnumUtilsTest.java ---
@@ -418,10 +418,10 @@ public void test_processBitVectors_longClass() {
 A00, A01, A02, A03, A04, A05, A06, A07, A08, A09, A10, A11, A12, A13, 
A14, A15,
 A16, A17, A18, A19, A20, A21, A22, A23, A24, A25, A26, A27, A28, A29, 
A30, A31,
 A32, A33, A34, A35, A36, A37, A38, A39, A40, A41, A42, A43, A44, A45, 
A46, A47,
-A48, A49, A50, A51, A52, A53, A54, A55, A56, A57, A58, A59, A60, A61, 
A62, A63;
+A48, A49, A50, A51, A52, A53, A54, A55, A56, A57, A58, A59, A60, A61, 
A62, A63
 }
 enum TooMany {
 A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z,
 
A1,B1,C1,D1,E1,F1,G1,H1,I1,J1,K1,L1,M1,N1,O1,P1,Q1,R1,S1,T1,U1,V1,W1,X1,Y1,Z1,
-A2,B2,C2,D2,E2,F2,G2,H2,I2,J2,K2,L2,M2;
+A2,B2,C2,D2,E2,F2,G2,H2,I2,J2,K2,L2,M2
 }
--- End diff --

@PascalSchumacher created [PR 
#241](https://github.com/apache/commons-lang/pull/241) with minor changes of 
enum spacing



---
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] commons-lang pull request #241: Fix spacing between enum constants

[Abrasha]

GitHub user Abrasha opened a pull request:

https://github.com/apache/commons-lang/pull/241

Fix spacing between enum constants



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Abrasha/commons-lang fix/enum-spaces

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/241.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 #241


commit d8e601fd179514715d719b966fd0fe9b8f5de424
Author: Andrii 
Date:   2017-02-21T21:08:38Z

fix spaces between enum constants




---
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] commons-lang issue #182: Add maven dependency for JMH framework.

[kinow]

Github user kinow commented on the issue:

https://github.com/apache/commons-lang/pull/182
  
Oh, missed that one, will take a look today to compare with [csv].

I've never seen it failing in Jenkins or Travis CI, but I suspect it is run 
manually, whenever someone needs to work on the classes involved in the 
benchmark tests for new features or debugging issues in different environments.


---
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] commons-lang pull request #240: Remove redundant semicolons from enums

[Abrasha]

Github user Abrasha commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/240#discussion_r102314467
  
--- Diff: src/test/java/org/apache/commons/lang3/EnumUtilsTest.java ---
@@ -418,10 +418,10 @@ public void test_processBitVectors_longClass() {
 A00, A01, A02, A03, A04, A05, A06, A07, A08, A09, A10, A11, A12, A13, 
A14, A15,
 A16, A17, A18, A19, A20, A21, A22, A23, A24, A25, A26, A27, A28, A29, 
A30, A31,
 A32, A33, A34, A35, A36, A37, A38, A39, A40, A41, A42, A43, A44, A45, 
A46, A47,
-A48, A49, A50, A51, A52, A53, A54, A55, A56, A57, A58, A59, A60, A61, 
A62, A63;
+A48, A49, A50, A51, A52, A53, A54, A55, A56, A57, A58, A59, A60, A61, 
A62, A63
 }
 enum TooMany {
 A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z,
 
A1,B1,C1,D1,E1,F1,G1,H1,I1,J1,K1,L1,M1,N1,O1,P1,Q1,R1,S1,T1,U1,V1,W1,X1,Y1,Z1,
-A2,B2,C2,D2,E2,F2,G2,H2,I2,J2,K2,L2,M2;
+A2,B2,C2,D2,E2,F2,G2,H2,I2,J2,K2,L2,M2
 }
--- End diff --

@PascalSchumacher I will see if we need to create separate PR with enum 
spacing. 


---
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] commons-lang issue #182: Add maven dependency for JMH framework.

[PascalSchumacher]

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/182
  
As far as I can tell @C0rWin updated the pull request 9 days ago (after 
your conversation).

By the way merging this only makes sense if commons lang actually uses JHM. 
Do you (or somebody else) plan to work on this?


---
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] commons-lang issue #182: Add maven dependency for JMH framework.

[kinow]

Github user kinow commented on the issue:

https://github.com/apache/commons-lang/pull/182
  
I was waiting for @C0rWin to update the pull request, to have an approach 
similar to what we have in other commons projects. If he has updated it, then 
+1 to merging (or maybe check with Emmanuel Bourg if it looks good too?)


---
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] commons-lang issue #182: Add maven dependency for JMH framework.

[PascalSchumacher]

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/182
  
I guess this is ready to merge?


---
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] (LANG-1312) LocaleUtils#toLocale does not support language followed by UN M.49 numeric-3 area code

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876625#comment-15876625
 ] 

ASF GitHub Bot commented on LANG-1312:
--

Github user asfgit closed the pull request at:

https://github.com/apache/commons-lang/pull/239


> LocaleUtils#toLocale does not support language followed by UN M.49 numeric-3 
> area code
> --
>
> Key: LANG-1312
> URL: https://issues.apache.org/jira/browse/LANG-1312
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 3.6
>
>
> These all work:
> {code:java}
> System.out.println(new Locale("en", "001"));
> System.out.println(new Locale("en", "150"));
> System.out.println(new Locale("ar", "001"));
> {code}
> but these all fail with an IllegalArgumentException:
> {code:java}
> System.out.println(LocaleUtils.toLocale("en_001"));
> System.out.println(LocaleUtils.toLocale("en_150"));
> System.out.println(LocaleUtils.toLocale("ar_001"));
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (LANG-1312) LocaleUtils#toLocale does not support language followed by UN M.49 numeric-3 area code

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved LANG-1312.
-
   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: 3.6

> LocaleUtils#toLocale does not support language followed by UN M.49 numeric-3 
> area code
> --
>
> Key: LANG-1312
> URL: https://issues.apache.org/jira/browse/LANG-1312
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 3.6
>
>
> These all work:
> {code:java}
> System.out.println(new Locale("en", "001"));
> System.out.println(new Locale("en", "150"));
> System.out.println(new Locale("ar", "001"));
> {code}
> but these all fail with an IllegalArgumentException:
> {code:java}
> System.out.println(LocaleUtils.toLocale("en_001"));
> System.out.println(LocaleUtils.toLocale("en_150"));
> System.out.println(LocaleUtils.toLocale("ar_001"));
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] commons-lang pull request #239: LANG-1312: LocaleUtils#toLocale does not sup...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-lang/pull/239


---
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] commons-lang issue #240: Remove redundant semicolons from enums

[PascalSchumacher]

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/240
  
Thanks!


---
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] commons-lang pull request #240: Remove redundant semicolons from enums

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-lang/pull/240


---
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] commons-lang pull request #240: Remove redundant semicolons from enums

[PascalSchumacher]

Github user PascalSchumacher commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/240#discussion_r102281919
  
--- Diff: src/test/java/org/apache/commons/lang3/EnumUtilsTest.java ---
@@ -418,10 +418,10 @@ public void test_processBitVectors_longClass() {
 A00, A01, A02, A03, A04, A05, A06, A07, A08, A09, A10, A11, A12, A13, 
A14, A15,
 A16, A17, A18, A19, A20, A21, A22, A23, A24, A25, A26, A27, A28, A29, 
A30, A31,
 A32, A33, A34, A35, A36, A37, A38, A39, A40, A41, A42, A43, A44, A45, 
A46, A47,
-A48, A49, A50, A51, A52, A53, A54, A55, A56, A57, A58, A59, A60, A61, 
A62, A63;
+A48, A49, A50, A51, A52, A53, A54, A55, A56, A57, A58, A59, A60, A61, 
A62, A63
 }
 enum TooMany {
 A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z,
 
A1,B1,C1,D1,E1,F1,G1,H1,I1,J1,K1,L1,M1,N1,O1,P1,Q1,R1,S1,T1,U1,V1,W1,X1,Y1,Z1,
-A2,B2,C2,D2,E2,F2,G2,H2,I2,J2,K2,L2,M2;
+A2,B2,C2,D2,E2,F2,G2,H2,I2,J2,K2,L2,M2
 }
--- End diff --

I guess there should, but let's keep this pull request focused one one 
thing. :)


---
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] commons-lang pull request #240: Remove redundant semicolons from enums

[mureinik]

Github user mureinik commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/240#discussion_r102256442
  
--- Diff: src/test/java/org/apache/commons/lang3/EnumUtilsTest.java ---
@@ -418,10 +418,10 @@ public void test_processBitVectors_longClass() {
 A00, A01, A02, A03, A04, A05, A06, A07, A08, A09, A10, A11, A12, A13, 
A14, A15,
 A16, A17, A18, A19, A20, A21, A22, A23, A24, A25, A26, A27, A28, A29, 
A30, A31,
 A32, A33, A34, A35, A36, A37, A38, A39, A40, A41, A42, A43, A44, A45, 
A46, A47,
-A48, A49, A50, A51, A52, A53, A54, A55, A56, A57, A58, A59, A60, A61, 
A62, A63;
+A48, A49, A50, A51, A52, A53, A54, A55, A56, A57, A58, A59, A60, A61, 
A62, A63
 }
 enum TooMany {
 A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z,
 
A1,B1,C1,D1,E1,F1,G1,H1,I1,J1,K1,L1,M1,N1,O1,P1,Q1,R1,S1,T1,U1,V1,W1,X1,Y1,Z1,
-A2,B2,C2,D2,E2,F2,G2,H2,I2,J2,K2,L2,M2;
+A2,B2,C2,D2,E2,F2,G2,H2,I2,J2,K2,L2,M2
 }
--- End diff --

I kept the style the code had. If we collectively decide that spaces would 
make the code better, I'd gladly add them.


---
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] (NUMBERS-10) Revamp "Complex" representation ?

[Eric Barnhill (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876128#comment-15876128
 ] 

Eric Barnhill commented on NUMBERS-10:
--

I'm starting to move this along -- had some hold-ups.

The following is in the commons-math Complex documentation. Is this a behavior 
that needs to be changed? It looks well thought out to me. 

/**
 * Representation of a Complex number, i.e. a number which has both a
 * real and imaginary part.
 * 
 * Implementations of arithmetic operations handle {@code NaN} and
 * infinite values according to the rules for {@link java.lang.Double}, i.e.
 * {@link #equals} is an equivalence relation for all instances that have
 * a {@code NaN} in either real or imaginary part, e.g. the following are
 * considered equal:
 * 
 *  {@code 1 + NaNi}
 *  {@code NaN + i}
 *  {@code NaN + NaNi}
 * 
 * Note that this contradicts the IEEE-754 standard for floating
 * point numbers (according to which the test {@code x == x} must fail if
 * {@code x} is {@code NaN}). The method
 * {@link org.apache.commons.numbers.core.Precision#equals(double,double,int)
 * equals for primitive double} in class {@code Precision} conforms with
 * IEEE-754 while this class conforms with the standard behavior for Java
 * object types.
 *
 */




> Revamp "Complex" representation ?
> -
>
> Key: NUMBERS-10
> URL: https://issues.apache.org/jira/browse/NUMBERS-10
> Project: Commons Numbers
>  Issue Type: Wish
>Reporter: Gilles
>  Labels: API, design, review
> Fix For: 1.0
>
> Attachments: CartesianRepresentation.java, Complex.java, 
> MixedRepresentation.java, PolarRepresentation.java
>
>
> This is a proposal to enhance the internal representation of complex numbers.
> The purpose is to allow usage of both cartesian and polar representations, 
> with the aim that calculations are performed (transparently) with the one 
> that will be more accurate and/or faster. 
> The API would certainly be improved, from
> {code}
> final Complex c1 = Complex.valueOf(1, 2);
> final Complex c2 = ComplexUtils.polar2Complex(2, 7);
> final Complex r = c1.add(c2);
>  {code}
> with the current code, to
> {code}
> final Complex c1 = Complex.createCartesian(1, 2);
> final Complex c2 = Complex.createPolar(2, 7);
> final Complex r = c1.add(c2);
> {code}
> Please refer to the attached files (they are self-documenting, but of course, 
> Javadoc must be added if the proposal is validated).
> Would there be merit in pursuing in that direction?
> Or is there any show-stopper?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] commons-lang pull request #240: Remove redundant semicolons from enums

[Abrasha]

Github user Abrasha commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/240#discussion_r102192663
  
--- Diff: src/test/java/org/apache/commons/lang3/EnumUtilsTest.java ---
@@ -418,10 +418,10 @@ public void test_processBitVectors_longClass() {
 A00, A01, A02, A03, A04, A05, A06, A07, A08, A09, A10, A11, A12, A13, 
A14, A15,
 A16, A17, A18, A19, A20, A21, A22, A23, A24, A25, A26, A27, A28, A29, 
A30, A31,
 A32, A33, A34, A35, A36, A37, A38, A39, A40, A41, A42, A43, A44, A45, 
A46, A47,
-A48, A49, A50, A51, A52, A53, A54, A55, A56, A57, A58, A59, A60, A61, 
A62, A63;
+A48, A49, A50, A51, A52, A53, A54, A55, A56, A57, A58, A59, A60, A61, 
A62, A63
 }
 enum TooMany {
 A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z,
 
A1,B1,C1,D1,E1,F1,G1,H1,I1,J1,K1,L1,M1,N1,O1,P1,Q1,R1,S1,T1,U1,V1,W1,X1,Y1,Z1,
-A2,B2,C2,D2,E2,F2,G2,H2,I2,J2,K2,L2,M2;
+A2,B2,C2,D2,E2,F2,G2,H2,I2,J2,K2,L2,M2
 }
--- End diff --

Should there be spaces between all 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.
---

[GitHub] commons-lang issue #231: Evaluate Architecure

[michael-o]

Github user michael-o commented on the issue:

https://github.com/apache/commons-lang/pull/231
  
@kinow The cheapest way is to produce two bundles, one for 32 bit and one 
for 64 bit, if possible. The lopica source is useless, it is 15 years old. 
Commons Crypto is better. hawtjni on GitHub has decent detection code. It is 
work checking. But the current approach is way too simple.


---
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] commons-lang issue #240: Remove redundant semicolons from enums

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/240
  

[![Coverage 
Status](https://coveralls.io/builds/10249437/badge)](https://coveralls.io/builds/10249437)

Coverage increased (+0.007%) to 94.536% when pulling 
**c0d2d5b632211bb6ebc6fc0e93e133be1c3184ff on mureinik:enum-semicolon** into 
**a64153a3710c5035988690f0acf57dd61b711cf4 on apache:master**.



---
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] commons-lang pull request #240: Remove redundant semicolons from enums

[mureinik]

GitHub user mureinik opened a pull request:

https://github.com/apache/commons-lang/pull/240

Remove redundant semicolons from enums

While enums allow ending the member list in a semicolon(;), it's
redundant. Some enums in the codebase use a semicolon in the end, and
some do not.

This patch standardizes the codebase's enum and cleans up the code by
removing these semicolons.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mureinik/commons-lang enum-semicolon

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/240.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 #240


commit c0d2d5b632211bb6ebc6fc0e93e133be1c3184ff
Author: Allon Mureinik 
Date:   2017-02-21T09:18:54Z

Remove redundant semicolons from enums

While enums allow ending the member list in a semicolon(;), it's
redundant. Some enums in the codebase use a semicolon in the end, and
some do not.

This patch standardizes the codebase's enum and cleans up the code by
removing these semicolons.




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