This was meant as a proof-of-concept and has several big inefficiencies that could be fixed pretty easily if someone was actually going to use it for something. The UI could also be improved, and I think at least IE9 could be reasonably easy to support (though I haven't tried).
I was using XHR because an important constraint was to do everything client-side, and there's no other way that I could find to get the raw image data. If you have server-side support, though, a lot of things can be made much simpler. Is there a reason not to proxy, like crux_ suggested?
To be more clear on the gh_pages idea. If you rename your master branch to gh_pages then github will automatically let you browse to it. For example one of my projects which includes a index.html just like yours on github:
Things have gotten worse, though, it seems; when I signed up it took about a month before I got the invitation, and I know others who've been waiting ~two months now and still haven't gotten it.
I'll give it a shot. For me, I think about e in terms of compound interest.
I.e. you have a bank account and put in a dollar. Its a great bank, they give you 100% interest. So, after a year, you have (1 + 1) = 2 dollars.
But wait, instead, they compound twice. That is, every 6 months, you get 50% interest. So now you have (1 + 1/2)^2 = 2.25 dollars.
Instead of compounding twice, they compound 4 times. So now you have (1 + 1/4)^4 = 2.44 dollars. Each time you get interest, its given in proportion to what you have in the account at the time. So, if they are compounding 4 times:
(Please note: Rounding error. I just typed in to two places after the decimal point).
Why 2 or 4? Lets just call it compounding n times. As n gets larger, you get more money, but it doesn't go on forever...
For n times, the formula for how much money you have is (1 + 1/n)^n. What if you want to continuously compound? I.e. at every instant, growth is proportional to the current value? Well, then you would want something like (1 + 1/infinity)^infinity. But, we can't really do that, so instead we say:
lim (n --> inf) of (1 + 1/n)^n
And thats what we call e. Start putting in larger and larger values of n and you'll see that it converges to 2.718... The point is that e is pretty much defined as the number you get when you take a number starting at 1 and have it grow in proportion to itself continuously. Instead, if you use 5 instead of e, your growing too fast. In terms of johnaspden's explanation, you'd move too far around the circle, past (-1, 0).
Also, johnaspden, your explanations are truly great, really
helped me understand Euler's formula.
I like to think that people vote on a comment based on the content, not on the (current) score. It is not particularly unlikely that twenty-four people thought:
This is a worthwhile comment! It points out something that I did not realize, and change the meaning of the article to a degree. I may as well vote on it, that it may move upward in the list and other people read it earlier than other comments.
Also remember that +1 isn't specified to be "Insightful" or "Informative" like Slashdot; nor can you vote a "half-good" comment up a half-point. Instead, to achieve the same effect, a half-good comment must appeal to half as many people. This comment happened to appeal, on its own merits, to twenty-four people.
(Does this mean that the highest-voted comments might be the ones that appeal to the biggest percentage of the site, rather than the ones of the highest quality? Hmm. Does that mean that for the voting system to work well, a good percentage of users must specifically only vote comments that are very good?)
What about letting people append to comments after the time limit? I've always thought that would be sensible: People could add to what they've said before in a visible way, but not "rewrite history".
After all, additions are already frequently marked as such (e.g., "EDIT:").
As lanaer said, "<-" is really syntax sugar for ">>=" (bind), and could mean a variety of things (including assignment). "=" is binding a variable, as in "let", and is not symmetric. One could argue that a better name for "=" would be "->", as in "case".
What does gvim have to do with the mouse? Regular console vim supports the mouse, and there are perfectly good reasons to use gvim without it (e.g., better color support, "Edit with Vim" in Windows).
I was using XHR because an important constraint was to do everything client-side, and there's no other way that I could find to get the raw image data. If you have server-side support, though, a lot of things can be made much simpler. Is there a reason not to proxy, like crux_ suggested?