[jira] [Updated] (LANG-1328) FastDateFormat does not support 'EEE' and 'MMM' abbreviations for PT_pt
[
https://issues.apache.org/jira/browse/LANG-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated LANG-1328:
-
Attachment: android.png
oracle.png
> FastDateFormat does not support 'EEE' and 'MMM' abbreviations for PT_pt
> ---
>
> Key: LANG-1328
> URL: https://issues.apache.org/jira/browse/LANG-1328
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.3.2
> Environment: Android
>Reporter: Pär Nils Amsen
> Attachments: android.png, oracle.png
>
>
> For the following statement:
> {code:java}
> FastDateFormat.getInstance("MMM", timeZone, new Locale("pt",
> "pt")).format(1494115200);
> {code}
> The outcome will be "dormingo" instead of "dor" in Portugese (pt_PT). I
> expect this to be a bug since the only reason for FastDateFormat to not
> abbreviate the weekdays would be that Portugese does not allow it, not very
> likely.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LANG-1328) FastDateFormat does not support 'EEE' and 'MMM' abbreviations for PT_pt
[
https://issues.apache.org/jira/browse/LANG-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999233#comment-15999233
]
Bruno P. Kinoshita commented on LANG-1328:
--
Hello,
Downloaded Android Studio (latest version), added Commons Lang 3.5 via Gradle,
added your code minus the Android specific line, and then put a breakpoint to
see what's happening.
In my case, I'm getting for pt_PT domingo for the EEE mask. Same code in Oracle
JVM gives me dom for EEE. I'm guessing the extra R that appears for you is a
typo? Or are you really seeing Dor and Dormingo? Dormingo does not exist in
Portuguese (except as a slang, recently created).
Debugging, I could see that my Oracle JDK was using a ResourceBundle to load
the Locale specific strings, while in Android, it was using ICU (import
libcore.icu.LocaleData). Attaching some images from my IDE's with breakpoints
around where I think the code differs.
I tried reproducing the issue with Oracle JDK + ICU here
https://github.com/kinow/commons-sandbox/blob/master/src/main/java/br/eti/kinoshita/commons/LangDateTests.java,
but I still get Dom for Oracle JDK, and dom with IBM ICU4J (tried recent
versions, and the oldest I tried was 4.0.1).
I wonder if the following excerpt from Google's libcore helps:
{quote}
From:
https://android.googlesource.com/platform/libcore/+/5d930ca/luni/src/main/java/java/util/Locale.java
*
Note that locale data is not necessarily available for any of the locales
pre-defined as
* constants in this class except for en_US, which is the only locale Java
guarantees is always
* available.
*
* It is also a mistake to assume that all devices have the same locales
available.
* A device sold in the US will almost certainly support en_US and es_US, but
not necessarily
* any locales with the same language but different countries (such as en_GB or
es_ES),
* nor any locales for other languages (such as de_DE). The opposite may well
be true for a device
* sold in Europe.
Versions of ICU:
* Here are the versions of ICU (and the corresponding CLDR and Unicode
versions) used in
* various Android releases:
*
* Android 1.5 (Cupcake)/Android 1.6 (Donut)/Android 2.0 (Eclair)
* ICU 3.8
* http://cldr.unicode.org/index/downloads/cldr-1-5;>CLDR
1.5
* http://www.unicode.org/versions/Unicode5.0.0/;>Unicode
5.0
* Android 2.2 (Froyo)
* ICU 4.2
* http://cldr.unicode.org/index/downloads/cldr-1-7;>CLDR
1.7
* http://www.unicode.org/versions/Unicode5.1.0/;>Unicode
5.1
* Android 2.3 (Gingerbread)/Android 3.0 (Honeycomb)
* ICU 4.4
* http://cldr.unicode.org/index/downloads/cldr-1-8;>CLDR
1.8
* http://www.unicode.org/versions/Unicode5.2.0/;>Unicode
5.2
* Android 4.0 (Ice Cream Sandwich)
* http://site.icu-project.org/download/46;>ICU 4.6
* http://cldr.unicode.org/index/downloads/cldr-1-9;>CLDR
1.9
* http://www.unicode.org/versions/Unicode6.0.0/;>Unicode
6.0
* Android 4.1 (Jelly Bean)
* http://site.icu-project.org/download/48;>ICU 4.8
* http://cldr.unicode.org/index/downloads/cldr-2-0;>CLDR
2.0
* http://www.unicode.org/versions/Unicode6.0.0/;>Unicode
6.0
* Android 4.3 (Jelly Bean MR2)
* http://site.icu-project.org/download/50;>ICU 50
* http://cldr.unicode.org/index/downloads/cldr-22-1;>CLDR
22.1
* http://www.unicode.org/versions/Unicode6.2.0/;>Unicode
6.2
* Android 4.4 (KitKat)
* http://site.icu-project.org/download/51;>ICU 51
* http://cldr.unicode.org/index/downloads/cldr-23;>CLDR
23
* http://www.unicode.org/versions/Unicode6.2.0/;>Unicode
6.2
* Android 4.? (STOPSHIP)
* http://site.icu-project.org/download/53;>ICU 53
* http://cldr.unicode.org/index/downloads/cldr-25;>CLDR
25
* http://www.unicode.org/versions/Unicode6.3.0/;>Unicode
6.3
*
{quote}
Before trying anything, it would be helpful to have some code
[~par.nils.am...@gmail.com]. Code that can be imported into an IDE, as well as
detailed instructions to reproduce the issue. Then someone would need to dig a
bit deeper than I did, and understand why the differences for the abbreviated
week day name.
I don't see what could be done in [lang], and believe we will be able to find
something missing in Android/libcore/icu for pt_PT, and then users will simply
need to update their dependencies, without any change here in [lang].
> FastDateFormat does not support 'EEE' and 'MMM' abbreviations for PT_pt
> ---
>
> Key: LANG-1328
> URL: https://issues.apache.org/jira/browse/LANG-1328
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.3.2
> Environment: Android
>Reporter: Pär Nils Amsen
> Attachments: android.png, oracle.png
>
>
> For the following statement:
> {code:java}
> FastDateFormat.getInstance("MMM",
[jira] [Commented] (MATH-1233) Uncommon wilcoxon signed-rank p-values
[ https://issues.apache.org/jira/browse/MATH-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999117#comment-15999117 ] Icaro Cavalcante Dourado commented on MATH-1233: one suggestion is to just to copy the code from scipy, including the tests, then port it to java. > Uncommon wilcoxon signed-rank p-values > -- > > Key: MATH-1233 > URL: https://issues.apache.org/jira/browse/MATH-1233 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Icaro Cavalcante Dourado >Assignee: Rob Tompkins > Fix For: 4.0 > > Attachments: MATH-1233-test.patch > > > This implementation in WilcoxonSignedRankTest looks weird. For equal vectors, > the correct pValue should be 1, because it is the probability of the vectors > to come from same population. > On the opposite, this implementation returns ~0 for equal vectors. So we need > to analyze the returned pValue > significanceLevel to reject H0 hypothesis, > while in R and many others tools we perform the opposite: pValue <= > significanceLevel gives us an argument to reject null hypothesis. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MATH-1233) Uncommon wilcoxon signed-rank p-values
[ https://issues.apache.org/jira/browse/MATH-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999073#comment-15999073 ] Gilles commented on MATH-1233: -- Was it the case too with the last official release (v3.6.1)? > Uncommon wilcoxon signed-rank p-values > -- > > Key: MATH-1233 > URL: https://issues.apache.org/jira/browse/MATH-1233 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Icaro Cavalcante Dourado >Assignee: Rob Tompkins > Fix For: 4.0 > > Attachments: MATH-1233-test.patch > > > This implementation in WilcoxonSignedRankTest looks weird. For equal vectors, > the correct pValue should be 1, because it is the probability of the vectors > to come from same population. > On the opposite, this implementation returns ~0 for equal vectors. So we need > to analyze the returned pValue > significanceLevel to reject H0 hypothesis, > while in R and many others tools we perform the opposite: pValue <= > significanceLevel gives us an argument to reject null hypothesis. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TEXT-39) WordUtils should use toXxxxCase(int) rather than toXxxxCase(char)
[ https://issues.apache.org/jira/browse/TEXT-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998903#comment-15998903 ] Amey Jadiye commented on TEXT-39: - [~pascalschumacher], I have submitted PR please verify https://github.com/apache/commons-text/pull/39 > WordUtils should use toXxxxCase(int) rather than toXxxxCase(char) > - > > Key: TEXT-39 > URL: https://issues.apache.org/jira/browse/TEXT-39 > Project: Commons Text > Issue Type: Improvement >Reporter: Sebb > Fix For: 1.1 > > > The Javadoc for Character#toTitleCase(char) recommends using > Character#toTitleCase(int) instead. This method was added in Java 1.5 which > is perhaps is why it was not used originally; maybe we should use it now. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IO-535) Thread bug in FileAlterationMonitor
[
https://issues.apache.org/jira/browse/IO-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony RAYMOND updated IO-535:
---
External issue URL: https://github.com/apache/commons-io/pull/36 (was:
https://github.com/apache/commons-io/pulls)
> Thread bug in FileAlterationMonitor
> ---
>
> Key: IO-535
> URL: https://issues.apache.org/jira/browse/IO-535
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.5
> Environment: Components managed by a DI Framework
>Reporter: Anthony RAYMOND
>Priority: Critical
> Labels: easyfix, patch, performance
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> The thread in FileAlterationMonitor wasn't stopped by the `stop(int)` method,
> which forbid application to shutdown until all `Thread` are exited (if
> FileAlterationMonitor is part of a DI managed component).
> This behavior conflict with the method javadoc `@param stopInterval the
> amount of time in milliseconds to wait for the thread to finish.`
> h5. Simple example to understand
> Bad behavior
> {code:java}
> Thread t = new Thread(() -> {
> try {
> Thread.sleep(50);
> } catch (final InterruptedException e) {
> }
> });
> t.start();
> t.join(50);
>// Ok, we reach this point until 50ms are elapsed, but the thread is
> still alive.
>// because Thread#join(int) does not kill the thread. And the thread
> remains alive.
> {code}
> Good behavior
> {code:java}
> Thread t = new Thread(() -> {
> try {
> Thread.sleep(50);
> } catch (final InterruptedException e) {
> }
> });
> t.start();
> t.join(50);
> t.interupt();
>// Thread is exited
> {code}
> In this case, we waited the given time BEFORE exiting the `Thread`, as
> described in the javadoc, and the `Thread` is now finished and killed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (MATH-1233) Uncommon wilcoxon signed-rank p-values
[ https://issues.apache.org/jira/browse/MATH-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998725#comment-15998725 ] Rob Tompkins edited comment on MATH-1233 at 5/5/17 6:25 PM: When we consider scipy, our results don't even match up with theirs on the same input, generally. This somewhat concerns me that our algorithm is generally not correct. was (Author: chtompki): When we consider scipy, our results don't even match up with theirs on the same input. This somewhat concerns me that our algorithm is generally not correct. > Uncommon wilcoxon signed-rank p-values > -- > > Key: MATH-1233 > URL: https://issues.apache.org/jira/browse/MATH-1233 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Icaro Cavalcante Dourado >Assignee: Rob Tompkins > Fix For: 4.0 > > Attachments: MATH-1233-test.patch > > > This implementation in WilcoxonSignedRankTest looks weird. For equal vectors, > the correct pValue should be 1, because it is the probability of the vectors > to come from same population. > On the opposite, this implementation returns ~0 for equal vectors. So we need > to analyze the returned pValue > significanceLevel to reject H0 hypothesis, > while in R and many others tools we perform the opposite: pValue <= > significanceLevel gives us an argument to reject null hypothesis. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MATH-1233) Uncommon wilcoxon signed-rank p-values
[ https://issues.apache.org/jira/browse/MATH-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998725#comment-15998725 ] Rob Tompkins commented on MATH-1233: When we consider scipy, our results don't even match up with theirs on the same input. This somewhat concerns me that our algorithm is generally not correct. > Uncommon wilcoxon signed-rank p-values > -- > > Key: MATH-1233 > URL: https://issues.apache.org/jira/browse/MATH-1233 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Icaro Cavalcante Dourado >Assignee: Rob Tompkins > Fix For: 4.0 > > Attachments: MATH-1233-test.patch > > > This implementation in WilcoxonSignedRankTest looks weird. For equal vectors, > the correct pValue should be 1, because it is the probability of the vectors > to come from same population. > On the opposite, this implementation returns ~0 for equal vectors. So we need > to analyze the returned pValue > significanceLevel to reject H0 hypothesis, > while in R and many others tools we perform the opposite: pValue <= > significanceLevel gives us an argument to reject null hypothesis. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (JCS-177) CompositeCacheManager leaks memory if CacheAccess.dipose is called
[ https://issues.apache.org/jira/browse/JCS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15997018#comment-15997018 ] Ryan Fong edited comment on JCS-177 at 5/5/17 3:51 PM: --- I have attached one possible solution that should fix this problem as jcs-177.patch. An alternative to this is to have a pointer from CompositeCache to CompositeCacheManager so we do not incur the overhead of incrementing and decrementing the client count. Also find an Eclipse project that uses stock 2.1 to demonstrate how the leak occurs and how CompositeCacheManager.freeCache avoids this issue. Update: I just discovered that auxiliaryCaches is leaking as well. I have updated the patch and test with a suggestion but did not compile it. was (Author: rpmcfong): I have attached one possible solution that should fix this problem as jcs-177.patch. An alternative to this is to have a pointer from CompositeCache to CompositeCacheManager so we do not incur the overhead of incrementing and decrementing the client count. Also find an Eclipse project that uses stock 2.1 to demonstrate how the leak occurs and how CompositeCacheManager.freeCache avoids this issue. Update: I just discovered that auxiliaryCaches is leaking as well. I can update the files later with an updated suggestion. > CompositeCacheManager leaks memory if CacheAccess.dipose is called > -- > > Key: JCS-177 > URL: https://issues.apache.org/jira/browse/JCS-177 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache >Affects Versions: jcs-2.1 >Reporter: Ryan Fong >Priority: Critical > Attachments: jcs-177.patch, jcs-test.zip > > > In JCS 2.1, The org.apache.commons.jcs.engine.control.CompositeCacheManager > holds onto a reference of CacheAccess in its caches map. If > CacheAccess.dispose is called, this reference is not cleaned up which results > in a memory leak. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (JCS-177) CompositeCacheManager leaks memory if CacheAccess.dipose is called
[ https://issues.apache.org/jira/browse/JCS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Fong updated JCS-177: -- Attachment: (was: jcs-177.patch) > CompositeCacheManager leaks memory if CacheAccess.dipose is called > -- > > Key: JCS-177 > URL: https://issues.apache.org/jira/browse/JCS-177 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache >Affects Versions: jcs-2.1 >Reporter: Ryan Fong >Priority: Critical > Attachments: jcs-177.patch, jcs-test.zip > > > In JCS 2.1, The org.apache.commons.jcs.engine.control.CompositeCacheManager > holds onto a reference of CacheAccess in its caches map. If > CacheAccess.dispose is called, this reference is not cleaned up which results > in a memory leak. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (JCS-177) CompositeCacheManager leaks memory if CacheAccess.dipose is called
[ https://issues.apache.org/jira/browse/JCS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Fong updated JCS-177: -- Component/s: Composite Cache > CompositeCacheManager leaks memory if CacheAccess.dipose is called > -- > > Key: JCS-177 > URL: https://issues.apache.org/jira/browse/JCS-177 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache >Affects Versions: jcs-2.1 >Reporter: Ryan Fong >Priority: Critical > Attachments: jcs-177.patch, jcs-test.zip > > > In JCS 2.1, The org.apache.commons.jcs.engine.control.CompositeCacheManager > holds onto a reference of CacheAccess in its caches map. If > CacheAccess.dispose is called, this reference is not cleaned up which results > in a memory leak. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (JCS-177) CompositeCacheManager leaks memory if CacheAccess.dipose is called
[ https://issues.apache.org/jira/browse/JCS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Fong updated JCS-177: -- Attachment: (was: jcs-test.zip) > CompositeCacheManager leaks memory if CacheAccess.dipose is called > -- > > Key: JCS-177 > URL: https://issues.apache.org/jira/browse/JCS-177 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache >Affects Versions: jcs-2.1 >Reporter: Ryan Fong >Priority: Critical > Attachments: jcs-177.patch, jcs-test.zip > > > In JCS 2.1, The org.apache.commons.jcs.engine.control.CompositeCacheManager > holds onto a reference of CacheAccess in its caches map. If > CacheAccess.dispose is called, this reference is not cleaned up which results > in a memory leak. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (JCS-177) CompositeCacheManager leaks memory if CacheAccess.dipose is called
[ https://issues.apache.org/jira/browse/JCS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Fong updated JCS-177: -- Attachment: jcs-test.zip jcs-177.patch > CompositeCacheManager leaks memory if CacheAccess.dipose is called > -- > > Key: JCS-177 > URL: https://issues.apache.org/jira/browse/JCS-177 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache >Affects Versions: jcs-2.1 >Reporter: Ryan Fong >Priority: Critical > Attachments: jcs-177.patch, jcs-test.zip > > > In JCS 2.1, The org.apache.commons.jcs.engine.control.CompositeCacheManager > holds onto a reference of CacheAccess in its caches map. If > CacheAccess.dispose is called, this reference is not cleaned up which results > in a memory leak. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (COMPRESS-391) Zip entries alignment
[ https://issues.apache.org/jira/browse/COMPRESS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998420#comment-15998420 ] ASF GitHub Bot commented on COMPRESS-391: - Github user bodewig commented on the issue: https://github.com/apache/commons-compress/pull/24 I don't see a chance of making it independent of `ZipArchiveOutputStream`, you are certainly correct. I was thinking along the lines of `ZipArchiveOutputStream` calculates the length needed for proper alignment, creates an instance of the new extra field passing in the size information necessary and adds it to the `ZipArchiveEntry` - after that the code in `ZipArchiveOutputStream` can be left unchanged. > Zip entries alignment > - > > Key: COMPRESS-391 > URL: https://issues.apache.org/jira/browse/COMPRESS-391 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Affects Versions: 1.13 >Reporter: Zbynek Vyskovsky > Labels: features, github-import, patch > Fix For: 1.14 > > > Similarly to COMPRESS-390, there are requirements of the zip content to be > mapped directly into memory and therefore may require special alignment on > the embedded files. E.g. libraries may be aligned to page (4096-bytes) > boundary, images on 4-bytes boundary etc. By alignment it's meant the offset > from the beginning of file where the actual data stream starts, not the > header. > One of the cases was (still is?) Android APK for which zipalign utility was > created. > It would be useful if commons-compress ZipArchiveOutputStream supports > something similar directly in its API. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (COMPRESS-391) Zip entries alignment
[ https://issues.apache.org/jira/browse/COMPRESS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998399#comment-15998399 ] ASF GitHub Bot commented on COMPRESS-391: - Github user kvr000 commented on the issue: https://github.com/apache/commons-compress/pull/24 @bodewig : Thanks for suggestions. There are definitely some pros with the approach, especially if it reaches Zip RFC :-) On the other hand, I don't think it could be made completely independent on ZipArchiveOutputStream as it has to know current stream offset on which to base the alignment. But I'll check in details... > Zip entries alignment > - > > Key: COMPRESS-391 > URL: https://issues.apache.org/jira/browse/COMPRESS-391 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Affects Versions: 1.13 >Reporter: Zbynek Vyskovsky > Labels: features, github-import, patch > Fix For: 1.14 > > > Similarly to COMPRESS-390, there are requirements of the zip content to be > mapped directly into memory and therefore may require special alignment on > the embedded files. E.g. libraries may be aligned to page (4096-bytes) > boundary, images on 4-bytes boundary etc. By alignment it's meant the offset > from the beginning of file where the actual data stream starts, not the > header. > One of the cases was (still is?) Android APK for which zipalign utility was > created. > It would be useful if commons-compress ZipArchiveOutputStream supports > something similar directly in its API. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (FILEUPLOAD-281) If Content-disposition is missing entirely, then file upload parts are missing
[ https://issues.apache.org/jira/browse/FILEUPLOAD-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Wallace updated FILEUPLOAD-281: Attachment: missingDisposition.patch > If Content-disposition is missing entirely, then file upload parts are missing > -- > > Key: FILEUPLOAD-281 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-281 > Project: Commons FileUpload > Issue Type: Improvement >Affects Versions: 1.3.2 >Reporter: Bill Wallace > Attachments: missingDisposition.patch > > > If the Content-disposition is missing entirely, then part is generated for > the upload. For some web standards, that is undesirable as the content > disposition isn't mandatory for those file uploads (particularly in this case > the IHE Dicom Web STOW-RS standard), and that prevents parsing such uploads > with this library. > The patch attached does not affect the other unit tests and should not > interact with more standards compatible file uploads. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (FILEUPLOAD-281) If Content-disposition is missing entirely, then file upload parts are missing
Bill Wallace created FILEUPLOAD-281: --- Summary: If Content-disposition is missing entirely, then file upload parts are missing Key: FILEUPLOAD-281 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-281 Project: Commons FileUpload Issue Type: Improvement Affects Versions: 1.3.2 Reporter: Bill Wallace If the Content-disposition is missing entirely, then part is generated for the upload. For some web standards, that is undesirable as the content disposition isn't mandatory for those file uploads (particularly in this case the IHE Dicom Web STOW-RS standard), and that prevents parsing such uploads with this library. The patch attached does not affect the other unit tests and should not interact with more standards compatible file uploads. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1233) Uncommon wilcoxon signed-rank p-values
[ https://issues.apache.org/jira/browse/MATH-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1233: --- Assignee: Rob Tompkins > Uncommon wilcoxon signed-rank p-values > -- > > Key: MATH-1233 > URL: https://issues.apache.org/jira/browse/MATH-1233 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Icaro Cavalcante Dourado >Assignee: Rob Tompkins > Fix For: 4.0 > > Attachments: MATH-1233-test.patch > > > This implementation in WilcoxonSignedRankTest looks weird. For equal vectors, > the correct pValue should be 1, because it is the probability of the vectors > to come from same population. > On the opposite, this implementation returns ~0 for equal vectors. So we need > to analyze the returned pValue > significanceLevel to reject H0 hypothesis, > while in R and many others tools we perform the opposite: pValue <= > significanceLevel gives us an argument to reject null hypothesis. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (COMPRESS-391) Zip entries alignment
[ https://issues.apache.org/jira/browse/COMPRESS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15997998#comment-15997998 ] ASF GitHub Bot commented on COMPRESS-391: - Github user bodewig commented on the issue: https://github.com/apache/commons-compress/pull/24 Many thanks @kvr000 Have you thought about adding a class implementing `ZipExtraField` for padding? You could add that to the entry if you detect padding is necessary and could remove code that now needs to know about the encoding of extra fields from `ZipArchiveOutputStream`. The central directory size should be 0 then. It would also preserve the padding information when an archive is read which may be useful when re-packing existing entries as you could strip or modify the padding extra field directly. Finally I wonder whether `setAlignment` should reject values bigger than 64k right away. > Zip entries alignment > - > > Key: COMPRESS-391 > URL: https://issues.apache.org/jira/browse/COMPRESS-391 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Affects Versions: 1.13 >Reporter: Zbynek Vyskovsky > Labels: features, github-import, patch > Fix For: 1.14 > > > Similarly to COMPRESS-390, there are requirements of the zip content to be > mapped directly into memory and therefore may require special alignment on > the embedded files. E.g. libraries may be aligned to page (4096-bytes) > boundary, images on 4-bytes boundary etc. By alignment it's meant the offset > from the beginning of file where the actual data stream starts, not the > header. > One of the cases was (still is?) Android APK for which zipalign utility was > created. > It would be useful if commons-compress ZipArchiveOutputStream supports > something similar directly in its API. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (NUMBERS-33) Move code from "Gamma" class
Gilles created NUMBERS-33:
-
Summary: Move code from "Gamma" class
Key: NUMBERS-33
URL: https://issues.apache.org/jira/browse/NUMBERS-33
Project: Commons Numbers
Issue Type: Task
Reporter: Gilles
Assignee: Gilles
Priority: Minor
Fix For: 1.0
I propose to create a new {{commons-numbers-gamma}} module to contain the
implementations of
[Gamma|http://mathworld.wolfram.com/GammaFunction.html]-related functions
currently in "Commons Math" (in package {{o.a.c.math4.special}}).
It would also contain the {{factorial}} implementation currently in class
{{o.a.c.math4.util.CombinatoricsUtils}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
