Emacs does indeed have a plugin for this called "undo-tree". I think it is missing the ability to specify a time to go back by, but you can view the timestamps in the tree visualization.
For anyone that uses emacs, there is an excellent plugin "undo-tree" that solves this problem in a slightly different way. Everytime you undo a series of actions and then perform a new action, it creates a branch in the "tree". You can then visualize the tree and move through it quickly your entire buffer history.
That concern is isolated to your region selection tool, and orthogonal to the undo functionality :-) So, you could select by lines, or intelligently select by parentheses/braces, etc. And ask these are nicely composable, so you could easily set up custom shortcuts if you don’t like the sequence of keystrokes.
Came here to post this. The undo tree is actually built into Vim, but I didn't know about it until I discovered Gundo a decade or so ago. I rarely use it, but it's still installed and has saved me hours of work on a few occasions.
Even without undo-tree, Emacs undo history is "persistent". By that I mean that changes aren't overwritten, so the statement in the article that undoing stuff and then making edits loses the undone changes is not true for Emacs. You just have to undo back through the new edits, then you will start to redo the old undone edits, and so on. It can be tedious, but just the knowledge that it's all there is quite liberating.
Another vanilla feature I sometimes use to keep track of old code is the "kill ring". Just cut the old code and it will be available in there later if needed.
This this this. It was the first thing I missed in Vim when I switched. You also don't lose in Vim, as it keeps it the history as a tree, but it is harder to navigate the tree than Emacs' linear history.
This was my first thought. A timeline is nice, but the problem with a linear undo history is that if you undo and then edit, you lose access to the state before you undid. A tree is clearly the right structure for undo history.
Heck it's how boring business apps handle bookkeeping data since forever. You never delete a record to correct a mistake, you create a new record to do it.
The tree structure is inherently flawed for storing undos when using features like undoing within a specific region, because the new state doesn't map to any previous node on the tree.
By default, Emacs has a linear undo structure, while still allowing you to never lose history.
On this point, C-h m yields a complete list of keybindings for all modes active in whatever buffer you do it in.
More generally, for anyone new to Emacs and struggling as I once did, I can't recommend strongly enough that you learn how to use the help system (C-h C-h) and the built-in manual (M-x info). Emacs can teach you a great deal about itself, and these are the ways it does so.
And if you use IntelliJ/Android Studio there's Local History, which shows your git revisions but also periodic versions of your code outside of your commits
You hit the nail on the head. All of that on top of the fact that he is comparing a top of the line GPU against a mediocre i3 processor. GPU to CPU comparisons are always apples to oranges, but this is pretty bad.
I would like to see an OpenCL kernel that is run on both the GPU and CPU to possibly even the playing field a little.
I wouldn't say GPUs are killing off MPI. You still need some way to pass data between nodes/GPUs (most of these datasets can't fit within a single GPU). What you are seeing though, is less and less use of the CPU. If code developers decide to use GPUs, they try and move their data onto the GPU and keep it there for as long as possible (data movement across PCIe is a killer for performance). ORNL's new machine Sumiit [1] will have 1/4 the nodes of their current machine, Titan, but multiple GPUs per node. Thus emphasizing the move away from CPUs and onto GPUs. Again though, there are still 3K nodes and you need some efficient way to pass data between those nodes.
Two can play at that game. You can store data in JPEG that can even survive recompression with lower quality. If it's worth it to you to go to all that trouble, that is.
Interesting paper: Bypassing Cloud Providers’ Data Validation
to Store Arbitrary Data [1]
>JPG & PNG Steganography Encoder (JPG-PNGStega).
The purpose of this encoder is to inject data (hiding
it) in JPG and PNG files. It takes a File Format Sample (JPG
or PNG) and, for each pixel, it injects 3 bits of data in the
LSBs (Least Significant Bit). There are more sophisticated
image steganography methods already widely discussed.
However, the use of this encoder shows that even basic meth-
ods of JPG and PNG steganography are possible in SaaS
applications, and the exploitation of such method may bring
impacts
The host-side application could already be written using Java, atleast for OpenCL applications[1] (The kernel--that is, the GPU code--was still written in OpenCL). My only concern is that Java will make it more difficult to find out exactly what's going on in the kernel code, and hence more difficult to optimise.
Now, this also doesn't solve the issue of needing to consider the parallel architecture when coding the kernel to actually make use of the hardware. Nevertheless, kudos to the guys behind this.
First the internet revolutionized music and eliminated record stores
Then it revolutionized videos and took down video stores
It didn't stop there, and moved on to bookstores and wiped them out.
And now its taking out brick and mortar stores in general.
Honestly, I LOVE IT! The internet is so great. Anything that gets stuff in my hand faster or easier is great in my eyes.
Not really. "It doesn't really use any parts of Wave's collab stack...We only really use the Keyboard signal event stuff from Wave since it is a pretty great library" -Jamie Yap's comment on g+ post.
