On Fri, Nov 8, 2013 at 7:05 PM, Gregory Szorc wrote:
> FWIW, our LLVM/Clang SVN HEAD compatibility has been deteriorating in recent
> months.
Since this is the case, I edited the wiki to suggest the latest
release instead of suggesting a trunk checkout. The release works for
me. (It wasn't availa
On September 12, a debug clobber build on my new Linux desktop took
12.7 minutes. Just then it took 7.5 minutes. Woo!
Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Tue, Nov 19, 2013 at 5:30 PM, Boris Zbarsky wrote:
> We could report all rejections, but I'm a bit leery of adding so much noise
> that people start ignoring the report altogether; a common problem in the
> past.
Given that we report "throw 42" we should also report these I think. A
promise is
On Wed, Nov 20, 2013 at 12:51 PM, Anne van Kesteren wrote:
> On Tue, Nov 19, 2013 at 5:30 PM, Boris Zbarsky wrote:
> > We could report all rejections, but I'm a bit leery of adding so much
> noise
> > that people start ignoring the report altogether; a common problem in the
> > past.
>
> Given th
On 11/20/13 6:51 AM, Anne van Kesteren wrote:
On Tue, Nov 19, 2013 at 5:30 PM, Boris Zbarsky wrote:
We could report all rejections, but I'm a bit leery of adding so much noise
that people start ignoring the report altogether; a common problem in the
past.
Given that we report "throw 42"
We
On 11/20/13 7:34 AM, Boris Zbarsky wrote:
We could certainly try to report everything. It would be pretty
bare-bones, since for things that are not Error we don't have line/file
information as to where they originated, so all we can report is that
some promise somewhere was rejected with the val
Hi,
On or around November 13 2013 Firefox of versions 25.0.1, 24.1.1 ESR and 17.0.1
ESR were rereleased, along with XULRunner 25.0.1, but not for ESR versions. My
question is was any incompatibilities between Fx and XULRunner introduced with
these releases, and if so, did those incompatibiliti
On Sat, Nov 9, 2013 at 5:13 PM, Benjamin Smedberg wrote:
> On 11/8/2013 4:33 AM, fma spew wrote:
>
>> We have a npapi-npruntime plug-in that access the Windows certificate
>> store
>> via CAPI to provide the end-user with its personal certificates to perform
>> different operations.
>>
> What is t
On 11/20/2013 8:02 AM, Look, Yuriy wrote:
Hi,
On or around November 13 2013 Firefox of versions 25.0.1, 24.1.1 ESR
and 17.0.1 ESR were rereleased, along with XULRunner 25.0.1, but not
for ESR versions. My question is was any incompatibilities between Fx
and XULRunner introduced with these rel
On Wed, Nov 20, 2013 at 12:36 PM, Boris Zbarsky wrote:
> I guess no less useful than the current error console reporting for "throw
> 42" in a function which is already pretty useless.
When I said we report "throw 42" I meant in a function context. Hence
the analogy I made.
--
http://annev
On 11/20/2013 3:10 AM, fma spew wrote:
Our customers' end-users have their end-user certificates stored in the
"Personal logical certificate store" on Windows. The rest of needed
certificates, ("Intermediary" and/or "Trusted Root Certificates") are also
stored on Windows certificate stores. Our p
On 11/20/13 1:09 PM, Till Schneidereit wrote:
> How about logging them with console.info? That seems the right logging
> level to me, and it's easy to turn off if it gets in the way.
Well, the problem is that of logging uncaught rejections. You can log
them only if you catch them.
Cheers,
David
Nicholas Nethercote schrieb:
It also assumes that we can backout stuff to fix
the problem; we tried that to some extent with the first OOM closure
-- it is the standard response to test failure, of course -- but it
didn't work.
Yes, in the case of those OOM issues that caused this closure, the
On Wed, Nov 20, 2013 at 4:04 PM, David Rajchenbach-Teller <
dtel...@mozilla.com> wrote:
> On 11/20/13 1:09 PM, Till Schneidereit wrote:
> > How about logging them with console.info? That seems the right logging
> > level to me, and it's easy to turn off if it gets in the way.
>
> Well, the problem
On 11/20/2013 11:16 AM, Wilkins, Brian wrote:
That's odd because on RHEL, Xulrunner 17 ESR is in the RHEL Repo. Is this just
a RHEL versioning mismatch with the official versions?
I don't understand the question. Some Linux distros build Firefox on top
of their XULRunner package, and so they
That's odd because on RHEL, Xulrunner 17 ESR is in the RHEL Repo. Is this just
a RHEL versioning mismatch with the official versions?
Brian
From: Enterprise [mailto:enterprise-boun...@mozilla.org] On Behalf Of Benjamin
Smedberg
Sent: Wednesday, November 20, 2013 8:28 AM
To: Look, Yuriy; enterp
On Wed, Nov 20, 2013 at 5:40 AM, Benjamin Smedberg
wrote:
> I'm pretty sure that WebCrypto will have a way so sign a document with a
> certificate. It's not clear to me whether WebCrypto as currently specced
> also has a way to prompt the user to access personal certificates.
> bsmith/ekr, do you
On 11/19/13, 10:08 PM, Gregory Szorc wrote:
And 24 hours later, m-c (4f993fa378eb) is getting faster:
Wall 8:47 (527)
User 52:41 (3161)
Sys4:38 (278)
Total 57:19 (3439)
Unified builds currently coalesce source files in batches of 16.
It might be useful to add a files_per_unified_file
Talking about ideas for further extending the impact of UNIFIED_SOURCES, it
seems that the biggest limitation at the moment is that sources can't be
unified between different moz.build's. Because of that, source directories
that consist of many small sub-directories do not benefit much from
UNIFIED
I was skeptical of this work - so I need to say now that it is paying
dividends bigger and faster than I thought it could. very nice!
On Wed, Nov 20, 2013 at 3:38 AM, Nicholas Nethercote wrote:
> On September 12, a debug clobber build on my new Linux desktop took
> 12.7 minutes. Just then it t
2013/11/20 Gregory Szorc
> On Nov 20, 2013, at 9:37, Benoit Jacob wrote:
>
> > Talking about ideas for further extending the impact of UNIFIED_SOURCES,
> it
> > seems that the biggest limitation at the moment is that sources can't be
> > unified between different moz.build's. Because of that, so
I would favour a whiteboard tag or keyword on the bug tracking the build
failure. It should be easy enough to create a query for all open bugs
with this tag. Usually you want to get to the bug anyway for the latest
workaround and/or info on what to back out locally.
Cheers,
kats
On 13-11-19 1
Just a heads-up for other LLDB users...
The last few days I've been driven nuts by Xcode failing to stop at some
breakpoints (it just lists them as pending). I've now tracked this down to the
use of UNIFIED_SOURCES. The issue is explained here:
http://lldb.llvm.org/troubleshooting.html
Unf
On 2013-11-20 12:37 PM, Benoit Jacob wrote:
Talking about ideas for further extending the impact of UNIFIED_SOURCES, it
seems that the biggest limitation at the moment is that sources can't be
unified between different moz.build's. Because of that, source directories
that consist of many small su
On 2013-11-20 12:09 PM, Chris Peterson wrote:
It might be useful to add a files_per_unified_file parameter to
mozconfig or mach build. People could benchmark different values of
files_per_unified_file (trading off clobber vs incremental build times).
The same parameter could also be used to disab
On Nov 20, 2013, at 9:37, Benoit Jacob wrote:
> Talking about ideas for further extending the impact of UNIFIED_SOURCES, it
> seems that the biggest limitation at the moment is that sources can't be
> unified between different moz.build's. Because of that, source directories
> that consist of man
On Wed, Nov 20, 2013 at 10:01 AM, Jonathan Watt wrote:
> I may end up being the guinea pig that is perpetually having his builds
> broken because he has to have a patch applied to revert all UNIFIED_SOURCES
> lines back to SOURCES lines in order to debug anything...
>
Given that new versions of
On Wed, Nov 20, 2013 at 1:27 PM, Bobby Holley wrote:
> On Wed, Nov 20, 2013 at 10:01 AM, Jonathan Watt wrote:
>
> > I may end up being the guinea pig that is perpetually having his builds
> > broken because he has to have a patch applied to revert all
> UNIFIED_SOURCES
> > lines back to SOURCES
Ok. What should we do in the mean time? Does anyone know if it's possible
to get gdb going with XCode 5 on Mavericks?
On Wed, Nov 20, 2013 at 10:30 AM, Ehsan Akhgari wrote:
> On Wed, Nov 20, 2013 at 1:27 PM, Bobby Holley wrote:
>
>> On Wed, Nov 20, 2013 at 10:01 AM, Jonathan Watt wrote:
>>
>> >
On 20/11/2013 18:30, Ehsan Akhgari wrote:
On Wed, Nov 20, 2013 at 1:27 PM, Bobby Holley wrote:
On Wed, Nov 20, 2013 at 10:01 AM, Jonathan Watt wrote:
I may end up being the guinea pig that is perpetually having his builds
broken because he has to have a patch applied to revert all
UNIFIED_
On 2013-11-20 1:33 PM, Jonathan Watt wrote:
On 20/11/2013 18:30, Ehsan Akhgari wrote:
On Wed, Nov 20, 2013 at 1:27 PM, Bobby Holley
wrote:
On Wed, Nov 20, 2013 at 10:01 AM, Jonathan Watt wrote:
I may end up being the guinea pig that is perpetually having his builds
broken because he has to
On 2013-11-20 1:34 PM, Bobby Holley wrote:
Ok. What should we do in the mean time? Does anyone know if it's
possible to get gdb going with XCode 5 on Mavericks?
This should help in the mean time:
https://bugzilla.mozilla.org/show_bug.cgi?id=939583#c3
On Wed, Nov 20, 2013 at 10:30 AM, Ehsan A
On 11/19/13, 11:06 PM, Tim Abraldes wrote:
Possible compromise: have this info live in the tree as part of the
in-tree docs under build/docs. You need build peer review to update
those docs and they are versioned with the tree. That addresses my
accuracy and versioning concerns.
This sounds rea
While this analysis is interesting, it doesn't measure the impact of the
unified builds project directly, so I decided that now that a good chunk
of code is being compiled in unified mode we should get some specific
numbers on the improvements.
What I did was I took inbound as of ab70db6b27c8,
On 11/20/13, 9:49 AM, Benoit Jacob wrote:
2013/11/20 Gregory Szorc mailto:g...@mozilla.com>>
On Nov 20, 2013, at 9:37, Benoit Jacob mailto:jacob.benoi...@gmail.com>> wrote:
> Talking about ideas for further extending the impact of
UNIFIED_SOURCES, it
> seems that the bigges
> >>> Somebody stop me if this already exists...
> >>>
> >>> I'm envisioning a central location, probably a wiki page at
> >>> https://wiki.mozilla.org/BrokenBuilds or similar, where people can find
> >>> the answers to these questions:
> >>>1. Given my current build configuration, why did my l
> I would favour a whiteboard tag or keyword on the bug tracking the build
> failure. It should be easy enough to create a query for all open bugs
> with this tag. Usually you want to get to the bug anyway for the latest
> workaround and/or info on what to back out locally.
I'm not opposed to a wh
On 11/20/13, 1:15 PM, Tim Abraldes wrote:
I would favour a whiteboard tag or keyword on the bug tracking the build
failure. It should be easy enough to create a query for all open bugs
with this tag. Usually you want to get to the bug anyway for the latest
workaround and/or info on what to back o
I think the crux of this is to reduce the time m-i is closed is to have
better monitoring on things like the memory during testing so we can see
if it is growing during tests or change the tests that we don't care
about that assert or hide the test on TBPL so the sheriffs ignore it.
The best a
> >> Possible compromise: have this info live in the tree as part of the
> >> in-tree docs under build/docs. You need build peer review to update
> >> those docs and they are versioned with the tree. That addresses my
> >> accuracy and versioning concerns.
> >
> > This sounds reasonable to me! The
I just did a unified and non-unified build on my windows desktop -- non SSD.
VS2012, using mozmake. Full clobber. (mozmake -s -j8)
Unified: 20 min
Non-Unified: 36 min
This is huge! I was curious about the cost for incremental builds...
touch gfx/2d/Factory.cpp (part of a unified file), r
On 2013-11-18 5:41 PM, Ehsan Akhgari wrote:
I wouldn't go all the way to that extreme. The list of broken system
headers is unfortunately quite large, and we already have lots of this
pattern in the tree:
#ifdef MyFunction
// screw you, windows.h/X.h/etc.
#undef MyFunction
#endif
A small not
On 2013-11-20 12:37 PM, Benoit Jacob wrote:
Talking about ideas for further extending the impact of UNIFIED_SOURCES, it
seems that the biggest limitation at the moment is that sources can't be
unified between different moz.build's. Because of that, source directories
that consist of many small su
On 11/20/13, 2:02 PM, Zack Weinberg wrote:
On 2013-11-18 5:41 PM, Ehsan Akhgari wrote:
I wouldn't go all the way to that extreme. The list of broken system
headers is unfortunately quite large, and we already have lots of this
pattern in the tree:
#ifdef MyFunction
// screw you, windows.h/X.h
On Thu, Nov 21, 2013 at 11:06 AM, Zack Weinberg wrote:
> On 2013-11-20 12:37 PM, Benoit Jacob wrote:
>
>> Talking about ideas for further extending the impact of UNIFIED_SOURCES,
>> it
>> seems that the biggest limitation at the moment is that sources can't be
>> unified between different moz.bui
On 2013-11-20 5:17 PM, Gregory Szorc wrote:
On 11/20/13, 2:02 PM, Zack Weinberg wrote:
On 2013-11-18 5:41 PM, Ehsan Akhgari wrote:
I wouldn't go all the way to that extreme. The list of broken system
headers is unfortunately quite large, and we already have lots of this
pattern in the tree:
On 2013-11-20 5:27 PM, Robert O'Callahan wrote:
On Thu, Nov 21, 2013 at 11:06 AM, Zack Weinberg wrote:
On 2013-11-20 12:37 PM, Benoit Jacob wrote:
Talking about ideas for further extending the impact of UNIFIED_SOURCES,
it
seems that the biggest limitation at the moment is that sources can't
2013/11/20 Ehsan Akhgari
> On 2013-11-20 5:27 PM, Robert O'Callahan wrote:
>
>> On Thu, Nov 21, 2013 at 11:06 AM, Zack Weinberg wrote:
>>
>> On 2013-11-20 12:37 PM, Benoit Jacob wrote:
>>>
>>> Talking about ideas for further extending the impact of UNIFIED_SOURCES,
it
seems that the
On 20/11/2013 18:48, Ehsan Akhgari wrote:
On 2013-11-20 1:33 PM, Jonathan Watt wrote:
I'm still investigating this, and will contact them once I understand a
bit better what's going on. For now I still wanted to give other LLDB
using mozilla devs a heads-up though.
Thanks! Please keep us in t
On Thursday, November 21, 2013 9:37:05 AM UTC+10, Jonathan Watt wrote:
> When I first added the line to set target.inline-breakpoint-strategy in my
>
> ~/.lldbinit as per:
>
>
>
>http://lldb.llvm.org/troubleshooting.html
>
>
>
> it didn't work, even after restarting Xcode and starting a
On 2013-11-20 6:37 PM, Jonathan Watt wrote:
On 20/11/2013 18:48, Ehsan Akhgari wrote:
On 2013-11-20 1:33 PM, Jonathan Watt wrote:
I'm still investigating this, and will contact them once I understand a
bit better what's going on. For now I still wanted to give other LLDB
using mozilla devs a he
It's very annoying to have to download a full update of Nightly (~40MB)
if you miss one. It'd be a better experience to download two or more
partial updates (usually < 10MB) and have the updater install them
sequentially.
[NB. I'm not suggesting doing anything else in the build, unlike in bug
5
On 21/11/2013 00:20, Robert Kaiser wrote:
> As in a lot of cases we're seeing, there's apparently too little memory
> available for Windows to even create a minidump, we have pretty little
> info about those issues - but we do have our additional annotations we
> send along with the crash repor
On 20/11/2013 01:30, Boris Zbarsky wrote:
> On 11/19/13 12:26 PM, Anne van Kesteren wrote:
>> On Tue, Nov 19, 2013 at 5:17 PM, Boris Zbarsky wrote:
>>> It's been the case since late August, though the behavior is a bit
>>> different: only thrown Errors or rejections with an Error are logged, not
>
On 11/20/2013 9:27 PM, Philip Chee wrote:
Currently, I'm getting this in the Error Console a few seconds after
startup:
Thu Nov 21 2013 13:23:23
Error: A promise chain failed to handle a rejection.
Date: Thu Nov 21 2013 13:23:13 GMT+0800 (Malay Peninsula Standard Time)
Full Message: [object St
On 11/19/2013 10:08 PM, Gregory Szorc wrote:
> On 11/18/13, 11:15 PM, Gregory Szorc wrote:
>> Do builds feel like they've gotten faster in the last few weeks^hours?
>> It's because they have.
>>
>> When I did my MacBook Pro comparison [1] with a changeset from Oct 28,
>> build times on my 2013 2.6
On Thu, Nov 21, 2013 at 4:17 AM, Geoff Lankow wrote:
> Has this been discussed before? If so, what was the outcome? Are there bugs
> filed? I didn't find any but I don't really know what to search for.
There's also https://bugzilla.mozilla.org/show_bug.cgi?id=353804,
which I think would alleviate
While that might makes sense to implement for nightly, aurora, and
possibly beta builds it doesn't makes sense to implement for release
builds where the vast majority of users are and there are many higher
priority bugs to work on that affect nightly, aurora, beta, and release.
On 11/20/2013 7
58 matches
Mail list logo
