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
Promise.any is an inverse of Promise.all, right? There and back again:
Promise.all(promises.map(p => p.then(r => Promise.reject(r), e => e)))
.then(r => Promise.reject(r), e => e)
https://jsfiddle.net/jib1/f085bcyk/
That said, Promise.any has a nice ring to it.
.: Jan-Ivar :.
On 10/30/19 6:
In order to support moving more of our frontend to HTML, I'd like to propose
that we change the way `hidden` and `collapsed` attributes and properties work
on XUL elements and rewrite frontend consumers to adapt.
Currently, hidden and collapsed in XUL behave like:
* Only a value of true hides or
Yes, it would have been clever of me to predict the semantics 3 years
ago. ;-)
But as I mention in the stackoverflow post, depending on context and the
type(s) of values expected, errors can often be distinguished easily
enough in practice, if not in general.
That said, I've never actually h
On 10/30/19 6:19 PM, Jan-Ivar Bruaroey wrote:
This always seemed trivial to me to do with:
Promise.all(promises.map(p => p.catch(e => e)))
This has different semantics from Promise.allSettled, right? In
particular, it effectively treats rejected promises as resolved with the
rejection
On Wed, Oct 30, 2019 at 5:20 PM Jan-Ivar Bruaroey wrote:
> This always seemed trivial to me to do with:
>
> Promise.all(promises.map(p => p.catch(e => e)))
>
I guess it depends on your definition of "trivial". If everyone knows de
Morgan's laws, we don't need *both* `||` and `&&` operators.
Every new primitive is a nail in the coffin of the next attempt to build a
new competitive web browser.
(Distraught voice: "Won't they think of the Servos?!?")
On Wed, Oct 30, 2019 at 3:20 PM Jan-Ivar Bruaroey wrote:
> This always seemed trivial to me to do with:
>
> Promise.all(promises.m
This always seemed trivial to me to do with:
Promise.all(promises.map(p => p.catch(e => e)))
https://stackoverflow.com/questions/31424561/wait-until-all-promises-complete-even-if-some-rejected/36115549#36115549
But I guess it's too late to make that point. I guess the more
primitives the m
Thanks for the clarification, Olli. We're in a bit of a transition process
of moving the addon's implementation into mozilla central with a direct
integration. I'll try to prioritize finishing up that transition as it's a
bit confusing as new features are landing in the popup, but not in the
addon
FWIW, apparently the UI is in the devtools profiler UI, not in the profiler
addon.
https://profiler.firefox.com/ still tells users to install the addon from there.
I was told that one can get the button similar to the addon by enabling
devtools.performance.popup.enabled boolean pref and then usi
In Firefox 71, we'll ship Promise.allSettled, a standard way to `await`
several promises at once. André Bargull [:anba] contributed the
implementation of this feature. It's in Nightly now.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1539694
Shipped in: https://bugzilla.mozilla.org/show_bug.c
Recently, we landed a new feature for the Firefox Profiler: the ability
to record IPC messages for monitored threads. This should be useful for
evaluating IPC-related performance issues as we make progress on Project
Fission. To enable this feature, just check the "IPC Messages" feature
in the
On Wed, Oct 30, 2019 at 8:47 AM Nathan Froyd wrote:
> On Wed, Oct 30, 2019 at 11:36 AM Tom Ritter wrote:
> >
> > I will claim that the most common behavior of developers is to leave
> > XPCOM_DEBUG_BREAK alone and not set it to any particular value. I bet
> most
> > people haven't even heard of
On Wed, Oct 30, 2019 at 11:36 AM Tom Ritter wrote:
>
> I will claim that the most common behavior of developers is to leave
> XPCOM_DEBUG_BREAK alone and not set it to any particular value. I bet most
> people haven't even heard of this or know what it does.
>
> With that env var unset, in Debug m
I will claim that the most common behavior of developers is to leave
XPCOM_DEBUG_BREAK alone and not set it to any particular value. I bet most
people haven't even heard of this or know what it does.
With that env var unset, in Debug mode, NS_ASSERTION will print to stderr
and otherwise do nothing
The Firefox Profiler has been getting some new memory tooling support to
help diagnose memory issues. In the past few weeks we have support for
native (C++, Rust) memory allocation tracking. The new tooling works with
the existing profiler UI, like the call tree, and flame graph. In addition,
the m
On Tue, Oct 29, 2019 at 9:45 PM Marcos Caceres wrote:
> Thanks Steve... so it does really sound like perhaps just investing in more
> individual computing power might be the way to go. I think that's ok... even
> if it means, in my own case, personally paying the extra "Apple Tax" for a
> Mac
Hi all,
when dealing with builds on slower machines I usually run a build every
morning (4AM) so that when I wake up I've got it ready (together with a
warm cache) and following builds won't be as bad.
This can be done easily on a Mac by setting up a cronjob that will run a
build on a freshly upd
> On 29. Oct 2019, at 18:53, Steve Fink wrote:
>
> On 10/28/19 9:17 PM, Marcos Caceres wrote:
>> On Tuesday, October 29, 2019 at 3:27:52 AM UTC+11, smaug wrote:
>>> Quite often one has just a laptop. Not compiling tons of Rust stuff all the
>>> time would be really nice.
>>> (I haven't figured o
19 matches
Mail list logo
