Merge lp://qastaging/~kamstrup/dee/tree-index into lp://qastaging/dee
Proposed by
Mikkel Kamstrup Erlandsen
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Michal Hruby | ||||
Approved revision: | 343 | ||||
Merged at revision: | 309 | ||||
Proposed branch: | lp://qastaging/~kamstrup/dee/tree-index | ||||
Merge into: | lp://qastaging/dee | ||||
Diff against target: |
4389 lines (+2926/-603) 32 files modified
bindings/python/Dee.py (+2/-2) dee/Makefile.am (+8/-2) dee/dee-analyzer.c (+504/-0) dee/dee-analyzer.h (+174/-0) dee/dee-glist-result-set.c (+4/-3) dee/dee-glist-result-set.h (+3/-3) dee/dee-hash-index.c (+30/-17) dee/dee-hash-index.h (+3/-2) dee/dee-index.c (+61/-19) dee/dee-index.h (+6/-47) dee/dee-model-reader.c (+157/-229) dee/dee-model-reader.h (+60/-11) dee/dee-term-list.c (+130/-27) dee/dee-term-list.h (+8/-4) dee/dee-text-analyzer.c (+192/-0) dee/dee-text-analyzer.h (+90/-0) dee/dee-tree-index.c (+713/-0) dee/dee-tree-index.h (+83/-0) dee/dee.h (+4/-1) doc/reference/dee-1.0/dee-1.0-docs.sgml (+4/-1) doc/reference/dee-1.0/dee-1.0.types (+3/-0) tests/Makefile.am (+18/-3) tests/test-analyzer.c (+137/-0) tests/test-dee.c (+4/-2) tests/test-glist-result-set.c (+3/-3) tests/test-index.c (+346/-112) tests/test-model-readers.c (+49/-83) tests/test-python.py (+31/-0) tests/test-term-list.c (+54/-0) vapi/Dee-0.5-custom.vala (+2/-12) vapi/Dee-0.5.metadata (+0/-1) vapi/dee-1.0.vapi (+43/-19) |
||||
To merge this branch: | bzr merge lp://qastaging/~kamstrup/dee/tree-index | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Michal Hruby (community) | Approve | ||
Review via email:
|
Description of the change
WARNING API+ABI break: Big overhaul of the whole text analysis, DeeAnalyzer, and DeeIndex framework.
Primary intent is to implement a DeeTreeIndex that can do O(logN) prefix searching.
To post a comment you must log in.
Wow, this is huge...
There are (closure) annotations missing for DeeModelReaderFunc, DeeCollatorFunc, and all the *_reader helpers.
dee_term_ list_clone_ real: is trying to be insanely quick, doing memcpy of the ptrarr->data fields could squeeze up some extra performance.
find_term_real: shouldn't it use g_sequence_lookup when doing MATCH_EXACT?
2573 +//fixme fixme - is there something to fix?