Test Informant Report - Week ending Jan 09
Test Informant report for 2015-01-09. State of test manifests at revision 286e1f883fdb. Using revision 636498d041b5 as a baseline for comparisons. Showing tests enabled or disabled between 2015-01-04 and 2015-01-09. 85% of tests across all suites and configurations are enabled. Summary --- marionette- ↑0↓0 - 92% mochitest-a11y- ↑0↓0 - 99% mochitest-browser-chrome - ↑218↓119 - 94% mochitest-browser-chrome-e10s - ↑14↓2 - 58% mochitest-chrome - ↑24↓0 - 96% mochitest-plain - ↑99↓11 - 84% mochitest-plain-e10s - ↑24↓4 - 79% xpcshell - ↑365↓11 - 86% Full Report --- http://brasstacks.mozilla.com/testreports/weekly/2015-01-09.informant-report.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Audio output device selector
What about if I create a firefox plugin? With a C++ plugin can I change the output audio device? Best regards, Balázs SÁNDOR Software Developer Virtual Call Center MUNICH http://virtual-call-center-software.de/ | BUDAPEST http://virtual-call-center-software.hu/ | WARSAW http://virtual-call-center-software.pl/ Phone: +44 (0) 863 801 69 Web: www.virtual-call-center.eu https://www.linkedin.com/profile/view?id=215233036 2014-12-03 16:11 GMT+01:00 Martin Thomson m...@mozilla.com: On 2014-12-03, at 06:24, Balázs Sándor balazs.san...@virtual-call-center.eu wrote: Can I change the audio output device? Currently, no. There is a plan to provide this capability. It was discussed at the last W3C meeting. I don’t think that it has been prioritised (yet). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Memory management in C programs
One large difference between C and most other programming languages is that in C, you have to handle memory yourself rather than having a garbage collector do it for you. Ensuring that memory is allocated at the correct moment is not very difficult (and something that needs to be done manually in pretty much every language); the hard part is to ensure that enough memory is allocated, and to ensure that the memory is deallocated when it is no longer in use. There are several techniques available for memory management in C. Many of them are used in NetHack 3.4.3; and even more are used somewhere in NetHack 4. In this blog post, I'd like to look at them and discuss their advantages and disadvantages. I'm mostly concerned about correctness, rather than efficiency, here; that means that unless the performance difference is very large, I care more about clean code than I do about fast code. http://nethack4.org/blog/memory.html Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendation: longdesc
On Wed, Jan 7, 2015 at 1:13 AM, L. David Baron dba...@dbaron.org wrote: W3C recently published the following proposed recommendation (the stage before W3C's final stage, Recommendation): http://www.w3.org/TR/html-longdesc/ HTML5 Image Description Extension (longdesc) There's a call for review to W3C member companies (of which Mozilla is one) open until January 16. If there are comments you think Mozilla should send as part of the review, or if you think Mozilla should voice support or opposition to the specification, please say so in this thread. I think we should not voice support for this specification (for reasons already stated in this thread). As for abstention vs. opposition, I'd prefer us to voice opposition in the REC transition questionnaire. For reasons already stated in this thread, it's probably not a good use of time to put effort into writing a long essay for the reasons for opposition. Therefore, I suggest choosing the opposition option on the form and just pasting the URL http://lists.w3.org/Archives/Public/public-html-admin/2014Aug/0028.html in the free-form field. That the Formal Objection was overruled shows that FOs are not an effective mechanism for dealing with dysfunction at the W3C. I don't expect our response to make a difference when it comes to longdesc transitioning to a REC, but I think we shouldn't stop signaling to the W3C staff that the way longdesc was handled (not just the FO but also the way the issue was allowed to poison the HTML WG to the point that productive contributors pretty much left the non-Task Force parts of the WG) is not OK--especially when such signaling is as easy as choosing an option on a form. (I'd note, however, that there have been many previous opportunities to make comments, so it's somewhat bad form to bring up fundamental issues for the first time at this stage.) I'm aware that this is boilerplate text, but in this case, it's definitely not a matter of bringing up fundamental issues first time at this stage. (I'm not happy about this spec; for a good description of why, see http://lists.w3.org/Archives/Public/public-html-admin/2014Aug/0028.html . I'm also under the impression that they're using Mozilla's implementation of it as support for the spec, which is rather galling considering that a big piece of what led to that implementation was an online harrassment campaign against a Mozilla UX designer to get the feature accepted. I'm not sure how much it's worth fighting it at this point, although probably a first step in that fight would be to remove our implementation.) Given the circumstances, I think we shouldn't feel that we have a duty to change code in order to register opposition to the REC transition. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How do I use the Dom File API from privileged code (documentation problem)
On 2015-01-11 9:50 PM, Naja Melan wrote: Found some workarounds, see this SO question. MDN updated: https://stackoverflow.com/questions/27893399/how-do-i-use-the-dom-file-api-from-privileged-code/27894221 Thank you for updating the docs! Cheers, Josh ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [blink-dev] Fwd: [Bug 441414] Treerows need a way to hold richer content
On Fri, Jan 9, 2015 at 10:38 AM, Jan Varga jan.va...@gmail.com wrote: HTML5 spec used to have something like that called datagrid Here's some info: https://bugs.webkit.org/show_bug.cgi?id=26545 As a former contributor to XUL tree widget, I would love to see a similar widget in HTML5. In general complex widgets like this are better built as libraries instead of into the platform itself. Jan On 09/01/15 19:18, Philipp Kewisch wrote: I think the question is rather if there is an interest to create a HTML5-equivalent of the XUL tree that has a similar or matching feature set. The main features required are being able to handle a datastore that has 10k+ rows by lazy loading (and unloading) the data into DOM nodes, hierarchical data view with ability to collapse levels, and columns that can be shown and hidden. I know there are a few table data libraries on the web, many of them use jquery. It would be nice to create/use something self-containing that doesn't require external libraries. The limiting factor is obviously time, but I would love to experiment with a HTML5 drop-in replacement that understands nsITreeView and friends. Philipp On 1/9/15 10:56 AM, PhistucK wrote: XUL is explicitly not implemented at all in Chrome, so I would not count on it being implemented in any form. ☆*PhistucK* On Fri, Jan 9, 2015 at 8:32 AM, 罗勇刚(Yonggang Luo) luoyongg...@gmail.com wrote: Does anybody have the intention to implement the things like XUL:tree in HTML5 with power functional. Such as scroll by pixel, and each cell can be either div or canvas -- Forwarded message -- From: Bugzilla@Mozilla bugzilla-dae...@mozilla.org Date: 2015-01-09 5:34 GMT+08:00 Subject: [Bug 441414] Treerows need a way to hold richer content To: luoyongg...@gmail.com Do not reply to this email. You can add comments to this bug at https://bugzilla.mozilla.org/show_bug.cgi?id=441414 David Baron [:dbaron] (UTC-8) (needinfo? for questions) dba...@dbaron.org changed: What|Removed |Added Flags|needinfo?(dba...@dbaron.org | |) | --- Comment #204 from David Baron [:dbaron] (UTC-8) (needinfo? for questions) dba...@dbaron.org 2015-01-08 13:34:46 PST --- (In reply to Yonggang Luo from comment #195) (In reply to David Baron [:dbaron] (UTC-8) (needinfo? for questions) from comment #194) Comment on attachment 8497672 0005-Fixes-for-bug-441414-to-add-rich-tree-support-crasht.patch As discussed in dev-platform, we don't want to take major feature improvements to XUL. I didn't see any HTML5 equivalent for XUL tree element. And this should not be a major feature improvements. This is a major feature; major features add substantial maintenance cost over time, and we're not interested in adding to that cost by adding additional XUL features. -- Configure bugmail: https://bugzilla.mozilla.org/userprefs.cgi?tab=email --- Product/Component: Core :: XUL --- You are receiving this mail because: --- You voted for the bug. You are on the CC list for the bug. -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. ___ 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: Audio output device selector
Our audio output subsystem is not an XPCOM component, so I would say no. Paul. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Good ways to view Firefox compile errors in a terminal?
Hi,
If you do |mach build| and get compile errors, often those errors
scroll quickly off screen and they are mixed in with other lines of
output and it's hard to find them.
I deal with this by using a bash alias that calls |mach build| and
pipes the output to file. I can then use Vim's quicklists feature to
jump directly to errors in the file. But sometimes I just want to
eyeball the errors directly in the terminal, so in my alias I also
have a post-build step that greps the output file for the first five
error messages.
This setup works well for me but it's also kinda gross [1] and this
seems like a problem that everybody else working on C++ code has to
deal with as well. So I'm wondering if there are other, better ways of
doing it, and if so, could they be made automatic? There is |mach
warnings-list| which is sort of like this, but not quite.
Thanks.
Nick
[1] How gross? Here are the two most important lines:
# Send mach's raw output to stdout and $config/log, and the
# timestamp-stripped output to errors.err. The $| = 1 disables Perl's
# buffering, so the output is available immediately.
MOZCONFIG=$HOME/moz/config/$config nice mach build $restdir 21 | \
tee (perl -p -e '$| = 1; s/^ *\d+:\d\d\.\d\d //' errors.err) \
$config/log
# Show up to five errors, with 10 lines of trailing context each. But
# first, truncate line length to 300 chars (because I sometimes get
# extremely long lines describing the command line used, which are
# annoying).
perl -p -e 's/^(.{300}).*$/\1/' $config/log | \
grep --max-count=5 --before-context=3 --after-context=10 \error:
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Good ways to view Firefox compile errors in a terminal?
I use the Konsole terminal, and have the Find bar always activated, with
error: typed in as the search string.
When I get a failing build, I click the handy From bottom button, which
searches backward from the bottom of the terminal output. That takes me to
the error I want to see in one click 99.9% of the time.
Cheers,
Botond
On Mon, Jan 12, 2015 at 5:09 PM, Nicholas Nethercote n.netherc...@gmail.com
wrote:
Hi,
If you do |mach build| and get compile errors, often those errors
scroll quickly off screen and they are mixed in with other lines of
output and it's hard to find them.
I deal with this by using a bash alias that calls |mach build| and
pipes the output to file. I can then use Vim's quicklists feature to
jump directly to errors in the file. But sometimes I just want to
eyeball the errors directly in the terminal, so in my alias I also
have a post-build step that greps the output file for the first five
error messages.
This setup works well for me but it's also kinda gross [1] and this
seems like a problem that everybody else working on C++ code has to
deal with as well. So I'm wondering if there are other, better ways of
doing it, and if so, could they be made automatic? There is |mach
warnings-list| which is sort of like this, but not quite.
Thanks.
Nick
[1] How gross? Here are the two most important lines:
# Send mach's raw output to stdout and $config/log, and the
# timestamp-stripped output to errors.err. The $| = 1 disables Perl's
# buffering, so the output is available immediately.
MOZCONFIG=$HOME/moz/config/$config nice mach build $restdir 21 | \
tee (perl -p -e '$| = 1; s/^ *\d+:\d\d\.\d\d //' errors.err) \
$config/log
# Show up to five errors, with 10 lines of trailing context each. But
# first, truncate line length to 300 chars (because I sometimes get
# extremely long lines describing the command line used, which are
# annoying).
perl -p -e 's/^(.{300}).*$/\1/' $config/log | \
grep --max-count=5 --before-context=3 --after-context=10 \error:
___
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: Good ways to view Firefox compile errors in a terminal?
|mach warnings-list| and the underlying implementation to parse and store
warnings [1] are one of the very first features of mach and there is
definite room for improvement. If the functionality isn't doing what you
want, send a patch to change it!
We probably could integrate warning parsing into the compiler wrapper
script so that we have the exact command arguments and full program output
available. Parsing make output is and will always be haphazard. But it was
the easiest to implement at the time.
[1]
https://dxr.mozilla.org/mozilla-central/source/python/mozbuild/mozbuild/compilation/warnings.py
On Mon, Jan 12, 2015 at 2:09 PM, Nicholas Nethercote n.netherc...@gmail.com
wrote:
Hi,
If you do |mach build| and get compile errors, often those errors
scroll quickly off screen and they are mixed in with other lines of
output and it's hard to find them.
I deal with this by using a bash alias that calls |mach build| and
pipes the output to file. I can then use Vim's quicklists feature to
jump directly to errors in the file. But sometimes I just want to
eyeball the errors directly in the terminal, so in my alias I also
have a post-build step that greps the output file for the first five
error messages.
This setup works well for me but it's also kinda gross [1] and this
seems like a problem that everybody else working on C++ code has to
deal with as well. So I'm wondering if there are other, better ways of
doing it, and if so, could they be made automatic? There is |mach
warnings-list| which is sort of like this, but not quite.
Thanks.
Nick
[1] How gross? Here are the two most important lines:
# Send mach's raw output to stdout and $config/log, and the
# timestamp-stripped output to errors.err. The $| = 1 disables Perl's
# buffering, so the output is available immediately.
MOZCONFIG=$HOME/moz/config/$config nice mach build $restdir 21 | \
tee (perl -p -e '$| = 1; s/^ *\d+:\d\d\.\d\d //' errors.err) \
$config/log
# Show up to five errors, with 10 lines of trailing context each. But
# first, truncate line length to 300 chars (because I sometimes get
# extremely long lines describing the command line used, which are
# annoying).
perl -p -e 's/^(.{300}).*$/\1/' $config/log | \
grep --max-count=5 --before-context=3 --after-context=10 \error:
___
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
Jemalloc 3 is now on by default
Hi, I just landed bug 762449 on inbound, which enables Jemalloc 3 on the nightly channel. This puts us a step forward to removing mozjemalloc, our highly patched fork of jemalloc 0.9. More importantly, it will allow us to more closely work with upstream, by proposing patches that do apply there (which is not the case every time we do changes to mozjemalloc), or taking improvements from upstream (which, for some, we backported to mozjemalloc, with pain). For now, the change is such that it won't ride the trains, because there are a few known regressions that need to be addressed first, but I'd expect them to be fixed by next merge-day. From a developer point of view, this shouldn't change anything. Thanks to Guilherme Gonçalves, Eric Rahm, and Emanuel Hoogeveen for the hard work. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Jemalloc 3 is now on by default
On Tue, Jan 13, 2015 at 10:13:34AM +0900, Mike Hommey wrote: Hi, I just landed bug 762449 on inbound, which enables Jemalloc 3 on the nightly channel. This puts us a step forward to removing mozjemalloc, our highly patched fork of jemalloc 0.9. More importantly, it will allow us to more closely work with upstream, by proposing patches that do apply there (which is not the case every time we do changes to mozjemalloc), or taking improvements from upstream (which, for some, we backported to mozjemalloc, with pain). Aaand as usual with such changes, it didn't stick. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Jemalloc 3 is now on by default
On 1/12/2015 9:44 PM, Mike Hommey wrote: Aaand as usual with such changes, it didn't stick. Does that mean I should assume that whenever someone makes this sort of announcement, I should assume they really mean this will take effect tomorrow or the day after, when I've figured out what went wrong? :-) -- 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
