badass debugger + badass toy = geek pr0n

Today I finally got working a hacked-together minimal version of the iPhone debugger client for BinNavi. It's heavily based on Patrick Walton's (with HD's updates) weasel debugger. Once tied to BinNavi debug client framework the whole client-server interaction is trivial.

It feels just right, the best looking debugger together with the slickest device.. recipe for fun.. ;-)



The test application is telnet on the iPhone. On the iPhone's screen is the debug output from BinNavi's debug client. telnet is launched from an ssh session in OSX, where BinNavi is running.



For anybody trying to link Mach's debugging interface with a C++ iPhone application, remember the extern "C" when defining boolean_t exc_server(mach_msg_header_t *in, mach_msg_header_t *out); (which is not defined in the header files, as pointed in weasel's source code). Otherwise you'll get a nasty "Undefined symbols" message when linking.

extern "C" is also needed for catch_exception_raise(...) so exc_server can call it to handle exceptions. Documented here.
(I've used the standard iPhone toolchain on Debian, this is running on the firmware 1.1.3)

pydot 1.0.2 ... that took long

Finally! it was long due. Here it is pydot 1.0.2

Some weeks ago I started updating the code to support all the attributes and enhancements in GraphViz 2.16. In attempting to make it pass all the regression tests some severe shortcomings it had became apparent.
pydot users had also provided with insight into how to improve performance by redesigning the way the data for the objects is stored internally. All in all, the limitations I was facing led me to rewrite the whole core of pydot, which took much longer than I wanted but I feel it was well worth it as it's orders of magnitude better than the last release 0.9.

Performance-wise the new pydot stores graphs and their objects using a hierarchy of nested dictionaries and lists. Graph, Node, Edge objects are mere proxies to the data and are created on demand. So that now it's possible to have a graph with a 1 million edges and there will not be a single Edge instance (only if requested, then they will be created on demand, mapping the data and providing with all the methods to act on the data in the global dictionary).
Storing a graph with 1 million edges in pydot 1.0 has approximately the same memory requirements (~813MiB) as dealing with one with only 40.000 edges in pydot 0.9 (~851MiB), the 40.000 edges graph needs ~35MiB in pydot 1.0 . Handling graphs should be much faster, as no linear searches are performed in pydot 1.0.2