[jira] [Commented] (IMAGING-285) Decoding of Rational Numbers broken when large values present
[
https://issues.apache.org/jira/browse/IMAGING-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396499#comment-17396499
]
Gilles Sadowski commented on IMAGING-285:
-
{quote}The RationalNumbers handling in the TIFF/EXIF formats is pretty narrow
and specialized. So it won't benefit from Commons Numbers, [...]
{quote}
At a glance, it seemed that the {{RationalNumber}} class and the {{Fraction}}
class mentioned above had a lot in common.
Is there some particular feature that would prevent that the latter be a
replacement for the former?
{quote}I didn't realize that Commons Numbers existed.
{quote}
{{Fraction}} and {{BigFraction}} were part of "Commons Math" until the last
official release (v3.6.1) and several improvements (including bug-fixes) were
made after they had been ported to "Commons Numbers".
bq. Cool stuff.
;-)
IMHO, some "consolidation" of the Commons components would be beneficial for
all of them, and their users...
> Decoding of Rational Numbers broken when large values present
> -
>
> Key: IMAGING-285
> URL: https://issues.apache.org/jira/browse/IMAGING-285
> Project: Commons Imaging
> Issue Type: Bug
> Components: imaging.common.*
>Affects Versions: 1.0-alpha2
>Reporter: John Andrade
>Priority: Major
> Attachments: DJI_0267 cropped.JPG
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Decoding Lat/Long EXIF data from JPEGs does not work for some values. I have
> attached a file where the conversion fails. I used the
> getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast methods from the
> TiffImageMetaData.GPSInfo class. The values are close, but seemingly off by
> a few miles.
> I've traced the source and I believe the issue is with how the RationalNumber
> class uses two 32-bit signed integers for the numerator and denominator. The
> definition of a RATIONAL data type uses 32-bit unsigned numbers. It seems as
> if the RationalNumber class already expects this as it has a non-public
> static method called factoryMethod to create a RationalNumber from two 64-bit
> numbers.
> This error is introduced in the ByteConversions class, specifically the
> toRational method where it uses the regular RationalNumber constructor and
> thus ensures any rational numbers that have numerator or denominator greater
> than the max signed 32-bit value will produce invalid values.
> I am attaching a JPEG that has this problem. I had to crop it to reduce the
> size, but the EXIF data was preserved.
> The EXIF GPS data contained in the JPEG is:
> GpsLatitudeRef: "N"
> GpsLatitude: 38, 1, 36, 1, 4120083230, 7000
> GpsLongitudeRef: "W"
> GpsLongitude: 90, 1, 12, 1, 2379156648, 7000
> According to the properties of the image (right-clicking on Windows 10), the
> L/L of the image is:
> Latitude: 38: 36: 58.85833
> Longitude: 90: 12: 33.98795... (Windows doesn't show E/W)
> These values convert to:
> 38.616349536627
> -90.2094410978095
> When I use the getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast
> methods, I get the following values:
> 38.5993060156
> -90.19239757679365
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MATH-1624) Consolidate test suite
Gilles Sadowski created MATH-1624:
-
Summary: Consolidate test suite
Key: MATH-1624
URL: https://issues.apache.org/jira/browse/MATH-1624
Project: Commons Math
Issue Type: Sub-task
Reporter: Gilles Sadowski
Fix For: 4.0
Add more [functions|https://www.sfu.ca/~ssurjano/optimization.html] to
[{{TestFunction}}|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-legacy/src/test/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/TestFunction.java;h=798ada191b8045f7e80819da30af5225aa15d26c;hb=HEAD].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-numbers] coveralls edited a comment on pull request #104: Improvements:
coveralls edited a comment on pull request #104: URL: https://github.com/apache/commons-numbers/pull/104#issuecomment-894756317 [](https://coveralls.io/builds/42029599) Coverage remained the same at 99.658% when pulling **c75965e49ec85aa60a3bdf02e09d59ed6cf9b3e1 on arturobernalg:feature/improvement** into **84c70907bcc795d0dbfea1bfcb919aa2b746d3e0 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (RNG-127) Assess future compatibility with JEP 356: Enhanced Pseudo-Random Number Generators
[
https://issues.apache.org/jira/browse/RNG-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396611#comment-17396611
]
Gilles Sadowski commented on RNG-127:
-
[Javadoc|https://cr.openjdk.java.net/~iris/se/17/build/latest/api/java.base/java/util/random/package-summary.html]
of the new {{java.util.random}} package.
> Assess future compatibility with JEP 356: Enhanced Pseudo-Random Number
> Generators
> ---
>
> Key: RNG-127
> URL: https://issues.apache.org/jira/browse/RNG-127
> Project: Commons RNG
> Issue Type: Task
> Components: client-api
>Affects Versions: 1.3
>Reporter: Alex Herbert
>Priority: Minor
>
> JEP 356 specifies an enhancement to the random number generators. This is
> targeted to JDK 17.
> [JEP 356: Enhanced Pseudo-Random Number
> Generators|https://openjdk.java.net/jeps/356]
> The enhancement will add interfaces to the JDK for random number generation:
> * SplittableRandomGenerator extends RandomGenerator and also provides
> methods named split and splits. Splittability allows the user to spawn a new
> RandomGenerator from an existing RandomGenerator that will generally produce
> statistically independent results.
> * JumpableRandomGenerator extends RandomGenerator and also provides
> methods named jump and jumps. Jumpability allows a user to jump ahead a
> moderate number of draws.
> * LeapableRandomGenerator extends RandomGenerator and also provides
> methods named leap and leaps. Leapability allows a user to jump ahead a
> large number of draws.
> * ArbitrarilyJumpableRandomGenerator extends LeapableRandomGenerator and
> also provides additional variations of jump and jumps that allow an arbitrary
> jump distance to be specified.
> The specification describes the development of abstract classes that would
> allow different algorithms to be easily implemented by developers and used
> with a Java application through a common interface. This would replicate the
> functionality of the Common RNG API and core modules within the JDK.
> The JDK interfaces should be compared with the current client API in Commons
> RNG with the aim to assess:
> # Compatibility
> # Potential to back-port functionality
> JEP 356 also mentions the implementation of the LXM family of RNGs and a
> change to the algorithm used by SplittableRandom to address two weaknesses
> identified in 2016. These could be included in the current codebase pending
> license compatibility checks.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-codec] coveralls commented on pull request #89: Improvements:
coveralls commented on pull request #89: URL: https://github.com/apache/commons-codec/pull/89#issuecomment-895951221 [](https://coveralls.io/builds/42030408) Coverage decreased (-0.009%) to 94.673% when pulling **99a80e80b1ea107658c5a7e7dc31b409bd6da20d on arturobernalg:feature/improvements** into **b7ba05ad6b99ae9d5f93cd18e936b3e8908202fb on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (RNG-127) Assess future compatibility with JEP 356: Enhanced Pseudo-Random Number Generators
[
https://issues.apache.org/jira/browse/RNG-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396626#comment-17396626
]
Gilles Sadowski commented on RNG-127:
-
bq. is creating by name the only mechanism to obtain a specific generator.
No but that's the one likely to be used by most users (casual use would be
through the
[{{getDefault()}}|https://cr.openjdk.java.net/~iris/se/17/build/latest/api/java.base/java/util/random/RandomGeneratorFactory.html#getDefault()]
method). The other way is to get
[all|https://cr.openjdk.java.net/~iris/se/17/build/latest/api/java.base/java/util/random/RandomGeneratorFactory.html#all()]
the available implementations and use the stream API to filter on various
[properties|https://cr.openjdk.java.net/~iris/se/17/build/latest/api/java.base/java/util/random/RandomGeneratorFactory.html]
(e.g. [state
size|https://cr.openjdk.java.net/~iris/se/17/build/latest/api/java.base/java/util/random/RandomGeneratorFactory.html#stateBits()]).
I'd think that the first step is to add the property methods to
{{RandomSource}}.
> Assess future compatibility with JEP 356: Enhanced Pseudo-Random Number
> Generators
> ---
>
> Key: RNG-127
> URL: https://issues.apache.org/jira/browse/RNG-127
> Project: Commons RNG
> Issue Type: Task
> Components: client-api
>Affects Versions: 1.3
>Reporter: Alex Herbert
>Priority: Minor
>
> JEP 356 specifies an enhancement to the random number generators. This is
> targeted to JDK 17.
> [JEP 356: Enhanced Pseudo-Random Number
> Generators|https://openjdk.java.net/jeps/356]
> The enhancement will add interfaces to the JDK for random number generation:
> * SplittableRandomGenerator extends RandomGenerator and also provides
> methods named split and splits. Splittability allows the user to spawn a new
> RandomGenerator from an existing RandomGenerator that will generally produce
> statistically independent results.
> * JumpableRandomGenerator extends RandomGenerator and also provides
> methods named jump and jumps. Jumpability allows a user to jump ahead a
> moderate number of draws.
> * LeapableRandomGenerator extends RandomGenerator and also provides
> methods named leap and leaps. Leapability allows a user to jump ahead a
> large number of draws.
> * ArbitrarilyJumpableRandomGenerator extends LeapableRandomGenerator and
> also provides additional variations of jump and jumps that allow an arbitrary
> jump distance to be specified.
> The specification describes the development of abstract classes that would
> allow different algorithms to be easily implemented by developers and used
> with a Java application through a common interface. This would replicate the
> functionality of the Common RNG API and core modules within the JDK.
> The JDK interfaces should be compared with the current client API in Commons
> RNG with the aim to assess:
> # Compatibility
> # Potential to back-port functionality
> JEP 356 also mentions the implementation of the LXM family of RNGs and a
> change to the algorithm used by SplittableRandom to address two weaknesses
> identified in 2016. These could be included in the current codebase pending
> license compatibility checks.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] blecher-at opened a new pull request #216: COMPRESS-582: update harmony to ASM >= 7.0
blecher-at opened a new pull request #216: URL: https://github.com/apache/commons-compress/pull/216 fix for https://issues.apache.org/jira/projects/COMPRESS/issues/COMPRESS-582 Upgrades the newly included harmony pack200 classes to support ASM >= 7.0 Earlier Versions (4-6) fail the unittests. To test with most recent asm version, run ./mvnw test -Dasm.version=9.2 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COMPRESS-582) Pack200CompressorOutputStream fails at runtime in 1.21 if ASM 4.0+ is used
[
https://issues.apache.org/jira/browse/COMPRESS-582?focusedWorklogId=636437&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-636437
]
ASF GitHub Bot logged work on COMPRESS-582:
---
Author: ASF GitHub Bot
Created on: 10/Aug/21 12:48
Start Date: 10/Aug/21 12:48
Worklog Time Spent: 10m
Work Description: blecher-at opened a new pull request #216:
URL: https://github.com/apache/commons-compress/pull/216
fix for https://issues.apache.org/jira/projects/COMPRESS/issues/COMPRESS-582
Upgrades the newly included harmony pack200 classes to support ASM >= 7.0
Earlier Versions (4-6) fail the unittests.
To test with most recent asm version, run ./mvnw test -Dasm.version=9.2
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 636437)
Remaining Estimate: 0h
Time Spent: 10m
> Pack200CompressorOutputStream fails at runtime in 1.21 if ASM 4.0+ is used
> --
>
> Key: COMPRESS-582
> URL: https://issues.apache.org/jira/browse/COMPRESS-582
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: Alex Landau
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I just tried to upgrade an existing codebase to commons-compress 1.21 (from
> 1.20, which was working correctly) and encountered the following error in
> code trying to use the Pack200CompressorOutputStream:
> {code:java}
> java.lang.IncompatibleClassChangeError: class
> org.apache.commons.compress.harmony.pack200.Segment can not implement
> org.objectweb.asm.ClassVisitor, because it is not an interface
> (org.objectweb.asm.ClassVisitor is in unnamed module of loader 'app')
> {code}
> The Segment class {{implements}} rather than {{extends}} ClassVisitor. It
> looks like commons-compress is built against asm 3.2. Per
> [https://asm.ow2.io/versions.html], ClassVisitor was converted from an
> interface to an abstract class in asm 4.0, which was released in 2011, "in
> order to ensure backward binary compatibility in future ASM versions". To be
> clear, our project needs a more recent asm version on the classpath to
> support other libraries.
> I have a repro of the error here, in case it helps:
> [https://github.com/AlexLandau/commons-compress-asm-error]
> I want to add that I appreciate the effort you are making to support pack200
> in a way that will outlast the JDK's native support.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-582) Pack200CompressorOutputStream fails at runtime in 1.21 if ASM 4.0+ is used
[
https://issues.apache.org/jira/browse/COMPRESS-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396657#comment-17396657
]
Stephan Blecher commented on COMPRESS-582:
--
patch for this [https://github.com/apache/commons-compress/pull/216]
_unfortunately_ the fix only works for asm7.0 and above, but this should cover
most usecases.
> Pack200CompressorOutputStream fails at runtime in 1.21 if ASM 4.0+ is used
> --
>
> Key: COMPRESS-582
> URL: https://issues.apache.org/jira/browse/COMPRESS-582
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: Alex Landau
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I just tried to upgrade an existing codebase to commons-compress 1.21 (from
> 1.20, which was working correctly) and encountered the following error in
> code trying to use the Pack200CompressorOutputStream:
> {code:java}
> java.lang.IncompatibleClassChangeError: class
> org.apache.commons.compress.harmony.pack200.Segment can not implement
> org.objectweb.asm.ClassVisitor, because it is not an interface
> (org.objectweb.asm.ClassVisitor is in unnamed module of loader 'app')
> {code}
> The Segment class {{implements}} rather than {{extends}} ClassVisitor. It
> looks like commons-compress is built against asm 3.2. Per
> [https://asm.ow2.io/versions.html], ClassVisitor was converted from an
> interface to an abstract class in asm 4.0, which was released in 2011, "in
> order to ensure backward binary compatibility in future ASM versions". To be
> clear, our project needs a more recent asm version on the classpath to
> support other libraries.
> I have a repro of the error here, in case it helps:
> [https://github.com/AlexLandau/commons-compress-asm-error]
> I want to add that I appreciate the effort you are making to support pack200
> in a way that will outlast the JDK's native support.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IMAGING-285) Decoding of Rational Numbers broken when large values present
[ https://issues.apache.org/jira/browse/IMAGING-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396661#comment-17396661 ] Gary Lucas commented on IMAGING-285: > Is there some particular feature that would prevent that the latter [Commons >Numbers] be a replacement for the former [existing code]? It's not that at all. I looked at Commons Numbers, and there's a lot to like about it. I really hope you see widespread adoption. In the case of Commons Imaging, I think that the issue is one of project dependencies. I caveat this with saying that I am not in charge of Commons Imaging, so I don't speak for the project. But I am reluctant to add any new dependencies to what should be just a single component API for developers to drop into to their applications. Also, Imaging's RationalNumber class is small enough that there isn't a strong motivation to depend on an external project even though that project would be almost certainly be more carefully written and maintained than the single, specialized class in Commons Imaging. Interestingly, the TIFF standard does not specify the arithmetic to be used for rational numbers. It calls for specifying real numbers using two unsigned 32-bit integers. Let's call them a and b. So the meaning of the computed floating point value (double)a/(double)b is pretty unambiguous. But the Commons Imaging RationalNumber class also has a method that returns the integer value a/b. The TIFF standard doesn't say anything about round-off. But maybe (a+b/2)/b might have been a better solution? I personally think so, but I am not about to mess with the way the code has always worked. At the same time, I have to say that one clear advantage of Commons Numbers is that It would "fill in the blanks" where there were gaps in the specification. Since Numbers specializes in things that Imaging merely uses, I'm sure you guys have worked through the details on operations like that. > Decoding of Rational Numbers broken when large values present > - > > Key: IMAGING-285 > URL: https://issues.apache.org/jira/browse/IMAGING-285 > Project: Commons Imaging > Issue Type: Bug > Components: imaging.common.* >Affects Versions: 1.0-alpha2 >Reporter: John Andrade >Priority: Major > Attachments: DJI_0267 cropped.JPG > > Original Estimate: 1h > Remaining Estimate: 1h > > Decoding Lat/Long EXIF data from JPEGs does not work for some values. I have > attached a file where the conversion fails. I used the > getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast methods from the > TiffImageMetaData.GPSInfo class. The values are close, but seemingly off by > a few miles. > I've traced the source and I believe the issue is with how the RationalNumber > class uses two 32-bit signed integers for the numerator and denominator. The > definition of a RATIONAL data type uses 32-bit unsigned numbers. It seems as > if the RationalNumber class already expects this as it has a non-public > static method called factoryMethod to create a RationalNumber from two 64-bit > numbers. > This error is introduced in the ByteConversions class, specifically the > toRational method where it uses the regular RationalNumber constructor and > thus ensures any rational numbers that have numerator or denominator greater > than the max signed 32-bit value will produce invalid values. > I am attaching a JPEG that has this problem. I had to crop it to reduce the > size, but the EXIF data was preserved. > The EXIF GPS data contained in the JPEG is: > GpsLatitudeRef: "N" > GpsLatitude: 38, 1, 36, 1, 4120083230, 7000 > GpsLongitudeRef: "W" > GpsLongitude: 90, 1, 12, 1, 2379156648, 7000 > According to the properties of the image (right-clicking on Windows 10), the > L/L of the image is: > Latitude: 38: 36: 58.85833 > Longitude: 90: 12: 33.98795... (Windows doesn't show E/W) > These values convert to: > 38.616349536627 > -90.2094410978095 > When I use the getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast > methods, I get the following values: > 38.5993060156 > -90.19239757679365 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (COMPRESS-244) 7z reading of UINT64 data type is wrong for big values
[
https://issues.apache.org/jira/browse/COMPRESS-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Drew Foulks updated COMPRESS-244:
-
Reporter: Nico Kruber (was: Nico Kruber)
> 7z reading of UINT64 data type is wrong for big values
> --
>
> Key: COMPRESS-244
> URL: https://issues.apache.org/jira/browse/COMPRESS-244
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.6
>Reporter: Nico Kruber
>Priority: Major
> Labels: 7z, easyfix, patch
> Fix For: 1.7
>
> Attachments: fix-readUint64-for-large-values.diff
>
>
> h2. Brief description
> large values with a first byte indicating at least 4 additional bytes shift
> an integer by at least 32bits thus leading to an overflow and an incorrect
> value - the value needs to be casted to long before the bitshift!
> (see the attached patch)
> h2. Details from the 7z documentation
> {quote}
> {noformat}
> UINT64 means real UINT64 encoded with the following scheme:
> Size of encoding sequence depends from first byte:
> First_Byte Extra_BytesValue
> (binary)
> 0xxx : ( xxx )
> 10xxBYTE y[1] : ( xx << (8 * 1)) + y
> 110xBYTE y[2] : ( x << (8 * 2)) + y
> ...
> 110xBYTE y[6] : ( x << (8 * 6)) + y
> 1110BYTE y[7] : y
> BYTE y[8] : y
> {noformat}
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] garydgregory merged pull request #216: COMPRESS-582: update harmony to ASM >= 7.0
garydgregory merged pull request #216: URL: https://github.com/apache/commons-compress/pull/216 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COMPRESS-582) Pack200CompressorOutputStream fails at runtime in 1.21 if ASM 4.0+ is used
[
https://issues.apache.org/jira/browse/COMPRESS-582?focusedWorklogId=636460&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-636460
]
ASF GitHub Bot logged work on COMPRESS-582:
---
Author: ASF GitHub Bot
Created on: 10/Aug/21 14:04
Start Date: 10/Aug/21 14:04
Worklog Time Spent: 10m
Work Description: garydgregory merged pull request #216:
URL: https://github.com/apache/commons-compress/pull/216
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 636460)
Time Spent: 20m (was: 10m)
> Pack200CompressorOutputStream fails at runtime in 1.21 if ASM 4.0+ is used
> --
>
> Key: COMPRESS-582
> URL: https://issues.apache.org/jira/browse/COMPRESS-582
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: Alex Landau
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I just tried to upgrade an existing codebase to commons-compress 1.21 (from
> 1.20, which was working correctly) and encountered the following error in
> code trying to use the Pack200CompressorOutputStream:
> {code:java}
> java.lang.IncompatibleClassChangeError: class
> org.apache.commons.compress.harmony.pack200.Segment can not implement
> org.objectweb.asm.ClassVisitor, because it is not an interface
> (org.objectweb.asm.ClassVisitor is in unnamed module of loader 'app')
> {code}
> The Segment class {{implements}} rather than {{extends}} ClassVisitor. It
> looks like commons-compress is built against asm 3.2. Per
> [https://asm.ow2.io/versions.html], ClassVisitor was converted from an
> interface to an abstract class in asm 4.0, which was released in 2011, "in
> order to ensure backward binary compatibility in future ASM versions". To be
> clear, our project needs a more recent asm version on the classpath to
> support other libraries.
> I have a repro of the error here, in case it helps:
> [https://github.com/AlexLandau/commons-compress-asm-error]
> I want to add that I appreciate the effort you are making to support pack200
> in a way that will outlast the JDK's native support.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] dependabot[bot] commented on pull request #211: Bump asm from 3.2 to 3.3.1
dependabot[bot] commented on pull request #211: URL: https://github.com/apache/commons-compress/pull/211#issuecomment-896057289 Looks like asm:asm is no longer a dependency, so this is no longer needed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] dependabot[bot] closed pull request #211: Bump asm from 3.2 to 3.3.1
dependabot[bot] closed pull request #211: URL: https://github.com/apache/commons-compress/pull/211 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (FILEUPLOAD-339) OWASP - Dependency-Check found vulnerable dependencies.
Paulo Machado created FILEUPLOAD-339: Summary: OWASP - Dependency-Check found vulnerable dependencies. Key: FILEUPLOAD-339 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-339 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.4 Reporter: Paulo Machado Hi guys, We have a vulnerability when we use commons-io 2.2: [https://nvd.nist.gov/vuln/detail/CVE-2021-35515] Could you update it for the latest one, please? Thank you! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (COMPRESS-582) Pack200CompressorOutputStream fails at runtime in 1.21 if ASM 4.0+ is used
[
https://issues.apache.org/jira/browse/COMPRESS-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved COMPRESS-582.
--
Fix Version/s: 1.22
Resolution: Fixed
Please see git master.
> Pack200CompressorOutputStream fails at runtime in 1.21 if ASM 4.0+ is used
> --
>
> Key: COMPRESS-582
> URL: https://issues.apache.org/jira/browse/COMPRESS-582
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: Alex Landau
>Priority: Major
> Fix For: 1.22
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I just tried to upgrade an existing codebase to commons-compress 1.21 (from
> 1.20, which was working correctly) and encountered the following error in
> code trying to use the Pack200CompressorOutputStream:
> {code:java}
> java.lang.IncompatibleClassChangeError: class
> org.apache.commons.compress.harmony.pack200.Segment can not implement
> org.objectweb.asm.ClassVisitor, because it is not an interface
> (org.objectweb.asm.ClassVisitor is in unnamed module of loader 'app')
> {code}
> The Segment class {{implements}} rather than {{extends}} ClassVisitor. It
> looks like commons-compress is built against asm 3.2. Per
> [https://asm.ow2.io/versions.html], ClassVisitor was converted from an
> interface to an abstract class in asm 4.0, which was released in 2011, "in
> order to ensure backward binary compatibility in future ASM versions". To be
> clear, our project needs a more recent asm version on the classpath to
> support other libraries.
> I have a repro of the error here, in case it helps:
> [https://github.com/AlexLandau/commons-compress-asm-error]
> I want to add that I appreciate the effort you are making to support pack200
> in a way that will outlast the JDK's native support.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IMAGING-285) Decoding of Rational Numbers broken when large values present
[
https://issues.apache.org/jira/browse/IMAGING-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396721#comment-17396721
]
Gilles Sadowski commented on IMAGING-285:
-
bq. [Imaging] should be just a single component API for developers
Is {{RationalNumber}} part of the API (directly) accessed by users of the
library, or merely a "utility" (i.e. for "internal" use)?
In either way, {{RationalNumber}} could delegate to {{Fraction}}...
bq. the issue is one of project dependencies.
With all "Commons" components following a "no JAR hell" policy, what would be
the issue?
bq. {{RationalNumber}} class is small enough that there isn't a strong
motivation to depend on an external project [...]
IMHO, this bug report is a good motivation.
Every project (including "Commons Numbers") that is duplicating functionality
is bound to go through the same bugs with its "small enough" classes.
"Commons" is _the_ project and the "Imaging" team can directly watch for
unwanted impact of changes in "Numbers" (e.g. through Jenkins).
> Decoding of Rational Numbers broken when large values present
> -
>
> Key: IMAGING-285
> URL: https://issues.apache.org/jira/browse/IMAGING-285
> Project: Commons Imaging
> Issue Type: Bug
> Components: imaging.common.*
>Affects Versions: 1.0-alpha2
>Reporter: John Andrade
>Priority: Major
> Attachments: DJI_0267 cropped.JPG
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Decoding Lat/Long EXIF data from JPEGs does not work for some values. I have
> attached a file where the conversion fails. I used the
> getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast methods from the
> TiffImageMetaData.GPSInfo class. The values are close, but seemingly off by
> a few miles.
> I've traced the source and I believe the issue is with how the RationalNumber
> class uses two 32-bit signed integers for the numerator and denominator. The
> definition of a RATIONAL data type uses 32-bit unsigned numbers. It seems as
> if the RationalNumber class already expects this as it has a non-public
> static method called factoryMethod to create a RationalNumber from two 64-bit
> numbers.
> This error is introduced in the ByteConversions class, specifically the
> toRational method where it uses the regular RationalNumber constructor and
> thus ensures any rational numbers that have numerator or denominator greater
> than the max signed 32-bit value will produce invalid values.
> I am attaching a JPEG that has this problem. I had to crop it to reduce the
> size, but the EXIF data was preserved.
> The EXIF GPS data contained in the JPEG is:
> GpsLatitudeRef: "N"
> GpsLatitude: 38, 1, 36, 1, 4120083230, 7000
> GpsLongitudeRef: "W"
> GpsLongitude: 90, 1, 12, 1, 2379156648, 7000
> According to the properties of the image (right-clicking on Windows 10), the
> L/L of the image is:
> Latitude: 38: 36: 58.85833
> Longitude: 90: 12: 33.98795... (Windows doesn't show E/W)
> These values convert to:
> 38.616349536627
> -90.2094410978095
> When I use the getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast
> methods, I get the following values:
> 38.5993060156
> -90.19239757679365
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MATH-1622) "SimplexOptimizer" hybridation with simulated annealing
[
https://issues.apache.org/jira/browse/MATH-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396732#comment-17396732
]
Gilles Sadowski commented on MATH-1622:
---
Tests introduced in commit 9fd6725d51e1106e3b07222bf11a96e2f2ca7b61 ("master"
branch).
Performance is far from the results reported in the paper on the algorithm:
* in some cases the number of function evaluations is way too large,
* in others, the optimum is rarely found (cases commented out in the unit test
[input
file|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-legacy/src/test/resources/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/std_test_func.simplex.hedar_fukushima.csv;h=e867df5ebd45fe7379ac46b7e0898353053296e2;hb=HEAD]).
To be investigated...
> "SimplexOptimizer" hybridation with simulated annealing
> ---
>
> Key: MATH-1622
> URL: https://issues.apache.org/jira/browse/MATH-1622
> Project: Commons Math
> Issue Type: Wish
>Reporter: Gilles Sadowski
>Priority: Minor
> Fix For: 4.0
>
>
> It is proposed to modify the API of [simplex-based
> optimization|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java;h=d95123d8f62ec029f1bd0190ca3c17d028ee9a64;hb=46a0c3ae4140fd34cf8479362192bddb7b7b3e38]
> in order to allow the [simplex transformation
> rule|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/Simplex.java;h=46345c3b7a5c6784a3afda33b490a1bd6a2ce1a3;hb=46a0c3ae4140fd34cf8479362192bddb7b7b3e38#l299]
> to retain less fit states with some probability, as per the "simulated
> annealing" heuristics.
> A {{SimulatedAnnealing}} class will implement
> [{{OptimizationData}}|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/OptimizationData.java;h=adb42ee040852971594520777ece3391e19052a8;hb=46a0c3ae4140fd34cf8479362192bddb7b7b3e38].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-imaging] coveralls commented on pull request #159: [IMAGING-308] Run CI tests on Windows
coveralls commented on pull request #159: URL: https://github.com/apache/commons-imaging/pull/159#issuecomment-896225438 [](https://coveralls.io/builds/42031312) Coverage remained the same at 76.725% when pulling **8b3b0ceba23ffda97375a15be51ee7ec2ca1385a on kinow:test-windows** into **a87b545e1019b43bfbe31fa5df3a4f3095a8b438 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IMAGING-308) Build failing on Windows (IptcParserTest)
[
https://issues.apache.org/jira/browse/IMAGING-308?focusedWorklogId=636561&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-636561
]
ASF GitHub Bot logged work on IMAGING-308:
--
Author: ASF GitHub Bot
Created on: 10/Aug/21 18:40
Start Date: 10/Aug/21 18:40
Worklog Time Spent: 10m
Work Description: coveralls commented on pull request #159:
URL: https://github.com/apache/commons-imaging/pull/159#issuecomment-896225438
[](https://coveralls.io/builds/42031312)
Coverage remained the same at 76.725% when pulling
**8b3b0ceba23ffda97375a15be51ee7ec2ca1385a on kinow:test-windows** into
**a87b545e1019b43bfbe31fa5df3a4f3095a8b438 on apache:master**.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 636561)
Remaining Estimate: 0h
Time Spent: 10m
> Build failing on Windows (IptcParserTest)
> -
>
> Key: IMAGING-308
> URL: https://issues.apache.org/jira/browse/IMAGING-308
> Project: Commons Imaging
> Issue Type: Improvement
>Affects Versions: 1.0-alpha2
>Reporter: Bruno P. Kinoshita
>Priority: Blocker
> Fix For: 1.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
>
>
> {noformat}
> [ERROR] Failures:
> [ERROR] IptcParserTest.testEncodingSupport:104 array lengths differ,
> expected: <6> but was: <2>
> [INFO]
> [ERROR] Tests run: 940, Failures: 1, Errors: 0, Skipped: 8
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 04:52 min
> [INFO] Finished at: 2021-08-10T16:50:24+12:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project commons-imaging: There are test failures.
> [ERROR]
> [ERROR] Please refer to
> C:\Users\kinoshitabd\Development\java\apache\commons-imaging\target\surefire-reports
> for the individual test results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test
> (default-test) on project commons-imaging: There are test failures.Please
> refer to
> C:\Users\kinoshitabd\Development\java\apache\commons-imaging\target\surefire-reports
> for the individual test results.
> Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump
> and [date].dumpstream.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.ple
[jira] [Created] (EMAIL-198) Performance in ImageHtmlEmail
Jochen Wiedmann created EMAIL-198:
-
Summary: Performance in ImageHtmlEmail
Key: EMAIL-198
URL: https://issues.apache.org/jira/browse/EMAIL-198
Project: Commons Email
Issue Type: Improvement
Affects Versions: 1.5
Reporter: Jochen Wiedmann
Assignee: Jochen Wiedmann
Fix For: 1.6
In the class ImageHtmlEmail, there are two regular expressions
(REGEX_SCRIPT_SRC, and
REGEX_IMAGE_SRC), which can behave rather slow in exceptional cases, as
evidenced by
the following code snippet:
@Test
public void testSlowRegularExpressions() throws Exception {
ImageHtmlEmail mail = new ImageHtmlEmail();
mail.setHostName("example.com");
mail.setFrom("f...@example.com");
mail.addTo("t...@example.com");
StringBuilder text = new StringBuilder("" + text + "");
long startTime = System.currentTimeMillis();
mail.buildMimeMessage();
long duration = System.currentTimeMillis() - startTime;
assertTrue("Run time exceeds permitted duration of 50 seconds: " + duration,
duration < 100*1000);
}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MATH-1623) Create "@ParameterizedTest" for simplex-based optimizers
[ https://issues.apache.org/jira/browse/MATH-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Sadowski resolved MATH-1623. --- Resolution: Done > Create "@ParameterizedTest" for simplex-based optimizers > > > Key: MATH-1623 > URL: https://issues.apache.org/jira/browse/MATH-1623 > Project: Commons Math > Issue Type: Sub-task >Reporter: Gilles Sadowski >Assignee: Gilles Sadowski >Priority: Minor > Fix For: 4.0 > > > [Parameterized unit > tests|https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests] > would reduce boiler-plate code in > * > [SimplexOptimizerNelderMeadTest|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-legacy/src/test/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizerNelderMeadTest.java;h=e2ed7418b26ae403302964904415c31694b8fe0f;hb=HEAD] > * > [SimplexOptimizerMultiDirectionalTest|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-legacy/src/test/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizerMultiDirectionalTest.java;h=a652cfb2f151e6a164992950e68359a3235d47a5;hb=HEAD] > * > [SimplexOptimizerHedarFukushimaTest|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-legacy/src/test/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizerHedarFukushimaTest.java;h=9b266f411e05c1f36cf2e65db723596ec16c78a4;hb=HEAD] > It will clarify the optimizer variants' performance on [identical > problems|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-legacy/src/test/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/TestFunction.java;h=2dd7048d7bc2a578e747613e6e02d250cdf427af;hb=HEAD] > (e.g. to explore issue MATH-1552). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-numbers] aherbert commented on a change in pull request #104: Improvements:
aherbert commented on a change in pull request #104:
URL: https://github.com/apache/commons-numbers/pull/104#discussion_r686347673
##
File path:
commons-numbers-combinatorics/src/main/java/org/apache/commons/numbers/combinatorics/LogFactorial.java
##
@@ -41,7 +41,7 @@
*
* @param numValues Number of values of the function to compute.
* @param cache Cached values.
- * @throw IllegalArgumentException if {@code n < 0}.
+ * @throw CombinatoricsException if {@code n < 0}.
Review comment:
You have left this `CombinatoricsException` exposed in the API.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-numbers] aherbert commented on a change in pull request #103: Simplify boolean expressions with an simpler and equivalent.
aherbert commented on a change in pull request #103:
URL: https://github.com/apache/commons-numbers/pull/103#discussion_r686349494
##
File path:
commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Precision.java
##
@@ -182,7 +182,7 @@ public static boolean equalsIncludingNaN(float x, float y) {
final boolean yIsNan = Float.isNaN(y);
// Combine the booleans with bitwise OR
return (xIsNan | yIsNan) ?
-!(xIsNan ^ yIsNan) :
+xIsNan == yIsNan :
Review comment:
The formatting looks wrong here as you have 8 character indent and then
a 4 character indent on the line underneath. It should be:
```java
return (xIsNan | yIsNan) ?
xIsNan == yIsNan :
equals(x, y, maxUlps);
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-math] aherbert commented on a change in pull request #196: Simplify assertions with equivalent but more simple.
aherbert commented on a change in pull request #196:
URL: https://github.com/apache/commons-math/pull/196#discussion_r686369063
##
File path:
commons-math-legacy/src/test/java/org/apache/commons/math4/legacy/linear/Array2DRowRealMatrixTest.java
##
@@ -895,9 +895,9 @@ public void testEqualsAndHashCode() {
Assert.assertEquals(m.hashCode(), m1.hashCode());
Assert.assertEquals(m, m);
Assert.assertEquals(m, m1);
-Assert.assertFalse(m.equals(null));
-Assert.assertFalse(m.equals(mt));
-Assert.assertFalse(m.equals(new Array2DRowRealMatrix(bigSingular)));
+Assert.assertNotEquals(null, m);
Review comment:
`m` should be the first argument
##
File path:
commons-math-legacy-core/src/test/java/org/apache/commons/math4/legacy/core/PairTest.java
##
@@ -39,26 +39,26 @@ public void testAccessor2() {
// Check that both APIs refer to the same data.
-Assert.assertTrue(p.getFirst() == p.getKey());
-Assert.assertTrue(p.getSecond() == p.getValue());
+Assert.assertSame(p.getFirst(), p.getKey());
+Assert.assertSame(p.getSecond(), p.getValue());
}
@Test
public void testEquals() {
Pair p1 = new Pair<>(null, null);
-Assert.assertFalse(p1.equals(null));
+Assert.assertNotEquals(null, p1);
Review comment:
`p1` should be the first argument to allow the assert method to invoke
`p1.equals(null)`
##
File path:
commons-math-legacy/src/test/java/org/apache/commons/math4/legacy/linear/BlockFieldMatrixTest.java
##
@@ -1150,9 +1150,9 @@ public void testEqualsAndHashCode() {
Assert.assertEquals(m.hashCode(), m1.hashCode());
Assert.assertEquals(m, m);
Assert.assertEquals(m, m1);
-Assert.assertFalse(m.equals(null));
-Assert.assertFalse(m.equals(mt));
-Assert.assertFalse(m.equals(new BlockFieldMatrix<>(bigSingular)));
+Assert.assertNotEquals(null, m);
Review comment:
`m` should be the first argument
##
File path:
commons-math-legacy/src/test/java/org/apache/commons/math4/legacy/linear/SparseFieldMatrixTest.java
##
@@ -568,9 +568,9 @@ public void testEqualsAndHashCode() {
Assert.assertEquals(m.hashCode(), m1.hashCode());
Assert.assertEquals(m, m);
Assert.assertEquals(m, m1);
-Assert.assertFalse(m.equals(null));
-Assert.assertFalse(m.equals(mt));
-Assert.assertFalse(m.equals(createSparseMatrix(bigSingular)));
+Assert.assertNotEquals(null, m);
Review comment:
`m` should be the first argument
##
File path:
commons-math-legacy/src/test/java/org/apache/commons/math4/legacy/stat/descriptive/rank/PSquarePercentileTest.java
##
@@ -146,9 +146,9 @@ public void testMiscellaniousFunctionsInMarkers() {
Arrays.asList(new Double[] { 0.02, 1.18, 9.15, 21.91,
38.62 }), p);
// Markers equality
-Assert.assertTrue(markers.equals(markers));
-Assert.assertFalse(markers.equals(null));
-Assert.assertFalse(markers.equals(""));
+Assert.assertEquals(markers, markers);
+Assert.assertNotEquals(null, markers);
Review comment:
`markers` should be the first argument
##
File path:
commons-math-legacy/src/test/java/org/apache/commons/math4/legacy/linear/FieldMatrixImplTest.java
##
@@ -867,9 +867,9 @@ public void testEqualsAndHashCode() {
Assert.assertEquals(m.hashCode(), m1.hashCode());
Assert.assertEquals(m, m);
Assert.assertEquals(m, m1);
-Assert.assertFalse(m.equals(null));
-Assert.assertFalse(m.equals(mt));
-Assert.assertFalse(m.equals(new Array2DRowFieldMatrix<>(bigSingular)));
+Assert.assertNotEquals(null, m);
Review comment:
`m` should be the first argument
##
File path:
commons-math-legacy/src/test/java/org/apache/commons/math4/legacy/linear/BlockRealMatrixTest.java
##
@@ -1054,9 +1054,9 @@ public void testEqualsAndHashCode() {
Assert.assertEquals(m.hashCode(), m1.hashCode());
Assert.assertEquals(m, m);
Assert.assertEquals(m, m1);
-Assert.assertFalse(m.equals(null));
-Assert.assertFalse(m.equals(mt));
-Assert.assertFalse(m.equals(new BlockRealMatrix(bigSingular)));
+Assert.assertNotEquals(null, m);
Review comment:
`m` should be the first argument
##
File path:
commons-math-legacy/src/test/java/org/apache/commons/math4/legacy/stat/descriptive/rank/PSquarePercentileTest.java
##
@@ -321,8 +321,8 @@ public void testMarkerHeightWithHigherIndex() {
public void testPSquaredEqualsAndMin() {
PSquarePercentile ptile = new PSquarePercentile(0);
Assert.assertEquals(ptile, ptile);
-Assert.assertFalse(ptile.equals(null));
-Assert.assertFalse(ptile.equals(""));
+As
[jira] [Commented] (IMAGING-285) Decoding of Rational Numbers broken when large values present
[
https://issues.apache.org/jira/browse/IMAGING-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396933#comment-17396933
]
Gary Lucas commented on IMAGING-285:
I think that the suggestion of using Commons Numbers really belongs in a
separate Jira item as an "enhancement". For now I'm going to limit my changes
to the issue that I understand and save any undertakings of a broader scope for
future work.
As an addendum, it turns out that there are some clear pro's and con's for
Gilles Sadowski's position. I will start with the con.
It turns out that the Commons Numbers API shares the same problem as the
Commons Imaging code. The problem is that the TIFF specification for Rational
elements calls for rational numbers based on two _*unsigned*_ 32-bit integers.
But both Imaging's current RationalNumber class and Number's Fraction class
both assume inputs as signed integers. So computing the latitude using the
parameters from the sample EXIF data in the original post, we find:
{code:java}
int numerator = -174884066; // 0xf5937b1e
int denominator = 7000;
Fraction frac = Fraction.of(numerator, denominator);
System.out.println("frac="+frac.doubleValue());
// The "unsigned" approach-
long n = numerator &0xL;
long d = denominator&0xL;
double lat = (double)n/(double)d;
System.out.println("latitude = "+lat);
Results:
frac = -2.4983438
latitude = 58.85833185714286
{code}
Thus we see that Numbers has its own variation of the problem. Numbers does
have a class called BigInteger which could be used to deal with this. But to me
it seems a little bit over complicated for this requirement.
On the pro side of Mr. Sadowski's suggestion, it looks like the code in Numbers
has received a lot more focused development than the code in Imaging's
RationalNumber class. For example, looking at the code for the Imaging's
RationalNumber class, I spotted a shortcoming:
{code:java}
@Override
public float floatValue() {
return (float) numerator / (float) divisor;
}{code}
The shortcoming here is that an IEEE-754 standard 32-bit floating point value
has only 24 bits of precision in its mantissa while an unsigned integer has 32.
So some of that low-order digits in the numerator and denominator could be
thrown away by the cast even before the division operation is performed. A
better solution would be to do things the way Commons Numbers does, which would
be basically the following:
{code:java}
@Override
public float floatValue() {
return (float) doubleValue();
}
@Override
public double doubleValue() {
return (double) numerator / (double) divisor;
}
{code}
> Decoding of Rational Numbers broken when large values present
> -
>
> Key: IMAGING-285
> URL: https://issues.apache.org/jira/browse/IMAGING-285
> Project: Commons Imaging
> Issue Type: Bug
> Components: imaging.common.*
>Affects Versions: 1.0-alpha2
>Reporter: John Andrade
>Priority: Major
> Attachments: DJI_0267 cropped.JPG
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Decoding Lat/Long EXIF data from JPEGs does not work for some values. I have
> attached a file where the conversion fails. I used the
> getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast methods from the
> TiffImageMetaData.GPSInfo class. The values are close, but seemingly off by
> a few miles.
> I've traced the source and I believe the issue is with how the RationalNumber
> class uses two 32-bit signed integers for the numerator and denominator. The
> definition of a RATIONAL data type uses 32-bit unsigned numbers. It seems as
> if the RationalNumber class already expects this as it has a non-public
> static method called factoryMethod to create a RationalNumber from two 64-bit
> numbers.
> This error is introduced in the ByteConversions class, specifically the
> toRational method where it uses the regular RationalNumber constructor and
> thus ensures any rational numbers that have numerator or denominator greater
> than the max signed 32-bit value will produce invalid values.
> I am attaching a JPEG that has this problem. I had to crop it to reduce the
> size, but the EXIF data was preserved.
> The EXIF GPS data contained in the JPEG is:
> GpsLatitudeRef: "N"
> GpsLatitude: 38, 1, 36, 1, 4120083230, 7000
> GpsLongitudeRef: "W"
> GpsLongitude: 90, 1, 12, 1, 2379156648, 7000
> According to the properties of the image (right-clicking on Windows 10), the
> L/L of the image is:
> Latitude: 38: 36: 58.85833
> Longitude: 90: 12: 33.98795... (Windows doesn't show E/W)
> These values convert to:
> 38.616349536627
> -90.2094410978095
> When I use the getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast
>
[GitHub] [commons-compress] PeterAlfredLee commented on pull request #214: [COMPRESS-584] Fix IOUtils.readRange() can read more from a channel than asked for
PeterAlfredLee commented on pull request #214: URL: https://github.com/apache/commons-compress/pull/214#issuecomment-896453094 Hi @matthijsln I want to merge this PR first. The current implementation didn't change much from original implemention. I will investigate into the "no copy buffer" implementation later when I can curve out some time. Thank you for your contributions! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COMPRESS-584) IOUtils.readRange() can read more from a channel than asked for
[
https://issues.apache.org/jira/browse/COMPRESS-584?focusedWorklogId=636709&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-636709
]
ASF GitHub Bot logged work on COMPRESS-584:
---
Author: ASF GitHub Bot
Created on: 11/Aug/21 02:33
Start Date: 11/Aug/21 02:33
Worklog Time Spent: 10m
Work Description: PeterAlfredLee commented on pull request #214:
URL: https://github.com/apache/commons-compress/pull/214#issuecomment-896453094
Hi @matthijsln
I want to merge this PR first. The current implementation didn't change much
from original implemention.
I will investigate into the "no copy buffer" implementation later when I can
curve out some time.
Thank you for your contributions!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 636709)
Time Spent: 5h (was: 4h 50m)
> IOUtils.readRange() can read more from a channel than asked for
> ---
>
> Key: COMPRESS-584
> URL: https://issues.apache.org/jira/browse/COMPRESS-584
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Matthijs Laan
>Assignee: Peter Lee
>Priority: Major
> Time Spent: 5h
> Remaining Estimate: 0h
>
> When {{IOUtils.readRange(ReadableByteChannel,int)}} gets less than the number
> of bytes asked for in the first read call it does not reduce the buffer size
> for the next read call and may read more than asked for.
> This situation is rare when using a {{FileChannel}} but I wrote a
> {{SeekableByteChannel}} backed by a URI using HTTP range requests and reading
> from a socket can often return less bytes than asked for. When I used this
> channel to read a {{ZipFile}} it only read the ZIP central directory
> partially sometimes because {{IOUtils.readRange()}} called from
> {{ZipFile.readCentralDirectoryEntry()}} read more bytes than asked for and it
> stopped parsing directory entries.
> Fix: [https://github.com/apache/commons-compress/pull/214]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] PeterAlfredLee merged pull request #214: [COMPRESS-584] Fix IOUtils.readRange() can read more from a channel than asked for
PeterAlfredLee merged pull request #214: URL: https://github.com/apache/commons-compress/pull/214 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COMPRESS-584) IOUtils.readRange() can read more from a channel than asked for
[
https://issues.apache.org/jira/browse/COMPRESS-584?focusedWorklogId=636710&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-636710
]
ASF GitHub Bot logged work on COMPRESS-584:
---
Author: ASF GitHub Bot
Created on: 11/Aug/21 02:35
Start Date: 11/Aug/21 02:35
Worklog Time Spent: 10m
Work Description: PeterAlfredLee merged pull request #214:
URL: https://github.com/apache/commons-compress/pull/214
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 636710)
Time Spent: 5h 10m (was: 5h)
> IOUtils.readRange() can read more from a channel than asked for
> ---
>
> Key: COMPRESS-584
> URL: https://issues.apache.org/jira/browse/COMPRESS-584
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Matthijs Laan
>Assignee: Peter Lee
>Priority: Major
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> When {{IOUtils.readRange(ReadableByteChannel,int)}} gets less than the number
> of bytes asked for in the first read call it does not reduce the buffer size
> for the next read call and may read more than asked for.
> This situation is rare when using a {{FileChannel}} but I wrote a
> {{SeekableByteChannel}} backed by a URI using HTTP range requests and reading
> from a socket can often return less bytes than asked for. When I used this
> channel to read a {{ZipFile}} it only read the ZIP central directory
> partially sometimes because {{IOUtils.readRange()}} called from
> {{ZipFile.readCentralDirectoryEntry()}} read more bytes than asked for and it
> stopped parsing directory entries.
> Fix: [https://github.com/apache/commons-compress/pull/214]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
