bq. merging down every so often seems manageable so far (Mark?). Yeah, this has been working great from my perspective.
Michael McCandless wrote: > I think you should keep doing all LUCENE-1606 work (and, any other > issues) on trunk, and then we merge down to flex branch once it's > committed? > > We shouldn't hold up any trunk features because flex is > coming... > > I'm hoping to finish flex soonish -- largely what remains (I think!) > is better testing (correctness & performance) of the 4-way > combinations. I think the codecs approach is generally working > well.. the fact that we have initial Pulsing & PforDelta codecs > working is great. > > Mike > > On Sun, Nov 22, 2009 at 1:11 PM, Robert Muir <rcm...@gmail.com> wrote: > >> Mike, I guess what I am implying is should i even bother with lucene-1606 >> and trunk? >> >> or instead, should i be helping you, looking at TermsEnum, and working on >> integrating it into flex? >> >> On Sun, Nov 22, 2009 at 1:05 PM, Michael McCandless >> <luc...@mikemccandless.com> wrote: >> >>> On Sun, Nov 22, 2009 at 11:31 AM, Robert Muir <rcm...@gmail.com> wrote: >>> >>> >>>>> No, not really... just an optimization I found when hunting ;) >>>>> >>>>> I'm working now on an AutomatonTermsEnum that uses the flex API >>>>> directly, to test that performance. >>>>> >>>>> >>>> I didn't mean to 'bail out' on this >>>> >>> You didn't 'bail out'; I 'bailed in' ;) This is the joy of open >>> source... great big noisy Bazaar. >>> >>> >>>> but I could not tell if TermsEnum was close to stabilized >>>> >>> I think it's close; we need to do this port anyway, once automaton is >>> committed to trunk, so really I saved Mark some work ;) >>> >>> >>>> and it might be significant work to convert it? >>>> >>> It wasn't too bad, but maybe you can look it over once I post patch >>> and see if I messed anything up :) >>> >>> >>>> Maybe benching numeric range would be easier and accomplish the same >>>> thing? >>>> >>> Yeah benching NRQ would be good too... many benchmarks still to run. >>> >>> Mike >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: java-dev-h...@lucene.apache.org >>> >>> >> >> -- >> Robert Muir >> rcm...@gmail.com >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
