1

Meeting 2014 04 14

Lars Bergstrom edited this page 2014-04-14 17:41:32 -07:00

Table of Contents

• Servo Meeting 2014-04-14
• Reminder
• Agenda
• Attending
• Rust upgrade strategy
• Linking
• Embedding
• Rooting
• Android
• Acid2 regression

Servo Meeting 2014-04-14

Reminder

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

Agenda

• Rust upgrade strategy? More often now?
• Embedding update - PRs inc (zmike or larsberg)
• Reviewers for rooting PR (jdm)

Attending

jdm, jack, mbrubeck, larsberg, pcwalton, brson, kmc, azita, samsung team

Rust upgrade strategy

• jack: We've had a large number of them in the last couple of weeks. Were they strategic? Or will we continue it?
• jdm: Mostly strategic, to get deref and things like that.
• jack: Last time we talked about our strategy was a year ago when we wnated to delay them as long as possible. It makes for very painful experiences for the upgrade, though. Should we reconsider?
• larsberg: I worry that it's basically a full-time person of work.
• jack: can we get tooling to help?
• larsberg: the API calls change, disappear, get renamed.
• jack: not much we can do.
• brson: yehuda has complained about this as well. Maybe we could make these more visible and upgradeable? But that's a big undertaking.
• jack: Maybe a changelog? Just old and new names?
• brson: yehuda would like that as well. Not conceptually hard to do, but a big cultural shift to get all of the reviewers doing that. But that's the minimal-ist thing we can. One other important point is you just went through the big API renaming, and nothing is going to be that painful again.
• pcwalton: We keep saying we're past it, but we keep redoing the whole thing.
• jack: I'm fine with Rust continuing to get better because they're net positive. But how can we deal with it more efficiently.
• brson: The longer we can keep the community on master and not settling on a point release, the longer we have freedom to keep working on rust. Anything we put in place to keep the community on Master.
• pcwalton: Could invest in Rustfix. But that's a lot of work...
• brson: Low-hanging fruit? I'm not suggesting we try to do something that ambitious at the moment.
• kmc: When a function or type is rename, could you have rustc flag the places using the old name as a warning? Maybe easier than grepping?
• jack: That tends to happen on non-API changes; we get a warning about new syntax.
• brson: Yes, we did more to make that better.
• kmc: Could just tell you want it became, not preserving the old behavior.
• brson: One thing that's easy is to leave a deprecated, failing stub.
• pcwalton: Failing at runtime is bad.
• brson: It'll warn at compile-time and fail are runtime...
• pcwalton: We should have something new and different from deprecated that actually errors out.
• kmc: Not arguing for keeping deprecated APIs around longer. Just an attribute on a stub function would work for us.
• pcwalton: Still a lot of work for splitting up libextra.
• kmc: Different crates, but also function name changes?
• jack: The APIs get redesigned to take advantage of those features. Like when vectors got changed, etc. Guess we'll just keep trying to improve. I'd like to have more of a cadence to this. Monthly, biweekly, etc. Longer than a month is really painful. Maybe rotate it around the team? It's not super-fun. Other thing is: do we have a solution for MutexArc?
• larsberg: No, we have to port all of libsync to get a MutexArc that has the same semantics...
• jack: Open a bug. Let's get it on the Rust agenda for tomorrow.
• pcwalton: I don't think we should recreate libsync the way it was before, since it was too slow to be usable.
• jack: Easiest was to just pull in an old datastructure, but it is way too much work for now. Bring it up in the rust meeting tomorrow and see if we can get help?
• pcwalton: Anything that relies on sync::sem is just so broken and slow there is no way to fix it.
• jack: MutexArc lots one of its bounds.
• brson: Just need a new bound somewhere?
• jdm: It gained a bound.
• larsberg: Arc<Mutex<>> requires Send+Share, which breaks the whole thing.
• brson: That sounds easy enough; let's fix it.

Linking

• larsberg: They fixed the linker order arg.
• jack: Same one on Android?
• mbrubeck: I think it's related to some Android-specific linker arguments.
• jack: We're having lots of linkage issues lately.
• mbrubeck: I think something underlying triggered both of those, because they were both sensititve to the order of arguments generated by rustc. So some changes to rustc might have exposed both of those more.
• larsberg: Also more than two people trying to compile Android.
• jack: If this issue comes up again, we should bring it up in the rust meeting. Be nice to remove the fancy link_args hackery we do on Android.

Embedding

• larsberg: mike starting to land his patches. they sould land as a few separate PRs. He and I are going to do a joint servo and embedding talk at LinuxCon EU and US. He's putting together a proposal for that. We need to get out and talk about Servo a little bit more.
• jdm: Bruno has an accepted talk at FISL (Brazilian OS conference)
• jack: Should be called BISL? :-)

Rooting

• jdm: It's a very big PR. I'm freely admitting, about a 8-9k diff. Someone will have to review it. I think I've explained it in the pull request well and a lot is mechanical. A slog, but not too bad.
• jack: did ms2ger review this?
• jdm: No. No real review has happened yet. Some touches layout, so someone should look at it, too.
• pcwalton: I can do layout or all of it, depending on what people want.
• jack: I'll look at the non-layout parts.
• pcwalton: I'll look at layout. I was going to look at the parallel layout bug anyway. If you're changing wrapper, we might as well fix it in the same patch, if it's something simple...
• jdm: I prefer to split that out; this is going to be big enough already.
• pcwalton: Unbreaking parallel layout may conflict.
• jack: Is this new rooting stuff going to make us compaitlbe with spidermonkey when we upgrade?
• jdm: Yes. We should be able to use precise rooting with it.
• jack: This does not work for a moving collector, right?
• pcwalton: It does on the script side. But there will be more work needed to make DOM objects on the layout side work. For now, it doesn't matter because we don't hav eincremental reflow. Once we do, we'll have addresses of DOM nodes inside boxes and that will be broken by the moving objects.
• jack: Is the spidermonkey we use now or later a moving collector?
• jdm: Right now they have generational GC by default, which is moving.
• pcwalton: Yes. It won't cause crashes. It'll cause events to be dropped on the floor. We will have to do something. Not insurmountable, but it'll be something like when JS moves objects, we need the old/new pointer lists.
• jack: Can you file a bug on that? It'll have to be done before we upgrade...
• pcwalton: We can turn of generational garbage collection. Or we can pretenure DOM nodes to avoid copying, so GGC is on for benchmarks, etc. but it doesn't affect the DOM code.
• kmc: Makes sense, since DOM is probably long-lived.
• jdm: For getElementsById, conceptually...
• pcwalton: Those are wrapped objects with short lifetimes; could be useful there. Of course, those don't live in layout, so we don't care about tenuring them, which might be a viable long-term strategy for reducing the overhead.

Android

• mbrubeck: Since Android is building again, I've been trying it out and experimenting with platform integration. Servo is registered as an HTTP and HTML file handler so you can click a link or a file in dropbox and have it open in Servo. There is more work to get it going, but there is a branch if you want to follow: https://github.com/mbrubeck/servo-android-glue/commits/intent
• pcwalton: I highly encourage submitting random patches! We're not at the point where Android is usable for real work, so I'd just land it.
• mbrubeck: I'm thinking of the app as scaffolding, since embedding is probably the long-term goal. But for now we might as well have nice scaffolding.
• pcwalton: You can ask jst; Gecko had something similar for quite a while (the Viewer)
• mbrubeck: Just want it easiest to use.
• jack: What's blocking us with regards to networking?
• larsberg: I suspect there's something blocking us in the bionic C runtime; maybe our Rust libraries are making calls that aren't supported in bionic libc.
• jack: Something in standard I/O?
• larsberg: As far as I can tell, yes. We're doing funny things with sockets that aren't allowed on Android.
• jack: Maybe we're not catching EINTR or something.

Acid2 regression

• june0cho: I am looking into the Acid2 failure on current servo. The eyes do not appear on current servo and I want to fix it. When I tested that case and removed the first two lines of the test case, the eyes appear again. Do you have any idea on what might be broken with Acid2?
• jack: You mean the first line of the smiley? Not the doctype of the HTML?
• june0cho: Yes, the first line of the face. I don't know the exact reason yet.
• jack: Class=forehead and a bunch of non-breaking spaces. It has margin, width, border-left, border-right, background with a data url... and line-height.
• larsberg: SimonSapin narrowed this down to the Rust upgrade.
• jack: Merge failure? There were min/max problems.
• pcwalton: did you break Acid2?
• jack: Immediately when you went on vacation.
• pcwalton: embarrassing!
• jack: It worked for two days! We tried to add a reftest... and that is when we realized it was broken. Hopefully it will be localized. Just the diff of src/components/main/layout should find it in the Rust upgrade.