Meeting 2014 01 13

Agenda

• Tests
  • fix and enable reftests
  • jgraham's test harness work
• de-@ of Servo

Attending

• larsberg, jack, pcwalton, jdm, ms2ger (on faith), dherman, SimonSapin, jgraham, brson, azita, abinader

Testing story

• jack: Upgrade landed. The next project is getting testing in shape. I upgraded ref tests. Most still pass, but a few do not. Like to start gating builds on them, since process management is straightened out. Also, anybody else want to take it on?
• larsberg: I can.
• jack: Next step: jgraham has been building a test harness for FF for the W3C content tests. It was easy to add Servo support. I'd like to get this into Servo ASAP. We would import the w3c platform tests submodule into servo; copy the test harness from the gecko repo; create a dir for our current content tests; get all this running. Over time, we upstream content tests we develop into the w3c repo. Until upstreamed, keep in our own thing. End goal is running all of the web platform tests from the w3c with no servo-specific tests.
• jdm: That sounds unlikely.
• jgraham: Might need things for testing particulars of a GC at certain momements, etc.
• jack: So, the only ones we'd have separate would be the servo-specific ones. We'd need those if we ever do have async DOM apis, etc. if we're ahead.
• SimonSapin: what is the story for tests at w3c that are not in the web-platform-tests repository (CSS).
• jgraham: The CSS folks want their stuff separate. In theory, we could bring them in, but it only supports ref tests in gecko, not in servo. Maybe we could pull them in and use the same infrastructure as the platform tests if servo supports it. I've been focusing on the platform tests for now.
• jack: I will look at this unless somebody else is interested? Are there other tests besides the CSS ones that we should be working on?
• jgraham: No. The other obvious thing is the javascript tests. But since we don't have our own engine, it's not as relevant.
• dherman: There's core spidermonkey, but also some integration ones for spidermonkey & DOM, right? Are those relevant?
• jdm: Not aware of anything in particular.
• dherman: Guess I'm thinking of the standalone shell...
• jdm: That's more XPcom-related stuff (xpcshell).

de-@

• jack: We're one commit short in Rust of the de-@mut of servo. I took the commit before that one, cherry-picked debug info, and have disabled static linking. Static linking should get fixed by updating the toolchain on the build slaves. So, the only thing left is getting rid of @ and @mut as blocking future Rust upgrades. Seems reasonable to do this early so it doesn't get terrible. Volunteers? Should be straightforward, but it's a little ugly due to explicit borrows and the temporary lifetime issue in Rust (which leads to 2 lines of code every time you want to do a borrow).
• pcwalton: niko wanted to land the lifetime fix last week, so hopefully next week.
• jack: Shouldn't block our own work. We can search/replace those two lines. We have them because of Rc<RefCell<>>?
• jdm: I can get rid of the DOM-related ones with JSManaged to avoid rebasing over the RefCell stuff.
• jack: The DOM is probably the biggest one. then platform.
• larsberg: And windowing. jack: Ok, if you can do that, jdm, that would be great, and we can pick up the rest.
• larsberg: Yeah, we got prety far behind.
• jack: Just owned closures were tough. Linked task failure turned out to be the biggest problem for us. Hopefully nothing else that large!
• brson: Was anything really obnoxious to you?
• jack: It's unclear. My first response is losing linked task failure sucks. A lot. Maybe we'll find alternatives to this problem.
• brson: Is there a good pattern that doesn't require deep scheduler integration?
• jack: There were all these weird bugs after porting syntax. And it ended up being that we depended that when a task comes down, the whole of servo comes down. Now, nothing happens.
• larsberg: losing linked task failure caused us to have to explicitly handle a lot of shutdown protocols that "just worked" before.
• jack: Feels fragile now. But I had no issues with the native/green split. We run native start, launch the profiler, start a green scheduler pool for the constellation (so JS, layout, pipeline is in green threads) and then run the compositor on the main native thread. We haven't had any trouble.
• brson: spidermonkey?
• jack: It's on a green thread. It's what we seem to want, right?
• brson: I thought there were obstacles. Doesn't it use TLS?
• jdm: That's a concern!
• jack: We had it on a green thread until we found the post-summit bug, when we put it in 1:1 mode. Otherwise, it's always beeen there. If spidermonkey gets its own thread, we won't be able to do the fast context switch thing between it and layout. So the goal is to try to make it work... Most of the stuff in the Rust upgrade, as painful as it was, is that Rust got more strict, which caused us to stop taking advantage of the unsafety, etc. Servo is always safer after the upgrades. Especially the lifetime temporaries thing, it feels like the first couple of passes with external iterators, where we went backwards a bit in design before moving forward.

workweek

• SimonSapin: Agenda for next week?
• jack: I'll send it out soon. The plan is to work on stuff related to ACID2 that we all need to be together for. Tables, positioning, generated content, stacking contexts/z-index.
• SimonSapin: generated content. Some has landed, but we're still missing generation.
• jack: I'll try to send it out in the next couple of days.
• azita: Do you know if we have our space in SF?
• jack: No mail yet. I'll follow up. And check on hotel accomodations.

review queue

• jack: Stacked up PRs because we basically closed it for the upgrade. Can we try to empty it? ~24 PRs open right now. If your patches got whacked, sorry! Let me know if you have questions about the rebase. Mainly affect patrick because the new layout safety is quite different.

Servo publicity

• brson: I don't do twitter. Are we getting enough out about Servo? Is it being publicized?
• jack: We should do more about that. TWiR now has TWiS! Next easy thing is to have a servo talk at the monthly meetups.
• dherman: Don't need to tie Servo and Rust together. Different crowds. We would like to get interest from people not necessarily contributing to the codebase. One thing is nightly builds would make it possible for people to kick the tires. Maybe not advertising it too much because we're too early to have people use it? But a place where you can find it and try things out, that would be interesting. Also, a website would be nice (servo.org just goes to the github repo).
• jack: Logo! Stickers! How did that work with Rust?
• dherman: We contracted(?) to Shawn Martell.
• brson: I think he also did the FF logo, or worked on it, right?
• dherman: azita and I will get on this.
• jack: We have the infra to do servo nightlies (static linking). Need to get that quickly because the last brendan demo was a bit chaotic. It will be no less so, so sooner would be better.
• dherman: Even one platform would be great.
• jack: Experiment during workweek? Maybe a make package that will get a static build.
• dherman: Do we have a moz-servo twitter account? Yes. It's never tweeted. Probably created by me. Maybe Andreas? I'll look into it. Not necessarily a huge amount of traffic.
• azita: Both on Rust & Servo, trying to talk more internally at Mozilla. Maybe in Monday meeting mention something about Rust, releases, etc. A tutorial would also be great (internally).
• larsberg: Niko is working on a small tutorial for POPL that maybe could go out.
• dherman: We'll need a better tutorial at 1.0 for Rust. First set of materials would be useful for us to build off of. Training for Rust within Mozilla is great, for testing, building Mozilla interest, etc. Maybe for Servo, too? A brownbag on how Servo works? Put some into the talk on how to dive in / contribute, maybe we'd get some more interest.
• jack: A follow-up to the Summit session? Or we could also have a Servo hack day the next time one of those DOM implementation things come up that has a huge list of small things to pull together. Might be a bunch of that stuff in the ACID2/ACID3 stuff as well. I'll follow up on Twitter, etc. We can chat more next week, too.
• dherman: A simple thing is if there's a big enough milestone, get it onto HN. Need some sort of a web page - blog with announcements, on Mozilla Research blog, even a github commit at worst (boo).
• jack: Once we have table layout and ACID2, we can do wikipedia well. I don't even know what's left for wikipedia after ACID2. A little time on a browser shell for zoom/pan, etc. it'd be a good release. It could be a wikipedia browser. Just opens wikipedia and doesn't go anywhere else. Maybe a little instrumentation to show parallelism, gains, etc.
• jack: Next week (workweek) we should start seeing what ACID2 looks like with current servo. Showing the progress would help build momentum. During the workweek, it looked pretty bad. Passing ACID2 will be good. It's harder to find these visual things post-ACID2. ACID3 is non-visual. And then there's no more easy visual benchmarks.
• dherman: At that point, we invent our own.
• pcwalton: ACID3 has a score. Everybody likes scores!
• jgraham: ACID3 is the point where "making pretty things" no longer worked anymore. People would do the minimum to make it render right. For ACID3 people would implement stub interfaces just to pass the test, so it wasn't really helping.
• jack: Guess I know how we'll pass ACID3 :-) After ACID3, most of what we need to show is web features. So we can pick pages we render nicely. We'll need other ways for people to see why servo's goodness. Just being safe and easy to modifiy doesn't work. The Shumway viewer (framerates, etc.) is something I keep thinking of to show how we compare. Page rendering tests against FF / Blink, etc. I assume our path looks like that post-ACID3.