[jira] [Work logged] (DBCP-562) Password should not be exposed via JMXBean
[ https://issues.apache.org/jira/browse/DBCP-562?focusedWorklogId=593834=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593834 ] ASF GitHub Bot logged work on DBCP-562: --- Author: ASF GitHub Bot Created on: 10/May/21 05:43 Start Date: 10/May/21 05:43 Worklog Time Spent: 10m Work Description: ManjunathMS35 commented on pull request #38: URL: https://github.com/apache/commons-dbcp/pull/38#issuecomment-836206072 Hello, when could be the new release with this fix? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 593834) Time Spent: 1.5h (was: 1h 20m) > Password should not be exposed via JMXBean > -- > > Key: DBCP-562 > URL: https://issues.apache.org/jira/browse/DBCP-562 > Project: Commons DBCP > Issue Type: Bug >Affects Versions: 2.5.0, 2.7.0 >Reporter: Frank Gasdorf >Priority: Critical > Labels: security > Time Spent: 1.5h > Remaining Estimate: 0h > > if a BasicDataSource is created with jmxName set, password property is > exposed/exported via jmx and is visible for everybody who is connected to jmx > port. > > Expectation : Do not export it via BasicDataSourceMXBean Interface -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-dbcp] ManjunathMS35 commented on pull request #38: [DBCP-562] avoids exposing password via JMX
ManjunathMS35 commented on pull request #38: URL: https://github.com/apache/commons-dbcp/pull/38#issuecomment-836206072 Hello, when could be the new release with this fix? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (FILEUPLOAD-336) WhitespaceAround
[ https://issues.apache.org/jira/browse/FILEUPLOAD-336?focusedWorklogId=593823=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593823 ] ASF GitHub Bot logged work on FILEUPLOAD-336: - Author: ASF GitHub Bot Created on: 10/May/21 04:29 Start Date: 10/May/21 04:29 Worklog Time Spent: 10m Work Description: coveralls commented on pull request #88: URL: https://github.com/apache/commons-fileupload/pull/88#issuecomment-836153815 [](https://coveralls.io/builds/39509750) Coverage remained the same at 78.341% when pulling **c7080af4736e0b922e762320f3286888ac31814a on arturobernalg:feature/FILEUPLOAD-336** into **5352ef0a1c914473de0820fc962cb81d8c5b6167 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 593823) Time Spent: 20m (was: 10m) > WhitespaceAround > > > Key: FILEUPLOAD-336 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-336 > Project: Commons FileUpload > Issue Type: Sub-task >Reporter: Arturo Bernal >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > * '+' is not preceded with whitespace. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-fileupload] coveralls commented on pull request #88: FILEUPLOAD-336 - WhitespaceAround
coveralls commented on pull request #88: URL: https://github.com/apache/commons-fileupload/pull/88#issuecomment-836153815 [](https://coveralls.io/builds/39509750) Coverage remained the same at 78.341% when pulling **c7080af4736e0b922e762320f3286888ac31814a on arturobernalg:feature/FILEUPLOAD-336** into **5352ef0a1c914473de0820fc962cb81d8c5b6167 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (FILEUPLOAD-336) WhitespaceAround
[ https://issues.apache.org/jira/browse/FILEUPLOAD-336?focusedWorklogId=593822=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593822 ] ASF GitHub Bot logged work on FILEUPLOAD-336: - Author: ASF GitHub Bot Created on: 10/May/21 04:27 Start Date: 10/May/21 04:27 Worklog Time Spent: 10m Work Description: arturobernalg opened a new pull request #88: URL: https://github.com/apache/commons-fileupload/pull/88 '+' is not preceded with whitespace. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 593822) Remaining Estimate: 0h Time Spent: 10m > WhitespaceAround > > > Key: FILEUPLOAD-336 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-336 > Project: Commons FileUpload > Issue Type: Sub-task >Reporter: Arturo Bernal >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > * '+' is not preceded with whitespace. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-fileupload] arturobernalg opened a new pull request #88: FILEUPLOAD-336 - WhitespaceAround
arturobernalg opened a new pull request #88: URL: https://github.com/apache/commons-fileupload/pull/88 '+' is not preceded with whitespace. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (FILEUPLOAD-336) WhitespaceAround
Arturo Bernal created FILEUPLOAD-336: Summary: WhitespaceAround Key: FILEUPLOAD-336 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-336 Project: Commons FileUpload Issue Type: Sub-task Reporter: Arturo Bernal * '+' is not preceded with whitespace. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
[
https://issues.apache.org/jira/browse/COMPRESS-565?focusedWorklogId=593819=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593819
]
ASF GitHub Bot logged work on COMPRESS-565:
---
Author: ASF GitHub Bot
Created on: 10/May/21 04:19
Start Date: 10/May/21 04:19
Worklog Time Spent: 10m
Work Description: bodewig commented on pull request #169:
URL: https://github.com/apache/commons-compress/pull/169#issuecomment-836147157
looks good to 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 593819)
Time Spent: 4h 10m (was: 4h)
> Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
> ---
>
> Key: COMPRESS-565
> URL: https://issues.apache.org/jira/browse/COMPRESS-565
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: Evgenii Bovykin
>Assignee: Peter Lee
>Priority: Major
> Fix For: 1.21
>
> Attachments: commons-compress-1.21-SNAPSHOT.jar,
> image-2021-02-20-15-51-21-747.png
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> We've recently updated commons-compress library from version 1.9 to 1.20 and
> now experiencing the problem that didn't occur before.
>
> When using ZipArchiveOutputStream to archive 5Gb file and setting the
> following fields
> {{output.setUseZip64(Zip64Mode.Always)}}
>
> {{output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)}}
> resulting archive contains corrupted headers.
> *Expand-Archive Powershell utility cannot extract the archive at all with the
> error about corrupted header. 7zip also complains about it, but can extract
> the archive.*
>
> The problem didn't appear when using library version 1.9.
>
> I've created a sample project that reproduces the error -
> [https://github.com/missingdays/commons-compress-example]
> Issue doesn't reproduce if you do any of the following:
>
> # Downgrade library to version 1.9
> # Remove
> output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)
> # Remove output.setUseZip64(Zip64Mode.Always) and zip smaller file (e.g. 1Gb)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] bodewig commented on pull request #169: COMPRESS-565 : add a new AlwaysWithCompatibility in Zip64Mode
bodewig commented on pull request #169: URL: https://github.com/apache/commons-compress/pull/169#issuecomment-836147157 looks good to 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
[
https://issues.apache.org/jira/browse/COMPRESS-565?focusedWorklogId=593817=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593817
]
ASF GitHub Bot logged work on COMPRESS-565:
---
Author: ASF GitHub Bot
Created on: 10/May/21 04:07
Start Date: 10/May/21 04:07
Worklog Time Spent: 10m
Work Description: PeterAlfredLee commented on pull request #169:
URL: https://github.com/apache/commons-compress/pull/169#issuecomment-836140258
The Github Actions is weird - I can successfully compile and test the class
`Zip64SupportIT`, but Actions is reporting compilation failure, which is caused
by the missing of `FileOutputStream` and `FileInputStream`. These 2 classes are
already imported but Actions seems missed them.
Maybe this is a bug of Github Actions?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 593817)
Time Spent: 4h (was: 3h 50m)
> Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
> ---
>
> Key: COMPRESS-565
> URL: https://issues.apache.org/jira/browse/COMPRESS-565
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: Evgenii Bovykin
>Assignee: Peter Lee
>Priority: Major
> Fix For: 1.21
>
> Attachments: commons-compress-1.21-SNAPSHOT.jar,
> image-2021-02-20-15-51-21-747.png
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> We've recently updated commons-compress library from version 1.9 to 1.20 and
> now experiencing the problem that didn't occur before.
>
> When using ZipArchiveOutputStream to archive 5Gb file and setting the
> following fields
> {{output.setUseZip64(Zip64Mode.Always)}}
>
> {{output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)}}
> resulting archive contains corrupted headers.
> *Expand-Archive Powershell utility cannot extract the archive at all with the
> error about corrupted header. 7zip also complains about it, but can extract
> the archive.*
>
> The problem didn't appear when using library version 1.9.
>
> I've created a sample project that reproduces the error -
> [https://github.com/missingdays/commons-compress-example]
> Issue doesn't reproduce if you do any of the following:
>
> # Downgrade library to version 1.9
> # Remove
> output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)
> # Remove output.setUseZip64(Zip64Mode.Always) and zip smaller file (e.g. 1Gb)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] PeterAlfredLee commented on pull request #169: COMPRESS-565 : add a new AlwaysWithCompatibility in Zip64Mode
PeterAlfredLee commented on pull request #169: URL: https://github.com/apache/commons-compress/pull/169#issuecomment-836140258 The Github Actions is weird - I can successfully compile and test the class `Zip64SupportIT`, but Actions is reporting compilation failure, which is caused by the missing of `FileOutputStream` and `FileInputStream`. These 2 classes are already imported but Actions seems missed them. Maybe this is a bug of Github Actions? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (JCS-223) Data not added in cache at certain scenarios
[ https://issues.apache.org/jira/browse/JCS-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sundharam updated JCS-223: -- Affects Version/s: jcs-3.0 > Data not added in cache at certain scenarios > > > Key: JCS-223 > URL: https://issues.apache.org/jira/browse/JCS-223 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-3.0 > Environment: JAVA >Reporter: Sundharam >Priority: Major > Attachments: Code.java, cache.ccf, output > > > Created a simple program to put 1000 data in the the cache and read 1000 data > from the cache. While retrieving the data nearly 200-250 entries were found > missing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
[
https://issues.apache.org/jira/browse/COMPRESS-565?focusedWorklogId=593815=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593815
]
ASF GitHub Bot logged work on COMPRESS-565:
---
Author: ASF GitHub Bot
Created on: 10/May/21 03:53
Start Date: 10/May/21 03:53
Worklog Time Spent: 10m
Work Description: PeterAlfredLee commented on pull request #169:
URL: https://github.com/apache/commons-compress/pull/169#issuecomment-836132501
I pushed a commit that fixes name of tests, and also fixes the
[comment](https://github.com/apache/commons-compress/pull/169#issuecomment-788865243).
WDYT? @bodewig @garydgregory
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 593815)
Time Spent: 3h 50m (was: 3h 40m)
> Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
> ---
>
> Key: COMPRESS-565
> URL: https://issues.apache.org/jira/browse/COMPRESS-565
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: Evgenii Bovykin
>Assignee: Peter Lee
>Priority: Major
> Fix For: 1.21
>
> Attachments: commons-compress-1.21-SNAPSHOT.jar,
> image-2021-02-20-15-51-21-747.png
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> We've recently updated commons-compress library from version 1.9 to 1.20 and
> now experiencing the problem that didn't occur before.
>
> When using ZipArchiveOutputStream to archive 5Gb file and setting the
> following fields
> {{output.setUseZip64(Zip64Mode.Always)}}
>
> {{output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)}}
> resulting archive contains corrupted headers.
> *Expand-Archive Powershell utility cannot extract the archive at all with the
> error about corrupted header. 7zip also complains about it, but can extract
> the archive.*
>
> The problem didn't appear when using library version 1.9.
>
> I've created a sample project that reproduces the error -
> [https://github.com/missingdays/commons-compress-example]
> Issue doesn't reproduce if you do any of the following:
>
> # Downgrade library to version 1.9
> # Remove
> output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)
> # Remove output.setUseZip64(Zip64Mode.Always) and zip smaller file (e.g. 1Gb)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] PeterAlfredLee commented on pull request #169: COMPRESS-565 : add a new AlwaysWithCompatibility in Zip64Mode
PeterAlfredLee commented on pull request #169: URL: https://github.com/apache/commons-compress/pull/169#issuecomment-836132501 I pushed a commit that fixes name of tests, and also fixes the [comment](https://github.com/apache/commons-compress/pull/169#issuecomment-788865243). WDYT? @bodewig @garydgregory -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (JCS-223) Data not added in cache at certain scenarios
Sundharam created JCS-223: - Summary: Data not added in cache at certain scenarios Key: JCS-223 URL: https://issues.apache.org/jira/browse/JCS-223 Project: Commons JCS Issue Type: Bug Environment: JAVA Reporter: Sundharam Attachments: Code.java, cache.ccf, output Created a simple program to put 1000 data in the the cache and read 1000 data from the cache. While retrieving the data nearly 200-250 entries were found missing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MATH-1574) not able to download common-math3.03 getting 404 error
[ https://issues.apache.org/jira/browse/MATH-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17341645#comment-17341645 ] Gilles Sadowski commented on MATH-1574: --- There seems to be a problem withe some parts of the project's web site. However, you can reach the download page with this one: [https://downloads.apache.org/commons/math/] > not able to download common-math3.03 getting 404 error > -- > > Key: MATH-1574 > URL: https://issues.apache.org/jira/browse/MATH-1574 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 >Reporter: Roopali >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MATH-1574) not able to download common-math3.03 getting 404 error
Roopali created MATH-1574: - Summary: not able to download common-math3.03 getting 404 error Key: MATH-1574 URL: https://issues.apache.org/jira/browse/MATH-1574 Project: Commons Math Issue Type: Bug Affects Versions: 3.6.1 Reporter: Roopali -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
[
https://issues.apache.org/jira/browse/COMPRESS-565?focusedWorklogId=593800=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593800
]
ASF GitHub Bot logged work on COMPRESS-565:
---
Author: ASF GitHub Bot
Created on: 10/May/21 01:09
Start Date: 10/May/21 01:09
Worklog Time Spent: 10m
Work Description: PeterAlfredLee commented on pull request #169:
URL: https://github.com/apache/commons-compress/pull/169#issuecomment-836032619
> you may want to change the name of the test method.
Ah, yes. I forgot to change the name of the 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 593800)
Time Spent: 3h 40m (was: 3.5h)
> Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
> ---
>
> Key: COMPRESS-565
> URL: https://issues.apache.org/jira/browse/COMPRESS-565
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: Evgenii Bovykin
>Assignee: Peter Lee
>Priority: Major
> Fix For: 1.21
>
> Attachments: commons-compress-1.21-SNAPSHOT.jar,
> image-2021-02-20-15-51-21-747.png
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> We've recently updated commons-compress library from version 1.9 to 1.20 and
> now experiencing the problem that didn't occur before.
>
> When using ZipArchiveOutputStream to archive 5Gb file and setting the
> following fields
> {{output.setUseZip64(Zip64Mode.Always)}}
>
> {{output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)}}
> resulting archive contains corrupted headers.
> *Expand-Archive Powershell utility cannot extract the archive at all with the
> error about corrupted header. 7zip also complains about it, but can extract
> the archive.*
>
> The problem didn't appear when using library version 1.9.
>
> I've created a sample project that reproduces the error -
> [https://github.com/missingdays/commons-compress-example]
> Issue doesn't reproduce if you do any of the following:
>
> # Downgrade library to version 1.9
> # Remove
> output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)
> # Remove output.setUseZip64(Zip64Mode.Always) and zip smaller file (e.g. 1Gb)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] PeterAlfredLee commented on pull request #169: COMPRESS-565 : add a new AlwaysWithCompatibility in Zip64Mode
PeterAlfredLee commented on pull request #169: URL: https://github.com/apache/commons-compress/pull/169#issuecomment-836032619 > you may want to change the name of the test method. Ah, yes. I forgot to change the name of the 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
[
https://issues.apache.org/jira/browse/COMPRESS-565?focusedWorklogId=593798=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593798
]
ASF GitHub Bot logged work on COMPRESS-565:
---
Author: ASF GitHub Bot
Created on: 10/May/21 01:07
Start Date: 10/May/21 01:07
Worklog Time Spent: 10m
Work Description: PeterAlfredLee commented on pull request #169:
URL: https://github.com/apache/commons-compress/pull/169#issuecomment-836027490
> I had another look and I don't think you've addressed my comment from #169
(comment)
I must have missed that. Sorry about that.
I will fix this today and push a commit in 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 593798)
Time Spent: 3.5h (was: 3h 20m)
> Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
> ---
>
> Key: COMPRESS-565
> URL: https://issues.apache.org/jira/browse/COMPRESS-565
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: Evgenii Bovykin
>Assignee: Peter Lee
>Priority: Major
> Fix For: 1.21
>
> Attachments: commons-compress-1.21-SNAPSHOT.jar,
> image-2021-02-20-15-51-21-747.png
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> We've recently updated commons-compress library from version 1.9 to 1.20 and
> now experiencing the problem that didn't occur before.
>
> When using ZipArchiveOutputStream to archive 5Gb file and setting the
> following fields
> {{output.setUseZip64(Zip64Mode.Always)}}
>
> {{output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)}}
> resulting archive contains corrupted headers.
> *Expand-Archive Powershell utility cannot extract the archive at all with the
> error about corrupted header. 7zip also complains about it, but can extract
> the archive.*
>
> The problem didn't appear when using library version 1.9.
>
> I've created a sample project that reproduces the error -
> [https://github.com/missingdays/commons-compress-example]
> Issue doesn't reproduce if you do any of the following:
>
> # Downgrade library to version 1.9
> # Remove
> output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)
> # Remove output.setUseZip64(Zip64Mode.Always) and zip smaller file (e.g. 1Gb)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] PeterAlfredLee commented on pull request #169: COMPRESS-565 : add a new AlwaysWithCompatibility in Zip64Mode
PeterAlfredLee commented on pull request #169: URL: https://github.com/apache/commons-compress/pull/169#issuecomment-836027490 > I had another look and I don't think you've addressed my comment from #169 (comment) I must have missed that. Sorry about that. I will fix this today and push a commit in 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
[
https://issues.apache.org/jira/browse/COMPRESS-565?focusedWorklogId=593797=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593797
]
ASF GitHub Bot logged work on COMPRESS-565:
---
Author: ASF GitHub Bot
Created on: 10/May/21 01:04
Start Date: 10/May/21 01:04
Worklog Time Spent: 10m
Work Description: PeterAlfredLee commented on pull request #169:
URL: https://github.com/apache/commons-compress/pull/169#issuecomment-836017333
> Surely we can come up with a better name than a "food item" (comestible)
or is that term used in the zip spec itself?
That was a typo and I'm using `Compatibility` now. But I forgot to change
the title of this PR, my 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 593797)
Time Spent: 3h 20m (was: 3h 10m)
> Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
> ---
>
> Key: COMPRESS-565
> URL: https://issues.apache.org/jira/browse/COMPRESS-565
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: Evgenii Bovykin
>Assignee: Peter Lee
>Priority: Major
> Fix For: 1.21
>
> Attachments: commons-compress-1.21-SNAPSHOT.jar,
> image-2021-02-20-15-51-21-747.png
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> We've recently updated commons-compress library from version 1.9 to 1.20 and
> now experiencing the problem that didn't occur before.
>
> When using ZipArchiveOutputStream to archive 5Gb file and setting the
> following fields
> {{output.setUseZip64(Zip64Mode.Always)}}
>
> {{output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)}}
> resulting archive contains corrupted headers.
> *Expand-Archive Powershell utility cannot extract the archive at all with the
> error about corrupted header. 7zip also complains about it, but can extract
> the archive.*
>
> The problem didn't appear when using library version 1.9.
>
> I've created a sample project that reproduces the error -
> [https://github.com/missingdays/commons-compress-example]
> Issue doesn't reproduce if you do any of the following:
>
> # Downgrade library to version 1.9
> # Remove
> output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)
> # Remove output.setUseZip64(Zip64Mode.Always) and zip smaller file (e.g. 1Gb)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] PeterAlfredLee commented on pull request #169: COMPRESS-565 : add a new AlwaysWithComestibles in Zip64Mode
PeterAlfredLee commented on pull request #169: URL: https://github.com/apache/commons-compress/pull/169#issuecomment-836017333 > Surely we can come up with a better name than a "food item" (comestible) or is that term used in the zip spec itself? That was a typo and I'm using `Compatibility` now. But I forgot to change the title of this PR, my 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (VFS-805) HTTP seek always exhausts response
[
https://issues.apache.org/jira/browse/VFS-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Stadler updated VFS-805:
--
Description:
Seeking on an HTTP resource always downloads ALL content if a Content-Length
header is present. The problem is that seeking closes the current input stream
which eventually ends up in ContentLengthInputStream.close() of the (ancient)
http client library.
To be clear, the problem is actually not with the seek itself, but with the
underlying close implementation that always exhausts the HTTP response body.
See the example below.
My use case is to perform binary search on sorted datasets on the Web (RDF data
in sorted ntriple syntax) - the binary search works locally and *in principle*
works on HTTP resources abstracted with VFS2, but the seek implementation that
downloads *ALL* data (in my case several GBs) unfortunately defeats the purpose
:(
>From org.apache.commons.httpclient.ContentLengthInputStream
>(commons-httpclient-3.1):
{code:java}
public void close() throws IOException {
if (!closed) {
try {
ChunkedInputStream.exhaustInputStream(this);
} finally {
// close after above so that we don't throw an exception trying
// to read after closed!
closed = true;
}
}
}
{code}
Example:
{code:java}
public static void main(String[] args) throws Exception {
String url = "http://localhost/large-file-2gb.txt;;
FileSystemManager fsManager = VFS.getManager();
try (FileObject file = fsManager.resolveFile(url)) {
try (RandomAccessContent r =
file.getContent().getRandomAccessContent(RandomAccessMode.READ)) {
StopWatch sw1 = StopWatch.createStarted();
r.seek(20);
System.out.println("Initial seek: " +
sw1.getTime(TimeUnit.MILLISECONDS));
StopWatch sw2 = StopWatch.createStarted();
byte[] bytes = new byte[100];
r.readFully(bytes);
System.out.println("Read: " +
sw2.getTime(TimeUnit.MILLISECONDS));
StopWatch sw3 = StopWatch.createStarted();
r.seek(100);
System.out.println("Subsequent seek: " +
sw3.getTime(TimeUnit.MILLISECONDS));
}
}
System.out.println("Done");
}
{code}
Output (times in milliseconds):
{code}
Initial seek: 0
Read: 4
Subsequent seek: 2538
Done
{code}
was:
Seeking on an HTTP resource always downloads ALL content if a Content-Length
header is present. The problem is that seeking closes the current input stream
which eventually ends up in ContentLengthInputStream.close() of the (ancient)
http client library.
To be clear, the problem is actually not with the seek itself, but with the
underlying close implementation that always exhausts the HTTP response body.
See the example below.
My use case is to perform binary search on sorted datasets on the Web (RDF data
in sorted ntriple syntax) - the binary search works locally and *in principle*
works on HTTP resources abstracted with VFS2, but the seek implementation that
downloads *ALL* data (in my case several GBs) unfortunately defeats the purpose
:(
{code:java}
// org.apache.commons.httpclient.ContentLengthInputStream
(commons-httpclient-3.1)
public void close() throws IOException {
if (!closed) {
try {
ChunkedInputStream.exhaustInputStream(this);
} finally {
// close after above so that we don't throw an exception trying
// to read after closed!
closed = true;
}
}
}{code}
{code:java}
public static void main(String[] args) throws Exception {
String url = "http://localhost/large-file-2gb.txt;;
FileSystemManager fsManager = VFS.getManager();
try (FileObject file = fsManager.resolveFile(url)) {
try (RandomAccessContent r =
file.getContent().getRandomAccessContent(RandomAccessMode.READ)) {
StopWatch sw1 = StopWatch.createStarted();
r.seek(20);
System.out.println("Initial seek: " +
sw1.getTime(TimeUnit.MILLISECONDS));
StopWatch sw2 = StopWatch.createStarted();
byte[] bytes = new byte[100];
r.readFully(bytes);
[jira] [Updated] (VFS-805) HTTP seek always exhausts response
[
https://issues.apache.org/jira/browse/VFS-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Stadler updated VFS-805:
--
Description:
Seeking on an HTTP resource always downloads ALL content if a Content-Length
header is present. The problem is that seeking closes the current input stream
which eventually ends up in ContentLengthInputStream.close() of the (ancient)
http client library.
To be clear, the problem is actually not with the seek itself, but with the
underlying close implementation that always exhausts the HTTP response body.
See the example below.
My use case is to perform binary search on sorted datasets on the Web (RDF data
in sorted ntriple syntax) - the binary search works locally and *in principle*
works on HTTP resources abstracted with VFS2, but the seek implementation that
downloads *ALL* data (in my case several GBs) unfortunately defeats the purpose
:(
{code:java}
// org.apache.commons.httpclient.ContentLengthInputStream
(commons-httpclient-3.1)
public void close() throws IOException {
if (!closed) {
try {
ChunkedInputStream.exhaustInputStream(this);
} finally {
// close after above so that we don't throw an exception trying
// to read after closed!
closed = true;
}
}
}{code}
{code:java}
public static void main(String[] args) throws Exception {
String url = "http://localhost/large-file-2gb.txt;;
FileSystemManager fsManager = VFS.getManager();
try (FileObject file = fsManager.resolveFile(url)) {
try (RandomAccessContent r =
file.getContent().getRandomAccessContent(RandomAccessMode.READ)) {
StopWatch sw1 = StopWatch.createStarted();
r.seek(20);
System.out.println("Initial seek: " +
sw1.getTime(TimeUnit.MILLISECONDS));
StopWatch sw2 = StopWatch.createStarted();
byte[] bytes = new byte[100];
r.readFully(bytes);
System.out.println("Read: " +
sw2.getTime(TimeUnit.MILLISECONDS));
StopWatch sw3 = StopWatch.createStarted();
r.seek(100);
System.out.println("Subsequent seek: " +
sw3.getTime(TimeUnit.MILLISECONDS));
}
}
System.out.println("Done");
}
/*
Output (times in milliseconds):
Initial seek: 0
Read: 4
Subsequent seek: 2538
Done
*/
{code}
was:
Seeking on an HTTP resource always downloads ALL content if a Content-Length
header is present. The problem is that seeking closes the current input stream
which eventually ends up in ContentLengthInputStream.close() of the (ancient)
http client library.
See the example below.
My use case is to perform binary search on sorted datasets on the Web (RDF data
in sorted ntriple syntax) - the binary search works locally and *in principle*
works on HTTP resources abstracted with VFS2, but the seek implementation that
downloads *ALL* data (in my case several GBs) unfortunately defeats the purpose
:(
>From org.apache.commons.httpclient.ContentLengthInputStream
>(commons-httpclient-3.1)
{code:java}
public void close() throws IOException {
if (!closed) {
try {
ChunkedInputStream.exhaustInputStream(this);
} finally {
// close after above so that we don't throw an exception trying
// to read after closed!
closed = true;
}
}
}
{code}
Example:
{code:java}
public static void main(String[] args) throws Exception {
String url = "http://localhost/large-file-2gb.txt;;
FileSystemManager fsManager = VFS.getManager();
try (FileObject file = fsManager.resolveFile(url)) {
try (RandomAccessContent r =
file.getContent().getRandomAccessContent(RandomAccessMode.READ)) {
StopWatch sw1 = StopWatch.createStarted();
r.seek(20);
System.out.println("Initial seek: " +
sw1.getTime(TimeUnit.MILLISECONDS));
StopWatch sw2 = StopWatch.createStarted();
byte[] bytes = new byte[100];
r.readFully(bytes);
System.out.println("Read: " +
sw2.getTime(TimeUnit.MILLISECONDS));
StopWatch sw3
[jira] [Updated] (VFS-805) HTTP seek always exhausts response
[
https://issues.apache.org/jira/browse/VFS-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Stadler updated VFS-805:
--
Description:
Seeking on an HTTP resource always downloads ALL content if a Content-Length
header is present. The problem is that seeking closes the current input stream
which eventually ends up in ContentLengthInputStream.close() of the (ancient)
http client library.
See the example below.
My use case is to perform binary search on sorted datasets on the Web (RDF data
in sorted ntriple syntax) - the binary search works locally and *in principle*
works on HTTP resources abstracted with VFS2, but the seek implementation that
downloads *ALL* data (in my case several GBs) unfortunately defeats the purpose
:(
>From org.apache.commons.httpclient.ContentLengthInputStream
>(commons-httpclient-3.1)
{code:java}
public void close() throws IOException {
if (!closed) {
try {
ChunkedInputStream.exhaustInputStream(this);
} finally {
// close after above so that we don't throw an exception trying
// to read after closed!
closed = true;
}
}
}
{code}
Example:
{code:java}
public static void main(String[] args) throws Exception {
String url = "http://localhost/large-file-2gb.txt;;
FileSystemManager fsManager = VFS.getManager();
try (FileObject file = fsManager.resolveFile(url)) {
try (RandomAccessContent r =
file.getContent().getRandomAccessContent(RandomAccessMode.READ)) {
StopWatch sw1 = StopWatch.createStarted();
r.seek(20);
System.out.println("Initial seek: " +
sw1.getTime(TimeUnit.MILLISECONDS));
StopWatch sw2 = StopWatch.createStarted();
byte[] bytes = new byte[100];
r.readFully(bytes);
System.out.println("Read: " +
sw2.getTime(TimeUnit.MILLISECONDS));
StopWatch sw3 = StopWatch.createStarted();
r.seek(100);
System.out.println("Subsequent seek: " +
sw3.getTime(TimeUnit.MILLISECONDS));
}
}
System.out.println("Done");
}
{code}
Output (times in milliseconds):
{code}
Initial seek: 0
Read: 4
Subsequent seek: 2538
Done
{code}
was:
Seeking on an HTTP resource always downloads ALL content if a Content-Length
header is present. The problem is that seeking closes the current input stream
which eventually ends up in ContentLengthInputStream.close() of the (ancient)
http client library.
See the example below.
My use case is to perform binary search on sorted datasets on the Web (RDF data
in sorted ntriple syntax) - the binary search works locally and *in principle*
works on HTTP resources abstracted with VFS2, but the seek implementation that
downloads *ALL* data (in my case several GBs) unfortunately defeats the purpose
:(
{code:java}
// org.apache.commons.httpclient.ContentLengthInputStream
(commons-httpclient-3.1)
public void close() throws IOException {
if (!closed) {
try {
ChunkedInputStream.exhaustInputStream(this);
} finally {
// close after above so that we don't throw an exception trying
// to read after closed!
closed = true;
}
}
}{code}
{code:java}
public static void main(String[] args) throws Exception {
String url = "http://localhost/large-file-2gb.txt;;
FileSystemManager fsManager = VFS.getManager();
try (FileObject file = fsManager.resolveFile(url)) {
try (RandomAccessContent r =
file.getContent().getRandomAccessContent(RandomAccessMode.READ)) {
StopWatch sw1 = StopWatch.createStarted();
r.seek(20);
System.out.println("Initial seek: " +
sw1.getTime(TimeUnit.MILLISECONDS));
StopWatch sw2 = StopWatch.createStarted();
byte[] bytes = new byte[100];
r.readFully(bytes);
System.out.println("Read: " +
sw2.getTime(TimeUnit.MILLISECONDS));
StopWatch sw3 = StopWatch.createStarted();
r.seek(100);
System.out.println("Subsequent seek: " +
[jira] [Updated] (VFS-805) HTTP seek always exhausts response
[
https://issues.apache.org/jira/browse/VFS-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Stadler updated VFS-805:
--
Description:
Seeking on an HTTP resource always downloads ALL content if a Content-Length
header is present. The problem is that seeking closes the current input stream
which eventually ends up in ContentLengthInputStream.close() of the (ancient)
http client library.
See the example below.
My use case is to perform binary search on sorted datasets on the Web (RDF data
in sorted ntriple syntax) - the binary search works locally and *in principle*
works on HTTP resources abstracted with VFS2, but the seek implementation that
downloads *ALL* data (in my case several GBs) unfortunately defeats the purpose
:(
{code:java}
// org.apache.commons.httpclient.ContentLengthInputStream
(commons-httpclient-3.1)
public void close() throws IOException {
if (!closed) {
try {
ChunkedInputStream.exhaustInputStream(this);
} finally {
// close after above so that we don't throw an exception trying
// to read after closed!
closed = true;
}
}
}{code}
{code:java}
public static void main(String[] args) throws Exception {
String url = "http://localhost/large-file-2gb.txt;;
FileSystemManager fsManager = VFS.getManager();
try (FileObject file = fsManager.resolveFile(url)) {
try (RandomAccessContent r =
file.getContent().getRandomAccessContent(RandomAccessMode.READ)) {
StopWatch sw1 = StopWatch.createStarted();
r.seek(20);
System.out.println("Initial seek: " +
sw1.getTime(TimeUnit.MILLISECONDS));
StopWatch sw2 = StopWatch.createStarted();
byte[] bytes = new byte[100];
r.readFully(bytes);
System.out.println("Read: " +
sw2.getTime(TimeUnit.MILLISECONDS));
StopWatch sw3 = StopWatch.createStarted();
r.seek(100);
System.out.println("Subsequent seek: " +
sw3.getTime(TimeUnit.MILLISECONDS));
}
}
System.out.println("Done");
}
/*
Output (times in milliseconds):
Initial seek: 0
Read: 4
Subsequent seek: 2538
Done
*/
{code}
was:
Seeking on an HTTP resource always downloads ALL content if a Content-Length
header is present. The problem is that seeking closes the current input stream
which eventually ends up in ContentLengthInputStream.close() of the (ancient)
http client library.
See the example below.
My use case is to perform binary search on sorted datasets on the Web (RDF data
in sorted ntriple syntax) - the binary search works locally and *in principle*
works on HTTP resources abstract with VFS2, but the seek implementation that
downloads *ALL* data (in my case several GBs) unfortunately defeats the purpose
:(
{code:java}
// org.apache.commons.httpclient.ContentLengthInputStream
(commons-httpclient-3.1)
public void close() throws IOException {
if (!closed) {
try {
ChunkedInputStream.exhaustInputStream(this);
} finally {
// close after above so that we don't throw an exception trying
// to read after closed!
closed = true;
}
}
}{code}
{code:java}
public static void main(String[] args) throws Exception {
String url = "http://localhost/large-file-2gb.txt;;
FileSystemManager fsManager = VFS.getManager();
try (FileObject file = fsManager.resolveFile(url)) {
try (RandomAccessContent r =
file.getContent().getRandomAccessContent(RandomAccessMode.READ)) {
StopWatch sw1 = StopWatch.createStarted();
r.seek(20);
System.out.println("Initial seek: " +
sw1.getTime(TimeUnit.MILLISECONDS));
StopWatch sw2 = StopWatch.createStarted();
byte[] bytes = new byte[100];
r.readFully(bytes);
System.out.println("Read: " +
sw2.getTime(TimeUnit.MILLISECONDS));
StopWatch sw3 = StopWatch.createStarted();
r.seek(100);
System.out.println("Subsequent seek: " +
[jira] [Created] (VFS-805) HTTP seek always exhausts response
Claus Stadler created VFS-805:
-
Summary: HTTP seek always exhausts response
Key: VFS-805
URL: https://issues.apache.org/jira/browse/VFS-805
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.8.0
Reporter: Claus Stadler
Seeking on an HTTP resource always downloads ALL content if a Content-Length
header is present. The problem is that seeking closes the current input stream
which eventually ends up in ContentLengthInputStream.close() of the (ancient)
http client library.
See the example below.
My use case is to perform binary search on sorted datasets on the Web (RDF data
in sorted ntriple syntax) - the binary search works locally and *in principle*
works on HTTP resources abstract with VFS2, but the seek implementation that
downloads *ALL* data (in my case several GBs) unfortunately defeats the purpose
:(
{code:java}
// org.apache.commons.httpclient.ContentLengthInputStream
(commons-httpclient-3.1)
public void close() throws IOException {
if (!closed) {
try {
ChunkedInputStream.exhaustInputStream(this);
} finally {
// close after above so that we don't throw an exception trying
// to read after closed!
closed = true;
}
}
}{code}
{code:java}
public static void main(String[] args) throws Exception {
String url = "http://localhost/large-file-2gb.txt;;
FileSystemManager fsManager = VFS.getManager();
try (FileObject file = fsManager.resolveFile(url)) {
try (RandomAccessContent r =
file.getContent().getRandomAccessContent(RandomAccessMode.READ)) {
StopWatch sw1 = StopWatch.createStarted();
r.seek(20);
System.out.println("Initial seek: " +
sw1.getTime(TimeUnit.MILLISECONDS));
StopWatch sw2 = StopWatch.createStarted();
byte[] bytes = new byte[100];
r.readFully(bytes);
System.out.println("Read: " +
sw2.getTime(TimeUnit.MILLISECONDS));
StopWatch sw3 = StopWatch.createStarted();
r.seek(100);
System.out.println("Subsequent seek: " +
sw3.getTime(TimeUnit.MILLISECONDS));
}
}
System.out.println("Done");
}
/*
Output (times in milliseconds):
Initial seek: 0
Read: 4
Subsequent seek: 2538
Done
*/
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMMONSSITE-145) upgrade checkstyle in several commons repos
[ https://issues.apache.org/jira/browse/COMMONSSITE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17341594#comment-17341594 ] Bruno P. Kinoshita commented on COMMONSSITE-145: Commons Collections is fixed. I added an entry to changes.xml mentioning the PR number in GitHub, and also this issue in the description. I don't think we needed another issue for the COLLECTIONS component, but if that was necessary, I can create one later and amend the changes.xml file. Thanks! Bruno > upgrade checkstyle in several commons repos > --- > > Key: COMMONSSITE-145 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-145 > Project: Apache Commons All > Issue Type: Improvement >Reporter: Jin Xu >Priority: Minor > Time Spent: 1h 10m > Remaining Estimate: 0h > > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its > grammar, which means some of our repos need a manual change to upgrade to > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. > including: > https://github.com/apache/commons-lang/pull/752 > https://github.com/apache/commons-configuration/pull/118 > https://github.com/apache/commons-dbutils/pull/68 > https://github.com/apache/commons-geometry/pull/160 > https://github.com/apache/commons-collections/pull/235 > https://github.com/apache/commons-vfs/pull/181 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (COMMONSSITE-145) upgrade checkstyle in several commons repos
[ https://issues.apache.org/jira/browse/COMMONSSITE-145?focusedWorklogId=593793=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593793 ] ASF GitHub Bot logged work on COMMONSSITE-145: -- Author: ASF GitHub Bot Created on: 09/May/21 19:12 Start Date: 09/May/21 19:12 Worklog Time Spent: 10m Work Description: kinow closed pull request #235: URL: https://github.com/apache/commons-collections/pull/235 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 593793) Time Spent: 1h (was: 50m) > upgrade checkstyle in several commons repos > --- > > Key: COMMONSSITE-145 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-145 > Project: Apache Commons All > Issue Type: Improvement >Reporter: Jin Xu >Priority: Minor > Time Spent: 1h > Remaining Estimate: 0h > > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its > grammar, which means some of our repos need a manual change to upgrade to > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. > including: > https://github.com/apache/commons-lang/pull/752 > https://github.com/apache/commons-configuration/pull/118 > https://github.com/apache/commons-dbutils/pull/68 > https://github.com/apache/commons-geometry/pull/160 > https://github.com/apache/commons-collections/pull/235 > https://github.com/apache/commons-vfs/pull/181 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (COMMONSSITE-145) upgrade checkstyle in several commons repos
[ https://issues.apache.org/jira/browse/COMMONSSITE-145?focusedWorklogId=593794=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593794 ] ASF GitHub Bot logged work on COMMONSSITE-145: -- Author: ASF GitHub Bot Created on: 09/May/21 19:12 Start Date: 09/May/21 19:12 Worklog Time Spent: 10m Work Description: kinow commented on pull request #235: URL: https://github.com/apache/commons-collections/pull/235#issuecomment-835866485 Merged, 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 593794) Time Spent: 1h 10m (was: 1h) > upgrade checkstyle in several commons repos > --- > > Key: COMMONSSITE-145 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-145 > Project: Apache Commons All > Issue Type: Improvement >Reporter: Jin Xu >Priority: Minor > Time Spent: 1h 10m > Remaining Estimate: 0h > > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its > grammar, which means some of our repos need a manual change to upgrade to > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. > including: > https://github.com/apache/commons-lang/pull/752 > https://github.com/apache/commons-configuration/pull/118 > https://github.com/apache/commons-dbutils/pull/68 > https://github.com/apache/commons-geometry/pull/160 > https://github.com/apache/commons-collections/pull/235 > https://github.com/apache/commons-vfs/pull/181 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-collections] kinow commented on pull request #235: [COMMONSSITE-145]upgrade checkstyle
kinow commented on pull request #235: URL: https://github.com/apache/commons-collections/pull/235#issuecomment-835866485 Merged, 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-collections] kinow closed pull request #235: [COMMONSSITE-145]upgrade checkstyle
kinow closed pull request #235: URL: https://github.com/apache/commons-collections/pull/235 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COMMONSSITE-145) upgrade checkstyle in several commons repos
[ https://issues.apache.org/jira/browse/COMMONSSITE-145?focusedWorklogId=593792=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593792 ] ASF GitHub Bot logged work on COMMONSSITE-145: -- Author: ASF GitHub Bot Created on: 09/May/21 19:00 Start Date: 09/May/21 19:00 Worklog Time Spent: 10m Work Description: kinow commented on pull request #235: URL: https://github.com/apache/commons-collections/pull/235#issuecomment-835864347 Thanks! Found [an issue](https://github.com/checkstyle/checkstyle/issues/7417) confirming the change and CI passing here now. LGTM -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 593792) Time Spent: 50m (was: 40m) > upgrade checkstyle in several commons repos > --- > > Key: COMMONSSITE-145 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-145 > Project: Apache Commons All > Issue Type: Improvement >Reporter: Jin Xu >Priority: Minor > Time Spent: 50m > Remaining Estimate: 0h > > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its > grammar, which means some of our repos need a manual change to upgrade to > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. > including: > https://github.com/apache/commons-lang/pull/752 > https://github.com/apache/commons-configuration/pull/118 > https://github.com/apache/commons-dbutils/pull/68 > https://github.com/apache/commons-geometry/pull/160 > https://github.com/apache/commons-collections/pull/235 > https://github.com/apache/commons-vfs/pull/181 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-collections] kinow commented on pull request #235: [COMMONSSITE-145]upgrade checkstyle
kinow commented on pull request #235: URL: https://github.com/apache/commons-collections/pull/235#issuecomment-835864347 Thanks! Found [an issue](https://github.com/checkstyle/checkstyle/issues/7417) confirming the change and CI passing here now. LGTM -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (COMMONSSITE-145) upgrade checkstyle in several commons repos
[ https://issues.apache.org/jira/browse/COMMONSSITE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jin Xu updated COMMONSSITE-145: --- Description: [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its grammar, which means some of our repos need a manual change to upgrade to [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. including: https://github.com/apache/commons-lang/pull/752 https://github.com/apache/commons-configuration/pull/118 https://github.com/apache/commons-dbutils/pull/68 https://github.com/apache/commons-geometry/pull/160 https://github.com/apache/commons-collections/pull/235 https://github.com/apache/commons-vfs/pull/181 was: [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its grammar, which means some of our repos need a manual change to upgrade to [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. including: https://github.com/apache/commons-lang/pull/752 https://github.com/apache/commons-configuration/pull/118 https://github.com/apache/commons-dbutils/pull/68 https://github.com/apache/commons-geometry/pull/160 https://github.com/apache/commons-collections/pull/235 > upgrade checkstyle in several commons repos > --- > > Key: COMMONSSITE-145 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-145 > Project: Apache Commons All > Issue Type: Improvement >Reporter: Jin Xu >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its > grammar, which means some of our repos need a manual change to upgrade to > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. > including: > https://github.com/apache/commons-lang/pull/752 > https://github.com/apache/commons-configuration/pull/118 > https://github.com/apache/commons-dbutils/pull/68 > https://github.com/apache/commons-geometry/pull/160 > https://github.com/apache/commons-collections/pull/235 > https://github.com/apache/commons-vfs/pull/181 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-vfs] XenoAmess opened a new pull request #181: [COMMONSSITE-145]upgrade checkstyle
XenoAmess opened a new pull request #181: URL: https://github.com/apache/commons-vfs/pull/181 https://issues.apache.org/jira/browse/COMMONSSITE-145 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] XenoAmess closed pull request #78: fix bug for class not found:org.apache.commons.vfs2.provider.webdav.WebdavFileProvider
XenoAmess closed pull request #78: URL: https://github.com/apache/commons-vfs/pull/78 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (COMMONSSITE-145) upgrade checkstyle in several commons repos
[ https://issues.apache.org/jira/browse/COMMONSSITE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jin Xu updated COMMONSSITE-145: --- Description: [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its grammar, which means some of our repos need a manual change to upgrade to [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. including: https://github.com/apache/commons-lang/pull/752 https://github.com/apache/commons-configuration/pull/118 https://github.com/apache/commons-dbutils/pull/68 https://github.com/apache/commons-geometry/pull/160 https://github.com/apache/commons-collections/pull/235 was: [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its grammar, which means some of our repos need a manual change to upgrade to [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. including: https://github.com/apache/commons-lang/pull/752 https://github.com/apache/commons-configuration/pull/118 https://github.com/apache/commons-dbutils/pull/68 https://github.com/apache/commons-geometry/pull/160 > upgrade checkstyle in several commons repos > --- > > Key: COMMONSSITE-145 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-145 > Project: Apache Commons All > Issue Type: Improvement >Reporter: Jin Xu >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its > grammar, which means some of our repos need a manual change to upgrade to > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. > including: > https://github.com/apache/commons-lang/pull/752 > https://github.com/apache/commons-configuration/pull/118 > https://github.com/apache/commons-dbutils/pull/68 > https://github.com/apache/commons-geometry/pull/160 > https://github.com/apache/commons-collections/pull/235 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (COMMONSSITE-145) upgrade checkstyle in several commons repos
[ https://issues.apache.org/jira/browse/COMMONSSITE-145?focusedWorklogId=593791=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593791 ] ASF GitHub Bot logged work on COMMONSSITE-145: -- Author: ASF GitHub Bot Created on: 09/May/21 17:31 Start Date: 09/May/21 17:31 Worklog Time Spent: 10m Work Description: XenoAmess commented on pull request #235: URL: https://github.com/apache/commons-collections/pull/235#issuecomment-835849249 Hi. You upgraded checkstyle version but forgot to upgrade the checkstyle xml. They changed grammar at 8.42 So that is why master cannot pass ci on travis-ci. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 593791) Time Spent: 40m (was: 0.5h) > upgrade checkstyle in several commons repos > --- > > Key: COMMONSSITE-145 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-145 > Project: Apache Commons All > Issue Type: Improvement >Reporter: Jin Xu >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its > grammar, which means some of our repos need a manual change to upgrade to > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. > including: > https://github.com/apache/commons-lang/pull/752 > https://github.com/apache/commons-configuration/pull/118 > https://github.com/apache/commons-dbutils/pull/68 > https://github.com/apache/commons-geometry/pull/160 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-collections] XenoAmess commented on pull request #235: [COMMONSSITE-145]upgrade checkstyle
XenoAmess commented on pull request #235: URL: https://github.com/apache/commons-collections/pull/235#issuecomment-835849249 Hi. You upgraded checkstyle version but forgot to upgrade the checkstyle xml. They changed grammar at 8.42 So that is why master cannot pass ci on travis-ci. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COMMONSSITE-145) upgrade checkstyle in several commons repos
[ https://issues.apache.org/jira/browse/COMMONSSITE-145?focusedWorklogId=593790=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593790 ] ASF GitHub Bot logged work on COMMONSSITE-145: -- Author: ASF GitHub Bot Created on: 09/May/21 17:30 Start Date: 09/May/21 17:30 Worklog Time Spent: 10m Work Description: XenoAmess opened a new pull request #235: URL: https://github.com/apache/commons-collections/pull/235 https://issues.apache.org/jira/browse/COMMONSSITE-145 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 593790) Time Spent: 0.5h (was: 20m) > upgrade checkstyle in several commons repos > --- > > Key: COMMONSSITE-145 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-145 > Project: Apache Commons All > Issue Type: Improvement >Reporter: Jin Xu >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its > grammar, which means some of our repos need a manual change to upgrade to > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. > including: > https://github.com/apache/commons-lang/pull/752 > https://github.com/apache/commons-configuration/pull/118 > https://github.com/apache/commons-dbutils/pull/68 > https://github.com/apache/commons-geometry/pull/160 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-collections] XenoAmess opened a new pull request #235: [COMMONSSITE-145]upgrade checkstyle
XenoAmess opened a new pull request #235: URL: https://github.com/apache/commons-collections/pull/235 https://issues.apache.org/jira/browse/COMMONSSITE-145 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (COMMONSSITE-145) upgrade checkstyle in several commons repos
[ https://issues.apache.org/jira/browse/COMMONSSITE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jin Xu updated COMMONSSITE-145: --- Description: [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its grammar, which means some of our repos need a manual change to upgrade to [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. including: https://github.com/apache/commons-lang/pull/752 https://github.com/apache/commons-configuration/pull/118 https://github.com/apache/commons-dbutils/pull/68 https://github.com/apache/commons-geometry/pull/160 was: [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its grammar, which means some of our repos need a manual change to upgrade to [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. including: https://github.com/apache/commons-lang/pull/752 https://github.com/apache/commons-configuration/pull/118 https://github.com/apache/commons-dbutils/pull/68 > upgrade checkstyle in several commons repos > --- > > Key: COMMONSSITE-145 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-145 > Project: Apache Commons All > Issue Type: Improvement >Reporter: Jin Xu >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its > grammar, which means some of our repos need a manual change to upgrade to > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. > including: > https://github.com/apache/commons-lang/pull/752 > https://github.com/apache/commons-configuration/pull/118 > https://github.com/apache/commons-dbutils/pull/68 > https://github.com/apache/commons-geometry/pull/160 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-geometry] XenoAmess opened a new pull request #160: [COMMONSSITE-145]upgrade checkstyle
XenoAmess opened a new pull request #160: URL: https://github.com/apache/commons-geometry/pull/160 https://issues.apache.org/jira/browse/COMMONSSITE-145 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NUMBERS-156) SafeNorm 3D overload
[
https://issues.apache.org/jira/browse/NUMBERS-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17341546#comment-17341546
]
Alex Herbert commented on NUMBERS-156:
--
So by my estimates you will have a fraction of numbers above 1 that overflow as
(550-512) / 550 = 38 / 550 = 7%. Likewise for underflow for numbers below 1. So
your data of about 10% non-finite approximately fits with this. The expected
fraction that can overflow is 3.5% so the number of non-overflows is 0.965^3 =
0.899. Thus you should see about 10% overflow in vectors of length 3.
However with such a large range for the exponent it is likely that many numbers
are created that do not need to be added as they are too far apart. A better
test to determine the ULP error would be to have an exponential range of only
26. Thus any squares always have to be added.
If you set the range as +550 to +524 then all numbers will overflow when
squared. You can then get a comparison of the error between SafeNorm and the
exact scaling method. You can also use +50 to +24. The SafeNorm method will
still scale these numbers with division due to the very conservative threshold
it uses. The exact scaling method will have the same error as the standard
unsafe method as these small numbers do not need to be scaled.
> SafeNorm 3D overload
>
>
> Key: NUMBERS-156
> URL: https://issues.apache.org/jira/browse/NUMBERS-156
> Project: Commons Numbers
> Issue Type: Improvement
>Reporter: Matt Juntunen
>Priority: Major
>
> We should create an overload of {{SafeNorm.value}} that accepts 3 arguments
> to potentially improve performance for 3D vectors.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (COMMONSSITE-145) upgrade checkstyle in several commons repos
[ https://issues.apache.org/jira/browse/COMMONSSITE-145?focusedWorklogId=593789=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593789 ] ASF GitHub Bot logged work on COMMONSSITE-145: -- Author: ASF GitHub Bot Created on: 09/May/21 16:14 Start Date: 09/May/21 16:14 Worklog Time Spent: 10m Work Description: coveralls commented on pull request #68: URL: https://github.com/apache/commons-dbutils/pull/68#issuecomment-835836737 [](https://coveralls.io/builds/39499035) Coverage increased (+0.02%) to 65.642% when pulling **7ef1d430439fe2a64e3542dac55a9897ce46b151 on xenoamess-fork:upgrade_checkstyle** into **c3db1e6dba63ea81201c7f9f454bdad65809b137 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 593789) Time Spent: 20m (was: 10m) > upgrade checkstyle in several commons repos > --- > > Key: COMMONSSITE-145 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-145 > Project: Apache Commons All > Issue Type: Improvement >Reporter: Jin Xu >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its > grammar, which means some of our repos need a manual change to upgrade to > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. > including: > https://github.com/apache/commons-lang/pull/752 > https://github.com/apache/commons-configuration/pull/118 > https://github.com/apache/commons-dbutils/pull/68 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-dbutils] coveralls commented on pull request #68: [COMMONSSITE-145]upgrade checkstyle
coveralls commented on pull request #68: URL: https://github.com/apache/commons-dbutils/pull/68#issuecomment-835836737 [](https://coveralls.io/builds/39499035) Coverage increased (+0.02%) to 65.642% when pulling **7ef1d430439fe2a64e3542dac55a9897ce46b151 on xenoamess-fork:upgrade_checkstyle** into **c3db1e6dba63ea81201c7f9f454bdad65809b137 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (COMMONSSITE-145) upgrade checkstyle in several commons repos
[ https://issues.apache.org/jira/browse/COMMONSSITE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jin Xu updated COMMONSSITE-145: --- Description: [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its grammar, which means some of our repos need a manual change to upgrade to [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. including: https://github.com/apache/commons-lang/pull/752 https://github.com/apache/commons-configuration/pull/118 https://github.com/apache/commons-dbutils/pull/68 was: [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its grammar, which means some of our repos need a manual change to upgrade to [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. including: https://github.com/apache/commons-lang/pull/752 https://github.com/apache/commons-configuration/pull/118 > upgrade checkstyle in several commons repos > --- > > Key: COMMONSSITE-145 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-145 > Project: Apache Commons All > Issue Type: Improvement >Reporter: Jin Xu >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its > grammar, which means some of our repos need a manual change to upgrade to > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. > including: > https://github.com/apache/commons-lang/pull/752 > https://github.com/apache/commons-configuration/pull/118 > https://github.com/apache/commons-dbutils/pull/68 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (COMMONSSITE-145) upgrade checkstyle in several commons repos
[ https://issues.apache.org/jira/browse/COMMONSSITE-145?focusedWorklogId=593788=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593788 ] ASF GitHub Bot logged work on COMMONSSITE-145: -- Author: ASF GitHub Bot Created on: 09/May/21 16:11 Start Date: 09/May/21 16:11 Worklog Time Spent: 10m Work Description: XenoAmess opened a new pull request #68: URL: https://github.com/apache/commons-dbutils/pull/68 https://issues.apache.org/jira/browse/COMMONSSITE-145 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 593788) Remaining Estimate: 0h Time Spent: 10m > upgrade checkstyle in several commons repos > --- > > Key: COMMONSSITE-145 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-145 > Project: Apache Commons All > Issue Type: Improvement >Reporter: Jin Xu >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its > grammar, which means some of our repos need a manual change to upgrade to > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. > including: > https://github.com/apache/commons-lang/pull/752 > https://github.com/apache/commons-configuration/pull/118 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-dbutils] XenoAmess opened a new pull request #68: [COMMONSSITE-145]upgrade checkstyle
XenoAmess opened a new pull request #68: URL: https://github.com/apache/commons-dbutils/pull/68 https://issues.apache.org/jira/browse/COMMONSSITE-145 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (COMMONSSITE-145) upgrade checkstyle in several commons repos
[ https://issues.apache.org/jira/browse/COMMONSSITE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jin Xu updated COMMONSSITE-145: --- Description: [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its grammar, which means some of our repos need a manual change to upgrade to [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. including: https://github.com/apache/commons-lang/pull/752 https://github.com/apache/commons-configuration/pull/118 was: [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its grammar, which means some of our repos need a manual change to upgrade to [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. including: https://github.com/apache/commons-lang/pull/752 > upgrade checkstyle in several commons repos > --- > > Key: COMMONSSITE-145 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-145 > Project: Apache Commons All > Issue Type: Improvement >Reporter: Jin Xu >Priority: Minor > > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its > grammar, which means some of our repos need a manual change to upgrade to > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. > including: > https://github.com/apache/commons-lang/pull/752 > https://github.com/apache/commons-configuration/pull/118 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-configuration] XenoAmess opened a new pull request #118: upgrade checkstyle
XenoAmess opened a new pull request #118: URL: https://github.com/apache/commons-configuration/pull/118 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (RNG-135) TetrahedronSampler: Sample uniformly from a tetrahedron
[
https://issues.apache.org/jira/browse/RNG-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17341540#comment-17341540
]
Alex Herbert commented on RNG-135:
--
Many of the shape samplers have a performance benefit from using primitives
rather than small arrays to store the coordinates. I tested the tetrahedron
sampler with array based or non array based coordinates. The sampling method
has 3 main branches to create the uniform deviates s, t, u which together sum
to less than 1. These can be used to create the sample:
{code:java}
// generate s, t, u
if (...) {
if (...) {
// update s, t, u
return createSample(s, t, u);
}
// update s, t, u
return createSample(s, t, u);
}
return createSample(s, t, u);
{code}
This can be rewritten without a method call to create the sample by falling
through and creating the sample at the end of the method:
{code:java}
// generate s, t, u
if (...) {
if (...) {
// update s, t, u
} else {
// update s, t, u
}
}
return createSample(s, t, u);
{code}
I added a JMH benchmark for the following:
||Method||Array coordinates||createSample method||
|Array|Y|Y|
|NonArray|N|Y|
|ArrayFallThrough|Y|N|
|NonArrayFallThrough|N|N|
Results:
||Size||Method||Score||Error||Relative Score||
|1|Baseline|15.83|1.09|1.00|
|1|Array|41.60|1.85|2.63|
|1|NonArray|39.61|4.99|2.50|
|1|ArrayFallThrough|44.54|2.42|2.81|
|1|NonArrayFallThrough|43.64|1.47|2.76|
|10|Baseline|147.27|4.49|1.00|
|10|Array|394.20|9.45|2.68|
|10|NonArray|400.87|9.24|2.72|
|10|ArrayFallThrough|423.88|14.23|2.88|
|10|NonArrayFallThrough|436.69|18.36|2.97|
|100|Baseline|1463.39|42.56|1.00|
|100|Array|3744.30|233.21|2.56|
|100|NonArray|3937.12|70.56|2.69|
|100|ArrayFallThrough|3854.06|41.60|2.63|
|100|NonArrayFallThrough|4116.94|63.63|2.81|
|1000|Baseline|14729.29|563.14|1.00|
|1000|Array|37375.66|672.31|2.54|
|1000|NonArray|37844.20|957.48|2.57|
|1000|ArrayFallThrough|40076.72|3939.63|2.72|
|1000|NonArrayFallThrough|42093.05|919.01|2.86|
|1|Baseline|134170.53|4274.78|1.00|
|1|Array|380554.77|15832.90|2.84|
|1|NonArray|407982.62|6280.78|3.04|
|1|ArrayFallThrough|381376.47|13830.11|2.84|
|1|NonArrayFallThrough|402414.90|7756.01|3.00|
For size 1 the non-array based coordinates are faster. For all other sizes the
array-based coordinates are faster. This is a reversal of the JMH results for
other shape samplers where the array coordinates had a performance penalty.
In almost all cases the method call to create the sample is faster than the
fall-through to create the sample.
The code in the PR uses the array based coordinates with the method call.
> TetrahedronSampler: Sample uniformly from a tetrahedron
> ---
>
> Key: RNG-135
> URL: https://issues.apache.org/jira/browse/RNG-135
> Project: Commons RNG
> Issue Type: New Feature
> Components: sampling
>Affects Versions: 1.4
>Reporter: Alex Herbert
>Assignee: Alex Herbert
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Create a sampler to sample uniformly within a
> [tetrahedron|https://en.wikipedia.org/wiki/Tetrahedron].
>
> {code:java}
> public abstract class TetrahedronSampler implements
> SharedStateSampler {
> public static TetrahedronSampler of(double[] a,
> double[] b,
> double[] c,
> double[] d,
> UniformRandomProvider rng);
> }
> {code}
> Inputs {{a,b,c,d}} are the vertices.
> Sampling can be performed using the algorithm of:
> {noformat}
> Rocchini, C & Cignoni, P (2001)
> Generating Random Points in a Tetrahedron.
> Journal of Graphics Tools 5(4), pp 9-12.
> {noformat}
> [DOI:
> 10.1080/10867651.2000.10487528|https://dx.doi.org/10.1080/10867651.2000.10487528]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] coveralls commented on pull request #752: upgrade checkstyle
coveralls commented on pull request #752: URL: https://github.com/apache/commons-lang/pull/752#issuecomment-835831317 [](https://coveralls.io/builds/39498687) Coverage remained the same at 94.927% when pulling **6362d0b8e26e3b4cf07501e177f6af214eaf524c on xenoamess-fork:upgrade_checkstyle** into **c1a0c26c305919c698196b857899e7e4725b0c45 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (COMMONSSITE-145) upgrade checkstyle in several commons repos
[ https://issues.apache.org/jira/browse/COMMONSSITE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jin Xu updated COMMONSSITE-145: --- Description: [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its grammar, which means some of our repos need a manual change to upgrade to [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. including: https://github.com/apache/commons-lang/pull/752 was:[checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its grammar, which means some of our repos need a manual change to upgrade to [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. > upgrade checkstyle in several commons repos > --- > > Key: COMMONSSITE-145 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-145 > Project: Apache Commons All > Issue Type: Improvement >Reporter: Jin Xu >Priority: Minor > > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its > grammar, which means some of our repos need a manual change to upgrade to > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. > including: > https://github.com/apache/commons-lang/pull/752 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] XenoAmess opened a new pull request #752: upgrade checkstyle
XenoAmess opened a new pull request #752: URL: https://github.com/apache/commons-lang/pull/752 https://issues.apache.org/jira/browse/COMMONSSITE-145 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (COMMONSSITE-145) upgrade checkstyle in several commons repos
[ https://issues.apache.org/jira/browse/COMMONSSITE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jin Xu updated COMMONSSITE-145: --- Summary: upgrade checkstyle in several commons repos (was: upgrade checkstyles in several commons repos) > upgrade checkstyle in several commons repos > --- > > Key: COMMONSSITE-145 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-145 > Project: Apache Commons All > Issue Type: Improvement >Reporter: Jin Xu >Priority: Minor > > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its > grammar, which means some of our repos need a manual change to upgrade to > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (COMMONSSITE-145) upgrade checkstyles in several commons repos
[ https://issues.apache.org/jira/browse/COMMONSSITE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jin Xu updated COMMONSSITE-145: --- Description: [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its grammar, which means some of our repos need a manual change to upgrade to checkstyles 8.42. (was: [checkstyle](https://github.com/checkstyle/checkstyle) 8.42 changes its grammar, which means some of our repos need a manual change to upgrade to checkstyles 8.42.) > upgrade checkstyles in several commons repos > > > Key: COMMONSSITE-145 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-145 > Project: Apache Commons All > Issue Type: Improvement >Reporter: Jin Xu >Priority: Minor > > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its > grammar, which means some of our repos need a manual change to upgrade to > checkstyles 8.42. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (COMMONSSITE-145) upgrade checkstyles in several commons repos
[ https://issues.apache.org/jira/browse/COMMONSSITE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jin Xu updated COMMONSSITE-145: --- Description: [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its grammar, which means some of our repos need a manual change to upgrade to [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. (was: [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its grammar, which means some of our repos need a manual change to upgrade to checkstyles 8.42.) > upgrade checkstyles in several commons repos > > > Key: COMMONSSITE-145 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-145 > Project: Apache Commons All > Issue Type: Improvement >Reporter: Jin Xu >Priority: Minor > > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42 changes its > grammar, which means some of our repos need a manual change to upgrade to > [checkstyle|https://github.com/checkstyle/checkstyle] 8.42. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (COMMONSSITE-145) upgrade checkstyles in several commons repos
[ https://issues.apache.org/jira/browse/COMMONSSITE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jin Xu updated COMMONSSITE-145: --- Description: [checkstyle](https://github.com/checkstyle/checkstyle) 8.42 changes its grammar, which means some of our repos need a manual change to upgrade to checkstyles 8.42. (was: checkstyles 8.42 changes its grammar, which means some of our repos need a manual change to upgrade to checkstyles 8.42.) > upgrade checkstyles in several commons repos > > > Key: COMMONSSITE-145 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-145 > Project: Apache Commons All > Issue Type: Improvement >Reporter: Jin Xu >Priority: Minor > > [checkstyle](https://github.com/checkstyle/checkstyle) 8.42 changes its > grammar, which means some of our repos need a manual change to upgrade to > checkstyles 8.42. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (COMMONSSITE-145) upgrade checkstyles in several commons repos
Jin Xu created COMMONSSITE-145: -- Summary: upgrade checkstyles in several commons repos Key: COMMONSSITE-145 URL: https://issues.apache.org/jira/browse/COMMONSSITE-145 Project: Apache Commons All Issue Type: Improvement Reporter: Jin Xu checkstyles 8.42 changes its grammar, which means some of our repos need a manual change to upgrade to checkstyles 8.42. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
[
https://issues.apache.org/jira/browse/COMPRESS-565?focusedWorklogId=593784=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593784
]
ASF GitHub Bot logged work on COMPRESS-565:
---
Author: ASF GitHub Bot
Created on: 09/May/21 15:08
Start Date: 09/May/21 15:08
Worklog Time Spent: 10m
Work Description: bodewig commented on pull request #169:
URL: https://github.com/apache/commons-compress/pull/169#issuecomment-835824973
@PeterAlfredLee I had another look and I don't think you've addressed my
comment from
https://github.com/apache/commons-compress/pull/169#issuecomment-788865243 -
but we can deal with that after the PR has been merged.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 593784)
Time Spent: 3h 10m (was: 3h)
> Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
> ---
>
> Key: COMPRESS-565
> URL: https://issues.apache.org/jira/browse/COMPRESS-565
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: Evgenii Bovykin
>Assignee: Peter Lee
>Priority: Major
> Fix For: 1.21
>
> Attachments: commons-compress-1.21-SNAPSHOT.jar,
> image-2021-02-20-15-51-21-747.png
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> We've recently updated commons-compress library from version 1.9 to 1.20 and
> now experiencing the problem that didn't occur before.
>
> When using ZipArchiveOutputStream to archive 5Gb file and setting the
> following fields
> {{output.setUseZip64(Zip64Mode.Always)}}
>
> {{output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)}}
> resulting archive contains corrupted headers.
> *Expand-Archive Powershell utility cannot extract the archive at all with the
> error about corrupted header. 7zip also complains about it, but can extract
> the archive.*
>
> The problem didn't appear when using library version 1.9.
>
> I've created a sample project that reproduces the error -
> [https://github.com/missingdays/commons-compress-example]
> Issue doesn't reproduce if you do any of the following:
>
> # Downgrade library to version 1.9
> # Remove
> output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)
> # Remove output.setUseZip64(Zip64Mode.Always) and zip smaller file (e.g. 1Gb)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] bodewig commented on pull request #169: COMPRESS-565 : add a new AlwaysWithComestibles in Zip64Mode
bodewig commented on pull request #169: URL: https://github.com/apache/commons-compress/pull/169#issuecomment-835824973 @PeterAlfredLee I had another look and I don't think you've addressed my comment from https://github.com/apache/commons-compress/pull/169#issuecomment-788865243 - but we can deal with that after the PR has been merged. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
[
https://issues.apache.org/jira/browse/COMPRESS-565?focusedWorklogId=593783=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593783
]
ASF GitHub Bot logged work on COMPRESS-565:
---
Author: ASF GitHub Bot
Created on: 09/May/21 15:02
Start Date: 09/May/21 15:02
Worklog Time Spent: 10m
Work Description: bodewig commented on pull request #169:
URL: https://github.com/apache/commons-compress/pull/169#issuecomment-835823881
you may want to change the name of the test method. Other than that, please
just go ahead.
@garydgregory "comestible" is almost only present in the PR's title. Peter
has fixed the occurrences in code already.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 593783)
Time Spent: 3h (was: 2h 50m)
> Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
> ---
>
> Key: COMPRESS-565
> URL: https://issues.apache.org/jira/browse/COMPRESS-565
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: Evgenii Bovykin
>Assignee: Peter Lee
>Priority: Major
> Fix For: 1.21
>
> Attachments: commons-compress-1.21-SNAPSHOT.jar,
> image-2021-02-20-15-51-21-747.png
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> We've recently updated commons-compress library from version 1.9 to 1.20 and
> now experiencing the problem that didn't occur before.
>
> When using ZipArchiveOutputStream to archive 5Gb file and setting the
> following fields
> {{output.setUseZip64(Zip64Mode.Always)}}
>
> {{output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)}}
> resulting archive contains corrupted headers.
> *Expand-Archive Powershell utility cannot extract the archive at all with the
> error about corrupted header. 7zip also complains about it, but can extract
> the archive.*
>
> The problem didn't appear when using library version 1.9.
>
> I've created a sample project that reproduces the error -
> [https://github.com/missingdays/commons-compress-example]
> Issue doesn't reproduce if you do any of the following:
>
> # Downgrade library to version 1.9
> # Remove
> output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)
> # Remove output.setUseZip64(Zip64Mode.Always) and zip smaller file (e.g. 1Gb)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] bodewig commented on pull request #169: COMPRESS-565 : add a new AlwaysWithComestibles in Zip64Mode
bodewig commented on pull request #169: URL: https://github.com/apache/commons-compress/pull/169#issuecomment-835823881 you may want to change the name of the test method. Other than that, please just go ahead. @garydgregory "comestible" is almost only present in the PR's title. Peter has fixed the occurrences in code already. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
[
https://issues.apache.org/jira/browse/COMPRESS-565?focusedWorklogId=593782=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593782
]
ASF GitHub Bot logged work on COMPRESS-565:
---
Author: ASF GitHub Bot
Created on: 09/May/21 15:00
Start Date: 09/May/21 15:00
Worklog Time Spent: 10m
Work Description: garydgregory commented on pull request #169:
URL: https://github.com/apache/commons-compress/pull/169#issuecomment-835823337
Surely we can come up with a better name than a "food item" (comestible) or
is that term used in the zip spec itself?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 593782)
Time Spent: 2h 50m (was: 2h 40m)
> Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
> ---
>
> Key: COMPRESS-565
> URL: https://issues.apache.org/jira/browse/COMPRESS-565
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: Evgenii Bovykin
>Assignee: Peter Lee
>Priority: Major
> Fix For: 1.21
>
> Attachments: commons-compress-1.21-SNAPSHOT.jar,
> image-2021-02-20-15-51-21-747.png
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> We've recently updated commons-compress library from version 1.9 to 1.20 and
> now experiencing the problem that didn't occur before.
>
> When using ZipArchiveOutputStream to archive 5Gb file and setting the
> following fields
> {{output.setUseZip64(Zip64Mode.Always)}}
>
> {{output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)}}
> resulting archive contains corrupted headers.
> *Expand-Archive Powershell utility cannot extract the archive at all with the
> error about corrupted header. 7zip also complains about it, but can extract
> the archive.*
>
> The problem didn't appear when using library version 1.9.
>
> I've created a sample project that reproduces the error -
> [https://github.com/missingdays/commons-compress-example]
> Issue doesn't reproduce if you do any of the following:
>
> # Downgrade library to version 1.9
> # Remove
> output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)
> # Remove output.setUseZip64(Zip64Mode.Always) and zip smaller file (e.g. 1Gb)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] garydgregory commented on pull request #169: COMPRESS-565 : add a new AlwaysWithComestibles in Zip64Mode
garydgregory commented on pull request #169: URL: https://github.com/apache/commons-compress/pull/169#issuecomment-835823337 Surely we can come up with a better name than a "food item" (comestible) or is that term used in the zip spec itself? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-165) [lang] parseDate with TimeZone
[
https://issues.apache.org/jira/browse/LANG-165?focusedWorklogId=593780=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593780
]
ASF GitHub Bot logged work on LANG-165:
---
Author: ASF GitHub Bot
Created on: 09/May/21 14:41
Start Date: 09/May/21 14:41
Worklog Time Spent: 10m
Work Description: garydgregory commented on a change in pull request #751:
URL: https://github.com/apache/commons-lang/pull/751#discussion_r628897878
##
File path: src/main/java/org/apache/commons/lang3/StringUtils.java
##
@@ -9638,6 +9638,79 @@ public static String wrapIfMissing(final String str,
final String wrapWith) {
return builder.toString();
}
+/**
+ * Method that assembles all the numbers, form the passed string and
returns them as list.
+ * It is important to note here, is that bu 'number' method assume any
digit sequence, that
+ * can (but not necessary at all) contains dot within it (I mean just
plain old floats,
+ * something like 51.82)
+ *
+ * For example, you may pass a string "21.2 days 3 minutes 22 seconds".
For this particular string
+ * the result list of doubles will look like this : [21.2, 3.0, 22.0]
+ *
+ * if string contains invalid numbers (for example this string contains
+ * not valid number: "My height is 1234.23.13" This is invalid because it
+ * is not clear how to parse this part - 1234.23.13), {@link
NumberFormatException}
+ * will be thrown. Though if string will contain number, where right
+ * after second dot resides not a number, or, any other char, then this
+ * case will be considered as valid. For example, this string contains
+ * only valid numbers: "My pulse is 90.123. and weight is 78.2"
+ * In this case sequence "90.123." will be considered as "90.123", as well
as
+ * sequence "90." (imagine that there is no digit right after dot) will be
+ * considered as 90.0 double.
+ *
+ * @param stringThatContainsNumbers - string, that contains number or
several numbers.
+ * Not necessary integers, may be numbers
with float point.
+ * @return - list of numbers, that this particular string contains
+ *
+ * @throws NumberFormatException - see documentation clarification about
cases when thrown above
+ */
+public static List extractNumbersFromString(String
stringThatContainsNumbers) {
Review comment:
The API name says Number but the return type says Double. They should
match.
But as soon as you type an API to Double, someone will want one for Integer,
Long, 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 593780)
Time Spent: 40m (was: 0.5h)
> [lang] parseDate with TimeZone
> --
>
> Key: LANG-165
> URL: https://issues.apache.org/jira/browse/LANG-165
> Project: Commons Lang
> Issue Type: Improvement
>Affects Versions: 2.1
> Environment: Operating System: All
> Platform: All
>Reporter: Bill Boland
>Priority: Minor
> Fix For: 2.2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I needed the ability to user a function like the
> org.apache.commons.lang.time.DateUtils.parseDate function but I needed to
> consider a different time zone when parsing the dates (assuming the format
> did
> not have the time zone as part of the input). This is needed for different
> clients to enter local date/time values on their browser and consider their
> defined time zone to convert this to the server/system time zone. I just
> thought an additional parameter to this function would make it more generic
> for this purpose while still keeping the current method signate which would
> use the tiem zone sensitive one with a null or default timezone value.
> Anyway, just thought I'd suggest it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-165) [lang] parseDate with TimeZone
[
https://issues.apache.org/jira/browse/LANG-165?focusedWorklogId=593779=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593779
]
ASF GitHub Bot logged work on LANG-165:
---
Author: ASF GitHub Bot
Created on: 09/May/21 14:40
Start Date: 09/May/21 14:40
Worklog Time Spent: 10m
Work Description: garydgregory commented on a change in pull request #751:
URL: https://github.com/apache/commons-lang/pull/751#discussion_r628897878
##
File path: src/main/java/org/apache/commons/lang3/StringUtils.java
##
@@ -9638,6 +9638,79 @@ public static String wrapIfMissing(final String str,
final String wrapWith) {
return builder.toString();
}
+/**
+ * Method that assembles all the numbers, form the passed string and
returns them as list.
+ * It is important to note here, is that bu 'number' method assume any
digit sequence, that
+ * can (but not necessary at all) contains dot within it (I mean just
plain old floats,
+ * something like 51.82)
+ *
+ * For example, you may pass a string "21.2 days 3 minutes 22 seconds".
For this particular string
+ * the result list of doubles will look like this : [21.2, 3.0, 22.0]
+ *
+ * if string contains invalid numbers (for example this string contains
+ * not valid number: "My height is 1234.23.13" This is invalid because it
+ * is not clear how to parse this part - 1234.23.13), {@link
NumberFormatException}
+ * will be thrown. Though if string will contain number, where right
+ * after second dot resides not a number, or, any other char, then this
+ * case will be considered as valid. For example, this string contains
+ * only valid numbers: "My pulse is 90.123. and weight is 78.2"
+ * In this case sequence "90.123." will be considered as "90.123", as well
as
+ * sequence "90." (imagine that there is no digit right after dot) will be
+ * considered as 90.0 double.
+ *
+ * @param stringThatContainsNumbers - string, that contains number or
several numbers.
+ * Not necessary integers, may be numbers
with float point.
+ * @return - list of numbers, that this particular string contains
+ *
+ * @throws NumberFormatException - see documentation clarification about
cases when thrown above
+ */
+public static List extractNumbersFromString(String
stringThatContainsNumbers) {
Review comment:
The API name says Number but the return type says Double. They should
match.
But as soon as you type an API to double, someone will want one for Integer,
Long, 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 593779)
Time Spent: 0.5h (was: 20m)
> [lang] parseDate with TimeZone
> --
>
> Key: LANG-165
> URL: https://issues.apache.org/jira/browse/LANG-165
> Project: Commons Lang
> Issue Type: Improvement
>Affects Versions: 2.1
> Environment: Operating System: All
> Platform: All
>Reporter: Bill Boland
>Priority: Minor
> Fix For: 2.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I needed the ability to user a function like the
> org.apache.commons.lang.time.DateUtils.parseDate function but I needed to
> consider a different time zone when parsing the dates (assuming the format
> did
> not have the time zone as part of the input). This is needed for different
> clients to enter local date/time values on their browser and consider their
> defined time zone to convert this to the server/system time zone. I just
> thought an additional parameter to this function would make it more generic
> for this purpose while still keeping the current method signate which would
> use the tiem zone sensitive one with a null or default timezone value.
> Anyway, just thought I'd suggest it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] garydgregory commented on a change in pull request #751: create API for searching for numbers within string - solving LANG-165…
garydgregory commented on a change in pull request #751:
URL: https://github.com/apache/commons-lang/pull/751#discussion_r628897878
##
File path: src/main/java/org/apache/commons/lang3/StringUtils.java
##
@@ -9638,6 +9638,79 @@ public static String wrapIfMissing(final String str,
final String wrapWith) {
return builder.toString();
}
+/**
+ * Method that assembles all the numbers, form the passed string and
returns them as list.
+ * It is important to note here, is that bu 'number' method assume any
digit sequence, that
+ * can (but not necessary at all) contains dot within it (I mean just
plain old floats,
+ * something like 51.82)
+ *
+ * For example, you may pass a string "21.2 days 3 minutes 22 seconds".
For this particular string
+ * the result list of doubles will look like this : [21.2, 3.0, 22.0]
+ *
+ * if string contains invalid numbers (for example this string contains
+ * not valid number: "My height is 1234.23.13" This is invalid because it
+ * is not clear how to parse this part - 1234.23.13), {@link
NumberFormatException}
+ * will be thrown. Though if string will contain number, where right
+ * after second dot resides not a number, or, any other char, then this
+ * case will be considered as valid. For example, this string contains
+ * only valid numbers: "My pulse is 90.123. and weight is 78.2"
+ * In this case sequence "90.123." will be considered as "90.123", as well
as
+ * sequence "90." (imagine that there is no digit right after dot) will be
+ * considered as 90.0 double.
+ *
+ * @param stringThatContainsNumbers - string, that contains number or
several numbers.
+ * Not necessary integers, may be numbers
with float point.
+ * @return - list of numbers, that this particular string contains
+ *
+ * @throws NumberFormatException - see documentation clarification about
cases when thrown above
+ */
+public static List extractNumbersFromString(String
stringThatContainsNumbers) {
Review comment:
The API name says Number but the return type says Double. They should
match.
But as soon as you type an API to Double, someone will want one for Integer,
Long, 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-lang] garydgregory commented on a change in pull request #751: create API for searching for numbers within string - solving LANG-165…
garydgregory commented on a change in pull request #751:
URL: https://github.com/apache/commons-lang/pull/751#discussion_r628897878
##
File path: src/main/java/org/apache/commons/lang3/StringUtils.java
##
@@ -9638,6 +9638,79 @@ public static String wrapIfMissing(final String str,
final String wrapWith) {
return builder.toString();
}
+/**
+ * Method that assembles all the numbers, form the passed string and
returns them as list.
+ * It is important to note here, is that bu 'number' method assume any
digit sequence, that
+ * can (but not necessary at all) contains dot within it (I mean just
plain old floats,
+ * something like 51.82)
+ *
+ * For example, you may pass a string "21.2 days 3 minutes 22 seconds".
For this particular string
+ * the result list of doubles will look like this : [21.2, 3.0, 22.0]
+ *
+ * if string contains invalid numbers (for example this string contains
+ * not valid number: "My height is 1234.23.13" This is invalid because it
+ * is not clear how to parse this part - 1234.23.13), {@link
NumberFormatException}
+ * will be thrown. Though if string will contain number, where right
+ * after second dot resides not a number, or, any other char, then this
+ * case will be considered as valid. For example, this string contains
+ * only valid numbers: "My pulse is 90.123. and weight is 78.2"
+ * In this case sequence "90.123." will be considered as "90.123", as well
as
+ * sequence "90." (imagine that there is no digit right after dot) will be
+ * considered as 90.0 double.
+ *
+ * @param stringThatContainsNumbers - string, that contains number or
several numbers.
+ * Not necessary integers, may be numbers
with float point.
+ * @return - list of numbers, that this particular string contains
+ *
+ * @throws NumberFormatException - see documentation clarification about
cases when thrown above
+ */
+public static List extractNumbersFromString(String
stringThatContainsNumbers) {
Review comment:
The API name says Number but the return type says Double. They should
match.
But as soon as you type an API to double, someone will want one for Integer,
Long, 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (LANG-165) [lang] parseDate with TimeZone
[
https://issues.apache.org/jira/browse/LANG-165?focusedWorklogId=593778=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593778
]
ASF GitHub Bot logged work on LANG-165:
---
Author: ASF GitHub Bot
Created on: 09/May/21 14:39
Start Date: 09/May/21 14:39
Worklog Time Spent: 10m
Work Description: garydgregory commented on a change in pull request #751:
URL: https://github.com/apache/commons-lang/pull/751#discussion_r628898328
##
File path: src/test/java/org/apache/commons/lang3/StringUtilsTest.java
##
@@ -3338,6 +3341,95 @@ public void testToRootUpperCase() {
}
}
+@Test
+void extractNumbersFromString() {
Review comment:
By convention test method have the "test" prefix.
You should break up each use case in their own method IMO.
There are no tests for edge cases: null and empty string. Also a non empty
string with no numbers.
##
File path: src/main/java/org/apache/commons/lang3/StringUtils.java
##
@@ -9638,6 +9638,79 @@ public static String wrapIfMissing(final String str,
final String wrapWith) {
return builder.toString();
}
+/**
+ * Method that assembles all the numbers, form the passed string and
returns them as list.
+ * It is important to note here, is that bu 'number' method assume any
digit sequence, that
+ * can (but not necessary at all) contains dot within it (I mean just
plain old floats,
+ * something like 51.82)
+ *
+ * For example, you may pass a string "21.2 days 3 minutes 22 seconds".
For this particular string
+ * the result list of doubles will look like this : [21.2, 3.0, 22.0]
+ *
+ * if string contains invalid numbers (for example this string contains
+ * not valid number: "My height is 1234.23.13" This is invalid because it
+ * is not clear how to parse this part - 1234.23.13), {@link
NumberFormatException}
+ * will be thrown. Though if string will contain number, where right
+ * after second dot resides not a number, or, any other char, then this
+ * case will be considered as valid. For example, this string contains
+ * only valid numbers: "My pulse is 90.123. and weight is 78.2"
+ * In this case sequence "90.123." will be considered as "90.123", as well
as
+ * sequence "90." (imagine that there is no digit right after dot) will be
+ * considered as 90.0 double.
+ *
+ * @param stringThatContainsNumbers - string, that contains number or
several numbers.
+ * Not necessary integers, may be numbers
with float point.
+ * @return - list of numbers, that this particular string contains
+ *
+ * @throws NumberFormatException - see documentation clarification about
cases when thrown above
+ */
+public static List extractNumbersFromString(String
stringThatContainsNumbers) {
+boolean hasDigitAlreadyStarted = false;
+boolean alreadyMetDotInThisNumber = false;
+
+List resultList = new ArrayList<>();
+
+StringBuilder currentNumberAsStringBuilder = new StringBuilder("");
+
+for (int i = 0; i < stringThatContainsNumbers.length(); i++) {
+char currentSymbol = stringThatContainsNumbers.charAt(i);
+if (Character.isDigit(currentSymbol)) {
+if (!hasDigitAlreadyStarted) {
+hasDigitAlreadyStarted = true;
+}
+currentNumberAsStringBuilder.append(currentSymbol);
+continue;
+} else if (currentSymbol == '.') {
Review comment:
This will not work on locales that use a different character for the
decimal marker.
##
File path: src/main/java/org/apache/commons/lang3/StringUtils.java
##
@@ -9638,6 +9638,79 @@ public static String wrapIfMissing(final String str,
final String wrapWith) {
return builder.toString();
}
+/**
+ * Method that assembles all the numbers, form the passed string and
returns them as list.
+ * It is important to note here, is that bu 'number' method assume any
digit sequence, that
+ * can (but not necessary at all) contains dot within it (I mean just
plain old floats,
+ * something like 51.82)
+ *
+ * For example, you may pass a string "21.2 days 3 minutes 22 seconds".
For this particular string
+ * the result list of doubles will look like this : [21.2, 3.0, 22.0]
+ *
+ * if string contains invalid numbers (for example this string contains
+ * not valid number: "My height is 1234.23.13" This is invalid because it
+ * is not clear how to parse this part - 1234.23.13), {@link
NumberFormatException}
+ * will be thrown. Though if string will contain number, where right
+ * after second dot resides not a number, or, any other char, then this
+ * case will be considered as
[GitHub] [commons-lang] garydgregory commented on a change in pull request #751: create API for searching for numbers within string - solving LANG-165…
garydgregory commented on a change in pull request #751:
URL: https://github.com/apache/commons-lang/pull/751#discussion_r628898328
##
File path: src/test/java/org/apache/commons/lang3/StringUtilsTest.java
##
@@ -3338,6 +3341,95 @@ public void testToRootUpperCase() {
}
}
+@Test
+void extractNumbersFromString() {
Review comment:
By convention test method have the "test" prefix.
You should break up each use case in their own method IMO.
There are no tests for edge cases: null and empty string. Also a non empty
string with no numbers.
##
File path: src/main/java/org/apache/commons/lang3/StringUtils.java
##
@@ -9638,6 +9638,79 @@ public static String wrapIfMissing(final String str,
final String wrapWith) {
return builder.toString();
}
+/**
+ * Method that assembles all the numbers, form the passed string and
returns them as list.
+ * It is important to note here, is that bu 'number' method assume any
digit sequence, that
+ * can (but not necessary at all) contains dot within it (I mean just
plain old floats,
+ * something like 51.82)
+ *
+ * For example, you may pass a string "21.2 days 3 minutes 22 seconds".
For this particular string
+ * the result list of doubles will look like this : [21.2, 3.0, 22.0]
+ *
+ * if string contains invalid numbers (for example this string contains
+ * not valid number: "My height is 1234.23.13" This is invalid because it
+ * is not clear how to parse this part - 1234.23.13), {@link
NumberFormatException}
+ * will be thrown. Though if string will contain number, where right
+ * after second dot resides not a number, or, any other char, then this
+ * case will be considered as valid. For example, this string contains
+ * only valid numbers: "My pulse is 90.123. and weight is 78.2"
+ * In this case sequence "90.123." will be considered as "90.123", as well
as
+ * sequence "90." (imagine that there is no digit right after dot) will be
+ * considered as 90.0 double.
+ *
+ * @param stringThatContainsNumbers - string, that contains number or
several numbers.
+ * Not necessary integers, may be numbers
with float point.
+ * @return - list of numbers, that this particular string contains
+ *
+ * @throws NumberFormatException - see documentation clarification about
cases when thrown above
+ */
+public static List extractNumbersFromString(String
stringThatContainsNumbers) {
+boolean hasDigitAlreadyStarted = false;
+boolean alreadyMetDotInThisNumber = false;
+
+List resultList = new ArrayList<>();
+
+StringBuilder currentNumberAsStringBuilder = new StringBuilder("");
+
+for (int i = 0; i < stringThatContainsNumbers.length(); i++) {
+char currentSymbol = stringThatContainsNumbers.charAt(i);
+if (Character.isDigit(currentSymbol)) {
+if (!hasDigitAlreadyStarted) {
+hasDigitAlreadyStarted = true;
+}
+currentNumberAsStringBuilder.append(currentSymbol);
+continue;
+} else if (currentSymbol == '.') {
Review comment:
This will not work on locales that use a different character for the
decimal marker.
##
File path: src/main/java/org/apache/commons/lang3/StringUtils.java
##
@@ -9638,6 +9638,79 @@ public static String wrapIfMissing(final String str,
final String wrapWith) {
return builder.toString();
}
+/**
+ * Method that assembles all the numbers, form the passed string and
returns them as list.
+ * It is important to note here, is that bu 'number' method assume any
digit sequence, that
+ * can (but not necessary at all) contains dot within it (I mean just
plain old floats,
+ * something like 51.82)
+ *
+ * For example, you may pass a string "21.2 days 3 minutes 22 seconds".
For this particular string
+ * the result list of doubles will look like this : [21.2, 3.0, 22.0]
+ *
+ * if string contains invalid numbers (for example this string contains
+ * not valid number: "My height is 1234.23.13" This is invalid because it
+ * is not clear how to parse this part - 1234.23.13), {@link
NumberFormatException}
+ * will be thrown. Though if string will contain number, where right
+ * after second dot resides not a number, or, any other char, then this
+ * case will be considered as valid. For example, this string contains
+ * only valid numbers: "My pulse is 90.123. and weight is 78.2"
+ * In this case sequence "90.123." will be considered as "90.123", as well
as
+ * sequence "90." (imagine that there is no digit right after dot) will be
+ * considered as 90.0 double.
+ *
+ * @param stringThatContainsNumbers - string, that contains number or
several numbers.
+ *
[jira] [Work logged] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
[
https://issues.apache.org/jira/browse/COMPRESS-565?focusedWorklogId=593773=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593773
]
ASF GitHub Bot logged work on COMPRESS-565:
---
Author: ASF GitHub Bot
Created on: 09/May/21 12:58
Start Date: 09/May/21 12:58
Worklog Time Spent: 10m
Work Description: PeterAlfredLee commented on pull request #169:
URL: https://github.com/apache/commons-compress/pull/169#issuecomment-835802713
I'm thinking about merge this PR.
Are there anything to be modified about this PR? @bodewig
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 593773)
Time Spent: 2h 40m (was: 2.5h)
> Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
> ---
>
> Key: COMPRESS-565
> URL: https://issues.apache.org/jira/browse/COMPRESS-565
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: Evgenii Bovykin
>Assignee: Peter Lee
>Priority: Major
> Fix For: 1.21
>
> Attachments: commons-compress-1.21-SNAPSHOT.jar,
> image-2021-02-20-15-51-21-747.png
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> We've recently updated commons-compress library from version 1.9 to 1.20 and
> now experiencing the problem that didn't occur before.
>
> When using ZipArchiveOutputStream to archive 5Gb file and setting the
> following fields
> {{output.setUseZip64(Zip64Mode.Always)}}
>
> {{output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)}}
> resulting archive contains corrupted headers.
> *Expand-Archive Powershell utility cannot extract the archive at all with the
> error about corrupted header. 7zip also complains about it, but can extract
> the archive.*
>
> The problem didn't appear when using library version 1.9.
>
> I've created a sample project that reproduces the error -
> [https://github.com/missingdays/commons-compress-example]
> Issue doesn't reproduce if you do any of the following:
>
> # Downgrade library to version 1.9
> # Remove
> output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)
> # Remove output.setUseZip64(Zip64Mode.Always) and zip smaller file (e.g. 1Gb)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] PeterAlfredLee commented on pull request #169: COMPRESS-565 : add a new AlwaysWithComestibles in Zip64Mode
PeterAlfredLee commented on pull request #169: URL: https://github.com/apache/commons-compress/pull/169#issuecomment-835802713 I'm thinking about merge this PR. Are there anything to be modified about this PR? @bodewig -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NUMBERS-156) SafeNorm 3D overload
[
https://issues.apache.org/jira/browse/NUMBERS-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17341499#comment-17341499
]
Matt Juntunen commented on NUMBERS-156:
---
bq. How are you generating the random vectors? Roughly what is the power of 2
exponent for each double, and the range of exponents over the numbers that are
summed?
I used a modified version of a random double generator from one of your
performance tests. For the benchmark posted above, I used {{maxExp = +550}} and
{{minExp = -550}}.
{code:java}
private double randomDouble() {
// Create random doubles using random bits in the sign bit and the
mantissa.
final long mask = ((1L << 52) - 1) | 1L << 63;
final long bits = rng.nextLong() & mask;
// The exponent must be unsigned so + 1023 to the signed exponent
final int expRange = Math.abs(maxExp - minExp);
final long exp = rng.nextInt(expRange) + minExp + 1023;
return Double.longBitsToDouble(bits | (exp << 52));
}
{code}
bq. I would favour the verbose manhatten, euclidian and maximum.
Same here. I'll start working toward that.
> SafeNorm 3D overload
>
>
> Key: NUMBERS-156
> URL: https://issues.apache.org/jira/browse/NUMBERS-156
> Project: Commons Numbers
> Issue Type: Improvement
>Reporter: Matt Juntunen
>Priority: Major
>
> We should create an overload of {{SafeNorm.value}} that accepts 3 arguments
> to potentially improve performance for 3D vectors.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-165) [lang] parseDate with TimeZone
[ https://issues.apache.org/jira/browse/LANG-165?focusedWorklogId=593763=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-593763 ] ASF GitHub Bot logged work on LANG-165: --- Author: ASF GitHub Bot Created on: 09/May/21 09:28 Start Date: 09/May/21 09:28 Worklog Time Spent: 10m Work Description: Mikhail-Polivakha opened a new pull request #751: URL: https://github.com/apache/commons-lang/pull/751 Solving Jira LANG-1658 issue. Unit test with multiple assertions is included. Jira issue reference: https://issues.apache.org/jira/browse/LANG-1658 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 593763) Remaining Estimate: 0h Time Spent: 10m > [lang] parseDate with TimeZone > -- > > Key: LANG-165 > URL: https://issues.apache.org/jira/browse/LANG-165 > Project: Commons Lang > Issue Type: Improvement >Affects Versions: 2.1 > Environment: Operating System: All > Platform: All >Reporter: Bill Boland >Priority: Minor > Fix For: 2.2 > > Time Spent: 10m > Remaining Estimate: 0h > > I needed the ability to user a function like the > org.apache.commons.lang.time.DateUtils.parseDate function but I needed to > consider a different time zone when parsing the dates (assuming the format > did > not have the time zone as part of the input). This is needed for different > clients to enter local date/time values on their browser and consider their > defined time zone to convert this to the server/system time zone. I just > thought an additional parameter to this function would make it more generic > for this purpose while still keeping the current method signate which would > use the tiem zone sensitive one with a null or default timezone value. > Anyway, just thought I'd suggest it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] Mikhail-Polivakha opened a new pull request #751: create API for searching for numbers within string - solving LANG-165…
Mikhail-Polivakha opened a new pull request #751: URL: https://github.com/apache/commons-lang/pull/751 Solving Jira LANG-1658 issue. Unit test with multiple assertions is included. Jira issue reference: https://issues.apache.org/jira/browse/LANG-1658 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (LANG-1658) Create new method to search for numbers within string
Mikhail Polivakha created LANG-1658: --- Summary: 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.* Affects Versions: 3.12.0 Reporter: Mikhail Polivakha 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.3.4#803005)
