Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r208652
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
-args += [ "-source", project.java.sourceCompatibility ]
-args += [ "-target", project.java.targetCompatibility ]
+args += ["-$project.java.sourceCompatibility"] // "compliance" level
Review Comment:
Actually the two lines above do the same. The change can be applied or not,
the result is identical. At end it sets compliance level.
I agree with Dawid, we can keep source/target as it is easier to understand
for javac people, but the whole discussion here is really nonsense. We never
wanted to make it slow and we have heard you now multiple times complaining. I
just repeat: "YES I HEARD YOU!" I have said multiple times, the code above
won't make it slow. We also tested it with Java 25 and a backported version. So
please stop arguing. Thanks!
--
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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2086555819
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
-args += [ "-source", project.java.sourceCompatibility ]
-args += [ "-target", project.java.targetCompatibility ]
+args += ["-$project.java.sourceCompatibility"] // "compliance" level
Review Comment:
We already agreed to keep the command line options as is. I just want you to
calm down and argue about something we agreed several times.
Sometimes you can do a cleanup or not, what @dsmiley dis was just to replace
a command line flag to make the command line shorter.
Actually puting target and source on the command line will set compliance
level, too. So it won't need to be included in the config file. It was always
obsolete and was only included for the Eclipse config. So see this two lines
just as a cleanup. We can argue several months about it, but I would no longer
listen to you. Sorry. Complete nonsense!
Therefore I added a commit yesterday to set the compliance level and
source/target level in the eclipse configuration. The ECJ linter uses the
property from command line, which is cheaper to do than patching a file (I
don't want to create random temp files for nonsense as sthis slows down on
Windows!).
--
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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2086555819
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
-args += [ "-source", project.java.sourceCompatibility ]
-args += [ "-target", project.java.targetCompatibility ]
+args += ["-$project.java.sourceCompatibility"] // "compliance" level
Review Comment:
We already agreed to keep the command line options as is. I just want you to
calm down and argue about something we agreed several times.
Sometimes you can do a cleanup or not, what @dsmiley did was just to replace
a command line flag to make the command line shorter. I also cleanup code when
I see something to change although it is unrelated. So while rewriting the
apijar extraction I added several new checks and fetaures and changed the code.
SHould I revert that, too, because it was not related to the original PR title?
Actually puting target and source on the command line will set compliance
level, too. So it won't need to be included in the config file. It was always
obsolete and was only included for the Eclipse config. So see this two lines
just as a cleanup. We can argue several months about it, but I would no longer
listen to you. Sorry. Complete nonsense!
Therefore I added a commit yesterday to set the compliance level and
source/target level in the eclipse configuration. The ECJ linter uses the
property from command line, which is cheaper to do than patching a file (I
don't want to create random temp files for nonsense as sthis slows down on
Windows!).
--
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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
rmuir commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2086560622
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
-args += [ "-source", project.java.sourceCompatibility ]
-args += [ "-target", project.java.targetCompatibility ]
+args += ["-$project.java.sourceCompatibility"] // "compliance" level
Review Comment:
i dont think we need to do any CLI flags change: That's exactly what I'm
requesting to revert here. And thats why the PR has 40+ comments.
If we were doing this with `make` we'd just `envsubst` and the hardcoded
value would be replaced by variable: problem solved.
I don't understand why it should be any more difficult than that with gradle.
--
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
Re: [PR] Mention label in changelog verifier comment [lucene]
stefanvodita merged PR #14656: URL: https://github.com/apache/lucene/pull/14656 -- 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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2086528285
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
-args += [ "-source", project.java.sourceCompatibility ]
-args += [ "-target", project.java.targetCompatibility ]
+args += ["-$project.java.sourceCompatibility"] // "compliance" level
Review Comment:
Compliance level is translated to source and target. If you pass source and
or traget it is vice versa converted to compliance level. Unless you set
release, the releaseVersion property is NOT set and the code does not slow
down. Please see my comment.
--
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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2086526348
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
-args += [ "-source", project.java.sourceCompatibility ]
-args += [ "-target", project.java.targetCompatibility ]
+args += ["-$project.java.sourceCompatibility"] // "compliance" level
Review Comment:
This line does not slow down, so it does not matter here. Unless you use
"release" flag. Please read Dawid and my analysis above.
--
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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r208652
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
-args += [ "-source", project.java.sourceCompatibility ]
-args += [ "-target", project.java.targetCompatibility ]
+args += ["-$project.java.sourceCompatibility"] // "compliance" level
Review Comment:
Actually the two lines above do the same. The change can be applied or not,
the result is identical. At end it sets compliance level.
I agree with Dawid, we can keep source/target as it is easier to understand
for javac people, but the whole discussion here is really nonsense. We never
wanted to make it slow and we have heard you now multiple times complaining. I
just repeat: "YES I HEARD YOU!" I have said multiple times, the code above
won't make it slow. We also tested it with Java 25 and a backported version".
So please stop arguing. Thanks!
--
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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r208652
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
-args += [ "-source", project.java.sourceCompatibility ]
-args += [ "-target", project.java.targetCompatibility ]
+args += ["-$project.java.sourceCompatibility"] // "compliance" level
Review Comment:
Actually the two lines above do the same. The change can be applied or not,
the result is identical. At end it sets compliance level.
I agree with Dawid, we can keep source/target as it is easier to understand
for javac people, but the whole discussion here is really nonsense. We never
wanted to make it slow and we havce heard you all the time complaining often
enough: "YES I HEARD YOU! I have said multiple times, the code above won't make
it slow. We also tested it with Java 25 and a backported version". So please
stop arguing. Thanks!
--
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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
rmuir commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2086541603
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
-args += [ "-source", project.java.sourceCompatibility ]
-args += [ "-target", project.java.targetCompatibility ]
+args += ["-$project.java.sourceCompatibility"] // "compliance" level
Review Comment:
It isn't nonsense: the title of the PR is to "remove hard-coded versions"
not "Change ECJ CLI flags".
If gradle can't "template" a file and replace some simple variables without
ALSO changing CLI flags, perhaps we should look at a different build tool
--
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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2086578233
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
-args += [ "-source", project.java.sourceCompatibility ]
-args += [ "-target", project.java.targetCompatibility ]
+args += ["-$project.java.sourceCompatibility"] // "compliance" level
Review Comment:
Man man. The change here is only cleanup. There is no need to change any
files. The removal of the propertie sin the file are not needed here. It was
already fixed by my commit.
The change here is. ONLY COSMETIC. It does not change anything in
functionality. So we can leave it out. Please stop arguing. This is annoying to
me. Sorry.
--
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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2086578233
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
-args += [ "-source", project.java.sourceCompatibility ]
-args += [ "-target", project.java.targetCompatibility ]
+args += ["-$project.java.sourceCompatibility"] // "compliance" level
Review Comment:
Man man. The change here is only cleanup. There is no need to change any
files. The removal of the properties in the properties file passed to compiler
are unrelated to that change we're talking about here. It was already fixed by
my commit.
The change here is. ONLY COSMETIC. It does not change anything in
functionality. So we can leave it out. Please stop arguing. This is annoying to
me. Sorry.
--
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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2876103288 I am complete pissed off, bye! Do whatever you want. Damn! -- 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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
github-actions[bot] commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2876119114 This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. -- 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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2086589925
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
-args += [ "-source", project.java.sourceCompatibility ]
-args += [ "-target", project.java.targetCompatibility ]
+args += ["-$project.java.sourceCompatibility"] // "compliance" level
Review Comment:
reverted. Man man.
--
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
Re: [PR] Use a hint to specify READONCE IOContext [lucene]
thecoop commented on PR #14509: URL: https://github.com/apache/lucene/pull/14509#issuecomment-2876771344 @ChrisHegarty @jpountz Does this look ok? -- 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
Re: [PR] Catch and re-throw Throwable rather than using a success boolean [lucene]
ChrisHegarty merged PR #14633: URL: https://github.com/apache/lucene/pull/14633 -- 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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dsmiley commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2876638709 Thanks Dawid for the deep dive and Uwe for helping with the Eclipse support! For this minor build improvement, I wasn't going to update CHANGES.txt but let me know if you think I should add it. I plan to back-port to 10x and also take it to Solr. I'll merge later tonight (like in ~8hrs). -- 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
Re: [PR] Early terminate visit BKD leaf when current value greater than upper point in sorted dim. [lucene]
vsop-479 commented on PR #12528: URL: https://github.com/apache/lucene/pull/12528#issuecomment-2876395494 Performance with "inverse" visitor implemented: box-points| baseline | candidate | Diff -- | -- | -- | -- BEST M hits/sec | 500.14 | 513.51 | 2.6% BEST QPS | 508.92 | 522.53 | 2.6% -- 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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dweiss commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2875450439 > The most important question here: Did you find out if "compliance" flag uses release or not? Looking at the code, it seems to be equivalent to setting the release flag. https://github.com/eclipse-jdt/eclipse.jdt.core/blob/master/org.eclipse.jdt.core.compiler.batch/src/org/eclipse/jdt/internal/compiler/batch/Main.java#L1985-L1997 https://github.com/eclipse-jdt/eclipse.jdt.core/blob/master/org.eclipse.jdt.core.compiler.batch/src/org/eclipse/jdt/internal/compiler/batch/Main.java#L2579-L2599 -- 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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dweiss commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2875439928 Also - the final cherry on top of this cake - why we can't see such significant difference on main is very likely on this change: https://bugs.openjdk.org/browse/JDK-8283336 If you go back to commit 8d0103724 and use the newest available ecj batch compiler with jdk17, the difference is still there (and large). If you run ecj with jdk 21 there (same invocation line but you need to do it manually because gradle bails out), the difference is much less pronounced. Fun. -- 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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2875439078 P.S.: It could be that the newest version of the ct.sym generator uses the Classfile API in a similar way like I refactored it last week. Have not checked source code, the last time I looked at it, it was NOT using ASM, but the compiler classfile parser. Nowadays all is merged together, so chances are high that it uses Classfile API nowadays. -- 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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2875430075 > the compiler and also introduced an - undocumented? - 'ct.sym' file, which is part of the JDK and is a zip file with class signatures from previous Java version. Couldn't find the docs on this file anywhere and ecj's source is a fun reading too: This is well documented in the source code of the JDK; I don't remember if there's also a JEP. The ct.sym file is generated by the JDK build and later committed when they start a new release. Actually the way how it is generated was my inspiration for the stub-only APIJAR files we have for compilation of MR-JARs. Basically it is more or less exactly the same: The ct.sym file is just a ZIP file with empty stubs and (in addition to Lucene's approach) with some additional logic to only record the differences between API versions. Because of this it is accessing the filesystem provider many times, because it has to load a symbol from many files until it has gotten all symbols by adding up all incremental changes. This is the reason for the file exists. It looks up for every previous Java relaese if a sym file exists. And as we are at 24 already it goes down to 7 or 8. This does not scale, so they should improve the lookup structure by having a pointer to previous release of a specific file in each class stub. The most important question here: Did you find out if "compliance" flag uses release or not? -- 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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dweiss commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2875453187 There is a lot of complexity involved in checking this release compatibility. I'd leave it out to javac and just use source/target here. No need to double-check the same stuff twice and slow down the build. -- 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
Re: [PR] Mention label in changelog verifier comment [lucene]
github-actions[bot] commented on PR #14656: URL: https://github.com/apache/lucene/pull/14656#issuecomment-2875933483 This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. -- 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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2875948758 > There is a lot of complexity involved in checking this release compatibility. I'd leave it out to javac and just use source/target here. No need to double-check the same stuff twice and slow down the build. This is not true, I checked the code. When you specify `-release` on command line (and only then), it sets relaese version: https://github.com/eclipse-jdt/eclipse.jdt.core/blob/85f1797ab9f379eeffd203d94522fbf3c6a4e7ce/org.eclipse.jdt.core.compiler.batch/src/org/eclipse/jdt/internal/compiler/batch/Main.java#L2588 If you just set compliance level it does not do this, Later in the code it compares the current compliance level and release version via `(this.releaseVersion != null && this.complianceLevel < jdkLevel)` -- At this place it sets up the "Horrible slowness": https://github.com/eclipse-jdt/eclipse.jdt.core/blob/85f1797ab9f379eeffd203d94522fbf3c6a4e7ce/org.eclipse.jdt.core.compiler.batch/src/org/eclipse/jdt/internal/compiler/batch/Main.java#L5191-L5198 So basically, the code in this PR is fine as it does not set the release version unless you use "release". If you just give compliance level it is identical to setting source/target. -- 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
Re: [I] Create a bot to check if there is a CHANGES entry for new PRs [lucene]
dweiss commented on issue #13898: URL: https://github.com/apache/lucene/issues/13898#issuecomment-2875734587 One would be probably enough. I'm also not sure we should require all changes in changes.txt. The one in 14653 doesn't seem to be that important (it applies to build infrastructure, nobody looking at changes.txt will ever care about 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
Re: [I] Create a bot to check if there is a CHANGES entry for new PRs [lucene]
stefanvodita commented on issue #13898: URL: https://github.com/apache/lucene/issues/13898#issuecomment-2875906960 I thought about it some more. The way we envisioned PR authors choosing not to run the verifier is by adding the [`skip-changelog-check` label](https://github.com/apache/lucene/labels/skip-changelog-check). I should have mentioned this in the email I sent to the dev list. Here is what I'd like to do next if it seems good to you as well. 1. Update the bot's comment to tell people they can use the label to skip the check on their PR. If they don't add the label, the bot will continue reminding us as the PR gets updated. If they do add the label, the bot will stop. 2. Eventually make the bot smarter like you are suggesting, so that it doesn't run on PRs that we know don't need a CHANGES entry. Maybe we would do this by unifying with the [module lebeler](https://github.com/apache/lucene/blob/main/.github/labeler.yml), which already looks at which files were touched. -- 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
Re: [I] asynchronous I/O + saturating NVMe bandwidth [lucene]
rmuir commented on issue #14655: URL: https://github.com/apache/lucene/issues/14655#issuecomment-2875770908 > So, I suggest a radical shift in the underlying posting format. Give up log-structured format (LSM)! Give up segments. LSM aims for sequential I/O, which is no longer relevant for NVMe SSDs. Have one monolithic index. Each term initially gets a page for its posting and related data. If the term is popular, progressively assign it chunks of multiple pages. Pages/chunks are chained using forward pointers. These pointers will be stored in an on-heap (or in-memory) data structure similar to skip offsets. (Embrace random SSD I/Os.) A single request can be broken down into many random pages on an SSD, and all these pages are part of the batch for io_submit(). On the write path, similarly, gather all updates in a submit buffer and issue hundreds of random I/Os. > Terms are no longer sorted You're free to write your own separate search engine, but this doesn't sound like lucene to me. -- 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
Re: [I] asynchronous I/O + saturating NVMe bandwidth [lucene]
shbakram commented on issue #14655: URL: https://github.com/apache/lucene/issues/14655#issuecomment-2875790379 Lucene can support various I/O engines: mmap, io_uring, pmem, etc. This way as storage technology improves, one can reuse all the latest developments in Lucene (e.g., high-dimensionality vectors, faceting, etc) evolved over decades while best exploiting new storage technology. The question is how much (and what) effort is required for this decoupling to succeed? -- 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
Re: [PR] build: configure 3 retries for all gradle Download tasks [lucene]
rmuir commented on code in PR #14653:
URL: https://github.com/apache/lucene/pull/14653#discussion_r2086404395
##
gradle/hacks/downloader-retries.gradle:
##
@@ -0,0 +1,27 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+allprojects {project ->
+// Limit configuration to just those projects that actually have the
plugin enabled.
+plugins.matching { Plugin plugin ->
+return plugin.class.name ==
"de.undercouch.gradle.tasks.download.DownloadTaskPlugin"
+}.configureEach {
+project.tasks.withType(Download).configureEach {
+it.retries 3
+}
+}
+}
Review Comment:
Thank you @dweiss. Much cleaner. Hopefully it stops the annoying build
failures!
--
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
Re: [I] Promote sandbox facets to the main facets module [lucene]
epotyom commented on issue #14619: URL: https://github.com/apache/lucene/issues/14619#issuecomment-2875780860 In my opinion, the new approach can eventually do everything the current approach does, but there are quite a few gaps to cover, see Milestone 2 in [the plan document](https://docs.google.com/document/d/1PF9KWYboy6terrPp8Frizlkp1ee09RX-DsuZrBux-Oo/edit?usp=sharing). Whether or not we want to deprecate the old functionality after that is a good question. The only benefit of pre-collecting to docId sets I know is that in theory user can do something like find top 1 book author (with taxonomy facets) and then count docs for price ranges for matching books of this author by reusing the docID set + [fastMatchQuery](https://github.com/apache/lucene/blob/0ea423e3025893fa1ce9a2633c59a7578b8478ea/lucene/facet/src/java/org/apache/lucene/facet/FacetCountsWithFilterQuery.java#L41-L45) . I don't know if anyone actually does something like that. Also, we can implement similar functionality for the new approach by making it compatible with pre-collected docID sets, I've just added the task to th e Milestone 2. The other potential concern is performance. While in general the new approach seems to be more efficient as it doesn't require intermediate docID sets, there are some cases where the old approach is faster, e.g. for taxonomy when user counts for MatchAllDocs query for a facet index field that is responsible for creating majority of taxonomy facet labels, see [luceneutil #325](https://github.com/mikemccand/luceneutil/pull/325#issuecomment-2580729914) for details. Although, I think we can find a way to optimize CountFacetRecorder for dense counting. Another example, the implementation for [long values facet counts](https://github.com/apache/lucene/blob/0ea423e3025893fa1ce9a2633c59a7578b8478ea/lucene/sandbox/src/java/org/apache/lucene/sandbox/facet/cutters/LongValueFacetCutter.java) for the new approach is also very inefficient, although Milestone 0 has an idea to try that can make it faster. Just to summarize, what I guess I'm saying is that eventually the new approach can replace the old one, but it will take time. -- 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
Re: [I] Create a bot to check if there is a CHANGES entry for new PRs [lucene]
stefanvodita commented on issue #13898: URL: https://github.com/apache/lucene/issues/13898#issuecomment-2875620327 The bot has processed one PR (#14653) and I already see something I'm not sure I like - it will post a comment every time we push to the branch and are missing a CHANGES entry. I can see arguments on both sides, but I think I would prefer a single comment per PR. We could probably do that by adding a label to the PR after the first comment. -- 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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2875507747 Thanks, so I'd like to revert those changes here with a clear warning next to 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
Re: [PR] build: configure 3 retries for all gradle Download tasks [lucene]
github-actions[bot] commented on PR #14653: URL: https://github.com/apache/lucene/pull/14653#issuecomment-2875511439 This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. -- 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
Re: [PR] build: configure 3 retries for all gradle Download tasks [lucene]
github-actions[bot] commented on PR #14653: URL: https://github.com/apache/lucene/pull/14653#issuecomment-2875512652 This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. -- 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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dweiss commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2875517286 Yep, I'd stick to using what was there before. Not a bad idea to replace java properties if you've already done it though. -- 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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dweiss commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2875398128 I dug deep into this, fascinating. So the problem is indeed in the release check flag. Here is a flame graph from a slowed-down execution of ecj:  you'll notice a lot of time spent in ```Files.exists``` there, which in turn is called from ```ClasspathJep247Jdk12```. JEP 247 (https://openjdk.org/jeps/247) introduced the ``--release`` option for the compiler and also introduced an - undocumented? - 'ct.sym' file, which is part of the JDK and is a zip file with class signatures from previous Java version. Couldn't find the docs on this file anywhere and ecj's source is a fun reading too: ``` * Abstraction to the ct.sym file access (see https://openjdk.java.net/jeps/247). The ct.sym file is required to * implement JEP 247 feature (compile with "--release" option against class stubs for older releases) and is currently * (Java 15) a jar file with undocumented internal structure, currently existing in at least two different format * versions (pre Java 12 and Java 12 and later). * * The only documentation known seem to be the current implementation of * com.sun.tools.javac.platform.JDKPlatformProvider and probably some JDK build tools that construct ct.sym file. Root * directories inside the file are somehow related to the Java release number, encoded as single digit or letter (single * digits for releases 7 to 9, capital letters for 10 and higher). * * If a release directory contains "system-modules" file, it is a flag that this release files are not inside ct.sym * file because it is the current release, and jrt file system should be used instead. * * All other release directories contain encoded signature (*.sig) files with class stubs for classes in the release. * * Some directories contain files that are shared between different releases, exact logic how they are distributed is * not known. * * ... ``` Anyway. The cause of the slowdown in ecj is caused by many repetitive calls to zip Filesystem provider, which doesn't seem to be too efficient. There does seem to be some caches around it in CtSym.java but evidently it depends not only on ecj version but also on the content of ct.sym file - how many patch releases there were for the target version (all patch sub-directories need to be checked). It's quite insane. I would leave release checking out of ecj. -- 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
Re: [I] Create a bot to check if there is a CHANGES entry for new PRs [lucene]
stefanvodita closed issue #13898: Create a bot to check if there is a CHANGES entry for new PRs URL: https://github.com/apache/lucene/issues/13898 -- 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
Re: [PR] Enable changelog verifier [lucene]
stefanvodita merged PR #14644: URL: https://github.com/apache/lucene/pull/14644 -- 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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2875957427 But at end I don't care if we set source+target or just compliance. It is effectively doing the same at end. We should just make sure to not set "release". Just to confirm that my observations are correct: Did you measure slowness with this PR if executed in Java 25? If yes, I am wrong with my analysis. -- 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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dweiss commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2875971667 Ok, I think the second snippet of yours is spot-on - yes. Still, I'd prefer using javac options. I understand them. Everyone who uses javac will. ecj's "numeric" compliance options are a shortcut that save like 10 characters but they're rather obscure. Why bother? -- 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
Re: [I] Create a bot to check if there is a CHANGES entry for new PRs [lucene]
stefanvodita commented on issue #13898: URL: https://github.com/apache/lucene/issues/13898#issuecomment-2875933174 #14656 is what I was suggesting as an immediate step. I wonder if all contributors have permissions to add labels to their PRs though. -- 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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dweiss commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2875975752 > Just to confirm that my observations are correct: Did you measure slowness with this PR if executed in Java 25? I don't see a lot of slowdown at all when I run on Java 21+. It is slightly slower but nowhere near what it used to be. I still don't see the point of using this entire back-compat infrastructure if it's duplicated in javac anyway. -- 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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
rmuir commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2875984812 Please don't enable this slowness, there is zero benefit as javac already checks it. We don't need it. Just avoid 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
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
rmuir commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2086524077
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
-args += [ "-source", project.java.sourceCompatibility ]
-args += [ "-target", project.java.targetCompatibility ]
+args += ["-$project.java.sourceCompatibility"] // "compliance" level
Review Comment:
Please don't change commandline flags here.
Somehow this issue has turned into... let's slow down the build.
It should be possible to template a string without changing stuff like this
and slowing down the build.
--
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
Re: [PR] Update IndicNormalizer.java [lucene]
github-actions[bot] commented on PR #14657: URL: https://github.com/apache/lucene/pull/14657#issuecomment-2877137967 This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. If the PR doesn't need a changelog entry, then add the label to it and you will stop receiving this reminder on future updates to the 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
[PR] Update IndicNormalizer.java [lucene]
Trey314159 opened a new pull request, #14657: URL: https://github.com/apache/lucene/pull/14657 Remove Telugu normalization of vu వు to ma మ from IndicNormalizer. ### Description Telugu vu వు and ma మ are visually similar—akin to English "rn" and "m"—but they should not be conflated. Names like వెంకటరామ (Venkatarama) and వెంకటరావు (Venkatarao) and words like [మండే](https://te.wiktionary.org/wiki/%E0%B0%AE%E0%B0%82%E0%B0%A6%E0%B0%BF) and [వుండే](https://te.wiktionary.org/wiki/%E0%B0%B5%E0%B1%81%E0%B0%82%E0%B0%A6%E0%B0%BF) (links to Telugu Wiktionary) are distinct. It's like conflating _burn/bum_ and _corn/com._ It could happen when reading quickly or with poor handwriting, but it is not something that should happen for search indexing. -- 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
Re: [PR] Update verifier comment to show label [lucene]
stefanvodita merged PR #14658: URL: https://github.com/apache/lucene/pull/14658 -- 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
[PR] Update verifier comment to show label [lucene]
stefanvodita opened a new pull request, #14658: URL: https://github.com/apache/lucene/pull/14658 Noticed on #14657 that the label wasn't being shown in the [comment](https://github.com/apache/lucene/pull/14657#issuecomment-2877137967). Sorry for the churn! -- 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
[I] Remove Telugu normalization of vu వు to ma మ from IndicNormalizer [lucene]
Trey314159 opened a new issue, #14659: URL: https://github.com/apache/lucene/issues/14659 ### Description Telugu vu వు and ma మ are visually similar—akin to English "rn" and "m"—but they should not be conflated. Names like వెంకటరామ (Venkatarama) and వెంకటరావు (Venkatarao) and words like [మండే](https://te.wiktionary.org/wiki/%E0%B0%AE%E0%B0%82%E0%B0%A6%E0%B0%BF) and [వుండే](https://te.wiktionary.org/wiki/%E0%B0%B5%E0%B1%81%E0%B0%82%E0%B0%A6%E0%B0%BF) (links to Telugu Wiktionary) are distinct. It's like conflating "rn" and "m" to merge _burn/bum_ and _corn/com._ It could happen when reading quickly or with poor handwriting, but it is not something that should happen for search indexing. I notice that some of the Telugu elements of IndicNormalizer are in TeluguNormalizer, but this mapping is not—which is good! (Sorry for the botched pull request. Obviously this change would also affect some tests, which need to be updated or re-evaluated.) ### Version and environment details My version: "distribution" : "opensearch", "number" : "1.3.20", "lucene_version : "8.10.1" Running on x86_64 GNU/Linux in Docker 4.15.0 on MacOS 13.6.3. -- 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.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
Re: [PR] Update IndicNormalizer.java [lucene]
github-actions[bot] commented on PR #14657: URL: https://github.com/apache/lucene/pull/14657#issuecomment-2877267036 This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. If the PR doesn't need a changelog entry, then add the skip-changelog-check label to it and you will stop receiving this reminder on future updates to the 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
Re: [PR] Update IndicNormalizer.java [lucene]
Trey314159 closed pull request #14657: Update IndicNormalizer.java URL: https://github.com/apache/lucene/pull/14657 -- 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
Re: [PR] Update verifier comment to show label [lucene]
github-actions[bot] commented on PR #14658: URL: https://github.com/apache/lucene/pull/14658#issuecomment-2877161916 This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. If the PR doesn't need a changelog entry, then add the label to it and you will stop receiving this reminder on future updates to the 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
