[Xcb] ANNOUNCE: XML-XCB project merging into XCB

[Josh Triplett]

Jamey Sharp wrote:
> I see that you've merged your work in now. On brief inspection, it looks
> good; I'll be digging through it some more later. In the meantime:

Thanks.

> When I 'cvs update'd, I discovered that I had some uncommitted work
> based on the M4 bits. This seemed like a good opportunity to try to
> modify your stylesheet, to see how easily I could do it.
> 
> This particular change was mostly straightforward, but I hit a
> limitation in the implementation: I want the major (and minor, if
> applicable) opcodes to be treated like the length field. Space should be
> reserved for them in the request structure, but they should not be
> assigned to in the generated code.
> 
> I dunno how to do that. A patch is attached with my efforts so far:
> could you play with it and advise me on a fix?

I'd be glad to take a look at the change you suggest.  However, there
didn't seem to be a patch attached to your mail.  Perhaps the list is
filtering attachments?

Note that I'm currently working on two large simplifications to the
XSLT, which might affect the work you are suggesting, and probably make
it easier:

1) I'm going to replace the complicated logic surrounding the <middle>
tag generated by intermediate passes and the hack of putting the first
field/pad/etc into one-byte padding gaps (with no way of knowing if the
first item is actually one byte in size).  The replacement will involve
an explicit "in-gap" attribute in the protocol descriptions, with the
assumption that if there are no fields with an "in-gap" attribute, the
gap should be filled with padding.  This will also allow the removal of
all <pad bytes="1" /> tags at the beginning of replies that are there
solely to fill that gap.

2) As we discussed previously, I'm going to replace the <extension> tag
that goes immediately under <xcb> in extension protocol descriptions
with optional extension-name and extension-xname attributes on the <xcb>
root tag.  This will allow removal of all the (/xcb|/xcb/extension)/...
constructs, as well as the need to use "ancestor::extension" to find the
extension information that applies to a given tag.  This relies on the
previously-stated assumption that there is no need to permit multiple
extensions in the same file.  I suspect this will make a noticeable
difference in the size and complexity of the XSLT, and hopefully speed
up processing as well.

> Could you also tell me whether my use of the <l> line-formatting tags
> matches what you intended?

<l> tags go inside a <function> tag generated by the first or second
pass, and represent one indented line of code.  The output pass will
simply output the content of each <l> as the function body, with each
line prefixed by four spaces.

> Thanks much!

No problem.

- Josh Triplett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://freedesktop.org/pipermail/xcb/attachments/20041106/0828471f/signature.pgp