Colin Putney cputney@wiresong.ca wrote:
This is something I've been working on addressing for the next version of OmniBrowser. Essentially, the next version of OB will operate on an AST that begins with Package at the top and extends down through Class and Method to sub-method parse nodes like MessageSend and Literal.
Yep, I would love to have something around like this and not maintain my own. Already I have stopped using my custom parser in favor of RB's, and I could probably have dumped my parse nodes though that is more trouble than its worth so far. I still am having to deal with keeping an object model of the code in the image (or *not* in the image, depending on what you are analyzing). A lot of this object model could surely be offloaded into a tool like OmniBrowser... but of course, it doesn't actually exist yet. :)
The thing that leaps immediately to mind is inter-package dependencies. I bet it would be feasible to deduce the minimal set of packages required to run, say, the unit tests for a package. (And the minimal code from the "as yet unpackaged" base image too!)
Yeah, that's an interesting application of a dead code remover. Dead code removal is an interesting application, if nothing else because Agesen did it with his inferencer. :) Unfortunately it is not trivial with Chuck being demand-driven; it takes some thought to make it work, and I am not completely sure whether it will be effective. It will certainly improve things on the current image-shrinking scripts, but it might not be good enough to give you good dependency information between packages.
-Lex