Re: Updated mozilla-central code coverage
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: Hi Joshua, Great job for working on this! However I found that the coverage doesn't include those ran on child process (e.g. ContentChild). It would be wonderful if we can add the support on it. The coverage files are emitted by a process when it exits via an atexit hook. If anything causes that hook not to fire (e.g., the process is still running at the time the testsuite exits, or if the process is killed by a segfault or other signal), then no coverage data would be emitted. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ 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: Updated mozilla-central code coverage
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 Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Replacing PR_LOG levels
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 people are used to enabling debug on random modules (or all:5), having verbose debugs in the normal :5 setting will cause pain. Can this be controlled some other way? Via a #define? Via another environment variable? Definitely *not* a #define. That makes it close-to-useless. I ask because in discussions with Eric I've been encouraging him to reduce the number of logging levels as much as possible. It would be sad to have to complicate the general mechanism because one module does things differently to the rest of the system. My point (as repeated here in other posts) is that you're reducing complexity (in number of log levels) by adding complexity elsewhere (and more total complexity, IMHO). I'd consider your suggestion above an example of complicating the general mechanism, but doing it indirectly so it can *appear* to be simple (but isn't really). This isn't a single module using values above DEBUG - this is *all* over the media modules in different debug tags. Audio, MediaDecoder, MediaStreamGraph, MediaManager, WebM, etc. Also, the current patch misses a number of uses like MediaEngine: #define LOG(msg) PR_LOG(GetMediaManagerLog(), PR_LOG_DEBUG, msg) #define LOGFRAME(msg) PR_LOG(GetMediaManagerLog(), 6, msg) (yes, this uses 6, such that the common habit of blah:5 logging doesn't turn on the spam - you have to *want* it) I like fixing up logging! I just think shoehorning a level *under* DEBUG confuses things, while adding a level *above* DEBUG would let up standardize/regularize current practice (and avoid the (temporary) which version am I using problem.) /me stops arguing having said his piece -- Randell Jesup, Mozilla Corp remove news for personal email ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Replacing PR_LOG levels
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 Verbose/Trace). I don't know why we wouldn't just add a more verbose log level (Verbose, Trace... I don't care what we call it). The presence of DEBUG + 1 in our code is evidence of a clear, actual need. This was my thought as well initially (my first proposal had a Verbose level). After auditing the code I changed my mind. I believe adding the Info level will serve this need. The feeling I got from most code that did 'DEBUG + 1' was that they needed to use DEBUG for the informational stuff (because there was no Info level) and wanted a lower level for the more spammy stuff (DEBUG was occupied, so fine DEBUG + 1). This was exemplified with the many variations of: #define LOGI(...) PR_LOG(..., PR_LOG_DEBUG) #define LOGV(...) PR_LOG(..., PR_LOG_DEBUG + 1) Note: For LOGI, to me at least, 'I' = Info Flipside of course the 'V' = Verbose, but I think this a semantic issue. Debug and Verbose are essentially the same thing now that we have Info. Only if you avoid the which module debug pattern am I in question by switching *all* non-verbose uses of PR_LOG_DEBUG to PR_LOG_INFO (basically remap DEBUG to INFO, so that verbose logging can own the DEBUG level... but this seems way overkill (and liable to cause horrible ongoing confusion) compared to allowing a PR_LOG_VERBOSE level. PR_LOG_VERBOSE is clear and understandable. Modules where normal debugs are on INFO and you-likely-don't-want-it is on DEBUG will cause ongoing mental anguish and mismatch, and confusion for new contributors. We can see this ambiguity in various logging frameworks, generally there's a debug, but if there's not there's a verbose/trace, and usually not both. Though Android has both. -- Randell Jesup, Mozilla Corp remove news for personal email ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
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 in that case? The prompts as implemented in IE are horrible, but I think there could be many better ways of doing it. Here is one way I have thought of how a prompt could look like, since you only allow it in relation to user interaction, you could make a prompt that looks like a context menu for the element the user interacted with, using a single word describing the action. I have implemented a mockup at http://jsfiddle.net/vvjcgj5g/1/ but I am sure Mozilla UX people could come up with better ways to do this. (My mockup has a prompt for all three actions, but you could do it for paste only) Handling paste is a difficult topic, and I definitely don't have a good answer yet. 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 page can handle the event to do something useful with the pasted data. -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MemShrink Meeting - Today, 26 May 2015 at 4:00PM PDT
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 progress. * Discuss approaches to getting more data. Meeting details: * Tue, 26 May 2015, 4:00 PM PDT * http://arewemeetingyet.com/Los%20Angeles/2015-05-26/16:00/MemShrink%20Meeting * Vidyo: Memshrink * Dial-in Info: - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference num 98802 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
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 mechanism the browser has to trigger a paste, and the page can handle the event to do something useful with the pasted data. The same can be said about cut and copy. I don't think it will work for my use case. Here is my use case: I have a web application that allows the user to upload tabular data. Users most often prepare the data in Excel or other spreadsheet applications before uploading the data. My application supports a CSV file upload, but it is slow to use, since you have to copy the section you which to upload into a separate spreadsheet, save it as a file, go into the web application and find the same file, upload it, and then delete the temporary file. You also get issues with character encoding when saving as CSV from Excel. As a quicker solution the web application allows the user to copy-paste the relevant section of their excel file into the web application, which takes much fewer steps. However users often need to paste large amounts of data (millions of cells), which will make the browser freeze while it tries to render the pasted text in the textarea. 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 paste event on a text area would be a confusing user experience, since you would have a visible text area that would not work when you type into it, and it looks like you would see your text when you paste, but you won't. So I believe I need to trigger the paste event when the user clicks a button in order to do this. People have used tricks with invisible text areas for other similar use cases. One example that comes to my mind is some editor widgets which place a transparent text area where the current caret should be in order to paint the caret and also receive an input event when the user types a character, but of course this is a gross hack at best... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
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 paste event on a text
area would be a confusing user experience, since you would have a
visible text area that would not work when you type into it, and it
looks like you would see your text when you paste, but you won't. So I
believe I need to trigger the paste event when the user clicks a button
in order to do this.
Your use case is the intended use of the paste event and doesn't require
a separate button.
The following, for example, pastes only the first letter of the text on
the clipboard:
input onpaste=this.value =
event.clipboardData.getData('text/plain')[0]; event.preventDefault()
What you can't do though is have two separate types of pastes, such as a
normal Paste and a Paste Without Formatting type of option, although you
could workaround this with a toggle that needs to be clicked first.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Updated mozilla-central code coverage
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 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 been made easier over the years by standardization of some of the hacks, such that you can now push to linux64-cc and get most of the same information. Notable changes I've made since the last upload: 1. I dropped debug builds, so all the information comes from Linux opt, both 32 and 64-bit. 2. Test names now derive from builder names directly, removing the need for a very long hardcoded list of M-bc means mochitest-browser-chrome. 2a. This means that what was once mochitest-1, mochitest-2, etc. is now condensed into mochitest. Mochitest-e10s-browser-chrome, etc., remain split out. 3. Minor changes in the UI frontend to help deal with the fact that my hosting webserver changed to forcing https. 4. I can now generate the ultimate combined .info file without needing manual post-processing, for the first time ever. The marionette and web-platform tests remain unaccounted for in coverage (Mn, Mn-e10s, Wr, W-* in treeherder lingo), and the new Ld (luciddream?) appears to be broken as well. On the possibility of expanding code coverage information to different platforms, languages, and tests: 1. OS X still has a link error and/or fail-to-run issue. I suspect a newer clang would help, but I lack a local OS X instance with which to do any detailed tests. I've never tested the ability of my scripts to adequately collect clang code coverage data, and I suspect they would themselves need some modification to do so. 2. Android builds work and can report back code coverage data, but so intermittently that I didn't bother to try including them. In my try run that I used to generate these results, mochitest-2 reported back data but mochitest-6 did not, yet both testsuites reported back success. The reason for this is not clear, so any help people could give in debugging issues would be most appreciated. 3. B2G desktop builds and Mulet builds on Linux appeared to work. However, the builds didn't appear to upload the gcno package for unknown reasons, and taskcluster uses such different mechanisms to upload the files that my scripts are of no use in collecting the gcda packages. 4. Windows is... special when it comes to code coverage. This is the last platform I would look at tackling. 5. JS code coverage is of course a hole I'd like to see rectified, but I don't have the time to invest in solving it myself. 6. Are we actually using Rust yet on our tryserver builds? 7. Android Java coverage is deferred until after I can get reliable Android code coverage in the first place. 8. I'd have to look into modifying mozharness to run code coverage on marionette et al builds. It shouldn't be hard, but it is annoying to have to hook into so many places to insert code coverage. 9. Ditto for Android xpcshell and cppunit tests. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Updated mozilla-central code coverage
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 been made easier over the years by standardization of some of the hacks, such that you can now push to linux64-cc and get most of the same information. Notable changes I've made since the last upload: 1. I dropped debug builds, so all the information comes from Linux opt, both 32 and 64-bit. 2. Test names now derive from builder names directly, removing the need for a very long hardcoded list of M-bc means mochitest-browser-chrome. 2a. This means that what was once mochitest-1, mochitest-2, etc. is now condensed into mochitest. Mochitest-e10s-browser-chrome, etc., remain split out. 3. Minor changes in the UI frontend to help deal with the fact that my hosting webserver changed to forcing https. 4. I can now generate the ultimate combined .info file without needing manual post-processing, for the first time ever. The marionette and web-platform tests remain unaccounted for in coverage (Mn, Mn-e10s, Wr, W-* in treeherder lingo), and the new Ld (luciddream?) appears to be broken as well. On the possibility of expanding code coverage information to different platforms, languages, and tests: 1. OS X still has a link error and/or fail-to-run issue. I suspect a newer clang would help, but I lack a local OS X instance with which to do any detailed tests. I've never tested the ability of my scripts to adequately collect clang code coverage data, and I suspect they would themselves need some modification to do so. 2. Android builds work and can report back code coverage data, but so intermittently that I didn't bother to try including them. In my try run that I used to generate these results, mochitest-2 reported back data but mochitest-6 did not, yet both testsuites reported back success. The reason for this is not clear, so any help people could give in debugging issues would be most appreciated. 3. B2G desktop builds and Mulet builds on Linux appeared to work. However, the builds didn't appear to upload the gcno package for unknown reasons, and taskcluster uses such different mechanisms to upload the files that my scripts are of no use in collecting the gcda packages. 4. Windows is... special when it comes to code coverage. This is the last platform I would look at tackling. 5. JS code coverage is of course a hole I'd like to see rectified, but I don't have the time to invest in solving it myself. 6. Are we actually using Rust yet on our tryserver builds? 7. Android Java coverage is deferred until after I can get reliable Android code coverage in the first place. 8. I'd have to look into modifying mozharness to run code coverage on marionette et al builds. It shouldn't be hard, but it is annoying to have to hook into so many places to insert code coverage. 9. Ditto for Android xpcshell and cppunit tests. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updated mozilla-central code coverage
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 are being run under Linux opt cppunittests, then they should be included. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
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 page can handle the event to do something useful with the pasted data. The same can be said about cut and copy. I don't think it will work for my use case. Here is my use case: I have a web application that allows the user to upload tabular data. Users most often prepare the data in Excel or other spreadsheet applications before uploading the data. My application supports a CSV file upload, but it is slow to use, since you have to copy the section you which to upload into a separate spreadsheet, save it as a file, go into the web application and find the same file, upload it, and then delete the temporary file. You also get issues with character encoding when saving as CSV from Excel. As a quicker solution the web application allows the user to copy-paste the relevant section of their excel file into the web application, which takes much fewer steps. However users often need to paste large amounts of data (millions of cells), which will make the browser freeze while it tries to render the pasted text in the textarea. 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 paste event on a text area would be a confusing user experience, since you would have a visible text area that would not work when you type into it, and it looks like you would see your text when you paste, but you won't. So I believe I need to trigger the paste event when the user clicks a button in order to do this. /Jesper Kristensen ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
FileIt has moved
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 transfer of repository, only renames.) It's also worth noting that since FileIt was created, Bugzilla's new bug page has had a similar component search field added: https://bugzilla.mozilla.org/enter_bug.cgi And the MyDashboard view has one too: https://bugzilla.mozilla.org/page.cgi?id=mydashboard.html Best wishes, Ed ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updated mozilla-central code coverage
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 under check, marionette, web-platform tests, or luciddream. If gtests are being run under Linux opt cppunittests, then they should be included. They are currently running during make check. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
