On Thu, Dec 12, 2013 at 9:48 AM, Nicholas Nethercote
wrote:
>>
>> Unfortunately, on December 5th, just before the changes were enabled,
>> something
>> else happened that caused the Valgrind jobs to start timing out all the time.
>> This is being tracked in https://bugzilla.mozilla.org/show_bug.c
After I announced the in-tree build docs powered by Sphinx a few months
ago [1], a few people came to me and said "that's really cool - I want
something like that for my module."
I'm pleased to announce that as of bug 939367 landing in inbound a few
hours ago, you can now deposit Sphinx docs a
On 12/12/2013 3:43 AM, Nicholas Nethercote wrote:
>
> I tracked this down to one of the Quitter files being a symlink with a
> relative path, and that path was going awry when the file was copied
> elsewhere within the chroot that the tests run in on the build
> slaves(!) And by the time I worked
Hi,
I think two prefs are needed.
In addition to the pref discussed in this topic, "make all media on any tabs be
click-to-play" is needed to ensure the Web Accessibility.
UAAG2 (User Agent Accessibility Guidelines 2.0) LCWD [1] contains two "Level A"
success criteria related to this topic.
-
= Data and Background =
See, as some anecdotal evidence:
Bug 930797 is a user who just upgraded to Firefox 25 and is seeing these
a lot.
dmajor tracked this down to our video implementation creating many
threads, each of which has an x86 stack as well as a 1MB memory
reservation for the wow6
On Fri, Dec 13, 2013 at 2:53 AM, Benjamin Smedberg
wrote:
>
> Also, we now have the ability to use DMD builds on Windows
DMD works on Windows debug builds, but doesn't currently work on opt
builds. But https://bugzilla.mozilla.org/show_bug.cgi?id=947117
(compile-time) and https://bugzilla.mozi
Hello all,
After disabling the Win7 tests on those b2g18 trees, I was told by the
sheriffs that the MacOS X testing is redundant.
Again:
* these are repositories where only security fixes are being landed
* this is not about b2g26
* we have testing coverage through Linux, Linux64, Android Noion +
On 12/12/2013 11:58 AM, arme...@mozilla.com wrote:
Hello all,
After disabling the Win7 tests on those b2g18 trees, I was told by the
sheriffs that the MacOS X testing is redundant.
Again:
* these are repositories where only security fixes are being landed
* this is not about b2g26
* we have test
+dev.b2g
tl;dr
- we want to disable Mac + Linux32-bit build/tests for mozilla-b2g18 and
mozilla-b2g18-v1.1.0hd
Hi Ryan,
I would be fine of taking care of it if I hear no objections by next week.
On 13-12-12 12:12 PM, Ryan VanderMeulen wrote:
> On 12/12/2013 11:58 AM, arme...@mozilla.com wrote:
>
On 12/10/2013 04:32 PM, Jeff Gilbert wrote:
> In my experience, docs for 'our' containers are also miles behind what the
> STL has available.
This, not unfamiliarity to new developers, is the big issue. Developers have
to learn new APIs all the time. STL versus something else shouldn't be that
Recently bug 539710 landed[0] to fix an unnecessary and apparently
unsafe operation:
const PRUnichar *comma = NS_LITERAL_STRING(",").get();
Curious, I did a quick search for other examples of NS_LITERAL_STRING
combined with .get() and found that this appears to be common[1].
So, I have a few ques
On 12/12/2013 6:52 PM, David Keeler wrote:
Recently bug 539710 landed[0] to fix an unnecessary and apparently
unsafe operation:
const PRUnichar *comma = NS_LITERAL_STRING(",").get();
Curious, I did a quick search for other examples of NS_LITERAL_STRING
combined with .get() and found that this a
On Thursday 2013-12-12 16:52 -0800, David Keeler wrote:
> Recently bug 539710 landed[0] to fix an unnecessary and apparently
> unsafe operation:
>
> const PRUnichar *comma = NS_LITERAL_STRING(",").get();
>
> Curious, I did a quick search for other examples of NS_LITERAL_STRING
> combined with .ge
On Thu, Dec 12, 2013 at 07:01:18PM -0600, Joshua Cranmer ? wrote:
> On 12/12/2013 6:52 PM, David Keeler wrote:
> >Recently bug 539710 landed[0] to fix an unnecessary and apparently
> >unsafe operation:
> >
> >const PRUnichar *comma = NS_LITERAL_STRING(",").get();
> >
> >Curious, I did a quick searc
On 12/12/13, 5:09 PM, L. David Baron wrote:
The preferred form would now be:
#include "mozilla/Char16.h"
const PRUnichar *comma = MOZ_UTF16(",");
I think char16_t is preferred over PRUnichar for new code.
chris
___
dev-platform mailing list
On Fri, Dec 13, 2013 at 3:02 PM, Chris Peterson wrote:
> On 12/12/13, 5:09 PM, L. David Baron wrote:
>
>> The preferred form would now be:
>>
>>#include "mozilla/Char16.h"
>>
>>const PRUnichar *comma = MOZ_UTF16(",");
>>
>
> I think char16_t is preferred over PRUnichar for new code.
>
So
On 12/12/2013, 9:18 PM, Robert O'Callahan wrote:
On Fri, Dec 13, 2013 at 3:02 PM, Chris Peterson wrote:
On 12/12/13, 5:09 PM, L. David Baron wrote:
The preferred form would now be:
#include "mozilla/Char16.h"
This #include is actually not needed. That header is available everywhere.
Just landed in inbound are patches that hopefully resolve the issue
where WebIDL changes required a clobber on Windows.
Please stop touching CLOBBER when modifying WebIDL files. Please be on
the lookout for WebIDL build system oddities.
Please be advised that developer workflow for updating W
On 12/12/2013 10:34 PM, Gregory Szorc wrote:
Just landed in inbound are patches that hopefully resolve the issue
where WebIDL changes required a clobber on Windows.
Please stop touching CLOBBER when modifying WebIDL files. Please be on
the lookout for WebIDL build system oddities.
Please be adv
On 12/12/13 10:34 PM, Gregory Szorc wrote:
Just landed in inbound are patches that hopefully resolve the issue
where WebIDL changes required a clobber on Windows.
Thank you again for picking this up and getting it done!
-Boris
___
dev-platform maili
20 matches
Mail list logo