Notes |
|
(0024157)
|
Brad King
|
2010-12-15 11:02
|
|
There are 2 forms of Test.xml from CTest: uncompressed and compressed.
(1) The uncompressed format shows the test output in human-readable form and always contains valid UTF-8 encoded XML since this commit:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e4beefeb [^]
which was merged for CMake 2.8.1 (back in CVS-hosted days so it is a different commit) here:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dc1d2189#patch249 [^]
Invalid encoding in test output is replaced with some human-readable placeholders that describe the error. This transformation is necessary to submit valid Test.xml files with bad test output while keeping the files human-readable (e.g. not base64 encoded).
(2) The compressed format is not human readable anyway so we just use base64 encoding to generate valid Test.xml files regardless of test output. When CDash receives such files and decompresses the output it is then responsible for handling what it gets.
This is a CDash issue, not a CTest issue. CDash needs to check the validity of the UTF-8 encoding in the test output after uncompressing it and store only valid UTF-8 encoded data in its database. |
|
|
(0024177)
|
David Cole
|
2010-12-15 12:29
|
|
|
|
(0024391)
|
Zach Mullen
|
2011-01-04 10:53
|
|
Going to fix this in CDash trunk. |
|
|
(0024392)
|
Zach Mullen
|
2011-01-04 11:03
|
|
What behavior would be preferable for handling non printed characters: replace them with a placeholder like a question mark, or just remove them altogether? |
|
|
(0024394)
|
David Cole
|
2011-01-04 11:15
(edited on: 2011-01-04 11:16) |
|
Replace them with an escaped/encoded representation such that a human reader can tell what the original character was...
As in "%20" == a space character in a URL, or "&# 32;" in escaped HTML-ese, something along these lines would be the way to print a non-printing character in test output shown in a CDash web page.
See, for example, the set of HTML 4 Special Characters listed here:
http://tntluoma.com/sidebars/codes/ [^]
I don't think it matters exactly how we represent these as long as we make it "human interpretable" if not necessarily easily readable. If you can find a pattern like this on other web sites that you like, mimic it.
|
|
|
(0024395)
|
Zach Mullen
|
2011-01-04 11:43
|
|
Sounds good. Any preference between these two styles:
&0x1b;
vs.
&27;
? |
|
|
(0024396)
|
Zach Mullen
|
2011-01-04 11:56
|
|
In version 1.9 @ revision 2832 |
|