Re: [dev-servo] Using IPC channels with Tokio?
Thanks On Sun, Dec 4, 2016 at 10:51 AM, Olaf Buddenhagen wrote: > Hi, > > On Wed, Nov 16, 2016 at 07:48:36PM +0100, Eddy Bruel wrote: > > > To make IPC channels usable with Tokio, we'd have to take whatever low > > level IO primitive IPC channels use under the hood, and then reimplement > > the same logic that the existing IPC channels implement on top of this, > but > > using a streams based API (by streams, I mean the streams from the > > futures-rs, crate). > > > > I'm not quite sure how much work this would be, since I don't know how > > complex ipc channels are under the hood. > > The low-level I/O in some of the platform back-ends in ipc-channel is > quite intricate -- and might change in incompatible ways at any time. I > don't think it's a good idea to try reimplementing it. Rather, we should > try to reuse as much of the existing low-level code as we can, while > creating an alternative API entry point. > > My *intuition* is that this should be quite doable -- though of course I > might be wrong... Especially since I'm not really familiar with Tokio > yet, beyond having some very rough idea of what it does. > > -antrik- > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] DOM goals for 2017
Hey everyone! It's time to make plans for 2017, so here are my thoughts on the subject. I think we should focus on the following high-level goals: 1) track performance metrics that are relevant to users 2) address web compatibility issues, prioritized according to frequency on real websites 3) reduce barriers to contributing to the DOM code These will allow us to make more meaningful comparisons between Servo and other production web browsers, while continuing to provide opportunities for volunteer contributors to make an impact. Broken down, I envision the following tasks allowing us to focus our efforts: 1) track performance metrics that are relevant to users * report progressive web metrics [1] 2) address web compatibility issues, prioritized according to frequency on real websites * implement missing/broken features required by Google Docs * support the needs of the WebVR team * track web compatibility issues on real websites * investigate panics reported by nightly users 3) reduce barriers to contributing to the DOM code * reduce the time required to build after changing non-WebIDL/bindings code * create high level abstractions for common patterns * reduce the need for unsafe code We've got a good base to work from - there are still some significant pieces of the web platform that we know are holding us back right now, but in general it feels like there is a long tail of smaller compatibility issues that we need to address. In 2017 I want to get a handle on how long that tail is and start addressing it. This will require being deliberate about trying Servo on a wide variety of sites, and filing issues to track everything that's not working correctly. We also have a small but enthusiastic group of people who try out nightly builds on a regular basis, and they're really helpful! Panics reported from nightly builds often go uninvestigated, and I believe this is hurting our compatibility story. Finally, we're all aware that working in the script crate can be a frustrating experience. It's time to start dealing with the burden of technical debt - we need to look for ways to write better async code, less unsafe code, and address the ever-growing, monolithic script crate. I have ideas I want to try for each of these problems, and I encourage everyone to be ambitious about them. I'm going to stop here rather than breaking down those tasks any further. I've got a list of issues that I want to tackle that address each of them, and it's going to get much larger once I get results back from the Blink team about DOM API use on the top 100,000 sites. I would welcome any feedback people have about these plans I've described so far! Cheers, Josh [1] https://groups.google.com/forum/#!topic/mozilla.dev.servo/LSWE3MdUGY4 ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] DOM goals for 2017
These seem like exactly the goals I'd come up with, as an occasional contributor to the DOM. +1! Patrick On Wed, Dec 14, 2016 at 9:03 AM, Josh Matthews wrote: > Hey everyone! It's time to make plans for 2017, so here are my thoughts on > the subject. I think we should focus on the following high-level goals: > > 1) track performance metrics that are relevant to users > 2) address web compatibility issues, prioritized according to frequency on > real websites > 3) reduce barriers to contributing to the DOM code > > These will allow us to make more meaningful comparisons between Servo and > other production web browsers, while continuing to provide opportunities > for volunteer contributors to make an impact. > > Broken down, I envision the following tasks allowing us to focus our > efforts: > > 1) track performance metrics that are relevant to users > * report progressive web metrics [1] > > 2) address web compatibility issues, prioritized according to frequency on > real websites > * implement missing/broken features required by Google Docs > * support the needs of the WebVR team > * track web compatibility issues on real websites > * investigate panics reported by nightly users > > 3) reduce barriers to contributing to the DOM code > * reduce the time required to build after changing non-WebIDL/bindings code > * create high level abstractions for common patterns > * reduce the need for unsafe code > > We've got a good base to work from - there are still some significant > pieces of the web platform that we know are holding us back right now, but > in general it feels like there is a long tail of smaller compatibility > issues that we need to address. In 2017 I want to get a handle on how long > that tail is and start addressing it. This will require being deliberate > about trying Servo on a wide variety of sites, and filing issues to track > everything that's not working correctly. > > We also have a small but enthusiastic group of people who try out nightly > builds on a regular basis, and they're really helpful! Panics reported from > nightly builds often go uninvestigated, and I believe this is hurting our > compatibility story. > > Finally, we're all aware that working in the script crate can be a > frustrating experience. It's time to start dealing with the burden of > technical debt - we need to look for ways to write better async code, less > unsafe code, and address the ever-growing, monolithic script crate. I have > ideas I want to try for each of these problems, and I encourage everyone to > be ambitious about them. > > I'm going to stop here rather than breaking down those tasks any further. > I've got a list of issues that I want to tackle that address each of them, > and it's going to get much larger once I get results back from the Blink > team about DOM API use on the top 100,000 sites. I would welcome any > feedback people have about these plans I've described so far! > > Cheers, > Josh > > > [1] https://groups.google.com/forum/#!topic/mozilla.dev.servo/LSWE3MdUGY4 > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] DOM goals for 2017
The only missing piece to this is the performance work / magic dom exploration. I am already excited for next year :) jack. On Wed, Dec 14, 2016 at 10:09 AM, Patrick Walton wrote: > These seem like exactly the goals I'd come up with, as an occasional > contributor to the DOM. +1! > > Patrick > > On Wed, Dec 14, 2016 at 9:03 AM, Josh Matthews > wrote: > >> Hey everyone! It's time to make plans for 2017, so here are my thoughts on >> the subject. I think we should focus on the following high-level goals: >> >> 1) track performance metrics that are relevant to users >> 2) address web compatibility issues, prioritized according to frequency on >> real websites >> 3) reduce barriers to contributing to the DOM code >> >> These will allow us to make more meaningful comparisons between Servo and >> other production web browsers, while continuing to provide opportunities >> for volunteer contributors to make an impact. >> >> Broken down, I envision the following tasks allowing us to focus our >> efforts: >> >> 1) track performance metrics that are relevant to users >> * report progressive web metrics [1] >> >> 2) address web compatibility issues, prioritized according to frequency on >> real websites >> * implement missing/broken features required by Google Docs >> * support the needs of the WebVR team >> * track web compatibility issues on real websites >> * investigate panics reported by nightly users >> >> 3) reduce barriers to contributing to the DOM code >> * reduce the time required to build after changing non-WebIDL/bindings code >> * create high level abstractions for common patterns >> * reduce the need for unsafe code >> >> We've got a good base to work from - there are still some significant >> pieces of the web platform that we know are holding us back right now, but >> in general it feels like there is a long tail of smaller compatibility >> issues that we need to address. In 2017 I want to get a handle on how long >> that tail is and start addressing it. This will require being deliberate >> about trying Servo on a wide variety of sites, and filing issues to track >> everything that's not working correctly. >> >> We also have a small but enthusiastic group of people who try out nightly >> builds on a regular basis, and they're really helpful! Panics reported from >> nightly builds often go uninvestigated, and I believe this is hurting our >> compatibility story. >> >> Finally, we're all aware that working in the script crate can be a >> frustrating experience. It's time to start dealing with the burden of >> technical debt - we need to look for ways to write better async code, less >> unsafe code, and address the ever-growing, monolithic script crate. I have >> ideas I want to try for each of these problems, and I encourage everyone to >> be ambitious about them. >> >> I'm going to stop here rather than breaking down those tasks any further. >> I've got a list of issues that I want to tackle that address each of them, >> and it's going to get much larger once I get results back from the Blink >> team about DOM API use on the top 100,000 sites. I would welcome any >> feedback people have about these plans I've described so far! >> >> Cheers, >> Josh >> >> >> [1] https://groups.google.com/forum/#!topic/mozilla.dev.servo/LSWE3MdUGY4 >> ___ >> dev-servo mailing list >> dev-servo@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-servo >> > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] DOM goals for 2017
So, for Firefox in 2017 we have a gross (meaning unrefined, broad) plan to gather the many sources of data we already have in Gecko (SPS; TraceLogger; TaskTracer; Window.performance; and on and on) into a single stream of data: - There should be a common API to enumerate and enable/disable data sources. - The disposition of the stream can be selected: circular buffer, captured on request, like Cleopatra? Log to file as JSON? protobuf on a socket? Send to an in-browser visualization tool? - Stream entries should have enough metadata to let generic tools plot them in some helpful way, as long as they have one of the usual shapes: point in time; range of time; native stack; JS stack; textual label; id with edges to other ids; etc. We're aiming to compete with fprintf: it should be almost as easy for a dev to hack in some instrumentation, recompile, and immediately see the results in the devtools, with no devtools UI hacking required, as it would be to fprintf it and glop it up into a Python script. SpiderMonkey will depend on the stream, so it'll be present in Servo once it picks up a recent enough version. It should be feasible to have Rust APIs for contributing data to the stream, so Servo could contribute, too. I don't know what would be entailed if we wanted to incorporate the new Cleopatra UI ( https://github.com/mstange/cleopatra ) into Servo, or if that's even desirable. But I don't know of any reason it would be more difficult than incorporating any other HTML/JS - based devtool UI. On Wed, Dec 14, 2016 at 9:42 AM, Jack Moffitt wrote: > The only missing piece to this is the performance work / magic dom > exploration. I am already excited for next year :) > > jack. > > On Wed, Dec 14, 2016 at 10:09 AM, Patrick Walton > wrote: > > These seem like exactly the goals I'd come up with, as an occasional > > contributor to the DOM. +1! > > > > Patrick > > > > On Wed, Dec 14, 2016 at 9:03 AM, Josh Matthews > > wrote: > > > >> Hey everyone! It's time to make plans for 2017, so here are my thoughts > on > >> the subject. I think we should focus on the following high-level goals: > >> > >> 1) track performance metrics that are relevant to users > >> 2) address web compatibility issues, prioritized according to frequency > on > >> real websites > >> 3) reduce barriers to contributing to the DOM code > >> > >> These will allow us to make more meaningful comparisons between Servo > and > >> other production web browsers, while continuing to provide opportunities > >> for volunteer contributors to make an impact. > >> > >> Broken down, I envision the following tasks allowing us to focus our > >> efforts: > >> > >> 1) track performance metrics that are relevant to users > >> * report progressive web metrics [1] > >> > >> 2) address web compatibility issues, prioritized according to frequency > on > >> real websites > >> * implement missing/broken features required by Google Docs > >> * support the needs of the WebVR team > >> * track web compatibility issues on real websites > >> * investigate panics reported by nightly users > >> > >> 3) reduce barriers to contributing to the DOM code > >> * reduce the time required to build after changing non-WebIDL/bindings > code > >> * create high level abstractions for common patterns > >> * reduce the need for unsafe code > >> > >> We've got a good base to work from - there are still some significant > >> pieces of the web platform that we know are holding us back right now, > but > >> in general it feels like there is a long tail of smaller compatibility > >> issues that we need to address. In 2017 I want to get a handle on how > long > >> that tail is and start addressing it. This will require being deliberate > >> about trying Servo on a wide variety of sites, and filing issues to > track > >> everything that's not working correctly. > >> > >> We also have a small but enthusiastic group of people who try out > nightly > >> builds on a regular basis, and they're really helpful! Panics reported > from > >> nightly builds often go uninvestigated, and I believe this is hurting > our > >> compatibility story. > >> > >> Finally, we're all aware that working in the script crate can be a > >> frustrating experience. It's time to start dealing with the burden of > >> technical debt - we need to look for ways to write better async code, > less > >> unsafe code, and address the ever-growing, monolithic script crate. I > have > >> ideas I want to try for each of these problems, and I encourage > everyone to > >> be ambitious about them. > >> > >> I'm going to stop here rather than breaking down those tasks any > further. > >> I've got a list of issues that I want to tackle that address each of > them, > >> and it's going to get much larger once I get results back from the Blink > >> team about DOM API use on the top 100,000 sites. I would welcome any > >> feedback people have about these plans I've described so far! > >> > >> Cheers, > >> Josh
[dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?
I'm thinking about splitting those parts into a separate crate because currently servo/style component's build script is doing two different things: 1. generate property code, 2. do bindgen. And mixing these things may lead to many unnecessary rebuild. In the current build-time bindgen code, all headers directly or indirectly included by header processed are listed as "cargo:rerun-if-changed", but majority of them may not actually affect the output of bindgen, and in that case, we don't really need to rebuild the style crate and anything depends on it. For solving that problem, I filed an issue [1] to cargo suggesting that we should have a mechanism for build script to inform cargo not to rebuild the crate simply because of build script. With that mechanism, we can compare the output of bindgen and see whether it is same as the existing code, and tell cargo not to rebuild if the code doesn't change. However, even if we have that mechanism, we cannot really tell whether rebuild is necessary for build script of style component, because we also generate property code there, and it seems to me detecting whether that code changes costs more work and doesn't make much sense, because unlike bindings generated from C++ code, changes to the template or property data likely actually need a rebuild. Given these, I guess the best solution would be to split the gecko binding things out into a separate crate with its own build script. Thoughts? [1] https://github.com/rust-lang/cargo/issues/3404 - Xidorn ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?
They used to be a different crate. I merged them so that we can do replacements with safer wrappers and have fewer coherence issues. Perhaps we can make triggering local build time bindgen regen more explicit? On Dec 14, 2016 2:57 PM, "Xidorn Quan" wrote: > I'm thinking about splitting those parts into a separate crate because > currently servo/style component's build script is doing two different > things: 1. generate property code, 2. do bindgen. And mixing these > things may lead to many unnecessary rebuild. > > In the current build-time bindgen code, all headers directly or > indirectly included by header processed are listed as > "cargo:rerun-if-changed", but majority of them may not actually affect > the output of bindgen, and in that case, we don't really need to rebuild > the style crate and anything depends on it. > > For solving that problem, I filed an issue [1] to cargo suggesting that > we should have a mechanism for build script to inform cargo not to > rebuild the crate simply because of build script. With that mechanism, > we can compare the output of bindgen and see whether it is same as the > existing code, and tell cargo not to rebuild if the code doesn't change. > > However, even if we have that mechanism, we cannot really tell whether > rebuild is necessary for build script of style component, because we > also generate property code there, and it seems to me detecting whether > that code changes costs more work and doesn't make much sense, because > unlike bindings generated from C++ code, changes to the template or > property data likely actually need a rebuild. > > Given these, I guess the best solution would be to split the gecko > binding things out into a separate crate with its own build script. > > Thoughts? > > [1] https://github.com/rust-lang/cargo/issues/3404 > > - Xidorn > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?
On Thu, Dec 15, 2016, at 12:01 PM, Manish Goregaokar wrote: > They used to be a different crate. I merged them so that we can do > replacements with safer wrappers and have fewer coherence issues. It doesn't seem to me the safer wrappers (I suppose the ones in gecko_bindings/sugar?) needs the bindings to stay in the style component. We can still leave gecko mod in style component, and just split out the bindings mods. That shouldn't cause much trouble I suppose. > Perhaps we can make triggering local build time bindgen regen more > explicit? You mean, probably not listing that many files in cargo:rerun-if-changed? That probably works I guess. - Xidorn ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?
The sugar stuff is just helpers. The crossover happens in the bindings file itself, where &ServoOpaqueType gets replaced with &RealType, etc. On Dec 14, 2016 5:13 PM, "Xidorn Quan" wrote: > On Thu, Dec 15, 2016, at 12:01 PM, Manish Goregaokar wrote: > > They used to be a different crate. I merged them so that we can do > > replacements with safer wrappers and have fewer coherence issues. > > It doesn't seem to me the safer wrappers (I suppose the ones in > gecko_bindings/sugar?) needs the bindings to stay in the style > component. We can still leave gecko mod in style component, and just > split out the bindings mods. That shouldn't cause much trouble I > suppose. > > > Perhaps we can make triggering local build time bindgen regen more > > explicit? > > You mean, probably not listing that many files in > cargo:rerun-if-changed? That probably works I guess. > > - Xidorn > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?
On 15/12/16 02:01, Manish Goregaokar wrote: They used to be a different crate. I merged them so that we can do replacements with safer wrappers and have fewer coherence issues. Could the code generated by bindgen be separated from the wrappers? That way wrappers could be wherever impl coherence require them to be, while keeping the bindgen-using build script in a dedicated crate. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?
Yes, this could be done. I would like to have more automated checks here however if we were to do this. At one point I had considered letting the generated bindings be super unsafe and then for each servo_*/gecko_* function have a safe wrapper that is generated (or handwritten?) that forwards to it with the types replaced. Generating it would still require the bindings build step to write code for the style crate however. I wasn't sure if we could trust manually writing it. On Dec 14, 2016 10:45 PM, "Simon Sapin" wrote: > On 15/12/16 02:01, Manish Goregaokar wrote: > >> They used to be a different crate. I merged them so that we can do >> replacements with safer wrappers and have fewer coherence issues. >> > > Could the code generated by bindgen be separated from the wrappers? That > way wrappers could be wherever impl coherence require them to be, while > keeping the bindgen-using build script in a dedicated crate. > > -- > Simon Sapin > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
