Michael Kaply: Domain Specific Flash Enabling on Firefox |
Update: It looks like Flash has been updated to 18.0.0.209, so this workaround shouldn't be needed. Save it for a rainy day (or the next time Firefox blocklists Flash.)
This big news today is that Mozilla blocked version 18.0.0.203 of Flash because of security vulnerabilities. At the time they blocked it, it was the latest version of Flash available. While this might be great for users, there are enterprises that have mission critical apps that require Flash.
Although you can use the various notifications in Firefox to re-enable Flash (it's what Firefox calls a soft block), you might wonder how you can make sure Flash is enabled for the specific domains you need it on regardless of the status of Flash security. You can do that using the Firefox permissions manager.
The easiest way to do this is using the CCK2. When you enable all plugins for a domain on the permissions page, it makes sure that Flash and Java work on that domain even if they are vulnerable.
If you are using AutoConfig, you can add this code to your config file:
Components.utils.import("resource://gre/modules/Services.jsm");
Components.utils.import("resource://gre/modules/NetUtil.jsm");
Services.perms.add(NetUtil.newURI("http://some.domain"), "plugine:flash", 1);
Services.perms.add(NetUtil.newURI("http://some.domain"), "plugin-vulnerable:flash", 1);
This will make sure that flash always works on the given domain. If you want to do this inside of your browser, you can check out the Scratchpad.
Note that for security reasons, you shouldn't enable the vulnerable versions of Flash and Java for any domain that you don't have control over.
https://mike.kaply.com/2015/07/14/domain-specific-flash-enabling-on-firefox/
|
|
Julien Pag`es: mozregression 0.37 release |
Yesterday we just released mozregression (command line regression range finder for Mozilla nightly and inbound builds) 0.37!
This release include some new features and fixes, and uses the new TaskCluster system from Mozilla Release Engineering to retrieve integration branch information. This considerably speeds up the bisection of inbound builds.
https://parkouss.wordpress.com/2015/07/14/mozregression-0-37-release/
|
|
Benjamin Kerensa: Can we kill Adobe Flash? |
Yesterday the usual tech news outlets were buzzing over an accidental tweet which the media incorrectly interpreted as Mozilla was ditching flash (Blame The Verge for the chain reaction of copied news articles) entirely as a policy. While that is not the case, I was just as excited as many at the faux-news. This got me thinking: what would it really take for the web to kill Adobe Flash? Could Mozilla really make such a move and kill Flash on its own if it wanted to?
My thought is that Mozilla could not because users would be upset at the immediate lack of support for flash which is widely used. However, if Mozilla talked to other browsers including the Chrome Team, Opera, Vivaldi, Safari etc and made a coordinated effort to get at least some of the major names to agree on a set date to end their support for flash, say a year or so out, then I think it would be possible for Adobe Flash to die.
But absent the above happening a tweet by Alex Stamos, CSO of Facebook is right and maybe he understated it because it is really past time for Adobe to do the right thing and announce a end-of-life date for Adobe Flash in the next year or two. Such an announcement would give websites a year or two to do the major task of removing flash from millions of sites around the world.
The open web would be a better place without Flash but it would also be a better place without Java (sorry Minecraft fans but that game needs porting to HTML5) and other relics of the early less open web.
If you agree it is time for a open web free of flash then go give Alex Stamos’s tweet a RT and buy him a beer.
http://feedproxy.google.com/~r/BenjaminKerensaDotComMozilla/~3/Ara6LC9FU5s/can-we-kill-adobe-flash
|
|
Mozilla Reps Community: Reps Weekly Call – July 9th 2015 |
Last Thursday we had our weekly call about the Reps program, where we talk about what’s going on in the program and what Reps have been doing during the last week.
Shoutouts to Dian Ina (@alamanda), @Christos, @konstantina, @bobchao, @irvin, @orin, Ernest, Peter Chen (@petercpg), @flore and @qudahmahmood.
Emma introduced the heartbeat process the Participation team is using to move forward.
Usually the process is each 3 weeks and the projects are based on the team quarterly goals, allowing to measure the success in an agile way.
At the end of the 3 weeks cycle demos of the most relevant project are presented.
The process is open to anyone to participate, simply add a comment on the project github issue you are interested in.
Don’t forget to add your event to Discourse, and share some photos, so it can be shared on Reps Twitter account.
Emma needs help turning Marketpulse four week course into a self-study resource, 90% there just need extra set of eyes to figure out what would be most intuitive. If you are interested in curriculum (qa, grammar, organization), please reach out to @emma_irwin or @Ioana.
This is a quick summary on what the Council is working this week.
Questions about what is happening? Ask on discourse or trello.
Mozfest Planning happened in Anstruther Scotland, it was the first of it’s kind because usually Mozfest planning is done remotely between the teams and individuals involved.
They were there to think differently about how we can plan sessions and the experience through Personas and pathways.
Don’t forget to comment about this call on Discourse and we hope to see you next week!
https://blog.mozilla.org/mozillareps/2015/07/14/reps-weekly-call-july-9th-2015/
|
|
Byron Jones: happy bmo push day! |
the following changes have been pushed to bugzilla.mozilla.org:
discuss these changes on mozilla.tools.bmo.
https://globau.wordpress.com/2015/07/14/happy-bmo-push-day-150/
|
|
Will Kahn-Greene: Input: 2015q2 quarter in review |
2015q2 was a bit slower bug-count-wise than 2015q1, but we got some important things accomplished.
Things to know:
This is the quarter in review for Mozilla Input!
Read more… (3 mins to read)
|
|
Mozilla WebDev Community: Extravaganza – July 2015 |
Once a month, web developers from across Mozilla get together to dumpster dive for hardware to add to our in-house cloud computing service. While we argue about the compute power of TI-83s, we find time to talk about the work we’ve shipped, share the libraries we’re working on, meet new folks, and talk about whatever else is on our minds. It’s the Webdev Extravaganza! The meeting is open to the public; you should stop by!
You can check out the wiki page we use to organize the meeting, or view a recording of the meeting in Air Mozilla. Or just read on for a summary!
The shipping celebration is for anything we finished and deployed in the past month, whether it be a brand new site, an upgrade to an existing one, or even a release of a library.
First up was Osmose (that’s me!) with a package for Atom, a text editor made by Github. The package is called atom-dxr-search and lets you perform searches on DXR (Mozilla’s structured code search engine) from directly within your text editor. And, if you have the code tree you’re searching open as a directory in Atom, you can click on the results to open the matching file and jump directly to the line in question!
Next was lonnen, who shared the great news that Socorro, the crash collector service that handles crash reports for Firefox and other products, has successfully migrated off of Mozilla infrastructure and on to AWS. This is the culmination of 2-3 quarters of work by the Socorro team, and will allow the team to scale and deploy much faster than before.
Along with the switch itself, the team set up several new tools to help deploy and monitor the service, including Atlas, which lets the team to audit and test infrastructure changes before they get deployed.
Peterbe launched the New/Upload page on Air Mozilla, which lets users to upload existing videos or record a new video from their webcam. The page makes it much easier to submit content to Air Mozilla, and in the future the page will allow you to record screencasts as well.
ErikRose shared a link to his presentation on the new things coming in the DXR 2.0 update, as well as a link to the post-presentation discussion on what the future roadmap for DXR looks like.
Mythmon has been working on Edwin, which is a small React app that lets you manage the list of bugs to work on for a project. It pulls data from both Bugzilla and GitHub, knows the current review status of a bug, and lets you to sort and prioritize work easily. SUMO and Input are currently using the tool to manage their work, and any projects interested in trying the tool out can contact mythmon to get their project added.
I wrapped things up with the news that Pontoon, a localization service that supports in-page translation for websites, has migrated to Heroku. The jump is the result of work from both myself and mathjazz, the main developer of the site. The migration required upgrading Django from 1.4 to 1.8, replacing Git submodules with a peep-compatible requirements file, replacing jingo with django-jinja, and a slew of other changes generally around removing the last traces of playdoh from the site.
In addition, the Pontoon team is looking to help anyone interested in switching to Pontoon. If you’re not using Pontoon and want to be (and you should), let me know and I’ll be able to help start the process as well as possibly contribute patches to your site to enable in-page localization.
In the end we weren’t able to find enough computers, so we opted to install rootkits on all the company laptops that harvest unused CPU for our cloud.
If you’re interested in web development at Mozilla, or want to attend next month’s Extravaganza, subscribe to the dev-webdev@lists.mozilla.org mailing list to be notified of the next meeting, and maybe send a message introducing yourself. We’d love to meet you!
See you next month!
https://blog.mozilla.org/webdev/2015/07/13/extravaganza-july-2015/
|
|
Air Mozilla: Mozilla Weekly Project Meeting |
The Monday Project Meeting
https://air.mozilla.org/mozilla-weekly-project-meeting-20150713-2/
|
|
About:Community: MDN Contributor of the Month for June 2015: Sebastian Zartner |
Congratulations to Sebastian Zartner, who is the MDN Contributor of the Month for June 2015. Sebastian has contributed a lot to both the content and structure of the CSS reference, including creating a JSON API for CSS pages, and a macro for CSS syntax.
Photo: Sebastian Zartner
Here is an interview with Sebastian, conducted by email:
When and how did you get started contributing to MDN?
My first contributions to MDN were back in 2007, so already some months ago. 
My first contributions were related to German translations to articles, but I also quickly started working on English ones. Some of those contributions were information updates, some of them spelling corrections and I also already started writing a few new articles back then.
How does what you do on MDN affect other parts of your life, and vice versa?
Writing on MDN requires some deeper understanding of web technologies on the one hand, and on the other the writer needs to be able to explain those technologies to other people. So by writing those articles, it helps me to learn about and understand the technologies myself and at the same time it allows me to improve my teaching skills. Having said that, what I’m currently mainly working on and what I was awarded for is more background and cleaning up work.
What advice do you have for new contributors on MDN?
New contributors to MDN should start by doing small changes to or translating existing articles. If they need help, there is already a lot of information on MDN explaining what to do. And if they prefer to ask someone, there’s always a helping hand [via email and IRC].
|
|
QMO: Firefox 40 Beta 3 Testday Results |
Hello Mozillians!
As you may already know, last Friday – July 10th – we held a new Testday event, for Firefox 40 Beta 3.
We’d like to take this opportunity to thank everyone for getting involved in the proposed testing activities and in general, for helping us make Firefox better.
Many thanks go out to the Bangladesh QA Community, for testing YouTube and Firefox Hello and also verifying lots of bug fixes: Nazir Ahmed Sabbir, Rezaul Huque Nayeem, Md. Rahimul Islam, Hossain Al Ikram, Khalid Syfullah Zaman, Towkir Ahmed, Sayed Mohammad Amir, Forhad Hossain, Saheda Reza Antora, Ashickur Rahman, Kazi Nuzhat Tasnem, Md. Ehsanul Hassan, Muktasib Un Nur, and Mohammad Maruf Islam. Also a big thank you goes to all our moderators.
Keep an eye on QMO for upcoming events! 
https://quality.mozilla.org/2015/07/firefox-40-beta-3-testday-results/
|
|
Christian Heilmann: 7 Reasons why EdgeConf rocks and why you should be part of it |
Having just been there and seeing that the coverage is available today, I wanted to use this post to tell you just how amazing EdgeConf is as a conference, a concept and a learning resource. So here are seven reasons why you should care about EdgeConf:
Unlike other conferences, where you hear great presentations and have meetings and chats of high significance but have to wait for weeks for them to come out, EdgeConf is live in its coverage. Everything that’s been discussed has a live comment backchannel (this year it was powered by Slack), there are dedicated note-takers and the video recordings are transcribed and published within a few days. The talks are searchable that way and you don’t need to sift through hours of footage to find the nugget of information you came for.
The format of EdgeConf is a Q&A session with experts, moderated by another expert. There are a few chosen experts on stage but everybody in the audience has the right to answer and be part of it. This happens in normal conference Q&A in any case; Edge makes sure it is natural instead of disrupting. There is no space for pathos and grandstanding in this event – it is all about facts.
Edge attracts the most dedicated people when it comes to newest technology and ideas on the web. Not blue-sky “I know what will be next” thinkers, but people who want to make the current state work and point towards what’s next. This can be intimidating – and it is to me – but for networking and having knowledgable people to bounce your ideas of, this is pure gold.
Edge is a commercial conference, with a very affordable ticket price. At the end of the conference, you see a full disclosure of who paid for what and how much money got in. Whatever is left over, gets donated right there and then to a good cause. This year, the conference generated a massive amount of money for codeclub. This means that your sponsorship is obvious and people see how much you put in. This is better than getting a random label like “platinum” or “silver”. People see how much things cost, and get to appreciate it more.
Instead of being in a hotel or convention centre that looks swanky but has no working WiFi, the organisers partner with tech companies to use their offices. That way you get up-close to Google, Facebook, or whoever they manage to partner with and meet local developers on their own turf. This is refreshingly simple and means you get to meet folk that don’t get time off to go to conferences, but can drop by for a coffee.
All the panels of this conference are live streamed, so even if you can’t make it, you can sit in and watch the action. You can even take part on Slack or Twitter and have a dedicated screening in your office to watch it. This is a ridiculously expensive and hard to pull off trick that many conferences wouldn’t event want to do. I think we should thank the organisers for going that extra step.
The team behind Edge is extremely dedicated and professional. I rushed my part this year, as I was in between other conferences, and I feel sorry and like a slacker in comparison what the organisers pulled off and how they herd presenters, moderators and audience. My hat is off to them, as they do not make any money with this event. If you get a chance to thank them, do so.
When the next Edge is announced, don’t hesitate. Try to get your tickets or at least make sure you have time to watch the live feeds and take part in the conversations. As someone thinking of sponsoring events, this is a great one to get seen and there is no confusion as to where the money goes.
|
|
Ben Hearsum: Mozilla will stop producing automated builds of XULRunner after the 41.0 cycle |
XULRunner is a runtime package that can be used to run XUL+XPCOM based applications. Automated builds of it have been produced alongside Firefox since 2006, but it has not been a supported or resourced product for many years. We've continued to produce automated builds of it because its build process also happens to build the Gecko SDK, which we do support and maintain. This will change soon, and we'll start building the Gecko SDK from Firefox instead (bug 672509). This work will land on mozilla-central during the 42.0 cycle, which means that when the 41.0 cycle ends (September 22, 2015), automated builds of XULRunner will cease.
If you are a consumer of the Gecko SDK this means very little to you -- we will continue to produce it with every Firefox release.
If you are a consumer of the XULRunner stub this means that you will no longer have a Mozilla produced version after 41.0. For folks in this group, you have two options:
|
|
David Rajchenbach Teller: Living in a Go Faster, post-XUL world |
A long time ago, XUL was an extraordinary component of Firefox. It meant that front-end and add-on developers could deliver user interfaces in a single, mostly-declarative, language, and see them adapt automatically to the look and feel of each OS. Ten years later, XUL has become a burden: most of its features have been ported to HTML5, often with slightly different semantics – which makes Gecko needlessly complex – and nobody understands XUL – which makes contributions harder than they should be. So, we have reached a stage at which we basically agree that, in a not-too-distant future, Firefox should not rely upon XUL anymore.
But wait, it’s not the only thing that needs to change. We also want to support piecewise updates for Firefox. We want Firefox to start fast. We want the UI to remain responsive. We want to keep supporting add-ons. Oh, and we want contributors, too. And we don’t want to lose internationalization.
Mmmh… and perhaps we don’t want to restart Firefox from bare Gecko.
All of the above are worthy objectives, but getting them all will require some careful thought.
So I’d like to put together a list of all our requirements, against which we could evaluate potential solutions, re-architectures, etc. for the front-end:
[1] I have heard this claim contested. Some apparently suggest that we should actually break Firefox and base all our XUL-less, Go Faster initiatives on a clean slate from e.g. Browser.html or Servo. If you wish to defend this, please step forward :)
Does this sound like a correct list for all of you?
https://dutherenverseauborddelatable.wordpress.com/2015/07/13/living-in-a-go-faster-post-xul-world/
|
|
Benjamin Kerensa: Pocket: the feature nobody wanted |
I’ve sat out of the discussion on Mozilla-Governance that has been ongoing over users disappointment with Pocket. I have seen other Mozillians dive in and defend the feature but I do not think this is helping at all. I read this post “Firefox, you’re supposed to be in my pocket, not the other way around” today and felt like it had many truths in it. I really do not know the rationale for adding Pocket as a default to Firefox but I assume there was some financial benefit for Mozilla involved.
The thing is the Pocket implementation is being lauded by Mozillians and MoCo as something that end users wanted but putting aside the discussions on Mozilla-Governance and the feedback from users on Input (Seems like the negative feedback is non-stop on Pocket). I’ll say that I have personally see a number of friends point out their distaste for this feature and it puts me in an awkward situation because I feel like defending Mozilla by default but rationally I cannot.
Who ever it was in management that gave the green light for this feature clearly is not listening to our users or didn’t get the right brief because I do not see a demand for Pocket in the browser. Can we start living the motto we like to use in marketing so much about how we serve our millions of users and not shareholders?
It seems like we are putting experiments and profit seeking features before our users instead of delivering on the features, performance and stability they truly want. So can we please make the rest of 2015 a year where we do not drop any other controversial features in our users laps? Can we focus on getting Electrolysis right? U2F? Improved ESR Support (Chrome is winning the web in Enterprise and Academia)?
|
|
Neil Deakin: Comparing Flexible Box Layouts |
I decided to take a look at what would happen if I replaced some code in Firefox such that instead of XUL box layout, CSS flex layout was used. The latter is generally a standardized version of XUL box layout using only CSS properties. It supports the same properties and values using different names, and has a few additional features. One possible way to implement this is to just set ‘display: flex’ on elements by default, and assign some rules to map the various attributes to the CSS flex properties. This isn’t enough though and just makes the UI look all confused. I then tried extending the CSS flex implementation to check for the XUL attributes as well as the existing XUL flex properties, but only for XUL elements. This worked slightly better.
It turns out that CSS flex doesn’t care for things that aren’t blocks or flexible elements as children, so I needed to tweak some checks to allow for certain types of XUL layout types that have no standard equivalent (such as the deck element needed for displaying a tabbed browser). I also disabled an assertion, but since this is just an experiment, I didn’t feel that was important. Finally, I was able to get a working Firefox browser.
It looks pretty good. There are a few glitches here and there that could be fixed up, for example, the titlebar overlaps the tab bar, and the back button and location field box overlap a bit, but it mostly looks and works fairly well. The preferences panel and other dialogs also work reasonably well. I had to disable menus, tooltips and panels though and didn’t investigate why they didn’t work.
Let’s take a look at how well this special version of Firefox performs.
Not very well actually. The CSS flex version spends over 13 times more time within the layout/reflow step than the XUL box version. When I then tried this in a debug build, there was noticeable delay while interacting with the browser when significant layout steps were needed, such as opening the sidebar.
There are several possible explanations. One is that CSS flex is just slower in general. Another is that it has trouble mixing flexible boxes with specific XUL layout types that are used within the Firefox UI (stacks, decks, etc) that I didn’t change. Or perhaps there are some specific arrangements of elements that cause an issue. In a debug build, some layout and flexbox related warnings are printed out; these could also account for performance issues. For example, some code may be getting confused, printing a warning, then trying to lay out some elements again; I’m not familiar enough with the implementation to know for sure. Let’s dig deeper.
I first tried a number of simpler XUL testcases, and found that performance was still better with XUL boxes, although not by an order of magnitude. I decided then to switch to an entriely HTML testcase, where any other aspects of XUL wouldn’t hopefully be involved. First, I tried a simple HTML testcase using the CSS flex type compared to the -moz-box (XUL box) type on the same element. I used a fresh optimized build of Mozilla code with only minor changes to disable scrollbars for this and the following tests. I loaded the test and measured the time spent.
The first test involves a single parent element with either of the two layout types with a variable number of children, up to 5000, as shown in the chart.
The first thing to notice is that a horizontally laid out element is slower than a vertical one for both XUL and CSS flex layout. I’m sure some layout developer could explain why that might be the case. Second, the XUL layout scales slightly worse than the CSS layout, although there isn’t a noticable difference at small values.
The second test involves a structure of a few elements mixed with some text. To check the scalability, I copied this structure of elements multiple times and nested them inside each other to create a very deeply nested structure many elements deep. I tried this test first with a mixture of horizontal and vertical layout, then with all elements set to use horizontal layout.
For this test, CSS flex is slightly worse at scaling to very deeply nested structures than XUL box layout, although again, only by a small amount. I then tried the same test where every element was assigned a horizontal layout. The XUL flex case is slightly worse, although not significantly. The CSS flex case however becomes significantly worse quite quickly, taking almost twice as long.
After I made this chart, I tried a case with only vertical laid out elements. Unfortunately, the XUL test case with only vertical elements got into some kind of infinite loop situation so I wasn’t able to make a direct comparison. However, the CSS flex case did appear to perform much better in this case, and scaled much better.
The obvious conclusion is that CSS flex layout is slow at horizontal layout. But that still might not be the case. One theory I have is that the overflow and scrolling mechanism for the document causes a delay only in the horizontal direction. I may investigate that further later. But even if CSS flex is slower horizontally, that doesn’t fully explain the extra 200 milliseconds of time taken to start Firefox. The tests done here tests scalability, but noticeable delays don’t really start until much higher values of children or nested structures, generally higher complexity than I would expect the Firefox UI to actually have.
For fun, I decided to add a rule that made almost every element a XUL box. The rule below should handle most cases, except for other style rules where the important marker is also used and a number of specific XUL elements that are mapped by tag name.
* { display: -moz-box !important; }
The result is that 40 milliseconds was taken up doing reflow at startup to load the initial page. A bit slower than the 16 milliseconds from before but still faster than CSS flex. I also tried replacing the rule above with one that used CSS flex by setting the display property to ‘flex’ but still maintaining the important marking. The result was that 49500 milliseconds of reflow time was spent during start up. You read that right: 49 thousand. That’s almost 50 seconds. I’ve no idea what could be causing such a drastic slow down when CSS flex is used, but that clearly isn’t good.
With the investigation so far, I can only conclude that it looks as if CSS flex box is not something that can be dropped into the Firefox UI with minimal changes, as I thought it might be. While it offers some feature advantages and fixes issues that XUL box layout has with inline text, the startup performance degradation with a simple fix is quite high. More detailed work and investigation is needed to determine the causes of the performance problems to determine whether there are specific element structures that cause problems that could be avoided, whether certain XUL layout types mixed with flexible boxes cause errors that can be fixed, or whether significant additional performance optimizations need to be done.
https://enndeakin.wordpress.com/2015/07/13/comparing-flexible-box-layouts/
|
|
Julien Pag`es: Python [aggressive] pep8 conversion using autopep8 |
Some time ago, I started to look at Talos, the python performance testing framework for firefox that is usable on Windows, Mac and Linux.
Talos has been around for a long time, and has seen many contributors! Unfortunately the codebase reflects that, and as an example there was simply no common code style around for all the Python files.
Sometimes a 2 spaces based indentation, sometimes 4 spaces based, sometimes something else. No limit for the lines length. This end up with something that is really hard to read, understand and maintain. So one of my first goal was to try to clean this up.
And I heard about autopep8. As the name suggests, this is a tool (command line) that will automatically do some pep8 conversion on Python source files.
Awesome! I highly recommend that to you if you are trying to adapt the coding style of some Python code to pep8 convention, this worked really well for me. This is a pain to do that by hand, and almost impracticable when the indentation needs to be fixed, but autopep8 makes that for you in a safe way.
Tip: the –aggressive flag is really nice for fixing long lines.
So, as an example this is how I used autopep8 on talos:
autopep8 --recursive --in-place --aggressive --aggressive /path/to/talos
Simple and effective. See the usage documentation to see with an example what it really does and other command line flags.
https://parkouss.wordpress.com/2015/07/13/python-aggressive-pep8-conversion-using-autopep8-2/
|
|
Emily Dunham: Interactive Rust Examples in Static Pages |
Rust by Example has a little box where readers can interact with some example Rust code, run it using the playground, and see the results in the page. As a sysadmin I’m loath to recommend that anybody trust the playground for anything, but as a nerd and coder I recognize that it’s super cool and people want to use it.
There are 2 ways to stuff a Playground into your website: The easy way, and the “right” way. Here’s how to do it the easy way, and where to look for examples of the hard way.
http://edunham.net/2015/07/13/interactive_rust_examples_in_static_pages.html
|
|
Robert O'Callahan: Two Reverse-Execution Optimizations |
rr 4.0 will be the first rr release where reverse execution is reliable. I want to release it soon, but some users still find situations where reverse executions that seems to hang. I've implemented a mitigation by allowing ctrl-C to interrupt reverse execution (though I think there are still bugs where sometimes it fails to interrupt cleanly), but there are also underlying issues that can cause reverse execution to be very slow, and I want to fix as many of those as I can. I've recently fixed the two major fixable issues that I currently know of, and they're interesting.
For the following discussion, keep in mind that we implement reverse execution by restoring the program state to a previous checkpoint, then executing forwards and noting which breakpoints/watchpoints get hit. Once we reach our original starting point, we know which breakpoint/watchpoint firing is the "next" one in the reverse direction; we restore the program state to a previous checkpoint again, and execute forward again until we reach that target breakpoint/watchpoint.
The first issue involves reverse execution over conditional breakpoints/watchpoints that are hit frequently but whose condition almost always returns false. Following the above procedure, rr would reverse-continue to the most recent triggering of the breakpoint (or watchpoint), then stop and signal gdb; gdb would read program state via rr to evaluate the breakpoint, and then signal rr to continue with reverse execution. Thus, every time the breakpoint is hit, rr must perform at least two clonings of checkpoint state plus some amount of forward execution. That makes reverse execution unbearably slow if the breakpoint is hit hundreds of times.
Fortunately, gdb has an obscure feature that lets it offload evaluation of simple conditions to the remote target (in this case, rr) by expressing them as bytecode. So we add to rr a little interpreter for gdb's bytecode; then rr can implement reverse execution by executing forwards over some time interval, and every time a breakpoint is hit, evaluating its condition and ignoring the hit if the condition evaluates to false. If all goes well we only have to reconstruct program state for debugger stops where the user actually wanted to stop.
Unfortunately not all goes well. Some breakpoint expressions, e.g. those involving function calls, are too complex for gdb to express with its bytecode; in such cases, pathological slowdown of reverse execution is inevitable. So try to avoid using complex breakpoint conditions on breakpoints that are frequently hit during reverse execution. Moreover it turns out gdb has a bad bug in code generation, which requires an even worse workaround. I submitted a gdb fix which has landed upstream so hopefully one day we can get rid of the workaround.
Another case which is difficult to deal with is an unconditional breakpoint being hit very many times during the interval we're reverse-executing over. In this case just executing forward and stopping thousands times to find the last hit can be prohibitively expensive. Ideally we could turn off breakpoints, run forward until we're close to where reverse execution started, then enable breakpoints and continue forward again, hopefully only hitting a few occurrences of the breakpoint before we reach the last one. We can approximate this by detecting that we're hitting "too many" breakpoints while executing forward, and responding by cutting the remaining execution interval roughly in half, advancing to the start of the second half with breakpoints disabled, and resuming normal forward execution with breakpoints enabled --- possibly having to repeat the subdivision process if we're still in dense region of breakpoint hits.
I just landed these fixes on master. I'm very interested in hearing about any remaining cases where reverse execution takes a pathologically long time.
http://robert.ocallahan.org/2015/07/two-reverse-execution-optimizations.html
|
|
This Week In Rust: This Week in Rust 87 |
Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust or send us an email! Want to get involved? We love contributions.
This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.
This week's edition was edited by: Brian Anderson, Vikrant Chaudhary
.collect() to transform Vec> into Result>.122 pull requests were merged in the last week.
#[prelude_import] attribute, which is employed by rustc to perform dark and mysterious acts, but is not supposed to be stable. This is not known to break real code.rustc on Windows now looks in the registry to find the location of the MSVC linker.Vec::resize and Read::read_to_end.PartialEq for slices.rustc now uses LLVM to write archive files where possible. Eventually this will eliminate the compiler's dependency on the ar utility.String::into_boxed_slice and Box::into_string .slice.tail(), slice.init() with new methods slice.split_first(), slice.split_last().connect to join.Every week the teams announce a 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. This week's FCPs are:
lines_any to BufReadIntoRaw{Fd, Socket, Handle} trait to complement AsRaw*useDebug of tuples, tuple structs and enum variants in a single linecargo installIf you are running a Rust event please add it to the calendar to get it mentioned here. Email Erick Tryzelaar or Brian Anderson for access.
I think if someone placed the Rust and Go community in a room and asked them to fight, we'd probably just all order pizza and geek out over languages. — Manish Goregaokar
Thanks to msiemens for the tip. Submit your quotes for next week!.
http://this-week-in-rust.org/blog/2015/07/13/this-week-in-rust-87/
|
|
Benjamin Sternthal: Wordpress + Docker + Github |
Working with Wordpress and Git for me has been a challenge. Ideally I want to keep just my plugins and theme in version control and keep all the Wordpress files (that I would never edit) seperate. You can accomplish this manually but how would this work if you are using Docker for local development?
Docker.. actually makes this easy and quite elegant.
With Docker you are able to leverage the Wordpress container and just have your theme and plugins in version control. Amazing.
Below is the docker-compose file, a project template using this can be found in this github repo.
web:
image: wordpress:4.2.2-apache
links:
- db:mysql
ports:
- "3000:80"
volumes:
- plugins/:/var/www/html/wp-content/plugins
- themes/:/var/www/html/wp-content/themes
db:
image: mariadb
environment:
MYSQL_ROOT_PASSWORD: example
image This pulls a specific version of wordpress. Use this to match whatever you are developing against. The list of available versions can be found in the docker registry
volumes This mounts your plugin folder at the correct location within the container.
That is all!
http://www.devpatch.com/articles/2015-07-13-Wordpress-Docker/
|
|