whiteknight/pbc_pbc branch needs testing

[Andrew Whitworth]

I've fixed the few remaining test failures that were reported to me,
and updated this branch to master. It's looking good to me already,
and I would like to try to merge it in to master tonight or tomorrow
morning.

For an example of an immediate use of the new features in the branch
see: https://gist.github.com/1099564. In this example I read in a .pbc
file from Rosella, get a list of all subs from it, and create a
.winxed header file with forward declarations for all the namespaces,
classes, and subs defined in it. That's only one new feature, there
are a few others at the C API level that aren't as easy to
demonstrate.

Test reports, suggestions and feedback would all be appreciated. Thanks!

--Andrew Whitworth



On Sun, Jul 17, 2011 at 11:41 AM, Andrew Whitworth
<wknight8111 at gmail.com> wrote:
> I have been working on several cleanups for the packfiles subsystem,
> especially the public API for it, in the whiteknight/pbc_pbc branch.
> Some changes I've made are straight-forward and should have no effects
> on most users. Others are a little bit more controversial (see TT
> #1324, for example). I would like to get testing on it to make sure
> it's moving in a good direction.
>
> This branch will not merge until after 3.6, if all goes well. Priority
> is still on testing master until 3.6 is out. If you have a few spare
> cycles, getting tests on this branch would be much appreciated.
>
> We're really starting to get this subsystem interface cleaned up. Not
> just the way the functions are named and things like that, but we're
> actually starting to make some real changes to the way the interface
> is used and what kinds of capabilities and semantics get exposed. I've
> removed a lot of dead code, and I've started adding some new features
> to enable some deprecation issues to start moving forward as well. I
> have a few other things I would like to try to tackle before merging,
> but I might not want to wait if there are blockers or deprecation
> boundaries in the way (TT #2140, TT #2144, TT #2135, etc).
>
> Thanks,
>
> --Andrew Whitworth
>