Mailing List Archive

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 <dawid.weiss@gmail.com> 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 <kwright@apache.org> 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 <kwright@apache.org>
>> 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");
>> }
>>
>>

> 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

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 <dawid.weiss@gmail.com> 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
>

> 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

>

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 <daddywri@gmail.com> 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 <dawid.weiss@gmail.com> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

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 <rcmuir@gmail.com> 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 <daddywri@gmail.com> 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 <dawid.weiss@gmail.com> 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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

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 <dawid.weiss@gmail.com>:
>
> ?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 <rcmuir@gmail.com> 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 <daddywri@gmail.com> 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 <dawid.weiss@gmail.com> 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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

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 <jan.asf@cominvent.com> 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 <dawid.weiss@gmail.com>:
>
> ?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 <rcmuir@gmail.com> 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 <daddywri@gmail.com> 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 <dawid.weiss@gmail.com> 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-unsubscribe@lucene.apache.org
>
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

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 <daddywri@gmail.com> 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 <jan.asf@cominvent.com> 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 <dawid.weiss@gmail.com>:
>>
>> ?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 <rcmuir@gmail.com> 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 <daddywri@gmail.com> 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 <dawid.weiss@gmail.com>
>> 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-unsubscribe@lucene.apache.org
>>
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>