You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@lucenenet.apache.org by Michael Garski <mg...@myspace-inc.com> on 2009/11/09 18:25:38 UTC
2.9 Target Framework
Apologies for the cross-posting to both lists, but I think this issue is
applicable to both.
What is the target framework for Lucene.Net 2.9? I'm assuming 2.0 but
would like to ensure this is defined. There are a few cases in some of
the internal implementation where use of LINQ would be handy, such as in
collection transformations to arrays. Overall, it's not a big deal to
target 2.0 however some of the implementation will be a bit more elegant
and precise if we target 3.5.
Cheers,
Michael
Michael Garski
Sr. Search Architect
310.969.7435 (office)
310.251.6355 (mobile)
www.myspace.com/michaelgarski
RE: 2.9 Target Framework
Posted by George Aroush <ge...@aroush.net>.
Hi Nick,
Doing an initial port is very challenging and time consuming because it's not totally automated. I have relied on JLCA and automated scripts that I wrote to do ports (going back to 1.4 days). The reaming issues that you see now are minor compared to what JLCA leaves you with. I have posted a couple of times about this, so search the mail archive for the details.
Basically, an initial port depends heavily on deltas between two release (deltas both in the Java Lucene and Lucene.Net world). Thus, if we start taking full advantage of what .NET and C# has to offer, unless if we are first at a commit-by-commit level with what's happening in the Java Lucene world, we can be in a total mess when the next release arrives. So, before we can achieve this, we need 1) release closer to Java Lucene releases (I hope 2.9.1 and 3.0 will be it), 2) we need more Lucene.Net contributors and committers who are active.
Thanks.
-- George
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
Sent: Tuesday, November 10, 2009 12:30 AM
To: lucene-net-dev@incubator.apache.org
Cc: lucene-net-user@incubator.apache.org
Subject: RE: 2.9 Target Framework
Michael,
Sorry for the newb question, but what are the issues in moving to .NET 3.5
now (I just joined the list today and am looking around in the archives now,
btw)?
In the move from .NET 2.0 -> 3.5, the CLR was not changed. The only things
that were changed were BCL types (base class libraries, and they are backwards
compatable), and the compilers (to allow for lambda expressions, anonymous
types, query syntax, and the like).
The reason I ask is that in doing my own port of Lucene.NET 2.0 to a .NET 3.5
implementation, I've found that there are a number of helpful constructs, some
of them being:
- Hashset<T>
- LINQ allows for the flattening of a number of nasty embedded loops, and a
more declarative style of code.
- Lambda expressions
Among many others.
If the concern is alienating a user base that is on .NET 2.0 and can't move
to .NET 3.5, then that settles it, but if it is a concern over one of the
items mentioned above (changes in the CLR, BCL), then I'm not sure what the
concern is (not saying that there isn't one, but looking through the archives,
I can't find the particular discussion around this topic).
The reason I question this is because when working on my port, I figured it
would be better to just contribute to the project itself. However, I feel I
can be of more use in getting the internals correct, and .NET 3.5 would really
help with that (there are a number of issues revolving around synchronization,
enumeration usage which are not best practices). While internals can be
changed for a move to .NET 2.0, for a lot of the places where you are going to
integrate .NET 2.0 code, you are probably going to want to use .NET 3.5 code
to even further simplify and enhance the code.
A perfect example is a number of the loop iterators that you have now over
ArrayList instances. At the least, those instances should be strongly-typed
IList<T> implementations (typically List<T>) especially when the type
parameter T is a value type. When a value type, the performance of using an
IList<T> implementation over an ArrayList is somewhere around 40%-50% faster
than using ArrayList (because of lack of boxing). When a reference type,
there is still a performance gain (I think it was around 10%-20%, but don't
quote me on that one). This is all Generics, and I assume everyone knows the
benefits of moving to them.
When doing so, that causes a chain reaction. In moving to an IList<T>
implementation, you have an IEnumerable<T> implementation and you will want to
replace a lot of the iterator code from for loops to foreach loops (which you
can use in .NET 1.1, I don't know why they weren't used, you still had the
runtime cast issues).
However, most of these loops have some sort of filtering/sorting/grouping
logic. LINQ really goes a great way to simplify the code in this situation,
separating the logic of what you want to do from the items you want to do it
to (or even creating the appropriate projections to assist in what you are
trying to do, I've used it in a number of places to flatten some pretty nasty
embedded for loops quite efficiently).
The point is, if you go to .NET 2.0, you get yourself part of the way there
when it comes to how much you can do to improve the codebase (and I am
speaking only of the internal implementation, I'm not suggesting you change
the public definition of the class) and will eventually require a revisit to
the same code.
Given that you have the test cases already, what's the harm (assuming it
isn't a user base issue) in going to .NET 3.5 now, and reaping the benefits
now if a number of files are going to be touched because of the move to .NET
2.0 anyways? - Nick
-----Original Message-----
From: Michael Garski [mailto:mgarski@myspace-inc.com]
Sent: Monday, November 09, 2009 11:20 PM
To: lucene-net-user@incubator.apache.org
Cc: lucene-net-dev@incubator.apache.org
Subject: RE: 2.9 Target Framework
No problem - 2.0 it is.
Michael
-----Original Message-----
From: George Aroush [mailto:george@aroush.net]
Sent: Monday, November 09, 2009 7:16 PM
To: lucene-net-user@incubator.apache.org
Cc: lucene-net-dev@incubator.apache.org
Subject: RE: 2.9 Target Framework
I agree with DIGY. We have discussed this in the past few times. We have
to get 2.9.1 out really soon, so we can catch up with 3.0 and do more than
just port over logic from Java to C# -- but also take advantage of what C#
and .NET has to offer.
BTW, those kind of discussions should be on the dev side vs. user.
-- George
-----Original Message-----
From: Digy [mailto:digydigy@gmail.com]
Sent: Monday, November 09, 2009 1:19 PM
To: lucene-net-user@incubator.apache.org
Subject: RE: 2.9 Target Framework
I think we should stick to .NET 2.0 till Lucene 3.0 which can be a good
place to switch to .NET 3.5 (so will Lucene.Java do also).
There are also a lot of places where smarter codes can be used ( replacing
"GetEnumerator+while" with "foreach", implementing a .NET like "Set" instead
of using Hashtable etc.) But it can be a problem in porting unless we catch
up with Lucene.Java.
DIGY
-----Original Message-----
From: Michael Garski [mailto:mgarski@myspace-inc.com]
Sent: Monday, November 09, 2009 7:26 PM
To: lucene-net-dev@incubator.apache.org;
lucene-net-user@incubator.apache.org
Subject: 2.9 Target Framework
Apologies for the cross-posting to both lists, but I think this issue is
applicable to both.
What is the target framework for Lucene.Net 2.9? I'm assuming 2.0 but
would like to ensure this is defined. There are a few cases in some of
the internal implementation where use of LINQ would be handy, such as in
collection transformations to arrays. Overall, it's not a big deal to
target 2.0 however some of the implementation will be a bit more elegant
and precise if we target 3.5.
Cheers,
Michael
Michael Garski
Sr. Search Architect
310.969.7435 (office)
310.251.6355 (mobile)
www.myspace.com/michaelgarski
RE: 2.9 Target Framework
Posted by George Aroush <ge...@aroush.net>.
Hi Nick,
Doing an initial port is very challenging and time consuming because it's not totally automated. I have relied on JLCA and automated scripts that I wrote to do ports (going back to 1.4 days). The reaming issues that you see now are minor compared to what JLCA leaves you with. I have posted a couple of times about this, so search the mail archive for the details.
Basically, an initial port depends heavily on deltas between two release (deltas both in the Java Lucene and Lucene.Net world). Thus, if we start taking full advantage of what .NET and C# has to offer, unless if we are first at a commit-by-commit level with what's happening in the Java Lucene world, we can be in a total mess when the next release arrives. So, before we can achieve this, we need 1) release closer to Java Lucene releases (I hope 2.9.1 and 3.0 will be it), 2) we need more Lucene.Net contributors and committers who are active.
Thanks.
-- George
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
Sent: Tuesday, November 10, 2009 12:30 AM
To: lucene-net-dev@incubator.apache.org
Cc: lucene-net-user@incubator.apache.org
Subject: RE: 2.9 Target Framework
Michael,
Sorry for the newb question, but what are the issues in moving to .NET 3.5
now (I just joined the list today and am looking around in the archives now,
btw)?
In the move from .NET 2.0 -> 3.5, the CLR was not changed. The only things
that were changed were BCL types (base class libraries, and they are backwards
compatable), and the compilers (to allow for lambda expressions, anonymous
types, query syntax, and the like).
The reason I ask is that in doing my own port of Lucene.NET 2.0 to a .NET 3.5
implementation, I've found that there are a number of helpful constructs, some
of them being:
- Hashset<T>
- LINQ allows for the flattening of a number of nasty embedded loops, and a
more declarative style of code.
- Lambda expressions
Among many others.
If the concern is alienating a user base that is on .NET 2.0 and can't move
to .NET 3.5, then that settles it, but if it is a concern over one of the
items mentioned above (changes in the CLR, BCL), then I'm not sure what the
concern is (not saying that there isn't one, but looking through the archives,
I can't find the particular discussion around this topic).
The reason I question this is because when working on my port, I figured it
would be better to just contribute to the project itself. However, I feel I
can be of more use in getting the internals correct, and .NET 3.5 would really
help with that (there are a number of issues revolving around synchronization,
enumeration usage which are not best practices). While internals can be
changed for a move to .NET 2.0, for a lot of the places where you are going to
integrate .NET 2.0 code, you are probably going to want to use .NET 3.5 code
to even further simplify and enhance the code.
A perfect example is a number of the loop iterators that you have now over
ArrayList instances. At the least, those instances should be strongly-typed
IList<T> implementations (typically List<T>) especially when the type
parameter T is a value type. When a value type, the performance of using an
IList<T> implementation over an ArrayList is somewhere around 40%-50% faster
than using ArrayList (because of lack of boxing). When a reference type,
there is still a performance gain (I think it was around 10%-20%, but don't
quote me on that one). This is all Generics, and I assume everyone knows the
benefits of moving to them.
When doing so, that causes a chain reaction. In moving to an IList<T>
implementation, you have an IEnumerable<T> implementation and you will want to
replace a lot of the iterator code from for loops to foreach loops (which you
can use in .NET 1.1, I don't know why they weren't used, you still had the
runtime cast issues).
However, most of these loops have some sort of filtering/sorting/grouping
logic. LINQ really goes a great way to simplify the code in this situation,
separating the logic of what you want to do from the items you want to do it
to (or even creating the appropriate projections to assist in what you are
trying to do, I've used it in a number of places to flatten some pretty nasty
embedded for loops quite efficiently).
The point is, if you go to .NET 2.0, you get yourself part of the way there
when it comes to how much you can do to improve the codebase (and I am
speaking only of the internal implementation, I'm not suggesting you change
the public definition of the class) and will eventually require a revisit to
the same code.
Given that you have the test cases already, what's the harm (assuming it
isn't a user base issue) in going to .NET 3.5 now, and reaping the benefits
now if a number of files are going to be touched because of the move to .NET
2.0 anyways? - Nick
-----Original Message-----
From: Michael Garski [mailto:mgarski@myspace-inc.com]
Sent: Monday, November 09, 2009 11:20 PM
To: lucene-net-user@incubator.apache.org
Cc: lucene-net-dev@incubator.apache.org
Subject: RE: 2.9 Target Framework
No problem - 2.0 it is.
Michael
-----Original Message-----
From: George Aroush [mailto:george@aroush.net]
Sent: Monday, November 09, 2009 7:16 PM
To: lucene-net-user@incubator.apache.org
Cc: lucene-net-dev@incubator.apache.org
Subject: RE: 2.9 Target Framework
I agree with DIGY. We have discussed this in the past few times. We have
to get 2.9.1 out really soon, so we can catch up with 3.0 and do more than
just port over logic from Java to C# -- but also take advantage of what C#
and .NET has to offer.
BTW, those kind of discussions should be on the dev side vs. user.
-- George
-----Original Message-----
From: Digy [mailto:digydigy@gmail.com]
Sent: Monday, November 09, 2009 1:19 PM
To: lucene-net-user@incubator.apache.org
Subject: RE: 2.9 Target Framework
I think we should stick to .NET 2.0 till Lucene 3.0 which can be a good
place to switch to .NET 3.5 (so will Lucene.Java do also).
There are also a lot of places where smarter codes can be used ( replacing
"GetEnumerator+while" with "foreach", implementing a .NET like "Set" instead
of using Hashtable etc.) But it can be a problem in porting unless we catch
up with Lucene.Java.
DIGY
-----Original Message-----
From: Michael Garski [mailto:mgarski@myspace-inc.com]
Sent: Monday, November 09, 2009 7:26 PM
To: lucene-net-dev@incubator.apache.org;
lucene-net-user@incubator.apache.org
Subject: 2.9 Target Framework
Apologies for the cross-posting to both lists, but I think this issue is
applicable to both.
What is the target framework for Lucene.Net 2.9? I'm assuming 2.0 but
would like to ensure this is defined. There are a few cases in some of
the internal implementation where use of LINQ would be handy, such as in
collection transformations to arrays. Overall, it's not a big deal to
target 2.0 however some of the implementation will be a bit more elegant
and precise if we target 3.5.
Cheers,
Michael
Michael Garski
Sr. Search Architect
310.969.7435 (office)
310.251.6355 (mobile)
www.myspace.com/michaelgarski
RE: 2.9 Target Framework
Posted by "Nicholas Paldino [.NET/C# MVP]" <ca...@caspershouse.com>.
Michael,
Sorry for the newb question, but what are the issues in moving to .NET 3.5
now (I just joined the list today and am looking around in the archives now,
btw)?
In the move from .NET 2.0 -> 3.5, the CLR was not changed. The only things
that were changed were BCL types (base class libraries, and they are backwards
compatable), and the compilers (to allow for lambda expressions, anonymous
types, query syntax, and the like).
The reason I ask is that in doing my own port of Lucene.NET 2.0 to a .NET 3.5
implementation, I've found that there are a number of helpful constructs, some
of them being:
- Hashset<T>
- LINQ allows for the flattening of a number of nasty embedded loops, and a
more declarative style of code.
- Lambda expressions
Among many others.
If the concern is alienating a user base that is on .NET 2.0 and can't move
to .NET 3.5, then that settles it, but if it is a concern over one of the
items mentioned above (changes in the CLR, BCL), then I'm not sure what the
concern is (not saying that there isn't one, but looking through the archives,
I can't find the particular discussion around this topic).
The reason I question this is because when working on my port, I figured it
would be better to just contribute to the project itself. However, I feel I
can be of more use in getting the internals correct, and .NET 3.5 would really
help with that (there are a number of issues revolving around synchronization,
enumeration usage which are not best practices). While internals can be
changed for a move to .NET 2.0, for a lot of the places where you are going to
integrate .NET 2.0 code, you are probably going to want to use .NET 3.5 code
to even further simplify and enhance the code.
A perfect example is a number of the loop iterators that you have now over
ArrayList instances. At the least, those instances should be strongly-typed
IList<T> implementations (typically List<T>) especially when the type
parameter T is a value type. When a value type, the performance of using an
IList<T> implementation over an ArrayList is somewhere around 40%-50% faster
than using ArrayList (because of lack of boxing). When a reference type,
there is still a performance gain (I think it was around 10%-20%, but don't
quote me on that one). This is all Generics, and I assume everyone knows the
benefits of moving to them.
When doing so, that causes a chain reaction. In moving to an IList<T>
implementation, you have an IEnumerable<T> implementation and you will want to
replace a lot of the iterator code from for loops to foreach loops (which you
can use in .NET 1.1, I don't know why they weren't used, you still had the
runtime cast issues).
However, most of these loops have some sort of filtering/sorting/grouping
logic. LINQ really goes a great way to simplify the code in this situation,
separating the logic of what you want to do from the items you want to do it
to (or even creating the appropriate projections to assist in what you are
trying to do, I've used it in a number of places to flatten some pretty nasty
embedded for loops quite efficiently).
The point is, if you go to .NET 2.0, you get yourself part of the way there
when it comes to how much you can do to improve the codebase (and I am
speaking only of the internal implementation, I'm not suggesting you change
the public definition of the class) and will eventually require a revisit to
the same code.
Given that you have the test cases already, what's the harm (assuming it
isn't a user base issue) in going to .NET 3.5 now, and reaping the benefits
now if a number of files are going to be touched because of the move to .NET
2.0 anyways? - Nick
-----Original Message-----
From: Michael Garski [mailto:mgarski@myspace-inc.com]
Sent: Monday, November 09, 2009 11:20 PM
To: lucene-net-user@incubator.apache.org
Cc: lucene-net-dev@incubator.apache.org
Subject: RE: 2.9 Target Framework
No problem - 2.0 it is.
Michael
-----Original Message-----
From: George Aroush [mailto:george@aroush.net]
Sent: Monday, November 09, 2009 7:16 PM
To: lucene-net-user@incubator.apache.org
Cc: lucene-net-dev@incubator.apache.org
Subject: RE: 2.9 Target Framework
I agree with DIGY. We have discussed this in the past few times. We have
to get 2.9.1 out really soon, so we can catch up with 3.0 and do more than
just port over logic from Java to C# -- but also take advantage of what C#
and .NET has to offer.
BTW, those kind of discussions should be on the dev side vs. user.
-- George
-----Original Message-----
From: Digy [mailto:digydigy@gmail.com]
Sent: Monday, November 09, 2009 1:19 PM
To: lucene-net-user@incubator.apache.org
Subject: RE: 2.9 Target Framework
I think we should stick to .NET 2.0 till Lucene 3.0 which can be a good
place to switch to .NET 3.5 (so will Lucene.Java do also).
There are also a lot of places where smarter codes can be used ( replacing
"GetEnumerator+while" with "foreach", implementing a .NET like "Set" instead
of using Hashtable etc.) But it can be a problem in porting unless we catch
up with Lucene.Java.
DIGY
-----Original Message-----
From: Michael Garski [mailto:mgarski@myspace-inc.com]
Sent: Monday, November 09, 2009 7:26 PM
To: lucene-net-dev@incubator.apache.org;
lucene-net-user@incubator.apache.org
Subject: 2.9 Target Framework
Apologies for the cross-posting to both lists, but I think this issue is
applicable to both.
What is the target framework for Lucene.Net 2.9? I'm assuming 2.0 but
would like to ensure this is defined. There are a few cases in some of
the internal implementation where use of LINQ would be handy, such as in
collection transformations to arrays. Overall, it's not a big deal to
target 2.0 however some of the implementation will be a bit more elegant
and precise if we target 3.5.
Cheers,
Michael
Michael Garski
Sr. Search Architect
310.969.7435 (office)
310.251.6355 (mobile)
www.myspace.com/michaelgarski
RE: 2.9 Target Framework
Posted by "Nicholas Paldino [.NET/C# MVP]" <ca...@caspershouse.com>.
Michael,
Sorry for the newb question, but what are the issues in moving to .NET 3.5
now (I just joined the list today and am looking around in the archives now,
btw)?
In the move from .NET 2.0 -> 3.5, the CLR was not changed. The only things
that were changed were BCL types (base class libraries, and they are backwards
compatable), and the compilers (to allow for lambda expressions, anonymous
types, query syntax, and the like).
The reason I ask is that in doing my own port of Lucene.NET 2.0 to a .NET 3.5
implementation, I've found that there are a number of helpful constructs, some
of them being:
- Hashset<T>
- LINQ allows for the flattening of a number of nasty embedded loops, and a
more declarative style of code.
- Lambda expressions
Among many others.
If the concern is alienating a user base that is on .NET 2.0 and can't move
to .NET 3.5, then that settles it, but if it is a concern over one of the
items mentioned above (changes in the CLR, BCL), then I'm not sure what the
concern is (not saying that there isn't one, but looking through the archives,
I can't find the particular discussion around this topic).
The reason I question this is because when working on my port, I figured it
would be better to just contribute to the project itself. However, I feel I
can be of more use in getting the internals correct, and .NET 3.5 would really
help with that (there are a number of issues revolving around synchronization,
enumeration usage which are not best practices). While internals can be
changed for a move to .NET 2.0, for a lot of the places where you are going to
integrate .NET 2.0 code, you are probably going to want to use .NET 3.5 code
to even further simplify and enhance the code.
A perfect example is a number of the loop iterators that you have now over
ArrayList instances. At the least, those instances should be strongly-typed
IList<T> implementations (typically List<T>) especially when the type
parameter T is a value type. When a value type, the performance of using an
IList<T> implementation over an ArrayList is somewhere around 40%-50% faster
than using ArrayList (because of lack of boxing). When a reference type,
there is still a performance gain (I think it was around 10%-20%, but don't
quote me on that one). This is all Generics, and I assume everyone knows the
benefits of moving to them.
When doing so, that causes a chain reaction. In moving to an IList<T>
implementation, you have an IEnumerable<T> implementation and you will want to
replace a lot of the iterator code from for loops to foreach loops (which you
can use in .NET 1.1, I don't know why they weren't used, you still had the
runtime cast issues).
However, most of these loops have some sort of filtering/sorting/grouping
logic. LINQ really goes a great way to simplify the code in this situation,
separating the logic of what you want to do from the items you want to do it
to (or even creating the appropriate projections to assist in what you are
trying to do, I've used it in a number of places to flatten some pretty nasty
embedded for loops quite efficiently).
The point is, if you go to .NET 2.0, you get yourself part of the way there
when it comes to how much you can do to improve the codebase (and I am
speaking only of the internal implementation, I'm not suggesting you change
the public definition of the class) and will eventually require a revisit to
the same code.
Given that you have the test cases already, what's the harm (assuming it
isn't a user base issue) in going to .NET 3.5 now, and reaping the benefits
now if a number of files are going to be touched because of the move to .NET
2.0 anyways? - Nick
-----Original Message-----
From: Michael Garski [mailto:mgarski@myspace-inc.com]
Sent: Monday, November 09, 2009 11:20 PM
To: lucene-net-user@incubator.apache.org
Cc: lucene-net-dev@incubator.apache.org
Subject: RE: 2.9 Target Framework
No problem - 2.0 it is.
Michael
-----Original Message-----
From: George Aroush [mailto:george@aroush.net]
Sent: Monday, November 09, 2009 7:16 PM
To: lucene-net-user@incubator.apache.org
Cc: lucene-net-dev@incubator.apache.org
Subject: RE: 2.9 Target Framework
I agree with DIGY. We have discussed this in the past few times. We have
to get 2.9.1 out really soon, so we can catch up with 3.0 and do more than
just port over logic from Java to C# -- but also take advantage of what C#
and .NET has to offer.
BTW, those kind of discussions should be on the dev side vs. user.
-- George
-----Original Message-----
From: Digy [mailto:digydigy@gmail.com]
Sent: Monday, November 09, 2009 1:19 PM
To: lucene-net-user@incubator.apache.org
Subject: RE: 2.9 Target Framework
I think we should stick to .NET 2.0 till Lucene 3.0 which can be a good
place to switch to .NET 3.5 (so will Lucene.Java do also).
There are also a lot of places where smarter codes can be used ( replacing
"GetEnumerator+while" with "foreach", implementing a .NET like "Set" instead
of using Hashtable etc.) But it can be a problem in porting unless we catch
up with Lucene.Java.
DIGY
-----Original Message-----
From: Michael Garski [mailto:mgarski@myspace-inc.com]
Sent: Monday, November 09, 2009 7:26 PM
To: lucene-net-dev@incubator.apache.org;
lucene-net-user@incubator.apache.org
Subject: 2.9 Target Framework
Apologies for the cross-posting to both lists, but I think this issue is
applicable to both.
What is the target framework for Lucene.Net 2.9? I'm assuming 2.0 but
would like to ensure this is defined. There are a few cases in some of
the internal implementation where use of LINQ would be handy, such as in
collection transformations to arrays. Overall, it's not a big deal to
target 2.0 however some of the implementation will be a bit more elegant
and precise if we target 3.5.
Cheers,
Michael
Michael Garski
Sr. Search Architect
310.969.7435 (office)
310.251.6355 (mobile)
www.myspace.com/michaelgarski
RE: 2.9 Target Framework
Posted by Michael Garski <mg...@myspace-inc.com>.
No problem - 2.0 it is.
Michael
-----Original Message-----
From: George Aroush [mailto:george@aroush.net]
Sent: Monday, November 09, 2009 7:16 PM
To: lucene-net-user@incubator.apache.org
Cc: lucene-net-dev@incubator.apache.org
Subject: RE: 2.9 Target Framework
I agree with DIGY. We have discussed this in the past few times. We have
to get 2.9.1 out really soon, so we can catch up with 3.0 and do more than
just port over logic from Java to C# -- but also take advantage of what C#
and .NET has to offer.
BTW, those kind of discussions should be on the dev side vs. user.
-- George
-----Original Message-----
From: Digy [mailto:digydigy@gmail.com]
Sent: Monday, November 09, 2009 1:19 PM
To: lucene-net-user@incubator.apache.org
Subject: RE: 2.9 Target Framework
I think we should stick to .NET 2.0 till Lucene 3.0 which can be a good
place to switch to .NET 3.5 (so will Lucene.Java do also).
There are also a lot of places where smarter codes can be used ( replacing
"GetEnumerator+while" with "foreach", implementing a .NET like "Set" instead
of using Hashtable etc.) But it can be a problem in porting unless we catch
up with Lucene.Java.
DIGY
-----Original Message-----
From: Michael Garski [mailto:mgarski@myspace-inc.com]
Sent: Monday, November 09, 2009 7:26 PM
To: lucene-net-dev@incubator.apache.org;
lucene-net-user@incubator.apache.org
Subject: 2.9 Target Framework
Apologies for the cross-posting to both lists, but I think this issue is
applicable to both.
What is the target framework for Lucene.Net 2.9? I'm assuming 2.0 but
would like to ensure this is defined. There are a few cases in some of
the internal implementation where use of LINQ would be handy, such as in
collection transformations to arrays. Overall, it's not a big deal to
target 2.0 however some of the implementation will be a bit more elegant
and precise if we target 3.5.
Cheers,
Michael
Michael Garski
Sr. Search Architect
310.969.7435 (office)
310.251.6355 (mobile)
www.myspace.com/michaelgarski
RE: 2.9 Target Framework
Posted by Michael Garski <mg...@myspace-inc.com>.
No problem - 2.0 it is.
Michael
-----Original Message-----
From: George Aroush [mailto:george@aroush.net]
Sent: Monday, November 09, 2009 7:16 PM
To: lucene-net-user@incubator.apache.org
Cc: lucene-net-dev@incubator.apache.org
Subject: RE: 2.9 Target Framework
I agree with DIGY. We have discussed this in the past few times. We have
to get 2.9.1 out really soon, so we can catch up with 3.0 and do more than
just port over logic from Java to C# -- but also take advantage of what C#
and .NET has to offer.
BTW, those kind of discussions should be on the dev side vs. user.
-- George
-----Original Message-----
From: Digy [mailto:digydigy@gmail.com]
Sent: Monday, November 09, 2009 1:19 PM
To: lucene-net-user@incubator.apache.org
Subject: RE: 2.9 Target Framework
I think we should stick to .NET 2.0 till Lucene 3.0 which can be a good
place to switch to .NET 3.5 (so will Lucene.Java do also).
There are also a lot of places where smarter codes can be used ( replacing
"GetEnumerator+while" with "foreach", implementing a .NET like "Set" instead
of using Hashtable etc.) But it can be a problem in porting unless we catch
up with Lucene.Java.
DIGY
-----Original Message-----
From: Michael Garski [mailto:mgarski@myspace-inc.com]
Sent: Monday, November 09, 2009 7:26 PM
To: lucene-net-dev@incubator.apache.org;
lucene-net-user@incubator.apache.org
Subject: 2.9 Target Framework
Apologies for the cross-posting to both lists, but I think this issue is
applicable to both.
What is the target framework for Lucene.Net 2.9? I'm assuming 2.0 but
would like to ensure this is defined. There are a few cases in some of
the internal implementation where use of LINQ would be handy, such as in
collection transformations to arrays. Overall, it's not a big deal to
target 2.0 however some of the implementation will be a bit more elegant
and precise if we target 3.5.
Cheers,
Michael
Michael Garski
Sr. Search Architect
310.969.7435 (office)
310.251.6355 (mobile)
www.myspace.com/michaelgarski
RE: 2.9 Target Framework
Posted by George Aroush <ge...@aroush.net>.
I agree with DIGY. We have discussed this in the past few times. We have
to get 2.9.1 out really soon, so we can catch up with 3.0 and do more than
just port over logic from Java to C# -- but also take advantage of what C#
and .NET has to offer.
BTW, those kind of discussions should be on the dev side vs. user.
-- George
-----Original Message-----
From: Digy [mailto:digydigy@gmail.com]
Sent: Monday, November 09, 2009 1:19 PM
To: lucene-net-user@incubator.apache.org
Subject: RE: 2.9 Target Framework
I think we should stick to .NET 2.0 till Lucene 3.0 which can be a good
place to switch to .NET 3.5 (so will Lucene.Java do also).
There are also a lot of places where smarter codes can be used ( replacing
"GetEnumerator+while" with "foreach", implementing a .NET like "Set" instead
of using Hashtable etc.) But it can be a problem in porting unless we catch
up with Lucene.Java.
DIGY
-----Original Message-----
From: Michael Garski [mailto:mgarski@myspace-inc.com]
Sent: Monday, November 09, 2009 7:26 PM
To: lucene-net-dev@incubator.apache.org;
lucene-net-user@incubator.apache.org
Subject: 2.9 Target Framework
Apologies for the cross-posting to both lists, but I think this issue is
applicable to both.
What is the target framework for Lucene.Net 2.9? I'm assuming 2.0 but
would like to ensure this is defined. There are a few cases in some of
the internal implementation where use of LINQ would be handy, such as in
collection transformations to arrays. Overall, it's not a big deal to
target 2.0 however some of the implementation will be a bit more elegant
and precise if we target 3.5.
Cheers,
Michael
Michael Garski
Sr. Search Architect
310.969.7435 (office)
310.251.6355 (mobile)
www.myspace.com/michaelgarski
RE: 2.9 Target Framework
Posted by George Aroush <ge...@aroush.net>.
I agree with DIGY. We have discussed this in the past few times. We have
to get 2.9.1 out really soon, so we can catch up with 3.0 and do more than
just port over logic from Java to C# -- but also take advantage of what C#
and .NET has to offer.
BTW, those kind of discussions should be on the dev side vs. user.
-- George
-----Original Message-----
From: Digy [mailto:digydigy@gmail.com]
Sent: Monday, November 09, 2009 1:19 PM
To: lucene-net-user@incubator.apache.org
Subject: RE: 2.9 Target Framework
I think we should stick to .NET 2.0 till Lucene 3.0 which can be a good
place to switch to .NET 3.5 (so will Lucene.Java do also).
There are also a lot of places where smarter codes can be used ( replacing
"GetEnumerator+while" with "foreach", implementing a .NET like "Set" instead
of using Hashtable etc.) But it can be a problem in porting unless we catch
up with Lucene.Java.
DIGY
-----Original Message-----
From: Michael Garski [mailto:mgarski@myspace-inc.com]
Sent: Monday, November 09, 2009 7:26 PM
To: lucene-net-dev@incubator.apache.org;
lucene-net-user@incubator.apache.org
Subject: 2.9 Target Framework
Apologies for the cross-posting to both lists, but I think this issue is
applicable to both.
What is the target framework for Lucene.Net 2.9? I'm assuming 2.0 but
would like to ensure this is defined. There are a few cases in some of
the internal implementation where use of LINQ would be handy, such as in
collection transformations to arrays. Overall, it's not a big deal to
target 2.0 however some of the implementation will be a bit more elegant
and precise if we target 3.5.
Cheers,
Michael
Michael Garski
Sr. Search Architect
310.969.7435 (office)
310.251.6355 (mobile)
www.myspace.com/michaelgarski
RE: 2.9 Target Framework
Posted by "Nicholas Paldino [.NET/C# MVP]" <ca...@caspershouse.com>.
Digy,
It's serendipity that this is the first email that I receive in
joining this group, as the reason I joined was because I found that I very
much don't like the API or some of the translations from the Java version of
Lucene.
To that end, I've taken the stable release (2.0) and started to do a
port to 3.5 (although most of it is 2.0 compliant, I use LINQ in very few
places), addressing most of the following at this point:
- Proper implementation of IDisposable over Close methods
- Proper implementation of IEnumerable<T> and replacing for with foreach
loops
- Use of LINQ in some places in order to make code more declarative
(e.g. flatting out nested loops)
- Removed use of Join method on the Thread class (it is depreciated),
replaced with other .NET synchronization primitives.
- Replacing ArrayList and Hashtable with List<T> and Dictionary<TKey,
TValue> instances
- Using generic versions vs non-generic versions, especially when a
type parameter is a structure provides massive performance gains (due to
lack of boxing)
- Where synchronized versions were used, locks were put into place
at appropriate areas to lock access
- Lock scope was expanded to ensure that multiple operations
on the same synchronized resource is atomic
- Implementing .NET types where appropriate
- e.g. ScoreDocComparator becomes IScoreDocComparer, deriving from
IComparer<ScoreDoc>
- Methods that override Equals implement IEquatable<T>, and
possibly, IComparable<T>
- Condensing types
- e.g. ICharStream is defined twice.
The list goes on of course. But these are some of the biggies. I'm
currently getting the source from SVN, and seeing where I can contribute
without causing too much of a fuss. =)
- Nick
-----Original Message-----
From: Digy [mailto:digydigy@gmail.com]
Sent: Monday, November 09, 2009 1:19 PM
To: lucene-net-user@incubator.apache.org
Subject: RE: 2.9 Target Framework
I think we should stick to .NET 2.0 till Lucene 3.0 which can be a good
place to switch to .NET 3.5 (so will Lucene.Java do also).
There are also a lot of places where smarter codes can be used ( replacing
"GetEnumerator+while" with "foreach", implementing a .NET like "Set" instead
of using Hashtable etc.) But it can be a problem in porting unless we catch
up with Lucene.Java.
DIGY
-----Original Message-----
From: Michael Garski [mailto:mgarski@myspace-inc.com]
Sent: Monday, November 09, 2009 7:26 PM
To: lucene-net-dev@incubator.apache.org;
lucene-net-user@incubator.apache.org
Subject: 2.9 Target Framework
Apologies for the cross-posting to both lists, but I think this issue is
applicable to both.
What is the target framework for Lucene.Net 2.9? I'm assuming 2.0 but
would like to ensure this is defined. There are a few cases in some of
the internal implementation where use of LINQ would be handy, such as in
collection transformations to arrays. Overall, it's not a big deal to
target 2.0 however some of the implementation will be a bit more elegant
and precise if we target 3.5.
Cheers,
Michael
Michael Garski
Sr. Search Architect
310.969.7435 (office)
310.251.6355 (mobile)
www.myspace.com/michaelgarski
RE: 2.9 Target Framework
Posted by Digy <di...@gmail.com>.
I think we should stick to .NET 2.0 till Lucene 3.0 which can be a good
place to switch to .NET 3.5 (so will Lucene.Java do also).
There are also a lot of places where smarter codes can be used ( replacing
"GetEnumerator+while" with "foreach", implementing a .NET like "Set" instead
of using Hashtable etc.) But it can be a problem in porting unless we catch
up with Lucene.Java.
DIGY
-----Original Message-----
From: Michael Garski [mailto:mgarski@myspace-inc.com]
Sent: Monday, November 09, 2009 7:26 PM
To: lucene-net-dev@incubator.apache.org;
lucene-net-user@incubator.apache.org
Subject: 2.9 Target Framework
Apologies for the cross-posting to both lists, but I think this issue is
applicable to both.
What is the target framework for Lucene.Net 2.9? I'm assuming 2.0 but
would like to ensure this is defined. There are a few cases in some of
the internal implementation where use of LINQ would be handy, such as in
collection transformations to arrays. Overall, it's not a big deal to
target 2.0 however some of the implementation will be a bit more elegant
and precise if we target 3.5.
Cheers,
Michael
Michael Garski
Sr. Search Architect
310.969.7435 (office)
310.251.6355 (mobile)
www.myspace.com/michaelgarski
RE: Does QueryParser Require Upper Case Operators
Posted by Digy <di...@gmail.com>.
No, they shouldn't be same.
See the difference:
Lucene.Net.QueryParsers.QueryParser p = new
Lucene.Net.QueryParsers.QueryParser("", new
Lucene.Net.Analysis.WhitespaceAnalyzer());
Console.WriteLine( p.Parse("(oil or petroleum) and prices").ToString() );
Console.WriteLine( p.Parse("(oil OR petroleum) AND prices").ToString() );
DIGY
-----Original Message-----
From: T. R. Halvorson [mailto:trh@midrivers.com]
Sent: Monday, November 09, 2009 8:23 PM
To: lucene-net-user@incubator.apache.org
Subject: Does QueryParser Require Upper Case Operators
Hi all. I'm new and asking a beginner's question that I have not found
answered in the archives.
Documentation I have says the QueryParser needs the operators AND, OR,
etc. to be in upper case. In an application under development, however,
lower case seems to produce correct results in initial tests. I.e.,
(oil or petroleum) and prices
is producing the same results as
(oil OR petroleum) AND prices
T. R. Halvorson
trh@midrivers.com
www.linkedin.com/in/trhalvorson
www.ncodian.com
http://twitter.com/trhalvorson
Does QueryParser Require Upper Case Operators
Posted by "T. R. Halvorson" <tr...@midrivers.com>.
Hi all. I'm new and asking a beginner's question that I have not found
answered in the archives.
Documentation I have says the QueryParser needs the operators AND, OR,
etc. to be in upper case. In an application under development, however,
lower case seems to produce correct results in initial tests. I.e.,
(oil or petroleum) and prices
is producing the same results as
(oil OR petroleum) AND prices
T. R. Halvorson
trh@midrivers.com
www.linkedin.com/in/trhalvorson
www.ncodian.com
http://twitter.com/trhalvorson