Re: [sword-devel] regex.h

[Greg Hellings]

Here's a patch that I was able to apply to the code base that allowed me to
cross-compile for Windows using the Autotools toolkit, and solved the
problem of the missing regex.h header in diatheke. I will also attach the
patch file to this email directly. I think the discrepancy happens because
glibc doesn't come along with most MinGW toolkits in the same way, and it's
lacking regex.h. It seems to be pretty standard to have that header in
Linux or Unix systems, so on those platforms the internal regex.h would not
commonly be used.

--- a/utilities/diatheke/Makefile.am
+++ b/utilities/diatheke/Makefile.am
@@ -1,5 +1,8 @@
AUTOMAKE_OPTIONS = 1.6

+if USE_INTERNAL_REGEX
+AM_CPPFLAGS = -I$(top_srcdir)/include/internal/regex
+endif
LDADD = $(top_builddir)/lib/libsword.la

bin_PROGRAMS = diatheke



On Thu, Oct 24, 2024 at 10:40 AM Greg Hellings 
wrote:

> I'm trying to build SWORD in an environment without a system regex.h. The
> library build itself goes great, but diatheke fails to find the internal
> regex.h file, ending with this error.
>
> sword-x86_64-w64-mingw32> corediatheke.cpp:29:10: fatal error: regex.h: No
> such file or directory
> sword-x86_64-w64-mingw32>29 | #include 
> sword-x86_64-w64-mingw32>   |  ^
> sword-x86_64-w64-mingw32> compilation terminated.
>
> The offending invocation of the compiler is:
> x86_64-w64-mingw32-g++ -DHAVE_CONFIG_H -I. -I../../include-Ofast -fPIC
> -D_ICU_ -DCURLAVAILABLE
> -I/nix/store/mkzj31p69kxrhar1b2l5vq7hkd1n45i4-curl-x86_64-w64-mingw32-8.9.1-dev/include
> -DCURLSFTPAVAILABLE -DUSEICUREGEX  -Wno-address -Wno-nonnull-compare
> -Wno-unused-but-set-variable -Wno-unknown-warning-option
> -DU_USING_ICU_NAMESPACE=1 -Wint-to-pointer-cast -fpermissive -D_ICUSWORD_
> -DCURL_STATICLIB -ftemplate-depth=100 -c -o corediatheke.o corediatheke.cpp
>
> I have tried this both with the -DUSEICUREGEX and with only the internal
> version, but that doesn't seem to affect this. It looks like the diatheke
> compile invocation needs to include -I../include/interna/regex when the
> internal regex.h is requested.
>
> Am I missing something to set that flag?
>
> --Greg
>
diff --git a/utilities/diatheke/Makefile.am b/utilities/diatheke/Makefile.am
index 8ba34e5..545af2c 100644
--- a/utilities/diatheke/Makefile.am
+++ b/utilities/diatheke/Makefile.am
@@ -1,5 +1,8 @@
 AUTOMAKE_OPTIONS = 1.6
 
+if USE_INTERNAL_REGEX
+AM_CPPFLAGS = -I$(top_srcdir)/include/internal/regex
+endif
 LDADD = $(top_builddir)/lib/libsword.la
 
 bin_PROGRAMS = diatheke
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

[sword-devel] regex.h

[Greg Hellings]

I'm trying to build SWORD in an environment without a system regex.h. The
library build itself goes great, but diatheke fails to find the internal
regex.h file, ending with this error.

sword-x86_64-w64-mingw32> corediatheke.cpp:29:10: fatal error: regex.h: No
such file or directory
sword-x86_64-w64-mingw32>29 | #include 
sword-x86_64-w64-mingw32>   |  ^
sword-x86_64-w64-mingw32> compilation terminated.

The offending invocation of the compiler is:
x86_64-w64-mingw32-g++ -DHAVE_CONFIG_H -I. -I../../include-Ofast -fPIC
-D_ICU_ -DCURLAVAILABLE
-I/nix/store/mkzj31p69kxrhar1b2l5vq7hkd1n45i4-curl-x86_64-w64-mingw32-8.9.1-dev/include
-DCURLSFTPAVAILABLE -DUSEICUREGEX  -Wno-address -Wno-nonnull-compare
-Wno-unused-but-set-variable -Wno-unknown-warning-option
-DU_USING_ICU_NAMESPACE=1 -Wint-to-pointer-cast -fpermissive -D_ICUSWORD_
-DCURL_STATICLIB -ftemplate-depth=100 -c -o corediatheke.o corediatheke.cpp

I have tried this both with the -DUSEICUREGEX and with only the internal
version, but that doesn't seem to affect this. It looks like the diatheke
compile invocation needs to include -I../include/interna/regex when the
internal regex.h is requested.

Am I missing something to set that flag?

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

[sword-devel] Windows tools build

[Greg Hellings]

SWORD fam:

I've been working my way towards a new and more convenient way to build
SWORD utils for Windows. You can read about the journey and how it's
*almost* complete over on my blog:
https://thehellings.com/posts/sword-cross-20241018/. There is also a link,
there, to download the binary.

It's a build of the latest release 1.9.0 rather than SVN head. Once I get
the last few libraries working in the native upstream, I will put together
a way to build SVN head. It's not difficult, I'm just focusing at the
moment on enabling the cross build.

Those of you on Windows, if you could give them a spin, I would appreciate
it. I verified that they're at least able to execute on my local system,
but I don't have any real use for them on that machine to do any extensive
testing. Although they might not be the very latest versions of the tools,
themselves, they do come with the latest versions of the dependency
libraries like libcurl and especially ICU.

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] HarmonyOS - lacking a SWORD app

[Greg Hellings]

The better question is: Does anyone at all in our community use it? I'm
certain there are users of HarmonyOS in China with how large Huawei is. But
are any of them part of our community?

--Greg

On Wed, Oct 16, 2024 at 6:35 AM David Haslam  wrote:

> Hi Tuomas,
>
> That’s as maybe for now, but the Wikipedia article includes this:
>
> The next iteration of HarmonyOS known as HarmonyOS NEXT was announced on
> August 4, 2023. It replaces the OpenHarmony multi-kernel system with its
> own HarmonyOS microkernel at its core, removes all Android code and
> supports only apps in its native App format. It is currently in beta
> testing and is expected to launch in the fourth quarter of 2024.
>
> So maybe my email should’ve been titled “HarmonyOS NEXT”.
>
> Regards,
>
> David.
>
>
>
>
>
> On Wed, Oct 16, 2024 at 12:18, Tuomas Airaksinen <
> tuomas.airaksi...@gmail.com
> > wrote:
>
> AndBible is available in AppGallery, I believe it should work with
> HarmonyOS but haven't tested.
>
> On Wed, Oct 16, 2024 at 2:15 PM David Haslam < dfh...@protonmail.com>
> wrote:
>
>> Dear app developers,
>>
>> HarmonyOS is the platform for the latest generation of Huawei smartphones.
>>
>> https://en.wikipedia.org/wiki/HarmonyOS?wprov=sfti1
>>
>> Most of us probably haven’t heard of it before.
>>
>> It would be worthwhile to develop a SWORD app for this and to make it
>> available via the Huawei AppGallery.
>>
>> Although earlier models could side-load Android apps, this will not be
>> possible going forward.
>>
>> Best regards,
>>
>> David
>> 
>>
>>
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>
>
> --
> T: Tuomas
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] problem in libsword in indexing Genesis?

[Greg Hellings]

Can you be more specific about what it does? I haven't noticed any issue in
Ezra on Android.

--Greg

On Sun, Oct 13, 2024, 2:45 AM Kovács Zoltán  wrote:

> Hi,
> I use BibleTime and Xiphos on Ubuntu Linux 24.04. They are based on
> libsword (version 1.9 at the moment). It seems that both programs have
> issues when trying to read Genesis or jumping on certain verses in Genesis.
> This is independent of which module (Bible translation) I use, I tried KJV
> and others (including non-English translations), but I guess there must be
> a bug somewhere in libsword. Other books than Genesis work fine.
> Does anybody experience something like this? I have been
> facing this problem for a couple of years already, so maybe it's related
> not to version 1.9 but also earlier ones.
> Thanks for any hints in advance.
> Best, Zoltán
>
> --
>
> *Dr. Zoltán** Kovács, MSc*
>
> Institut Ausbildung
>
>
>
>
> *Private Pädagogische Hochschule der Diözese Linz*
> *Private University of Education, Diocese Linz**Salesianumweg 3, 4020
> Linz
> *
> *Mail: zoltan.kov...@ph-linz.at *
>
> *Web: www.ph-linz.at *
>
> *RGate: **https://www.researchgate.net/profile/Zoltan-Kovacs-3
> *
>
>
> 
>
> *Aktuelle Veröffentlichungen:*
>
>
>- Noah Dana-Picard and Zoltán Kovács. “Estrella Solitaria in offset
>curves”. In: The 29nd International Conference on Applications of
>Computer Algebra ACA’2024, Program & Abstracts.
>https://www.math.unm.edu/~aca/ACA/2024/Education/Dana-Picard.pdf. June
>2024.
>- Zoltán Kovács. “Easy (but exact) study of caustics of conics”. In:
>Research Journal of Mathematics & Technology 13.1 (2024), pp. 39–59.
>- Zoltán Kovács and Reinhard Oldenburg. “A Technological Approach to
>Teaching Inequalities, Propositional and Predicate Logic”. In: 9th
>International Workshop on Satisfiability Checking and Symbolic
>Computation, July 2, 2024, Nancy, France, Collocated with IJCAR 2024.
>Ed. by Chris Brown, Daniela Kaufmann, Cláudia Nalon, Alexander Steen, and 
> Martin
>Suda. 3717 vols. July 2, 2024, pp. 122–131. eprint:
>http://ceur-ws.org/Vol-3717/paper7.pdf.
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Issues accessing STEP Bible repository?

[Greg Hellings]

I can't tell which repo is causing it because it is just a progress bar
when updating all repos. But yes, it is getting hung up for me. Been doing
it for at least a few weeks, stalling out at 90%, but still showing most
translations.

--Greg

On Sat, Sep 28, 2024, 1:44 PM Tobias Klein  wrote:

> Hi all,
>
> an Ezra Bible App user on Android reported issues with the repository
> update in Ezra.
>
> When I debugged the issue I could reproduce it on my phone and found
> that all repositories update successfully except the STEP Bible one -
> where it seems that the process runs into a timeout.
>
> Does anyone else have issues accessing the STEP Bible repo?
>
> Best regards,
> Tobias
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Access of SWORD repos through proxy?

[Greg Hellings]

If you have compiled SWORD with libcurl support for its transport, you can
just leverage built in SOCKS support in libcurl. I don't know how you'd do
this in a mobile app (you probably would need to expose it to the user in
your UI), but it should work transparently to the user once the environment
variables are set.

https://blog.emacsos.com/use-socks5-proxy-in-curl.html

--Greg

On Sun, Sep 1, 2024, 12:58 Tobias Klein  wrote:

> Thank you, Jaak and David,
>
> I have passed on your feedback to the user.
>
> See
>
> https://github.com/ezra-bible-app/ezra-bible-app/discussions/1093#discussioncomment-10512596
>
> Best regards,
> Tobias
>
> On 8/31/24 5:29 PM, Jaak Ristioja wrote:
> > Hi,
> >
> > I'm assuming your SOCKS5 traffic flows through a sufficiently
> > encrypted network tunnel.
> >
> > For Linux, there are programs which allow to run other programs and
> > direct their network traffic to some SOCKS5 proxy, e.g. proxychains-ng:
> >
> >   https://github.com/rofl0r/proxychains-ng/
> >
> > On Debian, Ubuntu and their derivates one can likely install it by using
> >
> >   sudo apt-get install proxychains4
> >
> > Proxychains-ng needs to be configured via /etc/proxychains.conf,
> > ~/.proxychains/proxychains.conf or proxychains.conf in the current
> > working directory unless the -f command line option is used to specify
> > a different location. After configuration, one should be able to run
> > programs via commands like
> >
> >   proxychains4 your_program --with=any arguments
> >
> > However, the problem with such tools is that they might not always
> > work as intended. For example when network traffic flows via paths
> > which tools like proxychains-ng do not know to intercept. Fpr example,
> > this is sometimes the case for DNS traffic (hostname to IP address
> > lookups) which is sometimes handled via external programs (e.g. DNS
> > cache service on local machine). So be sure to always thorougly test
> > (e.g. using network traffic analysis) whether this actually works
> > properly before actual use, and that nothing leaks. And test again
> > after ANY software updates or configuration changes. So be VERY VERY
> > CAREFUL when using things like proxychains-ng.
> >
> > A safer option might be to use something like Tails, a Debian Linux
> > based operating system which forces all programs to network over a
> > local SOCKS proxy providing Tor. It might be possible to configure
> > Tails to use some other SOCKS5 proxy as well.
> >
> > Regarding Tor, please note that in its simplest configuration Tor
> > attempts to connect to public Tor relays, making it possible for
> > eavesdroppers to detect Tor usage. A way around this (as suggested by
> > the Tor project) is to use (private) Tor bridges which use domain
> > fronting, traffic obfuscation and similar tricks. You might also find
> > some of these technologies useful for the tunneling the SOCKS5 traffic.
> >
> >
> > Best regards,
> > Jaak
> >
> >
> > PS: All security technologies and their implementations, including
> > proxychains-ng, Tails and Tor, have their weak points. So take care
> > when evaluating their fitness for your particular purpose.
> >
> >
> > On 31.08.24 14:20, Tobias Klein wrote:
> >> Hi Troy and all,
> >>
> >> One of the Ezra users has asked the following:
> >>
> >>
> >> The websites for updating modules and downloading Bibles are either
> >> inaccessible or subject to censorship for people living in countries
> >> that restrict internet access.
> >>
> >> Could the program be updated to support setting up a SOCKS5 or HTTP
> >> proxy, allowing users to access the internet through a proxy?
> >>
> >>
> >>
> >> How do you assess this request from a SWORD library perspective?
> >>
> >>
> >> Best regards,
> >> Tobias
> >>
> >>
> >> ___
> >> sword-devel mailing list: sword-devel@crosswire.org
> >> http://crosswire.org/mailman/listinfo/sword-devel
> >> Instructions to unsubscribe/change your settings at above page
> >
> > ___
> > sword-devel mailing list: sword-devel@crosswire.org
> > http://crosswire.org/mailman/listinfo/sword-devel
> > Instructions to unsubscribe/change your settings at above page
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Creating a "SWORD-over-network" protocol for remote SWORD repo access?

[Greg Hellings]

It really comes down to if Troy likes the idea. On threads like this he
usually lets everyone kick around ideas and discussions before making a
final decision. In my impression he is most welcoming of extra code like
this if it is optional. For instance the support for HTTP and HTTPS plus
HTML parsing was more than initially desired, but once we proposed it could
go behind the existing optional build flag for libcurl he was willing to
accept it. That allows people who want the minimum experience on super tiny
devices like a feature phone to still get their work done while people on
bigger devices can compile in library support for the extra features.

In my vision of the implementation you'd still send the data over an HTTP/S
transport, so hiding the feature behind libcurl flags would make sense
again. It also shouldn't need JSON or other more structured formats for
parsing, because it would send the whole blob just as it should be returned
from the method. But I would need to look deeply into the code and I'm on
mobile right now.

--Greg

On Sat, Aug 3, 2024, 15:39 Aaron Rainbolt  wrote:

> On Sat, Aug 3, 2024 at 3:03 PM Greg Hellings 
> wrote:
> >
> >
> >
> > On Sat, Aug 3, 2024, 14:41 Aaron Rainbolt  wrote:
> >>
> >> On Sat, Aug 3, 2024 at 5:30 AM Jaak Ristioja  wrote:
> >> >
> >> > On 29.07.24 11:10, Aaron Rainbolt wrote:
> >> > > The idea is to make it so that *existing* SWORD clients can be able
> to
> >> > > access data on remote servers without downloading the whole thing. I
> >> > > laid out some reasons why this is helpful in certain use cases in my
> >> > > first email. Existing SWORD clients are meant to retrieve
> information
> >> > > from libsword and then render it in somme way, thus to maximize the
> >> > > possibility of adoption, my hope was to implement in libsword the
> >> > > ability to fetch "raw" data from a remote server and then pass it
> >> > > through to the client, which already has code for rendering it
> however
> >> > > the client chooses. Ideally a client should need to do nothing more
> >> > > than point an SWMgr object at the remote server and then use it
> exactly
> >> > > the same way it would use a local repository (perhaps with some
> extra
> >> > > error checks for things like timeouts, interrupted connections, and
> >> > > whatnot).
> >> >
> >> > In my opinion, this is not worth the effort. Is it really too much for
> >> > the client to download the whole module(s) to some temporary storage
> or RAM?
> >>
> >> Depending on the module, yes. I've worked on Internet connections that
> >> were so slow that module downloads repeatedly timed out and failed. If
> >> I am using a SWORD client that has access to remote data, I don't want
> >> to have to wait thirty seconds to switch modules, and have some
> >> modules just outright refuse to work. I want to be able to work almost
> >> as fast and seamlessly as if I had the modules locally. Also for
> >> someone who used a lot of modules in their study, having these modules
> >> be temporarily downloaded on the fly could consume a lot of RAM or
> >> disk space (which may be a problem for users who are stuck with
> >> underpowered hardware), and they would have to be repeatedly
> >> downloaded every time they opened the client. For someone working with
> >> a modern laptop on gigabit WiFi, this might be comfortable, but for
> >> the person in (for instance) Africa working with a 32-bit Celeron on a
> >> dialup connection, this is not going to work.
> >>
> >> > Also, how do you envision this to work with existing SWORD clients?
> >>
> >> Ideally when making an SWMgr object, they could just pass a URL to the
> >> object pointing it to the remote repository, then use it as if it were
> >> local. Listing all modules would give you a list of all remote
> >> modules, fetching parts of a module would fetch them from a remote
> >> server, etc. For the client, it should be totally transparent except
> >> for the initial connection, and error handling in the event of a
> >> network issue.
> >
> >
> > To fit better within the Sword library implementation, you probably
> would just have the remote server setup as a normal remote like the current
> ones. When a user installed a module from the server, it would be sent the
> conf file which would hold all the metadata I mentioned earlier. However,
> instead of one of the existing S

Re: [sword-devel] Creating a "SWORD-over-network" protocol for remote SWORD repo access?

[Greg Hellings]

On Sat, Aug 3, 2024, 14:41 Aaron Rainbolt  wrote:

> On Sat, Aug 3, 2024 at 5:30 AM Jaak Ristioja  wrote:
> >
> > On 29.07.24 11:10, Aaron Rainbolt wrote:
> > > The idea is to make it so that *existing* SWORD clients can be able to
> > > access data on remote servers without downloading the whole thing. I
> > > laid out some reasons why this is helpful in certain use cases in my
> > > first email. Existing SWORD clients are meant to retrieve information
> > > from libsword and then render it in somme way, thus to maximize the
> > > possibility of adoption, my hope was to implement in libsword the
> > > ability to fetch "raw" data from a remote server and then pass it
> > > through to the client, which already has code for rendering it however
> > > the client chooses. Ideally a client should need to do nothing more
> > > than point an SWMgr object at the remote server and then use it exactly
> > > the same way it would use a local repository (perhaps with some extra
> > > error checks for things like timeouts, interrupted connections, and
> > > whatnot).
> >
> > In my opinion, this is not worth the effort. Is it really too much for
> > the client to download the whole module(s) to some temporary storage or
> RAM?
>
> Depending on the module, yes. I've worked on Internet connections that
> were so slow that module downloads repeatedly timed out and failed. If
> I am using a SWORD client that has access to remote data, I don't want
> to have to wait thirty seconds to switch modules, and have some
> modules just outright refuse to work. I want to be able to work almost
> as fast and seamlessly as if I had the modules locally. Also for
> someone who used a lot of modules in their study, having these modules
> be temporarily downloaded on the fly could consume a lot of RAM or
> disk space (which may be a problem for users who are stuck with
> underpowered hardware), and they would have to be repeatedly
> downloaded every time they opened the client. For someone working with
> a modern laptop on gigabit WiFi, this might be comfortable, but for
> the person in (for instance) Africa working with a 32-bit Celeron on a
> dialup connection, this is not going to work.
>
> > Also, how do you envision this to work with existing SWORD clients?
>
> Ideally when making an SWMgr object, they could just pass a URL to the
> object pointing it to the remote repository, then use it as if it were
> local. Listing all modules would give you a list of all remote
> modules, fetching parts of a module would fetch them from a remote
> server, etc. For the client, it should be totally transparent except
> for the initial connection, and error handling in the event of a
> network issue.
>

To fit better within the Sword library implementation, you probably would
just have the remote server setup as a normal remote like the current ones.
When a user installed a module from the server, it would be sent the conf
file which would hold all the metadata I mentioned earlier. However,
instead of one of the existing SWModule implementation classes that reads
from disk (we have zText classes for compressed files, RawText for
uncompressed, etc) the implementation would be a RemoteText and it would
simply request from the original server the binary blobs it needs. (In
Sword parlance, "Text" are modules with verse based keys like a Bible or
Commentary. But the same parallel exists for LD - lexicon/dictionary - and
general books. You would need to implement both of those if you wanted to
support the full set of modules.)

If you could accomplish that, it should be completely transparent to the
existing clients and not require much tweaking to the library. The SWMgr
mechanism that instantiates the concrete class based on the module config
type would need to know about your classes and that should be it.

I doubt that this would ever end up in the library, but if it did, that
would probably be the most backwards compatible mechanism.

--Greg

>
> > Best regards,
> > Jaak
> > ___
> > sword-devel mailing list: sword-devel@crosswire.org
> > http://crosswire.org/mailman/listinfo/sword-devel
> > Instructions to unsubscribe/change your settings at above page
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Creating a "SWORD-over-network" protocol for remote SWORD repo access?

[Greg Hellings]

On Mon, Jul 29, 2024 at 12:45 PM Aaron Rainbolt 
wrote:

> On Mon, 29 Jul 2024 08:44:54 -0500
> Greg Hellings  wrote:
>
> > On Mon, Jul 29, 2024 at 3:26 AM Aaron Rainbolt 
> > wrote:
> >
> > > On Sun, 28 Jul 2024 23:08:33 -0500
> > > Greg Hellings  wrote:
> > > >
> > > > Now, to switch to the idea of a specialized SWORD protocol to
> > > > address the user who does not want to fetch the entirety of a
> > > > module: why? The library can already generate HTML documents and
> > > > document fragments. Just do the rendering on the server and pass
> > > > the fragment to the client over HTTP. Wrap the rendered string
> > > > into a JSON object if you need to. Why try to pass the binary
> > > > blob of some random data to the remote unit when you could
> > > > already render it on the server?
> > >
> > > The idea is to make it so that *existing* SWORD clients can be able
> > > to access data on remote servers without downloading the whole
> > > thing. I laid out some reasons why this is helpful in certain use
> > > cases in my first email. Existing SWORD clients are meant to
> > > retrieve information from libsword and then render it in somme way,
> > > thus to maximize the possibility of adoption, my hope was to
> > > implement in libsword the ability to fetch "raw" data from a remote
> > > server and then pass it through to the client, which already has
> > > code for rendering it however the client chooses. Ideally a client
> > > should need to do nothing more than point an SWMgr object at the
> > > remote server and then use it exactly the same way it would use a
> > > local repository (perhaps with some extra error checks for things
> > > like timeouts, interrupted connections, and whatnot).
> > >
> >
> > A few caveats that might dissuade you from sending the raw data:
> >
> > The raw data can be in multiple formats, depending on the source
> > module and fields in use. OSIS, TEI, ThML, RTF, and GBF are the most
> > common formats. Meanwhile there are also a few major output formats
> > that might be requested. HTML, RTF, plain text are the most common.
> > But I think there might also be support for TeX? I'm not 100% sure.
> > All of that metadata is stored in the module configuration file and
> > not at the verse level in the resulting file. Why force the client to
> > handle this parsing and consume the extra information when it could
> > just slurp up the requested format as rendered by the server. On top
> > of that the configuration file will have information on if there are
> > lemmas, footnotes, and other information all of which will inform how
> > to render a particular blob of text.
>
> The problem is that nothing but the raw data will work in the way I
> hope. What's Xiphos going to do with pre-rendered data? Or Bibletime?
> Or Ezra, or SWORDWeb, or Bishop, or AndBible? These all get raw info
> from the library and render it, using the render helpers in libsword
> to do so (if I remember correctly, it's been a while since I tried to
> write a SWORD client). If you give them prerendered data, they aren't
> going to know what to do with that. Again, my hope was for *existing
> SWORD clients* to be able to add support for use of remote repositories
> with as little effort as possible. I don't expect the developers of any
> of these apps to spend their valuable time adding support for an
> entirely new input format (prerendered JSON) to their apps. I suspect
> they'd be willing to spend thirty minutes or so to add network support
> using the approach I'm suggesting though.
>

Actually not really. Most of the client's simply ask the library, "Please
give me the HTML for this" or "Please give me the plaintext for this". They
don't get the raw data and then pass it through the filters themselves.
They can do that, but it's rare. More often they'll construct an SWMgr
object with target FOO output format and then just call the renderText
method on that object with no knowledge of what it came from or how it got
into the FOO format. So your idea can still completely work under the hood
of the SWMgr. It just wouldn't be reading the file from local storage but
instead fetching it remotely. It would slot in nicely with the existing
system and would require 0 modification from existing applications other
than a way to specify the source type. And they all already know how to
specify remote repositories.

Where it is rendered is a moot point there. I was just suggesting you push
that off to the server in 

Re: [sword-devel] Creating a "SWORD-over-network" protocol for remote SWORD repo access?

[Greg Hellings]

On Mon, Jul 29, 2024 at 3:26 AM Aaron Rainbolt  wrote:

> On Sun, 28 Jul 2024 23:08:33 -0500
> Greg Hellings  wrote:
> >
> > Now, to switch to the idea of a specialized SWORD protocol to address
> > the user who does not want to fetch the entirety of a module: why?
> > The library can already generate HTML documents and document
> > fragments. Just do the rendering on the server and pass the fragment
> > to the client over HTTP. Wrap the rendered string into a JSON object
> > if you need to. Why try to pass the binary blob of some random data
> > to the remote unit when you could already render it on the server?
>
> The idea is to make it so that *existing* SWORD clients can be able to
> access data on remote servers without downloading the whole thing. I
> laid out some reasons why this is helpful in certain use cases in my
> first email. Existing SWORD clients are meant to retrieve information
> from libsword and then render it in somme way, thus to maximize the
> possibility of adoption, my hope was to implement in libsword the
> ability to fetch "raw" data from a remote server and then pass it
> through to the client, which already has code for rendering it however
> the client chooses. Ideally a client should need to do nothing more
> than point an SWMgr object at the remote server and then use it exactly
> the same way it would use a local repository (perhaps with some extra
> error checks for things like timeouts, interrupted connections, and
> whatnot).
>

A few caveats that might dissuade you from sending the raw data:

The raw data can be in multiple formats, depending on the source module and
fields in use. OSIS, TEI, ThML, RTF, and GBF are the most common formats.
Meanwhile there are also a few major output formats that might be
requested. HTML, RTF, plain text are the most common. But I think there
might also be support for TeX? I'm not 100% sure. All of that metadata is
stored in the module configuration file and not at the verse level in the
resulting file. Why force the client to handle this parsing and consume the
extra information when it could just slurp up the requested format as
rendered by the server. On top of that the configuration file will have
information on if there are lemmas, footnotes, and other information all of
which will inform how to render a particular blob of text.

Much simpler to just tell the server, "Please send me HTML and strip out
footnotes" than to try and encode all of that, send it to the client, and
then render it there. Every round trip would essentially need the fully
parsed config file to travel with it in your proposed raw form.


> > A simple REST library written in something like Go could easily be
> > linked to the libsword C library. It could query libsword to get the
> > list of modules and expose them, along with certain query parameters
> > specifying the format request. Then serve the resulting text over
> > HTTP. So a client library could hit something like
> > http://mylibrary.com/texts/KJV/Gen/1/1?format=html and it will get back
> > {"osisRef": "Gen.1.1", "text": "In the beginning..."}. You
> > wouldn't need to write some low level application protocol. You would
> > save the client device from needing to render the text and have extra
> > knowledge of the module. You wouldn't have to alter the library in
> > any fashion.
>
> This is similar to what I was thinking. I wasn't sure if JSON was the
> best wrapper to do it in, but I don't see any reason to use
> anything else, other than SWORD's apparent preference for XML-like
> formats. However my "text" field would probably look more like "text":
> "$$$Revelation of John 22:19\n morph="robinson:CONJ" src="1">And..." or some such (this is what
> mod2imp spit out when I used it to get an example).
>

There are two difficulties with this as I can see. The first I mentioned in
the paragraph above. You and I can look at this and recognize it as OSIS,
but that information is only encoded in the configuration file. Likewise,
telling the renderer that lemmas and morphology are supported is encoded
there. Why not just allow the library to handle that?

Secondly, the library has no knowledge of the import format. Knolwedge of
parsing that block from an input formatted file is known only in the
imp2mod utility. That utility is not linked into the library. It is
frequently distributed with the library, but it is not an inherent part of
it. Similarly the mod2imp utility is not a portion of the library. Those
two applications handle the generating and parsing of the input format, and
no attempt is made by either one to preserve the full round-trip
functionality of the underlying en

Re: [sword-devel] Creating a "SWORD-over-network" protocol for remote SWORD repo access?

[Greg Hellings]

So looking at this, you need to understand the goal of the libsword library
and its repository system.

The goal for a repository is to support the simplest methods of access.
Especially to support access by people who have no network so that an
entire repository can be loaded directly onto a CD, DVD, USB stick, or
other external media and passed around. Libsword can then install directly
from that. FTP was first implemented because it allowed the same super
simplistic process of pointing an FTP server at a working repository and
then anyone who can access that FTP server can also access and install
modules from there.

The goal of repository access and installs is not to create or define a
standard. It is, rather, to have the very simplest and easiest access
possible. Others have come through and implemented some parsing for the
HTML served up over HTTP/HTTPS which can be used if libsword is compiled
with the optional libcurl support. When I first helped contribute to those
code bases they strove to support both the Apache and Nginx form of HTML
that was served up by the automatic indexing those servers offer. Again,
the goal was not to provide cryptographic security, it was not to sign
files, it was not to define a standardized server process, or use some more
robust standard like WebDAV or what have you. The goal was simplicity.
Initially to allow iPhone users access to remote repositories while on cell
networks where FTP was blocked by many carriers and possibly the device
itself to some extent. Again, the goal was simplicity of access - pointing
the root of a folder to a working repository installation would allow
someone to remotely access all of the resources on that remote repository.

So the rest of the concerns were not addressed because they are not part of
the goal. It's not the goal of the process to specify a strict format the
repository needs to be exposed by over the network nor to ensure
cryptographically signed files are transmitted. If those are needs for
someone's use cases, then they should be implemented outside of the SWORD
library and its native support. The goal of the library is to be very
small, very fast, and as broadly portable as possible to more or less any
device for which there is a C compiler available, and the goal of its
support for remote repositories is to make it as simple as possible to get
the data onto those devices. Thus, no standardized parser is required
(though anyone using the library is free to extend its code to use one)
because that becomes less portable and more heavyweight. Libcurl isn't even
required - though without it access to HTTP/HTTPS sources vanishes because
the library does not provide an implementation of that.

Again, small size, speed, and nimbleness are the goals of the library.
Anything else that needs to be implemented for someone's requirements is up
to them to implement above the library's level. Nothing stops someone from
writing an application that connects over WebDAV to a server, fetches the
SWORD files, checks them against cryptographic signatures, and uses well
known libraries to handle all of that. But it's not the goal of libsword to
offer that. That is much higher friction than the goal of the underlying
library.

--

Now, to switch to the idea of a specialized SWORD protocol to address the
user who does not want to fetch the entirety of a module: why? The library
can already generate HTML documents and document fragments. Just do the
rendering on the server and pass the fragment to the client over HTTP. Wrap
the rendered string into a JSON object if you need to. Why try to pass the
binary blob of some random data to the remote unit when you could already
render it on the server?

A simple REST library written in something like Go could easily be linked
to the libsword C library. It could query libsword to get the list of
modules and expose them, along with certain query parameters specifying the
format request. Then serve the resulting text over HTTP. So a client
library could hit something like
http://mylibrary.com/texts/KJV/Gen/1/1?format=html and it will get back
{"osisRef": "Gen.1.1", "text": "In the beginning..."}. You wouldn't
need to write some low level application protocol. You would save the
client device from needing to render the text and have extra knowledge of
the module. You wouldn't have to alter the library in any fashion.

A simple application like this could be written up, distributed in a static
binary, and anyone would be able to hit it for a REST accessed, rendered
format of a given text. Going back to the goal of simplicity: this
application could be run by anyone on any computer where a SWORD library
already existed, and it could serve the baseline of those peoples' needs.

That's just an idea I've had bouncing around in my head for a long time. I
just have no need to access the scripture over REST or I would have already
written it. All the bits are already out there. There are lots of good REST
fram

Re: [sword-devel] Tumbleweek Packages

[Greg Hellings]

On Mon, Mar 11, 2024 at 4:21 PM Matěj Cepl  wrote:

> On Mon Mar 11, 2024 at 9:44 PM CET, David "Judah's Shadow" Blue wrote:
> > While we're on the topic of tumbleweed, do we know if there is a pumpkin
> > holder for the sword packages for openSUSE is, or if there even is one?
> I've
>
> These people https://build.opensuse.org/package/users/Education/sword ?
>
> I have tried to make my own submission to sword (not very well
> thought through, I am afraid) and I was rightfully run away by
> somebody.
>

I didn't run you away, but I am the pumpkin holder for libsword in SuSE.

Which is hilarious because the last time I installed SuSE on anything was
at least 15 years ago, probably more.

I can accept merge requests in the SuSE build infrastructure. But I
wouldn't even attempt to create one or vet that it's working properly
without having access to the distro.

--Greg

>
> Blessings,
>
> Matěj
>
> --
> http://matej.ceplovi.cz/blog/, @mcepl@floss.social
> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
>
> If trains stop at train stations, what happens at work stations?
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SWORD Dependancies

[Greg Hellings]

You really SHOULD have sword built against Curl. It can work without it,
but only against FTP and local file sources. All support for HTTP, HTTPS
(which most modern systems will require) only work with curl.

It's also common to have something like clucene or xapian for enhanced
search. But definitely not necessary.

I'm surprised there's no libz listed in those deps. I thought we linked
against that, but maybe we zip support vendored?

--Greg


On Sat, Mar 9, 2024, 13:26 David "Judah's Shadow" Blue 
wrote:

> On Saturday, March 9, 2024 2:15:40 PM EST Matěj Cepl wrote:
> > Well, this is what I get on openSUSE/Tumbleweed:
> >
> > tumbleweed-pkg~$ rpm -qR sword|awk -F '(' '{ print $1 ; }'|sort -u
> > config
> > libc.so.6
> > libgcc_s.so.1
> > libicuuc.so.73
> > libstdc++.so.6
> > libsword-1.8.1.so
> > rpmlib
> > Really, not much.
>
> Ok. Yeah, I didn't figure much, I knew the sword lib at least used to use
> curl
> for some things, but didn't know if that was the sort of thing I could
> assume
> would be installed if sword was installed.
>
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] What markup format is SWORD's internal markup, and/or where is it documented?

[Greg Hellings]

The actual files are a custom binary format which is not documented and is
not intended to be any sort of standard accessed by anything other than the
library itself.

Most newer works are imported from an OSIS file. Some older ones were
imported from GBF (I think?) or ThML (which is basically some basic HTML
display components mixed with a few tags for identifying things like words
of Christ or divine names). However, once they are imported as modules some
of that structure is lost to the proprietary binary format of the SWORD
module files.

If you want the text in Markdown the best way is to create a filter like
the existing filters in the engine which can be used to generate HTML,
LaTeX, etc and write some which produce Markdown output.

Although, since Markdown is basically simplified HTML that is specifically
intended to make HTML easier to write, why wouldn't you just render out
HTML from the existing filters and drop that into your Markdown editor?
Every md editor and renderer I've used will pass HTML through unchanged,
allowing the author to use its full syntax when they wanted to.

On Fri, Dec 15, 2023, 21:04 Aaron Rainbolt  wrote:

> I had an idea of making a primarily Markdown-centric SWORD frontend
> that would help with writing Bible studies and whatnot for
> Markdown-based platforms like Reddit or Obsidian notes. For this
> purpose, I want to parse the internal markup used by SWORD in its
> modules, and then use my own custom code to generate Markdown from
> that.
>
> Obviously I can learn a lot about this markup by simply looking at
> modules that use it, but I do wonder, is this markup at all
> standardized? Is it documented anywhere? Does it have a name of some
> sort that I can use to find handlers and tools for it in the SWORD API
> docs?
>
> Thanks,
> Aaron
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Fwd: [sword-support] Please add Sword Project to Winget on Windows

[Greg Hellings]

winget is pretty great. It works about like you'd expect from any other
package manager. And it has a very large collection of libraries and
software already available for it. As for how to add to it, I haven't the
slightest idea as creating packages for Windows is not a target I've
undertaken.

On Mon, Nov 27, 2023 at 7:03 PM Troy A. Griffitts 
wrote:

> For those who build packages for Windows.  We received this request on
> sword-support.  It sounds interesting.
>
>
>  Forwarded Message 
> Subject: [sword-support] Please add Sword Project to Winget on Windows
> Date: Wed, 8 Nov 2023 16:12:57 + (UTC)
> From: southpaw...@yahoo.com 
> 
> Reply-To: southpaw...@yahoo.com 
> 
> To: sword-feedb...@crosswire.org 
> 
>
> Sir or Ma'am,
>
> I had a catastrophic fail on Windows resulting in a fully reset operating
> system recently. I looked for some "newer" option for installations and
> there was an option called winget in powershell 7, and likely earlier(You
> can disable powershell 2, uninstall the microsoft store powershell 5 and
> just use powershell 7 and winget - https://winstall.app/ ). It's amazing.
> I installed all the software I could through winget, and I have found
> software dependencies update through winget easily(including dependencies
> from software installed by Steam).
>
> However, I also found that very little Bible software is using winget
> which is why I'm requesting this. There's BPBible, which requires additions
> separately downloaded through a web browser and Logos 9. Other than than,
> there's nothing Bible there. There's not even Bible memory apps.
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Where is the source code for individual SWORD modules?

[Greg Hellings]

In general the imported file will not be available since it is not the
source of those modules. Other than for the KJV itself, Crosswire is not
the authoritative source of the texts. Often any OSIS file is a product of
a conversation from the original source. If anything has been kept it
should be a script to produce that OSIS file so that, if the source
material is updated, the module can be automatically created from it. Very
old modules which have not been updated in a decade+ might not have any
reproducible material floating around at all if they predate that process.

The KJV(A) module pair are the exception to this and should be located on
the server somewhere.

As for generating LaTeX, I thought the engine could already do that? I
thought Peter had added a filter for that back when he was doing some work
with the texts. You should be able to iterate module and generate the text
from there, if a render filter exists for LaTeX. If not, now would be a
great time for you to learn the filter API (it is akin to an XML SAX style
of interface) and write one!

--Greg

On Fri, Oct 20, 2023, 23:28 Aaron Rainbolt  wrote:

> Gah, I am forgetful. I can just use mod2imp to get parsable text. It's
> not exactly what I was looking for but it'll work good enough :D
>
> On 10/20/23 23:15, Aaron Rainbolt wrote:
> > I don't know if I'm just blind or if these aren't public, but I cannot
> > find the OSIS (or whatever format) code for individual SWORD modules
> > in the Crosswire repository. Specifically I'm trying to find the
> > source for the AKJV module. I'd like to take the code and parse it
> > myself for a project of my own (I'm trying to typeset the AKJV
> > translation using LaTeX, and may want to do the same sort of thing
> > with other modules). As it is, I'm having to open the modules in
> > Xiphos, and then copy and paste their text one chapter at a time into
> > my formatting tools, which is... cumbersome. If I could get the source
> > code for the modules, I could just write a parser that would do the
> > whole job for me in one go.
> >
> > Are the OSIS sources kept private intentionally? If not, where would I
> > find them to download them?
> >
> > (Note that I understand why some modules' source code might be
> > private, for things like the NASB module. But it would be nice if the
> > code for public domain or otherwise permissively licensed modules were
> > available for public download.)
> >
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream

[Greg Hellings]

I've gone ahead and directly added you as an admin on the two projects.

On Thu, Oct 5, 2023 at 1:00 PM Aaron Rainbolt  wrote:

> On 9/28/23 11:29, Greg Hellings wrote:
> >
> >
> > On Thu, Sep 28, 2023, 12:14 Aaron Rainbolt  wrote:
> >
> > Hey, thanks for your help!
> >
> > I was able to just repack and remove most everything offending. I
> > figured I should share the info upstream so that if there was
> > anything
> > you wanted to do on your end, you could, but obviously if you're
> > comfortable keeping things as they are, I don't have a problem
> > with that :)
> >
> >
> > There are others who are pumpkin holders for separate parts and
> > they'll need to decide on updating their pieces. I own CMake and the
> > Swig bindings (Python and Perl for us).
> >
> >
> > I'll submit a patch for the Python bindings, the fix was fairly
> > simple.
> >
> > As for ftpparse, I could potentially try writing a replacement myself
> > and license it as GPLv2. We already probably have a good starting
> > point
> > since the FileZilla project is under GPL-2.0-or-later, and appears to
> > have its own independently developed directory litsing parser
> > written in
> > C++ (see
> >
> https://svn.filezilla-project.org/filezilla/FileZilla3/trunk/src/engine/directorylistingparser.cpp?revision=10945&view=markup
> > <
> https://svn.filezilla-project.org/filezilla/FileZilla3/trunk/src/engine/directorylistingparser.cpp?revision=10945&view=markup
> >).
> >
> > We could port the logic from that into something SWORD-compatible
> > perhaps?
> >
> >
> > That would probably work. Part of the goal with SWORD is that it needs
> > no hard external library dependencies. Thus why ftpparse has been
> > included inline. A novel contribution that replaces those but is still
> > highly portable C would likely be welcomed.
> >
> >
> > One more question about the CMake files, you mention that
> > FindXZ.cmake
> > is your original contribution and would be GPLv2, but it appears
> > to be
> > ported from the BSD-3-Clause FindBZIP2.cmake. Just to be clear,
> > since it
> > contains your modifications, it should be "upgraded" to GPLv2 as
> > it now
> > contains your GPLv2 contributions? If so, are there any other
> > files in
> > the CMake folder that should be similarly "upgraded"? Potentially
> > all of
> > them if they've all had to be modified for SWORD?
> >
> >
> > I don't believe I had to modify anything. They were simply pulled in
> > so I could maintain support for old versions of CMake - like on CentOS
> > 6 and old Ubuntu LTS versions at the time - that had the core
> > functionality needed but just lacked a file which newer CMake had
> > bundled. Including most of them is likely a moot point by now as those
> > versions are ancient. Yes, I undoubtedly modified it from FindBZIP2 as
> > it was a later addition to the optional dependencies. The only reason
> > to upgrade to GPL2 is that it's the exclusive license and version for
> > SWORD contributions, in absence of compelling reasons to the contrary.
> >
> >
> > Thanks so much for your help! Also, did you also previously maintain
> > Xiphos and Bibletime? If so, I would love to take maintainership of
> > those too so I can keep everything SWORD-related from dropping out of
> > Fedora.
> >
> >
> > I'm fairly certain that I am. If not the owner I was the defacto
> > maintainer. You are welcome to take over those packages, for sure. Let
> > me know if you need me to do the needful for that. I don't think
> > they've been officially orphaned for F39, but would be on the chopping
> > block for F40 in the absence of sword making it back in.
>
> Thanks! If all of the comaintainers for Xiphos and BibleTime are also no
> longer available or interested, I think it would be helpful if you could
> go into https://src.fedoraproject.org/rpms/xiphos and
> https://src.fedoraproject.org/rpms/bibletime and click the "Orphan"
> button on those. I'll take them once that's done and should be able to
> help keep them maintained.
>
> Thanks for all your help, and God bless!
>
> Aaron
>
> >
> > --Greg
> >
> >
> > God bless, and thanks again.
> >
> > Aaron
> >
> > On 9/28/23 07:05, Gr

Re: [sword-devel] [PATCH] Migrate setup.py files from using distutils to using setuptools

[Greg Hellings]

Aaron,

Your patch fails to apply against the head of SVN for me, with this error:

 @ patch -p1 < ../aaron-rainbolt.patch
patching file bindings/swig/oldmake/Makefile.am
Hunk #1 FAILED at 76.
1 out of 1 hunk FAILED -- saving rejects to file
bindings/swig/oldmake/Makefile.am.rej
patching file bindings/swig/package/Makefile.am
Hunk #1 FAILED at 84.
1 out of 1 hunk FAILED -- saving rejects to file
bindings/swig/package/Makefile.am.rej
can't find file to patch at input line 35
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|diff --git a/bindings/swig/package/Makefile.in
|b/bindings/swig/package/Makefile.in
|index b5f05c9..370a9e7 100644
|--- a/bindings/swig/package/Makefile.in
|+++ b/bindings/swig/package/Makefile.in
--
File to patch:

Furthermore, it looks like you are patching the autotools build system,
which is not supported in the Python and Perl bindings. Those are only
supported building through the CMake files. At least, they aren't supported
by me as I don't go near autotools, and last I knew I was the only one
working in the Swig bindings.

I don't know why your patch is failing to apply, as I don't believe there
should be any drift in those Makefiles. I'd be happy to try again if you
have any advice as to why the patch is not applying.

--Greg

On Thu, Sep 28, 2023 at 11:53 AM Aaron Rainbolt 
wrote:

> Good morning/evening, and thanks for your time.
>
> As distutils has been deprecated and finally removed in Python 3.12,
> SWORD is unable to build in Fedora without the following patch. The patch:
>
> * Replaces all references to distutils with their setuptools equivalents.
>
> * Modifies the build system to allow specifying a new CMake argument,
> "SWORD_PYTHON_INSTALL_ROOT", which allows setting the installation path
> for the Python bindings without generating a Python egg. (This is
> necessary since Python eggs have been deprecated as well and will likely
> be removed later. See https://github.com/pypa/setuptools/issues/3143 -
> specifying both a --root and a --prefix to the setup.py scripts seems to
> work around this issue.)
>
> All contributions in this patch are made available to the SWORD Project
> under the terms of the GNU General Public License version 2.
>
> Thanks for your consideration, and have a blessed day!
>
> Aaron
>
> (P.S. - the reason this appears to be a Git patch is because I used Git
> to let me generate a multi-file patch more easily. I realize SWORD uses
> SVN, sorry if this looks confusing.)
>
>
>
> From 07b31a74ea920077fa0d69cdab2ab188dd17b322 Mon Sep 17 00:00:00 2001
> From: Aaron Rainbolt 
> Date: Wed, 27 Sep 2023 10:51:27 -0600
> Subject: [PATCH] Migrate to setuptools
>
> ---
>   bindings/swig/oldmake/Makefile.am   | 2 +-
>   bindings/swig/package/Makefile.am   | 3 +--
>   bindings/swig/package/Makefile.in   | 3 +--
>   bindings/swig/python/CMakeLists.txt | 7 +--
>   4 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/bindings/swig/oldmake/Makefile.am
> b/bindings/swig/oldmake/Makefile.am
> index 45a37ef..789813b 100644
> --- a/bindings/swig/oldmake/Makefile.am
> +++ b/bindings/swig/oldmake/Makefile.am
> @@ -76,7 +76,7 @@ python_makebuild: $(PYTHONSWIG)
>   echo "writing python/setup.py"
>   @echo "#! /usr/bin/python" > python/setup.py
>   @echo "" >> python/setup.py
> -@echo "from distutils.core import setup, Extension" >> python/setup.py
> +@echo "from setuptools import setup, Extension" >> python/setup.py
>   @echo "setup (name = \"sword\"," >> python/setup.py
>   @echo "version = \"$(VERSION)\"," >> python/setup.py
>   @echo "maintainer = \"Sword Developers\"," >> python/setup.py
> diff --git a/bindings/swig/package/Makefile.am
> b/bindings/swig/package/Makefile.am
> index 14500c3..f44974d 100644
> --- a/bindings/swig/package/Makefile.am
> +++ b/bindings/swig/package/Makefile.am
> @@ -84,8 +84,7 @@ python_makebuild: $(PYTHONSWIG)
>   echo "writing python/setup.py"
>   @echo "#! /usr/bin/python" > python/setup.py
>   @echo "" >> python/setup.py
> -@echo "from distutils.core import setup" >> python/setup.py
> -@echo "from distutils.extension import Extension" >> python/setup.py
> +@echo "from setuptools import setup, Extension" >> python/setup.py
>   @echo "import commands" >> python/setup.py
>   @echo "" >> python/setup.py
>   @echo "def pkgconfig(*packages, **kw):" >> python/setup.py
> diff --git a/bindings/swig/package/Makefile.in
> b/bindings/swig/package/Makefile.in
> index b5f05c9..370a9e7 100644
> --- a/bindings/swig/package/Makefile.in
> +++ b/bindings/swig/package/Makefile.in
> @@ -938,8 +938,7 @@ python_makebuild: $(PYTHONSWIG)
>   echo "writing python/setup.py"
>   @echo "#! /usr/bin/python" > python/setup.py
>   @echo "" >> python/setup.py
> -@echo "from distutils.core import setup" >> python/setup.py
> -@echo "from distutils.extension import Extension" >> 

Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream

[Greg Hellings]

On Thu, Sep 28, 2023, 12:14 Aaron Rainbolt  wrote:

> Hey, thanks for your help!
>
> I was able to just repack and remove most everything offending. I
> figured I should share the info upstream so that if there was anything
> you wanted to do on your end, you could, but obviously if you're
> comfortable keeping things as they are, I don't have a problem with that :)
>

There are others who are pumpkin holders for separate parts and they'll
need to decide on updating their pieces. I own CMake and the Swig bindings
(Python and Perl for us).


> I'll submit a patch for the Python bindings, the fix was fairly simple.
>
> As for ftpparse, I could potentially try writing a replacement myself
> and license it as GPLv2. We already probably have a good starting point
> since the FileZilla project is under GPL-2.0-or-later, and appears to
> have its own independently developed directory litsing parser written in
> C++ (see
>
> https://svn.filezilla-project.org/filezilla/FileZilla3/trunk/src/engine/directorylistingparser.cpp?revision=10945&view=markup).
>
> We could port the logic from that into something SWORD-compatible perhaps?
>

That would probably work. Part of the goal with SWORD is that it needs no
hard external library dependencies. Thus why ftpparse has been included
inline. A novel contribution that replaces those but is still highly
portable C would likely be welcomed.


> One more question about the CMake files, you mention that FindXZ.cmake
> is your original contribution and would be GPLv2, but it appears to be
> ported from the BSD-3-Clause FindBZIP2.cmake. Just to be clear, since it
> contains your modifications, it should be "upgraded" to GPLv2 as it now
> contains your GPLv2 contributions? If so, are there any other files in
> the CMake folder that should be similarly "upgraded"? Potentially all of
> them if they've all had to be modified for SWORD?
>

I don't believe I had to modify anything. They were simply pulled in so I
could maintain support for old versions of CMake - like on CentOS 6 and old
Ubuntu LTS versions at the time - that had the core functionality needed
but just lacked a file which newer CMake had bundled. Including most of
them is likely a moot point by now as those versions are ancient. Yes, I
undoubtedly modified it from FindBZIP2 as it was a later addition to the
optional dependencies. The only reason to upgrade to GPL2 is that it's the
exclusive license and version for SWORD contributions, in absence of
compelling reasons to the contrary.


> Thanks so much for your help! Also, did you also previously maintain
> Xiphos and Bibletime? If so, I would love to take maintainership of
> those too so I can keep everything SWORD-related from dropping out of
> Fedora.
>

I'm fairly certain that I am. If not the owner I was the defacto
maintainer. You are welcome to take over those packages, for sure. Let me
know if you need me to do the needful for that. I don't think they've been
officially orphaned for F39, but would be on the chopping block for F40 in
the absence of sword making it back in.

--Greg


> God bless, and thanks again.
>
> Aaron
>
> On 9/28/23 07:05, Greg Hellings wrote:
> > Aaron,
> >
> > As the previous maintainer who dropped support, thank you for picking
> > it up. I have moved on from being a Fedora user (NixOS these days) and
> > was no longer maintaining those packages nor the apps that depend on
> > it. I am, however, the pumpkin holder for the Python and Perl
> > bindings. If you want to submit a patch to us that gets those working
> > again I would be happy to include it upstream.
> >
> > Any files under the cmake folder were contributed by me. Those noting
> > a license were taken from later CMake versions and would match
> > licenses there. The FindXZ file is my original contribution and is
> > under the GPLv2 like all other original SWORD code.
> >
> > The gSOAP and Objective-C bindings should be safe to remove in Fedora
> > as there is no need for them there.
> >
> > The win32 files would only affect the MinGW build of sword in Fedora,
> > which was not retired as it was unaffected by the Python changes.
> >
> > ftpparse is a constant thorn in our side whenever people become hung
> > up on the commercial clause. While not strictly necessary to SWORD, as
> > HTTP and HTTPS are supported if the library is built with cURL
> > support, it would be a huge loss of functionality for most users. It
> > probably is time to consider rewriting their functionality.
> >
> > The Android jar file is also unnecessary for your packaging and you
> > can safely delete it. And the whole pqa folder for diatheke should be
> >

Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream

[Greg Hellings]

Aaron,

As the previous maintainer who dropped support, thank you for picking it
up. I have moved on from being a Fedora user (NixOS these days) and was no
longer maintaining those packages nor the apps that depend on it. I am,
however, the pumpkin holder for the Python and Perl bindings. If you want
to submit a patch to us that gets those working again I would be happy to
include it upstream.

Any files under the cmake folder were contributed by me. Those noting a
license were taken from later CMake versions and would match licenses
there. The FindXZ file is my original contribution and is under the GPLv2
like all other original SWORD code.

The gSOAP and Objective-C bindings should be safe to remove in Fedora as
there is no need for them there.

The win32 files would only affect the MinGW build of sword in Fedora, which
was not retired as it was unaffected by the Python changes.

ftpparse is a constant thorn in our side whenever people become hung up on
the commercial clause. While not strictly necessary to SWORD, as HTTP and
HTTPS are supported if the library is built with cURL support, it would be
a huge loss of functionality for most users. It probably is time to
consider rewriting their functionality.

The Android jar file is also unnecessary for your packaging and you can
safely delete it. And the whole pqa folder for diatheke should be tossed.
Likely at the SVN level, as I'm sure we are not building Palm binaries
anymore.

Hope that helps.

--Greg


On Thu, Sep 28, 2023, 01:06 Aaron Rainbolt  wrote:

> Good morning/evening, and thanks for your time.
>
> Recently SWORD was removed from Fedora 39 because of a bug relating to
> the python bindings (it's still using distutils rather than setuptools,
> which needed to be fixed, but the maintainer didn't fix it in time). I'm
> attempting to get SWORD back into Fedora by fixing the issue, but as the
> package was already retired, I'm preparing to reintroduce it as if it
> were being added for the first time. For the sake of making things go
> smoothly, I did a full licensing audit on the SWORD source code to
> ensure that all licenses were compliant with Fedora's requirements.
>
> Some of the results of this audit were less-than-ideal, so I thought I
> would share the results with you so that you can take any measures you
> deem appropriate. I'm in the process of resolving these issues in Fedora.
>
> * There are several files under sword-1.9.0/cmake that have unclear
> licenses (referring to "the BSD license" but without specifying which
> version, and telling the user to look at a file that doesn't exist for
> the license details). I *believe* these files are licensed under
> BSD-3-Clause, as I found the original source for all but one of them,
> however I could not find the original source for
> sword-1.9.0/cmake/FindXZ.cmake.
>
> * The gSOAP bindings contain a file,
> sword-1.9.0/bindings/gsoap/include/stdsoap.h, which has no license and
> an "All rights reserved" notice.
>
> * The Objective-C bindings have a similar problem - the following files
> under sword-1.9.0/bindings/objc all have no license and an "All rights
> reserved" notice:
> - ObjCSword.h
> - src/Notifications.h (yes I realize this file consists entirely of
> comments but this is still worrying)
> - src/SwordBibleBook.h
> - src/SwordBibleBook.m
> - src/SwordBibleChapter.h
> - src/SwordBibleChapter.m
> - src/SwordBibleTextEntry.h
> - src/SwordBibleTextEntry.m
> - src/SwordInstallSource.h
> - src/SwordInstallManager.h
> - src/SwordInstallManager.mm
> - src/SwordInstallSource.mm
> - src/SwordKey.h
> - src/SwordKey.m
> - src/SwordListKey.h
> - src/SwordListKey.mm
> - src/SwordLocaleManager.h
> - src/SwordLocaleManager.mm
> - src/SwordModuleIndex.h
> - src/SwordModuleIndex.m
> - src/SwordModuleTextEntry.h
> - src/SwordModuleTextEntry.m
> - src/SwordTreeEntry.h
> - src/SwordTreeEntry.m
> - src/SwordVerseKey.h
> - src/SwordVerseKey.mm
> - src/SwordVerseManager.h
> - src/SwordVerseManager.m
> - src/VerseEnumerator.h
> - src/VerseEnumerator.m
> - src/services/Configuration.h
> - src/services/Configuration.m
> - src/services/iOSConfiguration.h
> - src/services/iOSConfiguration.m
> - src/services/OSXConfiguration.h
> - src/services/OSXConfiguration.m
> - SWORD/SWORD/SWORD.h
> - SWORD/SWORD/SWORD.m
> - test/SwordListKeyTest.h
> - test/SwordListKeyTest.m
> - test/SwordModuleLongRunTest.h
> - test/SwordModuleLongRunTest.mm
> - test/SwordModuleTest.h
> - test/SwordModuleTest.m
>
> * Two files under sword-1.9.0/src/utilfuns/win32 are under non-free
> licenses - they prohibit the sale of media containing those files for
> anything greater than the cost of distribution.
>
> * The files sword-1.9.0/include/ftpparse.h and
> sword-1.9.0/src/utilfuns/ftpparse.c are under informal non-free licenses
> prohibiting commercial use unless the

Re: [sword-devel] Adding some new modules to the Bible collection

[Greg Hellings]

It is also worth noting that CrossWire doesn't undertake these types of
tasks and does not want to be the main source for such original texts.
However, if another organization does make a digital text available,
CrossWire likely would be able to create a module from that efforts in a
reproducible way.

On Fri, Sep 15, 2023 at 10:54 AM David Haslam  wrote:

> Transcribing Bibles from the age before digital computers is best done by
> volunteers with MissionAssist UK.
>
> I can put you in contact with some of the friends who are volunteers.
>
> David Haslam
>
> Sent from Proton Mail  for iOS
>
>
> On Fri, Sep 15, 2023 at 16:44, D. Almeida  > wrote:
>
> Peace be upon you!!!
>
> I'd like to ask you, whether you could put in a digital format some old
> facsimiled Bibles, which have become out of print. All of them are on
> Public Domain: they range from the XVI-th to the XIX-th century.
>
> There are some old Ottoman Turkish, and Venice Mekhitarist translations,
> that could be of immense value, once made part of the library or
> digitalised:H
>
> 1. Helleno-Turkish (Turkish written in Greek alphabet):
>
> https://books.google.com/books?id=lj47cAAJ
> https://www.google.com/books/edition/Biblia_Turco_Greek/5Iw8cAAJ
>
> 2. Armeno-Turkish (Turkish written in Armenian alphabet):
>
> https://books.google.com/books?id=paxBYAAJ
>
> https://www.google.com/books/edition/Turkish_New_Testament_Written_in_Armenia/ViwwYAAJ
>
> https://www.google.com/books/edition/The_Bible_in_Turkish_written_in_Armenian/GhuHo5BZTcoC
>
> 3. Armeno-Kurdish (Kurdish written in Armenian alphabet):
>
> https://books.google.com/books?id=zywwYAAJ
>
> Added to these, another very useful Jewish translation of the Pentateuch:
> the Ferrara Bible
>
> https://www.larramendi.es/i18n/catalogo_imagenes/grupo.cmd?path=1001869
>
> Also, there is another Bible, in Basque, by Jean-Pierre Duvoisin:
>
> This is the facsimile version, by the Bibliothèque de France
>
>
> https://gallica.bnf.fr/ark:/12148/bpt6k96656209.r=bible%20saindua?rk=21459;2
>
> Here is its electronic version, made by Josu Landa Ijurko:
>
> https://klasikoak.armiarma.eus/idazlanak/D/DuvoisinBibleaI.htm
>
> https://klasikoak.armiarma.eus/idazlanak/D/DuvoisinBibleaII.htm
>
> https://klasikoak.armiarma.eus/idazlanak/D/DuvoisinBibleaIII.htm
>
>
> So, please consider adding these to the Library, as well.
>
> Thank you for your efforts, God bless them, always, as well as yourselves,
> and thank God, you've been sharing the Word with the whole world, making It
> available to us!
>
>
> God bless you, guys, and thank you so much for your efforts, more and more
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] When osis2mod reports NESTING errors?

[Greg Hellings]

It might help to see the bit of OSIS it is referencing, rather than poking
in the dark at possible answers to the implied question of what is wrong
with the OSIS file.

On Tue, Jun 13, 2023 at 11:13 AM Peter von Kaehne  wrote:

> I think irrespective of the different context the error lies in the USFM.
>
> Sent from my phone. Please forgive misspellings and weird “corrections”
>
> On 13 Jun 2023, at 12:26, David Haslam  wrote:
>
> 
> All very well, but my question arose from nesting errors arising in the
> context of the XML list element.
>
> It wasn’t a case like Peter just described, that touches on the underlying
> chapter and verse structure.
>
> David
>
> Sent from Proton Mail for iOS
>
>
> On Tue, Jun 13, 2023 at 12:06, Peter von Kaehne  > wrote:
>
> Nesting errors I have seen look like (pseudo code)
>
> 
> 
>
> Where the endID of the last verse of last chapter comes after the start is
> of the new chapter. It is a USFM error. It is too long that I did this but
> fixing the USFM makes this go away. I am not sure that u2o should fix it
> though recognising it would be nice of course.
>
> Peter
>
>
>
>
>
> Sent from my phone. Please forgive misspellings and weird “corrections”
>
> > On 11 Jun 2023, at 07:07, David Haslam  wrote:
> >
> > 
> > If osis2mod produces modules in which chapter and verse elements use the
> milestone forms, how is it possible that it can report NESTING errors when
> (eg) a verse eID milestone and the next verse sID milestone are generated
> somewhere within an XML list element?
> >
> > How can a milestone even do such a thing?
> >
> > Question prompted by recent issues in the GitHub repo for Adyeths script
> u2o.py that converts USFM to OSIS.
> > cf. It’s not something that he can comprehensively fix.
> >
> > Best regards,
> >
> > David
> >
> > Sent from Proton Mail for iOS
> > ___
> > sword-devel mailing list: sword-devel@crosswire.org
> > http://crosswire.org/mailman/listinfo/sword-devel
> > Instructions to unsubscribe/change your settings at above page
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Languages without a space between words

[Greg Hellings]

Yes, that looks like the type of thing. Although that is for Lucene (Java).
I don't know the status of CLucene's implementation of that nor of
Xapian's. But that would be the proper place for such processing to occur.
If those libraries do not have one, interested parties could submit one.
They could probably develop it inside of the SWORD library to be sure it's
doing what they want it to do (I believe those filters are designed to be
pluggable by the calling application) before submitting it to those
projects for inclusion.

--Greg

On Mon, Apr 17, 2023 at 1:12 PM David Haslam  wrote:

> Thanks, Greg.
>
> I just came across this
>
>
> https://lucene.apache.org/core/3_2_0/api/contrib-analyzers/org/apache/lucene/analysis/th/ThaiWordFilter.html
>
> Is that the kind of thing you were thinking of?
>
> David
>
> Sent from Proton Mail for iOS
>
>
> On Mon, Apr 17, 2023 at 17:51, Greg Hellings  > wrote:
>
> I don't believe you're going to get that sort of feature directly in the
> engine's simple search.
>
> However, if you're using a build of the library that utilizes CLucene or
> Xapian, then that should be the function of those libraries. They are
> supposed to be able to handle all of that type of functionality if the
> language has a corresponding contribution to that library. It might be
> better to check in with them.
>
> --Greg
>
> On Mon, Apr 17, 2023 at 11:46 AM David Haslam 
> wrote:
>
>> Unlike Hebrew and Arabic, etc, none of the names of the Thai Unicode 
>> characters
>> contain the word FINAL. Likewise for Myanmar letters.
>>
>> A possible way forward might be to run one of the several Word
>> Segmentation programs on the text of the ThaiKJV.
>>
>> Examples: KuCut, DeepCut, AttaCut
>>
>> This should insert a Unicode zero width non-joiner (ZWNJ) as a word
>> separator.
>>
>> NB. The module would have to be updated using the segmented source text.
>>
>> Visually, the resulting text would display the same as the original, but
>> the module would be amenable to indexing for word searches.
>>
>> A difficulty that might then arise is how the front-end user might enter
>> the search query for an exact phrase search type (containing more than one
>> word). Other search types (all words, any word) might be OK as is.
>>
>> Aside: The KuCut method developed in 2004 was originally trained using
>> the text of the ThaKJV.
>>
>> Regards,
>>
>> David
>>
>> Sent from Proton Mail for iOS
>>
>>
>> On Mon, Apr 17, 2023 at 17:16, Peter Von Kaehne > > wrote:
>>
>> Does Thai Burmese etc etc use end forms for letters? if so, are these
>> encoded as such?
>> Peter
>> *Gesendet:* Montag, 17. April 2023 um 16:47 Uhr
>> *Von:* "David Haslam" 
>> *An:* sword-devel@crosswire.org
>> *Betreff:* [sword-devel] Languages without a space between words
>> How (if at all) does the SWORD API generate a search index for a module
>> that is for a language without a space between words?
>>
>> Please consider how best to generate a useful search index for modules that 
>> are
>> for Bible translations in languages that have no spaces between words.
>>
>> Example: CrossWire module ThaiKJV
>>
>> Seehttps://en.wikipedia.org/wiki/Category:Writing_systems_without_word_boundaries
>>
>> Has this ever been considered before.
>>
>> Best regards,
>> David
>> Sent from Proton Mail for iOS
>> ___ sword-devel mailing list:
>> sword-devel@crosswire.org
>> http://crosswire.org/mailman/listinfo/sword-devel Instructions to
>> unsubscribe/change your settings at above page
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Languages without a space between words

[Greg Hellings]

I don't believe you're going to get that sort of feature directly in the
engine's simple search.

However, if you're using a build of the library that utilizes CLucene or
Xapian, then that should be the function of those libraries. They are
supposed to be able to handle all of that type of functionality if the
language has a corresponding contribution to that library. It might be
better to check in with them.

--Greg

On Mon, Apr 17, 2023 at 11:46 AM David Haslam  wrote:

> Unlike Hebrew and Arabic, etc, none of the names of the Thai Unicode 
> characters
> contain the word FINAL. Likewise for Myanmar letters.
>
> A possible way forward might be to run one of the several Word
> Segmentation programs on the text of the ThaiKJV.
>
> Examples: KuCut, DeepCut, AttaCut
>
> This should insert a Unicode zero width non-joiner (ZWNJ) as a word
> separator.
>
> NB. The module would have to be updated using the segmented source text.
>
> Visually, the resulting text would display the same as the original, but
> the module would be amenable to indexing for word searches.
>
> A difficulty that might then arise is how the front-end user might enter
> the search query for an exact phrase search type (containing more than one
> word). Other search types (all words, any word) might be OK as is.
>
> Aside: The KuCut method developed in 2004 was originally trained using the
> text of the ThaKJV.
>
> Regards,
>
> David
>
> Sent from Proton Mail for iOS
>
>
> On Mon, Apr 17, 2023 at 17:16, Peter Von Kaehne  > wrote:
>
> Does Thai Burmese etc etc use end forms for letters? if so, are these
> encoded as such?
>
> Peter
>
>
> *Gesendet:* Montag, 17. April 2023 um 16:47 Uhr
> *Von:* "David Haslam" 
> *An:* sword-devel@crosswire.org
> *Betreff:* [sword-devel] Languages without a space between words
> How (if at all) does the SWORD API generate a search index for a module
> that is for a language without a space between words?
>
> Please consider how best to generate a useful search index for modules that 
> are
> for Bible translations in languages that have no spaces between words.
>
> Example: CrossWire module ThaiKJV
>
> Seehttps://en.wikipedia.org/wiki/Category:Writing_systems_without_word_boundaries
>
> Has this ever been considered before.
>
> Best regards,
>
> David
>
> Sent from Proton Mail for iOS
> ___ sword-devel mailing list:
> sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel Instructions to
> unsubscribe/change your settings at above page
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] PHP SWIG Bindings and Extension Development

[Greg Hellings]

The language contribution for it just not have needed it, and no one has
bothered to add it since.

--Greg

On Thu, Apr 13, 2023, 06:49 Patrick Stephan  wrote:

> Do you have any idea why?
>
> - Patrick
> On Apr 13, 2023 at 6:40 AM -0500, Greg Hellings ,
> wrote:
>
> Without the missing std_list.i file, it won't. If they've added that into
> their head, then you'll be golden. But it has been missing since the days
> of PHP4.
>
> --Greg
>
> On Thu, Apr 13, 2023, 06:12 Patrick Stephan 
> wrote:
>
>> Something I discovered last night is that swig installed from apt-get
>> (which I am doing) is at version 4.0, which supports up to php 7.4.
>> Tonight, I will attempt to build swig from source, which supports php 8.
>> I’m crossing my fingers that that helps.
>>
>> - Patrick
>> On Apr 13, 2023 at 6:05 AM -0500, Greg Hellings ,
>> wrote:
>>
>> Patrick,
>>
>> It has been a long time since I touched the PHP bonding build process.
>> But the basic shortcoming you are encouraging is that Swig lacks support
>> for converting a list from C++ into PHP.
>>
>> This isn't because PHP has no list, but because Swig bindings for PHP
>> never got it added, at least not with the filename the other languages have.
>>
>> You will need to either go to the upstream Swig project and submit that
>> feature, or write one and bundle it just for the PHP bindings directly in
>> Sword. It's also possible the feature or include file is just different in
>> PHP from Python and Perl, so if you discover that, then you could update
>> our bindings to include the proper file. Obviously, in the spirit of FOSS
>> collaboration, doing engagements directly in Swig would be preferred. Until
>> then, PHP bindings will be unavailable unless you develop some other
>> workaround to missing lists.
>>
>> --Greg
>>
>> On Wed, Apr 12, 2023, 23:06 Patrick Stephan 
>> wrote:
>>
>>> Alright... So I've gotten a little bit farther...
>>>
>>> I was missing the `libtoolize --force` command before autogen. After
>>> including that command and replacing the php4 references with php8 in the
>>> php.m4, Makefile.am, and Makefile.in, I no longer get the "No rule to make
>>> target 'phpswig'. Stop." error.
>>>
>>> When I run the `make phpswig` command, this is what I get:
>>> ```
>>> mkdir -p php
>>> /usr/bin/swig -php -c++ -o php/Sword.cxx -I. -I/usr/include/sword
>>> ./sword.i
>>> templates.i:3: Error: Unable to find 'std_list.i'
>>> make: *** [Makefile:972: phpswig] Error 1
>>> ```
>>>
>>> That `std_list.i` file appears to be a swig file that is in its python
>>> and perl files, but not in its php files. I imagine that is what is causing
>>> this error. Does anyone know how to overcome this?
>>>
>>> - Patrick
>>> On Apr 12, 2023 at 1:50 AM -0500, Peter von Kaehne ,
>>> wrote:
>>>
>>> I am not on my computer and speak from old memory but there is a
>>> two-step for Perl so I guess that may be for php too .
>>>
>>>
>>>
>>> Sent from my phone. Please forgive misspellings and weird “corrections”
>>>
>>> On 12 Apr 2023, at 06:46, Patrick Stephan 
>>> wrote:
>>>
>>> 
>>> Hello!
>>>
>>> First off, I want to thank everyone for their work in this project. It's
>>> an incredible work to make God's word more readily available.
>>>
>>> As the subject of the email suggests, I am trying to interface with the
>>> sword library with PHP. I am attempting to use the SWIG bindings provided,
>>> but there are no current PHP bindings provided. There does appear to be
>>> some older PHP 4 (PHP 8 is the current major version available) references
>>> in the Makefiles and configure file in `bindings/swig/package/` and a
>>> php4.m4 file. Attempting to run `make phpswig` (when you might run `make
>>> perlswig` according to the readme file in the swig directory) returns a "No
>>> rule to make target 'phpswig'. Stop." error. I have made some attempts to
>>> replace `php4` with `php8`, but that changes nothing. Anyway, I am
>>> attempting to create (or revive) PHP bindings for the sword library and
>>> would love some direction on where/how to get started. I have practically
>>> no experience with c/c++ or make files or swig, but if someone could give
>>> me a

Re: [sword-devel] PHP SWIG Bindings and Extension Development

[Greg Hellings]

Without the missing std_list.i file, it won't. If they've added that into
their head, then you'll be golden. But it has been missing since the days
of PHP4.

--Greg

On Thu, Apr 13, 2023, 06:12 Patrick Stephan  wrote:

> Something I discovered last night is that swig installed from apt-get
> (which I am doing) is at version 4.0, which supports up to php 7.4.
> Tonight, I will attempt to build swig from source, which supports php 8.
> I’m crossing my fingers that that helps.
>
> - Patrick
> On Apr 13, 2023 at 6:05 AM -0500, Greg Hellings ,
> wrote:
>
> Patrick,
>
> It has been a long time since I touched the PHP bonding build process. But
> the basic shortcoming you are encouraging is that Swig lacks support for
> converting a list from C++ into PHP.
>
> This isn't because PHP has no list, but because Swig bindings for PHP
> never got it added, at least not with the filename the other languages have.
>
> You will need to either go to the upstream Swig project and submit that
> feature, or write one and bundle it just for the PHP bindings directly in
> Sword. It's also possible the feature or include file is just different in
> PHP from Python and Perl, so if you discover that, then you could update
> our bindings to include the proper file. Obviously, in the spirit of FOSS
> collaboration, doing engagements directly in Swig would be preferred. Until
> then, PHP bindings will be unavailable unless you develop some other
> workaround to missing lists.
>
> --Greg
>
> On Wed, Apr 12, 2023, 23:06 Patrick Stephan 
> wrote:
>
>> Alright... So I've gotten a little bit farther...
>>
>> I was missing the `libtoolize --force` command before autogen. After
>> including that command and replacing the php4 references with php8 in the
>> php.m4, Makefile.am, and Makefile.in, I no longer get the "No rule to make
>> target 'phpswig'. Stop." error.
>>
>> When I run the `make phpswig` command, this is what I get:
>> ```
>> mkdir -p php
>> /usr/bin/swig -php -c++ -o php/Sword.cxx -I. -I/usr/include/sword
>> ./sword.i
>> templates.i:3: Error: Unable to find 'std_list.i'
>> make: *** [Makefile:972: phpswig] Error 1
>> ```
>>
>> That `std_list.i` file appears to be a swig file that is in its python
>> and perl files, but not in its php files. I imagine that is what is causing
>> this error. Does anyone know how to overcome this?
>>
>> - Patrick
>> On Apr 12, 2023 at 1:50 AM -0500, Peter von Kaehne ,
>> wrote:
>>
>> I am not on my computer and speak from old memory but there is a two-step
>> for Perl so I guess that may be for php too .
>>
>>
>>
>> Sent from my phone. Please forgive misspellings and weird “corrections”
>>
>> On 12 Apr 2023, at 06:46, Patrick Stephan  wrote:
>>
>> 
>> Hello!
>>
>> First off, I want to thank everyone for their work in this project. It's
>> an incredible work to make God's word more readily available.
>>
>> As the subject of the email suggests, I am trying to interface with the
>> sword library with PHP. I am attempting to use the SWIG bindings provided,
>> but there are no current PHP bindings provided. There does appear to be
>> some older PHP 4 (PHP 8 is the current major version available) references
>> in the Makefiles and configure file in `bindings/swig/package/` and a
>> php4.m4 file. Attempting to run `make phpswig` (when you might run `make
>> perlswig` according to the readme file in the swig directory) returns a "No
>> rule to make target 'phpswig'. Stop." error. I have made some attempts to
>> replace `php4` with `php8`, but that changes nothing. Anyway, I am
>> attempting to create (or revive) PHP bindings for the sword library and
>> would love some direction on where/how to get started. I have practically
>> no experience with c/c++ or make files or swig, but if someone could give
>> me a shove in the right direction, I think I can figure it out.
>>
>> Thank you everyone!
>>
>> - Patrick
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>>
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>> ___
>> swo

Re: [sword-devel] PHP SWIG Bindings and Extension Development

[Greg Hellings]

Patrick,

It has been a long time since I touched the PHP bonding build process. But
the basic shortcoming you are encouraging is that Swig lacks support for
converting a list from C++ into PHP.

This isn't because PHP has no list, but because Swig bindings for PHP never
got it added, at least not with the filename the other languages have.

You will need to either go to the upstream Swig project and submit that
feature, or write one and bundle it just for the PHP bindings directly in
Sword. It's also possible the feature or include file is just different in
PHP from Python and Perl, so if you discover that, then you could update
our bindings to include the proper file. Obviously, in the spirit of FOSS
collaboration, doing engagements directly in Swig would be preferred. Until
then, PHP bindings will be unavailable unless you develop some other
workaround to missing lists.

--Greg

On Wed, Apr 12, 2023, 23:06 Patrick Stephan  wrote:

> Alright... So I've gotten a little bit farther...
>
> I was missing the `libtoolize --force` command before autogen. After
> including that command and replacing the php4 references with php8 in the
> php.m4, Makefile.am, and Makefile.in, I no longer get the "No rule to make
> target 'phpswig'. Stop." error.
>
> When I run the `make phpswig` command, this is what I get:
> ```
> mkdir -p php
> /usr/bin/swig -php -c++ -o php/Sword.cxx -I. -I/usr/include/sword ./sword.i
> templates.i:3: Error: Unable to find 'std_list.i'
> make: *** [Makefile:972: phpswig] Error 1
> ```
>
> That `std_list.i` file appears to be a swig file that is in its python and
> perl files, but not in its php files. I imagine that is what is causing
> this error. Does anyone know how to overcome this?
>
> - Patrick
> On Apr 12, 2023 at 1:50 AM -0500, Peter von Kaehne ,
> wrote:
>
> I am not on my computer and speak from old memory but there is a two-step
> for Perl so I guess that may be for php too .
>
>
>
> Sent from my phone. Please forgive misspellings and weird “corrections”
>
> On 12 Apr 2023, at 06:46, Patrick Stephan  wrote:
>
> 
> Hello!
>
> First off, I want to thank everyone for their work in this project. It's
> an incredible work to make God's word more readily available.
>
> As the subject of the email suggests, I am trying to interface with the
> sword library with PHP. I am attempting to use the SWIG bindings provided,
> but there are no current PHP bindings provided. There does appear to be
> some older PHP 4 (PHP 8 is the current major version available) references
> in the Makefiles and configure file in `bindings/swig/package/` and a
> php4.m4 file. Attempting to run `make phpswig` (when you might run `make
> perlswig` according to the readme file in the swig directory) returns a "No
> rule to make target 'phpswig'. Stop." error. I have made some attempts to
> replace `php4` with `php8`, but that changes nothing. Anyway, I am
> attempting to create (or revive) PHP bindings for the sword library and
> would love some direction on where/how to get started. I have practically
> no experience with c/c++ or make files or swig, but if someone could give
> me a shove in the right direction, I think I can figure it out.
>
> Thank you everyone!
>
> - Patrick
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] CrossWire and git

[Greg Hellings]

On Sat, Mar 18, 2023, 13:30 Fr Cyrille  wrote:

>
>
> Le 18/03/2023 à 15:57, Troy A. Griffitts a écrit :
>
> Guys who prefer GitLab, I am sorry. No university research project, no
> commercial job has ever asked me to use GitLab.
>
> The french wikipedia says about : The software is used by several large IT
> companies, including IBM, Sony, the Jülich Research Centre, NASA, Alibaba,
> Oracle, Invincea, O'Reilly Media, Leibniz Rechenzentrum, CERN4,5,6,
> European XFEL, the GNOME Foundation, Boeing, Autodata, SpaceX7 , Symbio and
> Altares...
>
> They have all asked me use GitHub. From a purely popular choice and to
> prevent all of us from having to create yet another account (I am sure most
> everyone already has a GitHub account) and learn yet another tool, can't we
> just settle on GitHub. Would it make anyone extremely unhappy? GitLab is
> not my preferred choice.
>
>
> I wouldn't be unhappy, but when I have a choice between open or
> proprietary software I always ask myself if the small inconvenience I would
> have to use open is worth it or not, if I have a surmountable inconvenience
> I favour the inconvenience. I don't know in our case, because I don't have
> the skills, and I trust you. However I wonder if for what we write as
> source code gitlab is not just enough?
> For the creation of an account, I think most of us already have an
> account, no?
>

Unfortunately, for Gitlab, the code owners feature is behind a paid
subscription. In that very important way it does not (freely) provide what
Troy needs to administrate the engine development. It works great for
modules because they are owned by a person and each in separate
repositories. This, Gitlab does not provide the features needed unless Troy
is willing to pay.

Another feature that Gitlab hides behind payment is multiple reviewers per
PR. I don't know if that's a hard requirement at this time, but it could be
if a proposed change touched multiple areas of the engine code.

Although I prefer to leverage the FOSS option where available, in this case
it comes down to Troy deciding whether it's worth the financial cost for
those features on Gitlab or working in GitHub where those are gratis. That
cost would come to $29 per user, per month. And then we lose the network
effect of allowing people to easily fork the repository and send a PR
unless he's paying for the SaaS version. There is a model for FOSS projects
to gain access to the premium features we need, if you apply and are
accepted. https://about.gitlab.com/solutions/open-source/projects/

--Greg

>
>
>
> On March 18, 2023 6:40:57 AM MST, Greg Hellings 
>  wrote:
>>
>>
>>
>> On Sat, Mar 18, 2023, 06:41 Peter von Kaehne  wrote:
>>
>>> GitLab vs GitLab
>>>
>>> [image: image3-1.png]
>>>
>>> GitLab vs GitHub: Top 10 Differences between GitHub and GitLab
>>> <https://intellipaat.com/blog/gitlab-vs-github-difference/>
>>> intellipaat.com
>>> <https://intellipaat.com/blog/gitlab-vs-github-difference/>
>>> <https://intellipaat.com/blog/gitlab-vs-github-difference/>
>>>
>>> There is plenty more but this gives a decent summary. GitLab allows
>>> private repos which I think are a really useful thing. I think it should
>>> also be easier to integrate our own GitLab stuff or move it if we want to
>>>
>>
>> This comparison is quite dated (for instance, GitHub definitely has CI/CD
>> integrated nowadays, and GitLab is by no means buggy and slow), but I also
>> would support GitLab over GitHub as our definitive location simply on the
>> principle of it being FOSS instead of closed source hosting.
>>
>> It does have an identical Code owners feature to GitHub with the same
>> syntax and location. I'm not sure if it's available in the self hosted/free
>> versions or if it is one of their premium features. I'm getting conflicting
>> information on that.
>>
>> It does support automatic mirroring, so it would be easy for us to self
>> host the official repository but still allow automated mirrors on GitHub
>> and the public GitLab for ease of contribution by others.
>>
>> --Greg
>>
>>
>>> We aren’t a democracy but as far as it goes - I welcome the move to Git
>>> so, so gladly and I vote for moving towards GitLab as there is more active
>>> development of us already
>>>
>>> Peter
>>>
>>> Sent from my phone. Please forgive misspellings and weird “corrections”
>>>
>>> On 18 Mar 2023, at 11:20, Matěj Cepl  wrote:
>>>
>>> On 2023-03-18, 09:55 GMT, Fr Cyrille wrote:
>>

Re: [sword-devel] CrossWire and git

[Greg Hellings]

>From an administration and uptime point of view, I'm in support of GitHub.
The only place I've used Gitlab is at Red Hat and only for internal
projects there. From a pragmatic standing I'm in full support of GitHub,
and with an existing Gitlab instance, we're already set if something comes
up in the future that forces us to reconsider.

--Greg

On Sat, Mar 18, 2023, 09:57 Troy A. Griffitts  wrote:

> Guys who prefer GitLab, I am sorry. No university research project, no
> commercial job has ever asked me to use GitLab. They have all asked me use
> GitHub. From a purely popular choice and to prevent all of us from having
> to create yet another account (I am sure most everyone already has a GitHub
> account) and learn yet another tool, can't we just settle on GitHub. Would
> it make anyone extremely unhappy? GitLab is not my preferred choice.
>
> On March 18, 2023 6:40:57 AM MST, Greg Hellings 
> wrote:
>>
>>
>>
>> On Sat, Mar 18, 2023, 06:41 Peter von Kaehne  wrote:
>>
>>> GitLab vs GitLab
>>>
>>> [image: image3-1.png]
>>>
>>> GitLab vs GitHub: Top 10 Differences between GitHub and GitLab
>>> <https://intellipaat.com/blog/gitlab-vs-github-difference/>
>>> intellipaat.com
>>> <https://intellipaat.com/blog/gitlab-vs-github-difference/>
>>> <https://intellipaat.com/blog/gitlab-vs-github-difference/>
>>>
>>> There is plenty more but this gives a decent summary. GitLab allows
>>> private repos which I think are a really useful thing. I think it should
>>> also be easier to integrate our own GitLab stuff or move it if we want to
>>>
>>
>> This comparison is quite dated (for instance, GitHub definitely has CI/CD
>> integrated nowadays, and GitLab is by no means buggy and slow), but I also
>> would support GitLab over GitHub as our definitive location simply on the
>> principle of it being FOSS instead of closed source hosting.
>>
>> It does have an identical Code owners feature to GitHub with the same
>> syntax and location. I'm not sure if it's available in the self hosted/free
>> versions or if it is one of their premium features. I'm getting conflicting
>> information on that.
>>
>> It does support automatic mirroring, so it would be easy for us to self
>> host the official repository but still allow automated mirrors on GitHub
>> and the public GitLab for ease of contribution by others.
>>
>> --Greg
>>
>>
>>> We aren’t a democracy but as far as it goes - I welcome the move to Git
>>> so, so gladly and I vote for moving towards GitLab as there is more active
>>> development of us already
>>>
>>> Peter
>>>
>>> Sent from my phone. Please forgive misspellings and weird “corrections”
>>>
>>> On 18 Mar 2023, at 11:20, Matěj Cepl  wrote:
>>>
>>> On 2023-03-18, 09:55 GMT, Fr Cyrille wrote:
>>>
>>> I am very happy with this progress in your thinking about git. I just
>>>
>>> reiterate my preference for gitlab, where as Peter has already pointed
>>>
>>> out we now have all our modules. It would be consistent to add the sword
>>>
>>> sources there as well.
>>>
>>> @David I don't particularly use github for my personal projects which
>>>
>>> are all under gitlab.
>>>
>>>
>>> +1
>>>
>>> Matěj
>>> --
>>> https://matej.ceplovi.cz/blog/, @mcepl@floss.social
>>> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
>>>
>>> Pain is inevitable, but misery is optional. We cannot avoid pain,
>>> but we can avoid joy.
>>>-- Tim Hansel
>>>
>>>
>>> ___
>>> sword-devel mailing list: sword-devel@crosswire.org
>>> http://crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>>
>>> ___
>>> sword-devel mailing list: sword-devel@crosswire.org
>>> http://crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>>
>> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] CrossWire and git

[Greg Hellings]

On Sat, Mar 18, 2023, 06:41 Peter von Kaehne  wrote:

> GitLab vs GitLab
>
> [image: image3-1.png]
>
> GitLab vs GitHub: Top 10 Differences between GitHub and GitLab
> 
> intellipaat.com
> 
> 
>
> There is plenty more but this gives a decent summary. GitLab allows
> private repos which I think are a really useful thing. I think it should
> also be easier to integrate our own GitLab stuff or move it if we want to
>

This comparison is quite dated (for instance, GitHub definitely has CI/CD
integrated nowadays, and GitLab is by no means buggy and slow), but I also
would support GitLab over GitHub as our definitive location simply on the
principle of it being FOSS instead of closed source hosting.

It does have an identical Code owners feature to GitHub with the same
syntax and location. I'm not sure if it's available in the self hosted/free
versions or if it is one of their premium features. I'm getting conflicting
information on that.

It does support automatic mirroring, so it would be easy for us to self
host the official repository but still allow automated mirrors on GitHub
and the public GitLab for ease of contribution by others.

--Greg


> We aren’t a democracy but as far as it goes - I welcome the move to Git
> so, so gladly and I vote for moving towards GitLab as there is more active
> development of us already
>
> Peter
>
> Sent from my phone. Please forgive misspellings and weird “corrections”
>
> On 18 Mar 2023, at 11:20, Matěj Cepl  wrote:
>
> On 2023-03-18, 09:55 GMT, Fr Cyrille wrote:
>
> I am very happy with this progress in your thinking about git. I just
>
> reiterate my preference for gitlab, where as Peter has already pointed
>
> out we now have all our modules. It would be consistent to add the sword
>
> sources there as well.
>
> @David I don't particularly use github for my personal projects which
>
> are all under gitlab.
>
>
> +1
>
> Matěj
> --
> https://matej.ceplovi.cz/blog/, @mcepl@floss.social
> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
>
> Pain is inevitable, but misery is optional. We cannot avoid pain,
> but we can avoid joy.
>-- Tim Hansel
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] CrossWire and git

[Greg Hellings]

Now I'm attaching a simplified version of the CODEOWNERS for just the sword
repository. I've combined the configure.ac, Makefile.am, and CMakeLists.txt
entries to single entries and I've sorted the entries alphabetically (I
think...) ignoring any leading "/" characters. I've also substituted
usernames for where I know them:

scribe -> scribe777
refdoc == refdoc
tbiggs -> Tee2
charcoal -> karlkleinpaste

The others mentioned I don't know an equivalent GitHub username for:
willthimbleby, mgruner, dglassey, jansorg, chrislit

I've also gone ahead and created the 3 teams that are mentioned in the
file, so users can be added to them as appropriate.

--Greg

On Fri, Mar 17, 2023 at 5:21 PM Greg Hellings 
wrote:

> I'm attaching a Python file that gives a basic go at parsing the access
> file into a GitHub CODEOWNERS file, along with the output I get from it.
> It's not flawless, but it does properly transform group names to
> "@crosswire/group-name". It also assumes users have the same username
> between Crosswire and GitHub. Obviously a search/replace can account for
> that where it proves false.
>
> There is obviously plenty of room to simplify this, as it assumes all
> files are anchored to the root of the repository, and that does not have to
> be the case for CODEOWNERS. (e.g. /CMakeLists.txt will only apply to the
> file in the root of the repository whereas CMakeLists.txt would apply to a
> file with that name anywhere in the repo) However, it _should_ get us 99%
> of the way there.
>
> Note that the CODEOWNERS_files.txt includes an output for every one of the
> repos mentioned in your access file that you'd need to copy and paste out.
> Feel free to modify the script I've attached and run it with
> `access-to-codeowners.py access` as the argument. It can take arbitrarily
> many inputs or can have the access file piped to it if you want to
> pre-process in some way (e.g. by something like `sed -e
> s/scribe/scribe777/g`).
>
> --Greg
>
> On Fri, Mar 17, 2023 at 4:59 PM Timmy  wrote:
>
>> I apologize, I notice some of the file was cut. What I sent gives the
>> idea. If it's helpful for me to send everything then I will do that.
>>
>>
>>
>> *--Timmy BraunCell: +501-615-4531*
>>
>>
>> On Fri, Mar 17, 2023 at 3:44 PM Timmy  wrote:
>>
>>> Also, if there's code that should not be available to the public it
>>> would have to be put in a separate private repository with access granted
>>> just to the person(s) or team(s) that should have access.
>>>
>>>
>>>
>>> *--Timmy BraunCell: +501-615-4531*
>>>
>>>
>>> On Fri, Mar 17, 2023 at 3:42 PM Timmy  wrote:
>>>
>>>> From my research and some help from ChatGPT, I think the below text
>>>> would be the replacement for the access file (for GitHub CODEOWNERS).
>>>>
>>>> Note that I've simplified the Makefile.am, configure.ac,
>>>> CMakeLists.txt files to one line. This means all files with that name would
>>>> be included (saying in case that's not the intention).
>>>>
>>>> The "Teams" sword-prelim, sword-cmake, sword-release, sword-make would
>>>> have to be created in the GitHub organization.
>>>>
>>>> A branch protection rule would have to be setup in GitHub for the
>>>> master branch which would require at least "Require a pull request before
>>>> merging" and "Require review from Code Owners". Admins would always have
>>>> access to merge PRs unless also checking "Do not allow bypassing the above
>>>> settings". In such a case no one would be able to merge to master without
>>>> PR.
>>>>
>>>> I don't claim to be "the expert" but take the info for what it's worth.
>>>>
>>>> # Specific access rules for refdoc
>>>> /trunk/man/ @refdoc
>>>> /trunk/src/modules/filters/ @refdoc
>>>> /trunk/include/teilatex.h @refdoc
>>>> /trunk/include/osislatex.h @refdoc
>>>> /trunk/include/gbflatex.h @refdoc
>>>> /trunk/include/thmllatex.h @refdoc
>>>> /trunk/src/mgr/markupfiltmgr.cpp @refdoc
>>>>
>>>> # Access rules for sword-prelim group
>>>> /trunk/locales.d/ @sword-prelim
>>>> /trunk/bindings/ @sword-prelim
>>>> /trunk/examples/ @sword-prelim
>>>> /trunk/utilities/ @sword-prelim
>>>> /trunk/tests/ @sword-prelim
>>>> /trunk/scripts/ @sword-prelim
>>>> /trunk/ChangeL

Re: [sword-devel] CrossWire and git

[Greg Hellings]

I'm attaching a Python file that gives a basic go at parsing the access
file into a GitHub CODEOWNERS file, along with the output I get from it.
It's not flawless, but it does properly transform group names to
"@crosswire/group-name". It also assumes users have the same username
between Crosswire and GitHub. Obviously a search/replace can account for
that where it proves false.

There is obviously plenty of room to simplify this, as it assumes all files
are anchored to the root of the repository, and that does not have to be
the case for CODEOWNERS. (e.g. /CMakeLists.txt will only apply to the file
in the root of the repository whereas CMakeLists.txt would apply to a file
with that name anywhere in the repo) However, it _should_ get us 99% of the
way there.

Note that the CODEOWNERS_files.txt includes an output for every one of the
repos mentioned in your access file that you'd need to copy and paste out.
Feel free to modify the script I've attached and run it with
`access-to-codeowners.py access` as the argument. It can take arbitrarily
many inputs or can have the access file piped to it if you want to
pre-process in some way (e.g. by something like `sed -e
s/scribe/scribe777/g`).

--Greg

On Fri, Mar 17, 2023 at 4:59 PM Timmy  wrote:

> I apologize, I notice some of the file was cut. What I sent gives the
> idea. If it's helpful for me to send everything then I will do that.
>
>
>
> *--Timmy BraunCell: +501-615-4531*
>
>
> On Fri, Mar 17, 2023 at 3:44 PM Timmy  wrote:
>
>> Also, if there's code that should not be available to the public it would
>> have to be put in a separate private repository with access granted just to
>> the person(s) or team(s) that should have access.
>>
>>
>>
>> *--Timmy BraunCell: +501-615-4531*
>>
>>
>> On Fri, Mar 17, 2023 at 3:42 PM Timmy  wrote:
>>
>>> From my research and some help from ChatGPT, I think the below text
>>> would be the replacement for the access file (for GitHub CODEOWNERS).
>>>
>>> Note that I've simplified the Makefile.am, configure.ac, CMakeLists.txt
>>> files to one line. This means all files with that name would be included
>>> (saying in case that's not the intention).
>>>
>>> The "Teams" sword-prelim, sword-cmake, sword-release, sword-make would
>>> have to be created in the GitHub organization.
>>>
>>> A branch protection rule would have to be setup in GitHub for the master
>>> branch which would require at least "Require a pull request before merging"
>>> and "Require review from Code Owners". Admins would always have access to
>>> merge PRs unless also checking "Do not allow bypassing the above settings".
>>> In such a case no one would be able to merge to master without PR.
>>>
>>> I don't claim to be "the expert" but take the info for what it's worth.
>>>
>>> # Specific access rules for refdoc
>>> /trunk/man/ @refdoc
>>> /trunk/src/modules/filters/ @refdoc
>>> /trunk/include/teilatex.h @refdoc
>>> /trunk/include/osislatex.h @refdoc
>>> /trunk/include/gbflatex.h @refdoc
>>> /trunk/include/thmllatex.h @refdoc
>>> /trunk/src/mgr/markupfiltmgr.cpp @refdoc
>>>
>>> # Access rules for sword-prelim group
>>> /trunk/locales.d/ @sword-prelim
>>> /trunk/bindings/ @sword-prelim
>>> /trunk/examples/ @sword-prelim
>>> /trunk/utilities/ @sword-prelim
>>> /trunk/tests/ @sword-prelim
>>> /trunk/scripts/ @sword-prelim
>>> /trunk/ChangeLog @sword-prelim
>>> /trunk/lib/vcppmake/ @sword-prelim
>>>
>>> # Access rules for sword-cmake group
>>> /trunk/cmake/ @sword-cmake
>>>
>>> # Access rules for sword-release group
>>> /branches/ @sword-release
>>> /tags/ @sword-release
>>>
>>> # Access rules for all files with the name Makefile.am
>>> **/Makefile.am @sword-make
>>>
>>> # Access rules for all files with the name configure.ac
>>> **/configure.ac @sword-make
>>>
>>> # Access rules for all files with the name CMakeLists.txt
>>> **/CMakeLists.txt @sword-cmake
>>>
>>>
>>>
>>> *--Timmy BraunCell: +501-615-4531*
>>>
>>>
>>> On Fri, Mar 17, 2023 at 2:40 PM Peter von Kaehne  wrote:
>>>
>>>> Just one suggestion - a huge amount of our module work happens already
>>>> on GitLab rather than GitHub. I think the reasons were to do with
>>>> unfriendly policy changes of GitHub - but I am not entirely sure anymore.

Re: [sword-devel] CrossWire and git

[Greg Hellings]

Current owners are myself, DM, Karl, and Doug Campos. I sent Troy an invite
to it.

--Greg

On Fri, Mar 17, 2023 at 3:09 PM Peter von Kaehne  wrote:

> I think I own the CrossWire organization though not sure anymore. I will
> look into it this weekend and approve you to the highest level if I can do
> so
>
> Sent from my phone. Please forgive misspellings and weird “corrections”
>
> On 17 Mar 2023, at 19:28, Greg Hellings  wrote:
>
> 
> Troy,
>
> I know we've discussed the merge issue in the past. In order to help point
> in the right direction, a couple of questions:
>
> Do you still envision self hosting the repository as you have SVN and
> using GitHub to mirror, or do you anticipate self hosting a repository that
> is just an insurance policy against GitHub becoming unfriendly in the
> future? Most popular self hosting Git supports both push and pull to GitHub
> repositories, but the one you anticipate being the source will determine
> the recommendations and conversion path.
>
> In the Git world, the feature you're looking at seems to be known as Code
> Owners. It's a relatively newer feature. Here is GitHub documentation about
> their implementation.
> Https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
>
> If you anticipate doing most of the work on a self hosted solution and
> pushing GitHub as the mirror, I can look for their technique.
>
> I'll look into the Crosswire organization on GitHub to see if I have admin
> rights there to address #1.
>
> --Greg
>
> On Fri, Mar 17, 2023, 14:09 Troy A. Griffitts 
> wrote:
>
>> I don't want this to turn into a debate.
>>
>> I agree, we need to move source control to git.
>>
>> I even mostly agree we should do most of our dev work on github for the
>> visibility to draw other developers.
>>
>> To move forward with this:
>>
>> 1) I would actually need access to the github 'crosswire' organization,
>> which I currently don't have.
>>
>> 2) I am happy to migrate our 27 repos there (yes, I was also surprised we
>> have 27, but even these old ones would be nice to have on github for
>> posterity).
>> 3) After #2, I would love for Github experts to help me find a solution
>> that effectively grant elevated access to individuals for merging PRs into
>> our master repository without my approval FOR CERTAIN PARTS OF THE REPO
>> they own or are trusted to approve.
>>
>> This #3 item had been the primary element holding us back from moving
>> from SVN to git.  If you are unaware, SVN has a very easy way to elevate
>> permissions for accounts for parts of the repository.  I don't want to have
>> to approve all changes!  I trust our pumpkin holders to care for their
>> parts of the repository.
>>
>> We've discussed, in the past, submodules for handle this, but they do not
>> handle this well.  e.g., I want to grant Greg Hellings full write access to
>> merge any PR which updates any of our cmake scripts in all folders
>> everywhere.  I don't know anything about cmake and Greg is an expert.  I
>> want him to be able to manage that build system without my oversight.  I
>> trust him.  I do not want to grant Greg merge access for code that has
>> anything to do with our C++ engine.  He might be a great C++ programmer,
>> but he hasn't expressed he wants that access or ever submitted C++ code for
>> me to review and merge myself, so I want to protect Greg from accidentally
>> merging in someone's PR which includes C++ engine code.
>>
>> In SVN this is easy.  Attached is our SVN access file.  Help me translate
>> this workflow to Github.  There must be some way to restrict merges based
>> on the merging user and files modified in the PR.  Or at least require a
>> review by certain users bases on the files modified in the PR.
>>
>> Help me :)
>>
>> Troy
>>
>>
>> On 3/17/23 11:24, Greg Hellings wrote:
>>
>> Indeed. It's not a principled stand that I'm refusing to get Subversion
>> going. It's simply that it's too much work that I haven't bothered and
>> don't foresee doing so anytime soon.
>>
>> And, with no setup to automatically test the scripts in all the
>> environments they must support, it's not likely others are willing to
>> commit this on my behalf.
>>
>> --Greg
>>
>> On Sun, Mar 12, 2023, 09:42 Peter von Kaehne  wrote:
>>
>>> I think you misunderstood Greg.
>>>
>>> There is a long campaig

Re: [sword-devel] CrossWire and git

[Greg Hellings]

Troy,

I know we've discussed the merge issue in the past. In order to help point
in the right direction, a couple of questions:

Do you still envision self hosting the repository as you have SVN and using
GitHub to mirror, or do you anticipate self hosting a repository that is
just an insurance policy against GitHub becoming unfriendly in the future?
Most popular self hosting Git supports both push and pull to GitHub
repositories, but the one you anticipate being the source will determine
the recommendations and conversion path.

In the Git world, the feature you're looking at seems to be known as Code
Owners. It's a relatively newer feature. Here is GitHub documentation about
their implementation.
Https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners

If you anticipate doing most of the work on a self hosted solution and
pushing GitHub as the mirror, I can look for their technique.

I'll look into the Crosswire organization on GitHub to see if I have admin
rights there to address #1.

--Greg

On Fri, Mar 17, 2023, 14:09 Troy A. Griffitts  wrote:

> I don't want this to turn into a debate.
>
> I agree, we need to move source control to git.
>
> I even mostly agree we should do most of our dev work on github for the
> visibility to draw other developers.
>
> To move forward with this:
>
> 1) I would actually need access to the github 'crosswire' organization,
> which I currently don't have.
>
> 2) I am happy to migrate our 27 repos there (yes, I was also surprised we
> have 27, but even these old ones would be nice to have on github for
> posterity).
> 3) After #2, I would love for Github experts to help me find a solution
> that effectively grant elevated access to individuals for merging PRs into
> our master repository without my approval FOR CERTAIN PARTS OF THE REPO
> they own or are trusted to approve.
>
> This #3 item had been the primary element holding us back from moving from
> SVN to git.  If you are unaware, SVN has a very easy way to elevate
> permissions for accounts for parts of the repository.  I don't want to have
> to approve all changes!  I trust our pumpkin holders to care for their
> parts of the repository.
>
> We've discussed, in the past, submodules for handle this, but they do not
> handle this well.  e.g., I want to grant Greg Hellings full write access to
> merge any PR which updates any of our cmake scripts in all folders
> everywhere.  I don't know anything about cmake and Greg is an expert.  I
> want him to be able to manage that build system without my oversight.  I
> trust him.  I do not want to grant Greg merge access for code that has
> anything to do with our C++ engine.  He might be a great C++ programmer,
> but he hasn't expressed he wants that access or ever submitted C++ code for
> me to review and merge myself, so I want to protect Greg from accidentally
> merging in someone's PR which includes C++ engine code.
>
> In SVN this is easy.  Attached is our SVN access file.  Help me translate
> this workflow to Github.  There must be some way to restrict merges based
> on the merging user and files modified in the PR.  Or at least require a
> review by certain users bases on the files modified in the PR.
>
> Help me :)
>
> Troy
>
>
> On 3/17/23 11:24, Greg Hellings wrote:
>
> Indeed. It's not a principled stand that I'm refusing to get Subversion
> going. It's simply that it's too much work that I haven't bothered and
> don't foresee doing so anytime soon.
>
> And, with no setup to automatically test the scripts in all the
> environments they must support, it's not likely others are willing to
> commit this on my behalf.
>
> --Greg
>
> On Sun, Mar 12, 2023, 09:42 Peter von Kaehne  wrote:
>
>> I think you misunderstood Greg.
>>
>> There is a long campaign and strong feeling to have the project on Git
>> but there is no agreement or movement to that. And it seems Greg is pausing
>> his contributions until that matter is resolved.
>>
>> Peter
>>
>> Sent from my phone. Please forgive misspellings and weird “corrections”
>>
>> On 12 Mar 2023, at 15:51, ZdPo Ster  wrote:
>>
>> 
>> I am sorry, but I did not get the point of your reply.
>> I do not use subversion - I use git-svn as proposed several months ago on
>> this forum. But current cmake configuration expects everybody to use
>> subversion, which is wrong.
>> These patches improve cmake build:
>>
>>-  that will work also with git-svn
>>- MSVC build
>>- fix depreciated
>>
>> AFAIK it should cause no 

Re: [sword-devel] Fwd: cmake patches

[Greg Hellings]

Indeed. It's not a principled stand that I'm refusing to get Subversion
going. It's simply that it's too much work that I haven't bothered and
don't foresee doing so anytime soon.

And, with no setup to automatically test the scripts in all the
environments they must support, it's not likely others are willing to
commit this on my behalf.

--Greg

On Sun, Mar 12, 2023, 09:42 Peter von Kaehne  wrote:

> I think you misunderstood Greg.
>
> There is a long campaign and strong feeling to have the project on Git but
> there is no agreement or movement to that. And it seems Greg is pausing his
> contributions until that matter is resolved.
>
> Peter
>
> Sent from my phone. Please forgive misspellings and weird “corrections”
>
> On 12 Mar 2023, at 15:51, ZdPo Ster  wrote:
>
> 
> I am sorry, but I did not get the point of your reply.
> I do not use subversion - I use git-svn as proposed several months ago on
> this forum. But current cmake configuration expects everybody to use
> subversion, which is wrong.
> These patches improve cmake build:
>
>-  that will work also with git-svn
>- MSVC build
>- fix depreciated
>
> AFAIK it should cause no harm for other combinations, just improve current
> state.
>
> Zdenko
>
> On Thu, 9 Mar 2023 at 23:18, Greg Hellings 
> wrote:
>
>> I've never bothered to get Subversion setup on my local machine.
>> Remembering the setup, plus my credentials, and how to use it is more labor
>> than I've been willing to spend on this effort. If, in the future, I
>> overcome that inertia then I'll happily test and apply this patch.
>>
>> --Greg
>>
>> On Sat, Feb 25, 2023 at 5:34 AM ZdPo Ster  wrote:
>>
>>> Any update on this (after 3.5 months)?
>>>
>>> Zdenko
>>>
>>> On Sat, 26 Nov 2022 at 21:53, Greg Hellings 
>>> wrote:
>>>
>>>> Thanks. I am not privy to the patches email inbox, so this mailing list
>>>> is the way to reach me for CMake things. I'll review these when I have the
>>>> opportunity.
>>>>
>>>> --Greg
>>>>
>>>> On Sat, Nov 26, 2022, 13:46 Peter von Kaehne  wrote:
>>>>
>>>>>
>>>>> How to suggest improvements to the sword project?
>>>>>
>>>>>
>>>>>
>>>>> You did it the right way. It just is a bit on/off as a project.
>>>>> GHellings is the cmake pumpkin holder as far as I know. I bcc him on a
>>>>> different email address.
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>>>
>>>>> BR,
>>>>>
>>>>> Zdenko
>>>>>
>>>>> -- Forwarded message -
>>>>> From: ZdPo Ster 
>>>>> Date: Sun, 6 Nov 2022 at 22:22
>>>>> Subject: cmake patches
>>>>> To: 
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> please find 3 few patches related to cmake build (tested on windows
>>>>> with MSVC 2019):
>>>>>
>>>>>1. cmake_fix_deprecation.patch - cmake version 3.23.2 produce
>>>>>depreciation warning for old minimum version, co IMO it is time to 
>>>>> increase
>>>>>expected cmake version
>>>>>2. cmake_fix_msvc.patch - there is no "/O3" options in current
>>>>>MSVC[1]
>>>>>3. cmake_git_svn.patch - I use git svn for accessing code, but
>>>>>cmake produce error because of missing svn executable. He is patch that
>>>>>fixed it + code for detecting svn revision (MYSVN_WC_REVISION) from git
>>>>>
>>>>> [1]
>>>>> https://learn.microsoft.com/en-us/cpp/build/reference/o-options-optimize-code?view=msvc-160
>>>>>
>>>>> Zdenko
>>>>>
>>>>> ___
>>>>> sword-devel mailing list: sword-devel@crosswire.org
>>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>>> Instructions to unsubscribe/change your settings at above page
>>>>>
>>>>> ___
>>>> sword-devel mailing list: sword-devel@crosswire.org
>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>> Instructions to unsubscribe/change your settings at above page
>>>>
>>> ___
>>> sword-devel mailing list: sword-devel@crosswire.org
>>> http://crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>>
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Fwd: cmake patches

[Greg Hellings]

I've never bothered to get Subversion setup on my local machine.
Remembering the setup, plus my credentials, and how to use it is more labor
than I've been willing to spend on this effort. If, in the future, I
overcome that inertia then I'll happily test and apply this patch.

--Greg

On Sat, Feb 25, 2023 at 5:34 AM ZdPo Ster  wrote:

> Any update on this (after 3.5 months)?
>
> Zdenko
>
> On Sat, 26 Nov 2022 at 21:53, Greg Hellings 
> wrote:
>
>> Thanks. I am not privy to the patches email inbox, so this mailing list
>> is the way to reach me for CMake things. I'll review these when I have the
>> opportunity.
>>
>> --Greg
>>
>> On Sat, Nov 26, 2022, 13:46 Peter von Kaehne  wrote:
>>
>>>
>>> How to suggest improvements to the sword project?
>>>
>>>
>>>
>>> You did it the right way. It just is a bit on/off as a project.
>>> GHellings is the cmake pumpkin holder as far as I know. I bcc him on a
>>> different email address.
>>>
>>> Peter
>>>
>>>
>>>
>>> BR,
>>>
>>> Zdenko
>>>
>>> -- Forwarded message -
>>> From: ZdPo Ster 
>>> Date: Sun, 6 Nov 2022 at 22:22
>>> Subject: cmake patches
>>> To: 
>>>
>>>
>>> Hello,
>>>
>>> please find 3 few patches related to cmake build (tested on windows with
>>> MSVC 2019):
>>>
>>>1. cmake_fix_deprecation.patch - cmake version 3.23.2 produce
>>>depreciation warning for old minimum version, co IMO it is time to 
>>> increase
>>>expected cmake version
>>>2. cmake_fix_msvc.patch - there is no "/O3" options in current
>>>MSVC[1]
>>>3. cmake_git_svn.patch - I use git svn for accessing code, but cmake
>>>produce error because of missing svn executable. He is patch that fixed 
>>> it
>>>+ code for detecting svn revision (MYSVN_WC_REVISION) from git
>>>
>>> [1]
>>> https://learn.microsoft.com/en-us/cpp/build/reference/o-options-optimize-code?view=msvc-160
>>>
>>> Zdenko
>>>
>>> ___
>>> sword-devel mailing list: sword-devel@crosswire.org
>>> http://crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>>
>>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Rendering issues with Finnish Umlauts in FinPR

[Greg Hellings]

Is Ezra properly setting encoding on the content it renders? Is it maybe
setting a font that doesn't have the proper code points?

--Greg

On Sat, Jan 21, 2023, 13:12 Tobias Klein  wrote:

> Hi Kristof, David,
>
> Adding Encoding=UTF-8 to the module conf file ~/.sword/mods.d/finpr.conf
> does not solve my issue.
>
> The text still looks the same as before ...
>
> What else could I do to further debug this?
>
> Best regards,
> Tobias
> On 1/21/23 5:18 PM, Kristof Szabo wrote:
>
> Hi Thomas,
>
> I suppose the problem is that finpr.conf contains no encoding information
> (check the Hun* modules for reference), and if there is nothing specified
> Latin-1 is the default. mod2osis (shouldn't be used !! :)) shows that the
> module is in UTF-8, so there is a misalignment.
>
>
> https://wiki.crosswire.org/DevTools:conf_Files#:~:text=Plaintext-,Encoding,-UTF%2D8%0AUTF
>
> Kind regards,
> Kristof
>
> On Sat, Jan 21, 2023 at 4:49 PM David Haslam 
> wrote:
>
>> Hi Thomas,
>>
>> What about other Finnish modules?
>> eg. FinPR92, FinRK, FinSTLK2017
>>
>> Presumably you already tested (eg) German modules and found that umlauts
>> and eszett are both rendered aright?
>>
>> Btw. FinPR renders aright in PocketSword (iOS/iPadOS).
>>
>> David
>>
>> Sent from Proton Mail for iOS
>>
>>
>> On Sat, Jan 21, 2023 at 15:25, Tobias Klein  wrote:
>>
>> Hi,
>>
>> When retrieving the text of the FinPR module I am getting some rendering
>> issues with the Finnish Umlauts. This is based on a user's problem report.
>>
>>
>> Romans 5:8 returns like this in node-sword-interface / Ezra:
>>
>> Mutta Jumala osoittaa rakkautensa meit� kohtaan siin�, ett� Kristus, kun
>> me viel� olimme syntisi�, kuoli meid�n edest�mme.
>>
>>
>> While it should like like this (rendered text copied from Xiphos):
>>
>> Mutta Jumala osoittaa rakkautensa meitä kohtaan siinä, että Kristus, kun
>> me vielä olimme syntisiä, kuoli meidän edestämme.
>>
>>
>> This occurs both on Linux and macOS (have not tested on Windows yet).
>>
>> Any pointers what could be the root cause? I generally have not observed
>> rendering issues with other modules.
>>
>>
>> Best regards,
>> Tobias
>>
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>
> ___
> sword-devel mailing list: 
> sword-devel@crosswire.orghttp://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Question regarding InstallMgr

[Greg Hellings]

I believe you will need to refresh that source before you call the install
method. It's trying to look up the config file for that module and isn't
finding it. Those get downloaded and cached by the Installmgr class when it
refreshes a source.

--Greg

On Thu, Dec 8, 2022, 14:51 P Mosier  wrote:

> Hello,
>
> I am trying to figure out what the appropriate steps to take are for
> programmatically installing a module through FTP.  Looking through the
> backend codebase, it seems like there are some configuration settings
> that have to be initialized in SWMgr order for InstallMgr::installModule
> to work.  However, tracking this down has eluded me as InstallMgr never
> seems to be set up and called the same way twice.
>
> I have this as a simple example:
>
>  sword::SWMgr swrd;
>  sword::InstallSource is("FTP");
>  is.source = "ftp.crosswire.org";
>  is.directory = "/pub/sword";
>
>  sword::InstallMgr im;
>  im.installModule(&swrd, 0, "KJVA", &is);
>
> The call to installModule segfaults at this line:
>
>  module = mgr.config->getSections().find(modName);
>
> I recognize it might be related to my own environment.  This is the
> entire content of my /etc/sword:
> [Install]
> DataPath=/usr/share/sword/
>
> Does someone have an idea for what I'm missing, or an example to direct
> me to so I can get a better handle on this area of code?
>
> Thanks,
> - Paul M
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Fwd: cmake patches

[Greg Hellings]

Thanks. I am not privy to the patches email inbox, so this mailing list is
the way to reach me for CMake things. I'll review these when I have the
opportunity.

--Greg

On Sat, Nov 26, 2022, 13:46 Peter von Kaehne  wrote:

>
> How to suggest improvements to the sword project?
>
>
>
> You did it the right way. It just is a bit on/off as a project. GHellings
> is the cmake pumpkin holder as far as I know. I bcc him on a different
> email address.
>
> Peter
>
>
>
> BR,
>
> Zdenko
>
> -- Forwarded message -
> From: ZdPo Ster 
> Date: Sun, 6 Nov 2022 at 22:22
> Subject: cmake patches
> To: 
>
>
> Hello,
>
> please find 3 few patches related to cmake build (tested on windows with
> MSVC 2019):
>
>1. cmake_fix_deprecation.patch - cmake version 3.23.2 produce
>depreciation warning for old minimum version, co IMO it is time to increase
>expected cmake version
>2. cmake_fix_msvc.patch - there is no "/O3" options in current MSVC[1]
>3. cmake_git_svn.patch - I use git svn for accessing code, but cmake
>produce error because of missing svn executable. He is patch that fixed it
>+ code for detecting svn revision (MYSVN_WC_REVISION) from git
>
> [1]
> https://learn.microsoft.com/en-us/cpp/build/reference/o-options-optimize-code?view=msvc-160
>
> Zdenko
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SWORD module installation bug

[Greg Hellings]

Troy,

Mine was with the version installed from Homebrew. It uses the 1.9.0
release tarball.
https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/sword.rb

--Greg

On Sat, Nov 12, 2022 at 9:14 AM Troy A. Griffitts 
wrote:

> Thank you Gred and Tobias for the reports.
>
> Has anyone seen this happen using svn trunk? I can write up some tests to
> add to our test suite but it would be helpful to know if either of you have
> seen this with the most recent version. It is useful to hear that it was
> happening on rev 3873. That rules out the cause being what I've updated
> since then.
>
> Happy weekend! Praise the Lord for weekends,
>
> Troy
>
> On November 12, 2022 7:13:54 AM MST, Greg Hellings <
> greg.helli...@gmail.com> wrote:
>>
>> Just this week I was trying to install a few modules on a new (Mac)
>> system. Install went off flawlessly according to the installmgr tool, but
>> nothing was actually installed until I manually created the mods.d and
>> modules directory under the ~/.sword folder. The tool manually created the
>> ~/.sword/InstallMgr folder, but not the target installation folders.
>>
>> Not sure if these are symptoms of the same bug or not.
>>
>> --Greg
>>
>> On Sat, Nov 12, 2022, 04:03 Tobias Klein  wrote:
>>
>>> Hi all,
>>>
>>> I have observed a bug with regard to SWORD module installation.
>>>
>>> I just tried to update existing modules by "installing them again" using
>>> InstallMgr::installModule().
>>>
>>> I ended up with a situation where the installation apparently finished
>>> ok based on return codes, but then I found the following:
>>>
>>> The *.conf files in the mods.d directory are still present, but the
>>> module contents under modules/texts/ztext are actually removed for the
>>> modules that I tried to update.
>>>
>>> Has anyone seen this behavior before? Is there an explanation?
>>>
>>> The modules are then still listed as installed, but there is no content
>>> ...
>>>
>>> I have seen this before at various times with individual modules, but
>>> did not report it. Now that I have this bug at a larger scale (for a
>>> bigger list of modules I tried to update) I felt like it's worth
>>> reporting.
>>>
>>> Best regards,
>>> Tobias
>>>
>>> PS: I have been using SWORD SVN Rev. 3873 (from Nov. 2021).
>>>
>>> ___
>>> sword-devel mailing list: sword-devel@crosswire.org
>>> http://crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>>
>> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SWORD module installation bug

[Greg Hellings]

Just this week I was trying to install a few modules on a new (Mac) system.
Install went off flawlessly according to the installmgr tool, but nothing
was actually installed until I manually created the mods.d and modules
directory under the ~/.sword folder. The tool manually created the
~/.sword/InstallMgr folder, but not the target installation folders.

Not sure if these are symptoms of the same bug or not.

--Greg

On Sat, Nov 12, 2022, 04:03 Tobias Klein  wrote:

> Hi all,
>
> I have observed a bug with regard to SWORD module installation.
>
> I just tried to update existing modules by "installing them again" using
> InstallMgr::installModule().
>
> I ended up with a situation where the installation apparently finished
> ok based on return codes, but then I found the following:
>
> The *.conf files in the mods.d directory are still present, but the
> module contents under modules/texts/ztext are actually removed for the
> modules that I tried to update.
>
> Has anyone seen this behavior before? Is there an explanation?
>
> The modules are then still listed as installed, but there is no content ...
>
> I have seen this before at various times with individual modules, but
> did not report it. Now that I have this bug at a larger scale (for a
> bigger list of modules I tried to update) I felt like it's worth reporting.
>
> Best regards,
> Tobias
>
> PS: I have been using SWORD SVN Rev. 3873 (from Nov. 2021).
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Possibility to install arbitrary module versions with InstallMgr

[Greg Hellings]

The biggest problem with that would seem to be that the server only keeps
the current version. It doesn't keep older versions in place (or, at least
it hasn't in the past)

--Greg

On Tue, Sep 27, 2022, 14:37 Tobias Klein  wrote:

> Hi Troy,
>
> As I am thinking about module upgrade support for Ezra Bible App
> (currently not implemented) I am also (once more) asking myself why
> there isn't an API for installing arbitrary module versions with
> InstallMgr.
>
> The two additional use cases that I would like to have in the SWORD
> engine are:
>
> - Add a function to list the module versions for a given module and a
> given repository
> - Add a version parameter to the installModule function
>
> Would it be much effort to implement this in SWORD?
>
> Are there any existing design constraints that make it hard to add this?
>
> Best regards,
> Tobias
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Ezra Bible App available for Android mobile now

[Greg Hellings]

On Sun, Aug 21, 2022, 15:15 Tobias Klein  wrote:

> On 8/21/22 7:42 PM, Greg Hellings wrote:
>
> - Built-in ability to sync database via Cloud storage (I am planning to
>>> start with Dropbox). This then supports the usecase of using the same
>>> database across multiple devices (Desktop, Tablet, Mobile).
>>>
>>
>> As someone who likes to self host with Synology, I would love to see
>> integration with that.
>>
>> You mean a NAS on the local network? What would be the interface to that?
>> Local http(s)?
>> Are there existing integrations for that with other apps?
>>
> Synology is a NAS appliance, yes. However, it comes with mobile apps (the
> main one of relevance here is called Drive) that simulate the behavior of
> Box, DropBox, etc apps for synching arbitrary files. On Android it appears
> in my list of places to open or save files to when I'm dealing with email
> attachments or social media uploads similar to the other apps mentioned.
>
> Ok. I would need to check this. The question is whether there is some kind
> of existing API to interface with this app ...
>
The app seems to hook directly into the Android file subsystem, so it
probably can work with a straight open/save dialog. I have used it with
KeePassXC successfully in the past this way.

Alternatively the NAS itself has an HTTP API you can access directly.
https://global.download.synology.com/download/Document/Software/DeveloperGuide/Package/FileStation/All/enu/Synology_File_Station_API_Guide.pdf

--Greg

>
> A few rough edges I noticed using it in service,  not related to the
> mobile bit specifically.
>
> Once I wrote a note for a verse, I had to cycle note visibility on and off
> again in the UI to hide them. It seems that entering the edit mode
> displayed them without toggling the menu item, I think? I'd have to play
> with it more to be certain that's what happened, but it seems that's what
> went on.
>
> Thanks. I'll look into this. I can confirm that the two features (on
> demand note editing vs. note editing turned on for all verses) are not
> properly synced.
>
> https://github.com/ezra-bible-app/ezra-bible-app/issues/733
>
>
> Also, not sure if this is the app or a module issue but I have both the
> NET module from eBible, KJVA from CrossWire, and a few other modules
> installed. NET is the primary display. When I select the first verse under
> any header and pull up the comparison pane to see other translations, all
> of them display text except for KJVA. The KJVA has text for the verse if I
> pull it up as the primary module, and it doesn't happen on other verses nor
> on other modules. I'm attaching a pair of screeneries to show what I mean.
>
> I'll look into this.
>
> https://github.com/ezra-bible-app/ezra-bible-app/issues/734
>
>
> Overall it is a very useful mobile app on tablet!
>
> Happy to hear that!
>
> Best regards,
> Tobias
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Ezra Bible App available for Android mobile now

[Greg Hellings]

Apparently my reply got snagged by the list for moderator approval because
of screenshots I added. But rest assured a reply is in the ether, waiting
to be released. 😂

--Greg

On Sun, Aug 21, 2022, 10:41 Tobias Klein  wrote:

> Thanks for the quick feedback, Greg :)
> On 8/21/22 5:10 PM, Greg Hellings wrote:
>
> While the resolution of my screen is unremarkable, on the tablet form
> factor the UI seems great. Very clean and usable. Someone the buttons are
> the smallest usable size, but the spacing between them means my taps are
> not mistaken for other buttons, and it's very usable for this screen.
>
> The tablet variant was already available previously :), but anyway thanks
> for trying this now!
>
> - Built-in ability to sync database via Cloud storage (I am planning to
>> start with Dropbox). This then supports the usecase of using the same
>> database across multiple devices (Desktop, Tablet, Mobile).
>>
>
> As someone who likes to self host with Synology, I would love to see
> integration with that.
>
> You mean a NAS on the local network? What would be the interface to that?
> Local http(s)?
> Are there existing integrations for that with other apps?
>
> - Ship the app with pre-packaged KJV for an easier start.
>>
>
> This would definitely be awesome. Or, like Xiphos on desktop, bring up the
> module manager on first boot to guide the user through installation. Even
> being familiar with Ezra it took me a moment to find the installer. Some
> sort of first run guide might be a good idea for the app, in general.
>
> Yes, I'll definitely consider these enhancements.
>
>
>
>> Feedback is very welcome!
>>
>
> I was bummed that it didn't discover the modules I had already installed
> through Bishop, but that was no great loss. I don't have anything custom
> installed through either one. Just a handful of basic Bible modules to use
> when I am at church. This is probably related to your post script statement
> below.
>
> Yes, I am currently not reading/writing other locations than the
> app-internal storage anymore with Android >= 11.
> Which Android version are you on? If this is not working with Android < 11
> than I may still be able to do something for the next release.
>
>
> I love Ezra's inline note editing. I would be curious about a way for me
> to back up that content before I go too far with using it.
>
> Yes, that is also related to the point about syncing the database.
>
> I am personally using an Android 10 tablet and there I don't have the
> /sdcard issue yet. So there I am using the "DropSync" app to sync a
> particular /sdcard folder with Dropbox. I manually changed the location of
> the database in the configuration of the app. This is quite neat because
> you can essentially switch back and forth between Desktop and Tablet and
> work with the same data.
>
>
> Overall, first five minute impression is that this is a solid app
> experience. And it arrived just in time to serve me at church this morning!
>
>
> Cool!
>
> Enjoy your Sunday afternoon!
>
> Best regards,
> Tobias
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Ezra Bible App available for Android mobile now

[Greg Hellings]

Tobias,

On Sun, Aug 21, 2022, 09:41 Tobias Klein  wrote:

> Dear all,
>
> Ezra Bible App (Version 1.7.0) is available for Android mobile now.
>

Installed it on my Galaxy S6 Lite tablet. Worked flawlessly.


> You can install it from the Play Store here:
> https://play.google.com/store/apps/details?id=net.ezrabibleapp.cordova
>
> This release does not contain any new functionality. It is just a
> port/optimization to smaller mobile resolutions.
>
> A detailed Change Log is available here:
> https://github.com/ezra-bible-app/ezra-bible-app/blob/master/CHANGELOG.md
>
> As this is the first published release for mobile, it is still a bit
> unpolished.
> Also, it will probably stay a bit of a compromise even in the long run -
> it is not easy to design an app that works on small resolutions vs.
> large resolutions equally well.
>

While the resolution of my screen is unremarkable, on the tablet form
factor the UI seems great. Very clean and usable. Someone the buttons are
the smallest usable size, but the spacing between them means my taps are
not mistaken for other buttons, and it's very usable for this screen.


> However, the major functionality of Ezra Bible App works and it is
> exactly the same codebase as for the desktop version. You can swipe
> left/right to switch chapters :)
>
> Here are some points that I'm considering for future versions:
>
> - Built-in ability to sync database via Cloud storage (I am planning to
> start with Dropbox). This then supports the usecase of using the same
> database across multiple devices (Desktop, Tablet, Mobile).
>

As someone who likes to self host with Synology, I would love to see
integration with that.

- More optimizations for mobile layout.

- Ship the app with pre-packaged KJV for an easier start.
>

This would definitely be awesome. Or, like Xiphos on desktop, bring up the
module manager on first boot to guide the user through installation. Even
being familiar with Ezra it took me a moment to find the installer. Some
sort of first run guide might be a good idea for the app, in general.


> Feedback is very welcome!
>

I was bummed that it didn't discover the modules I had already installed
through Bishop, but that was no great loss. I don't have anything custom
installed through either one. Just a handful of basic Bible modules to use
when I am at church. This is probably related to your post script statement
below. I love Ezra's inline note editing. I would be curious about a way
for me to back up that content before I go too far with using it.

Overall, first five minute impression is that this is a solid app
experience. And it arrived just in time to serve me at church this morning!

--Greg


> Best regards,
> Tobias
>
> PS: The app stops using external storage (/sdcard/**) starting with
> Android 11. It was too much trouble (I could somehow make it work, but
> when uninstalling and re-installing the app, it would not work until the
> next reboot ...).
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Bishop app usability issue

[Greg Hellings]

Brilliant! As a feature enhancement it would be great to click anywhere in
the verse, but this is definitely usable.

--Greg

On Sun, Aug 14, 2022, 12:15 Troy A. Griffitts  wrote:

> This is not obvious, but you can tap the blue verse number to select the
> verse and hopefully pull up the notes. Let me know if that doesn't work.
>
> On August 14, 2022 6:47:25 PM GMT+02:00, Greg Hellings <
> greg.helli...@gmail.com> wrote:
>>
>> Troy,
>>
>> I've been using Bishop on my Galaxy Tab. It is great on the tablet size
>> screen. However, as it gets towards the end of a chapter or while
>> displaying a shorter chapter, it becomes impossible to access module
>> footnotes for the latter parts of the passage.
>>
>> For instance, in this screenshot I cannot get the highlight to progress
>> beyond verse 1 as the whole passage displays in the top half of the screen.
>> It would be great if I could manually tap a verse to select it, in order to
>> see its footnotes.
>>
>> --Greg
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Ezra Bible App - Looking for Android Testers (Mobile)

[Greg Hellings]

I was able to build on my Pinephone Pro with no modifications from master,
using the Build.md. Huzzah! I'll work up a PR to send for dependencies on
Manjaro (the default distribution for PPP).

I'll also see about making it into a package for Manjaro so that there's a
solid mobile option.

--Greg

On Sat, May 14, 2022, 07:51 Tobias Klein  wrote:

> Somebody recently got Ezra Bible App working on Librem phone!
> See https://github.com/ezra-bible-app/ezra-bible-app/discussions/644
>
> The current code on the master branch is already optimized for phone
> screen sizes. But I have been only testing on Android plus on Desktop with
> the Chrome developer tools and emulated mobile resolutions.
>
> Best regards,
> Tobias
> On 5/14/22 2:13 PM, Greg Hellings wrote:
>
> I'm interested, but not for Android. My current phone is the Pinephone Pro
> from Pine64 and it runs mainline Linux with Gnome 42 Phosh. So a mobile
> experience and build is highly desirable!
>
> --Greg
>
> On Sat, May 14, 2022, 02:59 Tobias Klein  wrote:
>
>> Hi all,
>>
>> I am currently working on Ezra Bible App for mobile devices.
>>
>> It is the same app that is already available for tablets and bigger
>> screens (like Chromebooks or Android TV).
>>
>> If you would like to participate in a test I would need your Google
>> email address. As testers you will then get access to the test version
>> via Google Play Store.
>>
>> I would be glad if you could help me with this.
>>
>> Best regards,
>> Tobias
>>
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>
> ___
> sword-devel mailing list: 
> sword-devel@crosswire.orghttp://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Ezra Bible App - Looking for Android Testers (Mobile)

[Greg Hellings]

I'm interested, but not for Android. My current phone is the Pinephone Pro
from Pine64 and it runs mainline Linux with Gnome 42 Phosh. So a mobile
experience and build is highly desirable!

--Greg

On Sat, May 14, 2022, 02:59 Tobias Klein  wrote:

> Hi all,
>
> I am currently working on Ezra Bible App for mobile devices.
>
> It is the same app that is already available for tablets and bigger
> screens (like Chromebooks or Android TV).
>
> If you would like to participate in a test I would need your Google
> email address. As testers you will then get access to the test version
> via Google Play Store.
>
> I would be glad if you could help me with this.
>
> Best regards,
> Tobias
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

[sword-devel] WASM

[Greg Hellings]

I think there was a thread about WASM builds of the library. The changes
involved some CMake files. I seem to have misplaced the thread. Can someone
link it, or forward it to me so I can take a look at the patch? Thanks.

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Please support HTTPS repositories.

[Greg Hellings]

On Sat, Jan 15, 2022, 21:24 Michael Johnson  wrote:

> I thank God for you all who volunteer to work on the Sword Project.
>
> I have been upgrading and refining my server layout for eBible.org and a
> dozen other Bible sites. Keeping FTP going is becoming harder all of the
> time. Indeed, HTTP (not S) is getting harder, too. HTTPS is the
> future-resistant protocol to access a Sword repository. I think this is not
> a problem for currently updated Sword front ends using current back ends.
> However, the ancient FTP protocol is a terrible protocol to rely on because
> by default, there is no security to it at all for authentication or content
> protection. It is easy to abuse. All major browsers have now stopped
> supporting it. HTTP without TLS is likewise lacking, but at least it is
> mostly supported by major browsers and libraries. Google and Apple are
> nudging everyone to use HTTPS instead of HTTP. Of course, mainland China
> often blocks HTTPS traffic, trying to force traffic into the clear where it
> is easier to spy on and modify. It is a strange political environment,
> indeed.
>

Any build using the libcurl interfaces should support HTTPS without any
modifications necessary, provided libcurl was compiled with SSL/TLS
support. But I owe Troy an overdue response to our conversation back in
November wherein I test that to be sure.


> THEREFORE, the eBible.org Sword repository at https://eBible.org/sword/
> is the preferred repository to use for the modules I maintain.
>
> I try to keep http://eBible.org/sword/ (not https) working, but it is
> getting hard to test that, as most modern browsers "help" me to a more
> secure connection.
>

You should be able to use CURL on the command line to check. I believe it
won't follow Location header redirects by default (if it does, then there
is a command line switch to disable it), so you should be able to check
easily in an automated fashion using that.


> Anonymous FTP does not work on the main eBible.org (no ftp.) server. It
> does work most of the time on a separate machine named ftp.eBible.org.
> That machine is running a software configuration with a known bug that I
> don't yet know how to work around that causes it to go down at seemingly
> random times, usually when I'm asleep or out of my office.
>

It is a shame that FTP has gotten such a bad rap. Yes, it's plaintext but
there ARE times when encryption is unnecessary and just a burden. This is
one of those times.

--Greg

>
> Just FYI...
>
> --
> signature
>
> Aloha,
> */Michael Johnson/**
> 26 HIWALANI LOOP • MAKAWAO HI 96768-8747*• USA
> mljohnson.org  • eBible.org 
> • WorldEnglish.Bible  • PNG.Bible <
> https://PNG.Bible>
> Signal/Telegram/WhatsApp/Telephone: +1 808-333-6921
> Skype: kahunapule • Telegram/Twitter: @kahunapule • Facebook:
> fb.me/kahunapule 
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] ETS / IBR / SBL

[Greg Hellings]

We also enjoyed meeting you! My daughter was apprehensive about meeting a
stranger from the Internet, but afterwards she said you were "pretty
decent". That's high praise coming from her. I would definitely make
efforts to meet with larger groups for events. Have mobile device, will
travel!

--Greg


On Fri, Nov 19, 2021, 14:31 Troy A. Griffitts  wrote:

> Had a great time meeting up with Greg and his daughter after ETS in Fort
> Worth yesterday. We talked about life and tech and ways to improve SWORD
> module installation. It was thoroughly enjoyable! We really should find a
> way to restart annual SWORD-Meets.
>
> Troy
>
> On October 29, 2021 6:26:11 AM CDT, "Troy A. Griffitts" <
> scr...@crosswire.org> wrote:
>>
>> :) Great, Greg! Let me know if you would like to come the venue to meet
>> up, even if you don't attend any of the conferences. Would love to spend
>> some time together talking in person!
>>
>> On October 29, 2021 4:15:19 AM MST, Greg Hellings <
>> greg.helli...@gmail.com> wrote:
>>>
>>> I plan to still live in Texas next month, just south of DFW! Don't know
>>> that these are viable for me to attend this year, but I'm only about 45
>>> minutes from downtown Fort Worth.
>>>
>>> --Greg
>>>
>>> On Fri, Oct 29, 2021, 06:03 Troy A. Griffitts 
>>> wrote:
>>>
>>>> Anyone planning to visit Texas this year? I hope to be at each event.
>>>> Would love to meet if anyone else plans to attend or is in the area.
>>>>
>>>> https://www.etsjets.org/annual_meeting_overview
>>>> https://ibr-bbr.org/annual-meeting/annual-lecture
>>>> https://www.sbl-site.org/meetings/AnnualMeeting.aspx
>>>> --
>>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>>> ___
>>>> sword-devel mailing list: sword-devel@crosswire.org
>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>> Instructions to unsubscribe/change your settings at above page
>>>
>>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Mobile Linux UIs

[Greg Hellings]

Anbox and Waydroid are both possible on the Pine Phone, but Anbox
especially folks say is very slow because of the virtualization on the
hardware. Waydroid is better because it seems to use more of Container
space. In both cases people say the Pine Phone Pro is fantastic in
performance with them. But if I can get a native Linux app with a display
optimized for tiny screens it would be best.

Hmm, for some reason I thought Bible Time Mini had gotten folded into the
main line BT repo back in the day. Bummer. Wonder how tough it would be to
get it going with modern Sword and BT code.

--Greg



On Sun, Nov 7, 2021, 15:25 Timmy  wrote:

> I recently tried to run And Bible on anbox, but anbox is too old for
> current version of And Bible (it's actually webview that is too old and
> can't update it).
>
> With my searching I think I saw people running waydroid on pine phone.
> Waydroid has much more up-to-date Android versions available. But waydroid
> did not work with my computer graphics so I have not been able to try that
> yet.
>
> On Sun, Nov 7, 2021, 14:55 Michael H  wrote:
>
>> Bibletime mini is/was a separate initiative to make an android version
>> similar to bibletime.  As far as I know it's completely separate from
>> Bibletime and largely inactive. It shows available for Android 2.3, last
>> release was 5 years ago. but while the interface is designed for touch on
>> small screens, it doesn't have a linuxOS port... just most of the 2012
>> phoneOS options at the end of the first smartphone war (symbian, windows
>> mobile, etc.)
>>
>> Bibletime desktop has 3 or 4 rows of menus/toolbars at the top of the
>> screen. Some of them might be disabled, but then the app would be even less
>> touch friendly... same for the sidebar. It's built for a large screen
>> format with a mouse pointer. not a touch interface.
>>
>> Have you tried andbible via anbox?  (is it possible to compile andbible
>> to run in linux natively or as a java app in linux?)
>>
>> On Sun, Nov 7, 2021 at 2:30 PM Greg Hellings 
>> wrote:
>>
>>> For my phone I've been moving to my new Pine Phone. For those unaware,
>>> this is a cell phone that runs mainline Linux and most of the popular
>>> desktop distributions are available on it - Arch, Fedora, Ubuntu, Manjaro,
>>> and about a dozen others I don't recall off the top of my head. I'm
>>> personally driving mine with Fedora.
>>>
>>> Which of our apps have the ability to run in a mobile friendly UI but on
>>> desktop software stacks? The current Pine Phone is very slow (only quad Arm
>>> A53 cores at 1 GHz), so the full browser experience to bring up a Bible in
>>> the browser is like going back to 2015. If I could build one of our native
>>> apps, it would be grand. I think Bible Time has a mobile UI option, but I
>>> don't know if it is compatible with a desktop stack. Are there any others?
>>> Is anyone willing to help me get one built?
>>>
>>> --Greg
>>> ___
>>> sword-devel mailing list: sword-devel@crosswire.org
>>> http://crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

[sword-devel] Mobile Linux UIs

[Greg Hellings]

For my phone I've been moving to my new Pine Phone. For those unaware, this
is a cell phone that runs mainline Linux and most of the popular desktop
distributions are available on it - Arch, Fedora, Ubuntu, Manjaro, and
about a dozen others I don't recall off the top of my head. I'm personally
driving mine with Fedora.

Which of our apps have the ability to run in a mobile friendly UI but on
desktop software stacks? The current Pine Phone is very slow (only quad Arm
A53 cores at 1 GHz), so the full browser experience to bring up a Bible in
the browser is like going back to 2015. If I could build one of our native
apps, it would be grand. I think Bible Time has a mobile UI option, but I
don't know if it is compatible with a desktop stack. Are there any others?
Is anyone willing to help me get one built?

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] ETS / IBR / SBL

[Greg Hellings]

I plan to still live in Texas next month, just south of DFW! Don't know
that these are viable for me to attend this year, but I'm only about 45
minutes from downtown Fort Worth.

--Greg

On Fri, Oct 29, 2021, 06:03 Troy A. Griffitts  wrote:

> Anyone planning to visit Texas this year? I hope to be at each event.
> Would love to meet if anyone else plans to attend or is in the area.
>
> https://www.etsjets.org/annual_meeting_overview
> https://ibr-bbr.org/annual-meeting/annual-lecture
> https://www.sbl-site.org/meetings/AnnualMeeting.aspx
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Windows Development

[Greg Hellings]

Hi Jeff,

On Mon, Oct 4, 2021 at 5:25 PM Jeff Becker  wrote:

> Hello, everyone.
>
>
>
> Sorry for disappearing a few months ago without resolving the questions
> that I had. I have been taking care of issues in my personal life which I
> won’t go into here.
>
>
>
> I’ve had time to consider what I would do with the project that I have
> been working on and inquiring about here.  Seems I have a few options:
>
> 1)  Make the existing Win32 code work for what I’m doing;
>
The existing Win32 is good and complete. It can do everything you need from
a traditional Windows standpoint. It was recently improved with better
Unicode path support. I'm happy to help you work on building it, if you
have trouble. I do have a desktop, whence I'm writing you this message now,
that is running Windows 10. I know at least one of the BibleTime developers
also runs Windows to generate release builds on that platform.

> 2)  Convert what I have to the Linux platform and use what’s actually
> available and current in the SWORD Project;
>
This will be the path of least resistance from the SWORD side. I have no
knowledge into what else you're doing to know how it will affect that.

> 3)  Work to bring the work you all have done into the current Windows
> / .Net Framework environment;
>
This would be a good route. I don't believe anyone has done it, though we
do have active bindings for a large variety of other platforms already:
Python, Perl, JNI, , Objective-C. We do know
how to get bindings done, so you're welcome to take this path.

> 4)  Give up and go another route;
>
Happy hunting if this is your route!

>
>
> I’m leaning toward the third, but I don’t want to step on any toes. It
> will involve:
>
> · *Work out design issues* (such as .Net only or .Net as a
> wrapper, Azure compatibility)
>
I would suggest a wrapper. Rewrites of SWORD tend to never reach feature
completeness because there is OODLES of acknowledgement of corner cases in
Sword that it already handles.

> · *Create MS VC++ Project(s)* / Solution
>
This can be done, but you can also build off the CMake tooling that's
already in place if you would like to. There's already bits in there to
handle Python and Perl bindings being build from CMake, so it can probably
handle adding some .Net wrapping.

> · *Import code pages* (mostly .cpp and .h pages presumably)
>
> · *Work out build issues* for both *32 and 64 bit* platforms
>
The library currently handles both of these very smoothly across a large
number of architectures.

> · *Test* the results (beginning with my own existing projects)
>
> · *Share* the code, preferably using a method you all are used to
> using
>
The official SVN is where all the magic happens. Most of us are happy to
work in a git mirror while something matures and then eventually shine it
up to get it submitted to Troy for inclusion in the SVN.

> · *Maintain* the code (including changes to the main code base),
> possibly as a new branch of the existing code
>
Hopefully we can find a way to avoid a permanent branch. Other bindings
live in a bindings directory in the source tree and that is how they stay
up to date.

>
>
> I’m willing to take this on if it’s something that will be used by others
> and, hopefully, supported by others as well.
>
>
>
> I have to admit that my VC++ skills need improvement since I spend most of
> my time in C#.  But it’s a welcome chance to build my skill set. But, of
> course, any help would be greatly appreciated, especially in understanding
> both the current state and plans for the existing code base.
>
>
>
> Regarding the other options listed above:
>
> 1)  I have successfully accessed the sword.dll file from C#.  It
> required creating two separate wrapper classes and obtaining the mangled
> name using a utility provided with Visual Studio.  There are shortcomings
> to this approach including extensive coding and performance hits.  We can
> discuss those if a decision is made to move forward;
>
> 2)  I think I individually, we as contributors and potential
> contributors, as well as others who will come on later will all lose out
> without a viable, up-to-date interface for Windows VS development;
>
Prophecies of our doom have been often repeated, being aimed at everything
from our website (JSP-based) to our hosting (self-hosted SVN) to our
language (C and C++). I look forward to this not panning out, either.

> 3)  Bringing the code into current Windows, Visual Studio and .Net
> Framework development;
>
> 4)  I like what’s been accomplished in the SWORD Project and I want
> to both use it and contribute to it.
>

--Greg

>
>
> I look forward to hearing from you all, especially those who currently
> work in Windows development with this code.
>
>
>
> Jeff Becker
>
>
>
>
>
>
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-d

Re: [sword-devel] Windows Development

[Greg Hellings]

On Tue, Oct 5, 2021 at 4:26 PM John Dudeck  wrote:

> As a Sword content developer, but not a Sword software developer per se, I
> need to be able to do Sword content development on Windows. Not because I
> dislike Linux, but because I have created in-house Perl tools for a
> publishing team that uses Windows workstations and is not able or inclined
> to add Linux workstations for Sword content development, when everything
> else we do is on Windows. Mainly what we do is develop French content as a
> contractor for Logos, then also generate Sword modules from the Logos XML
> targeted for AndBible. (We also publish print and epub books).
>
> Theoretically I guess we could use WSL, but it would have to be easy to
> get it set up, and work seamlessly with our Windows-based workflow.
>

WSL is crazy easy and I highly suggest you use it. WSL2 is even better. I,
personally, run Fedora in there but it is side-loaded through a
custom-built script. Getting Ubuntu out of the Windows Store is silly
simple and you can leverage it from there. I don't know the state of Sword
packaging, but building from source in WSL is just as easy as it is on
full-fledged Linux.


>
> All that we need and want are the Windows command-line versions of the
> Sword tools, mostly just osis2mod.exe, tei2mod.exe and xml2gbs.exe, without
> having to whine and wait for somebody to generate them with each new tools
> revision. I don't have the time or desire to do the Win32 cross-builds on
> Linux. We don't care whether the exe's are built from C, C++, C#, Visual
> Basic, FORTRAN, Java, IBM360 Assembler, .Net Whatever™, or are 32 or 64
> bit. Just that they work on Windows, work correctly, and that bug fixes
> arrive in a timely manner.
>

These are automatically created on GitHub whenever I push a version tag
there. They've been available up there for quite some time, and anyone with
the ability to run the basic tools necessary can get them there.
https://github.com/devroles/mingw_sword_package

--Greg


>
> Thanks to all who have created Sword and the ongoing efforts to support
> and improve it for the Lord's glory!
>
> John Dudeck
>
>
> > Hello, everyone.
> >
> > Sorry for disappearing a few months ago without resolving the questions
> that I had. I have been
> > taking care of issues in my personal life which I won’t go into here.
> >
> > I’ve had time to consider what I would do with the project that I have
> been working on and
> > inquiring about here.  Seems I have a few options:
> > 1)  Make the existing Win32 code work for what I’m doing;
> > 2) Convert what I have to the Linux platform and use what’s actually
> available and current in
> > the SWORD Project;
> > 3) Work to bring the work you all have done into the current Windows
> / .Net Framework
> > environment;
> > 4)  Give up and go another route;
> >
> > I’m leaning toward the third, but I don’t want to step on any toes. It
> will involve:
> > ·Work out design issues (such as .Net only or .Net as a wrapper,
> Azure
> > compatibility)
> > ·Create MS VC++ Project(s) / Solution
> > ·Import code pages (mostly .cpp and .h pages presumably)
> > · Work out build issues for both 32 and 64 bit platforms
> > ·Test the results (beginning with my own existing projects)
> > ·Share the code, preferably using a method you all are used to
> using
> > ·Maintain the code (including changes to the main code base),
> possibly as a new
> > branch of the existing code
> >
> > I’m willing to take this on if it’s something that will be used by
> others and, hopefully, supported
> > by others as well.
> >
> > I have to admit that my VC++ skills need improvement since I spend most
> of my time in C#.  But
> > it’s a welcome chance to build my skill set. But, of course, any help
> would be greatly
> > appreciated, especially in understanding both the current state and
> plans for the existing code
> > base.
> >
> > Regarding the other options listed above:
> > 1) I have successfully accessed the sword.dll file from C#.  It
> required creating two separate
> > wrapper classes and obtaining the mangled name using a utility provided
> with Visual
> > Studio.  There are shortcomings to this approach including extensive
> coding and
> > performance hits.  We can discuss those if a decision is made to move
> forward;
> > 2) I think I individually, we as contributors and potential
> contributors, as well as others who
> > will come on later will all lose out without a viable, up-to-date
> interface for Windows VS
> > development;
> > 3) Bringing the code into current Windows, Visual Studio and .Net
> Framework development;
> > 4) I like what’s been accomplished in the SWORD Project and I want
> to both use it and
> > contribute to it.
> >
> > I look forward to hearing from you all, especially those who currently
> work in Windows
> > development with this code.
> >
> > Jeff Becker
>
> John Dudeck
> Programmer at Editions Cl

Re: [sword-devel] Xiphos / SWORD / F34

[Greg Hellings]

Hurray! Glad to know it worked out.

--Greg

On Thu, Jul 29, 2021 at 3:53 AM Troy A. Griffitts 
wrote:

> This morning I received my bright and shiny new SWORD and Xiphos updates
> from the F34 repos.  Thank you!
> On 7/19/21 5:50 PM, Greg Hellings wrote:
>
> Thanks!
>
> I've issued the rebuild commands for both Xiphos and BibleTime in Fedora
> and they've completed in F34. They should make their way into the
> updates-testing repositories in the next 24ish hours. After that they'll
> promote to the updates repo about 7 days later automatically (It can be
> faster with testing, but I rarely get feedback on the updates-testing
> results for these packages). Once they're in updates-testing, anyone can
> test out the install by passing the argument "--enablerepo updates-testing"
> to the DNF command.
>
> Xiphos update:
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-7c840c4245
> BibleTime update:
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-d44aac8e44
>
> --Greg
>
> On Wed, Jul 14, 2021 at 1:12 PM Troy A. Griffitts 
> wrote:
>
>> Congratulations and enjoy your honeymoon!
>>
>> On July 14, 2021 7:13:19 PM GMT+02:00, Greg Hellings <
>> greg.helli...@gmail.com> wrote:
>>>
>>> Yes, this is captured in a Bugzilla that was automatically filed last
>>> week by Fedora automation. I goofed up when I packaged the Sword 1.9.0RCs
>>> during the Fedora 34 beta cycle (I misnamed the RPM package so dnf sorted
>>> the RC as higher version than 1.9.0). I finally fixed that about a month
>>> ago, but the soname the linker used to build Xiphos was the beta version
>>> leading to the error you see. The Xiphos package is still looking for the
>>> RC.
>>>
>>> I couldn't make time to rebuild the Xiphos and Bible Time packages
>>> between sorting out the SWORD package and my wedding. All that needs done
>>> is for the two application packages to be rebuilt. If anyone else here is a
>>> Fedora packager, you can rebuild those against the 1.9.0 by just a revision
>>> bump. Otherwise I'll be home from my honeymoon and back to work on Monday
>>> where I can do the rebuild.
>>>
>>> I've only got my phone with me during this honeymoon month, so I can't
>>> do the fix myself until I'm home.
>>>
>>> --Greg
>>>
>>> On Wed, Jul 14, 2021, 01:20 Troy A. Griffitts 
>>> wrote:
>>>
>>>> Hey guys,
>>>>
>>>> I did an upgrade on my box last night from F33 -> F34 and only got one
>>>> error.  Anything we can do about this?
>>>>
>>>>
>>>>  Problem: package xiphos-4.2.1-9.fc34.x86_64 requires
>>>> libsword.so.1.8()(64bit), but none of the providers can be installed
>>>>   - cannot install both sword-1:1.9.0-7.fc34.x86_64 and
>>>> sword-1.9.0RC3-1.fc34.x86_64
>>>>   - cannot install the best update candidate for package
>>>> xiphos-4.2.1-9.fc34.x86_64
>>>>   - cannot install the best update candidate for package
>>>> sword-1.9.0RC3-1.fc34.x86_64
>>>>
>>>> 
>>>>  PackageArchitectureVersion
>>>> RepositorySize
>>>>
>>>> 
>>>> Skipping packages with conflicts:
>>>> (add '--best --allowerasing' to command line to force their upgrade):
>>>>  sword  x86_64  1:1.9.0-7.fc34
>>>> updates  692 k
>>>>
>>>> Transaction Summary
>>>>
>>>> 
>>>> Skip  1 Package
>>>>
>>>> ___
>>>> sword-devel mailing list: sword-devel@crosswire.org
>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>> Instructions to unsubscribe/change your settings at above page
>>>
>>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>
> ___
> sword-devel mailing list: 
> sword-devel@crosswire.orghttp://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Xiphos / SWORD / F34

[Greg Hellings]

Thanks!

I've issued the rebuild commands for both Xiphos and BibleTime in Fedora
and they've completed in F34. They should make their way into the
updates-testing repositories in the next 24ish hours. After that they'll
promote to the updates repo about 7 days later automatically (It can be
faster with testing, but I rarely get feedback on the updates-testing
results for these packages). Once they're in updates-testing, anyone can
test out the install by passing the argument "--enablerepo updates-testing"
to the DNF command.

Xiphos update:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-7c840c4245
BibleTime update:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-d44aac8e44

--Greg

On Wed, Jul 14, 2021 at 1:12 PM Troy A. Griffitts 
wrote:

> Congratulations and enjoy your honeymoon!
>
> On July 14, 2021 7:13:19 PM GMT+02:00, Greg Hellings <
> greg.helli...@gmail.com> wrote:
>>
>> Yes, this is captured in a Bugzilla that was automatically filed last
>> week by Fedora automation. I goofed up when I packaged the Sword 1.9.0RCs
>> during the Fedora 34 beta cycle (I misnamed the RPM package so dnf sorted
>> the RC as higher version than 1.9.0). I finally fixed that about a month
>> ago, but the soname the linker used to build Xiphos was the beta version
>> leading to the error you see. The Xiphos package is still looking for the
>> RC.
>>
>> I couldn't make time to rebuild the Xiphos and Bible Time packages
>> between sorting out the SWORD package and my wedding. All that needs done
>> is for the two application packages to be rebuilt. If anyone else here is a
>> Fedora packager, you can rebuild those against the 1.9.0 by just a revision
>> bump. Otherwise I'll be home from my honeymoon and back to work on Monday
>> where I can do the rebuild.
>>
>> I've only got my phone with me during this honeymoon month, so I can't do
>> the fix myself until I'm home.
>>
>> --Greg
>>
>> On Wed, Jul 14, 2021, 01:20 Troy A. Griffitts 
>> wrote:
>>
>>> Hey guys,
>>>
>>> I did an upgrade on my box last night from F33 -> F34 and only got one
>>> error.  Anything we can do about this?
>>>
>>>
>>>  Problem: package xiphos-4.2.1-9.fc34.x86_64 requires
>>> libsword.so.1.8()(64bit), but none of the providers can be installed
>>>   - cannot install both sword-1:1.9.0-7.fc34.x86_64 and
>>> sword-1.9.0RC3-1.fc34.x86_64
>>>   - cannot install the best update candidate for package
>>> xiphos-4.2.1-9.fc34.x86_64
>>>   - cannot install the best update candidate for package
>>> sword-1.9.0RC3-1.fc34.x86_64
>>>
>>> 
>>>  PackageArchitectureVersion
>>> RepositorySize
>>>
>>> 
>>> Skipping packages with conflicts:
>>> (add '--best --allowerasing' to command line to force their upgrade):
>>>  sword  x86_64  1:1.9.0-7.fc34
>>> updates  692 k
>>>
>>> Transaction Summary
>>>
>>> 
>>> Skip  1 Package
>>>
>>> ___
>>> sword-devel mailing list: sword-devel@crosswire.org
>>> http://crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Xiphos / SWORD / F34

[Greg Hellings]

Yes, this is captured in a Bugzilla that was automatically filed last week
by Fedora automation. I goofed up when I packaged the Sword 1.9.0RCs during
the Fedora 34 beta cycle (I misnamed the RPM package so dnf sorted the RC
as higher version than 1.9.0). I finally fixed that about a month ago, but
the soname the linker used to build Xiphos was the beta version leading to
the error you see. The Xiphos package is still looking for the RC.

I couldn't make time to rebuild the Xiphos and Bible Time packages between
sorting out the SWORD package and my wedding. All that needs done is for
the two application packages to be rebuilt. If anyone else here is a Fedora
packager, you can rebuild those against the 1.9.0 by just a revision bump.
Otherwise I'll be home from my honeymoon and back to work on Monday where I
can do the rebuild.

I've only got my phone with me during this honeymoon month, so I can't do
the fix myself until I'm home.

--Greg

On Wed, Jul 14, 2021, 01:20 Troy A. Griffitts  wrote:

> Hey guys,
>
> I did an upgrade on my box last night from F33 -> F34 and only got one
> error.  Anything we can do about this?
>
>
>  Problem: package xiphos-4.2.1-9.fc34.x86_64 requires
> libsword.so.1.8()(64bit), but none of the providers can be installed
>   - cannot install both sword-1:1.9.0-7.fc34.x86_64 and
> sword-1.9.0RC3-1.fc34.x86_64
>   - cannot install the best update candidate for package
> xiphos-4.2.1-9.fc34.x86_64
>   - cannot install the best update candidate for package
> sword-1.9.0RC3-1.fc34.x86_64
>
> 
>  PackageArchitectureVersion
> RepositorySize
>
> 
> Skipping packages with conflicts:
> (add '--best --allowerasing' to command line to force their upgrade):
>  sword  x86_64  1:1.9.0-7.fc34
> updates  692 k
>
> Transaction Summary
>
> 
> Skip  1 Package
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] #bibletime is now on irc.oftc.net

[Greg Hellings]

On Thu, May 20, 2021, 13:46 ref...@gmx.net  wrote:

> I think the problem will be to find something with similar longevity,
> simplicity and ease to IRC. Does this even exist?


That really depends on how we see "ease of use"? I find it ponderously
difficult to use IRC in my daily flow. Especially as I frequently rebuild
and reimage machines and need to either backup or reconfigure my client
config every time. A non technical user might find it hilariously difficult
to find us on Freenode or elsewhere.

If we're going to discuss moving, we should define what we want the
platform to be. Is it a place for users to find us? Then it should have
unauthenticated, web access. Is it a place for developers and admins to
congregate for high value communication? It should support notifications
and server side persistent messages. Do we also want it to support VOIP?
Video calls? Screen sharing?

Does it need to be self hosted? Does it need to be libre or is gratis
enough?

Before we decide on a tech, if we're making a change, then we should define
our wants and needs.

--Greg

>
>
> Peter
>
> Sent from my mobile. Please forgive shortness, typos and weird
> autocorrects.
>
>
>  Original Message 
> Subject: Re: [sword-devel] #bibletime is now on irc.oftc.net
> From: Greg Hellings
> To: SWORD Developers' Collaboration Forum
> CC:
>
>
>
>
> On Thu, May 20, 2021 at 12:04 PM Karl Kleinpaste 
> wrote:
>
>> On 5/20/21 12:55 PM, Greg Hellings wrote:
>>
>> Is this a time to consider a move to an alternative platform altogether?
>>
>>
>> I find Discord usable for several purposes. Is it possible to have
>> different names per Discord "server"?
>>
>
> Personally I only use it for one purpose (video games), but I'm on two
> channels. As for the different nicks... I *think* so? Not been using it
> much or for long.
>
> --Greg
>
>
>> I'm not going to do anything about the current  #xiphos for a bit just
>> yet.
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] #bibletime is now on irc.oftc.net

[Greg Hellings]

On Thu, May 20, 2021 at 12:04 PM Karl Kleinpaste 
wrote:

> On 5/20/21 12:55 PM, Greg Hellings wrote:
>
> Is this a time to consider a move to an alternative platform altogether?
>
>
> I find Discord usable for several purposes. Is it possible to have
> different names per Discord "server"?
>

Personally I only use it for one purpose (video games), but I'm on two
channels. As for the different nicks... I *think* so? Not been using it
much or for long.

--Greg


> I'm not going to do anything about the current  #xiphos for a bit just yet.
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] #bibletime is now on irc.oftc.net

[Greg Hellings]

Not to my knowledge. If much/most of the staff is moving to libera and,
from what I've heard, a number of the hardware backers are as well, I
imagine all of them are going to be unstable for a while until the new
owner spins up and trains replacement hardware and staff on Freenode.

Is this a time to consider a move to an alternative platform altogether?
Something like Matrix, which is FOSS, but supports modern uses such as
multiple user connections, server-side history, offline messages, plus
Video/VOIP for when we want to do another video chat like we did a few
weeks back. It also supports bridging to connect to IRC, so we don't have
to make a purely either/or decision.

--Greg

On Thu, May 20, 2021 at 10:47 AM Karl Kleinpaste 
wrote:

> Is there any reason to believe oftc.net (or any other) would be superior
> to libera.chat in quality/population/visibility/ease-of-use?
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] #bibletime is now on irc.oftc.net

[Greg Hellings]

All of the FOSS communities I'm connected to and listening in on through
work are moving to libera.chat, following the biggest section of the staff
from Freenode.

--Greg

On Wed, May 19, 2021 at 5:10 PM Karl Kleinpaste  wrote:

> First I saw mention of libera.chat in existing freenode #sword. Now I see
> ofte.net.
> I don't have an opinion about them because I know nothing of either.
>
> But could we gain some consensus *before* jumping overboard?
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SWORD license issues

[Greg Hellings]

I apologize, my eyes glaze over whenever licensing discussions come up.
Please work up whatever patch you think is appropriate and get Troy to
apply it.

--Greg

On Fri, May 14, 2021, 15:32 Bastian Germann 
wrote:

> Am 26.12.20 um 19:53 schrieb Troy A. Griffitts:
> >> Furthermore, some files in the cmake directory miss accompanying
> >> licenses. At least CMake's 3-clause BSD license, cmake/toolchains's
> >> 2-clause BSD license, and the Boost Software License have to be included
> >> in source distributions. The BSD license also applies to binary
> >> distributions but as that only affects the CMake build, there should not
> >> be any copies of those files ending up in the binaries.
> > Greg Hellings is the pumpkin holder for our CMake build system and trust
> > he will respond accordingly.
>
> Hi Troy and Greg,
>
> Half a year has passed without the licenses being added. This is a
> gentle reminder.
>
> Thanks,
> Bastian
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SWORD Virtual Coffee/Tea

[Greg Hellings]

I have Skype, Facebook Messenger, Zoom, and I think we still have Blue
jeans through work. At least we did at the beginning of the pandemic.

There is also Google Duo, which is free to use and I do leverage it
frequently.

Maybe now is also a good time to consider setting up a SWORD channel in one
of the free popular messaging systems not named IRC? Matrix, or Mumble, or
whatever the cool kids are using these days.

--Greg


On Fri, Apr 16, 2021, 19:52 Michael H  wrote:

> And you can use it through the web on a computer,  or on your phone via
> the app. That is, no app required for a computer... just a facebook acct.
>
> On Fri, Apr 16, 2021 at 7:49 PM Michael H  wrote:
>
>> Facebook messenger has a video meeting mode... it worked pretty well..
>> better than zoom in my opinion.
>>
>>
>> On Fri, Apr 16, 2021 at 7:38 PM Michael Johnson 
>> wrote:
>>
>>> I have Skype and Zoom. I haven't tried Bluejeans, and am too cheap to
>>> try it when there are good alternatives, unless someone else can pay and
>>> host the meeting. Skype is free and available for Linux, Mac, Windows, iOS,
>>> iPadOS, and Android. Zoom has a free version that is good for meetings up
>>> to 40 minutes, or longer if one person has a paid account (US$149.90/year)
>>> and is also very cross-platform.
>>>
>>> I recommend installing Skype, unless someone already has a paid Zoom
>>> account.
>>>
>>>
>>> On 4/16/21 10:58 AM, David Haslam wrote:
>>> > Would ZOOM be better for all ?
>>> >
>>> > I guess only 3 of us have BlueJeans installed.
>>> >
>>> > David
>>> >
>>> > Sent from ProtonMail for iOS
>>> >
>>> >
>>> > On Fri, Apr 16, 2021 at 21:53, ref...@gmx.net >> ref...@gmx.net>> wrote:
>>> >> Sorry, I don't have Skype.
>>> >>
>>> >> Sent from my mobile. Please forgive shortness, typos and weird
>>> autocorrects.
>>> >>
>>> >>
>>> >>  Original Message 
>>> >> Subject: Re: [sword-devel] SWORD Virtual Coffee/Tea
>>> >> From: Tobias Klein
>>> >> To: SWORD Developers' Collaboration Forum
>>> >> CC:
>>> >>
>>> >>
>>> >> Those who want to participate on Sunday, April 18th at 9pm CEST,
>>> please send me your Skype ID via email. I will then set up a Skype group.
>>> >>
>>> >> Best regards,
>>> >> Tobias
>>> >>
>>> >> Am 9. April 2021 17:00:27 schrieb Tobias Klein <
>>> cont...@tklein.info>:
>>> >>
>>> >>> The most-popular option is currently Sunday, April 18th with 7
>>> votes so far. We’ll probably go for that, unless additional votes change
>>> the picture.
>>> >>>
>>> >>> Best regards,
>>> >>> Tobias
>>> >>>
>>>  Am 05.04.2021 um 18:10 schrieb Tobias Klein <
>>> cont...@tklein.info>:
>>> 
>>>  Hi all,
>>> 
>>>  Why don't we have a virtual coffee/tea some time soon?
>>> 
>>>  Would anyone be free for a Skype/Zoom/... call one of the next
>>> weekends?
>>> 
>>>  Here is a doodle poll to see who can do it at what time during
>>> the next Saturdays/Sundays.
>>> 
>>> https://doodle.com/poll/dmpn874um28wuhm5?utm_source=poll&utm_medium=link
>>> 
>>>  I suggest 9-10 PM CEST, which translates to 3-4 PM in the US
>>> east coast and a bit earlier further west ...
>>> 
>>>  Blessings,
>>>  Tobias
>>> 
>>>  ___
>>>  sword-devel mailing list: sword-devel@crosswire.org
>>>  http://crosswire.org/mailman/listinfo/sword-devel
>>>  Instructions to unsubscribe/change your settings at above page
>>> >>>
>>> >>> ___
>>> >>> sword-devel mailing list: sword-devel@crosswire.org
>>> >>> http://crosswire.org/mailman/listinfo/sword-devel
>>> >>> Instructions to unsubscribe/change your settings at above page
>>> >>
>>> >> ___ sword-devel mailing
>>> list: sword-devel@crosswire.org
>>> http://crosswire.org/mailman/listinfo/sword-devel Instructions to
>>> unsubscribe/change your settings at above page
>>> >
>>> >
>>> >
>>> > ___
>>> > sword-devel mailing list: sword-devel@crosswire.org
>>> > http://crosswire.org/mailman/listinfo/sword-devel
>>> > Instructions to unsubscribe/change your settings at above page
>>>
>>>
>>> --
>>> signature
>>>
>>> Aloha,
>>> */Michael Johnson/**
>>> 26 HIWALANI LOOP • MAKAWAO HI 96768-8747*• USA
>>> mljohnson.org  • eBible.org 
>>> • WorldEnglish.Bible  • PNG.Bible <
>>> https://PNG.Bible>
>>> Signal/Telegram/WhatsApp/Telephone: +1 808-333-6921
>>> Skype: kahunapule • Telegram/Twitter: @kahunapule • Facebook:
>>> fb.me/kahunapule 
>>>
>>> ___
>>> sword-devel mailing list: sword-devel@crosswire.org
>>> http://crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>
>> 

Re: [sword-devel] SWORD Meet 2021

[Greg Hellings]

I've been wanting to be part of one of these for years! I joined the
community shortly after the last one in 2005. I would be eager to attend if
possible.

On Sun, Mar 28, 2021, 14:30 Troy A. Griffitts  wrote:

> Dear fellow CrossWire volunteers,
>
> It's been a really, really long time since we've had a SWORD Meet.  They
> have always blessed me greatly, getting to meet many of you and having
> the chance to spend a couple days fellowshipping, brainstorming, coding,
> and praying together.  We've had a few unofficial get-togethers, usually
> centered around other events we were already attending together like
> BibleTech, ETS, SBL, Fringe, etc...
>
>
> https://crosswire.org/~scribe/pics/photo.jsp?l=/2008/2008-09-18-Scotland/&i=imgp2234_swords.jpg
>
> But it has been over 15 years since we have had regular and
> intentionally planned official SWORD Meets...
>
>
> https://crosswire.org/~scribe/pics/photo.jsp?l=/2005/2005-02-Travel/2005-02-25/&i=imgp0163_groupshot.jpg
>
>
>
> https://crosswire.org/~scribe/pics/photo.jsp?l=/2002/0409_rome/2002-04-19_austria_to_cambridge/&i=pict0018_sword_group1.jpg
>
> ... when I was much thinner.  I miss the personal community closeness we
> had back then.
>
> I would really like to again offer 2 annual occasions for us to get
> together in person-- once during May/June in Europe and once in November
> in the U.S.
>
> U.S. - November
>
> Many of us already attend the Evangelical Theological Society (ETS)
> annual meetings in November, which are conveniently aligned in location
> and time with with the technology sessions of GERT at the Society of
> Biblical Literature (SBL).  Those meetings rotate U.S. cities each year,
> but are always just before Thanksgiving.  I have met informally with
> some of you during these conferences, as well, but I would like to start
> scheduling a U.S. SWORD Meet around this occasion.  I propose either a
> couple days before ETS or the Friday / Saturday between ETS and SBL,
> when ETS is winding down and SBL is still spinning up, and IBR has their
> free annual lecture-- which would be fun for those coming who officially
> are not attending either conference but coming just for the SWORD Meet.
> ETS: https://www.etsjets.org/annual_meeting_overview SBL:
> https://www.sbl-site.org/meetings/annualmeeting.aspx IBR:
> https://ibr-bbr.org/annual-meeting IBR:
> https://ibr-bbr.org/annual-meeting/annual-lecture


I feel lucky, here. I'm located physically in between ETS (Fort Worth,
about 40 minutes north) and SBL (San Antonio, 4 hours south). I'm not free
to carte blanche offer to host as I'll hopefully be married by then. But I
would love to engage with folks, even if it's just getting lunch as you
drive past my house between the two.

I don't know how much time my upcoming nuptials will permit me away from
work, but count me in for at least some part of a US meet during that time
frame.

--Greg


>
> Europe - Spring/Summer
>
> Our previous meetings were generously held at Daniel Glassey's apartment
> in Cambridge, UK.  I always enjoyed Cambridge, with the opportunity to
> meet and be encourage by the kind staff and researcher fellows at
> Tyndale House research library.  Daniel has been off serving with other
> ministries for the past decade so we probably need to find a new
> location for our European meetings (unless Daniel reads this and still
> would like to graciously offer his flat).
>
> It won't have the same opportunities to meet with world class Bible
> scholars that Cambridge / Tyndale House gave us, but we have talked
> about meeting during the Fringe Festival in Edinburgh during August, and
> I have informally met with some of you during this occasion over the
> past years.  That's still an option and provides some fun around our
> meeting.  Hostels often have a common room were we can setup and meet in
> the afternoons.
>
> Another option is that I can invite you to my small apartment in Siena,
> Italy.  An advantage to this is, like Daniel's apartment in Cambridge,
> we can all sleep on couches and bunk beds and rollout mattresses on the
> floor and not have any accommodation expenses.  I also have fiber
> internet there and can be sure to have desk space and whiteboards handy
> and can take us to amazing pizza and gelato.
>
> __
>
> What would be the interest for attending either event and what feedback
> do you have to my suggestions for time and venue?
>
> Troy
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Best way to interate through each key in a module

[Greg Hellings]

I think you need to do something like

sword::SWKey* key = module->getKey(); // or module->createKey(); if you
rather
for(key = sword::TOP

At least, I think that's what it needs...

--Greg

On Tue, Feb 23, 2021 at 12:01 PM David "Judah's Shadow" Blue <
yudahssha...@gmx.com> wrote:

> I'm wanting to iterate through each key in a given module (bible,
> commentary,
> lexdict). I tried
>
> ...
> sword::SWModule *module;
> module = this->swordLibrary.getModule(this->selectedModule.c_str());
> for(module = sword::TOP; !module->Error(); module++)
> ...
>
> and I get "error: invalid user-defined conversion from
> ‘sword::SW_POSITION’ to
> ‘sword::SWModule*" on building. So I'm wondering what the best way to go
> through each entry in a module.
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] InstallMgr Woes

[Greg Hellings]

Just to prove to myself that I'm not completely crazy, I just did the same
process on my Windows machine where I'm running Fedora 33 in WSL2, using
the exact same bits and bytes of SWORD.

I still had to edit /etc/sword.conf to avoid writing files to
/usr/share/sword, but it installed the KJV to ~/.sword without an issue,
and is working flawlessly. So it's something wonky with my Fedora
Silverblue box.

--Greg

On Fri, Feb 5, 2021 at 2:34 PM Greg Hellings 
wrote:

>
>
> On Fri, Feb 5, 2021 at 12:49 PM Troy A. Griffitts 
> wrote:
>
>> Hi Greg,
>>
>> I few quick comments and thoughts...
>>
>> So, regarding the commandline tool and option: installmgr -init
>>
>> This simply does:
>>
>> SWBuf baseDir = FileMgr::getSystemFileMgr()->getHomeDir();
>> if (baseDir.length() < 1) baseDir = ".";
>> baseDir += "/.sword/InstallMgr";
>> confPath = baseDir + "/InstallMgr.conf";
>>
>> So, regarding its own configuration and temporary storage, it always
>> uses, basically ~/.sword/installMgr/
>>
>> SWORD_PATH should be honored regarding WHERE to finally install modules,
>> but they will first always be downloaded to ~/.sword/installMgr and once a
>> successful download is completely, the install to SWORD_PATH should happen.
>>
> Is there a particular reason to not make that configurable via the same
> methods? It definitely threw me off, and in the world of Flatpaks, Snaps,
> AppImage, etc there are times where an application should be made to honor
> other configurations (e.g. making it relative to $XDG_DATA_DIR if that's
> defined instead of directly off of $HOME). I would have expected SWORD_PATH
> to be the mechanism used, so that was a surprise to me when it didn't.
>
>> Also, SWORD has a long list of rules it uses to find your SWORD library,
>> each with precedence.  For example, a SWORD library detected in you CWD is
>> highest priority.  i.e., be sure you aren't running the command from a
>> folder which has a mods.conf file or mods.d/ folder or it will think you
>> wish to operate on your CWD.  And on the positive side, try to cd ~/.sword
>> and run installmgr (assuming a ~/.sword/mods.d/ folder exists).  You
>> shouldn't have to set SWORD_PATH for installmgr to install to ~/.sword if
>> it is your CWD.
>>
> There were no mods.conf or mods.d folders in my CWD when I was running
> these. Running installmgr from within my ~/.sword folder still results in
> no files installed. But the mystery runs deeper. I just tried using the ASV
> module, and it worked fine. Then I installed NETfree, and it worked fine,
> but the data files for the ASV module were removed. Now I can't install any
> of them to ~/.sword. But they install to ~/.local/share/sword/ successfully.
>
>> I am curious that you got it working without /etc/sword.conf entries.
>>
> Indeed, I could not get it working when that was set (I didn't try
> changing that to my homedir, I just commented out its contents entirely).
>
>> You can always see the rules used to determine your library location by
>> turning log level all the way up:
>>
>> SWORD_LOGLEVEL=DEBUG ~/src/sword/utilities/installmgr -ri CrossWire KJV
>>
> Debugging output is how I knew it was claiming to write the files to the
> proper location. Those tell me all the proper values for
> destMgr->prefixPath properly pointing to ~/.sword or ~/.local/share/sword
> depending on my current environment settings. And before it writes the file
> it gives the full path. But, for whatever reason, that doesn't seem to be
> happening consistently.
>
>> You will get all kinds of noise, but near the top (I would recommend a
>> tput clear, to reset your scrollback buffer), you should see:
>>
>> [0.00146] Checking working directory for mods.d...
>> [0.00146] found.
>> [0.00147] LOOKING UP MODULE CONFIGURATION COMPLETE.
>>
> At this point, I can install the modules, but when I try to read them with
> diatheke, I get empty string outputs. They were working fine earlier today
> once I did get them installed.
>
> So, basically, my experience with the modules install is non-deterministic
> and I'm about to pull my hair out trying to figure out what's going on! I
> don't know if it is my filesystem (BTRFS), my system (Fedora Silverblue is
> designed to be weird), something in my Fedora packaging of the library
> (always a possibility), or if I'm being bombarded with Gamma rays right now
> and it's causing my computer to spazz out. Everything I'm doing is still
> working 

Re: [sword-devel] InstallMgr Woes

[Greg Hellings]

On Fri, Feb 5, 2021 at 12:49 PM Troy A. Griffitts 
wrote:

> Hi Greg,
>
> I few quick comments and thoughts...
>
> So, regarding the commandline tool and option: installmgr -init
>
> This simply does:
>
> SWBuf baseDir = FileMgr::getSystemFileMgr()->getHomeDir();
> if (baseDir.length() < 1) baseDir = ".";
> baseDir += "/.sword/InstallMgr";
> confPath = baseDir + "/InstallMgr.conf";
>
> So, regarding its own configuration and temporary storage, it always uses,
> basically ~/.sword/installMgr/
>
> SWORD_PATH should be honored regarding WHERE to finally install modules,
> but they will first always be downloaded to ~/.sword/installMgr and once a
> successful download is completely, the install to SWORD_PATH should happen.
>
Is there a particular reason to not make that configurable via the same
methods? It definitely threw me off, and in the world of Flatpaks, Snaps,
AppImage, etc there are times where an application should be made to honor
other configurations (e.g. making it relative to $XDG_DATA_DIR if that's
defined instead of directly off of $HOME). I would have expected SWORD_PATH
to be the mechanism used, so that was a surprise to me when it didn't.

> Also, SWORD has a long list of rules it uses to find your SWORD library,
> each with precedence.  For example, a SWORD library detected in you CWD is
> highest priority.  i.e., be sure you aren't running the command from a
> folder which has a mods.conf file or mods.d/ folder or it will think you
> wish to operate on your CWD.  And on the positive side, try to cd ~/.sword
> and run installmgr (assuming a ~/.sword/mods.d/ folder exists).  You
> shouldn't have to set SWORD_PATH for installmgr to install to ~/.sword if
> it is your CWD.
>
There were no mods.conf or mods.d folders in my CWD when I was running
these. Running installmgr from within my ~/.sword folder still results in
no files installed. But the mystery runs deeper. I just tried using the ASV
module, and it worked fine. Then I installed NETfree, and it worked fine,
but the data files for the ASV module were removed. Now I can't install any
of them to ~/.sword. But they install to ~/.local/share/sword/ successfully.

> I am curious that you got it working without /etc/sword.conf entries.
>
Indeed, I could not get it working when that was set (I didn't try changing
that to my homedir, I just commented out its contents entirely).

> You can always see the rules used to determine your library location by
> turning log level all the way up:
>
> SWORD_LOGLEVEL=DEBUG ~/src/sword/utilities/installmgr -ri CrossWire KJV
>
Debugging output is how I knew it was claiming to write the files to the
proper location. Those tell me all the proper values for
destMgr->prefixPath properly pointing to ~/.sword or ~/.local/share/sword
depending on my current environment settings. And before it writes the file
it gives the full path. But, for whatever reason, that doesn't seem to be
happening consistently.

> You will get all kinds of noise, but near the top (I would recommend a
> tput clear, to reset your scrollback buffer), you should see:
>
> [0.00146] Checking working directory for mods.d...
> [0.00146] found.
> [0.00147] LOOKING UP MODULE CONFIGURATION COMPLETE.
>
At this point, I can install the modules, but when I try to read them with
diatheke, I get empty string outputs. They were working fine earlier today
once I did get them installed.

So, basically, my experience with the modules install is non-deterministic
and I'm about to pull my hair out trying to figure out what's going on! I
don't know if it is my filesystem (BTRFS), my system (Fedora Silverblue is
designed to be weird), something in my Fedora packaging of the library
(always a possibility), or if I'm being bombarded with Gamma rays right now
and it's causing my computer to spazz out. Everything I'm doing is still
working wonderfully and deterministically in CI, so I guess that's a
blessing.

Anyways, if you have any ideas on how I can further plumb the mysteries,
I'd be happy to take them on.

--Greg

>
> Just a few things to try experimenting with.
>
> Troy
>
>
>
>
> On 2/5/21 10:50 AM, Greg Hellings wrote:
>
> PREAMBLE:
> I'm trying to install modules with installmgr on the command line. I seem
> to frequently run into issues with it silently dumping the files somewhere
> where they don't actually exist, and it's happening again. But I think I've
> narrowed down some of when it happens:
>
> I currently have a /etc/sword.conf that points to /usr/local/share. In
> that folder there are locale.d, mods.d, and modules folders, but the folder
> is not writable. This works

[sword-devel] InstallMgr Woes

[Greg Hellings]

PREAMBLE:
I'm trying to install modules with installmgr on the command line. I seem
to frequently run into issues with it silently dumping the files somewhere
where they don't actually exist, and it's happening again. But I think I've
narrowed down some of when it happens:

I currently have a /etc/sword.conf that points to /usr/local/share. In that
folder there are locale.d, mods.d, and modules folders, but the folder is
not writable. This works as expected, installmgr downloads the files then
tries to write them and says it failed and suggests it might be my
permissions.

FIRST ISSUE:
So I set SWORD_PATH to ~/.sword. I run installmgr init, sync, update
CrossWire, and try to install KJV. Now I get an attempt to write the files
- the kjv.conf gets written into mods.d, but the data files are nowhere to
be found. No errors, either. Debugging is telling me it's trying to write
them into ~/.sword/modules/texts/ztext/kjv, and it successfully creates the
modules/texts/ztext folders, but nothing below that. Not the "kjv" folder
and no data files. So now I try setting SWORD_PATH to
~/.local/share/sword. Same result as before.

Once I comment out the entries in /etc/sword.conf, all is well! I get my
files AND my folder structure. But only when SWORD_PATH is set to
~/.local/share/sword/. No luck under ~/.sword/. It still misbehaves.

SECOND ISSUE:
With SWORD_PATH set to ~/.local/share/sword/, I try running installmgr sync
again after deleting my ~/.sword directory. It's writing files to ~/.sword
still. This is despite the debugging telling me "Checking $SWORD_PATH...
found(/var/home/ghelling/.local/share/sword)". Yes, I know the folder path
is odd but ~/ is /var/home/ghelling on Fedora Silverblue.

If I'm setting SWORD_PATH to ~/.local/share/sword, then shouldn't
installmgr also honor that path for downloading its files? And shouldn't
installmgr be able to write the data files to ~/.sword in the first case?

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Unicode / Windows

[Greg Hellings]

Part of that discussion last year was that the library now handles this
properly internally. There are mechanisms for handling UTF-16 Windows APIs
and so forth. You should be able to use them rather than needing to roll
your own.

--Greg

On Wed, Jan 27, 2021 at 2:23 PM Tobias Klein  wrote:

> Hi all,
>
> I just recently faced some issues related to Unicode paths on Windows
>  and
> remembered the (brief) discussion on this list last summer.
>
> I then learned about what's needed to handle Unicode paths properly on
> Windows (working with all those w-prefixed methods and having to convert
> all strings to UTF16 before calling those methods).
>
> If anyone of you ever runs in the same issues (I suppose many of you
> already did ...), this blogpost has been very helpful to me:
>
> *Using UTF-8 as the internal representation for strings in C and C++ with
> Visual Studio*
> http://www.nubaria.com/en/blog/?p=289
>
> Blessings, I hope you're all doing fine!
>
> Best regards,
> Tobias
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] How to handle on xml file per book in Osis ?

[Greg Hellings]

I will guarantee you that XML include mechanisms will not work. In an
effort to reduce external dependencies, SWORD does not make use of a
standard XML library and, therefore, won't offer functionality like
includes.

However, osis2mod does offer the "-a" flag, which it says will "augment
module if exists (default is to create new)". And that exists specifically
to support the workflow you mention. If you want to have a separate XML
file for each book of the Bible, then you can just run "osis2mod" with the
-a flag for each subsequent file and it will add entries to the module
files. So a simple script like

for src in *.xml; do
  osis2mod -a "${src}" 
done

Will recreate your module each time. Of course, you'll want to delete the
existing files before you run this, or you'll end up with all sorts of
weirdness from running through the same XML files multiple times.

--Greg

On Sun, Jan 17, 2021 at 4:35 AM David Haslam  wrote:

> Hi Pierre,
>
> This is a very good idea but it would require considerable effort to
> incorporate into the release process script by the modules team.
>
> First though, can osis2mod handle a file that uses this method? If not,
> what would it take to implement it in the ModTools & SWORD ?
>
> Discuss details.
>
> Aside: I’ve seen at least one example of an XML file set that uses this
> method.
>
> Une version TEI XML de la traduction française de la Vulgate (Bible
> latine) par l'Abbé Glaire (†1879)
> https://github.com/MarjorieBurghart/VulgateGlaire
>
> I once converted her TEI files to a single OSIS file and built a module.
> Never got round to a formal submission to CrossWire.
>
> Best regards
>
> David
>
> Sent from ProtonMail Mobile
>
>
> On Sun, Jan 17, 2021 at 10:14, pierre amadio 
> wrote:
>
> Hi there !
>
> I am having a look at the Osis format and find it inconvenient to deal
> with the whole scripture in a single large xml document.
>
> I would like to be able to have all books in a separate xml file and a
> single container xml file referring to each book to be included in the
> final bible.
>
> I am not sure what is the best way to do that so that it is easy to
> deal with osis2mod: XML entities, XInclude, something else ?
>
> Any tips or suggestions welcome.
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Ezra Project - any plans for an x64 edition ?

[Greg Hellings]

On Tue, Jan 5, 2021, 15:00 Tobias Klein  wrote:

> Hi David,
>
>
>
> I have not looked into that yet, but it’s probably possible.
>
>
>
> Electron binaries are available 64 bit.
>
> On top of that I would have to compile node-sword-interface, SWORD + all
> dependent libraries as the 64 bit version as well.
>
>
>
> Question to all:
>
> Has anyone successfully built a 64bit version of SWORD for Windows?
>
>
>
I routinely build for x64 Windows in my Fedora cross compiled packages. I
don't know if that supports your needs, but the Fedora cross compile tools
are very strong and extensive.

If any dependencies are missing, I can help get them into Fedora directly
if needed.


In any case, regarding the 64 bit support I don’t see any additional value
> for the user at this point. Do you?
>

Only if Microsoft drops 32 bit some day.

--Greg

>
>
> Best regards,
> Tobias
>
>
>
> *From: *David Haslam 
> *Sent: *Dienstag, 5. Januar 2021 17:54
> *To: *sword-devel mailing list 
> *Subject: *[sword-devel] Ezra Project - any plans for an x64 edition ?
>
>
>
> For Tobias & fellow programmers
>
>
>
> Are there any plans to offer a separate install .exe for users with
> the x64 version of Windows?
>
>
>
> Best regards,
>
>
>
> David
>
>
>
> Sent from ProtonMail Mobile
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

[sword-devel] Windows tools

[Greg Hellings]

For those of you insistent on using Windows for module work, here's the
latest build of SWORD tools for Windows based on 1.9.0.

https://github.com/devroles/mingw_sword_package/releases/tag/1.9.0a

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Standalone works

[Greg Hellings]

On Fri, Jan 1, 2021 at 4:22 PM Michael H  wrote:

> re: Install Sword Files
>
> (Is/Can) a file extension for standalone Sword files be assigned?  No
> change to the current format within the zip file, but a unique file
> extension instead of .zip would allow filesystem handlers to be able to
> sent the files into the programs on download, or doubleclick.
>

The engine has no support for wrangling .zip files. I thought I heard rumor
of a front end that did, but I wouldn't swear to it


> The other half of this request: Is there any existing program that handles
> linked files on startup/passover in this way: tread ".swd" files like a
> .zipped module?
>

If any app has support for those zipped files it *might* be Xiphos? But
please don't quote me on that.


> I'd like to produce standalone works (non-scripture study materials) that
> link to scripture.  Actually I already am producing these... they are just
> currently in pdf form only. I'd like to produce them for sword, but "books"
> as a single category doesn't seem to be able to handle the library I'm
> building... It makes more sense to me to offer the works as an option on a
> library, rather than reproduce the library in an expanded sword repo.
>

Any reason to not distribute each collection as a separate repository and
offer the files in the same way they are now?

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Sword SVN trunk fails to build using CMake

[Greg Hellings]

I just saw this failure last night just before I retired for the evening.
Thanks for finding a solution before I got back to it!

--Greg

On Thu, Dec 31, 2020, 13:09 Troy A. Griffitts  wrote:

> Dear Jaak,
>
> Thank you for reporting the problem.  Yes, it looks like you have
> pointed out exactly the problem.  I've committed a small change to do
> the svn revision lookup differently and to ignore any failures if not
> building within an svn working copy.  My apologies for the troubles.
>
> Troy
>
>
> On 12/31/20 6:32 AM, Jaak Ristioja wrote:
> > Hello and Merry Christmas! :)
> >
> > Today the BibleTime CI system started getting the following errors
> > from CMake when trying to build Sword:
> >
> > CMake Error at cmake/options.cmake:75 (PROCESS_VERSION):
> >   PROCESS_VERSION Macro invoked with incorrect arguments for macro
> > named:
> >   PROCESS_VERSION
> > Call Stack (most recent call first):
> >   CMakeLists.txt:31 (INCLUDE)
> > CMake Error at cmake/options.cmake:76 (PROCESS_VERSION):
> >   PROCESS_VERSION Macro invoked with incorrect arguments for macro
> > named:
> >   PROCESS_VERSION
> > Call Stack (most recent call first):
> >   CMakeLists.txt:31 (INCLUDE)
> >
> > See https://travis-ci.org/github/bibletime/bibletime/jobs/752237032
> > for build details.
> >
> > Perhaps this is caused by SVN 3836 ("First cut to remove internal copy
> > of old zlib code.") which made the following change to CMakeLists.txt?
> >
> >   -SET(SWORD_VERSION 1.9.0)
> >   +SET(SWORD_VERSION 1.9.0.svnversion)
> >
> >
> > J
> > ___
> > sword-devel mailing list: sword-devel@crosswire.org
> > http://crosswire.org/mailman/listinfo/sword-devel
> > Instructions to unsubscribe/change your settings at above page
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Where is current cipherraw.exe for Windows?

[Greg Hellings]

Looking back through this - did you ever try mod2zmod? cipherraw, as
explained above in the thread, has been absent from SWORD for a long time.
Encrypted modules are only supported in compressed forms.

--Greg

On Tue, Dec 1, 2020 at 6:16 PM John Dudeck  wrote:

>
> I'm not sure why this message is showing up now. I posted it on 26 march
> 2019. The question still stands, as I have never gotten a response about
> how to make encrypted Genbooks.
>
> As to why I need the tools for Windows, I work with a very small group
> that is preparing a set of Bible study materials in Sword to run on
> AndBible, targeted to French-speaking African pastors. The materials are
> mostly copyrighted, and we are using the encryption feature of Sword to
> exert a bit of barrier against mass piracy outside of Africa. Our team uses
> Windows 10 workstations, and just want to create good working Sword modules.
>
> With the advent of WSL2, I can conceivably see creating scripts that would
> run the Sword tools in the Linux subsystem. I would appreciate it if
> somebody could point me to a tutorial for installing and using Sword under
> WSL2.
>
> Even more valuable would be if somebody could show me how to build Windows
> executables of the tools from within WSL2, which would eliminate the need
> for my coworkers to deal with installing WSL2 on their workstations.
>
> Thanks.
>
> John
>
> > Am 01.12.20 um 17:39 schrieb Greg Hellings:
> > >
> > >
> > > On Thu, Nov 26, 2020 at 11:08 AM John Dudeck  > > <mailto:jdud...@laclef.org>> wrote:
> > >
> > > __
> > > Greetings.
> > >
> > > I am looking into how to use the encryption feature for Sword
> > > modules. I have done it successfully using the -c command line
> > > switch on osis2mod for Bibles, commentaries, and dictionaries.
> > >
> > > But I also need to do encryption for Genbooks. Reading the
> > Crosswire
> > > wiki, it mentions the cipherraw tool.
> > >
> > > We do our module developement on Windows. I am using the other
> > > various utilities bundled with Xiphos 64-bit, but cipherraw.exe is
> > > missing.
> > >
> > >
> > > This is officially unsupported. Only Linux is officially supported for
> > > module development.
> > >
> > > Of course, with the world being what it is, one of the easiest places
> > > for you to test things out would be in Windows using the WSL2 support.
> > > You should be able to get copies of the module utilities by tapping a
> > > sword (or sword-utils on Fedora) package for any of the distros you
> > > install in WSL2.
> > >
> > >
> > > I have the 1.7.0 / 1.8.0 32-bit version from CrossWire. Is this the
> > > latest current version?
> > >
> > >
> > > I'm unaware of any official builds from CrossWire. Where did you get
> > it?
> > >
> >
> > I guess version 1.7.0 came from
> > http://crosswire.org/ftpmirror/pub/sword/utils/win32/
> > ___
> > sword-devel mailing list: sword-devel@crosswire.org
> > http://crosswire.org/mailman/listinfo/sword-devel
> > Instructions to unsubscribe/change your settings at above page
>
> John Dudeck  Tel: +1-704-588-9891  Cell: +1-803-504-8065
> john.dud...@sim.orgCharlotte, North Carolina
> --
> Most people want to serve God, but only in an advisory capacity.
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] 1st Clement editions with versification

[Greg Hellings]

That's already a LOT of variations! I imagine you're going to see more
variation than in the canonical works and that's to be expected. Probably
just pick the one closest to your text and roll with it. I don't think this
is something you're going to end up with dozens of people wanting to bring
dozens of different modules to the repos about. So it's probably not as
important to bring everyone into a single big tent of versification.

--Greg

On Thu, Dec 10, 2020 at 6:19 AM Troy A. Griffitts 
wrote:

> Here is some I've found online:
>
> http://www.earlychristianwritings.com/text/1clement-hoole.html
>
>
> http://ccat.sas.upenn.edu/gopher/text/religion/churchwriters/ApostolicFathers/1Clement
>
> https://www.sacred-texts.com/bib/lbob/lbob15.htm
>
> https://www.newadvent.org/fathers/1010.htm
>
> The last only has chapter divisions but favors the chapter divisions of
> the first two.
>
>
>
> On December 10, 2020 5:00:07 AM MST, "Troy A. Griffitts" <
> scr...@crosswire.org> wrote:
>>
>> Thanks, Greg.
>>
>> Do we have any insights into how many editions might versify 1st Clement
>> and if there are variation? Specifically, my need is for the Syriac, if
>> that makes any difference.
>>
>> Would love any insights people might find researching this.
>>
>> Troy
>>
>>
>> On December 8, 2020 11:20:29 PM MST, Greg Hellings <
>> greg.helli...@gmail.com> wrote:
>>>
>>> I know that some of their works were. Print copies I had to read from in
>>> school were often versified, though not all of the works were.
>>>
>>> I know of no SWORD efforts to actually bring this into the code base,
>>> though.
>>>
>>> --Greg
>>>
>>> On Tue, Dec 8, 2020 at 6:13 AM Karl Kleinpaste 
>>> wrote:
>>>
>>>> On 12/7/20 6:25 PM, Troy A. Griffitts wrote:
>>>>
>>>> I see the Xiphos repository has an "Early Fathers" modules, but it looks
>>>> like this is only referenced to the chapter level-- not down to the 
>>>> "verse".
>>>>
>>>>
>>>> That was originally a module I built in '08 after Peter referred me to
>>>> material obtained from St. Mina Monastery, a series of large *.chm that I
>>>> scripted into a ThML module. Later, Brian Dumont picked it up and converted
>>>> it from CCEL sources, expanding it considerably.
>>>>
>>>> I was not aware that ECF was ever "versified" in the first place, but
>>>> I've never seen it as originally published. Was it so in the original 19th
>>>> century print editions? I see there are Kindle editions available from
>>>> Amazon -- are those versified?
>>>> ___
>>>> sword-devel mailing list: sword-devel@crosswire.org
>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>> Instructions to unsubscribe/change your settings at above page
>>>
>>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Early Church Fathers

[Greg Hellings]

I know that some of their works were. Print copies I had to read from in
school were often versified, though not all of the works were.

I know of no SWORD efforts to actually bring this into the code base,
though.

--Greg

On Tue, Dec 8, 2020 at 6:13 AM Karl Kleinpaste  wrote:

> On 12/7/20 6:25 PM, Troy A. Griffitts wrote:
>
> I see the Xiphos repository has an "Early Fathers" modules, but it looks
> like this is only referenced to the chapter level-- not down to the "verse".
>
>
> That was originally a module I built in '08 after Peter referred me to
> material obtained from St. Mina Monastery, a series of large *.chm that I
> scripted into a ThML module. Later, Brian Dumont picked it up and converted
> it from CCEL sources, expanding it considerably.
>
> I was not aware that ECF was ever "versified" in the first place, but I've
> never seen it as originally published. Was it so in the original 19th
> century print editions? I see there are Kindle editions available from
> Amazon -- are those versified?
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Where is current cipherraw.exe for Windows?

[Greg Hellings]

On Thu, Nov 26, 2020 at 11:08 AM John Dudeck  wrote:

> Greetings.
>
> I am looking into how to use the encryption feature for Sword modules. I
> have done it successfully using the -c command line switch on osis2mod for
> Bibles, commentaries, and dictionaries.
>
> But I also need to do encryption for Genbooks. Reading the Crosswire wiki,
> it mentions the cipherraw tool.
>
> We do our module developement on Windows. I am using the other various
> utilities bundled with Xiphos 64-bit, but cipherraw.exe is missing.
>

This is officially unsupported. Only Linux is officially supported for
module development.

Of course, with the world being what it is, one of the easiest places for
you to test things out would be in Windows using the WSL2 support. You
should be able to get copies of the module utilities by tapping a sword (or
sword-utils on Fedora) package for any of the distros you install in WSL2.

>
> I have the 1.7.0 / 1.8.0 32-bit version from CrossWire. Is this the latest
> current version?
>

I'm unaware of any official builds from CrossWire. Where did you get it?

--Greg

>
> Thanks!
>
> John Dudeck
> Programmer at Editions Cle Lyon, France
> john.dud...@sim.orgj...@editionscle.com
> --
> It's not a bug; it's an undocumented feature.
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Sword and WebAssembly

[Greg Hellings]

Oi. That's going to be really ... interesting. Modules aren't particularly
small, though they rarely exceed 6-8 files except in the case of those
biggest image-based modules. You might be best to auto-scan the list of
available languages, and generate a different copy of your app for each
language that Sword offers modules for? And it would just have all the
relevant files for that language already loaded? It's going to cut down on
one of the great parts of Sword apps, and that's access to *all the
languages*. But if you include *all the languages* even just form CrossWire
and only the ones whose licenses are free to distribute (not all of them
are free for others to distribute, some are CW-only, etc), you're going to
be looking at a good sized application. You can easily grow to dozens of
gigabytes even just picking up a few modules from a few of the more popular
languages. And that's to say nothing of commentaries, lexica, and general
book modules which can balloon quickly in size.

And the user will need to download it *every time*. You might be better off
to have them load the files once, import the content into the Web database
on the host, and just ask for user permission to store lots of data.

A third alternative is to incorporate WebAssembly to fetch Sword files and
write them to local disk using the newly available
https://web.dev/file-system-access/. Requires newer browsers, but you're
not likely running on antique hardware if you're running a browser new
enough for WASM+Qt applications.

You'll mainly be looking into the FileMgr class in Sword for where file
access is.

CLucene is an optional library that is used to build indexes to modules to
speed up searching. It's entirely optional. libsword already includes
brute-force searching that's "good enough" for nearly everyone and "fast
enough" on any remotely modern machine to do the trick. CLucene is
nice-to-have, especially if you know the advanced Lucene search syntax or
if you have an older system with slow access. But it's definitely an
advanced, optional feature.

--Greg

On Tue, Nov 17, 2020 at 9:27 PM Loren Burkholder <
computersemiexp...@outlook.com> wrote:

> Thanks for the suggestions, Greg. One positive thing for me is that I am
> using Qt, and Qt has a macro Q_OS_WASM that is defined when you are
> building for WASM. I'm planning to use this, if necessary, to circumvent
> WASM limitations by removing/rethinking features when in WASM. Also,
> settings that require program reloads are not (in my experience) stored
> between loads of the WASM app. Therefore, the Q_OS_WASM macro could be used
> to simply cut such features from the WASM build.
>
> One thing to consider, as far as modules are concerned, is that if
> somebody is using the WebAssembly build of a program, they almost certainly
> will have a working internet connection at some point. This could mean that
> the program could simply download a basic module--like KJV--at startup, and
> give the user the option to download others straight from the web.
> Alternatively, embedded resources work just fine in WASM (that's how I've
> been delivering the Bible in my app up until now), so the KJV module could
> be embedded with the option to install others.
>
> About CLucene--is that something that is used in Sword by default or is it
> an optional feature?
>
> Loren
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Sword and WebAssembly

[Greg Hellings]

I looked into it back in the asm.js days and, at the time, couldn't even
get the asm.js stuff to work. I haven't touched it since WebAssembly came
along and seems to have really standardized things. I've heard of some very
complex things being transpiled into WASM, that gives great hope that
something as simple as SWORD can be, as well. Strictly speaking, libsword
has no hard dependencies. Only optional ones on cURL, CLucene, etc.

The hardest part is probably going to be fetching down the modules.
WebAssembly would need to have access to some sort of file system or
virtual file system, and you're looking at anywhere from a few dozen KB for
the smallest up to in the vicinity of a meg or two for many of them. The
biggest ones are image based and run to a couple hundred megabytes. I don't
know what WASM does for trapping file system calls or the limits on web app
storage. Most browsers, when looking at a website, are limiting it to
5-10MB per site. That's not going to go very far for SWORD data.

In short - no horror stories. You'll probably make off pretty well with it.
You'll just want to be sure you know how it's storing downloaded resources
and manage that, if necessary. Same thing if you build it with CLucene
dependency. That will need to store its indexes somewhere, but the space
isn't as big as most of the modules themselves. Just another file
management thing to consider.

--Greg

On Tue, Nov 17, 2020 at 8:05 PM Loren Burkholder <
computersemiexp...@outlook.com> wrote:

> First and foremost: I promise that I will try to not bug y'all with any
> more questions for a while (at least, not with questions not on this topic).
>
> Does anybody know if Sword works with WebAssembly? The reason that I ask
> is here: https://lorendb.github.io/TotalReqall/wasm/TotalReqall.html.
> (Note that this doesn't have Sword in it.) I want to continue providing a
> WASM binary, but in order to do that, I will need to get Sword working on
> WASM. Any thoughts, anecdotes, or horror stories?
>
> Loren
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Remove Strong's references from KJV module

[Greg Hellings]

Have you tried OSISPlain? KJV is not in GBF

On Sat, Nov 14, 2020, 21:42 Loren Burkholder 
wrote:

> I'm trying to get the plain text for a verse from the KJV module, but I
> can't figure out how to remove the Strong's references. I've tried adding a
> sword::GBFPlain and sword::GBFStrongs as a strip filter to my KJV module,
> but it only strips out the beginning of the  element, leaving me with
> stuff like:
>
> > salvm="strong:H072255">In the beginning
>
> as my output, instead of taking out the whole 
> tag. What should I be doing to get rid of all this?
>
> Thanks in advance.
> Loren Burkholder
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SWORD 1.9.0 final this weekend

[Greg Hellings]

On Fri, Oct 30, 2020 at 4:59 AM domcox  wrote:

> Le mer. 28 oct. 2020 à 17:18, Greg Hellings 
> a écrit :
> > It's not a Fedora thing
>
> Hi Greg,
>
> I'm Sorry! I have not been clear in my explanations:)
>
> I agree, it's not a Fedora thing, it's just that building with CMake
> now require out-of-source builds.
>

Odd, because I've been requiring and executing out-of-source builds with
CMake in Sword for a long time.


> At a first glance, it seems the Perl install script doesn't work with
> out-of source builds.
>

Something has changed. I don't know what it is, but it definitely needs
looking into.


> We were in a pre-lockdown situation yesterday, so I didn't have much
> spare time to work on this.
>

Enjoy your lockdown!

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SWORD 1.9.0 final this weekend

[Greg Hellings]

It's not a Fedora thing. I couldn't get it to build locally, anywhere. I
officially own that step of the build, but I haven't taken time this month
to look into it. The code hasn't changed in any way I'm aware of in a
modest lengthed eternity.

For the Fedora package I've temporarily disabled that building until I can
create a patch to get the build working again.

--Greg

On Wed, Oct 28, 2020, 15:20 domcox  wrote:

> Le mar. 27 oct. 2020 à 8:41, Troy A. Griffitts 
> a écrit :
> >
> I cannot either build Sword-1.8.1 Perl RPMs in f33.
>
> I guess it's related to the new %cmake macros used to build RPMs:
> https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
>
>
> Dom
> --
> domcox 
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SWORD 1.9.0RC3 Available

[Greg Hellings]

On Tue, Oct 6, 2020 at 3:52 AM ZdPo Ster  wrote:

>
>
> On Sun, 4 Oct 2020 at 21:32, Greg Hellings 
> wrote:
>
>> Ah, I had heard that Microsoft understood slash characters better in
>> paths nowadays compared to their insistence on backslashes in the past.
>> That update should be easy to merge.
>>
>
> IMO this (original warning) is not a problem of Microsoft but cmake.
>

This was a bad decision Microsoft made dozens of years ago. They're finally
getting better. :)


>
>> Why do we need to call this "CMAKE_POLICY" function? What is CMP0012? You
>> seem to be on a VERY new version of CMake, whereas we support pretty old
>> versions. The CMakeLists.txt itself claims to support back to 2.6.0, which
>> allows us to still cover older versions of CentOS and Ubuntu. Is this
>> policy something specific to newer versions of CMake? I would rather not
>> bump older versions out of accessibility if I don't need to.
>>
>
> Problem is not in SWORD but cURL (7.72.0). Here is output from cmake
> output:
>

Having read more, I'm not going to put settings into CMakeLists.txt that
account for deprecations in cURL. Please report this to cURL so they can
change the text of their generated CMake files.

The default path change has been added to the head of SVN now. You can grab
that and see if it works for you, now.

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SWORD 1.9.0RC3 Available - Windows

[Greg Hellings]

Gary,

I have prepared the changes for #1 and 4 below.

For #3 try defining CLUCENE_HOME with -DCLUCENE_HOME=../../some/path/ to
where you built and installed CLucene. That *should* allow
FindCLucene.cmake to locate the files appropriately.

Now, if I could just ever remember my SVN password to make a commit to the
source tree! Shame we can't have SSH transport for commits!

--Greg

On Sun, Oct 11, 2020 at 3:01 PM Greg Hellings 
wrote:

>
>
> On Sun, Oct 11, 2020, 11:21 Gary Holmlund  wrote:
>
>> Troy and Greg,
>>
>> I have compiled BibleTime with Sword 1.8.903 on Windows. To do this I
>> had to make 4 changes to cmake files. The first and last one are easy
>> changes. The second and third will need more effort to decide how to
>> properly fix them.
>>
>> Thanks for your great efforts.
>>
>> Gary Holmlund
>>
>>
>> 1. Find ICU Quiet.
>>
>> 52c52
>> < FIND_PACKAGE(ICU
>> ---
>>  > FIND_PACKAGE(ICU QUIET
>>
>
> This is curious. I wonder why.
>
>
>>
>>
>> 2.I had to comment out the find of clucene.
>>
>> 55c55
>> < FIND_PACKAGE(CLucene QUIET)
>> ---
>>  > #FIND_PACKAGE(CLucene QUIET)
>>
>>  If it is not commented out, I get this error.
>>
>>CMake Error at cmake/FindCLucene.cmake:82 (FILE):
>>FILE failed to open for reading (No such file or directory):
>>
>> C:/bibletime-tmp/b5/sword-prefix/src/sword-build/./CLucene/clucene-config.h
>>
>>NOTE: I find CLucene/clucene-config.h in the include directory.
>>
>
> There should be a series of search paths it looks through. I'm not at my
> computer right now to check, but if you define the search paths this should
> be unnecessary. Tobias, I think, has a build script that demonstrates
> defining the search path for CLucene.
>
>
>>
>>
>> 3. buildtest.exe build error - I comment out the building of
>> buildtest.exe in CMakeLists.txt
>>
>> 272,277c272,277
>> < ADD_EXECUTABLE(buildtest buildtest.cpp)
>> < IF(BUILDING_STATIC)
>> <   TARGET_LINK_LIBRARIES(buildtest sword_static)
>> < ELSE(BUILDING_STATIC)
>> <   TARGET_LINK_LIBRARIES(buildtest sword)
>> < ENDIF(BUILDING_STATIC)
>> ---
>>  > #ADD_EXECUTABLE(buildtest buildtest.cpp)
>>  > #IF(BUILDING_STATIC)
>>  > # TARGET_LINK_LIBRARIES(buildtest sword_static)
>>  > #ELSE(BUILDING_STATIC)
>>  > # TARGET_LINK_LIBRARIES(buildtest sword)
>>  > #ENDIF(BUILDING_STATIC)
>>
>> Here are the errors I got without this change.
>>
>> buildtest.cpp
>> 5>C:\bibletime-tmp\sword\include\swkey.h(92,32): warning C4251:
>> 'sword::SWKey::localeCache': class 'sword::SWKey::LocaleCache' needs to
>> have dll-interface to be used by clients of class 'sword::SWKey'
>> [C:\bibletime-tmp\b6\sword-prefix\src\sword-build\buildtest.vcxproj]
>> 5>C:\bibletime-tmp\sword\include\swkey.h(79): message : see declaration
>> of 'sword::SWKey::LocaleCache'
>> [C:\bibletime-tmp\b6\sword-prefix\src\sword-build\buildtest.vcxproj]
>> 5>C:\bibletime-tmp\sword\include\swconfig.h(125,34): warning C4251:
>> 'sword::SWConfig::Sections': class
>> 'std::map,std::allocator>
>> sword::SWBuf,sword::ConfigEntMap>>>' needs to have dll-interface to be
>> used by clients of class 'sword::SWConfig'
>> [C:\bibletime-tmp\b6\sword-prefix\src\sword-build\buildtest.vcxproj]
>> 5>C:\bibletime-tmp\sword\include\swconfig.h(36): message : see
>> declaration of
>> 'std::map,std::allocator>
>> sword::SWBuf,sword::ConfigEntMap>>>'
>> [C:\bibletime-tmp\b6\sword-prefix\src\sword-build\buildtest.vcxproj]
>> 5>C:\bibletime-tmp\sword\include\swmodule.h(118,24): warning C4251:
>> 'sword::SWModule::ownConfig': class
>> 'sword::multimapwithdefault>'
>>
>> needs to have dll-interface to be used by clients of class
>> 'sword::SWModule'
>> [C:\bibletime-tmp\b6\sword-prefix\src\sword-build\buildtest.vcxproj]
>> 5>C:\bibletime-tmp\sword\include\swconfig.h(35): message : see
>> declaration of
>> 'sword::multimapwithdefault>'
>>
>> [C:\bibletime-tmp\b6\sword-prefix\src\sword-build\buildtest.vcxproj]
>> 5>C:\bibletime-tmp\sword\include\swmodule.h(120,43): warning C4251:
>> 'sword::SWModule::entryAttributes': class
>> 'std::map,std::allocator>
>> sword::SWBuf,sword::AttributeList>>>' needs to have dll-inte

Re: [sword-devel] SWORD 1.9.0RC3 Available - Windows

[Greg Hellings]

On Sun, Oct 11, 2020, 11:21 Gary Holmlund  wrote:

> Troy and Greg,
>
> I have compiled BibleTime with Sword 1.8.903 on Windows. To do this I
> had to make 4 changes to cmake files. The first and last one are easy
> changes. The second and third will need more effort to decide how to
> properly fix them.
>
> Thanks for your great efforts.
>
> Gary Holmlund
>
>
> 1. Find ICU Quiet.
>
> 52c52
> < FIND_PACKAGE(ICU
> ---
>  > FIND_PACKAGE(ICU QUIET
>

This is curious. I wonder why.


>
>
> 2.I had to comment out the find of clucene.
>
> 55c55
> < FIND_PACKAGE(CLucene QUIET)
> ---
>  > #FIND_PACKAGE(CLucene QUIET)
>
>  If it is not commented out, I get this error.
>
>CMake Error at cmake/FindCLucene.cmake:82 (FILE):
>FILE failed to open for reading (No such file or directory):
> C:/bibletime-tmp/b5/sword-prefix/src/sword-build/./CLucene/clucene-config.h
>
>NOTE: I find CLucene/clucene-config.h in the include directory.
>

There should be a series of search paths it looks through. I'm not at my
computer right now to check, but if you define the search paths this should
be unnecessary. Tobias, I think, has a build script that demonstrates
defining the search path for CLucene.


>
>
> 3. buildtest.exe build error - I comment out the building of
> buildtest.exe in CMakeLists.txt
>
> 272,277c272,277
> < ADD_EXECUTABLE(buildtest buildtest.cpp)
> < IF(BUILDING_STATIC)
> <   TARGET_LINK_LIBRARIES(buildtest sword_static)
> < ELSE(BUILDING_STATIC)
> <   TARGET_LINK_LIBRARIES(buildtest sword)
> < ENDIF(BUILDING_STATIC)
> ---
>  > #ADD_EXECUTABLE(buildtest buildtest.cpp)
>  > #IF(BUILDING_STATIC)
>  > # TARGET_LINK_LIBRARIES(buildtest sword_static)
>  > #ELSE(BUILDING_STATIC)
>  > # TARGET_LINK_LIBRARIES(buildtest sword)
>  > #ENDIF(BUILDING_STATIC)
>
> Here are the errors I got without this change.
>
> buildtest.cpp
> 5>C:\bibletime-tmp\sword\include\swkey.h(92,32): warning C4251:
> 'sword::SWKey::localeCache': class 'sword::SWKey::LocaleCache' needs to
> have dll-interface to be used by clients of class 'sword::SWKey'
> [C:\bibletime-tmp\b6\sword-prefix\src\sword-build\buildtest.vcxproj]
> 5>C:\bibletime-tmp\sword\include\swkey.h(79): message : see declaration
> of 'sword::SWKey::LocaleCache'
> [C:\bibletime-tmp\b6\sword-prefix\src\sword-build\buildtest.vcxproj]
> 5>C:\bibletime-tmp\sword\include\swconfig.h(125,34): warning C4251:
> 'sword::SWConfig::Sections': class
> 'std::map,std::allocator
> sword::SWBuf,sword::ConfigEntMap>>>' needs to have dll-interface to be
> used by clients of class 'sword::SWConfig'
> [C:\bibletime-tmp\b6\sword-prefix\src\sword-build\buildtest.vcxproj]
> 5>C:\bibletime-tmp\sword\include\swconfig.h(36): message : see
> declaration of
> 'std::map,std::allocator
> sword::SWBuf,sword::ConfigEntMap>>>'
> [C:\bibletime-tmp\b6\sword-prefix\src\sword-build\buildtest.vcxproj]
> 5>C:\bibletime-tmp\sword\include\swmodule.h(118,24): warning C4251:
> 'sword::SWModule::ownConfig': class
> 'sword::multimapwithdefault>'
>
> needs to have dll-interface to be used by clients of class
> 'sword::SWModule'
> [C:\bibletime-tmp\b6\sword-prefix\src\sword-build\buildtest.vcxproj]
> 5>C:\bibletime-tmp\sword\include\swconfig.h(35): message : see
> declaration of
> 'sword::multimapwithdefault>'
>
> [C:\bibletime-tmp\b6\sword-prefix\src\sword-build\buildtest.vcxproj]
> 5>C:\bibletime-tmp\sword\include\swmodule.h(120,43): warning C4251:
> 'sword::SWModule::entryAttributes': class
> 'std::map,std::allocator
> sword::SWBuf,sword::AttributeList>>>' needs to have dll-interface to be
> used by clients of class 'sword::SWModule'
> [C:\bibletime-tmp\b6\sword-prefix\src\sword-build\buildtest.vcxproj]
> 5>C:\bibletime-tmp\sword\include\swmodule.h(78): message : see
> declaration of
> 'std::map,std::allocator
> sword::SWBuf,sword::AttributeList>>>'
> [C:\bibletime-tmp\b6\sword-prefix\src\sword-build\buildtest.vcxproj]
> 5>C:\bibletime-tmp\sword\include\swmodule.h(142,30): warning C4251:
> 'sword::SWModule::rawdisp': class 'sword::SWModule::StdOutDisplay' needs
> to have dll-interface to be used by clients of class 'sword::SWModule'
> [C:\bibletime-tmp\b6\sword-prefix\src\sword-build\buildtest.vcxproj]
> 5>C:\bibletime-tmp\sword\include\swmodule.h(107): message : see
> declaration of 'sword::SWModule::StdOutDisplay'
> [C:\bibletime-tmp\b6\sword-prefix\src\sword-build\buildtest.vcxproj]
> 5> Creating library
> C:/bibletime-tmp/b6/sword-prefix/src/sword-build/Release/buildtest.lib
> and object
> C:/bibletime-tmp/b6/sword-prefix/src/sword-build/Release/buildtest.exp
> 5>buildtest.obj : error LNK2019: unresolved external symbol "public:
> static char * sword::SWBuf::nullStr" (?nullStr@SWBuf@sword@@2PADA)
> referenced in function "public: __thiscall std::pair const ,class sword::multimapwithdefault sword::SWBuf,struct std::less > >::pair sword::SWBuf const ,class sword::multimapwithdefault sword::SWBuf,class sword::SWBuf,struct std::less >
>  >(struct std::piecewise_construct_t,class
> std::t

Re: [sword-devel] Issues with German Umlaut characters in SWORD trunk? [RESOLVED]

[Greg Hellings]

Tobias,

That's awesome to see that CMake is working out for building on Windows.
Two quick questions:

1) Are any of those CLI flags ones that we should include into the
CMakeLists.txt somewhere? I'm thinking specifically of the one where you
tell the system to export all symbols, but any others that should be
included or defaulted are also OK. Let me know and I can work on putting
them into the system to simplify your build process.

2) What version of CMake are you using? Someone on another thread is
struggling to build on Windows because of the default install directory
being set with \\ as the path separator and needed to switch it to /
instead. But they're on CMake 3.18.2, so I'm curious what version you're on
and if that is a new development in the CMake versions that they'll
understand Unix path separators on Windows.

--Greg

On Sun, Oct 4, 2020 at 12:15 PM Tobias Klein  wrote:

> I managed to fix my SWORD build for Windows without changing anything in
> the sources. I've changed the way how the CMake options for ICU are set at
> the time when CMake is configured.
>
> Previously I didn't have the ICU_ROOT variable set. After changing that to
> the correct value, ICU is detected correctly. For those curious, this is
> the current build script I'm using for SWORD on Windows:
>
>
> https://github.com/tobias-klein/sword-build-win32/blob/71e23ea83ad93a066c2fc0264f4c633025234712/build_sword.bat
>
> After configuring the SWORD Windows build like this I'm not getting the
> "Umlaut" issue anymore that triggered this e-mail thread.
>
> Best regards,
> Tobias
> On 10/3/20 9:39 PM, Tobias Klein wrote:
>
> Ok, so it's not about the CMake version. Current build still has issues
> with the older CMake version.
>
> I've checked on changes in CMakeLists.txt.
>
> Greg changed this on July 28th (SVN Rev. 3773, Commit message "Simplify
> finding libraries").
>
> Diff:
> https://github.com/bibletime/crosswire-sword-mirror/commit/dfcb4e42fd61a295c6c0e60a62088c34fd139f76#diff-af3b638bc2a3e6c650974192a53c7291
>
> For MSVC the following ICU related configuration changed:
>
> Previously (before SVN Rev. 3773):
>
> FIND_PACKAGE(ICU REQUIRED)
> Now (from SVN Rev. 3773):
>
> FIND_PACKAGE(ICU COMPONENTS data i18n io uc)
>
> *This looks like the root-cause to my issue.*
>
> With the previous command ICU is correctly found resulting in
> Found ICU: D:/a/sword-build-win32/sword-build-win32/icu/icu4c/include
> (found version "65.1")
>
> With the new command ICU is only partially found and then subsequently
> ignored alltogether:
>
> -- SEARCHING FOR SYTEM PACKAGES
> 5089
> --
> Found the following ICU libraries:
> 5090
> --
> i18n (required)
> 5091
> --
> uc (required)
> 5092
> --
> The following ICU libraries were not found:
> 5093
> --
> data (required)
> 5094
> --
> io (required)
> 5095
> --
> Failed to find all ICU components (missing: _ICU_REQUIRED_LIBS_FOUND)
> (found version "65.1")
>
> I guess I can now figure out why the data component and the io component
> are not found. In any case, before that change I could successfully build
> and link against ICU and in my application I did not get problems with
> German Umlaut's, which I now have ...
>
> I just double-checked the build with SVN Rev. 3772 (the version before
> Greg's change) and there ICU is still found correctly:
>
> -- SEARCHING FOR SYTEM PACKAGES
> 88
> --
> Found ICU: D:/a/sword-build-win32/sword-build-win32/icu/icu4c/include
> (found version "65.1")
>
> Any additional pointers? Are the ICU data and io components *actually*
> required by SWORD? I didn't seem to need them before.
>
> Best regards,
> Tobias
>
> On 10/3/20 8:09 PM, Tobias Klein wrote:
>
> When building SWORD based on SVN Rev. 3747 (May 18th) I get the following
> CMake output and with this SWORD version ICU *is still found correctly*.
>
> For both builds (ICU found vs. not found) I've been using the same ICU
> sources (Version 65, tag *release-65-1*,
> https://github.com/unicode-org/icu/tree/release-65-1).
>
> Since May 18th - has something changed in how the ICU library is
> found/detected?
>
> I will now check which CMake version is used on the GitHub build agents, I
> don't think I'm controlling

Re: [sword-devel] SWORD 1.9.0RC3 Available

[Greg Hellings]

Ah, I had heard that Microsoft understood slash characters better in paths
nowadays compared to their insistence on backslashes in the past. That
update should be easy to merge.

Why do we need to call this "CMAKE_POLICY" function? What is CMP0012? You
seem to be on a VERY new version of CMake, whereas we support pretty old
versions. The CMakeLists.txt itself claims to support back to 2.6.0, which
allows us to still cover older versions of CentOS and Ubuntu. Is this
policy something specific to newer versions of CMake? I would rather not
bump older versions out of accessibility if I don't need to.

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SWORD 1.9.0RC3 Available

[Greg Hellings]

Sword doesn't really support building on Windows other than with the
Borland C++ files that Troy maintains. CMake can easily be used to
cross-compile from Linux.

If you would like to provide fixes to it so that it also builds directly
from Windows with CMake, you're welcome to send those to the list or to me
directly.

--Greg

On Sat, Oct 3, 2020 at 4:09 AM ZdPo Ster  wrote:

> cmake 3.18.2 (on windows)  reports:
>
> CMake Warning (dev) at cmake/options.cmake:21 (set):
>   Syntax error in cmake code at
>
> F:/Project-Personal/clang_shared/sword-1.9.0RC3/cmake/options.cmake:21
>
>   when parsing string
>
> Directory into which to install architecture-dependent files. Defaults
> to C:\Program Files (x86)\libsword\.
>
>   Invalid escape sequence \P
>
>   Policy CMP0010 is not set: Bad variable reference syntax is an error.
> Run
>   "cmake --help-policy CMP0010" for policy details.  Use the cmake_policy
>   command to set the policy and suppress this warning.
> Call Stack (most recent call first):
>   cmake/options.cmake:35 (_SET_FANCY)
>   CMakeLists.txt:31 (INCLUDE)
> This warning is for project developers.
>
> cmake & VS build is ok.
> But when I tried to build sword with cmake and clang (which is able to
> create libraries compatible with VS or gcc) via ninja I got error message:
>
> failed with:
>ninja: error: build.ninja:2837: multiple rules generate sword.lib
>
> IMO these are not showstoppers, but it would be nice to solve them in the
> final release...
>
> Zdenko
>
> On Fri, 2 Oct 2020 at 22:00, Karl Kleinpaste  wrote:
>
>> On 10/2/20 9:42 AM, Troy A. Griffitts wrote:
>>
>> Please give it a try and let me know if you have any issues
>>
>> No issue building, and building Xiphos with it.
>>
>> But important question: Does this release take care of the UTF-16
>> problem? I know that was being discussed some months back. That is, will we
>> be able to dispose of the decade-old patch for Win32 Sword that keeps
>> Xiphos sane in the face of NTFS and đíàçŕïẗ́iċąłṡ?
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SWORD 1.9.0RC3 Available

[Greg Hellings]

On Fri, Oct 2, 2020 at 2:57 PM Karl Kleinpaste  wrote:

> On 10/2/20 9:42 AM, Troy A. Griffitts wrote:
>
> Please give it a try and let me know if you have any issues
>
> No issue building, and building Xiphos with it.
>
> But important question: Does this release take care of the UTF-16 problem?
> I know that was being discussed some months back. That is, will we be able
> to dispose of the decade-old patch for Win32 Sword that keeps Xiphos sane
> in the face of NTFS and đíàçŕïẗ́iċąłṡ?
>

It *should be*. Troy did inline a native Sword fix based on the latest
version of the Xiphos patch. More testing would, of course, be welcome.

--Greg

> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SWORD 1.9.0RC3 Available

[Greg Hellings]

Users of Fedora can now find a build of this in Rawhide as 1.8.903.

--Greg

On Fri, Oct 2, 2020 at 8:49 AM Troy A. Griffitts 
wrote:

> OK, I hope this will be the last RC before final release.  This RC
> includes the changes last week with the TEI filter supporting  for
> Fr. Cyrille, hiding implementation details for SWClass, defaulting
> SWDYANIC_CAST to the compiler's dynamic_cast, and better const stafety.
>
> There shouldn't be much that would break anything.  Please give it a try
> and let me know if you have any issues:
>
>
> https://crosswire.org/sword/ALPHAcckswwlkrfre22034820285912/sword-1.9.0RC3.tar.gz
>
> Thank you for all your help and comments.  Hope everyone is at the end
> of a good week and looking forward to a great weekend,
>
> Troy
>
>
> On 9/17/20 8:25 PM, Troy A. Griffitts wrote:
> > RC2 is available.  Small changes to accommodate a few lint warnings
> > and updated java-jni bindings.  Added Vietnamese [Pref Abbrevs]
> > section (thanks Daniel Owens!)
> >
> >
> https://crosswire.org/sword/ALPHAcckswwlkrfre22034820285912/sword-1.9.0RC2.tar.gz
> >
> >
> > Please let me know if you have positive or negative results.  I would
> > like to hear things are working in our mainstream frontends before
> > pushing this out; it would give me happy thoughts.
> >
> > Hope everyone is having a good week,
> >
> > Troy
> >
> >
> > On 9/11/20 6:57 PM, Troy A. Griffitts wrote:
> >> Give it a go and let me know.
> >>
> >>
> http://crosswire.org/sword/ALPHAcckswwlkrfre22034820285912/sword-1.9.0RC1.tar.gz
> >>
> >>
> >> Also, just to reiterate, if I've let anything out submitted by
> >> anyone, it isn't because I don't like you (probably), it's more
> >> likely that I'm old and forgetful. Please let me know if you don't
> >> notice something you've submitted in bundled up in the RC.
> >>
> >> Thanks for any feedback one way or another.
> >>
> >> Troy
> >>
> >> ___
> >> sword-devel mailing list: sword-devel@crosswire.org
> >> http://crosswire.org/mailman/listinfo/sword-devel
> >> Instructions to unsubscribe/change your settings at above page
> > ___
> > sword-devel mailing list: sword-devel@crosswire.org
> > http://crosswire.org/mailman/listinfo/sword-devel
> > Instructions to unsubscribe/change your settings at above page
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SWORD 1.9.0RC1 Available

[Greg Hellings]

On Fri, Sep 11, 2020 at 1:58 PM Dominique Corbex 
wrote:

> On Fri, 11 Sep 2020 13:30:56 -0500
> Greg Hellings  wrote:
>
> > Something is broken in the Perl bindings build.
>
> In bindings/swig/perl/CMakeLists.txt, we have:
>
> WriteMakefile(
> 'NAME'  => 'Sword',
> 'VERSION'   => '${SWORD_VERSION}',
> 'INC'   => '-I\"${CMAKE_SOURCE_DIR}/include\"
> -I\"${CMAKE_CURRENT_SOURCE_DIR}/..\"',
> 'DEFINE'=> '-DSWIG',
> 'LIBS'  => '-L\"${CMAKE_BINARY_DIR}\" -lsword -lz',
> 'FIRST_MAKEFILE' => 'Makefile.perlswig',
> 'PREREQ_PM' => {},
> ($] >= 5.005 ? ## Add these new keywords supported since
> 5.005
> (ABSTRACT => 'Sword Project perl bindings', # retrieve
> abstract from module
> AUTHOR => 'Sword Project ') :
> ()),
> );
>
> According to https://perldoc.perl.org/ExtUtils/MakeMaker.html:
> INSTALLDIRS is not set, the default is SITEPREFIX I guess, so the Perl
> bindings fails because
> - Perl bindings are built in /usr/local/lib
> - Sword Swig is built in /usr/lib
>

This is good to keep in mind, but the problem is more fundamentally that
the makefile above isn't getting generated (possibly at all, possibly in a
different path - I wasn't in a position to check that out, specifically)

--Greg

>
> But I'm not a Perl Monger and I don't know how to fix that bug.
>
> --
> domcox 
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SWORD 1.9.0RC1 Available

[Greg Hellings]

I'm building it for Fedora Rawhide right now. A scratch build went without
a hitch.

Something is broken in the Perl bindings build. I'll have to dig into that.

--Greg

On Fri, Sep 11, 2020 at 12:06 PM Troy A. Griffitts 
wrote:

> Give it a go and let me know.
>
>
> http://crosswire.org/sword/ALPHAcckswwlkrfre22034820285912/sword-1.9.0RC1.tar.gz
>
> Also, just to reiterate, if I've let anything out submitted by anyone,
> it isn't because I don't like you (probably), it's more likely that I'm
> old and forgetful. Please let me know if you don't notice something
> you've submitted in bundled up in the RC.
>
> Thanks for any feedback one way or another.
>
> Troy
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Ezra Project 0.14.0 released

[Greg Hellings]

Tobias,

I applaud your efforts! I just pulled the latest git, built, and am running
it on my local system. A few things came to my notice from a usability
perspective:

1) I absentmindedly selected a random module and pulled up a random book -
Ecclesiastes in the Westcott-Hort Greek NT module. Of course, Ecclesiastes
was grayed out in the book selection box, but that didn't stop me from
selecting it. As a result, I sat and stared at the spinning UI widget for
an embarrassingly long period of time before I realized it was a PEBKAC
situation and not a technical one. Perhaps disabling the selection (or even
display?) of unavailable portions of a text would be an improvement, here?

2) When I did finally get around to selecting a passage available in
Westcott-Hort, the tab title is updated to reflect "II John [WH2006]", but
the "Book" drop down still just says, "Book". Perhaps it could be updated,
as well? I would expect the UI component I just clicked on to be the one
that updates! The same goes for the search entry.

3) I really liked the touch where it searched a new module automatically
when I switched modules! That was nice!

4) When I loaded a verse and clicked "Compare Translations", I really like
the box that pops up. That's a nice touch I haven't seen anywhere else.
However, the title bar for it reads "Comparing translations for None" when
accessed from searches. It properly shows "Comparing translations for
Matthew 1:1" when I access it directly from the text.

5) Looking at the text window, it was not immediately obvious that the
numbers running down the left hand side were chapter numbers. I thought
they were allowing me to select verses and get more information on the
verse itself. So when I clicked on one, it surprised me to be suddenly
taken to another place in Matthew. Perhaps a header in the column would be
appropriate?

6) Something is weird about the rendering of footnotes in the ASV module.
Instead of having superscript characters, the numbers (1, 2, 3) appear in
the text directly, and the footnotes appear directly at the end of each
verse like "1) some note text". This isn't the case with other modules I
tested, so something is going on that's different. Most likely a difference
in the rendered HTML from the module. ASV isn't particularly necessary,
it's just one I happened to have installed and could take a look at.

A quick glance through, those were some of the things that just came up to
my eyes, quickly.

Also, I'd like to re-offer: if you can decompose the build/install process
from needing to bundle SWORD directly, I am happy to work with you on
packaging it directly for Fedora's main repositories.

--Greg

On Sun, Aug 30, 2020 at 12:57 PM Tobias Klein  wrote:

> Hi all,
>
> Ezra Project 0.14.0 has just been released.
>
> https://github.com/tobias-klein/ezra-project/releases/tag/0.14.0
>
> Ezra Project 0.14.0 features visualization of cross references and
> footnotes, an enhanced dictionary box that shows all Strong's linked
> dictionary resources for the selected Strong's number and various
> enhancements and bugfixes.
>
> Note-worthy improvements are:
>
>- Visualization of Cross References and Footnotes (from SWORD markup).
>- Dictionary box: Integrate possibility to show Strong's linked
>dictionary resources.
>- Dictionary install/uninstall assistant.
>- Added possibility to open verse lists (tagged verses or
>cross-references) in separate tab.
>- Windows/Linux: Added fullscreen feature (on F11).
>- Tagged Verse List popup: Added filter for the verses of the
>currently opened book.
>
> Details regarding changes can be found in the changelog
> .
>
> Installation instructions can be found here
> 
> .
>
> Downloads are available for:
>
>- Windows (tested on Windows 10)
>- macOS (tested on Catalina 10.15.5)
>- Ubuntu 18.04 + 19.10 + 20.04
>- Debian 10
>- Linux Mint 18 + 19
>- Fedora 29 (also works with Fedora 30)
>- Fedora 31
>- CentOS 8
>
> Translations are up-to-date for English, German, French and Dutch. Thanks
> to Tom Lemmens for the Dutch & French translation updates!
>
> Best regards,
> Tobias
> ___
> 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

Re: [sword-devel] Win32 FileMgr Subclass - BibleTime

[Greg Hellings]

On Mon, Jul 27, 2020 at 3:22 PM Tobias Klein  wrote:

> Maybe it helps: This is how I build bzip2 on Windows with the Visual
> Studio compiler based on their Git repo *git://sourceware.org/git/bzip2.git
> <http://sourceware.org/git/bzip2.git>*.
>
>
>
>
> https://github.com/tobias-klein/sword-build-win32/blob/master/build_bzip2.bat
>
>
>
> Best regards,
> Tobias
>
>
>
> *From: *Gary Holmlund 
> *Sent: *Montag, 27. Juli 2020 21:01
> *To: *SWORD Developers' Collaboration Forum ; Greg
> Hellings 
> *Subject: *Re: [sword-devel] Win32 FileMgr Subclass - BibleTime
>
>
>
>
>
> On 7/27/2020 7:24 AM, Greg Hellings wrote:
>
> >
>
> > If any other Xiphos developers want to do testing, or if BibleTime
>
> > does any cross compiling from Fedora. You can also find Xiphos
>
> > installers building the latest Xiphos head against this latest Sword
>
> > head. I'm very far from any Windows machine I can use as a test, so if
>
> > anyone else has a Windows machine to test this on - preferably one
>
> > with a username that includes non-ASCII characters in it - then feel
>
> > free to grab that. If the BibleTime Windows builder (Gary?) wants to
>
> > generate builds against the latest SVN HEAD and test in the same
>
> > manner, it would be a huge help.
>
>
>
> Greg,
>
>
>
> I tried to build BibleTime with the latest sword svn, but I ran into a
>
> build issue. We don't build with bzip2 because it is not well supported
>
> on Windows. I used the cmake var SWORD_NO_BZIP2=Yes, but the sword build
>
> still required bzip2. Can you fix this?
>

Interesting. I was sitting here trying to figure out what you could be
possibly running into. I don't do my builds with bzip2 installed from MinGW!

Turns out CMakeLists.txt has:

IF(MSVC)
 FIND_PACKAGE(BZIP2 REQUIRED)
 FIND_PACKAGE(XZ REQUIRED)
 FIND_PACKAGE(ICU REQUIRED)
 FIND_PACKAGE(CURL REQUIRED)
ELSE(MSVC)
 FIND_PACKAGE(BZIP2 QUIET)
 FIND_PACKAGE(XZ QUIET)
 FIND_PACKAGE(ICU
COMPONENTS data i18n io uc)
 FIND_PACKAGE(CURL QUIET)
ENDIF(MSVC)

No issues taking that out, but why would I have make BZip2, XZ, and cURL
required on MSVC but not for any builds with gcc, even on Windows?

As for its support, I imagine you can use vcpkg to install it? Then you
don't have to mess with maintaining your own builds.

--Greg

>
>
> Gary Holmlund
>
>
>
> ___
>
> 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

Re: [sword-devel] Win32 FileMgr Subclass

[Greg Hellings]

On Mon, Jul 27, 2020 at 4:42 AM Troy A. Griffitts 
wrote:

> That crazy cmake line certain did work to configure a cross-compile.
> Someone needs to write that one down somewhere.
>
That line was taken from my RPM build script. Most of it is the standard
MinGW cross-compile macro used, then a few extra options were my specific
addons for Sword options.

> So, I've included  in filemgr.cpp and this seems to resolve this
> for mingw.  I get a bunch of .EXEs in utilities, so I think it worked.
>
Worked beautifully for me, as well.

> I'll commit, and then go back and be sure I haven't broken the build on
> BCB.  I trust Microsoft VC++ has wchar.h available so it shouldn't break
> with the new change.
>
> And now I think we have 3 Microsoft compilers building (I hesitate to say
> "working" until we get confirmation that app using pristine SWORD can
> indeed work in paths above UTF-8 single byte on Windows.
>
Fedora 30 and 31 cross-compile builds are here:
http://dl.thehellings.com/sword/ (Xiphos still uses Fedora 30 to build the
Windows versions due to needing GtkHTML). If any other Xiphos developers
want to do testing, or if BibleTime does any cross compiling from Fedora.
You can also find Xiphos installers building the latest Xiphos head against
this latest Sword head. I'm very far from any Windows machine I can use as
a test, so if anyone else has a Windows machine to test this on -
preferably one with a username that includes non-ASCII characters in it -
then feel free to grab that. If the BibleTime Windows builder (Gary?) wants
to generate builds against the latest SVN HEAD and test in the same manner,
it would be a huge help.

Yes, David, this is the very latest set of Sword Utility builds you can
currently find for Windows, as well. It represents the exact State Of The
Art SVN HEAD built for Windows. It will be the ones installed at the root
of the Xiphos binary instead of my standalone pack. And no, it's still not
officially supported. 😋

> Thanks for your help Greg and Tobias.  It was great to have support
> through this long dreaded task.
>
Thank you for the dedication to get it working and remove that patch point.

--Greg

> Happy Monday!
>
> Troy
>
>
> On 7/27/20 7:57 AM, Greg Hellings wrote:
>
> If you're missing dependencies you should be able to do, "dnf builddep
> mingw-sword".
>
> --Greg
>
> On Mon, Jul 27, 2020 at 1:33 AM Greg Hellings 
> wrote:
>
>>
>>
>> On Sun, Jul 26, 2020 at 4:56 PM Tobias Klein  wrote:
>>
>>> Hi Troy,
>>>
>>> The latest version builds successfully.
>>>
>>> I created a new intermediate release of sword-build-win32 for further
>>> testing on Windows:
>>>
>> It's still failing for me trying to do a cross-compile with MinGW:
>>
>> [  6%] Building CXX object CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj
>> /usr/bin/i686-w64-mingw32-g++ -DCLUCENE2 -DCURLAVAILABLE
>> -DCURLSFTPAVAILABLE -DEXCLUDEBZIP2 -DEXCLUDEXZ
>> -DGLOBCONFPATH=\"/usr/i686-w64-mingw32/sys-root/mingw/etc/sword.conf\"
>> -DUSEICUREGEX -DUSELUCENE -DU_USING_ICU_NAMESPACE -D_FTPLIB_NO_COMPAT
>> -D_ICU_ -Dsword_EXPORTS @CMakeFiles/sword.dir/includes_CXX.rsp -D_ICUSWORD_
>> -g3 -Wall -O0 -D_ICUSWORD_ -o CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj
>> -c /builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp
>> /builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp: In static member
>> function 'static int sword::FileMgr::createParent(const char*)':
>> /builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:439:5: error:
>> '_wmkdir' was not declared in this scope; did you mean 'mkdir'?
>>   439 | _wmkdir((const wchar_t *)utf8ToWChar(buf).getRawData());
>>   | ^~~
>>   | mkdir
>> make[2]: *** [CMakeFiles/sword.dir/build.make:282:
>> CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj] Error 1
>> make[2]: Leaving directory
>> '/builddir/build/BUILD/sword-1.8.900/build_win32'
>> make[1]: Leaving directory
>> '/builddir/build/BUILD/sword-1.8.900/build_win32'
>> make[1]: *** [CMakeFiles/Makefile2:277: CMakeFiles/sword.dir/all] Error 2
>> make: *** [Makefile:152: all] Error 2
>> make: Leaving directory '/builddir/build/BUILD/sword-1.8.900/build_win32'
>>
>> Commands to do the build, from Fedora 32, include this lovely invocation
>> of CMake from within a subfolder of the source (build_win32 for the above):
>> /usr/bin/cmake
>> -DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-mingw32.cmake
>> -DBUILD_SHARED_LIBS:BOOL=ON
>> -DSYSCONF_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mi

Re: [sword-devel] Win32 FileMgr Subclass

[Greg Hellings]

If you're missing dependencies you should be able to do, "dnf builddep
mingw-sword".

--Greg

On Mon, Jul 27, 2020 at 1:33 AM Greg Hellings 
wrote:

>
>
> On Sun, Jul 26, 2020 at 4:56 PM Tobias Klein  wrote:
>
>> Hi Troy,
>>
>> The latest version builds successfully.
>>
>> I created a new intermediate release of sword-build-win32 for further
>> testing on Windows:
>>
> It's still failing for me trying to do a cross-compile with MinGW:
>
> [  6%] Building CXX object CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj
> /usr/bin/i686-w64-mingw32-g++ -DCLUCENE2 -DCURLAVAILABLE
> -DCURLSFTPAVAILABLE -DEXCLUDEBZIP2 -DEXCLUDEXZ
> -DGLOBCONFPATH=\"/usr/i686-w64-mingw32/sys-root/mingw/etc/sword.conf\"
> -DUSEICUREGEX -DUSELUCENE -DU_USING_ICU_NAMESPACE -D_FTPLIB_NO_COMPAT
> -D_ICU_ -Dsword_EXPORTS @CMakeFiles/sword.dir/includes_CXX.rsp -D_ICUSWORD_
> -g3 -Wall -O0 -D_ICUSWORD_ -o CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj
> -c /builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp
> /builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp: In static member
> function 'static int sword::FileMgr::createParent(const char*)':
> /builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:439:5: error:
> '_wmkdir' was not declared in this scope; did you mean 'mkdir'?
>   439 | _wmkdir((const wchar_t *)utf8ToWChar(buf).getRawData());
>   | ^~~
>   | mkdir
> make[2]: *** [CMakeFiles/sword.dir/build.make:282:
> CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj] Error 1
> make[2]: Leaving directory
> '/builddir/build/BUILD/sword-1.8.900/build_win32'
> make[1]: Leaving directory
> '/builddir/build/BUILD/sword-1.8.900/build_win32'
> make[1]: *** [CMakeFiles/Makefile2:277: CMakeFiles/sword.dir/all] Error 2
> make: *** [Makefile:152: all] Error 2
> make: Leaving directory '/builddir/build/BUILD/sword-1.8.900/build_win32'
>
> Commands to do the build, from Fedora 32, include this lovely invocation
> of CMake from within a subfolder of the source (build_win32 for the above):
> /usr/bin/cmake
> -DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-mingw32.cmake
> -DBUILD_SHARED_LIBS:BOOL=ON
> -DSYSCONF_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/etc
> -DSHARE_INSTALL_PREFIX:PATH=/usr/i686-w64-mingw32/sys-root/mingw/share
> -DCMAKE_INSTALL_PREFIX:PATH=/usr/i686-w64-mingw32/sys-root/mingw
> -DCMAKE_INSTALL_LIBDIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/lib
> -DICU_CONFIG_BIN_PATH=/usr/i686-w64-mingw32/sys-root/mingw/bin
> -DINCLUDE_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/include
> -DCMAKE_VERBOSE_MAKEFILE=ON -DLIBSWORD_LIBRARY_TYPE=Shared
> -DSWORD_BUILD_EXAMPLES=Yes -DCMAKE_BUILD_TYPE=Debug
> -DICU_CONFIG_OPTS=--noverify -DCROSS_COMPILE_MINGW32=TRUE ..
>
> Followed by
>
> make
>
> --Greg
>
>>
>> https://github.com/tobias-klein/sword-build-win32/releases/tag/v1.8.900-2020-07-26
>>
>> Best regards,
>> Tobias
>> On 7/26/20 8:37 PM, Troy A. Griffitts wrote:
>>
>> Thanks Tobias,
>>
>> I've made these updates and should have fixed the error in filemgr.cpp on
>> line 410. I appreciate the feedback.  Please update and try this out and
>> let me know.  Thanks for testing your compiler.
>>
>> Troy
>>
>>
>> On 7/26/20 8:25 PM, Tobias Klein wrote:
>>
>> To address the errors below I had to add the include for  both
>> in *src/mgr/filemgr.cpp* and in *src/modules/commons/zipmgr.cpp*.
>>
>> After that I'm getting the next error:
>>
>> 1>C:\Users\tobi\Dev\sword-build-win32\sword\src\mgr\filemgr.cpp(410):
>> error C2664: 'BOOL FindNextFileA(HANDLE,LPWIN32_FIND_DATAA)': cannot
>> convert argument 2 from 'WIN32_FIND_DATAW *' to 'LPWIN32_FIND_DATAA'
>> 1>C:\Users\tobi\Dev\sword-build-win32\sword\src\mgr\filemgr.cpp(410):
>> note: Types pointed to are unrelated; conversion requires reinterpret_cast,
>> C-style cast or function-style cast
>>
>> Best regards,
>> Tobias
>> On 7/26/20 4:44 PM, Troy A. Griffitts wrote:
>>
>> Can one of you guys try simply including  at the top of
>> filemgr.cpp and see if this fixes it for you?
>>
>>
>> On 7/26/20 4:01 PM, Tobias Klein wrote:
>>
>> I'm getting similar error messages with Visual Studio 2019. Note that I'm
>> also generating the make files via CMake.
>>
>> First couple of error messages:
>> 2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,2):
>> error C2065: 'WIN32_FIND_DATAW': undeclared identifier
>> 2>D:\a\sword-build