The immediate reason was lack of support in LLVM, but I suspect the reason why it wasn't re-implemented was that the demand wasn't enough to justify the significant amount of work that would be needed to get it working a) with LLVM and b) in the locked-down environment of iOS.
The speed boost from LLVM, SSDs, the "thin" nature of iOS apps, and the bump in processor performance was, per my intuition, enough that a typical "full" build today can handily beat a typical "Fix-and-Continue" build from a few years ago (I use the term "full" to mean a build that updates one or two compilation units and re-links).
It was a nifty feature and I wish they'd bring it back, but I'm pretty sure the XCode team has lower-hanging fruit (static analysis, code navigation, refactoring).
Just to note: Pyringe is not an official google project (we tend to also include googler hobby projects in the org). It's an intern's project that he wanted to open source.
The title is a bit misleading, since Pyringe is "only" able to inject Python code into Python processes.
Aside of that, I think this could prove useful for Clojure-like live coding.
Shameless plug: my company develops Deviare[1]: "code interception for dummies". It allows to intercept a Windows application from any COM capable programming language.
We have interesting code samples such as capturing video intercepting DirectX[2] and hooking into SQL Server to abort unsecure (e.g. injection attacks) queries[3].
Do you know of anything similar for amd64 Mac/Linux? Not PLT hooking but the sort of deal where the beginning of the function is overwritten with a jump to the hook. The overwritten instructions in the original function are copied to a mmap()ed area of memory that jumps back past the hook jump.
I found an old copy of MobileSubstrate that has partial support for i386 and x86_64 (which works fine on Linux since the ABI is the same as Mac). I found out that it doesn't support all the possible jumps in the overwritten area. I've been slowly patching and improving it[0] but I'd rather be spending my time hooking stuff than writing the hooker.
Depending on what state cpython is in when you inject, pyrasite may deadlock or segfault the interpreter. All it does is try to get the GIL and then inject the code.
Pyringe first gets to a safe place before injecting by (essentially) faking the delivery of a signal, then waiting for python-level signal handler dispatch to trigger. By doing so, it ensures the interpreter first gets itself into a state in which it can execute arbitrary python code before performing the injection.
Pyrasite has a bunch of features pyringe doesn't, though.
It doesn't really send a signal to your program. It just sets flags inside cpython to make it think so. (pendingbusy and pendingcalls_to_do, to be precise)
This is super cool. With C programs, you can already attach gdb to a running program and start debugging, without starting the program under the debugger. Before pyringe, you couldn't do the same with Python. This will be very helpful for me at work.
Yes, sure. GDB-level debugging of Python programs, without something like Pyringe, is pretty useless. So I am excited for the Python-level tool for debugging Python.
* https://github.com/albertz/pydbattach (my own :))
* PyInjector (don't find a good link right now)
* I'm quite sure I have seen at least one other similar project here on HN a while ago, but I don't remember the name...