VR-Zone
Mozilla Firefox updated to version 21, brings new Social API support
VR-Zone
This new API as Mozilla writes "has endless potential for integrating social networks, e-mail, finance, music, cloud possibilities, services, to-do lists, sports, news and other applications into your Firefox experience.” The newest version of Firefox ...

iDigitalTimes.com
Firefox 21: Mozilla Releases Browser Updates For Mac, Windows, Linux, Android
iDigitalTimes.com
Mozilla Firefox may not be the most popular web browser in the world -- that achievement now belongs to Google Chrome -- but fans of the free, open-source web browser are as excited about the browser as ever. Firefox 20, which was released in April ...

Golem.de
Sicherheitslücke Rechteerschleichung über den Mozilla Maintenance Service
Golem.de
Der Mozilla Maintenance Service von Firefox und Thunderbird lässt sich von lokaler Schadsoftware zur Erlangung höherer Rechte ausnutzen. Die Sicherheitslücke kann nur über Umwege ausgenutzt werden. Andere Lücken sind allerdings kritisch und ...

It’s an exceptional time to be a product person and a founder: we are collectively responsible for—and a part of—inventing the future. In the last ten years, design has changed the face of consumer electronics. That change has impacted the way we live, from how we communicate to how we get around.

I started Massive Health as a designer and a founder. These are the most important lessons and psychological pitfalls I learned. They apply to any founder or manager who is also a creative.

Your Job Isn’t To Make A Great Product

As a founder, your job isn’t to make a great product. It’s to build a great team that makes great products. You are who you hire.

If you love doing something, under no condition should you start a VC-backed company to do more of it. You won’t. You are going to spend all of your time recruiting, fundraising, recruiting, aligning team vision, recruiting, and figuring out which fires you can safely ignore.

To maintain your psychological health, you’ll need to learn how to shift the fufillment you get from making to the fufillment of enabling a team to make. You’ll be making vicariously, not making directly. You’ll have to come to terms and internalize it or else your lack of emotional fufillment will trickle down to your team.

Very early on, you’ll be able to make stuff. Enjoy it. It won’t last. In fact, making stuff as your team grows is often more harmful than helpful.

The Dangers of “Helping” & The Power of Words

Because you will spend your time building a great team that builds great product, the moments that you directly work on product will be rare. The rarity will make it insanely tempting—and it will feel insanely good—to get your hands dirty by fixing an interaction flow, pushing around some pixels, doing an information re-architecture, or whatever you may be passionate about. Here’s the thing: that can be insanely disruptive unless handled carefully.

Here’s why:

1

You are a founder, which means each word you say lands like an anvil. Even in a very small company, and especially in a larger one, it takes fortitude and courage for a team member to honestly critique your work. The courage required isn’t a one-time cost. It’s incurred every single time. By nature of being a founder, you are used to saying things with charisma and force and you will undoubtedly be excited by your solution and argue for it. This just makes it worse. A final note: it doesn’t matter how nice you are, or how close you are to your team. As a founder, your words are always more powerful than you think.

2

It’s easy for a brainstorm to be taken as direction. I talked to Tony Fadell of Nest and iPod fame about this topic: To this day, in every conversation he has—every—he tries to reiterate whether he is brainstorming or setting direction. Putting this into practice, you’ll feel like you are repeating yourself. That everyone gets it. Don’t stop. Keep saying it. Get used to saying it.

3

When you swoop in to help with complex problems, the person working on the problem has all the context and knows the pitfalls. You’ve hired this person because they are amazing at their job. Jumping in and then advocating for your ideas is often interpreted as a lack of trust in their ability. This can be a huge morale drain. Not only that, but your suggestions may be shortsighted. You’re jumping in—they’re living it.

You are a founder because of your vision and ability. Your input is, in fact, critical.

So what should you do? Define the problem and its constraints. Framing the problem is the most important step in helping your team find the right solution. You can and should point out what’s wrong with a design or product (sandwiching it with praise), just don’t prescribe how to fix it. Never give a solution unless a team member comes to you for help.

Hype can be psychologically compromising

Massive Health launched with a fair amount of hype. We were glad for it—it gave us good brand recognition while hiring, which is the most valuable outcome of PR for a pre-launch startup. But, it’ll hurt in ways you aren’t expecting. Think back to Color and how the hype overshadowed their product; it set expectations so high that whatever they made probably wouldn’t be good enough. When their product launched, the market thrashed them. That’s the obvious way hype hurts, and it’s not even the one I’m talking about.

The more subtle (and more damaging) way that hype hurts is psychologically. The hype nestled in the back of your mind is constantly tugging, saying that your product is never good enough to launch. That it isn’t big enough. That it isn’t ground-breaking enough.

The single most important thing a founder has to know is where to focus his team’s energy: what is and isn’t safe to ignore, which shortcuts are helpful or harmful, and where and when to invest in absolute perfection.

Hype compromises that ability.

Looking back, this was a major factor in launching only one of the awesome products we were working on at Massive. As a founder, I let perfect be the enemy of the good.

Ego And Reputation

A corollary to the psychological pressure of hype is ego. All product people learn the painful process of divorcing ideas from ego. That’s how great products are made. As a founder, you’ll have to learn how to divorce your ego from your company’s success.

You’ll live with knowing that you are personally judged based upon your company’s performance. That your reputation is tied to your company’s reputation. You’ll no longer be judged on your own work, but your team’s work. It will make you want to get too directly involved in the design. And, as we know, that’s dangerous.

Early on at Massive Health, I did not articulate these worries clearly or directly. It was just a fuzzy haze of emotion that confused my decision-making. Once I was able to articulate what was going on, it helped me mitigate its effects.

Be aware that ego can and will get in the way and be ready to fight it.

So Being A Designer and A Founder Sucks?

Not at all. It gives you huge strategic advantages. The Designer Fund articulates that well.

I founded Massive Health because there was a storm brewing: just over the horizon health was about to become consumerized; that quantified self would escape its geeky beginings and morph to become mainstream; that the Apples and Googles of consumer health didn’t yet exist but were about to. At the center of it all was design; and that design-focus is enabling us, now as a part of Jawbone, to invent the future.

The more you know.

Related posts:

1. So You Want To Be A Designer: Top 5 List
2. Massive Health: Raised Money, Spending On New Hires

Why Upgrade Your HR Systems?
CFO Magazine
CFOs may not be experts in either HR or technology, but they should know enough to sign off confidently on a buying decision. David McCann. Article; Comments (0). Repost This. |. Like. Email Print Single Page Minus Text Size Plus. This is the first of ...

en meer »

It's often said that the web needs a bytecode. For example, the very first comment in a very recent article on video codecs on the web says
A proper standardized bytecode for browsers would (most likely) allow developers a broader range of languages to choose from as well as hiding the source code from the browser/viewer (if that's good or not is subjective of course). And other comments continue with
Just to throw a random idea out there: LLVM bytecode. That infrastructure already exists, and you get to use the ton of languages that already have a frontend for it (and more in the future, I'm sure).
[..]
I also despise javascript as a language and wish someone would hurry up replacing it with a bytecode so we can use decent languages again.
[..]
Put a proper bytecode engine in the browser instead, and those people that love javascript for some unknowable reason could still use it, and the rest of us that use serious languages could use them too.
[..]
Honestly, .Net/Mono would probably be the best bet. It's mature, there are tons of languages targeting it, and it runs pretty much everywhere already as fast as native codeIgnoring the nonproductive JS-hating comments, basically the point is that people want to use various languages on the web, and they want those languages to run fast. Bytecode VMs have been very popular since Java in the 90's, and they show that multiple languages can run in a single VM while maintaining good performance, so asking for a bytecode for the web seems to make sense at first glance.

But already in the quotes above we see the first problem: Some people want one bytecode, others want another, for various reasons. Some people just like the languages on one VM more than another. Some bytecode VMs are proprietary or patented or tightly controlled by a single corporation, and some people don't like some of those things. So we don't actually have a candidate for a single universal bytecode for the web. What we have is a hope for an ideal bytecode - and multiple potential candidates.

Perhaps though not all of the candidates are relevant? We need to pin down the criteria for determining what is a "web bytecode". The requirements as mentioned by those requesting it include

• Support all the languages
• Run code at high speed

To those we can add two additional requirements that are not mentioned in the above quotations, but are often heard:

• Be a convenient compiler target
• Have a compact format for transfer

In addition we must add the requirements that anything that runs on the web must fulfill,

• Be standardized
• Be platform-independent
• Be secure

JavaScript can already do the last three (it's already on the web, so it has to). Can it do the first four? I would say yes:

• Support all the languages: A huge list of languages can compile into JavaScript, and that includes major ones like C, C++, Java, C#, LLVM bytecode, and so forth. There are some rough edges - often porting an app requires changing some amount of code - but nothing that can't be improved on with more work, if the relevant communities focus on it. C++ compilers into JavaScript like Emscripten and Mandreel have years of work put into them and are fairly mature (for example see the Emscripten list of demos). GWT (for Java) has likewise been used in production for many years; the situation for C# is perhaps not quite as good, but improving, and even things like Qt can be compiled into JavaScript. For C#, Qt, etc., it really just depends on the relevant community being focused on the web as one of its targets: We know how to do this stuff, and we know it can work.
• Run code at high speed: It turns out that C++ compiled to JavaScript can run at about half the speed of native code, which in some cases outperforms Java, and is expected to get better still. Those numbers are when using the asm.js subset of JavaScript, which basically structures the compiler output into something that is easier for a JS engine to optimize. It's still JavaScript, so it runs everywhere and has full backwards compatibility, but it can be run at near-native speed already today.
• Be a convenient compiler target: First of all, the long list of languages from before shows that many people have successfully targeted JavaScript. That's the best proof that JavaScript is a practical compiler target. Also, there are many languages that compile into either C or LLVM bytecode, and we have more than one compiler capable of compiling those to the web, and one of them is open source, so all those languages have an easy path. Finally, while compiling into a "high-level" language like JavaScript is quite convenient, there are downsides, in particular the lack of support for low-level control flow primitives like goto; however, this is addressed by reusable open source libraries like the Relooper.
• Have a compact format for transfer: It seems intuitive that a high-level language like JavaScript cannot be compact - it's human-readable, after all. But it turns out though that JS as a compiler target is already quite small, in fact comparable to native code when both are gzipped. Also, even in the largest and most challenging examples, like Unreal Engine 3, the time spent to parse JS into an AST does not need to be high. For example, in that demo it takes just 10 seconds on my machine to both parse and fully optimize the output of over 1 million lines of C++ (remember that much of that optimization time would need to be done no matter what format the code is in, because it has to be a portable one).

So arguably JavaScript is already very close to providing what a bytecode VM is supposed to offer, as listed in the 7 requirements above. And of course this is not the first time that has been said, see here for a previous discussion from November 2010. In the 2.5 years since that link, the case for that approach has gotten significantly stronger, for example, JavaScript's performance on compiled code has improved substantially, and compilers to JavaScript can compile very large C++ applications like Unreal Engine 3, both as mentioned before. At this point the main missing pieces are, first (as already mentioned) improving language support for ones not yet fully mature, and second, a few platform limitations that affect performance, notably lack of SIMD and threads with shared state.

Can JavaScript fill the gaps of SIMD and mutable-memory threads? Time will tell, and I think these things would take significant effort, but I believe it is clear that to standardize them would be orders of magnitude simpler and more realistic than to standardize a completely new bytecode. So a bytecode has no advantage there.

Some of the motivation for a new bytecode appears to come from an elegance standpoint: "JavaScript is hackish", "asm.js is a hack", and so forth, but a new from-scratch bytecode would be (presumably) a thing of perfection. That's an understandable sentiment, but technology has plenty of such things, witness the persistence of x86, C++, and so forth (some would add imperative programming to that list). It's not only true of technology but human civilization as well, for example no natural language has the elegance of Esperanto, and our currently-standing legal and political systems are far from what a from-scratch redesign would arrive at. But large long-standing institutions are easier to improve continuously rather than to completely replace. I think it's not surprising that that's true for the web as well.

(Note that I'm not saying we shouldn't try. We should. But we shouldn't stop trying at the same time to also improve the current situation in a gradual way. My point is that the latter is more likely to succeed.)

Elegance aside, could a from-scratch VM be better than JavaScript? In some ways of course it could, like any redesign from scratch of anything. But I'm not sure that it could fundamentally be better in substantial ways. The main problem is that we just don't know how to create a perfect "one bytecode to rule them all" that is

• Fast - runs all languages at their maximal speed
• Portable - runs on all CPUs and OSes
• Safe - sandboxable so it cannot be used to get control of users' machines

The elusive perfect universal bytecode would need to do all three, but it seems to me that we can only pick two.

Why is this so, when supposedly the CLR and JVM show that the trifecta is possible? The fact is that they do not, if you really take "fast" to mean what I wrote above, which is "runs all languages at their maximal speed" - that's what I mean by "perfect" in the context of the last paragraph. For example, you can run JavaScript on the JVM, but it won't come close to the speed of a modern JS VM. (There are examples of promising work like SPUR, but that was done before the leaps in JS performance that came with CrankShaft, TypeInference, IonMonkey, DFG, etc.).

The basic problem is that to run a dynamic language at full speed, you need to do the things that JavaScript engines, LuaJIT, etc. do, which includes self-modifying code (architecture-specific PICs), or even things like entire interpreters in handwritten optimized assembly. Making those things portable and safe is quite hard - when you make them portable and safe, you make them more generic pretty much by definition. But CPUs have significant-enough differences that doing generic things can lead to slower performance.

The problems don't stop there. A single "bytecode to rule them all" must make some decisions as to its basic types. LuaJIT and several JavaScript VMs represent numbers using a form of NaNboxing, which uses invalid values in doubles to store other types of values. Deciding to NaNbox (and in what way) or not NaNbox is typically a design desicion for an entire VM. NaNboxing might be well and good for JS and Lua, but it might slow down other languages. Another example is how strings are implemented: IronPython, Python on .NET, ran into issues with how Python expects strings to work as opposed to .NET.

Yet another area where decisions must be made is garbage collection. Different languages have different patterns of usage, both determined by the language itself and the culture around the language. For example, the new garbage collector planned for LuaJIT 3.0, a complete redesign from scratch, is not going to be a copying GC, but in other VMs there are copying GCs. Another concern is finalization: Some languages allow hooking into object destruction, either before or after the object is GC'd, while others disallow such things entirely. A design decision on that matter has implications for performance. So it is doubtful that a single GC could be truly optimal for all languages, in the sense of being "perfect" and letting everything run at maximal speed.

So any VM must make decisions and tradeoffs about fundamental features. There is no obvious optimal solution that is right for everything. If there were, all VMs would look the same, but they very much do not. Even relatively similar VMs like the JVM and CLR (which are similar for obvious historic reasons) have fundamental differences.

Perhaps a single VM could include all the possible basic types - both "normal" doubles and ints, and NaNboxed doubles? Both Pascal-type strings and C-type strings? Both asynchronous and synchronous APIs for everything? Of course all these things are possible, but they make things much more complicated. If you really want to squeeze every last ounce of performance out of your VM, you should keep it simple - that's what LuaJIT does, and very well. Trying to support all the things will lead to compromises, which goes against the goal of a VM that "runs all languages at their maximal speed".

(Of course there is one way to support all the things at maximal speed: Use a native platform as your VM. x86 can run Java, LuaJIT and JS all at maximal speed almost by definition. It can even be sandboxed in various ways. But it has lost the third property of being platform-independent.)

Could we perhaps just add another VM like the CLR alongside JavaScript, and get the best of both worlds that way, instead of putting everything we need in one VM? That sounds like an interesting idea at first, but it has technical difficulties and downsides, is complex, and would likely regress existing performance.

Do we actually need "maximal speed"? How about just "reasonable speed"? Definitely, we can't hold out for some perfect VM that can do it all. In the last few paragraphs I've been talking about a "perfect" bytecode VM that can run everything at maximal speed. My point is that it's important to realize that there is no such VM. But, with some compromise we definitely can have a VM that runs many things at very high speeds. Examples of such VMs are the JVM, CLR, and as mentioned before JavaScript VMs as well, since they can run one very popular dynamic language at maximal speed, and they can run statically typed code compiled from C++ about as well or even better than some bytecode VMs (with the already-discussed caveats of SIMD and shared-mutable threads).

For that reason, switching from JavaScript to another VM would not be a strictly better solution in all respects, but instead just shift us to another compromise. For example, JavaScript itself would be slower on the CLR, but C# would be faster, and I'm not sure which of the two can run C++ faster, but my bet is that both can run it at about the same speed.

So I don't think there is much to gain, technically speaking, from considering a new bytecode for the web. The only clear advantage such an approach could give is perhaps a more elegant solution, if we started from scratch and designed a new solution with less baggage. That's an appealing idea, and in general elegance often leads to better results, but as argued earlier there would likely be no significant technical advantages to elegance in this particular case - so it would be elegance for elegance's sake.

I purposefully said we don't need a new bytecode in the last paragraph. We already have JavaScript, which I have claimed is quite close to providing all the advantages that a bytecode VM could. Note that this wasn't entirely expected - not any language can in a straightforward way be transformed into a more general target for other languages. It just so happens though that JavaScript did have just enough low-level support (bitwise operations being 32-bit, for example) to make it a practical C/C++/LLVM IR compiler target, which made it worth investing in projects like the Relooper that work around some of its other limitations. Combined with the already ongoing speed competition among JavaScript engines, the result is that we now have JavaScript VMs that can run multiple languages at high speed.

In summary, we already have what practically amounts to a bytecode VM in our browsers. Work is not complete, though: While we can port many languages very well right now, support for other languages is not quite there yet. If you like a language that is not yet supported on the web, and you want it to run on the web, please contribute to the relevant open source project working on doing that (or start one if there isn't one already). There is no silver bullet here - no other bytecode VM that if only we decided on it, we would have all the languages and libraries we want on the web, "for free" - there is work that needs to be done. But in recent years we have made huge amounts of progress in this area, both in infrastructure for compiling code to JavaScript and in improvements to JavaScript VMs themselves. Let's work together to finish that for all languages.

Techtree.com
Firefox Health Report: Your Browser Now Phones Home to Mozilla - The Next Web
The Next Web
Mozilla today announced the release of Firefox 21. In the changelog, the company included an interesting point: “Preliminary implementation of Firefox Health Report.” Those with a sharp memory will remember that FHR was first announced back in ...
Mozilla pushes out new Firefox and Thunderbird: 8 security advisories, 3 ...Naked Security
Mozilla to Firefox: 'Browser, heal thyself'ComputerworldUK
Mozilla releases Firefox 21 with usage reportingInquirer
BGR India -Techtree.com -VR-Zone
alle 42 nieuwsartikelen »

OnSoftware NL
Mozilla lanceert vandaag Firefox 21
OnSoftware NL
Mozilla lanceert vandaag versie 21 van webbrowser Firefox. Zes weken geleden presenteerde het bedrijf voorloper Firefox 20 en volgens Mozilla-traditie verschijnt vandaag de nieuwe versie. De vernieuwde variant van de populaire open source browser ...
Firefox 21 plamuurt veiligheidsgaten en is socialerZDNet.nl

alle 7 nieuwsartikelen »

Giga.de
Mozilla: Firefox-OS auf High-End-Smartphones
Heise Newsticker
Mozillas Mobilbetriebssystem Firefox OS soll nicht nur auf Einsteigergeräten laufen. Laut Li Gong, bei Mozilla für die Mobilgerätesparte zuständig, könnte Sony demnächst ein High-End-Smartphone mit dem neuen System vorstellen. Bereits im Februar hatte ...
Mozilla Firefox 21 mit H.264-Unterstützung veröffentlichtGolem.de
Firefox 21 im Praxis-Test: Neuer Mozilla-Browser holt aufCOMPUTER BILD
Mozilla Firefox installieren und deinstallieren: TutorialGiga.de
ZDNet.de -Software und jede Menge Tipps & Tricks -GameStar
alle 33 nieuwsartikelen »

com-magazin.de
Mozilla Firefox 21 mit H.264-Unterstützung veröffentlicht
Golem.de
Mozilla hat Firefox 21 veröffentlicht. Unter Windows spielt der Browser erstmals Videos im Format H.264 ab. Zudem hat Mozilla die Do-Not-Track-Einstellungen erweitert und den Firefox Health Report (FHR) integriert, mit dem Mozilla mehr Daten für die ...
Mozilla sieht Firefox OS auch auf Geräten der OberklassePro-Linux
Mozilla: Firefox-OS auf High-End-SmartphonesHeise Newsticker
Mozilla veröffentlicht Firefox 21Netzwoche
COMPUTER BILD -com-magazin.de
alle 49 nieuwsartikelen »

Firefox for Android comes with the custom, open source fonts Charis and Open Sans to make the Web more beautiful and easier to read on your small screen. The Web is made up almost entirely of text and sometimes reading text can be difficult on small phone and tablet screens. These new fonts will replace the three available Android default fonts to enable a more visually appealing and clear reading experience on the Web. The difference is subtle, but beautiful.

Firefox for Android includes HTML5 compatibility improvements as tested on HTML5test.com, the leading industry HTML5 compliance test. Firefox Firefox scores 421 and 14 bonus points (out of a total of 500).

Thanks to the hard work of the many Mozillians who contribute to building the best mobile browser, Firefox for Android now has an average rating of 4.5 stars in the Google Play Store. Whoo-hoo!

For more information:

• Download Firefox for Android
• Firefox for Android Release Notes

Social sites are a key part of online life and with Firefox we want to make it easier to use the Web the way you want.  Mozilla developed the Social API to enable social providers to integrate directly into Firefox to make your browsing experience more social, customizable and personal. The Social API makes it easy for your favorite social providers to add a sidebar with your content to Firefox or notification buttons directly on the Firefox toolbar.

Last year we launched with Facebook as the first social integration partner in Firefox. Today, we are adding multiple new social providers Cliqz, Mixi and msnNOW to Firefox, in addition to Facebook Messenger for Firefox, to help you stay connected to your social networks, no matter where you go on the Web.

The new social providers in Firefox make it even easier for you to keep up with friends, family, news and events while you surf the Web. You can get real time updates about news activity, entertainment or your personal network while you browse the Web.

New providers you can now add to your Firefox include:

Cliqz:

Cliqz delivers a real-time stream of the most relevant articles, stories, and videos based on your interests directly to Firefox. In the upper left of the sidebar, you can personalize your news feed by selecting categories, keywords, websites, and specific people you want to follow. Share links across your social networks or by email; preview Twitter commentary; and save articles for later without ever leaving Firefox.

To activate, visit the Cliqz activation page and click “Activate Cliqz.”

Mixi:

The Mixi sidebar let’s you easily stay in touch with your friends on the Mixi social network in Japan. It provides a real-time activity stream of all comments and photo shares from your personal social network directly to your Firefox browser. Mixi for Firefox is only available to users in Japan.

msnNOW:

msnNOW makes it easy to stay up to date on the things people are talking about, searching for and sharing the most on Web. MSN scours the most interesting trends from real-time sources like Facebook, Twitter, Bing, and BreakingNews.com, so you’ll always know what’s happening and get the jump on what everyone is talking about. You can customize the activity stream to watch for particular types of trending content from the sidebar dropdown menu.

 To activate, go to the msnNOW page and click “Turn it On.”

The Social API has endless potential for integrating social networks, e-mail, finance, music, cloud possibilities, services, to-do lists, sports, news and other applications into your Firefox experience.  We designed the Social API to make it easier and more convenient to use the Web the way you want.  Soon we’ll add even more ways to integrate your favorite Web services into your Firefox Web experience.

For more information:

• Download Firefox for Windows, Mac and Linux
• Firefox for Windows, Mac and Linux Release Notes
• More information on Firefox Health Report

So, I didn’t actually mean to post that previous post, I had intended to think more on the idea. But oh well, cat’s out of the bag. In any case, I’ve been thinking about the “closures” vs “procedures” idea that I jotted down there and decided to try and elaborate on it a bit more, since I find it has a lot of appeal. In particular I think that the current collection of closure types is addressing too many distinct use cases and the result is confusing.

UPDATE 2013.05.14: Edited to tweak various errors and to add some variations at the end that I prefer.

Today: by-reference vs copying closures

Today we offer three different kinds of closures (&fn, @fn, and ~fn), but these closures can really be divided into two basic categories: by-reference and copying closures. A by-reference closure is the usual kind: it is allocated on the stack and has full access to the variables in the creating stack frame. It can read them, write them, and borrow them. These are used with for loops and the like.

Copying closures, on the other hand, are somewhat different. They are not tied to any particular stack frame. Instead, they copy the current values of the variables which they close over into their environment (like all the default Rust copies, this is a shallow copy, so if the value being closed over contains ~ pointers, it will no longer be accessible from the creator). These closures are used primarily as task bodies and for futures. There are some scattered uses of @fn closures in the compiler but as far as I can tell they are all legacy code that should eventually be purged and rewritten to use traits (i.e., the visitor, the AST folder).

Loosely speaking, a &fn closure is by-reference and @fn and ~fn closures are copying closures. But this is not strictly true. In fact, an the &fn type can be either a by-reference closure or a copying closure, because you are permitted to borrow a @fn or ~fn to a &fn. So the type in isolation does not tell you whether a closure is by-reference or not. In fact, there is no explicit indication at all—instead, when you create a closure today (i.e., with a |x, y| ...) expression, the compiler infers based on the expected types whether this should be a by-reference closure or a copying closure. Because the semantics of these two vary greatly, I find this potentially quite confusing and unfortunate.

Tomorrow (perhaps): closures and procedures

In general, I would prefer to draw a starker line between copying and by-reference closures. I propose to use the term closure to refer only to by-reference, stack-allocated closures. We could then use another term, perhaps procedure, to refer to the copying closures. This would mean that our type hierarchy would look like:

T = S // sized types | U // unsized types S = fn(S*) -> S // closures (*) | &'r T // region ptr | @T // managed ptr | ~T // unique ptr | [S, ..N] // fixed-length array | uint // scalars | ... U = [S] // vectors | str // string | Trait // existential ("exists S:Trait.S") | proc(S*) -> S // procedures (*)

This chart is basically the same as the one you will find in the dynamically sized types post from before with one crucial difference: closure types have been split from procedures, and closure types have moved into the category of sized types, meaning that you no longer write an explicit sigil when you use one. This is because the representation of a closure would always be a pair of a borrowed pointer into the stack and a function pointer: the type has a fixed size (two words) and requires no memory allocation.

I have chosen to leave procedures as unsized, since a procedure must allocate memory on the heap, and this allows the user to select which heap is used; in earlier drafts of this idea, I had modified procedures to implicit use the exchange heap, meaning that a type like proc() always represented an exchange heap allocation. But I think it’s more consistent to have that type be written ~proc, and it maintains the general Rust invariant “you don’t have allocation unless you see a sigil”.

UPDATE: bstrie on IRC asked about fn items, which never have any environment. As today, these would continue to be coercable to either a closure or a procedure.

Closure and procedure expressions

Closures would still be created with the form |x, y| expr. Procedures would be created using the keyword proc: proc(x, y) expr. If desired, we could integrate procedures into do using some syntax like one of the following, depending on whether we wish to make the sigil explicit:

do spawn proc { ... } // sigil inferred do spawn ~proc { ... } // sigil explicit Closure and procedure types in more detail

The full function or procedure type would look something like this ([] indicates optional content):

[once] (fn|proc) [:['r] [Bounds]] <'a...> (S*) -> S ^~~~~^ ^~~~~~~~~~~~~~~^ ^~~~~~^ ^~~^ ^ | | | | | | | | | Return type | | | Argument types | | Bound lifetime names | Lifetime and trait bounds Onceness

Here the “onceness” indicates whether the closure/procedure can be called more than once. The “lifetime and trait bounds” indicate constraints on the environment. The lifetime bound 'r indicates the minimum lifetime of the variables that the closure/procedure closes over, and the “bounds” (if any) would give bounds on the types of those variables. Finally, you have the argument and return types.

If omitted, the default bounds for a closure would be a fresh lifetime and no type bounds. The default bounds for a procedure would be the static lifetime and Owned.

Use cases

Let’s look briefly at the use cases I listed before.

Higher-order and once functions

Typical uses for higher-order and once functions look much the same as before, but minus a sigil.

impl<T:Sized> for [T] { pub fn map<U:Sized>(f: fn(&T) -> U) -> ~[U] { ... } // ^~~~~~~~~~~ } impl<T:Sized> for Option<T> { // `each` on an option type can only execute at most once: pub fn each(f: once fn(&T) -> bool) -> bool { ... } // ^~~~~~~~~~~~~~~~~~~ } }

For contrast, these are &fn(&T) -> U and &once fn(&T) -> bool today.

Sendable functions and sendable once functions

Here is an example of a sendable once function:

fn spawn(f: ~once proc()) {...} // ^~~~~~~~~~

As we saw before, one would write one of the following to call this function:

do spawn proc { ... } spawn(proc { ... })

Creating a future would look like future(proc expr) (vs future(|| expr) today).

Const closures

One could still use const closures to achieve lightweight parallelism:

impl<T:Sized> for [T] { pub fn par_map<U:Sized>(f: fn:Const(&T) -> U) -> bool { ... } // ^~~~~~~~~~~~~~~~~ }

However, I have been thinking that we’ll have to be careful here, we need some way to guarantee that the closure does not move from its environment and then replace the moved value. Today this is illegal, but if we can prevent closures from recursing (which we must do anyhow) then we could make such moves legal, and it would be useful sometimes. On simple solution is to stay that if the closure type has a Const bound, moves are illegal, but it’s a bit…ad-hoc, since the bounds are only supposed to be constraining the types of the variables that are closed over. Still, it might be good enough.

Sendable const functions and combinators

As I argued before, I think these are not important use cases, but with procedures they actually work out fine (though not with variations 2 and 3 below). A sendable const function can be expressed with the type ~proc:Owned+Const(), which is complex, but then it is a complex idea. Combinator types would likely look like @proc or @proc:'r, in the case where the combinator closes over borrowed data.

Variation #1: Leaving procedures out of the core language

In fact, I think proc types need not be built into the language, you could model them with traits, though you’d probably want a macro like proc!(...) for defining the proc body. This would also mean the procedures can’t be used with do form.

Variation #2: Limit procedures to execute once

I don’t know of any (good) uses cases for non-once procedures. I think they should just always be once. This would mean that the only closure types that are commonly needed would be:

1. fn(T) – normal higher-order functions
2. once fn(T) – higher-order functions that execute at most once
3. ~proc(T) – procedures

Because procedures can always be desugared into a struct and a trait, this would not lose no expressiveness.

Variation #3: Limit procedures to execute once and use exchange heap

For maximum streamlining, we could make proc implicitly use ~, in which case it would be written:

1. fn(T) – normal higher-order functions
2. once fn(T) – higher-order functions that execute at most once
3. proc(T) – procedures

These types read pretty well, I think.

Summary

I have long been unsatisfied with the implicit and confusing divide between “by reference” and “copying” closures. Splitting them into two concepts seems to address a lot of issues and be an overall win to me.

Techtree.com
Download Mozilla Firefox 21 Before Official Launch
Techtree.com
The next version of Mozilla's web browser, Firefox v21 can now be downloaded before its official release. The PC version of Mozilla's Firefox 21 is available for download via Mozilla's FTP servers. Windows users can head straight to the US English ...

OnSoftware NL
Mozilla lanceert vandaag Firefox 21
OnSoftware NL
Mozilla lanceert vandaag versie 21 van webbrowser Firefox. Zes weken geleden presenteerde het bedrijf voorloper Firefox 20 en volgens Mozilla-traditie verschijnt vandaag de nieuwe versie. De vernieuwde variant van de populaire open source browser ...
Firefox 21 beschikbaar, officiële lancering morgenTechzine

alle 2 nieuwsartikelen »

WinBeta
Mozilla Firefox 21 exits Beta, grab your download here
WinBeta
Mozilla Firefox 21 is no longer in Beta, as the company has released the new Firefox browser today. However, as we are hours away from the official release, Mozilla has already uploaded the new version to its servers, for all to download. Firefox 21 ...
Five new features coming in Firefox 21 tomorrowPCWorld
Firefox 21.0: Find out what is newGhacks Technology News
Firefox 21 out now with improved Do Not Track featureOnSoftware

alle 9 nieuwsartikelen »

Mobile World Live
Mozilla courts developers with free phone
Mobile World Live
Mozilla announced its Phones for Apps for Firefox OS programme, which will see approved developers receiving free handsets on which to test apps. In order to participate, developers need to show Mozilla “a great app idea and the skill to build it”. If ...
Free Firefox OS devices for developers - DecryptedTechDecryptedTech

alle 2 nieuwsartikelen »

I got to spend Wednesday through Friday in Edinburgh last week to attend Scotland.JS. Edinburgh is a lovely city and I will definitely return to get to know it better. It has great people, beers, food and even a castle - what could one want more?

I arrived on Wednesday, just in time for the TechMeetup. It took place in the Appleton Tower and had about 70-80 attendees with quite diverse technical backgrounds. I had a very interesting talk to a freelance patent attorney and also met a couple of people I knew from recent conferences and meetups in Berlin. After we were out of free pizza and beers we met most of the Scotland.JS attendees in a pub right next to the Appleton Tower. Cue more beers and tech conversations.

Thursday was the first day of Scotland.JS that started with a great keynote from Jan Lehnardt. The most memorable talk of the day was about Functional Reactive Programming using Bacon.js by Philip Roberts. There of course were a lot more great talks but the possibilities of creating and combining event streams kept my head spinning the most. At the end of the day we again went to a neat pub near the venue and I headed to bed rather early, still a little tired from travel and the day before.

Friday started with a short 20-minute walk through Edinburgh’s old town that I needed to pass on my way to the venue. My favorite talk of the second and last day was held by Dominic Tarr that tought us about the internals of leveldb. I also really enjoyed Mark Boas talking about making audio a first-class citizen of the web - a very entertaining and impressive mix of technologies. A GitHub drinkup in the venue’s own pub was a great way to end the conference - lots of good conversations with Scotland.JS attendees and speakers as well as people from the local tech community and visitors of the Scottish Ruby Conf.

I flew home the very next day and already miss Edinburgh with its neat little alleys and pubs everywhere. The JavaScript community has once again shown its value as a very interesting mix of nice welcoming people coming from so many different technical backgrounds. Like after most conferences I feel a little exhausted and my head is full of ideas for future or current (side-)projects. I will try my best to return next year, it has been a lot of fun!

I’ve been thinking about what I wrote in my last post regarding closures and I am beginning to change my opinion about the correct solution. fn~ just seems so unfortunate. So, besides writing fn~, what are the other options? I just thought I’d write down a few of the other ideas I’ve come up with for later reference. Not saying any of the ideas in this post are good yet.

Just write &mut fn()

Maybe it’s not so bad. It is advertising the possibility that the closure may mutate its environment. This would mean that while &fn() is a valid type, it is a type that does not permit the function to be called, much as &&mut (pointer to a mutable borrowed pointer) does not permit the mutable borrowed pointer to be used.

At first I was thinking that there is also a valid interpretation for &fn, meaning a function that does not mutate the variable in its environment, but then I realize that per the DST proposal any &mut fn could be borrowed to &fn, and so that would not be sound.

Remove everything but borrowed closures

We could just only have borrowed closures. The type would be written fn[:bounds]() or once fn[:bounds](). There’d be no need to notate the kind of environment pointer: it’s always a borrowed pointer. All other uses of closures would be expressed using traits and impls.

Mainly this means that code which spawns traits would get somewhat verbose, because you would need to create a struct or some other type to capture all of the upvars. For larger tasks, this is not a big deal, but for some code it could be rather annoying. I imagine futures in particular would become much more verbose; enough so as to be nearly unusable.

On the upside, there’d be no more confusion about whether a closure copies its environment or not (no, it never does). Closure types would be simpler (no need to worry about sigils). You’d write fn() or once fn() in all but the most esoteric cases. The code to manage closures would become much simpler.

Add a new keyword for what is now called an “owned closure”

This is basically the fn~ solution with another name. Rather than writing fn~ to indicate a closure value that owns its environment, we could write proc (for procedure) or something like that. This avoids the annoying “sigil after the name”, at the cost of a new keyword.

Procedures could probably always be single-shot (that is, once). Almost all use cases for them (futures, tasks, etc) are single-shot, and the others could probably be accommodated with traits instead. But we could also distinguish between a proc and a once proc if we wanted.

Procedures would probably be less interoperable with functions, since the name does not particularly suggest interoperability. For example, I imagine you could not use a proc where a fn is expected. I don’t know of any time that this is actually important.

Using a different name also helps to draw a clear line between between “closures” (which reference the variables in the stack frame that created them) and “procedures” (which copy out from that stack frame). I personally would prefer to designate procedures with a different syntax, e.g., proc(x, y) { ... } in place of |x, y| ..., but this is not necessary (as an aside, I had hoped to write some today about why I think our current use of || to designate any kind of closure is troublesome and should be changed, before I realized that we’d have to address this problem I’m thinking over instead).

More ideas?

Ok, that’s most of the more radical ideas I’ve had so far. I’ll have to keep thinking on it.

I'd like to make an attempt at delivering regular status updates on the Gecko/Firefox build system and related topics. Here we go with the first instance. I'm sure I missed awesomeness. Ping me and I'll add it to the next update.

MozillaBuild Windows build environment updated

Kyle Huey released version 1.7 of our Windows build environment. It contains a newer version of Python and a modern version of Mercurial among other features.

I highly recommend every Windows developer update ASAP. Please note that you will likely encounter Python errors unless you clobber your build.

New submodule and peers

I used my power as module owner to create a submodule of the build config module whose scope is the (largely mechanical) transition of content from Makefile.in to moz.build files. I granted Joey Armstrong and Mike Shal peer status for this module. I would like to eventually see both elevated to build peers of the main build module.

moz.build transition

The following progress has been made:

• Mike Shal has converted variables related to defining XPIDL files in bug 818246.
• Mike Shal converted MODULE in bug 844654.
• Mike Shal converted EXPORTS in bug 846634.
• Joey Armstrong converted xpcshell test manifests in bug 844655.
• Brian O'Keefe converted PROGRAM in bug 862986.
• Mike Shal is about to land conversion of CPPSRCS in bug 864774.

Non-recursive XPIDL generation

In bug 850380 I'm trying to land non-recursive building of XPIDL files. As part of this I'm trying to combine the generation of .xpt and .h for each input .idl file into a single process call because profiling revealed that parsing the IDL consumes most of the CPU time. This shaves a few dozen seconds off of build times.

I have encounterd multiple pymake bugs when developing this patch, which is the primary reason it hasn't landed yet.

WebIDL refactoring

I was looking at my build logs and noticed WebIDL generation was taking longer than I thought it should. I filed bug 861587 to investigate making it faster. While my initial profiling turned out to be wrong, Boris Zbarsky looked into things and discovered that the serialization and deserialization of the parser output was extremely slow. He is currently trying to land a refactor of how WebIDL bindings are handled. The early results look very promising.

I think the bug is a good example of the challenges we face improving the build system, as Boris can surely attest.

Test directory reorganization

Joel Maher is injecting sanity into the naming scheme of test directories in bug 852065.

Manifests for mochitests

Jeff Hammel, Joel Maher, Ted Mielczarek, and I are working out using manifests for mochitests (like xpcshell tests) in bug 852416.

Mach core is now a standalone package

I extracted the mach core to a standalone repository and added it to PyPI.

Mach now categorizes commands in its help output.

Requiring Python 2.7.3

Now that the Windows build environment ships with Python 2.7.4, I've filed bug 870420 to require Python 2.7.3+ to build the tree. We already require Python 2.7.0+. I want to bump the point release because there are many small bug fixes in 2.7.3, especially around Python 3 compatibility.

This is currently blocked on RelEng rolling out 2.7.3 to all the builders.

Eliminating master xpcshell manifest

Now that xpcshell test manifests are defined in moz.build files, we theoretically don't need the master manifest. Joshua Cranmer is working on removing them in bug 869635.

Enabling GTests and dual linking libxul

Benoit Gerard and Mike Hommey are working in bug 844288 to dual link libxul so GTests can eventually be enabled and executed as part of our automation.

This will regress build times since we need to link libxul twice. But, giving C++ developers the ability to write unit tests with a real testing framework is worth it, in my opinion.

ICU landing

ICU was briefly enabled in bug 853301 but then backed out because it broke cross-compiling. It should be on track for enabling in Firefox 24.

Resource monitoring in mozbase

I gave mozbase a class to record system resource usage. I plan to eventually hook this up to the build system so the build system records how long it took to perform key events. This will give us better insight into slow and inefficient parts of the build and will help us track build system speed improvements over time.

Sorted lists in moz.build files

I'm working on requiring lists in moz.build be sorted. Work is happening in bug 863069.

This idea started as a suggestion on the dev-platform list. If anyone has more great ideas, don't hold them back!

Smartmake added to mach

Nicholas Alexander taught mach how to build intelligently by importing some of Josh Matthews' smartmake tool's functionality into the tree.

Source server fixed

Kyle Huey and Ted Mielczarek collaborated to fix the source server.

Auto clobber functionality

Auto clobber functionality was added to the tree. After flirting briefly with on-by-default, we changed it to opt-in. When you encounter it, it will tell you how to enable it.

Faster clobbers on automation

I was looking at build logs and identified we were inefficiently performing clobber.

Massimo Gervasini and Chris AtLee deployed changes to automation to make it more efficient. My measurements showed a Windows try build that took 15 fewer minutes to start - a huge improvement.

Upgrading to Mercurial 2.5.4

RelEng is tracking the global deployment of Mercurial 2.5.4. hg.mozilla.org is currently running 2.0.2 and automation is all over the map. The upgrade should make Mercurial operations faster and more robust across the board.

I'm considering adding code to mach or the build system that prompts the user when her Mercurial is out of date (since an out of date Mercurial can result in a sub-par user experience).

Parallelize reftests

Nathan Froyd is leading an effort to parallelize reftest execution. If he pulls this off, it could shave hours off of the total automation load per checkin. Go Nathan!

Overhaul of MozillaBuild in the works

I am mentoring a pair of interns this summer. I'm still working out the final set of goals, but I'm keen to have one of them overhaul the MozillaBuild Windows development environment. Cross your fingers.