Re: [geos-devel] 3.12.0beta2
Beta 2 works as expected with GEOSwift. Sent via Superhuman ( https://sprh.mn/?vip=andrew.d.hershber...@gmail.com ) On Thu, Jun 15, 2023 at 3:24 PM, Paul Ramsey < pram...@cleverelephant.ca > wrote: > > >> >> >> On Jun 15, 2023, at 12:18 PM, Sean Gillies < sean. gillies@ gmail. com ( >> sean.gill...@gmail.com ) > wrote: >> >> >> >> The GEOSMinimumRotatedEnvelope algorithm change affects some Shapely >> tests, but I don't see any other problems. We're likely to change the >> tests to match the new implementation. >> >> > > > > Super! Yes, this new implementation is “different but better” than the old > one. We had some tickets that explicitly pointed out places the old one > was wrong. > > > > P > > > > ___ > geos-devel mailing list > geos-devel@ lists. osgeo. org ( geos-devel@lists.osgeo.org ) > https:/ / lists. osgeo. org/ mailman/ listinfo/ geos-devel ( > https://lists.osgeo.org/mailman/listinfo/geos-devel ) > > >___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta2
> On Jun 15, 2023, at 12:18 PM, Sean Gillies wrote: > > The GEOSMinimumRotatedEnvelope algorithm change affects some Shapely tests, > but I don't see any other problems. We're likely to change the tests to match > the new implementation. Super! Yes, this new implementation is “different but better” than the old one. We had some tickets that explicitly pointed out places the old one was wrong. P ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta2
Hi Paul, The GEOSMinimumRotatedEnvelope algorithm change affects some Shapely tests, but I don't see any other problems. We're likely to change the tests to match the new implementation. Beta2 looks good from here! On Wed, Jun 14, 2023 at 2:01 PM Paul Ramsey wrote: > Thank you everyone who tested and gave feedback on the first beta > release. Having incorporated all the feedback thus far, the next beta > is available: > > https://download.osgeo.org/geos/geos-3.12.0beta2.tar.bz2 > > Thanks again, > P > -- Sean Gillies ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta2
"Regina Obe" writes: >> On Thu, Jun 15, 2023 at 6:30 AM Greg Troxel wrote: >> >> > Looking at the logs (at end), overall this smells like either a >> > systematic issue where the floating point on my system is broken, or >> > there is some slight floating point difference from x86, and geos >> > tests are very sensitive to exact FP results. But that's just guessing. >> >> In terms of CI, it's linux/windows/macos all on Intel. In terms of >> development, >> there's me on MacOS AppleSilicon, so getting a little >> Arm64 in there. It's possible there's something special about the floating >> point >> in the RPI3, but there's also a failure in unit-io-GeoJSONReader in there, >> which >> ... is not doing any heavy lifting. So I duno. As with other fun platforms >> I'm >> always open to patches. :) > > We do have 2 rasberry Pis (Arm64 and Arm32) running debian bullseye testing - > berrie and berrie64 > And those look to be showing successes. But not sure about the endian. > > https://libgeos.org/project/development/ci_status/ Interesting. Raspberry Pi culture is very much to run LE, and I have never heard of Debian doing BE on RPI. NetBSD people do occasionally, just to be difficult, I mean to help with testing. > I think we've had issues in past specific to big endian. I would expect so absent testing. Someday(tm) I will have an emulated sparc64 to run tests on. For now, I think the project should just keep my report in mind in case there are similar, but I don't think it's reasonable to ask anyone to do anything, mostly. My only suggestion for the CI page is: Avoid using '32-bit' and '64-bit' as if that describes a CPU type, using i386/x86_64 for PCs and armv7/aarch64 (or some such) for RPI/ARM. but that's just being picky about wording, not anything real. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta2
> On Thu, Jun 15, 2023 at 6:30 AM Greg Troxel wrote: > > > Looking at the logs (at end), overall this smells like either a > > systematic issue where the floating point on my system is broken, or > > there is some slight floating point difference from x86, and geos > > tests are very sensitive to exact FP results. But that's just guessing. > > In terms of CI, it's linux/windows/macos all on Intel. In terms of > development, > there's me on MacOS AppleSilicon, so getting a little > Arm64 in there. It's possible there's something special about the floating > point > in the RPI3, but there's also a failure in unit-io-GeoJSONReader in there, > which > ... is not doing any heavy lifting. So I duno. As with other fun platforms I'm > always open to patches. :) > > P We do have 2 rasberry Pis (Arm64 and Arm32) running debian bullseye testing - berrie and berrie64 And those look to be showing successes. But not sure about the endian. https://libgeos.org/project/development/ci_status/ I think we've had issues in past specific to big endian. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta2
On Thu, Jun 15, 2023 at 6:30 AM Greg Troxel wrote: > Looking at the logs (at end), overall this smells like either a > systematic issue where the floating point on my system is broken, or > there is some slight floating point difference from x86, and geos tests > are very sensitive to exact FP results. But that's just guessing. In terms of CI, it's linux/windows/macos all on Intel. In terms of development, there's me on MacOS AppleSilicon, so getting a little Arm64 in there. It's possible there's something special about the floating point in the RPI3, but there's also a failure in unit-io-GeoJSONReader in there, which ... is not doing any heavy lifting. So I duno. As with other fun platforms I'm always open to patches. :) P ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta2
I have no clear memory of whether I ever tried to build geos or run tests on RPI3 before. I have a very very vague memory of having trouble and never having chased it down. So I am definitely not asking that the release be held for this! > https://download.osgeo.org/geos/geos-3.12.0beta2.tar.bz2 I am using gcc version 7.5.0 (nb4 20200810) On NetBSD 9 amd64, after installing it, tests all pass. [snip] Start 466: xml-validate-TestRelatePP 466/466 Test #466: xml-validate-TestRelatePP .. Passed0.01 sec 100% tests passed, 0 tests failed out of 466 Total Test time (real) = 20.89 sec On NetBSD 9 earmv7hf-el (RPI3 hardware, specifically), after installing it, most but not all tests pass. I ran it twice with the same results 96% tests passed, 18 tests failed out of 465 Total Test time (real) = 111.91 sec The following tests did not run: 377 - xml-issue-issue-geos-837 (Disabled) The following tests FAILED: 25 - unit-algorithm-construct-MaximumInscribedCircle (Subprocess aborted) 32 - unit-capi-GEOSBuffer (Subprocess aborted) 35 - unit-capi-GEOSClipByRect (Subprocess aborted) 42 - unit-capi-GEOSCoordSeq (Subprocess aborted) 62 - unit-capi-GEOSGeomGeoJSONRead (Subprocess aborted) 94 - unit-capi-GEOSInterrupt (Subprocess aborted) 104 - unit-capi-GEOSMaximumInscribedCircle (Subprocess aborted) 140 - unit-capi-GEOSUnaryUnion (Subprocess aborted) 143 - unit-capi-GEOSUnion (Subprocess aborted) 168 - unit-geom-Dimension (Subprocess aborted) 212 - unit-io-GeoJSONReader (Subprocess aborted) 233 - unit-operation-buffer-BufferOp (Subprocess aborted) 240 - unit-operation-distance-IndexedFacetDistance (Subprocess aborted) 300 - xml-general-TestBuffer (Subprocess aborted) 305 - xml-general-TestDensify (Subprocess aborted) 361 - xml-issue-issue-geos-366 (Subprocess aborted) 373 - xml-issue-issue-geos-605 (Subprocess aborted) 399 - xml-misc-safe-TestBufferJagged (Subprocess aborted) Errors while running CTest Output from these tests are in: /d0/n0/pkgsrc/geography/geos/work/geos-3.12.0beta2/Testing/Temporary/LastTest.log Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely. gmake[4]: *** [Makefile:91: test] Error 8 gmake[4]: Leaving directory '/d0/n0/pkgsrc/geography/geos/work/geos-3.12.0beta2' *** Error code 2 Looking at the logs (at end), overall this smells like either a systematic issue where the floating point on my system is broken, or there is some slight floating point difference from x86, and geos tests are very sensitive to exact FP results. But that's just guessing. I'm building for NetBSD 9 i386 and will also try macOS x86_64. FWIW, I ran paranoia and got: No failures, defects nor flaws have been discovered. Rounding appears to conform to the proposed IEEE standard P754. The arithmetic diagnosed appears to be Excellent! I am curious if others have been running tests on CPUs other than x86, and on those systems, if other than GNU/Linux. Here's the output of "ctest --rerun-failed --output-on-failure": Test project /usr/pkgsrc/geography/geos/work/geos-3.12.0beta2 Start 25: unit-algorithm-construct-MaximumInscribedCircle 1/18 Test #25: unit-algorithm-construct-MaximumInscribedCircle ...Subprocess aborted***Exception: 0.40 sec === GEOS Unit Test Suite === geos::algorithm::construct::MaximumInscribedCircle: ...terminate called after throwing an instance of 'geos::util::GEOSException' what(): Non-finite envelope encountered. Start 32: unit-capi-GEOSBuffer 2/18 Test #32: unit-capi-GEOSBuffer ..Subprocess aborted***Exception: 0.09 sec === GEOS Unit Test Suite === capi::GEOSBuffer: .NOTICE: IllegalArgumentException: Invalid buffer endCap style NOTICE: IllegalArgumentException: Invalid buffer join style .terminate called after throwing an instance of 'geos::util::GEOSException' what(): Shell empty after removing invalid points Start 35: unit-capi-GEOSClipByRect 3/18 Test #35: unit-capi-GEOSClipByRect ..Subprocess aborted***Exception: 0.09 sec === GEOS Unit Test Suite === capi::GEOSClipByRect: .terminate called after throwing an instance of 'geos::util::IllegalArgumentException' what(): IllegalArgumentException: Invalid number of points in LinearRing found 3 - must be 0 or >= 4 Start 42: unit-capi-GEOSCoordSeq 4/18 Test #42: unit-capi-GEOSCoordSeq Subprocess aborted***Exception: 0.08 sec
Re: [geos-devel] 3.12.0beta2
This is of course not a request to hold the release; just a comment on something that I don't yet understand. I am able to run tests by installing the just built geos and then running them. The plot thickens on the meta test issues. I built on RPI3 under NetBSD; geos had not been previously installed (because that CPU, 1 GB RAM, and no monitor or keyboard makes for a poor qgis experience!). The tests all failed, which if the issue was rpath order should not be. I then looked into the build dir: /usr/pkgsrc/geography/geos/work/geos-3.12.0beta2/bin $ ldd test_xmltester test_xmltester: -lgeos.3.12.0 => not found -lstdc++.9 => /usr/lib/libstdc++.so.9 -lm.0 => /usr/lib/libm.so.0 -lc.12 => /usr/lib/libc.so.12 objdump says NEEDED libgeos.so.3.12.0 NEEDED libstdc++.so.9 NEEDED libm.so.0 NEEDED libc.so.12 RPATH/usr/pkg/lib which is ok for an installed program, but not one that intends to use a library from the build tree. I see 'make test' runs ctest, but I can't follow how that is supposed to set up LD_LIBRARY_PATH to pre-load from the built but not installed library. I can't find 'LD_LIBR' by grepping the source tree. I know autoconf/libtool links once in the tree and relinks at install time -- but I do not have the impression cmake does it that way. I wonder if for others, tests work from a build, in the case of no geos at all installed on the system, and what ldd/objdump says on bin/test_xmltester after building. Can anyone explain the theory of how the tests are run linking against the just-built library instead of one that is (or is not) installed in the system? ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
