[GitHub] [commons-vfs] boris-petrov commented on issue #30: VFS-614 MonitorInputStream should not close the stream in "read"
boris-petrov commented on issue #30: VFS-614 MonitorInputStream should not close the stream in "read" URL: https://github.com/apache/commons-vfs/pull/30#issuecomment-503410665 @jclx, @garydgregory - this was actually [fixed a couple of hours ago](https://github.com/apache/commons-vfs/pull/67). @garydgregory - do you mind looking at/merging the [other PR I made](https://github.com/apache/commons-vfs/pull/66) and creating a new snapshot with the latest fixes please? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (RNG-99) AliasMethodDiscreteSampler
[
https://issues.apache.org/jira/browse/RNG-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867121#comment-16867121
]
Alex D Herbert commented on RNG-99:
---
The Alias method consists of two steps:
* Pick a random index into the tables. Uses an {{int}} sample from
{{nextInt(int)}}.
* Choose between the original sample value or its alias using a random
deviate. Uses a {{double}} sample.
Total number of bits using a standard generator is at least 96-bits: a 32-bit
int and then 64-bits to create a double. Only 53-bits are required to create
the double. Note: I say at least 96-bits because a rejection algorithm is used
to create the {{int}} index using {{nextInt(int)}}. So it is possible that more
than 1 {{int}} sample is used to create the index.
If the size of the table is small (<= 2^11 or 2048) and a power of 2 then the
two samples can be done using 64-bits: Up to 11-bits to obtain the {{int}}
sample and the remaining 53-bits for the {{double}}.
So there is an optimisation where the input probability distribution can be
padded with zeros so that it is a power of 2. In this case any sample with zero
probability is not possible. However the alias tables will still be computed
and the method still works.
So if the distribution size is small (<=2048) then only 64-bits are required.
If larger but still a power of 2 then 96-bits is used. Only when the number of
possible samples is above 2^30 can padding not be done.
The only disadvantage is storage. The method stores 12-bits per tabulated
probability. However when padding to a power of 2 the extra probability table
is not required (it is always zero) and so storage is only the alias. This is
4-bits per padded probability.
So to keep the options open (for those where storage is more important) a
factory method could be provided to pad the probabilities:
{code:java}
public class AliasMethodDiscreteSampler implements DiscreteSampler {
public AliasMethodDiscreteSampler(UniformRandomProvider rng,
double[] probabilities) {
// Validate probabilities sum to >0
// Construct alias tables
// Detect power of 2 tables
}
public AliasMethodDiscreteSampler create(UniformRandomProvider rng,
double[] probabilities) {
// Pad probabilities to next power of 2
// Call constructor
}
@Override
public int sample() {
// Sample from alias tables
// (Optimise for power of 2 tables)
}
}
{code}
The alternative is to always pad in the constructor if possible, removing the
choice from the user.
> AliasMethodDiscreteSampler
> --
>
> Key: RNG-99
> URL: https://issues.apache.org/jira/browse/RNG-99
> Project: Commons RNG
> Issue Type: New Feature
> Components: sampling
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Minor
> Fix For: 1.3
>
>
> From Wikipedia:
> [Alias Method|https://en.wikipedia.org/wiki/Alias_method]
> {noformat}
> In computing, the alias method is a family of efficient algorithms for
> sampling from
> a discrete probability distribution, due to A. J. Walker. That is, it returns
> integer
> values 1 ≤ i ≤ n according to some arbitrary probability distribution. The
> algorithms
> typically use O(n log n) or O(n) preprocessing time, after which random
> values can
> be drawn from the distribution in O(1) time.
> {noformat}
> Create a sampler using the Alias method:
> {code:java}
> package org.apache.commons.rng.sampling.distribution;
> public class AliasMethodDiscreteSampler implements DiscreteSampler {
> public AliasMethodDiscreteSampler(UniformRandomProvider rng,
> double[] probabilities) {
> // Validate probabilities sum to >0
> // Construct alias tables
> }
> @Override
> public int sample() {
> // Sample from alias tables
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-vfs] jclx commented on issue #30: VFS-614 MonitorInputStream should not close the stream in "read"
jclx commented on issue #30: VFS-614 MonitorInputStream should not close the
stream in "read"
URL: https://github.com/apache/commons-vfs/pull/30#issuecomment-503345452
just need to remove the close() from the 'public int read()' method. I have
not created an account to create a jira issue yet. VFS 2.3 won't work for us
with this bug as we use marking / reset a lot.
A simple test case converting the one in the pr to call 'int read()' instead.
`public void testMarkingWhenReadEOS() throws Exception
{
File temp = File.createTempFile("temp-file-name", ".tmp");
FileSystemManager fileSystemManager = VFS.getManager();
try (FileObject file =
fileSystemManager.resolveFile(temp.getAbsolutePath()))
{
try (OutputStream outputStream =
file.getContent().getOutputStream())
{
outputStream.write(expected.getBytes());
outputStream.flush();
}
try (InputStream stream =
file.getContent().getInputStream())
{
if (stream.markSupported())
{
for (int i = 0; i < 10; i++)
{
stream.mark(0);
byte[] data = new byte[100];
int readCount = 0;
int bt = 0;
while ((bt = stream.read()) !=
-1)
{
data[readCount] =
(byte) bt;
readCount++;
}
Assert.assertEquals(readCount,
7);
Assert.assertEquals(expected,
new String(data).trim());
Assert.assertEquals(bt, -1);
stream.reset();
}
}
}
}
}
`
yields this exception:
Exception in thread "main" java.io.IOException: Stream closed
at
java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:170)
at java.io.BufferedInputStream.reset(BufferedInputStream.java:446)
at Tester.testMarkingWhenReadEOS(Tester.java:123)
at Tester.main(Tester.java:25)
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Closed] (NUMBERS-117) Redundant methods in several TestUtils classes
[
https://issues.apache.org/jira/browse/NUMBERS-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Heinrich Bohne closed NUMBERS-117.
--
Resolution: Fixed
> Redundant methods in several TestUtils classes
> --
>
> Key: NUMBERS-117
> URL: https://issues.apache.org/jira/browse/NUMBERS-117
> Project: Commons Numbers
> Issue Type: Improvement
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following methods from the class {{TestUtils}} in the module
> _commons-numbers-core_ are redundant:
> |{{assertEquals(double, double, double)}}|{{Assertions.assertEquals(double,
> double, double)}} already considers two {{NaN}} values equal, so the two
> methods are equivalent.|
> |{{assertEquals(String, double, double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double, double, String)}}, as explained
> above|
> |{{assertSame(double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double)}}|
> |{{assertEquals(double[], double[], double)}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[], double)}}|
> |{{assertEquals(String, double[], double[], double)}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[], double, String)}}|
> |{{assertEquals(String, float[], float[], float)}}|Equivalent to
> {{Assertions.assertArrayEquals(float[], float[], float, String)}}|
> Similarly, the following methods from the class {{TestUtils}} in the module
> _commons-numbers-complex-streams_ are redundant:
> |{{assertEquals(double, double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double, double)}}, as explained above|
> |{{assertEquals(String, double, double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double, double, String)}}, as explained
> above|
> |{{assertSame(double[], double[])}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[])}}|
> |{{assertSame(float[], float[])}}|Equivalent to
> {{Assertions.assertArrayEquals(float[], float[])}}|
> |{{assertSame(double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double)}}|
> |{{assertEquals(String, double[], double[], double)}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[], double, String)}}|
> |{{assertEquals(String, float[], float[], float)}}|Equivalent to
> {{Assertions.assertArrayEquals(float[], float[], float, String)}}|
> |{{equalsIncludingNaN(double, double, double)}}|Equivalent to
> {{Precision.equalsIncludingNaN(double, double, double)}}|
> Finally, the following methods from the class {{TestUtils}} in the module
> _commons-numbers-complex_ are redundant:
> |{{assertEquals(double, double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double, double)}}, as explained above|
> |{{assertEquals(String, double, double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double, double, String)}}, as explained
> above|
> |{{assertSame(double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double)}}|
> |{{assertEquals(double[], double[], double)}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[], double)}}|
> |{{assertEquals(String, double[], double[], double)}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[], double, String)}}|
> |{{assertEquals(String, float[], float[], float)}}|Equivalent to
> {{Assertions.assertArrayEquals(float[], float[], float, String)}}|
> |{{equalsIncludingNaN(double, double, double)}}|Equivalent to
> {{Precision.equalsIncludingNaN(double, double, double)}}|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-117) Redundant methods in several TestUtils classes
[
https://issues.apache.org/jira/browse/NUMBERS-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867116#comment-16867116
]
Gilles commented on NUMBERS-117:
Commit 44cdefe8ca22cc3151e32eb956324ed535f5a2e7 in "master".
> Redundant methods in several TestUtils classes
> --
>
> Key: NUMBERS-117
> URL: https://issues.apache.org/jira/browse/NUMBERS-117
> Project: Commons Numbers
> Issue Type: Improvement
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following methods from the class {{TestUtils}} in the module
> _commons-numbers-core_ are redundant:
> |{{assertEquals(double, double, double)}}|{{Assertions.assertEquals(double,
> double, double)}} already considers two {{NaN}} values equal, so the two
> methods are equivalent.|
> |{{assertEquals(String, double, double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double, double, String)}}, as explained
> above|
> |{{assertSame(double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double)}}|
> |{{assertEquals(double[], double[], double)}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[], double)}}|
> |{{assertEquals(String, double[], double[], double)}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[], double, String)}}|
> |{{assertEquals(String, float[], float[], float)}}|Equivalent to
> {{Assertions.assertArrayEquals(float[], float[], float, String)}}|
> Similarly, the following methods from the class {{TestUtils}} in the module
> _commons-numbers-complex-streams_ are redundant:
> |{{assertEquals(double, double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double, double)}}, as explained above|
> |{{assertEquals(String, double, double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double, double, String)}}, as explained
> above|
> |{{assertSame(double[], double[])}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[])}}|
> |{{assertSame(float[], float[])}}|Equivalent to
> {{Assertions.assertArrayEquals(float[], float[])}}|
> |{{assertSame(double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double)}}|
> |{{assertEquals(String, double[], double[], double)}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[], double, String)}}|
> |{{assertEquals(String, float[], float[], float)}}|Equivalent to
> {{Assertions.assertArrayEquals(float[], float[], float, String)}}|
> |{{equalsIncludingNaN(double, double, double)}}|Equivalent to
> {{Precision.equalsIncludingNaN(double, double, double)}}|
> Finally, the following methods from the class {{TestUtils}} in the module
> _commons-numbers-complex_ are redundant:
> |{{assertEquals(double, double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double, double)}}, as explained above|
> |{{assertEquals(String, double, double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double, double, String)}}, as explained
> above|
> |{{assertSame(double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double)}}|
> |{{assertEquals(double[], double[], double)}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[], double)}}|
> |{{assertEquals(String, double[], double[], double)}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[], double, String)}}|
> |{{assertEquals(String, float[], float[], float)}}|Equivalent to
> {{Assertions.assertArrayEquals(float[], float[], float, String)}}|
> |{{equalsIncludingNaN(double, double, double)}}|Equivalent to
> {{Precision.equalsIncludingNaN(double, double, double)}}|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (NUMBERS-117) Redundant methods in several TestUtils classes
[
https://issues.apache.org/jira/browse/NUMBERS-117?focusedWorklogId=262667&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-262667
]
ASF GitHub Bot logged work on NUMBERS-117:
--
Author: ASF GitHub Bot
Created on: 18/Jun/19 23:02
Start Date: 18/Jun/19 23:02
Worklog Time Spent: 10m
Work Description: asfgit commented on pull request #53: [NUMBERS-117]
Remove redundant TestUtils methods
URL: https://github.com/apache/commons-numbers/pull/53
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 262667)
Time Spent: 20m (was: 10m)
> Redundant methods in several TestUtils classes
> --
>
> Key: NUMBERS-117
> URL: https://issues.apache.org/jira/browse/NUMBERS-117
> Project: Commons Numbers
> Issue Type: Improvement
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following methods from the class {{TestUtils}} in the module
> _commons-numbers-core_ are redundant:
> |{{assertEquals(double, double, double)}}|{{Assertions.assertEquals(double,
> double, double)}} already considers two {{NaN}} values equal, so the two
> methods are equivalent.|
> |{{assertEquals(String, double, double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double, double, String)}}, as explained
> above|
> |{{assertSame(double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double)}}|
> |{{assertEquals(double[], double[], double)}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[], double)}}|
> |{{assertEquals(String, double[], double[], double)}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[], double, String)}}|
> |{{assertEquals(String, float[], float[], float)}}|Equivalent to
> {{Assertions.assertArrayEquals(float[], float[], float, String)}}|
> Similarly, the following methods from the class {{TestUtils}} in the module
> _commons-numbers-complex-streams_ are redundant:
> |{{assertEquals(double, double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double, double)}}, as explained above|
> |{{assertEquals(String, double, double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double, double, String)}}, as explained
> above|
> |{{assertSame(double[], double[])}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[])}}|
> |{{assertSame(float[], float[])}}|Equivalent to
> {{Assertions.assertArrayEquals(float[], float[])}}|
> |{{assertSame(double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double)}}|
> |{{assertEquals(String, double[], double[], double)}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[], double, String)}}|
> |{{assertEquals(String, float[], float[], float)}}|Equivalent to
> {{Assertions.assertArrayEquals(float[], float[], float, String)}}|
> |{{equalsIncludingNaN(double, double, double)}}|Equivalent to
> {{Precision.equalsIncludingNaN(double, double, double)}}|
> Finally, the following methods from the class {{TestUtils}} in the module
> _commons-numbers-complex_ are redundant:
> |{{assertEquals(double, double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double, double)}}, as explained above|
> |{{assertEquals(String, double, double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double, double, String)}}, as explained
> above|
> |{{assertSame(double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double)}}|
> |{{assertEquals(double[], double[], double)}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[], double)}}|
> |{{assertEquals(String, double[], double[], double)}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[], double, String)}}|
> |{{assertEquals(String, float[], float[], float)}}|Equivalent to
> {{Assertions.assertArrayEquals(float[], float[], float, String)}}|
> |{{equalsIncludingNaN(double, double, double)}}|Equivalent to
> {{Precision.equalsIncludingNaN(double, double, double)}}|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-numbers] asfgit merged pull request #53: [NUMBERS-117] Remove redundant TestUtils methods
asfgit merged pull request #53: [NUMBERS-117] Remove redundant TestUtils methods URL: https://github.com/apache/commons-numbers/pull/53 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] garydgregory commented on issue #30: VFS-614 MonitorInputStream should not close the stream in "read"
garydgregory commented on issue #30: VFS-614 MonitorInputStream should not close the stream in "read" URL: https://github.com/apache/commons-vfs/pull/30#issuecomment-503337977 Patches with tests are welcome; -) 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (NUMBERS-117) Redundant methods in several TestUtils classes
[
https://issues.apache.org/jira/browse/NUMBERS-117?focusedWorklogId=262651&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-262651
]
ASF GitHub Bot logged work on NUMBERS-117:
--
Author: ASF GitHub Bot
Created on: 18/Jun/19 22:09
Start Date: 18/Jun/19 22:09
Worklog Time Spent: 10m
Work Description: Schamschi commented on pull request #53: [NUMBERS-117]
Remove redundant TestUtils methods
URL: https://github.com/apache/commons-numbers/pull/53
This pull request does _not_ conflict with [PR
#52](https://github.com/apache/commons-numbers/pull/52).
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 262651)
Time Spent: 10m
Remaining Estimate: 0h
> Redundant methods in several TestUtils classes
> --
>
> Key: NUMBERS-117
> URL: https://issues.apache.org/jira/browse/NUMBERS-117
> Project: Commons Numbers
> Issue Type: Improvement
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following methods from the class {{TestUtils}} in the module
> _commons-numbers-core_ are redundant:
> |{{assertEquals(double, double, double)}}|{{Assertions.assertEquals(double,
> double, double)}} already considers two {{NaN}} values equal, so the two
> methods are equivalent.|
> |{{assertEquals(String, double, double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double, double, String)}}, as explained
> above|
> |{{assertSame(double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double)}}|
> |{{assertEquals(double[], double[], double)}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[], double)}}|
> |{{assertEquals(String, double[], double[], double)}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[], double, String)}}|
> |{{assertEquals(String, float[], float[], float)}}|Equivalent to
> {{Assertions.assertArrayEquals(float[], float[], float, String)}}|
> Similarly, the following methods from the class {{TestUtils}} in the module
> _commons-numbers-complex-streams_ are redundant:
> |{{assertEquals(double, double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double, double)}}, as explained above|
> |{{assertEquals(String, double, double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double, double, String)}}, as explained
> above|
> |{{assertSame(double[], double[])}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[])}}|
> |{{assertSame(float[], float[])}}|Equivalent to
> {{Assertions.assertArrayEquals(float[], float[])}}|
> |{{assertSame(double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double)}}|
> |{{assertEquals(String, double[], double[], double)}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[], double, String)}}|
> |{{assertEquals(String, float[], float[], float)}}|Equivalent to
> {{Assertions.assertArrayEquals(float[], float[], float, String)}}|
> |{{equalsIncludingNaN(double, double, double)}}|Equivalent to
> {{Precision.equalsIncludingNaN(double, double, double)}}|
> Finally, the following methods from the class {{TestUtils}} in the module
> _commons-numbers-complex_ are redundant:
> |{{assertEquals(double, double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double, double)}}, as explained above|
> |{{assertEquals(String, double, double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double, double, String)}}, as explained
> above|
> |{{assertSame(double, double)}}|Equivalent to
> {{Assertions.assertEquals(double, double)}}|
> |{{assertEquals(double[], double[], double)}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[], double)}}|
> |{{assertEquals(String, double[], double[], double)}}|Equivalent to
> {{Assertions.assertArrayEquals(double[], double[], double, String)}}|
> |{{assertEquals(String, float[], float[], float)}}|Equivalent to
> {{Assertions.assertArrayEquals(float[], float[], float, String)}}|
> |{{equalsIncludingNaN(double, double, double)}}|Equivalent to
> {{Precision.equalsIncludingNaN(double, double, double)}}|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-numbers] Schamschi opened a new pull request #53: [NUMBERS-117] Remove redundant TestUtils methods
Schamschi opened a new pull request #53: [NUMBERS-117] Remove redundant TestUtils methods URL: https://github.com/apache/commons-numbers/pull/53 This pull request does _not_ conflict with [PR #52](https://github.com/apache/commons-numbers/pull/52). 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (NUMBERS-117) Redundant methods in several TestUtils classes
Heinrich Bohne created NUMBERS-117:
--
Summary: Redundant methods in several TestUtils classes
Key: NUMBERS-117
URL: https://issues.apache.org/jira/browse/NUMBERS-117
Project: Commons Numbers
Issue Type: Improvement
Reporter: Heinrich Bohne
The following methods from the class {{TestUtils}} in the module
_commons-numbers-core_ are redundant:
|{{assertEquals(double, double, double)}}|{{Assertions.assertEquals(double,
double, double)}} already considers two {{NaN}} values equal, so the two
methods are equivalent.|
|{{assertEquals(String, double, double, double)}}|Equivalent to
{{Assertions.assertEquals(double, double, double, String)}}, as explained above|
|{{assertSame(double, double)}}|Equivalent to {{Assertions.assertEquals(double,
double)}}|
|{{assertEquals(double[], double[], double)}}|Equivalent to
{{Assertions.assertArrayEquals(double[], double[], double)}}|
|{{assertEquals(String, double[], double[], double)}}|Equivalent to
{{Assertions.assertArrayEquals(double[], double[], double, String)}}|
|{{assertEquals(String, float[], float[], float)}}|Equivalent to
{{Assertions.assertArrayEquals(float[], float[], float, String)}}|
Similarly, the following methods from the class {{TestUtils}} in the module
_commons-numbers-complex-streams_ are redundant:
|{{assertEquals(double, double, double)}}|Equivalent to
{{Assertions.assertEquals(double, double, double)}}, as explained above|
|{{assertEquals(String, double, double, double)}}|Equivalent to
{{Assertions.assertEquals(double, double, double, String)}}, as explained above|
|{{assertSame(double[], double[])}}|Equivalent to
{{Assertions.assertArrayEquals(double[], double[])}}|
|{{assertSame(float[], float[])}}|Equivalent to
{{Assertions.assertArrayEquals(float[], float[])}}|
|{{assertSame(double, double)}}|Equivalent to {{Assertions.assertEquals(double,
double)}}|
|{{assertEquals(String, double[], double[], double)}}|Equivalent to
{{Assertions.assertArrayEquals(double[], double[], double, String)}}|
|{{assertEquals(String, float[], float[], float)}}|Equivalent to
{{Assertions.assertArrayEquals(float[], float[], float, String)}}|
|{{equalsIncludingNaN(double, double, double)}}|Equivalent to
{{Precision.equalsIncludingNaN(double, double, double)}}|
Finally, the following methods from the class {{TestUtils}} in the module
_commons-numbers-complex_ are redundant:
|{{assertEquals(double, double, double)}}|Equivalent to
{{Assertions.assertEquals(double, double, double)}}, as explained above|
|{{assertEquals(String, double, double, double)}}|Equivalent to
{{Assertions.assertEquals(double, double, double, String)}}, as explained above|
|{{assertSame(double, double)}}|Equivalent to {{Assertions.assertEquals(double,
double)}}|
|{{assertEquals(double[], double[], double)}}|Equivalent to
{{Assertions.assertArrayEquals(double[], double[], double)}}|
|{{assertEquals(String, double[], double[], double)}}|Equivalent to
{{Assertions.assertArrayEquals(double[], double[], double, String)}}|
|{{assertEquals(String, float[], float[], float)}}|Equivalent to
{{Assertions.assertArrayEquals(float[], float[], float, String)}}|
|{{equalsIncludingNaN(double, double, double)}}|Equivalent to
{{Precision.equalsIncludingNaN(double, double, double)}}|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (RNG-100) GuideTableDiscreteSampler
[
https://issues.apache.org/jira/browse/RNG-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex D Herbert resolved RNG-100.
Resolution: Implemented
In master.
> GuideTableDiscreteSampler
> -
>
> Key: RNG-100
> URL: https://issues.apache.org/jira/browse/RNG-100
> Project: Commons RNG
> Issue Type: New Feature
> Components: sampling
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Minor
> Fix For: 1.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> From
> {noformat}
> Devroye, Luc (1986). Non-Uniform Random Variate Generation.
> New York: Springer-Verlag. Chapter 3.2.4 "The method of guide tables" p. 96.
> {noformat}
> [Chapter 3|http://luc.devroye.org/chapter_three.pdf] from the author's
> website.
> The method divides the range for the cumulative probability table of {{K}}
> values into {{alpha * K}} equispaced intervals. Each interval i contains the
> maximum sample value where the cumulative probability is less than i /
> table.length.
> Given a uniform deviate u in the range [0, 1] the guide can be obtained using
> floor(u * table.length). This guide value is the start point for search of
> the cumulative probability table. The number of comparisons of the uniform
> deviate within the cumulative probability table is upper bounded by 2 (see
> Devroye, p97) making the search very efficient.
> Create a sampler using the Guide table method:
> {code:java}
> package org.apache.commons.rng.sampling.distribution;
> public class GuideTableDiscreteSampler implements DiscreteSampler {
> public GuideTableDiscreteSampler(UniformRandomProvider rng,
> double[] probabilities,
> double alpha) {
> // Validate probabilities sum to >0
> // Construct cumulative probability table
> // Construct guide table
> }
> @Override
> public int sample() {
> // Look-up sample value in guide table
> // Search cumulative probability table
> }
> }
> {code}
> The alpha value is not required. However large alpha increase the size of the
> guide table and improve performance at the cost of storage.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (STATISTICS-19) Migrate to JUnit 5
[ https://issues.apache.org/jira/browse/STATISTICS-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex D Herbert resolved STATISTICS-19. -- Resolution: Done In master. > Migrate to JUnit 5 > -- > > Key: STATISTICS-19 > URL: https://issues.apache.org/jira/browse/STATISTICS-19 > Project: Apache Commons Statistics > Issue Type: Task > Components: distribution >Reporter: Alex D Herbert >Priority: Minor > > Upgrade JUnit 4 to 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-statistics] asfgit merged pull request #16: Upgrade junit5
asfgit merged pull request #16: Upgrade junit5 URL: https://github.com/apache/commons-statistics/pull/16 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-rng] asfgit merged pull request #52: RNG-100: Add a GuideTableDiscreteSampler.
asfgit merged pull request #52: RNG-100: Add a GuideTableDiscreteSampler. URL: https://github.com/apache/commons-rng/pull/52 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] jclx commented on issue #30: VFS-614 MonitorInputStream should not close the stream in "read"
jclx commented on issue #30: VFS-614 MonitorInputStream should not close the stream in "read" URL: https://github.com/apache/commons-vfs/pull/30#issuecomment-503310095 What about fixing the public int read() throws IOException method too? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (STATISTICS-19) Migrate to JUnit 5
Alex D Herbert created STATISTICS-19: Summary: Migrate to JUnit 5 Key: STATISTICS-19 URL: https://issues.apache.org/jira/browse/STATISTICS-19 Project: Apache Commons Statistics Issue Type: Task Components: distribution Reporter: Alex D Herbert Upgrade JUnit 4 to 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CODEC-166) Base64 could be faster
[
https://issues.apache.org/jira/browse/CODEC-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb closed CODEC-166.
--
Resolution: Won't Fix
> Base64 could be faster
> --
>
> Key: CODEC-166
> URL: https://issues.apache.org/jira/browse/CODEC-166
> Project: Commons Codec
> Issue Type: Wish
>Affects Versions: 1.7
>Reporter: Julius Davies
>Assignee: Julius Davies
>Priority: Major
> Fix For: 2.0
>
> Attachments: CODEC-166.patch, CODEC-166_speed.patch, base64bench.zip
>
>
> Our Base64 consistently performs 3 times slower compared to MiGBase64 and
> iHarder in the byte[] and String encode() methods.
> We are pretty good on decode(), though a little slower (approx. 33% slower)
> than MiGBase64.
> We always win in the Streaming methods (MiGBase64 doesn't do streaming).
> Yay! :-) :-) :-)
> I put together a benchmark. Here's a typical run:
> {noformat}
> LARGE DATA new byte[12345]
> iHarder...
> encode 486.0 MB/sdecode 158.0 MB/s
> encode 491.0 MB/sdecode 148.0 MB/s
> MiGBase64...
> encode 499.0 MB/sdecode 222.0 MB/s
> encode 493.0 MB/sdecode 226.0 MB/s
> Apache Commons Codec...
> encode 142.0 MB/sdecode 146.0 MB/s
> encode 138.0 MB/sdecode 150.0 MB/s
> {noformat}
> I believe the main approach we can consider to improve performance is to
> avoid array copies at all costs. MiGBase64 even counts the number of valid
> Base64 characters ahead of time on decode() to precalculate the result's size
> and avoid any array copying!
> I suspect this will mean writing out separate execution paths for the String
> and byte[] methods, and keeping them out of the streaming logic, since the
> streaming logic is founded on array copy.
> Unfortunately this means we will diminish internal reuse of the streaming
> implementation, but I think it's the only way to improve performance, if we
> want to.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CODEC-255) ColognePhonetic handles x incorrectly
[ https://issues.apache.org/jira/browse/CODEC-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CODEC-255. Resolution: Fixed 7972242 CODEC-255 ColognePhonetic handles x incorrectly > ColognePhonetic handles x incorrectly > - > > Key: CODEC-255 > URL: https://issues.apache.org/jira/browse/CODEC-255 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.12 >Reporter: Holger Grote >Priority: Major > > In the ColognePhonetic the letter x is coded as 48. This is solved in the > implementation in adding a 's' in the string. > With this a string 'xch' ist coded as 48 instead of the correct 484. > A solution is to store the added 'S' in the next loop not in the lastChar. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CODEC-255) ColognePhonetic handles x incorrectly
[ https://issues.apache.org/jira/browse/CODEC-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16866976#comment-16866976 ] Sebb commented on CODEC-255: Agreed. Using an 'S' to force the '8' digit looks like a clever idea, however this does not work when the next letter is a C. > ColognePhonetic handles x incorrectly > - > > Key: CODEC-255 > URL: https://issues.apache.org/jira/browse/CODEC-255 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.12 >Reporter: Holger Grote >Priority: Major > > In the ColognePhonetic the letter x is coded as 48. This is solved in the > implementation in adding a 's' in the string. > With this a string 'xch' ist coded as 48 instead of the correct 484. > A solution is to store the added 'S' in the next loop not in the lastChar. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-daemon] markt-asf commented on issue #3: DAEMON-369: Fixing general stuff around processes, test and quality of code.
markt-asf commented on issue #3: DAEMON-369: Fixing general stuff around processes, test and quality of code. URL: https://github.com/apache/commons-daemon/pull/3#issuecomment-503257155 This PR has been open for almost 2 years since feedback was requested without the requested changes being made. I am therefore closing this. If you wish to pursue these changes I'd recommend tackling one issue at a time - each in its own 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-daemon] markt-asf closed pull request #3: DAEMON-369: Fixing general stuff around processes, test and quality of code.
markt-asf closed pull request #3: DAEMON-369: Fixing general stuff around processes, test and quality of code. URL: https://github.com/apache/commons-daemon/pull/3 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (CODEC-255) ColognePhonetic handles x incorrectly
[ https://issues.apache.org/jira/browse/CODEC-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CODEC-255: --- Summary: ColognePhonetic handles x incorrectly (was: ColognePhonetic handles x incorrect) > ColognePhonetic handles x incorrectly > - > > Key: CODEC-255 > URL: https://issues.apache.org/jira/browse/CODEC-255 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.12 >Reporter: Holger Grote >Priority: Major > > In the ColognePhonetic the letter x is coded as 48. This is solved in the > implementation in adding a 's' in the string. > With this a string 'xch' ist coded as 48 instead of the correct 484. > A solution is to store the added 'S' in the next loop not in the lastChar. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-daemon] markt-asf merged pull request #10: apsupport.m4: improve mips detect
markt-asf merged pull request #10: apsupport.m4: improve mips detect URL: https://github.com/apache/commons-daemon/pull/10 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (NUMBERS-116) Remove redundant methods in ArithmeticUtils
[
https://issues.apache.org/jira/browse/NUMBERS-116?focusedWorklogId=262448&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-262448
]
ASF GitHub Bot logged work on NUMBERS-116:
--
Author: ASF GitHub Bot
Created on: 18/Jun/19 16:43
Start Date: 18/Jun/19 16:43
Worklog Time Spent: 10m
Work Description: coveralls commented on issue #52: [NUMBERS-116] Remove
redundant methods in org.apache.commons.numbers.core.ArithmeticUtils
URL: https://github.com/apache/commons-numbers/pull/52#issuecomment-503216715
[](https://coveralls.io/builds/24065497)
Coverage decreased (-0.2%) to 94.196% when pulling
**ab7f81481350b0d8bec83da46db014a0c7739fc6 on Schamschi:NUMBERS-116** into
**5d6e5414cb0a44719e1bb6de4a8b03cb2686eb59 on apache:master**.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 262448)
Time Spent: 20m (was: 10m)
> Remove redundant methods in ArithmeticUtils
> ---
>
> Key: NUMBERS-116
> URL: https://issues.apache.org/jira/browse/NUMBERS-116
> Project: Commons Numbers
> Issue Type: Improvement
> Components: core
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As has been
> [discussed|http://mail-archives.apache.org/mod_mbox/commons-dev/201906.mbox/%3C940f9ff0-0b25-cd31-ddb3-a95ca777ba06%40gmx.at%3E]
> on the developers' mailing list, the following methods from the class
> {{ArithmeticUtils}} can be removed:
> {{addAndCheck(int, int)}}
> {{addAndCheck(long, long)}}
> {{mulAndCheck(int, int)}}
> {{mulAndCheck(long, long)}}
> {{subAndCheck(int, int)}}
> {{subAndCheck(long, long)}}
> And their usages replaced with the following equivalent methods from
> {{java.lang.Math}}:
> {{addExact(int, int)}}
> {{addExact(long, long)}}
> {{multiplyExact(int, int)}}
> {{multiplyExact(long, long)}}
> {{subtractExact(int, int)}}
> {{subtractExact(long, long)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-numbers] coveralls commented on issue #52: [NUMBERS-116] Remove redundant methods in org.apache.commons.numbers.core.ArithmeticUtils
coveralls commented on issue #52: [NUMBERS-116] Remove redundant methods in org.apache.commons.numbers.core.ArithmeticUtils URL: https://github.com/apache/commons-numbers/pull/52#issuecomment-503216715 [](https://coveralls.io/builds/24065497) Coverage decreased (-0.2%) to 94.196% when pulling **ab7f81481350b0d8bec83da46db014a0c7739fc6 on Schamschi:NUMBERS-116** into **5d6e5414cb0a44719e1bb6de4a8b03cb2686eb59 on apache:master**. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-daemon] markt-asf closed pull request #11: Better logging messsages in prunsrv.c
markt-asf closed pull request #11: Better logging messsages in prunsrv.c URL: https://github.com/apache/commons-daemon/pull/11 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-daemon] markt-asf commented on issue #11: Better logging messsages in prunsrv.c
markt-asf commented on issue #11: Better logging messsages in prunsrv.c URL: https://github.com/apache/commons-daemon/pull/11#issuecomment-503195253 LGTM. Merged. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (NUMBERS-116) Remove redundant methods in ArithmeticUtils
[
https://issues.apache.org/jira/browse/NUMBERS-116?focusedWorklogId=262350&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-262350
]
ASF GitHub Bot logged work on NUMBERS-116:
--
Author: ASF GitHub Bot
Created on: 18/Jun/19 14:51
Start Date: 18/Jun/19 14:51
Worklog Time Spent: 10m
Work Description: Schamschi commented on pull request #52: [NUMBERS-116]
Remove redundant methods in org.apache.commons.numbers.core.ArithmeticUtils
URL: https://github.com/apache/commons-numbers/pull/52
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 262350)
Time Spent: 10m
Remaining Estimate: 0h
> Remove redundant methods in ArithmeticUtils
> ---
>
> Key: NUMBERS-116
> URL: https://issues.apache.org/jira/browse/NUMBERS-116
> Project: Commons Numbers
> Issue Type: Improvement
> Components: core
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As has been
> [discussed|http://mail-archives.apache.org/mod_mbox/commons-dev/201906.mbox/%3C940f9ff0-0b25-cd31-ddb3-a95ca777ba06%40gmx.at%3E]
> on the developers' mailing list, the following methods from the class
> {{ArithmeticUtils}} can be removed:
> {{addAndCheck(int, int)}}
> {{addAndCheck(long, long)}}
> {{mulAndCheck(int, int)}}
> {{mulAndCheck(long, long)}}
> {{subAndCheck(int, int)}}
> {{subAndCheck(long, long)}}
> And their usages replaced with the following equivalent methods from
> {{java.lang.Math}}:
> {{addExact(int, int)}}
> {{addExact(long, long)}}
> {{multiplyExact(int, int)}}
> {{multiplyExact(long, long)}}
> {{subtractExact(int, int)}}
> {{subtractExact(long, long)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-numbers] Schamschi opened a new pull request #52: [NUMBERS-116] Remove redundant methods in org.apache.commons.numbers.core.ArithmeticUtils
Schamschi opened a new pull request #52: [NUMBERS-116] Remove redundant methods in org.apache.commons.numbers.core.ArithmeticUtils URL: https://github.com/apache/commons-numbers/pull/52 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (NUMBERS-116) Remove redundant methods in ArithmeticUtils
Heinrich Bohne created NUMBERS-116:
--
Summary: Remove redundant methods in ArithmeticUtils
Key: NUMBERS-116
URL: https://issues.apache.org/jira/browse/NUMBERS-116
Project: Commons Numbers
Issue Type: Improvement
Components: core
Reporter: Heinrich Bohne
As has been
[discussed|http://mail-archives.apache.org/mod_mbox/commons-dev/201906.mbox/%3C940f9ff0-0b25-cd31-ddb3-a95ca777ba06%40gmx.at%3E]
on the developers' mailing list, the following methods from the class
{{ArithmeticUtils}} can be removed:
{{addAndCheck(int, int)}}
{{addAndCheck(long, long)}}
{{mulAndCheck(int, int)}}
{{mulAndCheck(long, long)}}
{{subAndCheck(int, int)}}
{{subAndCheck(long, long)}}
And their usages replaced with the following equivalent methods from
{{java.lang.Math}}:
{{addExact(int, int)}}
{{addExact(long, long)}}
{{multiplyExact(int, int)}}
{{multiplyExact(long, long)}}
{{subtractExact(int, int)}}
{{subtractExact(long, long)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (NUMBERS-115) Migrate to JUnit 5
[ https://issues.apache.org/jira/browse/NUMBERS-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heinrich Bohne closed NUMBERS-115. -- Resolution: Fixed > Migrate to JUnit 5 > -- > > Key: NUMBERS-115 > URL: https://issues.apache.org/jira/browse/NUMBERS-115 > Project: Commons Numbers > Issue Type: Task >Reporter: Heinrich Bohne >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > As has been > [discussed|http://mail-archives.apache.org/mod_mbox/commons-dev/201905.mbox/%3C8883d6fc-2a22-608a-af3d-96272cd425c9%40gmx.at%3E] > on the developers' mailing list, the whole project can be migrated to JUnit > 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NUMBERS-115) Migrate to JUnit 5
[ https://issues.apache.org/jira/browse/NUMBERS-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16866657#comment-16866657 ] Gilles commented on NUMBERS-115: PR #51 merged to "master". > Migrate to JUnit 5 > -- > > Key: NUMBERS-115 > URL: https://issues.apache.org/jira/browse/NUMBERS-115 > Project: Commons Numbers > Issue Type: Task >Reporter: Heinrich Bohne >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > As has been > [discussed|http://mail-archives.apache.org/mod_mbox/commons-dev/201905.mbox/%3C8883d6fc-2a22-608a-af3d-96272cd425c9%40gmx.at%3E] > on the developers' mailing list, the whole project can be migrated to JUnit > 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (NUMBERS-115) Migrate to JUnit 5
[ https://issues.apache.org/jira/browse/NUMBERS-115?focusedWorklogId=262337&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-262337 ] ASF GitHub Bot logged work on NUMBERS-115: -- Author: ASF GitHub Bot Created on: 18/Jun/19 14:35 Start Date: 18/Jun/19 14:35 Worklog Time Spent: 10m Work Description: asfgit commented on pull request #51: NUMBERS-115: Remove obsolete JUnit 4 dependencies URL: https://github.com/apache/commons-numbers/pull/51 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 262337) Time Spent: 20m (was: 10m) > Migrate to JUnit 5 > -- > > Key: NUMBERS-115 > URL: https://issues.apache.org/jira/browse/NUMBERS-115 > Project: Commons Numbers > Issue Type: Task >Reporter: Heinrich Bohne >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > As has been > [discussed|http://mail-archives.apache.org/mod_mbox/commons-dev/201905.mbox/%3C8883d6fc-2a22-608a-af3d-96272cd425c9%40gmx.at%3E] > on the developers' mailing list, the whole project can be migrated to JUnit > 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-numbers] asfgit merged pull request #51: NUMBERS-115: Remove obsolete JUnit 4 dependencies
asfgit merged pull request #51: NUMBERS-115: Remove obsolete JUnit 4 dependencies URL: https://github.com/apache/commons-numbers/pull/51 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-numbers] Schamschi opened a new pull request #51: NUMBERS-115: Remove obsolete JUnit 4 dependencies
Schamschi opened a new pull request #51: NUMBERS-115: Remove obsolete JUnit 4 dependencies URL: https://github.com/apache/commons-numbers/pull/51 Remove the following dependencies: org.junit.platform:junit-platform-runner org.junit.vintage:junit-vintage-engine 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (NUMBERS-115) Migrate to JUnit 5
[ https://issues.apache.org/jira/browse/NUMBERS-115?focusedWorklogId=262324&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-262324 ] ASF GitHub Bot logged work on NUMBERS-115: -- Author: ASF GitHub Bot Created on: 18/Jun/19 14:15 Start Date: 18/Jun/19 14:15 Worklog Time Spent: 10m Work Description: Schamschi commented on pull request #51: NUMBERS-115: Remove obsolete JUnit 4 dependencies URL: https://github.com/apache/commons-numbers/pull/51 Remove the following dependencies: org.junit.platform:junit-platform-runner org.junit.vintage:junit-vintage-engine 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 262324) Time Spent: 10m Remaining Estimate: 0h > Migrate to JUnit 5 > -- > > Key: NUMBERS-115 > URL: https://issues.apache.org/jira/browse/NUMBERS-115 > Project: Commons Numbers > Issue Type: Task >Reporter: Heinrich Bohne >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > As has been > [discussed|http://mail-archives.apache.org/mod_mbox/commons-dev/201905.mbox/%3C8883d6fc-2a22-608a-af3d-96272cd425c9%40gmx.at%3E] > on the developers' mailing list, the whole project can be migrated to JUnit > 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CODEC-254) ColognePhonetic does not treat the letter H correctly
[ https://issues.apache.org/jira/browse/CODEC-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16866636#comment-16866636 ] Melloware commented on CODEC-254: - [~sebb] This looks awfully similar to this issue? https://issues.apache.org/jira/browse/CODEC-255 Is it possible it is fixed also? > ColognePhonetic does not treat the letter H correctly > - > > Key: CODEC-254 > URL: https://issues.apache.org/jira/browse/CODEC-254 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.12 >Reporter: Holger Grote >Priority: Major > > With the fix in CODEC-250 the letter H is not treaten correct any more. > A String 'shch' is coded as 8 and not as 84. (This string is sometimes in > foreign surnames) > The reasen is the letter h is ignored completely and not stored in the > lastChar anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (VFS-718) MonitorInputStream should not close the stream in "read" #67
[ https://issues.apache.org/jira/browse/VFS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed VFS-718. Resolution: Fixed Fix Version/s: 2.4 In git master. > MonitorInputStream should not close the stream in "read" #67 > > > Key: VFS-718 > URL: https://issues.apache.org/jira/browse/VFS-718 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Gary Gregory >Priority: Major > Fix For: 2.4 > > > MonitorInputStream should not close the stream in "read" #67 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (VFS-718) MonitorInputStream should not close the stream in "read" #67
Gary Gregory created VFS-718: Summary: MonitorInputStream should not close the stream in "read" #67 Key: VFS-718 URL: https://issues.apache.org/jira/browse/VFS-718 Project: Commons VFS Issue Type: Bug Affects Versions: 2.3 Reporter: Gary Gregory MonitorInputStream should not close the stream in "read" #67 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-vfs] garydgregory merged pull request #67: MonitorInputStream should not close the stream in "read"
garydgregory merged pull request #67: MonitorInputStream should not close the stream in "read" URL: https://github.com/apache/commons-vfs/pull/67 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (NUMBERS-115) Migrate to JUnit 5
[
https://issues.apache.org/jira/browse/NUMBERS-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16866622#comment-16866622
]
Gilles commented on NUMBERS-115:
Yes.
And the commit message would be something like:
{noformat}
NUMBERS-115: Remove obsolete dependency (Junit 4).
{noformat}
> Migrate to JUnit 5
> --
>
> Key: NUMBERS-115
> URL: https://issues.apache.org/jira/browse/NUMBERS-115
> Project: Commons Numbers
> Issue Type: Task
>Reporter: Heinrich Bohne
>Priority: Minor
>
> As has been
> [discussed|http://mail-archives.apache.org/mod_mbox/commons-dev/201905.mbox/%3C8883d6fc-2a22-608a-af3d-96272cd425c9%40gmx.at%3E]
> on the developers' mailing list, the whole project can be migrated to JUnit
> 5.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-115) Migrate to JUnit 5
[ https://issues.apache.org/jira/browse/NUMBERS-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16866610#comment-16866610 ] Heinrich Bohne commented on NUMBERS-115: Indeed, the dependencies still need to be taken care of. Grimreaper said that he would do it after the merge, so I assumed he had a reason not to do it in [PR #48|https://github.com/apache/commons-numbers/pull/48], otherwise I would have already included it in the pull request. Should I also relate the new pull request to this JIRA ticket? > Migrate to JUnit 5 > -- > > Key: NUMBERS-115 > URL: https://issues.apache.org/jira/browse/NUMBERS-115 > Project: Commons Numbers > Issue Type: Task >Reporter: Heinrich Bohne >Priority: Minor > > As has been > [discussed|http://mail-archives.apache.org/mod_mbox/commons-dev/201905.mbox/%3C8883d6fc-2a22-608a-af3d-96272cd425c9%40gmx.at%3E] > on the developers' mailing list, the whole project can be migrated to JUnit > 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-vfs] ottobackwards commented on issue #67: MonitorInputStream should not close the stream in "read"
ottobackwards commented on issue #67: MonitorInputStream should not close the stream in "read" URL: https://github.com/apache/commons-vfs/pull/67#issuecomment-503135793 +1, sorry to have missed this in my 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (NUMBERS-115) Migrate to JUnit 5
[ https://issues.apache.org/jira/browse/NUMBERS-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16866593#comment-16866593 ] Gilles commented on NUMBERS-115: Commit c3586cf3df16b08c0b1fbd0e3275d07ae3eb3a8d in "master". Unless I'm mistaken, the "vintage" junit dependency hasn't been removed, but should be, in order to prevent further additions of outdated test methods. If so, could you please do it in another PR? Thanks. > Migrate to JUnit 5 > -- > > Key: NUMBERS-115 > URL: https://issues.apache.org/jira/browse/NUMBERS-115 > Project: Commons Numbers > Issue Type: Task >Reporter: Heinrich Bohne >Priority: Minor > > As has been > [discussed|http://mail-archives.apache.org/mod_mbox/commons-dev/201905.mbox/%3C8883d6fc-2a22-608a-af3d-96272cd425c9%40gmx.at%3E] > on the developers' mailing list, the whole project can be migrated to JUnit > 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-numbers] asfgit merged pull request #48: [WIP] perform the actual migration to JUnit 5
asfgit merged pull request #48: [WIP] perform the actual migration to JUnit 5 URL: https://github.com/apache/commons-numbers/pull/48 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] boris-petrov opened a new pull request #67: MonitorInputStream should not close the stream in "read"
boris-petrov opened a new pull request #67: MonitorInputStream should not close the stream in "read" URL: https://github.com/apache/commons-vfs/pull/67 Similar to https://github.com/apache/commons-vfs/pull/30. That PR fixed only the `read` overload which accepts a buffer but missed the one with no arguments. This PR fixes also the other case. See https://issues.apache.org/jira/projects/VFS/issues/VFS-614. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (NUMBERS-115) Migrate to JUnit 5
[ https://issues.apache.org/jira/browse/NUMBERS-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heinrich Bohne updated NUMBERS-115: --- External issue URL: (was: https://github.com/apache/commons-numbers/pull/48) > Migrate to JUnit 5 > -- > > Key: NUMBERS-115 > URL: https://issues.apache.org/jira/browse/NUMBERS-115 > Project: Commons Numbers > Issue Type: Task >Reporter: Heinrich Bohne >Priority: Minor > > As has been > [discussed|http://mail-archives.apache.org/mod_mbox/commons-dev/201905.mbox/%3C8883d6fc-2a22-608a-af3d-96272cd425c9%40gmx.at%3E] > on the developers' mailing list, the whole project can be migrated to JUnit > 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NUMBERS-115) Migrate to JUnit 5
Heinrich Bohne created NUMBERS-115: -- Summary: Migrate to JUnit 5 Key: NUMBERS-115 URL: https://issues.apache.org/jira/browse/NUMBERS-115 Project: Commons Numbers Issue Type: Task Reporter: Heinrich Bohne As has been [discussed|http://mail-archives.apache.org/mod_mbox/commons-dev/201905.mbox/%3C8883d6fc-2a22-608a-af3d-96272cd425c9%40gmx.at%3E] on the developers' mailing list, the whole project can be migrated to JUnit 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (MATH-1489) Test failure because of incompatible version specification of JaCoCo in pom.xml
[ https://issues.apache.org/jira/browse/MATH-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-1489. -- Resolution: Fixed Remaining issue(s) is unrelated to the original description. > Test failure because of incompatible version specification of JaCoCo in > pom.xml > --- > > Key: MATH-1489 > URL: https://issues.apache.org/jira/browse/MATH-1489 > Project: Commons Math > Issue Type: Bug > Environment: OpenJDK 11.0.3 > Debian GNU/Linux 9.9 stretch > >Reporter: M. Z. >Priority: Critical > Labels: build, easyfix, newbie > Attachments: commons-math-buildlog-2019-06-15.log > > Original Estimate: 10m > Remaining Estimate: 10m > > I've experienced constant build failures on the attempt to "mvn clean package" > on a working copy of [http://gitbox.apache.org/repos/asf/commons-math.git] ( > commit 4b0f52c0dd9df564d58140e1d717a2da218f0139 ) > It has to do with the specified version of jacoco in pom.xml. See attached > buildlog for concrete error. > My solution: > $ git diff > --- a/pom.xml > +++ b/pom.xml > @@ -493,7 +493,7 @@ > 2.7.2 > > > - 0.8.0 > + 0.8.4 > 0.96 > 0.8 > 0.8 > > See > [https://stackoverflow.com/questions/55272870/surefire-maven-plugin-corrupted-stdout-by-directly-writing-to-native-stream-in] > for a previously reported issue with the use jacoco and OpenJDK 11. > After the proposed change, I've got > $ mvn clean package > > [INFO] Results: > [INFO] > [ERROR] Failures: > [ERROR] FastMathTest.checkMissingFastMathClasses:1275 FastMath should > implement all StrictMath methods > [INFO] > [ERROR] Tests run: 4864, Failures: 1, Errors: 0, Skipped: 31 > [INFO] > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > ... > So tests should have been executed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-compress] bodewig merged pull request #81: Performance Improvement: Call toArray with 0 Array Size
bodewig merged pull request #81: Performance Improvement: Call toArray with 0 Array Size URL: https://github.com/apache/commons-compress/pull/81 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-compress] bodewig commented on issue #81: Performance Improvement: Call toArray with 0 Array Size
bodewig commented on issue #81: Performance Improvement: Call toArray with 0 Array Size URL: https://github.com/apache/commons-compress/pull/81#issuecomment-503032198 many thanks, @DaGeRe 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (RNG-16) Linear congruential generators
[ https://issues.apache.org/jira/browse/RNG-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16865548#comment-16865548 ] Abhishek Singh Dhadwal edited comment on RNG-16 at 6/18/19 8:21 AM: Hello, I shall be working on the task at hand. Upon discussion with Gilles and Alex Herbert, following are the details about the plan for implementation of the RNG. There shall be a base abstract class (AbstractLCG) which shall take inputs of a,c,m and the seed and return integer values as required. There shall be a child class (KnuthLewisLCG) which shall extend the aforementioned class with the values of a, c and m referred from [Numerical Recipes |https://en.wikipedia.org/wiki/Linear_congruential_generator#Parameters_in_common_use] The current questions/queries at hand are : * Will it pass the test suite? * Can using modulo 2^32 increase performance (to be tested using JMH) * Comparison between KnuthLewisDirect and the aforementioned child class The github repository where I will be working currently is : [https://github.com/AbhishekSinghDhadwal/commons-rng] The test values (hexadecimal) obtained as per numerical recipes ( for seed = 0) are as follows : 3c6ef35f 47502932 d1ccf6e9 aaf95334 6252e503 9f2ec686 57fe6c2d a3d95fa8 81fdbee7 94f0af1a The generator should match these values. was (Author: abhi1507): Hello, I shall be working on the task at hand. Upon discussion with Gilles and Alex Herbert, following are the details about the plan for implementation of the RNG. There shall be a base abstract class (AbstractLCG) which shall take inputs of a,c,m and the seed and return integer values as required. There shall be a child class (KnuthLewisLCG) which shall extend the aforementioned class with the values of a, c and m referred from [Numerical Recipes |https://en.wikipedia.org/wiki/Linear_congruential_generator#Parameters_in_common_use] The current questions/queries at hand are : * Will it pass the test suite? * Can using modulo 2^32 increase performance (to be tested using JMH) * Comparison between KnuthLewisDirect and the aforementioned child class The github repository where I will be working currently is : [https://github.com/AbhishekSinghDhadwal/commons-rng] The test values (hexadecimal) obtained as per numerical recipes ( for seed = 0) are as follows : 0 3c6ef35f 47502932 d1ccf6e9 aaf95334 6252e503 9f2ec686 57fe6c2d a3d95fa8 81fdbee7 94f0af1a The generator should match these values. > Linear congruential generators > -- > > Key: RNG-16 > URL: https://issues.apache.org/jira/browse/RNG-16 > Project: Commons RNG > Issue Type: Sub-task >Reporter: Emmanuel Bourg >Priority: Minor > Labels: gsoc2019 > > This is a RFE for implementing linear congruential generators: > https://en.wikipedia.org/wiki/Linear_congruential_generator > This type of random generator is often used in language runtimes (Borland C, > GCC, Delphi, VB and even Java). Preconfigured generators using the same > parameters as these languages would be convenient for reproducing the same > number sequences in Java. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (RNG-16) Linear congruential generators
[ https://issues.apache.org/jira/browse/RNG-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16865548#comment-16865548 ] Abhishek Singh Dhadwal edited comment on RNG-16 at 6/18/19 8:19 AM: Hello, I shall be working on the task at hand. Upon discussion with Gilles and Alex Herbert, following are the details about the plan for implementation of the RNG. There shall be a base abstract class (AbstractLCG) which shall take inputs of a,c,m and the seed and return integer values as required. There shall be a child class (KnuthLewisLCG) which shall extend the aforementioned class with the values of a, c and m referred from [Numerical Recipes |https://en.wikipedia.org/wiki/Linear_congruential_generator#Parameters_in_common_use] The current questions/queries at hand are : * Will it pass the test suite? * Can using modulo 2^32 increase performance (to be tested using JMH) * Comparison between KnuthLewisDirect and the aforementioned child class The github repository where I will be working currently is : [https://github.com/AbhishekSinghDhadwal/commons-rng] The test values (hexadecimal) obtained as per numerical recipes ( for seed = 0) are as follows : 0 3c6ef35f 47502932 d1ccf6e9 aaf95334 6252e503 9f2ec686 57fe6c2d a3d95fa8 81fdbee7 94f0af1a The generator should match these values. was (Author: abhi1507): Hello, I shall be working on the task at hand. Upon discussion with Gilles and Alex Herbert, following are the details about the plan for implementation of the RNG. There shall be a base abstract class (AbstractLCG) which shall take inputs of a,c,m and the seed and return integer values as required. There shall be a child class (KnuthLewisLCG) which shall extend the aforementioned class with the values of a, c and m referred from [Numerical Recipes |https://en.wikipedia.org/wiki/Linear_congruential_generator#Parameters_in_common_use] The current questions/queries at hand are : * Will it pass the test suite? * Can using modulo 2^32 increase performance (to be tested using JMH) * Comparison between KnuthLewisDirect and the aforementioned child class > Linear congruential generators > -- > > Key: RNG-16 > URL: https://issues.apache.org/jira/browse/RNG-16 > Project: Commons RNG > Issue Type: Sub-task >Reporter: Emmanuel Bourg >Priority: Minor > Labels: gsoc2019 > > This is a RFE for implementing linear congruential generators: > https://en.wikipedia.org/wiki/Linear_congruential_generator > This type of random generator is often used in language runtimes (Borland C, > GCC, Delphi, VB and even Java). Preconfigured generators using the same > parameters as these languages would be convenient for reproducing the same > number sequences in Java. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-lang] lukaseder commented on issue #300: Improve StringUtils#replace throughput
lukaseder commented on issue #300: Improve StringUtils#replace throughput URL: https://github.com/apache/commons-lang/pull/300#issuecomment-502995001 Hah! :-) We're upgrading our Commons Lang dependency because of this issue. Great to see that this issue, in turn, was created because of our own benchmarks! Also interesting, JDK 13 adds further improvements: https://twitter.com/tagir_valeev/status/1140882246552956929 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
