Welcome, Richard! I would start at 2 places:
First, have a look at our tracker here. We are not very (very not) disciplined at keeping it current. Skimming through there and commenting on anything that looks interesting, or even cleaning a few things up in there that you confirm are no longer a problem might be a useful exercise to get you poking around at internals and would be a blessing for us. Our modus operandi as of late is to create a new unit test in sword/tests/testssuite/ which fails at the bug and then once fixed, the test should pass and we leave the test around to be sure we don't regress. We can always use more tests in our tests suite. Next, we have the intention to modularize our search engines support and search types. Right now, SWModule (which represents a Bible) implements our SWSearchable interface, which is fine, but right now it has a bunch of #ifdef logic and switch statements to take different code paths depending on which search engine is compiled into SWORD and which search type is specified. This was fine initially, but has grown to such that we now support spaghetti in there. It should probably simply have a set of SWSearchable objects in a map<SEARCH_TYPE, SWSearchable> and proxy the search request to the appropriate SWSearchable impl based on what types are registered for the module. This would allow us to implement new types and register them with modules which support special search types, e.g., advanced Hebrew Morphology searching. That's the general idea anyway. You should probably become familiar with SWFilter and how we use these throughout the engine. These prepare a buffer for particular objectives. We have RenderFilters, EncodingFilters, StripFilters, ... The last prepares an SWModule entry for searching by, typically, stripping out all markup and leaving only a plaintext buffer which can be searched. We have some special code in the SWModule::search spaghetti which takes Greek and Hebrew modules and turns buffers into a series of Strongs#@MorphCode Strong#@MorphCode ... which allows regex searches to do some advanced morph searching... like: Find this strongs number, any morphology, followed by a any verb withing 2 words. You have to be pretty familiar with the Strong#@MorphCode syntax to formulate something like that, but the idea is that a frontend could have a nice UI to help a user come up with some creative searches. Anyway, these should all be probably modulized out by renaming the StripFilter concept to SearchFilter, and then pushing all this special code out to SearchFilter impls which do these special things... Finally, an objective of all this search modularization is also to break out the code required to create search indexes for each of the search engines we support. Ideally, we should be able to support the same searches either as an indexed or brute force search. The same code which iterates a module, prepares each entry, and pushes that entry to the search engine, building the search index, should also work for a brute force search-- iterating the module, preparing each entry for the search engine.. and then performing a check on that buffer to see if it matches the search expression. I hope this gives you a few things to think about. It has been good for me to refresh thoughts on all of this. Have a look and let me know what you think. Welcome! Looking forward to sharing in service together, Troy On 5/27/19 1:09 PM, Richard Smith wrote: > Hi, > > My name's Richard Smith. I'm a C++ software engineer with 10 years > experience in various industries. I was wondering if there was any > space for a volunteer. I've started taking a look at things (building > repos on Win/unix), but if there are specific things that are > required, within my ability, I'm happy to do that. > > Best Regards > Richard Smith > > _______________________________________________ > sword-devel mailing list: sword-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
