Re: Reminder: Planned Taskcluster migration this weekend (Nov 9)

2019-11-04 Thread Simon Sapin

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?

2019-10-29 Thread Simon Sapin

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?

2019-08-23 Thread Simon Sapin

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?

2019-08-22 Thread Simon Sapin

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: Must we rebuild all our rust code constantly?

2019-08-19 Thread Simon Sapin

On 20/08/2019 00:20, Simon Sapin wrote:

It would be good to have steps to reproduce the issue. Then Cargo’s
debug logs should show what it thinks is out of date.


Running with a CARGO_LOG=cargo::core::compiler::fingerprint environment 
variable should show some relevant information.


--
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?

2019-08-19 Thread Simon Sapin

On 19/08/2019 22:55, Dave Townsend wrote:

For a couple of weeks now I've seen that any attempt to build Firefox, even
incremental builds seem to rebuild an awful lot of rust code. I found this
in the source which seems to suggest why:
https://searchfox.org/mozilla-central/source/config/makefiles/rust.mk#238.
But, this means that now an incremental build with a couple of code change
that have no impact on rust is taking upwards of 4 minutes to complete in
comparison to around 40 seconds, and the log file is full of cargo output.
I've heard similar comments from other developers.

This is a pretty big increase in the time to compile and test and is really
slowing down my work. Is there any way we can avoid this?


Running `cargo build` every time makes sense to me, for the reasons 
given in that makefile comment. However when everything is already up to 
date it should finish quickly (single-digit seconds or less) after 
printing something like:



Finished dev [unoptimized + debuginfo] target(s) in 1.24s


… and without printing any line that starts with "Compiling".


It would be good to have steps to reproduce the issue. Then Cargo’s 
debug logs should show what it thinks is out of date. (But I don’t 
remember at hand the exact invocation to obtain them, and they can be 
kinda hard to read.)


--
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

2019-07-19 Thread Simon Sapin

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?

2019-03-15 Thread Simon Sapin

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

2018-12-07 Thread Simon Sapin

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

2018-08-12 Thread Simon Sapin

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

2018-06-27 Thread Simon Sapin

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?

2018-04-10 Thread Simon Sapin

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

2018-04-09 Thread Simon Sapin

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

2018-01-17 Thread Simon Sapin

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

2017-11-04 Thread Simon Sapin

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

2017-10-31 Thread Simon Sapin

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

2017-10-31 Thread Simon Sapin

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

2017-10-30 Thread Simon Sapin

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?

2017-08-31 Thread Simon Sapin

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

2017-08-04 Thread Simon Sapin

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

2017-08-04 Thread Simon Sapin

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

2017-07-26 Thread Simon Sapin

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

2017-07-06 Thread Simon Sapin

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

2017-06-15 Thread Simon Sapin

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

2017-06-07 Thread Simon Sapin

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

2017-03-16 Thread Simon Sapin

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?

2017-03-08 Thread Simon Sapin

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

2017-02-27 Thread Simon Sapin

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?

2017-02-13 Thread Simon Sapin

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

2016-12-16 Thread Simon Sapin

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

2016-11-15 Thread Simon Sapin

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?

2015-06-16 Thread Simon Sapin

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

2015-05-06 Thread Simon Sapin

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