<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. ;)&nbsp; 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>