[jira] [Commented] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15013031#comment-15013031 ] Emmanuel Bourg commented on IO-487: --- The name isn't included on purpose to avoid disclosing too much information to an attacker. That said, we could display the name only when a debug mode is enabled. > ValidatingObjectInputStream contribution - restrict which classes can be > deserialized > - > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487-2.patch, IO-487-accept-reject-2.patch, > IO-487-accept-reject.patch, IO-487-matchers.patch, > IO-487-name-regex-acceptor.patch, IO-487.patch, IO-487.patch, IO-487.patch, > IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15012958#comment-15012958
]
Naozumi Taromaru commented on COLLECTIONS-580:
--
I used commons-collections-3.2.2.
ForClosure and WhileClosure can not deserialize.
But, ChainedTransformer can deserialize.
A DoS attack similar to an infinite loop becomes possible by the following way.
{code:java}
HashMap map = new HashMap();
for (int i = Integer.MIN_VALUE + 1; i <= Integer.MIN_VALUE + 10; i++) {
map.put(i, i);
}
Transformer constantTransformer = ConstantTransformer.getInstance(map);
Transformer stringValueTransformer =
StringValueTransformer.getInstance();
Transformer transformerChain =
ChainedTransformer.getInstance(constantTransformer, stringValueTransformer);
for (int i = 0; i < 10; i++) {
Transformer[] transformers = new Transformer[10];
Arrays.fill(transformers, transformerChain);
transformerChain = ChainedTransformer.getInstance(transformers);
}
{code}
This serialized file size is less than 2KB.
But it takes 6~7 hours for deserialize. (Core i5 CPU)
I think the similar way is also possible in ChainedClosure, AllPredicate,
AnyPredicate.
When other class of org.apache.commons.collections.functors package was used,
it was possible to make OutOfMemoryError occur.
I think all classes of org.apache.commons.collections.functors package should
call FunctorUtils#checkUnsafeSerialization.
> Arbitrary remote code execution with InvokerTransformer
> ---
>
> Key: COLLECTIONS-580
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-580
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 3.0, 4.0
>Reporter: Philippe Marschall
> Fix For: 3.2.2, 4.1
>
> Attachments: COLLECTIONS-580.patch
>
>
> With {{InvokerTransformer}} serializable collections can be build that
> execute arbitrary Java code.
> {{sun.reflect.annotation.AnnotationInvocationHandler#readObject}} invokes
> {{#entrySet}} and {{#get}} on a deserialized collection. If you have an
> endpoint that accepts serialized Java objects (JMX, RMI, remote EJB, ...) you
> can combine the two to create arbitrary remote code execution vulnerability.
> I don't know of a good fix short of removing {{InvokerTransformer}} or making
> it not Serializable. Both probably break existing applications.
> This is not my research, but has been discovered by other people.
> https://github.com/frohoff/ysoserial
> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1293) Tabulating the logarithmic factorial
[ https://issues.apache.org/jira/browse/MATH-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15012486#comment-15012486 ] Gilles commented on MATH-1293: -- Did you subscribe? http://commons.apache.org/proper/commons-math/mail-lists.html > Tabulating the logarithmic factorial > > > Key: MATH-1293 > URL: https://issues.apache.org/jira/browse/MATH-1293 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.5 >Reporter: Aleksei Dievskii >Priority: Minor > Labels: feature, patch > Attachments: factlog.patch > > > Presently, CombinatoricsUtils#factorialLog is calculated via a tabulated > value for the first 21 entries, and for the rest it employs linear-complexity > direct summing. For the factorial-heavy computations this can be rather > painful. I propose a patch which allocates additional 16KB of tabulated > log-factorial values, allowing very fast (constant complexity) computation > for arguments up to 17000, and delegating to the log-gamma for the rest. > Benchmarks show a speed-up of up to 200x. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (VALIDATOR-364) Email Validator does not support quoted/escaped character in the local part of the email address
[
https://issues.apache.org/jira/browse/VALIDATOR-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved VALIDATOR-364.
Resolution: Fixed
URL: http://svn.apache.org/viewvc?rev=1715076&view=rev
Log:
VALIDATOR-382 duplicates VALIDATOR-353
Modified:
commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/UrlValidatorTest.java
> Email Validator does not support quoted/escaped character in the local part
> of the email address
>
>
> Key: VALIDATOR-364
> URL: https://issues.apache.org/jira/browse/VALIDATOR-364
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
>Affects Versions: 1.4.1 Release
>Reporter: teo bran
> Attachments: VALIDATOR-364.patch
>
>
> Currently the email address validator doesn't support to quote (or escape) a
> character in the local part of the address.
> Examples:
> {noformat}
> Abc\@d...@example.com
> Fred\ blo...@example.com
> Joe.\\b...@example.com
> {noformat}
> Source: [RFC 3696 | http://tools.ietf.org/html/rfc3696#section-3]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (VALIDATOR-382) URL validator returns false to FTP url with username and password
[ https://issues.apache.org/jira/browse/VALIDATOR-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved VALIDATOR-382. Resolution: Duplicate > URL validator returns false to FTP url with username and password > - > > Key: VALIDATOR-382 > URL: https://issues.apache.org/jira/browse/VALIDATOR-382 > Project: Commons Validator > Issue Type: Bug > Components: Routines >Affects Versions: 1.4.1 Release >Reporter: Ofer Bachner > > The following ftp address is a valid ftp url, but the url validator returns > false. > ftp://username:passw...@example.com:8042/over/there/index.dtb?type=animal&name=narwhal#nose -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized
[
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15012207#comment-15012207
]
Niall Pemberton commented on IO-487:
Go for it - looks good to me, the only minor comment I have is, can you include
the className in the exception message:
{{throw new InvalidClassException("Class '" + className + "' not accepted");}}
> ValidatingObjectInputStream contribution - restrict which classes can be
> deserialized
> -
>
> Key: IO-487
> URL: https://issues.apache.org/jira/browse/IO-487
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 2.4
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Labels: patch
> Fix For: 2.5
>
> Attachments: IO-487-2.patch, IO-487-accept-reject-2.patch,
> IO-487-accept-reject.patch, IO-487-matchers.patch,
> IO-487-name-regex-acceptor.patch, IO-487.patch, IO-487.patch, IO-487.patch,
> IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch
>
>
> As discussed on the commons dev list I'd like to contribute my SLING-5288
> code to commons-io. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011647#comment-15011647 ] Bertrand Delacretaz commented on IO-487: at least you spelled it right, that's no so common ;-) > ValidatingObjectInputStream contribution - restrict which classes can be > deserialized > - > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487-2.patch, IO-487-accept-reject-2.patch, > IO-487-accept-reject.patch, IO-487-matchers.patch, > IO-487-name-regex-acceptor.patch, IO-487.patch, IO-487.patch, IO-487.patch, > IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized
[
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011623#comment-15011623
]
Gary Gregory commented on IO-487:
-
This is also {{DelacretazObjectInputStream}} ... ;-)
> ValidatingObjectInputStream contribution - restrict which classes can be
> deserialized
> -
>
> Key: IO-487
> URL: https://issues.apache.org/jira/browse/IO-487
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 2.4
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Labels: patch
> Fix For: 2.5
>
> Attachments: IO-487-2.patch, IO-487-accept-reject-2.patch,
> IO-487-accept-reject.patch, IO-487-matchers.patch,
> IO-487-name-regex-acceptor.patch, IO-487.patch, IO-487.patch, IO-487.patch,
> IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch
>
>
> As discussed on the commons dev list I'd like to contribute my SLING-5288
> code to commons-io. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011611#comment-15011611 ] Bertrand Delacretaz commented on IO-487: RestrictedObjectInputStream maybe, but ValidatingObjectInputStream works for me. > ValidatingObjectInputStream contribution - restrict which classes can be > deserialized > - > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487-2.patch, IO-487-accept-reject-2.patch, > IO-487-accept-reject.patch, IO-487-matchers.patch, > IO-487-name-regex-acceptor.patch, IO-487.patch, IO-487.patch, IO-487.patch, > IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011403#comment-15011403 ] Christopher Schultz commented on IO-487: I would suggest Filter[ing]ObjectInputStream, except it doesn't actually /filter/... it merely ... objects to things. RestrictingObjectInputStream? VetoingObjectInputStream? SentinelObjectInputStream? PrudishObjectInputStream? > ValidatingObjectInputStream contribution - restrict which classes can be > deserialized > - > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487-2.patch, IO-487-accept-reject-2.patch, > IO-487-accept-reject.patch, IO-487-matchers.patch, > IO-487-name-regex-acceptor.patch, IO-487.patch, IO-487.patch, IO-487.patch, > IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized
[
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011354#comment-15011354
]
Gary Gregory commented on IO-487:
-
I like {{ValidatingObjectInputStream}} for the name.
> ValidatingObjectInputStream contribution - restrict which classes can be
> deserialized
> -
>
> Key: IO-487
> URL: https://issues.apache.org/jira/browse/IO-487
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 2.4
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Labels: patch
> Fix For: 2.5
>
> Attachments: IO-487-2.patch, IO-487-accept-reject-2.patch,
> IO-487-accept-reject.patch, IO-487-matchers.patch,
> IO-487-name-regex-acceptor.patch, IO-487.patch, IO-487.patch, IO-487.patch,
> IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch
>
>
> As discussed on the commons dev list I'd like to contribute my SLING-5288
> code to commons-io. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011332#comment-15011332 ] Bertrand Delacretaz commented on IO-487: bq. if nobody objects you can even do it yourself since the repository is open to all Apache committers. Ok, I'll wait about 24 hours in case there are objections. > ValidatingObjectInputStream contribution - restrict which classes can be > deserialized > - > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487-2.patch, IO-487-accept-reject-2.patch, > IO-487-accept-reject.patch, IO-487-matchers.patch, > IO-487-name-regex-acceptor.patch, IO-487.patch, IO-487.patch, IO-487.patch, > IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011319#comment-15011319 ] Emmanuel Bourg commented on IO-487: --- Its looks ready to be committed to me, and if nobody objects you can even do it yourself since the repository is open to all Apache committers. As for the name I don't know. SanitizingObjectInputStream maybe? SafeObjectInputStream wasn't that bad. > ValidatingObjectInputStream contribution - restrict which classes can be > deserialized > - > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487-2.patch, IO-487-accept-reject-2.patch, > IO-487-accept-reject.patch, IO-487-matchers.patch, > IO-487-name-regex-acceptor.patch, IO-487.patch, IO-487.patch, IO-487.patch, > IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1293) Tabulating the logarithmic factorial
[ https://issues.apache.org/jira/browse/MATH-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011295#comment-15011295 ] Aleksei Dievskii commented on MATH-1293: Thank you for your advice! However, I'm not exactly sure how to do this. I've sent an email to d...@commons.apache.org, but it hasn't shown up in the archive at https://mail-archives.apache.org/mod_mbox/commons-dev/201511.mbox/browser . Is it the wrong way to reach the mailing list? > Tabulating the logarithmic factorial > > > Key: MATH-1293 > URL: https://issues.apache.org/jira/browse/MATH-1293 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.5 >Reporter: Aleksei Dievskii >Priority: Minor > Labels: feature, patch > Attachments: factlog.patch > > > Presently, CombinatoricsUtils#factorialLog is calculated via a tabulated > value for the first 21 entries, and for the rest it employs linear-complexity > direct summing. For the factorial-heavy computations this can be rather > painful. I propose a patch which allocates additional 16KB of tabulated > log-factorial values, allowing very fast (constant complexity) computation > for arguments up to 17000, and delegating to the log-gamma for the rest. > Benchmarks show a speed-up of up to 200x. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated IO-487: --- Summary: ValidatingObjectInputStream contribution - restrict which classes can be deserialized (was: SafeObjectInputStream contribution - restrict which classes can be deserialized) > ValidatingObjectInputStream contribution - restrict which classes can be > deserialized > - > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487-2.patch, IO-487-accept-reject-2.patch, > IO-487-accept-reject.patch, IO-487-matchers.patch, > IO-487-name-regex-acceptor.patch, IO-487.patch, IO-487.patch, IO-487.patch, > IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated IO-487:
---
Attachment: IO-487-accept-reject-2.patch
Here's an updated {{IO-487-accept-reject-2.patch}} that adds a protected
{{invalidClassNameFound}} method to {{ValidatingObjectInputStream}}, as
suggested by [~ebourg]. That method could be overridden to log invalid classes
instead of failing, and it also includes the comment about not logging the
invalid class name.
Do you guys think this can be committed? I guess what's important is to agree
on the API-like elements which are only the {{ClassNameMatcher}} interface and
the public/protected methods of {{ValidatingObjectInputStream}}.
> SafeObjectInputStream contribution - restrict which classes can be
> deserialized
> ---
>
> Key: IO-487
> URL: https://issues.apache.org/jira/browse/IO-487
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 2.4
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Labels: patch
> Fix For: 2.5
>
> Attachments: IO-487-2.patch, IO-487-accept-reject-2.patch,
> IO-487-accept-reject.patch, IO-487-matchers.patch,
> IO-487-name-regex-acceptor.patch, IO-487.patch, IO-487.patch, IO-487.patch,
> IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch
>
>
> As discussed on the commons dev list I'd like to contribute my SLING-5288
> code to commons-io. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1293) Tabulating the logarithmic factorial
[
https://issues.apache.org/jira/browse/MATH-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011124#comment-15011124
]
Gilles commented on MATH-1293:
--
It's a step in the right direction but at this point, it's only my opinion.
You really should raise the issue on the "dev" ML to potentially get other
opinions on how the optimization must be integrated in future versions of CM.
For example, my idea was that the helper class do not need to bother with a
table fixed at compile time; the constructor of {{FastFactorialLog}} would
indeed initialize everything according to the caller's request (e.g. cache
size).
It would be the role of {{CombinatoricsUtils}} to decide how to instantiate a
{{FastFactorialLog}} object; and the policy (e.g. lazy instantiation at the
first call to {{factorialLog}} or in a _static_ block) must be discussed on the
"dev" ML.
Since we want to have more flexible interfaces, we might want to test
alternative design for those "small" utilities.
An idea would be to create a function object:
{code}
FastFactorialLog fact =
CombinatoricsUtils.createFactorialLog().withCacheSize(1024);
{code}
Then the caller could use the returned object:
{code}
double r = fact.value(123);
{code}
So a user won't depend on how we decided to implement the {{factorialLog}}
static function (and maybe the function should be deprecated if the same
functionality and more can be achieved in a better way).
There might be other suggestion of usability improvements or changes... So,
before you embark on yet another patch, you should really raise the issue on
the ML. Thanks!
> Tabulating the logarithmic factorial
>
>
> Key: MATH-1293
> URL: https://issues.apache.org/jira/browse/MATH-1293
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.5
>Reporter: Aleksei Dievskii
>Priority: Minor
> Labels: feature, patch
> Attachments: factlog.patch
>
>
> Presently, CombinatoricsUtils#factorialLog is calculated via a tabulated
> value for the first 21 entries, and for the rest it employs linear-complexity
> direct summing. For the factorial-heavy computations this can be rather
> painful. I propose a patch which allocates additional 16KB of tabulated
> log-factorial values, allowing very fast (constant complexity) computation
> for arguments up to 17000, and delegating to the log-gamma for the rest.
> Benchmarks show a speed-up of up to 200x.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1506#comment-1506
]
Tiago Stürmer Daitx commented on COLLECTIONS-580:
-
According to CVE assignment team [1] no CVE ID will be allocated for this issue
and:
"The CVE-2015-4852 ID came from Oracle and must remain associated only with
Oracle's own software (WebLogic Server is the product they've named)."
but then Oracle's Thomas Keefe reply [1] to that thread stated:
"We do not have a problem with this use of the CVE# we registered
(CVE-2015-4852)."
[1] http://www.openwall.com/lists/oss-security/2015/11/17/19
[2] http://www.openwall.com/lists/oss-security/2015/11/18/1
> Arbitrary remote code execution with InvokerTransformer
> ---
>
> Key: COLLECTIONS-580
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-580
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 3.0, 4.0
>Reporter: Philippe Marschall
> Fix For: 3.2.2, 4.1
>
> Attachments: COLLECTIONS-580.patch
>
>
> With {{InvokerTransformer}} serializable collections can be build that
> execute arbitrary Java code.
> {{sun.reflect.annotation.AnnotationInvocationHandler#readObject}} invokes
> {{#entrySet}} and {{#get}} on a deserialized collection. If you have an
> endpoint that accepts serialized Java objects (JMX, RMI, remote EJB, ...) you
> can combine the two to create arbitrary remote code execution vulnerability.
> I don't know of a good fix short of removing {{InvokerTransformer}} or making
> it not Serializable. Both probably break existing applications.
> This is not my research, but has been discovered by other people.
> https://github.com/frohoff/ysoserial
> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1236) Improve Kolmogorov-Smirnov statistic for two samples
[ https://issues.apache.org/jira/browse/MATH-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011043#comment-15011043 ] Christophe S commented on MATH-1236: Hi, Moreover it seems the patch fixes also the problem when we compare two identical distributions (with exactly the same arrays as input). Now the distance is 0, before it wasn't the case! Thx! > Improve Kolmogorov-Smirnov statistic for two samples > > > Key: MATH-1236 > URL: https://issues.apache.org/jira/browse/MATH-1236 > Project: Commons Math > Issue Type: Improvement >Reporter: Otmar Ertl > Fix For: 4.0, 3.6 > > Attachments: patch > > > I reimplemented the Kolmogorov-Smirnov test statistic for two samples because > of its problems with identical values. Although its already fixed in the > meantime (see MATH-1197), the proposed code is an improvement, because it is > simpler and does not require binary searches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMPRESS-327) Support in-memory processing for ZipFile
[ https://issues.apache.org/jira/browse/COMPRESS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011020#comment-15011020 ] Stefan Bodewig commented on COMPRESS-327: - We might be better off with discussing this on the dev list :-) [~damjan] I'll look into the patch soonish, but likely not before Sunday. There is no design doc for the 2.x branch, just a couple of mail threads to the dev list from late 2013, early 2014 (I think the first message I sent was http://mail-archives.apache.org/mod_mbox/commons-dev/201312.mbox/%3C877gbf4yyg.fsf%40v35516.1blu.de%3E > Support in-memory processing for ZipFile > > > Key: COMPRESS-327 > URL: https://issues.apache.org/jira/browse/COMPRESS-327 > Project: Commons Compress > Issue Type: New Feature >Reporter: Brett Kail >Priority: Minor > Attachments: seekable-input-stream.txt > > > ZipFile (and SevenZFile) currently require a File argument, but it would be > nice to support in-memory byte buffers rather than requiring temp files. > Perhaps create a new SeekableInputStream class (or SeekableDataInput > interface) and add corresponding constructors. > For convenience, perhaps also add a utility class that wraps a ByteBuffer > and/or byte[] and implements the new interface. > (The sevenz package appears to have a similar limitation, so it might make > sense to add the support there at the same time, but I personally don't have > a need for that.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1293) Tabulating the logarithmic factorial
[ https://issues.apache.org/jira/browse/MATH-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011000#comment-15011000 ] Aleksei Dievskii commented on MATH-1293: OK, I attached the new patch. > Tabulating the logarithmic factorial > > > Key: MATH-1293 > URL: https://issues.apache.org/jira/browse/MATH-1293 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.5 >Reporter: Aleksei Dievskii >Priority: Minor > Labels: feature, patch > Attachments: factlog.patch > > > Presently, CombinatoricsUtils#factorialLog is calculated via a tabulated > value for the first 21 entries, and for the rest it employs linear-complexity > direct summing. For the factorial-heavy computations this can be rather > painful. I propose a patch which allocates additional 16KB of tabulated > log-factorial values, allowing very fast (constant complexity) computation > for arguments up to 17000, and delegating to the log-gamma for the rest. > Benchmarks show a speed-up of up to 200x. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MATH-1293) Tabulating the logarithmic factorial
[ https://issues.apache.org/jira/browse/MATH-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Dievskii updated MATH-1293: --- Attachment: factlog.patch > Tabulating the logarithmic factorial > > > Key: MATH-1293 > URL: https://issues.apache.org/jira/browse/MATH-1293 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.5 >Reporter: Aleksei Dievskii >Priority: Minor > Labels: feature, patch > Attachments: factlog.patch > > > Presently, CombinatoricsUtils#factorialLog is calculated via a tabulated > value for the first 21 entries, and for the rest it employs linear-complexity > direct summing. For the factorial-heavy computations this can be rather > painful. I propose a patch which allocates additional 16KB of tabulated > log-factorial values, allowing very fast (constant complexity) computation > for arguments up to 17000, and delegating to the log-gamma for the rest. > Benchmarks show a speed-up of up to 200x. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MATH-1293) Tabulating the logarithmic factorial
[ https://issues.apache.org/jira/browse/MATH-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Dievskii updated MATH-1293: --- Attachment: (was: factlog.patch) > Tabulating the logarithmic factorial > > > Key: MATH-1293 > URL: https://issues.apache.org/jira/browse/MATH-1293 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.5 >Reporter: Aleksei Dievskii >Priority: Minor > Labels: feature, patch > > Presently, CombinatoricsUtils#factorialLog is calculated via a tabulated > value for the first 21 entries, and for the rest it employs linear-complexity > direct summing. For the factorial-heavy computations this can be rather > painful. I propose a patch which allocates additional 16KB of tabulated > log-factorial values, allowing very fast (constant complexity) computation > for arguments up to 17000, and delegating to the log-gamma for the rest. > Benchmarks show a speed-up of up to 200x. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1293) Tabulating the logarithmic factorial
[ https://issues.apache.org/jira/browse/MATH-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15010886#comment-15010886 ] Aleksei Dievskii commented on MATH-1293: This sounds simple! I will then attempt to make it so and attach a new patch. > Tabulating the logarithmic factorial > > > Key: MATH-1293 > URL: https://issues.apache.org/jira/browse/MATH-1293 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.5 >Reporter: Aleksei Dievskii >Priority: Minor > Labels: feature, patch > Attachments: factlog.patch > > > Presently, CombinatoricsUtils#factorialLog is calculated via a tabulated > value for the first 21 entries, and for the rest it employs linear-complexity > direct summing. For the factorial-heavy computations this can be rather > painful. I propose a patch which allocates additional 16KB of tabulated > log-factorial values, allowing very fast (constant complexity) computation > for arguments up to 17000, and delegating to the log-gamma for the rest. > Benchmarks show a speed-up of up to 200x. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JEXL-180) Documentation - suggests using float for financials
[ https://issues.apache.org/jira/browse/JEXL-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15010879#comment-15010879 ] Henri Biestro commented on JEXL-180: Michael, a BigDecimal is a Number and the example no longer gives a bad hint; it only supposes people know their field (like you). If you feel like it, you can contribute better documentation and examples to the project. The only caveat is that no-one feels like producing an official release so all this is anyway moot... > Documentation - suggests using float for financials > --- > > Key: JEXL-180 > URL: https://issues.apache.org/jira/browse/JEXL-180 > Project: Commons JEXL > Issue Type: Bug >Reporter: Kimball Robinson >Assignee: Henri Biestro > Fix For: 3.0 > > > The examples page: > https://commons.apache.org/proper/commons-jexl/reference/examples.html > Uses a Float type to represent dollar amounts. This is a bad idea--floating > point values are not large enough to represent larger transactions and this > could teach developers bad habits, especially in enterprise environments. > At the least you should use the Double class in your example. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JEXL-180) Documentation - suggests using float for financials
[
https://issues.apache.org/jira/browse/JEXL-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15010859#comment-15010859
]
Michael Osipov commented on JEXL-180:
-
Henri, using {{BigDecimal}} would be best practice with financials.
> Documentation - suggests using float for financials
> ---
>
> Key: JEXL-180
> URL: https://issues.apache.org/jira/browse/JEXL-180
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: Kimball Robinson
>Assignee: Henri Biestro
> Fix For: 3.0
>
>
> The examples page:
> https://commons.apache.org/proper/commons-jexl/reference/examples.html
> Uses a Float type to represent dollar amounts. This is a bad idea--floating
> point values are not large enough to represent larger transactions and this
> could teach developers bad habits, especially in enterprise environments.
> At the least you should use the Double class in your example.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1293) Tabulating the logarithmic factorial
[
https://issues.apache.org/jira/browse/MATH-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15010820#comment-15010820
]
Gilles commented on MATH-1293:
--
bq. create a package-local class
Yes (although actually I'd think it should be a "private" inner class).
Thus IMHO to be hopefully quite clear there could be
{code}
public class CombinatoricsUtils {
final FastFactorialLog FAST_FACTORIAL_LOG = new FastFactorialLog();
// ...
public static double factorialLog(final int n) {
return FAST_FACTORIAL_LOG.value(n);
}
// ...
private static class FastFactorialLog {
// Constants... No hard-coded numbers. ;-)
// ... Initialization
/** ... */
public double value(int n) {
// ...
}
}
}
{code}
But then, it will possible to consider parameterization of the utility class
(e.g. size of the precomputed table).
Also to be clarified is whether to always initialize this class, or use lazy
initialization. This has to be agreed on on the "dev" ML.
> Tabulating the logarithmic factorial
>
>
> Key: MATH-1293
> URL: https://issues.apache.org/jira/browse/MATH-1293
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.5
>Reporter: Aleksei Dievskii
>Priority: Minor
> Labels: feature, patch
> Attachments: factlog.patch
>
>
> Presently, CombinatoricsUtils#factorialLog is calculated via a tabulated
> value for the first 21 entries, and for the rest it employs linear-complexity
> direct summing. For the factorial-heavy computations this can be rather
> painful. I propose a patch which allocates additional 16KB of tabulated
> log-factorial values, allowing very fast (constant complexity) computation
> for arguments up to 17000, and delegating to the log-gamma for the rest.
> Benchmarks show a speed-up of up to 200x.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1293) Tabulating the logarithmic factorial
[ https://issues.apache.org/jira/browse/MATH-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15010789#comment-15010789 ] Aleksei Dievskii commented on MATH-1293: Gilles, thanks for your response. However, I don't quite understand what do you mean. Should I create a package-local class which would contain only the constants and the method to retrieve them (and extensive documentation, of course), and then make factorialLog delegate to that method? > Tabulating the logarithmic factorial > > > Key: MATH-1293 > URL: https://issues.apache.org/jira/browse/MATH-1293 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.5 >Reporter: Aleksei Dievskii >Priority: Minor > Labels: feature, patch > Attachments: factlog.patch > > > Presently, CombinatoricsUtils#factorialLog is calculated via a tabulated > value for the first 21 entries, and for the rest it employs linear-complexity > direct summing. For the factorial-heavy computations this can be rather > painful. I propose a patch which allocates additional 16KB of tabulated > log-factorial values, allowing very fast (constant complexity) computation > for arguments up to 17000, and delegating to the log-gamma for the rest. > Benchmarks show a speed-up of up to 200x. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JEXL-180) Documentation - suggests using float for financials
[ https://issues.apache.org/jira/browse/JEXL-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-180. Resolution: Fixed Example now uses a Number. > Documentation - suggests using float for financials > --- > > Key: JEXL-180 > URL: https://issues.apache.org/jira/browse/JEXL-180 > Project: Commons JEXL > Issue Type: Bug >Reporter: Kimball Robinson >Assignee: Henri Biestro > Fix For: 3.0 > > > The examples page: > https://commons.apache.org/proper/commons-jexl/reference/examples.html > Uses a Float type to represent dollar amounts. This is a bad idea--floating > point values are not large enough to represent larger transactions and this > could teach developers bad habits, especially in enterprise environments. > At the least you should use the Double class in your example. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JEXL-180) Documentation - suggests using float for financials
[ https://issues.apache.org/jira/browse/JEXL-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-180: --- Fix Version/s: 3.0 > Documentation - suggests using float for financials > --- > > Key: JEXL-180 > URL: https://issues.apache.org/jira/browse/JEXL-180 > Project: Commons JEXL > Issue Type: Bug >Reporter: Kimball Robinson > Fix For: 3.0 > > > The examples page: > https://commons.apache.org/proper/commons-jexl/reference/examples.html > Uses a Float type to represent dollar amounts. This is a bad idea--floating > point values are not large enough to represent larger transactions and this > could teach developers bad habits, especially in enterprise environments. > At the least you should use the Double class in your example. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1293) Tabulating the logarithmic factorial
[ https://issues.apache.org/jira/browse/MATH-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15010769#comment-15010769 ] Gilles commented on MATH-1293: -- Thanks for this proposal. However, for such contributions (that mainly aim at aggressive performance optimization), I'd suggest that a helper class be defined with extensive use of (fully documented) constant declarations. Future readers will be thankful to be able to quickly figure out what parts of the code they are interested in. > Tabulating the logarithmic factorial > > > Key: MATH-1293 > URL: https://issues.apache.org/jira/browse/MATH-1293 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.5 >Reporter: Aleksei Dievskii >Priority: Minor > Labels: feature, patch > Attachments: factlog.patch > > > Presently, CombinatoricsUtils#factorialLog is calculated via a tabulated > value for the first 21 entries, and for the rest it employs linear-complexity > direct summing. For the factorial-heavy computations this can be rather > painful. I propose a patch which allocates additional 16KB of tabulated > log-factorial values, allowing very fast (constant complexity) computation > for arguments up to 17000, and delegating to the log-gamma for the rest. > Benchmarks show a speed-up of up to 200x. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1292) Change convertToComplex method to real2Complex
[ https://issues.apache.org/jira/browse/MATH-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15010753#comment-15010753 ] Gilles commented on MATH-1292: -- Please ask for comment about MATH-1291 and MATH-1291 on the "dev" ML, so that we can go forward with those small changes (at least in the "master" branch). > Change convertToComplex method to real2Complex > -- > > Key: MATH-1292 > URL: https://issues.apache.org/jira/browse/MATH-1292 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.5 >Reporter: Eric Barnhill >Priority: Trivial > Labels: newbie, patch > Fix For: 4.0 > > > Change the nomenclature of this method slightly so that it matches all the > proposed new methods in ComplexUtils: complex2InterleavedFloat etc. This will > also require a small patch on LaguerreSolver so that it doesn't break, but > there appear to be no further dependencies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1292) Change convertToComplex method to real2Complex
[ https://issues.apache.org/jira/browse/MATH-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15010752#comment-15010752 ] Eric Barnhill commented on MATH-1292: - As currently written, the method is overloaded to handle either. > Change convertToComplex method to real2Complex > -- > > Key: MATH-1292 > URL: https://issues.apache.org/jira/browse/MATH-1292 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.5 >Reporter: Eric Barnhill >Priority: Trivial > Labels: newbie, patch > Fix For: 4.0 > > > Change the nomenclature of this method slightly so that it matches all the > proposed new methods in ComplexUtils: complex2InterleavedFloat etc. This will > also require a small patch on LaguerreSolver so that it doesn't break, but > there appear to be no further dependencies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1292) Change convertToComplex method to real2Complex
[ https://issues.apache.org/jira/browse/MATH-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15010745#comment-15010745 ] Gilles commented on MATH-1292: -- Since converting from/to "float" is also foreseen, wouldn't it be safer to name that method "double2Complex"? > Change convertToComplex method to real2Complex > -- > > Key: MATH-1292 > URL: https://issues.apache.org/jira/browse/MATH-1292 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.5 >Reporter: Eric Barnhill >Priority: Trivial > Labels: newbie, patch > Fix For: 4.0 > > > Change the nomenclature of this method slightly so that it matches all the > proposed new methods in ComplexUtils: complex2InterleavedFloat etc. This will > also require a small patch on LaguerreSolver so that it doesn't break, but > there appear to be no further dependencies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MATH-1293) Tabulating the logarithmic factorial
[ https://issues.apache.org/jira/browse/MATH-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Dievskii updated MATH-1293: --- Attachment: factlog.patch The logarithmic factorial patch. > Tabulating the logarithmic factorial > > > Key: MATH-1293 > URL: https://issues.apache.org/jira/browse/MATH-1293 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.5 >Reporter: Aleksei Dievskii >Priority: Minor > Labels: feature, patch > Attachments: factlog.patch > > > Presently, CombinatoricsUtils#factorialLog is calculated via a tabulated > value for the first 21 entries, and for the rest it employs linear-complexity > direct summing. For the factorial-heavy computations this can be rather > painful. I propose a patch which allocates additional 16KB of tabulated > log-factorial values, allowing very fast (constant complexity) computation > for arguments up to 17000, and delegating to the log-gamma for the rest. > Benchmarks show a speed-up of up to 200x. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MATH-1293) Tabulating the logarithmic factorial
Aleksei Dievskii created MATH-1293: -- Summary: Tabulating the logarithmic factorial Key: MATH-1293 URL: https://issues.apache.org/jira/browse/MATH-1293 Project: Commons Math Issue Type: Improvement Affects Versions: 3.5 Reporter: Aleksei Dievskii Priority: Minor Presently, CombinatoricsUtils#factorialLog is calculated via a tabulated value for the first 21 entries, and for the rest it employs linear-complexity direct summing. For the factorial-heavy computations this can be rather painful. I propose a patch which allocates additional 16KB of tabulated log-factorial values, allowing very fast (constant complexity) computation for arguments up to 17000, and delegating to the log-gamma for the rest. Benchmarks show a speed-up of up to 200x. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1292) Change convertToComplex method to real2Complex
[ https://issues.apache.org/jira/browse/MATH-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15010724#comment-15010724 ] Eric Barnhill commented on MATH-1292: - Sorry Gilles, that was not right. It was a method called convertToComplex that had to be changed. polar2Complex already had the 2 in it. I checked the development branch to be sure this time. LaguerreSolver does indeed call convertToComplex and I propose in Math-1291 to change this call to real2Complex so it doesn't break. > Change convertToComplex method to real2Complex > -- > > Key: MATH-1292 > URL: https://issues.apache.org/jira/browse/MATH-1292 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.5 >Reporter: Eric Barnhill >Priority: Trivial > Labels: newbie, patch > Fix For: 4.0 > > > Change the nomenclature of this method slightly so that it matches all the > proposed new methods in ComplexUtils: complex2InterleavedFloat etc. This will > also require a small patch on LaguerreSolver so that it doesn't break, but > there appear to be no further dependencies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MATH-1292) Change convertToComplex method to real2Complex
[ https://issues.apache.org/jira/browse/MATH-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Barnhill updated MATH-1292: Summary: Change convertToComplex method to real2Complex (was: Change polarToComplex to polar2Complex) > Change convertToComplex method to real2Complex > -- > > Key: MATH-1292 > URL: https://issues.apache.org/jira/browse/MATH-1292 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.5 >Reporter: Eric Barnhill >Priority: Trivial > Labels: newbie, patch > Fix For: 4.0 > > > Change the nomenclature of this method slightly so that it matches all the > proposed new methods in ComplexUtils: complex2InterleavedFloat etc. This will > also require a small patch on LaguerreSolver so that it doesn't break, but > there appear to be no further dependencies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MATH-1291) Alteration of LaguerreSolver to adapt to new ComplexUtils nomenclature
[ https://issues.apache.org/jira/browse/MATH-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Barnhill updated MATH-1291: Description: I have adopted nomenclature such as complex2Real and interleavedFloat2Complex in my proposed patch for ComplexUtils. There is already a method present called convertToComplex which I propose elsewhere to changing to real2Complex to conform to this new nomenclature. This method is called by LaguerreSolver, so I propose a patch to LaguerreSolver so that the code is not broken by this change to ComplexUtils. (was: I have adopted nomenclature such as complex2Real and interleavedFloat2Complex in my proposed patch for ComplexUtils. There is already a method present called polarToComplex which I propose elsewhere to changing to polar2Complex to conform to this new nomenclature. This method is called by LaguerreSolver, so I propose a patch to LaguerreSolver so that the code is not broken by this change to ComplexUtils.) > Alteration of LaguerreSolver to adapt to new ComplexUtils nomenclature > -- > > Key: MATH-1291 > URL: https://issues.apache.org/jira/browse/MATH-1291 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.5 >Reporter: Eric Barnhill >Priority: Trivial > Labels: newbie, patch > Fix For: 4.0 > > Original Estimate: 1h > Remaining Estimate: 1h > > I have adopted nomenclature such as complex2Real and interleavedFloat2Complex > in my proposed patch for ComplexUtils. There is already a method present > called convertToComplex which I propose elsewhere to changing to real2Complex > to conform to this new nomenclature. This method is called by LaguerreSolver, > so I propose a patch to LaguerreSolver so that the code is not broken by this > change to ComplexUtils. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1292) Change polarToComplex to polar2Complex
[ https://issues.apache.org/jira/browse/MATH-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15010710#comment-15010710 ] Gilles commented on MATH-1292: -- I don't see that a method "polarToComplex" still exists (in either of the two development branches). > Change polarToComplex to polar2Complex > -- > > Key: MATH-1292 > URL: https://issues.apache.org/jira/browse/MATH-1292 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.5 >Reporter: Eric Barnhill >Priority: Trivial > Labels: newbie, patch > Fix For: 4.0 > > > Change the nomenclature of this method slightly so that it matches all the > proposed new methods in ComplexUtils: complex2InterleavedFloat etc. This will > also require a small patch on LaguerreSolver so that it doesn't break, but > there appear to be no further dependencies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-582) Maven repository metadata of Commons Collections in bad condition
[ https://issues.apache.org/jira/browse/COLLECTIONS-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15010665#comment-15010665 ] Joerg Schaible commented on COLLECTIONS-582: Not possible, it's auto-generated at central. > Maven repository metadata of Commons Collections in bad condition > - > > Key: COLLECTIONS-582 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-582 > Project: Commons Collections > Issue Type: Bug > Components: Core >Affects Versions: 3.2.2 >Reporter: Alexander Veit > > The metadata located at > https://repo1.maven.org/maven2/commons-collections/commons-collections/maven-metadata.xml > are in a bad condition. > It states that latest version and release version is 20040616. Moreover, the > list of versions does not reflect the actual release order. > This makes it difficult to automatically check for new versions in our QA > processes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MATH-1292) Change polarToComplex to polar2Complex
Eric Barnhill created MATH-1292: --- Summary: Change polarToComplex to polar2Complex Key: MATH-1292 URL: https://issues.apache.org/jira/browse/MATH-1292 Project: Commons Math Issue Type: Improvement Affects Versions: 3.5 Reporter: Eric Barnhill Priority: Trivial Fix For: 4.0 Change the nomenclature of this method slightly so that it matches all the proposed new methods in ComplexUtils: complex2InterleavedFloat etc. This will also require a small patch on LaguerreSolver so that it doesn't break, but there appear to be no further dependencies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MATH-1291) Alteration of LaguerreSolver to adapt to new ComplexUtils nomenclature
Eric Barnhill created MATH-1291: --- Summary: Alteration of LaguerreSolver to adapt to new ComplexUtils nomenclature Key: MATH-1291 URL: https://issues.apache.org/jira/browse/MATH-1291 Project: Commons Math Issue Type: Improvement Affects Versions: 3.5 Reporter: Eric Barnhill Priority: Trivial Fix For: 4.0 I have adopted nomenclature such as complex2Real and interleavedFloat2Complex in my proposed patch for ComplexUtils. There is already a method present called polarToComplex which I propose elsewhere to changing to polar2Complex to conform to this new nomenclature. This method is called by LaguerreSolver, so I propose a patch to LaguerreSolver so that the code is not broken by this change to ComplexUtils. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MATH-1290) Additions to Complex Utils; creation of conversion methods between Complex[], double[], float[], and interleaved arrays
Eric Barnhill created MATH-1290: --- Summary: Additions to Complex Utils; creation of conversion methods between Complex[], double[], float[], and interleaved arrays Key: MATH-1290 URL: https://issues.apache.org/jira/browse/MATH-1290 Project: Commons Math Issue Type: Improvement Affects Versions: 3.5 Reporter: Eric Barnhill Priority: Minor Fix For: 4.0 I propose to add several new methods to the ComplexUtils class enabling easy conversion between Complex[] arrays, real or imaginary double[] or float[] arrays, and interleaved complex double[] or float[] arrays. The last two in particular are beneficial to have for OpenCL implementations and the JTransforms library. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-582) Maven repository metadata of Commons Collections in bad condition
[ https://issues.apache.org/jira/browse/COLLECTIONS-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15010565#comment-15010565 ] Emmanuel Bourg commented on COLLECTIONS-582: Would it be possible to ask for a modification of the metadata file? The versions deployed would remain, but maven-metadata.xml could at least point to 3.2.2 as the latest release. This happens automatically with every new release, so it's legitimate to expect that for commons-collections 3.2.2. > Maven repository metadata of Commons Collections in bad condition > - > > Key: COLLECTIONS-582 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-582 > Project: Commons Collections > Issue Type: Bug > Components: Core >Affects Versions: 3.2.2 >Reporter: Alexander Veit > > The metadata located at > https://repo1.maven.org/maven2/commons-collections/commons-collections/maven-metadata.xml > are in a bad condition. > It states that latest version and release version is 20040616. Moreover, the > list of versions does not reflect the actual release order. > This makes it difficult to automatically check for new versions in our QA > processes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (COLLECTIONS-582) Maven repository metadata of Commons Collections in bad condition
[ https://issues.apache.org/jira/browse/COLLECTIONS-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved COLLECTIONS-582. - Resolution: Won't Fix This is unfortunate, but a mistake from the past which can not be corrected afaict. The collections4 release has different maven coordinates, so for the newer version this should have been fixed. > Maven repository metadata of Commons Collections in bad condition > - > > Key: COLLECTIONS-582 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-582 > Project: Commons Collections > Issue Type: Bug > Components: Core >Affects Versions: 3.2.2 >Reporter: Alexander Veit > > The metadata located at > https://repo1.maven.org/maven2/commons-collections/commons-collections/maven-metadata.xml > are in a bad condition. > It states that latest version and release version is 20040616. Moreover, the > list of versions does not reflect the actual release order. > This makes it difficult to automatically check for new versions in our QA > processes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COLLECTIONS-582) Maven repository metadata of Commons Collections in bad condition
Alexander Veit created COLLECTIONS-582: -- Summary: Maven repository metadata of Commons Collections in bad condition Key: COLLECTIONS-582 URL: https://issues.apache.org/jira/browse/COLLECTIONS-582 Project: Commons Collections Issue Type: Bug Components: Core Affects Versions: 3.2.2 Reporter: Alexander Veit The metadata located at https://repo1.maven.org/maven2/commons-collections/commons-collections/maven-metadata.xml are in a bad condition. It states that latest version and release version is 20040616. Moreover, the list of versions does not reflect the actual release order. This makes it difficult to automatically check for new versions in our QA processes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
