[jira] [Created] (MATH-638) "&" instead of "&&" in "SingularValueDecompositionImpl"
"&" instead of "&&" in "SingularValueDecompositionImpl" --- Key: MATH-638 URL: https://issues.apache.org/jira/browse/MATH-638 Project: Commons Math Issue Type: Improvement Reporter: Gilles Assignee: Gilles Priority: Trivial Fix For: 3.0 Findbugs signalled the use of the not short-circuit logical operator "&". -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-638) "&" instead of "&&" in "SingularValueDecompositionImpl"
[ https://issues.apache.org/jira/browse/MATH-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-638. - Resolution: Fixed Revision 1152462. > "&" instead of "&&" in "SingularValueDecompositionImpl" > --- > > Key: MATH-638 > URL: https://issues.apache.org/jira/browse/MATH-638 > Project: Commons Math > Issue Type: Improvement >Reporter: Gilles >Assignee: Gilles >Priority: Trivial > Fix For: 3.0 > > > Findbugs signalled the use of the not short-circuit logical operator "&". -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated DBUTILS-78: - Attachment: AsyncQueryRunner.java > Add asynchronous batch, query, and update calls > --- > > Key: DBUTILS-78 > URL: https://issues.apache.org/jira/browse/DBUTILS-78 > Project: Commons DbUtils > Issue Type: New Feature >Reporter: William R. Speirs >Priority: Minor > Fix For: 1.4 > > Attachments: AsyncQueryRunner.java, AsyncQueryRunnerTest.java > > > I propose a new QueryRunner class, AsyncQueryRunner, which changes the return > type of batch, query, and update methods. Instead of returning their > respective return types, the methods would return a RunnableFuture. This > would allow callers to either execute the RunnableFuture in a thread or via > an CompletionService like the ExecutorCompletionService. > I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated DBUTILS-78: - Attachment: (was: AsyncQueryRunner.java) > Add asynchronous batch, query, and update calls > --- > > Key: DBUTILS-78 > URL: https://issues.apache.org/jira/browse/DBUTILS-78 > Project: Commons DbUtils > Issue Type: New Feature >Reporter: William R. Speirs >Priority: Minor > Fix For: 1.4 > > Attachments: AsyncQueryRunner.java, AsyncQueryRunnerTest.java > > > I propose a new QueryRunner class, AsyncQueryRunner, which changes the return > type of batch, query, and update methods. Instead of returning their > respective return types, the methods would return a RunnableFuture. This > would allow callers to either execute the RunnableFuture in a thread or via > an CompletionService like the ExecutorCompletionService. > I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated DBUTILS-78: - Attachment: AsyncQueryRunnerTest.java > Add asynchronous batch, query, and update calls > --- > > Key: DBUTILS-78 > URL: https://issues.apache.org/jira/browse/DBUTILS-78 > Project: Commons DbUtils > Issue Type: New Feature >Reporter: William R. Speirs >Priority: Minor > Fix For: 1.4 > > Attachments: AsyncQueryRunner.java, AsyncQueryRunnerTest.java > > > I propose a new QueryRunner class, AsyncQueryRunner, which changes the return > type of batch, query, and update methods. Instead of returning their > respective return types, the methods would return a RunnableFuture. This > would allow callers to either execute the RunnableFuture in a thread or via > an CompletionService like the ExecutorCompletionService. > I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073197#comment-13073197 ] William R. Speirs commented on DBUTILS-78: -- I wrote unit tests for the AsyncQueryRunner code. I am getting 73% coverage over the AsyncQueryRunner class. The only things that are not covered are a few exceptions in a few places; however, all methods are covered. I also replaced the version of my AsyncQueryRunner code after fixing numerous bugs I found while writing the unit tests. > Add asynchronous batch, query, and update calls > --- > > Key: DBUTILS-78 > URL: https://issues.apache.org/jira/browse/DBUTILS-78 > Project: Commons DbUtils > Issue Type: New Feature >Reporter: William R. Speirs >Priority: Minor > Fix For: 1.4 > > Attachments: AsyncQueryRunner.java, AsyncQueryRunnerTest.java > > > I propose a new QueryRunner class, AsyncQueryRunner, which changes the return > type of batch, query, and update methods. Instead of returning their > respective return types, the methods would return a RunnableFuture. This > would allow callers to either execute the RunnableFuture in a thread or via > an CompletionService like the ExecutorCompletionService. > I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-79) fillStatement doesn't complain when there are too few parameters
[ https://issues.apache.org/jira/browse/DBUTILS-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073198#comment-13073198 ] William R. Speirs commented on DBUTILS-79: -- See DBUTILS-78, it has an updated version of the fillStatement function which properly checks to see that the number of parameters passed in matches the number of parameters required by the statement. > fillStatement doesn't complain when there are too few parameters > > > Key: DBUTILS-79 > URL: https://issues.apache.org/jira/browse/DBUTILS-79 > Project: Commons DbUtils > Issue Type: Bug >Affects Versions: 1.3 >Reporter: William R. Speirs > Fix For: 1.4 > > > Unless I'm reading the code incorrectly, it appears that the fillStatement > function does not complain if you provide too few parameters. For example, if > you supply an SQL statement like: select * from blah where ? = ?; but only > provide a single parameter "test", fillStatement returns without issue. > However, only the first ? is actually set. > Granted, this will almost always cause an exception to be thrown by the > driver, but since there is already a check for too many parameters, why not > check for too few as well? > (FYI: I came across this bug, and a few others in my AsyncQueryRunner > implementation, while re-writing the unit tests to use Mockito.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-53) Set Derby up as a unit test database
[ https://issues.apache.org/jira/browse/DBUTILS-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073203#comment-13073203 ] William R. Speirs commented on DBUTILS-53: -- See DBUTILS-78 for an updated unit test which covers 73% of the AsyncQueryRunner class. These unit tests should be easily adapted to cover QueryRunner. These unit tests also ensure that the ResultSet and PreparedStatement are always closed, and the Connection closed only when it is supposed to be. > Set Derby up as a unit test database > > > Key: DBUTILS-53 > URL: https://issues.apache.org/jira/browse/DBUTILS-53 > Project: Commons DbUtils > Issue Type: Task >Reporter: Henri Yandell > > Or hsqldb. I used Derby for Taglibs to test the sql tags and it worked well > enough. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CONFIGURATION-457) Escape only unicode characters not supported by the file encoding
Escape only unicode characters not supported by the file encoding - Key: CONFIGURATION-457 URL: https://issues.apache.org/jira/browse/CONFIGURATION-457 Project: Commons Configuration Issue Type: Improvement Components: Format Affects Versions: 1.6 Reporter: Emmanuel Bourg Priority: Minor Fix For: 1.7 A non ASCII character is always escaped in a PropertiesConfiguration, even if the encoding selected supports it. It can make the properties file difficult to read and edit manually, especially for non latin languages. This issue was found on Stack Overflow: http://stackoverflow.com/questions/5661315 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-637) Simple utility for micro-benchmarking
[ https://issues.apache.org/jira/browse/MATH-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073257#comment-13073257 ] Gilles commented on MATH-637: - Revision 1152524 contains significant changes that aim to thwart some of the criticisms discussed [here|http://blog.juma.me.uk/2011/02/23/performance-of-fastmath-from-commons-math/]. Please review. > Simple utility for micro-benchmarking > - > > Key: MATH-637 > URL: https://issues.apache.org/jira/browse/MATH-637 > Project: Commons Math > Issue Type: Wish >Reporter: Gilles >Assignee: Gilles >Priority: Minor > Labels: test > Fix For: 3.0 > > > As per the discussion on the "dev" ML (with subject: "Simple benchmarking > utility"), it would be useful to have an easy way to benchmark alternative > implementations of some functionality. > The proposed utility methods will be collected in a class located in the > "src/test/java" part of the code repository. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-637) Simple utility for micro-benchmarking
[ https://issues.apache.org/jira/browse/MATH-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-637: - Attachment: PerfUtils.patch One thing to think about is whether we really want / need to store all of the timing results in an array. The times array could get quite large if the number of iterations is very large. The attached patch prepares for eventual move to just streaming the execution times by changing the statistical aggregator from DescriptiveStatistics to SummaryStatistics. The latter does not store velues in memory. The patch also replaces the array of DescriptiveStatistics describing method results with an array of StatisticalSummary instances. The latter are immutable value objects that just maintain values of statistics. These changes should probably be made even if we decide to hold the full time array in storage, since the current impl is needlessly storing the raw data again inside the DescriptiveStatistics instances and all you really need to store is the result of the statistical analysis. > Simple utility for micro-benchmarking > - > > Key: MATH-637 > URL: https://issues.apache.org/jira/browse/MATH-637 > Project: Commons Math > Issue Type: Wish >Reporter: Gilles >Assignee: Gilles >Priority: Minor > Labels: test > Fix For: 3.0 > > Attachments: PerfUtils.patch > > > As per the discussion on the "dev" ML (with subject: "Simple benchmarking > utility"), it would be useful to have an easy way to benchmark alternative > implementations of some functionality. > The proposed utility methods will be collected in a class located in the > "src/test/java" part of the code repository. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
