Re: Plans for Hunspell integration (and: How do I build the trunk?)

[Simon Svensson]

I've found the issue; I'm running with CurrentCulture = sv_SE, and the 
tests presumes a culture that can parse "0.7". I've reported this as 
https://issues.apache.org/jira/browse/LUCENENET-490. This looks like a 
regression, the problem does not exist in 2.9.4.

What's the cleanest way to change these tests into using several 
cultures? Having an array of cultures to use, and iterating it in every 
test, sounds ... unclean. The SetCulture-attribute doesn't seem to work 
(perhaps a R# limitation), and it would still require duplication of 
test for every culture.

On 2012-05-29 20:03, Christopher Currens wrote:
I can't reproduce the failed tests in TestQueryParser.TestWildCard.  Works
for me in both debug and release builds, running via R# and Gallio.

On Tue, May 29, 2012 at 10:45 AM, Prescott Nasser<geobmx...@hotmail.com>wrote:


my intentions to move this code into contrib, which brings the first of
many questions; should it be added to Contrib.Analyzers, or a new
project?

Analyzers sounds like the right space for it.

I'm currently experimenting with the build environment and making sure
that all tools work properly on my machine. However, I'm greeted with
several execution errors when executing a "build simple all release";
tests for SimpleFacetedSearch and SpellChecker calls non-existant
overload of IndexReader.Open and Memory tests have wrong assembly name
and output path. The build will proceed if I fix these errors, but some
tests fail. (one being TestQueryParser.TextWildCard with "Query
/term~0.7/ yielded /term~0.5/, expecting /term~0.7/"). These tests do
also fail in Resharpers unittest-runner.
I'll try to take a look at this this week. We've mostly been focusing on
the core, and I know that the contrib packages have started to fall to the
wayside. We need to take a good look at them, make sure they are the right
ports, and make the fixes to adjust to our api. If you do notice problems,
I'd encourage you to at the very least throw up a JIRA issue. If it turns
out it's not a problem, we can always close it.
I've tried "build commit all release" (from the build information wiki
page[3]) which fails with "NCover v3 does not appear to be installed".
This is correct; I've been unable to find a free version of a NCover v3.
Is the commit build target perhaps only meant for build servers?
I think it was Michael who did all the work around the build system, I
still build the old fashioned way... VS2010 - right click, build.

I've copied lib\StyleCop.4.5 to C:\Program Files
(x86)\MSBuild\StyleCop\v4.5 to remove the
stylecop-4.5-could-not-be-found warnings. I expect to get a gazillion
stylecop-related warnings when building (stylecop has never really liked
me), but get none at all. Is the code perfect, or are no rules applied?
That's a good question, we discussed style cop at one point, but I don't
think we every had a consensus on that.