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 <geobmx...@hotmail.com>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: casper...@caspershouse.com
> > To: geobmx...@hotmail.com; lucene-net-dev@lucene.apache.org
> > Date: Fri, 23 Sep 2011 06:33:03 -0700
> > Subject: RE: [Lucene.Net] 2.9.4
> >
> > NP
> >
> > ----------------------------------------
> >
> > From: "Prescott Nasser" <geobmx...@hotmail.com>
> >
> > Sent: Friday, September 23, 2011 9:31 AM
> >
> > To: lucene-net-dev@lucene.apache.org, casper...@caspershouse.com
> >
> > Subject: RE: [Lucene.Net] 2.9.4
> >
> >
> > That helps thanks. No Jira although I will put one in.
> >
> >
> > Sent from my Windows Phone
> >
> >
> > -----Original Message-----
> >
> > From: casper...@caspershouse.com
> >
> > Sent: Friday, September 23, 2011 6:05 AM
> >
> > To: lucene-net-dev@lucene.apache.org
> >
> > Subject: RE: [Lucene.Net] 2.9.4
> >
> >
> > Prescott,
> >
> >
> > You can do one of two things:
> >
> >
> > - Remove the volatile keyword, but keep the lock statement around the
> >
> > access to the field
> >
> >
> > - Remove the lock, and add the volatile keyword to the field
> >
> >
> > This will allow you to assign to the _infoStream variable (read/write)
> and
> >
> > be sure to have the most up-to-date value in the variable, as well as
> >
> > guarantee atomic reads/writes to that variable.
> >
> >
> > Your example is incorrect. The volatile on "p" only guarantees that
> >
> > reads/writes will be current if p is changed. In other words, if you
> >
> > assign a new person instance to p, you can do so without using a lock
> >
> > statement and guarantee that the reads/writes from p will be atomic.
> >
> >
> > However, any calls you make to p are not protected, not because of
> >
> > volatile. Volatile will *never* be able to protect calls, it only
> > protects
> >
> > variables.
> >
> >
> > Lock, on the other hand, can protect calls, assuming that you cover all
> > the
> >
> > calls with the same lock. You can also group other operations and make
> >
> > sure that synchronization occurs.
> >
> >
> > Note that a lock *only* guarantees atomicity/mutual exclusion; when
> > applied
> >
> > to multiple statements, there's no guarantee that you won't corrupt
> >
> > something. If an exception is thrown inside of a lock statement (the
> >
> > second line in three lines of code in the lock block, for example) then
> > the
> >
> > previous values don't roll back or anything.
> >
> >
> > Because atomicity with a variable assignment is mutually exclusive around
> >
> > *one* operation, there's no chance of corruption.
> >
> >
> > Let me know if you want further clarification.
> >
> >
> > Additionally, if you have a specific patch/issue in JIRA you want me to
> >
> > look at, let me know, I'll let you know if the solution is right from a
> >
> > thread-safety point of view.
> >
> >
> > - Nick
> >
> >
> > ----------------------------------------
> >
> >
> > From: "Prescott Nasser" <geobmx...@hotmail.com>
> >
> >
> > Sent: Friday, September 23, 2011 1:17 AM
> >
> >
> > To: lucene-net-dev@lucene.apache.org
> >
> >
> > Subject: RE: [Lucene.Net] 2.9.4
> >
> >
> > I see, so you're essentially saying, I can simply remove the volatile
> >
> > keyword in this case, and it's exactly the same becuase I am only using
> it
> >
> > for read and writes?
> >
> >
> > So the case I'd need to be more careful of is if an manipulation method
> is
> >
> > called on the object itself - suppose:
> >
> >
> > public person {
> >
> >
> > _name = "Me"
> >
> >
> > public changeName(string n)
> >
> >
> > {
> >
> >
> > _name = n;
> >
> >
> > }
> >
> >
> > }
> >
> >
> > If one were to write
> >
> >
> > public volatile person p = new person();
> >
> >
> > p.changeName("You");
> >
> >
> > the call to the method would in this case need a lock (which volatile
> >
> > gives) to gaurentee that changeName occurs before other items read or
> >
> > overwrite variable p?
> >
> >
> > but a straight read or write won't matter:
> >
> >
> > p = new person();
> >
> >
> > p = new person():
> >
> >
> > x = p;
> >
> >
> > p = new person();
> >
> >
> > Here, I wouldn't need the volatile keyword becuase those are merely reads
> >
> > and wrights?
> >
> >
> > ----------------------------------------
> >
> >
> > > CC: lucene-net-dev@lucene.apache.org
> >
> >
> > > From: casper...@caspershouse.com
> >
> >
> > > Date: Thu, 22 Sep 2011 23:58:42 -0400
> >
> >
> > > To: lucene-net-dev@lucene.apache.org
> >
> >
> > > Subject: Re: [Lucene.Net] 2.9.4
> >
> >
> > >
> >
> >
> > > Prescott,
> >
> >
> > >
> >
> >
> > > You really don't need to do that; reads and writes of reference fields
> >
> > are guaranteed to be atomic as per section 5.5 of the C# Language
> >
> > Specufication (Atomicity of variable references)
> >
> >
> > >
> >
> >
> > > If you were doing other operations beyond the read and write that you
> >
> > wanted to be atomic, then the lock statement is appropriate, but in this
> >
> > case it's not.
> >
> >
> > >
> >
> >
> > > The volatile keyword in this case (assuming no lock) would absolutely
> be
> >
> > needed to guarantee that the variable has the most up-to-date value at
> the
> >
> > time of access; using lock does this for you and makes volatile
> >
> > unnecessary.
> >
> >
> > >
> >
> >
> > > - Nick
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > On Sep 22, 2011, at 11:14 PM, Prescott Nasser <geobmx...@hotmail.com>
> >
> > wrote:
> >
> >
> > >
> >
> >
> > > >
> >
> >
> > > > Before I go replacing all the volatile fields I wanted to run this
> > past
> >
> > the list:
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > > private System.IO.StreamWriter infoStream;
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > > into
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > > private object o = new object();
> >
> >
> > > > private System.IO.StreamWriter _infoStream;
> >
> >
> > > > private System.IO.StreamWriter infoStream
> >
> >
> > > > {
> >
> >
> > > > get
> >
> >
> > > > {
> >
> >
> > > > lock (o)
> >
> >
> > > > {
> >
> >
> > > > return _infoStream;
> >
> >
> > > > }
> >
> >
> > > > }
> >
> >
> > > > set
> >
> >
> > > > {
> >
> >
> > > > lock (o)
> >
> >
> > > > {
> >
> >
> > > > _infoStream = value;
> >
> >
> > > > }
> >
> >
> > > > }
> >
> >
> > > > }
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > > Sorry, I don't normally deal with locks..
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > > Thanks for any guidance
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > > ~P
> >
> >
> > > >
> >
> >
> > > >>
> >
> >
> > > >> @Prescott,
> >
> >
> > > >> Can the volatile fields be wrapped in a lock statement and code that
> >
> > access
> >
> >
> > > >> those fields with replaced with call to a property /method that
> wraps
> >
> > access
> >
> >
> > > >> to that field?
> >
> >
> > > >>
> >
> >
> > > >>
> >
> >
> > > >>
> >
> >
> > > >>
> >
> >
> > > >> On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard <thowar...@gmail.com>
> >
> > wrote:
> >
> >
> > > >>
> >
> >
> > > >>> I thought it was:
> >
> >
> > > >>>
> >
> >
> > > >>> 2.9.2 and before are 2.0 compatible
> >
> >
> > > >>> 2.9.4 and before are 3.5 compatible
> >
> >
> > > >>> After 2.9.4 are 4.0 compatible
> >
> >
> > > >>>
> >
> >
> > > >>> Thanks,
> >
> >
> > > >>> Troy
> >
> >
> > > >>>
> >
> >
> > > >>> On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
> >
> >
> > > >>> <mhern...@wickedsoftware.net> wrote:
> >
> >
> > > >>>> if thats the case, then well need conditional statements for
> >
> > including
> >
> >
> > > >>>> ThreadLocal<T>
> >
> >
> > > >>>>
> >
> >
> > > >>>> On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser
> >
> > <geobmx...@hotmail.com
> >
> >
> > > >>>> wrote:
> >
> >
> > > >>>>
> >
> >
> > > >>>>> I thought this was after 2.9.4
> >
> >
> > > >>>>>
> >
> >
> > > >>>>> Sent from my Windows Phone
> >
> >
> > > >>>>>
> >
> >
> > > >>>>> -----Original Message-----
> >
> >
> > > >>>>> From: Michael Herndon
> >
> >
> > > >>>>> Sent: Wednesday, September 21, 2011 8:30 AM
> >
> >
> > > >>>>> To: lucene-net-dev@lucene.apache.org
> >
> >
> > > >>>>> Cc: lucene-net-...@incubator.apache.org
> >
> >
> > > >>>>> Subject: Re: [Lucene.Net] 2.9.4
> >
> >
> > > >>>>>
> >
> >
> > > >>>>> @Robert,
> >
> >
> > > >>>>>
> >
> >
> > > >>>>> I believe the overwhelming consensus on the mailing list vote was
> >
> > to
> >
> >
> > > >>> move
> >
> >
> > > >>>>> to
> >
> >
> > > >>>>> .NET 4.0 and drop support for previous versions.
> >
> >
> > > >>>>>
> >
> >
> > > >>>>> I'll take care of build scripts issue while they being refactored
> >
> > into
> >
> >
> > > >>>>> smaller chunks this week.
> >
> >
> > > >>>>>
> >
> >
> > > >>>>> @Troy, Agreed.
> >
> >
> > > >>>>>
> >
> >
> > > >>>>> On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan <robe...@gmx.net>
> >
> > wrote:
> >
> >
> > > >>>>>
> >
> >
> > > >>>>>> On 20.09.2011 23:48, Prescott Nasser wrote:
> >
> >
> > > >>>>>>
> >
> >
> > > >>>>>>> Hey all seems like we are set with 2.9.4? Feedback has been
> >
> > positive
> >
> >
> > > >>> and
> >
> >
> > > >>>>>>> its been quiet. Do we feel ready to vote for a new release?
> >
> >
> > > >>>>>>>
> >
> >
> > > >>>>>>
> >
> >
> > > >>>>>> I don't know if the build infrastructure is part of the
> >
> >
> > > >>>>>> release. If yes, then there is an open issue:
> >
> >
> > > >>>>>>
> >
> >
> > > >>>>>> Contrib doesn't build right now because there
> >
> >
> > > >>>>>> are some assembly name mismatches between certain *.csproj
> >
> >
> > > >>>>>> files and build/scripts/contrib.targets.
> >
> >
> > > >>>>>>
> >
> >
> > > >>>>>> The following patches should fix the issue:
> >
> >
> > > >>>>>>
> >
> >
> > > >>>>>> https://github.com/robert-j/**lucene.net/commit/**
> >
> >
> > > >>>>>> c5218bca56c19b3407648224781eec**7316994a39<
> >
> >
> > > >>>>>
> >
> >
> > > >>>
> >
> >
> https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec
> >
> >
> > 7316994a39
> >
> >
> > > >>>>>>
> >
> >
> > > >>>>>>
> >
> >
> > > >>>>>> https://github.com/robert-j/**lucene.net/commit/**
> >
> >
> > > >>>>>> 50bad187655d59968d51d472b57c2a**40e201d663<
> >
> >
> > > >>>>>
> >
> >
> > > >>>
> >
> >
> https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a
> >
> >
> > 40e201d663
> >
> >
> > > >>>>>>
> >
> >
> > > >>>>>>
> >
> >
> > > >>>>>>
> >
> >
> > > >>>>>> Also, the fix for [LUCENENET-358] is basically making
> >
> >
> > > >>>>>> Lucene.Net.dll a .NET 4.0-only assembly:
> >
> >
> > > >>>>>>
> >
> >
> > > >>>>>> https://github.com/apache/**lucene.net/commit/**
> >
> >
> > > >>>>>> 23ea6f52362fc7dbce48fd012cea12**9a7350c73c<
> >
> >
> > > >>>>>
> >
> >
> > > >>>
> >
> >
> https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a
> >
> >
> > 7350c73c
> >
> >
> > > >>>>>>
> >
> >
> > > >>>>>>
> >
> >
> > > >>>>>> Did we agree about abandoning .NET <= 3.5?
> >
> >
> > > >>>>>>
> >
> >
> > > >>>>>> Robert
> >
> >
> > > >>>>>>
> >
> >
> > > >>>>>>
> >
> >
> > > >>>>>
> >
> >
> > > >>>>
> >
> >
> > > >>>
> >
> >
> > >
> >
> >
> > >
> >
>
