lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Svensson <si...@devhost.se>
Subject Re: Plans for Hunspell integration (and: How do I build the trunk?)
Date Tue, 29 May 2012 19:10:42 GMT
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<geobmx540@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.
>>

Mime
View raw message