[
https://issues.apache.org/jira/browse/LUCENE-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508119#comment-13508119
]
Steven Rowe edited comment on LUCENE-4584 at 12/2/12 12:33 AM:
---------------------------------------------------------------
bq. Steven: We are a Java project and we have no platform independent way to
run C code. I think Adrien's idea is enough, maybe use 2 or 3 different length
examples. Just like Apache TIKA parading MS Office docs, they also don't start
MS Office while testing ♥
I agree Adrien's idea is enough, and in any case is better than what we have
now (pnp), but I still think cross-impl testing would be nice.
cpp-tasks is used to compile NativePosixUtil.cpp, so there is precedent for
this in our project...
bq. I'm a little worried about adding the sources of LZ4 and a task to compile
C code to the lucene-core build (or maybe I could do these LZ4 tests in a
dedicated module so that it doesn't make lucene-core depend on native code?).
I think it would be fine to include test-only native code in lucene-core tests,
as long as compilation and testing were both fast.
bq. I think we should also compare the output bytes to make sure the compressor
is efficient. [...] Given that the LZ4 output depends on the endianess of the
machine, this can unfortunately only be done with static files.
You wouldn't need static files if you compared output lengths, though
correctness would of course no longer be implied.
was (Author: steve_rowe):
bq. Steven: We are a Java project and we have no platform independent way
to run C code. I think Adrien's idea is enough, maybe use 2 or 3 different
length examples. Just like Apache TIKA parading MS Office docs, they also don't
start MS Office while testing ♥
I agree Adrien's idea is enough, and in any case is better than what we have
now (pnp), but I still think cross-impl testing would be nice.
cpp-tasks is used to compile NativeUnixDirectory.cpp, so there is precedent for
this in our project...
bq. I'm a little worried about adding the sources of LZ4 and a task to compile
C code to the lucene-core build (or maybe I could do these LZ4 tests in a
dedicated module so that it doesn't make lucene-core depend on native code?).
I think it would be fine to include test-only native code in lucene-core tests,
as long as compilation and testing were both fast.
bq. I think we should also compare the output bytes to make sure the compressor
is efficient. [...] Given that the LZ4 output depends on the endianess of the
machine, this can unfortunately only be done with static files.
You wouldn't need static files if you compared output lengths, though
correctness would of course no longer be implied.
> Compare the LZ4 implementation in Lucene against the original impl
> ------------------------------------------------------------------
>
> Key: LUCENE-4584
> URL: https://issues.apache.org/jira/browse/LUCENE-4584
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Priority: Blocker
> Fix For: 4.1
>
>
> We should add tests to make sure that the LZ4 impl in Lucene compresses data
> the exact same way as the original impl.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
