[jira] [Commented] (MATH-1026) Separate Optimization Problem from Algorithm
[ https://issues.apache.org/jira/browse/MATH-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13751732#comment-13751732 ] Gilles commented on MATH-1026: -- bq. I re-factored the tests [...] What is the advantage over inheriting the test and overriding a "getOptimizer()" method? It is rather confusing to have all those changes together because simple checks (e.g. compare the number of tests run) are not simple anymore... You should really mention that on the ML, and get some other people agree to that move. I'm off for a week now. > Separate Optimization Problem from Algorithm > > > Key: MATH-1026 > URL: https://issues.apache.org/jira/browse/MATH-1026 > Project: Commons Math > Issue Type: Improvement >Reporter: Evan Ward > Attachments: opt.tar.gz > > > See discussion on the mailing list starting with: > http://www.mail-archive.com/dev@commons.apache.org/msg39681.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-1026) Separate Optimization Problem from Algorithm
[ https://issues.apache.org/jira/browse/MATH-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13751699#comment-13751699 ] Evan Ward commented on MATH-1026: - I re-factored the tests so that I could run all of the tests on different configurations of each optimizer. testLevenberMarquardtOptimizer() calls check(LSOptimizer), which then calls all of the individual test methods with the given optimizer. I used this to test LU and QR with GN. For LM I just used the default parameters. > Separate Optimization Problem from Algorithm > > > Key: MATH-1026 > URL: https://issues.apache.org/jira/browse/MATH-1026 > Project: Commons Math > Issue Type: Improvement >Reporter: Evan Ward > Attachments: opt.tar.gz > > > See discussion on the mailing list starting with: > http://www.mail-archive.com/dev@commons.apache.org/msg39681.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-1026) Separate Optimization Problem from Algorithm
[
https://issues.apache.org/jira/browse/MATH-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13751693#comment-13751693
]
Gilles commented on MATH-1026:
--
Running
{noformat}
mvn -Dtest=LevenbergMarquardtOptimizerTest test
{noformat}
I get:
{noformat}
Running
org.apache.commons.math3.optim.nonlinear.vector.jacobian.LevenbergMarquardtOptimizerTest
Tests run: 23, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.3 sec - in
org.apache.commons.math3.optim.nonlinear.vector.jacobian.LevenbergMarquardtOptimizerTest
Running
org.apache.commons.math3.optimization.general.LevenbergMarquardtOptimizerTest
Tests run: 22, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.205 sec - in
org.apache.commons.math3.optimization.general.LevenbergMarquardtOptimizerTest
Running
org.apache.commons.math3.fitting.leastsquares2.LevenbergMarquardtOptimizerTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.075 sec - in
org.apache.commons.math3.fitting.leastsquares2.LevenbergMarquardtOptimizerTest
Running
org.apache.commons.math3.fitting.leastsquares.LevenbergMarquardtOptimizerTest
Tests run: 23, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.091 sec - in
org.apache.commons.math3.fitting.leastsquares.LevenbergMarquardtOptimizerTest
{noformat}
Oops!
Looks like you forgot to annotate the test methods in
{{AbstractLeastSquaresOptimizerAbstractTest}}...
> Separate Optimization Problem from Algorithm
>
>
> Key: MATH-1026
> URL: https://issues.apache.org/jira/browse/MATH-1026
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Evan Ward
> Attachments: opt.tar.gz
>
>
> See discussion on the mailing list starting with:
> http://www.mail-archive.com/dev@commons.apache.org/msg39681.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JCI-74) FilesystemAlterationMonitor.delay is not safely published
[ https://issues.apache.org/jira/browse/JCI-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved JCI-74. - Resolution: Fixed Fix Version/s: 1.1 URL: http://svn.apache.org/r1517922 Log: JCI-74 - FilesystemAlterationMonitor.delay is not safely published Modified: commons/proper/jci/trunk/fam/src/main/java/org/apache/commons/jci/monitor/FilesystemAlterationMonitor.java > FilesystemAlterationMonitor.delay is not safely published > - > > Key: JCI-74 > URL: https://issues.apache.org/jira/browse/JCI-74 > Project: Commons JCI > Issue Type: Bug > Components: fam >Affects Versions: 1.0 >Reporter: Sebb > Fix For: 1.1 > > > The field FilesystemAlterationMonitor.delay is read by the daemon thread but > the writer and reader do not use synchronisation. > If the delay is changed after the thread is started, any changes may not be > seen by the thread (unsafe publication). > The delay field needs to be made volatile. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JCI-74) FilesystemAlterationMonitor.delay is not safely published
Sebb created JCI-74: --- Summary: FilesystemAlterationMonitor.delay is not safely published Key: JCI-74 URL: https://issues.apache.org/jira/browse/JCI-74 Project: Commons JCI Issue Type: Bug Components: fam Affects Versions: 1.0 Reporter: Sebb The field FilesystemAlterationMonitor.delay is read by the daemon thread but the writer and reader do not use synchronisation. If the delay is changed after the thread is started, any changes may not be seen by the thread (unsafe publication). The delay field needs to be made volatile. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-468) Request for native support for socks proxy routing with Commons net FTP
[ https://issues.apache.org/jira/browse/NET-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-468: - Fix Version/s: 3.2 > Request for native support for socks proxy routing with Commons net FTP > --- > > Key: NET-468 > URL: https://issues.apache.org/jira/browse/NET-468 > Project: Commons Net > Issue Type: Improvement > Components: FTP >Affects Versions: 1.4, 2.0, 3.0.1, 3.1 > Environment: We use commons net in out products for all > communication to an FTP server. OS : All. No other environment specifications. >Reporter: Ramya Rajendiran > Fix For: 3.2 > > Attachments: sockclient-proxy3.diff, sockclient-proxy4.diff, > sockclient-proxy5.diff, sockclient-proxy6.diff, sockclient-proxy7.diff > > > Commons net currently does not natively support connection to an FTP server > via a socks proxy. The only way of achieving this would be to work at the > socket level as observed here > http://wiki.apache.org/commons/Net/FrequentlyAskedQuestions. (by setting JVM > properties socksProxyPort and socksProxyPortHost) > However, a major side effect of this all connections on this JVM will go > through the socks proxy since this setting is at the JVM level. This is > sometimes undesirable as the business requirements are such that only certain > applications on the JVM need to go through the socks proxy. There are no > existing workarounds to conditionally prevent other applications to not be > routed through the socks proxy. This makes our application which consumes the > commons net unusable for such businesses. > Providing native support for socks proxy with commons net for FTP, will go a > long way in supporting such common scenarios and business continuity. > Therefore raising this enhancement request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (MATH-1026) Separate Optimization Problem from Algorithm
[ https://issues.apache.org/jira/browse/MATH-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13751436#comment-13751436 ] Evan Ward edited comment on MATH-1026 at 8/27/13 4:57 PM: -- Changed files attached in opt.tar.gz Same as in https://github.com/apache/commons-math/pull/2 was (Author: evanward1): Changed files attached in opt.tar.gz > Separate Optimization Problem from Algorithm > > > Key: MATH-1026 > URL: https://issues.apache.org/jira/browse/MATH-1026 > Project: Commons Math > Issue Type: Improvement >Reporter: Evan Ward > Attachments: opt.tar.gz > > > See discussion on the mailing list starting with: > http://www.mail-archive.com/dev@commons.apache.org/msg39681.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-1026) Separate Optimization Problem from Algorithm
[ https://issues.apache.org/jira/browse/MATH-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evan Ward updated MATH-1026: Attachment: opt.tar.gz Changed files attached in opt.tar.gz > Separate Optimization Problem from Algorithm > > > Key: MATH-1026 > URL: https://issues.apache.org/jira/browse/MATH-1026 > Project: Commons Math > Issue Type: Improvement >Reporter: Evan Ward > Attachments: opt.tar.gz > > > See discussion on the mailing list starting with: > http://www.mail-archive.com/dev@commons.apache.org/msg39681.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-280) Dubious use of mkdirs() return code
[
https://issues.apache.org/jira/browse/IO-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated IO-280:
Description:
FileUtils.openOutputStream() has the following code:
{code}
File parent = file.getParentFile();
if (parent != null && parent.exists() == false) {
if (parent.mkdirs() == false) {
throw new IOException("File '" + file + "' could not be created");
}
}
{code}
Now mkdirs() returns true only if the method actually created the directories;
it's theoretically possible for the directory to be created in the window
between the exists() and mkdirs() invocations. [Indeed the class actually
checks for this in the forceMkdir() method]
It would be safer to use:
{code}
File parent = file.getParentFile();
if (parent != null && !parent.mkdirs() && !parent.isDirectory()) {
throw new IOException("Directory '" + parent + "' could not be created");
// note changed text
}
{code}
Similarly elsewhere in the class where mkdirs() is used.
was:
FileUtils.openOutputStream() has the following code:
{code}
File parent = file.getParentFile();
if (parent != null && parent.exists() == false) {
if (parent.mkdirs() == false) {
throw new IOException("File '" + file + "' could not be created");
}
}
{code}
Now mkdirs() returns true only if the method actually created the directories;
it's theoretically possible for the directory to be created in the window
between the exists() and mkdirs() invocations. [Indeed the class actually
checks for this in the forceMkdir() method]
It would be safer to use:
{code}
File parent = file.getParentFile();
if (parent != null && !parent.mkdirs() && !parent.isDirectory()) {
throw new IOException("Directory '" + parent + "' could not be
created"); // note changed text
}
}
{code}
Similarly elsewhere in the class where mkdirs() is used.
> Dubious use of mkdirs() return code
> ---
>
> Key: IO-280
> URL: https://issues.apache.org/jira/browse/IO-280
> Project: Commons IO
> Issue Type: Bug
>Reporter: Sebb
>Priority: Minor
> Fix For: 2.1
>
>
> FileUtils.openOutputStream() has the following code:
> {code}
> File parent = file.getParentFile();
> if (parent != null && parent.exists() == false) {
> if (parent.mkdirs() == false) {
> throw new IOException("File '" + file + "' could not be created");
> }
> }
> {code}
> Now mkdirs() returns true only if the method actually created the
> directories; it's theoretically possible for the directory to be created in
> the window between the exists() and mkdirs() invocations. [Indeed the class
> actually checks for this in the forceMkdir() method]
> It would be safer to use:
> {code}
> File parent = file.getParentFile();
> if (parent != null && !parent.mkdirs() && !parent.isDirectory()) {
> throw new IOException("Directory '" + parent + "' could not be created");
> // note changed text
> }
> {code}
> Similarly elsewhere in the class where mkdirs() is used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JCI-67) Dubious use of mkdirs() return code
[
https://issues.apache.org/jira/browse/JCI-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved JCI-67.
-
Resolution: Fixed
URL: http://svn.apache.org/r1517840
Log:
JCI-67 Dubious use of mkdirs() return code
Modified:
commons/proper/jci/trunk/core/src/main/java/org/apache/commons/jci/stores/FileResourceStore.java
commons/proper/jci/trunk/core/src/test/java/org/apache/commons/jci/AbstractTestCase.java
commons/proper/jci/trunk/fam/src/test/java/org/apache/commons/jci/monitor/FilesystemAlterationMonitorTestCase.java
> Dubious use of mkdirs() return code
> ---
>
> Key: JCI-67
> URL: https://issues.apache.org/jira/browse/JCI-67
> Project: Commons JCI
> Issue Type: Bug
>Reporter: Sebb
>Priority: Minor
> Fix For: 1.1
>
>
> FileRestoreStore.java uses mkdirs() as follows:
> {code}
> final File parent = file.getParentFile();
> if (!parent.exists()) {
> if (!parent.mkdirs()) {
> throw new IOException("could not create" + parent);
> }
> }
> {code}
> Now mkdirs() returns true *only* if the method actually created the
> directories; it's theoretically possible for the directory to be created in
> the window between the exists() and mkdirs() invocations.
> Also, the initial exists() call is redundant, because that's what mkdirs()
> does anyway (in the RI implementation, at least).
> I suggest the following instead:
> {code}
> final File parent = file.getParentFile();
> if (!parent.mkdirs() && !parent.exists()) {
> throw new IOException("could not create" + parent);
> }
> }
> {code}
> If mkdirs() returns false, the code then checks to see if the directory
> exists, so the throws clause will only be invoked if the parent really cannot
> be created.
> The same code also appears in AbstractTestCase and
> FilesystemAlterationMonitorTestCase.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (JCI-67) Dubious use of mkdirs() return code
[
https://issues.apache.org/jira/browse/JCI-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13085339#comment-13085339
]
Sebb edited comment on JCI-67 at 8/27/13 2:54 PM:
--
Safer would be the following, as it checks the path is actually a directory:
{code}
final File parent = file.getParentFile();
if (!parent.mkdirs() && !parent.isDirectory()) {
throw new IOException("could not create" + parent);
}
{code}
was (Author: s...@apache.org):
Safer would be the following, as it checks the path is actually a directory:
{code}
final File parent = file.getParentFile();
if (!parent.mkdirs() && !parent.isDirectory()) {
throw new IOException("could not create" + parent);
}
}
{code}
> Dubious use of mkdirs() return code
> ---
>
> Key: JCI-67
> URL: https://issues.apache.org/jira/browse/JCI-67
> Project: Commons JCI
> Issue Type: Bug
>Reporter: Sebb
>Priority: Minor
> Fix For: 1.1
>
>
> FileRestoreStore.java uses mkdirs() as follows:
> {code}
> final File parent = file.getParentFile();
> if (!parent.exists()) {
> if (!parent.mkdirs()) {
> throw new IOException("could not create" + parent);
> }
> }
> {code}
> Now mkdirs() returns true *only* if the method actually created the
> directories; it's theoretically possible for the directory to be created in
> the window between the exists() and mkdirs() invocations.
> Also, the initial exists() call is redundant, because that's what mkdirs()
> does anyway (in the RI implementation, at least).
> I suggest the following instead:
> {code}
> final File parent = file.getParentFile();
> if (!parent.mkdirs() && !parent.exists()) {
> throw new IOException("could not create" + parent);
> }
> }
> {code}
> If mkdirs() returns false, the code then checks to see if the directory
> exists, so the throws clause will only be invoked if the parent really cannot
> be created.
> The same code also appears in AbstractTestCase and
> FilesystemAlterationMonitorTestCase.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-1027) Create "Combinations" class
Gilles created MATH-1027: Summary: Create "Combinations" class Key: MATH-1027 URL: https://issues.apache.org/jira/browse/MATH-1027 Project: Commons Math Issue Type: Task Reporter: Gilles Priority: Minor Fix For: 3.3 A new class will be created (with most of the code already implemented by Phil in "combinationIterator" method in "o.a.c.m.util.CombinatoricsUtils"). Cf. the [conclusion|http://markmail.org/message/2al2cxi4c4ce37lk] of a discussion on the ML. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
