mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla gemeenschap

Will Kahn-Greene: Input status: July 20th, 2014

Mozilla planet - snein, 20/07/2014 - 13:37
Summary

This is the status report for development on Input. I publish a status report to the input-dev mailing list every couple of weeks or so covering what was accomplished and by whom and also what I'm focusing on over the next couple of weeks. I sometimes ruminate on some of my concerns. I think one time I told a joke.

Last status report was at the end of June. This status report covers the last few things we landed in 2014q2 as well as everything we've done so far in 2014q3.

Development

Landed and deployed:

  • 6ecd0ce [bug 1027108] Change default doc theme to mozilla sphinx (Anna Philips)
  • 070f992 [bug 1030526] Add cors; add api feedback get view
  • f6f5bc9 [bug 1030526] Explicitly declare publicly-visible fields
  • c243b5d [bug 1027280] Add GengoHumanTranslater.translate; cleanup
  • 3c9cdd1 [bug 1027280] Add human tests; overhaul Gengo tests
  • ff39543 [bug 1027280] Add support for the Gengo sandbox
  • 258c0b5 [bug 1027280] Add test for get_balance
  • 44dd8e5 [bug 1027280] Implement Gengo Human push_translations
  • 35ae6ec [bug 1027280] Clean up API code
  • a7bf90a [bug 1027280] Finish pull_translations and tests
  • c9db147 [bug 1027286] Gengo translation system status
  • f975f3f [bug 1027291] Implement spot Gengo human translation
  • f864b6b [bug 1027295] Add translation_sync cron job
  • c58fd44 [bug 1032226] en-GB should copyover, too
  • 7480f87 [bug 1032226] Tweak the code to be more defensive
  • 7ac1114 [bug 1032571] CSRF exempt the API
  • ac856eb [bug 1032571] Fix tests to catch csrf issues in the api
  • 74e8e09 [bug 1032967] Handle unsupported language pairs
  • 74a409e [bug 1026503] First pass at vagrantification
  • a7a440f Continued working on docs; ditched hacking howto
  • 44e702b [bug 1018727] Backfill translations
  • 69f9b5b Fix date_end issue
  • e59d4f6 [bug 1033852] Better handle unsupported src languages
  • cc3c4d7 Add list of unsupported languages to admin
  • 32e7434 [bug 1014874] Fix translate ux
  • 672abba [bug 1038774] Hide responses from hidden products
  • e23eca5 Fix a goof in the last commit
  • 6f78e2e [bug 947767] Nix authentication for API stuff
  • a9f2179 Fix response view re: non-existent products
  • e4c7c6c [Bug 1030905] fjord feedback api tests for dates (Ian Kronquist)
  • 0d8e024 [bug 935731] Add FactoryBoy
  • 646156f Minor fixes to the existing API docs
  • f69b58b [bug 1033419] Heartbeat backend prototype
  • f557433 [bug 1033419] Add docs for heartbeat posting

Landed, but not deployed:

  • 7c7009b [bug 935731] Switch all tests to use FactoryBoy
  • 2351fb5 Generate locales so ubuntu will quite whining (Ian Kronquist)

Current head: 7ea9fc3

High-level

At a high level, this is:

  1. Landed automated Gengo human translation and a bunch of minor fixes to make it work more smoothly.
  2. Reworked how we build development environments to use vagrant. This radically simplifies the instructions and should make it a lot easier for contributors to build a development environment. This in turn should lead to more people working on Input.
  3. Fixed a bug where products marked as "hidden" were still showing up in the dashboard.
  4. Implemented a GET API for Input responses. (https://wiki.mozilla.org/Firefox/Input/Dashboards_for_Everyone)
  5. Implemented the backend for the Heartbeat prototype. (https://wiki.mozilla.org/Firefox/Input/Heartbeat)
  6. Also, I'm fleshing out the Input section in the wiki complete with project plans. (https://wiki.mozilla.org/Firefox/Input)
Over the next two weeks
  1. Continue fleshing out project plans for in-progress projects on the wiki.
  2. Gradient sentiment and product picker work.
What I need help with
  1. We have a new system for setting up development environments. I've tested it on Linux. Ian has, too (pretty sure he's using Linux). We could use some help testing it on Windows and Mac OSX.

Do the instructions work on Windows? Do the instructions work on Mac OSX? Are there important things the instructions don't cover? Is there anything confusing?

http://fjord.readthedocs.org/en/latest/getting_started.html

  1. I'm changing the way I'm managing Fjord development. All project plans will be codified in the wiki. A rough roadmap of which projects are on the drawing board, in-progress, completed, etc is also on the wiki. I threw together a structure for all of this that I think is good, but it could use some review.

Do these project plans provide useful information? Are there important questions that need answering that the plans do not answer?

https://wiki.mozilla.org/Firefox/Input

If you're interested in helping, let me know! We hang out on #input on irc.mozilla.org and there's the input-dev mailing list.

I think that covers it!

Categorieën: Mozilla-nl planet

Mozilla's Firefox OS is NO JOKE: Comes to Germany, France and Asian ... - Gigjets

Nieuws verzameld via Google - snein, 20/07/2014 - 12:24

Mozilla's Firefox OS is NO JOKE: Comes to Germany, France and Asian ...
Gigjets
And the latest news seems to suggest that Mozilla's plans are going forward with their product. Albeit Firefox OS is mainly aimed at developing countries, Mozilla has partnered with various carriers across many developed countries and it will soon ...

Google Nieuws
Categorieën: Mozilla-nl planet

Soledad Penades: “Just turn it into a node module”, and other mantras Edna taught me

Mozilla planet - sn, 19/07/2014 - 23:41

Here are the screencast and the write up on the talk I gave today at One-Shot London NodeConf. As usual I diverge a bit from the initial narrative and I forgot to mention a couple of topics I wanted to highlight, but I have had a horrible week and considering that, this has turned out pretty well!

It was great to meet so many interesting people at the conference and seeing old friends again! Also now I’m quite excited to hack with a few things. Damn (or yay!).

Slides and code for the slides.

Creative technologist

creative technologist

A little more than a year ago I started working at an agency in London as a creative technologist. It was fun to be trying out all the new things and building cool experiences with them. So whatever new APIs were out there, we would come up with some idea to use them. Sometimes that would be because the client wanted to be “first” in using that browser functionality so theirs would be the first website that did X and that would drive a ton of traffic to them, and other times we just wanted to do some cool experiment for our own website so we would master that technology and also attract traffic and get new clients–that’s how it works in advertising.

We mostly used JavaScript on the front-end (except some old remains from the past built in Flash). On the server, we used a mix of Python and node.js. Most of the Python was actually for setting up websites and authentication in Google App Engine which is what they used to host the websites (so the server wouldn’t go down when the site got popular), but for all the real time communication we used Socket.io running in node.js because it was way easier than Python alternatives.

I had been toying with node.js on and off for a while already, but this was when I started to actually believe that I could just use JS for everything… even build scripts!

The worst habits

But I had the worst habits after a life of many other programming languages, and although I wasn’t consciously aware of them, I knew that something didn’t feel quite right. But what? It was hard to say when everyone else in your environment was OK with whatever solution you came up with as long as it worked well enough and you delivered on time.

This was also part of why I joined Mozilla–I was feeling super guilty that we were building things that were not using standards and they would break in the future, or even worse, set bad precedents and habits. I didn’t want to contribute to a web where the cool experiences only worked on one browser, but I wanted to contribute to make the web more powerful and expressive.

My buddy Jen

cult leader

A couple of months later, I was in Mountain View for my onboarding week. I was disoriented and jetlagged, but also very excited and scared! And more people on from my future team were in Mountain View for that week. One of them, Jen, sent me a message pretty much just as I checked in into the hotel: “hey, ready for dinner?”

I hadn’t even met her or spoken to her during the interviews, so I wasn’t even sure how did she look like in real life. I washed my face and told to myself in the mirror that it was 6pm, NOT 2 AM as my body was trying to protest, and that everything was OK. And went downstairs to meet her.

She was waiting in the parking lot. I had only seen a tiny picture of her with shorter hair in her (very prolific) github profile, but honestly, who waits alone in the parking lot of a hotel in Mountain View at 6pm on a Sunday? We said “hi” and she said: “it’s my birthday today, and I want to have a nice dinner”. Would I oppose such thing? No!

Jen’s a philosopher, therefore she philosophises

best github account ever

We walked to Castro street, spending some time admiring the peculiarities of the business on either side of El Camino Real. You might have a chiropractice, a massage parlour, a beauty salon, and a gun seller, all side by side. It was all very amusing. Then we went into a Moroccan restaurant, and we had to prove our age by showing our respective passports, which was amusing again.

So we started talking about the food first… how it didn’t taste like anything Moroccan I had had before, and whether the Moroccan food I had had either in London or Paris could be considered authentic, or more authentic than this–based on closeness to the “source”. But you can only analyse food so much, so we switched to other topics and at the end of dinner she was telling me how she was going to build a distributed blog system but she would do it into a module so she could then reuse it for other things because it would be generic enough and… with the wine and the jetlag I was really finding it hard to follow.

She continued discussing and elaborating on these ideas during the week. She was hacking on a module that would be called meatspace. And she excitedly told me: “to empty it you would just call the flush method!”. Not being a native English speaker, I didn’t understand what ‘meatspace’ meant initially, so the whole naming seemed disgusting to me. Flushing meat drown the drain to empty the stored messages! GROSS.

rtcamera

My first task to get acquainted with the Mozilla process was to port or rewrite one of my existing Android apps to the web. WebRTC support was coming up soon in Firefox, so I opted to build something similar to Nerdstalgia. And I built something, and then I had Jen code review it. I didn’t know it initially, but she had been appointed my “Moz buddy”, to guide me around and introduce me to the usual processes.

She would keep mentioning this notion of “making things into modules” but I still didn’t quite get it. I regularly extracted my code into libraries, right? So why all this insistence on modules?

Modules

Intrigued (or sparkled) by her insistence, I started extracting modules out of rtcamera. The first one was the Animated_GIF library, and then gumHelper. This was quite providential because a while later she was exploring this idea of a distributed multiuser chat that could use your webcam to capture your facial expression, and because we had these libraries handy, adding them to the stack was very easy. You might, or might not, have heard of a thing called Meatspace Chat

Frida is my muse
Frida is one of Jen’s cats. This is Frida after seeing comma-first JS, according to Potch.

Something that really helped me “get the node way” were her comments on how to pass parameters, and callbacks. This was one of the reasons why I felt my node.js code didn’t feel ‘right’, and that’s because I was using my own adhoc style which was the result of having programmed in many languages but not being profficient in node.js – so I wasn’t using their idioms, and my code felt weird when using other people’s code–even system modules such as fs.

She insisted a lot on using a standard “callback signature” — the function(err, result) style which honestly drove me a bit nuts at the beginning. But if you’re using the same style throughout the code you can exchange node modules or even send the callback to another function, and it’s easier than if you have different signatures on each library.

Simplify

Another of her lessons was that if you were trapped in callback hell, maybe you were doing it conceptually wrong. Maybe you should be simplifying your code so you do calls in a different way. I am not totally sure of what I like most yet–promises or just plain callbacks, but I see her point, and oftentimes I would bring a Promises library to my project, then after refactoring the code so it would be suitable for promises I find that I don’t really need them at all.

Likewise for user interfaces–most of the time we agonise over how pretty something has to look but the fact is that the site might not provide any value to a user and so they leave. We should focus on the experience first, and then maybe we can make the things prettier.

npm

Another important lesson: it’s totally OK to use other people’s modules! Believe it or not, my initial node code almost didn’t use anyone’s modules, and if I used external code that was because I downloaded the code and copied it to the src folder AND loaded it with a local require path. npm? What was that thing?

Funny fact: I was watching RealtimeConf’s live stream because Jen was doing a talk on all the experiments she had been working on and was going to present Meatspace chat for the first time, and so I stayed for a while. And then I learnt a nice lesson not from her directly but from Max Ogden on his RealtimeConf talk: you don’t need to care about the code style in a node module, as long as it works. If it doesn’t, either you replace that module with another one, or you fix it. And again, if you’re using the same signature, this is easier to accomplish–you’re just replacing “boxes”.

Having tests is incredibly useful for this. Jen often writes the module tests first and then the module code itself–so she defines the API that way and sees if it feels natural and intuitive.

At this point there’s no UI code yet, just tests that make sure the logic works. If you can run the same test input data through two different modules you can make sure they do what they are supposed to do, and can also compare their performance or whatever nit is that makes you want to switch modules. This again is way easier if your function signatures are “standard node.js style”.

Browserify

I heard about this one actually the same week I started in Mozilla. But I was unable to appreciate its awesomeness–I was just used to applying Google Closure compiler to my concatenated code and calling it a day. I either concatenated the code with a nice

cat *.js > all.js

or maybe I built Python scripts that would read certain code files and join them together before either invoking a local version of the closure compiler (which was Java), or would send the uncompressed code to the Google Closure service to hopefully get it back, if there weren’t any errors.

But I quickly forgot about it. About some time later, I was looking into building a somewhat complex thing for my JSConf.EU project, and somehow Jen reminded me about it.

This project was a fun one, because I was using everything on it: server side node with Express.js serving the slides, which were advanced according to the music player with virtual Web Audio based instruments that was running on the browser, plus I had Socket.io sending data to and from a hardware MIDI device through OSC. So there were lots of data to pass back and forth and lots of modules to orchestrate, and including script tags in the browser wasn’t going to work well if I wanted to stay sane. So all the front-end code was launched using Browserify.

Another favourite anecdote in this project is that I in fact extracted several modules out of it, with tests and all, that I then reused in other projects. So I was taking advantage of my own work later on, and I like to think that when this happens, more people might find it useful too.

Multiplatform

Finally–and this is not a thing that only Jen taught me– one of the reasons why we like node a lot in Mozilla is because it makes it so much easier to write code that works everywhere. And with that I mean different platforms. As long as node can run in that system, the code can run.

This is very important because most of the times developers assume that everyone else is running the same system they are developing on, and in rich countries this often means the assumption that people use Macs, but that’s not the case everywhere, and certainly not in poorer countries. They use Windows or Linux, and setting up a toolchain to have a working make tool with which to run Makefile is either harder or not for the faint of mind.

So in this context, distributing build scripts written for node.js is way more democratic and helps us get our code to more people than if we used Make or Bash scripts.

And here comes one of my favourite stories–when one of the meatspacers sent me a PR to improve the build system of one of the libraries I had extracted and make it use node.js with uglify instead of the bash script I was using. That simple gesture enabled all the Windows developers to contribute to my module!

Conclusions
  • node modularity is awesome, but it takes time to ‘get it’. It’s OK to not to get things at the first try.
  • If you can find a mentor, it will help you ‘get it’ faster.
  • Otherwise maybe hang on the proper channels (irc, user groups, blogs, confs), study other people’s code and BE A SPONGE (a nodesponge?)
  • Don’t be afraid to experiment but also use the safety harness: tests!
  • And don’t be afraid to publish your code – maybe someone else will find it useful OR give you advice to improve it!

flattr this!

Categorieën: Mozilla-nl planet

Mozilla integriert OpenH264 Video Codec von Cisco in Firefox 33 - soeren-hentzschel.at

Nieuws verzameld via Google - sn, 19/07/2014 - 15:27

Mozilla integriert OpenH264 Video Codec von Cisco in Firefox 33
soeren-hentzschel.at
Mozilla integriert Ciscos OpenH264-Codec für WebRTC-Kommunikation in Firefox 33, genauer gesagt in Form eines automatischen Downloads eines sogenanntes Gecko Media Plugins, einer neuen Form von Plugins in Firefox. Als Cisco vor einigen ...

Google Nieuws
Categorieën: Mozilla-nl planet

Adam Lofting: 2014 Contributor Goals: Half-time check-in

Mozilla planet - sn, 19/07/2014 - 08:10

We’re a little over halfway through the year now, and our dashboard is now good enough to tell us how we’re doing.

TL;DR:
  • The existing trend lines won’t get us to our 2014 goals
    • but knowing this is helpful
    • and getting there is possible
  • Ask less: How do we count our contributors?
  • Ask more: What are we doing to grow the contributor community? And, are we on track?
Changing the question

Our dashboard now needs to move from being a project to being a tool that helps us do better. After all, Mozilla’s unique strength is that we’re a community of contributors and this dashboard, and the 2014 contributor goal, exist to help us focus our workflows, decisions and investments in ways that empower the community. Not just for the fun of counting things.

The first half of the year focused us on the question “How do we count contributors?”. By and large, this has now been answered.

We need to switch our focus to:

  1. Are we on track?
  2. What are we doing to grow the contributor community?

Then repeating these two question regularly throughout the year, and adjusting our strategy as we go.

Are we on track?

Wearing my cold-dispassionate-metrics hat, and not my “I know how hard you’re all working already” hat, I have to say no (or, not yet).

I’m going to look at this team by team and then look at the All Mozilla Foundation view at the end.

Your task, for each graph below is to take an imaginary marker pen and draw the line for the rest of the year based on the data you can see to date. And only on the data you can see to-date.

  • What does your trend line look like?
  • Is it going to cross the dotted target line in 2014?
OpenNews

Screen Shot 2014-07-18 at 19.48.44

Based on the data to-date, I’d draw a flat line here. Although there are new contributors joining pretty regularly, the overall trend is flat. In marketing terms there is ‘churn’; not a nice term, but a useful one to talk about the data. To use other crass marketing terms, ‘retention’ is as important as ‘acquisition’ in changing the shape of this graph.

Science Lab

Screen Shot 2014-07-18 at 19.49.55

Dispassionately here, I’d have to draw a trend line that’s pointing slightly down. One thing to note in this view is that the Science Lab team have good historic data, so what we’re seeing here is the result of the size of the community in early 2013, and some drop-off from those people.

Appmaker

Screen Shot 2014-07-18 at 19.50.57

This graph is closest to what we want to see generally, i.e. pointing up. But I’ll caveat that with a couple of points. First, taking the imaginary marker pen, this isn’t going to cross the 2014 target line at the current rate. Second, unlike the Science Lab and OpenNews data above, much of this Appmaker counting is new. And when you count things for the first time, a 12 month rolling active total has a cumulative effect in the first year, which increases the appearance of growth, but might not be a long term trend. This is because Appmaker community churn won’t be a visible thing until next year when people could first drop out of the twelve month active time-frame.

Webmaker

Screen Shot 2014-07-18 at 19.51.47

This graph is the hardest to extend with our imaginary marker pen, especially with the positive incline we can see as Maker Party kicks off. The Webmaker plan expects much of the contributor community growth to come from the Maker Party campaign, so a steady incline was not the expectation across the year. But, we can still play with the imaginary marker pen.

I’d do the following exercise: In the first six months, active contributors grew by ~800 (~130 per month), so assuming that’s a general trend (big assumption) and you work back from 10k in December you would need to be at ~9,500 by the end of September. Mark a point at 9,500 contributors above the October tick and look at the angle of growth required throughout Maker Party to get there. That’s not impossible, but it’s a big challenge and I don’t have any historic data to make an informed call here.

Note: the Appmaker/Webmaker separation here is a legacy thing from the beginning of the year when we started this project. The de-duped datastore we’re working on next will allow us to graph: Webmaker Total > Webmaker Tools > Appmaker as separate graphs with separate goals, but which get de-duped and roll-up into the total numbers above, and in turn roll-up into the Mozilla wide total at areweamillionyet.org – this will better reflect the actual overlaps.

Metrics

[ 0 contributors ]

The MoFo metrics team currently has zero active volunteer contributors, and based on the data available to date is trending absolutely flat. Action is required here, or this isn’t going to change. I also need to set a target. Growing 0 by 10X doesn’t really work. So I’ll aim for 10 volunteer contributors in 2014.

All Mozilla Foundation

Screen Shot 2014-07-18 at 19.52.40

Here we’re adding up the other graphs and also adding in ~900 people who contributed to MozFest in October 2013. That MozFest number isn’t counted towards a particular team and simply lifts the total for the year. There is no trend for the MozFest data because all the activity happened at once, but if there wasn’t a MozFest this year (don’t worry, there is!) in October the total line would drop by 900 in a single week. Beyond that, the shape of this line is the cumulative result of the team graphs above.

In Q3, we’ll be able to de-dupe this combined number as there are certainly contributors working across MoFo teams. In a good way, our total will be less that the sum of our parts.

Where do we go from here?

First, don’t panic. Influencing these trend lines is not like trying to shift a nation’s voting trends in the next election. Much of this is directly under our control, or if not ‘control’, then it’s something we can strongly influence. So long as we work on it.

Next, it’s important to note that this is the first time we’ve been able to see these trends, and the first time we can measure the impact of decisions we make around community building. Growing a community beyond a certain scale is not a passive thing. I’ve found David Boswell’s use of the term ‘intentional’ community building really helpful here. And much more tasteful than my marketing vocabulary!

These graphs show where we’re heading based on what we’re currently doing, and until now we didn’t know if we were doing well, or even improving at all. We didn’t have any feedback mechanism on decisions we’d make relating to community growth. Now we do.

Trend setting

Here are some initial steps that can help with the ‘measuring’ part of this community building task.

Going back to the marker pen exercise, take another imaginary color and rather than extrapolate the current trend, draw a positive line that gets you to your target by the end of the year. This doesn’t have to be a straight line; allow your planned activity to shape the growth you want to see. Then ask:

  • Where do you need to be in Aug, Sep, Oct, Nov, Dec?
  • How are you going to reach each of these smaller steps?

Schedule a regular check-in that focuses on growing your contributor community and check your dashboard:

  • Are your current actions getting you to your goals?
  • What are the next actions you’re going to take?

The first rule of fundraising is ‘Ask for money’. People often overlook this. By the same measure, are you asking for contributions?

  • How many people are you asking this week or month to get involved?
  • What percentage of them do you expect to say yes and do something?

Multiply those numbers together and see if it that prediction can get you to your next step towards your goal.

Asking these questions alone won’t get us to our goals, but it helps us to know if our current approach has the capacity to get there. If it doesn’t we need to adjust the approach.

Those are just the numbers

I could probably wrap up this check-in from a metrics point of view here, but this is not a numbers game. The Total Active Contributor number is a tool to help us understand scale beyond the face-to-face relationships we can store in our personal memories.

We’re lucky at Mozilla that so many people already care about the mission and want to get involved, but sitting and waiting for contributors to show up is not going to get us to our goals in 2014. Community building is an intentional act.

Here’s to setting new trends.

Categorieën: Mozilla-nl planet

Kevin Ngo: Poker Sessions #19 to #27 - Downswing

Mozilla planet - sn, 19/07/2014 - 02:00
Just keep Hulking through the drops.

Since returning from a three-week personal/work/family trip in Florida, things have not gone too hot. Busted out of a $5K (-$80), out of a freeroll (-$60), a $3K (-$90), a couple of small $300s (-$90), a couple of $1500s (-$100), and a couple more $5Ks (-$160). That totals for a -$480 dip. Though I try not to be results-oriented.

The first couple of tournaments were rust. I chalk the rest up to "that's tournament poker". MTTs are naturally swingy, despite playing pretty solid. Most bust outs were failed steals in the higher all-in-or-fold blind levels, a couple were suckouts. But I won't recite every bust-out hand.

Though I have been doing pretty solid live, I have been getting undisciplined in my online poker play. It's time to hit the books and tighten up. Harrington has a solid guide for preflop play that I need to freshen up upon.

After doing some bookkeeping, my poker bankroll after after 27 sessions is +$3272.

Sessions Conclusions
  • Went Well: improving on hand-reading, taking less marginal lines, super patience
  • Mistakes: some loose push-fold play, thinking limpers always have marginal hands
  • Get Better At: studying on late push-fold play, whether it needs to tighten up
  • Profit: -$480
Categorieën: Mozilla-nl planet

Kim Moir: Reminder: Release Engineering Special Issue submission deadline is August 1, 2014

Mozilla planet - sn, 19/07/2014 - 00:03
Just a friendly reminder that the deadline for the Release Engineering Special Issue is August 1, 2014.  If you have any questions about the submission process or a topic that's you'd like to write about, the guest editors, including myself, are happy to help you!

Categorieën: Mozilla-nl planet

Kim Moir: Mozilla pushes - June 2014

Mozilla planet - fr, 18/07/2014 - 23:46
Here's June 2014's  analysis of the pushes to our Mozilla development trees. You can load the data as an HTML page or as a json file
Trends This was another record breaking month with a total of 12534 pushes.  As a note of interest, this is is over double the number of pushes we had in June 2013. So big kudos to everyone who helped us scale our infrastructure and tooling.  (Actually we had 6,433 pushes in April 2013 which would make this less than half because June 2013 was a bit of a dip.  But still impressive :-)
Highlights
  • 12534 pushes
    • new record
  • 418 pushes/day (average)
    • new record
  • Highest number of pushes/day: 662 pushes on June 5, 2014
    • new record
  • Highest 23.17 pushes/hour (average)
    • new record

General RemarksThe introduction of Gaia-try in April has been very popular and comprised around 30% of pushes in June compared to 29% last month.The Try branch itself consisted of around 38% of pushes.The three integration repositories (fx-team, mozilla-inbound and b2g-inbound) account around 21% of all the pushes, compared to 22% in the previous month.
RecordsJune 2014 was the month with most pushes (12534 pushes)
June 2014 has the highest pushes/day average with 418 pushes/day
June 2014 has the highest average of "pushes-per-hour" is 23.17 pushes/hour
June 4th, 2014 had the highest number of pushes in one day with 662 pushes




Categorieën: Mozilla-nl planet

Mark Surman: Quick thoughts from Kenya

Mozilla planet - fr, 18/07/2014 - 22:36

Going anywhere in Africa always energizes me. It surprises me. Challenges my assumptions. Gives me new ideas. And makes me smile. The week I just spent in Nairobi did all these things.

Airtel top up agenda in Nairobi

The main goal of my trip was to talk to people about the local content and simple appmaking work Mozilla is doing. I spent an evening talking with Mozilla community members, a day and a bit with people at Equity Bank and a bunch of time with people from iHub. Here are three of the many thoughts I had while reflecting on the flight home:

Microbusiness is our biggest opportunity for AppMaker

I talked to ALOT of people about the idea of non-techie smartphone users being able to make their own apps.

My main question was: who would want to make their own app rather than just use Facebook? Most of the good answers had to with someone running a very small business. A person selling juice to office workers who wastes alot of travel time taking orders. An up and coming musician who wants a way to pre-sell tickets to loyal fans using mobile money. A chicken farmer outside Nairobi who is always on the phone with the hotels she sells to (pic below, met her and her husband while on a trip with Equity Bank folks). The common thread: simple to make and remix apps could be very useful to very small real world businesses that would benefit from better communications, record keeping and transaction processing via mobile phone.

IMG_20140717_085731~2

Our main priority with AppMaker (or whatever we call it) right now is to get a first cut at on-device authoring out there. In the background, we also really need to be pushing on use cases like these — and the kind of app templates that would enable them. Some people at the iHub in Nairobi have offered to help with prototyping template apps specific to Kenya over the next few months, which will help with figuring this out.

Even online is offline in much of Africa

As I was reminded at MozFest East Africa, even online is offline in much of Africa (and many other parts of the world). In the city, the cost of data for high bandwidth applications like media streaming — or running a Webmaker workshop — is expensive. And, outside the city, huge areas have connections that are spotty or non-existent.

BRCK-in-use

It was great to meet the BRCK people who are building products to address issues like this. Specifically: BRCK is a ruggedized wifi router with a SIM card, useful I/O ports and local storage. Brainstorming with Juliana and Erik from iHub, it quickly became clear that it could be useful for things like Webmaker workshops in places where connectivity is expensive, slow or even non-existent. If you popped a Raspberry Pi on the side, you might even be able create a working version of Webmaker tools like Thimble and Appmaker that people could use locally — with published web pages and apps trickling back or syncing once the BRCK had a connection. The Kenyan Mozillians I talked to were very excited about this idea. Worth exploring.

People buy brands

During a dinner with local Mozillians, a question was raised: ‘what will it take for Firefox OS to succeed in Kenya?’ A debate ensued. “Price,” said one person, “you can’t get a $30 smartphone like the one Mozilla is going to sell.” “Yes you can!”, said another. “But those are China phones,” said someone else. “People want real phones backed by a real brand. If people believe Firefox phones are authentic, they will buy them.”

IMG_20140717_103451~4

Essentially, they were talking about the tension between brand / authenticity / price in commodity markets like smartphones. The contention was: young Kenyan’s are aspiring to move up in the world. An affordable phone backed by a global brand like Mozilla stands for this. Of course, we know this. But it’s a good reminder from the people who care most about Mozilla (our community, pic below of Mozillians from Kenya) that the Firefox brand really needs to shine through on our devices and in the product experience as we roll out phones in more parts of the world.

Mozillians from Nairobi

I’ve got alot more than this rumbling around in my head, of course. My week in Uganda and Kenya really has my mind spinning. In a good way. It’s all a good reminder that the diverse perspectives of our community and our partners are one of our greatest strengths. As an organization, we need to tap into that even more than we already do. I truly believe that the big brain that is the Mozilla Community will be a key factor in winning the next round in our efforts to stand up for the web.


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

Mozilla's Firefox OS devices ready to reach Europe, Latin America, Asia Pacific - Mobile & Apps

Nieuws verzameld via Google - fr, 18/07/2014 - 14:16

Mozilla's Firefox OS devices ready to reach Europe, Latin America, Asia Pacific
Mobile & Apps
Mozilla has signed a number of new partnerships in Europe and Latin America, as part of an effort to expand the availability of its Firefox OS in more countries. For those unfamiliar with Firefox OS, Mozilla's operating system aims to leverage the web ...

Categorieën: Mozilla-nl planet

Doug Belshaw: HOWTO: apply for Webmaker badges

Mozilla planet - fr, 18/07/2014 - 13:51

super-mentor-02.jpg

We’re in full swing with Webmaker contribution and web literacy badges at the moment, so I wanted to take a moment to give some advice to people thinking of applying. We already have a couple of pages on the Webmaker blog for the Mentor and Super Mentor badges:

However, I wanted to give some general advice and fill in the gaps.

First of all, it’s worth sharing the guidance page for the people reviewing your application. In the case of a Webmaker Super Mentor badge, this will be a Mozilla paid contributor (i.e. staff member), but for all other badges it may be community member who has unlocked the necessary privileges.

To be clear:

The best applications we’ve seen for the Webmaker badges so far take the explain how the applicant meets each one of the criteria on the badge detail page.

For example, this was Stefan Bohacek’s successful application for the Sharing ‘maker’ badge:

1) Sharing a resource using an appropriate tool and format for the audience: I wrote tutorials for people learning to make websites and web apps and shared them on my blog: http://blog.fourtonfish.com/tagged/tutorial. These also exist as a teaching kit on Webmaker – see my blogpost with a link here: http://blog.fourtonfish.com/post/89157427285/mozilla-webmaker-featured-teaching-kit. Furthermore I created resources for web developers such as http://simplesharingbuttons.com (also see: http://badges.p2pu.org/en/project/477) and some other (mini-)projects here: https://github.com/fourtonfish

2) Tracking changes made to co-created Web resources: I use GitHub for some of my personal projects (although I only received a handful of opened issues) and GitLab with clients I worked with/for.

3) Using synchronous and asynchronous tools to communicate with web communities, networks and groups https://twitter.com/fourtonfish – I follow some of the members of Webmaker (and seldomly frustrate Doug Belshaw with questions) https://plus.google.com/+StefanBohacek/posts – I am a member of the Webmaker community http://webdevrefinery.com/forums/user/18887-ftfish/ – I (infrequently) post here, share ideas, comment on ideas of others etc. stefan@fourtonfish.com – I wouldn’t be able to finish my teaching kit without the help of other webmakers and my email account to communicate with them

Note that Stefan earned his badge for numbers 1) and 3) in the above example. This was enough to meet the requirements as the badge is awarded for meeting any two of the criteria listed on the badge detail page. He did not provide any evidence for using GitHub, as mentioned in 2), so this was not used as evidence by the person reviewing his application.

Applying for a badge is just like applying for anything in life:

  • Make the reviewer’s job easy – they’re looking at lots of applications!
  • Tell the reviewer which of the criteria you think you have met.
  • Include a link for each of the criteria – more than one if you can.
  • If you are stuck, ask for help. A good place to start is the Webmaker discussion forum, or if you know someone who’s already got that badge, ask them to help you!

Questions? Comments? I’m @dajbelshaw or you can email me at doug@mozillafoundation.org. Note that specific badge questions should go in the discussion forum.

Image CC Mozilla in Europe

Categorieën: Mozilla-nl planet

Mozilla takes Firefox OS to new markets and devices, including India - BetaNews

Nieuws verzameld via Google - fr, 18/07/2014 - 13:09

BetaNews

Mozilla takes Firefox OS to new markets and devices, including India
BetaNews
"To accelerate the design, development and testing of the Firefox OS ecosystem, Mozilla has partnered with Thundersoft to manufacture and distribute the Firefox OS Flame reference phone", the organization states. This device is now available for purchase.
In Pictures: Beyond Firefox - 10 Mozilla projects fuelling the open WebComputerworld New Zealand
Mozilla announces Firefox OS expansion plans into AsiaDigit

alle 21 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Mozilla takes Firefox OS to new markets and devices, including India - BetaNews

Nieuws verzameld via Google - fr, 18/07/2014 - 13:09

BetaNews

Mozilla takes Firefox OS to new markets and devices, including India
BetaNews
"To accelerate the design, development and testing of the Firefox OS ecosystem, Mozilla has partnered with Thundersoft to manufacture and distribute the Firefox OS Flame reference phone", the organization states. This device is now available for purchase.
Mozilla announces Firefox OS expansion plans into AsiaDigit
Mozilla's Firefox OS devices ready to reach Europe, Latin America, Asia PacificMobile & Apps
Firefox OS lands in Germany – with France, Asia, and more to comeRegister
Liliputing -DigitalTVEurope.net
alle 12 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Mozilla takes Firefox OS to new markets and devices, including India - BetaNews

Nieuws verzameld via Google - fr, 18/07/2014 - 13:09

BetaNews

Mozilla takes Firefox OS to new markets and devices, including India
BetaNews
"To accelerate the design, development and testing of the Firefox OS ecosystem, Mozilla has partnered with Thundersoft to manufacture and distribute the Firefox OS Flame reference phone", the organization states. This device is now available for purchase.
Mozilla announces Firefox OS expansion plans into AsiaDigit
Firefox OS lands in Germany – with France, Asia, and more to comeRegister
Firefox OS expands in Europe, Latin America, Asia PacificLiliputing
DigitalTVEurope.net -GSMArena.com
alle 11 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Mozilla announces Firefox OS expansion plans into Asia - Digit

Nieuws verzameld via Google - fr, 18/07/2014 - 09:26

Liliputing

Mozilla announces Firefox OS expansion plans into Asia
Digit
Open source giant Mozilla yesterday announced its expansion plans on its blog yesterday, covering Europe, Latin America and Asia. This means that phones from ZTE, LG etc. that are currently running the Firefox OS, may soon be available in these areas.
Firefox OS lands in Germany – with France, Asia, and more to comeRegister
Firefox OS expands in Europe, Latin America, Asia PacificLiliputing
Firefox OS expands in Europe, Latin America and Asia PacificGSMArena.com
Telecompaper (subscription)
alle 7 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Botond Ballo: Trip Report: C++ Standards Committee Meeting in Rapperswil, June 2014

Mozilla planet - fr, 18/07/2014 - 03:12
Summary / TL;DR Project Status C++14 On track to be published late 2014 C++17 A few minor features so far, including for (elem : range) Networking TS Ambitious proposal to standardize sockets based on Boost.ASIO Filesystems TS On track to be published late 2014 Library Fundamentals TS Contains optional, any, string_view and more. Progressing well, expected early 2015 Library Fundamentals TS II Follow-up to Library Fundamentals TS; will contain array_view and more. In early stage Array Extensions TS Completely stalled. No proposal related to runtime-sized arrays/objects currently has consensus Parallelism TS Progressing well; expected 2015 Concurrency TS Executors and resumable functions need more work Transactional Memory TS Progressing well; expected 2015-ish Concepts (“Lite”) TS Progressing well; expected 2015 Reflection A relatively full-featured compile-time introspection proposal was favourably reviewed. Might target a TS or C++17 Graphics Moving forward with a cairo-based API, to be published in the form of a TS Modules Clang has a complete implementation for C++, plan to push it for C++17 Introduction

Last week I attended another meeting of the ISO C++ Standards Committee in Rapperswil, Switzerland (near Zurich). This is the third Committee meeting I have attended; you can find my reports about the previous two here (September 2013, Chicago) and here (February 2014, Issaquah). These reports, particularly the Issaquah one, provide useful context for this post.

With C++14′s final ballot being still in progress, the focus of this meeting was the various language and library Technical Specifications (TS) that are planned as follow-ups to C++14, and on C++17.

C++14

C++14 is currently out for its “DIS” (Draft International Standard) ballot (see my Issaquah report for a description of the procedure for publishing a new language standard). This ballot was sent out at the end of the Issaquah meeting, and will close mid-August. If no national standards body poses an objection by then – an outcome considered very likely – then the standard will be published before the end of the year.

Since a ballot was in progress, no changes to the C++14 draft were made during the Rapperswil meeting.

C++17, and what’s up with all these TS’s?

ISO procedure allows the Committee to publish two types of documents:

  • International Standards (IS). These are official standards with stringent backwards-compatibility requirements.
  • Technical Specifications (TS) (formerly called Technical Reports (TR)). These are for things that are not quite ready to be enshrined into an official standard yet, and have no backwards-compatibility requirements. Specifications contained in a TS may or may not be added, possibly with modifications, into a future IS.

C++98 and C++11 are IS’s, as will be C++14 and C++17. The TS/TR form factor has, up until recently, only been used once by the Committee: for TR1, the 2005 library spec that gave us std::tr1::shared_ptr and other library enhancements that were then added into C++11.

Since C++11, in an attempt to make the standardization process more agile, the Committee has been aiming to place significant new language and library features into TS’s, published on a schedule independent of the IS’s. The idea is that being in a TS allows the feature to gain user and implementation experience, which the committee can then use to re-evaluate and possibly revise the feature before putting it into an IS.

As such, much of the standardization work taking place concurrently with and immediately after C++14 is in the form of TS’s, the first wave of which will be published over the next year or so, and the contents of which may then go into C++17 or a subsequent IS, as schedules permit.

Therefore, at this stage, only some fairly minor features have been added directly to C++17.

The most notable among them is the ability to write a range-based for loop of the form for (elem : range), i.e. with the type of the element omitted altogether. As explained in detail in my Issaquah report, this is a shorthand for for (auto&& elem : range) which is almost always what you want. The Evolution Working Group (EWG) approved this proposal in Issaquah; in Rapperswil it was also approved by the Core Working Group (CWG) and voted into C++17.

Other minor things voted into C++17 include:

  • static_assert(condition), i.e. with the message omitted. An implementation-defined message is displayed.
  • auto var{expr}; is now valid and equivalent to T var{expr}; (where T is the deduced type)
  • A template template parameter can now be written as template <...> typename Name in addition to template <...> class Name, to mirror the way a type template parameter can be written as typename Name in addition to class Name
  • Trigraphs (an obscure feature that allowed certain characters, such as #, which are not present on some ancient keyboards, to be written as a three-character sequence, such as ??=) were removed from the language
Evolution Working Group (EWG)

As with previous meetings, I spent most of time in the Evolution Working Group, which spends its time looking at proposals for new language features that either do not fall into the scope of any Study Group, or have already been approved by a Study Group. There was certainly no lack of proposals at this meeting; to EWG’s credit, it got through all of them, at least the ones which had papers in the official pre-Rapperswil mailing.

Incoming proposals were categorized into three rough categories:

  • Approved. The proposal is approved without design changes. They are sent on to CWG, which revises them at the wording level, and then puts them in front of the committee at large to be voted into whatever IS or TS they are targeting.
  • Further Work. The proposal’s direction is promising, but it is either not fleshed out well enough, or there are specific concerns with one or more design points. The author is encouraged to come back with a modified proposal that is more fleshed out and/or addresses the stated concerns.
  • Rejected. The proposal is unlikely to be accepted even with design changes.

Accepted proposals:

  • Opening two nested namespaces with namespace A::B { in addition to namespace A { namespace B {
  • “Making return explicit”. This means that if a class A has an explicit constructor which takes a parameter of type B, then, in a function whose return type is A, it is valid to write return b; where b has type B. (Currently, one has to writen return A(b);.) The idea is to avoid repetition; a very common use case is A being std::unique_ptr<T> for some T, and B being T*. This proposal was relatively controversial; it passed with a weak consensus in EWG, and was also discussed in the Library Evolution Working Group (LEWG), where there was no consensus for it. I was surprised that EWG passed this to CWG, given the state of the consensus; in fact, CWG indicated that they would like additional discussion of it in a forum that includes both EWG and LEWG members, before looking at it in CWG.
  • A preprocessor feature for testing for the presence of a (C++11-style) attribute: __has_cpp_attribute(attribute_name)
  • A couple that I already mentioned because they were also passed in CWG and voted into C++17 at the same meeting:

Proposals for which further work is encouraged:

  • A proposal to make C++ more friendly for embedded systems development by reducing the overhead of exception handling, and further expanding the expressiveness of constexpr. EWG encouraged the author to gather people interested in this topic and form a Study Group to explore it in more detail.
  • A proposal to convey information to the compiler about aliasing, via attributes. This is intended to be an improvment to C99′s restrict.
  • A way to get the compiler to, on an opt-in basis, generate equality and comparison operators for a structure/class. Everyone wanted this feature, but there were disagreements about how terse the syntax should be, whether complementary operators should be generated automatically (e.g. != based on ==), how exactly the compiler should implement the operators (particularly for comparison – questions of total order vs. weaker orders came up), and how mutable members should be handled.
  • A proposal for a per-platform portable C++ ABI. I will talk about this in more detail below.
  • A way to force the compiler to omit padding between two structure fields
  • A way to specify that a class should be converted to another type in auto initialization. That is, for a class C, to specify that in auto var = c; (with c having type C), the type of var should actually be some other type D. The motivating use here is expression templates; in Matrix X, Y; auto Z = X * Y; we want the type of Z to be Matrix even if the type of X * Y is some expression template type. EWG liked the motivation, but the proposal tried to modify the semantics of template parameter deduction for by-value parameters so as to remain consistent with auto, and EWG was concerned that this was starting to encroach on too many areas of the language. The author was encouraged to come back with a more limited-scope proposal that concerned auto initialization only.
  • Fixed-size template parameter packs (typename...[K]) , and packs where all parameters must be of the same type (T...[N]). EWG liked the idea, but had some concerns about syntactic ambiguities. The proposal also inspired an offshoot idea of subscripting parameter packs (e.g. Pack[0] gives you the first parameter), to avoid having to use recursion to iterate over the parameters in many cases.
  • Expanding parameter packs as expressions. Currently, if T is a parameter pack bound to parameters A, B, and C, then T... expands to A, B, C; this expansion is allowed in various contexts where a comma-separated list of things (types or expressions, as the parameters may be) is allowed. The proposal here is to allow things like T +... which would expand to A + B + C, which would be allowed in an expression context.

Rejected proposals:

  • Objects of runtime size. This would have allowed a pure library implementation of something like std::dynarray (and allowed users to write similar classes of their own), but it unfortunately failed to gain consensus. More about this in the Array Extensions TS section.
  • Additional flow control mechanisms like break label;, continue label; and goto case value;. EWG thought these encouraged hard-to-follow control flow.
  • Allowing specifiers such as virtual, static, override, and some others, to apply to a group of members the way acess specifiers (private: etc.) currently do. The basis for rejection here was that separating these specifiers from the members they apply to can make class definitions less readable.
  • Specializing an entity in a different namespace without closing the namespaces you are currently in. Rejected because it’s not clear what would be in scope inside the specialization (names from the entity’s namespace, the current namespace, or both).
  • <<< and >>> operators for circular bit-shifts. EWG felt these would be more appropriate as library functions.
  • A rather complicated proposal for annotating template parameter packs that claimed to be a generalization of the proposal for fixed-size template parameter packs. Rejected because it would have made the language much more complicated, while the benefit would mostly have been for template metaprogramming; also, several of the use cases can be satisfied with Concepts instead.
  • Throwing an exception on stack exhaustion. The implementers in the room felt this was not implementable.

I should also mention the proposal for named arguments that Ehsan and I have been working on. We did not prepare this proposal in time to get it into the pre-Rapperswil mailing, and as such, EWG did not look at it in Rapperswil. However, I did have some informal discussions with people about it. The main concerns were:

  • consideration for constructor calls with {...} syntax and, by extension, aggregate initialization
  • the relationship to C99 designated initializers (if we are covering aggregate initializtion, then these can be viewed as competing syntaxes)
  • most significantly: parameter names becoming part of a library’s interface that library authors then have to be careful not to break

Assuming we are able to address these concerns, we will likely write an updated proposal, get it into the pre-Urbana mailing (Urbana-Champaign, Illinois is the location of the next Committee meeting in November), and present it at the Urbana meeting.

Portable C++ ABI

One of the most exciting proposals at this meeting, in my opinion, was Herb Sutter’s proposal for a per-platform portable C++ ABI.

A per-platform portable ABI means that, on a given platform (where “platform” is generally understood to a mean the combination of an operating system, processor family, and bitness), binary components can be linked together even if they were compiled with different compilers, or different versions of the same compiler, or different compiler options. The current lack of this in C++ is, I think, one of C++’s greatest weaknesses compared to other languages like C or Java.

More specifically, there are two aspects to ABI portability: language and library. On the language side, portability means that binary components can be linked together as long as, for any interface between two components (for example, for a function that one component defines and the other calls, the interface would consist of the function’s declaration, and the definitions of any types used as parameters or return type), the two components are compiled from identical standard-conforming source code for that interface. On the library side, portability additionally means that interfaces between components can make use of standard library types (this does not follow solely from the language part, because different compilers may not have identical source code for their standard library types).

It has long been established that it is out of scope for the C++ Standard to prescribe an ABI that vendors should use (among other reasons, because parts of an ABI are inherently platform-specific, and the standard cannot enumerate every platform and prescribe something for each one). Instead, Herb’s proposal is that the standard codify the notions of a platform and a platform owner (an organization/entity who controls the platform); require that platform owners document an ABI (in the case of the standard library, this means making available the source code of a standard library implementation) which is then considered the platform ABI; and require compiler and standard library vendors to support the platform ABI to be conformant on any given platform.

In order to ease transitioning from the current world where, on a given platform, the ABI can be highly dependent on the compiler, the compiler version, or even compiler options, Herb also proposes some mechanisms for delineating a portion of one’s code which should be ABI-portable, and therefore compiled using the platform ABI. These mechanisms are a new linkage (extern "abi") on the language side, and a new namespace (std::abi, containing the same members as std) on the library side. The idea is that one can restrict the use of these mechanisms to code that constitutes component interfaces, thereby achieving ABI portability without affecting other code.

This proposal was generally well-received, and certainly people agreed that a portable ABI is something C++ needs badly, but some people had concerns about the specific approach. In particular, implementers were uncomfortable with the idea of potentially having to support two different ABI’s side-by-side in the same program (the platform ABI for extern "abi" entities, and the existing ABI for other entities), and, especially, with having two copies of every library entity (one in std and one in std::abi). Other concerns about std::abi were raised as well, such as the performance penalty arising from having to convert between std and std::abi types in some places, and the duplication being difficult to teach. It seemed that a modified proposal that concerned the language only and dropped std::abi would have greater consensus.

Array Extensions TS

The Array Extensions TS was initally formed at the Chicago meeting (September 2013) when the committee decided to pull out arrays of runtime bound (ARBs, the C++ version of C’s VLAs) and dynarray, the standard library class for encapsulating them, out of C++14 and into a TS. This was done mostly because people were concerned that dynarray required too much compiler magic to implement. People expressed a desire for a language feature that would allow them to implement a class like dynarray themselves, without any compiler magic.

In Issaquah a couple of proposals for such a language feature were presented, but they were relatively early-stage proposals, and had various issues such as having quirky syntax and not being sufficiently general. Nonetheless there was consensus that a library component is necessary, and we’d rather not have ARBs at all than get them without a library component to wrap them into a C++ interface.

At this meeting, a relatively fully fleshed-out proposal was presented that gave programmers a fairly general/flexible way to define classes of runtime size. Unfortunately, it was considered a complex change that touches many parts of the language, and there was no consensus for going forward with it.

As a result, the Array Extensions TS is completely stalled: ARBs themselves are ready, but we don’t want them without a library wrapper, and no proposal for a library wrapper (or mechanism that would enable one to be written) has consensus. This means that the status quo of not being able to use VLAs in C++ (unless a vendor enables C-stle VLAs in C++ as an extension) will remain for now.

Library / Library Evolution Working Groups (LWG and LEWG)

Library work at this meeting included the Library Fundamentals TS (and its planned follow-up, Library Fundamentals II), the Filesystems TS and Networking TS (about which I’ll talk in the SG 3 and SG 4 sections below), and reviewing library components of other projects like the Concurrency TS.

The Library Fundamentals TS was in the wording review stage at this meeting, with no new proposals being added to it. It contains general library utilities such as optional, any, string_view, and more; see my Issaquah report for a full list. The current draft of the TS can be found here. At the end of the meeting, the Committee voted to send out the TS for its first national body ballot, the PDTS (Preliminary Draft TS) ballot. This ballot concludes before the Urbana meeting in November; if the comments can be addressed during that meeting and the TS sent out for its second and final ballot, the DTS (Draft TS) ballot, it could be published in early 2015.

The Committee is also planning a follow-up to the Library Fundamentals TS, called the Library Fundamentals TS II, which will contain general utilities that did not make it into the first one. Currently, it contains one proposal, a generalized callable negator; another proposal, containing library facilities for contract programming, got rejected for several reasons, one of them being that it is expected to be obsoleted in large part by reflection. Proposals under consideration to be added include:

Study Groups

SG 1 (Concurrency)

SG 1 focuses on two areas, concurrency and parallelism, and there is one TS in the works for each.

I don’t know much about the Parallelism TS other than it’s in good shape and was sent out for its PDTS ballot at the end of the meeting, which could lead to publication in 2015.

The status of the Concurrency TS is less certain. Coming into the Rapperswil meeting, the Concurrency TS contained two things: improvements to std::future (notably a then() method for chaining a second operation to it), and executors and schedulers, with resumable function being slated for addition.

However, the pre-Rapperswil mailing contained several papers arguing against the existing designs for executors and resumable functions, and proposing alternative designs instead. These papers led to executors and schedulers being removed from the Concurrency TS, and resumable functions not being added, until people come to a consensus regarding the alternative designs. I’m not sure whether publication of the Concurrency TS (which now contains only the std::future improvements) will proceed, leaving executors and resumable functions for a follow-up TS, or be stalled until consensus on the latter topics is reached.

For resumable functions, I was in the room during the technical discussion, and found it quite interesting. The alternative proposal is a coroutines library based on Boost.Coroutine. The two proposals differ both in syntax (new keywords async and await vs. the magic being hidden entirely behind a library interface), and implementation technique for storing the local variables of a resumable function (heap-allocated “activation frames” vs. side stacks). The feedback from SG 1 was to disentangle these two aspects, possibly yielding a proposal where either syntax could be matched with either implementation technique.

There are also other concurrency-related proposals before SG 1, such as ostream buffers, latches and barries, shared_mutex, atomic operations on non-atomic data, and a synchronized wrapper. I assume these will go into either the current Concurrency TS, or a follow-up TS, depending on how they progress through the committee.

SG 2 (Modules)

Modules is, in my opinion, one of the most sorely needed features in C++. They have the potential of increasing compile times by an order of magnitude or more, thus bringing compile-time performance more in line with more modern languages, and of solving the combinatorial explosion problem, caused by macros, that hampers the development of powerful tooling such as automated refactoring.

The standardization of modules has been a slow process for two reasons. First, it’s an objectively difficult problem to solve. Second, the solution shares some of the implementation difficulties of the export keyword, a poorly thought-out feature in C++98 that sought to allow separate compilation of templates; export was only ever implemented by one compiler (EDG), and the implementation process revealed flaws that led not only to other compilers not even bothering to implement it, but also to the feature being removed from the language in C++11. This bad experience with export led people to be uncertain about whether modules are even implementable. As a result, while some papers have been written proposing designs for modules (notably, one by Daveed Vandevoorde a couple of years back, and one by Gabriel Dos Reis very recently, what everyone has really been holding their breaths for was an implementation (of any variation/design), to see that one was possible.

Google and others have been working on such an implementation in Clang, and I was very excited to hear Chandler Carruth (head of Google’s team working on Clang) report that they have now completed it! As this work was completely very recently prior to the meeting, they did not get a chance to write a paper to present at this meeting, but Chandler said one will be forthcoming for the next meeting.

EWG held a session on Modules, where Gaby presented his paper, and the Clang folks discussed their implementation. There were definitely some differences between the two. Gaby’s proposal came across as more idealistic: this is what a module system should look like if you’re writing new code from scratch with modules. Clang’s implementation is more practical: this is how we can start using modules right away in existing codebases. For example, in Gaby’s proposal, a macro defined in a module is not visible to an importing module; in Clang’s implementation, it is, reflecting the reality that today’s codebases still use macros heavily. As another example, in Gaby’s proposal, a module writer must say which declarations in the module file are visible to importing modules by surrounding them in an export block (not to be confused with the failed language feature I talked about above); in Clang’s implementation, a header file can be used as a module without any changes, using an external “module map” file to tell the compiler it is a module. Another interesting design question that came up was whether private members of a class exported from a module are “visible” to an importing module (in the sense that importing modules need to be recompiled if such a private member is added or modified); in Clang’s implementation, this is the case, but there would certainly be value in avoiding this (among other things, it would obsolete the laborious “Pimpl” design pattern).

The takeaway was that, while everyone wants this feature, and everyone is excited about there finally being an implementation, several design points still need to be decided. EWG deemed that it was too early to take any polls on this topic, but instead encouraged the two parties (the Clang folks, and Gaby, who works for Microsoft and hinted at a possible Microsoft implementation effort as well) to collaborate on future work. Specifically, EWG encourages that the following papers be written for Urbana: one about what is common to the various proposals, and one or more about the remaining deep technical issues. I eagerly await such future work and papers.

SG 3 (Filesystems)

At this meeting, the Library Working Group finished addressing the ballot comments for the Filesystem TS’s PDTS ballot, and sent out the TS for the final “DTS” ballot. If this ballot is successful, the Filesystems TS will be published by the end of 2014.

Beman (the SG 3 chair) stated that SG 3 will entertain new filesystem-related proposals that build upon the Filesystems TS, targetting a follow-up Filesystems TS II. To my knowledge no such proposals have been submitted so far.

SG 4 (Networking)

SG 4 had been working on standardizing basic building blocks related to networking, such as IP addresses and URIs. However, these efforts are stalled.

As a result, the LEWG decided at this meeting to take it upon itself to advance networking-related proposals, and they set their sights on something much more ambitious than IP addresses and URIs: a full-blown sockets library, based on Boost.ASIO. The plan is basically to pick up Chris Kohlhoff’s (the author of ASIO) 2007 paper proposing ASIO for standardization, incorporating changes to update the library for C++11, as well as C++14 (forthcoming). This idea received very widespread support in LEWG; the group decided to give people another meeting to digest the new direction, and then propose adopting these papers as the working paper for the Networking TS in Urbana.

This change in pace and direction might seem radical, but it’s in line with the committee’s philosophy for moving more rapidly with TS’s. Adopting the ASIO spec as the initial Networking TS working paper does not mean that the committee agrees with every design decision in ASIO; on the contrary, people are likely to propose numerous changes to it before it gets standardized. However, having a working paper will give people something to propose changes against, and thus facilitate progress.

SG 5 (Transactional Memory)

The Transactional Memory TS is progressing well through the committee. CWG began reviewing its wording at this meeting, and referred one design issue to EWG. (The issue concerned functions that were declared to be neither transaction-safe nor transaction-unsafe, and defined out of line (so the compiler cannot compute the transaction safety from the definition). The state of the proposal coming into the discussion was that for such functions, the compiler must assume that they can be either transaction-safe or transaction-unsafe; this resulted in the compiler sometimes needing to generate two versions of some functions, with the linker stripping out the unused version if you’re lucky. EWG preferred avoiding this, and instead assuming that such functions are transaction-unsafe.) CWG will continue reviewing the wording in Urbana, and hopefully sendout the TS for its PDTS ballot then.

SG 6 (Numerics)

Did not meet in Rapperswil, but plans to meet in Urbana.

SG 7 (Reflection)

SG 7 met for an evening session and looked at three papers:

  • The latest version of the source code information capture proposal, which aims to replace the __LINE__, __FILE__, and __FUNCTION__ macros with a first-class language feature. There was a lot of enthusiasm for this idea in Issaquah, and now that it’s been written up as a paper, SG 7 is moving on it quickly, deciding to send it right on to LEWG with only minor changes. The publication vehicle – with possible choices being Library Fundamentals TS II, a hypothetical Reflection TS, or C++17 – will be decided by LEWG.
  • The type member property queries proposal by Andrew Tomazos. This is an evolution of an earlier proposal which concerned enumerations only, and which was favourably reviewed in Issaquah; the updated proposal extends the approach taken for enumerations, to all types. The result is already a quite featureful compile-time introspection facility, on top of which facilities such as serialization can be built. It does have one significant limitation: it relies on forming pointers to members, and thus cannot be used to introspect members to which pointers cannot be formed – namely, references and bitfields. The author acknowledged this, and pointed out that supporting such members with the current approach would require language changes. SG 7 did not deem this a deal-breaker problem, possibly out of optimism that such language changes would be forthcoming if this facility created a demand for them. Overall, the general direction of the proposal had basically unanimous support, and the author was encouraged to come back with a revised proposal that splits out the included compile-time string facility (used to represent names of members for introspection) into a separate, non-reflection-specific proposal, possibly targeted at Library Fundamentals II. The question of extending this facility to introspect things other than types (notably, namespaces, although there was some opposition to being able to introspect namespaces) also came up; the consensus here was that such extensions can be proposed separately when desired.
  • A more comprehensive static reflection proposal was looked at very, very briefly (the author was not present to speak about it in detail). This was a higher-level and more featureful proposal than Tomazos’ one; the prevailing opinion was that it is best to standardize something lower-level like Tomazos’ proposal first, and then consider standardizing higher-level libraries that build on it if appropriate.
SG 8 (Concepts)

The Concepts TS (formerly called “Concepts Lite”, but then people thought “Lite” was too informal to be in the title of a published standard) is still in the CWG review stage. Even though CWG looked at it in Issaquah, and the author and project editor, Andrew Sutton, revised the draft TS significantly for Rapperswil, the feature touches many areas of the language, and as such more review of the wording was required; in fact, CWG spent almost three full days looking at it this time.

The purpose of a CWG review of a new language feature is twofold: first, to make sure the feature meshes well with all areas of the language, including interactions that the author and EWG may have glossed over; and second, to make sure that the wording reflects the author’s intention accurately. In fulfilling the first objective, CWG often ends up making minor changes to a feature, while staying away from making fundamental changes to the design (sometimes, recommendations for more significant changes do come up during a CWG review – these are run by EWG before being acted on).

In the case of the Concepts TS, CWG made numerous minor changes over the course of the review. It was initially hoped that there would be time to revise the wording to reflect these changes, and put the reivsed wording out for a PDTS ballot by the end of the meeting, but the changes were too numerous to make this feasible. Therefore, the PDTS ballot proposal was postponed until Urbana, and Andrew has until then to implement the wording changes.

SG 9 (Ranges)

SG 9 did not meet in Rapperswil, but does plan to meet in Urbana, and I anticipate some exciting developments in Urbana.

First, I learned that Eric Niebler, who in Issaquah talked about an idea for a Ranges proposal that I thought was very exciting (I describe it in my Issaquah report), plans to write up his idea as a proposal and present it in Urbana.

Second, one of the attendees at Rapperswil, Fabio Fracassi, told me that he is also working on a (different) Ranges proposal that he plans to present in Urbana as well. I’m not familiar with his proposal, but I look forward to it. Competition is always healthy when it comes up early-stage standards proposal / choosing an approach to solving a problem.

SG 10 (Feature Test)

I didn’t follow the work of SG 10 very closely. I assume that, in addition to the __has_cpp_attribute() preprocessor feature that I mentioned above in the EWG section, they are kept busy by the flow of new features being added into working papers, for each of which they have to decide whether the feature deserves a feature-test macro, and if so standardize a name for one.

Clark (the SG 10 chair) did mention that the existence of TS’s complicates matters for SG 10, but I suppose that’s a small price to pay for the benefits of TS’s.

SG 12 (Undefined Behaviour)

Did not meet in Rapperswil, but plans to meet in Urbana.

SG 13 (Human Interaction, formerly “Graphics”)

SG 13 met for a quarter-day session, during which Herb presented an updated version of the proposal for a cairo-based 2D drawing API. A few interesting points came up in the discussion:

  • The interface being standardized is a C++ wrapper interface around cairo that was generated using a set of mechanical transformation rules applied to cairo’s interface. The transformation rules are not being standardized, only their result (so the standard interface can potentially diverge from cairo in the future, though presumably this wouldn’t be done without a very good reason).
  • I noted that Mozilla is moving away from cairo, in part due to inefficiencies caused by cairo being a stateful API (as explained here). It was pointed out that this inefficiency is an issue of implementation (due to cairo using a stateless layer internally), not one of interface. This is a good point, although I’m not sure how much it matters in practice, as standard library vendors are much more likely to ship cairo’s implementation than write their own. (Jonathan Wakely said so about libstdc++, but I think it’s very likely the case for other vendors as well.)
  • Regarding the tradeoff between a nice interface and high performance, Herb said the goal was to provide a nice interface while providing as good of a performance as we can get, without necesarily squeezing every last ounce of performance.
  • The library has the necessary extension points in place to allow for uses such as hooking into drawing onto a drawing surface of an existing library, such as a Qt canvas (with the cooperation of the existing library, cairo, and the platform, of course).

The proposal is moving forward: the authors are encouraged to come back with wording.

TS Content Guidelines

One mildly controversial issue that came to a vote in the plenary meeting at the end of the week, is the treatment of modifications/extensions to standard library types in a Technical Specification. One group held that the simplest thing to do for users is to have the TS specify modifications to the types in std:: themselves. Another group was of the view that, in order to make life easier for a third-party library vendor to implement a TS, as well as to ensure that it remains practical for a subsequent IS to break the TS if it needs to, the types that are modified should be cloned into an std::experimental:: namespace, and the modifications applied there. This second view prevailed.

Next Meeting

The next Committee meeting (“Urbana”) will be at the University of Illinois at Urbana-Champaign, the week of November 3rd.

Conclusion

The highlights of the meeting for me, personally, were:

  • The relevation that clang has completed their modules implementation, that they will be pushing it for C++17, and that they are fairly confident that they will be able to get it in. The adoption of a proper modules system has the potential to revolutionize compilation speeds and the tooling landscape – revolutions that C++ needs badly.
  • Herb’s proposal for a portable C++ ABI. It is very encouraging to see the committee, which has long held this issue to be out of its scope, looking at a concrete proposal for solving a problem which, in my opinion, plays a significant role in hampering the use of C++ interfaces in libraries.
  • LEWG looking at bringing the entire Boost.ASIO proposal into the Networking TS. This dramatically brings forward the expected timeframe of having a standard sockets library, compared to the previous approach of standardizing first URIs and IP addresses, and then who knows what before finally getting to sockets.

I eagerly await further developments on these fronts and others, and continue to be very excited about the progress of C++ standardization.


Categorieën: Mozilla-nl planet

In Pictures: Beyond Firefox - 10 Mozilla projects fuelling the open Web - Computerworld Australia

Nieuws verzameld via Google - fr, 18/07/2014 - 01:28

Computerworld Australia

In Pictures: Beyond Firefox - 10 Mozilla projects fuelling the open Web
Computerworld Australia
Ten Mozilla projects fueling the open Web Firefox reinvented the old-school Netscape browser, marking a defining moment for Mozilla as an advocate for open Web technologies. Today, market share for Mozilla's most noteworthy project is slumping, and the ...

Categorieën: Mozilla-nl planet

In Pictures: Beyond Firefox - 10 Mozilla projects fueling the open Web - CIO Magazine

Nieuws verzameld via Google - fr, 18/07/2014 - 00:09

CIO Magazine

In Pictures: Beyond Firefox - 10 Mozilla projects fueling the open Web
CIO Magazine
Ten Mozilla projects fueling the open Web Firefox reinvented the old-school Netscape browser, marking a defining moment for Mozilla as an advocate for open Web technologies. Today, market share for Mozilla's most noteworthy project is slumping, and the ...

Categorieën: Mozilla-nl planet

In Pictures: Beyond Firefox - 10 Mozilla projects fueling the open Web - Computerworld Australia

Nieuws verzameld via Google - fr, 18/07/2014 - 00:07

Computerworld Australia

In Pictures: Beyond Firefox - 10 Mozilla projects fueling the open Web
Computerworld Australia
Ten Mozilla projects fueling the open Web Firefox reinvented the old-school Netscape browser, marking a defining moment for Mozilla as an advocate for open Web technologies. Today, market share for Mozilla's most noteworthy project is slumping, and the ...

en meer »
Categorieën: Mozilla-nl planet

In Pictures: Beyond Firefox - 10 Mozilla projects fuelling the open Web - Computerworld New Zealand

Nieuws verzameld via Google - fr, 18/07/2014 - 00:04

Computerworld New Zealand

In Pictures: Beyond Firefox - 10 Mozilla projects fuelling the open Web
Computerworld New Zealand
Ten Mozilla projects fueling the open Web Firefox reinvented the old-school Netscape browser, marking a defining moment for Mozilla as an advocate for open Web technologies. Today, market share for Mozilla's most noteworthy project is slumping, and the ...

en meer »
Categorieën: Mozilla-nl planet

Pages