Skip to content

Meeting 2014 10 13

jdm edited this page Oct 14, 2014 · 1 revision

Servo Meeting 2014-10-13

Reminder

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

Agenda

  • speakers for servo-themed rust meetup during workweek (jdm)
  • recipes for servo-themed cookies during workweek (zwarich)
  • wpt flakiness (jdm)
  • html5ever status (kmc)
  • incremental reflow progress (cgaebel)
  • november work week update (jack)

Attending

  • mrobinson, kmc, Manishearth, jdm, pcwalton, gw, mbrubeck, azita, zwarich, cgaebel

Rust meetup

  • jdm: erickt is going to be putting on a rust meetup during our work week in MV. He wants it to be Servo-themed, so we need speakers. Does anyone have something cool they want to talk about?
  • kmc: I'd be happy to do something. [Maybe something about the architecture of html5ever and how it uses metaprogramming]
  • pcwalton: me too
  • azita: Will this be in the Mountain View office? What night?
  • jdm: Yes, at Mozilla SF on Thu. Nov. 6, I believe.
  • jdm: Jack suggested mbrubeck could talk about robinson.
  • mbrubeck: sure.
  • azita: We just cancelled the Research staff meeting but instead we want to do monthly company-wide brownbags. Lars is going to be talking about Servo as a brownbag that week, Tuesday I think, also in the Mountain View office.

Cookies

  • zwarich: I don't actually know how to bake.

WPT

  • jdm: web-platform-tests is being extremely flaky. I'm going to start digging into that tomorrow. We can categorize the failures as X11 errors, silent timeouts (I'm going to talk to jgraham about getting better output), and bogus output from the test harness web server. There's also at least one layout race where we end up with a borrowing error. I've turned on backtraces so we should get more information about that. And finally a weird Python test harness failure on interfaces.html (which sends a huge amount of JSON output to the test harness, which somehow chokes on it intermittently). I swear these problems are recent, so if there are any suggestions for figuring out what regressed...
  • pcwalton: You could bisect servo.
  • ??: Or look at historical logs.
  • jdm: I think larsberg said the buildbot machine stores the logs.
  • Manishearth: We could bisect by doing 3-4 runs of WPT on each revision.
  • jdm: I like the idea, except I ran WPT about 7 times in a row today and got zero failures. Which is really weird.
  • jack: Do you think lowering the process count would help?
  • jdm: I tried increasing and decreasing it, and didn't see any difference.
  • jack: Failures on Linux only?
  • jdm: Also on Mac. Maybe more often on Linux.
  • jack: FYI, on Mac someone has to be logged in for there to be a display, and whatever resolution their desktop is will be the resolution for the "screen" backing buffer. This can affect reftests if the Servo window is partially offscreen.
  • gw: I changed that to render to an off-screen buffer, which I thought work work around that. But I've still seen some reftest failures I need to look into.
  • jack: Yeah, that should work. The way we noticed this before was that the images being output had the wrong dimensions.
  • jdm: Any ideas for the X11 errors?
  • jack: Can you send an example?
  • jdm: https://github.com/servo/servo/issues/3595
  • gw: I've been able to reproduce previous failures on a VM, so I could try that again.
  • jdm: It's really intermittent.
  • jack: Is there a specific set of tests that always fails? I see interfaces.html. Anything else?
  • jdm: No; seemingly arbitrary set.
  • jack: We should send a note to the list telling people to use @bors: retry (not @bors-servo: retry).

html5ever status

  • kmc: I think it's ready. I addressed the last round of feedback. As soon as jdm and Ms2ger get a chance to look at it, we can land it.
  • jack: Are there any known things that are missing?
  • kmc: Plenty of web features (SVG, MathML, templates), but nothing that was previously implemented. They're all in the bug tracker.
  • jack: What did hubbub do in those cases?
  • kmc: I'm not sure, but we didn't support them. There's a switch to either fail on those tags, or just parse them as normal HTML tags. We use the latter in Servo and it's enough to pass all the tests we currently have. 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.
  • jdm: I can talk to student teams about that.
  • zwarich: On the web, is validity-checking for XML input required?
  • jack: That can depend on the MIME type. If you serve XML as text/html it'll use the HTML parser.
  • kmc: The sense I'm getting from people who do standards work is that the HTML philosophy won. The point of giving an error is that people will go and fix their markup, but that doesn't actually happen.
  • zwarich: But for things that do serve XML as XML, browsers do currently use draconian error checking.
  • kmc: I'll link to the relevant discussion: https://github.com/servo/servo/issues/3319
  • jack: There are also two levels of checking, well-formedness and DTD validation.
  • kmc: IE6 never supported XHTML, so it never caught on even for horrid internal corporate web apps.
  • jack: Chrome had a big thing on blink-dev about wanting to remove XSLT.
  • kmc: Or they were talking about moving it into JavaScript code.
  • jack: I think they're missing some JS APIs they'd need. And anyone willing to implement XSLT in JS. It would be nice if we could re-use that though.
  • kmc: I was 7/8-jokingly suggesting you could build apps in XML and use XSLT to render them in Servo. Then you could use any native XSLT impl, Servo doesn't need to know about it.
  • jack: Yeah, although those are slow and designed for batch processing.

Incremental reflow

  • cgaebel: We currently have a pull request to enable this behind a flag, because there are still a lot of little bugs with things like word-wrap not being idempotent. There are a series of failing reftests and probably WPT failures next that we'll need to work through.
  • jack: This sounds like what we saw when reflows triggered by resize would cause text to jump around.
  • pcwalton: I think that was different, caused by style sharing. This is layout not being idempotent, which we've known about for a while. We'll definitely need some mechanism for joining fragments that were previously split. I had hoped we could get away with never splitting fragments, but we can't. Without re-joining, you'll get more and more fragments over time. Only ScannedTextFragments need to be considered for re-joining. Just look at adjacent ones pointing to the same original text.

Work week

  • jack: We have 21 people coming to the November work week. It's going to be our biggest work week ever. If anyone has a particular topic for discussion, I'm starting to work on the agenda. We haven't done much 2015 planning yet, so there will be several roadmap discussions and roughing out of big projects people can work on next year. Ideas are welcome.
  • cgaebel: What's a work week?
  • jack: It's when the whole team gets together for a week to work from the same physical location. We do a lot of design discussions, hacking together, etc.
  • kmc: One thing we need is a roadmap for getting Servo to a point where we're confident about its real-world security, and processes for handling security issues.
  • jack: We're still trying to figure things out for the December all-company work week. We'll probably be sharing a space with at least the Rust team, for at least half of the week.
  • jack: I'll send out an etherpad with a draft/placeholder agenda tomorrow.
Clone this wiki locally