Stitching is now done automatically in a sub process by the
server. This is much cleaner - and all we need to do is poll for
file updates.
I've also styled the log display slightly better.
I'm now running stitching in subprocesses during the scan.
This seems to be working well - I'm using multiple CPU
cores and getting images out. However, the only way to
avoid circular dependencies was to combine the Things.
I'm still getting not-infrequent memory allocation errors from the camera, which may or may not be related.
To save some CPU cycles, we will return immediately if the
images don't look newer than the stitch. NB this does mean
that the stitched image will be repeatedly transferred, as its
URL will change each time it's re-requested.
Alternatively, we could fail with an error, which may be more efficient, at the expense of being uglier.
checkExistingTasks was looking up the task's `self` link by
checking for `rel=self`, which failed. I have corrected this
to `rel="self"` - `self` would have evaluated to `undefined`.
The log viewer was scrolling to the bottom when new logs
appeared, but not when the status updated. This meant that the status update may have been invisible. I now scroll
when the status changes too, which should fix the problem.
NB there's a confusing feature, where stage.move will
fail after the task has been cancelled, because it is cancellable.
For now, we can work around it by passing `block_cancellation` but
this may want to be solved more generally in LabThings
I've tidied up the UI a bit here:
* The modal box stays open and must be explicitly closed.
Pretty much everywhere we want to use this, it would be nice
to see the final confirmation it's worked - so I have removed
the line that closes it after the task completes.
* The progress bar no longer animates after the task has
finished (logic previously didn't consider that state as the
bar wasn't visible except while it was running).
* A helpful message is printed when the task completes or is
cancelled.
Python stack traces use spaces and carets to "underline" the
code causing the problem. I've now matched and processed
these lines to add <u> tags.
This necessitated escaping messages and displaying raw HTML
which is now done by `escapeText`.
I fixed a logic error related to the reversing of the list, and
now display multi-line log messages as a single summary line with a "more info" link to expand them.
Expanded log messages show without text wrap - this makes
Python exception traces easier to read.
For extra points, we could even do something cunning, like
process the ^^^ markers into <u>
