I was just going to ask about this. I glanced through the mozconfigs in the
tree for at least Linux debug, but it looks like it only has --enable-debug,
not even -O1. Maybe it's buried somewhere in there, but I didn't find it with a
quick look.
I took a look at the build log for WinXP debug,
On Tue, Aug 19, 2014 at 11:26:42PM -0700, Jeff Gilbert wrote:
I was just going to ask about this. I glanced through the mozconfigs
in the tree for at least Linux debug, but it looks like it only has
--enable-debug, not even -O1. Maybe it's buried somewhere in there,
but I didn't find it with a
Gregory Szorc wrote:
Well, mach seems to be working for people doing m-c development.
[Still needs a working build environment, while python runtests.py just
used to need an objdir.]
--
Warning: May contain traces of nuts.
___
dev-platform
Neil wrote:
Gregory Szorc wrote:
Well, mach seems to be working for people doing m-c development.
[Still needs a working build environment, while python runtests.py
just used to need an objdir.]
In fact there was a time where I could cross-compile and copy the objdir
onto the target OS
Hi all,
As a part of the ongoing nested content process work[1][2], the
TabParent now could be created in a content process so please don't
assume it's in the chrome process. Passing PBrowser around in ipdl
protocol is not safe either, because the PBrowser may live in a
different protocol tree.
On 8/20/2014 4:16 AM, Neil wrote:
Neil wrote:
Gregory Szorc wrote:
Well, mach seems to be working for people doing m-c development.
[Still needs a working build environment, while python runtests.py
just used to need an objdir.]
In fact there was a time where I could cross-compile and
Ted Mielczarek wrote:
our supported use cases are run from mach and run from the test package.
How does a test package differ from an objdir? Do you still need an
entire build environment to run a test package?
--
Warning: May contain traces of nuts.
On 8/20/2014 3:07 AM, Mike Hommey wrote:
Optimized builds have been the default for a while, if not ever[1].
Bug 54828 made optimized builds the default in 2004 right before we
released Firefox 1.0. It only took four years to make that decision ;-)
--BDS
(Cross posting for visibility. Followups to dev-planning please.)
The next merge was scheduled for Mon, Sep 1, 2014, which is labour day in
Canada and the US. In order to accommodate holiday schedules, the merge will
instead occur on Tue, Sep 2, 2014. This change will have no impact on the
The Web APIs documentation meeting is Friday at 10 AM Pacific Time (see
http://bit.ly/APIDocsMeeting for your time zone). Everyone's welcome to
attend; if you're interested in ensuring that all Web APIs are properly
documented, we'd love your input.
We have an agenda, as well as details on
No success, I take it?
On 04/07/14 20:11, Ehsan Akhgari wrote:
I'm not aware of any such APIs, but CCing some other folks who know more
about Windows than I do.
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
TL;DR
I'm looking for:
1. an API to open a XUL window but keep it invisible;
2. an API to make an invisible XUL window visible, but behind the
currently active window;
3. an API to open a XUL window but keep it in the background.
Do we have such things? Otherwise, how hard would it be to add
Has anyone tried SetWindowPos? It has a mechanism for altering the
windows z-order, which determines the order in which windows are
enumerated. That should affect ordering in the taskbar.
A hide/show pair after that might also be sufficient, but I assume
something that simple was tried already.
I remember that the Composer in Mozilla Suite was doing something like
1. and 2. for new mail windows.
On 20/08/14 10:50, David Rajchenbach-Teller wrote:
TL;DR
I'm looking for:
1. an API to open a XUL window but keep it invisible;
2. an API to make an invisible XUL window visible, but behind
On 19/08/2014 21:55, Benoit Girard wrote:
I completely agree with Jeff Gilbert on this one.
I think we should try to coalesce -better-. I just checked the current
state of mozilla-inbound and it doesn't feel any of the current patch
really need their own set of tests because they're are not
Ted Mielczarek wrote:
it requires you to specify all of the relevant options.
And where are these options documented?
--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 2014-08-20, 10:50 AM, David Rajchenbach-Teller wrote:
TL;DR
I'm looking for:
1. an API to open a XUL window but keep it invisible;
You should be able to show/hide windows using nsIWidget::Show.
2. an API to make an invisible XUL window visible, but behind the
currently active window;
On 2014-08-20, 10:54 AM, Katelyn Gadd wrote:
Has anyone tried SetWindowPos? It has a mechanism for altering the
windows z-order, which determines the order in which windows are
enumerated. That should affect ordering in the taskbar.
Hmm, interesting. SetWindowPos is what nsWindow::PlaceBehind
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 from mochitest run inside mach, though
if there had been instructions on how to use
I have done this sort of thing a number of times too (sometimes
successfully, sometimes not), and it's been multiple hours each time. I
also recall hearing from several other people who have tried to do this
and ended up giving up. I love it when mach just works and runs exactly
what I want, but
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 from mochitest run inside mach, though
if
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 20/08/14 17:50, Ehsan Akhgari wrote:
A hide/show pair after that might also be sufficient, but I assume
something that simple was tried already.
This is also interesting. This maps to nsWindow::Show(false/true).
Yes, I believe that this would work, but I didn't try it in practice, as
I'm
On 18:25, Tue, 19 Aug, Ehsan Akhgari wrote:
On 2014-08-19, 5:49 PM, Jonathan Griffin wrote:
On 8/19/2014 2:41 PM, Ehsan Akhgari wrote:
On 2014-08-19, 3:57 PM, Jeff Gilbert wrote:
I would actually say that debug tests are more important for
continuous integration than opt tests. At least in
On 2014-08-20, 12:02 PM, Chris AtLee wrote:
On 18:25, Tue, 19 Aug, Ehsan Akhgari wrote:
On 2014-08-19, 5:49 PM, Jonathan Griffin wrote:
On 8/19/2014 2:41 PM, Ehsan Akhgari wrote:
On 2014-08-19, 3:57 PM, Jeff Gilbert wrote:
I would actually say that debug tests are more important for
On Wed, Aug 20, 2014 at 03:58:55PM +0100, Ed Morley wrote:
On 19/08/2014 21:55, Benoit Girard wrote:
I completely agree with Jeff Gilbert on this one.
I think we should try to coalesce -better-. I just checked the current
state of mozilla-inbound and it doesn't feel any of the current patch
Graphics in particular is plagued by non-cross-platform code. Debug coverage on
Linux gives us no practical coverage for our windows, mac, android, or b2g
code. Maybe this is better solved with reviving the Graphics branch, however.
-Jeff
- Original Message -
From: Chris AtLee
On 2014-08-20, 5:46 PM, Jeff Gilbert wrote:
Graphics in particular is plagued by non-cross-platform code. Debug coverage on
Linux gives us no practical coverage for our windows, mac, android, or b2g
code. Maybe this is better solved with reviving the Graphics branch, however.
Having more
If running debug tests on a single platform is generally sufficient for
non-graphics bugs, it might be useful to have the Graphics branch run debug
tests on all platforms, for use with graphics checkins. (while running a
decreased number of debug tests on the main branches) It's still possible
On 2014-08-20, 6:29 PM, Jeff Gilbert wrote:
If running debug tests on a single platform is generally sufficient for
non-graphics bugs,
It is not. That is the point I was trying to make. :-)
it might be useful to have the Graphics branch run debug tests on all
platforms, for use with
From: Gregory Szorc g...@mozilla.com
To: James Graham ja...@hoppipolla.co.uk, dev-platform@lists.mozilla.org
Sent: Wednesday, August 20, 2014 11:24:00 AM
Subject: Re: Running mochitests from a copy of the objdir?
It sounds like the copy build to remote machine so we can run tests
there is
From: Ehsan Akhgari ehsan.akhg...@gmail.com
To: Jeff Gilbert jgilb...@mozilla.com
Cc: Chris AtLee cat...@mozilla.com, Jonathan Griffin
jgrif...@mozilla.com, dev-platform@lists.mozilla.org
Sent: Wednesday, August 20, 2014 4:00:15 PM
Subject: Re: Experiment with running debug tests less often
On Wed, Aug 20, 2014 at 4:24 PM, Jeff Gilbert jgilb...@mozilla.com wrote:
I have been asked in the past if we really need to run WebGL tests on
Android, if they have coverage on Desktop platforms.
And then again later, why B2G if we have Android.
There seems to be enough belief in
33 matches
Mail list logo
