date:20150902

Peter,

Are you also contemplating a new configuration item? e.g.

GlobalOptionFilter=UTF8ArabicHarraket

Might this be a useful enhancement to module AraNAV ?

David



--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/testing-for-diacritics-tp4655091p4655188.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
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] eBible.org repository minor tweak


  
  
Sorry, I should have said HTTPS is not
  supported by all front ends. Note that HTTPS is not HTTP.
  
  The eBible.org repository can be reached at:
  https://eBible.org/sword
  http://eBible.org/sword
  ftp://ftp.eBible.org/sword
  ftp://ftp.ebible.org/pub/sword
  
  All of those lead to the same physical files on the same disk.
  
  For the test/beta repository, substitute "swordbeta" for "sword"
  in the above URLs.
  
  On 09/02/2015 02:24 AM, Martin Denham wrote:


  The http link is missed from the first post but
works fine with JSword.  And Bible is using http to access the
repo.


Martin
  
  
On 2 September 2015 at 06:04, Chris
  Burrell 
  wrote:
  

  
It's
  the only supported protocol for jsword (step, and
  bible, ...) though I believe dm may have implemented
  ftp recently
  
  
From:
Greg Hellings
Sent:
‎02/‎09/‎2015
  04:20
To:
SWORD Developers' Collaboration
Forum
Subject:
Re:
  [sword-devel] eBible.org repository minor tweak

  
  

  Why is HTTPS not supported? It's
supported by the engine and by at least BibleTime
and Xiphos AFAIK.


--Greg
  
  
On Tue, Sep 1, 2015 at 9:03
  PM, Kahunapule Michael Johnson 
  wrote:
  
 The main
  repository has been updated with revised
  modules with Strong's numbers (5 of them). The
  update is about markup and conf files, with no
  change to source text.
  
  Also, I used symbolic links to allow the /pub
  in the directory to be omitted. In other
  words, ftp://ftp.eBible.org/sword
  works just as well as ftp://ftp.eBible.org/pub/sword
  and ftp://ftp.eBible.org/swordbeta
  works just as well as ftp://ftp.eBible.org/pub/swordbeta.
  
  If you ever wonder if you are getting the
  latest version and suspect ISP-level caching
  of defeating my updates, you can try using https://eBible.org/sword/.
  The HTTPS protocol isn't currently a supported
  repository access method, but you could use a
  browser to grab a copy of what you are
  interested in, then install locally from that
  copy.
  -- 

  



  
  Your
  partner in electronic Bible
  publishing,
  


  


  

  MICHAEL
JOHNSON
PO BOX 881143
PUKALANI HI 96788-1143
  USA
   eBible.org
  MLJohnson.org
  Mobile: +1 808-333-6921
  Skype: kahunapule

  

  


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

Re: [sword-devel] Semantic problem: real module names vs. Abbreviation=XYZ

On 09/02/2015 10:51 AM, David Haslam wrote:
> those whose real module names include a lowercase
> language code prefix are listed below all the modules that have a
> capitalized [ModName].
An unintentional side effect that I intend to try to fix, caused by the
modules arriving in the list in ModName order (straight from the Sword
API), with the Abbreviation then substituted.  I need to find a way to
re-sort before generating the list, but given the sequence of events,
it's a bit of a problem.

One catastrophe at a time.
___
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] Semantic problem: real module names vs. Abbreviation=XYZ

2015-09-02 Thread DM Smith

> On Sep 2, 2015, at 11:14 AM, Karl Kleinpaste  wrote:
> 
> On 09/02/2015 10:51 AM, David Haslam wrote:
>> those whose real module names include a lowercase
>> language code prefix are listed below all the modules that have a
>> capitalized [ModName].
> An unintentional side effect that I intend to try to fix, caused by the 
> modules arriving in the list in ModName order (straight from the Sword API), 
> with the Abbreviation then substituted.  I need to find a way to re-sort 
> before generating the list, but given the sequence of events, it's a bit of a 
> problem.
> 
> One catastrophe at a time.

Yes, one at a time! JSword has the same problem as I’ve been trying to weave in 
Abbreviation. There are lots of places that look odd now.

Right now, I’m trying to figure out whether we need to replace Set, which 
doesn’t allow for collisions, with List. Or what the the true internal module 
ID is for the key.

The displaying of that set is also a problem as we sometimes display a sorted 
list of Module names, other places Description.

— DM

___
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] testing for diacritics

2015-09-02 Thread Matěj Cepl

On 2015-09-02, 14:43 GMT, David Haslam wrote:
> For an online utility see http://www.harakat.ae/
>
> فِي الْبَدْءِ خَلَقَ اللهُ السَّمَاوَاتِ وَالأَرْضَ،
> becomes
> في البدء خلق الله السماوات والأرض، 

With a bit of web-scrapping, one could make a library using it 
as a webservice, couldn't we?

Matěj

-- 
http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
 
I am a Roman Catholic, so that I do not expect `history' to be
anything but a `long defeat' -- though it contains (and in
a legend may contain more clearly and movingly) some samples or
glimpses of final victory.
  -- J.R.R. Tolkien


___
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] eBible.org repository minor tweak


  
  
These are the latest versions at ftp://ftp.ebible.org/sword:
  
  engKJV1769 (KJVD)
  Version=8.1
  History_8.1=Automatically generated on 2015-09-01 from source
  files dated 2015-08-31
  
  spaRV1909 (RV1909)
  Version=2.11
  History_2.11=Automatically generated on 2015-09-01 from source
  files dated 2015-08-10
  
  grcTisch (Tischendorf)
  Version=2.9
  History_2.9=Automatically generated on 2015-09-01 from source
  files dated 2014-01-11
  
  hbo (Masoretic)
  Version=2.9
  History_2.9=Automatically generated on 2015-09-01 from source
  files dated 2013-12-11
  
  hboWLC (WLC)
  Version=2.10
  History_2.10=Automatically generated on 2015-09-01 from source
  files dated 2014-04-08
  
  
  
  On 09/02/2015 04:30 AM, David Haslam wrote:


  Xiphos will only categorize under "Updates" if the Version has changed.

For a minor tweak where only the conf file is changed, the third part of the
Revision ought to be incremented.  Did you ensure this was done?

I just refreshed the repo in Xiphos, but I see no updates.

On the other hand, I may not have previously installed all these 5 modules.

David



David



--
View this message in context: http://sword-dev.350566.n4.nabble.com/eBible-org-repository-minor-tweak-tp4655171p4655180.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
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




-- 
  
  Aloha,
  Kahunapule Michael Johnson
  

  
MICHAEL JOHNSON
  PO BOX 881143
  PUKALANI HI 96788-1143
USA

eBible.org
MLJohnson.org
Mobile: +1 808-333-6921
Skype: kahunapule
  

  

  


___
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] testing for diacritics

Isn't that only a LocalStripFilter?

http://www.crosswire.org/wiki/DevTools:conf_Files#Strip_Filters

Or can any of these existing filters be used as a GlobalOptionFilter,
becoming usable only when front-ends (and the relevant sword utilities)
provide UI options to toggle them?

cf. Diatheke already has two Arabic related options:

p (Arabic Vowels)
r (Arabic Shaping)

David



David



--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/testing-for-diacritics-tp4655091p4655192.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
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] eBible.org repository minor tweak

On 09/02/2015 01:19 PM, Kahunapule Michael Johnson wrote:
> grcTisch (Tischendorf)
> Version=2.9
> History_2.9=Automatically generated on 2015-09-01 from source files
> dated 2014-01-11
Weakness: Still no variants, per source text (11 verses).

Error: Morph content is present but there is no OSISMorph config
specification, meaning it can't be turned on/off, in turn meaning it's
always present, so in Xiphos the morph data overlays Strong's numbers
when Strong's is enabled; when Strong's is disabled, morph data appears
in "native" mode of the filter output (i.e. "following parenthetically").
___
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] Module deduplication: ASV

2015-09-02 Thread DM Smith

Just a mechanical point. If you add Obsoletes=ASV, then it rules out CrossWire 
from updating it.

— DM

> On Sep 2, 2015, at 1:51 PM, Kahunapule Michael Johnson 
>  wrote:
> 
> The ASV module (American Standard Version of 1901) in the Crosswire main 
> repository came from my eBible.org copy around 2006. Since that time, there 
> have been numerous typo corrections and corrections to conform to the printed 
> master copy, based on emailed feedback diligently compared to the master 
> copy, public errata on the web (because most ASVs in electronic format came 
> from the same scan), and a detailed Genesis-to-Revelation proofreading by 
> Dale and cross-checked by myself. While there were only a few differences 
> that I would consider theologically significant, there were literally 
> hundreds of corrections made.
> 
> The current best text of the ASV I know of anywhere, including in commercial 
> software, is on eBible.org in many formats, including the engASV1901 module. 
> The ASV module on the main crosswire repository could be replaced with the 
> eBible.org copy or removed. I'll add on "Obsoletes=ASV" line to the 
> engASV1901.conf file with the next rebuild.
> -- 
>Your partner in electronic Bible publishing,
> 
> MICHAEL JOHNSON
> PO BOX 881143
> PUKALANI HI 96788-1143
> USA   eBible.org 
> MLJohnson.org 
> Mobile: +1 808-333-6921
> Skype: kahunapule ___
> 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] testing for diacritics

We have a filter which does that - UTF8ArabicPoints. 

Peter

On Wed, 2015-09-02 at 09:08 -0700, David Haslam wrote:
> Peter,
> 
> Are you also contemplating a new configuration item? e.g.
> 
> GlobalOptionFilter=UTF8ArabicHarraket
> 
> Might this be a useful enhancement to module AraNAV ?
> 
> David
> 
> 
> 
> --
> View this message in context: http://sword
> -dev.350566.n4.nabble.com/testing-for-diacritics
> -tp4655091p4655188.html
> Sent from the SWORD Dev mailing list archive at Nabble.com.
> 
> ___
> 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] Semantic problem: real module names vs. Abbreviation=XYZ


  
  
OK. On my end with module generation,
  I'll not worry about abbreviation uniqueness if there are strong
  traditional abbreviations to use, but try to be unique most of the
  time in module generation. Any conflicts that slip through
  (especially across repositories) will be left to front ends and
  users to resolve.
  
  On 09/02/2015 03:24 AM, Peter von Kaehne wrote:


  Karl, can I summarise :

1) Abbreviations need to be bidirectional

2) Uniqueness needs to happen at user-level for bidirectionality to
work. Not above. 

3) Both across repos and internal to repos we can have one, some and
many modules which carry the same abbreviation - KJV being the most
notorious. It will be (see 2) up to the user to resolve this - but we
should make an effort to create sensible defaults. 

4) Apart from all that, we should try and eliminate genuine
duplications and ensure that we do not confuse users more than
necessary. E.g. to have many KJV (English language 1769 King James
Bibles) modules is not desirable. 

I think this is sensible and good.

Peter


On Wed, 2015-09-02 at 08:28 -0400, Karl Kleinpaste wrote:

  
On 09/01/2015 09:45 PM, Kahunapule Michael Johnson wrote:


  The uniqueness of an abbreviation is not required as long as you 
never try to look up which module corresponds to that abbreviation. 
If all you do is use the abbreviation as a short way to display 
which text is selected, i.e. just looking up the abbreviation given 
the module name, collisions are no big deal.


"If all you do is..."

That's entirely the problem: That is not all we (need to) do.  You 
are proceeding from false assumption.  As DM said, you're wrongly 
insistent on demanding uni-directional "output" use, as a mere 
eyeball convenience.  And that is simply not the case in the real 
world, and actually hasn't been so for a long time, if it ever was.  
Joe Average wants to type "KJV" in many contexts.  Module authors 
want to cross-ref into "KJV" in their content as a matter of routine.
  Network protocols want to ship "KJV" as a commonly-understood 
reference name.


  Module ID -> abbreviation is OK.
abbreviation -> Module ID is not OK.


But it must be made OK.

You said to me in private email that you "live in a wider world than 
Crosswire."  I suppose that's true along one axis of consideration.  
I live in a wider world than Crosswire along a different axis: I am a 
network head, and absolutely positively anything that threatens to 
share data from Hither to Yon (or from Alice to Bob) must be not 
merely handled, but expected all the time.  You cannot expect that 
Bob will tell Alice -- the nature of whose Bible app is unknown to 
Bob -- that her app should locate a module absurdly named 
"engKJV2006."  It is entirely unreasonable to believe that other 
software producers will name any module that way, and Alice's app may 
not be from Crosswire.  So common abbreviations are the way to 
achieve generality across software architectures, and they must be 
accepted as input that way.  If Bob likes engKJV2006 as his KJV 
implementation, great, and he should tell Alice that he's using (what 
he thinks of as) "KJV," but Alice wants the official version as 
supplied for her software.  They must interoperate.

A cardinal rule of the Internet since the ARPAnet days has been "be 
conservative in what you send, and liberal in what you accept."  
Conservatively, "KJV" is the correct way to identify the King James 
Version to anyone on the planet.  Liberally, "KJV" is a correct 
identification of a Bible to be provided by someone else, yet it is 
not unique in a (Crosswire or any other) world where KJV and 
(something like) engKJV2006 try to co-exist.


   language ID + abbreviation -> Module ID is OK.


No, it is not.  At very best, you could claim that you have reduced 
the breadth of conflict, but sometime next week someone else will 
produce a different "Thai KJV" module that they want to show up in 
our module selector lists, and so again conflict resolution is needed 
because yours is not necessarily special to Thai speakers any more 
than Crosswire's KJV is necessarily special to English speakers.  
This example conflict just happens to become localized to the subset 
of modules specific to Thai.  One cannot expect that there is always 
and forever exactly one module implementation of XYZ in any language 
group.


  Stop doing that, and always require a full module ID whenever you 
want to find a module. (Requires some software rewriting and 
distribution.)


Absolutely impossible, for all the reasons discussed above.  Users 
type Bible names, common names with which they've been familiar since 
childhood.  Commentary authors mention those same common Bible names.
  Networks transport those same common Bible names.  The programmatic

Re: [sword-devel] eBible.org repository minor tweak

Thank you, Martin.

1. Well, that is embarrassing. I'm glad you pointed that out.
Rebuilding is in progress. That one affects a lot of modules.
2. I filled in the missing descriptions in the Haiola metadata. It
will be in the conf files with the next rebuild (again, in
progress). I also coded a fallback, such that the long English
description will be used if there is no short English title in my
input data.
3. The stray globals.conf has been disposed of.

An incremental rebuild is in progress live on
ftp://ftp.eBible.org/swordbeta, alphabetically by module name. If
no obvious problems with swordbeta present themselves, I'll
overwrite ftp://ftp.eBible.org/sword with that repository once it
is done and I do a spot check to make sure it worked.

On 09/02/2015 10:18 AM, Martin Denham wrote:

And Bible/JSword is reporting errors in some conf files:

1. In cta1981.conf and many others the extra trailing '*'
obstructs line continuation:

\*
You must give Attribution to the work. \
\*
You do not sell this work for a profit. \
\*

2. Many modules have no description
e.g. kdc2014

Malformed conf file for apeB2013. No
Description found. Using internal of apeB2013

Malformed conf file for msk1975. No
Description found. Using internal of msk1975
Malformed conf file for kmk2003. No
Description found. Using internal of kmk2003
Malformed conf file for vid2014. No
Description found. Using internal of vid2014

Malformed conf file for mbs1982. No
Description found. Using internal of mbs1982
Malformed conf file for jae1980. No
Description found. Using internal of jae1980
Malformed conf file for xon2014. No
Description found. Using internal of xon2014

Malformed conf file for kdc2014. No
Description found. Using internal of kdc2014

3. In mods.d.tar.gz there is a
miscellaneous file called globals.conf which causes JSword to
throw an error and prevents And Bible loading the eBible repo.

Book not supported: malformed conf
file for globals no ModDrv found.
Malformed conf file for globals. No
Description found. Using internal of globals

Cheers

Martin

On 2 September 2015 at 20:13, David
Haslam
wrote:
In
fact, it was even worse than that.

The installed module [spaRV1909] got corrupted due to the
fact that the
earlier module had not been first removed by Xiphos, as it
would have done
in the normal course of events.

I have just manually removed the eBible module, and
reinstalled the
CrossWire module [SpaRV1909].
So apart from file date stamps, I'm back to where I was an
hour ago.

Another possible source of confusion is that the CrossWire
module is
encrypted, yet comes with its own key.
The eBible module [spaRV1909] is not encrypted.

David

--
View this message in context: http://sword-dev.350566.n4.nabble.com/eBible-org-repository-minor-tweak-tp4655171p4655200.html

Sent from the SWORD Dev mailing list
archive at Nabble.com.

___
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

Aloha,
Kahunapule Michael Johnson

MICHAEL JOHNSON
PO BOX 881143
PUKALANI HI 96788-1143
USA

eBible.org
MLJohnson.org
Mobile: +1 808-333-6921
Skype:

[sword-devel] Module collisions

2015-09-02 Thread Greg Hellings

So I just added the new eBible repository and I'm seeing a few module
name collisions with existing modules that I have installed (and I, by
no means, have a large number of them installed - only about two dozen
at present).

General Books - Pilgrim's Progress
Dictionaries - Robinson's, StrongsGreek, WebstersDict

All four of these are marked in the Xiphos module manager as being
modules I already have installed for which there are versions in the
eBible repository.

--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] testing for diacritics

On Wed, 2015-09-02 at 07:18 -0700, David Haslam wrote:
> Windows users may find it useful to know that BabelPad has a menu 
> option to
> strip diacritics.

Again, the point of my request is not to remove diacritics per se, but
to test their presence (the presence only of those we have a filter for
stripping) and if so, to engage the appropriate GlobalOptionFilter in
the conf file. 

While there are a whole bunch of ways of removing diacritics, including
GUI tools and various ways of engaging with regexes, using the sword
-library itself ensures that any GlobalOptionFilter set in a conf file
is actually corresponding to a real, existing ability of the engine to
do something with the text. It also ensures that any modulemaking
scripts do not need to be kept separately in sync with whatever happens
in the engine. 

Peter



___
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] eBible.org repository minor tweak

In fact, it was even worse than that.

The installed module [spaRV1909] got corrupted due to the fact that the
earlier module had not been first removed by Xiphos, as it would have done
in the normal course of events.

I have just manually removed the eBible module, and reinstalled the
CrossWire module [SpaRV1909].
So apart from file date stamps, I'm back to where I was an hour ago.

Another possible source of confusion is that the CrossWire module is
encrypted, yet comes with its own key.
The eBible module [spaRV1909] is not encrypted.

David





--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/eBible-org-repository-minor-tweak-tp4655171p4655200.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
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] testing for diacritics

On Wed, 2015-09-02 at 10:21 -0700, David Haslam wrote:
> Isn't that only a LocalStripFilter?
> 
> http://www.crosswire.org/wiki/DevTools:conf_Files#Strip_Filters
> 
> Or can any of these existing filters be used as a GlobalOptionFilter,
> becoming usable only when front-ends (and the relevant sword 
> utilities)
> provide UI options to toggle them?

Yes. It can be a GlobalOptionFilter. Not sure which frontends implement
it. There is some weirdness around the whole lot still. Nevertheless.

Peter



> 
> cf. Diatheke already has two Arabic related options:
> 
> p (Arabic Vowels)
> r (Arabic Shaping)
> 
> David
> 
> 
> 
> David
> 
> 
> 
> --
> View this message in context: http://sword
> -dev.350566.n4.nabble.com/testing-for-diacritics
> -tp4655091p4655192.html
> Sent from the SWORD Dev mailing list archive at Nabble.com.
> 
> ___
> 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] eBible.org repository minor tweak

2015-09-02 Thread Martin Denham

And Bible/JSword is reporting errors in some conf files:
1. In cta1981.conf and many others the extra trailing '*' obstructs line
continuation:

 \*
You must give Attribution to the work. \
 \*
You do not sell this work for a profit. \
 \*

2. Many modules have no description e.g. kdc2014
Malformed conf file for apeB2013. No Description found. Using internal of
apeB2013
Malformed conf file for msk1975. No Description found. Using internal of
msk1975
Malformed conf file for kmk2003. No Description found. Using internal of
kmk2003
Malformed conf file for vid2014. No Description found. Using internal of
vid2014
Malformed conf file for mbs1982. No Description found. Using internal of
mbs1982
Malformed conf file for jae1980. No Description found. Using internal of
jae1980
Malformed conf file for xon2014. No Description found. Using internal of
xon2014
Malformed conf file for kdc2014. No Description found. Using internal of
kdc2014

3. In mods.d.tar.gz there is a miscellaneous file called globals.conf which
causes JSword to throw an error and prevents And Bible loading the eBible
repo.
Book not supported: malformed conf file for globals no ModDrv found.
Malformed conf file for globals. No Description found. Using internal of
globals

Cheers
Martin

On 2 September 2015 at 20:13, David Haslam  wrote:

> In fact, it was even worse than that.
>
> The installed module [spaRV1909] got corrupted due to the fact that the
> earlier module had not been first removed by Xiphos, as it would have done
> in the normal course of events.
>
> I have just manually removed the eBible module, and reinstalled the
> CrossWire module [SpaRV1909].
> So apart from file date stamps, I'm back to where I was an hour ago.
>
> Another possible source of confusion is that the CrossWire module is
> encrypted, yet comes with its own key.
> The eBible module [spaRV1909] is not encrypted.
>
> David
>
>
>
>
>
> --
> View this message in context:
> http://sword-dev.350566.n4.nabble.com/eBible-org-repository-minor-tweak-tp4655171p4655200.html
> Sent from the SWORD Dev mailing list archive at Nabble.com.
>
> ___
> 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] eBible.org repository minor tweak

Michael,

Your module [spaRV1909] has the same DataPath as the CrossWire module
[SpaRV1909].

This name clash needs resolving asap, else other users will meet the same
problem I just experienced.

The fact that the first letter is lowercase in your module name is
effectively ignored by the Xiphos module manager. 

When I installed yours v2.11, it replaced the earlier CrossWire module which
is still version 1.01

Rather confusingly, Xiphos retained the Lucene search index generated from
the CrossWire module
It was that which first alerted me. After installing your module, I switched
to the Maintenance window.
I was surprised to see that a module that I had just installed had somehow
already been indexed!

Unless the modules happen to be identical, the old index would not be valid
for the new module!

Xiphos module update is supposed to first remove the earlier version
completely, yet it seems that in this subtle scenario, it failed to do so. 
Karl may wish to look into how this happened.

Best regards,

David



--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/eBible-org-repository-minor-tweak-tp4655171p4655198.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
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 conf files with a blank first line before the module name

Minor annoyance.

A number of our modules have a spurious blank line before the [ModName].

e.g. SpaRV1909

Next time there's a general tidy up in our repositories, this needs fixing.

Best regards,

David



--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/Module-conf-files-with-a-blank-first-line-before-the-module-name-tp4655199.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
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] eBible.org repository minor tweak

Lacking a compelling reason to do
otherwise, I have removed spaRV1909 from the eBible.org sword
repository.

I haven't bothered encrypting any Sword modules, yet. I might do
that for proprietary copyrighted Bibles in the future if that is
what it takes to get permission to distribute them, but I really
don't want to get involved in key management and sales.

The irony that the guy who contributed encryption algorithm and
code to the Sword project currently sees little point in using it
has not escaped me.

On another topic, one use of cryptography in Bible modules that
would be worthwhile would be implementing digital signatures for
assurance that a module hasn't been tampered with since it was
released. Perhaps another day...

On 09/02/2015 09:13 AM, David Haslam wrote:

In fact, it was even worse than that.

The installed module [spaRV1909] got corrupted due to the fact that the
earlier module had not been first removed by Xiphos, as it would have done
in the normal course of events.

I have just manually removed the eBible module, and reinstalled the
CrossWire module [SpaRV1909].
So apart from file date stamps, I'm back to where I was an hour ago.

Another possible source of confusion is that the CrossWire module is
encrypted, yet comes with its own key.
The eBible module [spaRV1909] is not encrypted.

David

--
View this message in context: http://sword-dev.350566.n4.nabble.com/eBible-org-repository-minor-tweak-tp4655171p4655200.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
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

Aloha,
Kahunapule Michael Johnson

MICHAEL JOHNSON
PO BOX 881143
PUKALANI HI 96788-1143
USA

eBible.org
MLJohnson.org
Mobile: +1 808-333-6921
Skype: kahunapule

___
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] eBible.org repository minor tweak

2015-09-02 Thread Martin Denham

The http link is missed from the first post but works fine with JSword.
And Bible is using http to access the repo.

Martin

On 2 September 2015 at 06:04, Chris Burrell 
wrote:

> It's the only supported protocol for jsword (step, and bible, ...) though
> I believe dm may have implemented ftp recently
> --
> From: Greg Hellings 
> Sent: ‎02/‎09/‎2015 04:20
> To: SWORD Developers' Collaboration Forum 
> Subject: Re: [sword-devel] eBible.org repository minor tweak
>
> Why is HTTPS not supported? It's supported by the engine and by at least
> BibleTime and Xiphos AFAIK.
>
> --Greg
>
> On Tue, Sep 1, 2015 at 9:03 PM, Kahunapule Michael Johnson <
> kahunap...@ebible.org> wrote:
>
>> The main repository has been updated with revised modules with Strong's
>> numbers (5 of them). The update is about markup and conf files, with no
>> change to source text.
>>
>> Also, I used symbolic links to allow the /pub in the directory to be
>> omitted. In other words, ftp://ftp.eBible.org/sword works just as well
>> as ftp://ftp.eBible.org/pub/sword and ftp://ftp.eBible.org/swordbeta
>> works just as well as ftp://ftp.eBible.org/pub/swordbeta.
>>
>> If you ever wonder if you are getting the latest version and suspect
>> ISP-level caching of defeating my updates, you can try using
>> https://eBible.org/sword/. The HTTPS protocol isn't currently a
>> supported repository access method, but you could use a browser to grab a
>> copy of what you are interested in, then install locally from that copy.
>> --
>> Your partner in electronic Bible publishing,
>>
>>
>>
>> *MICHAEL JOHNSON PO BOX 881143 PUKALANI HI 96788-1143*
>> USA eBible.org
>> MLJohnson.org
>> Mobile: +1 *808-333-6921 <808-333-6921>*
>> Skype: kahunapule
>>
>> ___
>> 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] Semantic problem: real module names vs. Abbreviation=XYZ

On 09/01/2015 09:45 PM, Kahunapule Michael Johnson wrote:
> The uniqueness of an abbreviation is not required as long as you never
> try to look up which module corresponds to that abbreviation. If all
> you do is use the abbreviation as a short way to display which text is
> selected, i.e. just looking up the abbreviation given the module name,
> collisions are no big deal.
"If all you do is..."

That's entirely the problem: That is /not/ all we (need to) do.  You are
proceeding from false assumption.  As DM said, you're wrongly insistent
on demanding uni-directional "output" use, as a mere eyeball
convenience.  And that is simply not the case in the real world, and
actually hasn't been so for a long time, if it ever was.  Joe Average
wants to type "KJV" in many contexts.  Module authors want to cross-ref
into "KJV" in their content as a matter of routine.  Network protocols
want to ship "KJV" as a commonly-understood reference name.
> Module ID -> abbreviation is OK.
> abbreviation -> Module ID is not OK.
But it /must be made/ OK.

You said to me in private email that you "live in a wider world than
Crosswire."  I suppose that's true along one axis of consideration.  I
live in a wider world than Crosswire along a different axis: I am a
network head, and absolutely positively anything that threatens to share
data from Hither to Yon (or from Alice to Bob) must be not merely
handled, but expected all the time.  You /cannot/ expect that Bob will
tell Alice -- the nature of whose Bible app is unknown to Bob -- that
her app should locate a module absurdly named "engKJV2006."  It is
entirely unreasonable to believe that other software producers will name
any module that way, and Alice's app may not be from Crosswire.  So
common abbreviations are the way to achieve generality across software
architectures, and they /must/ be accepted as input that way.  If Bob
likes engKJV2006 as his KJV implementation, great, and he should tell
Alice that he's using (what he thinks of as) "KJV," but Alice wants the
official version as supplied for her software.  They /must/ interoperate.

A cardinal rule of the Internet since the ARPAnet days has been "be
conservative in what you send, and liberal in what you accept." 
Conservatively, "KJV" is the correct way to identify the King James
Version to anyone on the planet.  Liberally, "KJV" is a correct
identification of a Bible to be provided by someone else, yet it is not
unique in a (Crosswire or any other) world where KJV and (something
like) engKJV2006 try to co-exist.
> language ID + abbreviation -> Module ID is OK.
No, it is not.  At very best, you could claim that you have reduced the
breadth of conflict, but sometime next week someone else will produce a
different "Thai KJV" module that they want to show up in our module
selector lists, and so again conflict resolution is needed because yours
is not necessarily special to Thai speakers any more than Crosswire's
KJV is necessarily special to English speakers.  This example conflict
just happens to become localized to the subset of modules specific to
Thai.  One cannot expect that there is always and forever exactly one
module implementation of XYZ in any language group.
> Stop doing that, and always require a full module ID whenever you want
> to find a module. (Requires some software rewriting and distribution.)
Absolutely impossible, for all the reasons discussed above.  Users type
Bible names, common names with which they've been familiar since
childhood.  Commentary authors mention those same common Bible names. 
Networks transport those same common Bible names.  The programmatic
handlers of these names must resolve such references to something in the
user's (local) real world.  So Alice will tell Bob via BSP to find a
certain verse in "KJV" and Bob's preference for engKJV2006 as his "KJV"
means he'll get what he wants.
> Require that all module abbreviations are globally unique across well
> over 1,000 translations.
> Let the user assign abbreviations and disallow assignment of a duplicate.
This is the solution needed, in combination: Abbreviations must be
unique, and conflicts must be resolved as they are encountered.
> Personally, I don't like the idea of burdening the user with managing
> unique abbreviations, unless you have working defaults so that this
> level of customization is not required.
It is a mighty small burden: "By the way, your set of modules has 1
naming conflict.  Here's how to fix..."  As far as I know, at this
moment, there are exactly 2 actual conflicts, KJV and WEB.  You have
already made the former go away by removing engKJV2006 from eBible;
Crosswire will make the latter go away by removing WEB from Crosswire
main.  But the problem is general and could re-present itself tomorrow
with some other name.

The alternative is for abbreviation references literally not to work as
input, yet they /must/.
___
sword-devel mailing list: sword-devel@crosswire.org

Re: [sword-devel] Semantic problem: real module names vs. Abbreviation=XYZ

Karl, can I summarise :

1) Abbreviations need to be bidirectional

2) Uniqueness needs to happen at user-level for bidirectionality to
work. Not above. 

3) Both across repos and internal to repos we can have one, some and
many modules which carry the same abbreviation - KJV being the most
notorious. It will be (see 2) up to the user to resolve this - but we
should make an effort to create sensible defaults. 

4) Apart from all that, we should try and eliminate genuine
duplications and ensure that we do not confuse users more than
necessary. E.g. to have many KJV (English language 1769 King James
Bibles) modules is not desirable. 

I think this is sensible and good.

Peter


On Wed, 2015-09-02 at 08:28 -0400, Karl Kleinpaste wrote:
> On 09/01/2015 09:45 PM, Kahunapule Michael Johnson wrote:
> > The uniqueness of an abbreviation is not required as long as you 
> > never try to look up which module corresponds to that abbreviation. 
> > If all you do is use the abbreviation as a short way to display 
> > which text is selected, i.e. just looking up the abbreviation given 
> > the module name, collisions are no big deal.
> "If all you do is..."
> 
> That's entirely the problem: That is not all we (need to) do.  You 
> are proceeding from false assumption.  As DM said, you're wrongly 
> insistent on demanding uni-directional "output" use, as a mere 
> eyeball convenience.  And that is simply not the case in the real 
> world, and actually hasn't been so for a long time, if it ever was.  
> Joe Average wants to type "KJV" in many contexts.  Module authors 
> want to cross-ref into "KJV" in their content as a matter of routine.
>   Network protocols want to ship "KJV" as a commonly-understood 
> reference name.
> > Module ID -> abbreviation is OK.
> > abbreviation -> Module ID is not OK.
> But it must be made OK.
> 
> You said to me in private email that you "live in a wider world than 
> Crosswire."  I suppose that's true along one axis of consideration.  
> I live in a wider world than Crosswire along a different axis: I am a 
> network head, and absolutely positively anything that threatens to 
> share data from Hither to Yon (or from Alice to Bob) must be not 
> merely handled, but expected all the time.  You cannot expect that 
> Bob will tell Alice -- the nature of whose Bible app is unknown to 
> Bob -- that her app should locate a module absurdly named 
> "engKJV2006."  It is entirely unreasonable to believe that other 
> software producers will name any module that way, and Alice's app may 
> not be from Crosswire.  So common abbreviations are the way to 
> achieve generality across software architectures, and they must be 
> accepted as input that way.  If Bob likes engKJV2006 as his KJV 
> implementation, great, and he should tell Alice that he's using (what 
> he thinks of as) "KJV," but Alice wants the official version as 
> supplied for her software.  They must interoperate.
> 
> A cardinal rule of the Internet since the ARPAnet days has been "be 
> conservative in what you send, and liberal in what you accept."  
> Conservatively, "KJV" is the correct way to identify the King James 
> Version to anyone on the planet.  Liberally, "KJV" is a correct 
> identification of a Bible to be provided by someone else, yet it is 
> not unique in a (Crosswire or any other) world where KJV and 
> (something like) engKJV2006 try to co-exist.
> >  language ID + abbreviation -> Module ID is OK.
> No, it is not.  At very best, you could claim that you have reduced 
> the breadth of conflict, but sometime next week someone else will 
> produce a different "Thai KJV" module that they want to show up in 
> our module selector lists, and so again conflict resolution is needed 
> because yours is not necessarily special to Thai speakers any more 
> than Crosswire's KJV is necessarily special to English speakers.  
> This example conflict just happens to become localized to the subset 
> of modules specific to Thai.  One cannot expect that there is always 
> and forever exactly one module implementation of XYZ in any language 
> group.
> > Stop doing that, and always require a full module ID whenever you 
> > want to find a module. (Requires some software rewriting and 
> > distribution.)
> Absolutely impossible, for all the reasons discussed above.  Users 
> type Bible names, common names with which they've been familiar since 
> childhood.  Commentary authors mention those same common Bible names.
>   Networks transport those same common Bible names.  The programmatic 
> handlers of these names must resolve such references to something in 
> the user's (local) real world.  So Alice will tell Bob via BSP to 
> find a certain verse in "KJV" and Bob's preference for engKJV2006 as 
> his "KJV" means he'll get what he wants.
> > Require that all module abbreviations are globally unique across 
> > well over 1,000 translations.
> > Let the user assign abbreviations and disallow assignment of a 
> > duplicate.
> This is the

Re: [sword-devel] Semantic problem: real module names vs. Abbreviation=XYZ

And in the sidebar, those whose real module names include a lowercase
language code prefix are listed below all the modules that have a
capitalized [ModName].

So (e.g.) Brenton comes after Worsley.  (LOL)

David





--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/Semantic-problem-real-module-names-vs-Abbreviation-XYZ-tp4655148p4655185.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
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] eBible.org repository minor tweak

Several front-ends have a user action to force a refresh for the remote
module resource.
Among these are Xiphos and PocketSword.

Xiphos does support both FTP and HTTP.
PocketSword only supports FTP for adding new sources.

Do ISPs really sometimes cache FTP? 
I'd only expect them to cache high demand HTTP pages.

David



--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/eBible-org-repository-minor-tweak-tp4655171p4655177.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
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] testing for diacritics

Windows users may find it useful to know that BabelPad has a menu option to
strip diacritics.

Convert | Other | Strip diacritics

It certainly works well for Cyrillic & Latin scripts, as well as Hebrew &
Greek.

It may not work for Arabic/Persian scripts. 

Can you provide some examples of such with real diacritic characters?

David



--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/testing-for-diacritics-tp4655091p4655178.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
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] Semantic problem: real module names vs. Abbreviation=XYZ

Karl wrote,

"FYI, in Xiphos' module list trees -- sidebar, module manager, advanced
search, and parallel bible/commentary selector trees -- modules with
abbreviations show up as "Abbrev (Real)" so that it is clear to the user
what he's getting when he sees the selections."

That may have been the case in version 4.0.3 but it is no longer so in
version 4.0.4

The sidebar (etc) now just displays "Abbrev: Description"

David



--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/Semantic-problem-real-module-names-vs-Abbreviation-XYZ-tp4655148p4655179.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
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] eBible.org repository minor tweak

Xiphos will only categorize under "Updates" if the Version has changed.

For a minor tweak where only the conf file is changed, the third part of the
Revision ought to be incremented.  Did you ensure this was done?

I just refreshed the repo in Xiphos, but I see no updates.

On the other hand, I may not have previously installed all these 5 modules.

David



David



--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/eBible-org-repository-minor-tweak-tp4655171p4655180.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
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] Semantic problem: real module names vs. Abbreviation=XYZ

On 09/02/2015 10:24 AM, David Haslam wrote:
> The sidebar (etc) now just displays "Abbrev: Description"
You're right, my mistake.

The display of "Abbrev (Real)" is restricted to the module manager,
which is where I figured it mattered most, or at all.  By the time the
user has installed a module, I think I figured that he'd know what he'd
done when seeing it in other contexts.
___
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] eBible.org repository minor tweak