[jira] [Commented] (MATH-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[
https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13144927#comment-13144927
]
Sébastien Brisard commented on MATH-699:
I think Christian has a point here. The bracketing step is superfluous. I'll
propose a new impl getting rid of it, so that you can decide whether or not to
restore it.
However, we cannot forbit getDomainLowerBound() and getDomainUpperBound() to
return {{Double.POSITIVE_INFINITY}} (for {{p == 1}}) or
{{Double.NEGATIVE_INFINITY}} (for {{p == 0}}). I will prepare something along
these lines.
inverseCumulativeDistribution fails with cumulative distribution having a
plateau
-
Key: MATH-699
URL: https://issues.apache.org/jira/browse/MATH-699
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Priority: Minor
Attachments: AbstractContinuousDistributionTest.java
This bug report follows MATH-692. The attached unit test fails. As required
by the definition in MATH-692, the lower-bound of the interval on which the
cdf is constant should be returned. This is not so at the moment.
--
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-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13144933#comment-13144933 ] Phil Steitz commented on MATH-699: -- Be careful eliminating the bracketing step. IIRC it is in there to resolve a bug involving some corner case. In theory, the unit tests should pick up any regressions, but it would be a good idea to review the commit logs and issue reports for this class before ripping out the bracketing step. inverseCumulativeDistribution fails with cumulative distribution having a plateau - Key: MATH-699 URL: https://issues.apache.org/jira/browse/MATH-699 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Sébastien Brisard Assignee: Sébastien Brisard Priority: Minor Attachments: AbstractContinuousDistributionTest.java This bug report follows MATH-692. The attached unit test fails. As required by the definition in MATH-692, the lower-bound of the interval on which the cdf is constant should be returned. This is not so at the moment. -- 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-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13144939#comment-13144939 ] Sébastien Brisard commented on MATH-699: OK, thanks for the tip. I will do so. Sébastien inverseCumulativeDistribution fails with cumulative distribution having a plateau - Key: MATH-699 URL: https://issues.apache.org/jira/browse/MATH-699 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Sébastien Brisard Assignee: Sébastien Brisard Priority: Minor Attachments: AbstractContinuousDistributionTest.java This bug report follows MATH-692. The attached unit test fails. As required by the definition in MATH-692, the lower-bound of the interval on which the cdf is constant should be returned. This is not so at the moment. -- 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-462) Random Generator from Stable Distribution
[ https://issues.apache.org/jira/browse/MATH-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved MATH-462. -- Resolution: Fixed Patch with trivial formatting / doc changes committed in r1198165. Many thanks. Random Generator from Stable Distribution - Key: MATH-462 URL: https://issues.apache.org/jira/browse/MATH-462 Project: Commons Math Issue Type: New Feature Reporter: Pavel Ryzhov Assignee: Phil Steitz Priority: Minor Fix For: 3.0 Attachments: stable_rnd.patch Stable random generator based on Chambers-Mallows-Stuck method as it is described in Handbook of computational statistics: concepts and methods by James E. Gentle, Wolfgang Härdle, Yuichi Mori -- 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] (MATH-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13144939#comment-13144939 ] Sébastien Brisard edited comment on MATH-699 at 11/6/11 8:08 AM: - OK, thanks for the tip. I will do so. Sébastien Additional note: Phil, you are referring to r141391. This was 7 years, 3 months ago, you do have a good memory! Will look into that more closely. was (Author: celestin): OK, thanks for the tip. I will do so. Sébastien inverseCumulativeDistribution fails with cumulative distribution having a plateau - Key: MATH-699 URL: https://issues.apache.org/jira/browse/MATH-699 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Sébastien Brisard Assignee: Sébastien Brisard Priority: Minor Attachments: AbstractContinuousDistributionTest.java This bug report follows MATH-692. The attached unit test fails. As required by the definition in MATH-692, the lower-bound of the interval on which the cdf is constant should be returned. This is not so at the moment. -- 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 the APT to process Digester Annotations and generate RulesModule instances at compile-time
[
https://issues.apache.org/jira/browse/DIGESTER-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13144961#comment-13144961
]
Simone Tripodi commented on DIGESTER-158:
-
urgh, looks like I didn't pay attention to the fact it is not possible to
express more than one {{RetentionPolicy}} in annotations, and actually is set
to {{RetentionPolicy.RUNTIME}}.
An idea could be writing a compiler that has nothing to do with the APT...
Use the APT to process Digester Annotations and 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.2
Using the [APT
Tool|http://download.oracle.com/javase/1,5.0/docs/guide/apt/GettingStarted.html]
it would be possible 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
Re: [jira] [Commented] (MATH-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
Le 06/11/2011 07:34, Sébastien Brisard (Commented) (JIRA) a écrit : [ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13144939#comment-13144939 ] Sébastien Brisard commented on MATH-699: OK, thanks for the tip. I will do so. You can also identify a which revision a line was last changed by using svn blame. With luck, the last change will be a meaningful information. Luc Sébastien inverseCumulativeDistribution fails with cumulative distribution having a plateau - Key: MATH-699 URL: https://issues.apache.org/jira/browse/MATH-699 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Sébastien Brisard Assignee: Sébastien Brisard Priority: Minor Attachments: AbstractContinuousDistributionTest.java This bug report follows MATH-692. The attached unit test fails. As required by the definition in MATH-692, the lower-bound of the interval on which the cdf is constant should be returned. This is not so at the moment. -- 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
Re: [jira] [Commented] (MATH-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
You can also identify a which revision a line was last changed by using svn blame. With luck, the last change will be a meaningful information. Luc That's a good one too, thanks Luc. I really need to give read the SVN doc on my TODO list top priority... By the way, I like the choice of the blame keyword...
[jira] [Created] (BEANUTILS-406) DynaClassReader to read DynaClass definitions from a DSL
DynaClassReader to read DynaClass definitions from a DSL
--
Key: BEANUTILS-406
URL: https://issues.apache.org/jira/browse/BEANUTILS-406
Project: Commons BeanUtils
Issue Type: New Feature
Components: DynaBean
Affects Versions: 1.8.3
Reporter: Michael Vorburger
It could sometimes be very useful to create DynaClass definitions not only
programmatically (as is possible today), but to define data structures in some
textual format (a DSL), and load that into DynaClass/DynaProperty and create
DynaBeans from that.
This isn't very hard to add to BeanUtils (I've done it and will attach a patch)
and would allow the following usage, given:
{noformat}Address {
zip: java.lang.Long
}
Employee {
firstName : java.lang.String
lastName :java.lang.String
mainAddress : Address
boss : Employee
subordinates : Employee *
address : Address
}{noformat}
one could then use the new proposed DynaClassReader like so:
{noformat}DynaClassReader r = new DynaClassReader();
r.readClasspathResource(/DynaClassReaderTest.domain.txt);
DynaClass klass = r.getDynaClass(Employee);
{noformat}
This requires BEANUTILS-405.
--
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] (BEANUTILS-406) DynaClassReader to read DynaClass definitions from a DSL
[
https://issues.apache.org/jira/browse/BEANUTILS-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger updated BEANUTILS-406:
Attachment: 0002-BEANUTILS-406-DynaClassReader-to-read-DynaClass-defi.patch
Attached proposed patch. This builds on top of the two patches in
BEANUTILS-405.
Same also on
https://github.com/vorburger/apache-commons-beanutils/commits/domain-file-reader
- would be easier to contribute via BEANUTILS-404 ... ;-)
DynaClassReader to read DynaClass definitions from a DSL
--
Key: BEANUTILS-406
URL: https://issues.apache.org/jira/browse/BEANUTILS-406
Project: Commons BeanUtils
Issue Type: New Feature
Components: DynaBean
Affects Versions: 1.8.3
Reporter: Michael Vorburger
Attachments:
0002-BEANUTILS-406-DynaClassReader-to-read-DynaClass-defi.patch
It could sometimes be very useful to create DynaClass definitions not only
programmatically (as is possible today), but to define data structures in
some textual format (a DSL), and load that into DynaClass/DynaProperty and
create DynaBeans from that.
This isn't very hard to add to BeanUtils (I've done it and will attach a
patch) and would allow the following usage, given:
{noformat}Address {
zip: java.lang.Long
}
Employee {
firstName : java.lang.String
lastName :java.lang.String
mainAddress : Address
boss : Employee
subordinates : Employee *
address : Address
}{noformat}
one could then use the new proposed DynaClassReader like so:
{noformat}DynaClassReader r = new DynaClassReader();
r.readClasspathResource(/DynaClassReaderTest.domain.txt);
DynaClass klass = r.getDynaClass(Employee);
{noformat}
This requires BEANUTILS-405.
--
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] (BEANUTILS-405) DynaBean should support nested dynamic structures
[
https://issues.apache.org/jira/browse/BEANUTILS-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger updated BEANUTILS-405:
Attachment: 0001-BEANUTILS-405-related-minor-improvement-this-is-clea.patch
Attaching small additional patch, which makes sense for the API to be clearer
to use.
DynaBean should support nested dynamic structures
-
Key: BEANUTILS-405
URL: https://issues.apache.org/jira/browse/BEANUTILS-405
Project: Commons BeanUtils
Issue Type: New Feature
Components: DynaBean
Affects Versions: 1.8.3
Reporter: Michael Vorburger
Attachments:
0001-BEANUTILS-405-DynaBean-support-nested-dynamic-struct.patch,
0001-BEANUTILS-405-related-minor-improvement-this-is-clea.patch
It would be useful if DynaBean would have support for nested dynamic types,
like e.g. EMF and SDO have.
Currently simple types (or the content types of indexed or mapped types) must
be a Java language primitive (such as int, a simple object (such as a
java.lang.String), or a more complex object whose class is defined either by
the Java language. It turns out it wouldn't be very hard at all (I've tried
and will attach a patch) to make some minor changes to relax this, and in
addition also allow the following usage:
{noformat}DynaProperty[] adrProps = new DynaProperty[]{
new DynaProperty(zip, Long.class)
};
BasicDynaClass adrDynaClass = new BasicDynaClass(Address, adrProps);
DynaProperty[] empProps = new DynaProperty[]{
new DynaProperty(address, java.util.Map.class,
adrDynaClass),
new DynaProperty(subordinate, java.util.List.class,
DynaClass.class),
new DynaProperty(firstName, String.class),
new DynaProperty(lastName,String.class),
new DynaProperty(mainAddress, adrDynaClass),
new DynaProperty(boss,DynaClass.class)
};
BasicDynaClass empDynaClass = new BasicDynaClass(Employee,
empProps);
empDynaClass.getDynaProperty(boss).setDynaType(empDynaClass);
empDynaClass.getDynaProperty(subordinate).setDynaType(empDynaClass);
// ---
DynaBean address = adrDynaClass.newInstance();
address.set(zip, new Long(9016));
DynaBean subordinate = empDynaClass.newInstance();
subordinate.set(firstName, Dino);
DynaBean boss = empDynaClass.newInstance();
boss.set(firstName, Wilma);
DynaBean employee = empDynaClass.newInstance();
employee.set(firstName, Fred);
employee.set(lastName, Flintstone);
employee.set(mainAddress, address);
employee.set(boss, boss);
PropertyUtils.setProperty(employee, boss.lastName, Flintstone);
employee.set(address, new HashMap());
PropertyUtils.setProperty(employee, address(home), address);
employee.set(subordinate, new ArrayList());
((List)employee.get(subordinate)).add(subordinate);
{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] [Commented] (DIGESTER-158) Use the APT to process Digester Annotations and generate RulesModule instances at compile-time
[
https://issues.apache.org/jira/browse/DIGESTER-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145019#comment-13145019
]
Matt Benson commented on DIGESTER-158:
--
If it would indeed be a problem to have a precompiled {{RulesModule}} for which
there are available corresponding Digester annotations at runtime, can you get
around it with a wrapper annotation? i.e., is there a class-level annotation
required to trigger the runtime behavior? If so, couldn't you make *that*
annotation an element of a compile-time-retention annotation, thus preventing
the trigger annotation's runtime availability?
Use the APT to process Digester Annotations and 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.2
Using the [APT
Tool|http://download.oracle.com/javase/1,5.0/docs/guide/apt/GettingStarted.html]
it would be possible 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] [Updated] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-291: --- Attachment: io-291-simple.diff Attached is a much simpler implementation that works with: - Unrealized File objects - No recursion. Add new function FileUtils.isContained -- Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Fix For: 2.1 Attachments: FileUtils.isContained.patch, io-291-simple.diff, io-291.diff I added a function that determines whether the specified leaf is contains by the specified composite. -- 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] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-291: --- Attachment: (was: io-291-simple.diff) Add new function FileUtils.isContained -- Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Fix For: 2.1 Attachments: FileUtils.isContained.patch, io-291.diff I added a function that determines whether the specified leaf is contains by the specified composite. -- 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] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-291: --- Attachment: io-291-simple.diff Attached is a much simpler implementation that works with: - Unrealized File objects - No recursion. - Correct Javadoc Add new function FileUtils.isContained -- Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Fix For: 2.1 Attachments: FileUtils.isContained.patch, io-291-simple.diff, io-291.diff I added a function that determines whether the specified leaf is contains by the specified composite. -- 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] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-291: --- Attachment: io-291-simple.diff Attached is a much simpler implementation that works with: - Unrealized File objects - No recursion. - Correct Javadoc - No tabs. Add new function FileUtils.isContained -- Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Fix For: 2.1 Attachments: FileUtils.isContained.patch, io-291-simple.diff, io-291.diff I added a function that determines whether the specified leaf is contains by the specified composite. -- 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] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-291: --- Attachment: (was: io-291-simple.diff) Add new function FileUtils.isContained -- Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Fix For: 2.1 Attachments: FileUtils.isContained.patch, io-291-simple.diff, io-291.diff I added a function that determines whether the specified leaf is contains by the specified composite. -- 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 the APT to process Digester Annotations and generate RulesModule instances at compile-time
[
https://issues.apache.org/jira/browse/DIGESTER-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145040#comment-13145040
]
Simone Tripodi commented on DIGESTER-158:
-
Thanks for the feedbacks Matt! :)
What it is still not clear to me about APT is that {{RetentionPolicy.RUNTIME}}
annotation are visible to {{apt}} tool.
I wouldn't worry they are available at runtime as well since they are not
processed unless users explicitly require loading them via the appropriate
module.
As you understand, I'm an {{apt}} newbie... :P
Use the APT to process Digester Annotations and 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.2
Using the [APT
Tool|http://download.oracle.com/javase/1,5.0/docs/guide/apt/GettingStarted.html]
it would be possible 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] (VFS-381) Iterate over a FileObject using the Java foreach statement, to provide all descendents of a FileObject.
Iterate over a FileObject using the Java foreach statement, to provide all descendents of a FileObject. - Key: VFS-381 URL: https://issues.apache.org/jira/browse/VFS-381 Project: Commons VFS Issue Type: New Feature Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) Maven home: C:\Java\apache-maven-3.0.3\bin\.. Java version: 1.6.0_29, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_29\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary D. Gregory Assignee: Gary D. Gregory Fix For: Nightly Builds Iterate over a FileObject using the Java foreach statement, to provide all descendents of a FileObject. -- 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] (VFS-381) Iterate over a FileObject using the Java foreach statement, to provide all descendents of a FileObject.
[ https://issues.apache.org/jira/browse/VFS-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved VFS-381. - Resolution: Fixed Committed revision 1198524. Iterate over a FileObject using the Java foreach statement, to provide all descendents of a FileObject. - Key: VFS-381 URL: https://issues.apache.org/jira/browse/VFS-381 Project: Commons VFS Issue Type: New Feature Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) Maven home: C:\Java\apache-maven-3.0.3\bin\.. Java version: 1.6.0_29, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_29\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary D. Gregory Assignee: Gary D. Gregory Fix For: Nightly Builds Iterate over a FileObject using the Java foreach statement, to provide all descendents of a FileObject. -- 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] (VFS-371) Add FileObject API deleteAll()
[
https://issues.apache.org/jira/browse/VFS-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-371:
Summary: Add FileObject API deleteAll() (was: Add FileObject API
deleteAllDescendents())
Add FileObject API deleteAll()
--
Key: VFS-371
URL: https://issues.apache.org/jira/browse/VFS-371
Project: Commons VFS
Issue Type: New Feature
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
Maven home: C:\Java\apache-maven-3.0.3\bin\..
Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_29\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows
Reporter: Gary D. Gregory
Fix For: 2.1
Attachments: FileObject-deleteAllDescendents.diff
I see a lot of call sites within VFS 2 and some in my work server that do:
{code:java}
fileObject.delete(Selectors.SELECT_ALL);
{code}
It therefore seems like a sensible refactoring.
Add to {{FileObject}}:
{code:java}
/**
* Deletes all descendents of this file.
* Does nothing if this file does not exist.
* Shorthand for {@code delete(Selectors.Selectors.SELECT_ALL)}
* p/
* pThis method is not transactional. If it fails and throws an
* exception, this file will potentially only be partially deleted.
*
* @return the number of deleted objects
* @throws FileSystemException If this file or one of its descendents is
read-only, or on error
* deleting this file or one of its
descendents.
*/
int deleteAllDescendents() throws FileSystemException;
{code}
And to {{AbstractFileObject}}:
{code:java}
/**
* Deletes this file, and all children.
*
* @return the number of deleted files.
* @throws FileSystemException if an error occurs.
*/
public int deleteAllDescendents() throws FileSystemException
{
return this.delete(Selectors.SELECT_ALL);
}
{code}
Thoughts?
Attaching patch.
--
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 the APT to process Digester Annotations and generate RulesModule instances at compile-time
[
https://issues.apache.org/jira/browse/DIGESTER-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145064#comment-13145064
]
Matt Benson commented on DIGESTER-158:
--
I've only used the APT a tiny bit as well... not sure I've even tried to use
the code I wrote, TBH. That said, I still don't *think* there's any reason the
processor wouldn't be able to see the RT-retention annotations if that's all
you're worried about.
Use the APT to process Digester Annotations and 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.2
Using the [APT
Tool|http://download.oracle.com/javase/1,5.0/docs/guide/apt/GettingStarted.html]
it would be possible 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] [Updated] (VFS-371) Add FileObject API deleteAll()
[
https://issues.apache.org/jira/browse/VFS-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-371:
Description:
I see a lot of call sites within VFS 2 and some in my work server that do:
{code:java}
fileObject.delete(Selectors.SELECT_ALL);
{code}
It therefore seems like a sensible refactoring.
Add to {{FileObject}}:
{code:java}
/**
* Deletes all descendents of this file.
* Does nothing if this file does not exist.
* Shorthand for {@code delete(Selectors.Selectors.SELECT_ALL)}
* p/
* pThis method is not transactional. If it fails and throws an
* exception, this file will potentially only be partially deleted.
*
* @return the number of deleted objects
* @throws FileSystemException If this file or one of its descendents is
read-only, or on error
* deleting this file or one of its descendents.
*/
int deleteAll() throws FileSystemException;
{code}
And to {{AbstractFileObject}}:
{code:java}
/**
* Deletes this file, and all children.
*
* @return the number of deleted files.
* @throws FileSystemException if an error occurs.
*/
public int deleteAllDescendents() throws FileSystemException
{
return this.delete(Selectors.SELECT_ALL);
}
{code}
Thoughts?
Attaching patch.
was:
I see a lot of call sites within VFS 2 and some in my work server that do:
{code:java}
fileObject.delete(Selectors.SELECT_ALL);
{code}
It therefore seems like a sensible refactoring.
Add to {{FileObject}}:
{code:java}
/**
* Deletes all descendents of this file.
* Does nothing if this file does not exist.
* Shorthand for {@code delete(Selectors.Selectors.SELECT_ALL)}
* p/
* pThis method is not transactional. If it fails and throws an
* exception, this file will potentially only be partially deleted.
*
* @return the number of deleted objects
* @throws FileSystemException If this file or one of its descendents is
read-only, or on error
* deleting this file or one of its descendents.
*/
int deleteAllDescendents() throws FileSystemException;
{code}
And to {{AbstractFileObject}}:
{code:java}
/**
* Deletes this file, and all children.
*
* @return the number of deleted files.
* @throws FileSystemException if an error occurs.
*/
public int deleteAllDescendents() throws FileSystemException
{
return this.delete(Selectors.SELECT_ALL);
}
{code}
Thoughts?
Attaching patch.
Add FileObject API deleteAll()
--
Key: VFS-371
URL: https://issues.apache.org/jira/browse/VFS-371
Project: Commons VFS
Issue Type: New Feature
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
Maven home: C:\Java\apache-maven-3.0.3\bin\..
Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_29\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows
Reporter: Gary D. Gregory
Fix For: 2.1
Attachments: FileObject-deleteAllDescendents.diff
I see a lot of call sites within VFS 2 and some in my work server that do:
{code:java}
fileObject.delete(Selectors.SELECT_ALL);
{code}
It therefore seems like a sensible refactoring.
Add to {{FileObject}}:
{code:java}
/**
* Deletes all descendents of this file.
* Does nothing if this file does not exist.
* Shorthand for {@code delete(Selectors.Selectors.SELECT_ALL)}
* p/
* pThis method is not transactional. If it fails and throws an
* exception, this file will potentially only be partially deleted.
*
* @return the number of deleted objects
* @throws FileSystemException If this file or one of its descendents is
read-only, or on error
* deleting this file or one of its
descendents.
*/
int deleteAll() throws FileSystemException;
{code}
And to {{AbstractFileObject}}:
{code:java}
/**
* Deletes this file, and all children.
*
* @return the number of deleted files.
* @throws FileSystemException if an error occurs.
*/
public int deleteAllDescendents() throws FileSystemException
{
return this.delete(Selectors.SELECT_ALL);
}
{code}
Thoughts?
Attaching patch.
--
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-371) Add FileObject API deleteAll()
[
https://issues.apache.org/jira/browse/VFS-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145066#comment-13145066
]
Gary D. Gregory commented on VFS-371:
-
I'm going with {{deleteAll()}} for the name.
Add FileObject API deleteAll()
--
Key: VFS-371
URL: https://issues.apache.org/jira/browse/VFS-371
Project: Commons VFS
Issue Type: New Feature
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
Maven home: C:\Java\apache-maven-3.0.3\bin\..
Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_29\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows
Reporter: Gary D. Gregory
Fix For: 2.1
Attachments: FileObject-deleteAllDescendents.diff
I see a lot of call sites within VFS 2 and some in my work server that do:
{code:java}
fileObject.delete(Selectors.SELECT_ALL);
{code}
It therefore seems like a sensible refactoring.
Add to {{FileObject}}:
{code:java}
/**
* Deletes all descendents of this file.
* Does nothing if this file does not exist.
* Shorthand for {@code delete(Selectors.Selectors.SELECT_ALL)}
* p/
* pThis method is not transactional. If it fails and throws an
* exception, this file will potentially only be partially deleted.
*
* @return the number of deleted objects
* @throws FileSystemException If this file or one of its descendents is
read-only, or on error
* deleting this file or one of its
descendents.
*/
int deleteAll() throws FileSystemException;
{code}
And to {{AbstractFileObject}}:
{code:java}
/**
* Deletes this file, and all children.
*
* @return the number of deleted files.
* @throws FileSystemException if an error occurs.
*/
public int deleteAllDescendents() throws FileSystemException
{
return this.delete(Selectors.SELECT_ALL);
}
{code}
Thoughts?
Attaching patch.
--
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] (VFS-371) Add FileObject API deleteAll()
[
https://issues.apache.org/jira/browse/VFS-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved VFS-371.
-
Resolution: Fixed
Fix Version/s: Nightly Builds
Assignee: Gary D. Gregory
Committed revision 1198532.
Add FileObject API deleteAll()
--
Key: VFS-371
URL: https://issues.apache.org/jira/browse/VFS-371
Project: Commons VFS
Issue Type: New Feature
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
Maven home: C:\Java\apache-maven-3.0.3\bin\..
Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_29\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows
Reporter: Gary D. Gregory
Assignee: Gary D. Gregory
Fix For: Nightly Builds, 2.1
Attachments: FileObject-deleteAllDescendents.diff
I see a lot of call sites within VFS 2 and some in my work server that do:
{code:java}
fileObject.delete(Selectors.SELECT_ALL);
{code}
It therefore seems like a sensible refactoring.
Add to {{FileObject}}:
{code:java}
/**
* Deletes all descendents of this file.
* Does nothing if this file does not exist.
* Shorthand for {@code delete(Selectors.Selectors.SELECT_ALL)}
* p/
* pThis method is not transactional. If it fails and throws an
* exception, this file will potentially only be partially deleted.
*
* @return the number of deleted objects
* @throws FileSystemException If this file or one of its descendents is
read-only, or on error
* deleting this file or one of its
descendents.
*/
int deleteAll() throws FileSystemException;
{code}
And to {{AbstractFileObject}}:
{code:java}
/**
* Deletes this file, and all children.
*
* @return the number of deleted files.
* @throws FileSystemException if an error occurs.
*/
public int deleteAllDescendents() throws FileSystemException
{
return this.delete(Selectors.SELECT_ALL);
}
{code}
Thoughts?
Attaching patch.
--
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 the APT to process Digester Annotations and generate RulesModule instances at compile-time
[
https://issues.apache.org/jira/browse/DIGESTER-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145088#comment-13145088
]
Simone Tripodi commented on DIGESTER-158:
-
As far as you know, does the {{apt}} have a tool to generate Java sources or
users have to use a 3rd part template engine, such as {{Velocity}}?
Many thanks in advance!
Use the APT to process Digester Annotations and 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.2
Using the [APT
Tool|http://download.oracle.com/javase/1,5.0/docs/guide/apt/GettingStarted.html]
it would be possible 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] (BEANUTILS-407) DynaBean Byte Code generation, for interoperability
DynaBean Byte Code generation, for interoperability - Key: BEANUTILS-407 URL: https://issues.apache.org/jira/browse/BEANUTILS-407 Project: Commons BeanUtils Issue Type: New Feature Components: DynaBean Affects Versions: 1.8.3 Reporter: Michael Vorburger Priority: Critical It would be very very cool if DynaBeans could be used with any framework doing reflection - not only the specially DynaBean-aware BeanUtils. It turns out that using CGLIB this would be possible, I've tried and will attach a patch. -- 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] (BEANUTILS-407) DynaBean Byte Code generation, for interoperability
[ https://issues.apache.org/jira/browse/BEANUTILS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger updated BEANUTILS-407: Attachment: 0001-BEANUTILS-407-DynaBean-Byte-Code-generation.patch Attached proposed patch. Same also on https://github.com/vorburger/apache-commons-beanutils/compare/master...bytecodefun (would be easier with BEANUTILS-404...) Usage see in proposed doc on https://github.com/vorburger/apache-commons-beanutils/commit/85322280b3f981a3b3221d3ee414d5a52658b89d#src/main/java/org/apache/commons/beanutils/package.html DynaBean Byte Code generation, for interoperability - Key: BEANUTILS-407 URL: https://issues.apache.org/jira/browse/BEANUTILS-407 Project: Commons BeanUtils Issue Type: New Feature Components: DynaBean Affects Versions: 1.8.3 Reporter: Michael Vorburger Priority: Critical Attachments: 0001-BEANUTILS-407-DynaBean-Byte-Code-generation.patch It would be very very cool if DynaBeans could be used with any framework doing reflection - not only the specially DynaBean-aware BeanUtils. It turns out that using CGLIB this would be possible, I've tried and will attach a patch. -- 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] (BEANUTILS-406) DynaClassReader to read DynaClass definitions from a DSL
[
https://issues.apache.org/jira/browse/BEANUTILS-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145100#comment-13145100
]
Michael Vorburger commented on BEANUTILS-406:
-
This would probably still need a few lines of new doc about it in the
src\main\java\overview.html (like I've provided for BEANUTILS-405
BEANUTILS-407).
DynaClassReader to read DynaClass definitions from a DSL
--
Key: BEANUTILS-406
URL: https://issues.apache.org/jira/browse/BEANUTILS-406
Project: Commons BeanUtils
Issue Type: New Feature
Components: DynaBean
Affects Versions: 1.8.3
Reporter: Michael Vorburger
Attachments:
0002-BEANUTILS-406-DynaClassReader-to-read-DynaClass-defi.patch
It could sometimes be very useful to create DynaClass definitions not only
programmatically (as is possible today), but to define data structures in
some textual format (a DSL), and load that into DynaClass/DynaProperty and
create DynaBeans from that.
This isn't very hard to add to BeanUtils (I've done it and will attach a
patch) and would allow the following usage, given:
{noformat}Address {
zip: java.lang.Long
}
Employee {
firstName : java.lang.String
lastName :java.lang.String
mainAddress : Address
boss : Employee
subordinates : Employee *
address : Address
}{noformat}
one could then use the new proposed DynaClassReader like so:
{noformat}DynaClassReader r = new DynaClassReader();
r.readClasspathResource(/DynaClassReaderTest.domain.txt);
DynaClass klass = r.getDynaClass(Employee);
{noformat}
This requires BEANUTILS-405.
--
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] (BEANUTILS-406) DynaClassReader to read DynaClass definitions from a DSL
[
https://issues.apache.org/jira/browse/BEANUTILS-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145100#comment-13145100
]
Michael Vorburger edited comment on BEANUTILS-406 at 11/6/11 8:56 PM:
--
This would probably still need a few lines of new doc about it in the
src\main\java\org\apache\commons\beanutils\package.html (like I've provided for
BEANUTILS-405 BEANUTILS-407).
was (Author: vorburger):
This would probably still need a few lines of new doc about it in the
src\main\java\overview.html (like I've provided for BEANUTILS-405
BEANUTILS-407).
DynaClassReader to read DynaClass definitions from a DSL
--
Key: BEANUTILS-406
URL: https://issues.apache.org/jira/browse/BEANUTILS-406
Project: Commons BeanUtils
Issue Type: New Feature
Components: DynaBean
Affects Versions: 1.8.3
Reporter: Michael Vorburger
Attachments:
0002-BEANUTILS-406-DynaClassReader-to-read-DynaClass-defi.patch
It could sometimes be very useful to create DynaClass definitions not only
programmatically (as is possible today), but to define data structures in
some textual format (a DSL), and load that into DynaClass/DynaProperty and
create DynaBeans from that.
This isn't very hard to add to BeanUtils (I've done it and will attach a
patch) and would allow the following usage, given:
{noformat}Address {
zip: java.lang.Long
}
Employee {
firstName : java.lang.String
lastName :java.lang.String
mainAddress : Address
boss : Employee
subordinates : Employee *
address : Address
}{noformat}
one could then use the new proposed DynaClassReader like so:
{noformat}DynaClassReader r = new DynaClassReader();
r.readClasspathResource(/DynaClassReaderTest.domain.txt);
DynaClass klass = r.getDynaClass(Employee);
{noformat}
This requires BEANUTILS-405.
--
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] (BEANUTILS-407) DynaBean Byte Code generation, for interoperability
[ https://issues.apache.org/jira/browse/BEANUTILS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145110#comment-13145110 ] Michael Vorburger commented on BEANUTILS-407: - BEANUTILS-405, which is per se unrelated to this, may have a follow-up impact on this, for consistency: Users would probably expect that the wrapper turn a normal DynaBean returned from get() into a wrapped one as well? DynaBean Byte Code generation, for interoperability - Key: BEANUTILS-407 URL: https://issues.apache.org/jira/browse/BEANUTILS-407 Project: Commons BeanUtils Issue Type: New Feature Components: DynaBean Affects Versions: 1.8.3 Reporter: Michael Vorburger Priority: Critical Attachments: 0001-BEANUTILS-407-DynaBean-Byte-Code-generation.patch It would be very very cool if DynaBeans could be used with any framework doing reflection - not only the specially DynaBean-aware BeanUtils. It turns out that using CGLIB this would be possible, I've tried and will attach a patch. -- 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] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145123#comment-13145123 ] Pier-Luc Caron St-Pierre commented on IO-291: - Thanks for you input. The initial use case is that I am exposing all the content of a folder to my user by a web service. I trust the lib to sanitize correctly the parameters, but I am afraid that my function will be used by my coworker in other context. * I have make some coding style fix in the io-291-v4.patch. * I have removed the author tag. Add new function FileUtils.isContained -- Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Fix For: 2.1 Attachments: FileUtils.isContained.patch, io-291-simple.diff, io-291.diff I added a function that determines whether the specified leaf is contains by the specified composite. -- 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] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145123#comment-13145123 ] Pier-Luc Caron St-Pierre edited comment on IO-291 at 11/6/11 9:42 PM: -- Thanks for you input. The initial use case is that I am exposing all the content of a folder to my user by a web service. I trust the lib to sanitize correctly the parameters, but I am afraid that my function will be used by my coworker in other context. * I have make some coding style fix in the io-291-simple.patch. * I have removed the author tag. was (Author: plcstpierre): Thanks for you input. The initial use case is that I am exposing all the content of a folder to my user by a web service. I trust the lib to sanitize correctly the parameters, but I am afraid that my function will be used by my coworker in other context. * I have make some coding style fix in the io-291-v4.patch. * I have removed the author tag. Add new function FileUtils.isContained -- Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Fix For: 2.1 Attachments: FileUtils.isContained.patch, io-291-simple.diff, io-291-v4.patch, io-291.diff I added a function that determines whether the specified leaf is contains by the specified composite. -- 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] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pier-Luc Caron St-Pierre updated IO-291: Attachment: io-291-v4.patch Add new function FileUtils.isContained -- Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Fix For: 2.1 Attachments: FileUtils.isContained.patch, io-291-simple.diff, io-291-v4.patch, io-291.diff I added a function that determines whether the specified leaf is contains by the specified composite. -- 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] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145123#comment-13145123 ] Pier-Luc Caron St-Pierre edited comment on IO-291 at 11/6/11 9:49 PM: -- Thanks for you input. The initial use case is that I am exposing all the content of a folder to my user by a web service. I trust the lib to sanitize correctly the parameters, but I am afraid that my function will be used in other context. * I have make some coding style fix in the io-291-simple.patch. * I have removed the author tag. was (Author: plcstpierre): Thanks for you input. The initial use case is that I am exposing all the content of a folder to my user by a web service. I trust the lib to sanitize correctly the parameters, but I am afraid that my function will be used by my coworker in other context. * I have make some coding style fix in the io-291-simple.patch. * I have removed the author tag. Add new function FileUtils.isContained -- Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Fix For: 2.1 Attachments: FileUtils.isContained.patch, io-291-simple.diff, io-291-v4.patch, io-291.diff I added a function that determines whether the specified leaf is contains by the specified composite. -- 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] (OGNL-38) [PATCH] Use StringBuilder instead of StringBuffer, deprecate =JDK1.5 conditionals and use CONSTANT.equals(variable).
[ https://issues.apache.org/jira/browse/OGNL-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Cumiskey updated OGNL-38: Attachment: patch-OGNL38.txt [PATCH] Use StringBuilder instead of StringBuffer, deprecate =JDK1.5 conditionals and use CONSTANT.equals(variable). - Key: OGNL-38 URL: https://issues.apache.org/jira/browse/OGNL-38 Project: OGNL Issue Type: Improvement Reporter: Adrian Cumiskey Priority: Minor Attachments: patch-OGNL38.txt This patch replaces all StringBuffer references with StringBuilder for better performance. Improved performance has not been verified but it is fairly well established that StringBuilder performs better in single threaded use cases (see http://littletutorials.com/2008/07/16/stringbuffer-vs-stringbuilder-performance-comparison/). All JDK1.5 checking has also been deprecated/removed since OGNL is now dependent upon =JDK1.5 these days. Lastly, all remaining variable.equals(CONSTANT) has been flipped to the null safe CONSTANT.equals(variable). A list of modified classes and changes are given here :- MenuItem: toString() now uses a chained StringBuilder instead of StringBuffer. StaticsAndConstructorsTest: use StringBuilder instead of StringBuffer. EnumerationPropertyAccessor: Test CONSTANT.equals(variable). ExpressionCompiler: Test CONSTANT.equals(variable). ASTMethod: Variable naming (don't use acronyms), remove OgnlRuntime.isJdk15() check. OgnlRuntime: * Remove JDK1.5 checking since OGNL now requires =JDK1.5. * The isJdk15() method is now deprecated. * Variable naming (don't use acronyms. * getPointerString(int) now uses StringBuilder instead of StringBuffer. * getUniqueDescriptor(Object, boolean) now uses StringBuilder instead of StringBuffer. * package private method findType() unused to removed. * Simplify getMethods(Class?,boolean) with ternary. * getStaticField(OgnlContext,String,String) test CONSTANT.equals(variable) and remove JDK1.5 conditionals. * A lot of variable naming! SetPropertyAccessor: Test CONSTANT.equals(variable) and simplify conditionals. ASTStaticField: Test CONSTANT.equals(variable), remove JDK1.5 conditionals and variable naming. MapPropertyAccessor: Simplify conditionals. ArrayPropertyAccessor: Test CONSTANT.equals(variable). IteratorPropertyAccessor: Test CONSTANT.equals(variable). OgnlOps: Use StringBuilder instead of StringBuffer. ognl.jjt: Variable naming, use StringBuilder instead of StringBuffer. Replace new String(stringBuffer) with stringBuffer.toString(). Cheers, Adrian. -- 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] (OGNL-38) [PATCH] Use StringBuilder instead of StringBuffer, deprecate =JDK1.5 conditionals and use CONSTANT.equals(variable).
[PATCH] Use StringBuilder instead of StringBuffer, deprecate =JDK1.5 conditionals and use CONSTANT.equals(variable). - Key: OGNL-38 URL: https://issues.apache.org/jira/browse/OGNL-38 Project: OGNL Issue Type: Improvement Reporter: Adrian Cumiskey Priority: Minor Attachments: patch-OGNL38.txt This patch replaces all StringBuffer references with StringBuilder for better performance. Improved performance has not been verified but it is fairly well established that StringBuilder performs better in single threaded use cases (see http://littletutorials.com/2008/07/16/stringbuffer-vs-stringbuilder-performance-comparison/). All JDK1.5 checking has also been deprecated/removed since OGNL is now dependent upon =JDK1.5 these days. Lastly, all remaining variable.equals(CONSTANT) has been flipped to the null safe CONSTANT.equals(variable). A list of modified classes and changes are given here :- MenuItem: toString() now uses a chained StringBuilder instead of StringBuffer. StaticsAndConstructorsTest: use StringBuilder instead of StringBuffer. EnumerationPropertyAccessor: Test CONSTANT.equals(variable). ExpressionCompiler: Test CONSTANT.equals(variable). ASTMethod: Variable naming (don't use acronyms), remove OgnlRuntime.isJdk15() check. OgnlRuntime: * Remove JDK1.5 checking since OGNL now requires =JDK1.5. * The isJdk15() method is now deprecated. * Variable naming (don't use acronyms. * getPointerString(int) now uses StringBuilder instead of StringBuffer. * getUniqueDescriptor(Object, boolean) now uses StringBuilder instead of StringBuffer. * package private method findType() unused to removed. * Simplify getMethods(Class?,boolean) with ternary. * getStaticField(OgnlContext,String,String) test CONSTANT.equals(variable) and remove JDK1.5 conditionals. * A lot of variable naming! SetPropertyAccessor: Test CONSTANT.equals(variable) and simplify conditionals. ASTStaticField: Test CONSTANT.equals(variable), remove JDK1.5 conditionals and variable naming. MapPropertyAccessor: Simplify conditionals. ArrayPropertyAccessor: Test CONSTANT.equals(variable). IteratorPropertyAccessor: Test CONSTANT.equals(variable). OgnlOps: Use StringBuilder instead of StringBuffer. ognl.jjt: Variable naming, use StringBuilder instead of StringBuffer. Replace new String(stringBuffer) with stringBuffer.toString(). Cheers, Adrian. -- 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-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[
https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145211#comment-13145211
]
Sébastien Brisard commented on MATH-699:
Hi,
I thought I would keep you up to date with the problems I'm facing at the
moment.
First of all, I see no smart way to check that for sure,
{{inverseCumulativeProbability(0)}} (resp. {{inverseCumulativeProbability(1)}})
should return {{Double.NEGATIVE_INFINITY}} (resp.
{{Double.POSITIVE_INFINITY}}). What could be done would be to test for a
neighbouring value, and check that the cumulative probability is slightly above
zero (resp. below one). But this makes no sense, because the only neighbouring
value which would make sense would be {{+/-Double.MAX_VALUE}}, and this surely
return 0.0 or 1.0. So this is my first problem.
The way I see things is as follows: users might have no clue about the inverse
cumulative probability, but they *must* know the values of this inverse for p =
0 and p = 1. So I would suggest to change the contract of
{{getInitialDomain(p)}}. I would make clear in the javadoc that
{{getInitialDomain(p)}} should return {{Double.NEGATIVE_INFINITY}} *if, and
only if* {{inverseCumulativeProbability(0) == Double.NEGATIVE_INFINITY}}.
Similarly, {{getInitialDomain(p)}} should return {{Double.POSITIVE_INFINITY}}
*if, and only if* {{inverseCumulativeProbability(1) ==
Double.POSITIVE_INFINITY}}.
My second problem is to check for the presence of plateaux, consistently with
finite precision. Here is my initial idea. I first define the two absolute
accuracies
* {{dx = getSolverAbsoluteAccuracy()}},
* {{dp = getSolverFunctionValueAccuracy()}}.
Then, if {{x}} is the root found by the solver: we do have
{{cumulativeProbability( x ) == p}} (within a specified accuracy). The problem
is to check whether there is a *smaller* value which also satisfies this
requirement (in which case, the smallest such value must be returned).
My initial test was {{cumulativeProbability(x - dx) == p}}. Then, I tried
{{FastMath.abs(cumulativeProbability(x - dx) - p) = dp}}. Although more
consistent with finite precision, this is not fully satisfactory, because in
simple cases (where there is no plateau), it might lead to the solver moving to
a somewhat less good point. At the very least, it would lead to additional
iterations... to finally get back to the initial point {{x}}.
Then, I thought of checking for *exact* nullity of the pdf at x. The problem is
that the pdf might have discontinuities, in which case, this simple test might
fail (if {{x}} turns out to be the higher-end of the plateau, and there is a
slope discontinuity here).
So, I'm now back to this test: {{cumulativeProbability(x - dx) ==
cumulativeProbability( x )}}. Please note
* *exact* equality test,
* I'm no longer testing for equality with the target value {{p}}, but with its
estimate {{cumulativeProbability( x )}}.
I would be grateful for some feedback on these issues. Also, I think it is
clear that
* my code will require careful reviewers!!!
* it won't be completely fool-proof.
inverseCumulativeDistribution fails with cumulative distribution having a
plateau
-
Key: MATH-699
URL: https://issues.apache.org/jira/browse/MATH-699
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Priority: Minor
Attachments: AbstractContinuousDistributionTest.java
This bug report follows MATH-692. The attached unit test fails. As required
by the definition in MATH-692, the lower-bound of the interval on which the
cdf is constant should be returned. This is not so at the moment.
--
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
