I'm announcing a new library for procedural macro authors: proc-macro-rules (and on crates.io). It allows you to do macro_rules-like pattern matching inside a procedural macro. The goal is to smooth the transition from declarative to procedural macros (this works pretty well when used with the quote crate).
(This is part of my Christmas yak mega-shave. That might someday get a blog post of its own, but I only managed to shave about 1/3 of my yaks, so it might take till next Christmas).
Here's an example,
rules!(tokens => {
($finish:ident ($($found:ident)*) # [ $($inner:tt)* ] $($rest:tt)*) => {
for f in found {
do_something(finish, f, inner, rest[0]);
}
}
(foo $($bar:expr)?) => {
match bar {
Some(e) => foo_with_expr(e),
None => foo_no_expr(),
}
}
});
The example is kind of nonsense. The interesting thing is that the syntax is very similar to macro_rules macros. The patterns which are matched are exactly the same as in macro_rules (modulo bugs, of course). Metavariables in the pattern (e.g., $finish or $found in the first arm) are bound to fresh variables in the arm's body (e.g., finish and found). The types reflect the type of the metavariable (for example, $finish has type syn::Ident). Because $found occurs inside a $(...)*, it is matched multiple times and so has type Vec.
The syntax is:
rules!( $tokens:expr => { $($arm)* })
where $tokens evaluates to a TokenStream and the syntax of an $arm is given by
($pattern) => { $body }
or
($pattern) => $body,
where $pattern is a valid macro_rules pattern (which is not yet verified by the library, but should be) and $body is Rust code (i.e., an expression or block.
The intent of this library is to make it easier to write the 'frontend' of a procedural macro, i.e., to make parsing the input a bit easier. In particular to make it easy to convert a macro_rules macro to a procedural macro and replace a small part with some procedural code, without having to roll off the 'procedural cliff' and rewrite the whole macro.
As an example of converting macros, here is a declarative macro which is sort-of like the vec macro (example usage: let v = vec![a, b, c]):
macro_rules! vec {
() => {
Vec::new()
};
( $( $x:expr ),+ ) => {
{
let mut temp_vec = Vec::new();
$(
temp_vec.push($x);
)*
temp_vec
}
};
}
Converting to a procedural macro becomes a mechanical conversion:
use quote::quote;
use proc_macro::TokenStream;
use proc_macro_rules::rules;
#[proc_macro]
pub fn vec(input: TokenStream) -> TokenStream {
rules!(input.into() => {
() => { quote! {
Vec::new()
}}
( $( $x:expr ),+ ) => { quote! {
let mut temp_vec = Vec::new();
#(
temp_vec.push(#x);
)*
temp_vec
}}
}).into()
}
Note that we are using the quote crate to write the bodies of the match arms. That crate allows writing the output of a procedural macro in a similar way to a declarative macro by using quasi-quoting.
How it works
I'm going to dive in a little bit to the implementation because I think it is interesting. You don't need to know this to use proc-macro-rules, and if you only want to do that, then you can stop reading now.
rules is a procedural macro, using syn for parsing, and quote for code generation. The high-level flow is that we parse all code passed to the macro into an AST, then handle each rule in turn (generating a big if/else). For each rule, we make a pass over the rule to
We all want to build the next (or perhaps the first) great Augmented Reality app. But there be dragons! The space is new and not well defined. There aren’t any AR apps that people use every day to serve as starting points or examples. Your new ideas have to compete against an already very high quality bar of traditional 2d apps. And building a new app can be expensive, especially for native app environments. This makes AR apps still somewhat uncharted territory, requiring a higher initial investment of time, talent and treasure.
But this also creates a sense of opportunity; a chance to participate early before the space is fully saturated.
From our point of view the questions are: What kinds of tools do artists, developers, designers, entrepreneurs and creatives of all flavors need to be able to easily make augmented reality experiences? What kinds of apps can people build with tools we provide?
For example: Can I watch Trevor Noah on the Daily Show this evening, and then release an app tomorrow that is a riff on a joke he made the previous night? A measure of success is being able to speak in rich media quickly and easily, to be a timely part of a global conversation.
With Blair MacIntyre‘s help I wrote an experiment to play-test a variety of ideas exploring these questions. In this comprehensive post-mortem I’ll review the app we made, what we learned and where we’re going next.
Finding “good” use cases
To answer some of the above questions, we started out surveying AR and VR developers, asking them their thoughts and observations. We had some rules of thumb. What we looked for were AR use cases that people value, that are meaningful enough, useful enough, make enough of a difference, that they might possibly become a part of people’s lives.
Existing AR apps also provided inspiration. One simple AR app I like for example is AirMeasure, which is part of a family of similar apps such as the Augmented Reality Measuring Tape. I use it once or twice a month and while not often, it’s incredibly handy. It’s an app with real utility and has 6500 reviews on the App Store – so there’s clearly some appetite already.
Sean White, Mozilla’s Chief R&D Officer, has a very specific definition for an MVP (minimum viable product). He asks: What would 100 people use every day?
When I hear this, I hear something like: What kind of experience is complete, compelling, and useful enough, that even in an earliest incarnation it captures a core essential quality that makes it actually useful for 100 real world people, with real world concerns, to use daily even with current limitations? Shipping can be hard, and finding those first users harder.
Browser-based AR
New Pixel phones, iPhones and other emerging devices such as the Magic Leap already support Augmented Reality. They report where the ground is, where walls are, and other kinds of environment sensing questions critical for AR. They support pass-through vision and 3d tracking and registration. Emerging standards, notably WebXR, will soon expose these powers to the browser in a standards- based way, much like the way other hardware features are built and made available in the browser.
Native app development toolchains are excellent but there is friction. It can be challenging to jump through the hoops required to release a product across several different app stores or platforms. Costs that are reasonable for a AAA title may not be reasonable for a smaller project. If you want to knock out an app tonight for a client tomorrow, or post an app as a response to an article in the press or a current event— it can take too long.
With AR support coming to the browser there’s an option now to focus on telling the story rather than worrying about the technology, costs and distribution. Browsers historically offer lower barriers to entry, and instant deployment to millions of users, unrestricted distribution and a sharing culture. Being able to distribute an app at the click of a link, with no install, lowers the activation costs and enables virality. This complements
For the last three years Firefox has invested heavily in innovation, and our users have been an essential part of this journey. Through the Test Pilot Program, Firefox users have been able to help us test and evaluate a variety of potential Firefox features. Building on the success of this program, we’re proud to announce today that we’re evolving our approach to experimentation even further.
Lessons Learned from Test Pilot
Test Pilot was designed to harness the energy of our most passionate users. We gave them early prototypes and product explorations that weren’t ready for wide release. In return, they gave us feedback and patience as these projects evolved into the highly polished features within our products today. Through this program we have been able to iterate quickly, try daring new things, and build products that our users have been excited to embrace.
Graduated Features
Since the beginning of the Test Pilot program, we’ve built or helped build a number of popular Firefox features. Activity Stream, which now features prominently on the Firefox homepage, was in the first round of Test Pilot experiments. Activity Stream brought new life to an otherwise barren page and made it easier to recall and discover new content on the web. The Test Pilot team continued to draw the attention of the press and users alike with experiments like Containers that paved the way for our highly successful Facebook Container. Send made private, encrypted, file sharing as easy as clicking a button. Lockbox helped you take your Firefox passwords to iOS devices (and soon to Android). Page Shot started as a simple way to capture and share screenshots in Firefox. We shipped the feature now known as Screenshots and have since added our new approach to anti-tracking that first gained traction as a Test Pilot experiment.
So what’s next?
Test Pilot performed better than we could have ever imagined. As a result of this program we’re now in a stronger position where we are using the knowledge that we gained from small groups, evangelizing the benefits of rapid iteration, taking bold (but safe) risks, and putting the user front and center.
We’re applying these valuable lessons not only to continued product innovation, but also to how we test and ideate across the Firefox organization. So today, we are announcing that we will be moving to a new structure that will demonstrate our ability to innovate in exciting ways and as a result we are closing the Test Pilot program as we’ve known it.
More user input, more testing
Migrating to a new model doesn’t mean we’re doing fewer experiments. In fact, we’ll be doing even more! The innovation processes that led to products like Firefox Monitor are no longer the responsibility of a handful of individuals but rather the entire organization. Everyone is responsible for maintaining the Culture of Experimentation Firefox has developed through this process. These techniques and tools have become a part of our very DNA and identity. That is something to celebrate. As such, we won’t be uninstalling any experiments you’re using today, in fact, many of the Test Pilot experiments and features will find their way to Addons.Mozilla.Org, while others like Send and Lockbox will continue to take in more input from you as they evolve into stand alone products.
We couldn’t do it without you
We want to thank Firefox users for their input and support of product features and functionality testing through the Test Pilot Program. We look forward to continuing to work closely with our users who are the reason we build Firefox in the first place. In the coming months look out for news on how you can get involved in the next stage of our experimentation.
In the meantime, the Firefox team will continue to
With Firefox 67 you’ll be able to run different Firefox installs side by side by default.
Supporting profiles per installation is a feature that has been requested by pre-release users for a long time now and we’re pleased to announce that starting with Firefox 67 users will be able to run different installs of Firefox side by side without needing to manage profiles.
What are profiles?
Firefox saves information such as bookmarks, passwords and user preferences in a set of files called your profile. This profile is stored in a location separate from the Firefox program files.
More details on profiles are can be found here.
What changes are we making to profiles in Firefox 67?
Previously, all Firefox versions shared a single profile by default. With Firefox 67, Firefox will begin using a dedicated profile for each Firefox version (including Nightly, Beta, Developer Edition, and ESR). This will make Firefox more stable when switching between versions on the same computer and will also allow you to run different Firefox installations at the same time:
- You have not lost any personal data or customizations. Any previous profile data is saved and associated with the first Firefox installation that was opened after this change.
- Starting with Firefox 67, Firefox installations will now have separate profiles. This will apply to Nightly 67 initially and then to all versions of release 67 and above as the change makes it way to Developer Edition, Beta, Firefox, and ESR.
What are my options?
If you do nothing, your profile data will be different on each version of Firefox.
If you would like the information you save to Firefox to be the same on all versions, you can use a Firefox Account to keep them in sync.
Sync is the easiest way to make your profiles consistent on all of your versions of Firefox. You also get additional benefits like sending tabs and secure password storage. Get started with Sync here.
You will not lose any personal data or customizations. Any previous profile data is safe and attached to the first Firefox installation that was opened after this change.
Users of only one Firefox install or users of multiple Firefox installs who already had set different profiles for different installations will not notice the change
We really hope that this change will make it simpler for Firefox users to start running Nightly. If you come across a bug or have any suggestions we really welcome your input through our support channels.
What if I already use separate profiles for my different Firefox installations?
Users who already have created manually separate profile for different installations will not notice the change (this has been the advised procedure on Nightly for a while).
https://blog.nightly.mozilla.org/2019/01/14/moving-to-a-profile-per-install-architecture/
TenFourFox Feature Parity 12 beta 1 is now available (downloads, hashes, release notes). As before, this is a smaller-scope release with no new features, just fixes and improvements. The big changes are a fix for CVE-2018-12404, a holdover security fix from FPR11 that also helps improve JavaScript optimization, and Raphael's hand-coded assembly language AltiVec-accelerated string matching routines with special enhancements for G5 systems. These replace the C routines I wrote using AltiVec intrinsics, which will be removed from our hacked NSPR libc source code once his versions stick.
Unfortunately, we continue to accumulate difficult-to-solve JavaScript bugs. The newest one is issue 541, which affects Github most severely and is hampering my ability to use the G5 to work in the interface. This one could be temporarily repaired with some ugly hacks and I'm planning to look into that for FPR13, but I don't have this proposed fix in FPR12 since it could cause parser regressions and more testing is definitely required. However, the definitive fix is the same one needed for the frustrating issue 533, i.e., the new frontend bindings introduced with Firefox 51. I don't know if I can do that backport (both with respect to the technical issues and the sheer amount of time required) but it's increasingly looking like it's necessary for full functionality and it may be more than I can personally manage.
Meanwhile, FPR12 is scheduled for parallel release with Firefox 60.5/65 on January 29. Report new issues in the comments (as always, please verify the issue doesn't also occur in FPR11 before reporting a new regression, since sites change more than our core does).
http://tenfourfox.blogspot.com/2019/01/tenfourfox-fpr12b1-available.html
In the past three weeks, we merged 72 PRs in the Servo organization’s repositories.
Congratulations to dlrobertson for their new reviewer status for the ipc-channel library!
Planning and Status
Our roadmap is available online. Plans for 2019 will be published soon.
This week’s status updates are here.
Exciting works in progress
- Maharsh is adding preliminary support for the OffscreenCanvas API.
- jdm is fixing the bug preventing Google from loading.
- sreeise is adding the DOM APIs for manipulating audio and video tracks.
Notable Additions
- nox improved the web compatibility of the MIME type parser.
- Manishearth removed some blocking behaviour from the WebXR implementation.
- Collares implemented the
ChannelSplitterNodeWebAudio API. - makepost added musl support to the ipc-channel crate.
- aditj implemented several missing APIs for the resource timing standard.
- dlrobertson exposed the
HTMLTrackElementAPI. - ferjm added support for backoff to the media playback implementation.
- jdm implemented the missing
sourceAPI for message events. - ferjm improved the compatibility of the media playback DOM integration.
- germangc implemented missing DOM APIs for looping and terminating media playback.
New Contributors
Interested in helping build a web browser? Take a look at our curated list of issues that are good for new contributors!
The new Flexbox Inspector, created by Firefox DevTools, helps developers understand the sizing, positioning, and nesting of Flexbox elements. You can try it out now in Firefox DevEdition or join us for its official launch in Firefox 65 on January 29th.
The UX challenges of this tool have been both frustrating and a lot of fun for our team. Built on the basic concepts of the CSS Grid Inspector, we sought to expand on the possibilities of what a design tool could be. I’m excited to share a behind-the-scenes look at the UX patterns and processes that drove our design forward.
Research and ideation
CSS Flexbox is an increasingly popular layout model that helps in building robust dynamic page layouts. However, it has a big learning curve—at the beginning of this project, our team wasn’t sure if we understood Flexbox ourselves, and we didn’t know what the main challenges were. So, we gathered data to help us design the basic feature set.
Our earliest research on design-focused tools included interviews with developer/designer friends and community members who told us they wanted to understand Flexbox better.
We also ran a survey to rank the Flexbox features folks most wanted to see. Min/max width and height constraints received the highest score. The ranking of shrink/grow features was also higher than we expected. This greatly influenced our plans, as we had originally assumed these more complicated features could wait for a version 2.0. It was clear however that these were the details developers needed most.
Most of the early design work took the form of spirited brainstorming sessions in video chat, text chat, and email. We also consulted the experts: Daniel Holbert, our Gecko engine developer who implemented the Flexbox spec for Firefox; Dave Geddes, CSS educator and creator of the Flexbox Zombies course; and Jen Simmons, web standards champion and designer of the Grid Inspector.
The discussions with friendly and passionate colleagues were among the best parts of working on this project. We were able to deep-dive into the meaty questions, the nitty-gritty details, and the far-flung ideas about what could be possible. As a designer, it is amazing to work with developers and product managers who care so much about the design process and have so many great UX ideas.
Visualizing a new layout model
After our info-gathering, we worked to build our own mental models of Flexbox.
While trying to learn Flexbox myself, I drew diagrams that show its different features.
My colleague Gabriel created a working prototype of a Flexbox highlighter that greatly influenced our first launch version of the overlay. It’s a monochrome design similar to our Grid Inspector overlay, with a customizable highlight color to make it clearly visible on any website.
We use a dotted outline for the container, solid outlines for items, and diagonal shading between the items to represent the free space created by justify-content and
Bonsoir! Another week, another newsletter. I stealthily published WebRender on crates.io this week. This doesn’t mean anything in terms of API stability and whatnot, but it makes it easier for people to use WebRender in their own rust projects. Many asked for it so there it is. Everyone is welcome to use it, find bugs, report them, submit fixes and improvements even!
In other news we are initiating a notable workflow change: WebRender patches will land directly in Firefox’s mozilla-central repository and a bot will automatically mirror them on github. This change mostly affects the gfx team. What it means for us is that testing webrender changes becomes a lot easier as we don’t have to manually import every single work in progress commit to test it against Firefox’s CI anymore. Also Kats won’t have to spend a considerable amount of his time porting WebRender changes to mozilla-central anymore.
We know that interacting with mozilla-central can be intimidating for external contributors so we’ll still accept pull requests on the github repository although instead of merging them from there, someone in the gfx team will import them in mozilla-central manually (which we already had to do for non-trivial patches to run them against CI before merging). So for anyone who doesn’t work everyday on WebRender this workflow change is pretty much cosmetic. You are still welcome to keep following and interacting with the github repository.
Notable WebRender and Gecko changes
- Jeff fixed a recent regression that was causing blob images to be painted twice.
- Kats the work to make the repository transition possible without losing any of the tools and testing we have in WebRender. He also set up the repository synchronization.
- Kvark completed the clipping API saga.
- Matt added some new telemetry for paint times, that take vsync into account.
- Matt fixed a bug with a telemetry probe that was mixing content and UI paint times.
- Andrew fixed an image flickering issue.
- Andrew fixed a bug with image decode size and pixel snapping.
- Lee fixed a crash in DWrite font rasterization.
- Lee fixed a bug related to transforms and clips.
- Emilio fixed a bug with clip path and nested clips.
- Glenn fixed caching fixed position clips.
- Glenn improved the cached tile eviction heuristics (2).
- Glenn fixed an intermittent test failure.
- Glenn fixed caching with opacity bindings that are values.
- Glenn avoided caching tiles that always change.
- Glenn fixed a cache eviction issue.
- Glenn added a debugging overlay for picture caching.
- Nical reduced the overdraw when rendering dashed corners, which was causing freezes in extreme cases.
- Nical added the possibility to run wrench/scripts/headless.py (which lets us run CI under os-mesa) inside gdb, cgdb, rust-gdb and rr both with release and debug builds (see Debugging WebRender on wiki for more info about how to set this up).
- Nical fixed a blob image key leak.
- Sotaro fixed the timing of async animation deletion which addressed bug 1497852 and bug 1505363.
- Sotaro
The Levchin Prize awards two entrepreneurs every year for significant contributions to solving global, real-world cryptography issues that make the internet safer at scale. This year, we’re proud to announce that our very own Firefox CTO, Eric Rescorla, was awarded one of these prizes for his involvement in spearheading the latest version of Transport Layer Security (TLS). TLS 1.3 incorporates significant improvements in both security and speed, and was completed in August and already secures 10% of sites.
Eric has contributed extensively to many of the core security protocols used in the internet, including TLS, DTLS, WebRTC, ACME, and the in development IETF QUIC protocol. Most recently, he was editor of TLS 1.3, which already secures 10% of websites despite having been finished for less than six months. He also co-founded Let’s Encrypt, a free and automated certificate authority that now issues more than a million certificates a day, in order to remove barriers to online encryption and helped HTTPS grow from around 30% of the web to around 75%. Previously, he served on the California Secretary of State’s Top To Bottom Review where he was part of a team that found severe vulnerabilities in multiple electronic voting devices.
The 2019 winners were selected by the Real-World Cryptography conference steering committee, which includes professors from Stanford University, University of Edinburgh, Microsoft Research, Royal Holloway University of London, Cornell Tech, University of Florida, University of Bristol, and NEC Research.
This prize was announced on January 9th at the 2019 Real-World Crypto Conference in San Jose, California. The conference brings together cryptography researchers and developers who are implementing cryptography on the internet, the cloud and embedded devices from around the world. The conference is organized by the International Association of Cryptologic Research (IACR) to strengthen and advance the conversation between these two communities.
For more information about the Levchin Prize visit www.levchinprize.com.
The post Eric Rescorla Wins the Levchin Prize at the 2019 Real-World Crypto Conference appeared first on The Mozilla Blog.
Last week Mozilla sent a letter to the House Energy and Commerce Committee concerning its investigation into Facebook’s privacy practices. We believe Facebook’s representations to the Committee — and more recently — concerning Mozilla are inaccurate and wanted to set the record straight about any past and current work with Facebook. You can read the full letter here.
The post Our Letter to Congress About Facebook Data Sharing appeared first on Open Policy & Advocacy.
https://blog.mozilla.org/netpolicy/2019/01/08/our-letter-to-congress-about-facebook/
Last year, Mozilla set out to build a best-in-class browser that was made specifically for immersive browsing. The result was Firefox Reality, a browser designed from the ground up to work on virtual reality headsets. To kick off 2019, we are happy to announce that we are partnering with HTC VIVE to power immersive web experiences across Vive’s portfolio of devices.
What does this mean? It means that Vive users will enjoy all of the benefits of Firefox Reality (such as its speed, power, and privacy features) every time they open the Vive internet browser. We are also excited to bring our feed of immersive web experiences to every Vive user. There are so many amazing creators out there, and we are continually impressed by what they are building.
“This year, Vive has set out to bring everyday computing tasks into VR for the first time,” said Michael Almeraris, Vice President, HTC Vive. “Through our exciting and innovative collaboration with Mozilla, we’re closing the gap in XR computing, empowering Vive users to get more content in their headset, while enabling developers to quickly create content for consumers.”
Virtual reality is one example of how web browsing is evolving beyond our desktop and mobile screens. Here at Mozilla, we are working hard to ensure these new platforms can deliver browsing experiences that provide users with the level of privacy, ease-of-use, and control that they have come to expect from Firefox.
In the few months since we released Firefox Reality, we have already released several new features and improvements based on the feedback we’ve received from our users and content creators. In 2019, you will see us continue to prove our commitment to this product and our users with every update we provide.
Stay tuned to our mixed reality blog and twitter account for more details. In the meantime, you can check out all of the announcements from HTC Vive here.
If you have an all-in-one VR device running Vive Wave, you can search for “Firefox Reality” in the Viveport store to try it out right now.
The post Mozilla Announces Deal to Bring Firefox Reality to HTC VIVE Devices appeared first on The Mozilla Blog.
Over the past few months I’ve been building VR demos and writing tutorial blogs. Navigation on a device with only three degrees of freedom (3dof) is tricky, So I decided to do a survey of many native apps and games for the Oculus Go to see how each of them handled it. Below are my results.
For this study I looked only at navigation, meaning how the user moves around in the space, either by directly moving or by jumping to semantically different spaces (ex: click a door to go to the next room). I don't cover other interactions like how buttons or sliders work. Just navigation.
TL;DR
Don’t touch the camera. The camera is part of the users head. Don’t try to move it. All apps which move the camera induce some form of motion sickness. Instead use one of a few different forms of teleportation, always under user control.
The ideal control for me was teleportation to semantically meaningful locations, not just 'forward ten steps'. Further more, when presenting the user with a full 360 environment it is helpful to have a way to recenter the view, such as by using left/right buttons on the controller. Without a recentering option the user will have to physically turn themselves around, which is cumbersome unless you are in a swivel chair.
To help complete the illusion I suggest subtle sound effects for movement, selection, and recentering. Just make sure they aren't very noticable.
Epic Roller Coaster
This is a roller coaster simulator, except it lets you do things that a real rollercoaster can’t, such as jumping between tracks and being chased by dinosaurs. To start you have pointer interaction across three panels: left, center, right. Everything has hover/rollover effects with sound. During the actual rollercoaster ride you are literally a camera on rails. Press the trigger to start and then the camera moves at constant speed. All you can do is look around. Speed and angle changes made me dizzy and I had to take it off after about five minutes, but my 7 year old loves Epic Roller Coaster.
Space Time
A PBS app that teaches you about black holes, the speed of light, and other physics concepts. You use pointer interaction to click buttons then watch non-interactive 3D scenes/info, though they are in full 360 3D, rather than plain movies.
Within Videos
A collection of many 360 and 3D movies. Pointer interaction to pick videos, some scrolling w/ touch gestures. Then non-interactive videos except for the video controls.
Master Work Journeys
Explorer famous monuments and locations like Mount Rushmore. You can navigate around 360 videos by clicking on hotspots with the pointer. Some trigger photos or audio. Others are teleportation spots. There is no free navigation or free teleportation, only to the hotspots. You can adjust the camera with left and right swipes, though.
Thumper
An intense driving and tilting music game. It uses pointer control for menus. In the game you run at a constant speed. The track itself turns but you are always stable in the middle. Particle effects stream at you, reinforcing the illusion of the tube you are in.
Bait
A fishing simulator. You use pointer clicks for navigation in the menus. The main interaction is a fishing pole. Hold then release button at the right time while flicking the pole forward to cast, then click to reel it back in.
Dinosaurs
Basically like the rollercoaster game, but you learn about various dinosaurs by driving on a constant speed rails car to different scenes. It felt better to me than Epic Roller Coaster because the velocity is constant, rather than changing.
Breaking Boundaries in Science
Text overlays with audio and 360 background image. You can navigate through full 3D space by jumping to hard coded teleport spots. You can click certain spots to get to these points, hear audio, and lightly interact with artifacts. If you look up at an angle you see a flip-180 button to change the view. This avoids the problem of having to be in a 360 chair to navigate around. You cannot camera adjust with left/right swipes.
WonderGlade
In every scene you float over a static mini-landscape, sort of like you are above a game board. You cannot adjust the angle or camera, just move your head to see stuff. Everything laid around you for easy viewing from the fixed camera point. Individual mini games may use different mechanics for playing, but they are all using the same camera. Essentially the camera and world never move. You can navigate your player character around the board by clicking on spots, similar to an RTS like Starcraft.
Starchart
Menus are a static camera view with mouse interaction. Once inside of a
Hello Mozillians,
We are happy to let you know that Friday, January 11th, we are organizing Firefox 65 Beta 10 Testday. We’ll be focusing our testing on: Firefox Monitor, Content Blocking and Find Toolbar.
Check out the detailed instructions via this etherpad.
No previous testing experience is required, so feel free to join us on #qa IRC channel where our moderators will offer you guidance and answer your questions.
Join us and help us make Firefox better!
See you on Friday!
https://quality.mozilla.org/2019/01/firefox-65-beta-10-testday-january-11th/
After almost seven and a half years as an employee of Mozilla Corporation, I'm moving on. I have already worked my final day as an employee.
This post is the first time that I've publicly acknowledged my departure. To any Mozillians reading this, I regret that I did not send out a farewell email before I left. But the circumstances of my departure weren't conducive to doing so. I've been drafting a proper farewell blog post. But it has been very challenging to compose. Furthermore, each passing day brings with it new insights into my time at Mozilla and a new wrinkle to integrate into the reflective story I want to tell in that post. I vow to eventually publish a proper goodbye that serves as the bookend to my employment at Mozilla. Until then, just let me say that I'm already missing working with many of you. I've connected with several people since I left and still owe responses or messages to many more. If you want to get in touch, my contact info is in my r'esum'e.
I left Mozilla without new employment lined up. That leads me to the subject line of this post: I'm seeking employment. The remainder of this post is thus tailored to potential employers.
My r'esum'e has been updated. But that two page summary only scratches the surface of my experience and set of skills. The Body of Work page of my website is a more detailed record of the work I've done. But even it is not complete!
Perusing through my posts on this blog will reveal even more about the work I've done and how I go about it. My r'esum'e links to a few posts that I think are great examples of the level of understanding and detail that I'm capable of harnessing.
As far as the kind of work I want to do or the type of company I want to work for, I'm trying to keep an open mind. But I do have some biases.
I prefer established companies to early start-ups for various reasons. Dan Luu's Big companies v. startups is aligned pretty well with my thinking.
One of the reasons I worked for Mozilla was because of my personal alignment with the Mozilla Manifesto. So I gravitate towards employers that share those principles and am somewhat turned off by those that counteract them. But I recognize that the world is complex and that competing perspectives aren't intrinsically evil. In other words, I try to maintain an open mind.
I'm attracted to employers that align their business with improving the well-being of the planet, especially the people on it. The link between the business and well-being can be tenuous: a B2B business for example is presumably selling something that helps people, and that helping is what matters to me. The tighter the link between the business and improving the world will increase my attraction to a employer.
I started my university education as a biomedical engineer because I liked the idea of being at the intersection of technology and medicine. And part of me really wants to return to this space because there are few things more noble than helping a fellow human being in need.
As for the kind of role or technical work I want to do, I could go in any number of directions. I still enjoy doing individual contributor type work and believe I could be an asset to an employer doing that work. But I also crave working on a team, performing technical mentorship, and being a leader of technical components. I enjoy participating in high-level planning as well as implementing the low-level aspects. I recognize that while my individual output can be substantial (I can provide data showing that I was one of the most prolific technical contributors at Mozilla during my time there) I can be more valuable to an employer when I bestow skills and knowledge unto others through teaching, mentorship, setting an example, etc.
I have what I would consider expertise in a few domains that may be attractive to employers.
I was a technical maintainer of Firefox's build system and initiated a transition away from an architecture that had been in place since the Netscape days. I definitely geek out way too much on build systems.
I am a contributor to the Mercurial version control tool. I know way too much about the internals of Mercurial, Git, and other version control tools. I am intimately aware of scaling problems with these tools. Some of the scaling work I did for Mercurial saved Mozilla tens of thousands of dollars in direct operational costs and probably hundreds of thousands of dollars in saved people time due to fewer service disruptions and faster operations.
I have exposure to both client and server side work and the
What is it?
Everett is a configuration library for Python apps.
Goals of Everett:
- flexible configuration from multiple configured environments
- easy testing with configuration
- easy documentation of configuration for users
From that, Everett has the following features:
- is composeable and flexible
- makes it easier to provide helpful error messages for users trying to configure your software
- supports auto-documentation of configuration with a Sphinx autocomponent directive
- has an API for testing configuration variations in your tests
- can pull configuration from a variety of specified sources (environment, INI files, YAML files, dict, write-your-own)
- supports parsing values (bool, int, lists of things, classes, write-your-own)
- supports key namespaces
- supports component architectures
- works with whatever you're writing--command line tools, web sites, system daemons, etc
v1.0.0 released!
This release fixes many sharp edges, adds a YAML configuration environment, and fixes Everett so that it has no dependencies unless you want to use YAML or INI.
It also drops support for Python 2.7--Everett no longer supports Python 2.
Why you should take a look at Everett
At Mozilla, I'm using Everett for Antenna which is the edge collector for the crash ingestion pipeline for Mozilla products including Firefox and Fennec. It's been in production for a little under a year now and doing super. Using Everett makes it much easier to:
- deal with different configurations between local development and server environments
- test different configuration values
- document configuration options
It's also used in a few other places and I plan to use it for the rest of the components in the crash ingestion pipeline.
First-class docs. First-class configuration error help. First-class testing. This is why I created Everett.
If this sounds useful to you, take it for a spin. It's almost a drop-in replacement for python-decouple and os.environ.get('CONFIGVAR', 'default_value') style of configuration.
Enjoy!
Thank you!
Thank you to Paul Jimenez who helped fixing issues and provided thoughtful insight on API ergonomics!
Where to go for more
For more specifics on this release, see here: https://everett.readthedocs.io/en/latest/history.html#january-7th-2019
Documentation and quickstart here: https://everett.readthedocs.io/en/latest/
Source code and issue tracker here: https://github.com/willkg/everett
To me, 2018 felt like a big turning point for Rust, and it wasn’t just the edition. Suddenly, it has become “normal” for me to meet people using Rust at their jobs. Rust conferences are growing and starting to have large number of sponsors. Heck, I even met some professional Rust developers amongst the parents at a kid’s birthday party recently. Something has shifted, and I like it.
At the same time, I’ve also noticed a lot of exhaustion. I know I feel it – and a lot of people I talk to seem to feel the same way. It’s great that so much is going on in the Rust world, but we need to get better at scaling our processes up and processing it effectively.
When I think about a “theme” for 2019, the word that keeps coming to mind for me is sustainability. I think Rust has been moving at a breakneck pace since 1.0, and that’s been great: it’s what Rust needed. But as Rust gains more solid footing out there, it’s a good idea for us to start looking for how we can go back and tend to the structures we’ve built.
Sustainable processes
There has been a lot of great constructive criticism of our current processes: most recently, boat’s post on organizational debt, along with Florian’s series of posts, did a great job of crystallizing a lot of the challenges we face. I am pretty confident that we can adjust our processes here and make things a lot better, though obviously some of these problems have no easy solution.
Obviously, I don’t know exactly what we should do here. But I think I see some of the pieces of the puzzle. Here is a variety of bullet points that have been kicking around in my head.
Working groups. In general, I would like to see us adopting the idea of working groups as a core “organizational unit” for Rust, and in particular as the core place where work gets done. A working group is an ad-hoc set of people that includes both members of the relevant Rust team but also interested volunteers. Among other benefits, they can be a great vehicle for mentoring, since it gives people a particular area to focus on, versus trying to participate in the Rust project as a whole, which can be very overwhelming.
Explicit stages. Right now, Rust features go through a number of official and semi-official stages before they become “stable”. As I have argued before, I think we would benefit from making these stages a more explicit part of the process (much as e.g. the TC39 and WebAssembly groups already do).
Finishing what we start. Right now, we have no mechanism to expose the “capacity” of our teams – we tend to, for example, accept RFCs without any idea who will implement it, or even mentor an implementation. In fact, there isn’t really a defined set of people to try and ensure that it happens. The result is that a lot of things linger in limbo, either unimplemented, undocumented, or unstabilized. I think working groups can help to solve this, by having a core leadership team that is committed to seeing the feature through.
Expose capacity. Continuing the previous point, I think we should integrate a notion of capacity into the staging process: so that we avoid moving too far in the design until we have some idea who is going to be implementing (or mentoring an implementation). If that is hard to do, then it indicates we may not have the capacity to do this idea right now – if that seems unacceptable, then we need to find something else to stop doing.
Don’t fly solo. One of the things that we discussed in a recent compiler team steering meeting is that being the leader of a working group is super stressful – it’s a lot to manage! However, being a co-leader of a working group is very different. Having someone else (or multiple someones) that you can share work with, bounce ideas off of, and so forth makes all the difference. It’s also a great mentoring opportunities, as the leaders of working groups don’t necessarily have to be full members of the team (yet). Part of exposing capacity, then, is trying to ensure that we don’t just have one person doing any one thing – we have multiple. This is scary: we will get less done. But we will all be happier doing it.
Evaluate priorities regularly. In
In the past three weeks, we merged 130 PRs in the Servo organization’s repositories.
Congratulations to Ygg01 for their new reviewer status for the html5ever repository!
Planning and Status
Our roadmap is available online. Plans for 2019 will be published soon.
This week’s status updates are here.
Exciting works in progress
- mandreyel is adding support for parallel CSS parsing.
- cbrewster is adding profiling support for WebGL APIs.
- jdm is synchronizing WebGL rendering with WebRender’s GL requirements.
Notable Additions
- gterzian replaced some synchronous communication with the embedder.
- eijebong implemented support for the
onceargument foraddEventListener. - Darkspirit slimmed down the list of supported TLS ciphers.
- jdm fixed a web incompatibility preventing the DuckDuckGo search from loading.
- oOIgnitionOo made it easier to run historical nightlies from the command line.
- jdm fixed a bug preventing iframes from being sized correctly initially.
- cdeler enabled the WebBluetooth tests from upstream.
- paulrouget split the
simpleservoembedding crate into crates for Rust, Java, and C. - georgeroman added support for the
playbackRatemedia API. - denixmerigoux avoided an assertion failure in the text editing implementation.
- SimonSapin converted the first macOS CI builder to run in Taskcluster.
- emilio consolidated the style thread pools into a single per-process threadpool.
- asajeffrey implemented keyboard support for Magic Leap devices.
- ferjm implemented backoff support for media playaback.
- Manishearth implemented support for WebXR controller input.
- cybai ensured that constructing URLs removes question mark characters appropriately.
- Manishearth made safe
Rcvalues not be reported as unrooted by the rooting static analysis.
New Contributors
Interested in helping build a web browser? Take a look at our curated list of issues that are good for new contributors!
As I sit here quietly in the dawn of 2019, I feel deep gratitude for the year that has just passed — and tremendous hope for the year ahead. My hope is for a year where I raise my sights, to notice things more and see what can blossom from seeds I have sown over the past few years.
At the beginning of last year, I set the intention to ‘stay the course’ on big changes that I had made in both my personal life and at Mozilla. This has paid off. I have a house of my own that I have slowly, and with the help of others, turned into a home. I have a renewed sense of family and community, including a much richer relationship with my boys. And, I have energy, hope and gratitude for Mozilla and the people I work with that is stronger than it has been in years. Being present and staying the course on a good set of choices, made these things possible.
Looking ahead, it would be easy to say ‘I should just stay the course on staying the course’. In some ways, that is what I will do. Yet, I also want to look at things from a slightly different angle as I proceed.
My intention for 2019 is to ‘raise my sights’ — to look out further as I walk. In doing so, I hope to observe things I otherwise couldn’t see. And, to respond to these observations in a way that will slowly, subtly elevate and unlock more joy and love and impact. My intention is to go slow, look ahead and act boldly as I continue along the path I have carved over the past few years.
Oddly, I landed on this intention in part by reading about wine. In particular, I came across a term that I had never heard before: 'elevage, the care and work put in after fermentation to bring out quality and make a wine ready to drink. This may sound like a corny or even pretentious source for a yearly intention — but I found a great deal in the idea of 'elevage as I reflected on it.
Growing and crushing grapes is what most often comes to mind when we think of ‘making great wine’. Of course, this process of creative destruction is at the core of wine making. A great deal of energy is applied, intensely and with intention. That intensity and intention have a huge impact on what the wine becomes. In that way, it is much like starting a new project or making big changes in your life.
There is another part of winemaking that is almost as impactful, yet often under appreciated. This is the process of 'elevage: looking after that wine after you have ‘made’ it and before you lock it into a bottle for ageing and drinking. It is in the process of listening to the wine as it begins to take shape, raising it up and helping it mature in slow and subtle ways. Deciding on wood or steel or clay. Topping up the barrel. Or, not. Blending. This phase is critical in shaping what the wine does or doesn’t become — and yet it can only happen in its own time, in a very slow dance of listening and acting and listening again. This is a dance that we often forget when making changes to our lives and our organizations.
It was with this reflection that I landed on the idea of ‘raising my sights’ — and elevating what is possible — as my intention for 2019. I have put a great deal of energy and intention into the last few years, and I am seeing the results in my home life, my personal life and my work life. It has been a period of creative destruction. In so many ways, I am happy with what has been created. Yet, there is still much more to strive for and explore and enjoy on this path.
Now feels like the time to at once look up and slow down. Whether in small or big ways, I am hopeful that there are great things on the path ahead. The trick will be to notice and embrace and nurture them as they appear.
The post Raising my sights in 2019 appeared first on Mark Surman.
https://marksurman.commons.ca/2019/01/04/raising-my-sights-in-2019/
A month ago, we formally announced that we were working to bring Firefox to ARM64 Windows. The last month has seen significant progress on our journey to that release.
The biggest news is that we have dogfoodable (auto-updating) Nightly builds available! As that message states, these Nightlies are even nightlier than our normal Nightlies, as they have not gone through our normal testing processes. But Firefox is perfectly usable on ARM64 Windows in its present state, so if you have an ARM64 device, please give it a try and file any bugs you find!
Since that announcement, native stack unwinding has been implemented. That in turn means the Gecko Profiler can now capture native (C++/Rust) stack frames, which is an important step towards making the Gecko Profiler functional. We also enabled WebRTC support, even though WebRTC video not working on ARM64 Windows is a known issue.
We’re currently working on porting our top-tier JavaScript JIT (IonMonkey) to ARM64. We’re also working on enabling the crashreporter, which is a pretty important feature for getting bug reports from the field! From my low-level tools perspective, the most interesting bug discovered via dogfooding is a WebRender crash caused by obscure ARM64-specific parameter passing issues in Rust itself.
Ideally, I’ll be writing updates every two weeks or so. If you see something I missed, or want to point out something that should be in the next update, please email me or come find me on IRC.
https://blog.mozilla.org/nfroyd/2019/01/04/arm64-windows-update-1/