Re: [sword-devel] ppc64le build error
Yes, it is a sizeable patch. Although there might be hacks around this issue, getting rid of the reserved identifiers and using the fixed-width types from seems to be the correct approach to take. I'm not even sure the patch applies correctly to Sword SVN trunk, but since this issue has long been fixed in Sword++, I referred to this commit in hopes to accelerate this getting fixed for Sword as well. I think it would not benefit anyone if Sword was left failing on Fedora rawhide. +Jaak On 18.07.19 06:47, Greg Hellings wrote: > That is a rather sizeable patch. I don't want to just apply it wholesale to > the Sword engine without some input from people who know more about the > code than I do. It should, however, be workable if Troy doesn't have a more > permanent fix in mind. > > --Greg > > On Wed, Jul 17, 2019 at 4:52 PM Jaak Ristioja wrote: > >> In Sword++ we fixed [1] this by using the fixed-width integer types >> provided by . Note also that some certain names containing >> underscores are reserved to the C++ implementation [2], e.g. names >> beginning with underscores and names containing adjacent underscores. >> >> >> Best regards, >> Jaak >> >> >> [1]: Feel free to integrate >> >> https://github.com/swordxx/swordxx/commit/3934674fd8db1302cc323c0a56235292d6d7 >> back to Sword. In Sword++ most of these type names were later prefixed >> with std::, e.g. std::uint64_t instead of plain uint64_t. >> >> [2]: See https://stackoverflow.com/a/228797 for a good summary on this. >> >> >> On 17.07.19 17:52, Greg Hellings wrote: >>> I got an automated report this week that Sword 1.8.1 has begun failing to >>> build on ppc64le architecture with type redefinition errors. The errors >> are >>> reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1730318 >>> >>> To copy from that link, the relevant error is: >>> >>> /usr/include/asm-generic/int-l64.h:29:25: error: conflicting >>> declaration 'typedef long int __s64' >>> 29 | typedef __signed__ long __s64; >>>| ^ >>> >>> /usr/include/asm-generic/int-l64.h:30:23: error: conflicting >>> declaration 'typedef long unsigned int __u64' >>> 30 | typedef unsigned long __u64; >>>| ^ >>> >>> I try to shy away from knowing too much about C's typing system. I can >>> easily locate the places in our code where we are defining those types >>> ourself. However, I don't want to mess up proper detection and >>> definition of them in a patch if I can help it. >>> >>> --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 >>> >> >> >> ___ >> 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] How to deal with invalid markup?
Thank you, Michael! Exodus 3:22 looks fine now after upgrading from engNET2016eb 25.2 to 25.4. Best regards, Tobias On 18.07.19 02:51, Michael Johnson wrote: Mea culpa. Sorry about that. The engNET2016eb module has been updated to get rid of some residual XHTML notes at ends of chapters that were missed in the first filtering process. Oddly enough, the result was actually valid XML syntax, but its semantics were wrong. On 7/16/19 9:36 PM, David Haslam wrote: Hi Tobias, OSIS Modules submitted for release by CrossWire should always be validated prior to submission. They would be rejected if the XML cannot be validated to one of the OSIS schemas that SWORD supports. All the more so if the input file fails to pass an XML syntax check. CrossWire has no control over the preparation of modules for the associated repositories such as eBible.org Such errors should be reported to the repository owner, in this case Kahunapule Michael Paul Johnson. He is a member of this mailing list. Best regards, David Sent from ProtonMail Mobile On Wed, Jul 17, 2019 at 07:13, Tobias Klein mailto:cont...@tklein.info>> wrote: Hi everyone, Is there a recommended way on how to deal with invalid markup (in a frontend) when using the text from a Sword module? To me invalid markup is basically invalid XML. You find an example below (Exodus 3:22 / engNET2016eb). Are Sword modules validated with standard XML validation tools before being published? Best regards, Tobias Module: engNET2016eb Mark-up text of Exodus 3:22 (module->getRawEntry()): Every woman will ask her neighbor and the one who happens to be staying in her house for items of silver and gold and for clothing. You will put these articles on your sons and daughters – thus you INVALID section starts here: will plunder Egypt*!” ‘*span class=”footnote” id=”footnote-65”*’‘*span class=”key”’65‘ a**href=”#note-65” class=”backref”’*3:19‘/a’‘*span class=”text”’ tn: Heb “ and not with a mighty hand.” ... ___ 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] How to deal with invalid markup?
I just checked how the "plaintext" version of engNET2016eb Exodus 3:22 looks like. Whereas all the other verses are actually returned with no markup, this particular verse is still returned like this (using module->stripText()): Every woman will ask her neighbor and the one who happens to be staying in her house for items of silver and gold and for clothing. You will put these articles on your sons and daughters – thus you will plunder Egypt!”‘span class=”footnote” id=”footnote-65”’‘span class=”key”’65‘a href=”#note-65” class=”backref”’3:19‘/a’‘span class=”text”’ *tn*: *Heb* “and not with a mighty hand.” This expression (וְלֹא בְּיָד חֲזָקָה, vÿlo’ vÿyad khazaqa) is unclear, since v. 20 says that God will stretch out his hand and do his wonders. Some have taken v. 19b to refer to God’s mighty hand also, meaning that the king would not let them go unless a mighty hand compels him (NIV). The expression “mighty hand” is used of God’s rescuing Israel elsewhere ( Exod 6:1, 13:9, 32:11; but note also Num 20:20). This idea is a rather general interpretation of the words; it owes much to the LXX, which has “except by a mighty hand,” though “and not with” does not have the meaning of “except” or “unless” in other places. In view of these difficulties, others have suggested that v. 19b means “strong [threats]” from the Israelites (as in 4:24ff. and 5:3; see B. Jacob, *Exodus*, 81). This does not seem as convincing as the first view. Another possibility is that the phrase conveys Pharaoh’s point of view and intention; the Lord knows that Pharaoh plans to resist letting the Israelites go, regardless of the exercise of a strong hand against him (P. Addinall, “Exodus III 19B and the Interpretation of Biblical Narrative,” *VT* 49 [1999]: 289-300; see also the construction “and not with” in Num 12:8; 1 Sam 20:15 and elsewhere). If that is the case, v. 20 provides an ironic and pointed contradiction to Pharaoh’s plans as the Lord announces the effect that his hand will have. At any rate, Pharaoh will have to be forced to let Israel go. I guess the SWORD engine is not able to filter out the markup in this particular case. Using plaintext as a fallback option may not be sufficient. Best regards, Tobias On 17.07.19 22:12, Tobias Klein wrote: Thanks, good advice! Especially the idea about dynamically validating markup text and then going for the plain text version as a fallback. I'll think about using that option in node-sword-interface (Ezra Project's SWORD integration library). Best regards, Tobias On 17.07.19 13:59, Peter Von Kaehne wrote: 1) The best way is to recognise it and either fall back to something sane or refuse to deal with the module without crashing. You could presumably if an xml chunk is delivered by the engine to you and is not internally valid ask the engine to re-render it plainly and spit out some message to that effect on the terminal. Then a use may be in the position to see this and send a bug report to whoever is responsible for the dodgy module. 2) CrossWire modules are for teh last 10 years or so always tested and validated before they are published but other repositories are subject to their own rules. The module you reference is from eBible and not CrossWire. But - admittedly - we have in CrossWire still a lot of old modules which may well have bugs which only show up slowly. Peter *Gesendet:* Mittwoch, 17. Juli 2019 um 07:13 Uhr *Von:* "Tobias Klein" *An:* "SWORD Developers' Collaboration Forum" *Betreff:* [sword-devel] How to deal with invalid markup? Hi everyone, Is there a recommended way on how to deal with invalid markup (in a frontend) when using the text from a Sword module? To me invalid markup is basically invalid XML. You find an example below (Exodus 3:22 / engNET2016eb). Are Sword modules validated with standard XML validation tools before being published? Best regards, Tobias Module: engNET2016eb Mark-up text of Exodus 3:22 (module->getRawEntry()): Every woman lemma="strong:H7592">will ask her neighbor and the one who happens to be staying in her house lemma="strong:H3627">for items of silver and gold lemma="strong:H8071">and for clothing. lemma="strong:H7760">You will put these articles on lemma="strong:H1121">your sons and daughters – thus you INVALID section starts here: will plunder Egypt*!” ‘*span class=”footnote” id=”footnote-65”*’‘*span class=”key”’65‘ a**href=”#note-65” class=”backref”’*3:19‘/a’‘*span class=”text”’ type="italic">tn: Heb “ and not lemma="strong:H1004">with a mighty hand.” ... ___ 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
