Henri Sivonen wrote:
On Wed, Mar 23, 2016 at 1:51 AM, Petr Cerny wrote:
Saying "Linux is good, we can actually do things there, that are
more complicated elsewhere, but you are hindering our development"
sound a bit unfair.
There is no contradiction between Rust working the best on Linux and
On 3/21/2016 18:17, Nicholas Alexander wrote:
On Mon, Mar 21, 2016 at 9:13 AM, Honza Bambas wrote:
tl;dr: Start migrating to use of MOZ_LOG_* instead of NSPR_LOG_*. Don't
worry about backward compatibility tho, when MOZ_LOG_* is not set, we
fallback to NSPR_LOG_* values.
Hi Honza,
Thanks f
Hi!
We are holding off on packaging with nix for a couple quarters because of
how much work in the TC-worker we have ahead of us.
Let's have a nix conversation the first week of the quarter and then we can
see what low hanging fruit there is. Right now, lots of people are stressed
with gsoc and o
Hi!
I resorted/renamed my profile folders...
Now, when I start the Developer Edition with the profile manager, FF creates a
new entry with "dev-edition-default" and the according folders in
\Roaming\Mozilla\Firefox\Profiles\ and \Local\Mozilla\Firefox\Profiles\ (Win7).
How to prevent this and ma
Hi!
In the program folder of FF by Windows there is a file called "removed-files"...
This file includes a list with files (rules) that should be removed...
What's about updating this?
I see a lot of (old) files and folders in the profile folders that should be
IMHO removed to clean up the profile
On Wed, Jan 6, 2016 at 7:15 AM, Henri Sivonen wrote:
> On Thu, Oct 1, 2015 at 9:58 PM, Jonathan Watt wrote:
>> For those who are interested in this, there's a bug to consider integrating
>> the Guidelines Support Library (GSL) into the tree:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1208
Bug 1243083 tracks enabling e10s by default when running tests locally.
I intend to do this for as many harnesses as possible unless someone
says otherwise.
The implication is that the --e10s flag will be renamed to
--disable-e10s. So you'll need to pass in --disable-e10s if you wish to
run witho
On 3/24/16 12:15 PM, Andrew Halberstadt wrote:
If you have any concerns or know of other suites that should explicitly
*not* be run with e10s enabled by default, please let me know.
Do we have any plans for making --debugger not completely useless when
running tests in e10s mode? There are va
On Wed, Mar 23, 2016 at 7:03 PM, Gregory Szorc wrote:
> On Wed, Mar 16, 2016 at 11:49 PM, Gregory Szorc wrote:
>
>>
>> On Thu, Mar 10, 2016 at 8:14 AM, Gregory Szorc wrote:
>>
>>> Visual Studio 2015 has been out for a while. Many people have put in
>>> work to make Firefox build on it. The time
I'm not aware of work around this. If --debugger is completely busted
with e10s, I could potentially make --debugger imply --disable-e10s
until it gets fixed. Is there a bug on file?
I also forgot to mention that command defaults are likely coming soon,
so once bug 1255450 lands you'll be able to
Discussion seems to have wound down. Is there a decision on this?
-r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 3/24/16 12:43 PM, Andrew Halberstadt wrote:
I'm not aware of work around this. If --debugger is completely busted
with e10s, I could potentially make --debugger imply --disable-e10s
until it gets fixed. Is there a bug on file?
I don't know of one.
It's not that it's busted per se, it's that
On Mon, Mar 21, 2016 at 9:13 AM, Honza Bambas wrote:
> tl;dr: Start migrating to use of MOZ_LOG_* instead of NSPR_LOG_*. Don't
> worry about backward compatibility tho, when MOZ_LOG_* is not set, we
> fallback to NSPR_LOG_* values.
Could this be an opportunity to shorten NSPR_LOG_MODULES to jus
+1. The MOZ_DEBUG_CHILD_PROCESS hack is pretty arcane.
On Thu, Mar 24, 2016 at 9:30 AM, Boris Zbarsky wrote:
> On 3/24/16 12:15 PM, Andrew Halberstadt wrote:
>
>> If you have any concerns or know of other suites that should explicitly
>> *not* be run with e10s enabled by default, please let me k
I know that most people aren't debugging e10s on Windows, but if you
are, here's a protip (provided that you are using WinDbg):
If you include the "-o" option in the debugger args, WinDbg will
automatically attach itself to all child processes that are started by
the chrome process. No special
On 3/24/16 9:54 AM, Ralph Giles wrote:
On Mon, Mar 21, 2016 at 9:13 AM, Honza Bambas wrote:
tl;dr: Start migrating to use of MOZ_LOG_* instead of NSPR_LOG_*. Don't
worry about backward compatibility tho, when MOZ_LOG_* is not set, we
fallback to NSPR_LOG_* values.
Could this be an opportuni
On Tuesday, March 22, 2016 at 4:25:35 PM UTC-7, atu...@mozilla.com wrote:
> The Rust compiler has had over 300 snapshots, so re-bootstrapping from ocaml
> would take at least 900 compiles (each one requires three stages of internal
> builds); by my estimation, this would take at least a month of
Do we know whether `set follow-fork-mode child` in gdb would work ? If
not, can we fix it ? It would be a pretty good experience for most
developers that only care about the child.
Paul.
On Thu, Mar 24, 2016, at 06:05 PM, Aaron Klotz wrote:
> I know that most people aren't debugging e10s on Windo
On 3/24/16 10:13 AM, atu...@mozilla.com wrote:
The Rust core team met yesterday and developed a complete plan for Rust to be
build with the previous stable compiler as snapshot. We will be landing the
infrastructure needed to do this shortly.
In terms of release timing, it will take some time
We fork a process to test gfx early on so 'set follow-for-mode child'
might end up following that.
'set detach-on-fork off' will keep you attached to everything though.
-Jeff
On Thu, Mar 24, 2016 at 1:21 PM, Paul Adenot wrote:
> Do we know whether `set follow-fork-mode child` in gdb would work ?
On Thu, Mar 24, 2016 at 9:15 AM, Andrew Halberstadt <
ahalberst...@mozilla.com> wrote:
> Bug 1243083 tracks enabling e10s by default when running tests locally.
> I intend to do this for as many harnesses as possible unless someone
> says otherwise.
Great!
[some text deleted]
One potential sti
Afaict, ./mach mochitest -f chrome --e10s enables e10s. At least the
python side isn't overriding that default. Maybe there's some JS code
somewhere that overrides it.
But if the intent is for mochitest-chrome to never run with e10s enabled
anyway, then I guess not having that option isn't a big
On 2016-03-24 1:25 PM, Andrew McCreight wrote:
> One potential sticking point is mochitest-chrome. It currently does not
>> get run in e10s in CI, so local configuration should mirror this.
>> However, since --e10s is being removed, this means it would be
>> impossible to run mochitest-chrome in e1
Yeah, --e10s enables e10s in the browser for mochitest-chrome. However,
the test harness is a .xul file opened in a tab, and that runs that tab as
non-remote, so for most tests it ends up testing the same thing as not
using --e10s. Other tabs and/or windows opened manually by the test would
be rem
On Thu, Mar 24, 2016 at 2:10 PM, Felipe G wrote:
> Yeah, --e10s enables e10s in the browser for mochitest-chrome. However,
> the test harness is a .xul file opened in a tab, and that runs that tab as
> non-remote, so for most tests it ends up testing the same thing as not
> using --e10s. Other t
On Thursday, March 24, 2016 at 10:21:12 AM UTC-7, Chris Peterson wrote:
> On 3/24/16 10:13 AM, atu...@mozilla.com wrote:
> > The Rust core team met yesterday and developed a complete plan for Rust to
> > be build with the previous stable compiler as snapshot. We will be landing
> > the infrastruc
Yeah, that sounds like another good outcome of replacing --e10s with
--disable-e10s.
On Thu, Mar 24, 2016 at 3:59 PM, Ehsan Akhgari
wrote:
> On Thu, Mar 24, 2016 at 2:10 PM, Felipe G wrote:
>
>> Yeah, --e10s enables e10s in the browser for mochitest-chrome. However,
>> the test harness is a .x
On Thursday, March 24, 2016 at 10:10:30 AM UTC-7, Justin Dolske wrote:
> On 3/24/16 9:54 AM, Ralph Giles wrote:
> > On Mon, Mar 21, 2016 at 9:13 AM, Honza Bambas wrote:
> >
> >> tl;dr: Start migrating to use of MOZ_LOG_* instead of NSPR_LOG_*. Don't
> >> worry about backward compatibility tho, wh
I have already filed bug 1255095 about this, as you are far from the first
person to be confused by this!
Andrew
On Thu, Mar 24, 2016 at 11:59 AM, Ehsan Akhgari
wrote:
> On Thu, Mar 24, 2016 at 2:10 PM, Felipe G wrote:
>
>> Yeah, --e10s enables e10s in the browser for mochitest-chrome. Howeve
The removed-files file is only used for files within the application
directory during an application update. This mitigates security issues of
having an elevated process manipulating files outside of the application
directory which can lead to exploits. There are cases where this process
won't have
Slightly related: since bug 1253233 landed (well, hum, the most important parts
of it), it’s possible to add fully functioning
elements to mochitest-chrome test windows. Since many chrome test use the
pattern of adding a browser element and do stuff with it upon load, I thought
this might be a
Hey all,
Sandboxing is currently enabled for content processes for a couple platforms.
If you're curious where a sandbox is running you can check current status at
the sandboxing wiki page [1].
The team has a process in place for triaging incoming bugs on a weekly basis.
If you think you have
I want to port Firefox OS 2.5 to my phone which support android system. And
I've done the following things:
1. Get the Firefox OS 2.5 code from git and config the nexus-5-l branch.
2. Replace the kernel with the prebuilt one from my android kernel source code.
3. Modify a little in init.rc ( which
Felipe G. writes:
> Yeah, --e10s enables e10s in the browser for mochitest-chrome. However,
> the test harness is a .xul file opened in a tab, and that runs that tab as
> non-remote, so for most tests it ends up testing the same thing as not
> using --e10s. Other tabs and/or windows opened manual
On Fri, Mar 25, 2016 at 12:44 AM, Gregory Szorc wrote:
> On Wed, Mar 23, 2016 at 7:03 PM, Gregory Szorc wrote:
>
> > On Wed, Mar 16, 2016 at 11:49 PM, Gregory Szorc wrote:
> >
> >>
> >> On Thu, Mar 10, 2016 at 8:14 AM, Gregory Szorc wrote:
> >>
> >>> Visual Studio 2015 has been out for a while
> On Mar 24, 2016, at 23:25, Xidorn Quan wrote:
>
>> On Fri, Mar 25, 2016 at 12:44 AM, Gregory Szorc wrote:
>> On Wed, Mar 23, 2016 at 7:03 PM, Gregory Szorc wrote:
>>
>> > On Wed, Mar 16, 2016 at 11:49 PM, Gregory Szorc wrote:
>> >
>> >>
>> >> On Thu, Mar 10, 2016 at 8:14 AM, Gregory Szorc
36 matches
Mail list logo
