Disclaimer: This content reflects my personal opinions, not those of any organizations I am or have been affiliated with. Code samples are provided for illustration purposes only, use with caution and test thoroughly before deployment.
While working on a compiled language like Rust, a typical workflow is compile -> find the errors in the compiler message -> find the file containing the error -> edit -> re-compile. But usually there are lots of errors scattered around the compiler log, and to identify the filename and line number, and manually open the file to the correct line in an editor is a tedious job. Vim’s quickfix streamline the process by collecting the errors into the split panel in vim, and allow you to navigate through the errors using the :cnext (next error) and :cprev (previous command). While you navigate to an error, the corresponding source file will be opened in the main vim window and jump directly to the line where the error is.
I wrote this post on the Servo wiki to help beginners getting started with rebasing and squashing, two of the most terrifying operations you’ll face if you are not familiar with git. I’m cross posting this here for people working on other projects.
Big thanks to Wafflespeanut who proofread the post, any error you found here is my own.
Suppose you’ve created a pull request following the checklist, but the reviewer asks you to fix something, do a rebase or squash your commits, how exactly do you do that? If you have some experience with git, you might want to check the GitHub workflow for a quick overview. But if you are not familiar with git enough, we’ll teach you how to do these common operations in detail.
We will be working on (gradually) migrating the majority of the code base to the Stryker.
So I’ll update my post to use the latest Stryker framework. The following will be the updated post with all the code example migrated to the Stryker framework:
August was quite a busy month for me. I went to two conferences and one workshop to promote Servo and Rust. Here are what I’ve observed in those events.
COSCUP
COSCUP is one of the largest volunteer-organized conference on open source software in Taiwan. When I was a student I tried to attend all the sessions, wishing to learn from the talks. But in recent years I realize that it’s really not about the talks, but more about meeting people. Half of the talks are about introducing people to new tools or libraries. You can learn them by yourself more efficiently by reading tutorial articles online. The most rewarding part is actually socializing with people. Because most of the open source participants will attended this conference, you can easily meet a lot of new friends through mutual friends. So this year I spend most of my time at social events, for example the speaker dinner party, Mozilla BoF (bird of a feather), and chatting with my friend’s friends.
Performance has always been a key focus for the Servo browser engine project. But just measure the performance through profilers and benchmarks is not enough. The first impression to a real user is the page load time. Although many internal, non-visible optimizations are important, we still want to make sure our page load time is doing well.
Back in April, I opened this bug #10452 to start planning the page load test. With the kind advice from the Servo community and the Treeherder people, we finally settled for a test design similar to the Talos test suite, and decided to use Perfherder for visualization.
