Re: User-facing benefits from UA exposure of Android version and Linux CPU architecture
On Thu, Feb 18, 2021 at 01:51:07PM +0200, Henri Sivonen wrote: > Does reporting "Linux aarch64" have significant concrete benefits to > users? Would actual presently-existing app download pages break if, > for privacy, we always reported "Linux x86_64" on Linux regardless of > the actual CPU architecture (or reported it on anything but 32-bit > x86)? Would not exposing the CPU architecture be an option? Are UA sniffers expecting the UA format to include the CPU architecture? Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: FTP protocol implementation
On Wed, Feb 10, 2021 at 11:00:14AM +0100, Valentin Gosu wrote: > On Wed, 10 Feb 2021 at 09:57, Mike Hommey wrote: > > > On Wed, Feb 10, 2021 at 10:45:53AM +0200, Henri Sivonen wrote: > > > On Wed, Feb 10, 2021 at 10:37 AM Valentin Gosu > > wrote: > > > > FTP support is currently disabled on Nightly. > > > > Our current plan is for the pref flip to ride the trains with Firefox > > 88 to > > > > beta and release [1], meaning we would be disabling FTP a week after > > Chrome > > > > [2] > > > > > > Are we also stopping advertising the capability to act as an ftp: URL > > > handler to operating systems? Currently, if I try to follow an ftp: > > > URL in Gnome Terminal, it tries to launch Firefox. Is that something > > > we advertise to Gnome or something that Gnome just knows and needs to > > > be patched to stop knowing? > > > > I /think/ this comes from the .desktop file, which in most cases, comes > > from the distro. > > > > We have this bug on file: > https://bugzilla.mozilla.org/show_bug.cgi?id=1667468 > We should definitely stop registering Firefox as an ftp handler. Oh right, the external protocol service also registers. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: FTP protocol implementation
On Wed, Feb 10, 2021 at 10:45:53AM +0200, Henri Sivonen wrote: > On Wed, Feb 10, 2021 at 10:37 AM Valentin Gosu > wrote: > > FTP support is currently disabled on Nightly. > > Our current plan is for the pref flip to ride the trains with Firefox 88 to > > beta and release [1], meaning we would be disabling FTP a week after Chrome > > [2] > > Are we also stopping advertising the capability to act as an ftp: URL > handler to operating systems? Currently, if I try to follow an ftp: > URL in Gnome Terminal, it tries to launch Firefox. Is that something > we advertise to Gnome or something that Gnome just knows and needs to > be patched to stop knowing? I /think/ this comes from the .desktop file, which in most cases, comes from the distro. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: Experimental support for auto-updating the tools mach bootstrap installs
Hi, mozilla-central now has a new experimental configure option that will automatically upgrade the tools mach bootstrap installed. You can use it with ac_add_options --enable-bootstrap Please give it a try, and report any problems you encounter on https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox+Build+System&component=General or #build:mozilla.org on Element. The feature is expected to eventually also cover installation, but for now, it only covers what has already been installed once. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA (Windows): Startup Skeleton UI Enabled on Nightly
On Wed, Jan 06, 2021 at 01:46:52PM -0800, Doug Thayer wrote: > On 1/6/2021 1:44 PM, Mike Hommey wrote: > > > On Wed, Jan 06, 2021 at 01:30:00PM -0800, Doug Thayer wrote: > > > On Wed, Jan 6, 2021 at 1:23 PM Mike Hommey wrote: > > > > > > > On Wed, Jan 06, 2021 at 11:57:18AM -0800, Doug Thayer wrote: > > > > > If you don't spend any time on Nightly in Windows 10, please feel > > > > > free to > > > > > disregard this. > > > > > > > > > > tl;dr: we're sometimes creating the first window differently than > > > > > usual, > > > > so > > > > > be on the lookout for breakages. > > > > > > > > > > On 2021-01-05, a change landed in Nightly which enabled the pre-XUL > > > > skeleton > > > > > UI [1]. This is a feature which allows us to create the first window > > > > > and > > > > > populate it with a non-interactive placeholder UI before we load > > > > xul.dll. On > > > > > some systems, this can mean we can give visual indication of Firefox > > > > > launching as much as 15 seconds sooner than normal (loading xul.dll > > > > > can > > > > take > > > > > a while). We're hoping this could be a big win for users who > > > > > experience > > > > very > > > > > slow startups, and we also hope it will improve the overall > > > > > snappiness of > > > > > startup even on fast systems. > > > > What does the placeholder UI look like? > > > > > > > Colors and layout can vary, but the basic look is this: > > > [image: image.png] > > The image attachment didn't quite work. > > Woops. Here is a link: https://i.imgur.com/R4ynXW5.png Does the placement and the size of that window vary? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA (Windows): Startup Skeleton UI Enabled on Nightly
On Wed, Jan 06, 2021 at 01:30:00PM -0800, Doug Thayer wrote: > On Wed, Jan 6, 2021 at 1:23 PM Mike Hommey wrote: > > > On Wed, Jan 06, 2021 at 11:57:18AM -0800, Doug Thayer wrote: > > > If you don't spend any time on Nightly in Windows 10, please feel free to > > > disregard this. > > > > > > tl;dr: we're sometimes creating the first window differently than usual, > > so > > > be on the lookout for breakages. > > > > > > On 2021-01-05, a change landed in Nightly which enabled the pre-XUL > > skeleton > > > UI [1]. This is a feature which allows us to create the first window and > > > populate it with a non-interactive placeholder UI before we load > > xul.dll. On > > > some systems, this can mean we can give visual indication of Firefox > > > launching as much as 15 seconds sooner than normal (loading xul.dll can > > take > > > a while). We're hoping this could be a big win for users who experience > > very > > > slow startups, and we also hope it will improve the overall snappiness of > > > startup even on fast systems. > > > > What does the placeholder UI look like? > > > > Colors and layout can vary, but the basic look is this: > [image: image.png] The image attachment didn't quite work. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA (Windows): Startup Skeleton UI Enabled on Nightly
On Wed, Jan 06, 2021 at 11:57:18AM -0800, Doug Thayer wrote: > If you don't spend any time on Nightly in Windows 10, please feel free to > disregard this. > > tl;dr: we're sometimes creating the first window differently than usual, so > be on the lookout for breakages. > > On 2021-01-05, a change landed in Nightly which enabled the pre-XUL skeleton > UI [1]. This is a feature which allows us to create the first window and > populate it with a non-interactive placeholder UI before we load xul.dll. On > some systems, this can mean we can give visual indication of Firefox > launching as much as 15 seconds sooner than normal (loading xul.dll can take > a while). We're hoping this could be a big win for users who experience very > slow startups, and we also hope it will improve the overall snappiness of > startup even on fast systems. What does the placeholder UI look like? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Building for macos now requires at least macos 10.12 SDK
Hi, Automation was recently updated to use the 10.12 SDK, because it turns out it had been a while we haven't supported running Firefox on macos 10.11 and earlier (support dropped in bug 1634765, SDK updated in bug 1680152). As usual in those cases, but quicker than usual, something else landed that made the 10.12 SDK implicitly required, by using an API new to 10.12 (bug 1678174). The error message when building with the 10.11 SDK looks like: "error: use of undeclared identifier 'CLOCK_REALTIME'" It's only fair not to maintain code that users would never use in practice just to keep things building with the older SDK, so we're going to deprecate building with the 10.11 SDK. If you've been using that SDK, you can remove the --with-macos-sdk line from your mozconfig (or however other config you used) and use whatever SDK you have with Xcode or the Command Line Tools (the build should pick one on its own by default). There used to be problems with SDKs 10.13 or 10.14 and newer, but those are long gone. We're now even shipping builds for arm64 based on the very latest 11.0 SDK. Only in rare occasions would I expect the SDK version used in local builds to matter, but if it does matter for your use-cases, you'll unfortunately have to get the 10.12 SDK by your own means, from e.g. Xcode 8.3.3. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Adopting the black Python code style
Is black still opiniated about string types and insisting to use double quotes, when we mostly settled on single quotes? On Mon, Oct 12, 2020 at 10:00:56AM -0700, Ricky Stewart wrote: > Hello everyone, > > If you don't write Python code in mozilla-central, you can stop reading now. > > On October 19, 2020 we will be officially adopting the black Python style for > all our Python code in mozilla-central. > > black (https://black.readthedocs.io/en/stable/) is an opinionated, fast, and > correct auto-formatter for Python. It is an increasingly popular > autoformatter which might be considered the de facto standard for Python code > (like clang-format and jslint are for C++ and JS). It is already used by > several Mozilla projects, including Release Engineering, Lando, and moz-phab. > > black makes it easy for us to reliably format all our Python code in a > consistent way, making the codebase easier to read on the whole and allowing > us to spend more time in code review discussing substantive issues over > trivial formatting matters. > > This policy change will affect all Python code in-tree, including sandboxed > Python code used by the build system (.configure, .build, and .mozbuild > files). > > As part of this policy change, we plan on doing a one-time auto-reformat on > October 19 of all Python code in the entire repository. In addition, mach > lint > (https://firefox-source-docs.mozilla.org/code-quality/lint/linters/black.html) > and reviewbot will be updated to print warnings for Python source files that > violate the black style. Just like with C/C++ or Rust, we won’t backout > offending changes but instead will do regular refreshes of the tree. > > If there are any questions, please let me know! > > Ricky > ___ > 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
PSA: js_options is no more
Hi, If you've written patches for configure in the past few years to add some flag to use in mozconfig with `ac_add_options`, you may have seen that while in most cases, you may do that with `option()`, in some cases, for weird reasons, you had to use `js_option()`. That's finally not the case anymore. If you have patches pending that are using `js_option()`, they will fail. You just need to replace it with `option()`. The downside, though, is that these patches may cause subtle problems if they are uplifted, so if you can avoid uplifting patches adding `option()` for a few cycles, that would be better (though a quick look at the history of the beta branch suggests no such patch has ever been uplifted so far). The underlying reason why it is finally this way is that when running configure for Firefox, we now don't run configure again for Spidermonkey. At least not for the python parts of configure. Hopefully, this makes configure a little faster. The autoconf parts, however, are still executed. For the curious, the bugs involved are #1669633 and #1520395. Cheers, Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutting down legacy Taskcluster deployment
On Fri, Jun 26, 2020 at 08:04:01PM +, Tom Ritter wrote: > On Fri, Jun 26, 2020 at 7:34 PM Andrew Halberstadt wrote: > > > > On Fri, Jun 26, 2020 at 3:14 PM Jeff Muizelaar > > wrote: > >> > >> What percentage of the space used for artifacts is actually builds > >> that are used for mozregression vs other stuff (like debug builds)? Is > >> there a way that we could somehow have different expiraries for the > >> different kinds of data? 1 year for logs, debug symbols and debug > >> builds seems very generous but 8 months for builds for mozregression > >> seems stingy. > > > > > > Keep in mind this is only temporary, with every passing day we approach a > > full year's worth of builds again. As a longer term solution to this > > particular problem, I wonder if we can get mozregression to farm out > > missing builds on try.. then there would be no limit to how far back it > > could go. > > I think that would be difficult. While taskcluster specifiesthe > toolchain configuration, I think changes to TC infrastructure mean > that old trees do not easily run there. (I think worker-types > disappear for example.) And locally, your toolchain can be too new to > build an old version of Firefox - I've had to switch back to older > versions of rust a few times in particular. Heck, we need to land patches to the esr68 branch for taskcluster infra changes. As a matter of fact, anything that predates the switch to the new infra won't work on try. I'm sure there are other changes that happened since the switch that require newer code from mozilla-central (ISTR there were gecko-decision task failures just a few weeks ago that needed newer m-c) Now, to come back on the longer term solution, the only thing I can think of would be to publish all the shippable builds from taskcluster to the "FTP" server. Because there's no saying the taskcluster infra won't migrate again in x years and we'd have the same problem as now. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Is --disable-libjpeg-turbo gone?
On Sat, May 16, 2020 at 09:26:30AM +0900, ISHIKAWA,chiaki wrote: > On 2020/05/16 7:51, Mike Hommey wrote: > > On Sat, May 16, 2020 at 07:24:44AM +0900, ISHIKAWA,chiaki wrote: > > > I have --disable-libjpeg-turbo in my mozconfig for many years (I build TB > > > locally). > > > > > > After an update of the local source tree this morning, it is no longer > > > recognized? > > > (The last update was several days ago.) > > > > > > Has anyone also experienced this? > > > > > > Traceback (most recent call last): > > > File "/NEW-SSD/NREF-COMM-CENTRAL/mozilla/configure.py", line 181, in > > > > > > sys.exit(main(sys.argv)) > > > File "/NEW-SSD/NREF-COMM-CENTRAL/mozilla/configure.py", line 52, in > > > main > > > sandbox.run(os.path.join(os.path.dirname(__file__), 'moz.configure')) > > > File > > > "/NEW-SSD/NREF-COMM-CENTRAL/mozilla/python/mozbuild/mozbuild/configure/__init__.py", > > > line 494, in run > > > raise InvalidOptionError(msg) > > > mozbuild.configure.options.InvalidOptionError: Unknown option: > > > --disable-libjpeg-turbo > > > *** Fix above errors and then restart with\ > > > "./mach build" > > > make: *** [client.mk:115: configure] Error 1 > > I removed it in bug 1638195, but it hasn't done anything since bug > > 1515852. > > > > Mike > > > > > Thank you for the pointer. > > Does this mean I can safely remove --disable-libjpeg-turbo? Rule of thumb: clear up your mozconfig, chances are you don't need most of what it contains anymore if it's years old. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Is --disable-libjpeg-turbo gone?
On Sat, May 16, 2020 at 07:24:44AM +0900, ISHIKAWA,chiaki wrote: > I have --disable-libjpeg-turbo in my mozconfig for many years (I build TB > locally). > > After an update of the local source tree this morning, it is no longer > recognized? > (The last update was several days ago.) > > Has anyone also experienced this? > > Traceback (most recent call last): > File "/NEW-SSD/NREF-COMM-CENTRAL/mozilla/configure.py", line 181, in > > sys.exit(main(sys.argv)) > File "/NEW-SSD/NREF-COMM-CENTRAL/mozilla/configure.py", line 52, in main > sandbox.run(os.path.join(os.path.dirname(__file__), 'moz.configure')) > File > "/NEW-SSD/NREF-COMM-CENTRAL/mozilla/python/mozbuild/mozbuild/configure/__init__.py", > line 494, in run > raise InvalidOptionError(msg) > mozbuild.configure.options.InvalidOptionError: Unknown option: > --disable-libjpeg-turbo > *** Fix above errors and then restart with\ > "./mach build" > make: *** [client.mk:115: configure] Error 1 I removed it in bug 1638195, but it hasn't done anything since bug 1515852. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firefox Build Requirements - NASM
On Thu, May 14, 2020 at 06:28:36PM -0700, Thomas Daede wrote: > On 5/14/20 4:10 PM, Charles Robertson wrote: > > Is there a new build requirement for future Firefox 78 ESR on nasm-2.14.02? > > If so is this documented anywhere? > > It is a dependency for dav1d, our AV1 decoder. > > It looks like a bump of the dav1d version increased the minimum to 2.14. > This hasn't been detected on our build systems as we always have used > 2.14 (it was the most recent version when dav1d was added to the tree). > If you really have to, you can work around this by disabling AV1 support. There's an explicit check in https://searchfox.org/mozilla-central/rev/4166c15e2a99a23a9b38ad62c9fdfe8e5448b354/toolkit/moz.configure#472 (since 76) Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Testing Rust code in tree
On Mon, May 11, 2020 at 03:37:07PM -0700, Dave Townsend wrote: > Do we have any standard way to test in-tree Rust code? > > Context: We're building a standalone binary in Rust that in the future will > be distributed with Firefox and of course we want to test it. It lives > in-tree and while we could use something like xpcshell to drive the > produced executable and verify its effects it would be much nicer to be > able to use Rust tests themselves. But I don't see a standard way to do > that right now. > > Is there something, should we build something? https://searchfox.org/mozilla-central/rev/446160560bf32ebf4cb7c4e25d7386ee22667255/python/mozbuild/mozbuild/frontend/context.py#1393 Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Anyone using the mapfiles? (Was: PSA: Changes to Gecko/Firefox mirrors on github)
By the way, I forgot to add: With this change, mapping files ([1] and [2] for gecko-dev and gecko-projects respectively) are less necessary (because git-cinnabar can be used instead). 1. https://moz-vcssync.s3-us-west-2.amazonaws.com/mapping/gecko-dev/git-mapfile.tar.bz2 2. https://moz-vcssync.s3-us-west-2.amazonaws.com/mapping/gecko-projects/git-mapfile.tar.bz2 We are considering stopping the publication of those files in a month. Please come forward if you have a use for them and would like to keep them alive. Mike On Fri, Apr 17, 2020 at 10:55:35AM +0900, Mike Hommey wrote: > Hi, > > There are two officially supported mirrors of Gecko/Firefox on github: > - https://github.com/mozilla/gecko-dev/ for main branches, like > mozilla-central, mozilla-beta, etc. > - https://github.com/mozilla/gecko-projects/ for project branches, like > alder, ash, birch, etc. > > As of a couple hours ago, they are now updated with git-cinnabar[1] instead > of hg-git[2]. > > 1. https://github.com/glandium/git-cinnabar > 2. https://bitbucket.org/durin42/hg-git > > What does this mean? > > If you're using one of these repositories on their own, it means > nothing has changed for you. You'll get updates as usual, albeit maybe a > little earlier than before. > > If you're using a clone of gecko-dev to push to mercurial, per [3] or > previous instructions on using git-cinnabar with gecko-dev, that setup > will keep working. But it will also be possible to switch to a simpler > setup. Check out the updated instructions[4] in the coming days, after the > upcoming release of git-cinnabar 0.5.5. > > 3. > https://github.com/glandium/git-cinnabar/wiki/Mozilla:-Using-a-git-clone-of-gecko%E2%80%90dev-to-push-to-mercurial/1405a1da2b59892271a88c7dcc65a4f31b19e587 > 4. > https://github.com/glandium/git-cinnabar/wiki/Mozilla:-Using-a-git-clone-of-gecko%E2%80%90dev-to-push-to-mercurial > > Thanks to David House for the assistance during the migration. > > Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Changes to Gecko/Firefox mirrors on github
On Fri, Apr 17, 2020 at 11:18:06AM -0400, Kartikaya Gupta wrote: > Yay! Thanks for doing this. For posterity, do you happen to know the > first commit that was migrated with cinnabar? If you're asking the first ever: https://github.com/mozilla/gecko-dev/commit/ae8f8ae52f732a8c7a7938cc2bd39d0faf485bcd (that was on beta) If you're asking the first from mozilla-central: https://github.com/mozilla/gecko-dev/commit/8dcf22da549436327987e9ed49c4182688864fa2 Mike > On Thu, Apr 16, 2020 at 9:55 PM Mike Hommey wrote: > > > > Hi, > > > > There are two officially supported mirrors of Gecko/Firefox on github: > > - https://github.com/mozilla/gecko-dev/ for main branches, like > > mozilla-central, mozilla-beta, etc. > > - https://github.com/mozilla/gecko-projects/ for project branches, like > > alder, ash, birch, etc. > > > > As of a couple hours ago, they are now updated with git-cinnabar[1] instead > > of hg-git[2]. > > > > 1. https://github.com/glandium/git-cinnabar > > 2. https://bitbucket.org/durin42/hg-git > > > > What does this mean? > > > > If you're using one of these repositories on their own, it means > > nothing has changed for you. You'll get updates as usual, albeit maybe a > > little earlier than before. > > > > If you're using a clone of gecko-dev to push to mercurial, per [3] or > > previous instructions on using git-cinnabar with gecko-dev, that setup > > will keep working. But it will also be possible to switch to a simpler > > setup. Check out the updated instructions[4] in the coming days, after the > > upcoming release of git-cinnabar 0.5.5. > > > > 3. > > https://github.com/glandium/git-cinnabar/wiki/Mozilla:-Using-a-git-clone-of-gecko%E2%80%90dev-to-push-to-mercurial/1405a1da2b59892271a88c7dcc65a4f31b19e587 > > 4. > > https://github.com/glandium/git-cinnabar/wiki/Mozilla:-Using-a-git-clone-of-gecko%E2%80%90dev-to-push-to-mercurial > > > > Thanks to David House for the assistance during the migration. > > > > Mike > > ___ > > 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: Changes to Gecko/Firefox mirrors on github
Hi, There are two officially supported mirrors of Gecko/Firefox on github: - https://github.com/mozilla/gecko-dev/ for main branches, like mozilla-central, mozilla-beta, etc. - https://github.com/mozilla/gecko-projects/ for project branches, like alder, ash, birch, etc. As of a couple hours ago, they are now updated with git-cinnabar[1] instead of hg-git[2]. 1. https://github.com/glandium/git-cinnabar 2. https://bitbucket.org/durin42/hg-git What does this mean? If you're using one of these repositories on their own, it means nothing has changed for you. You'll get updates as usual, albeit maybe a little earlier than before. If you're using a clone of gecko-dev to push to mercurial, per [3] or previous instructions on using git-cinnabar with gecko-dev, that setup will keep working. But it will also be possible to switch to a simpler setup. Check out the updated instructions[4] in the coming days, after the upcoming release of git-cinnabar 0.5.5. 3. https://github.com/glandium/git-cinnabar/wiki/Mozilla:-Using-a-git-clone-of-gecko%E2%80%90dev-to-push-to-mercurial/1405a1da2b59892271a88c7dcc65a4f31b19e587 4. https://github.com/glandium/git-cinnabar/wiki/Mozilla:-Using-a-git-clone-of-gecko%E2%80%90dev-to-push-to-mercurial Thanks to David House for the assistance during the migration. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firefox Future Rust Requirements
On Thu, Mar 19, 2020 at 09:45:47PM +, Charles Robertson wrote: > Is there a calendar or somethings that shows future Firefox releases > Rust requirements? I would like to know what Rust version will Firefox > 78.0 ESR require when it is released? There is an outdated one on https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox that I will update in the coming days, and it looks like 78 will be using 1.43. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How to generate compatible firefox for all versions of linux system?
On Tue, Dec 10, 2019 at 10:54:39PM -0800, acnatar...@gmail.com wrote: > Hi all, > > I had built a firefox on ubuntu 16.04 with GCC 5.4.0 and Glibc 2.23 from > Mozilla-central. Exported the package using "./mach package". > > firefox version 72.0a1.en > > When I try to launch the exported firefox from another ubuntu machine with > same config ubuntu 16.04, GCC 5.4.0 I was getting an error > > > """ > XPCOMGlueLoad error for file /home/test/Documents/firefox/libxul.so: > /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.22' not found > (required by /home/test/Documents/firefox/libxul.so) > Couldn't load XPCOM > """ > > This requires me to upgrade GCC in that machine in order to launch the > browser without errors. > > I tried Firefox Nightly from Mozilla official releases works fine without > depending on the Glibc version. > > > What should I do to configure and build to make the exported firefox work on > other machines without upgrading the GCC version? You need to add `ac_add_options --enable-stdcxx-compat` to your mozconfig. It's not guaranteed to work in all cases, though (it's only tested in the build environment Mozilla uses for its builds) Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Must we rebuild all our rust code constantly?
On Thu, Aug 22, 2019 at 06:48:03PM -0700, Chris M. wrote: > On Mon, Aug 19, 2019 at 10:32 PM Kris Maglione > wrote: > > > On Tue, Aug 20, 2019 at 02:23:06PM +0900, ISHIKAWA,chiaki wrote: > > >On 2019/08/20 9:11, Dave Townsend wrote: > > >>Thanks to a tip I've tracked this down. This seems to only be the case > > when > > >>I have sccache enabled. Disabling it gives me nice quick incremental > > builds > > >>again. Of course that isn't an ideal solution but it will do for now. > > >> > > >>On Mon, Aug 19, 2019 at 1:55 PM Dave Townsend > > wrote: > > >> > > >>>For a couple of weeks now I've seen that any attempt to build Firefox, > > >>>even incremental builds seem to rebuild an awful lot of rust code. I > > found > > >>>this in the source which seems to suggest why: > > >>> > > https://searchfox.org/mozilla-central/source/config/makefiles/rust.mk#238. > > >>>But, this means that now an incremental build with a couple of code > > change > > >>>that have no impact on rust is taking upwards of 4 minutes to complete > > in > > >>>comparison to around 40 seconds, and the log file is full of cargo > > output. > > >>>I've heard similar comments from other developers. > > >>> > > >>>This is a pretty big increase in the time to compile and test and is > > >>>really slowing down my work. Is there any way we can avoid this? > > >>> > > >> > > > > > > > > >I am using linux for local development and noticed something similar. > > > > > >So I should disable sccache (!?). > > > > For what it's worth, Rust is now configured to use incremental > > compilation, which has its own cache which isn't cleared after > > clobber, so sccache isn't actually needed anymore. Ordinary > > ccache should be sufficient. > > > sccache will still cache dependencies from crates.io. From a quick check > building the rust in the tree on my laptop, a full cache hit for rust with > sccache produces a significant speedup (2x) versus incremental alone. I had a similar experience on a 36-core machine earlier today. It seems incremental is not working properly for the style crate: incremental is supposed to have the same effect as sccache, but it still takes a long time to compile style. I'm told mw is going to look into this in the coming weeks. In the meanwhile, as discussed on irc, it seems fair to disable CARGO_INCREMENTAL when building with sccache. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Watch out for build issues on non-Unicode systems
On Thu, Aug 22, 2019 at 02:42:48PM +0200, Nihanth Subramanya wrote: > Note that the config.status changes in bug 844509 seem to break `$./mach > clobber` - I had to manually rm -rf my objdir. Filed as bug 1575959, fixed on mozilla-central. Sorry for the annoyance. Mike > On Thu, Aug 22, 2019 at 2:35 AM Mike Hommey wrote: > > > Hi, > > > > In bug 1575135 and bug 844509, we've changed how configure handles > > strings from files and subprocesses, to normalize everything to Unicode. > > > > On systems where the system locale is based on UTF-8 (e.g. most Linux > > or macOS), this shouldn't make a difference. > > > > On systems where the system locale is not based on UTF-8, this might > > cause problems, so please watch out, especially on non-Latin Windows. > > > > I don't believe things would have regressed (things should be handled > > more or less similarly to before). I can think of a few things that > > could fail, but for that matter, those I have in mind would have failed > > before too. > > > > However, it is possible that a few corner cases that are not covered by > > automation lead to configure complaining about some key or values not > > being unicode strings. If that happens, please file bugs with your > > mozconfig and as much detail as possible. > > > > Cheers, > > > > Mike > > ___ > > 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
Watch out for build issues on non-Unicode systems
Hi, In bug 1575135 and bug 844509, we've changed how configure handles strings from files and subprocesses, to normalize everything to Unicode. On systems where the system locale is based on UTF-8 (e.g. most Linux or macOS), this shouldn't make a difference. On systems where the system locale is not based on UTF-8, this might cause problems, so please watch out, especially on non-Latin Windows. I don't believe things would have regressed (things should be handled more or less similarly to before). I can think of a few things that could fail, but for that matter, those I have in mind would have failed before too. However, it is possible that a few corner cases that are not covered by automation lead to configure complaining about some key or values not being unicode strings. If that happens, please file bugs with your mozconfig and as much detail as possible. Cheers, Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming C++ standards meeting in Cologne
On Tue, Jul 30, 2019 at 01:04:56PM -0400, Nathan Froyd wrote: > On Sat, Jul 27, 2019 at 1:42 PM Botond Ballo wrote: > > If you're interested in some more details about what happened at last > > week's meeting, my blog post about it is now available (also on > > Planet): > > > > https://botondballo.wordpress.com/2019/07/26/trip-report-c-standards-meeting-in-cologne-july-2019/ > > Thanks for writing this up. I always enjoy reading these reports. > > One grotty low-level question about the new exception proposal. Your > post states: > > "it was observed that since we need to revise the calling convention > as part of this proposal anyways, perhaps we could take the > opportunity to make other improvements to it as well, such as allowing > small objects to be passed in registers, the lack of which is a pretty > unfortunate performance problem today (certainly one we’ve run into at > Mozilla multiple times). That seems intriguing." > > How is revising the calling convention a C++ standards committee > issue? Doesn't that properly belong to the underlying platform (CPU > and/or OS)? ... and aren't small objects already passed via registers already? https://gcc.godbolt.org/z/VE009V Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firefox command seems to be a wrapper
On Tue, Jul 16, 2019 at 06:44:36AM +0430, Mahmood Naderan wrote: > OK I will try the source compilation. Please let me know if I have use > specific options for my purpose or not. I'm not sure how you jumped from my response to building from source, but what I'm saying is that you probably can run /usr/lib64/firefox/firefox. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firefox command seems to be a wrapper
On Tuesday, July 16, 2019 at 12:51:28 AM UTC+9, Mahmood Naderan wrote: > > Hi, > > I want to analyze firefox by tracing instruction footprints as I am > working with that. Problem is that when I pass /usr/bin/firefox (or simply > firefox) to the tracer, it stops logging as soon as the main window opens. > > As I looked further, I have noticed that another process is launched and > that is what I have to analyze. I also have noticed that /usr/bin/firefox > isn't present in the output of ps command. > > # ps aux | grep firefox > mahmood 8358 61.8 0.3 2679204 201348 pts/1 Sl+ 12:58 0:03 > /usr/lib64/firefox/firefox > mahmood 8494 20.0 0.1 2351288 69648 pts/1 Sl+ 12:58 0:00 > /usr/lib64/firefox/plugin-container -greomni /usr/lib64/firefox/omni.ja > -appomni /usr/lib64/firefox/browser/omni.ja -appdir > /usr/lib64/firefox/browser 8358 tab > root 8633 0.0 0.0 112664 972 pts/2S+ 12:58 0:00 grep > --color=auto firefox > > Ignoring the absence of /usr/bin/firefox, when I run > /usr/lib64/firefox/plugin-container -greomni /usr/lib64/firefox/omni.ja > -appomni /usr/lib64/firefox/browser/omni.ja -appdir > /usr/lib64/firefox/browser 8358 tab in the terminal, I get shared library > access error. > > Overall, firefox command is a wrapper and I am seeking for a way to access > the main firefox. I also tried > > export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib64/firefox > > but wasn't successful. Any idea? It looks like your Linux distro has set their own wrapper for Firefox. That's not something that comes from Firefox itself. So looking at your paths, this would suggest /usr/lib64/firefox/firefox is the real, non-wrapped, Firefox binary. As for whether you'd be losing anything by not using the wrapper, that's a question for your distro. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Coding style 🙄 : `int` vs `intX_t` vs `unsigned/uintX_t`
On Tue, Jul 09, 2019 at 10:39:37AM -0400, Ehsan Akhgari wrote: > On Mon, Jul 8, 2019 at 11:00 PM Gerald Squelart > wrote: > > > Thank you all for some very interesting discussions so far. > > > > Even if we don't take blanket steps to avoid unsigned types in > > non-bitfield/modulo cases (as suggested by our newly-adopted Google style), > > at least hopefully we're now aware of their subtleties, and we can be more > > careful and deliberate in our choice of integer types in our respective > > domains. > > > > Coming back to my original questions, I think the first part has not been > > categorically answered yet: > > > > Do we have style rules (or folklore) against naked `int`s/`unsigned`s, in > > favor of explicitly-sized `(u)intXX_t` everywhere? > > > > For new code, the style guide for this question can be found here: > https://google.github.io/styleguide/cppguide.html#Integer_Types. For > existing code, consistency with surrounding code should take precedence for > now. I hope this answers your question. I thought we only adopted the Google style guide for formatting. Does everything from the guide apply now? Or only parts of it? If the latter, which parts? I'm surprised because I don't remember having seen a mail about this, and surely, I should have noticed something that'd be saying that class member variables names would stop beginning with m, and would instead finish with an underscore and be all lowercase. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing --enable-shared-js [Was: Rust and --enable-shared-js]
On Tue, May 21, 2019 at 10:32:20PM -0400, Boris Zbarsky wrote: > On 5/21/19 9:55 PM, Mike Hommey wrote: > > Considering this has apparently been broken for so long, I guess nobody > > will object to me removing the option for Gecko builds? > > It's probably fine, yeah... Now removed on autoland via bug 1554056. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Removing --enable-shared-js [Was: Rust and --enable-shared-js]
Hi, I'm revisiting the topic of --enable-shared-js for Gecko builds for different reasons than the one that started this thread. On Mon, Sep 24, 2018 at 08:24:43AM -0400, Boris Zbarsky wrote: > My use case for it is to be able to use the "exclude samples from library X" > or "collapse library X" tools in profilers (like Instruments) to more easily > break down profiles into "page JS" and "Gecko things". > > That said, I haven't done that very much recently... And my guess nobody has done that since, nor for a while, because the way an attempt to build with --enable-shared-js fails leaves me thinking this has been broken at least since bug 1436179 landed... a year ago. Considering this has apparently been broken for so long, I guess nobody will object to me removing the option for Gecko builds? On Tue, Oct 02, 2018 at 09:29:51AM -0500, Luke Wagner wrote: > (Sorry, I polled #jsapi about this issue back when you first posted and > then forgot to reply with the response.) > > It doesn't seem like any SM devs use --enable-shared-js for their own > development but we do know that various embedders (e.g. GNOME) use the JS > shared library and so we'd like to keep that configuration tested and > working. One hybrid option is thus: > - drop support for building Gecko with --enable-shared-js (avoiding the > symbol conflict issue), but keep --enable-shared-js as a configure option > for JS shell builds > - have at least one tier-1 --enable-shared-js JS shell build on automation > so that we at least keep it working It's worth noting that --enable-shared-js is already the default when building spidermonkey standalone. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing ./mach busted
On Sun, Apr 28, 2019 at 04:58:59PM -0400, Randell Jesup wrote: > >TL;DR - In bug 1543241 (alias 'mach-busted'), we now have a central > >clearinghouse of bugs for broken mozilla-central tooling. You can invoke > >|./mach busted| to get a list of known outstanding issues, and |./mach > >busted file| to report a new one. > > In case it's not obvious (it wasn't to me), 'file' is a keyword, not a > file to include, and all you really need to do is file a bug that blocks > bug 1543241 (or add that to an existing bug). We also should name that > bug, for easy in referencing in the future (I propose "mach-busted" ;-) ) It already has that alias. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Fennec moving to extended support
On Thu, Apr 25, 2019 at 09:10:36PM -0400, Ryan VanderMeulen wrote: > Hello everyone, > > tl;dr: Fennec will be following the 68 train to ESR68-based release. > > Why are we doing it? > > We want to provide users with a secure and supported legacy Firefox for > Android until Fenix has matured enough for users to migrate to it. > Therefore, starting from Gecko 68, we plan to use the ESR68 repository as a > stable base for managing Fennec engineering, testing, and release of builds > going forward. > > Will end users notice a difference? > > There will be little to no user-visible changes from this change. Users > will continue to receive new releases on the same cadence as before. > > What should developers expect? > > We specifically chose to make this decision now to take advantage of a new > ESR cycle in order to minimize the overhead such a change entails. > Backports of security fixes and other critical bugs will continue as > expected. This change allows us to continue supporting Fennec for lower > cost while we focus our development resources on GeckoView and Fenix. > > Also, in case of unforeseen issues with this plan going forward, we are not > planning to make any breaking changes to Fennec builds and tests on > mozilla-central until after the start of the Gecko 71 cycle. Tests will be > moved to Tier 2 status and run at lower frequency, however. > > How long will we support Fennec? > > While the ESR68 branch is due to be supported until late 2020, we are not > committing to tying Fennec’s support lifespan to that timeframe. The > decision for if and when to officially EOL Fennec will depend on our > readiness to replace it, which is still TBD. > > If you have any questions about this plan, don’t hesitate to reach out and > I will do my best to follow up. Also, a more detailed project plan is > available at the link below: > > https://docs.google.com/document/d/1oRPkwP3l7QzdQYj0Wn7d_3EfTZaakocA_i_pGKlG0dI/edit?usp=sharing Just skimmed the document, so I might have missed it, but it doesn't seem to mention it. I assume Fenned will live on the same mercurial branch as Firefox ESR68 in the mozilla-esr68 repository (presumably, default) ? Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward
On Wed, Apr 24, 2019 at 03:49:47PM -0700, Bobby Holley wrote: > On Wed, Apr 24, 2019 at 2:21 PM David Major wrote: > > > On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley > > wrote: > > > > > > Thanks Mike! > > > > > > So Fennec is the last remaining non-e10s configuration we ship to users. > > > Given that Fennec test coverage is somewhat incomplete, we probably want > > to > > > keep running desktop 1proc tests until Fennec EOL. We don't strictly need > > > the browser-chrome tests, but we should probably avoid intentionally > > > breaking non-e10s browser-chrome as long as engineers may still need to > > > debug non-e10s test failures. > > > > > > After Fennec EOL, we basically have two options: a clean break where we > > rip > > > out non-e10s support entirely, or a more muddled approach where we > > > halfheartedly keep it working as a handy engineering hack as long as is > > > practical. I think we should do the former. > > > > > > I don't want to downplay the handiness - being able to test and debug the > > > browser in a single process can eliminate complexity and non-determinism, > > > and save a lot of time. But at some point there's going to be a piece of > > > core functionality that's too much work to keep supporting under > > non-e10s - > > > and agonizing over that threshold on an ongoing basis is not a good use > > of > > > anyone's time. > > > > Why not have the conversation when such a piece of core functionality > > arises? It's a much more convincing argument when you can say > > "non-e10s needs to go away in order to support X". > > > > I'm concerned about the impact of a gradual degradation of the e10s > experience and an ambiguous bar as to exactly how much work developers are > expected to do to support it. It's effectively going to be a Tier-3 > platform with no owner. > > > > > > In the meantime, single process debugging is a tremendous saver of > > time and hassle, and we'd need a great reason to disable it. I'm not > > convinced that one currently exists. > > > > I think the tradeoff boils down to (a) how many developers are using > non-e10s debugging, with what frequency, versus (b) how much ongoing > maintenance work is required across various components to keep non-e10s > working. We all have intuition about these things, but I doubt we have hard > data. > > I'm open to the argument that my proposal is too aggressive. We could > certainly try the muddle approach for a while and see how it goes, and how > often 1proc breaks in practice. I don't think we can justify continuing to > run the full suite of 1proc tests as tier-1, but we could potentially run a > few smoketests, which might keep the builds usable enough for debugging. > > If anyone is chomping at the bit to remove 1proc support from their module, > please speak up. I'm not versed on the details of non-e10s, but is it so different from e10s that it could easily break? Or are we more concerned, long term, that non-e10s would block us from making some architectural changes to e10s? Relatedly, do we have a history of having broken non-e10s with e10s changes? Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: NSMODULE_DEFN is no more
As of bug 1541792, it is not possible to define XPCOM components with NSMODULE_DEFN anymore. This follows the recent changes announced by Kris Maglione in https://lists.mozilla.org/pipermail/dev-platform/2019-February/023503.html After those changes, there were too few remaining components not using the new system (and the number if meant to decrease, not increase) to justify keeping the hacks used to register them. Those hacks have served us well, but they've also caused us some subtle problems in the past with LTO and PGO (heck, they even caused problems with PGO during Kris's work). Those remaining components are still registered the old way, but that's now done via manual RegisterModule calls in nsComponentManager.cpp, so if you _really_ need to add components the old way, that's about the only difference: no NSMODULE_DEFN, and a manual registration in nsComponentManager.cpp. But you _really_ should have a good reason to do that. Prefer the new registration described in Kris's message. As a followup, I'm also going to convert some of the remaining components to the new system. Eventually, the old system will go away completely. Cheers, Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: git-cinnabar users, please read
The corruption can manifest itself in different forms. The most obvious one is when you get an error while pulling. The less obvious one is when some file looks weird when you look at it. The specifics of the corruption is that it involves files that were renamed/moved/copied and marked as such in mercurial, and that metadata about the rename/move/copy was not preserved in git-cinnabar for some reason. In that case, subsequent updates to the file may be broken. Pushing modifications to those files might be broken too. If you see any kind of corruption, please keep a copy of your broken clone, open an issue against git-cinnabar, make sure you're up-to-date wrt git-cinnabar and reclone. I'm not able to address issues that aren't reported. Mike On Mon, Apr 08, 2019 at 01:25:40PM +0200, Yaron Tausky wrote: > Could you perhaps tell us more about the corruption? I recently had the > contents of a file corrupted, and after several attempts to fix it myself I > just recloned the repository. I suppose I'm not the only one who > encountered the problem, and most people probably didn't report it. > > Yaron > > On Fri, Apr 5, 2019 at 11:20 AM Mike Hommey wrote: > > > Hi, > > > > If you are using git-cinnabar to access the Mozilla mercurial > > repositories, I need your help. > > > > Please take a minute to download the following file: > > > > https://gist.githubusercontent.com/glandium/a46ef0282e28b8ad2e3ecb5cca259833/raw/2ee8b8dd2c3b07226b6b967f1fb1c407c45f8862/check.py > > > > Then, from within your git clone of a Mozilla repository, please > > run the command: > > > > git cinnabar python check.py > > > > (replace check.py with the location of the file downloaded above) > > > > The script will download a list of sha1s and check whether your > > repository is affected by a corruption. It doesn't send data, and > > doesn't write anything to disk. Please follow the instructions > > if the script finds something wrong. > > > > Thank you for your cooperation, and sorry for the inconvenience if you > > happen to be a victim. With luck, the corruption only happened to the > > person who reported it (because I have no clue how it happened, although > > I understand what the corruption is) > > > > Cheers, > > > > Mike > > ___ > > 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
git-cinnabar users, please read
Hi, If you are using git-cinnabar to access the Mozilla mercurial repositories, I need your help. Please take a minute to download the following file: https://gist.githubusercontent.com/glandium/a46ef0282e28b8ad2e3ecb5cca259833/raw/2ee8b8dd2c3b07226b6b967f1fb1c407c45f8862/check.py Then, from within your git clone of a Mozilla repository, please run the command: git cinnabar python check.py (replace check.py with the location of the file downloaded above) The script will download a list of sha1s and check whether your repository is affected by a corruption. It doesn't send data, and doesn't write anything to disk. Please follow the instructions if the script finds something wrong. Thank you for your cooperation, and sorry for the inconvenience if you happen to be a victim. With luck, the corruption only happened to the person who reported it (because I have no clue how it happened, although I understand what the corruption is) Cheers, Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Building dav1d 0.2.1 - nasm error
On Fri, Mar 22, 2019 at 10:53:40AM +0100, Gabriele Svelto wrote: > Hi Gangadharan, > > On 22/03/19 05:25, gangadhara...@gmail.com wrote: > > I've been trying to build dav1d 0.2 but I always end with meson error > > > > Unusable script '/usr/bin/nasm' > > Program nasm found: NO > > > > meson.build:324:4: ERROR: Program(s) ['nasm'] not found or not executable > > > > Eventhough the path /usr/bin/nasm has nasm in it(latest version). Maybe am > > I missing something here? please suggest me to get this error. > > nasm is now part of the toolchain that can be obtained using ./mach > bootstrap. Run ./mach bootstrap again in your mozilla-central directory > and it will be installed under ~/.mozbuild like the rest of the > toolchain. Once that's done try building again, it should work > out-of-the box. But they're talking about meson, which implies they're trying to build dav1d standalone. But dav1d is not a Mozilla project, it's a videolan project. So Gangadharan, you may want to redirect your question to the videolan project. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using inline variables (C++17) in Gecko
Sorry for the late answer. Thanks for prodding me on irc. On Sat, Feb 23, 2019 at 06:36:39PM -0800, Emilio Cobos Álvarez wrote: > Hey, > > I have a use-case for inline variables, and it's not 100% clear to me > how up-to-date is [1], so asking this mailing-list directly. > > Looks like they're supported from clang 3.9 [2] and gcc 7 [3]. > > We're requiring clang 4.0+ to build already, and IIUC we don't build > with MSVC anymore. But looks like we still support gcc 6 (which I guess > means I can't use them right now). > > Is that right? If so, how far are we from requiring gcc 7 to build? According to [1], the only main distro that would have a hard time _building_ Firefox with such a requirement and that is not EOL is Debian 9. Now, two things that do not appear yet on that table, because I haven't added them, is rustc and nasm. As only the ESR version really has any sort of impact on Debian stable, and the next ESR is, afaik, going to be 68, the requirements for rustc and nasm for that version are going to be, respectively, (probably) 1.33 and 2.13. Neither of those is available in Debian 9, so Debian will have to backport those anyways. In the process of backporting rustc, they'll have to backport a recent llvm too (probably 7, maybe 8), which will mechanically bring a newer version of clang. So, with my Debian hat on, even if a backport of a more recent version of GCC is not made for ESR68 (there's precedent on using a "gcc-mozilla" package to build Firefox, so that's also a possibility), there's going to be a recent enough version of clang to build Firefox (and even then, Debian 9 has clang-4 too). So... with both my Debian and Mozilla hats on, I think we can reasonably bump the requirement to GCC 7. However, there have been hurdles in the past with GCC 7 on Mozilla CI, but IIRC that was related to trying to _ship_ those builds. We still do have builds using GCC for various reasons, but we don't ship them, so that should be fine. We _do_ have jobs that use a GCC plugin that may not be ready to be updated to GCC 7, though. So, I'd say, change all occurrences of linux64-gcc-6 with linux64-gcc-7 under taskcluster/ci, change the minimum GCC version supported in build/moz.configure/toolchain.configure, and do a try build including all the build types you changed the toolchain dependencies of, and see how it goes. And file bugs if things don't go well :). Cheers, Mike 1. https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Linux_compatibility_matrix ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for compiling with MSVC in the near future
Hi, Bug 1512504 has now landed on autoland, meaning that compiling Firefox with MSVC is now not supported anymore. MSVC is however still necessary as a build requirement for its headers and libraries (as well as its assembler on aarch64 and the preprocessor for midl ; and maybe a few other things) Mike On Thu, Dec 06, 2018 at 03:00:12PM -0500, Ted Mielczarek wrote: > Hello, > > In light of the fact that we've switched to clang-cl for our Windows > builds[1], we are planning to drop support for compiling Firefox with MSVC in > the near future[2]. Our estimate is that this will happen sometime in Q1. > Supporting more than one compiler is a maintenance burden and we've already > seen developers spend considerable time getting their patches that work with > clang-cl to build with MSVC. We are currently blocked by the fact that our > aarch64-windows builds are still using MSVC and we are waiting on upstream > clang-cl work to switch those builds to clang-cl. Once that takes place we no > longer have a compelling reason to continue supporting MSVC. > > To preempt the question--when this happens we intend to make MSVC error in > configure, and not just move MSVC to Tier 3 "patches welcome" status. Our > reasoning is that Tier 3 configurations still create work: developers spend > time building in those configurations, and lack of CI coverage means that > when they inevitably break they waste time trying to fix things. Bugs get > filed, and other developers waste time trying to help or reviewing patches to > fix things. Explicitly unsupporting MSVC is the best way for us to convey the > fact that developers should not be using it and we will not accept patches to > fix issues that only affect MSVC. > > If you have specific reasons for continuing to use MSVC please let us know. > If there are deficiencies in clang-cl compared to MSVC we should get them > filed and fixed. > > Thanks, > -Ted > > 1. https://bugzilla.mozilla.org/show_bug.cgi?id=1443590 > 2. https://bugzilla.mozilla.org/show_bug.cgi?id=1512504 > ___ > 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: PSA: 64-bits Windows build are now the default on 64-bits Windows
On Wed, Jan 30, 2019 at 01:41:26PM +0900, Mike Hommey wrote: > On Tue, Jan 29, 2019 at 07:59:29AM +0900, Mike Hommey wrote: > > Hi, > > > > As of bug 1522354, now on autoland, hopefully merged in a few hours, > > the default build you get on a 64-bits Windows machine will be 64-bits, > > instead of 32-bits like it had been forever. > > > > If you do wish to do a 32-bits build on a 64-bits Windows machine, you > > can add: > > > > ``` > > ac_add_options --target=i686 > > ``` > > > > to your mozconfig, and that will do it. > > Actually, that, as well as --target=aarch64, announced in > https://groups.google.com/d/msg/mozilla.dev.platform/F8VOvJHP1T0/tXJ7ldeVDAAJ > > is likely broken at the moment. Thankfully, that will be fixed with bug > 1523540. It turns out it's not broken if the build system is autodetecting an MSVC install (as in, if it's registered in the Windows registry). It is broken if it's not, and bug 1523540 should fix that. Cheers, Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: 64-bits Windows build are now the default on 64-bits Windows
On Tue, Jan 29, 2019 at 07:59:29AM +0900, Mike Hommey wrote: > Hi, > > As of bug 1522354, now on autoland, hopefully merged in a few hours, > the default build you get on a 64-bits Windows machine will be 64-bits, > instead of 32-bits like it had been forever. > > If you do wish to do a 32-bits build on a 64-bits Windows machine, you > can add: > > ``` > ac_add_options --target=i686 > ``` > > to your mozconfig, and that will do it. Actually, that, as well as --target=aarch64, announced in https://groups.google.com/d/msg/mozilla.dev.platform/F8VOvJHP1T0/tXJ7ldeVDAAJ is likely broken at the moment. Thankfully, that will be fixed with bug 1523540. Cheers, Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: 64-bits Windows build are now the default on 64-bits Windows
Hi, As of bug 1522354, now on autoland, hopefully merged in a few hours, the default build you get on a 64-bits Windows machine will be 64-bits, instead of 32-bits like it had been forever. If you do wish to do a 32-bits build on a 64-bits Windows machine, you can add: ``` ac_add_options --target=i686 ``` to your mozconfig, and that will do it. Cheers, Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: New and improved "about:config" for Firefox Desktop
On Fri, Jan 25, 2019 at 10:36:16PM +, Paolo Amadini wrote: > On 1/25/2019 10:39 AM, Axel Hecht wrote: > > Is there a tracking bug for follow-ups? > > Please file bugs blocking bug 1493439, I'll triage them as necessary. > > > filter [...] by modified > > This is bug 1502867, it is something we've considered but I'm a bit > conflicted as it's only really used on 0.4% of page views and we have a > better section dedicated to that use case in "about:support". Actually, I never realized we could order by column, and I've always thought what's in about:support is not enough, because it doesn't allow to edit. I don't think column ordering by modified is interesting in itself, but the fact that it allows to bring all modified prefs at the top is what's interesting, and a view similar to that of about:support, but editable, would go a long way. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Building Firefox for arm64 windows got a lot easier
On Fri, Jan 11, 2019 at 09:24:25AM +0900, Mike Hommey wrote: > Hi, > > Usual disclaimer: the following assumes this all sticks. > > I just landed bug 1515528 to autoland, which simplifies drastically how > to build Firefox for arm64 windows, from a x86/x86_64 windows machine. > > At the moment, this requires some extra manual steps over mach > bootstrap, because this doesn't work with clang-cl yet, and requires > some extra MSVC components. > > In the MSVC installer, choose the following extra components: > - Visual Studio C++ compiler and libraries for ARM64 > - Visual C++ ATL for ARM64 > - Visual C++ MFC for ARM64 > > (apologies if the names above don't match exactly what the installer > shows, I translated them from my Japanese installer) > > While we're here, you might find it useful to know that the build system > supports using Visual Studio Build Tools 2017, which is has a smaller > footprint than e.g. Visual Studio Community 2017. > > With all the above MSVC components installed, edit a mozconfig with the > following content: > ac_add_options --target=aarch64 Oh, forgot one more detail: you need to use nightly rust, and install the aarch64 rust target: rustup default nightly rustup target add aarch64-pc-windows-msvc Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: Building Firefox for arm64 windows got a lot easier
Hi, Usual disclaimer: the following assumes this all sticks. I just landed bug 1515528 to autoland, which simplifies drastically how to build Firefox for arm64 windows, from a x86/x86_64 windows machine. At the moment, this requires some extra manual steps over mach bootstrap, because this doesn't work with clang-cl yet, and requires some extra MSVC components. In the MSVC installer, choose the following extra components: - Visual Studio C++ compiler and libraries for ARM64 - Visual C++ ATL for ARM64 - Visual C++ MFC for ARM64 (apologies if the names above don't match exactly what the installer shows, I translated them from my Japanese installer) While we're here, you might find it useful to know that the build system supports using Visual Studio Build Tools 2017, which is has a smaller footprint than e.g. Visual Studio Community 2017. With all the above MSVC components installed, edit a mozconfig with the following content: ac_add_options --target=aarch64 (yes, that's all) and run `./mach build`. Once the build is finished, you can run `./mach package`, and copy the resulting obj-aarch64/dist/firefox*.zip file to your arm64 machine. Cheers, Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: nasm will soon become a build dependency
On Fri, Dec 21, 2018 at 04:21:03PM -0500, Kartikaya Gupta wrote: > On Fri, Dec 21, 2018 at 4:10 PM Thomas Daede wrote: > > There is a toolchain build for nasm for windows: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1511224 > > > > If getting a newer nasm version is inconvenient for a majority of linux > > users, the toolchain build could be used to produce nasm binaries for > > mach bootstrap as well. > > I would certainly prefer this, and having this work smoothly would > also be good for new contributors. Having to build and install extra > packages is always a hassle. It's a hassle downstream too. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to our C++ Coding Style
On Fri, Dec 07, 2018 at 03:08:51PM -0500, Andrew Halberstadt wrote: > I think we should implement a) and do the formatting prior to submission. > This prevents us from wasting reviewer time on format issues, and also > makes sure that "what you see in phab, is what gets landed". Also, that would make it clear if weird formatting would entirely be due to clang-format (in which case, we should probably file bugs), and not a person's doing. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is future of editor mode-lines after the switch to clang-format?
On Fri, Nov 30, 2018 at 09:57:00AM -0800, tcampb...@mozilla.com wrote: > Now that all of mozilla-central is been migrated to use clang-format > automated code formatting, the question of what should happen with editor > modelines at the top of files should be considered. > > https://bugzilla.mozilla.org/show_bug.cgi?id=clang-format > > Here are some options and some arguments I've heard. Please reply with > further ideas or rationale. I've not classified points as pro/con and leave > that up to the reader's interpretation. > > Option 1: Remove mode lines > - Devs are expected to run clang-format anyways (hopefully automated with a > hook of sorts) > - Devs are free to set their modeline configuration elsewhere > - If they aren't providing value, they deserve to be removed. > - Many of these were already inconsistent/wrong, so this might be an > opportunity to phase out > - Not all devs use vim/emacs, so we should think about workflows help that > doesn't need stuff in every single source file. Even more, Debian-based vim packages have the modeline-reading feature disabled by default for security reasons (because they can, in fact, do anything), which makes vim modelines essentially useless to even a large number of vim users. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Workflow Apropos!
On Wed, Nov 28, 2018 at 09:20:17PM +, James Graham wrote: > On 28/11/2018 20:15, Mark Côté wrote: > > We're still working through a longer-term vision that we'll share early > > next year, but I can answer some questions now. > > Thanks, this is helpful! > > > * Have to make a choice early on about whether to learn a relatively > > unfamiliar (to the majority of developers) VCS (mercurial), use a > > slightly unorthodox git setup with slow initial clone (cinnabar), or > > use > > the largely unsupported (?) GitHub clone. > > > > > > This is a very difficult problem. I can't see this problem going away > > entirely without some sort of executive decision to require everyone use > > a particular VCS. That said, Mercurial should still be seen as the > > default VCS, especially as we get partial-clone support > > (https://bugzilla.mozilla.org/show_bug.cgi?id=150). Git-cinnabar > > should be treated as an "advanced" option. Perhaps docs could be > > clarified as to this. > > I understand that mercurial is not going away :) Having said that it's a > pretty hard sell to get someone to make an initial contribution if it > involves learning a whole new VCS; that's a considerable investment of time > on its own. I wonder if there's something we could do to help people here > like run a taskcluster task on m-c to produce an artifact containing a > cinnabar clone archived using git-bundle, and then set up the bootstrap.py > script to give a choice between mercurial and git using cinnabar, and in the > git case, do the initial clone by downloading a recent bundle and then > fetching missing commits. There's probably a good reason that won't work, > but I'm not sure what it is yet :) https://bugzilla.mozilla.org/show_bug.cgi?id=1459200 is one step in that direction. And git-cinnabar version 0.5.0b4 and newer support cloning from a git reference repo[1]. There is even a mercurial extension[2] to make this more automated, but git-cinnabar won't try to use it by default for now. I want to add support for git bundles, or at least future-proofing for git bundles, first. The reference repo would also need to be updated frequently. Mike 1. For example, you can do: git -c cinnabar.clone=https://github.com/glandium/gecko clone hg::https://hg.mozilla.org/mozilla-unified 2. https://github.com/glandium/git-cinnabar/blob/master/mercurial/cinnabarclone.py ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Signals in Firefox
On Wed, Nov 21, 2018 at 10:22:38AM -0500, Nathan Froyd wrote: > On Wed, Nov 21, 2018 at 4:45 AM David Teller wrote: > > What is our policy on using Unix signals on Firefox? I am currently > > reviewing a patch by external contributors that involves inotify's > > signal API, and I assume it's a bad idea, but I'd like to ask around > > first before sending them back to the drawing board. > > I don't think we have a policy, per se; certainly we already have uses > of signals in the JS engine's wasm implementation and the Gecko > profiler. But in those cases, signals are basically the only way to > do what we want. If there were alternative ways to accomplish those > tasks besides signals, I think we would have avoided signals. > > inotify looks like it has a file descriptor-based interface which > seems perfectly usable. Not being familiar with inotify beyond > reading http://man7.org/linux/man-pages/man7/inotify.7.html, is there > a reason to prefer the signal interface versus the file descriptor > interface? We use the standard gio/gtk event loop, so hooking up the > returned file descriptor from inotify_init should not be onerous. > widget/gtk/nsAppShell.cpp even contains some code to crib from: > > https://searchfox.org/mozilla-central/source/widget/gtk/nsAppShell.cpp#275-281 I'd go one step further. We use Gio from libglib, is there a reason not to use the GFileMonitor API, which wraps inotify? https://developer.gnome.org/gio/stable/GFileMonitor.html Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: Firefox Nightly now with experimental Wayland support
Hi, As of last nightly (20181115100051), Firefox now supports Wayland, thanks to the work from Martin Stransky and Jan Horak, mostly. Before that, it was possible to build your own Firefox with Wayland support (and Fedora does it), but now the downloads from mozilla.org come with Wayland support out of the box for the first time. However, being experimental and all, the Wayland support is not enabled by default, meaning by default, you'll still be using XWayland. To enable wayland support, first set the `GDK_BACKEND` environment variable to `wayland`. To verify whether Wayland support is enabled, go to `about:support`, and check "WebGL 1 Driver WSI Info" and/or "WebGL 2 Driver WSI Info". If they say something about `GLX`, Wayland support is not enabled. If they say something about `EGL`, it is. I filed a bug[1] to make it more obvious what is being used. It's probably still a long way before Firefox enables Wayland support on Wayland by default, but we reached a major milestone here. Please test and report any bug you encounter[2]. Mike 1. https://bugzilla.mozilla.org/show_bug.cgi?id=1507665 2. https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Widget%3A%20Gtk ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Performance profiling improvements #3
On Thu, Nov 01, 2018 at 01:07:54AM -0400, Randell Jesup wrote: > >I think sudo will let you have symbolicated kernel stacks which can be handy. > > $ sudo perf record ./firefox has a problem: > "Running Nightly as root in a regular user's session is not supported." Try sudo -H. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Performance profiling improvements #3
On Mon, Oct 22, 2018 at 02:20:32PM -0700, Panos Astithas wrote: > # Import native `perf` traces > Two of the current limitations of the profiler are that it can’t profile > the very early phase of browser startup (before the profiler code has been > initialized) and that it imposes some small overhead when recording. The > overhead increases when one increases the number of sampled threads. One > nice workaround for both problems that still lets you use the profiler UI > to investigate is recording a profile on Linux with the ‘perf’ tool and > then importing the output from https://perf-html.io/. The profiler can > parse the recorded profile and display the aggregated stacks (but of course > without markers). To record a profile with the ‘perf’ command run the > following commands and then load the firefox.symbol.data output file from > https://perf-html.io: > > sudo perf record -g -F 999 -p > > sudo perf script -F +pid > firefox.symbol.data sudo shouldn't be necessary in either case. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Coming in Firefox 65: Dedicated Profiles Per Install and Profile Downgrade Protection
On Thu, Oct 18, 2018 at 12:32:36PM -0700, Dave Townsend wrote: > In Firefox 65 we intend to ship two new features to help prevent user > frustration caused by using profiles created by newer versions of Firefox. > > Why > > Firefox stores all of its settings in the user’s profile and unless certain > command line arguments are used Firefox always launches with the same > profile. Periodically as Firefox upgrades it makes changes to the settings > that can render the profile unusable by earlier versions of Firefox. This > can cause anything from certain features of Firefox being broken after a > downgrade to Firefox crashing on startup. > > To protect against this two new features will be landing in Nightly soon. > > Dedicated Profiles Per Install > > A common cause of users switching between different versions of Firefox is > having Firefox installed multiple times. This most often happens when users > have different channels installed at the same time like ESR and Release. It > is a common request to be able to run the different installs at the same > time. In Firefox 35 this was made possible for the developer edition by > giving it a dedicated profile. The new dedicated profiles per install > feature extends this and will give every install of Firefox on the computer > a dedicated profile by default. > > Users will be able to run different installs of Firefox simultaneously. > Each will use a different profile for its settings. Upgrading an install of > Firefox will keep it using the same settings. > > We’re tracking work on this feature in bug 1474285. > > Profile Downgrade Protection > > For cases where users manually downgrade an install of Firefox or attempt > to forcefully use an older version of Firefox with a newer profile the > profile downgrade protection feature will now tell the user that the > profile is too new to use with this Firefox giving them the option to > create a new profile to use or to quit. > > We’re tracking work on this feature in bug 1455707. > > Developer Implications > > As developers it is quite common to switch between different builds for > example when testing different built versions of Firefox and doing > regression testing. To support these use-cases a new command line argument > “--allow-downgrade” will allow skipping the downgrade protection. > > Conclusions > > While some users may be impacted by this change we believe that most users > will be unaffected and those that are will see less problems caused by > downgrades than previously. This will give us the ability to ignore the > possibility of downgrades when implementing new features and fixing bugs > going forwards. Being able to make the assumption that this code works as > designed will allow us flexibility in other changes downstream. Does this also mean we can actively remove old data from profiles after this work lands? My profile is very old, and there is a non-negligible amount of data that has accumulated that's just leftover from old data formats that have changed and are now stored in different files. We've never cleaned those up presumably to support downgrades. It seems to me with downgrades officially being unsupported, we should have an active policy of removing old profile data when we migrate to new formats. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How do I file a bug?
On Thu, Oct 04, 2018 at 05:14:47PM -0700, fantasai wrote: > On 10/04/2018 04:26 PM, Steve Fink wrote: > > On 10/04/2018 03:45 PM, fantasai wrote: > > > Start here, at Mozilla's home page: > > > https://www.mozilla.org/ > > > > > > Give me steps to reproduce to find instructions for filing > > > a bug against Firefox. Ditto for up-to-date instructions > > > for building the source and submitting a patch. > > > > > > (Don't send me links to the instructions; I'm cheating by > > > asking here already. Walk me through the process of > > > discovering how I can contribute to Mozilla and make the > > > world a better place. I wouldn't be here if I hadn't > > > already walked that path 19 years ago, but I can't find it > > > anymore so I need some help.) > > > > I tried it out, and did better than I expected on my first run-through: > > [...] > > I'm impressed! Want to take a stab at finding patch-submission > instructions? :D > > > I agree that a nice path from www.mozilla.org would be beneficial, > > especially for promoting the volunteer aspect of the project. > > We've got a lot of highly-produced (read: expensive) material > promoting the volunteer aspect of Mozilla: > https://www.mozilla.org/en-US/contribute/ > But afaict none of it actually leads to a viable path towards > actually becoming a technical contributor... > > From my discussions with staff at Mozilla, the people actually > working with volunteers (like QA and l10n) find this very > frustrating, but the people whose job it is to connect volunteers > to opportunities to contribute don't think it's useful, important, > or in some cases even a good idea to fix this problem. I don't > know how to break through that resistance, and I find it very > demoralizing that there even is any. :( > > I'm also disconnected enough from Mozilla the last few years > that I've no idea where up-to-date documentation on this stuff > would live. If I ever manage to dig myself out of the backlog > of spec work enough to write a patch, I'd like to know where > to look! > > Fwiw, here's how I arrived at becoming a technical contributor: > https://web.archive.org/web/2125153750/http://www.mozilla.org:80/ > > https://web.archive.org/web/2301043132/http://www.mozilla.org:80/get-involved.html > > https://web.archive.org/web/2302035824/http://www.mozilla.org:80/quality/bug-writing-guidelines.html > > https://web.archive.org/web/2304015940/http://www.mozilla.org:80/newlayout/bugathon.html I gave a shot at a generic "I want to contribute" approach of the web site. Starting from https://www.mozilla.org, there's a "Get Involved" link at the top, which leads to https://www.mozilla.org/en-US/contribute/, which has another "Get Involved" button... which leads to https://www.mozilla.org/en-US/contribute/signup/, a disappointing list of 3 simple items, 3 "more challenging" items, and ... nothing else. And what items: - simple - Connect with Mozilla on Twitter - Use Firefox on your phone - Discover why we can't live without encryption - more challenging: - watch someone live hack on Firefox - Learn a bit about coding (which is disappointingly a link to developer tools challenger) - Start using the Mozilla Sumbler app Why there's no link to https://codetribute.mozilla.org/ is beyond me (and it does not help to get to filing new bugs, though) Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rust and --enable-shared-js
On Tue, Oct 02, 2018 at 03:25:04PM +0300, Henri Sivonen wrote: > On Mon, Sep 24, 2018 at 3:24 PM, Boris Zbarsky wrote: > > On 9/24/18 4:04 AM, Henri Sivonen wrote: > >> > >> How important is --enable-shared-js? I gather its use case is making > >> builds faster for SpiderMonkey developers. > > > > > > My use case for it is to be able to use the "exclude samples from library X" > > or "collapse library X" tools in profilers (like Instruments) to more easily > > break down profiles into "page JS" and "Gecko things". I would probably be worthwhile to be able to do that without --enable-shared-js, only because that's not how Nightlies are shipped, and this seems like something that can be useful to do on nightlies. Is grouping by js::* JS* a workable alternative? > On Mon, Sep 24, 2018 at 1:24 PM, Mike Hommey wrote: > >> How important is --enable-shared-js? I gather its use case is making > >> builds faster for SpiderMonkey developers. Is that the only use case? > > > > for _Gecko_ developers. > > This surprises me. Doesn't the build system take care of not > rebuilding SpiderMonkey if it hasn't been edited? Is this only about > the link time? Yes, it reduces link time for libxul because libmozjs doesn't need to be linked statically to it. That might not matter anymore, but it's better to know if people rely on that. I'd like to note that making libxul always have libmozjs statically linked could allow to move some things from libmozglue to libxul. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rust and --enable-shared-js
On Mon, Sep 24, 2018 at 11:04:43AM +0300, Henri Sivonen wrote: > There's an effort to add Rust code to SpiderMonkey: > https://bugzilla.mozilla.org/show_bug.cgi?id=1490948 > > This will introduce a jsrust_shared crate that will just depend on all > the Rust crates that SpiderMonkey needs like gkrust_shared depends on > the crates the rest of Gecko needs. > > This is fine both for building standalone SpiderMonkey (a top-level > jsrust will produce a .a and depend on jsrust_shared) and SpiderMonkey > as part of libxul (gkrust_shared will depend on jsrust_shared). > > However, there exists a third configuration: --enable-shared-js. With > this option, SpiderMonkey is linked dynamically instead of being baked > into libxul. This is fine as long the set of FFI-exposing crates that > SpiderMonkey depends on and the set of FFI-exposing crates that the > rest of Gecko depends on are disjoint. If they aren't disjoint, a > symbol conflict is expected. > > AFAICT, this could be solved in at least three ways: > > 1) Keeping the sets disjoint. If both SpiderMonkey and the rest of > Gecko want to call the same Rust code, introduce a differently-named > FFI binding for SpiderMonkey. > > 2) Making FFI symbols .so-internal so that they don't conflict > between shared libraries. Per > https://bugzilla.mozilla.org/show_bug.cgi?id=1490603 , it seems that > this would require rustc changes that don't exist yet. > > 3) Dropping support for --enable-shared-js > > For my immediate use case, I want to make 4 functions available both > to SpiderMonkey and the rest of Gecko, so option #1 is feasible, but > it won't scale. Maybe #2 becomes feasible before scaling up #1 becomes > a problem. > > But still, I'm curious: > > How important is --enable-shared-js? I gather its use case is making > builds faster for SpiderMonkey developers. Is that the only use case? for _Gecko_ developers. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser Architecture Newsletter #7 (S02E02)
On Thu, Sep 20, 2018 at 12:18:49PM +0300, smaug wrote: > On 09/19/2018 08:34 PM, Nicholas Alexander wrote: > >2. > > > >Making the main browser window be an HTML document with (mostly) HTML > >DOM elements instead of a XUL document with (mostly) XUL DOM elements. > > It is still mystery to me how the performance can be anywhere close to XUL > when > starting browser or opening a new window. > XUL's prototype cache was explicitly added because of performance long ago. > That is why we need to only load already parsed document in a binary format, > or in case of new window, just clone from the prototype. > Last time I heard, moving to use HTML document does cause significant > regressions. I'm reminded of https://bugzilla.mozilla.org/show_bug.cgi?id=618912 but IIRC there were similar experiments back then on desktop, and basic html chrome was significantly faster than basic xul chrome. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Enabling (many) assertions in opt builds locally and eventually Nightly
On Thu, Sep 20, 2018 at 09:22:12AM +1000, Cameron McCormack wrote: > On Thu, Sep 20, 2018, at 1:52 AM, Ehsan Akhgari wrote: > > While it may be the case that we may need to be more stable for > > MOZ_RELEASE_ASSERTs, I very much doubt that every single MOZ_ASSERT in our > > codebase is actually a guaranteed to never fail, so promoting them all to > > be enabled in something like Nightly is extremely dangerous in terms of the > > stability of Nightly for users who are trying to use the browser to get > > their normal work done. > > If it's truly useful to know whether Nightly users are failing these > MOZ_ASSERT assertions, we could use Telemetry to report their failure instead > of crashing. > > (I wonder if we could collect all the same data, and use the same crash > reporting infrastructure, for non-crashing crash reports like this.) On Linux and Mac, we could make MOZ_ASSERT fork and crash in the child, and continue in the parent process. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Lando: Commit Series Landing Support Beta
Apart from some initial issue with warnings that is now fixed, I've used this successfully several times. It can also be used to land unrelated patches in one go, if you go to phabricator and "Edit Related Revisions". That does feel like a hack, though, adding dependencies in phabricator that are actually irrelevant. It's also quite cumbersome to do. As a random thought, an "Add to cart" type of workflow would be great for this. Mike On Tue, Sep 18, 2018 at 12:28:40PM -0400, Steven MacLeod wrote: > Lando support for pushing a series of commits from a Phabricator stack has > been live for the past week or so. Anyone who would like to test & provide > feedback is welcome to start using it. We are leaving the current non-series > version live for a short period to allow falling back to it if something > isn't working for you. > > During this beta period there will be two links to Lando from a Phabricator > revision, "View in Lando" (Which takes you to the non-series Lando) and > "View stack in Lando (beta)" (For series support). The series Lando also > supports landing a single revision as well and I encourage you to use it > for all your landings (unless something gets in your way). > > A few notes to keep in mind: > - The original Lando version will be removed eventually (With the current >URLs being redirected to the series support equivalent). > - Series support Lando for a revision is found at >https://lando.services.mozilla.com/D/ > - Landing only part of a stack is supported. Visit Lando through the >revision you'd like to be the tip of the push. The UI will show you >that revision along with the open parents that must land with it. If >the revision you visit is blocked for some reason the parents will >not be shown. > - This is not the final UI for Lando's series support. > - Bugs can be filed under Conduit :: Lando > > https://bugzilla.mozilla.org/enter_bug.cgi?product=Conduit&component=Lando > - #lando on irc for support. > > > # Future plans for series support > > This iteration of the UI for series support in Lando is intended to be > temporary. The final UI is being worked on and will show the entire stack of > revisions (with a view similar to the one in Phabricator) for any revision > you > visit. You will be able to select the set of revisions to land from the > stack by > choosing a ready to land revision as your tip. > > https://bugzilla.mozilla.org/show_bug.cgi?id=1490337 can be tracked for > updates on the final UI. > ___ > 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
PSA: All nightlies for tier-1 platforms are now built with clang and at least LTO
Hi, As per the subject, as of next nightly, Windows, Mac, Linux, and Android nightlies are now all built with clang, with LTO enabled for all of them, and also with PGO for Windows and Linux. More about it on https://glandium.org/blog/?p=3888 Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dead-code removal of unused Rust FFI exports
On Thu, Aug 30, 2018 at 10:21:09AM -0500, Tom Ritter wrote: > CFI vcall requires one to specify a -fvisibility flag on the command line, > with hidden being the preffered. We set visibility explicitly in some > difficult-to-quickly-identify ways, and adding -fvisibility=hidden > triggered issues with NSS (as well as apparently being redundant to what we > currently do). I tracked them in > https://bugzilla.mozilla.org/show_bug.cgi?id=1459314 The real requirement is for the maximum number of symbols not to be exported, which usually doesn't happen. But it does in our build system, without -fvisibility. If clang doesn't want to honor this, that is a problem, and short-sighted on their part. > That bug includes a monster patch to set visibility manually on a ton of > NSS stuff to get the browser running as a POC, but CFI vcall would need > something much more intelligent. I think the answer is to change the > compiler to not require the flag be present. > > > For Firefox, simply having an equivalent to `-fvisilbility=hidden` so > that all the symbols in the generated static library are hidden would be > sufficient to meet our current needs > > The understanding I got from my bug was that we were already doing the > equivalent of this... somehow. Rust doesn't export as many symbols as C++ does by default. Practically speaking, it's doing the same as we do for C++, without an explicit compiler flag. The "problem" is that it still places *some* symbols public, but we don't need them to be, and it would be better for us to be able to *force* those to be hidden. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dead-code removal of unused Rust FFI exports
On Tue, Aug 28, 2018 at 09:14:02AM -0400, Jeff Muizelaar wrote: > We don't LTO yet on Mac. We don't LTO across languages on any platform yet. Rust is LTOed on all platforms, which removes a bunch of its symbols. Everything that is exposed for C/C++ from Rust, though, is left alone. That's likely to stay true even with cross-language LTO, because as far as the linker is concerned, those FFI symbols might be used by code that link against libxul, so it would still export them. We'd essentially need the equivalent to -fvisibility=hidden for Rust for that to stop being true. Mike > On Tue, Aug 28, 2018 at 5:17 AM, Emilio Cobos Álvarez > wrote: > > > > > > On 8/28/18 9:35 AM, Henri Sivonen wrote: > >> > >> Does some lld mechanism successfully remove dead code when gkrust > >> exports some FFI function that the rest of Gecko never ends up > >> calling? > > > > > > I would expect LTO to get rid of it, but haven't checked myself. > > > >> I.e. in terms of code size, is it OK to vendor an FFI-exposing Rust > >> crate where not every FFI function is used (at least right away)? > >> > > ___ > > 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: mercurial-setup becomes vcs-setup and adds support for git
On Tue, Aug 21, 2018 at 01:26:27PM +0200, Jean-Yves Avenard wrote: > Hi. > > This is awesome, upgrading and configuring cinnabar had always been a sore > point > > But I just noticed that it appears to pull from git-cinnabar master branch… > > I had to run bootstrap on android yesterday, which upgraded git-cinnabar > (requiring a git upgrade) > and had to run it again today. which too requires a git upgrade > > git upgrade takes a significant time. > > Wouldn’t it be better to follow the release branch instead of master? The master branch is now the default branch and recommended to use from 0.5 onwards. It won't receive any change that require a git cinnabar upgrade (until next "minor" version change, aka 0.6). Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Some of the Phabricator review requests don't show up in Bugzilla dashboard
On Thu, Aug 16, 2018 at 10:19:37AM +0100, Andreas Tolfsen wrote: > Also sprach Mike Hommey: > > > Also, for reviewers, be aware that phabricator reviews don't count > > in the red counter on the top right of bugzilla, don't appear in > > the associated drop-down menu, and don't appear in "My requests" > > either. > > This is a bit surprising. I just discovered I had two reviews > waiting for me that had been sitting there for four days. > > Could we do anything to have them included in the ‘Requests’ queue > in Bugzilla? Note they do appear in "My dashboard". But as per the thread starter, that doesn't contain all review requests anyways, so at the moment, the best thing to do is to check https://phabricator.services.mozilla.com/ Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Some of the Phabricator review requests don't show up in Bugzilla dashboard
On Wed, Aug 15, 2018 at 04:53:22PM +0300, smaug wrote: > Hi all, > > I think it is good to let people know that some of the review requests in > Phabricator don't show up in Bugzilla. > https://bugzilla.mozilla.org/show_bug.cgi?id=1482110 > > > > So, if some review seems to take too much time, better to ping the requestee. Also, for reviewers, be aware that phabricator reviews don't count in the red counter on the top right of bugzilla, don't appear in the associated drop-down menu, and don't appear in "My requests" either. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Plan for Sunsetting MozReview
On Thu, Jul 26, 2018 at 06:31:34PM -0400, Mark Côté wrote: > The problem there is that the review repo will be bundled and stored. We > don't want to run another Mercurial server indefinitely. Although, if the > parent is a public changeset (as I believe most are), we could put a link > to that commit in mozilla-central somewhere. Does it need to be "another mercurial server", though? It could be moved to hg.mozilla.org, under some archive hierarchy or something. Or its heads could be added to try (for the gecko mozreview repo). Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposal for a embedding library
On Wed, Jul 18, 2018 at 12:45:30PM -0400, Botond Ballo wrote: > Hi everyone, > > With the proposal for a standard 2D graphics library now on ice [1], > members of the C++ standards committee have been investigating > alternative ways of giving C++ programmers a standard way to write > graphical and interactive applications, in a way that leverages > existing standards and imposes a lower workload on the committee. > > A recent proposal along these lines is for a standard embedding > facility called "web_view", inspired by existing embedding APIs like > Android's WebView: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1108r0.html > > As we have some experience in the embedding space here at Mozilla, I > was wondering if anyone had feedback on this embedding library > proposal. This is an early-stage proposal, so high-level feedback on > the design and overall approach is likely to be welcome. Other than everything that has already been said in this thread, something bugs me with this proposal: a web view is a very UI thing. And I don't think there's any proposal to add more basic UI elements to the standard library. So even if a web view is a desirable thing in the long term (and I'm not saying it is!), there are way more things that should come first. Come to think of it, don't many UI libraries come with a web view anyways? (or is Qt the only one that does?) Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Automated code analysis now also in Phabricator
On Tue, Jul 17, 2018 at 05:06:07PM +0200, Jan Keromnes wrote: > Thanks all for the enthusiasm, we're also excited about what this can do > for us. > > > When did this become active? > > Last year on MozReview, yesterday on Phabricator. > > > Can existing diff be forced to be scanned if they weren’t before? > > The easiest way to force a re-scan is to re-upload the patch (e.g. after > rebasing it). > > Note that the bot doesn't publish anything if no defect was detected. A > complete analysis generally takes a few minutes. It might be better to have some indicator that the analysis *did* run, because otherwise, you can't tell if you should wait longer for the result or whether your code is clean. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Tagged pointers
On Fri, Jul 13, 2018 at 03:03:47PM +1200, Robert O'Callahan wrote: > On Fri, Jul 13, 2018 at 11:40 AM, Steve Fink wrote: > > > On 07/12/2018 04:27 PM, Cameron McCormack wrote: > > > >> On Fri, Jul 13, 2018, at 6:51 AM, Kris Maglione wrote: > >> > >>> I actually have a patch sitting around with helpers to make it super > >>> easy to > >>> use smart pointers as tagged pointers :) I never wound up putting it up > >>> for > >>> review, since my original use case went away, but it you can think of any > >>> specific cases where it would be useful, I'd be happy to try and get it > >>> landed. > >>> > >> Speaking of tagged pointers, I've used lower one or two bits for tagging > >> a number of times, but I've never tried packing things into the high bits > >> of a 64 bit pointer. Is that inadvisable for any reason? How many bits > >> can I use, given the 64 bit platforms we need to support? > >> > > > > JS::Value makes use of this. We preserve the bottom 47 bits, but that's > > starting to be problematic as some systems want 48. So, stashing stuff into > > the high 16 bits is pretty safe! > > > > 57-bit address space support is coming for x86-64. The high 16 bits are also used for user-space address space on some tier-3 platforms, and we've had to make the memory allocator avoid those addresses to make JS::Value work there. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Tagged pointers
On Thu, Jul 12, 2018 at 04:40:39PM -0700, Steve Fink wrote: > On 07/12/2018 04:27 PM, Cameron McCormack wrote: > > On Fri, Jul 13, 2018, at 6:51 AM, Kris Maglione wrote: > > > I actually have a patch sitting around with helpers to make it super easy > > > to > > > use smart pointers as tagged pointers :) I never wound up putting it up > > > for > > > review, since my original use case went away, but it you can think of any > > > specific cases where it would be useful, I'd be happy to try and get it > > > landed. > > Speaking of tagged pointers, I've used lower one or two bits for tagging a > > number of times, but I've never tried packing things into the high bits of > > a 64 bit pointer. Is that inadvisable for any reason? How many bits can I > > use, given the 64 bit platforms we need to support? > > JS::Value makes use of this. We preserve the bottom 47 bits, but that's > starting to be problematic as some systems want 48. So, stashing stuff into > the high 16 bits is pretty safe! > > The number of low bits available depends on your pointer alignment. But you > can generally get away with 2 bits on 32-bit, 3 bits on 64-bit -- unless > it's a char*, in which case it's quite common to have byte-aligned pointers > (eg when sharing part of another string.) You really do need to know the > exact alignment, though, rather than guessing. > > Bit ops are pretty cheap, and in these post-Spectre days, it's not an awful > idea to xor with a type field in those high bits before (potentially > speculatively) accessing pointers. I think you still get the benefits of > speculation if it's the right type. On the topic of tagged pointers, the approach taken in the LLVM code base is interesting, as described in this talk by Chandler Carruth. https://www.youtube.com/watch?v=vElZc6zSIXM (the part relevant to tagged pointers starts at 22:36) (relatedly, I have the beginning of something similar for rust) Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using clang-cl to ship Windows builds
On Wed, Jul 11, 2018 at 11:34:52PM -0700, Anthony Jones wrote: > On Thursday, 12 July 2018 15:50:40 UTC+12, halivi...@gmail.com wrote: > > I hope that both Firefox and Chrome continue to keep the build and > > tests running on MSVC. It would suck if for example we can't build > > Firefox with MSVC. > > I can't comment on Chrome. > > > Will the Firefox team publish builds of Firefox from both MSVC and > > Clang with symbols so we can profile ourselves and compare which is > > faster for the webpages we use? > > The MSVC nightly builds will likely continue until we fully commit to > clang-cl. It is expensive to maintain MSVC workarounds and given that > cross-language LTO[1] is compelling for Firefox, it is unlikely we'd > return to MSVC. Actually, I don't think we do produce MSVC nightly builds. We *do* MSVC build on automation, but they're not exactly nightlies. You won't find them along other nightlies. And until bug 1474756 lands, those builds aren't even with PGO enabled. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using clang-cl to ship Windows builds
On Wed, Jul 11, 2018 at 09:48:23AM -0700, Thomas Daede wrote: > On 07/10/2018 01:29 PM, David Major wrote: > > Bug 1443590 is switching our official Windows builds to use clang-cl > > as the compiler. > > Another great effect of this change is that it finally fixes the issue > of constantly running out of virtual address space when linking Win32 > builds: https://bugzilla.mozilla.org/show_bug.cgi?id=709193 > > This was, for example, blocking AV1 support on Win32 until today. Thanks > for the great work! That will still block it, until clang-cl actually becomes the compiler we use to ship. At the moment, it's not certain it will stay that way, so we need to keep MSVC builds working, including PGO. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)
On Wed, Jul 11, 2018 at 11:42:01PM +0200, Jean-Yves Avenard wrote: > Hi > > > On 11 Jul 2018, at 10:10 pm, Kris Maglione wrote: > > Thanks. Boris added this as a blocker. > > > > It looks like it will be helpful, but unfortunately won't give us the 2MB > > simple arithmetic would suggest. On Windows, at least, (and probably > > elsewhere, but need to confirm) thread stacks are lazily committed, so as > > long as the decoders aren't used in a process, the overhead is probably > > closer to 25KB per thread. > > > > Shrinking the size of the thread pool and lazily spinning up threads when > > they're first needed would probably save us 200KB per process, though... > > I haven’t looked much in details, not being an expert on this and having just > finished watching the world cup… > > A quick glance at the code gives me: > > On mac/linux using pthread: > when a thread is created, the stack size is set using > pthread_attr_setstacksize > https://searchfox.org/mozilla-central/source/nsprpub/pr/src/pthreads/ptthread.c#355 > > On Linux, the man page is clear: > "The stack size attribute determines the minimum size (in bytes) that will be > allocated for threads created using the thread attributes object attr.” > > On mac, less so, I’m not sure what’s the behaviour there is, if it’s > allocated or not… > > On Windows: > https://searchfox.org/mozilla-central/source/nsprpub/pr/src/md/windows/w95thred.c#151 > > the thread is created with STACK_SIZE_PARAM_IS_A_RESERVATION flag set. This > will allocate the memory immediately. Allocate in this context means address space being consumed. It doesn't mean memory being actually committed. Memory is only committed once used, so only as much as what the code running in the thread actually uses is committed (rounded to page size). This means at least 4k per thread, so the more threads we have at initialization, the more memory is committed. That being said, we're talking about something akin to NUWA here, and presumably, we're talking about processes that don't initialize everything. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Coding style: Making the `e` prefix for enum variants not mandatory?
On Thu, Jun 28, 2018 at 05:27:23PM +0200, Emilio Cobos Álvarez wrote: > I asked kats@ (which added the list item regarding enums) and he was fine > removing it from the coding style, so given that and the rest of the thread > I've edited the page accordingly. Not that I'd oppose, but I'll note that neither kats, nor participants to this thread so far are peers of the "C++/Rust usage, tools, and style" module. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozilla-inbound backout policy subject to change (become similar to autoland)
On Wed, Jun 27, 2018 at 12:36:22AM -0400, Boris Zbarsky wrote: > On 6/26/18 6:53 PM, Gregory Szorc wrote: > > I agree that the default behavior of `-p all -u all -t all` is running too > > much and confusing people. I filed bug 1471404 to change the behavior. > > > > Will that be sufficient to fix the issue? > > The proposal is to have that syntax run all tier1 and tier2 things, right? > > It seems to me that we should have a way of running just tier1, since tier2 > problems should not lead to immediate backout. Perma bustage of tier-2 jobs usually do. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XPIDL trajectory
On Wed, Jun 27, 2018 at 01:24:27PM +1000, Nicholas Nethercote wrote: > Thanks for the tip. I've updated the last part of the script accordingly: > > # Count number of bytes in the xptdata.o file. > cd o64 > echo -n "xptdata.o bytes: " > wc --bytes xpcom/reflect/xptinfo/xptdata.o > cd .. > > The current measurements are now: > > Tue, Jun 26, 2018: m-i 423583:4a20ed6e2fee > .idl files: 905 > .idl lines: 97278 total > xptdata.o bytes: 1139160 That includes debug info, though. You may want to look at the output of `size xptdata.o`, and take the decimal sum in the fourth column. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozilla-inbound backout policy subject to change (become similar to autoland)
On Sun, Jun 24, 2018 at 03:28:45PM -0400, Boris Zbarsky wrote: > On 6/19/18 9:04 AM, Sebastian Hengst wrote: > > TL;DR: We would like to change the mozilla-inbound backout policy to be > > like autoland’s. > > This seems like a pretty reasonable change in general. > > Is there a well-documented try syntax string which corresponds to "these are > the things that need to be green to avoid being backed out"? Presumably that > string is not "-p all -u all" because it should exclude tier2 and lower > things, but it's not entirely clear to me what the autoland backout criteria > are. I would assume we want developers to do a try run with that syntax > before pushing to inbound as needed. For some reason, -p all -u all runs things that are not marked tier-2 but also don't run on autoland/inbound/central. I don't know why, but that has repeatedly made me waste time trying to figure out why I was getting oranges on those jobs, which, it turned out, are already busted with an unmodified tree. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: clang prefered for local builds on *nix
Hi, As of bug 1253064 landed earlier today (and now merged on central), local builds on *nix (Linux, BSDs, etc.) will prefer to use clang over gcc by default. If you still prefer to build with gcc instead of clang, you can do so by setting CC=gcc in your environment or adding ac_add_options CC=gcc in your mozconfig. This doesn't affect builds using --enable-release or MOZILLA_OFFICIAL, which means it doesn't affect the builds we or downstreams ship (as long as they are using those options, which they should be). Cheers, Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Update on rustc/clang goodness
On Wed, May 30, 2018 at 02:40:01PM +0300, Henri Sivonen wrote: > On Wed, May 30, 2018 at 8:06 AM, Dave Townsend wrote: > > On Tue, May 29, 2018 at 10:03 PM Jeff Gilbert wrote: > >> I get that, but it reminds me of the reasons people give for "our > >> website works best in $browser". > > > > I was concerned by this too but found myself swayed by the arguments in > > https://blog.mozilla.org/nfroyd/2018/05/29/when-implementation-monoculture-right-thing/and > > in particular the first comment there. > > Indeed, the first comment there (by roc) gets to the point. > > Additionally, the reasons for not supporting multiple browsers tend to > be closer to the "didn't bother" kind whereas we're looking to get a > substantial benefit from clang that MSVC and GCC don't offer to us but > clang likely will: Cross-language inlining across code compiled with > clang and code compiled with rustc. > > To the extent Mozilla runs the compiler, it makes sense to go for the > Open Source choice that allows us to deliver better on "performance as > a feature". We still have at least one static analysis running on GCC, > so I wouldn't expect GCC-compatibility to be dropped even if the app > wouldn't be "best compiled with" GCC. The Linux distro case is > trickier than Mozilla's compiler choice. For CPUs that are tier-3 for > Mozilla, we already tolerate less great performance attributes in > order to enable availability, so distros keeping using GCC for tier-3 > probably isn't a problem. x86_64 could be a problem, though. If > Firefox's performance becomes significantly dependent on having > cross-language inlining, and I expect it will, having a substantial > portion of the user base run without it while thinking they have a > top-tier build could be bad. I hope we can get x86_64 Linux distros to > track our compiler configuration closely. That part might end up more difficult than one could expect. Cross-language inlining is going to require rustc and clang having a compatible llvm ir, and that's pretty much guaranteed to be a problem, even for Mozilla. I'm sure the day we'll have to choose between not doing cross-language inlining or upgrading clang for e.g. security features is relatively close. Anyways, Mozilla builds today are built with PGO, and many downstreams don't even do that... Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Update on rustc/clang goodness
On Wed, May 30, 2018 at 09:19:29AM +1000, Nicholas Nethercote wrote: > On Wed, May 30, 2018 at 7:58 AM, Gregory Szorc wrote: > > > > > MSVC is a separate beast. It is a great compiler. > > > > FWIW: numerous times I have been stymied by MSVC's bugs or lack of > features. Bug 1449787 is a recent example. Also: https://bugzilla.mozilla.org/show_bug.cgi?id=1460341#c22 https://bugzilla.mozilla.org/show_bug.cgi?id=1460341#c24 https://bugzilla.mozilla.org/show_bug.cgi?id=1464036#c17 MSVC generates static initializers for constexpr constructors! (And we're tracking their number as of bug 1464522) Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: License of test data?
On Thu, May 17, 2018 at 01:31:43PM -0400, mhoye wrote: > On 2018-04-24 10:36 AM, mhoye wrote: > > On 2018-04-24 10:24 AM, David Teller wrote: > > > What's our policy for this? Are there any restrictions? All the > > > frameworks I currently have at hand are have either an MIT- or an > > > MIT-like license, so in theory, we need to copy the license somewhere in > > > the test repo, right? > > > > I think that this is my question to answer now; I've taken on licensing > > questions in Gerv's absence. I'm new to this part of the job, so it'll > > take me a day or two to get the answer; I'll come back to this thread > > when I have it. > > Well, more than a day or two. The MIT license is fine to include, and we > have a pile of MIT-licensed code in-tree already. > > Other already-in-tree MPL-2.0 compatible licenses - the "just do it" set, > basically - include Apache 2.0, BSD 2- and 3-clause, LGPL 2.1 and 3.0, GPL > 3.0 and the Unicode Consortium's ICU. The above list is for tests. For things that go in Firefox, it's more complicated. LGPL have requirements that makes us have to put all LGPL libraries in a separate dynamic library (liblgpllibs), and GPL can't be used at all. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent To Require Manifests For Vendored Code In mozilla-central
On Tue, Apr 10, 2018 at 02:46:40PM +1000, Martin Thomson wrote: > This seems like a good idea. > > Please consider adding hg.mozilla.org to your list of things you will > clone from. That will allow us to remove some ugly hacks from the > tree for vendoring NSS and NSPR. (libffi uses the same script, but it > seems to be on GitHub now, so that seems like an easy win assuming > even that libffi still uses that script.) We could use the NSS GitHub > mirror, but NSPR doesn't have one yet and those can't be the only > projects that we have using mercurial. Of course, if that is the > case, then don't worry, we'll just have to talk more seriously about > moving NSS to GitHub. > > You don't permit the use of a tag for vendoring, is that intentional? > Tags for releases are so commonplace that you should consider it. You > shouldn't need a branch AND a tag either. More so because branches > move, which makes them not reliable here. > > Having a version in addition to a tag is redundant and therefore > likely to result in mismatches. I'd say that the tag is enough. I'd say a revision should be mandatory. Branches and tags can change. Revisions can't. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent To Require Manifests For Vendored Code In mozilla-central
On Tue, Apr 10, 2018 at 12:33:27PM +0800, Byron Jones wrote: > glob wrote: > > The plan is to create a YAML file for each library containing metadata > > such as the homepage url, vendored version, bugzilla component, etc. See > > https://goo.gl/QZyz4xfor the full specification. > > this should be: https://goo.gl/QZyz4x for the full specification. This format is essentially assuming the vendored code comes from a VCS repository. We have plenty of third party code that is imported through upstream tarballs, so this should probably be accounted for. How does this fit with rust vendoring? Most if not all the information from your proposed moz.yaml is available in Cargo.toml. Do we need to duplicate this? Does mach vendor rust need to create moz.yaml files from Cargo.toml when it does the vendoring? Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Building Firefox 61+ with GCC will soon require version GCC 6.1+
On Thu, Apr 05, 2018 at 06:53:52PM +1000, Nicholas Nethercote wrote: > Thank you for working on this, jgilbert. > > I tried to take advantage of C++14's relaxed constexpr for bug 1451278, but > I'm getting one test job failure on automation, visible here: > > https://treeherder.mozilla.org/#/jobs?repo=try&revision=bcd8e01989d987268cfb6beb7f86e948eae3730d&selectedJob=172004924 That's a funny error. But the most important bit of information is missing, so one can only conjecture. So, cmake is used to build jsglue.cpp for the rust js crate. It properly uses GCC 6.4 from the right directory, yet fails to build. GCC 6.4 *defaults* to C++14, so I can only conjecture that cmake is explicitly passing some argument that makes it use an older C++ version, because the log doesn't say what command line was used to invoke GCC. (If someone feels like removing the use of cmake, be my guest, we surely don't want that to slip in when those bindings become necessary for gecko ; ironically, it's used to build *one* file. Why the rust cc crate is not used instead is beyond me) Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Visual Studio 2017 15.6 now required to build 61+
On Tue, Mar 13, 2018 at 09:05:50AM +0200, Henri Sivonen wrote: > On Tue, Mar 13, 2018 at 2:29 AM, Ryan VanderMeulen > wrote: > > While I know I'm tempting fate by sending this out while the patches are > > still on autoland, I wanted to start giving people a heads-up now that bug > > 1424281 has been pushed, which will make Visual Studio 2017 15.6 (Update 6) > > the minimum version required to build Gecko 61+ once it merges to m-c. > > > > This change brings a number of improvements over version 15.4, which is > > what we've been using in automation since Gecko 58, including performance > > wins and better C++17 support. > > Thank you! > > It seems that > https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code > doesn't match this information. Also, it seems that last week Gecko > stopped compiling with clang 3.8 even though that page says clang 3.6 > is supported. > > To be clear, I'm not arguing that we should support old compilers, but > it would be good to keep that page up-to-date. > > On the topic of old compilers, it looks like we could get more C++ > features if we changed the minimum gcc requirement. Is Debian > oldstable the current reason for keeping gcc at 4.9? No, the reason we're stuck with 4.9 is that hazard builds are still using 4.9. The GCC plugin used for those builds needs to be updated, and hopefully that will happen soon. > In particular, C++17 structured bindings (gcc 7) would make working > with tuple return values more ergonomic than working with them is > today and more ergonomic than working with outparams. Instead of The best we can bump to right now is GCC 6, which is what we currently use to build the releases. GCC 7 may or may not require more work. > uint32_t result; > size_t read; > size_t written; > bool hadErrors; > Tie(result, read, written, hadErrors) = mDecoder->DecodeToUTF16(...); > > one would write > > auto [result, read, written, hadErrors] = mDecoder->DecodeToUTF16(...); > > bringing ergonomics closer to Rust's ergonomics. I'm not sure type inference in C++ is something to look forward to. In rust, although it can be painful to figure out what type a binding has, at least there's not too many possible coercions. In C++ my gut reaction is that that looks like a foot-chaingun. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review
On Thu, Mar 08, 2018 at 02:40:52PM -0800, Bobby Holley wrote: > I've seen a lot of momentum around migrating chrome-only XPIDL interfaces > to WebIDL. I'm concerned that insufficient attention is being paid to the > impact on our binary size. > > Fundamentally, the WebIDL bindings improve performance and spec correctness > at the expense of code size (and build times). This makes sense for things > that are web-exposed or performance-sensitive. But since the webidl > bindings are also more modern and easier to use, I'm concerned that people > will use them indiscriminately for all sorts of internal APIs, and our > binary will bloat by a thousand paper cuts. > > A WebIDL method binding can easily cost a kilobyte or more, depending on > the number and types of the arguments. If we were to convert all of our > existing xpidl methods, we could approach 10MB in added code size. Last time I looked at bindings, I was horrified to see all the various strings that all look the same except between bindings for field and class names. I wonder how much of the bindings cost in terms of binary size is due to that, or other similar inefficiencies. At least there seems to be a low hanging fruit there. (IIRC, the same was true of ipdl bindings) Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review
On Thu, Mar 08, 2018 at 11:16:44PM +, Stuart Philp wrote: > Generally I think we’d take performance and memory wins over installer > size, but we monitor all three and if installer size grows (gradually) by > an uncomfortable amount we ought to make a call on the trade off. We can > bring it to product should that happen. Note that bigger binary sizes means more memory usage mechanically. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster gecko builds with IceCC on Mac and Linux
On Tue, Jan 16, 2018 at 10:02:12AM -0800, Ralph Giles wrote: > On Tue, Jan 16, 2018 at 7:51 AM, Jean-Yves Avenard > wrote: > > But I would be interested in knowing how long that same Lenovo P710 takes > > to compile *today*…. > > > > On my Lenovo P710 (2x2x6 core Xeon E5-2643 v4), Fedora 27 Linux > > debug -Og build with gcc: 12:34 > debug -Og build with clang: 12:55 > opt build with clang: 11:51 > > Interestingly, I can almost no longer get any benefits when using icecream, > > with 36 cores it saves 11s, with 52 cores it saves 50s only… > > > > Are you staturating all 52 cores during the buidls? Most of the increase in > build time is new Rust code, and icecream doesn't distribute Rust. So in > addition to some long compile times for final crates limiting the minimum > build time, icecream doesn't help much in the run-up either. This is why > I'm excited about the distributed build feature we're adding to sccache. Distributed compilation of rust won't help unfortunately. That won't solve the fact that the long pole of rust compilation is a series of multiple long single-threaded processes that can't happen in parallel because each of them depends on the output of the previous one. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: searchfox now indexes rust
On Mon, Jan 08, 2018 at 11:15:13AM -0500, Kartikaya Gupta wrote: > Just a heads-up, thanks to a bunch of work by Emilio, searchfox.org > now indexes rust code as well, so you can do things like jump to > function definitions and call sites and whatnot. Please use it and > file bugs under Webtools :: Searchfox for defects or feature requests. > I'm not sure how quickly we'll be able to fix them but it'll be good > to have stuff on file. So, now that searchfox is definitely more useful than dxr, can we do something about not having two such services? Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: `general.useragent.locale` is no more. All hail `intl.locale.requested`
On Tue, Dec 05, 2017 at 03:15:06PM -0800, Zibi Braniecki (Gandalf) wrote: > Hi all, > > We just landed a major patch which replaces `general.useragent.locale` pref > with a new pref `intl.locale.requested`. > > Historically, `general.useragent.locale` has been widely used to set a > locale for Firefox UI. > > This year, we introduced a full new API called mozilla::intl::LocaleService > which allows for setting and reading via setRequestedLocales and > getRequestedLocales, respectively. > > Behind some linting and checking, the API still used > `general.useragent.locale` which limited us due to the nature of the pref > and how it stored data. > > With the change, we introduce a new pref - `intl.locale.requested`, which > can be set in the same manner if needed, but can also handle a list of > locales separated via `,` character and is validated to accept only > well-formed BCP47 language tags [1] making our locale handling much more > flexible and resilient. > > This is one of the last major changes in the grand rewrite of how Gecko > handles locales and language negotiation. > > If you need to read/write the requested locales it is *highly* preferred > that you use the (mozI)LocaleService API over reading/writing to the pref > itself, but if you must, the code will be able to handle your change with > grace. > > Over last months we removed all direct writes/reads of the pref, so I hope > there is nothing remaining, and we also introduced a migration code in > nsBrowserGlue for 59 users, but if you happen to encounter a regression, > please report it and CC me. > > If you have any questions about it, let me know! Any change wrt intl.locale.matchOS? Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping remains of support for non-UTF-8 file paths on Gtk platforms (was: Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code)
On Tue, Dec 05, 2017 at 05:16:52PM +0200, Henri Sivonen wrote: > On Tue, Dec 5, 2017 at 4:37 PM, ISHIKAWA,chiaki wrote: > > There are other non-ASCII character issues such as > > https://bugzilla.mozilla.org/show_bug.cgi?id=1258613 > > Very weird bug! (Summary for others: decomposed voiced sound mark is > rendered on the wrong base character.) > > > But the bug I mention occurs because some characters are encoded DIFFERENTLY > > under iOS and the rest of the world when UTF-8 is used. > > HFS+ decomposed Unicode leakage to other systems causes pain, but the > topic of this thread isn't affected by Unicode normalization. > > > By mentioning the bug, I just wanted to point out that there *ARE* obnoxious > > bugs regarding non-ASCII character handling in mozilla software. > > But majority of the Japanese users probably failed to file the non-ASCII > > character bugs, and just think, "oh, another instance of Japanese characters > > not passed correctly between mozilla applications and the external programs, > > etc." > > Possibly, but unfiled bugs don't get fixed and, as seen with non-ASCII > path handling with non-UTF-8 Linux locales, even filed bugs don't get > fixed. As the experiments documented in my previous email to this > thread indicate, non-UTF-8 paths already cause such breakage that at > this point it no longer makes sense to even pretend to support them. Wouldn't it make sense, then, to actively fail to even start Firefox in such cases, instead of pretending it kind of works at all, if we can't even save history or bookmarks properly? Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to require Python 3 to build Firefox 59 and later
On Fri, Nov 10, 2017 at 05:42:01PM -0800, Gregory Szorc wrote: > On Fri, Nov 10, 2017 at 4:22 PM, Xidorn Quan wrote: > > > I'm happy hearing this. I would be interested on whether we are going to > > drop Python 2 at some point, or are we stuck with that forever? > > > > Let's put it this way: we still have a few uses of Perl in the build > system. There have been no meaningful changes to that Perl code in years. > > We'll likely be using Python 2 for years ahead because there isn't a > compelling reason to port code that isn't being actively updated. > > > > > > Also I'm curious what modern features are the team looking forward to? > > > > asyncio is huge for performance, especially for I/O bound workloads (both > local and network). We have a few of these in critical paths in the build > system. > > Python 3.6 is faster than 2.7 pretty much across the board in everything > except for process startup overhead. > > Python 3 has sensible behavior with regards to not coercing Unicode and > bytes types, which means people not using English in their operation system > won't experience as many build failures due to us failing to handle Unicode > in the build system. In fairness, those problems wouldn't be magically be fixed by using python 3. We'd still have to handle the difference between bytes and unicode somehow, and the reason there have been these problems is that we're failing to do that, and python 3 alone wouldn't solve that. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)
On Wed, Nov 08, 2017 at 09:43:29AM +0200, Henri Sivonen wrote: > I agree that workstation GPUs should be avoided. Even if they were as > well supported by Linux distro-provided Open Source drivers as > consumer GPUs, it's at the very least more difficult to find > information about what's true about them. > > We don't need the GPU to be at max spec like we need the CPU to be. > The GPU doesn't affect build times, and for running Firefox it seems > more useful to see how it runs with a consumer GPU. > > I think we also shouldn't overdo multi-monitor *connectors* at the > expense of Linux-compatibility, especially considering that > DisplayPort is supposed to support monitor chaining behind one port on > the graphics card. The Quadro M2000 that caused trouble for me had > *four* DisplayPort connectors. Considering the number of ports vs. > Linux distros Just Working, I'd expect the prioritizing Linux distros > Just Working to be more useful (as in letting developers write code > instead of troubleshoot GPU issues) than having a "professional" > number of connectors as the configuration offered to people who don't > ask for a lot of connectors. (The specs for the older generation > consumer-grade Radeon RX 460 claim 5 DisplayPort screens behind the > one DisplayPort connector on the card, but I haven't verified it > empirically, since I don't have that many screens to test with.) Yes, you can daisy-chain many monitors with DisplayPort, but there's a bandwidth limit you need to be aware of. DP 1.2 can only handle 4 HD screens at 60Hz, and *one* 4K screen at 60Hz DP 1.3 and 1.4 can "only" handle two 4K screens at 60Hz. Also, support for multi-screen over DP is usually flaky wrt hot-plug. At least that's been my experience on both Linux and Windows, and I hear Windows is actually worse. Also, I usually get my monitors set in a different order when I upgrade the kernel. (And I'm only using two HD monitors) Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Pulsebot in #developers
Hi, As the owner of the mentioned bot, I feel I need to jump in, not because I want to defend any position (I pretty much don't care whether pulsebot sends its messages to #developers or somewhere else), but just to mention some facts. Pulsebot did its first post to #developers on May 30, 2014, but really only started reporting checkins 4 days later. Before that, check-ins were reported by firebot, and it had been doing that for as long as my irc logs go, which is September of 2010. Now, looking at the history of firebot and pulsebot messages, it seems there's been an increase over time, but it started before pulsebot (it could be related to the limit above which only one line is sent for a push with multiple commits, I haven't looked into more detail). https://docs.google.com/spreadsheets/d/e/2PACX-1vRNTVhBVEr3Vu6bFaaeHRvY6BaTwuSYrHAa33fZSZda6XzeSw4Jp1l6kIYyNV4c4yOuPnKhQuH6gmz7/pubhtml?gid=534714054&single=true BTW, you'll see in the stats you linked to that the third place goes to firebot, which hasn't posted much since june 2014. So, practically speaking, not much has changed in the recent past as far as commits are concerned. What *did* change, however, if I didn't screw up my grepping, is the number of total messages on the channel: https://docs.google.com/spreadsheets/d/e/2PACX-1vRNTVhBVEr3Vu6bFaaeHRvY6BaTwuSYrHAa33fZSZda6XzeSw4Jp1l6kIYyNV4c4yOuPnKhQuH6gmz7/pubhtml?gid=819219011&single=true Consequently, the percentage of messages due to commits is very much larger. So it seems to me the core problem is not as much "there's too much noise" as "people are not posting on #developers anymore". One could think there's correlation, but I think the reality is simply that less people use irc. Mike On Sat, Nov 04, 2017 at 12:44:32PM +0100, Philipp Kewisch wrote: > Hey Folks, > > I'm a big fan of having development discussions in the open, and in the > past #developers has been the prime place to do that. Even if the > benefit may not be apparent vs. having a private discussion or using a > closed channel, I think this is one of many ways to increase interest > within the community. Back when I got started with Mozilla as a > volunteer, I enjoyed reading discussions in #developers because they > allowed me to peek into things that Mozilla developers were working on, > and at times got me interested in the code that was being talked about. > > One thing that has recently "gotten in the way" of this is pulsebot. I > acknowledge the usefulness of getting notifications on checkin, but it > does add a lot of noise to #developers. Questions asked or discussions > quickly fade away when pulsebot sends another dozen messages due to > checkins and merges. How much exactly becomes apparent when you visit > https://mozilla.logbot.info/developers/stats : pulsebot has said more > than twice as much as anyone else. > > Of course you could say, why don't I just ignore pulsebot? The point is > that only few will actually do so. My impression over time is that less > of the questions I have asked are being answered, and my suspicion is > that in part, people qualified to answer will just not see it in > scrollback between all the pulsebot messages. > > Long story short, can we move pulsebot to a separate channel so that > people can opt-in to, and encourage people to discuss their Gecko > development topics in #developers again? > > Philip > > ___ > 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: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)
On Thu, Oct 26, 2017 at 04:02:20PM -0700, Gregory Szorc wrote: > Also, the machines come with Windows by default. That's by design: that's > where the bulk of Firefox users are. We will develop better products if the > machines we use every day resemble what actual users use. I would encourage > developers to keep Windows on the new machines when they are issued. Except actual users are not using i9s or dual xeons. Yes, we have slower reference hardware, but that also makes the argument of using the same thing as actual users less relevant: you can't develop on machines that actually look like what users have. So, as long as you have the slower reference hardware to test, it doesn't seem to me it should matter what OS you're running on your development machine. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Enable: Automated Static Analysis feedback in MozReview
On Tue, Oct 17, 2017 at 10:38:09AM +0200, Jean-Yves Avenard wrote: > Hi > > Do you have ways to prevent running this code on some external > frameworks? > > Whenever we modify a gtest this causes hundreds of errors about not > using a default constructor … (which shouldn’t be an error anyway) https://github.com/mozilla-releng/services/issues/658 Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Changes to tab min-width
On Fri, Oct 06, 2017 at 05:40:13PM +0100, Jonathan Kew wrote: > On 06/10/2017 17:05, Boris Zbarsky wrote: > > On 10/3/17 5:18 PM, Boris Zbarsky wrote: > > > So just to make sure I understand the change (and this is a > > > theoretical point, because I haven't had a chance to try the change > > > yet)... > > > > OK, now I have had a chance to try it. > > > > When set to the new 50px default, I see 1 letter of title or less (less, > > because the entire second half of the letter is faded out badly). This > > makes tabs more or less unusable for me. :( > > Agree totally with this. I had seen the beginning of this discussion before > I updated to a Nightly with the change, so I knew it was coming (and what > the rationale was), but I was quite shocked at how unusable I found the > browser with narrow tabs. > > No doubt I'd get used to it somehow if there were no way it could be > changed, but I don't think I'd ever be happy with it. I've reset mine to > 100, though I can see that if I didn't have lots of bugzilla tabs open > (where I want to see the whole bug number), I might be OK with about 80. > > Aside: IMO, a more interesting UI experiment than shrinking the tab width > would be a built-in option to put a tab-strip on the side of the window, > instead of across the top. Yes, I know about Tree-Style Tabs and similar > add-ons, but I tend to run something as close as possible to a "vanilla" > browser configuration, so that I'm getting a similar experience to the > majority of our users. If we had "Tabs at the side" (or something) in the > browser preferences (or in Customize?), I suspect a significant number of > users might discover and like it, whereas if it requires finding an add-on, > most people never will. I, for one, would like vertical tabs. As in, rotated tabs, with text that reads vertically. Side note: it's sad that side-bar based tab addons now have to waste a large portion of vertical space because of the (large) side-bar header. Plus, they can't push the toolbar like they used to, taking the whole height of the window. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Follow up on clang-format
On Tue, Sep 26, 2017 at 02:49:56PM +0200, Sylvestre Ledru wrote:
> Le 26/09/2017 à 14:33, smaug a écrit :
> > On 05/23/2014 04:29 AM, Anthony Jones wrote:
> >> Some of you may remember the discussion on clang-format and the `mach
> >> clang-format` command. What we have in place right now is very temporary
> >> but it is functional enough to give it a try. I have not put the effort
> >> into upstreaming my changes. Depending on the feedback I receive I will
> >> either:
> >>
> >> * Finish my existing changes and upstream them
> >> * Remove the `mach clang-format` command altogether
> >> * Do nothing
> >>
> >> I have personally found it useful. However I would like to hear from
> >> other people who have tried it to help me decide what to do next.
> >>
> >> Anthony
> >>
> >
> >
> > clang-format messes up really badly many macros.
> > For example nsElementTable.cpp becomes unreadable.
>
> Yeah, for this kind of structure & presentation layout, we should just ignore
> the formatting on these.
>
> It is hard for reformatting tools to know exactly to do with such patterns.
>
> I reported bug 1403150 for this.
Having run clang-format on a few files recently, I must say I don't like
that it insists some things mut be on one line. Essentially, when you
have a method that is short enough to fit in one line, it forces it to.
And then you end up with something like:
class Foo {
Type MethodA() { do_something(); }
Type MethodB()
{
do_something_that_happens_to_be_long_enough_not_to_fit_on_the_same_line();
}
Type MethodC() { do_something_else(); }
};
And I find that distracting. Is there a pref to make it not reformat things
that look reasonable already, although not "optimally" so?
Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Reminder on Try usage and infrastructure resources
On Thu, Sep 14, 2017 at 11:35:53AM -0400, Stuart Philp wrote: > Hello all, > > As we near 57 the Firefox CI group felt it was important to send out a bit > of a reminder regarding infrastructure usage when you push. > > *tl;dr* There is a real cost (both time and $) to using the 'all' flags in > pushes. They are there if you need them, but please remember to think about > what platforms and test suites you need to execute before you push, and > limit the scope of execution if you can. Maybe it's time to kill the `all` flag, at least for -p. Why? For the combined reason that you're saying we shouldn't be using it, and that it's actually *not* running every platform. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Re-visiting the DOM tree depth limit in layout
On Wed, Sep 13, 2017 at 10:03:55AM -0700, Eric Rahm wrote: > Jan is right, increasing the stack size for all threads would cause a very > large memory regression. Lets not do that ;) Selectively increasing might > make sense but we'd need to keep an eye on how large of an increase we're > expecting. We could also move the main thread loop to a thread that we create with a stack size we want, and leave the original main thread just waiting for it (joining it). Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
