Swanson's law is an observation that the price of solar photovoltaic modules tends to drop 20 percent for every doubling of cumulative shipped volume. At present rates, costs halve about every 10 years.
I have not yet made a decision about how to respond to James Damore's memo about diversity at Google. I am going to wait for the outrage to subside, for the various members of the Twitter mob to lay down their metaphorical pitchforks and return to their homes. I do not wish to be a participant in a modern-day Internet lynching -- and neither should you. If anything Mr. Damore has written in the memo constitutes a fireable offense (as some people have alleged), then I will, indeed take that step. However, such a drastic action does not need to take place immediately. If it is in fact justified, then delaying it a few days will cause no great harm. And this little bit of extra time will allow for hurt feelings and outrage to subside, and that will in turn allow us all to approach the issue with cooler heads and sounder judgment.
-- Imaginary Sundar Pichai
The chemtrail conspiracy theory is the unproven belief that long-lasting trails, so-called "chemtrails", are left in the sky by high-flying aircraft and that they consist of chemical or biological agents deliberately sprayed for sinister purposes undisclosed to the general public. [1]
> 16.2 billion gallons
> 61.3 billion liters ; 3.78541 liters per gallon
> 47.5 billion kg ; 775 g/l or 0.775 kg/l, the lower figure for jet fuel
> 47.5 million tons ; 1000kg per metric ton
> 1.66 million tons ; tons sulfur, assuming 3.5% sulfur by weight
> 3.32 million tons ; sulfur dioxide is about 1/2 sulfur by mass (32.06 / 64.066)
> 3.32 million tons ; assume U.S. aircraft inject 3.32 million tons of sulfur dioxide
> 6.64 million tons ; assume European and Asian aircraft can inject a similar amount
> 13.3 million tons ; assume a 2 year time horizon
It is shown that self-sinking of a spherical probe in the form of a capsule filled with radionuclides, whose decay heats and melts the rock in its path, deep into the Earth is possible. Information on the formation, structure, and shifts deep in the Earth can be obtained by recording and analyzing acoustic signals from the recrystallization of the rock by the probe.
A cryobot or Philberth-probe is a robot that can penetrate water ice. A cryobot uses heat to melt the ice, and gravity to sink downward. The difference between the cryobot and a drill is that the cryobot uses less power than a drill[citation needed] and doesn't pollute the environment.
A cryobot or Philberth-probe is a robot that can penetrate water ice. A cryobot uses heat to melt the ice, and gravity to sink downward.
Feature Description
We want Firefox to override server-supplied 404 error pages in certain cases. The Firefox 404 page should provide the user with tools we think are more useful to the user for resolving the situation, than the server supplied page. This includes alternate ("did you mean") URLs derived from the Places database and some pre-loaded search links/controls. This is being tracked in bug 482874. StatusStalled.The primary sticking point is the review of docshell/resources/content/notFoundError.xhtml. The network error pages seem to be poorly owned, and it’s not clear to me who to even ask for review. Final L10N approval is waiting on error page approval.There are some relatively minor changes to nsDocShell.cpp since Boris Zbarsky’s approval last year. I don’t think this is a big deal, but it is C++ and it is in docshell, so it probably needs a further look. There’s one minor outstanding change needed for RTL approval.Next StepsA code reviewer for notFoundError.xhtml needs to come forward and help me out. Any suggestions? If a code reviewer materializes and provides code review, I’ll take care of the necessary code changes. I have already tried (without success) to try to run down a code reviewer myself, so I need help from someone to do that. Notes]]>
It sometimes makes sense to parameterize localizable strings. For example, in the 404 error page, I need to display a string that looks like:
"Search {site} for {search-phrase}"If this string were in a .properties file, it might actually look like: "Search %S for %P"However, since I need to reference the string from a non-privileged XHTML page, I have to use an ENTITY definition in a ".dtd" file. The "%" character is not legal in an entity definition, at least not as a literal. And, if we want to parameterize an entity, we have to roll our own parameterization scheme anyway. For XHTML files, it turns out the simplest way to do this is to embed XHTML markup in the entity definition, for example: "Search <span id='site'/> for <span id='searchPhrase'/>"It's then trivial to look these elements up using JavaScript and inject the appropriate contents at runtime. This makes for ugly looking strings, but it's dirt simple to implement. It occurred to me the other day, that since you can embed references to other entities inside, you could replace the SPAN markup with something like: "Search ¶m.site; for ¶m.searchPhrase;" A more complete example might look like: <!ENTITY httpFileNotFound.searchSiteForA few months back I got this wild idea that you could insert trace-logging code (not jit-tracing, that's something else) into more or less arbitrary C++ by redefining certain C++ keywords as macros. It turns out that you can, in fact, make this work, at least for certain non-trivial cases. Notably, I've been able to compile an instrumented version of Firefox on OS X using this technique.
I'm not sure whether the technique is generally useful, but given our new focus on crashes and hangs, I thought I'd at least mention it. It's probably not particularly useful for crashes but it may have some utility for debugging hangs. I used an earlier version of this code to debug a Firebug hang (Bug 497028), although in that case I already had a good idea where the problem was and I probably could have used the debugger just as effectively.
Here's the latest tracing code, which I have in a file called "quicktrace.h":
#ifdef __cplusplus #include <stdio.h> #include <string.h> static void QuickTrace(const char *fileName, int lineNumber) { if (lineNumber % 100 != 0) return;// if (strstr(fileName, "/js/") != NULL) return; fprintf(stderr, ";;; %s %d\n", fileName, lineNumber); } #define if if (QuickTrace(__FILE__, __LINE__), 0) {throw 0;} else if #define for if (0) {throw 0;} else for #define switch if (0) {throw 0;} else switch #define do if (0) {throw 0;} else do #endif
I inserted this code globally by adding the following two lines to my .mozconfig:
export CXXFLAGS="-include /Users/cbartley/dev/mozilla-e/src/quicktrace.h" ac_add_options --enable-cpp-exceptions
Note that the use of exceptions is non-functional -- the only purpose is to suppress warnings about code paths that don't return a value. If you don't care about the warnings you can dispense with the "throw 0" statements in the header file and the --enable-cpp-exceptions in your .mozconfig file.
Notes:
Feature Description
We want Firefox to override server-supplied 404 error pages in certain cases. The Firefox 404 page should provide the user with tools we think are more useful to the user for resolving the situation, than the server supplied page. This includes alternate ("did you mean") URLs derived from the Places database and some pre-loaded search links/controls.
Status
Next Steps
Notes
Edit: Added Notes section.
]]>
Note: Since I was getting lots of comment spam I've closed comments here. If you have any comments or suggestions, feel free to file them on the Firebug Issues page or drop us a line in the Firebug discussion group in the Tabs on Top thread.
The Firebug tabs-on-top UI refactoring has finally landed in Firebug 1.4 alpha. You can download it as firebug-1.4.0a17.xpi (or later) from http://getfirebug.com/releases/firebug/1.4. This change is pretty close to the one I described and prototyped in February (see Improving the Firebug UI) and which in turn follows my original proposal from late last year (see Firebug UI: Tabs on the Top). These blog posts describe the reasoning behind the change so I won't rehash it in full.
The old layout had a toolbar at the top of the Firebug UI, and a tabbed "panel bar" below it. Sometimes a tabbed "side panel bar" would show up to the right of the main panel bar. This change essentially takes the toolbar and the side panel bar (when it appears) and puts them inside the active panel. This puts the panel tabs at the top of the Firebug UI (hence the name "tabs-on-top") and panel specific controls underneath. Several controls that are not panel-specific (the main Firebug menu, the search box, and the detach window and close window buttons) have been moved to the tab strip, so they are effectively in the same location as before the change. The idea is that UI elements that are specific to a panel look like they are inside that panel. This description probably makes the change sound more complicated that it really is. A screenshot will better communicate how it looks.
Last week we were discussing, among many other things, ways to speed up Firefox during startup. One obvious option was to move more of our I/O off of the main thread. This in turn involves making more code asynchronous, and asynchronous code is simply harder to manage. Mike Shaver mentioned something about "futures" as a possible way to handle the extra complexity, and then the discussion moved on to something else.
I'm not exactly an expert, but I've not just used futures, I've written my own implementations in JavaScript and even Object Pascal (in hindsight I'm not sure the latter was a good idea, but it was certainly an interesting exercise). Futures seem esoteric, but they really shouldn't be -- the idea is really quite simple. In this post I'll try to explain what futures are and how they can be used to make asynchronous programming easier.In the simplest form, a future works like an IOU. I can't give you the money you've asked for right now, but I can give you this IOU. At some point in the future, you can give me the IOU and I'll give you the money -- if I have it. If I don't have it yet, then you can wait until I do. I get paid on Friday.
Alternatively there's the dry cleaner metaphor. You drop your clothes off on Monday and the clerk gives you a ticket that you can use later to reclaim your clothes after they've been cleaned. The clothes will be ready on Tuesday morning, but if you show up too early, you'll have to wait. On the other hand, if there's no hurry, you can just do other stuff on Tuesday and show up on Wednesday with a reasonable expectation that they'll be ready when you arrive. You'll just hand your ticket over, collect your clothes, and be on your way. A future is similar to the IOU (or the dry cleaning ticket). It gives you a way to represent the result of a computation that has not yet completed, and it allows you to access that result once it becomes available. So you can call a function which starts some asynchronous process but doesn't wait for it to finish. Nevertheless the function can return you a useful result: a future which can be used to claim the real result later. Of course if you ask for the result too soon, you'll have to wait. On the other hand, if the result becomes available before you want it, then it will wait for you.Here's an example of what this might look like in pseudo-JavaScript:
function doStuff() {Imagine that I have a web page that sends an AJAX request to a server and then displays the results in an IFRAME -- and furthermore does it automatically on page load. I have to wait for both the AJAX request to return data and for the IFRAME to finish loading -- only then can I display the results. This can be done fairly simply using callbacks:
function showData(dataUrl, iframeUrl) {Imagine if you have not one, or two, or three futures, but rather an arbitrary number of futures. What we'd really like to have is a way to take an array of futures and produce from it a single future for an array of concrete values. Something like:
function showData(dataUrlArray, iframeUrls) { // The "dataFutureArray" is a concrete array of futures.OK, now for a more elaborate example. Imagine a function which retrieves the first page of Google search results for a particular query, and then goes through and re-orders the results based on its own ranking system. Furthermore, imagine that this ranking is computed based on the contents of each web page. We'll need to to make requests to many different servers for many different web pages. This will be fastest if we issue all the requests at once.
function search(query) {
My main project for the last few weeks has been doing some Firebug UI work that I’ve been thinking about for a while. Since I’ve just been moving UI elements around (to make the layout more logical), I’ve been referring to this effort as “UI refactoring”.
So here’s the deal. It’s not enough that I think this redesign is an improvement, or even that the Firebug working group has been supportive. We need to know what you, the Firebug user, think.
Before I get started, I should let you know that I’ve been working on the Firebug 1.4 branch, which is still undergoing active development. The changes I’m proposing are fairly simple in the sense that they are really only a reorganization of existing UI elements. However, if you have not yet seen 1.4, be aware that there are other significant UI changes, notably John J. Barton’s work on the activation UI, kpdecker’s multi-file search capability, and Hans Hillen’s work on accessibility.
What’s wrong with the current Firebug UI?The basic UI layout for Firebug today consists of a toolbar across the top, a main “panel bar” underneath, and an optional “side panel bar” to the right. Each panel bar consists of a set of tabbed panels, only one of which is visible at a time.
This is a simple design, and seems pretty logical. There’s a problem, however. The contents of the toolbar can change substantially depending on which panel is selected in the main panel bar. For some panels this is maybe not such a big deal. At the other extreme, consider the Net panel. When the Net Panel is selected, it adds seven buttons to the toolbar which control what information is displayed inside the Net panel’s content area.
For me, using these buttons, with this placement, feels even weirder than the screenshot looks. They would feel much more natural if they were adjacent to the content area that they affect.
Furthermore, the side panel bar is only visible when either the HTML tab or the Script tab is selected. And, of course, it’s a different set of panels that show up in the side panel bar depending on whether it’s the HTML panel, or the Script panel. Logically, you could think of the HTML panel as having a smaller panel bar embedded inside it which in turn contains several sub-panels specific to the HTML view. You can think of the Script panel similarly. The other panels simply don’t have any sub-panels they need to display.
Basically, the problem is that clicking a tab changes not only the main panel below the tab strip, but also the toolbar above it, and oftentimes the side panel bar to the right as well. You click on a tab, and the whole UI mutates around it. Even though the current UI layout makes superficial sense, I contend that the toolbar – or at least a big chunk of it – belongs inside the main panel bar. I also think you can make an argument that the side panel bar, when it appears, should look like it’s inside the currently selected panel.
Another way to think of it: The tabs – Console, HTML, CSS, Script, DOM, and Net – should appear at the top of the Firebug UI where the panel-specific toolbar elements appear now. Since these main panels are the major organizing principle of the Firebug UI, it makes sense that they should be more prominent.
I’m clearly not the first person to come to this conclusion since Firebug Issue 222 makes a similar argument.
This is the layout I have working now. I’ve been referring to this as the “tabs-on-top” layout.
In this design, not all of the toolbar has been relocated. The main Firebug menu that hangs off the Firebug button is in the top-left just as it always has, and the search elements and Firebug window control elements are still at the top right. Although the side panel bar doesn’t really appear to be inside the main panel, it does at least appear subservient.
There are some smaller changes as well. Notably the tabs are now “stand-up” style –
The handling of the main panel Options button and the Inspect button still leave something to be desired. Nevertheless, I think this is a more logical layout, although you probably have to use it to really appreciate the improvement.
What now?As I mentioned above, you really need to try the out the new layout to see if it’s really does work better. To that end, I’ve attached an experimental version of the Firebug extension to the post, so you can download it and try it out. I’ve tested it fairly thoroughly on Windows and to a lesser extent on Mac and Linux. Also, since it’s built on top of the 1.4 branch, which is still under active development, you probably won’t want to leave it installed for too long. However, it should be good enough for you to take it for a test drive.
]]>