Re: [lucene] branch main updated: Prevent NPEs while still handling the polar case for horizontal planes right off the pole
I have multiple Windows machines, including laptops. Never had this issue (but I stay away from WSL and such). Performance is, I'd say 25% slower than comparable Linux machines. Something is wrong with your rig. Dawid On Thu, Nov 24, 2022 at 12:26 PM Karl Wright wrote: > My entire tool set and work environment is inside WSL. > > I've determined that the issue for me is the performance of the file > system. I had to remove the (bundled) antivirus software to get even where > I am now. But I have no evidence that even doing windows-native operations > with this disk are fast. I suspect that even though this is an SSD it's > not a very fast one. It did get twice as fast when I turned off the new > Windows 11 "climate change" feature, which apparently conserves energy by > throttling the hell out of everything, including disk access. So maybe > this is still being throttled to some degree and I have to figure out where. > > Karl > > > On Thu, Nov 24, 2022 at 3:23 AM Jan Høydahl wrote: > >> I’m not on Windows myself, but I think the trick is doing the git clone >> to the WSL file system. So you may have one checkout for use with windows >> and another for use within wsl. >> >> And if you’re a CLI person, there’s a GitHub cli tool ‘hub’ that is >> handy: https://hub.github.com/ >> >> Jan Høydahl >> >> 17. nov. 2022 kl. 16:49 skrev Dawid Weiss : >> >> I never used WSL but it does seem like the problem there: >> >> "As you can tell from the comparison table above, the WSL 2 >> architecture outperforms WSL 1 in several ways, with the exception of >> performance across OS file systems, which can be addressed by storing >> your project files on the same operating system as the tools you are >> running to work on the project." >> >> https://learn.microsoft.com/en-us/windows/wsl/compare-versions >> >> Dawid >> >> >> On Thu, Nov 17, 2022 at 1:11 PM Robert Muir wrote: >> >> >> if your machine is really 12 cores and 64GB ram but is that slow, then >> >> uninstall that windows shit immediately, that's horrible. >> >> >> On Thu, Nov 17, 2022 at 5:46 AM Karl Wright wrote: >> >> >> Thanks - the target I was using was the complete "build" target on the >> whole project. This will be a valuable improvement. ;-) >> >> >> I have slow network here so it is possible that the entire build was slow >> for that reason. The machine is a new Dell laptop, 12 cores, 64GB memory, >> but I am running under Windows Subsystem for Linux which is a bit slower >> than native Ubuntu. Still, the gradlew command you gave takes many minutes >> (of which a sizable amount is spent in :gitStatus - more than 5 minutes >> there alone). Anything less than 10 minutes I deem acceptable, which this >> doesn't quite manage, but I'll live. >> >> >> Karl >> >> >> >> On Thu, Nov 17, 2022 at 5:06 AM Dawid Weiss >> wrote: >> >> >> >> Thank you for the comment. >> >> >> >> Sorry if it came out the wrong way - I certainly didn't mean it to be >> unkind. >> >> >> >> It took me several days just to get things set up so I was able to commit >> again, and I did this through command-line not github. >> >> >> >> These things are not mutually exclusive - I work with command line as >> well. You just push to your own repository (or a branch, if you don't care >> to have your own fork on github) and then file a PR from there. If you're >> on a slower machine - this is even better since precommit checks run for >> you there. >> >> >> >> The full gradlew script takes over 2 hours to run now so if there's a >> faster target I can use to determine these things in advance I'd love to >> know what it is. >> >> >> >> Well, this is crazy long so I wonder what's happening. I'd love to help >> but it'd be good to know what machine this is (disk, cpu, memory?) and what >> the build command was. Without knowing these, I'd say - run the tests and >> checks for the module you've changed only, not for everything. How long >> does this take? >> >> >> ./gradlew check -p lucene/spatial3d >> >> >> It takes roughly 1 minute for me, including startup (after the daemon is >> running in the background, it's much faster). >> >> >> There are some workflow examples/ hints I left here: >> >> https://github.com/apache/lucene/blob/main/help/workflow.txt#L6-L22 >> >> >> Hope it helps, >> >> Dawid >> >> >> - >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
Re: [lucene] branch main updated: Prevent NPEs while still handling the polar case for horizontal planes right off the pole
My entire tool set and work environment is inside WSL. I've determined that the issue for me is the performance of the file system. I had to remove the (bundled) antivirus software to get even where I am now. But I have no evidence that even doing windows-native operations with this disk are fast. I suspect that even though this is an SSD it's not a very fast one. It did get twice as fast when I turned off the new Windows 11 "climate change" feature, which apparently conserves energy by throttling the hell out of everything, including disk access. So maybe this is still being throttled to some degree and I have to figure out where. Karl On Thu, Nov 24, 2022 at 3:23 AM Jan Høydahl wrote: > I’m not on Windows myself, but I think the trick is doing the git clone to > the WSL file system. So you may have one checkout for use with windows and > another for use within wsl. > > And if you’re a CLI person, there’s a GitHub cli tool ‘hub’ that is handy: > https://hub.github.com/ > > Jan Høydahl > > 17. nov. 2022 kl. 16:49 skrev Dawid Weiss : > > I never used WSL but it does seem like the problem there: > > "As you can tell from the comparison table above, the WSL 2 > architecture outperforms WSL 1 in several ways, with the exception of > performance across OS file systems, which can be addressed by storing > your project files on the same operating system as the tools you are > running to work on the project." > > https://learn.microsoft.com/en-us/windows/wsl/compare-versions > > Dawid > > > On Thu, Nov 17, 2022 at 1:11 PM Robert Muir wrote: > > > if your machine is really 12 cores and 64GB ram but is that slow, then > > uninstall that windows shit immediately, that's horrible. > > > On Thu, Nov 17, 2022 at 5:46 AM Karl Wright wrote: > > > Thanks - the target I was using was the complete "build" target on the > whole project. This will be a valuable improvement. ;-) > > > I have slow network here so it is possible that the entire build was slow > for that reason. The machine is a new Dell laptop, 12 cores, 64GB memory, > but I am running under Windows Subsystem for Linux which is a bit slower > than native Ubuntu. Still, the gradlew command you gave takes many minutes > (of which a sizable amount is spent in :gitStatus - more than 5 minutes > there alone). Anything less than 10 minutes I deem acceptable, which this > doesn't quite manage, but I'll live. > > > Karl > > > > On Thu, Nov 17, 2022 at 5:06 AM Dawid Weiss wrote: > > > > Thank you for the comment. > > > > Sorry if it came out the wrong way - I certainly didn't mean it to be > unkind. > > > > It took me several days just to get things set up so I was able to commit > again, and I did this through command-line not github. > > > > These things are not mutually exclusive - I work with command line as > well. You just push to your own repository (or a branch, if you don't care > to have your own fork on github) and then file a PR from there. If you're > on a slower machine - this is even better since precommit checks run for > you there. > > > > The full gradlew script takes over 2 hours to run now so if there's a > faster target I can use to determine these things in advance I'd love to > know what it is. > > > > Well, this is crazy long so I wonder what's happening. I'd love to help > but it'd be good to know what machine this is (disk, cpu, memory?) and what > the build command was. Without knowing these, I'd say - run the tests and > checks for the module you've changed only, not for everything. How long > does this take? > > > ./gradlew check -p lucene/spatial3d > > > It takes roughly 1 minute for me, including startup (after the daemon is > running in the background, it's much faster). > > > There are some workflow examples/ hints I left here: > > https://github.com/apache/lucene/blob/main/help/workflow.txt#L6-L22 > > > Hope it helps, > > Dawid > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: [lucene] branch main updated: Prevent NPEs while still handling the polar case for horizontal planes right off the pole
I’m not on Windows myself, but I think the trick is doing the git clone to the WSL file system. So you may have one checkout for use with windows and another for use within wsl. And if you’re a CLI person, there’s a GitHub cli tool ‘hub’ that is handy: https://hub.github.com/ Jan Høydahl > 17. nov. 2022 kl. 16:49 skrev Dawid Weiss : > > I never used WSL but it does seem like the problem there: > > "As you can tell from the comparison table above, the WSL 2 > architecture outperforms WSL 1 in several ways, with the exception of > performance across OS file systems, which can be addressed by storing > your project files on the same operating system as the tools you are > running to work on the project." > > https://learn.microsoft.com/en-us/windows/wsl/compare-versions > > Dawid > > >> On Thu, Nov 17, 2022 at 1:11 PM Robert Muir wrote: >> >> if your machine is really 12 cores and 64GB ram but is that slow, then >> uninstall that windows shit immediately, that's horrible. >> >>> On Thu, Nov 17, 2022 at 5:46 AM Karl Wright wrote: >>> >>> Thanks - the target I was using was the complete "build" target on the >>> whole project. This will be a valuable improvement. ;-) >>> >>> I have slow network here so it is possible that the entire build was slow >>> for that reason. The machine is a new Dell laptop, 12 cores, 64GB memory, >>> but I am running under Windows Subsystem for Linux which is a bit slower >>> than native Ubuntu. Still, the gradlew command you gave takes many minutes >>> (of which a sizable amount is spent in :gitStatus - more than 5 minutes >>> there alone). Anything less than 10 minutes I deem acceptable, which this >>> doesn't quite manage, but I'll live. >>> >>> Karl >>> >>> >>> On Thu, Nov 17, 2022 at 5:06 AM Dawid Weiss wrote: > Thank you for the comment. Sorry if it came out the wrong way - I certainly didn't mean it to be unkind. > > It took me several days just to get things set up so I was able to commit > again, and I did this through command-line not github. These things are not mutually exclusive - I work with command line as well. You just push to your own repository (or a branch, if you don't care to have your own fork on github) and then file a PR from there. If you're on a slower machine - this is even better since precommit checks run for you there. > > The full gradlew script takes over 2 hours to run now so if there's a > faster target I can use to determine these things in advance I'd love to > know what it is. Well, this is crazy long so I wonder what's happening. I'd love to help but it'd be good to know what machine this is (disk, cpu, memory?) and what the build command was. Without knowing these, I'd say - run the tests and checks for the module you've changed only, not for everything. How long does this take? ./gradlew check -p lucene/spatial3d It takes roughly 1 minute for me, including startup (after the daemon is running in the background, it's much faster). There are some workflow examples/ hints I left here: https://github.com/apache/lucene/blob/main/help/workflow.txt#L6-L22 Hope it helps, Dawid >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org >
Re: [lucene] branch main updated: Prevent NPEs while still handling the polar case for horizontal planes right off the pole
I never used WSL but it does seem like the problem there: "As you can tell from the comparison table above, the WSL 2 architecture outperforms WSL 1 in several ways, with the exception of performance across OS file systems, which can be addressed by storing your project files on the same operating system as the tools you are running to work on the project." https://learn.microsoft.com/en-us/windows/wsl/compare-versions Dawid On Thu, Nov 17, 2022 at 1:11 PM Robert Muir wrote: > > if your machine is really 12 cores and 64GB ram but is that slow, then > uninstall that windows shit immediately, that's horrible. > > On Thu, Nov 17, 2022 at 5:46 AM Karl Wright wrote: > > > > Thanks - the target I was using was the complete "build" target on the > > whole project. This will be a valuable improvement. ;-) > > > > I have slow network here so it is possible that the entire build was slow > > for that reason. The machine is a new Dell laptop, 12 cores, 64GB memory, > > but I am running under Windows Subsystem for Linux which is a bit slower > > than native Ubuntu. Still, the gradlew command you gave takes many minutes > > (of which a sizable amount is spent in :gitStatus - more than 5 minutes > > there alone). Anything less than 10 minutes I deem acceptable, which this > > doesn't quite manage, but I'll live. > > > > Karl > > > > > > On Thu, Nov 17, 2022 at 5:06 AM Dawid Weiss wrote: > >> > >> > >>> Thank you for the comment. > >> > >> > >> Sorry if it came out the wrong way - I certainly didn't mean it to be > >> unkind. > >> > >>> > >>> It took me several days just to get things set up so I was able to commit > >>> again, and I did this through command-line not github. > >> > >> > >> These things are not mutually exclusive - I work with command line as > >> well. You just push to your own repository (or a branch, if you don't care > >> to have your own fork on github) and then file a PR from there. If you're > >> on a slower machine - this is even better since precommit checks run for > >> you there. > >> > >>> > >>> The full gradlew script takes over 2 hours to run now so if there's a > >>> faster target I can use to determine these things in advance I'd love to > >>> know what it is. > >> > >> > >> Well, this is crazy long so I wonder what's happening. I'd love to help > >> but it'd be good to know what machine this is (disk, cpu, memory?) and > >> what the build command was. Without knowing these, I'd say - run the tests > >> and checks for the module you've changed only, not for everything. How > >> long does this take? > >> > >> ./gradlew check -p lucene/spatial3d > >> > >> It takes roughly 1 minute for me, including startup (after the daemon is > >> running in the background, it's much faster). > >> > >> There are some workflow examples/ hints I left here: > >> https://github.com/apache/lucene/blob/main/help/workflow.txt#L6-L22 > >> > >> Hope it helps, > >> Dawid > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [lucene] branch main updated: Prevent NPEs while still handling the polar case for horizontal planes right off the pole
if your machine is really 12 cores and 64GB ram but is that slow, then uninstall that windows shit immediately, that's horrible. On Thu, Nov 17, 2022 at 5:46 AM Karl Wright wrote: > > Thanks - the target I was using was the complete "build" target on the whole > project. This will be a valuable improvement. ;-) > > I have slow network here so it is possible that the entire build was slow for > that reason. The machine is a new Dell laptop, 12 cores, 64GB memory, but I > am running under Windows Subsystem for Linux which is a bit slower than > native Ubuntu. Still, the gradlew command you gave takes many minutes (of > which a sizable amount is spent in :gitStatus - more than 5 minutes there > alone). Anything less than 10 minutes I deem acceptable, which this doesn't > quite manage, but I'll live. > > Karl > > > On Thu, Nov 17, 2022 at 5:06 AM Dawid Weiss wrote: >> >> >>> Thank you for the comment. >> >> >> Sorry if it came out the wrong way - I certainly didn't mean it to be unkind. >> >>> >>> It took me several days just to get things set up so I was able to commit >>> again, and I did this through command-line not github. >> >> >> These things are not mutually exclusive - I work with command line as well. >> You just push to your own repository (or a branch, if you don't care to have >> your own fork on github) and then file a PR from there. If you're on a >> slower machine - this is even better since precommit checks run for you >> there. >> >>> >>> The full gradlew script takes over 2 hours to run now so if there's a >>> faster target I can use to determine these things in advance I'd love to >>> know what it is. >> >> >> Well, this is crazy long so I wonder what's happening. I'd love to help but >> it'd be good to know what machine this is (disk, cpu, memory?) and what the >> build command was. Without knowing these, I'd say - run the tests and checks >> for the module you've changed only, not for everything. How long does this >> take? >> >> ./gradlew check -p lucene/spatial3d >> >> It takes roughly 1 minute for me, including startup (after the daemon is >> running in the background, it's much faster). >> >> There are some workflow examples/ hints I left here: >> https://github.com/apache/lucene/blob/main/help/workflow.txt#L6-L22 >> >> Hope it helps, >> Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [lucene] branch main updated: Prevent NPEs while still handling the polar case for horizontal planes right off the pole
> I have slow network here so it is possible that the entire build was slow > for that reason. The machine is a new Dell laptop, 12 cores, 64GB memory, > but I am running under Windows Subsystem for Linux which is a bit slower > than native Ubuntu. Still, the gradlew command you gave takes many minutes > (of which a sizable amount is spent in :gitStatus - more than 5 minutes > there alone). Anything less than 10 minutes I deem acceptable, which this > doesn't quite manage, but I'll live. > These are extreme times, really. Anything filesystem related will be slow(er) on Windows and there is a fair amount of files being written/ stat'd but it's still _nowhere_ near the times you're reporting (I also work on Windows). This has to be an i/o bottleneck somewhere - git status is basically no-op, see this: >gradlew :gitStatus -Ptask.times=true Aggregate task times (possibly running in parallel!): 0.24 sec. gitStatus So something is off with that setup. I'd try running on Windows directly first, just to rule out WSL quirks. It definitely should be much faster on that hardware... Dawid >
Re: [lucene] branch main updated: Prevent NPEs while still handling the polar case for horizontal planes right off the pole
Thanks - the target I was using was the complete "build" target on the whole project. This will be a valuable improvement. ;-) I have slow network here so it is possible that the entire build was slow for that reason. The machine is a new Dell laptop, 12 cores, 64GB memory, but I am running under Windows Subsystem for Linux which is a bit slower than native Ubuntu. Still, the gradlew command you gave takes many minutes (of which a sizable amount is spent in :gitStatus - more than 5 minutes there alone). Anything less than 10 minutes I deem acceptable, which this doesn't quite manage, but I'll live. Karl On Thu, Nov 17, 2022 at 5:06 AM Dawid Weiss wrote: > > Thank you for the comment. >> > > Sorry if it came out the wrong way - I certainly didn't mean it to be > unkind. > > >> It took me several days just to get things set up so I was able to commit >> again, and I did this through command-line not github. >> > > These things are not mutually exclusive - I work with command line as > well. You just push to your own repository (or a branch, if you don't care > to have your own fork on github) and then file a PR from there. If you're > on a slower machine - this is even better since precommit checks run for > you there. > > >> The full gradlew script takes over 2 hours to run now so if there's a >> faster target I can use to determine these things in advance I'd love to >> know what it is. >> > > Well, this is crazy long so I wonder what's happening. I'd love to help > but it'd be good to know what machine this is (disk, cpu, memory?) and what > the build command was. Without knowing these, I'd say - run the tests and > checks for the module you've changed only, not for everything. How long > does this take? > > ./gradlew check -p lucene/spatial3d > > It takes roughly 1 minute for me, including startup (after the daemon is > running in the background, it's much faster). > > There are some workflow examples/ hints I left here: > https://github.com/apache/lucene/blob/main/help/workflow.txt#L6-L22 > > Hope it helps, > Dawid >
Re: [lucene] branch main updated: Prevent NPEs while still handling the polar case for horizontal planes right off the pole
> Thank you for the comment. > Sorry if it came out the wrong way - I certainly didn't mean it to be unkind. > It took me several days just to get things set up so I was able to commit > again, and I did this through command-line not github. > These things are not mutually exclusive - I work with command line as well. You just push to your own repository (or a branch, if you don't care to have your own fork on github) and then file a PR from there. If you're on a slower machine - this is even better since precommit checks run for you there. > The full gradlew script takes over 2 hours to run now so if there's a > faster target I can use to determine these things in advance I'd love to > know what it is. > Well, this is crazy long so I wonder what's happening. I'd love to help but it'd be good to know what machine this is (disk, cpu, memory?) and what the build command was. Without knowing these, I'd say - run the tests and checks for the module you've changed only, not for everything. How long does this take? ./gradlew check -p lucene/spatial3d It takes roughly 1 minute for me, including startup (after the daemon is running in the background, it's much faster). There are some workflow examples/ hints I left here: https://github.com/apache/lucene/blob/main/help/workflow.txt#L6-L22 Hope it helps, Dawid
Re: [lucene] branch main updated: Prevent NPEs while still handling the polar case for horizontal planes right off the pole
Thank you for the comment. It took me several days just to get things set up so I was able to commit again, and I did this through command-line not github. The full gradlew script takes over 2 hours to run now so if there's a faster target I can use to determine these things in advance I'd love to know what it is. Karl On Thu, Nov 17, 2022 at 1:23 AM Dawid Weiss wrote: > > Hi Karl, > > This commit broke the build because code formatting was off (this was > fixed in a subsequent, unrelated commit). > > I spent some time looking for the issue to check what happened and > couldn't find it anywhere. Github's PR infrastructure > makes it quite convenient to ensure everything passes before it's merged > and it leaves a handy > place to add comments in case something doesn't work - I highly recommend > it. > > Dawid > > On Thu, Nov 17, 2022 at 2:19 AM wrote: > >> This is an automated email from the ASF dual-hosted git repository. >> >> kwright pushed a commit to branch main >> in repository https://gitbox.apache.org/repos/asf/lucene.git >> >> >> The following commit(s) were added to refs/heads/main by this push: >> new b6ebfd18610 Prevent NPEs while still handling the polar case for >> horizontal planes right off the pole >> b6ebfd18610 is described below >> >> commit b6ebfd18610c482109c6a38b2327254848508f03 >> Author: Karl David Wright >> AuthorDate: Wed Nov 16 11:03:24 2022 -0500 >> >> Prevent NPEs while still handling the polar case for horizontal >> planes right off the pole >> --- >> .../java/org/apache/lucene/spatial3d/geom/Plane.java | 20 >> >> 1 file changed, 16 insertions(+), 4 deletions(-) >> >> diff --git >> a/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/Plane.java >> b/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/Plane.java >> index ef9e9773223..9b46c3553bf 100755 >> --- >> a/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/Plane.java >> +++ >> b/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/Plane.java >> @@ -1500,9 +1500,14 @@ public class Plane extends Vector { >>} else { >> // Since a==b==0, any plane including the Z axis suffices. >> // System.err.println(" Perpendicular to z"); >> -final GeoPoint[] points = >> +GeoPoint[] points = >> findIntersections(planetModel, normalYPlane, NO_BOUNDS, >> NO_BOUNDS); >> -if (points.length > 0) { >> +if (points.length == 0) { >> + points = findIntersections(planetModel, normalXPlane, >> NO_BOUNDS, NO_BOUNDS); >> +} >> +if (points.length == 0) { >> + boundsInfo.addZValue(new GeoPoint(0.0, 0.0, -this.z)); >> +} else { >>boundsInfo.addZValue(points[0]); >> } >>} >> @@ -2042,9 +2047,16 @@ public class Plane extends Vector { >> } >>} else { >> // Horizontal circle. Since a==b, any vertical plane suffices. >> -final GeoPoint[] points = >> +GeoPoint[] points = >> findIntersections(planetModel, normalXPlane, NO_BOUNDS, >> NO_BOUNDS); >> -boundsInfo.addZValue(points[0]); >> +if (points.length == 0) { >> + points = findIntersections(planetModel, normalYPlane, >> NO_BOUNDS, NO_BOUNDS); >> +} >> +if (points.length == 0) { >> + boundsInfo.addZValue(new GeoPoint(0.0, 0.0, -this.z)); >> +} else { >> + boundsInfo.addZValue(points[0]); >> +} >>} >>// System.err.println("Done latitude bounds"); >> } >> >>
Re: [lucene] branch main updated: Prevent NPEs while still handling the polar case for horizontal planes right off the pole
Hi Karl, This commit broke the build because code formatting was off (this was fixed in a subsequent, unrelated commit). I spent some time looking for the issue to check what happened and couldn't find it anywhere. Github's PR infrastructure makes it quite convenient to ensure everything passes before it's merged and it leaves a handy place to add comments in case something doesn't work - I highly recommend it. Dawid On Thu, Nov 17, 2022 at 2:19 AM wrote: > This is an automated email from the ASF dual-hosted git repository. > > kwright pushed a commit to branch main > in repository https://gitbox.apache.org/repos/asf/lucene.git > > > The following commit(s) were added to refs/heads/main by this push: > new b6ebfd18610 Prevent NPEs while still handling the polar case for > horizontal planes right off the pole > b6ebfd18610 is described below > > commit b6ebfd18610c482109c6a38b2327254848508f03 > Author: Karl David Wright > AuthorDate: Wed Nov 16 11:03:24 2022 -0500 > > Prevent NPEs while still handling the polar case for horizontal planes > right off the pole > --- > .../java/org/apache/lucene/spatial3d/geom/Plane.java | 20 > > 1 file changed, 16 insertions(+), 4 deletions(-) > > diff --git > a/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/Plane.java > b/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/Plane.java > index ef9e9773223..9b46c3553bf 100755 > --- a/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/Plane.java > +++ b/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/Plane.java > @@ -1500,9 +1500,14 @@ public class Plane extends Vector { >} else { > // Since a==b==0, any plane including the Z axis suffices. > // System.err.println(" Perpendicular to z"); > -final GeoPoint[] points = > +GeoPoint[] points = > findIntersections(planetModel, normalYPlane, NO_BOUNDS, > NO_BOUNDS); > -if (points.length > 0) { > +if (points.length == 0) { > + points = findIntersections(planetModel, normalXPlane, > NO_BOUNDS, NO_BOUNDS); > +} > +if (points.length == 0) { > + boundsInfo.addZValue(new GeoPoint(0.0, 0.0, -this.z)); > +} else { >boundsInfo.addZValue(points[0]); > } >} > @@ -2042,9 +2047,16 @@ public class Plane extends Vector { > } >} else { > // Horizontal circle. Since a==b, any vertical plane suffices. > -final GeoPoint[] points = > +GeoPoint[] points = > findIntersections(planetModel, normalXPlane, NO_BOUNDS, > NO_BOUNDS); > -boundsInfo.addZValue(points[0]); > +if (points.length == 0) { > + points = findIntersections(planetModel, normalYPlane, > NO_BOUNDS, NO_BOUNDS); > +} > +if (points.length == 0) { > + boundsInfo.addZValue(new GeoPoint(0.0, 0.0, -this.z)); > +} else { > + boundsInfo.addZValue(points[0]); > +} >} >// System.err.println("Done latitude bounds"); > } > >