Merge NumericValue into Histogram

Merge NumericValue into Histogram.

Pour one out for Value, y'all.
The Value system was a really neat architecture. It made good sense.
But when the TBM2 rubber hit the road, it turned out that the only Value
subclass that was needed was NumericValue.
And in order for merging NumericValues to be predictable, they need to specify
reasonable ranges, and, well, be Histograms.
The TBM2 UIs should handle the scalar statistics.
If all metrics always produce NumericValues that contain Histograms, it's just
more ergonomic if those are the same object.
This aligns with UMA histograms, which have names and bin configurations and
descriptions.

I considered splitting Histogram into a base/ Histogram without name and
diagnostics, and a MetricHistogram with them, but the only non-metric client of
Histogram (multi_sample_sub_view) needs diagnostics (though not name).
So let's keep a monolithic Histogram for now. We can split it if and when a
fault-line emerges in the use-cases. This means that tracing/ui will depend on
value/ (when lpy lands it), but that's already been the case since ScalarNumeric
was moved to value/.

This will invalidate existing results2.html again.

A follow-up patch will move ScalarNumeric to base/ with the Unit system, and
delete NumericBase.
Another follow-up will rename ValueSet, value-set-table, sourceValues, etc.

BUG=catapult:#2685

Committed: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+/4d79e0661cd7df860765247ca5250f8dcb19735c

[benjhayden, 2016-09-14 17:41:01]

Patchset #1 (id:1) has been deleted

[benjhayden, 2016-09-14 17:41:06]

Patchset #1 (id:20001) has been deleted

[benjhayden, 2016-09-14 17:57:03]

Description was changed from

==========
Merge NumericValue into Histogram.

This will invalidate existing results2.html again.

BUG=catapult:#2685
==========

to

==========
Merge NumericValue into Histogram.

Pour one out for Value, y'all.
The Value system was a really neat architecture. It made good sense.
But when the TBM2 rubber hit the road, it turned out that the only Value
subclass that was needed was NumericValue.
Also, the system really needs metrics to specify reasonable ranges for their
computed values so that merging them is predictable.
So metrics should always use Histograms, and let the TBM2 UIs deal with the
Scalars.
If all metrics always produce NumericValues that contain Histograms, it's just
more
ergonomic if those are the same object.

I considered splitting Histogram into a base/ Histogram without name and
diagnostics,
and a MetricHistogram with them, but the only non-metric client of Histogram
(multi_sample_sub_view) needs diagnostics (though not name).
So let's keep a monolithic Histogram for now. We can split it if and when a
fault-line emerges in the use-cases.

This will invalidate existing results2.html again.

A follow-up patch will move ScalarNumeric to base/ with the Unit system.

BUG=catapult:#2685
==========

[benjhayden, 2016-09-14 18:05:17]

Description was changed from

==========
Merge NumericValue into Histogram.

Pour one out for Value, y'all.
The Value system was a really neat architecture. It made good sense.
But when the TBM2 rubber hit the road, it turned out that the only Value
subclass that was needed was NumericValue.
Also, the system really needs metrics to specify reasonable ranges for their
computed values so that merging them is predictable.
So metrics should always use Histograms, and let the TBM2 UIs deal with the
Scalars.
If all metrics always produce NumericValues that contain Histograms, it's just
more
ergonomic if those are the same object.

I considered splitting Histogram into a base/ Histogram without name and
diagnostics,
and a MetricHistogram with them, but the only non-metric client of Histogram
(multi_sample_sub_view) needs diagnostics (though not name).
So let's keep a monolithic Histogram for now. We can split it if and when a
fault-line emerges in the use-cases.

This will invalidate existing results2.html again.

A follow-up patch will move ScalarNumeric to base/ with the Unit system.

BUG=catapult:#2685
==========

to

==========
Merge NumericValue into Histogram.

Pour one out for Value, y'all.
The Value system was a really neat architecture. It made good sense.
But when the TBM2 rubber hit the road, it turned out that the only Value
subclass that was needed was NumericValue.
In order for merging NumericValues to be predictable, they need to specify
reasonable ranges, and, well, be Histograms.
The TBM2 UIs should handle the scalar statistics.
If all metrics always produce NumericValues that contain Histograms, it's just
more ergonomic if those are the same object.

I considered splitting Histogram into a base/ Histogram without name and
diagnostics, and a MetricHistogram with them, but the only non-metric client of
Histogram (multi_sample_sub_view) needs diagnostics (though not name).
So let's keep a monolithic Histogram for now. We can split it if and when a
fault-line emerges in the use-cases.

This will invalidate existing results2.html again.

A follow-up patch will move ScalarNumeric to base/ with the Unit system.

BUG=catapult:#2685
==========

[benjhayden, 2016-09-14 18:06:48]

Description was changed from

==========
Merge NumericValue into Histogram.

Pour one out for Value, y'all.
The Value system was a really neat architecture. It made good sense.
But when the TBM2 rubber hit the road, it turned out that the only Value
subclass that was needed was NumericValue.
In order for merging NumericValues to be predictable, they need to specify
reasonable ranges, and, well, be Histograms.
The TBM2 UIs should handle the scalar statistics.
If all metrics always produce NumericValues that contain Histograms, it's just
more ergonomic if those are the same object.

I considered splitting Histogram into a base/ Histogram without name and
diagnostics, and a MetricHistogram with them, but the only non-metric client of
Histogram (multi_sample_sub_view) needs diagnostics (though not name).
So let's keep a monolithic Histogram for now. We can split it if and when a
fault-line emerges in the use-cases.

This will invalidate existing results2.html again.

A follow-up patch will move ScalarNumeric to base/ with the Unit system.

BUG=catapult:#2685
==========

to

==========
Merge NumericValue into Histogram.

Pour one out for Value, y'all.
The Value system was a really neat architecture. It made good sense.
But when the TBM2 rubber hit the road, it turned out that the only Value
subclass that was needed was NumericValue.
In order for merging NumericValues to be predictable, they need to specify
reasonable ranges, and, well, be Histograms.
The TBM2 UIs should handle the scalar statistics.
If all metrics always produce NumericValues that contain Histograms, it's just
more ergonomic if those are the same object.
This aligns with UMA histograms, which have names and bin configurations and
descriptions.

I considered splitting Histogram into a base/ Histogram without name and
diagnostics, and a MetricHistogram with them, but the only non-metric client of
Histogram (multi_sample_sub_view) needs diagnostics (though not name).
So let's keep a monolithic Histogram for now. We can split it if and when a
fault-line emerges in the use-cases.

This will invalidate existing results2.html again.

A follow-up patch will move ScalarNumeric to base/ with the Unit system.

BUG=catapult:#2685
==========

[benjhayden, 2016-09-14 18:09:26]

Description was changed from

==========
Merge NumericValue into Histogram.

Pour one out for Value, y'all.
The Value system was a really neat architecture. It made good sense.
But when the TBM2 rubber hit the road, it turned out that the only Value
subclass that was needed was NumericValue.
In order for merging NumericValues to be predictable, they need to specify
reasonable ranges, and, well, be Histograms.
The TBM2 UIs should handle the scalar statistics.
If all metrics always produce NumericValues that contain Histograms, it's just
more ergonomic if those are the same object.
This aligns with UMA histograms, which have names and bin configurations and
descriptions.

I considered splitting Histogram into a base/ Histogram without name and
diagnostics, and a MetricHistogram with them, but the only non-metric client of
Histogram (multi_sample_sub_view) needs diagnostics (though not name).
So let's keep a monolithic Histogram for now. We can split it if and when a
fault-line emerges in the use-cases.

This will invalidate existing results2.html again.

A follow-up patch will move ScalarNumeric to base/ with the Unit system.

BUG=catapult:#2685
==========

to

==========
Merge NumericValue into Histogram.

Pour one out for Value, y'all.
The Value system was a really neat architecture. It made good sense.
But when the TBM2 rubber hit the road, it turned out that the only Value
subclass that was needed was NumericValue.
In order for merging NumericValues to be predictable, they need to specify
reasonable ranges, and, well, be Histograms.
The TBM2 UIs should handle the scalar statistics.
If all metrics always produce NumericValues that contain Histograms, it's just
more ergonomic if those are the same object.
This aligns with UMA histograms, which have names and bin configurations and
descriptions.

I considered splitting Histogram into a base/ Histogram without name and
diagnostics, and a MetricHistogram with them, but the only non-metric client of
Histogram (multi_sample_sub_view) needs diagnostics (though not name).
So let's keep a monolithic Histogram for now. We can split it if and when a
fault-line emerges in the use-cases.

This will invalidate existing results2.html again.

A follow-up patch will move ScalarNumeric to base/ with the Unit system, and
delete NumericBase.

BUG=catapult:#2685
==========

[benjhayden, 2016-09-14 18:12:54]

Patchset #1 (id:40001) has been deleted

[benjhayden, 2016-09-14 18:13:04]

benjhayden@chromium.org changed reviewers:
+ eakuefner@chromium.org

[benjhayden, 2016-09-14 18:13:05]

:-)

[benjhayden, 2016-09-14 18:14:39]

Description was changed from

==========
Merge NumericValue into Histogram.

Pour one out for Value, y'all.
The Value system was a really neat architecture. It made good sense.
But when the TBM2 rubber hit the road, it turned out that the only Value
subclass that was needed was NumericValue.
In order for merging NumericValues to be predictable, they need to specify
reasonable ranges, and, well, be Histograms.
The TBM2 UIs should handle the scalar statistics.
If all metrics always produce NumericValues that contain Histograms, it's just
more ergonomic if those are the same object.
This aligns with UMA histograms, which have names and bin configurations and
descriptions.

I considered splitting Histogram into a base/ Histogram without name and
diagnostics, and a MetricHistogram with them, but the only non-metric client of
Histogram (multi_sample_sub_view) needs diagnostics (though not name).
So let's keep a monolithic Histogram for now. We can split it if and when a
fault-line emerges in the use-cases.

This will invalidate existing results2.html again.

A follow-up patch will move ScalarNumeric to base/ with the Unit system, and
delete NumericBase.

BUG=catapult:#2685
==========

to

==========
Merge NumericValue into Histogram.

Pour one out for Value, y'all.
The Value system was a really neat architecture. It made good sense.
But when the TBM2 rubber hit the road, it turned out that the only Value
subclass that was needed was NumericValue.
In order for merging NumericValues to be predictable, they need to specify
reasonable ranges, and, well, be Histograms.
The TBM2 UIs should handle the scalar statistics.
If all metrics always produce NumericValues that contain Histograms, it's just
more ergonomic if those are the same object.
This aligns with UMA histograms, which have names and bin configurations and
descriptions.

I considered splitting Histogram into a base/ Histogram without name and
diagnostics, and a MetricHistogram with them, but the only non-metric client of
Histogram (multi_sample_sub_view) needs diagnostics (though not name).
So let's keep a monolithic Histogram for now. We can split it if and when a
fault-line emerges in the use-cases. This means that tracing/ui will depend on
value/ (when lpy lands it), but that's already been the case since ScalarNumeric
was moved to value/.

This will invalidate existing results2.html again.

A follow-up patch will move ScalarNumeric to base/ with the Unit system, and
delete NumericBase.

BUG=catapult:#2685
==========

[eakuefner, 2016-09-14 18:16:43]

eakuefner@chromium.org changed reviewers:
+ oysteine@chromium.org

[eakuefner, 2016-09-14 18:16:45]

+oysteine for TP OWNERS

lgtm % potential followup to rename more refs to Value

https://codereview.chromium.org/2334233003/diff/60001/tracing/tracing/value/h...
File tracing/tracing/value/histogram.html (right):

https://codereview.chromium.org/2334233003/diff/60001/tracing/tracing/value/h...
tracing/tracing/value/histogram.html:106: // If this Value is being
deserialized, then its guid will be set by
s/Value/Histogram/

https://codereview.chromium.org/2334233003/diff/60001/tracing/tracing/value/h...
tracing/tracing/value/histogram.html:108: // If this Value is being computed by
a metric, then its guid will be
and here

https://codereview.chromium.org/2334233003/diff/60001/tracing/tracing/value/v...
File tracing/tracing/value/value_set.html (right):

https://codereview.chromium.org/2334233003/diff/60001/tracing/tracing/value/v...
tracing/tracing/value/value_set.html:127: return this.toArray().filter(h =>
h.name == name);
===

[benjhayden, 2016-09-14 18:21:21]

Description was changed from

==========
Merge NumericValue into Histogram.

Pour one out for Value, y'all.
The Value system was a really neat architecture. It made good sense.
But when the TBM2 rubber hit the road, it turned out that the only Value
subclass that was needed was NumericValue.
In order for merging NumericValues to be predictable, they need to specify
reasonable ranges, and, well, be Histograms.
The TBM2 UIs should handle the scalar statistics.
If all metrics always produce NumericValues that contain Histograms, it's just
more ergonomic if those are the same object.
This aligns with UMA histograms, which have names and bin configurations and
descriptions.

I considered splitting Histogram into a base/ Histogram without name and
diagnostics, and a MetricHistogram with them, but the only non-metric client of
Histogram (multi_sample_sub_view) needs diagnostics (though not name).
So let's keep a monolithic Histogram for now. We can split it if and when a
fault-line emerges in the use-cases. This means that tracing/ui will depend on
value/ (when lpy lands it), but that's already been the case since ScalarNumeric
was moved to value/.

This will invalidate existing results2.html again.

A follow-up patch will move ScalarNumeric to base/ with the Unit system, and
delete NumericBase.

BUG=catapult:#2685
==========

to

==========
Merge NumericValue into Histogram.

Pour one out for Value, y'all.
The Value system was a really neat architecture. It made good sense.
But when the TBM2 rubber hit the road, it turned out that the only Value
subclass that was needed was NumericValue.
And in order for merging NumericValues to be predictable, they need to specify
reasonable ranges, and, well, be Histograms.
The TBM2 UIs should handle the scalar statistics.
If all metrics always produce NumericValues that contain Histograms, it's just
more ergonomic if those are the same object.
This aligns with UMA histograms, which have names and bin configurations and
descriptions.

I considered splitting Histogram into a base/ Histogram without name and
diagnostics, and a MetricHistogram with them, but the only non-metric client of
Histogram (multi_sample_sub_view) needs diagnostics (though not name).
So let's keep a monolithic Histogram for now. We can split it if and when a
fault-line emerges in the use-cases. This means that tracing/ui will depend on
value/ (when lpy lands it), but that's already been the case since ScalarNumeric
was moved to value/.

This will invalidate existing results2.html again.

A follow-up patch will move ScalarNumeric to base/ with the Unit system, and
delete NumericBase.

BUG=catapult:#2685
==========

[benjhayden, 2016-09-14 18:22:24]

Description was changed from

==========
Merge NumericValue into Histogram.

Pour one out for Value, y'all.
The Value system was a really neat architecture. It made good sense.
But when the TBM2 rubber hit the road, it turned out that the only Value
subclass that was needed was NumericValue.
And in order for merging NumericValues to be predictable, they need to specify
reasonable ranges, and, well, be Histograms.
The TBM2 UIs should handle the scalar statistics.
If all metrics always produce NumericValues that contain Histograms, it's just
more ergonomic if those are the same object.
This aligns with UMA histograms, which have names and bin configurations and
descriptions.

I considered splitting Histogram into a base/ Histogram without name and
diagnostics, and a MetricHistogram with them, but the only non-metric client of
Histogram (multi_sample_sub_view) needs diagnostics (though not name).
So let's keep a monolithic Histogram for now. We can split it if and when a
fault-line emerges in the use-cases. This means that tracing/ui will depend on
value/ (when lpy lands it), but that's already been the case since ScalarNumeric
was moved to value/.

This will invalidate existing results2.html again.

A follow-up patch will move ScalarNumeric to base/ with the Unit system, and
delete NumericBase.

BUG=catapult:#2685
==========

to

==========
Merge NumericValue into Histogram.

Pour one out for Value, y'all.
The Value system was a really neat architecture. It made good sense.
But when the TBM2 rubber hit the road, it turned out that the only Value
subclass that was needed was NumericValue.
And in order for merging NumericValues to be predictable, they need to specify
reasonable ranges, and, well, be Histograms.
The TBM2 UIs should handle the scalar statistics.
If all metrics always produce NumericValues that contain Histograms, it's just
more ergonomic if those are the same object.
This aligns with UMA histograms, which have names and bin configurations and
descriptions.

I considered splitting Histogram into a base/ Histogram without name and
diagnostics, and a MetricHistogram with them, but the only non-metric client of
Histogram (multi_sample_sub_view) needs diagnostics (though not name).
So let's keep a monolithic Histogram for now. We can split it if and when a
fault-line emerges in the use-cases. This means that tracing/ui will depend on
value/ (when lpy lands it), but that's already been the case since ScalarNumeric
was moved to value/.

This will invalidate existing results2.html again.

A follow-up patch will move ScalarNumeric to base/ with the Unit system, and
delete NumericBase.
Another follow-up will rename ValueSet, value-set-table, sourceValues, etc.

BUG=catapult:#2685
==========

[oystein (OOO til 10th of July), 2016-09-15 20:48:47]

lgtm

[benjhayden, 2016-09-15 20:55:53]

The CQ bit was checked by benjhayden@chromium.org

[benjhayden, 2016-09-15 20:55:54]

The patchset sent to the CQ was uploaded after l-g-t-m from
eakuefner@chromium.org
Link to the patchset: https://codereview.chromium.org/2334233003/#ps100001
(title: "rebase")

[commit-bot: I haz the power, 2016-09-15 20:55:58]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-15 21:19:00]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-15 21:19:02]

Try jobs failed on following builders:
  Catapult Windows Tryserver on master.tryserver.client.catapult (JOB_FAILED,
https://build.chromium.org/p/tryserver.client.catapult/builders/Catapult%20Wi...)

[benjhayden, 2016-09-15 21:29:41]

The CQ bit was checked by benjhayden@chromium.org

[commit-bot: I haz the power, 2016-09-15 21:29:52]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-15 21:52:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-15 21:52:02]

Try jobs failed on following builders:
  Catapult Mac Tryserver on master.tryserver.client.catapult (JOB_FAILED,
https://build.chromium.org/p/tryserver.client.catapult/builders/Catapult%20Ma...)

[benjhayden, 2016-09-15 23:08:00]

The CQ bit was checked by benjhayden@chromium.org

[benjhayden, 2016-09-15 23:08:01]

The patchset sent to the CQ was uploaded after l-g-t-m from
eakuefner@chromium.org, oysteine@chromium.org
Link to the patchset: https://codereview.chromium.org/2334233003/#ps120001
(title: "fix rail_power_metric")

[commit-bot: I haz the power, 2016-09-15 23:08:11]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-15 23:30:59]

Description was changed from

==========
Merge NumericValue into Histogram.

Pour one out for Value, y'all.
The Value system was a really neat architecture. It made good sense.
But when the TBM2 rubber hit the road, it turned out that the only Value
subclass that was needed was NumericValue.
And in order for merging NumericValues to be predictable, they need to specify
reasonable ranges, and, well, be Histograms.
The TBM2 UIs should handle the scalar statistics.
If all metrics always produce NumericValues that contain Histograms, it's just
more ergonomic if those are the same object.
This aligns with UMA histograms, which have names and bin configurations and
descriptions.

I considered splitting Histogram into a base/ Histogram without name and
diagnostics, and a MetricHistogram with them, but the only non-metric client of
Histogram (multi_sample_sub_view) needs diagnostics (though not name).
So let's keep a monolithic Histogram for now. We can split it if and when a
fault-line emerges in the use-cases. This means that tracing/ui will depend on
value/ (when lpy lands it), but that's already been the case since ScalarNumeric
was moved to value/.

This will invalidate existing results2.html again.

A follow-up patch will move ScalarNumeric to base/ with the Unit system, and
delete NumericBase.
Another follow-up will rename ValueSet, value-set-table, sourceValues, etc.

BUG=catapult:#2685
==========

to

==========
Merge NumericValue into Histogram.

Pour one out for Value, y'all.
The Value system was a really neat architecture. It made good sense.
But when the TBM2 rubber hit the road, it turned out that the only Value
subclass that was needed was NumericValue.
And in order for merging NumericValues to be predictable, they need to specify
reasonable ranges, and, well, be Histograms.
The TBM2 UIs should handle the scalar statistics.
If all metrics always produce NumericValues that contain Histograms, it's just
more ergonomic if those are the same object.
This aligns with UMA histograms, which have names and bin configurations and
descriptions.

I considered splitting Histogram into a base/ Histogram without name and
diagnostics, and a MetricHistogram with them, but the only non-metric client of
Histogram (multi_sample_sub_view) needs diagnostics (though not name).
So let's keep a monolithic Histogram for now. We can split it if and when a
fault-line emerges in the use-cases. This means that tracing/ui will depend on
value/ (when lpy lands it), but that's already been the case since ScalarNumeric
was moved to value/.

This will invalidate existing results2.html again.

A follow-up patch will move ScalarNumeric to base/ with the Unit system, and
delete NumericBase.
Another follow-up will rename ValueSet, value-set-table, sourceValues, etc.

BUG=catapult:#2685

Committed:
https://chromium.googlesource.com/external/github.com/catapult-project/catapu...
==========

[commit-bot: I haz the power, 2016-09-15 23:31:00]

Committed patchset #4 (id:120001) as
https://chromium.googlesource.com/external/github.com/catapult-project/catapu...