[jira] [Issue Comment Edited] (CSV-52) Keep track of record numbers
[ https://issues.apache.org/jira/browse/CSV-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241528#comment-13241528 ] Sebb edited comment on CSV-52 at 3/29/12 7:58 PM: -- Maybe the number should also be stored in the record? The counter should be the same type (long, int) as the line number. was (Author: s...@apache.org): Maybe the number should also be stored in the record? The counter should be long. > Keep track of record numbers > > > Key: CSV-52 > URL: https://issues.apache.org/jira/browse/CSV-52 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Reporter: Emmanuel Bourg >Priority: Minor > Fix For: 1.x > > > The parser is able to return the current line number of the file, it should > also be able to return the record number. -- 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] (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-tabpanel&focusedCommentId=13239359#comment-13239359 ] Sebb edited comment on CSV-88 at 3/29/12 6:53 PM: -- 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. was (Author: s...@apache.org): 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] [Issue Comment Edited] (IO-315) Replace all "String encoding" parameters with a value type
[
https://issues.apache.org/jira/browse/IO-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238598#comment-13238598
]
Sebb edited comment on IO-315 at 3/26/12 5:43 PM:
--
That makes more sense now, but I think it would be overkill to introduce a new
interface here.
Using Charset would be better IMO.
Using Charset would convert the checked {{UnsupportedEncodingException}} into
the unchecked {{UnsupportedCharsetException}}.
This should simplify application code that does not already catch
{{IOException}}, though of course in Commons IO many methods throw IOE already.
AFAICT, parameters would need to be changed to use (e.g.)
{{Charset.forName("UTF-8")}} instead of {{"UTF-8"}} so user code would be
slightly longer.
was (Author: s...@apache.org):
That makes a more sense now, but I think it would be overkill to introduce
a new interface here.
Using Charset would be better IMO.
Using Charset would convert the checked {{UnsupportedEncodingException}} into
the unchecked {{UnsupportedCharsetException}}.
This should simplify application code that does not already catch
{{IOException}}, though of course in Commons IO many methods throw IOE already.
AFAICT, parameters would need to be changed to use (e.g.)
{{Charset.forName("UTF-8")}} instead of {{"UTF-8"}} so user code would be
slightly longer.
> Replace all "String encoding" parameters with a value type
> --
>
> Key: IO-315
> URL: https://issues.apache.org/jira/browse/IO-315
> Project: Commons IO
> Issue Type: New Feature
> Components: Streams/Writers
>Affects Versions: 2.1
>Reporter: Aaron Digulla
>
> Please create an interface "Encoding" plus a set of useful defaults (UTF_8,
> ISO_LATIN_1, CP_1250 and CP_1252).
> Use this interface in all places where "String encoding" is used now. This
> would make the API more reliable, improve code reuse and reduce futile catch
> blocks for {{UnsupportedEncodingException}}.
--
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] (CSV-70) Improve readability of CSVLexer
[ https://issues.apache.org/jira/browse/CSV-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238039#comment-13238039 ] Sebb edited comment on CSV-70 at 3/26/12 1:29 AM: -- Yes, I tried something similar and it broke the tests. I think it would be useful to provide (optional) access to the comment fields so one way to solve this would be to return the comment as a token, and deal with it at the record level. was (Author: s...@apache.org): Yes, I tried something similar and it broke the tests. I think it would be useful to provide (optional) access to the comment fields so one way to solve this would be to return the comment as a token, and deal will it at the record level. > 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() > * 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] [Issue Comment Edited] (CSV-68) Use Builder pattern for CSVFormat
[
https://issues.apache.org/jira/browse/CSV-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230818#comment-13230818
]
Sebb edited comment on CSV-68 at 3/16/12 1:54 AM:
--
Patch with skeleton implementation.
The build() method should be updated to include validation.
was (Author: s...@apache.org):
Patch with skeleton implementation
> Use Builder pattern for CSVFormat
> -
>
> Key: CSV-68
> URL: https://issues.apache.org/jira/browse/CSV-68
> Project: Commons CSV
> Issue Type: Improvement
>Reporter: Sebb
> Attachments: CSV-68.patch
>
>
> Using a builder pattern to create CSVFormat instances would allow the
> settings to be validated at creation time and would eliminate the need to
> keep creating new CSVFormat instances whilst still allowing the class to be
> immutable.
> A possible API is as follows:
> {code}
> CSVFormat DEFAULT = CSVFormat.init(',') // delimiter is required
> .withEncapsulator('"')
> .withLeadingSpacesIgnored(true)
> .withTrailingSpacesIgnored(true)
> .withEmptyLinesIgnored(true)
> .withLineSeparator("\r\n") // optional, as it would be the default
> .build();
> CSVFormat format = CSVFormat.init(CSVFormat.DEFAULT) // alternatively start
> with pre-defined format
> .withSurroundingSpacesIgnored(false)
> .build();
> {code}
> Compare this with the current syntax:
> {code}
> // internal syntax; not easy to determine what all the parameters do
> CSVFormat DEFAULT1 = new CSVFormat(',', '"', DISABLED, DISABLED, true, true,
> false, true, CRLF);
> // external syntax
> CSVFormat format = CSVFormat.DEFAULT.withSurroundingSpacesIgnored(false);
> {code}
> As a proof of concept I've written skeleton code which compiles (but needs
> completing).
--
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] (NET-445) The method listFiles in FTPClient can not list these files which upload to FTP Server in Feb, 29 2012
[ https://issues.apache.org/jira/browse/NET-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13219204#comment-13219204 ] Sebb edited comment on NET-445 at 3/6/12 9:02 PM: -- NET uses SimpleDateFormat to parse short dates; however this does not work properly for Feb 29. The current work-round fails for leap-years. [Later] the problem with SimpleDateFormat is that it assumes the year is 1970 - which was not a leap year. The workround is to append the current year to the short date before parsing. This works fine if the current year is a leap year, as is true of 2012. However, if the ftp server continues to display short dates after the end of 2012, the work-round will fail at the start of 2013. Many ftp servers only display short dates for +/- 6 months; such servers will switch to long format dates for Feb 29 before the end of 2012, so won't be affected. was (Author: s...@apache.org): NET uses SimpleDateFormat to parse short dates; however this does not work properly for Feb 29. The current work-round fails for leap-years. Hope to have a fix soon. > The method listFiles in FTPClient can not list these files which upload to > FTP Server in Feb, 29 2012 > - > > Key: NET-445 > URL: https://issues.apache.org/jira/browse/NET-445 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.0.1 >Reporter: keming.hu > > Before Feb, 29 2012, the method listFiles() in FTPClient.class can list all > files in FTP Server. But today, for any file which be uploaded to FTP Server > in Feb, 29 2012, this API can not list these files. When I change the date of > FTP Server(it is not Feb, 29 2012), this API can list all files in FTP Server > also. -- 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] (NET-449) listFiles bug with folder that begins with "-"
[
https://issues.apache.org/jira/browse/NET-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13222468#comment-13222468
]
Sebb edited comment on NET-449 at 3/5/12 5:51 PM:
--
Not sure there's anything Net can do about this.
The parameter to the LIST command is supposed to be a pathname, and it is up to
the server to determine if it is a file or a directory.
However, the "-" prefix is used by some servers for supporting qualifiers, e.g.
-a, -l
This obviously has the potential to be confused with a valid pathname.
If the server fails to recognise "-data" as a pathname, then it seems to me
that this is a bug in the server.
It ought to behave according to the RFCs.
was (Author: s...@apache.org):
Not sure there's anything Net can do about this.
The parameter to the LIST command is supposed to be a pathname, and it is up to
the server to determine if it is a file or a directory.
The "-" prefix is used by some servers for supporting qualifiers, e.g. -a.
I don't think there is any way to "escape" the leading "-", at least not one
that would work on all servers.
The parameter "./-data" would probably work on most FTP servers, but AFAIK
servers don't have to support that, and some may not do so.
> listFiles bug with folder that begins with "-"
> --
>
> Key: NET-449
> URL: https://issues.apache.org/jira/browse/NET-449
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.1
>Reporter: Stéphane Verger
>
> FTP Server status:
> {code}
> root@xxx-srv:/data/Library# tree -A
> .
> ├── -dash
> │ ├── -dash.txt
> │ ├── file1.txt
> │ └── file2.txt
> └── test
> ├── file2.txt
> └── file.txt
> {code}
> Test code:
> {code}
> final org.apache.commons.net.ftp.FTPClient ftp = new
> org.apache.commons.net.ftp.FTPClient();
> ftp.connect(host, port);
> ftp.login(login, pwd);
>
> System.out.println("PWD: " + ftp.printWorkingDirectory());
> final FTPFile[] listFiles = ftp.listFiles();
> for (int i = 0; i < listFiles.length; i++) {
> System.out.println("[" + i + "] " + listFiles[i]);
> }
>
> System.out.println("Files in /-dash");
> final FTPFile[] listFiles2 = ftp.listFiles("/-dash");
> for (int i = 0; i < listFiles2.length; i++) {
> System.out.println("[" + i + "] " + listFiles2[i]);
> }
>
> System.out.println("Files in -dash");
> final FTPFile[] listFiles3 = ftp.listFiles("-dash");
> for (int i = 0; i < listFiles3.length; i++) {
> System.out.println("[" + i + "] " + listFiles3[i]);
> }
> {code}
> results:
> {code}
> PWD: /
> [0] -dash
> [1] test
> Files in /-dash
> [0] -dash.txt
> [1] file1.txt
> [2] file2.txt
> Files in -dash
> [0] -dash
> [1] .
> [2] ..
> [3] test
> {code}
> When listing "-dash", it list the current directory instead of the
> destination one.
> If I do the same test with the folder test, this time it works as expected.
--
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] (VFS-178) Indicate that passive FTP (and other options) should be used when writing to a FTP location
[ https://issues.apache.org/jira/browse/VFS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622497#comment-12622497 ] Sebb edited comment on VFS-178 at 12/8/11 9:25 AM: --- According to RFC1738, "?" is allowed to be used unencoded as part of the ftp path, so using it for defining parameters seems a bit risky. Perhaps it would be better to choose a different introducer, for example ";" - the FTP scheme already has ";type=" as an optional qualifier. Maybe it would be safer to use ";vfs.mode=" for this specific case? Or perhaps ";vfs.option=" for the general case? was (Author: s...@apache.org): According to RFX1738, "?" is allowed to be used unencoded as part of the ftp path, so using it for defining parameters seems a bit risky. Perhaps it would be better to choose a different introducer, for example ";" - the FTP scheme already has ";type=" as an optional qualifier. Maybe it would be safer to use ";vfs.mode=" for this specific case? Or perhaps ";vfs.option=" for the general case? > Indicate that passive FTP (and other options) should be used when writing to > a FTP location > --- > > Key: VFS-178 > URL: https://issues.apache.org/jira/browse/VFS-178 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: Nightly Builds >Reporter: Asankha C. Perera > Attachments: vfs-ftp.patch > > > I am trying to use VFS to connect to a FTP file, but the problem is that I > cannot specify that PASSIVE mode should be used. I think we could use the > format below to specify for example: ?passive=true etc. > ftp://myusername:mypassword@somehost/pub/downloads/somefile.tgz?option=value > Referece thread > http://mail-archives.apache.org/mod_mbox/commons-dev/200709.mbox/%3c46dfe27e.6070...@ops.co.at%3e > > I think the use of the ?? would not be a good URI scheme. However, maybe we > > > could simply make the VFS parameters unique. For example add vfs. in front > > > of them. > > > > > > For example, > > > http://www/path/cgi-bin/send.pl?FILE=ABC&TYPE=PDF&vfs.proxyHost=proxy.host&vfs.proxyPort=8080 > > > > Yes, for sure, this could make it too - I thought about it too. Even if > I am still not that happy with this query-string parsing/repacking stuff > I'd commit it if someone contributes 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] [Issue Comment Edited] (LANG-774) Add isStarted isStopped and isSuspended to StopWatch
[ https://issues.apache.org/jira/browse/LANG-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157355#comment-13157355 ] Sebb edited comment on LANG-774 at 11/26/11 1:02 AM: - The patch contains a spurious (and incorrect) change to Validate.java, but that can be ignored. Otherwise generally looks OK, though it might be better to use a positive check for isStarted. i.e instead of bq. return this.runningState != STATE_UNSTARTED && this.runningState != STATE_STOPPED; one could use bq. return this.runningState == STATE_RUNNING || this.runningState == STATE_SUSPENDED; It occurs to me that the code would be easier to read if the states were expressed as enums (the code predates them). In which case, the enum itself could have methods for reporting whether it was started/stopped/etc. was (Author: s...@apache.org): The patch contains a spurious (and incorrect) change to Validate.java, but that can be ignored. Otherwise generally looks OK, though it might be better to use a positive check for isStarted. i.e instead of bq. return this.runningState != STATE_UNSTARTED && this.runningState != STATE_STOPPED; one could use return this.runningState == STATE_RUNNING || this.runningState == STATE_SUSPENDED; It occurs to me that the code would be easier to read if the states were expressed as enums (the code predates them). In which case, the enum itself could have methods for reporting whether it was started/stopped/etc. > Add isStarted isStopped and isSuspended to StopWatch > > > Key: LANG-774 > URL: https://issues.apache.org/jira/browse/LANG-774 > Project: Commons Lang > Issue Type: Improvement > Components: lang.time.* >Affects Versions: 3.1 >Reporter: Michael Akerman >Priority: Minor > Labels: features > Fix For: 3.2 > > Attachments: LANG774.diff > > Original Estimate: 2h > Remaining Estimate: 2h > > It would be nice to have: >isStarted >isStopped >isSuspended > On StopWatch -- 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] (LANG-777) jar contains velocity template of release notes
[ https://issues.apache.org/jira/browse/LANG-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155088#comment-13155088 ] Sebb edited comment on LANG-777 at 11/22/11 1:07 PM: - Alternatively, I suppose one could override the CP release-notes profile to fix the location. Or copy them to the new location. Depends on whether there is any need to keep the existing location or not. was (Author: s...@apache.org): Alternatively, I suppose one could override the CP release-notes profile to fix the location. > jar contains velocity template of release notes > --- > > Key: LANG-777 > URL: https://issues.apache.org/jira/browse/LANG-777 > Project: Commons Lang > Issue Type: Bug > Components: General >Affects Versions: 3.1 >Reporter: Joerg Schaible >Priority: Trivial > Labels: build > > The released Java archive of 3.1 contains the velocity template > "release-notes.vm" (claiming to be for 3.0.1 anyway) in the Java package > "templates". -- 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-688) "FastMath" contains fractions of constants
[ https://issues.apache.org/jira/browse/MATH-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13123811#comment-13123811 ] Sebb edited comment on MATH-688 at 10/10/11 10:22 AM: -- bq. the downside will be that these constants will be computed at the loading of "FastMath" AFAIK, the constant calculations will be done at compile time. was (Author: s...@apache.org): AFAIK, the calculations will be done at compile time. > "FastMath" contains fractions of constants > -- > > Key: MATH-688 > URL: https://issues.apache.org/jira/browse/MATH-688 > Project: Commons Math > Issue Type: Improvement >Reporter: Gilles >Assignee: Gilles >Priority: Trivial > Fix For: 3.0 > > > Fractions such as 1.0 / 3.0, 1.0 / 5.0, ... could be replaced with static > final constants. > In "asinh", for example, the change can sometimes result in more than halving > the computation time (when the argument is in the range of values where the > constants are used). > In absolute times, the gain is not huge, amounting (on my machine) to > something like 370 ms for 10 million computations. > And, of course, the downside will be that these constants will be computed at > the loading of "FastMath", leading to an additional penalty of about 16 > divisions at initialization... :) -- 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
