Re: Introducing mozilla::Abs to mfbt, replacing std::abs
Mozilla used to use NS_ABS to compute absolute values, but half a year ago we switched to std::abs. Unfortunately, practical experience with std::abs has pointed out various issues with it: the various overloads are confusingly split across multiple headers, std::abs(int64_t) doesn't always work, and std::abs doesn't work with INT32_MIN, INT64_MIN, and so on. For these reasons we recently introduced mozilla::Abs, in mozilla/MathAlgorithms.h, to mfbt. Going forward, you should use that function, not abs or std::abs, to compute absolute values. Slightly more detail is here if you want it: http://whereswalden.com/2013/04/30/introducing-mozillaabs-to-mfbt/ What about all the abs() calls in imported libraries? I assume leave them unless there's a demonstrated problem? -- 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: Standalone GTests
On 05/08/2013 08:06 PM, Benoit Girard wrote: I personally have a strong preference for keeping tests, particularly unit tests, running fast. My workflow is to develop new code by testing it via unit tests so longer turn around times slow down my development workflow. Sadly we don't have a good a way with dealing with slow but efficient tests and they end up making it difficult to test locally. But this isn't a reason to reject a useful test so feel free to check it in. Perhaps we should consider introducing a concept of smoke tests for developers to run locally where we can aim to maintain a good trade off between code coverage and turn around times. But that's orthogonal to your request. I think splitting GTest into a separate test job should be a prerequisite to not slow down the build job significantly which AIUI reduces test turn around times by delaying all test jobs from starting. Test jobs are kicked off before 'make check' starts. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MozillaBuild 1.7 Release
I am pleased to announce that (thanks to work by Ted) MozillaBuild 1.7 is available at http://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32/MozillaBuildSetup-Latest.exe This release contains: - Support for the 8.0 SDK with MSVC 2010 - Mercurial 2.5.4 - Python 2.7.4 - NSIS 2.22 has been removed. To upgrade, 1. Remove your current mozillabuild installation. (If you can't remove the existing installation, you probably have a Mozillabuild terminal open or ssh-agent running. Terminate it and try again). 2. Install MozillaBuild 1.7. 3. Clobber (remove the object directory of) any trees you have. (If you don't do this you'll get weird build errors). Please file any problems you come across in mozilla.org::MozillaBuild. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozillaBuild 1.7 Release
On 5/9/2013 11:15 AM, Kyle Huey wrote: I am pleased to announce that (thanks to work by Ted) MozillaBuild 1.7 is available at http://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32/MozillaBuildSetup-Latest.exe This release contains: - Support for the 8.0 SDK with MSVC 2010 - Mercurial 2.5.4 - Python 2.7.4 - NSIS 2.22 has been removed. To upgrade, 1. Remove your current mozillabuild installation. (If you can't remove the existing installation, you probably have a Mozillabuild terminal open or ssh-agent running. Terminate it and try again). 2. Install MozillaBuild 1.7. 3. Clobber (remove the object directory of) any trees you have. (If you don't do this you'll get weird build errors). Please file any problems you come across in mozilla.org::MozillaBuild. - Kyle Note the information on the wiki about how to handle hg phases on Try with the updated version of Mercurial. https://wiki.mozilla.org/ReleaseEngineering/TryServer#hg_phases ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozillaBuild 1.7 Release
On 5/9/2013 10:00 AM, Gregory Szorc wrote: MozillaBuild was AFAIK the last thing holding us back from requiring Python 2.7.3 to build the tree. So, I filed bug 870420 to up the build requirements from 2.7.0+ to 2.7.3+. For the unaware, 2.7.3 fixes a whole host of small bugs that we constantly have to work around. I'd rather we just bump the version requirement than continue to toil with workarounds to fixed Python bugs. ++ Get everything to python 2.7.3! -- Clint ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Storage in Gecko
Gregory Szorc schrieb: Perhaps this should be advertised more, especially to the add-on community. Looking at about:config of my main profile, about 2/3 of my preferences are user set. There are hundreds of preferences apparently being used for key-value storage by add-ons (not to pick on one, but HTTPS Everywhere has a few hundred prefs). FWIW, we had a pretty high-ranking topcrash in https://bugzilla.mozilla.org/show_bug.cgi?id=836263 where an add-on stored strings up to at least 128MB in prefs, and Nightly now limits prefs to 1MB max, and that add-on switched to indexedDB instead. This should happen more, for sure. I'd think that anything larger than a few KB probably doesn't belong in a pref. We couldn't easily set that limit mentioned above as low as we'd like because up to now we had no limit at all and some add-ons definitely store large stuff in prefs. Given that we probably read prefs in startup and before we can do anything useful with the launched Firefox, I wonder how much of a perf problem those large prefs tend to be, actually. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: We should drop MathML
Even Raymond Chen wants better MathML support? http://blogs.msdn.com/b/oldnewthing/archive/2013/05/08/10416823.aspx#comments ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
