Re: [dev-servo] Should we use Dependabot?
On 22/04/2020 20:30, Josh Matthews wrote: * it provides links to changelogs/release notes/included commits which makes reviewing easier Does this also work for crates.io dependencies? (As opposed to git dependencies.) Does it rely on the upstream repository having git tags that happen to match the crates.io version numbers? -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] The future of irc.mozilla.org/#servo
On 19/12/2019 17:43, Josh Bowman-Matthews wrote: * crowbot is an IRC bot whose biggest responsibilities include github link integration, collecting standups entries, and recording messages for users who aren't online. Riot (the main Matrix client) provides "URL previews" by default, which for GitHub PRs includes the title and start of the description. Matrix already records messages while no client is running, clients show and highlight the next time they run mentions that happen during that time. So it looks like what remains is mostly standups? Benjamin said he’d be open to accepting PRs to https://github.com/bnjbvr/botzilla -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Re-enable non_snake_case warnings?
On 09/01/2020 22:33, Josh Matthews wrote: After coming across an instance of a non-snake case variable name that didn't trigger any compiler warnings, I discovered that we disabled that warning for the script crate 5 years ago (https://github.com/servo/servo/commit/dc86e8365495acc87b983a290bb7277a37a5247f#diff-7efb30b262e93375ff2af348d5a870f9R11). Any objections to re-enabling it in Servo-specific code throughout the project and fixing the existing instances? No objection, but fixing may be non-trivial. Changing that `allow` to `deny` produces: error: aborting due to 368 previous errors It looks like many of these names are generated from WebIDL, so this might require codegen change (not just renames in source code). -- Simon ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] The future of irc.mozilla.org/#servo
On 20/12/2019 17:41, Josh Bowman-Matthews wrote: One more IRC integration that I forgot about - we receive notifications about daily taskcluster job failures on IRC. We'll want to verify the plans for the taskcluster-notify service with respect to Matrix. I asked: Hi. What’s the future of IRC notifications through https://docs.taskcluster.net/docs/reference/core/notify/usage ? Will they move to Matrix? > I believe they should, yeah. I know it has been talked about before matrix was announced. It will need to be implemented first, though, and I'm not sure what the taskcluster team's bandwidth for that is. it's on our radar. probably can get it done in q1? assuming that their api isn't too hard to work with also could be a great contributor project actually https://github.com/taskcluster/taskcluster/tree/master/services/notify looks like it’s in JS, and https://github.com/matrix-org/matrix-js-sdk exists yeah, the plan is to use that but it could still take a little while to get it all working ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] The future of irc.mozilla.org/#servo
I’ve been mostly happy with IRC, but for #servo I think I’d like to try out Matrix since many Mozillians will need it anyway. https://view.matrix.org/ can presumably fulfill public logging (and might be maintained by more than one person). Porting bots to a different protocol would take some work but seems doable. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Tree is back open
On 16/11/2019 05:25, Josh Bowman-Matthews wrote: I have closed the tree because mac3 is not in a usable state (https://github.com/servo/servo/issues/24755) and my attempts to follow the instructions in https://github.com/servo/taskcluster-config/ to disable it have not succeeded. The tree will remain closed until mac3 can either be removed from the pool of workers or repaired. I’ve (hopefully) fixed this and reopened the tree: https://github.com/servo/servo/issues/24755#issuecomment-554619776 -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] CSS, SVG, and Houdini meetings on September 16-20
TPAC, W3C’s yearly gathering, happens in a couple weeks: https://www.w3.org/2019/09/TPAC/schedule.html I plan to attend the meetings for the CSS WG, the SVG WG, and the Houdini TF. Let me know if you have topics that I should bring to either of those groups’ attention. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] ./mach build vs. cargo build
On 05/04/18 18:21, Matt Brubeck wrote: We can set rustflags in the `[build]` section of .cargo/config: https://doc.rust-lang.org/cargo/reference/config.html I tried to do this for the unused extern crate warning (ld.gold can already be disabled through a `.servobuild` config) but hit https://github.com/rust-lang/cargo/issues/5376 -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] ./mach build vs. cargo build
On 03/04/18 23:30, Emilio Cobos Álvarez wrote: or the bit to use the gold linker. The best outcome IMO would be to make that the default: https://github.com/rust-lang/rust/issues/30783 This was implemented and then reverted because of Debian Wheezy (oldoldstable), whose LTS ends next month in May. My pings on the issue a few months ago did not get a response, so the next step is probably sending a PR and picking someone on the compiler team to nag for review. -- Simon ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Best practices for running try builds
On 24/01/18 22:19, Emilio Cobos Álvarez wrote: please consider relying on the grid (see #1) rather than retrying until you get a success notice from homu. Just to make sure, how should we deal with when one of these failures happen and prevent a PR from landing? I assume Josh was talking about try builds (where you can maybe be satisfied when the grid mostly green) and did not mean to suggest bypassing homu when it’s time to actually land something. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] PSA: Servo now uses rustup.rs, you can probably free up some disk space
On 13/01/18 23:35, pyfi...@gmail.com wrote: Hi, I deleted .cargo and noticed that there was a file .cargo/config in this folder which is still part of the git repo. (https://github.com/servo/servo/blob/7b92eb932b34ce1a4b823b2571a50a928491b4b2/.cargo/config) Is it still needed or can it be removed? Oops. Yes, this file should stay. Besides that, I *think* you should only have .cargo/git and .cargo/registry. These are the download cache for dependencies. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] PSA: Servo now uses rustup.rs, you can probably free up some disk space
https://github.com/servo/servo/pull/19395 has (finally) landed. Instead of custom scripts, Servo now uses rustup.rs (which needs to be installed separately) to download and manage various versions of Rust and Cargo. These files are kept under $RUSTUP_HOME/toolchains. $RUSTUP_HOME defaults to ~/.rustup If you’ve built Servo before yesterday, you probably have a .servo directory under your clone of the servo repository that’s taking up disk space with previous copies of Rust and Cargo. It can now be removed. Similarly, in the default config we used to override $CARGO_HOME (which contains a cache of crates.io and git dependencies) to .cargo under the repo. You also remove that, now we leave the environment’s $CARGO_HOME (which defaults to ~/.cargo). This cache is now shared with other clones of the repository, or with other projects that might use some of the same Rust dependencies. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Old builds on CI machines take up increasing disk space
On 04/01/18 22:31, Josh Bowman-Matthews wrote: I just encountered a try build failure which contained: ar: libjs_static.a: No space left on device I logged into the build machine and checked, and there were 5mb left out of the 61gb disk. After checking that the machine was idle, I cleared out 34gb worth of old builds from the target/ directories of the various builder directories. What can we do to avoid repeating this exercise in the future? One of the buildbot steps is steps.Git(…, method="fresh") which removes the target/ dir (and anything else not tracked by git) https://github.com/servo/saltfs/blob/master/buildbot/master/files/config/factories.py#L59 But this is a done at the *start* of a job. And it looks like the same machine can be used (not a the same time) for different kinds of jobs, each in a separate directories. That’s how we end up with multiple target/ dirs taking lots of space. We probably want to keep running this step at the start of jobs to get closer to a known state. But maybe we can *also* run it at the end, to free up space? I’m guessing this happened now and not before because we made a few try builds with cargo/rustc versions that enable incremental compilation by default, which takes a lot of space. Since we’re removing target/ for each build, we probably should disable it explicitly. The easiest place to do so is probably https://github.com/servo/saltfs/blob/master/buildbot/master/files/config/environments.py#L51 . By the way, it would be nice to have this file in servo/servo so we don’t need to do the highstate dance every time we change it. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Lots of warnings: the type of this value must be known in this context
On 23/12/17 20:54, Enrico Weigelt, metux IT consult via dev-servo wrote: I'm using a pretty fresh rustc I’ve responded in https://github.com/servo/servo/issues/19637. Please pick one of the mailing list or issue tracker for each topic, and avoid duplicating discussions. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] making features optional
On 21/12/17 20:12, google via dev-servo wrote:
Does it only compile those modules that are actually imported ?
In current Rust, the `mod` keyword is a module *declaration*. When used
without a {…} block, it makes the compiler read a corresponding .rs file.
`use` imports some names in the current scope.
https://doc.rust-lang.org/book/second-edition/ch07-00-modules.html
--
Simon Sapin
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] RFC: Require rustup.rs to build Servo with mach
In https://github.com/servo/servo/issues/11361 we’ve discussed using rustup.rs to bootstrap Rust and Cargo. With https://github.com/servo/servo/pull/19213 landing soon, I think the last blocker is resolved. One proposal has been to use rustup when available, and fall back to our existing mechanism when not. However I think rustup is well-established enough these days and I’d like to go further: make it a requirement and remove our code that duplicates rustup’s functionality: downloading and extracting tarballs, juggling toolchain versions, etc. mach would make sure to run cargo/rustc/etc. through rustup (https://github.com/rust-lang-nursery/rustup.rs/issues/1293), and set the $RUSTUP_TOOLCHAIN environment variable to select the appropriate toolchain version. Recent versions of rustup now download missing toolchains automatically. We’d document instructions for installing rustup in our README, and again an error message when mach cannot find a `rustup` executable. The `system-rust = true` configuration would remain available and run plain `cargo` or `rustc` like before. Thoughts? -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Enabling tests in web-platform-tests/css/
On 01/11/17 22:25, Josh Matthews wrote: In short, I think we should enable the new testsuite, remove the old tests and related CI jobs, and never look back! The ability to upstream reftests and share others' improvements will be a significant boon. Great news! Thanks for working on this. -- Simon ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Rust CI is now gated on compiling pinned commits of Stylo and WebRender
On 25/10/17 16:43, Josh Matthews wrote: This is great news! Is there any chance that the compilation time for these crates is tracked over time as well? That’s https://github.com/rust-lang-nursery/rustc-perf and http://perf.rust-lang.org/ , which has a separate list of crates. It already had the style crate (in gecko mode), but that had been broken for a while. I fixed it in https://github.com/rust-lang-nursery/rustc-perf/pull/162 There’s follow-up work to do to add a patch that applies cleanly to that updated version of style, in order to test incremental compilation time. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Rust CI is now gated on compiling pinned commits of Stylo and WebRender
As part of the tests that must succeed on CI before any pull request is merged, the https://github.com/rust-lang/rust/ repository has a src/tools/cargotest subdirectory that runs 'cargo test' in a given list of other git repositories. Each has a fixed commit that is known to work on stable Rust, so a Rust PR that breaks any of them is probably a compiler regression and will be blocked from landing. In https://github.com/rust-lang/rust/pull/44603 I’ve added to this list: * servo/webrender: all crates in the workspace * servo/servo: - The stylo_tests crate (which depends on the geckoservo crate) - The selectors crate (which has a few more unit tests) This does not (yet) include more of Servo, mostly because it must not involve unstable language or library features where breakage is expected. (I’ve also introduced a Servo compilation mode that uses unstable features less (sacrificing some optimizations) with the goal that the script crate can eventually be added to that list, but we’re not there yet. This is tracked at https://github.com/servo/servo/issues/5286.) In the future if Stylo or Webrender starts exercising different parts of the compiler (for example if they start making significant use of a new language feature) it maybe worth updating the commit hashes in https://github.com/rust-lang/rust/blob/master/src/tools/cargotest/main.rs -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Bootstrap is broken for old Servo versions. How much should we do about it?
On 18/10/2017 23:26, Simon Sapin wrote: Anyway, some of the affected commits have a rust-toolchain or rust-nightly-date file that contains a date. You can then run something like `rustup override set nightly-2017-10-13` to get that version and tell rustup to use it when under the current directory. Other commits however have a rust-commit-hash file, and there’s not necessarily a Nightly with that exact commit. Go to e.g. https://github.com/rust-lang/rust/commit/23de823e93dc19ef1b9cb65b48860a892cd6ff18 (or run `git show 23de823e93dc19ef1b9cb65b48860a892cd6ff18` in a local clone of the rust repo), look at the merge commit’s date, and try the next day’s nightly. (Nighties in rustup are indexed by date of publication, but are picked from the last merge before midnight, so on the previous day.) Commits after https://github.com/servo/servo/pull/18942 should bootstrap successfully "forever"[1] if "llvm-assertions = true" is configured in the [build] section of .servobuild. (The default is false, which uses "alternate" rustc builds which are not yet available officially.) [1] As long as corresponding Nightly builds are available on static.rust-lang.org, which is the location that the Rust infra team considers "stable and public". -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] RFC: Require Python 2.7.9+ (for TLS Server Name Indication)
On 19/10/2017 17:40, Gregory Szorc wrote: CERTIFICATE_VERIFY_FAILED likely means there is no trust chain on the client for the server x509 certificate. My guess is the Amazon root CA isn't in the trusted root CA certificates list on that Windows builder. You can verify this by temporarily disabling x509 certificate trust checking via ssl.wrap_socket(cert_reqs=ssl.VERIFY_NONE) (<2.7.9) or ssl.SSLContext.verify_mode = ssl.VERIFY_NONE. I know Firefox CI has had problems related to the Amazon root CA not being installed because it is a relatively recent root CA. The generic Python way to fix this is to use the certifi Python package and load it by specifying ca_file to ssl.wrap_socket() (pre 2.7.9) or ssl.SSLContext.load_verify_locations() with 2.7.9+. Or figure out where Python thinks the default CA certificate list is (ssl.get_default_verify_paths()) and ensure a modern root CA bundle is in that location. Although on Windows and MacOS, support for loading certs from the system varies. Read the code comments at https://www.mercurial-scm.org/repo/hg/file/aa5e7b4a3a01/mercurial/sslutil.py#l693. Also note the hack on MacOS's Python where loading a specially crafted CA file has the side-effect of importing CA certs from the MacOS Keychain. Talk about an esoteric hack! Thanks, with this advice I’ve managed to land https://github.com/servo/servo/pull/18942 However the cafile parameter of urllib2.urlopen() is new in 2.7.9 and I don’t know how to feature-test that without making a call and catching some exceptions, but that seems fragile. We’re not using the ssl module directly. So now, `if HAS_SNI and sys.version_info >= (2, 7, 9)`, we use the CloudFront hostname with root CAs from the certifi package. Otherwise we use the unofficial S3 hostname. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] RFC: Require Python 2.7.9+ (for TLS Server Name Indication)
On 18/10/2017 22:37, Gregory Szorc wrote: The latter merely requires an up-to-date trusted CA certificate roots bundle for x509 certificate verification (assuming the client does certificate validation properly - which older versions of Python don't unless configured to do so - Python's default security story was a mess until relatively recently). On Windows builders for Servo’s buildbot CI we have Python v2.7.12:d33e0cf91556 with ssl.HAS_SNI == True. Connecting to https://static-rust-lang-org.s3.amazonaws.com/ works fine, but connecting to https://static.rust-lang.org/ (a CloudFront hostname) causes: URLError: verify failed (_ssl.c:590)> On https://www.ssllabs.com/ssltest/analyze.html?d=static.rust-lang.org&s=54.192.142.81&latest (picking one the first IP address listed), everything in "certification path" is either "sent by server" or "in trust store". Gregory, do you have an idea what could be wrong here? -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Bootstrap is broken for old Servo versions. How much should we do about it?
On 18/10/2017 22:35, Josh Matthews wrote: I have used git bisect fewer than 5 times in the past year. I think the absolutely minimum we should do is provide clear instructions for how to obtain missing versions and make the Servo build system use them; it would be nice if that didn't involve building rustc from source. If breaking the boostrap of old commits were a proposed change I’d be all for blocking it on having such instructions. But it has already happened: many files that used to be under https://s3.amazonaws.com/rust-lang-ci/ are gone. Anyway, some of the affected commits have a rust-toolchain or rust-nightly-date file that contains a date. You can then run something like `rustup override set nightly-2017-10-13` to get that version and tell rustup to use it when under the current directory. Other commits however have a rust-commit-hash file, and there’s not necessarily a Nightly with that exact commit. Go to e.g. https://github.com/rust-lang/rust/commit/23de823e93dc19ef1b9cb65b48860a892cd6ff18 (or run `git show 23de823e93dc19ef1b9cb65b48860a892cd6ff18` in a local clone of the rust repo), look at the merge commit’s date, and try the next day’s nightly. (Nighties in rustup are indexed by date of publication, but are picked from the last merge before midnight, so on the previous day.) -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] RFC: Require Python 2.7.9+ (for TLS Server Name Indication)
On 18/10/2017 22:37, Gregory Szorc wrote: On Wed, Oct 18, 2017 at 10:01 PM, Simon Sapin wrote: try: from ssl import HAS_SNI except ImportError: HAS_SNI = False […] https://static-rust-lang-org.s3.amazonaws.com/ is what we use at the moment. I’ve updated https://github.com/servo/servo/pull/18942 to use https://static.rust-lang.org/ when ssl.HAS_SNI exists and is true, and https://static-rust-lang-org.s3.amazonaws.com/ otherwise. I'd set up your own S3 bucket and potentially CloudFront distribution so you are in control of your own hostnames. That’s certainly one option, yes. Though we’re also considering using rustup.rs, so “install rustup any way you can” could be a way to bootstrap, instead of downloading rustc from Python. an up-to-date trusted CA certificate roots bundle for x509 certificate verification (assuming the client does certificate validation properly - which older versions of Python don't unless configured to do so - Python's default security story was a mess until relatively recently). That sounds like a whole other can of worms that I don’t really want to get into today :/ -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] RFC: Require Python 2.7.9+ (for TLS Server Name Indication)
On 18/10/2017 21:09, Gregory Szorc wrote: Having somewhat recently overhauled Mercurial’s TLS code, I can tell you that Python installs without the ssl module additions added in 2.7.9 are still quite common in the wild. I suspect that requiring SNI support in the Python client will draw ire from a significant population. Also, there are versions of Python <2.7.9 that have the ssl module improvements backported. For example, RHEL/CentOS 7 ship a Python 2.7.5 that has all the ssl goodies from 2.7.9. Good to know, thanks. So please look for presence of attributes on the ssl module instead of version sniffing. Something like this? try: from ssl import HAS_SNI except ImportError: HAS_SNI = False If I were in your shoes, I would provide a hostname without SNI as a fallback. (I’m assuming you aren’t willing to do non-SNI CDN for cost reasons - last I looked this was somewhat costly.) I.e. the script would attempt to use CDN+SNI and fall back to a single homed service if the client lacks modern crypto. Part of the issue here is that we (the Servo team) are not the ones providing the hostname. The Rust team recently declared everything other than static.rust-lang.org (the one that requires SNI) to be “considered private and unstable — use at your own risk”. https://internals.rust-lang.org/t/public-stable-rust-services/6072 And it’s not just a matter of updated our scripts when the server setup changes, I’d like old git commits to keep working. (To the extend reasonably possible.) Assuming you are using CloudFront backed by S3, the fallback could be the generic per-region S3 hostname. This is how we handle “clone bundle” hosting for hg.mozilla.org. It is definitely S3, and I believe it is CloudFront. And yes, https://static-rust-lang-org.s3.amazonaws.com/ is what we use at the moment. I’ll discuss with the Rust team to see if they’re willing to commit to supporting some non-SNI hostname. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Self-hosting online resources used by Servo’ build system
Servo’s build system currently download things from under https://s3.amazonaws.com/rust-lang-ci/ Rust’s infrastructure team, who manages this S3 bucket, says we shouldn’t rely on it: https://internals.rust-lang.org/t/public-stable-rust-services/6072 Once https://github.com/servo/servo/pull/18942 lands, there will be two remaining things we download from there: * openssl-1.0.2k.tar.gz, when building for Android. Maybe we should package that into crates.io with a build script. This might also help with https://github.com/servo/servo/issues/18343 * "Alternate" builds of rustc, that have LLVM assertions disabled. These compile 20~50% faster than official Nightly builds. We’re working one making this officially available on static.rlo (https://github.com/rust-lang/rust/issues/45334) and with rustup (https://github.com/rust-lang-nursery/rustup.rs/issues/1099) In the meantime, we might still want to move off of 'rust-lang-ci' so something we (the Servo team) control. Maybe the 'servo-rust' AWS S3 bucket that we’ve used until November 2015 to download custom Rust builds. (Before official Nightly supported cross-compilation to Android, IIRC.) Every time we update the compiler version, we’d need to copy some files from 'rust-lang-ci' to 'servo-rust'. I assume we don’t want to distribute AWS keys to too many people, so maybe there could be a dedicated repository where Travis-CI is configured to do that copy when we merge a new Nightly date. Or something like that. Thoughts? -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Bootstrap is broken for old Servo versions. How much should we do about it?
We generally try to make it so that old revisions of Servo keep working, so that we can for example use 'git bisect'. We just found out that, unfortunately, bootstrapping is broken for all Servo revisions since 2015-11-07, or (for more recent revisions) will be soon. In the default config, these revisions automatically downloads some combination of rustc, std, and/or cargo from the 'rust-lang-ci' AWS S3 bucket. This contains the output of Rust’s CI for every merged PR, and is managed by Rust’s infrastructure team. They have recently announced a policy of removing files more than 90 days old: https://internals.rust-lang.org/t/updates-on-rusts-ci-uploads/6062 They have further clarified that only resources under https://static.rust-lang.org/ are considered stable and public, everything else could go away at any time: https://internals.rust-lang.org/t/public-stable-rust-services/6072 We can move to static.rust-lang.org as much as possible (I’ll start another thread with the details), but that leaves older commits of the servo/servo repository. Rewriting the git history (to bootstrap from different URLs) would be very disruptive, I strongly think we should not. The relevant range of Servo commits depends on a few dozens of Rust version, much fewer than every merged Rust PR in that time. We could ask the Rust team if they’re willing to add exceptions to their deletion policy to preserve these specific versions. However some of these files are already gone, we’d have to recompile them from source. But more importantly, how much should we really care about all this? How often have you used 'git bisect' in servo/servo, let’s say in the past year? How much effort should we put into all this, compared to the effort of manually finding and configuring working Rust and Cargo versions if we ever need to build an old Servo version? -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] RFC: Require Python 2.7.9+ (for TLS Server Name Indication)
Servo downloads appropriate versions of Rust and Cargo using Python’s urllib2. At some point, https://static.rust-lang.org started requiring TLS SNI (I think when it moved to a CDN?) and we had issues with downloads failing on CI or on contributor’s machines because of old Python versions. So we moved to using https://static-rust-lang-org.s3.amazonaws.com instead, which does not require SNI. However, that URL is not considered stable: https://internals.rust-lang.org/t/public-stable-rust-services/6072 I don’t expect it’ll go away any time soon, but we should still consider not relying on it. I propose that we move back to using https://static.rust-lang.org, and document that Python 2.7.9 or more recent is required, and print a warning when and older version is used. Support for SNI was added in 2.7.9, which was released in December 2014. Debian has had a recent enough default version since Debian 8.0 Jessie released in April 2015, and Ubuntu since Vivid Vervet 15.04 released in April 2015. Travis-CI still uses Ubuntu 14.04 LTS, but using 'language: python' in .travis.yml gives an environment with a recent enough Python version. Thoughts ? -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] No disk IO?
On 10/10/2017 10:34, Paul Rouget wrote: Does it make sense to make it so that Servo does do any disk IO and delegate everything to the embedder? For example, on Android, reading the resources file is hacky because we have to copy the files at startup to the sdcard. Not because we can't have resources files in the apk, but because servo needs a full path, when android provides streams. To solve the resources issue on Android, we could just expose a specific API to read the resource files, but if we agree that Servo should not do any disk IO itself, we would go for a more generic approach. Embedding the resource files in the binary as discussed in https://github.com/servo/servo/issues/15635#issuecomment-298699103 should solve this, right? Is there more disk I/O other than that and navigating to a file:// URL? (By the way, to do we disallow access to file: from http: and other URL schemes?) -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Memory reporting in Servo: the next step
On 06/10/2017 06:05, Nicholas Nethercote wrote: If we went with the second option from my original mail (i.e. stop using heapsize) then it would probably make sense to deprecate heapsize entirely, stop those crates from depending on it, and implement the MallocSizeOf trait for those crates' types within Servo. I’m in favor of this. It does create a contention point in the dependency graph (malloc_size_of depends on many crates, and many other crates depend on malloc_size_of). But the current heapsize situation (crates in many repositories depend on heapsize) is also a pain whenever we want to make breaking changes to heapsize. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Test cases for (incremental) compile times (PSA: disable incremental compilation for now)
On 04/10/2017 13:44, Nicholas Matsakis wrote:
- Configure servo to use "system rust" and to enable incremental
By the way, with a few recent patches you can now skip mach entirely and
run `cargo build -p servo` or `(cd ports/servo && cargo build)`.
(The latter allows using -p with some other crate, otherwise the wrong
set of cargo features might be selected because of
https://github.com/rust-lang/cargo/issues/4463.)
FWIW, my "5x slower" figure was building the script crate ("mach build -p
script" where the dependencies are already compiled) soon after upgrading
rustc (so possibly with no relevant incremental cache entries) to
1.22.0-nightly (c6884b12d 2017-09-30).
5x slower than what?
Slower than the same with incremental disabled. Seven and a half minutes
(incremental = true) vs one and a half (incremental = false), on a fast CPU.
--
Simon Sapin
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Test cases for (incremental) compile times (PSA: disable incremental compilation for now)
On 03/10/2017 21:51, Nicholas Matsakis wrote:
That said, the measurements I just did today still showed big wins
(~3x), at least for the sample changes that I've been making (adding
new methods, changing method bodies in style). So it may be worth
testing.
This 3x is what compared to what?
FWIW, my "5x slower" figure was building the script crate ("mach build
-p script" where the dependencies are already compiled) soon after
upgrading rustc (so possibly with no relevant incremental cache entries)
to 1.22.0-nightly (c6884b12d 2017-09-30).
Let me use this opportunity to ask a question:
I'd love to get some help coming up with representative changes, or at
least determine what to measure. I was thinking of trying to stand up
automated measurements of the following:
- "Servo dev happiness index"
- Time to build HEAD on servo incrementally, if HEAD^ is already compiled
- Perhaps divided by the `+/-` on the diff, LOC, or something.
- This will be a crazy noisy measurement, but if we look at
medians over time, it can give us some sense of how servo build times
are evolving.
- "Stable, representative diffs"
- Time to build stylo (baseline) and then with various
"representative" diffs:
- Editing interior of a method
- Renaming something
- Adding new field
- etc
The latter measurement would focus on stylo because it builds on
stable Rust, and hence we can have some reasonable confidence that it
will keep building on all nighties. Prior attempts tried to build the
script crate, but the version I was testing stopped building on
nightly builds, and I found it hard to port the diffs to the latest
HEAD.
I'd appreciate some help in setting those up!
I can help look into all this with you.
Previously, my benchmark for incremental has been building once, using
"touch" to change the timestamp of some source file (but not change any
contents) and rebuild. It’s not representative of any real workflow, but
so far the results had not been absurdly different from making a read
code change. Maybe the red/green system will change that?
A real change that could occur during debugging and that’s easy to
reproduce at any base commit is adding println!("{:#?}", some_variable)
at a random place in the code.
--
Simon Sapin
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] PSA: disable incremental compilation for now
At the moment, Servo does not use incremental compilation by default. You can enable it by copying servobuild.example to .servobuild in your clone of the repository and setting "incremental = true" in the [build] section. If you’ve done this, **you probably want to reverse it** for a while. Incremental compilation in rustc is being rewritten and there are large compiler performance regression when it’s enabled. These are visible as the big increases on http://perf.rust-lang.org/ We’ve updated Servo two days ago to use a Rust Nightly version with these regressions. I’ve measured component/script take ~5x as long to compile as with incremental disabled. I hear that these regressions should be fixed in the next few weeks as the rewrite settles down in the compiler, and hopefully the new approach can eventually give significantly better perf than before. This talk by Niko explains the new query-based approach for compiler internals: https://skillsmatter.com/skillscasts/10868-inside-the-rust-compiler -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] [stylo-team] Mozilla central backout support arriving to Servo later this week
On 19/06/2017 20:48, Lars Bergstrom wrote: tldr: If you see some PRs from the moz-servo-sync GitHub user with a priority of "treeclosed," it's because those must be landed into Servo ASAP to support Firefox backouts. Where do we file bugs on this tool? It creates a new PR that mentions the number of the PR being reverted, which is good. It should also comment on *that* PR to let the people involved that they’ll have something to fix and they’ll need to try to land this again. We don’t want improvements being forgotten after being backed out. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] What would it take to make Servo a replacement for ChromeOS?
On 18/06/2017 22:04, Jose Marinez via dev-servo wrote: So yes, there’s Redox as an alt-os in Rust and it’s quite early for to start thinking this way, but perhaps not. A Servo based OS would have many benefits. A browser engine based OS is where we should’ve been in 1994 if we had more CS people aware of the true nature and goals of the (I)nternet as imagined in the 60s and 70s. With WebAssembly and competing technologies at its core, ServoOS can come closer to a decentralized and scalable platform for all to share, use and express on. Again, from a technical perspective, what would this take to extend Servo to a full OS? Thanks Hi, You may have heard of Firefox OS, also known as Boot to Gecko (B2G). It’s a lot like an hypothetical ServoOS in its core idea: “The Web is the platform.” Its components are split into three layers: * Gonk is roughly half of Android: the kernel, device drivers, the low-level rendering pipeline, etc. But not the Java VM, for example. * Gecko, Firefox’s rendering engine. In the case of Firefox OS, running directly on top of Gonk without the rest of a traditional operating system. * Gaia, the user interface (home screen, status bar, base apps) written in JavaScript/HTML/CSS and running on top of Gecko. All apps/websites also run on Gecko. Back in Servo land, a couple years ago we had an experiment called Boot to Servo (B2S): make Servo run on top of Gonk, with the goal of eventually being able to run Gaia and make Servo an alternative engine for Firefox OS. We got a prototype working on real hardware: https://blog.servo.org/2015/02/10/twis-23/#screenshots Last year, we removed the Gonk port from the Servo tree after Mozilla effectively abandoned Firefox OS. More background: https://medium.com/@bfrancis/the-story-of-firefox-os-cb5bf796e8fb -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Fwd: Incremental compilation and other compile time tricks
`mach cargo check` is worth listing in Servo's README.md, IMO! https://github.com/servo/servo/pull/16854 adds `mach check` and `mach check-geckolib`, and mentions the former in README. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Incremental compilation and other compile time tricks
On 31/03/17 19:43, Simon Sapin wrote: # cargo check Remember how I said a crate needs its dependencies to be compiled before it can start compiling? It actually only needs metadata (the results of the analysis phase), not the generated code. Cargo added a `cargo check` command that skips code generation entirely (except for build scripts and build-dependencies). This saves a lot of time (I’ve measured up to 5× speed from `./mach clean`), though obviously you don’t get an executable at the end. Still, it can help for example during a refactoring: run `./mach cargo check` many times until compiler error are resolved, and only then run `./mach build` and/or `./mach test-unit`. https://github.com/rust-lang/cargo/pull/3296 https://github.com/servo/servo/pull/14594 With a couple pull requests that just landed, "./mach cargo-geckolib check" now also works. On a fast desktop it runs in 28 seconds after "cargo clean" and 19 seconds after "touch components/style/lib.rs". -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Incremental compilation and other compile time tricks
On 31/03/17 20:25, Keith Yeung wrote: If this becomes an occasional problem, can we simply just connect to the CI build machines and run `./mach clean`? That should remove all the files that broke CI. I think reverting should be considered when it really does become a very frequent problem. Agreed. I mentioned reverting because we got feedback that Firefox compiles from scratch to avoid such issues, which I assume at some point were pervasive enough to be a pain. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Incremental compilation and other compile time tricks
will consider reverting this change it this turns out to be a problem. https://github.com/servo/saltfs/pull/611 # Incremental compilation Finally, the compiler feature everyone is waiting for. In the current default configuration, entire crates are recompiled from scratch whenever the smallest part of their source or dependencies is touched. Incremental compilation changes this, caching many intermediate results so that the next build hopefully doesn’t need to do that work again. Incremental compilation in Rust Nightly is currently in "beta". It mostly works (I’ve been using it exclusively for a couple months) but it’s buggy on some platforms and the speedups are not as good as one might hope. (Only code generation is cached, at the moment.) It also uses a lot of disk space and memory. The `target` directory in one of my trees takes 26 GB. (I don’t know if there’s any cache eviction, so running `cargo clean` occasionally may be needed.) One of our CI builders with "only" 8 GB of RAM and no swap is unable to build the script crate with incremental compilation enabled. So far we have *not* enabled incremental compilation by default in Servo. Still, you can try it by copying servobuild.example to .servobuild, then editing the latter to change `incremental = false` to `incremental = true` in the [build] section. Please send us any feedback! https://blog.rust-lang.org/2016/09/08/incremental.html https://internals.rust-lang.org/t/incremental-compilation-beta/4721 https://github.com/servo/servo/pull/15390 https://github.com/servo/servo/pull/15565 -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Please avoid @-mentioning people in commit or PR messages
On 01/03/17 18:38, Manish Goregaokar wrote: FWIW gps planned to strip @mentions in the autosync service, so most of the pain here could go away. Even only within servo/servo @-mentions in PR messages or commit messages still cause more email than necessary. So please keep them to separate PR comments anyway :) -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Please avoid @-mentioning people in commit or PR messages
On 01/03/17 16:32, Nicholas Matsakis wrote: Something I learned the hard way is to avoid a sentence like this one: "Does not fix #123." Github will dutifully detect "fix #123" and close the corresponding issue. =) On Wed, Mar 1, 2017 at 10:21 AM, Alan Jeffrey wrote: The other thing I learned the hard way is not to #N-mention any issues that aren't to be closed when then PR is merged. The full list of keywords is at https://help.github.com/articles/closing-issues-via-commit-messages/ I don’t know of a problem with referring to issue numbers without these keywords. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Please avoid @-mentioning people in commit or PR messages
The first message of a pull request is copied into the merge commit when bors/homu merges it. When a commit with an @-mention in the message is pushed to any branch, GitHub sends an email notification to that person (unless they have disabled email notifications). Servo commits tend to be pushed multiple times: first in a PR’s branch, then to master in servo/servo, then replicated into mozilla/gecko-dev, and sometimes also replicated in other Mozilla repositories. This causes as many unnecessary emails to be sent. So if you want to attract someone’s attention, including to ask for review, please do so in a subsequent comment on a pull request, not in a commit message or initial pull request message. Thanks! -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Proposal: move the source code for rust-selectors into servo/servo
On 11/02/17 01:09, Bobby Holley wrote: Simon took the "big sign" approach, which seems fine to me: https://github.com/servo/rust-selectors Yes, as mentioned in another part of this thread: I’ve pushed a new branch to https://github.com/servo/rust-selectors and made it the default. It only has a readme file that says the source is now at https://github.com/servo/servo/tree/master/components/selectors. The master branch and issue / PR tracker are still there if we need them. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Proposal: move the source code for rust-selectors into servo/servo
On 08/02/17 22:31, Jack Moffitt wrote: Let's allow until Friday afternoon for feedback to come in, but I don't think it makes sense to delay this decision. I approved https://github.com/servo/servo/pull/15447 and it has already landed. Oh well. I’ve pushed a new branch to https://github.com/servo/rust-selectors and made it the default. It only has a readme file that says the source is now at https://github.com/servo/servo/tree/master/components/selectors. The master branch and issue / PR tracker is still there if we need it. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Proposal: move the source code for rust-selectors into servo/servo
On 08/02/17 19:42, Bobby Holley wrote: Won't they need to do this anyway? At least assuming we accept your proposal below that: "Whenever a PR to rust-selectors (and other repositories where we think that’s appropriate) makes breaking changes, we don’t land it until there’s also a corresponding PR to update Servo for these changes." No. If a contributor makes a change that is breaking, I or someone else on the Servo team would take care of updating Servo for them. We have two years of historical data. That does not predict the future, it's at least some indication of the volume we might expect in the near term. I agree with your cost / benefit analysis. But as I mentioned before, my reluctance is also based on principle. But please consider that it causes me (and some others) a lot of pain. I believe you, but to be honest I don’t understand. (To me, contributing to Gecko also requires jumping through a number of (different) hoops.) I’m inclined to concede, but I’d like to hear from other people before hitting the button. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Proposal: move the source code for rust-selectors into servo/servo
It’s a trade-off. It’s true that historically we’ve been more eager than necessary to put every crate going to crates.io in its own repository. (See for example github.com/servo/webrender_traits, since then merged into webrender.) I understand that juggling multiple repositories makes things complicated for Servo contributors. But I think that it’s not too terrible once you figure out the workflow, and that we can improve it both with tooling (in Cargo replacements/overrides support) and in our own habits/conventions. On the other hand, keeping / moving back a library in servo/servo that is used outside makes life more difficult for contributors since they need to clone/checkout a much larger repository, CI takes much longer, is more prone to unrelated intermittent failures, and the CI queue can be more busy. (Though this has gotten better now that we don’t need anymore to retry more often than not because of intermittent.) On 07/02/17 22:47, Bobby Holley wrote: rust-selectors was split out into a separate crate and repository in 2015. Since then, there has been one push (with 2 commits) by a contributor that does not also contribute to servo But we don’t know how many people will want to contribute in the future, and how many would be discouraged if it’s in servo/servo. I also think that even if the direct benefits in this particular case are small, doing this is part of being a "good citizen" in the Rust ecosystem. But now I'm ready to land these changes, and things get tricky. The latest version of rust-selectors is several breaking versions ahead of the one used by servo, so now I need to either do these updates for code changes I'm not familiar with, or block my patch indefinitely until someone else does it: I can't make progress until that "lock" is released. In this case, servo/rust-selectors had two breaking changes ahead of Servo: * One added variants to a public enum. Since Servo doesn’t match values of that enum, no change at all was required. * The other changed a parameter in a method of a public trait from Foo to &Foo. The fix was to add & in a few places in Servo. But yes, you couldn’t know how much effort this update would take until you tried it. You could have asked, though. We have people in multiple time zones who could help with this, some of whom reviewed the relevant changes. The reason the update was not in Servo yet was that I wanted to land it with tests that are not written yet. It is landed now (with an open issue for the tests). Thanks to Nox and KiChjang for doing it while I was sleeping. So here is a proposal to avoid this situation in the future: Whenever a PR to rust-selectors (and other repositories where we think that’s appropriate) makes breaking changes, we don’t land it until there’s also a corresponding PR to update Servo for these changes. What do you think? And then I still want to run my combined (servo+rust-selectors) changes through servo try before landing and publishing the rust-selectors change, which means that I need to go push a special branch, You’ll need a branch anyway to make a PR. and fuss with with the cargo manifests to reference the temporary branch, and then push that to servo/servo, and then trigger a try push, I think we can and should improve tooling here. One command to add a replacement/override, one command to start a try build. [...] and then publish to crates.io, [...] I think we should make Travis-CI publish to crates.io when we merge a version number change to master. -- 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?
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] CSSOM ownership woes
On 11/11/16 12:22, Manish Goregaokar wrote: Servo currently has a style tree (stylesheets->rulelist->rules->other rules and rule lists) in style::Stylesheet[1], and this is shared with the DOM via Arcs. As I understand it, Gecko, on the other hand, just uses the CSSOM DOM tree and has no "style tree" otherwise. Reading rules in Gecko requires traversing through CSSOM objects. This is a straightforward solution to the same-object restriction; if your style tree is made up of these objects in the first place there's nothing to worry about. Servo can't use this solution. Trying to thread style through the DOM will mean merging the style and script crates, and it will be quite complicated to make Servo's style system generic over CSSOM implementations for stylo to work. I’ve proposed this approach before, and I don’t think it would be that complicated. The only parts of components/style that access this tree (other than the parsing part creating it) is Stylist::update and Stylist::set_device taking &[Arc] and traversing the tree. I’m sure we can reasonably define a trait to abstract this traversal. The "leaves" of this tree (selector list, declaration block, …) would stay in style crate, but the tree structure and the ownership/mutability story doesn’t need to be handled there. Bobby argued that we should keep that tree in the style crate because it can implement some operations that won’t have to be re-implemented in both Servo and Gecko/Stylo. But I don’t know if there is much to share anyway, and the alternative (maintaining parallel trees) also has its complexity. A possible solution is to have a opaquish DOM backpointer to corresponding rule objects in the style tree and have it call some update function to update the DOM when mutating. This isn't a great solution IMO. The one that we seem to prefer is maintaining the style tree and the CSSOM tree in parallel, with references from the CSSOM tree to the style tree, but not vice versa. Only the DOM mutates the style tree. Yes, in my mind that was always the plan, as discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=1281962. Have a tree in style without parent pointers or pointers back to DOM, and a parallel CSSOM tree where each JS object holds an Arc to the corresponding style object (and a parent pointer as needed), with DOM operations taking care of keeping them in sync. This could possible be enforced by wrapping all interior mutability in the style tree with a type that requires a zero-sized token to be passed in to the borrow_mut/write method; a token which can't be created normally but can be obtained via a method on dom::Reflectable (within arms reach for most DOM code). Stylo code can FFI call into functions using a similar mechanism. I don’t think enforcing this is important. As mentioned above the part of the style crate accessing this tree is small, so I don’t think it likely that it will accidentally mutate it. And I, as far as I know, the worst that can happen if they do get out of sync is incorrect styling or results from CSSOM, but nothing like a memory safety issue. In the case of CSSRuleList, we have a bit of an issue. There's no corresponding arc'd style:: type for CSSRuleList. There's just `Vec`, which is used in Stylesheet[1], MediaRule[2], and @supports rules (not supported in servo yet). There isn’t yet (in master) but as you did in #14190 the idea is to introduce Arc’s (and RwLock’s) as needed. (That is, unless we get rid of this style tree.) -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] .getBoundingClientRect() or lightweight alternative?
On 12/11/16 17:49, Emilio Cobos Álvarez wrote: I think most developers affected by this would be somewhat happy with width and height just for textual elements. They also might like some exposure of the actual selected font so that font table information can be used in layout. There is a proposed Font Metrics API that does this: https://drafts.css-houdini.org/font-metrics-api/ It is still in early exploratory stages. Please send feedback on this API as indicated near the top of the draft. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] string-cache (string interning) is now generic
On 03/11/16 21:02, Boris Zbarsky wrote: On 11/3/16 3:17 PM, Simon Sapin wrote: An important aspect is that atoms with different static sets are different Rust types. Just to check that I understand correctly... Are element names atoms? Which static set do they come from? Presumably the html5ever one? Yes. Previously Servo had a single Atom type that was used, among other things, for element names. Now there is html5ever_atoms::LocalName (which is a type alias for string_cache::Atom), used for element and content attribute names. When parsing CSS selectors, are tag name selectors atomized? Which static set is used for that? Yes. Types from the selectors crate are generic, with a trait that has associated types for the string types of various components. Servo defines: type AttrValue = std::string::String; type Identifier = servo_atoms::Atom; type ClassName = servo_atoms::Atom; type LocalName = html5ever_atoms::LocalName; type NamespacePrefix = html5ever_atoms::Prefix; Stylo defines: type AttrValue = gecko_string_cache::Atom; type Identifier = gecko_string_cache::Atom; type ClassName = gecko_string_cache::Atom; type LocalName = gecko_string_cache::Atom; type NamespacePrefix = gecko_string_cache::Atom; gecko_string_cache::Atom wraps *mut nsIAtom. (I don’t know if there’s a reason for the discrepancy: interning attribute values in selectors in Stylo but not Servo. We can change it.) -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] string-cache (string interning) is now generic
Stylo Stylo is not affected by any of this. When built for stylo, the Prefix and LocalName types used in selectors are conditionally-complied re-exports of gecko_string_cache::Atom, which is unchanged. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Moving style out of tree as an alternative to frankenbuild?
On 25/08/16 20:55, Manish Goregaokar wrote: I suspect they won't be too bad, and once stylo settles down a bit there won't be many breaking changes. I believe this is not at all the case. We gave up a long time ago on reducing the API surface of the style crate (what’s visible from other crates) and made everything public. There is zero separation between public API and implementation details. My experience is that, because of that, most changes to style are breaking changes that require some other crate (typically script or/and layout) to be updated as well. The problem with breaking changes is that once that more than one of them lands upstream, their order is linearized. For example, we recently published versions 0.9.0, then 0.10.0, then 0.11.0 of the 'selectors' crate within a few days. There was a PR to update Servo to 0.10.0, but we’ve had to wait until it was reviewed and merged (which took days with the usual CI bots babysitting because of intermittent failures) before we could take advantage in servo of the features introduced in 0.11.0. Sorry this message is all negative without proposing an alternative, but I’m very wary of this proposal. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Moving style out of tree as an alternative to frankenbuild?
On 25/08/16 20:55, Manish Goregaokar wrote: I suspect they won't be too bad, and once stylo settles down a bit there won't be many breaking changes. I believe this is not at all the case. We gave up a long time ago on reducing the API surface of the style crate (what’s visible from other crates) and made everything public. There is zero separation between public API and implementation details. My experience is that, because of that, most changes to style are breaking changes that require some other crate (typically script or/and layout) to be updated as well. The problem with breaking changes is that once that more than one of them lands upstream, their order is linearized. For example, we recently published versions 0.9.0, then 0.10.0, then 0.11.0 of the 'selectors' crate within a few days. There was a PR to update Servo to 0.10.0, but we’ve had to wait until it was reviewed and merged (which took days with the usual CI bots babysitting because of intermittent failures) before we could take advantage in servo of the features introduced in 0.11.0. Sorry this message is all negative without proposing an alternative, but I’m very wary of this proposal. -- Simon Sapin -- You received this message because you are subscribed to the Google Groups "stylo-team" group. To unsubscribe from this group and stop receiving emails from it, send an email to stylo-team+unsubscr...@mozilla.com. To post to this group, send email to stylo-t...@mozilla.com. To view this discussion on the web visit https://groups.google.com/a/mozilla.com/d/msgid/stylo-team/0e8bc74d-dfdc-bb9d-e657-61ffda9f194f%40mozilla.com. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] The size of the tests/ directory
On 24/08/16 20:04, Jim Blandy wrote: Are any of these reductions things that could be contributed upstream? If Mozilla's work could help the CSS WG test suite's other users, that would be pretty great. In short: yes. As I understand, the current build system is designed so that the build output for one specification in one format can be used independently from the rest. That’s why things are duplicated. We can contribute a "build everything to be used together" opt-in flag/mode that would undo tests v.s. support files duplication, and a "I only care about HTML (not XHTML)" one. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] The size of the tests/ directory
On 24/08/16 18:37, Simon Sapin wrote: Some files (some of them relatively large, like reference/support/big-buck-bunny-240p.webm) are also duplicated across multiple specs. Looks like even within on spec, /support and /reference/support have some duplication. We should merge those too. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] The size of the tests/ directory
On 24/08/16 18:12, Lars Bergstrom wrote:
Currently, the GitHub Servo repository has 134,062 files... 131,477 of
which are in the tests/ directory. Of those, 102,871 are in the CSS WG
tests. I know it's not a perfect measure, but that's also 862megs of
the 1.132gb of disk space usage reported by `du` on macOS for a Servo
checkout.
So, I'd like to have a discussion to see if there's something we can
do here to reduce the number of files. There are two reasons this has
come up:
- If we do end up "copying" the Servo GitHub repository into the
Mozilla monorepo, unfortunately mercurial cannot scale to that number
of files (though there is work going on at Facebook to make it able to
do so in the next year or two). Plus, the non-CSS WG tests in the WPT
directory are duplicate with those already in m-c.
- That's a lot of disk space, and might not be needed for new
contributors who working on anything other than layout features.
There are a few options I can see here (apart from "do nothing"):
1) Reduce the duplication in the CSS WG tests. A lot of it is due to
the build system. How small could we get it? Similar to WPT (i.e., 10x
fewer files)?
2) Break out the CSS WG and WPT tests into a separate location, to be
downloaded as-needed. If we do this, though, what is the workflow for
adding, deleting, or correcting a test? And is it still just as easy
to run a single test? Jamming it in a crate will leave it in a wonky
directory (e.g., target/debug/build/csswg-7062634bbf237306/output)
that is not exactly awesome for viewing & running tests from.
Any opinions or other ideas here?
Currently almost everything in tests/wpt/css-tests (that is, the build
output CSSWG’s test repository) is duplicated three times in
$spec-short-name/{html,xhtml1,xhtml1print} directory.
We can probably hack the build system to not generate xhtml1 and
xhtml1print directories at all, since we don’t use them.
Some files (some of them relatively large, like
reference/support/big-buck-bunny-240p.webm) are also duplicated across
multiple specs. Again by hacking the build script I think we can have a
single "support" directory shared across specs, with a step that checks
that files with colliding names have identical content. (If that’s not
always the case, we’d have rename some files in the source and update
tests that use them.)
With this, I expect we can reduce the number of files by 3x and the size
in bytes more than that.
--
Simon Sapin
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Github CI checks are expected to pass
On 18/07/16 15:43, Josh Matthews wrote: Hi folks! We turned off Appveyor builds about 1.5 months ago because they were constantly failing while building SpiderMonkey, and we just had a few days where the TravisCI builds were permafailing unexpectedly. I am pleased to report that we have re-enabled Appveyor, and the TravisCI failures have been fixed. Please treat any CI failures observed in PRs as blocking the merge once again! Do we need to wait for the green tick on the PR before r+’ing, or does bors/homu also run the same checks? -- Simon ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] How to efficiently react to an element changing visibility status from DOM code?
On 17/06/16 13:01, Josh Matthews wrote: While listening to the Gecko platform talk about shutting down video decoders for offscreen elements, I wondered about how we could do the same in Servo. We obviously don't support decoding video yet, but what would be an efficient way of doing that in the future? I think there are two parts to this: * Whether a Servo tab is visible at all (the window could be showing another tab, or be minimized, in another workspace, behind another opaque window, ...) * Whether a given element intersects the visual viewport. I believe WebRender tracks the latter to skip painting such elements. Maybe it could add a way to query that information? Or maybe display lists already carry that information, without going to webrender? -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Problems fetching crates while building servo-glutin.
On 02/06/16 10:31, sow...@gmail.com wrote: crate.io does show that wayland-client crate is available. Any idea how to make build get this crate? The package name (known by Cargo and crates.io) is wayland-client, it’s the library name (known by rustc) that’s wayland_client. https://crates.io/crates/wayland-client Beyond that, crates.io was unavailable for a while yesterday. Maybe that impacted you? What’s the full output you get when building Servo? -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Servo without Bluetooth
On 31/05/16 16:40, Manish Goregaokar wrote: My main issue with cargo features is that they would pollute all the Cargo.tomls in the dependency tree between servo and devices, and if another dependency is added (even amongst these crates) it would have to be added, or else we may get confusing compile errors. It would be nice if you can "drop in" features from above without requiring daisy chaining, but AFAICT that's not always doable. It is possible currently to do `cargo build --features net/devices/nameoffeature` without polluting cargo.tomls, I think we can have something like this in components/servo/Cargo.toml : [features] no-bluetooth = ["net/devices/no-bluetooth"] but IIRC this isn't always supposed to work (since all the other dependency paths do not have it enabled). If this turns out to be working reliably I'd prefer to do this, though it may unexpectedly break in the future. Why isn’t this supposed to work? Based on conversations with Alex, Cargo by design builds a crate with the union of all requested features. There is no need for all dependents to specify the same set of features and this isn’t an accident. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] How to disable Rust download and force use of pre-installed Rust?
On 11/05/16 21:29, Michal Suchanek wrote: Hello, On 11 May 2016 at 16:21, Jack Moffitt wrote: Note that you will not be able to build with 1.8.0 since we depend on many features available only in nightly. You can see which nightly we download by looking at the date in https://github.com/servo/servo/blob/master/rust-nightly-date (currently 2016-05-07). It may work with slightly newer or older nightlies as well. I suspect the reason you can't download the nightly is that the platform detection code is returning "unknown" for your processor. You might consider filing a bug for that. What target triple do you normally use? Is such download even available? You can find the level of Rust support for various platforms documented here: https://doc.rust-lang.org/book/getting-started.html#platform-support If you navigate to https://static.rust-lang.org/dist/2016-05-07/ (or similarly for another date) you can find the official builds as well as rustc-nightly-src.tar.gz, the source package that you can build yourself. Back when I tried to build servo for ARM rust claimed ARM compatibility but I could not find a prebuilt compiler. rust-lang.org only started making builds of the standard library for cross-compiling to ARM a few months ago, but it’s been functional (with users building their compiler and standard library themselves) for longer than that. I downloaded the x86 version and kind of cross-compiled rust using qemu and tweaked the servo build script to skip the download. As Jack mentioned, you can copy servobuild.example to .servobuild and configure it with the location of your Rust build. No need to tweak the script. The built servo was more flaky than the x86 one. iirc it seemed to require more featureful graphics than fbdev. And i did not have the exact nightly used by the build script, too. Servo does do a lot of stuff of the GPU, but I don’t know the exact requirements. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] rust-url 1.0: rewrite the data structure and API
Hi all, I have a pull request for rust-url with large breaking changes: https://github.com/servo/rust-url/pull/176 I’d appreciate feedback (preferably in github comments) on the API design. Thanks! -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Hello and intro!
On 05/02/16 21:53, Rebecca Star wrote: Hi all, Wanted to introduce myself! I'm Rebecca Star. I'm currently a grad student at Penn, and will be contributing to Servo over the next few months for school credit. I'm hoping to start out with a few smaller issues, and then try for a bigger contribution towards the end of the semester. I'm currently working on this - https://github.com/servo/servo/issues/9540. Afterwards, I'll be looking for more things to pick up, so feel free to reach out! Welcome! Feel free to ask questions on this list or on the #servo IRC channel: https://wiki.mozilla.org/IRC -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Using Cargo in Gecko
On 22/12/15 03:55, gsz...@mozilla.com wrote: The *only* way to prevent [race conditions] is for there to be a single source of truth. Yes, I think that’s an important point. An alternative is to make mozilla-central the canonical repository. Facebook has [...] When it comes time to merge a pull request, they don't merge it in GitHub. Instead, a tool grafts the branch onto their monorepo, commits it, syncs it back out to the GitHub project, then closes the pull request. I understand why there would be visceral reactions to shackling your project to mozilla-central. There is a lot of process and overhead there. But, with some tooling and realized planned improvements to the automation infrastructure that e.g. reduce tree closures, I think many of these concerns would go away. Projects could be canonically located in mozilla-central, but all day-to-day development is performed in GitHub (or wherever). This gives us all the nice properties of the monorepo without the bi-directional syncing problems and hopefully without forcing too many [sub-optimal] workflows and limitations on people. As the primary maintainer of rust-url, I’m willing to try this. But to be honest, it feels backwards from how things "should" be. Servo and Firefox are two of many projects using rust-url. (Which replaces what used to be a module in the Rust standard library.) I don’t think we can ask the same of Rust projects whose maintainer don’t happen to be on the Servo team. At worst this could be perceived like a hostile take-over. I’m also worried about the process and overhead you mention. Gecko developer first committing upstream and then pulling down that change into mozilla-central - likely high latency and frustrating Isn’t that latency and frustration the same the other way around? How long would it typically take between approving a GitHub PR and having it land in GitHub master? (This matters when a conflicting PR needs to be rebased.) Would it be blocked on mozilla-inbound being merged into mozilla-central? -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Using Cargo in Gecko
On 18/12/15 00:04, Valentin Gosu wrote: [http] timeout = 0, which prevents downloading any resources from crates.io. [1] Serious question: does timeout = 0 stop HTTP requests from being made in the first place, or do they fail because you happen to be more than 500 miles from an S3 server? http://www.ibiblio.org/harris/500milemail.html -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Fwd: Profile directory (Re: IndexDB project)
On 17/12/15 17:09, Josh Matthews wrote: Right, I know there are expected conventions. My previous suggestion was an attempt to provide a mechanism to allow testing persistence between sessions without actually committing to any of the work involved in creating a proper setup for persistent profiles. That feels like a distraction to me, at the moment, and we could spend the time on more interesting things. Since rust-xdg already exists, I don’t think using it in code and setting an environment variable in tests is harder than adding a non-standard command-line option. This doesn’t have to be a distraction if we don’t bikeshed it. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Planning to experiment with inline storage for DOMString / webidl binding codegen
On 02/12/15 02:39, Nick Fitzgerald wrote: I've created a crate[0] that provides a mostly drop-in replacement of std::string::String but with inline storage for small strings to avoid heap allocation. [0]https://github.com/fitzgen/inlinable_string There’s also [1], already in used in Servo in some places, which behaves like Vec but stores items inline up to a certain length. I’ve also been playing with [2] to be like String but with a generic backing storage. (I’ve used it in [3] to return a single code point in UTF-8 as StringWrapper<[u8; 4]>.) Would it make sense to converge with some of these? [1] https://github.com/servo/rust-smallvec [2] https://github.com/SimonSapin/rust-std-candidates/blob/master/string-wrapper/lib.rs [3] https://github.com/SimonSapin/rust-utf8 -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Revisiting "conflicting version" tidy checks
On 26/11/15 17:05, Simon Sapin wrote:
Currently, pull requests can not land until `./mach test-tidy` passes,
which includes checking that we’re not building more than one version of
any crate.
This usually makes sense: duplicate crates increase binary size and
sometimes cause build errors ("expected `url::Url`, found `url::Url`).
But sometimes this is a pain to fix.
https://github.com/servo/servo/pull/8446 (a Rust upgrade started 17 days
ago) is nearly ready to land except for 54 such tidy errors:
https://gist.github.com/anonymous/94c681bf50df3b784c84
All of them are to be fixed in repositories other than servo/servo (most
of which don’t have a maintainer in the Servo team). Most of them are
about libc 0.1 and 0.2 (which is mostly type and function definitions,
so maybe no binary size impact?). None of them cause build errors.
In this case, I feel like this check is more of a burden than it helps.
What do you think of making it advisory rather than a hard requirement?
Josh pointed out that tidy.py has a list of exceptions for this check.
I’ve added libc to the list, which leaves 5 repositories to send PRs to
(rather than dozens). I’ll try this.
--
Simon Sapin
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Revisiting "conflicting version" tidy checks
Currently, pull requests can not land until `./mach test-tidy` passes,
which includes checking that we’re not building more than one version of
any crate.
This usually makes sense: duplicate crates increase binary size and
sometimes cause build errors ("expected `url::Url`, found `url::Url`).
But sometimes this is a pain to fix.
https://github.com/servo/servo/pull/8446 (a Rust upgrade started 17 days
ago) is nearly ready to land except for 54 such tidy errors:
https://gist.github.com/anonymous/94c681bf50df3b784c84
All of them are to be fixed in repositories other than servo/servo (most
of which don’t have a maintainer in the Servo team). Most of them are
about libc 0.1 and 0.2 (which is mostly type and function definitions,
so maybe no binary size impact?). None of them cause build errors.
In this case, I feel like this check is more of a burden than it helps.
What do you think of making it advisory rather than a hard requirement?
--
Simon Sapin
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] PSA: Review delegation enabled for homu
On 12/11/15 01:22, Lars Bergstrom wrote: the 1--2AM US Pacific slot that appears to be both the "deadzone" for our reviewer coverage That’s 10~11 am in my time zone. I’m generally awake at that time, feel free to ping me on IRC if I can unblock something. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Query on properties.mako.rs for CSSparser
On 31/10/15 03:00, Pranesha Shashwath Kumar Kattepura Jayabheema Rao wrote: Hi, We are getting an error "This function takes 4 parameters but 3 were supplied" for all the instances of the function get_specified!. Adding to what Josh said: get_specified! is not a function, it’s a macro. (This is visible by the ! mark.) So "this function" refers to something else. Rather than returning a value like functions, macros expand to more code. Errors like "This function takes N parameters" occur after macro expansion. You can read more about macros at http://doc.rust-lang.org/book/macros.html -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] libz error while building servo in Ubuntu
On 23/10/15 05:43, Pranesha Shashwath Kumar Kattepura Jayabheema Rao wrote: Python virtualenv failed to execute properly. Try removing the python/_virtualenv directory, it should be re-created automatically next time you run ./mach build -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] "Hacking Servo for noobs" moving it to servo repo or to wiki?
On 22/10/15 20:35, Josh Matthews wrote: I'd prefer a separate file. There's a lot of information in Paul's guide, and CONTRIBUTING.md should be a curated overview of only what is immediately relevant to a new contributor. I’d say a seperate file, linked from both CONTRIBUTING.md and README.md. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Running WPT tests
On 21/10/15 11:06, Gilles Leblanc wrote: Also running these takes a really long time. Is there a guideline for when/how to run them? Release builds take longer to make, but then run tests much faster. (About 3x and 5x respectively on my machine.) They’re worth it if you run all or a large part of the WPT suite. ./mach build -r ./mach test-wpt -r -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] (no subject)
On 17/10/15 23:00, Manish Goregaokar wrote: This is a known issue. aster needs to be updated to work with latest Rust. You can use Servo's Rust snapshot (here <http://servo-rust.s3.amazonaws.com/168a23ebe1729386138fa71643382fdd64fac205/rust-docs-1.5.0-dev-x86_64-unknown-linux-gnu.tar.gz>) in the meantime. If you also have a clone of the Servo repository, you can use its Rust snapshot (which is downloaded automatically) by using e.g. `../servo/mach cargo` instead of `cargo`. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] new project meeting schedule proposal
On 05/10/15 19:01, Jack Moffitt wrote: Moving the meeting later is not great since it needs to be early for the comfort of people in Europe. Is Wednesday better? Yours was the only conflict brought to my attention. On Wednesdays I have the CSSWG call at 9am (California time), but it finishes by 10am. Batching meetings would be ideal for me, but other days work too. Does the early meeting need to move at all? I thought what promted this was conflicts with the late meeting time. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Rust embedding
On 08/09/15 17:02, meh. wrote: [1]: https://github.com/meh/miserve/blob/master/SERVO.md Style The style hooks are required to implement user-styles. There should be a way to prepend a stylesheet to any page. You can use http://doc.servo.org/servo/util/opts/struct.Opts.html#structfield.user_stylesheets to add "user origin" stylesheets to every document. See https://drafts.csswg.org/css-cascade/#cascade-origin and https://drafts.csswg.org/css-cascade/#cascading-origins -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Reviewers
On 01/09/15 10:15, Anthony Ramine wrote: I can be the second person on h5e, if you want. That’s great, thanks! -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Reviewers
On 01/09/15 02:21, Josh Matthews wrote: https://github.com/servo/servo/wiki/Meeting-2015-08-31 Submodule reviews html5ever reviews I have delayed these html5ever reviews for various reasons, but they’re on my queue. I’m willing to take this on officially, whatever that means. Speaking of which, we should figure out what that means. Ideally, I’d like us to have at least two reviewers / owners for each area of code, with their names published somewhere easy to find. One is not ideal when they’re on vacation or otherwise unavailable, or to get their own PRs reviewed. "Areas of code", to start, could be each crate in the servo/servo repository and each other repository in the servo org on github. Of course we may not be able to reach this ideal state yet, but we should still go towards it. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] PSA: import blocks are now sorted
On 25/08/15 08:22, Nicholas Nethercote wrote: Unfortunately the group ordering is inconsistent and sometimes wrong. For example, in some files it goes: - imports from this crate - imports from other Servo crates - imports from non-Servo crates - imports from built-in crates I’m in favor of a single alphabetical-order group. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Travis, Rust Nightlies & Aster
On 20/08/15 17:50, Ms2ger wrote: Hi all, Recently, homu has regularly rejected PRs to rust-layers because of a mismatch between the latest Rust nightly (which Travis uses by default), and Aster (which it depends on through euclid and serde_macros). This has been solved by locking the Rust nightly to a version that works with the latest version of Aster (at that point). However, when Aster is updated for the breaking changes in Rust, the build breaks again. Does anyone have ideas on how to avoid this issue in the future? If https://nightli.es/ or something like it is set up on aster and serde to notify of breaking changes in Rust Nightly and they are kept up-to-date then the problem is solved, isn’t it? Erickt has offered to give push access to some of us to help make this happen. I don’t mind doing it if nobody else wants to. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] rust-geom has been renamed to euclid
On 17/06/15 17:30, Jack Moffitt wrote: Servo is not yet using this new version yet, but repo links to the rust-geom repo should still be valid for a while. Github sets up redirect (for both git and web access) that should keep working until we create a new servo/rust-geom repository (if we do at all), so old Servo commits should still build. We should still update to the new name, though, and use the crates.io copy to force ourselves to keep it up-to-date. I’ve filed https://github.com/servo/servo/issues/6406 about this. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] (Not) using wildcard version when declaring dependencies
On 15/06/15 23:03, Manish Goregaokar wrote: From what I've seen, semver isn't being used to it's full extent yet, especially with libraries working on nightly. Locking to particular versions tends to make rustups harder (and leads to multiple versions of the same package being used). The breaking changes in libraries seem less common and breaking than breaking changes in, say, plugins, so IMO we should stick to Cargo.lock for pinning and use `mach update-cargo -a` during rust upgrades. My previous message was about breaking changes in a library on crates.io, not in the standard library. Many crates follow Rust master. In the past, that meant that that any given version a library only worked with a narrow range of Rust version/commits. As a consequence, we mostly only updated Servo’s dependencies while doing Rust upgrades at the same time. But with 1.0 out this is less and less the case: many libraries can be updated without updating Rust, and a smaller number of libraries need to be updated when we update Rust. In time, there’ll be no reason to do both at the same time. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] (Not) using wildcard version when declaring dependencies
Some of our dependencies to crates on crates.io are declared in Cargo.toml files like this: [dependencies] foo = "*" To be honest, I’m not sure why. With such a declaration, `cargo update` will happily update the foo library to its latest version, whatever it is. There’s a number of things we can write instead of "*" (documented in http://doc.crates.io/crates-io.html ), but another way looks like this: [dependencies] bar = "0.1.3" This looks like we’re specifying a dependency on one precise version, but we’re not. "0.1.3" is equivalent to "^0.1.3" which means anything that is compatible with 0.1.3 per Semantic Versionning, namely ">=0.1.3 <0.2". If we follow Semantic Versionning and increment the first non-zero component of the version number for breaking changes and another component for backward-compatible changes, and also use this kind of dependency declaration, then `cargo update` will pick up any new version that are compatible, but none with breaking changes. I think we should do this. (Breaking changes would most likely require changing some source code, so changing the dependency declaration at the same time isn’t too much of a bother.) -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Tree open again (Re: Tree closed for line length reduction (!))
On 24/05/15 09:21, Simon Sapin wrote: Please delay landing any PR in servo/servo until https://github.com/servo/servo/pull/6174 gets reviewed and merged. If you want to discuss the idea, head over to https://github.com/servo/servo/issues/6041 . It’s landed, the tree is open again. Thanks Corey! -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Tree closed for line length reduction (!)
Please delay landing any PR in servo/servo until https://github.com/servo/servo/pull/6174 gets reviewed and merged. If you want to discuss the idea, head over to https://github.com/servo/servo/issues/6041 . -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] crates.io package ownership (write access)
At the moment, packages on crates.io have one or more "owner", individuals with GitHub accounts. We have a feature request on crates.io to have groups or something https://github.com/rust-lang/crates.io/issues/137 but until that happens the ownership of each package is managed separately. (Or perhaps we could build the feature and contribute it to crates.io.) We probably don’t want to be blocked from publishing an update because the person who originally published a package happens to be on vacation and no one else is "owner". So we should actively be adding multiple owners for packages whose source is under https://github.com/servo . Who should that be? Everyone on https://github.com/orgs/servo/teams/owners ? Everyone on https://github.com/orgs/servo/people ? Some other set of people? Or something different for each package, based on people’s area of interest? -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Policy for publishing submodules to crates.io
On 22/05/15 15:49, Josh Matthews wrote: https://github.com/servo/rust-harfbuzz/issues/39 is not the first request to publish certain dependencies on crates.io. I'm in favour of this; the question is whether we can build in systems that avoid the publish-and-forget workflow. Thoughts? Should we just go ahead and publish the latest revision whenever someone asks us to? What’s the concern, that we’ll publish once and then never republish because we keep using a git dependency? Then we can stop using a git dependency and have Servo get that package from crates.io. That way we’ll be "forced" to publish changes on crates.io before Servo can use them. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Adding Windows CI
On 10/05/2015 06:01, Manish Goregaokar wrote: Appveyor provides free CI for Windows, and is pretty easy to set up. Since we already have Travis set up on almost all deps, should we do the same with Appveyor? I tried it out on rust-url[1] and it worked pretty smoothly (yml copied from Glutin) Most of our deps should just work with Windows, and various volunteers have made progress on Windowsifying our native deps. Identifying which deps need Windows work; and ensuring that the working deps continue to work, would be quite helpful for the Windows effort. Thoughts? rust-url has platform-specific code (with e.g. #[cfg(windows)]) that, even though there’s not a lot of it, regularly got broken on Windows because I don’t test it and Travis-CI doesn’t test it: https://github.com/servo/rust-url/issues/102 So Appveyor is helpful there. For libraries like cssparser that don’t have platform-specific code however, I don’t think Appveyor brings us anything. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Upgrading Rust / Hyper for Websocket Integration
On 16/03/15 00:15, cgrdocume...@gmail.com wrote: Alright, after modifying WebSocket to use the hyper on the servo git, we are having problems now with bswap 0.1.8, another dependency, not compiling now. Going to keep trying to compile and we will see what happens. What’s the library that depends on bswap? In the Rust version that Servo uses right now, that functionality is part of the standard library’s std::old_io::Reader and std::old_io::Writer and the bswap library did not exist yet. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] CSS Houdini meeting report
Last week I was in Sydney for the first face to face meeting of “CSS Houdini”, a new joint task force of W3C’s CSS Working Group and Technical Architecture Group. The goal is to “explain the magic” of CSS, make it extensible by providing low-level primitives that can be built upon to add new higher-level features to the platform without baking them into browsers. Participants were from Microsoft, Google, Mozilla, HP, W3C, Disruptive Innovations, Apple, Vivliostyle, Adobe, and jQuery Foundation. I have heard concerns that Google or Apple would just expose whatever Blink/WebKit’s internals currently are, and the rest of us implementers would be stuck with that. Since this work is happening at W3C and participants include people working on competing engines, I am confident this won’t happen. I will also be watching for design decisions that could be incompatible with Servo’s goals (e.g. parallel layout, layout concurrent with script, etc.) About the task force: Mailing list: https://lists.w3.org/Archives/Public/public-houdini/ IRC: #houdini @ irc.w3.org Wiki: https://wiki.css-houdini.org/ Draft specifications: http://dev.w3.org/houdini/ Source repository: https://hg.css-houdini.org/drafts Read/write mirror repository (pull requests work): https://github.com/w3c/css-houdini-drafts Formatted minutes of these discussions should be published soon. In the meantime, the raw IRC logs are at: http://log.csswg.org/irc.w3.org/houdini/2015-02-06/ http://log.csswg.org/irc.w3.org/houdini/2015-02-07/ The group agreed on its own scope, and on starting new 8 specifications. I described them below based on my the minutes and my own recollection of the discussions. If you want to discussed the proposals themselves (as opposed to their implications for Servo), please do so on the public-houd...@w3.org mailing list. (Subscription info is at the URL above.) * Fragment Tree Expose read-only information to script about the fragment tree, which is roughly what implementations call the render tree, frame tree, or flow tree. This includes "anonymous" fragments, that are not generated directly by any DOM element. This was previously discussed as a "Box Tree", but was renamed since boxes (as defined in CSS specs) don’t have geometry, only fragments (again per spec, after fragmentation across lines, columns, regions or pages) do. * CSS Parser API Expose various pieces of the CSS parser: selectors, rules, complete stylesheets, colors, gradients, unknown properties, etc. Web authors are often doing this ad-hoc with regular expressions, which is painful and hard to get right. The shape and API of returned objects (representing tokens or an AST or higher-level values) is yet to be determined. * CSS Properties and Values Extensions Currently, CSS implementations throw away (per spec) rules or declarations they don’t understand. The error recovery and fallback allow for some forward-compatibility, but this is somewhat limited. We now also have CSS Custom Properties, but they’re namespaced with the -- prefix. This proposes adding APIs enabling script to register new at-rules and properties with a details about their behavior and callbacks for parsing, as well as new values for existing "types" (e.g color, length, image, …), thus enabling polyfills. * Font Metrics Extensions Some desired features like drop caps a.k.a. initial letters require various measurements from fonts such as position of the baseline, height of ascenders and descenders, etc. This proposes APIs to determine which font is actually used for a given piece of text in the document (since the `font-family` property accepts a list of family names) and query such measurements. * Custom Paint This proposes adding callbacks into script during painting, to enable various graphical effects. One example given was an animated procedural background image of ripples, as if on a fluid surface, that propagate from a disturbance point and bounce against the borders of the element. * CSS Custom Layout This propose adding the ability to define new layout modes (like Flexbox is a layout mode) in script, with callbacks for the various phases of layout. These modes would probably be opted into through new values of the 'display' property. * CSS Scroll Extensions This proposes adding hooks to control scrolling (e.g. for snap points), and what scrolling should block on (e.g. slow scroll event handlers). * CSS Async Style As far as I understand, this proposes adding control on what phases of rendering of what parts of the document can be deferred or (de)prioritized. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] New CSS parsing conventions
“newnewnewcss”, the port of Servo to the recently refactored rust-cssparser, has landed: https://github.com/servo/servo/pull/4689 Please let me know if you find any regression. If you’re writing or modifying CSS parsing code in Servo (e.g. adding a new CSS property), you should be aware of and follow the conventions documented here: http://servo.github.io/rust-cssparser/cssparser/index.html Previously, parsing was based on "component values" that were either tokens, or blocks/function that contained a vector of more component values, forming a tree. Parsing functions would take a `&ComponentValue` or `&[ComponentValue]` parameter as their input. Now the input is represented by a `&mut Parser` that tracks its own position within the input and yields tokens. When encountering a function token on block-opening token, you can get another `Parser` object for the arguments/contents. Otherwise the block is just skipped. Alternatives can be expressed by saving and restoring the internal state of the parser. (This is cheap, just copying 16 bytes. However some tokenization work may be duplicated.) Everything relies heavily on `Result<_, ()>` types and the `try!` macro (which returns early on `Err`) to make the code easier to read and maintain. (For what it’s worth, the diff stat is +1,949/-2,319 lines.) Finally, string components of tokens now use the `CowString` type to borrow from the input when possible and avoid many allocations and lots of copying. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Regarding Google Summer of Code 2015
On 22/12/14 11:50, Gervase Markham wrote: Like all other teams in Mozilla, the Servo team will have an opportunity to propose ideas (with attached mentors) on the Mozilla ideas list. I was wondering how that works. It seems that proposals should go to the 2015 equivalent (when it’s created, likely some time in January) of this page: https://wiki.mozilla.org/Community:SummerOfCode14:Brainstorming We can still start gathering ideas, of course. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] The target directory has moved
https://github.com/servo/servo/pull/4140 has landed. It moves the Cargo.toml file for the 'servo' crate from the repository’s root to 'components/servo'. As a result, the 'target' directory created by Cargo is now at 'components/servo/target'. Most importantly, if you use execute './target/servo' directly, it will be your previous build and will not be updated by 'mach build' anymore. You should use './components/servo/target/servo' or 'mach run' instead. You can also run 'mv target components/servo' to avoid re-building everything from scratch. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] CSS property usage chart
On 08/11/14 22:14, Patrick Walton wrote: Hi everyone, I've created a simple chart of Servo CSS property support vs. usage (taken from Chromium's usage charts at [1]). This may be useful if you're looking for something to implement :) https://docs.google.com/spreadsheets/d/1CxLS8w8GwK-2euVErrqpUUb76PiZa6w5h5EnGsL9KFs/edit?usp=sharing Obligatory caveats: * This was automatically generated from the Chromium charts, Servo source code, and W3C specifications, so there may be some errors, especially around classification of properties into levels 2 and 3. * This was taken from my branch (so `box-shadow` is considered supported even though it's not in the master branch yet). * This only indicates whether Servo has any support at all for each CSS property. It does not test whether the implementation of the property is bug-free in Servo, whether all of the features of the property (e.g. multiple backgrounds) are supported, or whether the property is implemented in a performant manner. Very nice, thanks Patrick. Could you add the caveats at the top of the spreadsheet itself, for people coming from Twitter? Additional caveat: just because a property has high usage doesn’t mean we should implement it in Servo. For example, the 'zoom' property is non-standard and roughly equivalent to 'transform: scale(...)'. Since it’s not implemented in Firefox, I doubt many websites actually rely on it, rather than just using it as a fallback for older browsers that don’t support CSS transforms. (Still, this is more of an exception than a common case.) -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Intrinsic sizing of orthogonal flows and parallel layout
So far, Servo’s layout implementation is divided into three parallel tree traversals: intrinsic inline-size calculation (bottom up), used inline-size assignment (top down) and block-size assignment (bottom up). Each traversal only depends on results from the previous one. (Inline-size and block-size and width and height respectively in horizontal text such as English.) Now that we’re adding CSS Writing Modes, there is a problem with orthogonal flows (vertical text where the parent is horizontal, or the other way around.) Normally the intrinsic inline-size of a block is based on the intrinsic inline-size of its children. But if one of the children is an orthogonal flow, it’s based on that child’s intrinsic block-size instead. Now, the details of intrinsic block-size are not that well-defined in the spec [1] right now, but it probably involves doing actual layout all the way through, with a couple of different available inline sizes. [1] http://dev.w3.org/csswg/css-sizing/#block-intrinsic This means using results (for a subtree) of our third traversal in the first traversal. Can we do that without compromising parallel layout? -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Question about a certain line of code in Servo
On 24/10/14 17:19, Gilles Leblanc wrote:
Declaration_(Declaration{ location: l, name: n, value: v, important: i}) =>
{
The code is doing some pattern matching. `_` normally matches against every
other case.
`_` here is part of the `Declaration_` name, not a pattern of its own.
`Declaration_` is an enum variant that used to be called `Declaration`,
but had to be renamed relatively recently when variants started taking
up a name in the type namespace, to avoid colliding with the
`Declaration` struct.
http://doc.servo.org/cssparser/ast/enum.DeclarationListItem.html#variant.Declaration_
http://doc.servo.org/cssparser/ast/struct.Declaration.html
https://github.com/rust-lang/rfcs/blob/master/text/0234-variants-namespace.md
as if `item` matches the result of any function starting with
Declaration and with any suffix
In patterns, the syntax `Foo(..)` indicates enum variants or tuple-like
structs, not arbitrary functions.
I can't seem to find where Declaration is defined, where `mportant`
comes from
As Josh mentioned, the rustdoc documentation for Servo, all its
dependencies, and the Rust version we’re using is at
http://doc.servo.org/ . They can be search with the bar at the top, or
with an URL like http://doc.servo.org/servo/?search=foo
--
Simon Sapin
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] (Lack of) XML parser (was: Meeting notes 10/13)
https://github.com/servo/servo/wiki/Meeting-2014-10-13 kmc: [...] I was just reading about XML5 which uses an HTML parsing algorithm; possibly we could use for XML that instead of wiring up a proper XML parser. There are two different things. XML5 is a new parsing algorithm for XML that uses permissive error handling (like HTML) instead of draconian (the yellow screen of death). It is designed to be backward-compatible and relatively sane, without all the weird behavior that HTML parsing has for compatibility with existing content. There is a spec and a Python implementation, both made in 2007, and a Ruby port made in 2011. Neither look like they’ve been used much beyond the "interesting experiment" phase. I don’t know how much code an XML5 parser would be able to share with an HTML parser, but it’s a separate algorithm. I also heard some noises about Blink wanting to use their HTML parser (I suppose with some tweaks such as starting in a different mode) for image/svg+xml, in order to get permissive error handling, and the SVG Working Group being receptive to the idea. This is not XML5. It might involve less engineering effort than XML5. Is there anything other than SVG that might require an XML parser? zwarich: On the web, is validity-checking for XML input required? I don’t have evidence either way (and the only way to find out might be to try it), but it sounds unlikely that real content relies on an entire document failing to parse. XML5 is entirely based on the assumption that we can give any meaning we want to input sequences that used to fail to parse. -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] WTF-8 encoding for DOM strings and HTML parsing
On 06/10/14 07:57, Henri Sivonen wrote:
On Sun, Oct 5, 2014 at 7:26 PM, Simon Sapin wrote:
JavaScript strings, however, can. (They are effectively potentially
ill-formed UTF-16.) It’s possible (?) that the Web depends on these
surrogates being preserved.
It's clear that JS programs depend on being able to hold unpaired
surrogates and then to be able to later pair them. However, is there
evidence of the Web depending on the preservation of unpaired
surrogates outside the JS engine?
Is "outside the JS engine" anything other than DOM and CSSOM?
* Specification: https://simonsapin.github.io/wtf-8/
Looks great, except for the definition of "code unit". I think it's a
bad idea to redefine "code unit". I suggest minting a different
defined term, e.g. "16-bit code unit", to avoid redefining "code
unit".
Also, even though it's pretty obvious, it might be worthwhile to brag
in an informative note that "To convert lossily from WTF-8 to UTF-8,
replace any surrogate byte sequence with the sequence of three bytes
<0xEF, 0xBF, 0xBD>, the UTF-8 encoding of the replacement character."
means that you can do it *in place*, since a surrogate byte sequence
is always three bytes long and the UTF-8 representation of the
REPLACEMENT CHARACTER is three bytes long.
Good points. I’ve done both of these as suggested.
* document.write() converts its argument to WTF-8
Did you instrument Gecko to see if supporting the halves of a
surrogate pair falling into different document.write() calls is
actually needed for Web compat?
I have not. Can our telemetry infrastructure support this kind of thing?
FWIW, it is supported in Gecko, WebKit, Blink, and Trident. (Presto
shows two "missing glyph" rectangles.)
document.write('"\uD83D');
document.write('\uDCA9"');
(Of course, if you believe that
supporting the halves of a surrogate pair falling into different
[adjacent] text nodes in the DOM is required for Web compat, you might
as well make the parser operate on wtf-8.)
I’m guessing that is not necessary, since WebKit, Blink, and Presto
don’t support it. (Gecko and Trident do.)
document.body.appendChild(document.createTextNode('"\uD83D'));
document.body.appendChild(document.createTextNode('\uDCA9"'));
WebKit and Blink appear to ignore for text rendering everything from the
first unpaired surrogate until the end of the text node. (The data is
still in the DOM.) Presto shows two rectangles.
In the future, if the JS team thinks it’s a good idea (and figures something
out for .charAt() and friends), SpiderMonkey could support WTF-8 internally
for JS strings and Servo’s bindings could remove the conversion.
For me, absent evidence, it's much easier to believe that using WTF-8
instead of potentially ill-formed UTF-16 would be a win for the JS
engine than to believe that using WTF-8 instead of UTF-8 in the DOM
would be a win.
So you’re suggesting Servo could get away with UTF-8 in the DOM? I
hadn’t considered it. I remove my proposal at the start of this thread,
I’d like us to try this instead.
Servo would not need to use WTF-8 at all, and could just keep a single
16 bit code unit around for when the document.write() input ends with a
lead surrogate, as Keegan suggested here:
https://github.com/kmcallister/html5ever/issues/6
Did anyone instrument SpiderMonkey in the Gecko case to see if
performance-sensitive repetitive random-access charAt() actually
occurs on the real Web? (If perf-sensitive charAt() occurs with
sequential indeces in practice, it should be possible to optimize
charAt() on WTF-8 backing storage to be O(1) in that case even if it
was O(N) in the general case.)
Sounds interesting, but I’ll leave this to people who actually work on
SpiderMonkey.
--
Simon Sapin
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] WTF-8 encoding for DOM strings and HTML parsing
We’ve discussed using UTF-8 internally for strings in Servo, but well-formed UTF-8 can not represent surrogate code points. JavaScript strings, however, can. (They are effectively potentially ill-formed UTF-16.) It’s possible (?) that the Web depends on these surrogates being preserved. So instead of UTF-8, we can use something we’ll call Wobbly Transformation Format − 8-bit (WTF-8). * Specification: https://simonsapin.github.io/wtf-8/ * Rust implementation, as a Cargo library: https://github.com/SimonSapin/rust-wtf8 * Library documentation: https://simonsapin.github.io/rust-wtf8/wtf8/index.html It is a strict superset of UTF-8 (like UTF-8 is a strict superset of ASCII), so converting from well-formed UTF-8 is a no-op. It can losslessly represent all values JavaScript strings can (code points, including surrogates, as long as they’re not paired.) Concatenating needs care to behave like concatenating JS strings would. (Convert newly-paired surrogates into supplementary code points.) Proposal for Servo: use WTF-8 internally for all strings in the DOM and for HTML parsing. * rust-encoding decodes bytes form the network into well-formed UTF-8 * document.write() converts its argument to WTF-8 * The html5ever tokenizer takes buffers that are either UTF-8 or WTF-8 * html5ever uses WTF-8 everywhere internally, and emits WTF-8 to the tree builder. * (Optionally, html5ever could support a separate UTF-8 only interface for non-Servo users that don’t need to support document.write().) * Servo’s DOM stores WTF-8. * Strings are converted to/from potentially ill-formed UTF-16 (that SpiderMonkey can use) by the bindings code generation, at the boundary between JavaScript and Rust. In the future, if the JS team thinks it’s a good idea (and figures something out for .charAt() and friends), SpiderMonkey could support WTF-8 internally for JS strings and Servo’s bindings could remove the conversion. What do you think? -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
