On Sun, Oct 24, 2010 at 11:58 AM, Jonathan Lange <email address hidden> wrote:
>>> Thus, the net effect of two consecutive time events is to set the time
>>> for all future events to whatever value was provided with the second
>>> time event. The first is ignored.
Yes, but we're altering the stream and stripping other things. While
its ignored we could use to use it.
>>
>> If you were computing "how long did success: X" take, wouldn't you
>> subtract C from B?
>>
>
> Why would I compute how long "success: X" took? If I wanted to know
> the amount of time between the test X starting and it completing, I'd
> calculate B - A.
Yes.
> Also, and perhaps I'm being too pedantic here, but unless the subunit
> protocol is being used in a non-standard way, time C does not mean
> "when success: X finished", it means "when the first event after
> success: X happened".
Thats right, it means 'first event after success: X', which for
figuring out stuff in slow test runners may (or may not) be
interesting.
On Sun, Oct 24, 2010 at 11:58 AM, Jonathan Lange <email address hidden> wrote:
>>> Thus, the net effect of two consecutive time events is to set the time
>>> for all future events to whatever value was provided with the second
>>> time event. The first is ignored.
Yes, but we're altering the stream and stripping other things. While
its ignored we could use to use it.
>>
>> If you were computing "how long did success: X" take, wouldn't you
>> subtract C from B?
>>
>
> Why would I compute how long "success: X" took? If I wanted to know
> the amount of time between the test X starting and it completing, I'd
> calculate B - A.
Yes.
> Also, and perhaps I'm being too pedantic here, but unless the subunit
> protocol is being used in a non-standard way, time C does not mean
> "when success: X finished", it means "when the first event after
> success: X happened".
Thats right, it means 'first event after success: X', which for
figuring out stuff in slow test runners may (or may not) be
interesting.
-Rob