[jira] [Commented] (SANSELAN-21) Fetching GPS Latitude Ref gets Interoperability Index instead of Reference
[ https://issues.apache.org/jira/browse/SANSELAN-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13157700#comment-13157700 ] Damjan Jovanovic commented on SANSELAN-21: -- Oh I see... the findEXIFValue() method of JpegImageMetadata has this comment: // In some cases, we want an exact directory match (such as GPS values). // In other cases, we are more permissive (ie. with tags that may appear // in a number of different directories, depending on the camera manufacturer, etc. // TODO: Modify TagInfo class to include a permissive/exact flag. Since I only see tag duplication between GPSTagConstants and 2 interoperability related ExifTagConstants, and only the tags that can be duplicated need the exact directory match, this change should be very easy. Fetching GPS Latitude Ref gets Interoperability Index instead of Reference -- Key: SANSELAN-21 URL: https://issues.apache.org/jira/browse/SANSELAN-21 Project: Commons Sanselan Issue Type: Bug Affects Versions: 0.94-incubator Environment: Windows XP SP3, java version 1.5.0_17 apache-sanselan-incubating-0.97-bin.zip Reporter: Christian Junk Priority: Minor Attachments: R0013102.jpg, geo1.jpg, sanselan-21.patch When testing the following example https://svn.apache.org/repos/asf/incubator/sanselan/trunk/src/test/java/org/apache/sanselan/sampleUsage/MetadataExample.java with apache-sanselan-incubating-0.97 it always stops working throwing a ClassCastException. It seems, that the line TiffField gpsLatitudeRefField = jpegMetadata .findEXIFValue(TiffConstants.GPS_TAG_GPS_LATITUDE_REF); returns the Interoperability Index (R98) instead of the GPS Latitude Ref. XResolution: 72 Date Time: '2008:07:23 18:19:58' Date Time Original: '2008:07:23 10:05:21' Create Date: '2008:07:23 10:05:21' ISO: 64 Shutter Speed Value: Not Found. Aperture Value: 6 Brightness Value: 81/10 (8,1) GPS Latitude Ref: 'R98' !!! GPS Latitude: 48, 49, 48, 48 GPS Longitude Ref: 'E' GPS Longitude: 6, 38, 2061/100 (20,61) GPS Description: [GPS. Latitude: 49 degrees, 45 minutes, 34,18 seconds N, Longitude: 6 degrees, 38 minutes, 20,61 seconds E] Exception in thread main java.lang.ClassCastException: [B at com.alta4.phasr.MetadataExample.metadataExample(MetadataExample.java:113) -- 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] (SANSELAN-21) Fetching GPS Latitude Ref gets Interoperability Index instead of Reference
[ https://issues.apache.org/jira/browse/SANSELAN-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damjan Jovanovic updated SANSELAN-21: - Attachment: tiff-tag-exact-directory.patch This patch fixes your test case, but doesn't fix what toString() of JpegImageMetadata returns. That seems to require further changes to TIFF code. Fetching GPS Latitude Ref gets Interoperability Index instead of Reference -- Key: SANSELAN-21 URL: https://issues.apache.org/jira/browse/SANSELAN-21 Project: Commons Sanselan Issue Type: Bug Affects Versions: 0.94-incubator Environment: Windows XP SP3, java version 1.5.0_17 apache-sanselan-incubating-0.97-bin.zip Reporter: Christian Junk Priority: Minor Attachments: R0013102.jpg, geo1.jpg, sanselan-21.patch, tiff-tag-exact-directory.patch When testing the following example https://svn.apache.org/repos/asf/incubator/sanselan/trunk/src/test/java/org/apache/sanselan/sampleUsage/MetadataExample.java with apache-sanselan-incubating-0.97 it always stops working throwing a ClassCastException. It seems, that the line TiffField gpsLatitudeRefField = jpegMetadata .findEXIFValue(TiffConstants.GPS_TAG_GPS_LATITUDE_REF); returns the Interoperability Index (R98) instead of the GPS Latitude Ref. XResolution: 72 Date Time: '2008:07:23 18:19:58' Date Time Original: '2008:07:23 10:05:21' Create Date: '2008:07:23 10:05:21' ISO: 64 Shutter Speed Value: Not Found. Aperture Value: 6 Brightness Value: 81/10 (8,1) GPS Latitude Ref: 'R98' !!! GPS Latitude: 48, 49, 48, 48 GPS Longitude Ref: 'E' GPS Longitude: 6, 38, 2061/100 (20,61) GPS Description: [GPS. Latitude: 49 degrees, 45 minutes, 34,18 seconds N, Longitude: 6 degrees, 38 minutes, 20,61 seconds E] Exception in thread main java.lang.ClassCastException: [B at com.alta4.phasr.MetadataExample.metadataExample(MetadataExample.java:113) -- 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] (MATH-705) DormandPrince853 integrator leads to revisiting of state events
[
https://issues.apache.org/jira/browse/MATH-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe updated MATH-705:
---
Fix Version/s: 3.0
Assignee: Luc Maisonobe
DormandPrince853 integrator leads to revisiting of state events
---
Key: MATH-705
URL: https://issues.apache.org/jira/browse/MATH-705
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Environment: Commons Math trunk, Java 6, Linux
Reporter: Dennis Hendriks
Assignee: Luc Maisonobe
Fix For: 3.0
Attachments: ReappearingEventTest.java, ReappearingEventTest.out
See the attached ReappearingEventTest.java. It has two unit tests, which use
either the DormandPrince853 or the GraggBulirschStoer integrator, on the same
ODE problem. It is a problem starting at time 6.0, with 7 variables, and 1
state event. The state event was previously detected at time 6.0, which is
why I start there now. I provide and end time of 10.0. Since I start at the
state event, I expect to integrate all the way to the end (10.0). For the
GraggBulirschStoer this is what happens (see attached
ReappearingEventTest.out). For the DormandPrince853Integerator, it detects a
state event and stops integration at 6.002.
I think the problem becomes clear by looking at the output in
ReappearingEventTest.out, in particular these lines:
{noformat}
computeDerivatives: t=6.0 y=[2.0 , 2.0
, 2.0 , 4.0 , 2.0 ,
7.0 , 15.0]
(...)
g : t=6.0 y=[1.9996 ,
1.9996 , 1.9996 , 4.0 ,
1.9996 , 7.0 , 14.998 ]
(...)
final result : t=6.002y=[2.0013 ,
2.0013 , 2.0013 , 4.002 ,
2.0013 , 7.002 , 15.0]
{noformat}
The initial value of the last variable in y, the one that the state event
refers to, is 15.0. However, the first time it is given to the g function,
the value is 14.998. This value is less than 15, and more
importantly, it is a value from the past (as all functions are increasing),
*before* the state event. This makes that the state event re-appears
immediately, and integration stops at 6.002 because of the
detected state event.
I find it puzzling that for the DormandPrince853Integerator the y array that
is given to the first evaluation of the g function, has different values than
the y array that is the input to the problem. For GraggBulirschStoer is can
be seen that the y arrays have identical values.
--
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] (MATH-710) Add support for fast cryptographically secure pseudorandom number generator ISAAC
[ https://issues.apache.org/jira/browse/MATH-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe updated MATH-710: --- Priority: Minor (was: Major) Fix Version/s: 3.0 Assignee: Luc Maisonobe Add support for fast cryptographically secure pseudorandom number generator ISAAC - Key: MATH-710 URL: https://issues.apache.org/jira/browse/MATH-710 Project: Commons Math Issue Type: New Feature Affects Versions: 2.2 Reporter: Eldar Agalarov Assignee: Luc Maisonobe Priority: Minor Fix For: 3.0 Attachments: ISAACRandom.java, ISAACRandom.java, ISAACTest.java Original Estimate: 1h Remaining Estimate: 1h Dear developers, please add to Commons Math library support for ISAAC random number generator. This is a free and open-source CSPRNG (see at http://burtleburtle.net/bob/rand/isaacafa.html). Rewrited (with some improvements) Java code from original C version is attached. -- 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-713) Negative value with restrictNonNegative
[ https://issues.apache.org/jira/browse/MATH-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13157713#comment-13157713 ] Luc Maisonobe commented on MATH-713: Could you please check this agains the latest development version from the subversion repository ? There have been several fixes concerning these coefficients in simplex solver since 2.2 Negative value with restrictNonNegative --- Key: MATH-713 URL: https://issues.apache.org/jira/browse/MATH-713 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Environment: commons-math-2.2 Reporter: Michał Skrzypczak Labels: nonnegative, simplex, solver Original Estimate: 3h Remaining Estimate: 3h Problem: commons-math-2.2 SimplexSolver. A variable with 0 coefficient may be assigned a negative value nevertheless restrictToNonnegative flag in call: SimplexSolver.optimize(function, constraints, GoalType.MINIMIZE, true); Function 1 * x + 1 * y + 0 Constraints: 1 * x + 0 * y = 1 Result: x = 1; y = -1; Probably variables with 0 coefficients are omitted at some point of computation and because of that the restrictions do not affect their values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-713) Negative value with restrictNonNegative
[ https://issues.apache.org/jira/browse/MATH-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13157713#comment-13157713 ] Luc Maisonobe edited comment on MATH-713 at 11/27/11 9:29 AM: -- Could you please check this against the latest development version from the subversion repository ? There have been several fixes concerning these coefficients in simplex solver since 2.2 was (Author: luc): Could you please check this agains the latest development version from the subversion repository ? There have been several fixes concerning these coefficients in simplex solver since 2.2 Negative value with restrictNonNegative --- Key: MATH-713 URL: https://issues.apache.org/jira/browse/MATH-713 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Environment: commons-math-2.2 Reporter: Michał Skrzypczak Labels: nonnegative, simplex, solver Original Estimate: 3h Remaining Estimate: 3h Problem: commons-math-2.2 SimplexSolver. A variable with 0 coefficient may be assigned a negative value nevertheless restrictToNonnegative flag in call: SimplexSolver.optimize(function, constraints, GoalType.MINIMIZE, true); Function 1 * x + 1 * y + 0 Constraints: 1 * x + 0 * y = 1 Result: x = 1; y = -1; Probably variables with 0 coefficients are omitted at some point of computation and because of that the restrictions do not affect their values. -- 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] (SANSELAN-21) Fetching GPS Latitude Ref gets Interoperability Index instead of Reference
[ https://issues.apache.org/jira/browse/SANSELAN-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13157716#comment-13157716 ] Damjan Jovanovic commented on SANSELAN-21: -- No, at least 79 cases of TIFF tag duplication exist in the code, hardcoding which tag directories are matched inexactly seems too error-prone. The real problem here is that Sanselan hasn't solved the problem of inexact tag matching. The many hacks and commented out code in TiffField's getTag() method, and the fact it searches through only EXIF tags instead of all tags, show there is a serious problem. I'll have to see what other EXIF tools do in this case. Fetching GPS Latitude Ref gets Interoperability Index instead of Reference -- Key: SANSELAN-21 URL: https://issues.apache.org/jira/browse/SANSELAN-21 Project: Commons Sanselan Issue Type: Bug Affects Versions: 0.94-incubator Environment: Windows XP SP3, java version 1.5.0_17 apache-sanselan-incubating-0.97-bin.zip Reporter: Christian Junk Priority: Minor Attachments: R0013102.jpg, geo1.jpg, sanselan-21.patch, tiff-tag-exact-directory.patch When testing the following example https://svn.apache.org/repos/asf/incubator/sanselan/trunk/src/test/java/org/apache/sanselan/sampleUsage/MetadataExample.java with apache-sanselan-incubating-0.97 it always stops working throwing a ClassCastException. It seems, that the line TiffField gpsLatitudeRefField = jpegMetadata .findEXIFValue(TiffConstants.GPS_TAG_GPS_LATITUDE_REF); returns the Interoperability Index (R98) instead of the GPS Latitude Ref. XResolution: 72 Date Time: '2008:07:23 18:19:58' Date Time Original: '2008:07:23 10:05:21' Create Date: '2008:07:23 10:05:21' ISO: 64 Shutter Speed Value: Not Found. Aperture Value: 6 Brightness Value: 81/10 (8,1) GPS Latitude Ref: 'R98' !!! GPS Latitude: 48, 49, 48, 48 GPS Longitude Ref: 'E' GPS Longitude: 6, 38, 2061/100 (20,61) GPS Description: [GPS. Latitude: 49 degrees, 45 minutes, 34,18 seconds N, Longitude: 6 degrees, 38 minutes, 20,61 seconds E] Exception in thread main java.lang.ClassCastException: [B at com.alta4.phasr.MetadataExample.metadataExample(MetadataExample.java:113) -- 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-705) DormandPrince853 integrator leads to revisiting of state events
[
https://issues.apache.org/jira/browse/MATH-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe resolved MATH-705.
Resolution: Fixed
Fixed in subversion repository as of r1206723.
Applied same method to all Runge-Kutta based integrators.
Thanks for the report.
DormandPrince853 integrator leads to revisiting of state events
---
Key: MATH-705
URL: https://issues.apache.org/jira/browse/MATH-705
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Environment: Commons Math trunk, Java 6, Linux
Reporter: Dennis Hendriks
Assignee: Luc Maisonobe
Fix For: 3.0
Attachments: ReappearingEventTest.java, ReappearingEventTest.out
See the attached ReappearingEventTest.java. It has two unit tests, which use
either the DormandPrince853 or the GraggBulirschStoer integrator, on the same
ODE problem. It is a problem starting at time 6.0, with 7 variables, and 1
state event. The state event was previously detected at time 6.0, which is
why I start there now. I provide and end time of 10.0. Since I start at the
state event, I expect to integrate all the way to the end (10.0). For the
GraggBulirschStoer this is what happens (see attached
ReappearingEventTest.out). For the DormandPrince853Integerator, it detects a
state event and stops integration at 6.002.
I think the problem becomes clear by looking at the output in
ReappearingEventTest.out, in particular these lines:
{noformat}
computeDerivatives: t=6.0 y=[2.0 , 2.0
, 2.0 , 4.0 , 2.0 ,
7.0 , 15.0]
(...)
g : t=6.0 y=[1.9996 ,
1.9996 , 1.9996 , 4.0 ,
1.9996 , 7.0 , 14.998 ]
(...)
final result : t=6.002y=[2.0013 ,
2.0013 , 2.0013 , 4.002 ,
2.0013 , 7.002 , 15.0]
{noformat}
The initial value of the last variable in y, the one that the state event
refers to, is 15.0. However, the first time it is given to the g function,
the value is 14.998. This value is less than 15, and more
importantly, it is a value from the past (as all functions are increasing),
*before* the state event. This makes that the state event re-appears
immediately, and integration stops at 6.002 because of the
detected state event.
I find it puzzling that for the DormandPrince853Integerator the y array that
is given to the first evaluation of the g function, has different values than
the y array that is the input to the problem. For GraggBulirschStoer is can
be seen that the y arrays have identical values.
--
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] (COMPRESS-16) unable to extract a TAR file that contains an entry which is 10 GB in size
[ https://issues.apache.org/jira/browse/COMPRESS-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Kodis updated COMPRESS-16: --- Attachment: 0002-Allow-creating-tar-archives-with-files-over-8GB.patch 0001-Accept-GNU-tar-files-with-entries-over-8GB-in-size.patch [PATCH 1/2] Accept GNU tar files with entries over 8GB in size. The tar file format originally stored the size of a file in a 12 byte null-terminated field, which allowed a maximum file size of 8^11, or 8,589,934,592 bytes. To accomodate larger files, later versions of GNU tar will use this same 12 byte field to hold a binary representation of the file size, denoting this as a binary value by setting the most-significant bit of the first byte of the field. [PATCH 2/2] Allow creating tar archives with files over 8GB. Use the same binary encoding scheme above to allow the creation of tar archives containing files over 8GB in size. unable to extract a TAR file that contains an entry which is 10 GB in size -- Key: COMPRESS-16 URL: https://issues.apache.org/jira/browse/COMPRESS-16 Project: Commons Compress Issue Type: Bug Components: Archivers Environment: I am using win xp sp3, but this should be platform independent. Reporter: Sam Smith Attachments: 0001-Accept-GNU-tar-files-with-entries-over-8GB-in-size.patch, 0002-Allow-creating-tar-archives-with-files-over-8GB.patch, ant-8GB-tar.patch, patch-for-compress.txt I made a TAR file which contains a file entry where the file is 10 GB in size. When I attempt to extract the file using TarInputStream, it fails with the following stack trace: java.io.IOException: unexpected EOF with 24064 bytes unread at org.apache.commons.compress.archivers.tar.TarInputStream.read(TarInputStream.java:348) at org.apache.commons.compress.archivers.tar.TarInputStream.copyEntryContents(TarInputStream.java:388) So, TarInputStream does not seem to support large ( 8 GB?) files. Here is something else to note: I created that TAR file using TarOutputStream , which did not complain when asked to write a 10 GB file into the TAR file, so I assume that TarOutputStream has no file size limits? That, or does it silently create corrupted TAR files (which would be the worst situation of all...)? -- 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] (COMPRESS-16) unable to extract a TAR file that contains an entry which is 10 GB in size
[ https://issues.apache.org/jira/browse/COMPRESS-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Kodis updated COMPRESS-16: --- Comment: was deleted (was: I've attached two patch files against commons-compress-1.3-src which add support for reading (patch 0001) and writing (patch 0002) tar archives which contain files larger than the 8GB limit imposed by the use of a 12 character octal size field in the tar header. I've followed the approach taken by the GNU tar utility: for files larger than the 8GB limit, continue to use the same size field, but switch to a binary size representation, noting this change by detecting (on read) or setting (on write) the most significant bit of the first byte of the size field. ) unable to extract a TAR file that contains an entry which is 10 GB in size -- Key: COMPRESS-16 URL: https://issues.apache.org/jira/browse/COMPRESS-16 Project: Commons Compress Issue Type: Bug Components: Archivers Environment: I am using win xp sp3, but this should be platform independent. Reporter: Sam Smith Attachments: 0001-Accept-GNU-tar-files-with-entries-over-8GB-in-size.patch, 0002-Allow-creating-tar-archives-with-files-over-8GB.patch, ant-8GB-tar.patch, patch-for-compress.txt I made a TAR file which contains a file entry where the file is 10 GB in size. When I attempt to extract the file using TarInputStream, it fails with the following stack trace: java.io.IOException: unexpected EOF with 24064 bytes unread at org.apache.commons.compress.archivers.tar.TarInputStream.read(TarInputStream.java:348) at org.apache.commons.compress.archivers.tar.TarInputStream.copyEntryContents(TarInputStream.java:388) So, TarInputStream does not seem to support large ( 8 GB?) files. Here is something else to note: I created that TAR file using TarOutputStream , which did not complain when asked to write a 10 GB file into the TAR file, so I assume that TarOutputStream has no file size limits? That, or does it silently create corrupted TAR files (which would be the worst situation of all...)? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-16) unable to extract a TAR file that contains an entry which is 10 GB in size
[ https://issues.apache.org/jira/browse/COMPRESS-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13157913#comment-13157913 ] John Kodis commented on COMPRESS-16: I've attached two patch files against commons-compress-1.3-src which add support for reading (patch 0001) and writing (patch 0002) tar archives which contain files larger than the 8GB limit imposed by the use of a 12 character octal size field in the tar header. I've followed the approach taken by the GNU tar utility: for files larger than the 8GB limit, continue to use the same size field, but switch to a binary size representation, noting this change by detecting (on read) or setting (on write) the most significant bit of the first byte of the size field. unable to extract a TAR file that contains an entry which is 10 GB in size -- Key: COMPRESS-16 URL: https://issues.apache.org/jira/browse/COMPRESS-16 Project: Commons Compress Issue Type: Bug Components: Archivers Environment: I am using win xp sp3, but this should be platform independent. Reporter: Sam Smith Attachments: 0001-Accept-GNU-tar-files-with-entries-over-8GB-in-size.patch, 0002-Allow-creating-tar-archives-with-files-over-8GB.patch, ant-8GB-tar.patch, patch-for-compress.txt I made a TAR file which contains a file entry where the file is 10 GB in size. When I attempt to extract the file using TarInputStream, it fails with the following stack trace: java.io.IOException: unexpected EOF with 24064 bytes unread at org.apache.commons.compress.archivers.tar.TarInputStream.read(TarInputStream.java:348) at org.apache.commons.compress.archivers.tar.TarInputStream.copyEntryContents(TarInputStream.java:388) So, TarInputStream does not seem to support large ( 8 GB?) files. Here is something else to note: I created that TAR file using TarOutputStream , which did not complain when asked to write a 10 GB file into the TAR file, so I assume that TarOutputStream has no file size limits? That, or does it silently create corrupted TAR files (which would be the worst situation of all...)? -- 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] (COMPRESS-16) unable to extract a TAR file that contains an entry which is 10 GB in size
[ https://issues.apache.org/jira/browse/COMPRESS-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Kodis updated COMPRESS-16: --- Comment: was deleted (was: [PATCH 1/2] Accept GNU tar files with entries over 8GB in size. The tar file format originally stored the size of a file in a 12 byte null-terminated field, which allowed a maximum file size of 8^11, or 8,589,934,592 bytes. To accomodate larger files, later versions of GNU tar will use this same 12 byte field to hold a binary representation of the file size, denoting this as a binary value by setting the most-significant bit of the first byte of the field. [PATCH 2/2] Allow creating tar archives with files over 8GB. Use the same binary encoding scheme above to allow the creation of tar archives containing files over 8GB in size.) unable to extract a TAR file that contains an entry which is 10 GB in size -- Key: COMPRESS-16 URL: https://issues.apache.org/jira/browse/COMPRESS-16 Project: Commons Compress Issue Type: Bug Components: Archivers Environment: I am using win xp sp3, but this should be platform independent. Reporter: Sam Smith Attachments: 0001-Accept-GNU-tar-files-with-entries-over-8GB-in-size.patch, 0002-Allow-creating-tar-archives-with-files-over-8GB.patch, ant-8GB-tar.patch, patch-for-compress.txt I made a TAR file which contains a file entry where the file is 10 GB in size. When I attempt to extract the file using TarInputStream, it fails with the following stack trace: java.io.IOException: unexpected EOF with 24064 bytes unread at org.apache.commons.compress.archivers.tar.TarInputStream.read(TarInputStream.java:348) at org.apache.commons.compress.archivers.tar.TarInputStream.copyEntryContents(TarInputStream.java:388) So, TarInputStream does not seem to support large ( 8 GB?) files. Here is something else to note: I created that TAR file using TarOutputStream , which did not complain when asked to write a 10 GB file into the TAR file, so I assume that TarOutputStream has no file size limits? That, or does it silently create corrupted TAR files (which would be the worst situation of all...)? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-16) unable to extract a TAR file that contains an entry which is 10 GB in size
[ https://issues.apache.org/jira/browse/COMPRESS-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13157915#comment-13157915 ] John Kodis commented on COMPRESS-16: I've attached two patch files against commons-compress-1.3-src which add support for reading (patch 0001) and writing (patch 0002) tar archives which contain files larger than the 8GB limit imposed by the use of a 12 character octal size field in the tar header. I've followed the approach taken by the GNU tar utility: for files larger than the 8GB limit, continue to use the same size field, but switch to a binary size representation, noting this change by detecting (on read) or setting (on write) the most significant bit of the first byte of the size field. Tar archives written in this format are correctly processed by at least GNU tar (used primarily on Linux), BSD tar (used on Mac OS-X as well as the BSDs), and 7-Zip (used primarily on Windows). unable to extract a TAR file that contains an entry which is 10 GB in size -- Key: COMPRESS-16 URL: https://issues.apache.org/jira/browse/COMPRESS-16 Project: Commons Compress Issue Type: Bug Components: Archivers Environment: I am using win xp sp3, but this should be platform independent. Reporter: Sam Smith Attachments: 0001-Accept-GNU-tar-files-with-entries-over-8GB-in-size.patch, 0002-Allow-creating-tar-archives-with-files-over-8GB.patch, ant-8GB-tar.patch, patch-for-compress.txt I made a TAR file which contains a file entry where the file is 10 GB in size. When I attempt to extract the file using TarInputStream, it fails with the following stack trace: java.io.IOException: unexpected EOF with 24064 bytes unread at org.apache.commons.compress.archivers.tar.TarInputStream.read(TarInputStream.java:348) at org.apache.commons.compress.archivers.tar.TarInputStream.copyEntryContents(TarInputStream.java:388) So, TarInputStream does not seem to support large ( 8 GB?) files. Here is something else to note: I created that TAR file using TarOutputStream , which did not complain when asked to write a 10 GB file into the TAR file, so I assume that TarOutputStream has no file size limits? That, or does it silently create corrupted TAR files (which would be the worst situation of all...)? -- 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-703) Splitting up the distribution hierarchy
[
https://issues.apache.org/jira/browse/MATH-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13157961#comment-13157961
]
Christian Winter commented on MATH-703:
---
Thanks for the comments. I'm going to prepare a new patch based on them. I
appreciate removing the caching support for mean and variance (thanks for the
point with mutable distributions) as well as the method
{{toRealDistribution()}}. When preparing the first version of the patch, I just
wanted to retain the old code/functionality in some form in order to have a
discussion basis which doesn't drop anything tacitly.
I will move Default to its children as there are two votes for it. I don't
have a preference on another possibility (keeping Default or moving it to the
parents).
Splitting up the distribution hierarchy
---
Key: MATH-703
URL: https://issues.apache.org/jira/browse/MATH-703
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Christian Winter
Priority: Minor
Fix For: 3.0
Attachments: MATH-703_patch.zip
As discussed on the mailing list
(http://apache-commons.680414.n4.nabble.com/math-Distributions-over-sample-spaces-other-than-R-tp3931349p3931349.html),
the distribution interfaces should be restructured.
The most important point is to create one root interface for each domain.
There should *not* be a common super-interace because different domains
require different functionality. Additionally, a super-inferface would
require to parametrize the domain which makes things more complicated (e.g.,
double would have to be replaced by Double). Currently, Commons Math
supports distributions with real domain and distributions with integer
domain. Thus there will be the interfaces RealDistribution and
IntegerDistribution.
Another point is to drop the special cases of distributions with real domain
in order to simplify the structure. There won't be an interface for
absolutely continuous distributions, and there won't be an interface for
discrete distributions on the real domain. All the functionality required by
the special cases can be defined in RealDistribution.
--
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] (CHAIN-58) Update Chain Context interface to use K,V generics
[
https://issues.apache.org/jira/browse/CHAIN-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elijah Zupancic updated CHAIN-58:
-
Attachment: chain-58.diff
Patch for suggested changes to doing a K,V style generics for chain.
Update Chain Context interface to use K,V generics
--
Key: CHAIN-58
URL: https://issues.apache.org/jira/browse/CHAIN-58
Project: Commons Chain
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Elijah Zupancic
Fix For: 2.0
Attachments: chain-58.diff, chain-58.diff
As discussed in the mailing list, I am suggesting that we change the
definition of Context from:
{noformat}
public interface Context extends MapString, Object {
{noformat}
to:
{noformat}
public interface ContextK, V extends MapK, V {
{noformat}
--
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] (CHAIN-58) Update Chain Context interface to use K,V generics
[
https://issues.apache.org/jira/browse/CHAIN-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elijah Zupancic updated CHAIN-58:
-
Attachment: (was: chain-58.diff)
Update Chain Context interface to use K,V generics
--
Key: CHAIN-58
URL: https://issues.apache.org/jira/browse/CHAIN-58
Project: Commons Chain
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Elijah Zupancic
Fix For: 2.0
Attachments: chain-58.diff
As discussed in the mailing list, I am suggesting that we change the
definition of Context from:
{noformat}
public interface Context extends MapString, Object {
{noformat}
to:
{noformat}
public interface ContextK, V extends MapK, V {
{noformat}
--
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-649) SimpleRegression needs the ability to suppress the intercept
[ https://issues.apache.org/jira/browse/MATH-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved MATH-649. -- Resolution: Fixed SimpleRegression needs the ability to suppress the intercept Key: MATH-649 URL: https://issues.apache.org/jira/browse/MATH-649 Project: Commons Math Issue Type: New Feature Affects Versions: 1.2, 2.1, 2.2 Environment: JAVA Reporter: greg sterijevski Assignee: greg sterijevski Priority: Minor Labels: NOINTERCEPT, SIMPLEREGRESSION Fix For: 3.0 Attachments: simplereg, simplereg2, simpleregtest Original Estimate: 2h Remaining Estimate: 2h The SimpleRegression class is a useful class for running regressions involving one independent variable. It lacks the ability to constrain the constant to be zero. I am attaching a patch which gives a constructor for setting NOINT. I am also checking in two NIST data sets for noint estimation. -- 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] (VFS-396) RAM FileSystem allows the file system size to exceed the max size limit.
RAM FileSystem allows the file system size to exceed the max size limit.
Key: VFS-396
URL: https://issues.apache.org/jira/browse/VFS-396
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0
Environment: All
Reporter: Rupesh Kumar
When a new file is created in the RAM file system, and content is written to
its outputstream, there is a check in place for ensuring that file system size
does not exceed the max limit set. But that check is wrong.
In RamFileOutputStream.write(), you calculate the size, newsize and call
file.resize(newSize)
And in the RamFileObject.resize(), there is a check
if (fs.size() + newSize - this.size() maxSize)
{
throw new IOException(FileSystem capacity ( + maxSize
+ ) exceeded.);
}
This check is wrong.
Consider this case of a new file system where the file system size is set to 5
MB and I am trying to create a file of 10 MB in the RAM file system. the file
is being written in the chunk of 8 kb. For every resize check, fs.size() would
be 0 and (newsize - this.size()) would be 8 kb and therefore the check never
passes.
It could have been correct if the old size was locked down to the size that
was registered with the file system but the old size (this.size()) keeps
changing at every write. Thus the difference in newSize and this.size() would
always be the chunk size (typically 8 kb) and therefore no exception would be
thrown ever.
--
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-774) Add isStarted isStopped and isSuspended to StopWatch
[ https://issues.apache.org/jira/browse/LANG-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13158016#comment-13158016 ] Erhan Bagdemir commented on LANG-774: - These overridden methods in enum types give me a feeling that there's something duplicated or redundant :-S I think it's a question of coding style not design. Add isStarted isStopped and isSuspended to StopWatch Key: LANG-774 URL: https://issues.apache.org/jira/browse/LANG-774 Project: Commons Lang Issue Type: Improvement Components: lang.time.* Affects Versions: 3.1 Reporter: Michael Akerman Priority: Minor Labels: features Fix For: 3.2 Attachments: LANG774.diff, LANG774_1.diff, LANG774_2.patch, StopWatch.java Original Estimate: 2h Remaining Estimate: 2h It would be nice to have: isStarted isStopped isSuspended On StopWatch -- 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-396) RAM FileSystem allows the file system size to exceed the max size limit.
[
https://issues.apache.org/jira/browse/VFS-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13158036#comment-13158036
]
Gary D. Gregory commented on VFS-396:
-
Can you provide a patch with a unit test please?
-- Posted from Bugbox for iPhone
RAM FileSystem allows the file system size to exceed the max size limit.
Key: VFS-396
URL: https://issues.apache.org/jira/browse/VFS-396
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0
Environment: All
Reporter: Rupesh Kumar
Original Estimate: 0.5h
Remaining Estimate: 0.5h
When a new file is created in the RAM file system, and content is written to
its outputstream, there is a check in place for ensuring that file system
size does not exceed the max limit set. But that check is wrong.
In RamFileOutputStream.write(), you calculate the size, newsize and call
file.resize(newSize)
And in the RamFileObject.resize(), there is a check
if (fs.size() + newSize - this.size() maxSize)
{
throw new IOException(FileSystem capacity ( + maxSize
+ ) exceeded.);
}
This check is wrong.
Consider this case of a new file system where the file system size is set to
5 MB and I am trying to create a file of 10 MB in the RAM file system. the
file is being written in the chunk of 8 kb. For every resize check, fs.size()
would be 0 and (newsize - this.size()) would be 8 kb and therefore the check
never passes.
It could have been correct if the old size was locked down to the size
that was registered with the file system but the old size (this.size()) keeps
changing at every write. Thus the difference in newSize and this.size() would
always be the chunk size (typically 8 kb) and therefore no exception would be
thrown ever.
--
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-707) Naming confusion
[
https://issues.apache.org/jira/browse/MATH-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13158048#comment-13158048
]
Gilles commented on MATH-707:
-
Changed {{...UnivariateRealFunction}} to {{...UnivariateFunction}} (revision
1206867).
Naming confusion
Key: MATH-707
URL: https://issues.apache.org/jira/browse/MATH-707
Project: Commons Math
Issue Type: Task
Reporter: Gilles
Assignee: Gilles
Priority: Trivial
Labels: api-change
Fix For: 3.0
This issue was raised in [this
thread|http://markmail.org/thread/4h6omyqsik65rcgv] on the dev ML.
It proposes to consistently name classes/interfaces that refer to number
types (e.g. Real, Complex, ...) and structure (e.g. Scalar,
Vectorial, ...), with Real and Scalar components in names being assumed
(thus, not to be included in the name).
For example, for the Univariate... interfaces (in package analysis), the
proposal is to operate the following renaming:
* {{UnivariateRealFunction}} - {{UnivariateFunction}}
* {{UnivariateRealVectorialFunction}} - {{UnivariateVectorFunction}}
* {{UnivariateMatrixFunction}} - {{UnivariateMatrixFunction}}
Similar changes are in order in the package optimization (where Real is
sometimes included in the name and sometimes not, or used instead of
Scalar).
--
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-707) Naming confusion
[
https://issues.apache.org/jira/browse/MATH-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13158063#comment-13158063
]
Gilles commented on MATH-707:
-
Changed {{...MultivariateRealFunction}} to {{...MultivariateFunction}}
(revision 1206889).
Naming confusion
Key: MATH-707
URL: https://issues.apache.org/jira/browse/MATH-707
Project: Commons Math
Issue Type: Task
Reporter: Gilles
Assignee: Gilles
Priority: Trivial
Labels: api-change
Fix For: 3.0
This issue was raised in [this
thread|http://markmail.org/thread/4h6omyqsik65rcgv] on the dev ML.
It proposes to consistently name classes/interfaces that refer to number
types (e.g. Real, Complex, ...) and structure (e.g. Scalar,
Vectorial, ...), with Real and Scalar components in names being assumed
(thus, not to be included in the name).
For example, for the Univariate... interfaces (in package analysis), the
proposal is to operate the following renaming:
* {{UnivariateRealFunction}} - {{UnivariateFunction}}
* {{UnivariateRealVectorialFunction}} - {{UnivariateVectorFunction}}
* {{UnivariateMatrixFunction}} - {{UnivariateMatrixFunction}}
Similar changes are in order in the package optimization (where Real is
sometimes included in the name and sometimes not, or used instead of
Scalar).
--
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] (SANSELAN-21) Fetching GPS Latitude Ref gets Interoperability Index instead of Reference
[ https://issues.apache.org/jira/browse/SANSELAN-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damjan Jovanovic resolved SANSELAN-21. -- Resolution: Fixed Fix Version/s: 0.94-incubator Fix committed to latest SVN, resolving fixed. Fetching GPS Latitude Ref gets Interoperability Index instead of Reference -- Key: SANSELAN-21 URL: https://issues.apache.org/jira/browse/SANSELAN-21 Project: Commons Sanselan Issue Type: Bug Affects Versions: 0.94-incubator Environment: Windows XP SP3, java version 1.5.0_17 apache-sanselan-incubating-0.97-bin.zip Reporter: Christian Junk Priority: Minor Fix For: 0.94-incubator Attachments: R0013102.jpg, geo1.jpg, sanselan-21.patch, tiff-tag-exact-directory.patch When testing the following example https://svn.apache.org/repos/asf/incubator/sanselan/trunk/src/test/java/org/apache/sanselan/sampleUsage/MetadataExample.java with apache-sanselan-incubating-0.97 it always stops working throwing a ClassCastException. It seems, that the line TiffField gpsLatitudeRefField = jpegMetadata .findEXIFValue(TiffConstants.GPS_TAG_GPS_LATITUDE_REF); returns the Interoperability Index (R98) instead of the GPS Latitude Ref. XResolution: 72 Date Time: '2008:07:23 18:19:58' Date Time Original: '2008:07:23 10:05:21' Create Date: '2008:07:23 10:05:21' ISO: 64 Shutter Speed Value: Not Found. Aperture Value: 6 Brightness Value: 81/10 (8,1) GPS Latitude Ref: 'R98' !!! GPS Latitude: 48, 49, 48, 48 GPS Longitude Ref: 'E' GPS Longitude: 6, 38, 2061/100 (20,61) GPS Description: [GPS. Latitude: 49 degrees, 45 minutes, 34,18 seconds N, Longitude: 6 degrees, 38 minutes, 20,61 seconds E] Exception in thread main java.lang.ClassCastException: [B at com.alta4.phasr.MetadataExample.metadataExample(MetadataExample.java:113) -- 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
