[jira] [Commented] (MATH-771) Improve javadoc for iterative linear solvers with preconditioners
[
https://issues.apache.org/jira/browse/MATH-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239206#comment-13239206
]
Sébastien Brisard commented on MATH-771:
Changes applied to
{{org.apache.commons.math3.linear.PreconditionedIterativeLinearSolver}} in
{{r1305738}}.
Improve javadoc for iterative linear solvers with preconditioners
-
Key: MATH-771
URL: https://issues.apache.org/jira/browse/MATH-771
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.1
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Labels: javadoc, linear, solver
Preconditioning is the replacement of the linear system {{A * x = b}} with
{{A * M^(-1) * y = b}}, followed by {{x = M^(-1) * y}}, where {{M}}
approximates in some sense {{A}}. There is no consensus in the literature as
to whether {{M}} of {{M^(-1)}} should be called the preconditioner.
In {{o.a.c.m3.linear}}, the Javadoc currently states that {{M}} is the
preconditioner. However, following MATH-735, the solver must be passed
{{M^(-1)}} (not {{M}}!) as a {{RealLinearOperator}}. This makes the whole
Javadoc a bit obscure. It would be logical to call preconditioning the
replacement of the initial system with {{A * M * y = b}}, where {{M}}
approximates in some sense {{A^(-1)}} and will be called the preconditioner.
Such a change will make the javadoc more readable. However, it requires
careful review of the existing Javadoc for the following classes
* {{PreconditionedIterativeLinearSolver}},
* {{ConjugateGradient}},
* {{SymmLQ}},
* {{JacobiPreconditioner}},
Also, in {{PreconditionedIterativeLinearSolver}} (and its concrete
implementations), the parameter {{minv}} in {{solve()}} should be renamed
{{m}}.
--
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] (JELLY-290) Links to source code in tutorial page are broken
Links to source code in tutorial page are broken Key: JELLY-290 URL: https://issues.apache.org/jira/browse/JELLY-290 Project: Commons Jelly Issue Type: Improvement Components: documentation Reporter: Vigneshwaran Raveendran Priority: Minor The links to demo source codes in this page: http://commons.apache.org/jelly/tutorial.html are dead. They return 404 Not Found error. Please fix the links. 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] (JELLY-290) Links to source code in tutorial page are broken
[ https://issues.apache.org/jira/browse/JELLY-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239280#comment-13239280 ] Paul Libbrecht commented on JELLY-290: -- Indeed, this is an issue. I am not sure when we shall be able to rebuild the site for good. In the meantime, please use http://svn.apache.org/viewvc/commons/proper/jelly/trunk/ as basis. paul Links to source code in tutorial page are broken Key: JELLY-290 URL: https://issues.apache.org/jira/browse/JELLY-290 Project: Commons Jelly Issue Type: Improvement Components: documentation Reporter: Vigneshwaran Raveendran Priority: Minor Labels: documentation The links to demo source codes in this page: http://commons.apache.org/jelly/tutorial.html are dead. They return 404 Not Found error. Please fix the links. 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] (CSV-53) Allow to always enclose printed values into quotes
[
https://issues.apache.org/jira/browse/CSV-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239318#comment-13239318
]
Emmanuel Bourg commented on CSV-53:
---
The Python CSV module has a similar concept, it offers 4 modes to control the
quoting behavior:
http://docs.python.org/library/csv.html
{quote}
- csv.QUOTE_ALL
Instructs writer objects to quote all fields.
- csv.QUOTE_MINIMAL
Instructs writer objects to only quote those fields which contain special
characters such as delimiter, quotechar or any of the characters in
lineterminator.
- csv.QUOTE_NONNUMERIC
Instructs writer objects to quote all non-numeric fields.
Instructs the reader to convert all non-quoted fields to type float.
- csv.QUOTE_NONE
Instructs writer objects to never quote fields. When the current delimiter
occurs in output data it is preceded by the current escapechar character. If
escapechar is not set, the writer will raise Error if any characters that
require escaping are encountered.
Instructs reader to perform no special processing of quote characters.
{quote}
The idea to quote only non numeric values is interesting, I wonder if this
helps Excel to select the right data type. However I wouldn't mix the quoting
behavior with the escaping behavior as specified by QUOTE_NONE, this is
probably best handled by a separate parameter.
Allow to always enclose printed values into quotes
--
Key: CSV-53
URL: https://issues.apache.org/jira/browse/CSV-53
Project: Commons CSV
Issue Type: Improvement
Components: Printer
Reporter: Emmanuel Bourg
Fix For: 1.x
The printer encloses the values into quotes only if it contains a special
character like a field separator or a line separator. However some
applications expect the values to always be enclosed into quotes. It's
necassary to be able to control how the quotes are added, either always or as
needed.
--
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] (CSV-88) Not possible to create a CSVFormat from scratch
[ https://issues.apache.org/jira/browse/CSV-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239341#comment-13239341 ] Emmanuel Bourg commented on CSV-88: --- +0 for a no arg constructor equivalent to the default format. -1 for more constructors or making PRISTINE public. More constructors defeats the purpose of the fluent API, and PRISTINE is useless as a base format because all properties have to be defined. Not possible to create a CSVFormat from scratch --- Key: CSV-88 URL: https://issues.apache.org/jira/browse/CSV-88 Project: Commons CSV Issue Type: Bug Reporter: Sebb It's not possible to create a CSVFormat except by modifying an existing format. Could either make the PRISTINE format public, or provide a constructor with a single parameter (the delimiter). Could provide a no-args ctor instead, but there seems little point in that. -- 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] (CSV-88) Not possible to create a CSVFormat from scratch
[ https://issues.apache.org/jira/browse/CSV-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239359#comment-13239359 ] Sebb commented on CSV-88: - bq. +0 for a no arg constructor equivalent to the default format. If you mean the DEFAULT format here then that achieves nothing, as the user would have to override any unwanted settings - and the use would have to know which ones to override. If the DEFAULT format were ever later updated, that could invalidate the user's format. I meant that the ctor should be equivalent to PRISTINE or perhaps PRISTINE + CRLF. To fit in with the fluent API, there needs to be a static method. For example, withDefault(char) would do. Not possible to create a CSVFormat from scratch --- Key: CSV-88 URL: https://issues.apache.org/jira/browse/CSV-88 Project: Commons CSV Issue Type: Bug Reporter: Sebb It's not possible to create a CSVFormat except by modifying an existing format. Could either make the PRISTINE format public, or provide a constructor with a single parameter (the delimiter). Could provide a no-args ctor instead, but there seems little point in that. -- 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] (CSV-89) Rename withLineSeparator as withOutputLineSeparator
Rename withLineSeparator as withOutputLineSeparator --- Key: CSV-89 URL: https://issues.apache.org/jira/browse/CSV-89 Project: Commons CSV Issue Type: Improvement Reporter: Sebb The name withLineSeparator is misleading, as it could be taken to mean that the separator applies to input as well as output. The Javadoc tries to make this clear, but it would be better if the name reflected the function/purpose as well. -- 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] (CSV-53) Allow to always enclose printed values into quotes
[ https://issues.apache.org/jira/browse/CSV-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239364#comment-13239364 ] Sebb commented on CSV-53: - +1 to including an OutputQuoting setting along those lines, e.g. an Enum. Though I don't think we should convert numeric fields to type float! QUOTE_NONE cannot be allowed to generate invalid output, so must either escape or throw an error. So I don't understand what you mean by a separate parameter. Allow to always enclose printed values into quotes -- Key: CSV-53 URL: https://issues.apache.org/jira/browse/CSV-53 Project: Commons CSV Issue Type: Improvement Components: Printer Reporter: Emmanuel Bourg Fix For: 1.x The printer encloses the values into quotes only if it contains a special character like a field separator or a line separator. However some applications expect the values to always be enclosed into quotes. It's necassary to be able to control how the quotes are added, either always or as needed. -- 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] (NET-455) FTPClient listFiles(FTPFileFilter) can be faster...
[
https://issues.apache.org/jira/browse/NET-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239370#comment-13239370
]
Nicolas commented on NET-455:
-
I did few tests !
I confirm that
{code} files = ftpClient.listFiles(./, ftpFileFilter); {code}
is slower than
{code} files = ftpClient.listFiles(null, ftpFileFilter); {code}
In mys tests, the first case took 3min05sec and the second one took 17 sec
However, this happens on a wuFTP Server 2.6.1 and can't be reproduced on a
vsFTP Server. Maybe it's wuFTP related...
I tested
{code} files = ftpClient.listFiles(., ftpFileFilter); {code} and it's as fast
the null parameter (17sec). I don't know why listFiles ./ is slow on wuFTP.
And of course, the manual filter with the ArrayList took 17.2/17.3 seconds
(make sense after looking code).
I think this issue can be closed, however people have to remember to not use
./ with wuftp !
FTPClient listFiles(FTPFileFilter) can be faster...
---
Key: NET-455
URL: https://issues.apache.org/jira/browse/NET-455
Project: Commons Net
Issue Type: Improvement
Components: FTP
Affects Versions: 3.0.1
Environment: all
Reporter: Nicolas
Priority: Minor
Labels: ftpclient, listFiles
Original Estimate: 1h
Remaining Estimate: 1h
I tested two ways of sorting files on a remote FTP server with many files (
110 000). Both of these use the FtpFileFilter class (with a test on the
extension filename... very simple).
The first one is the conventionnal =
{code}
files = ftpClient.listFiles(./, ftpFileFilter);
{code}
It takes about 90 seconds ...
the second one is ... nearly as simple as the first one :
{code}
FTPFile [] allFilesListed = ftpClient.listFiles();
files = FTPFileFilterWithExtension.fastFilter(ftpFileFilter, allFilesListed);
{code}
The function FTPFileFilterWithExtension.fastFilter() call the same
ftpFileFilter :
{code}
public static FTPFile [] fastFilter(FTPFileFilter filter, FTPFile
ftpFileArray []) {
ArrayListFTPFile listOfFTPFiles = new ArrayListFTPFile();
for (FTPFile ftpf : ftpFileArray) {
boolean accepted = filter.accept(ftpf);
if (accepted) {
listOfFTPFiles.add(ftpf);
}
}
FTPFile resultArray [] = new FTPFile[listOfFTPFiles.size()];
return listOfFTPFiles.toArray(resultArray);
}
{code}
The second method is EIGHT times faster than the first one ... and I don't
really understand why...
--
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-457) Does commonsnet ftp component connect to a Secure Stratus site?
Does commonsnet ftp component connect to a Secure Stratus site? --- Key: NET-457 URL: https://issues.apache.org/jira/browse/NET-457 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.0.1 Environment: I am connecting from a Windows 2003 Server environment, JDK 1.6 to a Stratus FTP secure site. Reporter: Ramya Rajendiran Priority: Minor This is not a bug. Just a support question. I am connecting from a Windows 2003 Server environment, JDK 1.6, commons net 301 to a Stratus FTP secure site. The stratus box, supports a directory delimiter of ''. I think this is the problem. Does the commons net FTP component support FTP server delimiter of '' -- 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] [Closed] (NET-457) Does commonsnet ftp component connect to a Secure Stratus site?
[ https://issues.apache.org/jira/browse/NET-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas closed NET-457. --- Resolution: Invalid JIRA is not a support forum. Please use the users mailing list. Does commonsnet ftp component connect to a Secure Stratus site? --- Key: NET-457 URL: https://issues.apache.org/jira/browse/NET-457 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.0.1 Environment: I am connecting from a Windows 2003 Server environment, JDK 1.6 to a Stratus FTP secure site. Reporter: Ramya Rajendiran Priority: Minor Labels: newbie This is not a bug. Just a support question. I am connecting from a Windows 2003 Server environment, JDK 1.6, commons net 301 to a Stratus FTP secure site. The stratus box, supports a directory delimiter of ''. I think this is the problem. Does the commons net FTP component support FTP server delimiter of '' -- 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] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
DateUtils.addDays does not work properly with daylight saving time (DST)
Key: LANG-796
URL: https://issues.apache.org/jira/browse/LANG-796
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 2.6
Reporter: Nicola Barbiero
DateUtils.addDays does not work properly with daylight saving time.
The signature of the method is
Date addDays(Date date, int amount)
and the javadocs says Adds a number of days to a date returning a new object.
The original date object is unchanged,
so if X=date.getTime() is the number of milliseconds of the date in input,
the expected behaviour is that the returned Date has a number of milliseconds
equal to X+amount*(8640), where 8640 is the number of milliseconds in
one day.
But when the calculation goes across the DST change date, the number of
milliseconds added does not correspond to whole days.
For example, here in Brussels, this code fragment:
Date input = DateUtils.parseDateStrictly(25-03-2012_00:00, new String[] {
dd-MM-_HH:mm });
Date output = DateUtils.addDays(input, 1);
will give:
'input' equals to Sun Mar 25 00:00:00 CET 2012== input.getTime() equals
to 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime() equals
to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 is equivalent to 23h).
Since addDays is working with objects Date, it should not be influenced by
events like the DST.
Proposed solution: replace the current implementation
public static Date add(Date date, int calendarField, int amount) {
if (date == null) {
throw new IllegalArgumentException(The date must not be null);
}
Calendar c = Calendar.getInstance();
c.setTime(date);
c.add(calendarField, amount);
return c.getTime();
}
based on Calendar with an implementation that works only with Date objects, for
example:
public static Date add(Date date, int calendarField, int amount) {
if (date == null) {
throw new IllegalArgumentException(The date must not be null);
}
return new Date(input.getTime() + amount * 8640l);
}
--
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] (CSV-89) Rename withLineSeparator as withOutputLineSeparator
[ https://issues.apache.org/jira/browse/CSV-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239457#comment-13239457 ] Emmanuel Bourg commented on CSV-89: --- -1 this is too long. Documenting this properly is sufficient. Rename withLineSeparator as withOutputLineSeparator --- Key: CSV-89 URL: https://issues.apache.org/jira/browse/CSV-89 Project: Commons CSV Issue Type: Improvement Reporter: Sebb The name withLineSeparator is misleading, as it could be taken to mean that the separator applies to input as well as output. The Javadoc tries to make this clear, but it would be better if the name reflected the function/purpose as well. -- 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-455) FTPClient listFiles(FTPFileFilter) can be faster...
[
https://issues.apache.org/jira/browse/NET-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-455.
--
Resolution: Not A Problem
Thanks for confirming that it is not a problem in NET
FTPClient listFiles(FTPFileFilter) can be faster...
---
Key: NET-455
URL: https://issues.apache.org/jira/browse/NET-455
Project: Commons Net
Issue Type: Improvement
Components: FTP
Affects Versions: 3.0.1
Environment: all
Reporter: Nicolas
Priority: Minor
Labels: ftpclient, listFiles
Original Estimate: 1h
Remaining Estimate: 1h
I tested two ways of sorting files on a remote FTP server with many files (
110 000). Both of these use the FtpFileFilter class (with a test on the
extension filename... very simple).
The first one is the conventionnal =
{code}
files = ftpClient.listFiles(./, ftpFileFilter);
{code}
It takes about 90 seconds ...
the second one is ... nearly as simple as the first one :
{code}
FTPFile [] allFilesListed = ftpClient.listFiles();
files = FTPFileFilterWithExtension.fastFilter(ftpFileFilter, allFilesListed);
{code}
The function FTPFileFilterWithExtension.fastFilter() call the same
ftpFileFilter :
{code}
public static FTPFile [] fastFilter(FTPFileFilter filter, FTPFile
ftpFileArray []) {
ArrayListFTPFile listOfFTPFiles = new ArrayListFTPFile();
for (FTPFile ftpf : ftpFileArray) {
boolean accepted = filter.accept(ftpf);
if (accepted) {
listOfFTPFiles.add(ftpf);
}
}
FTPFile resultArray [] = new FTPFile[listOfFTPFiles.size()];
return listOfFTPFiles.toArray(resultArray);
}
{code}
The second method is EIGHT times faster than the first one ... and I don't
really understand why...
--
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] (CSV-53) Allow to always enclose printed values into quotes
[ https://issues.apache.org/jira/browse/CSV-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239465#comment-13239465 ] Emmanuel Bourg commented on CSV-53: --- I agree that numeric fields are not to be converted to floats by the parser, my comment was referring to the printer. The escaping might be specified by another enum to select between quote doubling, quote escaping and no escaping. Allow to always enclose printed values into quotes -- Key: CSV-53 URL: https://issues.apache.org/jira/browse/CSV-53 Project: Commons CSV Issue Type: Improvement Components: Printer Reporter: Emmanuel Bourg Fix For: 1.x The printer encloses the values into quotes only if it contains a special character like a field separator or a line separator. However some applications expect the values to always be enclosed into quotes. It's necassary to be able to control how the quotes are added, either always or as needed. -- 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] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239466#comment-13239466
]
Adrian Crum commented on LANG-796:
--
The current behavior is correct. The result added one day. One day is NOT equal
to 8640 milliseconds - as you can see from the result.
DateUtils.addDays does not work properly with daylight saving time (DST)
Key: LANG-796
URL: https://issues.apache.org/jira/browse/LANG-796
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 2.6
Reporter: Nicola Barbiero
DateUtils.addDays does not work properly with daylight saving time.
The signature of the method is
Date addDays(Date date, int amount)
and the javadocs says Adds a number of days to a date returning a new
object. The original date object is unchanged,
so if X=date.getTime() is the number of milliseconds of the date in input,
the expected behaviour is that the returned Date has a number of milliseconds
equal to X+amount*(8640), where 8640 is the number of milliseconds in
one day.
But when the calculation goes across the DST change date, the number of
milliseconds added does not correspond to whole days.
For example, here in Brussels, this code fragment:
Date input = DateUtils.parseDateStrictly(25-03-2012_00:00, new String[]
{ dd-MM-_HH:mm });
Date output = DateUtils.addDays(input, 1);
will give:
'input' equals to Sun Mar 25 00:00:00 CET 2012== input.getTime()
equals to 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime()
equals to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 is equivalent to 23h).
Since addDays is working with objects Date, it should not be influenced by
events like the DST.
Proposed solution: replace the current implementation
public static Date add(Date date, int calendarField, int amount) {
if (date == null) {
throw new IllegalArgumentException(The date must not be null);
}
Calendar c = Calendar.getInstance();
c.setTime(date);
c.add(calendarField, amount);
return c.getTime();
}
based on Calendar with an implementation that works only with Date objects,
for example:
public static Date add(Date date, int calendarField, int amount) {
if (date == null) {
throw new IllegalArgumentException(The date must not be null);
}
return new Date(input.getTime() + amount * 8640l);
}
--
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] (CSV-53) Allow to always enclose printed values into quotes
[ https://issues.apache.org/jira/browse/CSV-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239491#comment-13239491 ] Sebb commented on CSV-53: - If the user selects QUOTE_NONE then the only options for printing a value which contains a delimiter or EOL - or which starts with the quote character - are: - escape the character(s) - throw an Exception In which case, we just use the escape character setting to determine which to do. [Otherwise the printed output will not be valid, and I don't think we should allow that.] If the user wants to use a different escape setting for parsing and printing, then they can just create a different format. Otherwise we are back into having separate parsing and printing CSVFormat classes, which you already said you did not want. Allow to always enclose printed values into quotes -- Key: CSV-53 URL: https://issues.apache.org/jira/browse/CSV-53 Project: Commons CSV Issue Type: Improvement Components: Printer Reporter: Emmanuel Bourg Fix For: 1.x The printer encloses the values into quotes only if it contains a special character like a field separator or a line separator. However some applications expect the values to always be enclosed into quotes. It's necassary to be able to control how the quotes are added, either always or as needed. -- 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] (LOGGING-119) deadlock on re-registration of logger
[ https://issues.apache.org/jira/browse/LOGGING-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239515#comment-13239515 ] Anthony Orapallo commented on LOGGING-119: -- Has anyone been able to reliably reproduce the issue. Or get a patch working? We appear to be experiencing this issue as well and need a fix. will upgrading commons-logging.jar fix the issue? All threads get blocked waiting for the WeakHashTable object. The thread holding the object is this: btpool0-193 prio=10 tid=0x2aaabc7e7800 nid=0x468 waiting for monitor entry [0x50a7d000] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.commons.logging.impl.WeakHashtable.purge(WeakHashtable.java:323) - waiting to lock 0x0006e37d3a18 (a java.lang.ref.ReferenceQueue) at org.apache.commons.logging.impl.WeakHashtable.rehash(WeakHashtable.java:312) at java.util.Hashtable.put(Hashtable.java:412) - locked 0x0006e37cf4d0 (a org.apache.commons.logging.impl.WeakHashtable) Note that it is waiting to lock a ReferenceQueue object. The ReferenceQueue object is held by: btpool0-229 prio=10 tid=0x2aaac0c69800 nid=0x6b07 waiting for monitor entry [0x43fd2000] java.lang.Thread.State: BLOCKED (on object monitor) at java.util.Hashtable.remove(Hashtable.java:435) - waiting to lock 0x0006e37cf4d0 (a org.apache.commons.logging.impl.WeakHashtable) at org.apache.commons.logging.impl.WeakHashtable.purgeOne(WeakHashtable.java:338) - locked 0x0006e37d3a18 (a java.lang.ref.ReferenceQueue) Note that this one is waiting to lock the WeakHashTable object, so the thread lock will never break, and all the other btpool threads will back up behind it. deadlock on re-registration of logger - Key: LOGGING-119 URL: https://issues.apache.org/jira/browse/LOGGING-119 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.1 Environment: Java 1.5, Windows Reporter: Nitzan Niv Attachments: BugDeadlock.java, Patch-WeakHashtable-1.1.1.txt Reached a deadlock inside common-logging while concurrently re-deploying 2 WARs. In each WAR there is an attempt to get a logger: private final Log logger = LogFactory.getLog(ContextLoader.class); Thread dump: [deadlocked thread] Thread-96: - Thread 'Thread-96' is waiting to acquire lock 'java.lang.ref.ReferenceQueue@5266e0' that is held by thread 'Thread-102' Stack trace: org.apache.commons.logging.impl.WeakHashtable.purge(WeakHashtable.java:323) org.apache.commons.logging.impl.WeakHashtable.rehash(WeakHashtable.java:312) java.util.Hashtable.put(Hashtable.java:414) org.apache.commons.logging.impl.WeakHashtable.put(WeakHashtable.java:242) org.apache.commons.logging.LogFactory.cacheFactory(LogFactory.java:1004) org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:657) org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685) org.springframework.web.context.ContextLoader.init(ContextLoader.java:145) [deadlocked thread] Thread-102: -- Thread 'Thread-102' is waiting to acquire lock 'org.apache.commons.logging.impl. WeakHashtable@1e02138' that is held by thread 'Thread-96' Stack trace: java.util.Hashtable.remove(Hashtable.java:437) org.apache.commons.logging.impl.WeakHashtable.purgeOne(WeakHashtable.java:338) org.apache.commons.logging.impl.WeakHashtable.put(WeakHashtable.java:238) org.apache.commons.logging.LogFactory.cacheFactory(LogFactory.java:1004) org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:657) org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685) org.springframework.web.context.ContextLoader.init(ContextLoader.java:145) -- 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] (POOL-107) number of connections created has crossed more than maxActive
[
https://issues.apache.org/jira/browse/POOL-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239526#comment-13239526
]
Dmytro Savchenko commented on POOL-107:
---
The problem is reproduced exact as described by Victor N with commons-dbcp-1.4
and commons-pool-1.6. Pool should be created prior to DB became available.
There is a problem method in org.apache.commons.dbcp.BasicDataSource class:
protected void createConnectionPool() {
// Create an object pool to contain our active connections
GenericObjectPool gop;
if ((abandonedConfig != null)
(abandonedConfig.getRemoveAbandoned())) {
gop = new AbandonedObjectPool(null,abandonedConfig);
}
else {
gop = new GenericObjectPool();
}
gop.setMaxActive(maxActive);
gop.setMaxIdle(maxIdle);
gop.setMinIdle(minIdle);
gop.setMaxWait(maxWait);
gop.setTestOnBorrow(testOnBorrow);
gop.setTestOnReturn(testOnReturn);
gop.setTimeBetweenEvictionRunsMillis(timeBetweenEvictionRunsMillis);
gop.setNumTestsPerEvictionRun(numTestsPerEvictionRun);
gop.setMinEvictableIdleTimeMillis(minEvictableIdleTimeMillis);
gop.setTestWhileIdle(testWhileIdle);
connectionPool = gop;
}
When client application calls getConnection() method there will be an attempt
to create real data source. There are some steps that will be performed:
1) createConnectionPool() creates connection pool and starts evictor thread if
minEvictableIdleTimeMillis 0. This additional thread will clean up pool and
create new connections to met the minIdle connection count if it's 0.
2) createPoolableConnectionFactory() will create connection factory. And pool
created on previous step will get this factory. After that evictor will start
trying to get the number of connections defined by minIdle parameter even if
DB is unavailable.
The problem appears is on step 1. If (connectionPool != null) we will lose
previously created pool with connection factory set and evictor started. And
this happens every time BasicDataSource::getConnection() method is called.
So, when DB will became available there will be a lot of lost connection pools
each trying to get the minIdle connections.
We've solved this by extending BasicDataSource and overriding of
createConnectionPool method in such a way:
protected void createConnectionPool()
{
if (connectionPool != null)
{
try
{
connectionPool.close();
}
catch (Exception e)
{
}
}
super.createConnectionPool();
}
number of connections created has crossed more than maxActive
--
Key: POOL-107
URL: https://issues.apache.org/jira/browse/POOL-107
Project: Commons Pool
Issue Type: Bug
Affects Versions: 1.3
Environment: OS:Red Hat Enterprise Linux AS release 4 (Nahant Update
2)
uname:Linux 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:32:14 EDT 2005 i686
vm_info: Java HotSpot(TM) Server VM (1.4.2_13-b06) for
linux-x86, built
on Oct 18 2006 09:55:11 by unknown with unknown compiler
Reporter: Bhaskar NA
Fix For: 1.5
I found that when the minIdle is configured then during loads, common pool
creates more number of connections it will be greater than maxActive.
When I had following settings:
maxActive = 50
maxIdle = 30
minIdle=30
factory=org.apache.commons.dbcp.BasicDataSourceFactory
maxWait=1
timeBetweenEvictionRunsMillis=90
numTestsPerEvictionRun=50
minEvictableIdleTimeMillis=180
testWhileIdle=true
testOnBorrow = true
validationQuery='select 1 from dual'
Number of connections in the pool went upto 121. (found thru netstat)
When I changed minIdle to 15 and did my load test connecitons in the pool
went upto 66
Looks like maxActive is getting bypassed with minIdle.
When I changed minIdle to 10 and maxActive to 30 and maxIdle to 30 then
number of connections went upto 40.
Can someone please throw light on what is going on here? I am using DBCP
1.2.1 and common pool 1.3.
Bhaskar
--
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] (JELLY-290) Links to source code in tutorial page are broken
[ https://issues.apache.org/jira/browse/JELLY-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239530#comment-13239530 ] Sebb commented on JELLY-290: The files had moved from their original locations, which is why the cvs = svn redirect did not work. Temporary fix applied to HTML files; this should show up in a few hours on the main site. Links to source code in tutorial page are broken Key: JELLY-290 URL: https://issues.apache.org/jira/browse/JELLY-290 Project: Commons Jelly Issue Type: Improvement Components: documentation Reporter: Vigneshwaran Raveendran Priority: Minor Labels: documentation The links to demo source codes in this page: http://commons.apache.org/jelly/tutorial.html are dead. They return 404 Not Found error. Please fix the links. 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] (JELLY-290) Links to source code in tutorial page are broken
[ https://issues.apache.org/jira/browse/JELLY-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239549#comment-13239549 ] Sebb commented on JELLY-290: Also fixed XML source files so eventual rebuild will hopefully keep the changes Links to source code in tutorial page are broken Key: JELLY-290 URL: https://issues.apache.org/jira/browse/JELLY-290 Project: Commons Jelly Issue Type: Improvement Components: documentation Reporter: Vigneshwaran Raveendran Priority: Minor Labels: documentation The links to demo source codes in this page: http://commons.apache.org/jelly/tutorial.html are dead. They return 404 Not Found error. Please fix the links. 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] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239560#comment-13239560
]
Nicola Barbiero commented on LANG-796:
--
From http://docs.oracle.com/javase/6/docs/api/java/util/Date.html:
The class Date represents a specific instant in time, with millisecond
precision. [...] the Date class is intended to reflect coordinated universal
time (UTC) [...] Nearly all modern operating systems assume that 1 day = 24 ×
60 × 60 = 86400 seconds in all cases.
The concept of daylight saving time (DST) is not present in UTC, and UTC is
NEVER effected by DST, so a method that receives a Date in input and returns a
Date should never be effected by DST.
http://en.wikipedia.org/wiki/Coordinated_Universal_Time#Daylight_saving
The current behavior would be correct if working on Calendar objects, since a
Calendar takes in account the concept of DST.
By the way, even if the final choice will be to not change the current behavior
for this method, at least it should be better documented in its javadoc, to
avoid misuses and misunderstanding in its way of working.
DateUtils.addDays does not work properly with daylight saving time (DST)
Key: LANG-796
URL: https://issues.apache.org/jira/browse/LANG-796
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 2.6
Reporter: Nicola Barbiero
DateUtils.addDays does not work properly with daylight saving time.
The signature of the method is
Date addDays(Date date, int amount)
and the javadocs says Adds a number of days to a date returning a new
object. The original date object is unchanged,
so if X=date.getTime() is the number of milliseconds of the date in input,
the expected behaviour is that the returned Date has a number of milliseconds
equal to X+amount*(8640), where 8640 is the number of milliseconds in
one day.
But when the calculation goes across the DST change date, the number of
milliseconds added does not correspond to whole days.
For example, here in Brussels, this code fragment:
Date input = DateUtils.parseDateStrictly(25-03-2012_00:00, new String[]
{ dd-MM-_HH:mm });
Date output = DateUtils.addDays(input, 1);
will give:
'input' equals to Sun Mar 25 00:00:00 CET 2012== input.getTime()
equals to 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime()
equals to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 is equivalent to 23h).
Since addDays is working with objects Date, it should not be influenced by
events like the DST.
Proposed solution: replace the current implementation
public static Date add(Date date, int calendarField, int amount) {
if (date == null) {
throw new IllegalArgumentException(The date must not be null);
}
Calendar c = Calendar.getInstance();
c.setTime(date);
c.add(calendarField, amount);
return c.getTime();
}
based on Calendar with an implementation that works only with Date objects,
for example:
public static Date add(Date date, int calendarField, int amount) {
if (date == null) {
throw new IllegalArgumentException(The date must not be null);
}
return new Date(input.getTime() + amount * 8640l);
}
--
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] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239606#comment-13239606
]
Adrian Crum commented on LANG-796:
--
If you want to perform millisecond arithmetic, then I recommend you use long
values and avoid using the DateUtils class.
The JavaDocs seem clear to me - the method adds a day, not 8640
milliseconds.
DateUtils.addDays does not work properly with daylight saving time (DST)
Key: LANG-796
URL: https://issues.apache.org/jira/browse/LANG-796
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 2.6
Reporter: Nicola Barbiero
DateUtils.addDays does not work properly with daylight saving time.
The signature of the method is
Date addDays(Date date, int amount)
and the javadocs says Adds a number of days to a date returning a new
object. The original date object is unchanged,
so if X=date.getTime() is the number of milliseconds of the date in input,
the expected behaviour is that the returned Date has a number of milliseconds
equal to X+amount*(8640), where 8640 is the number of milliseconds in
one day.
But when the calculation goes across the DST change date, the number of
milliseconds added does not correspond to whole days.
For example, here in Brussels, this code fragment:
Date input = DateUtils.parseDateStrictly(25-03-2012_00:00, new String[]
{ dd-MM-_HH:mm });
Date output = DateUtils.addDays(input, 1);
will give:
'input' equals to Sun Mar 25 00:00:00 CET 2012== input.getTime()
equals to 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime()
equals to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 is equivalent to 23h).
Since addDays is working with objects Date, it should not be influenced by
events like the DST.
Proposed solution: replace the current implementation
public static Date add(Date date, int calendarField, int amount) {
if (date == null) {
throw new IllegalArgumentException(The date must not be null);
}
Calendar c = Calendar.getInstance();
c.setTime(date);
c.add(calendarField, amount);
return c.getTime();
}
based on Calendar with an implementation that works only with Date objects,
for example:
public static Date add(Date date, int calendarField, int amount) {
if (date == null) {
throw new IllegalArgumentException(The date must not be null);
}
return new Date(input.getTime() + amount * 8640l);
}
--
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] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239608#comment-13239608
]
Thomas Neidhart commented on LANG-796:
--
I had to deal with DST problems just recently myself:
The behaviour of DateUtils is perfectly valid if you consider your local
timezone. The method uses internally the default Calendar instance (that is set
to your local timezone) and is thus affected by DST. If you want to operate on
UTC dates only, use a Calendar configured for the UTC timezone.
It could be elaborated a bit more in the javadoc, so that people are aware of
the fact, but there is nothing wrong with it imho.
DateUtils.addDays does not work properly with daylight saving time (DST)
Key: LANG-796
URL: https://issues.apache.org/jira/browse/LANG-796
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 2.6
Reporter: Nicola Barbiero
DateUtils.addDays does not work properly with daylight saving time.
The signature of the method is
Date addDays(Date date, int amount)
and the javadocs says Adds a number of days to a date returning a new
object. The original date object is unchanged,
so if X=date.getTime() is the number of milliseconds of the date in input,
the expected behaviour is that the returned Date has a number of milliseconds
equal to X+amount*(8640), where 8640 is the number of milliseconds in
one day.
But when the calculation goes across the DST change date, the number of
milliseconds added does not correspond to whole days.
For example, here in Brussels, this code fragment:
Date input = DateUtils.parseDateStrictly(25-03-2012_00:00, new String[]
{ dd-MM-_HH:mm });
Date output = DateUtils.addDays(input, 1);
will give:
'input' equals to Sun Mar 25 00:00:00 CET 2012== input.getTime()
equals to 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime()
equals to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 is equivalent to 23h).
Since addDays is working with objects Date, it should not be influenced by
events like the DST.
Proposed solution: replace the current implementation
public static Date add(Date date, int calendarField, int amount) {
if (date == null) {
throw new IllegalArgumentException(The date must not be null);
}
Calendar c = Calendar.getInstance();
c.setTime(date);
c.add(calendarField, amount);
return c.getTime();
}
based on Calendar with an implementation that works only with Date objects,
for example:
public static Date add(Date date, int calendarField, int amount) {
if (date == null) {
throw new IllegalArgumentException(The date must not be null);
}
return new Date(input.getTime() + amount * 8640l);
}
--
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] (SANDBOX-416) Improve DFS/BFS visit detecting multiple states and related actions instead of just stop/continue
[
https://issues.apache.org/jira/browse/SANDBOX-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239942#comment-13239942
]
Claudio Squarcella commented on SANDBOX-416:
Hi Simone,
I just committed the proposed change. Now {{ABORT}} is available also for the
two methods {{discoveryEdge}} and {{discoveryVertex}}. Please see
[r1306016|http://svn.apache.org/viewvc?view=revisionrevision=1306016].
If it looks good I guess we can close the issue.
Cheers :)
Claudio
Improve DFS/BFS visit detecting multiple states and related actions instead
of just stop/continue
-
Key: SANDBOX-416
URL: https://issues.apache.org/jira/browse/SANDBOX-416
Project: Commons Sandbox
Issue Type: Improvement
Components: Graph
Reporter: Simone Tripodi
Assignee: Claudio Squarcella
As discussed in
[ML|http://mail-archives.apache.org/mod_mbox/commons-dev/201203.mbox/%3CCAAqLGLOhZYC8qvT4TLugsnqCgw9BQ-%2BkYoGXVrKASy7PDZdeoQ%40mail.gmail.com%3E],
{{org.apache.commons.graph.visit.GraphVisitHandler}} methods that return
{{boolean}} flags can be sometimes not so intuitive.
The proposal is replacing {{boolean}} flags return statements with an
enumeration values {{ABORT}}, {{CONTINUE}}, {{SKIP}} to identify
* visit has to be immediately terminated
* visit can continue;
* current node children visit can be skipped.
--
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] (SANDBOX-416) Improve DFS/BFS visit detecting multiple states and related actions instead of just stop/continue
[
https://issues.apache.org/jira/browse/SANDBOX-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239975#comment-13239975
]
Simone Tripodi commented on SANDBOX-416:
very well done, I like the actual behavior :)
Issue can be IMHO resolved, the only thing I would suggest you to improve is,
when comparing values, putting expected values first, i.e. inetsad of
{code}
if ( stateAfterEdgeDiscovery != VisitState.CONTINUE )
{code}
it could be
{code}
if ( VisitState.CONTINUE != stateAfterEdgeDiscovery )
{code}
and constants could be statically imported. Not an issue, just a matter of
having clean code.
well done!
-Simo
Improve DFS/BFS visit detecting multiple states and related actions instead
of just stop/continue
-
Key: SANDBOX-416
URL: https://issues.apache.org/jira/browse/SANDBOX-416
Project: Commons Sandbox
Issue Type: Improvement
Components: Graph
Reporter: Simone Tripodi
Assignee: Claudio Squarcella
As discussed in
[ML|http://mail-archives.apache.org/mod_mbox/commons-dev/201203.mbox/%3CCAAqLGLOhZYC8qvT4TLugsnqCgw9BQ-%2BkYoGXVrKASy7PDZdeoQ%40mail.gmail.com%3E],
{{org.apache.commons.graph.visit.GraphVisitHandler}} methods that return
{{boolean}} flags can be sometimes not so intuitive.
The proposal is replacing {{boolean}} flags return statements with an
enumeration values {{ABORT}}, {{CONTINUE}}, {{SKIP}} to identify
* visit has to be immediately terminated
* visit can continue;
* current node children visit can be skipped.
--
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] (CODEC-136) Use Charset objects when possible, create Charsets for required character encodings
Use Charset objects when possible, create Charsets for required character encodings --- Key: CODEC-136 URL: https://issues.apache.org/jira/browse/CODEC-136 Project: Commons Codec Issue Type: New Feature Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) Maven home: C:\Java\apache-maven-3.0.4\bin\.. Java version: 1.6.0_31, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_31\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 Use Charset objects when possible, create Charsets for required character encodings. -- 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] (CODEC-136) Use Charset objects when possible, create Charsets for required character encodings
[ https://issues.apache.org/jira/browse/CODEC-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-136: -- Fix Version/s: 1.7 Use Charset objects when possible, create Charsets for required character encodings --- Key: CODEC-136 URL: https://issues.apache.org/jira/browse/CODEC-136 Project: Commons Codec Issue Type: New Feature Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) Maven home: C:\Java\apache-maven-3.0.4\bin\.. Java version: 1.6.0_31, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_31\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: 1.7 Use Charset objects when possible, create Charsets for required character encodings. -- 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] (CSV-70) Improve readability of CSVLexer
[ https://issues.apache.org/jira/browse/CSV-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CSV-70: Description: There are several things that can be improved in the token lexer (this has also been discussed on ML, see http://markmail.org/thread/c6x5ji4v44nx5k4h): * Remove Token input parameter in nextToken() (x) this makes lexer slower * Add convenience methods isDelimiter(c) and isEncapsulator(c) (/) * Remove current caracter input parameter from methods (/) * If possible: replace while(true) loops was: There are several things that can be improved in the token lexer (this has also been discussed on ML, see http://markmail.org/thread/c6x5ji4v44nx5k4h): * Remove Token input parameter in nextToken() * Add convenience methods isDelimiter(c) and isEncapsulator(c) * Remove current caracter input parameter from methods * If possible: replace while(true) loops Improve readability of CSVLexer --- Key: CSV-70 URL: https://issues.apache.org/jira/browse/CSV-70 Project: Commons CSV Issue Type: Improvement Components: Parser Affects Versions: 1.0 Reporter: Benedikt Ritter Fix For: 1.0 There are several things that can be improved in the token lexer (this has also been discussed on ML, see http://markmail.org/thread/c6x5ji4v44nx5k4h): * Remove Token input parameter in nextToken() (x) this makes lexer slower * Add convenience methods isDelimiter(c) and isEncapsulator(c) (/) * Remove current caracter input parameter from methods (/) * If possible: replace while(true) loops -- 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] (CSV-86) Remove current character input parameter from Lexer methods
[ https://issues.apache.org/jira/browse/CSV-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-86. - Resolution: Fixed Remove current character input parameter from Lexer methods --- Key: CSV-86 URL: https://issues.apache.org/jira/browse/CSV-86 Project: Commons CSV Issue Type: Sub-task Components: Parser Reporter: Benedikt Ritter Fix For: 1.0 Attachments: CSV-86.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] (CSV-58) Eascape handling needs rethinking
[ https://issues.apache.org/jira/browse/CSV-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CSV-58: Summary: Eascape handling needs rethinking (was: Unicode escapes are lost if escape character is backslash) Eascape handling needs rethinking - Key: CSV-58 URL: https://issues.apache.org/jira/browse/CSV-58 Project: Commons CSV Issue Type: Bug Components: Parser Reporter: Sebb Fix For: 1.0 The current escape parsing converts escchar to plain char if the char is not one of the special characters to be escaped. This can affect unicode escapes if the esc character is backslash. One way round this is to specifically check for char == 'u', but it seems wrong to only do this for 'u'. Another solution would be to leave escchar as is unless the char is one of the special characters. There are several possible ways to treat unrecognised escapes: - treat it as if the escape char had not been present (current behaviour) - leave the escape char as is - throw an exception -- 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] (CSV-84) Clarify comment handling
[ https://issues.apache.org/jira/browse/CSV-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240074#comment-13240074 ] Sebb commented on CSV-84: - OK, so we should only allow comments at the start of a record. This may be a bit tricky to achieve, as the lexer knows about tokens, not records. Clarify comment handling Key: CSV-84 URL: https://issues.apache.org/jira/browse/CSV-84 Project: Commons CSV Issue Type: Improvement Reporter: Sebb Fix For: 1.0 Comment handling is not currently fully documented / tested. There are several possible situations: 1) trailing comment following one or more values 2) comment marker starts in the first column 3) comment marker starts in the first non-whitespace column How should these be handled? 1) The trailing comment should be ignored 2) Entire line should be ignored, i.e. don't treat it as a blank line 3) This is trickier: if whitespace is being trimmed, treat as 2, else treat as 1, i.e. there is a single value containing whitespace It might also be useful to consider returning comments to the application program as part of CSVRecord. -- 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] (CSV-84) Clarify comment handling
[
https://issues.apache.org/jira/browse/CSV-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240089#comment-13240089
]
Sebb commented on CSV-84:
-
bq. This case is not covered by the tests,
In fact - as I discovered when I tried to fix the code - it is tested.
The test CSVParserTest.testDefaultFormat() includes the CSV source:
{code}
a,b\n
\n, \n
,#\n
{code}
Note that the comment follows the empty quoted value.
However, I think this is mistake.
Clarify comment handling
Key: CSV-84
URL: https://issues.apache.org/jira/browse/CSV-84
Project: Commons CSV
Issue Type: Improvement
Reporter: Sebb
Fix For: 1.0
Comment handling is not currently fully documented / tested.
There are several possible situations:
1) trailing comment following one or more values
2) comment marker starts in the first column
3) comment marker starts in the first non-whitespace column
How should these be handled?
1) The trailing comment should be ignored
2) Entire line should be ignored, i.e. don't treat it as a blank line
3) This is trickier: if whitespace is being trimmed, treat as 2, else treat
as 1, i.e. there is a single value containing whitespace
It might also be useful to consider returning comments to the application
program as part of CSVRecord.
--
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] (CSV-58) Escape handling needs rethinking
[ https://issues.apache.org/jira/browse/CSV-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CSV-58: Summary: Escape handling needs rethinking (was: Eascape handling needs rethinking) Escape handling needs rethinking Key: CSV-58 URL: https://issues.apache.org/jira/browse/CSV-58 Project: Commons CSV Issue Type: Bug Components: Parser Reporter: Sebb Fix For: 1.0 The current escape parsing converts escchar to plain char if the char is not one of the special characters to be escaped. This can affect unicode escapes if the esc character is backslash. One way round this is to specifically check for char == 'u', but it seems wrong to only do this for 'u'. Another solution would be to leave escchar as is unless the char is one of the special characters. There are several possible ways to treat unrecognised escapes: - treat it as if the escape char had not been present (current behaviour) - leave the escape char as is - throw an exception -- 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-771) Improve javadoc for iterative linear solvers with preconditioners
[
https://issues.apache.org/jira/browse/MATH-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240131#comment-13240131
]
Sébastien Brisard commented on MATH-771:
Changes applied to {{org.apache.commons.math3.linear.ConjugateGradient}} in
{{r1306133}}.
Improve javadoc for iterative linear solvers with preconditioners
-
Key: MATH-771
URL: https://issues.apache.org/jira/browse/MATH-771
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.1
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Labels: javadoc, linear, solver
Preconditioning is the replacement of the linear system {{A * x = b}} with
{{A * M^(-1) * y = b}}, followed by {{x = M^(-1) * y}}, where {{M}}
approximates in some sense {{A}}. There is no consensus in the literature as
to whether {{M}} of {{M^(-1)}} should be called the preconditioner.
In {{o.a.c.m3.linear}}, the Javadoc currently states that {{M}} is the
preconditioner. However, following MATH-735, the solver must be passed
{{M^(-1)}} (not {{M}}!) as a {{RealLinearOperator}}. This makes the whole
Javadoc a bit obscure. It would be logical to call preconditioning the
replacement of the initial system with {{A * M * y = b}}, where {{M}}
approximates in some sense {{A^(-1)}} and will be called the preconditioner.
Such a change will make the javadoc more readable. However, it requires
careful review of the existing Javadoc for the following classes
* {{PreconditionedIterativeLinearSolver}},
* {{ConjugateGradient}},
* {{SymmLQ}},
* {{JacobiPreconditioner}},
Also, in {{PreconditionedIterativeLinearSolver}} (and its concrete
implementations), the parameter {{minv}} in {{solve()}} should be renamed
{{m}}.
--
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-771) Improve javadoc for iterative linear solvers with preconditioners
[
https://issues.apache.org/jira/browse/MATH-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240145#comment-13240145
]
Sébastien Brisard commented on MATH-771:
Changes applied to {{org.apache.commons.math3.linear.JacobiPreconditioner}} in
{{r1306148}}.
Improve javadoc for iterative linear solvers with preconditioners
-
Key: MATH-771
URL: https://issues.apache.org/jira/browse/MATH-771
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.1
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Labels: javadoc, linear, solver
Preconditioning is the replacement of the linear system {{A * x = b}} with
{{A * M^(-1) * y = b}}, followed by {{x = M^(-1) * y}}, where {{M}}
approximates in some sense {{A}}. There is no consensus in the literature as
to whether {{M}} of {{M^(-1)}} should be called the preconditioner.
In {{o.a.c.m3.linear}}, the Javadoc currently states that {{M}} is the
preconditioner. However, following MATH-735, the solver must be passed
{{M^(-1)}} (not {{M}}!) as a {{RealLinearOperator}}. This makes the whole
Javadoc a bit obscure. It would be logical to call preconditioning the
replacement of the initial system with {{A * M * y = b}}, where {{M}}
approximates in some sense {{A^(-1)}} and will be called the preconditioner.
Such a change will make the javadoc more readable. However, it requires
careful review of the existing Javadoc for the following classes
* {{PreconditionedIterativeLinearSolver}},
* {{ConjugateGradient}},
* {{SymmLQ}},
* {{JacobiPreconditioner}},
Also, in {{PreconditionedIterativeLinearSolver}} (and its concrete
implementations), the parameter {{minv}} in {{solve()}} should be renamed
{{m}}.
--
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-755) On the contract of FieldElementT.divide(T)
[
https://issues.apache.org/jira/browse/MATH-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard resolved MATH-755.
Resolution: Fixed
Actually fixed prior to the release of 3.0.
On the contract of FieldElementT.divide(T)
Key: MATH-755
URL: https://issues.apache.org/jira/browse/MATH-755
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0, 3.1
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Priority: Minor
Labels: exception, field
Fix For: 3.1
As discussed on the mailing list:
{quote}
The contract of {{FieldElementT.divide(T)}} states that an
{{ArithmeticException}} should be thrown if the parameter is zero. However,
for this boundary case
* {{BigFraction}} throws {{ZeroException}}
* {{BigReal}} throws {{ArithmeticException}}
* {{Complex}} uses NaNs instead of exceptions
* {{Dfp}}, {{DfpDec}} use flags instead of exceptions
* {{Fraction}} throws {{MathArithmeticException}}.
{quote}
There is a need for some cleaning up, which will proceed in two steps
# in the {{FieldElement}} interface the statement that an exception must be
thrown will be removed. The rationale for this is that sometimes, an
exception is actually not wanted. For example, I'm using a wrapper around
primitive {{double}}, and I want all boundary cases to be handled _exactly_
the same way as the primitive operation /).
# the _same_ exception (if any) will be thrown by all implementations. This
will require to chose between {{ArithmeticException}},
{{MathArithmeticException}} and {{ZeroException}}.
--
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] [Closed] (MATH-755) On the contract of FieldElementT.divide(T)
[
https://issues.apache.org/jira/browse/MATH-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-755.
--
Fixed in 3.0.
On the contract of FieldElementT.divide(T)
Key: MATH-755
URL: https://issues.apache.org/jira/browse/MATH-755
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0, 3.1
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Priority: Minor
Labels: exception, field
Fix For: 3.1
As discussed on the mailing list:
{quote}
The contract of {{FieldElementT.divide(T)}} states that an
{{ArithmeticException}} should be thrown if the parameter is zero. However,
for this boundary case
* {{BigFraction}} throws {{ZeroException}}
* {{BigReal}} throws {{ArithmeticException}}
* {{Complex}} uses NaNs instead of exceptions
* {{Dfp}}, {{DfpDec}} use flags instead of exceptions
* {{Fraction}} throws {{MathArithmeticException}}.
{quote}
There is a need for some cleaning up, which will proceed in two steps
# in the {{FieldElement}} interface the statement that an exception must be
thrown will be removed. The rationale for this is that sometimes, an
exception is actually not wanted. For example, I'm using a wrapper around
primitive {{double}}, and I want all boundary cases to be handled _exactly_
the same way as the primitive operation /).
# the _same_ exception (if any) will be thrown by all implementations. This
will require to chose between {{ArithmeticException}},
{{MathArithmeticException}} and {{ZeroException}}.
--
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-771) Improve javadoc for iterative linear solvers with preconditioners
[
https://issues.apache.org/jira/browse/MATH-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard resolved MATH-771.
Resolution: Fixed
Fixed in {{r1306150}}.
Improve javadoc for iterative linear solvers with preconditioners
-
Key: MATH-771
URL: https://issues.apache.org/jira/browse/MATH-771
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.1
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Labels: javadoc, linear, solver
Preconditioning is the replacement of the linear system {{A * x = b}} with
{{A * M^(-1) * y = b}}, followed by {{x = M^(-1) * y}}, where {{M}}
approximates in some sense {{A}}. There is no consensus in the literature as
to whether {{M}} of {{M^(-1)}} should be called the preconditioner.
In {{o.a.c.m3.linear}}, the Javadoc currently states that {{M}} is the
preconditioner. However, following MATH-735, the solver must be passed
{{M^(-1)}} (not {{M}}!) as a {{RealLinearOperator}}. This makes the whole
Javadoc a bit obscure. It would be logical to call preconditioning the
replacement of the initial system with {{A * M * y = b}}, where {{M}}
approximates in some sense {{A^(-1)}} and will be called the preconditioner.
Such a change will make the javadoc more readable. However, it requires
careful review of the existing Javadoc for the following classes
* {{PreconditionedIterativeLinearSolver}},
* {{ConjugateGradient}},
* {{SymmLQ}},
* {{JacobiPreconditioner}},
Also, in {{PreconditionedIterativeLinearSolver}} (and its concrete
implementations), the parameter {{minv}} in {{solve()}} should be renamed
{{m}}.
--
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-756) double as FieldElement
[
https://issues.apache.org/jira/browse/MATH-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard resolved MATH-756.
Resolution: Fixed
Fix Version/s: 3.1
New feature added in {{r1306177}}.
double as FieldElement
--
Key: MATH-756
URL: https://issues.apache.org/jira/browse/MATH-756
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.1
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Priority: Minor
Labels: double, field
Fix For: 3.1
As discussed on the mailing-list, it is proposed to develop a wrapper class
around the {{double}} primitive type. This wrapper class should implement
{{FieldElement}}. This would allow generic calculations on exchangeable
number types (big fractions, big decimals, fractions, decimals). This class
will be called {{Decimal64}} (together with the corresponding
{{Decimal64Field}}).
Similarly, to the {{BigReal}} class, the newly created {{Decimal64}} class
could go to the {{o.a.c.m3.util}} package.
--
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
