Re: Standalone GTests

2013-05-08 Thread Benoit Girard
If you plan on adding more tests to GTest please build against patches in bug 844288 which will hopefully land soon. Note that I have one outstanding problem left on Windows where the linking only fails on TBPL jobs. I personally have a strong preference for keeping tests, particularly unit tests,

Re: We should drop MathML

2013-05-08 Thread kyvago
On Monday, 6 May 2013 01:38:39 UTC+10, Benoit Jacob wrote: > Hi, > > > > Summary: MathML is a vestigial remnant of the XML-everything era, and we > > should drop it. > > > > *** > > > > 1. Reasons why I believe that MathML never was a good idea. Summary: > > over-specialized and uniform

Re: Standalone GTests

2013-05-08 Thread Adam Roach
On 5/8/13 12:10, Gregory Szorc wrote: I think this is more a question for sheriffs and people closer to automation. Generally, you need to be cognizant of timeouts enforced by our automation infrastructure and the scorn people will give you for running a test that isn't efficient. But if it is

Re: Standalone GTests

2013-05-08 Thread Gregory Szorc
On 5/8/2013 8:41 AM, Ethan Hugg wrote: Hi All, We currently have 10 C++ GTest unittests in Firefox in media/mtransport/test and media/webrtc/signaling/test that build standalone tests with the FF build. These tests currently run as part of the build and make the B orange if they fail which is w

Re: We should drop MathML

2013-05-08 Thread kyvago
On Monday, 6 May 2013 22:19:31 UTC+10, Boris Zbarsky wrote: > On 5/6/13 7:27 AM, Benoit Jacob wrote: > > > I guess I don't see the usefulness of allowing to apply style to individual > > > parts of an equation > > > > Styling parts of an equation with different colors can be _extremely_ > >

Standalone GTests

2013-05-08 Thread Ethan Hugg
Hi All, We currently have 10 C++ GTest unittests in Firefox in media/mtransport/test and media/webrtc/signaling/test that build standalone tests with the FF build. These tests currently run as part of the build and make the B orange if they fail which is why a couple of them are still stubbed at

Re: Simplify async code-flows and unify unit tests

2013-05-08 Thread Mike de Boer
Hi Sam! Thanks for taking the time to read and reply! Please read my answers inline... On May 8, 2013, at 3:11 PM, sam foster wrote: > I want to add my +1 to the goal of unifying and streamlining the setting up > of test flows and a common assertion syntax. > Yay! > I know some of the iss

Re: Simplify async code-flows and unify unit tests

2013-05-08 Thread Mike de Boer
Hi Joshua! Thanks for taking the time to read and reply! Please read my answers inline... On May 8, 2013, at 6:17 AM, Joshua Cranmer 🐧 wrote: > On 5/7/2013 8:49 AM, Mike de Boer wrote: >> I've told some of you before that I'm not a big fan of Promise libraries (if >> not, please read the 10 r

Re: Simplify async code-flows and unify unit tests

2013-05-08 Thread sam foster
I want to add my +1 to the goal of unifying and streamlining the setting up of test flows and a common assertion syntax. I know some of the issues you raise with Promises (like getting a useful stack on exceptions) are being discussed and addressed already. I dont have all the context, but IST

Re: Simplify async code-flows and unify unit tests

2013-05-08 Thread Mike de Boer
Hi Mark! Thanks for taking the time to read and reply! I really don't have an aversion to using Promises at all! I'm trying to point out that continuation passing style async programming and Promises can co-exist. I love the way how Promises can be neatly combined with Generators and the semant