[jira] [Updated] (NET-418) File truncated when transfer on ftp
[ https://issues.apache.org/jira/browse/NET-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] PARENT JP updated NET-418: -- Attachment: notices.txt Original file for ftp transfer File truncated when transfer on ftp --- Key: NET-418 URL: https://issues.apache.org/jira/browse/NET-418 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.0.1 Environment: Transfer from Windows server 2008 R2 64 bits to Linux Centos 5.5 x86 64 bits Pro FTPD A31 Reporter: PARENT JP Attachments: notices.txt File after transfer is truncated. Original file has a size of 17 172 261 bytes and file after transfer 17 170 762 bytes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-418) File truncated when transfer on ftp
[ https://issues.apache.org/jira/browse/NET-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] PARENT JP updated NET-418: -- Attachment: notices_total.zip Previous file was not the good one File truncated when transfer on ftp --- Key: NET-418 URL: https://issues.apache.org/jira/browse/NET-418 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.0.1 Environment: Transfer from Windows server 2008 R2 64 bits to Linux Centos 5.5 x86 64 bits Pro FTPD A31 Reporter: PARENT JP Attachments: notices.txt, notices_total.zip File after transfer is truncated. Original file has a size of 17 172 261 bytes and file after transfer 17 170 762 bytes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-418) File truncated when transfer on ftp
[ https://issues.apache.org/jira/browse/NET-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079294#comment-13079294 ] PARENT JP commented on NET-418: --- notices.txt has also the same problem, original size 148 232 bytes and after transfer file has a size of 148 228 bytes File truncated when transfer on ftp --- Key: NET-418 URL: https://issues.apache.org/jira/browse/NET-418 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.0.1 Environment: Transfer from Windows server 2008 R2 64 bits to Linux Centos 5.5 x86 64 bits Pro FTPD A31 Reporter: PARENT JP Attachments: notices.txt, notices_total.zip File after transfer is truncated. Original file has a size of 17 172 261 bytes and file after transfer 17 170 762 bytes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (BEANUTILS-397) NumberConverter is limited to Long when converting Date/Calendar to Number
NumberConverter is limited to Long when converting Date/Calendar to Number -- Key: BEANUTILS-397 URL: https://issues.apache.org/jira/browse/BEANUTILS-397 Project: Commons BeanUtils Issue Type: Improvement Components: ConvertUtils Converters Affects Versions: 1.8.3 Reporter: Oliver Sauder Priority: Minor Fix For: 1.8.4 NumberConverter is limited to Long when converting Date/Calendar to Number. However it would be desirable when the conversion would work to BigDecimal and BigInteger as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (BEANUTILS-397) NumberConverter is limited to Long when converting Date/Calendar to Number
[ https://issues.apache.org/jira/browse/BEANUTILS-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Sauder updated BEANUTILS-397: Attachment: numberconverter-datecalendar-to-bigdecimalbiginteger.patch Patch against trunk adding Date/Calendar to BigDecimal/BigInteger support NumberConverter is limited to Long when converting Date/Calendar to Number -- Key: BEANUTILS-397 URL: https://issues.apache.org/jira/browse/BEANUTILS-397 Project: Commons BeanUtils Issue Type: Improvement Components: ConvertUtils Converters Affects Versions: 1.8.3 Reporter: Oliver Sauder Priority: Minor Fix For: 1.8.4 Attachments: numberconverter-datecalendar-to-bigdecimalbiginteger.patch NumberConverter is limited to Long when converting Date/Calendar to Number. However it would be desirable when the conversion would work to BigDecimal and BigInteger as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COMPRESS-149) Support reading of ZIP64 files in ZipFile
[ https://issues.apache.org/jira/browse/COMPRESS-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved COMPRESS-149. - Resolution: Fixed should work with svn revision 1153850 Support reading of ZIP64 files in ZipFile - Key: COMPRESS-149 URL: https://issues.apache.org/jira/browse/COMPRESS-149 Project: Commons Compress Issue Type: Sub-task Components: Archivers Reporter: Stefan Bodewig Assignee: Stefan Bodewig Fix For: 1.3 Will need support for reading the new central directory structure as well as everything that ZipArchiveInputStream does. It may turn out that parsing of zip extra fields needs to be special cased for the Zip64 field as the CD data cannot be reliably parsed from the raw bytes without knowing which fields in the CD have been set to 0x. Given that the zip64 extra field is a very special one for the format, this may just be OK. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-36) Add Zip64 Suport
[ https://issues.apache.org/jira/browse/COMPRESS-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079332#comment-13079332 ] Stefan Bodewig commented on COMPRESS-36: Status update: ZipArchiveInputStream and ZipFile seem to be complete now ZipArchiveOutputStream works transparently except for the single case when a DEFLATED entry of unknown size gets written to a non-seekable stream. This one cannot work transparently and it will be pretty easy to implenent once we have decided at which granularity and with which defaults the user code will have to ask for ZIP64 features to be enabled, Add Zip64 Suport Key: COMPRESS-36 URL: https://issues.apache.org/jira/browse/COMPRESS-36 Project: Commons Compress Issue Type: New Feature Components: Archivers Reporter: Christian Grobmeier Assignee: Stefan Bodewig Fix For: 1.3 Attachments: 5GB_of_Zeros.zip, 5GB_of_Zeros_7ZIP.zip, 5GB_of_Zeros_WindowsCompressedFolders.zip, 5GB_of_Zeros_jar.zip, zip64-sample.zip Add Zip64 support. This will make it work to deal with zipfiles 2 GB. Planned for compress 1.1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-125) Implement a Beider-Morse phonetic matching codec
[ https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079427#comment-13079427 ] Gary D. Gregory commented on CODEC-125: --- Any chance of getting more tests? Matthew? Tamas? Implement a Beider-Morse phonetic matching codec Key: CODEC-125 URL: https://issues.apache.org/jira/browse/CODEC-125 Project: Commons Codec Issue Type: New Feature Reporter: Matthew Pocock Priority: Minor Attachments: acz.patch, bm-gg.diff, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, majorFix.patch, testEncodeGna.patch I have implemented Beider Morse Phonetic Matching as a codec against the commons-codec svn trunk. I would like to contribute this to commons-codec. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (IO-226) question with byteCountToDisplaySize(long size)
[ https://issues.apache.org/jira/browse/IO-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079442#comment-13079442 ] Yury Kats edited comment on IO-226 at 8/4/11 4:18 PM: -- What is the reason for rounding down? bq. it would have to display the value 2047 as 1.9990234375KB which is not very readable. This can easily be turned into 1.9 (or 1.99), which is readable and way more accurate. Because of the current behaviour, any project I've been on ends up writing its own byteCountToDisplaySize method and not using FileUtils. Who needs a method that returns 1 GB for a 1.99GB file? was (Author: ykats): What is the reason for rounding down? .bq. it would have to display the value 2047 as 1.9990234375KB which is not very readable. This can easily be turned into 1.9 (or 1.99), which is readable and way more accurate. Because of the current behaviour, any project I've been on ends up writing its own byteCountToDisplaySize method and not using FileUtils. Who needs a method that returns 1 GB for a 1.99GB file? question with byteCountToDisplaySize(long size) --- Key: IO-226 URL: https://issues.apache.org/jira/browse/IO-226 Project: Commons IO Issue Type: Improvement Components: Utilities Reporter: shu kai yuan Fix For: 2.0 I do not understand the byteCountToDisplaySize(long size) method which is in class FileUtils of the package org.apache.commons.io. If the parameter size is 2047 , the method will return 1 KB.Why it will lose precision. I read the code. Maybe it is a bug? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-226) question with byteCountToDisplaySize(long size)
[ https://issues.apache.org/jira/browse/IO-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079442#comment-13079442 ] Yury Kats commented on IO-226: -- What is the reason for rounding down? .bq. it would have to display the value 2047 as 1.9990234375KB which is not very readable. This can easily be turned into 1.9 (or 1.99), which is readable and way more accurate. Because of the current behaviour, any project I've been on ends up writing its own byteCountToDisplaySize method and not using FileUtils. Who needs a method that returns 1 GB for a 1.99GB file? question with byteCountToDisplaySize(long size) --- Key: IO-226 URL: https://issues.apache.org/jira/browse/IO-226 Project: Commons IO Issue Type: Improvement Components: Utilities Reporter: shu kai yuan Fix For: 2.0 I do not understand the byteCountToDisplaySize(long size) method which is in class FileUtils of the package org.apache.commons.io. If the parameter size is 2047 , the method will return 1 KB.Why it will lose precision. I read the code. Maybe it is a bug? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-226) question with byteCountToDisplaySize(long size)
[ https://issues.apache.org/jira/browse/IO-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079453#comment-13079453 ] Mark Miller commented on IO-226: bq. Who needs a method that returns 1 GB for a 1.99GB file? +1 - I'm sure everyone just re-implements this method. I have done it and seen it done. question with byteCountToDisplaySize(long size) --- Key: IO-226 URL: https://issues.apache.org/jira/browse/IO-226 Project: Commons IO Issue Type: Improvement Components: Utilities Reporter: shu kai yuan Fix For: 2.0 I do not understand the byteCountToDisplaySize(long size) method which is in class FileUtils of the package org.apache.commons.io. If the parameter size is 2047 , the method will return 1 KB.Why it will lose precision. I read the code. Maybe it is a bug? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-125) Implement a Beider-Morse phonetic matching codec
[ https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079457#comment-13079457 ] Tamas Kende commented on CODEC-125: --- Gary: I would like to, but I am busy now. I will try to create more tests this weekend. Implement a Beider-Morse phonetic matching codec Key: CODEC-125 URL: https://issues.apache.org/jira/browse/CODEC-125 Project: Commons Codec Issue Type: New Feature Reporter: Matthew Pocock Priority: Minor Attachments: acz.patch, bm-gg.diff, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, majorFix.patch, testEncodeGna.patch I have implemented Beider Morse Phonetic Matching as a codec against the commons-codec svn trunk. I would like to contribute this to commons-codec. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-226) question with byteCountToDisplaySize(long size)
[ https://issues.apache.org/jira/browse/IO-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079502#comment-13079502 ] Gary D. Gregory commented on IO-226: +1 here too. Would using 2 digit precision all the time be better? question with byteCountToDisplaySize(long size) --- Key: IO-226 URL: https://issues.apache.org/jira/browse/IO-226 Project: Commons IO Issue Type: Improvement Components: Utilities Reporter: shu kai yuan Fix For: 2.0 I do not understand the byteCountToDisplaySize(long size) method which is in class FileUtils of the package org.apache.commons.io. If the parameter size is 2047 , the method will return 1 KB.Why it will lose precision. I read the code. Maybe it is a bug? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-581) Support for iterative linear solvers
[ https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Brisard updated MATH-581: --- Attachment: (was: MATH-581-06.zip) Support for iterative linear solvers Key: MATH-581 URL: https://issues.apache.org/jira/browse/MATH-581 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0, Nightly Builds Reporter: Sébastien Brisard Labels: iterative, linear, solver Attachments: MATH-581-01.patch, MATH-581-02.zip, MATH-581-03.zip, MATH-581-04.zip, MATH-581-05.patch, MATH-581-05.patch, linearoperator.zip Dear all, this issue has already been discussed on the forum. The idea is to implement the most popular linear iterative solvers (CG, SYMMLQ, etc...) in commons-math. The beauty of these solvers is that they do not need direct access to the coefficients of the matrix, only matrix-vector products are necessary. This is goof, as sometimes it is inetficient to store the coefficients of the matrix. So basically, before implementing the iterative solvers, we need to define an interface slightly more general than a matrix, namely LinearOperator, with only one basic operation: matrix-vector product. Here are a few interfaces and abstract classes that do that. Nothing fancy yet, I just wanted to have you advice on the implementation before I commit some solvers. I thought these classes could go in a package org.apache.commons.math.linearoperator, but really, I haven't got a clue... Best regards, Sebastien -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-581) Support for iterative linear solvers
[
https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079236#comment-13079236
]
Sébastien Brisard edited comment on MATH-581 at 8/4/11 6:09 PM:
Hi,
attached are some classes entering the heart of the matter.
* Abstract classes
** {{AbstractIterativeLinearSolver}}
** {{AbstractPreconditionedIterativeLinearSolver}}
** {{AbstractIterativeLinearSolverMonitor}}
* Concrete implementations
** {{ConjugateGradient}}
** {{JacobiPreconditioner}}
** {{StoppingCriterion2}} (the 2 comes from the name this stopping criterion
received in the templates)
* Unit tests
** {{ConjugateGradientTest}}
* Supporting classes for unit tests
** {{HilbertMatrix}}
** {{InverseHilbertMatrix}}
Hope you like it!
Sébastien
EDIT Removed the attachment, because discussions on the forum revealed that the
exceptions could be improved.
was (Author: celestin):
Hi,
attached are some classes entering the heart of the matter.
* Abstract classes
** {{AbstractIterativeLinearSolver}}
** {{AbstractPreconditionedIterativeLinearSolver}}
** {{AbstractIterativeLinearSolverMonitor}}
* Concrete implementations
** {{ConjugateGradient}}
** {{JacobiPreconditioner}}
** {{StoppingCriterion2}} (the 2 comes from the name this stopping criterion
received in the templates)
* Unit tests
** {{ConjugateGradientTest}}
* Supporting classes for unit tests
** {{HilbertMatrix}}
** {{InverseHilbertMatrix}}
Hope you like it!
Sébastien
Support for iterative linear solvers
Key: MATH-581
URL: https://issues.apache.org/jira/browse/MATH-581
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0, Nightly Builds
Reporter: Sébastien Brisard
Labels: iterative, linear, solver
Attachments: MATH-581-01.patch, MATH-581-02.zip, MATH-581-03.zip,
MATH-581-04.zip, MATH-581-05.patch, MATH-581-05.patch, linearoperator.zip
Dear all,
this issue has already been discussed on the forum. The idea is to implement
the most popular linear iterative solvers (CG, SYMMLQ, etc...) in
commons-math. The beauty of these solvers is that they do not need direct
access to the coefficients of the matrix, only matrix-vector products are
necessary. This is goof, as sometimes it is inetficient to store the
coefficients of the matrix.
So basically, before implementing the iterative solvers, we need to define an
interface slightly more general than a matrix, namely LinearOperator, with
only one basic operation: matrix-vector product.
Here are a few interfaces and abstract classes that do that. Nothing fancy
yet, I just wanted to have you advice on the implementation before I commit
some solvers.
I thought these classes could go in a package
org.apache.commons.math.linearoperator, but really, I haven't got a clue...
Best regards,
Sebastien
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-581) Support for iterative linear solvers
[
https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard updated MATH-581:
---
Attachment: exceptions.patch
{{exceptions.patch}} removes all getOffendinXXX methods. ExceptionContext will
be used instead
Support for iterative linear solvers
Key: MATH-581
URL: https://issues.apache.org/jira/browse/MATH-581
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0, Nightly Builds
Reporter: Sébastien Brisard
Labels: iterative, linear, solver
Attachments: MATH-581-01.patch, MATH-581-02.zip, MATH-581-03.zip,
MATH-581-04.zip, MATH-581-05.patch, MATH-581-05.patch, exceptions.patch,
linearoperator.zip
Dear all,
this issue has already been discussed on the forum. The idea is to implement
the most popular linear iterative solvers (CG, SYMMLQ, etc...) in
commons-math. The beauty of these solvers is that they do not need direct
access to the coefficients of the matrix, only matrix-vector products are
necessary. This is goof, as sometimes it is inetficient to store the
coefficients of the matrix.
So basically, before implementing the iterative solvers, we need to define an
interface slightly more general than a matrix, namely LinearOperator, with
only one basic operation: matrix-vector product.
Here are a few interfaces and abstract classes that do that. Nothing fancy
yet, I just wanted to have you advice on the implementation before I commit
some solvers.
I thought these classes could go in a package
org.apache.commons.math.linearoperator, but really, I haven't got a clue...
Best regards,
Sebastien
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-581) Support for iterative linear solvers
[ https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Brisard updated MATH-581: --- Attachment: (was: conjugate-gradient.zip) Support for iterative linear solvers Key: MATH-581 URL: https://issues.apache.org/jira/browse/MATH-581 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0, Nightly Builds Reporter: Sébastien Brisard Labels: iterative, linear, solver Attachments: MATH-581-01.patch, MATH-581-02.zip, MATH-581-03.zip, MATH-581-04.zip, MATH-581-05.patch, MATH-581-05.patch, exceptions.patch, linearoperator.zip Dear all, this issue has already been discussed on the forum. The idea is to implement the most popular linear iterative solvers (CG, SYMMLQ, etc...) in commons-math. The beauty of these solvers is that they do not need direct access to the coefficients of the matrix, only matrix-vector products are necessary. This is goof, as sometimes it is inetficient to store the coefficients of the matrix. So basically, before implementing the iterative solvers, we need to define an interface slightly more general than a matrix, namely LinearOperator, with only one basic operation: matrix-vector product. Here are a few interfaces and abstract classes that do that. Nothing fancy yet, I just wanted to have you advice on the implementation before I commit some solvers. I thought these classes could go in a package org.apache.commons.math.linearoperator, but really, I haven't got a clue... Best regards, Sebastien -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-581) Support for iterative linear solvers
[ https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Brisard updated MATH-581: --- Attachment: conjugate-gradient.zip This is a new attempt, with extensive use of ExceptionContext to handle errors. Support for iterative linear solvers Key: MATH-581 URL: https://issues.apache.org/jira/browse/MATH-581 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0, Nightly Builds Reporter: Sébastien Brisard Labels: iterative, linear, solver Attachments: MATH-581-01.patch, MATH-581-02.zip, MATH-581-03.zip, MATH-581-04.zip, MATH-581-05.patch, MATH-581-05.patch, exceptions.patch, linearoperator.zip Dear all, this issue has already been discussed on the forum. The idea is to implement the most popular linear iterative solvers (CG, SYMMLQ, etc...) in commons-math. The beauty of these solvers is that they do not need direct access to the coefficients of the matrix, only matrix-vector products are necessary. This is goof, as sometimes it is inetficient to store the coefficients of the matrix. So basically, before implementing the iterative solvers, we need to define an interface slightly more general than a matrix, namely LinearOperator, with only one basic operation: matrix-vector product. Here are a few interfaces and abstract classes that do that. Nothing fancy yet, I just wanted to have you advice on the implementation before I commit some solvers. I thought these classes could go in a package org.apache.commons.math.linearoperator, but really, I haven't got a clue... Best regards, Sebastien -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-581) Support for iterative linear solvers
[ https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Brisard updated MATH-581: --- Attachment: conjugate-gradient.zip conjugate-gradient.zip includes all above-mentioned classes, with correcte exceptions (with extensive use of ExceptionContext). Thanks for your comments! Support for iterative linear solvers Key: MATH-581 URL: https://issues.apache.org/jira/browse/MATH-581 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0, Nightly Builds Reporter: Sébastien Brisard Labels: iterative, linear, solver Attachments: MATH-581-01.patch, MATH-581-02.zip, MATH-581-03.zip, MATH-581-04.zip, MATH-581-05.patch, MATH-581-05.patch, conjugate-gradient.zip, exceptions.patch, linearoperator.zip Dear all, this issue has already been discussed on the forum. The idea is to implement the most popular linear iterative solvers (CG, SYMMLQ, etc...) in commons-math. The beauty of these solvers is that they do not need direct access to the coefficients of the matrix, only matrix-vector products are necessary. This is goof, as sometimes it is inetficient to store the coefficients of the matrix. So basically, before implementing the iterative solvers, we need to define an interface slightly more general than a matrix, namely LinearOperator, with only one basic operation: matrix-vector product. Here are a few interfaces and abstract classes that do that. Nothing fancy yet, I just wanted to have you advice on the implementation before I commit some solvers. I thought these classes could go in a package org.apache.commons.math.linearoperator, but really, I haven't got a clue... Best regards, Sebastien -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-581) Support for iterative linear solvers
[ https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Brisard updated MATH-581: --- Comment: was deleted (was: This is a new attempt, with extensive use of ExceptionContext to handle errors.) Support for iterative linear solvers Key: MATH-581 URL: https://issues.apache.org/jira/browse/MATH-581 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0, Nightly Builds Reporter: Sébastien Brisard Labels: iterative, linear, solver Attachments: MATH-581-01.patch, MATH-581-02.zip, MATH-581-03.zip, MATH-581-04.zip, MATH-581-05.patch, MATH-581-05.patch, conjugate-gradient.zip, exceptions.patch, linearoperator.zip Dear all, this issue has already been discussed on the forum. The idea is to implement the most popular linear iterative solvers (CG, SYMMLQ, etc...) in commons-math. The beauty of these solvers is that they do not need direct access to the coefficients of the matrix, only matrix-vector products are necessary. This is goof, as sometimes it is inetficient to store the coefficients of the matrix. So basically, before implementing the iterative solvers, we need to define an interface slightly more general than a matrix, namely LinearOperator, with only one basic operation: matrix-vector product. Here are a few interfaces and abstract classes that do that. Nothing fancy yet, I just wanted to have you advice on the implementation before I commit some solvers. I thought these classes could go in a package org.apache.commons.math.linearoperator, but really, I haven't got a clue... Best regards, Sebastien -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CONFIGURATION-456) AbstractConfiguration.getKeys(String prefix) docs doesn't say about the point ('.')
[
https://issues.apache.org/jira/browse/CONFIGURATION-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-456.
Resolution: Fixed
Fix Version/s: 1.7
Thanks for the report, the documentation was indeed not exact. I tried to
improve it by giving concrete examples. The fix is availabe in subversion in
revision 1153992.
AbstractConfiguration.getKeys(String prefix) docs doesn't say about the point
('.')
---
Key: CONFIGURATION-456
URL: https://issues.apache.org/jira/browse/CONFIGURATION-456
Project: Commons Configuration
Issue Type: Bug
Components: Documentation
Affects Versions: 1.6
Reporter: Mirco Andreon
Priority: Trivial
Fix For: 1.7
Original Estimate: 10m
Remaining Estimate: 10m
For the method
org.apache.commons.configuration.AbstractConfiguration.getKeys(String prefix)
the documentation doesn't say that to the prefix will be added a point
character ('.') to filter the keys list
(http://commons.apache.org/configuration/apidocs/org/apache/commons/configuration/AbstractConfiguration.html#getKeys%28java.lang.String%29).
I discovered it only reading the source.
Maybe I should have known this behaviour, but I think a lot of occasional
users could face this unpredictable behaviour. Specifying this would be very
helpfull.
Many thanks for your wonderful libraries!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CONFIGURATION-452) HierarchicalConfiguration with XPathExpressionEngine does not work when setting a new property
[
https://issues.apache.org/jira/browse/CONFIGURATION-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-452.
Resolution: Fixed
Fix Version/s: 1.7
Marking this issue as fixed because the reported problem should be solved. Feel
free to reopen - or create a new issue - if you encounter further problems.
HierarchicalConfiguration with XPathExpressionEngine does not work when
setting a new property
--
Key: CONFIGURATION-452
URL: https://issues.apache.org/jira/browse/CONFIGURATION-452
Project: Commons Configuration
Issue Type: Bug
Components: Expression engine
Affects Versions: 1.6
Environment: all
Reporter: Fabien Nisol
Assignee: Oliver Heger
Fix For: 1.7
The following code does not work as expected
{code:title=Bug.java|borderStyle=solid}
public class Bug {
public static void main(String[] args) {
try {
XMLConfiguration config = new XMLConfiguration();
// works
config.setProperty(test.property[@attribute],
value);
config.setExpressionEngine(new XPathExpressionEngine());
config.save(System.out);
// works
config.setProperty(test/property/@attribute, value);
// does not work
config.setProperty(test/property/@attribute2,
value);
} catch (ConfigurationException e) {
// @FIXME Traitement d'exception par defaut
throw new RuntimeException(e);
}
}
}
{code}
hangs with the following exception:
Exception in thread main java.lang.IllegalArgumentException: prepareAdd:
Passed in key must contain a whitespace!
at
org.apache.commons.configuration.tree.xpath.XPathExpressionEngine.prepareAdd(XPathExpressionEngine.java:223)
at
org.apache.commons.configuration.HierarchicalConfiguration.addPropertyDirect(HierarchicalConfiguration.java:371)
at
org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.addPropertyDirect(AbstractHierarchicalFileConfiguration.java:140)
at
org.apache.commons.configuration.HierarchicalConfiguration.setProperty(HierarchicalConfiguration.java:749)
at
org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.setProperty(AbstractHierarchicalFileConfiguration.java:158)
at Bug.main(Bug.java:29)
the setProperty() method does not work if the property have to be added. This
behavior is not really wanted, because in some generic cases, we don't know
if the property is set or not before trying to set it.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CONFIGURATION-440) setProperty in XmlConfiguration escapes backslashes
[
https://issues.apache.org/jira/browse/CONFIGURATION-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-440.
Resolution: Duplicate
Fix Version/s: 1.7
Got nor more feedback, so I assume this is actually a duplicate of
CONFIGURATION-428.
setProperty in XmlConfiguration escapes backslashes
---
Key: CONFIGURATION-440
URL: https://issues.apache.org/jira/browse/CONFIGURATION-440
Project: Commons Configuration
Issue Type: Bug
Components: Build
Affects Versions: 1.6
Environment: Windows 7
Reporter: B
Labels: build
Fix For: 1.7, 2.0
When setPropery sets a new value that has backslashes (like path),
backslashes are escaped. When that value is loaded again, all backslashes are
duplicated.
Following test keeps failing. Don't know if there is some kind of formatting.
public class XmlConfigurationTest {
private static final String XML_CONFIGURATION_PATH =
resources/xml/config.xml;
private static final String PATH1 = c:\\temp\\path\\file.txt;
private static final String PATH2 = c:\\temp1\\path1\\file1.txt;
private static final String PATH3 = c:\\temp2\\path2\\file2.txt;
@Test
public void testXmlConfiguration() throws IOException {
File resourceFile = null;
try {
assertNotNull(_bundleContext);
resourceFile = new File(SystemUtils.getTargetDirectory(),
XML_CONFIGURATION_PATH);
assertTrue(resourceFile.getParentFile().mkdirs());
String value = null;
XMLConfiguration configuration = new XMLConfiguration();
configuration.setExpressionEngine(new XPathExpressionEngine());
configuration.setDelimiterParsingDisabled(true);
configuration.addProperty( key1, PATH1);
configuration.setProperty( key2, PATH2);
configuration.save(resourceFile);
/* All values are saved with non escaped backslashes */
value = configuration.getString(key1);
assertEquals(value, PATH1);
value = configuration.getString(key2);
assertEquals(value, PATH2);
/*
* Set again same property with different value. Setting property
* with this configuration will escape backslashes. Even though
* assert will pass, path with escaped backslashes will be written
* in a file (don't know if it is setProperty or save that is
causing troubles).
*/
configuration.setProperty( key2, PATH3);
configuration.save(resourceFile);
value = configuration.getString(key2);
assertEquals(value, PATH3);
/*
* Create new configuration and load values from previously saved
* file.
*/
XMLConfiguration newConfiguration = new XMLConfiguration();
newConfiguration.setExpressionEngine(new XPathExpressionEngine());
newConfiguration.setDelimiterParsingDisabled(true);
newConfiguration.load(resourceFile);
/*
* At this point, configuration will load escaped backslashes, and
* the test will fail.
*/
value = newConfiguration.getString(key2);
assertEquals(value, PATH3);
} catch (Throwable e) {
e.printStackTrace();
fail(e.getLocalizedMessage());
} finally {
/*
* Delete resource file
*/
resourceFile.delete();
}
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONFIGURATION-431) Code caused NullPointer error in XMLConfiguration
[
https://issues.apache.org/jira/browse/CONFIGURATION-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger updated CONFIGURATION-431:
---
Priority: Major (was: Critical)
Fix Version/s: 2.0
Setting fix version to 2.0 because a fix would probably break binary
compatibility.
Code caused NullPointer error in XMLConfiguration
-
Key: CONFIGURATION-431
URL: https://issues.apache.org/jira/browse/CONFIGURATION-431
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.6
Reporter: gentboy
Fix For: 2.0
In class XMLConfiguration there is a code structure like below:
public static void main(String[] args) {
new B();
}
static abstract class A {
A(){
print();
}
abstract void print();
}
static class B extends A{
String s = new String(asdf);
B(){
super();
}
void print(){
System.out.println(s);
}
}
While in B.print the field s is actually not initialized because it is called
from the super() method.
In XMLConfiguration the not properly initialized field is registeredEntities,
which will defenitly cause nullpointer in some case.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-442) SubsetConfiguration does not properly list attributes when a delimiter is set
[
https://issues.apache.org/jira/browse/CONFIGURATION-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079568#comment-13079568
]
Oliver Heger commented on CONFIGURATION-442:
Does the suggested workaround solve your problem? Then I would close this issue.
SubsetConfiguration does not properly list attributes when a delimiter is set
-
Key: CONFIGURATION-442
URL: https://issues.apache.org/jira/browse/CONFIGURATION-442
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.6
Environment: all
Reporter: Fabien Nisol
imagine a XmlConfiguration like this:
{code}
properties
prop1
prop2
prop
attr1=attr1
attr2=attr2/
/prop2
/prop1
/properties
{code}
If subset get instanciated to the end of the hierarchy, with a specific
delimiter, getKeys() won't return the correct keys:
{code}
...
XMLConfiguration config = new XMLConfiguration(test/test.xml);
Configuration subset = new SubsetConfiguration(config,prop1.prop2.prop,.);
ConfigurationUtils.dump(subset, System.err);
...
{code}
gives the result:
{code}
@attr1]=null
@attr2]=null
{code}
it should give the result
{code}
[@attr1]=attr1
[@attr2]=attr2
{code}
The wrong dump is a side effect of the wrong implementation of the
_getChildKey_ method of SubsetConfiguration
{code}
/**
* Return the key in the subset configuration associated to the specified
* key in the parent configuration.
*
* @param key The key in the parent configuration.
* @return the key in the context of this subset configuration
*/
protected String getChildKey(String key)
{
if (!key.startsWith(prefix))
{
throw new IllegalArgumentException(The parent key ' + key + '
is not in the subset.);
}
else
{
String modifiedKey = null;
if (key.length() == prefix.length())
{
modifiedKey = ;
}
else
{
int i = prefix.length() + (delimiter != null ?
delimiter.length() : 0);
modifiedKey = key.substring(i);
}
return modifiedKey;
}
}
{code}
In this code, the _else_ part is wrong. In a hierarchical configuration, the
attribute delimiter is '[' and is removed here.
I think a more correct code would be :
{code}
/**
* Return the key in the subset configuration associated to the specified
* key in the parent configuration.
*
* @param key The key in the parent configuration.
* @return the key in the context of this subset configuration
*/
protected String getChildKey(String key)
{
if (!key.startsWith(prefix))
{
throw new IllegalArgumentException(The parent key ' + key + '
is not in the subset.);
}
else
{
String modifiedKey = null;
if (key.length() == prefix.length())
{
modifiedKey = ;
}
else
{
modifiedKey = key.substring(prefix.length());
if(delimiter!=null modifiedKey.startsWith(delimiter))
{
modifiedKey=modifiedKey.substring(delimiter.length());
}
}
return modifiedKey;
}
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-442) SubsetConfiguration does not properly list attributes when a delimiter is set
[
https://issues.apache.org/jira/browse/CONFIGURATION-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079572#comment-13079572
]
Fabien Nisol commented on CONFIGURATION-442:
It does ! Thanks :)
SubsetConfiguration does not properly list attributes when a delimiter is set
-
Key: CONFIGURATION-442
URL: https://issues.apache.org/jira/browse/CONFIGURATION-442
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.6
Environment: all
Reporter: Fabien Nisol
imagine a XmlConfiguration like this:
{code}
properties
prop1
prop2
prop
attr1=attr1
attr2=attr2/
/prop2
/prop1
/properties
{code}
If subset get instanciated to the end of the hierarchy, with a specific
delimiter, getKeys() won't return the correct keys:
{code}
...
XMLConfiguration config = new XMLConfiguration(test/test.xml);
Configuration subset = new SubsetConfiguration(config,prop1.prop2.prop,.);
ConfigurationUtils.dump(subset, System.err);
...
{code}
gives the result:
{code}
@attr1]=null
@attr2]=null
{code}
it should give the result
{code}
[@attr1]=attr1
[@attr2]=attr2
{code}
The wrong dump is a side effect of the wrong implementation of the
_getChildKey_ method of SubsetConfiguration
{code}
/**
* Return the key in the subset configuration associated to the specified
* key in the parent configuration.
*
* @param key The key in the parent configuration.
* @return the key in the context of this subset configuration
*/
protected String getChildKey(String key)
{
if (!key.startsWith(prefix))
{
throw new IllegalArgumentException(The parent key ' + key + '
is not in the subset.);
}
else
{
String modifiedKey = null;
if (key.length() == prefix.length())
{
modifiedKey = ;
}
else
{
int i = prefix.length() + (delimiter != null ?
delimiter.length() : 0);
modifiedKey = key.substring(i);
}
return modifiedKey;
}
}
{code}
In this code, the _else_ part is wrong. In a hierarchical configuration, the
attribute delimiter is '[' and is removed here.
I think a more correct code would be :
{code}
/**
* Return the key in the subset configuration associated to the specified
* key in the parent configuration.
*
* @param key The key in the parent configuration.
* @return the key in the context of this subset configuration
*/
protected String getChildKey(String key)
{
if (!key.startsWith(prefix))
{
throw new IllegalArgumentException(The parent key ' + key + '
is not in the subset.);
}
else
{
String modifiedKey = null;
if (key.length() == prefix.length())
{
modifiedKey = ;
}
else
{
modifiedKey = key.substring(prefix.length());
if(delimiter!=null modifiedKey.startsWith(delimiter))
{
modifiedKey=modifiedKey.substring(delimiter.length());
}
}
return modifiedKey;
}
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-457) Escape only unicode characters not supported by the file encoding
[ https://issues.apache.org/jira/browse/CONFIGURATION-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079571#comment-13079571 ] Oliver Heger commented on CONFIGURATION-457: Do you have a fix for this issue? Escape only unicode characters not supported by the file encoding - Key: CONFIGURATION-457 URL: https://issues.apache.org/jira/browse/CONFIGURATION-457 Project: Commons Configuration Issue Type: Improvement Components: Format Affects Versions: 1.6 Reporter: Emmanuel Bourg Priority: Minor Fix For: 1.7 A non ASCII character is always escaped in a PropertiesConfiguration, even if the encoding selected supports it. It can make the properties file difficult to read and edit manually, especially for non latin languages. This issue was found on Stack Overflow: http://stackoverflow.com/questions/5661315 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CONFIGURATION-442) SubsetConfiguration does not properly list attributes when a delimiter is set
[
https://issues.apache.org/jira/browse/CONFIGURATION-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-442.
Resolution: Won't Fix
Fix Version/s: 1.7
There is a workaround for this problem.
SubsetConfiguration does not properly list attributes when a delimiter is set
-
Key: CONFIGURATION-442
URL: https://issues.apache.org/jira/browse/CONFIGURATION-442
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.6
Environment: all
Reporter: Fabien Nisol
Fix For: 1.7
imagine a XmlConfiguration like this:
{code}
properties
prop1
prop2
prop
attr1=attr1
attr2=attr2/
/prop2
/prop1
/properties
{code}
If subset get instanciated to the end of the hierarchy, with a specific
delimiter, getKeys() won't return the correct keys:
{code}
...
XMLConfiguration config = new XMLConfiguration(test/test.xml);
Configuration subset = new SubsetConfiguration(config,prop1.prop2.prop,.);
ConfigurationUtils.dump(subset, System.err);
...
{code}
gives the result:
{code}
@attr1]=null
@attr2]=null
{code}
it should give the result
{code}
[@attr1]=attr1
[@attr2]=attr2
{code}
The wrong dump is a side effect of the wrong implementation of the
_getChildKey_ method of SubsetConfiguration
{code}
/**
* Return the key in the subset configuration associated to the specified
* key in the parent configuration.
*
* @param key The key in the parent configuration.
* @return the key in the context of this subset configuration
*/
protected String getChildKey(String key)
{
if (!key.startsWith(prefix))
{
throw new IllegalArgumentException(The parent key ' + key + '
is not in the subset.);
}
else
{
String modifiedKey = null;
if (key.length() == prefix.length())
{
modifiedKey = ;
}
else
{
int i = prefix.length() + (delimiter != null ?
delimiter.length() : 0);
modifiedKey = key.substring(i);
}
return modifiedKey;
}
}
{code}
In this code, the _else_ part is wrong. In a hierarchical configuration, the
attribute delimiter is '[' and is removed here.
I think a more correct code would be :
{code}
/**
* Return the key in the subset configuration associated to the specified
* key in the parent configuration.
*
* @param key The key in the parent configuration.
* @return the key in the context of this subset configuration
*/
protected String getChildKey(String key)
{
if (!key.startsWith(prefix))
{
throw new IllegalArgumentException(The parent key ' + key + '
is not in the subset.);
}
else
{
String modifiedKey = null;
if (key.length() == prefix.length())
{
modifiedKey = ;
}
else
{
modifiedKey = key.substring(prefix.length());
if(delimiter!=null modifiedKey.startsWith(delimiter))
{
modifiedKey=modifiedKey.substring(delimiter.length());
}
}
return modifiedKey;
}
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-457) Escape only unicode characters not supported by the file encoding
[
https://issues.apache.org/jira/browse/CONFIGURATION-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079611#comment-13079611
]
Emmanuel Bourg commented on CONFIGURATION-457:
--
This could be implemented by using the {{java.nio.charset.CharsetEncoder}}
class to check if the characters can be encoded. Unsupported characters would
be escaped.
I'm not working on a fix now, so if someone want to pick the task, it's free.
Escape only unicode characters not supported by the file encoding
-
Key: CONFIGURATION-457
URL: https://issues.apache.org/jira/browse/CONFIGURATION-457
Project: Commons Configuration
Issue Type: Improvement
Components: Format
Affects Versions: 1.6
Reporter: Emmanuel Bourg
Priority: Minor
Fix For: 1.7
A non ASCII character is always escaped in a PropertiesConfiguration, even if
the encoding selected supports it. It can make the properties file difficult
to read and edit manually, especially for non latin languages.
This issue was found on Stack Overflow:
http://stackoverflow.com/questions/5661315
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
