[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [OSSTEST PATCH v13 19/24] TestSupport: Implement target_subunit_cmd a subunit stream parser into substeps
Anthony PERARD writes ("Re: [OSSTEST PATCH v13 19/24] TestSupport: Implement target_subunit_cmd a subunit stream parser into substeps"): > I think I start by looking at what kind of characters could be part of > type and sub-type, and just start writing a more complicated regex. > > So is the following would be enough for you? > m{^Content-Type: [^/ ]+/[^/ ]+(?:;.+)?$} Why do you need to check the at all ? I think, according to the spec, that the only thing which can occur here is "Content-Type: something" or "]". What would be wrong with m{^content-type:}i ? > > > + # Read chunks of a part > > > + while (<$stdout>) { > > > + if (/^([0-9A-F]+)\r$/i) { > > > + my $chunk_size = hex($1); > > > > What makes you think the digits are in hex ? > > I tried with [0-9] (because DIGITS), but that was not enought. Then I've > check the subunit implementation, there are using "%X" which is hex. Wow. Can you put a comment next to this please ? Something like # The chunk size is in hex, even though this does not seem to be # documented in the subunit specification. perhaps. > > Since you have to go to the effort of separating out all of this > > stuff, it might be worth printing these multipart objects with one > > object per logfile. Although I won't insist on that because I suspect > > that multipart results are rare. > > There are usually 3 part per tests, with those names: > pythonlogging:'' > stdout > stderr > And sometime, there is also one name 'traceback'. > I think stdout and stderr are usually empty. > > I think having one file per part will make it more complicated to > read logs of a failed test. OK, leave it as-is then. (Also, "pythonlogging:''" ?!) > > I guess the error recovery is to continue until you see "]" > > and hope. Fair enough. > > That one of the reason for the subunit-v2, with a binary protocol, > better recovery. I don't think that's a good reason. But this ranting is quite off-topic now :-). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |