On Jul 16, 2011, at 3:57 PM, David Troidl wrote:
>
>
> On 7/16/2011 3:03 PM, DM Smith wrote:
>> It is possible at least in part. Just define a v11n with 200 chapters per
>> book and 200 verses per book. This doesn't handle alternate book order.
> I think you misunderstood.
Rereading your post
Ok, I did what Troy initially recommended, i.e. Checking if
VerseKey.getVerse()>VerseKey.getMaxVerse, ditto for the chapter. If this is
true, I used ListKey.SetToElement() and ListKey.Remove() to remove the invalid
reference(s).
Works great.
I can see the utility of wrapping for interactiv
I. Currently
1) We force module developers to choose a v11n. This is painful for
them, but in their own interest, as it will enable their module to work
within the future utopia of a cross-module equivalent content
reconciliation implementation (CMECRI, pronounced: see-me-cry)
2) The downsid
I think it would be just a binarized canon header file:
string, string, string, int,
string string, string, int,
. . .
DM Smith писал(а) в своём письме Sat, 16 Jul 2011
18:07:21 +0400:
For JSword, I'm planning on having the v11n in external resources. If
the performance is not good, then
On 7/16/2011 3:03 PM, DM Smith wrote:
It is possible at least in part. Just define a v11n with 200 chapters per book
and 200 verses per book. This doesn't handle alternate book order.
I think you misunderstood. Haggai has 2 chapters in any v11n I know
of. It would continue to have 2 chapter
On 7/16/2011 12:03 PM, DM Smith wrote:
It is possible at least in part. Just define a v11n with 200 chapters per book
and 200 verses per book. This doesn't handle alternate book order.
I used 200 but any suitably large number would work.
The other problem is that verse++ at the real end of a c
Troy, Thanks so much for the reply.
I added parser.setAutoNormalize(false) before the result =
parser.ParseVerseList() in verserangeparser.cpp. Now when I run the program
with an invalid reference like jn22:1, I don't get any output but it looks like
it errors out, even if I have some valid
It is possible at least in part. Just define a v11n with 200 chapters per book
and 200 verses per book. This doesn't handle alternate book order.
I used 200 but any suitably large number would work.
The other problem is that verse++ at the real end of a chapter would neither
advance to the fi
Wouldn't it be possible to have one "master" v11n, that all the others
could map to (linear growth), rather than trying to map them all to each
other (exponential growth)?
For example:
1) Psalm 3 could retain the Hebrew Bible numbering, and KJV map the
heading to 3:1, and 3:1 to 3:2, etc.
2) P
Sorry, infinite loop typo...
On 16/07/11 17:56, Troy A. Griffitts wrote:
> // show a context window
> int contextWindow = 5;
- for (verseKey-=(contextWindow/2); !verseKey.Error() && contextWindow;
verseKey++) ...
+ for (verseKey-=(contextWindow/2); !verseKey.Error() && contextWindow;
verseKey++,con
Hey Alex,
Well, it depends on what behavior you want to happen when parsing an
'invalid verse reference'.
1) Error() should be raised when parsing is completely misunderstood
2) You can set VerseKey::Normalize to false, and arguably Error() should
be raised when parsing chapters and verses outsi
Hi folks,
I'm just getting started with Sword, and Im working through the included
examples. How can I prevent the verse parser from mapping a non valid reference
to the next logical book/chapter?
For example if I run verserangeparse (in /examples) with "jn22:1" I get acts
1:1, which is the ne
For JSword, I'm planning on having the v11n in external resources. If the
performance is not good, then it'll be moved internally. Can we define the
format of the file? That way, we won't need to change it if SWORD ever
externalizes it.
In Him,
DM
On Jul 16, 2011, at 6:33 AM, Troy A. G
On Sat, Jul 16, 2011 at 6:04 AM, David Haslam wrote:
> I've been following the thread and I think that's a fair summary, Troy.
>
> Though we have not yet come across such a translation, it's also conceivable
> that in future we may receive a set of USFM files that make some use of the
> *\va* and
On 16/07/11 12:33, Troy A. Griffitts wrote:
> III) Konstantin clarified/proposed a hybrid system where we still seek
> to define 'canonical' (no pun intended) internal v11ns, but if an
> internal v11n doesn't yet exist for a module, then the module developer
> can provide a private v11n used only f
I've been following the thread and I think that's a fair summary, Troy.
Though we have not yet come across such a translation, it's also conceivable
that in future we may receive a set of USFM files that make some use of the
*\va* and *\ca* tags.
I've described this in the wiki, when I added the
Thanks Seb.
Very useful page, though as he states in the header paragraph,
"The comparison below of the various versions of the Bible in terms of
divisions into chapters and verses was made on a selection of Bibles
somewhat arbitrary, some quite common translations were not analyzed."
No mention
OK, to summarize where we are, for those who haven't read all the
details and would like to jump in this weekend on the conversation
(Konstantin, please correct me if I've misrepresented your position).
I) Konstantin proposed 2 possibly paths and outlined the benefits and
drawback for both, favori
Here is a french page describing versification for some translations, mostly
french. There nothing about psalms headers.
http://bibliquest.org/Bibliquest/Bibliquest-Discordances_de_numerotation_des_versets.htm
Some points from the header of this page:
- Versification came from english bishop Ste
Chris,
Yes - I'm talking about each single translation in its own right.
See also
http://fr.wikipedia.org/wiki/Traductions_de_la_Bible_en_fran%C3%A7ais
My own printed French Bible is Version Synodale 1962, but I'm pretty sure it
is in a long line of tradition that follows the same v11n, which in
Indeed, possibility to use module-supplied v11n can seriously simplify
process of development multiple v11ns.
If was discovered that any built-in v11n or mappings contain errors we can
update that module with module-supplied v11n, then after new version of
engine and applications will be re
21 matches
Mail list logo
