Re: [JENKINS] Lucene » Lucene-Check-9.x - Build # 3700 - Failure!
I opened https://github.com/apache/lucene/pull/11975 to address this compile error. On Thu, Nov 24, 2022 at 6:35 PM Apache Jenkins Server < jenk...@builds.apache.org> wrote: > Build: https://ci-builds.apache.org/job/Lucene/job/Lucene-Check-9.x/3700/ > > All tests passed > > Build Log: > [...truncated 1349 lines...] > BUILD FAILED in 18m 58s > 768 actionable tasks: 768 executed > Build step 'Invoke Gradle script' changed build result to FAILURE > Build step 'Invoke Gradle script' marked build as failure > Archiving artifacts > Recording test results > [Checks API] No suitable checks publisher found. > Email was triggered for: Failure - Any > Sending email for trigger: Failure - Any > > - > To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org > For additional commands, e-mail: builds-h...@lucene.apache.org
Re: [lucene] branch main updated: More refactoring work, and fix a distance calculation.
Thanks, I was unable to get to this until this morning.
The code was dead because the corresponding call hadn't been included.
Fixed now.
Karl
On Thu, Nov 24, 2022 at 5:50 AM Adrien Grand wrote:
> Karl, this commit has been failing precommit because it introduced
> dead code. I just pushed a fix.
>
>
> On Thu, Nov 24, 2022 at 10:47 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 839dfb5a2dc More refactoring work, and fix a distance
> calculation.
> > 839dfb5a2dc is described below
> >
> > commit 839dfb5a2dc46c4b2d16d9db5ea9f31ca1e8d907
> > Author: Karl David Wright
> > AuthorDate: Wed Nov 23 23:36:15 2022 -0500
> >
> > More refactoring work, and fix a distance calculation.
> > ---
> > .../lucene/spatial3d/geom/GeoDegeneratePath.java | 32 ++---
> > .../lucene/spatial3d/geom/GeoStandardPath.java | 54
> --
> > .../apache/lucene/spatial3d/geom/TestGeoPath.java | 12 +++--
> > 3 files changed, 62 insertions(+), 36 deletions(-)
> >
> > diff --git
> a/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoDegeneratePath.java
> b/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoDegeneratePath.java
> > index 524451ac68a..d1a452ca566 100644
> > ---
> a/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoDegeneratePath.java
> > +++
> b/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoDegeneratePath.java
> > @@ -282,7 +282,7 @@ class GeoDegeneratePath extends GeoBasePath {
> > minDistance = newDistance;
> >}
> > }
> > -return minDistance;
> > +return distanceStyle.fromAggregationForm(minDistance);
> >}
> >
> >@Override
> > @@ -468,6 +468,15 @@ class GeoDegeneratePath extends GeoBasePath {
> >return this.point.isIdentical(x, y, z);
> > }
> >
> > +public boolean isWithinSection(final double x, final double y,
> final double z) {
> > + for (final Membership cutoffPlane : cutoffPlanes) {
> > +if (!cutoffPlane.isWithin(x, y, z)) {
> > + return false;
> > +}
> > + }
> > + return true;
> > +}
> > +
> > /**
> > * Compute interior path distance.
> > *
> > @@ -502,7 +511,7 @@ class GeoDegeneratePath extends GeoBasePath {
> >return Double.POSITIVE_INFINITY;
> > }
> >}
> > - return distanceStyle.computeDistance(this.point, x, y, z);
> > + return
> distanceStyle.toAggregationForm(distanceStyle.computeDistance(this.point,
> x, y, z));
> > }
> >
> > /**
> > @@ -516,7 +525,7 @@ class GeoDegeneratePath extends GeoBasePath {
> > */
> > public double outsideDistance(
> > final DistanceStyle distanceStyle, final double x, final double
> y, final double z) {
> > - return distanceStyle.computeDistance(this.point, x, y, z);
> > + return
> distanceStyle.toAggregationForm(distanceStyle.computeDistance(this.point,
> x, y, z));
> > }
> >
> > /**
> > @@ -578,7 +587,7 @@ class GeoDegeneratePath extends GeoBasePath {
> >
> > @Override
> > public String toString() {
> > - return point.toString();
> > + return "SegmentEndpoint: " + point;
> > }
> >}
> >
> > @@ -659,6 +668,10 @@ class GeoDegeneratePath extends GeoBasePath {
> >&& normalizedConnectingPlane.evaluateIsZero(x, y, z);
> > }
> >
> > +public boolean isWithinSection(final double x, final double y,
> final double z) {
> > + return startCutoffPlane.isWithin(x, y, z) &&
> endCutoffPlane.isWithin(x, y, z);
> > +}
> > +
> > /**
> > * Compute path center distance (distance from path to current
> point).
> > *
> > @@ -671,7 +684,7 @@ class GeoDegeneratePath extends GeoBasePath {
> > public double pathCenterDistance(
> > final DistanceStyle distanceStyle, final double x, final double
> y, final double z) {
> >// First, if this point is outside the endplanes of the segment,
> return POSITIVE_INFINITY.
> > - if (!startCutoffPlane.isWithin(x, y, z) ||
> !endCutoffPlane.isWithin(x, y, z)) {
> > + if (!isWithinSection(x, y, z)) {
> > return Double.POSITIVE_INFINITY;
> >}
> >// (1) Compute normalizedPerpPlane. If degenerate, then there is
> no such plane, which means
> > @@ -710,7 +723,7 @@ class GeoDegeneratePath extends GeoBasePath {
> >"Can't find world intersection for point x=" + x + " y="
> + y + " z=" + z);
> > }
> >}
> > - return distanceStyle.computeDistance(thePoint, x, y, z);
> > + return
> distanceStyle.toAggregationForm(distanceStyle.computeDistance(thePoint, x,
> y, z));
> > }
> >
> > /**
> > @@ -726,7 +739,7 @@ class GeoDegeneratePath extends GeoBasePath {
> > public
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: More refactoring work, and fix a distance calculation.
Karl, this commit has been failing precommit because it introduced
dead code. I just pushed a fix.
On Thu, Nov 24, 2022 at 10:47 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 839dfb5a2dc More refactoring work, and fix a distance calculation.
> 839dfb5a2dc is described below
>
> commit 839dfb5a2dc46c4b2d16d9db5ea9f31ca1e8d907
> Author: Karl David Wright
> AuthorDate: Wed Nov 23 23:36:15 2022 -0500
>
> More refactoring work, and fix a distance calculation.
> ---
> .../lucene/spatial3d/geom/GeoDegeneratePath.java | 32 ++---
> .../lucene/spatial3d/geom/GeoStandardPath.java | 54
> --
> .../apache/lucene/spatial3d/geom/TestGeoPath.java | 12 +++--
> 3 files changed, 62 insertions(+), 36 deletions(-)
>
> diff --git
> a/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoDegeneratePath.java
>
> b/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoDegeneratePath.java
> index 524451ac68a..d1a452ca566 100644
> ---
> a/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoDegeneratePath.java
> +++
> b/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoDegeneratePath.java
> @@ -282,7 +282,7 @@ class GeoDegeneratePath extends GeoBasePath {
> minDistance = newDistance;
>}
> }
> -return minDistance;
> +return distanceStyle.fromAggregationForm(minDistance);
>}
>
>@Override
> @@ -468,6 +468,15 @@ class GeoDegeneratePath extends GeoBasePath {
>return this.point.isIdentical(x, y, z);
> }
>
> +public boolean isWithinSection(final double x, final double y, final
> double z) {
> + for (final Membership cutoffPlane : cutoffPlanes) {
> +if (!cutoffPlane.isWithin(x, y, z)) {
> + return false;
> +}
> + }
> + return true;
> +}
> +
> /**
> * Compute interior path distance.
> *
> @@ -502,7 +511,7 @@ class GeoDegeneratePath extends GeoBasePath {
>return Double.POSITIVE_INFINITY;
> }
>}
> - return distanceStyle.computeDistance(this.point, x, y, z);
> + return
> distanceStyle.toAggregationForm(distanceStyle.computeDistance(this.point, x,
> y, z));
> }
>
> /**
> @@ -516,7 +525,7 @@ class GeoDegeneratePath extends GeoBasePath {
> */
> public double outsideDistance(
> final DistanceStyle distanceStyle, final double x, final double y,
> final double z) {
> - return distanceStyle.computeDistance(this.point, x, y, z);
> + return
> distanceStyle.toAggregationForm(distanceStyle.computeDistance(this.point, x,
> y, z));
> }
>
> /**
> @@ -578,7 +587,7 @@ class GeoDegeneratePath extends GeoBasePath {
>
> @Override
> public String toString() {
> - return point.toString();
> + return "SegmentEndpoint: " + point;
> }
>}
>
> @@ -659,6 +668,10 @@ class GeoDegeneratePath extends GeoBasePath {
>&& normalizedConnectingPlane.evaluateIsZero(x, y, z);
> }
>
> +public boolean isWithinSection(final double x, final double y, final
> double z) {
> + return startCutoffPlane.isWithin(x, y, z) &&
> endCutoffPlane.isWithin(x, y, z);
> +}
> +
> /**
> * Compute path center distance (distance from path to current point).
> *
> @@ -671,7 +684,7 @@ class GeoDegeneratePath extends GeoBasePath {
> public double pathCenterDistance(
> final DistanceStyle distanceStyle, final double x, final double y,
> final double z) {
>// First, if this point is outside the endplanes of the segment,
> return POSITIVE_INFINITY.
> - if (!startCutoffPlane.isWithin(x, y, z) || !endCutoffPlane.isWithin(x,
> y, z)) {
> + if (!isWithinSection(x, y, z)) {
> return Double.POSITIVE_INFINITY;
>}
>// (1) Compute normalizedPerpPlane. If degenerate, then there is no
> such plane, which means
> @@ -710,7 +723,7 @@ class GeoDegeneratePath extends GeoBasePath {
>"Can't find world intersection for point x=" + x + " y=" + y +
> " z=" + z);
> }
>}
> - return distanceStyle.computeDistance(thePoint, x, y, z);
> + return
> distanceStyle.toAggregationForm(distanceStyle.computeDistance(thePoint, x, y,
> z));
> }
>
> /**
> @@ -726,7 +739,7 @@ class GeoDegeneratePath extends GeoBasePath {
> public double nearestPathDistance(
> final DistanceStyle distanceStyle, final double x, final double y,
> final double z) {
>// First, if this point is outside the endplanes of the segment,
> return POSITIVE_INFINITY.
> - if (!startCutoffPlane.isWithin(x, y, z) || !endCutoffPlane.isWithin(x,
> y, z)) {
> + if (!isWithinSection(x, y, z)) {
> return Double.POSITIVE_INFINITY;
>
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 >
