Re: [sword-devel] breakage in verse management at -r2785?
Troy, Karl, It should also be noted that this update to SWORD causes a segfault in the following code in Xiphos https://gist.github.com/anonymous/5187582 Specifically the line key-setAutoNormalize(oldAutoNorm); on line 38 of that Gist generates a SegFault with the following backtrace. #0 0x75278ef0 in std::vectorint, std::allocatorint ::size (this=0x676e6175685a20) at /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_vector.h:626 #1 0x7527724c in sword::VersificationMgr::Book::getVerseMax (this=0xa60028, chapter=17424) at /home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241 #2 0x7525aebb in sword::VerseKey::getVerseMax (this=0x1249a60) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243 #3 0x7525b65b in sword::VerseKey::normalize (this=0x1249a60, autocheck=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353 #4 0x7525bc85 in sword::VerseKey::setAutoNormalize (this=0x1249a60, iautonorm=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1548 #5 0x0049e118 in GTKChapDisp::getVerseBefore (this=0xefc930, imodule=...) at ../src/main/display.cc:1138 This segfault only seems to happen when I enter Genesis 1 in the navigation panel and not at any other time. Those with more gdb savvy than I can maybe figure out more of what is going on. --Greg On Mon, Mar 11, 2013 at 8:57 PM, Karl Kleinpaste k...@kleinpaste.orgwrote: I see that your new showchapter.cpp works. The only difference in how that works versus Xiphos code is you changed the VerseKey init slightly, so I made that change: VerseKey *key = (VerseKey *)imodule.getKey(); And yet Xiphos still fails to construct the chapter. The loop never executes once. I don't know what to make of it. I will have to look at it some more. ___ 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] breakage in verse management at -r2785?
Also, I just committed a fix that permits Xiphos to display text. The issue was, after attempting to fetch material from 0:0 and n:0 the restoration was being done through a call to setBook setChapter setVerse setTestament I moved the setTestament to be the first call and text display works swimmingly. Except I still see the segfault I mentioned in trying to navigate to Genesis 1:1 in both our KJV and ASVD. Xiphos head SVN should work for other references now, though. --Greg On Mon, Mar 18, 2013 at 9:41 AM, Greg Hellings greg.helli...@gmail.comwrote: Troy, Karl, It should also be noted that this update to SWORD causes a segfault in the following code in Xiphos https://gist.github.com/anonymous/5187582 Specifically the line key-setAutoNormalize(oldAutoNorm); on line 38 of that Gist generates a SegFault with the following backtrace. #0 0x75278ef0 in std::vectorint, std::allocatorint ::size (this=0x676e6175685a20) at /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_vector.h:626 #1 0x7527724c in sword::VersificationMgr::Book::getVerseMax (this=0xa60028, chapter=17424) at /home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241 #2 0x7525aebb in sword::VerseKey::getVerseMax (this=0x1249a60) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243 #3 0x7525b65b in sword::VerseKey::normalize (this=0x1249a60, autocheck=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353 #4 0x7525bc85 in sword::VerseKey::setAutoNormalize (this=0x1249a60, iautonorm=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1548 #5 0x0049e118 in GTKChapDisp::getVerseBefore (this=0xefc930, imodule=...) at ../src/main/display.cc:1138 This segfault only seems to happen when I enter Genesis 1 in the navigation panel and not at any other time. Those with more gdb savvy than I can maybe figure out more of what is going on. --Greg On Mon, Mar 11, 2013 at 8:57 PM, Karl Kleinpaste k...@kleinpaste.orgwrote: I see that your new showchapter.cpp works. The only difference in how that works versus Xiphos code is you changed the VerseKey init slightly, so I made that change: VerseKey *key = (VerseKey *)imodule.getKey(); And yet Xiphos still fails to construct the chapter. The loop never executes once. I don't know what to make of it. I will have to look at it some more. ___ 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] breakage in verse management at -r2785?
On Mon, Mar 18, 2013 at 9:41 AM, Greg Hellings greg.helli...@gmail.comwrote: Troy, Karl, It should also be noted that this update to SWORD causes a segfault in the following code in Xiphos https://gist.github.com/anonymous/5187582 Specifically the line key-setAutoNormalize(oldAutoNorm); on line 38 of that Gist generates a SegFault with the following backtrace. #0 0x75278ef0 in std::vectorint, std::allocatorint ::size (this=0x676e6175685a20) at /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_vector.h:626 #1 0x7527724c in sword::VersificationMgr::Book::getVerseMax (this=0xa60028, chapter=17424) at /home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241 #2 0x7525aebb in sword::VerseKey::getVerseMax (this=0x1249a60) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243 #3 0x7525b65b in sword::VerseKey::normalize (this=0x1249a60, autocheck=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353 #4 0x7525bc85 in sword::VerseKey::setAutoNormalize (this=0x1249a60, iautonorm=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1548 #5 0x0049e118 in GTKChapDisp::getVerseBefore (this=0xefc930, imodule=...) at ../src/main/display.cc:1138 I'm still seeing a SegFault as before, after I fixed the issue with other text not displaying. However, the offending line is now display.cc:1130 which is lines 30-32 of the code I pasted above. The stack trace looks like this #0 0x75278ef0 in std::vectorint, std::allocatorint ::size (this=0x676e6175685a20) at /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_vector.h:626 #1 0x7527724c in sword::VersificationMgr::Book::getVerseMax (this=0xa60028, chapter=17424) at /home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241 #2 0x7525aebb in sword::VerseKey::getVerseMax (this=0xdcc290) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243 #3 0x7525b65b in sword::VerseKey::normalize (this=0xdcc290, autocheck=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353 #4 0x7525bbe9 in sword::VerseKey::setVerse (this=0xdcc290, iverse=0) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1523 #5 0x752596b3 in sword::VerseKey::parseVerseList (this=0xeb7fa0, buf=0xea5e1b , defaultKey=0x0, expandRange=false, useChapterAsVerse=false) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:944 #6 0x752570d8 in sword::VerseKey::parse (this=0xeb7fa0, checkAutoNormalize=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:293 #7 0x004922df in sword::VerseKey::setText (this=0xeb7fa0, ikey=0xd04b20 Genesis 0:0) at /usr/local/include/sword/versekey.h:210 #8 0x00492310 in sword::VerseKey::operator= (this=0xeb7fa0, ikey=0xd04b20 Genesis 0:0) at /usr/local/include/sword/versekey.h:475 #9 0x752df98f in sword::OSISFootnotes::processText (this=0xef4920, text=..., key=0xd14a00, module=0xef9618) at /home/ghellings/Projects-old/sword/src/modules/filters/osisfootnotes.cpp:65 #10 0x75296fec in sword::SWModule::filterBuffer (this=0xef9618, filters=0xef90b0, buf=..., key=0xd14a00) at /home/ghellings/Projects-old/sword/src/modules/swmodule.cpp:1352 #11 0x75297aa1 in sword::SWModule::optionFilter (this=0xef9618, buf=..., key=0xd14a00) at /home/ghellings/Projects-old/sword/include/swmodule.h:622 #12 0x75293ea7 in sword::SWModule::renderText (this=0xef9618, buf=0x0, len=-1, render=true) at /home/ghellings/Projects-old/sword/src/modules/swmodule.cpp:826 #13 0x0049219f in sword::SWModule::operator char const* (this=0xef9618) at /usr/local/include/sword/swmodule.h:709 #14 0x0049e093 in GTKChapDisp::getVerseBefore (this=0xf0b420, imodule=...) at ../src/main/display.cc:1130 When I drill all the way down in, the appear to try and pull the verse max for chapter 17424 when asked to render Genesis 0:0. --Greg This segfault only seems to happen when I enter Genesis 1 in the navigation panel and not at any other time. Those with more gdb savvy than I can maybe figure out more of what is going on. --Greg On Mon, Mar 11, 2013 at 8:57 PM, Karl Kleinpaste k...@kleinpaste.orgwrote: I see that your new showchapter.cpp works. The only difference in how that works versus Xiphos code is you changed the VerseKey init slightly, so I made that change: VerseKey *key = (VerseKey *)imodule.getKey(); And yet Xiphos still fails to construct the chapter. The loop never executes once. I don't know what to make of it. I will have to look at it some more. ___ 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] Status of av11n conversions
Hello. There really is done work for av11n conversion support for sword. You even may get patch at https://gitorious.org/~kalemas/sword-svn-mirrors/kalemas_at_mail_ru-trunk/commit/35a3fc6bde1ccff945d51558d7e21ab1074a4152 and use it if you compile libsword for your self. But you also should take into account that this feature is not supported officially and would be incompatible with future releases of Sword. And there is no known schedule for this as this work was not considered for two years. Blessings. Chris Burrell ch...@burrell.me.uk писал(а) в своём письме Tue, 12 Mar 2013 23:44:36 +0400: Hi I was wondering if someone is working on being able to convert from 1 versification system to another. This very important for being to line up verses and therefore very important to STEP for our interlinears. I'm told someone is doing the work for Sword first and then we will bring it across into JSword. Is someone working on this? Does anyone know what the status of this is? Is there a target date for when the design will be finalised such that we can implement this in JSword? Chris -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ ___ 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] Status of av11n conversions
Hi All Troy, thanks for the patch. Would you be able to send it as a text file or something? I'm not sure what I can use to open your attachment? It looks base-64 encoded on my laptop. Konstantin, I've had a brief look and can see lots of numbers. Presumably the numbers are the versifications, and the mappings array is the mappings between two or three or four versifications? The mappings look like they are possibly verse numbers? I was hoping for a versification patching system that might be a bit more supportable/maintainable if possible, i.e. using references to match up between versions. I've copied below my suggestion of a system, originally posted on the JSword list, based on some of the posts I've seen previously in the Sword mailing list. = *Key ideas* - create a converter that goes through to a master versification as you suggested. We define the mappings for those OsisIDs that don't match. The master version is based on the KJV versification (for ease of being able to create new mappings) + the books that aren't in the KJV. - mappings include just the bits that don't match up. - mappings can be define for sets of verses with offset, e.g. Psalm 51:1-5=Psalm 51:1+1 (where +1 indicates an offset of 1 to be applied to the source. - Have the concept of split verses (i.e. Rom 1:1a, Rom 1:1b, etc.) - A tool to create a split in the master versification, which rewrites all the current versifications, such that when someone writes a mapping and needs to split a verse, they can introduce the split without adversely affecting every other mapping. - the lookup process takes an String (OSIS ID) with a source and target versification. (also overload that with Key/Verse). It then queries the master mapping, which returns 1 or more entries (an entry being a whole verse, or set of split verses). Then goes to reverse mappings for the target versification and does the same. For incomplete verses on one side or the other, we round up the closest verse. - The reason for basing the versification on KJV (or some other English versification), is that's it easy to work against. The alternative would be to go for the most split versification ever found, but that becomes painful in the future if someone decides to split another verse in 2 parts. - When introducing a split, we would want to record what the split actually refers to (i.e. what content). This wouldn't be used by the library, but instead be useful for people coming along and writing new mappings. = *And here are some examples of how it would work in practice:* *2 verse in the original, 1 verse in the KJV-based master* Gen.1.1=Gen.1.1 Gen.1.2=Gen.1.1 *1 verse in the original, 2 verses in the master* Gen.1.1=Gen.1.1-Gen.1.2 *Using splits, so that 2 separate versifications can refer to the same parts of verses* Gen.1.1=Gen.1.1a Gen.1.2=Gen.1.1b Gen.1.3=Gen.1.1.c Then another versification can also refer to the same parts. It would become necessary to keep track of what the parts are, such that they can be easily re-used when approrpriate. For example, a second versification might be mapped as follows: Gen.1.1=Gen.1.1a-Gen.1.1b Gen.1.2=Gen.1.c *No mapping* Osis IDs mean the same thing. I think the above covers, Split verse, Merged verse, Different verse boundaries. *Chapter boundaries can be mapped equally the same:* Gen.1.1=Gen.1.1 Gen.1.2=Gen.2.1 indicates that that Genesis 1:2 can be found in Gen 2:1 in the master. *Extra verses* We simply introduce some identified ids (osis ids, or other form of unique identifier) in the master to identify the content of these verses Additional verses within a chapter can be represented using the above. *Psalm headings:* Ps.53.1=Ps.53.1 (not required, or required if map it to 'nothing' or '0') Ps.53.2=Ps.53.1 Ps.53.3=Ps.53.2 We can reduce this to if we want to introduce a less verbose way of mapping things. Ps.53.2-7-=Ps.53.1-+1 (where minus simply indicates that there is an offset of 1 compared to the master) *Absent verses* absent=Gen1.91,Gen.2.32 *For new sections in the middle:* We invent some new ideas, for example in Daniel, we could have the mappings: Dan.3.24=songofchildren.1 Dan.3.25=songofchildren.2 ... I don't think we need to introduce splits on the left hand-side. The reason being, you can't do anything with an OSIS id of Gen.1.1a, since you're going to retrieve a whole verse anyway, so we can keep things with splits only-ever on the right hand side. Splits are only used to refer to the master system. They are not necessary but they add resolution to the mapping lookups. Here's the reason. If a and b split verses in a similar way we would like to be able to go from a to b without ending up with a bigger chunk of text. Gen.1.1=Gen.1.1a Gen.1.2=Gen.1.1b If both versifications define the above we can go from gen.1.1 in one versification to the equivalent in the target. Without the split, the intermediate master resolves to gen.1.1 which in turn resolves to
Re: [sword-devel] breakage in verse management at -r2785?
Thanks Greg, Any idea where chapter 17474 is coming from? I can add code to check max before looking into the vector, which I'd rather not because it should be an unnecessary check each time and will be a speed hit, but even so, who ever is asking for the maximum verse for chapter 17474 is obviously doing something wrong. I'll try to have a look soon. Troy On 03/18/2013 05:12 PM, Greg Hellings wrote: #1 0x7527724c in sword::VersificationMgr::Book::getVerseMax (this=0xa60028, chapter=17424) at /home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241 #2 0x7525aebb in sword::VerseKey::getVerseMax (this=0xdcc290) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243 #3 0x7525b65b in sword::VerseKey::normalize (this=0xdcc290, autocheck=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353 #4 0x7525bbe9 in sword::VerseKey::setVerse (this=0xdcc290, iverse=0) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1523 #5 0x752596b3 in sword::VerseKey::parseVerseList (this=0xeb7fa0, buf=0xea5e1b , defaultKey=0x0, expandRange=false, useChapterAsVerse=false) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:944 #6 0x752570d8 in sword::VerseKey::parse (this=0xeb7fa0, checkAutoNormalize=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:293 #7 0x004922df in sword::VerseKey::setText (this=0xeb7fa0, ikey=0xd04b20 Genesis 0:0) at /usr/local/include/sword/versekey.h:210 #8 0x00492310 in sword::VerseKey::operator= (this=0xeb7fa0, ikey=0xd04b20 Genesis 0:0) at /usr/local/include/sword/versekey.h:475 #9 0x752df98f in sword::OSISFootnotes::processText (this=0xef4920, text=..., key=0xd14a00, module=0xef9618) at /home/ghellings/Projects-old/sword/src/modules/filters/osisfootnotes.cpp:65 #10 0x75296fec in sword::SWModule::filterBuffer (this=0xef9618, filters=0xef90b0, buf=..., key=0xd14a00) at /home/ghellings/Projects-old/sword/src/modules/swmodule.cpp:1352 #11 0x75297aa1 in sword::SWModule::optionFilter (this=0xef9618, buf=..., key=0xd14a00) at /home/ghellings/Projects-old/sword/include/swmodule.h:622 #12 0x75293ea7 in sword::SWModule::renderText (this=0xef9618, buf=0x0, len=-1, render=true) at /home/ghellings/Projects-old/sword/src/modules/swmodule.cpp:826 #13 0x0049219f in sword::SWModule::operator char const* (this=0xef9618) at /usr/local/include/sword/swmodule.h:709 #14 0x0049e093 in GTKChapDisp::getVerseBefore (this=0xf0b420, imodule=...) at ../src/main/display.cc:1130 When I drill all the way down in, the appear to try and pull the verse max for chapter 17424 when asked to render Genesis 0:0. --Greg This segfault only seems to happen when I enter Genesis 1 in the navigation panel and not at any other time. Those with more gdb savvy than I can maybe figure out more of what is going on. --Greg On Mon, Mar 11, 2013 at 8:57 PM, Karl Kleinpaste k...@kleinpaste.org mailto:k...@kleinpaste.org wrote: I see that your new showchapter.cpp works. The only difference in how that works versus Xiphos code is you changed the VerseKey init slightly, so I made that change: VerseKey *key = (VerseKey *)imodule.getKey(); And yet Xiphos still fails to construct the chapter. The loop never executes once. I don't know what to make of it. I will have to look at it some more. ___ sword-devel mailing list: sword-devel@crosswire.org mailto: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] Status of av11n conversions
Konstantin,
Thanks very much for the work you've done.
I'm trying to understand the data structure. JSword is an independent
implementation and doesn't use SWORD libraries. So to implement something like
this, it'll be helpful to understand what the data structures and the data
means.
If I understand, you are using the KJVA as the common bridge between different
versifications.
For the NRSV you have the following:
unsigned char mappings_nrsv[] = {
0,
66, 12, 18, 19, 13, 1, 0,
66, 13, 1, 1, 13, 1, 0,
0
};
If I read this correctly, 66 refers to Revelation (with the books are numbered
from 1 for Genesis to 66 for Rev as appears in the KJV, and all apocryphal
books are numbered higher than the canonical ordered as in the KJVA).
In the first non-zero row, the 66, 12, 18, 19 means Rev 12:18-19 from the NRSV.
And the 13, 1, 0 means Rev 13:1 in the KJV.
So basically, NRSV Rev 12:18-19 is the same as KJV Rev 13:1.
When I look into the NRSV versification in SWORD, I'm seeing that Rev 12 goes
to verse 18. Whereas the KJV goes to verse 17. Where does the 19 come in?
The next line has 66, 13, 1, 1 (So NRSV 13:1) maps to 13, 1, 0 (to KJV 13:1).
Putting all of this together, KJV 13:1 is NRSV 12:18-13:1.
Curious why is it 66, 13, 1, 1 and not 66, 13, 1, 0?
Am also wondering why there's no entry for John 3. In the NRSV, there are 15
verses but in the KJV there are 14. So shouldn't there be a line with:
64, 1, 14, 15, 1, 14, 0
I'm sure as I dig into Synodal, I'll have more questions. But I wait until I
find out whether I'm missing something here.
In Him,
DM
On Mar 18, 2013, at 3:24 PM, Konstantin Maslyuk kostyamasl...@gmail.com
wrote:
Hello. There really is done work for av11n conversion support for sword. You
even may get patch at
https://gitorious.org/~kalemas/sword-svn-mirrors/kalemas_at_mail_ru-trunk/commit/35a3fc6bde1ccff945d51558d7e21ab1074a4152
and use it if you compile libsword for your self. But you also should take
into account that this feature is not supported officially and would be
incompatible with future releases of Sword. And there is no known schedule
for this as this work was not considered for two years.
Blessings.
Chris Burrell ch...@burrell.me.uk писал(а) в своём письме Tue, 12 Mar 2013
23:44:36 +0400:
Hi
I was wondering if someone is working on being able to convert from 1
versification system to another. This very important for being to line up
verses and therefore very important to STEP for our interlinears.
I'm told someone is doing the work for Sword first and then we will bring
it across into JSword.
Is someone working on this? Does anyone know what the status of this is? Is
there a target date for when the design will be finalised such that we can
implement this in JSword?
Chris
--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
___
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] breakage in verse management at -r2785?
On Mon, Mar 18, 2013 at 5:07 PM, Troy A. Griffitts scr...@crosswire.orgwrote: Thanks Greg, Any idea where chapter 17474 is coming from? I can add code to check max before looking into the vector, which I'd rather not because it should be an unnecessary check each time and will be a speed hit, but even so, who ever is asking for the maximum verse for chapter 17474 is obviously doing something wrong. I'm hardly competent with a C debugger, but let's see what sense I can make of this. Somewhere in VerseKey::parseVerseList on line 944 (#5 in the stack trace) curKey has a value of 17425 for chapter. The text buffer reads Genesis 1:0 and the value of the chap variable is 1. The value of 17,425 is being set on line 1351 of versekey.cpp when a key value of Genesis 1:0 is being parsed while intros == 0. This triggers the condition if (verse (intros?0:1)) which causes the resulting block to be executed. Xiphos believes that headings have been enabled here, and Xiphos has always considered 'Headings' and 'Introductions' to be synonymous from my understanding. I know there's been some discussion of the Headings/Intro distinction here lately, so I don't know if Xiphos is now running afoul of changes you made in this distinction due to prior bugs in the implementation that unified them or not? I'm not sure if there's more I can contribute here without a deeper understanding of Xiphos' options and SWORD's parsing. --Greg I'll try to have a look soon. Troy On 03/18/2013 05:12 PM, Greg Hellings wrote: #1 0x7527724c in sword::VersificationMgr::Book::getVerseMax (this=0xa60028, chapter=17424) at /home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241 #2 0x7525aebb in sword::VerseKey::getVerseMax (this=0xdcc290) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243 #3 0x7525b65b in sword::VerseKey::normalize (this=0xdcc290, autocheck=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353 #4 0x7525bbe9 in sword::VerseKey::setVerse (this=0xdcc290, iverse=0) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1523 #5 0x752596b3 in sword::VerseKey::parseVerseList (this=0xeb7fa0, buf=0xea5e1b , defaultKey=0x0, expandRange=false, useChapterAsVerse=false) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:944 #6 0x752570d8 in sword::VerseKey::parse (this=0xeb7fa0, checkAutoNormalize=true) at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:293 #7 0x004922df in sword::VerseKey::setText (this=0xeb7fa0, ikey=0xd04b20 Genesis 0:0) at /usr/local/include/sword/versekey.h:210 #8 0x00492310 in sword::VerseKey::operator= (this=0xeb7fa0, ikey=0xd04b20 Genesis 0:0) at /usr/local/include/sword/versekey.h:475 #9 0x752df98f in sword::OSISFootnotes::processText (this=0xef4920, text=..., key=0xd14a00, module=0xef9618) at /home/ghellings/Projects-old/sword/src/modules/filters/osisfootnotes.cpp:65 #10 0x75296fec in sword::SWModule::filterBuffer (this=0xef9618, filters=0xef90b0, buf=..., key=0xd14a00) at /home/ghellings/Projects-old/sword/src/modules/swmodule.cpp:1352 #11 0x75297aa1 in sword::SWModule::optionFilter (this=0xef9618, buf=..., key=0xd14a00) at /home/ghellings/Projects-old/sword/include/swmodule.h:622 #12 0x75293ea7 in sword::SWModule::renderText (this=0xef9618, buf=0x0, len=-1, render=true) at /home/ghellings/Projects-old/sword/src/modules/swmodule.cpp:826 #13 0x0049219f in sword::SWModule::operator char const* (this=0xef9618) at /usr/local/include/sword/swmodule.h:709 #14 0x0049e093 in GTKChapDisp::getVerseBefore (this=0xf0b420, imodule=...) at ../src/main/display.cc:1130 When I drill all the way down in, the appear to try and pull the verse max for chapter 17424 when asked to render Genesis 0:0. --Greg This segfault only seems to happen when I enter Genesis 1 in the navigation panel and not at any other time. Those with more gdb savvy than I can maybe figure out more of what is going on. --Greg On Mon, Mar 11, 2013 at 8:57 PM, Karl Kleinpaste k...@kleinpaste.orgwrote: I see that your new showchapter.cpp works. The only difference in how that works versus Xiphos code is you changed the VerseKey init slightly, so I made that change: VerseKey *key = (VerseKey *)imodule.getKey(); And yet Xiphos still fails to construct the chapter. The loop never executes once. I don't know what to make of it. I will have to look at it some more. ___ 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:
