Re: [dev-servo] ./mach build vs. cargo build

[Matt Brubeck]

We can set rustflags in the `[build]` section of .cargo/config:

https://doc.rust-lang.org/cargo/reference/config.html

On Wed, Apr 4, 2018 at 6:47 AM, Manish Goregaokar 
wrote:

> IMO those reasons do not apply to toplevel flags; and given that Cargo
> profiles are a thing we really should have a rustflags key there. I've
> always had trouble with getting IDEs working with servo because of this.
>
> -Manish Goregaokar
>
> On Wed, Apr 4, 2018 at 6:12 AM, Lars Bergstrom 
> wrote:
>
> > Cargo has traditionally not wanted to add full support for arbitrary
> > RUSTFLAGS, for reasonable reasons:
> > https://github.com/rust-lang/cargo/issues/60#issuecomment-51705597
> >
> > What we've done in the past is for each flag that we needed exposed
> opened
> > a specific Issue or PR to Cargo to have just that one feature either
> added
> > to the allowed flags list or as a new toplevel item in the profile. I'd
> at
> > least check those out first before regressing link performance
> > significantly or adding a local development footgun (only checking
> certain
> > warnings in CI and requiring people to take an extra trip through the
> homu
> > queue to find out things they could have tested locally).
> >
> > FWIW, I agree totally - any reasonable IDE is not going to respect usage
> of
> > `mach` to set env vars and we'd LOVE to have all this stuff in Cargo
> > configs. The use of RUSTFLAGS in mach has traditionally been a staging
> area
> > for features not yet turned on by default in rustc or not yet supported
> for
> > configuration in cargo (especially in the dark old days of cross
> > compilation woes - much better now!).
> > - Lars
> >
> >
> > On Tue, Apr 3, 2018 at 4:44 PM, Simon Sapin 
> wrote:
> >
> > > 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
> > >
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> >
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Standalone NDK concerns?

[Matt Brubeck]

We used to use a standalone toolchain:
https://github.com/servo/servo/wiki/Building-for-Android/16f371c68d7da393d178646dcb18dac2c2ea8826

but this changed back in 2016; I'm not clear on the exact reasons:
https://github.com/servo/servo/pull/13945

On Tue, Mar 6, 2018 at 4:46 PM, Josh Bowman-Matthews 
wrote:

> I'm trying to update our NDK from 12b to a more modern 16b. Since the
> default NDK installation is so convoluted in terms of include/lib/bin
> directories, I'm giving the standalone SDK a shot and it appears to be much
> more straightforward to integrate into the build. Is there any reason we
> haven't required the use of standalone SDKs before?
>
> Cheers,
> Josh
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Servo tree closed; testing issues

[Matt Brubeck]

This is now fixed and the Servo tree is open again.

On Tue, Jan 24, 2017 at 11:21 AM, Matt Brubeck <mbrub...@mozilla.com> wrote:

> Please do not approve any PRs in the servo/servo repo until #15164 is
> merged.
>
> #15064 accidentally caused our test automation to silently fail to run
> most of the CSS and WPT tests.  This means that our builds will stay green
> and PRs will land even if they contain changes that break these tests.
>
> https://github.com/servo/servo/pull/15164 is the change to revert this
> breakage, along with some other PRs that landed in the meantime that may
> have caused new test failures.
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Servo tree closed; testing issues

[Matt Brubeck]

Please do not approve any PRs in the servo/servo repo until #15164 is
merged.

#15064 accidentally caused our test automation to silently fail to run most
of the CSS and WPT tests.  This means that our builds will stay green and
PRs will land even if they contain changes that break these tests.

https://github.com/servo/servo/pull/15164 is the change to revert this
breakage, along with some other PRs that landed in the meantime that may
have caused new test failures.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Servo without Bluetooth

[Matt Brubeck]

If the `bluetooth` feature is enabled by default, then you will also need
to pass `--no-default-features` to the `cargo build` command (and then add
back any features that you *do* want).  We don't currently have a way to do
this through `mach build` but it would be easy to add by adding a new
argument to the command here:

https://github.com/servo/servo/blob/cba47174e0b104ddb701c5b733a06509a21174dc/python/servo/build_commands.py#L116-L151

On Wed, Jun 1, 2016 at 1:53 AM, Manish Goregaokar 
wrote:

> It should be net/device/bluetooth. For some reason the crate is imported as
> "device" instead of "devices" in net
>
> -Manish Goregaokar
>
> On Wed, Jun 1, 2016 at 1:29 PM, Dirkjan Ochtman 
> wrote:
>
> > On Tue, May 31, 2016 at 4:51 PM, Simon Sapin 
> wrote:
> > >> 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"]
> >
> > FWIW, with this diff:
> >
> > djc@dochtman-dev servo $ git diff
> > diff --git a/components/servo/Cargo.toml b/components/servo/Cargo.toml
> > index a0ff462..3380450 100644
> > --- a/components/servo/Cargo.toml
> > +++ b/components/servo/Cargo.toml
> > @@ -23,6 +23,7 @@ default = ["glutin_app", "webdriver", "max_log_level"]
> >  max_log_level = ["log/release_max_level_info"]
> >  webdriver = ["webdriver_server"]
> >  energy-profiling = ["profile_traits/energy-profiling"]
> > +bluetooth = ["net/devices/bluetooth"]
> >
> >  [profile.release]
> >  opt-level = 3
> >
> > I get an error:
> >
> > djc@dochtman-dev servo $ ./mach build --dev --features ""
> > error: Package `net v0.0.1
> > (file:///home/djc/src/servo/components/net)` does not have these
> > features: `devices`
> > Build completed in 0:00:00
> >
> > So not sure that actually works recursively?
> >
> > I think having positive features ("bluetooth") is better than having
> > negative features ("no-bluetooth"), so I'm checking whether I can get
> > that to work cleanly. It looks like cargo doesn't really support it
> > cleanly...
> >
> > Cheers,
> >
> > Dirkjan
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> >
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Asynchronous image loading in layout

[Matt Brubeck]

In ancient double-digit-issue times, our forefather brson suggested that we
could store some sort of promise or future in the display list, for images
pending load:
https://github.com/servo/servo/issues/43

Would something like this work?  It might make sense to store the futures
in the flow tree instead of (or in addition to?) the display list.  The
future would contain sort of identifier that corresponds to an image
request.  Each time layout runs, any "image future" fragment would check to
see if its request was now finished.  When any image load completes, we
could trigger a layout pass that triggers these checks.  (This could use a
new RestyleDamage flag, or maybe just make sure these fragments have an
existing flag like REPAINT set for as long as they contain an unfulfilled
future.)
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Intermittent shutdown panics on Mac

[Matt Brubeck]

We have a new intermittent failure that has been wreaking havoc on our CI
all day.  It's an intermittent shutdown panic in the script thread,
possibly only on the Mac builders:

https://github.com/servo/servo/issues/11059

Our usual trick of disabling tests won't work, since it seems to happen
indiscriminately across all tests. If anyone has any ideas for fixing the
bug or backing out patches that might have introduced it, please speak up.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Moving away from merge commits

[Matt Brubeck]

On Wed, Apr 27, 2016 at 7:25 AM, Manish Goregaokar 
wrote:

> Another reason I prefer merge commits is that it becomes very easy to hunt
> down which PR caused a bug (after using blame or pickaxe).


We could potentially also make homu add this info (PR# and head commit) to
the commit message or headers when it pushes a PR to auto.  If it's
rebasing, then it's going to be rewriting commits anyways, so this
shouldn't cause any additional problems.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Cargo top-level overrides

[Matt Brubeck]

Cargo recently gained the ability for the top-level crate (e.g. servo) to
override any crate in the dependency tree. This is similar to the "paths"
key in .cargo/config, but designed for longer-term shared use (rather than
just for local development):

https://github.com/rust-lang/cargo/pull/2385

This means that if we need to fork a crate for any reason, we don't need to
rename it or modify all of the crates that depend on it.  Instead we can
just add one new `[replace]` entry in the top-level Cargo.toml, pointing to
our forked repo.

For example, we currently have a fork of glutin.  This required us to
publish a new package on crates.io and modify our skia crate to depend on
`servo-glutin` instead of `glutin`. This is a problem for anyone who wants
to use our skia crate with regular glutin.  With top-level overrides, our
servo-skia could depend on regular glutin, but servo could replace that
dependency with our forked glutin.  Then both Servo and non-Servo projects
could share the same skia bindings easily.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Fwd: Firefox.html: rebuilding Firefox UI in HTML

[Matt Brubeck]

Paul Rouget started an experimental re-implementation of the Firefox 
desktop UI in HTML instead of XUL, using the Browser API (iframe 
mozbrowser) from Firefox OS.  One of his motivations was to build a 
browser UI that could someday be powered by Servo.  See his email below, 
or read the full thread at:

https://mail.mozilla.org/pipermail/firefox-dev/2014-December/002510.html


 Forwarded Message 
Subject:Firefox.html: rebuilding Firefox UI in HTML
Date:   Tue, 9 Dec 2014 17:43:08 +0100
From:   Paul Rouget p...@mozilla.com
To: firefox-...@mozilla.org



Firefox.html is an experiment, a proof of concept: trying to
re-implement the Firefox UI in HTML, as an app (like FxOS apps).

Code, builds, screenshots: https://github.com/paulrouget/firefox.html

We are working hard on making HTML fast and rich enough to build
a whole operating system (Firefox OS) and a browser (Firefox OS' browser).
With a UI in HTML leveraging the Browser API, we could drop XUL and close
the gap between B2G and Firefox Desktop. And eventually be able to
render Firefox Desktop with Servo. And maybe, one day, host the
Firefox UI online (trusted app?).

The only purpose of Firefox.html, at this stage, is to yield a
discussion about the future of XUL.

I'm fully aware of the massive amount work required to ever reach
the quality of Firefox Desktop (we're talking about years of work),
but I thought that we might want to talk about it.

What do you think? Is it something we want to try? Or maybe it's
too early, or maybe we don't want to use HTML for this, use native
toolkits, or just keep XUL.

~~~

Some techical details:

  - code is ugly. Don't build stuff on top of that. It's just an experiment.
  - The runtime is just Firefox Desktop with some tweaks (mostly ajusting
  how apps are handled on Desktop).
  - The app (app://browser.gaiamobile.org/manifest.webapp) is loaded in a 
iframe.
  - The only remaining XUL piece is the top level window. It's a blank window
  that position the iframe over the window controls, to allow HTML to draw
  in the titlebar.
  - The app itself uses the Browser API.

-- Paul
___
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev



___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Meeting notes 10/20 (work week agenda; intermittent failure troubles; inversion of control; sync script loading; document load tracking)

[Matt Brubeck]

On 10/20/2014 11:08 AM, Boris Zbarsky wrote:

I'm not sure I understand the sync script bit.

You don't want to block user interaction with the page while fetching 
a script.  You also don't want to block the parser tokenization 
prescan, preloads from that prescan, etc.


All that should be blocked is DOM construction from the parser.


We're probably blocking too much right now.  We'll need some follow-up 
work to optimize this, and also to make it use the correct fetch 
algorithm and support async/defer.

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] (Lack of) XML parser

[Matt Brubeck]

On 10/13/2014 09:26 PM, Simon Sapin wrote:

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.


I should note that most of the imprecision here is from my note-taking; 
the full discussion in the meeting was more detailed.

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Important Cargo fixes

[Matt Brubeck]

On 09/15/2014 12:26 AM, Simon Sapin wrote:

On 15/09/14 05:13, Matt Brubeck wrote:

Today's Cargo nightly contains some recent fixes  [...]


Which version is that? I just updated to 3f6af3d 2014-09-13, which may 
or may not be today’s because of 
https://github.com/rust-lang/rust/issues/1664


Yes, 3f6af3d includes the fixes.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Important Cargo fixes

[Matt Brubeck]

Today's Cargo nightly contains some recent fixes to make it rebuild the 
correct crates after changes to non-Rust source files, like the codegen 
input files in Servo's |`script/dom/bindings`| and |`style/properties`| 
crates.


To update to the newest Cargo nightly, run this command in your Servo 
directory:


|./mach bootstrap-cargo -f|

(If you have several clones of the Servo repo, you'll need to run it in 
each of them.)


Technical details of the fixes, if you're curious:

 * https://github.com/rust-lang/cargo/pull/561
 * https://github.com/rust-lang/cargo/pull/563

In other build system news, mach has gained some new abilities in the 
last few days:


 *

   |`./mach clean`| (shorthand for |`mach cargo clean`|)

 *

   |`./mach rustc args ...`| (run any |rustc| command using Servo's
   Rust snapshot)

 *

   |`./mach test-ref test-name` |(run reftests whose names match the
   given pattern - also works with the other testing commands like
   |`test-content`|)

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo