Now I am trying to building a xpcom components, but it have multiple
.idl file to compiled into a single xpt component, how to do that?
I am using XULRunner 31 sdk/bin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On Mon, Aug 11, 2014 at 5:16 PM, Karl Dubost kdub...@mozilla.com wrote:
Jonas,
Le 12 août 2014 à 08:33, Jonas Sicking jo...@sicking.cc a écrit :
However in some cases we can do better than that by loading a template
page that can be used for multiple of the search results.
This I'm not sure
On 2014-08-11, 6:03 PM, Jonas Sicking wrote:
Very exited to see this happening.
Implementation issues aside, I have two comments:
* This is something that we really need on FirefoxOS. I hope that the
implementation strategy will work there too?
Yes, the majority of the code is going to be
On Thursday, August 7, 2014 9:19:09 AM UTC+1, Gian-Carlo Pascutto wrote:
Does this filter on any cpp_guards?
No, it doesn't.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 12 Aug 2014, at 15:33, Benjamin Smedberg benja...@smedbergs.us wrote:
Is it possible to email the people who added/reviewed the probe and let them
know Probe X which you added will be set to expire unless you take action?
I expect that generic announcements to dev.platform won't get the
From now on all alerts will be sent by default also to
telemetry-ale...@mozilla.com.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Just reading bug 1052477, and I'm wondering about what are intentions
are for already_AddRefed.
In that bug it's proposed to change the return type of NS_NewAtom from
already_AddRefed to nsCOMPtr. I don't think that actually saves any
addref/release pairs if done properly, since you'd
On Tue, Aug 12, 2014 at 5:59 PM, Benjamin Smedberg
benja...@smedbergs.us wrote:
Just reading bug 1052477, and I'm wondering about what are intentions are
for already_AddRefed.
In that bug it's proposed to change the return type of NS_NewAtom from
already_AddRefed to nsCOMPtr. I don't think
On Tuesday 2014-08-12 10:59 -0400, Benjamin Smedberg wrote:
Just reading bug 1052477, and I'm wondering about what are
intentions are for already_AddRefed.
In that bug it's proposed to change the return type of NS_NewAtom
from already_AddRefed to nsCOMPtr. I don't think that actually saves
As far as I know, the only downside in replacing already_AddRefed by
nsCOMPtr would be to incur more useless calls to AddRef and Release. In the
case of threadsafe i.e. atomic refcounting, these use atomic
instructions, which might be expensive enough on certain ARM CPUs that this
might matter. So
On Tue, Aug 12, 2014 at 6:14 PM, L. David Baron dba...@dbaron.org wrote:
Bug 967364 did already add assertions to guarantee this.
Yes, if I'm not mistaken, already_AddRefed these days is quite safe.
Two thoughts:
(1) I think it introduces a somewhat major coding style risk, in
that it
On Tue, Aug 12, 2014 at 6:16 PM, Benoit Jacob jacob.benoi...@gmail.com wrote:
As far as I know, the only downside in replacing already_AddRefed by
nsCOMPtr would be to incur more useless calls to AddRef and Release. In the
case of threadsafe i.e. atomic refcounting, these use atomic
On Tuesday 2014-08-12 18:15 +0300, Aryeh Gregor wrote:
1) You can use the return value directly without assigning it to an
nsCOMPtr/nsRefPtr. For instance, pass it to a function that wants a
raw pointer, or compare it against a different value.
I consider this a disadvantage, as I pointed out
On Tuesday 2014-08-12 18:22 +0300, Aryeh Gregor wrote:
On Tue, Aug 12, 2014 at 6:14 PM, L. David Baron dba...@dbaron.org wrote:
Two thoughts:
(1) I think it introduces a somewhat major coding style risk, in
that it makes it possible to accidentally assign the value of a
function that
On 8/12/14 12:08 AM, Yonggang Luo wrote:
Now I am trying to building a xpcom components, but it have multiple
.idl file to compiled into a single xpt component, how to do that?
Here is the code the build system uses for XPIDLs:
This templated prerendereing sounds like a complicated API. Is there any
advantage of this over what is possible today with a single page
application using history.pushState?
Den 12-08-2014 kl. 00:03 skrev Jonas Sicking:
Very exited to see this happening.
Implementation issues aside, I have
On Tue, Aug 12, 2014 at 6:25 PM, L. David Baron dba...@dbaron.org wrote:
On Tuesday 2014-08-12 18:15 +0300, Aryeh Gregor wrote:
1) You can use the return value directly without assigning it to an 4) If
the callee already holds a strong reference in a local variable,
it can just return that
On Tuesday 2014-08-12 18:40 +0300, Aryeh Gregor wrote:
On Tue, Aug 12, 2014 at 6:29 PM, L. David Baron dba...@dbaron.org wrote:
This is done very commonly when we know some other data structure
(or the lifetime of |this|) owns the object, and will continue to
across the lifetime of the
The server-side Mercurial hooks living in
https://hg.mozilla.org/hgcustom/hghooks/ have been migrated to the
hghooks/ directory of
https://hg.mozilla.org/hgcustom/version-control-tools/.
This change will enable:
* Code/hook sharing between client and server (version-control-tools is
already
I'm about to land bug 1046222, which changes the default behaviour of
XPCOM_DEBUG_BREAK on Windows to warn, instead of trap. If run under the
debugger, trap will cause the debugger to stop as if it hit a breakpoint in
debug builds.
This would be useful behaviour if we didn't still have a
On Tuesday, August 12, 2014 11:22:05 AM UTC-4, Aryeh Gregor wrote:
For refcounted types, isn't a raw pointer in a local variable a red
flag to reviewers to begin with? If GetT() returns a raw pointer
today, like nsINode::GetFirstChild() or something, storing the result
in a raw pointer is a
On 2014-08-12, 11:39 AM, Jesper Kristensen wrote:
This templated prerendereing sounds like a complicated API. Is there any
advantage of this over what is possible today with a single page
application using history.pushState?
Yes, I think so. The idea of single page applications is nice, but
On 8/12/2014 9:59 AM, Benjamin Smedberg wrote:
Just reading bug 1052477, and I'm wondering about what are intentions
are for already_AddRefed.
In that bug it's proposed to change the return type of NS_NewAtom from
already_AddRefed to nsCOMPtr. I don't think that actually saves any
On Tue, Aug 12, 2014 at 6:46 PM, L. David Baron dba...@dbaron.org wrote:
In these cases we document that it's likely safe for callers to do
this by having those getters return raw pointers. Getters that
require reference-counting return already_AddRefed. Thus the
designer of the API makes a
On 8/12/2014 12:28 PM, Joshua Cranmer wrote:
But now that nsCOMPtr/nsRefPtr support proper move constructors, is
there any reason for already_AddRefed to exist at all in our
codebase? Could we replace every already_AddRefed return value with a
nsCOMPtr?
The rationale for why we still
On Tue, Aug 12, 2014 at 9:35 AM, Aryeh Gregor a...@aryeh.name wrote:
On Tue, Aug 12, 2014 at 6:46 PM, L. David Baron dba...@dbaron.org wrote:
In these cases we document that it's likely safe for callers to do
this by having those getters return raw pointers. Getters that
require
On Tue, Aug 12, 2014 at 7:12 PM, Vladimir Vukicevic vladi...@pobox.com wrote:
It's unfortunate that we can't create a nsCOMPtr that will disallow
assignment to a bare pointer without an explicit .get(), but will still allow
conversion to a bare pointer for arg passing purposes. (Or can we? I
On Tue, Aug 12, 2014 at 7:37 PM, Benjamin Smedberg
benja...@smedbergs.us wrote:
On 8/12/2014 12:28 PM, Joshua Cranmer wrote:
The rationale for why we still had it was that:
nsIFoo *foobar = ReturnsACOMPtr();
silently leaks.
Really? I thought that in this case there would be no leak
On 8/12/2014 11:12 AM, Vladimir Vukicevic wrote:
It's unfortunate that we can't create a nsCOMPtr that will disallow assignment to a bare
pointer without an explicit .get(), but will still allow conversion to a bare pointer for arg passing
purposes. (Or can we? I admit my C++-fu is not that
On 8/12/2014 11:40 AM, Aryeh Gregor wrote:
On Tue, Aug 12, 2014 at 7:37 PM, Benjamin Smedberg
benja...@smedbergs.us wrote:
On 8/12/2014 12:28 PM, Joshua Cranmer wrote:
The rationale for why we still had it was that:
nsIFoo *foobar = ReturnsACOMPtr();
silently leaks.
Really? I thought that
Hi all,
Apple recently announced changes to how OS X applications must be packaged and
signed
(https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG205)
in order for them to function correctly on OS X 10.9.5 and 10.10. The tl;dr
version
On 2014-08-12, 12:41 PM, Joshua Cranmer wrote:
On 8/12/2014 11:12 AM, Vladimir Vukicevic wrote:
It's unfortunate that we can't create a nsCOMPtr that will disallow
assignment to a bare pointer without an explicit .get(), but will
still allow conversion to a bare pointer for arg passing
The possibility of using JavaScript Object Signing and Encryption (JOSE)
- specifically the verification part of the JSON Web Signature (JWS)
component - came up as part of planning a JavaScript-based feature I'm
working on.
We don't appear to have an implementation in mozilla-central yet.
On 2014-08-12, 11:25 AM, L. David Baron wrote:
On Tuesday 2014-08-12 18:15 +0300, Aryeh Gregor wrote:
1) You can use the return value directly without assigning it to an
nsCOMPtr/nsRefPtr. For instance, pass it to a function that wants a
raw pointer, or compare it against a different value.
+rbarnes is responsible for adding WebCrypto, which includes some JOSE features.
On 2014-08-12, at 10:22, Gregory Szorc g...@mozilla.com wrote:
The possibility of using JavaScript Object Signing and Encryption (JOSE) -
specifically the verification part of the JSON Web Signature (JWS)
On Tuesday, August 12, 2014 1:22:28 PM UTC-4, Gregory Szorc wrote:
The possibility of using JavaScript Object Signing and Encryption (JOSE)
- specifically the verification part of the JSON Web Signature (JWS)
component - came up as part of planning a JavaScript-based feature I'm
On Tuesday, August 12, 2014 8:39:11 AM UTC-7, Jesper Kristensen wrote:
This templated prerendereing sounds like a complicated API. Is there any
advantage of this over what is possible today with a single page
application using history.pushState?
I'm still trying to wrap my head around the
An alternative solution to templates for this use case is the following:
1) In the prerendered page's html, group preloaded resources (LINK
rel=subresource currently) into base and extended hints. This can be
accomplished by a new LINK attribute, for example.
2) The prerenderer can then fetch
On Tue, Aug 12, 2014 at 1:04 PM, Ilya Grigorik igrigo...@gmail.com wrote:
I'm still trying to wrap my head around the use case, but I'm with you on
this so far...
[snip]
It seems like there are two cases to consider here:
(a) You're on a page with the same base template as destination
(b)
Jonas,
thanks for the explanations so far. It helps a lot to understand and sorry for
the naive questions. There is still something I do not get:
Le 13 août 2014 à 07:17, Jonas Sicking jo...@sicking.cc a écrit :
It would be much more practically doable for calendar instead to
prerender a blank
Aryeh Gregor wrote:
2) It's easier to use, as evidenced by the patches in bugs 1015114 and 1052477.
No .forget() is needed, a raw pointer can be returned directly, even things
like do_QueryInterface can be returned directly without a temporary nsCOMPtr
(since the return type creates the
On Wed, Aug 13, 2014 at 4:35 AM, Aryeh Gregor a...@aryeh.name wrote:
On Tue, Aug 12, 2014 at 6:46 PM, L. David Baron dba...@dbaron.org wrote:
In these cases we document that it's likely safe for callers to do
this by having those getters return raw pointers. Getters that
require
One thing to test heavily would be background updates which rely somewhat
on the structure of these files abd directories...
Cheers,
Ehsan
On Aug 12, 2014 1:05 PM, Ben Hearsum bhear...@mozilla.com wrote:
Hi all,
Apple recently announced changes to how OS X applications must be packaged
and
Ben Hearsum wrote:
Apple recently announced changes to how OS X applications must be packaged and
signed
Does this also apply if you run .app/Contents/MacOS/firefox binary
manually rather than opening the .app?
If developers do update their OS to 10.9.5 when it's released, is there
a way
Le 13 août 2014 à 09:13, Jonas Sicking jo...@sicking.cc a écrit :
The goal of prerender is to improve performance when navigating to a
new page.
my understanding too.
I'm talking about doing a full rendering of a template page. I.e. a
normal webpage which the website can then use JavaScript
Yes, this is very much on our radar.
Cheers,
Robert
-Original Message-
From: dev-platform
[mailto:dev-platform-bounces+rstrong=mozilla@lists.mozilla.org] On
Behalf Of Ehsan Akhgari
Sent: Tuesday, August 12, 2014 5:33 PM
To: Ben Hearsum
Cc: dev-platform@lists.mozilla.org
Subject: Re:
On 08/12/2014 04:04 PM, Ilya Grigorik wrote:
In short, seems like this is inventing a derivative single-page app model for
building pages/apps, and that makes me wonder because it doesn't seem to make
it any easier. Everything described here can be achieved with current tools,
but perhaps
On Tue, Aug 12, 2014 at 5:47 PM, Karl Dubost kdub...@mozilla.com wrote:
Le 13 août 2014 à 09:13, Jonas Sicking jo...@sicking.cc a écrit :
The goal of prerender is to improve performance when navigating to a
new page.
my understanding too.
I'm talking about doing a full rendering of a
Just to be clear I have *read*
http://code.google.com/chrome/whitepapers/prerender.html
So my understanding of pretender is based on this whitepaper. :)
Le 13 août 2014 à 10:09, Jonas Sicking jo...@sicking.cc a écrit :
And what would be the fallback for non JS user agents (cue accessibility and
On Tue, Aug 12, 2014 at 6:53 PM, Karl Dubost kdub...@mozilla.com wrote:
Le 13 août 2014 à 10:09, Jonas Sicking jo...@sicking.cc a écrit :
And what would be the fallback for non JS user agents (cue accessibility
and HTTP scripting here)?
The same as any other time when prerendering is used.
On 8/12/14, 8:46 PM, Cameron McCormack wrote:
Ben Hearsum wrote:
Apple recently announced changes to how OS X applications must be
packaged and signed
Does this also apply if you run .app/Contents/MacOS/firefox binary
manually rather than opening the .app?
As best as I can tell, no. You
Aryeh Gregor writes:
The compiler is required to use the move constructor (if one exists)
instead of the copy constructor when constructing the return value of
a function, and also when initializing an object from the return value
of a function, or assigning the return value of a function.
I would prefer a public list available over NNTP like
mozilla.dev.tree-management so I don't have to get the large volume of
mail in my inbox.
MattN
On 8/12/14 5:17 PM, Gavin Sharp wrote:
What does that alias point to? Seems to me a public mailman mailing
list would be a better choice, since
53 matches
Mail list logo
