[sword-devel] C++ volunteer
Cyrille
lafricain79 at gmail.com
Mon May 27 23:54:15 MST 2019
Hello Richard,
Welcome!
May I make a very selfish proposal to Richard who offers his help. There
are two issues that I really want to be resolved. One of which
particularly handicaps Catholic users, (but I discovered today that the
issue wasn't been reported!!! I just did it):
https://tracker.crosswire.org/browse/API-216
And the second: https://tracker.crosswire.org/projects/API/issues/API-180
If there are more important things that I am not able to estimate not
being a developer, I would have tried my luck ;)
Il 28/05/2019 01:38, Troy A. Griffitts ha scritto:
> 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
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20190528/0970523b/attachment-0001.html>
More information about the sword-devel
mailing list