[jira] [Commented] (IO-392) StringSourceStream
[ https://issues.apache.org/jira/browse/IO-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800233#comment-17800233 ] Elliotte Rusty Harold commented on IO-392: -- IMHO this one should be closed. Commons IO is not the right place for XML or other format specific functionality. > StringSourceStream > -- > > Key: IO-392 > URL: https://issues.apache.org/jira/browse/IO-392 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: David Mollitor >Priority: Minor > Attachments: StringStreamSource.java > > > I am included a simple SourceStream for reading XML from a string. Feel free > to close issue if this is not suitable for this library. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] more modern temp file creation and deletion [commons-io]
elharo commented on PR #535: URL: https://github.com/apache/commons-io/pull/535#issuecomment-1868610331 Thanks. I'll look at that. The one test failure on CI looks unrelated: --- Error: Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:3.1.1:deploy (default-deploy) on project commons-io: Failed to deploy artifacts: Could not transfer artifact commons-io:commons-io:pom:2.16.0-20231224.153125-11 from/to apache.snapshots.https (https://repository.apache.org/content/repositories/snapshots): authentication failed for https://repository.apache.org/content/repositories/snapshots/commons-io/commons-io/2.16.0-SNAPSHOT/commons-io-2.16.0-20231224.153125-11.pom, status: 401 Unauthorized -> [Help 1] -- 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
Re: [PR] Use the new methods introduced in Java 1.8 [commons-numbers]
aherbert commented on PR #139: URL: https://github.com/apache/commons-numbers/pull/139#issuecomment-1868575960 Added the benchmark to master. Run using: ``` cd commons-numbers-examples/examples-jmh mvn package -Pexamples-jmh java -jar target/examples-jmh.jar ArithmeticPerformance ``` -- 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
Re: [PR] Use the new methods introduced in Java 1.8 [commons-numbers]
aherbert commented on PR #139: URL: https://github.com/apache/commons-numbers/pull/139#issuecomment-1868574821 Just browsed the JDK 17 source code for the long methods. These use a method from Hacker's Delight (**2nd ed**). So the Hacker's Delight (presumed **1st ed**) method in ArithmeticUtils has been improved. Without access to the book, and a license compatibility check, we cannot use the updated version. But the original is still 15-25x faster than the JDK 8/11 version using BigInteger. -- 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
Re: [PR] Use the new methods introduced in Java 1.8 [commons-numbers]
aherbert commented on PR #139: URL: https://github.com/apache/commons-numbers/pull/139#issuecomment-1868571519 Here are some benchmark results. JDK variants are prefixed with the class that implements the method. TLDR; the JDK is always faster for the int methods. It can be dramatically slower for the long methods. They fixed this in JDK 17. ``` Tested using a MacBook Pro using an Apple M2 Pro CPU. JDK 1.8.0_392, OpenJDK 64-Bit Server VM, 25.392-b08 ArithmeticPerformance.intOp 1024 Integer.divideUnsigned avgt5 499.478 ± 14.720 ns/op ArithmeticPerformance.intOp 1024 divideUnsigned avgt5 765.350 ± 47.075 ns/op ArithmeticPerformance.intOp 1024 Integer.remainderUnsigned avgt5 500.030 ±3.619 ns/op ArithmeticPerformance.intOp 1024 remainderUnsigned avgt5 771.374 ± 33.150 ns/op ArithmeticPerformance.longOp 1024Long.divideUnsigned avgt5 9423.845 ± 2154.701 ns/op ArithmeticPerformance.longOp 1024 divideUnsigned avgt5 766.622 ± 41.090 ns/op ArithmeticPerformance.longOp 1024 Long.remainderUnsigned avgt5 15715.308 ± 3224.676 ns/op ArithmeticPerformance.longOp 1024 remainderUnsigned avgt5 730.340 ± 65.106 ns/op JDK 11.0.21, OpenJDK 64-Bit Server VM, 11.0.21+9 Benchmark (length) (name) Mode Cnt Score Error Units ArithmeticPerformance.intOp 1024 Integer.divideUnsigned avgt5 304.676 ± 1.188 ns/op ArithmeticPerformance.intOp 1024 divideUnsigned avgt5 572.168 ±42.582 ns/op ArithmeticPerformance.intOp 1024 Integer.remainderUnsigned avgt5 315.873 ± 5.194 ns/op ArithmeticPerformance.intOp 1024 remainderUnsigned avgt5 549.925 ±29.060 ns/op ArithmeticPerformance.longOp 1024Long.divideUnsigned avgt5 26664.266 ± 13297.623 ns/op ArithmeticPerformance.longOp 1024 divideUnsigned avgt5 572.840 ±44.454 ns/op ArithmeticPerformance.longOp 1024 Long.remainderUnsigned avgt5 10413.690 ± 1756.904 ns/op ArithmeticPerformance.longOp 1024 remainderUnsigned avgt5 547.748 ±34.804 ns/op JDK 17.0.9, OpenJDK 64-Bit Server VM, 17.0.9+9 ArithmeticPerformance.intOp 1024 Integer.divideUnsigned avgt5 304.743 ± 2.939 ns/op ArithmeticPerformance.intOp 1024 divideUnsigned avgt5 595.448 ± 26.346 ns/op ArithmeticPerformance.intOp 1024 Integer.remainderUnsigned avgt5 312.449 ± 0.673 ns/op ArithmeticPerformance.intOp 1024 remainderUnsigned avgt5 547.708 ± 22.514 ns/op ArithmeticPerformance.longOp 1024Long.divideUnsigned avgt5 418.294 ± 21.639 ns/op ArithmeticPerformance.longOp 1024 divideUnsigned avgt5 595.529 ± 28.412 ns/op ArithmeticPerformance.longOp 1024 Long.remainderUnsigned avgt5 438.290 ± 13.524 ns/op ArithmeticPerformance.longOp 1024 remainderUnsigned avgt5 499.466 ± 27.701 ns/op ``` It seems that performing the int divide using conversion to a long is faster than the method to avoid long arithmetic. But the BigInteger divide was only fixed in JDK 17. I would recommend: dropping the int divide variants and delegating to the JDK methods; and keeping the long divide variants. A note can be added to the javadoc that the equivalent method in the JDK changed from JDK 11 to 17 to avoid BigInteger arithmetic. I do not think we should add a deprecated notice to the method until all supported versions of the JDK are comparable in speed. Note: The int results would be more interesting on a CPU that does not support native long division. -- 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
Re: [PR] Use the new methods introduced in Java 1.8 [commons-numbers]
aherbert commented on PR #139: URL: https://github.com/apache/commons-numbers/pull/139#issuecomment-1868555695 I agree. ArithmeticUtils predates JDK 8. I imagine it was ported from Math to Numbers without knowing that JDK 8 had equivalent methods. I'll do a performance test, then we can either merge this PR, or update the code with comments on the performance vs the JDK methods. -- 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
Re: [PR] Use the new methods introduced in Java 1.8 [commons-numbers]
sebbASF commented on PR #139: URL: https://github.com/apache/commons-numbers/pull/139#issuecomment-1868554318 If the reason we don't use the JDK methods is performance, this should be explicitly noted in the source so future maintainers are aware. -- 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
Re: [PR] Use the new methods introduced in Java 1.8 [commons-numbers]
aherbert commented on PR #139: URL: https://github.com/apache/commons-numbers/pull/139#issuecomment-1868552071 I would be wary of this simplification without a performance test. In the Numbers class the int methods do not use long arithmetic. The long methods do not use BigInteger. This is unlike those methods in my JDK 8 source code which do and _may_ be slower. A quick check in JDK 21 finds this is still not an intrinsic method [1]. Note that the Numbers methods are based on the Hacker's Delight book which is not free, thus it is not easy to check the implementation against the source. However, there is frequent use of Hacker's Delight in the JDK source. So I wonder why they have not use this trick here. I can create a quick JMH benchmark to test the Numbers methods against the JDK. The int method may not be faster as long divide should be supported on most hardware. But avoiding BigInteger divide may be noticeable. Alex [1] [VM Intrinsics Explorer - HotSpot Intrinsics for OpenJDK21](https://chriswhocodes.com/hotspot_intrinsics_openjdk21.html) -- 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
Re: [PR] Bump org.apache.commons:commons-parent from 64 to 65 [commons-fileupload]
garydgregory closed pull request #257: Bump org.apache.commons:commons-parent from 64 to 65 URL: https://github.com/apache/commons-fileupload/pull/257 -- 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
Re: [PR] Bump org.apache.commons:commons-parent from 64 to 65 [commons-fileupload]
garydgregory commented on PR #257: URL: https://github.com/apache/commons-fileupload/pull/257#issuecomment-1868547626 Closing: Already done. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] more modern temp file creation and deletion [commons-io]
garydgregory commented on PR #535: URL: https://github.com/apache/commons-io/pull/535#issuecomment-1868546472 @elharo Toward this type of effort, I refactored some tests a while back to extend `AbstractTempDirTest`. Perhaps this class should do the same. -- 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] (CODEC-316) Support for yescrypt
[
https://issues.apache.org/jira/browse/CODEC-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800194#comment-17800194
]
Gary D. Gregory commented on CODEC-316:
---
Hello [~technobcn]
Thank you for your request.
Feel free to provide a PR on GitHub.
> Support for yescrypt
>
>
> Key: CODEC-316
> URL: https://issues.apache.org/jira/browse/CODEC-316
> Project: Commons Codec
> Issue Type: Wish
>Reporter: Guillermo Grandes
>Priority: Major
>
> I have recently been aware (although it's not something new ??2021??) of the
> switch ^[3]^ to yescrypt ^[1]^ from scrypt/sha512crypt ^[4]^ for shadow
> passwords on Linux distributions such as Fedora, Debian, Ubuntu and Arch. I
> have not found the porting/implementation in commons-codec like
> org.apache.commons.codec.digest.Sha2Crypt, nor a Jira ticket about it.
> It would be nice to have support for yescrypt {^}[2]{^}.
> Output description {^}[5]{^}:
> {noformat}
> Prefix
> "$y$"
> Hashed passphrase format
> \$y\$[./A-Za-z0-9]+\$[./A-Za-z0-9]{,86}\$[./A-Za-z0-9]{43}
> Maximum passphrase length
> unlimited
> Hash size
> 256 bits
> Salt size
> up to 512 (128+ recommended) bits
> CPU time cost parameter
> 1 to 11 (logarithmic)
> {noformat}
> Test vectors:
> {noformat}
> yescrypt("test")=$y$j9T$UcqCeDUQFBu6eDpvTJWXL.$nfThj9aJvXBk3nmdKQqtvMGkElHH6czHg7zbiw7lSBC
> yescrypt("test")=$y$j9T$yzE3Bw20v45HTM16muFqi1$5TZjNm3236kfMfJVPg98dcH8R0FsprhXdTEdvG/MxJ7
> {noformat}
> References:
> # yescrypt - scalable KDF and password hashing scheme
> [https://www.openwall.com/yescrypt/]
> # yescrypt - C source code
> [https://github.com/openwall/yescrypt]
> # Fedora change log - yescrypt as default hashing for shadow
> [https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow]
> # Sha2Scrypt Javadoc - Apache Commons Codec
> [https://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/digest/Sha2Crypt.html]
> # man crypt(5)
> [https://manpages.debian.org/bookworm/libcrypt-dev/crypt.5.en.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] Use the new methods introduced in Java 1.8 [commons-numbers]
sebbASF opened a new pull request, #139: URL: https://github.com/apache/commons-numbers/pull/139 (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
Re: [PR] GEOMETRY-110 [commons-geometry]
agoss94 commented on PR #225: URL: https://github.com/apache/commons-geometry/pull/225#issuecomment-1868505809 Thanks @darkma773r I think I am mostly done with all remarks. There is one other thing we should discuss. The original paper [Quickhull](https://dl.acm.org/doi/pdf/10.1145/235815.235821) and this source here [Implementing Quickhull] (http://media.steampowered.com/apps/valve/2014/DirkGregorius_ImplementingQuickHull.pdf) mention facet merging as an error handling strategy. The qhull documentation has similar strategies [Qhull Imprecision](http://www.qhull.org/html/qh-impre.htm). Currently we joggle the input in some place, but leave all vertices fixed. Also we do not merge any facets as can be seen in the unit cube test. I should at least mention, that most sources assume facet merging to be a superior error handling strategy compared to joggling input. The strategy itself is relatively straight forward to understand although it is not immediately obvious how this would fit into our current implementation. -- 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] (CODEC-316) Support for yescrypt
Guillermo Grandes created CODEC-316:
---
Summary: Support for yescrypt
Key: CODEC-316
URL: https://issues.apache.org/jira/browse/CODEC-316
Project: Commons Codec
Issue Type: Wish
Reporter: Guillermo Grandes
I have recently been aware (although it's not something new ??2021??) of the
switch ^[3]^ to yescrypt ^[1]^ from scrypt/sha512crypt ^[4]^ for shadow
passwords on Linux distributions such as Fedora, Debian, Ubuntu and Arch. I
have not found the porting/implementation in commons-codec like
org.apache.commons.codec.digest.Sha2Crypt, nor a Jira ticket about it.
It would be nice to have support for yescrypt {^}[2]{^}.
Output description {^}[5]{^}:
{noformat}
Prefix
"$y$"
Hashed passphrase format
\$y\$[./A-Za-z0-9]+\$[./A-Za-z0-9]{,86}\$[./A-Za-z0-9]{43}
Maximum passphrase length
unlimited
Hash size
256 bits
Salt size
up to 512 (128+ recommended) bits
CPU time cost parameter
1 to 11 (logarithmic)
{noformat}
Test vectors:
{noformat}
yescrypt("test")=$y$j9T$UcqCeDUQFBu6eDpvTJWXL.$nfThj9aJvXBk3nmdKQqtvMGkElHH6czHg7zbiw7lSBC
yescrypt("test")=$y$j9T$yzE3Bw20v45HTM16muFqi1$5TZjNm3236kfMfJVPg98dcH8R0FsprhXdTEdvG/MxJ7
{noformat}
References:
# yescrypt - scalable KDF and password hashing scheme
[https://www.openwall.com/yescrypt/]
# yescrypt - C source code
[https://github.com/openwall/yescrypt]
# Fedora change log - yescrypt as default hashing for shadow
[https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow]
# Sha2Scrypt Javadoc - Apache Commons Codec
[https://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/digest/Sha2Crypt.html]
# man crypt(5)
[https://manpages.debian.org/bookworm/libcrypt-dev/crypt.5.en.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IO-405) Support threshold=0 in ThresholdingOutputStream
[ https://issues.apache.org/jira/browse/IO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800172#comment-17800172 ] Elliotte Rusty Harold commented on IO-405: -- I don't see any reason for the constructor to throw an exception. Looking at the code I do notice that it doesn't really document or test what happens when the threshold is less than one, though I think the first byte written probably does throw an exception. I'll need to add a test for that. > Support threshold=0 in ThresholdingOutputStream > --- > > Key: IO-405 > URL: https://issues.apache.org/jira/browse/IO-405 > Project: Commons IO > Issue Type: Improvement > Components: Streams/Writers >Affects Versions: 2.5 >Reporter: Jochen Wiedmann >Assignee: Jochen Wiedmann >Priority: Minor > > I recently had a case where I would wish threshold=0 to trigger an immediate > thresholdReached() in ThresholdingOutputStream(). This seems to me to be a > natural expectation. However, thresholdReached() is only triggered after the > first byte has been written. > I'd like to modify the constructor of ThresholdingOutputStream() in that > sense. However, as thresholdReached() might throw an IOException, there are > two possibilities I'd like to discuss: > 1.) Pass the IOException through. Or, in other words: Modify the constructor > to throw an IOException. (Slight binary incompatibility.) > 2.) Catch the IOException, pass on a RuntimeException. Source code > compatibility, but surprising for the developer. > Personally, I'm in favour for 1.) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-412) AllOrNothingOutputStream
[
https://issues.apache.org/jira/browse/IO-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800170#comment-17800170
]
Elliotte Rusty Harold commented on IO-412:
--
I don't think IO-316 is the same. IO-316 is about maintaining backup copies of
file, like VMS used to do, not about all or nothing writes. This proposal does
not maintain any backup copies.
The idea here does strike me as useful. I don't know how to reliably implement
it across platforms, but maybe somebody can figure it out by starting with
other FileUtils methods to move files.
> AllOrNothingOutputStream
>
>
> Key: IO-412
> URL: https://issues.apache.org/jira/browse/IO-412
> Project: Commons IO
> Issue Type: New Feature
> Components: Streams/Writers
>Reporter: David Mollitor
>Priority: Minor
> Attachments: AllOrNothingFileOutputStream.java,
> PartingFileOutputStream.java, PartingFileOutputStreamTest.java
>
>
> Feel free to include this new FileOutputstream. No unit tests yet. Looking
> for feedback at this point.
> {code}
> /**
> * This is a wrapper around a FileOutputStream. It enables a stream to be
> * written to a hidden file in a directory and only then renamed to the final
> * destination if no exceptions occur. This implementation marks the file as
> * hidden by pre-appending the file name with a period. If any exceptions
> occur
> * during writing, the hidden file will be deleted once close() is called.
> This
> * class takes advantage of {@link File#renameTo(File)}; therefore, many
> aspects
> * of the behavior of this class are inherently platform-dependent: The rename
> * operation might not be able to move a file from one filesystem to another,
> it
> * might not be atomic, and it might not succeed if a file with the
> destination
> * abstract pathname already exists. This class is most useful when the rename
> * operation is atomic. It is designed for the case when one process is
> writing
> * to a directory and another process is polling the directory for files to
> * read.
> */
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IO-413) deleteQuietly(File) should try to closeOnDelete too
[
https://issues.apache.org/jira/browse/IO-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved IO-413.
-
Resolution: Won't Do
Agreed
> deleteQuietly(File) should try to closeOnDelete too
> ---
>
> Key: IO-413
> URL: https://issues.apache.org/jira/browse/IO-413
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Reporter: David Mollitor
>Priority: Minor
>
> Something like...
> {code}
> public static boolean deleteQuietly(final File file, final boolean
> deleteOnExit) {
> boolean fileDeleted = false;
> if (file == null) {
> return false;
> }
> try {
> if (file.isDirectory()) {
> cleanDirectory(file);
> }
> } catch (final Exception ignored) {
> }
> try {
> fileDeleted = file.delete();
> } catch (final Exception ignored) {
> return false;
> }
>if (deleteOnExit && !fileDeleted)
>{
>file.deleteOnExit();
>}
> return fileDeleted;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Dev [commons-beanutils]
F0otman commented on PR #194: URL: https://github.com/apache/commons-beanutils/pull/194#issuecomment-1868459915 Apologize for the wrong operate -- 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
Re: [PR] Dev [commons-beanutils]
F0otman closed pull request #194: Dev URL: https://github.com/apache/commons-beanutils/pull/194 -- 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
[PR] Dev [commons-beanutils]
F0otman opened a new pull request, #194: URL: https://github.com/apache/commons-beanutils/pull/194 (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
