date:20111107


 [ 
https://issues.apache.org/jira/browse/NET-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Allen Atamer updated NET-429:
-

Description: 
Using the FTPClient object in commons net the way it is shown in the Javadoc 
results in a file that is 0 bytes on the remote host. When you get to the 
storeFile(..) method, it waits for about 20 seconds before it returns the error 
message shown to System.out.

I've tried a number of different things

1. commons-net version 3.0.1 (supposedly had the bug fix for this, but didn't 
work for me)
2. [boolean] storeFile (String, InputStream)
3. [OutputStream] storeFile (String)
4. commons-net version 1.4 (still no dice)

Here's my code:
{quote}
boolean error = false;
FTPClient ftp = new FTPClient();
InputStream localStream = null;
try {
int reply;
String server = ftp.myserver.com;
ftp.connect(server, 21);
System.out.println(Connected to  + server + .);
System.out.print(ftp.getReplyString());

// After connection attempt, you should check the reply 
code to
// verify
// success.
reply = ftp.getReplyCode();

if (!FTPReply.isPositiveCompletion(reply)) {
ftp.disconnect();
System.err.println(FTP server refused 
connection.);
System.exit(1);
}
boolean wasSuccessful = ftp.login(user, password);
if (!wasSuccessful) {
System.err.println(Login unsuccessful);
System.exit(1);
}

System.out.println(login successful);
String localPath=C:/projects/TEMP/uga.html;
File localFile = new File(localPath);

if (localFile.exists()) {
localStream = new BufferedInputStream(new 
FileInputStream(localPath));
wasSuccessful = ftp.storeFile(uga.html, 
localStream);
if (!wasSuccessful) {
System.err.println(could not store 
file:  + localPath);
System.exit(1);
} else {
System.out.println(Successfully saved 
file!);
}
}


// transfer files
ftp.logout();
} catch (IOException e) {
error = true;
e.printStackTrace();
} finally {
if (ftp.isConnected()) {
try {
ftp.disconnect();
} catch (IOException ioe) {
// do nothing
}
}
if (localStream != null) {
try {
localStream.close();
} catch (IOException e) {
}
}
System.exit(error ? 1 : 0);
}
{quote}

Here's my System.out:

{quote}
Connected to ftp.harmari.com.
220-- Welcome to Pure-FTPd [privsep] [TLS] --
220-You are user number 16 of 500 allowed.
220-Local time is now 05:59. Server port: 21.
220-This is a private system - No anonymous login
220 You will be disconnected after 3 minutes of inactivity.
login successful
could not store file: 2482049866.html
{quote}

More background:
FileZilla works on my machine
I've also tried the primitive Sun API, and it works perfectly:
{quote}
try {
url = new 
URL(ftp://harmari:U!jxm9...@ftp.harmari.com/offline3/uga.html;type=i;);
URLConnection urlc = url.openConnection();
OutputStream os = urlc.getOutputStream(); // To upload

String localPath = C:/projects/TEMP/uga.html;
InputStream bis = new BufferedInputStream(new 
FileInputStream(localPath));

byte[] bstr = new byte[1024];
while (bis.read(bstr)  0) {
os.write(bstr); 
}
} catch (MalformedURLException e) {

[jira] [Updated] (NET-429) FTPClient storeFile method creates a file of 0 bytes


 [ 
https://issues.apache.org/jira/browse/NET-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Allen Atamer updated NET-429:
-

Environment: 
jdk1.6.0_27
Windows 7 Pro SP1 local machine
Uploading to a GoDaddy Linux shared hosting environment.  File is created with 
0x604 permissions.

  was:
jdk1.6.0_27
Windows 7 Pro SP1


 FTPClient storeFile method creates a file of 0 bytes
 

 Key: NET-429
 URL: https://issues.apache.org/jira/browse/NET-429
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 1.4, 3.0.1
 Environment: jdk1.6.0_27
 Windows 7 Pro SP1 local machine
 Uploading to a GoDaddy Linux shared hosting environment.  File is created 
 with 0x604 permissions.
Reporter: Allen Atamer
  Labels: bytes, ftp, storeFile, zero

 Using the FTPClient object in commons net the way it is shown in the Javadoc 
 results in a file that is 0 bytes on the remote host. When you get to the 
 storeFile(..) method, it waits for about 20 seconds before it returns the 
 error message shown to System.out.
 I've tried a number of different things
 1. commons-net version 3.0.1 (supposedly had the bug fix for this, but didn't 
 work for me)
 2. [boolean] storeFile (String, InputStream)
 3. [OutputStream] storeFile (String)
 4. commons-net version 1.4 (still no dice)
 Here's my code:
 {quote}
   boolean error = false;
   FTPClient ftp = new FTPClient();
   InputStream localStream = null;
   try {
   int reply;
   String server = ftp.myserver.com;
   ftp.connect(server, 21);
   System.out.println(Connected to  + server + .);
   System.out.print(ftp.getReplyString());
   // After connection attempt, you should check the reply 
 code to
   // verify
   // success.
   reply = ftp.getReplyCode();
   if (!FTPReply.isPositiveCompletion(reply)) {
   ftp.disconnect();
   System.err.println(FTP server refused 
 connection.);
   System.exit(1);
   }
   boolean wasSuccessful = ftp.login(user, password);
   if (!wasSuccessful) {
   System.err.println(Login unsuccessful);
   System.exit(1);
   }
   
   System.out.println(login successful);
   String localPath=C:/projects/TEMP/uga.html;
   File localFile = new File(localPath);
   
   if (localFile.exists()) {
   localStream = new BufferedInputStream(new 
 FileInputStream(localPath));
   wasSuccessful = ftp.storeFile(uga.html, 
 localStream);
   if (!wasSuccessful) {
   System.err.println(could not store 
 file:  + localPath);
   System.exit(1);
   } else {
   System.out.println(Successfully saved 
 file!);
   }
   }
   
   // transfer files
   ftp.logout();
   } catch (IOException e) {
   error = true;
   e.printStackTrace();
   } finally {
   if (ftp.isConnected()) {
   try {
   ftp.disconnect();
   } catch (IOException ioe) {
   // do nothing
   }
   }
   if (localStream != null) {
   try {
   localStream.close();
   } catch (IOException e) {
   }
   }
   System.exit(error ? 1 : 0);
   }
 {quote}
 Here's my System.out:
 {quote}
 Connected to ftp.harmari.com.
 220-- Welcome to Pure-FTPd [privsep] [TLS] --
 220-You are user number 16 of 500 allowed.
 220-Local time is now 05:59. Server port: 21.
 220-This is a private system - No anonymous login
 220 You will be disconnected after 3 minutes of inactivity.
 login successful
 could not store file: 2482049866.html
 {quote}
 More background:
 FileZilla works on my machine
 I've also tried the primitive Sun API, and it works perfectly:
 {quote}
   try {

[jira] [Updated] (NET-429) FTPClient storeFile method creates a file of 0 bytes


 [ 
https://issues.apache.org/jira/browse/NET-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Allen Atamer updated NET-429:
-

Description: 
Using the FTPClient object in commons net the way it is shown in the Javadoc 
results in a file that is 0 bytes on the remote host. When you get to the 
storeFile(..) method, it waits for about 20 seconds before it returns the error 
message shown to System.out.

I've tried a number of different things

1. commons-net version 3.0.1 (supposedly had the bug fix for this, but didn't 
work for me)
2. [boolean] storeFile (String, InputStream)
3. [OutputStream] storeFile (String)
4. commons-net version 1.4 (still no dice)
5. ftp.connect(server) and ftp.connect(server, 21)

Here's my code:
{quote}
boolean error = false;
FTPClient ftp = new FTPClient();
InputStream localStream = null;
try {
int reply;
String server = ftp.myserver.com;
ftp.connect(server, 21);
System.out.println(Connected to  + server + .);
System.out.print(ftp.getReplyString());

// After connection attempt, you should check the reply 
code to
// verify
// success.
reply = ftp.getReplyCode();

if (!FTPReply.isPositiveCompletion(reply)) {
ftp.disconnect();
System.err.println(FTP server refused 
connection.);
System.exit(1);
}
boolean wasSuccessful = ftp.login(user, password);
if (!wasSuccessful) {
System.err.println(Login unsuccessful);
System.exit(1);
}

System.out.println(login successful);
String localPath=C:/projects/TEMP/uga.html;
File localFile = new File(localPath);

if (localFile.exists()) {
localStream = new BufferedInputStream(new 
FileInputStream(localPath));
wasSuccessful = ftp.storeFile(uga.html, 
localStream);
if (!wasSuccessful) {
System.err.println(could not store 
file:  + localPath);
System.exit(1);
} else {
System.out.println(Successfully saved 
file!);
}
}


// transfer files
ftp.logout();
} catch (IOException e) {
error = true;
e.printStackTrace();
} finally {
if (ftp.isConnected()) {
try {
ftp.disconnect();
} catch (IOException ioe) {
// do nothing
}
}
if (localStream != null) {
try {
localStream.close();
} catch (IOException e) {
}
}
System.exit(error ? 1 : 0);
}
{quote}

Here's my System.out:

{quote}
Connected to ftp.harmari.com.
220-- Welcome to Pure-FTPd [privsep] [TLS] --
220-You are user number 16 of 500 allowed.
220-Local time is now 05:59. Server port: 21.
220-This is a private system - No anonymous login
220 You will be disconnected after 3 minutes of inactivity.
login successful
could not store file: 2482049866.html
{quote}

More background:
FileZilla works on my machine
I've also tried the primitive Sun API, and it works perfectly:
{quote}
try {
url = new 
URL(ftp://harmari:U!jxm9...@ftp.harmari.com/offline3/uga.html;type=i;);
URLConnection urlc = url.openConnection();
OutputStream os = urlc.getOutputStream(); // To upload

String localPath = C:/projects/TEMP/uga.html;
InputStream bis = new BufferedInputStream(new 
FileInputStream(localPath));

byte[] bstr = new byte[1024];
while (bis.read(bstr)  0) {
os.write(bstr); 
}

[jira] [Updated] (NET-429) FTPClient storeFile method creates a file of 0 bytes

2011-11-07 Thread Phil Steitz (Issue Comment Edited) (JIRA)


 [ 
https://issues.apache.org/jira/browse/NET-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Allen Atamer updated NET-429:
-

Description: 
Using the FTPClient object in commons net the way it is shown in the Javadoc 
results in a file that is 0 bytes on the remote host. When you get to the 
storeFile(..) method, it waits for about 20 seconds before it returns the error 
message shown to System.out.

I've tried a number of different things

1. commons-net version 3.0.1 (supposedly had the bug fix for this, but didn't 
work for me)
2. [boolean] storeFile (String, InputStream)
3. [OutputStream] storeFile (String)
4. commons-net version 1.4 (still no dice)
5. ftp.connect(server) and ftp.connect(server, 21)

Here's my code:
{quote}
boolean error = false;
FTPClient ftp = new FTPClient();
InputStream localStream = null;
try {
int reply;
String server = ftp.myserver.com;
ftp.connect(server, 21);
System.out.println(Connected to  + server + .);
System.out.print(ftp.getReplyString());

// After connection attempt, you should check the reply 
code to
// verify
// success.
reply = ftp.getReplyCode();

if (!FTPReply.isPositiveCompletion(reply)) {
ftp.disconnect();
System.err.println(FTP server refused 
connection.);
System.exit(1);
}
boolean wasSuccessful = ftp.login(user, password);
if (!wasSuccessful) {
System.err.println(Login unsuccessful);
System.exit(1);
}

System.out.println(login successful);
String localPath=C:/projects/TEMP/uga.html;
File localFile = new File(localPath);

if (localFile.exists()) {
localStream = new BufferedInputStream(new 
FileInputStream(localPath));
wasSuccessful = ftp.storeFile(uga.html, 
localStream);
if (!wasSuccessful) {
System.err.println(could not store 
file:  + localPath);
System.exit(1);
} else {
System.out.println(Successfully saved 
file!);
}
}


// transfer files
ftp.logout();
} catch (IOException e) {
error = true;
e.printStackTrace();
} finally {
if (ftp.isConnected()) {
try {
ftp.disconnect();
} catch (IOException ioe) {
// do nothing
}
}
if (localStream != null) {
try {
localStream.close();
} catch (IOException e) {
}
}
System.exit(error ? 1 : 0);
}
{quote}

Here's my System.out:

{quote}
Connected to ftp.harmari.com.
220-- Welcome to Pure-FTPd [privsep] [TLS] --
220-You are user number 16 of 500 allowed.
220-Local time is now 05:59. Server port: 21.
220-This is a private system - No anonymous login
220 You will be disconnected after 3 minutes of inactivity.
login successful
could not store file: 2482049866.html
{quote}

More background:
FileZilla works on my machine
I've also tried the primitive Sun API, and it works perfectly:
{quote}
try {
url = new 
URL(ftp://username:passw...@ftp.myserver.com/offline3/uga.html;type=i;);
URLConnection urlc = url.openConnection();
OutputStream os = urlc.getOutputStream(); // To upload

String localPath = C:/projects/TEMP/uga.html;
InputStream bis = new BufferedInputStream(new 
FileInputStream(localPath));

byte[] bstr = new byte[1024];
while (bis.read(bstr)  0) {
os.write(bstr); 
}

[jira] [Created] (MATH-702) CMA-ES optimizer input sigma should not be normalized by user

2011-11-07 Thread Luc Maisonobe (Created) (JIRA)

CMA-ES optimizer input sigma should not be normalized by user
-

 Key: MATH-702
 URL: https://issues.apache.org/jira/browse/MATH-702
 Project: Commons Math
  Issue Type: Bug
Affects Versions: 3.0
Reporter: Luc Maisonobe
Priority: Minor
 Fix For: 3.0


I am trying to use CMA-ES optimizer with simple boundaries.

It seems the inputSigma parameter should be normalized as it is checked against 
the [0 - 1] range in the checkParameters private method and as its value 
defaults to 0.3 if not not set in the initializeCMA private method.

I would have expected this value to be in the same units as the user parameters 
and to be normalized as part of an internal processing step instead of relying 
to the user doing this. I think the method need normalized values internally, 
as per the encode/decode methods in the inner class FitnessFunction suggest.

The optimizer should accept values in the same units as the other parameters 
and use encode (or a similar function) to do the normalization. This way, 
normalization is considered an internal implementation detail.



--
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-702) CMA-ES optimizer input sigma should not be normalized by user

2011-11-07 Thread Luc Maisonobe (Resolved) (JIRA)


 [ 
https://issues.apache.org/jira/browse/MATH-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luc Maisonobe resolved MATH-702.


Resolution: Fixed

Fixed in subversion repository as of r1198741.

 CMA-ES optimizer input sigma should not be normalized by user
 -

 Key: MATH-702
 URL: https://issues.apache.org/jira/browse/MATH-702
 Project: Commons Math
  Issue Type: Bug
Affects Versions: 3.0
Reporter: Luc Maisonobe
Priority: Minor
 Fix For: 3.0


 I am trying to use CMA-ES optimizer with simple boundaries.
 It seems the inputSigma parameter should be normalized as it is checked 
 against the [0 - 1] range in the checkParameters private method and as its 
 value defaults to 0.3 if not not set in the initializeCMA private method.
 I would have expected this value to be in the same units as the user 
 parameters and to be normalized as part of an internal processing step 
 instead of relying to the user doing this. I think the method need normalized 
 values internally, as per the encode/decode methods in the inner class 
 FitnessFunction suggest.
 The optimizer should accept values in the same units as the other parameters 
 and use encode (or a similar function) to do the normalization. This way, 
 normalization is considered an internal implementation detail.

--
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] (DIGESTER-158) Use the APT to process Digester Annotations and generate RulesModule instances at compile-time

2011-11-07 Thread Matt Benson (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/DIGESTER-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145517#comment-13145517
 ] 

Matt Benson commented on DIGESTER-158:
--

No, not that I've heard.  There is the com.sun.codemodel that more than one 
person has used; this is what my (again, untested) code uses.

 Use the APT to process Digester Annotations and generate RulesModule 
 instances at compile-time
 --

 Key: DIGESTER-158
 URL: https://issues.apache.org/jira/browse/DIGESTER-158
 Project: Commons Digester
  Issue Type: New Feature
Affects Versions: 3.2
Reporter: Simone Tripodi
Assignee: Simone Tripodi
 Fix For: 3.2


 Using the [APT 
 Tool|http://download.oracle.com/javase/1,5.0/docs/guide/apt/GettingStarted.html]
  it would be possible to process Digester annotations rules and generate 
 {{RulesModule}} instances at compile time.

--
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-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau

2011-11-07 Thread Phil Steitz (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145544#comment-13145544
 ] 

Phil Steitz commented on MATH-699:
--

My inclination would be to keep the implementation in the base class as simple 
as possible, documenting what it does and pushing the responsibility for 
dealing with plateaus in the distribution to the implementations that have 
these.  I don't think any of the currently implemented real distributions have 
this problem.  Correct?  

The invariant you are proposing for when to return infinities for domain lower 
and upper bounds would make sense if these were intended to be the bounds of 
support for the distribution, but this is not what these properties represent.  
They are initial guesses for where to start when trying to bracket a root.  
That means they have to be values that can be fed into the cumulative 
probability function. Have you convinced yourself that we do not need to 
bracket a root at the beginning?  What bounds would we then provide to the 
solver?  The code you reference is trying to do the bracketing, starting with 
the domain upper and lower bounds as initial guesses.  

Remember to consider convergence problems when the actual parameter to inverse 
cum is close to or exactly equal to 0 or 1.  Per the comment in the code above 
the test that uses (or should use) the function value absolute accuracy, if the 
distribution has bounded support and the argument is 0 or 1, bracketing will 
fail.



 inverseCumulativeDistribution fails with cumulative distribution having a 
 plateau
 -

 Key: MATH-699
 URL: https://issues.apache.org/jira/browse/MATH-699
 Project: Commons Math
  Issue Type: Bug
Affects Versions: 3.0
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Priority: Minor
 Attachments: AbstractContinuousDistributionTest.java


 This bug report follows MATH-692. The attached unit test fails. As required 
 by the definition in MATH-692, the lower-bound of the interval on which the 
 cdf is constant should be returned. This is not so at the moment.

--
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-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau


[ 
https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145544#comment-13145544
 ] 

Phil Steitz edited comment on MATH-699 at 11/7/11 3:18 PM:
---

My inclination would be to keep the implementation in the base class as simple 
as possible, documenting what it does and pushing the responsibility for 
dealing with plateaus in the distribution to the implementations that have 
these.  I don't think any of the currently implemented real distributions have 
this problem.  Correct?  

The invariant you are proposing for when to return infinities for domain lower 
and upper bounds would make sense if these were intended to be the bounds of 
support for the distribution, but this is not what these properties represent.  
They are initial guesses for where to start when trying to bracket a root.  
That means they have to be values that can be fed into the cumulative 
probability function. I may be missing the point that you and Christian are 
making, but the basic problem is that as Christian points out, we always need 
to start with finite values and that is what led to the somewhat inelegant 
construct of the domain lower/upper bounds as guesses and the need to do the 
bracketing step.  The code you reference is trying to do the bracketing, 
starting with the domain upper and lower bounds as initial guesses.  

Remember to consider convergence problems when the actual parameter to inverse 
cum is close to or exactly equal to 0 or 1.  Per the comment in the code above 
the test that uses (or should use) the function value absolute accuracy, if the 
distribution has bounded support and the argument is 0 or 1, bracketing will 
fail.



  was (Author: psteitz):
My inclination would be to keep the implementation in the base class as 
simple as possible, documenting what it does and pushing the responsibility for 
dealing with plateaus in the distribution to the implementations that have 
these.  I don't think any of the currently implemented real distributions have 
this problem.  Correct?  

The invariant you are proposing for when to return infinities for domain lower 
and upper bounds would make sense if these were intended to be the bounds of 
support for the distribution, but this is not what these properties represent.  
They are initial guesses for where to start when trying to bracket a root.  
That means they have to be values that can be fed into the cumulative 
probability function. Have you convinced yourself that we do not need to 
bracket a root at the beginning?  What bounds would we then provide to the 
solver?  The code you reference is trying to do the bracketing, starting with 
the domain upper and lower bounds as initial guesses.  

Remember to consider convergence problems when the actual parameter to inverse 
cum is close to or exactly equal to 0 or 1.  Per the comment in the code above 
the test that uses (or should use) the function value absolute accuracy, if the 
distribution has bounded support and the argument is 0 or 1, bracketing will 
fail.


  
 inverseCumulativeDistribution fails with cumulative distribution having a 
 plateau
 -

 Key: MATH-699
 URL: https://issues.apache.org/jira/browse/MATH-699
 Project: Commons Math
  Issue Type: Bug
Affects Versions: 3.0
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Priority: Minor
 Attachments: AbstractContinuousDistributionTest.java


 This bug report follows MATH-692. The attached unit test fails. As required 
 by the definition in MATH-692, the lower-bound of the interval on which the 
 cdf is constant should be returned. This is not so at the moment.

--
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] (DAEMON-227) Support both flavors of Java on HP-UX IA64


 [ 
https://issues.apache.org/jira/browse/DAEMON-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mladen Turk resolved DAEMON-227.


   Resolution: Fixed
Fix Version/s: 1.0.8

Fixed HP-UX configure on IA64
For 32-bit use ./configure --build i386-hp-hpux11
For 64-bit use ./configure


 Support both flavors of Java on HP-UX IA64
 --

 Key: DAEMON-227
 URL: https://issues.apache.org/jira/browse/DAEMON-227
 Project: Commons Daemon
  Issue Type: Improvement
  Components: Jsvc
Affects Versions: Nightly Builds
Reporter: Michael Osipov
Assignee: Mladen Turk
Priority: Minor
 Fix For: 1.0.8

 Attachments: DAEMON-227.patch


 Compared to Linux and other OS on IA64, HP delivers two types of JVMs in 
 IA64. A normal (32 bit) and a wide (64 bit). Any binary or lib can be 
 compiled that way.
 {noformat}
 smartld@blnn721x - /opt/java6/jre/lib
 bash $ ll | grep  '^d'
 dr-xr-xr-x  19 binbin   8192 Jun 28 12:20 ./
 dr-xr-xr-x   8 binbin   8192 Jan 22  2009 ../
 dr-xr-xr-x   8 binbin   8192 Jun 28 12:20 IA64N/
 dr-xr-xr-x   8 binbin   8192 Jun 28 12:20 IA64W/
 dr-xr-xr-x   3 binbin 96 Dec  4  2007 PA_RISC2.0/
 dr-xr-xr-x   2 binbin 96 Oct 16  2009 applet/
 dr-xr-xr-x   2 binbin 96 Dec  4  2007 audio/
 ...
 {noformat}
 The apsupport.m4 does not reflect that in ia64). I have adapted it to support 
 both options. Default is 32 bit build on HP-UX 64 bit can be enabled with a 
 switch.

--
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] (COMPRESS-161) bzip2 decompression terminates after 900000 bytes

2011-11-07 Thread Stefan Bodewig (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/COMPRESS-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145550#comment-13145550
 ] 

Stefan Bodewig commented on COMPRESS-161:
-

I can confirm the limit with the file you have attached.  At the same time I 
can easily uncompress even larger files completely so there must be something 
specific to the archive you are using.

Any hints on how you have created it?

 bzip2 decompression terminates after 90 bytes
 -

 Key: COMPRESS-161
 URL: https://issues.apache.org/jira/browse/COMPRESS-161
 Project: Commons Compress
  Issue Type: Bug
  Components: Compressors
Affects Versions: 1.3
 Environment: Windows7 64bit JDK7u1,2
Reporter: Hans horn
Priority: Critical
 Fix For: 1.3

 Attachments: INT1_aminey.inp.bz2


 bzip2 decompression terminates (w/o error) after 90 bytes
 try {
   InputStream iin = new BZip2CompressorInputStream(new 
 FileInputStream(bzip2 compressed file that was uncompressed  90 bytes in 
 size);
   int data = iin.read();
   while (data != -1) {
 System.out.print((char) data); ++nBytes;
 data = iin.read();
   }
 } catch (IOException iox) { /**/ }
 System.out.println(#Bytes read  + nBytes);
 prints: #Bytes read 90

--
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] (DAEMON-228) Add default location of JDK and libjvm on HP-UX IA64


 [ 
https://issues.apache.org/jira/browse/DAEMON-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mladen Turk resolved DAEMON-228.


   Resolution: Fixed
Fix Version/s: 1.0.8

Fixed by using correct CPU and new SO_EXT inside configure.
Added some parts from your patch like /opt/java* stuff

 Add default location of JDK and libjvm on HP-UX IA64
 

 Key: DAEMON-228
 URL: https://issues.apache.org/jira/browse/DAEMON-228
 Project: Commons Daemon
  Issue Type: Improvement
  Components: Jsvc
Affects Versions: Nightly Builds
Reporter: Michael Osipov
Assignee: Mladen Turk
Priority: Minor
 Fix For: 1.0.8

 Attachments: DAEMON-228.patch


 1. Added two more recent JDK locations.
 2. libraries on IA64 end with .so and PA-RISC on .sl. I have added a further 
 flag to switch between these.
 {noformat}
 smartld@blnn721x - /opt/java6/jre/lib/IA64N/server
 bash $ ll
 total 308976
 -r-xr-xr-x   1 binbin76798188 May 11  2010 #libjvm.so*
 dr-xr-xr-x   2 binbin   8192 Jun 28 12:20 ./
 dr-xr-xr-x   8 binbin   8192 Jun 28 12:20 ../
 -r--r--r--   1 binbin   2400 Mar 11  2011 Xusage.txt
 lr-xr-xr-x   1 binbin 13 Jun 28 12:20 libjsig.so@ - 
 ../libjsig.so
 -r-xr-xr-x   1 binbin 234296 Mar 11  2011 libjunwind.so*
 -r-xr-xr-x   1 binbin 238304 Mar 11  2011 libjunwind64.so*
 -r-xr-xr-x   1 binbin80868772 Mar 11  2011 libjvm.so*
 {noformat}
 This patch includes DAEMON-227. If 227 is applied separately, I can recreate 
 this 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] [Resolved] (DAEMON-136) Jsvc does not exit when all non-daemon threads are died


 [ 
https://issues.apache.org/jira/browse/DAEMON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mladen Turk resolved DAEMON-136.


Resolution: Incomplete

Please provide a test case so we can verify your claims.
I'm closing this issue, but you are free to reopen it
wit something we can use for testing

 Jsvc does not exit when all non-daemon threads are died
 ---

 Key: DAEMON-136
 URL: https://issues.apache.org/jira/browse/DAEMON-136
 Project: Commons Daemon
  Issue Type: Bug
  Components: Jsvc
Affects Versions: 1.0.2
 Environment: Ubuntu 9.10, Sun Java 1.6.0_16
Reporter: Hontvari Jozsef
Priority: Minor
 Attachments: stack, stack-long, stack-mixed-long


 A jsvc dameon keeps running even if all non-dameon Java threads are exited. 
 It can be reproduced by creating a start class with the usual four, but empty 
 functions. The symtom does not change if init() takes a few seconds of time.  
 I have attached three stack traces, using different jstack options, I don't 
 see anything special, however.
 The workaround is to explicitly call System.exit() at places where the system 
 can finish its work.

--
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] (COMPRESS-111) support for lzma files

2011-11-07 Thread Stefan Bodewig (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/COMPRESS-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145564#comment-13145564
 ] 

Stefan Bodewig commented on COMPRESS-111:
-

I think support for the old lzma format would be beneficial for all people 
having to deal with legacy archives, so at least read-only support would be 
great.

Then again adding write support won't hurt either.  We could recommend people 
use XZ instead inside the docs, of course.


 support for lzma files
 --

 Key: COMPRESS-111
 URL: https://issues.apache.org/jira/browse/COMPRESS-111
 Project: Commons Compress
  Issue Type: New Feature
  Components: Compressors
Affects Versions: 1.0
Reporter: maurel jean francois
 Attachments: compress-trunk-lzmaRev0.patch, 
 compress-trunk-lzmaRev1.patch


 adding support for compressing and decompressing of files with LZMA algoritm 
 (Lempel-Ziv-Markov chain-Algorithm)
 (see 
 http://markmail.org/search/?q=list%3Aorg.apache.commons.users/#query:list%3Aorg.apache.commons.users%2F+page:1+mid:syn4uuvbzusevtko+state:results)

--
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] (DAEMON-216) Add command line switch to hide console window when switch --type interactive is used.


 [ 
https://issues.apache.org/jira/browse/DAEMON-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mladen Turk resolved DAEMON-216.


   Resolution: Fixed
Fix Version/s: 1.0.8

Fixed in the trunk.
AllocConsole is now followed by ShowWindow(GetConsoleWindow(), SW_HIDE)
This will cause invisible console window which shouldn't be displayed from the 
service anyhow. Not because its ugly, but because user can hit CTRL+C and close 
the service

 Add command line switch to hide console window when switch --type 
 interactive is used.
 

 Key: DAEMON-216
 URL: https://issues.apache.org/jira/browse/DAEMON-216
 Project: Commons Daemon
  Issue Type: New Feature
  Components: Procrun
 Environment: windows family
Reporter: Kurt Järmann
Priority: Minor
 Fix For: 1.0.8


 I have a Java Service and it is creating a tasktray. This only works with the 
 switch --type interactive but its creating a not needed console window to 
 fetch user input.
 I wish a switch to hide the unwanted window.
 Thank you for your efforts.
 Kurt

--
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] (COMPRESS-161) bzip2 decompression terminates after 900000 bytes

2011-11-07 Thread Hans horn (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/COMPRESS-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145574#comment-13145574
 ] 

Hans horn commented on COMPRESS-161:


Stefan,

I probably compressed it using cygwin's pbzip2 in August when I started 
to run out of disk space.
I just unpacked that file and repacked it using the non-parallel version 
of cygwin bzip2 and it decompresses just fine with Commons Compress!

Nice catch, Stefan

What now? I've got about 500GB of stuff compressed that way, that has 
become inaccessible to Java.
Are there any plans to support multiple concatenated streams in 
Commons Compress in the not so distant future?

Thx.,
H.




 bzip2 decompression terminates after 90 bytes
 -

 Key: COMPRESS-161
 URL: https://issues.apache.org/jira/browse/COMPRESS-161
 Project: Commons Compress
  Issue Type: Bug
  Components: Compressors
Affects Versions: 1.3
 Environment: Windows7 64bit JDK7u1,2
Reporter: Hans horn
Priority: Critical
 Fix For: 1.3

 Attachments: INT1_aminey.inp.bz2


 bzip2 decompression terminates (w/o error) after 90 bytes
 try {
   InputStream iin = new BZip2CompressorInputStream(new 
 FileInputStream(bzip2 compressed file that was uncompressed  90 bytes in 
 size);
   int data = iin.read();
   while (data != -1) {
 System.out.print((char) data); ++nBytes;
 data = iin.read();
   }
 } catch (IOException iox) { /**/ }
 System.out.println(#Bytes read  + nBytes);
 prints: #Bytes read 90

--
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] (COMPRESS-161) bzip2 decompression terminates after 900000 bytes

2011-11-07 Thread Stefan Bodewig (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/COMPRESS-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145592#comment-13145592
 ] 

Stefan Bodewig commented on COMPRESS-161:
-

COMPRESS-146 has got a patch attached that I'll look into.  If it fixes the 
problem with your archive I'm going to commit it.

 bzip2 decompression terminates after 90 bytes
 -

 Key: COMPRESS-161
 URL: https://issues.apache.org/jira/browse/COMPRESS-161
 Project: Commons Compress
  Issue Type: Bug
  Components: Compressors
Affects Versions: 1.3
 Environment: Windows7 64bit JDK7u1,2
Reporter: Hans horn
Priority: Critical
 Fix For: 1.3

 Attachments: INT1_aminey.inp.bz2


 bzip2 decompression terminates (w/o error) after 90 bytes
 try {
   InputStream iin = new BZip2CompressorInputStream(new 
 FileInputStream(bzip2 compressed file that was uncompressed  90 bytes in 
 size);
   int data = iin.read();
   while (data != -1) {
 System.out.print((char) data); ++nBytes;
 data = iin.read();
   }
 } catch (IOException iox) { /**/ }
 System.out.println(#Bytes read  + nBytes);
 prints: #Bytes read 90

--
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] (IO-291) Add new function FileUtils.isContained

2011-11-07 Thread Sebb (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145596#comment-13145596
 ] 

Sebb commented on IO-291:
-

bq. No tabs.

The file io-291-simple.diff still contains some tabs.

By the way, when uploading a replacement patch, please delete any file(s) that 
are totally superseded by the new patch.
Unfortunately JIRA does not have any way to mark patches as obsolete.


 Add new function FileUtils.isContained
 --

 Key: IO-291
 URL: https://issues.apache.org/jira/browse/IO-291
 Project: Commons IO
  Issue Type: New Feature
  Components: Utilities
Affects Versions: 2.1
Reporter: Pier-Luc Caron St-Pierre
Assignee: Gary D. Gregory
  Labels: patch
 Fix For: 2.1

 Attachments: FileUtils.isContained.patch, io-291-simple.diff, 
 io-291-v4.patch, io-291.diff


 I added a function that determines whether the specified leaf is contains by 
 the specified composite.

--
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] (COMPRESS-146) BZip2CompressorInputStream always treats 0x177245385090 as EOF, but should treat this as EOS

2011-11-07 Thread Stefan Bodewig (Resolved) (JIRA)


 [ 
https://issues.apache.org/jira/browse/COMPRESS-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig resolved COMPRESS-146.
-

   Resolution: Fixed
Fix Version/s: 1.4

applied Lasse's patch with a small modification.  The default constructor will 
not support concatenated streams for maximum backwards compatibility.

This will need some docs that I'm going to add once I've looked into the 
similar patch by Lasse for gzip as well.

Thanks!

 BZip2CompressorInputStream always treats 0x177245385090 as EOF, but should 
 treat this as EOS
 

 Key: COMPRESS-146
 URL: https://issues.apache.org/jira/browse/COMPRESS-146
 Project: Commons Compress
  Issue Type: Bug
  Components: Compressors
 Environment: all
Reporter: Dmitriy Smirnov
Priority: Critical
  Labels: 0x177245385090
 Fix For: 1.4

 Attachments: bzip2-concatenated.patch

   Original Estimate: 4h
  Remaining Estimate: 4h

 BZip2CompressorInputStream always treats 0x177245385090 as EOF, but should 
 treat this as EOS
 This error occurs mostly on large size files as sudden EOF somwere in the 
 middle of the file.
 An example of data from archived file:
 $ cat fastq.ax.bz2 | od -t x1 | grep -A 1 '17 72 45'
 22711660 d0 ff b6 01 20 10 ff ff 17 72 45 38 50 90 2e ff
 22711700 b2 d3 42 5a 68 39 31 41 59 26 53 59 84 3c 41 75
 --
 24637020 c5 49 ff 19 80 49 20 7f ff 17 72 45 38 50 90 a4
 24637040 a8 ac bd 42 5a 68 39 31 41 59 26 53 59 0d 9a b4
 --
 40302720 ff b1 24 80 10 ff ff 17 72 45 38 50 90 24 cb c5
 40302740 90 42 5a 68 39 31 41 59 26 53 59 42 05 ae 5e 05
 .
 Suggested solution:
 private void initBlock() throws IOException {
 char magic0 = bsGetUByte();
 char magic1 = bsGetUByte();
 char magic2 = bsGetUByte();
 char magic3 = bsGetUByte();
 char magic4 = bsGetUByte();
 char magic5 = bsGetUByte();
 if( magic0 == 0x17  magic1 == 0x72  magic2 == 0x45
  magic3 == 0x38  magic4 == 0x50  magic5 == 0x90 ) 
   
 {
   if( complete() ) // end of file);
   {
   return;
   } else
   {
   magic0 = bsGetUByte();
 magic1 = bsGetUByte();
 magic2 = bsGetUByte();
 magic3 = bsGetUByte();
 magic4 = bsGetUByte();
 magic5 = bsGetUByte();
   }
 } 
 if (magic0 != 0x31 || // '1'
magic1 != 0x41 || // 'A'
magic2 != 0x59 || // 'Y'
magic3 != 0x26 || // ''
magic4 != 0x53 || // 'S'
magic5 != 0x59 // 'Y'
) {
 this.currentState = EOF;
 throw new IOException(bad block header);
 } else {
 this.storedBlockCRC = bsGetInt();
 this.blockRandomised = bsR(1) == 1;
 /**
  * Allocate data here instead in constructor, so we do not 
 allocate
  * it if the input file is empty.
  */
 if (this.data == null) {
 this.data = new Data(this.blockSize100k);
 }
 // currBlockNo++;
 getAndMoveToFrontDecode();
 this.crc.initialiseCRC();
 this.currentState = START_BLOCK_STATE;
 }
 }
 private boolean 
 complete() throws IOException 
 { 
   boolean result = false;
 this.storedCombinedCRC = bsGetInt();
 try
 {
 if (in.available() == 0 ) 
 {
 throw new IOException( EOF );
 }
 checkMagicChar('B', first);
 checkMagicChar('Z', second);
 checkMagicChar('h', third);
 int blockSize = this.in.read();
 if ((blockSize  '1') || (blockSize  '9')) {
 throw new IOException(Stream is not BZip2 formatted: illegal 
 
   + blocksize  + (char) blockSize);
 }
 this.blockSize100k = blockSize - '0';
 this.bsLive = 0;
 this.bsBuff = 0;
 } catch( IOException e )
 {
   this.currentState = EOF;
   
   result = true;
 }
 
 this.data = null;
 if (this.storedCombinedCRC != this.computedCombinedCRC) {
 throw new IOException(BZip2 CRC error);
 }
 this.computedCombinedCRC = 0;
 return result;
 }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:

[jira] [Resolved] (COMPRESS-161) bzip2 decompression terminates after 900000 bytes

2011-11-07 Thread Stefan Bodewig (Resolved) (JIRA)


 [ 
https://issues.apache.org/jira/browse/COMPRESS-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig resolved COMPRESS-161.
-

   Resolution: Duplicate
Fix Version/s: (was: 1.3)
   1.4

This is COMPRESS-146 which has just been fixed.

In order to make it work you must use the new two-arg constructor of the stream 
and pass in true as second argument.


 bzip2 decompression terminates after 90 bytes
 -

 Key: COMPRESS-161
 URL: https://issues.apache.org/jira/browse/COMPRESS-161
 Project: Commons Compress
  Issue Type: Bug
  Components: Compressors
Affects Versions: 1.3
 Environment: Windows7 64bit JDK7u1,2
Reporter: Hans horn
Priority: Critical
 Fix For: 1.4

 Attachments: INT1_aminey.inp.bz2


 bzip2 decompression terminates (w/o error) after 90 bytes
 try {
   InputStream iin = new BZip2CompressorInputStream(new 
 FileInputStream(bzip2 compressed file that was uncompressed  90 bytes in 
 size);
   int data = iin.read();
   while (data != -1) {
 System.out.print((char) data); ++nBytes;
 data = iin.read();
   }
 } catch (IOException iox) { /**/ }
 System.out.println(#Bytes read  + nBytes);
 prints: #Bytes read 90

--
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] (IO-291) Add new function FileUtils.isContained


 [ 
https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated IO-291:
---

Attachment: (was: io-291.diff)

 Add new function FileUtils.isContained
 --

 Key: IO-291
 URL: https://issues.apache.org/jira/browse/IO-291
 Project: Commons IO
  Issue Type: New Feature
  Components: Utilities
Affects Versions: 2.1
Reporter: Pier-Luc Caron St-Pierre
Assignee: Gary D. Gregory
  Labels: patch
 Fix For: 2.1

 Attachments: FileUtils.isContained.patch, io-291-simple.diff, 
 io-291-v4.patch


 I added a function that determines whether the specified leaf is contains by 
 the specified composite.

--
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] (IO-291) Add new function FileUtils.isContained


 [ 
https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated IO-291:
---

Attachment: (was: io-291-simple.diff)

 Add new function FileUtils.isContained
 --

 Key: IO-291
 URL: https://issues.apache.org/jira/browse/IO-291
 Project: Commons IO
  Issue Type: New Feature
  Components: Utilities
Affects Versions: 2.1
Reporter: Pier-Luc Caron St-Pierre
Assignee: Gary D. Gregory
  Labels: patch
 Fix For: 2.1

 Attachments: FileUtils.isContained.patch, io-291-simple.diff, 
 io-291-v4.patch


 I added a function that determines whether the specified leaf is contains by 
 the specified composite.

--
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] (IO-291) Add new function FileUtils.isContained

2011-11-07 Thread Pier-Luc Caron St-Pierre (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated IO-291:
---

Attachment: io-291-simple.diff

Let's try again:

Attached is a much simpler implementation that works with:

Unrealized File objects
No recursion.
Correct Javadoc
No tabs.



 Add new function FileUtils.isContained
 --

 Key: IO-291
 URL: https://issues.apache.org/jira/browse/IO-291
 Project: Commons IO
  Issue Type: New Feature
  Components: Utilities
Affects Versions: 2.1
Reporter: Pier-Luc Caron St-Pierre
Assignee: Gary D. Gregory
  Labels: patch
 Fix For: 2.1

 Attachments: FileUtils.isContained.patch, io-291-simple.diff, 
 io-291-v4.patch


 I added a function that determines whether the specified leaf is contains by 
 the specified composite.

--
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-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau

2011-11-07 Thread Commented


[ 
https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145718#comment-13145718
 ] 

Sébastien Brisard commented on MATH-699:


{quote}
I don't think any of the currently implemented real distributions have this 
problem. Correct?
{quote}
Maybe I misunderstood, but in MATH-692 asked for a more precise definition of 
{{inverseCumulativeProbability}} as inf{x in R | P(X=x) = p}. If we exclude 
distribution with plateaus, I think that the current implementation is  
satisfactory (but for the use of the wrong tolerance I've already pointed out). 
But it was agreed that this implementation should be made more robust. So what 
was it exactly that needed improvement? What do you want me to do on this 
method?

{quote}
They are initial guesses for where to start when trying to bracket a root. That 
means they have to be values that can be fed into the cumulative probability 
function.
{quote}
I'm aware of that, but the current solver does fail when 
{{inverseCumulativeProbability(0)}} should return -inf, or 
{{inverseCumulativeProbability(1)}} should return +inf. See for example the 
implementation of {{NormalDistributionImpl}}.
{code:java}
public double inverseCumulativeProbability(final double p)
 {
if (p == 0) {
return Double.NEGATIVE_INFINITY;
}
if (p == 1) {
return Double.POSITIVE_INFINITY;
}
return super.inverseCumulativeProbability(p);
}
{code}
So currently, people who want to implement a distribution must be aware of the 
fact that the default implementation of {{inverseCumulativeProbability}} *must* 
be overriden. This rather unusual fact should be made clear in the Javadoc, 
unless a workaround can be thought of. I agree the one I proposed was far from 
perfect.

{quote}
Remember to consider convergence problems when the actual parameter to inverse 
cum is close to or exactly equal to 0 or 1.
{quote}
Thank you for pointing this out earlier. I do keep this important point in 
mind. But again, if we do not widen the scope of this method, I don't see what 
is required of me (appart from some cosmetic alterations to the Javadoc).

 inverseCumulativeDistribution fails with cumulative distribution having a 
 plateau
 -

 Key: MATH-699
 URL: https://issues.apache.org/jira/browse/MATH-699
 Project: Commons Math
  Issue Type: Bug
Affects Versions: 3.0
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Priority: Minor
 Attachments: AbstractContinuousDistributionTest.java


 This bug report follows MATH-692. The attached unit test fails. As required 
 by the definition in MATH-692, the lower-bound of the interval on which the 
 cdf is constant should be returned. This is not so at the moment.

--
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

Re: [jira] [Created] (MATH-702) CMA-ES optimizer input sigma should not be normalized by user

2011-11-07 Thread Nikolaus Hansen


good point. However, if the encoding/decoding methods can be defined
coordinate-wise differently or are even non-linear (I am not aware whether
they can be or not), I am not sure you can come up with a sufficiently
reasonable and comprehensible way to apply this transformation to sigma.
sigma is a scalar and positive, so it is a different object than the
encoding/decoding methods are operating on, right?

The interplay between sigma and an encoding is an unfortunately delicate
part in the user interface, but I don't really see a way to make it right
*and* look entirely obvious to the user.


On Mon, 07 Nov 2011 14:48:51 +0100, Luc Maisonobe (Created) (JIRA)
j...@apache.org wrote:


CMA-ES optimizer input sigma should not be normalized by user
-

 Key: MATH-702
 URL: https://issues.apache.org/jira/browse/MATH-702
 Project: Commons Math
  Issue Type: Bug
Affects Versions: 3.0
Reporter: Luc Maisonobe
Priority: Minor
 Fix For: 3.0


I am trying to use CMA-ES optimizer with simple boundaries.

It seems the inputSigma parameter should be normalized as it is checked  
against the [0 - 1] range in the checkParameters private method and as  
its value defaults to 0.3 if not not set in the initializeCMA private  
method.


I would have expected this value to be in the same units as the user  
parameters and to be normalized as part of an internal processing step  
instead of relying to the user doing this. I think the method need  
normalized values internally, as per the encode/decode methods in the  
inner class FitnessFunction suggest.


The optimizer should accept values in the same units as the other  
parameters and use encode (or a similar function) to do the  
normalization. This way, normalization is considered an internal  
implementation detail.




--
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





--
Science is a way of trying not to fool yourself.

The first principle is that you must not fool yourself, and you
are the easiest person to fool. So you have to be very careful
about that. After you've not fooled yourself, it's easy not to
fool other[ scientist]s. You just have to be honest in a
conventional way after that.
-- Richard P. Feynman

Nikolaus Hansen
INRIA, Research Centre Saclay – Ile-de-France
Machine Learning and Optimization group (TAO)
University Paris-Sud (Orsay)
LRI (UMR 8623), building 490
91405 ORSAY Cedex, France
Phone: +33-1-691-56495, Fax: +33-1-691-54240
URL: http://www.lri.fr/~hansen

[jira] [Commented] (MATH-702) CMA-ES optimizer input sigma should not be normalized by user

2011-11-07 Thread Nikolaus Hansen (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/MATH-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145736#comment-13145736
 ] 

Nikolaus Hansen commented on MATH-702:
--

good point. However, if the encoding/decoding methods can be defined
coordinate-wise differently or are even non-linear (I am not aware whether
they can be or not), I am not sure you can come up with a sufficiently
reasonable and comprehensible way to apply this transformation to sigma.
sigma is a scalar and positive, so it is a different object than the
encoding/decoding methods are operating on, right?

The interplay between sigma and an encoding is an unfortunately delicate
part in the user interface, but I don't really see a way to make it right
*and* look entirely obvious to the user.


On Mon, 07 Nov 2011 14:48:51 +0100, Luc Maisonobe (Created) (JIRA)



-- 
Science is a way of trying not to fool yourself.

The first principle is that you must not fool yourself, and you
are the easiest person to fool. So you have to be very careful
about that. After you've not fooled yourself, it's easy not to
fool other[ scientist]s. You just have to be honest in a
conventional way after that.
 -- Richard P. Feynman

Nikolaus Hansen
INRIA, Research Centre Saclay – Ile-de-France
Machine Learning and Optimization group (TAO)
University Paris-Sud (Orsay)
LRI (UMR 8623), building 490
91405 ORSAY Cedex, France
Phone: +33-1-691-56495, Fax: +33-1-691-54240
URL: http://www.lri.fr/~hansen


 CMA-ES optimizer input sigma should not be normalized by user
 -

 Key: MATH-702
 URL: https://issues.apache.org/jira/browse/MATH-702
 Project: Commons Math
  Issue Type: Bug
Affects Versions: 3.0
Reporter: Luc Maisonobe
Priority: Minor
 Fix For: 3.0


 I am trying to use CMA-ES optimizer with simple boundaries.
 It seems the inputSigma parameter should be normalized as it is checked 
 against the [0 - 1] range in the checkParameters private method and as its 
 value defaults to 0.3 if not not set in the initializeCMA private method.
 I would have expected this value to be in the same units as the user 
 parameters and to be normalized as part of an internal processing step 
 instead of relying to the user doing this. I think the method need normalized 
 values internally, as per the encode/decode methods in the inner class 
 FitnessFunction suggest.
 The optimizer should accept values in the same units as the other parameters 
 and use encode (or a similar function) to do the normalization. This way, 
 normalization is considered an internal implementation detail.

--
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-702) CMA-ES optimizer input sigma should not be normalized by user

2011-11-07 Thread Luc Maisonobe (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/MATH-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145744#comment-13145744
 ] 

Luc Maisonobe commented on MATH-702:


You are right.
for now, encoding/decoding is both liner only and hidden in a private inner 
class (FitnessFunction), so users only see simple bounds and inside these 
bounds the transform is linear.
For sure if we come up with a different mapping, we will need to come up with a 
way to define also the mapping of covariance. One way would be to rely on the 
Jacobian, but it would be strange to propose mapping function and requiring 
them to be smooth while the goal function by itself could be highly non-smooth.
So for now, the simple linear mapping seems sufficient to me, and would need 
improvement only if we change some internals of the class.

 CMA-ES optimizer input sigma should not be normalized by user
 -

 Key: MATH-702
 URL: https://issues.apache.org/jira/browse/MATH-702
 Project: Commons Math
  Issue Type: Bug
Affects Versions: 3.0
Reporter: Luc Maisonobe
Priority: Minor
 Fix For: 3.0


 I am trying to use CMA-ES optimizer with simple boundaries.
 It seems the inputSigma parameter should be normalized as it is checked 
 against the [0 - 1] range in the checkParameters private method and as its 
 value defaults to 0.3 if not not set in the initializeCMA private method.
 I would have expected this value to be in the same units as the user 
 parameters and to be normalized as part of an internal processing step 
 instead of relying to the user doing this. I think the method need normalized 
 values internally, as per the encode/decode methods in the inner class 
 FitnessFunction suggest.
 The optimizer should accept values in the same units as the other parameters 
 and use encode (or a similar function) to do the normalization. This way, 
 normalization is considered an internal implementation detail.

--
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] (CONFIGURATION-470) Extract classes generated by JavaCC

2011-11-07 Thread Emmanuel Bourg (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145928#comment-13145928
 ] 

Emmanuel Bourg commented on CONFIGURATION-470:
--

I preferred keeping the generated files, they could have been excluded from 
checkstyle and findbugs if that was an issue. Now the build is slower and my 
IDE complains about missing classes :(

 Extract classes generated by JavaCC
 ---

 Key: CONFIGURATION-470
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-470
 Project: Commons Configuration
  Issue Type: Improvement
  Components: Build
Affects Versions: 1.7
Reporter: Oliver Heger
Assignee: Oliver Heger
Priority: Minor
 Fix For: 1.8


 In the plist package classes generated by JavaCC are used to parse specific 
 configuration files. Currently these files are stored in SVN like regular 
 source files. This does not conform to best practices, is confusing, and 
 requires a special treatment in the configuration of tools like checkstyle or 
 findbugs.
 It would be better to let these files be generated during the build process 
 by the maven JavaCC plug-in. A working configuration can kindly be borrowed 
 from the OGNL component. The additional generation step should not slow down 
 the build significantly.

--
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] (IO-291) Add new function FileUtils.isContained


 [ 
https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pier-Luc Caron St-Pierre updated IO-291:


Attachment: (was: FileUtils.isContained.patch)

 Add new function FileUtils.isContained
 --

 Key: IO-291
 URL: https://issues.apache.org/jira/browse/IO-291
 Project: Commons IO
  Issue Type: New Feature
  Components: Utilities
Affects Versions: 2.1
Reporter: Pier-Luc Caron St-Pierre
Assignee: Gary D. Gregory
  Labels: patch
 Fix For: 2.1

 Attachments: io-291-simple.diff, io-291-v4.patch


 I added a function that determines whether the specified leaf is contains by 
 the specified composite.

--
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] (IO-291) Add new function FileUtils.isContained

2011-11-07 Thread Pier-Luc Caron St-Pierre (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pier-Luc Caron St-Pierre updated IO-291:


Attachment: (was: io-291-v4.patch)

 Add new function FileUtils.isContained
 --

 Key: IO-291
 URL: https://issues.apache.org/jira/browse/IO-291
 Project: Commons IO
  Issue Type: New Feature
  Components: Utilities
Affects Versions: 2.1
Reporter: Pier-Luc Caron St-Pierre
Assignee: Gary D. Gregory
  Labels: patch
 Fix For: 2.1

 Attachments: io-291-simple.diff


 I added a function that determines whether the specified leaf is contains by 
 the specified composite.

--
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] (IO-291) Add new function FileUtils.isContained

2011-11-07 Thread Pier-Luc Caron St-Pierre (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pier-Luc Caron St-Pierre updated IO-291:


Attachment: io-291-v5.patch

 Add new function FileUtils.isContained
 --

 Key: IO-291
 URL: https://issues.apache.org/jira/browse/IO-291
 Project: Commons IO
  Issue Type: New Feature
  Components: Utilities
Affects Versions: 2.1
Reporter: Pier-Luc Caron St-Pierre
Assignee: Gary D. Gregory
  Labels: patch
 Fix For: 2.1

 Attachments: io-291-simple.diff, io-291-v5.patch


 I added a function that determines whether the specified leaf is contains by 
 the specified composite.

--
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-291) Add new function FileUtils.isContained

2011-11-07 Thread Pier-Luc Caron St-Pierre (Issue Comment Edited) (JIRA)

[
https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13146045#comment-13146045
]

Pier-Luc Caron St-Pierre edited comment on IO-291 at 11/8/11 2:38 AM:
--

I built on top of your patch. So if you apply my patch (io-291-v5.patch) from
scratch, you should have our combined changes.

* I have implemented the directoryContains(final File directory, final File
child)
* I have added some test case for the newly implemented function.
* I have added some javadoc, renamed some parameters
* I have corrected the code style of the test to match the original style.

We have some issues to address :

* Actually the test case fail on testSameFile() because the case is tester on
a file. It fail the rule that a directory cannot be a file
* Does a directory contain itself? I do not have strong opinions about that.
* Does a file contain itself? I do not have strong opinions about that.
* In the scope of the method directoryContains(final File directory, final
File child), what will happens if the files is an empty collection?

was (Author: plcstpierre):
I build on top of your patch. So if you apply my patch (io-291-v5.patch)
from scratch, you should have our combined changes.

* I have implemented the directoryContains(final File directory, final File
child)
* I have added some test case for the newly implemented function.
* I have Added some javadoc, renamed some parameters
* I have corrected the code style of the test to match the original style.

We have some issues to address :

Add new function FileUtils.isContained
--

Key: IO-291
URL: https://issues.apache.org/jira/browse/IO-291
Project: Commons IO
Issue Type: New Feature
Components: Utilities
Affects Versions: 2.1
Reporter: Pier-Luc Caron St-Pierre
Assignee: Gary D. Gregory
Labels: patch
Fix For: 2.1

Attachments: io-291-simple.diff, io-291-v5.patch

I added a function that determines whether the specified leaf is contains by
the specified composite.

--
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] (IO-291) Add new function FileUtils.isContained

2011-11-07 Thread Pier-Luc Caron St-Pierre (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13146045#comment-13146045
 ] 

Pier-Luc Caron St-Pierre commented on IO-291:
-

I build on top of your patch. So if you apply my patch (io-291-v5.patch) from 
scratch, you should have our combined changes.

 * I have implemented the directoryContains(final File directory, final File 
child) 
 * I have added some test case for the newly implemented function.
 * I have Added some javadoc, renamed some parameters
 * I have corrected the code style of the test to match the original style.

We have some issues to address :

 * Actually the test case fail on testSameFile() because the case is tester on 
a file. It fail the rule that a directory cannot be a file
 * Does a directory contain itself? I do not have strong opinions about that.
 * Does a file contain itself? I do not have strong opinions about that.
 * In the scope of the method directoryContains(final File directory, final 
File child), what will happens if the files is an empty collection?

 Add new function FileUtils.isContained
 --

 Key: IO-291
 URL: https://issues.apache.org/jira/browse/IO-291
 Project: Commons IO
  Issue Type: New Feature
  Components: Utilities
Affects Versions: 2.1
Reporter: Pier-Luc Caron St-Pierre
Assignee: Gary D. Gregory
  Labels: patch
 Fix For: 2.1

 Attachments: io-291-simple.diff, io-291-v5.patch


 I added a function that determines whether the specified leaf is contains by 
 the specified composite.

--
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] (IO-291) Add new function FileUtils.isContained