[jira] [Commented] (NET-397) FTPSClient does not handle AUTH or ADAT and only partially handles PBSZ. FTPSCommand should be deprecated
[ https://issues.apache.org/jira/browse/NET-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13014827#comment-13014827 ] Sebb commented on NET-397: -- Cannot change the values for the FTPSCommand entries now, as that's not backwards compatible, though that would have been a possible "solution" originally. > FTPSClient does not handle AUTH or ADAT and only partially handles PBSZ. > FTPSCommand should be deprecated > -- > > Key: NET-397 > URL: https://issues.apache.org/jira/browse/NET-397 > Project: Commons Net > Issue Type: Bug >Reporter: Sebb > Fix For: 3.0 > > Attachments: ftps-rfc2228.diff > > > FTPSClient does not provide any code to handle AUTH or ADAT, and does not > provide support for handling a reduced buffer size provided by the server. > FTPSCommand defines int values for AUTH and ADAT, but if the integer values > are used by client code, the value will be passed to FTPClient, which uses > its own array of command strings, and FTPSCommand.AUTH will translate to > "USER" and ADAT => "PASS", similarly for PBSZ, PROT and CCC. > These commands all need special handling, so should be dealt with by > FTPSClient only. > FTPSClient can override the sendCommand(int) and sendCommand(int, String) > methods in FTPClient which will help prevent problems. > Since most of these commands need additional special handling, there should > be execNAME() methods for each. > FTPSCommand should be deprecated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-397) FTPSClient does not handle AUTH or ADAT and only partially handles PBSZ. FTPSCommand should be deprecated
[ https://issues.apache.org/jira/browse/NET-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13014783#comment-13014783 ] Bogdan Drozdowski commented on NET-397: --- Deprecating FTPSCommand is probably a good idea, because commands shouldn't be spread among many files. But before the file gets removed, how about increasing the integer constants somewhere over the number of commands in FTPCOmmand? Like AUTH=100, ADAT=101 and so on. This would no more make conflicts. Then change the command array in FTPSCommand to have the right number of null entries before the right commands (static initializer block). And if the index given to getCommand() is too low, FTPSCommand could even delegate the call to FTPCommand. You're right about sendCommand() not being able to distinguish what to use, but the new indices in FTPSCommand would fix this. Yes, if had been an enum from the beginning, there wouldn't be problems like this, because the sendCommand() methods would have different signatures. But still either the commands would be spread among 2 files or all would be in FTPCommand and the plain FTPClient would now have to accept FTP-only commands and FTPSClient - FTPS commands (and delegate the rest to FTPClient). Now that we have execXXX() methods, FTPSCommand is unused. Just parsing the PBSZ reply is still a good idea - the user can call setSendBufferSize()/setReceiveBufferSize() if this is the right thing to do. Although isProtectedReplyCode() is FTPS-specific, it's a good idea that it's now in FTPReply - everything in one place. I keep command names public, so the users can send them manually, if they want (like when they think Base64 or something else is buggy), but otherwise there are no other reasons to do this. No other issues right now. If I find something about PBSZ that would be worth implementing separately, I'll let you know. > FTPSClient does not handle AUTH or ADAT and only partially handles PBSZ. > FTPSCommand should be deprecated > -- > > Key: NET-397 > URL: https://issues.apache.org/jira/browse/NET-397 > Project: Commons Net > Issue Type: Bug >Reporter: Sebb > Fix For: 3.0 > > Attachments: ftps-rfc2228.diff > > > FTPSClient does not provide any code to handle AUTH or ADAT, and does not > provide support for handling a reduced buffer size provided by the server. > FTPSCommand defines int values for AUTH and ADAT, but if the integer values > are used by client code, the value will be passed to FTPClient, which uses > its own array of command strings, and FTPSCommand.AUTH will translate to > "USER" and ADAT => "PASS", similarly for PBSZ, PROT and CCC. > These commands all need special handling, so should be dealt with by > FTPSClient only. > FTPSClient can override the sendCommand(int) and sendCommand(int, String) > methods in FTPClient which will help prevent problems. > Since most of these commands need additional special handling, there should > be execNAME() methods for each. > FTPSCommand should be deprecated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-547) KMeansPlusPlusClusterer should not call equals()
[ https://issues.apache.org/jira/browse/MATH-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated MATH-547: - Attachment: MATH-547.patch Added a simple patch to prevent comparing cluster centroids as an exit condition. Instead, the assignments of the data points to the clusters are tracked using an int array. > KMeansPlusPlusClusterer should not call equals() > > > Key: MATH-547 > URL: https://issues.apache.org/jira/browse/MATH-547 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Nate Paymer >Priority: Minor > Attachments: MATH-547.patch > > > In determining whether the clusters have changed between iterations, the > KMeansPlusPlusClusterer currently calls equals to determine whether the > cluster centers have changed. It would be better to avoid relying on equals > by instead checking whether any points have moved between clusters. > equals can be problematic because floating point operations are not strictly > commutative or associative, so getCentroid may return slightly different > values even when called with the same set of inputs. Additionally, the > client may choose not to override equals at all, since it's not clear that > it's required. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-267) Implement Iterable versions of methods that currently provide an Iterator
[ https://issues.apache.org/jira/browse/IO-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13014622#comment-13014622 ] Sebb commented on IO-267: - Duh! Should have noticed that. Perhaps the Javadoc should explicitly say that the listFiles() versions are suitable for use with "foreach" loops. > Implement Iterable versions of methods that currently provide an Iterator > - > > Key: IO-267 > URL: https://issues.apache.org/jira/browse/IO-267 > Project: Commons IO > Issue Type: New Feature >Reporter: Sebb > > It would be useful to be able to use methods such as FileUtils.iterateFiles() > in a foreach loop. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-267) Implement Iterable versions of methods that currently provide an Iterator
[ https://issues.apache.org/jira/browse/IO-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-267. Resolution: Won't Fix You can use FileUtils.listFiles() - http://tinyurl.com/3bs9uya > Implement Iterable versions of methods that currently provide an Iterator > - > > Key: IO-267 > URL: https://issues.apache.org/jira/browse/IO-267 > Project: Commons IO > Issue Type: New Feature >Reporter: Sebb > > It would be useful to be able to use methods such as FileUtils.iterateFiles() > in a foreach loop. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-267) Implement Iterable versions of methods that currently provide an Iterator
Implement Iterable versions of methods that currently provide an Iterator - Key: IO-267 URL: https://issues.apache.org/jira/browse/IO-267 Project: Commons IO Issue Type: New Feature Reporter: Sebb It would be useful to be able to use methods such as FileUtils.iterateFiles() in a foreach loop. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-552) MultidimensionalCounter.getCounts(int) returns wrong array of indices
[
https://issues.apache.org/jira/browse/MATH-552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved MATH-552.
-
Resolution: Fixed
Fix Version/s: 3.0
Oops, I wrote this code :(. Many thanks for finding out and fixing that bug.
Patch applied in revision 1087637.
> MultidimensionalCounter.getCounts(int) returns wrong array of indices
> -
>
> Key: MATH-552
> URL: https://issues.apache.org/jira/browse/MATH-552
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Java 1.6
>Reporter: James Bence
>Priority: Minor
> Fix For: 3.0
>
> Attachments: MultidimensionalCounter.patch
>
>
> MultidimensionalCounter counter = new MultidimensionalCounter(2, 4);
> for (Integer i : counter) {
> int[] x = counter.getCounts(i);
> System.out.println(i + " " + Arrays.toString(x));
> }
> Output is:
> 0 [0, 0]
> 1 [0, 1]
> 2 [0, 2]
> 3 [0, 2] <=== should be [0, 3]
> 4 [1, 0]
> 5 [1, 1]
> 6 [1, 2]
> 7 [1, 2] <=== should be [1, 3]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-549) Suggestion: Make PearsonsCorrelation.correlation(double[], double[]) static
[ https://issues.apache.org/jira/browse/MATH-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-549. - Resolution: Won't Fix Reverted to original code (revision 1087630) as this was done on purpose (to allow overriding). > Suggestion: Make PearsonsCorrelation.correlation(double[], double[]) static > --- > > Key: MATH-549 > URL: https://issues.apache.org/jira/browse/MATH-549 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Tomas Salfischberger >Priority: Minor > Fix For: 3.0 > > > Making PearsonsCorrelation.correlation(double[], double[]) static would allow > for calculating a correlation without instantiating a PearsonsCorrelation > object. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
