On 08/12/2014 10:06 AM, Ehsan Akhgari wrote:
> It could also be solved with making operator T*() explicit, but neither of
> these options are something that we can use in our code base today.
So at risk of adding yet another flavor of thing: why not introduce an
already_AddRefed sort of struct t
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
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.
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.
On Tue, Aug 12, 2014 at 6:53 PM, Karl Dubost wrote:
> Le 13 août 2014 à 10:09, Jonas Sicking 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. The fallback
>> would simp
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 a écrit :
>> And what would be the fallback for non JS user agents (cue accessibility and
>> HTTP script
On Tue, Aug 12, 2014 at 5:47 PM, Karl Dubost wrote:
>
> Le 13 août 2014 à 09:13, Jonas Sicking 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
>> nor
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 coul
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: U
Le 13 août 2014 à 09:13, Jonas Sicking 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 to mutate
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 t
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" wrote:
> Hi all,
>
> Apple recently announced changes to how OS X applications must be packaged
> and signed (
> https
On Wed, Aug 13, 2014 at 4:35 AM, Aryeh Gregor wrote:
> On Tue, Aug 12, 2014 at 6:46 PM, L. David Baron 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_A
What does that alias point to? Seems to me a public mailman mailing
list would be a better choice, since then people can
subscribe/unsubscribe on their own.
Gavin
On Tue, Aug 12, 2014 at 7:57 AM, wrote:
> From now on all alerts will be sent by default also to
> telemetry-ale...@mozilla.com.
>
On Tue, Aug 12, 2014 at 4:18 PM, Karl Dubost wrote:
> 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 a écrit :
>> It would be much more practically do
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 temp
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 a écrit :
> It would be much more practically doable for calendar instead to
> prerender a blank search result
On Tue, Aug 12, 2014 at 1:04 PM, Ilya Grigorik 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) You're navigati
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 fetc
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
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
>
>
+rbarnes is responsible for adding WebCrypto, which includes some JOSE features.
On 2014-08-12, at 10:22, 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
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.
I
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. I'm
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 purpo
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 8/12/2014 11:40 AM, Aryeh Gregor wrote:
On Tue, Aug 12, 2014 at 7:37 PM, Benjamin Smedberg
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 wou
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 Tue, Aug 12, 2014 at 7:37 PM, Benjamin Smedberg
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 because the
> (
On Tue, Aug 12, 2014 at 7:12 PM, 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
On Tue, Aug 12, 2014 at 9:35 AM, Aryeh Gregor wrote:
> On Tue, Aug 12, 2014 at 6:46 PM, L. David Baron 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_AddRe
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 h
On Tue, Aug 12, 2014 at 6:46 PM, L. David Baron 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 choice about w
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
addref/rele
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 it
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
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
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
On Tuesday 2014-08-12 18:40 +0300, Aryeh Gregor wrote:
> On Tue, Aug 12, 2014 at 6:29 PM, L. David Baron 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 function.
> >
>
On Tue, Aug 12, 2014 at 6:25 PM, 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>> 4) If
>> the callee already holds a strong reference in a local variable,
>> it can just return that reference i
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 t
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:
http://dxr.mozilla.org/mozilla-central/source/python/mozbuild/mozb
On Tuesday 2014-08-12 18:22 +0300, Aryeh Gregor wrote:
> On Tue, Aug 12, 2014 at 6:14 PM, L. David Baron 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 return
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 o
On Tue, Aug 12, 2014 at 6:16 PM, Benoit Jacob 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 instructions,
> which might be
On Tue, Aug 12, 2014 at 6:14 PM, L. David Baron 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 makes it possibl
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. S
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 sav
On Tue, Aug 12, 2014 at 5:59 PM, 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
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 typicall
>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
On 12 Aug 2014, at 15:33, Benjamin Smedberg 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 attention
> of t
On 8/12/2014 10:26 AM, rviti...@mozilla.com wrote:
We are planning to forcefully set the expiration version of many outstanding
probes, i.e. those that don't have yet an explicitly set expiration, to version
40.
Please have a look at bug 1045108 and comment if you are against it or if you
wa
We are planning to forcefully set the expiration version of many outstanding
probes, i.e. those that don't have yet an explicitly set expiration, to version
40.
Please have a look at bug 1045108 and comment if you are against it or if you
want us to don't set an expiration version for your prob
On Wednesday, August 6, 2014 9:12:07 PM UTC+1, Jim (Ningjie) Chen wrote:
> Looks great! Is the system specific to histograms or can it be adapted to
> other telemetry measurements?
>
>
>
> Looking at the dashboard, we have a growing list of telemetry measurements
> outside of histograms (hangs
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 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 sha
On Mon, Aug 11, 2014 at 5:16 PM, Karl Dubost wrote:
> Jonas,
>
> Le 12 août 2014 à 08:33, Jonas Sicking 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 to understand how that wou
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
https://lists.mozilla.org
59 matches
Mail list logo
