lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George Aroush" <geo...@aroush.net>
Subject RE: 2.9 Target Framework
Date Tue, 10 Nov 2009 12:48:19 GMT
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







Mime
View raw message