chrislit at crosswire.org
Wed May 22 21:29:49 MST 2013
On 5/22/2013 5:49 PM, Robert Hunt wrote:
> Thanks Chris. Yes, multiprocessing is great on my i7. :-)
> Actually the bug I reported
> <http://www.crosswire.org/tracker/browse/MODTOOLS-40> was "usfm2osis.py
> enters infinite loop". The bug that was fixed was something like
> "\periph USFM doesn't process properly".
Okay, I amend my comment to: I only fixed the bug that you reported,
despite the uninformative title. (It's not really an infinite loop
you're seeing anyway; it's a wait loop in the mp queue.) If you have
encountered another bug, you will need to identify it in a reproducible way.
> 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
The traceback output from the interpreter is actually super-informative
on its own. It specifies exactly where the error in the code is,
allowing it to be corrected.
If you're seeing non-termination with other USFM, then there is a
different bug elsewhere in the script. If a thread dies with an error,
like this one, then the error message points to the problem, which will
be located in a different section of the script.
If a thread really gets stuck in a loop and never throws any kind of
error, that's completely unrelated to this bug.
You don't necessarily have to isolate the issue, as long as you can
provide some USFM that causes the problem you're seeing. If you can't
share files because of rights issues, you can also use lorem.py (found
in the directory with usfm2osis.py) to replace text in USFM with lorem
ipsum text. It expects files in usfmSamples_orig and outputs them to
> Meanwhile "ctrl+C" or "ps xa | grep usfm2osis" and "halt" are my
> friends, unfortunately.
Yes, Ctrl-C is your friend. I don't see why that is the least bit onerous.
It's not as if my adding an exception handler to make the script die
more elegantly would also make it function correctly in these instances.
It would just die more elegantly.
tl;dr: If you're still experiencing incorrect behavior, you do need to
file a new bug.
More information about the sword-devel