+1
On Feb 17, 2005, at 6:11 AM, Erik Hatcher wrote:
The Incubator requires the Lucene PMC vote on whether to accept the
lucene4c codebase.
+1 from me.
Other Lucene PMC members - please cast your vote on this thread.
Erik
Begin forwarded message:
From: Cliff Schmidt [EMAIL PROTECTED]
+1
smime.p7s
Description: S/MIME cryptographic signature
+1
On Jan 11, 2005, at 1:11 PM, Doug Cutting wrote:
Sigh. This stuff would get a lot simpler if we were able to use Java
1.4's FileLock. Then locks would be automatically cleared by the OS
if the JVM crashes.
Should we upgrade the JVM requirements to 1.4 for Lucene's 1.9/2.0
releases and
Nope, that's the way to do it.
S
On Jan 4, 2005, at 11:53 AM, George Aroush wrote:
Hi folks,
In Lucene, how can I retrieve all documents that don't match the term
of my
query? That is, I want all documents that don't have the word CAT.
The only way I can think of how to do it now is to create a
I support this and I'm willing to help.
Scott
On Dec 10, 2004, at 3:18 PM, Erik Hatcher wrote:
The idea of creating a new top-level Apache project, namely
search.apache.org, has been floating around for a while. The idea is
to bring Lucene under this new umbrella, along with incubating Nutch
I prefer this as well. But then again I didn't agree with the
TooManyClauses decision, either, where it was decided that the better
good was served by protecting the user regardless of whether he or she
wanted it. Isn't this pretty much debating this philosophy again?
On Oct 20, 2004, at
I just thought the group might want to be aware of this perception:
http://www.drbacchus.com/journal/archives/000555.html
S
smime.p7s
Description: S/MIME cryptographic signature
I like this one (and it uses Lucene): http://snipsnap.org/. It's a
blog and a wiki at once...
Scott
On Feb 28, 2004, at 8:37 AM, Michael McGrady wrote:
Where can I get a good Java wiki? What is the best? Don't be shy.
Michael McGrady
+1. Excellent addition.
On Feb 25, 2004, at 5:21 PM, Doug Cutting wrote:
I propose that we add Tim Jones, author of the recently added result
sorting code, as a Lucene committer.
Votes?
Doug
-
To unsubscribe, e-mail: [EMAIL
In the process of debugging I noticed some code in the Lock class that
I believe is not ideal. In the method obtain(long lockWaitTimeout)
you'll see the following code:
int maxSleepCount = (int)(lockWaitTimeout / LOCK_POLL_INTERVAL);
int sleepCount = 0;
while (!locked) {
if (++sleepCount ==
It is a simple matter to wrap the Lucene API to do what you are
requesting. However, I don't believe it is likely that you'll see
Lucene itself changed to do this.
Scott
On Dec 9, 2003, at 6:37 AM, Leos Literak wrote:
Hi,
I understand this point of view, though I would love to see one
I'm no expert in NIO, but I've heard a lot of people claim that NIO
improvements over traditional I/O can be significant. I don't know if
it would work for your case (does it have to map the entire file into
memory?), but you might try the NIODirectory implementation that
Francesco Bellomi
My vote is with option 3.
Scott
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I have always been rather troubled by this Exception. The truth is
that by imposing a limitation where there was none before, this change
is already an incompatible change to the existing API. Hiding the fact
that the original contract has been broken by using a RuntimeException
to slip past
a strongly-typed language...)
Scott
On Nov 26, 2003, at 5:08 PM, Doug Cutting wrote:
Scott ganyo wrote:
I have always been rather troubled by this Exception. The truth is
that by imposing a limitation where there was none before, this
change is already an incompatible change to the existing
+1
Doug Cutting wrote:
Should I go ahead and make this release, or should we wait for a fix
to the timestamp problem? I'm leaving town Thursday, and can either
make this release tomorrow morning, or not until November. My hunch
is to go ahead and make an RC release tomorrow, then, in
+1. Let's keep the Lucene core focused on things that really are core
to indexing and retrieval.
Otis Gospodnetic wrote:
Couldn't we also stick this in the Sandbox, make sure it builds into a
nice little Jar, and just document it in the Lucene's xdocs?
I'm just thinking that highlighting is
Actually, I think anyone's informed opinion counts...
Anyway, it's not that I don't like it. I think it is a good thing to
support highlighting. I just don't think it should be core
functionality as I believe that probably every project that uses Lucene
and wants to do highlighting will end
Ok, I know I said I'd check in Wednesday, but as it turns out I'm going
to be out Wednesday. So, as there has only been positive feedback, I'm
just going to go ahead and commit now.
Scott
Scott Ganyo wrote:
As suggested in previous emails, I have implemented the ability to
wait on any kind
Ok. I'll buy that. Consider the TIMEOUT constants moved.
Scott
Doug Cutting wrote:
Scott Ganyo wrote:
Thanks, Doug. Unfortunately, as you know, IndexWriter isn't the only
one using these locks:
1) IndexReader uses the commit.lock when opening.
2) IndexReader needs to create a write.lock
As suggested in previous emails, I have implemented the ability to wait
on any kind of lock. I've attached the diffs, but here are the highlights:
1) added the following statics to Lock:
public static long WRITE_LOCK_TIMEOUT = 1000;
public static long COMMIT_LOCK_TIMEOUT = 1;
I guess I don't mind it being packaged as part of the base download
(although I have no use for them)... but I would prefer that it remain
a separate jar file from the core Lucene classes.
Scott
David Birtwell wrote:
On Wednesday, March 19, 2003, at 03:26 PM, Doug Cutting wrote:
Shall we
Nice optimization! If I read this right, I believe that this should
have a beneficial impact on RangeQuery as well as PrefixQuery. Have you
had a chance to try it?
Thanks,
Scott
Dmitry Serebrennikov wrote:
Greetings,
I've been running Lucene (inside of our application) in OptimizeIt to
see
I'm ok with this, given the lack of a better option. Please ensure that
the input and output streams are closed in a finally block, though.
Scott
Otis Gospodnetic wrote:
I hate having to make the suggested change for the reasons Matt
mentioned as disadvantages belowbut what is one to do?
+1. In general, I don't believe that returning Iterators is a good
idea. Whenever feasible, I would return a Collection instead of an
Iterator.
Scott
Materna, Wolf-Dietrich (empolis B) wrote:
[Clemens Marschner]
Instead of returning Object[] or Collection I would
consider returning an
Follow up to my other comment about not passing Iterators. Here is the
official word from the designer of the Java Collections API:
http://java.sun.com/products/jdk/1.2/docs/guide/collections/designfaq.html#8
Scott
Clemens Marschner wrote:
Instead of returning Object[] or Collection I would
and think about rewriting those for consistency's sake?
Will submit updated diffs to the list (with Collection-Set) later today.
Peter
/
/Scott Ganyo wrote:
+1. In general, I don't believe that returning Iterators is a good
idea. Whenever feasible, I would return a Collection instead
+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
Yes, especially on OS X or Solaris! :-P
-Original Message-
From: Dmitry Serebrennikov [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 12, 2002 5:08 PM
To: Lucene Developers List
Subject: Re: [ANN] NLucene 1.2b released
So is this really a one-for-one port to C# or is it some sort
That's interesting. So it would be a very small change to add transactional
(and even 2-phase commit) capabilities to the writer? What about deletes?
Since they use the reader, would it still be possible to allow a 2-phase
commit/abort on that?
I would very much like to have a 2-phase commit
If you're basically looking for a query, try using a RangeQuery instead of a
Filter. I think a filter is really best used if you are doing multiple
queries on a subset of your data that you can create a filter for.
Scott
P.S. This question really should have been asked on the *users* list, not
[+1] Have RC5 be Final 1.2 Release
-Original Message-
From: Peter Carlson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 28, 2002 12:14 PM
To: Lucene Developers List
Subject: VOTE: Final Release
Hi All,
It has been almost 2 weeks since we release RC5 and it looks
like
Personally, I wouldn't recommend this. The only thing it does is circumvent
the built-in Serialization protection mechanism.
(It's somewhat akin to immediately slashing the seatbelt of your new care
because someday that belt might keep you from being thrown free of your
fire-enveloped car. ;)
I have a related problem where I attempt to use Lucene as a duplicate
checking mechanism. I've found that it is very difficult to get Lucene to
give a decent probability of duplication because of this specific type of
weighting that is done.
Scott
-Original Message-
From: Halcsy Pter
FYI - The latest edition of Java Developers Journal has an article on using
JavaCC.
-Original Message-
From: Lee Mallabone [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 10, 2002 10:39 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: HighLighting Service
On Wed,
Peter wrote:
In step 3. -- since there is only one reference to the
searhcer -- the real searcher is closed:
original-code
else // last reference to searcher
{
info.searcher.close();
}
/original-code
The info isn't deleted.
In
(quotes clipped for brevity)
1. Why don't we have as many control/manager object as index
we want to use?
2. Why is it a static class with only static methods?
That would destroy what this class is attempting to accomplish: Guarding
the index resources so that you don't have to think
Yes, but then you rely on the user to make sure that they
don't create two
on the same path, right? If you really don't like the static
style for some
reason (why?), I suppose we could have a static accessor like:
IndexAccessControl getController(path) and maintain an
internal map of
Come on, what are we really asking of folks here? That those who wish to
*build* Lucene know a little bit about reading an XML file? Why would this
be a problem? You can always download the latest nightly binaries or
whatever if you aren't up to building it.
I would prefer that the
I'm proposing the following changes to Term and Query (just added
implements java.io.Serializable). The changes work fine and we've tested
them in a distributed environment. Any objections?
Thanks,
Scott
Index: src/java/org/apache/lucene/index/Term.java
, February 05, 2002 12:53 PM
To: Lucene Developers List
Subject: Re: Making Term and Query serializable
Serializable is only a 'markup interface', isn't it?
I don't see why not...
Otis
--- Scott Ganyo [EMAIL PROTECTED] wrote:
I'm proposing the following changes to Term and Query (just added
Ok with me.
Scott
-Original Message-
From: Doug Cutting [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 21, 2002 12:41 PM
To: '[EMAIL PROTECTED]'
Subject: parsing range queries: should they be analyzed?
(I have some time to work on Lucene this week, so I'm going
through old
Yes, this is the exact error that I've addressed in the patch I'm about to
check in for SegmentTermEnum.
Scott
-Original Message-
From: Anders Nielsen [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 11, 2001 9:57 AM
To: [EMAIL PROTECTED]
Subject: Null pointer error when
first offspring
shall proudly bear the name Scott..
In other words: thanks
regards,
Anders Nielsen
-Original Message-
From: Scott Ganyo [mailto:[EMAIL PROTECTED]]
Sent: 11. oktober 2001 17:07
To: '[EMAIL PROTECTED]'
Subject: RE: Null pointer error when searching with DateFilter
I'm getting a NullPointerException when a requested Term is greater than
(using compareTo) all existing Terms in a given segment. Here are my
proposed changes:
[Index: SegmentsReader.java]
[===]
[RCS file:
45 matches
Mail list logo
