I think sharing more code is a great idea - and is something I've been meaning to do for a while but haven't had time.

I'm wondering if we want to merge all of remoteprocess into this spytools crate ? I think having one more fully fleshed out crate will make life a little easier for us -

That sounds good to me. I think my first refactor attempt will be pretty rough (not merge-worthy), but it should give us a sense of what's possible. I'll ping you here when that's done so that we can think through next steps.

WIP branch here: https://github.com/acj/rbspy/tree/spytools-crate

So far, I've moved PythonProcessInfo (now ProcessInfo) and BinaryParser into the new crate (just a subdirectory right now), and they work pretty well. I was able to delete a lot of scruffy address lookup code. The main compatibility snag is that there's a list of symbols (get_windows_symbols), a handful of regexes (is_lib), and a hard coded name or two (is_framework) that we'll need to parameterize somehow if py-spy and rbspy are going to share the code.

To keep it simple for the calling code, I was thinking about defining a trait in the spytools crate that has a method for each bit of info that varies between python and ruby, and then adding a generic parameter to ProcessInfo::new that implements that trait. Not sure whether the trait implementations should live in spytools or in the respective spy repos. If you know of a cleaner way, or if that seems like a bad idea, let me know.

Once the dust settles on ProcessInfo, I'll take a look at merging remoteprocess into the crate, and then I'll put up a PR for feedback.