[GitHub] [commons-cli] garydgregory commented on pull request #179: DisablePartialMatching Test
garydgregory commented on PR #179: URL: https://github.com/apache/commons-cli/pull/179#issuecomment-1617155586 -1: This is a Java project and this file is not helpful. -- 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-cli] moonlightingLL opened a new pull request, #179: DisablePartialMatching Test
moonlightingLL opened a new pull request, #179: URL: https://github.com/apache/commons-cli/pull/179 (no 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] (MATH-1394) Implementation of DIRECT global optimizer
[ https://issues.apache.org/jira/browse/MATH-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739426#comment-17739426 ] Gilles Sadowski commented on MATH-1394: --- bq. I was wondering if I can use the clustering apis that common-maths have Sure; it's always better if we can reuse existing code. Note that there are some issues with the design of the clustering functionality (reported on JIRA). Eventually, fixing those would allow the refactored code to be moved to a new (maven) module. > Implementation of DIRECT global optimizer > - > > Key: MATH-1394 > URL: https://issues.apache.org/jira/browse/MATH-1394 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.5, 3.6 >Reporter: Kevin A. Burton >Priority: Major > Fix For: 4.X > > Attachments: DIRECT.png, GLOBAL.png > > > An open source implementation of the DIRECT global optimizer, described by > Jones, Perttunen and Stuckmann, implementing > math3.optim.nonlinear.scalar.MultivariateOptimizer, is available as > DIRECTOptimizer.java at > https://github.com/edwardkort/WWIDesigner/tree/optimizer/WWIDesigner/src/main/com/wwidesigner/math. > There are also three variants of the algorithm on that page: > DIRECT_L_Optimizer implements DIRECT-L by Gablonsky and Kelley, > DIRECT1Optimizer changes which sides are chosen for dividing, and > DIRECTCOptimizer adds alternative ways to select potentially-optimal > hyperrectangles. > DIRECT is not as fast as BOBYQA, but is better at finding a global minimum in > a field of many local minima. > JUnit tests for all of these, using standard optimizer test functions, are > available in > https://github.com/edwardkort/WWIDesigner/tree/optimizer/WWIDesigner/src/test/com/wwidesigner/math. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [commons-lang] garydgregory commented on pull request #1071: LANG-1695
garydgregory commented on PR #1071: URL: https://github.com/apache/commons-lang/pull/1071#issuecomment-1617054177 > @garydgregory I am new to open source contribution and a week ago I started with Apache. I applied for a JIRA account, but I was denied one (with no reason given). So, I cannot login to JIRA. Here is the email from apache: We regret to inform you that, upon reviewing your request for a new Jira account connected with The Apache Software Foundation, the commons project has chosen to deny the request. We therefore will not create the Jira account. > > The following reason was given: No reason given. > > If you wish to appeal this decision, you may do so either directly with the commons project, or by contacting the ASF Infrastructure team at: [us...@infra.apache.org](mailto:us...@infra.apache.org) @orionlibs Please apply again for a Jira account, I'll watch for it. -- 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
[ https://issues.apache.org/jira/browse/IMAGING-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739423#comment-17739423 ] Gary D. Gregory commented on IMAGING-356: - Hi [~gwlucas] What is "the TIFF branch of Commons Imaging"? The only branch that matters is master. > 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 > > 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)
[jira] [Commented] (IMAGING-356) TIFF reading extremely slow in version 1.0-SNAPSHOT
[ https://issues.apache.org/jira/browse/IMAGING-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739420#comment-17739420 ] Gary Lucas commented on IMAGING-356: Any good sized TIFF file would do (not sure about other formats). The one I used was located in https://github.com/apache/commons-imaging/tree/master/src/test/data/images/tiff/1/PICT2833.TIF I picked that one just because it was large enough that I could make meaningful access time measurements, but not so large that it would be impractical. Also, it was already part of the distribution, so it wouldn't add anything new to the project. Internally, it is accessed by the TIFF branch of Commons Imaging in a class called DataReaderStrips. Good luck. > 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 > > 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-math] orionlibs commented on pull request #233: new method that takes string and extracts list of numbers
orionlibs commented on PR #233: URL: https://github.com/apache/commons-math/pull/233#issuecomment-1616878566 @sebbASF this method was supposed to be just a general utility. I emailed the maillist and I will see what other people say and well. If most people agree with you, then I will just close this 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
[GitHub] [commons-math] sebbASF commented on pull request #233: new method that takes string and extracts list of numbers
sebbASF commented on PR #233: URL: https://github.com/apache/commons-math/pull/233#issuecomment-1616865490 Different contexts will need different solutions. -- 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-math] orionlibs commented on pull request #233: new method that takes string and extracts list of numbers
orionlibs commented on PR #233: URL: https://github.com/apache/commons-math/pull/233#issuecomment-1616861706 @sebbASF thank you. I will look into it tomorrow since it is 23:14 here. Thanks -- 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-math] sebbASF commented on pull request #233: new method that takes string and extracts list of numbers
sebbASF commented on PR #233: URL: https://github.com/apache/commons-math/pull/233#issuecomment-1616856138 I'm not convinced that the method is appropriate for a Commons component. Seems to me any such parsing really needs to be designed for the context in which it is to be used. Also, as it stands, the proposed method depends on the representation of the decimal point. It also does not allow for thousands separators, and will match numbers with leading or trailing text (e.g. G7, 3G). It also does not allow for large integer numbers beyond the range of Double. -- 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-math] orionlibs commented on pull request #233: new method that takes string and extracts list of numbers
orionlibs commented on PR #233: URL: https://github.com/apache/commons-math/pull/233#issuecomment-1616830468 @aherbert thank you for replying. I put this method in NumberUtils in the LANG project, but they told me there that it probably belongs to MATH because it has to do with numbers. So that is what I did, but the MATH project does not have a lot of string parsing classes and methods. Right? I think. The TEXT project is more about manipulating strings and not extracting data from them. I think it belongs to LANG, because this method doesn't do math calculations. It just uses a base Java Lang class (i.e. String) to extract something. It is a weird method, because it includes a String and numbers. There are a number of potential uses: 1--This could be particularly useful for data mining or information extraction where you are dealing with unstructured text. It could be a part of a larger Natural Language Processing (NLP) or text analysis tool where numeric information needs to be analyzed separately. 2--If you're parsing contact information and want to separate phone numbers or other numeric information from a larger string. 3--If you are working with log files, XML or JSON data, and you need to extract certain numeric values that are embedded within text. 4--If the dates or times are in a specific format embedded in text, the method can be used to extract the relevant parts. 5--If you're scraping data from websites, it's often the case that useful numeric data like prices, dates, and identifiers are mixed in with other text. 6--if you want to extract all the numbers and perform mathematical operations such as sum, average etc. 7--For analyzing textual data for occurrences of numbers or patterns involving numbers. 8--In chatbots, virtual assistants, or any other AI that interprets human language, to identify and process numbers mentioned in the user's input. I will email DEV -- 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-math] aherbert commented on pull request #233: new method that takes string and extracts list of numbers
aherbert commented on PR #233: URL: https://github.com/apache/commons-math/pull/233#issuecomment-1616820363 It is difficult to find a static class to host this method as it is not typically something performed in the math library, i.e. parsing numbers from within text is not within the current scope of math. It is not a mathematical operation or algorithm. Some legacy classes exist to perform String IO but the current trend in the math derived libraries for new code such as Numbers is to avoid IO conversions as this is locale specific and/or a user specific choice of format. Parsing of strings and formatting to strings delegates to the JDK methods, e.g. `double Double.parseDouble(String)` and `String Double.toString(double)`. Composite numbers are typically delimited strings of standard format numbers, see for example `o.a.c.numbers.complex.Complex` for `static Complex parse(String)` and `String toString()`. For the parsing, no regex is used and all identification of the number is left to `Double.parseDouble`. The commons method is solely responsible for cutting up the string using known delimiters. I think you may find some interest in the value of this type of method by writing to the dev mailing list. If you put `[math][lang][text]` in the subject heading and start a discussion on the utility of this functionality and the use cases you have, e.g. why are you stripping out numbers from strings but not supporting scientific notation; what mystery input strings are you wishing to decipher and use the numbers from? -- 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
[ https://issues.apache.org/jira/browse/IMAGING-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739410#comment-17739410 ] Gary D. Gregory commented on IMAGING-356: - [~gwlucas] What file should I use to run the test? > 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 > > 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)
[jira] [Commented] (IMAGING-356) TIFF reading extremely slow in version 1.0-SNAPSHOT
[
https://issues.apache.org/jira/browse/IMAGING-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739408#comment-17739408
]
Gary D. Gregory commented on IMAGING-356:
-
Hi [~gwlucas]
I just found and fixed one oddball character in {{Allocator}} Javadocs. Let me
know if you see others.
> 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
>
> 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)
[jira] [Resolved] (LANG-1647) Add and ExceptionUtils.isChecked() and isUnchecked()
[ https://issues.apache.org/jira/browse/LANG-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved LANG-1647. --- Fix Version/s: 3.13.0 Resolution: Fixed > Add and ExceptionUtils.isChecked() and isUnchecked() > > > Key: LANG-1647 > URL: https://issues.apache.org/jira/browse/LANG-1647 > Project: Commons Lang > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Minor > Fix For: 3.13.0 > > Time Spent: 3.5h > Remaining Estimate: 0h > > The idea it's have a function that check if a given throwable is a checked > exception. There are some similar function in ConcurrentUtils, but have > package visibility and return the same exception. > Seem logic have this verification in the class that have this responsibility > - ExceptionUtils -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (LANG-1647) Add and ExceptionUtils.isChecked() and isUnchecked()
[ https://issues.apache.org/jira/browse/LANG-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated LANG-1647: -- Summary: Add and ExceptionUtils.isChecked() and isUnchecked() (was: Check if a throwable is a [un]checked exception) > Add and ExceptionUtils.isChecked() and isUnchecked() > > > Key: LANG-1647 > URL: https://issues.apache.org/jira/browse/LANG-1647 > Project: Commons Lang > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Minor > Time Spent: 3.5h > Remaining Estimate: 0h > > The idea it's have a function that check if a given throwable is a checked > exception. There are some similar function in ConcurrentUtils, but have > package visibility and return the same exception. > Seem logic have this verification in the class that have this responsibility > - ExceptionUtils -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (LANG-1647) Check if a throwable is a [un]checked exception
[ https://issues.apache.org/jira/browse/LANG-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated LANG-1647: -- Summary: Check if a throwable is a [un]checked exception (was: Check if a throwable is a checked exception) > Check if a throwable is a [un]checked exception > --- > > Key: LANG-1647 > URL: https://issues.apache.org/jira/browse/LANG-1647 > Project: Commons Lang > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Minor > Time Spent: 3.5h > Remaining Estimate: 0h > > The idea it's have a function that check if a given throwable is a checked > exception. There are some similar function in ConcurrentUtils, but have > package visibility and return the same exception. > Seem logic have this verification in the class that have this responsibility > - ExceptionUtils -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (LANG-1647) Check if a throwable is a checked exception
[ https://issues.apache.org/jira/browse/LANG-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated LANG-1647: -- Summary: Check if a throwable is a checked exception (was: Check if an throwable is a checked exception) > Check if a throwable is a checked exception > --- > > Key: LANG-1647 > URL: https://issues.apache.org/jira/browse/LANG-1647 > Project: Commons Lang > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Minor > Time Spent: 3.5h > Remaining Estimate: 0h > > The idea it's have a function that check if a given throwable is a checked > exception. There are some similar function in ConcurrentUtils, but have > package visibility and return the same exception. > Seem logic have this verification in the class that have this responsibility > - ExceptionUtils -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [commons-lang] garydgregory merged pull request #1069: LANG-1647
garydgregory merged PR #1069: URL: https://github.com/apache/commons-lang/pull/1069 -- 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] [Created] (EXEC-121) Async execution does not guarantee that process destroyer is registered
Marcono1234 created EXEC-121:
Summary: Async execution does not guarantee that process destroyer
is registered
Key: EXEC-121
URL: https://issues.apache.org/jira/browse/EXEC-121
Project: Commons Exec
Issue Type: Bug
Affects Versions: 1.3
Reporter: Marcono1234
h3. Bug
When using one of the async {{Executor.execute}} methods, i.e. one taking an
{{ExecuteResultHandler}} argument, it is not guaranteed that the process
destroyer is registered.
The reason for this is that launching of the process and registration of the
process destroyer is done already in the separate executor thread. So it is
possible that a race condition occurs where the process is currently launching
but in the mean time the JVM exits, so the process destroyer is never
registered and the process is therefore not destroyed.
While I assume for normal use cases it is unlikely that the JVM exits right
after the process was launched, such situations could occur if a (possibly
unrelated) error occurs and the whole application should terminate. In such
cases it would probably be important that any launched process is destroyed as
well.
h3. Example
Here is a small example demonstrating this:
{code}
Executor e = new DaemonExecutor();
e.setProcessDestroyer(new ShutdownHookProcessDestroyer());
// This is to get the timing of this test right, that is, finish in `main`
right after process was launched
CountDownLatch latch = new CountDownLatch(1);
e.setStreamHandler(new PumpStreamHandler() {
@Override
public void start() {
latch.countDown();
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
super.start();
}
});
CommandLine c = new CommandLine("notepad.exe"); // for Windows
e.execute(c, new ExecuteResultHandler() {
@Override
public void onProcessFailed(ExecuteException e) {
e.printStackTrace();
}
@Override
public void onProcessComplete(int exitValue) {
System.out.println("Completed: " + exitValue);
}
});
latch.await();
{code}
This is a bit contrived to make sure it gets the timing right, but it can also
be reproduced with "real world" code. What happens is that Notepad is launched,
the JVM exits but Notepad remains open (= the bug).
If you add for example a {{Thread.sleep(3000);}} at the end of {{main}} it
works as expected and Notepad is closed when the JVM exits.
h3. Possible solution
One solution might be to launch the process and register the process destroyer
outside the executor thread. This would also have the nice side effect that
execution fails fast if the process cannot even be launched in the first place.
But on the other hand it would probably slow down starting async execution
because it has to wait until the process is launched (though not until it
exits; that is still handled by the executor thread).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (EXEC-53) Allow control over asynchronous execution thread
[
https://issues.apache.org/jira/browse/EXEC-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739400#comment-17739400
]
Marcono1234 commented on EXEC-53:
-
This is resolved, right? Because
{{org.apache.commons.exec.DefaultExecutor#createThread}} was added back then,
though as part of EXEC-55 apparently.
> Allow control over asynchronous execution thread
>
>
> Key: EXEC-53
> URL: https://issues.apache.org/jira/browse/EXEC-53
> Project: Commons Exec
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Nikolay Martynov
>Assignee: Siegfried Goeschl
>Priority: Major
> Labels: patch
> Attachments: EXEC-53.unit-test.patch, commons-exec-daemon.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> When process is started asynchronously using DefaultExecutor then thread is
> created that monitors process. This thread is user thread and blocks java
> program from exiting. There is no way to make this thread daemon. Allowing
> this to be a daemon thread one would be able to spawn process without &,
> monitor this process for some time to be sure that it is alive and then exit
> without calling System.exit() that isnt always possible/desirable.
> Also it would be nice to be able to create thread with specific priority or
> thread group or thread name or anything else.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-lang] orionlibs commented on a diff in pull request #1069: LANG-1647
orionlibs commented on code in PR #1069:
URL: https://github.com/apache/commons-lang/pull/1069#discussion_r1249641820
##
src/test/java/org/apache/commons/lang3/exception/ExceptionUtilsTest.java:
##
@@ -850,4 +850,40 @@ public void testWrapAndUnwrapThrowable() {
final Throwable t = assertThrows(Throwable.class, () ->
ExceptionUtils.wrapAndThrow(new TestThrowable()));
assertTrue(ExceptionUtils.hasCause(t, TestThrowable.class));
}
+
+@Test
+public void testIsChecked_unchecked() {
+final boolean result = ExceptionUtils.isChecked(new
IllegalArgumentException());
Review Comment:
@garydgregory you are right. I made ConcurrentUtils to use the new method. I
hope this completes this PR. Thank you for pointing that comment out. I focused
on other parts and I missed that part of the comment. Distractions are bad
--
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] (STATISTICS-71) Implementation of Univariate Statistics
[
https://issues.apache.org/jira/browse/STATISTICS-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739392#comment-17739392
]
Gilles Sadowski commented on STATISTICS-71:
---
{quote}[...] I included this signature is to possibly support [...]
{quote}
The fist step is to define the _minimal_ interface that would the support the
main functionality.
{quote}[...] I feel we might actually need 3 interfaces [...]
{quote}
Let's focus on the most useful functionality (i.e. handling the "double" type).
{quote}I feel its better to have Storeless as part of the interface name to
make it clear that it is a storeless implementation, [...]
{quote}
The point is that an _interface_ is *not* an implementation. The string
"storeless" cannot impose anything on an implementation. It's the
implementation that can "mark" itself.
{code:java}
public interface Storeless {}
{code}
{code:java}
class StorelessMean implements DoubleStatistics, Storeless {
// ... implementation "knows" that is storeless.
}
{code}
However we could have instead
{code:java}
public interface DoubleStatistics extends DoubleSupplier {
boolean isStoreless();
// ... "combine" ...
}
{code}
The latter would make the marker interface unnecessary, and also impose to
every implementation the behaviour of signalling whether it is storeless.
{quote}[...] cannot do certain things like compute rolling statistics for
instance.
{quote}
How could one expect a "rolling" functionality with the current definition of
the interface?
{quote}[...] kinds of combinations we want to restrict [...]
{quote}
{code:java}
Min a = new Min();
Max b = new Max();
// ...
a.combine(b); // ???
{code}
> Implementation of Univariate Statistics
> ---
>
> Key: STATISTICS-71
> URL: https://issues.apache.org/jira/browse/STATISTICS-71
> Project: Commons Statistics
> Issue Type: Task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> Jira ticket to track the implementation of the Univariate statistics required
> for the updated SummaryStatistics API.
> The implementation would be "storeless". It should be used for calculating
> statistics that can be computed in one pass through the data without storing
> the sample values.
> Currently I have the definition of API as (this might evolve as I continue
> working)
> {code:java}
> public interface DoubleStorelessUnivariateStatistic extends DoubleSupplier {
> DoubleStorelessUnivariateStatistic add(double v);
> long getCount();
> void combine(DoubleStorelessUnivariateStatistic other);
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-lang] orionlibs closed pull request #1075: ArchUtils refactoring
orionlibs closed pull request #1075: ArchUtils refactoring URL: https://github.com/apache/commons-lang/pull/1075 -- 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-math] orionlibs opened a new pull request, #233: new method that takes a string and extracts a list of numbers
orionlibs opened a new pull request, #233: URL: https://github.com/apache/commons-math/pull/233 --created a method that takes a string and extracts a list of numbers that it finds inside the string. --created tests --this project does not have a class like NumberUtils so, I thought that the most relevant existing class that can hold this method is CompositeFormat for the only reason that it already has number parsing methods. Please tell me if I should put this method in another 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
[GitHub] [commons-lang] garydgregory commented on a diff in pull request #1069: LANG-1647
garydgregory commented on code in PR #1069:
URL: https://github.com/apache/commons-lang/pull/1069#discussion_r1249622583
##
src/test/java/org/apache/commons/lang3/exception/ExceptionUtilsTest.java:
##
@@ -850,4 +850,40 @@ public void testWrapAndUnwrapThrowable() {
final Throwable t = assertThrows(Throwable.class, () ->
ExceptionUtils.wrapAndThrow(new TestThrowable()));
assertTrue(ExceptionUtils.hasCause(t, TestThrowable.class));
}
+
+@Test
+public void testIsChecked_unchecked() {
+final boolean result = ExceptionUtils.isChecked(new
IllegalArgumentException());
Review Comment:
Not quite, see
https://github.com/apache/commons-lang/pull/1069#issuecomment-1616686083
--
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 #1075: ArchUtils refactoring
garydgregory commented on PR #1075: URL: https://github.com/apache/commons-lang/pull/1075#issuecomment-1616727797 > @garydgregory thank you. So, should I close this PR? I think so. You can check the master branch for the current state. -- 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] (STATISTICS-71) Implementation of Univariate Statistics
[
https://issues.apache.org/jira/browse/STATISTICS-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739388#comment-17739388
]
Anirudh Joshi edited comment on STATISTICS-71 at 7/2/23 4:31 PM:
-
{quote}[...] What about {{Count}} being a {{{}DoubleStorelessStatistics{}}}, on
which other(s) could depend?
{quote}
I was thinking the same to avoid redundant computations while computing
multiple statistics. We could implement count as a standalone statistic and use
composition to avoid redundant computations while computing multiple statistics
?
{code:java}
DoubleStorelessUnivariateStatistic add(double d);{code}
{quote}{{[...] What's the intended usage?}}
{quote}
{{The reason I included this signature is to possibly support chaining during
the add calls like}}
{code:java}
Mean m = new Mean();
double mean = m.add(1).add(2).add(3).getAsDouble();
double mean = Stream.of(1.0, 2.0, 3.0).map(Mean::add).getAsDouble();{code}
{quote}[...] E.g. is "Storeless" a required part of the name? Or is it an
"implementation detail"?
{quote}
I changed the interface name to `DoubleStorelessUnivariateStatistic` since I
feel we might actually need 3 interfaces, `IntStorelessSummaryStatistics` for
integer data and `LongStorelessSummaryStatistics` for long data, similar to JDK
SummaryStatistics. I feel its better to have Storeless as part of the interface
name to make it clear that it is a storeless implementation, so that users are
aware that they cannot do certain things like compute rolling statistics for
instance. But I do not have a strong opinion on this and curious to hear other
arguments against the naming (e.g. if the name is too verbose)
Also in the StatisticsBuilder example, `StorelessMean` and `PlainMean` are
conceptually different (one is storeless and other is stored so there may be
different endpoints the impl classes may have) so I am wondering if it would be
a good idea to have them share the base Mean class. This would make the base
class restrictive and the users may not be able to use the specific features
available (in PlainMean for instance) ?
{quote}[...] be more restrictive in order to forbid meaningless combinations?
{quote}
Not sure if I understand the requirement correctly. What are the kinds of
combinations we want to restrict here ?
was (Author: JIRAUSER299640):
{quote}[...] What about {{Count}} being a {{{}DoubleStorelessStatistics{}}}, on
which other(s) could depend?
{quote}
I was thinking the same to avoid redundant computations while computing
multiple statistics. We could implement count as a standalone statistic and use
composition to avoid redundant computations while computing multiple statistics
?
{code:java}
DoubleStorelessUnivariateStatistic add(double d);{code}
{quote}{{[...] What's the intended usage?}}
{quote}
{{The reason I included this signature is to possibly support chaining during
the add calls like}}
{code:java}
Mean m = new Mean();
double mean = m.add(1).add(2).add(3).getAsDouble();
double mean = Stream.of(1.0, 2.0, 3.0).map(Mean::add).getAsDouble();{code}
{quote}[...] E.g. is "Storeless" a required part of the name? Or is it an
"implementation detail"?
{quote}
I changed the interface name to `DoubleStorelessUnivariateStatistic` since I
feel we might actually need 3 interfaces, `IntStorelessSummaryStatistics` for
integer data and `LongStorelessSummaryStatistics` for long data, similar to JDK
SummaryStatistics. I feel its better to have Storeless as part of the interface
name to make it clear that it is a storeless implementation, so that users are
aware that they cannot do certain things like compute rolling statistics for
instance. But I do not have a strong opinion on this and curious to hear other
arguments against the naming (e.g. if the name is too verbose)
Also in the StatisticsBuilder example, `StorelessMean` and `PlainMean` are
conceptually different (one is storeless and other is stored so there may be
different endpoints the impl classes may have) so I am wondering if it would be
a good idea to have them share the base Mean class. This would make the base
class restrictive and the users may not be able to use the specific features
available (in PlainMean for instance) ?
{quote}[...] be more restrictive in order to forbid meaningless combinations?
{quote}
Not sure if I understand the requirement correctly. What are the kinds of
combinations we want to restrict here ?
> Implementation of Univariate Statistics
> ---
>
> Key: STATISTICS-71
> URL: https://issues.apache.org/jira/browse/STATISTICS-71
> Project: Commons Statistics
> Issue Type: Task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> Jira ticket to track the implementation of the Univariate
[jira] [Comment Edited] (STATISTICS-71) Implementation of Univariate Statistics
[
https://issues.apache.org/jira/browse/STATISTICS-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739388#comment-17739388
]
Anirudh Joshi edited comment on STATISTICS-71 at 7/2/23 4:30 PM:
-
{quote}[...] What about {{Count}} being a {{{}DoubleStorelessStatistics{}}}, on
which other(s) could depend?
{quote}
I was thinking the same to avoid redundant computations while computing
multiple statistics. We could implement count as a standalone statistic and use
composition to avoid redundant computations while computing multiple statistics
?
{code:java}
DoubleStorelessUnivariateStatistic add(double d);{code}
{quote}{{[...] What's the intended usage?}}
{quote}
{{The reason I included this signature is to possibly support chaining during
the add calls like}}
{code:java}
Mean m = new Mean();
double mean = m.add(1).add(2).add(3).getAsDouble();
double mean = Stream.of(1.0, 2.0, 3.0).map(Mean::add).getAsDouble();{code}
{quote}[...] E.g. is "Storeless" a required part of the name? Or is it an
"implementation detail"?
{quote}
I changed the interface name to `DoubleStorelessUnivariateStatistic` since I
feel we might actually need 3 interfaces, `IntStorelessSummaryStatistics` for
integer data and `LongStorelessSummaryStatistics` for long data, similar to JDK
SummaryStatistics. I feel its better to have Storeless as part of the interface
name to make it clear that it is a storeless implementation, so that users are
aware that they cannot do certain things like compute rolling statistics for
instance. But I do not have a strong opinion on this and curious to hear other
arguments against the naming (e.g. if the name is too verbose)
Also in the StatisticsBuilder example, `StorelessMean` and `PlainMean` are
conceptually different (one is storeless and other is stored so there may be
different endpoints the impl classes may have) so I am wondering if it would be
a good idea to have them share the base Mean class. This would make the base
class restrictive and the users may not be able to use the specific features
available (in PlainMean for instance) ?
{quote}[...] be more restrictive in order to forbid meaningless combinations?
{quote}
Not sure if I understand the requirement correctly. What are the kinds of
combinations we want to restrict here ?
was (Author: JIRAUSER299640):
{quote}[...] What about {{Count}} being a {{{}DoubleStorelessStatistics{}}}, on
which other(s) could depend?
{quote}
I was thinking the same to avoid redundant computations while computing
multiple statistics. We could implement count as a standalone statistic and use
composition to avoid redundant computations while computing multiple statistics
?
{code:java}
DoubleStorelessUnivariateStatistic add(double d);{code}
{quote}{{[...] What's the intended usage?}}
{quote}
{{The reason I included this signature is to possibly support chaining during
the add calls like}}
{code:java}
Mean m = new Mean();
double mean = m.add(1).add(2).add(3).getAsDouble();
double mean = Stream.of(1.0, 2.0, 3.0).map(Mean::add).getAsDouble();{code}
{quote}[...] E.g. is "Storeless" a required part of the name? Or is it an
"implementation detail"?
{quote}
I changed the interface name to `DoubleStorelessUnivariateStatistic` since I
feel we might actually need 3 interfaces, `IntStorelessSummaryStatistics` for
integer data and `LongStorelessSummaryStatistics` for long data, similar to JDK
SummaryStatistics. I feel its better to have Storeless as part of the interface
name to make it clear that it is a storeless implementation, so that users are
aware that they cannot do certain things like compute rolling statistics for
instance. But I do not have a strong opinion on this and curious to hear other
arguments against the naming (e.g. if the name is too verbose)
Also in the StatisticsBuilder example, `StorelessMean` and `PlainMean` are
conceptually different (one is storeless and other is stored so there may be
different endpoints the impl classes may have) so I am wondering if it would be
a good idea to have them share the base Mean class. This would make the base
class restrictive and the users may not be able to use the specific features
available (in PlainMean for instance) ?
{quote}[...] be more restrictive in order to forbid meaningless combinations?
{quote}
Not sure if I understand the requirement correctly. What are the kinds of
combinations we want to restrict here ?
> Implementation of Univariate Statistics
> ---
>
> Key: STATISTICS-71
> URL: https://issues.apache.org/jira/browse/STATISTICS-71
> Project: Commons Statistics
> Issue Type: Task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> Jira ticket to track the implementation of the Univariate
[jira] [Comment Edited] (STATISTICS-71) Implementation of Univariate Statistics
[
https://issues.apache.org/jira/browse/STATISTICS-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739388#comment-17739388
]
Anirudh Joshi edited comment on STATISTICS-71 at 7/2/23 4:28 PM:
-
{quote}[...] What about {{Count}} being a {{{}DoubleStorelessStatistics{}}}, on
which other(s) could depend?
{quote}
I was thinking the same to avoid redundant computations while computing
multiple statistics. We could implement count as a standalone statistic and use
composition to avoid redundant computations while computing multiple statistics
?
{code:java}
DoubleStorelessUnivariateStatistic add(double d);{code}
{quote}{{[...] What's the intended usage?}}
{quote}
{{The reason I included this signature is to possibly support chaining during
the add calls like}}
{code:java}
Mean m = new Mean();
double mean = m.add(1).add(2).add(3).getAsDouble();
double mean = Stream.of(1.0, 2.0, 3.0).map(Mean::add).getAsDouble();{code}
{quote}[...] E.g. is "Storeless" a required part of the name? Or is it an
"implementation detail"?
{quote}
I changed the interface name to `DoubleStorelessUnivariateStatistic` since I
feel we might actually need 3 interfaces, `IntStorelessSummaryStatistics` for
integer data and `LongStorelessSummaryStatistics` for long data, similar to JDK
SummaryStatistics. I feel its better to have Storeless as part of the interface
name to make it clear that it is a storeless implementation, so that users are
aware that they cannot do certain things like compute rolling statistics for
instance. But I do not have a strong opinion on this and curious to hear other
arguments against the naming (e.g. if the name is too verbose)
Also in the StatisticsBuilder example, `StorelessMean` and `PlainMean` are
conceptually different (one is storeless and other is stored so there may be
different endpoints the impl classes may have) so I am wondering if it would be
a good idea to have them share the base Mean class. This would make the base
class restrictive and the users may not be able to use the specific features
available (in PlainMean for instance) ?
{quote}[...] be more restrictive in order to forbid meaningless combinations?
{quote}
Not sure if I understand the requirement correctly. What are the kinds of
combinations we want to restrict here ?
was (Author: JIRAUSER299640):
{quote}[...] What about {{Count}} being a {{{}DoubleStorelessStatistics{}}}, on
which other(s) could depend?
{quote}
I was thinking the same to avoid redundant computations while computing
multiple statistics. We could implement count as a standalone statistic and use
composition to avoid redundant computations while computing multiple statistics
?
{code:java}
DoubleStorelessUnivariateStatistic add(double d);{code}
{quote}{{[...] What's the intended usage?}}
{quote}
{{The reason I included this signature is to possibly support chaining during
the add calls like}}
{code:java}
Mean m = new Mean();
double mean = m.add(1).add(2).add(3).getAsDouble();
double mean = Stream.of(1.0, 2.0, 3.0).map(Mean::add).getAsDouble();{code}
{quote}[...] E.g. is "Storeless" a required part of the name? Or is it an
"implementation detail"?
{quote}
I changed the interface name to DoubleStorelessUnivariateStatistic since I feel
we might actually need 3 interfaces, IntStorelessSummaryStatistics for integer
data and LongStorelessSummaryStatistics for long data, similar to JDK
SummaryStatistics. I feel its better to have Storeless as part of the interface
name to make it clear that it is a storeless implementation, so that users are
aware that they cannot do certain things like compute rolling statistics for
instance. But I do not have a strong opinion on this and curious to hear other
arguments against the naming (e.g. if the name is too verbose)
{quote}[...] be more restrictive in order to forbid meaningless combinations?
{quote}
Not sure if I understand the requirement correctly. What are the kinds of
combinations we want to restrict here ?
> Implementation of Univariate Statistics
> ---
>
> Key: STATISTICS-71
> URL: https://issues.apache.org/jira/browse/STATISTICS-71
> Project: Commons Statistics
> Issue Type: Task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> Jira ticket to track the implementation of the Univariate statistics required
> for the updated SummaryStatistics API.
> The implementation would be "storeless". It should be used for calculating
> statistics that can be computed in one pass through the data without storing
> the sample values.
> Currently I have the definition of API as (this might evolve as I continue
> working)
> {code:java}
> public interface DoubleStorelessUnivariateStatistic extends DoubleSupplier {
>
[GitHub] [commons-lang] orionlibs commented on pull request #1071: LANG-1695
orionlibs commented on PR #1071: URL: https://github.com/apache/commons-lang/pull/1071#issuecomment-1616720795 > What user name and real name did you use in the application? I'll see if I can find the application and rejection in the archives. @garydgregory I used this page https://selfserve.apache.org/jira-account.html and the info I entered was: email address = efthymiou.dimitri...@gmail.com username = dimitrios.efthymiou real public name = Dimitrios Efthymiou tell us the intent for this account = I don't need the account now, but I don't know when I will. It is like when you join a company. They give you access to some basic services. (This was probably the reason, but I didn't know then that I needed access to JIRA in order to update the tickets I worked on. I worked on a few tickets that were unassigned and did not have PR links in them. With a JIRA account I can assign myself to the tickets I work on and I can add my PR links in there. I guess that was the reason they rejected me) -- 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 #1069: LANG-1647
orionlibs commented on code in PR #1069:
URL: https://github.com/apache/commons-lang/pull/1069#discussion_r1249608304
##
src/test/java/org/apache/commons/lang3/exception/ExceptionUtilsTest.java:
##
@@ -850,4 +850,40 @@ public void testWrapAndUnwrapThrowable() {
final Throwable t = assertThrows(Throwable.class, () ->
ExceptionUtils.wrapAndThrow(new TestThrowable()));
assertTrue(ExceptionUtils.hasCause(t, TestThrowable.class));
}
+
+@Test
+public void testIsChecked_unchecked() {
+final boolean result = ExceptionUtils.isChecked(new
IllegalArgumentException());
Review Comment:
done!
##
src/test/java/org/apache/commons/lang3/exception/ExceptionUtilsTest.java:
##
@@ -850,4 +850,40 @@ public void testWrapAndUnwrapThrowable() {
final Throwable t = assertThrows(Throwable.class, () ->
ExceptionUtils.wrapAndThrow(new TestThrowable()));
assertTrue(ExceptionUtils.hasCause(t, TestThrowable.class));
}
+
+@Test
+public void testIsChecked_unchecked() {
+final boolean result = ExceptionUtils.isChecked(new
IllegalArgumentException());
Review Comment:
done! I updated the 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] (STATISTICS-71) Implementation of Univariate Statistics
[
https://issues.apache.org/jira/browse/STATISTICS-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739388#comment-17739388
]
Anirudh Joshi edited comment on STATISTICS-71 at 7/2/23 4:19 PM:
-
{quote}[...] What about {{Count}} being a {{{}DoubleStorelessStatistics{}}}, on
which other(s) could depend?
{quote}
I was thinking the same to avoid redundant computations while computing
multiple statistics. We could implement count as a standalone statistic and use
composition to avoid redundant computations while computing multiple statistics
?
{code:java}
DoubleStorelessUnivariateStatistic add(double d);{code}
{quote}{{[...] What's the intended usage?}}
{quote}
{{The reason I included this signature is to possibly support chaining during
the add calls like}}
{code:java}
Mean m = new Mean();
double mean = m.add(1).add(2).add(3).getAsDouble();
double mean = Stream.of(1.0, 2.0, 3.0).map(Mean::add).getAsDouble();{code}
{quote}[...] E.g. is "Storeless" a required part of the name? Or is it an
"implementation detail"?
{quote}
I changed the interface name to DoubleStorelessUnivariateStatistic since I feel
we might actually need 3 interfaces, IntStorelessSummaryStatistics for integer
data and LongStorelessSummaryStatistics for long data, similar to JDK
SummaryStatistics. I feel its better to have Storeless as part of the interface
name to make it clear that it is a storeless implementation, so that users are
aware that they cannot do certain things like compute rolling statistics for
instance. But I do not have a strong opinion on this and curious to hear other
arguments against the naming (e.g. if the name is too verbose)
{quote}[...] be more restrictive in order to forbid meaningless combinations?
{quote}
Not sure if I understand the requirement correctly. What are the kinds of
combinations we want to restrict here ?
was (Author: JIRAUSER299640):
{quote}[...] What about {{Count}} being a {{{}DoubleStorelessStatistics{}}}, on
which other(s) could depend?
{quote}
I was thinking the same to avoid redundant computations while computing
multiple statistics. We could implement count as a standalone statistic and use
composition to avoid redundant computations while computing multiple statistics
?
DoubleStorelessUnivariateStatistic add(double d);
{quote}{{[...] What's the intended usage?}}
{quote}
{{The reason I included this signature is to possibly support chaining during
the add calls like}}
{code:java}
Mean m = new Mean();
double mean = m.add(1).add(2).add(3).getAsDouble();
double mean = Stream.of(1.0, 2.0, 3.0).map(Mean::add).getAsDouble();{code}
{quote}[...] E.g. is "Storeless" a required part of the name? Or is it an
"implementation detail"?
{quote}
I changed the interface name to DoubleStorelessUnivariateStatistic since I feel
we might actually need 3 interfaces, IntStorelessSummaryStatistics for integer
data and LongStorelessSummaryStatistics for long data, similar to JDK
SummaryStatistics. I feel its better to have Storeless as part of the interface
name to make it clear that it is a storeless implementation, so that users are
aware that they cannot do certain things like compute rolling statistics for
instance. But I do not have a strong opinion on this and curious to hear other
arguments against the naming (e.g. if the name is too verbose)
{quote}[...] be more restrictive in order to forbid meaningless combinations?
{quote}
Not sure if I understand the requirement correctly. What are the kinds of
combinations we want to restrict here ?
> Implementation of Univariate Statistics
> ---
>
> Key: STATISTICS-71
> URL: https://issues.apache.org/jira/browse/STATISTICS-71
> Project: Commons Statistics
> Issue Type: Task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> Jira ticket to track the implementation of the Univariate statistics required
> for the updated SummaryStatistics API.
> The implementation would be "storeless". It should be used for calculating
> statistics that can be computed in one pass through the data without storing
> the sample values.
> Currently I have the definition of API as (this might evolve as I continue
> working)
> {code:java}
> public interface DoubleStorelessUnivariateStatistic extends DoubleSupplier {
> DoubleStorelessUnivariateStatistic add(double v);
> long getCount();
> void combine(DoubleStorelessUnivariateStatistic other);
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-lang] garydgregory commented on pull request #1071: LANG-1695
garydgregory commented on PR #1071: URL: https://github.com/apache/commons-lang/pull/1071#issuecomment-1616719162 > @garydgregory I am new to open source contribution and a week ago I started with Apache. I applied for a JIRA account, but I was denied one (with no reason given). So, I cannot login to JIRA. Here is the email from apache: We regret to inform you that, upon reviewing your request for a new Jira account connected with The Apache Software Foundation, the commons project has chosen to deny the request. We therefore will not create the Jira account. > > The following reason was given: No reason given. > > If you wish to appeal this decision, you may do so either directly with the commons project, or by contacting the ASF Infrastructure team at: [us...@infra.apache.org](mailto:us...@infra.apache.org) What user name and real name did you use in the application? I'll see if I can find the application and rejection in the archives. -- 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] (STATISTICS-71) Implementation of Univariate Statistics
[
https://issues.apache.org/jira/browse/STATISTICS-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739388#comment-17739388
]
Anirudh Joshi edited comment on STATISTICS-71 at 7/2/23 4:18 PM:
-
{quote}[...] What about {{Count}} being a {{{}DoubleStorelessStatistics{}}}, on
which other(s) could depend?
{quote}
I was thinking the same to avoid redundant computations while computing
multiple statistics. We could implement count as a standalone statistic and use
composition to avoid redundant computations while computing multiple statistics
?
DoubleStorelessUnivariateStatistic add(double d);
{quote}{{[...] What's the intended usage?}}
{quote}
{{The reason I included this signature is to possibly support chaining during
the add calls like}}
{code:java}
Mean m = new Mean();
double mean = m.add(1).add(2).add(3).getAsDouble();
double mean = Stream.of(1.0, 2.0, 3.0).map(Mean::add).getAsDouble();{code}
{quote}[...] E.g. is "Storeless" a required part of the name? Or is it an
"implementation detail"?
{quote}
I changed the interface name to DoubleStorelessUnivariateStatistic since I feel
we might actually need 3 interfaces, IntStorelessSummaryStatistics for integer
data and LongStorelessSummaryStatistics for long data, similar to JDK
SummaryStatistics. I feel its better to have Storeless as part of the interface
name to make it clear that it is a storeless implementation, so that users are
aware that they cannot do certain things like compute rolling statistics for
instance. But I do not have a strong opinion on this and curious to hear other
arguments against the naming (e.g. if the name is too verbose)
{quote}[...] be more restrictive in order to forbid meaningless combinations?
{quote}
Not sure if I understand the requirement correctly. What are the kinds of
combinations we want to restrict here ?
was (Author: JIRAUSER299640):
{quote}[...] What about {{Count}} being a {{{}DoubleStorelessStatistics{}}}, on
which other(s) could depend?
{quote}
I was thinking the same to avoid redundant computations while computing
multiple statistics. We could implement count as a standalone statistic and use
composition to avoid redundant computations while computing multiple statistics
?
DoubleStorelessUnivariateStatistic add(double d);
{quote}{{{}[...] What's the intended usage?{}}}{\{ }}
{quote}
{{The reason I included this signature is to possibly support chaining during
the add calls like}}
{code:java}
Mean m = new Mean();
double mean = m.add(1).add(2).add(3).getAsDouble();
double mean = Stream.of(1.0, 2.0, 3.0).map(Mean::add).getAsDouble();{code}
{quote}[...] E.g. is "Storeless" a required part of the name? Or is it an
"implementation detail"?
{quote}
I changed the interface name to DoubleStorelessUnivariateStatistic since I feel
we might actually need 3 interfaces, IntStorelessSummaryStatistics for integer
data and LongStorelessSummaryStatistics for long data, similar to JDK
SummaryStatistics. I feel its better to have Storeless as part of the interface
name to make it clear that it is a storeless implementation, so that users are
aware that they cannot do certain things like compute rolling statistics for
instance. But I do not have a strong opinion on this and curious to hear other
arguments against the naming (e.g. if the name is too verbose)
{quote}[...] be more restrictive in order to forbid meaningless combinations?
{quote}
Not sure if I understand the requirement correctly. What are the kinds of
combinations we want to restrict here ?
> Implementation of Univariate Statistics
> ---
>
> Key: STATISTICS-71
> URL: https://issues.apache.org/jira/browse/STATISTICS-71
> Project: Commons Statistics
> Issue Type: Task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> Jira ticket to track the implementation of the Univariate statistics required
> for the updated SummaryStatistics API.
> The implementation would be "storeless". It should be used for calculating
> statistics that can be computed in one pass through the data without storing
> the sample values.
> Currently I have the definition of API as (this might evolve as I continue
> working)
> {code:java}
> public interface DoubleStorelessUnivariateStatistic extends DoubleSupplier {
> DoubleStorelessUnivariateStatistic add(double v);
> long getCount();
> void combine(DoubleStorelessUnivariateStatistic other);
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (STATISTICS-71) Implementation of Univariate Statistics
[
https://issues.apache.org/jira/browse/STATISTICS-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739388#comment-17739388
]
Anirudh Joshi edited comment on STATISTICS-71 at 7/2/23 4:18 PM:
-
{quote}[...] What about {{Count}} being a {{{}DoubleStorelessStatistics{}}}, on
which other(s) could depend?
{quote}
I was thinking the same to avoid redundant computations while computing
multiple statistics. We could implement count as a standalone statistic and use
composition to avoid redundant computations while computing multiple statistics
?
DoubleStorelessUnivariateStatistic add(double d);
{quote}{{{}[...] What's the intended usage?{}}}{\{ }}
{quote}
{{The reason I included this signature is to possibly support chaining during
the add calls like}}
{code:java}
Mean m = new Mean();
double mean = m.add(1).add(2).add(3).getAsDouble();
double mean = Stream.of(1.0, 2.0, 3.0).map(Mean::add).getAsDouble();{code}
{quote}[...] E.g. is "Storeless" a required part of the name? Or is it an
"implementation detail"?
{quote}
I changed the interface name to DoubleStorelessUnivariateStatistic since I feel
we might actually need 3 interfaces, IntStorelessSummaryStatistics for integer
data and LongStorelessSummaryStatistics for long data, similar to JDK
SummaryStatistics. I feel its better to have Storeless as part of the interface
name to make it clear that it is a storeless implementation, so that users are
aware that they cannot do certain things like compute rolling statistics for
instance. But I do not have a strong opinion on this and curious to hear other
arguments against the naming (e.g. if the name is too verbose)
{quote}[...] be more restrictive in order to forbid meaningless combinations?
{quote}
Not sure if I understand the requirement correctly. What are the kinds of
combinations we want to restrict here ?
was (Author: JIRAUSER299640):
{quote}[...] What about {{Count}} being a {{{}DoubleStorelessStatistics{}}}, on
which other(s) could depend?
{quote}
I was thinking the same to avoid redundant computations while computing
multiple statistics. We could implement count as a standalone statistic and use
composition to avoid redundant computations while computing multiple statistics
?
DoubleStorelessUnivariateStatistic add(double d);
{quote}{{[...] What's the intended usage?}}{{ }}
{quote}
{{The reason I included this signature is to possibly support chaining during
the add calls like}}
{code:java}
Mean m = new Mean();
double mean = m.add(1).add(2).add(3).getAsDouble();
double mean = Stream.of(1.0, 2.0, 3.0).map(Mean::add).getAsDouble();{code}
{quote}
[...] E.g. is "Storeless" a required part of the name? Or is it an
"implementation detail"?
{quote}
I changed the interface name to DoubleStorelessUnivariateStatistic since I feel
we might actually need 3 interfaces, IntStorelessSummaryStatistics for integer
data and LongSummaryStatistics for long data, similar to JDK SummaryStatistics.
I feel its better to have Storeless as part of the interface name to make it
clear that it is a storeless implementation, so that users are aware that they
cannot do certain things like compute rolling statistics for instance. But I do
not have a strong opinion on this and curious to hear other arguments against
the naming (e.g. if the name is too verbose)
{quote}
[...] be more restrictive in order to forbid meaningless combinations?
{quote}
Not sure if I understand the requirement correctly. What are the kinds of
combinations we want to restrict here ?
> Implementation of Univariate Statistics
> ---
>
> Key: STATISTICS-71
> URL: https://issues.apache.org/jira/browse/STATISTICS-71
> Project: Commons Statistics
> Issue Type: Task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> Jira ticket to track the implementation of the Univariate statistics required
> for the updated SummaryStatistics API.
> The implementation would be "storeless". It should be used for calculating
> statistics that can be computed in one pass through the data without storing
> the sample values.
> Currently I have the definition of API as (this might evolve as I continue
> working)
> {code:java}
> public interface DoubleStorelessUnivariateStatistic extends DoubleSupplier {
> DoubleStorelessUnivariateStatistic add(double v);
> long getCount();
> void combine(DoubleStorelessUnivariateStatistic other);
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-lang] orionlibs commented on a diff in pull request #1069: LANG-1647
orionlibs commented on code in PR #1069:
URL: https://github.com/apache/commons-lang/pull/1069#discussion_r1249605535
##
src/test/java/org/apache/commons/lang3/exception/ExceptionUtilsTest.java:
##
@@ -850,4 +850,40 @@ public void testWrapAndUnwrapThrowable() {
final Throwable t = assertThrows(Throwable.class, () ->
ExceptionUtils.wrapAndThrow(new TestThrowable()));
assertTrue(ExceptionUtils.hasCause(t, TestThrowable.class));
}
+
+@Test
+public void testIsChecked_unchecked() {
+final boolean result = ExceptionUtils.isChecked(new
IllegalArgumentException());
Review Comment:
@garydgregory so, I don't need to create local variables if the assertion
looks like this:
assertTrue(ExceptionUtils.isChecked(new IllegalArgumentException()));
Is that what you mean? Is that what I need to do for this 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] [Commented] (STATISTICS-71) Implementation of Univariate Statistics
[
https://issues.apache.org/jira/browse/STATISTICS-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739388#comment-17739388
]
Anirudh Joshi commented on STATISTICS-71:
-
{quote}[...] What about {{Count}} being a {{{}DoubleStorelessStatistics{}}}, on
which other(s) could depend?
{quote}
I was thinking the same to avoid redundant computations while computing
multiple statistics. We could implement count as a standalone statistic and use
composition to avoid redundant computations while computing multiple statistics
?
DoubleStorelessUnivariateStatistic add(double d);
{quote}{{[...] What's the intended usage?}}{{ }}
{quote}
{{The reason I included this signature is to possibly support chaining during
the add calls like}}
{code:java}
Mean m = new Mean();
double mean = m.add(1).add(2).add(3).getAsDouble();
double mean = Stream.of(1.0, 2.0, 3.0).map(Mean::add).getAsDouble();{code}
{quote}
[...] E.g. is "Storeless" a required part of the name? Or is it an
"implementation detail"?
{quote}
I changed the interface name to DoubleStorelessUnivariateStatistic since I feel
we might actually need 3 interfaces, IntStorelessSummaryStatistics for integer
data and LongSummaryStatistics for long data, similar to JDK SummaryStatistics.
I feel its better to have Storeless as part of the interface name to make it
clear that it is a storeless implementation, so that users are aware that they
cannot do certain things like compute rolling statistics for instance. But I do
not have a strong opinion on this and curious to hear other arguments against
the naming (e.g. if the name is too verbose)
{quote}
[...] be more restrictive in order to forbid meaningless combinations?
{quote}
Not sure if I understand the requirement correctly. What are the kinds of
combinations we want to restrict here ?
> Implementation of Univariate Statistics
> ---
>
> Key: STATISTICS-71
> URL: https://issues.apache.org/jira/browse/STATISTICS-71
> Project: Commons Statistics
> Issue Type: Task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> Jira ticket to track the implementation of the Univariate statistics required
> for the updated SummaryStatistics API.
> The implementation would be "storeless". It should be used for calculating
> statistics that can be computed in one pass through the data without storing
> the sample values.
> Currently I have the definition of API as (this might evolve as I continue
> working)
> {code:java}
> public interface DoubleStorelessUnivariateStatistic extends DoubleSupplier {
> DoubleStorelessUnivariateStatistic add(double v);
> long getCount();
> void combine(DoubleStorelessUnivariateStatistic other);
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-lang] garydgregory commented on a diff in pull request #1069: LANG-1647
garydgregory commented on code in PR #1069:
URL: https://github.com/apache/commons-lang/pull/1069#discussion_r1249606014
##
src/test/java/org/apache/commons/lang3/exception/ExceptionUtilsTest.java:
##
@@ -850,4 +850,40 @@ public void testWrapAndUnwrapThrowable() {
final Throwable t = assertThrows(Throwable.class, () ->
ExceptionUtils.wrapAndThrow(new TestThrowable()));
assertTrue(ExceptionUtils.hasCause(t, TestThrowable.class));
}
+
+@Test
+public void testIsChecked_unchecked() {
+final boolean result = ExceptionUtils.isChecked(new
IllegalArgumentException());
Review 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
[GitHub] [commons-lang] orionlibs commented on a diff in pull request #1069: LANG-1647
orionlibs commented on code in PR #1069:
URL: https://github.com/apache/commons-lang/pull/1069#discussion_r1249605535
##
src/test/java/org/apache/commons/lang3/exception/ExceptionUtilsTest.java:
##
@@ -850,4 +850,40 @@ public void testWrapAndUnwrapThrowable() {
final Throwable t = assertThrows(Throwable.class, () ->
ExceptionUtils.wrapAndThrow(new TestThrowable()));
assertTrue(ExceptionUtils.hasCause(t, TestThrowable.class));
}
+
+@Test
+public void testIsChecked_unchecked() {
+final boolean result = ExceptionUtils.isChecked(new
IllegalArgumentException());
Review Comment:
@garydgregory so, I don't need to create local variables if the assertion
looks like this:
assertTrue(ExceptionUtils.isChecked(new IllegalArgumentException()));
Is that what you mean?
--
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-71) Implementation of Univariate Statistics
[
https://issues.apache.org/jira/browse/STATISTICS-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anirudh Joshi updated STATISTICS-71:
Description:
Jira ticket to track the implementation of the Univariate statistics required
for the updated SummaryStatistics API.
The implementation would be "storeless". It should be used for calculating
statistics that can be computed in one pass through the data without storing
the sample values.
Currently I have the definition of API as (this might evolve as I continue
working)
{code:java}
public interface DoubleStorelessUnivariateStatistic extends DoubleSupplier {
DoubleStorelessUnivariateStatistic add(double v);
long getCount();
void combine(DoubleStorelessUnivariateStatistic other);
} {code}
was:
Jira ticket to track the implementation of the Univariate statistics required
for the updated SummaryStatistics API.
The implementation would be "storeless". It should be used for calculating
statistics that can be computed in one pass through the data without storing
the sample values.
Currently I have the definition of API as (this might evolve as I continue
working)
{code:java}
public interface DoubleStorelessUnivariateStatistic extends DoubleSupplier {
DoubleStorelessUnivariateStatistic add(double v);
long getCount();
void combine(StorelessUnivariateStatistic other);
} {code}
> Implementation of Univariate Statistics
> ---
>
> Key: STATISTICS-71
> URL: https://issues.apache.org/jira/browse/STATISTICS-71
> Project: Commons Statistics
> Issue Type: Task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> Jira ticket to track the implementation of the Univariate statistics required
> for the updated SummaryStatistics API.
> The implementation would be "storeless". It should be used for calculating
> statistics that can be computed in one pass through the data without storing
> the sample values.
> Currently I have the definition of API as (this might evolve as I continue
> working)
> {code:java}
> public interface DoubleStorelessUnivariateStatistic extends DoubleSupplier {
> DoubleStorelessUnivariateStatistic add(double v);
> long getCount();
> void combine(DoubleStorelessUnivariateStatistic other);
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-lang] garydgregory commented on a diff in pull request #1069: LANG-1647
garydgregory commented on code in PR #1069:
URL: https://github.com/apache/commons-lang/pull/1069#discussion_r1249604113
##
src/test/java/org/apache/commons/lang3/exception/ExceptionUtilsTest.java:
##
@@ -850,4 +850,40 @@ public void testWrapAndUnwrapThrowable() {
final Throwable t = assertThrows(Throwable.class, () ->
ExceptionUtils.wrapAndThrow(new TestThrowable()));
assertTrue(ExceptionUtils.hasCause(t, TestThrowable.class));
}
+
+@Test
+public void testIsChecked_unchecked() {
+final boolean result = ExceptionUtils.isChecked(new
IllegalArgumentException());
Review Comment:
> @garydgregory so, should I create new local variables for each case?
You've got it backward.
--
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 #1069: LANG-1647
orionlibs commented on code in PR #1069:
URL: https://github.com/apache/commons-lang/pull/1069#discussion_r1249567341
##
src/test/java/org/apache/commons/lang3/exception/ExceptionUtilsTest.java:
##
@@ -850,4 +850,40 @@ public void testWrapAndUnwrapThrowable() {
final Throwable t = assertThrows(Throwable.class, () ->
ExceptionUtils.wrapAndThrow(new TestThrowable()));
assertTrue(ExceptionUtils.hasCause(t, TestThrowable.class));
}
+
+@Test
+public void testIsChecked_unchecked() {
+final boolean result = ExceptionUtils.isChecked(new
IllegalArgumentException());
Review Comment:
@garydgregory what should I do for this PR to be successful?
--
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 pull request #1071: LANG-1695
orionlibs commented on PR #1071: URL: https://github.com/apache/commons-lang/pull/1071#issuecomment-1616698137 @garydgregory also there are many many open tickets in JIRA for many projects that have actually been completed, but they are still open, with no assignees or comments or anything. -- 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 pull request #1071: LANG-1695
orionlibs commented on PR #1071: URL: https://github.com/apache/commons-lang/pull/1071#issuecomment-1616697860 @garydgregory I am new to open source contribution and a week ago I started with Apache. I applied for a JIRA account, but I was denied one (with no reason given). So, I cannot login to JIRA -- 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 closed pull request #1072: LANG-1658
orionlibs closed pull request #1072: LANG-1658 URL: https://github.com/apache/commons-lang/pull/1072 -- 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 #1069: LANG-1647
orionlibs commented on code in PR #1069:
URL: https://github.com/apache/commons-lang/pull/1069#discussion_r1249563312
##
src/test/java/org/apache/commons/lang3/exception/ExceptionUtilsTest.java:
##
@@ -850,4 +850,40 @@ public void testWrapAndUnwrapThrowable() {
final Throwable t = assertThrows(Throwable.class, () ->
ExceptionUtils.wrapAndThrow(new TestThrowable()));
assertTrue(ExceptionUtils.hasCause(t, TestThrowable.class));
}
+
+@Test
+public void testIsChecked_unchecked() {
+final boolean result = ExceptionUtils.isChecked(new
IllegalArgumentException());
Review Comment:
@garydgregory so, should I create new local variables for each case?
--
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 pull request #1075: ArchUtils refactoring
orionlibs commented on PR #1075: URL: https://github.com/apache/commons-lang/pull/1075#issuecomment-1616694182 @garydgregory thank you. So, should I close this 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
[GitHub] [commons-io] garydgregory closed pull request #74: Add new function: byteCountToDisplayRoundedSize
garydgregory closed pull request #74: Add new function: byteCountToDisplayRoundedSize URL: https://github.com/apache/commons-io/pull/74 -- 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-io] garydgregory commented on pull request #74: Add new function: byteCountToDisplayRoundedSize
garydgregory commented on PR #74: URL: https://github.com/apache/commons-io/pull/74#issuecomment-1616692171 Closing, moving to Commons Text (presumably). -- 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-io] garydgregory closed pull request #102: Improvement of FileUtils test coverage
garydgregory closed pull request #102: Improvement of FileUtils test coverage URL: https://github.com/apache/commons-io/pull/102 -- 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-io] garydgregory commented on pull request #457: Implemented overloaded readFileToByteArray() method
garydgregory commented on PR #457: URL: https://github.com/apache/commons-io/pull/457#issuecomment-1616691695 Closing, no reply in 3 weeks. -- 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-io] garydgregory closed pull request #457: Implemented overloaded readFileToByteArray() method
garydgregory closed pull request #457: Implemented overloaded readFileToByteArray() method URL: https://github.com/apache/commons-io/pull/457 -- 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 #1071: LANG-1695
garydgregory commented on PR #1071: URL: https://github.com/apache/commons-lang/pull/1071#issuecomment-1616689605 @orionlibs Thank you for the PR. Would you please reply in the Jira ticket to the comment https://issues.apache.org/jira/browse/LANG-1695?focusedCommentId=17709278=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17709278 We really need to make sure we are not creating trouble for ourselves ;-) -- 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] (LANG-1658) Create new method to search for numbers within string
[ https://issues.apache.org/jira/browse/LANG-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739381#comment-17739381 ] Gary D. Gregory commented on LANG-1658: --- 1: I really don't think https://issues.apache.org/jira/browse/LANG-1658 belongs in Commons Lang, maybe in Commons Number, or Commons Text, but not here. The best place to discuss this is on the dev mailing list. > Create new method to search for numbers within string > - > > Key: LANG-1658 > URL: https://issues.apache.org/jira/browse/LANG-1658 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Mikhail Polivakha >Priority: Minor > > I have encountered in my work with a requirement to parse string and fetch > all of the numbers from it (may be integers, may be float). I guess, perhaps > it will be helpful for comunity. > Example of use cases: > 1) Input: " Duration : 12.3 days, 34minutes" > Output: [12.3, 34.0] > 2) Input: " Weight is 76 and height is 180.2 cm" > Output : [76.0, 180.2] > 3) Input: "Between 12.22 and 90" > Output: [12.22, 90] > 4) Input: "First: 1289.0 Second: 9283.112 Third: 281" > Output : [1289.0, 9283.112, 281.0] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (LANG-1658) Create new method to search for numbers within string
[ https://issues.apache.org/jira/browse/LANG-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739381#comment-17739381 ] Gary D. Gregory edited comment on LANG-1658 at 7/2/23 2:49 PM: --- 1: I really don't think this belongs in Commons Lang, maybe in Commons Number, or Commons Text, but not here. The best place to discuss this is on the dev mailing list. was (Author: garydgregory): 1: I really don't think https://issues.apache.org/jira/browse/LANG-1658 belongs in Commons Lang, maybe in Commons Number, or Commons Text, but not here. The best place to discuss this is on the dev mailing list. > Create new method to search for numbers within string > - > > Key: LANG-1658 > URL: https://issues.apache.org/jira/browse/LANG-1658 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Mikhail Polivakha >Priority: Minor > > I have encountered in my work with a requirement to parse string and fetch > all of the numbers from it (may be integers, may be float). I guess, perhaps > it will be helpful for comunity. > Example of use cases: > 1) Input: " Duration : 12.3 days, 34minutes" > Output: [12.3, 34.0] > 2) Input: " Weight is 76 and height is 180.2 cm" > Output : [76.0, 180.2] > 3) Input: "Between 12.22 and 90" > Output: [12.22, 90] > 4) Input: "First: 1289.0 Second: 9283.112 Third: 281" > Output : [1289.0, 9283.112, 281.0] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (LANG-1658) Create new method to search for numbers within string
[ https://issues.apache.org/jira/browse/LANG-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated LANG-1658: -- Affects Version/s: (was: 3.12.0) > Create new method to search for numbers within string > - > > Key: LANG-1658 > URL: https://issues.apache.org/jira/browse/LANG-1658 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Mikhail Polivakha >Priority: Minor > > I have encountered in my work with a requirement to parse string and fetch > all of the numbers from it (may be integers, may be float). I guess, perhaps > it will be helpful for comunity. > Example of use cases: > 1) Input: " Duration : 12.3 days, 34minutes" > Output: [12.3, 34.0] > 2) Input: " Weight is 76 and height is 180.2 cm" > Output : [76.0, 180.2] > 3) Input: "Between 12.22 and 90" > Output: [12.22, 90] > 4) Input: "First: 1289.0 Second: 9283.112 Third: 281" > Output : [1289.0, 9283.112, 281.0] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [commons-lang] garydgregory commented on pull request #1072: LANG-1658
garydgregory commented on PR #1072: URL: https://github.com/apache/commons-lang/pull/1072#issuecomment-1616687687 1: I really don't think https://issues.apache.org/jira/browse/LANG-1658 belongs in Commons Lang, maybe in Commons Number, or Commons Text, but not here. The best place to discuss this is on the dev mailing list. -- 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 a diff in pull request #1069: LANG-1647
garydgregory commented on code in PR #1069:
URL: https://github.com/apache/commons-lang/pull/1069#discussion_r1249556051
##
src/test/java/org/apache/commons/lang3/exception/ExceptionUtilsTest.java:
##
@@ -850,4 +850,40 @@ public void testWrapAndUnwrapThrowable() {
final Throwable t = assertThrows(Throwable.class, () ->
ExceptionUtils.wrapAndThrow(new TestThrowable()));
assertTrue(ExceptionUtils.hasCause(t, TestThrowable.class));
}
+
+@Test
+public void testIsChecked_unchecked() {
+final boolean result = ExceptionUtils.isChecked(new
IllegalArgumentException());
Review Comment:
@orionlibs
There is no need for a single-use local variable here and in other new tests.
--
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 #1069: LANG-1647
garydgregory commented on PR #1069: URL: https://github.com/apache/commons-lang/pull/1069#issuecomment-1616686083 -1 as is, in https://issues.apache.org/jira/browse/LANG-1647 the description reads: ``` The idea it's have a function that check if a given throwable is a checked exception. There are some similar function in ConcurrentUtils, but have package visibility and return the same exception. Seem logic have this verification in the class that have this responsibility - ExceptionUtils ``` `ConcurrentUtils` and anywhere else in Commons Lang should reuse these new APIs, otherwise, the PR just creates duplication of existing code patterns. -- 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 #1075: ArchUtils refactoring
garydgregory commented on PR #1075: URL: https://github.com/apache/commons-lang/pull/1075#issuecomment-1616683936 @orionlibs Thank you for your PR. -1: IMO, this is a case where you have to consider making it evident to people reading the code what it is we support. One method per processor type makes it obvious as soon as you look at the class. I would say that this is a rare case, where a tiny amount of code duplication (calling the ctor) is worth it because: The code is only invoked once (per class loader) and the method names serve as "code as documentation". Each private method _could_ have a Javadoc added to make it even nicer, but I'll leave that as a TODO for anyone that wants to do that. -- 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 #1078: Update Javadoc for the insert methods in ArrayUtils
garydgregory commented on PR #1078: URL: https://github.com/apache/commons-lang/pull/1078#issuecomment-1616684102 @orionlibs Merged, TY for the 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
[GitHub] [commons-lang] orionlibs closed pull request #1076: refactored an addAll method in ArrayUtils
orionlibs closed pull request #1076: refactored an addAll method in ArrayUtils URL: https://github.com/apache/commons-lang/pull/1076 -- 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 closed pull request #1077: refactored ArrayUtils to reuse the getLength(Object array) method
orionlibs closed pull request #1077: refactored ArrayUtils to reuse the getLength(Object array) method URL: https://github.com/apache/commons-lang/pull/1077 -- 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 #1077: refactored ArrayUtils to reuse the getLength(Object array) method
orionlibs commented on code in PR #1077: URL: https://github.com/apache/commons-lang/pull/1077#discussion_r1249553125 ## src/main/java/org/apache/commons/lang3/ArrayUtils.java: ## @@ -655,7 +655,7 @@ private static Object add(final Object array, final int index, final Object elem Array.set(joinedArray, 0, element); return joinedArray; } -final int length = Array.getLength(array); +final int length = getLength(array); Review Comment: just for code reuse. This class already has a getLength method. Why not reuse it inside this class? That was my thought. Not nulls. But it is OK. I will close it -- 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 a diff in pull request #1077: refactored ArrayUtils to reuse the getLength(Object array) method
garydgregory commented on code in PR #1077:
URL: https://github.com/apache/commons-lang/pull/1077#discussion_r1249551867
##
src/main/java/org/apache/commons/lang3/ArrayUtils.java:
##
@@ -655,7 +655,7 @@ private static Object add(final Object array, final int
index, final Object elem
Array.set(joinedArray, 0, element);
return joinedArray;
}
-final int length = Array.getLength(array);
+final int length = getLength(array);
Review Comment:
-1: Why? `array` can't be null here.
##
src/main/java/org/apache/commons/lang3/ArrayUtils.java:
##
@@ -1668,7 +1668,7 @@ public static boolean containsAny(final Object[] array,
final Object... objectsT
*/
private static Object copyArrayGrow1(final Object array, final Class
newArrayComponentType) {
if (array != null) {
-final int arrayLength = Array.getLength(array);
+final int arrayLength = getLength(array);
Review Comment:
-1: Makes no sense since you're in a block where `array` can't be null.
--
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 merged pull request #1078: Update Javadoc for the insert methods in ArrayUtils
garydgregory merged PR #1078: URL: https://github.com/apache/commons-lang/pull/1078 -- 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
[ https://issues.apache.org/jira/browse/IMAGING-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739377#comment-17739377 ] Gary Lucas commented on IMAGING-356: The glitch in the Allocator class is that there are a couple of non UTF-8 valid characters in the Javadoc. So it doesn't affect anything code-wise and doesn't urgently require attention. I might submit a PR at some point. The speed and memory test isn't a JUnit test. It's a tool for developers. It's remarkable how many "good ideas" about improving performance do no such thing, So it was useful to have an unambiguous benchmark to measure stuff. We were interested in looking at aerial photographs for geospatial analysis logic. I spent weeks trying to get the Imaging performance to the point where it was useful in an application. It was quite the learning experience Since then, I always encourage folks to do benchmarking as well as JUnit tests. > 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 > > 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-net] garydgregory commented on a diff in pull request #161: Add Base64 missing tests and documentation fixes
garydgregory commented on code in PR #161:
URL: https://github.com/apache/commons-net/pull/161#discussion_r1249526432
##
src/test/java/org/apache/commons/net/util/Base64Test.java:
##
@@ -208,9 +241,10 @@ public void testEncodeObject() {
}
@Test
-@Ignore
public void testEncodeToString() {
-fail("Not yet implemented");
+final Base64 base64 = new Base64();
+final byte[] bytesToEncode = new byte[] {'l', 'i', 'g', 'h', 't', ' ',
'w', 'o', 'r'};
Review Comment:
> Random question here; was the example intended to be "light work" encoded?
Asking as it was used in the other tests, but doesn't really matter as this
test is working fine
In the future, we could split up test method per test source, like
`testWikipediaExamplesAbc`, `testRfc123FeatureX`, and so on.
--
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-net] garydgregory merged pull request #161: Add Base64 missing tests and documentation fixes
garydgregory merged PR #161: URL: https://github.com/apache/commons-net/pull/161 -- 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
[ https://issues.apache.org/jira/browse/IMAGING-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739375#comment-17739375 ] Gary D. Gregory commented on IMAGING-356: - [~gwlucas] I did commit the change to master. I did not run the test you mention, I ran a full build using the default maven goal which lists all our checks. I have not seen complaints about the Allocator class. Note that this class was introduced to address a list of issues revealed by the ossfuzz integration. There are a handful of issues remaining. > 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 > > 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)
[jira] [Commented] (MATH-1394) Implementation of DIRECT global optimizer
[ https://issues.apache.org/jira/browse/MATH-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739374#comment-17739374 ] Kiriakos Marantidis commented on MATH-1394: --- So there is a step where we cluster some points. I was wondering if I can use the clustering apis that common-maths have or if I need to do some from scratch implementation. Also since we have multiple times generation of points, sorting of these points and merging of these points with an existing set of points I think the only efficient data structure to handle such data is a Tree. > Implementation of DIRECT global optimizer > - > > Key: MATH-1394 > URL: https://issues.apache.org/jira/browse/MATH-1394 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.5, 3.6 >Reporter: Kevin A. Burton >Priority: Major > Fix For: 4.X > > Attachments: DIRECT.png, GLOBAL.png > > > An open source implementation of the DIRECT global optimizer, described by > Jones, Perttunen and Stuckmann, implementing > math3.optim.nonlinear.scalar.MultivariateOptimizer, is available as > DIRECTOptimizer.java at > https://github.com/edwardkort/WWIDesigner/tree/optimizer/WWIDesigner/src/main/com/wwidesigner/math. > There are also three variants of the algorithm on that page: > DIRECT_L_Optimizer implements DIRECT-L by Gablonsky and Kelley, > DIRECT1Optimizer changes which sides are chosen for dividing, and > DIRECTCOptimizer adds alternative ways to select potentially-optimal > hyperrectangles. > DIRECT is not as fast as BOBYQA, but is better at finding a global minimum in > a field of many local minima. > JUnit tests for all of these, using standard optimizer test functions, are > available in > https://github.com/edwardkort/WWIDesigner/tree/optimizer/WWIDesigner/src/test/com/wwidesigner/math. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NET-712) Image are not uploaded correctly
[ https://issues.apache.org/jira/browse/NET-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] qwerty287 resolved NET-712. --- Resolution: Not A Problem Just set file type to BINARY > Image are not uploaded correctly > > > Key: NET-712 > URL: https://issues.apache.org/jira/browse/NET-712 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.8.0 > Environment: Android and Manjaro, running in IntelliJ with Gradle and > OpenJDK 17 >Reporter: qwerty287 >Priority: Major > Attachments: FTPImageExample.kt > > > If I try to upload images (tested with PNG and JPEG), the images are not > correctly stored on the server. Instead, they are missing one byte. Two > examples: > # The original file had a size of 35518 bytes, once I transferred it using > FTPClient it were 35517 bytes. > # The original file had a size of 45010 bytes, once I transferred it using > FTPClient it were 45009 bytes. > Using a PNG breaks the image completely (viewers can't view it), using a JPEG > makes the photo still viewable, but the files are different (in size/MD5 > fingerprint). > This affects all PNG and JPEG files, but any other file works. They have the > same size and MD5 fingerprint. > Maybe related to https://issues.apache.org/jira/browse/NET-409 which was > fixed in 3.0.1, but this occurs on 3.8.0. > > This can be reproduced on Android using FTPClient in an app and on "regular" > JVM (for me OpenJDK 17). The Kotlin file I attached provides a simple > example, but it doesn't contain something special. I executed it using Gradle > (to add NET as dependency) and using IntelliJ's build and run system. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IMAGING-356) TIFF reading extremely slow in version 1.0-SNAPSHOT
[ https://issues.apache.org/jira/browse/IMAGING-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739371#comment-17739371 ] Gary Lucas commented on IMAGING-356: No luck. Same runtime as before... Though the change did reduce the memory use quite a bit. First, to confirm that I tested the right thing... You pushed your changes directly to the master branch? That's where I downloaded code and I did see the commit comment saying "Delegate size". I also stepped through the code just to be sure that a change was in effect. The change I saw looks much more reasonable than the previous approach. Did you try running the ApacheImagingSpeedAndMemoryTest? I wrote it back when I was trying to optimize the speed of the imaging classes (the old Sanselan classes). I tried a lot of different ideas before I got things running at a reasonable speed. It was very helpful. For this test, I tried processing the file called PICT2833.TIF which is included in the project distribution as part of a suite of test files. Gary P.S. On an separate issue, have you been seeing complaints about encoding errors in the Allocator class? I am seeing invalid UTF-8 characters in the Javadoc comments on lines 144 and 165. > 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 > > 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)
[jira] [Commented] (STATISTICS-71) Implementation of Univariate Statistics
[
https://issues.apache.org/jira/browse/STATISTICS-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739369#comment-17739369
]
Gilles Sadowski commented on STATISTICS-71:
---
Shouldn't the signature of
{code}
void combine(StorelessUnivariateStatistic other);
{code}
be more restrictive in order to forbid meaningless combinations?
> Implementation of Univariate Statistics
> ---
>
> Key: STATISTICS-71
> URL: https://issues.apache.org/jira/browse/STATISTICS-71
> Project: Commons Statistics
> Issue Type: Task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> Jira ticket to track the implementation of the Univariate statistics required
> for the updated SummaryStatistics API.
> The implementation would be "storeless". It should be used for calculating
> statistics that can be computed in one pass through the data without storing
> the sample values.
> Currently I have the definition of API as (this might evolve as I continue
> working)
> {code:java}
> public interface DoubleStorelessUnivariateStatistic extends DoubleSupplier {
> DoubleStorelessUnivariateStatistic add(double v);
> long getCount();
> void combine(StorelessUnivariateStatistic other);
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (STATISTICS-71) Implementation of Univariate Statistics
[
https://issues.apache.org/jira/browse/STATISTICS-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739368#comment-17739368
]
Gilles Sadowski commented on STATISTICS-71:
---
Is {{DoubleStorelessUnivariateStatistics}} to be used as a "marker" interface?
If so, what is the use-case?
E.g. is "Storeless" a required part of the name? Or is it an "implementation
detail"?
It seems that alternative (internal) implementations could be built:
{code}
public class StatisticsBuilder {
/**
* @param storeless Whether the instance should be storeless.
* @return the statistics.
*/
public static Mean createMean(boolean storeless) {
return storeless ? StorelessMean.create() : PlainMean.create();
}
}
{code}
> Implementation of Univariate Statistics
> ---
>
> Key: STATISTICS-71
> URL: https://issues.apache.org/jira/browse/STATISTICS-71
> Project: Commons Statistics
> Issue Type: Task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> Jira ticket to track the implementation of the Univariate statistics required
> for the updated SummaryStatistics API.
> The implementation would be "storeless". It should be used for calculating
> statistics that can be computed in one pass through the data without storing
> the sample values.
> Currently I have the definition of API as (this might evolve as I continue
> working)
> {code:java}
> public interface DoubleStorelessUnivariateStatistic extends DoubleSupplier {
> DoubleStorelessUnivariateStatistic add(double v);
> long getCount();
> void combine(StorelessUnivariateStatistic other);
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (STATISTICS-71) Implementation of Univariate Statistics
[
https://issues.apache.org/jira/browse/STATISTICS-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739367#comment-17739367
]
Gilles Sadowski commented on STATISTICS-71:
---
bq. [...] for a simple statistic (min, max, sum) then computing the count is a
waste of resources.
I imagine than an increment by one is a marginal cost wrt the mechanics of
streams.
Even it is not necessary for computing the value, the count may be an
information needed by many users.
bq. [...] you only require one [count].
Indeed, recomputing the same values several times would indicate a design
problem.
What about {{Count}} being a {{DoubleStorelessStatistics}}, on which other(s)
could depend?
When using a "shared" {{Count}} instance (e.g. in a {{SummaryStatistics}}),
we'll have to ensure that all individual statistics can only be updated
together.
> Implementation of Univariate Statistics
> ---
>
> Key: STATISTICS-71
> URL: https://issues.apache.org/jira/browse/STATISTICS-71
> Project: Commons Statistics
> Issue Type: Task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> Jira ticket to track the implementation of the Univariate statistics required
> for the updated SummaryStatistics API.
> The implementation would be "storeless". It should be used for calculating
> statistics that can be computed in one pass through the data without storing
> the sample values.
> Currently I have the definition of API as (this might evolve as I continue
> working)
> {code:java}
> public interface DoubleStorelessUnivariateStatistic extends DoubleSupplier {
> DoubleStorelessUnivariateStatistic add(double v);
> long getCount();
> void combine(StorelessUnivariateStatistic other);
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-net] jkbkupczyk commented on a diff in pull request #161: Add Base64 missing tests and documentation fixes
jkbkupczyk commented on code in PR #161:
URL: https://github.com/apache/commons-net/pull/161#discussion_r1249331794
##
src/main/java/org/apache/commons/net/util/Base64.java:
##
@@ -603,10 +603,10 @@ int avail() {
}
/**
- * Decodes a byte[] containing characters in the Base64 alphabet.
+ * Decodes a byte array containing characters in the Base64 alphabet.
*
* @param pArray A byte array containing Base64 character data
- * @return a byte array containing binary data
+ * @return a byte array containing binary data; will return {@code null}
if provided byte array is null.
Review Comment:
fixed in 7c11889a03a3754a9abd6874cf8b2d06707d0cb9
--
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-net] jkbkupczyk commented on a diff in pull request #161: Add Base64 missing tests and documentation fixes
jkbkupczyk commented on code in PR #161:
URL: https://github.com/apache/commons-net/pull/161#discussion_r1249330003
##
src/main/java/org/apache/commons/net/util/Base64.java:
##
@@ -114,10 +114,10 @@ public class Base64 {
// some state be preserved between calls of encode() and decode().
/**
- * Tests a given byte array to see if it contains only valid characters
within the Base64 alphabet.
+ * Tests a given byte array to see if it contains any valid character
within the Base64 alphabet.
Review Comment:
thanks
--
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] (STATISTICS-71) Implementation of Univariate Statistics
[
https://issues.apache.org/jira/browse/STATISTICS-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739356#comment-17739356
]
Alex Herbert commented on STATISTICS-71:
I am not convinced we require:
{code:java}
long getN();{code}
In cases where you wish for a simple statistic (min, max, sum) then computing
the count is a waste of resources. If you combine several statistics then all
will compute the count and this is also a waste of resources as you only
require one.
> Implementation of Univariate Statistics
> ---
>
> Key: STATISTICS-71
> URL: https://issues.apache.org/jira/browse/STATISTICS-71
> Project: Commons Statistics
> Issue Type: Task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> Jira ticket to track the implementation of the Univariate statistics required
> for the updated SummaryStatistics API.
> The implementation would be "storeless". It should be used for calculating
> statistics that can be computed in one pass through the data without storing
> the sample values.
> Currently I have the definition of API as (this might evolve as I continue
> working)
> {code:java}
> public interface DoubleStorelessUnivariateStatistic extends DoubleSupplier {
> DoubleStorelessUnivariateStatistic add(double v);
> long getCount();
> void combine(StorelessUnivariateStatistic other);
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-net] jkbkupczyk commented on a diff in pull request #161: Add Base64 missing tests and documentation fixes
jkbkupczyk commented on code in PR #161:
URL: https://github.com/apache/commons-net/pull/161#discussion_r1249325364
##
src/test/java/org/apache/commons/net/util/Base64Test.java:
##
@@ -208,9 +241,10 @@ public void testEncodeObject() {
}
@Test
-@Ignore
public void testEncodeToString() {
-fail("Not yet implemented");
+final Base64 base64 = new Base64();
+final byte[] bytesToEncode = new byte[] {'l', 'i', 'g', 'h', 't', ' ',
'w', 'o', 'r'};
Review Comment:
nope, just a random example from [Base64 - Output
Padding](https://en.wikipedia.org/wiki/Base64#Output_padding) page in wikipedia
--
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-net] kinow commented on a diff in pull request #161: Add Base64 missing tests and documentation fixes
kinow commented on code in PR #161:
URL: https://github.com/apache/commons-net/pull/161#discussion_r1249295029
##
src/test/java/org/apache/commons/net/util/Base64Test.java:
##
@@ -208,9 +241,10 @@ public void testEncodeObject() {
}
@Test
-@Ignore
public void testEncodeToString() {
-fail("Not yet implemented");
+final Base64 base64 = new Base64();
+final byte[] bytesToEncode = new byte[] {'l', 'i', 'g', 'h', 't', ' ',
'w', 'o', 'r'};
Review Comment:
Random question here; was the example intended to be "light work" encoded?
:slightly_smiling_face: Asking as it was used in the other tests, but doesn't
really matter as this test is working fine :+1:
##
src/main/java/org/apache/commons/net/util/Base64.java:
##
@@ -114,10 +114,10 @@ public class Base64 {
// some state be preserved between calls of encode() and decode().
/**
- * Tests a given byte array to see if it contains only valid characters
within the Base64 alphabet.
+ * Tests a given byte array to see if it contains any valid character
within the Base64 alphabet.
Review Comment:
Oh, I had to read the code to confirm it. To me the updated text looks
correct, great catch!
##
src/main/java/org/apache/commons/net/util/Base64.java:
##
@@ -603,10 +603,10 @@ int avail() {
}
/**
- * Decodes a byte[] containing characters in the Base64 alphabet.
+ * Decodes a byte array containing characters in the Base64 alphabet.
*
* @param pArray A byte array containing Base64 character data
- * @return a byte array containing binary data
+ * @return a byte array containing binary data; will return {@code null}
if provided byte array is null.
Review Comment:
s/is null/is {@code null}
--
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
