Currently nsAtom::mString points to the interior of an nsStringBuffer. For
static atoms this requires the use of nsFakeStringBuffer, which is pretty
gross.
This patch changes things so that nsAtom::mString points to a static char
buffer for static atoms. This simplifies a number of things:
- nsFakeStringBuffer and CheckStaticAtomSizes are no longer needed.
- FakeBufferRefCountHelper is no longer needed.
- nsAtom's constructor for static atoms is simpler.
- RegisterStaticAtoms() is simpler.
On the flip-side, a couple of things get more complicated.
- nsAtom::ToString() treats static and dynamic atoms differently.
- nsAtom::GetStringBuffer() is now only valid for dynamic atoms. This
function is only used in two places, both involving DOMString, so those
locations are updated appropriately. This also requires updating some other
code assigning nsStrings to DOMStrings, because we can't assume that
nsStrings are shared.
On Linux64 this change reduces the size of the binary by 8752 B, and moves
81968 B from the .data to the .rodata section, where it can be shared between
processes.
--HG--
extra : rebase_source : 0f6fcdec1c525aa66222e208b66a9f9026f69bcb
This also fixes the Unix part of bug 678369, and fixes bug 147659 as a
convenient side-effect of using LaunchApp (which has the desired
fd-closing behavior already) rather than directly using fork/exec.
The main goal is to work around bug 227246, where PR_CreateProcess on
Unix interferes with anything else that tries to use child processes.
This does not fix that bug -- NSPR will still cause problems if used in
that way -- but it's an adequate workaround for that bug in Gecko in
almost all cases (the one known exception is nsAuthSambaNTLM, which uses
NSPR directly and needs to be fixed separately).
Waiting for the child process uses waitpid() directly, sharing the
existing code used for OS X.
MozReview-Commit-ID: 6zfZ1Zgk2i9
--HG--
extra : rebase_source : e8230503d82943af4563d8d63baa029d8a698683
Bug 1134923 removed the use of those functions in gecko, and left some
for the XPCOM standalone glue. The XPCOM standalone glue was severely
stripped down in bug 1306327, with the effect of removing the
implementation for those functions.
The remains in nsXPCOM.h are:
XPCOM_API(void*) NS_Alloc(size_t aSize);
XPCOM_API(void*) NS_Realloc(void* aPtr, size_t aSize);
XPCOM_API(void) NS_Free(void* aPtr);
With no implementation left, the first arm is never actually used, and
the second arm means every remaining use of those functions in the tree
is a macro expansion to one of moz_xmalloc, moz_xrealloc or free.
--HG--
extra : rebase_source : fd1669abc5a25d8edbd5c3a8522e22a5c3f558e2
nsEscape.cpp doesn't build in non-unified mode, as it uses mozilla::fallible,
mozilla::CheckedInt and mozilla::ASCIIMask::IsMasked without prefixing them
with the mozilla namespace. I suspect this file is usually included in
unified_cpp file which includes a "using namespace mozilla" directive.
MozReview-Commit-ID: GwlsK8kytLj
--HG--
extra : rebase_source : c3063aff7cdf10c416b8ee782c9bee745e643842
We were using a StaticRefPtr without it being fully defined for
SystemGroupImpl::sSingleton, resulting in a non-unified build failure.
MozReview-Commit-ID: AgSuVvGTri7
--HG--
extra : rebase_source : 906e30e8c2c21e13a045a941e9d92e1d2d2af079
This Makefile.in contains a bunch of cruft for Tier-3 platforms. If
someone is still supporting any of them they can make the necessary
fixes to moz.build files themselves.
MozReview-Commit-ID: HxbbCv395Y5
--HG--
extra : rebase_source : 94f04128d2b3dd1285dfeafbfeb320b2f0d0bb19
extra : histedit_source : 2353127161ae58e54b6296e98b6b4b972ae439fe
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive.
This patch splits that macro into three new ones that are harder to mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 53c8b43b6a1be06d00618a133e28bf95c46a3ba3
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive.
This patch splits that macro into three new ones that are harder to mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 59f77df0124249bfd11fee3585420a17b4201d37
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
Adds a new directory provider key "XRESysExtDev" to be used by system extension
developers needing to load system extensions from a directory readable by
sandboxed content processes.
MozReview-Commit-ID: 4BKOZoPzCC3
--HG--
extra : rebase_source : 452db8d53a1f0248a080f858c48492978b5db808
Removes the XPCOM interface for nsIDOMHTMLCanvasElement, replacing it
with binding class usage.
MozReview-Commit-ID: DQJhqGlY8U6
--HG--
extra : rebase_source : a33146a22ee356a0840bb9fef82d51b2b315f6d7
The Windows and OSX code paths were essentially doing the same thing,
and the Unix fallback was using an old convention that is pretty much
outdated.
Under normal conditions (XPCOM initialized by Firefox),
NS_XPCOM_INIT_CURRENT_PROCESS_DIR is set from BinaryPath anyways, so
this only really affects adhoc XPCOM initialization from e.g. C++ unit
tests.
--HG--
extra : rebase_source : b3151fffd4c82159b633a48dead86f2c3b0a03d6
Back in the day, there was no global with an already initialized
DirectoryService. But now there is, and, in fact,
GetCurrentProcessDirectory already errors out if that global is not set
by the time it's called. All calling nsDirectoryService::Create achieves
is doing the check again and calling QueryInterface, which we don't need
to do anyways.
--HG--
extra : rebase_source : 32f5080ecb8165cffd601799e72d278b482b0871
It seemingly hasn't been needed since Mac OS 10.7. A diagnostic assertion that
has been in place for a while hasn't caught any uses of it.
--HG--
extra : rebase_source : 9834849eec9174267c7df8de7fd22840ffa36d8f
This adds an attribute 'noShell' to nsIProcess that is used to launch a process
using CreateProcess() if we are sure we are launching an executable and don't
require the extra work of the Windows shell service.
MozReview-Commit-ID: 7p0iHCZK1uX
Add macro for nsISupports inheriting classes that need cycle
collection and only inherit from one parent, with no interface table
needed. Takes care of map and addref/release calls.
MozReview-Commit-ID: LtTwYH0DeEz
--HG--
extra : rebase_source : d3650209ddd7e28cbf205ac84f152b9763c26bde
This fixes the build in non-unified mode, as nsCOMArray::Sort() method uses
NS_QuickSort().
MozReview-Commit-ID: CDBLIX8D3mL
--HG--
extra : rebase_source : 67902cf10b9311adbd97fecf7906762bb86c52e4
The Windows and OSX code paths were essentially doing the same thing,
and the Unix fallback was using an old convention that is pretty much
outdated.
Under normal conditions (XPCOM initialized by Firefox),
NS_XPCOM_INIT_CURRENT_PROCESS_DIR is set from BinaryPath anyways, so
this only really affects adhoc XPCOM initialization from e.g. C++ unit
tests.
--HG--
extra : rebase_source : f7faa6f22ffc56fb4da7ae96eb571a35fa6f615d
Back in the day, there was no global with an already initialized
DirectoryService. But now there is, and, in fact,
GetCurrentProcessDirectory already errors out if that global is not set
by the time it's called. All calling nsDirectoryService::Create achieves
is doing the check again and calling QueryInterface, which we don't need
to do anyways.
--HG--
extra : rebase_source : 519980829be4ff4a0941c0e8d18be5761ece6552
(patch is actually r=erahm,mystor)
nsTFixedString<T> is only used as a base class for nsTAutoStringN<T, N>, so
this patch merges the former into the latter, cutting some code and simplifying
the string class hierarchy.
Because the "Fixed" name is now gone, the patch also renames
StringDataFlags::FIXED as INLINE and ClassDataFlags::FIXED as INLINE.
The patch also removes nsFixed[C]String and ns_auto_[c]string! from Rust code
because nsAutoString can't be implemented directly in Rust due to its move
semantics. There were only two uses of ns_auto_string! outside of tests so this
seems like a minor loss.
MozReview-Commit-ID: 8ntximghiut
--HG--
extra : rebase_source : f36edbae0553adcfee356fb8b311097ff7424786
The Windows and OSX code paths were essentially doing the same thing,
and the Unix fallback was using an old convention that is pretty much
outdated.
Under normal conditions (XPCOM initialized by Firefox),
NS_XPCOM_INIT_CURRENT_PROCESS_DIR is set from BinaryPath anyways, so
this only really affects adhoc XPCOM initialization from e.g. C++ unit
tests.
--HG--
extra : rebase_source : b3151fffd4c82159b633a48dead86f2c3b0a03d6
Back in the day, there was no global with an already initialized
DirectoryService. But now there is, and, in fact,
GetCurrentProcessDirectory already errors out if that global is not set
by the time it's called. All calling nsDirectoryService::Create achieves
is doing the check again and calling QueryInterface, which we don't need
to do anyways.
--HG--
extra : rebase_source : 32f5080ecb8165cffd601799e72d278b482b0871
Removes the XPCOM interface for nsIDOMHTMLAreaElement, replacing it
with binding class usage.
MozReview-Commit-ID: IaX4JFTPZn6
--HG--
extra : rebase_source : 79f9200c6ff9e081a5d9bc21eaa605f88caa99e9
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
nsHtml5Atoms are very similar to dynamic nsAtoms. This patch removes the former
in favour of the latter, which leaves nsAtom as the only subclass of nsIAtom.
nsAtom::mKind is still used to distinguish dynamic atoms from HTML5 atoms, and
the HTML5 parser still uses manual memory management to handle its HTML5 atoms.
nsHtml5AtomEntry::mAtom had to be changed from an nsAutoPtr to a raw pointer
because nsAtom's destructor is private.
MozReview-Commit-ID: 1pBzwkog3ut
--HG--
extra : rebase_source : fbb819e527cb30606348da9ce3eede62e00fb936
This patch moves nsAtom's declaration to nsIAtom.h. In order to keep most of
nsAtom's members private the patch also does the following.
- It introduces a new class, nsAtomFriend, which encapsulates the functions
that will need access to nsAtom's private members.
- It moves GCKind, GCAtomTable(), and GCAtomTableLocked() out of nsAtom.
- It removes the factory methods, and replaces their uses with direct
constructor calls.
MozReview-Commit-ID: L8vfrHsR2cS
--HG--
extra : rebase_source : d38a65515ae82c355966ca80ab235bea11b638af
Because it's going to be exposed via nsIAtom.h in the next few patches.
MozReview-Commit-ID: A81s1nWrvmB
--HG--
extra : rebase_source : 43990feb460fc7343c994f72fb6c6679a3aeb1cc
Full specialization is allowed in MSVC, but not in gcc.
MozReview-Commit-ID: 9QI6YWc5Rvr
--HG--
extra : rebase_source : 7387899a6d76832afbe15e088b80a82adee59ca3
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: B5Y8KyExPQ8
--HG--
extra : rebase_source : e27b266c145daa5acd887e998c6d5b408101e1db
extra : source : 33f49977a33cbdb1c7127871b940eefccc018f65
Removes the nsIDOMHTMLObjectElement XPCOM interface, replacing it with
HTMLObjectElement and FromContent conversion usage.
MozReview-Commit-ID: dmsjSO97uh
--HG--
extra : rebase_source : 9b2c25b8681f754bc34233afccdb6fc5d38f0804
XPCOM's string API doesn't have the notion of a "null string". But it does have
the notion of a "void string" (or "voided string"), and that's what these
functions are returning. So the names should reflect that.
--HG--
extra : rebase_source : 4e3f982e0873877174a08a25413595ff66f7d20e
This patch reduces sizeof(PLDHashTable) as follows.
- 64-bit: from 40 bytes to 32
- 32-bit: from 28 bytes to 20
It does this by doing the following.
- It moves mGeneration from EntryStore to PLDHashTable, to avoid unnecessary
padding on 64-bit. This requires tweaking EntryStore::Set() as explained in a
comment.
- It also shrinks mGeneration from uint32_t to uint16_t, saving 2 bytes of
data.
- It shrinks mEntrySize from uint32_t to uint8_t, to cut 3 bytes of data.
- It shrinks mHashShift from int16_t to uint8_t, trimming another byte of data,
and moves it, saving another 2 bytes of padding.
And it reorders the fields so the word-sized ones are at the start, which makes
it easier to imagine the memory layout.
The patch also adds a test, and fixes some misordered function arguments in
existing tests.
--HG--
extra : rebase_source : 6ed6f7be68477fd4a82f07dd2f51c1f1d9b92dcc
The current code replaces one PLDHashTable's mGeneration with another. If the
two generation values happen to be equal, it will look as though the storage
hasn't changed when really it has.
The fix is to use EntryStore::Set() to update mEntryStore, which increments
mGeneration appropriately.
--HG--
extra : rebase_source : d1779a143746c8d1a3e67bc3685e703496206b0f
nsIHandleReportCallback, typedef of nsIMemoryReporterCallback, has been the
preferred name for a long time and is used in most places. This patch removes
nsIMemoryReporterCallback.
--HG--
extra : rebase_source : c675076b4f98d93d96235dad890e31e0b0e6c277
Bug 1388789 introduced a bug breaking formats like "%*.f". The problem
was that the next "natural" argument was taken before the "*" width
argument.
MozReview-Commit-ID: BZack9faY7a
--HG--
extra : rebase_source : a14485914ef9e29e38f29be6c1df1372ce5e722f
Defining get() in the declaration of nsThreadManager implicitly sticks
an "inline" on the function, which is not what we want: inlining it
spreads around a lot of static initialization code. Providing an
out-of-line definition is much better in terms of code size.
nsTextFormatter unconditionally emitted a trailing \0, leading some code
elsewhere to have to work around this. This changes the code to only
emit it in snprintf.
MozReview-Commit-ID: G3CBpAPp9Tn
--HG--
extra : rebase_source : 36666476a4f796e2553c9fa31daa54d245ae3b5f
The char* and char16_t* cases handled null strings differently;
normalize them to both emit "(null)".
MozReview-Commit-ID: IzRkc3pSSjl
--HG--
extra : rebase_source : f43a1a852a2c8aa3d6607c7202f7cd42fdd5740a
Change nsTextFormatter functions to template functions, box their
arguments, and then make the formatter mostly impervious to type
mismatches. Most formatting is done according to the type of the actual
argument.
MozReview-Commit-ID: H8WmyxFCb7s
--HG--
extra : rebase_source : ad98ad6243825f1a892fc6a641d155e239b12a6b
nsTextFormatter::vsnprintf is defined to return uint32_t(-1) on error.
However, it was not doing this.
nsTextFormatter::vssprintf is defined as infallible; enforce this by
having it return void.
MozReview-Commit-ID: LdOhIHzRvAT
--HG--
extra : rebase_source : 7164eb47a89ecebfa50d40684eea1325de0172ba
nsTextFormatter tried to pass unrecognized escapes in the format string
through to the output. However, if the format held a width or
precision, that text was not output. It seems better to me to try to
preserve the format text as-is.
MozReview-Commit-ID: HoBykpfzK7C
--HG--
extra : rebase_source : 9b071db3800e3e75cabb4995a920818dfb35b03d
nsTextFormatter used nsAutoString for arrays of hex digits; but this
didn't seem to provide any benefit.
MozReview-Commit-ID: EYHtnAzJL8h
--HG--
extra : rebase_source : 6906075f06478b7c10229201de46e36d08d1f7f8
The runtime type-checking rewrite of nsTextFormatter will not support
va_list uses. So, make these functions private and fix the sole user.
MozReview-Commit-ID: IBWALVzIcHC
--HG--
extra : rebase_source : a822697c81c1a054359fc2ecd894d51f95686548
This is a preexisting issue that makes nsMultiplexInputStream multiple-inherit
from nsIInputStream: once via nsIMultipartInputStream and once via
nsIAsyncInputStream. This causes problems once we end up with more multiplex
streams that are async streams, because then some assingments to
nsCOMPtr<nsIInputStream> start asserting. This patch just removes the footgun
by getting rid of the multiple inheritance.
This is a preexisting issue that makes nsMultiplexInputStream multiple-inherit
from nsIInputStream: once via nsIMultipartInputStream and once via
nsIAsyncInputStream. This causes problems once we end up with more multiplex
streams that are async streams, because then some assingments to
nsCOMPtr<nsIInputStream> start asserting. This patch just removes the footgun
by getting rid of the multiple inheritance.
The compiler complains because a postfix increment is done inside of an assert.
MozReview-Commit-ID: LSRsWMn9Tlj
--HG--
extra : rebase_source : 18539a430c3d84675c602699be9a5a62dd477fec
There is no use mozilla namespace statement in this compilation unit, so the
call to GetErrorName() has to be prefixed with the mozilla namespace.
MozReview-Commit-ID: G3caP2v9PFF
--HG--
extra : rebase_source : 9aebe0711cf8ad81dc47592521a4f29b4f75caab
By doing this we avoid triggering assertions in the Servo code that ensure
we have registered the thread with Servo and set the proper state on it.
MozReview-Commit-ID: K6qHrYoQDLm
--HG--
extra : rebase_source : d01b0aad42273f6b92b7cfd5f5fe17ffe7b4cda0
Unfortunately, this needed some additional trickery in order to keep its
constructor "private". I stole this trick from [1]. With this patch, we tear
down the statistics object during XPCOM shutdown intead of after it. I don't
believe that we need the object to live past the ClearOnShutdown destructors.
[1] http://rienajouter.blogspot.com/2014/10/makeshared-and-makeunique-for-classes.html
MozReview-Commit-ID: JsiN6Bq9Yp4
--HG--
extra : rebase_source : dd26c8e6906a6c9fd500c28379f8c63fd7c3ad6a
do_CreateInstance was used without prior declaration.
MozReview-Commit-ID: 4LkXAcZytM7
--HG--
extra : rebase_source : a983330be02ed058a109ba3bbfd6ecdd3f2ddf56
LabeledEventQueue was used without prior declaration.
MozReview-Commit-ID: 3aqGDb0cZFY
--HG--
extra : rebase_source : 08e207b2024e5ba1be1eb0c55ddbe7b0fc405637
AbstractThread was used without prior declaration.
MozReview-Commit-ID: BmP83mmjX3b
--HG--
extra : rebase_source : 4f079246b7dd6c378eba97897f74a3c9623540df
nsIThreadObserver (defined in nsIThreadInternal.h) was used without prior
declaration.
MozReview-Commit-ID: 9cSuERgUPtl
--HG--
extra : rebase_source : 15219cba6f5a41c42aa1103d8c958a55ac3b9af0
nsTArray and EventLoopActivation were used without prior declaration.
MozReview-Commit-ID: C05YG6Nzh52
--HG--
extra : rebase_source : 3f78b6a1d73f4d59d3aac4b2da79c27cae404897
The LinkedList.h header is requires for the sSchedulerGroups variable
declaration.
MozReview-Commit-ID: 6T0WPKQER9S
--HG--
extra : rebase_source : 545e60bdec4e186a03cb20e342e561e104abcd98
InputEventStatistics::Get() requires the InputEventStatistics.h #include.
MakeScopeExit() requires the ScopeExit.h #include.
LabeledEventQueue.h is required for the PrioritizedEventQueue class.
MozReview-Commit-ID: 7gRwhV3YQXw
--HG--
extra : rebase_source : 54b56317b2876db2ed679e9f47ffb87fdf83cdd2
The nsTArray type was used without prior declaration.
MozReview-Commit-ID: KMUgXO2kBIY
--HG--
extra : rebase_source : 671ffe885ae7220bff746d433f55196519d05b8c
nsIRunnable was used without prior declaration.
MozReview-Commit-ID: CVEkaw6xBsC
--HG--
extra : rebase_source : 06c71dfada5e26725d7771284a9f400bf7b5fdd8
nsCOMPtr and nsThreadPoolNaming types were used without prior
declaration.
MozReview-Commit-ID: Gt7gksujs13
--HG--
extra : rebase_source : 57bbdb4f0d7ae0789dfc095fd4b6c99ad780f1ad
The template declaration and definition of Compare use NS_FASTCALL,
while the explicit instantiation of Compare does not, which produces
complaints from newer compilers. Add NS_FASTCALL to the explicit
instantiation so that things match up.
We're calling GetCurrentVirtualThread() which is defined in nsThreadUtils.h, so
without including nsThreadUtils.h we'll get a compile error if unified builds
are disabled.
MozReview-Commit-ID: JWCigMqNJDi
--HG--
extra : rebase_source : bac48b8f91e6561dfb7afe2828c3652431347c40
nsTSubstring.cpp is calling RoundUpPow2 which is defined in MathAlgorithms.h.
Without this, we get a build failure in non-unified builds.
MozReview-Commit-ID: Dz7VIZk4dLw
--HG--
extra : rebase_source : 7795784894bfca6e921d38cedaa4f543317c2165
Kris Maglione
Daosheng Mu
Nicholas Nethercote
Kyle Machulis
Xidorn Quan
Sebastian Hengst
Andrew McCreight
Phil Ringnalda
Jed Davis
Blake Kaplan
Mike Hommey
Ryan VanderMeulen
Tom Ritter
Chris Pearce
Ted Mielczarek
Olli Pettay
Eric Rahm
James Cheng
David Keeler
Jon Coppeard
Luke Wagner
Haik Aftandilian
Wes Kocher
Andrea Marchesini
Cervantes Yu
Cosm
David Major
Philippe Normand
Emilio Cobos Álvarez
Michael Layzell
Jean-Yves Avenard
Bevis Tseng
Chris Peterson
Tom Tromey
ffxbld
Nathan Froyd
Byron Campen [:bwc]
Jan Varga
Boris Zbarsky
Tomislav Jovanovic
Bill McCloskey
Ben Kelly