Hi,
If you've read the "You want faster builds, don't you" thread, you may
know that some build improvements have recently landed.
I just landed the most important part of it all, and we should now be in
a much better place, but, as I'm very cautious, and as this is
incremental improvements to an
> I have a laundry list of stuff that I want a fly-on-the-wall perspective.
>
> First is the discussion of the standardization support macros (so we
> don't have to maintain crummy stuff like mfbt/Compiler.h), although that
> meeting may have already passed.
The latest proposal for these macros c
> what i've really been wondering about for a while is
> whether there are any considerations of static / compile-time introspection,
> and if not, why.
> It's nothing pressing, i'm just really curious and i haven't found anything
> on it (besides the rare musings of other C++ users on this).
>
>
> Fixing the "include hell" problem would be at the top of my list of
> wants as someone who cares about the performance of a large scale build
> system. I believe there was a C++ modules proposal on the standards
> track at one point. Not sure what it's status is beyond being an
> experimental fea
On Tue, Oct 01, 2013 at 01:13:37PM -0700, Botond Ballo wrote:
> > - final on data / non virtual member functions
> > - virtual constants (maybe ability to get at vtable pointer too?)
> > - ability to say classes should only be used on stack / heap or not used
> > in one of those
> >
> > It wou
> There is a Reflection Study Group (a sub-group of the Committee which
> focuses on a particular area) which is tasked with investigating
> language and library extensions for compile-time and runtime reflection.
By the way, the Reflection Study Group has just opened a public mailing
list [1].
B
> - final on data / non virtual member functions
> - virtual constants (maybe ability to get at vtable pointer too?)
> - ability to say classes should only be used on stack / heap or not used
> in one of those
>
> It would be nice to know if we can interest people in supporting any
> of thos
> OK, here is something that I would really like:
>
> http://llvm.org/devmtg/2012-11/Weber_TypeAwareMemoryProfiling.pdf
>
> Basically, this is a language extension that asks the compiler to store
> type information for each object in memory, so that one can query at
> runtime the type of what's s
> what i've really been wondering about for a while is
> whether there are any considerations of static / compile-time introspection,
> and if not, why.
> It's nothing pressing, i'm just really curious and i haven't found anything
> on it (besides the rare musings of other C++ users on this).
>
>
On 9/20/2013 9:06 AM, Benjamin Smedberg wrote:
So I would like to propose that we link the JS libraries statically
into libxul and stop exporting JSAPI symbols entirely. This will
effectively prevent extensions from using it.
This has been checked in for Firefox 27 in bug 920731, in the followin
On 10/1/13 10:43 AM, Gregory Szorc wrote:
On 10/1/13 10:26 AM, Karl Tomlinson wrote:
Gregory Szorc writes:
Just landed in inbound is a mass conversion of mochitests to use
manifests.
When adding a new test, the process used to be:
1. add new file path/to/test/directory/new-file
2. add "new-
Dear platformers,
As you may be aware, we have been busy for the past few months/years
adding platform APIs to simplify everybody's task of writing
asynchronous or, even better, off-main thread code [1].
Do you have wishes for Q4 or beyond? [De]compressing files on chrome
workers? Access
On 10/1/13 10:26 AM, Karl Tomlinson wrote:
Gregory Szorc writes:
Just landed in inbound is a mass conversion of mochitests to use manifests.
When adding a new test, the process used to be:
1. add new file path/to/test/directory/new-file
2. add "new-file" to MOCHITEST_FILES in path/to/test/di
Gregory Szorc writes:
> Just landed in inbound is a mass conversion of mochitests to use manifests.
When adding a new test, the process used to be:
1. add new file path/to/test/directory/new-file
2. add "new-file" to MOCHITEST_FILES in path/to/test/directory/Makefile.in
3. make -C obj/path/to/te
On 10/01/2013 12:25 AM, Karl Tomlinson wrote:
Bill McCloskey writes:
# Silence ++THIS and --THAT
export MOZ_QUIET=1
# Silence NS_WARNING
export MOZ_IGNORE_WARNINGS=1
then you won't get any more messages about DOM windows or
docshell creation/destruction or about NS_WARNINGs firing.
Thanks v
15 matches
Mail list logo
