Mozilla Nederland Logo De Nederlandse Mozilla gemeenschap

Abonneren op feed Mozilla planet
Planet Mozilla -
Bijgewerkt: 2 uur 53 min geleden

Edward Lee: Mr. AwesomeBar Runs for Congress

4 uur 45 min geleden

tl;dr The non-profit Mozilla changed the Internet by giving users choice and liberty. I, Ed Lee, want to build on that foundation to change how politics works in 2 ways: 1) get rid of politicians who focus on money and forget about voters and 2) change how politics is won by showing you can win without spammy advertisements that track tons of data about people. The Internet helped Mozilla take on “unbeatable” opponents, and I need your help to do the same.

I became a Mozillian 10 years ago. I found my passion helping people through Mozilla, a non-profit that promotes user choice and liberty on the Internet. These values attracted me to Mozilla in the first place, and I believe in these values even more after being employed at Mozilla for five years. I want to bring these values to politics because while the Internet can be a big part of our lives, politics tend to control the rest and can destroy the things/people we care about most.

During the SOPA protests, SopaTrack showed not only which Representatives were co-sponsors for the bill but also how often they voted with whichever side gave the most money. I was quite appalled to find out that Mark Amodei co-sponsored a bill that would take away our freedoms and earned a perfect 100% record of voting with the money [].

The behavior of this “Representative” is the complete opposite of the values that brought me to Mozilla, and I believe the correct solution is to vote out these politicians. That’s why I’m running against him as a US Congress candidate in Nevada on a platform of “Non Profit” and “For Liberty” to directly contrast with this incumbent.

Amodei votes 100% with money, SOPA co-sponsor vs. Ed Lee

Amodei votes 100% with money, SOPA co-sponsor vs. Ed Lee

I’ve talked to various people involved in politics, and I’ve been ignored, laughed at, told to go away and stop wasting my time. The most interesting dismissal: “the Internet can’t help,” and I thought to myself, “Challenge Accepted.” I hope the rest of the Internet is as outraged as I was to hear that the best action is to do nothing and give a free pass to this incumbent who just votes with the money to destroy our liberties.

Mozilla was in a similar situation when Firefox had to take on the dominant web browser. The Internet cared about the browser that focuses on the user (e.g., would you like to see that popup?). People helped spread Firefox even without understanding the non-profit that created it because the built in values of freedom and choice resonated with users.

My ask of you is to think of aunts/uncles/friends/relatives in Reno/Sparks/Carson City and see if they’re on this anonymized list of names []. If so, please text or call that person and simply say “please look into Ed Lee,” and if you let me know, I’ll personally follow up with your contact. If you don’t find anyone on the list, please share it with others whom you think might know someone living in the northern half of Nevada. Early voting starts in a month with the primary less than 2 months away on June 10th, so let’s move fast!

I’m aiming for at least a third of the midterm primary votes in a 4-way race, and that roughly comes out to just over 9000. (Really!) The anonymized list of names are of people most likely to vote in my district’s Democratic primary, and the plan is to have the millions on the Internet find a connection to those several thousands to make a personal request. This is as opposed to traditional political advertising where large amounts of money is raised to track down and spam people where I estimate more than 95% of people won’t even be moved to vote or vote differently. With my Mozilla background, that’s not how I would want to approach campaigning.

If this technique works for the primary, it could work for the general election by focusing on non-partisan voters. We can further develop this technique to vote out all the money-seeking politicians and replace them with people who care about individuals and freedoms across the US, and dare I say, across the world.

The Internet helped Mozilla change the world with its non-profit mission and strong core values. I need your help to do the same in the world of politics.

- Ed Lee (Ed “Mr. AwesomeBar” Lee is a bit long for the ballot)

Paid for by Ed Lee for Congress
Yay for free speech, but apparently not free-as-in-beer if not correctly attributed.

No comments
Categorieën: Mozilla-nl planet

Byron Jones: happy bmo push day!

12 uur 47 min geleden

the following changes have been pushed to

  • [994570] unable to create an attachment with review+ : “You must provide a reviewer for review requests”
  • [994540] “details” link in overdue requests email links to attachment content instead of details page
  • [993940] Group icons should be displayed for indirect memberships, too
  • [993913] remove the %user_cache from inline history, and ensure the object cache is always used
  • [998236] Privacy policy url has changed
  • [968576] Dangerous control characters allowed in Bugzilla text
  • [997281] New QuickSearch operators can short-circuit each other depending on which ones are tested first
  • [993894] the database query in bless_groups is slow
  • [936509] Automatically disable accounts based on the number of comments tagged as spam
  • [998017] Internal error: “Not an ARRAY reference” when using the summarize time feature
  • [999734] User email addresses are publicly visible in profile titles
  • [993910] Bugzilla/Search/ isn’t using the cache
  • [998323] URLs pasted in comments are no longer displayed

discuss these changes on

Filed under: bmo, mozilla
Categorieën: Mozilla-nl planet

Sylvestre Ledru: Changes Firefox 29 beta9 to 29build1

15 uur 31 min geleden

Last changes for the release. Fortunately, not too much changes. Mostly tests and a last minute top crash fix.

If needed, we might do a build2 but it is not planned.

  • 9 changesets
  • 29 files changed
  • 155 insertions
  • 292 deletions

ExtensionOccurrences js8 cpp7 h4 html3 css2 py1 list1 jsm1 idl1

ModuleOccurrences toolkit17 js4 browser3 testing1 modules1 layout1 editor1

List of changesets:

Mike ConnorBug 997402 - both bing and yahoo params are broken, r=mfinkle, a=sylvestre - 6bc0291bbe83 Ehsan AkhgariBug 996009 - Ensure that the richtext2 browserscope tests do not attempt to contact the external network. r=roc, a=test-only - 5944b238bd76 Nathan FroydBug 996019 - Fix browser_bug435325.js to not connect to r=ehsan, a=test-only - 6bfce9c619d1 Nathan FroydBug 996031 - Remove 455407.html crashtest. r=dholbert, a=test-only - 6431641fb1b6 Nathan FroydBug 995995 - Set testing prefs to redirect to the test proxy server for RSS feeds. r=jmaher, a=test-only - ba1c380f55b9 Monica ChewBug 998370: Rollback bugs 997759, 989232, 985720, 985623 in beta (r=backout,ba=sledru) - 4f4941d4cda9 Douglas CrosherBug 996883. r=mjrosenb, a=abillings - 9208db873dbf Jan de MooijBug 976536 - Fix JSFunction::existingScript returning NULL in some cases. r=till, a=sledru - a5688b606883 Gavin SharpBacked out changeset cb7f81834560 (Bug 980339) since it caused Bug 999080, a=lsblakk - 02556a393ed8

r= means reviewed by
a= means uplift approved by

Previous changelogs:

Original post blogged on b2evolution.

Categorieën: Mozilla-nl planet

Nick Cameron: Rust for C++ programmers - part 3: primitive types and operators

16 uur 53 min geleden
Rust has pretty much the same arithmetic and logical operators as C++. `bool` is the same in both languages (as are the `true` and `false` literals). Rust has similar concepts of integers, unsigned integers, and floats. However the syntax is a bit different. Rust uses `int` to mean an integer and `uint` to mean an unsigned integer. These types are pointer sized. E.g., on a 32 bit system, `uint` means a 32 bit unsigned integer. Rust also has explicitly sized types which are `u` or `i` followed by 8, 16, 32, or 64. So, for example, `u8` is an 8 bit unsigned integer and `i32` is a 32 bit signed integer. For floats, Rust has `f32` and `f64` (`f128` is coming soon too).

Numeric literals can take suffixes to indicate their type (using `i` and `u` instead of `int` and `uint`). If no suffix is given, Rust tries to infer the type. If it can't infer, it uses `int` or `f64` (if there is a decimal point). Examples:
fn main() {
    let x: bool = true;
    let x = 34;   // type int
    let x = 34u;  // type uint
    let x: u8 = 34u8;
    let x = 34i64;
    let x = 34f32;
}As a side note, Rust lets you redefine variables so the above code is legal - each `let` statement creates a new variable `x` and hides the previous one. This is more useful than you might expect due to variables being immutable by default.

Numeric literals can be given as binary, octal, and hexadecimal, as well as decimal. Use the `0b`, `0o`, and `0x` prefixes, respectively. You can use an underscore anywhere in a numeric literal and it will be ignored. E.g,
fn main() {
    let x = 12;
    let x = 0b1100;
    let x = 0o14;
    let x = 0xe;
    let y = 0b_1100_0011_1011_0001;
}Rust has chars and strings, but since they are Unicode, they are a bit different from C++. I'm going to postpone talking about them until after I've introduced pointers, references, and vectors (arrays).

Rust does not implicitly coerce numeric types. In general, Rust has much less implicit coercion and subtyping than C++. Rust uses the `as` keyword for explicit coercions and casting. Any numeric value can be cast to another numeric type. `as` cannot be used to convert between booleans and numeric types. E.g.,
fn main() {
    let x = 34u as int;     // cast unsigned int to int
    let x = 10 as f32;      // int to float
    let x = 10.45f64 as i8; // float to int (loses precision)
    let x = 4u8 as u64;     // gains precision
    let x = 400u16 as u8;   // 144, loses precision (and thus changes the value)
    println!("`400u16 as u8` gives {}", x);
    let x = -3i8 as u8;     // 253, signed to unsigned (changes sign)
    println!("`-3i8 as u8` gives {}", x);
    //let x = 45u as bool;  // FAILS!
}Rust has the following numeric operators: `+`, `-`, `*`, `/`, `%`; bitwise operators: `|`, `&`, `^`, `<<`, `>>`; comparison operators: `==`, `!=`, `>`, `<`, `>=`, `<=`; short-circuit logical operators: `||`, `&&`. All of these behave as in C++, however, Rust is a bit stricter about the types the operators can be applied to - the bitwise operators can only be applied to integers and the logical operators can only be applied to booleans. Rust has the `-` unary operator which negates a number. The `!` operator negates a boolean and inverts every bit on an integer type (equivalent to `~` in C++ in the latter case). Rust has compound assignment operators as in C++, e.g., `+=`, but does not have increment or decrement operators (e.g., `++`).
Categorieën: Mozilla-nl planet

William Lachance: PyCon 2014 impressions: ipython notebook is the future & more

di, 22/04/2014 - 23:36

This year’s PyCon US (Python Conference) was in my city of residence (Montréal) so I took the opportunity to go and see what was up in the world of the language I use the most at Mozilla. It was pretty great!


The highlight for me was learning about the possibilities of ipython notebooks, an absolutely fantastic interactive tool for debugging python in a live browser-based environment. I’d heard about it before, but it wasn’t immediately apparent how it would really improve things — it seemed to be just a less convenient interface to the python console that required me to futz around with my web browser. Watching a few presentations on the topic made me realize how wrong I was. It’s already changed the way I do work with Eideticker data, for the better.

Using ipython to analyze some eideticker dataUsing ipython to analyze some eideticker data
I think the basic premise is really quite simple: a better interface for typing in, experimenting with, and running python code. If you stop and think about it, the modern web interface supports a much richer vocabulary of interactive concepts that the console (or even text editors like emacs): there’s no reason we shouldn’t take advantage of it.

Here are the (IMO) killer features that make it worth using:

  • The ability to immediately re-execute a block of code after editing and seeing an error (essentially merging the immediacy of the python console with the permanency / cut & pastability of an actual script)
  • Live-printing out graphs of numerical results using matplotlib. ZOMG this is so handy. Especially in conjunction with the live-editing outlined above, there’s no better tool for fine-tuning mathematical/statistical analysis.
  • The shareability of the results. Any ipython notebook can be saved and then saved to a public website. Many presentations at PyCon 2014, in fact, were done entirely with ipython notebooks. So handy for answering questions like “how did you get that”?

To learn more about how to use ipython notebooks for data analysis, I highly recommend Julie Evan’s talk Diving into Open Data with IPython Notebook & Pandas, which you can find on

Other Good Talks

I saw some other good talks at the conference, here are some of them:

  • All Your Ducks In A Row: Data Structures in the Standard Library and Beyond – A useful talk by Brandon Rhoades on the implementation of basic data structures in Python, and how to select the ones to use for optimal performance. It turns out that lists aren’t the best thing to use for long sequences of numerical data (who knew?)
  • Fast Python, Slow Python – An interesting talk by Alex Gaynor about how to write decent performing pure-python code in a single-threaded context. Lots of intelligent stuff about producing robust code that matches your intention and data structures, and caution against doing fancy things in the name of being “pythonic” or “general”.
  • Analyzing Rap Lyrics with Python – Another data analysis talk, this one about a subject I knew almost nothing about. The best part of it (for me anyway) was learning how the speaker (Julie Lavoie) narrowed her focus in her research to the exact aspects of the problem that would let her answer the question she was interested in (“Can we automatically find out which rap lyrics are the most sexist?”) as opposed to interesting problems (“how can I design the most general scraping library possible?”) that don’t answer the question. In my opinion, this ability to focus is one of the key things that seperates successful projects from unsuccessful ones.
Categorieën: Mozilla-nl planet

Florian Quèze: Thoughts about mentoring Summer of Code students

di, 22/04/2014 - 22:24
I've mentored Google Summer of Code students 3 years in a row, and I would like to share with new GSoC mentors what I've learned, in the hope that it can help them get more out of the summer. I'm going to assume that most mentors share these 3 goals:
  • get usable code at the end of the summer
  • train long term contributors who will stay active after the end of the summer
  • avoid spending disproportionate amounts of time mentoring.
I can't overstate how important it is to give the student good working habits from the very beginning. If you setup a good working relationship from the beginning, you are on for an awesome summer. If you let a student do things that frustrate you without sending immediate feedback about it, you'll both suffer during the whole summer.Here are some frequent problems that are likely to happen if you don't pay enough attention in the beginning:
  • Because of the way school works, students are used to hiding their work until it's ready to be evaluated. Training them to show work-in-progress code so that you can provide early feedback and effectively help them takes time. You'll likely need to ask "show me the code, please" several times, encourage them, and comfort them that it's OK to show unfinished non-working code.
  • Students are used to receiving feedback from one person, and are likely to send their work only to their mentor when requesting feedback or expecting evaluation. Encourage the student to discuss the project with all the relevant people and more generally to interact with the community; avoid private discussion of technical matters. Doing this has 2 interesting consequences: the time you'll spend mentoring the student will be dramatically reduced because the mentoring load will be spread across all your team (for me this often meant that when my student asked a question on IRC, he received a good and timely answer before I had even read the question!), and the student will feel like he's part of your team, which increases the likelihood of staying around after the summer.
  • Unless given specific directions, students tend to work on a branch or on a repository somewhere, and think about merging their code or getting a review only at the end of the summer. It's common to see student applications where the schedule says that they will do all the coding work, and then get a review during the last week of the summer to land the code. Experienced Mozilla developers knows there's no way sending a several-months-of-work-worth patch to someone's review queue and expecting a timely review will work. But students usually dramatically underestimate both the time it takes to get a review AND the time it takes to address the feedback (probably because at school they hand their work and only expect a grade, or a pass/fail in return). As a mentor it's your job to ensure they get their code through review. Urge students to write small patches, and get them reviewed as soon as possible. Students (and other developers ;)) will be tempted to 'just add one more little feature before attaching the patch'. Resist! Filing a new bug is easy. If the schedule of a student involves writing code without submitting it for review and inclusion, this raises a red flag for me: is there really no way to break this down to smaller pieces that could land separately? Don't hesitate to rediscuss the schedule with the student if you aren't fully happy with it.
  • Given that the students are being paid money to participate in GSoC, it makes sense that lots of students will consider summer of code as "work", and have money be the primary motivator; which means that once they get the final payment, they disappear. This feeling can't be avoided in all cases, but if we can get the student to instead feel that the money is an opportunity to not do any other work during that time to focus full-time on volunteering for a project they care about, the student is likely to stay around for much longer than the summer. This can be done by treating the student more like a volunteer than like someone paid to be on your team. Get the student to have code landing early, and often. Get the student addicted to restarting his nightly build and seeing his code is in use there. Encourage the student to not only fix things directly related to his GSoC project, but to also spend a few hours here and there fixing his own itches and looking into other bugs that make the product better for his own use cases.
Here is one suggestion to get students started: during the community bounding period, assign them a 'small' project to warm up. The ideal characteristics of such a project are:
  • will get the student to go through all the processes of your team (using bugzilla, attaching patches, requesting review, handling review comments, …)
  • will get the student to touch code areas that will be relevant during the summer.
  • can be completed by the student before the ends of the community bounding period (think of it as a 2-weeks project, but size it like something you would do in a rainy week-end. Remember that most of the time spent by the student will not be actual coding, but learning to interact with your team, and this is the very reason why this project is done during the community bounding period).
  • once this small project lands, it will be highly visible, and will cause the student to receive appreciation from other people in your team/community.
It's not always possible to find a project fitting perfectly here, but it's usually possible to find something close enough to fit the purpose of getting the student started. The Instantbird team will be using this 'small community bounding project' approach to starting the mentoring relationship for the third time this year.I tend to think that getting the student started on the right track is the most important thing a mentor needs to do, and if it's done correctly the rest of the mentoring is easy and pleasurable.
Categorieën: Mozilla-nl planet

Kat Braybrooke: Let's teach the web, offline! A design canvas and a new kit.

di, 22/04/2014 - 22:20

At Webmaker, we’ve been scheming and discussing potential solutions to a key challenge for a while — how can we empower educators to teach the web using peer-to-peer methods in regions where computers and web connectivity aren’t a given?

Enter this Design Canvas, an analog effort to help makers prototype Webmaker Teaching Kits together on paper before going online. I situate this Canvas within a larger hands-on prototyping exercise which implements some pretty radical participatory design methods, in the hope that it can improve the in-person experiences of mentors and participants alike…

Best of all, this Design Canvas and other activities like it will also help us build a brand new (and very salient) Lo-Fi Teaching Kit, codesigned with a team of Webmaker community members, that will highlight a series of remixable, modular group activities that empower educators to address different parts of the Web Literacy Map using analog materials.

Example of pre-kit brainstorms on paper at a Webmaker Training.

What I find most exciting about these efforts is the fact that in each case, the community has really been a core partner from the beginning. The Design Canvas activity has already been translated into Spanish thanks to community member Alvar Maciel, and it is being prototyped at various events, including a digital leadership training for National Citizen Service youth in London recently facilitated by the ever-talented Laura Hilliger.

Filled out Design Canvasses from Webmaker Training in London.

Next on my agenda is the creation of a paper-based canvas to help build out more granular Teaching Kit activities, and further work on the Lo-Fi Teaching Kit with our community co-authors. Want to get involved? Provide feedback on how the Canvas worked for you, or join us and help author the Lo-Fi kit from your own experience.

I am already looking forward to the prototypes, discussions, learnings and global translations yet to come!

Categorieën: Mozilla-nl planet

Christian Heilmann: Quick one: using download attribute on links to save Canvas as PNG

di, 22/04/2014 - 22:09

One of the things I always liked about Firefox is that you can right-click any canvas and select “save image as”. Chrome and others don’t do that (well, Chrome doesn’t). Instead you need to get the image data, create a url and open a new tab or something in that order.

One very simple way to allow people to save a canvas as an image (and name it differently – which would have to be done by hand in the case of right-clicking on Firefox) is to use the download attribute of a link.

You can see this in action in this JSFiddle. Simply paint something and click the “download image” link.

The relevant code is short and sweet (canvas is the reference of the canvas element):

var link = document.createElement('a'); link.innerHTML = 'download image'; link.addEventListener('click', function(ev) { link.href = canvas.toDataURL(); = "mypainting.png"; }, false); document.body.appendChild(link);

Categorieën: Mozilla-nl planet

Asa Dotzler: Tablets Start Shipping This Week

di, 22/04/2014 - 20:44

The Tablet Contribution Program is getting under way with the distribution of 500 tablets to our community starting this week. We’re not a giant operation here, so it’s going to take us a bit of time to package, address, and ship 500 devices to dozens of countries. Your patience is appreciated.

When your tablet ships, you will receive an email with tracking information. If you have not received that email, it means your tablet has not shipped yet.

Categorieën: Mozilla-nl planet

Manish Goregaokar: I've been selected for Google Summer of Code 2014!

di, 22/04/2014 - 12:06
I've been selected for GSoC 2014!

My project is to implement XMLHttpRequest in Servo (proposal), under Mozilla (mentored by the awesome Josh Matthews)

Servo is a browser engine written in Rust. The Servo project is basically a research project, where Mozilla is trying to rethink the way browser engines are designed and try to make one which is more memory safe (The usage of Rust is very crucial to this goal), and much more parallel. If you'd like to learn more about it, check out this talk or join #servo on

What is GSoC?Google Summer of Code is a program by Google that helps jumpstart involvement in open source amongst students. Organizations are invited to float their own open source projects, and students float project proposals. If selected, you get to code the project over the summer, working closely with the mentor. It's supposed to be a great experience, and I'm glad I'll get to be a part of it this year!
Who else got selected?
One purpose of this post was to recognize all my friends and college-mates who got selected:

Mozillia India friendsOther IITB-ians
Categorieën: Mozilla-nl planet

Manish Goregaokar: Getting started with bug-squashing for Firefox

di, 22/04/2014 - 11:20
So over the past few months I've been trying to contribute a bit to Mozilla (mainly Firefox). Last August there was a MozBoot session at IIT Bombay which helped me get over the learning curve.

First off, a big thanks to @Debloper (and @hardfire) for showing me the basics. The process is intimidating, though once you've done it with help, it becomes pretty natural. These Mozilla reps got me past that intimidation point, so I'm really grateful for that.

This post is basically an tutorial on how to get started. It's basically an in-depth version of this tutorial, which I feel misses a few things.

Note that I am still a beginner at this, comments on how to improve this post/my workflow appreciated.

Ok, let's get started.

Step 1: Identifying a bug you want to fixFirstly, make an account on You'll need it later. Browse the bug lists on the site, looking for bugs that seem fixable. Look for bugs marked as "good first bug", which have a status of "NEW".
Of course, this is a bit cumbersome to do and there are a lot of  bugs which are nontrivial or have a lot of discussion baggage which you may not want to go through. Fortunately, there are some tools out there that greatly help in searching for bugs.

Firstly, there's What Can I Do For Mozilla?. This is an interactive questionnaire that helps you find out which portions of Mozilla or Firefox you may be able to comfortably contribute to. Note that this is not just Firefox, though if you select the HTML or JS categories you will be presented with the Firefox subcategory which contains various entries.

This doesn't help find bugs as much as it helps you find the areas of the codebase that you might want to look at.

However, there is a different tool that is built specifically for this purpose; to look for easy bugs given one's preferences and capabilities. It's called Bugs Ahoy, and it lets you tick your preferences and programming languages to filter for bugs. It also has two insanely useful options, one that lets you filter out assigned bugs, and one that tells it to look for "good first bugs" ("simple bugs"). "Good first bug"s on Bugzilla are easy bugs which are kept aside for new users to try their hand at. There is a mentor for these bugs, who is a very active community member or employee. These mentors help you through the rest of the process, from where you need to look in the code to how to put up a patch. I've found that the mentors are very friendly and helpful, and the experience of being mentored on a bug is rather enjoyable.

Make sure the bug isn't assigned to anyone, and look through the comments and attachments for details on the status of the bug. Some bugs are still being discussed, and some bugs are half-written (it's not as easy to use these for your first bug). If you need help on choosing a bug, join #introduction on There are lots of helpful people out there who can give feedback on your chosen bug, and help you get started.

Step 2: Finding the relevant bits of codeIf this is a mentored bug, you usually can ask the mentor in a comment on the bug for help. Be sure to get it assigned to you! If the mentor doesn't respond in a few days, use the needinfo box at the bottom of the page:

Type the username (usually preceded by a colon somewhere in the full name string), and a suggestion box should pop up with various users. Pick your mentor out from the list, and ask for help in the comment box.
If you want to look for the code yourself, Mozilla Cross-Reference is a great tool. For Firefox, you probably want the mozilla-central subtree. With MXR, you can easily search the codebase for text, variable names, and regexes.
For most UI changes, you can track the code down by first looking for nearby strings.  For example, if you want to look at the code for the where-do-I-save-downloads preference which is preceded with the text "Save files to", the search result leads to a dtd file, which defines the entity saveTo.label as the string. (Remember, all displayed strings will be in a localization file). Searching for saveTo.label turns up main.xul. Now that you've found this, you can dig deeper by looking at the event handling and figuring out where the relevant javascript is, or you can look around this same file and figure out how it works, depending on what you want to fix.
I've not really made any changes to the C++ yet, only the toolkit and UI javascript, so I can't comment on how one can find the C++ code relevant to a bug. But you can always ask around in IRC or ask your mentor (if any) for help.

Step 3: Downloading and building the codeSee also: Simple Firefox build
Not all bugs need a build. Some are quite easy to do without having a full copy of the code or a build, and while you'll eventually want to have both of these, it is possible to hold this off for a while, depending on the bug. While it's easier to create patchfiles when the system is all set up, I will address patching without the full code in the next section.

Downloading can be done in two ways. Both require Mercurial to be installed (sudo apt-get mercurial works).

One way is to simply hg clone This will download the full repository. However, if you don't think your internet connection will be stable, download the mozilla-central bundle from here and follow the steps given there. Note that Mercurial is a bit different from Git, so you may wish to read up on the basics.

To build firefox , you first need to setup your build environment. If you already have Mercurial and Python installed on Linux/OSX, the build environment setup is simply ./mach bootstrap, run from the root directory of the cloned repository. For setting it up on Windows or for other corner cases, go here.

Once done, go to the root directory of the firefox code and run ./mach build. After your first build, you can run incremental builds (that only build the files you ask it to, and rebuilds any files depending on it) by using ./mach build <list of filepaths>, eg ./mach build browser/components/preferences/. You can specify both folders and files to the incremental build.

Note that for some javascript files, you have to build their containing directory — so if your changes aren't getting reflected in the incremental build, try building the directory they are in.

Step 4: Getting a patchSee also: How to submit a patchMercurial Queues
So by this point you will have figured out the fix and modified the code so that you have a partial (for a multifaceted bug) or full fix of the bug. At this point you can submit the patch for review. For this, you need to have a patch to submit first!

Creating patches with hg
If you have the full cloned repository, first add these lines to your ~/.hgrc to enable the mercurial queues extension with the proper settings.
username = Firstname Lastname

qnew = -Ue

mq =

git = 1
unified = 8
showfunc = 1

Once done, navigate to the firefox source tree and run hg qqueue -c somequeuenamehere. This will create a named patch queue that you can work on.

Now, run hg qnew patchname.patch and then hg qpush patchname.patch. This creates a new patch by that name in the .hg/patches-queuename folder, and pushes it onto the curretly applied stack of patches. You can update its contents with the changes made to the code by  hg qrefresh or simply hg qref.  This patch is the one that you can submit in step 5.

When you run hg qnew, it will ask you to enter a commit message. Write the bug name and a short description of the patch ("Bug 12345 - Frob the baz button when foo happens"), and add a ";r=nameofreviewer". In case of mentored bugs, the uername of the mentor will be your reviewer. If not, you'll have to find a reviewer (more details on this later, for now you may leave this blank and edit it in the patch file later). Note that the default editor for this is usually vim, so you have to press Ins before typing text and then Esc followed by a :x and Enter to save.

Advanced usage
In case of complicated bugs or bugs which already have a patch, you can queue the patches up. Simply use hg qnew to create patches and  hg qpush or hg qpop to move up and down the patch queue (this will change the code to reflect the currently active patch, and hg qref will update that same patch)

If you want to work on a different bug in parallel, you just have to pop all current patches out, and create a new patch queue with hg qqueue -c. You can then switch between the queues with hg qqueue queuename.

Creating patches without hg
Since the full repository takes a really long time to download and unpack, it's useful to have a different way of making patches so that the download doesn't become a blocking step.

For preliminary patches, with just one file
This is if you want to submit a patch that can be reviewed fr feedback but not checked in as a final patch. I wouldn't recommend using this method, but I'll keep these instructions here just in case.

If you're just editing one file, put the old version and the new version side by side, and run diff -u oldfile newfile >mypatch.patch in the same directory. Now, open the patch file and edit the paths to match the relative filepath of the edited file from the root firefox directory (eg if you edited main.xulold to main.xul, replace both names with browser/components/preferences/main.xul)

Proper patches
Put the files in a directory, and then run git init on the files. Now, git add *  and then git commit -m "commit message" to commit the files.
After this, make your changes to the files. Then, run git diff -U8 >output.patch . Edit the patch and change the a/filename and b/filename lines to be a/path/to/filename and b/path/to/filename. The paths here are relative with respect to the root directory.

Now, add the following to the top of the patch

# HG changeset patch
# Parent parenthash
# User Firstname Lastname>
Bug 12345 - Frob the baz button when foo happens; r=jawsSet the commit message as described in the above section for creating patches with hg.

As for the parent hash, you can ignore and remove the line (or get it by going to the mozilla-central hg repository and copying the hash of the tip commit).

Step 5: Submitting the patch, and the review processSee also: Getting reviews
Now that you're at this stage, the rest is pretty smooth sailing. Find the "add attachment"  link on the bugzilla page:

Upload the attachment, give it a descriptive name ("Patch for barring the foo", though sometimes I just use "Patch 0.1"), and make sure the "patch" checkbox is ticked

Now, you also need to ask for review. Click the dropdown next to the review menu, and set it to "?" ("requesting review"). Put the username of your reviewer in the "Requestee" box (and use the autosuggest to get the email address). If you don't know who to ask for review:
  • If the bug is mentored, your mentor will be able to review your code. Usually the mentor name will turn up in the "suggested reviewers" dropdown box in bold, too.
  • If the bug isn't mentored, you still might be able to find reviewers in the suggested reviewers dropdown. The dropdown is available for bugs in most firefox and b2g components.
  • Otherwise, ask around in IRC or check out the hg logs of the file you modified (start here) to find out who would be an appropriate reviewer.
  • A list of module owners and peers for each module can be found here (the Firefox and Toolkit ones are usually the ones you want). These users are allowed to review code in that module, so make sure you pick from those. If you mistakenly pick someone else, they'll usually be helpful enough to redirect the review to the right person.

Usually, on the first bug, your review will be canceled ("r-"). This is nothing to be worried about, the mentors (and/or reviewers) are very helpful and will let you know exactly what can be improved in the process. This is one of the things I like about Mozilla; everyone's quite helpful!
Once you fix the nits and other changes requested from you, re-upload the attachment (mark the old one as obsolete).
At one point, the review will be granted, and the code will be checked in. Once that happens, the bug will get marked as resolved. And you're done with your first bug!
Categorieën: Mozilla-nl planet

Jonathan Protzenko: Shutting down my (now redundant) comm-central clone on github

di, 22/04/2014 - 09:33

This is just a public service announcement: I'm shutting down the comm-central repository on github I've been maintaining since 2011. Please use the official version: they share the same hashes so it's just a matter of modifying the url in your .git/config. Plus, the official repo has all the cool tags baked in.

(Turns out that due to yet-another hg repository corruption, the repo has been broken since early March. Since no one complained, I suspect no one's really using this anymore. I'm pretty sure the folks at Mozilla are much better at avoiding hg repository corruptions than I am, so here's the end of it!).

Categorieën: Mozilla-nl planet

Justin Dolske: Satellite Radio

di, 22/04/2014 - 07:25

In my last blog post, I wrote about how I helped fund the launch of a satellite via KickStarter, and that after launch I would have more to say about receiving radio signals from it. This is that update.

The good news is that SpaceX’s Falcon 9 finally launched last Friday. It’s had two delays since the originally scheduled date of March 30th. No big deal, it happens. Here’s the launch video, showing liftoff, onboard rocketcam, staging, and separation of the Dragon cargo capsule: (YouTube)

This is the CRS-3 flight — the 3rd  Commercial Resupply Service flight hauling cargo to the International Space Station. With the retirement of the Space Shuttle, CRS flights are the only US vehicles going to ISS, although other countries have their own capabilities. This is also the first flight where SpaceX has successfully flown the first stage back to Earth for a landing (albeit in the ocean, for safety, as it’s still experimental). Usually rockets like this are expendable – they just reenter the atmosphere and burn up. But SpaceX plans to fly them back to reuse the hardware and enable lower costs. It’s a pretty stunning concept. There’s no video of CRS-3′s Falcon 9 returning (yet?), just two tweets confirming it was successful. But it just so happens they did a test flight last week that demonstrates the idea: (YouTube)

So back to to satellite I funded: KickSat. The “carrier” was successfully deployed, and the first telemetry packets have been received and decoded. In a couple of weeks (May 4th) it will deploy its 104 “Sprite” nanosatellites, which will each start broadcasting their own unique signals. Things are off to a great start!

The slightly bad news is that I haven’t been completely successful in capturing Kicksat broadcasts with my own ground equipment. Yet.

It’s challenging for a few reasons…

The biggest factor is that the signals are inherently just not very strong, due to power limitations. The KickSat carrier is a 3U cubesat, with limited area for solar-cells. It periodically broadcasts a brief telemetry packet with a 1-watt radio, which is what I’m trying to capture.

And of course the Sprites it carries are even smaller, and will only be transmitting with a mere 10mW of power. The silver area in the Sprite I’m holding below is where the solar cell goes. (It turns out that satellite-grade solar cells are export-restricted under US law, so the sample units shipped without ‘em!)

Such faint signals need some modestly specialized (but still off-the-shelf) equipment to enable reception. I’ve got a yagi antenna and low-noise amplifier, as recommended on the KickSat wiki. Successfully making use of it is a little tricky, though. You need to use orbit tracking tools (e.g. gpredict or via Heavens Above) to know when a satellite pass will occur, and where in the local sky its path will be. Yagis are directional, and thus need to be pointed (at least roughly) to the right place. Not every pass is directly overhead, and if it’s too low on the horizon it may be too hard to receive (due to strength or interference).

Additionally, KickSat only broadcasts a short packet once every 30 or 250 seconds (depending on what mode it’s in), and during a pass it’s only above the horizon for a few minutes. That makes for a rather ephemeral indication that it’s even there. Blink and it’s gone! My location has about 4 pass opportunities a day, but not all are useful.

Oh, and did I mention I’m doing this all with a cheap $20 RTL2832U software defined radio?! Heck, the coax cables connecting my dongle to the antenna cost more than the radio itself!

I decided to start off by first trying to catch signals from some other satellites. I went through AMSAT’s status page and DK3WN’s fantastic satellite blog and gathered a list of a couple dozen satellites known to be active on the same 70cm (~435Mhz) band KickSat is using.

My first success was HO-68 (aka Hope Oscar 68 aka XW-1). This is a Chinese satellite launched in 2009, broadcasting a fairly constant 200mW telemetry “beacon” in morse code. Picking out the dotted line in the GQRX waterfall display was pretty easy, even though it’s not exactly on the expected 435.790Mhz frequency due to inaccuracies in my radio and doppler shift(!).

This is what it sounds like: WAV | OGG. Why is the tone shifting? The gradual lowering is doppler shift. The abrupt jumps upward are just from me adjusting the radio tuning to keep it audible. My morse code skills are terrible, but I replayed it enough times to convince myself that it starts out with the expected “BJ1SA XW XW” (the radio sign and initials of its name), per the page describing the signal format. For the lazy, that’s – . . . / . – - – / . – - – - / . . . / . – / – . . – / . – - / – . . – / . – - in morse code.

Next up was FO-29.

Here’s a screengrab of gpredict, showing the predicted path low in the sky, from the southeast to north.

It’s got a stronger 1-watt beacon, which wasn’t too hard to spot. Here I’ve switched from GQRX on OS X to SDRSharp on Windows. It has more features, plugins, and makes it easy to zoom in on a signal. The signal with doppler-shift is readily apparent as a diagonal line.

Audio of FO-29′s beacon: WAV | OGG. Despite the stronger transmitter, the received signal is weaker (probably due to being low on the horizon), and the the morse code is sufficiently fast that I’m not able to decode it by ear. (There’s an app for automatic decoding, but I haven’t tried it yet.)

And lastly… *drumroll*… After a number of unsuccessful attempts to receive KickSat’s signal, I finally caught it today! There was a nearly-overhead pass in the afternoon, so the as-received signal strength was optimal.

I pointed my antenna upwards, tilted it to my clear northeast view, tuned SDRSharp to the 437.505 MHz KickSat frequency, and waited. This is one of the usecases where software radio is really useful… While waiting, I was was recording the entire raw ~2Mhz slice of bandwidth around that frequency. That’s 4.5GB for the 7 minutes I was recording. I actually missed the transmission the first time, as it’s indicated about 23kHz lower than expected (again, due to hardware inaccuracies and doppler shift). But no big deal, I just replayed the recorded data and fine tuned things to the right spot.

Here’s what it sounds like: WAV | OGG. Unlike the steady stream of analog dit-dahs from HO-68 and FO-29, this is just 2 seconds of digital “noise”, like you would hear from a dialup modem. In fact, it’s exactly what you’d hear from an old modem. KickSat is using the 1200bps AFSK-modulated format, which is apparently still widely used in amateur packet radio. There are decoders available to extract the digital data (GQRX has one built in, and SDRSharp output can be piped to the qtmm AFSK1200 decoder).

If you’ve got SDRSharp, here’s the raw IQ data for the packet (ZIP, 60.3MB). I cropped the data to just the relevant portion. Alas, I can’t seem to get the decoder to recognize the packet. :( I’m not quite sure what the problem is yet… I’ve successfully decoded other AFSK data with this setup, so I suspect my signal was just too weak/noisy. Could be poor antenna pointing, but this was an easy pass. Some folks have had success with improving SNR with shielding, but I haven’t been able to replicate their results. There are a number of knobs and dials in SDRSharp to adjust manual/automatic gain control, so I might need to tweak that. (Unfortunately difficult, as there are only a few brief chances a day to catch KickSat.) It’s also possible that this is just slightly beyond the capabilities of a $20 RTL2832U dongle. Other options exist. I’d love to get a HackRF SDR board, but they’re not available yet. The FUNcube Dongle Pro+ can be had for about $200, but from comparisons I’m not sure exactly how much better it is in this band, or if it’s worth it. I’d love to hear opinions from hams who know this stuff better, or have tried both!

Amusing aside: while poking around in the 70cm band for interesting things, I stumbled across Santa Clara County’s ARES/RACES packet radio BBS. (Apparently, Ted, that is indeed still a thing!) In fact, FO-29 is actually an orbiting BBS! It’s quaintly amusing in the Internet Age, but when it launched in 1990 it must have been amazing. I had just upgraded to a 2400bps modem and discovered FidoNet and UUCP to reach beyond the local area code BBS systems.

That’s it for now. Over the next few weeks I’ll be refining my equipment and skills, and hope to capture some solid transmissions by the time my Sprite deploys. That will be even tougher to catch, but it’s a fun challenge!

Categorieën: Mozilla-nl planet

Pascal Finette: Anatomy of a Speech

di, 22/04/2014 - 01:21

A few weeks ago I was invited to speak at the World Business Dialogue in Cologne, Germany on “Tech for Good”.

As part of my speech I prepared speaking notes for the deck I was using. Below you’ll find the raw notes – this is the completely unedited version I wrote to prepare myself for the speech a day before the event itself.

I figured it might be fun to get a peek into the ugly underbelly of making a public speech.

[1] Good afternoon. Let’s talk a bit about what I mean when I talk about technology for good, why it’s important and why I am so passionate about it that I spent considerable amounts of my time working on it.

[2] Over the last century we experienced a rapidly accelerating curve of progress - all driven by technology. We long left the linear growth path and are on an accelerated exponential curve.

You might have heard of Moore’s Law: Intel’s founder Gordon Moore predicted that computers will double in speed about every two years. That’s linear growth. And it’s not true for a lot of technologies anymore - we far exceed this growth pattern.

Let me give you just two examples:

[3] 5 Exabytes of information, that’s a one with 18 zeros, is the amount of information all of mankind produced since the beginning of time until the year 2003.

In 2010 we produced the same amount of information every two days.

Last year we produced those 5 exabytes every 10 minutes.

[4] When the human genome project first sequenced the full human genome we spend about 10 years and 3 billion dollars on it. That was around the year 2000.

In 2006 we brought the price down to $10 million dollars and a few months of sequencing time.

This year you can get your genome sequenced for a mere $1,000 in just a few hours.

[5] These are all exponential trends. They happen in industry after industry - and yet, as humans, we are poorly equipped to identify them.

Take this curve of mobile phone adoption over time: Every single time an expert made a projection their prognosis was way off - and linear. We kept saying: We have reached the tipping point, technology doesn’t get any cheaper, faster or better anymore by the same rate we saw before. And we were wrong.

So why is this important? Because we need to push the envelop to solve some of the worlds most intractable problems.

[6] In 2050 we will have 9 billion people on this planet. To feed them we need to grow agricultural output by 2% year over year. Current technology only produces a 1% year over year gain.

[7] Today 3 billion people live on less than $2.5 a day - that’s about half what your cup of fancy Starbucks coffee cost you.

[8] Currently 800 million people don’t have access to clean drinking water. Not running water in their homes - any form of clean drinking water even from a well 10 miles away.

[9] 2.5 billion people around the world don’t have access to sanitation. Which effectively means open defecation - which results in countless health issues.

[10] We need to create 600 million new jobs in the next 15 years to sustain current employment rates.

And yet…

[11] When it comes to technology too many of us focus on building the next version of this.

Let me give you a few examples of technology solving real world problems at scale:

[12] 30% of all water pumps in the 3rd world don’t work. Nobody knows which ones. The movie which plays again and again is: Aid organizations go into a village, build a well, leave and a year or so later the well doesn’t work anymore.

[13] A San Francisco startup builds this sensor which measures water flow speed and even monitors water quality, sends this information wirelessly to a central command center and allows, for the first time, so see which wells operate well, which need servicing and so on. These sensors cost less than $30 and are currently deployed in Africa by Charity Water.

[14] Or take vaccination: 20% of all vaccines administered in the 3rd world are spoiled due to a break in the cold chain. In the best case this leads to ineffective vaccines, in the worst case it kills people. In any case - it leads to massive challenges if we want to eradicate diseases.

[15] A Boston-based startup developed this wirelessly controlled sensor which monitors temperature every few minutes, sends the data to a server and allows not only to find out if a particular vaccine is spoiled but also where in the chain it spoiled and thus allows, for the first time, to fix and optimize cold chains.

[16] And take natural disasters. One of the big challenges in disaster areas is that often vital infrastructure such as roads is destroyed. To get intel and aid into these regions we fly helicopters and airplanes - very expensive, hard to pull off (you need a working air strip etc), complicated.

[17] This copter-drone, developed by a team at Singularity University costs $2000, delivers up to 20 pounds of medication and provides valuable on-the-ground intel to aid workers.

[18] In summary: We need to develop new and novel ways to solve some of the worlds largest problems. Those solutions need to be deployed at scale. Technology is our ticket out of this situation. Pushing the curve towards exponential growth is what’s needed.

[19] And make no mistake: This is not only charity but good business. People who live on $2.50 a day still spend those $2.50. They just can’t buy good products at the moment. These are markets with hundreds of millions and billions of people.

Categorieën: Mozilla-nl planet

Frédéric Harper: YulDev, connecting with other developers

ma, 21/04/2014 - 17:46



Montreal’s Developers, would you like to have more occasions to network with your peers, no matter which technology they are using? If it’s the case, YulDev is for you: a new monthly meetup where you can network with developers, and talk about whatever you like. The simplicity of just discussing code (or anything else) with a drink (juice, coffee, beer, glass of wine…) and other developers.

We are lucky in Montreal: there are many user groups for developers! Most of them have one point in common: they often focus on one technology or a group of related ones, and the primary goal is to learn from a speaker. Like you, I have much interest when it comes to technology, but I also have limited time in a week. Therefore, I cannot attends all the user groups or events I would like too, and I feel I’m missing opportunity to meet new amazing developers. With this in mind, I created YulDev, a Montreal style (French & English) user group or I should say, networking group as there will be no presentation (maybe greetings from your host in the beginning, but nothing else). In a 6@8 formula, the goal of this monthly event is to mingle, talk with people you know, and of course, meet new one. You never know what will happen next: new job, new friend, possible customer, a startup idea, interest in a new language, discovering a new user group you did not know about, and of course, an amazing evening with great developers.

So don’t wait, join the group, share about it with your co-workers, and RSVP for our first meetup in May. Don’t underestimate the power of networking in our industry!

P.S.: If you are the lead of a group for developers in Montreal or a media, and would like to promote YulDev, please let me know. If you are a company, and would like to sponsor the group, let’s talk about it (more information soon about our needs).

YulDev, connecting with other developers is a post on Out of Comfort Zone from Frédéric Harper

Related posts:

  1. User groups: learn, meet and share Please note that this blog post talk about Make Web...
  2. So you want to find a co-founder for your startup idea in Montreal? I’ve got asked quite often about the startup industry in...
  3. Empower Mobile Web Developers with JavaScript & WebAPI at PragueJS HTML5 is a giant step in the right direction: it...
Categorieën: Mozilla-nl planet

Joel Maher: Hi Vikas Mishra, welcome to the Mozilla community!

ma, 21/04/2014 - 14:38

I remember right before the winter break where I was off for a couple of weeks to end the year, A new person showed up and started working on some of my bugs. This was Vikas and he was eager and motivated to do a lot of great things.  Fast forward to today, and I still chat with Vikas weekly in irc.  When he gets a break from school and other activities of interest, he will be hunting for bugs to fix and usually knocking them out 3 or 4 at a time. In fact, I was surprised when I did a query on bugzilla, and on github to see that he is involved in a variety of projects at Mozilla such as Phonebook, Marionette, Talos, and test automation.

I wanted to learn more about Vikas, so I asked him some questions

Tell me about where you live?

Currently I live in Goa, India which is famous for its beaches and attracts many tourists from both India as well as foreign nationals. The best thing about this place is my campus which feels like a home away from home now. I like this place for its beautiful weather, its beaches and ever friendly nature of people living here. This place has brought  a lot of changes in my personality and has given me a chance to make some new friends who are always ready to help.

Tell me about your school?

I am a first year undergraduate student at Birla Institute of Technology and Science Pilani, Goa Campus (popularly known as BITS Pilani Goa) pursuing Msc.(Hons) Economics. I am enrolled in a dual degree scheme offered by my college where in I get an option to take a B.E degree depending on my first year’s performance and I hope to get a C.S major. My favorite subject so far has been Computer Science as I’ve always been fascinated towards computers and love to code

How did you get involved with Mozilla?

My first interaction with the Mozilla community was when I started using firefox few years back. Last December I decided to start contributing to some open source organizations and searched for organizations to start with and decided to go with Mozilla. I started with Mozilla since its a very large community so there’s always lots of help available. My experience with Mozilla community so far has been absolutely great, I had no idea how the open source community works and was afraid to ask silly questions as I thought people wont have time to answer those questions. I remember when I was assigned my first bug and Joel Maher was my mentor, while setting the local environment I kept on getting errors and used to pastebin those to him and it took me hours to set it up but he was totally cool with it even though I  myself was annoyed with those ever lasting errors. Even now I get stuck at some places but he’s always there to help me. Besides him there are other members too who have helped a lot and are always ready to help if required. My experience so far has been brilliant and am looking forward to learning new things and meeting some great people in the future as well.

What hobbies and activities do you enjoy doing?

Nowadays I spend most of my time coding and learning new stuff. I love the concept of open source software and love to interact with the community and gain valuable experience. Besides coding I enjoy playing football, cricket, and am a complete movie buff. I also love to hang out with friends and spend time with them.

Where do you see yourself in 5 years?

Down the lane in 5 years I see myself as a software engineer working for Mozilla (preferably in the Ateam) solving problems and developing new tools.

What advice would you give someone?

Although I don’t see myself as someone who can advise about life but If someone asked me I’ll advise him/her to enjoy life to the fullest and do whatever he/she loves to do no matter what others expect them to do and if they are related to the software industry obviously I’ll advise them to contribute to the open source community :)


I have enjoyed watching Vikas learn his way around Mozilla.  If you have worked with him, you probably already know why I have enjoyed my interactions with him, if you haven’t had the chance to work with him, say hi in irc, his nick is :mishravikas.

Categorieën: Mozilla-nl planet

Will Kahn-Greene: Dennis v0.3.11 released! Fixes and Python 3 support

ma, 21/04/2014 - 14:00
What is it?

Dennis is a Python command line utility (and library) for working with localization. It includes:

  • a linter for finding problems in strings in .po files like invalid Python variable syntax which leads to exceptions
  • a statuser for seeing the high-level translation/error status of your .po files
  • a translator for strings in your .po files to make development easier
v0.3.11 released!

v0.3.11 adds Python 3 support (there might be problems, but it's working for me) and adds error detection for the case where there's a } but no {.

Definitely worth updating!

8 out of 11 people who have heard of Dennis and continue to ignore its baby mews of wonderfulness also have a severe allergy to rainbows and kittens.

Categorieën: Mozilla-nl planet

Nick Cameron: Rust for C++ programmers - part 2: control flow

zo, 20/04/2014 - 10:45
IfThe `if` statement is pretty much the same in Rust as C++. One difference is that the braces are mandatory, but brackets around the expression being tested are not. Another is that `if` is an expression, so you can use it the same way as the ternary `?` operator in C++ (remember from last time that if the last expression in a block is not terminated by a semi-colon, then it becomes the value of the block). There is no ternary `?` in Rust. So, the following two functions do the same thing:
fn foo(x: int) -> &'static str {
    let mut result: &'static str;
    if x < 10 {
        result = "less than 10";
    } else {
        result = "10 or more";
    return result;

fn bar(x: int) -> &'static str {
    if x < 10 {
        "less than 10"
    } else {
        "10 or more"
}The first is a fairly literal translation of what you might write in C++. The second is in better Rust style.

You can also write `let x = if ...`, etc.

LoopsRust has while loops, again just like C++:fn main() {
    let mut x = 10;
    while x > 0 {
        println!("Current value: {}", x);
        x -= 1;
}There is no do...while loop in Rust, but we do have the `loop` statement which just loops forever:fn main() {
    loop {
        println!("Just looping");   
}Rust has `break` and `continue` just like C++.For loopsRust also has `for` loops, but these are a bit different. Lets say you have a vector of ints and you want to print them all (we'll cover vectors/arrays, iterators, and generics in more detail in the future. For now, know that a `Vec<T>` is a sequence of `T`s and `iter()` returns an iterator from anything you might reasonably want to iterate over). A simple `for` loop would look like:fn print_all(all: Vec<int>) {
    for a in all.iter() {
        println!("{}", a);
}If we want to index over the indices of `all` (a bit more like a standard C++ for loop over an array), you could dofn print_all(all: Vec<int>) {
    for i in range(0, all.len()) {
        println!("{}: {}", i, all.get(i));
}Hopefully, it is obvious what the `range` and `len` functions do. Switch/MatchRust has a match expression which is similar to a C++ switch statement, but much more powerful. This simple version should look pretty familiar:fn print_some(x: int) {
    match x {
        0 => println!("x is zero"),
        1 => println!("x is one"),
        10 => println!("x is ten"),
        y => println!("x is something else {}", y),
}There are some syntactic differences - we use `=>` to go from the matched value to the expression to execute, and the match arms are separated by `,` (that last `,` is optional). There are also some semantic differences which are not so obvious: the matched patterns must be exhaustive, that is all possible values of the matched expression (`x` in the above example) must be covered. Try removing the `y => ...` line and see what happens; that is because we only have matches for 0, 1, and 10 and obviously there are lots of other ints which don't get matched. In that last arm, `y` is bound to the value being matched (`x` in this case). We could also write:fn print_some(x: int) {
    match x {
        x => println!("x is something else {}", x)
}Here the `x` in the match arm introduces a new variable which hides the argument `x`, just like declaring a variable in an inner scope.

If we don't want to name the variable, we can use `_` for an unnamed variable, which is like having a wildcard match. If we don't want to do anything, we can provide an empty branch:fn print_some(x: int) {
    match x {
        0 => println!("x is zero"),
        1 => println!("x is one"),
        10 => println!("x is ten"),
        _ => {}
}Another semantic difference is that there is no fall through from one arm to the next.

We'll see in later posts that match is extremely powerful. For now I want to introduce just a couple more features - the 'or' operator for values and `if` clauses on arms. Hopefully an example is self-explanatory:fn print_some_more(x: int) {
    match x {
        0 | 1 | 10 => println!("x is one of zero, one, or ten"),
        y if y < 20 => println!("x is less than 20, but not zero, one, or ten"),
        y if y == 200 => println!("x is 200 (but this is not very stylish)"),
        _ => {}
}Just like `if` expressions, `match` statements are actually expressions so we could re-write the last example as:fn print_some_more(x: int) {
    let msg = match x {
        0 | 1 | 10 => "one of zero, one, or ten",
        y if y < 20 => "less than 20, but not zero, one, or ten",
        y if y == 200 => "200 (but this is not very stylish)",
        _ => "something else"

    println!("x is {}", msg);
}Note the semi-colon after the closing brace, that is because the `let` statement is a statement and must take the form `let msg = ...;`. We fill the rhs with a match expression (which doesn't usually need a semi-colon), but the `let` statement does. This catches me out all the time.

Motivation: Rust match statements avoid the common bugs with C++ switch statements - you can't forget a `break` and unintentionally fall through; if you add a case to an enum (more later on) the compiler will make sure it is covered by your `match` statement.Method callFinally, just a quick note that methods exist in Rust, similarly to C++. They are always called via the `.` operator (no `->`, more on this in another post). We saw a few examples above (`len`, `iter`). We'll go into more detail in the future about how they are defined and called. Most assumptions you might make from C++ or Java are probably correct.
Categorieën: Mozilla-nl planet

Rizky Ariestiyansyah: Tnotify, a Terminal Notification

zo, 20/04/2014 - 05:42
Hello guys, this is short post to tell you about tnotify the easiest, most attractive way to fire off notifications from your terminal. This application is available on ruby gem repository, you know why...
Categorieën: Mozilla-nl planet

Gervase Markham: 10 Year Blogaversary

za, 19/04/2014 - 21:12

10 years ago today, I started blogging.

At the time, I thought I was rather late to the blogging party. In hindsight, it seems not. Since then, through one change of host (thanks, Mozillazine!), there have been 1,463 posts (including this one), and 11,486 comments. Huge thanks to everyone who’s read and/or commented (well, if you commented without reading, not so much) in the last 10 years. It’s uncertain whether I or the blog will last another 10 (the Lord is in control of that) but here’s to however long it is!

Categorieën: Mozilla-nl planet