Yes, it seems that Chris did indeed fix the script so that my supplied
minimal test case no longer causes the program to require a manual halt.
:-)
Unfortunately though, processing of that particular USFM field wasn't my
main issue. The main issue seems to be that the program does not fail
gracefully if a processing fault is hit in the USFM to OSIS conversion.
So I still have to manually halt the script to try to track down the
next USFM processing error. (I suspect the main problem that I'm
concerned about is in the multiprocessing aspect of the script.)
Robert.
On 22/05/13 21:25, Nic Carter wrote:
Look at the latest SVN commit. Seems related :)
On 22/05/2013, at 18:13, David Haslam <dfh...@googlemail.com> wrote:
http://www.crosswire.org/tracker/browse/MODTOOLS-40 has been closed by
Chris, but without a explanatory closing comment.
It does rather look as though you'll need to isolate the next USFM tag which
causes such a loop, and then create a new issue.
As it happens, I'm still waiting for Chris to respond to
http://www.crosswire.org/tracker/browse/MODTOOLS-42
for which I have provided the full set of USFM files (for the particular
translation this relates to) plus a screenshot showing the faulty line group
elements in the OSIS output.
_______________________________________________
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
