bin/convwatch.py: graphical layout regression test re-incarnated

[Michael Stahl]

On 11/03/12 16:50, Thorsten Behrens wrote:
> Michael Stahl wrote:
>> like several previous incarnations of the same idea, it bootstraps
>> an office, loads all documents in a directory and prints them to
>> files.
>>
> Hehe, you rock - just, FWIW, there's this in the old build repo:
> 
>  http://cgit.freedesktop.org/libreoffice/build/tree/bin/oodocdiff.sh?h=libreoffice-3-4
> 
> (seems it wasn't moved over to solenv/bin),
> 
> which relies on the rather new-fangled batch-conversion /
> batch-printing options of the office binary:
> 
>  --print-to-file [-printer-name printer_name] [--outdir output_dir] files
>       Batch print files to file.
>       If --outdir is not specified then current working dir is used as output_dir.
>       Eg. --print-to-file *.doc
>           --print-to-file --printer-name nasty_lowres_printer --outdir /home/user *.doc

oh, those are so new-fangled i never heard of them :)

>> it is based on a handful of general purpose classes to setup connections
>> to an soffice process in a robust way that could be useful for writing
>> UNO API tests in Python.
>>
> Which is lovely - just, for the sake of orthogonality, we (back in
> the day) opted to only test document printing, and not the (somewhat
> flaky) remote UNO on top. ;)

for me it turned out that the problems of remote UNO are completely
dwarfed by the un-reliability of our awful office code; e.g. i did not
succeed once in printing ~120 specific ODT documents with a single
soffice process in some hours of trying, always crashing with a
different non-reproducible stack, and thus added a connection mechanism
that starts a new soffice process for every document (plus retries),
which worked much better.  working with an un-reliable soffice is a
requirement for this kind of tool, because you may want to compare
against older OOo versions which are, if anything, even worse.

(of course this is also a really simple use case of remote UNO, it only
calls load, print, close in a loop so the usual race conditions don't
have that much opportunity to manifest)

oh, and after loading 1000 documents (it doesn't seem to crash as often
if you don't print) soffice.bin has >1G of resident memory, though i
don't remember if it went away after terminating the remote process, so
maybe that is actually caused by the remoting, but i'd guess it's not.