[GitHub] [commons-pool] zenghu1chen commented on pull request #230: Support for loom

[via GitHub]

zenghu1chen commented on PR #230:
URL: https://github.com/apache/commons-pool/pull/230#issuecomment-1639523105

   > To help with tracing, could you provide the versions of both Jedis and 
Commons Pool that you are using?
   
   Hello @psteitz
   The version of Jedis I'm using is 2.8.1.3, the version of Commons Pool is 
2.4.2, and the Java version is 19.0.2. 
   My application was running stably for two months, but one day Redis had a 
failure, which caused timeouts or other exceptions (I'm not sure about the 
details of the failure). After that, all requests were hung up and did not 
recover for several hours, and it was not until after restarting the 
application instance that it resumed normal operation.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Resolved] (NUMBERS-194) JavaDoc change - coprimes check in ArithmeticUtils::gcd

[Alex Herbert (Jira)]

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

Alex Herbert resolved NUMBERS-194.
--
Fix Version/s: 1.2
   Resolution: Implemented

Updated in commit

0437008ed3e901ce70090542855c2a51731d1638

 

> JavaDoc change - coprimes check in ArithmeticUtils::gcd
> ---
>
> Key: NUMBERS-194
> URL: https://issues.apache.org/jira/browse/NUMBERS-194
> Project: Commons Numbers
>  Issue Type: New Feature
>  Components: primes
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
> Fix For: 1.2
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I am proposing a JavaDoc addition to ArithmeticUtils::gcd that mentions that 
> GCD can be used to check 2 integers are coprime. This was [~aherbert] idea.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [commons-numbers] asfgit closed pull request #133: NUMBERS-194: GCD JavaDoc mention coprimes check

[via GitHub]

asfgit closed pull request #133: NUMBERS-194: GCD JavaDoc mention coprimes check
URL: https://github.com/apache/commons-numbers/pull/133


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-pool] psteitz commented on pull request #230: Support for loom

[via GitHub]

psteitz commented on PR #230:
URL: https://github.com/apache/commons-pool/pull/230#issuecomment-1639007029

   To help with tracing, could you provide the versions of both Jedis and 
Commons Pool that you are using?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-collections] aherbert commented on pull request #406: COLLECTIONS-844 - allow counting Bloom filters with cell size other than Integer.SIZE

[via GitHub]

aherbert commented on PR #406:
URL: 
https://github.com/apache/commons-collections/pull/406#issuecomment-1638985470

   There are two terms here used through the API: _bit index_ which refers to a 
position within the shape; and the _count_ of the number of observations of 
that index. In that context you are stating a cell is a position that can be 
filled with counts. So it is a countable bit index. Would the term _cell_ ever 
be used for non-counting Bloom filters?
   
   Where does that leave the naming of BitCountProducer? CellCountProducer; 
CellProducer? This is why I questioned it. Adding new terminology should make 
sense to those reading the API for the first time. Perhaps it can be done by 
adding a note to the class javadoc for CountingBloomFilter that bit indices 
that can be counted are also known as cells (if this is correct).


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-text] orionlibs closed pull request #430: TEXT-227: removed unnecessary IF statement

[via GitHub]

orionlibs closed pull request #430: TEXT-227: removed unnecessary IF statement
URL: https://github.com/apache/commons-text/pull/430


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-numbers] orionlibs commented on a diff in pull request #133: NUMBERS-194: GCD JavaDoc mention coprimes check

[via GitHub]

orionlibs commented on code in PR #133:
URL: https://github.com/apache/commons-numbers/pull/133#discussion_r1265957810


##
commons-numbers-core/src/main/java/org/apache/commons/numbers/core/ArithmeticUtils.java:
##
@@ -58,6 +58,8 @@ private ArithmeticUtils() {
  *   for the special cases above.
  *  The invocation {@code gcd(0, 0)} is the only one which returns
  *   {@code 0}.
+ *   gcd can be used to determine if two numbers are relatively prime.

Review Comment:
   @aherbert fixed JavaDoc



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-lang] orionlibs commented on a diff in pull request #1071: LANG-1695: NumberUtils::isParseable does not recognise numbers ending in dot

[via GitHub]

orionlibs commented on code in PR #1071:
URL: https://github.com/apache/commons-lang/pull/1071#discussion_r1265949881


##
src/test/java/org/apache/commons/lang3/math/NumberUtilsTest.java:
##
@@ -918,7 +918,8 @@ public void testIsParsable() {
 assertFalse(NumberUtils.isParsable("pendro"));
 assertFalse(NumberUtils.isParsable("64, 2"));
 assertFalse(NumberUtils.isParsable("64.2.2"));
-assertFalse(NumberUtils.isParsable("64."));
+assertTrue(NumberUtils.isParsable("64."));

Review Comment:
   @elharo sorry. My understanding of the ticket is that 64. is true i.e. 
parseable and valid



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-lang] orionlibs commented on a diff in pull request #1071: LANG-1695: NumberUtils::isParseable does not recognise numbers ending in dot

[via GitHub]

orionlibs commented on code in PR #1071:
URL: https://github.com/apache/commons-lang/pull/1071#discussion_r1265949881


##
src/test/java/org/apache/commons/lang3/math/NumberUtilsTest.java:
##
@@ -918,7 +918,8 @@ public void testIsParsable() {
 assertFalse(NumberUtils.isParsable("pendro"));
 assertFalse(NumberUtils.isParsable("64, 2"));
 assertFalse(NumberUtils.isParsable("64.2.2"));
-assertFalse(NumberUtils.isParsable("64."));
+assertTrue(NumberUtils.isParsable("64."));

Review Comment:
   @elharo sorry. My understanding of the ticket is that 64. is valid



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-email] orionlibs commented on a diff in pull request #153: EMAIL-205: removed dead code

[via GitHub]

orionlibs commented on code in PR #153:
URL: https://github.com/apache/commons-email/pull/153#discussion_r1265946647


##
src/main/java/org/apache/commons/mail/EmailUtils.java:
##
@@ -295,10 +295,6 @@ static String encodeUrl(final String input) throws 
UnsupportedEncodingException
 for (final byte c : input.getBytes(US_ASCII))
 {
 int b = c;
-if (b < 0)

Review Comment:
   @aherbert done



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-collections] Claudenw commented on pull request #406: COLLECTIONS-844 - allow counting Bloom filters with cell size other than Integer.SIZE

[via GitHub]

Claudenw commented on PR #406:
URL: 
https://github.com/apache/commons-collections/pull/406#issuecomment-1638721687

   @aherbert 
   
   Cell is a standard term in the literature.  I am preparing two more pull 
requests.  
   
   1. A stable Bloom filter (weird beast) that acts sorta like a counting Bloom 
filter with random deletions.
   2. Another implementation of counting Bloom filter that uses the core 
classes from stable Bloom filter to implement counting Bloom filters that can 
use from 1 to 32 bits (1 is a bit ridiculous but it is supported).
   
   Both the new counting implementation and the stable Bloom filter are 
dependant upon a CellManager class and some supporting classes.  I could 
present the pull requests in either order, the first one being largish (like 
the layerd change) with the second being a couple of classes for the specific 
implementation. 
   
   I can update the current counting Bloom filter with the term "cell", but I 
would like to keep the terminology.  I thought I had change the method name to 
`getMaxCount`, I'll figure out where that change went.
   
   Would you be amenable to updating the documentation to refer to cell when we 
have "bits" that are values more than bits?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Updated] (STATISTICS-78) Create JMH benchmarks for alternative summation algorithms

[Anirudh Joshi (Jira)]

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

Anirudh Joshi updated STATISTICS-78:

Summary: Create JMH benchmarks for alternative summation algorithms  (was: 
JMH benchmarks for alternative summation algorithms)

> Create JMH benchmarks for alternative summation algorithms
> --
>
> Key: STATISTICS-78
> URL: https://issues.apache.org/jira/browse/STATISTICS-78
> Project: Commons Statistics
>  Issue Type: Sub-task
>  Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
>  Labels: gsoc, gsoc2023
>
> Develop JMH benchmarks to compare:
>  # Simple Sum (simply add the input values)
>  # Kahan summation algorithm 
> ([https://en.wikipedia.org/wiki/Kahan_summation_algorithm)]
>  # Two sum method (Neumaier sum) 
> [https://en.wikipedia.org/wiki/Kahan_summation_algorithm#Further_enhancements]
>  # Higher-order extended precision floating-point sums
>  # The add() methods in `BigDecimal` class with various MathContext limits on 
> the precision.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (STATISTICS-78) JMH benchmarks for alternative summation algorithms

[Anirudh Joshi (Jira)]

Anirudh Joshi created STATISTICS-78:
---

 Summary: JMH benchmarks for alternative summation algorithms
 Key: STATISTICS-78
 URL: https://issues.apache.org/jira/browse/STATISTICS-78
 Project: Commons Statistics
  Issue Type: Sub-task
  Components: descriptive
Reporter: Anirudh Joshi


Develop JMH benchmarks to compare:
 # Simple Sum (simply add the input values)
 # Kahan summation algorithm 
([https://en.wikipedia.org/wiki/Kahan_summation_algorithm)]
 # Two sum method (Neumaier sum) 
[https://en.wikipedia.org/wiki/Kahan_summation_algorithm#Further_enhancements]
 # Higher-order extended precision floating-point sums
 # The add() methods in `BigDecimal` class with various MathContext limits on 
the precision.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (STATISTICS-77) Implement Sum

[Anirudh Joshi (Jira)]

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

Anirudh Joshi updated STATISTICS-77:

Description: 
This implementation uses {{commons-numbers}} 
[Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
 as the underlying implementation.

This may be further expanded to include various other Sum implementations like 
[Kahan Sum|https://en.wikipedia.org/wiki/Kahan_summation_algorithm], {{Neumaier 
Sum}} (Two sum method) etc. with the option for the users to choose an 
implementation. However, before beginning the implementation of various other 
algorithms it may be worthwhile to discuss and investigate the relative speed 
of the current Sum implementation compared to {{DoubleStream.sum}} through JMH 
benchmarks.
When we know the different speeds, it would be more clear if the user should 
have a choice for this statistic, e.g.
 * When using {{DoubleStream.sum}} is too slow and it would be nice to have a 
simple sum variation.
 * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers from 
random walk around zero.

  was:
This implementation uses {{commons-numbers}} 
[Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
 as the underlying implementation.

This may be further expanded to include various other Sum implementations like 
[Kahan Sum|[https://en.wikipedia.org/wiki/Kahan_summation_algorithm]], 
{{Neumaier Sum}} (Two sum method) etc. with the option for the users to choose 
an implementation. However, before beginning the implementation of various 
other algorithms it may be worthwhile to discuss and investigate the relative 
speed of the current Sum implementation compared to {{DoubleStream.sum}} 
through JMH benchmarks.
When we know the different speeds, it would be more clear if the user should 
have a choice for this statistic, e.g.
 * When using {{DoubleStream.sum}} is too slow and it would be nice to have a 
simple sum variation.
 * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers from 
random walk around zero.


> Implement Sum
> -
>
> Key: STATISTICS-77
> URL: https://issues.apache.org/jira/browse/STATISTICS-77
> Project: Commons Statistics
>  Issue Type: Sub-task
>  Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
>  Labels: gsoc, gsoc2023
>
> This implementation uses {{commons-numbers}} 
> [Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
>  as the underlying implementation.
> This may be further expanded to include various other Sum implementations 
> like [Kahan Sum|https://en.wikipedia.org/wiki/Kahan_summation_algorithm], 
> {{Neumaier Sum}} (Two sum method) etc. with the option for the users to 
> choose an implementation. However, before beginning the implementation of 
> various other algorithms it may be worthwhile to discuss and investigate the 
> relative speed of the current Sum implementation compared to 
> {{DoubleStream.sum}} through JMH benchmarks.
> When we know the different speeds, it would be more clear if the user should 
> have a choice for this statistic, e.g.
>  * When using {{DoubleStream.sum}} is too slow and it would be nice to have a 
> simple sum variation.
>  * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers 
> from random walk around zero.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (STATISTICS-77) Implement Sum

[Anirudh Joshi (Jira)]

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

Anirudh Joshi updated STATISTICS-77:

Description: 
This implementation uses {{commons-numbers}} 
[Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
 as the underlying implementation.

This may be further expanded to include various other Sum implementations like 
`[Kahan Sum|[https://en.wikipedia.org/wiki/Kahan_summation_algorithm]], 
{{Neumaier Sum}} (Two sum method) etc. with the option for the users to choose 
an implementation. However, before beginning the implementation of various 
other algorithms it may be worthwhile to discuss and investigate the relative 
speed of the current Sum implementation compared to {{DoubleStream.sum}} 
through JMH benchmarks.
When we know the different speeds, it would be more clear if the user should 
have a choice for this statistic, e.g.
 * When using {{DoubleStream.sum}} is too slow and it would be nice to have a 
simple sum variation.
 * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers from 
random walk around zero.

  was:
This implementation uses {{commons-numbers}} 
[Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
 as the underlying implementation.

This may be further expanded to include various other Sum implementations like 
`[Kahan Sum|[https://en.wikipedia.org/wiki/Kahan_summation_algorithm]], 
{{Neumaier Sum}} (Two sum method) etc. with the option for the users to choose 
an implementation. However, before beginning the implementation of various 
other algorithms it may be worthwhile to discuss and investigate the relative 
speed of the current Sum implementation compared to {{DoubleStream.sum}} 
through JMH benchmarks.
When we know the different speeds, it would be more clear if the user should 
have a choice for this statistic, e.g. * When using {{DoubleStream.sum}} is too 
slow and it would be nice to have a simple sum variation.
 * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers from 
random walk around zero.


> Implement Sum
> -
>
> Key: STATISTICS-77
> URL: https://issues.apache.org/jira/browse/STATISTICS-77
> Project: Commons Statistics
>  Issue Type: Sub-task
>  Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
>  Labels: gsoc, gsoc2023
>
> This implementation uses {{commons-numbers}} 
> [Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
>  as the underlying implementation.
> This may be further expanded to include various other Sum implementations 
> like `[Kahan Sum|[https://en.wikipedia.org/wiki/Kahan_summation_algorithm]], 
> {{Neumaier Sum}} (Two sum method) etc. with the option for the users to 
> choose an implementation. However, before beginning the implementation of 
> various other algorithms it may be worthwhile to discuss and investigate the 
> relative speed of the current Sum implementation compared to 
> {{DoubleStream.sum}} through JMH benchmarks.
> When we know the different speeds, it would be more clear if the user should 
> have a choice for this statistic, e.g.
>  * When using {{DoubleStream.sum}} is too slow and it would be nice to have a 
> simple sum variation.
>  * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers 
> from random walk around zero.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (STATISTICS-77) Implement Sum

[Anirudh Joshi (Jira)]

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

Anirudh Joshi updated STATISTICS-77:

Description: 
This implementation uses {{commons-numbers}} 
[Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
 as the underlying implementation.

This may be further expanded to include various other Sum implementations like 
[Kahan Sum|[https://en.wikipedia.org/wiki/Kahan_summation_algorithm]], 
{{Neumaier Sum}} (Two sum method) etc. with the option for the users to choose 
an implementation. However, before beginning the implementation of various 
other algorithms it may be worthwhile to discuss and investigate the relative 
speed of the current Sum implementation compared to {{DoubleStream.sum}} 
through JMH benchmarks.
When we know the different speeds, it would be more clear if the user should 
have a choice for this statistic, e.g.
 * When using {{DoubleStream.sum}} is too slow and it would be nice to have a 
simple sum variation.
 * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers from 
random walk around zero.

  was:
This implementation uses {{commons-numbers}} 
[Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
 as the underlying implementation.

This may be further expanded to include various other Sum implementations like 
`[Kahan Sum|[https://en.wikipedia.org/wiki/Kahan_summation_algorithm]], 
{{Neumaier Sum}} (Two sum method) etc. with the option for the users to choose 
an implementation. However, before beginning the implementation of various 
other algorithms it may be worthwhile to discuss and investigate the relative 
speed of the current Sum implementation compared to {{DoubleStream.sum}} 
through JMH benchmarks.
When we know the different speeds, it would be more clear if the user should 
have a choice for this statistic, e.g.

When using {{DoubleStream.sum}} is too slow and it would be nice to have a 
simple sum variation.
 * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers from 
random walk around zero.


> Implement Sum
> -
>
> Key: STATISTICS-77
> URL: https://issues.apache.org/jira/browse/STATISTICS-77
> Project: Commons Statistics
>  Issue Type: Sub-task
>  Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
>  Labels: gsoc, gsoc2023
>
> This implementation uses {{commons-numbers}} 
> [Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
>  as the underlying implementation.
> This may be further expanded to include various other Sum implementations 
> like [Kahan Sum|[https://en.wikipedia.org/wiki/Kahan_summation_algorithm]], 
> {{Neumaier Sum}} (Two sum method) etc. with the option for the users to 
> choose an implementation. However, before beginning the implementation of 
> various other algorithms it may be worthwhile to discuss and investigate the 
> relative speed of the current Sum implementation compared to 
> {{DoubleStream.sum}} through JMH benchmarks.
> When we know the different speeds, it would be more clear if the user should 
> have a choice for this statistic, e.g.
>  * When using {{DoubleStream.sum}} is too slow and it would be nice to have a 
> simple sum variation.
>  * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers 
> from random walk around zero.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (STATISTICS-77) Implement Sum

[Anirudh Joshi (Jira)]

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

Anirudh Joshi updated STATISTICS-77:

Description: 
This implementation uses {{commons-numbers}} 
[Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
 as the underlying implementation.

This may be further expanded to include various other Sum implementations like 
`[Kahan Sum|[https://en.wikipedia.org/wiki/Kahan_summation_algorithm]], 
{{Neumaier Sum}} (Two sum method) etc. with the option for the users to choose 
an implementation. However, before beginning the implementation of various 
other algorithms it may be worthwhile to discuss and investigate the relative 
speed of the current Sum implementation compared to {{DoubleStream.sum}} 
through JMH benchmarks.
When we know the different speeds, it would be more clear if the user should 
have a choice for this statistic, e.g.

When using {{DoubleStream.sum}} is too slow and it would be nice to have a 
simple sum variation.
 * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers from 
random walk around zero.

  was:
This implementation uses {{commons-numbers}} 
[Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
 as the underlying implementation.

This may be further expanded to include various other Sum implementations like 
`[Kahan Sum|[https://en.wikipedia.org/wiki/Kahan_summation_algorithm]], 
{{Neumaier Sum}} (Two sum method) etc. with the option for the users to choose 
an implementation. However, before beginning the implementation of various 
other algorithms it may be worthwhile to discuss and investigate the relative 
speed of the current Sum implementation compared to {{DoubleStream.sum}} 
through JMH benchmarks.
When we know the different speeds, it would be more clear if the user should 
have a choice for this statistic, e.g.
 * When using {{DoubleStream.sum}} is too slow and it would be nice to have a 
simple sum variation.
 * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers from 
random walk around zero.


> Implement Sum
> -
>
> Key: STATISTICS-77
> URL: https://issues.apache.org/jira/browse/STATISTICS-77
> Project: Commons Statistics
>  Issue Type: Sub-task
>  Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
>  Labels: gsoc, gsoc2023
>
> This implementation uses {{commons-numbers}} 
> [Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
>  as the underlying implementation.
> This may be further expanded to include various other Sum implementations 
> like `[Kahan Sum|[https://en.wikipedia.org/wiki/Kahan_summation_algorithm]], 
> {{Neumaier Sum}} (Two sum method) etc. with the option for the users to 
> choose an implementation. However, before beginning the implementation of 
> various other algorithms it may be worthwhile to discuss and investigate the 
> relative speed of the current Sum implementation compared to 
> {{DoubleStream.sum}} through JMH benchmarks.
> When we know the different speeds, it would be more clear if the user should 
> have a choice for this statistic, e.g.
> When using {{DoubleStream.sum}} is too slow and it would be nice to have a 
> simple sum variation.
>  * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers 
> from random walk around zero.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (STATISTICS-77) Implement Sum

[Anirudh Joshi (Jira)]

Anirudh Joshi created STATISTICS-77:
---

 Summary: Implement Sum
 Key: STATISTICS-77
 URL: https://issues.apache.org/jira/browse/STATISTICS-77
 Project: Commons Statistics
  Issue Type: Sub-task
  Components: descriptive
Reporter: Anirudh Joshi


This implementation uses {{commons-numbers}} 
[Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
 as the underlying implementation.

This may be further expanded to include various other Sum implementations like 
`[Kahan Sum|[https://en.wikipedia.org/wiki/Kahan_summation_algorithm]], 
{{Neumaier Sum}} (Two sum method) etc. with the option for the users to choose 
an implementation. However, before beginning the implementation of various 
other algorithms it may be worthwhile to discuss and investigate the relative 
speed of the current Sum implementation compared to {{DoubleStream.sum}} 
through JMH benchmarks.
When we know the different speeds, it would be more clear if the user should 
have a choice for this statistic, e.g. * When using {{DoubleStream.sum}} is too 
slow and it would be nice to have a simple sum variation.
 * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers from 
random walk around zero.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IMAGING-358) "RationalNumber" class is "public"

[Gilles Sadowski (Jira)]

[ 
https://issues.apache.org/jira/browse/IMAGING-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743888#comment-17743888
 ] 

Gilles Sadowski commented on IMAGING-358:
-

bq.  I cited concerns that the alternate approach might not work due to the 
possibility of difference in implementation and rules.  You asked the 
reasonable question "where are the differences?"  And  now I will make the 
reasonable observation that the onus is on you to answer that, not me.

I was suggesting team work towards a common goal.  If such does not exist, then 
there is no point.

bq. After all, you are the one who is proposing to replace existing code.  
Before the commons-number solution could be integrated into commons-imaging, 
someone would have to inspect both approaches method-by-method to verify that 
the results are compatible.

Yes, but it was the result of noticing that your {{RationalNumber}} 
implementation hit bugs that might not exist (or have been fixed) in [Numbers]. 
 Of course, there is the risk that bugs still exist, but the point of 
consolidation is to not hit the same bug twice.  The more a code is used, the 
better (in my book).
Obviously (?), it does not make sense that an app developer who needs a 
"fraction" should depend on [Imaging]; so the functionality has to stand on its 
own in a truly low-level library.  Once there, it makes sense that other 
libraries reuse it.

bq. [...] we saw recently that changing legacy code to use an alternate API can 
go badly wrong.

OK.  That happens.
Reinventing all the wheels also has its drawbacks.

bq. I have a point that cannot be dismissed out-of-hand.

I'm not doing that.
I repeat: I had only pointed out a very real drawback of dismissing (!) the 
principle of code reuse.
[It just happens that at work, a bug has lived on for years because some 
computation was deemed "so easy" that several teams would perform it (rather 
than a single one who'd then share the results).  Not everyone got it right...]

bq. Commons-numbers-fraction is only 25.7 K with 7 compiled classes. That's no 
big deal in a modern computing environment.  But, oh yeah, it depends on 
commons-number-core (25,3 K, 14 compiled classes). So now my Configuration 
Management team, to whom I am answerable, has to add two new Jar files to their 
build.

This is irrelevant to the _principle_ of code reuse which I advocate.
Thanks to having control over all those codes, what you expose here is a 
_practical problem_ which we can solve (once known): We could indeed further 
modularize "Commons Numbers" so as to generate a "convenience" JAR that only 
contains what you need.  Alternately, as was done in the past IIRC, [Imaging] 
could use "shading" in order to effectively have no dependencies, while still 
reusing common code.

bq. Finally, on a less contentious topic, [...]

I don't remember if you were around at the time, but be sure that it has been 
very, very contentious, with some PMC members preferring to move [Math] to the 
"attic" rather than refactor it...

bq. I did want to add that the refactoring of the Math project into smaller 
pieces is an excellent idea and that you guys have made an outstanding effort. 
[...]

Thanks a lot; I'm glad to hear it finally (that the idea was good)!  Of course, 
many thanks to [~aherbert] and [~mattjuntunen] for being instrumental in the 
enhanced functionality which the spun-off components now provide.

bq. So I do admire what you were able to accomplish.

Work is not done yet.  You are welcome to help.  Even if you insist on keeping 
{{RationalNumber}} in [Imaging]. ;-)


> "RationalNumber" class is "public"
> --
>
> Key: IMAGING-358
> URL: https://issues.apache.org/jira/browse/IMAGING-358
> Project: Commons Imaging
>  Issue Type: Wish
>  Components: imaging.common.*
>Affects Versions: 1.0-alpha2
>Reporter: Gilles Sadowski
>Priority: Major
>  Labels: API, support
> Fix For: 1.0, 1.0-alpha3
>
>
> As per its Javadoc, class 
> [{{RationalNumber}}|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/common/RationalNumber.html]
>  is tuned to the requirements of the TIFF format while its name purports that 
> it's a general implementation of the "fraction" concept.
> Which is it?
> Do we want that utility to be part of [Imaging]'s public API (thus eliciting 
> support to application developers who might use it beyond its intended scope)?
> A dependency on [[Numbers]'s "fraction" 
> module|https://commons.apache.org/proper/commons-numbers/commons-numbers-docs/apidocs/org/apache/commons/numbers/fraction/package-summary.html],
>  as proposed in IMAGING-309) would avoid the issue, and also consolidate 
> (and/or help find potential bugs in) [Numbers]'s implementation.
> If that proposal is not accepted, 

[jira] [Updated] (STATISTICS-72) Implement Min

[Alex Herbert (Jira)]

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

Alex Herbert updated STATISTICS-72:
---
Fix Version/s: 1.1

> Implement Min
> -
>
> Key: STATISTICS-72
> URL: https://issues.apache.org/jira/browse/STATISTICS-72
> Project: Commons Statistics
>  Issue Type: Sub-task
>  Components: descriptive
>Reporter: Anirudh Joshi
>Assignee: Anirudh Joshi
>Priority: Minor
>  Labels: gsoc, gsoc2023
> Fix For: 1.1
>
>
> Logic to compute the minimum of all values seen so far.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (STATISTICS-76) Implement Max

[Alex Herbert (Jira)]

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

Alex Herbert resolved STATISTICS-76.

Fix Version/s: 1.1
   Resolution: Implemented

Added in commit:

4633d9bb7989dc7b168ab04456b1a085d59d53b5

 

> Implement Max
> -
>
> Key: STATISTICS-76
> URL: https://issues.apache.org/jira/browse/STATISTICS-76
> Project: Commons Statistics
>  Issue Type: Sub-task
>  Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
>  Labels: gsoc, gsoc2023
> Fix For: 1.1
>
>
> Logic to compute the maximum of all the input values.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [commons-statistics] aherbert merged pull request #49: STATISTICS-76: Max Implementation

[via GitHub]

aherbert merged PR #49:
URL: https://github.com/apache/commons-statistics/pull/49


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (IMAGING-356) TIFF reading extremely slow in version 1.0-SNAPSHOT

[Gary Lucas (Jira)]

[ 
https://issues.apache.org/jira/browse/IMAGING-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743841#comment-17743841
 ] 

Gary Lucas commented on IMAGING-356:


Gary,

I think you are correct in identifying ImageBuilder.setRGB() as a bottleneck.  

The setRGB method is called to populate each pixel in an image one-at-a-time.  
I will look at what would be required to implement a method that populated a 
set of multiple pixels (perhaps one row at a time).   

The current version uses the Java Math.multiplyExact and Math.addExact methods 
to perform exact arithmetic in an effort to avoid integer overflow. Of course, 
integer overflow is a condition that will "never" happen...  The elements 
involved, image width and x/y coordinates should be well within the range of 
normal integer arithmetic. And if they're not, then something else will break 
long before setRGB is called.   Even so, I am not strongly advocating changing 
setRGB back to the form I originally implemented.

Just to gain insights, I looked at reverting the code back to its original form.

The current code looks something like:
{code:java}
        final int rowOffset = Math.multiplyExact(y, width);
        final int index = Math.addExact(rowOffset, x);
        if (index > data.length) {
             throw new IllegalArgumentException("setRGB: Illegal array index.");
        }
        data[index] = argb;{code}
 

I tried refactoring it two ways (bare bones):
{code:java}
data[y * width + x] = argb;{code}
And range checked
{code:java}
        final int index = y * width + x;
        if(0<=index && index TIFF reading extremely slow in version 1.0-SNAPSHOT
> ---
>
> Key: IMAGING-356
> URL: https://issues.apache.org/jira/browse/IMAGING-356
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: TIFF
>Affects Versions: 1.0
>Reporter: Gary Lucas
>Priority: Major
> Attachments: image-2023-07-04-08-52-36-535.png
>
>
> I am using the latest code from github (1.0-SNAPSHOT downloaded from github 
> of June 2023) to read a 300 megabyte TIFF file.  Version 1.0-alpha3 required 
> 673 milliseconds to read that file.  The new code requires upward of 15 
> minutes.   Clearly something got broken since the last release.
> The TIFF file is a 1x1 pixel 4 byte image format organized in strips. 
>  The bottleneck appears to occur in the TiffReader getTiffRawImageData method 
> which reads raw data from the file in preparation of creating a BufferedImage 
> object.
> I suspect that there may be a general slowness of file access.  In debugging, 
> even reading the initial metadata (22 TIFF tags) took a couple of seconds.  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [commons-statistics] aherbert commented on a diff in pull request #49: [STATISTICS-76]: Max Implementation

[via GitHub]

aherbert commented on code in PR #49:
URL: https://github.com/apache/commons-statistics/pull/49#discussion_r1265505789


##
commons-statistics-descriptive/src/test/java/org/apache/commons/statistics/descriptive/MaxTest.java:
##
@@ -0,0 +1,188 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.statistics.descriptive;
+
+import java.util.Arrays;
+import java.util.function.DoubleSupplier;
+import java.util.stream.Stream;
+import org.apache.commons.rng.UniformRandomProvider;
+import org.junit.jupiter.api.Assertions;
+import org.junit.jupiter.api.Test;
+import org.junit.jupiter.params.ParameterizedTest;
+import org.junit.jupiter.params.provider.Arguments;
+import org.junit.jupiter.params.provider.MethodSource;
+
+/**
+ * Test for {@link Max}.
+ */
+final class MaxTest {
+
+@Test
+void testEmpty() {
+Max max = Max.create();
+Assertions.assertEquals(Double.NEGATIVE_INFINITY, max.getAsDouble());
+}
+
+@Test
+void testIncrement() {
+// Test the max after each incremental update
+// First parameter of testArray is the value that would be added
+// Second parameter of testArray is the max we expect after adding the 
value
+double[][] testArray = {
+{1729.22, 1729.22},
+{2520.35, 2520.35},
+{2010.87, 2520.35},
+{1.1, 1.1},
+{+0.0, 1.1},
+{-0.0, 1.1},
+{Double.MAX_VALUE, Double.MAX_VALUE},
+{Double.POSITIVE_INFINITY, Double.POSITIVE_INFINITY},
+{Double.NEGATIVE_INFINITY, Double.POSITIVE_INFINITY}
+};
+
+Max stat = Max.create();
+for (final double[] valueAndExpected: testArray) {
+final double value = valueAndExpected[0];
+final double expected = valueAndExpected[1];
+stat.accept(value);
+Assertions.assertEquals(expected, stat.getAsDouble());
+}
+}
+
+@Test
+void testNaN() {
+// Test non-nan values cannot revert a NaN
+double[] testArray = {Double.NaN, +0.0d, -0.0d, 
Double.POSITIVE_INFINITY, Double.NEGATIVE_INFINITY};
+Max stat = Max.create();
+for (final double x : testArray) {
+stat.accept(x);
+Assertions.assertEquals(Double.NaN, stat.getAsDouble());
+}
+}
+
+@ParameterizedTest
+@MethodSource
+void testMax(double[] values, double expected) {
+Max stat = Max.create();
+Arrays.stream(values).forEach(stat);
+double actual = stat.getAsDouble();
+Assertions.assertEquals(expected, actual, "max");
+Assertions.assertEquals(expected, Max.of(values).getAsDouble(), "max");

Review Comment:
   The assertion message here is not helpful to distinguish this case. You 
could use "of(values)". Just change the test data so the test fails and you can 
see how JUnit will output the message. This should be helpful to diagnose the 
problem with the code.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-lang] garydgregory commented on pull request #786: Lang-1657: Diff Result Type Constraint

[via GitHub]

garydgregory commented on PR #786:
URL: https://github.com/apache/commons-lang/pull/786#issuecomment-1638309110

   @greatmastermario 
   Don't worry about git for now since GitHub does seem to see conflicts for a 
merge. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-lang] greatmastermario commented on pull request #786: Lang-1657: Diff Result Type Constraint

[via GitHub]

greatmastermario commented on PR #786:
URL: https://github.com/apache/commons-lang/pull/786#issuecomment-1638302422

   No problem, thought I would check. I typically use git pull to merge a
   remote branch, so I'm not used to the rebase command. I can continue to
   work through the rebate conflicts, was just trying to save some time.
   
   On Mon, Jul 17, 2023, 7:44 AM Gary Gregory ***@***.***> wrote:
   
   > No, please don't open and close PRs and create noise. Just Google on how
   > to use git and you'll get there, but for now, see my comment #786
   > (comment)
   > 
   >
   > If you can't figure out git, don't worry, and we will deal with the PR as
   > it is.
   >
   > —
   > Reply to this email directly, view it on GitHub
   > ,
   > or unsubscribe
   > 

   > .
   > You are receiving this because you were mentioned.Message ID:
   > ***@***.***>
   >
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (COLLECTIONS-844) Counting Bloom filter expects counts (cells) to be ints

[Alex Herbert (Jira)]

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743827#comment-17743827
 ] 

Alex Herbert commented on COLLECTIONS-844:
--

The functional changes in the PR are fine, i.e. expose some measure of the 
capacity of the counts. But without an exact use case I am not certain of how 
it would be used by an API user. If this is simply to make the abstract test 
passable for other implementation then it does not add value to the API.

Q. Is there a reference computation for an estimate of the number of items that 
can be added before saturating a bit index with a certain probability. It may 
be useful to point a reader in the direction of some calculations. Thus they 
can use the Shape and this property to get an estimate of capacity before 
invalidation.

 

> Counting Bloom filter expects counts (cells) to be ints
> ---
>
> Key: COLLECTIONS-844
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-844
> Project: Commons Collections
>  Issue Type: Improvement
>Affects Versions: 4.5
>Reporter: Claude Warren
>Priority: Minor
>
> The AbstractCountingBloomFilterTest assumes that the Bloom filter is using an 
> int to track the counts.  Any implementation using a smaller storage size 
> will not be able to pass the test.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [commons-collections] aherbert commented on pull request #406: COLLECTIONS-844 - allow counting Bloom filters with cell size other than Integer.SIZE

[via GitHub]

aherbert commented on PR #406:
URL: 
https://github.com/apache/commons-collections/pull/406#issuecomment-1638300622

   The functional changes are fine, i.e. expose some measure of the capacity of 
the counts. But without an exact use case I am not certain of how it would be 
used.
   
   I think this could do with some naming improvement. You cannot `get` values 
from a counting Bloom filter. So `getMaxValue` seems out of context. Plus no 
other docs in the class refer to a 'cell'. The filter always uses the term 'bit 
index'.
   
   Should this property instead reflect that it is the maximum count of the 
same bit index that can be added to the filter before the state is invalidated. 
So change to `getMaxCount` and document that it is the maximum count that can 
be held for any bit index. If this is exceeded then the filter is invalidated 
(see `#isValid`).
   
   Q. Is there a reference computation for an estimate of the number of items 
that can be added before saturating a bit index with a certain probability. It 
may be useful to point a reader in the direction of some calculations. Thus 
they can use the Shape and this property to get an estimate of capacity.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-lang] garydgregory commented on pull request #786: Lang-1657: Diff Result Type Constraint

[via GitHub]

garydgregory commented on PR #786:
URL: https://github.com/apache/commons-lang/pull/786#issuecomment-1638297185

   No, please don't open and close PRs and create noise. Just Google on how to 
use git and you'll get there, but for now, see my comment 
https://github.com/apache/commons-lang/pull/786#discussion_r1264740474
   
   If you can't figure out git, don't worry, and we will deal with the PR as it 
is.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-lang] greatmastermario commented on a diff in pull request #786: Lang-1657: Diff Result Type Constraint

[via GitHub]

greatmastermario commented on code in PR #786:
URL: https://github.com/apache/commons-lang/pull/786#discussion_r1265397528


##
src/test/java/org/apache/commons/lang3/builder/DiffBuilderTest.java:
##
@@ -495,4 +519,16 @@ public void testTriviallyEqualTestEnabled() {
 assertThat(explicitTestAndEqual.build().getNumberOfDiffs(), 
equalToZero);
 }
 
+@Test
+public void testNestedDiffable() {

Review Comment:
   Let me validate again, but this should not be passing. The generic type T in 
master (did it get renamed to main? I don't see that in the repo) makes it 
where the passed diff needs to be the same type as the original builder. Making 
it ? allows other types of DiffBuilders to be passed. If this is not the 
behavior in master, I can rewrite the test.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-lang] greatmastermario commented on pull request #786: Lang-1657: Diff Result Type Constraint

[via GitHub]

greatmastermario commented on PR #786:
URL: https://github.com/apache/commons-lang/pull/786#issuecomment-1638189350

   > @greatmastermario I'm having trouble applying the patch locally on master 
with `git apply`. Would you rebase on master, please?
   
   Hi Gary, I am trying to do a git rebase, but it's considering every change 
from the last two years a "merge conflict" and making me manually apply all the 
changes. Should I close this PR, recreate the branch, and open a new PR?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Comment Edited] (IMAGING-358) "RationalNumber" class is "public"

[Gary Lucas (Jira)]

[ 
https://issues.apache.org/jira/browse/IMAGING-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743803#comment-17743803
 ] 

Gary Lucas edited comment on IMAGING-358 at 7/17/23 1:17 PM:
-

So what you are proposing is to  replace code that has been around for long 
time with an alternate module.   I cited concerns that the alternate approach 
might not work due to the possibility of difference in implementation and 
rules.  You asked the reasonable question "where are the differences?"  And  
now I will make the reasonable observation that the onus is on you to answer 
that, not me.  After all, you are the one who is proposing to replace existing 
code.  Before the commons-number solution could be integrated into 
commons-imaging, someone would have to inspect both approaches method-by-method 
to verify that the results are compatible.  In doing so, he might discover that 
the JUnit tests in commons-imaging needed to be enhanced to pick up the edge 
cases (after all, imaging is a pretty old set of code that was written before 
JUnit tests had come into wide practice). 

The idea of promoting code reuse is usually a good idea.  But in Imaging-356, 
we saw recently that changing legacy code to use an alternate API can go badly 
wrong.  

 

Now, regarding the idea of bloat, we will never agree.  And I maintain that I 
have a point that cannot be dismissed out-of-hand.  Commons-numbers-fraction is 
only 25.7 K with 7 compiled classes. That's no big deal in a modern computing 
environment.  But, oh yeah, it depends on commons-number-core (25,3 K, 14 
compiled classes).   So now my Configuration Management team, to whom I am 
answerable, has to add two new Jar files to their build.  And adding a 
dependency on commons-numbers will be adding multiple classes that are 
unrelated to what commons-imaging does.  We use a lot of commons APIs, but we 
won't currently use the numbers classes.    

 

Finally, on a less contentious topic, I did want to add that the refactoring of 
the Math project into smaller pieces is an excellent idea and that you guys 
have made an outstanding effort.  Some years back, I went through the mental 
exercise of wondering what would be involved in reorganizing math into separate 
modules (a core including linear algebra? where would combinatorics go? can you 
separate statistics from differential equations? how would you handle complex 
numbers?).   I quickly concluded that it would be a tricky job with a lot of 
hard decisions and that I wasn't even going to propose it.   So I do admire 
what you were able to accomplish.

 

 


was (Author: gwlucas):
So what you are proposing is to  replace code that has been around for long 
time with an alternate module.   I cited concerns that the alternate approach 
might not work due to the possibility of difference in implementation and 
rules.  You asked the reasonable question "where are the differences?"  And  
now I will make the reasonable observation that the onus is on you to answer 
that, not me.  After all, you are the one who is proposing to replace existing 
code.  Before the commons-number solution could be integrated into 
commons-imaging, someone would have to inspect both approaches method-by-method 
to verify that the results are compatible.  In doing so, he might discover that 
the JUnit tests in commons-imaging needed to be enhanced to pick up the edge 
cases (after all, imaging is a pretty old set of code that was written before 
JUnit tests had come into wide practice). 

The idea of promoting code reuse is usually a good idea.  But in Imaging-356, 
we saw recently that changing legacy code to use an alternate API's can go 
badly wrong.  

 

Now, regarding the idea of bloat, we will never agree.  And I maintain that I 
have a point that cannot be dismissed out-of-hand.  Commons-numbers-fraction is 
only 25.7 K with 7 compiled classes. That's no big deal in a modern computing 
environment.  But, oh yeah, it depends on commons-number-core (25,3 K, 14 
compiled classes).   So now my Configuration Management team, to whom I am 
answerable, has to add two new Jar files to their build.  And adding a 
dependency on commons-numbers will be adding multiple classes that are 
unrelated to what commons-imaging does.  We use a lot of commons APIs, but we 
won't currently use the numbers classes.    

 

Finally, on a less contentious topic, I did want to add that the refactoring of 
the Math project into smaller pieces is an excellent idea and that you guys 
have made an outstanding effort.  Some years back, I went through the mental 
exercise of wondering what would be involved in reorganizing math into separate 
modules (a core including linear algebra? where would combinatorics go? can you 
separate statistics from differential equations? how would you handle complex 
numbers?).   I quickly concluded that it would be a tricky job with a lot 

[jira] [Commented] (IMAGING-358) "RationalNumber" class is "public"

[Gary Lucas (Jira)]

[ 
https://issues.apache.org/jira/browse/IMAGING-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743803#comment-17743803
 ] 

Gary Lucas commented on IMAGING-358:


So what you are proposing is to  replace code that has been around for long 
time with an alternate module.   I cited concerns that the alternate approach 
might not work due to the possibility of difference in implementation and rule. 
 You asked the reasonable question "where are the differences?"  And  now I 
will make the reasonable observation that the onus is on you to answer that, 
not me.  After all, you are the one who is proposing to replace existing code.  
Before the commons-number solution could be integrated into commons-imaging, 
someone would have to inspect both approaches method-by-method to verify that 
the results are compatible.  In doing so, he might discover that the JUnit 
tests in commons-imaging needed to be enhanced to pick up the edge cases (after 
all, imaging is a pretty old set of code that was written before JUnit tests 
had come into wide practice). 

The idea of promoting code reuse is usually a good idea.  But in Imaging-356, 
we saw recently that changing legacy code to use an alternate API's can go 
badly wrong.  

 

Now, regarding the idea of bloat, we will never agree.  And I maintain that I 
have a point that cannot be dismissed out-of-hand.  Commons-numbers-fraction is 
only 25.7 K with 7 compiled classes. That's no big deal in a modern computing 
environment.  But, oh yeah, it depends on commons-number-core (25,3 K, 14 
compiled classes).   So now my Configuration Management team, to whom I am 
answerable, has to add two new Jar files to their build.  And adding a 
dependency on commons-numbers will be adding multiple classes that are 
unrelated to what commons-imaging does.  We use a lot of commons APIs, but we 
won't currently use the numbers classes.    

 

Finally, on a less contentious topic, I did want to add that the refactoring of 
the Math project into smaller pieces is an excellent idea and that you guys 
have made an outstanding effort.  Some years back, I went through the mental 
exercise of wondering what would be involved in reorganizing math into separate 
modules (a core including linear algebra? where would combinatorics go? can you 
separate statistics from differential equations? how would you handle complex 
numbers?).   I quickly concluded that it would be a tricky job with a lot of 
hard decisions and that I wasn't even going to propose it.   So I do admire 
what you were able to accomplish.

 

 

> "RationalNumber" class is "public"
> --
>
> Key: IMAGING-358
> URL: https://issues.apache.org/jira/browse/IMAGING-358
> Project: Commons Imaging
>  Issue Type: Wish
>  Components: imaging.common.*
>Affects Versions: 1.0-alpha2
>Reporter: Gilles Sadowski
>Priority: Major
>  Labels: API, support
> Fix For: 1.0, 1.0-alpha3
>
>
> As per its Javadoc, class 
> [{{RationalNumber}}|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/common/RationalNumber.html]
>  is tuned to the requirements of the TIFF format while its name purports that 
> it's a general implementation of the "fraction" concept.
> Which is it?
> Do we want that utility to be part of [Imaging]'s public API (thus eliciting 
> support to application developers who might use it beyond its intended scope)?
> A dependency on [[Numbers]'s "fraction" 
> module|https://commons.apache.org/proper/commons-numbers/commons-numbers-docs/apidocs/org/apache/commons/numbers/fraction/package-summary.html],
>  as proposed in IMAGING-309) would avoid the issue, and also consolidate 
> (and/or help find potential bugs in) [Numbers]'s implementation.
> If that proposal is not accepted, {{RationalNumber}} should preferably be 
> moved to [Imaging]'s [{{internal}} 
> package|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/internal/package-summary.html].



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (IMAGING-358) "RationalNumber" class is "public"

[Gary Lucas (Jira)]

[ 
https://issues.apache.org/jira/browse/IMAGING-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743803#comment-17743803
 ] 

Gary Lucas edited comment on IMAGING-358 at 7/17/23 1:16 PM:
-

So what you are proposing is to  replace code that has been around for long 
time with an alternate module.   I cited concerns that the alternate approach 
might not work due to the possibility of difference in implementation and 
rules.  You asked the reasonable question "where are the differences?"  And  
now I will make the reasonable observation that the onus is on you to answer 
that, not me.  After all, you are the one who is proposing to replace existing 
code.  Before the commons-number solution could be integrated into 
commons-imaging, someone would have to inspect both approaches method-by-method 
to verify that the results are compatible.  In doing so, he might discover that 
the JUnit tests in commons-imaging needed to be enhanced to pick up the edge 
cases (after all, imaging is a pretty old set of code that was written before 
JUnit tests had come into wide practice). 

The idea of promoting code reuse is usually a good idea.  But in Imaging-356, 
we saw recently that changing legacy code to use an alternate API's can go 
badly wrong.  

 

Now, regarding the idea of bloat, we will never agree.  And I maintain that I 
have a point that cannot be dismissed out-of-hand.  Commons-numbers-fraction is 
only 25.7 K with 7 compiled classes. That's no big deal in a modern computing 
environment.  But, oh yeah, it depends on commons-number-core (25,3 K, 14 
compiled classes).   So now my Configuration Management team, to whom I am 
answerable, has to add two new Jar files to their build.  And adding a 
dependency on commons-numbers will be adding multiple classes that are 
unrelated to what commons-imaging does.  We use a lot of commons APIs, but we 
won't currently use the numbers classes.    

 

Finally, on a less contentious topic, I did want to add that the refactoring of 
the Math project into smaller pieces is an excellent idea and that you guys 
have made an outstanding effort.  Some years back, I went through the mental 
exercise of wondering what would be involved in reorganizing math into separate 
modules (a core including linear algebra? where would combinatorics go? can you 
separate statistics from differential equations? how would you handle complex 
numbers?).   I quickly concluded that it would be a tricky job with a lot of 
hard decisions and that I wasn't even going to propose it.   So I do admire 
what you were able to accomplish.

 

 


was (Author: gwlucas):
So what you are proposing is to  replace code that has been around for long 
time with an alternate module.   I cited concerns that the alternate approach 
might not work due to the possibility of difference in implementation and rule. 
 You asked the reasonable question "where are the differences?"  And  now I 
will make the reasonable observation that the onus is on you to answer that, 
not me.  After all, you are the one who is proposing to replace existing code.  
Before the commons-number solution could be integrated into commons-imaging, 
someone would have to inspect both approaches method-by-method to verify that 
the results are compatible.  In doing so, he might discover that the JUnit 
tests in commons-imaging needed to be enhanced to pick up the edge cases (after 
all, imaging is a pretty old set of code that was written before JUnit tests 
had come into wide practice). 

The idea of promoting code reuse is usually a good idea.  But in Imaging-356, 
we saw recently that changing legacy code to use an alternate API's can go 
badly wrong.  

 

Now, regarding the idea of bloat, we will never agree.  And I maintain that I 
have a point that cannot be dismissed out-of-hand.  Commons-numbers-fraction is 
only 25.7 K with 7 compiled classes. That's no big deal in a modern computing 
environment.  But, oh yeah, it depends on commons-number-core (25,3 K, 14 
compiled classes).   So now my Configuration Management team, to whom I am 
answerable, has to add two new Jar files to their build.  And adding a 
dependency on commons-numbers will be adding multiple classes that are 
unrelated to what commons-imaging does.  We use a lot of commons APIs, but we 
won't currently use the numbers classes.    

 

Finally, on a less contentious topic, I did want to add that the refactoring of 
the Math project into smaller pieces is an excellent idea and that you guys 
have made an outstanding effort.  Some years back, I went through the mental 
exercise of wondering what would be involved in reorganizing math into separate 
modules (a core including linear algebra? where would combinatorics go? can you 
separate statistics from differential equations? how would you handle complex 
numbers?).   I quickly concluded that it would be a tricky job with a lot 

[jira] [Closed] (GEOMETRY-155) Implement getMidpoint(Vector x)

[Dimitrios Efthymiou (Jira)]

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

Dimitrios Efthymiou closed GEOMETRY-155.

Resolution: Abandoned

> Implement getMidpoint(Vector x)
> ---
>
> Key: GEOMETRY-155
> URL: https://issues.apache.org/jira/browse/GEOMETRY-155
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It takes a vector and returns the point that is in the middle of the vector



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (GEOMETRY-150) implement isCodirectionalWith(Vector y)

[Dimitrios Efthymiou (Jira)]

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

Dimitrios Efthymiou updated GEOMETRY-150:
-
Description: implement isCodirectionalWith(Vector y) method in the Vector 
interface. The isCodirectionalWith() checks if the 2 vectors point at the same 
direction. This means that each vector can be obtained from the other by 
multiplying by a positive scalar.  (was: implement isCodirectionalTo(Vector y) 
method in the Vector interface. The isCodirectionalTo() checks if the 2 vectors 
point at the same direction. This means that each vector can be obtained from 
the other by multiplying by a positive scalar.)

> implement isCodirectionalWith(Vector y)
> ---
>
> Key: GEOMETRY-150
> URL: https://issues.apache.org/jira/browse/GEOMETRY-150
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
> Fix For: 1.1
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> implement isCodirectionalWith(Vector y) method in the Vector interface. The 
> isCodirectionalWith() checks if the 2 vectors point at the same direction. 
> This means that each vector can be obtained from the other by multiplying by 
> a positive scalar.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (GEOMETRY-150) implement isCodirectionalWith(Vector y)

[Dimitrios Efthymiou (Jira)]

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

Dimitrios Efthymiou updated GEOMETRY-150:
-
Summary: implement isCodirectionalWith(Vector y)  (was: implement 
isCodirectionalTo(Vector y))

> implement isCodirectionalWith(Vector y)
> ---
>
> Key: GEOMETRY-150
> URL: https://issues.apache.org/jira/browse/GEOMETRY-150
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
> Fix For: 1.1
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> implement isCodirectionalTo(Vector y) method in the Vector interface. The 
> isCodirectionalTo() checks if the 2 vectors point at the same direction. This 
> means that each vector can be obtained from the other by multiplying by a 
> positive scalar.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)

[Dimitrios Efthymiou (Jira)]

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

Dimitrios Efthymiou closed GEOMETRY-154.

Resolution: Abandoned

> Implement divideVectorWithRatio(Vector x, double ratio)
> ---
>
> Key: GEOMETRY-154
> URL: https://issues.apache.org/jira/browse/GEOMETRY-154
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That 
> will return a pair of vectors v = (3.33) and w = (6.66). Regardless of 
> dimensions, both vectors start at the point of origin



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (EXEC-105) Small mistakes in the documentation for Apache Commons Exec 1.3

[Bernd Eckenfels (Jira)]

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

Bernd Eckenfels resolved EXEC-105.
--
Fix Version/s: 1.4
 Assignee: Gary D. Gregory
   Resolution: Fixed

Remaining issues have been fixed (the other examples have not been reviewed)

> Small mistakes in the documentation for Apache Commons Exec 1.3
> ---
>
> Key: EXEC-105
> URL: https://issues.apache.org/jira/browse/EXEC-105
> Project: Commons Exec
>  Issue Type: Wish
>Affects Versions: 1.3
>Reporter: Ivan Puntev
>Assignee: Gary D. Gregory
>Priority: Trivial
> Fix For: 1.4
>
>
> I want to apologize if this issue is not correctly formatted, but I am new 
> into the issue reporting.
> On this page on the bottom - 
> [http://commons.apache.org/proper/commons-exec/tutorial.html]
> I found wrong code example in "Unblock Your Execution paragraph".
>  
> The "cmdLine" variable later in code changes its name to  "commandLine".
> At the end, this code line -> int exitValue = resultHandler.waitFor();  is 
> wrong because the waitFor() method is void and doesn't return any value.
>  
> In the examples above may also have mistakes but I haven't checked.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (EXEC-105) Small mistakes in the documentation for Apache Commons Exec 1.3

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/EXEC-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743778#comment-17743778
 ] 

Gary D. Gregory commented on EXEC-105:
--

[~b.eckenfels]
OK to resolve this issue now?

> Small mistakes in the documentation for Apache Commons Exec 1.3
> ---
>
> Key: EXEC-105
> URL: https://issues.apache.org/jira/browse/EXEC-105
> Project: Commons Exec
>  Issue Type: Wish
>Affects Versions: 1.3
>Reporter: Ivan Puntev
>Priority: Trivial
>
> I want to apologize if this issue is not correctly formatted, but I am new 
> into the issue reporting.
> On this page on the bottom - 
> [http://commons.apache.org/proper/commons-exec/tutorial.html]
> I found wrong code example in "Unblock Your Execution paragraph".
>  
> The "cmdLine" variable later in code changes its name to  "commandLine".
> At the end, this code line -> int exitValue = resultHandler.waitFor();  is 
> wrong because the waitFor() method is void and doesn't return any value.
>  
> In the examples above may also have mistakes but I haven't checked.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCS-235) Thread leakage in JCS 3.1 with primary and secondary server configuration

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/JCS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743775#comment-17743775
 ] 

Gary D. Gregory commented on JCS-235:
-

Hello [~Amol D]
Thank you for the report.
The fastest way you'll get feedback IMO is if you can provide a test program 
that reproduces the issue. Even better if that can be in the form of a failing 
unit test or integration test. A GitHub PR is a good way to do that since we'll 
see it compile, run, and fail in the CI.

> Thread leakage in JCS 3.1 with primary and secondary server configuration
> -
>
> Key: JCS-235
> URL: https://issues.apache.org/jira/browse/JCS-235
> Project: Commons JCS
>  Issue Type: Bug
>  Components: RMI Remote Cache
>Affects Versions: jcs-3.1
>Reporter: Amol D
>Priority: Major
> Attachments: client-remoet-cache.ccf, primaryserver-remote-cache.ccf, 
> secondaryserver-remote-cache.ccf
>
>
> We are using Apache JCS as a primary cache server in our application. The 
> version we are using is apache-commons-jcs3 3.1. On production environment we 
> have observed that this specific version is having a thread leakage issue 
> where on the production servers, the thread count is increasing rapidly and 
> reaching 2 threads, and the system crashes due to the OutOfMemory error. 
> It is observed while degrading the JCS version from 3.1 to 3.0. The problem 
> is no longer reproducible. With the JCS 3.1 version we have also tried 
> implementing thread pooling, but it did not solve the problem . 
> Steps to reproduce -
> 1) JCS configured to have primary and failover server
> Please refer cache.ccf configurations attached
> Check thread count via command
> ps -o pid,comm,user,thcount -p 
> 2) Restart Primary server
> After certain usage by JCS client check the thread count via below command
> ps -o pid,comm,user,thcount -p 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [commons-pool] garydgregory commented on a diff in pull request #230: Support for loom

[via GitHub]

garydgregory commented on code in PR #230:
URL: https://github.com/apache/commons-pool/pull/230#discussion_r1265218231


##
src/main/java/org/apache/commons/pool2/PooledObject.java:
##
@@ -33,6 +34,8 @@
  */
 public interface PooledObject extends Comparable> {
 
+ReentrantLock lock = new ReentrantLock();

Review Comment:
   Hello @zenghu1chen 
   A mutable global variable in an interface is an anti-pattern IMO, you've not 
addressed this issue in your comment.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (IMAGING-358) "RationalNumber" class is "public"

[Gilles Sadowski (Jira)]

[ 
https://issues.apache.org/jira/browse/IMAGING-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743693#comment-17743693
 ] 

Gilles Sadowski commented on IMAGING-358:
-

bq. It's been two years [...] I recall the differences between the 
implementations in Commons Imaging and Commons Numbers were related to the way 
the two classes treated 32-bit unsigned integers

I asked the same question at the time.  The initial answer was also about some 
suspected special thing about a "TIFF fraction"; it might be case, but when I 
suggested to investigate, the eventual answer morphed into the unrelated "no 
dependency" mantra.

bq. I think the question is a bit disingenuous.

Because we don't agree about what "bloat" is does not need to bring snark in 
the conversation.

bq. Commons Imaging started with no external dependencies except the Java 
standard API.  If we were to add a dependency to another library, and then that 
library added dependencies of its own, we would have bloat.

As stated already, this is all within "Commons"; (potential) issues related to 
dependencies are under our control.
The main (only?) rationale for "Commons" components to not have _external_ 
dependencies was to avoid the risk of JAR hell.

"Bloat" is orthogonal to "having dependencies".
I also don't like "bloat" (in the sense of "risk brought by redundancy"); I 
believe that code reuse is more important than "having no dependencies".

One kind of "bloat" is nicely illustrated by "Commons" having at least 3 
components implement a "fraction" (with varying degrees of flexibility, 
performance, and robustness):
* [Imaging]
* [Lang]
* [Numbers] (originally in [Math])

The purpose of a *modular* [Numbers] was to solve the bloat which [Math] had 
become, here in the sense that (before the spin-off), in order to use a small, 
common, functionality like "fraction", you indeed had to depend on a library 
with more than 300K lines of code.  With [Numbers], you get the functionality 
in less than 2K lines.


> "RationalNumber" class is "public"
> --
>
> Key: IMAGING-358
> URL: https://issues.apache.org/jira/browse/IMAGING-358
> Project: Commons Imaging
>  Issue Type: Wish
>  Components: imaging.common.*
>Affects Versions: 1.0-alpha2
>Reporter: Gilles Sadowski
>Priority: Major
>  Labels: API, support
> Fix For: 1.0, 1.0-alpha3
>
>
> As per its Javadoc, class 
> [{{RationalNumber}}|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/common/RationalNumber.html]
>  is tuned to the requirements of the TIFF format while its name purports that 
> it's a general implementation of the "fraction" concept.
> Which is it?
> Do we want that utility to be part of [Imaging]'s public API (thus eliciting 
> support to application developers who might use it beyond its intended scope)?
> A dependency on [[Numbers]'s "fraction" 
> module|https://commons.apache.org/proper/commons-numbers/commons-numbers-docs/apidocs/org/apache/commons/numbers/fraction/package-summary.html],
>  as proposed in IMAGING-309) would avoid the issue, and also consolidate 
> (and/or help find potential bugs in) [Numbers]'s implementation.
> If that proposal is not accepted, {{RationalNumber}} should preferably be 
> moved to [Imaging]'s [{{internal}} 
> package|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/internal/package-summary.html].



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCS-235) Thread leakage in JCS 3.1 with primary and secondary server configuration

[Amol D (Jira)]

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

Amol D updated JCS-235:
---
Description: 
We are using Apache JCS as a primary cache server in our application. The 
version we are using is apache-commons-jcs3 3.1. On production environment we 
have observed that this specific version is having a thread leakage issue where 
on the production servers, the thread count is increasing rapidly and reaching 
2 threads, and the system crashes due to the OutOfMemory error. It is 
observed while degrading the JCS version from 3.1 to 3.0. The problem is no 
longer reproducible. With the JCS 3.1 version we have also tried implementing 
thread pooling, but it did not solve the problem . 

Steps to reproduce -

1) JCS configured to have primary and failover server

Please refer cache.ccf configurations attached

Check thread count via command

ps -o pid,comm,user,thcount -p 

2) Restart Primary server

After certain usage by JCS client check the thread count via below command

ps -o pid,comm,user,thcount -p 

 

  was:
We are using Apache JCS as a primary cache server in our application. The 
version we are using is apache-commons-jcs3 3.1. On production environment we 
have observed that this specific version is having a thread leakage issue where 
on the production servers, the thread count is increasing rapidly and reaching 
2 threads, and the system crashes due to the OutOfMemory error. It is 
observed while degrading the JCS version from 3.1 to 3.0. The problem is no 
longer reproducible. With the JCS 3.1 version we have also tried implementing 
thread pooling, but it did not solve the problem . We request Apache community 
to triage the issue.

Steps to reproduce -

1) JCS configured to have primary and failover server 

Please refer cache.ccf configurations attached 

Check thread count via command 

ps -o pid,comm,user,thcount -p 

2) Restart Primary server 

After certain usage by JCS client check the thread count via below command 

ps -o pid,comm,user,thcount -p 

 


> Thread leakage in JCS 3.1 with primary and secondary server configuration
> -
>
> Key: JCS-235
> URL: https://issues.apache.org/jira/browse/JCS-235
> Project: Commons JCS
>  Issue Type: Bug
>  Components: RMI Remote Cache
>Affects Versions: jcs-3.1
>Reporter: Amol D
>Priority: Major
> Attachments: client-remoet-cache.ccf, primaryserver-remote-cache.ccf, 
> secondaryserver-remote-cache.ccf
>
>
> We are using Apache JCS as a primary cache server in our application. The 
> version we are using is apache-commons-jcs3 3.1. On production environment we 
> have observed that this specific version is having a thread leakage issue 
> where on the production servers, the thread count is increasing rapidly and 
> reaching 2 threads, and the system crashes due to the OutOfMemory error. 
> It is observed while degrading the JCS version from 3.1 to 3.0. The problem 
> is no longer reproducible. With the JCS 3.1 version we have also tried 
> implementing thread pooling, but it did not solve the problem . 
> Steps to reproduce -
> 1) JCS configured to have primary and failover server
> Please refer cache.ccf configurations attached
> Check thread count via command
> ps -o pid,comm,user,thcount -p 
> 2) Restart Primary server
> After certain usage by JCS client check the thread count via below command
> ps -o pid,comm,user,thcount -p 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (JCS-235) Thread leakage in JCS 3.1 with primary and secondary server configuration

[Amol D (Jira)]

Amol D created JCS-235:
--

 Summary: Thread leakage in JCS 3.1 with primary and secondary 
server configuration
 Key: JCS-235
 URL: https://issues.apache.org/jira/browse/JCS-235
 Project: Commons JCS
  Issue Type: Bug
  Components: RMI Remote Cache
Affects Versions: jcs-3.1
Reporter: Amol D
 Attachments: client-remoet-cache.ccf, primaryserver-remote-cache.ccf, 
secondaryserver-remote-cache.ccf

We are using Apache JCS as a primary cache server in our application. The 
version we are using is apache-commons-jcs3 3.1. On production environment we 
have observed that this specific version is having a thread leakage issue where 
on the production servers, the thread count is increasing rapidly and reaching 
2 threads, and the system crashes due to the OutOfMemory error. It is 
observed while degrading the JCS version from 3.1 to 3.0. The problem is no 
longer reproducible. With the JCS 3.1 version we have also tried implementing 
thread pooling, but it did not solve the problem . We request Apache community 
to triage the issue.

Steps to reproduce -

1) JCS configured to have primary and failover server 

Please refer cache.ccf configurations attached 

Check thread count via command 

ps -o pid,comm,user,thcount -p 

2) Restart Primary server 

After certain usage by JCS client check the thread count via below command 

ps -o pid,comm,user,thcount -p 

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [commons-pool] zenghu1chen commented on pull request #230: Support for loom

[via GitHub]

zenghu1chen commented on PR #230:
URL: https://github.com/apache/commons-pool/pull/230#issuecomment-1637476815

   > @zenghu1chen Thank you for the PR. Please see the build failure and update 
the PR. There are no unit tests here, I'd really like to see a test that can 
demonstrate a dead lock in order to prove that the changes actually fix an 
issue rather than relying on some external empirical evidence. The test need 
not use Redis for example but be built in whatever way effectively causes a 
test to fail or hang. CC: @psteitz
   
   I'm trying to write test cases to reproduce the deadlock situation. Please 
wait for a while, thank you.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-pool] zenghu1chen commented on a diff in pull request #230: Support for loom

[via GitHub]

zenghu1chen commented on code in PR #230:
URL: https://github.com/apache/commons-pool/pull/230#discussion_r1264935217


##
src/main/java/org/apache/commons/pool2/PooledObject.java:
##
@@ -33,6 +34,8 @@
  */
 public interface PooledObject extends Comparable> {
 
+ReentrantLock lock = new ReentrantLock();

Review Comment:
   This lock is to replace synchronized(PooledObject) with ReentrantLock in the 
GenericObjectPool,BaseGenericObjectPool and GenericKeyedObjectPool class.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org