[jira] [Commented] (MATH-743) Use enums in package transform
[
https://issues.apache.org/jira/browse/MATH-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13205295#comment-13205295
]
Sébastien Brisard commented on MATH-743:
In revision {{r1242703}}, introduced
* enumeration {{TransformType}}, with two values {{FORWARD}} and {{INVERSE}}
* enumeration {{FastFourierTransformer.DftNormalization}}, with two values
{{STANDARD}} and {{UNITARY}}.
In {{FastFourierTransformer}}, the normalization is now specified at
construction time, while the type is specified in the methods {{Complex[]
transform(Complex[], TransformType)}} and the likes. The rationale is that no
matter the transform (DFT, DST, DCT, DHT), forward and inverse are always
meaningful (so {{TransformType}} is shared by *all* transforms). On the other
hand, normalization is transform specific. For example, DST and DCT can be made
orthogonal, while FFT can be made unitary (orthogonal doesn't mean anything
with complex transforms).
This API change greatly simplifies unit testing, as it is now possible to
*loop* over the types and normalizations!
In order to allow for possible independent implementations of the DFT, I
propose that {{DftNormalization}} be a top-level enum, instead of a nested
enum. Also, most of the header of the current Javadoc of
{{FastFourierTransformer}} should actually move to {{DftNormalization}}.
Use enums in package transform
--
Key: MATH-743
URL: https://issues.apache.org/jira/browse/MATH-743
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Labels: api-change, enum, transform
As discussed on the mailing-list, enums could be used in the package
{{transform}}
# An enumeration {{FORWARD, INVERSE}} will be created to specify whether the
inverse transform is to be computed. This will replace the pair
{{transform}}/{{inverseTransform}}
# An enumeration {{STANDARD, ORTHOGONAL}} will be introduced (where relevant)
in each transform class, in order to specify the normalization that should be
used. Then the factory methods {{create()}}/{{createOrthogonal()}} will be
replaced by a parameter passed to the constructor, which will be made public.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-742) Please make PolynomialSplineFunction Serializable
[
https://issues.apache.org/jira/browse/MATH-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13205373#comment-13205373
]
Leandro Ariel Pezzente commented on MATH-742:
-
Anyone has any thougths about this issue ?
Please make PolynomialSplineFunction Serializable
-
Key: MATH-742
URL: https://issues.apache.org/jira/browse/MATH-742
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Neil Roeth
Priority: Minor
PolynomialSplineFunction is not Serializable, while the very similar
PolynomialFunction class in the same package is. All that needs to be done is
to add the import:
{{import java.io.Serializable;}}
and change this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction}}
to this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction, Serializable}}
I made exactly that modification to a local copy and it serialized
successfully. Before the change, I got serialization errors.
Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-742) Please make PolynomialSplineFunction Serializable
[
https://issues.apache.org/jira/browse/MATH-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13205385#comment-13205385
]
Luc Maisonobe commented on MATH-742:
Sounds good to me.
Note that once class becomes serializable, it should have a serialization ID.
We recently decided to use the date of the source file change as the idea in
short ISO-8601 format. So if the change were made today, the ID would be
20120210.
Please make PolynomialSplineFunction Serializable
-
Key: MATH-742
URL: https://issues.apache.org/jira/browse/MATH-742
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Neil Roeth
Priority: Minor
PolynomialSplineFunction is not Serializable, while the very similar
PolynomialFunction class in the same package is. All that needs to be done is
to add the import:
{{import java.io.Serializable;}}
and change this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction}}
to this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction, Serializable}}
I made exactly that modification to a local copy and it serialized
successfully. Before the change, I got serialization errors.
Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANDBOX-389) [BeanUtils2] Implement populate() on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated SANDBOX-389:
Attachment: SANDBOX-389v2.txt
I finally got the time to review and fix my patch. I re-implemented
{{equals()}} on {{TestBean}} using commons lang 3. Commons lang 3.1 has been
added as a dependency in test scope to pom.xml.
Now everything should be fine with {{populate}()}.
Regards,
Benedikt
[BeanUtils2] Implement populate() on DefaultBeanAccessor
-
Key: SANDBOX-389
URL: https://issues.apache.org/jira/browse/SANDBOX-389
Project: Commons Sandbox
Issue Type: Improvement
Components: BeanUtils2
Affects Versions: Nightly Builds
Reporter: Benedikt Ritter
Attachments: SANDBOX-389.txt, SANDBOX-389v2.txt
Implement {{populate()}} as discussed on the ML (see
http://markmail.org/thread/niv47muvrms56pqr)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (SANDBOX-389) [BeanUtils2] Implement populate() on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13205386#comment-13205386
]
Benedikt Ritter edited comment on SANDBOX-389 at 2/10/12 12:13 PM:
---
I finally got the time to review and fix my patch. I re-implemented
{{equals()}} on {{TestBean}} using commons lang 3. Commons lang 3.1 has been
added as a dependency in test scope to pom.xml.
Now everything should be fine with {{populate()}}.
Regards,
Benedikt
was (Author: britter):
I finally got the time to review and fix my patch. I re-implemented
{{equals()}} on {{TestBean}} using commons lang 3. Commons lang 3.1 has been
added as a dependency in test scope to pom.xml.
Now everything should be fine with {{populate}()}.
Regards,
Benedikt
[BeanUtils2] Implement populate() on DefaultBeanAccessor
-
Key: SANDBOX-389
URL: https://issues.apache.org/jira/browse/SANDBOX-389
Project: Commons Sandbox
Issue Type: Improvement
Components: BeanUtils2
Affects Versions: Nightly Builds
Reporter: Benedikt Ritter
Attachments: SANDBOX-389.txt, SANDBOX-389v2.txt
Implement {{populate()}} as discussed on the ML (see
http://markmail.org/thread/niv47muvrms56pqr)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-742) Please make PolynomialSplineFunction Serializable
[
https://issues.apache.org/jira/browse/MATH-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13205399#comment-13205399
]
Leandro Ariel Pezzente commented on MATH-742:
-
Ok. There , can you check if The changes have being made properly ?
Please make PolynomialSplineFunction Serializable
-
Key: MATH-742
URL: https://issues.apache.org/jira/browse/MATH-742
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Neil Roeth
Priority: Minor
Attachments: PolynomialSplineFunction.java
PolynomialSplineFunction is not Serializable, while the very similar
PolynomialFunction class in the same package is. All that needs to be done is
to add the import:
{{import java.io.Serializable;}}
and change this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction}}
to this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction, Serializable}}
I made exactly that modification to a local copy and it serialized
successfully. Before the change, I got serialization errors.
Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-742) Please make PolynomialSplineFunction Serializable
[
https://issues.apache.org/jira/browse/MATH-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leandro Ariel Pezzente updated MATH-742:
Attachment: PolynomialSplineFunction.java
Please make PolynomialSplineFunction Serializable
-
Key: MATH-742
URL: https://issues.apache.org/jira/browse/MATH-742
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Neil Roeth
Priority: Minor
Attachments: PolynomialSplineFunction.java
PolynomialSplineFunction is not Serializable, while the very similar
PolynomialFunction class in the same package is. All that needs to be done is
to add the import:
{{import java.io.Serializable;}}
and change this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction}}
to this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction, Serializable}}
I made exactly that modification to a local copy and it serialized
successfully. Before the change, I got serialization errors.
Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-742) Please make PolynomialSplineFunction Serializable
[
https://issues.apache.org/jira/browse/MATH-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13205404#comment-13205404
]
Gilles commented on MATH-742:
-
In principle, I'm against applying the {{Serializable}} pseudo-interface.
In this case, as with most of what is in CM, we deal with an object whose main
purpose is to _compute_ something, not to store data. I know that the border
between data and computation is not clear-cut, especially in the OO paradigm...
But the main rationale is to not induce the users to think that it is good
practice to store data using the default serialization system. If I'm not
mistaken, this feature was meant to ease some of the plumbing needed for
distributed applications.
Serializable is certainly not to be taken as a substitute for a stable API
aimed at safe long-term storage. It is for this reason that I think that the
default should be to *not* implement Serializable unless there is a good
clear case (i.e. not one that displays a bad practice) that needs it. E.g.
there was the convincing case for the exception infrastructure (cf. package
exception.util) to be Serializable: Whenever some remote application using
CM needed to report a failure and could not unless the given exception could be
serialized.
Please make PolynomialSplineFunction Serializable
-
Key: MATH-742
URL: https://issues.apache.org/jira/browse/MATH-742
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Neil Roeth
Priority: Minor
Attachments: PolynomialSplineFunction.java
PolynomialSplineFunction is not Serializable, while the very similar
PolynomialFunction class in the same package is. All that needs to be done is
to add the import:
{{import java.io.Serializable;}}
and change this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction}}
to this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction, Serializable}}
I made exactly that modification to a local copy and it serialized
successfully. Before the change, I got serialization errors.
Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-742) Please make PolynomialSplineFunction Serializable
[
https://issues.apache.org/jira/browse/MATH-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13205424#comment-13205424
]
Luc Maisonobe commented on MATH-742:
Instead of full file, we often prefer to get patches in the form of diff. It
simplifies checking the changes and applying them.
The problem with having non-serializable classes is that this completely
prevents them from being used as fields in user-defined classes which may need
to be serializable. Serialization is useful in many situations which are not
related to long-term storage and we should not prevent it. So as long as there
is no identified problem to have serializable classes (such as very big data
structures or singletons), then serializable could be added liberally.
Please make PolynomialSplineFunction Serializable
-
Key: MATH-742
URL: https://issues.apache.org/jira/browse/MATH-742
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Neil Roeth
Priority: Minor
Attachments: PolynomialSplineFunction.java
PolynomialSplineFunction is not Serializable, while the very similar
PolynomialFunction class in the same package is. All that needs to be done is
to add the import:
{{import java.io.Serializable;}}
and change this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction}}
to this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction, Serializable}}
I made exactly that modification to a local copy and it serialized
successfully. Before the change, I got serialization errors.
Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-741) Univariate Function Series Abstract Factory Implementation
[ https://issues.apache.org/jira/browse/MATH-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13205427#comment-13205427 ] Gilles commented on MATH-741: - Leandro, First, I must say that we are really happy that you want to join in and contribute. However, your proposal and implementations have several issues: * The formatting is not compliant. * The documentation is incomplete and contains a lot of typos. * The purpose of the proposal is not clear and should be presented on the dev ML. (For example, the name UnivariateFunctionFactory does not reflect the specific concept at hand.) * The implementation uses the type of coding that is best avoided whenever possible (cf setResult and initUnivariateFunctionFactory). Please note that I couldn't review your code in much detail, because the main priority is to release 3.0 very soon now. But you should really start a discussion on this feature on the dev ML. Thanks. Univariate Function Series Abstract Factory Implementation -- Key: MATH-741 URL: https://issues.apache.org/jira/browse/MATH-741 Project: Commons Math Issue Type: New Feature Affects Versions: 4.0 Reporter: Leandro Ariel Pezzente Priority: Minor Attachments: Hypergeometric.java, TestHypergeometric.java, UnivariateFunctionFactory.java To Implement an abstract class for witch Univariate functions constructed using functional series. This abstract class must resolve all terms sums using recursive iterative methods. Classes subclassed by this abstract function must implement UnivariateFunction interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-742) Please make PolynomialSplineFunction Serializable
[
https://issues.apache.org/jira/browse/MATH-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13205452#comment-13205452
]
Neil Roeth commented on MATH-742:
-
Luc, that is precisely my situation. I have a grid computing application where
my user-defined objects are returned from the grid, and they contain a
PolynomialSplineFunction that is a critical part of the calculated result.
Gilles, this is the plumbing needed for distributed applications in my case.
Please make PolynomialSplineFunction Serializable
-
Key: MATH-742
URL: https://issues.apache.org/jira/browse/MATH-742
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Neil Roeth
Priority: Minor
Attachments: PolynomialSplineFunction.java
PolynomialSplineFunction is not Serializable, while the very similar
PolynomialFunction class in the same package is. All that needs to be done is
to add the import:
{{import java.io.Serializable;}}
and change this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction}}
to this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction, Serializable}}
I made exactly that modification to a local copy and it serialized
successfully. Before the change, I got serialization errors.
Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SCXML-137) Implement full support for core module in scxml-js
[ https://issues.apache.org/jira/browse/SCXML-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Beard resolved SCXML-137. --- Resolution: Fixed Implement full support for core module in scxml-js -- Key: SCXML-137 URL: https://issues.apache.org/jira/browse/SCXML-137 Project: Commons SCXML Issue Type: Improvement Affects Versions: GSoC Reporter: Jacob Beard Assignee: Jacob Beard Fix For: GSoC -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SCXML-144) send
[ https://issues.apache.org/jira/browse/SCXML-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Beard resolved SCXML-144. --- Resolution: Won't Fix send -- Key: SCXML-144 URL: https://issues.apache.org/jira/browse/SCXML-144 Project: Commons SCXML Issue Type: Sub-task Reporter: Jacob Beard Assignee: Jacob Beard Fix For: GSoC http://www.w3.org/TR/scxml/#send -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SCXML-146) invoke
[ https://issues.apache.org/jira/browse/SCXML-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Beard resolved SCXML-146. --- Resolution: Won't Fix invoke Key: SCXML-146 URL: https://issues.apache.org/jira/browse/SCXML-146 Project: Commons SCXML Issue Type: Sub-task Affects Versions: GSoC Reporter: Jacob Beard Assignee: Jacob Beard Fix For: GSoC http://www.w3.org/TR/scxml/#Invoke -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SCXML-125) Add compiler flags to allow target code to integrate with existing JavaScript toolkits
[ https://issues.apache.org/jira/browse/SCXML-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Beard resolved SCXML-125. --- Resolution: Won't Fix Add compiler flags to allow target code to integrate with existing JavaScript toolkits -- Key: SCXML-125 URL: https://issues.apache.org/jira/browse/SCXML-125 Project: Commons SCXML Issue Type: Sub-task Reporter: Jacob Beard Fix For: GSoC * investigate integration with Dojo JavaScript toolkit -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SCXML-126) Implement framework for graphical debugging
[ https://issues.apache.org/jira/browse/SCXML-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Beard resolved SCXML-126. --- Resolution: Fixed Implement framework for graphical debugging --- Key: SCXML-126 URL: https://issues.apache.org/jira/browse/SCXML-126 Project: Commons SCXML Issue Type: Sub-task Reporter: Jacob Beard Fix For: GSoC * Automatic generation of graphical depiction of statechart static structure ** Port Denis Dube's work on graph layout from Python and Tkinter to SVG and JavaScript: http://msdl.cs.mcgill.ca/people/denis/atom3layout * Instrumentation of JavaScript backends to support animation of graphical depiction -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SCXML-121) Assemble Test Models
[ https://issues.apache.org/jira/browse/SCXML-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Beard resolved SCXML-121. --- Resolution: Won't Fix Assemble Test Models Key: SCXML-121 URL: https://issues.apache.org/jira/browse/SCXML-121 Project: Commons SCXML Issue Type: Sub-task Reporter: Jacob Beard Fix For: GSoC * From domain of User Interfaces ** Model of Inkscape canvas object Behaviour *** port simple csgroup statechart to scxml *** compile w/ scxmlcgf/js ensure changes in state work *** add in support for script tags, datamodel, etc. into scxmlcgfs/js *** write unit tests to show that it works *** run performance benchmarks ** Model of Spline-drawing behaviour ** ATOMPM behaviour models * From other domains ** ask the community to contribute relevant work -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SCXML-145) cancel
[ https://issues.apache.org/jira/browse/SCXML-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Beard resolved SCXML-145. --- Resolution: Fixed cancel Key: SCXML-145 URL: https://issues.apache.org/jira/browse/SCXML-145 Project: Commons SCXML Issue Type: Sub-task Reporter: Jacob Beard Assignee: Jacob Beard Fix For: GSoC http://www.w3.org/TR/scxml/#cancel -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SCXML-122) Tune performance of compiled code
[ https://issues.apache.org/jira/browse/SCXML-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Beard resolved SCXML-122. --- Resolution: Won't Fix Tune performance of compiled code - Key: SCXML-122 URL: https://issues.apache.org/jira/browse/SCXML-122 Project: Commons SCXML Issue Type: Sub-task Reporter: Jacob Beard Fix For: GSoC * Perform data acquisiton and anlysis to determine which SC compilation strategy offers fastest execution speed, least memory usage, etc. * Take optimal strategies, run through a profiler to look for other performance bottlenecks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SCXML-147) finalize
[ https://issues.apache.org/jira/browse/SCXML-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Beard resolved SCXML-147. --- Resolution: Won't Fix finalize -- Key: SCXML-147 URL: https://issues.apache.org/jira/browse/SCXML-147 Project: Commons SCXML Issue Type: Sub-task Affects Versions: GSoC Reporter: Jacob Beard Assignee: Jacob Beard Fix For: GSoC http://www.w3.org/TR/scxml/#finalize -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SCXML-148) Implement Data Module for scxml-js
[ https://issues.apache.org/jira/browse/SCXML-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Beard resolved SCXML-148. --- Resolution: Fixed Implement Data Module for scxml-js -- Key: SCXML-148 URL: https://issues.apache.org/jira/browse/SCXML-148 Project: Commons SCXML Issue Type: New Feature Affects Versions: GSoC Reporter: Jacob Beard Assignee: Jacob Beard Fix For: GSoC -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SCXML-136) Migrate build system to Maven or Ant
[ https://issues.apache.org/jira/browse/SCXML-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Beard resolved SCXML-136. --- Resolution: Fixed Migrate build system to Maven or Ant Key: SCXML-136 URL: https://issues.apache.org/jira/browse/SCXML-136 Project: Commons SCXML Issue Type: Sub-task Reporter: Jacob Beard Assignee: Jacob Beard Fix For: GSoC Original Estimate: 10h Remaining Estimate: 10h -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SCXML-143) Implement external communications module for scxml-js
[ https://issues.apache.org/jira/browse/SCXML-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Beard resolved SCXML-143. --- Resolution: Fixed Implement external communications module for scxml-js - Key: SCXML-143 URL: https://issues.apache.org/jira/browse/SCXML-143 Project: Commons SCXML Issue Type: New Feature Affects Versions: GSoC Reporter: Jacob Beard Assignee: Jacob Beard Fix For: GSoC -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SCXML-149) Implement Script module for scxml-js
[ https://issues.apache.org/jira/browse/SCXML-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Beard resolved SCXML-149. --- Resolution: Fixed Implement Script module for scxml-js Key: SCXML-149 URL: https://issues.apache.org/jira/browse/SCXML-149 Project: Commons SCXML Issue Type: New Feature Affects Versions: GSoC Reporter: Jacob Beard Assignee: Jacob Beard Fix For: GSoC -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SCXML-120) Implement Full coverage of SCXML Specification
[ https://issues.apache.org/jira/browse/SCXML-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Beard resolved SCXML-120. --- Resolution: Won't Fix Implement Full coverage of SCXML Specification -- Key: SCXML-120 URL: https://issues.apache.org/jira/browse/SCXML-120 Project: Commons SCXML Issue Type: Sub-task Reporter: Jacob Beard Assignee: Jacob Beard Fix For: GSoC Script Module Condition Expressions on Transitions Data Module Hierarchical Events External Communications Module -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SCXML-115) SCXML Code Generation Framework, JavaScript Edition (SCXML/cgf/js): An SCXML-to-JavaScript Compiler Optimized for User Interface Development on the World Wide Web
[ https://issues.apache.org/jira/browse/SCXML-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Beard resolved SCXML-115. --- Resolution: Won't Fix SCXML Code Generation Framework, JavaScript Edition (SCXML/cgf/js): An SCXML-to-JavaScript Compiler Optimized for User Interface Development on the World Wide Web -- Key: SCXML-115 URL: https://issues.apache.org/jira/browse/SCXML-115 Project: Commons SCXML Issue Type: New Feature Environment: Compiler runs on the Java Virtual Machine Compiled code targets the web browser environment Reporter: Jacob Beard Priority: Minor Labels: GSoC, mentor Fix For: GSoC Original Estimate: 1,872h Remaining Estimate: 1,872h There are many challenges that software developers face during the development of complex User Interfaces (UI). Desired behaviour may be autonomous or reactive, and possibly real-time. Each UI component may be required to exhibit a radically different behaviour from that of any other component, and the behaviour of components may be inter-related. These complex behavioural relationships between components are often difficult to express, and are even more difficult to encode and maintain. A solution may be found in Model-Driven Engineering. In particular, Statecharts, a formalism for describing complex, state-based behaviour, is well-suited for describing certain kinds of UI behaviour. At the same time, the Open Web is becoming increasingly popular as a platform for application development. Applications may be built using a suite of technologies implemented in modern web browsers. In particular, the JavaScript language is used to implement interactivity and dynamic behaviour in UI objects. It is thus possible to create browser-based applications that are richly interactive. These applications are typically called Rich Internet Applications (RIAs). SCXML is a human-readable XML application for describing Statecharts. An SCXML-to-JavaScript compiler, then, would allow developers of RIAs to use Statecharts to describe and implement the behaviour of their UIs, which would thus make it easier to develop RIAs with complex behaviour requirements. Furthermore, in order to allow developers to better comprehend the dynamic behaviour described by their statechart, it would be useful to provide a tool that may generate graphical depictions of statecharts from SCXML input documents, which may then be animated in response to live user interface events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-742) Please make PolynomialSplineFunction Serializable
[
https://issues.apache.org/jira/browse/MATH-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13205517#comment-13205517
]
Gilles commented on MATH-742:
-
bq. this completely prevents them from being used as fields in user-defined
classes which may need to be serializable
The issue (and my question) is: Is this field needed in the serialization? If
not, the user can add the transient keyword to the variable instance
declaration.
If it is needed, then again, is Serializable the correct way? That it is the
quick-and-dirty solution, I know.
Finally, if we don't care about advertising good (or bad) practice in this
area, then let's globally add Serializable to every class...
Is there a CheckStyle rule to detect such a requirement? Can anyone come up
with a script that would automatically do the job?
Please make PolynomialSplineFunction Serializable
-
Key: MATH-742
URL: https://issues.apache.org/jira/browse/MATH-742
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Neil Roeth
Priority: Minor
Attachments: PolynomialSplineFunction.java
PolynomialSplineFunction is not Serializable, while the very similar
PolynomialFunction class in the same package is. All that needs to be done is
to add the import:
{{import java.io.Serializable;}}
and change this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction}}
to this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction, Serializable}}
I made exactly that modification to a local copy and it serialized
successfully. Before the change, I got serialization errors.
Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-741) Univariate Function Series Abstract Factory Implementation
[ https://issues.apache.org/jira/browse/MATH-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13205541#comment-13205541 ] Leandro Ariel Pezzente commented on MATH-741: - Thanks for your commments , Gilles!. I think I should give this idea a deep review. I am gonna focus on trying to contribute with the open tickets instead. Do you this I should close this isse for now ? Univariate Function Series Abstract Factory Implementation -- Key: MATH-741 URL: https://issues.apache.org/jira/browse/MATH-741 Project: Commons Math Issue Type: New Feature Affects Versions: 4.0 Reporter: Leandro Ariel Pezzente Priority: Minor Attachments: Hypergeometric.java, TestHypergeometric.java, UnivariateFunctionFactory.java To Implement an abstract class for witch Univariate functions constructed using functional series. This abstract class must resolve all terms sums using recursive iterative methods. Classes subclassed by this abstract function must implement UnivariateFunction interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIGESTER-158) Use Java6 annotation processing to generate RulesModule instances at compile-time
[
https://issues.apache.org/jira/browse/DIGESTER-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13205543#comment-13205543
]
Matt Benson commented on DIGESTER-158:
--
This was left as a problem: Simo's initial implementation of this was done
against Java 5 APT. [digester] currently supports Java 5, but its CI systems
(Continuum in particular) are using a Java 6 installation. To be
forward-looking and use the Java 6 {{Processor}}, etc. APIs, is it reasonable
to say:
- [digester]'s runtime code uses only Java 5 APIs
- [digester] includes a Java 6 {{Processor}} that precompiles [digester]
annotations into configured {{RulesModule}}s.
- [digester]'s build is configured with source 1.6, target 1.5
?
Is this a workable approach, or does the {{Processor}} stuff break down on the
third point? If so, would it be simpler to convert [digester] to a multimodule
project and provide the precompilation {{Processor}} as an independent module
that depends on 1.6 even though the core does not? I feel favorable towards
this approach because it makes enabling the precompilation a very explicit act,
and gives the user the opportunity to exclude the {{Processor}} from his
runtime deployment.
Matt
P.S. the {{com.sun.codemodel}} code I mentioned before is in fact working now ;)
Use Java6 annotation processing to generate RulesModule instances at
compile-time
-
Key: DIGESTER-158
URL: https://issues.apache.org/jira/browse/DIGESTER-158
Project: Commons Digester
Issue Type: New Feature
Affects Versions: 3.2
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Fix For: 3.3
Implement a
[http://docs.oracle.com/javase/6/docs/api/javax/annotation/processing/Processor.html]
to process Digester annotations rules and generate {{RulesModule}} instances
at compile time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-732) Major Speed Improvement to 1D Discrete Fourier Transform (approximately 5x-9x improvement). Preserved public API 100%. Removed unnecessary use of instance variables and i
[ https://issues.apache.org/jira/browse/MATH-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13205558#comment-13205558 ] Kurt Ostfeld commented on MATH-732: --- Just checked the latest version from SVN. These changes look excellent. Major Speed Improvement to 1D Discrete Fourier Transform (approximately 5x-9x improvement). Preserved public API 100%. Removed unnecessary use of instance variables and instance state. Key: MATH-732 URL: https://issues.apache.org/jira/browse/MATH-732 Project: Commons Math Issue Type: Improvement Affects Versions: 3.0 Reporter: Kurt Ostfeld Assignee: Sébastien Brisard Labels: api, perfomance Fix For: 3.0 Attachments: DFTPerformanceWithPatch.png, DFTPerformanceWithoutPatch.png, FastFourierTransformer.java, FastFourierTransformerTest.java, Main.java I wrote my own Discrete Fourier Transform function in Java and ran some benchmarks and found that it ran dramatically faster than the Apache library implementation. This is a pretty straight forward implementation of the standard Cooley Tukey algorithm that I read out of a textbook. This passes all the Apache library test cases plus several I had written on my own. I created a source code library patch that preserves the public API completely while changing the internal implementation to achieve the performance improvement. In addition to the performance issue, I suggest that Discrete Fourier Transform functionality be provided as stateless pure functions (in Java this would be implemented with static methods) just like most other math functions. As-is, the library requires the user to instantiate a Transformer instance which maintains instance state, which is an unecessary complexity for a pure math function. I held off on this change since it would change the public API and affect existing code. However, I see similar backward compatability breaking API changes are already in the FastFourierTransformer class in the 3.0 code base. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-741) Univariate Function Series Abstract Factory Implementation
[ https://issues.apache.org/jira/browse/MATH-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13205605#comment-13205605 ] Gilles commented on MATH-741: - Before being closed, the issue must first be resolved. Moreover, I think that closing is done in bulk just before a new version is released. So, whether to resolve depends on how you intend to continue with this issue. If you think that the feature is worth implementing, and you want to start a discussion on the ML and are ready to modify the code according to what emerges from it, then it's fine to leave the ticket open. If you prefer to tackle something else in the list of open tickets, while you'll work on your own until you can provide a more closely compliant patch concerning this feature, it is probably fine to resolve for the time being (maybe using Later as the resolution field). One can always reopen it... later. :) Univariate Function Series Abstract Factory Implementation -- Key: MATH-741 URL: https://issues.apache.org/jira/browse/MATH-741 Project: Commons Math Issue Type: New Feature Affects Versions: 4.0 Reporter: Leandro Ariel Pezzente Priority: Minor Attachments: Hypergeometric.java, TestHypergeometric.java, UnivariateFunctionFactory.java To Implement an abstract class for witch Univariate functions constructed using functional series. This abstract class must resolve all terms sums using recursive iterative methods. Classes subclassed by this abstract function must implement UnivariateFunction interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-742) Please make PolynomialSplineFunction Serializable
[
https://issues.apache.org/jira/browse/MATH-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13205607#comment-13205607
]
Neil Roeth commented on MATH-742:
-
Gilles,
{quote}The issue (and my question) is: Is this field needed in the
serialization?{quote}
Yes.
{quote}If it is needed, then again, is Serializable the correct way?{quote}
As you said, [Serializable] was meant to ease some of the plumbing needed for
distributed applications, so since my application is distributed and needs
this plumbing, the answer is again yes.
I raised this issue to add Serializable to this one particular class; if you
want to discuss globally adding Serializable to every class, that's a different
issue. Could you please open a new issue to discuss that topic? Thanks.
Please make PolynomialSplineFunction Serializable
-
Key: MATH-742
URL: https://issues.apache.org/jira/browse/MATH-742
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Neil Roeth
Priority: Minor
Attachments: PolynomialSplineFunction.java
PolynomialSplineFunction is not Serializable, while the very similar
PolynomialFunction class in the same package is. All that needs to be done is
to add the import:
{{import java.io.Serializable;}}
and change this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction}}
to this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction, Serializable}}
I made exactly that modification to a local copy and it serialized
successfully. Before the change, I got serialization errors.
Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIGESTER-158) Use Java6 annotation processing to generate RulesModule instances at compile-time
[
https://issues.apache.org/jira/browse/DIGESTER-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13205659#comment-13205659
]
Simone Tripodi commented on DIGESTER-158:
-
always *amazing* feedbacks from you, Matt!!!
I think that the suggested multi-module approach sounds the way to go! I will
take care of it as soon as I get a cycle to dedicate to Digester and moving
forward this issue from its status of problem to a feature :)
Use Java6 annotation processing to generate RulesModule instances at
compile-time
-
Key: DIGESTER-158
URL: https://issues.apache.org/jira/browse/DIGESTER-158
Project: Commons Digester
Issue Type: New Feature
Affects Versions: 3.2
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Fix For: 3.3
Implement a
[http://docs.oracle.com/javase/6/docs/api/javax/annotation/processing/Processor.html]
to process Digester annotations rules and generate {{RulesModule}} instances
at compile time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (NET-441) mlistDir doc should be MLSD not MSLD
mlistDir doc should be MLSD not MSLD Key: NET-441 URL: https://issues.apache.org/jira/browse/NET-441 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.1 Reporter: consiliens Priority: Trivial In FTPClient.class Generate a directory listing for the current directory using the MSLD command. should use MLSD not MSLD. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CHAIN-58) Update Chain Context interface to use K,V generics
[
https://issues.apache.org/jira/browse/CHAIN-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi updated CHAIN-58:
Attachment: CHAIN-58-working-context-generics.patch
The latest attached patch implements {{Chains}} taking in consideration any
{{MapK, V}} extension as context (including the existing {{Context}}).
All tests pass.
There are unchecked casts in the XML rules, but, IIRC, XML rules are something
we want to get rid of in 2.0.
There are also binary breakages, sounds it is the right moment to bump to major
version.
Please review the patch, if there is an agreement I can commit it and moving
[chains] development forward.
Update Chain Context interface to use K,V generics
--
Key: CHAIN-58
URL: https://issues.apache.org/jira/browse/CHAIN-58
Project: Commons Chain
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Elijah Zupancic
Fix For: 2.0
Attachments: CHAIN-58-working-context-generics.patch,
chain-58-improved-context-generic.diff, chain-58-with-context-generic.diff,
chain-58.diff
As discussed in the mailing list, I am suggesting that we change the
definition of Context from:
{noformat}
public interface Context extends MapString, Object {
{noformat}
to:
{noformat}
public interface ContextK, V extends MapK, V {
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (NET-441) mlistDir doc should be MLSD not MSLD
[ https://issues.apache.org/jira/browse/NET-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-441. -- Resolution: Fixed Fix Version/s: 3.1 Thanks! mlistDir doc should be MLSD not MSLD Key: NET-441 URL: https://issues.apache.org/jira/browse/NET-441 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.1 Reporter: consiliens Priority: Trivial Fix For: 3.1 Original Estimate: 10m Remaining Estimate: 10m In FTPClient.class Generate a directory listing for the current directory using the MSLD command. should use MLSD not MSLD. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-741) Univariate Function Series Abstract Factory Implementation
[ https://issues.apache.org/jira/browse/MATH-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13205980#comment-13205980 ] Leandro Ariel Pezzente commented on MATH-741: - I like the idea of having a resusable template wich user can rely on to build their own univariate functions implementations given they can't found one that fits they needs. I am willing to both , start a discussion on the ML and modify the code accordingly once i have got properly familiar with this project coding style and formatting. So I think resolving this to Later is a nice solution. Thanks for your feedback Gilles ! :) Univariate Function Series Abstract Factory Implementation -- Key: MATH-741 URL: https://issues.apache.org/jira/browse/MATH-741 Project: Commons Math Issue Type: New Feature Affects Versions: 4.0 Reporter: Leandro Ariel Pezzente Priority: Minor Attachments: Hypergeometric.java, TestHypergeometric.java, UnivariateFunctionFactory.java To Implement an abstract class for witch Univariate functions constructed using functional series. This abstract class must resolve all terms sums using recursive iterative methods. Classes subclassed by this abstract function must implement UnivariateFunction interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[ https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206014#comment-13206014 ] Paul commented on VFS-398: -- As a user of the API, this is in the context of FtpFileObject.getChildren() so it is not possible to percent-encode. From Mark's findings, it looks like this is a major bug that has to be fixed internally right? FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name Key: VFS-398 URL: https://issues.apache.org/jira/browse/VFS-398 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Environment: Connecting via FTP to a host running SunOS 5.10 Reporter: Mark Leonard Priority: Blocker Fix For: 2.0 In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme() method is called: String scheme = UriParser.extractScheme(buffer.toString()); This code was added in revision 780730 http://svn.apache.org/viewvc?view=revisionrevision=780730 It is not clear to me why this change was made. For the FTP provider, buffer contains a plain file name (i.e. without a path and definitely not in URI form) A colon is a valid character for a file name. However a colon will be interpreted as a URI scheme name. This causes an exception when the resolved path is checked using AbstractFileName.checkName() Sample code: FileObject fo = VFS.getManager().resolveFile(ftp://user:pass@host/some/path/some.file;); fo.getParent().getChildren(); If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is thrown: Exception in thread main org.apache.commons.vfs2.FileSystemException: Invalid descendent file name PREFIX:SUFFIX. at org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791) at org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420) Therefore calling code is unable to list the children of the specified folder. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-732) Major Speed Improvement to 1D Discrete Fourier Transform (approximately 5x-9x improvement). Preserved public API 100%. Removed unnecessary use of instance variables and in
[ https://issues.apache.org/jira/browse/MATH-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Brisard resolved MATH-732. Resolution: Fixed Patch successfully committed. Many thanks to the contributor. Further API changes are considered in MATH-743. Major Speed Improvement to 1D Discrete Fourier Transform (approximately 5x-9x improvement). Preserved public API 100%. Removed unnecessary use of instance variables and instance state. Key: MATH-732 URL: https://issues.apache.org/jira/browse/MATH-732 Project: Commons Math Issue Type: Improvement Affects Versions: 3.0 Reporter: Kurt Ostfeld Assignee: Sébastien Brisard Labels: api, perfomance Fix For: 3.0 Attachments: DFTPerformanceWithPatch.png, DFTPerformanceWithoutPatch.png, FastFourierTransformer.java, FastFourierTransformerTest.java, Main.java I wrote my own Discrete Fourier Transform function in Java and ran some benchmarks and found that it ran dramatically faster than the Apache library implementation. This is a pretty straight forward implementation of the standard Cooley Tukey algorithm that I read out of a textbook. This passes all the Apache library test cases plus several I had written on my own. I created a source code library patch that preserves the public API completely while changing the internal implementation to achieve the performance improvement. In addition to the performance issue, I suggest that Discrete Fourier Transform functionality be provided as stateless pure functions (in Java this would be implemented with static methods) just like most other math functions. As-is, the library requires the user to instantiate a Transformer instance which maintains instance state, which is an unecessary complexity for a pure math function. I held off on this change since it would change the public API and affect existing code. However, I see similar backward compatability breaking API changes are already in the FastFourierTransformer class in the 3.0 code base. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-743) Use enums in package transform
[
https://issues.apache.org/jira/browse/MATH-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206041#comment-13206041
]
Sébastien Brisard commented on MATH-743:
In {{r1243009}}, {{DftNormalization}} has been changed to a top-level enum.
Use enums in package transform
--
Key: MATH-743
URL: https://issues.apache.org/jira/browse/MATH-743
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Labels: api-change, enum, transform
As discussed on the mailing-list, enums could be used in the package
{{transform}}
# An enumeration {{FORWARD, INVERSE}} will be created to specify whether the
inverse transform is to be computed. This will replace the pair
{{transform}}/{{inverseTransform}}
# An enumeration {{STANDARD, ORTHOGONAL}} will be introduced (where relevant)
in each transform class, in order to specify the normalization that should be
used. Then the factory methods {{create()}}/{{createOrthogonal()}} will be
replaced by a parameter passed to the constructor, which will be made public.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
