Always capture stack traces when running pub tests.

Always capture stack traces when running pub tests.

Now that stack_trace lazily parses stacks, this should be fast enough to be
usable.

R=rnystrom@google.com

Committed: https://code.google.com/p/dart/source/detail?r=22217

[nweiz, 2013-04-30 22:04:30]

Empirical tests indicate that this doesn't appreciably slow down the pub tests.

[nweiz, 2013-04-30 22:07:18]

On 2013/04/30 22:04:30, nweiz wrote:
> Empirical tests indicate that this doesn't appreciably slow down the pub
tests.

Actually, on further testing it seems to slow down the full pub test suite by
about 35%. I'll see if I can get that down.

[Bob Nystrom, 2013-04-30 22:18:17]

LGTM.

[nweiz, 2013-04-30 22:22:22]

On 2013/04/30 22:18:17, Bob Nystrom wrote:
> LGTM.

I've added a patch set that make scheduled_test be lazy about converting stack
traces to strings. It should bring performance to about the same level as it was
before. PTAL.

[Bob Nystrom, 2013-04-30 23:05:35]

https://codereview.chromium.org/14706002/diff/5001/pkg/scheduled_test/lib/src...
File pkg/scheduled_test/lib/src/schedule.dart (right):

https://codereview.chromium.org/14706002/diff/5001/pkg/scheduled_test/lib/src...
pkg/scheduled_test/lib/src/schedule.dart:516: if (captureStackTraces) {
If capturing stack traces is fast enough now, how about removing this flag
entirely?

https://codereview.chromium.org/14706002/diff/5001/pkg/scheduled_test/lib/src...
pkg/scheduled_test/lib/src/schedule.dart:613: typedef String
_DescriptionThunk();
Oh Dart and your awful function type syntax. You could just stick:

typedef T Fn<T>();

Somewhere in utils and be done with it. :)

https://codereview.chromium.org/14706002/diff/5001/pkg/scheduled_test/lib/src...
pkg/scheduled_test/lib/src/schedule.dart:616: class PendingCallback {
The fact that it's for an out-of-band callback isn't really relevant to the
class itself, is it? How about "Description" and then in the body document that
the class exists to lazily calculate the description for perf and stack trace
reasons?

[nweiz, 2013-04-30 23:13:14]

https://codereview.chromium.org/14706002/diff/5001/pkg/scheduled_test/lib/src...
File pkg/scheduled_test/lib/src/schedule.dart (right):

https://codereview.chromium.org/14706002/diff/5001/pkg/scheduled_test/lib/src...
pkg/scheduled_test/lib/src/schedule.dart:516: if (captureStackTraces) {
On 2013/04/30 23:05:36, Bob Nystrom wrote:
> If capturing stack traces is fast enough now, how about removing this flag
> entirely?

Done.

https://codereview.chromium.org/14706002/diff/5001/pkg/scheduled_test/lib/src...
pkg/scheduled_test/lib/src/schedule.dart:613: typedef String
_DescriptionThunk();
On 2013/04/30 23:05:36, Bob Nystrom wrote:
> Oh Dart and your awful function type syntax. You could just stick:
> 
> typedef T Fn<T>();
> 
> Somewhere in utils and be done with it. :)

Currently we're using this once each in several different packages, so that
wouldn't save us anything.

https://codereview.chromium.org/14706002/diff/5001/pkg/scheduled_test/lib/src...
pkg/scheduled_test/lib/src/schedule.dart:616: class PendingCallback {
On 2013/04/30 23:05:36, Bob Nystrom wrote:
> The fact that it's for an out-of-band callback isn't really relevant to the
> class itself, is it? How about "Description" and then in the body document
that
> the class exists to lazily calculate the description for perf and stack trace
> reasons?

I'm more interested in being able to add more pending-callback-related
information here than I am in using it in other places that would require a lazy
description.

[Bob Nystrom, 2013-05-01 00:02:25]

LGTM.

https://codereview.chromium.org/14706002/diff/5001/pkg/scheduled_test/lib/src...
File pkg/scheduled_test/lib/src/schedule.dart (right):

https://codereview.chromium.org/14706002/diff/5001/pkg/scheduled_test/lib/src...
pkg/scheduled_test/lib/src/schedule.dart:616: class PendingCallback {
On 2013/04/30 23:13:14, nweiz wrote:
> On 2013/04/30 23:05:36, Bob Nystrom wrote:
> > The fact that it's for an out-of-band callback isn't really relevant to the
> > class itself, is it? How about "Description" and then in the body document
> that
> > the class exists to lazily calculate the description for perf and stack
trace
> > reasons?
> 
> I'm more interested in being able to add more pending-callback-related
> information here than I am in using it in other places that would require a
lazy
> description.

In that case, keep the name of this type, but update the doc comments above to
remove "The descriptions of".

[nweiz, 2013-05-01 00:33:44]

https://codereview.chromium.org/14706002/diff/5001/pkg/scheduled_test/lib/src...
File pkg/scheduled_test/lib/src/schedule.dart (right):

https://codereview.chromium.org/14706002/diff/5001/pkg/scheduled_test/lib/src...
pkg/scheduled_test/lib/src/schedule.dart:616: class PendingCallback {
On 2013/05/01 00:02:25, Bob Nystrom wrote:
> On 2013/04/30 23:13:14, nweiz wrote:
> > On 2013/04/30 23:05:36, Bob Nystrom wrote:
> > > The fact that it's for an out-of-band callback isn't really relevant to
the
> > > class itself, is it? How about "Description" and then in the body document
> > that
> > > the class exists to lazily calculate the description for perf and stack
> trace
> > > reasons?
> > 
> > I'm more interested in being able to add more pending-callback-related
> > information here than I am in using it in other places that would require a
> lazy
> > description.
> 
> In that case, keep the name of this type, but update the doc comments above to
> remove "The descriptions of".

That's specifically referring to the string, not the [PendingCallback] object.

[nweiz, 2013-05-01 00:34:15]

Committed patchset #3 manually as r22217 (presubmit successful).