Re: [VOTE] Release Lucene 9.4.2 RC1
+1. SUCCESS! [0:40:42.940614] On Thu, Nov 17, 2022 at 9:58 AM Dawid Weiss wrote: > +1. > > SUCCESS! [0:56:24.797915] > > On Thu, Nov 17, 2022 at 3:18 PM Adrien Grand wrote: > > > > Please vote for release candidate 1 for Lucene 9.4.2 > > > > The artifacts can be downloaded from: > > > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.4.2-RC1-rev-858d9b437047a577fa9457089afff43eefa461db > > > > You can run the smoke tester directly with this command: > > > > python3 -u dev-tools/scripts/smokeTestRelease.py \ > > > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.4.2-RC1-rev-858d9b437047a577fa9457089afff43eefa461db > > > > The vote will be open for at least 72 hours i.e. until 2022-11-20 15:00 > UTC. > > > > [ ] +1 approve > > [ ] +0 no opinion > > [ ] -1 disapprove (and reason why) > > > > Here is my +1. > > > > -- > > Adrien > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: [VOTE] Release Lucene 9.4.2 RC1
+1. SUCCESS! [0:56:24.797915] On Thu, Nov 17, 2022 at 3:18 PM Adrien Grand wrote: > > Please vote for release candidate 1 for Lucene 9.4.2 > > The artifacts can be downloaded from: > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.4.2-RC1-rev-858d9b437047a577fa9457089afff43eefa461db > > You can run the smoke tester directly with this command: > > python3 -u dev-tools/scripts/smokeTestRelease.py \ > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.4.2-RC1-rev-858d9b437047a577fa9457089afff43eefa461db > > The vote will be open for at least 72 hours i.e. until 2022-11-20 15:00 UTC. > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > Here is my +1. > > -- > Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene 9.4.2 RC1
+1 SUCCESS! [1:16:29.706409] On Thu, Nov 17, 2022 at 9:18 AM Adrien Grand wrote: > > Please vote for release candidate 1 for Lucene 9.4.2 > > The artifacts can be downloaded from: > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.4.2-RC1-rev-858d9b437047a577fa9457089afff43eefa461db > > You can run the smoke tester directly with this command: > > python3 -u dev-tools/scripts/smokeTestRelease.py \ > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.4.2-RC1-rev-858d9b437047a577fa9457089afff43eefa461db > > The vote will be open for at least 72 hours i.e. until 2022-11-20 15:00 UTC. > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > Here is my +1. > > -- > Adrien - 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: [VOTE] Release Lucene 9.4.2 RC1
SUCCESS! [0:46:39.842784] +1 On Thu, Nov 17, 2022 at 3:18 PM Adrien Grand wrote: > Please vote for release candidate 1 for Lucene 9.4.2 > > The artifacts can be downloaded from: > > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.4.2-RC1-rev-858d9b437047a577fa9457089afff43eefa461db > > You can run the smoke tester directly with this command: > > python3 -u dev-tools/scripts/smokeTestRelease.py \ > > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.4.2-RC1-rev-858d9b437047a577fa9457089afff43eefa461db > > The vote will be open for at least 72 hours i.e. until 2022-11-20 15:00 > UTC. > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > Here is my +1. > > -- > Adrien >
[VOTE] Release Lucene 9.4.2 RC1
Please vote for release candidate 1 for Lucene 9.4.2 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/lucene/lucene-9.4.2-RC1-rev-858d9b437047a577fa9457089afff43eefa461db You can run the smoke tester directly with this command: python3 -u dev-tools/scripts/smokeTestRelease.py \ https://dist.apache.org/repos/dist/dev/lucene/lucene-9.4.2-RC1-rev-858d9b437047a577fa9457089afff43eefa461db The vote will be open for at least 72 hours i.e. until 2022-11-20 15:00 UTC. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Here is my +1. -- Adrien
Re: Maven artifacts and releases
> I remember another proposal which consisted of using the Gradle build to > rebuild Maven artifacts at the type of uploading to Nexus, which I liked > less because it involved re-building, and who knows what may happen that > could produce slightly different binaries. I like your new proposal better. > Right - it would have to be a one-step operation, otherwise I wouldn't bet on those JARs being the same... > > Those are browsable and artifacts can be downloaded from there before > voting (although I'm not sure if anybody inspects those maven artifacts) > > I suspect you know this, but the smoke tester does download these > artifacts and runs some checks. > We could still build that zip for the smoke tester. The important thing here is that local artifact building and staged artifacts would be synced (uploaded within one gradle command). An alternative is to implement post-vote artifact upload in gradle (or ant within gradle). This is also possible but seems somewhat backward... Dawid >
Re: Maven artifacts and releases
I remember another proposal which consisted of using the Gradle build to rebuild Maven artifacts at the type of uploading to Nexus, which I liked less because it involved re-building, and who knows what may happen that could produce slightly different binaries. I like your new proposal better. > Those are browsable and artifacts can be downloaded from there before voting (although I'm not sure if anybody inspects those maven artifacts) I suspect you know this, but the smoke tester does download these artifacts and runs some checks. On Thu, Nov 17, 2022 at 2:31 PM Dawid Weiss wrote: > > Yeah, I thought so. I'd love to help improve this as part of the next > release - it should really be simple. I know the old way was to have maven > artifacts separately (to agree/vote upon) but in my opinion it wouldn't > change much if the release manager pointed to release artifacts + maven > artifact (staging) repository uploaded to Apache Nexus. Those are browsable > and artifacts can be downloaded from there before voting (although I'm not > sure if anybody inspects those maven artifacts). Also, the staging > repository can "hang" unreleased until the voting is closed. This would > make the build side of things much easier and wound't require any extra > infrastructure/ steps. > > Dawid > > On Thu, Nov 17, 2022 at 2:08 PM Adrien Grand wrote: > >> I remember using a 8.x build to do that for the 9.0 release. >> >> On Thu, Nov 17, 2022 at 1:54 PM Dawid Weiss >> wrote: >> >>> >>> I looked at an old issue related to maven artifact publishing and I >>> noticed the release wizard still gives instructions to use the ant-based >>> script (which isn't there anymore?): >>> >>> ant clean stage-maven-artifacts >>> >>> I'm sorry to ask but how did release managers stage maven artifacts so >>> far on 9x? >>> >>> Dawid >>> >> >> >> -- >> Adrien >> > -- Adrien
Re: Maven artifacts and releases
Yeah, I thought so. I'd love to help improve this as part of the next release - it should really be simple. I know the old way was to have maven artifacts separately (to agree/vote upon) but in my opinion it wouldn't change much if the release manager pointed to release artifacts + maven artifact (staging) repository uploaded to Apache Nexus. Those are browsable and artifacts can be downloaded from there before voting (although I'm not sure if anybody inspects those maven artifacts). Also, the staging repository can "hang" unreleased until the voting is closed. This would make the build side of things much easier and wound't require any extra infrastructure/ steps. Dawid On Thu, Nov 17, 2022 at 2:08 PM Adrien Grand wrote: > I remember using a 8.x build to do that for the 9.0 release. > > On Thu, Nov 17, 2022 at 1:54 PM Dawid Weiss wrote: > >> >> I looked at an old issue related to maven artifact publishing and I >> noticed the release wizard still gives instructions to use the ant-based >> script (which isn't there anymore?): >> >> ant clean stage-maven-artifacts >> >> I'm sorry to ask but how did release managers stage maven artifacts so >> far on 9x? >> >> Dawid >> > > > -- > Adrien >
Re: Maven artifacts and releases
I remember using a 8.x build to do that for the 9.0 release. On Thu, Nov 17, 2022 at 1:54 PM Dawid Weiss wrote: > > I looked at an old issue related to maven artifact publishing and I > noticed the release wizard still gives instructions to use the ant-based > script (which isn't there anymore?): > > ant clean stage-maven-artifacts > > I'm sorry to ask but how did release managers stage maven artifacts so far > on 9x? > > Dawid > -- Adrien
Maven artifacts and releases
I looked at an old issue related to maven artifact publishing and I noticed the release wizard still gives instructions to use the ant-based script (which isn't there anymore?): ant clean stage-maven-artifacts I'm sorry to ask but how did release managers stage maven artifacts so far on 9x? Dawid
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: Release Lucene 9.4.2
I have now started the release process and created a draft of release notes at https://cwiki.apache.org/confluence/display/LUCENE/Release+Notes+9.4.2. Feel free to edit directly if you have improvements in mind. On Wed, Nov 16, 2022 at 4:57 PM Robert Muir wrote: > +1, thanks for the patience. I feel we at least made the effort to > root out any more of these and hopefully prevent a 9.4.3 with another > overflow bug. > > On Wed, Nov 16, 2022 at 10:55 AM Adrien Grand wrote: > > > > It looks like we're good with the changes we wanted to get in for 9.4.2. > > > > I plan on starting the release process tomorrow if there are no > objections. > > > > On Fri, Nov 11, 2022 at 4:22 PM Robert Muir wrote: > >> > >> These are the 9.4.2 completed issues: > >> > >> https://github.com/apache/lucene/pull/11905 <-- bug and associated > monster test > >> https://github.com/apache/lucene/pull/11916 <-- checkindex improvement > >> https://github.com/apache/lucene/pull/11919 <-- checkindex improvement > >> > >> These are the remaining issues: > >> > >> https://github.com/apache/lucene/pull/11918 <-- better error messages, > >> looks close to being merged > >> https://github.com/apache/lucene/issues/11910 <-- static analysis: > >> after discussion on the issue, let's consider just doing a "one-time" > >> pass to look for more problems? > >> > >> On Fri, Nov 11, 2022 at 9:52 AM Michael Sokolov > wrote: > >> > > >> > +1 makes sense. I do think given this is the second similar-flavored > >> > bug we've found that we should be thorough and try to get them all > >> > rather than having a 9.4.3 ... > >> > > >> > On Wed, Nov 9, 2022 at 10:25 AM Julie Tibshirani > wrote: > >> > > > >> > > +1 from me for a bugfix release once we've solidified testing. > Thanks to everyone working on improving tests and static analysis -- this > now is our second time encountering a bad arithmetic bug and it's important > to get ahead of these issues! > >> > > > >> > > Julie > >> > > > >> > > On Wed, Nov 9, 2022 at 8:26 AM Robert Muir > wrote: > >> > >> > >> > >> Thank you Adrien! > >> > >> > >> > >> I created an issue for the static analysis piece, but I'm not > >> > >> currently working on it yet. This could be a fun one, if anyone is > >> > >> interested, to flush a bunch of these bugs out at once: > >> > >> https://github.com/apache/lucene/issues/11910 > >> > >> > >> > >> On Wed, Nov 9, 2022 at 10:48 AM Adrien Grand > wrote: > >> > >> > > >> > >> > Totally Robert, I was not trying to add any time pressure, next > week is totally fine. I mostly wanted to get the discussion started because > folks sometimes have one or two bug fixes they'd like to fold into a bugfix > release so I wanted to give them time to plan. Friday is also a public > holiday here, celebrating the end of World War 1. :) > >> > >> > > >> > >> > On Wed, Nov 9, 2022 at 4:41 PM Robert Muir > wrote: > >> > >> >> > >> > >> >> Can we please have a few days to improve the test situation? I > think > >> > >> >> we need to beef up checkindex to exercise seek() on the > vectors, also > >> > >> >> we need to look at static analysis to try to find other similar > bugs. > >> > >> >> This would help prevent "whack-a-mole" and improve correctness > going forwards. > >> > >> >> > >> > >> >> I want to help more but it's difficult timing-wise, lots of > stuff > >> > >> >> going on this week, and in my country friday is Veteran's Day > holiday. > >> > >> >> > >> > >> >> On Wed, Nov 9, 2022 at 10:39 AM Adrien Grand > wrote: > >> > >> >> > > >> > >> >> > Hello all, > >> > >> >> > > >> > >> >> > A bad integer overflow has been discovered in the KNN vectors > format, which affects segments that have more than ~16M vectors. I'd like > to do a bugfix release when the bug is fixed and we have a test for such > large datasets of KNN vectors. I volunteer to be the RM for this release. > >> > >> >> > > >> > >> >> > -- > >> > >> >> > Adrien > >> > >> >> > >> > >> >> > - > >> > >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> > >> >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > >> >> > >> > >> > > >> > >> > > >> > >> > -- > >> > >> > Adrien > >> > >> > >> > >> > - > >> > >> 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 > >> > > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > > > > > -- > > Adrien > >
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");
>> }
>>
>>
