On Sat, Sep 21, 2013 at 12:16 PM, Gregory Szorc wrote:
> Anyway, I wanted to reiterate that from the perspective of the build
> system, our hands are mostly tied when it comes to making C++
> compilation faster. We can deliver precompiled headers and better
> support for using "unified" C++ sourc
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 stored at a giv
(2013/09/21 9:03), Gregory Szorc wrote:
The "mach" script in the root directory of mozilla-central is a generic
command dispatching tool. Have a piece of commonly used functionality
useful to many people? Create a mach command so others can use it easily!
While mach started with commands dealing
On 9/20/13 6:23 PM, Bobby Holley wrote:
It seems like we're going to need a story for this kind of stuff.
Sure. That story may not be WebIDL (e.g. there are proposals to not
have a Date type in IDL at all and just use raw numeric timestamps for
dates).
One major goal of the bindings is to
On Sat, Sep 21, 2013 at 10:16 AM, Gregory Szorc wrote:
> On 9/20/2013 4:47 PM, Nicholas Nethercote wrote:
>
> I'm also surprised your no-change rebuild was 29s before this patch. I'm
> still hovering around ~60s on my i7-2600K under Linux and on my 2011 MBP
> pre-patch. This patch descreased my no
On 9/20/2013 4:47 PM, Nicholas Nethercote wrote:
> On Fri, Sep 20, 2013 at 11:24 PM, Mike Hommey wrote:
>>
>> Try an incremental build, too :)
>
> Some fresh results, with a |--enable-test --enable-debug
> --enable-optimize='-O0'| build. (And I forgot to mention that I'm
> using clang).
>
> - C
The "mach" script in the root directory of mozilla-central is a generic
command dispatching tool. Have a piece of commonly used functionality
useful to many people? Create a mach command so others can use it easily!
While mach started with commands dealing with build system interaction
and running
On Fri, Sep 20, 2013 at 11:24 PM, Mike Hommey wrote:
>
> Try an incremental build, too :)
Some fresh results, with a |--enable-test --enable-debug
--enable-optimize='-O0'| build. (And I forgot to mention that I'm
using clang).
- Clobber build: 12m54s --> 11m16s (1.14x faster)
- Touch-jsapi.h-a
In bug 917988, we just landed support for using Sphinx [1] to manage the
build system documentation. You can generate the documentation by running:
$ mach build-docs
By default it will generate HTML documentation using the Sphinx MDN
theme, so it's Mozilla branded and it is lovely. Sphinx is a
On 9/20/13 10:02 AM, Benjamin Smedberg wrote:
Hrm. Can profilers (Instruments in particular) profile by C++
namespace?
I don't see a way to do it (keep in mind that it's probably primarily
targeting ObjC, not C++).
It can do things per-symbol and per-library, but those are theoptions.
Bor
It seems like we're going to need a story for this kind of stuff. One major
goal of the bindings is to remove the need for C++ consumers to manually
muck with JSAPI. And as more web objects (TypedArrays, Promises, etc) move
into the JS engine, we're going to want a sane mechanism for manipulating
t
On 9/20/13 3:21 PM, Bobby Holley wrote:
Can you manipulate Dates using the WebIDL bindings instead?
From C++? No.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Hi everyone,
The C++ Standards Committee is meeting in Chicago next week. Their focus will
be on C++14, the upcoming version of the C++ standard, as well as some
Technical Specifications (specifications for features intended to be
standardized but not fully-baked enough to be standardized now)
I've never used webidl bindings before. Sounds to me that I can somehow
use mozilla::dom::Date in a way that it is part of the xpcom object?
If there is a way to achieve this without jsapi, then I'm fine with it.
Implementing it just shouldn't become overly complicated.
Philipp
On 9/20/13
On 9/20/13 6:24 PM, Paul Rouget wrote:
Patrick, do you think you could reduce this jsbin problem to a smaller test
case?
Brian Grinstead and I have been trying for the last days with no luck so far
Does docShell.getSameTypeParentIgnoreBrowserAndAppBoundaries() return null?
Or is it querySelect
On 9/20/13 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.
To answer questions I received privately about the impact of addon
comp
On 9/20/13 8:22 PM, Benjamin Smedberg wrote:
On 9/20/13 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.
To answer questions I rece
On Fri, Sep 20, 2013 at 3:07 PM, Patrick Brosset wrote:
> docShell.getSameTypeParentIgnoreBrowserAndAppBoundaries() doesn't return
> null, it returns a docShell, but the subsequent querySelectorAll("iframe")
> call returns an empty array.
You can have a child docshell in a container other than "i
Boris Zbarsky wrote:
> On 9/20/13 11:14 AM, Patrick Brosset wrote:
> >The helper is here:
> >http://mxr.mozilla.org/mozilla-aurora/source/toolkit/devtools/LayoutHelpers.jsm#370
>
> 379 if (docShell.isBrowserOrApp) {
> ...
> 389 } else {
> 390 return win.frameElement;
> 391 }
>
>
On Fri, Sep 20, 2013 at 11:14 AM, Patrick Brosset wrote:
> When the site loads, we listen to (using nsIWebProgressListener) state
> changes and for each window that completes loading, we call a helper
> function that'll tell us if that window is the website's top one or not.
Can't you use aWebPro
Can you manipulate Dates using the WebIDL bindings instead?
On Fri, Sep 20, 2013 at 12:12 PM, Philipp Kewisch wrote:
> On 9/20/13 8:22 PM, Benjamin Smedberg wrote:
>
>> On 9/20/13 9:06 AM, Benjamin Smedberg wrote:
>>
>>> So I would like to propose that we link the JS libraries statically
>>> in
On Fri, Sep 20, 2013 at 6:06 AM, Benjamin Smedberg
wrote:
> Currently, extensions are able to use the JSAPI via its exported symbols.
> This pretty much invariably leads to stability or security issues with
> extensions that actually do this:
>
> * the JSAPI is complicated, and even within Mozilla
On 9/20/13 2:12 AM, Nicolas B. Pierron wrote:
On 09/19/2013 10:02 PM, Dave Townsend wrote:
I would expect that the total server load on hg.mozilla.org is high
enough
that whatever you do as a single person isn't going to be even a blip on
the radar so I'd expect just a "hg pull" with a reasonabl
On Fri, Sep 20, 2013 at 12:24 PM, Paul Rouget wrote:
> @all: Is there a way to know which DOM element holds a docShell? Basically,
> which
> owns the docshell?
Sounds like you want a scriptable (privileged-only) version of
nsIDOMWindow realFrameElement
Gavin
__
I use http://whereswalden.com/2011/11/03/how-i-organize-my-mozilla-trees/ to
organize all my trees on the one machine I use (a laptop). That's one machine,
so a bit easier to deal with than your "spread around" setup. I develop on
Windows on occasion, but I don't do it often enough for anythin
On 9/20/13 12:24 PM, Paul Rouget wrote:
@all: Is there a way to know which DOM element holds a docShell? Basically,
which
owns the docshell?
We should add one as needed.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://l
Patrick, do you think you could reduce this jsbin problem to a smaller test
case?
Does docShell.getSameTypeParentIgnoreBrowserAndAppBoundaries() return null?
Or is it querySelectorAll() that returns an array without the iframe we're
looking for?
Does isTopLevelWindow() returns true? If so, it's
On 9/20/13 11:14 AM, Patrick Brosset wrote:
The helper is here:
http://mxr.mozilla.org/mozilla-aurora/source/toolkit/devtools/LayoutHelpers.jsm#370
379 if (docShell.isBrowserOrApp) {
...
389 } else {
390 return win.frameElement;
391 }
So for anything on desktop it is in fact
Hello,
I'm currently investigating a bug we're having in the DevTools inspector
(https://bugzilla.mozilla.org/show_bug.cgi?id=917448) whereby the
inspector won't load for some websites.
One such website is http://jsbin.com/, and we've narrowed it down to a
problem we're having with inner ifr
The Rendering meeting is about all things Gfx, Image, Layout, and Media.
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm
PDT.
The next meeting will take place this coming Monday, September 23 at 2:30 PM
US/Pacific
Please add to the agenda:
https://wiki.mozilla.org/
On 9/20/2013 9:23 AM, Mike Hommey wrote:
We're already statically linking js libraries info libxul. Except on
windows, but that's work in progress in bug 915735
I am primarily worried about doing this on Windows.
, although we don't
know yet if it's going to work at all: after dealing with the
On 09/20/13 12:31 AM, Blair McBride wrote:
> Ohai!
>
> I have numerous copies of mozilla-central (and other repos) for various
> purposes - spread around physical boxes and VMs. Some of them I use
> regularly and update regularly, others not-regularly. I've been thinking
> about the amount of time
On Fri, Sep 20, 2013 at 06:58:20PM +1000, Nicholas Nethercote wrote:
> On Fri, Sep 20, 2013 at 3:58 PM, Mike Hommey wrote:
> >
> > Add the following to your .mozconfig:
> >
> > export MOZ_PSEUDO_DERECURSE=1
> >
> > That's it.
>
> I just tried this on my fast new Linux machine.
>
> - A |--ena
On Fri, Sep 20, 2013 at 09:06:41AM -0400, Benjamin Smedberg wrote:
> Currently, extensions are able to use the JSAPI via its exported
> symbols. This pretty much invariably leads to stability or security
> issues with extensions that actually do this:
>
> * the JSAPI is complicated, and even withi
Currently, extensions are able to use the JSAPI via its exported
symbols. This pretty much invariably leads to stability or security
issues with extensions that actually do this:
* the JSAPI is complicated, and even within Mozilla we get reviews from
a select set of people on JSAPI code
* the
On 20/09/13 13:29 , Henri Sivonen wrote:
I don't happen to have multi-locale Android or B2G builds set up, but
I need to know how they behave to avoid breaking them. Does anyone
happen to know if the following code would end up printing the locale
code for the active browser UI localization on An
I don't happen to have multi-locale Android or B2G builds set up, but
I need to know how they behave to avoid breaking them. Does anyone
happen to know if the following code would end up printing the locale
code for the active browser UI localization on Android and B2G despite
them not being XUL pl
On 09/19/2013 10:02 PM, Dave Townsend wrote:
I would expect that the total server load on hg.mozilla.org is high enough
that whatever you do as a single person isn't going to be even a blip on
the radar so I'd expect just a "hg pull" with a reasonable frequency would
be just fine. If you want to
On Fri, Sep 20, 2013 at 3:58 PM, Mike Hommey wrote:
>
> Add the following to your .mozconfig:
>
> export MOZ_PSEUDO_DERECURSE=1
>
> That's it.
I just tried this on my fast new Linux machine.
- A |--enable-tests --enable-debug build| with -j8 improved from
15m48s to 13m30s, a 1.17x improvemen
Steve Fink wrote:
function pullup () {
( cd $(hg path default) && hg pull )
}
I use hg pull -R $(hg path default)
--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listi
Dave Townsend wrote:
Downside? I've had a cronjob doing this frequently for a while and the local
repo gets corrupt data in it about every other week and I have to go manually
strip the offending changesets and repull. No idea why.
I've had a cronjob doing this for 5 years (so it's still runn
41 matches
Mail list logo
