Re: How does xpcshell unittest are runned
Error code 3, for me, always meant that I made a typo in head.js - or other JS files loaded other than the test file itself - that caused a SyntaxError. It’s unfortunate that there’s no better error reporting during loading and evaluation of JS while loading the harness, so I needed to resort to printf-debugging (`dump(“1.\n”); … dump(“2.\n”);` etc) to figure out where things went wrong. When I narrowed it down close enough, I wrapped the suspicious code in a try…catch block and dumped the exception message- and stack-properties. I hope this helps! Mike. On 11 Jul 2014, at 04:51, Yonggang Luo luoyongg...@gmail.com wrote: Thanks, I found the files, but when I running unittest, I have the error code 3 for all test cases. I'd like to know what's the possible reason to cause this. On 7/10/14, 6:54 PM, Yonggang Luo wrote: I found following code in `runxpcshelltests.py`: def buildXpcsRunArgs(self): Add arguments to run the test or make it interactive. if self.interactive: self.xpcsRunArgs = [ '-e', 'print(To start the test, type |_execute_test();|.);', '-i'] else: self.xpcsRunArgs = ['-e', '_execute_test(); quit(0);'] But I don't know where does _execute_test() comes from. testing/xpcshell/head.js is contains all the code for setting up and running each individual xpcshell test. _execute_test() lives in that file. https://hg.mozilla.org/mozilla-central/file/e1a037c085d1/testing/xpcshell/head.js#l375 ___ 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: How does xpcshell unittest are runned
This is the case on opt builds, but at least on tbpl, debug builds of xpcshell dump error information about why a file failed to load/run, e.g. https://tbpl.mozilla.org/php/getParsedLog.php?id=43053178tree=Mozilla-Esr24 ~ Gijs On 11/07/2014 09:12, Mike de Boer wrote: Error code 3, for me, always meant that I made a typo in head.js - or other JS files loaded other than the test file itself - that caused a SyntaxError. It’s unfortunate that there’s no better error reporting during loading and evaluation of JS while loading the harness, so I needed to resort to printf-debugging (`dump(“1.\n”); … dump(“2.\n”);` etc) to figure out where things went wrong. When I narrowed it down close enough, I wrapped the suspicious code in a try…catch block and dumped the exception message- and stack-properties. I hope this helps! Mike. On 11 Jul 2014, at 04:51, Yonggang Luo luoyongg...@gmail.com wrote: Thanks, I found the files, but when I running unittest, I have the error code 3 for all test cases. I'd like to know what's the possible reason to cause this. On 7/10/14, 6:54 PM, Yonggang Luo wrote: I found following code in `runxpcshelltests.py`: def buildXpcsRunArgs(self): Add arguments to run the test or make it interactive. if self.interactive: self.xpcsRunArgs = [ '-e', 'print(To start the test, type |_execute_test();|.);', '-i'] else: self.xpcsRunArgs = ['-e', '_execute_test(); quit(0);'] But I don't know where does _execute_test() comes from. testing/xpcshell/head.js is contains all the code for setting up and running each individual xpcshell test. _execute_test() lives in that file. https://hg.mozilla.org/mozilla-central/file/e1a037c085d1/testing/xpcshell/head.js#l375 ___ 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
.properties and a single \u
Hi, in .properties foo = some \unicode bar = some \a creates the most icky output. I'd like to get a defined behavior, but it turns out to be hard. Java: - dies with a parsing error on foo, bar is some a XPCOM: - returns some , as \u is converted to \0 on foo, bar is some a Gaia: - returns some \unicode, some \a (doesn't drop unknown escapes apparently) Compare-locales: - dies with a python error on parsing in my code on foo, bar is some a My mental parser: - returns some unicode, some a I dislike both java and compare-locales, and I think that both gaia and xpcom don't work great. What's your take? Axel cross-posting to .platform for xpcom, .tools.l10n for gaia's l10n.js ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: the 'box-decoration-break' CSS property
As of 2014-07-08 support for the CSS property 'box-decoration-break' has been turn on by default in Nightly (sorry for being late in announcing that). It's been developed behind the preference layout.css.box-decoration-break.enabled. The plan is to enable it by default also on Aurora (32) to provide an upgrade path for an old prefixed property (-moz-background-inline-policy) which was removed. Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1006326 Link to standard: http://dev.w3.org/csswg/css-break/#break-decoration Chrome has shipped the prefixed property -webkit-box-decoration-break IE10 has -ms-box-decoration-break ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Try-based code coverage results
On Monday, July 7, 2014 4:44:50 PM UTC-7, Joshua Cranmer wrote: On 7/7/2014 5:25 PM, Jonathan Griffin wrote: Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1035464 for those that would like to follow along. Perhaps bug 890116 is a better measure of tracking. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist Hi Joshua-- I work on the Treeherder dev team. Would you be up for writing a few bugs against Treeherder on what you found? Here’s a link to do so: https://bugzilla.mozilla.org/enter_bug.cgi?product=Tree%20Management We definitely want to get things like this fixed. Also, please feel free to ping us on the #treeherder channel on irc and we can work with you on issues that might block your progress. Thanks! -Cam ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Try-based code coverage results
On Friday, July 11, 2014 3:59:41 PM UTC-7, cda...@mozilla.com wrote: On Monday, July 7, 2014 4:44:50 PM UTC-7, Joshua Cranmer wrote: On 7/7/2014 5:25 PM, Jonathan Griffin wrote: Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1035464 for those that would like to follow along. Perhaps bug 890116 is a better measure of tracking. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist Hi Joshua-- I work on the Treeherder dev team. Would you be up for writing a few bugs against Treeherder on what you found? Here’s a link to do so: https://bugzilla.mozilla.org/enter_bug.cgi?product=Tree%20Management We definitely want to get things like this fixed. Also, please feel free to ping us on the #treeherder channel on irc and we can work with you on issues that might block your progress. Thanks! -Cam Hi Joshua-- Actually I see the bug wrt the M-e10s jobs all looking the same. I wrote up https://bugzilla.mozilla.org/show_bug.cgi?id=1037719 and should have a fix for that by Monday. -Cam ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
