Re: [sword-devel] Tumbleweek Packages

2024-03-12 Thread 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

2024-03-09 Thread 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?

2023-12-15 Thread 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

2023-11-27 Thread 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?

2023-10-20 Thread 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

2023-10-05 Thread 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=markup
> > <
> https://svn.filezilla-project.org/filezilla/FileZilla3/trunk/src/engine/directorylistingparser.cpp?revision=10945=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, Greg Hellings wrote:
> > > Aaron,
> > >
> > > As

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

2023-10-02 Thread 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

2023-09-28 Thread 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=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
> > tossed. Likely at the SVN level, as I

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

2023-09-28 Thread 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 

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

2023-09-15 Thread 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?

2023-06-13 Thread 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

2023-04-17 Thread 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

2023-04-17 Thread 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

2023-04-13 Thread 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 shove in the right direction, I think I can figure it out.
>>&g

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

2023-04-13 Thread 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
>>
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://cross

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

2023-04-13 Thread 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

2023-03-18 Thread 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:
>>>
>>> I am very happy with this progress in y

Re: [sword-devel] CrossWire and git

2023-03-18 Thread 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

2023-03-18 Thread 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

2023-03-17 Thread 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/ChangeLog @sword-prelim
>>>> /trunk/lib/vcppmake/ @sword-prelim
>&g

Re: [sword-devel] CrossWire and git

2023-03-17 Thread 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.
>>>>
>>>> Cyril

Re: [sword-devel] CrossWire and git

2023-03-17 Thread 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 campaign and strong feeling to have the project on Git
>>> but there is no agreement or movement t

Re: [sword-devel] CrossWire and git

2023-03-17 Thread 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 harm for other combinations, just improve
>> current state.
>>
>> Zdenko
>>

Re: [sword-devel] Fwd: cmake patches

2023-03-17 Thread 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

2023-03-09 Thread 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

2023-01-21 Thread 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

2022-12-08 Thread 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(, 0, "KJVA", );
>
> 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

2022-11-26 Thread 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

2022-11-12 Thread 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

2022-11-12 Thread 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

2022-09-27 Thread 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

2022-08-21 Thread 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

2022-08-21 Thread 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

2022-08-21 Thread 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

2022-08-14 Thread 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)

2022-05-14 Thread 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)

2022-05-14 Thread 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

2022-01-29 Thread 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.

2022-01-15 Thread 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

2021-11-20 Thread 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

2021-11-07 Thread 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

2021-11-07 Thread 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

2021-10-29 Thread 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

2021-10-05 Thread 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
> 

Re: [sword-devel] Windows Development

2021-10-05 Thread 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 

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

2021-07-29 Thread 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

2021-07-19 Thread 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

2021-07-14 Thread 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

2021-05-20 Thread 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

2021-05-20 Thread 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

2021-05-20 Thread 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

2021-05-20 Thread 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

2021-05-15 Thread 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

2021-04-16 Thread 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_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

2021-03-28 Thread 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/=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/=imgp0163_groupshot.jpg
>
>
>
> https://crosswire.org/~scribe/pics/photo.jsp?l=/2002/0409_rome/2002-04-19_austria_to_cambridge/=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

2021-02-23 Thread 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

2021-02-05 Thread 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 wonderfully and deterministically in CI, so I guess that's a
> blessing.

Re: [sword-devel] InstallMgr Woes

2021-02-05 Thread 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 as expected, installmgr downloads the files
> then tries to write them and says it failed a

[sword-devel] InstallMgr Woes

2021-02-05 Thread 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

2021-01-27 Thread 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 ?

2021-01-18 Thread 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 ?

2021-01-05 Thread 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

2021-01-01 Thread 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

2021-01-01 Thread 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

2020-12-31 Thread 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?

2020-12-14 Thread 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

2020-12-10 Thread 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

2020-12-08 Thread 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?

2020-12-01 Thread 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

2020-11-17 Thread 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

2020-11-17 Thread 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

2020-11-14 Thread 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

2020-10-30 Thread 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

2020-10-28 Thread 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

2020-10-11 Thread 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

2020-10-11 Thread 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-interface to be
>> used by clients of class 'sword::SWModule'
>> [C:\bibletime-tmp\b6\sword-prefix\src\sword-build\buildtest.vcxproj]
>>

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

2020-10-11 Thread 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
> 

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

2020-10-04 Thread 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 

Re: [sword-devel] SWORD 1.9.0RC3 Available

2020-10-04 Thread 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

2020-10-03 Thread 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

2020-10-03 Thread 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

2020-10-02 Thread 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

2020-09-11 Thread 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

2020-09-11 Thread 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

2020-08-31 Thread 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

2020-07-27 Thread 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

2020-07-27 Thread 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/mingw/etc
>> -DSHARE_INSTALL_PREFIX:PATH=/usr/i686-w64-mingw32/sys-root/mingw/share
>> -DC

Re: [sword-devel] Win32 FileMgr Subclass

2020-07-26 Thread 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-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,19):
>> error C2146: syntax error: missing ';' before identifier 'fil

Re: [sword-devel] tests/testsuite/verseparsing-utf8

2020-07-26 Thread Greg Hellings
On Sun, Jul 26, 2020 at 10:34 AM Troy A. Griffitts 
wrote:

> So Greg,
>
> I learned about cmake a bit today :)
>
> Nice work on the build system.
>
> I checked out a clean copy from source control, built with cmake,
> proceeded into the tests/testsuite folder
>
> ran: ./runall.sh
>
> and sure enough, it failed for me.
>
> Went back and re-read your sword/cmake/README to figure out how to build
> with debug.  Turned that on, rebuild, and stepped through the code.
>
> The difference:
>
> autotools does not include bindings/flatapi.cpp by default in the lib
>
> cmake does.
>
> The flatapi bindings injects its own StringMgr into SWORD to allow you to
> implement your own toUpperUTF C function (this is really the only necessary
> method SWORD requires to support Unicode at a basic level).
>
Aha! I figured there must be a discrepancy I couldn't spot. I did the first
pass of the cmake system before I knew very much about autotools at all.
I've gleaned quite a bit more about it, since then, but hadn't managed to
tease out that difference. Thanks!

> This was overriding the ICUStringMgr that was injected because of the
> build defines.
>
> I've enhanced this "feature" of flatapi.cpp to only inject its own
> StringMgr if StringMgr::hasUTF8Support == false.  Now flatapi.cpp can be
> included in libsword.so
>
> Anyway, in summary, if you update and build again and run the tests, they
> should work now.  Again, well done on the cmake system!
>
Confirmed - everything builds and runs perfectly with a freshly updated
copy of trunk.

As an interesting sidenote, all of the parsing code is about twice as fast
now in the testsuite. The regular verseparsing test was running a little
over 60 seconds before and it's now down around 35! The UTF8 one is down
from a few seconds to 1 second flat.

One thing about the shell scripts that I've learned - you might be best to
include a "set -e" in some of them. And, if they include pipes, a "set -o
pipefail" - which can be combined into "set -e -o pipefail". This will
ensure that the shell scripts will actually error out if a command isn't
found or exits improperly. Not necessary and might not be applicable to all
tests. But could be worth a consideration. I've had some tests give weird
results because they failed to write a file early on, but the shell script
continued going (due to having wonky directory permissions after
accidentally doing a build as root) and left odd behaviors in the test
result. Editing my local copy to include the "set -e" caused the whole
thing to stop at the moment of the write failure and made the test easier
to diagnose, instead of losing that output somewhere else.

--Greg

> Troy
>
>
> On 7/26/20 2:47 PM, Greg Hellings wrote:
>
>
>
> On Sun, Jul 26, 2020 at 7:29 AM Troy A. Griffitts 
> wrote:
>
>> Greg, what's the output, or at least the couple lines of output from your
>> failed unit test?  It might help.  When I saw your note, I had suspected it
>> was because of something I had installed on my machine that was enabling
>> the test to pass (/etc/sword.conf) or something.  But I've removed what I
>> thought might be helping and I still pass all unit tests here on F32 using
>> autotools to build.
>>
> Oh yes, that's probably relevant!
>
> $ ./runtest.sh verseparsing-utf8
> Script failed at: (- bad output; + should have been)
> --- verseparsing-utf8.try 2020-07-26 08:45:12.077941691 -0400
> +++ verseparsing-utf8.good 2020-07-26 08:43:25.621662269 -0400
> @@ -1,7 +1,7 @@
> -Matthäus 2:3-12 de KJV ge 1:
> -Römer 2:13 de KJV ge 1:
> -Matthäus 1:2-Röm 3:13 de KJV ge 1:
> -1. Könige 2 de KJV ge 1:
> -1. Könige - 2. Könige; Markus 1:1; Matthäus 2:1; Matthäus; 1.Kön de KJV
> ge 1: Markus 1:1
> -1. Könige - 2. Könige; Markus 1:1; Matthäus 2:1; Matthäus; 1.Kön-2.Kön;I
> Kings-Matthäus de KJV ge 1: Markus 1:1; 1. K�nige 1:1-Markus 1:1
> -Maleachi 1:1 - Matthäus 2:1 de KJV ge 1: Maleachi 1:1-Offenbarung 22:21
> +Matthäus 2:3-12 de KJV ge 1: Matthäus 2:3-Matthäus 2:12
> +Römer 2:13 de KJV ge 1: Römer 2:13
> +Matthäus 1:2-Röm 3:13 de KJV ge 1: Matthäus 1:2-Römer 3:13
> +1. Könige 2 de KJV ge 1: 1. Könige 2:1-1. Könige 2:46
> +1. Könige - 2. Könige; Markus 1:1; Matthäus 2:1; Matthäus; 1.Kön de KJV
> ge 1: 1. Könige 1:1-2. Könige 25:30; Markus 1:1; Matthäus 2:1; Matthäus
> 1:1-Matthäus 28:20; 1. Könige 1:1-1. Könige 22:53
> +1. Könige - 2. Könige; Markus 1:1; Matthäus 2:1; Matthäus; 1.Kön-2.Kön;I
> Kings-Matthäus de KJV ge 1: 1. Könige 1:1-2. Könige 25:30; Markus 1:1;
> Matthäus 2:1; Matthäus 1:1-Matthäus 28:20; 1. Könige 1:1-2. Könige 25:30;
> 1. Könige 1:1-Matthäus 28:20
> +Maleachi 1:1 - Matthäus 2:1 de KJV ge 1: Maleachi 1:1-Matthäus 2:1
>
> It appe

Re: [sword-devel] Win32 FileMgr Subclass

2020-07-26 Thread Greg Hellings
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-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,19):
> error C2146: syntax error: missing ';' before identifier 'fileData'
>
> 2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(395,19):
> error C2065: 'fileData': undeclared identifier
>
> 2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,2):
> error C2065: 'HANDLE': undeclared identifier
>
> 2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,9):
> error C2146: syntax error: missing ';' before identifier 'findIterator'
> 2>D:\a\sword-build-win32\sword-build-win32\sword\src\mgr\filemgr.cpp(398,9):
> error C2065: 'findIterator': undeclared identifier
> 2>D:\a\sword-build-w

Re: [sword-devel] Win32 FileMgr Subclass

2020-07-26 Thread Greg Hellings
On Sun, Jul 26, 2020 at 6:42 AM Troy A. Griffitts 
wrote:

> I've just committed the last bit for fixing the WIN32 Unicode issues.  If
> anyone can try compiling and running Xiphos without the Xiphos patch or any
> other projects for Windows, and let me know if things work for them in
> folders which include Unicode character, I would appreciate it.  I've
> tested BibleCS and it now works with a SWORD_PATH defined to /books/χαρις.
> I've tested using and installing modules in this configuration and believe
> all the bugs are squashed, but I would love confirmation from other
> projects.
>
> Thanks for any feedback,
>
> Troy
>
During cross-compile I'm getting the following errors:

[  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 std::vector
sword::FileMgr::getDirList(const char*, bool, bool)':
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:395:2: error:
'WIN32_FIND_DATAW' was not declared in this scope
  395 |  WIN32_FIND_DATAW fileData;
  |  ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:398:2: error:
'HANDLE' was not declared in this scope
  398 |  HANDLE findIterator = FindFirstFileW(wcharPath, );
  |  ^~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:399:6: error:
'findIterator' was not declared in this scope
  399 |  if (findIterator != INVALID_HANDLE_VALUE) {
  |  ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:399:22: error:
'INVALID_HANDLE_VALUE' was not declared in this scope
  399 |  if (findIterator != INVALID_HANDLE_VALUE) {
  |  ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:401:35: error:
'fileData' was not declared in this scope
  401 |SWBuf dirEntName = wcharToUTF8(fileData.cFileName);
  |   ^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:405:49: error:
'FILE_ATTRIBUTE_DIRECTORY' was not declared in this scope
  405 | i.isDirectory = fileData.dwFileAttributes &
FILE_ATTRIBUTE_DIRECTORY;
  |
^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:409:40: error:
'fileData' was not declared in this scope
  409 |   } while (FindNextFile(findIterator, ) != 0);
  |^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:409:12: error:
'FindNextFile' was not declared in this scope
  409 |   } while (FindNextFile(findIterator, ) != 0);
  |^~~~
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:410:3: error:
'FindClose' was not declared in this scope; did you mean '_findclose'?
  410 |   FindClose(findIterator);
  |   ^
  |   _findclose
/builddir/build/BUILD/sword-1.8.900/src/mgr/filemgr.cpp:397:17: warning:
unused variable 'wcharPath' [-Wunused-variable]
  397 |  const wchar_t *wcharPath = (const wchar_t *)wcharBuf.getRawData();
  | ^
/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:436:5: error:
'_wmkdir' was not declared in this scope; did you mean 'mkdir'?
  436 | _wmkdir((const wchar_t *)utf8ToWChar(buf).getRawData());
  | ^~~
  | mkdir
make[2]: *** [CMakeFiles/sword.dir/build.make:283:
CMakeFiles/sword.dir/src/mgr/filemgr.cpp.obj] Error 1

I'm assuming there's a new package or macro I need to define? On my system
the WIN32_FIND_DATAW struct is defined in both minwinbase.h and shtypes.h.
I'm building with MinGW which might have a different header structure than
your compilers, if you're using Borland?

--Greg

>
> On 7/20/20 7:18 PM, Greg Hellings wrote:
>
> Sorry for the previous blank email - user error when I tried to reply:
>
> On Sun, Jul 19, 2020 at 2:40 PM Tobias Klein  wrote:
>
>> Thanks for giving me the background on this, Karl! I appreciate it!
>>
>> Is Xiphos the only frontend that has been patching Sword for this
>> purpose? Then I suppose all other frontends suffer from this issue, huh?
>>
>
> When I first encountered this patch in Xiphos I tested with BibleTime and
> The Sword Project for Windows and both of them do crash under these
> circumstances.
>
> Yes, other toolkits such as Qt

Re: [sword-devel] tests/testsuite/verseparsing-utf8

2020-07-26 Thread Greg Hellings
On Sun, Jul 26, 2020 at 7:29 AM Troy A. Griffitts 
wrote:

> Greg, what's the output, or at least the couple lines of output from your
> failed unit test?  It might help.  When I saw your note, I had suspected it
> was because of something I had installed on my machine that was enabling
> the test to pass (/etc/sword.conf) or something.  But I've removed what I
> thought might be helping and I still pass all unit tests here on F32 using
> autotools to build.
>
Oh yes, that's probably relevant!

$ ./runtest.sh verseparsing-utf8
Script failed at: (- bad output; + should have been)
--- verseparsing-utf8.try 2020-07-26 08:45:12.077941691 -0400
+++ verseparsing-utf8.good 2020-07-26 08:43:25.621662269 -0400
@@ -1,7 +1,7 @@
-Matthäus 2:3-12 de KJV ge 1:
-Römer 2:13 de KJV ge 1:
-Matthäus 1:2-Röm 3:13 de KJV ge 1:
-1. Könige 2 de KJV ge 1:
-1. Könige - 2. Könige; Markus 1:1; Matthäus 2:1; Matthäus; 1.Kön de KJV ge
1: Markus 1:1
-1. Könige - 2. Könige; Markus 1:1; Matthäus 2:1; Matthäus; 1.Kön-2.Kön;I
Kings-Matthäus de KJV ge 1: Markus 1:1; 1. K�nige 1:1-Markus 1:1
-Maleachi 1:1 - Matthäus 2:1 de KJV ge 1: Maleachi 1:1-Offenbarung 22:21
+Matthäus 2:3-12 de KJV ge 1: Matthäus 2:3-Matthäus 2:12
+Römer 2:13 de KJV ge 1: Römer 2:13
+Matthäus 1:2-Röm 3:13 de KJV ge 1: Matthäus 1:2-Römer 3:13
+1. Könige 2 de KJV ge 1: 1. Könige 2:1-1. Könige 2:46
+1. Könige - 2. Könige; Markus 1:1; Matthäus 2:1; Matthäus; 1.Kön de KJV ge
1: 1. Könige 1:1-2. Könige 25:30; Markus 1:1; Matthäus 2:1; Matthäus
1:1-Matthäus 28:20; 1. Könige 1:1-1. Könige 22:53
+1. Könige - 2. Könige; Markus 1:1; Matthäus 2:1; Matthäus; 1.Kön-2.Kön;I
Kings-Matthäus de KJV ge 1: 1. Könige 1:1-2. Könige 25:30; Markus 1:1;
Matthäus 2:1; Matthäus 1:1-Matthäus 28:20; 1. Könige 1:1-2. Könige 25:30;
1. Könige 1:1-Matthäus 28:20
+Maleachi 1:1 - Matthäus 2:1 de KJV ge 1: Maleachi 1:1-Matthäus 2:1

It appears the test isn't even trying to parse the inputs? It's certainly
not giving any output to make it look like it is.

--Greg

> Hope we can figure it out,
>
> Troy
>
>
> On 7/25/20 5:46 AM, Greg Hellings wrote:
>
> Quick question - maybe a longer answer. Mostly for Troy, as you're
> probably the only one familiar with this code:
>
> I'm trying to get the testsuit working in the CMake build. Things seem to
> be going great. I can get 13/14 tests passing. But I've had a long-nagging
> issue with getting verparsing-utf8 to pass in the CMake build. I'm building
> with -D_ICU_ throughout, so it's not that the flag is missing. I'm also not
> getting  passing results out of the autotools build, so this isn't just a
> problem with CMake - although in the past I've had systems where I could
> get the autotools build to work properly but the CMake one would not.
>
> I don't know enough about running a C++ debugger to dig into where the
> problem lives. The verseparsing-utf8 is clear that the library needs ICU in
> order for it to work, and it shows up in the list of linked libraries off
> the sword library and in the compile flags.
>
> I assume the tests are still working for you? If so, any hints I can use
> to track down why it's not working for me?
>
> --Greg
>
> ___
> sword-devel mailing list: 
> sword-devel@crosswire.orghttp://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

[sword-devel] tests/testsuite/verseparsing-utf8

2020-07-24 Thread Greg Hellings
Quick question - maybe a longer answer. Mostly for Troy, as you're probably
the only one familiar with this code:

I'm trying to get the testsuit working in the CMake build. Things seem to
be going great. I can get 13/14 tests passing. But I've had a long-nagging
issue with getting verparsing-utf8 to pass in the CMake build. I'm building
with -D_ICU_ throughout, so it's not that the flag is missing. I'm also not
getting  passing results out of the autotools build, so this isn't just a
problem with CMake - although in the past I've had systems where I could
get the autotools build to work properly but the CMake one would not.

I don't know enough about running a C++ debugger to dig into where the
problem lives. The verseparsing-utf8 is clear that the library needs ICU in
order for it to work, and it shows up in the list of linked libraries off
the sword library and in the compile flags.

I assume the tests are still working for you? If so, any hints I can use to
track down why it's not working for me?

--Greg
___
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] Not user-friendly behavior in commentaries (should be continuous)

2020-07-23 Thread Greg Hellings
On Thu, Jul 23, 2020 at 12:44 PM yvand  wrote:

> Thanks Greg for your quick reply with explanation!
>
> I thought there was a bug and "link entries" were not taken into
> consideration, when using osis2mod. Is there a simple way to test if a
> commentary module contains link entries? I tried with mod2imp to export
> FreCJE but it only shows verses with attached commentary ($$$Genesis 1:2
> is missing for instance). Maybe I misunderstood "link entries"
> functionality...
>
> I believe it worked as expected in the past (at least with Xiphos), but
> maybe I am wrong.
>

If you want to dig out an archival version of the library and apps, it
would be wonderful to see if this is the case.


> Unfortunately I am not familiar with C/C++ and with the sword engine, so
> I am not able to offer you a patch.
>

No, but you can definitely help define the desired behavior.


> I understand the issues you pointed and it doesn't seem easy. Currently,
> there are still questions, for instance: how will operate the engine if
> there are multiple commentaries starting with Gen.1.1 in the source, like :
>
> > ...
> > ...
> > ...
> I guess I will now give up for this feature.
>

By no means do I intend to influence you to give up! There is still plenty
you can help do. First and foremost would be to wrap this up into a
detailed but concise definition with the reproducers you've mentioned above
and file it with the front-ends in their bug trackers. That's a good place
for getting front end changes and discussing them with the developers of
those apps. If one of them investigates and finds out that this is
something that needs to change in the engine or in the imports, then they
can work in a more technical and detailed way with the library developers
on which part needs to change and how.

Please, don't take this as discouragement. A complex issue like this, which
possibly represents a regression or an unintentional design change doesn't
just have a quick fix that someone is likely to toss out in a few days of
volunteer work. You've done a good job bringing up the difficulties you've
faced. If we can get this into a place more visible than email (like a bug
tracker), then we can make sure it doesn't fall out of peoples' minds.

--Greg

>
> --yvand
>
> ___
> 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] Not user-friendly behavior in commentaries (should be continuous)

2020-07-23 Thread Greg Hellings
On Thu, Jul 23, 2020 at 11:44 AM yvand  wrote:

> Dear all,
>
> I am disappointed, because the issue still persists and nobody confirmed
> the bug. Although I already send to the mailing the source of the module
> FreCJE as asked and John Dudeck recently revived the issue with no
> success. Below is again my problem :
>
> I use OSIS commentary for "DayByDay" commentary. The module is called
> FreCJE (for French Chaque jour les Écritures) and is available in the
> main repository of Crosswire. Commentaries cover half or full part of a
> Bible chapter. For instance, here are the first commentaries :
>
> >  > annotateRef="Gen.1.1-Gen.1.19">...
> >  > annotateRef="Gen.1.20-Gen.1.31">...
> >  > annotateRef="Gen.2.1-Gen.2.14">...
> >  > annotateRef="Gen.2.15-Gen.2.25">...
> >  > annotateRef="Gen.3.1-Gen.3.13">...
> >  > annotateRef="Gen.3.14-Gen.3.24">...
> > etc.
> BUT when I use frontends, commentaries are ONLY shown when you are at
> the FIRST verse mentioned in the annotateRef. So Gen.1.1, Gen.1.20,
> Gen.2.1, Gen.2.15… will have a commentary, but not Gen.1.2, Gen.1.3…
> There seems to be no link entries for other verses as expected.
>
> I believe it worked fine years ago, but currently it seems broken :-(
>
> You can access and download the source of FreCJE using this link:
> https://yapper.fr/~yvand/frecje_v2.0.zip (OSIS file)
>
> Can you confirm the bug?


This is more of a UX design decision than a bug, specifically. But that
doesn't mean it can't be changed.

Or is it a .conf issue or something else? What
> can I do?
>

Offer a proposed patch to one or all of the front ends to change that UX
behavior.

One consideration for it needs to be - what do you do if there are
overlapping annotations? What do you do if one entry is for Genesis 1:1-2:2
and then there are also passages for Genesis 1:1, Genesis 1:2, etc? Are
those both displayed at the same time? How do they look? How do you show
that they're different, and only one portion of them changes?

The problem is more of a design one than a technical one. Once all the
logic of the design is hammered out, someone will need to do the actual
code changes for it. It's not likely to be super tricky. Not too much of
the Sword or display code is opaque and inscrutable. But someone will still
need to put in the effort to make it happen.

So, the fastest way to get a solution, is to offer a fully formed proposal
of exactly how things should change and look and then offer changes to the
code that make it happen. If you don't have the skills for one or either of
those sides, then you'll have to wait for a volunteer to put in the work to
get them done.

--Greg

>
> Thanks in advance for any help.
>
> Best regards,
>
> --yvand
>
>
> >
> > Yeah, you very much don't want to do that. The best plan is to send
> > the file to someone (Troy or DM or whoever owns osis2mod) or post it
> > publicly here so they can verify if it's the utility, the engine, or
> > front ends.
> >
> > Everything you've said, so far, sounds like it's just a front end
> > display problem and not a module or engine thing. But that can't be
> > guaranteed until someone looks closely at the output of the
> > appropriate tools to see what exactly is ending up in the module.
> >
> > --Greg
> ___
> 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

2020-07-20 Thread Greg Hellings
Sorry for the previous blank email - user error when I tried to reply:

On Sun, Jul 19, 2020 at 2:40 PM Tobias Klein  wrote:

> Thanks for giving me the background on this, Karl! I appreciate it!
>
> Is Xiphos the only frontend that has been patching Sword for this purpose?
> Then I suppose all other frontends suffer from this issue, huh?
>

When I first encountered this patch in Xiphos I tested with BibleTime and
The Sword Project for Windows and both of them do crash under these
circumstances.

Yes, other toolkits such as Qt do have wrappers for this shortcoming
already, but none of the other front ends I've worked with have bothered to
put in the effort to produce a patched version of Sword to fix the crash.

--Greg
___
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

2020-07-20 Thread Greg Hellings
On Sun, Jul 19, 2020 at 2:40 PM Tobias Klein  wrote:

> Thanks for giving me the background on this, Karl! I appreciate it!
>
> Is Xiphos the only frontend that has been patching Sword for this purpose?
> Then I suppose all other frontends suffer from this issue, huh?
>
> Thanks for putting in the work to make Sword behave well with non-ascii
> path names!
>
>
>
> Best regards,
> Tobias
>
>
>
> *From: *Karl Kleinpaste 
> *Sent: *Sonntag, 19. Juli 2020 15:23
> *To: *SWORD Developers' Collaboration Forum 
> *Subject: *Re: [sword-devel] Win32 FileMgr Subclass
>
>
>
> On 7/18/20 1:53 PM, Tobias Klein wrote:
>
> No, I have not tested my code properly with non-ascii characters in paths
> / file names.
>
>
> The original cause for the Xiphos patch to Sword was because, 11 years ago
> when we introduced the Win32 port, as GnomeSword was renamed Xiphos, one of
> our first new Windows users was a fellow in Spain who wanted to review it.
> His name was Reuvén, and that was his login name on his Windows machine.
> So of course the path C:\Users\Reuvén was involved, and that 'é' is what
> killed us.
>
> What dies here is Sword itself.  Xiphos was fine, being already based on
> glib, but Sword's collapse came as soon as Xiphos made its first filesystem
> call.  The patch glib-ifies Sword, where glib works rather hard at hiding
> the UTF16 boundary from the application.
>
>
> ___
> 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

2020-07-18 Thread Greg Hellings
For Xiphos we use the MinGW compiler and library from Xiphos. You should be
able to grab them via Cygwin as well, if you prefer? I haven't run actual
Windows in a life age to know, though.

Greg

On Sat, Jul 18, 2020, 16:57 Tobias Klein  wrote:

> I'm using the Visual Studio compilers. All modern VS compilers are
> available via GitHub Actions! I'm most of the time letting GitHub build my
> Windows binaries, but I do have Visual Studio 2017 installed in a Windows
> 10 VM for debugging.
>
> Tobias
>
> Am 18. Juli 2020 22:53:23 schrieb "Troy A. Griffitts" <
> scr...@crosswire.org>:
>
>> OK guys, another question.
>>
>> What exactly does your build environment look like these days for win32?
>> I just tried to boot one of my old Windows VMs with
>> Borland/Inprise/Embarcadero build tools and it is in such a sad state, I am
>> not even going to attempt to recover that world right now.  I'd rather
>> support your build environments.  What are you using? cygwin? MicrosoftVS?
>> Something else?
>>
>> Troy
>>
>>
>> On 7/18/20 7:53 PM, Tobias Klein wrote:
>>
>> Thanks Greg & Troy for pointing out these potential issues. No, I have
>> not tested my code properly with non-ascii characters in paths / file names.
>>
>>
>>
>> I suppose this would particularly be an issue if the username has certain
>> characters that cause issues? (applicable for the ~/.sword directory). And
>> then also, when arbitrary folders are added to SWMgr?!
>>
>>
>>
>> I’ll do some testing in this area!
>>
>>
>>
>> I wonder whether libraries like Qt or Boost have solved these kind of
>> issues somehow …
>>
>>
>>
>> Best regards,
>> Tobias
>>
>>
>>
>> *From: *Greg Hellings 
>> *Sent: *Samstag, 18. Juli 2020 15:58
>> *To: *SWORD Developers' Collaboration Forum 
>> *Subject: *Re: [sword-devel] Win32 FileMgr Subclass
>>
>>
>>
>> Tobias,
>>
>>
>>
>> Has this been tested with file paths that contain characters outside of
>> the basic ASCII code range? That's where current Sword fails. Not in
>> fetching the data for the paths themselves, but the actual calls to fopen
>> and friends, on Windows, do not understand non ASCII data.
>>
>>
>>
>> It looks like your code would suffer similar to other Sword code, which
>> eventually passes through the library's fopen calls.
>>
>>
>>
>> On Sat, Jul 18, 2020, 08:24 Tobias Klein  wrote:
>>
>> Maybe not a full-fledged FileMgr class, but at least everything I need in
>> Ezra Project at the moment:
>>
>>
>> https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.hpp
>>
>>
>>
>>
>> https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.cpp
>>
>>
>>
>> It works on Windows, macOS and Linux.
>>
>>
>>
>> Best regards,
>> Tobias
>>
>>
>>
>> *From: *Troy A. Griffitts 
>> *Sent: *Samstag, 18. Juli 2020 14:42
>> *To: *SWORD Developers' Collaboration Forum 
>> *Subject: *[sword-devel] Win32 FileMgr Subclass
>>
>>
>>
>> I know Greg has sent me a link to the patch you guys apply to get Xiphos
>>
>> to run well on Win32, but I have searched through all my past emails
>>
>> with every relevant term I can thing of, and still can't find it.  I am
>>
>> sorry,  Could you possibly sent that again? I think you guys were using
>>
>> glib routines.  If possible, I'd like to include something in SWORD more
>>
>> generic, possibly using native Win32 calls.  I've done something similar
>>
>> for a couple projects in the past and need to find all that code.  The
>>
>> only one I keep thinking of off the top of my head is swordreader's
>>
>> wince layer, which I believe is similar to win32 methods, but might need
>>
>> some adapting.
>>
>>
>>
>> http://crosswire.org/svn/swordreader/trunk/src/Dll1/winceSword/src/
>>
>>
>>
>> The Xiphos code would be very helpful, if not just for finding
>>
>> everyplace you needed to make a modification.  Thanks for any help
>>
>> finding it,
>>
>>
>>
>> Troy
>>
>>
>>
>>
>>
>> ___
>>
>> sword-devel mailing list: sword-devel@crosswire.org
>>
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>
>&

Re: [sword-devel] Win32 FileMgr Subclass

2020-07-18 Thread Greg Hellings
Tobias,

Has this been tested with file paths that contain characters outside of the
basic ASCII code range? That's where current Sword fails. Not in fetching
the data for the paths themselves, but the actual calls to fopen and
friends, on Windows, do not understand non ASCII data.

It looks like your code would suffer similar to other Sword code, which
eventually passes through the library's fopen calls.

On Sat, Jul 18, 2020, 08:24 Tobias Klein  wrote:

> Maybe not a full-fledged FileMgr class, but at least everything I need in
> Ezra Project at the moment:
>
>
> https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.hpp
>
>
>
>
> https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/file_system_helper.cpp
>
>
>
> It works on Windows, macOS and Linux.
>
>
>
> Best regards,
> Tobias
>
>
>
> *From: *Troy A. Griffitts 
> *Sent: *Samstag, 18. Juli 2020 14:42
> *To: *SWORD Developers' Collaboration Forum 
> *Subject: *[sword-devel] Win32 FileMgr Subclass
>
>
>
> I know Greg has sent me a link to the patch you guys apply to get Xiphos
>
> to run well on Win32, but I have searched through all my past emails
>
> with every relevant term I can thing of, and still can't find it.  I am
>
> sorry,  Could you possibly sent that again? I think you guys were using
>
> glib routines.  If possible, I'd like to include something in SWORD more
>
> generic, possibly using native Win32 calls.  I've done something similar
>
> for a couple projects in the past and need to find all that code.  The
>
> only one I keep thinking of off the top of my head is swordreader's
>
> wince layer, which I believe is similar to win32 methods, but might need
>
> some adapting.
>
>
>
> http://crosswire.org/svn/swordreader/trunk/src/Dll1/winceSword/src/
>
>
>
> The Xiphos code would be very helpful, if not just for finding
>
> everyplace you needed to make a modification.  Thanks for any help
>
> finding it,
>
>
>
> Troy
>
>
>
>
>
> ___
>
> sword-devel mailing list: sword-devel@crosswire.org
>
> http://www.crosswire.org/mailman/listinfo/sword-devel
>
> Instructions to unsubscribe/change your settings at above page
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Win32 FileMgr Subclass

2020-07-18 Thread Greg Hellings
On Sat, Jul 18, 2020, 07:42 Troy A. Griffitts  wrote:

> I know Greg has sent me a link to the patch you guys apply to get Xiphos
> to run well on Win32, but I have searched through all my past emails
> with every relevant term I can thing of, and still can't find it.  I am
> sorry,  Could you possibly sent that again? I think you guys were using
> glib routines.  If possible, I'd like to include something in SWORD more
> generic, possibly using native Win32 calls.  I've done something similar
> for a couple projects in the past and need to find all that code.  The
> only one I keep thinking of off the top of my head is swordreader's
> wince layer, which I believe is similar to win32 methods, but might need
> some adapting.
>

Here is the existing patch which applies pretty cleanly on 1.8.1.
https://src.fedoraproject.org/rpms/mingw-sword/blob/master/f/xiphos_sword.patch

I attempted, once, to wrap the Sword calls the way you propose, but at the
time my knowledge of UTF-16 and file pointers was woefully inadequate to
get it right. The Windows native file calls only speak UTF-16, while their
standard "open" methods only speak CP-1252.

Thanks for tackling this!

--Greg


> http://crosswire.org/svn/swordreader/trunk/src/Dll1/winceSword/src/
>
> The Xiphos code would be very helpful, if not just for finding
> everyplace you needed to make a modification.  Thanks for any help
> finding it,
>
> Troy
>
>
> ___
> 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

  1   2   3   4   5   6   7   8   9   10   >