lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <ita...@code972.com>
Subject Re: Porting questions
Date Sat, 03 May 2014 17:47:48 GMT
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 Fri, May 2, 2014 at 8:58 PM, Simon Svensson <sisve@devhost.se> wrote:

> 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.
>

Most of them, yes.

See my previous email on porting tests, generally it should now be mostly
copy-paste-minor fixes operation



>
> 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?


This is a change on the Java part of things, for performance reasons, to
allow for in-place editing. You actually should keep it this way and port
the relevant changes made to the TokenFilter implementations


>
>
> // 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message