[jira] [Closed] (CSV-214) Adding a placeholder in the Lexer and CSV parser to store the end-of-line string
[ https://issues.apache.org/jira/browse/CSV-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mahendru closed CSV-214. -- Code has been merged to master and has been verified. > Adding a placeholder in the Lexer and CSV parser to store the end-of-line > string > > > Key: CSV-214 > URL: https://issues.apache.org/jira/browse/CSV-214 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Reporter: Nitin Mahendru >Assignee: Gary Gregory >Priority: Trivial > Fix For: 1.5 > > Original Estimate: 24h > Remaining Estimate: 24h > > Hi All, > > In my use-case , I have to read a CSV file, Mangle some columns and then > write out a new csv file with those mangled columns. > I have gone through the parser code and I have found no usable way of getting > the line ending information from the CSVParser object. The function > readEndOfLine just consumes End of line whether it is CRLF or LF. > Now that problem is that when I am writing my file back using the CSVPrinter, > I need to know what line ending my input file was. I could write an external > function to do that. A better way would be to store that information in the > CSVParser object and just use it. > To do that I am just saving the state in a variable and exposing that using a > getter. > I have done some basic testing. and Submitting a pull request regarding that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CSV-214) Adding a placeholder in the Lexer and CSV parser to store the end-of-line string
[ https://issues.apache.org/jira/browse/CSV-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124099#comment-16124099 ] Nitin Mahendru commented on CSV-214: Thanks. Will close this ticket. > Adding a placeholder in the Lexer and CSV parser to store the end-of-line > string > > > Key: CSV-214 > URL: https://issues.apache.org/jira/browse/CSV-214 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Reporter: Nitin Mahendru >Assignee: Gary Gregory >Priority: Trivial > Fix For: 1.5 > > Original Estimate: 24h > Remaining Estimate: 24h > > Hi All, > > In my use-case , I have to read a CSV file, Mangle some columns and then > write out a new csv file with those mangled columns. > I have gone through the parser code and I have found no usable way of getting > the line ending information from the CSVParser object. The function > readEndOfLine just consumes End of line whether it is CRLF or LF. > Now that problem is that when I am writing my file back using the CSVPrinter, > I need to know what line ending my input file was. I could write an external > function to do that. A better way would be to store that information in the > CSVParser object and just use it. > To do that I am just saving the state in a variable and exposing that using a > getter. > I have done some basic testing. and Submitting a pull request regarding that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] commons-lang issue #282: SwappedPair constructed as Pair.of(rhs,lhs)
Github user garydgregory commented on the issue: https://github.com/apache/commons-lang/pull/282 +1 on the unit test request, we need it to avoid regressions. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (CSV-214) Adding a placeholder in the Lexer and CSV parser to store the end-of-line string
[ https://issues.apache.org/jira/browse/CSV-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved CSV-214. -- Resolution: Fixed Fix Version/s: (was: Discussion) 1.5 In Git master, please verify and close. Closes #20. > Adding a placeholder in the Lexer and CSV parser to store the end-of-line > string > > > Key: CSV-214 > URL: https://issues.apache.org/jira/browse/CSV-214 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Reporter: Nitin Mahendru >Assignee: Gary Gregory >Priority: Trivial > Fix For: 1.5 > > Original Estimate: 24h > Remaining Estimate: 24h > > Hi All, > > In my use-case , I have to read a CSV file, Mangle some columns and then > write out a new csv file with those mangled columns. > I have gone through the parser code and I have found no usable way of getting > the line ending information from the CSVParser object. The function > readEndOfLine just consumes End of line whether it is CRLF or LF. > Now that problem is that when I am writing my file back using the CSVPrinter, > I need to know what line ending my input file was. I could write an external > function to do that. A better way would be to store that information in the > CSVParser object and just use it. > To do that I am just saving the state in a variable and exposing that using a > getter. > I have done some basic testing. and Submitting a pull request regarding that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CSV-214) Adding a placeholder in the Lexer and CSV parser to store the end-of-line string
[ https://issues.apache.org/jira/browse/CSV-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated CSV-214: - Summary: Adding a placeholder in the Lexer and CSV parser to store the end-of-line string (was: Adding a placeholder in the Lexer and CSV parser to store the Line Ending) > Adding a placeholder in the Lexer and CSV parser to store the end-of-line > string > > > Key: CSV-214 > URL: https://issues.apache.org/jira/browse/CSV-214 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Reporter: Nitin Mahendru >Assignee: Gary Gregory >Priority: Trivial > Fix For: Discussion > > Original Estimate: 24h > Remaining Estimate: 24h > > Hi All, > > In my use-case , I have to read a CSV file, Mangle some columns and then > write out a new csv file with those mangled columns. > I have gone through the parser code and I have found no usable way of getting > the line ending information from the CSVParser object. The function > readEndOfLine just consumes End of line whether it is CRLF or LF. > Now that problem is that when I am writing my file back using the CSVPrinter, > I need to know what line ending my input file was. I could write an external > function to do that. A better way would be to store that information in the > CSVParser object and just use it. > To do that I am just saving the state in a variable and exposing that using a > getter. > I have done some basic testing. and Submitting a pull request regarding that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MATH-1428) OLSMultipleLinearRegression estimates different residuals with different order of input
[ https://issues.apache.org/jira/browse/MATH-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123215#comment-16123215 ] Gilles commented on MATH-1428: -- What result did you expect? What do other libraries produce? Also, please provide a _minimal_ working code (preferably a JUnit test) example. > OLSMultipleLinearRegression estimates different residuals with different > order of input > > > Key: MATH-1428 > URL: https://issues.apache.org/jira/browse/MATH-1428 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.4.1 > Environment: win7 64bit jdk1.8 intelljidea >Reporter: butchild > Labels: ols, regression, residuals > > I have a regression job with 31 X ,which 30 of them are dummys . > And the length of data is 800+ . > I'm using OLSMultipleLinearRegression to do regression. > I found if I change the order of the 800+ data, the residuals I got from > ols.estimateResiduals() > are differents ,and the correlation of the two differet rersiduals is near > 100%,like 99.8%. > My data is below in Docs Text area. > The fields of each Column is : > sig,y,x1,x2,xn -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] commons-lang issue #282: SwappedPair constructed as Pair.of(rhs,lhs)
Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/282 Makes sense, good catch. However, would be nice to have a unit test at least to cover that case, and make sure we don't have any regression for this behaviour. Would you be able to create one @namannigam ? Thanks!!! Bruno --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Comment Edited] (NET-642) using execPROT on FTPSClients with Proxy Settings removes Proxy Settings
[ https://issues.apache.org/jira/browse/NET-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123134#comment-16123134 ] Johannes Frank edited comment on NET-642 at 8/11/17 10:17 AM: -- I have the unit test but how and to which branch should I create a PR for that? Edit: NVM, done. You have a Pull Request https://github.com/apache/commons-net/pull/27 was (Author: djgummikuh): I have the unit test but how and to which branch should I create a PR for that? > using execPROT on FTPSClients with Proxy Settings removes Proxy Settings > > > Key: NET-642 > URL: https://issues.apache.org/jira/browse/NET-642 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6 > Environment: Java 1.8.0_112 > Linux 64bit >Reporter: Johannes Frank >Priority: Critical > > In Reference to https://issues.apache.org/jira/browse/NET-578 > I'm trying to establish an FTPS Connection via a HTTP Proxy. The Control > Connection is properly established, however the Moment I do execPROT the > Proxy settings are resetted by call to setSocketFactory(new > FTPSSocketFactory(context)); in FTPSClient.java:534. > This causes FTPSClients with a call to execPROT to actually ignore the proxy > settings and attempt to contact the FTPS Server directly for data connections. > Since we are required to use PROT P this is currently blocking our feature > for FTPS Connections via HTTP proxy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NET-642) using execPROT on FTPSClients with Proxy Settings removes Proxy Settings
[ https://issues.apache.org/jira/browse/NET-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123134#comment-16123134 ] Johannes Frank commented on NET-642: I have the unit test but how and to which branch should I create a PR for that? > using execPROT on FTPSClients with Proxy Settings removes Proxy Settings > > > Key: NET-642 > URL: https://issues.apache.org/jira/browse/NET-642 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6 > Environment: Java 1.8.0_112 > Linux 64bit >Reporter: Johannes Frank >Priority: Critical > > In Reference to https://issues.apache.org/jira/browse/NET-578 > I'm trying to establish an FTPS Connection via a HTTP Proxy. The Control > Connection is properly established, however the Moment I do execPROT the > Proxy settings are resetted by call to setSocketFactory(new > FTPSSocketFactory(context)); in FTPSClient.java:534. > This causes FTPSClients with a call to execPROT to actually ignore the proxy > settings and attempt to contact the FTPS Server directly for data connections. > Since we are required to use PROT P this is currently blocking our feature > for FTPS Connections via HTTP proxy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IO-523) Do not reload the entire file when a tailed file's length and position are the same but the file is newer
[
https://issues.apache.org/jira/browse/IO-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123104#comment-16123104
]
Sebb commented on IO-523:
-
The behaviour needs to be optional to account for the case where the file has
been rewritten to the same size.
> Do not reload the entire file when a tailed file's length and position are
> the same but the file is newer
> -
>
> Key: IO-523
> URL: https://issues.apache.org/jira/browse/IO-523
> Project: Commons IO
> Issue Type: Improvement
> Components: Streams/Writers
>Affects Versions: 2.5
> Environment: Windows 10
>Reporter: Tyler Murry
>Priority: Minor
> Attachments: IO-523.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> In the Tailer class, when the file length is equal to the position and the
> file is newer, the following branch is executed:
> {code:title=org.apache.commons.io.input.Tailer.java}
> // --- Lines 461 - 472 --
> // ...
> else if (newer) {
> /*
>* This can happen if the file is truncated or overwritten with the exact
> same length of
>* information. In cases like this, the file position needs to be reset
>*/
> position = 0;
> reader.seek(position); // cannot be null here
> // Now we can read new lines
> position = readLines(reader);
> last = file.lastModified();
> }
> // ...
> {code}
> The comments in the branch specifically mention wanting to reset the position
> and reload the entire file. However, I believe this can lead to undesirable
> effects in certain cases.
> One example is when you are tailing one file into another file. If this
> branch is hit, the entire input file is recopied into the output file. This
> is especially troublesome if you have a rouge file who's timestamp changes
> regularly without any content changes.
> My improvement would be to simply remove this branch if it works for the
> general case as well. Or, at least for special cases, allow a parameter to be
> checked to prevent this behavior.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MATH-1428) OLSMultipleLinearRegression estimates different residuals with different order of input
butchild created MATH-1428: -- Summary: OLSMultipleLinearRegression estimates different residuals with different order of input Key: MATH-1428 URL: https://issues.apache.org/jira/browse/MATH-1428 Project: Commons Math Issue Type: Bug Affects Versions: 3.4.1 Environment: win7 64bit jdk1.8 intelljidea Reporter: butchild I have a regression job with 31 X ,which 30 of them are dummys . And the length of data is 800+ . I'm using OLSMultipleLinearRegression to do regression. I found if I change the order of the 800+ data, the residuals I got from ols.estimateResiduals() are differents ,and the correlation of the two differet rersiduals is near 100%,like 99.8%. My data is below in Docs Text area. The fields of each Column is : sig,y,x1,x2,xn -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IO-523) Do not reload the entire file when a tailed file's length and position are the same but the file is newer
[
https://issues.apache.org/jira/browse/IO-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16122954#comment-16122954
]
lingyangtt commented on IO-523:
---
I foud this issue 3 years ago, it seems sometimes the file is newer, but its
length has not changed. I changed the code, in this case, do nothing .
else if (newer) {
//logger.info("no read bytes");
}
> Do not reload the entire file when a tailed file's length and position are
> the same but the file is newer
> -
>
> Key: IO-523
> URL: https://issues.apache.org/jira/browse/IO-523
> Project: Commons IO
> Issue Type: Improvement
> Components: Streams/Writers
>Affects Versions: 2.5
> Environment: Windows 10
>Reporter: Tyler Murry
>Priority: Minor
> Attachments: IO-523.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> In the Tailer class, when the file length is equal to the position and the
> file is newer, the following branch is executed:
> {code:title=org.apache.commons.io.input.Tailer.java}
> // --- Lines 461 - 472 --
> // ...
> else if (newer) {
> /*
>* This can happen if the file is truncated or overwritten with the exact
> same length of
>* information. In cases like this, the file position needs to be reset
>*/
> position = 0;
> reader.seek(position); // cannot be null here
> // Now we can read new lines
> position = readLines(reader);
> last = file.lastModified();
> }
> // ...
> {code}
> The comments in the branch specifically mention wanting to reset the position
> and reload the entire file. However, I believe this can lead to undesirable
> effects in certain cases.
> One example is when you are tailing one file into another file. If this
> branch is hit, the entire input file is recopied into the output file. This
> is especially troublesome if you have a rouge file who's timestamp changes
> regularly without any content changes.
> My improvement would be to simply remove this branch if it works for the
> general case as well. Or, at least for special cases, allow a parameter to be
> checked to prevent this behavior.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
