<div dir="ltr">As to checking for (consecutive) linked verses, you can do something like this (horrible, but should work in theory - I haven't tested it):<br><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">// keep the key we were at</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">SWKey* k = module.getKey().clone();</span><br style="font-family: courier new,monospace;"><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">// move forward without skipping over links</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">module.setSkipConsecutiveLinks(false);</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">module.increment();</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">SWKey* k_2 = module.getKey().clone();</span><br style="font-family: courier new,monospace;"><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">// now go back and try again skipping over links</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">module.setKey(k)</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">module.setSkipConsecutiveLinks(true);</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">module.increment();</span><br style="font-family: courier new,monospace;"><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">// If k != module.getKey(), we skipped over some links</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">boolean linked = !(module.getKey().equals(k2));</span><br><br>I don't believe you can easily check for non-consecutive verses being linked - not that it makes all that much sense.<br clear="all">
God Bless,<br>Ben<br>-------------------------------------------------------------------------------------------<br>The Lord is not slow to fulfill his promise as some count slowness,<br>but is patient toward you, not wishing that any should perish,<br>
but that all should reach repentance.<br>2 Peter 3:9 (ESV)<br>
<br><br><div class="gmail_quote">On Fri, Sep 5, 2008 at 8:14 AM, Troy A. Griffitts <span dir="ltr"><<a href="mailto:scribe@crosswire.org">scribe@crosswire.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Right, it seems like we might need a bool SWModule::isLinked(const SWKey<br>
&) which tells you if the current location is linked to the provided<br>
location. Something which compares 'inodes' in versetext and @link<br>
values in others, etc...<br>
<br>
That's doable from the engine point of view, but I'm not sure will solve<br>
your problem.<br>
<br>
Like you mention, you're looking for a way to get the entire set of<br>
entries that link to a data slot. Something like:<br>
<br>
find / -samefile xyz -print<br>
<br>
I guess you could use the newly proposed method above to iterate all<br>
entries and check if any are the 'samefile' as one you are interested<br>
in. But like the filesystem, we don't store a set of all directory<br>
entries that happen to point to the same inode. And if you're looking<br>
for backward compatability, we can't change the format (not that I would<br>
want to change the format for this anyway).<br>
<br>
With the the logic osis2mod is using (for any verses outside of KJV,<br>
read text from closest previous valid KJV entry, append new verse text<br>
and rewrite the entry) it sounds these exception KJV-reversifications<br>
should probably do the ugly: `find / -samefile xyz -print` logic to<br>
check if the entry they are about to rewrite is linked to by anyone<br>
else. It sucks, but it is all I can think of that would solve this<br>
problem. And pragmatically, you probably only have to: do { module--; }<br>
while (!module.Error() && module.getRawEntryBuf() ==<br>
aboutToBeRewrittenEntryBuf);<br>
<br>
Hope I haven't pass the buck for no good reason.<br>
<font color="#888888"><br>
-Troy.<br>
</font><div><div></div><div class="Wj3C7c"><br>
DM Smith wrote:<br>
> Greg Hellings wrote:<br>
>> DM,<br>
>><br>
>> On Thu, Sep 4, 2008 at 1:05 PM, DM Smith <<a href="mailto:dmsmith555@yahoo.com">dmsmith555@yahoo.com</a>> wrote:<br>
>><br>
>>> I'm trying to solve an osis2mod linking bug that was exposed by several<br>
>>> beta modules.<br>
>>><br>
>>> Here is the scenario:<br>
>>> <verse osisID="XXX.1.29 XXX.1.30 XXX.1.31">Text for the last three<br>
>>> verses of XXX, chapter 1 in the KJV versification</verse><br>
>>> <verse osisID="XXX.1.32 XXX.1.33">Text for additional verses in the XXX,<br>
>>> chapter 1 in the non-KJV versification</verse><br>
>>><br>
>>> 1) osis2mod links 1.30 and 1.31 by writing out the start and offset of<br>
>>> the data for 1.29. That means that 1.29 has to be written first. In the<br>
>>> index file the result is that all three entries have the same start and<br>
>>> offset. So far so good, if there weren't a bug that writes the links<br>
>>> first and then the data, resulting in start/offset of 0/0 for the links.<br>
>>> But I've already figured out how to fix that bug.<br>
>>><br>
>>> 2) Now a non-KJV verse is found and osis2mod appends it to the last<br>
>>> verse of the chapter according to the KJV versification. So the entry<br>
>>> for XXX.1.31 is found, the raw text is gotten and it is appended and<br>
>>> this augmented text is written to the data file, at the end of the file.<br>
>>> Finally the index entry for XXX.1.31 is updated.<br>
>>><br>
>>> The problem is that 1.29 and 1.30 are not updated, they still point to<br>
>>> the "1.29-1.31" text and now 1.31 points to the "1.29-1.33" text.<br>
>>><br>
>>> 3) The other problem is with 1.33, it is noticed that it is out of<br>
>>> bounds and is changed to 1.31 and then it is linked to 1.32, which does<br>
>>> not exist and thus 1.31 is re-written to 0/0.<br>
>>><br>
>>> I'm looking for a way to solve these problems. Here is what I am<br>
>>> thinking and I'd like feedback or a better way.<br>
>>> For 1) I have postponed the writing of the links until the verse is<br>
>>> written. I could either wait until the next verse is ready to be<br>
>>> written, or later. I've decided to wait until the very end and do the<br>
>>> linking then. This might help solve 2 and 3.<br>
>>><br>
>>> For 2) I'm thinking that the verse to append is the last verse in the<br>
>>> chapter with content. By postponing linking until later, it will append<br>
>>> to 1.29. Then the linking will propagate the final start/offset values<br>
>>> for 1.29. The problem I have with this is that this is somewhat disk<br>
>>> intensive. I start with the last verse in the chapter and get the raw<br>
>>> text for it. If there is none, I then decrement and refetch until I find<br>
>>> it. I looked for a way to know if a verse were part of a linked set and<br>
>>> what the members of that set were, but I didn't see any in the SWORD<br>
>>> engine. Am I missing it?<br>
>>><br>
>> When I ran into this bug in dabbling with a SWORD front-end, I was<br>
>> told that the only way to test for whether it is part of a set is to<br>
>> compare the text of verse x with verse x-1. I don't know that the<br>
>> feature we both sought has been added. If it has, I haven not heard<br>
>> word of it.<br>
>><br>
> Ouch, that is expensive. It should not be necessary to dig down to the<br>
> text and then do a string comparison. Comparing the start/offset<br>
> (block/start/offset for compressed) is sufficient. I don't see how to<br>
> get this info. It would be nice to have the ability, in the engine, to<br>
> compare two keys to see if they refer to the same text.<br>
><br>
>> Alternatively -- aren't we supposed to be moving to the VerseTreeKey?<br>
>> Shouldn't a new module in the Beta stage be using that? It seems like<br>
>> that would completely do away with the problem. Updating osis2mod to<br>
>> use that, either as the default or as an option for a module like this<br>
>> might eliminate the issue?<br>
>><br>
> I think ultimately that osis2mod will need to be updated to handle other<br>
> versifications. The VerseKey module type is significantly faster than a<br>
> VerseTreeKey module will ever be.<br>
><br>
> My goal in modifying osis2mod is that it will create 1.5.9 compatible<br>
> modules.<br>
><br>
> Later, I intend to make modifications that will require <a href="http://1.5.12." target="_blank">1.5.12.</a><br>
> (Specifically, an extension of preverse content that we've discussed<br>
> here that will have a preverse div and not just a preverse title.) At<br>
> that time, it would also be appropriate to handle VerseTreeKey as an option.<br>
>><br>
>>> For 3) this is fairly simple, one should not link verses that are not in<br>
>>> the KJV versification.<br>
>>><br>
>> That seems like a very stringent restriction. If linking is supported<br>
>> for the KJV system, why should it not be allowed for other systems?<br>
>> It seems like linking should be fixed in a way to allow everyone to do<br>
>> it.<br>
> It's not a stringent restriction for the current osis2mod which only<br>
> works for KJV versifications. Later, when osis2mod is upgraded then that<br>
> restriction will need to be removed.<br>
><br>
> In Him,<br>
> DM<br>
><br>
><br>
><br>
> _______________________________________________<br>
> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
> Instructions to unsubscribe/change your settings at above page<br>
<br>
<br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</div></div></blockquote></div><br></div>