Linux App Summit - Nov 12-15, Barcelona

Hi! A friend of mine is helping organize the 2019 Linux App Summit ( https://linuxappsummit.org/), so I wanted to make sure Mozilla devs had heard about it. (Barcelona is also hosting RustFest.eu from Nov 9-12!) Here's what LAS has to say for itself: --- Applications are the foundation of the

Slides from Orlando platform memory tools meeting

Hi, everybody. I've asked the folks who presented at the platform memory tools meeting in Orlando last Thursday over in the Swan::Ibis meeting room to add a link to their slides or notes to this Google sheet

Re: How do I file a bug?

Below is the text from the code of conduct. The CoC does say to be positive, but it is also at pains to emphasize the importance of being able to speak directly, being open to being wrong, and valuing others' input. I read frustration being expressed in this thread, but not disrespect. The

Re: C++ standards proposal for a embedding library

Reading between the lines, it seems like the committee's aim is to take something that is widely understood and used, broadly capable, and in the big picture relatively well-defined (i.e. the Web), and incorporate it into the C++ standard by reference. The problem is that the *relationship of web

Re: mozilla-central now compiles with C++14

Oh, this is great!! I was going to have to use horrible kludges to get around the lack of generic lambdas. On Wed, Nov 15, 2017 at 8:44 PM, Nathan Froyd wrote: > C++14 constructs are now usable in mozilla-central and related trees. > According to: > >

Re: Visual Studio 2017 coming soon

Okay, this is half the argument. The second half would be: - Does auto cause such mistakes more often than it prevents them? The benefit claimed for auto is that it usually makes code more legible. Hopefully that prevents mistakes, on the balance. - Is ranged-for more prone to iterator

Re: Fennec now builds with clang instead of gcc

As I said in the other thread, I'm eager for generic lambdas. They would let me avoid trying to resurrect mfbt/Function.h and adding support for allocation policies! So: quite eager. On Sun, Oct 29, 2017 at 6:19 PM, Makoto Kato wrote: > Great! BTW, is minimal

Re: Visual Studio 2017 coming soon

How will this affect the matrix of specific C++ features we can use? https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code (At the moment I'm dying for generic lambdas, which are C++14. I'd been using std::function as a workaround, but I also need control over the allocation policy,

Re: Implementing a Chrome DevTools Protocol server in Firefox

, James Graham <ja...@hoppipolla.co.uk> wrote: > On 04/09/17 23:34, Jim Blandy wrote: > >> On Mon, Sep 4, 2017 at 7:36 AM, David Burns <dbu...@mozilla.com> wrote: >> >>> I don't think anyone would disagree with the reasons for doing this. I, >>> >&

Re: Implementing a Chrome DevTools Protocol server in Firefox

On Mon, Sep 4, 2017 at 7:36 AM, David Burns wrote: > I don't think anyone would disagree with the reasons for doing this. I, like James who brought it up earlier, am concerned that we from the emails appear to think that implementing the wire protocol would be sufficient to

Re: Implementing a Chrome DevTools Protocol server in Firefox

Certain bits of the original post are getting more emphasis than I had anticipated. Let me try to clarify why we in Devtools want this change or something like it. The primary goals here are not related to automation and testing. They are: - to allow Devtools to migrate the console and the JS

Re: Implementing a Chrome DevTools Protocol server in Firefox

at 1:09 PM, James Graham <ja...@hoppipolla.co.uk> wrote: > On 31/08/17 19:42, Jim Blandy wrote: > >> Some possibly missing context: Mozilla Devtools wants to see this >> implemented for our own use. After much discussion last summer in London, >> the Firefox

Re: Implementing a Chrome DevTools Protocol server in Firefox

On Thu, Aug 31, 2017 at 2:50 AM, James Graham wrote: > In general it seems unfortunate if we are deciding to implement a > proprietary protocol rather than opting to either extend something that is > already a standard (e.g. WebDriver) or perform standardisation work >

Re: Implementing a Chrome DevTools Protocol server in Firefox

Some possibly missing context: Mozilla Devtools wants to see this implemented for our own use. After much discussion last summer in London, the Firefox Devtools team decided to adopt the Chrome Debugging Protocol for the console and the JavaScript debugger. (The cases for converting the other

Re: Implementing a Chrome DevTools Protocol server in Firefox

project has also expressed interest in adding > > CDP support to improve its own devtools story, and a PR is in flight to > > land a CDP server implementation there [1]. > > > > I've been working on this project with guidance from Jim Blandy. We've > > come up with the followin

Re: JavaScript Binary AST Engineering Newsletter #1

Can code transmitted as an AST be source-mapped, so that developer tools can work properly? On Fri, Aug 18, 2017 at 4:39 AM, David Teller wrote: > Hey, all cool kids have exciting Engineering Newsletters these days, so > it's high time the JavaScript Binary AST got one! > >

Re: Actually-Infallible Fallible Allocations

On Wed, Aug 2, 2017 at 7:58 AM, Ehsan Akhgari wrote: > Vector reallocations show up in profiles all the time, literally in more > than half of the profiles I look at every day. If you examine for example > the large dependency graph of https://bugzilla.mozilla.org/s >

Re: Actually-Infallible Fallible Allocations

I have to ask: does anyone recall the benchmarks that showed that bounds checks or vector reallocations were a measurable performance hit in this code? If we don't, we should just write simple, obviously correct code. If we do, there should be a comment to that effect, or something to convey to

Re: [PATCH] mfbt: Poison: drop obsolete OS2 support

Please read our documentation on submitting patches to Firefox: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/How_to_Submit_a_Patch On Mon, Jul 31, 2017 at 12:28 AM, Enrico Weigelt, metux IT consult < enrico.weig...@gr13.net> wrote: > Signed-off-by: Enrico Weigelt, metux IT

Re: More Rust code

BTW, speaking of training: Jason's and my book, "Programming Rust" will be available on paper from O'Reilly on August 29th! Steve Klabnik's book with No Starch Press is coming out soon as well, but I don't know the details there. On Mon, Jul 17, 2017 at 12:43 PM, Ted Mielczarek

Re: Phabricator Update, July 2017

Yeah, this is kind of the opposite of "No New Rationale". https://air.mozilla.org/friday-plenary-rust-and-the-community/ On Thu, Jul 13, 2017 at 2:49 PM, David Anderson wrote: > On Thursday, July 13, 2017 at 1:38:18 PM UTC-7, Joe Hildebrand wrote: > > I'm responding at the

Re: Phabricator Update, July 2017

Many people seem to be asking, essentially: What will happen to old bugs? I'm trying to follow the discussion, and I'm not clear on this myself. For example, "Splinter will be turned off." For commenting and reviewing, okay, understood. What about viewing patches on old bugs? Yes, Phabricator

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

It seems like there is actually not a consensus on this. (I had thought Smaug's view was the consensus, and found bz's post surprising.) Both approaches have tradeoffs. There's a good reason we require the bug number front and center in a commit message. But I dare you to read the Web Replay bug

Re: FYI: We've forked the Breakpad client code

Under the circumstances, I'll volunteer to review, if that's feasible. On Thu, Feb 9, 2017 at 12:37 PM, Ted Mielczarek wrote: > On Thu, Feb 9, 2017, at 02:47 PM, Aaron Klotz wrote: > > This is great news, Ted! > > > > Are you going to be creating a module for this? Who are

Re: PSA: sysconf(_SC_NPROCESSORS_ONLN) is apparently not reliable on Android / ARM

There are plans to move the js/src/threading primitives into MFBT, so I don't think the core count is out of scope. On Mon, Jan 23, 2017 at 11:53 AM, Gabriele Svelto wrote: > On 23/01/2017 18:44, Gian-Carlo Pascutto wrote: > > If only we had some crossplatform runtime that

Re: Rust required to build Gecko

n Stinnett <jry...@gmail.com> wrote: > On Wed, Dec 21, 2016 at 12:23 AM, Jim Blandy <jbla...@mozilla.com> wrote: > > I had a .mozconfig file that included the line: > > > > . "$topsrcdir/build/mozconfig.common" > > My understanding is that we're

Re: Rust required to build Gecko

I had a .mozconfig file that included the line: . "$topsrcdir/build/mozconfig.common" This turns out to cause problems: it loads build/mozconfig.rust, which says to look for rustc in $topsrcdir/rustc/bin, leading to errors like this: 0:05.53 checking for rustc... not found 0:05.53 DEBUG:

Re: Windows CPU power settings

On Fedora, that'd be the kernel-tools package, and the "cpupower frequency-info" command, I think? On Sat, Dec 17, 2016 at 11:04 PM, Bobby Holley wrote: > It looks like there are similar (though not as bad) shenanigans on Linux. > > In a fresh Ubuntu install, there are

Re: Intent to deprecate: Insecure HTTP

Can't people use Let's Encrypt to obtain a certificate for free without the usual CA run-around? https://letsencrypt.org/getting-started/ "Let’s Encrypt is a free, automated, and open certificate authority brought to you by the non-profit Internet Security Research Group (ISRG)." On Tue, Dec

Re: Mozilla's x86 Linux builds now require SSE2

But, how can we so casually drop support for processors manufactured as recently as 2003? Wasn't there any discussion of this decision? Just kidding, I'm glad we can finally put the x87 behind us, and I know there was *lots* of discussion... On Sun, Nov 27, 2016 at 1:25 AM, Henri Sivonen

Re: Would "Core :: Debugging: gdb" be a good bugzilla component?

I think a meta bug would meet all the requirements. - You'd have to tell people about the component anyway, just as you would a metabug. - Components have textual names instead of numbers, but you can give bugs names that you can use in the blocker field. - You can get mail for new bugs added

Re: Getting rid of already_AddRefed?

9/12/16 3:40 PM, Jim Blandy wrote: > >> Could you go into more detail here? Either the caller will free it, or the >> callee will free it --- but they're both on the same thread. >> > > We have this pretty common pattern for handing references around threads > safely:

Re: Getting rid of already_AddRefed?

On Mon, Sep 12, 2016 at 12:22 PM, Boris Zbarsky wrote: It brings up one potential concern with Move: since the > >> callee might not take the value (intentionally or unintentionally), the >> caller must *refrain* from caring about the state of its Move()'d >> variable, between

Re: DXR: How to search for a file that has since been removed from the tree?

On Fri, Aug 26, 2016 at 1:41 PM, Gregory Szorc wrote: > $ time hg log dom/canvas/WebGLContextReporter.cpp > /dev/null > 0.110s real > > $ time git log -- dom/canvas/WebGLContextReporter.cpp > /dev/null > 3.175s > Yes --- For similar reasons, CVS handled this case very well

Re: New [must_use] property in XPIDL

On Wed, Aug 24, 2016 at 12:17 PM, R Kent James wrote: > But for the record, there are LOTS of issues in Mozilla code that are > missing a "part of writing production code" My own pet peeve is JS code > that gives no hint about the types of inputs, when there are complex >

Re: New [must_use] property in XPIDL

On Mon, Aug 22, 2016 at 4:39 PM, R Kent James wrote: > Exactly, and I hope that you and others restrain your exuberance a > little bit for this reason. A warning would be one thing, but a hard > failure that forces developers to drop what they are doing and think > hard about an

Re: snake_case C++ in m-c (was: Re: C++ Core Guidelines)

On Mon, Aug 15, 2016 at 11:59 AM, Bobby Holley wrote: > On Mon, Aug 15, 2016 at 11:53 AM, Henri Sivonen > wrote: > >> What I'm asking is: >> >> When I take encoding_rs_cpp.h and adapt it to XPCOM/MFBT types for use >> in Gecko, should this be >>

Re: snake_case C++ in m-c (was: Re: C++ Core Guidelines)

tl;dr: There's a reason it's called "mangling"... On Mon, Aug 15, 2016 at 8:45 AM, Jim Blandy <jbla...@mozilla.com> wrote: > I suggest that we start allowing snake_case C++ in m-c so that C++ >> wrappers for the C interfaces to Rust code can be named with mere >>

Re: snake_case C++ in m-c (was: Re: C++ Core Guidelines)

, a slightly different C++ wrapper is > called for in the Gecko case. > > But should such a wrapper just use XPCOM nsACString and MFBT Range or > should it also change the names of the methods to follow Gecko case > rules? > > Relatedly, on the topic of MFBT Range and GSL, und

Re: Report your development frustrations via `mach rage`

-08-08 04:25 PM, Jim Blandy wrote: > >> LOL, but honestly, one of the ways I get myself to treat people better is >> to avoid the whole rage / tableflip / flame vocabulary when thinking about >> what I want to do. Could we publicize this as "mach gripe", and leave &g

Re: Report your development frustrations via `mach rage`

LOL, but honestly, one of the ways I get myself to treat people better is to avoid the whole rage / tableflip / flame vocabulary when thinking about what I want to do. Could we publicize this as "mach gripe", and leave "rage" as an alias? On Mon, Aug 8, 2016 at 10:51 AM, Gregory Szorc

Re: Gecko gdb pretty printers now understand nsTHashtable/friends

It warms the cockles of my heart to see people adding to the GDB pretty-printers. :) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: C++ Core Guidelines

Given GSL's pedigree, I was assuming that we'd bring it in-tree and switch out MFBT facilities with the corresponding GSL things as they became available. One of the main roles of MFBT is to provide polyfills for features standardized in C++ that we can't use yet for toolchain reasons (remember

Re: Static analysis for "use-after-move"?

Yes, that's part of the standard expectations for std::move, and thus mozilla::Move as well. On Thu, Jul 7, 2016 at 6:53 AM, Gerald Squelart <squel...@gmail.com> wrote: > On Monday, May 2, 2016 at 9:49:24 AM UTC+10, Jim Blandy wrote: > > No, we don't know that [moved-from strin

Re: Intent to implement and ship: Changing the toString result on DOM prototype objects

Well, the Debugger.Object.prototype.class getter shouldn't change, but perhaps devtools shouldn't use it any more. Devtools should be displaying objects in a way that doesn't surprise developers. It seems to me the ideal behavior would be for Devtools to show objects in the way that the ES6

Re: All about crashes

On Wed, May 25, 2016 at 8:59 AM, Eric Rescorla wrote: > It's not a matter of defects versus non-defects. It's a matter of abnormal > program > termination versus non-termination. > Great clarification - thanks for explaining! ___

Re: Requiring SSE2 on all 32-bit x86 OSs (was: Re: Reverting to VS2013 on central and aurora)

On Wed, May 18, 2016 at 9:51 AM, Ralph Giles wrote: > On Wed, May 18, 2016 at 3:54 AM, Mike Hommey wrote: > > > Now, with my Debian hat on, I can tell you with 100% certainty that > > angry Debian users *will* come with patches and will return even > >

Re: Requiring SSE2 on all 32-bit x86 OSs (was: Re: Reverting to VS2013 on central and aurora)

I think we need to admit that there isn't any rational, analytical way to compare most of the costs here. The one number we *do* have, the number of users who can't upgrade, is kind of tantalizing us, but we can't quantify how many users we'll gain by requiring SSE2, how many other bugs we'll fix

Re: Reverting to VS2013 on central and aurora

Since we didn't require SSE2 in 32-bit builds until this point, were floating-point results rounded unpredictably in those builds until now? On Fri, May 13, 2016 at 1:42 PM, Benjamin Smedberg wrote: > I am talking about requiring SSE2. That is a larger (but still quite

Re: Can MAX_REFLOW_DEPTH be increased?

Would it be feasible to rewrite the recursive code to be iterative, and keep state in an explicit data structure? That would make it much easier to keep the behavior predictable and consistent across platforms. On Mon, May 2, 2016 at 10:34 AM, L. David Baron wrote: > On

Re: Static analysis for "use-after-move"?

On Fri, Apr 29, 2016 at 4:43 PM, Gerald Squelart wrote: > For example, we know how strings behave when moved from* (the original > becomes empty), and it'd be nice to be able to use that trick when possible > and really needed. > No, we don't know that. The contract of a

Re: ICU proposing to drop support for WinXP (and OS X 10.6)

What are the distributions of memory and flash sizes for the devices people currently run Fennec on? It'll be almost impossible to have a good discussion about Fennec size without those numbers. I seem to remember that is data we felt was okay to collect. On Sun, May 1, 2016 at 2:21 PM, Boris

Re: Static analysis for "use-after-move"?

On Thu, Apr 28, 2016 at 8:22 PM, <jww...@mozilla.com> wrote: > Jim Blandy於 2016年4月28日星期四 UTC+8下午1時51分15秒寫道： > > I don't really think it's a good example. TakeMediaIfKnown is accepting a > > UniquePtr as an inout parameter: it uses, and may modify, its > > value. It shou

Re: Static analysis for "use-after-move"?

On Wed, Apr 27, 2016 at 8:02 PM, Ehsan Akhgari wrote: > Hmm, OK, this is a good example. :-) > > Even though Xidorn's suggestion may work in some cases, I can imagine > that in other cases you wouldn't want the caller to have to know the > preconditions of calling

Re: PSA: Dump GC's retaining paths for any GC thing while debugging with JS::ubi::dumpPaths

Could you show a sample patch that uses this? On Mon, Apr 25, 2016 at 10:19 AM, Nick Fitzgerald wrote: > Hi everyone! > > Friendly PSA: sometimes you're debugging a "leak" where the GC considers > something reachable and therefore won't collect it, and this happens at

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Mon, Apr 25, 2016 at 4:03 AM, Jean-Yves Avenard wrote: > I don't know how popular this method would be, nor if people would be > shocked by providing a operator bool() but here it is :) > > Usually, the people most shocked by providing an operator bool() are those who

Re: Proposal: use nsresult& outparams in constructors to represent failure

The pattern seems reasonable enough. DXR says we have 2579 "init" or "Init" functions, and 9801 callers of such functions. I used: function:init ext:cpp ext:h callers:init ext:cpp ext:h Do you propose we make an effort to fix up existing code, or just introduce this as the preferred pattern in

Re: Why do we still need to include Qt widget in mozilla-central?

ed Raine Mäkeläinen, who has been committing to qtmozembed lately, to >> CC. >> >> On Thu, Apr 14, 2016 at 1:51 AM, Jim Blandy <jbla...@mozilla.com> wrote: >> > On Tue, Apr 12, 2016 at 4:27 AM, Henri Sivonen <hsivo...@hsivonen.fi> >> wrote: >> >> &

Re: PSA: Cancel your old Try pushes

On Fri, Apr 15, 2016 at 12:36 PM, Jonas Sicking wrote: > We could also make the default behavior be to cancel old pushes. And > then enable push message syntax for opting in to not cancelling. > > This could be very frustrating (and cause farm work to be wasted) if it happened

Re: Why do we still need to include Qt widget in mozilla-central?

On Tue, Apr 12, 2016 at 4:27 AM, Henri Sivonen wrote: > On Tue, Apr 12, 2016 at 7:45 AM, Masayuki Nakano > wrote: > > So, my question is, why do we still have Qt widget in mozilla-central? > What > > the reason of keeping it in mozilla-central? > >

Fwd: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

Has anyone contacted the commenter and found out what he's trying to do? I've received bugmail for a lot of comments like the one below today; I assume others have too. They're not very helpful, especially given their length. It seems like he's intending to be helpful, but got some bad advice.

Re: emacs M-x gdb and mach --debug

I don't know of a good way to make mach stop chatting in the middle of GDB's serious conversation with Emacs. It sure would be nice to fix this. Note that Emacs sets the "EMACS" environment variable to "t" in the GDB subprocess. Perhaps mach could use this as a way to automatically behave

Re: Is anyone still using JS strict warnings?

The bug is surprising, in that it claims that the bytecode that consumes the value determines whether a warning is issued (SETLOCAL;CALL), rather than the bytecode doing the fetch. Is that the intended behavior? I can't see how that makes much sense. On Dec 19, 2014 2:55 PM, David

Re: Is anyone still using JS strict warnings?

On Fri, Dec 19, 2014 at 2:22 PM, Nick Fitzgerald nfitzger...@mozilla.com wrote: I generally don't find them useful, but instead annoying, and that they provide a lot of noise to filter out to find actual relevant errors. This is including the undefined property errors. It is a common JS style

Re: Memory management in features implemented in JS

On 03/23/2014 12:17 AM, Boris Zbarsky wrote: Say we have this: observerService.addSettingObserver(data-changed, obj, cache, null) and someone sets a data-changed notification. If I understand your proposal correctly, that will do some equivalent of obj.cache = null, assuming obj is still

Re: Memory management in features implemented in JS

On 03/23/2014 10:56 PM, Steve Fink wrote: Anyway, with your specific example, it seems to me that the problem is that you're losing information. The popups need the main window to communicate with each other, and the main window needs all of its stuff to work while it's open. The solution, then,

Re: Memory management in features implemented in JS

On 03/24/2014 12:55 AM, Jason Orendorff wrote: and blow that whole window out the air lock. Actually, we nuke it from orbit. It's the only way to be sure. ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Memory management in features implemented in JS

On 03/22/2014 10:43 PM, K. Gadd wrote: I'm confused about how this would work. who's observing what? How can obj be collected if you're passing it as an argument? This looks like a synchronous property set passed through an unnecessary intermediary. Sorry, my code example was confusingly

Re: Memory management in features implemented in JS

On 03/22/2014 11:36 PM, Boris Zbarsky wrote: On 3/23/14 2:21 AM, Jim Blandy wrote: See my slightly longer explanation in the previous message. The advantage over passing true for ownsWeak is that my proposed API is completely deterministic. I'm not sure I follow The current setup

Re: Memory management in features implemented in JS

Perhaps in some cases weaker, more manageable mechanisms than full-powered observers and listeners could be sufficient. For example, one approach which gets you the right cleanup behavior without exposing GC, is to have special-case observers which can be easily proven to be safe to drop. For

Re: Memory management in features implemented in JS

On 03/19/2014 04:39 PM, Kyle Huey wrote: Short of not implementing things in JS, what ideas do people have for fixing these issues? We have some ideas of how to add helpers to scope these things to the lifetime of the window (perhaps by adding an API that returns a promise that is resolved at

Re: Memory management in features implemented in JS

On 03/19/2014 04:39 PM, Kyle Huey wrote: Short of not implementing things in JS, what ideas do people have for fixing these issues? We have some ideas of how to add helpers to scope these things to the lifetime of the window (perhaps by adding an API that returns a promise that is resolved at

Re: Memory management in features implemented in JS

On 03/21/2014 03:34 PM, Jim Blandy wrote: What if these DOM nodes could use a special class of observers / listeners that automatically set themselves aside when the node is deleted from the document, and re-instate themselves if the node is re-inserted in the document? Similarly for when

Re: Memory management in features implemented in JS

On 03/21/2014 05:03 PM, Boris Zbarsky wrote: On 3/21/14 6:34 PM, Jim Blandy wrote: I don't believe there are any DOM nodes involved in the situation that Kyle described at the start of this thread... It's true that when I read, We are discovering a lot of leaks in JS implemented DOM objects

Re: Exact rooting is now enabled on desktop

On 01/17/2014 01:24 PM, Terrence Cole wrote: Exact stack rooting is now enabled by default on desktop builds of firefox. I've never heard of a major project escaping from conservative GC once it had entered that state of sin; nor have I heard of anyone implementing a moving collector after

Re: Let's never, ever, shut down NSS -- even in debug builds

On 02/01/2013 09:49 PM, Philip Chee wrote: On Thu, 31 Jan 2013 02:40:01 +0100, Robert Kaiser wrote: Robert Relyea schrieb: Switching to SQLite would make this a non-issue. Is there a plan to do this? An open bug? Someone working on it? Robert Kaiser Doesn't SQLite come with its own set