[jira] [Resolved] (LUCENE-10673) Spatial3d fails constructing a legal bounding box
[
https://issues.apache.org/jira/browse/LUCENE-10673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignacio Vera resolved LUCENE-10673.
---
Fix Version/s: 9.4
Assignee: Ignacio Vera
Resolution: Fixed
> Spatial3d fails constructing a legal bounding box
> -
>
> Key: LUCENE-10673
> URL: https://issues.apache.org/jira/browse/LUCENE-10673
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Ignacio Vera
>Priority: Major
> Fix For: 9.4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The issue can be reproduced with the following test:
> {code}
> @Test
> public void testBBoxLatDegenerate() {
> double minX = Geo3DUtil.fromDegrees(-180.0);
> double maxX = Geo3DUtil.fromDegrees(-174.3758381903);
> double minY = Geo3DUtil.fromDegrees(89.9765306711);
> double maxY = Geo3DUtil.fromDegrees(89.9794643372);
> assertNotNull(GeoAreaFactory.makeGeoArea(PlanetModel.SPHERE, maxY,
> minY, minX, maxX));
> }
> {code}
> this currently fails with the following error:
> {code}
> Cannot determine sidedness because check point is on plane.
> java.lang.IllegalArgumentException: Cannot determine sidedness because check
> point is on plane.
> at
> __randomizedtesting.SeedInfo.seed([F8095E23398C1BA6:396A213B6362092D]:0)
> at
> org.apache.lucene.spatial3d.geom.SidedPlane.(SidedPlane.java:137)
> at
> org.apache.lucene.spatial3d.geom.GeoRectangle.(GeoRectangle.java:149)
> at
> org.apache.lucene.spatial3d.geom.GeoBBoxFactory.makeGeoBBox(GeoBBoxFactory.java:134)
> at
> org.apache.lucene.spatial3d.geom.GeoAreaFactory.makeGeoArea(GeoAreaFactory.java:43)
> at
> org.apache.lucene.spatial3d.geom.TestGeoBBox.testBBoxLonDegenerate(TestGeoBBox.java:538)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10673) Spatial3d fails constructing a legal bounding box
[
https://issues.apache.org/jira/browse/LUCENE-10673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575016#comment-17575016
]
ASF subversion and git services commented on LUCENE-10673:
--
Commit 17e8a42e1aa5c5c8328b2e675605a731adeea201 in lucene's branch
refs/heads/branch_9x from Ignacio Vera
[ https://gitbox.apache.org/repos/asf?p=lucene.git;h=17e8a42e1aa ]
LUCENE-10673: Improve check of equality for latitudes for spatial3d
GeoBoundingBox (#1056)
> Spatial3d fails constructing a legal bounding box
> -
>
> Key: LUCENE-10673
> URL: https://issues.apache.org/jira/browse/LUCENE-10673
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The issue can be reproduced with the following test:
> {code}
> @Test
> public void testBBoxLatDegenerate() {
> double minX = Geo3DUtil.fromDegrees(-180.0);
> double maxX = Geo3DUtil.fromDegrees(-174.3758381903);
> double minY = Geo3DUtil.fromDegrees(89.9765306711);
> double maxY = Geo3DUtil.fromDegrees(89.9794643372);
> assertNotNull(GeoAreaFactory.makeGeoArea(PlanetModel.SPHERE, maxY,
> minY, minX, maxX));
> }
> {code}
> this currently fails with the following error:
> {code}
> Cannot determine sidedness because check point is on plane.
> java.lang.IllegalArgumentException: Cannot determine sidedness because check
> point is on plane.
> at
> __randomizedtesting.SeedInfo.seed([F8095E23398C1BA6:396A213B6362092D]:0)
> at
> org.apache.lucene.spatial3d.geom.SidedPlane.(SidedPlane.java:137)
> at
> org.apache.lucene.spatial3d.geom.GeoRectangle.(GeoRectangle.java:149)
> at
> org.apache.lucene.spatial3d.geom.GeoBBoxFactory.makeGeoBBox(GeoBBoxFactory.java:134)
> at
> org.apache.lucene.spatial3d.geom.GeoAreaFactory.makeGeoArea(GeoAreaFactory.java:43)
> at
> org.apache.lucene.spatial3d.geom.TestGeoBBox.testBBoxLonDegenerate(TestGeoBBox.java:538)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10673) Spatial3d fails constructing a legal bounding box
[
https://issues.apache.org/jira/browse/LUCENE-10673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575015#comment-17575015
]
ASF subversion and git services commented on LUCENE-10673:
--
Commit bd0718f0716ad3f30e0d79b352cd678df249f550 in lucene's branch
refs/heads/main from Ignacio Vera
[ https://gitbox.apache.org/repos/asf?p=lucene.git;h=bd0718f0716 ]
LUCENE-10673: Improve check of equality for latitudes for spatial3d
GeoBoundingBox (#1056)
> Spatial3d fails constructing a legal bounding box
> -
>
> Key: LUCENE-10673
> URL: https://issues.apache.org/jira/browse/LUCENE-10673
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The issue can be reproduced with the following test:
> {code}
> @Test
> public void testBBoxLatDegenerate() {
> double minX = Geo3DUtil.fromDegrees(-180.0);
> double maxX = Geo3DUtil.fromDegrees(-174.3758381903);
> double minY = Geo3DUtil.fromDegrees(89.9765306711);
> double maxY = Geo3DUtil.fromDegrees(89.9794643372);
> assertNotNull(GeoAreaFactory.makeGeoArea(PlanetModel.SPHERE, maxY,
> minY, minX, maxX));
> }
> {code}
> this currently fails with the following error:
> {code}
> Cannot determine sidedness because check point is on plane.
> java.lang.IllegalArgumentException: Cannot determine sidedness because check
> point is on plane.
> at
> __randomizedtesting.SeedInfo.seed([F8095E23398C1BA6:396A213B6362092D]:0)
> at
> org.apache.lucene.spatial3d.geom.SidedPlane.(SidedPlane.java:137)
> at
> org.apache.lucene.spatial3d.geom.GeoRectangle.(GeoRectangle.java:149)
> at
> org.apache.lucene.spatial3d.geom.GeoBBoxFactory.makeGeoBBox(GeoBBoxFactory.java:134)
> at
> org.apache.lucene.spatial3d.geom.GeoAreaFactory.makeGeoArea(GeoAreaFactory.java:43)
> at
> org.apache.lucene.spatial3d.geom.TestGeoBBox.testBBoxLonDegenerate(TestGeoBBox.java:538)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] iverase merged pull request #1056: LUCENE-10673: Improve check of equality for latitudes for spatial3d GeoBoundingBox
iverase merged PR #1056: URL: https://github.com/apache/lucene/pull/1056 -- 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] [Updated] (LUCENE-10670) Add a Codec class to track merge time of each index part
[ https://issues.apache.org/jira/browse/LUCENE-10670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuan Xiao updated LUCENE-10670: --- Description: Lucene has applied filter pattern to *Path*, *Codec*, *Reader* etc(FilterPath, FilterCodec, FilterReader) , we should do the same for Writer/Producer/Reader/Consumer/Format(postings, points, doc values, vectors, stored fields, live docs, term vectors) under Codec. One use case is enabling probe the merge time of different file format by making a FilterCodec that overrides the merge method of each Codec format writer through these filters. It will allow downstream to add any additional functionality to those classes. I have opened up a PR for this use case. Any suggestions of different ways to track index parts merge time is welcome. was: Lucene has applied filter pattern to *Path*, *Codec*, *Reader* etc(FilterPath, FilterCodec, FilterReader) , we should do the same for Writer/Producer/Reader/Consumer/Format(postings, points, doc values, vectors, stored fields, live docs, term vectors) under Codec. One use case is enabling probe the merge time of different file format by making a FilterCodec that overrides the merge method of each Codec format writer through these filters. It will allow downstream to add any additional functionality to those classes. I have opened up a PR Any suggestions is welcome. Summary: Add a Codec class to track merge time of each index part (was: Add Filter class to Codec Writer/Producer/Reader/Consumer/Format) > Add a Codec class to track merge time of each index part > > > Key: LUCENE-10670 > URL: https://issues.apache.org/jira/browse/LUCENE-10670 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Yuan Xiao >Priority: Major > > Lucene has applied filter pattern to *Path*, *Codec*, *Reader* > etc(FilterPath, FilterCodec, FilterReader) , we should do the same for > Writer/Producer/Reader/Consumer/Format(postings, points, doc values, vectors, > stored fields, live docs, term vectors) under Codec. > One use case is enabling probe the merge time of different file format by > making a FilterCodec that overrides the merge method of each Codec format > writer through these filters. > It will allow downstream to add any additional functionality to those > classes. > I have opened up a PR for this use case. > Any suggestions of different ways to track index parts merge time is welcome. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] yugushihuang opened a new pull request, #1057: Add a codec class to track merge time of each index part
yugushihuang opened a new pull request, #1057: URL: https://github.com/apache/lucene/pull/1057 This PR add filter class for each index format classes and their writer/producer/reader/consumer and add a tracking codec class to track merge time of each index part. [Jira Issue Link](https://issues.apache.org/jira/projects/LUCENE/issues/LUCENE-10670) -- 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] [Updated] (LUCENE-10670) Add Filter class to Codec Writer/Producer/Reader/Consumer/Format
[ https://issues.apache.org/jira/browse/LUCENE-10670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuan Xiao updated LUCENE-10670: --- Description: Lucene has applied filter pattern to *Path*, *Codec*, *Reader* etc(FilterPath, FilterCodec, FilterReader) , we should do the same for Writer/Producer/Reader/Consumer/Format(postings, points, doc values, vectors, stored fields, live docs, term vectors) under Codec. One use case is enabling probe the merge time of different file format by making a FilterCodec that overrides the merge method of each Codec format writer through these filters. It will allow downstream to add any additional functionality to those classes. I have opened up a PR Any suggestions is welcome. was: Lucene has applied filter pattern to *Path*, *Codec*, *Reader* etc(FilterPath, FilterCodec, FilterReader) , we should do the same for Writer/Producer/Reader/Consumer/Format(postings, points, doc values, vectors, stored fields, live docs, term vectors) under Codec. One use case is enabling probe the merge time of different file format by making a FilterCodec that overrides the merge method of each Codec format writer through these filters. It will allow downstream to add any additional functionality to those classes. > Add Filter class to Codec Writer/Producer/Reader/Consumer/Format > > > Key: LUCENE-10670 > URL: https://issues.apache.org/jira/browse/LUCENE-10670 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Yuan Xiao >Priority: Major > > Lucene has applied filter pattern to *Path*, *Codec*, *Reader* > etc(FilterPath, FilterCodec, FilterReader) , we should do the same for > Writer/Producer/Reader/Consumer/Format(postings, points, doc values, vectors, > stored fields, live docs, term vectors) under Codec. > One use case is enabling probe the merge time of different file format by > making a FilterCodec that overrides the merge method of each Codec format > writer through these filters. > It will allow downstream to add any additional functionality to those > classes. > I have opened up a PR > Any suggestions is welcome. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-jira-archive] mikemccand merged pull request #108: Reorder text processing, tweak mention format, escape tilde
mikemccand merged PR #108: URL: https://github.com/apache/lucene-jira-archive/pull/108 -- 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-jira-archive] mocobeta commented on issue #89: Excess strike-through on conversion
mocobeta commented on issue #89: URL: https://github.com/apache/lucene-jira-archive/issues/89#issuecomment-1204100796 No, in fact, it should be safely done - #108. -- 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-jira-archive] mocobeta commented on a diff in pull request #108: Reorder text processing, tweak mention format, escape tilde
mocobeta commented on code in PR #108:
URL:
https://github.com/apache/lucene-jira-archive/pull/108#discussion_r936795884
##
migration/src/jira_util.py:
##
@@ -287,9 +276,23 @@ def escape_gh_issue_link(m: re.Match):
disp_name = jira_users.get(jira_id)
gh_m = account_map.get(jira_id)
# replace Jira name with GitHub account or Jira display name if it
is available, othewise show Jira name with ``
-mention = lambda: f"@{gh_m}" if gh_m else disp_name if disp_name
else f"`~{jira_id}`"
+mention = lambda: f"@{gh_m}" if gh_m else disp_name if disp_name
else f"`@{jira_id}`"
text = text.replace(m, mention())
+# escape tilde to avoid unintentional strike-throughs in Markdown
+text = text.replace("~", "\~")
Review Comment:
Escape `~` **before** Markdown conversion and **after** mention conversion.
--
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-jira-archive] mocobeta commented on a diff in pull request #108: Reorder text processing, tweak mention format, escape tilde
mocobeta commented on code in PR #108:
URL:
https://github.com/apache/lucene-jira-archive/pull/108#discussion_r936796559
##
migration/src/jira_util.py:
##
@@ -287,9 +276,23 @@ def escape_gh_issue_link(m: re.Match):
disp_name = jira_users.get(jira_id)
gh_m = account_map.get(jira_id)
# replace Jira name with GitHub account or Jira display name if it
is available, othewise show Jira name with ``
-mention = lambda: f"@{gh_m}" if gh_m else disp_name if disp_name
else f"`~{jira_id}`"
+mention = lambda: f"@{gh_m}" if gh_m else disp_name if disp_name
else f"`@{jira_id}`"
text = text.replace(m, mention())
+# escape tilde to avoid unintentional strike-throughs in Markdown
+text = text.replace("~", "\~")
+
+# convert Jira markup into Markdown with customization
+elements = MarkupElements()
+elements.replace(UnorderedList, UnorderedTweakedList)
+elements.replace(OrderedList, OrderedTweakedList)
+elements.replace(BlockQuote, TweakedBlockQuote)
+elements.replace(Quote, TweakedQuote)
+elements.replace(Monospaced, TweakedMonospaced)
+elements.insert_after(Ruler, LongRuler)
+elements.append(EscapeHtmlTag)
+text = jira2markdown.convert(text, elements=elements)
Review Comment:
Do syntax conversion after escaping `~`.
--
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-jira-archive] mocobeta commented on a diff in pull request #108: Reorder text processing, tweak mention format, escape tilde
mocobeta commented on code in PR #108:
URL:
https://github.com/apache/lucene-jira-archive/pull/108#discussion_r936795884
##
migration/src/jira_util.py:
##
@@ -287,9 +276,23 @@ def escape_gh_issue_link(m: re.Match):
disp_name = jira_users.get(jira_id)
gh_m = account_map.get(jira_id)
# replace Jira name with GitHub account or Jira display name if it
is available, othewise show Jira name with ``
-mention = lambda: f"@{gh_m}" if gh_m else disp_name if disp_name
else f"`~{jira_id}`"
+mention = lambda: f"@{gh_m}" if gh_m else disp_name if disp_name
else f"`@{jira_id}`"
text = text.replace(m, mention())
+# escape tilde to avoid unintentional strike-throughs in Markdown
+text = text.replace("~", "\~")
Review Comment:
Escape `~` before Markdown conversion and after mention conversion.
--
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-jira-archive] mocobeta commented on a diff in pull request #108: Reorder text processing, tweak mention format, escape tilde
mocobeta commented on code in PR #108:
URL:
https://github.com/apache/lucene-jira-archive/pull/108#discussion_r936795269
##
migration/src/jira_util.py:
##
@@ -287,9 +276,23 @@ def escape_gh_issue_link(m: re.Match):
disp_name = jira_users.get(jira_id)
gh_m = account_map.get(jira_id)
# replace Jira name with GitHub account or Jira display name if it
is available, othewise show Jira name with ``
-mention = lambda: f"@{gh_m}" if gh_m else disp_name if disp_name
else f"`~{jira_id}`"
+mention = lambda: f"@{gh_m}" if gh_m else disp_name if disp_name
else f"`@{jira_id}`"
Review Comment:
Use `@` instead of `~` for mentions.
--
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-jira-archive] mocobeta commented on pull request #108: Reorder text processing, tweak mention format, escape tilde
mocobeta commented on PR #108: URL: https://github.com/apache/lucene-jira-archive/pull/108#issuecomment-1204091313 The result seems fine: https://github.com/mocobeta/migration-test-3/issues/522  -- 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-jira-archive] mocobeta opened a new pull request, #108: Reorder text processing, tweak mention format, escape tilde
mocobeta opened a new pull request, #108: URL: https://github.com/apache/lucene-jira-archive/pull/108 #89 I think this should be safe. 1. Convert Jira's `[~username]` mention to GitHub mention. 2. Escape all `~` in Jira data 3. Convert Jira syntax to Markdown -- 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-jira-archive] mocobeta commented on issue #89: Excess strike-through on conversion
mocobeta commented on issue #89: URL: https://github.com/apache/lucene-jira-archive/issues/89#issuecomment-1203992440 The difficulty here is that `~` actually has special meanings in both Jira syntax and Markdown. The conversion process is done as follows and the order is important. 1. Convert Jira syntax to Markdown 2. Convert Jira mentions to GitHub mentions Escaping `~` should be done _before_ 1) syntax conversion; otherwise valid strike-throughs in Markdown are affected. However, it also should be done _after_ 2) mention conversion; otherwise `[~username]` mentions are affected. We could find a tricky workaround, but I'm afraid any workaround has unpredictable side effects - I would leave this issue. -- 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] iverase opened a new pull request, #1056: LUCENE-10673: Improve check of equality for latitudes for GeoBoundingBox
iverase opened a new pull request, #1056: URL: https://github.com/apache/lucene/pull/1056 The PR makes two latitudes to be equal if the value of the sine is lower than the vector resolution. -- 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-jira-archive] mocobeta commented on issue #106: Inlined patches don't migrate correctly
mocobeta commented on issue #106: URL: https://github.com/apache/lucene-jira-archive/issues/106#issuecomment-1203827169 Thanks, I added this to the migration plan (or to-do list) in #7. -- 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-10672) Re-evaluate different ways to encode postings
[
https://issues.apache.org/jira/browse/LUCENE-10672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17574668#comment-17574668
]
Michael McCandless commented on LUCENE-10672:
-
+1
Maybe we can also peek at how Vespa and Tantivy do their encoding ... any
inspiration there?
The world needs more popular open-search source engines.
> Re-evaluate different ways to encode postings
> -
>
> Key: LUCENE-10672
> URL: https://issues.apache.org/jira/browse/LUCENE-10672
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
>
> In Lucene 4, we moved to FOR to encode postings because it woud give better
> throughput compared to VInts that we had been using until then. This was a
> time when Lucene would often need to evaluate entire postings lists, and
> optimizations like BS1 were very important for good performance.
> Nowadays, Lucene performs more dynamic pruning and it's less frequent that
> Lucene needs to evaluate all hits that match a query. So the performance of
> {{nextDoc()}} has become a bit less relevant while the performance of
> {{advance(target)}} has become more relevant.
> I wonder if we should re-evaluate other ways to encode postings that are
> theoretically better at skipping, such as Elias-Fano coding, since they
> support skipping directly on the encoded representation instead of requiring
> decoding a full block of integers where only a couple of them would be
> relevant.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-10673) Spatial3d fails constructing a legal bounding box
[
https://issues.apache.org/jira/browse/LUCENE-10673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignacio Vera updated LUCENE-10673:
--
Component/s: modules/spatial3d
> Spatial3d fails constructing a legal bounding box
> -
>
> Key: LUCENE-10673
> URL: https://issues.apache.org/jira/browse/LUCENE-10673
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Priority: Major
>
> The issue can be reproduced with the following test:
> {code}
> @Test
> public void testBBoxLatDegenerate() {
> double minX = Geo3DUtil.fromDegrees(-180.0);
> double maxX = Geo3DUtil.fromDegrees(-174.3758381903);
> double minY = Geo3DUtil.fromDegrees(89.9765306711);
> double maxY = Geo3DUtil.fromDegrees(89.9794643372);
> assertNotNull(GeoAreaFactory.makeGeoArea(PlanetModel.SPHERE, maxY,
> minY, minX, maxX));
> }
> {code}
> this currently fails with the following error:
> {code}
> Cannot determine sidedness because check point is on plane.
> java.lang.IllegalArgumentException: Cannot determine sidedness because check
> point is on plane.
> at
> __randomizedtesting.SeedInfo.seed([F8095E23398C1BA6:396A213B6362092D]:0)
> at
> org.apache.lucene.spatial3d.geom.SidedPlane.(SidedPlane.java:137)
> at
> org.apache.lucene.spatial3d.geom.GeoRectangle.(GeoRectangle.java:149)
> at
> org.apache.lucene.spatial3d.geom.GeoBBoxFactory.makeGeoBBox(GeoBBoxFactory.java:134)
> at
> org.apache.lucene.spatial3d.geom.GeoAreaFactory.makeGeoArea(GeoAreaFactory.java:43)
> at
> org.apache.lucene.spatial3d.geom.TestGeoBBox.testBBoxLonDegenerate(TestGeoBBox.java:538)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-10673) Spatial3d fails constructing a legal bounding box
Ignacio Vera created LUCENE-10673:
-
Summary: Spatial3d fails constructing a legal bounding box
Key: LUCENE-10673
URL: https://issues.apache.org/jira/browse/LUCENE-10673
Project: Lucene - Core
Issue Type: Bug
Reporter: Ignacio Vera
The issue can be reproduced with the following test:
{code}
@Test
public void testBBoxLatDegenerate() {
double minX = Geo3DUtil.fromDegrees(-180.0);
double maxX = Geo3DUtil.fromDegrees(-174.3758381903);
double minY = Geo3DUtil.fromDegrees(89.9765306711);
double maxY = Geo3DUtil.fromDegrees(89.9794643372);
assertNotNull(GeoAreaFactory.makeGeoArea(PlanetModel.SPHERE, maxY, minY,
minX, maxX));
}
{code}
this currently fails with the following error:
{code}
Cannot determine sidedness because check point is on plane.
java.lang.IllegalArgumentException: Cannot determine sidedness because check
point is on plane.
at
__randomizedtesting.SeedInfo.seed([F8095E23398C1BA6:396A213B6362092D]:0)
at
org.apache.lucene.spatial3d.geom.SidedPlane.(SidedPlane.java:137)
at
org.apache.lucene.spatial3d.geom.GeoRectangle.(GeoRectangle.java:149)
at
org.apache.lucene.spatial3d.geom.GeoBBoxFactory.makeGeoBBox(GeoBBoxFactory.java:134)
at
org.apache.lucene.spatial3d.geom.GeoAreaFactory.makeGeoArea(GeoAreaFactory.java:43)
at
org.apache.lucene.spatial3d.geom.TestGeoBBox.testBBoxLonDegenerate(TestGeoBBox.java:538)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-jira-archive] mikemccand commented on issue #106: Inlined patches don't migrate correctly
mikemccand commented on issue #106: URL: https://github.com/apache/lucene-jira-archive/issues/106#issuecomment-1203800580 Some of those are properly marked up with Jira's markup, and should migrate well, but others are not. Honestly, I still feel this is part of the "long tail" of Jira authors writing comments in invalid Jira markup, and we should not aim to correct their mistakes here. Maybe a best effort when we see the errors at most ... -- 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-jira-archive] mikemccand commented on issue #106: Inlined patches don't migrate correctly
mikemccand commented on issue #106:
URL:
https://github.com/apache/lucene-jira-archive/issues/106#issuecomment-1203799408
OK I iterated some more on my silly "attempt to detected diff/patch/quoted
code" to this VERY scratchy tool:
```
import os
import re
import glob
import json
reDiffLines = re.compile('^[\d,]+[cd][\d,]+\s*$', re.MULTILINE)
reDiffCommand = re.compile('\s+diff\s+[^\s]+')
reLeadingLessGreaterThan = re.compile(r'^[<>] .*?\);.*?', re.MULTILINE)
results = []
for file_name in glob.glob('jira-dump/*.json'):
s = open(file_name).read()
d = json.loads(s)
jira_id = d['key']
if not jira_id.startswith('LUCENE'):
print(f'SKIPPING: {jira_id}')
continue
fields = d['fields']
#print(fields.keys())
desc = fields['description']
#if desc is not None and ('\n---\n' in desc or
reDiffLines.search(desc)):
if desc is not None:
count = len(reLeadingLessGreaterThan.findall(desc))
if reDiffLines.search(desc) or count >= 2:
#print(f'MATCH: {d["key"]}\n {desc}')
#print(f'MATCH: {d["key"]}\n')
results.append((jira_id, f'*** Diff in desc?:
[{jira_id}](https://issues.apache.org/jira/browse/{jira_id})'))
#print(repr(desc))
if jira_id == 'LUCENE-825':
print(reDiffCommand.match(desc))
print(repr(desc))
for comment in fields['comment']['comments']:
comment_text = comment['body']
comment_id = comment['id']
count = len(reLeadingLessGreaterThan.findall(comment_text))
#if '\n---\n' in comment_text or reDiffLines.search(comment_text):
if reDiffLines.search(comment_text) or count > 2:
#print(f'MATCH: {d["key"]}\n {comment_text}')
jira_comment_link =
f'https://issues.apache.org/jira/browse/{jira_id}?focusedCommentId={comment_id}=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-{comment_id}'
results.append((jira_id, f'*** Diff in comment?:
[{jira_id}]({jira_comment_link})'))
if jira_id == 'LUCENE-5400':
print(reDiffCommand.search(comment_text))
print(repr(comment_text))
#print(repr(comment_text))
print(f'\n{len(results)} possible diffs:\n')
for jira_id, text in sorted(results, key=lambda x: int(x[0][7:])):
print(text)
```
It produces these results:
> 9 possible diffs:
*** Diff in desc?:
[LUCENE-108](https://issues.apache.org/jira/browse/LUCENE-108)
*** Diff in desc?:
[LUCENE-162](https://issues.apache.org/jira/browse/LUCENE-162)
*** Diff in desc?:
[LUCENE-327](https://issues.apache.org/jira/browse/LUCENE-327)
*** Diff in comment?:
[LUCENE-584](https://issues.apache.org/jira/browse/LUCENE-584?focusedCommentId=12487106=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12487106)
*** Diff in comment?:
[LUCENE-743](https://issues.apache.org/jira/browse/LUCENE-743?focusedCommentId=12520476=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12520476)
*** Diff in desc?:
[LUCENE-825](https://issues.apache.org/jira/browse/LUCENE-825)
*** Diff in desc?:
[LUCENE-5110](https://issues.apache.org/jira/browse/LUCENE-5110)
*** Diff in comment?:
[GitHub] [lucene-jira-archive] mikemccand commented on issue #106: Inlined patches don't migrate correctly
mikemccand commented on issue #106: URL: https://github.com/apache/lucene-jira-archive/issues/106#issuecomment-1203731966 > I can fix 19 issues by hand after the migration (there would be no hurry), could you tell me the issue numbers or commands to identify the issues with inline patches? OK will do -- I'll post my findings here. Thanks @mocobeta. -- 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-10672) Re-evaluate different ways to encode postings
Adrien Grand created LUCENE-10672:
-
Summary: Re-evaluate different ways to encode postings
Key: LUCENE-10672
URL: https://issues.apache.org/jira/browse/LUCENE-10672
Project: Lucene - Core
Issue Type: Task
Reporter: Adrien Grand
In Lucene 4, we moved to FOR to encode postings because it woud give better
throughput compared to VInts that we had been using until then. This was a time
when Lucene would often need to evaluate entire postings lists, and
optimizations like BS1 were very important for good performance.
Nowadays, Lucene performs more dynamic pruning and it's less frequent that
Lucene needs to evaluate all hits that match a query. So the performance of
{{nextDoc()}} has become a bit less relevant while the performance of
{{advance(target)}} has become more relevant.
I wonder if we should re-evaluate other ways to encode postings that are
theoretically better at skipping, such as Elias-Fano coding, since they support
skipping directly on the encoded representation instead of requiring decoding a
full block of integers where only a couple of them would be relevant.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
