# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 3
# self = https://watcher.sour.is/conv/xnfrmlq
Here’s an example of X11/Xlib being old and archaic.
X11 knows the data type “cardinal”. For example, the window property _NET_WM_ICON (which holds image data for icons) is an array of “cardinal”. I am already not really familiar with that word and I’m assuming that it comes from mathematics:
https://en.wikipedia.org/wiki/Cardinal_number
(It could also be a bird, but probably not: https://en.wikipedia.org/wiki/Cardinalidae)
We would probably call this an “integer” today.
EWMH says that icons are arrays of cardinals and that they’re 32-bit numbers:
https://specifications.freedesktop.org/wm-spec/latest-single/#id-1.6.13
So it’s something like 0x11223344 with 0x11 being the alpha channel, 0x22 is red, and so on.
You would assume that, when you retrieve such an array from the X11 server, you’d get an array of uint32_t, right?
Nope.
Xlib is so old, they use char for 8-bit stuff, short int for 16-bit, and long int for 32-bit:
https://x.org/releases/current/doc/libX11/libX11/libX11.html#Obtaining_and_Changing_Window_Properties
That is congruent with the general C data types, so it *does* make sense:
https://en.wikipedia.org/wiki/C_data_types
Now the funny thing is, on modern x86_64, the type long int is actually 64 bits wide.
The result is that every pixel in a Pixmap, for example, is twice as large in memory as it would need to be. Just because Xlib uses long int, because uint32_t didn’t exist, yet.
And this is something that I wouldn’t know how to fix without breaking clients.
Here’s an example of X11/Xlib being old and archaic.
X11 knows the data type “cardinal”. For example, the window property _NET_WM_ICON (which holds image data for icons) is an array of “cardinal”. I am already not really familiar with that word and I’m assuming that it comes from mathematics:
https://en.wikipedia.org/wiki/Cardinal_number
(It could also be a bird, but probably not: https://en.wikipedia.org/wiki/Cardinalidae)
We would probably call this an “integer” today.
EWMH says that icons are arrays of cardinals and that they’re 32-bit numbers:
https://specifications.freedesktop.org/wm-spec/latest-single/#id-1.6.13
So it’s something like 0x11223344 with 0x11 being the alpha channel, 0x22 is red, and so on.
You would assume that, when you retrieve such an array from the X11 server, you’d get an array of uint32_t, right?
Nope.
Xlib is so old, they use char for 8-bit stuff, short int for 16-bit, and long int for 32-bit:
https://x.org/releases/current/doc/libX11/libX11/libX11.html#Obtaining_and_Changing_Window_Properties
That is congruent with the general C data types, so it *does* make sense:
https://en.wikipedia.org/wiki/C_data_types
Now the funny thing is, on modern x86_64, the type long int is actually 64 bits wide.
The result is that every pixel in a Pixmap, for example, is twice as large in memory as it would need to be. Just because Xlib uses long int, because uint32_t didn’t exist, yet.
And this is something that I wouldn’t know how to fix without breaking clients.
@movq Nice looking birds! :-)
Oh, interesting. Lessons learned: Never simply redefine things.