Re: Xulrunner standalone application auto update stopped working
Manish wrote: Also we came across this error on console: Error: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIStringBundle.GetStringFromName] Source File: XStringBundle Line: 21 If you had a debug build you could try setting a breakpoint here: http://mxr.mozilla.org/mozilla-release/source/intl/strres/src/nsStringBundle.cpp#219 aName would contain the missing string name, or you could call DumpJSStack() to find the caller. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Enabling NSPR logging in release builds
Any noticable impact on the binary code size? -- - Milan On Oct 3, 2014, at 16:12 , Eric Rahm er...@mozilla.com wrote: Hi all- In bug 806819 we're planning on landing a change that allows us to turn on NSPR logging in release builds [1]. To be clear, by default all logging output is disabled, this will just allow you to turn on logging via the same mechanisms [2] that have been available to debug builds and modules that already force logging to be enabled. Initial tests show no impact to performance, but of course it's possible there will be unforeseen regressions. Testing included all Talos tests, averaging of mochitest runtimes, and local ad-hoc performance measurements. Areas to look out for: * Logging being done in hot areas. PR_LOG is no longer a no-op so there is a slight amount of overhead with each logging call. If your output is truly debug only consider wrapping in a #ifdef DEBUG block. * Creating a log message and then logging it. PR_LOG supports printf style formatting, so you can save some overhead by using that rather than writing to your own buffer. For example, if you once had: #ifdef PR_LOGGING char* msg = expensiveFunction(); PR_LOG(module, PR_LOG_DEBUG, (msg)); #endif You'll want to move to: PR_LOG(module, PR_LOG_DEBUG, (%s, expensiveFunction())); If you're interested in making logging better, please take a look at our meta bug [3] tracking various improvements. There's talk of making improvements to NSPR logging, ditching NSPR logging all together, adding streaming interfaces, switching log levels at runtime, and more. Feel free to join in the conversation. Please note: after this change you should never need to use FORCE_PR_LOG (and you'll probably get build errors if you do). A few side benefits: * All usage of FORCE_PR_LOG has been removed * Many more files are now eligible for unified building -e [1] https://bugzilla.mozilla.org/show_bug.cgi?id=806819 [2] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSPR/Reference/Logging [3] https://bugzilla.mozilla.org/show_bug.cgi?id=881389 ___ 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: Using c++11 right angle bracket in template code?
On Thu, Oct 02, 2014 at 01:58:52PM -0400, Ehsan Akhgari wrote:
On 2014-10-02, 1:14 AM, Xidorn Quan wrote:
On Wed, Oct 1, 2014 at 6:27 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
mailto:ehsan.akhg...@gmail.com wrote:
On 2014-10-01, 7:42 PM, L. David Baron wrote:
On Wednesday 2014-10-01 16:24 -0700, Eric Rescorla wrote:
Obviously, if you have some argument that auto is bad
programming practice
or a hazard and should thus be forbidden, that's something
you could make
and
see if people generally agree...
I think there are cases where |auto| makes code substantially less
readable, and cases where it's fine. I don't think I have enough
experience reading code using |auto| to say exactly what's in which
set, but I have mandated less use of |auto| in code reviews.
Some of it is simple readability; there are cases where seeing the
type of a variable allows its name to be simpler while preserving
the same level of readability, and if we're going to hide the type,
I'd want it to have a more complex name to make the code obvious.
But I'm also worried about use of auto leading people to stop using
const or where they should be (particularly where |auto| instead
of |const auto| leads to unnecessary expensive copies). (And I
think knowing whether I want |auto| or |const auto| requires
knowing the type, which makes the feature less valuable to me.)
I'm fine with just enforcing reasonable judgment in code reviews,
although I suspect some people would be bothered by having code
reviewers enforce style rules that aren't written down.
FWIW, I have had some actual practical experience in using |auto| in
the LLVM code base (and with reading code that uses it). Here is my
take on things:
* Beware of using auto in cases where types can be constructed
implicitly from other types.
This is the most important rule, I think. Here's an example of how
this can introduce real bugs. Let's imagine you have code like this:
nsIFoo* FooGetter();
nsCOMPtrnsIFoo foo = FooGetter();
DO NOT replace the type here with auto:
auto foo = FooGetter(); // NOT COOL!
After this change, foo will be a raw nsIFoo*, which is a weak
reference, so this changes the meaning of the program.
Arguably, this is not an issue with auto, but with implicit
conversions. It is one of the reasons why implicit conversions are
evil. :-)
* |auto| itself is rarely what you want (unless you know the
underlying type is not copyable), you probably want |auto| for
references if you intend to modify the original value, or |const
auto| if you don't. A sufficiently smart compiler should be able
to figure out that it doesn't actually need to create a reference
under the hood if the type it's seeing is a built-in one. (clang
seems to be able to do this based on a quick test.)
* If you find yourself typing the type once in the statement
already, use |auto|. Example:
auto ptr = static_castClass*(foo);
* Do not use auto for functions that can return different types that
have the same interface, as it obscures away the operation performed
on the type. Example:
class Container {
// ...
// Assume that the below iterator types map closely to the STL
concepts
iterator foo(int x);
reverse_iterator foo(string y);
};
Container c;
auto it = c.foo(str); // What kind of iterator do I have?!
* Do use auto for situations where the type doesn't really matter.
For example, if you have code like below:
foo(bar());
And want to put the call to |bar| into its own statements, and do
not care what the return type is, use auto:
const auto result = bar();
foo(result);
(Of course, depending on the nature of |foo| and |bar|, not all code
that looks like this should be refactored this way.)
* Do not use auto outside of a local scope. This helps restrict the
implications of auto to a hopefully smaller amount of code.
* Do not overuse auto. Consider auto as a handy tool that prevents
you from typing needlessly. But if you have code which uses auto
all over the place, you're *probably* doing it wrong.
* Remember that at the end of the day, code is read way more often
than it is written. If in doubt, opt for keeping the code more
readable by typing in what you mean, IOW, don't use auto when in doubt.
I want to add one case, which is when receiving some plain integers from
some kinds of functions, and doing computation based on them. For example:
nsTArraynsString array;
auto length = array.Length();
In this
Re: c++ unit test in content process
On 10/03/2014 08:59 AM, Benjamin Smedberg wrote: On 10/3/2014 9:46 AM, Patrick Wang wrote: The test I am writing is to test an implementation of WebRTC's TCP socket in content process. These codes are build on top of TCPSocket's IPDL in C++ and don't have IDL so it cannot be called directly from JS, and the tests for chrome process version are written with gtest. Therefore I am thinking of writing a similar one with gtest but run in content process. Does the unit of code you're testing include two processes communicating via IPDL? If so, I think you're going to need something more than a C++ unit test, and should probably focus your efforts on a more end-to-end integration test. Setting up IPDL connections and all of the machinery that goes with that doesn't sounds like something we should be trying in low-level unit tests. I agree. This was hard for me to accept when I first started working on the JS engine. It seemed like there should be more C++ unit tests. And maybe if there were, we'd have a better, less spaghetti-coupled design at that level. But as it stands, both in the JS engine and in Gecko generally, the dependencies are such that bootstrapping one subsystem usually amounts to firing up the whole thing. Mocking the rest of the browser is a long hard road. The good news is, using integration test frameworks to test unit functionality works astonishingly, deplorably well in Gecko. A mochitest often lets you target the exact code you wish to test using a tiny amount of HTML and JS. And it isolates your test from all sorts of future C++-level API churn. That said, if you see ways to improve the situation, go strong. The reason we have tests and a testing culture here at all is herculean efforts from Rob Sayre and others who saw what needed doing and did it. -j ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using c++11 right angle bracket in template code?
Trevor Saunders wrote: for (auto l = tarray.Length() - 1; l tarray.Length(); l--) Which is how you'd iterate backwards over a non empty array. for (auto l = tarray.Length(); l-- 0; ) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: c++ unit test in content process
And as “bad” as it is, it’s as good as it gets, and it will only get worse - unless we continue the efforts to make things better. Sometimes it’s a long haul, and you can’t get the approval to spend a lot of time digging out of some places, but often even small things help. -- - Milan On Oct 6, 2014, at 11:21 , Jason Orendorff jorendo...@mozilla.com wrote: On 10/03/2014 08:59 AM, Benjamin Smedberg wrote: On 10/3/2014 9:46 AM, Patrick Wang wrote: The test I am writing is to test an implementation of WebRTC's TCP socket in content process. These codes are build on top of TCPSocket's IPDL in C++ and don't have IDL so it cannot be called directly from JS, and the tests for chrome process version are written with gtest. Therefore I am thinking of writing a similar one with gtest but run in content process. Does the unit of code you're testing include two processes communicating via IPDL? If so, I think you're going to need something more than a C++ unit test, and should probably focus your efforts on a more end-to-end integration test. Setting up IPDL connections and all of the machinery that goes with that doesn't sounds like something we should be trying in low-level unit tests. I agree. This was hard for me to accept when I first started working on the JS engine. It seemed like there should be more C++ unit tests. And maybe if there were, we'd have a better, less spaghetti-coupled design at that level. But as it stands, both in the JS engine and in Gecko generally, the dependencies are such that bootstrapping one subsystem usually amounts to firing up the whole thing. Mocking the rest of the browser is a long hard road. The good news is, using integration test frameworks to test unit functionality works astonishingly, deplorably well in Gecko. A mochitest often lets you target the exact code you wish to test using a tiny amount of HTML and JS. And it isolates your test from all sorts of future C++-level API churn. That said, if you see ways to improve the situation, go strong. The reason we have tests and a testing culture here at all is herculean efforts from Rob Sayre and others who saw what needed doing and did it. -j ___ 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: c++ unit test in content process
On Mon, Oct 6, 2014 at 8:21 AM, Jason Orendorff jorendo...@mozilla.com wrote: That said, if you see ways to improve the situation, go strong. The reason we have tests and a testing culture here at all is herculean efforts from Rob Sayre and others who saw what needed doing and did it. srsly. That guy rocked. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Documenting uses of Github at Mozilla
Since all these repo links are likely to become unfindable in email... Contributions welcome: https://wiki.mozilla.org/Github Thanks, Tantek On Thu, Oct 2, 2014 at 12:46 PM, Mike Hoye mh...@mozilla.com wrote: On 2014-10-01 12:16 PM, Ehsan Akhgari wrote: On 2014-10-01, 11:59 AM, Ralph Giles wrote: On 2014-10-01 7:17 AM, Mike Hoye wrote: Having to scramble to recover from data loss - particularly around source or bug tracking - is a miserable experience we should try to avoid. Perhaps http://gitmirror.mozilla.org/ should be our project directory. That is a great idea! There's a proposal to decommission gitmirror.m.o. in https://bugzilla.mozilla.org/show_bug.cgi?id=910040 ... in favor of git.m.o for major projects. I've made the case there that instead, we should keep it as an automated index of tier-2 GitHub repos and cc'ed Ehsan and Ralph on it, for initiating this discussion and issuing the first pull request to the old updater script respectively. - mhoye ___ 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: c++ unit test in content process
I see. I'll try to write with a more end-to-end test framework then. Thank you. Patrick On 10/3/14 9:59 PM, Benjamin Smedberg wrote: On 10/3/2014 9:46 AM, Patrick Wang wrote: The test I am writing is to test an implementation of WebRTC's TCP socket in content process. These codes are build on top of TCPSocket's IPDL in C++ and don't have IDL so it cannot be called directly from JS, and the tests for chrome process version are written with gtest. Therefore I am thinking of writing a similar one with gtest but run in content process. Does the unit of code you're testing include two processes communicating via IPDL? If so, I think you're going to need something more than a C++ unit test, and should probably focus your efforts on a more end-to-end integration test. Setting up IPDL connections and all of the machinery that goes with that doesn't sounds like something we should be trying in low-level unit tests. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform smime.p7s Description: S/MIME Cryptographic Signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using c++11 right angle bracket in template code?
On 2014-10-06, 11:20 AM, Trevor Saunders wrote: Hence, I suggest for cases like this, |auto| should be a recommendation. IIRC, it is one of the cases that |auto| was introduced for. For cases like: for (int32_t i = 0; i array.Length(); i++) I even want to write it as for (decltype(array.Length()) i = 0; i array.Length(); i++) but I feel it too redundant. I hope C++ could support for (auto iend = array.Length(), i = 0; i iend; i++) but, unfortunately, it does not. Do you think this case reasonable? Your request is very reasonable, but as you note, it's not possible in C++. C++'s answer to this is ranged-based for loops http://en.wikipedia.org/wiki/C%2B%2B11#Range-based_for_loop which in my experience are *super* nice. They let you iterate over the array like this: I'll certainly grant they look nice, but I'm worried they obscure what happens in case of mutation, and we already have plenty of exploitable bugs about that. The usage of the iterator object which can also store state allows you to check for that exact pattern, so arguably you won't lose anything using range-based for loops if we added a good iterator implementation to nsTArray that checks for mutations. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On 2014-10-03 4:37 AM, Jonathan Kew wrote: it seems we fetch fonts using Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 which doesn't look even remotely sensible. Agree, but note that there are no official MIME types for most font formats. (I *think* application/font-woff did get registered for WOFF1.) Lots of people have just made up MIME types, including e.g. application/x-ttf, application/ttf, font/ttf (inventing a whole category!) and so on. I'm not aware of any significant changes in this area since I wrote https://www.owlfolio.org/htmletc/strawman-mime-type-for-fonts/ back in 2011. As described in that post, I continue to think that Accept: application/font plus client-side selection of URL based on format() is the Right Thing. I just filed bug 1077312. However, I don't think this needs to actually block the implementation of WOFF2 support. Also agree here. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On Mon, Oct 6, 2014 at 11:07 PM, Zack Weinberg za...@panix.com wrote: https://www.owlfolio.org/htmletc/strawman-mime-type-for-fonts/ back in 2011. I tried fixing this together with Håkon back in 2008: https://annevankesteren.nl/2008/08/font-mime-types We couldn't get agreement with the IETF fast enough so instead browsers ignore MIME types for fonts as Safari was already doing: http://www.alvestrand.no/pipermail/ietf-types/2008-August/002066.html It was all rather sad. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Why does nsWindowMediator have a lock?
As far as I can tell, nsWindowMediator::mListLock protects mOldestWindow and mTopmostWindow. However, the only direct users of nsWindowMediator are the enumerators in nsAppShellWindowEnumerator.cpp, and all uses of nsIWindowMediator that I could find appear to be in JS (ie. on the main thread) or don't look like C++ that runs off the main thread (nsPluginHost and ApplicationAccessible seem like the most likely candidates for that to be false). Am I missing something? It doesn't appear to be providing any benefit here. Cheers, Josh ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using c++11 right angle bracket in template code?
Ehsan Akhgari wrote: The usage of the iterator object which can also store state allows you to check for that exact pattern, so arguably you won't lose anything using range-based for loops if we added a good iterator implementation to nsTArray that checks for mutations. If you need to check for mutations then you should be using nsTObserverArray, which specifically supports iterators that are stable even if the array is modified during iteration. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Why does nsWindowMediator have a lock?
Josh Matthews wrote: As far as I can tell, nsWindowMediator::mListLock protects mOldestWindow and mTopmostWindow. However, the only direct users of nsWindowMediator are the enumerators in nsAppShellWindowEnumerator.cpp, and all uses of nsIWindowMediator that I could find appear to be in JS (ie. on the main thread) or don't look like C++ that runs off the main thread (nsPluginHost and ApplicationAccessible seem like the most likely candidates for that to be false). Am I missing something? It doesn't appear to be providing any benefit here. Seems to have been added by http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/xpfe/appshell/src/nsWindowMediator.cpprev=1.26 and not actually reviewed as such ;-) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
