On 5/22/2013 3:26 AM, Robert Hunt wrote:
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.
Indeed... I only fixed the bug that you reported, not the bug you didn't
report. ;) If you can provide a bug report with some input that
predictably produces erroneous output or gets stuck, I can fix the bug.
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.)
I'm not sure what could concern you about a multithreaded application.
In this case, the script gives each USFM file to a separate thread for
processing and does them in parallel, attempting to keep all of your
processor's logical cores fully utilized. You can always turn
multithreading off (i.e. set the thread count to 1), but it really won't
change anything other than the running time.
--Chris
_______________________________________________
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
