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

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: > > >

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

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

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

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 > > >

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

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

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

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

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

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 > > > l

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

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

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

Anyone using the mapfiles? (Was: PSA: Changes to Gecko/Firefox mirrors on github)

-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: >

Re: PSA: Changes to Gecko/Firefox mirrors on github

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 s

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

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

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

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

Re: Watch out for build issues on non-Unicode systems

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-

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

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): > > > >

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

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

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

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... No

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"

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

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

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. > > >

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

Re: git-cinnabar users, please read

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

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

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 > > > >

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

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

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 w

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

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

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

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.

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

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

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

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. > >

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

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

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

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

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

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

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 > > >

Re: Rust and --enable-shared-js

nd "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,

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

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

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

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

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 ___

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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,

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 >

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)

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

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 >

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 >

Re: Coding style: Placement of binary operators when breaking a long line

On Thu, Sep 07, 2017 at 12:47:51AM -0700, Chris Peterson wrote: > On 2017-09-06 8:06 PM, Ehsan Akhgari wrote: > > The interesting points to consider is the data that Nick alluded to in > > the previous discussion about the existing prevalent style. > > > > Also, the point you up about the

Re: Coding style: Placement of binary operators when breaking a long line

On Wed, Sep 06, 2017 at 12:30:58PM -0700, Eric Rahm wrote: > Hi folks- > > *Note: Previously we've discussed the placement of logical operators && and > ||; a decision was made and I do not wish to re-litigate that here*. > > Currently we have a somewhat convoluted set of rules about where to

  1   2   3   4   5   6   >