The next MemShrink meeting will be brought to you by the Shumway Benchmark:
http://www.areweflashyet.com/
The wiki page for this meeting is at:
https://wiki.mozilla.org/Performance/MemShrink
Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approa
On 7/23/2013 6:52 AM, Ralph Giles wrote:
On 13-07-22 7:40 AM, lchenneb...@gmail.com wrote:
When do you think it will be released?
Maybe in Firefox 26 or 27. I have a working patch, but am struggling to
find time to finish it up.
Chris P.
___
d
On Mon, Jul 22, 2013 at 12:46 PM, Benjamin Smedberg
wrote:
> On 7/22/2013 3:01 PM, Rob Arnold wrote:
>
>>
>> Wouldn't disallowing this implicit conversion break code which does
>>
>>void UseFoo(nsIFoo* foo);
>>
>>nsCOMPtr foo;
>>UseFoo(foo);
>>
>> ? That is an extremely common idiom i
Gecko 24, https://bugzilla.mozilla.org/show_bug.cgi?id=872421
On Mon, Jul 22, 2013 at 9:53 AM, Jorge Villalobos wrote:
> On 7/19/13 3:21 AM, David Rajchenbach-Teller wrote:
>> This is a short announcement: chrome workers now support modules. For
>> your future developments involving chrome worker
On 7/22/2013 3:01 PM, Rob Arnold wrote:
Wouldn't disallowing this implicit conversion break code which does
void UseFoo(nsIFoo* foo);
nsCOMPtr foo;
UseFoo(foo);
? That is an extremely common idiom in our code.
That idiom seems dangerous by itself; the assumption it makes is that th
On 7/22/2013 1:59 AM, Justin Lebar wrote:
It seems really dangerous that there is an implicit conversion from a strong
ref ptr to a weak pointer. With C++11, you can thankfully require this
conversion to be explicit which should alleviate your concern.
Wouldn't disallowing this implicit conversi
On 13-07-22 7:40 AM, lchenneb...@gmail.com wrote:
> When do you think it will be released?
Fixes are generally released 12-18 weeks after the corresponding bug is
fixed. I don't know when that bug will be resolved, but you can add
yourself to the cc list (if you have a bugzilla account) if you wa
On 13-07-22 10:30 AM, Ehsan Akhgari wrote:
> That's not possible in C++11. Thinking about this more, the reason that
> this works fine for std::shared_ptr is the fact that it does _not_ have
> a T* implicit conversion operator. Therefore, we can't switch to rvalue
> references to replace already_
On Sun, Jul 21, 2013 at 11:59 PM, Justin Lebar wrote:
> > It seems really dangerous that there is an implicit conversion from a
> strong
> > ref ptr to a weak pointer. With C++11, you can thankfully require this
> > conversion to be explicit which should alleviate your concern.
>
> Wouldn't disall
Last week we enabled mozharness for talos on the try server and we have
resolved all found issues since then. The issues were related to proper
integration with tbpl and talos's try support.
We will switch talos jobs to be driven by mozharness rather than through
buildbot by Wednesday morning
Do you use Mercurial to interact with mozilla-central and related
repositories? I wrote an extension to make your life easier.
* Easily manage unified Mercurial repositories (like the Git mirror)
* hg tbpl (open TBPL for a changeset)
* hg treestatus
* hg pull fx-team
* hg clone inbound
* hg up e
On 2013-07-22 2:59 AM, Justin Lebar wrote:
It seems really dangerous that there is an implicit conversion from a strong
ref ptr to a weak pointer. With C++11, you can thankfully require this
conversion to be explicit which should alleviate your concern.
Wouldn't disallowing this implicit conver
On Mon, Jul 22, 2013 at 6:45 AM, wrote:
> I'm working on a html 5 interactive player that 100% compatible with
> Chrome from XP to Window 8.
> I Saw that the support of mp3 and mp4 has been introduced in firefox on
> v21 for win 7 and v22 for Vista.
>
> Do you consider to port these formats on Wi
On 7/22/13 10:45 AM, Andrea Marchesini wrote:
I know that we don't want to convert all the existing interfaces to WebIDL, but
I still think this report is useful to choose which interface is available to
be converted.
I think it would be useful to have a report like this but restricted to
ns
On 7/19/13 3:21 AM, David Rajchenbach-Teller wrote:
> This is a short announcement: chrome workers now support modules. For
> your future developments involving chrome workers, please make use of
> the module system.
>
> All the documentation may be found here:
>
> https://developer.mozilla.org/e
On Mon, Jul 22, 2013 at 7:45 AM, Andrea Marchesini
wrote:
> Hi all,
>
> this is my first email here. wow.
> I'm writing this email because I spent several months converting IDL
> components to WebIDL.
> It's hard to find how many components have been converted, what is still
> missing, etc, etc.
>
On 7/22/2013 4:40 AM, Neil wrote:
Robert O'Callahan wrote:
On Mon, Jul 22, 2013 at 3:58 PM, L. David Baron
wrote:
Is the idea here that nsRefPtr/nsCOMPtr/etc. would have move
constructors, and we'd just return them, and the move constructors
plus return value optimizations would take care
Hi all,
this is my first email here. wow.
I'm writing this email because I spent several months converting IDL components
to WebIDL.
It's hard to find how many components have been converted, what is still
missing, etc, etc.
So I wrote this:
https://people.mozilla.com/~amarchesini/code/idl2webi
On Tuesday, July 16, 2013 2:24:47 PM UTC-4, Ralph Giles wrote:
> On 13-07-16 11:15 AM, Ludovic Chenneberg wrote:
>
> > I'm working on a html 5 interactive player that 100% compatible with Chrome
> > from XP to Window 8.
>
> > I Saw that the support of mp3 and mp4 has been introduced in firefox o
I'm working on a html 5 interactive player that 100% compatible with Chrome
from XP to Window 8.
I Saw that the support of mp3 and mp4 has been introduced in firefox on v21 for
win 7 and v22 for Vista.
Do you consider to port these formats on Windows XP?
_
Meeting Details:
* Agenda: https://etherpad.mozilla.org/webapi-meetingnotes
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office
* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone #
Robert O'Callahan wrote:
On Mon, Jul 22, 2013 at 3:58 PM, L. David Baron wrote:
Is the idea here that nsRefPtr/nsCOMPtr/etc. would have move constructors, and
we'd just return them, and the move constructors plus return value
optimizations would take care of avoiding excess reference counti
> It seems really dangerous that there is an implicit conversion from a strong
> ref ptr to a weak pointer. With C++11, you can thankfully require this
> conversion to be explicit which should alleviate your concern.
Wouldn't disallowing this implicit conversion break code which does
void UseFo
23 matches
Mail list logo
