On Fri, Oct 27, 2017 at 4:48 AM, Sophana "Soap" Aik wrote:
> Hello everyone, great feedback that I will keep in mind and continue to work
> with our vendors to find the best solution with. One of the cards that I was
> looking at is fairly cheap and can at least drive multi-displays (even 4K
> 60h
As of Bug 792059 landing, If you're adding new WebIDL interfaces to gecko,
we will now generate constant definitions in the binding namespace of the
C++ binding headers.
For example, if you have a WebIDL interface that looks like
---
interface TestExampleInterface {
...
[NeedsWindowsUndef]
c
On Thu, Oct 26, 2017 at 4:31 PM, Mike Hommey wrote:
> On Thu, Oct 26, 2017 at 04:02:20PM -0700, Gregory Szorc wrote:
> > Also, the machines come with Windows by default. That's by design: that's
> > where the bulk of Firefox users are. We will develop better products if
> the
> > machines we use
On Thu, Oct 26, 2017 at 04:02:20PM -0700, Gregory Szorc wrote:
> Also, the machines come with Windows by default. That's by design: that's
> where the bulk of Firefox users are. We will develop better products if the
> machines we use every day resemble what actual users use. I would encourage
> de
On Thu, Oct 26, 2017 at 7:02 PM, Gregory Szorc wrote:
> I also share your desire to not issue fancy video cards in these machines
> by default. If there are suggestions for a default video card, now is the
> time to make noise :)
Intel GPUs are the best choice if you want to be like bulk of our
u
On Thu, Oct 26, 2017 at 7:02 PM, Gregory Szorc wrote:
> Unless you have requirements that prohibit using a
> VM, I encourage using this setup.
rr doesn't work in hyper-v. AFAIK the only Windows VM it works in is VMWare
-Jeff
___
dev-platform mailing li
On Thu, Oct 26, 2017 at 6:34 AM, Henri Sivonen wrote:
> On Thu, Oct 26, 2017 at 9:15 AM, Henri Sivonen
> wrote:
> > There's a huge downside, though:
> > If the screen stops consuming the DisplayPort data stream, the
> > graphical session gets killed! So if you do normal things like turn
> > the
On 10/26/2017 06:34 AM, Henri Sivonen wrote:
> As for the computer at hand, I want to put an end to this Nvidia
> obstacle to getting stuff done. It's been suggested to me that Radeon
> RX 560 would be well supported by distro-provided drivers, but the
> "*2" footnote at https://help.ubuntu.com/com
On 10/26/17 2:51 PM, Jeff Muizelaar wrote:
What's the use case for a
--enable-optimize, opt-level=1 build?
Fwiw, I ended up doing a fair amount of my work recently in a
"--enable-optimize, --disable-debug, --enable-rust-debug" build, for the
following reasons:
1) I was modifying Rust styl
On Thu, Oct 26, 2017 at 3:08 PM, Gregory Szorc wrote:
> Would it help if we had a separate --enable-optimize-rust (or similar)
> option to control Rust optimizations so we have separate knobs? If we did
> that, --disable-optimize-rust could be opt-level 0 or 1 and
> --enable-optimize-rust could be
On Thu, Oct 26, 2017 at 11:51 AM, Jeff Muizelaar
wrote:
> FWIW, WebRender becomes unusable opt-level=1. It also looks like style
> performance takes quite a hit as well which means that our default
> developer builds become unusable for performance work. I worry that
> people will forget this and
FWIW, WebRender becomes unusable opt-level=1. It also looks like style
performance takes quite a hit as well which means that our default
developer builds become unusable for performance work. I worry that
people will forget this and end up rediscovering only when they look
at profiles (as mstange
On Thu, Oct 26, 2017 at 12:34 AM, Boris Zbarsky wrote:
> Either approach would break at least some legitimate sites.
>
Thanks for confirming this.
In general, as Myk points out, the question of when web pages should be
> able to respond to what sorts of input, and whether they should be able to
On Wed, Oct 25, 2017 at 10:34 AM, Gregory Szorc wrote:
> Compiling Rust code with optimizations is significantly slower than
> compiling without optimizations. As was measured in bug 1411081, the
> difference between rustc's -Copt-level 1 and 2 on an i7-6700K (4+4 cores)
> for a recent revision o
Some of our most troublesome intermittent test failures are leak bugs
("Intermittent LeakSanitizer | leak at ..." or "Intermittent leakcheck
| default process: bytes leaked ...") Even when they fail
frequently, these bugs often seem to remain unresolved for many weeks.
Leaks are sometimes not stro
On 2017-10-26 12:19 PM, Ryan VanderMeulen wrote:
On 10/26/2017 10:14 AM, Milan Sreckovic wrote:
Are we locked into using the same compiler for the ESR updates? In
other words, do we need to keep VS2015 for ESR52 builds until they
are not needed anymore?
Our compiler toolchains are determin
On 10/26/2017 10:14 AM, Milan Sreckovic wrote:
Are we locked into using the same compiler for the ESR updates? In
other words, do we need to keep VS2015 for ESR52 builds until they are
not needed anymore?
Our compiler toolchains are determined with in-tree configs nowadays, so
this change wo
It would be great to get these speed gains for 58, hot on the heels of the
57 release.
My plan is this: if I can get this landed by Monday, that still leaves two
weeks in the cycle. Based on my positive experience thus far with this
compiler (this update has been much more smooth than past ones),
Agreed, changing compilers of an already-released ESR isn't a good idea.
You could use 2017 to build ESR52 locally though, if that's what you're
asking. Our tree has supported 2017 builds for a good while, since it's the
default VS download from Microsoft and a number of Mozillians have been
using
On 26/10/2017 15:14, Milan Sreckovic wrote:
Are we locked into using the same compiler for the ESR updates? In
other words, do we need to keep VS2015 for ESR52 builds until they are
not needed anymore?
Yes, IMO.
Whether or not we're "locked" in any technical sense, I think we should
proba
Are we locked into using the same compiler for the ESR updates? In
other words, do we need to keep VS2015 for ESR52 builds until they are
not needed anymore?
On 26-Oct-17 3:31, Sylvestre Ledru wrote:
Hello,
On 25/10/2017 23:48, David Major wrote:
I'm planning to move production Windows bui
On Thu, Oct 26, 2017 at 9:34 AM, Henri Sivonen wrote:
> As for the computer at hand, I want to put an end to this Nvidia
> obstacle to getting stuff done. It's been suggested to me that Radeon
> RX 560 would be well supported by distro-provided drivers, but the
> "*2" footnote at https://help.ubun
Yeah. I'd suggest anyone who's running Linux on these machines just go
out and buy a $100 AMD GPU to replace the Quadro. Even if you don't
expense the new GPU and just throw the Quadro in the trash you'll
probably be happier.
-Jeff
On Thu, Oct 26, 2017 at 9:34 AM, Henri Sivonen wrote:
> On Thu,
On Thu, Oct 26, 2017 at 9:15 AM, Henri Sivonen wrote:
> There's a huge downside, though:
> If the screen stops consuming the DisplayPort data stream, the
> graphical session gets killed! So if you do normal things like turn
> the screen off or switch input on a multi-input screen, your graphical
>
Hello,
On 25/10/2017 23:48, David Major wrote:
> I'm planning to move production Windows builds to VS2017 (15.4.1) in bug
> 1408789.
>
In which version are you planning to land this change?
As we are close to the end of the 58 cycle in nightly, it would be great
to wait for 59.
Thanks,
Sylvestre
25 matches
Mail list logo
