[sword-devel] C++ volunteer

Troy A. Griffitts scribe at crosswire.org
Mon May 27 16:38:31 MST 2019


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 at 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 at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page



More information about the sword-devel mailing list