Re: [dev-servo] Rustfmt now checked on CI

[Keith Yeung]

Woohoo! Great work everyone!
On Wed, Nov 7, 2018 at 11:22 AM Josh Bowman-Matthews
 wrote:
>
> Thank you for all your help in formatting the existing code and enabling
> rustfmt in CI! I'm very pleased that we've adopted rustfmt and that we
> now have consistent formatting with the rest of the Rust ecosystem.
>
> Cheers,
> Josh
>
> On 11/7/18 1:51 PM, Pyfisch wrote:
> > Hi Everyone,
> >
> > Servo source code is now formatted with rustfmt [1]. Style checking is
> > part of ./mach test-tidy and enforced on CI. To automatically format
> > your code run ./mach fmt before commiting. Import order was changed but
> > ./mach fmt will fix
> > any issues. Please ask any questions you may have.
> >
> > Regards
> > Pyfisch
> >
> > [1]: https://github.com/servo/servo/pull/22126
> >
> >
>
> ___
> 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] Outstanding concerns with WPT platform?

[Keith Yeung]

Following on your 3rd point about reducing code patterns that lead to
TIMEOUTs, I'm wondering if the test harness has a function that allows you
to fail the WPT entirely, without running the remaining tests?

Here's an example of what I mean: suppose this function is named fail(),
and we have the following test:

test(function() {
if (failingCondition)
fail();
else
// continue test as normal
}, "test 1");
test(function() { ... }, "test 2");

Test 2 would never be run if the failingCondition is true, and all
subsequent tests after test 2 would also not be run, should there be any.

- Keith


On Wed, Sep 26, 2018, 8:22 AM Josh Bowman-Matthews 
wrote:

> I'll be meeting with various WPT stakeholders at the Web Engines
> Hackfest next week. Do we have any thoughts or concerns about the future
> of WPT as a platform to drive Servo's web compatibility and testing web
> features across all browsers? Are there any web platform features that
> are still hard to test that we should be talking about? Are there any
> concerns about the quality of tests, or feature sets that Servo does not
> support that we should discuss rewriting in existing tests?
>
> On my list right now:
> * PRs can merge upstream that fail the lint without being detected; this
> breaks our nightly syncing
> (https://github.com/servo/servo/pull/21814#issuecomment-424737163 and
> https://github.com/web-platform-tests/wpt/issues/13222).
> * Unnecessary use of the named window getter in tests, which Servo does
> not support and is more complex than it sounds
> * Reduce code patterns in tests that lead to TIMEOUT rather than ERROR
> when a feature is unsupported
>
> Please let me know if there is anything I'm missing!
>
> 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] Incremental compilation and other compile time tricks

[Keith Yeung]

This is a great write-up on the details of our compilation process, thanks
Simon!

> There is a risk that preserved files could be left by a previous builds
in a broken state, leading to failures that only happen on CI. We’re
monitoring this and will consider reverting this change it this turns out
to be a problem.

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.

Keith

On Fri, Mar 31, 2017 at 10:43 AM, Simon Sapin  wrote:

> If you build Servo a lot you may have noticed that compilation times have
> improved over the last few months. This is combination of multiple factors.
>
>
> # Compiler optimization
>
> Plain old optimization of the compiler’s code. Sometimes a rustup makes
> things a bit faster without us changing anything else. For example:
>
> https://blog.mozilla.org/nnethercote/2016/10/14/how-to-speed
> -up-the-rust-compiler/
> https://blog.mozilla.org/nnethercote/2016/11/23/how-to-speed
> -up-the-rust-compiler-some-more/
>
>
> # Limited parallelism
>
> Cargo can compile multiple crates at the same time, but a crate can only
> start after its dependencies are done. And in the default configuration,
> compiling one crate only uses one CPU core/thread. Servo’s dependency graph
> tends to be narrow near the end, in particular with the script crate that
> takes a lot of time to compile. This limits the overall available
> parallelism.
>
>
> # Hardware
>
> CPUs with many cores tend to make each core slower, to manage heat.
> Counter-intuitively this can make then worse for compiling Servo. If you’re
> spending (your employer’s) money on hardware, I recommend the highest
> single-thread performance you can find even if this means fewer cores.
> Currently, this is probably Intel’s i7-7700K. (4 cores, 8 threads, 4.2 GHz,
> easy to overclock to 4.6 GHz.)
>
>
> # Codegen units
>
> Compilation of a crate can be roughly split into two phases: analysis and
> code generation. The former includes parsing, type checking, borrow
> checking, etc. The latter is mostly LLVM.
>
> rustc added a feature to get parallelism in code generation. With `rustc
> -C codegen-units=4` for example, the code to generate is split into four
> parts that are given separately to LLVM in threads that run in parallel.
>
> This makes compilation faster but has a runtime cost: LLVM’s optimizer
> only sees one unit at a time, which reduces opportunities for inlining and
> other compile-time optimizations.
>
> Also, only code generation is parallelized, the analysis phase still runs
> on a single thread. So Amdahl’s law limits how much speed improvement we
> can get with this.
>
> In Servo we’ve enabled codegen-units=4 by default in debug mode, but not
> in release mode.
>
> https://github.com/servo/servo/pull/14995
>
>
> # LLVM assertions
>
> When compiling LLVM (and so when compiling rustc) we can choose to enable
> LLVM assertions. There assertions can help find bugs (in LLVM or in rustc),
> but they have a runtime cost. (LLVM’s runtime, which is Servo’s compile
> time.) This cost can be significant, especially in release mode (where
> LLVM’s optimizer does a lot of work).
>
> Official Rust builds have LLVM assertions enabled in Rust Nightly (to help
> catch bug), but not in the beta or stable release channels.
>
> At our request, the Rust team started making alternative Rust Nightly
> builds without LLVM assertions, for some platforms. We’re now using them by
> default, except for some of our Continuous Integration builders (in order
> to preserve some of the coverage).
>
> https://github.com/rust-lang/rust/pull/39754
> https://github.com/servo/servo/pull/15559
> https://github.com/servo/servo/pull/15564
>
>
> # 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
>
> Follow-up work wanted: add a mach sub-command or option to do this with
> geckolib.
>
> (It would also be nice for rustc to have a mode to write both metadata and
> full build, and signal somehow as soon as the former is ready; and have
> Cargo start building dependents on that signal while codegen for the
> dependencies is still running, increasing overall parallelism.)
>
>
> #

Re: [dev-servo] Android support

[Keith Yeung]

Have you also looked at https://github.com/paulrouget/servoshell/projects/2
? I believe that some issues listed there are being addressed, maybe it
also addresses the issues arising from supporting use case 3-5.

On Tue, Mar 7, 2017 at 3:15 PM, Michael Howell 
wrote:

> Would the Chrome Embedding Framework (CEF) work help at all?
>
> On Tue, Mar 7, 2017 at 4:11 PM Fabrice Desré  wrote:
>
> >   Hi all,
> >
> > I want to start a discussion about Servo's Android support. The current
> > state is quite basic and doesn't provide what we need to cover several
> > interesting use cases.
> >
> > So far I have identified these:
> > 1- Full screen app (games, VR).
> > 2- Browser with a pure html "chrome" like browser.html.
> > 3- Browser with a native (java) chrome.
> > 4- Reusable WebView (ServoView !) for other apps to embed.
> > 5- Providing a CustomTab implementation (Chrome and Fennec support that).
> >
> > 1- and 2- are the only cases we can cover with the current platform
> > code. However I believe that we need more flexibility and that the key
> > here is to implement the ServoView, as it is a dependency for all the
> > other cases.
> >
> > ServoView would expose an API as close as possible to
> > https://developer.android.com/reference/android/webkit/WebView.html to
> > ease reusability in the Android community.
> >
> > This ties into the overall embedding story, which I discussed with Paul.
> > We have alignment there, relying mostly on 2 aspects:
> > - the embedding support provided by libservo will be low level enough to
> > let us build the ServoView and CustomTabs on top of it. Expect a lot of
> > JNI fun!
> > - glutin may not be something we want to keep using. I haven't looked in
> > details yet but glutin may be too high level an opinionated for us in
> > this context (eg. can glutin let us display several ServoViews?).
> >
> > So my current plan of action is to verify whether glutin is suitable or
> > not on Android, fix that if needed and then start on a ServoView
> > implementation.
> >
> > Thoughts?
> >
> > --
> > Fabrice Desré
> > Emerging Technologies
> > Mozilla Corporation
> > ___
> > 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] Mentors needed (on IRC)

[Keith Yeung]

I happen to sleep pretty late, and actually write and read Traditional
Chinese, so I'm quite likely to be on that time! Otherwise, I think Ms2ger,
Manishearth, nox and waffles will be the people who are compatible with the
GMT+8 timezone.

On Tue, Aug 23, 2016 at 8:39 AM, Jack Moffitt  wrote:

> Also, if anyone has new E-easy's, it would be good to get them filed
> before this event so that the group has a reasonable amount to work
> on.
>
> jack.
>
> On Tue, Aug 23, 2016 at 3:13 AM, Shing Lyu  wrote:
> > Hi,
> >
> > I'll attend a bootcamp called "Taiwan Code Sprint", which is aimed to
> > introducing newcomers to contributing to open source projects, There will
> > be roughly 4~6 people working on Servo E-easy bugs on Aug 27 & 28, Taipei
> > Time (GMT+8).
> >
> > Since I can't be there all day. We'd appreciate if you can drop by the
> IRC
> > and Github issue/PRs more frequently during that time.
> >
> > Also, if you have any material about contribution workflow, codebase
> > overview, project ideas, etc., please kindly let me know. Hopefully we
> can
> > have attract more contributors! Thanks!
> >
> >  - Shing Lyu | Mozilla Taipei
> > ___
> > 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] NCSU Student Project: Implement HTML5 form validation

[Keith Yeung]

Hi Arpit,

Just as a quick reminder, it's often a good idea to create a new feature
branch when trying to make a PR. You'll inadvertently need to rebase
against the changes in upstream master, so making a feature branch will
prevent weird issues from happening whilst you're rebasing.

Regards,
Keith

On Mon, Mar 21, 2016 at 3:27 PM, Arpit Tyagi  wrote:

> Hi Josh,
>
> I believe, we have completed the coding for the initial steps, however I am
> not sure how can I test these changes. Could you please advise how can I
> test these changes.
>
> I will also appreciate if you could have a quick look on code changes in
> git (https://github.com/tyagiarpit/servo).
>
> Cheers!!
> Arpit
>
> On Sun, Mar 20, 2016 at 10:41 PM, Josh Matthews 
> wrote:
>
> > Welcome! Please ask questions here or on IRC if anything about the
> project
> > is unclear :)
> >
> > Cheers,
> > Josh
> >
> > On 2016-03-19 5:39 PM, Ravi Ashok Kumar Patel wrote:
> >
> >> Hi,
> >>
> >>
> >>
> >> This is regarding the Student Project we are working on as part of our
> >> curriculum at NC State University.
> >>
> >>
> >>
> >> Me and my team are working on "**Implement HTML5 form validation**" for
> >> servo
> >> web browser engine.
> >>
> >> Following people are working on this project
> >>
> >>
> >>
> >>1. Arpit Tyagi 
> >>2. Vinay Suryadevara 
> >>3. Ravi Patel 
> >> We are being assisted by  Sagar Muchhal  for
> >> this
> >> project
> >>
> >>
> >>
> >> Currently we are working on Initial Steps listed on wiki page available
> on
> >> github.
> >>
> >>
> >>
> >> Please let us know in case any further information is required
> >>
> >>
> >>
> >> Thanks
> >>
> >>
> >
> ___
> 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] Please don't leave PRs without an assignee

[Keith Yeung]

Should we have a list of people who are familiar with a certain crate
within Servo? I think the wiki has a list, but it seems oudated.
On Mar 9, 2016 11:16 AM, "Jack Moffitt"  wrote:

> On Wed, Mar 9, 2016 at 8:25 AM, Josh Matthews 
> wrote:
> > Hi reviewers of Servo! As you've noticed, we recently started assigning
> > reviewers to new PRs by random selection. Sometimes this means that a
> > reviewer ends up assigned to a PR which they don't feel comfortable
> > reviewing, which is totally fine! When that happens, please redirect the
> > review to somebody else more appropriate rather than just removing
> yourself
> > as the assignee.
>
> I would also encourage those of you getting PRs outside your comfort
> zone to at least glance at the PR and maybe try and do what you can.
> You'll learn something new, expand your comfort zone, and probably
> catch some things other reviewers didn't. I often find that when I
> review code I'm not as comfortable with, I'm usually much more careful
> and catch more undocumented assumptions.
>
> jack.
> ___
> 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] New Outreachy Intern

[Keith Yeung]

Welcome, welcome, Nikki Bee! My name is Keith and I was working on the
Fetch spec (specifically, the files under components/net/fetch). If you
have any questions or problems or just any hiccups you've encountered,
don't hesistate to ping me in IRC (KiChjang) or Ms2ger or jdm, we'd all be
happy to help!

Best wishes,
Keith

On Sun, Dec 6, 2015 at 9:05 PM, Nikki Bee  wrote:

> Hello everyone!
>
> I'm Nikki Bee, one of the new interns for this round of Outreachy
> https://www.gnome.org/outreachy/. Josh Matthews suggested I introduce
> myself to everyone, so here I am! I'm going to be contributing to Servo
> based on the project details here:
>
> https://wiki.mozilla.org/Outreachy/2016/December_to_March#Servo:_Complete_implementation_of_Fetch_standard
>
> My first contribution to Servo started a month ago, which you can check out
> here: https://github.com/servo/servo/pull/8218. That was when I first
> started learning Rust, and I'm greatly enjoying it as a language!
>
> I look forward to working on Servo and meeting more of y'all in doing so.
>
> - Nikki Bee
> ___
> 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