Re: [sword-devel] SWORD, diatheke and a self-closing OSIS note element...

2020-06-20 Thread David Haslam 
Thanks, Peter.

Created API-241 as requested.
Unable to assign your username to the issue. You weren’t listed.

I will add something to the wiki page OSIS 211 CR.

Grab a copy of the HunUj module for testing before it’s updated.

David

Sent from ProtonMail Mobile

On Sat, Jun 20, 2020 at 18:16, ref...@gmx.net  wrote:

> Fixing the filter should be done to avoid the picture, and I can likely do 
> that asap, particularly in light of Troy's announcement. Please though file a 
> bug against the engine (not diatheke) , the likely source of the problem is 
> in the osisplain filter. And file a further bug against the scheme, which 
> will stay until that is fixed even once the engine does not produce bad 
> output anymore
>
> Thanks
>
> Peter
>
> Sent from my mobile. Please forgive shortness, typos and weird autocorrects.
>
>  Original Message 
> Subject: Re: [sword-devel] SWORD, diatheke and a self-closing OSIS note 
> element...
> From: Greg Hellings
> To: David Haslam ,SWORD Developers' Collaboration Forum
> CC:
>
>> I believe that we can mandate, through the schema, that a tag not be self 
>> closing. If the schema really permits that, it can be prevented at that 
>> level if deemed necessary. If it's not appropriate to prevent an empty note, 
>> then we need to update the filter to at least close the brackets when it's a 
>> self closing tag.
>>
>> On Fri, Jun 19, 2020, 07:50 David Haslam  wrote:
>>
>>> Hi everyone,
>>>
>>> Today I was testing the updated HunUj module in CrossWire Beta and I came 
>>> across an unusual anomaly in OSIS that almost escaped being detected.
>>>
>>> If one gives the following command:
>>>
>>> diatheke -b HunUj -b plain -k Gen.32.2
>>>
>>> the output is
>>>
>>> Genesis 32:2: Jákób is útnak indult, és találkoztak vele Isten angyalai. [
>>> (HunUj)
>>>
>>> "What's odd about that?" one might ask
>>>
>>> It's perfectly normal but for the unepected [ at the end of the verse text.
>>>
>>> Upon inspection using osis2mod, the verse text ends with an OSIS note...
>>>
>>> $$$Genesis 32:2
>>> Jákób is útnak indult, és találkoztak vele Isten angyalai.>> osisID="Gen.32.2!crossReference.a" osisRef="Gen.32.2" 
>>> type="crossReference"/>
>>>
>>> Observe closely, the OSIS note element is self-closing and therefore 
>>> contains no note text or reference element.
>>>
>>> Now imagine the module developer getting ready to submit the module. He 
>>> runs the OSIS through XML syntax check and then proceeds to validate it to 
>>> the OSIS schema. It passes both. The self-closing note element is perfectly 
>>> valid OSIS even though it's semantically deficient.
>>>
>>> Had I not noticed the anomalous [ in the diatheke output, this source text 
>>> anomaly would have remained undetected.
>>>
>>> So the question for SWORD developers is this: Why does diatheke plain text 
>>> output include the ] ?
>>>
>>> I'm not complaining. I'm glad that it behaved in this way, otherwise the 
>>> OSIS anomaly would have completely passed us by.
>>> There are no other similar anomalies elsewhere in the HunUj module.
>>>
>>> I'd just like to understand better how exactly diatheke parses this 
>>> peculiar construct and thus give the otherwise unexpected ]
>>>
>>> The textual bug is very interesting to me, because I can think of no 
>>> readily available utility whereby it could have been flagged up in the OSIS 
>>> file. If you know of such an XML tool, we'd all benefit from you sharing 
>>> your wisdom and experience.
>>>
>>> Best regards,
>>>
>>> David
>>>
>>> Sent with ProtonMail Secure Email.
>>>
>>> ___
>>> 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] Bishop 1.4.0 and SWORD Utility Modules

2020-06-20 Thread Jaak Ristioja 
On 21.03.20 12:37, Cyrille wrote:
> @Troy, we have to figure out how to automate the translation with Pootle
> or something else like transifex (nice tool but not free).

According to the FAQ at the end of https://www.transifex.com/pricing/
Transifex is free for open source projects which "have no funding,
revenue and/or commercialization model". See the FAQ for details.

BibleTime is quite successfully using Transifex.

J
___
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] NA28 shows no verses

2020-06-20 Thread Jaak Ristioja 
On 02.06.20 03:22, Greg Hellings wrote:
> On Mon, Jun 1, 2020 at 3:57 PM Troy A. Griffitts 
> wrote:
>> Some of this delay is my fault.  The "unique per user" key recognition was
>> added to SWORD about 8 months or so and we haven't released a new official
>> stable branch yet.  trunk is pretty stable and I use it for Bishop
>> releases, but other frontends have policies to only use official stable
>> branch releases.  I must be remembering wrong, but I thought I heard
>> Bibletime reported it was working ok in their latest release so I thought
>> they were using trunk.
>>
> Bibletime compiles against trunk, I'm sure, as part of its testing matrix.
> But I don't believe it uses trunk for releases. I'm fairly sure your work
> on Bishop is the only one that leverages unreleased code other than the
> couple of immediately necessary patches that Karl mentioned I grabbed for
> Fedora repos.

Distros usually package a specific version of Sword, and we want
BibleTime to support at least the latest stable version of Sword and not
rely on features in SVN trunk. This also helps packagers. We might
consider using SVN trunk for snaps, flatpaks, Windows and OS X where we
have no other options but control the entire stack. In my opinion,
bundling libraries with BibleTime (binaries or source) is generally a
bad idea for multiple reasons, mostly related to packaging,
compatibility and security.

J
___
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] [PATCH] Fix ICU checking without icu-config

2020-06-20 Thread Adrian Bunk 
On Sat, Jun 20, 2020 at 03:47:13PM -0400, Karl Kleinpaste wrote:
>...
> Fedora handles this problem /just fine/:
> 
> $ grep libicu-devel /var/log/rpmpkgs
> libicu-devel-63.2-3.fc31.i686.rpm
> libicu-devel-63.2-3.fc31.x86_64.rpm
> $ ls -l /usr/bin/icu-config*
> -rwxr-xr-x 1 root root   205 May 28  2018 /usr/bin/icu-config
> -rwxr-xr-x 1 root root 22011 Jul 25  2019 /usr/bin/icu-config-32
> -rwxr-xr-x 1 root root 22019 Jul 25  2019 /usr/bin/icu-config-64
> $ rpm -qf /usr/bin/icu-config*
> libicu-devel-63.2-3.fc31.x86_64
> libicu-devel-63.2-3.fc31.i686
> libicu-devel-63.2-3.fc31.i686
> libicu-devel-63.2-3.fc31.x86_64
> 
> The main script is a 32/64-bit selector script which then calls the
> right arch-specific binary, and the relevant symlinks are all correct in
> /usr/lib{,64}.
>...

What is "the right arch-specific binary" when I am building on x86_64?
icu-config automatically using icu-config-64 is right most of the time,
but not when building on x86_64 for i686.

On Debian/Ubuntu I can just install the i686 version of pkg-config,
and this will then give the correct i686 output.

Nowadays pkg-config is the standard tool for this kind of information,
the Fedora libicu-devel package is shipping a pkg-config file since 2006.

cu
Adrian
___
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] [PATCH] Fix ICU checking without icu-config

2020-06-20 Thread Karl Kleinpaste 
On 6/20/20 3:35 PM, Adrian Bunk wrote:
> icu-config is no longer available on Debian/Ubuntu, for background
> see https://bugs.debian.org/898820

Is it worth pointing out that Debian/Ubuntu are becoming real PITAs? 
>From the bug:

libicu-dev is not multi-arch aware, causing the i386 version to conflict
with the amd64 one which makes it impossible to install both. As a
result the /usr/lib/i386-linux-gnu/libicu*.so symbolic links are missing
so that developing 32 bit applications using this library is impossible
on a 64 bit system.

Fedora handles this problem /just fine/:

$ grep libicu-devel /var/log/rpmpkgs
libicu-devel-63.2-3.fc31.i686.rpm
libicu-devel-63.2-3.fc31.x86_64.rpm
$ ls -l /usr/bin/icu-config*
-rwxr-xr-x 1 root root   205 May 28  2018 /usr/bin/icu-config
-rwxr-xr-x 1 root root 22011 Jul 25  2019 /usr/bin/icu-config-32
-rwxr-xr-x 1 root root 22019 Jul 25  2019 /usr/bin/icu-config-64
$ rpm -qf /usr/bin/icu-config*
libicu-devel-63.2-3.fc31.x86_64
libicu-devel-63.2-3.fc31.i686
libicu-devel-63.2-3.fc31.i686
libicu-devel-63.2-3.fc31.x86_64

The main script is a 32/64-bit selector script which then calls the
right arch-specific binary, and the relevant symlinks are all correct in
/usr/lib{,64}.

Not that I'm interested in a distro war, but some of us are getting
darned tired of Debian/Ubuntu's high-handed /purity/ demands, virtually
demanding that everyone else fall over for them.
___
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] [PATCH] Fix ICU checking without icu-config

2020-06-20 Thread Adrian Bunk 
On Sat, Jun 20, 2020 at 02:25:58PM -0500, Greg Hellings wrote:
> What's wrong with using icu-config? I'm not sure what you're fixing with
> this.

Thanks for asking, I failed to mention the root problem.

icu-config is no longer available on Debian/Ubuntu, for background
see https://bugs.debian.org/898820

> Greg

cu
Adrian
___
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] [PATCH] Fix ICU checking without icu-config

2020-06-20 Thread Greg Hellings 
What's wrong with using icu-config? I'm not sure what you're fixing with
this.

Greg

On Sat, Jun 20, 2020, 11:56 Adrian Bunk  wrote:

> From: László Böszörményi 
>
> Let still search for icu-config but use pkg-config method after that.
>
> https://bugs.debian.org/962265
> ---
>  configure.ac | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index cd587b41..b7cab681 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -240,9 +240,19 @@ if test x$with_icu = xyes; then
>AM_CXXFLAGS="$AM_CXXFLAGS -D_ICU_"
>AM_CFLAGS="$AM_CFLAGS -D_ICU_"
> else
> -  echo "*** The icu-config script installed by icu could not be
> found"
> -  echo "*** compiling without ICU support"
> -  with_icu=no
> +  PKG_CHECK_MODULES([ICU], [icu-i18n >= 63.1], [found_icu=yes])
> +  if test "$found_icu" = "yes"; then
> + PKG_CHECK_MODULES([ICU_IO], [icu-io >= 63.1])
> + ICU_IOLIBS="$ICU_IO_LIBS"
> + with_icu=yes
> + LIBS="$LIBS $ICU_LIBS $ICU_IOLIBS"
> + AM_CXXFLAGS="$AM_CXXFLAGS -D_ICU_"
> + AM_CFLAGS="$AM_CFLAGS -D_ICU_"
> +  else
> + echo "*** The icu-config script installed by icu could not
> be found"
> + echo "*** compiling without ICU support"
> + with_icu=no
> +  fi
> fi
>  fi
>
> --
> 2.20.1
>
> ___
> 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] Module release: Westminster

2020-06-20 Thread domcox 
Dear All,

This is to announce that we have just now uploaded Westminster
in the CrossWire (main) repository.

## Language:
English

## Description:
Westminster Confession & Catechisms

## Category:
Generic Book

## Version:
This is an update. Version: 1.0.1

## Fixes:
Improvements in xref detection by frontends.

Many thanks to David_Haslam for the hard work.

We wish you enjoyable reading,
The Module Team

P.S.: This email is sent automatically on upload of a new/updated module

___
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] Module release: BaptistConfession1689

2020-06-20 Thread domcox 
Dear All,

This is to announce that we have just now uploaded BaptistConfession1689
in the CrossWire (main) repository.

## Language:
English

## Description:
Baptist Confession of Faith of 1689

## Category:
Generic Book

## Version:
This is an update. Version: 1.0.2

## Fixes:
Improvements in xref detection by frontends.

Many thanks to David_Haslam for the hard work.

We wish you enjoyable reading,
The Module Team

P.S.: This email is sent automatically on upload of a new/updated module

___
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] SWORD, diatheke and a self-closing OSIS note element...

2020-06-20 Thread ref...@gmx.net 
Fixing the filter should be done to avoid the picture, and I can likely do that asap, particularly in light of Troy's announcement. Please though file a bug against the engine (not diatheke) , the likely source of the problem is in the osisplain filter. And file a further bug against the scheme, which will stay until that is fixed even once the engine does not produce bad output anymoreThanksPeterSent from my mobile. Please forgive shortness, typos and weird autocorrects. Original Message Subject: Re: [sword-devel] SWORD,	diatheke and a self-closing OSIS note element...From: Greg Hellings To: David Haslam ,SWORD Developers' Collaboration Forum CC: I believe that we can mandate, through the schema, that a tag not be self closing. If the schema really permits that, it can be prevented at that level if deemed necessary. If it's not appropriate to prevent an empty note, then we need to update the filter to at least close the brackets when it's a self closing tag.On Fri, Jun 19, 2020, 07:50 David Haslam  wrote:Hi everyone,

Today I was testing the updated HunUj module in CrossWire Beta and I came across an unusual anomaly in OSIS that almost escaped being detected.

If one gives the following command:

diatheke -b HunUj -b plain -k Gen.32.2

the output is

Genesis 32:2: Jákób is útnak indult, és találkoztak vele Isten angyalai. [
(HunUj)

"What's odd about that?" one might ask

It's perfectly normal but for the unepected [ at the end of the verse text.

Upon inspection using osis2mod, the verse text ends with an OSIS note...

$$$Genesis 32:2
Jákób is útnak indult, és találkoztak vele Isten angyalai.

Observe closely, the OSIS note element is self-closing and therefore contains no note text or reference element.

Now imagine the module developer getting ready to submit the module. He runs the OSIS through XML syntax check and then proceeds to validate it to the OSIS schema. It passes both. The self-closing note element is perfectly valid OSIS even though it's semantically deficient.

Had I not noticed the anomalous [ in the diatheke output, this source text anomaly would have remained undetected.

So the question for SWORD developers is this: Why does diatheke plain text output include the ] ?

I'm not complaining. I'm glad that it behaved in this way, otherwise the OSIS anomaly would have completely passed us by.
There are no other similar anomalies elsewhere in the HunUj module.

I'd just like to understand better how exactly diatheke parses this peculiar construct and thus give the otherwise unexpected ]

The textual bug is very interesting to me, because I can think of no readily available utility whereby it could have been flagged up in the OSIS file. If you know of such an XML tool, we'd all benefit from you sharing your wisdom and experience.


Best regards,

David

Sent with ProtonMail Secure Email.


___
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] [PATCH] Use C++ 11 instead of __{s, u}* typedefs

2020-06-20 Thread Jaak Ristioja 
On 20.06.20 19:56, Adrian Bunk wrote:
> Names like __u32 do not pollute the POSIX namespace,
> but the Linux kernel uses exactly the same names.
> 
> On some Linux architectures the kernel definitions are different,
> e.g. http://tracker.crosswire.org/browse/API-178

Additionally, according to the C++ draft standard working draft,
https://eel.is/c++draft/lex.name#3:

> 3 In addition, some identifiers are reserved for use by
> C++ implementations and shall not be used otherwise; no
> diagnostic is required.
> (3.1) Each identifier that contains a double underscore
> __ or begins with an underscore followed by an uppercase
> letter is reserved to the implementation for any use.
> (3.2) Each identifier that begins with an underscore is
> reserved to the implementation for use as a name in the
> global namespace.

> All relevant compilers should now support C++ 11,
> but please double-check that this change works on
> all non-gcc compilers you support.

See also these threads for previous discussions on the issue:

https://www.crosswire.org/pipermail/sword-devel/2014-May/041401.html
https://www.crosswire.org/pipermail/sword-devel/2019-July/047252.html

J
___
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] [PATCH] Use C++ 11 instead of __{s, u}* typedefs

2020-06-20 Thread Adrian Bunk 
Names like __u32 do not pollute the POSIX namespace,
but the Linux kernel uses exactly the same names.

On some Linux architectures the kernel definitions are different,
e.g. http://tracker.crosswire.org/browse/API-178

All relevant compilers should now support C++ 11,
but please double-check that this change works on
all non-gcc compilers you support.
---
 CMakeLists.txt|   5 +-
 configure.ac  |   3 +-
 examples/cmdline/search.cpp   |   4 +-
 include/rawstr.h  |   5 +-
 include/rawstr4.h |   5 +-
 include/stringmgr.h   |   9 +-
 include/swkey.h   |   3 +-
 include/sysdata.h |  61 +-
 include/treekeyidx.h  |  11 +-
 include/utilstr.h |   7 +-
 include/xzcomprs.h|   3 +-
 m4/ax_cxx_compile_stdcxx.m4   | 951 ++
 src/keys/treekeyidx.cpp   |  37 +-
 src/keys/versekey.cpp |  17 +-
 src/mgr/stringmgr.cpp |  25 +-
 src/modules/comments/rawfiles/rawfiles.cpp|   5 +-
 src/modules/common/entriesblk.cpp |  21 +-
 src/modules/common/rawstr.cpp |  37 +-
 src/modules/common/rawstr4.cpp|  39 +-
 src/modules/common/rawverse.cpp   |  19 +-
 src/modules/common/rawverse4.cpp  |  21 +-
 src/modules/common/zstr.cpp   |  73 +-
 src/modules/common/zverse.cpp |  49 +-
 src/modules/common/zverse4.cpp|  51 +-
 src/modules/filters/rtfhtml.cpp   |   5 +-
 src/modules/filters/utf8greekaccents.cpp  |   7 +-
 src/modules/filters/utf8utf16.cpp |  17 +-
 src/modules/genbook/rawgenbook/rawgenbook.cpp |  11 +-
 src/modules/lexdict/rawld/rawld.cpp   |  10 +-
 src/modules/lexdict/rawld4/rawld4.cpp |  10 +-
 src/modules/swmodule.cpp  |   5 +-
 tests/filtertest.cpp  |   3 +-
 tests/utf8norm.cpp|   3 +-
 33 files changed, 1248 insertions(+), 284 deletions(-)
 create mode 100644 m4/ax_cxx_compile_stdcxx.m4

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 1aa66701..bbb4d212 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -12,7 +12,7 @@
 # all posterity and eternity, wherever such transfer is possible.  Where it is
 # not, then this file is released under the GPLv2 by myself.
 PROJECT(libsword CXX C)
-CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0)
+CMAKE_MINIMUM_REQUIRED(VERSION 3.1.0)
 SET(SWORD_VERSION 1.8.900)
 
 # Make sure it's an out-of-stream build
@@ -155,6 +155,9 @@ ENDIF(BUILDING_SHARED)
 #SET(CMAKE_C_FLAGS  "${CMAKE_C_FLAGS}"   or "$ENV{CFLAGS}" or 
"" )
 #SET(CMAKE_CXX_FLAGS"${CMAKE_CXX_FLAGS}" or "$ENV{CXXFLAGS}" 
or "" )
 
+SET(CMAKE_CXX_STANDARD 11)
+SET(CMAKE_CXX_STANDARD_REQUIRED ON)
+
 IF(SWORD_ENABLE_WARNINGS STREQUAL "Yes")
SET(CMAKE_C_FLAGS "-Werror ${CMAKE_C_FLAGS}")
SET(CMAKE_CXX_FLAGS "-Werror ${CMAKE_CXX_FLAGS}")
diff --git a/configure.ac b/configure.ac
index 315bafda..cd587b41 100644
--- a/configure.ac
+++ b/configure.ac
@@ -37,6 +37,7 @@ CXXFLAGS=" $CXXFLAGS"
 AC_LANG(C++)
 AC_PROG_CC
 AC_PROG_CXX
+AX_CXX_COMPILE_STDCXX(11)
 AC_PROG_INSTALL
 AC_LIBTOOL_WIN32_DLL
 AC_PROG_LIBTOOL
@@ -302,7 +303,7 @@ else
 fi
 
 if test x$with_cxx11regex = xyes; then
-   AM_CXXFLAGS="$AM_CXXFLAGS -DUSECXX11REGEX -std=c++11"
+   AM_CXXFLAGS="$AM_CXXFLAGS -DUSECXX11REGEX"
 fi
 
 # -
diff --git a/examples/cmdline/search.cpp b/examples/cmdline/search.cpp
index 5fd9e78c..3a54aafb 100644
--- a/examples/cmdline/search.cpp
+++ b/examples/cmdline/search.cpp
@@ -24,6 +24,8 @@
  *
  */
 
+#include 
+
 #include 
 #include 
 #include 
@@ -134,7 +136,7 @@ int main(int argc, char **argv)
SWKey *k = listKey.getElement();
std::cout << k->getRangeText();
 // std::cout << (const char *)listKey;
-   if (k->userData) std::cout << " : " << (__u64)k->userData << 
"%";
+   if (k->userData) std::cout << " : " << (uint64_t)k->userData << 
"%";
std::cout << std::endl;
}
 
diff --git a/include/rawstr.h b/include/rawstr.h
index d25ebc37..cdd05c2c 100644
--- a/include/rawstr.h
+++ b/include/rawstr.h
@@ -26,6 +26,7 @@
 #ifndef RAWSTR_H
 #define RAWSTR_H
 
+#include 
 #include 
 #include 
 
@@ -54,8 +55,8 @@ public:
virtual ~RawStr();
void getIDXBuf(long ioffset, char **buf) const;
void getIDXBufDat(long ioffset, char **buf) const;
-   signed char findOffset(const char *key, __u32 *start, __u16 *size, long 
away = 0, __u32 *idxoff = 0) const;
-   void readText(__u32 start, __u16 *size, char **idxbuf, SWBuf )

[sword-devel] [PATCH] Fix ICU checking without icu-config

2020-06-20 Thread Adrian Bunk 
From: László Böszörményi 

Let still search for icu-config but use pkg-config method after that.

https://bugs.debian.org/962265
---
 configure.ac | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index cd587b41..b7cab681 100644
--- a/configure.ac
+++ b/configure.ac
@@ -240,9 +240,19 @@ if test x$with_icu = xyes; then
   AM_CXXFLAGS="$AM_CXXFLAGS -D_ICU_"
   AM_CFLAGS="$AM_CFLAGS -D_ICU_"
else
-  echo "*** The icu-config script installed by icu could not be found"
-  echo "*** compiling without ICU support"
-  with_icu=no
+  PKG_CHECK_MODULES([ICU], [icu-i18n >= 63.1], [found_icu=yes])
+  if test "$found_icu" = "yes"; then
+ PKG_CHECK_MODULES([ICU_IO], [icu-io >= 63.1])
+ ICU_IOLIBS="$ICU_IO_LIBS"
+ with_icu=yes
+ LIBS="$LIBS $ICU_LIBS $ICU_IOLIBS"
+ AM_CXXFLAGS="$AM_CXXFLAGS -D_ICU_"
+ AM_CFLAGS="$AM_CFLAGS -D_ICU_"
+  else
+ echo "*** The icu-config script installed by icu could not be 
found"
+ echo "*** compiling without ICU support"
+ with_icu=no
+  fi
fi
 fi
 
-- 
2.20.1

___
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] SWORD 1.9.0 release intention

2020-06-20 Thread Troy A. Griffitts 
So, I am making an attempt to travel for my usual summer work in Europe 
next week.  As of now, I believe the rules are that I will be required 
to quarantine for 14 days, this means that the first 2 weeks of July 
should be a great time for me to isolated at home working on SWORD 
1.9.0.  My intention is to finish the following things up in those 2 
weeks (and fix any bugs we find, accordingly).  If you have anything 
else you'd like to get into this release, especially if it 
interface-breaking, please try to have anything committed to me soon.  
Let's shoot for mid-July for the release.  Thank you for all of your 
varied and many contributions to our ministry together!



Renaming the __u64 style macros to something like SW_u64.

Merging the Windows FileMgr patch you have been keeping for Xiphos into 
something build configurable.


A large refactoring commit I have locally which completes the camelCase 
normalization of the public API but doesn't yet pass all unit tests. 
Need to debug and find what I missed.


___
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] SWORD, diatheke and a self-closing OSIS note element...

2020-06-20 Thread Greg Hellings 
I believe that we can mandate, through the schema, that a tag not be self
closing. If the schema really permits that, it can be prevented at that
level if deemed necessary. If it's not appropriate to prevent an empty
note, then we need to update the filter to at least close the brackets when
it's a self closing tag.

On Fri, Jun 19, 2020, 07:50 David Haslam  wrote:

> Hi everyone,
>
> Today I was testing the updated HunUj module in CrossWire Beta and I came
> across an unusual anomaly in OSIS that almost escaped being detected.
>
> If one gives the following command:
>
> diatheke -b HunUj -b plain -k Gen.32.2
>
> the output is
>
> Genesis 32:2: Jákób is útnak indult, és találkoztak vele Isten angyalai. [
> (HunUj)
>
> "What's odd about that?" one might ask
>
> It's perfectly normal but for the unepected [ at the end of the verse text.
>
> Upon inspection using osis2mod, the verse text ends with an OSIS note...
>
> $$$Genesis 32:2
> Jákób is útnak indult, és találkoztak vele Isten angyalai. osisID="Gen.32.2!crossReference.a" osisRef="Gen.32.2"
> type="crossReference"/>
>
> Observe closely, the OSIS note element is self-closing and therefore
> contains no note text or reference element.
>
> Now imagine the module developer getting ready to submit the module. He
> runs the OSIS through XML syntax check and then proceeds to validate it to
> the OSIS schema. It passes both. The self-closing note element is perfectly
> valid OSIS even though it's semantically deficient.
>
> Had I not noticed the anomalous [ in the diatheke output, this source text
> anomaly would have remained undetected.
>
> So the question for SWORD developers is this: Why does diatheke plain text
> output include the ] ?
>
> I'm not complaining. I'm glad that it behaved in this way, otherwise the
> OSIS anomaly would have completely passed us by.
> There are no other similar anomalies elsewhere in the HunUj module.
>
> I'd just like to understand better how exactly diatheke parses this
> peculiar construct and thus give the otherwise unexpected ]
>
> The textual bug is very interesting to me, because I can think of no
> readily available utility whereby it could have been flagged up in the OSIS
> file. If you know of such an XML tool, we'd all benefit from you sharing
> your wisdom and experience.
>
>
> Best regards,
>
> David
>
> Sent with ProtonMail Secure Email.
>
>
> ___
> 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