lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Svensson <si...@devhost.se>
Subject Re: Porting questions
Date Fri, 02 May 2014 17:58:08 GMT
That sounds like a Plugin of Pure Awesome.

Anyhow, I've commited some stuff at 
https://github.com/sisve/lucene.net/commits/contrib-hunspell

I changed the CharFilter to derive from TextReader instead of 
StreamReader and excluded tests from the Contrib.Test project, and 
everything that's still left compiles and pass the few tests that are 
present. There's one test for the core assembly which fails, looks like 
issues with RandomizedContext and testing infrastructure related.

Q: Are the sources in Contrib/Contrib.Tests old 3.0.3-sources? Then my 
next step would be to port the 4.3.0 java-sources (for the hunspell 
code) before submitting a pull request.

Q: The ICharTermAttribute lacks functionality for working with strings. 
This may be an issue due to previous question, the code I got running 
used String ITermAttribute.Term and not Char[]. Anyhow, should we add 
convenience methods to work with strings directly, or force callers to 
either with Char[] or do their own String.ToCharArray() calls?

// Simon


On 01/05/14 22:02, Itamar Syn-Hershko wrote:
> Yes, this is why we are working towards having a good R# plugin that will
> let us do Java to C# porting easily, taking into account things like you
> mention. This may already be supported by Paul's library by the way, and if
> it isn't it can certainly be added to it. The R# plugin we plan on having
> will be based on that. I hope to have more news in the upcoming weeks.
>
> Personally I couldn't care less about curly brackets, but we should decide
> on whitespaces/tabs and use stylecop or similar to enforce that, for
> readability sake
>
> --
>
> Itamar Syn-Hershko
> http://code972.com | @synhershko <https://twitter.com/synhershko>
> Freelance Developer & Consultant
> Author of RavenDB in Action <http://manning.com/synhershko/>
>
>
> On Thu, May 1, 2014 at 4:17 PM, Simon Svensson <sisve@devhost.se> wrote:
>
>> Outline!
>>
>> Regarding the extension methods mentioned at the end, I'm talking about
>> introducing such a class/helper into the core Lucene.Net assembly for use
>> of non-test assemblies. Those I've found so far (JavaCompatilibity/*.cs in
>> Lucene.Test.Framework) are for tests only. Your mails from April 20th
>> indicate that the purpose of such helper methods are for quick porting of
>> tests only.
>>
>> One example would be the java substring function. I've been bitten several
>> times (and never seem to learn) that the parameters are different between
>> java and .net.
>>
>>          [Obsolete("Call String.Substring instead. Note that Java uses
>> start+end while .NET uses start+length")]
>>          public static String substring(this String value, Int32 start,
>> Int32 end) {
>>              return value.Substring(start, end - start + 1);
>>          }
>>
>> On another line of thought, are there any code formatting rules or plugins
>> that helps? I believe Resharper/StyleCop supports storing code formatting
>> settings in a file that can be commited so we're producing similar looking
>> code. Or should we start a religious war about curly braces and
>> whitespaces? ;)
>>
>> // Simon
>>
>>
>>
>> On 01/05/14 14:23, Itamar Syn-Hershko wrote:
>>
>>> inline
>>>
>>> --
>>>
>>> Itamar Syn-Hershko
>>> http://code972.com | @synhershko <https://twitter.com/synhershko>
>>> Freelance Developer & Consultant
>>> Author of RavenDB in Action <http://manning.com/synhershko/>
>>>
>>>
>>>
>>> On Thu, May 1, 2014 at 9:42 AM, Simon Svensson <sisve@devhost.se> wrote:
>>>
>>>   Hi,
>>>> I've once again woken up thinking that I should stop lurking and start
>>>> coding.
>>>>
>>>> Could someone confirm that I am going about this in a correct way?
>>>> 1) I've forked the repository to sisve/lucene.net (added remote as
>>>> origin)
>>>> 2) I've added another remote for apache/lucene.net named upstream
>>>> 3) I'm using the branch named "branch_4x"
>>>>
>>>>   yes
>>>
>>>   Q: Do we work by coding in our personal repos and sending pull request to
>>>> apache/lucene.net? Or are we pushing directly to apache/lucene.net?
>>>>
>>>>   The best way to work is by creating branch-per-feature or porting job or
>>> whatever and then sending a PR to apache/lucene.net. Then notify us in
>>> the
>>> mailing list (or open a JIRA ticket, but I think discussions on the GitHub
>>> repos are much easier to work with).
>>>
>>> After discussions and possibly some revisions (by pushing more commits to
>>> your branch) we can merge to branch_4x in upstream and once it will be
>>> synced with the github mirror (it takes it 30 mins or so) the PR will be
>>> automatically marked as closed.
>>>
>>>
>>>   Q: Is the mirroring against the apache-hosted lucene.net repository
>>>> automatic?
>>>>
>>>>   Yes
>>>
>>>   When opening the Lucene.Net.sln file, hosting only Lucene.Net,
>>>> Lucene.Net.Tests and Lucene.Net.TestFramework, I have a suspiciously low
>>>> number of tests, only 24 (of which 3 fails). (At least it compiles.)
>>>>
>>>>   Someone (I think Paul) removed them from the solution, and the work now
>>> is
>>> on bringing them back in mostly by re-porting them
>>>
>>>
>>>   Q: Am I doing something wrong, or is this the current state?
>>>> Since I've had some run-ins with the hunspell analyzer (a long long time
>>>> ago) I thought that I should look into the contrib solution and see
>>>> what's
>>>> needed. I'm quickly informed by Resharper's solution-wide analysis "[n]
>>>> errors in [m] files", where [n] and [m] > 0.
>>>>
>>>> I'm thinking that the first step is to introduce a big
>>>> PortingHelper.cs-file with extension methods matching the java api,
>>>> forward
>>>> them to the correct .net api (usually just casing- or minor changes), and
>>>> marking these helper extension methods as obsolete. This would both allow
>>>> stuff to compile, and give hints to whoever ports/fixes the classes about
>>>> the ".net way" to do whatever is being done. This PortingHelper.cs-file
>>>> should not be present when we're done (doh!).
>>>>
>>>> Q: Does this seem reasonable? The goal is to make everything compile
>>>> (even
>>>> with obsolete-warnings) so that the tests can tell the status of things.
>>>>
>>> Please read up on the mailing list and look at the most recent commits. We
>>> are already doing that.
>>>
>>>
>>>
>>>> // Simon
>>>>
>>>>
>>>>


Mime
View raw message