On Wed, 8 Feb 2012, Markus Mohrhard wrote:
2012/2/8 Caolán McNamara <caol...@redhat.com>:
On Tue, 2012-02-07 at 22:05 +0100, Markus Mohrhard wrote:
But keep in mind that this is nothing that will be fast. I needed
around one week to check a bit more than 4000 files
My times are dramatically faster than this for .doc files in writer at
least. I can load 4000 .doc files *under valgrind* overnight in about 10
hours. So apparently mileage varies quite a bit depending on hardware
and file format and debugging level.
That only works if you have no crashs or looping documents. Especially
looping is a big problem in calc.
Then if we want to be fast using a debug/dbgutil build is the wrong
way but then we loose the advantages of gcc's safe iterators.
So I think 4000 known good documents can be easily tested in one day
or even faster with a "decent" machine but taking 4000 random
documents from bugzilla needs some manual interaction and therefore
will need more time.
As mentionend in the last mail, I think we could speed that up by
copying the test code and the makefile several times and run the test
in parallel. That way we could use more cores and would be more
reliable against crashs. ( we should of course not commit this stuff
then)
I would investigate in what cloudooo is doing, they already monitor the
process and detect a runaway/memory-leaked process, or intervene when a
conversion is spending more time than we would expect.
If we simply implement his logic in a small python tool and make it work
on a directory of documents, we could run this command every night using
the latest snapshot and record/log any debug output (in parallel if need
be).
And if we use the same (growing) set of documents we also test for
regressions by having a directory of files that never failed, and a
directory with files that have failed, and have the tool move the files
around.
And in the same time the robustness of the UNO python bindings is tests
;-)
PS I would add cloudooo logic to unoconv, but I prefer to keep workarounds
out of unoconv, as I prefer such errors to be reported rather than hide
them from users.
--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, i...@dagit.net, http://dagit.net/
[Any errors in spelling, tact or fact are transmission errors]
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
