RE: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts
Say what? There's no personalities involved here. It's simple, anything that comes between me and the source is unnecessary and just gets in the way of deploying and using Lucene.NET - Neal -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Wednesday, September 21, 2011 10:07 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts Michael - Could be wrong, but I think Nick might have gotten you confused with Neal. Regardless, I completely agree with everything you just said. And, Yay for NuGet! Package management is the bomb. -T On Wed, Sep 21, 2011 at 7:43 PM, Michael Herndon mhern...@wickedsoftware.net wrote: Nick, The last e-mail was out of line and out of context. If anything, emails like that can push people into emotional or motivational apathy towards working on a project. 1) Lucene.Net will be getting nuget packages. People can hate on it, grumble, or not use it, but its a viable distribution vehicle. Its going in. This thread was to gather feedback on how people that would use it, see themselves using it. 2) Others might want alternatives to nuget that have not been provided yet. We should be open to providing distribution alternatives if enough people warrant it. Its not apathetic or impassive to think to that there might be more than one way to distribute releases. 3) Attack problems. Not people. If you believe a person is the problem, take the issue up with them offline. Those kinds of things are better face to face or through a phone call, or an exceptionally clear e-mail. Its way too easy for people to read into things too much or take things out of context in an e-mail. Attacking people also distracts people from focusing on the actual issue and prevents any actually logic or reason or sound argument from being heard. Its a good way to alienate people that you should actually be trying to persuade. 4) If I was actually apathetic and severely short sighted, I would not be spending my own vacation time this weekend automating nuget packages with the build scripts for Lucene.Net or experimenting Portable Library Tools for Lucene.Net 4.x to see if we can get it working on mobile. Nor would I have spent my last 4 day weekend setting up jenkins and local builds of Lucene.Net. Or put in the hours today to make sure the build scripts are granular enough to implement the smaller packages. 5) If you feel so passionately about all this, why not work towards being a contributor or committer and lead by example ? - Michael Since I'm the one implementing Nuget into the build process and I have not played with the nuget server or creating a package, it just seem wise to gather feedback on how people saw themselves using the contrib packages. On Wed, Sep 21, 2011 at 9:00 PM, Nicholas Paldino [.NET/C# MVP] casper...@caspershouse.com wrote: With all due respect, it's myopic opinions like yours and Michael's (his leans more towards apathy) which will harm the ability to get the project into the hands of people. I think (hope?) it can be agreed upon that the more that people are aware of Lucene.NET, the better it is for the project in general, and most importantly, the more potential that you have that someone will *contribute back* to it (and given what Lucene.NET has gone through in the past year, it desperately needs that participation). The fact of the matter is that Nuget puts packages in the hands of .NET developers, that leads to exposure and regardless of personal opinions on whether or not they *like* Nuget, it can't be denied that it's an *extremely* popular way to get libraries into people's projects. If you want to quibble over the actual numbers (and the definition of extremely popular) then that's fine, but here are the numbers you want: http://stats.nuget.org/ If you want to just tell that audience to take a leap, that's fine, but I think it would be foolish to do so otherwise. Additionally, given that Lucene.NET is already on Nuget, isn't there *any* concern that there isn't an official distro? Aren't you concerned about the integrity of the brand that so many of you fought to keep alive over the past year? There's no guarantee that what's on Nuget will be the official releases/builds that come out of this project, and I'm a little surprised there isn't more concern over that aspect either. Just my $0.02 - Nick -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Wednesday, September 21, 2011 7:06 PM To: lucene-net-dev@lucene.apache.org Subject: RE: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts I am not against it, but personally think it as a toy. I am from the generation where people used vi to write codes. DIGY -Original Message- From: Aaron Powell [mailto:m...@aaron-powell.com] Sent: Thursday, September 22, 2011 1:56 AM To: lucene-net-dev@lucene.apache.org
Re: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts
Michael, Troy is indeed right in that I was referring to Neal's email and not yours. That was a mistake on my part and anything that sprung from that mistake was unintended and I apologize for that. For the rest, see inline. The last e-mail was out of line and out of context. If anything, emails like that can push people into emotional or motivational apathy towards working on a project. I believe it is debatable whether or not it was out of context; yes, the Nuget packages *are* being created, but people started to give sweeping generalizations about Nuget, so the out-of-context nature had already been established. While not an excuse for continuing to be out-of-context, I felt it exposed a larger issue which I was trying to address. I disagree that it was out of line. Can emails like that push people into emotional or motivational apathy towards working on a project? Yes, it absolutely can. However, I feel that's part of the problem, there's already too much emotional and motivational apathy around working on the Lucene.NET project and my statements were to show example that I felt harbored that environment; I believe that saying something that needs to be heard takes precedence over whether or not the audience wants to hear it. 1) Lucene.Net will be getting nuget packages. People can hate on it, grumble, or not use it, but its a viable distribution vehicle. Its going in. This thread was to gather feedback on how people that would use it, see themselves using it. Understood. This is a very good thing. See my previous comments on how the thread changed. 2) Others might want alternatives to nuget that have not been provided yet. We should be open to providing distribution alternatives if enough people warrant it. Its not apathetic or impassive to think to that there might be more than one way to distribute releases. It was never implied that Nuget should be the only means of distribution. This falls outside the scope of the points I was trying to make. FWIW, any distribution method that maintains the integrity of the project releases and helps to distribute those releases to the most people possible and also reduces the barrier to entry is a good thing. 3) Attack problems. Not people. If you believe a person is the problem, take the issue up with them offline. Those kinds of things are better face to face or through a phone call, or an exceptionally clear e-mail. Its way too easy for people to read into things too much or take things out of context in an e-mail. When the problem *is the people* (or at least, their opinions on the project which have an impact on it), then unfortunately, they are one in the same. I believe there is a systemic problem with many of the opinions that prevent the growth of the project. While I believe that those are the symptoms, it can't be argued that there *isn't* a problem with the project on some level, hence Lucene.NET going into incubation status. I'm trying to point out an example of what I feel part (if not most or all) of the problem is. Attacking people also distracts people from focusing on the actual issue and prevents any actually logic or reason or sound argument from being heard. Its a good way to alienate people that you should actually be trying to persuade. Agreed, but see above in reference to people or aspects of people being the problem. 4) If I was actually apathetic and severely short sighted, I would not be spending my own vacation time this weekend automating nuget packages with the build scripts for Lucene.Net or experimenting Portable Library Tools for Lucene.Net 4.x to see if we can get it working on mobile. Nor would I have spent my last 4 day weekend setting up jenkins and local builds of Lucene.Net. Or put in the hours today to make sure the build scripts are granular enough to implement the smaller packages. Already addressed. 5) If you feel so passionately about all this, why not work towards being a contributor or committer and lead by example ? When I first started using Lucene.NET, I did try to make a handful contributions, as well as had a few prolonged conversations about the process and vision of the project (at the time, it was to maintain a line-by-line port of the project). At that point, the examples were not well-received (which was not something I took personally, it was simply a matter of not having compatible visions) nor did they foster leadership, so I diverted my energies elsewhere. I might divert my energy back when I feel those visions are more compatible. I've seen some underpinnings, but not enough, frankly, to warrant my participation as a contributor or committer to the project. Also, it should be noted that my level of participation in the project is not relevant to providing an opinion as to why the project is struggling. I appreciate trying to encourage people to participate, but it
RE: [Lucene.Net] 2.9.4
Before I go replacing all the volatile fields I wanted to run this past the
list:
private System.IO.StreamWriter infoStream;
into
private object o = new object();
private System.IO.StreamWriter _infoStream;
private System.IO.StreamWriter infoStream
{
get
{
lock (o)
{
return _infoStream;
}
}
set
{
lock (o)
{
_infoStream = value;
}
}
}
Sorry, I don't normally deal with locks..
Thanks for any guidance
~P
@Prescott,
Can the volatile fields be wrapped in a lock statement and code that access
those fields with replaced with call to a property /method that wraps access
to that field?
On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard thowar...@gmail.com wrote:
I thought it was:
2.9.2 and before are 2.0 compatible
2.9.4 and before are 3.5 compatible
After 2.9.4 are 4.0 compatible
Thanks,
Troy
On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
mhern...@wickedsoftware.net wrote:
if thats the case, then well need conditional statements for including
ThreadLocalT
On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser geobmx...@hotmail.com
wrote:
I thought this was after 2.9.4
Sent from my Windows Phone
-Original Message-
From: Michael Herndon
Sent: Wednesday, September 21, 2011 8:30 AM
To: lucene-net-dev@lucene.apache.org
Cc: lucene-net-...@incubator.apache.org
Subject: Re: [Lucene.Net] 2.9.4
@Robert,
I believe the overwhelming consensus on the mailing list vote was to
move
to
.NET 4.0 and drop support for previous versions.
I'll take care of build scripts issue while they being refactored into
smaller chunks this week.
@Troy, Agreed.
On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan robe...@gmx.net wrote:
On 20.09.2011 23:48, Prescott Nasser wrote:
Hey all seems like we are set with 2.9.4? Feedback has been positive
and
its been quiet. Do we feel ready to vote for a new release?
I don't know if the build infrastructure is part of the
release. If yes, then there is an open issue:
Contrib doesn't build right now because there
are some assembly name mismatches between certain *.csproj
files and build/scripts/contrib.targets.
The following patches should fix the issue:
https://github.com/robert-j/**lucene.net/commit/**
c5218bca56c19b3407648224781eec**7316994a39
https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec7316994a39
https://github.com/robert-j/**lucene.net/commit/**
50bad187655d59968d51d472b57c2a**40e201d663
https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a40e201d663
Also, the fix for [LUCENENET-358] is basically making
Lucene.Net.dll a .NET 4.0-only assembly:
https://github.com/apache/**lucene.net/commit/**
23ea6f52362fc7dbce48fd012cea12**9a7350c73c
https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a7350c73c
Did we agree about abandoning .NET = 3.5?
Robert
RE: [Lucene.Net] 2.9.4
The line before had volatile in it..
private volatile System.IO.StreamWriter infoStream;
From: geobmx...@hotmail.com
To: lucene-net-dev@lucene.apache.org
Date: Thu, 22 Sep 2011 20:14:41 -0700
Subject: RE: [Lucene.Net] 2.9.4
Before I go replacing all the volatile fields I wanted to run this past the
list:
private System.IO.StreamWriter infoStream;
into
private object o = new object();
private System.IO.StreamWriter _infoStream;
private System.IO.StreamWriter infoStream
{
get
{
lock (o)
{
return _infoStream;
}
}
set
{
lock (o)
{
_infoStream = value;
}
}
}
Sorry, I don't normally deal with locks..
Thanks for any guidance
~P
@Prescott,
Can the volatile fields be wrapped in a lock statement and code that access
those fields with replaced with call to a property /method that wraps access
to that field?
On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard thowar...@gmail.com wrote:
I thought it was:
2.9.2 and before are 2.0 compatible
2.9.4 and before are 3.5 compatible
After 2.9.4 are 4.0 compatible
Thanks,
Troy
On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
mhern...@wickedsoftware.net wrote:
if thats the case, then well need conditional statements for including
ThreadLocalT
On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser geobmx...@hotmail.com
wrote:
I thought this was after 2.9.4
Sent from my Windows Phone
-Original Message-
From: Michael Herndon
Sent: Wednesday, September 21, 2011 8:30 AM
To: lucene-net-dev@lucene.apache.org
Cc: lucene-net-...@incubator.apache.org
Subject: Re: [Lucene.Net] 2.9.4
@Robert,
I believe the overwhelming consensus on the mailing list vote was to
move
to
.NET 4.0 and drop support for previous versions.
I'll take care of build scripts issue while they being refactored into
smaller chunks this week.
@Troy, Agreed.
On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan robe...@gmx.net wrote:
On 20.09.2011 23:48, Prescott Nasser wrote:
Hey all seems like we are set with 2.9.4? Feedback has been positive
and
its been quiet. Do we feel ready to vote for a new release?
I don't know if the build infrastructure is part of the
release. If yes, then there is an open issue:
Contrib doesn't build right now because there
are some assembly name mismatches between certain *.csproj
files and build/scripts/contrib.targets.
The following patches should fix the issue:
https://github.com/robert-j/**lucene.net/commit/**
c5218bca56c19b3407648224781eec**7316994a39
https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec7316994a39
https://github.com/robert-j/**lucene.net/commit/**
50bad187655d59968d51d472b57c2a**40e201d663
https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a40e201d663
Also, the fix for [LUCENENET-358] is basically making
Lucene.Net.dll a .NET 4.0-only assembly:
https://github.com/apache/**lucene.net/commit/**
23ea6f52362fc7dbce48fd012cea12**9a7350c73c
https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a7350c73c
Did we agree about abandoning .NET = 3.5?
Robert
Re: [Lucene.Net] 2.9.4
Prescott,
You really don't need to do that; reads and writes of reference fields are
guaranteed to be atomic as per section 5.5 of the C# Language Specufication
(Atomicity of variable references)
If you were doing other operations beyond the read and write that you wanted to
be atomic, then the lock statement is appropriate, but in this case it's not.
The volatile keyword in this case (assuming no lock) would absolutely be needed
to guarantee that the variable has the most up-to-date value at the time of
access; using lock does this for you and makes volatile unnecessary.
- Nick
On Sep 22, 2011, at 11:14 PM, Prescott Nasser geobmx...@hotmail.com wrote:
Before I go replacing all the volatile fields I wanted to run this past the
list:
private System.IO.StreamWriter infoStream;
into
private object o = new object();
private System.IO.StreamWriter _infoStream;
private System.IO.StreamWriter infoStream
{
get
{
lock (o)
{
return _infoStream;
}
}
set
{
lock (o)
{
_infoStream = value;
}
}
}
Sorry, I don't normally deal with locks..
Thanks for any guidance
~P
@Prescott,
Can the volatile fields be wrapped in a lock statement and code that access
those fields with replaced with call to a property /method that wraps access
to that field?
On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard thowar...@gmail.com wrote:
I thought it was:
2.9.2 and before are 2.0 compatible
2.9.4 and before are 3.5 compatible
After 2.9.4 are 4.0 compatible
Thanks,
Troy
On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
mhern...@wickedsoftware.net wrote:
if thats the case, then well need conditional statements for including
ThreadLocalT
On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser geobmx...@hotmail.com
wrote:
I thought this was after 2.9.4
Sent from my Windows Phone
-Original Message-
From: Michael Herndon
Sent: Wednesday, September 21, 2011 8:30 AM
To: lucene-net-dev@lucene.apache.org
Cc: lucene-net-...@incubator.apache.org
Subject: Re: [Lucene.Net] 2.9.4
@Robert,
I believe the overwhelming consensus on the mailing list vote was to
move
to
.NET 4.0 and drop support for previous versions.
I'll take care of build scripts issue while they being refactored into
smaller chunks this week.
@Troy, Agreed.
On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan robe...@gmx.net wrote:
On 20.09.2011 23:48, Prescott Nasser wrote:
Hey all seems like we are set with 2.9.4? Feedback has been positive
and
its been quiet. Do we feel ready to vote for a new release?
I don't know if the build infrastructure is part of the
release. If yes, then there is an open issue:
Contrib doesn't build right now because there
are some assembly name mismatches between certain *.csproj
files and build/scripts/contrib.targets.
The following patches should fix the issue:
https://github.com/robert-j/**lucene.net/commit/**
c5218bca56c19b3407648224781eec**7316994a39
https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec7316994a39
https://github.com/robert-j/**lucene.net/commit/**
50bad187655d59968d51d472b57c2a**40e201d663
https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a40e201d663
Also, the fix for [LUCENENET-358] is basically making
Lucene.Net.dll a .NET 4.0-only assembly:
https://github.com/apache/**lucene.net/commit/**
23ea6f52362fc7dbce48fd012cea12**9a7350c73c
https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a7350c73c
Did we agree about abandoning .NET = 3.5?
Robert
Re: [Lucene.Net] Contribution
On 2011-09-22, Danijel Kecman wrote: i would like to contribute. welcome Danijel. The best way to start contributing is by looking at the issues in JIRA pick one and start providing patches there - as well as engaging in discussion on this list. Cheers Stefan
RE: [Lucene.Net] 2.9.4
I see, so you're essentially saying, I can simply remove the volatile keyword
in this case, and it's exactly the same becuase I am only using it for read and
writes?
So the case I'd need to be more careful of is if an manipulation method is
called on the object itself - suppose:
public person {
_name = Me
public changeName(string n)
{
_name = n;
}
}
If one were to write
public volatile person p = new person();
p.changeName(You);
the call to the method would in this case need a lock (which volatile gives) to
gaurentee that changeName occurs before other items read or overwrite variable
p?
but a straight read or write won't matter:
p = new person();
p = new person():
x = p;
p = new person();
Here, I wouldn't need the volatile keyword becuase those are merely reads and
wrights?
CC: lucene-net-dev@lucene.apache.org
From: casper...@caspershouse.com
Date: Thu, 22 Sep 2011 23:58:42 -0400
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] 2.9.4
Prescott,
You really don't need to do that; reads and writes of reference fields are
guaranteed to be atomic as per section 5.5 of the C# Language Specufication
(Atomicity of variable references)
If you were doing other operations beyond the read and write that you wanted
to be atomic, then the lock statement is appropriate, but in this case it's
not.
The volatile keyword in this case (assuming no lock) would absolutely be
needed to guarantee that the variable has the most up-to-date value at the
time of access; using lock does this for you and makes volatile unnecessary.
- Nick
On Sep 22, 2011, at 11:14 PM, Prescott Nasser geobmx...@hotmail.com wrote:
Before I go replacing all the volatile fields I wanted to run this past the
list:
private System.IO.StreamWriter infoStream;
into
private object o = new object();
private System.IO.StreamWriter _infoStream;
private System.IO.StreamWriter infoStream
{
get
{
lock (o)
{
return _infoStream;
}
}
set
{
lock (o)
{
_infoStream = value;
}
}
}
Sorry, I don't normally deal with locks..
Thanks for any guidance
~P
@Prescott,
Can the volatile fields be wrapped in a lock statement and code that access
those fields with replaced with call to a property /method that wraps
access
to that field?
On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard thowar...@gmail.com wrote:
I thought it was:
2.9.2 and before are 2.0 compatible
2.9.4 and before are 3.5 compatible
After 2.9.4 are 4.0 compatible
Thanks,
Troy
On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
mhern...@wickedsoftware.net wrote:
if thats the case, then well need conditional statements for including
ThreadLocalT
On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser geobmx...@hotmail.com
wrote:
I thought this was after 2.9.4
Sent from my Windows Phone
-Original Message-
From: Michael Herndon
Sent: Wednesday, September 21, 2011 8:30 AM
To: lucene-net-dev@lucene.apache.org
Cc: lucene-net-...@incubator.apache.org
Subject: Re: [Lucene.Net] 2.9.4
@Robert,
I believe the overwhelming consensus on the mailing list vote was to
move
to
.NET 4.0 and drop support for previous versions.
I'll take care of build scripts issue while they being refactored into
smaller chunks this week.
@Troy, Agreed.
On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan robe...@gmx.net wrote:
On 20.09.2011 23:48, Prescott Nasser wrote:
Hey all seems like we are set with 2.9.4? Feedback has been positive
and
its been quiet. Do we feel ready to vote for a new release?
I don't know if the build infrastructure is part of the
release. If yes, then there is an open issue:
Contrib doesn't build right now because there
are some assembly name mismatches between certain *.csproj
files and build/scripts/contrib.targets.
The following patches should fix the issue:
https://github.com/robert-j/**lucene.net/commit/**
c5218bca56c19b3407648224781eec**7316994a39
https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec7316994a39
https://github.com/robert-j/**lucene.net/commit/**
50bad187655d59968d51d472b57c2a**40e201d663
https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a40e201d663
Also, the fix for [LUCENENET-358] is basically making
Lucene.Net.dll a .NET 4.0-only assembly:
https://github.com/apache/**lucene.net/commit/**
23ea6f52362fc7dbce48fd012cea12**9a7350c73c
https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a7350c73c
Did we agree about abandoning .NET = 3.5?
Robert
