lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prescott Nasser (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENENET-380) Evaluate Sharpen as a port tool
Date Thu, 25 Nov 2010 19:53:16 GMT

    [ https://issues.apache.org/jira/browse/LUCENENET-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935856#action_12935856
] 

Prescott Nasser commented on LUCENENET-380:
-------------------------------------------

IndexWriter.java to IndexWriter.cs (Sharpen) - thoughts and observations

Some generic comments:
1. Some comments that are nexted withint methods and functions get moved around. Some are
merged with the summaries of the next function, not a big deal
2. With asserts commented out BEFORE the conversion, sometimes they get moved to incorrect
places (part of 1). 
   Check out lines 3224(java) and 4242(.cs). This shoudln't be to hard to diagnose, once we
determine how we are going to
   convert assert to .net, we can do a quick search for assert to find these kinds of things
3. Sharpen libraries show up a few places - my intuition says that we need to get rid of those?
Am I correct on that?
3. formatting needs some work imo
4. The CS - SetDiagnostics(...) just feels wrong :) - diagnostics["java.vendor"] = ..

I think the biggest question in my head is how do we deal with the asserts - the rest seems
ok to me.


Specifics:

IndexWriter.java
line 506: final int numSegments = infos.size();
IndexWriter.cs
line 622: int numSegments = infos.Count;

Is this missing a final? (does it matter?) This happens in a number of places.

IndexWriter.java
line 786:     notifyAll();
IndexWriter.cs
line 1018: Sharpen.Runtime.NotifyAll(this);

Why is Sharpen referenced here? Is this just part of the assertion stuff? I don't think
we want to have this line in the final build.

IndexWriter.java
line 789: synchronized final boolean isOpen(boolean includePendingClose) {
IndexWriter.cs
line 1022: 		internal bool IsOpen(bool includePendingClose)

The method declaration is fine - the question I have is in the implimentation, for c# it
uses the lock (this) to replace the synchronized java keyword - but then it's statment is:
return !(closed || (includePendingClose && closing));

In other cases, it would be this.closed, and this.closing (or this._enclosing.closed).. 
this shows up a number of other places. It's likely my misunderstanding of how locking works

in c#, but wouldn't we want the this. infront of those?

This happens in a few places

IndexWriter.java
line 1575: synced.addAll(segmentInfos.files(directory, true));
IndexWriter.cs
line 2102: 	Sharpen.Collections.AddAll(synced, segmentInfos.Files(directory, true));

Again we reference Sharpen here - I'm not sure why, but my intuition says this is not what
we want.
(search on Sharpen. turns this up a number of places)


> Evaluate Sharpen as a port tool
> -------------------------------
>
>                 Key: LUCENENET-380
>                 URL: https://issues.apache.org/jira/browse/LUCENENET-380
>             Project: Lucene.Net
>          Issue Type: Task
>            Reporter: George Aroush
>         Attachments: 3.0.2_JavaToCSharpConverter_AfterPostProcessing.zip, 3.0.2_JavaToCSharpConverter_NoPostProcessing.zip,
IndexWriter.java, Lucene.Net.Sharpen20101104.zip, Lucene.Net.Sharpen20101114.zip, NIOFSDirectory.java,
QueryParser.java, TestBufferedIndexInput.java, TestDateFilter.java
>
>
> This task is to evaluate Sharpen as a port tool for Lucene.Net.
> The files to be evaluated are attached.  We need to run those files (which are off Java
Lucene 2.9.2) against Sharpen and compare the result against JLCA result.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message