Re: Using C++0x auto
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 UseFoo(nsIFoo* foo); nsCOMPtrnsIFoo foo; UseFoo(foo); ? That is an extremely common idiom in our code. Like I say, maybe there's a way to allow lvalue nsRefPtrT to convert to T*, but disallow the conversion for rvalue nsRefPtrT. That would be reasonable, I think. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using C++0x auto
Robert O'Callahan wrote: On Mon, Jul 22, 2013 at 3:58 PM, L. David Baron dba...@dbaron.org 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 counting? That, plus forget() returns a nsRefPtr. Historically people used refptr.forget().get(); to get a raw addrefed pointer. MXR suggests that we still have 72 uses like this. (But as an interim stage I assume you could keep the addrefed wrapper type and define a move constructor from it to refptr.) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
WebAPI Meeting: Tuesday 23 July @ 10 AM Pacific [1]
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 # 1-800-707-2533 (PIN 369) Conference #98413 (US) * Join irc.mozilla.org #webapi for back channel All are welcome. Andrew [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130723T10p1=224am=30 Please comment on potential new meeting time: https://groups.google.com/d/msg/mozilla.dev.webapi/ySb3gLSCYS8/1frJTXelNhUJ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
id2webidl
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/idl2webidl.rb This ruby script generates an HTML page: https://people.mozilla.com/~amarchesini/code/idl2webidl.html (this page is not up-to-date) 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. Bye, b ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: id2webidl
On Mon, Jul 22, 2013 at 7:45 AM, Andrea Marchesini amarches...@mozilla.comwrote: 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/idl2webidl.rb This ruby script generates an HTML page: https://people.mozilla.com/~amarchesini/code/idl2webidl.html (this page is not up-to-date) 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. Bye, b ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform FWIW, the only things we have to convert are DOM interfaces. The rest are things we can do if desired, but we should default to not converting internal XPCOM interfaces due to the additional codesize that WebIDL bindings add. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: id2webidl
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 nsIDOM* interfaces, which are more likely to be something we want to convert. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Do you consider to port mp3 support on Windows XP
On Mon, Jul 22, 2013 at 6:45 AM, lchenneb...@gmail.com 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 Windows XP? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform You already asked this question and got an answer ... - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using C++0x auto
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 conversion break code which does void UseFoo(nsIFoo* foo); nsCOMPtrnsIFoo foo; UseFoo(foo); ? That is an extremely common idiom in our code. Yeah... Like I say, maybe there's a way to allow lvalue nsRefPtrT to convert to T*, but disallow the conversion for rvalue nsRefPtrT. That would be reasonable, I think. 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_AddRefed. :( Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Enabling mozharness for talos for FF25 projects (was Re: Running talos through mozharness)
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 in the morning of EDT. I assume that changeset 3d1c2ca7efe8 is already on your local checkout after a week being in the tree but worth raising it up again. There's one thing to do on your part if you want to not have failing *talos* jobs on the try server, make sure that the changeset 3d1c2ca7efe8 is in your local checkout [5][6]. If you have updated your repo from m-i by Friday 12th at 10:19AM PDT you should be good to go. regards, Jason Armen [5] http://hg.mozilla.org/integration/mozilla-inbound/rev/3d1c2ca7efe8 [6] http://hg.mozilla.org/mozilla-central/rev/3d1c2ca7efe8 On 2013-07-16 8:51 AM, Armen Zambrano G. wrote: Hi, We have recently been working hard to separate the buildbot logic that runs our talos jobs on tbpl to its own separate script (using mozharness). [1][2] This has the advantage of permitting anyone (specially the a-team) to adjust how our harnesses run talos inside of our infrastructure without having to set up buildbot (which is what currently runs our talos jobs). This also permits anyone to run the jobs locally in the same manner as Releng's infrastructure. This also allows for further development and flexibility on how we configure the jobs we run. Initially, we will enable it on the try server today to see production-like load. So far, it's been looking great on Cedar. [3] The only gotcha is that there will be a small performance hit for the ts tests that we are willing to take. [4] There's one thing to do on your part if you want to not have failing *talos* jobs on the try server, make sure that the changeset 3d1c2ca7efe8 is in your local checkout [5][6]. If you have updated your repo from m-i by Friday 12th at 10:19AM PDT you should be good to go. Once we get a couple of days worth of load on the try server and see nothing new we will go ahead and enable it for every m-c based repository. If you have any questions/concerns please write a comment on bug 713055. Best regards, Jason Armen Release Engineering [1] https://bugzilla.mozilla.org/show_bug.cgi?id=713055 [2] https://developer.mozilla.org/en-US/docs/Mozharness_FAQ [3] https://tbpl.mozilla.org/?tree=Cedarjobname=talos [4] https://bugzilla.mozilla.org/show_bug.cgi?id=802801#c10 [5] http://hg.mozilla.org/integration/mozilla-inbound/rev/3d1c2ca7efe8 [6] http://hg.mozilla.org/mozilla-central/rev/3d1c2ca7efe8 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using C++0x auto
On Sun, Jul 21, 2013 at 11:59 PM, Justin Lebar justin.le...@gmail.comwrote: 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 UseFoo(nsIFoo* foo); nsCOMPtrnsIFoo foo; UseFoo(foo); ? That is an extremely common idiom in our code. That idiom seems dangerous by itself; the assumption it makes is that the reference will outlive the callee but that isn't actually enforced anywhere (you could write UseFoo(nsRefPtrT(new T)) and Bad Things would happen; there are less obvious ways to write this). I would rewrite UseFoo to take an const nsRefPtrnsIFoo instead and then you don't have to worry about these issues. -Rob ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Do you consider to port mp3 support on Windows XP
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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
