[sword-devel] Changing #include structure (was: I implore you...)

DM Smith dmsmith at crosswire.org
Thu Jun 13 07:46:23 MST 2013 

I've got no skin in the game, but I'm not short on opinions. ;)

Jaak, the change you've requested is a good, right and proper one. But it really needs to wait until after the release.

In Him,
	DM

On Jun 13, 2013, at 4:47 AM, Jaak Ristioja <jaak at ristioja.ee> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Troy,
> 
> Imho there are already header files which clash, namely the zlib ones:
> 
> $ `echo -n 'ls -ld '; find include/ -name '*.h' | sed -e
> 's_^include/_/usr/include/_'` 2>/dev/null
> - -rw-r--r-- 1 root root 15292 sept  24  2012 /usr/include/zconf.h
> - -rw-r--r-- 1 root root 87011 sept  24  2012 /usr/include/zlib.h
> 
> Jaak
> 
> 
> On 13.06.2013 11:32, Troy A. Griffitts wrote:
>> Jaak,
>> 
>> On 06/13/2013 10:12 AM, Jaak Ristioja wrote: Troy,
>> 
>> It still seems that you missed one thing. Namely, the #includes
>> with <> still include a prefix, i.e. sound/ and omniORB4/. The
>> Sword #includes do not, and this by itself is a big problem which
>> makes header filename clashes a lot more probable, especially if
>> other libraries would follow suit and have the same #include
>> convention as Sword does.
>>> Jaak,  I didn't miss this.
>> 
>>> As I said in my last email, I'm not saying your wrong.  I'm just
>>> saying:
>> 
>>> a) the headers I looked at include things DIFFERENTLY than your
>>> patch, so I'm not sure your fix is the most standard. b) things
>>> work right now on a ton of platforms and compilers and build 
>>> projects, and I don't want to change this just before a release,
>>> which could potential break all of these-- especially if there
>>> are no known problems with this right now.  There is no reason to
>>> push a potentially disruptive patch just before a release.
>> 
>>> Also, if you use pkg-config to get the compile and link
>>> directives, you shouldn't need to care about what to pass to the
>>> compiler.
>> 
>>> .cpp: g++ `pkg-config --cflags sword` $< -o $@ `pkg-config --libs
>>> sword`
>> 
>> 
>>> Thanks for being concerned.  I understand your concern and value
>>> your input, Troy
>> 
>> 
>> 
>> Regarding <> and "", the latter provides a better safeguard
>> against including the wrong headers in some situations, especially
>> when dealing with multiple versions of the headers being installed
>> at the same time. More commonly, using "" instead of <> can also
>> help to simplify the build system for libraries such as Sword.
>> 
>> I don't consider using <> instead of "" a bug. But what I think is 
>> very inconvenient is that one has to explicitly use 
>> -I/usr/include/sword/ instead of just using #include
>> <sword/stuff.h> in the source files.
>> 
>> This is cause for confusion for developers, who might think (as I
>> did and do): 1) Do I need to #include <stuff.h> // Sword header ? 
>> 2) If I #include <sword/stuff.h> then why do I need to pass an
>> extra -I argument to the compiler?
>> 
>> What I'm asking is that even if you don't want "" instead of <>, 
>> please use a sword/ prefix for all respective #includes in all
>> header files of Sword.
>> 
>> Blessings, Jaak
>> 
>> 
>> On 13.06.2013 09:47, Troy A. Griffitts wrote:
>>>>> Jaak,
>>>>> 
>>>>> I'm of the same mind as Greg.  Our include syntax has been
>>>>> working as is for 20 years on a number of compilers and
>>>>> platforms.  I hesitate to wholesale change this now because
>>>>> of 'in principle' arguments without any actual problems being
>>>>> seen.  I don't have time to compile your changes on all the
>>>>> platforms we support to test them.  I know what we have now
>>>>> works.
>>>>> 
>>>>> I'm not saying that you're not right, but I also don't see
>>>>> your changes as standard.  Just a brief look on my box, 
>>>>> /usr/include/sound/sfnt_info.h includes 
>>>>> /usr/include/sound/asound.h with: #include <sound/asound.h>
>>>>> 
>>>>> /usr/include/omniORB4/anyStream.h includes 
>>>>> /usr/include/omniORB4/omniTypedefs.hh with: #include 
>>>>> <omniORB4/omniTypedefs.hh>
>>>>> 
>>>>> Just the first 2 I looked at.
>>>>> 
>>>>> I'd like more time to investigate this before making a
>>>>> change,
>>>>> 
>>>>> Troy
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 06/12/2013 10:28 PM, Jaak Ristioja wrote:
>>>>>> Well, using -I/usr/include/sword is just an ugly
>>>>>> workaround. It doesn't change the fact that Sword headers
>>>>>> include each other in a wrong manner (using <> instead of
>>>>>> ""). Because it would only be a workaround, we do not want
>>>>>> to stick to it forever. We want this fixed.
>>>>>> 
>>>>>> Secondly, headers in the Sword include directory have a
>>>>>> greater chance of colluding with other headers in
>>>>>> /usr/include/ and elsewhere. Hence the Sword headers
>>>>>> themselves might include wrong header files if that
>>>>>> happens. That's why using "" instead of <> is important so
>>>>>> that relative paths would be searched before any locations
>>>>>> specified by -I arguments to the compiler.
>>>>>> 
>>>>>> I don't believe my patch broke anything, the main changes
>>>>>> were substituting <> with "" when #including Sword headers.
>>>>>> However, if it did break anything, it should be easy to
>>>>>> amend. I'm highly motivated to get my patches applied to
>>>>>> the next version of Sword one way or the other. So just ask
>>>>>> and I'll fix it.
>>>>>> 
>>>>>> Blessings, Jaak
>>>>>> 
>>>>>> 
>>>>>> On 12.06.2013 23:05, Greg Hellings wrote:
>>>>>>> 
>>>>>>> On Wed, Jun 12, 2013 at 2:51 PM, Jaak Ristioja 
>>>>>>> <jaak at ristioja.ee <mailto:jaak at ristioja.ee>> wrote:
>>>>>>> 
>>>>>>> Hi!
>>>>>>> 
>>>>>>> What's the integration status on this patch?
>>>>>>> 
>>>>>>> Blessings, Jaak
>>>>>>> 
>>>>>>> 
>>>>>>>> Can we allow changes which are not bare-minimum 
>>>>>>>> build-breakers, such as restructuring the includes, be
>>>>>>>> a later issue for the next next release and just get
>>>>>>>> 1.7.0 out the door, please? Also, what prevents you
>>>>>>>> from having -I/usr/include -I/usr/include/sowrd and
>>>>>>>> then having #include <sword/foo.h> and having it all
>>>>>>>> work just as planned? --Greg
>>>>>>> 
>>>>>>> PS: Is Troy the only one with access to apply this?
>>>>>>> 
>>>>>>> On 10.06.2013 22:49, Jaak Ristioja wrote:
>>>>>>>> Argh, someone must have changed things on SVN lately,
>>>>>>>> so this patch was invalid for the current trunk... I
>>>>>>>> wish you guys would learn git or something. Anyway,
>>>>>>>> here's something which should apply to SVN 2819, I
>>>>>>>> hope. SHA1SUM: 071a4fb64f1d0c2ed5d746d08791592f76eaf633
>>>>>>>> Blessings, Jaak On 10.06.2013 22:34, Jaak Ristioja
>>>>>>>> wrote:
>>>>>>>>> Attached is a patch for this. Please apply. SHA1SUM: 
>>>>>>>>> 9a99e34ce419ea3288a32148d431ec971fb0e675 Blessings,
>>>>>>>>> Jaak On 10.06.2013 19:38, Jaak Ristioja wrote:
>>>>>>>>>> I'm working on the patch but here's a short
>>>>>>>>>> overview of the problem, in case discussion is
>>>>>>>>>> required. The problem is that source code using
>>>>>>>>>> Sword can't do stuff like: #include
>>>>>>>>>> <sword/versekey.h> This is VERY BAD, because we 
>>>>>>>>>> must do #include <versekey.h> and provide 
>>>>>>>>>> -I/path/to/sword/includes/ to the compiler every
>>>>>>>>>> time. The problem with this approach is that
>>>>>>>>>> versekey.h might also exist in /usr/include or in
>>>>>>>>>> other -I/include/paths. Additionally, this makes
>>>>>>>>>> the #include list rather incomprehensible,
>>>>>>>>>> especially when we want to sort it alphabetically.
>>>>>>>>>> There's no telling what <versekey.h> refers to - is
>>>>>>>>>> it part of Sword, part of something else, or a typo
>>>>>>>>>> (e.g. maybe this needs to be "versekey.h"). Why
>>>>>>>>>> #includes like <sword/versekey.h> don't work is
>>>>>>>>>> that the Sword headers themselves use includes
>>>>>>>>>> like <versekey.h> instead of "versekey.h" which is
>>>>>>>>>> correct. If I don't include -I/usr/include/sword in
>>>>>>>>>> my compiler arguments, but #include
>>>>>>>>>> <sword/versekey.h>, the versekey.h file tries to
>>>>>>>>>> #include <swkey.h> which fails because it can't
>>>>>>>>>> find the file in in the include path. The *.cpp
>>>>>>>>>> files in Sword also need to use "" instead of <> to
>>>>>>>>>> distinguish between header system and local header 
>>>>>>>>>> files. Afaik this is just best practice. Existing
>>>>>>>>>> code using #include <versekey.h> etc will continue
>>>>>>>>>> to work as long as the -I/path/to/sword/includes
>>>>>>>>>> exists. Blessings, Jaak On 10.06.2013 19:21, Jaak
>>>>>>>>>> Ristioja wrote:
>>>>>>>>>>> Actually I just remembered another serious flaw
>>>>>>>>>>> which causes a headache for developers using
>>>>>>>>>>> Sword. I'll write a patch ASAP. Blessings, Jaak
>>>>>>>>>>> On 10.06.2013 09:43, Troy A. Griffitts wrote:
>>>>>>>>>>>> Jaak,
>>>>>>>>>>>> 
>>>>>>>>>>>> I accepted and applied your header file patch
>>>>>>>>>>>> nearly 5 months ago.  Are you telling me that
>>>>>>>>>>>> you still have 549 warnings from SWORD
>>>>>>>>>>>> headers?
>>>>>>>>>>>> 
>>>>>>>>>>>> Troy
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On 06/09/2013 11:55 PM, Jaak Ristioja wrote:
>>>>>>>>>>>> On 09.06.2013 23:21, Troy A. Griffitts wrote:
>>>>>>>>>>>>>>> I don't think other developers are
>>>>>>>>>>>>>>> getting ignored. Please be specific.
>>>>>>>>>>>>>>> Just because I don't accept a patch
>>>>>>>>>>>>>>> doesn't mean a developer is getting
>>>>>>>>>>>>>>> ignored.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> In fact, many times trying to make this 
>>>>>>>>>>>>>>> release, when people complain that we
>>>>>>>>>>>>>>> need something fixed for this release, I
>>>>>>>>>>>>>>> ask for a simple testsuite addition to
>>>>>>>>>>>>>>> show the problem and desired result, and
>>>>>>>>>>>>>>> don't get a response.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I don't believe the problem is as you
>>>>>>>>>>>>>>> think it is Jaak. Many people whine about
>>>>>>>>>>>>>>> this or that. Not all whine for things to
>>>>>>>>>>>>>>> go in the same direction.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Everyone whines for a release but not
>>>>>>>>>>>>>>> everyone is willing to help submit tests
>>>>>>>>>>>>>>> and then fixes for those tests.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> You stated that you would get involved
>>>>>>>>>>>>>>> to help, but you only submit things for
>>>>>>>>>>>>>>> which I previously told you I wasn't
>>>>>>>>>>>>>>> interested in accepting (worrying about
>>>>>>>>>>>>>>> pedantic warnings whose changes often
>>>>>>>>>>>>>>> make the code less readable and do
>>>>>>>>>>>>>>> nothing to improve any of the real
>>>>>>>>>>>>>>> problems for the end user.  Though I do 
>>>>>>>>>>>>>>> appreciate a few of the warning fixes
>>>>>>>>>>>>>>> you submitted, a few being actual bug
>>>>>>>>>>>>>>> fixed too (thank you)-- I'm just ranting
>>>>>>>>>>>>>>> right now.)
>>>>>>>>>>>> As a BibleTime developer, I want to available
>>>>>>>>>>>> tools (-Wall, -Wextra, cppcheck, etc) to fix
>>>>>>>>>>>> any errors in my code. Due to the Sword header
>>>>>>>>>>>> files which generate a lot of warnings this
>>>>>>>>>>>> task is VERY inconvenient. For example, when I
>>>>>>>>>>>> compile the whole of BibleTime with GCC, I get
>>>>>>>>>>>> 549 warnings from Sword headers (mostly for
>>>>>>>>>>>> unused arguments) - how am I supposed to find
>>>>>>>>>>>> the warnings relevant for BibleTime? This alone
>>>>>>>>>>>> often makes it a pain to develop BibleTime and
>>>>>>>>>>>> gives me enough reason to want to fork Sword.
>>>>>>>>>>>> 
>>>>>>>>>>>> Turning on and fixing pedantic warnings will
>>>>>>>>>>>> help find real bugs. FACT! Forcing developers
>>>>>>>>>>>> to work blindfolded will not help anyone.
>>>>>>>>>>>> 
>>>>>>>>>>>> The same tools can be used to find bugs in
>>>>>>>>>>>> Sword code, and SHOULD regularly be used for
>>>>>>>>>>>> this purpose to ensure code quality. As is
>>>>>>>>>>>> obvious these are currently NOT BEING USED by
>>>>>>>>>>>> Sword developers. However, when things
>>>>>>>>>>>> eventually break, users complain to the
>>>>>>>>>>>> BibleTime project. Hence, it is also in the
>>>>>>>>>>>> interests of front-ends to ensure that the code
>>>>>>>>>>>> of Sword is of good quality. Again - if Sword 
>>>>>>>>>>>> won't work to ensure this and wont let us in to
>>>>>>>>>>>> fix things, we have another reason to fork.
>>>>>>>>>>>> 
>>>>>>>>>>>> This again leads us to the issue of attracting
>>>>>>>>>>>> new developers to Sword. I don't want to write
>>>>>>>>>>>> on this more than necessary to provide a small
>>>>>>>>>>>> argument for my conclusion. Afaik the current
>>>>>>>>>>>> situation isn't working well. Biggest obstacles
>>>>>>>>>>>> for me personally include working blindfolded,
>>>>>>>>>>>> submitting patches by e-mail and not getting
>>>>>>>>>>>> enough feedback for (ignored) patches and other
>>>>>>>>>>>> emails.
>>>>>>>>>>>> 
>>>>>>>>>>>> To conclude - maybe its just me, but altogether
>>>>>>>>>>>> I really feel it were easier to maintain a
>>>>>>>>>>>> parallel fork (at minimal to provide set of
>>>>>>>>>>>> patches) than to waste my time writing long
>>>>>>>>>>>> letters trying to make this relationship work
>>>>>>>>>>>> in its current form. I accept whatever path the
>>>>>>>>>>>> Sword project takes, but if it's not enough for
>>>>>>>>>>>> the needs of BibleTime and our devs, we will
>>>>>>>>>>>> make our own choices as well.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Blessings, Jaak The BibleTime team
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> PS: I apologize if this late-night response is 
>>>>>>>>>>>> incomprehensible.
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
> sword-devel mailing list:
>>>>>>>>>>>>> sword-devel at crosswire.org
>>>>>>> <mailto: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
>>>>>>> <mailto: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
>>>>>>> <mailto: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
>>>>>>> <mailto: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
>>>>>>> <mailto: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 
>>>>>>>> <mailto: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 
>>>>>>> <mailto: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
>>>>> 
>>>>> 
>>>>> _______________________________________________ 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
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.20 (GNU/Linux)
> 
> iQgcBAEBAgAGBQJRuYcrAAoJEEqsYmEt1rCO2dBAAJmo5vimBUbV9Oj8eA6QOvR3
> kj79xjqsWouPTuoV5fv5oYqO8KH3S03IzTIR5NjjYQ0gBJSstIE2bfvAwlUnTzkq
> 5+6/ZQiqLyK1mpMn/Hs1ykze5eV6bKz+bM+9gY2PvI/ftTiPf5inob9iLdU+pv0Z
> mh6SGgkv21F3o0S/rWIxGEQM4em59IEbjYqxwniHnq8Icmr3ln2xbu3AObZziAVS
> qLg/PHQaYrL1P6E7YetynO4gWqFAqFb5vK/7Jd55qsYLP2XdAP2nUUD5ftMBkils
> WFbFZgj3G+6zfQdCo385WROzc6++AUGqXHsFvg0FvpHn5bDQ+66JiifSaykibU9G
> cZerJ9yFWB6CyX+E1L7FTsZKkf4RHzwmv86OCXiJAJhECfHAnyKFK4Dp+2Z3oVNw
> ME6e4DTmJuPQOEUI4BF2o5rd2HzxxzRZzonzkrpfXkH0DbRJNuZqL6xQVX3Eefen
> hCENogvrBT9ZKG1Uq24denYJMSXLaS3JI2il4SruTMGML/ODvUnQ5uTPkoxUICJt
> /e/El7vIPwIxLbNOTDiSg+d80c7Uo7Ro3tWOGkN0Qw640arLf11RFu1qeALJRHqK
> Wsew6bZzpRZ1U07XXLLAakkIdCfxMW7xfaV4vouSOn5oxROK2I4joFdat1N/ykAD
> /7y4uGk8Zbz2/X4gfl84rDvfDo73TVxTrHcVREmwIc2JKP7YUR5k1FOBbEt7y3jd
> 9p17l/D8SzIkFdKF+/0hsz0o4rSJIQqD5AByPihDtQ3ECIwxtcC9q/xD8RbzL4cg
> B2QDJ5xUI1v2nWmQNzXn2RH5zYKARQWlmLJEwiyQA1DPk+U8TewRY/4dBU7C2JAA
> E5KhC4lbB8sbBWj3o/qqs4MWXDfBgHI3jHjH5+0UVQj/ucSI/8uSVasy/LU16g4Y
> PUbqDC9fNh/JtINj0Yi3IRnpg8et6Jdiy1kuzcPhVUne9er3Yd9VqywNS/uB1sMF
> mNU3T+nXdkR8MnK7XQ0eCN3UPVj2Nk7+m+9PqY05agVWQSUxuwYt9gApiLZYIfJg
> sTPKtx+uGQqJ4abRrGN9DGdM6bEG7rT1xG0CduJDwWrPHXv/AvXeGiZh4Qhs4jG4
> 6na7BY+yR1UpCHj9N8Qj3IS69BVmB63TMfEts135i4tChX0HIHi4fdNuhKcoK5pe
> 7hfEgD6D5rQKtbb5x1w9RlDUddeh/4ksuxo2/QFGPliKr5VhEsthUF3HS+IF4jRE
> bdHZQyBjSbNITKMwTCyQt/pVeypBf7ZiNB7z6TbflDA1riwgQOuHCrkOi+t2BiK6
> WQvm2GkEYn0ePQQVSlt87srYZw1NCLjoNkU2pVDfMGdtmSsUAXgP5UqgCDbO+gFP
> 61zwWYr4GJ3CiYThgtZifybTN3efL4eQyNNLgziPrgKqE85D4KEI5F5C9cU32c+k
> vLrjBQgx2ss6ICsaCoDrFpoqfqQFhTYK8FYRJileigWR7sBislhnP/MM/4QGUiOu
> A1GaaJNuu1aHrqB5+ff3LtdOg37BaZmB6tdjOxV3nrRADL+rEm3FBiU+9sbTartd
> qckR/xTHYq9nBJ+BgYCgeq7O6U40AItLFE9WTWIFsGAU6Ve4FrDwYQa67syYtEkN
> byQpgD9/hg5fKeMbYZcmEmNPcdb99cLc43qUVv3UcavzbJhV+iuefLTSUpoUqOOa
> N02MmnT0y0iEPYxFeWTnXu4gmgv0FH9SuPPa8riwXaBnPEkSrhOaztApJAIj+d2M
> ZAXalwIHK3wd6k2S9dTysCKIqfv4THAbZoVPkG49f0ThN5E5hzsgfVsZX8wbqbPk
> qp/nl3/BYMeuddHtqzJYapJ4FJvB0g119MhnBz0bnXLWOlXJpborni39CjwSEZqz
> cfFep3DHISyo2uQ1GqSn1qKAU9h3mMBAtfNQofQsZ3rKoXVtllhPG85bHBS7MupD
> MxrxQtKIQLxS0xF2eeUg86bjzX7aP/ojoNuliGsV2AXO2DAbu/EVHPMJofI6mY7R
> qdpg6hGTldIPI3smkFJKEL57f9O1rVsegmGIJoTloDX/qOXQg6D74C3tG6hST64v
> B5dNGLF/h+PQAcC7TTiBPkIOPVzjXiqyup2zsqkIwCkWKYOHXTbUXr5yDVdKFEiB
> cTsTa5DUlRbMJPfb9LCdcnHzkUCmukYBDtZA1omBIFP2B5kaZ9oosjVuYqMiJqfw
> xbVW2JZCOcUkGG31wE5xYEFJkCCfDH+KJ3O2TEsS+af2I9D8mDYZY1sEzOuEJZ88
> EW1N1VuxMyXzlhvahjnEr2mjsdYGVdC8bI4tBGjLBcrZ1AEKJItcpYhvugOJkTo4
> hXHcWyz5IfOGfw8Yv4cFRKwUCcUztv5wmu8ZI0dXeaIGFphwelF/dwCiPcyN9FwF
> fRudqSds6crUmMt3zgHHTzL35HYzh5UOZocGzCkW0Q1O+z6CaY80xUQOrJIvkU9l
> 8IUL7ePRsNDz3ZPMJaYvnVFHdmi5Y29Y9+GfyNsoSoyfhtbWoIqGWTt4OYazUBGu
> 1YQ3lum2Fix6ZjLI3THXUJhzfUt2rL76n+ulk8G3W88iDXHHvYoN7yWSx28bWBBp
> pJmiiBWKa5p1ESADG3LXQ2sdDKpCrDpUaSbf2rf/gJGvomgcfKVxd8cJ4PfJYIsZ
> j6YFDUOqnGf1/YnQo7GZ55AgLok2DQRTBkIFJbZiElkG7rwHEa6awUaftoT0m171
> /Si9mQmShWYoKvkbUWsP
> =jSzY
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> 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