On Thu, May 16, 2013 at 10:50:18AM +0200, Mike Hommey wrote:
> > Following this, we're going to switch all Linux builds to gcc 4.7, later
> > this week.
>
> Chances are this is not going to happen this week. Something in the last
> 569 changesets before 15ba59a74221 broke some webgl mochitest when
On 4/16/13 10:15 PM, Robert O'Callahan wrote:
I have a request ... can we require lists in moz.build files to be in
alphabetical order, and actually enforce with some build-system check? I'm
always annoyed by Makefiles where lists are sometimes unordered and it's
hard to find items and know where
Matthew Gertner wrote:
It seems like the panel is automatically being closed when its hidden property
is set to true.
display: none; destroys the nsIFrame object (in this case an
nsMenuPopupFrame), thus closing the panel.
--
Warning: May contain traces of nuts.
_
Ehsan Akhgari wrote:
> On 2013-05-15 5:18 PM, Vladan Djeric wrote:
> > I'd like to know if these use-cases are sufficiently rare that we
> > should just add new shutdown events when needed (e.g. we added
> > "profile-before-change2" for Telemetry in bug 844331), or if we
> > should come up with a g
On 13-05-16 12:53 PM, Gregory Szorc wrote:
As I wrote at [1] there are some scenarios where the build system and
related tools would like to store persistent state. Some uses for this
include:
* Automatically recording previous build logs, compiler warnings, and
test results.
* Holding build env
On 5/16/13 3:15 PM, Ted Mielczarek wrote:
TL;DR: PGO on MSVC is now opt-in per-source-directory.
This is awesome. Thank you, Ehsan and Ted, for getting this sorted out!
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://list
On 13-05-16 12:53 PM, Gregory Szorc wrote:
As I wrote at [1] there are some scenarios where the build system and
related tools would like to store persistent state. Some uses for this
include:
* Automatically recording previous build logs, compiler warnings, and
test results.
* Holding build env
On Thu, May 16, 2013 at 03:15:48PM -0400, Ted Mielczarek wrote:
> Longer-term this should buy us more time for a real solution, as new
> directories won't automatically contribute to the problem. We heard from
> Microsoft that they are working on a 64-to-32-bit cross-toolchain, which
> is the only
On Thursday, May 16, 2013 7:20:33 PM UTC+2, Gavin Sharp wrote:
> Can't you just avoid calling openPopup until the page is loaded, and
> avoid messing with the panel's "hidden" state completely?
I tried that but it seemed like the iframe didn't have a docShell until after
the popup is shown so I c
As I wrote at [1] there are some scenarios where the build system and
related tools would like to store persistent state. Some uses for this
include:
* Automatically recording previous build logs, compiler warnings, and
test results.
* Holding build environments (downloaded Mercurial extension
Hello friends,
TL;DR: PGO on MSVC is now opt-in per-source-directory.
Today I landed a patch[1] that significantly lowered the memory usage of
the Visual C++ linker during PGO builds, which has been a consistent
pain point for us. The ever-wonderful Ehsan got in touch with a VC++
program manager
On 16/05/2013 20:12, Ehsan Akhgari wrote:
If OS.File can detect shutdown at the correct time, then it seems like
all of the above issues are going to be easy to fix. Which makes me
think of all of these as one use case (please correct me if I'm wrong.)
David prepared a patch for bug 845190 whi
On 5/16/2013 8:12 PM, Ehsan Akhgari wrote:
A dependency system for startup/shutdown isn't free. It's going to
have runtime cost, and it's going to make the code more complicated.
Given the fact that we've managed to get by just fine without one for
years, I think we should continue to do that
On 2013-05-16 10:23 AM, David Rajchenbach-Teller wrote:
On 5/16/13 3:03 PM, Ehsan Akhgari wrote:
Is this not the OS.File issue that Vladan mentioned?
My point is that there doesn't seem to be enough use cases to warrant a
new infrastructure to handle shutdown dependencies.
Well, as we expand
On Thu, May 16, 2013 at 01:30:14PM -0400, Subrata Mazumdar wrote:
>
> I have now tested with with Firefox-22 as beta and ot still does not
> work. Please see the attached message for the description of the
> problem.
>
> I think that the problem is related to mismatch between the shared
> librari
I have now tested with with Firefox-22 as beta and ot still does not
work. Please see the attached message for the description of the problem.
I think that the problem is related to mismatch between the shared
libraries in XULRunner and the shared libraries in the Firefox-22
distribution.
Can't you just avoid calling openPopup until the page is loaded, and
avoid messing with the panel's "hidden" state completely?
Gavin
On Thu, May 16, 2013 at 8:27 AM, Matthew Gertner
wrote:
> I have a toolbar button that displays a XUL panel when pressed. The panel
> contains an iframe into whic
I have a toolbar button that displays a XUL panel when pressed. The panel
contains an iframe into which an HTML page is loaded. To avoid "flicker", I'd
like to defer display of the panel until the HTML page has finished loading
(DOMContentLoaded).
I tried setting the panel's hidden property to
On 5/16/13 3:03 PM, Ehsan Akhgari wrote:
> Is this not the OS.File issue that Vladan mentioned?
>
> My point is that there doesn't seem to be enough use cases to warrant a
> new infrastructure to handle shutdown dependencies.
Well, as we expand our use of OS.File, we start observing a number of
i
On 16/05/2013 15:03, Ehsan Akhgari wrote:
Is this not the OS.File issue that Vladan mentioned?
Yes but it seems to me that it's not an OS.File-specific issue. Anything
using workers might run into shutdown problems if the same situation
arises (pending but not-yet-loaded worker requiring an a
On 5/15/13 11:32 PM, Gregory Szorc wrote:
On 5/15/13 2:18 PM, Vladan Djeric wrote:
I think the more compelling use case is service startup. Proper
dependencies should allow us to more intelligently start services on
demand. This should lead to lower resource utilization and faster
startup times.
On 2013-05-16 7:30 AM, Gabriele Svelto wrote:
Do you have use cases besides these two?
In bug 845190 [1] we're seeing an issue which might be caused by an
unexpected shutdown sequence. What seems to be happening is that a DOM
worker thread is created very late during the test; once ShutdownXPCO
Do you have use cases besides these two?
In bug 845190 [1] we're seeing an issue which might be caused by an
unexpected shutdown sequence. What seems to be happening is that a DOM
worker thread is created very late during the test; once ShutdownXPCOM()
is invoked the worker runtime service is
On 5/16/13 2:26 AM, Robert Kaiser wrote:
> David Rajchenbach-Teller schrieb:
>> I'd even go as far as limiting it to 16kb.
>> (possibly with a transition phase during which going above 16kb only
>> prints warnings)
>
> I think most of us agree, but the problem is that apparently a number of
> add-
On Wed, May 15, 2013 at 11:42:33AM +0200, Mike Hommey wrote:
> Hi,
>
> With the increasing number of reports of local builds for Linux and
> Android hitting the 32-bits address space limits when linking, and with
> the fact that gcc 4.7 on try does hit that limit on PGO builds, it has
> become nec
25 matches
Mail list logo
