Below is a highlight of all work the build peers have done in the last few
weeks as part of their work to modernise the build infrastructure.
Since the last report[1] a large number of improvements have landed in
Mozilla Central.
The build peers have landed support for a new construct in python c
The patch has been backed out because of the merge. To be continued on next
Monday.
More info about the back-out:
https://bugzilla.mozilla.org/show_bug.cgi?id=1303113#c9
-Gabor
On Thu, Nov 10, 2016 at 1:29 AM, Blake Kaplan wrote:
> Hello everyone,
>
> We've been working on the e10s-multi projec
Take the following code example:
someCondition = false;
async function onClick(event) {
if (someCondition) {
await Promise.resolve(); // Or any other async function.
}
event.stopPropagation();
}
let called = false;
onClick({ stopPropagation: () => called = true })
Ok. My usecase is the reimplementation of OS.File in Rust, which should
be pretty straightforward and shave a few Mb of RAM and possibly a few
seconds during some startups. The only difficulty is the actual JS
binding. I believe that the only DOM object involved would be Promise,
I'll see how trick
On 10/11/2016 00:22, smaug wrote:
> Parent process doesn't yet have higher priority handling [2].
> Need to fix racy tests first.
> Locally using higher priority also in parent process seems to make tab
> throbber smoother.
We have an ad-hoc mechanism for scheduling memory pressure event ahead
of
On this update we will look at the progress made in the last two weeks.
This quarter’s main focus is on improving end to end times on Try (Thunder
Try project).
Thunder Try - Improve end to end times on try
-
Project #1 - Artifact builds on automation
On 11/10/16 4:53 AM, David Teller wrote:
I believe that the only DOM object involved would be Promise
Note that Promise isn't really a DOM object anymore. It's a
SpiderMonkey thing.
We still have dom::Promise as a way to create a nice C++-friendly API
around Spidermonkey Promises. But not
On 11/10/16 7:25 AM, Paolo Amadini wrote:
Is it a deliberate choice that the first chunk of an async function is
executed synchronously instead of waiting for the next microtask?
In terms of implementation or specification?
In terms of implementation, I think it's deliberate in the sense of
f
On 10/11/2016 18:12, smaug wrote:
> vsync handling happens usually right after a task (per HTML spec).
> Basically we have now two event queues with similar priority, and they
> are handled the same priority, but since
> the other one is used very rarely, events added to it get processed on
> avera
9 matches
Mail list logo
