xcffib.pack_list in xprotoExtension methods about xcffib

[tych0]

Hi,

Thanks for the report! I noticed the name thing myself yesterday. I have a patch to fix it, I just have't pushed it yet; I will do that ASAP.

Can you elaborate a little on why you needed the isinstance check in ListFonts? Was that an API supported by xpyb, or just a nice to have thing?

Thanks!

[FRProj]

Hi,

Without the isinstance check I get "struct.error: required argument is not an integer" if I pass a string as the pattern argument for ListFonts. The struct.pack seems to be expecting integers. The list(map(ord...)) thing above was pretty much just a guess on my part that seemed to make it work as I expected, but I dont know if its the "right way".

The conversion of a string to char integers could be done outside the ListFonts by the user as well, I suppose, but I think xpyb accepts string inputs to the ListFonts (FWIW the xcb C interface seems to take a const char * pattern, too).

Unrelated to the above (should I open a separate issue for this?), I had to change another thing I didn't mention earlier in order to get xcffib working on my computer. The offset due to bufsize calculations in the generated xproto.py were of the form "offset += obj.bufsize", But I noticed that the data I got from e.g. get_setup were "in the wrong places" (i.e. they were incorrect, but I could see the correct values in the data nearby but misplaced).

So I checked in xproto.py from xpyb and they have an additional "offset += xcb.type_pad(size, offset)" line in the corresponding places. By adding this I could make get_setup give me what seems like the right values on my computer.

So, in "Parse.hs", I changed
-- totalBytes = mkAttr (n ++ ".bufsize")
to
totalBytes = mkCall "xcffib.incr_offset" ([ (mkName $ "self." ++ n), (mkName "offset")] ++ size)

and then added:

def type_pad(t, i):
return -i & (3 if t > 4 else t - 1)

def incr_offset(data, offset, size = None):
if size:
return data.bufsize + type_pad(size, offset)
else:
return data.bufsize

to init.py. This seems to get me the right results in get_setup, e.g. the root window ID, depth and such. On the other hand I see the xcffib tests are passing on travis for the Python 3.4 build, so I dont know if maybe it should work fine without the type_pad stuff above, and theres something else wrong on my end.

[tych0]

On Wed, Jun 18, 2014 at 05:19:54AM -0700, frobbit wrote:

Hi,

Without the isinstance check I get "struct.error: required argument is not an integer" if I pass a string as the pattern argument for ListFonts. The struct.pack seems to be expecting integers. The list(map(ord...)) thing above was pretty much just a guess on my part that seemed to make it work as I expected, but I dont know if its the "right way".

I think the Right Way is in the commit da9ffe6 that I just pushed. Can
you check that it works for you and I'll merge it?

The conversion of a string to char integers could be done outside the ListFonts by the user as well, I suppose, but I think xpyb accepts string inputs to the ListFonts (FWIW the xcb C interface seems to take a const char * pattern, too).

Yep, just looked at the xml and you're right what is in xcffib now is
definitely broken.

Unrelated to the above, I had to change another thing I didn't mention earlier in order to get xcffib working on my computer. The offset due to bufsize calculations in the generated xproto.py were of the form "offset += obj.bufsize", But I noticed that the data I got from e.g. get_setup were "in the wrong places" (i.e. they were incorrect, but I could see the correct values in the data nearby but misplaced).

So I checked in xproto.py from xpyb and they have an additional "offset += xcb.type_pad(size, offset)" line in the corresponding places. By adding this I could make setup give me what seems like the right values on my computer.

Ah ha, interesting. I haven't implemented this at all yet, so that's
probably why :-).

So, in "Parse.hs", I changed
-- totalBytes = mkAttr (n ++ ".bufsize")
to
totalBytes = mkCall "xcffib.incr_offset" ([ (mkName $ "self." ++ n), (mkName "offset")] ++ size)

and then added:

This calculation corresponds to

return Py_BuildValue("I", -i & (t > 4 ? 3 : t - 1));

in module.c in xpyb

def type_pad(t, i):
return -i & (3 if t > 4 else t - 1)

def incr_offset(data, offset, size = None):
if size:
return data.bufsize + type_pad(size, offset)
else:
return data.bufsize

to init.py. This seems to get me the right results in get_setup, e.g. the root window ID, depth and such. On the other hand I see the xcffib tests are passing on travis for the Python 3.4 build, so I dont know if maybe it should work fine without the type_pad stuff above, and theres something else wrong on my end.

Can you write a test that fails without it? That would be the easiest
way. E.g. by asking for the root window ID with some other request and
then matching it to setup's? The test suite right now isn't very
complete, so it doesn't surprise me at all that there are bugs that it
doesn't catch.

Opening another issue would be great. I'm happy to help you make a
pull request too for any patches you want to integrate. I'm in #qtile
on irc.oftc.net, otherwise github has some reasonable documentation
as well: https://help.github.com/articles/using-pull-requests

Thanks!

[tych0]

Ok, looks like I forgot to fix the tests too. The branch fix-2 fixes the tests as well. Thank god for ci ;-)

[FRProj]

Yes, changing the "b" to "c" in the pack_list fixes the ListFonts thing! (the extra "self." on the pattern_len is still there, though). For the root window ID, I think one of the current tests might cover it. There's one with a line
"
reply = self.xproto.QueryTree(self.default_screen.root).reply()
"
which fails with an "xcffib.xproto.WindowError" when I run "make check" here (since the default_screen.root has an invalid ID).

I haven't figured out how to check whether that test succeeds when I modify the "totalBytes = mkAttr (n ++ ".bufsize")" line in Parse.hs, since another earlier test fails when I make that modification in the Haskell (the "rendering equal" test). I'll take a look at that pull-request doc, and perhaps set up a fork if I come up with any good patches (though unfortunately I'll be mostly restricted to contributing to the Python parts due to very limited Haskell skills). Thanks!

[tych0]

On Wed, Jun 18, 2014 at 08:24:27AM -0700, frobbit wrote:

Yes, changing the "b" to "c" in the pack_list fixes the ListFonts thing! (the extra "self." on the pattern_len is still there, though).

Yep, I will push a patch for that later today. It is a little more
involved and not nearly as clean :-).

For the root window ID, I think one of the current tests might cover it. There's one with a line

"
reply = self.xproto.QueryTree(self.default_screen.root).reply()
"
which fails with an "xcffib.xproto.WindowError" when I run "make check" here (since the default_screen.root has an invalid ID).

Ok. Can you post the traceback in a new issue?

I haven't figured out how to check whether that test succeeds when I modify the "totalBytes = mkAttr (n ++ ".bufsize")" line in Parse.hs, since another earlier test fails when I make that modification in the Haskell (the "rendering equal" test). I'll take a look at that pull-request doc, and perhaps set up a fork if I come up with any good patches (though unfortunately I'll be mostly restricted to contributing to the Python parts due to very limited Haskell skills). Thanks!

Yeah, you can 'fix' the rendering tests by running 'make newtests',
which will overwrite the current rendered tests with new versions. I
mostly just have them there to see small diffs of the changes I'm
making in the output to make sure they're right.

No problem on the Haskell part, I knew I was on my own when I picked
that ;-).

\t