DateField bug in 1.9 RC1 build 4
Key: LUCENENET-6
URL: http://issues.apache.org/jira/browse/LUCENENET-6
Project: Lucene.NET
Type: Bug
Environment: Windows Server 2003 on Vmware, .NET 2.0.50727
Reporter: AqD
Lucene.Net
thread local storage bug in 1.9 RC1 build 4
---
Key: LUCENENET-7
URL: http://issues.apache.org/jira/browse/LUCENENET-7
Project: Lucene.NET
Type: Bug
Environment: Windows Server 2003 on VMware, .NET 2.0.50727
Reporter
I just updated this. Thanks for catching it.
Doug
Chris Hostetter wrote:
Someone with the neccessary permisions to update the javadocs on the
website might want to do so, they currently say "Lucene 1.9-rc1 API" which
might confuse people (even if the API is exactly the same as 1.
Someone with the neccessary permisions to update the javadocs on the
website might want to do so, they currently say "Lucene 1.9-rc1 API" which
might confuse people (even if the API is exactly the same as 1.9.1)
http://lucene.apache.org/java/docs/api
Filed the bug, https://issues.apache.org/jira/browse/LUCENE-511 .
Also added the simple fix, it seems to work, and I think the rest of
the method is ok.
Shay
On 2 Mar 2006, at 19:19, Doug Cutting wrote:
Shay Banon wrote:
...
} else {
// is data larger then buffer?
if (le
Steven Tamm wrote:
We just discovered this problem as well. Here's a test case that fails
without the fix.
Can you please attach this patch file to:
http://issues.apache.org/jira/browse/LUCENE-511
Thanks,
Doug
-
To unsubsc
void testLargeWrites() throws IOException {
+IndexOutput os = dir.createOutput("testBufferStart.txt");
+
+byte[] largeBuf = new byte[2048];
+for (int i=0; imailto:[EMAIL PROTECTED]
Sent: Thursday, March 02, 2006 11:20 AM
To: java-dev@lucene.apache.org
Subject: Re
Shay Banon wrote:
...
} else {
// is data larger then buffer?
if (length > BUFFER_SIZE) {
// we flush the buffer
if (bufferPosition > 0)
flush();
// and write data at once
flushBuffer(b, length);
} else {
...
the bufferStart is not
Hi,
I have just updated to lucene 1.9, and hit a problem with the
mentioned optimization. I have applied it to the my
JdbcBufferedOutput (I only duplicate the code because the BUFFER_SIZE
is final), and I hit a problem. In the following code fragment (the
method is writeBytes):
...
Erik Hatcher wrote:
On Feb 25, 2006, at 3:24 PM, Daniel Naber wrote:
On Freitag 24 Februar 2006 00:50, Doug Cutting wrote:
Are these all modules that don't need external libs?
So far as I know!
I found another module that requires external libraries: regex. These
are
even defined in th
On Feb 26, 2006, at 7:18 AM, Daniel Naber wrote:
On Sonntag 26 Februar 2006 02:42, Erik Hatcher wrote:
I personally don't think we should be distributing any external
dependencies. Whoever builds the releases needs to have the
dependencies locally, but 3rd party JARs, even Apache ones, should
On Sonntag 26 Februar 2006 02:42, Erik Hatcher wrote:
> I personally don't think we should be distributing any external
> dependencies. Whoever builds the releases needs to have the
> dependencies locally, but 3rd party JARs, even Apache ones, should
> not go along for the .tar/zip ride IMO
On Feb 25, 2006, at 3:24 PM, Daniel Naber wrote:
On Freitag 24 Februar 2006 00:50, Doug Cutting wrote:
Are these all modules that don't need external libs?
So far as I know!
I found another module that requires external libraries: regex.
These are
even defined in the additional.dependenc
Thanks Paul, it's in.
Otis
- Original Message
From: Paul Elschot <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Saturday, February 25, 2006 7:09:25 AM
Subject: Re: Lucene 1.9 RC1 release available: surround package.html files
On Saturday 25 February 2006 01:23, Chri
On Freitag 24 Februar 2006 00:50, Doug Cutting wrote:
> > Are these all modules that don't need external libs?
>
> So far as I know!
I found another module that requires external libraries: regex. These are
even defined in the additional.dependencies property in the build.xml, but
it seems it's
On Saturday 25 February 2006 01:23, Chris Hostetter wrote:
>
...
>
> ...Which means this weekend would be a good time for contrib module owners
> to commit a quick one sentence "package.html" for each package in their
> module. Now that the contrib classes are built/bundled/distributed along
> w
: FYI, I think all of the commits to trunk since the RC1 release are safe
: to merge to the 1.9 branch. They're mostly documentation improvements.
: So my plan is currently, on Monday, to merge these changes to the 1.9
: branch, then make a 1.9-final release. I'll again announce it to the
...
On Freitag 24 Februar 2006 00:50, Doug Cutting wrote:
> > Are these all modules that don't need external libs?
>
> So far as I know! They built without me downloading anything extra.
Lucli requires jline.jar which is also in SVN and can be distributed thanks
to its very liberal license (jline.L
On Feb 23, 2006, at 6:33 PM, Daniel Naber wrote:
BTW, lucli (the command line lucene searcher) builds fine, but the
manifest
in the jar doesn't specify the Main-Class so you cannot start it with
java's -jar option. Could someone have a look at this (Erik?)? I don't
understand how that ant task
Daniel Naber wrote:
Are these all modules that don't need external libs?
So far as I know! They built without me downloading anything extra.
FYI, I think all of the commits to trunk since the RC1 release are safe
to merge to the 1.9 branch. They're mostly documentation improvements.
So my
On Freitag 24 Februar 2006 00:33, Daniel Naber wrote:
> Shouldn't we include at least some package from contrib, like analyzers
> and highlighter?
Sorry, I totally missed the "contrib" sub directory that contains
everything I'm asking for... Are these all modules that don't need
external libs?
On Dienstag 21 Februar 2006 18:50, Doug Cutting wrote:
> I will send this announcement to user list tomorrow if no major issues
> are identified. If things still look good next week, I will promote
> this release to 1.9-final.
Shouldn't we include at least some package from contrib, like analyze
Arguing about this won't change the code. A well-constructed patch
might (but there are no guarantees).
To me, this sounds like an uphill battle. If we want to add a feature
to wildcard 0-N characters at the end of a word, then I don't think we'd
use '?' plus a flag. Rather I think it would
Grant Ingersoll wrote:
I am wondering what the motivation is for being forward compatible to
2.0. Is the only change from 1.9 to 2.0 going to be the removal of
deprecated items?
Pretty much, yes.
Are we going to be preventing ourselves from making
broader structural changes? My understand
Doug Cutting wrote:
1.9 will be the last 1.x release. It is both back-compatible with
1.4.3 and forward-compatible with the upcoming 2.0 release. Many
methods and classes in 1.4.3 have been deprecated in 1.9 and will be
removed in 2.0. Applications must compile against 1.9 without
deprecati
1) Having a simple way to match singular and plural forms of a term with
a single wildcard expression is quite useful.
2) The trailing '?' behavior has been present since that wildcard was
first introduced. Why not provide a flag to allow the original behavior
to optionally be preserved?
3) The
: In either case, what I'm arguing is that the current behavior makes more
: sense in the real world of query expressions (that is, makes the most
: common query expressions simpler), so why not continue it?
I disagree with that statment. People familiar with shell globing are
going to be confus
Hoss,
Whether the previous behavior (which I believe has been present in
Lucene from the outset) was a "bug" or a "feature" is kind of academic.
My point is that this behavior has value that's not countered by any
argument that any significant value is added by eliminating it.
As to your ri
Marvin,
While a stemming analyzer can work well for general purpose queries, if
you're seeking a decent level of precision/recall, stemming often
severely limits you. Moreover, unless the user is very familiar with
the behavior of the stemmer used, some of the returned results can be
quite s
: of query). Under the previous versions of QueryParser, I could simply
: specify 'riot???' and capture all of those variants.
I don't have a strong opinion on this issue, but it seems clear to me that
this was a bug in 1.4.3 not a change in the orriginally intended behavior.
queryparsersyntax.h
Terry,
Is there a reason you wouldn't use a stemming analyzer of some kind,
which would match cat and cats but not cater, catches, etc?
http://snowball.tartarus.org/demo.php
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
On Feb 21, 2006, at 3:13 PM, Terry Steichen wrote:
Terry,
I think most of the examples you provide are normally handled via stemming.
Using wildcarding for stemming will normally be less accurate.
The current behavior is also consistent with the way file globbing works.
-Yonik
On 2/21/06, Terry Steichen <[EMAIL PROTECTED]> wrote:
> Yonik,
>
>
Yonik,
No, I don't think that the riot* option would work for many queries.
Let's take a simple case where you want a singular or plural form, like
either cat or cats (which would be very common). With 1.4.x, you can
use cat? to retrieve such matches. With the new change, you need to use
(
On 2/21/06, Terry Steichen <[EMAIL PROTECTED]> wrote:
> For example, let's say that I'm interested in docs with terms 'riot',
> 'riots', 'rioting' and 'rioters' (which, I think, is a reasonable kind
> of query). Under the previous versions of QueryParser, I could simply
> specify 'riot???' and cap
In reviewing the latest changes incorporated into release 1.9 RC1, I
noticed a change responding to JIRA item LUCENE-306. According to the
writeup, the new change forces the wildcard pattern 'cat??' to exactly
match the length of the term (in this case, a five-letter term starting
Doug Cutting wrote:
Release 1.9 RC1 of Lucene is now available from:
http://www.apache.org/dyn/closer.cgi/lucene/java/
I will send this announcement to user list tomorrow if no major issues
are identified. If things still look good next week, I will promote
this release to 1.9-final. Once
Maxim Patramanskij wrote:
Doug,
what about including optimization of BuffereIndexOutput.writeBytes()
method:
[ http://issues.apache.org/jira/browse/LUCENE-435?page=all ]
made by Lukas Zapletal, into 1.9?
I just committed this to trunk. If no issues arise with it there then
perhaps we can
Chris Hostetter wrote:
I think moving forward the query parser and fileformat docs should be
moved into docfile directories within the java source, so they are
reved/tagged with the individual releases. That way when people have
questions about the file format of their index built with 1.9 they
Release 1.9 RC1 of Lucene is now available from:
http://www.apache.org/dyn/closer.cgi/lucene/java/
This release candidate has many improvements since release 1.4.3,
including new features, performance improvements, bug fixes, etc. For
details, see:
http://svn.apache.org/viewcvs.cgi
--- Nadav Har'El <[EMAIL PROTECTED]> wrote:
> Dan Armbrust <[EMAIL PROTECTED]> wrote
> on 17/02/2006 08:50:53
> PM:
...
> So I'm not sure the solution is to change the
> semantics of the existing
> constructor, but I think Lucene definitely need a
> new constructor or
> convenience
> function that
Dan Armbrust <[EMAIL PROTECTED]> wrote on 17/02/2006 08:50:53
PM:
>...
> Short summary - The Constructor for IndexWriter currently will only
> create an index in a folder if you set the boolean create flag to true.
> But then, if you want to append to that index, you have to set the
> create flag
I'd like to see this improvement request implemented - but I'm not sure
if 1.9 or 2.0 would be a better place to do it:
http://issues.apache.org/jira/browse/LUCENE-301
Short summary - The Constructor for IndexWriter currently will only
create an index in a folder if you set the boolean create
Maxim - vote for it. Not guaranteed to get tihngs in, but votes helps us see
what people need/want/like.
Otis
- Original Message
From: Maxim Patramanskij <[EMAIL PROTECTED]>
To: Doug Cutting
Sent: Wednesday, February 15, 2006 7:25:52 AM
Subject: Re: 1.9 RC1
Doug,
what
This week is pretty booked for me, so, barring major objections, I will
make a 1.9 RC1 release next Monday, February 20th. If there are no
problems discovered, I'll aim to make a 1.9 final release a week later,
around the 27th.
Has anyone tested if 1.9 can build with a Free Sof
DM Smith wrote:
Would that mean that 1.9 and 2.0 will be released at the same time?
No. 2.0 will be released after 1.9. The primary change will be that
all deprecated methods are removed, but there may be other changes, but
probably not many.
Doug
Erik Hatcher wrote:
On Feb 15, 2006, at 9:11 AM, DM Smith wrote:
Not to get to far ahead, but what is the schedule relation between
1.9 and 2.0?
What are the dependencies on releasing 2.0?
My understanding is that 2.0 will be 1.9 with all the deprecated API
removed. Maybe there are other fe
On Feb 15, 2006, at 9:11 AM, DM Smith wrote:
Not to get to far ahead, but what is the schedule relation between
1.9 and 2.0?
What are the dependencies on releasing 2.0?
My understanding is that 2.0 will be 1.9 with all the deprecated API
removed. Maybe there are other features planned?
Not to get to far ahead, but what is the schedule relation between 1.9
and 2.0?
What are the dependencies on releasing 2.0?
Doug Cutting wrote:
I'd like to push out a 1.9 release candidate in the next week or so.
Are there any patches folks are really hoping to sneak into 1.9? If
so, now's th
Doug,
what about including optimization of BuffereIndexOutput.writeBytes()
method:
[ http://issues.apache.org/jira/browse/LUCENE-435?page=all ]
made by Lukas Zapletal, into 1.9?
I'm wondering, because this can decrease index creation time, which I
discovered as critical when using Lucene toget
I've been away from constant e-mail for several days (nice while it
lasted, but rough to come back to!)...
I'm +1 for 1.9 RC1, just for the record. As for the copyright years
- those should reflect only the years those files were touched, at
least that is how it is carefully don
is pretty booked for me, so, barring major objections, I will
make a 1.9 RC1 release next Monday, February 20th. If there are no
problems discovered, I'll aim to make a 1.9 final release a week later,
around the 27th.
Doug
--
: I'd like to push out a 1.9 release candidate in the next week or so.
I'm not sure what the ASF/Lucene policy is on keeping Copyright/License
statements in source files up to date, but should they all be updated to
say "Copyright 2006 The Apache Software Foundation" prior to a 1.9
release?
I've
: This is a great time to improve the javadoc. I see lots of blank boxes
: which could use a bit of descriptive text, for example:
That reminds me about a documentation/release issue that's been rolling
arround in the back of my mind that seems like it's only going to get
worse as future release
Doug Cutting wrote:
I'd like to push out a 1.9 release candidate in the next week or so. Are
there any patches folks are really hoping to sneak into 1.9? If so,
now's the time.
This is a great time to improve the javadoc. I see lots of blank boxes
which could use a bit of descriptive text,
I'd like to push out a 1.9 release candidate in the next week or so.
Are there any patches folks are really hoping to sneak into 1.9? If so,
now's the time.
Doug
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional comm
55 matches
Mail list logo
