date:20120307


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

Emmanuel Bourg updated SANDBOX-410:
---

Component/s: CSV

 Predefined format for MYSQL
 ---

 Key: SANDBOX-410
 URL: https://issues.apache.org/jira/browse/SANDBOX-410
 Project: Commons Sandbox
  Issue Type: Improvement
  Components: CSV
Reporter: Emmanuel Bourg
Priority: Minor
 Fix For: CSV 1.0


 MYSQL is able to import/export data in the CSV format. Commons CSV should 
 have a predefined format for the default CSV format used by MYSQL:
 http://dev.mysql.com/doc/refman/5.1/en/load-data.html
 The specifications of this format is:
 - Field separator: \t
 - Record separator: \n
 - No quoted values
 - Field and record separators in field values are escaped with '\'
 - Field values are not trimmed
 - No header

--
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] (SANDBOX-291) Lots of possible changes


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

Emmanuel Bourg updated SANDBOX-291:
---

Description: 
I made a lot of changes to pretty much all of the classes in the csv package.  
I thought it would be better to put all of the the changes here in one issue, 
but feel free to only take the parts you like (if any).  Hopefully if nothing 
else the test cases will be useful to you.

I'll try to list most of the changes here, but I'm sure I'm forgetting some. 
This should include all of the big changes at least. I focused mostly on the 
parser, but I also made a few changes to the printer classes (although I don't 
think I added any new test cases there).

h3. General Changes

- Changed all class names with CSV in them to use Csv. This is how it 
appears in the commons-lang escapeCsv methods and I think it's easier to read 
the class name when acronyms are not in all upper case.

- Formatted the code. I used Eclipse with a version of the Java formatting 
style that uses spaces instead of tabs and with a few other small changes to 
try to make it more similar to the style of this code. The formatting was 
inconsistent before (sometimes 2 space indent, sometimes 4) which made it 
really hard to work on.

- Removed all deprecated methods/constructors

- Made all public classes final. If there is ever a need to create subclasses 
of them then this could be changed, but I think it would be better to at least 
start them as final (since once they are released as non-final it's hard to go 
back).

- A few bug fixes (and test cases for them)

h3. CsvParser

- There were a few bugs for special cases, so I made as small of changes as I 
could to the parser code to fix these.

- Added a lot of test cases. I created a test case for all bugs that I found, 
so even if you don't use my changes to this class you should be able to use the 
test cases to find all of the same bugs.

- Added a close method.

- Renamed the nextValue method to getValue (so it is more consistent with the 
getAll and getLine method names). I think I would prefer to use a different 
method name prefix for all three of these (like readAll) since I wouldn't 
normally expect a get method to have side effects, but I didn't want to just 
change the names of the most used methods.

- Changed the getLineNumber method to return the correct line number when there 
are multi-line values.

- Moved all of the lexer methods into an inner CsvLexer class that is 
completely independent of the CsvParser class. The methods were already 
separated out, so it wasn't a very big change. I also moved the lexer test 
cases into a new CsvLexerTest class.

- Got rid of the interpreting unicode escape options. This doesn't really have 
anything to do with parsing a CSV file so I think it should be left up to the 
user of the class to implement this if needed. As an example, I made a 
CsvParserUnicodeEscapeTest class that uses the code from the lexer in a Reader 
subclass. One nice thing is that with this implementation, the interpretted 
values can be used as the delimiter, encapsulator, etc.

- Got rid of the escape option for the same reason as the unicode escape 
option. I replaced it with an encapsulator escape option that is only used as 
an escape operator on the encapsulator character.

h3. ExtendedBufferedReader

- Greatly simplified this class. I removed all the methods that weren't being 
used (including keeping track of the line number) and changed the lookahead 
option to use the BufferedReader mark and reset methods.


h3. CsvStrategy

- I split this class into three classes: an abstract base class (CsvStrategy), 
a parser-specific version (CsvParseStrategy) and a printer-specific version 
(CsvPrintStrategy). I didn't like that the strategy was used for both parsing 
and printing even though some of the values only applied to parsing (and there 
could be values that apply only to printing as well).

- Made this class immutable (as described in SANDBOX-279)

- Changed the whitespace options to not ignore whitespace by default. This is 
what the document at http://www.rfc-editor.org/rfc/rfc4180.txt recommends for 
the CSV format, so I think it should be like that by default. I added an 
IGNORE_WHITESPACE_STRATEGY field that works the same as the old defaults.

- Removed the interpretUnicodeEscape option and replaced the escape field with 
an encapsuatorEscape field (as described in the CsvParser change details).

- Added an ignoreEncapsulationTrailingCharacters field. This is used to either 
ignore or append characters that are after an encapsulated value. Previously an 
IOException was being thrown here, which I don't think is ever a good idea.

- Added some restrictions to prevent the values from being things that would 
break the parser. This includes using a line break for anything or having equal 
two values (other than the encapsulator and

[jira] [Updated] (SANDBOX-291) Lots of possible changes


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

Emmanuel Bourg updated SANDBOX-291:
---

Comment: was deleted

(was: I'll try to list most of the changes here, but I'm sure I'm forgetting 
some.  This should include all of the big changes at least.  I focused mostly 
on the parser, but I also made a few changes to the printer classes (although I 
don't think I added any new test cases there).


General Changes:
- Changed all class names with CSV in them to use Csv.  This is how it 
appears in the commons-lang escapeCsv methods and I think it's easier to read 
the class name when acronyms are not in all upper case.

- Formatted the code.  I used Eclipse with a version of the Java formatting 
style that uses spaces instead of tabs and with a few other small changes to 
try to make it more similar to the style of this code.  The formatting was 
inconsistent before (sometimes 2 space indent, sometimes 4) which made it 
really hard to work on.

- Removed all deprecated methods/constructors

- Made all public classes final.  If there is ever a need to create subclasses 
of them then this could be changed, but I think it would be better to at least 
start them as final (since once they are released as non-final it's hard to go 
back).

- A few bug fixes (and test cases for them)


-


CsvParser:
- There were a few bugs for special cases, so I made as small of changes as I 
could to the parser code to fix these.

- Added a lot of test cases. I created a test case for all bugs that I found, 
so even if you don't use my changes to this class you should be able to use the 
test cases to find all of the same bugs.

- Added a close method.

- Renamed the nextValue method to getValue (so it is more consistent with the 
getAll and getLine method names).  I think I would prefer to use a different 
method name prefix for all three of these (like readAll) since I wouldn't 
normally expect a get method to have side effects, but I didn't want to just 
change the names of the most used methods.

- Changed the getLineNumber method to return the correct line number when there 
are multi-line values.

- Moved all of the lexer methods into an inner CsvLexer class that is 
completely independent of the CsvParser class.  The methods were already 
separated out, so it wasn't a very big change.  I also moved the lexer test 
cases into a new CsvLexerTest class.

- Got rid of the interpreting unicode escape options.  This doesn't really have 
anything to do with parsing a CSV file so I think it should be left up to the 
user of the class to implement this if needed.  As an example, I made a 
CsvParserUnicodeEscapeTest class that uses the code from the lexer in a Reader 
subclass.  One nice thing is that with this implementation, the interpretted 
values can be used as the delimiter, encapsulator, etc.

- Got rid of the escape option for the same reason as the unicode escape 
option.  I replaced it with an encapsulator escape option that is only used as 
an escape operator on the encapsulator character.


-

ExtendedBufferedReader
- Greatly simplified this class. I removed all the methods that weren't being 
used (including keeping track of the line number) and changed the lookahead 
option to use the BufferedReader mark and reset methods.




CsvStrategy:
- I split this class into three classes: an abstract base class (CsvStrategy), 
a parser-specific version (CsvParseStrategy) and a printer-specific version 
(CsvPrintStrategy).  I didn't like that the strategy was used for both parsing 
and printing even though some of the values only applied to parsing (and there 
could be values that apply only to printing as well).

- Made this class immutable (as described in SANDBOX-279)

- Changed the whitespace options to not ignore whitespace by default.  This is 
what the document at http://www.rfc-editor.org/rfc/rfc4180.txt recommends for 
the CSV format, so I think it should be like that by default.  I added an 
IGNORE_WHITESPACE_STRATEGY field that works the same as the old defaults.

- Removed the interpretUnicodeEscape option and replaced the escape field with 
an encapsuatorEscape field (as described in the CsvParser change details).

- Added an ignoreEncapsulationTrailingCharacters field.  This is used to either 
ignore or append characters that are after an encapsulated value.  Previously 
an IOException was being thrown here, which I don't think is ever a good idea.

- Added some restrictions to prevent the values from being things that would 
break the parser.  This includes using a line break for anything or having 
equal two values (other than the encapsulator and encapsulator escape).


-


CsvPrinter:
- I changed this to use a modified version of the commons-lang escapeCsv method 
(I hope it is ok to copy a small amount of code from one commons project to 
another?).  The escaping is a little

[jira] [Commented] (SANDBOX-291) Lots of possible changes

2012-03-07 Thread Emmanuel Bourg (Commented) (JIRA)


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

Emmanuel Bourg commented on SANDBOX-291:


There are a lot of good suggestions, I moved the details in the description of 
the issue so we can update it as we make progress integrating the changes.

 Lots of possible changes
 

 Key: SANDBOX-291
 URL: https://issues.apache.org/jira/browse/SANDBOX-291
 Project: Commons Sandbox
  Issue Type: Improvement
  Components: CSV
Affects Versions: Nightly Builds
Reporter: Bob Smith
Priority: Minor
 Attachments: src.zip


 I made a lot of changes to pretty much all of the classes in the csv package. 
  I thought it would be better to put all of the the changes here in one 
 issue, but feel free to only take the parts you like (if any).  Hopefully if 
 nothing else the test cases will be useful to you.
 I'll try to list most of the changes here, but I'm sure I'm forgetting some. 
 This should include all of the big changes at least. I focused mostly on the 
 parser, but I also made a few changes to the printer classes (although I 
 don't think I added any new test cases there).
 h3. General Changes
 - Changed all class names with CSV in them to use Csv. This is how it 
 appears in the commons-lang escapeCsv methods and I think it's easier to 
 read the class name when acronyms are not in all upper case.
 - Formatted the code. I used Eclipse with a version of the Java formatting 
 style that uses spaces instead of tabs and with a few other small changes to 
 try to make it more similar to the style of this code. The formatting was 
 inconsistent before (sometimes 2 space indent, sometimes 4) which made it 
 really hard to work on.
 - Removed all deprecated methods/constructors
 - Made all public classes final. If there is ever a need to create subclasses 
 of them then this could be changed, but I think it would be better to at 
 least start them as final (since once they are released as non-final it's 
 hard to go back).
 - A few bug fixes (and test cases for them)
 h3. CsvParser
 - There were a few bugs for special cases, so I made as small of changes as I 
 could to the parser code to fix these.
 - Added a lot of test cases. I created a test case for all bugs that I found, 
 so even if you don't use my changes to this class you should be able to use 
 the test cases to find all of the same bugs.
 - Added a close method.
 - Renamed the nextValue method to getValue (so it is more consistent with the 
 getAll and getLine method names). I think I would prefer to use a different 
 method name prefix for all three of these (like readAll) since I wouldn't 
 normally expect a get method to have side effects, but I didn't want to 
 just change the names of the most used methods.
 - Changed the getLineNumber method to return the correct line number when 
 there are multi-line values.
 - Moved all of the lexer methods into an inner CsvLexer class that is 
 completely independent of the CsvParser class. The methods were already 
 separated out, so it wasn't a very big change. I also moved the lexer test 
 cases into a new CsvLexerTest class.
 - Got rid of the interpreting unicode escape options. This doesn't really 
 have anything to do with parsing a CSV file so I think it should be left up 
 to the user of the class to implement this if needed. As an example, I made a 
 CsvParserUnicodeEscapeTest class that uses the code from the lexer in a 
 Reader subclass. One nice thing is that with this implementation, the 
 interpretted values can be used as the delimiter, encapsulator, etc.
 - Got rid of the escape option for the same reason as the unicode escape 
 option. I replaced it with an encapsulator escape option that is only used as 
 an escape operator on the encapsulator character.
 h3. ExtendedBufferedReader
 - Greatly simplified this class. I removed all the methods that weren't being 
 used (including keeping track of the line number) and changed the lookahead 
 option to use the BufferedReader mark and reset methods.
 h3. CsvStrategy
 - I split this class into three classes: an abstract base class 
 (CsvStrategy), a parser-specific version (CsvParseStrategy) and a 
 printer-specific version (CsvPrintStrategy). I didn't like that the strategy 
 was used for both parsing and printing even though some of the values only 
 applied to parsing (and there could be values that apply only to printing as 
 well).
 - Made this class immutable (as described in SANDBOX-279)
 - Changed the whitespace options to not ignore whitespace by default. This is 
 what the document at http://www.rfc-editor.org/rfc/rfc4180.txt recommends for 
 the CSV format, so I think it should be like that by default. I added an 
 IGNORE_WHITESPACE_STRATEGY field

[jira] [Updated] (SANDBOX-291) Lots of possible changes


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

Emmanuel Bourg updated SANDBOX-291:
---

Description: 
I made a lot of changes to pretty much all of the classes in the csv package.  
I thought it would be better to put all of the the changes here in one issue, 
but feel free to only take the parts you like (if any).  Hopefully if nothing 
else the test cases will be useful to you.

I'll try to list most of the changes here, but I'm sure I'm forgetting some. 
This should include all of the big changes at least. I focused mostly on the 
parser, but I also made a few changes to the printer classes (although I don't 
think I added any new test cases there).

h3. General Changes

- Changed all class names with CSV in them to use Csv. This is how it 
appears in the commons-lang escapeCsv methods and I think it's easier to read 
the class name when acronyms are not in all upper case.

- Formatted the code. I used Eclipse with a version of the Java formatting 
style that uses spaces instead of tabs and with a few other small changes to 
try to make it more similar to the style of this code. The formatting was 
inconsistent before (sometimes 2 space indent, sometimes 4) which made it 
really hard to work on. (/) DONE

- Removed all deprecated methods/constructors (/) DONE

- Made all public classes final. If there is ever a need to create subclasses 
of them then this could be changed, but I think it would be better to at least 
start them as final (since once they are released as non-final it's hard to go 
back).

- A few bug fixes (and test cases for them)

h3. CsvParser

- There were a few bugs for special cases, so I made as small of changes as I 
could to the parser code to fix these.

- Added a lot of test cases. I created a test case for all bugs that I found, 
so even if you don't use my changes to this class you should be able to use the 
test cases to find all of the same bugs.

- Added a close method.

- Renamed the nextValue method to getValue (so it is more consistent with the 
getAll and getLine method names). I think I would prefer to use a different 
method name prefix for all three of these (like readAll) since I wouldn't 
normally expect a get method to have side effects, but I didn't want to just 
change the names of the most used methods.

- Changed the getLineNumber method to return the correct line number when there 
are multi-line values.

- Moved all of the lexer methods into an inner CsvLexer class that is 
completely independent of the CsvParser class. The methods were already 
separated out, so it wasn't a very big change. I also moved the lexer test 
cases into a new CsvLexerTest class.

- Got rid of the interpreting unicode escape options. This doesn't really have 
anything to do with parsing a CSV file so I think it should be left up to the 
user of the class to implement this if needed. As an example, I made a 
CsvParserUnicodeEscapeTest class that uses the code from the lexer in a Reader 
subclass. One nice thing is that with this implementation, the interpretted 
values can be used as the delimiter, encapsulator, etc.

- Got rid of the escape option for the same reason as the unicode escape 
option. I replaced it with an encapsulator escape option that is only used as 
an escape operator on the encapsulator character.

h3. ExtendedBufferedReader

- Greatly simplified this class. I removed all the methods that weren't being 
used (including keeping track of the line number) and changed the lookahead 
option to use the BufferedReader mark and reset methods.


h3. CsvStrategy

- I split this class into three classes: an abstract base class (CsvStrategy), 
a parser-specific version (CsvParseStrategy) and a printer-specific version 
(CsvPrintStrategy). I didn't like that the strategy was used for both parsing 
and printing even though some of the values only applied to parsing (and there 
could be values that apply only to printing as well).

- Made this class immutable (as described in SANDBOX-279) (/) DONE

- Changed the whitespace options to not ignore whitespace by default. This is 
what the document at http://www.rfc-editor.org/rfc/rfc4180.txt recommends for 
the CSV format, so I think it should be like that by default. I added an 
IGNORE_WHITESPACE_STRATEGY field that works the same as the old defaults. (/) 
DONE

- Removed the interpretUnicodeEscape option and replaced the escape field with 
an encapsuatorEscape field (as described in the CsvParser change details).

- Added an ignoreEncapsulationTrailingCharacters field. This is used to either 
ignore or append characters that are after an encapsulated value. Previously an 
IOException was being thrown here, which I don't think is ever a good idea.

- Added some restrictions to prevent the values from being things that would 
break the parser. This includes using a line break for anything or having equal 
two

[jira] [Commented] (IO-305) New copy() method in IOUtils that takes additional offset, length and buffersize arguments


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

Sebb commented on IO-305:
-

Should use long for the offset and length.

It would be useful to return the number of bytes actually copied, as per the 
copyLarge methods.

 New copy() method in IOUtils that takes additional offset, length and 
 buffersize arguments
 --

 Key: IO-305
 URL: https://issues.apache.org/jira/browse/IO-305
 Project: Commons IO
  Issue Type: New Feature
  Components: Utilities
Reporter: Manoj Mokashi
Priority: Minor
 Attachments: IOUtils.java, IOUtilsTest.java


 /**
  * Copy from input to output stream
  * @param is : input stream
  * @param os : output stream
  * @param offset : number of bytes to skip from input before copying
  * -ve values are ignored
  * @param len : number of bytes to copy. -1 means all
  * @param bufferSize : buffer size to use for copying
  * @throws IOException
  */
 public static void copy( InputStream is, OutputStream os, int offset, int 
 len, int bufferSize) throws IOException


--
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] (SANDBOX-291) Lots of possible changes


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

Emmanuel Bourg updated SANDBOX-291:
---

Description: 
I made a lot of changes to pretty much all of the classes in the csv package.  
I thought it would be better to put all of the the changes here in one issue, 
but feel free to only take the parts you like (if any).  Hopefully if nothing 
else the test cases will be useful to you.

I'll try to list most of the changes here, but I'm sure I'm forgetting some. 
This should include all of the big changes at least. I focused mostly on the 
parser, but I also made a few changes to the printer classes (although I don't 
think I added any new test cases there).

h3. General Changes

- Changed all class names with CSV in them to use Csv. This is how it 
appears in the commons-lang escapeCsv methods and I think it's easier to read 
the class name when acronyms are not in all upper case. (x) {color:red}3 letter 
acronyms are usually kept in uppercase (for example URLConnection or SAXParser 
in the JDK, but here are exceptions){color}

- Formatted the code. I used Eclipse with a version of the Java formatting 
style that uses spaces instead of tabs and with a few other small changes to 
try to make it more similar to the style of this code. The formatting was 
inconsistent before (sometimes 2 space indent, sometimes 4) which made it 
really hard to work on. (/) {color:green}DONE{color}

- Removed all deprecated methods/constructors (/) {color:green}DONE{color}

- Made all public classes final. If there is ever a need to create subclasses 
of them then this could be changed, but I think it would be better to at least 
start them as final (since once they are released as non-final it's hard to go 
back).

- A few bug fixes (and test cases for them)

h3. CsvParser

- There were a few bugs for special cases, so I made as small of changes as I 
could to the parser code to fix these.

- Added a lot of test cases. I created a test case for all bugs that I found, 
so even if you don't use my changes to this class you should be able to use the 
test cases to find all of the same bugs.

- Added a close method.

- Renamed the nextValue method to getValue (so it is more consistent with the 
getAll and getLine method names). I think I would prefer to use a different 
method name prefix for all three of these (like readAll) since I wouldn't 
normally expect a get method to have side effects, but I didn't want to just 
change the names of the most used methods. (x) {color:red}This method has been 
removed, the parser now works line by line.{color}

- Changed the getLineNumber method to return the correct line number when there 
are multi-line values.

- Moved all of the lexer methods into an inner CsvLexer class that is 
completely independent of the CsvParser class. The methods were already 
separated out, so it wasn't a very big change. I also moved the lexer test 
cases into a new CsvLexerTest class.

- Got rid of the interpreting unicode escape options. This doesn't really have 
anything to do with parsing a CSV file so I think it should be left up to the 
user of the class to implement this if needed. As an example, I made a 
CsvParserUnicodeEscapeTest class that uses the code from the lexer in a Reader 
subclass. One nice thing is that with this implementation, the interpretted 
values can be used as the delimiter, encapsulator, etc.

- Got rid of the escape option for the same reason as the unicode escape 
option. I replaced it with an encapsulator escape option that is only used as 
an escape operator on the encapsulator character.

h3. ExtendedBufferedReader

- Greatly simplified this class. I removed all the methods that weren't being 
used (including keeping track of the line number) and changed the lookahead 
option to use the BufferedReader mark and reset methods.


h3. CsvStrategy

- I split this class into three classes: an abstract base class (CsvStrategy), 
a parser-specific version (CsvParseStrategy) and a printer-specific version 
(CsvPrintStrategy). I didn't like that the strategy was used for both parsing 
and printing even though some of the values only applied to parsing (and there 
could be values that apply only to printing as well).

- Made this class immutable (as described in SANDBOX-279) (/) 
{color:green}DONE{color}

- Changed the whitespace options to not ignore whitespace by default. This is 
what the document at http://www.rfc-editor.org/rfc/rfc4180.txt recommends for 
the CSV format, so I think it should be like that by default. I added an 
IGNORE_WHITESPACE_STRATEGY field that works the same as the old defaults. (/) 
{color:green}DONE{color}

- Removed the interpretUnicodeEscape option and replaced the escape field with 
an encapsuatorEscape field (as described in the CsvParser change details).

- Added an ignoreEncapsulationTrailingCharacters field. This is used to either 
ignore

[jira] [Updated] (MATH-746) Things to do before releasing 3.0

2012-03-07 Thread Gilles (Updated) (JIRA)


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

Gilles updated MATH-746:


Description: 
This issue is meant to contain a list of tasks to be completed before the 
release.

* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and 
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/) 
(r1291896)
** List of new features (/) (r1292318)
* Create a release branch
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
* Comment out print statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
* Remove unit test class {{BatteryNISTTest}} (/) (cf. MATH-763)
* Remove class {{PivotingQRDecomposition}} (/) (cf. MATH-763)
* Comment out print statement in {{SymmLQTest}} (/) (r1244992, removed in 
r1244996)
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
** org.apache.commons.math3.distribution.TriangularDistribution (/) (r1292572)
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be 
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251 and 
r1292270)
* Check the user guide (/) (no negative comments)


  was:
This issue is meant to contain a list of tasks to be completed before the 
release.

* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and 
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/) 
(r1291896)
** List of new features (/) (r1292318)
* Create a release branch
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
* Comment out print statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out print statement in {{SymmLQTest}} (/) (r1244992, removed in 
r1244996)
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
** org.apache.commons.math3.distribution.TriangularDistribution (/) (r1292572)
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be 
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251 and 
r1292270)
* Check the user guide



 Things to do before releasing 3.0
 -

 Key: MATH-746
 URL: https://issues.apache.org/jira/browse/MATH-746
 Project: Commons Math
  Issue Type: Task
Reporter: Gilles
Priority: Blocker
 Fix For: 3.0


 This issue is meant to contain a list of tasks to be completed before the 
 release.
 * Remarks to be added to the *release notes*:
 ** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
 *** Many code paths untested
 *** Looking for volunteers to improve the code readability, robustness and 
 performance
 *** Looking for volunteers to extend the test suite
 ** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/) 
 (r1291896)
 ** List of new features (/) (r1292318)
 * Create a release branch
 * Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
 * Comment out print statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
 * Remove unit test class {{BatteryNISTTest}} (/) (cf. MATH-763)
 * Remove class {{PivotingQRDecomposition}} (/) (cf. MATH-763)
 * Comment out print statement in {{SymmLQTest}} (/) (r1244992, removed in 
 r1244996)
 * Findbugs:
 ** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
 ** org.apache.commons.math3.distribution.TriangularDistribution (/) (r1292572)
 ** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be 
 corrected before release)
 ** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251 
 and r1292270)
 * Check the user guide (/) (no negative comments)

--
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-746) Things to do before releasing 3.0

2012-03-07 Thread Gilles (Resolved) (JIRA)


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

Gilles resolved MATH-746.
-

Resolution: Fixed

All blocking issues have been dealt with.
Finer polishing of the source code is left for the next round of development.


 Things to do before releasing 3.0
 -

 Key: MATH-746
 URL: https://issues.apache.org/jira/browse/MATH-746
 Project: Commons Math
  Issue Type: Task
Reporter: Gilles
Priority: Blocker
 Fix For: 3.0


 This issue is meant to contain a list of tasks to be completed before the 
 release.
 * Remarks to be added to the *release notes*:
 ** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
 *** Many code paths untested
 *** Looking for volunteers to improve the code readability, robustness and 
 performance
 *** Looking for volunteers to extend the test suite
 ** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/) 
 (r1291896)
 ** List of new features (/) (r1292318)
 * Create a release branch
 * Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
 * Comment out print statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
 * Remove unit test class {{BatteryNISTTest}} (/) (cf. MATH-763)
 * Remove class {{PivotingQRDecomposition}} (/) (cf. MATH-763)
 * Comment out print statement in {{SymmLQTest}} (/) (r1244992, removed in 
 r1244996)
 * Findbugs:
 ** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
 ** org.apache.commons.math3.distribution.TriangularDistribution (/) (r1292572)
 ** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be 
 corrected before release)
 ** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251 
 and r1292270)
 * Check the user guide (/) (no negative comments)

--
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] [Created] (COLLECTIONS-397) BoundedFifoBuffer could allow null entries

BoundedFifoBuffer could allow null entries
--

 Key: COLLECTIONS-397
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-397
 Project: Commons Collections
  Issue Type: Improvement
Reporter: Sebb


BoundedFifoBuffer could easily allow null entries - it uses an array for 
storage.

Is there any reason why nulls should not be (optionally) allowed?
This would mean changing the remove() implementation.

--
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-764) New sample() API should accept RandomGenerator as parameter

2012-03-07 Thread Gilles (Commented) (JIRA)


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

Gilles commented on MATH-764:
-

* In the current design, the specific distribution subclasses would need to 
implement both RealDistribution and Sampler.
Can you give an example of a class that would implement Sampler interface?
* The addition of the sample methods in the distribution classes were 
accepted, as syntactic sugar, on the premisses that users should be satisfied 
with the default RNG.
* As much as possible, we try to have immutable objects; in this view, creating 
(reinitializing) the RNG after construction is not an option.
* If you need to access (or change) the RNG, the original methods designed to 
offer sequences of pseudo-random numbers (with certain properties) are located 
in package random (in class RandomDataImpl).


 New sample() API should accept RandomGenerator as parameter
 ---

 Key: MATH-764
 URL: https://issues.apache.org/jira/browse/MATH-764
 Project: Commons Math
  Issue Type: Improvement
Affects Versions: 3.0
Reporter: Alex Bertram
   Original Estimate: 48h
  Remaining Estimate: 48h

 This may come to late as I know the 3.0 release is nearing completion, but I 
 had some concerns about the new sample() method on the math3 RealDistribution 
 interface. 
 Specifically, there doesn't seem to be a way to supply a random generator to 
 the sampler. Perhaps it would be better to have a factory method on the 
 RealDistribution interface that accepted a RandomGenerator and returns an 
 instance of some new interface, Sampler, which contains the sample() methods. 
 That is:
 interface RealDistribution {
 Sampler createSampler(RandomGenerator generator);
 Sample createSampler(); // uses default RandomGenerator
 }
 interface Sampler {
 double sample();
 double[] sample(int sampleSize);
 }

--
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] [Created] (COLLECTIONS-398) BoundedFifoBuffer could be simplified by keeping a count of the number of entries

2012-03-07 Thread Radoslaw Wisniewski (Commented) (JIRA)

BoundedFifoBuffer could be simplified by keeping a count of the number of 
entries
-

 Key: COLLECTIONS-398
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-398
 Project: Commons Collections
  Issue Type: Improvement
Reporter: Sebb


BoundedFifoBuffer could be much simplified by keeping a count of the number of 
entries, and dropping the boolean full.

This would speed up size() and isEmpty() and isFull().

--
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] (VFS-201) FTP is failing by saying File doesn't exist even the file exists and a valid file.


[ 
https://issues.apache.org/jira/browse/VFS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224380#comment-13224380
 ] 

Radoslaw Wisniewski commented on VFS-201:
-

I'm facing the same problem with 29 February like Oliver Haider. I’ve detected 
two conflicting libraries in my claspath: commons-net-1.4.1 and 
commons-net-2.0.  After removing the older one, all worked fine and 29 Feb was 
not a problem anymore.

 FTP is failing by saying File doesn't exist even the file exists and a 
 valid file.
 

 Key: VFS-201
 URL: https://issues.apache.org/jira/browse/VFS-201
 Project: Commons VFS
  Issue Type: Bug
 Environment: Linux
Reporter: Satish Kumar Kommuri

 Hi,
 We are facing a strange problem with vfs file transfer from one of the FTP 
 locations. Java code throws the FileSystemException by saying particular 
 file does not exist. On the other hand, FTP to that site and wget are 
 working.
 Moreover, from the same machine we are able to FTP from the command line and 
 able to download the file using get command.
 And also, wget works fine. No idea the same is failing from java.
 Please find the code snippent below:
  FileSystemOptions fso = new FileSystemOptions();
  SftpFileSystemConfigBuilder.getInstance().setStrictHostKeyChecking(fso, 
 no);
  FileObject sourceFileObject = fsm.resolveFile(sourceUri, fso);
  String sourceFilePath = sourceFileObject.getName().getPath();
  FileObject targetFileObject = fsm.resolveFile(targetUri, fso);
 FileObject tfo = targetFileObject;
 if(tfo.getType() == FileType.FOLDER)
   tfo = 
 targetFileObject.resolveFile(sourceFileObject.getName().getBaseName());
   LOGGER.info(The URI is a file);
LOGGER.info(Remote Path: [ + sourceFileObject.getName().getPath() + 
 ] Local Path: [ + tfo.getName().getPath() + ]);
   copyFile(sourceFileObject, tfo);
 copyFrom method:
  private void copyFile(FileObject sourceFileObject, FileObject 
 targetFileObject) 
{  
   targetFileObject.copyFrom(sourceFileObject, new 
 AllFileSelector()); 
   copiedFiles.add(sourceFileObject.getName().getPath());
   } catch (FileSystemException e) 
   {
   failedFiles.add(sourceFileObject.getName().getPath());
   failedFileExceptions.add(e);
   LOGGER.error(Exception in FileTransferAgent:copyFile 
 +e);
   }
}
 exception is:
 Exception in FileTransferAgent:copyFile 
 org.apache.commons.vfs.FileSystemException: Could not copy 
 ftp://usename:password@ipaddress/home/blrproj/console.out; because it does 
 not exist.
 org.apache.commons.vfs.FileSystemException: Could not copy 
 ftp://usename:password@ipaddress/home/blrproj/console.out; because it does 
 not exist.
 at 
 org.apache.commons.vfs.provider.AbstractFileObject.copyFrom(AbstractFileObject.java:858)
 at FileTransferAgent.copyFile(FileTransferAgent.java:153)
 at FileTransferAgent.copyFiles(FileTransferAgent.java:131)
 at FileTransferAgent.main(FileTransferAgent.java:238)

--
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] (CODEC-121) QuotedPrintableCodec does not support soft line break per the 'quoted-printable' example on Wikipedia

2012-03-07 Thread Gary D. Gregory (Resolved) (JIRA)


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

Gary D. Gregory resolved CODEC-121.
---

Resolution: Fixed

Patch applied with slight modifications. Thank you!

 QuotedPrintableCodec does not support soft line break per the 
 'quoted-printable' example on Wikipedia
 -

 Key: CODEC-121
 URL: https://issues.apache.org/jira/browse/CODEC-121
 Project: Commons Codec
  Issue Type: Bug
Affects Versions: 1.5
 Environment: I tested on Windows 7.
Reporter: Java John
  Labels: codec, decode, quoted-printable
 Fix For: 1.x

 Attachments: CODEC-121.patch, CODEC-121_v2.patch


 Writing a unit test I discovered that the example Wikipedia uses for 
 quoted-printable data does not decode but instead throws an exception.  
 Their example is here:  http://en.wikipedia.org/wiki/Quoted-printable#Example
 test:
   String qpdata   = If you believe that truth=3Dbeauty, then surely=20=\r\n 
 +
   mathematics is the most beautiful branch of philosophy.;
   String expected = If you believe that truth=beauty, then surely  +
   mathematics is the most beautiful branch of philosophy.;
   assertEquals( expected,  new QuotedPrintableCodec().decode(qpdata) );
 I suppose I could fix if you like but currently I'm not a registered 
 developer.  

--
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] (CODEC-121) QuotedPrintableCodec does not support soft line break per the 'quoted-printable' example on Wikipedia

2012-03-07 Thread Gary D. Gregory (Updated) (JIRA)


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

Gary D. Gregory updated CODEC-121:
--

Affects Version/s: 1.6
Fix Version/s: (was: 1.x)
   1.6.1

 QuotedPrintableCodec does not support soft line break per the 
 'quoted-printable' example on Wikipedia
 -

 Key: CODEC-121
 URL: https://issues.apache.org/jira/browse/CODEC-121
 Project: Commons Codec
  Issue Type: Bug
Affects Versions: 1.5, 1.6
 Environment: I tested on Windows 7.
Reporter: Java John
  Labels: codec, decode, quoted-printable
 Fix For: 1.6.1

 Attachments: CODEC-121.patch, CODEC-121_v2.patch


 Writing a unit test I discovered that the example Wikipedia uses for 
 quoted-printable data does not decode but instead throws an exception.  
 Their example is here:  http://en.wikipedia.org/wiki/Quoted-printable#Example
 test:
   String qpdata   = If you believe that truth=3Dbeauty, then surely=20=\r\n 
 +
   mathematics is the most beautiful branch of philosophy.;
   String expected = If you believe that truth=beauty, then surely  +
   mathematics is the most beautiful branch of philosophy.;
   assertEquals( expected,  new QuotedPrintableCodec().decode(qpdata) );
 I suppose I could fix if you like but currently I'm not a registered 
 developer.  

--
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] [Created] (DAEMON-246) jsvc fails to load libcap.so.2 from /lib64

2012-03-07 Thread Emily Middleton (Created) (JIRA)

jsvc fails to load libcap.so.2 from /lib64
--

 Key: DAEMON-246
 URL: https://issues.apache.org/jira/browse/DAEMON-246
 Project: Commons Daemon
  Issue Type: Bug
  Components: Jsvc
Affects Versions: 1.0.10
 Environment: Fedora Core 16 (x86_64, using an x86_64 jsvc), CentOS 5.5 
(x86_86, using an x86_64 jsvc), Debian Squeeze (x86_64, using an i686 jsvc), 
Debian Wheezy (x86_64, using an i686 jsvc)
Reporter: Emily Middleton


I see this when running jsvc -debug ...

Attemtping to load library /lib/libcap.so.2
Attemtping to load library /lib/libcap.so.1
Attemtping to load library /lib/libcap.so
Attemtping to load library /usr/lib/libcap.so.2
Attemtping to load library /usr/lib/libcap.so.1
Attemtping to load library /usr/lib/libcap.so
failed loading capabilities library -- /usr/lib/libcap.so: cannot open shared
object file: No such file or directory.

This does not work on 64bit Fedora, as the lib directory is /lib64/.

It also won't work if you're using a 32bit copy of jsvc on a 64bit copy of 
Debian, which has a similar problem (the 32bit copy of libcap.so.2 is found at 
/lib32/libcap.so.2).

These alternative library locations are mentioned in the Linux filesystem 
hierarchy standard 
(http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL).

The hard-coded /lib and /usr/lib paths in jsvc are counter-productive in the 
environments mentioned, and also in environments where the user expects to be 
able to control the library search path with the LD_LIBRARY_PATH environment 
variable.  jsvc should be utilising the normal ld.so search path.  This can be 
achieved even with a desire to be able to load either version 1 or 2 of libcap 
(as requested in https://issues.apache.org/jira/browse/DAEMON-234) because you 
don't need to give a full path to dlopen, according to its man page on Linux:

If filename contains a slash (/), then it is interpreted as a (relative or 
absolute) pathname.  Otherwise, the dynamic linker searches for the library as 
follows ... (see ld.so(8) for further details)

So the issue can be resolved by simply making libcap_locs contain the desired 
filenames rather than pathnames.  Patch will be attached shortly.


--
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] (DAEMON-246) jsvc fails to load libcap.so.2 from /lib64

2012-03-07 Thread Emily Middleton (Updated) (JIRA)


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

Emily Middleton updated DAEMON-246:
---

Attachment: patch.txt

Let dlopen use the default search path for libraries

 jsvc fails to load libcap.so.2 from /lib64
 --

 Key: DAEMON-246
 URL: https://issues.apache.org/jira/browse/DAEMON-246
 Project: Commons Daemon
  Issue Type: Bug
  Components: Jsvc
Affects Versions: 1.0.10
 Environment: Fedora Core 16 (x86_64, using an x86_64 jsvc), CentOS 
 5.5 (x86_86, using an x86_64 jsvc), Debian Squeeze (x86_64, using an i686 
 jsvc), Debian Wheezy (x86_64, using an i686 jsvc)
Reporter: Emily Middleton
 Attachments: patch.txt


 I see this when running jsvc -debug ...
 Attemtping to load library /lib/libcap.so.2
 Attemtping to load library /lib/libcap.so.1
 Attemtping to load library /lib/libcap.so
 Attemtping to load library /usr/lib/libcap.so.2
 Attemtping to load library /usr/lib/libcap.so.1
 Attemtping to load library /usr/lib/libcap.so
 failed loading capabilities library -- /usr/lib/libcap.so: cannot open shared
 object file: No such file or directory.
 This does not work on 64bit Fedora, as the lib directory is /lib64/.
 It also won't work if you're using a 32bit copy of jsvc on a 64bit copy of 
 Debian, which has a similar problem (the 32bit copy of libcap.so.2 is found 
 at /lib32/libcap.so.2).
 These alternative library locations are mentioned in the Linux filesystem 
 hierarchy standard 
 (http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL).
 The hard-coded /lib and /usr/lib paths in jsvc are counter-productive in the 
 environments mentioned, and also in environments where the user expects to be 
 able to control the library search path with the LD_LIBRARY_PATH environment 
 variable.  jsvc should be utilising the normal ld.so search path.  This can 
 be achieved even with a desire to be able to load either version 1 or 2 of 
 libcap (as requested in https://issues.apache.org/jira/browse/DAEMON-234) 
 because you don't need to give a full path to dlopen, according to its man 
 page on Linux:
 If filename contains a slash (/), then it is interpreted as a (relative or 
 absolute) pathname.  Otherwise, the dynamic linker searches for the library 
 as follows ... (see ld.so(8) for further details)
 So the issue can be resolved by simply making libcap_locs contain the desired 
 filenames rather than pathnames.  Patch will be attached shortly.

--
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] (LANG-790) Null safe Navigation in ObjectUtils

2012-03-07 Thread Gary D. Gregory (Commented) (JIRA)

[
https://issues.apache.org/jira/browse/LANG-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224492#comment-13224492
]

Gary D. Gregory commented on LANG-790:
--

IMO, the request is not for another expression language or interpreter, it is
for just an utility method for easy navigation.

That does not make sense to me, when you have a string that maps to a sequence
of method executions that does not involve code generation, then you gave an
interpreter.

if(a!=null a.getB()!=null a.getB().getC())

For this kind of code, you have to ask yourself if null is a legal value in the
model or a programming/configuration error where an NPE or IAE would be
justified.

JavaScript in Java6 - I guess this is not a solution for the problem we are
trying to solve in Java, converting Java Object to java script object each time
may not be a good choice, if this is the choice even we can use groovy or any
other languages supported by JVM to solve this problem, the main objective is
to find easy solution with in java not outside.

Scripting *is* part of Java, and the JS engine is in Java so I am not sure what
conversion you are talking about. Like you say and this is true in general,
this may not be a good choice but is might just as well be a good choice.
You won't know until you try. By the same logic, the solution you propose might
not be a good choice either! You'll only know when you compare both solutions.
If you want to take the time to do that, please go ahead, I'm sure the results
would be interesting :)

for your question on Arrays, Collections, Maps -- when we can navigate an
object safely on nulls, we can do so in these as well, after all they are all
just group of Objects.

Uh? So *are* proposing to already augment the syntax to support [] addressing?

for your question on Private Methods -- I am not sure what is your point with
Private methods.

Should your . be allowed to access private fields and methods?

for your point on Full Interpreter -- I am not sure what is the need of
interpreter in this case.

See above.

Cheers,
Gary

If you really want this, keep on bringing it up here and on the ML.

Null safe Navigation in ObjectUtils
---

Key: LANG-790
URL: https://issues.apache.org/jira/browse/LANG-790
Project: Commons Lang
Issue Type: New Feature
Reporter: Gokul Nanthakumar C

Adding a method for null safe navigation of objects will be very helpful. for
example a method like
ObjectUtils.getValue(Object obj, String path, String defaultValue);
ex :ObjectUtils.getValue(myObject, x.y.z, default);
it will navigate in the myObject like myObject.getX().getY().getZ(), if any
thing in the path is null (x,y or z), it will return the default value.
It will be really useful, it is like null safe navigation in groovy.

--
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] (SANDBOX-291) Lots of possible changes


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

Emmanuel Bourg updated SANDBOX-291:
---

Description: 
I made a lot of changes to pretty much all of the classes in the csv package.  
I thought it would be better to put all of the the changes here in one issue, 
but feel free to only take the parts you like (if any).  Hopefully if nothing 
else the test cases will be useful to you.

I'll try to list most of the changes here, but I'm sure I'm forgetting some. 
This should include all of the big changes at least. I focused mostly on the 
parser, but I also made a few changes to the printer classes (although I don't 
think I added any new test cases there).

h3. General Changes

- Changed all class names with CSV in them to use Csv. This is how it 
appears in the commons-lang escapeCsv methods and I think it's easier to read 
the class name when acronyms are not in all upper case. (x) {color:red}3 letter 
acronyms are usually kept in uppercase (for example URLConnection or SAXParser 
in the JDK, but here are exceptions){color}

- Formatted the code. I used Eclipse with a version of the Java formatting 
style that uses spaces instead of tabs and with a few other small changes to 
try to make it more similar to the style of this code. The formatting was 
inconsistent before (sometimes 2 space indent, sometimes 4) which made it 
really hard to work on. (/) {color:green}DONE{color}

- Removed all deprecated methods/constructors (/) {color:green}DONE{color}

- Made all public classes final. If there is ever a need to create subclasses 
of them then this could be changed, but I think it would be better to at least 
start them as final (since once they are released as non-final it's hard to go 
back).

- A few bug fixes (and test cases for them)

h3. CsvParser

- There were a few bugs for special cases, so I made as small of changes as I 
could to the parser code to fix these.

- Added a lot of test cases. I created a test case for all bugs that I found, 
so even if you don't use my changes to this class you should be able to use the 
test cases to find all of the same bugs.

- Added a close method.

- Renamed the nextValue method to getValue (so it is more consistent with the 
getAll and getLine method names). I think I would prefer to use a different 
method name prefix for all three of these (like readAll) since I wouldn't 
normally expect a get method to have side effects, but I didn't want to just 
change the names of the most used methods. (x) {color:red}This method has been 
removed, the parser now works line by line.{color}

- Changed the getLineNumber method to return the correct line number when there 
are multi-line values.

- Moved all of the lexer methods into an inner CsvLexer class that is 
completely independent of the CsvParser class. The methods were already 
separated out, so it wasn't a very big change. I also moved the lexer test 
cases into a new CsvLexerTest class.

- Got rid of the interpreting unicode escape options. This doesn't really have 
anything to do with parsing a CSV file so I think it should be left up to the 
user of the class to implement this if needed. As an example, I made a 
CsvParserUnicodeEscapeTest class that uses the code from the lexer in a Reader 
subclass. One nice thing is that with this implementation, the interpreted 
values can be used as the delimiter, encapsulator, etc. (/) {color:green}DONE - 
The unicode unescaping is now handled by a class implementing java.io.Reader 
(to be contributed to Commons IO).{color}

- Got rid of the escape option for the same reason as the unicode escape 
option. I replaced it with an encapsulator escape option that is only used as 
an escape operator on the encapsulator character.

h3. ExtendedBufferedReader

- Greatly simplified this class. I removed all the methods that weren't being 
used (including keeping track of the line number) and changed the lookahead 
option to use the BufferedReader mark and reset methods.


h3. CsvStrategy

- I split this class into three classes: an abstract base class (CsvStrategy), 
a parser-specific version (CsvParseStrategy) and a printer-specific version 
(CsvPrintStrategy). I didn't like that the strategy was used for both parsing 
and printing even though some of the values only applied to parsing (and there 
could be values that apply only to printing as well).

- Made this class immutable (as described in SANDBOX-279) (/) 
{color:green}DONE{color}

- Changed the whitespace options to not ignore whitespace by default. This is 
what the document at http://www.rfc-editor.org/rfc/rfc4180.txt recommends for 
the CSV format, so I think it should be like that by default. I added an 
IGNORE_WHITESPACE_STRATEGY field that works the same as the old defaults. (/) 
{color:green}DONE{color}

- Removed the interpretUnicodeEscape option and replaced the escape field with 
an encapsuatorEscape

[jira] [Commented] (DBCP-363) dbcp bundle should use DynamicImport

2012-03-07 Thread Jukka Zitting (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/DBCP-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224547#comment-13224547
 ] 

Jukka Zitting commented on DBCP-363:


Having DynamicImport in place does not prevent DBCP from also using the 
DataSourceFactory mechanism in OSGi.

Meanwhile defining DynamicImport for DBCP does solve the problem for cases 
where the JDBC driver exports the relevant driver classes but does not (yet) 
implement a DataSourceFactory service.

 dbcp bundle should use DynamicImport
 

 Key: DBCP-363
 URL: https://issues.apache.org/jira/browse/DBCP-363
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: 1.3, 1.4
Reporter: Felix Mayerhuber
 Fix For: 1.4.1


 The bundle provided in the maven central of the commons.dbcp doesn't have a 
 DynamicImport defined. This resolves in following error:
 If you want to use a BasicDataSource class as dataSource and the class is 
 provided by the osgi environment (equinox, ...) the dataSource is not able to 
 be created due to a ClassNotFoundException. If the bundle would have set 
 DynamicImport it works. (I had to change from your bundle to the commons.dbcp 
 bundle provided by servicemix, because there the DynamicImport is set)

--
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] [Created] (MATH-765) Refactoring the vector and matrix classes

2012-03-07 Thread Created

Refactoring the vector and matrix classes
-

 Key: MATH-765
 URL: https://issues.apache.org/jira/browse/MATH-765
 Project: Commons Math
  Issue Type: Improvement
Affects Versions: 4.0
Reporter: Sébastien Brisard


{panel:title=Warning|borderStyle=solid}
This is not a bug report, but rather a summary of all discussions which have 
taken place on the mailing list regarding the refactoring of the vector and 
matrix classes. Indeed, it has been argued many times that the {{RealVector}} 
and {{RealMatrix}} interfaces are really cluttered, and could benefit from 
other approaches (like functional programming). 

The description of this ticket will be updated as the discussion progresses on 
the mailing-list, and new JIRA tickets will be created to carry out the real 
work. In order to keep this ticket tidy, contributors should refrain from 
commenting on this website. Instead, messages should be posted on the dev 
mailing-list.
{panel}

--
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] (SANDBOX-291) Lots of possible changes

2012-03-07 Thread Leandro Ariel Pezzente (Commented) (JIRA)


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

Emmanuel Bourg updated SANDBOX-291:
---

Description: 
I made a lot of changes to pretty much all of the classes in the csv package.  
I thought it would be better to put all of the the changes here in one issue, 
but feel free to only take the parts you like (if any).  Hopefully if nothing 
else the test cases will be useful to you.

I'll try to list most of the changes here, but I'm sure I'm forgetting some. 
This should include all of the big changes at least. I focused mostly on the 
parser, but I also made a few changes to the printer classes (although I don't 
think I added any new test cases there).

h3. General Changes

- Changed all class names with CSV in them to use Csv. This is how it 
appears in the commons-lang escapeCsv methods and I think it's easier to read 
the class name when acronyms are not in all upper case. (x) {color:red}3 letter 
acronyms are usually kept in uppercase (for example URLConnection or SAXParser 
in the JDK, but here are exceptions){color}

- Formatted the code. I used Eclipse with a version of the Java formatting 
style that uses spaces instead of tabs and with a few other small changes to 
try to make it more similar to the style of this code. The formatting was 
inconsistent before (sometimes 2 space indent, sometimes 4) which made it 
really hard to work on. (/) {color:green}DONE{color}

- Removed all deprecated methods/constructors (/) {color:green}DONE{color}

- Made all public classes final. If there is ever a need to create subclasses 
of them then this could be changed, but I think it would be better to at least 
start them as final (since once they are released as non-final it's hard to go 
back).

- A few bug fixes (and test cases for them)

h3. CsvParser

- There were a few bugs for special cases, so I made as small of changes as I 
could to the parser code to fix these.

- Added a lot of test cases. I created a test case for all bugs that I found, 
so even if you don't use my changes to this class you should be able to use the 
test cases to find all of the same bugs.

- Added a close method.

- Renamed the nextValue method to getValue (so it is more consistent with the 
getAll and getLine method names). I think I would prefer to use a different 
method name prefix for all three of these (like readAll) since I wouldn't 
normally expect a get method to have side effects, but I didn't want to just 
change the names of the most used methods. (x) {color:red}This method has been 
removed, the parser now works line by line.{color}

- Changed the getLineNumber method to return the correct line number when there 
are multi-line values.

- Moved all of the lexer methods into an inner CsvLexer class that is 
completely independent of the CsvParser class. The methods were already 
separated out, so it wasn't a very big change. I also moved the lexer test 
cases into a new CsvLexerTest class. (/) {color:green}DONE{color}

- Got rid of the interpreting unicode escape options. This doesn't really have 
anything to do with parsing a CSV file so I think it should be left up to the 
user of the class to implement this if needed. As an example, I made a 
CsvParserUnicodeEscapeTest class that uses the code from the lexer in a Reader 
subclass. One nice thing is that with this implementation, the interpreted 
values can be used as the delimiter, encapsulator, etc. (/) {color:green}DONE - 
The unicode unescaping is now handled by a class implementing java.io.Reader 
(to be contributed to Commons IO).{color}

- Got rid of the escape option for the same reason as the unicode escape 
option. I replaced it with an encapsulator escape option that is only used as 
an escape operator on the encapsulator character.

h3. ExtendedBufferedReader

- Greatly simplified this class. I removed all the methods that weren't being 
used (including keeping track of the line number) and changed the lookahead 
option to use the BufferedReader mark and reset methods.


h3. CsvStrategy

- I split this class into three classes: an abstract base class (CsvStrategy), 
a parser-specific version (CsvParseStrategy) and a printer-specific version 
(CsvPrintStrategy). I didn't like that the strategy was used for both parsing 
and printing even though some of the values only applied to parsing (and there 
could be values that apply only to printing as well). (x) {color:red}There 
aren't enough properties in CSVFormat to split the class{color}

- Made this class immutable (as described in SANDBOX-279) (/) 
{color:green}DONE{color}

- Changed the whitespace options to not ignore whitespace by default. This is 
what the document at http://www.rfc-editor.org/rfc/rfc4180.txt recommends for 
the CSV format, so I think it should be like that by default. I added an 
IGNORE_WHITESPACE_STRATEGY field that works the same as the old defaults. (/)

[jira] [Updated] (MATH-765) Refactoring the vector and matrix classes

2012-03-07 Thread Updated


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

Sébastien Brisard updated MATH-765:
---

Description: 
{panel:title=Warning|borderStyle=solid}
This is not a bug report, but rather a summary of all discussions which have 
taken place on the mailing list regarding the refactoring of the vector and 
matrix classes. Indeed, it has been argued many times that the {{RealVector}} 
and {{RealMatrix}} interfaces are really cluttered, and could benefit from 
other approaches (like functional programming). 

The description of this ticket will be updated as the discussion progresses on 
the mailing-list, and new JIRA tickets will be created to carry out the real 
work. In order to keep this ticket tidy, contributors should refrain from 
commenting on this website. Instead, messages should be posted on the dev 
mailing-list.
{panel}


h1. The current API (version 3.0)

In this section, the current interfaces for vectors and matrices are compared. 
Vectors and matrices are two mathematical objects which are very close in 
nature. Their implementations should therefore be as similar as possible. The 
methods will be sorted as follows
* methods reflecting the mathematical structure of vector space: addition, 
multiplication by a scalar, matrix-vector product, ...
* methods reflecting the mathematical structure of euclidean space
* ...

h2. Methods reflecting the mathematical structure of vector space
|| {{RealVector}}  || {{RealMatrix}}
   || Comments ||
| {{RealVector add(RealVector v)}} | {{RealMatrix add(RealMatrix m)}}   
   |   |
| {{int getDimension()}}   | {{int getRowDimension()}},\\ {{int 
getColumnDimension()}} |   |
| {{RealVector mapMultiply(double d)}} | {{scalarMultiply(double d)}}   
   |   |
|  | {{multiply(RealMatrix m)}} 
   |   |
|  | {{double[] operate(double[])}} 
   |   |
|  | {{RealVector operate(RealVector)}} 
   |   |
|  | {{double[] preMultiply(double[])}} 
   |   |
|  | {{RealMatrix preMultiply(RealMatrix)}} 
   |   |
|  | {{RealVector preMultiply(RealVector)}} 
   |   |

h2. Methods reflecting the mathematical structure of euclidean space

  was:
{panel:title=Warning|borderStyle=solid}
This is not a bug report, but rather a summary of all discussions which have 
taken place on the mailing list regarding the refactoring of the vector and 
matrix classes. Indeed, it has been argued many times that the {{RealVector}} 
and {{RealMatrix}} interfaces are really cluttered, and could benefit from 
other approaches (like functional programming). 

The description of this ticket will be updated as the discussion progresses on 
the mailing-list, and new JIRA tickets will be created to carry out the real 
work. In order to keep this ticket tidy, contributors should refrain from 
commenting on this website. Instead, messages should be posted on the dev 
mailing-list.
{panel}


 Refactoring the vector and matrix classes
 -

 Key: MATH-765
 URL: https://issues.apache.org/jira/browse/MATH-765
 Project: Commons Math
  Issue Type: Improvement
Affects Versions: 4.0
Reporter: Sébastien Brisard
  Labels: api-change, linear

 {panel:title=Warning|borderStyle=solid}
 This is not a bug report, but rather a summary of all discussions which have 
 taken place on the mailing list regarding the refactoring of the vector and 
 matrix classes. Indeed, it has been argued many times that the {{RealVector}} 
 and {{RealMatrix}} interfaces are really cluttered, and could benefit from 
 other approaches (like functional programming). 
 The description of this ticket will be updated as the discussion progresses 
 on the mailing-list, and new JIRA tickets will be created to carry out the 
 real work. In order to keep this ticket tidy, contributors should refrain 
 from commenting on this website. Instead, messages should be posted on the 
 dev mailing-list.
 {panel}
 h1. The current API (version 3.0)
 In this section, the current interfaces for vectors and matrices are 
 compared. Vectors and matrices are two mathematical objects which are very 
 close in nature. Their implementations should therefore be as similar as 
 possible. The methods will be sorted as follows
 * methods reflecting the mathematical structure of vector space: addition, 
 multiplication by a scalar,

[jira] [Commented] (CODEC-132) BeiderMorseEncoder OOM issues

2012-03-07 Thread Matthew Pocock (Commented) (JIRA)

[
https://issues.apache.org/jira/browse/CODEC-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224610#comment-13224610
]

Matthew Pocock commented on CODEC-132:
--

Hi,

Limiting the size of the set of intermediate phonemes considered is probably a
good thing for this kind of random-string testing, and may well have no
discernible negative impact in normal use. The rules are not really intended to
apply to random strings, and words from languages (and in particular, names)
are very much not random.

I've not run a corpus of real names through this code to estimate the normal
range of this phoneme set size. If we start seeing incomplete or strange
results after this change, perhaps it would be worth doing.

Matthew

BeiderMorseEncoder OOM issues
-

Key: CODEC-132
URL: https://issues.apache.org/jira/browse/CODEC-132
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.6
Reporter: Robert Muir
Attachments: CODEC-132.patch, CODEC-132_test.patch

In Lucene/Solr, we integrated this encoder into the latest release.
Our tests use a variety of random strings, and we have recent jenkins failures
from some input streams (of length = 10), using huge amounts of memory (e.g.
64MB),
resulting in OOM.
I've created a test case (length is 30 here) that will OOM with -Xmx256M.
I haven't dug into this much as to what's causing it, but I suspect there
might be a bug
revolving around certain punctuation characters: we didn't see this happening
until
we beefed up our random string generation to start producing html-like
strings.

[jira] [Commented] (CODEC-132) BeiderMorseEncoder OOM issues

2012-03-07 Thread Robert Muir (Commented) (JIRA)

[
https://issues.apache.org/jira/browse/CODEC-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224619#comment-13224619
]

Robert Muir commented on CODEC-132:
---

Thomas: I haven't tested your patch with Lucene/Solr, but I'm +1 on premise.

In reality the random testing we do may seem absurd... yes in a way its totally
unrealistic.

On the other hand if someone is indexing/crawling data, often times this
type-detection of either file-type or character set
or whatever is really just a heuristic: its really impossible to ultimately
prevent the indexing of some binary file
(e.g. misdetected character set or simply a video file or whatever). This is
part of why we do the testing we do.

Thanks again everyone for digging in and reviewing.

BeiderMorseEncoder OOM issues
-

[jira] [Commented] (MATH-765) Refactoring the vector and matrix classes


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

Leandro Ariel Pezzente commented on MATH-765:
-

Since inner product should be implemented , shouldnt a user be able to change a 
matrix representation in a given base ? . Something along the lines of :

RealMatrix changeBase( RealMatrix newBase )

Ohhh .. btw , calculating a Matrix's trace could prove usefull too ...

double trace() or static double trace( RealMatrix m )


 Refactoring the vector and matrix classes
 -

 Key: MATH-765
 URL: https://issues.apache.org/jira/browse/MATH-765
 Project: Commons Math
  Issue Type: Improvement
Affects Versions: 4.0
Reporter: Sébastien Brisard
  Labels: api-change, linear

 {panel:title=Warning|borderStyle=solid}
 This is not a bug report, but rather a summary of all discussions which have 
 taken place on the mailing list regarding the refactoring of the vector and 
 matrix classes. Indeed, it has been argued many times that the {{RealVector}} 
 and {{RealMatrix}} interfaces are really cluttered, and could benefit from 
 other approaches (like functional programming). 
 The description of this ticket will be updated as the discussion progresses 
 on the mailing-list, and new JIRA tickets will be created to carry out the 
 real work. In order to keep this ticket tidy, contributors should refrain 
 from commenting on this website. Instead, messages should be posted on the 
 dev mailing-list.
 {panel}
 h1. The current API (version 3.0)
 In this section, the current interfaces for vectors and matrices are 
 compared. Vectors and matrices are two mathematical objects which are very 
 close in nature. Their implementations should therefore be as similar as 
 possible. The methods will be sorted as follows
 * methods reflecting the mathematical structure of vector space: addition, 
 multiplication by a scalar, matrix-vector product, ...
 * methods reflecting the mathematical structure of euclidean space
 * ...
 h2. Methods reflecting the mathematical structure of vector space
 || {{RealVector}}  || {{RealMatrix}}  
  || Comments ||
 | {{RealVector add(RealVector v)}} | {{RealMatrix add(RealMatrix m)}} 
  |   |
 | {{int getDimension()}}   | {{int getRowDimension()}},\\ {{int 
 getColumnDimension()}} |   |
 | {{RealVector mapMultiply(double d)}} | {{scalarMultiply(double d)}} 
  |   |
 |  | {{multiply(RealMatrix m)}}   
  |   |
 |  | {{double[] operate(double[])}}   
  |   |
 |  | {{RealVector operate(RealVector)}}   
  |   |
 |  | {{double[] preMultiply(double[])}}   
  |   |
 |  | {{RealMatrix 
 preMultiply(RealMatrix)}}|   |
 |  | {{RealVector 
 preMultiply(RealVector)}}|   |
 h2. Methods reflecting the mathematical structure of euclidean space

--
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] [Created] (SANDBOX-411) Implement a new version of ConcurrentGraph

2012-03-07 Thread Marco Speranza (Created) (JIRA)

Implement a new version of ConcurrentGraph
--

 Key: SANDBOX-411
 URL: https://issues.apache.org/jira/browse/SANDBOX-411
 Project: Commons Sandbox
  Issue Type: Sub-task
  Components: Graph
Reporter: Marco Speranza
Priority: Minor


As widely discussed in ML it's convenient create a new package 'concurrent' and 
 create a parallel implementation on ConcurrentGraph.



--
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] (SANDBOX-411) Implement a new version of ConcurrentGraph

2012-03-07 Thread Marco Speranza (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SANDBOX-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224695#comment-13224695
 ] 

Marco Speranza commented on SANDBOX-411:


The implementation can use the Read/Write locks. A typical scenario could be 
the execution of different algorithms in a multi-threading environment.

The main problem is ensure that the algorithm is executed into a 
critical-section in order to avoid a possible graph modification.


 Implement a new version of ConcurrentGraph
 --

 Key: SANDBOX-411
 URL: https://issues.apache.org/jira/browse/SANDBOX-411
 Project: Commons Sandbox
  Issue Type: Sub-task
  Components: Graph
Reporter: Marco Speranza
Priority: Minor

 As widely discussed in ML it's convenient create a new package 'concurrent' 
 and  create a parallel implementation on ConcurrentGraph.

--
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] (SANDBOX-411) Implement a new version of ConcurrentGraph

2012-03-07 Thread Marco Speranza (Issue Comment Edited) (JIRA)

[
https://issues.apache.org/jira/browse/SANDBOX-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224695#comment-13224695
]

Marco Speranza edited comment on SANDBOX-411 at 3/7/12 8:48 PM:

The implementation can use the Read/Write locks. A typical scenario could be
the execution of different algorithms in a multi-threading environment.

The main problem is ensure that the algorithm is executed into a
critical-section in order to avoid a possible graph modification.

Thoughts?

was (Author: marco.speranza):
The implementation can use the Read/Write locks. A typical scenario could
be the execution of different algorithms in a multi-threading environment.

The main problem is ensure that the algorithm is executed into a
critical-section in order to avoid a possible graph modification.

Implement a new version of ConcurrentGraph
--

Key: SANDBOX-411
URL: https://issues.apache.org/jira/browse/SANDBOX-411
Project: Commons Sandbox
Issue Type: Sub-task
Components: Graph
Reporter: Marco Speranza
Priority: Minor

As widely discussed in ML it's convenient create a new package 'concurrent'
and create a parallel implementation on ConcurrentGraph.

[jira] [Resolved] (CODEC-132) BeiderMorseEncoder OOM issues

2012-03-07 Thread Gary D. Gregory (Resolved) (JIRA)


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

Gary D. Gregory resolved CODEC-132.
---

   Resolution: Fixed
Fix Version/s: 1.6.1

Patch applied in SVN, plus some other minor test improvements.

 BeiderMorseEncoder OOM issues
 -

 Key: CODEC-132
 URL: https://issues.apache.org/jira/browse/CODEC-132
 Project: Commons Codec
  Issue Type: Bug
Affects Versions: 1.6
Reporter: Robert Muir
 Fix For: 1.6.1

 Attachments: CODEC-132.patch, CODEC-132_test.patch


 In Lucene/Solr, we integrated this encoder into the latest release.
 Our tests use a variety of random strings, and we have recent jenkins failures
 from some input streams (of length = 10), using huge amounts of memory (e.g. 
  64MB),
 resulting in OOM.
 I've created a test case (length is 30 here) that will OOM with -Xmx256M. 
 I haven't dug into this much as to what's causing it, but I suspect there 
 might be a bug
 revolving around certain punctuation characters: we didn't see this happening 
 until
 we beefed up our random string generation to start producing html-like 
 strings.

--
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] (CODEC-132) BeiderMorseEncoder OOM issues

2012-03-07 Thread Thomas Neidhart (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/CODEC-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224729#comment-13224729
 ] 

Thomas Neidhart commented on CODEC-132:
---

@Matthew: thanks for your feedback, I had some experience with similar rule 
base systems before, and knew that they can become very fragile with unforeseen 
input as the number of rules grows (especially generic ones). Anyway, your code 
was easy to debug, and nice to read!

@Robert: your tests make perfect sense imo, thanks for reporting back.

@Gary: thanks for applying the patch

 BeiderMorseEncoder OOM issues
 -

 Key: CODEC-132
 URL: https://issues.apache.org/jira/browse/CODEC-132
 Project: Commons Codec
  Issue Type: Bug
Affects Versions: 1.6
Reporter: Robert Muir
 Fix For: 1.6.1

 Attachments: CODEC-132.patch, CODEC-132_test.patch


 In Lucene/Solr, we integrated this encoder into the latest release.
 Our tests use a variety of random strings, and we have recent jenkins failures
 from some input streams (of length = 10), using huge amounts of memory (e.g. 
  64MB),
 resulting in OOM.
 I've created a test case (length is 30 here) that will OOM with -Xmx256M. 
 I haven't dug into this much as to what's causing it, but I suspect there 
 might be a bug
 revolving around certain punctuation characters: we didn't see this happening 
 until
 we beefed up our random string generation to start producing html-like 
 strings.

--
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] (SANDBOX-404) Simplify weight model

2012-03-07 Thread Claudio Squarcella (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224737#comment-13224737
 ] 

Claudio Squarcella commented on SANDBOX-404:


Hi,

just a quick notice to confirm that I just committed the modifications 
contained in [the second patch posted 
above|https://issues.apache.org/jira/secure/attachment/12516966/SANDBOX-404_gettingRidOfOrderedMonoid.patch]
 (see [r1298136|http://svn.apache.org/viewvc?view=revisionrevision=1298136]) :)

Claudio

 Simplify weight model
 -

 Key: SANDBOX-404
 URL: https://issues.apache.org/jira/browse/SANDBOX-404
 Project: Commons Sandbox
  Issue Type: Improvement
  Components: Graph
Reporter: Simone Tripodi
 Attachments: SANDBOX-404.patch, 
 SANDBOX-404_FromMonoidToAddition.patch, 
 SANDBOX-404_gettingRidOfOrderedMonoid.patch


 As discussed on {{dev@}}, {{Zero}}, {{Semigroup}} and {{Monoid}} can be 
 merged directly in one single interface

--
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] [Created] (MATH-766) Refactor RealMatrix and proper SparseRealMatrix

2012-03-07 Thread sergio brignone (Created) (JIRA)

Refactor RealMatrix and proper SparseRealMatrix
---

 Key: MATH-766
 URL: https://issues.apache.org/jira/browse/MATH-766
 Project: Commons Math
  Issue Type: Improvement
Affects Versions: 2.2
Reporter: sergio brignone


As is in Version 2.2, SparseRealMatrix is identical to RealMatrix. The latest 
contains methods that are practically incopatible with sparse implementations 
(e.g. getData retuns double[][] ... not usefull for sparse matrices). 
Sugestion: Split RealMatrix into RealMatrix and FullRealMatrix that extends 
RealMatrix and update SparseRealMatrix. Refactor AbstractRealMatrix as well.


--
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] (CODEC-63) Implement Nysiis

2012-03-07 Thread Thomas Neidhart (Updated) (JIRA)

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

Thomas Neidhart updated CODEC-63:
-

Attachment: CODEC-63-reworked.tar

It is a pity, that such a feature request with attached patch stays open for
such a long time. I have reworked the patch, and added more unit tests (in
comparison with http://www.dropby.com/NYSIIS.html).

The implementation at dropby has some bugs tough, which have been addressed in
this implementation:

* no key character should be appended if it is the same as the previous one,
this applies also for the first key char, so it should not be valid to have two
times the same char at the beginning of the result (e.g. SSNAT). This would
btw. also circumvent the idea of the code to map similar names to a unified one.

* in the dropby example, certain names are wrongly transcoded, e.g. KOEHN -
C, but should be CAN

Note: the implementation is optimized for readability and not for performance.

Implement Nysiis

Key: CODEC-63
URL: https://issues.apache.org/jira/browse/CODEC-63
Project: Commons Codec
Issue Type: New Feature
Affects Versions: 1.x
Reporter: Henri Yandell
Fix For: 1.x

Attachments: CODEC-63-reworked.tar, Nysiis.patch

http://en.wikipedia.org/wiki/NYSIIS

[jira] [Resolved] (CODEC-131) DoubleMetaphone javadoc contains dead links

2012-03-07 Thread Thomas Neidhart (Resolved) (JIRA)


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

Thomas Neidhart resolved CODEC-131.
---

   Resolution: Fixed
Fix Version/s: 1.6.1

The links have been updated:

 * [http://drdobbs.com/184401251?pgno=2]
 * [http://en.wikipedia.org/wiki/Metaphone]

Thanks for reporting it!


 DoubleMetaphone javadoc contains dead links
 ---

 Key: CODEC-131
 URL: https://issues.apache.org/jira/browse/CODEC-131
 Project: Commons Codec
  Issue Type: Bug
Reporter: Santiago M. Mola
Priority: Trivial
  Labels: documentation
 Fix For: 1.6.1


 DoubleMetaphone documentation points to dead links in the domain cuj.com:
Original Article: http://www.cuj.com/documents/s=8038/cuj0006philips/
Original Source Code: ftp://ftp.cuj.com/pub/2000/1806/philips.zip

--
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] (SANDBOX-408) CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe


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

Sebb updated SANDBOX-408:
-

Attachment: CSVFormat.java

CSVFormat.java reworked to use all final variables.

[Can be provided as diff if required; it's easier to understand a full source 
file]

 CSVFormat describes itself as immutable, but it is not - in particular it is 
 not thread-safe
 

 Key: SANDBOX-408
 URL: https://issues.apache.org/jira/browse/SANDBOX-408
 Project: Commons Sandbox
  Issue Type: Bug
  Components: CSV
Reporter: Sebb
 Attachments: CSVFormat.java


 CSVFormat describes itself as immutable, but it is not @Immutable - the class 
 fields are all mutable.
 The methods that change the fields do so by creating a clone, and returning 
 the changed clone.
 So in a sense the class is immutable.
 However, the normal expectation is that @Immutable classes are @ThreadSafe.
 CSVFormat is not thread-safe, because the fields are not volatile, and the 
 fields are not written  read using a common lock.
 The comment needs to be clarified or removed.

--
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] (SANDBOX-408) CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe

2012-03-07 Thread Emmanuel Bourg (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SANDBOX-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224834#comment-13224834
 ] 

Emmanuel Bourg commented on SANDBOX-408:


Thank you for showing how this can be implemented Sebb. Considering that thread 
safety is not a goal I think I still prefer the current implementation.

 CSVFormat describes itself as immutable, but it is not - in particular it is 
 not thread-safe
 

 Key: SANDBOX-408
 URL: https://issues.apache.org/jira/browse/SANDBOX-408
 Project: Commons Sandbox
  Issue Type: Bug
  Components: CSV
Reporter: Sebb
 Attachments: CSVFormat.java


 CSVFormat describes itself as immutable, but it is not @Immutable - the class 
 fields are all mutable.
 The methods that change the fields do so by creating a clone, and returning 
 the changed clone.
 So in a sense the class is immutable.
 However, the normal expectation is that @Immutable classes are @ThreadSafe.
 CSVFormat is not thread-safe, because the fields are not volatile, and the 
 fields are not written  read using a common lock.
 The comment needs to be clarified or removed.

--
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] (SANDBOX-291) Lots of possible changes


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

Emmanuel Bourg updated SANDBOX-291:
---

Description: 
I made a lot of changes to pretty much all of the classes in the csv package.  
I thought it would be better to put all of the the changes here in one issue, 
but feel free to only take the parts you like (if any).  Hopefully if nothing 
else the test cases will be useful to you.

I'll try to list most of the changes here, but I'm sure I'm forgetting some. 
This should include all of the big changes at least. I focused mostly on the 
parser, but I also made a few changes to the printer classes (although I don't 
think I added any new test cases there).

h3. General Changes

- Changed all class names with CSV in them to use Csv. This is how it 
appears in the commons-lang escapeCsv methods and I think it's easier to read 
the class name when acronyms are not in all upper case. (x) {color:red}3 letter 
acronyms are usually kept in uppercase (for example URLConnection or SAXParser 
in the JDK, but here are exceptions){color}

- Formatted the code. I used Eclipse with a version of the Java formatting 
style that uses spaces instead of tabs and with a few other small changes to 
try to make it more similar to the style of this code. The formatting was 
inconsistent before (sometimes 2 space indent, sometimes 4) which made it 
really hard to work on. (/) {color:green}DONE{color}

- Removed all deprecated methods/constructors (/) {color:green}DONE{color}

- Made all public classes final. If there is ever a need to create subclasses 
of them then this could be changed, but I think it would be better to at least 
start them as final (since once they are released as non-final it's hard to go 
back).

- A few bug fixes (and test cases for them)

h3. CsvParser

- There were a few bugs for special cases, so I made as small of changes as I 
could to the parser code to fix these.

- Added a lot of test cases. I created a test case for all bugs that I found, 
so even if you don't use my changes to this class you should be able to use the 
test cases to find all of the same bugs.

- Added a close method.

- Renamed the nextValue method to getValue (so it is more consistent with the 
getAll and getLine method names). I think I would prefer to use a different 
method name prefix for all three of these (like readAll) since I wouldn't 
normally expect a get method to have side effects, but I didn't want to just 
change the names of the most used methods. (x) {color:red}This method has been 
removed, the parser now works line by line.{color}

- Changed the getLineNumber method to return the correct line number when there 
are multi-line values.

- Moved all of the lexer methods into an inner CsvLexer class that is 
completely independent of the CsvParser class. The methods were already 
separated out, so it wasn't a very big change. I also moved the lexer test 
cases into a new CsvLexerTest class. (/) {color:green}DONE{color}

- Got rid of the interpreting unicode escape options. This doesn't really have 
anything to do with parsing a CSV file so I think it should be left up to the 
user of the class to implement this if needed. As an example, I made a 
CsvParserUnicodeEscapeTest class that uses the code from the lexer in a Reader 
subclass. One nice thing is that with this implementation, the interpreted 
values can be used as the delimiter, encapsulator, etc. (/) {color:green}DONE - 
The unicode unescaping is now handled by a class implementing java.io.Reader 
(to be contributed to Commons IO).{color}

- Got rid of the escape option for the same reason as the unicode escape 
option. I replaced it with an encapsulator escape option that is only used as 
an escape operator on the encapsulator character.

h3. ExtendedBufferedReader

- Greatly simplified this class. I removed all the methods that weren't being 
used (including keeping track of the line number) and changed the lookahead 
option to use the BufferedReader mark and reset methods.


h3. CsvStrategy

- I split this class into three classes: an abstract base class (CsvStrategy), 
a parser-specific version (CsvParseStrategy) and a printer-specific version 
(CsvPrintStrategy). I didn't like that the strategy was used for both parsing 
and printing even though some of the values only applied to parsing (and there 
could be values that apply only to printing as well). (x) {color:red}There 
aren't enough properties in CSVFormat to split the class{color}

- Made this class immutable (as described in SANDBOX-279) (/) 
{color:green}DONE{color}

- Changed the whitespace options to not ignore whitespace by default. This is 
what the document at http://www.rfc-editor.org/rfc/rfc4180.txt recommends for 
the CSV format, so I think it should be like that by default. I added an 
IGNORE_WHITESPACE_STRATEGY field that works the same as the old defaults. (/)

[jira] [Commented] (SANDBOX-408) CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe


[ 
https://issues.apache.org/jira/browse/SANDBOX-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224859#comment-13224859
 ] 

Sebb commented on SANDBOX-408:
--

I thought you wanted to be able to pass CSVFormat objects between threads?

As it stands, the implementation is not completely thread-safe.
And the Javadoc comment is still misleading.

 CSVFormat describes itself as immutable, but it is not - in particular it is 
 not thread-safe
 

 Key: SANDBOX-408
 URL: https://issues.apache.org/jira/browse/SANDBOX-408
 Project: Commons Sandbox
  Issue Type: Bug
  Components: CSV
Reporter: Sebb
 Attachments: CSVFormat.java


 CSVFormat describes itself as immutable, but it is not @Immutable - the class 
 fields are all mutable.
 The methods that change the fields do so by creating a clone, and returning 
 the changed clone.
 So in a sense the class is immutable.
 However, the normal expectation is that @Immutable classes are @ThreadSafe.
 CSVFormat is not thread-safe, because the fields are not volatile, and the 
 fields are not written  read using a common lock.
 The comment needs to be clarified or removed.

--
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] (COLLECTIONS-398) BoundedFifoBuffer could be simplified by keeping a count of the number of entries


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

Sebb updated COLLECTIONS-398:
-

Attachment: COLLECTIONS-398.patch

Patch to replace full boolean with numEntries int.

 BoundedFifoBuffer could be simplified by keeping a count of the number of 
 entries
 -

 Key: COLLECTIONS-398
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-398
 Project: Commons Collections
  Issue Type: Improvement
Reporter: Sebb
 Attachments: COLLECTIONS-398.patch


 BoundedFifoBuffer could be much simplified by keeping a count of the number 
 of entries, and dropping the boolean full.
 This would speed up size() and isEmpty() and isFull().

--
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] (SANDBOX-291) Lots of possible changes


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

Emmanuel Bourg updated SANDBOX-291:
---

Description: 
I made a lot of changes to pretty much all of the classes in the csv package.  
I thought it would be better to put all of the the changes here in one issue, 
but feel free to only take the parts you like (if any).  Hopefully if nothing 
else the test cases will be useful to you.

I'll try to list most of the changes here, but I'm sure I'm forgetting some. 
This should include all of the big changes at least. I focused mostly on the 
parser, but I also made a few changes to the printer classes (although I don't 
think I added any new test cases there).

h3. General Changes

- Changed all class names with CSV in them to use Csv. This is how it 
appears in the commons-lang escapeCsv methods and I think it's easier to read 
the class name when acronyms are not in all upper case. (x) {color:red}3 letter 
acronyms are usually kept in uppercase (for example URLConnection or SAXParser 
in the JDK, but here are exceptions){color}

- Formatted the code. I used Eclipse with a version of the Java formatting 
style that uses spaces instead of tabs and with a few other small changes to 
try to make it more similar to the style of this code. The formatting was 
inconsistent before (sometimes 2 space indent, sometimes 4) which made it 
really hard to work on. (/) {color:green}DONE{color}

- Removed all deprecated methods/constructors (/) {color:green}DONE{color}

- Made all public classes final. If there is ever a need to create subclasses 
of them then this could be changed, but I think it would be better to at least 
start them as final (since once they are released as non-final it's hard to go 
back).

- A few bug fixes (and test cases for them)

h3. CsvParser

- There were a few bugs for special cases, so I made as small of changes as I 
could to the parser code to fix these.

- Added a lot of test cases. I created a test case for all bugs that I found, 
so even if you don't use my changes to this class you should be able to use the 
test cases to find all of the same bugs.

- Added a close method.

- Renamed the nextValue method to getValue (so it is more consistent with the 
getAll and getLine method names). I think I would prefer to use a different 
method name prefix for all three of these (like readAll) since I wouldn't 
normally expect a get method to have side effects, but I didn't want to just 
change the names of the most used methods. (x) {color:red}This method has been 
removed, the parser now works line by line.{color}

- Changed the getLineNumber method to return the correct line number when there 
are multi-line values.

- Moved all of the lexer methods into an inner CsvLexer class that is 
completely independent of the CsvParser class. The methods were already 
separated out, so it wasn't a very big change. I also moved the lexer test 
cases into a new CsvLexerTest class. (/) {color:green}DONE{color}

- Got rid of the interpreting unicode escape options. This doesn't really have 
anything to do with parsing a CSV file so I think it should be left up to the 
user of the class to implement this if needed. As an example, I made a 
CsvParserUnicodeEscapeTest class that uses the code from the lexer in a Reader 
subclass. One nice thing is that with this implementation, the interpreted 
values can be used as the delimiter, encapsulator, etc. (/) {color:green}DONE - 
The unicode unescaping is now handled by a class implementing java.io.Reader 
(to be contributed to Commons IO).{color}

- Got rid of the escape option for the same reason as the unicode escape 
option. I replaced it with an encapsulator escape option that is only used as 
an escape operator on the encapsulator character.

h3. ExtendedBufferedReader

- Greatly simplified this class. I removed all the methods that weren't being 
used (including keeping track of the line number) and changed the lookahead 
option to use the BufferedReader mark and reset methods.


h3. CsvStrategy

- I split this class into three classes: an abstract base class (CsvStrategy), 
a parser-specific version (CsvParseStrategy) and a printer-specific version 
(CsvPrintStrategy). I didn't like that the strategy was used for both parsing 
and printing even though some of the values only applied to parsing (and there 
could be values that apply only to printing as well). (x) {color:red}There 
aren't enough properties in CSVFormat to split the class{color}

- Made this class immutable (as described in SANDBOX-279) (/) 
{color:green}DONE{color}

- Changed the whitespace options to not ignore whitespace by default. This is 
what the document at http://www.rfc-editor.org/rfc/rfc4180.txt recommends for 
the CSV format, so I think it should be like that by default. I added an 
IGNORE_WHITESPACE_STRATEGY field that works the same as the old defaults. (/)

[jira] [Commented] (MATH-765) Refactoring the vector and matrix classes

2012-03-07 Thread Gilles (Commented) (JIRA)


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

Gilles commented on MATH-765:
-

Before they try to reinvent the wheel, I suggest that everyone interested in 
this refactoring has a look at the [ojAlgo|http://www.ojalgo.org] project. 
Certainly, there are things to learn from it, either to take inspiration from, 
or to avoid.

 Refactoring the vector and matrix classes
 -

 Key: MATH-765
 URL: https://issues.apache.org/jira/browse/MATH-765
 Project: Commons Math
  Issue Type: Improvement
Affects Versions: 4.0
Reporter: Sébastien Brisard
  Labels: api-change, linear

 {panel:title=Warning|borderStyle=solid}
 This is not a bug report, but rather a summary of all discussions which have 
 taken place on the mailing list regarding the refactoring of the vector and 
 matrix classes. Indeed, it has been argued many times that the {{RealVector}} 
 and {{RealMatrix}} interfaces are really cluttered, and could benefit from 
 other approaches (like functional programming). 
 The description of this ticket will be updated as the discussion progresses 
 on the mailing-list, and new JIRA tickets will be created to carry out the 
 real work. In order to keep this ticket tidy, contributors should refrain 
 from commenting on this website. Instead, messages should be posted on the 
 dev mailing-list.
 {panel}
 h1. The current API (version 3.0)
 In this section, the current interfaces for vectors and matrices are 
 compared. Vectors and matrices are two mathematical objects which are very 
 close in nature. Their implementations should therefore be as similar as 
 possible. The methods will be sorted as follows
 * methods reflecting the mathematical structure of vector space: addition, 
 multiplication by a scalar, matrix-vector product, ...
 * methods reflecting the mathematical structure of euclidean space
 * ...
 h2. Methods reflecting the mathematical structure of vector space
 || {{RealVector}}  || {{RealMatrix}}  
  || Comments ||
 | {{RealVector add(RealVector v)}} | {{RealMatrix add(RealMatrix m)}} 
  |   |
 | {{int getDimension()}}   | {{int getRowDimension()}},\\ {{int 
 getColumnDimension()}} |   |
 | {{RealVector mapMultiply(double d)}} | {{scalarMultiply(double d)}} 
  |   |
 |  | {{multiply(RealMatrix m)}}   
  |   |
 |  | {{double[] operate(double[])}}   
  |   |
 |  | {{RealVector operate(RealVector)}}   
  |   |
 |  | {{double[] preMultiply(double[])}}   
  |   |
 |  | {{RealMatrix 
 preMultiply(RealMatrix)}}|   |
 |  | {{RealVector 
 preMultiply(RealVector)}}|   |
 h2. Methods reflecting the mathematical structure of euclidean space

--
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] (SANDBOX-291) Lots of possible changes


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

Emmanuel Bourg updated SANDBOX-291:
---

Description: 
I made a lot of changes to pretty much all of the classes in the csv package.  
I thought it would be better to put all of the the changes here in one issue, 
but feel free to only take the parts you like (if any).  Hopefully if nothing 
else the test cases will be useful to you.

I'll try to list most of the changes here, but I'm sure I'm forgetting some. 
This should include all of the big changes at least. I focused mostly on the 
parser, but I also made a few changes to the printer classes (although I don't 
think I added any new test cases there).

h3. General Changes

- Changed all class names with CSV in them to use Csv. This is how it 
appears in the commons-lang escapeCsv methods and I think it's easier to read 
the class name when acronyms are not in all upper case. (x) {color:red}3 letter 
acronyms are usually kept in uppercase (for example URLConnection or SAXParser 
in the JDK, but there are some exceptions){color}

- Formatted the code. I used Eclipse with a version of the Java formatting 
style that uses spaces instead of tabs and with a few other small changes to 
try to make it more similar to the style of this code. The formatting was 
inconsistent before (sometimes 2 space indent, sometimes 4) which made it 
really hard to work on. (/) {color:green}DONE{color}

- Removed all deprecated methods/constructors (/) {color:green}DONE{color}

- Made all public classes final. If there is ever a need to create subclasses 
of them then this could be changed, but I think it would be better to at least 
start them as final (since once they are released as non-final it's hard to go 
back).

- A few bug fixes (and test cases for them)

h3. CsvParser

- There were a few bugs for special cases, so I made as small of changes as I 
could to the parser code to fix these.

- Added a lot of test cases. I created a test case for all bugs that I found, 
so even if you don't use my changes to this class you should be able to use the 
test cases to find all of the same bugs.

- Added a close method.

- Renamed the nextValue method to getValue (so it is more consistent with the 
getAll and getLine method names). I think I would prefer to use a different 
method name prefix for all three of these (like readAll) since I wouldn't 
normally expect a get method to have side effects, but I didn't want to just 
change the names of the most used methods. (x) {color:red}This method has been 
removed, the parser now works line by line.{color}

- Changed the getLineNumber method to return the correct line number when there 
are multi-line values.

- Moved all of the lexer methods into an inner CsvLexer class that is 
completely independent of the CsvParser class. The methods were already 
separated out, so it wasn't a very big change. I also moved the lexer test 
cases into a new CsvLexerTest class. (/) {color:green}DONE{color}

- Got rid of the interpreting unicode escape options. This doesn't really have 
anything to do with parsing a CSV file so I think it should be left up to the 
user of the class to implement this if needed. As an example, I made a 
CsvParserUnicodeEscapeTest class that uses the code from the lexer in a Reader 
subclass. One nice thing is that with this implementation, the interpreted 
values can be used as the delimiter, encapsulator, etc. (/) {color:green}DONE - 
The unicode unescaping is now handled by a class implementing java.io.Reader 
(to be contributed to Commons IO).{color}

- Got rid of the escape option for the same reason as the unicode escape 
option. I replaced it with an encapsulator escape option that is only used as 
an escape operator on the encapsulator character.

h3. ExtendedBufferedReader

- Greatly simplified this class. I removed all the methods that weren't being 
used (including keeping track of the line number) and changed the lookahead 
option to use the BufferedReader mark and reset methods.


h3. CsvStrategy

- I split this class into three classes: an abstract base class (CsvStrategy), 
a parser-specific version (CsvParseStrategy) and a printer-specific version 
(CsvPrintStrategy). I didn't like that the strategy was used for both parsing 
and printing even though some of the values only applied to parsing (and there 
could be values that apply only to printing as well). (x) {color:red}There 
aren't enough properties in CSVFormat to split the class{color}

- Made this class immutable (as described in SANDBOX-279) (/) 
{color:green}DONE{color}

- Changed the whitespace options to not ignore whitespace by default. This is 
what the document at http://www.rfc-editor.org/rfc/rfc4180.txt recommends for 
the CSV format, so I think it should be like that by default. I added an 
IGNORE_WHITESPACE_STRATEGY field that works the same as the old defaults. (/)

[jira] [Updated] (COLLECTIONS-398) BoundedFifoBuffer could be simplified by keeping a count of the number of entries


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

Sebb updated COLLECTIONS-398:
-

Attachment: COLLECTIONS-398-2.patch

Better patch - no need to check for null element in remove()

 BoundedFifoBuffer could be simplified by keeping a count of the number of 
 entries
 -

 Key: COLLECTIONS-398
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-398
 Project: Commons Collections
  Issue Type: Improvement
Reporter: Sebb
 Attachments: COLLECTIONS-398-2.patch, COLLECTIONS-398.patch


 BoundedFifoBuffer could be much simplified by keeping a count of the number 
 of entries, and dropping the boolean full.
 This would speed up size() and isEmpty() and isFull().

--
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] (SANDBOX-408) CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe


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

Sebb updated SANDBOX-408:
-

Attachment: (was: COLLECTIONS-398-2.patch)

 CSVFormat describes itself as immutable, but it is not - in particular it is 
 not thread-safe
 

 Key: SANDBOX-408
 URL: https://issues.apache.org/jira/browse/SANDBOX-408
 Project: Commons Sandbox
  Issue Type: Bug
  Components: CSV
Reporter: Sebb
 Attachments: CSVFormat.java


 CSVFormat describes itself as immutable, but it is not @Immutable - the class 
 fields are all mutable.
 The methods that change the fields do so by creating a clone, and returning 
 the changed clone.
 So in a sense the class is immutable.
 However, the normal expectation is that @Immutable classes are @ThreadSafe.
 CSVFormat is not thread-safe, because the fields are not volatile, and the 
 fields are not written  read using a common lock.
 The comment needs to be clarified or removed.

--
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] (SANDBOX-408) CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe


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

Sebb updated SANDBOX-408:
-

Comment: was deleted

(was: Another simplification; no need to check for null element.)

 CSVFormat describes itself as immutable, but it is not - in particular it is 
 not thread-safe
 

 Key: SANDBOX-408
 URL: https://issues.apache.org/jira/browse/SANDBOX-408
 Project: Commons Sandbox
  Issue Type: Bug
  Components: CSV
Reporter: Sebb
 Attachments: CSVFormat.java


 CSVFormat describes itself as immutable, but it is not @Immutable - the class 
 fields are all mutable.
 The methods that change the fields do so by creating a clone, and returning 
 the changed clone.
 So in a sense the class is immutable.
 However, the normal expectation is that @Immutable classes are @ThreadSafe.
 CSVFormat is not thread-safe, because the fields are not volatile, and the 
 fields are not written  read using a common lock.
 The comment needs to be clarified or removed.

--
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] (SANDBOX-408) CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe


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

Sebb updated SANDBOX-408:
-

Attachment: COLLECTIONS-398-2.patch

Another simplification; no need to check for null element.

 CSVFormat describes itself as immutable, but it is not - in particular it is 
 not thread-safe
 

 Key: SANDBOX-408
 URL: https://issues.apache.org/jira/browse/SANDBOX-408
 Project: Commons Sandbox
  Issue Type: Bug
  Components: CSV
Reporter: Sebb
 Attachments: CSVFormat.java


 CSVFormat describes itself as immutable, but it is not @Immutable - the class 
 fields are all mutable.
 The methods that change the fields do so by creating a clone, and returning 
 the changed clone.
 So in a sense the class is immutable.
 However, the normal expectation is that @Immutable classes are @ThreadSafe.
 CSVFormat is not thread-safe, because the fields are not volatile, and the 
 fields are not written  read using a common lock.
 The comment needs to be clarified or removed.

--
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] (CODEC-63) Implement NYSIIS

2012-03-07 Thread Gary D. Gregory (Updated) (JIRA)


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

Gary D. Gregory updated CODEC-63:
-

Summary: Implement NYSIIS  (was: Implement Nysiis)

 Implement NYSIIS
 

 Key: CODEC-63
 URL: https://issues.apache.org/jira/browse/CODEC-63
 Project: Commons Codec
  Issue Type: New Feature
Affects Versions: 1.x
Reporter: Henri Yandell
 Fix For: 1.x

 Attachments: CODEC-63-reworked.tar, Nysiis.patch


 http://en.wikipedia.org/wiki/NYSIIS

--
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] (COLLECTIONS-397) BoundedFifoBuffer could allow null entries

2012-03-07 Thread Leandro Ariel Pezzente (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224885#comment-13224885
 ] 

Sebb commented on COLLECTIONS-397:
--

If COLLECTIONS-398-2.patch is applied (see COLLECTIONS-398) then the underlying 
code will support nulls.

The null check in add() would obviously have to be disabled to allow null 
entries.

Two possible approaches:
- remove the restriction that nulls are not allowed; this would be a change in 
behaviour so might not be acceptable
- add new ctors with a boolean parameter to specify whether nulls are allowed.

 BoundedFifoBuffer could allow null entries
 --

 Key: COLLECTIONS-397
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-397
 Project: Commons Collections
  Issue Type: Improvement
Reporter: Sebb

 BoundedFifoBuffer could easily allow null entries - it uses an array for 
 storage.
 Is there any reason why nulls should not be (optionally) allowed?
 This would mean changing the remove() implementation.

--
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-765) Refactoring the vector and matrix classes


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

Leandro Ariel Pezzente commented on MATH-765:
-

Gilles , do you know if MIT License is compatibles with APL 2.0 ?

 Refactoring the vector and matrix classes
 -

 Key: MATH-765
 URL: https://issues.apache.org/jira/browse/MATH-765
 Project: Commons Math
  Issue Type: Improvement
Affects Versions: 4.0
Reporter: Sébastien Brisard
  Labels: api-change, linear

 {panel:title=Warning|borderStyle=solid}
 This is not a bug report, but rather a summary of all discussions which have 
 taken place on the mailing list regarding the refactoring of the vector and 
 matrix classes. Indeed, it has been argued many times that the {{RealVector}} 
 and {{RealMatrix}} interfaces are really cluttered, and could benefit from 
 other approaches (like functional programming). 
 The description of this ticket will be updated as the discussion progresses 
 on the mailing-list, and new JIRA tickets will be created to carry out the 
 real work. In order to keep this ticket tidy, contributors should refrain 
 from commenting on this website. Instead, messages should be posted on the 
 dev mailing-list.
 {panel}
 h1. The current API (version 3.0)
 In this section, the current interfaces for vectors and matrices are 
 compared. Vectors and matrices are two mathematical objects which are very 
 close in nature. Their implementations should therefore be as similar as 
 possible. The methods will be sorted as follows
 * methods reflecting the mathematical structure of vector space: addition, 
 multiplication by a scalar, matrix-vector product, ...
 * methods reflecting the mathematical structure of euclidean space
 * ...
 h2. Methods reflecting the mathematical structure of vector space
 || {{RealVector}}  || {{RealMatrix}}  
  || Comments ||
 | {{RealVector add(RealVector v)}} | {{RealMatrix add(RealMatrix m)}} 
  |   |
 | {{int getDimension()}}   | {{int getRowDimension()}},\\ {{int 
 getColumnDimension()}} |   |
 | {{RealVector mapMultiply(double d)}} | {{scalarMultiply(double d)}} 
  |   |
 |  | {{multiply(RealMatrix m)}}   
  |   |
 |  | {{double[] operate(double[])}}   
  |   |
 |  | {{RealVector operate(RealVector)}}   
  |   |
 |  | {{double[] preMultiply(double[])}}   
  |   |
 |  | {{RealMatrix 
 preMultiply(RealMatrix)}}|   |
 |  | {{RealVector 
 preMultiply(RealVector)}}|   |
 h2. Methods reflecting the mathematical structure of euclidean space

--
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] [Created] (COLLECTIONS-399) Add indexed get to BoundedFifoBuffer / CircularFifoBuffer

Add indexed get to BoundedFifoBuffer / CircularFifoBuffer
-

 Key: COLLECTIONS-399
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-399
 Project: Commons Collections
  Issue Type: New Feature
Reporter: Sebb


Since the BoundedFifoBuffer is implemented as an array, it should be simple to 
implement random access to any element of the buffer.

[This functionality was requested on the Commons user list]

For example:

// get nth entry; i.e. get(0) is the same as get()
// NoSuchElementException if i = numEntries
// if i  0, could either throw an Exception or treat as reverse index from end 
of buffer
E get(int i)

This would also work for the sub-class CircularFifoBuffer.

--
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] (CODEC-63) Implement NYSIIS

2012-03-07 Thread Gary D. Gregory (Commented) (JIRA)

[
https://issues.apache.org/jira/browse/CODEC-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224932#comment-13224932
]

Gary D. Gregory commented on CODEC-63:
--

Hi Thomas,

Thank you for providing the refreshed patch. Can you do a little more digging
on this one please (see below)?

Please find attached my version which adds more tests, some failing that are
commented out. I also added a boolean to do 'true' Nysiis which always
truncates to length 6.

This needs more work to figure out why the tests fail.

I used the data here: http://www.dropby.com/NYSIISTextStrings.html

Note the 'Original' and 'Modified' columns.

Our code sometimes matches one column, sometimes the other.

I imagine that by no means is the dropby data is canonical but we should
document clearly in the tests and in the code what is what.

Right now, I do not know if our implementation is correct or buggy for the
commented out tests.

Granted I've not spent much time on this.

The unit tests do not get 100% code coverage either, which should be a goal for
a new codec. 100% coverage does not guarantee correct implementation of course,
but it's a start to make sure we at least test what we have.

At least, the new tests brought the coverage from 98%/93% line/branch to
100%/94%, so we've got that going for us ;)

Gary

Implement NYSIIS

Key: CODEC-63
URL: https://issues.apache.org/jira/browse/CODEC-63
Project: Commons Codec
Issue Type: New Feature
Affects Versions: 1.x
Reporter: Henri Yandell
Fix For: 1.x

Attachments: CODEC-63-reworked.tar, Nysiis.patch

http://en.wikipedia.org/wiki/NYSIIS

[jira] [Updated] (CODEC-63) Implement NYSIIS

2012-03-07 Thread Gary D. Gregory (Updated) (JIRA)


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

Gary D. Gregory updated CODEC-63:
-

Attachment: codec-63-nysiis-ggregory.diff

Takes the previous patches, adds tests to improve code coverage and show issues 
(bugs or not). Also adds trueLength (6) boolean.

 Implement NYSIIS
 

 Key: CODEC-63
 URL: https://issues.apache.org/jira/browse/CODEC-63
 Project: Commons Codec
  Issue Type: New Feature
Affects Versions: 1.x
Reporter: Henri Yandell
 Fix For: 1.x

 Attachments: CODEC-63-reworked.tar, Nysiis.patch, 
 codec-63-nysiis-ggregory.diff


 http://en.wikipedia.org/wiki/NYSIIS

--
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] (COLLECTIONS-285) TreeBidiMap should implement Serializable


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224934#comment-13224934
 ] 

Sebb commented on COLLECTIONS-285:
--

This patch only adds transient markers to the main class fields.

What about the nested classes?
Some of those have fields - should they be serialised or not?

 TreeBidiMap should implement Serializable
 -

 Key: COLLECTIONS-285
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-285
 Project: Commons Collections
  Issue Type: Improvement
  Components: BidiMap
Affects Versions: 3.2
Reporter: Geert Pante
 Fix For: 4.0-beta-1

 Attachments: COLLECTIONS-285.patch, COLLECTIONS_285.diff


 TreeBidiMap does not implement Serializable. DualTreeBidiMap does.
 It's just a matter of checking which fields should be transient and done.
 In fact, all Maps should be Serializable.

--
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] (COLLECTIONS-183) [collections] Supplement collections with contribution

2012-03-07 Thread Sebb (Resolved) (JIRA)


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

Sebb resolved COLLECTIONS-183.
--

Resolution: Won't Fix

Link to proposed code no longer works

 [collections] Supplement collections with contribution
 --

 Key: COLLECTIONS-183
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-183
 Project: Commons Collections
  Issue Type: Improvement
 Environment: Operating System: other
 Platform: Other
Reporter: loney
Priority: Minor

 Contribute a supplement to Collections as explained below.
 On Mon, 2005-03-21 at 14:56, Stephen Colebourne wrote:
  I've only had a quick glance so far, but there looks like some interesting 
  stuff. It will take me a little while to understand and act on any of it. 
  If 
  nothing happens, PLEASE re-promt the list!
  
  Alternatively, raise a bugzilla call to point at your URL.
  
  Also, I'm musing over how to enable [collections] to be a little more 
  flexible in what it accepts at the moment.
  
  Stephen
  
  
  - Original Message - 
  From: Fred Loney lo...@spiritedsw.com
  I would like to contribute a supplement to Collections developed over
   the past couple of years. The supplement is available at:
  
   http://www.spiritedsw.com/collections/index.html
  
   If there is interest, I will change the copyright and submit these to
   Jakarta.
  
   Each class has a robust test case and is well-documented. I would
   exclude the proxy package; the proxy package is a useful complement to
   Collections, but does not belong in Collections proper.
  
   The contribution is more substantial than a conventional patch, so I'm
   not sure of the preferred submission mechanism.
  
   Please let me know if you find this supplement useful or have any
   questions.

--
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] [Created] (LANG-792) ToStringStyle registry may retain entries between invocations - is this a problem?