Richard, sorry, I meant to give you the link to our tracker: https://tracker.crosswire.org
On 5/27/19 4:32 PM, Troy A. Griffitts wrote: > 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 _______________________________________________ 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
