On Aug 27, 2014, at 5:18, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
On 2014-08-26, 11:54 PM, Mike Hommey wrote:
On Tue, Aug 26, 2014 at 11:34:29PM -0400, Ehsan Akhgari wrote:
On 2014-08-26, 6:05 PM, Mike Hommey wrote:
On Tue, Aug 26, 2014 at 10:40:39AM -0400, Ehsan Akhgari wrote:
On 8/27/2014 6:52 AM, Benjamin Smedberg wrote:
On 8/27/14, 9:47 AM, Gregory Szorc wrote:
I interpret this this use case as building a related set of object
files for the purpose of quick/imprecise validation of changes to a
specific component. So what you really want is to build specific
On 8/27/2014 7:39 AM, Benjamin Smedberg wrote:
On 8/27/14, 10:22 AM, Gregory Szorc wrote:
There is additional cognitive load required to map a logical feature
into a set of directories. I would prefer this burden go away, as it
only breeds confusion and a higher barrier to contributing (new
On 8/27/14 10:02 AM, Boris Zbarsky wrote:
On 8/27/14, 12:29 PM, Steve Fink wrote:
Enumerating some of them:
Let me add one:
6. I touched a file or files. Rebuild only the compiled-code tests
that test this stuff.
Let's try to capture |mach build| workflows and requirements in an
(Apologies if this is a double post. The archives say this never made it
to dev.platform.)
There will be a large gathering of Mercurial contributors this weekend
discuss the future of Mercurial and to set an agenda for improving it.
Proposed topics are listed at [1].
Mozilla is one of the
On 8/22/14 9:08 AM, Ehsan Akhgari wrote:
Unfortunately I don't really understand the reasons behind this, but if you
use this command, please know that it doesn't work properly any more, even
if it seems to work in some cases. AFAICT the workarounds are either doing
a full build or ./mach build
On 8/25/14 11:00 AM, Ehsan Akhgari wrote:
On 2014-08-25, 1:54 PM, Nathan Froyd wrote:
- Original Message -
Often my workflow looks something like this:
change files in directory D
rebuild only D, get a list of errors to fix
...iterate until no more errors
try to rebuild a few related
On 8/25/14 1:15 PM, L. David Baron wrote:
On Monday 2014-08-25 10:27 -0700, Bill McCloskey wrote:
Even if a full no-op build took no time, partial builds are still useful. Often
my workflow looks something like this:
change files in directory D
rebuild only D, get a list of errors to fix
On 8/25/14 3:06 PM, Ehsan Akhgari wrote:
On 2014-08-25, 4:49 PM, Gregory Szorc wrote:
On 8/25/14 1:15 PM, L. David Baron wrote:
On Monday 2014-08-25 10:27 -0700, Bill McCloskey wrote:
Even if a full no-op build took no time, partial builds are still
useful. Often my workflow looks something
On 8/20/14 10:58 AM, James Graham wrote:
On 20/08/14 18:38, Joshua Cranmer wrote:
On 8/20/2014 12:22 PM, L. David Baron wrote:
(I estimated that it was going to be faster to get that working than
to try to figure out how to use the packaged tests, since it was
possible to reverse-engineer
On 8/19/14 1:53 AM, Neil wrote:
Gregory Szorc wrote:
On 8/18/2014 4:45 PM, Neil wrote:
Time was that you could just python runtests.py to run mochitests.
Then we needed modules that you don't get in the default python, so
you had to invoke python from the virtualenv instead.
Now
On 8/19/14 2:11 PM, Neil wrote:
Gregory Szorc wrote:
I think the underlying bug here is mach mochitest doesn't work for
comm-central. It should. I'm sure there is a bug on file somewhere.
Fair enough, but for when it does work, what's the mach version of
python runtests.py?
mach mochitest
On 8/18/2014 4:45 PM, Neil wrote:
Time was that you could just python runtests.py to run mochitests.
Then we needed modules that you don't get in the default python, so you
had to invoke python from the virtualenv instead.
Now that doesn't work either, because it's trying to run
On 8/13/14 9:21 AM, Edwin Wong wrote:
Hi dev-platform,
TL;DR - Cloud Services and Quality Engineering would like to propose the creation of
a directory named “external in gecko and gaia repos for externally dependent
tests.
This enables features married to Cloud Services such as Loop,
On 8/12/14 12:08 AM, Yonggang Luo wrote:
Now I am trying to building a xpcom components, but it have multiple
.idl file to compiled into a single xpt component, how to do that?
Here is the code the build system uses for XPIDLs:
The server-side Mercurial hooks living in
https://hg.mozilla.org/hgcustom/hghooks/ have been migrated to the
hghooks/ directory of
https://hg.mozilla.org/hgcustom/version-control-tools/.
This change will enable:
* Code/hook sharing between client and server (version-control-tools is
already
The possibility of using JavaScript Object Signing and Encryption (JOSE)
- specifically the verification part of the JSON Web Signature (JWS)
component - came up as part of planning a JavaScript-based feature I'm
working on.
We don't appear to have an implementation in mozilla-central yet.
On 8/4/14, 10:39 AM, Dave Townsend wrote:
I've done a little investigation into marionette and I've found a few
issues with it:
Firstly it doesn't look like running marionette directly or through mach
allows developers to select individual directories or test files to run,
rather it is a
I just installed a fresh version of Ubuntu Server 14.04.1 and
bootstrap.py works great for me.
The bootstrap script is verifying you have Mercurial 3.0+ installed and
falling back to installing from the PPA if not. You can always install
Mercurial 3.0+ manually to bypass the PPA.
On 7/29/14, 12:27 AM, Mike Hommey wrote:
On Tue, Jul 29, 2014 at 02:59:17PM +0800, Philip Chee wrote:
On 29/07/2014 08:32, Mike Hommey wrote:
Hi,
I'd like to inform you today that choosing the right variable when
adding a new directory to the tree just got a lot easier with the
landing of bug
On 7/15/14, 11:49 AM, Dave Townsend wrote:
Since forever Jetpack tests in the Firefox trees have been run using our
custom python CFX tool which is based on a fork of an ancient version of
mozrunner. This causes us a number of problems. Keeping up with tree
visibility rules is hard. Some
On 7/10/14, 6:54 PM, Yonggang Luo wrote:
I found following code in `runxpcshelltests.py`:
def buildXpcsRunArgs(self):
Add arguments to run the test or make it interactive.
if self.interactive:
self.xpcsRunArgs = [
'-e',
On 7/9/14, 8:21 PM, Yonggang Luo wrote:
In the moz.build files, there is specified XPCSHELL_TESTS_MANIFESTS,
but I can not found where to processing this variable/files in mozbuild system.
See the following:
On 7/4/14, 7:46 AM, David Rajchenbach-Teller wrote:
Well, we basically have the Windows version implemented already. We
could possibly use Watchman for other platforms. How do others feel
about introducing a dependency towards Watchman?
The inotify limitation on watchers is indeed annoying in
On 7/7/14, 10:53 AM, Josh Matthews wrote:
Garvan is referring to JS files that implement XPCOM interfaces. It's
impossible to test internal details of the components without exposing
them via an interface, which can end up convoluting the code in some cases.
Really? I thought you could
On 7/3/14, 1:22 AM, Yonggang Luo wrote:
This is the blocker that stops the remove of Makefile.in in building systems.
Not all variables have been ported to moz.build yet. It's perfectly
acceptable to define this variable in a Makefile.in for the time being.
On 7/2/14, 4:21 AM, Mike Hommey wrote:
On Wed, Jul 02, 2014 at 12:43:47PM +0200, Axel Hecht wrote:
On 7/2/14 12:25 PM, Yonggang Luo wrote:
I am using Mozilla XUL SDK to build my own application, So I'd like
to know what's the format of jar.mn file
Took me a while to find it, but I think
I've written a cross-platform file watching API for Windows/OS X/Linux
before. It's no fun.
I would strongly recommend using an existing higher-level abstraction
layer because implementing this ourselves will lead to constant edge
case discovery and bug fixing. I'd like to think that any
On 7/2/14, 9:48 AM, Gijs Kruitbosch wrote:
On 02/07/2014 17:46, Joshua Cranmer wrote:
On 7/2/2014 11:18 AM, Gregory Szorc wrote:
I find the current state extremely frustrating. I had big plans for
the in-tree docs, including capturing JavaScript docs and having JSM
APIs automatically
On 6/25/14, 8:15 AM, Jason Orendorff wrote:
We're considering building a JavaScript API for dynamic analysis of JS
code.
Here's the sort of thing you could do with it:
- Gather code coverage information (useful for testing/release mgmt?)
As someone who develops JS for Firefox features,
On 6/20/14, 5:00 AM, Joshua Cranmer wrote:
On 6/20/2014 4:25 AM, Sylvestre Ledru wrote:
It takes around 26 hours on my workstation to run all the tests
and about 4 days on (old?) Macbook pro.
I haven't work on improving this yet.
I am mildly distrustful of results that aren't running on as
On 6/3/14, 6:42 AM, Ben Hearsum wrote:
On 14-06-03 06:39 AM, Gabor Krizsanits wrote:
From time to time, no matter what platform I use, the build configuration on
the try server changes
and from that point on it's just a matter of time that my build gets broken.
When you're
about to work on
On 4/16/14, 10:02 AM, Bobby Holley wrote:
On Wed, Apr 16, 2014 at 9:47 AM, Robert Kaiser ka...@kairo.at wrote:
That's a good step. IMHO, often another good step is to mostly separate
every patch to its own bug (I know there are cases where it might not makes
sense, but often it does) so that
On 4/14/14, 8:31 AM, Boris Zbarsky wrote:
On 4/14/14 5:13 AM, Aryeh Gregor wrote:
But doesn't Mercurial hide all but the first line by
default in the places you'd normally look for it (e.g., log)?
The normal place I'd look for the detailed message is something like
I came across the following articles on source control and code review:
*
https://secure.phabricator.com/book/phabflavor/article/recommendations_on_revision_control/
*
https://secure.phabricator.com/book/phabflavor/article/writing_reviewable_code/
*
On 4/8/14, 6:51 AM, James Graham wrote:
On 08/04/14 14:43, Andrew Halberstadt wrote:
On 07/04/14 11:49 AM, Aryeh Gregor wrote:
On Mon, Apr 7, 2014 at 6:12 PM, Ted Mielczarek t...@mielczarek.org
wrote:
If a bug is causing a test to fail intermittently, then that test loses
value. It still has
On 4/9/14, 11:29 AM, L. David Baron wrote:
On Wednesday 2014-04-09 11:00 -0700, Gregory Szorc wrote:
The simple solution is to have a separate in-tree manifest
annotation for intermittents. Put another way, we can describe
exactly why we are not running a test. This is kinda/sorta the realm
On 4/9/14, 2:07 PM, Karl Tomlinson wrote:
Gregory Szorc writes:
2) Run marked intermittent tests multiple times. If it works all
25 times, fail the test run for inconsistent metadata.
We need to consider intermittently failing tests as failed, and we
need to only test things that always pass
On 3/29/14, 5:55 AM, Paolo Amadini wrote:
With bug 988122 landing soon, you'll now find a Promise object
available by default in the global scope of JavaScript modules.
However, this default implementation is still limited, and you're
strongly recommended to import Promise.jsm explicitly in new
On 3/28/14, 10:31 AM, ISHIKAWA,chiaki wrote:
Recently after a refesh of code from comm-central,
I noticed that running |make mozmill|
TB test suite using full DEBUG BUILD of TB produced the
following warning lines:
System JS : WARNING
On 3/28/14, 2:16 PM, Chris Peterson wrote:
warp is Facebook's new C/C++ preprocessor, written by Walter Bright (in
D, of course). They claim build time (not just preprocessing time) of
10% to 40%.
https://code.facebook.com/posts/476987592402291/under-the-hood-warp-a-fast-c-and-c-preprocessor
On 3/27/14, 6:37 AM, Justin Wood (Callek) wrote:
On 3/26/2014 9:15 PM, Taras Glek wrote:
Bobby Holley mailto:bobbyhol...@gmail.com
Wednesday, March 26, 2014 17:27
I don't understand what the overhead is. We don't run CI on user
repos. It's effectively just ssh:// + disk space, right? That
On 3/26/14, 4:53 PM, Taras Glek wrote:
*User Repos*
TLDR: I would like to make user repos read-only by April 30th. We should
archive them by May 31st.
Time spent operating user repositories could be spent reducing our
end-to-end continuous integration cycles. These do not seem like
On 3/25/14, 6:21 PM, Mike Hommey wrote:
Hi,
In the coming days and weeks, there are going to be a few changes to how
we do automated build on Windows, all in the interest of faster build
times:
- Shared compilation cache is going to be deployed soon(ish). We
currently have no compilation
On 3/26/14, 10:11 PM, Mike Hommey wrote:
On Wed, Mar 26, 2014 at 05:40:36PM -0700, Gregory Szorc wrote:
On 3/26/14, 4:53 PM, Taras Glek wrote:
*User Repos*
TLDR: I would like to make user repos read-only by April 30th. We should
archive them by May 31st.
Time spent operating user
On 3/25/14, 3:14 PM, Andrew Halberstadt wrote:
With the completion of bug 981030 test harness options are now defined
in-tree.
This means any push without this patch [1] will fail. I already went
ahead and landed it on all release branches, but if you have an
integration or project branch, you
Could someone please provide an update on reducing compartment overhead?
Are we at a point where things like services/healthreport/HealthReport.jsm
should be considered a necessary evil rather than a gross hack?
What other solutions besides concatenating files and lazy loading are there?
On 3/21/14, 1:37 AM, Nicholas Nethercote wrote:
On Fri, Mar 21, 2014 at 12:16 AM, Gregory Szorc g...@mozilla.com wrote:
Could someone please provide an update on reducing compartment overhead?
Are we at a point where things like services/healthreport/HealthReport.jsm should be considered
On 3/21/14, 9:36 AM, Bill McCloskey wrote:
- Original Message -
From: Gregory Szorc g...@mozilla.com
To: Nicholas Nethercote n.netherc...@gmail.com
Cc: dev-platform dev-platform@lists.mozilla.org
Sent: Friday, March 21, 2014 9:27:34 AM
Subject: Re: Too many system compartments at start
On 3/21/14, 9:06 AM, Bill McCloskey wrote:
- Original Message -
From: Bobby Holley bobbyhol...@gmail.com
To: Benjamin Smedberg benja...@smedbergs.us
Cc: dev-platform dev-platform@lists.mozilla.org, Nicholas Nethercote
n.netherc...@gmail.com
Sent: Friday, March 21, 2014 8:02:58 AM
On 3/20/14, 10:38 AM, Irving Reid wrote:
Looking into some odd exceptions in the Addon Manager (bug 985998), I
found that the behaviour of the Preference service is:
a) We infer the type of a preference from the data read in from prefs.js
(see e.g.
On 3/20/14, 10:50 AM, Gregory Szorc wrote:
On 3/20/14, 10:38 AM, Irving Reid wrote:
Looking into some odd exceptions in the Addon Manager (bug 985998), I
found that the behaviour of the Preference service is:
a) We infer the type of a preference from the data read in from prefs.js
(see e.g
On 2/28/14, 5:24 PM, Hal Wine wrote:
tl;dr: what is the balance point between pushes to try taking too long
and loosing repository history of recent try pushes?
Summary:
As most developers have experienced, pushing to try can sometimes take a
long time. Once it takes too long (as
On 3/2/14, 1:46 PM, Axel Hecht wrote:
Hi,
I've watched you guys thinking for an hour ;-)
Some comments from me.
Yes to moving build flows that generate assets into the tree.
Yes to having a way for developers to reproduce what automation does.
Yes to having jobs being executed more on demand
On 2/27/2014 2:02 PM, Nicholas Nethercote wrote:
On Thu, Feb 27, 2014 at 12:44 PM, Zack Weinberg za...@panix.com wrote:
Treating these as warnings, not errors, is probably the best thing
here. If you see the warning and you've recently changed that
code, then check it. If you haven't, you
(This is likely off-topic for many dev-platform readers. I was advised
to post here because RelEng monitors dev-platform and I don't like
cross-posting.)
The technical interaction between build automation and mozilla-central
has organically grown into something that's very difficult to
On 2/28/14, 1:28 PM, Boris Zbarsky wrote:
On 2/28/14 3:48 PM, Gregory Szorc wrote:
* A lot of us want to kill client.mk. Having automation not directly
calling it will allow us to finally do this.
This will make bisects a bit exciting, because the right command to run
to do a toplevel build
https://bugzilla.mozilla.org/show_bug.cgi?id=977292
Assigned to nobody.
On 2/26/2014 12:49 PM, Andreas Gal wrote:
This sounds like quite an opportunity to shorten download times and reduce
CDN load. Who wants to file the bug? :)
Andreas
On Feb 26, 2014, at 9:44 PM, Benjamin Smedberg
On Feb 22, 2014, at 8:18, Kyle Huey m...@kylehuey.com wrote:
If you needed another reason to follow the style guide:
https://www.imperialviolet.org/2014/02/22/applebug.html
Code coverage would have caught this as well.
The time investment into 100% line and branch coverage is debatable. But
The tree (only inbound so far) now has (alpha) support for generating
Visual Studio Project files.
Features:
* IntelliSense works
* Build from within Visual Studio
* Launch binaries from Visual Studio
* Debug symbols loaded automatically (breakpoints work)
Please read
On 2/13/14, 1:23 PM, Honza Bambas wrote:
An optional /* @reviewer: m...@foo.com */ comment under the license would
do. If not present, find reviewer the usual way (not always hitting the
right person).
Reason is that despite we have peer lists, sometimes files are
written/maintained by
On 8/7/13, 1:00 PM, d...@dmik.org wrote:
пятница, 2 августа 2013 г., 3:13:23 UTC+4 пользователь Gregory Szorc написал:
Are there any objections to this proposal?
Hello everybody, I'm the person who's being actively working now on getting
Mozilla build on OS/2 again with all the new IPC
it
is!)
Gavin
On Wed, Feb 5, 2014 at 6:21 PM, Gregory Szorc g...@mozilla.com
mailto:g...@mozilla.com wrote:
There are a number of people who can't use mach because of the
way it does
environment detection (e.g. how it resolves object directories
and other
paths
On 2/6/14, 11:21 AM, Dave Townsend wrote:
On Thu, Feb 6, 2014 at 10:57 AM, Gregory Szorc g...@mozilla.com
mailto:g...@mozilla.com wrote:
On 2/6/14, 9:23 AM, Dave Townsend wrote:
I assume the second section is actually getcwd() not in objdir
but is
in srcdir
On 2/6/14, 11:34 AM, Dave Townsend wrote:
I think perhaps I wasn't clear. I'd expect getcwd() not in
objdir nor
srcdir to have as the first option look for the srcdir based
on the
location of the called mach script. So I can do srcdir/mach and
have
There are a number of people who can't use mach because of the way it
does environment detection (e.g. how it resolves object directories and
other paths).
There are numerous bugs on the issue. We even have bug 912114 tracking
everywhere that mach and the build system is doing something wrong
On 2/4/14, 3:33 PM, Nicholas Nethercote wrote:
On Mon, Feb 3, 2014 at 2:32 PM, Taras Glek tg...@mozilla.com wrote:
A few people noticed that we do not have a nice, searchable knowledge base
for Gecko tech. We have places to ask questions such as various newsgroups,
irc and places to document
On 1/31/14, 3:25 PM, Paolo Amadini wrote:
I have just filed bugs to make sure our DOM Promise implementation is
on par with Promise.jsm in these areas:
- Make state, value and reason inspectable in the debugger (bug 966471)
- Report all unhandled rejections to the Console on GC (bug 966452)
On 2/3/14, 9:13 AM, Boris Zbarsky wrote:
On 2/3/14 11:48 AM, Gregory Szorc wrote:
what's the impact of this on performance?
It's hard to say without an example of the sort of code whose
performance we're worried about.
because promises involve multiple function calls instead of a single
On 1/28/14, 7:15 PM, Anthony Jones wrote:
On 28/01/14 13:08, Nicholas Nethercote wrote:
In the meantime, we should wrap up the pending discussions about other
changes to the style guide, such as 80/100/infinite columns,
member/parameter/local naming convention, and other threads that Gavin was
As a temporary workaround until upstream gets patched, we're downloading and
running hosted binaries from ajone's people account (with consent of course).
He hasn't built the binary for OS X yet.
On Jan 22, 2014, at 18:19, Bobby Holley bobbyhol...@gmail.com wrote:
On OSX10.9, I get:
On 1/21/14, 10:25 AM, Ehsan Akhgari wrote:
On 1/21/2014, 12:54 PM, Gregory Szorc wrote:
On 1/21/14, 9:05 AM, Ehsan Akhgari wrote:
It seems to me like the splitting algorithm for mochitests gives us
different chunking results on different platforms, see this test failure
for example:
https
On 1/6/14, 7:12 AM, Ehsan Akhgari wrote:
With Birunthan's restless efforts in bug 784739, we have finally removed
the usage of NULL in our C++ code. Please stop using NULL in new C++ code,
and use nullptr instead!
Can we update the Clang plugin to emit an error (and turn the tree red)
if a
On 1/6/14, 10:54 AM, Trevor Saunders wrote:
On Mon, Jan 06, 2014 at 01:35:38PM -0500, Ehsan Akhgari wrote:
On 1/6/2014, 1:20 PM, Gregory Szorc wrote:
On 1/6/14, 7:12 AM, Ehsan Akhgari wrote:
With Birunthan's restless efforts in bug 784739, we have finally removed
the usage of NULL in our C
On 1/6/14, 11:32 AM, Martin Thomson wrote:
On 2014-01-06, at 11:25, Gregory Szorc g...@mozilla.com wrote:
Clang provides access to the low-level token stream [1]. This is available via
libclang (the C API) and the Python bindings and I'm pretty sure you can access
this info from plugins
On 1/6/14, 3:35 PM, Daniel Holbert wrote:
On 01/06/2014 03:10 PM, Karl Tomlinson wrote:
Martin Thomson writes:
I would like to think that adding (or removing) braces from block statements
should be acceptable.
I would argue that braces should not be added with automation.
When debugging
On Jan 6, 2014, at 17:10, Karl Tomlinson mozn...@karlt.net wrote:
Gregory Szorc writes:
I think you just gave an example of why our tooling needs to
identify poorly formatted code better. An if without a brace
followed by multiple indented lines containing compiler
expressions is a bug
We have an in-tree Clang plugin in build/clang-plugin that can be used
to deploy more in-depth checking on top of the AST. You can have it emit
compiler warnings or errors. It runs as part of automation, so if you
write a checker, the tree will burn and bad commits will get backed out.
A
On 12/16/13, 12:58 AM, Gijs Kruitbosch wrote:
From what I've been able to tell from the interwebs, extracting
documentation (autodoc-fashion) from JS/C++/IDL isn't possible with
Sphinx. Is that correct?
It is possible.
Sphinx can consume Doxygen's XML output to generate C++ docs via Breathe
On 12/16/13, 10:46 AM, Jeff Walden wrote:
On 12/16/2013 01:17 PM, Gregory Szorc wrote:
Does SpiderMonkey expose documentation blocks to the AST? If not, should it?
No, and probably not. Comments are not tokens, so they're not in the AST.
Right now SpiderMonkey pretty much just throws them
Ehsan,
I'm sure I'm speaking for many Mozillians when I say thank you for running this
service - from building on Chris Double's initial work, keeping it running
while dealing with GitHub shenanigans, and for assisting with a transition plan
to its natural successor. You could easily have done
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
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
On 11/30/13, 11:16 AM, Gregory Szorc wrote:
On 11/30/13, 3:24 AM, smaug wrote:
(Before using unified mode I didn't have mem usage problems with gcc and
there was never any significant
difference in build times comparing to clang.)
I filed bug 944842 to have mach report swapping during builds
On 12/12/13, 6:14 AM, Neil wrote:
Gregory Szorc wrote:
On 11/30/13, 11:16 AM, Gregory Szorc wrote:
On 11/30/13, 3:24 AM, smaug wrote:
(Before using unified mode I didn't have mem usage problems with gcc
and there was never any significant difference in build times
comparing to clang.)
I
On 11/30/13, 7:06 PM, Neil wrote:
Gregory Szorc wrote:
There are also plans to offer a build mode for non-Gecko developers
that downloads a pre-built libxul so these developers don't have to
spend many minutes building Gecko.
Isn't it already possible to build both Firefox and Thunderbird
On 11/29/13, 4:00 AM, Ehsan Akhgari wrote:
On 11/25/2013, 7:41 PM, Gregory Szorc wrote:
The repo was hiding that old changeset because it has been obsoleted
(Mercurial changeset evolution magic). I updated the server config to
expose hidden changesets, so the link works again.
However
On 11/30/13, 3:24 AM, smaug wrote:
Hi all and FYI
unified build mode has increased memory usage of building with gcc
significantly.
On my laptop (8 gig mem) I started to see some swapping, and because of
that
build times with unified mode weren't that much better than before.
But now, finally
On 11/29/13, 5:12 AM, Ehsan Akhgari wrote:
On 11/28/2013, 4:55 PM, Mike Hoye wrote:
On 11/28/2013, 4:45 PM, Nicholas Nethercote wrote:
I'm pretty sure that gps was saying if you're paid to work by
Mozilla, get a faster machine. More generally, we're all in furious
agreement: fast builds are
On 11/21/13, 10:38 PM, Gregory Szorc wrote:
On 11/20/13, 9:57 PM, Gregory Szorc wrote:
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
On 11/28/13, 12:21 PM, Gabriele Svelto wrote:
On 28/11/2013 06:06, Gregory Szorc wrote:
On de5aa094b55f, we're now down to:
Wall 7:37 (457)
User 45:38 (2738)
Sys3:54 (234)
Total 49:32 (2972)
That's with WebRTC and ICU enabled.
Looking at my own stats while building I
Akhgari wrote:
This patch doesn't seem to exist any more. Do you have another copy of
it lying somewhere?
Thanks!
--
Ehsan
http://ehsanakhgari.org/
On Fri, Nov 15, 2013 at 12:43 AM, Gregory Szorc g...@mozilla.com
mailto:g...@mozilla.com wrote:
C++ developers,
Over 90% of the CPU time
It looks like GitHub decided to disable Ehsan's repo and all forks
without notice. https://bugzilla.mozilla.org/show_bug.cgi?id=943132
tracks it from our end.
On 11/25/13, 11:39 PM, Ehsan Akhgari wrote:
Dear all,
For the past two and a half years I have been maintaining a git mirror
of
On Nov 22, 2013, at 13:16, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
On Fri, Nov 22, 2013 at 1:02 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/22/13 11:41 AM, Ehsan Akhgari wrote:
Hmm to the best of my knowledge, we don't generate the *.i files unless
if you explicitly request them.
On 11/21/13, 8:40 AM, Ehsan Akhgari wrote:
On 2013-11-21 10:44 AM, Ed Morley wrote:
On 21 November 2013 15:38:28, Ehsan Akhgari wrote:
We don't, we clobber periodically. I'm not sure why that is better
than never clobbering...
We've been force-clobbering 1-2 times a day in automation for
On 11/21/13, 7:06 AM, Michael Shal wrote:
From: Gregory Szorc g...@mozilla.com
Unified sources have probably saved sufficient CPU cycles across all of
automation to more than offset having a non-unified build-only job. I'll
defer to the Platform Team (Ehsan?) to request that from Release
On 11/21/13, 1:12 PM, Laura Thomson wrote:
I can explain a little more about the motivation.
bonsai is old code, and written in very old-fashioned perl. As such, security
bugs are frequently filed against it, and it's very hard to find people who are
willing and able to fix them. If you are
On 11/20/13, 9:57 PM, Gregory Szorc wrote:
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
On Nov 20, 2013, at 9:37, Benoit Jacob jacob.benoi...@gmail.com 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
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
301 - 400 of 526 matches
Mail list logo
