Once you are convinced that your setup is reasonable you should
generate a wired
BitStreamIndexReader
/BitStreamHPIndexReader
.
The latter are the generic classes used by MG4J to read an index: thus,
they incorporates all the logic required to handle literally hundreds of
types of indices. However, you can use the Ruby script
genbitstreamreaders.rb
provided with MG4J to generate
additional instances that are wired to a specific index type. When loading
an index, MG4J will fetch dynamically (by reflection) the wired class and
will log (at INFO
level) that it is using a wired class
instead of the generic class. (The standard MG4J distribution contains
wired classes for the default index-construction options.)
The Ruby script above prints a list of commands involving a C
compiler (by default, gcc). Actually, the commands use
the C preprocessor to filter a driver file contained in the source tree
(BitStream[HP]IndexReader.c
). Executing the output of
the Ruby script will generate all possible wired classes (hundreds), but
you can also select manually the classes you prefer to generate.
The simplest way to understand the wiring process is having a look
at the output of the Ruby script: essentially, defining the symbol
GENERIC
you obtain the generic driver. Otherwise, you
can define symbols SKIPS
and
PAYLOADS
if you want these features, and then you must
specify assertions with name frequencies
,
pointers
, counts
, and
positions
that either select a code or disable a
feature (as in Combine
's command line options). The
symbol CLASSNAME
defines the wired class name, and
must be generated following the algorithm contained
in the Ruby script, or MG4J will mistakenly load wired classes that are
not adapt for your index.