Re: Proposal to change the semantics of DONTBUILD
On Tuesday 2013-01-15 13:20 -0800, Gregory Szorc wrote: This seems to make sense. My only concern is if there is a scenario where you absolutely need to push without incurring a build (think merge commit where you don't have control over the previous commits). I'm not sure why we'd do that, so I'm inclined to believe that such a scenario does not exist. I haven't heard of an absolutely need to not build scenario. We sometimes do extra builds for various reasons. The point of DONTBUILD is to save resources; occasionally failing to save resources when we could have done so is much less of a problem than not doing things that we really need to do. So Ehsan's proposal sounds great. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Enumerated values and locales in telemetry
On Mon, Dec 26, 2011 at 12:54 PM, Brian Smith bsm...@mozilla.com wrote: Henri Sivonen wrote: I suspect some of our localizations have inappropriate defaults for the fallback character encoding. On the conceptual level, telemetry could be used to discover a) how often pages end up relying on the fallback character encoding b) what the fallback encoding is in those cases (i.e. has the user changed it and to what) c) how often users override the character encoding on a per-page basis It turns out there are two problems here: 1) Telemetry doesn't seem to have nice ready-made tools for dealing with enumerations 2) These metrics would only make sense to measure on a per-localization basis and there doesn't appear to be a way to do this Regarding privacy, would we even want to include these two pieces of information in the telemetry data?: * what the fallback encoding was and/or what it was changed to * what the locale was How do you suggest we answer the question: “Do we have the most successful encoding defaults for all our localizations?” This is the kind of data that, in combination with other such data, would seem to cause trouble along the same lines as the Netflix Prize [1]. For example, if the locale is Romanian, then you have reduced the search space for an individual from 7,000,000,000 to 25,000,000. Let's say the platform is Android. Then, you've probably narrowed the search space down to less than 1,000 people. With just these two factors, you aren't far from isolating individual users from their telemetry data, even before you combine it with other factors. At least in theory, this could be cross-referenced with other datasets, such as Romanian-language tweets sent from the Twitter for Android app at times close to the times the Telemetry data was sent, to identify telemetry-providing users by name with a high degree of accuracy. Do I understand correctly that the problem is that even if we stored the locale-related telemetry data separately from other telemetry data and threw out IP address and time stamp right away, we couldn’t prove that to users? Actual ability to correlate the data could be removed by discarding the originating IP address, the exact time and the association with other telemetry data, right? On Mon, Dec 26, 2011 at 7:30 PM, Doug Turner doug.tur...@gmail.com wrote: Brian, you are right. Sid's teams should audit these closely. Our privacy policy says: Beginning with version 7, Firefox includes functionality that is turned off by default to send to Mozilla non-personal usage, performance, and responsiveness statistics about user interface features, memory, and hardware configuration. The data I’m interested in would fall under “user interface features” first and “performance” second. I'd like to have answers to these questions, and I think telemetry might be able to provide the answers: 1) Do we have the most successful encoding defaults for our locales? The reason I want to know: by inspection, I suspect that the locales turned up by the search http://mxr.mozilla.org/l10n-central/search?string=charset.default\s*%3D\s*UTF-8regexp=1find=\.properties%24findi=filter=^[^\0]*%24hitlimit=tree=l10n-central have inappropriate defaults, because the default encoding exists for misauthored legacy content that predates UTF-8. Inappropriate defaults may lead to user frustration or choosing another browser over Firefox. 2) Instead of having locale-specific defaults, could we decide the fallback encoding based on the top-level domain name of the site? The reason I want to know: Currently, the Web-exposed behavior of Firefox depends on the localization. It's bad that the way sites work depends on the UI language of the browser. In principle, you should be able to read e.g. Russian-language sites as successfully with e.g. Estonian-language Firefox then with a Russian-language Firefox. 3) Could we use a pan-Chinese encoding detector? Currently, it appears that our zh-TW localization turns on the universal detector. The universal detector has various problems (it isn't actually universal), so if the use case is that Taiwanese users often read both Traditional Chinese and Simplified Chinese legacy content while also reading some English content, maybe a detector that doesn't try to detect stuff as Cyrillic encodings could be more successful and perform faster. 4) Do users actually use the Character Encoding menu enough to warrant keeping that UI around? Can we get rid of the menu already? Reasons why it would be nice to get rid of the menu: * We shouldn't be signaling to Web authors that they have the option to leave this problem to users instead of getting their authoring act together. * Less opportunity for users to introduce data corruption by using the menu and then submitting a form. * Less code complexity. * Less code to maintain and fix. (I just wrote a fix in this area. Even though the code changes weren't that
xulrunner 17.0.1 application has issues on shutdown
Dear All,
I ported a rather large xulrunner 1.9.2 based application to xulrunner 17.0.1.
So far, most of all functionality still works.
I use both JS and C++ xpcoms, initiated via JS and defined within
chrome.manifest. I can use those xpcoms, no issues at all.
However, on shutdown, the thing breaks badly. I can see from debugging, that
non of the destructors within the C++ xpcoms get called. I get a free()
corruption somewhere near one xpcom and near xpcomglue - if I can trust the
stack trace from VS2010.
For shutdown, I use:
function closeImmediate() {
var appStartup = Components.classes['@mozilla.org/toolkit/app-startup;1'].
getService(Components.interfaces.nsIAppStartup);
// eAttemptQuit will try to close each XUL window, but the XUL window can
cancel the quit
// process if there is unsaved data. eForceQuit will quit no matter what.
var quitSeverity = Components.interfaces.nsIAppStartup.eForceQuit;
appStartup.quit(quitSeverity);
}
If I call closeImmediate() immediately after application startup (e.g. no xpcom
interaction yet), it crashes too.
I scanned lots of groups and couldn't find any info on how the shutdown from
within JS should be done nowaydays.
Any input appreciated.
Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Alternative to math.h for pow() and other elementary functions?
Do we have any alternative to math.h when you need pow() or other such elementary functions? Normally I am Mr. We Should Use The Standard Library, but math.h in particular tends to have weird shit in it that causes conflicts with xpcom headers, surprising behavior when everything isn't a 'double', etc. I unfortunately don't remember the details, but nsCSSScanner.cpp has workarounds for these problems and I do remember that I tried to take them out once and the build blew up on Windows. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Alternative to math.h for pow() and other elementary functions?
For starters, the standard C++ cmath library is already much better. You get an overloaded/templatized pow(x,y) that does the right thing, instead of pow()-only-for-double / powf()-only-for-float. http://en.cppreference.com/w/cpp/numeric/math/pow Benoit 2013/1/16 Zack Weinberg za...@panix.com Do we have any alternative to math.h when you need pow() or other such elementary functions? Normally I am Mr. We Should Use The Standard Library, but math.h in particular tends to have weird shit in it that causes conflicts with xpcom headers, surprising behavior when everything isn't a 'double', etc. I unfortunately don't remember the details, but nsCSSScanner.cpp has workarounds for these problems and I do remember that I tried to take them out once and the build blew up on Windows. zw __**_ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/**listinfo/dev-platformhttps://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Alternative to math.h for pow() and other elementary functions?
On 2013-01-16 2:38 PM, Benoit Jacob wrote: For starters, the standard C++ cmath library is already much better. I was under the impression that the cwhatever headers could not be used in Mozilla code. Is that no longer the case? I also expect that cmath should contain at least as much weird shit as the corresponding math.h, since as far as I know no OS vendor has ever actually succeeded in making the cwhatever headers define only symbols in namespace std. Thus it would not help with my particular problem. However, the math headers are a bit of a special snowflake and I could *imagine* cmath not being as troublesome as math.h. Does anyone know for sure? zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: region of zeroes in Gecko address space
Mike Hommey wrote: On Tue, Jan 15, 2013 at 03:19:42PM +, Neil wrote: Out of interest, where is that set? For mozjemalloc (current default): http://hg.mozilla.org/mozilla-central/file/b695e94363b5/memory/mozjemalloc/jemalloc.c#l547 Indeed, I don't know why I didn't spot it there. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Alternative to math.h for pow() and other elementary functions?
2013/1/16 Zack Weinberg za...@panix.com On 2013-01-16 2:38 PM, Benoit Jacob wrote: For starters, the standard C++ cmath library is already much better. I was under the impression that the cwhatever headers could not be used in Mozilla code. Is that no longer the case? Really? I've been using them in all my Mozilla code for 3 years now and never had a reviewer complain about that. What would be the rationale for allowing foo.h and disallowing cfoo anyway? I also expect that cmath should contain at least as much weird shit as the corresponding math.h, since as far as I know no OS vendor has ever actually succeeded in making the cwhatever headers define only symbols in namespace std. Thus it would not help with my particular problem. However, the math headers are a bit of a special snowflake and I could *imagine* cmath not being as troublesome as math.h. Does anyone know for sure? I was only addressing the surprising behavior when everything isn't a 'double' part of your email. Clearly, cmath typically #includes math.h so you get the same things from it, and more. At least here on GCC 4.6 / linux, cmath #includes math.h. That said, I have been including it in code that also includes XPCOM, without trouble. Benoit zw __**_ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/**listinfo/dev-platformhttps://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Update your Snappy status for Jan 17
Please share your Snappy status on the etherpad by EOD Thursday. https://etherpad.mozilla.org/snappy Thanks, Lawrence ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: fair well NS_IMPL_CYCLE_COLLECTION_CLASS()
Thanks for taking care of this! 2013/1/16 Trevor Saunders trev.saund...@gmail.com hi, a while ago I removed the need for NS_IMPL_CYCLE_COLLECTION_CLASS() and its friends NS_IMPL_CYCLE_COLLECTION_NATIVE_CLASS NS_IMPL_CYCLE_COLLECTION_LEGACY_NATIVE_CLASS andNS_IMPL_CYCLE_COLLECTION_SCRIPT_HOLDER_NATIVE_CLASS in bug 819215. I'm now removing the macros alltogether in bug 822289. enjoy your slightly less macroful life :) Trev ___ 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
