I don't think the SWORD v11n allows for starts other than 1 nor for numbering
out of order. In the v11n there is merely verse counts per chapter.
In Him,
DM
On May 14, 2013, at 8:34 PM, jonathon jonathon.bl...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/13/2013
Yes, DM is correct. We don't provide a mechanism to facilitate this. These
anomalies must be handled as such: anomalies. They will need to use some
strategy like appending verses together and linking from all involved verses to
the same out of ordered chunk, or if the material is really a mess,
On Tue, May 14, 2013 at 5:40 PM, Peter von Kaehne ref...@gmx.net
mailto:ref...@gmx.net wrote:
A decent Scope implementation has advantages for partial Bibles,
of which we have some and will get more. The mapping could be
directed in a conf entry - Syn2KJV, SynP2KJV etc.
Yes, by
On 05/13/2013 06:41 PM, Костя Маслюк wrote:
Prov.13.26 Prov.18.25 Dan.3.34-100 - is not correct, but i also got
mistaken: Dan.3.24-3.90 *Prov.13.14* Prov.18.8
Thanks Kostya for pointing this important discrepancy out. I looked into
this and have learned something new that has serious
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/13/2013 11:34 AM, Костя Маслюк wrote:
No need to introduce new functions because last chapter would be always
calculated via getChapterMax().
For Greek Esther, that approach is always going to fail.
The first verse of Greek Esther is Esther
On 13/05/13 05:30, Troy A. Griffitts wrote:
What sort of use cases do we have to build further API calls on this?
vectorstring getBooksPresent()
In terms of being able to not showing lists of books which are not
present, this would probably be enough.
Would it be good enough to have this as
On 05/13/2013 10:30 AM, Troy A. Griffitts wrote:
We have the first part already in the API:
SWModule::hasEntry(const SWKey *)
What sort of use cases do we have to build further API calls on this?
vectorstring getBooksPresent()
???
Yes- or even just:
bool isBookPresent(aBook)
and there
Along the same lines, might you require further Booleans to return something
for translations in which the Greek additions to Esther are assigned their
own separate book?
i.e. When the first verse is ESG 10:4
David
--
View this message in context:
No need to introduce new functions because last chapter would be always
calculated via getChapterMax().
Here is list of *difficult cases* of deuterocanonical content in Synodal
v11n
Dan.3.24-3.90 Prov.14.13 Prov.18.8
Here deuterocanonical text is inside of chapter... In text without
On 05/13/2013 05:34 PM, Костя Маслюк wrote:
No need to introduce new functions because last chapter would be always
calculated via getChapterMax().
I think that getChapterMax returns the maximum chapter in the verse
system. But we still need something like lastChapterPresent to return
the
Prov.13.26 Prov.18.25 Dan.3.34-100 - is not correct, but i also got
mistaken: Dan.3.24-3.90 *Prov.13.14* Prov.18.8
2013/5/13 John Austin gpl.programs.i...@gmail.com
On 05/13/2013 05:34 PM, Костя Маслюк wrote:
No need to introduce new functions because last chapter would be always
BPBible already has code which (attempts) to check if a chapter is present.
https://code.google.com/p/bpbible/source/browse/trunk/backend/book.py?spec=svn1419r=1414#716
Note this isn't yet av11n compliant, but the general principle should be
much the same. It's in Python but should be pretty much
Thanks friends.
I wasn't trying to muddy the waters at all, but I myself had wondered
whatever had happened after the detailed discussion about scope in .conf
files.
If you can come to a consensus as to the best way forward, I'm sure I can
persuade our friend at IBT to take advantage of it, once
On 05/12/2013 02:19 PM, David Haslam wrote:
Thanks friends.
I wasn't trying to muddy the waters at all, but I myself had wondered
whatever had happened after the detailed discussion about scope in .conf
files.
Yes- The Scope param, if properly implemented, can solve many problems.
I would
be beneficial
Sent from my HTC
- Reply message -
From: John Austin gpl.programs.i...@gmail.com
To: SWORD Developers' Collaboration Forum sword-devel@crosswire.org
Subject: [sword-devel] Synodal versification IBT modules?
Date: Sun, May 12, 2013 12:47
On 05/12/2013 02:19 PM, David Haslam
Hi DM,
On 12/05/2013, at 7:40 AM, DM Smith dmsm...@crosswire.org wrote:
Chris Burrell added some code to JSword that allows for the quick
determination of whether a verse is present in a module. He is using this in
STEP to prune the v11n to only those books, chapters and verses that are
JSword (Java) is quite different from SWORD (C++). But I'll give you an
overview. Each module has a similar structure. There is an index file where
slots have records indicating offset and size into a data file. For a Bible
module, each slot represents a verse.
If the size is 0 then that
More:
Once that is written, the worst case for analysis is a book that is entirely
absent. Basically, when you find something from a book, you don't need to look
any further in the book and go to the next.
On May 12, 2013, at 10:06 PM, DM Smith dmsm...@crosswire.org wrote:
JSword (Java) is
We have the first part already in the API:
SWModule::hasEntry(const SWKey *)
What sort of use cases do we have to build further API calls on this?
vectorstring getBooksPresent()
???
On 05/12/2013 07:11 PM, DM Smith wrote:
More:
Once that is written, the worst case for analysis is a
IBT modules specify Versification=Synodal
This is because they follow the Russian Synodal v11n.
This causes some front-end apps to display all the deuterocanonical books in
the book selector.
e.g. PocketSword.
However, none of the IBT modules include deuterocanonical books.
They are all at
On 5/11/2013 4:38 AM, David Haslam wrote:
IBT modules specify Versification=Synodal
This is because they follow the Russian Synodal v11n.
This causes some front-end apps to display all the deuterocanonical books in
the book selector.
e.g. PocketSword.
However, none of the IBT modules include
Did IBT's programmer actually know that you'd provided it during the period
in question?
It might just have been not used due to his excessive workload, or other
factors affecting his situation.
If we have Luther and German as two similar cases, why balk at SynodalP?
IMHO, the argument against
We have many modules whose scope does not match the versification. E.g. NT
Bibles, translations with a book or two. Having an adaptive list of books based
upon the modules being viewed is the way to go.
Chris Burrell added some code to JSword that allows for the quick determination
of whether
On Sat, 2013-05-11 at 17:40 -0400, DM Smith wrote:
So, I concur with Chris L but for different reasons.
Seconded. We had actually a discussion a while back re adding a scope
entry to the conf file.
Peter
signature.asc
Description: This is a digitally signed message part
On 5/11/2013 2:28 PM, David Haslam wrote:
Did IBT's programmer actually know that you'd provided it during the period
in question?
Yes, and declined to use it, IIRC. We'd used their own canon.h file and
they transitioned to our Synodal v11n instead.
It might just have been not used due to
25 matches
Mail list logo
