This is the mail archive of the
mailing list for the Archer project.
Re: freshly-cut python patches
El mar, 14-10-2008 a las 13:45 -0600, Tom Tromey escribiÃ:
> Thiago> I saw some fixes from you on that code, not sure if it was
> Thiago> related to pretty-printing or not.
> I've tried to be careful about making separate commits, but I think
> there is a case or two where I didn't. Sorry about that.
Nothing to be sorry about, it was easy to work with the commits you
made. I was just pointing out what I saw while working with them.
> Thiago> - I'm not sure yet how to organize the pretty-printing work. A few
> Thiago> commits are floating around in isolation as a result of this. Initially,
> Thiago> I was thinking of having two patches: a "ground work and CLI pretty
> Thiago> printing" patch and an "MI pretty printing" patch, but it would take
> Thiago> some effort to make the division. Besides, you and Vladimir will
> Thiago> probably have to agree anyway before submitting any of the patches, so
> Thiago> there seems to be no benefit in the separation and I'm thinking of
> Thiago> making only one pretty printing patch. WDYT?
> Yes, I think one patch is what we should do. The MI and CLI cases are
> tied together now -- they share a good amount of code.
> The pretty-printing code isn't really ready yet, though. I am still
> working on the MI bits. Also, I think we might want to change the
> auto-loading stuff a little.
Ok. I'll merge all the pretty-printing-related patches and commits in
the near future. For the auto-loading bits, I suggest keeping them
separate since they have a good chance of being discussed for some time
when submitted, and the pretty-printing part could be committed earlier.
> I think a good candidate for the next patch would be more additions to
> Value. On the branch I added a couple methods, and these are needed
> to write decent pretty-printers. I can submit this one if you would
Either way is fine by me.
> There are a few other things that are a bit less intertwined that we
> could clean up and submit after that. Specifically I'm thinking of
> convenience functions, commands, and parameters.
Ok. Convenience functions in particular is a good one, because Rob
Quill's scope checking patch (which didn't go in yet) could use it. The
others are good candidates too.
Thiago Jung Bauermann
IBM Linux Technology Center