Lucene.Net, mail # dev - Re: [Lucene.Net] 2.9.4

RE: [Lucene.Net] 2.9.4

Prescott Nasser 2011-10-03, 16:13

I was looking into the possibility of making it cls compliant - but that's really out the window for this. I think we're ready, i just dont know the procedures to call a vote.

Sent from my Windows Phone
________________________________
From: Itamar Syn-Hershko
Sent: 10/3/2011 2:08 AM
To: [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] 2.9.4

Hi guys,

What's the status of this? Is there anything I can do to help to wrap
everything up and make a release?

You can also grab whatever you want from
https://github.com/synhershko/Lucene.Net.Contrib - send me the docs you want
me to sign.

Itamar.

On Tue, Sep 20, 2011 at 11:48 PM, Prescott Nasser <[EMAIL PROTECTED]>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

Stefan Bodewig 2011-10-04, 04:30

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

Digy 2011-09-05, 20:45

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:[EMAIL PROTECTED]]
Sent: Monday, September 05, 2011 11:09 PM
To: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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

Prescott Nasser 2011-09-07, 01:11

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: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> 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:[EMAIL PROTECTED]]
> Sent: Monday, September 05, 2011 9:22 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> 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

Michael Herndon 2011-09-07, 03:53

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 <[EMAIL PROTECTED]>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: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > 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:[EMAIL PROTECTED]]
> > Sent: Monday, September 05, 2011 9:22 PM
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > 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

digy digy 2011-09-07, 07:22

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 <[EMAIL PROTECTED]>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: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > 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:[EMAIL PROTECTED]]
> > Sent: Monday, September 05, 2011 9:22 PM
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > 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

Itamar Syn-Hershko 2011-09-07, 09:17

What version is going to make it to nuget? 2.9.4 or 2.9.4g?

2011/9/7 digy digy <[EMAIL PROTECTED]>

> 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 <[EMAIL PROTECTED]
> >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: [EMAIL PROTECTED]
> > > To: [EMAIL PROTECTED]
> > > 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:[EMAIL PROTECTED]]
> > > Sent: Monday, September 05, 2011 9:22 PM
> > > To: [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> > > 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

Digy 2011-09-05, 21:48

To avoid misunderstanding...

Community==all Lucene.Net users

DIGY

-----Original Message-----
From: Digy [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 05, 2011 11:46 PM
To: '[EMAIL PROTECTED]'
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:[EMAIL PROTECTED]]
Sent: Monday, September 05, 2011 11:09 PM
To: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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

Prescott Nasser 2011-09-06, 01:44

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: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> 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:[EMAIL PROTECTED]]
> Sent: Monday, September 05, 2011 11:46 PM
> To: '[EMAIL PROTECTED]'
> 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:[EMAIL PROTECTED]]
> Sent: Monday, September 05, 2011 11:09 PM
> To: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]> 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

Itamar Syn-Hershko 2011-09-05, 23:33

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 <[EMAIL PROTECTED]>

> To avoid misunderstanding...
>
> Community==all Lucene.Net users
>
> DIGY
>
> -----Original Message-----
> From: Digy [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 05, 2011 11:46 PM
> To: '[EMAIL PROTECTED]'
> 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:[EMAIL PROTECTED]]
> Sent: Monday, September 05, 2011 11:09 PM
> To: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]> 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

Digy 2011-09-06, 17:44

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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of Itamar Syn-Hershko
Sent: Tuesday, September 06, 2011 2:34 AM
To: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>

> To avoid misunderstanding...
>
> Community==all Lucene.Net users
>
> DIGY
>
> -----Original Message-----
> From: Digy [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 05, 2011 11:46 PM
> To: '[EMAIL PROTECTED]'
> 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:[EMAIL PROTECTED]]
> Sent: Monday, September 05, 2011 11:09 PM
> To: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]> 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

Michael Herndon 2011-09-06, 17:59

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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
> Behalf Of Itamar Syn-Hershko
> Sent: Tuesday, September 06, 2011 2:34 AM
> To: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]>
>
> > To avoid misunderstanding...
> >
> > Community==all Lucene.Net users
> >
> > DIGY
> >
> > -----Original Message-----
> > From: Digy [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, September 05, 2011 11:46 PM
> > To: '[EMAIL PROTECTED]'
> > 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:[EMAIL PROTECTED]]
> > Sent: Monday, September 05, 2011 11:09 PM
> > To: [EMAIL PROTECTED]
> > 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 <[EMAIL PROTECTED]>
> 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

Itamar Syn-Hershko 2011-09-06, 22:01

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 <[EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> On
> > Behalf Of Itamar Syn-Hershko
> > Sent: Tuesday, September 06, 2011 2:34 AM
> > To: [EMAIL PROTECTED]
> > 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 <[EMAIL PROTECTED]>
> >
> > > To avoid misunderstanding...
> > >
> > > Community==all Lucene.Net users
> > >
> > > DIGY
> > >
> > > -----Original Message-----
> > > From: Digy [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, September 05, 2011 11:46 PM
> > > To: '[EMAIL PROTECTED]'
> > > 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:[EMAIL PROTECTED]]
> > > Sent: Monday, September 05, 2011 11:09 PM
> > > To: [EMAIL PROTECTED]
> > > 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 <[EMAIL PROTECTED]>
> > 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

Itamar Syn-Hershko 2011-09-07, 10:03

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 <[EMAIL PROTECTED]>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 <
> [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>> On
>> > Behalf Of Itamar Syn-Hershko
>> > Sent: Tuesday, September 06, 2011 2:34 AM
>> > To: [EMAIL PROTECTED]
>> > 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 <[EMAIL PROTECTED]>
>> >
>> > > To avoid misunderstanding...
>> > >
>> > > Community==all Lucene.Net users
>> > >
>> > > DIGY
>> > >
>> > > -----Original Message-----
>> > > From: Digy [mailto:[EMAIL PROTECTED]]
>> > > Sent: Monday, September 05, 2011 11:46 PM
>> > > To: '[EMAIL PROTECTED]'
>> > > 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:[EMAIL PROTECTED]]
>> > > Sent: Monday, September 05, 2011 11:09 PM
>> > > To: [EMAIL PROTECTED]
>> > > 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 <[EMAIL PROTECTED]>
>> > 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

digy digy 2011-09-07, 10:46

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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]
> >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 <
> > [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> ]
> >> On
> >> > Behalf Of Itamar Syn-Hershko
> >> > Sent: Tuesday, September 06, 2011 2:34 AM
> >> > To: [EMAIL PROTECTED]
> >> > 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 <[EMAIL PROTECTED]>
> >> >
> >> > > To avoid misunderstanding...
> >> > >
> >> > > Community==all Lucene.Net users
> >> > >
> >> > > DIGY
> >> > >
> >> > > -----Original Message-----
> >> > > From: Digy [mailto:[EMAIL PROTECTED]]
> >> > > Sent: Monday, September 05, 2011 11:46 PM
> >> > > To: '[EMAIL PROTECTED]'
> >> > > 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:[EMAIL PROTECTED]]
> >> > > Sent: Monday, September 05, 2011 11:09 PM
> >> > > To: [EMAIL PROTECTED]
> >> > > 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 <[EMAIL PROTECTED]>
> >> > 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

Re: [Lucene.Net] 2.9.4

Michael Herndon 2011-09-07, 12:12

> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]
> >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 <[EMAIL PROTECTED]
> > >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 <
> > > [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED]
> > ]
> > >> On
> > >> > Behalf Of Itamar Syn-Hershko
> > >> > Sent: Tuesday, September 06, 2011 2:34 AM
> > >> > To: [EMAIL PROTECTED]
> > >> > 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 <[EMAIL PROTECTED]>
> > >> >
> > >> > > To avoid misunderstanding...
> > >> > >
> > >> > > Community==all Lucene.Net users
> > >> > >
> > >> > > DIGY
> > >> > >
> > >> > > -----Original Message-----
> > >> > > From: Digy [mailto:[EMAIL PROTECTED]]
> > >> > > Sent: Monday, September 05, 2011 11:46 PM
> > >> > > To: '[EMAIL PROTECTED]'
> > >> > > 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:[EMAIL PROTECTED]]
> > >> > > Sent: Monday, September 05, 2011 11:09 PM
> > >> > > To: [EMAIL PROTECTED]
> > >> > > 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.

Re: [Lucene.Net] 2.9.4

Itamar Syn-Hershko 2011-09-07, 12:07

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]
> >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 <[EMAIL PROTECTED]
> > >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 <
> > > [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED]
> > ]
> > >> On
> > >> > Behalf Of Itamar Syn-Hershko
> > >> > Sent: Tuesday, September 06, 2011 2:34 AM
> > >> > To: [EMAIL PROTECTED]
> > >> > 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 <[EMAIL PROTECTED]>
> > >> >
> > >> > > To avoid misunderstanding...
> > >> > >
> > >> > > Community==all Lucene.Net users
> > >> > >
> > >> > > DIGY
> > >> > >
> > >> > > -----Original Message-----
> > >> > > From: Digy [mailto:[EMAIL PROTECTED]]
> > >> > > Sent: Monday, September 05, 2011 11:46 PM
> > >> > > To: '[EMAIL PROTECTED]'
> > >> > > 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:[EMAIL PROTECTED]]
> > >> > > Sent: Monday, September 05, 2011 11:09 PM
> > >> > > To: [EMAIL PROTECTED]
> > >> > > 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.

RE: [Lucene.Net] 2.9.4

Prescott Nasser 2011-09-07, 14:07

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: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]
> >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 <[EMAIL PROTECTED]
> > >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 <
> > > [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED]
> > ]
> > >> On
> > >> > Behalf Of Itamar Syn-Hershko
> > >> > Sent: Tuesday, September 06, 2011 2:34 AM
> > >> > To: [EMAIL PROTECTED]
> > >> > 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 <[EMAIL PROTECTED]>
> > >> >
> > >> > > To avoid misunderstanding...
> > >> > >
> > >> > > Community==all Lucene.Net users
> > >> > >
> > >> > > DIGY
> > >> > >
> > >> > > -----Original Message-----
> > >> > > From: Digy [mailto:[EMAIL PROTECTED]]
> > >> > > Sent: Monday, September 05, 2011 11:46 PM
> > >> > > To: '[EMAIL PROTECTED]'
> > >> > > 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:[EMAIL PROTECTED]]
> > >> > > Sent: Monday, September 05, 2011 11:09 PM
> > >> > > To: [EMAIL PROTECTED]
> > >> > > 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 (

Re: [Lucene.Net] 2.9.4

Itamar Syn-Hershko 2011-09-10, 17:22

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 <[EMAIL PROTECTED]>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: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]
> > >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 <[EMAIL PROTECTED]
> > > >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 <
> > > > [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:
> > [EMAIL PROTECTED]
> > > ]
> > > >> On
> > > >> > Behalf Of Itamar Syn-Hershko
> > > >> > Sent: Tuesday, September 06, 2011 2:34 AM
> > > >> > To: [EMAIL PROTECTED]
> > > >> > 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 <[EMAIL PROTECTED]>
> > > >> >
> > > >> > > To avoid misunderstanding...
> > > >> > >
> > > >> > > Community==all Lucene.Net users
> > > >> > >
> > > >> > > DIGY
> > > >> > >
> > > >> > > -----Original Message-----
> > > >> > > From: Digy [mailto:[EMAIL PROTECTED]]
> > > >> > > Sent: Monday, September 05, 2011 11:46 PM
> > > >> > > To: '[EMAIL PROTECTED]'
> > > >> > > Subject: RE: [Lucene.Net] 2.9.4
> > > >> > >
> > > >> > > Not bad idea, but I would prefer community's feedback instead of

RE: [Lucene.Net] 2.9.4

Digy 2011-09-10, 17:36

Good news. Thanks Itamar.

DIGY

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of Itamar Syn-Hershko
Sent: Saturday, September 10, 2011 8:23 PM
To: [EMAIL PROTECTED]
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
<[EMAIL PROTECTED]>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: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]
> > >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 <[EMAIL PROTECTED]
> > > >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 <
> > > > [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:
> > [EMAIL PROTECTED]
> > > ]
> > > >> On
> > > >> > Behalf Of Itamar Syn-Hershko
> > > >> > Sent: Tuesday, September 06, 2011 2:34 AM
> > > >> > To: [EMAIL PROTECTED]
> > > >> > 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 <[EMAIL PROTECTED]>
> > > >> >
> > > >> > > To avoid misunderstanding...
> > > >> > >
> > > >> > > Community==all Lucene.Net users
> > > >> > >
> > > >> > > DIGY
> > > >> > >
> > > >> > > -----Original Message-----
> > > >> > > From: Digy [mailto:[EMAIL PROTECTED]]
of
https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2
all
have
Checked by AVG - www.avg.com
Version: 2012.0.1796 / Virus Database: 2082/4488 - Release Date: 09/10/11

RE: [Lucene.Net] 2.9.4

Prescott Nasser 2011-09-11, 17:22

Thanks Itamar!

----------------------------------------
> Date: Sat, 10 Sep 2011 20:22:59 +0300
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]>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: [EMAIL PROTECTED]
> > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]
> > > >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 <[EMAIL PROTECTED]
> > > > >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 <
> > > > > [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:
> > > [EMAIL PROTECTED]
> > > > ]
> > > > >> On
> > > > >> > Behalf Of Itamar Syn-Hershko
> > > > >> > Sent: Tuesday, September 06, 2011 2:34 AM
> > > > >> > To: [EMAIL PROTECTED]
> > > > >> > 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 <[EMAIL PROTECTED]>
> > > > >> >
> > > > >> > > To avoid misunderstanding...
>

Re: [Lucene.Net] 2.9.4

Itamar Syn-Hershko 2011-09-12, 14:45

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 <[EMAIL PROTECTED]>wrote:

>
> Thanks Itamar!
>
> ----------------------------------------
> > Date: Sat, 10 Sep 2011 20:22:59 +0300
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > 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 <[EMAIL PROTECTED]
> >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: [EMAIL PROTECTED]
> > > 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 <[EMAIL PROTECTED]> 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 <
> [EMAIL PROTECTED]
> > > > >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 <
> [EMAIL PROTECTED]
> > > > > >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 <
> > > > > > [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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: [EMAIL PROTECTED] [mailto:
> > > > [EMAIL PROTECTED]
> > > > > ]
> > > > > >> On
> > > > > >> > Behalf Of Itamar Syn-Hershko
> > > > > >> > Sent: Tuesday, September 06, 2011 2:34 AM
> > > > > >> > To: [EMAIL PROTECTED]
> > > > > >> > Subject: Re: [Lucene.Net] 2.9.4

Re: [Lucene.Net] 2.9.4

Michael Herndon 2011-09-20, 22:29

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 <[EMAIL PROTECTED]>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

Itamar Syn-Hershko 2011-09-20, 22:43

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 <
[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]
> >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

Prescott Nasser 2011-09-21, 03:38

>
> 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 <[EMAIL PROTECTED]>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

Michael Herndon 2011-09-21, 04:15

>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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]
> >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

Troy Howard 2011-09-21, 04:37

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
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]
>> >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

Michael Herndon 2011-09-21, 04:48

Could we store sandcastle docs as a single zip/chm?

On Wed, Sep 21, 2011 at 12:37 AM, Troy Howard <[EMAIL PROTECTED]> 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
> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]
> >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 <
> [EMAIL PROTECTED]
> >> >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

Troy Howard 2011-09-21, 04:56

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
<[EMAIL PROTECTED]> wrote:
> Could we store sandcastle docs as a single zip/chm?
>
>
>
> On Wed, Sep 21, 2011 at 12:37 AM, Troy Howard <[EMAIL PROTECTED]> 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
>> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]
>> >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:

Re: [Lucene.Net] 2.9.4

Michael Herndon 2011-09-21, 05:40

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 <[EMAIL PROTECTED]> 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
> <[EMAIL PROTECTED]> wrote:
> > Could we store sandcastle docs as a single zip/chm?
> >
> >
> >
> > On Wed, Sep 21, 2011 at 12:37 AM, Troy Howard <[EMAIL PROTECTED]>
> 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
> >> <[EMAIL PROTECTED]> 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

Re: [Lucene.Net] 2.9.4

Troy Howard 2011-09-21, 10:10

My opinion is that:

SVN should not hold generated files, including XML/HTML docs.

The *binary* release packages should contain the .xml files so that VS
can intellisense intelligently against the DLLs, and that HTML docs
should be included so they are available online or offline.

But... online HTML should be the gold standard, and be up to date w/
SVN at all times via post-commit hooks that trigger Sandcastle
rebuilds.

-T
On Tue, Sep 20, 2011 at 10:40 PM, Michael Herndon
<[EMAIL PROTECTED]> wrote:
> 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 <[EMAIL PROTECTED]> 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
>> <[EMAIL PROTECTED]> wrote:
>> > Could we store sandcastle docs as a single zip/chm?
>> >
>> >
>> >
>> > On Wed, Sep 21, 2011 at 12:37 AM, Troy Howard <[EMAIL PROTECTED]>
>> 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
>> >> <[EMAIL PROTECTED]> 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

Re: [Lucene.Net] 2.9.4

Michael Herndon 2011-09-24, 05:42

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 <[EMAIL PROTECTED]> 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
> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]
> >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 <
> [EMAIL PROTECTED]
> >> >wrote:
> >> >

Re: [Lucene.Net] 2.9.4

Robert Jordan 2011-09-21, 12:08

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/c5218bca56c19b3407648224781eec7316994a39

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/23ea6f52362fc7dbce48fd012cea129a7350c73c

Did we agree about abandoning .NET <= 3.5?

Robert

Re: [Lucene.Net] 2.9.4

Michael Herndon 2011-09-21, 15:30

@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 <[EMAIL PROTECTED]> 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

Digy 2011-09-21, 21:38

@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:[EMAIL PROTECTED]]
Sent: Wednesday, September 21, 2011 3:09 PM
To: [EMAIL PROTECTED]
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

Robert Jordan 2011-09-21, 22:16

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:[EMAIL PROTECTED]]
> Sent: Wednesday, September 21, 2011 3:09 PM
> To: [EMAIL PROTECTED]
> 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

Robert Jordan 2011-09-21, 22:22

On 22.09.2011 00:16, Robert Jordan wrote:
> 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.

Scratch this. The whole point of ThreadLocal<T> is actually
Init(). Sorry for the noise :)

Robert

RE: [Lucene.Net] 2.9.4

Digy 2011-09-21, 22:57

I think, there was a sync problem between our eMails :(

DIGY

-----Original Message-----
From: Robert Jordan [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 22, 2011 1:22 AM
To: [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] 2.9.4

On 22.09.2011 00:16, Robert Jordan wrote:
> 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.

Scratch this. The whole point of ThreadLocal<T> is actually
Init(). Sorry for the noise :)

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

Digy 2011-09-21, 22:34

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:[EMAIL PROTECTED]]
Sent: Thursday, September 22, 2011 1:16 AM
To: [EMAIL PROTECTED]
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:[EMAIL PROTECTED]]
> Sent: Wednesday, September 21, 2011 3:09 PM
> To: [EMAIL PROTECTED]
> 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

Digy 2011-09-21, 22:38

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:[EMAIL PROTECTED]]
Sent: Thursday, September 22, 2011 1:16 AM
To: [EMAIL PROTECTED]
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:[EMAIL PROTECTED]]
> Sent: Wednesday, September 21, 2011 3:09 PM
> To: [EMAIL PROTECTED]
> 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

Prescott Nasser 2011-09-21, 16:47

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: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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

Michael Herndon 2011-09-21, 17:15

if thats the case, then well need conditional statements for including
ThreadLocal<T>

On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser <[EMAIL PROTECTED]>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: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]> 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

Troy Howard 2011-09-21, 17:36

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
<[EMAIL PROTECTED]> wrote:
> if thats the case, then well need conditional statements for including
> ThreadLocal<T>
>
> On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser <[EMAIL PROTECTED]>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: [EMAIL PROTECTED]
>> Cc: [EMAIL PROTECTED]
>> 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 <[EMAIL PROTECTED]> 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

Michael Herndon 2011-09-21, 19:40

@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 <[EMAIL PROTECTED]> 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
> <[EMAIL PROTECTED]> wrote:
> > if thats the case, then well need conditional statements for including
> > ThreadLocal<T>
> >
> > On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser <[EMAIL PROTECTED]
> >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: [EMAIL PROTECTED]
> >> Cc: [EMAIL PROTECTED]
> >> 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 <[EMAIL PROTECTED]> 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

Digy 2011-09-21, 21:19

> 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:[EMAIL PROTECTED]]
Sent: Wednesday, September 21, 2011 10:40 PM
To: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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
> <[EMAIL PROTECTED]> wrote:
> > if thats the case, then well need conditional statements for including
> > ThreadLocal<T>
> >
> > On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser <[EMAIL PROTECTED]
> >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: [EMAIL PROTECTED]
> >> Cc: [EMAIL PROTECTED]
> >> 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 <[EMAIL PROTECTED]> 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 Jordan 2011-09-21, 21:59

On 21.09.2011 21:40, Michael Herndon wrote:
> @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 .

The Highlighter tests are probably failing due to a
missing

SetMultiTermRewriteMethod(MultiTermQuery.SCORING_BOOLEAN_QUERY_REWRITE):

https://github.com/robert-j/lucene.net/commit/a4cdf4bb613770913af1bf9d546d6499bed452bf

Robert
>
> 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<[EMAIL PROTECTED]> 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
>> <[EMAIL PROTECTED]> wrote:
>>> if thats the case, then well need conditional statements for including
>>> ThreadLocal<T>
>>>
>>> On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser<[EMAIL PROTECTED]
>>> 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: [EMAIL PROTECTED]
>>>> Cc: [EMAIL PROTECTED]
>>>> 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<[EMAIL PROTECTED]> 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 Nasser 2011-09-23, 03:14

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 <[EMAIL PROTECTED]> 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
> > <[EMAIL PROTECTED]> wrote:
> > > if thats the case, then well need conditional statements for including
> > > ThreadLocal<T>
> > >
> > > On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser <[EMAIL PROTECTED]
> > >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: [EMAIL PROTECTED]
> > >> Cc: [EMAIL PROTECTED]
> > >> 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 <[EMAIL PROTECTED]> 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 Nasser 2011-09-23, 03:20

The line before had volatile in it..

private volatile System.IO.StreamWriter infoStream;

----------------------------------------
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]> 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
> > > <[EMAIL PROTECTED]> wrote:
> > > > if thats the case, then well need conditional statements for including
> > > > ThreadLocal<T>
> > > >
> > > > On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser <[EMAIL PROTECTED]
> > > >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: [EMAIL PROTECTED]
> > > >> Cc: [EMAIL PROTECTED]
> > > >> 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 <[EMAIL PROTECTED]> 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

Nicholas Paldino [.NET/C ... 2011-09-23, 03:58

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>>> <[EMAIL PROTECTED]> wrote:
>>>> if thats the case, then well need conditional statements for including
>>>> ThreadLocal<T>
>>>>
>>>> On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser <[EMAIL PROTECTED]
>>>> 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: [EMAIL PROTECTED]
>>>>> Cc: [EMAIL PROTECTED]
>>>>> 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 <[EMAIL PROTECTED]> 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:

RE: [Lucene.Net] 2.9.4

Prescott Nasser 2011-09-23, 04:16

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: [EMAIL PROTECTED]
> From: [EMAIL PROTECTED]
> Date: Thu, 22 Sep 2011 23:58:42 -0400
> To: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
> >>> <[EMAIL PROTECTED]> wrote:
> >>>> if thats the case, then well need conditional statements for including
> >>>> ThreadLocal<T>
> >>>>
> >>>> On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser <[EMAIL PROTECTED]
> >>>> 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: [EMAIL PROTECTED]
> >>>>> Cc: [EMAIL PROTECTED]
> >>>>> 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 <[EMAIL PROTECTED]> wrote:
> >>>>>
> >>>>>> On 20.09.2011 23:48, Prescott Nasser wrote:

RE: [Lucene.Net] 2.9.4

Prescott Nasser 2011-09-22, 21:01

This is what I thought - is that good by everyone?

Sent from my Windows Phone

-----Original Message-----
From: Troy Howard
Sent: Wednesday, September 21, 2011 10:36 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: 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
<[EMAIL PROTECTED]> wrote:
> if thats the case, then well need conditional statements for including
> ThreadLocal<T>
>
> On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser <[EMAIL PROTECTED]>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: [EMAIL PROTECTED]
>> Cc: [EMAIL PROTECTED]
>> 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 <[EMAIL PROTECTED]> 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

casperOne@...) 2011-09-23, 13:05

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" <[EMAIL PROTECTED]>

Sent: Friday, September 23, 2011 1:17 AM

To: [EMAIL PROTECTED]

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: [EMAIL PROTECTED]

> From: [EMAIL PROTECTED]

> Date: Thu, 22 Sep 2011 23:58:42 -0400

> To: [EMAIL PROTECTED]

> 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 <[EMAIL PROTECTED]>
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

access

access
wrote:

including

<[EMAIL PROTECTED]

to

into

wrote:
positive

https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec
7316994a39
https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a
40e201d663

https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a
7350c73c

RE: [Lucene.Net] 2.9.4

Prescott Nasser 2011-09-23, 13:30

That helps thanks. No Jira although I will put one in.

Sent from my Windows Phone

-----Original Message-----
From: [EMAIL PROTECTED]
Sent: Friday, September 23, 2011 6:05 AM
To: [EMAIL PROTECTED]
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" <[EMAIL PROTECTED]>

Sent: Friday, September 23, 2011 1:17 AM

To: [EMAIL PROTECTED]

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: [EMAIL PROTECTED]

> From: [EMAIL PROTECTED]

> Date: Thu, 22 Sep 2011 23:58:42 -0400

> To: [EMAIL PROTECTED]

> 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 <[EMAIL PROTECTED]>
wrote:

>

> >

> > Before I go replacing all the volatile fields I wanted to run this past
the list:

access

access
wrote:

including

<[EMAIL PROTECTED]

to

into

wrote:
positive

https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec
7316994a39
https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a
40e201d663

https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a
7350c73c

RE: [Lucene.Net] 2.9.4

casperOne@...) 2011-09-23, 13:33

NP

----------------------------------------

From: "Prescott Nasser" <[EMAIL PROTECTED]>

Sent: Friday, September 23, 2011 9:31 AM

To: [EMAIL PROTECTED], [EMAIL PROTECTED]

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: [EMAIL PROTECTED]

Sent: Friday, September 23, 2011 6:05 AM

To: [EMAIL PROTECTED]

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" <[EMAIL PROTECTED]>
Sent: Friday, September 23, 2011 1:17 AM
To: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
> From: [EMAIL PROTECTED]
> Date: Thu, 22 Sep 2011 23:58:42 -0400
> To: [EMAIL PROTECTED]
> 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.

wrote:
past

the list:

access

access

wrote:

including

<[EMAIL PROTECTED]

to

into

wrote:

positive

https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec
7316994a39

https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a
40e201d663

https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a
7350c73c

RE: [Lucene.Net] 2.9.4

Prescott Nasser 2011-10-01, 23:31

Alright, I've really dug into changing a lot of the non CLS stuff - but I don't think it's worth doing for 2.9.4. Please see https://issues.apache.org/jira/browse/LUCENENET-446 for more details.

Unless anyone disagrees and still thinks we should attempt to clear the CLS warnings - is there anything else holding us up from a 2.9.4 release at this point?

~P
----------------------------------------
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Date: Fri, 23 Sep 2011 06:33:03 -0700
> Subject: RE: [Lucene.Net] 2.9.4
>
> NP
>
> ----------------------------------------
>
> From: "Prescott Nasser" <[EMAIL PROTECTED]>
>
> Sent: Friday, September 23, 2011 9:31 AM
>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
>
> 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: [EMAIL PROTECTED]
>
> Sent: Friday, September 23, 2011 6:05 AM
>
> To: [EMAIL PROTECTED]
>
> 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" <[EMAIL PROTECTED]>
>
>
> Sent: Friday, September 23, 2011 1:17 AM
>
>
> To: [EMAIL PROTECTED]
>
>
> 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();

Re: [Lucene.Net] 2.9.4

Michael Herndon 2011-10-02, 16:48

I'd say the main thing for cls was the mismatch casing of fields/properties.
i.e Something like public type fieldName; and public type FieldName {
get; set; } on the same class was preventing people from using certain
higher level classes in vb.net

Hopefully the unsigned types are not be high level enough for anyone to need
to use/consume directly.
On Sat, Oct 1, 2011 at 7:31 PM, Prescott Nasser <[EMAIL PROTECTED]>wrote:

>
> Alright, I've really dug into changing a lot of the non CLS stuff - but I
> don't think it's worth doing for 2.9.4. Please see
> https://issues.apache.org/jira/browse/LUCENENET-446 for more details.
>
>
>
> Unless anyone disagrees and still thinks we should attempt to clear the CLS
> warnings - is there anything else holding us up from a 2.9.4 release at this
> point?
>
>
>
> ~P
>
>
> ----------------------------------------
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Date: Fri, 23 Sep 2011 06:33:03 -0700
> > Subject: RE: [Lucene.Net] 2.9.4
> >
> > NP
> >
> > ----------------------------------------
> >
> > From: "Prescott Nasser" <[EMAIL PROTECTED]>
> >
> > Sent: Friday, September 23, 2011 9:31 AM
> >
> > To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> >
> > 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: [EMAIL PROTECTED]
> >
> > Sent: Friday, September 23, 2011 6:05 AM
> >
> > To: [EMAIL PROTECTED]
> >
> > 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" <[EMAIL PROTECTED]>
> >
> >
> > Sent: Friday, September 23, 2011 1:17 AM
> >
> >
> > To: [EMAIL PROTECTED]
> >
> >
> > 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