Rust documentation update

Hi, I have updated the in-tree documentation on writing Rust code: - Adding Rust code - Writing Rust code - Testing & debugging Rust code

Re: Testing Rust code in tree

I have written some draft docs about testing and debugging Rust code, which can be seen in bug 1647987 . I have done my best to summarize the important info mentioned in this thread, plus other stuff. I'd be happy to hear feedback. Relatedly, i

Re: Testing Rust code in tree

The Oxidation wiki has this entry in its FAQ : *Q:* How are in-tree Rust crates tested? *A:* In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhe

Re: New and improved stack-fixing

On Wed, 6 May 2020 at 07:22, Markus Stange wrote: > > >> - On opt builds you won't get symbolication on any platform. >> > > Are there plans to make this work? Does this apply to "optimized debug > builds"? > This was in relation to tests, and it is due to this simple check

Re: New and improved stack-fixing

On Wed, 29 Apr 2020 at 02:32, ISHIKAWA,chiaki wrote: > > Ouch, I am using -gsplit-dwarf to make gdb startup time faster... > > -gsplit-dwarf is set manually on my bash script before invoking ./mach > configure and build. > That would be the problem! Do you think digging github of fix-stack gets

Re: New and improved stack-fixing

On Tue, 28 Apr 2020 at 17:50, ISHIKAWA,chiaki wrote: > > 0:28.98 GECKO(727384) #01: ??? > (/NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/libxul.so + 0x5ab5921) > 0:28.99 GECKO(727384) #02: ??? > (/NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/libxul.so + 0x5ab7f34) > 0:28.99 GECKO(727384) #03: ??? > (

Re: New and improved stack-fixing

On Fri, 6 Mar 2020 at 09:52, Nicholas Nethercote wrote: > > I have written a new stack-fixing tool, called `fix-stacks`, which > symbolizes stack traces produced by Firefox. > > [...] > > There is more work to be done. Soon, I plan to: > > * use `fix-stacks` on test

Re: New and improved stack-fixing

No need to file a bug, I will fix this (and any other documentation I can find) soon. Thanks for the link to this particular case. Nick On Fri, 13 Mar 2020 at 01:08, Chris Hutten-Czapski wrote: > This is wonderful news! > > The most recent time I interacted with this was tracking down a refcoun

Re: New and improved stack-fixing

On Fri, 6 Mar 2020 at 11:27, Andrew Sutherland wrote: > Does this eliminate the need documented at > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Mochitest#stacks > to acquire a `minidump_stackwalk` binary and then expose it via > MINIDUMP_STACKWALK environment variable to get symbol

New and improved stack-fixing

Hi all, I have written a new stack-fixing tool, called `fix-stacks`, which symbolizes stack traces produced by Firefox. `fix-stacks` is intended to replace our existing stack-fixing scripts, `fix_{linux,macosx}_stack.py` and `fix_stack_using_bpsyms.py`, which are used (a) on many test outputs, bo

Accuracy of the list of Rust components in and around Firefox?

Hi, We have a list of Rust components at https://wiki.mozilla.org/Oxidation#Rust_Components. This list includes both components within Firefox and components "around" Firefox, i.e. not shipped in Firefox but used for Firefox development or services. I'd like to know if this list is accurate and

Re: PSA: Improvements to infrastructure underpinning `firefox-source-docs`

I recently wrote my first firefox-source-docs and I was surprised and impressed by one thing in particular: when you run `./mach docs` or `./mach docs ` it opens a Firefox instance that shows the generated HTML, and it *also* starts up a server that automatically regenerates and reloads that HTML e

Re: Static prefs are now defined in a YAML file

On Thu, 18 Jul 2019 at 14:20, Nicholas Nethercote wrote: > Greetings, > > I just landed the patches in bug 1564724. As a result, static prefs are no > longer defined in modules/libpref/init/StaticPrefList.h. They are now > defined in modules/libpref/init/StaticPrefList.yam

Re: PHC, a probabilistic heap checker, will soon be enabled on Linux64 Nightly

of the `phc kind` field. The `phc alloc stack` and `phc free stack` fields currently are not auto-symbolicated; Christian Holler has a script that can do the symbolication. Nick On Fri, 19 Jul 2019 at 13:32, Nicholas Nethercote wrote: > Greetings, > > PHC is a probabilistic heap check

Re: Static prefs are now defined in a YAML file

On Thu, 18 Jul 2019 at 14:20, Nicholas Nethercote wrote: > > I just landed the patches in bug 1564724. As a result, static prefs are no > longer defined in modules/libpref/init/StaticPrefList.h. They are now > defined in modules/libpref/init/StaticPrefList.yaml, from which a > S

Re: Intent to ship: accumulating most JS scripts' data as UTF-8, then directly parsing as UTF-8 (without inflating to UTF-16)

This is excellent news. Do you have any measurements showing perf effects? Semi-relatedly, Swift 5 will change the preferred encoding of strings from UTF-16 to UTF-8. Some readers might find the accompanying blog post interesting: https://swift.org/blog/utf8-string/. Nick On Sat, 20 Jul 2019 at

PHC, a probabilistic heap checker, will soon be enabled on Linux64 Nightly

Greetings, PHC is a probabilistic heap checker I have been working on. It has landed and I am planning to enable it on Monday morning AEST (which is Sunday afternoon/evening in many parts of the world). For now it will only be enabled on Linux64 Nightly builds (and also local developer builds) but

Static prefs are now defined in a YAML file

Greetings, I just landed the patches in bug 1564724. As a result, static prefs are no longer defined in modules/libpref/init/StaticPrefList.h. They are now defined in modules/libpref/init/StaticPrefList.yaml, from which a StaticPrefList.h file is generated. The format is explained in a comment at

Fwd: Enable cargo pipelining to speed up Firefox builds

Hi, The Rust compiler and cargo have a very new feature called "pipelining". This feature increases the amount of parallelism available when building a multi-crate Rust project by overlapping the compilation of dependent crates. For more details on how it works, and lots of measurements, see this

Re: crash reporting, inline functions, and you

I've done a lot of profiling of Rust code using tools that are based around stack traces. I can't emphasize how useful it is to have inlined stack frames. Here is a highly typical example from a profile I had lying around: #1: 0x655A213: alloc (alloc.rs:75) #2: 0x655A213: alloc (alloc.rs:151) #3:

The DOMString type has been removed from XPIDL

Greetings, I just landed the patches for bug 1489047, which remove the DOMString type from XPIDL. Why? Here are details about how string types in XPIDL and WebIDL are converted from JS to C++: - XPIDL AString: `undefined` becomes Void, `null` becomes Void. - XPIDL DOMString: `undefined` becomes

NS_strdup() and nsMemory::Clone() have been renamed

Greetings, In bug 1486690 I renamed both variants of NS_strdup() as NS_xstrdup(). I also renamed nsMemory::Clone() as moz_xmemdup() and moved it into mozalloc. Rationale: - These functions are all infallible, and the 'x' prefix makes this clear, as per our allocator naming convention (e.g. moz_x

Re: mozilla::Hash{Map,Set}

On Fri, Aug 17, 2018 at 3:31 AM, Eric Rahm wrote: > > nsTHashTable is just a templated wrapper around PLDHashTable. For > reference we also have nsDataHashtable, nsClassHashtable, > nsRefPtrHashtable, nsInterfaceHashtable [1] all of which are rather > convenient wrappers around PLDHashTable. Thes

Re: mozilla::Hash{Map,Set}

On Fri, Aug 17, 2018 at 3:10 AM, Kris Maglione wrote: > > It would probably worth converging the APIs, if only because the > nsTHashtable APIs are arcane and antiquated. But it's easier said than > done. There are a lot of consumers of all of the hashtable APIs, and the > code is... not very easy

Re: mozilla::Hash{Map,Set}

On Thu, Aug 16, 2018 at 9:28 AM, Ehsan Akhgari wrote: > > Do you have any good suggestions of how to find such candidates? One > thing that came to my mind was that the BHR data may be a useful source of > insight for this... category=all&durationSpec=512_2048&in

Re: mozilla::Hash{Map,Set}

d other platforms. (PLDHash is substantially smaller, by comparison.) Nick On Thu, Aug 16, 2018 at 6:18 AM, Jeff Gilbert wrote: > Awesome! > > What are the pros/cons to mozilla::Hash{Map,Set} vs > std::unordered_{map,set}? I'm assuming perf is the main draw? Do we > have a

mozilla::Hash{Map,Set}

Hi, I recently moved Spidermonkey's js::Hash{Map,Set} classes from js/public/HashTable.h into mfbt/HashTable.h and renamed them as mozilla::Hash{Map,Set}. They can now be used throughout Gecko. (js/public/HashTable.h still exists in order to provide renamings of mozilla::Hash{Map,Set} as js::Hash

Re: PSA: Major preference service architecture changes inbound

On Fri, Jul 20, 2018 at 7:37 AM, Daniel Veditz wrote: > ​Prefs might be a terrible way to implement that functionality, but it's > been used that way as long as we've had prefs in Mozilla so there seems to > be a need for it. Early offenders: printer setup, mail accounts, external > protocol hand

Re: PSA: Major preference service architecture changes inbound

On Wed, Jul 18, 2018 at 1:57 AM, Kris Maglione wrote: > > While we're thinking about the prefs service, is there any possibility we >> could enable off-main-thread access to preferences? >> > > I think the chances of that are pretty close to 0, but I'll defer to Nick. > I agree, for the reasons

Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

On Fri, Jul 13, 2018 at 1:56 AM, Andrew McCreight wrote: > > > > Just curious, is there a bug on file to measure excess capacity on > > nsTArrays and hash tables? > > njn looked at that kind of issue at some point (he changed how arrays grow, > for instance, to reduce overhead), but it has probab

Two tips for faster Firefox builds

Hi, Here are two things that might help you get faster builds. TL;DR: 1. On Linux, make sure you have lld installed, because it's a *much* faster linker than gold, and it's now used by default if installed. 2. Upgrade your sccache to version 0.2.7 to get faster rebuilds of changed Rust files.

Re: XPIDL trajectory

undled. They're combined into a single .cpp file (xptdata.cpp) which > generates shared static pages (mostly) without relocations :-). > > Perhaps measuring the size of xptdata.o could be more useful? > > - Nika > > On Tue, Jun 26, 2018, 12:31 AM Nicholas Nethercote >

XPIDL trajectory

Hi, After Firefox 57 removed support for legacy extensions, I decided to (roughly) track how much XPIDL code we have. Here are some measurements: Fri, Aug 4, 2017: m-i 372493:72873c109b1b .idl files: 1167 .idl lines: 110240 total .xpt bytes: 417621 total Thu, Aug 17, 2017: m-i 375206:7a794cd2aee

Re: Windows Address Sanitizer enabled on trunk

This is excellent news! Great work by all those involved. Nick On Sat, Jun 2, 2018 at 5:16 AM, David Major wrote: > Bug 1360120 on inbound enables Windows ASan builds and tests on trunk > branches. > > Initially these are tier-2 while we confirm that this doesn't > introduce test flakiness. If

Re: Update on rustc/clang goodness

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. Nick ___ dev-platform mailing l

Re: PSA: Building Firefox 61+ with GCC will soon require version GCC 6.1+

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

dom/ipc/ContentPrefs.{h,cpp} are gone

Greetings, For some time we have had a whitelist of prefs that get sent to content processes very early, in dom/ipc/ContentPrefs.cpp, not via the standard IPC channels. There is also some checking machinery that makes sure that prefs not on that list aren't accessed too early. It is a significant

nsGkAtoms.h has moved

Hi, I just landed bug 1445142, which moves dom/base/nsGkAtoms.h to xpcom/ds/nsGkAtoms.h. The reason for this move: - These atoms aren't really DOM-specific. - The move to xpcom/ means they can be registered immediately after the atom table is created, instead of waiting until nsLayoutStatics::I

Re: Web-Feed subscription improvements

On Wed, Mar 14, 2018 at 2:26 AM, wrote: > > PS: I'm sorry if this post violates any posting guidelines, I'm not > accustomed to newsgroups. > It doesn't violate guidelines. In fact, your post was a very model of a good post: polite, friendly, and informed. Posts from users who are having trouble

Re: Prefs overhaul

, Mar 12, 2018 at 9:16 PM, David Teller wrote: > Out of curiosity, why is the read handled by C++ code? > > On 12/03/2018 10:38, Nicholas Nethercote wrote: > > I don't know. But libpref's file-reading is done by C++ code, which > passes > > a string to the R

Re: Prefs overhaul

On Sun, Mar 11, 2018 at 4:24 AM, ISHIKAWA,chiaki wrote: > > I have noticed that you mentioned rewrite in Rust. > > Does the I/O primitive Rust uses handle the following "short read" case > niciely? > I don't know. But libpref's file-reading is done by C++ code, which passes a string to the Rust

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Sat, Mar 10, 2018 at 11:11 AM, Myk Melez wrote: > If we removed XPConnect bindings entirely and converted XPIDL interfaces > used only by C++ into concrete native classes, then what else would > continue to need XPCOM? > What's your definition of XPCOM? Look in xpcom/, there is a ton of stuff

Prefs overhaul

Hi, I've been doing a lot of work to improve libpref recently, and there is more in the pipeline. I've written a brief roadmap that might be of interest to people: https://wiki.mozilla.org/Platform/PrefsOverhaul I'd be happy to hear feedback, via this list or other means. Thanks. Nick __

Re: New prefs parser has landed

On Sat, Feb 3, 2018 at 9:01 AM, Boris Zbarsky wrote: > On 2/2/18 4:57 PM, Nicholas Nethercote wrote: > >> It shouldn't be too hard, because the prefs grammar is very simple. I >> would >> just implement "panic mode" recovery, which scans for a synchroni

Re: How to pass data from to a content process when it starts up?

> > [1] https://searchfox.org/mozilla-central/rev/ > d03ad8843e3bf2e856126bc53b0475c595e5183b/ipc/glue/ > GeckoChildProcessHost.cpp#1046 > > On Wednesday, 14 February 2018 07:02:43 UTC, Nicholas Nethercote wrote: > > Hi, > > > > When a content process is started, a bunch of pref va

How to pass data from to a content process when it starts up?

Hi, When a content process is started, a bunch of pref values are sent via some -intPrefs/-boolPrefs/-stringPrefs arguments on the command line. This is ugly and limiting and causes multiple problems, so I'd like to find a different way to send this data. The use case is pretty simple, because it

Re: New prefs parser has landed

On Sat, Feb 3, 2018 at 12:42 AM, Boris Zbarsky wrote: > > Perhaps I should implement error recovery, so that ill-formed prefs won't >> cause subsequent prefs to be lost. >> > > You mean pick up parsing again after hitting an error? That sounds > complicated... > It shouldn't be too hard, becau

Re: New prefs parser has landed

On Fri, Feb 2, 2018 at 2:27 PM, Nicholas Nethercote wrote: > It might be possible that you could use about:config or the prefs API to > set a string pref that contains an invalid escape sequence that the parser > will subsequently reject. I will check that. > Thinking (and testing)

Re: New prefs parser has landed

On Fri, Feb 2, 2018 at 12:50 PM, Boris Zbarsky wrote: > On 2/1/18 6:40 PM, Nicholas Nethercote wrote: > >> - prefs.js, which is written by Firefox. Firefox should always generate >> data that is accepted by the new parser >> > > OK. I assume we've double-c

Re: New prefs parser has landed

On Fri, Feb 2, 2018 at 11:32 AM, Xidorn Quan wrote: > > One approach would probably be showing a warning UI to tell people that we > fail to parse user.js and ask them to fix it. > > Not sure how complicated that approach would be. > This suggestion came up in one of the old bugs on this topic.

Re: New prefs parser has landed

On Fri, Feb 2, 2018 at 10:32 AM, Justin Dolske wrote: > > Can I presume that things which now trigger parsing issues are escaped or > errored by the relevant prefs APIs? e.g. if a caller tries to set a pref > name or value with an embedded NULL? > Only the parser has changed. The other APIs are

Re: New prefs parser has landed

On Fri, Feb 2, 2018 at 9:47 AM, Boris Zbarsky wrote: > > What happens if a user's prefs file has things that were OK but now fail? > Is it effectively dataloss in that we will not parse anything after that > and then write out the modified pref file with all the later things missing? > There are

New prefs parser has landed

Hi, I just landed https://bugzilla.mozilla.org/show_bug.cgi?id=1423840, which replaces the old prefs parser with a new one. The new parser is faster, safer, gives better and more accurate error messages, and is *much* easier to maintain. It is also slightly stricter; see the list at the bottom o

Re: Revised proposal to refactor the observer service

I have similar issues with some changes to prefs that I am planning. I too am probably going to end up with a split implementation, with "good prefs" (faster, better) for C++ usage and "crappy prefs" (the current implementation) for JS usage. https://bugzilla.mozilla.org/show_bug.cgi?id=1425909 is

All about Prefs

Hi, I recently became the module owner of Prefs, and there are several peers. In the past it was an ill-maintained module, but that is no longer the case. I have been doing a bunch of work to improve Prefs. As part of this I wrote a document that describes how they currently work, and some of the

Proposal to remove some preferences override support

Greetings, In https://bugzilla.mozilla.org/show_bug.cgi?id=1413413 I am planning to remove a couple of things relating to preferences. 1) Remove the defaults/preferences directory support for extensions. This is a feature that was used by legacy extensions but is not used by WebExtensions. 2) Re

Re: nsAutoConfig

Thank you for the info! I will leave that code alone :) Nick On Wed, Nov 1, 2017 at 2:22 AM, wrote: > On Tuesday, October 31, 2017 at 12:10:21 AM UTC-5, Nicholas Nethercote > wrote: > > Hi, > > > > I was just looking at the extensions/pref/autoconfig/ directory and &g

nsAutoConfig

Hi, I was just looking at the extensions/pref/autoconfig/ directory and trying to understand what it does. As far as I can tell, the code is there to allow custom deployments with particular prefs set, as described at https://developer.mozilla.org/en-US/Firefox/Enterprise_deployment#Configuration

Re: Fennec now builds with clang instead of gcc

Excellent news! Thank you for completing this. Updating toolchains isn't glamorous work but it is important and helps everybody. Nick On Mon, Oct 30, 2017 at 10:15 AM, Nathan Froyd wrote: > Hi all, > > Bug 1163171 has been merged to mozilla-central, moving our Android > builds over to using cla

Re: Intent to remove client.mk

This is excellent news. Relatedly, I want to particularly say that I think moz.build files are great. The syntax and semantics are very clear. They're easy to modify. They handle both simple cases and complex cases well. They pretty much never get in the way, which is exactly what a developer want

Re: nsIAtom has been deCOMtaminated and is now called nsAtom

On Mon, Oct 9, 2017 at 1:32 PM, Kyle Huey wrote: > > You couldn't get to mozilla::Atom? > See https://bugzilla.mozilla.org/show_bug.cgi?id=1400460#c2. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo

nsIAtom has been deCOMtaminated and is now called nsAtom

Greetings, I have been deCOMtaminating nsIAtom over the past two months: https://bugzilla.mozilla.org/show_bug.cgi?id=1392883. A big step that landed over a week ago was the devirtualization of nsIAtom, which means it is no longer a subclass of nsISupports: https://bugzilla.mozilla.org/show_bug.c

Re: Changes to tab min-width

On Sat, Oct 7, 2017 at 9:40 AM, Mike Hommey wrote: > 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. >

Re: Intent to Enable: Automated Static Analysis feedback in MozReview

This sounds interesting! But it's not analyzing patches that are not using MozReview. Will those patches be analyzed after landing? Nick On Wed, Oct 4, 2017 at 6:17 PM, Jan Keromnes wrote: > TL;DR -- We wrote a static analysis bot for MozReview ("clangbot") and it's > about to complain about a

Null[C]String() has been renamed Void[C]String()

Hi, I just landed patches from bug 1401813 that rename Null[C]String() as Void[C]String(). The commit message has the rationale: > XPCOM's string API doesn't have the notion of a "null string". But it does have > the notion of a "void string" (or "voided string"), and that's what these > function

Re: Intent to require `mach try` for submitting to Try

ge syntax, so given that try syntax is supposed to continue to work > with `mach try`, I don't see why trychooser wouldn't. > > > On Sat, Sep 16, 2017 at 09:51:41AM +1000, Nicholas Nethercote wrote: > >> Are there docs on how to use `./mach try`? `./mach help try` do

Re: Intent to require `mach try` for submitting to Try

Are there docs on how to use `./mach try`? `./mach help try` doesn't give much detail. Also, will https://mozilla-releng.net/trychooser/ still work? I'm generally more of a command line person than a GUI person, but this is one case where I find the GUI approach far more usable. Nick On Sat, Sep

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

On Wed, Aug 23, 2017 at 2:50 AM, Nicholas Alexander wrote: > >> I really wish our top-level namespace was "moz", rather than "mozilla". > > Can you say why? Is it "just" shorter? Is it more pleasant to s/std/moz/ and vice versa? Mostly because it's shorter. It's good for common names to be shor

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

I really wish our top-level namespace was "moz", rather than "mozilla". Nick On Tue, Aug 22, 2017 at 10:31 AM, Eric Rahm wrote: > On Mon, Aug 21, 2017 at 8:32 AM, Jonathan Kew wrote: > > > > > Wouldn't it be more "modern Gecko-ish", though, to drop the "ns" prefix, > > and perhaps put Auto[C]S

New string types: nsAutoStringN<> and nsAutoCStringN<>

Hi, For a long time we have had types nsAutoString and nsAutoCString which are strings with 64 chars of inline storage. They are good for holding short strings, most often on the stack, because they avoid the need to heap allocate a char buffer. I recently landed patches (bug 1386103) that introd

Re: ns*String vs. printf()

There's documentation about this here: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Guide/Internal_strings#printf_and_a_UTF-16_string Nick On Tue, Aug 15, 2017 at 3:28 PM, Enrico Weigelt, metux IT consult < enrico.weig...@gr13.net> wrote: > Hi folks, > > what's the best way to pri

Re: Changing .idl files

On Tue, Aug 8, 2017 at 7:12 AM, Boris Zbarsky wrote: > > So if right now we land a patch that breaks addons, and a nightly user > updates, they get a broken browser and have to try to figure out whether > it's because we broken an addon (and this may not be the first thing they > think of) or bec

Re: 64-bit Firefox progress report: 2017-07-18

I think the 2GB "requirement" from Microsoft should be ignored, because plenty of our users are ignoring it. Nick On Mon, Aug 7, 2017 at 5:51 PM, Chris Peterson wrote: > On 2017-08-06 11:26 PM, Henri Sivonen wrote: > >> On Thu, Jul 20, 2017 at 10:42 AM, Chris Peterson >> wrote: >> >>> Users wit

Stack walking in Gecko

Hi, We have multiple ways of getting stack traces, and it is hard to keep track of them all. I wrote down some notes that reflect my understanding, and I thought I'd share it in case it's useful, and in case people have ideas on how to improve things. Nick --

Re: Extensions and Gecko specific APIs

FWIW, I share Steve's broad concerns here. Mozilla's track record on extension APIs has had many dead-ends and changes of direction. Now that we're wiping the slate clean, it would be good to not repeat history. Nick On Fri, Jul 28, 2017 at 3:02 AM, Steve Fink wrote: > On 07/26/2017 10:45 PM, A

Re: Announcing MozillaBuild 3.0 Release

This thread is nominally about a new version of MozillaBuild 3.0, though it has strayed significantly. I'm going to politely suggest that discussion of other topics in this thread cease. If anybody wants to start other threads on other topics, please do so. But also be aware that this mailing list

Re: More Rust code

On Tue, Jul 11, 2017 at 11:03 AM, Nicholas Nethercote < n.netherc...@gmail.com> wrote: > > >> The first thing comes to my mind is crash reports. It currently doesn't >> always include useful panic message from Rust, see for example [1] and [2]. >> >

Re: More Rust code

https://wiki.mozilla.org/Oxidation#Documentation has some documentation about how Rust code should be incorporated into Firefox. I don't know how accurate and thorough it is, but it looks like a good starting point. Nick On Tue, Jul 11, 2017 at 8:16 PM, Gabor Krizsanits wrote: > > > On Mon, Jul

Re: More Rust code

On Tue, Jul 11, 2017 at 11:15 AM, Bobby Holley wrote: > If I were the owner of that module I would consider implementing a policy >> something like the following: >> >> "When a person writes a new compiled-code component, or majorly rewrites >> an existing one, they should strongly consider writi

Re: More Rust code

On Tue, Jul 11, 2017 at 9:48 AM, Xidorn Quan wrote: > Tooling around debug info in Rust code still isn't great. > The good news is that tooling issues are generally among the easier ones to solve. Even the existing Rust code that is present in Firefox will require at least some of these things t

Re: More Rust code

On Tue, Jul 11, 2017 at 2:33 AM, Bobby Holley wrote: > > In other words, I think we should encourage people to consider Rust for > new code, but also make sure that we have a thoughtful and informed > discussion about whether a use-case makes sense and how best to support it. > Definitely! I del

Re: More Rust code

On Mon, Jul 10, 2017 at 11:41 PM, smaug wrote: > > - Interop with existing components can be difficult. IPDL codegen rust >> bindings could be a big help. >> > > ipdl? or do you mean idl? or perhaps webidl? > bkelly suggested that item to me on Twitter :) Probably all three of those are relevan

More Rust code

Hi, Firefox now has multiple Rust components, and it's on track to get a bunch more. See https://wiki.mozilla.org/Oxidation for details. I think this is an excellent trend, and I've been thinking about how to accelerate it. Here's a provocative goal worth considering: "when writing a new compiled

Re: Changing .idl files

ck On Wed, Jun 14, 2017 at 10:40 AM, Nicholas Nethercote < n.netherc...@gmail.com> wrote: > Hi, > > What must be considered when changing an XPIDL interface in a .idl file? > As far > as I know, it's the following. > > (1) Update browser C++ code that uses the interf

Changing .idl files

Hi, What must be considered when changing an XPIDL interface in a .idl file? As far as I know, it's the following. (1) Update browser C++ code that uses the interface. This is easy because the compiler will tell you the parts that need changing. (2) Update browser JS code that uses the interface

Re: Is it OK to make allocations that intentionally aren't freed? (was: Re: Is Big5 form submission fast enough?)

On Mon, May 22, 2017 at 10:06 AM, Andrew McCreight wrote: > > NS_FREE_PERMANENT_DATA. > That's it! (Thank you mccr8.) Please use that one. Look at the existing uses for ideas. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://

Re: Is it OK to make allocations that intentionally aren't freed? (was: Re: Is Big5 form submission fast enough?)

There's also a pre-processor constant that we define in Valgrind/ASAN/etc. builds that you can check in order to free more stuff than you otherwise would. But I can't for the life of me remember what it's called :( Nick On Sat, May 20, 2017 at 5:09 AM, Jeff Muizelaar wrote: > We use functions l

Re: Volunteer maintainer wanted: mac x86

On Wed, May 17, 2017 at 5:28 PM, Nicholas Nethercote wrote: > https://developer.mozilla.org/en/docs/Supported_build_configurations > still lists x86/Mac as a tier 1 platform. > > Should it be moved to tier 3, or removed altogether? > If anyone was wondering... I was abo

MOZ_WIDGET_GONK removal

Hi, The Gonk widget code is in the process of being removed. - https://bugzilla.mozilla.org/show_bug.cgi?id=1355752#c25 is where the decision was made to stop supporting it. A chunk of Gonk widget code was also removed from layout/ in that bug. - https://bugzilla.mozilla.org/show_bug.cgi?id=

Re: Volunteer maintainer wanted: mac x86

https://developer.mozilla.org/en/docs/Supported_build_configurations still lists x86/Mac as a tier 1 platform. Should it be moved to tier 3, or removed altogether? Nick On Thu, Dec 1, 2016 at 2:29 AM, Benjamin Smedberg wrote: > As of Firefox 53, we are intending to switch Firefox on mac from a

Re: Removing Jemalloc 4

On Wed, May 17, 2017 at 4:28 AM, Steve Fink wrote: > > But I'm curious if you know anything about the intended future directions > of jemalloc, if there are any, and whether they align with anything we need. As far as I know the short answer is "whatever Facebook needs", because jemalloc's auth

Re: Removing Jemalloc 4

Just to add some context: glandium is deeply familiar with jemalloc4's internals, having submitted numerous patches and fixes to it. And he has spent *significant* time and effort on multiple occasions, on multiple versions of jemalloc4, trying to avoid the performance regressions, without success.

Re: Using references vs. pointers in C++ code

On Wed, May 10, 2017 at 10:27 AM, Karl Tomlinson wrote: > > Or is NotNull really too awkward IRL? > I wrote NotNull.h, and I've used it in various places. I'm ambivalent about it. It does make things clear, but it also is a bit annoying to use. The code tends to end up with WrapNotNull() and get

Re: Quantum Flow Engineering Newsletter #6

Judging from the incoming flow of bug reports, the number of people using the Gecko Profiler has increased in the last week or two. I take this as a good sign that it's being used increasingly heavily for Quantum Flow work, which is good. Nick On Fri, Apr 21, 2017 at 4:25 PM, Ehsan Akhgari wrote

Re: A reminder about commit messages: they should be useful

On Tue, Apr 18, 2017 at 11:34 AM, Ben Kelly wrote: > FWIW I agree with Olli. I look for a good one line summary of the change, > but beyond that I find you really do need to look at the bug to get the > full context. > Huh, interesting. Thanks for the data point. > I don't object to people wr

Re: A reminder about commit messages: they should be useful

On Tue, Apr 18, 2017 at 9:58 AM, smaug wrote: > > That is why we have links to the bug. Bug should always be the unite of > truth telling > why some change was done. Bugs tend to have so much more context about the > change than any individual commit message can or should have. > With all due re

Re: e10s-multi update and tests

On Thu, Mar 23, 2017 at 12:12 PM, Andrew McCreight wrote: > > Though maybe you are asking which processes count against the limit of 4. > Yes, that's what I am asking. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.moz

Re: e10s-multi update and tests

Do we have a clear definition of "content process"? I.e. does/will it include: - GMP processes (no?) - GPU process (probably not?) - file:// URL processes (probably should?) - Web Extensions processes (probably should?) - ServiceWorker processes (probably should?) Thanks. Nick On Thu, Mar 23, 2

Re: The future of commit access policy for core Firefox

On Sat, Mar 11, 2017 at 2:23 PM, smaug via governance < governa...@lists.mozilla.org> wrote: > > I'd be ok to do a quick r+ if interdiff was working well. Depending on the relative timezones of the reviewer and reviewee, that could delay landing by 24 hours or even a whole weekend. In general the

Re: All the processes

On Tue, Mar 7, 2017 at 11:27 AM, wrote: > > Intuitively I don't grasp how each content process can add that much more memory that it would become a "major problem" jumping from 4 to 8 Simple: lots of stuff gets duplicated in each process. Efforts have been made to share data between processes to

  1   2   3   4   5   >