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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>> 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 >>>>> >>>>> >>>>> >>>>> >
