On Sat, 17 Apr 2010 10:00:53 -0400, Jeff King <peff@xxxxxxxx> wrote:
> On Sat, Apr 17, 2010 at 03:02:39PM +0200, Jakub Narebski wrote:
>
>> Something like that (please remember that it is still in vague
beginnings
>> of an idea stage:
>>
>> OUT_OBJECT(
>> OUT_FIELD("mode", OUT_MODE, tree.mode), SP,
>> OUT_FIELD("type", "%s", tree.object.type), SP,
>> OUT_FIELD("object", OUT_SHA1, tree.object.sha1), TAB,
>> OUT_FIELD("file", OUT_FILE(sep), tree.filename),
>> sep
>> );
>
> Doing that would require variadic macros, which are a C99-ism. So you
> would have to do:
>
> OUT_OBJECT_START();
> OUT_FIELD("mode", OUT_MODE, tree.mode); OUT_SP;
> ...
> OUT_OBJECT_END();
Also, backends such as JSON want to know which things are strings, and
which are numbers - as they print differently. An XML backend may want to
distinguish even more (though I guess that depends on the design).
> which is not all that different from what Julian has now. I do think
> some type-specific conversions might be handy. They don't even need to
> be macros. E.g.,:
>
> void output_mode(struct output_context *oc, int mode)
> {
> output_strf(oc, "mode", "%06o", mode);
> }
>
> OTOH, looking over Julian's last patch series, there really aren't that
> many that would be generally applicable, and as you can see they only
> save a few characters, not even a line. A few bigger objects could be
> factored out, but he has already done that (e.g., see
> wt_porcelain_unmerged in his v2 3/4).
It might help standardise the output between commands if there were helper
functions for some of the larger structures - e.g. commits. Though I don't
think that those functions would be able to do legacy output, due to the
current lack of cross-command output compatibility. I'm starting to see
this with blame and diff-tree (and family), where they both want to output
information about commits.
I think that maybe I need to design and document the output structure for
common concepts - so that it would be possible to pass the output from any
command to a common parser, with matching utility functions in the code.
Though, I'm not sure if there actually are any common concepts that need
outputting apart from commits.
Current Status
--------------
I had been planning to post an updated series this weekend, but I'm too
tired to attempt tidying things up for posting at the moment ... If you
want to see the current state then my current mess is available at
http://git.q42.co.uk/w/output.git.
A quick summary of main changes since v2:
- backends are now in a subdirectory
- blame, diff-tree, have --ouptut=... support for plumbing output
- log has some support for --ouput=...
- output library has extended API, including quoted strings and
is_structured_output function
- backend API includes explicit functions for top-level items
--
Julian
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html