On 31/10/2014 22:21, Ehsan Akhgari wrote:
>> a) Landing code to inbound, fx-team, aurora, etc
>
> I have the following git alias:
>
> hgp = show -M -C --binary --full-index --format=\"From: %an
> <%ae>%nSubject: %s%n%n%b\" -U8
>
> And my workflow for landing code is like this:
>
> $ cd /path/
On 31/10/2014 13:48, Gregory Szorc wrote:
> Does anyone use hg-git (it has gotten *much* faster in the past year
> thanks to Facebook's investment)?
In order to submit a patch (or is it called a pull request) to the
Addon-SDK I installed hggit (since all my other workflows are Hg).
Pulling and pu
Mike Hommey schrieb:
The only way to generate them is to run firefox. Well, there are other
ways, but I don't think adding parts of the js engine and gecko to the
installer is really a great idea.
Could the installer run the Firefox binary in some mode that would just
generate those files and
The differences are as follows:
- DOM Promise don't implement Promise.defer;
- the scheduling of asynchronous tasks will sometimes be different.
If you rely on neither, you should be ok. Task.jsm will be migrated to
DOM Promise once we are satisfied that it doesn't break anything on m-c.
Cheers,
On Saturday, November 1, 2014 12:50:24 PM UTC-7, Kyle Huey wrote:
> On Sat, Nov 1, 2014 at 12:42 PM, wrote:
> > The reviewer should understand asynchronous Promise operations, preferably
> > the OS.File promises
>
> We shouldn't be landing new code that uses Promise.jsm in mozilla-central.
>
>
>
> Are we using the discrete GPU when Chrome is not?
That was my first guess as well. As far as I can tell we fall back to
integrated GPU just fine, according to the Activity Monitor. Even App Nap seems
to work when FF is occluded. Yet, our avg energy impact is 5x of Chrome.
Andreas
>
> - K
On Sat, Nov 1, 2014 at 12:47 PM, Andreas Gal wrote:
>
> I am using Nightly on Yosemite and power use is pretty atrocious. The battery
> menu tags Firefox Nightly as a significant battery hog, and I can confirm
> this from the user experience perspective as well. My battery time is a
> fraction
On Sat, Nov 1, 2014 at 12:42 PM, wrote:
> The reviewer should understand asynchronous Promise operations, preferably
> the OS.File promises
We shouldn't be landing new code that uses Promise.jsm in mozilla-central.
- Kyle
___
dev-platform mailing lis
I am using Nightly on Yosemite and power use is pretty atrocious. The battery
menu tags Firefox Nightly as a significant battery hog, and I can confirm this
from the user experience perspective as well. My battery time is a fraction of
using Chrome for the same tasks.
Not every kind of content
In a couple weeks I'll be doing some work on Firefox-as-a-platform-SDK
(replacement for XULRunner) and addon infrastructure work. Part of that latter
bit would be support for asynchronous file operations in the AddonManager.
The file operations, however, have to be revertable in the face of an
Current source code:
http://sourceforge.net/p/verbosio/templates/code/ci/default/tree/src/transactions/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Gregory Szorc writes:
> I'm trying to learn more about how the people who use Git for
> Firefox/Gecko development manage interacting with repositories that
> have their canonical home in Mercurial (mozilla-central, Try,
> etc). I'm doing this to ensure the replacement Try architecture will
> be u
在 2014年11月1日星期六UTC+8下午5时58分46秒，Bobby Holley写道：
> I think you're probably out of luck - the method was de-COMed, and is now
> not accessible from external C++ code.
>
> In generally, using nsIDOM* interfaces from external applications is
> explicitly not supported. If you want to do DOM stuff, you
I think you're probably out of luck - the method was de-COMed, and is now
not accessible from external C++ code.
In generally, using nsIDOM* interfaces from external applications is
explicitly not supported. If you want to do DOM stuff, you should do so
from JS, and communicate with your JS code u
在 2014年11月1日星期六UTC+8下午4时40分57秒，David Rajchenbach-Teller写道：
> I believe that the methods have migrated to
>
> http://dxr.mozilla.org/mozilla-central/source/dom/xslt/xpath/XPathResult.h?from=XPathResult#47
>
> Cheers,
> David
>
> On 01/11/14 08:43, fuller...@gmail.com wrote:
> > Hi,
> >
> > Xulr
I believe that the methods have migrated to
http://dxr.mozilla.org/mozilla-central/source/dom/xslt/xpath/XPathResult.h?from=XPathResult#47
Cheers,
David
On 01/11/14 08:43, fuller...@gmail.com wrote:
> Hi,
>
> Xulrunner 33.x is different from the former releases. I cannot compile my C++
> XPCO
Hi,
Xulrunner 33.x is different from the former releases. I cannot compile my C++
XPCOMs because the new interface of nsIDOMXPathResult has not the methods to
get the values.
What should I do?
___
dev-platform mailing list
dev-platform@lists.mozilla.o
17 matches
Mail list logo
