Where do we stand with this?
I want to push to a 3.0.3 release, what items are still pending?
Itamar.
This is a proposed change
I got really tired of writing unnecessary code all the time
when opening FSDirectory
-- Forwarded message --
From:
Date: Thu, Jun 14, 2012 at 1:19 PM
Subject: svn commit: r1350178 - /incubator/
lucene.net/trunk/src/core/Store/FSDirectory.cs
To: lucene-ne
On 2012-06-14, wrote:
>> /// Currently this returns
>> as
>> /// NIOFSDirectory is currently not supported.
>> ///
>> /// NOTE: this method may suddenly change which
>> /// implementation is returned from release to release, in
>>
I'd assume so, at least partially
I just copy-pasted from one method below
On Thu, Jun 14, 2012 at 2:52 PM, Stefan Bodewig wrote:
> On 2012-06-14, wrote:
>
> >> /// Currently this returns cref="SimpleFSDirectory" /> as
> >> /// NIOFSDirectory is currently not support
Agreed -
JIRA for 3.0.3
https://issues.apache.org/jira/browse/LUCENENET/fixforversion/12316215#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel
We should evaluate all of these - fix them, mark as won't fix, or move them to
another release version. I think the biggest h
I think with the addition of two new committers we've made some progress in
community growth. I think we'll have 3.0.3 out the door soon - are there any
other items we think we need to address before looking to graduate?
~P
IMHO, whatever brings more attention to the project, and I'm not sure
graduation is what this project needs right now. In the end it's just
semantics.
I'd focus those efforts on getting more work done and having more frequent
releases. Hence our proposition to sponsor dev, which still stands.
On
Ok, and is the code in 100% compliance with the 3.0.3 Java code?
I'll be spending some time on fixing the index corruption issue, and it is
probably best for Chris to wrap up the work he has started
Anyone else on board to close some tickets?
On Thu, Jun 14, 2012 at 6:19 PM, Prescott Nasser wrot
I'm going to try and review some of them - looking at the 3.5 ticket atm. The
code should be in compliance with 3.0.3. We might want to do some spot checking
various parts of the code. I'm not sure about the tests. Also, we should
probably run some code coverage tools to see how much coverage w
As a mentor, it's my job argue with Itamar a bit. It's not just
semantics. We don't incubate projects indefinitely. I think that you
all are good to go. The transition is not very much work. Please do
draft a resolution and conduct a vote in the community, and we can
then take it to the incubator P
[
https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295135#comment-13295135
]
Prescott Nasser commented on LUCENENET-480:
---
Attempting to compile the trunk
That comment is correct. We don't have support for NIOFSDirectory in .NET
(and the JVM support for it in windows has a major bug). We also don't
support MMapDirectory, because we haven't bothered to support it yet. I
think digy ported it once, but it didn't add any speed benefits, and was
actual
Well, the only thing I see is that there is no place where writer.Commit()
is called in the delegate assigned to corpusReader.OnDocument. I know that
lucene is very transactional, and at least in 3.x, the writer will never
auto commit to the index. You can write millions of documents, but if
comm
I've gone back and forth on whether I think we're ready for graduation or
not. I had always felt like we weren't because the project isn't as active
as I'd like it to be. However, I think I've been looking at it wrong.
We've got a good enough process and we *have* made progress. If anything,
gr
I'm quite certain this shouldn't happen also when Commit wasn't called.
Mike, can you comment on that?
On Thu, Jun 14, 2012 at 8:03 PM, Christopher Currens <
currens.ch...@gmail.com> wrote:
> Well, the only thing I see is that there is no place where writer.Commit()
> is called in the delegate a
I've been thinking about LUCENENET-493 (Make Lucene.Net culture
insensitive). It's easy to fix the code, and verify it on my machine
(running CurrentCulture=sv-SE), but there are no tests to confirm the
changes. I've been looking for ways to build test cases for different
cultures, like the ove
I can't guarantee that the code is 100% in compliance with java 3.0.3. All
changes that could be ported have been ported in core and most contrib
projects. There are a few things that should at least be discussed
regarding the compatibility in core:
Occur (BooleanClause) in java is converted to
Something like:
Thread.CurrentThread.CurrentCulture = cultureInfo;
Thread.CurrentThread.CurrentUICulture = cultureInfo;
And setting it back later when the test is done.
You can easily do this with an IDisposable like this:
using(new TemporaryCulture(culture)){
...
}
On Thu, Jun 14, 2012 at 9:1
Sorry, misread your question
This can be easily done with xUnit, using Theories.
On Thu, Jun 14, 2012 at 9:26 PM, Itamar Syn-Hershko wrote:
> Something like:
>
> Thread.CurrentThread.CurrentCulture = cultureInfo;
> Thread.CurrentThread.CurrentUICulture = cultureInfo;
>
> And setting it back late
I don't have any ideas for this, but I looked around at them myself.
You'll notice in TestQueryParser.cs, it inherits from LocalizedTestCase,
which is good. It means that we should be able to identify fairly easily
which unit tests should be localized. However, there is no automated way
to do th
[
https://issues.apache.org/jira/browse/LUCENENET-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295213#comment-13295213
]
Simon Svensson commented on LUCENENET-490:
--
I've commited changes to QueryPars
[
https://issues.apache.org/jira/browse/LUCENENET-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Currens resolved LUCENENET-490.
---
Resolution: Fixed
That is how it used to be. I believe I caused this regr
[
https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295239#comment-13295239
]
Christopher Currens commented on LUCENENET-480:
---
I'm assuming we're going
I think it depends on how we decided to implement the enumerable. Are we
going to implement it on the IndexReader or on a TermEnum (makes more sense
this way)? In that case, I would imagine it would look something like this:
// Used to wrap the actual results of a TermEnum, which includes a Term
+1 on the string vs DirectoryInfo overload, Iatmar
Re: Comments and JVM, I'd suggest editing the .NET comments to remove
Java specific recommendations/concerns. We're not running on the JVM,
so consumes of our code don't need that info.
Re: GC pressure on the File/DirectoryInfo objects.. There's
I'd say we're ready for graduation. Since I'm not really involved in
the coding effort at the moment, I'll work with Prescott on this
process.
The only reservation I have about graduation is losing or lessening
Stefan Bodewig's involvement. He's been really helpful. Can we keep
all of our mentors
> If this is the case, 2328 probably made it's way to Lucene.Net since we are
> using the released sources for porting, and we now need to apply 3418 in
> the current version.
Iatmar: I confirmed that 2328 is in the latest code.
Thanks,
Troy
On Wed, Jun 13, 2012 at 5:45 PM, Itamar Syn-Hershko
I want to clarify that graduation is a somewhat gradual process, and
the early parts are not much work. You create a resolution for the
board that would establish your project. You conduct a community vote.
We conduct an IPMC vote. At the next board meeting, which could then
be as much as 30 days l
They're used more than it looks like they are. One of the largest ways
they're used in the Store namespace is *to create FileStream
objects*...which is such a waste of an allocation. A small test program I
wrote created ~1000 FileInfo objects every minute, most of that thanks to
merging. Conside
Well, yeah, that's a lot more than I realized.. My assumption was that
there wouldn't be more FileInfo objects created than there were files
created, which is not that many. Whatever is doing that should be
re-written to pass the obj vs recreating it.
-T
On Thu, Jun 14, 2012 at 3:57 PM, Christoph
[
https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295406#comment-13295406
]
Prescott Nasser commented on LUCENENET-480:
---
Yes I think we should do this vi
I can confirm 2.9.4 had autoCommit, but it is gone in 3.0.3 already, so
Lucene.Net doesn't have autoCommit.
So I don't have autoCommit set to true, but I can clearly see a segments_1
file there along with the other files. If that helpes, it always keeps with
the name segments_1 with 32 bytes, neve
32 matches
Mail list logo
