[GitHub] [commons-scxml] dependabot[bot] opened a new pull request #41: Bump jaxb-impl from 2.3.6 to 3.0.2
dependabot[bot] opened a new pull request #41: URL: https://github.com/apache/commons-scxml/pull/41 Bumps jaxb-impl from 2.3.6 to 3.0.2. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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-scxml] dependabot[bot] opened a new pull request #40: Bump junit-jupiter-engine from 5.4.2 to 5.8.2
dependabot[bot] opened a new pull request #40: URL: https://github.com/apache/commons-scxml/pull/40 Bumps [junit-jupiter-engine](https://github.com/junit-team/junit5) from 5.4.2 to 5.8.2. Release notes Sourced from https://github.com/junit-team/junit5/releases;>junit-jupiter-engine's releases. JUnit 5.8.2 = Platform 1.8.2 + Jupiter 5.8.2 + Vintage 5.8.2 See http://junit.org/junit5/docs/5.8.2/release-notes/;>Release Notes. JUnit 5.8.1 = Platform 1.8.1 + Jupiter 5.8.1 + Vintage 5.8.1 See http://junit.org/junit5/docs/5.8.1/release-notes/;>Release Notes. JUnit 5.8.0 = Platform 1.8.0 + Jupiter 5.8.0 + Vintage 5.8.0 See http://junit.org/junit5/docs/5.8.0/release-notes/;>Release Notes. JUnit 5.8.0-RC1 = Platform 1.8.0-RC1 + Jupiter 5.8.0-RC1 + Vintage 5.8.0-RC1 See http://junit.org/junit5/docs/5.8.0-RC1/release-notes/;>Release Notes. JUnit 5.8.0-M1 = Platform 1.8.0-M1 + Jupiter 5.8.0-M1 + Vintage 5.8.0-M1 See http://junit.org/junit5/docs/5.8.0-M1/release-notes/;>Release Notes. JUnit 5.7.2 = Platform 1.7.2 + Jupiter 5.7.2 + Vintage 5.7.2 See http://junit.org/junit5/docs/5.7.2/release-notes/;>Release Notes. JUnit 5.7.1 = Platform 1.7.1 + Jupiter 5.7.1 + Vintage 5.7.1 See http://junit.org/junit5/docs/5.7.1/release-notes/;>Release Notes. JUnit 5.7.0 = Platform 1.7.0 + Jupiter 5.7.0 + Vintage 5.7.0 See http://junit.org/junit5/docs/5.7.0/release-notes/;>Release Notes. JUnit 5.7.0-RC1 = Platform 1.7.0-RC1 + Jupiter 5.7.0-RC1 + Vintage 5.7.0-RC1 See http://junit.org/junit5/docs/5.7.0-RC1/release-notes/;>Release Notes. JUnit 5.7.0-M1 = Platform 1.7.0-M1 + Jupiter 5.7.0-M1 + Vintage 5.7.0-M1 See http://junit.org/junit5/docs/5.7.0-M1/release-notes/;>Release Notes. JUnit 5.6.3 = Platform 1.6.3 + Jupiter 5.6.3 + Vintage 5.6.3 See http://junit.org/junit5/docs/5.6.3/release-notes/;>Release Notes. JUnit 5.6.2 = Platform 1.6.2 + Jupiter 5.6.2 + Vintage 5.6.2 See http://junit.org/junit5/docs/5.6.2/release-notes/;>Release Notes. JUnit 5.6.1 = Platform 1.6.1 + Jupiter 5.6.1 + Vintage 5.6.1 ... (truncated) Commits https://github.com/junit-team/junit5/commit/f58cd419755846f1476e8d15783438de8d7aede4;>f58cd41 Release 5.8.2 https://github.com/junit-team/junit5/commit/893617c8bcfd50a9c22023177c80db9973e36d8f;>893617c Fix Javadoc of DEFAULT_DISCOVERY_LISTENER_CONFIGURATION_PROPERTY_NAME https://github.com/junit-team/junit5/commit/3d75f99bf78fa386c17a52009670d6bcfa3f3168;>3d75f99 Use Gradle because to document junit-platform-launcher dependency https://github.com/junit-team/junit5/commit/4ef6e70989fb9ad9efef7bb45996854d876503b1;>4ef6e70 Support CSV headers in display names in parameterized tests https://github.com/junit-team/junit5/commit/69aed70d38b2b2ca3bb51b7a4f29c909573c0544;>69aed70 Polish Overview section of User Guide https://github.com/junit-team/junit5/commit/4181b9c05d5ac8ea056e3c06d35503f99403157a;>4181b9c Make quote character in https://github.com/CsvFileSource;>@CsvFileSource configurable https://github.com/junit-team/junit5/commit/e27058ec5c283bce2f495d0d0b4d328abc16d6e1;>e27058e Stop publishing to scans.gradle.com for PR builds https://github.com/junit-team/junit5/commit/d455b9894ae508d5aa859b7b8ae42debaadb8137;>d455b98 Always update snapshots https://github.com/junit-team/junit5/commit/938ab00d4db1f5ef074856907536bdec5ec414a1;>938ab00 Increase tool timeout to reduce flakiness https://github.com/junit-team/junit5/commit/cd257bd863cc63d32adbefe0c596b881eeabe099;>cd257bd Use longer timeouts to stabilize flaky tests Additional commits viewable in https://github.com/junit-team/junit5/compare/r5.4.2...r5.8.2;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot
[GitHub] [commons-scxml] dependabot[bot] opened a new pull request #39: Bump jackson-core from 2.9.3 to 2.13.2
dependabot[bot] opened a new pull request #39: URL: https://github.com/apache/commons-scxml/pull/39 Bumps [jackson-core](https://github.com/FasterXML/jackson-core) from 2.9.3 to 2.13.2. Commits https://github.com/FasterXML/jackson-core/commit/c5b123b88961eaef9326eb084fbb10aca65b52ad;>c5b123b [maven-release-plugin] prepare release jackson-core-2.13.2 https://github.com/FasterXML/jackson-core/commit/21117bae1af265bffac713364a36140606b62124;>21117ba Prepare for 2.13.2 releae https://github.com/FasterXML/jackson-core/commit/2b65ea1e9401d948ba929724a2711c9ea89a87f5;>2b65ea1 Add bit more testing for names with null bytes (inspired by [dataformats-bina... https://github.com/FasterXML/jackson-core/commit/f3f1f781ba9c9157dddb453ae469d053b1eef46b;>f3f1f78 minor comment improvements https://github.com/FasterXML/jackson-core/commit/d4d97a6ab8c69ca6fd779eac63fa1da5a68afa6d;>d4d97a6 Test is now passing (https://github-redirect.dependabot.com/FasterXML/jackson-core/issues/740;>#740) https://github.com/FasterXML/jackson-core/commit/456b20fa70737eba334ce3a7cc372466d49920ea;>456b20f Bit more checking wrt JsonLocation (and https://github-redirect.dependabot.com/FasterXML/jackson-core/issues/739;>#739) https://github.com/FasterXML/jackson-core/commit/c5aa1e18c71507fbd080567cde14332d684e8e5a;>c5aa1e1 Fix https://github-redirect.dependabot.com/FasterXML/jackson-core/issues/739;>#739 https://github.com/FasterXML/jackson-core/commit/143eecedfb37bacfb33c1fb58f24bfdee67edf78;>143eece ... https://github.com/FasterXML/jackson-core/commit/3740a938231cb6871de0f83c627a002c12e4b260;>3740a93 Add test for https://github-redirect.dependabot.com/FasterXML/jackson-core/issues/736;>#736 https://github.com/FasterXML/jackson-core/commit/18b46344384fd87a287da6b4a921a4b6a65de3f9;>18b4634 Update release notes Additional commits viewable in https://github.com/FasterXML/jackson-core/compare/jackson-core-2.9.3...jackson-core-2.13.2;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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] (NUMBERS-186) GSoC 2022
[ https://issues.apache.org/jira/browse/NUMBERS-186 ]
Raving deleted comment on NUMBERS-186:
was (Author: JIRAUSER286480):
Class : Node
# prev : Node // A pointer to the previous data
# next : Node // A pointer to the next data
# real : Integer
# imaginary : Integer
> GSoC 2022
> -
>
> Key: NUMBERS-186
> URL: https://issues.apache.org/jira/browse/NUMBERS-186
> Project: Commons Numbers
> Issue Type: Wish
> Components: complex
>Reporter: Alex Herbert
>Priority: Minor
> Labels: gsoc, gsoc2022
>
> Placeholder for tasks that could be undertaken in this year's
> [GSoC|https://summerofcode.withgoogle.com/].
> Ideas:
> - Update the support for complex numbers in the {{complex}} package to allow
> operations to be performed on lists of complex numbers. This requires
> abstracting the representation of multiple complex numbers into a list
> structure storing real and imaginary parts that can be efficiently iterated
> to apply all the operations supported by the {{Complex}} class. Operations
> should modify the numbers in place allowing efficient, zero allocation
> complex number math to be performed on large datasets.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] (NUMBERS-186) GSoC 2022
[ https://issues.apache.org/jira/browse/NUMBERS-186 ]
Raving deleted comment on NUMBERS-186:
was (Author: JIRAUSER286480):
Class : ComplexList
Node head;
Node tail;
int size;
int capacity;
Node[] nums;
> GSoC 2022
> -
>
> Key: NUMBERS-186
> URL: https://issues.apache.org/jira/browse/NUMBERS-186
> Project: Commons Numbers
> Issue Type: Wish
> Components: complex
>Reporter: Alex Herbert
>Priority: Minor
> Labels: gsoc, gsoc2022
>
> Placeholder for tasks that could be undertaken in this year's
> [GSoC|https://summerofcode.withgoogle.com/].
> Ideas:
> - Update the support for complex numbers in the {{complex}} package to allow
> operations to be performed on lists of complex numbers. This requires
> abstracting the representation of multiple complex numbers into a list
> structure storing real and imaginary parts that can be efficiently iterated
> to apply all the operations supported by the {{Complex}} class. Operations
> should modify the numbers in place allowing efficient, zero allocation
> complex number math to be performed on large datasets.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (NUMBERS-186) GSoC 2022
[
https://issues.apache.org/jira/browse/NUMBERS-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505932#comment-17505932
]
Sumanth Sulur Rajkumar commented on NUMBERS-186:
Hi, I had sent an email to the dev mail explaining my idea for the issue
yesterday. I was just wondering when I can expect a reply for that
> GSoC 2022
> -
>
> Key: NUMBERS-186
> URL: https://issues.apache.org/jira/browse/NUMBERS-186
> Project: Commons Numbers
> Issue Type: Wish
> Components: complex
>Reporter: Alex Herbert
>Priority: Minor
> Labels: gsoc, gsoc2022
>
> Placeholder for tasks that could be undertaken in this year's
> [GSoC|https://summerofcode.withgoogle.com/].
> Ideas:
> - Update the support for complex numbers in the {{complex}} package to allow
> operations to be performed on lists of complex numbers. This requires
> abstracting the representation of multiple complex numbers into a list
> structure storing real and imaginary parts that can be efficiently iterated
> to apply all the operations supported by the {{Complex}} class. Operations
> should modify the numbers in place allowing efficient, zero allocation
> complex number math to be performed on large datasets.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (COMPRESS-613) Write ZIP extra time fields automatically
[
https://issues.apache.org/jira/browse/COMPRESS-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505926#comment-17505926
]
Andre Brait commented on COMPRESS-613:
--
[~ggregory]
I'd say it's unlikely. Extra fields are part of the specification.
What I can think of is this change ending up revealing bugs on how they handle
extra fields in general, or how they parse dates from those extra fields (which
means they do exoect those to exist and to be able to use them).
I can always add a flag or something, but I wouldn't expect it to affect them
unless it somehow affects them when opening zips packaged by other tools as
well (including WinZip, java.util.zip classes, etc.).
> Write ZIP extra time fields automatically
> -
>
> Key: COMPRESS-613
> URL: https://issues.apache.org/jira/browse/COMPRESS-613
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Andre Brait
>Priority: Major
> Labels: zip
>
> When writing to a Zip file through ZipArchiveOutputStream, setting creation
> and access times in a ZipArchiveEntry does not cause these to be reflected as
> X5455 or X000A extra fields in the resulting zip file. This also happens for
> modification times that do not fit into an MS-DOS time.
> As a consequence, the date range is reduced, as well as the granularity (form
> 100ns intervals to seconds).
> ZipEntry and standard java.util.zip facilities do that automatically, but
> that's missing here.
> My proposal is to use the same logic the java.util.zip do and add those extra
> fields automatically, if situation requires them.
> See my existing logic for this here:
> [https://github.com/andrebrait/DATROMTool/blob/86a4f4978bab250ca54d047c58b4f91e7dbbcc7f/core/src/main/java/io/github/datromtool/io/FileCopier.java#L1425]
> It's (almost) the same logic from java.util.zip, but adapted to be used with
> ZipArchiveEntry.
> If you're ok with it, I can send a PR.
> Actual logic will be more like
> {{{}java.util.zip.ZipOutputStream#writeLOC(XEntry){}}}, represented below:
> {code:java}
> int elenEXTT = 0; // info-zip extended timestamp
> int flagEXTT = 0;
> long umtime = -1;
> long uatime = -1;
> long uctime = -1;
> if (e.mtime != null) {
> elenEXTT += 4;
> flagEXTT |= EXTT_FLAG_LMT;
> umtime = fileTimeToUnixTime(e.mtime);
> }
> if (e.atime != null) {
> elenEXTT += 4;
> flagEXTT |= EXTT_FLAG_LAT;
> uatime = fileTimeToUnixTime(e.atime);
> }
> if (e.ctime != null) {
> elenEXTT += 4;
> flagEXTT |= EXTT_FLAT_CT;
> uctime = fileTimeToUnixTime(e.ctime);
> }
> if (flagEXTT != 0) {
> // to use ntfs time if any m/a/ctime is beyond unixtime upper
> bound
> if (umtime > UPPER_UNIXTIME_BOUND ||
> uatime > UPPER_UNIXTIME_BOUND ||
> uctime > UPPER_UNIXTIME_BOUND) {
> elen += 36;// NTFS time, total 36 bytes
> } else {
> elen += (elenEXTT + 5);// headid(2) + size(2) + flag(1) +
> data
> }
> }
> writeShort(elen);
> writeBytes(nameBytes, 0, nameBytes.length);
> if (hasZip64) {
> writeShort(ZIP64_EXTID);
> writeShort(16);
> writeLong(e.size);
> writeLong(e.csize);
> }
> if (flagEXTT != 0) {
> if (umtime > UPPER_UNIXTIME_BOUND ||
> uatime > UPPER_UNIXTIME_BOUND ||
> uctime > UPPER_UNIXTIME_BOUND) {
> writeShort(EXTID_NTFS);// id
> writeShort(32);// data size
> writeInt(0); // reserved
> writeShort(0x0001);// NTFS attr tag
> writeShort(24);
> writeLong(e.mtime == null ? WINDOWS_TIME_NOT_AVAILABLE
> : fileTimeToWinTime(e.mtime));
> writeLong(e.atime == null ? WINDOWS_TIME_NOT_AVAILABLE
> : fileTimeToWinTime(e.atime));
> writeLong(e.ctime == null ? WINDOWS_TIME_NOT_AVAILABLE
> : fileTimeToWinTime(e.ctime));
> } else {
> writeShort(EXTID_EXTT);
> writeShort(elenEXTT + 1); // flag + data
> writeByte(flagEXTT);
> if (e.mtime != null)
> writeInt(umtime);
> if (e.atime != null)
> writeInt(uatime);
> if (e.ctime != null)
>
[jira] [Work logged] (CLI-313) StringIndexOutOfBoundsException thrown by CommandLineParser.parse() on invalid input
[
https://issues.apache.org/jira/browse/CLI-313?focusedWorklogId=740588=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-740588
]
ASF GitHub Bot logged work on CLI-313:
--
Author: ASF GitHub Bot
Created on: 13/Mar/22 22:25
Start Date: 13/Mar/22 22:25
Worklog Time Spent: 10m
Work Description: garydgregory commented on a change in pull request #95:
URL: https://github.com/apache/commons-cli/pull/95#discussion_r825512651
##
File path: src/main/java/org/apache/commons/cli/DefaultParser.java
##
@@ -580,7 +580,7 @@ private boolean isArgument(final String token) {
* Tests if the specified token is a Java-like property (-Dkey=value).
*/
private boolean isJavaProperty(final String token) {
-final String opt = token.substring(0, 1);
+final String opt = token.length() > 0? token.substring(0, 1): null;
Review comment:
Ping?
--
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
Issue Time Tracking
---
Worklog Id: (was: 740588)
Time Spent: 0.5h (was: 20m)
> StringIndexOutOfBoundsException thrown by CommandLineParser.parse() on
> invalid input
>
>
> Key: CLI-313
> URL: https://issues.apache.org/jira/browse/CLI-313
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.5
>Reporter: Dominik Stadler
>Priority: Critical
> Labels: exception, fuzzer
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I discovered a case which can trigger a StringIndexOutOfBoundsException in
> {{{}CommandLineParser.parse(){}}}.
> The following code-snippet reproduces it:
> {noformat}
> CommandLineParser parser = new DefaultParser();
> Options options = new Options();
> parser.parse(options, new String[] {"-=-"}); {noformat}
>
> When run against current commons-cli 1.5.0 as well as on latest git, it
> causes the following stacktrace:
> {noformat}
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: begin
> 0, end 1, length 0
> at java.base/java.lang.String.checkBoundsBeginEnd(String.java:3319)
> at java.base/java.lang.String.substring(String.java:1874)
> at
> org.apache.commons.cli.DefaultParser.isJavaProperty(DefaultParser.java:583)
> at
> org.apache.commons.cli.DefaultParser.handleShortAndLongOption(DefaultParser.java:511)
> at
> org.apache.commons.cli.DefaultParser.handleToken(DefaultParser.java:542)
> at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:712)
> at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:679)
> at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:660)
> at
> org.dstadler.cli.fuzz.Crash_4543e54e8e6239dec6cc2eea74b83d5de693ec71.main(Crash_4543e54e8e6239dec6cc2eea74b83d5de693ec71.java:13)
> {noformat}
>
> According to the JavaDoc, all failures to parse the arguments should lead to
> a {{{}ParseException{}}}, but it seems this case is not handled currently.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-cli] garydgregory commented on a change in pull request #95: CLI-313: adding new test to properly handling negative case of invali…
garydgregory commented on a change in pull request #95:
URL: https://github.com/apache/commons-cli/pull/95#discussion_r825512651
##
File path: src/main/java/org/apache/commons/cli/DefaultParser.java
##
@@ -580,7 +580,7 @@ private boolean isArgument(final String token) {
* Tests if the specified token is a Java-like property (-Dkey=value).
*/
private boolean isJavaProperty(final String token) {
-final String opt = token.substring(0, 1);
+final String opt = token.length() > 0? token.substring(0, 1): null;
Review comment:
Ping?
--
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] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[ https://issues.apache.org/jira/browse/COMPRESS-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505919#comment-17505919 ] Gary D. Gregory commented on COMPRESS-612: -- Sounds good. We definitely want to keep API compatibility. > Support atime/ctime and higher time precision for TAR > - > > Key: COMPRESS-612 > URL: https://issues.apache.org/jira/browse/COMPRESS-612 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.21 >Reporter: Andre Brait >Priority: Major > Labels: tar > > This is a proposal for some code I have already worked on. > h3. Context > I'm coding a tool that requires extracting/compressing files. I noticed the > following shortcomings: > - -File size is limited to 8GB. This limitation was lifted as of > POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger > files are fully supported by some TAR archiving tools such as GNU TAR. > Reference: > [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]- > -- I think I was actually wrong here in that current implementation should > support files >8GB if using BIGNUMBER_POSIX. > - Only modification date is available as a time type. > - Maximum granularity is seconds, even though the PAX header contains 100ns > intervals > - Other time-related PAX headers are considered extra headers (ctime and > atime) > My proposal is as follows: > - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime > - Keep backwards compatibility through getter/setter methods and add new > ones for FileTime > - Parse times in with a maximal granularity of 100ns intervals from PAX > headers > - Read/write ctime and atime and add corresponding fields > - Write times to PAX headers using a maximum granularity of 100ns intervals > when in BIGNUMBER_POSIX mode. > - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowing for > the bigger size, mtime, ctime and atime to be written- > - -Lift the 8GB limit when using BIGNUMBER_POSIX_2001- > I already have some code for that in > https://github.com/andrebrait/commons-compress/tree/COMPRESS-612 > Since compatibility with Android now requires API level 26 and that includes > FileTime, I think we can do that here as well. > This will bring tar in line with Zip in this regard. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (COMPRESS-613) Write ZIP extra time fields automatically
[
https://issues.apache.org/jira/browse/COMPRESS-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505918#comment-17505918
]
Gary D. Gregory commented on COMPRESS-613:
--
This sounds reasonable. Is there any chance that this could create
compatibility issues for apps that read our zip files after this change is made?
> Write ZIP extra time fields automatically
> -
>
> Key: COMPRESS-613
> URL: https://issues.apache.org/jira/browse/COMPRESS-613
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Andre Brait
>Priority: Major
> Labels: zip
>
> When writing to a Zip file through ZipArchiveOutputStream, setting creation
> and access times in a ZipArchiveEntry does not cause these to be reflected as
> X5455 or X000A extra fields in the resulting zip file. This also happens for
> modification times that do not fit into an MS-DOS time.
> As a consequence, the date range is reduced, as well as the granularity (form
> 100ns intervals to seconds).
> ZipEntry and standard java.util.zip facilities do that automatically, but
> that's missing here.
> My proposal is to use the same logic the java.util.zip do and add those extra
> fields automatically, if situation requires them.
> See my existing logic for this here:
> [https://github.com/andrebrait/DATROMTool/blob/86a4f4978bab250ca54d047c58b4f91e7dbbcc7f/core/src/main/java/io/github/datromtool/io/FileCopier.java#L1425]
> It's (almost) the same logic from java.util.zip, but adapted to be used with
> ZipArchiveEntry.
> If you're ok with it, I can send a PR.
> Actual logic will be more like
> {{{}java.util.zip.ZipOutputStream#writeLOC(XEntry){}}}, represented below:
> {code:java}
> int elenEXTT = 0; // info-zip extended timestamp
> int flagEXTT = 0;
> long umtime = -1;
> long uatime = -1;
> long uctime = -1;
> if (e.mtime != null) {
> elenEXTT += 4;
> flagEXTT |= EXTT_FLAG_LMT;
> umtime = fileTimeToUnixTime(e.mtime);
> }
> if (e.atime != null) {
> elenEXTT += 4;
> flagEXTT |= EXTT_FLAG_LAT;
> uatime = fileTimeToUnixTime(e.atime);
> }
> if (e.ctime != null) {
> elenEXTT += 4;
> flagEXTT |= EXTT_FLAT_CT;
> uctime = fileTimeToUnixTime(e.ctime);
> }
> if (flagEXTT != 0) {
> // to use ntfs time if any m/a/ctime is beyond unixtime upper
> bound
> if (umtime > UPPER_UNIXTIME_BOUND ||
> uatime > UPPER_UNIXTIME_BOUND ||
> uctime > UPPER_UNIXTIME_BOUND) {
> elen += 36;// NTFS time, total 36 bytes
> } else {
> elen += (elenEXTT + 5);// headid(2) + size(2) + flag(1) +
> data
> }
> }
> writeShort(elen);
> writeBytes(nameBytes, 0, nameBytes.length);
> if (hasZip64) {
> writeShort(ZIP64_EXTID);
> writeShort(16);
> writeLong(e.size);
> writeLong(e.csize);
> }
> if (flagEXTT != 0) {
> if (umtime > UPPER_UNIXTIME_BOUND ||
> uatime > UPPER_UNIXTIME_BOUND ||
> uctime > UPPER_UNIXTIME_BOUND) {
> writeShort(EXTID_NTFS);// id
> writeShort(32);// data size
> writeInt(0); // reserved
> writeShort(0x0001);// NTFS attr tag
> writeShort(24);
> writeLong(e.mtime == null ? WINDOWS_TIME_NOT_AVAILABLE
> : fileTimeToWinTime(e.mtime));
> writeLong(e.atime == null ? WINDOWS_TIME_NOT_AVAILABLE
> : fileTimeToWinTime(e.atime));
> writeLong(e.ctime == null ? WINDOWS_TIME_NOT_AVAILABLE
> : fileTimeToWinTime(e.ctime));
> } else {
> writeShort(EXTID_EXTT);
> writeShort(elenEXTT + 1); // flag + data
> writeByte(flagEXTT);
> if (e.mtime != null)
> writeInt(umtime);
> if (e.atime != null)
> writeInt(uatime);
> if (e.ctime != null)
> writeInt(uctime);
> }
> }
> writeExtra(e.extra);
> locoff = written;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-geometry] darkma773r commented on pull request #194: GEOMETRY-142: PointMap and PointSet
darkma773r commented on pull request #194: URL: https://github.com/apache/commons-geometry/pull/194#issuecomment-1066117860 Thanks for the review, @kinow! Your feedback is invaluable. I'll make the changes you suggested as soon as I get some time. -- 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-geometry] darkma773r commented on a change in pull request #194: GEOMETRY-142: PointMap and PointSet
darkma773r commented on a change in pull request #194:
URL: https://github.com/apache/commons-geometry/pull/194#discussion_r825459403
##
File path:
commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/PointMap2DImpl.java
##
@@ -0,0 +1,151 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.geometry.euclidean;
+
+import java.util.List;
+
+import org.apache.commons.geometry.core.collection.PointMap;
+import org.apache.commons.geometry.core.internal.AbstractBucketPointMap;
+import org.apache.commons.geometry.euclidean.twod.Vector2D;
+import org.apache.commons.numbers.core.Precision;
+
+/** Internal {@link PointMap2D} implementation.
Review comment:
Darn. Those were extensions of `PointMap` specific to those spaces. I
ended up removing them since they didn't really add anything. I thought I
removed all of the references in the docs but I guess not.
--
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-geometry] darkma773r commented on a change in pull request #194: GEOMETRY-142: PointMap and PointSet
darkma773r commented on a change in pull request #194:
URL: https://github.com/apache/commons-geometry/pull/194#discussion_r825459133
##
File path:
commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/PointMap3DImpl.java
##
@@ -0,0 +1,174 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.geometry.euclidean;
+
+import java.util.List;
+
+import org.apache.commons.geometry.core.collection.PointMap;
+import org.apache.commons.geometry.core.internal.AbstractBucketPointMap;
+import org.apache.commons.geometry.euclidean.threed.Vector3D;
+import org.apache.commons.numbers.core.Precision;
+
+/** Internal {@link PointMap3D} implementation.
+ * @param Map value type
+ */
+final class PointMap3DImpl
+extends AbstractBucketPointMap
+implements PointMap {
+
+/** Number of children per node. */
+private static final int NODE_CHILD_COUNT = 8;
+
+/** Max entries per node. This value was determined empirically was chosen
to
+ * provide a balance between having a small number of entries in each node
when
+ * searching and having a large number of samples to provide a good split
point
+ * during insertion.
+ */
+private static final int MAX_ENTRIES_PER_NODE = 32;
+
+/** X negative octant flag. */
+private static final int XNEG = 1 << 5;
+
+/** X postive octant flag. */
+private static final int XPOS = 1 << 4;
+
+/** Y negative octant flag. */
+private static final int YNEG = 1 << 3;
+
+/** Y positive octant flag. */
+private static final int YPOS = 1 << 2;
+
+/** Z negative octant flag. */
+private static final int ZNEG = 1 << 1;
+
+/** Z positive octant flag. */
+private static final int ZPOS = 1;
+
+/** Octant location flags for child nodes. */
+private static final int[] CHILD_LOCATIONS = {
+XNEG | YNEG | ZNEG,
+XNEG | YNEG | ZPOS,
+XNEG | YPOS | ZNEG,
+XNEG | YPOS | ZPOS,
+
+XPOS | YNEG | ZNEG,
+XPOS | YNEG | ZPOS,
+XPOS | YPOS | ZNEG,
+XPOS | YPOS | ZPOS
+};
+
+/** Construct a new instance using the given precision context to determine
+ * floating point equality.
+ * @param precision precision context
+ */
+PointMap3DImpl(final Precision.DoubleEquivalence precision) {
+super(MapNode3D::new,
Review comment:
Lol! It's one of my favorite tricks at the moment :-)
--
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-geometry] darkma773r commented on a change in pull request #194: GEOMETRY-142: PointMap and PointSet
darkma773r commented on a change in pull request #194:
URL: https://github.com/apache/commons-geometry/pull/194#discussion_r825458882
##
File path:
commons-geometry-core/src/main/java/org/apache/commons/geometry/core/internal/PointMapAsSetAdapter.java
##
@@ -0,0 +1,89 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.geometry.core.internal;
+
+import java.util.AbstractSet;
+import java.util.Iterator;
+
+import org.apache.commons.geometry.core.Point;
+import org.apache.commons.geometry.core.collection.PointMap;
+import org.apache.commons.geometry.core.collection.PointSet;
+
+/** Class that exposes a {@link PointMap} as a {@link PointSet}.
+ * @param Point type
+ * @param Map type
+ */
+public class PointMapAsSetAdapter, M extends PointMap>
+extends AbstractSet
+implements PointSet {
+
+/** Dummy map value used to indicate presence in the set. */
+private static final Object PRESENT = new Object();
+
+/** Backing map. */
+private final M map;
+
+/** Construct a new instance that use the argument as its backing map.
+ * @param backingMap backing map
+ */
+public PointMapAsSetAdapter(final M backingMap) {
+this.map = backingMap;
+}
+
+/** {@inheritDoc} */
+@Override
+public P resolve(final P pt) {
+return map.resolveKey(pt);
+}
+
+/** {@inheritDoc} */
+@Override
+public Iterator iterator() {
+return map.keySet().iterator();
+}
+
+/** {@inheritDoc} */
+@Override
+public int size() {
+return map.size();
+}
+
+/** {@inheritDoc} */
+@Override
+public boolean contains(final Object obj) {
+return map.containsKey(obj);
+}
+
+/** {@inheritDoc} */
+@Override
+public boolean add(final P pt) {
+return map.put(pt, PRESENT) == null;
+}
+
+/** {@inheritDoc} */
+@Override
+public boolean remove(final Object obj) {
+final Object prev = map.remove(obj);
+return GeometryInternalUtils.sameInstance(prev, PRESENT);
Review comment:
This would indeed cause an issue if a user followed your steps above.
I'm not picturing `PointMapAsSetAdapter` being used directly by users, hence
it's presence in the `internal` package in core. I should probably make that
explicit in the javadocs, though.
--
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] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen updated GEOMETRY-146:
---
Fix Version/s: 1.1
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEOMETRY-146) PointSet/Map closest points
Matt Juntunen created GEOMETRY-146:
--
Summary: PointSet/Map closest points
Key: GEOMETRY-146
URL: https://issues.apache.org/jira/browse/GEOMETRY-146
Project: Commons Geometry
Issue Type: New Feature
Reporter: Matt Juntunen
Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
querying of points in order of distance from a query point.
{code:java}
PointSet {
// find the closest point to pt or null if empty
P closest(P pt);
// iterate through points in order, with points closest to pt coming first
Iterable closestFirst(P pt);
// find the farthest point from pt or null if emtpy
P farthest(P pt);
// iterate through point in order, with points farthest from pt coming first
Iterable farthestFirst(P pt);
}
{code}
{{PointMap}} should have similar methods providing access to the map keys and
entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (NUMBERS-186) GSoC 2022
[
https://issues.apache.org/jira/browse/NUMBERS-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505837#comment-17505837
]
Gilles Sadowski commented on NUMBERS-186:
-
bq. Can I design [...]
Please subscribe to the ["dev"
ML|https://commons.apache.org/proper/commons-numbers/mailing-lists.html];
design discussions should always be initiated _there_, for the record. Then,
when some agreement on *what* to do has been reached, specific tasks are
reported _here_, on JIRA, where we can possibly discuss the details of *how* to
implement the feature.
bq. [...] this way?
Quite certainly, no; at least, because
* the real and imaginary parts of a complex number are real numbers (thus, to
be represented as {{double}}),
* a linked list would be extremely wasteful of RAM.
> GSoC 2022
> -
>
> Key: NUMBERS-186
> URL: https://issues.apache.org/jira/browse/NUMBERS-186
> Project: Commons Numbers
> Issue Type: Wish
> Components: complex
>Reporter: Alex Herbert
>Priority: Minor
> Labels: gsoc, gsoc2022
>
> Placeholder for tasks that could be undertaken in this year's
> [GSoC|https://summerofcode.withgoogle.com/].
> Ideas:
> - Update the support for complex numbers in the {{complex}} package to allow
> operations to be performed on lists of complex numbers. This requires
> abstracting the representation of multiple complex numbers into a list
> structure storing real and imaginary parts that can be efficiently iterated
> to apply all the operations supported by the {{Complex}} class. Operations
> should modify the numbers in place allowing efficient, zero allocation
> complex number math to be performed on large datasets.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (NUMBERS-186) GSoC 2022
[
https://issues.apache.org/jira/browse/NUMBERS-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505419#comment-17505419
]
Raving edited comment on NUMBERS-186 at 3/13/22, 10:33 AM:
---
Class : ComplexList
Node head;
Node tail;
int size;
int capacity;
Node[] nums;
was (Author: JIRAUSER286480):
Class : ComplexList
Node head;
Node tail;
int size;
int capacity;
List nums;
> GSoC 2022
> -
>
> Key: NUMBERS-186
> URL: https://issues.apache.org/jira/browse/NUMBERS-186
> Project: Commons Numbers
> Issue Type: Wish
> Components: complex
>Reporter: Alex Herbert
>Priority: Minor
> Labels: gsoc, gsoc2022
>
> Placeholder for tasks that could be undertaken in this year's
> [GSoC|https://summerofcode.withgoogle.com/].
> Ideas:
> - Update the support for complex numbers in the {{complex}} package to allow
> operations to be performed on lists of complex numbers. This requires
> abstracting the representation of multiple complex numbers into a list
> structure storing real and imaginary parts that can be efficiently iterated
> to apply all the operations supported by the {{Complex}} class. Operations
> should modify the numbers in place allowing efficient, zero allocation
> complex number math to be performed on large datasets.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (NUMBERS-186) GSoC 2022
[
https://issues.apache.org/jira/browse/NUMBERS-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505420#comment-17505420
]
Raving commented on NUMBERS-186:
Can I design the data architecture this way?
> GSoC 2022
> -
>
> Key: NUMBERS-186
> URL: https://issues.apache.org/jira/browse/NUMBERS-186
> Project: Commons Numbers
> Issue Type: Wish
> Components: complex
>Reporter: Alex Herbert
>Priority: Minor
> Labels: gsoc, gsoc2022
>
> Placeholder for tasks that could be undertaken in this year's
> [GSoC|https://summerofcode.withgoogle.com/].
> Ideas:
> - Update the support for complex numbers in the {{complex}} package to allow
> operations to be performed on lists of complex numbers. This requires
> abstracting the representation of multiple complex numbers into a list
> structure storing real and imaginary parts that can be efficiently iterated
> to apply all the operations supported by the {{Complex}} class. Operations
> should modify the numbers in place allowing efficient, zero allocation
> complex number math to be performed on large datasets.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (NUMBERS-186) GSoC 2022
[
https://issues.apache.org/jira/browse/NUMBERS-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505419#comment-17505419
]
Raving commented on NUMBERS-186:
Class : ComplexList
Node head;
Node tail;
int size;
int capacity;
List nums;
> GSoC 2022
> -
>
> Key: NUMBERS-186
> URL: https://issues.apache.org/jira/browse/NUMBERS-186
> Project: Commons Numbers
> Issue Type: Wish
> Components: complex
>Reporter: Alex Herbert
>Priority: Minor
> Labels: gsoc, gsoc2022
>
> Placeholder for tasks that could be undertaken in this year's
> [GSoC|https://summerofcode.withgoogle.com/].
> Ideas:
> - Update the support for complex numbers in the {{complex}} package to allow
> operations to be performed on lists of complex numbers. This requires
> abstracting the representation of multiple complex numbers into a list
> structure storing real and imaginary parts that can be efficiently iterated
> to apply all the operations supported by the {{Complex}} class. Operations
> should modify the numbers in place allowing efficient, zero allocation
> complex number math to be performed on large datasets.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (NUMBERS-186) GSoC 2022
[
https://issues.apache.org/jira/browse/NUMBERS-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505417#comment-17505417
]
Raving commented on NUMBERS-186:
Class : Node
# prev : Node // A pointer to the previous data
# next : Node // A pointer to the next data
# real : Integer
# imaginary : Integer
> GSoC 2022
> -
>
> Key: NUMBERS-186
> URL: https://issues.apache.org/jira/browse/NUMBERS-186
> Project: Commons Numbers
> Issue Type: Wish
> Components: complex
>Reporter: Alex Herbert
>Priority: Minor
> Labels: gsoc, gsoc2022
>
> Placeholder for tasks that could be undertaken in this year's
> [GSoC|https://summerofcode.withgoogle.com/].
> Ideas:
> - Update the support for complex numbers in the {{complex}} package to allow
> operations to be performed on lists of complex numbers. This requires
> abstracting the representation of multiple complex numbers into a list
> structure storing real and imaginary parts that can be efficiently iterated
> to apply all the operations supported by the {{Complex}} class. Operations
> should modify the numbers in place allowing efficient, zero allocation
> complex number math to be performed on large datasets.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
