Re: XPIDL trajectory
On 6/26/18 12:45 AM, L. David Baron wrote: What's the relative value of making something not use xpidl anymore vs. marking an xpidl interface as no longer [scriptable]? I think the main value is in not using xpidl anymore, for two reasons: 1) You can't devirtualize things while still using xpidl. Removing xpidl bits means your objects might get smaller (fewer vtable pointers), our relocatable data gets smaller (fewer vtables), and runtime likely gets faster. 2) It's hard to get sane C++ method signatures while using xpidl. You _can_ do it with [notxpcom,nostdcall] and enought native-type declaration. But it requires some hoop-jumping. And at that point what's the benefit of using xpidl for it? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XPIDL trajectory
On Mon, Jun 25, 2018 at 09:45:22PM -0700, L. David Baron wrote: On Tuesday 2018-06-26 14:29 +1000, Nicholas Nethercote wrote: The trend is clearly down, except for the large increase in .xpt size for the most recent measurement -- note the extra digit! It appears that .xpt files used to be binary, and now they are JSON. This might be related to mccr8's recent XPT overhaul (bug 1438688)? What's the relative value of making something not use xpidl anymore vs. marking an xpidl interface as no longer [scriptable]? (I hope that marking it not [scriptable] would mean we don't generate .xpt data for it... although I haven't checked. I *think* mccr8's XPT work means that we no longer have duplicate in-memory copies of the xpt data across processes, though, so some of this isn't as big a deal as it used to be.) For C++, it generally means fewer vtables/virtual calls (which is currently a significant win for content process memory), and generally a nicer API surface. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XPIDL trajectory
On Tuesday 2018-06-26 14:29 +1000, Nicholas Nethercote wrote: > The trend is clearly down, except for the large increase in .xpt size for > the most recent measurement -- note the extra digit! It appears that .xpt > files used to be binary, and now they are JSON. This might be related to > mccr8's recent XPT overhaul (bug 1438688)? What's the relative value of making something not use xpidl anymore vs. marking an xpidl interface as no longer [scriptable]? (I hope that marking it not [scriptable] would mean we don't generate .xpt data for it... although I haven't checked. I *think* mccr8's XPT work means that we no longer have duplicate in-memory copies of the xpt data across processes, though, so some of this isn't as big a deal as it used to be.) -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
XPIDL trajectory
Hi, After Firefox 57 removed support for legacy extensions, I decided to (roughly) track how much XPIDL code we have. Here are some measurements: Fri, Aug 4, 2017: m-i 372493:72873c109b1b .idl files: 1167 .idl lines: 110240 total .xpt bytes: 417621 total Thu, Aug 17, 2017: m-i 375206:7a794cd2aee1 .idl files: 1150 .idl lines: 108854 total .xpt bytes: 412984 total Tue, Sep 26, 2017: m-i 382849:42a6a1c9c4cf .idl files: 1122 .idl lines: 107963 total .xpt bytes: 411283 total Tue, Nov 14, 2017: m-i 391533:479f3105ad3b .idl files: 1087 .idl lines: 106809 total .xpt bytes: 409510 total Thu, Feb 01, 2018: m-i 401956:8ebdf597ade8 .idl files: 1027 .idl lines: 103800 total .xpt bytes: 398695 total Tue, Jun 26, 2018: m-i 423583:4a20ed6e2fee .idl files: 905 .idl lines: 97278 total .xpt bytes: 3717958 total The trend is clearly down, except for the large increase in .xpt size for the most recent measurement -- note the extra digit! It appears that .xpt files used to be binary, and now they are JSON. This might be related to mccr8's recent XPT overhaul (bug 1438688)? The script I use for this is below, for those who are interested. Nick #! /bin/sh # # Measures various XPIDL things in ./ and o64/. (It assumes o64/ is the # objdir.) I put the results in ~/moz/txt/xpidl.txt. if [ ! -d o64 ] ; then echo "o64/ doesn't exist" return 1 fi # Count number of .idl files, excluding ones in objdirs, testing ones, and # mortar ones. echo -n ".idl files: " find . -name '*.idl' | \ grep -v "64[a-z]*\/dist" | grep -v "testing\/" | grep -v "mortar\/" | \ wc --lines # Count number of lines in those .idl files. echo -n ".idl lines: " find . -name '*.idl' | \ grep -v "64[a-z]*\/dist" | grep -v "testing\/" | grep -v "mortar\/" | \ xargs wc --lines | tail -1 # Count number of bytes in .xpt files. cd o64 echo -n ".xpt bytes: " find . -name '*.xpt' | xargs wc --bytes | tail -1 cd .. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Coding style: Making the `e` prefix for enum variants not mandatory?
If we can't agree, it shouldn't be in the style guide.
On Mon, Jun 25, 2018 at 2:17 PM, Peter Saint-Andre wrote:
> And perhaps good reason for removing it from the style guide? ;-)
>
> On 6/25/18 3:08 PM, Emilio Cobos Álvarez wrote:
>> And Kris pointed out that we already had another huge thread on this:
>>
>>
>> https://groups.google.com/d/msg/mozilla.dev.platform/WAuySoTfq_w/-DggRotpBQAJ
>>
>>
>> Looks like there wasn't agreement on that one... But oh well, don't want
>> to repeat a lot of that discussion.
>>
>> I think the argument for consistency with the other systems language we
>> have in-tree, the fact that it's not predominant (at least for enum
>> classes) even though it is in the coding style, and that there wasn't
>> agreement in the previous thread are good reasons for not enforcing it,
>> but...
>>
>> -- Emilio
>>
>> On 6/25/18 10:41 PM, Emilio Cobos Álvarez wrote:
>>> Our coding style states that we should use an `e` prefix for enum
>>> variants, that is:
>>>
>>>enum class Foo { eBar, eBaz };
>>>
>>> We're not really consistent about it: looking at layout/, we mostly
>>> use CamelCase, though we do have some prefixed enums. Looking at other
>>> modules, enum classes almost never use it either. DOM bindings also
>>> don't use that prefix.
>>>
>>> I think that with enum classes the usefulness of the prefix is less
>>> justified. Plus removing them would allow us to match the Rust coding
>>> style as well, which is nice IMO.
>>>
>>> Would anybody object to making the prefix non-mandatory, removing that
>>> line from the coding style doc? Maybe only making it non-mandatory for
>>> enum classes?
>>>
>>> Thanks,
>>>
>>> -- Emilio
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Coding style: Making the `e` prefix for enum variants not mandatory?
And perhaps good reason for removing it from the style guide? ;-)
On 6/25/18 3:08 PM, Emilio Cobos Álvarez wrote:
> And Kris pointed out that we already had another huge thread on this:
>
>
> https://groups.google.com/d/msg/mozilla.dev.platform/WAuySoTfq_w/-DggRotpBQAJ
>
>
> Looks like there wasn't agreement on that one... But oh well, don't want
> to repeat a lot of that discussion.
>
> I think the argument for consistency with the other systems language we
> have in-tree, the fact that it's not predominant (at least for enum
> classes) even though it is in the coding style, and that there wasn't
> agreement in the previous thread are good reasons for not enforcing it,
> but...
>
> -- Emilio
>
> On 6/25/18 10:41 PM, Emilio Cobos Álvarez wrote:
>> Our coding style states that we should use an `e` prefix for enum
>> variants, that is:
>>
>> enum class Foo { eBar, eBaz };
>>
>> We're not really consistent about it: looking at layout/, we mostly
>> use CamelCase, though we do have some prefixed enums. Looking at other
>> modules, enum classes almost never use it either. DOM bindings also
>> don't use that prefix.
>>
>> I think that with enum classes the usefulness of the prefix is less
>> justified. Plus removing them would allow us to match the Rust coding
>> style as well, which is nice IMO.
>>
>> Would anybody object to making the prefix non-mandatory, removing that
>> line from the coding style doc? Maybe only making it non-mandatory for
>> enum classes?
>>
>> Thanks,
>>
>> -- Emilio
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Some of the mediaqueries-4 syntax improvements.
On 6/25/18 11:01 PM, L. David Baron wrote:
How does the particular set of features that you're planning to ship
vs. not ship align with what other browsers have shipped (or are
close shipping)?
I'm not aware of any other browser implementing or shipping any of the
changes from MQ3 to MQ4, so we'd be the first to support these.
This subset is somewhat straight-forward, and spec author feedback is
clear I think:
https://lists.w3.org/Archives/Public/www-style/2017Feb/0036.html
I'd be fine not shipping it for now and keeping it behind a pref, but I
don't think it's worth it given how unlikely it is to change. Let me
know if you think otherwise though.
-- Emilio
-David
On Monday 2018-06-25 21:13 +0200, Emilio Cobos Álvarez wrote:
In bug 145 I plan to land most of the syntax improvements to
mediaqueries-4.
Some of the features included are:
* Allowing operators such as >, <, >=, or <= in media feature expressions,
which allows to properly exclude media queries in a way min-* and max-*
cannot, like:
@media (width >= 900px) { some rules }
@media (width < 900px) { some other rules }
Guarantees that either `some rules` or `some other rules` apply, which is
something that is not guaranteed by the existing syntax (see [1] or [2], for
example).
* Or expressions, and arbitrary expression nesting like:
@media ((width >= 500px) and (width <= 900px)) or (not (orientation:
portrait))
Things that are _not_ included are:
* The range syntax, or allowing values before the feature name, that is:
@media (500px > width) or (500px < width < 900px)
This is nice, but not so trivial to implement, and you can either reverse
the expression (`(width <= 500px)` in the first case), or use the expanded
version of it using `and` expressions for the second.
* The changes to serialization and parsing that allows basically anything
in a feature expression to be valid, that is, treating as a valid media
query something like:
@media (orientation: portrait) or (garbage)
Bug 1469174 and bug 1469173 are tracking those two, respectively.
Let me know if you find unknown issues, or think we shouldn't ship this.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Coding style: Making the `e` prefix for enum variants not mandatory?
And Kris pointed out that we already had another huge thread on this:
https://groups.google.com/d/msg/mozilla.dev.platform/WAuySoTfq_w/-DggRotpBQAJ
Looks like there wasn't agreement on that one... But oh well, don't want
to repeat a lot of that discussion.
I think the argument for consistency with the other systems language we
have in-tree, the fact that it's not predominant (at least for enum
classes) even though it is in the coding style, and that there wasn't
agreement in the previous thread are good reasons for not enforcing it,
but...
-- Emilio
On 6/25/18 10:41 PM, Emilio Cobos Álvarez wrote:
Our coding style states that we should use an `e` prefix for enum
variants, that is:
enum class Foo { eBar, eBaz };
We're not really consistent about it: looking at layout/, we mostly use
CamelCase, though we do have some prefixed enums. Looking at other
modules, enum classes almost never use it either. DOM bindings also
don't use that prefix.
I think that with enum classes the usefulness of the prefix is less
justified. Plus removing them would allow us to match the Rust coding
style as well, which is nice IMO.
Would anybody object to making the prefix non-mandatory, removing that
line from the coding style doc? Maybe only making it non-mandatory for
enum classes?
Thanks,
-- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Some of the mediaqueries-4 syntax improvements.
How does the particular set of features that you're planning to ship
vs. not ship align with what other browsers have shipped (or are
close shipping)?
-David
On Monday 2018-06-25 21:13 +0200, Emilio Cobos Álvarez wrote:
> In bug 145 I plan to land most of the syntax improvements to
> mediaqueries-4.
>
> Some of the features included are:
>
> * Allowing operators such as >, <, >=, or <= in media feature expressions,
> which allows to properly exclude media queries in a way min-* and max-*
> cannot, like:
>
> @media (width >= 900px) { some rules }
> @media (width < 900px) { some other rules }
>
> Guarantees that either `some rules` or `some other rules` apply, which is
> something that is not guaranteed by the existing syntax (see [1] or [2], for
> example).
>
> * Or expressions, and arbitrary expression nesting like:
>
> @media ((width >= 500px) and (width <= 900px)) or (not (orientation:
> portrait))
>
> Things that are _not_ included are:
>
> * The range syntax, or allowing values before the feature name, that is:
>
> @media (500px > width) or (500px < width < 900px)
>
>This is nice, but not so trivial to implement, and you can either reverse
> the expression (`(width <= 500px)` in the first case), or use the expanded
> version of it using `and` expressions for the second.
>
> * The changes to serialization and parsing that allows basically anything
> in a feature expression to be valid, that is, treating as a valid media
> query something like:
>
> @media (orientation: portrait) or (garbage)
>
> Bug 1469174 and bug 1469173 are tracking those two, respectively.
>
> Let me know if you find unknown issues, or think we shouldn't ship this.
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.org/ 턂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)
signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Coding style: Making the `e` prefix for enum variants not mandatory?
Our coding style states that we should use an `e` prefix for enum
variants, that is:
enum class Foo { eBar, eBaz };
We're not really consistent about it: looking at layout/, we mostly use
CamelCase, though we do have some prefixed enums. Looking at other
modules, enum classes almost never use it either. DOM bindings also
don't use that prefix.
I think that with enum classes the usefulness of the prefix is less
justified. Plus removing them would allow us to match the Rust coding
style as well, which is nice IMO.
Would anybody object to making the prefix non-mandatory, removing that
line from the coding style doc? Maybe only making it non-mandatory for
enum classes?
Thanks,
-- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: Some of the mediaqueries-4 syntax improvements.
Hi,
In bug 145 I plan to land most of the syntax improvements to
mediaqueries-4.
Some of the features included are:
* Allowing operators such as >, <, >=, or <= in media feature
expressions, which allows to properly exclude media queries in a way
min-* and max-* cannot, like:
@media (width >= 900px) { some rules }
@media (width < 900px) { some other rules }
Guarantees that either `some rules` or `some other rules` apply, which
is something that is not guaranteed by the existing syntax (see [1] or
[2], for example).
* Or expressions, and arbitrary expression nesting like:
@media ((width >= 500px) and (width <= 900px)) or (not
(orientation: portrait))
Things that are _not_ included are:
* The range syntax, or allowing values before the feature name, that is:
@media (500px > width) or (500px < width < 900px)
This is nice, but not so trivial to implement, and you can either
reverse the expression (`(width <= 500px)` in the first case), or use
the expanded version of it using `and` expressions for the second.
* The changes to serialization and parsing that allows basically
anything in a feature expression to be valid, that is, treating as a
valid media query something like:
@media (orientation: portrait) or (garbage)
Bug 1469174 and bug 1469173 are tracking those two, respectively.
Let me know if you find unknown issues, or think we shouldn't ship this.
Thanks!
-- Emilio
[1]:
http://damienclarke.me/code/posts/those-1px-gaps-between-media-queries-can-be-a-problem
[2]: https://github.com/twbs/bootstrap/issues/19197
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Slightly delayed Intent to Ship: getComputedStyle changes on some edge cases.
Hi, Just something I figure was worth sending an email for, due to the potential (ideally positive) web-compat impact. In bug 1467722[1], I brought us closer to the spec and to WebKit / Blink in terms of what happens when we can't return a style for an element from getComputedStyle (mostly relevant for hidden iframes, for example). Before that change, we either returned null (if you called getComputedStyle _after_ hiding the iframe) or threw an NS_ERROR_NOT_AVAILABLE exception (if you call getComputedStyle before hiding the frame, but getPropertyValue afterwards). Now we'll never return null for getComputedStyle(..), and we'll return an empty string and a .length of zero when we can't get a style, aligning us with other browser's 'no style' behavior[2]. The idea is that this will prevent most of the pain that bugs like [3] cause us, and be a step into aligning with the CSSOM spec more closely. This landed on time for 62, and I don't expect any breakage from it, but let me know if you see something. -- Emilio [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1467722 [2]: WebKit and Blink do not return a style for an element outside of the document, for example, and they behave that way in that case. [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=548397 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
[desktop] Bugs logged by Desktop Release QA in the last 8 days
Hello, Here's the list of new issues found and filed by the Desktop Release QA team last two weeks. Additional details on the team's priorities last week, as well as the plans for the current week are available at: https://tinyurl.com/yb3fuetd Bugs logged by Desktop Release QA in the last 8 days Firefox: Site Identity and Permission Panels NEW - https://bugzil.la/1470382 - Visibility issues inside permission doorhanger on dark theme Firefox: PDF Viewer NEW - https://bugzil.la/1470409 - Visual glitches are triggered on zoom inside a Pdf. file Firefox: Keyboard Navigation NEW - https://bugizl.la/1470410 - "Page Up" doesn't scroll to the beginning of the list in Storage Inspector (DevTools) Core: DOM NEW - https://bugzil.la/1470419 - Video controls tooltips are offset on "spiegel.de" Core: Audio/Video: Playback NEW - https://bugzil.la/1469558 - The adds are played on top of a video from the bbc website Core: Layout: Text NEW - https://bugzil.la/1470136 - [WIN] Text descenders are clipped/covered on linkedin's "profile strength" section Core: DOM: Core & HTML NEW - https://bugzil.la/1470154 - theGuardian.com - menu Close click goes trough To scrollbar under it Toolkit: Video/Audio Controls NEW - https://bugzil.la/1470377 - Video context menu does not stay on screen and it pauses the video on Twitter Toolkit: Startup and Profile NEW - https://bugzil.la/1469314 - "Welcome to Firefox" page is not loaded when opening Firefox by dragging and dropping the path to a an .exe file into Command Prompt DevTools: Storage Inspector NEW - https://bugzil.la/1470406 - Keyboard navigation in Storage Inspector (DevTools) doesn't work properly This is available as a Bugzilla bug list as well: https://tinyurl.com/yc55v63l Regards, Bogdan (:bogdan_maris) Desktop Release QA ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Code Coverage Summary
Vào 06:37:53 UTC+7 Thứ Bảy, ngày 23 tháng 6 năm 2018, Kyle Lahnakoski đã viết: > ## Overview > > * **Coverage on recent changesets** - A list of recent changesets and > the percent of new lines covered by tests. > https://firefox-code-coverage.herokuapp.com > * **Coverage addon** - Use it to show coverage on your patches in > Bugzilla - > https://addons.mozilla.org/en-US/firefox/addon/gecko-code-coverage/ > * **Daily coverage aggregates** - by directory and file - > https://codecov.io/gh/mozilla/gecko-dev > * **Zero coverage reports** - > https://marco-c.github.io/code-coverage-reports/ with ore details here: > https://release.mozilla.org/tooling/codecoverage/2018/03/23/code-coverage.html > * **Not-so-raw coverage artifacts** - If you are interested in the > details, you may want to see the artifacts produced by coverage builds: > https://treeherder.mozilla.org/#/jobs?repo=mozilla-central=ccov > > > ## Contact Us > > If you want to know more, or want to participate, stop by and say "hi": > > * **Mail list** - codecover...@mozilla.com > * **IRC** - #codecoverage > > > ## Details > > This past 6 months have been spent working on minutia and hard problems > of the CodeCoverage system. There are many platforms, many suites, a > complex build, and a lot of data. Taming the complexity so we can > provide "clean" coverage artifacts is proving arduous. Here are some > examples: > > * **translating filenames** - Our build has generated source files, and > files copied to appropriate directories before compile. The file > reported in coverage artifacts must be mapped back to files we see in > the tree. Our coverage processing now does this work. > * **chunk <-> file mapping** - Our coverage is collected by running > hundreds of tasks, each responsible for running some part of a test > suite; called a "chunk". An interesting question is "if we have a > changeset, and we know what files it changed, can we schedule less > chunks?" The chunk<->file mapping allows use to answer that question. > Turns out the answer is "not really". > * **windows coverage** - If you visit Treeherder you will see we are > collecting coverage on Windows (using clang-cl). This allows us to see > platform-specific lines. > * **grcov improvements** - now faster than before, and can process llvm > coverage output > * **jsdcov e10s** - We had to verify that coverage was getting > collected by all processes > * **frontend refinements** - There has been continued work on the > frontend to meet Release Management's use cases. Another cohort of > UCOSP students has helped fix bugs, and added functionality to the > frontend. > * **variability analysis** - Coverage at the Firefox-scale has > variability from many different sources. For instance, running the same > test on the same revision multiple times shows differences from one run > to the next. Plus, in some other cases, tests fail, which results in > different coverage. These situations were explored in more detail to > better understand what variability we are dealing with. > * **jsdcov vs jsvm** - Both are collecting coverage on javascript; they > appear to be capturing different coverage; we must look into this more > * **bugs!** - Many bugs, timing bugs in the tests, and bugs in the > coverage collection/reporting pipeline. > * **android experiments** - Android will be be given more focus in the > coming year, so we should look at how coverage will help. > * **backend improvements** - Work that must be done to deal with data > volume, but is barely visible to the end user. > * **backend moved to production** - CodeCoverage has moved to > production; and this took time. > * **subtracting baselines** - We reduce our coverage artifact size by > subtracting no-test coverage from test coverage. In theory, after > subtraction, the coverage represents what is uniquely used by the test > and removes all standard browser/test start and shutdown coverage. > However, we have found that coverage variability is affecting these > results as well and are now looking into mitigation strategies. > * **per test coverage** - One of our goals is to collect coverage at > the test level; this can help guide what tests should be run when a file > changes. It may also help with understanding gaining a deeper > understanding of what our tests are testing. > > ## The Future > > * **move off codecov.io** - Our data volume and our use cases, do not > fit with codecov.io. We will use our own database to store coverage > artifacts, and enable us to do more. > * **per test coverage** - One of our goals is to collect coverage at > the test level; this can help guide what tests should be run when a file > changes. It might also help understanding which tests are important > (e.g. for evaluating whether to disable or fix intermittent tests) > * **compare coverage across revisions** - We want to markup the > coverage so a reasonable comparison can be done between
