[GitHub] [commons-statistics] mmalenic opened a new pull request #26: Add truncated normal distribution.
mmalenic opened a new pull request #26: URL: https://github.com/apache/commons-statistics/pull/26 Truncated normal distribution implementation according to https://issues.apache.org/jira/browse/STATISTICS-27. 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] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
[
https://issues.apache.org/jira/browse/COMPRESS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17286905#comment-17286905
]
Peter Lee commented on COMPRESS-565:
I also tested in windows using 7zip 19.00, and it successfully extracted the
_output.zip_ without reporting any errors.
> 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
>
> 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)
[jira] [Commented] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
[
https://issues.apache.org/jira/browse/COMPRESS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17286884#comment-17286884
]
Peter Lee commented on COMPRESS-565:
And I'm testing with UnZip 6.00.
> 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
>
> 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)
[jira] [Commented] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
[
https://issues.apache.org/jira/browse/COMPRESS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17286882#comment-17286882
]
Peter Lee commented on COMPRESS-565:
I'm testing like this:
{code:java}
RandomAccessFile randomAccessFile = new RandomAccessFile("archive/input.bin",
"rw");
randomAccessFile.setLength(1024L * 1024 * 1024 * 5);
File outputFile = new File("archive/output.zip");
outputFile.createNewFile();
try(ZipArchiveOutputStream zipArchiveOutputStream = new
ZipArchiveOutputStream(new BufferedOutputStream(new
FileOutputStream(outputFile {
zipArchiveOutputStream.setUseZip64(Zip64Mode.Always);
zipArchiveOutputStream.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS);
zipArchiveOutputStream.putArchiveEntry(new ZipArchiveEntry("input.bin"));
InputStream inputStream = new FileInputStream("archive/input.bin");
IOUtils.copy(inputStream, zipArchiveOutputStream);
zipArchiveOutputStream.closeArchiveEntry();
}
{code}
And I think this test is exactly the same as yours.
I'm testing on Ubuntu and I can successfully extract the generated output.zip
using _unzip_ command without reporting any errors.
> 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
>
> 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)
[jira] [Work logged] (IO-670) IOUtils.contentEquals is of low performance. I will refine it.
[ https://issues.apache.org/jira/browse/IO-670?focusedWorklogId=554569=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554569 ] ASF GitHub Bot logged work on IO-670: - Author: ASF GitHub Bot Created on: 19/Feb/21 03:05 Start Date: 19/Feb/21 03:05 Worklog Time Spent: 10m Work Description: coveralls edited a comment on pull request #118: URL: https://github.com/apache/commons-io/pull/118#issuecomment-636980413 [](https://coveralls.io/builds/37260076) Coverage increased (+0.005%) to 89.4% when pulling **eb25f9a554b8302b5bc870c6b0c960bd74a2f45c on xenoamess-fork:refine_contentEquals** into **c54bf688e94b550c3ccd4c0789e0b3e00cf1d0ea 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: 554569) Time Spent: 14h 50m (was: 14h 40m) > IOUtils.contentEquals is of low performance. I will refine it. > -- > > Key: IO-670 > URL: https://issues.apache.org/jira/browse/IO-670 > Project: Commons IO > Issue Type: Improvement >Reporter: Jin Xu >Priority: Critical > Attachments: jmh-result.org.apache.json > > Time Spent: 14h 50m > Remaining Estimate: 0h > > [https://github.com/apache/commons-io/pull/118] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-io] coveralls edited a comment on pull request #118: [IO-670] refine IOUtils.contentEquals(Reader, Reader)
coveralls edited a comment on pull request #118: URL: https://github.com/apache/commons-io/pull/118#issuecomment-636980413 [](https://coveralls.io/builds/37260076) Coverage increased (+0.005%) to 89.4% when pulling **eb25f9a554b8302b5bc870c6b0c960bd74a2f45c on xenoamess-fork:refine_contentEquals** into **c54bf688e94b550c3ccd4c0789e0b3e00cf1d0ea 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] [Commented] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
[
https://issues.apache.org/jira/browse/COMPRESS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17286828#comment-17286828
]
Peter Lee commented on COMPRESS-565:
Not familiar with gradle and kotlin. :(
Is the input.bin an empty file with size of 5GB?
Or could you provide an example with Java using maven?
> 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
>
> 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)
[jira] [Comment Edited] (IO-670) IOUtils.contentEquals is of low performance. I will refine it.
[ https://issues.apache.org/jira/browse/IO-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17286827#comment-17286827 ] Jin Xu edited comment on IO-670 at 2/19/21, 2:46 AM: - [~ggregory] Please review this pr again. I rebased. Thanks. There still be some things in this pr. was (Author: xenoamess): [~ggregory] Please review this pr again. I rebased. Thanks. > IOUtils.contentEquals is of low performance. I will refine it. > -- > > Key: IO-670 > URL: https://issues.apache.org/jira/browse/IO-670 > Project: Commons IO > Issue Type: Improvement >Reporter: Jin Xu >Priority: Critical > Attachments: jmh-result.org.apache.json > > Time Spent: 14h 40m > Remaining Estimate: 0h > > [https://github.com/apache/commons-io/pull/118] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IO-670) IOUtils.contentEquals is of low performance. I will refine it.
[ https://issues.apache.org/jira/browse/IO-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17286827#comment-17286827 ] Jin Xu commented on IO-670: --- [~ggregory] Please review this pr again. I rebased. Thanks. > IOUtils.contentEquals is of low performance. I will refine it. > -- > > Key: IO-670 > URL: https://issues.apache.org/jira/browse/IO-670 > Project: Commons IO > Issue Type: Improvement >Reporter: Jin Xu >Priority: Critical > Attachments: jmh-result.org.apache.json > > Time Spent: 14h 40m > Remaining Estimate: 0h > > [https://github.com/apache/commons-io/pull/118] -- This message was sent by Atlassian Jira (v8.3.4#803005)
