I thought I tried to contribute this months ago but I can't find
the orig post - no problem - I'd just be happy to see it get in.
And yes, there was the same discussion about ctr vs. helper method.
-Original Message-
From: Otis Gospodnetic [mailto:otis_gospodnetic;yahoo.com]
Sent:
I like this, thanks for the contribution!
Developers:
Shall we include this?
Shall we include this as is in a new org.apache.lucene.util package?
Shall we include this as is in the org.apache.lucene.store package?
Shall we just add the convert method to FSDirectory class?
Thanks,
Otis
---
otis2002/10/17 19:32:44
Removed: xdocslucenesandbox.xml
docs lucenesandbox.html
Log:
- These files have been replaced by nicer looking (x)docs/lucene-sandox* pages.
--
To unsubscribe, e-mail: mailto:lucene-dev-unsubscribe;jakarta.apache.org
For
Opps - one thing missing -probably - a d.close(); at the end,
though one might argue that the caller should close it but it's
more in the spirit of the use case for this method/ctr to do it.
-Original Message-
From: Otis Gospodnetic [mailto:otis_gospodnetic;yahoo.com]
Sent: Thursday,
Why not add this code to a RAMDirectory constructor like:
public RAMDirectory(Directory d) throws IOException {
this();
final String[] ar = d.list();
for (int i = 0; i ar.length; i++) {
// make place on ram disk
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12667.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Moved to lucene-dev.
Wow, this sounds good, but I'd love to see the code first and see how
this log file business works first.
Also, I don't think we ever got any tests that use multiple threads and
demonstrate the problems with symultaneous read/write/delete, etc.
It would be nice to have
otis2002/10/17 19:28:19
Added: lib junit-3.8.1.jar
Removed: lib junit_37.jar
Log:
- Removed JUnit 3.7 and added JUnit 3.8.1. All unit tests work with it.
Revision ChangesPath
1.1 jakarta-lucene/lib/junit-3.8.1.jar
Binary
Yes, I forgot to list that option.
Btw. this all sounds very familiar. I thought somebody (from France?)
has already contributed this months ago.
Otis
--- Eric Isakson [EMAIL PROTECTED] wrote:
Why not add this code to a RAMDirectory constructor like:
public RAMDirectory(Directory d)
+1
-Original Message-
From: Eric Isakson [mailto:Eric.Isakson;sas.com]
Sent: Thursday, October 17, 2002 1:43 PM
To: Lucene Developers List
Subject: RE: Converting a Directory to a RAMDirectory
Why not add this code to a RAMDirectory constructor like:
public
Another test file is attached.
-Message d'origine-
De : Andy Thomas [mailto:alt;picnic.demon.co.uk]
Envoyé : mercredi 16 octobre 2002 21:59
À : [EMAIL PROTECTED]
Objet : MultiSearch MultiTermQuery
Hi,
I recently posted a patch (summary included below) that fixes a problem
with
Hi,
now I'm finally done and already thinking about the new LARM developments.
I see the following priorities:
1) Make all properties for a crawl configurable
2) Update documentation and make LARM more public (and probably get more
developerts on the project)
3) Implement the politeness stuff.
Doug Cutting wrote:
David Birtwell wrote:
To enable this, Similarity could have a method like:
float applyNorm(float baseScore)
which could optionally ignore baseScore and modify the scorer classes
to do:
score = applyNorm(score)
instead of the
score *= Similarity.decodeNorms()
That
Great
Look forward to it.
--Peter
On Friday, October 18, 2002, at 02:01 PM, [EMAIL PROTECTED] wrote:
In the next couple of weeks (as time permits) I will clean up the code
from
Epiphany's proprietary stuff, maybe put some documentation, get green
light
from legal and send it over to
yes, there is a new interface that has FUID (fetch, insert, update, delete)
methods. And yes, system requires unique ID per document.
Currently it is using FS Directories, but it should be straight forward to
add support for RAM Directories.
In the next couple of weeks (as time permits) I will
15 matches
Mail list logo