Re: Release 6.6

;>>> > >> >>>>>>>>>>> > Le 12 mai 2017 18:44, "Ishan Chattopadhyaya" >> >>>>>>>>>>> > a écrit : >> >>>>>>>>>>> > Sure, Jim. Please go ahead! >

Re: Release 6.6

>>> > a écrit : > >>>>>>>>>>> > Sure, Jim. Please go ahead! > >>>>>>>>>>> > > >>>>>>>>>>> > On Fri, May 12, 2017 at 10:01 PM, jim ferenczi > >>>>>>>>>>> > wrote: > >>>>>>>>>>> > Hi, > >>>>>>

Re: Release 6.6

gt;>> > wrote: >>>>>>>>>>> > Hi, >>>>>>>>>>> > Would be great to have >>>>>>>>>>> > https://issues.apache.org/jira/browse/LUCENE-7824 included for >>>>>>>

Re: Release 6.6

gt;>>>>> > >>>>>>>>>> > 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya < >>>>>>>>>> ichattopadhy...@gmail.com>: >>>>>>>>>> > Done, Adrien. Thanks! >>>>>>>>>> &g

Re: Release 6.6

Thanks! >>>>>>>>> > >>>>>>>>> > On Thu, May 11, 2017 at 7:34 PM, Adrien Grand >>>>>>>>> wrote: >>>>>>>>> > Ishan, wdyt about running addVersion on the branch_6x/master as >>>&

Re: Release 6.6

gt; wrote: >>>>>>>> > Ishan, wdyt about running addVersion on the branch_6x/master as >>>>>>>> well? I think it would help realize that the 6.6 branch has been cut >>>>>>>> when >>>>>>>> looking at the CHANGES.txt file and not forget about backporting? >>>>>

Re: Release 6.6

>>>> > >>>>>>>>> > On Thu, May 11, 2017 at 7:34 PM, Adrien Grand >>>>>>>>> > wrote: >>>>>>>>> > Ishan, wdyt about running addVersion on the branch_6x/master as >>>>>>>>&

Re: Release 6.6

d help realize that the 6.6 branch has been cut >>>>>>>> when >>>>>>>> looking at the CHANGES.txt file and not forget about backporting? >>>>>>>> > >>>>>>>> > Le mar. 9 mai 2017 à 17:58, Ishan Ch

Re: Release 6.6

gt;> >> //build spanQuery with term parameter >>>>>>> >> org.apache.lucene.search.spans.SpanQuery spanQuery1 = new >>>>>>> SpanTermQuery(term1); >>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayload

Re: Release 6.6

May. Please let me know if >>>>>> there are any objections. >>>>>> > >>>>>> > Thanks, >>>>>> > Ishan >>>>>> > >>>>>> > On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya < >>

Re: Release 6.6

17 at 11:10 AM, Ishan Chattopadhyaya < >>>>> ichattopadhy...@gmail.com> wrote: >>>>> > Planning to cut the release branch in another 10-12 hours. >>>>> > >>>>> > On Mon, May 1, 2017 at 4:00 PM, Martin Gainty >>>>> wrot

Re: Release 6.6

gt;>>> ichattopadhy...@gmail.com> wrote: >>>> > Planning to cut the release branch in another 10-12 hours. >>>> > >>>> > On Mon, May 1, 2017 at 4:00 PM, Martin Gainty >>>> wrote: >>>> > i was wondering if there was a specific test

Re: Release 6.6

;>> method >>> > >>> > matches = payloadToMatch.get(upto).bytesEquals(payload); >>> > >>> > >>> > >>> > the only implementation i could locate was in collectLeaf of >>> SpanPayloadCheckQuery >>> > &

Re: Release 6.6

yload); >> > >> > >> > >> > the only implementation i could locate was in collectLeaf of >> SpanPayloadCheckQuery >> > >> > >> > I will submit JIRA with Patch >> > >> > >> > as a CS *dinosaur* I am more familia

Re: Release 6.6

gt; > > > > > I will submit JIRA with Patch > > > > > > as a CS *dinosaur* I am more familiar with LISP for dissecting sentence > fragments (what we called phenomes) than current SEO implementations > > > > > > Can you suggest a book to read to

Re: Release 6.6

P for dissecting >sentence fragments (what we called phenomes) than current SEO >implementations >> >> >> Can you suggest a book to read to better understand Lucenes pattern >dissection and match algorithms? >> >> >> Many Thanks for helpful guidance >

Re: Release 6.6

e familiar with LISP for dissecting sentence > fragments (what we called phenomes) than current SEO implementations > > > Can you suggest a book to read to better understand Lucenes pattern > dissection and match algorithms? > > > Many Thanks for helpful guidance

Re: Release 6.6

> I will submit JIRA with Patch >>>>>> >>>>>> >>>>>> as a CS *dinosaur* I am more familiar with LISP for dissecting >>>>>> sentence fragments (what we called phenomes) than current SEO >>>>>> implementations

Re: Release 6.6

gt;>>>> as a CS *dinosaur* I am more familiar with LISP for dissecting >>>>>> sentence fragments (what we called phenomes) than current SEO >>>>>> implementations >>>>>> >>>>>> >>>>>>

Re: Release 6.6

;> I will submit JIRA with Patch >>>>> >>>>> >>>>> as a CS *dinosaur* I am more familiar with LISP for dissecting >>>>> sentence fragments (what we called phenomes) than current SEO >>>>> implementations >>>>> >>>>> >>>>> Can you sugge

Re: Release 6.6

dinosaur* I am more familiar with LISP for dissecting sentence >>>> fragments (what we called phenomes) than current SEO implementations >>>> >>>> >>>> Can you suggest a book to read to better understand Lucenes pattern >>>> dissection and mat

Re: Release 6.6

on and match algorithms? >>> >>> >>> Many Thanks for helpful guidance >>> Martin >>> __ >>> >>> >>> >>> >>> -- >>> *From:* Erik H

Re: Release 6.6

______ >> >> >> >> >> -- >> *From:* Erik Hatcher >> *Sent:* Sunday, April 30, 2017 2:06 PM >> >> *To:* dev@lucene.apache.org >> *Subject:* Re: Release 6.6 >> >>

Re: Release 6.6

org.apache. > lucene.index.PostingsEnum)postings, (int)position,(org.apache. > lucene.index.Term)term1); > } > catch(java.io.IOException ioe) { > log.debug("TestPayloadCheckQuery::testSpanPayloadCheck > LINE 264 query.getPayloadChecker().collectLeaf((org.apache. > lucene.index.PostingsEnum)postings, > (int)position,(org.apache.lucene.index.Term)term1) > LI

Re: Release 6.6

__ From: Erik Hatcher Sent: Sunday, April 30, 2017 2:06 PM To: dev@lucene.apache.org Subject: Re: Release 6.6 Martin - I have to admit to still being unsure what the gist is here - is there a bug? Apologies for not catching what you’re saying/showing here. Again

Re: Release 6.6

Leaf((org.apache.lucene.index.PostingsEnum)postings, > (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws > IOException ="+ioe.getMessage()); } > > collectLeaf is the only method that compares > matches=payloadToMatch.get(upto).bytesEquals(payload) > to determ

Re: Release 6.6

106 throws IOException ="+ioe.getMessage()); } collectLeaf is the only method that compares matches=payloadToMatch.get(upto).bytesEquals(payload) to determine "match" unless of course match between individual payload and payloadToMatch is tested elsewhere ? WDYT? Martin ___

Re: Release 6.6

__ > > > > From: Erik Hatcher > Sent: Saturday, April 29, 2017 8:58 AM > To: dev@lucene.apache.org > Subject: Re: Release 6.6 > > Martin - there is a test class specifically for this query. See the recent > commits I've made to test it fur

Re: Release 6.6

situation Thanks! Martin __ From: Erik Hatcher Sent: Saturday, April 29, 2017 8:58 AM To: dev@lucene.apache.org Subject: Re: Release 6.6 Martin - there is a test class specifically for this query. See the recent commits I've made to test it further fixing .equals/.hashCode and rewr

Re: Release 6.6

.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, > (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws > IOException ="+ioe.getMessage()); } > > unless of course anyone has a better idea to test collectLeaf ? > > Martin >

Re: Release 6.6

ion ="+ioe.getMessage()); } unless of course anyone has a better idea to test collectLeaf ? Martin __ From: Erik Hatcher Sent: Tuesday, April 25, 2017 7:57 PM To: dev@lucene.apache.org Subject: Re: Release 6.6 P

Re: Release 6.6

+1 to start complaining in logs ASAP. (Thanks for working on this Jan). On Wed, Apr 26, 2017 at 5:32 AM Jan Høydahl wrote: > I was hoping to nuke the and solrQueryParser from > schema https://issues.apache.org/jira/browse/SOLR-7041 > so 7.0.0 could get rid of that code/config completely. But a

Re: Release 6.6

I was hoping to nuke the and solrQueryParser from schema https://issues.apache.org/jira/browse/SOLR-7041 so 7.0.0 could get rid of that code/config completely. But a ton of tests still depend on these deprecated configs, and fixing it all in one

Re: Release 6.6

I’m a little tired of re-implementing the patch. I did it for 1.3, 3.x, and 4.x. Perhaps someone more familiar with edismax could take a look. With the 100X speedup for fuzzy in 4.x, should be widely useful. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog

Re: Release 6.6

Probably no bribe needed, but an updated patch would be a good start (or will the 2.5 year old patch still apply and be acceptable as-is?) Erik > On Apr 25, 2017, at 7:52 PM, Walter Underwood wrote: > > Who do I have to bribe to get SOLR-629 included? > > https://issues.apache.org/jir

Re: Release 6.6

Who do I have to bribe to get SOLR-629 included? https://issues.apache.org/jira/browse/SOLR-629 wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya > wro

Re: Release 6.6

I'd appreciate feedback on https://issues.apache.org/jira/browse/SOLR-10479 with a view towards making it into the 6.6 release. Christine - Original Message - From: dev@lucene.apache.org To: dev@lucene.apache.org At: 04/25/17 19:13:39 I’d like to get SOLR-1485, at least the numeric payl

Re: Release 6.6

I’d like to get SOLR-1485, at least the numeric payload value source part, in to 6.6. With some help (nudge nudge, Erickson) I think we can get this in by then. Erik > On Apr 25, 2017, at 1:46 PM, Ishan Chattopadhyaya > wrote: > > Hi, > We have lots of changes, optimizations, bug