Meeting 2014 07 07

Servo Meeting 2014-07-07

Reminder

Please update your status at: http://benjamin.smedbergs.us/weekly-updates.fcgi/

Agenda

• Welcome Laleh, an intern on Servo (larsberg)
• Possible hand-generation of snapshots for now (larsberg)
• Update on EFL in Servo (bjz + larsberg)
• Travis Linux builder randomly dies during builds (zwarich)
• Style warnings (zwarich)
• What to do with rust-http?
• Cancellation of Servo workweek
  • to be replaced by Servo partyweek?
• Future plans for azure/skia? (gw)
• newbors (jack)

Welcome Laleh!

• laleh: I'm the new intern
• lars: she'll be looking at power related issues in servo. how we work on mobile with cpu vs. gpu and also under a variety of execution strategies. this is all stuff we've speculated on for a while, but can start getting numbers about, as soon as she can get a device.
• jack: I have a spare nexus7, if that would be useful!
• laleh: I have them on order!
• jack: Let me know if you don't get anything soon; we can find a backup strategy.

Hand-generated snapshots

• lars: working well - reduced from 3 hours to 15 minutes. generating new snapshots has been challenging on travis infrastructure. may end up generating them by hand until we can get travis to give us more time.
• jack: we've talked with them about getting more time on the builders. what's the holdup there?
• lars: I need a number for how much money they want us to give them.
• jack: The longer they wait, the higher the number!

EFL

• bjz: I'm working a Servo-specific wrapper for EFL. It is a massive, comprehensive library, but we only need a small subset. I am just doing enough to be compatible with our current API in the platform crate. We can expand from there if we need new functionality. Should appear next week.
• jack: This will handle both setting up themain frame buffer and input events?
• bjz: Yes! And it will enable wayland support, headless testing, etc.
• jack: Will be be the first browser with native wayland support?
• pcwalton: There are ports of webkit that has it...
• mbrubeck: Firefox port is in progress - http://emilio.pozuelo.org/posts/75
• jack: Might be interesting to find that out.
• bjz: I've been on the #edevelop channel and they've been very helpful getting me up to speed. I should have it done soon.
• jack: fedora 21 should have wayland in there, but won't turn it on until 23.

Travis linux builder

• zwarich: I've noticed with a bunch of my PRs, the Linux builder just dies while running tests with no specific error message or anything that went wrong. Not a timeout.
• pcwalton: Sometimes with massive amounts of parallelism.
• larsberg: There's a 3.5 GB limit and a parallelism limit...
• pcwalton: There's a lot of opengl stuff and bjz's laptop was crashing on the tests intermittently. I don't know of a solution, other than maybe not using so much stuff?
• jack: Just run the tests with limited parallelism?
• pcwalton: Sure. But I think on linux you can just set an environment variable. Then you've got the GPU entirely out of the picture. (LIBGL_ALWAYS_SOFTWARE --pcwalton)
• mrobinson: LLVMPIPE also gives pixel similarities betwen platforms.
• pcwalton: If you use that env variable, servo will stop using the GPU.
• jack: if you find a build that fails, try LIBGL_ALWAYS_SOFTWARE
• zwarich: Can I change that?
• jack: It's just the makefiles in Servo, anyone can change them.
• manish: You can change whatever you want in .travis.yml with our builder process (this affects PRs too)
• jack: Or ping one of us to look at it.

Style warnings

• zwarich: The style guildeline warnings and lints keep creeping up on us. Should we disable them all globally? They seem to be things we don't care about and don't fix, but those drown out real warnings.
• jack: My prefernce would be to fix them. Except for s_n_a_k_e_c_a_s_e, all pretty normal. The only one we really need to disable is the FFI ones, which is a fine choice.
• bjz: Often, for FFI stuff, I just disable it globally for the module. (#[allow(foo)] or something)
• jack: zwarich, do you know of examples that hit the warnings without being an FFI? Or just old-style code?
• gw: A lot are from the auto-generated template code. We can probably just add a warning/disable to the generator for that. Those are the only ones I can think of that aren't FFI.
• jack: If you search for "allow(" in the codegenrust.py file, you'll find a few
• zwarich: If we don't think there will be other style warnings that will bite us in the future, that's fine. I think brson proposed a global style disabling item
• brson: The compiler itself should maybe not have this responsibility; maybe rustfmt should.
• jack: We could do "-D" globally... but normally we'd like the snake_case warning in most of servo code, just not in some of our crates. I'm not sure of the best way to do that. If we could get warning-clean again, it would be easier to determine how annoying this is.
• brson: That sounds E-Easy!
• jack: gw just did another pass cleaning up some of them.
• mbrubeck: I can help. When we get warning clean, we could also make them errors so they never come back.
• jack: We did that for unused imports...
• gw: They come during upgrades, though...
• mbrubeck: Maybe turn it back into warnings during an upgrade?
• jack: jdm is currently doing a Rust upgrade?
• jdm: No I'm not.
• jack: For the SpiderMonkey?
• jdm: I was, but then we encountered issues generating a snapshot....
• jack: Is it abandoned?
• jdm: Yes, we just need a new LLVM + snapshot, etc.
• jack: How close are we to stabilizing our LLVM dependency, brson?
• brson: Not that close. Trying to maintain compat with stock-3.5, but we have minor fixes and optimizations that we will accumulate for a while...
• manish: LLVM snapshots on rust-lang.org?
• brson: Anything is possible. :-) But not probable.
• jack: If we can get a workflow to also have hand-generated snapshots, we'll be fine.
• brson: Why are you having a problem?
• jack: New LLVM requires a new clang, toolchain, etc.
• brson: Not using self-contained LLVM in the Rust build? Oh, and travis' ubuntu doesn't have the C++ compiler.
• larsberg: lots of dependencies in LLVM hurt
• brson: Yes, we turn them off. One thing we're planning to do in Rust is create a nightly archive, which would replace your snapshots...
• larsberg: cross-compile!?!?!?!?
• brson: We can fabricate a cross-compiler from two non-cross-compiler snapshots. Just slap e'm together and it works!

rust-http

https://groups.google.com/forum/#!topic/mozilla.dev.servo/bKxozFRAQLM

• jack: manish sent an e-mail to the list. My thought is that we shouldn't wait for Teepee.
• manish: Best if we try to at least handle some of it ourselves.
• jack: Sounded like most of the glue code would be servo-specific, so just put it in the main Servo repo. If it turns out this isn't servo-specific later, we can pull it back out. I can't imagine too many Rust projects will want to implement Fetch.
• SimonSapin: rust-http has some design issues with strings vs. byte arrays, the header formats, etc. It's non-trivial to fix it all and unclear if we want to fix rust-http or work on something else.
• jack: My intuition here is that we need something that will fix things like the SSL problem. Also, we want Manish's project to be successful before his internship ends. Let's solve the second in a way that doesn't break the first.
• manish: I will keep working after I finish! In fact, my GSoC is technically finished apart (proposal wise -- lots of fun extras to do otherwise) from some glue code. But one way to use rust-http is to keep all the basic HTTP handling (+SSL) and just rewrite the externally exposed API. That might be possible;I'm looking into it right now.
• jack: If we can make some to rust-http now and overhaul later, that sounds better. It'd be nice if we had a new http library that did everything we wanted.

Servo workweek

• summary: no more servo workweek in September. Will arrange one ASAP in 2015.

Future plans for azure & skia

• gw: I've been looking into issues in skia and azure. Most have been related to skia's not really being "happy" with being used from multiple threads, causing me to disable parallel rendering to avoid heap corruption. Thought it would be worth chatting about our plans. Briefly, we have talked about doing our own implementation, even though it's a big chunk of work. Options are: 1) Leave as-is and patch on top of it; 2) update those libraries; 3) build our own rust-specific ones. Both of those libraries have diverged quite a lot from what we have and we have a lot of patches on top of the old ones. So, I was interested in others' opinions.
• pcwalton: Glad you brought it up! I've been talking with jack and dherman about getting you in a room with gal to talk about a moz2d optimized for low memory situations. Definitely, we should have this conversation.
• gw: The other thing that leads me toward it is that we're using them so suboptimally that I'm not surprised it's slower than the CPU rendering. At the moment, we have multiple contexts per frame, and on each frame, it creates hundreds of extensions.
• zwarich: Should never be creating it for every time you render... I also already started working on a 2d display list rasterizer to see if a CPU or GPU renderer would be faster, especially with Laleh around to look at power usage! I was doing it for experimental usage, but I could try to make it less so. I was going to do a CPU renderer with vector SIMD assembly for basic blitting/blending and then a GPU impl. that would just require GLES2 and see the perf. I'm expecting on Linux we'll have weird situations where we put the driver in sub-optimal states, but we can also just look what Skia/Azure do on that platform. I don't think it's that much work for the current subset we have, but when you look at our future support for Canvas, SVG... do we want to re-implement it all? Shell out to something else? But then we have 2 2d rasterizers. That's actually the big question. But it would definitely be better for controlling memory use & parallelism.
• jack: It'll be hard to get Andreas' time and several weeks out. So I suggest gw and zwarich and anybody else interested meet later this week to see what experiments we have done and need to do. Then maybe a call with Bas (on gfx) and at that point we can have a meeting with gal with a bit more info available. Anybody who wants to be part of this, please ping me.
• zwarich: The other thing that's a little tricky, is that some of the problems the gfx team is trying to solve in Moz2D rewrite are well beyond the kinds of things Servo currently supports. If we want to do 2d, do we want to solve all of Moz2D, or just make an optimal renderer for the subset of the web Servo supports? Before we talk widely, we should figure out our scope. It's also hard to test some of the proposed scene graph optimizations until you have the whole browser implemented.

newbors

• jack: I'm working on a new version of bors that supports our travis workflow - same thing, but with travis. Rust also needs a new bors for API limit reasons (so many PRs on Rust and bors makes so many operations), and needs to shift to webhooks instead of 3-5 minute polling via cron job. My plan is that I have half the state machinery there. The next step is the little travis integration so that we have the same bors as a cron job. Finally, I can start adding in the webhook part. Once I have the state infra, I'll put it up so others can work on it with me - I believe Manish was interested. Is there anything the Rust team needs from newbors?
• brson: We haven't started working on anything, but bors is mostly maintained by the basho guys on Riak and are 6 months ahead of us - like speculative execution (for multiple builds in parallel), etc.
• jack: I didn't see that, butI didn't get to that part yet. I did see the r- stuff, etc., though. And the collaborators-as-reviewers.
• brson: By default, bors will push every PR straight to the buildbot. But, you can restrict that to 1 build. For Rust, I'd like 2.
• jack: Right now, every PR does a travis build. We need bors to check that the build state matches the merge, b/c a PR does not get re-tested whenever master gets updated.

Other topics?

• jack: Sounds like "no", so that's the end! Thanks.