93 lines
3.1 KiB
Plaintext
93 lines
3.1 KiB
Plaintext
|
|
CVS
|
|
---
|
|
|
|
CLucene's source repository is in SVN
|
|
|
|
For information on CVS, see:
|
|
http://sourceforge.net/svn/?group_id=80013
|
|
|
|
|
|
Coding Style
|
|
------------
|
|
|
|
CLucene follows a hybrid coding style. Because of the nature of the code being
|
|
a java port, there are naturally some java like syntax.
|
|
|
|
todo: put the coding standard here
|
|
|
|
* Never use CL_NS_USE(x) in a header file (use CL_NS(x):: for each class), it defeats the purpose of namespaces.
|
|
* Use CL_NS_USE(x) in .cpp files if there are more than a few usages of that namespace.
|
|
|
|
Good development tips
|
|
---------------------
|
|
When developing, use the available clucene debugging tools:
|
|
* _CND_DEBUG - condition debugging, an 'assert' type system (or configure with --enable-cnddebug)
|
|
* LUCENE_ENABLE_MEMLEAKTRACKING - to assist in memory leak tracking (or configure with --enable-debug),
|
|
enable this. This keeps track of clucene object creations
|
|
and deletions. Always use _CLNEW and _CLDELETE. At the end
|
|
of your program, call:
|
|
|
|
_lucene_run_objectcheck
|
|
|
|
lucene::debug::LuceneBase::__cl_PrintUnclosedObjects();
|
|
which prints all the open clucene objects. Then call
|
|
lucene::debug::LuceneBase::__cl_ClearMemory();
|
|
which clears all the clucene memory, so that you can
|
|
use other memory tracking tools to further help you
|
|
discover memory leaks
|
|
|
|
__cl_PrintUnclosedObjects returns a list of objects with
|
|
the number that it was created at. If your debugger allows
|
|
you to set watches you can add:
|
|
_lucene_counter_break
|
|
to the watch list and change the value to this number. Then
|
|
it will break into CLDebugBreak in the StdHeader.cpp file.
|
|
|
|
Another trick is to use set:
|
|
_lucene_run_objectcheck
|
|
to true. This will check the validity of memory before deleting it.
|
|
It can't always help, but may help in some situations.
|
|
|
|
Good performance tips:
|
|
CLucene has a lot of new changes to help improve performance.
|
|
Some of them are still being tuned...
|
|
LUCENE_ENABLE_MEMORY_POOL helps speed up allocations for small
|
|
objects. The types of classes who are pooled are done on a
|
|
class by class basis - thus it is still being tuned. More testing
|
|
is required to see which classes would benefit from pooling.
|
|
|
|
(currently this is broken, i think)
|
|
|
|
MSVC profiling tutorial:
|
|
http://webserver.tc.cornell.edu/services/edu/topics/Performance/Profiling/more.asp
|
|
|
|
For GCC see gprof
|
|
you can enable gprof by configuring with --enable-gprof
|
|
|
|
Developing
|
|
----------
|
|
When developing, please keep in mind cross-platform issues and also
|
|
character set issues (unicode/ascii).
|
|
|
|
Hint:
|
|
To do a quick test to see if the code compiles
|
|
run this command from the root directory of clucene.
|
|
It will compile all the CLucene code monolithically.
|
|
|
|
% cd src; make monolithic; cd ../test; make monolithic; ./cl_test_monolithic
|
|
|
|
This will do a quick compile then run all the clucene tests.
|
|
|
|
GDB - GNU debugging tool
|
|
------------------------
|
|
This is not clucene specific, but useful for novices none the less.
|
|
|
|
Because cl_test is a libtool bash script, you can use this command to
|
|
run gdb:
|
|
|
|
libtool --mode=execute gdb cl_test
|
|
|
|
Then type run to start the debug tool.
|
|
If a crash occurs, you can type bt to get a backtrace.
|