Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust
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: Rust as build requirement was Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust
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
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: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust
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: Rust as build requirement was Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust
> 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
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: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust
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
Re: FYI: e10s will be enabled in beta 44/45
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
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