: I think that it might be good to define 3 levels:
: fundamental - what all programs probably will use
: useful - what many programs might use
: contrib - mostly examples and code that is not quite ready to be
: classed as useful
Those three levels make sense -- but they don't map to what's curr
On Jun 20, 2006, at 6:43 PM, Yonik Seeley wrote:
On 6/20/06, DM Smith <[EMAIL PROTECTED]> wrote:
The problem
we have is trying to explain to users how to install java in order to
get our application to work.
Ahh... if you didn't already have a large code base, I'd suggest
trying PyLucene in
On Jun 21, 2006, at 3:43 AM, Chris Hostetter wrote:
: I think that it might be good to define 3 levels:
: fundamental - what all programs probably will use
: useful - what many programs might use
: contrib - mostly examples and code that is not quite ready to be
: classed as useful
Those thre
[ http://issues.apache.org/jira/browse/LUCENE-598?page=all ]
Simon Willnauer updated LUCENE-598:
---
Attachment: 21_06_06_milestone2.diff
Added Authentication component.
XSD Schema for configuration files.
Refactoring
Testcases
@Yonik & Doug
Please com
On Jun 20, 2006, at 6:42 PM, Robert Engels wrote:
Finding good SWT support on anything but the latest (and major)
OS's is
going to be rather poor and inconsistent. Just check the SWT bugs
(especially for things like printing).
For a company that seems to want to allow their users to stay in
This sounds reasonable to me...
Robert Engels wrote:
I don't follow...
If a user came to you and said I want to run BibleDesktop, and they have
MS-DOS, you would tell them you can't (or you might have to run the very old
BibleDesktop 1.0).
If they told you they have Windows 98 with Java 1.4 an
On Jun 21, 2006, at 7:52 AM, Grant Ingersoll wrote:
This sounds reasonable to me...
But it is not at all reasonable for us. Our application is designed
with a write one, run anywhere mentality for the hardware/OS base
that our users currently have. Again many of our users use old,
beyon
It sounds like you did something ill-advised. Why change your code to 1.5 if
a significant portion of your users can run it, and the previous release was
not essentially bug free (if it was, your users would not have seen any
difference).
It also seems very unlikely you need any significant change
CC'ing java-dev to talk about details of locking.
I can reproduce this on Windows XP, Java 1.4.2: two separate JVMs are able
to get the Lock at the same time.
The code looks correct to me.
Strangely, if I make a separate standalone test that just uses
java.io.File.createNewFile directly, it wo
OK, the root cause was found here (passing "true" as 2nd arg to
FSDirectory.getDirectory(...)) -- that was causing the directory (and lock
file) to be removed.
But I think the questions below of java.io.File.createNewFile vs
java.nio.channels.FileLock for locking are still important / relevant.
Hi,
- Original Message
From: DM Smith <[EMAIL PROTECTED]>
On Jun 21, 2006, at 7:52 AM, Grant Ingersoll wrote:
> This sounds reasonable to me...
OG: It sounded reasonable to me, too. I don't quite understand why that's SO
hard to accept. Btw., I run Lucene 1.4.3 on Java 1.4.2 as well
Chris,
Judging from a cursory look at LUCENE-406, that should be in the core (my
reasoning was: well, if it's simply the direct opposite of what's already in
the core, it makes sense to sit right next to its opposite in the core with the
"opposite name", or else who'll think to look in contrib,
Hello,
I am new to lucene index api. Please help me with the following:
* Lucene search is returning documents. Is there an api that I use to
search content inside a document to return only the line that match the
search query?
Sincerely,
Anh Ngo
-Original Message-
From: Chuck W
On 6/21/06, Robert Engels <[EMAIL PROTECTED]> wrote:
It sounds like you did something ill-advised. Why change your code to 1.5if
a significant portion of your users can run it, and the previous release
was
not essentially bug free (if it was, your users would not have seen any
difference).
It
On 6/21/06, Michael McCandless <[EMAIL PROTECTED]> wrote:
Does anyone know of any reasons not to switch Lucene's FSDirectory locking
to the java.nio.channels.FileLock? EG, are there any performance issues
that people are aware of? It's available since Java 1.4.
Good question Michael, no reaso
Otis,
I should have taken a closer look before I made my comment. I have just now.
So never mind.
DM
On 6/21/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
Chris,
Judging from a cursory look at LUCENE-406, that should be in the core (my
reasoning was: well, if it's simply the direct opposite
Hi,
I have just tried to compile lucene with ecj, Eclipse's compiler, and it
complains of errors with BooleanScorer2. The problematic construction is
present 2x in the class:
if (doc() > lastScoredDoc) {
lastScoredDoc = doc();
coordinator.nrMatchers += super.nrMatchers;
LUCENE-545 that was recently committed breaks backward compatibility with
Document.getField(), a non-expert level API that is *very* widely used.
Something simple like
Field x = mydoc.getField("x");
no longer compiles (and neither do other methods with Field in the signature).
Is this intentio
: Not sure what the solution should be:
I haven't looed at the code so i'm not sure ... but my first thought would
be to try both this.doc() and BooleanScorer2.this.doc(), and see which one
passes all the unit tests. Of course, if both of them pass the unit
tests, then I'd be *really* worried.
Looking at the changes a little more, it looks like the following
Document methods should be reverted:
public final Fieldable[] getFields(String name)
and
public final Fieldable getField(String name)
That should preserve compatibility with older applications.
The only danger is that a cast to
: Is this intentional?
: If not, uses of "Field" in unit tests should not have been changed to
Fieldable.
If it was intentional, then at a minimum it should be documented as an
API Change (and not just a new feature).
-Hoss
-
On 6/21/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
Hi,
- Original Message
From: DM Smith <[EMAIL PROTECTED]>
On Jun 21, 2006, at 7:52 AM, Grant Ingersoll wrote:
> This sounds reasonable to me...
OG: It sounded reasonable to me, too. I don't quite understand why that's
SO hard
Lazy field loading breaks backward compat
-
Key: LUCENE-609
URL: http://issues.apache.org/jira/browse/LUCENE-609
Project: Lucene - Java
Type: Bug
Components: Other
Versions: 2.0.1
Reporter: Yonik Seeley
Fi
[
http://issues.apache.org/jira/browse/LUCENE-609?page=comments#action_12417158 ]
Yonik Seeley commented on LUCENE-609:
-
I'll work up a quick patch to revert those APIs and add new ones for Fieldable.
> Lazy field loading breaks backward compat
> --
I can help if you need it.
Yonik Seeley (JIRA) wrote:
[ http://issues.apache.org/jira/browse/LUCENE-609?page=comments#action_12417158 ]
Yonik Seeley commented on LUCENE-609:
-
I'll work up a quick patch to revert those APIs and add new ones for Fieldabl
[ http://issues.apache.org/jira/browse/LUCENE-609?page=all ]
Yonik Seeley updated LUCENE-609:
Attachment: fieldable_patch.diff
OK, here's the quick'n'dirty version that passes lucene unit tests.
- The new getFieldable methods can be considered temporar
No, this is my mistake. I should have deprecated and added new methods
that returned the Fieldable.
The cast is only going to be safe when using non lazy field loading,
which is the standard before this anyway.
Chris Hostetter wrote:
: Is this intentional?
: If not, uses of "Field" in uni
[
http://issues.apache.org/jira/browse/LUCENE-609?page=comments#action_12417164 ]
Yonik Seeley commented on LUCENE-609:
-
I just verified that Solr now compiles/works correctly again with this patch.
Any objections to committing it?
> Lazy field loading
[
http://issues.apache.org/jira/browse/LUCENE-609?page=comments#action_12417166 ]
Grant Ingersoll commented on LUCENE-609:
I think there is a typo of getFielables on Document.java, other than that looks
good.
> Lazy field loading breaks backward co
Maybe I am missing something...
Would it not be easier to just create a LazyDocument that extends Document,
and handles all of this transparently? It would also require no changes to
existing code.
The code that currently returns a Document, can just return a LazyDocument
(if lazy/selective loadi
[ http://issues.apache.org/jira/browse/LUCENE-609?page=all ]
Yonik Seeley resolved LUCENE-609:
-
Resolution: Fixed
Assign To: Yonik Seeley
Committed (with typo fixes :-)
The main point for me was to return backward compatibility of getField(s)
I am not sure I see why it would require no changes? You would have to
have some way to tell the FieldsReader you wanted a LazyDocument instead
of a regular Document. Also, the desire was to have the ability to have
some fields load as they do now while others are loaded when accessed.
Robe
I was thinking of a default value, probably by Searcher, that is 'use lazy
loading'.
For query specific "which fields to load", you are correct, there is no REAL
choice but add new code, but I would think you would pass a list of field
ids to the searcher that you wanted early loaded. But this cou
: Would it not be easier to just create a LazyDocument that extends Document,
: and handles all of this transparently? It would also require no changes to
: existing code.
:
: The code that currently returns a Document, can just return a LazyDocument
: (if lazy/selective loading is enabled).
assu
On 6/21/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: Not sure what the solution should be:
I haven't looed at the code so i'm not sure ... but my first thought would
be to try both this.doc() and BooleanScorer2.this.doc(), and see which one
passes all the unit tests. Of course, if both of
: > I haven't looed at the code so i'm not sure ... but my first thought would
: > be to try both this.doc() and BooleanScorer2.this.doc(), and see which one
: > passes all the unit tests. Of course, if both of them pass the unit
: > tests, then I'd be *really* worried.
: Start worrying!
: this.
On 6/21/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
LazyField doesn't extend Field.
Yeah, that's the crux of the matter.
I assume this is the case because people need to instantiate Field to
add it to a Document at index time, and I guess there is some FIeld
baggage that LazyField didn't wa
I was assuming it would be changed so that LazyField extended Field.
Is this not a better approach?
Fieldable sounds poor to me - implies an object can be a Field.
If we are only working with fields, why not just extend Field, and remove
Fieldable?
-Original Message-
From: Chris Hostett
I understand that by having LazyField extend Field it would probably
override all methods, but it still seems cleaner given the existing code
base. LazyField would only need a package level ctor.
-Original Message-
From: Yonik Seeley [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 21, 200
BooleanScorer2 does not compile with ecj
Key: LUCENE-610
URL: http://issues.apache.org/jira/browse/LUCENE-610
Project: Lucene - Java
Type: Bug
Components: Search
Versions: 2.0.0
Environment: Eclipse 3.1.2, Fedora
On 6/21/06, DM Smith <[EMAIL PROTECTED]> wrote:
On 6/21/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
>
>
> : Not sure what the solution should be:
>
> I haven't looed at the code so i'm not sure ... but my first thought would
> be to try both this.doc() and BooleanScorer2.this.doc(), and see wh
: I was assuming it would be changed so that LazyField extended Field.
in which case we wouldn't really need a LazyDocument class .. Document
could be used (and could contain LazyField's directly)
I don't know why LazyField doesn't subclass Field ... but i assume there's
a good reason (becuaes i
On 6/21/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: > I haven't looed at the code so i'm not sure ... but my first thought
would
: > be to try both this.doc() and BooleanScorer2.this.doc(), and see which
one
: > passes all the unit tests. Of course, if both of them pass the unit
: > tests
[
http://issues.apache.org/jira/browse/LUCENE-610?page=comments#action_12417186 ]
DM Smith commented on LUCENE-610:
-
I did a bit further testing. The current behavior under Java 5 is to call
this.doc();
> BooleanScorer2 does not compile with ecj
> ---
[
http://issues.apache.org/jira/browse/LUCENE-609?page=comments#action_12417188 ]
Chuck Williams commented on LUCENE-609:
---
I'm late to the discussion and have only read the patch file, but it seems
invalid to me. Won't getField() get a class cast exc
[ http://issues.apache.org/jira/browse/LUCENE-610?page=all ]
Yonik Seeley resolved LUCENE-610:
-
Fix Version: 2.0.1
Resolution: Fixed
Assign To: Yonik Seeley
Changes commited
doc() => this.doc()
Thanks for investigating this.
> BooleanSco
[
http://issues.apache.org/jira/browse/LUCENE-609?page=comments#action_12417193 ]
Yonik Seeley commented on LUCENE-609:
-
> I'm late to the discussion
Yes, I didn't leave much time for debate :-) I really wanted to get back to
something backward compati
[ http://issues.apache.org/jira/browse/LUCENE-451?page=all ]
Hoss Man updated LUCENE-451:
Attachment: bq.containing.clause.with.zero.boost.tests.patch
slight bug in test2 - the old method of checking the results using Hits had a
differnet set of matching do
[ http://issues.apache.org/jira/browse/LUCENE-605?page=all ]
Hoss Man updated LUCENE-605:
Attachment: LUCENE-605-fix-with-subclassing.patch
I should have just kept on working on this last night .. it only took about 20
minutes to make the remaining changes
[ http://issues.apache.org/jira/browse/LUCENE-569?page=all ]
paul.elschot updated LUCENE-569:
Attachment: common-build.assertions.patch
NearSpansOrdered.java
common-build.assertions.patch enables assertions in org.apache.lucene during
th
[ http://issues.apache.org/jira/browse/LUCENE-569?page=all ]
paul.elschot updated LUCENE-569:
Attachment: (was: NearSpansOrdered.java)
> NearSpans skipTo bug
>
>
> Key: LUCENE-569
> URL: http://issues.apache.org
51 matches
Mail list logo
