Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust

[Nicholas Nethercote]

On Sun, Dec 13, 2015 at 9:17 AM, Cameron Kaiser  wrote:
>
> This would essentially mandate, then, that Gecko can only be built on
> platforms with a Rust toolchain. That may be desirable, but it would
> probably bust some of the obscure Tier-3 platforms and it would definitely
> bust TenFourFox (we can't even get clang to be happy on 10.4 currently). Not
> that we haven't been on borrowed time for awhile; I just point it out for
> the record.

I've been wondering about this. There's a big difference between (a)
permitting Rust components (while still allowing fallback C++
equivalents) and (b) mandating Rust components.

Step (a) is close at hand but I'm not aware of any planning or
predictions for when (b) will happen. The most detail I've seen was in
an exchange I had on Hackers News [1] where I said "it feels like
something that is multiple years away" and pcwalton replied "I agree
with you on the probable time frame here."

[1] https://news.ycombinator.com/item?id=10522194

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust

[Nicholas Nethercote]

On Sun, Dec 13, 2015 at 11:28 AM, Bobby Holley  wrote:
>>
>> I've been wondering about this. There's a big difference between (a)
>> permitting Rust components (while still allowing fallback C++
>> equivalents) and (b) mandating Rust components.
>
> I don't know why we would allow there to be a long gap between (a) and (b).
> Maintaining/supporting two sets of the same code is costly. So if we get the
> rust code working and shipping on all platforms, I can't think of a reason
> why we wouldn't move as quickly as possible to requiring it.

The "if" in your second sentence is exactly what I'm worried about. My
gut tells me that step (b) is a *lot* harder than step (a). I could be
too pessimistic, but Android and the tier 3 platforms worry me.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust as build requirement was Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust

[Cameron Kaiser]

On 12/13/15 12:50 AM, Nicholas Nethercote wrote:

On Sun, Dec 13, 2015 at 9:17 AM, Cameron Kaiser  wrote:


This would essentially mandate, then, that Gecko can only be built on
platforms with a Rust toolchain. That may be desirable, but it would
probably bust some of the obscure Tier-3 platforms and it would definitely
bust TenFourFox (we can't even get clang to be happy on 10.4 currently). Not
that we haven't been on borrowed time for awhile; I just point it out for
the record.


I've been wondering about this. There's a big difference between (a)
permitting Rust components (while still allowing fallback C++
equivalents) and (b) mandating Rust components.

Step (a) is close at hand but I'm not aware of any planning or
predictions for when (b) will happen. The most detail I've seen was in
an exchange I had on Hackers News [1] where I said "it feels like
something that is multiple years away" and pcwalton replied "I agree
with you on the probable time frame here."

[1] https://news.ycombinator.com/item?id=10522194


On the other hand, in that same thread, metajack said, "The current plan 
is to have Rust (in the form of rust-url replacing nsUrlParser) riding 
the trains later this quarter."


My usual genial scepticism alleges "this quarter" is optimistic, but I 
can well see it occurring Q1/Q2 2016. I did some Bugzilla digging and 
while the current plan in bug 1151899 is to run them in parallel, I 
foresee that lasting at most a release or two. That said, there hasn't 
been any activity on it since April.


Cameron Kaiser
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust

[Bobby Holley]

On Sun, Dec 13, 2015 at 3:50 AM, Nicholas Nethercote  wrote:

> On Sun, Dec 13, 2015 at 9:17 AM, Cameron Kaiser 
> wrote:
> >
> > This would essentially mandate, then, that Gecko can only be built on
> > platforms with a Rust toolchain. That may be desirable, but it would
> > probably bust some of the obscure Tier-3 platforms and it would
> definitely
> > bust TenFourFox (we can't even get clang to be happy on 10.4 currently).
> Not
> > that we haven't been on borrowed time for awhile; I just point it out for
> > the record.
>
> I've been wondering about this. There's a big difference between (a)
> permitting Rust components (while still allowing fallback C++
> equivalents) and (b) mandating Rust components.
>
> Step (a) is close at hand but I'm not aware of any planning or
> predictions for when (b) will happen.


I don't know why we would allow there to be a long gap between (a) and (b).
Maintaining/supporting two sets of the same code is costly. So if we get
the rust code working and shipping on all platforms, I can't think of a
reason why we wouldn't move as quickly as possible to requiring it.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust as build requirement was Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust

[Jack Moffitt]

> On the other hand, in that same thread, metajack said, "The current plan is
> to have Rust (in the form of rust-url replacing nsUrlParser) riding the
> trains later this quarter."

And indeed, Rust is now riding the trains with the moov parser. It's
not required for the build yet, but Nightly (and soon Aurora)
dsitributions will both have it.

You can see this by looking at telemetry for MEDIA_RUST_MP4PARSER_SUCCESS.

jack.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust

[Robert O'Callahan]

On Sun, Dec 13, 2015 at 2:28 PM, Bobby Holley  wrote:

> I don't know why we would allow there to be a long gap between (a) and (b).
> Maintaining/supporting two sets of the same code is costly. So if we get
> the rust code working and shipping on all platforms, I can't think of a
> reason why we wouldn't move as quickly as possible to requiring it.
>

I agree. I'd like to know why Nick and Patrick think this is multiple years
away. It had better not be!

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: FYI: e10s will be enabled in beta 44/45

[Daniel Veditz]

On Mon, Dec 7, 2015 at 4:36 AM, Kurt Roeckx  wrote:

> On 2015-12-04 19:43, jmath...@mozilla.com wrote:
>
>> Not an issue since initial rollout to beta and release will be to users
>> who do not have addons installed.
>>
>
> Is it even possible to have no addons installed?  Firefox installed a
> number of them on it's own without asking me.


​Jim meant the "extension" type of add-on specifically, not everything that
shows up on about:addons. Firefox shouldn't be installing extensions on its
own, unless you're a beta user who hasn't disabled "experiments" (if we're
still doing those) or we have a security issue that requires a "hotfix".

-Dan Veditz
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: APZ enabled on Fennec nightly

[Jared Wein]

Nice feedback on Reddit about the changes. Great job!

https://www.reddit.com/r/firefox/comments/3wo4rm/nightlyandroid_scroll_speed_is_improving/

- jared

On Wed, Dec 2, 2015 at 12:39 PM, Kartikaya Gupta  wrote:

> Thanks for trying it out and reporting these issues! I've filed them
> as separate bugs - bug 1229840, bug 1229839, and bug 1229841. We
> should be able to address 2 and 3 by tuning some prefs, 1 will take a
> bit more investigation.
>
> Cheers,
> kats
>
> On Wed, Dec 2, 2015 at 11:31 AM,   wrote:
> > Thanks for hard the work on this! I'm happy you're working on improving
> the scrolling.
> >
> >
> > Since the change, I've noticed a few things:
> >
> > 1. Reader mode's toolbar now sometimes seems to jump up and down several
> times.
> >
> > 2. Deceleration takes too long to happen (the page seems to just float
> for far too long after flings happen, especially for slower, smaller
> flings). It's much slower than other apps, and it also feels much slower
> than I remember for Firefox before the update.
> >
> > 3. Quick flings don't jump up or down on the page as quickly as they
> previously did, making more work to get back up to the top of a page, or to
> quickly jump down to read the summary paragraph of an article.
> >
> >
> > This is all on a Nexus 6P running stock Android Marshmallow, by-the-way.
> It might feel different on other devices.
> >
> >
> > Again, thanks for working on this! I know it's a WIP in Nightly it's
> probably subject to change a little with a few tweaks.
> >
> > Cheers,
> > Garrett
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust

[Bobby Holley]

On Sun, Dec 13, 2015 at 6:27 PM, Nicholas Nethercote  wrote:

> On Sun, Dec 13, 2015 at 11:28 AM, Bobby Holley 
> wrote:
> >>
> >> I've been wondering about this. There's a big difference between (a)
> >> permitting Rust components (while still allowing fallback C++
> >> equivalents) and (b) mandating Rust components.
> >
> > I don't know why we would allow there to be a long gap between (a) and
> (b).
> > Maintaining/supporting two sets of the same code is costly. So if we get
> the
> > rust code working and shipping on all platforms, I can't think of a
> reason
> > why we wouldn't move as quickly as possible to requiring it.
>
> The "if" in your second sentence is exactly what I'm worried about. My
> gut tells me that step (b) is a *lot* harder than step (a). I could be
> too pessimistic, but Android


I believe there's a plan there, but don't have a good window into how long
it will take.


> and the tier 3 platforms


I'm pretty sure we wouldn't block on those, precisely because they're
tier-3.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform