[jira] Updated: (LUCENE-1410) PFOR implementation
[ https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Renaud Delbru updated LUCENE-1410: -- Attachment: for-summary.txt File containing a summary of the results for each bit frame, based on variants of FOR. > PFOR implementation > --- > > Key: LUCENE-1410 > URL: https://issues.apache.org/jira/browse/LUCENE-1410 > Project: Lucene - Java > Issue Type: New Feature > Components: Other >Reporter: Paul Elschot >Priority: Minor > Attachments: autogen.tgz, for-summary.txt, > LUCENE-1410-codecs.tar.bz2, LUCENE-1410b.patch, LUCENE-1410c.patch, > LUCENE-1410d.patch, LUCENE-1410e.patch, TermQueryTests.tgz, TestPFor2.java, > TestPFor2.java, TestPFor2.java > > Original Estimate: 21840h > Remaining Estimate: 21840h > > Implementation of Patched Frame of Reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1410) PFOR implementation
[ https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-1410: --- Attachment: LUCENE-1410-codecs.tar.bz2 Attaching sep, intblock and pfordelta codecs, spun out of the last patch on LUCENE-1458. Once LUCENE-1458 is in, we should finish the pfordelta codec to make it a real choice. I actually think some combination of pulsing, standard, pfordelta and simple bit packing (in order by increasing term's docFreq), within a single codec, may be best. Ie, rare terms (only in a doc or two) could be inlined into the the terms dict. Slightly more common terms can use the more CPU intensive standard codec. Common terms can use cpu-friendly-yet-still-decent-compression pfordelta. Obsenely common terms can use bit packing for the fastest decode. > PFOR implementation > --- > > Key: LUCENE-1410 > URL: https://issues.apache.org/jira/browse/LUCENE-1410 > Project: Lucene - Java > Issue Type: New Feature > Components: Other >Reporter: Paul Elschot >Priority: Minor > Attachments: autogen.tgz, LUCENE-1410-codecs.tar.bz2, > LUCENE-1410b.patch, LUCENE-1410c.patch, LUCENE-1410d.patch, > LUCENE-1410e.patch, TermQueryTests.tgz, TestPFor2.java, TestPFor2.java, > TestPFor2.java > > Original Estimate: 21840h > Remaining Estimate: 21840h > > Implementation of Patched Frame of Reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1410) PFOR implementation
[ https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Elschot updated LUCENE-1410: - Attachment: LUCENE-1410e.patch The 1410e patch splits off a FrameOfRef class as the superclass from the PFor class. Test cases are split similarly, all added test cases pass. This should make it easier to chose between the patching version PFor and the non patching version FrameOfRef. There lots of small changes compared to the 1410d patch, mostly in the o.a.l.util.pfor package, and a few in the util package. Some javadocs are added, but javadoc generation is not yet tested. After applying the patch, run gendecompress.py as for the 1410b patch to generate the java sources for decompression. Then: ant -Dtestcase=TestFrameOfRef test-core and ant -Dtestcase=TestPFor test-core should pass. The following (at least) is still to be done: - peformance tests for patching decompression, - relative compressed data buffer addressing, - generate code for compression in the same way as for decompression, - a few fixme's and checkme's in the code, - javadoc generation. > PFOR implementation > --- > > Key: LUCENE-1410 > URL: https://issues.apache.org/jira/browse/LUCENE-1410 > Project: Lucene - Java > Issue Type: New Feature > Components: Other >Reporter: Paul Elschot >Priority: Minor > Attachments: autogen.tgz, LUCENE-1410b.patch, LUCENE-1410c.patch, > LUCENE-1410d.patch, LUCENE-1410e.patch, TermQueryTests.tgz, TestPFor2.java, > TestPFor2.java, TestPFor2.java > > Original Estimate: 21840h > Remaining Estimate: 21840h > > Implementation of Patched Frame of Reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1410) PFOR implementation
[ https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Elschot updated LUCENE-1410: - Attachment: LUCENE-1410d.patch 1410d patch: as 1410c, with the following further changes: - moved exceptions to their natural borders, - unrolled exception patching code, - some more testcases for exceptions, - a specialized version for "decompressing" with 32 frame bits, - all other frame decompression is left to generated code (not contained in the patch), - compressed and decompressed sizes are now reported in numbers of integers, - also contains an adapted version of TestPFor2. This should diminish the difference in performance between PFOR and BITS (which is actually just FOR, unpatched Frame Of Reference.). > PFOR implementation > --- > > Key: LUCENE-1410 > URL: https://issues.apache.org/jira/browse/LUCENE-1410 > Project: Lucene - Java > Issue Type: New Feature > Components: Other >Reporter: Paul Elschot >Priority: Minor > Attachments: autogen.tgz, LUCENE-1410b.patch, LUCENE-1410c.patch, > LUCENE-1410d.patch, TermQueryTests.tgz, TestPFor2.java, TestPFor2.java, > TestPFor2.java > > Original Estimate: 21840h > Remaining Estimate: 21840h > > Implementation of Patched Frame of Reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1410) PFOR implementation
[ https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-1410: --- Attachment: TermQueryTests.tgz In order to understand how time is spent overall during searching, I took TermQuery and reimplemented it in several different ways. While each implementatation is correct (checksum of final top N docs matches) they are very much prototypes and nowhere near committable. I then took the 100 most frequent terms (total 23.3 million hits) from my Wikipedia index and ran them each in sequence. Each result is best of 25 runs (all results are from the OS's IO cache): ||Test||Time (msec)||Hits/msec||Speedup|| |Baseline|674|34496|1.00X| |+ Code Speedups|591|39340|1.14X| |+ Code Speedups + PFOR|295|78814|2.28X| |+ Code Speedups + BITS|247|94130|2.73X| |+ Code Speedups + BITS (native)|230|101088|2.93X| Here's what the test names mean: * Baseline is the normal TermQuery, searching with TopDocsCollector for top 10 docs. * Code Speedups means some basic optimizations, eg made my own specialized priority queue, unrolled loops, etc. * PFOR means switching to PFOR for storing docs & freqs as separate streams. Each term's posting starts a new PFOR block. * BITS just means using packed n-bit ints for each block (ie, it has no exceptions, so it sets N so that all ints will fit). The resulting frq file was 18% bigger and doc file was 10% bigger -- but this is just for the 100 most frequent terms. * BITS (native) is BITS but running as JNI (C++) code. Next, I tried running the same things above, but I turned off collection of hits. So this really just tests decode time: ||Test||Time (msec)||Hits/msec||Speedup|| |+ Code Speedups|384|60547|1.76X| |+ Code Speedups + PFOR|91|255497|7.41X| |+ Code Speedups + BITS|49|474496|13.76X| |+ Code Speedups + BITS (native)|32|726572|21.06X| Some observations: * PFOR really does speed up TermQuery overall, so, I think we should pursue it and get it committed. * BITS is a good speedup beyond PFOR, but we haven't optimized PFOR yet. Also, BITS would be very seekable. We could also use PFOR but increase the bit size of blocks, to get the same thing. * Once we swap in PFOR and/or BITS or other interesting int block compression, accumulating hits becomes the slowest part of TermQuery. * Native BITS decoding code is quite a bit faster for decoding, but, probably not worth pursuing for now since with PFOR decode time becomes a small part of the overall time. * TermQuery is the simplest query; other queries will spend more CPU time coordinating, or time handling positions, so we can't yet conclude how much of an impact PFOR will have on them. > PFOR implementation > --- > > Key: LUCENE-1410 > URL: https://issues.apache.org/jira/browse/LUCENE-1410 > Project: Lucene - Java > Issue Type: New Feature > Components: Other >Reporter: Paul Elschot >Priority: Minor > Attachments: autogen.tgz, LUCENE-1410b.patch, LUCENE-1410c.patch, > TermQueryTests.tgz, TestPFor2.java, TestPFor2.java, TestPFor2.java > > Original Estimate: 21840h > Remaining Estimate: 21840h > > Implementation of Patched Frame of Reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1410) PFOR implementation
[ https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Elschot updated LUCENE-1410: - Attachment: LUCENE-1410c.patch The 1410c patch is much like the 1410b. It adds some bug fixes and code cleanups and it includes a generator for java decompression classes. After applying the patch, run the generator once in src/java/org/apache/lucene/util/pfor : python gendecompress.py After that, in the trunk directory: ant -Dtestcase=TestPFor test-core should finish successfully in just over a minute, as it also includes decompression performance tests. To be done: - possibly split the performance tests from the functional tests, this might require adding an ant target for performance tests, - possibly add byte padding to move exceptions to natural position, - add performance tests for decompression with exception patching, - switch decompression to relative buffer addressing (get() instead of get(index)), - optimize the exception decoding (i.e. patching) code, - optimize the compression code, - generate/correct the javadocs. > PFOR implementation > --- > > Key: LUCENE-1410 > URL: https://issues.apache.org/jira/browse/LUCENE-1410 > Project: Lucene - Java > Issue Type: New Feature > Components: Other >Reporter: Paul Elschot >Priority: Minor > Attachments: autogen.tgz, LUCENE-1410b.patch, LUCENE-1410c.patch, > TestPFor2.java, TestPFor2.java, TestPFor2.java > > Original Estimate: 21840h > Remaining Estimate: 21840h > > Implementation of Patched Frame of Reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1410) PFOR implementation
[ https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-1410: --- Attachment: autogen.tgz Woops I forgot the attachment... > PFOR implementation > --- > > Key: LUCENE-1410 > URL: https://issues.apache.org/jira/browse/LUCENE-1410 > Project: Lucene - Java > Issue Type: New Feature > Components: Other >Reporter: Paul Elschot >Priority: Minor > Attachments: autogen.tgz, LUCENE-1410b.patch, TestPFor2.java, > TestPFor2.java, TestPFor2.java > > Original Estimate: 21840h > Remaining Estimate: 21840h > > Implementation of Patched Frame of Reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1410) PFOR implementation
[ https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-1410: --- Attachment: TestPFor2.java Attached new TestPfor2.java: - If you run it on _x.frq, it will split that into _x.frq.frq and _x.frq.doc so we can separately test frq vs docs - Added checksum. - Added zeroing of reused IntBuffer before calling PFor.compress (seems to be necessary? Else I trip an assert inside PFor). Paul, indeed I get a different checksum for vint vs pfor decoding. I think the bug is somewhere in pfor, I'm guessing in the exception logic, because the difference I see is suddenly pfor returns 0 when it should have returned a large int relative to the other ints nearby. Maybe this is why exception processing looked so much faster :) I'll hold off posting more perf results until we can resolve that. To see the checksum run it with asserts, eg like this: java -ea oal.util.pfor.TestPFor2 /path/to/index _x.prx It then prints out SUM lines after each iteration. If you set DEBUG = true, it'll print the first 1000 values and then search for "v=0". > PFOR implementation > --- > > Key: LUCENE-1410 > URL: https://issues.apache.org/jira/browse/LUCENE-1410 > Project: Lucene - Java > Issue Type: New Feature > Components: Other >Reporter: Paul Elschot >Priority: Minor > Attachments: LUCENE-1410b.patch, TestPFor2.java, TestPFor2.java, > TestPFor2.java > > Original Estimate: 21840h > Remaining Estimate: 21840h > > Implementation of Patched Frame of Reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1410) PFOR implementation
[
https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1410:
---
Attachment: TestPFor2.java
New TestPFor2 attached. I changed vInt -> int in the prints and now
compute "best" bit size per-block using getNumFrameBits() and use that
per block.
I took a big frq file and computed %tg for each #bits:
||bits||count||pct||
|1|0|0.0|
|2|24328|0.9|
|3|94689|3.7|
|4|213887|8.4|
|5|277510|10.8|
|6|284905|11.1|
|7|193081|7.5|
|8|262857|10.3|
|9|260460|10.2|
|10|212046|8.3|
|11|162872|6.4|
|12|109801|4.3|
|13|77366|3.0|
|14|56620|2.2|
|15|34294|1.3|
|16|31000|1.2|
|17|28803|1.1|
|18|21617|0.8|
|19|22317|0.9|
|20|30326|1.2|
|21|162663|6.4|
And for prx:
||bits||count||pct||
|1|23034|0.7|
|2|12637|0.4|
|3|49286|1.4|
|4|56344|1.6|
|5|69385|2.0|
|6|81964|2.4|
|7|108847|3.1|
|8|179296|5.2|
|9|428787|12.4|
|10|873828|25.2|
|11|957913|27.7|
|12|534426|15.4|
|13|81856|2.4|
|14|2436|0.1|
|15|474|0.0|
|16|200|0.0|
|17|43|0.0|
|18|17|0.0|
|19|1|0.0|
It's interesting that prx is so much more tightly clustered than frq.
New results for decoding vInt vs pfor, for frq file:
{code}
327864576 ints; 431137397 bytes compressed vs orig size 447077047
decompress using pfor:
2514 msec to decode 327864576 ints (130415 ints/msec)
2171 msec to decode 327864576 ints (151020 ints/msec)
2137 msec to decode 327864576 ints (153422 ints/msec)
2148 msec to decode 327864576 ints (152637 ints/msec)
2067 msec to decode 327864576 ints (158618 ints/msec)
decompress using readVInt:
4549 msec to read 327864691 ints (72074 ints/msec)
4421 msec to read 327864691 ints (74160 ints/msec)
3240 msec to read 327864691 ints (101192 ints/msec)
3199 msec to read 327864691 ints (102489 ints/msec)
3323 msec to read 327864691 ints (98665 ints/msec)
PFor is 54.766% faster
{code}
and prx file:
{code}
encode _l.prx to _l.prx.pfor...
442979072 ints; 628580878 bytes compressed vs orig size 651670377
decompress using pfor:
6385 msec to decode 442979072 ints (69378 ints/msec)
5904 msec to decode 442979072 ints (75030 ints/msec)
5796 msec to decode 442979072 ints (76428 ints/msec)
5807 msec to decode 442979072 ints (76283 ints/msec)
5803 msec to decode 442979072 ints (76336 ints/msec)
decompress using readVInt:
6893 msec to read 442979104 ints (64265 ints/msec)
6759 msec to read 442979104 ints (65539 ints/msec)
5304 msec to read 442979104 ints (83517 ints/msec)
5275 msec to read 442979104 ints (83977 ints/msec)
5792 msec to read 442979104 ints (76481 ints/msec)
PFor is 8.989% slower
{code}
Some comments:
* In both cases, the pfor file a bit smaller than the original
Lucene file. And, it's unfair because I inject the 4 extra bytes
per block (which I think won't be needed "for real").
* For frq file, pfor is quite a bit faster (54.8%) but for prx file
it's slower (9.0%). Maybe it's because prx file has much higher
occurrence of bigger bit sizes (where we don't have unrolled
version)? It's odd; maybe I'm doing something wrong. With a
fixed 6 bits it is quite a bit faster (I retested to verify!)
which is also weird because there would be many exceptions.
Exception processing ought to be slower than non-exception
processing!
Stepping back a bit: I wonder what %tg of the time in a "typical"
Lucene search is spent decoding vInts? That would bound how much
improvement we could ever expect from this optimization during
searching.
> PFOR implementation
> ---
>
> Key: LUCENE-1410
> URL: https://issues.apache.org/jira/browse/LUCENE-1410
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Other
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: LUCENE-1410b.patch, TestPFor2.java, TestPFor2.java
>
> Original Estimate: 21840h
> Remaining Estimate: 21840h
>
> Implementation of Patched Frame of Reference.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1410) PFOR implementation
[
https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1410:
---
Attachment: TestPFor2.java
Paul, I'm eager to test pfor on real Lucene vInts.
So I created a simple test program (attached TestPFor2.java). Run it
like this:
{code}
Usage: java org.apache.lucene.util.pfor.TestPFor2
Eg: java org.apache.lucene.util.pfor.TestPFor2 /lucene/index _l.prx
_l.prx.pfor
{code}
where indexDirName is the directory of a Lucene index, vIntFileNameIn
should be a file that just has a bunch of vInts (Lucene's *.frq and
*.prx fit this) and pForFileNameOut is a file it writes with blocks
encoded in PFor.
It first encodes the vInts from vIntFileNameIn into pfor blocks
written to pForFileNameOut. Then it measures decode time of reading
all vInts from vIntFileNameIn vs decode time of reading all pfor
blocks. It runs each round 5 times.
The test has certain serious flaws:
* Can you add a method that figures out the right frame size to use
for a given block of ints (so that ~90% of the ints are < N bits)?
* I'm using fixed 6-bit frame size. Can you add bigger bit sizes to
your pfor decompress?
With these fixes the test would be more fair to pfor.
In the PFor file that I write, I simply write an int (# bytes)
followed by the bytes, for each block. Then when reading these blocks
I read the #bytes, then read into the byte array backing the intArray
passed to the PFor for decompress. In a real integration I think
writing the int #bytes should be unecessary (is pfor self
puncuating?).
This is inefficient because in doing this for real we should avoid the
double-copy of the byte[]. In fact, we might push it even lower
(under IndexInput, eg, create a IntBlockIndexInput) to possibly avoid
the copy into byte[] in BufferedIndexInput by maybe using direct
ByteBuffers from the OS. So even once we fix the top two issues
above, the results of a "real" integration should be still faster.
I ran this on a 622 MB prx file from a Wikipedia index, and even with
the above 2 limitations it's still a good amount faster:
{code}
java org.apache.lucene.util.pfor.TestPFor2 /lucene/big _l.prx _l.prx.pfor
encode _l.prx to _l.prx.pfor...
442979072 vints; 888027375 bytes compressed vs orig size 651670377
decompress using pfor:
4198 msec to decode 442979072 vInts (105521 vInts/msec)
4332 msec to decode 442979072 vInts (102257 vInts/msec)
4165 msec to decode 442979072 vInts (106357 vInts/msec)
4122 msec to decode 442979072 vInts (107467 vInts/msec)
4061 msec to decode 442979072 vInts (109081 vInts/msec)
decompress using readVInt:
7315 msec to read 442979104 vInts (60557 vInts/msec)
7390 msec to read 442979104 vInts (59943 vInts/msec)
5816 msec to read 442979104 vInts (76165 vInts/msec)
5937 msec to read 442979104 vInts (74613 vInts/msec)
5970 msec to read 442979104 vInts (74200 vInts/msec)
{code}
It's really weird how the time gets suddenly faster during readVInt.
It's very repeatable. on another machine I see it get suddenly slower
starting at the same (3rd) round. Adding -server and -Xbatch doesn't
change this behavior. This is with (build 1.6.0_10-rc-b28) on Linux
and (build 1.6.0_05-b13-120) on Mac OS X 10.5.5.
> PFOR implementation
> ---
>
> Key: LUCENE-1410
> URL: https://issues.apache.org/jira/browse/LUCENE-1410
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Other
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: LUCENE-1410b.patch, TestPFor2.java
>
> Original Estimate: 21840h
> Remaining Estimate: 21840h
>
> Implementation of Patched Frame of Reference.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1410) PFOR implementation
[ https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Elschot updated LUCENE-1410: - Attachment: LUCENE-1410b.patch A corrected b.patch including TestPFor.java > PFOR implementation > --- > > Key: LUCENE-1410 > URL: https://issues.apache.org/jira/browse/LUCENE-1410 > Project: Lucene - Java > Issue Type: New Feature > Components: Other >Reporter: Paul Elschot >Priority: Minor > Attachments: LUCENE-1410b.patch > > Original Estimate: 21840h > Remaining Estimate: 21840h > > Implementation of Patched Frame of Reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1410) PFOR implementation
[ https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Elschot updated LUCENE-1410: - Attachment: (was: LUCENE-1410.patch) > PFOR implementation > --- > > Key: LUCENE-1410 > URL: https://issues.apache.org/jira/browse/LUCENE-1410 > Project: Lucene - Java > Issue Type: New Feature > Components: Other >Reporter: Paul Elschot >Priority: Minor > Original Estimate: 21840h > Remaining Estimate: 21840h > > Implementation of Patched Frame of Reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (LUCENE-1410) PFOR implementation
HiPaul, I am trying to see the intended usage for the this package. But I am unable to run the test as this what I get /Users/abhasin/source-repo/lucene-src/lucene-2.3.2/src/test/org/apache/lucene/util/pfor/TestPFor.java:1: 'class' or 'interface' expected [javac] link /home/ype/svnwork/lequel/trunk/src/test/org/apache/lucene/util/pfor/TestPFor.java [javac] ^ [javac] 1 error The contents of TestPFor are link /home/ype/svnwork/lequel/trunk/src/test/org/apache/lucene/util/pfor/TestPFor.java Any pointers ? Anmol On Wed, Oct 1, 2008 at 12:57 PM, Paul Elschot (JIRA) <[EMAIL PROTECTED]> wrote: > > [ > https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Paul Elschot updated LUCENE-1410: > - > >Remaining Estimate: 21840h (was: 0.5h) > Original Estimate: 21840h (was: 0.5h) > >> PFOR implementation >> --- >> >> Key: LUCENE-1410 >> URL: https://issues.apache.org/jira/browse/LUCENE-1410 >> Project: Lucene - Java >> Issue Type: New Feature >> Components: Other >>Reporter: Paul Elschot >>Priority: Minor >> Attachments: LUCENE-1410.patch >> >> Original Estimate: 21840h >> Remaining Estimate: 21840h >> >> Implementation of Patched Frame of Reference. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Courage doesn't always roar. Sometimes courage is the quiet voice at the end of the day saying, "I will try again tomorrow" Anmol Bhasin SSE Data Platform www.linkedin.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1410) PFOR implementation
[ https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Elschot updated LUCENE-1410: - Remaining Estimate: 21840h (was: 0.5h) Original Estimate: 21840h (was: 0.5h) > PFOR implementation > --- > > Key: LUCENE-1410 > URL: https://issues.apache.org/jira/browse/LUCENE-1410 > Project: Lucene - Java > Issue Type: New Feature > Components: Other >Reporter: Paul Elschot >Priority: Minor > Attachments: LUCENE-1410.patch > > Original Estimate: 21840h > Remaining Estimate: 21840h > > Implementation of Patched Frame of Reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1410) PFOR implementation
[ https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Elschot updated LUCENE-1410: - Summary: PFOR implementation (was: PFOR implemenation) > PFOR implementation > --- > > Key: LUCENE-1410 > URL: https://issues.apache.org/jira/browse/LUCENE-1410 > Project: Lucene - Java > Issue Type: New Feature > Components: Other >Reporter: Paul Elschot >Priority: Minor > Attachments: LUCENE-1410.patch > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Implementation of Patched Frame of Reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
