Re: Reminder: Planned Taskcluster migration this weekend (Nov 9)
On 04/11/2019 23:00, Chris Cooper wrote: Existing URLs, e.g. links to artifacts, will continue to work once the current monolithic deployment is put into read-only mode on Monday, Nov 11. How long is are these read-only URLs expected to be maintained after that? -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: To what extent is sccache's distributed compilation usable?
On 28/10/2019 17:27, smaug wrote: Quite often one has just a laptop. Not compiling tons of Rust stuff all the time would be really nice. (I haven't figured out when stylo decides to recompile itself - it seems to be somewhat random.) I’m pretty sure there is no call to a random number generator in Cargo’s code for dependency tracking. Spurious recompiles are bugs that are worth filing so that they can be fixed. If you manage to find steps to reproduce, building with a CARGO_LOG=cargo::core::compiler::fingerprint environment variable should print some details about why Cargo things some crate (and there for those that transitively depend on it) needs to be rebuilt. https://github.com/servo/mozjs/pull/203 is an example of a fix for such a bug: a combination of a `build.rs` script being over-eager in using `rerun-if-changed` and calling something that ends up writing to the source directory. `rerun-if-changed` is documented at https://doc.rust-lang.org/cargo/reference/build-scripts.html On 29/10/2019 00:54, Gerald Squelart wrote: It's a bit annoying to see things like "force-cargo-...-build" when nothing has changed, That much makes sense to me: running `cargo build` is part of figuring out that nothing has changed. Cargo has a lot of dependency tracking logic, duplicating it all to avoid calling it would be unproductive and fragile. Running `cargo build` with a warm filesystem cache when there’s nothing to do should not take more than a couple of seconds. (Looking at the mtime of each source file.) accompanied by lots of "waiting for file lock on package cache". This line is printed − once − when Cargo is waiting for a filesystem lock. It showing up N times is a sign that there are at least N+1 copies of Cargo running concurrently. It would be nice to run Cargo only once and tell it up-front everything it needs to do (with `-p foo` multiple times, or `--all`, or `default-memebers` https://doc.rust-lang.org/cargo/reference/manifest.html#package-selection) rather that having multiples copies competing for a shared resource. -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Must we rebuild all our rust code constantly?
On 23/08/2019 04:00, Mike Hommey wrote: I had a similar experience on a 36-core machine earlier today. It seems incremental is not working properly for the style crate: incremental is supposed to have the same effect as sccache, but it still takes a long time to compile style. I'm told mw is going to look into this in the coming weeks. I don’t know how much it has evolved since, but the initial versions of incremental compilation in rustc only cached code generation in LLVM. Type checking, trait resolution, etc. was still done every time rustc was invoked for a crate. -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Must we rebuild all our rust code constantly?
On 22/08/2019 03:42, ISHIKAWA, Chiaki wrote: At the same time, I have a feeling that the debug symbol that rustc generates may be a tad bigger than I would like it to be, but I need to investigate more about this. Sounds like this known bug of rustc: https://github.com/rust-lang/rust/issues/56068 -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: New Lockwise Password Manager UI now on autoland
On 19/07/2019 19:14, Nicolas B. Pierron wrote: How does that work for migrating password from the current password manager? As far as I understand Lockwise-in-Firefox *is* the current password manager, only with a new UI similar to the Lockwise standalone Android app. Storage and sync are the same as before. -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Duplicate dependency policy for Rust in mozilla-central?
On 15/03/2019 14:31, Xidorn Quan wrote: Servo has a policy banning duplicate dependencies with a whitelist, and such list currently has: This exact allow-list is not part of Servo’s policy, but is constantly evolving. If you can reduce it (typically by updating some intermediate dependencies to versions that use e.g. log 0.4 instead of 0.3), this is great and we love you. If you add a new exception to the allow-list, in review we will ask that you make some effort to avoid doing so. If the effort turns out to be disproportionate (for example: many intermediate dependencies are affected, and they in turn would affect other crates in the graph) or if we want to avoid waiting too long on upstream (because a patch is at risk of bitrotting, or blocks other work, or…) then we may accept growing the list. The important part is that machine-verification avoids accidentally adding new duplications. On 15/03/2019 15:38, Andreas Tolfsen wrote: It is my experience that far too many dependencies are defined on exact version numbers, e.g. "log = 0.3.9", which effectively forces us to vendor that exact version in-tree. It does not force that. Specifying `log = "0.3.9"` in Cargo.toml’s [dependencies] section is equivalent to `log = "^0.3.9"` which is equivalent to `log = ">=0.3.9 < 0.4.0"`. So if a project uses crates A with the above and crate B with `log = "0.3.12"`, then version 0.3.15 is acceptable to satisfy both dependencies. What would force an exact version is `log = "=0.3.9"`. (Note that the first equal sign is TOML syntax for key/value pairs, while the second one is part of the version specification string, inside the quotes.) See https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for compiling with MSVC in the near future
On 07/12/2018 00:08, Gijs Kruitbosch wrote: We're already making people install MSVS to get the relevant Windows SDKs (manually, not supported via ./mach bootstrap, and hopefully ticking the right boxes in the installer or they have to do it again until they do win at checkbox-golfing) We should fix that. Microsoft provides "Visual Studio Build Tools" which allows installing components such as those needed to build Firefox, without installing the whole IDE. It can be configured with the same command line arguments as "full" MSVC [1], in particular to select the components (checkboxes) and/or to run unattended (see "--passive" or "--quiet"). Component IDs are documented at [2]. I’ve used this for unattended install in a system image used for Servo CI [3]. Could `./mach bootstrap` do something similar? [1]: https://docs.microsoft.com/en-us/visualstudio/install/use-command-line-parameters-to-install-visual-studio?view=vs-2017 [2]: https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-build-tools?view=vs-2017 [3]: https://github.com/servo/servo/blob/3c19cd49e/etc/taskcluster/windows/first-boot.ps1#L71-L77 -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rust version required to build Firefox ESR versions
On 08/08/2018 17:04, Nathan Froyd wrote: On Wed, Aug 8, 2018 at 9:50 AM, Dirkjan Ochtman wrote: A related question: is there some place where I can follow along with plans relating to Rust upgrades for mozilla-central? As a Linux distribution packager, that might be useful information. (I remember seeing there was a Rust upgrade planned from 1.24.0 straight to 1.28.0, but couldn't find a reference when I recently went looking for it in Bugzilla.) There's https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox which appears to be reasonably current. This is the general policy, but there can be cases like 1.25 where a regression is deemed important enough to delay upgrading the Rust version used for Mozilla builds or increasing the minimum version requirement. You can search Bugzilla for "builders rust" and "require rust" to find bugs tracking those changes respectively, such as https://bugzilla.mozilla.org/show_bug.cgi?id=1450078 This configuration is in tree, changes are made first in central / nightly and then ride the trains. -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rust crate approval
On 27/06/18 19:45, Bobby Holley wrote: Hi Adam, At present, I think you should raise your questions with Nathan Froyd and Ehsan Akhgari, who are the owners of the C++/Rust usage module [1]. There has been some discussion around creating a Rust-in-Firefox Advisory Committee to handle questions like this, but it hasn't happened yet. In the mean time, I'm comfortable saying that the organization fully trusts Ehsan and Nathan to make intelligent decisions in this area, delegate to subject-area experts as appropriate, and consult the FTLM for any larger policy questions. Cheers, bholley It sounded to me that the question was not about Rust specifically (despite the subject line), but rather about licensing and code quality concerns around vendoring and using third-party code. In another instance where the language would be C++, do we have a policy for importing code like this? (I’m not at all questioning Ehsan’s and Nathan’s position to make this call anyway.) -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Is realloc() between bucket sizes worthwhile with jemalloc?
On 09/04/18 13:58, Henri Sivonen wrote: Specifically, is it actually useful that nsStringBuffer uses realloc() as opposed to malloc(), memcpy() with actually semantically filled amount and free()? Upon superficial code reading, it seems to me that currently changing the capacity of an nsA[C]STring might uselessly use realloc to copy data that's not semantically live data from the string's point of view and wouldn't really need to be preserved. Have I actually discovered useless copying or am I misunderstanding? This came up while discussing allocator APIs for Rust. (The outcome of those discussions is https://github.com/rust-lang/rust/pull/49669 and https://github.com/rust-lang/rust/issues/49668.) In our new APIs, we could have an additional parameter to realloc that says how many bytes need to be copied. The conclusion was to not add that because: * Not even the most exotic parts of jemalloc’s non-standard API have something like this, as far as I can tell. * For vectors, the two common realloc case seem to be pushing one item while already at capacity, and shrinking (perhaps after removing some items) to make the capacity fit the length exactly. In both cases, min(old size, new size) already matches the amount of meaningful bytes. However these APIs are not stable yet and we can still revisit this if there’s new information or arguments. -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: incremental compilation for opt Rust builds
On 05/04/18 14:19, Henri Sivonen wrote: Can we make a particular vendored crate (encoding_rs) use -O3 while the default for Rust code remains at -O2? There’s an accepted RFC for "per-crate profiles" but it’s not implemented yet: https://github.com/rust-lang/rust/issues/48683 -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster gecko builds with IceCC on Mac and Linux
On 17/01/18 19:27, Steve Fink wrote: Would it be possible that when I do an hg pull of mozilla-central or mozilla-inbound, I can also choose to download the object files from the most recent ancestor that had an automation build? (It could be a separate command, or ./mach pull.) They would go into a local ccache (or probably sccache?) directory. I believe that sccache already has support for Amazon S3. I don’t know if we already enable that for our CI infra. Once we do, I imagine we could make that store world-readable and configure local builds to use it. -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Pulsebot in #developers
On 04/11/17 17:21, Zibi Braniecki wrote: +1 The only thing I'd like to see from pulsebot on developers is: "26 commits have been merged from autoland into mozilla-central. List:http://...; Even that would probably be still be high traffic. A separate channel would allow interested people to opt-in. -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Default Rust optimization level decreased from 2 to 1
On 31/10/17 19:30, Randell Jesup wrote: Note that this means that profiles taken with local builds will be "off" compared to Nightly/etc, unless you rebuild with extra options. How much off? probably not a lot unless you're super-focused on Rust code, but that's just a guess. This was also the case before this change if you did not use --enable-release. LTO can make a significant difference. (I’ve seen -10% time in some microbenchmarks.) -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: upcoming requirements changes for Stylo builds + request for help
On 31/10/17 10:37, m...@fireburn.co.uk wrote: I'm curious as to why Clang is required, why doesn't GCC work? rust-bindgen uses libclang to parse C++ header files and generate corresponding Rust definitions. GCC can still be used for compiling. -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Visual Studio 2017 coming soon
On 30/10/17 15:05, smaug wrote: And let's be careful with the new C++ features, pretty please. We managed to not be careful when we started to use auto, or ranged-for or lambdas. I'd prefer to not fix more security critical bugs or memory leaks just because of fancy hip and cool language features ;) Careful how? How do new language features lead to security bugs? Is new compiler code not as well tested and could have miscompiles? Are specific features easy to misuse? -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Stylesheet wait timeout?
On 31/08/2017 19:45, Chris Peterson wrote: Gerv, do you have Stylo enabled? Even if you did not flip the pref (layout.css.servo.enabled), you might be in the Stylo experiment for Nightly users. Check about:support for "Stylo". I’ve also seen many more "flashes of unstyled content" than usual lately on Nigthly. I’ve reproduced it both with and without Stylo. -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: sccache as ccache
On 04/08/2017 13:02, Mike Hommey wrote: On Fri, Aug 04, 2017 at 11:25:52AM +0200, Simon Sapin wrote: `mk_add_options export RUSTC_WRAPPER=sccache` causes an error: It's `mk_add_options "export RUSTC_WRAPPER=sccache"`. That worked, thanks! I now have: ac_add_options --with-ccache=/usr/bin/ccache mk_add_options "export CCACHE_PREFIX=icecc" mk_add_options "export RUSTC_WRAPPER=sccache" mk_add_options MOZ_MAKE_FLAGS="-j100" -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: sccache as ccache
On 26/07/2017 19:22, Ted Mielczarek wrote:
I’ve ended up keeping "classic" ccache for C and C++ code and adding
'export RUSTC_WRAPPER=sccache' to my mach wrapper script in order to use
sccache for Rust code. (Having this line with or without 'export' in
.mozconfig did not appear to do anything. Can mozconfig set arbitrary
environment variables?)
No, mozconfig variable setting is sort of restricted. Bare variable
assignments (with or without export) are evaluated in the context of
configure, but don't survive to the Makefile environment. If you write
it as `mk_add_options export RUSTC_WRAPPER=sccache` that ought to work,
since that will be set as an exported Makefile variable, meaning it will
be set in the environment for commands executed by make.
`mk_add_options export RUSTC_WRAPPER=sccache` causes an error:
ValueError: dictionary update sequence element #1 has length 1; 2 is
required
File "/home/simon/gecko/python/mozbuild/mozbuild/base.py", line 342,
in resolve_config_guess
make_extra = dict(m.split('=', 1) for m in make_extra)
When I removed `export` the build ran normally but didn’t use sccache.
What *did* work is mk_add_options MOZ_MAKE_FLAGS="RUSTC_WRAPPER=sccache"
I also had mk_add_options MOZ_MAKE_FLAGS="-j100" to make icecc
effective, but when specifying both separately only one would take effect.
Overall, I ended up with this:
ac_add_options --with-ccache=/usr/bin/ccache
mk_add_options MOZ_MAKE_FLAGS="-j100 RUSTC_WRAPPER=sccache"
CC="/usr/lib/icecc/bin/cc"
CXX="/usr/lib/icecc/bin/c++"
--
Simon Sapin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: sccache as ccache
On 26/07/2017 15:05, Ted Mielczarek wrote: ac_add_options --with-ccache=sccache When used together with icecc, this appears to force all jobs to run locally which makes icecc pointless. I’ve ended up keeping "classic" ccache for C and C++ code and adding 'export RUSTC_WRAPPER=sccache' to my mach wrapper script in order to use sccache for Rust code. (Having this line with or without 'export' in .mozconfig did not appear to do anything. Can mozconfig set arbitrary environment variables?) -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: `mach cargo check` now available
On 06/07/2017 03:18, Nathan Froyd wrote: Cargo recently added a subcommand, `cargo check`, to perform type checking of Rust crates without the additional step of code generation. As code generation tends to dominate Rust compilation times, `cargo check` speeds up the edit-borrow checker-bewilderment cycle. This command is now available for toplevel crates (gkrust, gkrust-gtest, geckodriver, and mozjs_sys) via the `mach cargo check` command. You can run: $ mach cargo check which checks gkrust (i.e. everything that goes into libxul). You can check other crates: $ mach cargo check gkrust-gtest or even multiple crates: $ mach cargo check gkrust gkrust-gtest If you have ideas on how this command could be improved, please bugs in Core :: Build Config. Nice, thank you! Would it make sense to allow arbitrary Cargo sub-commands? In Servo I end up using `mach cargo update` for manipulating Cargo.lock, `mach cargo rustc` for passing debugging options to the compiler, etc. -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: New character encoding conversion API
On 15/06/2017 12:32, Henri Sivonen wrote: * We don't have third-party crates in m-c that (unconditionally) require rust-encoding. However, if you need to import such a crate and it's infeasible to make it use encoding_rs directly, please do not vendor rust-encoding into the tree. Vendoring rust-encoding into the tree would bring in another set of lookup tables, which encoding_rs is specifically trying to avoid. I have a compatibily shim ready in case the need to vendor rust-encoding-dependent crates arises. https://github.com/hsivonen/encoding_rs_compat I’ve recently made the rust-encoding dependency in Tendril optional and disabled by default. (Tendril is the refcounted buffer type used in html5ever, Servo’s HTML parser.) So this won’t be an issue if we ever want to use html5ever in m-c. I’ve also removed the "parse from bytes" (as opposed to Unicode ) API from html5ever because it couldn’t support interrupting parsing on correctly. When adding something again we’ll do it using encoding_rs. -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Consensus check: Asking the Unicode Technical Committee to revert their decision to change the preferred UTF-8 error handling
On 07/06/17 12:45, Henri Sivonen wrote: It seems to me that this episode has revealed that the Unicode Consortium doesn't have an objective way to deem one way of doing things as clearly the best one, so it seems to me that there's a better chance of Unicode toning down the language expresses a preference to make it a lesser preference (by calling it something lesser than "best practice" going forward) and it seems to me that there wouldn't be Unicode-level agreement of elevating the old or the new preference to a requirement on the Unicode level. The WHATWG spec would continue to make the old Unicode preference required, so I think it's an OK outcome for the requirement to live in the WHATWG spec and Unicode preferring the same thing (i.e. reverting the change to the preference) in weaker terms than so far. Letting it be this way wouldn't invite objections from non-Web-oriented implementors who implement something else that's currently within Unicode compliance and who don't want to change any code. I agree with Henri on the original issue. I also agree that it’s probably easier to not also try to make this a strong requirement. When you ask for two things at the same time it’s easy for someone to respond to / argue about one and forget the other, deliberately or not. -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Editing vendored crates
On 27/02/17 19:47, Simon Sapin wrote: On 27/02/17 19:30, Henri Sivonen wrote: On Mon, Feb 27, 2017 at 8:00 PM, Bobby Holley <bobbyhol...@gmail.com> wrote: FWIW, |cargo tree| is a very helpful tool to figure out who's pulling in a crate. Thanks, but what I'm trying to figure out isn't whose pulling it in (the style crate is) but whether it is actually used beyond an always-None Option in a way that would result in the data tables actually getting included in the build as oppose to (hopefully) getting discarded by LTO. (Motivation: If we are taking on the data tables, I want to argue that we should include encoding_rs instead even before the "replace uconv with encoding_rs" step is done.) As an aside, I have a plan to remove rust-encoding entirely from Servo (including Stylo) and use encoding_rs instead. But doing this the way I want to has a number of prerequisites, and I’d prefer to switch everything at once to avoid having both in the build. At the moment I’m prioritizing other Stylo-related work, but I’m confident it’ll happen before we start shipping Stylo. Henri, you’re correct that the parts of the style crate using rust-encoding are never used in Stylo. Gecko always passes UTF-8 input (after decoding on the C++ side I assume) to Stylo for parsing stylesheets, which we unsafely view as with std::str::from_utf8_unchecked. I’ve submitted https://github.com/servo/servo/pull/15993 to remove the rust-encoding dependency from stylo. This doesn’t need to wait on switching the rest of Servo. -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Is there a way to improve partial compilation times?
On 08/03/17 15:24, Ehsan Akhgari wrote: What we did in the Toronto office was walked to people who ran Linux on their desktop machines and installed the icecream server on their computer. I suggest you do the same in London. There is no need to wait for dedicated build machines. ;-) We’ve just started doing that in the Paris office. Just a few machines seem to be enough to get to the point of diminishing returns. Does that sound right? -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Editing vendored crates
On 27/02/17 19:30, Henri Sivonen wrote: On Mon, Feb 27, 2017 at 8:00 PM, Bobby Holley <bobbyhol...@gmail.com> wrote: FWIW, |cargo tree| is a very helpful tool to figure out who's pulling in a crate. Thanks, but what I'm trying to figure out isn't whose pulling it in (the style crate is) but whether it is actually used beyond an always-None Option in a way that would result in the data tables actually getting included in the build as oppose to (hopefully) getting discarded by LTO. (Motivation: If we are taking on the data tables, I want to argue that we should include encoding_rs instead even before the "replace uconv with encoding_rs" step is done.) As an aside, I have a plan to remove rust-encoding entirely from Servo (including Stylo) and use encoding_rs instead. But doing this the way I want to has a number of prerequisites, and I’d prefer to switch everything at once to avoid having both in the build. At the moment I’m prioritizing other Stylo-related work, but I’m confident it’ll happen before we start shipping Stylo. -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How to see which parts of Servo are in use?
On 13/02/17 13:49, Henri Sivonen wrote: A search like https://searchfox.org/mozilla-central/search?q=EncodingRef finds a bunch of stuff that is under servo/components/script/. I gather we don't use that part of Servo in Quantum. Correct? Correct. How does one see which parts of servo/ are actually in use in Quantum? I just came up with this: % cargo tree --manifest-path toolkit/library/rust/Cargo.toml \ --all-features --no-indent --all|grep -o '(.*)'|sort -u (file:///home/simon/gecko/gfx/webrender) (file:///home/simon/gecko/gfx/webrender_bindings) (file:///home/simon/gecko/gfx/webrender_traits) (file:///home/simon/gecko/media/libstagefright/binding/mp4parse) (file:///home/simon/gecko/media/libstagefright/binding/mp4parse_capi) (file:///home/simon/gecko/netwerk/base/rust-url-capi) (file:///home/simon/gecko/servo/components/config) (file:///home/simon/gecko/servo/components/geometry) (file:///home/simon/gecko/servo/components/selectors) (file:///home/simon/gecko/servo/components/style) (file:///home/simon/gecko/servo/components/style/gecko_bindings/nsstring_vendor) (file:///home/simon/gecko/servo/components/style_traits) (file:///home/simon/gecko/servo/components/url) (file:///home/simon/gecko/servo/ports/geckolib) (file:///home/simon/gecko/toolkit/library/rust) (file:///home/simon/gecko/toolkit/library/rust/shared) (file:///home/simon/gecko/xpcom/rust/nsstring) If I got it right, these are all the Rust crates not pulled from crates.io that can be enabled to be compiled in in libxul. I think there’s a couple more for unit tests. (Note that "cargo tree" is separate from the rest of Cargo. You need to run "cargo install cargo-tree" and add ~/.cargo/bin to $PATH to get it.) Is there a way to filter out the unused parts on Searchfox? I don’t know. -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rust required to build Gecko
On 16/12/16 17:27, Ben Kelly wrote: I tried ./mach bootstrap on a fresh m-c this morning and got: Will try to install Rust. Downloading rustup-init... Error running mach: ['bootstrap'] The error occurred in code that was called by the mach command. This is either a bug in the called code itself or in the way that mach is calling it. You should consider filing a bug for this issue. If filing a bug, please include the full output of mach, including this error message. The details of the failure are as follows: URLError: What Python version do you have? (Run 'python --version') If it’s not the latest, can you update it? Try modifying python/mozboot/mozboot/rust.py to replace this line: RUSTUP_URL_BASE = 'https://static.rust-lang.org/rustup' by this line: RUSTUP_URL_BASE = 'https://static-rust-lang-org.s3.amazonaws.com/rustup' If that fixes the issue for you, it’s likely that your Python version does not support SSL SNI. -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: CSS Grid
On 16/11/16 01:40, Mats Palmgren wrote: Note about the 'subgrid' feature: We will *not* support the subgrid feature of CSS Grid in this first release. This feature is marked as "at-risk" in the spec and thus not needed for spec compliance. (Chrome is likewise not going to support subgrid in their first release.) I don’t have a strong opinion on subgrid specifically, and other arguments can be made, but I’d like to note: It is marked at-risk in the spec *because* several vendors had said they might not support it at first. So using this to justify not supporting it is a circular argument. -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: atom-shell is electron, what's gecko-shell would be?
On 16/06/15 17:59, Yonggang Luo wrote: I am looking forward to it. Prism? https://mozillalabs.com/en-US/prism/ -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using rust in Gecko. rust-url compatibility
On 01/05/15 00:42, Jet Villegas wrote: I wonder why we'd allow *any* parsing differences here? If we're also signing up to increase spec compliance as part of the rewrite, that should be called out as an explicit goal rust-url (https://github.com/servo/rust-url/) was originally written per the URL standard (https://url.spec.whatwg.org/) for Servo and the rest of the Rust ecosystem (replacing a something that was at the time part of the Rust standard library). The idea to use it in Gecko only came up recently. Where rust-url diverges from Gecko’s currently behavior, I’d rather consider case by case which should be changed (including possibly changing the spec) rather than systematically align with what Gecko happens to be doing. On 01/05/15 19:58, Gregory Szorc wrote: Shipping *any* Rust component as part of Gecko is already going to be a long and arduous task. I think it makes sense for the first Rust component in Gecko to be a drop-in, behavior identical replacement. i.e. don't bloat scope to include behavior changes that could jeopardize the deliverable. All true. It would be really unfortunate if we did all this Rust preparation work only to have the feature utilizing it backed out because of behavior differences. I expect Rust support in the build system to land separately from any code that uses it: https://bugzilla.mozilla.org/show_bug.cgi?id=oxidation But this is a very high-level observation. I know others spent a lot of time figuring out what to Rust-ify first and URL parsing was eventually chosen. If you say it is the least risky part of Gecko to swap out, I trust that assessment. URL parsing will not necessarily be the first Rust component to land. There is also work going on on MP4 parsing (https://bugzilla.mozilla.org/show_bug.cgi?id=1161350), and we’ve discussed BMP decoding as a low-risk component. On 05/05/15 21:55, Jonas Sicking wrote: Will this affect our ability to make nsStandardURL thread-safe? I don’t know of any thread safety issue in rust-url. It’s only doing string manipulation. On 06/05/15 04:07, Boris Zbarsky wrote: Note that performance has been a recurring problem in our current URI code. It's a bit (10%) slower than Chrome's, but about 2x slower than Safari's, and shows up a good bit in profiles. I haven’t looked into rust-url’s performance at all. This means two things: it’s probably not great right now, but it can probably be improved. For example, the Url struct currently contains a vector of strings for the path and a some more strings for other URL components. Each (non-empty) string is a memory allocation. It would probably be more efficient to have a single string with some indices delimiting the components. Some of this may be due to XPCOM strings, of course, and the fact that there's a lot of back-and-forth between UTF-16 and UTF-8 involved, but some is just the way the URI parsers work. rust-url uses the String type from the Rust standard library, which is based on UTF-8. If conversions to/from UTF-16 turn out to take significant time I could imagine making the parsing code generic over the string representation. -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
