Re: [Lucene.Net] 2.9.4 release couldn't be compiled for .Net3.5
Hi Alexey, I believe this version of Lucene.Net will be the last version that can be compiled with the .NET 2.0 runtime which is what .NET 3.5 runs on. There was a vote on supported runtime versions by the community this past year, The community widely supported to drop .NET 2.0 runtime after the 2.9.4 release in favor of the .NET 4.0 runtime. I also believe most of the committers will be focused on using generics with the next version and possibly .NET 4.0 specific code. However, since the code is open source, anyone can contribute branches that can be compiled on the .NET 2.0 runtime. There is plenty of work and only a handful of committers with a limited amount of time to work on the project and there is a need for a narrow focus from the committers in order to move the project forward with releases. But we're more than open to discussing what it would take to accomplish something like that if it has enough support from the community if that is something that interests you or anyone else reading this thread. If you search the mailing list, DIGY has some instructions on how to compile the 2.9.4 tag in a way that is compatible with .NET 2.0. If I stumble across it or someone else knows the steps, it will re-posted in this thread. But it does have to do with commenting out the ThreadLocal and uncommenting out another portion of the code. - Michael On Tue, Dec 6, 2011 at 7:42 AM, Alexey Shcherbachev ale...@renaissance-it.ru wrote: Hi, First of all thank you for the new release 2.9.4. That makes me really happy. However, I noted that current binaries are build for .Net 4.0 framework only, which is very inconvenient. The reason is we have a hard requirement to use .Net3.5sp1. We were going to build it manually as usual, but stumbled upon .Net 4.0 specific code (file CloseableThreadLocal.cs): private ThreadLocalWeakReference t = new ThreadLocalWeakReference(); For now we just replaced CloseableThreadLocal file with a version from 2.9.2, but still. What is an official strategy of the Lucene.Net team about framework versions? Is there a chance that Lucene.Net will be released in future not only for 4.0, but for 3.5 too? Kind Regards, Alexey Shcherbachev Rebel Search team Skype: Leha-2304 Web: http://rebelsearch.net/
RE: [Lucene.Net] 2.9.4 release couldn't be compiled for .Net3.5
From digy: OK, here is the code that can be compiled against .NET 2.0 http://pastebin.com/k2f7JfPd FYI, we believe there may be a memory leak related to this code ( not in this particular code though ) Sent from my Windows Phone From: Michael Herndon Sent: 12/6/2011 5:42 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 release couldn't be compiled for .Net3.5 Hi Alexey, I believe this version of Lucene.Net will be the last version that can be compiled with the .NET 2.0 runtime which is what .NET 3.5 runs on. There was a vote on supported runtime versions by the community this past year, The community widely supported to drop .NET 2.0 runtime after the 2.9.4 release in favor of the .NET 4.0 runtime. I also believe most of the committers will be focused on using generics with the next version and possibly .NET 4.0 specific code. However, since the code is open source, anyone can contribute branches that can be compiled on the .NET 2.0 runtime. There is plenty of work and only a handful of committers with a limited amount of time to work on the project and there is a need for a narrow focus from the committers in order to move the project forward with releases. But we're more than open to discussing what it would take to accomplish something like that if it has enough support from the community if that is something that interests you or anyone else reading this thread. If you search the mailing list, DIGY has some instructions on how to compile the 2.9.4 tag in a way that is compatible with .NET 2.0. If I stumble across it or someone else knows the steps, it will re-posted in this thread. But it does have to do with commenting out the ThreadLocal and uncommenting out another portion of the code. - Michael On Tue, Dec 6, 2011 at 7:42 AM, Alexey Shcherbachev ale...@renaissance-it.ru wrote: Hi, First of all thank you for the new release 2.9.4. That makes me really happy. However, I noted that current binaries are build for .Net 4.0 framework only, which is very inconvenient. The reason is we have a hard requirement to use .Net3.5sp1. We were going to build it manually as usual, but stumbled upon .Net 4.0 specific code (file CloseableThreadLocal.cs): private ThreadLocalWeakReference t = new ThreadLocalWeakReference(); For now we just replaced CloseableThreadLocal file with a version from 2.9.2, but still. What is an official strategy of the Lucene.Net team about framework versions? Is there a chance that Lucene.Net will be released in future not only for 4.0, but for 3.5 too? Kind Regards, Alexey Shcherbachev Rebel Search team Skype: Leha-2304 Web: http://rebelsearch.net/
Re: [Lucene.Net] 2.9.4 is a go for release
On 2011-11-29, Prescott Nasser wrote: 1. Move the artifacts to the distribution place (not sure where or how yet) /www/www.apache.org/dist/incubator/lucene.net/ make sure all files and directories are owned by the group incubator and group writable. If you create new directories, set the sticky bit (chmod 2775 dirname). 3. Update the website It may take up to an hour before the release is visible on the public www.apache.org and several hours until all mirrors have picked up the new files. OTOH the website update will be immediate, so you better hold back that part. Stefan
Re: [Lucene.Net] 2.9.4 RC1
Any chance you guys fix and merge this https://issues.apache.org/jira/browse/LUCENENET-450 before releasing? On Sun, Oct 30, 2011 at 11:12 PM, Prescott Nasser geobmx...@hotmail.comwrote: Alright- this took me way too long, I'm sorry for that. Could you guys please take a look at: http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/hopefully I've done this right, once you guys think it looks good, I'd like to call a vote to release this ~Prescott
RE: [Lucene.Net] 2.9.4 RC1
Done - i've uploaded the new files to the same place. I actually found an issue with the bin.zip file, so it was good that I merged that bug fix in. If you guys don't mind taking a look, I'd like to submit it to the incubator mailing list for a vote tomorrow if we have no issues with these ~Prescott Date: Mon, 31 Oct 2011 01:14:52 +0200 From: ita...@code972.com To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 RC1 Any chance you guys fix and merge this https://issues.apache.org/jira/browse/LUCENENET-450 before releasing? On Sun, Oct 30, 2011 at 11:12 PM, Prescott Nasser geobmx...@hotmail.comwrote: Alright- this took me way too long, I'm sorry for that. Could you guys please take a look at: http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/hopefully I've done this right, once you guys think it looks good, I'd like to call a vote to release this ~Prescott
Re: [Lucene.Net] 2.9.4 RC1
Hi Prescott, thank you for pushing things forward. On 2011-10-31, Prescott Nasser wrote: Done - i've uploaded the new files to the same place. I actually found an issue with the bin.zip file, so it was good that I merged that bug fix in. I'm pretty sure you know that, but if you decide to do something like this after you've started the vote, please cancel the vote, bump the RC number and start a new vote. If you guys don't mind taking a look, I'd like to submit it to the incubator mailing list for a vote tomorrow if we have no issues with these Start a VOTE thread on this list and if it passes go to the general list. If all mentors vote on this list the VOTE on the general list is more informational than anything else. I'll look into the ZIPs myself in a few hours so you'll know how I'm going to vote 8-) Stefan
RE: [Lucene.Net] 2.9.4 RC1
Done - i've uploaded the new files to the same place. I actually found an issue with the bin.zip file, so it was good that I merged that bug fix in. I'm pretty sure you know that, but if you decide to do something like this after you've started the vote, please cancel the vote, bump the RC number and start a new vote. Check If you guys don't mind taking a look, I'd like to submit it to the incubator mailing list for a vote tomorrow if we have no issues with these Start a VOTE thread on this list and if it passes go to the general list. If all mentors vote on this list the VOTE on the general list is more informational than anything else. Done! I'll look into the ZIPs myself in a few hours so you'll know how I'm going to vote 8-) Stefan
Re: [Lucene.Net] 2.9.4
On 2011-10-03, Prescott Nasser wrote: I think we're ready, i just dont know the procedures to call a vote. Don't know the exact details for Lucene.Net but the general approach is likely always the same. * Make sure your PGP key is inside the KEYS file people will use to check the artifacts * tag the tree that is going to become the release (svn cp trunk tags/2.9.4RC1 - or something like that) * build the release artifacts, hash and sign them * upload the release artifacts to you personal homepage on people.apache.org * call for a vote on this list listing the svn tag (including the revision number would be good) and the location where to find the artifacts. * if the vote fails, adapt and start with a new tag (incrementing the number after the RC) * if the vote passes, copy the tag to 2.9.4 without any RC, copy the artifacts to your incubator dist area, wait for a few hours to allow the mirrors to catch up, update download page and publish it, announce wherever you feel it is appropriate Stefan
RE: [Lucene.Net] 2.9.4
Prescott,
You can do one of two things:
- Remove the volatile keyword, but keep the lock statement around the
access to the field
- Remove the lock, and add the volatile keyword to the field
This will allow you to assign to the _infoStream variable (read/write) and
be sure to have the most up-to-date value in the variable, as well as
guarantee atomic reads/writes to that variable.
Your example is incorrect. The volatile on p only guarantees that
reads/writes will be current if p is changed. In other words, if you
assign a new person instance to p, you can do so without using a lock
statement and guarantee that the reads/writes from p will be atomic.
However, any calls you make to p are not protected, not because of
volatile. Volatile will *never* be able to protect calls, it only protects
variables.
Lock, on the other hand, can protect calls, assuming that you cover all the
calls with the same lock. You can also group other operations and make
sure that synchronization occurs.
Note that a lock *only* guarantees atomicity/mutual exclusion; when applied
to multiple statements, there's no guarantee that you won't corrupt
something. If an exception is thrown inside of a lock statement (the
second line in three lines of code in the lock block, for example) then the
previous values don't roll back or anything.
Because atomicity with a variable assignment is mutually exclusive around
*one* operation, there's no chance of corruption.
Let me know if you want further clarification.
Additionally, if you have a specific patch/issue in JIRA you want me to
look at, let me know, I'll let you know if the solution is right from a
thread-safety point of view.
- Nick
From: Prescott Nasser geobmx...@hotmail.com
Sent: Friday, September 23, 2011 1:17 AM
To: lucene-net-dev@lucene.apache.org
Subject: RE: [Lucene.Net] 2.9.4
I see, so you're essentially saying, I can simply remove the volatile
keyword in this case, and it's exactly the same becuase I am only using it
for read and writes?
So the case I'd need to be more careful of is if an manipulation method is
called on the object itself - suppose:
public person {
_name = Me
public changeName(string n)
{
_name = n;
}
}
If one were to write
public volatile person p = new person();
p.changeName(You);
the call to the method would in this case need a lock (which volatile
gives) to gaurentee that changeName occurs before other items read or
overwrite variable p?
but a straight read or write won't matter:
p = new person();
p = new person():
x = p;
p = new person();
Here, I wouldn't need the volatile keyword becuase those are merely reads
and wrights?
CC: lucene-net-dev@lucene.apache.org
From: casper...@caspershouse.com
Date: Thu, 22 Sep 2011 23:58:42 -0400
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] 2.9.4
Prescott,
You really don't need to do that; reads and writes of reference fields
are guaranteed to be atomic as per section 5.5 of the C# Language
Specufication (Atomicity of variable references)
If you were doing other operations beyond the read and write that you
wanted to be atomic, then the lock statement is appropriate, but in this
case it's not.
The volatile keyword in this case (assuming no lock) would absolutely be
needed to guarantee that the variable has the most up-to-date value at the
time of access; using lock does this for you and makes volatile
unnecessary.
- Nick
On Sep 22, 2011, at 11:14 PM, Prescott Nasser geobmx...@hotmail.com
wrote:
Before I go replacing all the volatile fields I wanted to run this past
the list:
private System.IO.StreamWriter infoStream;
into
private object o = new object();
private System.IO.StreamWriter _infoStream;
private System.IO.StreamWriter infoStream
{
get
{
lock (o)
{
return _infoStream;
}
}
set
{
lock (o)
{
_infoStream = value;
}
}
}
Sorry, I don't normally deal with locks..
Thanks for any guidance
~P
@Prescott,
Can the volatile fields be wrapped in a lock statement and code that
access
those fields with replaced with call to a property /method that wraps
access
to that field?
On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard thowar...@gmail.com
wrote:
I thought it was:
2.9.2 and before are 2.0 compatible
2.9.4 and before are 3.5 compatible
After 2.9.4 are 4.0 compatible
Thanks,
Troy
On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
mhern...@wickedsoftware.net wrote:
if thats the case, then well need conditional statements for
including
ThreadLocalT
On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser
geobmx...@hotmail.com
wrote:
I thought this was after 2.9.4
Sent
RE: [Lucene.Net] 2.9.4
NP
From: Prescott Nasser geobmx...@hotmail.com
Sent: Friday, September 23, 2011 9:31 AM
To: lucene-net-dev@lucene.apache.org, casper...@caspershouse.com
Subject: RE: [Lucene.Net] 2.9.4
That helps thanks. No Jira although I will put one in.
Sent from my Windows Phone
-Original Message-
From: casper...@caspershouse.com
Sent: Friday, September 23, 2011 6:05 AM
To: lucene-net-dev@lucene.apache.org
Subject: RE: [Lucene.Net] 2.9.4
Prescott,
You can do one of two things:
- Remove the volatile keyword, but keep the lock statement around the
access to the field
- Remove the lock, and add the volatile keyword to the field
This will allow you to assign to the _infoStream variable (read/write) and
be sure to have the most up-to-date value in the variable, as well as
guarantee atomic reads/writes to that variable.
Your example is incorrect. The volatile on p only guarantees that
reads/writes will be current if p is changed. In other words, if you
assign a new person instance to p, you can do so without using a lock
statement and guarantee that the reads/writes from p will be atomic.
However, any calls you make to p are not protected, not because of
volatile. Volatile will *never* be able to protect calls, it only
protects
variables.
Lock, on the other hand, can protect calls, assuming that you cover all
the
calls with the same lock. You can also group other operations and make
sure that synchronization occurs.
Note that a lock *only* guarantees atomicity/mutual exclusion; when
applied
to multiple statements, there's no guarantee that you won't corrupt
something. If an exception is thrown inside of a lock statement (the
second line in three lines of code in the lock block, for example) then
the
previous values don't roll back or anything.
Because atomicity with a variable assignment is mutually exclusive around
*one* operation, there's no chance of corruption.
Let me know if you want further clarification.
Additionally, if you have a specific patch/issue in JIRA you want me to
look at, let me know, I'll let you know if the solution is right from a
thread-safety point of view.
- Nick
From: Prescott Nasser geobmx...@hotmail.com
Sent: Friday, September 23, 2011 1:17 AM
To: lucene-net-dev@lucene.apache.org
Subject: RE: [Lucene.Net] 2.9.4
I see, so you're essentially saying, I can simply remove the volatile
keyword in this case, and it's exactly the same becuase I am only using it
for read and writes?
So the case I'd need to be more careful of is if an manipulation method is
called on the object itself - suppose:
public person {
_name = Me
public changeName(string n)
{
_name = n;
}
}
If one were to write
public volatile person p = new person();
p.changeName(You);
the call to the method would in this case need a lock (which volatile
gives) to gaurentee that changeName occurs before other items read or
overwrite variable p?
but a straight read or write won't matter:
p = new person();
p = new person():
x = p;
p = new person();
Here, I wouldn't need the volatile keyword becuase those are merely reads
and wrights?
CC: lucene-net-dev@lucene.apache.org
From: casper...@caspershouse.com
Date: Thu, 22 Sep 2011 23:58:42 -0400
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] 2.9.4
Prescott,
You really don't need to do that; reads and writes of reference fields
are guaranteed to be atomic as per section 5.5 of the C# Language
Specufication (Atomicity of variable references)
If you were doing other operations beyond the read and write that you
wanted to be atomic, then the lock statement is appropriate, but in this
case it's not.
The volatile keyword in this case (assuming no lock) would absolutely be
needed to guarantee that the variable has the most up-to-date value at the
time of access; using lock does this for you and makes volatile
unnecessary.
- Nick
On Sep 22, 2011, at 11:14 PM, Prescott Nasser geobmx...@hotmail.com
wrote:
Before I go replacing all the volatile fields I wanted to run this
past
the list:
private System.IO.StreamWriter infoStream;
into
private object o = new object();
private System.IO.StreamWriter _infoStream;
private System.IO.StreamWriter infoStream
{
get
{
lock (o)
{
return _infoStream;
}
}
set
{
lock (o)
{
_infoStream = value;
}
}
}
Sorry, I don't normally deal with locks..
Thanks for any guidance
~P
@Prescott,
Can the volatile fields be wrapped in a lock statement and code that
access
those fields with replaced with call to a property /method that wraps
access
to that field
Re: [Lucene.Net] 2.9.4
So I now have the scripts exporting the html site. Does the current cms/site some how link to ~/site/docs ? Or if we publish the documents online they would need to into two directories ~/site/docs/version for posterity ~/site/trunk/content/ lucene.net/docs/version for everyone to view them online? On Wed, Sep 21, 2011 at 12:37 AM, Troy Howard thowar...@gmail.com wrote: At one time I had a SVN server set up at work that had a post-commit hook set up that would generate a static HTML site from the XML doc files using Sandcastle. So.. It can be done. That was about 3-4 years ago and I don't work at that company any longer, so I don't have access to the details of how that was done. Regarding SVN locations... Autogenerated XML doc files should go in the ~/trunk/doc/component folders. The Sandcastle generated static HTML should go under ~/site/docs/version folders. I'll see if I can't dig up some info on how to generate static HTML with Sandcastle. Thanks, Troy On Tue, Sep 20, 2011 at 9:15 PM, Michael Herndon mhern...@wickedsoftware.net wrote: We have a folder /trunk/docs, shouldn't this be the place for that? We should have a live site for the documentation that people can browse, similar to the parent project's site. http://lucene.apache.org/java/3_4_0/api/all/index.html. It makes it the documentation more accessible. The rub is that Sandcastle SHFB generates html files with guid names, xml bin files that map to the html files, and aspx pages which acts as the glue. The aspx pages parses the xml/bin files which creates the document site. Thus we're now required to use a server that knows how to serve up aspx pages. If any one knows a way to generate just vanilla html using Sandcastle SHFB, I could just create a folder per version and push the docs to incubator site. But so far I haven't found an option for this. Keeping the generated help docs inside of source would still require for users to setup a local website just to view the documentation and it adds extra noise in the project. In the release we can provide a zipped file of the site and a generated .chm or even help2/3 files. On Tue, Sep 20, 2011 at 11:38 PM, Prescott Nasser geobmx...@hotmail.com wrote: We should probably fix the ClsCompliance warnings if they have not already been fixed We will have some issues with this - some are marked volatile - which basically have to be a non-CLS compliant type (as far as my research is finding) Anyone have thoughts? I went through and replaced sbyte - Int16, and uint - Int64, but I'm having an issue with this, and I don't think removing the volatile keyword is the right solution. find a place to put the generated documentation. We have a folder /trunk/docs, shouldn't this be the place for that? I remember someone mentioning he/she was unable to access a class from VB.NET. The class had public fields properties with the same names but different casing. The fields should be private. The link in the readme is a dead link: http://lucene.apache.org/lucene.net/docs/2.4.0/ The docs generated by sandcastle SHFB require a server that allows aspx files to be executed. We should either remove the link from the readme or find the docs a new home and update the link. We should generate new documentation and update the link I'll see if I can setup automating Lucene.Net http://lucene.net nuget package creation for trunk in the next day or so. - Michael On Tue, Sep 20, 2011 at 5:48 PM, Prescott Nasser geobmx...@hotmail.com wrote: Hey all seems like we are set with 2.9.4? Feedback has been positive and its been quiet. Do we feel ready to vote for a new release? -Prescott Sent from my Windows Phone
RE: [Lucene.Net] 2.9.4
Before I go replacing all the volatile fields I wanted to run this past the
list:
private System.IO.StreamWriter infoStream;
into
private object o = new object();
private System.IO.StreamWriter _infoStream;
private System.IO.StreamWriter infoStream
{
get
{
lock (o)
{
return _infoStream;
}
}
set
{
lock (o)
{
_infoStream = value;
}
}
}
Sorry, I don't normally deal with locks..
Thanks for any guidance
~P
@Prescott,
Can the volatile fields be wrapped in a lock statement and code that access
those fields with replaced with call to a property /method that wraps access
to that field?
On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard thowar...@gmail.com wrote:
I thought it was:
2.9.2 and before are 2.0 compatible
2.9.4 and before are 3.5 compatible
After 2.9.4 are 4.0 compatible
Thanks,
Troy
On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
mhern...@wickedsoftware.net wrote:
if thats the case, then well need conditional statements for including
ThreadLocalT
On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser geobmx...@hotmail.com
wrote:
I thought this was after 2.9.4
Sent from my Windows Phone
-Original Message-
From: Michael Herndon
Sent: Wednesday, September 21, 2011 8:30 AM
To: lucene-net-dev@lucene.apache.org
Cc: lucene-net-...@incubator.apache.org
Subject: Re: [Lucene.Net] 2.9.4
@Robert,
I believe the overwhelming consensus on the mailing list vote was to
move
to
.NET 4.0 and drop support for previous versions.
I'll take care of build scripts issue while they being refactored into
smaller chunks this week.
@Troy, Agreed.
On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan robe...@gmx.net wrote:
On 20.09.2011 23:48, Prescott Nasser wrote:
Hey all seems like we are set with 2.9.4? Feedback has been positive
and
its been quiet. Do we feel ready to vote for a new release?
I don't know if the build infrastructure is part of the
release. If yes, then there is an open issue:
Contrib doesn't build right now because there
are some assembly name mismatches between certain *.csproj
files and build/scripts/contrib.targets.
The following patches should fix the issue:
https://github.com/robert-j/**lucene.net/commit/**
c5218bca56c19b3407648224781eec**7316994a39
https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec7316994a39
https://github.com/robert-j/**lucene.net/commit/**
50bad187655d59968d51d472b57c2a**40e201d663
https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a40e201d663
Also, the fix for [LUCENENET-358] is basically making
Lucene.Net.dll a .NET 4.0-only assembly:
https://github.com/apache/**lucene.net/commit/**
23ea6f52362fc7dbce48fd012cea12**9a7350c73c
https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a7350c73c
Did we agree about abandoning .NET = 3.5?
Robert
RE: [Lucene.Net] 2.9.4
The line before had volatile in it..
private volatile System.IO.StreamWriter infoStream;
From: geobmx...@hotmail.com
To: lucene-net-dev@lucene.apache.org
Date: Thu, 22 Sep 2011 20:14:41 -0700
Subject: RE: [Lucene.Net] 2.9.4
Before I go replacing all the volatile fields I wanted to run this past the
list:
private System.IO.StreamWriter infoStream;
into
private object o = new object();
private System.IO.StreamWriter _infoStream;
private System.IO.StreamWriter infoStream
{
get
{
lock (o)
{
return _infoStream;
}
}
set
{
lock (o)
{
_infoStream = value;
}
}
}
Sorry, I don't normally deal with locks..
Thanks for any guidance
~P
@Prescott,
Can the volatile fields be wrapped in a lock statement and code that access
those fields with replaced with call to a property /method that wraps access
to that field?
On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard thowar...@gmail.com wrote:
I thought it was:
2.9.2 and before are 2.0 compatible
2.9.4 and before are 3.5 compatible
After 2.9.4 are 4.0 compatible
Thanks,
Troy
On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
mhern...@wickedsoftware.net wrote:
if thats the case, then well need conditional statements for including
ThreadLocalT
On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser geobmx...@hotmail.com
wrote:
I thought this was after 2.9.4
Sent from my Windows Phone
-Original Message-
From: Michael Herndon
Sent: Wednesday, September 21, 2011 8:30 AM
To: lucene-net-dev@lucene.apache.org
Cc: lucene-net-...@incubator.apache.org
Subject: Re: [Lucene.Net] 2.9.4
@Robert,
I believe the overwhelming consensus on the mailing list vote was to
move
to
.NET 4.0 and drop support for previous versions.
I'll take care of build scripts issue while they being refactored into
smaller chunks this week.
@Troy, Agreed.
On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan robe...@gmx.net wrote:
On 20.09.2011 23:48, Prescott Nasser wrote:
Hey all seems like we are set with 2.9.4? Feedback has been positive
and
its been quiet. Do we feel ready to vote for a new release?
I don't know if the build infrastructure is part of the
release. If yes, then there is an open issue:
Contrib doesn't build right now because there
are some assembly name mismatches between certain *.csproj
files and build/scripts/contrib.targets.
The following patches should fix the issue:
https://github.com/robert-j/**lucene.net/commit/**
c5218bca56c19b3407648224781eec**7316994a39
https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec7316994a39
https://github.com/robert-j/**lucene.net/commit/**
50bad187655d59968d51d472b57c2a**40e201d663
https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a40e201d663
Also, the fix for [LUCENENET-358] is basically making
Lucene.Net.dll a .NET 4.0-only assembly:
https://github.com/apache/**lucene.net/commit/**
23ea6f52362fc7dbce48fd012cea12**9a7350c73c
https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a7350c73c
Did we agree about abandoning .NET = 3.5?
Robert
Re: [Lucene.Net] 2.9.4
Prescott,
You really don't need to do that; reads and writes of reference fields are
guaranteed to be atomic as per section 5.5 of the C# Language Specufication
(Atomicity of variable references)
If you were doing other operations beyond the read and write that you wanted to
be atomic, then the lock statement is appropriate, but in this case it's not.
The volatile keyword in this case (assuming no lock) would absolutely be needed
to guarantee that the variable has the most up-to-date value at the time of
access; using lock does this for you and makes volatile unnecessary.
- Nick
On Sep 22, 2011, at 11:14 PM, Prescott Nasser geobmx...@hotmail.com wrote:
Before I go replacing all the volatile fields I wanted to run this past the
list:
private System.IO.StreamWriter infoStream;
into
private object o = new object();
private System.IO.StreamWriter _infoStream;
private System.IO.StreamWriter infoStream
{
get
{
lock (o)
{
return _infoStream;
}
}
set
{
lock (o)
{
_infoStream = value;
}
}
}
Sorry, I don't normally deal with locks..
Thanks for any guidance
~P
@Prescott,
Can the volatile fields be wrapped in a lock statement and code that access
those fields with replaced with call to a property /method that wraps access
to that field?
On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard thowar...@gmail.com wrote:
I thought it was:
2.9.2 and before are 2.0 compatible
2.9.4 and before are 3.5 compatible
After 2.9.4 are 4.0 compatible
Thanks,
Troy
On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
mhern...@wickedsoftware.net wrote:
if thats the case, then well need conditional statements for including
ThreadLocalT
On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser geobmx...@hotmail.com
wrote:
I thought this was after 2.9.4
Sent from my Windows Phone
-Original Message-
From: Michael Herndon
Sent: Wednesday, September 21, 2011 8:30 AM
To: lucene-net-dev@lucene.apache.org
Cc: lucene-net-...@incubator.apache.org
Subject: Re: [Lucene.Net] 2.9.4
@Robert,
I believe the overwhelming consensus on the mailing list vote was to
move
to
.NET 4.0 and drop support for previous versions.
I'll take care of build scripts issue while they being refactored into
smaller chunks this week.
@Troy, Agreed.
On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan robe...@gmx.net wrote:
On 20.09.2011 23:48, Prescott Nasser wrote:
Hey all seems like we are set with 2.9.4? Feedback has been positive
and
its been quiet. Do we feel ready to vote for a new release?
I don't know if the build infrastructure is part of the
release. If yes, then there is an open issue:
Contrib doesn't build right now because there
are some assembly name mismatches between certain *.csproj
files and build/scripts/contrib.targets.
The following patches should fix the issue:
https://github.com/robert-j/**lucene.net/commit/**
c5218bca56c19b3407648224781eec**7316994a39
https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec7316994a39
https://github.com/robert-j/**lucene.net/commit/**
50bad187655d59968d51d472b57c2a**40e201d663
https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a40e201d663
Also, the fix for [LUCENENET-358] is basically making
Lucene.Net.dll a .NET 4.0-only assembly:
https://github.com/apache/**lucene.net/commit/**
23ea6f52362fc7dbce48fd012cea12**9a7350c73c
https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a7350c73c
Did we agree about abandoning .NET = 3.5?
Robert
RE: [Lucene.Net] 2.9.4
I see, so you're essentially saying, I can simply remove the volatile keyword
in this case, and it's exactly the same becuase I am only using it for read and
writes?
So the case I'd need to be more careful of is if an manipulation method is
called on the object itself - suppose:
public person {
_name = Me
public changeName(string n)
{
_name = n;
}
}
If one were to write
public volatile person p = new person();
p.changeName(You);
the call to the method would in this case need a lock (which volatile gives) to
gaurentee that changeName occurs before other items read or overwrite variable
p?
but a straight read or write won't matter:
p = new person();
p = new person():
x = p;
p = new person();
Here, I wouldn't need the volatile keyword becuase those are merely reads and
wrights?
CC: lucene-net-dev@lucene.apache.org
From: casper...@caspershouse.com
Date: Thu, 22 Sep 2011 23:58:42 -0400
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] 2.9.4
Prescott,
You really don't need to do that; reads and writes of reference fields are
guaranteed to be atomic as per section 5.5 of the C# Language Specufication
(Atomicity of variable references)
If you were doing other operations beyond the read and write that you wanted
to be atomic, then the lock statement is appropriate, but in this case it's
not.
The volatile keyword in this case (assuming no lock) would absolutely be
needed to guarantee that the variable has the most up-to-date value at the
time of access; using lock does this for you and makes volatile unnecessary.
- Nick
On Sep 22, 2011, at 11:14 PM, Prescott Nasser geobmx...@hotmail.com wrote:
Before I go replacing all the volatile fields I wanted to run this past the
list:
private System.IO.StreamWriter infoStream;
into
private object o = new object();
private System.IO.StreamWriter _infoStream;
private System.IO.StreamWriter infoStream
{
get
{
lock (o)
{
return _infoStream;
}
}
set
{
lock (o)
{
_infoStream = value;
}
}
}
Sorry, I don't normally deal with locks..
Thanks for any guidance
~P
@Prescott,
Can the volatile fields be wrapped in a lock statement and code that access
those fields with replaced with call to a property /method that wraps
access
to that field?
On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard thowar...@gmail.com wrote:
I thought it was:
2.9.2 and before are 2.0 compatible
2.9.4 and before are 3.5 compatible
After 2.9.4 are 4.0 compatible
Thanks,
Troy
On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
mhern...@wickedsoftware.net wrote:
if thats the case, then well need conditional statements for including
ThreadLocalT
On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser geobmx...@hotmail.com
wrote:
I thought this was after 2.9.4
Sent from my Windows Phone
-Original Message-
From: Michael Herndon
Sent: Wednesday, September 21, 2011 8:30 AM
To: lucene-net-dev@lucene.apache.org
Cc: lucene-net-...@incubator.apache.org
Subject: Re: [Lucene.Net] 2.9.4
@Robert,
I believe the overwhelming consensus on the mailing list vote was to
move
to
.NET 4.0 and drop support for previous versions.
I'll take care of build scripts issue while they being refactored into
smaller chunks this week.
@Troy, Agreed.
On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan robe...@gmx.net wrote:
On 20.09.2011 23:48, Prescott Nasser wrote:
Hey all seems like we are set with 2.9.4? Feedback has been positive
and
its been quiet. Do we feel ready to vote for a new release?
I don't know if the build infrastructure is part of the
release. If yes, then there is an open issue:
Contrib doesn't build right now because there
are some assembly name mismatches between certain *.csproj
files and build/scripts/contrib.targets.
The following patches should fix the issue:
https://github.com/robert-j/**lucene.net/commit/**
c5218bca56c19b3407648224781eec**7316994a39
https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec7316994a39
https://github.com/robert-j/**lucene.net/commit/**
50bad187655d59968d51d472b57c2a**40e201d663
https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a40e201d663
Also, the fix for [LUCENENET-358] is basically making
Lucene.Net.dll a .NET 4.0-only assembly:
https://github.com/apache/**lucene.net/commit/**
23ea6f52362fc7dbce48fd012cea12**9a7350c73c
https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a7350c73c
Did we agree about abandoning .NET = 3.5?
Robert
Re: [Lucene.Net] 2.9.4
I thought it was: 2.9.2 and before are 2.0 compatible 2.9.4 and before are 3.5 compatible After 2.9.4 are 4.0 compatible Thanks, Troy On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon mhern...@wickedsoftware.net wrote: if thats the case, then well need conditional statements for including ThreadLocalT On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser geobmx...@hotmail.comwrote: I thought this was after 2.9.4 Sent from my Windows Phone -Original Message- From: Michael Herndon Sent: Wednesday, September 21, 2011 8:30 AM To: lucene-net-dev@lucene.apache.org Cc: lucene-net-...@incubator.apache.org Subject: Re: [Lucene.Net] 2.9.4 @Robert, I believe the overwhelming consensus on the mailing list vote was to move to .NET 4.0 and drop support for previous versions. I'll take care of build scripts issue while they being refactored into smaller chunks this week. @Troy, Agreed. On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan robe...@gmx.net wrote: On 20.09.2011 23:48, Prescott Nasser wrote: Hey all seems like we are set with 2.9.4? Feedback has been positive and its been quiet. Do we feel ready to vote for a new release? I don't know if the build infrastructure is part of the release. If yes, then there is an open issue: Contrib doesn't build right now because there are some assembly name mismatches between certain *.csproj files and build/scripts/contrib.targets. The following patches should fix the issue: https://github.com/robert-j/**lucene.net/commit/** c5218bca56c19b3407648224781eec**7316994a39 https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec7316994a39 https://github.com/robert-j/**lucene.net/commit/** 50bad187655d59968d51d472b57c2a**40e201d663 https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a40e201d663 Also, the fix for [LUCENENET-358] is basically making Lucene.Net.dll a .NET 4.0-only assembly: https://github.com/apache/**lucene.net/commit/** 23ea6f52362fc7dbce48fd012cea12**9a7350c73c https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a7350c73c Did we agree about abandoning .NET = 3.5? Robert
Re: [Lucene.Net] 2.9.4
@all, I updated the build scripts to increase it's granularity. https://cwiki.apache.org/LUCENENET/build-system-scripts.html Similarity was include, though are there any tests for this project ? Some of the contrib tests are failing, I saw a few in Contrib.Highlighter just glancing at the output . I recieved some feedback Eric Woodruff. It looks like SHFB Sandcastle generate a plain file html, its been staring me in the face this whole time. I'll need to build in some targets that extract whats needed to push to site branch. Then I'll start working on nuget. @Prescott, Can the volatile fields be wrapped in a lock statement and code that access those fields with replaced with call to a property /method that wraps access to that field? On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard thowar...@gmail.com wrote: I thought it was: 2.9.2 and before are 2.0 compatible 2.9.4 and before are 3.5 compatible After 2.9.4 are 4.0 compatible Thanks, Troy On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon mhern...@wickedsoftware.net wrote: if thats the case, then well need conditional statements for including ThreadLocalT On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser geobmx...@hotmail.com wrote: I thought this was after 2.9.4 Sent from my Windows Phone -Original Message- From: Michael Herndon Sent: Wednesday, September 21, 2011 8:30 AM To: lucene-net-dev@lucene.apache.org Cc: lucene-net-...@incubator.apache.org Subject: Re: [Lucene.Net] 2.9.4 @Robert, I believe the overwhelming consensus on the mailing list vote was to move to .NET 4.0 and drop support for previous versions. I'll take care of build scripts issue while they being refactored into smaller chunks this week. @Troy, Agreed. On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan robe...@gmx.net wrote: On 20.09.2011 23:48, Prescott Nasser wrote: Hey all seems like we are set with 2.9.4? Feedback has been positive and its been quiet. Do we feel ready to vote for a new release? I don't know if the build infrastructure is part of the release. If yes, then there is an open issue: Contrib doesn't build right now because there are some assembly name mismatches between certain *.csproj files and build/scripts/contrib.targets. The following patches should fix the issue: https://github.com/robert-j/**lucene.net/commit/** c5218bca56c19b3407648224781eec**7316994a39 https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec7316994a39 https://github.com/robert-j/**lucene.net/commit/** 50bad187655d59968d51d472b57c2a**40e201d663 https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a40e201d663 Also, the fix for [LUCENENET-358] is basically making Lucene.Net.dll a .NET 4.0-only assembly: https://github.com/apache/**lucene.net/commit/** 23ea6f52362fc7dbce48fd012cea12**9a7350c73c https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a7350c73c Did we agree about abandoning .NET = 3.5? Robert
RE: [Lucene.Net] 2.9.4
Similarity was include, though are there any tests for this project ? Similarity is obsolete (Queries.Net replaces it has test cases). It has already been removed in 2.9.4g DIGY -Original Message- From: Michael Herndon [mailto:mhern...@wickedsoftware.net] Sent: Wednesday, September 21, 2011 10:40 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 @all, I updated the build scripts to increase it's granularity. https://cwiki.apache.org/LUCENENET/build-system-scripts.html Similarity was include, though are there any tests for this project ? Some of the contrib tests are failing, I saw a few in Contrib.Highlighter just glancing at the output . I recieved some feedback Eric Woodruff. It looks like SHFB Sandcastle generate a plain file html, its been staring me in the face this whole time. I'll need to build in some targets that extract whats needed to push to site branch. Then I'll start working on nuget. @Prescott, Can the volatile fields be wrapped in a lock statement and code that access those fields with replaced with call to a property /method that wraps access to that field? On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard thowar...@gmail.com wrote: I thought it was: 2.9.2 and before are 2.0 compatible 2.9.4 and before are 3.5 compatible After 2.9.4 are 4.0 compatible Thanks, Troy On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon mhern...@wickedsoftware.net wrote: if thats the case, then well need conditional statements for including ThreadLocalT On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser geobmx...@hotmail.com wrote: I thought this was after 2.9.4 Sent from my Windows Phone -Original Message- From: Michael Herndon Sent: Wednesday, September 21, 2011 8:30 AM To: lucene-net-dev@lucene.apache.org Cc: lucene-net-...@incubator.apache.org Subject: Re: [Lucene.Net] 2.9.4 @Robert, I believe the overwhelming consensus on the mailing list vote was to move to .NET 4.0 and drop support for previous versions. I'll take care of build scripts issue while they being refactored into smaller chunks this week. @Troy, Agreed. On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan robe...@gmx.net wrote: On 20.09.2011 23:48, Prescott Nasser wrote: Hey all seems like we are set with 2.9.4? Feedback has been positive and its been quiet. Do we feel ready to vote for a new release? I don't know if the build infrastructure is part of the release. If yes, then there is an open issue: Contrib doesn't build right now because there are some assembly name mismatches between certain *.csproj files and build/scripts/contrib.targets. The following patches should fix the issue: https://github.com/robert-j/**lucene.net/commit/** c5218bca56c19b3407648224781eec**7316994a39 https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec 7316994a39 https://github.com/robert-j/**lucene.net/commit/** 50bad187655d59968d51d472b57c2a**40e201d663 https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a 40e201d663 Also, the fix for [LUCENENET-358] is basically making Lucene.Net.dll a .NET 4.0-only assembly: https://github.com/apache/**lucene.net/commit/** 23ea6f52362fc7dbce48fd012cea12**9a7350c73c https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a 7350c73c Did we agree about abandoning .NET = 3.5? Robert - Checked by AVG - www.avg.com Version: 2012.0.1809 / Virus Database: 2085/4510 - Release Date: 09/21/11
RE: [Lucene.Net] 2.9.4
@Robert Also, the fix for [LUCENENET-358] is basically making Lucene.Net.dll a .NET 4.0-only assembly: There is a commented part at the end of the CloseableThreadLocal which may seem familiar to you :) No harm in uncommenting it and no conditional compilation is needed. It also pass all test cases. DIGY -Original Message- From: Robert Jordan [mailto:robe...@gmx.net] Sent: Wednesday, September 21, 2011 3:09 PM To: lucene-net-...@incubator.apache.org Subject: Re: [Lucene.Net] 2.9.4 On 20.09.2011 23:48, Prescott Nasser wrote: Hey all seems like we are set with 2.9.4? Feedback has been positive and its been quiet. Do we feel ready to vote for a new release? I don't know if the build infrastructure is part of the release. If yes, then there is an open issue: Contrib doesn't build right now because there are some assembly name mismatches between certain *.csproj files and build/scripts/contrib.targets. The following patches should fix the issue: https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec 7316994a39 https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a 40e201d663 Also, the fix for [LUCENENET-358] is basically making Lucene.Net.dll a .NET 4.0-only assembly: https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a 7350c73c Did we agree about abandoning .NET = 3.5? Robert - Checked by AVG - www.avg.com Version: 2012.0.1809 / Virus Database: 2085/4510 - Release Date: 09/21/11
RE: [Lucene.Net] 2.9.4
You are right in race condition NullReferenceException. but static SupportClass.WeakHashTable slots = new SupportClass.WeakHashTable(); wouldn't work since it is intented to be created in all threads not once. Would you patch it or leave it to me? Thanks, DIGY -Original Message- From: Robert Jordan [mailto:robe...@gmx.net] Sent: Thursday, September 22, 2011 1:16 AM To: lucene-net-...@incubator.apache.org Subject: Re: [Lucene.Net] 2.9.4 Hi Digy, On 21.09.2011 23:38, Digy wrote: @Robert Also, the fix for [LUCENENET-358] is basically making Lucene.Net.dll a .NET 4.0-only assembly: There is a commented part at the end of the CloseableThreadLocal which may seem familiar to you :) Indeed :) I've missed this comment. No harm in uncommenting it and no conditional compilation is needed. It also pass all test cases. BTW, there is an issue with this commented-out code. If Value is not accessed at least once, Dispose() will fail with a NullReferenceException. There is also a little chance for a race condition. I'd rather get rid of Init() for this code: static SupportClass.WeakHashTable slots = new SupportClass.WeakHashTable(); Robert DIGY -Original Message- From: Robert Jordan [mailto:robe...@gmx.net] Sent: Wednesday, September 21, 2011 3:09 PM To: lucene-net-...@incubator.apache.org Subject: Re: [Lucene.Net] 2.9.4 On 20.09.2011 23:48, Prescott Nasser wrote: Hey all seems like we are set with 2.9.4? Feedback has been positive and its been quiet. Do we feel ready to vote for a new release? I don't know if the build infrastructure is part of the release. If yes, then there is an open issue: Contrib doesn't build right now because there are some assembly name mismatches between certain *.csproj files and build/scripts/contrib.targets. The following patches should fix the issue: https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec 7316994a39 https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a 40e201d663 Also, the fix for [LUCENENET-358] is basically making Lucene.Net.dll a .NET 4.0-only assembly: https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a 7350c73c Did we agree about abandoning .NET= 3.5? Robert - Checked by AVG - www.avg.com Version: 2012.0.1809 / Virus Database: 2085/4510 - Release Date: 09/21/11 - Checked by AVG - www.avg.com Version: 2012.0.1809 / Virus Database: 2085/4510 - Release Date: 09/21/11
RE: [Lucene.Net] 2.9.4
I reconsidered it and there is no race condition. A new slot will be created for each thread. But NullReferenceException bug is still there. DIGY -Original Message- From: Robert Jordan [mailto:robe...@gmx.net] Sent: Thursday, September 22, 2011 1:16 AM To: lucene-net-...@incubator.apache.org Subject: Re: [Lucene.Net] 2.9.4 Hi Digy, On 21.09.2011 23:38, Digy wrote: @Robert Also, the fix for [LUCENENET-358] is basically making Lucene.Net.dll a .NET 4.0-only assembly: There is a commented part at the end of the CloseableThreadLocal which may seem familiar to you :) Indeed :) I've missed this comment. No harm in uncommenting it and no conditional compilation is needed. It also pass all test cases. BTW, there is an issue with this commented-out code. If Value is not accessed at least once, Dispose() will fail with a NullReferenceException. There is also a little chance for a race condition. I'd rather get rid of Init() for this code: static SupportClass.WeakHashTable slots = new SupportClass.WeakHashTable(); Robert DIGY -Original Message- From: Robert Jordan [mailto:robe...@gmx.net] Sent: Wednesday, September 21, 2011 3:09 PM To: lucene-net-...@incubator.apache.org Subject: Re: [Lucene.Net] 2.9.4 On 20.09.2011 23:48, Prescott Nasser wrote: Hey all seems like we are set with 2.9.4? Feedback has been positive and its been quiet. Do we feel ready to vote for a new release? I don't know if the build infrastructure is part of the release. If yes, then there is an open issue: Contrib doesn't build right now because there are some assembly name mismatches between certain *.csproj files and build/scripts/contrib.targets. The following patches should fix the issue: https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec 7316994a39 https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a 40e201d663 Also, the fix for [LUCENENET-358] is basically making Lucene.Net.dll a .NET 4.0-only assembly: https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a 7350c73c Did we agree about abandoning .NET= 3.5? Robert - Checked by AVG - www.avg.com Version: 2012.0.1809 / Virus Database: 2085/4510 - Release Date: 09/21/11 - Checked by AVG - www.avg.com Version: 2012.0.1809 / Virus Database: 2085/4510 - Release Date: 09/21/11
Re: [Lucene.Net] 2.9.4
Big OK from our end Sorry to be nagging on this again, but it would be very nice if you could incorporate https://issues.apache.org/jira/browse/LUCENENET-431 in 2.9.4 as well. It is one of those bugfixes that really fix a lot more than they can possible break, so I hope this will justify a small divergence from JL. On Wed, Sep 21, 2011 at 1:29 AM, Michael Herndon mhern...@wickedsoftware.net wrote: We should probably fix the ClsCompliance warnings if they have not already been fixed find a place to put the generated documentation. I remember someone mentioning he/she was unable to access a class from VB.NET. The class had public fields properties with the same names but different casing. The fields should be private. The link in the readme is a dead link: http://lucene.apache.org/lucene.net/docs/2.4.0/ The docs generated by sandcastle SHFB require a server that allows aspx files to be executed. We should either remove the link from the readme or find the docs a new home and update the link. I'll see if I can setup automating Lucene.Net http://lucene.net nuget package creation for trunk in the next day or so. - Michael On Tue, Sep 20, 2011 at 5:48 PM, Prescott Nasser geobmx...@hotmail.com wrote: Hey all seems like we are set with 2.9.4? Feedback has been positive and its been quiet. Do we feel ready to vote for a new release? -Prescott Sent from my Windows Phone
RE: [Lucene.Net] 2.9.4
We should probably fix the ClsCompliance warnings if they have not already been fixed We will have some issues with this - some are marked volatile - which basically have to be a non-CLS compliant type (as far as my research is finding) Anyone have thoughts? I went through and replaced sbyte - Int16, and uint - Int64, but I'm having an issue with this, and I don't think removing the volatile keyword is the right solution. find a place to put the generated documentation. We have a folder /trunk/docs, shouldn't this be the place for that? I remember someone mentioning he/she was unable to access a class from VB.NET. The class had public fields properties with the same names but different casing. The fields should be private. The link in the readme is a dead link: http://lucene.apache.org/lucene.net/docs/2.4.0/ The docs generated by sandcastle SHFB require a server that allows aspx files to be executed. We should either remove the link from the readme or find the docs a new home and update the link. We should generate new documentation and update the link I'll see if I can setup automating Lucene.Net http://lucene.net nuget package creation for trunk in the next day or so. - Michael On Tue, Sep 20, 2011 at 5:48 PM, Prescott Nasser geobmx...@hotmail.comwrote: Hey all seems like we are set with 2.9.4? Feedback has been positive and its been quiet. Do we feel ready to vote for a new release? -Prescott Sent from my Windows Phone
Re: [Lucene.Net] 2.9.4
We have a folder /trunk/docs, shouldn't this be the place for that? We should have a live site for the documentation that people can browse, similar to the parent project's site. http://lucene.apache.org/java/3_4_0/api/all/index.html. It makes it the documentation more accessible. The rub is that Sandcastle SHFB generates html files with guid names, xml bin files that map to the html files, and aspx pages which acts as the glue. The aspx pages parses the xml/bin files which creates the document site. Thus we're now required to use a server that knows how to serve up aspx pages. If any one knows a way to generate just vanilla html using Sandcastle SHFB, I could just create a folder per version and push the docs to incubator site. But so far I haven't found an option for this. Keeping the generated help docs inside of source would still require for users to setup a local website just to view the documentation and it adds extra noise in the project. In the release we can provide a zipped file of the site and a generated .chm or even help2/3 files. On Tue, Sep 20, 2011 at 11:38 PM, Prescott Nasser geobmx...@hotmail.comwrote: We should probably fix the ClsCompliance warnings if they have not already been fixed We will have some issues with this - some are marked volatile - which basically have to be a non-CLS compliant type (as far as my research is finding) Anyone have thoughts? I went through and replaced sbyte - Int16, and uint - Int64, but I'm having an issue with this, and I don't think removing the volatile keyword is the right solution. find a place to put the generated documentation. We have a folder /trunk/docs, shouldn't this be the place for that? I remember someone mentioning he/she was unable to access a class from VB.NET. The class had public fields properties with the same names but different casing. The fields should be private. The link in the readme is a dead link: http://lucene.apache.org/lucene.net/docs/2.4.0/ The docs generated by sandcastle SHFB require a server that allows aspx files to be executed. We should either remove the link from the readme or find the docs a new home and update the link. We should generate new documentation and update the link I'll see if I can setup automating Lucene.Net http://lucene.net nuget package creation for trunk in the next day or so. - Michael On Tue, Sep 20, 2011 at 5:48 PM, Prescott Nasser geobmx...@hotmail.com wrote: Hey all seems like we are set with 2.9.4? Feedback has been positive and its been quiet. Do we feel ready to vote for a new release? -Prescott Sent from my Windows Phone
Re: [Lucene.Net] 2.9.4
Could we store sandcastle docs as a single zip/chm? On Wed, Sep 21, 2011 at 12:37 AM, Troy Howard thowar...@gmail.com wrote: At one time I had a SVN server set up at work that had a post-commit hook set up that would generate a static HTML site from the XML doc files using Sandcastle. So.. It can be done. That was about 3-4 years ago and I don't work at that company any longer, so I don't have access to the details of how that was done. Regarding SVN locations... Autogenerated XML doc files should go in the ~/trunk/doc/component folders. The Sandcastle generated static HTML should go under ~/site/docs/version folders. I'll see if I can't dig up some info on how to generate static HTML with Sandcastle. Thanks, Troy On Tue, Sep 20, 2011 at 9:15 PM, Michael Herndon mhern...@wickedsoftware.net wrote: We have a folder /trunk/docs, shouldn't this be the place for that? We should have a live site for the documentation that people can browse, similar to the parent project's site. http://lucene.apache.org/java/3_4_0/api/all/index.html. It makes it the documentation more accessible. The rub is that Sandcastle SHFB generates html files with guid names, xml bin files that map to the html files, and aspx pages which acts as the glue. The aspx pages parses the xml/bin files which creates the document site. Thus we're now required to use a server that knows how to serve up aspx pages. If any one knows a way to generate just vanilla html using Sandcastle SHFB, I could just create a folder per version and push the docs to incubator site. But so far I haven't found an option for this. Keeping the generated help docs inside of source would still require for users to setup a local website just to view the documentation and it adds extra noise in the project. In the release we can provide a zipped file of the site and a generated .chm or even help2/3 files. On Tue, Sep 20, 2011 at 11:38 PM, Prescott Nasser geobmx...@hotmail.com wrote: We should probably fix the ClsCompliance warnings if they have not already been fixed We will have some issues with this - some are marked volatile - which basically have to be a non-CLS compliant type (as far as my research is finding) Anyone have thoughts? I went through and replaced sbyte - Int16, and uint - Int64, but I'm having an issue with this, and I don't think removing the volatile keyword is the right solution. find a place to put the generated documentation. We have a folder /trunk/docs, shouldn't this be the place for that? I remember someone mentioning he/she was unable to access a class from VB.NET. The class had public fields properties with the same names but different casing. The fields should be private. The link in the readme is a dead link: http://lucene.apache.org/lucene.net/docs/2.4.0/ The docs generated by sandcastle SHFB require a server that allows aspx files to be executed. We should either remove the link from the readme or find the docs a new home and update the link. We should generate new documentation and update the link I'll see if I can setup automating Lucene.Net http://lucene.net nuget package creation for trunk in the next day or so. - Michael On Tue, Sep 20, 2011 at 5:48 PM, Prescott Nasser geobmx...@hotmail.com wrote: Hey all seems like we are set with 2.9.4? Feedback has been positive and its been quiet. Do we feel ready to vote for a new release? -Prescott Sent from my Windows Phone
Re: [Lucene.Net] 2.9.4
Why would we want to do that? Under the /site/docs directory, they need to be served up as loose HTML... IMO the XML files shouldn't be checked into SVN because they are auto-generated. The same goes for Sandcastle files.. However, in the release packages, I think we should include the XML files as well as a fully functional version of the Sandcastle docs that can be viewed locally. I personally thing CHMs are terrible user experience, and I'd much rather have a static HTML site I can browse locally, if we're going to bother including a copy of the documentation in the package, vs just hosting it online and calling that good (this is what most projects these days do). Good thing about hosting online -- searchable via google. Thanks, Troy On Tue, Sep 20, 2011 at 9:48 PM, Michael Herndon mhern...@wickedsoftware.net wrote: Could we store sandcastle docs as a single zip/chm? On Wed, Sep 21, 2011 at 12:37 AM, Troy Howard thowar...@gmail.com wrote: At one time I had a SVN server set up at work that had a post-commit hook set up that would generate a static HTML site from the XML doc files using Sandcastle. So.. It can be done. That was about 3-4 years ago and I don't work at that company any longer, so I don't have access to the details of how that was done. Regarding SVN locations... Autogenerated XML doc files should go in the ~/trunk/doc/component folders. The Sandcastle generated static HTML should go under ~/site/docs/version folders. I'll see if I can't dig up some info on how to generate static HTML with Sandcastle. Thanks, Troy On Tue, Sep 20, 2011 at 9:15 PM, Michael Herndon mhern...@wickedsoftware.net wrote: We have a folder /trunk/docs, shouldn't this be the place for that? We should have a live site for the documentation that people can browse, similar to the parent project's site. http://lucene.apache.org/java/3_4_0/api/all/index.html. It makes it the documentation more accessible. The rub is that Sandcastle SHFB generates html files with guid names, xml bin files that map to the html files, and aspx pages which acts as the glue. The aspx pages parses the xml/bin files which creates the document site. Thus we're now required to use a server that knows how to serve up aspx pages. If any one knows a way to generate just vanilla html using Sandcastle SHFB, I could just create a folder per version and push the docs to incubator site. But so far I haven't found an option for this. Keeping the generated help docs inside of source would still require for users to setup a local website just to view the documentation and it adds extra noise in the project. In the release we can provide a zipped file of the site and a generated .chm or even help2/3 files. On Tue, Sep 20, 2011 at 11:38 PM, Prescott Nasser geobmx...@hotmail.com wrote: We should probably fix the ClsCompliance warnings if they have not already been fixed We will have some issues with this - some are marked volatile - which basically have to be a non-CLS compliant type (as far as my research is finding) Anyone have thoughts? I went through and replaced sbyte - Int16, and uint - Int64, but I'm having an issue with this, and I don't think removing the volatile keyword is the right solution. find a place to put the generated documentation. We have a folder /trunk/docs, shouldn't this be the place for that? I remember someone mentioning he/she was unable to access a class from VB.NET. The class had public fields properties with the same names but different casing. The fields should be private. The link in the readme is a dead link: http://lucene.apache.org/lucene.net/docs/2.4.0/ The docs generated by sandcastle SHFB require a server that allows aspx files to be executed. We should either remove the link from the readme or find the docs a new home and update the link. We should generate new documentation and update the link I'll see if I can setup automating Lucene.Net http://lucene.net nuget package creation for trunk in the next day or so. - Michael On Tue, Sep 20, 2011 at 5:48 PM, Prescott Nasser geobmx...@hotmail.com wrote: Hey all seems like we are set with 2.9.4? Feedback has been positive and its been quiet. Do we feel ready to vote for a new release? -Prescott Sent from my Windows Phone
Re: [Lucene.Net] 2.9.4
I'm with you on checking in the static files into ~/site/doc/version that would be pretty easy to automate from jenkins msbuild if we can get the docs into static html. I currently just push all assemblies, help files, xml docs into ~/trunk/bin on the user's local once the scripts finish building, running tests, and reports. Nothing gets commited into svn from this at the moment. The site is generated, but not pushed anywhere. I was waiting to see how aspx thing plays out getting CI up with nuget before setting up a build release build task that automates everything including pushing the docs, finalized content, etc. So my real question is, do we need to store static docs that are generate in ~/trunk/docs/? If so, could we store those in a single file format and just provide a setup script that takes care of extracting the latest for the user versus putting all those files into trunk. Technically someone could build an post process hook that builds up a static html index from xml bin files, but I'm hoping it does not come to that. - Michael On Wed, Sep 21, 2011 at 12:56 AM, Troy Howard thowar...@gmail.com wrote: Why would we want to do that? Under the /site/docs directory, they need to be served up as loose HTML... IMO the XML files shouldn't be checked into SVN because they are auto-generated. The same goes for Sandcastle files.. However, in the release packages, I think we should include the XML files as well as a fully functional version of the Sandcastle docs that can be viewed locally. I personally thing CHMs are terrible user experience, and I'd much rather have a static HTML site I can browse locally, if we're going to bother including a copy of the documentation in the package, vs just hosting it online and calling that good (this is what most projects these days do). Good thing about hosting online -- searchable via google. Thanks, Troy On Tue, Sep 20, 2011 at 9:48 PM, Michael Herndon mhern...@wickedsoftware.net wrote: Could we store sandcastle docs as a single zip/chm? On Wed, Sep 21, 2011 at 12:37 AM, Troy Howard thowar...@gmail.com wrote: At one time I had a SVN server set up at work that had a post-commit hook set up that would generate a static HTML site from the XML doc files using Sandcastle. So.. It can be done. That was about 3-4 years ago and I don't work at that company any longer, so I don't have access to the details of how that was done. Regarding SVN locations... Autogenerated XML doc files should go in the ~/trunk/doc/component folders. The Sandcastle generated static HTML should go under ~/site/docs/version folders. I'll see if I can't dig up some info on how to generate static HTML with Sandcastle. Thanks, Troy On Tue, Sep 20, 2011 at 9:15 PM, Michael Herndon mhern...@wickedsoftware.net wrote: We have a folder /trunk/docs, shouldn't this be the place for that? We should have a live site for the documentation that people can browse, similar to the parent project's site. http://lucene.apache.org/java/3_4_0/api/all/index.html. It makes it the documentation more accessible. The rub is that Sandcastle SHFB generates html files with guid names, xml bin files that map to the html files, and aspx pages which acts as the glue. The aspx pages parses the xml/bin files which creates the document site. Thus we're now required to use a server that knows how to serve up aspx pages. If any one knows a way to generate just vanilla html using Sandcastle SHFB, I could just create a folder per version and push the docs to incubator site. But so far I haven't found an option for this. Keeping the generated help docs inside of source would still require for users to setup a local website just to view the documentation and it adds extra noise in the project. In the release we can provide a zipped file of the site and a generated .chm or even help2/3 files. On Tue, Sep 20, 2011 at 11:38 PM, Prescott Nasser geobmx...@hotmail.com wrote: We should probably fix the ClsCompliance warnings if they have not already been fixed We will have some issues with this - some are marked volatile - which basically have to be a non-CLS compliant type (as far as my research is finding) Anyone have thoughts? I went through and replaced sbyte - Int16, and uint - Int64, but I'm having an issue with this, and I don't think removing the volatile keyword is the right solution. find a place to put the generated documentation. We have a folder /trunk/docs, shouldn't this be the place for that? I remember someone mentioning he/she was unable to access a class from VB.NET. The class had public fields properties with the same names but different casing. The fields should be private. The link in the readme is a
Re: [Lucene.Net] 2.9.4
Hello again, We are done with testing on our end. As far as we can tell, Lucene 2.9.4 is good to go. Now all that is left is to hope Digy will decide to have the Spatial.Net fix in too so we can get the whole deal from nuget :) On Sun, Sep 11, 2011 at 8:22 PM, Prescott Nasser geobmx...@hotmail.comwrote: Thanks Itamar! Date: Sat, 10 Sep 2011 20:22:59 +0300 From: ita...@code972.com To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 We have been running some extensive tests 30hrs now against the 2.9.4 branch, and did not detect any leaks. We will have it running a few more days, if you wish to wait for more conclusive findings. On Wed, Sep 7, 2011 at 5:07 PM, Prescott Nasser geobmx...@hotmail.com wrote: 2.9.4 would make it in I assume because that will be our next official release. Sent from my Windows Phone -Original Message- From: Michael Herndon Sent: Wednesday, September 07, 2011 5:12 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 What version is going to make it to nuget? 2.9.4 or 2.9.4g? ooo totally forgot about nuget. we definitely need to get that setup. On Wed, Sep 7, 2011 at 6:46 AM, digy digy digyd...@gmail.com wrote: Since it includes some level of divergence from java I committed it to only 2.9.4g branch. https://issues.apache.org/jira/browse/LUCENE-1930 https://issues.apache.org/jira/browse/LUCENENET-431 DIGY On Wed, Sep 7, 2011 at 1:03 PM, Itamar Syn-Hershko ita...@code972.com wrote: Ok, core compiles, and all tests pass. We are now running long tests to measure memory usage among other things. There is one show stopper tho. There was a patch sent by Matt Warren for Spatial.Net, that doesn't seem to be in. See http://groups.google.com/group/ravendb/msg/7517f095810c48f3 Any chance you can get it in to 2.9.4? On Wed, Sep 7, 2011 at 1:01 AM, Itamar Syn-Hershko ita...@code972.com wrote: Ok, great, we will run RavenDB on top of 2.9.4 in the next few days and will let you know how it went. On Tue, Sep 6, 2011 at 8:59 PM, Michael Herndon mhern...@wickedsoftware.net wrote: I can't tell if the apache git mirror is updated via scheduler or from commit hooks, but its generally stays close to being on par with svn. I'll check next time I push something to svn. But both of those items have made it to the mirror. - michael On Tue, Sep 6, 2011 at 1:44 PM, Digy digyd...@gmail.com wrote: I don't know how often github mirror is updated. These are the original locations 2.9.4 https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/ 2.9.4g https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_ 9_4g/ Both versions include ThreadLocal fix + Signing. Thanks, DIGY -Original Message- From: itamar.synhers...@gmail.com [mailto: itamar.synhers...@gmail.com ] On Behalf Of Itamar Syn-Hershko Sent: Tuesday, September 06, 2011 2:34 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 Not a problem, we will test RavenDB on a separate branch, also for potential memory leaks Digy, can you make sure the github mirror contains an updated 2.9.4 tag I can pull from, which includes the latest ThreadLocal fix + the strongly signed patch applied to it? 2011/9/6 Digy digyd...@gmail.com To avoid misunderstanding... Community==all Lucene.Net users DIGY -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Monday, September 05, 2011 11:46 PM To: 'lucene-net-dev@lucene.apache.org' Subject: RE: [Lucene.Net] 2.9.4 Not bad idea, but I would prefer community's feedback instead of testing against all projects using Lucene.Net DIGY -Original Message- From: Matt Warren [mailto:mattd...@gmail.com] Sent: Monday, September 05, 2011 11:09 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 If you want to test it against a large project you could take a look at how RavenDB uses it? At the moment it's using 2.9.2 ( https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2 ) but if you were to recompile it against 2.9.4 and check that all it's
RE: [Lucene.Net] 2.9.4
Thanks Itamar! Date: Sat, 10 Sep 2011 20:22:59 +0300 From: ita...@code972.com To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 We have been running some extensive tests 30hrs now against the 2.9.4 branch, and did not detect any leaks. We will have it running a few more days, if you wish to wait for more conclusive findings. On Wed, Sep 7, 2011 at 5:07 PM, Prescott Nasser geobmx...@hotmail.comwrote: 2.9.4 would make it in I assume because that will be our next official release. Sent from my Windows Phone -Original Message- From: Michael Herndon Sent: Wednesday, September 07, 2011 5:12 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 What version is going to make it to nuget? 2.9.4 or 2.9.4g? ooo totally forgot about nuget. we definitely need to get that setup. On Wed, Sep 7, 2011 at 6:46 AM, digy digy digyd...@gmail.com wrote: Since it includes some level of divergence from java I committed it to only 2.9.4g branch. https://issues.apache.org/jira/browse/LUCENE-1930 https://issues.apache.org/jira/browse/LUCENENET-431 DIGY On Wed, Sep 7, 2011 at 1:03 PM, Itamar Syn-Hershko ita...@code972.com wrote: Ok, core compiles, and all tests pass. We are now running long tests to measure memory usage among other things. There is one show stopper tho. There was a patch sent by Matt Warren for Spatial.Net, that doesn't seem to be in. See http://groups.google.com/group/ravendb/msg/7517f095810c48f3 Any chance you can get it in to 2.9.4? On Wed, Sep 7, 2011 at 1:01 AM, Itamar Syn-Hershko ita...@code972.com wrote: Ok, great, we will run RavenDB on top of 2.9.4 in the next few days and will let you know how it went. On Tue, Sep 6, 2011 at 8:59 PM, Michael Herndon mhern...@wickedsoftware.net wrote: I can't tell if the apache git mirror is updated via scheduler or from commit hooks, but its generally stays close to being on par with svn. I'll check next time I push something to svn. But both of those items have made it to the mirror. - michael On Tue, Sep 6, 2011 at 1:44 PM, Digy digyd...@gmail.com wrote: I don't know how often github mirror is updated. These are the original locations 2.9.4 https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/ 2.9.4g https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_ 9_4g/ Both versions include ThreadLocal fix + Signing. Thanks, DIGY -Original Message- From: itamar.synhers...@gmail.com [mailto: itamar.synhers...@gmail.com ] On Behalf Of Itamar Syn-Hershko Sent: Tuesday, September 06, 2011 2:34 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 Not a problem, we will test RavenDB on a separate branch, also for potential memory leaks Digy, can you make sure the github mirror contains an updated 2.9.4 tag I can pull from, which includes the latest ThreadLocal fix + the strongly signed patch applied to it? 2011/9/6 Digy digyd...@gmail.com To avoid misunderstanding... Community==all Lucene.Net users DIGY -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Monday, September 05, 2011 11:46 PM To: 'lucene-net-dev@lucene.apache.org' Subject: RE: [Lucene.Net] 2.9.4 Not bad idea, but I would prefer community's feedback instead of testing against all projects using Lucene.Net DIGY -Original Message- From: Matt Warren [mailto:mattd...@gmail.com] Sent: Monday, September 05, 2011 11:09 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 If you want to test it against a large project you could take a look at how RavenDB uses it? At the moment it's using 2.9.2 ( https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2 ) but if you were to recompile it against 2.9.4 and check that all it's unit-tests still run that would give you quite a large test case. On 5 September 2011 19:22, Prescott Nasser geobmx...@hotmail.com wrote: Hey All, How do people feel about the 2.9.4 code base? I've been using it for sometime, for my use cases it's be excellent. Do we feel we are ready to package this up and make it an official release? Or do we have some tasks left
Re: [Lucene.Net] 2.9.4
We have been running some extensive tests 30hrs now against the 2.9.4 branch, and did not detect any leaks. We will have it running a few more days, if you wish to wait for more conclusive findings. On Wed, Sep 7, 2011 at 5:07 PM, Prescott Nasser geobmx...@hotmail.comwrote: 2.9.4 would make it in I assume because that will be our next official release. Sent from my Windows Phone -Original Message- From: Michael Herndon Sent: Wednesday, September 07, 2011 5:12 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 What version is going to make it to nuget? 2.9.4 or 2.9.4g? ooo totally forgot about nuget. we definitely need to get that setup. On Wed, Sep 7, 2011 at 6:46 AM, digy digy digyd...@gmail.com wrote: Since it includes some level of divergence from java I committed it to only 2.9.4g branch. https://issues.apache.org/jira/browse/LUCENE-1930 https://issues.apache.org/jira/browse/LUCENENET-431 DIGY On Wed, Sep 7, 2011 at 1:03 PM, Itamar Syn-Hershko ita...@code972.com wrote: Ok, core compiles, and all tests pass. We are now running long tests to measure memory usage among other things. There is one show stopper tho. There was a patch sent by Matt Warren for Spatial.Net, that doesn't seem to be in. See http://groups.google.com/group/ravendb/msg/7517f095810c48f3 Any chance you can get it in to 2.9.4? On Wed, Sep 7, 2011 at 1:01 AM, Itamar Syn-Hershko ita...@code972.com wrote: Ok, great, we will run RavenDB on top of 2.9.4 in the next few days and will let you know how it went. On Tue, Sep 6, 2011 at 8:59 PM, Michael Herndon mhern...@wickedsoftware.net wrote: I can't tell if the apache git mirror is updated via scheduler or from commit hooks, but its generally stays close to being on par with svn. I'll check next time I push something to svn. But both of those items have made it to the mirror. - michael On Tue, Sep 6, 2011 at 1:44 PM, Digy digyd...@gmail.com wrote: I don't know how often github mirror is updated. These are the original locations 2.9.4 https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/ 2.9.4g https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_ 9_4g/ Both versions include ThreadLocal fix + Signing. Thanks, DIGY -Original Message- From: itamar.synhers...@gmail.com [mailto: itamar.synhers...@gmail.com ] On Behalf Of Itamar Syn-Hershko Sent: Tuesday, September 06, 2011 2:34 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 Not a problem, we will test RavenDB on a separate branch, also for potential memory leaks Digy, can you make sure the github mirror contains an updated 2.9.4 tag I can pull from, which includes the latest ThreadLocal fix + the strongly signed patch applied to it? 2011/9/6 Digy digyd...@gmail.com To avoid misunderstanding... Community==all Lucene.Net users DIGY -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Monday, September 05, 2011 11:46 PM To: 'lucene-net-dev@lucene.apache.org' Subject: RE: [Lucene.Net] 2.9.4 Not bad idea, but I would prefer community's feedback instead of testing against all projects using Lucene.Net DIGY -Original Message- From: Matt Warren [mailto:mattd...@gmail.com] Sent: Monday, September 05, 2011 11:09 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 If you want to test it against a large project you could take a look at how RavenDB uses it? At the moment it's using 2.9.2 ( https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2 ) but if you were to recompile it against 2.9.4 and check that all it's unit-tests still run that would give you quite a large test case. On 5 September 2011 19:22, Prescott Nasser geobmx...@hotmail.com wrote: Hey All, How do people feel about the 2.9.4 code base? I've been using it for sometime, for my use cases it's be excellent. Do we feel we are ready to package this up and make it an official release? Or do we have some tasks left to take care of? ~Prescott
RE: [Lucene.Net] 2.9.4
Good news. Thanks Itamar. DIGY -Original Message- From: itamar.synhers...@gmail.com [mailto:itamar.synhers...@gmail.com] On Behalf Of Itamar Syn-Hershko Sent: Saturday, September 10, 2011 8:23 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 We have been running some extensive tests 30hrs now against the 2.9.4 branch, and did not detect any leaks. We will have it running a few more days, if you wish to wait for more conclusive findings. On Wed, Sep 7, 2011 at 5:07 PM, Prescott Nasser geobmx...@hotmail.comwrote: 2.9.4 would make it in I assume because that will be our next official release. Sent from my Windows Phone -Original Message- From: Michael Herndon Sent: Wednesday, September 07, 2011 5:12 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 What version is going to make it to nuget? 2.9.4 or 2.9.4g? ooo totally forgot about nuget. we definitely need to get that setup. On Wed, Sep 7, 2011 at 6:46 AM, digy digy digyd...@gmail.com wrote: Since it includes some level of divergence from java I committed it to only 2.9.4g branch. https://issues.apache.org/jira/browse/LUCENE-1930 https://issues.apache.org/jira/browse/LUCENENET-431 DIGY On Wed, Sep 7, 2011 at 1:03 PM, Itamar Syn-Hershko ita...@code972.com wrote: Ok, core compiles, and all tests pass. We are now running long tests to measure memory usage among other things. There is one show stopper tho. There was a patch sent by Matt Warren for Spatial.Net, that doesn't seem to be in. See http://groups.google.com/group/ravendb/msg/7517f095810c48f3 Any chance you can get it in to 2.9.4? On Wed, Sep 7, 2011 at 1:01 AM, Itamar Syn-Hershko ita...@code972.com wrote: Ok, great, we will run RavenDB on top of 2.9.4 in the next few days and will let you know how it went. On Tue, Sep 6, 2011 at 8:59 PM, Michael Herndon mhern...@wickedsoftware.net wrote: I can't tell if the apache git mirror is updated via scheduler or from commit hooks, but its generally stays close to being on par with svn. I'll check next time I push something to svn. But both of those items have made it to the mirror. - michael On Tue, Sep 6, 2011 at 1:44 PM, Digy digyd...@gmail.com wrote: I don't know how often github mirror is updated. These are the original locations 2.9.4 https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/ 2.9.4g https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_ 9_4g/ Both versions include ThreadLocal fix + Signing. Thanks, DIGY -Original Message- From: itamar.synhers...@gmail.com [mailto: itamar.synhers...@gmail.com ] On Behalf Of Itamar Syn-Hershko Sent: Tuesday, September 06, 2011 2:34 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 Not a problem, we will test RavenDB on a separate branch, also for potential memory leaks Digy, can you make sure the github mirror contains an updated 2.9.4 tag I can pull from, which includes the latest ThreadLocal fix + the strongly signed patch applied to it? 2011/9/6 Digy digyd...@gmail.com To avoid misunderstanding... Community==all Lucene.Net users DIGY -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Monday, September 05, 2011 11:46 PM To: 'lucene-net-dev@lucene.apache.org' Subject: RE: [Lucene.Net] 2.9.4 Not bad idea, but I would prefer community's feedback instead of testing against all projects using Lucene.Net DIGY -Original Message- From: Matt Warren [mailto:mattd...@gmail.com] Sent: Monday, September 05, 2011 11:09 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 If you want to test it against a large project you could take a look at how RavenDB uses it? At the moment it's using 2.9.2 ( https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2 ) but if you were to recompile it against 2.9.4 and check that all it's unit-tests still run that would give you quite a large test case. On 5 September 2011 19:22, Prescott Nasser geobmx...@hotmail.com wrote: Hey All, How do people feel about the 2.9.4 code base? I've been using it for sometime, for my use cases it's be excellent. Do we feel we are ready to package this up and make it an official release? Or do we have some tasks left to take care of? ~Prescott
Re: [Lucene.Net] 2.9.4
What version is going to make it to nuget? 2.9.4 or 2.9.4g? 2011/9/7 digy digy digyd...@gmail.com You are right. I forgot to add a patch related with type-casting. Summary of the long story: Since CharArraySet inherits from Hashtable, some unimplemented methods such as Add(object,object) refer to the base class(Hashtable) which is wrong. Also calling GetEnumerator() using the System.Collections.ICollection interface does result in Hashtable's GetEnumerator() being invoked. So an explicit typecast is needed for invoking CharArraySet.GetEnumerator() (As a result, a bad (but *almost* working) implementation. It is rewritten in 2.9.4g) DIGY On Wed, Sep 7, 2011 at 4:11 AM, Prescott Nasser geobmx...@hotmail.com wrote: Also +1 - but I don't mind waiting to hear back regarding the RavenDB stuff - but we can prepare assuming it's all good. Digy can you elaborate on 414 ( https://issues.apache.org/jira/browse/LUCENENET-414). I must not have understood the complaint/question as adding that one method to me doesn't seem to resolve the issue brought up Thanks, ~P From: digyd...@gmail.com To: lucene-net-dev@lucene.apache.org Date: Tue, 6 Sep 2011 23:14:37 +0300 Subject: RE: [Lucene.Net] 2.9.4 +1 for an official release. DIGY -Original Message- From: Prescott Nasser [mailto:geobmx...@hotmail.com] Sent: Monday, September 05, 2011 9:22 PM To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org Subject: [Lucene.Net] 2.9.4 Hey All, How do people feel about the 2.9.4 code base? I've been using it for sometime, for my use cases it's be excellent. Do we feel we are ready to package this up and make it an official release? Or do we have some tasks left to take care of? ~Prescott = - Bu iletide virüs bulunamadı. AVG tarafından kontrol edildi - www.avg.com Sürüm: 2012.0.1796 / Virüs Veritabanı: 2082/4478 - Sürüm Tarihi: 05.09.2011
Re: [Lucene.Net] 2.9.4
Since it includes some level of divergence from java I committed it to only 2.9.4g branch. https://issues.apache.org/jira/browse/LUCENE-1930 https://issues.apache.org/jira/browse/LUCENENET-431 DIGY On Wed, Sep 7, 2011 at 1:03 PM, Itamar Syn-Hershko ita...@code972.comwrote: Ok, core compiles, and all tests pass. We are now running long tests to measure memory usage among other things. There is one show stopper tho. There was a patch sent by Matt Warren for Spatial.Net, that doesn't seem to be in. See http://groups.google.com/group/ravendb/msg/7517f095810c48f3 Any chance you can get it in to 2.9.4? On Wed, Sep 7, 2011 at 1:01 AM, Itamar Syn-Hershko ita...@code972.com wrote: Ok, great, we will run RavenDB on top of 2.9.4 in the next few days and will let you know how it went. On Tue, Sep 6, 2011 at 8:59 PM, Michael Herndon mhern...@wickedsoftware.net wrote: I can't tell if the apache git mirror is updated via scheduler or from commit hooks, but its generally stays close to being on par with svn. I'll check next time I push something to svn. But both of those items have made it to the mirror. - michael On Tue, Sep 6, 2011 at 1:44 PM, Digy digyd...@gmail.com wrote: I don't know how often github mirror is updated. These are the original locations 2.9.4 https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/ 2.9.4g https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_ 9_4g/ Both versions include ThreadLocal fix + Signing. Thanks, DIGY -Original Message- From: itamar.synhers...@gmail.com [mailto:itamar.synhers...@gmail.com ] On Behalf Of Itamar Syn-Hershko Sent: Tuesday, September 06, 2011 2:34 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 Not a problem, we will test RavenDB on a separate branch, also for potential memory leaks Digy, can you make sure the github mirror contains an updated 2.9.4 tag I can pull from, which includes the latest ThreadLocal fix + the strongly signed patch applied to it? 2011/9/6 Digy digyd...@gmail.com To avoid misunderstanding... Community==all Lucene.Net users DIGY -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Monday, September 05, 2011 11:46 PM To: 'lucene-net-dev@lucene.apache.org' Subject: RE: [Lucene.Net] 2.9.4 Not bad idea, but I would prefer community's feedback instead of testing against all projects using Lucene.Net DIGY -Original Message- From: Matt Warren [mailto:mattd...@gmail.com] Sent: Monday, September 05, 2011 11:09 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 If you want to test it against a large project you could take a look at how RavenDB uses it? At the moment it's using 2.9.2 ( https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2 ) but if you were to recompile it against 2.9.4 and check that all it's unit-tests still run that would give you quite a large test case. On 5 September 2011 19:22, Prescott Nasser geobmx...@hotmail.com wrote: Hey All, How do people feel about the 2.9.4 code base? I've been using it for sometime, for my use cases it's be excellent. Do we feel we are ready to package this up and make it an official release? Or do we have some tasks left to take care of? ~Prescott
Re: [Lucene.Net] 2.9.4
What version is going to make it to nuget? 2.9.4 or 2.9.4g? ooo totally forgot about nuget. we definitely need to get that setup. On Wed, Sep 7, 2011 at 6:46 AM, digy digy digyd...@gmail.com wrote: Since it includes some level of divergence from java I committed it to only 2.9.4g branch. https://issues.apache.org/jira/browse/LUCENE-1930 https://issues.apache.org/jira/browse/LUCENENET-431 DIGY On Wed, Sep 7, 2011 at 1:03 PM, Itamar Syn-Hershko ita...@code972.com wrote: Ok, core compiles, and all tests pass. We are now running long tests to measure memory usage among other things. There is one show stopper tho. There was a patch sent by Matt Warren for Spatial.Net, that doesn't seem to be in. See http://groups.google.com/group/ravendb/msg/7517f095810c48f3 Any chance you can get it in to 2.9.4? On Wed, Sep 7, 2011 at 1:01 AM, Itamar Syn-Hershko ita...@code972.com wrote: Ok, great, we will run RavenDB on top of 2.9.4 in the next few days and will let you know how it went. On Tue, Sep 6, 2011 at 8:59 PM, Michael Herndon mhern...@wickedsoftware.net wrote: I can't tell if the apache git mirror is updated via scheduler or from commit hooks, but its generally stays close to being on par with svn. I'll check next time I push something to svn. But both of those items have made it to the mirror. - michael On Tue, Sep 6, 2011 at 1:44 PM, Digy digyd...@gmail.com wrote: I don't know how often github mirror is updated. These are the original locations 2.9.4 https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/ 2.9.4g https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_ 9_4g/ Both versions include ThreadLocal fix + Signing. Thanks, DIGY -Original Message- From: itamar.synhers...@gmail.com [mailto: itamar.synhers...@gmail.com ] On Behalf Of Itamar Syn-Hershko Sent: Tuesday, September 06, 2011 2:34 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 Not a problem, we will test RavenDB on a separate branch, also for potential memory leaks Digy, can you make sure the github mirror contains an updated 2.9.4 tag I can pull from, which includes the latest ThreadLocal fix + the strongly signed patch applied to it? 2011/9/6 Digy digyd...@gmail.com To avoid misunderstanding... Community==all Lucene.Net users DIGY -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Monday, September 05, 2011 11:46 PM To: 'lucene-net-dev@lucene.apache.org' Subject: RE: [Lucene.Net] 2.9.4 Not bad idea, but I would prefer community's feedback instead of testing against all projects using Lucene.Net DIGY -Original Message- From: Matt Warren [mailto:mattd...@gmail.com] Sent: Monday, September 05, 2011 11:09 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 If you want to test it against a large project you could take a look at how RavenDB uses it? At the moment it's using 2.9.2 ( https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2 ) but if you were to recompile it against 2.9.4 and check that all it's unit-tests still run that would give you quite a large test case. On 5 September 2011 19:22, Prescott Nasser geobmx...@hotmail.com wrote: Hey All, How do people feel about the 2.9.4 code base? I've been using it for sometime, for my use cases it's be excellent. Do we feel we are ready to package this up and make it an official release? Or do we have some tasks left to take care of? ~Prescott
Re: [Lucene.Net] 2.9.4
I see. It is merely a bug fix, and we would be happy to see it in 2.9.4 too - so we can get it from nuget instead of forking it On Wed, Sep 7, 2011 at 1:46 PM, digy digy digyd...@gmail.com wrote: Since it includes some level of divergence from java I committed it to only 2.9.4g branch. https://issues.apache.org/jira/browse/LUCENE-1930 https://issues.apache.org/jira/browse/LUCENENET-431 DIGY On Wed, Sep 7, 2011 at 1:03 PM, Itamar Syn-Hershko ita...@code972.com wrote: Ok, core compiles, and all tests pass. We are now running long tests to measure memory usage among other things. There is one show stopper tho. There was a patch sent by Matt Warren for Spatial.Net, that doesn't seem to be in. See http://groups.google.com/group/ravendb/msg/7517f095810c48f3 Any chance you can get it in to 2.9.4? On Wed, Sep 7, 2011 at 1:01 AM, Itamar Syn-Hershko ita...@code972.com wrote: Ok, great, we will run RavenDB on top of 2.9.4 in the next few days and will let you know how it went. On Tue, Sep 6, 2011 at 8:59 PM, Michael Herndon mhern...@wickedsoftware.net wrote: I can't tell if the apache git mirror is updated via scheduler or from commit hooks, but its generally stays close to being on par with svn. I'll check next time I push something to svn. But both of those items have made it to the mirror. - michael On Tue, Sep 6, 2011 at 1:44 PM, Digy digyd...@gmail.com wrote: I don't know how often github mirror is updated. These are the original locations 2.9.4 https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/ 2.9.4g https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_ 9_4g/ Both versions include ThreadLocal fix + Signing. Thanks, DIGY -Original Message- From: itamar.synhers...@gmail.com [mailto: itamar.synhers...@gmail.com ] On Behalf Of Itamar Syn-Hershko Sent: Tuesday, September 06, 2011 2:34 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 Not a problem, we will test RavenDB on a separate branch, also for potential memory leaks Digy, can you make sure the github mirror contains an updated 2.9.4 tag I can pull from, which includes the latest ThreadLocal fix + the strongly signed patch applied to it? 2011/9/6 Digy digyd...@gmail.com To avoid misunderstanding... Community==all Lucene.Net users DIGY -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Monday, September 05, 2011 11:46 PM To: 'lucene-net-dev@lucene.apache.org' Subject: RE: [Lucene.Net] 2.9.4 Not bad idea, but I would prefer community's feedback instead of testing against all projects using Lucene.Net DIGY -Original Message- From: Matt Warren [mailto:mattd...@gmail.com] Sent: Monday, September 05, 2011 11:09 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 If you want to test it against a large project you could take a look at how RavenDB uses it? At the moment it's using 2.9.2 ( https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2 ) but if you were to recompile it against 2.9.4 and check that all it's unit-tests still run that would give you quite a large test case. On 5 September 2011 19:22, Prescott Nasser geobmx...@hotmail.com wrote: Hey All, How do people feel about the 2.9.4 code base? I've been using it for sometime, for my use cases it's be excellent. Do we feel we are ready to package this up and make it an official release? Or do we have some tasks left to take care of? ~Prescott
RE: [Lucene.Net] 2.9.4
I don't know how often github mirror is updated. These are the original locations 2.9.4 https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/ 2.9.4g https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_ 9_4g/ Both versions include ThreadLocal fix + Signing. Thanks, DIGY -Original Message- From: itamar.synhers...@gmail.com [mailto:itamar.synhers...@gmail.com] On Behalf Of Itamar Syn-Hershko Sent: Tuesday, September 06, 2011 2:34 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 Not a problem, we will test RavenDB on a separate branch, also for potential memory leaks Digy, can you make sure the github mirror contains an updated 2.9.4 tag I can pull from, which includes the latest ThreadLocal fix + the strongly signed patch applied to it? 2011/9/6 Digy digyd...@gmail.com To avoid misunderstanding... Community==all Lucene.Net users DIGY -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Monday, September 05, 2011 11:46 PM To: 'lucene-net-dev@lucene.apache.org' Subject: RE: [Lucene.Net] 2.9.4 Not bad idea, but I would prefer community's feedback instead of testing against all projects using Lucene.Net DIGY -Original Message- From: Matt Warren [mailto:mattd...@gmail.com] Sent: Monday, September 05, 2011 11:09 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 If you want to test it against a large project you could take a look at how RavenDB uses it? At the moment it's using 2.9.2 ( https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2 ) but if you were to recompile it against 2.9.4 and check that all it's unit-tests still run that would give you quite a large test case. On 5 September 2011 19:22, Prescott Nasser geobmx...@hotmail.com wrote: Hey All, How do people feel about the 2.9.4 code base? I've been using it for sometime, for my use cases it's be excellent. Do we feel we are ready to package this up and make it an official release? Or do we have some tasks left to take care of? ~Prescott
RE: [Lucene.Net] 2.9.4
Also +1 - but I don't mind waiting to hear back regarding the RavenDB stuff - but we can prepare assuming it's all good. Digy can you elaborate on 414 (https://issues.apache.org/jira/browse/LUCENENET-414). I must not have understood the complaint/question as adding that one method to me doesn't seem to resolve the issue brought up Thanks, ~P From: digyd...@gmail.com To: lucene-net-dev@lucene.apache.org Date: Tue, 6 Sep 2011 23:14:37 +0300 Subject: RE: [Lucene.Net] 2.9.4 +1 for an official release. DIGY -Original Message- From: Prescott Nasser [mailto:geobmx...@hotmail.com] Sent: Monday, September 05, 2011 9:22 PM To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org Subject: [Lucene.Net] 2.9.4 Hey All, How do people feel about the 2.9.4 code base? I've been using it for sometime, for my use cases it's be excellent. Do we feel we are ready to package this up and make it an official release? Or do we have some tasks left to take care of? ~Prescott = - Bu iletide virüs bulunamadı. AVG tarafından kontrol edildi - www.avg.com Sürüm: 2012.0.1796 / Virüs Veritabanı: 2082/4478 - Sürüm Tarihi: 05.09.2011
Re: [Lucene.Net] 2.9.4
Ok, great, we will run RavenDB on top of 2.9.4 in the next few days and will let you know how it went. On Tue, Sep 6, 2011 at 8:59 PM, Michael Herndon mhern...@wickedsoftware.net wrote: I can't tell if the apache git mirror is updated via scheduler or from commit hooks, but its generally stays close to being on par with svn. I'll check next time I push something to svn. But both of those items have made it to the mirror. - michael On Tue, Sep 6, 2011 at 1:44 PM, Digy digyd...@gmail.com wrote: I don't know how often github mirror is updated. These are the original locations 2.9.4 https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/ 2.9.4g https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_ 9_4g/ Both versions include ThreadLocal fix + Signing. Thanks, DIGY -Original Message- From: itamar.synhers...@gmail.com [mailto:itamar.synhers...@gmail.com] On Behalf Of Itamar Syn-Hershko Sent: Tuesday, September 06, 2011 2:34 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 Not a problem, we will test RavenDB on a separate branch, also for potential memory leaks Digy, can you make sure the github mirror contains an updated 2.9.4 tag I can pull from, which includes the latest ThreadLocal fix + the strongly signed patch applied to it? 2011/9/6 Digy digyd...@gmail.com To avoid misunderstanding... Community==all Lucene.Net users DIGY -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Monday, September 05, 2011 11:46 PM To: 'lucene-net-dev@lucene.apache.org' Subject: RE: [Lucene.Net] 2.9.4 Not bad idea, but I would prefer community's feedback instead of testing against all projects using Lucene.Net DIGY -Original Message- From: Matt Warren [mailto:mattd...@gmail.com] Sent: Monday, September 05, 2011 11:09 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 If you want to test it against a large project you could take a look at how RavenDB uses it? At the moment it's using 2.9.2 ( https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2 ) but if you were to recompile it against 2.9.4 and check that all it's unit-tests still run that would give you quite a large test case. On 5 September 2011 19:22, Prescott Nasser geobmx...@hotmail.com wrote: Hey All, How do people feel about the 2.9.4 code base? I've been using it for sometime, for my use cases it's be excellent. Do we feel we are ready to package this up and make it an official release? Or do we have some tasks left to take care of? ~Prescott
Re: [Lucene.Net] 2.9.4
Should we put together a quick release checklist ? * I know that jira 407 mentions putting out a 2.9.2 build that is signed when releasing 2.9.4 * We should be able to build a chm doc website using sandcastle.The downside is the website that gets built now requires asp.net instead of just vanilla HTML and I have yet to find an option that allows just HTML. Depending on what we do with this, we would need to remove the link to the docs in the README file inside of trunk. * Stefan Bodewig might still be away and I think we need his vote on the release when the time comes. (correct me, because I could be uber wrong). If there is anything that requires work and you think I can help with in order to get this release out the door, just let me know. - Michael On Tue, Sep 6, 2011 at 9:11 PM, Prescott Nasser geobmx...@hotmail.comwrote: Also +1 - but I don't mind waiting to hear back regarding the RavenDB stuff - but we can prepare assuming it's all good. Digy can you elaborate on 414 ( https://issues.apache.org/jira/browse/LUCENENET-414). I must not have understood the complaint/question as adding that one method to me doesn't seem to resolve the issue brought up Thanks, ~P From: digyd...@gmail.com To: lucene-net-dev@lucene.apache.org Date: Tue, 6 Sep 2011 23:14:37 +0300 Subject: RE: [Lucene.Net] 2.9.4 +1 for an official release. DIGY -Original Message- From: Prescott Nasser [mailto:geobmx...@hotmail.com] Sent: Monday, September 05, 2011 9:22 PM To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org Subject: [Lucene.Net] 2.9.4 Hey All, How do people feel about the 2.9.4 code base? I've been using it for sometime, for my use cases it's be excellent. Do we feel we are ready to package this up and make it an official release? Or do we have some tasks left to take care of? ~Prescott = - Bu iletide virüs bulunamadı. AVG tarafından kontrol edildi - www.avg.com Sürüm: 2012.0.1796 / Virüs Veritabanı: 2082/4478 - Sürüm Tarihi: 05.09.2011
Re: [Lucene.Net] 2.9.4
On 2011-09-07, Michael Herndon wrote: Stefan Bodewig might still be away He is back ;-) and I think we need his vote on the release when the time comes. (correct me, because I could be uber wrong). For the release you need three +1s by Incubator PMC members. After voting here a second vote will happen on the general list where the missing IPMC member votes can be collected. Of course it will be easier if the mentors (Benson, Gianugo and myself in this case) have already voted. Stefan
RE: [Lucene.Net] 2.9.4
To avoid misunderstanding... Community==all Lucene.Net users DIGY -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Monday, September 05, 2011 11:46 PM To: 'lucene-net-dev@lucene.apache.org' Subject: RE: [Lucene.Net] 2.9.4 Not bad idea, but I would prefer community's feedback instead of testing against all projects using Lucene.Net DIGY -Original Message- From: Matt Warren [mailto:mattd...@gmail.com] Sent: Monday, September 05, 2011 11:09 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 If you want to test it against a large project you could take a look at how RavenDB uses it? At the moment it's using 2.9.2 ( https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2 ) but if you were to recompile it against 2.9.4 and check that all it's unit-tests still run that would give you quite a large test case. On 5 September 2011 19:22, Prescott Nasser geobmx...@hotmail.com wrote: Hey All, How do people feel about the 2.9.4 code base? I've been using it for sometime, for my use cases it's be excellent. Do we feel we are ready to package this up and make it an official release? Or do we have some tasks left to take care of? ~Prescott - Bu iletide virüs bulunamadı. AVG tarafından kontrol edildi - www.avg.com Sürüm: 2012.0.1796 / Virüs Veritabanı: 2082/4478 - Sürüm Tarihi: 05.09.2011
RE: [Lucene.Net] 2.9.4
Yeah, I looked at it as 2.9.4 has been around a while, I've been using it for a while, and I assume others have as well, and we haven't had any complaints (few exceptions). I hope people aren't waiting for a last call to provide feedback. It should be continous. When it dies down, I assume issues are shaken out and things are somewhat vetted. ~P From: digyd...@gmail.com To: lucene-net-dev@lucene.apache.org Date: Tue, 6 Sep 2011 00:48:02 +0300 Subject: RE: [Lucene.Net] 2.9.4 To avoid misunderstanding... Community==all Lucene.Net users DIGY -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Monday, September 05, 2011 11:46 PM To: 'lucene-net-dev@lucene.apache.org' Subject: RE: [Lucene.Net] 2.9.4 Not bad idea, but I would prefer community's feedback instead of testing against all projects using Lucene.Net DIGY -Original Message- From: Matt Warren [mailto:mattd...@gmail.com] Sent: Monday, September 05, 2011 11:09 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 If you want to test it against a large project you could take a look at how RavenDB uses it? At the moment it's using 2.9.2 ( https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2 ) but if you were to recompile it against 2.9.4 and check that all it's unit-tests still run that would give you quite a large test case. On 5 September 2011 19:22, Prescott Nasser geobmx...@hotmail.com wrote: Hey All, How do people feel about the 2.9.4 code base? I've been using it for sometime, for my use cases it's be excellent. Do we feel we are ready to package this up and make it an official release? Or do we have some tasks left to take care of? ~Prescott - Bu iletide virüs bulunamadı. AVG tarafından kontrol edildi - www.avg.com Sürüm: 2012.0.1796 / Virüs Veritabanı: 2082/4478 - Sürüm Tarihi: 05.09.2011
Re: [Lucene.Net] 2.9.4
Not a problem, we will test RavenDB on a separate branch, also for potential memory leaks Digy, can you make sure the github mirror contains an updated 2.9.4 tag I can pull from, which includes the latest ThreadLocal fix + the strongly signed patch applied to it? 2011/9/6 Digy digyd...@gmail.com To avoid misunderstanding... Community==all Lucene.Net users DIGY -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Monday, September 05, 2011 11:46 PM To: 'lucene-net-dev@lucene.apache.org' Subject: RE: [Lucene.Net] 2.9.4 Not bad idea, but I would prefer community's feedback instead of testing against all projects using Lucene.Net DIGY -Original Message- From: Matt Warren [mailto:mattd...@gmail.com] Sent: Monday, September 05, 2011 11:09 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 2.9.4 If you want to test it against a large project you could take a look at how RavenDB uses it? At the moment it's using 2.9.2 ( https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2 ) but if you were to recompile it against 2.9.4 and check that all it's unit-tests still run that would give you quite a large test case. On 5 September 2011 19:22, Prescott Nasser geobmx...@hotmail.com wrote: Hey All, How do people feel about the 2.9.4 code base? I've been using it for sometime, for my use cases it's be excellent. Do we feel we are ready to package this up and make it an official release? Or do we have some tasks left to take care of? ~Prescott - Bu iletide virüs bulunamadı. AVG tarafından kontrol edildi - www.avg.com Sürüm: 2012.0.1796 / Virüs Veritabanı: 2082/4478 - Sürüm Tarihi: 05.09.2011
