Hi,
Machines are getting more cores, web devs want to make use of that opportunity.
We (webdev hat) have WebWorkers, that's cool, but one can only do ~math in
there. It's not possible to update a UI in real time from a WebWorker. It's not
possible to update a canvas or WebGL context either. New
Hi there,
My apologies in case this topic has already been discussed before.
It is well known that one of the biggest bottlenecks in web application
performance are DOM operations. While the recommendation to developers is to
try to not update the DOM and trigger reflows if it is not completel
On 15/01/2014 02:37, Matt Brubeck wrote:
> On 1/13/2014 8:05 PM, Mike Hommey wrote:
>> I hear frontend developers are using it for frontend code, I would like
>> to know if you would be bothered if it were to disappear.
>
> As a front-end developer, I think dumbmake is harmful almost as often as
On 01/12/2014 07:34 PM, Mike Hommey wrote:
Hi,
Let's face it: xulrunner is hardly maintained, we barely build and test
it on automation, and the result is that it is often broken for long
periods of time.
I propose that we just stop pretending, and terminate xulrunner,
considering the following
Having proper support for multi-profile is great, by opposition to the
current "hidden on the command line" support, but I believe that this
discussion deserves its own thread (and its own bug).
Cheers,
David
On 1/16/14 4:13 PM, WaltS wrote:
> User thoughts.
>
> You can close this bug as WONTFI
The Web API documentation meeting is tomorrow at 9 AM Pacific Time.
Everyone's welcome to attend; if you're interested in ensuring that
these APIs are properly documented, we'd love your input.
We have an agenda, as well as details on how to join, here:
https://etherpad.mozilla.org/WebAPI-docs
(Some messages in this thread seem to be taking an absurdly long time to
arrive, so I apologize if what I'm talking about has long been addressed.)
On Thu, Jan 16, 2014 at 2:00 PM, Philip Chee wrote:
> On 15/01/2014 02:37, Matt Brubeck wrote:
> > On 1/13/2014 8:05 PM, Mike Hommey wrote:
> >> I
On 1/16/2014 11:26 AM, Till Schneidereit wrote:
>
> I'd be extremely unhappy if this disappeared without any replacement.
> Changing a cpp file under js/src and running `mach` takes about 2 minutes
> for me, whereas running `mach js/src` takes about 18 seconds.
>
> As one of the people behind the p
(2014/01/16 12:22), Zack Weinberg wrote:
On 2013-11-26 5:40 AM, Neil wrote:
Henri Sivonen wrote:
On Windows, do we really need to pay homage to the pre-NT legacy when
doing Save As? How about we just use UTF-8 for "HTML Page, complete"
reserialization like on Mac?
You'll need a BOM, of cour
On 1/16/14 7:18 AM, David Bruant wrote:
From what I understand, it's already possible to create process-separated
frames [3] which I feel isn't that far away from a parallel iframe
It's pretty far away in Gecko as it stands, because we have all sorts of
global state (class statics, say!) that
On 1/16/14 7:15 AM, Sergi Mansilla wrote:
I still think that automatically batching the changes that DOM operations cause
at the end of the event loop
This is already basically done in Gecko, no? Unless you explicitly
flush out layout or style, we don't actually update them when the DOM
mut
On 1/16/14 12:05 PM, Ted Mielczarek wrote:
Have you tried `mach build binaries`?
That doesn't do the same thing as "mach build dirname", though.
Certainly not for dom/bindings...
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
h
On Thu, Jan 16, 2014 at 6:05 PM, Ted Mielczarek wrote:
> On 1/16/2014 11:26 AM, Till Schneidereit wrote:
> >
> > I'd be extremely unhappy if this disappeared without any replacement.
> > Changing a cpp file under js/src and running `mach` takes about 2 minutes
> > for me, whereas running `mach js
Le jeudi 16 janvier 2014 18:31:59 UTC+1, Boris Zbarsky a écrit :
> It's pretty far away in Gecko as it stands, because we have all sorts of
> global state (class statics, say!) that is not parallel-safe.
>
> Process-separated is likely to be simpler to get to work without pesky
> things like mem
On 1/9/2014 9:47 AM, Gavin Sharp wrote:
> In theory (mine at least), the field is free to be used for planning
> which release you want the bug fixed in, before the bug is fixed.
> After the bug is fixed, it should be used as you describe.
Some groups do use the field this way, for example the NSS
On 1/16/14 11:36 AM, Daniel Veditz wrote:
On 1/9/2014 9:47 AM, Gavin Sharp wrote:
In theory (mine at least), the field is free to be used for planning
which release you want the bug fixed in, before the bug is fixed.
After the bug is fixed, it should be used as you describe.
Some groups do use
On 1/16/14 2:29 PM, David Bruant wrote:
I don't understand the last sentence. Is "memory corruption" referring to the
global state you mentioned before?
Yes.
When you wrote "parallel-safe" above, was that implicitly thread-parallelism?
Yes.
As a web developer, I'm happy with process-sepa
- Original Message -
> From: "David Bruant"
> To: dev-platform@lists.mozilla.org
> Sent: Thursday, January 16, 2014 11:29:59 AM
> Subject: Re: Parallel sandboxed iframes
>
> As a web developer, I'm happy with process-separated if it's easier, at least
> for a first shot, but I can imagine
On 1/16/2014, 3:34 PM, Bill McCloskey wrote:
- Original Message -
From: "David Bruant"
To: dev-platform@lists.mozilla.org
Sent: Thursday, January 16, 2014 11:29:59 AM
Subject: Re: Parallel sandboxed iframes
As a web developer, I'm happy with process-separated if it's easier, at least
f
- Original Message -
> From: "Ehsan Akhgari"
> To: "Bill McCloskey" , "David Bruant"
>
> Cc: dev-platform@lists.mozilla.org
> Sent: Thursday, January 16, 2014 1:45:08 PM
> Subject: Re: Parallel sandboxed iframes
>
> About the front-end breakages, the ongoing e10s work should help with
>
re 80char vs 100chars:
I am for 80 chars.
If the argument for expanding to 100 or more is that screen is getting wider,
then the benefit of wide screen is able to fit multiple terminals in one
window. For normal workflow, I'd split my windows into two or terminals,
depending on what I am doing
21 matches
Mail list logo
