[sword-devel] usfm2osis.py

[Robert Hunt]

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 <dfhmch at 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.