On Friday, March 27, 2020 at 11:11:46 PM UTC+11, Bastien Abadie wrote:
> The code review bot has been updated today and now publishes all issues
> found on your patches as Phabricator lint results (Diff Detail section)
> instead of inline comments.
>
> Here is a sample revision showcasing the new
On Friday, December 6, 2019 at 9:20:21 AM UTC+11, Geoff Lankow wrote:
> Hi all
>
> I'm redesigning a bunch of Thunderbird things to be asynchronous. I'd
> like to use Promises but a lot of the time I'll be far from a JS context
> so that doesn't really seem like an option. The best alternative I
Unfortunately using the pref doesn't always work.
Instead, go to the Firefox hamburger menu -> Web Developer -> Enable Profiler
Toolbar Icon. It shows up as a small stopwatch.
As Greg said, we're still in transition, sorry for the confusion! ;-)
- Gerald
On Thursday, October 31, 2019 at 8:45:1
On Tuesday, October 29, 2019 at 3:27:52 AM UTC+11, smaug wrote:
> On 10/24/19 9:17 AM, Marcos Caceres wrote:
> > On Thursday, October 24, 2019 at 6:46:08 AM UTC+11, Christopher Manchester
> > wrote:
> >> As announced in this week's project call, sccache-dist schedulers have been
> >> deployed to m
I'm in the middle of watching Chandler Carruth's CppCon talk "There Are No
Zero-Cost Abstractions" and there's this interesting insight:
https://youtu.be/rHIkrotSwcc?t=1041
The spoiler is already in the title (sorry!), which is that passing
std::unique_ptr by value is more expensive than passing
On Friday, August 16, 2019 at 4:19:20 PM UTC+10, Henri Sivonen wrote:
> This week, I wrote some code that made me wish we already had support
> for structured bindings and return by initializer list (both from
> C++17) for mozilla::Tuple.
>
> That is, if we have
> mozilla::Tuple Foo()
> it would b
On Wednesday, July 10, 2019 at 9:12:23 AM UTC+10, Bobby Holley wrote:
> On Tue, Jul 9, 2019 at 3:23 PM Mike Hommey wrote:
>
> > 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:
> &
e?
Thanks,
Gerald
On Thursday, July 4, 2019 at 3:11:27 PM UTC+10, Gerald Squelart wrote:
> Recently I coded something with a not-very-important slow-changing
> rarely-used positive number: `unsigned mGeneration;`
> My reviewer commented: "Please use a type with an explicit s
(Glad I started this discussion; thank you Nathan for the enlightening links, I
need to review all my code now!)
Jeff, maybe what we need is a new value type that advertizes that it's
unsigned, but doesn't have the unwanted 2^N wrapping (and its effects on
bug-finding tools and compiler optimiz
On Thursday, July 4, 2019 at 4:53:34 PM UTC+10, Boris Zbarsky wrote:
> On 7/4/19 10:11 PM, Gerald Squelart wrote:
> > - I found plenty of `unsigned`s around, more than `uint32_t`s.
>
> How many are in code that predates the ability to use uint32_t, though?
I didn't do deeper
Recently I coded something with a not-very-important slow-changing rarely-used
positive number: `unsigned mGeneration;`
My reviewer commented: "Please use a type with an explicit size, such as
uint32_t. (General mozilla style; you don't see a bare "unsigned" around much)"
I had never heard of th
On Tuesday, November 29, 2016 at 5:03:17 AM UTC+11, Gregory Szorc wrote:
> > On Nov 27, 2016, at 14:46, Gerald Squelart wrote:
> >
> >> On Saturday, November 26, 2016 at 3:59:05 AM UTC+11, Ralph Giles wrote:
> >> On Fri, Nov 25, 2016 at 7:48 AM, Andrew Halbersta
On Saturday, November 26, 2016 at 3:59:05 AM UTC+11, Ralph Giles wrote:
> On Fri, Nov 25, 2016 at 7:48 AM, Andrew Halberstadt
> wrote:
>
> > For anyone confused by this, the binaries are downloaded to ~/.cargo/bin
> > and adding this directory to your $PATH should fix the issue. The
> > bootstrap
On Friday, October 7, 2016 at 6:49:53 PM UTC+11, Gian-Carlo Pascutto wrote:
> Hi all,
>
> the next Nightly build will have a significantly tightened Linux
> sandbox. Writes are no longer allowed except to shared memory (for IPC),
> and to the system TMPDIR (and we're eventually going to get rid of
On Thursday, September 22, 2016 at 5:58:58 PM UTC+10, Paul Adenot wrote:
> On Thu, Sep 22, 2016, at 07:33 AM, Gerald Squelart wrote:
> > Sitting on the shoulders of giants, an idea, in the unlikely case it's
> > not been thought of yet:
> > How about an assertion tha
On Thursday, September 22, 2016 at 2:58:46 PM UTC+10, Daniel Holbert wrote:
> On 09/21/2016 08:41 PM, Samael Wang wrote:
> > The NS_ASSERTION document [1] says "Don't use NS_ASSERTION", which could be
> > a bit confusing that now some of the similar named macros may be deprecated
> > but some are
On the build-time vs static analysis point:
I'd much prefer to have errors pointed out right from './mach build', which I
can fix on the spot; rather than wait hours until I notice static analysis
errors on a treeherder build.
(e.g., I always forget explicit/MOZ_IMPLICIT!)
Unless we can get cro
On Thursday, July 14, 2016 at 6:51:21 AM UTC+10, Benjamin Smedberg wrote:
> I'd like to welcome Chenxia Liu, François Marier, and Rebecca Weiss as
> peers of Firefox Data Stewardship, joining Ally and myself. I'm excited to
> bring a selection of people from across the organization who are familiar
On Saturday, July 9, 2016 at 12:57:31 PM UTC+10, Boris Zbarsky wrote:
> On 7/8/16 7:25 PM, Gerald Squelart wrote:
> > The annotate (aka blame) functionality of hg.mozilla.org can point at one
> > line
>
> Yes, I know. What it can't do is highlight some set of lines c
On Saturday, July 9, 2016 at 7:21:24 AM UTC+10, Boris Zbarsky wrote:
> On 7/8/16 4:18 PM, Steve Fink wrote:
> > Are either mxr or dxr really the right thing for canonical links to our
> > source code? As long as we're updating links, through one means or
> > another, temporarily or permanently, cou
On Monday, May 2, 2016 at 9:49:24 AM UTC+10, Jim Blandy wrote:
> No, we don't know that [moved-from strings become empty].
> The contract of a move in C++ is simply that the
> source object is safe to destruct, but otherwise in an undefined state*. You
> must not make any assumptions about its valu
On Friday, June 17, 2016 at 3:57:01 PM UTC+1, Gerald Squelart wrote:
> On Friday, June 17, 2016 at 2:31:15 PM UTC+1, smaug wrote:
> > On 06/16/2016 06:40 PM, smaug wrote:
> > > On 05/24/2016 08:33 AM, jw...@mozilla.com wrote:
> > >> For
> > >>
>
On Friday, June 17, 2016 at 2:31:15 PM UTC+1, smaug wrote:
> On 06/16/2016 06:40 PM, smaug wrote:
> > On 05/24/2016 08:33 AM, jw...@mozilla.com wrote:
> >> For
> >>
> >> RefPtr GetFoo() {
> >>RefPtr foo;
> >>// ...
> >> }
> >>
> >> should we:
> >>
> >> 1. return foo and expect RVO to kick i
Coincidentally: (?)
https://bugzilla.mozilla.org/show_bug.cgi?id=1280296
"remove already_AddRefed"
:-)
For your original question, I would vote for RVO when possible, and Move()
otherwise.
It feels like static analysis should be able to detect cases where RVO is
possible and suggest it if miss
On Monday, May 2, 2016 at 9:49:24 AM UTC+10, Jim Blandy wrote:
> 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
On Saturday, April 30, 2016 at 9:43:46 AM UTC+10, Gerald Squelart wrote:
> On Friday, April 29, 2016 at 2:15:03 PM UTC+10, Jim Blandy wrote:
> > On Thu, Apr 28, 2016 at 8:22 PM, wrote:
> >
> > > Jim Blandy於 2016年4月28日星期四 UTC+8下午1時51分15秒寫道：
> > > > I do
On Friday, April 29, 2016 at 2:15:03 PM UTC+10, Jim Blandy wrote:
> On Thu, Apr 28, 2016 at 8:22 PM, 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 mo
On Friday, April 29, 2016 at 8:04:46 PM UTC+10, Nicholas Nethercote wrote:
> On Fri, Apr 29, 2016 at 10:25 AM, Nicholas Nethercote
> wrote:
> >
> > I just landed on inbound the patches in bug 1267550, which renamed
> > MOZ_WARN_UNUSED_RESULT as MOZ_MUST_USE.
> >
> > A shorter name was in order bec
pen, but not necessarily.
> On 2016-04-28 9:52 AM, Gerald Squelart wrote:
> > Anyway, how about this:
> > - mozilla::Move() is reserved for expected moves, and *any* re-use after
> > that is considered an error.
> > - We introduce something like mozilla::MakeAvailableForMove(),
On Thursday, April 28, 2016 at 11:25:38 AM UTC+10, Ehsan Akhgari wrote:
> On 2016-04-28 9:00 AM, Gerald Squelart wrote:
> > On Thursday, April 28, 2016 at 10:41:21 AM UTC+10, Ehsan Akhgari wrote:
> >> On 2016-04-28 8:00 AM, Gerald Squelart wrote:
> >>> On Thursday, Ap
On Thursday, April 28, 2016 at 11:00:12 AM UTC+10, Gerald Squelart wrote:
> On Thursday, April 28, 2016 at 10:41:21 AM UTC+10, Ehsan Akhgari wrote:
> > On 2016-04-28 8:00 AM, Gerald Squelart wrote:
> > > On Thursday, April 28, 2016 at 9:35:56 AM UTC+10, Kyle Huey wrote:
> &
On Thursday, April 28, 2016 at 10:41:21 AM UTC+10, Ehsan Akhgari wrote:
> On 2016-04-28 8:00 AM, Gerald Squelart wrote:
> > On Thursday, April 28, 2016 at 9:35:56 AM UTC+10, Kyle Huey wrote:
> >> Can we catch this pattern with a compiler somehow?
> >>
> >> Foo
On Thursday, April 28, 2016 at 9:35:56 AM UTC+10, Kyle Huey wrote:
> Can we catch this pattern with a compiler somehow?
>
> Foo foo;
> foo.x = thing;
> DoBar(mozilla::Move(foo));
> if (foo.x) { /* do stuff */ }
>
> - Kyle
Definitely something that would be nice.
But if we have/implement such a
On Saturday, April 23, 2016 at 6:25:36 AM UTC+10, Gregory Szorc wrote:
> Visual Studio 2015 Update 2 was released just days after we switched
> automation from VS2013 to VS2015 Update 1. We know we were going to take
> Update 2 eventually and we didn't want to run a Windows toolchain for as
> short
On Thursday, April 21, 2016 at 4:33:40 PM UTC+10, Nicholas Nethercote wrote:
> On Thu, Apr 21, 2016 at 4:19 PM, Xidorn Quan wrote:
> >>
> >> Maybe you're referring to factory methods, like this:
> >>
> >> static T* T::New();
> >>
> >> which would return null on failure. Such methods can be usefu
On Thursday, April 21, 2016 at 11:15:10 AM UTC+10, Nicholas Nethercote wrote:
> Hi,
>
> C++ constructors can't be made fallible without using exceptions. As a result,
> for many classes we have a constructor and a fallible Init() method which must
> be called immediately after construction.
>
> E
On Friday, March 18, 2016 at 2:07:34 PM UTC+11, jww...@mozilla.com wrote:
> https://hg.mozilla.org/mozilla-central/file/3e04659fdf6aef792f7cf9840189c6c38d08d1e8/mfbt/UniquePtr.h#l182
>
> "To unconditionally transfer ownership of a UniquePtr into a method, use a
> |UniquePtr| argument. To conditi
On Monday, October 19, 2015 at 11:09:46 AM UTC+11, Eric Rescorla wrote:
> On Sun, Oct 18, 2015 at 4:14 PM, Nicholas Nethercote
> wrote:
>
> > On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla wrote:
> > >
> > > What's needed here is a dependency management system that
> > > simply builds what's neede
On Friday, September 18, 2015 at 3:55:27 AM UTC+10, Andrew McCreight wrote:
> On Thu, Sep 17, 2015 at 7:42 AM, Andrew McCreight
> wrote:
> >
> > On Thu, Sep 17, 2015 at 5:31 AM, Gerald Squelart
> > wrote:
> >
> >> Good stuff!
> >>
> >> I hop
Good stuff!
I hope you'll consider tracking AddRef's and Release's as well.
I recently experimented with that for a troubled RefCounted class [1], and it
was very useful to find which AddRef didn't have its corresponding Release.
Cheers,
Gerald
[1] https://hg.mozilla.org/try/rev/8dffaf0d2acf
_
Will there be a blanket change sometime soon?
If not, are we supposed to start using the new style in patches now, even when
it would clash with nearby old-style overrides/finals in the same file or in
the same directory?
___
dev-platform mailing list
41 matches
Mail list logo
