Thanks for the explanation. IIRC content process is closed by SIGKILL in
Gecko. Looks like we'll have to tweak the timing.
Best Regards,
Shih-Chiang Chien
Mozilla Taiwan
On Wed, May 27, 2015 at 10:10 AM, Joshua Cranmer pidgeo...@gmail.com
wrote:
On 5/26/2015 8:54 PM, Shih-Chiang Chien wrote:
On 5/26/2015 10:20 PM, Shih-Chiang Chien wrote:
Thanks for the explanation. IIRC content process is closed by SIGKILL in
Gecko. Looks like we'll have to tweak the timing.
A SIGKILL would definitely not trigger the information to be dumped.
--
Joshua Cranmer
Thunderbird and DXR developer
On Sat, May 23, 2015 at 4:46 AM, Randell Jesup rjesup.n...@jesup.org wrote:
This is used extensively in WebRTC and related media bits to enable
*huge* amounts of debugs (like every-frame debugs for audio or video or
per-network-packet debugs, which will swamp a system normally), and since
Thanks Adam, these are good points.
On Friday, May 22, 2015 at 2:08:33 PM UTC-7, Adam Roach wrote:
On 5/22/15 15:51, Eric Rahm wrote:
I agree, we shouldn't make it harder to turn on logging. The easy
solution is just to add a separate logger for verbose messages (if we
choose not to add
On Mon, May 25, 2015, at 11:04 AM, Ehsan Akhgari wrote:
On 2015-05-23 5:02 AM, Jesper Kristensen wrote:
Very nice, I am looking very much forward to using this.
It would be nice of you could also support paste. I agree that it is
more sensitive, so maybe you could go with a user prompt
Today's MemShrink meeting is brought to you by memory.report_concurrency:
https://bugzilla.mozilla.org/show_bug.cgi?id=1154053
The wiki page for this meeting is at:
https://wiki.mozilla.org/Performance/MemShrink
Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure
On 2015-05-26 10:42 AM, Jesper Kristensen wrote:
Den 26-05-2015 kl. 13:13 skrev Ted Mielczarek:
Additionally, the 'paste' event from the spec already works, which seems
like it provides pretty useful functionality for webapps. The user can
use Ctrl+V or Edit-Paste or whatever existing UI
On 2015-05-26 10:42 AM, Jesper Kristensen wrote:
It would be much faster if I could just present a Paste data or
Upload from clipboard button, which could load the data from the
clipboard directly into a JavaScript string without first trying to
render it. I feel that doing this by handling the
Does this coverage info also include gtests? From a quick glance it looks like
not.
On Tuesday, May 26, 2015 at 2:59:16 PM UTC-4, Joshua Cranmer wrote:
I've posted updated code coverage information for mozilla-central to
https://www.tjhsst.edu/~jcranmer/m-ccov/. This data is accurate as of
I've posted updated code coverage information for mozilla-central to
https://www.tjhsst.edu/~jcranmer/m-ccov/. This data is accurate as of
yesterday. For those of you who are unaware, I periodically run these
code coverage statistics by use of the try server and instrumented runs.
This has
On 5/26/2015 3:21 PM, kgu...@mozilla.com wrote:
Does this coverage info also include gtests? From a quick glance it looks like
not.
The code coverage includes all tests run on Linux opt or Linux-64 opt
excluding those run under check, marionette, web-platform tests, or
luciddream. If gtests
Den 26-05-2015 kl. 13:13 skrev Ted Mielczarek:
Additionally, the 'paste' event from the spec already works, which seems
like it provides pretty useful functionality for webapps. The user can
use Ctrl+V or Edit-Paste or whatever existing UI mechanism the browser
has to trigger a paste, and the
FileIt (a tool for quickly finding the product/component for filing a bug)
has been moved from Heather's github account to mine, since she no longer
wishes to maintain it.
It can now be found here:
https://edmorley.github.io/fileit/
(Unfortunately Github doesn't set up HTTP redirects for a
On Tue, May 26, 2015 at 03:48:06PM -0500, Joshua Cranmer ? wrote:
On 5/26/2015 3:21 PM, kgu...@mozilla.com wrote:
Does this coverage info also include gtests? From a quick glance it looks
like not.
The code coverage includes all tests run on Linux opt or Linux-64 opt
excluding those run
14 matches
Mail list logo
