xulrunner under android and libxpcom.so missing
Hi all I want to develop an multiplatform application for Windows and Android with web browse capabilties. The application will be written using C++. Under Windows no problem but looking into xulrunner version for android I don't find the library libxpcom.so to use for run xul gecko engine. The core of my app will be in native code (C++ es explained) and the interface between app code and xul engine will be using this native part. For android integration an additional java layer thorugh jni will be added but the point is I need to reuse the C++ code working directly with libxpcom.so library under android too. Someone know why libxpcom.so is missing from android part? (or, in case exist, where to find or how to compiel it in the right way using android NDK) Thank you ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: Frame Timing API
Summary: Provides an interface for receiving frame performance timing including composites happening on a separate thread/process. This can be used to calculate measures of smoothness that incorporate the effect of async pan and zoom and off-main thread animation. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1158032 Link to standard: https://w3c.github.io/frame-timing/ Platform coverage: all platforms Estimated or target release: Firefox 43 although we might hold off shipping depending on the state of the spec at that time (there has been discussion of replacing the buffer-based interface with an observer interface). Preference behind which this will be implemented: dom.enable_frame_timing DevTools bug: No specific bug yet but the DevTools team is aware of our intention to implement and indicated they could use this API. Other browser support: Blink: in development, soon to reach Canary.[1] [1] https://code.google.com/p/chromium/issues/detail?id=120796#c53 Thanks, hiro ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
NS_LITERAL_CSTRING
NS_LITERAL_STRING, as its name suggests, only ever gets used on string
literals, or macros that expand to string literals.
NS_LITERAL_CSTRING gets (ab?)used in all sorts of ways. Should we be
consistent and require NS_LITERAL_CSTRING to be used on string literals?
I found the following in-tree examples, none of which would have worked
with NS_LITERAL_STRING:
static const char f00[] = f00;
F001(NS_LITERAL_CSTRING(f00));
NS_NAMED_LITERAL_CSTRING(f002, NS_LITERAL_CSTRING(F00));
templatesize_t N
void F003(const char (f00)[N])
{
F003(NS_LITERAL_CSTRING(f00));
}
F004(NS_LITERAL_CSTRING(F00) + NS_LITERAL_CSTRING(f00));
NS_ConvertASCIItoUTF16 f005(NS_LITERAL_CSTRING(f00));
NS_NAMED_LITERAL_CSTRING(f006, f00);
f007.Assign(NS_LITERAL_CSTRING(f00));
When I tried enforcing string literals the compilers also tripped up
over this line but it might be because of the way macros are expanded:
nsCString f008 = NS_LITERAL_CSTRING(__FUNCTION__);
--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used
On 04/27/2015 12:48 PM, Ehsan Akhgari wrote: I think we should change it to require the usage of exactly one of these keywords per *overridden* function: virtual, override, and final. Let me attempt to clarify why the exactly one requirement here is important. (It's non-obvious.) This verbose function-signature... virtual void foo() final override; ...can be expressed as the following, without removing any strictness: void foo() final BUT, if we add back the virtual keyword, we *lose some strictness*. In other words, this is *not* equivalent to the versions above: virtual void foo() final Unless the formulations above, this version isn't guaranteed to override. The keywords final override can be viewed as redundant, but only if the virtual keyword is not present. This is because final implies virtual, and virtualness-without-an-explicit-virtual-keyword implies override. So final + lack-of-virtual-keyword implies override. Hence the exactly one requirement that ehsan is proposing (which Google has adopted). * It makes it easier to determine what kind of function you are looking at by just looking at its declaration. |virtual void foo();| means a virtual function that is not overridden, |void foo() override;| means an overridden virtual function, and |void foo() final;| means an overridden virtual function that cannot be further overridden. After discussing briefly with ehsan on IRC -- let me clarify the language on this, since the word overridden is ambiguous here. (ehsan was mostly using it to mean is an override of something else) I'll restate the three categories, with less ambiguous language: - |virtual void foo();| means a virtual function that is not an override of a superclass method. - |void foo() override;| means an overriding virtual function. - |void foo() final;| means an overriding virtual function that cannot be further overridden. * It will allow us to remove NS_IMETHODIMP, and use NS_IMETHOD instead. (FWIW: This is because NS_METHODIMP expands to the exact same thing as NS_IMETHOD, minus the 'virtual' keyword: https://mxr.mozilla.org/mozilla-central/source/xpcom/base/nscore.h?rev=7e4e5e971d95mark=96-97#96 So if we were to drop 'virtual' from NS_IMETHOD -- as we probably would want to if we adopt ehsan's proposal -- then NS_IMETHODIMP would have no reason to exist.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used
I completely support this. Let the needless verbosity end! - Seth On Apr 27, 2015, at 12:48 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Right now, our coding style requires that both the virtual and override keywords to be specified for overridden virtual functions. A few things have changed since we decided that a number of years ago: 1. The override and final keywords are now available on all of the compilers that we build with, and we have stopped supporting compilers that do not support these features. 2. We have very recently gained the ability to run clang-based mass source code transformations over our code that would let us enforce the coding style [1]. I would like to propose a change to our coding style, and run a mass transformation over our code in order to enforce it. I think we should change it to require the usage of exactly one of these keywords per *overridden* function: virtual, override, and final. Here are the advantages: * It is a more succinct, as |virtual void foo() override;| doesn't convey more information than |void foo() override;|. * It can be easily enforced using clang-tidy across the entire code base. * It makes it easier to determine what kind of function you are looking at by just looking at its declaration. |virtual void foo();| means a virtual function that is not overridden, |void foo() override;| means an overridden virtual function, and |void foo() final;| means an overridden virtual function that cannot be further overridden. * It allows us to be in sync with the Google C++ Style on this issue [2]. * It will allow us to remove NS_IMETHODIMP, and use NS_IMETHOD instead. Please let me know what you think! [1] Facilitated by bug 904572. Also see bug 1158776 for my first attempt at this. [2] http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Inheritance Cheers, -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used
Right now, our coding style requires that both the virtual and override keywords to be specified for overridden virtual functions. A few things have changed since we decided that a number of years ago: 1. The override and final keywords are now available on all of the compilers that we build with, and we have stopped supporting compilers that do not support these features. 2. We have very recently gained the ability to run clang-based mass source code transformations over our code that would let us enforce the coding style [1]. I would like to propose a change to our coding style, and run a mass transformation over our code in order to enforce it. I think we should change it to require the usage of exactly one of these keywords per *overridden* function: virtual, override, and final. Here are the advantages: * It is a more succinct, as |virtual void foo() override;| doesn't convey more information than |void foo() override;|. * It can be easily enforced using clang-tidy across the entire code base. * It makes it easier to determine what kind of function you are looking at by just looking at its declaration. |virtual void foo();| means a virtual function that is not overridden, |void foo() override;| means an overridden virtual function, and |void foo() final;| means an overridden virtual function that cannot be further overridden. * It allows us to be in sync with the Google C++ Style on this issue [2]. * It will allow us to remove NS_IMETHODIMP, and use NS_IMETHOD instead. Please let me know what you think! [1] Facilitated by bug 904572. Also see bug 1158776 for my first attempt at this. [2] http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Inheritance Cheers, -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used
On Mon, Apr 27, 2015 at 03:48:48PM -0400, Ehsan Akhgari wrote: Right now, our coding style requires that both the virtual and override keywords to be specified for overridden virtual functions. A few things have changed since we decided that a number of years ago: 1. The override and final keywords are now available on all of the compilers that we build with, and we have stopped supporting compilers that do not support these features. 2. We have very recently gained the ability to run clang-based mass source code transformations over our code that would let us enforce the coding style [1]. I would like to propose a change to our coding style, and run a mass transformation over our code in order to enforce it. I think we should change it to require the usage of exactly one of these keywords per *overridden* function: virtual, override, and final. Here are the advantages: I believe we have some cases in the tree where a virtual function doesn't override but is final so you need to write virtual final. I believe one of those cases may be so a function can be called indirectly from outside libxul, and another might be to prevent people using some cc macros incorrectly. * It is a more succinct, as |virtual void foo() override;| doesn't convey more information than |void foo() override;|. personally I think it takes significantly more mental effort to read void foo() final; to mean it overrides something and is virtual than if its explicit as in virtual void foo() override final; and actually I'd also like it if C++ changed to allow override and final on non virtual functions in which case this would be a loss of information. * It can be easily enforced using clang-tidy across the entire code base. That doesn't really seem like an argument for choosing this particular style we could as easily check that virtual functions are always marked virtual, and marked override if possible. * It makes it easier to determine what kind of function you are looking at by just looking at its declaration. |virtual void foo();| means a virtual function that is not overridden, |void foo() override;| means an overridden virtual function, and |void foo() final;| means an overridden virtual function that cannot be further overridden. this seems to be more an advantage of any enforced rule. That is if we just enforced that any function that overrides is marked override then you would know that virtual void foo(); doesn't override, and otherwise override would always be present which would make it clear it does override in addition to possibly being final. * It allows us to be in sync with the Google C++ Style on this issue [2]. I don't personally care about that much. * It will allow us to remove NS_IMETHODIMP, and use NS_IMETHOD instead. That doesn't really seem like much of an improvement, and of course really we should just get rid of both but that's more work. Trev Please let me know what you think! [1] Facilitated by bug 904572. Also see bug 1158776 for my first attempt at this. [2] http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Inheritance Cheers, -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: You can now log into BMO with your GitHub account
On 2015-04-27 10:41 AM, Mike Hoye wrote: On 2015-04-27 10:15 AM, Mark Côté wrote: This morning we enabled a feature on bugzilla.mozilla.org that allows users to log in with their GitHub credentials, similar to our existing Persona support. If you have several email addresses associated with your GitHub account, you will be prompted to choose one. In either case, if your chosen GitHub email address does not match an existing user, you will be prompted to create an account. Also note that, as with Persona, GitHub login is not available to users with special administrative or security permissions. This is pretty great for a couple of things I'm working on. What does special administrative or security permissions mean? Can a user logged in via GitHub have editbugs or canconfirm? It means access to things such as the core-security group which lets you view all security sensitive bugs. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: NS_LITERAL_CSTRING
On 2015-04-27 6:29 AM, Neil wrote: NS_LITERAL_STRING, as its name suggests, only ever gets used on string literals, or macros that expand to string literals. NS_LITERAL_CSTRING gets (ab?)used in all sorts of ways. Should we be consistent and require NS_LITERAL_CSTRING to be used on string literals? I would say yes. I found the following in-tree examples, none of which would have worked with NS_LITERAL_STRING: These are terrible! When I tried enforcing string literals the compilers also tripped up over this line but it might be because of the way macros are expanded: nsCString f008 = NS_LITERAL_CSTRING(__FUNCTION__); That's because __FUNCTION__ doesn't get handled by the preprocessor! The compilers typically cannot replace it with a string sooner than the semantic analysis phase since they need to, well, know what function it's used in. :-) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: You can now log into BMO with your GitHub account
On 2015-04-27 10:54 AM, Mark Côté wrote: On 2015-04-27 10:41 AM, Mike Hoye wrote: What does special administrative or security permissions mean? Can a user logged in via GitHub have editbugs or canconfirm? editbugs and canconfirm on their own are fine. The vast majority of users will be able to use GitHub login. Awesome, thank you! - mhoye ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: (mozci) Triggering jobs on treeherder
Thank you all for reading through the post and the feedback. It seems that there is interest for this. On 15-04-24 06:06 PM, Mike Hommey wrote: On Fri, Apr 24, 2015 at 10:26:58PM +0100, Gijs Kruitbosch wrote: Are you going to build a web UI for this so I don't need to check out a repo and run a python script with syntax that I'll likely need to look up every time I want to do it, guessing builder names that I don't know? (don't get me wrong, I could probably use it if I needed to, but it's harder than it could be right now...) If we allowed invoking through mach, it would also help with not needing to checkout an extra repo OR pip install a package on your system. Yes, we could build a web UI to help with this process, however, at the same time I wanted to measure how many people would likely use it. It seems to me like self-serve does a lot of this, but you can't retrigger things that haven't run in the first place. mozci allows you to trigger jobs that have not been scheduled. It uses an API that self-serve/buildapi provides. I know that the self-serve UI does not provide access to this specific API but others. Why not have these features on treeherder? Yes, we could; it is in the milestones. We need to be picky as to what to move there. I will announce it once we have a prototype working. Mike -- Zambrano Gasparnian, Armen Automation Tools Engineer http://armenzg.blogspot.ca ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
You can now log into BMO with your GitHub account
This morning we enabled a feature on bugzilla.mozilla.org that allows users to log in with their GitHub credentials, similar to our existing Persona support. If you have several email addresses associated with your GitHub account, you will be prompted to choose one. In either case, if your chosen GitHub email address does not match an existing user, you will be prompted to create an account. Also note that, as with Persona, GitHub login is not available to users with special administrative or security permissions. Although hopefully convenient on its own, this feature is also a step toward our plan to enabling importing of GitHub pull requests into MozReview. Mark ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: You can now log into BMO with your GitHub account
On 2015-04-27 10:15 AM, Mark Côté wrote: This morning we enabled a feature on bugzilla.mozilla.org that allows users to log in with their GitHub credentials, similar to our existing Persona support. If you have several email addresses associated with your GitHub account, you will be prompted to choose one. In either case, if your chosen GitHub email address does not match an existing user, you will be prompted to create an account. Also note that, as with Persona, GitHub login is not available to users with special administrative or security permissions. This is pretty great for a couple of things I'm working on. What does special administrative or security permissions mean? Can a user logged in via GitHub have editbugs or canconfirm? - mhoye ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: You can now log into BMO with your GitHub account
On 2015-04-27 10:41 AM, Mike Hoye wrote: On 2015-04-27 10:15 AM, Mark Côté wrote: This morning we enabled a feature on bugzilla.mozilla.org that allows users to log in with their GitHub credentials, similar to our existing Persona support. If you have several email addresses associated with your GitHub account, you will be prompted to choose one. In either case, if your chosen GitHub email address does not match an existing user, you will be prompted to create an account. Also note that, as with Persona, GitHub login is not available to users with special administrative or security permissions. This is pretty great for a couple of things I'm working on. What does special administrative or security permissions mean? Can a user logged in via GitHub have editbugs or canconfirm? editbugs and canconfirm on their own are fine. The vast majority of users will be able to use GitHub login. Accounts that cannot use GitHub include those that are members of security groups; members of other private groups like HR, legal, and privacy; and those who have admin rights, like the BMO devs. Mark ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing Operation Instrument
Wow. Email formatting fail. Hopefully this turns out a little better: Hello platform hackers! [Operation Instrument](https://wiki.mozilla.org/DevTools/OperationInstrument) is a project that aims to add tracing instrumentation to Gecko and provide a holistic view of where time is being spent and why. Examples of traced operations include: * Style Recalculation * Layout Reflow * Painting * JavaScript Run-to-Completion * Etc. The traced operations are displayed in the DevTools Performance panel's timeline: https://wiki.mozilla.org/File:Timeline-screenshot.png The goal is to have zero gaps between markers, so that we can always tell at a high level what Gecko is doing, and what brought it there. But, the DevTools team can't do it alone. You can help add new instrumentation to the parts of Gecko you're familiar with. If you have an nsDocShell, it can be as easy as using a simple RAII class: `mozilla::AutoTimelineMarker`. There is a quick and easy tutorial with examples here: https://wiki.mozilla.org/DevTools/OperationInstrument#Tutorial:_Instrumenting_New_Operations Additionally, when you are implementing new features, please consider adding instrumentation right off the bat! Please take a look at the blockers of our meta bug, and file new bugs that block it: https://bugzilla.mozilla.org/show_bug.cgi?id=1145271 Thanks, Nick (and the whole DevTools team) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used
That's correct. Using override and final on a non-virtual function is a compile time error. On Apr 27, 2015 5:34 PM, L. David Baron dba...@dbaron.org wrote: On Monday 2015-04-27 15:48 -0400, Ehsan Akhgari wrote: Right now, our coding style requires that both the virtual and override keywords to be specified for overridden virtual functions. A few things have changed since we decided that a number of years ago: 1. The override and final keywords are now available on all of the compilers that we build with, and we have stopped supporting compilers that do not support these features. 2. We have very recently gained the ability to run clang-based mass source code transformations over our code that would let us enforce the coding style [1]. I would like to propose a change to our coding style, and run a mass transformation over our code in order to enforce it. I think we should change it to require the usage of exactly one of these keywords per *overridden* function: virtual, override, and final. Here are the advantages: Are the override and final keywords not allowed on non-virtual functions? -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used
On Mon, Apr 27, 2015 at 5:45 PM, Trevor Saunders tbsau...@tbsaunde.org wrote: On Mon, Apr 27, 2015 at 03:48:48PM -0400, Ehsan Akhgari wrote: Right now, our coding style requires that both the virtual and override keywords to be specified for overridden virtual functions. A few things have changed since we decided that a number of years ago: 1. The override and final keywords are now available on all of the compilers that we build with, and we have stopped supporting compilers that do not support these features. 2. We have very recently gained the ability to run clang-based mass source code transformations over our code that would let us enforce the coding style [1]. I would like to propose a change to our coding style, and run a mass transformation over our code in order to enforce it. I think we should change it to require the usage of exactly one of these keywords per *overridden* function: virtual, override, and final. Here are the advantages: I believe we have some cases in the tree where a virtual function doesn't override but is final so you need to write virtual final. I believe one of those cases may be so a function can be called indirectly from outside libxul, and another might be to prevent people using some cc macros incorrectly. Any chance you could point us to those functions, please? * It is a more succinct, as |virtual void foo() override;| doesn't convey more information than |void foo() override;|. personally I think it takes significantly more mental effort to read void foo() final; to mean it overrides something and is virtual than if its explicit as in virtual void foo() override final; and actually I'd also like it if C++ changed to allow override and final on non virtual functions in which case this would be a loss of information. Well, we're not talking about changing C++. ;-) But why do you find it more clear to say |virtual ... final| than |... final|? They both convey the exact same amount of information. Is it just habit and/or personal preference? * It can be easily enforced using clang-tidy across the entire code base. That doesn't really seem like an argument for choosing this particular style we could as easily check that virtual functions are always marked virtual, and marked override if possible. Except that is more tricky to get right. Please see bug 1158776. * It makes it easier to determine what kind of function you are looking at by just looking at its declaration. |virtual void foo();| means a virtual function that is not overridden, |void foo() override;| means an overridden virtual function, and |void foo() final;| means an overridden virtual function that cannot be further overridden. this seems to be more an advantage of any enforced rule. That is if we just enforced that any function that overrides is marked override then you would know that virtual void foo(); doesn't override, and otherwise override would always be present which would make it clear it does override in addition to possibly being final. Yes, but again the point is that 1) one alternative repeats redundant keywords, and 2) we don't *need* to use the virtual keyword on overriding functions any more. Perhaps the second point is not clear from my first email. Before, because not all of the compilers we target supported override and final, we *needed* to keep the virtual function, but now we don't, so using virtual for overriding function now requires a justification, contrary to our past practice. * It allows us to be in sync with the Google C++ Style on this issue [2]. I don't personally care about that much. The reason why this is important is that many of the existing tools for massive rewriting of code bases have been written with that coding style in mind, so not diverging from that style enables us to use those tools out of the box. (But this is just a nicety, of course.) * It will allow us to remove NS_IMETHODIMP, and use NS_IMETHOD instead. That doesn't really seem like much of an improvement, and of course really we should just get rid of both but that's more work. I don't understand how this is not an improvement. I have seen *tons* of places where people are not sure which one they are supposed to use, or use the wrong one (for example, NS_IMETHODIMP for inline functions inside class bodies -- thankfully the virtual keyword is redundant. ;-) Also I don't understand why you think we should get rid of both. Not meaning to open a discussion on that since that's off-topic, but we should definitely not get rid of this macro, since it has a job that it's really good at (encapsulating the COM compatible calling convention on Windows.) Perhaps you meant taking the nsresult out of it, but that just gives us more verbosity which is not nice.. But I digress! Please let me know what you think! [1] Facilitated by bug 904572. Also see bug 1158776 for my first
Announcing Operation Instrument
Hello platform hackers! [ Operation Instrument ] (htt ps://wiki.mozilla.org/DevTools/OperationInstrument) is a project that aims to add tracing instrumentation to Gecko and provide a holistic view of where time is being spent and why. Examples of traced operations include: * Style Recalculation * Layout Reflow * Painting * JavaScript R un-to- C ompletion * Etc. The traced operations are displayed in the DevTools Performance panel 's timeline: https://wiki.mozilla.org/File:Timeline-screenshot.png The goal is to have zero gaps between markers, so that we can always tell at a high level what Gecko is doing, and what brought it there. But , the DevTools team can't do it alone. You can help add new instrumentation to the parts of Gecko you're familiar with. If you have an nsDocShell, it can be as easy as using a simple RAII class: `mozilla::AutoTimelineMarker`. There is a quick and easy tutorial with examples here: https://wiki.mozilla.org/DevTools/OperationInstrument#Tutorial:_Instrumenting_New_Operations Additionally, when you are implementing new features, please consider adding instrumentation right off the bat! Please take a look at the blockers of our meta bug, and file new bugs that block it: https://bugzilla.mozilla.org/show_bug.cgi?id=1145271 Thanks, Nick (and the whole DevTools team ) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used
On Mon, Apr 27, 2015 at 09:07:51PM -0400, Ehsan Akhgari wrote:
On Mon, Apr 27, 2015 at 5:45 PM, Trevor Saunders tbsau...@tbsaunde.org
wrote:
On Mon, Apr 27, 2015 at 03:48:48PM -0400, Ehsan Akhgari wrote:
Right now, our coding style requires that both the virtual and override
keywords to be specified for overridden virtual functions. A few things
have changed since we decided that a number of years ago:
1. The override and final keywords are now available on all of the
compilers that we build with, and we have stopped supporting compilers
that
do not support these features.
2. We have very recently gained the ability to run clang-based mass
source
code transformations over our code that would let us enforce the coding
style [1].
I would like to propose a change to our coding style, and run a mass
transformation over our code in order to enforce it. I think we should
change it to require the usage of exactly one of these keywords per
*overridden* function: virtual, override, and final. Here are the
advantages:
I believe we have some cases in the tree where a virtual function
doesn't override but is final so you need to write virtual final. I
believe one of those cases may be so a function can be called indirectly
from outside libxul, and another might be to prevent people using some
cc macros incorrectly.
Any chance you could point us to those functions, please?
http://mxr.mozilla.org/mozilla-central/source/xpcom/glue/nsCycleCollectionParticipant.h#548
and this one isn't final, but we could make it final if the tu will be
built into libxul (because then devirtualization is fine)
http://mxr.mozilla.org/mozilla-central/source/dom/base/nsIDocument.h#1287
* It is a more succinct, as |virtual void foo() override;| doesn't convey
more information than |void foo() override;|.
personally I think it takes significantly more mental effort to read
void foo() final; to mean it overrides something and is virtual than if
its explicit as in virtual void foo() override final;
and actually I'd also like it if C++ changed to allow override and final
on non virtual functions in which case this would be a loss of
information.
Well, we're not talking about changing C++. ;-) But why do you find it
I didn't say we were, but should such a change happen this would then be
confusing.
more clear to say |virtual ... final| than |... final|? They both convey
the exact same amount of information. Is it just habit and/or personal
preference?
its explicit vs implicit yes it is true that you can derive foo is
virtual from void foo() final; it doesn't take any habit or thinking to
see that from virtual void foo() override final; but I would claim its
not as obvious with void foo() final; I don't think that's really a
preference more than say prefering text files to gziped files ;)
* It can be easily enforced using clang-tidy across the entire code base.
That doesn't really seem like an argument for choosing this particular
style we could as easily check that virtual functions are always marked
virtual, and marked override if possible.
Except that is more tricky to get right. Please see bug 1158776.
not if we have a static analysis that checks override is always present.
* It makes it easier to determine what kind of function you are looking
at
by just looking at its declaration. |virtual void foo();| means a
virtual
function that is not overridden, |void foo() override;| means an
overridden
virtual function, and |void foo() final;| means an overridden virtual
function that cannot be further overridden.
this seems to be more an advantage of any enforced rule. That is if we
just enforced that any function that overrides is marked override then
you would know that virtual void foo(); doesn't override, and otherwise
override would always be present which would make it clear it does
override in addition to possibly being final.
Yes, but again the point is that 1) one alternative repeats redundant
sure, they're redundant if your only goal is to wwrite the shortest
possibleC++, but I'd claim if your goal is to write readable code they
are not redundant which is basically my whole point here.
keywords, and 2) we don't *need* to use the virtual keyword on overriding
functions any more. Perhaps the second point is not clear from my first
email. Before, because not all of the compilers we target supported
override and final, we *needed* to keep the virtual function, but now we
no, we never *needed* to use virtual on overides that is
class a { virtual void foo(); };
class b : a
{
void foo();
};
is perfectly valid C++.
don't, so using virtual for overriding function now requires a
justification, contrary to our past practice.
* It allows us to be in sync with the Google C++ Style on this issue [2].
I don't personally care about that much.
Re: Announcing Operation Instrument
How is this related to PROFILER_LABELs, docshell ProfileTimelineMarkers, and VisualEventTracer? Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: RFC: Navigation transitions
This is awesome!! I completely agree that the Google proposal is much too complicated for an initial take on solving transitions. I agree with Anne that this should be doable by adding CSS rules to a normal stylesheet rather than using a special linking mechanism. If that sounds good to you, then it would probably be worth updating the examples in the proposal to reflect this (don't worry about suboptimal names for now). I do have a few questions, but generally this looks great! * Is it always the right decision to have the new page render on top of the old one? Are there situations when you'd want, for example, the old page to slide away and have the new one appear underneath? You could for example create the effect of turning page in a book if the old page folds forward with the new page appearing behind it. One problem though would be how the old and the new page would negotiate which should appears on top, and which should appear on bottom. * Is it worth making it possible to animate the viewport in/out rather than just style the various elements in the page? For example if you want the new page to slide in from the right you have to not just animate the body element. You also have to animate any position:absolute and position:fixed elements. Maybe this would be best solved as an orthogonal feature which allows applying CSS transformations to the viewport. * We probably should add some form of API which allows the loading page to indicate when it's ready to be rendered. I.e. when the browser should start triggering the animate-in/out animations. This page is ready to be rendered feature has come up in several other contexts but seems extra important here. * I think we should make sure that this proposal doesn't make the feature Google ask for impossible to add in the future. I don't think the current proposal does, but it might be worth explicitly saying that that can be added in the future, rather than to just say that it's impossible right now. All in all, this is super awesome. Please do push for it at the W3C! / Jonas On Thu, Apr 23, 2015 at 3:39 AM, Christopher Lord cl...@mozilla.com wrote: Seems it has, sorry about that - here's a new one: http://chrislord.net/?p=273preview=1_ppp=d17048fbc3 I plan on publishing this (on my blog) today. The proposal and shim source is also visible permanently in git: https://gitlab.com/Cwiiis/gaia-navigator On Thu, Apr 23, 2015 at 5:23 AM, Ting-Yu Chou tc...@mozilla.com wrote: On Wed, Apr 22, 2015 at 1:02 AM, Christopher Lord cl...@mozilla.com wrote: down. I'm not a huge fan of all aspects of their proposal, so I've made my own: http://chrislord.net/?p=273preview=1_ppp=0afe20d87f Seems the link is outdated? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: You can now log into BMO with your GitHub account
On Mon, Apr 27, 2015 at 7:15 AM, Mark Côté mc...@mozilla.com wrote: This morning we enabled a feature on bugzilla.mozilla.org that allows users to log in with their GitHub credentials, similar to our existing Persona support. If you have several email addresses associated with your GitHub account, you will be prompted to choose one. In either case, if your chosen GitHub email address does not match an existing user, you will be prompted to create an account. Also note that, as with Persona, GitHub login is not available to users with special administrative or security permissions. Although hopefully convenient on its own, this feature is also a step toward our plan to enabling importing of GitHub pull requests into MozReview. Hi Mark, hi BMO team, As a developer working on Firefox for iOS (join us at https://github.com/mozilla/firefox-ios) this is awesome. I hope this will reduce our contributor's overhead when reporting and tracking issues. I will update our README to include logging in with Github's credentials. Thanks! Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Frame Timing API
On 2015/04/28 10:43, Jonas Sicking wrote: Please make sure to do a security review so that this doesn't expose any sensitive information accidentally. In particular, is there any way to use this API to use :visited hacks along with timing information to see if a user has visited a particular URL? I think we're ok since :visited only affects colors which shouldn't affect render or composite times? Is there someone we should loop in who can give a more informed appraisal? On Mon, Apr 27, 2015 at 2:27 AM, Hiroyuki Ikezoe hiike...@mozilla-japan.org wrote: Summary: Provides an interface for receiving frame performance timing including composites happening on a separate thread/process. This can be used to calculate measures of smoothness that incorporate the effect of async pan and zoom and off-main thread animation. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1158032 Link to standard: https://w3c.github.io/frame-timing/ Platform coverage: all platforms Estimated or target release: Firefox 43 although we might hold off shipping depending on the state of the spec at that time (there has been discussion of replacing the buffer-based interface with an observer interface). Preference behind which this will be implemented: dom.enable_frame_timing DevTools bug: No specific bug yet but the DevTools team is aware of our intention to implement and indicated they could use this API. Other browser support: Blink: in development, soon to reach Canary.[1] [1] https://code.google.com/p/chromium/issues/detail?id=120796#c53 Thanks, hiro ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
