DO NOT REPLY [Bug 34066] - [PATCH] Extension to binary Fields that allows fixed byte buffer

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 34066] - [PATCH] Extension to binary Fields that allows fixed byte buffer

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 34066] - [PATCH] Extension to binary Fields that allows fixed byte buffer

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 34066] New: - [PATCH] Extension to binary Fields that allows fixed byte buffer

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: snowball analyzer uismo issue in spanish stemmer

Erik Hatcher wrote: If you see regeneration differences would you please commit them? There were no differences. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: snowball analyzer uismo issue in spanish stemmer

On Mar 17, 2005, at 2:12 PM, Doug Cutting wrote: Erik Hatcher wrote: I just tried regenerating, which automatically pulls from CVS, and got this error: /Users/erik/dev/lucene/java/contrib/snowball/snowball/website/p/ generator.c:425: internal compiler error: in extract_insn, at recog.c:2175

Re: snowball analyzer uismo issue in spanish stemmer

Erik Hatcher wrote: I just tried regenerating, which automatically pulls from CVS, and got this error: /Users/erik/dev/lucene/java/contrib/snowball/snowball/website/p/ generator.c:425: internal compiler error: in extract_insn, at recog.c:2175 [apply] Please submit a full bug report, [a

Re: Interfaces

Erik Hatcher wrote: Ultimately, though, the decision to refactor the codebase to use interfaces more pervasively lies with Doug. Actually the decision lies not with me, but with the Lucene PMC as a group, according to Apache's voting process: http://www.apache.org/foundation/voting.html But, lik

RE: Interfaces

I only speak from current project experience, where we've developed a "search server" utilizing lucene , utilizing custom indexing formats in order to support high-speed incremental indexing. It was necessary to extend IndexReader in order to have the rest of the searching framework work properly,

Wanted Delphi developers for MUTIS (Lucene port to Delphi)

If some delphi developer read this list, MUTIS is looking for more developers. Read in https://sourceforge.net/people/viewjob.php?group_id=130034&job_id=21616. -- Mario Alejandro Montoya MCP www.solucionesvulcano.com !Obtenga su sitio Web dinámico!

Re: Interfaces

Erik Hatcher wrote: I think, though I'm not speaking for anyone here but myself, that the Lucene team is open to API improvements that _do not adversely affect performance_ and that have _a real benefit_. While I'm as IoC and design pattern savvy as the next developer, I'm also highly pragmatic

Re: Interfaces

On Mar 17, 2005, at 9:15 AM, Maik Schreiber wrote: Pragmatically, have you ever had addDocument fail? If not, then what peace of mind are you getting from such a test? The test I've shown is not supposed to test if addDocument() fails or not, but to test if addDocument() is invoked at all. The t

Re: Fwd: Recomended strategy for perform test cases for a new port

I finish the main (and boring!) part of port Lucene to Delphi (http://mutis.sourceforge.net/). So, I build some test cases and rigth now I pass test cases for: - BitVector - Field - DateField - Document - Number - PriorityQueue - StringHelper - Token - Analyzers (Simple,Null,Stop,Perfield) I want

Fwd: Recomended strategy for perform test cases for a new port

I don't know why, but this message not appear before in the list, so I resend it... -- Forwarded message -- From: Mario Alejandro M. <[EMAIL PROTECTED]> Date: Tue, 15 Mar 2005 16:28:01 -0500 Subject: Recomended strategy for perform test cases for a new port To: Lucene Developers L

Re: Precedence parser: NOT/AND, disableCoord

On Mar 15, 2005, at 3:57 PM, Paul Elschot wrote: On Tuesday 15 March 2005 01:55, Erik Hatcher wrote: I'd welcome others to give it a try, though. I'm still learning how to accomplish things with JavaCC. The basic rule is the deeper the nesting of the grammar construct, the higher the parsing prec

Re: Interfaces

Pragmatically, have you ever had addDocument fail? If not, then what peace of mind are you getting from such a test? The test I've shown is not supposed to test if addDocument() fails or not, but to test if addDocument() is invoked at all. The tested method was Foo.foo(), which could be doing

Re: Interfaces

I think, though I'm not speaking for anyone here but myself, that the Lucene team is open to API improvements that _do not adversely affect performance_ and that have _a real benefit_. While I'm as IoC and design pattern savvy as the next developer, I'm also highly pragmatic. I've not been con