<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Thanks Chris. Yes, multiprocessing is great on my i7. <span
class="moz-smiley-s1"><span> :-) </span></span><br>
<br>
Actually the bug I <a
href="http://www.crosswire.org/tracker/browse/MODTOOLS-40">reported</a>
was "usfm2osis.py enters infinite loop". The bug that was fixed was
something like "\periph USFM doesn't process properly".<br>
<br>
I don't think it really needs a new bug report. To debug and fix the
main issue, simply roll-back (temporarily) yesterday's fix to the
processing of the \periph element. Then using my provided minimal
test file or something similar, get the program to terminate
properly with a suitable error message. Then redo the \periph fix
and hopefully any other USFM processing shortcomings will also
benefit from a more helpful output. (I can probably try to do this
myself on the weekend sometime if it's not fixed by then, but I
think your Python skills are way ahead of mine.)<br>
<br>
Meanwhile "ctrl+C" or "ps xa | grep usfm2osis" and "halt" are my
friends, unfortunately.<br>
<br>
Thanks,<br>
Robert.<br>
<br>
<br>
<div class="moz-cite-prefix">On 22/05/13 23:05, Chris Little wrote:<br>
</div>
<blockquote cite="mid:519CA688.7020208@crosswire.org" type="cite">On
5/22/2013 3:26 AM, Robert Hunt wrote:
<br>
<blockquote type="cite">Yes, it seems that Chris did indeed fix
the script so that my supplied
<br>
minimal test case no longer causes the program to require a
manual halt.
<br>
:-)
<br>
<br>
Unfortunately though, processing of that particular USFM field
wasn't my
<br>
main issue. The main issue seems to be that the program does not
fail
<br>
gracefully if a processing fault is hit in the USFM to OSIS
conversion.
<br>
</blockquote>
<br>
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.
<br>
<br>
<blockquote type="cite">So I still have to manually halt the
script to try to track down the
<br>
next USFM processing error. (I suspect the main problem that I'm
<br>
concerned about is in the multiprocessing aspect of the script.)
<br>
</blockquote>
<br>
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.<br>
</blockquote>
</body>
</html>