a1ea875581587dac752d541e09e66123150b4078: Fixup for bug 1172632 on a CLOSED TREE. r=me
Mike Hommey <mh+mozilla@glandium.org> - Wed, 10 Jun 2015 11:17:45 +0900 - rev 247862
Push 28885 by cbook@mozilla.com at Wed, 10 Jun 2015 13:18:59 +0000
Fixup for bug 1172632 on a CLOSED TREE. r=me
e1c4c278b3b337c0b6fd4604ed95789bc1e9b2d1: Bug 1170454: Fix up instance type for VAOs. r=smaug,r=jgilbert
Dan Glastonbury <dglastonbury@mozilla.com> - Mon, 01 Jun 2015 16:49:47 +1000 - rev 247861
Push 28885 by cbook@mozilla.com at Wed, 10 Jun 2015 13:18:59 +0000
Bug 1170454: Fix up instance type for VAOs. r=smaug,r=jgilbert
89a60988b587d76829bc3e0409f4a7bfb5cd348b: Bug 1169769 - Stop pretending js/src is a top-level directory. r=gps
Mike Hommey <mh+mozilla@glandium.org> - Wed, 10 Jun 2015 09:21:24 +0900 - rev 247860
Push 28885 by cbook@mozilla.com at Wed, 10 Jun 2015 13:18:59 +0000
Bug 1169769 - Stop pretending js/src is a top-level directory. r=gps It hasn't been a top-level directory since bug 969164.
bcea81eae808ed420c51423dfb7ce3c09793de23: Bug 1172668 - Unbreak DMD on OS X after bug 1168719. r=gps
Mike Hommey <mh+mozilla@glandium.org> - Wed, 10 Jun 2015 09:00:34 +0900 - rev 247859
Push 28885 by cbook@mozilla.com at Wed, 10 Jun 2015 13:18:59 +0000
Bug 1172668 - Unbreak DMD on OS X after bug 1168719. r=gps Bug 1168719 added a generic replace malloc library which name happened to be the same as the existing dummy library used to link replace malloc on OSX. Change the name of that dummy library.
5c0acaf8f47857f634ffdf3151f5418f18cbb97d: bug 1172632 - Move some allocator related configure checks in a common location for both top-level and js/src to use. r=mshal
Mike Hommey <mh+mozilla@glandium.org> - Wed, 10 Jun 2015 09:58:50 +0900 - rev 247858
Push 28885 by cbook@mozilla.com at Wed, 10 Jun 2015 13:18:59 +0000
bug 1172632 - Move some allocator related configure checks in a common location for both top-level and js/src to use. r=mshal
46dde6cfd3036e6839657cf779e80ad6240354cb: Bug 1172632 - Don't guess malloc_usable_size type of argument based on ANDROID_VERSION in mozjemalloc, but use the result of the configure test instead. r=njn
Mike Hommey <mh+mozilla@glandium.org> - Tue, 09 Jun 2015 09:54:24 +0900 - rev 247857
Push 28885 by cbook@mozilla.com at Wed, 10 Jun 2015 13:18:59 +0000
Bug 1172632 - Don't guess malloc_usable_size type of argument based on ANDROID_VERSION in mozjemalloc, but use the result of the configure test instead. r=njn
f7acbdc32c612056eaf72f953e19770f243ea6b4: Backed out 5 changesets (bug 1171716) for android bustage
Wes Kocher <wkocher@mozilla.com> - Tue, 09 Jun 2015 18:48:37 -0700 - rev 247856
Push 28885 by cbook@mozilla.com at Wed, 10 Jun 2015 13:18:59 +0000
Backed out 5 changesets (bug 1171716) for android bustage Backed out changeset 4986f8464f9c (bug 1171716) Backed out changeset bc8405b07d10 (bug 1171716) Backed out changeset 10e18e494630 (bug 1171716) Backed out changeset be499a3cae5d (bug 1171716) Backed out changeset f75717d3eba0 (bug 1171716)
4986f8464f9c4629144ca73fc973003cf388cf1a: Bug 1171716 - Part 5: Use NS_ReleaseOnMainThread in HttpBaseChannel dtor. r=froydnj
Eric Rahm <erahm@mozilla.com> - Tue, 09 Jun 2015 18:25:48 -0700 - rev 247855
Push 28885 by cbook@mozilla.com at Wed, 10 Jun 2015 13:18:59 +0000
Bug 1171716 - Part 5: Use NS_ReleaseOnMainThread in HttpBaseChannel dtor. r=froydnj
bc8405b07d107d856fd2dfd089ea0bb71537e232: Bug 1171716 - Part 4: Use NS_ReleaseOnMainThread in JarChannel dtor. r=froydnj
Eric Rahm <erahm@mozilla.com> - Tue, 09 Jun 2015 18:25:47 -0700 - rev 247854
Push 28885 by cbook@mozilla.com at Wed, 10 Jun 2015 13:18:59 +0000
Bug 1171716 - Part 4: Use NS_ReleaseOnMainThread in JarChannel dtor. r=froydnj
10e18e49463030f1cdfcb27e827c4fe4dd9a7d49: Bug 1171716 - Part 3: Use NS_ReleaseOnMainThread in WebSocketChannel dtor. r=froydnj
Eric Rahm <erahm@mozilla.com> - Tue, 09 Jun 2015 18:25:46 -0700 - rev 247853
Push 28885 by cbook@mozilla.com at Wed, 10 Jun 2015 13:18:59 +0000
Bug 1171716 - Part 3: Use NS_ReleaseOnMainThread in WebSocketChannel dtor. r=froydnj
be499a3cae5d741b7a1a1ca5fc8b91fc0cdf6d68: Bug 1171716 - Part 2: Use NS_ReleaseOnMainThread in nsBaseChannel. r=froydnj
Eric Rahm <erahm@mozilla.com> - Tue, 09 Jun 2015 18:25:44 -0700 - rev 247852
Push 28885 by cbook@mozilla.com at Wed, 10 Jun 2015 13:18:59 +0000
Bug 1171716 - Part 2: Use NS_ReleaseOnMainThread in nsBaseChannel. r=froydnj
f75717d3eba012a76cabe0a5aa512320b9f8f6d8: Bug 1171716 - Part 1: Add NS_ReleaseOnMainThread. r=froydnj
Eric Rahm <erahm@mozilla.com> - Tue, 09 Jun 2015 18:25:43 -0700 - rev 247851
Push 28885 by cbook@mozilla.com at Wed, 10 Jun 2015 13:18:59 +0000
Bug 1171716 - Part 1: Add NS_ReleaseOnMainThread. r=froydnj
a7d7921c934544346369fa6832bf57191de77503: Bug 1168607 - Add a native Mercurial finder; r=glandium
Gregory Szorc <gps@mozilla.com> - Tue, 09 Jun 2015 13:49:45 -0700 - rev 247850
Push 28885 by cbook@mozilla.com at Wed, 10 Jun 2015 13:18:59 +0000
Bug 1168607 - Add a native Mercurial finder; r=glandium The hglib Mercurial finder was nice. But it is somewhat slow, as it involves a separate Mercurial process. This commit introduces a native Mercurial finder that speaks directly to a Mercurial repository instance. It is significantly faster. The new code is isolated to its own file because it imports Mercurial code, which is GPL.
96934755c9c5bda247aa8f7601344fc6787fe942: Bug 1168607 - Make `mach file-info` work with Mercurial repos; r=glandium
Gregory Szorc <gps@mozilla.com> - Tue, 09 Jun 2015 13:43:22 -0700 - rev 247849
Push 28885 by cbook@mozilla.com at Wed, 10 Jun 2015 13:18:59 +0000
Bug 1168607 - Make `mach file-info` work with Mercurial repos; r=glandium This commit adds support for specifying a Mercurial revision with `mach file-info`. Aside from being a potentially useful feature, it proves that MercurialRevisionFinder works with BuildReader.
1b4a8275f7f2c2f2474f780e3b9e30457d74342c: Bug 1168607 - Add mode to MercurialFileFinder to support non-relative paths; r=glandium
Gregory Szorc <gps@mozilla.com> - Mon, 08 Jun 2015 09:33:46 -0700 - rev 247848
Push 28885 by cbook@mozilla.com at Wed, 10 Jun 2015 13:18:59 +0000
Bug 1168607 - Add mode to MercurialFileFinder to support non-relative paths; r=glandium The moz.build reader uses absolute paths when referencing moz.build files. *Finder classes expect paths to be relative to a base. When we switched the reader to use *Finder instances for I/O, we simply provided a default FileFinder based at the filesystem root. This was quick and easy. Things worked. Unfortunately, that solution isn't ideal because not all *Finder instances can accept absolute paths like that. The MercurialRevisionFinder is one of them. Changing the moz.build reader to talk in terms of relative paths is a lot of work. While this would be ideal, it is significantly easier to defer the problem until later and hack up MercurialRevisionFinder to accept absolute paths. This commit does exactly that. Bug 1171069 has been filed to track converting BuildReader to relative paths.
ab4010e0785fb1a6688f93626e1e30dbefe075db: Bug 1168607 - Implement a finder that reads from a Mercurial repo; r=glandium
Gregory Szorc <gps@mozilla.com> - Tue, 09 Jun 2015 13:39:01 -0700 - rev 247847
Push 28885 by cbook@mozilla.com at Wed, 10 Jun 2015 13:18:59 +0000
Bug 1168607 - Implement a finder that reads from a Mercurial repo; r=glandium Now that moz.build files use finders for I/O, we can start reading moz.build data from other sources. Version control is essentially a filesystem. We implement a finder that speaks to Mercurial to obtain file data. It is able to obtain file data from a specific revision in the repository. We use the hglib package (which uses the Mercurial command server) for speaking with Mercurial. This adds overhead compared to consuming the raw Mercurial APIs. However, it also avoids GPL side-effects of importing Mercurial's Python modules. Testing shows that performance is good but not great. A follow-up commit will introduce a GPL licensed Mercurial finder. For now, get the base functionality in place.
4001a09e72858ab2e70d9b9bbbdfe36d0b7c1fe2: Bug 1168607 - Use mozpack Finders for reading moz.build files; r=glandium
Gregory Szorc <gps@mozilla.com> - Tue, 09 Jun 2015 18:16:35 -0700 - rev 247846
Push 28885 by cbook@mozilla.com at Wed, 10 Jun 2015 13:18:59 +0000
Bug 1168607 - Use mozpack Finders for reading moz.build files; r=glandium Sometimes moz.build data may not come from the local filesystem. To support defining moz.build data in other backing stores, we switch moz.build reading to use mozpack's *Finder classes for I/O. The use of a FileFinder bound to / is sub-optimal. We should ideally be creating a finder bound to topsrcdir. However, doing this would require refactoring a lot of path handling in the reader, as that code makes many assumptions that paths are absolute. This would be excellent follow-up work. While I was here, I cleaned up some linter warnings for unused imports. On my machine, this commit results in a slight slowdown of moz.build reading. Before, `mach build-backend` was consistently reporting 1.99s for reading 2,572 moz.build files. After, it is consistently reporting 2.07s, an increase of 4%. This is likely due to a) function call overhead b) the cost of instantiating a few thousand File instances c) FileFinder performing an os.path.exists() before returning File instances. I believe the regression is tolerable.
1a470efc9fc2b3d76831f683dc2eae1c143628c1: Bug 1168607 - Add a read() method to File; r=glandium
Gregory Szorc <gps@mozilla.com> - Tue, 02 Jun 2015 09:37:45 -0700 - rev 247845
Push 28885 by cbook@mozilla.com at Wed, 10 Jun 2015 13:18:59 +0000
Bug 1168607 - Add a read() method to File; r=glandium Passing raw file handles around is a bit dangerous because it could lead to leaking file descriptors. Add a read() method that handles the simple case of obtaining the full contents of a File instance. This should ideally be a method on BaseFile. But this would require extra work and isn't needed. So we've deferred it until bug 1170329.
187dfb251703ddce7ffbb553850efcabf3bf8774: Bug 1168607 - Add get method to finders; r=glandium
Gregory Szorc <gps@mozilla.com> - Thu, 04 Jun 2015 11:24:03 -0700 - rev 247844
Push 28885 by cbook@mozilla.com at Wed, 10 Jun 2015 13:18:59 +0000
Bug 1168607 - Add get method to finders; r=glandium Today, the *Finder classes are optimized for doing matching and returning multiple results. However, sometimes only looking for a single file is wanted. This commit implements the "get" method on all the *Finder classes. It returns a BaseFile or None. FileFinder._find_file has been refactored into FileFinder.get to avoid code duplication.
553615c0705ea3aa76fea98e3b4b14dcbabcc760: Bug 1166960 - Remove redundant call to UnlockPointer and unnecessary check before calling that function. r=smaug
Xidorn Quan <quanxunzhen@gmail.com> - Wed, 10 Jun 2015 13:14:57 +1200 - rev 247843
Push 28885 by cbook@mozilla.com at Wed, 10 Jun 2015 13:18:59 +0000
Bug 1166960 - Remove redundant call to UnlockPointer and unnecessary check before calling that function. r=smaug
(0) -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip