[jira] [Commented] (LUCENE-9997) Revisit smoketester for 9.0 build
[
https://issues.apache.org/jira/browse/LUCENE-9997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17429869#comment-17429869
]
Dawid Weiss commented on LUCENE-9997:
-
Filed a PR here:
https://github.com/apache/lucene/pull/392
> Revisit smoketester for 9.0 build
> -
>
> Key: LUCENE-9997
> URL: https://issues.apache.org/jira/browse/LUCENE-9997
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Robert Muir
>Priority: Major
> Attachments: image-2021-10-12-12-47-11-480.png,
> image-2021-10-12-12-48-15-373.png
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> Currently we have a (great) {{dev-tools/scripts/smokeTester.py}} that will
> perform automated tests against a release.
> This was developed with the ant build process in mind.
> This issue is just about considering the automated checks we do here, maybe
> some of them can be done efficiently in the gradle build in earlier places:
> this would be a large improvement!
> Obviously some of them (e.g. GPG release key verifications) are really
> specific to the artifacts in question. These are most important to release
> verification, as that is actually the only place we can check it.
> Any other checks (and I do tend to think, this checker should try to be
> thorough, invoking gradle etc), should be stuff we regularly test in
> PRs/nightly/builds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] rmuir commented on a change in pull request #389: LUCENE-10159: Fix invalid access in sorted set dv
rmuir commented on a change in pull request #389:
URL: https://github.com/apache/lucene/pull/389#discussion_r730728533
##
File path:
lucene/core/src/java/org/apache/lucene/codecs/lucene90/Lucene90DocValuesProducer.java
##
@@ -1402,15 +1403,23 @@ public int docID() {
@Override
public int nextDoc() throws IOException {
int doc = ords.nextDoc();
-count = ords.docValueCount();
+if (doc != NO_MORE_DOCS) {
+ count = ords.docValueCount();
+} else {
+ count = 0;
+}
i = 0;
return doc;
}
@Override
public int advance(int target) throws IOException {
int doc = ords.advance(target);
-count = ords.docValueCount();
+if (doc != NO_MORE_DOCS) {
+ count = ords.docValueCount();
+} else {
+ count = 0;
+}
Review comment:
@jpountz that isn't the problem. the problem is that we call
`docValueCount` "eagerly" ourselves inside of `next`/`advance` and cache it. I
don't know why that is.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] rmuir commented on pull request #389: LUCENE-10159: Fix invalid access in sorted set dv
rmuir commented on pull request #389:
URL: https://github.com/apache/lucene/pull/389#issuecomment-945586019
Seems a lot easier to just test this via SORTED_NUMERIC. There isn't any
point in testing SORTED_SET as it only makes things more difficult.
The test should fail without the fix and pass with the fix, so there is no
"use" to be had otherwise.
As far as Asserting, maybe you misunderstand the issue. It does not happen
via the public API, so such a class cannot catch it? It happens via
implementation detail:
```
NumericDocValues ords = ... // fetch internal
return new SortedNumericDocvalues() { ... } // buggy delegator
```
Why do we have all this delegation?
If we truly must delegate, why not delegate docValueCount too?
I don't understand why we eagerly invoke it in next/advance and cache it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] jpountz commented on a change in pull request #389: LUCENE-10159: Fix invalid access in sorted set dv
jpountz commented on a change in pull request #389:
URL: https://github.com/apache/lucene/pull/389#discussion_r730745755
##
File path:
lucene/core/src/java/org/apache/lucene/codecs/lucene90/Lucene90DocValuesProducer.java
##
@@ -1402,15 +1403,23 @@ public int docID() {
@Override
public int nextDoc() throws IOException {
int doc = ords.nextDoc();
-count = ords.docValueCount();
+if (doc != NO_MORE_DOCS) {
+ count = ords.docValueCount();
+} else {
+ count = 0;
+}
i = 0;
return doc;
}
@Override
public int advance(int target) throws IOException {
int doc = ords.advance(target);
-count = ords.docValueCount();
+if (doc != NO_MORE_DOCS) {
+ count = ords.docValueCount();
+} else {
+ count = 0;
+}
Review comment:
I agree we need to change this. We could use the same approach that we
use in `getSortedNumeric` by having a `boolean set` flag to only read values if
they are actually needed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] jpountz commented on pull request #389: LUCENE-10159: Fix invalid access in sorted set dv
jpountz commented on pull request #389: URL: https://github.com/apache/lucene/pull/389#issuecomment-945593285 > Why do we have all this delegation? It was a way to have sorted set doc values automatically benefit from the specialization of sorted numeric doc values without duplicating all the specialized cases. > If we truly must delegate, why not delegate docValueCount too? Sorted set doc values don't have a `docValueCount` API, they're just expected to return `NO_MORE_ORDS` when all ords have been exhausted. > I don't understand why we eagerly invoke it in next/advance and cache it. +1 to change this. This would fix the bug, and probably also help a bit when the iterator is used to iterate over docs that have a value while never reading the values, such as with `DocValueFieldExistsQuery`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] janhoy commented on pull request #392: LUCENE-9997: Collect signed maven artifacts if -Psign is passed.
janhoy commented on pull request #392: URL: https://github.com/apache/lucene/pull/392#issuecomment-945617644 I run the build with this patch, but get errors ``` > Task :lucene:backward-codecs:javadocJar Caching disabled for task ':lucene:backward-codecs:javadocJar' because: Build cache is disabled Task ':lucene:backward-codecs:javadocJar' is not up-to-date because: Output property 'archiveFile' file /Users/janhoy/git/lucene/lucene/backward-codecs/build/libs/lucene-backward-codecs-9.0.0-javadoc.jar has been removed. :lucene:backward-codecs:javadocJar (Thread[Execution worker for ':' Thread 6,5,main]) completed. Took 0.072 secs. :lucene:backward-codecs:signSignedJarsPublication (Thread[Execution worker for ':' Thread 6,5,main]) started. > Task :lucene:backward-codecs:signSignedJarsPublication FAILED Caching disabled for task ':lucene:backward-codecs:signSignedJarsPublication' because: Build cache is disabled Task ':lucene:backward-codecs:signSignedJarsPublication' is not up-to-date because: Task has failed previously. :lucene:backward-codecs:signSignedJarsPublication (Thread[Execution worker for ':' Thread 6,5,main]) completed. Took 0.002 secs. [...] FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':lucene:backward-codecs:signSignedJarsPublication'. > Cannot perform signing task ':lucene:backward-codecs:signSignedJarsPublication' because it has no configured signatory ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] janhoy commented on pull request #392: LUCENE-9997: Collect signed maven artifacts if -Psign is passed.
janhoy commented on pull request #392: URL: https://github.com/apache/lucene/pull/392#issuecomment-945628415 I made the build pass when trying the java-based signing (`-Psign -Psigning.keyId="" -Psigning.password=$GPGPASS -Psigning.secretKeyRingFile=$HOME/.gnupg/secring.gpg`), but it does not work for gpg (`-Psign -PuseGpg -Psigning.gnupg.keyName="" -Psigning.gnupg.passphrase=$GPGPASS`) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10182) TestRamUsageEstimator asserts trivial equality
[
https://issues.apache.org/jira/browse/LUCENE-10182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17429927#comment-17429927
]
Stefan Vodita commented on LUCENE-10182:
I pushed a change renaming {{RamUsageTester.sizeOf}} to {{ramUsed}}. Let me
know if this solution looks better to you.
> TestRamUsageEstimator asserts trivial equality
> --
>
> Key: LUCENE-10182
> URL: https://issues.apache.org/jira/browse/LUCENE-10182
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Stefan Vodita
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{TestRamUsageEstimator.testStaticOverloads}} has serveral lines like:
> {code:java}
> assertEquals(sizeOf(array), sizeOf((Object) array));
> {code}
> Both calls to {{sizeOf()}} fall back on {{RamUsageTester.sizeOf}}, making the
> 2 calls identical. Instead, we would want one of the calls to go to
> {{RamUsageEstimator.sizeOf}}.
>
> This issue came up while working on LUCENE-10129. A possible solution, as per
> [~uschindler]'s suggestion, would be to remove the static import
> {code:java}
> import static org.apache.lucene.util.RamUsageTester.sizeOf;
> {code}
> Instead, we could be explicit on which method we are calling, like:
> {code:java}
> assertEquals(RamUsageEstimator.sizeOf(array), RamUsageTester.sizeOf(array));
> {code}
> This could be replicated for other potentially confusing cases in the test
> class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10054) Handle hierarchy in HNSW graph
[ https://issues.apache.org/jira/browse/LUCENE-10054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17429958#comment-17429958 ] Michael McCandless commented on LUCENE-10054: - [~mayya] this looks like an awesome improvement! Can this maybe be resolved now? Or are we leaving it open to support the hierarchy also on-disk? Maybe open a separate spinoff issue for that? > Handle hierarchy in HNSW graph > -- > > Key: LUCENE-10054 > URL: https://issues.apache.org/jira/browse/LUCENE-10054 > Project: Lucene - Core > Issue Type: Task >Reporter: Mayya Sharipova >Priority: Major > Time Spent: 8.5h > Remaining Estimate: 0h > > Currently HNSW graph is represented as a single layer graph. > We would like to extend it to handle hierarchy as per > [discussion|https://issues.apache.org/jira/browse/LUCENE-9004?focusedCommentId=17393216&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17393216]. > > > TODO tasks: > - add multiple layers in the HnswGraph class > - modify the format in Lucene90HnswVectorsWriter and > Lucene90HnswVectorsReader to handle multiple layers > - modify graph construction and search algorithm to handle hierarchy > - run benchmarks -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] jpountz commented on pull request #389: LUCENE-10159: Fix invalid access in sorted set dv
jpountz commented on pull request #389: URL: https://github.com/apache/lucene/pull/389#issuecomment-945690914 > As far as Asserting, maybe you misunderstand the issue Sorry you are right indeed, AssertingDVFormat cannot help here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] dweiss commented on pull request #392: LUCENE-9997: Collect signed maven artifacts if -Psign is passed.
dweiss commented on pull request #392: URL: https://github.com/apache/lucene/pull/392#issuecomment-945778193 Eh. Ok, I'll take another look. It's all a bit of a black-box with those plugins... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] xiaoshi2013 commented on pull request #301: LUCENE-10100: same as 10091 Fix some old errors in the main branch
xiaoshi2013 commented on pull request #301: URL: https://github.com/apache/lucene/pull/301#issuecomment-945829893 Hi @mikemccand , I've updated some of the descriptions, can you take a look at this pr? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10182) TestRamUsageEstimator asserts trivial equality
[
https://issues.apache.org/jira/browse/LUCENE-10182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430044#comment-17430044
]
Dawid Weiss commented on LUCENE-10182:
--
I like this explicit version better. [~uschindler]?
> TestRamUsageEstimator asserts trivial equality
> --
>
> Key: LUCENE-10182
> URL: https://issues.apache.org/jira/browse/LUCENE-10182
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Stefan Vodita
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{TestRamUsageEstimator.testStaticOverloads}} has serveral lines like:
> {code:java}
> assertEquals(sizeOf(array), sizeOf((Object) array));
> {code}
> Both calls to {{sizeOf()}} fall back on {{RamUsageTester.sizeOf}}, making the
> 2 calls identical. Instead, we would want one of the calls to go to
> {{RamUsageEstimator.sizeOf}}.
>
> This issue came up while working on LUCENE-10129. A possible solution, as per
> [~uschindler]'s suggestion, would be to remove the static import
> {code:java}
> import static org.apache.lucene.util.RamUsageTester.sizeOf;
> {code}
> Instead, we could be explicit on which method we are calling, like:
> {code:java}
> assertEquals(RamUsageEstimator.sizeOf(array), RamUsageTester.sizeOf(array));
> {code}
> This could be replicated for other potentially confusing cases in the test
> class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] mocobeta commented on a change in pull request #391: LUCENE-9997 Second pass smoketester fixes for 9.0
mocobeta commented on a change in pull request #391:
URL: https://github.com/apache/lucene/pull/391#discussion_r731013013
##
File path: dev-tools/scripts/smokeTestRelease.py
##
@@ -1033,7 +1030,7 @@ def
confirmAllReleasesAreTestedForBackCompat(smokeVersion, unpackPath):
os.chdir(unpackPath)
print('run TestBackwardsCompatibility..')
- command = 'gradlew test -p lucene/backward-codecs --tests
TestBackwardsCompatibility --max-workers=1 ' \
+ command = './gradlew test -p lucene/backward-codecs --tests
TestBackwardsCompatibility --max-workers=1 ' \
Review comment:
Is this work on Windows?
I haven't tried it on Windows but just noticed this script doesn't append
`./` to commands in branch_8x.
For example:
https://github.com/apache/lucene-solr/blob/277e1e064559117ccbc3004be88160bf24380d55/dev-tools/scripts/smokeTestRelease.py#L1326
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] mocobeta commented on a change in pull request #391: LUCENE-9997 Second pass smoketester fixes for 9.0
mocobeta commented on a change in pull request #391:
URL: https://github.com/apache/lucene/pull/391#discussion_r731013013
##
File path: dev-tools/scripts/smokeTestRelease.py
##
@@ -1033,7 +1030,7 @@ def
confirmAllReleasesAreTestedForBackCompat(smokeVersion, unpackPath):
os.chdir(unpackPath)
print('run TestBackwardsCompatibility..')
- command = 'gradlew test -p lucene/backward-codecs --tests
TestBackwardsCompatibility --max-workers=1 ' \
+ command = './gradlew test -p lucene/backward-codecs --tests
TestBackwardsCompatibility --max-workers=1 ' \
Review comment:
Does this work on Windows?
I haven't tried it on Windows but just noticed this script doesn't append
`./` to commands in branch_8x.
For example:
https://github.com/apache/lucene-solr/blob/277e1e064559117ccbc3004be88160bf24380d55/dev-tools/scripts/smokeTestRelease.py#L1326
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] dweiss commented on pull request #392: LUCENE-9997: Collect signed maven artifacts if -Psign is passed.
dweiss commented on pull request #392: URL: https://github.com/apache/lucene/pull/392#issuecomment-945885397 I've corrected the setup to configure the signing plugin across all projects - this should fix the problem. It works for me locally (with gpg), although on Windows it displays concurrent lock warnings (multiple threads trying to sign at the same time). I don't think it's a problem. It also made me think whether we need two options... perhaps -Psign could be an alias for the java-based signer and -Psign=gpg could be used to indicate signing via GPG? One option less to remember? Can be done later as well. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] mocobeta commented on a change in pull request #391: LUCENE-9997 Second pass smoketester fixes for 9.0
mocobeta commented on a change in pull request #391: URL: https://github.com/apache/lucene/pull/391#discussion_r731075943 ## File path: dev-tools/scripts/smokeTestRelease.py ## @@ -539,58 +529,72 @@ def unpackAndVerify(java, tmpDir, artifact, gitRevision, version, testArgs): LUCENE_LICENSE = None +def is_in_list(in_folder, files, indent=4): Review comment: nice refactoring! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10182) TestRamUsageEstimator asserts trivial equality
[
https://issues.apache.org/jira/browse/LUCENE-10182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430077#comment-17430077
]
Uwe Schindler commented on LUCENE-10182:
+1. I approved the pull request.
> TestRamUsageEstimator asserts trivial equality
> --
>
> Key: LUCENE-10182
> URL: https://issues.apache.org/jira/browse/LUCENE-10182
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Stefan Vodita
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{TestRamUsageEstimator.testStaticOverloads}} has serveral lines like:
> {code:java}
> assertEquals(sizeOf(array), sizeOf((Object) array));
> {code}
> Both calls to {{sizeOf()}} fall back on {{RamUsageTester.sizeOf}}, making the
> 2 calls identical. Instead, we would want one of the calls to go to
> {{RamUsageEstimator.sizeOf}}.
>
> This issue came up while working on LUCENE-10129. A possible solution, as per
> [~uschindler]'s suggestion, would be to remove the static import
> {code:java}
> import static org.apache.lucene.util.RamUsageTester.sizeOf;
> {code}
> Instead, we could be explicit on which method we are calling, like:
> {code:java}
> assertEquals(RamUsageEstimator.sizeOf(array), RamUsageTester.sizeOf(array));
> {code}
> This could be replicated for other potentially confusing cases in the test
> class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] dnhatn commented on pull request #389: LUCENE-10159: Fix invalid access in sorted set dv
dnhatn commented on pull request #389: URL: https://github.com/apache/lucene/pull/389#issuecomment-945953376 > Seems a lot easier to just test this via SORTED_NUMERIC. There isn't any point in testing SORTED_SET as it only makes things more difficult. @rmuir @jpountz Thanks for your reviews and discussion. I think the issue only affects the sorted_set dv. I've simplified the unit test and applied the solution that you both discussed. Can you give it another look. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-10182) TestRamUsageEstimator asserts trivial equality
[
https://issues.apache.org/jira/browse/LUCENE-10182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler reassigned LUCENE-10182:
--
Assignee: Uwe Schindler
> TestRamUsageEstimator asserts trivial equality
> --
>
> Key: LUCENE-10182
> URL: https://issues.apache.org/jira/browse/LUCENE-10182
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Stefan Vodita
>Assignee: Uwe Schindler
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{TestRamUsageEstimator.testStaticOverloads}} has serveral lines like:
> {code:java}
> assertEquals(sizeOf(array), sizeOf((Object) array));
> {code}
> Both calls to {{sizeOf()}} fall back on {{RamUsageTester.sizeOf}}, making the
> 2 calls identical. Instead, we would want one of the calls to go to
> {{RamUsageEstimator.sizeOf}}.
>
> This issue came up while working on LUCENE-10129. A possible solution, as per
> [~uschindler]'s suggestion, would be to remove the static import
> {code:java}
> import static org.apache.lucene.util.RamUsageTester.sizeOf;
> {code}
> Instead, we could be explicit on which method we are calling, like:
> {code:java}
> assertEquals(RamUsageEstimator.sizeOf(array), RamUsageTester.sizeOf(array));
> {code}
> This could be replicated for other potentially confusing cases in the test
> class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10182) TestRamUsageEstimator asserts trivial equality
[
https://issues.apache.org/jira/browse/LUCENE-10182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430123#comment-17430123
]
Uwe Schindler commented on LUCENE-10182:
I will merge this later in the evening.
Should we backport this to 8.x, as the no-op tests are actually a bug?
> TestRamUsageEstimator asserts trivial equality
> --
>
> Key: LUCENE-10182
> URL: https://issues.apache.org/jira/browse/LUCENE-10182
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Stefan Vodita
>Assignee: Uwe Schindler
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{TestRamUsageEstimator.testStaticOverloads}} has serveral lines like:
> {code:java}
> assertEquals(sizeOf(array), sizeOf((Object) array));
> {code}
> Both calls to {{sizeOf()}} fall back on {{RamUsageTester.sizeOf}}, making the
> 2 calls identical. Instead, we would want one of the calls to go to
> {{RamUsageEstimator.sizeOf}}.
>
> This issue came up while working on LUCENE-10129. A possible solution, as per
> [~uschindler]'s suggestion, would be to remove the static import
> {code:java}
> import static org.apache.lucene.util.RamUsageTester.sizeOf;
> {code}
> Instead, we could be explicit on which method we are calling, like:
> {code:java}
> assertEquals(RamUsageEstimator.sizeOf(array), RamUsageTester.sizeOf(array));
> {code}
> This could be replicated for other potentially confusing cases in the test
> class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9997) Revisit smoketester for 9.0 build
[
https://issues.apache.org/jira/browse/LUCENE-9997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430157#comment-17430157
]
Dawid Weiss commented on LUCENE-9997:
-
The smoke tester writes a repository-local file "rev.txt" and pollutes pristine
local state. I'm not sure why it's doing it but perhaps it should be writing to
temp?
{code:java}
with open('rev.txt', mode='wb') as f:
f.write(rev.encode('UTF-8')) {code}
> Revisit smoketester for 9.0 build
> -
>
> Key: LUCENE-9997
> URL: https://issues.apache.org/jira/browse/LUCENE-9997
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Robert Muir
>Priority: Major
> Attachments: image-2021-10-12-12-47-11-480.png,
> image-2021-10-12-12-48-15-373.png
>
> Time Spent: 5h 50m
> Remaining Estimate: 0h
>
> Currently we have a (great) {{dev-tools/scripts/smokeTester.py}} that will
> perform automated tests against a release.
> This was developed with the ant build process in mind.
> This issue is just about considering the automated checks we do here, maybe
> some of them can be done efficiently in the gradle build in earlier places:
> this would be a large improvement!
> Obviously some of them (e.g. GPG release key verifications) are really
> specific to the artifacts in question. These are most important to release
> verification, as that is actually the only place we can check it.
> Any other checks (and I do tend to think, this checker should try to be
> thorough, invoking gradle etc), should be stuff we regularly test in
> PRs/nightly/builds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9997) Revisit smoketester for 9.0 build
[
https://issues.apache.org/jira/browse/LUCENE-9997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430165#comment-17430165
]
Dawid Weiss commented on LUCENE-9997:
-
Also, the beauty of gradle is that we (in theory) wouldn't have to clean prior
to running assembleRelease (which would make the smoke tester much faster).
Gradle should handle all the incremental changes and synchronizations - files
are not copied, they're synced to the distribution submodule. If you feel safer
with a "clean" then I'd suggest running "git clean -xfd ." as it really
restores the pristine state of the repository.
> Revisit smoketester for 9.0 build
> -
>
> Key: LUCENE-9997
> URL: https://issues.apache.org/jira/browse/LUCENE-9997
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Robert Muir
>Priority: Major
> Attachments: image-2021-10-12-12-47-11-480.png,
> image-2021-10-12-12-48-15-373.png
>
> Time Spent: 5h 50m
> Remaining Estimate: 0h
>
> Currently we have a (great) {{dev-tools/scripts/smokeTester.py}} that will
> perform automated tests against a release.
> This was developed with the ant build process in mind.
> This issue is just about considering the automated checks we do here, maybe
> some of them can be done efficiently in the gradle build in earlier places:
> this would be a large improvement!
> Obviously some of them (e.g. GPG release key verifications) are really
> specific to the artifacts in question. These are most important to release
> verification, as that is actually the only place we can check it.
> Any other checks (and I do tend to think, this checker should try to be
> thorough, invoking gradle etc), should be stuff we regularly test in
> PRs/nightly/builds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] dweiss merged pull request #392: LUCENE-9997: Collect signed maven artifacts if -Psign is passed.
dweiss merged pull request #392: URL: https://github.com/apache/lucene/pull/392 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] dweiss commented on pull request #391: LUCENE-9997 Second pass smoketester fixes for 9.0
dweiss commented on pull request #391: URL: https://github.com/apache/lucene/pull/391#issuecomment-946072163 I merged with main where the artifact-signing changes landed. The buildAndPushRelease.py works for me (although it does create that stray file so I suspect it won't run properly unless in dev mode). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] mikemccand commented on pull request #375: LUCENE-10093: first cut at fixing conflicting test assert and improving TMP javadocs
mikemccand commented on pull request #375: URL: https://github.com/apache/lucene/pull/375#issuecomment-946076421 OK I think this one is ready -- I downgraded all `// nocommit` to `TODO`s and merged in `main` again. For some reason `./gradlew check` in my local env fails with this: ``` Execution failed for task ':lucene:rat'. > Found 1 file(s) with errors: - Unknown license: /l/trunk/lucene/packaging/build/rat/rat-report.xml ``` And so I go look in that `rat-report.xml` and find this: ``` ``` But that file/directory (`/l/trunk/lucene/packaging/build.gradle`) does not seem to exist. I tried `./gradlew clean`, but no luck. I'm running Java 16. On a clean `main` checkout the problem does NOT happen. Weird... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] dweiss commented on pull request #375: LUCENE-10093: first cut at fixing conflicting test assert and improving TMP javadocs
dweiss commented on pull request #375: URL: https://github.com/apache/lucene/pull/375#issuecomment-946079849 gradlew clean only cleans active modules. packaging has been renamed and no longer exists. Wipe all old cruft with: git clean -xfd lucene -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-10185) gradle check fails on java 17 (security manager deprecation)
Robert Muir created LUCENE-10185:
Summary: gradle check fails on java 17 (security manager
deprecation)
Key: LUCENE-10185
URL: https://issues.apache.org/jira/browse/LUCENE-10185
Project: Lucene - Core
Issue Type: Task
Reporter: Robert Muir
I don't think we should add SuppressWarnings here, instead fix our ECJ linter
configuration. Seems like we should be specifying something similar to
"-release 11" and it shouldn't care about the new deprecations from java 17. Or
if we can't do that, maybe we should disable the "deprecated for removal" check
in ECJ entirely?
{noformat}
> Task :lucene:core:ecjLintMain
--
1. ERROR in
/home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
(at line 42)
final SecurityManager s = System.getSecurityManager();
^^^
The type SecurityManager has been deprecated since version 17 and marked for
removal
--
2. ERROR in
/home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
(at line 42)
final SecurityManager s = System.getSecurityManager();
The method getSecurityManager() from the type System has been deprecated since
version 17 and marked for removal
--
3. ERROR in
/home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
(at line 43)
group = (s != null) ? s.getThreadGroup() :
Thread.currentThread().getThreadGroup();
The method getThreadGroup() from the type SecurityManager has been deprecated
and marked for removal
--
--
4. ERROR in
/home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
(at line 23)
import java.security.AccessControlException;
The type AccessControlException has been deprecated since version 17 and marked
for removal
--
5. ERROR in
/home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
(at line 24)
import java.security.AccessController;
^^
The type AccessController has been deprecated since version 17 and marked for
removal
--
6. ERROR in
/home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
(at line 574)
AccessController.doPrivileged((PrivilegedAction)
target::getDeclaredFields);
The type AccessController has been deprecated since version 17 and marked for
removal
--
7. ERROR in
/home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
(at line 574)
AccessController.doPrivileged((PrivilegedAction)
target::getDeclaredFields);
^^^
The method doPrivileged(PrivilegedAction) from the type
AccessController has been deprecated and marked for removal
--
8. ERROR in
/home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
(at line 575)
} catch (AccessControlException e) {
^^
The type AccessControlException has been deprecated since version 17 and marked
for removal
--
--
9. ERROR in
/home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
(at line 33)
import java.security.AccessController;
^^
The type AccessController has been deprecated since version 17 and marked for
removal
--
10. ERROR in
/home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
(at line 337)
AccessController.doPrivileged((PrivilegedAction)
MMapDirectory::unmapHackImpl);
The type AccessController has been deprecated since version 17 and marked for
removal
--
11. ERROR in
/home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
(at line 337)
AccessController.doPrivileged((PrivilegedAction)
MMapDirectory::unmapHackImpl);
^
The method doPrivileged(PrivilegedAction) from the type
AccessController has been deprecated and marked for removal
--
12. ERROR in
/home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
(at line 390)
AccessController.doPrivileged(
The type AccessController has been deprecated since version 17 and marked for
removal
--
13. ERROR in
/home/rmuir/workspace/lucene/lucene/core/src/java/org/apache
[jira] [Commented] (LUCENE-9997) Revisit smoketester for 9.0 build
[
https://issues.apache.org/jira/browse/LUCENE-9997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430176#comment-17430176
]
ASF subversion and git services commented on LUCENE-9997:
-
Commit c4c3c3270e4283f6cb1df4959fb0b33069941688 in lucene's branch
refs/heads/main from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene.git;h=c4c3c32 ]
LUCENE-9997: Collect signed maven artifacts if -Psign is passed. (#392)
* Collect signed maven artifacts if -Psign is passed.
* Configure signing using gpg across all projects.
> Revisit smoketester for 9.0 build
> -
>
> Key: LUCENE-9997
> URL: https://issues.apache.org/jira/browse/LUCENE-9997
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Robert Muir
>Priority: Major
> Attachments: image-2021-10-12-12-47-11-480.png,
> image-2021-10-12-12-48-15-373.png
>
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> Currently we have a (great) {{dev-tools/scripts/smokeTester.py}} that will
> perform automated tests against a release.
> This was developed with the ant build process in mind.
> This issue is just about considering the automated checks we do here, maybe
> some of them can be done efficiently in the gradle build in earlier places:
> this would be a large improvement!
> Obviously some of them (e.g. GPG release key verifications) are really
> specific to the artifacts in question. These are most important to release
> verification, as that is actually the only place we can check it.
> Any other checks (and I do tend to think, this checker should try to be
> thorough, invoking gradle etc), should be stuff we regularly test in
> PRs/nightly/builds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10182) TestRamUsageEstimator asserts trivial equality
[
https://issues.apache.org/jira/browse/LUCENE-10182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430179#comment-17430179
]
Stefan Vodita commented on LUCENE-10182:
I’d be happy to help with this. I saw mention at some point of an 8.x branch,
but I don’t see it in the repo. How does the code get backported?
> TestRamUsageEstimator asserts trivial equality
> --
>
> Key: LUCENE-10182
> URL: https://issues.apache.org/jira/browse/LUCENE-10182
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Stefan Vodita
>Assignee: Uwe Schindler
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{TestRamUsageEstimator.testStaticOverloads}} has serveral lines like:
> {code:java}
> assertEquals(sizeOf(array), sizeOf((Object) array));
> {code}
> Both calls to {{sizeOf()}} fall back on {{RamUsageTester.sizeOf}}, making the
> 2 calls identical. Instead, we would want one of the calls to go to
> {{RamUsageEstimator.sizeOf}}.
>
> This issue came up while working on LUCENE-10129. A possible solution, as per
> [~uschindler]'s suggestion, would be to remove the static import
> {code:java}
> import static org.apache.lucene.util.RamUsageTester.sizeOf;
> {code}
> Instead, we could be explicit on which method we are calling, like:
> {code:java}
> assertEquals(RamUsageEstimator.sizeOf(array), RamUsageTester.sizeOf(array));
> {code}
> This could be replicated for other potentially confusing cases in the test
> class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] mikemccand commented on pull request #375: LUCENE-10093: first cut at fixing conflicting test assert and improving TMP javadocs
mikemccand commented on pull request #375: URL: https://github.com/apache/lucene/pull/375#issuecomment-946100745 > gradlew clean only cleans active modules. packaging has been renamed and no longer exists. Wipe all old cruft with: > git clean -xfd lucene Aha! Thermonuclear clean, I like it. I'll try that. Thanks @dweiss. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10185) gradle check fails on java 17 (security manager deprecation)
[
https://issues.apache.org/jira/browse/LUCENE-10185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430189#comment-17430189
]
Robert Muir commented on LUCENE-10185:
--
The following patch seems to fix the issues around "deprecated for removals"
with java 17:
{noformat}
diff --git a/gradle/validation/ecj-lint.gradle
b/gradle/validation/ecj-lint.gradle
index 8c72f9d30f9..1027c7bd9a3 100644
--- a/gradle/validation/ecj-lint.gradle
+++ b/gradle/validation/ecj-lint.gradle
@@ -65,6 +65,7 @@ allprojects {
// Compilation environment.
args += [ "-source", project.java.sourceCompatibility ]
args += [ "-target", project.java.targetCompatibility ]
+args += [ "--release", project.java.targetCompatibility ]
args += [ "-encoding", "UTF-8"]
args += [ "-proc:none" ]
args += [ "-nowarn" ]
{noformat}
It seems to be the correct solution.
But it introduces a new failure (type safety in the AttributeSource method
handle):
{noformat}
--
1. ERROR in
/home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/AttributeFactory.java
(at line 154)
return (A) constr.invokeExact();
Type safety: Unchecked cast from Object to A
--
1 problem (1 error)
{noformat}
So I just have to figure this out (have not looked yet). My guess is the
{{--release 11}} enabled something that wasn't enabled otherwise, so it gets
angry here. We may need a SuppressWarnings or something...
{noformat}
> gradle check fails on java 17 (security manager deprecation)
>
>
> Key: LUCENE-10185
> URL: https://issues.apache.org/jira/browse/LUCENE-10185
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
>
> I don't think we should add SuppressWarnings here, instead fix our ECJ linter
> configuration. Seems like we should be specifying something similar to
> "-release 11" and it shouldn't care about the new deprecations from java 17.
> Or if we can't do that, maybe we should disable the "deprecated for removal"
> check in ECJ entirely?
> {noformat}
> > Task :lucene:core:ecjLintMain
> --
> 1. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 42)
> final SecurityManager s = System.getSecurityManager();
> ^^^
> The type SecurityManager has been deprecated since version 17 and marked for
> removal
> --
> 2. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 42)
> final SecurityManager s = System.getSecurityManager();
>
> The method getSecurityManager() from the type System has been deprecated
> since version 17 and marked for removal
> --
> 3. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 43)
> group = (s != null) ? s.getThreadGroup() :
> Thread.currentThread().getThreadGroup();
>
> The method getThreadGroup() from the type SecurityManager has been deprecated
> and marked for removal
> --
> --
> 4. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 23)
> import java.security.AccessControlException;
>
> The type AccessControlException has been deprecated since version 17 and
> marked for removal
> --
> 5. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 24)
> import java.security.AccessController;
>^^
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 6. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 574)
> AccessController.doPrivileged((PrivilegedAction)
> target::getDeclaredFields);
>
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 7. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 574)
> AccessController.doPrivileged((PrivilegedAction)
> target::getDeclaredFields);
>
> ^^^
> The method doPrivileged(PrivilegedAction) from the type
> AccessController has been deprecated and marked for removal
> --
> 8. ERROR i
[jira] [Commented] (LUCENE-10185) gradle check fails on java 17 (security manager deprecation)
[
https://issues.apache.org/jira/browse/LUCENE-10185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430190#comment-17430190
]
Robert Muir commented on LUCENE-10185:
--
I also tried upgrading ecj from 3.25.0 to 3.27.0 (in case it was some bug in
the checker that already got fixed) but it makes no difference here. cc
[~uschindler]
> gradle check fails on java 17 (security manager deprecation)
>
>
> Key: LUCENE-10185
> URL: https://issues.apache.org/jira/browse/LUCENE-10185
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
>
> I don't think we should add SuppressWarnings here, instead fix our ECJ linter
> configuration. Seems like we should be specifying something similar to
> "-release 11" and it shouldn't care about the new deprecations from java 17.
> Or if we can't do that, maybe we should disable the "deprecated for removal"
> check in ECJ entirely?
> {noformat}
> > Task :lucene:core:ecjLintMain
> --
> 1. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 42)
> final SecurityManager s = System.getSecurityManager();
> ^^^
> The type SecurityManager has been deprecated since version 17 and marked for
> removal
> --
> 2. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 42)
> final SecurityManager s = System.getSecurityManager();
>
> The method getSecurityManager() from the type System has been deprecated
> since version 17 and marked for removal
> --
> 3. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 43)
> group = (s != null) ? s.getThreadGroup() :
> Thread.currentThread().getThreadGroup();
>
> The method getThreadGroup() from the type SecurityManager has been deprecated
> and marked for removal
> --
> --
> 4. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 23)
> import java.security.AccessControlException;
>
> The type AccessControlException has been deprecated since version 17 and
> marked for removal
> --
> 5. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 24)
> import java.security.AccessController;
>^^
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 6. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 574)
> AccessController.doPrivileged((PrivilegedAction)
> target::getDeclaredFields);
>
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 7. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 574)
> AccessController.doPrivileged((PrivilegedAction)
> target::getDeclaredFields);
>
> ^^^
> The method doPrivileged(PrivilegedAction) from the type
> AccessController has been deprecated and marked for removal
> --
> 8. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 575)
> } catch (AccessControlException e) {
> ^^
> The type AccessControlException has been deprecated since version 17 and
> marked for removal
> --
> --
> 9. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
> (at line 33)
> import java.security.AccessController;
>^^
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 10. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
> (at line 337)
> AccessController.doPrivileged((PrivilegedAction)
> MMapDirectory::unmapHackImpl);
>
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 11. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
> (at line 337)
> AccessController.doPrivileged((Privil
[jira] [Commented] (LUCENE-10185) gradle check fails on java 17 (security manager deprecation)
[
https://issues.apache.org/jira/browse/LUCENE-10185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430193#comment-17430193
]
Dawid Weiss commented on LUCENE-10185:
--
Weird. Can't see why it'd generate a warning...
I don't think you need -source and -target if you're using the release flag. In
fact, they should be mutually exclusive.
> gradle check fails on java 17 (security manager deprecation)
>
>
> Key: LUCENE-10185
> URL: https://issues.apache.org/jira/browse/LUCENE-10185
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
>
> I don't think we should add SuppressWarnings here, instead fix our ECJ linter
> configuration. Seems like we should be specifying something similar to
> "-release 11" and it shouldn't care about the new deprecations from java 17.
> Or if we can't do that, maybe we should disable the "deprecated for removal"
> check in ECJ entirely?
> {noformat}
> > Task :lucene:core:ecjLintMain
> --
> 1. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 42)
> final SecurityManager s = System.getSecurityManager();
> ^^^
> The type SecurityManager has been deprecated since version 17 and marked for
> removal
> --
> 2. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 42)
> final SecurityManager s = System.getSecurityManager();
>
> The method getSecurityManager() from the type System has been deprecated
> since version 17 and marked for removal
> --
> 3. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 43)
> group = (s != null) ? s.getThreadGroup() :
> Thread.currentThread().getThreadGroup();
>
> The method getThreadGroup() from the type SecurityManager has been deprecated
> and marked for removal
> --
> --
> 4. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 23)
> import java.security.AccessControlException;
>
> The type AccessControlException has been deprecated since version 17 and
> marked for removal
> --
> 5. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 24)
> import java.security.AccessController;
>^^
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 6. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 574)
> AccessController.doPrivileged((PrivilegedAction)
> target::getDeclaredFields);
>
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 7. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 574)
> AccessController.doPrivileged((PrivilegedAction)
> target::getDeclaredFields);
>
> ^^^
> The method doPrivileged(PrivilegedAction) from the type
> AccessController has been deprecated and marked for removal
> --
> 8. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 575)
> } catch (AccessControlException e) {
> ^^
> The type AccessControlException has been deprecated since version 17 and
> marked for removal
> --
> --
> 9. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
> (at line 33)
> import java.security.AccessController;
>^^
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 10. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
> (at line 337)
> AccessController.doPrivileged((PrivilegedAction)
> MMapDirectory::unmapHackImpl);
>
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 11. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
> (at line 337)
> AccessController.doPrivileged(
[GitHub] [lucene] dweiss commented on pull request #375: LUCENE-10093: first cut at fixing conflicting test assert and improving TMP javadocs
dweiss commented on pull request #375: URL: https://github.com/apache/lucene/pull/375#issuecomment-946114742 Yeah, sorry about it. We could add an exclusion to rat-checks but these proliferate over time... When you're switching branches, git will leave temporary files behind, it sometimes creates mess like this. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10185) gradle check fails on java 17 (security manager deprecation)
[
https://issues.apache.org/jira/browse/LUCENE-10185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430196#comment-17430196
]
Robert Muir commented on LUCENE-10185:
--
[~dweiss] in the ECJ at least these options are in different categories:
{noformat}
Compliance options:
-1.3 use 1.3 compliance (-source 1.3 -target 1.1)
-1.4 + use 1.4 compliance (-source 1.3 -target 1.2)
-1.5 -5 -5.0 use 1.5 compliance (-source 1.5 -target 1.5)
-1.6 -6 -6.0 use 1.6 compliance (-source 1.6 -target 1.6)
-1.7 -7 -7.0 use 1.7 compliance (-source 1.7 -target 1.7)
-1.8 -8 -8.0 use 1.8 compliance (-source 1.8 -target 1.8)
-1.9 -9 -9.0 use 1.9 compliance (-source 1.9 -target 1.9)
-10 -10.0 use 10 compliance (-source 10 -target 10)
-11 -11.0 use 11 compliance (-source 11 -target 11)
-12 -12.0 use 12 compliance (-source 12 -target 12)
-13 -13.0 use 13 compliance (-source 13 -target 13)
-14 -14.0 use 14 compliance (-source 14 -target 14)
-15 -15.0 use 15 compliance (-source 15 -target 15)
-source set source level: 1.3 to 1.9, 10 to 15
(or 6, 6.0, etc)
-target set classfile target: 1.3 to 1.9, 10 to 15
(or 6, 6.0, etc)
cldc1.1 can also be used to generate the StackMap
attribute
...
Module compilation options:
These options are meaningful only in Java 9 environment or later.
--module-source-path
specify where to find source files for multiple modules
-p --module-path
specify where to find application modules
--processor-module-path
specify module path where annotation processors
can be found
--system Override location of system modules
--add-exports /=(,)*
specify additional package exports clauses to the
given modules
--add-reads =(,)*
specify additional modules to be considered as required
by given modules
--add-modules (,)*
specify the additional module names that should be
resolved to be root modules
--limit-modules (,)*
specify the observable module names
--release
compile for a specific VM version
{noformat}
> gradle check fails on java 17 (security manager deprecation)
>
>
> Key: LUCENE-10185
> URL: https://issues.apache.org/jira/browse/LUCENE-10185
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
>
> I don't think we should add SuppressWarnings here, instead fix our ECJ linter
> configuration. Seems like we should be specifying something similar to
> "-release 11" and it shouldn't care about the new deprecations from java 17.
> Or if we can't do that, maybe we should disable the "deprecated for removal"
> check in ECJ entirely?
> {noformat}
> > Task :lucene:core:ecjLintMain
> --
> 1. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 42)
> final SecurityManager s = System.getSecurityManager();
> ^^^
> The type SecurityManager has been deprecated since version 17 and marked for
> removal
> --
> 2. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 42)
> final SecurityManager s = System.getSecurityManager();
>
> The method getSecurityManager() from the type System has been deprecated
> since version 17 and marked for removal
> --
> 3. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 43)
> group = (s != null) ? s.getThreadGroup() :
> Thread.currentThread().getThreadGroup();
>
> The method getThreadGroup() from the type SecurityManager has been deprecated
> and marked for removal
> --
> --
> 4. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 23)
> import java.security.AccessControlException;
>
> The type AccessControlException has been deprecated since version 17 and
> marked for removal
> --
> 5. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 2
[jira] [Commented] (LUCENE-10185) gradle check fails on java 17 (security manager deprecation)
[
https://issues.apache.org/jira/browse/LUCENE-10185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430197#comment-17430197
]
Dawid Weiss commented on LUCENE-10185:
--
I can actually see this warning in intellij as well... This is the ugly
workaround.
{code:java}
@SuppressWarnings("unchecked")
A local = (A) constr.invokeExact();
return local; {code}
> gradle check fails on java 17 (security manager deprecation)
>
>
> Key: LUCENE-10185
> URL: https://issues.apache.org/jira/browse/LUCENE-10185
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
>
> I don't think we should add SuppressWarnings here, instead fix our ECJ linter
> configuration. Seems like we should be specifying something similar to
> "-release 11" and it shouldn't care about the new deprecations from java 17.
> Or if we can't do that, maybe we should disable the "deprecated for removal"
> check in ECJ entirely?
> {noformat}
> > Task :lucene:core:ecjLintMain
> --
> 1. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 42)
> final SecurityManager s = System.getSecurityManager();
> ^^^
> The type SecurityManager has been deprecated since version 17 and marked for
> removal
> --
> 2. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 42)
> final SecurityManager s = System.getSecurityManager();
>
> The method getSecurityManager() from the type System has been deprecated
> since version 17 and marked for removal
> --
> 3. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 43)
> group = (s != null) ? s.getThreadGroup() :
> Thread.currentThread().getThreadGroup();
>
> The method getThreadGroup() from the type SecurityManager has been deprecated
> and marked for removal
> --
> --
> 4. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 23)
> import java.security.AccessControlException;
>
> The type AccessControlException has been deprecated since version 17 and
> marked for removal
> --
> 5. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 24)
> import java.security.AccessController;
>^^
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 6. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 574)
> AccessController.doPrivileged((PrivilegedAction)
> target::getDeclaredFields);
>
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 7. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 574)
> AccessController.doPrivileged((PrivilegedAction)
> target::getDeclaredFields);
>
> ^^^
> The method doPrivileged(PrivilegedAction) from the type
> AccessController has been deprecated and marked for removal
> --
> 8. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 575)
> } catch (AccessControlException e) {
> ^^
> The type AccessControlException has been deprecated since version 17 and
> marked for removal
> --
> --
> 9. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
> (at line 33)
> import java.security.AccessController;
>^^
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 10. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
> (at line 337)
> AccessController.doPrivileged((PrivilegedAction)
> MMapDirectory::unmapHackImpl);
>
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 11. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
> (at line 337)
> AccessController.
[jira] [Commented] (LUCENE-10054) Handle hierarchy in HNSW graph
[ https://issues.apache.org/jira/browse/LUCENE-10054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430199#comment-17430199 ] Mayya Sharipova commented on LUCENE-10054: -- [~mikemccand] Thanks for checking. This issue is not resolved yet. We have implemented this as a [feature brach|https://github.com/apache/lucene/tree/hnsw], but it has not been merged to the `main` branch yet. Storing hierarchy on disk is already implemented in that feature branch as well. We had an idea to move some data off-heap, and run more benchmarking tests, and then open a PR against a `main` branch. > Handle hierarchy in HNSW graph > -- > > Key: LUCENE-10054 > URL: https://issues.apache.org/jira/browse/LUCENE-10054 > Project: Lucene - Core > Issue Type: Task >Reporter: Mayya Sharipova >Priority: Major > Time Spent: 8.5h > Remaining Estimate: 0h > > Currently HNSW graph is represented as a single layer graph. > We would like to extend it to handle hierarchy as per > [discussion|https://issues.apache.org/jira/browse/LUCENE-9004?focusedCommentId=17393216&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17393216]. > > > TODO tasks: > - add multiple layers in the HnswGraph class > - modify the format in Lucene90HnswVectorsWriter and > Lucene90HnswVectorsReader to handle multiple layers > - modify graph construction and search algorithm to handle hierarchy > - run benchmarks -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] rmuir opened a new pull request #393: LUCENE-10185: pass --release 11 to ECJ linter, fix JDK 17 build
rmuir opened a new pull request #393: URL: https://github.com/apache/lucene/pull/393 Otherwise, new java releases such as JDK 18, JDK 19, ... may have even more new deprecations, the build shouldn't fail in such cases. Note: I did a very simple suppression-fix for the AttributeFactory type-safety issue that pops up when enabling `--release`. If you have a better fix, please commit it in here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] dweiss commented on a change in pull request #393: LUCENE-10185: pass --release 11 to ECJ linter, fix JDK 17 build
dweiss commented on a change in pull request #393:
URL: https://github.com/apache/lucene/pull/393#discussion_r731285380
##
File path: lucene/core/src/java/org/apache/lucene/util/AttributeFactory.java
##
@@ -148,7 +148,10 @@ public int hashCode() {
AttributeFactory delegate, Class clazz) {
final MethodHandle constr = findAttributeImplCtor(clazz);
return new StaticImplementationAttributeFactory(delegate, clazz) {
+ // UweSays: It's ok. I know why it happens, but it's a bug. The type
safety is checked by the
Review comment:
Indeed. But I can't make javac complain about it if I try to do it in
stand-alone mode (with linting). It does show up in intellij though, even if it
claims it's using javac... go figure.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] rmuir commented on pull request #393: LUCENE-10185: pass --release 11 to ECJ linter, fix JDK 17 build
rmuir commented on pull request #393: URL: https://github.com/apache/lucene/pull/393#issuecomment-946137876 thanks, i nuked `-source/-release`, just wanted to test that it worked first... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] rmuir edited a comment on pull request #393: LUCENE-10185: pass --release 11 to ECJ linter, fix JDK 17 build
rmuir edited a comment on pull request #393: URL: https://github.com/apache/lucene/pull/393#issuecomment-946137876 thanks, i nuked `-source/-target`, just wanted to test that it worked first... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] rmuir commented on pull request #393: LUCENE-10185: pass --release 11 to ECJ linter, fix JDK 17 build
rmuir commented on pull request #393: URL: https://github.com/apache/lucene/pull/393#issuecomment-946139296 I am running `gradle check` with the latest commits on JDK-17 before pushing. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] uschindler commented on a change in pull request #393: LUCENE-10185: pass --release 11 to ECJ linter, fix JDK 17 build
uschindler commented on a change in pull request #393:
URL: https://github.com/apache/lucene/pull/393#discussion_r731292709
##
File path: lucene/core/src/java/org/apache/lucene/util/AttributeFactory.java
##
@@ -148,7 +148,10 @@ public int hashCode() {
AttributeFactory delegate, Class clazz) {
final MethodHandle constr = findAttributeImplCtor(clazz);
return new StaticImplementationAttributeFactory(delegate, clazz) {
+ // UweSays: It's ok. I know why it happens, but it's a bug. The type
safety is checked by the
Review comment:
I fixed it. The problem here is worse: it's a bug in ECJ so it compiles
the wrong signature. It compiles it to bytecode that calls invokeExcat with
"Object" return code (wrongly guessed). Javac does it correct. To prevent the
problem I made all casts explcit so the MethodHandle's invokeExact is called
with 100% correct signature. The unsafe cast is in following line, now marked
as unsafe (which is fine, as we know the return type).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10182) TestRamUsageEstimator asserts trivial equality
[
https://issues.apache.org/jira/browse/LUCENE-10182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430213#comment-17430213
]
Uwe Schindler commented on LUCENE-10182:
That's just a cherry-pick across different upstream repositories (the code must
be cherry-picked from new "lucene" repository to the "branch_8x" of old
"lucene-solr" repo). It needs a rather complicated setup, so I will do it. I
just wanted to know if you think it's worth.
> TestRamUsageEstimator asserts trivial equality
> --
>
> Key: LUCENE-10182
> URL: https://issues.apache.org/jira/browse/LUCENE-10182
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Stefan Vodita
>Assignee: Uwe Schindler
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{TestRamUsageEstimator.testStaticOverloads}} has serveral lines like:
> {code:java}
> assertEquals(sizeOf(array), sizeOf((Object) array));
> {code}
> Both calls to {{sizeOf()}} fall back on {{RamUsageTester.sizeOf}}, making the
> 2 calls identical. Instead, we would want one of the calls to go to
> {{RamUsageEstimator.sizeOf}}.
>
> This issue came up while working on LUCENE-10129. A possible solution, as per
> [~uschindler]'s suggestion, would be to remove the static import
> {code:java}
> import static org.apache.lucene.util.RamUsageTester.sizeOf;
> {code}
> Instead, we could be explicit on which method we are calling, like:
> {code:java}
> assertEquals(RamUsageEstimator.sizeOf(array), RamUsageTester.sizeOf(array));
> {code}
> This could be replicated for other potentially confusing cases in the test
> class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10182) TestRamUsageEstimator asserts trivial equality
[
https://issues.apache.org/jira/browse/LUCENE-10182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430216#comment-17430216
]
Stefan Vodita commented on LUCENE-10182:
Oh, I get it now. Thanks for the explanation! I guess the question on whether
it’s worth it is for Dawid then.
> TestRamUsageEstimator asserts trivial equality
> --
>
> Key: LUCENE-10182
> URL: https://issues.apache.org/jira/browse/LUCENE-10182
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Stefan Vodita
>Assignee: Uwe Schindler
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{TestRamUsageEstimator.testStaticOverloads}} has serveral lines like:
> {code:java}
> assertEquals(sizeOf(array), sizeOf((Object) array));
> {code}
> Both calls to {{sizeOf()}} fall back on {{RamUsageTester.sizeOf}}, making the
> 2 calls identical. Instead, we would want one of the calls to go to
> {{RamUsageEstimator.sizeOf}}.
>
> This issue came up while working on LUCENE-10129. A possible solution, as per
> [~uschindler]'s suggestion, would be to remove the static import
> {code:java}
> import static org.apache.lucene.util.RamUsageTester.sizeOf;
> {code}
> Instead, we could be explicit on which method we are calling, like:
> {code:java}
> assertEquals(RamUsageEstimator.sizeOf(array), RamUsageTester.sizeOf(array));
> {code}
> This could be replicated for other potentially confusing cases in the test
> class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] rmuir merged pull request #393: LUCENE-10185: pass --release 11 to ECJ linter, fix JDK 17 build
rmuir merged pull request #393: URL: https://github.com/apache/lucene/pull/393 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-10185) gradle check fails on java 17 (security manager deprecation)
[
https://issues.apache.org/jira/browse/LUCENE-10185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved LUCENE-10185.
--
Fix Version/s: main (9.0)
Resolution: Fixed
> gradle check fails on java 17 (security manager deprecation)
>
>
> Key: LUCENE-10185
> URL: https://issues.apache.org/jira/browse/LUCENE-10185
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Fix For: main (9.0)
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I don't think we should add SuppressWarnings here, instead fix our ECJ linter
> configuration. Seems like we should be specifying something similar to
> "-release 11" and it shouldn't care about the new deprecations from java 17.
> Or if we can't do that, maybe we should disable the "deprecated for removal"
> check in ECJ entirely?
> {noformat}
> > Task :lucene:core:ecjLintMain
> --
> 1. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 42)
> final SecurityManager s = System.getSecurityManager();
> ^^^
> The type SecurityManager has been deprecated since version 17 and marked for
> removal
> --
> 2. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 42)
> final SecurityManager s = System.getSecurityManager();
>
> The method getSecurityManager() from the type System has been deprecated
> since version 17 and marked for removal
> --
> 3. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 43)
> group = (s != null) ? s.getThreadGroup() :
> Thread.currentThread().getThreadGroup();
>
> The method getThreadGroup() from the type SecurityManager has been deprecated
> and marked for removal
> --
> --
> 4. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 23)
> import java.security.AccessControlException;
>
> The type AccessControlException has been deprecated since version 17 and
> marked for removal
> --
> 5. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 24)
> import java.security.AccessController;
>^^
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 6. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 574)
> AccessController.doPrivileged((PrivilegedAction)
> target::getDeclaredFields);
>
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 7. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 574)
> AccessController.doPrivileged((PrivilegedAction)
> target::getDeclaredFields);
>
> ^^^
> The method doPrivileged(PrivilegedAction) from the type
> AccessController has been deprecated and marked for removal
> --
> 8. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 575)
> } catch (AccessControlException e) {
> ^^
> The type AccessControlException has been deprecated since version 17 and
> marked for removal
> --
> --
> 9. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
> (at line 33)
> import java.security.AccessController;
>^^
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 10. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
> (at line 337)
> AccessController.doPrivileged((PrivilegedAction)
> MMapDirectory::unmapHackImpl);
>
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 11. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
> (at line 337)
> AccessController.doPrivileged((PrivilegedAction)
> MMapDirectory::unmapHackImpl);
>
[jira] [Commented] (LUCENE-10185) gradle check fails on java 17 (security manager deprecation)
[
https://issues.apache.org/jira/browse/LUCENE-10185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430219#comment-17430219
]
ASF subversion and git services commented on LUCENE-10185:
--
Commit f8d431ae4461a65ab109c0b8afffdfbcc5a12a5b in lucene's branch
refs/heads/main from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene.git;h=f8d431a ]
LUCENE-10185: pass --release 11 to ECJ linter, fix JDK 17 build (#393)
* LUCENE-10185: pass --release 11 to ECJ linter, fix JDK 17 build
Otherwise, new java releases such as JDK 18, JDK 19, ... may have even
more new deprecations, the build shouldn't fail in such cases.
Remove -source/-target now that we pass --release
Fix casting so ECJ understands it and creates correct call signature (UweSays:
"It's ok. I know why it happens, but it's a bug in ECJ. The type safety is
checked by the invokeexact")
Co-authored-by: Uwe Schindler
> gradle check fails on java 17 (security manager deprecation)
>
>
> Key: LUCENE-10185
> URL: https://issues.apache.org/jira/browse/LUCENE-10185
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Fix For: main (9.0)
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I don't think we should add SuppressWarnings here, instead fix our ECJ linter
> configuration. Seems like we should be specifying something similar to
> "-release 11" and it shouldn't care about the new deprecations from java 17.
> Or if we can't do that, maybe we should disable the "deprecated for removal"
> check in ECJ entirely?
> {noformat}
> > Task :lucene:core:ecjLintMain
> --
> 1. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 42)
> final SecurityManager s = System.getSecurityManager();
> ^^^
> The type SecurityManager has been deprecated since version 17 and marked for
> removal
> --
> 2. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 42)
> final SecurityManager s = System.getSecurityManager();
>
> The method getSecurityManager() from the type System has been deprecated
> since version 17 and marked for removal
> --
> 3. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 43)
> group = (s != null) ? s.getThreadGroup() :
> Thread.currentThread().getThreadGroup();
>
> The method getThreadGroup() from the type SecurityManager has been deprecated
> and marked for removal
> --
> --
> 4. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 23)
> import java.security.AccessControlException;
>
> The type AccessControlException has been deprecated since version 17 and
> marked for removal
> --
> 5. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 24)
> import java.security.AccessController;
>^^
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 6. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 574)
> AccessController.doPrivileged((PrivilegedAction)
> target::getDeclaredFields);
>
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 7. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 574)
> AccessController.doPrivileged((PrivilegedAction)
> target::getDeclaredFields);
>
> ^^^
> The method doPrivileged(PrivilegedAction) from the type
> AccessController has been deprecated and marked for removal
> --
> 8. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 575)
> } catch (AccessControlException e) {
> ^^
> The type AccessControlException has been deprecated since version 17 and
> marked for removal
> --
> --
> 9. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
> (at line 33)
> import java.security.AccessController;
>
[jira] [Commented] (LUCENE-10185) gradle check fails on java 17 (security manager deprecation)
[
https://issues.apache.org/jira/browse/LUCENE-10185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430221#comment-17430221
]
Robert Muir commented on LUCENE-10185:
--
{quote}
I can actually see this warning in intellij as well...
{quote}
[~dweiss] I will check eclipse too separately. Not sure if it will show the
bogus JDK17 deprecation warnings. We try to make the eclipse warnings
consistent with the errors that you'd get from {{./gradlew ecjLintXXX}}. It
makes for a less painful IDE experience. I will look into that later (we may
have to do something in .project or whatever), just wanted to get gradle
working first. It may also be possible to do similar stuff with intellij (I
dont know it, and i knew using ecj compiler was an option, but i didnt know if
it was the default, etc).
> gradle check fails on java 17 (security manager deprecation)
>
>
> Key: LUCENE-10185
> URL: https://issues.apache.org/jira/browse/LUCENE-10185
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Fix For: main (9.0)
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I don't think we should add SuppressWarnings here, instead fix our ECJ linter
> configuration. Seems like we should be specifying something similar to
> "-release 11" and it shouldn't care about the new deprecations from java 17.
> Or if we can't do that, maybe we should disable the "deprecated for removal"
> check in ECJ entirely?
> {noformat}
> > Task :lucene:core:ecjLintMain
> --
> 1. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 42)
> final SecurityManager s = System.getSecurityManager();
> ^^^
> The type SecurityManager has been deprecated since version 17 and marked for
> removal
> --
> 2. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 42)
> final SecurityManager s = System.getSecurityManager();
>
> The method getSecurityManager() from the type System has been deprecated
> since version 17 and marked for removal
> --
> 3. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 43)
> group = (s != null) ? s.getThreadGroup() :
> Thread.currentThread().getThreadGroup();
>
> The method getThreadGroup() from the type SecurityManager has been deprecated
> and marked for removal
> --
> --
> 4. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 23)
> import java.security.AccessControlException;
>
> The type AccessControlException has been deprecated since version 17 and
> marked for removal
> --
> 5. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 24)
> import java.security.AccessController;
>^^
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 6. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 574)
> AccessController.doPrivileged((PrivilegedAction)
> target::getDeclaredFields);
>
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 7. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 574)
> AccessController.doPrivileged((PrivilegedAction)
> target::getDeclaredFields);
>
> ^^^
> The method doPrivileged(PrivilegedAction) from the type
> AccessController has been deprecated and marked for removal
> --
> 8. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 575)
> } catch (AccessControlException e) {
> ^^
> The type AccessControlException has been deprecated since version 17 and
> marked for removal
> --
> --
> 9. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
> (at line 33)
> import java.security.AccessController;
>^^
> The type AccessController has been deprecated since version 17 and ma
[jira] [Commented] (LUCENE-10180) Remove usage of lambdas in SegmentMerger?
[ https://issues.apache.org/jira/browse/LUCENE-10180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430229#comment-17430229 ] Vigya Sharma commented on LUCENE-10180: --- I would like to work on this issue and get more involved with merge related functionality. Might need some help as I'm new here. [~jpountz] - Are you suggesting we replace these lambda invocations with separately named VoidMerger objects for each merge task like mergeTerms, mergeDocValues, ... ? > Remove usage of lambdas in SegmentMerger? > - > > Key: LUCENE-10180 > URL: https://issues.apache.org/jira/browse/LUCENE-10180 > Project: Lucene - Core > Issue Type: Wish >Reporter: Adrien Grand >Priority: Minor > Attachments: profile.png > > > SegmentMerger now uses lambdas to share the logic around logging merging > times for all file formats. > One problem is that these lambdas get auto-generated names, and it makes it > harder to work with profilers since things that should logically end up in > the same sub tree end up in different sub trees because two instances of the > same lambda get different names. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-10180) Remove usage of lambdas in SegmentMerger?
[ https://issues.apache.org/jira/browse/LUCENE-10180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430229#comment-17430229 ] Vigya Sharma edited comment on LUCENE-10180 at 10/18/21, 9:28 PM: -- I would like to work on this issue and get more involved with merge related functionality. Might need some help as I'm new here. Is the idea here to use a function pointer (similar to the one used for mergeTermVectors) for each of the merge tasks? was (Author: vigyas): I would like to work on this issue and get more involved with merge related functionality. Might need some help as I'm new here. [~jpountz] - Are you suggesting we replace these lambda invocations with separately named VoidMerger objects for each merge task like mergeTerms, mergeDocValues, ... ? > Remove usage of lambdas in SegmentMerger? > - > > Key: LUCENE-10180 > URL: https://issues.apache.org/jira/browse/LUCENE-10180 > Project: Lucene - Core > Issue Type: Wish >Reporter: Adrien Grand >Priority: Minor > Attachments: profile.png > > > SegmentMerger now uses lambdas to share the logic around logging merging > times for all file formats. > One problem is that these lambdas get auto-generated names, and it makes it > harder to work with profilers since things that should logically end up in > the same sub tree end up in different sub trees because two instances of the > same lambda get different names. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] vigyasharma commented on a change in pull request #2573: LUCENE-10008: Respect ignoreCase flag in CommonGramsFilterFactory
vigyasharma commented on a change in pull request #2573: URL: https://github.com/apache/lucene-solr/pull/2573#discussion_r731346908 ## File path: lucene/CHANGES.txt ## @@ -648,6 +648,8 @@ Optimizations Bug Fixes - +* LUCENE-10008: Respect ignoreCase in CommonGramsFilterFactory (Vigya Sharma) Review comment: Oops, my bad. Thanks for checking this Mike. Moved this line to 8.11 section. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] uschindler merged pull request #386: LUCENE-10182: Be specific about which sizeOf() is called
uschindler merged pull request #386: URL: https://github.com/apache/lucene/pull/386 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10182) TestRamUsageEstimator asserts trivial equality
[
https://issues.apache.org/jira/browse/LUCENE-10182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430241#comment-17430241
]
ASF subversion and git services commented on LUCENE-10182:
--
Commit d9e3d99ec91129e41f4afb35481fe33e0e4571bd in lucene's branch
refs/heads/main from Stefan Vodita
[ https://gitbox.apache.org/repos/asf?p=lucene.git;h=d9e3d99 ]
LUCENE-10182: Be specific about which sizeOf() is called; rename
RamUsageTester.sizeOf to ramUsed (#386)
Co-authored-by: Stefan Vodita
> TestRamUsageEstimator asserts trivial equality
> --
>
> Key: LUCENE-10182
> URL: https://issues.apache.org/jira/browse/LUCENE-10182
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Stefan Vodita
>Assignee: Uwe Schindler
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{TestRamUsageEstimator.testStaticOverloads}} has serveral lines like:
> {code:java}
> assertEquals(sizeOf(array), sizeOf((Object) array));
> {code}
> Both calls to {{sizeOf()}} fall back on {{RamUsageTester.sizeOf}}, making the
> 2 calls identical. Instead, we would want one of the calls to go to
> {{RamUsageEstimator.sizeOf}}.
>
> This issue came up while working on LUCENE-10129. A possible solution, as per
> [~uschindler]'s suggestion, would be to remove the static import
> {code:java}
> import static org.apache.lucene.util.RamUsageTester.sizeOf;
> {code}
> Instead, we could be explicit on which method we are calling, like:
> {code:java}
> assertEquals(RamUsageEstimator.sizeOf(array), RamUsageTester.sizeOf(array));
> {code}
> This could be replicated for other potentially confusing cases in the test
> class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10182) TestRamUsageEstimator asserts trivial equality
[
https://issues.apache.org/jira/browse/LUCENE-10182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430243#comment-17430243
]
Uwe Schindler commented on LUCENE-10182:
I merged the PR. Will check backports tomorrow, it's too late now.
> TestRamUsageEstimator asserts trivial equality
> --
>
> Key: LUCENE-10182
> URL: https://issues.apache.org/jira/browse/LUCENE-10182
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Stefan Vodita
>Assignee: Uwe Schindler
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{TestRamUsageEstimator.testStaticOverloads}} has serveral lines like:
> {code:java}
> assertEquals(sizeOf(array), sizeOf((Object) array));
> {code}
> Both calls to {{sizeOf()}} fall back on {{RamUsageTester.sizeOf}}, making the
> 2 calls identical. Instead, we would want one of the calls to go to
> {{RamUsageEstimator.sizeOf}}.
>
> This issue came up while working on LUCENE-10129. A possible solution, as per
> [~uschindler]'s suggestion, would be to remove the static import
> {code:java}
> import static org.apache.lucene.util.RamUsageTester.sizeOf;
> {code}
> Instead, we could be explicit on which method we are calling, like:
> {code:java}
> assertEquals(RamUsageEstimator.sizeOf(array), RamUsageTester.sizeOf(array));
> {code}
> This could be replicated for other potentially confusing cases in the test
> class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-10182) TestRamUsageEstimator asserts trivial equality
[
https://issues.apache.org/jira/browse/LUCENE-10182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-10182:
---
Fix Version/s: main (9.0)
> TestRamUsageEstimator asserts trivial equality
> --
>
> Key: LUCENE-10182
> URL: https://issues.apache.org/jira/browse/LUCENE-10182
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Stefan Vodita
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: main (9.0)
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{TestRamUsageEstimator.testStaticOverloads}} has serveral lines like:
> {code:java}
> assertEquals(sizeOf(array), sizeOf((Object) array));
> {code}
> Both calls to {{sizeOf()}} fall back on {{RamUsageTester.sizeOf}}, making the
> 2 calls identical. Instead, we would want one of the calls to go to
> {{RamUsageEstimator.sizeOf}}.
>
> This issue came up while working on LUCENE-10129. A possible solution, as per
> [~uschindler]'s suggestion, would be to remove the static import
> {code:java}
> import static org.apache.lucene.util.RamUsageTester.sizeOf;
> {code}
> Instead, we could be explicit on which method we are calling, like:
> {code:java}
> assertEquals(RamUsageEstimator.sizeOf(array), RamUsageTester.sizeOf(array));
> {code}
> This could be replicated for other potentially confusing cases in the test
> class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] janhoy commented on pull request #391: LUCENE-9997 Second pass smoketester fixes for 9.0
janhoy commented on pull request #391: URL: https://github.com/apache/lucene/pull/391#issuecomment-946219082 > I merged with main where the artifact-signing changes landed. The buildAndPushRelease.py works for me (although it does create that stray file so I suspect it won't run properly unless in dev mode). Thanks. I get the `gpg: signing failed: Cannot allocate memory` error with gpg, caused by gpg daemon running out of mem during many parallell signing commands. I found a workaround by adding `auto-expand-secmem` to `~/.gnupg/gpg-agent.conf` and then running `gpg-connect-agent killagent /bye` to restart the agent, and it works. This could perhaps be documented as a prerequisite for using gpg, if you don't want to run serially. Or the script could run the main build in parallel and then run just the signing serially. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] rmuir commented on pull request #389: LUCENE-10159: Fix invalid access in sorted set dv
rmuir commented on pull request #389: URL: https://github.com/apache/lucene/pull/389#issuecomment-946248949 > Sorted set doc values don't have a docValueCount API, they're just expected to return NO_MORE_ORDS when all ords have been exhausted. Thanks, sorry I had completely forgotten that, and that's the inconsistency that is root cause of the trouble here (padding/alignment that hid the bug didn't help). SortedSet was added first, and not having a count method may not have been the best decision. I am not sure it is even slightly helpful to save space if you want to implement as a vint-list, because you still need to store "some kind of length" to have per-document random access. With the SortedNumeric, there is no available sentinel value that can be used (without boxing or something nasty), so we had to do a count method. Maybe it is worth a second thought, if the SortedSet could get a count method to be more consistent and efficient like the numeric one. It would have costs (e.g. we'd need to hard-break the api in a way that it isnt trappy on users), but it would also have benefits: e.g. none of this state-keeping inside the codec, instead based on a more natural loop that happens outside of the codec code. Then AssertingCodec would really detect issues, maybe the compiler can do a better job with it, etc. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10180) Remove usage of lambdas in SegmentMerger?
[ https://issues.apache.org/jira/browse/LUCENE-10180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430276#comment-17430276 ] Michael Sokolov commented on LUCENE-10180: -- It looks as if [~jpountz] posted a PR: [https://github.com/apache/lucene/pull/385.|https://github.com/apache/lucene/pull/385] I'm not sure why it didn't get linked here automatically > Remove usage of lambdas in SegmentMerger? > - > > Key: LUCENE-10180 > URL: https://issues.apache.org/jira/browse/LUCENE-10180 > Project: Lucene - Core > Issue Type: Wish >Reporter: Adrien Grand >Priority: Minor > Attachments: profile.png > > > SegmentMerger now uses lambdas to share the logic around logging merging > times for all file formats. > One problem is that these lambdas get auto-generated names, and it makes it > harder to work with profilers since things that should logically end up in > the same sub tree end up in different sub trees because two instances of the > same lambda get different names. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] mocobeta opened a new pull request #394: LUCENE-9997: write release revision to system temp dir
mocobeta opened a new pull request #394: URL: https://github.com/apache/lucene/pull/394 Suggested at: - https://github.com/apache/lucene/pull/382#discussion_r729615274 - https://issues.apache.org/jira/browse/LUCENE-9997?focusedCommentId=17430157&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17430157 `/tmp` should work on any standard linux filesystems. I think the fixed path is okay. https://superuser.com/questions/332610/where-is-the-temporary-directory-in-linux/332616 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9997) Revisit smoketester for 9.0 build
[
https://issues.apache.org/jira/browse/LUCENE-9997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430278#comment-17430278
]
Tomoko Uchida commented on LUCENE-9997:
---
bq. The smoke tester writes a repository-local file "rev.txt" and pollutes
pristine local state.
I opened a PR: https://github.com/apache/lucene/pull/394
> Revisit smoketester for 9.0 build
> -
>
> Key: LUCENE-9997
> URL: https://issues.apache.org/jira/browse/LUCENE-9997
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Robert Muir
>Priority: Major
> Attachments: image-2021-10-12-12-47-11-480.png,
> image-2021-10-12-12-48-15-373.png
>
> Time Spent: 6.5h
> Remaining Estimate: 0h
>
> Currently we have a (great) {{dev-tools/scripts/smokeTester.py}} that will
> perform automated tests against a release.
> This was developed with the ant build process in mind.
> This issue is just about considering the automated checks we do here, maybe
> some of them can be done efficiently in the gradle build in earlier places:
> this would be a large improvement!
> Obviously some of them (e.g. GPG release key verifications) are really
> specific to the artifacts in question. These are most important to release
> verification, as that is actually the only place we can check it.
> Any other checks (and I do tend to think, this checker should try to be
> thorough, invoking gradle etc), should be stuff we regularly test in
> PRs/nightly/builds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] mocobeta commented on pull request #391: LUCENE-9997 Second pass smoketester fixes for 9.0
mocobeta commented on pull request #391:
URL: https://github.com/apache/lucene/pull/391#issuecomment-946304048
With skipping sthe ign verification (`--not-signed`), smoketester stopped
here for me.
```
unpack lucene-9.0.0.tgz...
verify that Maven artifacts are same as in the binary distribution...
verify JAR metadata/identity/no javax.* or java.* classes...
Traceback (most recent call last):
File "/mnt/hdd/repo/lucene/dev-tools/scripts/smokeTestRelease.py", line
134, in checkJARMetaData
if z.getinfo(name) is None:
File "/usr/lib64/python3.9/zipfile.py", line 1429, in getinfo
raise KeyError(
KeyError: "There is no item named 'META-INF/NOTICE.txt' in the archive"
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/mnt/hdd/repo/lucene/dev-tools/scripts/smokeTestRelease.py", line
1180, in
main()
File "/mnt/hdd/repo/lucene/dev-tools/scripts/smokeTestRelease.py", line
1119, in main
smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed,
c.local_keys, ' '.join(c.test_args),
File "/mnt/hdd/repo/lucene/dev-tools/scripts/smokeTestRelease.py", line
1171, in smokeTest
checkMaven(baseURL, tmpDir, gitRevision, version, isSigned, keysFile)
File "/mnt/hdd/repo/lucene/dev-tools/scripts/smokeTestRelease.py", line
710, in checkMaven
checkAllJARs('%s/maven/org/apache/lucene' % tmpDir, gitRevision, version)
File "/mnt/hdd/repo/lucene/dev-tools/scripts/smokeTestRelease.py", line
206, in checkAllJARs
checkJARMetaData('JAR file "%s"' % fullPath, fullPath, gitRevision,
version)
File "/mnt/hdd/repo/lucene/dev-tools/scripts/smokeTestRelease.py", line
137, in checkJARMetaData
raise RuntimeError('%s is missing %s' % (desc, name))
RuntimeError: JAR file
"/tmp/smoke_lucene_9.0.0_6f67e8287f19c4b3fedfaacc0312f987fcd2d5b7/maven/org/apache/lucene/lucene-test-framework/9.0.0/lucene-test-framework-9.0.0-sources.jar"
is missing META-INF/NOTICE.txt
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] mocobeta edited a comment on pull request #391: LUCENE-9997 Second pass smoketester fixes for 9.0
mocobeta edited a comment on pull request #391:
URL: https://github.com/apache/lucene/pull/391#issuecomment-946304048
With skipping the sign verification (`--not-signed`), smoketester stopped
here for me.
```
unpack lucene-9.0.0.tgz...
verify that Maven artifacts are same as in the binary distribution...
verify JAR metadata/identity/no javax.* or java.* classes...
Traceback (most recent call last):
File "/mnt/hdd/repo/lucene/dev-tools/scripts/smokeTestRelease.py", line
134, in checkJARMetaData
if z.getinfo(name) is None:
File "/usr/lib64/python3.9/zipfile.py", line 1429, in getinfo
raise KeyError(
KeyError: "There is no item named 'META-INF/NOTICE.txt' in the archive"
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/mnt/hdd/repo/lucene/dev-tools/scripts/smokeTestRelease.py", line
1180, in
main()
File "/mnt/hdd/repo/lucene/dev-tools/scripts/smokeTestRelease.py", line
1119, in main
smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed,
c.local_keys, ' '.join(c.test_args),
File "/mnt/hdd/repo/lucene/dev-tools/scripts/smokeTestRelease.py", line
1171, in smokeTest
checkMaven(baseURL, tmpDir, gitRevision, version, isSigned, keysFile)
File "/mnt/hdd/repo/lucene/dev-tools/scripts/smokeTestRelease.py", line
710, in checkMaven
checkAllJARs('%s/maven/org/apache/lucene' % tmpDir, gitRevision, version)
File "/mnt/hdd/repo/lucene/dev-tools/scripts/smokeTestRelease.py", line
206, in checkAllJARs
checkJARMetaData('JAR file "%s"' % fullPath, fullPath, gitRevision,
version)
File "/mnt/hdd/repo/lucene/dev-tools/scripts/smokeTestRelease.py", line
137, in checkJARMetaData
raise RuntimeError('%s is missing %s' % (desc, name))
RuntimeError: JAR file
"/tmp/smoke_lucene_9.0.0_6f67e8287f19c4b3fedfaacc0312f987fcd2d5b7/maven/org/apache/lucene/lucene-test-framework/9.0.0/lucene-test-framework-9.0.0-sources.jar"
is missing META-INF/NOTICE.txt
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10185) gradle check fails on java 17 (security manager deprecation)
[
https://issues.apache.org/jira/browse/LUCENE-10185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430349#comment-17430349
]
Dawid Weiss commented on LUCENE-10185:
--
It's fine, really. This is what struck me as odd:
{code}
import java.lang.invoke.*;
public class Foo {
public static A foo(MethodHandle mh, Object in) throws Throwable {
return (A) mh.invokeExact(in);
}
public static A foo(Object in) throws Throwable {
return (A) in;
}
}
{code}
With javac, only the second method generates a warning. Must be some secret
exception rule in the compiler for method handles.
{code}
>javac Foo.java --release 11 -Xlint:unchecked
Foo.java:9: warning: [unchecked] unchecked cast
return (A) in;
^
required: A
found:Object
where A is a type-variable:
A extends Object declared in method foo(Object)
1 warning
{code}
> gradle check fails on java 17 (security manager deprecation)
>
>
> Key: LUCENE-10185
> URL: https://issues.apache.org/jira/browse/LUCENE-10185
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Fix For: main (9.0)
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I don't think we should add SuppressWarnings here, instead fix our ECJ linter
> configuration. Seems like we should be specifying something similar to
> "-release 11" and it shouldn't care about the new deprecations from java 17.
> Or if we can't do that, maybe we should disable the "deprecated for removal"
> check in ECJ entirely?
> {noformat}
> > Task :lucene:core:ecjLintMain
> --
> 1. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 42)
> final SecurityManager s = System.getSecurityManager();
> ^^^
> The type SecurityManager has been deprecated since version 17 and marked for
> removal
> --
> 2. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 42)
> final SecurityManager s = System.getSecurityManager();
>
> The method getSecurityManager() from the type System has been deprecated
> since version 17 and marked for removal
> --
> 3. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/NamedThreadFactory.java
> (at line 43)
> group = (s != null) ? s.getThreadGroup() :
> Thread.currentThread().getThreadGroup();
>
> The method getThreadGroup() from the type SecurityManager has been deprecated
> and marked for removal
> --
> --
> 4. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 23)
> import java.security.AccessControlException;
>
> The type AccessControlException has been deprecated since version 17 and
> marked for removal
> --
> 5. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 24)
> import java.security.AccessController;
>^^
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 6. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 574)
> AccessController.doPrivileged((PrivilegedAction)
> target::getDeclaredFields);
>
> The type AccessController has been deprecated since version 17 and marked for
> removal
> --
> 7. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 574)
> AccessController.doPrivileged((PrivilegedAction)
> target::getDeclaredFields);
>
> ^^^
> The method doPrivileged(PrivilegedAction) from the type
> AccessController has been deprecated and marked for removal
> --
> 8. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/util/RamUsageEstimator.java
> (at line 575)
> } catch (AccessControlException e) {
> ^^
> The type AccessControlException has been deprecated since version 17 and
> marked for removal
> --
> --
> 9. ERROR in
> /home/rmuir/workspace/lucene/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
> (at line 33)
> import java.security.AccessController;
>^^
>
