Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
I think I'd prefer to not convert wflinfo to python. I also hesitate to convert wflinfo to python. After we push all the complexity of wflinfo.c into a library call, then wflinfo.c will largely consist of argparsing and a minimal json parser. wflinfo.c will then be so small that I don't expect to gain much benefit in moving it to wflinfo.py. (I expect moving it to Python might make it *more* complicated if its argparsing code attempts to be python-2-and-3 compatible). I don't have a dog in the race, but: Having written a python2.x/3.x compatible code it's not very hard as long as you don't have to support python 2.5 or 3.0 - 3.1 argparse is available from 2.7 and 3.1, which is the best way to work, and is available as a pip installable module for 2.6. Honestly at this point for a new project trying to support anything 2.7 is silly, so it should be pretty simple. All that said, I think that leaving it in C makes more sense. I think that the cython or cffi code to plug the two together would be more complex than the pure c code would be. Dylan signature.asc Description: Digital signature ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
On 02/20/2015 01:49 PM, Jordan Justen wrote: On 2015-02-20 12:58:07, Chad Versace wrote: On 02/17/2015 11:30 PM, Jordan Justen wrote: For the sake of apps who want to dump the info to a log file or to the console and get on with their lives, I think the default output format should be a single, giant string. But, as we're discovering in this conversation, a single giant string might not be appropriate as a one-size-fits-all format. I believe we can have it both ways, though, by adding some optional parameters to the API. void* waffle_display_get_info(struct waffle_display *dpy, enum waffle_display_info_format format, uint32_t flags); Then we have the ability to define API like this: // Returns a single, string suitable for log output. The return value // must be cast to `char*`. One valid flag is currently defined for this // format, WAFFLE_DISPLAY_INFO_VERBOSE_BIT. waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_SIMPLE, 0) // Returns Jordan array of strings. The return value must be cast to `char**`. // One valid flag is currently defined for this format, // WAFFLE_DISPLAY_INFO_VERBOSE_BIT. waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_JORDAN, 0); // Returns a JSON string. The return valud must be cast to `char*`. Two // flags are currently defined for this format: WAFFLE_DISPLAY_INFO_VERBOSE_BIT // and WAFFLE_DISPLAY_INFO_INDENT_BIT. waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_JSON, 0); Of course, the simple and jordan formats will be the first ones implemented. People can implement other formats in the future. (The JSON format, I'm just using that as a hypothetical example.) Do you think this is a good compromise between usability and extensibility? Does my proposal lack some important knob you think is needed? Or is my proposal just overall a bad idea? My idea was just to define a one-time API that left presentation of the strings to the user of the library. Therefore, the Core API wouldn't ever need to change past that point. It was also an attempt to make it fairly easy to iterate through the results. One example of trouble we might get into could be WAFFLE_DISPLAY_INFO_FORMAT_GLXINFO. Meaning we try to comma separate and break lines. Except, we wouldn't know the best line length to use for breaking lines. In that case it more likely the application could best format it. (Assuming it was able to read the console text resolution.) But, I have to admit, your idea probably would be pretty helpful to some applications. For example, JSON would probably be used by piglit. Assuming you don't think the string pointers output is too horribly complex to document, then this seems like a good set to consider: * WAFFLE_DISPLAY_INFO_FORMAT_STRING_POINTERS * WAFFLE_DISPLAY_INFO_FORMAT_TEXT * WAFFLE_DISPLAY_INFO_FORMAT_JSON * WAFFLE_DISPLAY_INFO_FORMAT_XML * WAFFLE_DISPLAY_INFO_FORMAT_CSV (Eh, I'm not sure I like this one.) The last 4 would be easy to implement based on the first. This set seems like enough where we could avoid the need to add any more formats. That set looks good to me, except for CSV. I don't like CSV. The name STRING_POINTERS is clunky, but I can't think of a better alternative. For a first pass, I think we should implement STRING_POINTERS and TEXT. Then, soon after that, JSON. I consider XML a nice-to-have right now, just because I don't want to think about schema versioning. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
On 2015-02-20 12:58:07, Chad Versace wrote: On 02/17/2015 11:30 PM, Jordan Justen wrote: On 2015-02-10 12:09:05, Chad Versace wrote: I prefer core too. Not for the sake of less code, but because I like the idea of it being available as core API. This surprised me a bit. I wouldn't think of the waffle library wanting to embed a bunch of strings to fulfill such an API. Embedding string? I don't understand. Your proposal needs embedded strings too: the strings for the key values. If Waffle provides the display info in one big string or in a sequence of little strings, as you propose, the same key strings need to be embedded into the library. Am I missing something? You are correct. While, I was somewhat surpised about adding it to the waffle API, my idea was not an attempt to limit the string or code data added to waffle library to support this. It was just a discussion of what a good API might look like if we did add it. Anyway... how about this: char** waffle_display_info_strings(struct waffle_display *self, bool verbose); The returned array of strings could have this property: First look for a key string pointer. If it is NULL, then you are done. If you find non-NULL key string pointer then search for 0 or more non-NULL value string pointers. When a NULL pointer is seen, go back to looking for a key string pointer. I've attached an example program that sort of emulates wflinfo... This would allow the consumer to use comma separation and/or line breaks as desired. For the sake of apps who want to dump the info to a log file or to the console and get on with their lives, I think the default output format should be a single, giant string. But, as we're discovering in this conversation, a single giant string might not be appropriate as a one-size-fits-all format. I believe we can have it both ways, though, by adding some optional parameters to the API. void* waffle_display_get_info(struct waffle_display *dpy, enum waffle_display_info_format format, uint32_t flags); Then we have the ability to define API like this: // Returns a single, string suitable for log output. The return value // must be cast to `char*`. One valid flag is currently defined for this // format, WAFFLE_DISPLAY_INFO_VERBOSE_BIT. waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_SIMPLE, 0) // Returns Jordan array of strings. The return value must be cast to `char**`. // One valid flag is currently defined for this format, // WAFFLE_DISPLAY_INFO_VERBOSE_BIT. waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_JORDAN, 0); // Returns a JSON string. The return valud must be cast to `char*`. Two // flags are currently defined for this format: WAFFLE_DISPLAY_INFO_VERBOSE_BIT // and WAFFLE_DISPLAY_INFO_INDENT_BIT. waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_JSON, 0); Of course, the simple and jordan formats will be the first ones implemented. People can implement other formats in the future. (The JSON format, I'm just using that as a hypothetical example.) Do you think this is a good compromise between usability and extensibility? Does my proposal lack some important knob you think is needed? Or is my proposal just overall a bad idea? My idea was just to define a one-time API that left presentation of the strings to the user of the library. Therefore, the Core API wouldn't ever need to change past that point. It was also an attempt to make it fairly easy to iterate through the results. One example of trouble we might get into could be WAFFLE_DISPLAY_INFO_FORMAT_GLXINFO. Meaning we try to comma separate and break lines. Except, we wouldn't know the best line length to use for breaking lines. In that case it more likely the application could best format it. (Assuming it was able to read the console text resolution.) But, I have to admit, your idea probably would be pretty helpful to some applications. For example, JSON would probably be used by piglit. Assuming you don't think the string pointers output is too horribly complex to document, then this seems like a good set to consider: * WAFFLE_DISPLAY_INFO_FORMAT_STRING_POINTERS * WAFFLE_DISPLAY_INFO_FORMAT_TEXT * WAFFLE_DISPLAY_INFO_FORMAT_JSON * WAFFLE_DISPLAY_INFO_FORMAT_XML * WAFFLE_DISPLAY_INFO_FORMAT_CSV (Eh, I'm not sure I like this one.) The last 4 would be easy to implement based on the first. This set seems like enough where we could avoid the need to add any more formats. -Jordan ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
On 02/17/2015 11:30 PM, Jordan Justen wrote: On 2015-02-10 12:09:05, Chad Versace wrote: On Sun, Feb 08, 2015 at 07:50:15PM -0500, Frank Henigman wrote: I'd like to extend wflinfo so it can print platform-specific information and eventually be able to replace glxinfo, eglinfo and the like (I only know what's on linux). There would be a new flag to request the platform-specific output in addition to the existing output. For example on glx you'd see glx extensions, on egl you'd see egl extensions. I've started two different implementations and I'd like to know which is preferred before I go any farther. Or if there's a better idea than either of my approaches. I've dubbed the two approaches native and core. native - all the work is done in wflinfo, no changes to waffle api - use waffle_display_get_native() to access platform-specific stuff - pro: changes limited to wflinfo, doesn't clutter up the rest of waffle - con: some duplicate code to open libraries and lookup symbols - https://github.com/fjhenigman/waffle/tree/ps_native core - add waffle_display_print_info() to waffle api - add print_info() method to each platform - pro: less code, no duplication - con (perhaps): some wflinfo functionality is now in core waffle - https://github.com/fjhenigman/waffle/tree/ps_core I'm leaning toward core because there is less code. We get to leverage the platform libraries and functions already stored in waffle platform structs. But if the consensus is it's cleaner to keep this stuff in wflinfo I'm ok with that too. I prefer core too. Not for the sake of less code, but because I like the idea of it being available as core API. This surprised me a bit. I wouldn't think of the waffle library wanting to embed a bunch of strings to fulfill such an API. Embedding string? I don't understand. Your proposal needs embedded strings too: the strings for the key values. If Waffle provides the display info in one big string or in a sequence of little strings, as you propose, the same key strings need to be embedded into the library. Am I missing something? Anyway... how about this: char** waffle_display_info_strings(struct waffle_display *self, bool verbose); The returned array of strings could have this property: First look for a key string pointer. If it is NULL, then you are done. If you find non-NULL key string pointer then search for 0 or more non-NULL value string pointers. When a NULL pointer is seen, go back to looking for a key string pointer. I've attached an example program that sort of emulates wflinfo... This would allow the consumer to use comma separation and/or line breaks as desired. For the sake of apps who want to dump the info to a log file or to the console and get on with their lives, I think the default output format should be a single, giant string. But, as we're discovering in this conversation, a single giant string might not be appropriate as a one-size-fits-all format. I believe we can have it both ways, though, by adding some optional parameters to the API. void* waffle_display_get_info(struct waffle_display *dpy, enum waffle_display_info_format format, uint32_t flags); Then we have the ability to define API like this: // Returns a single, string suitable for log output. The return value // must be cast to `char*`. One valid flag is currently defined for this // format, WAFFLE_DISPLAY_INFO_VERBOSE_BIT. waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_SIMPLE, 0) // Returns Jordan array of strings. The return value must be cast to `char**`. // One valid flag is currently defined for this format, // WAFFLE_DISPLAY_INFO_VERBOSE_BIT. waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_JORDAN, 0); // Returns a JSON string. The return valud must be cast to `char*`. Two // flags are currently defined for this format: WAFFLE_DISPLAY_INFO_VERBOSE_BIT // and WAFFLE_DISPLAY_INFO_INDENT_BIT. waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_JSON, 0); Of course, the simple and jordan formats will be the first ones implemented. People can implement other formats in the future. (The JSON format, I'm just using that as a hypothetical example.) Do you think this is a good compromise between usability and extensibility? Does my proposal lack some important knob you think is needed? Or is my proposal just overall a bad idea? signature.asc Description: OpenPGP digital signature ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
I don't know how I missed this, I don't care if the output is character for character with glxinfo, as long as it conveys the same information. On Wed, Feb 11, 2015 at 06:01:26PM -0800, Chad Versace wrote: On 02/10/2015 01:20 PM, Frank Henigman wrote: On Tue, Feb 10, 2015 at 4:08 PM, Frank Henigman fjhenig...@google.com wrote: Looks like Issue #3 is the format of the information. I thought it was given we should duplicate existing glxinfo/eglinfo/etc as closely as possible, in order to be a drop-in replacement, but if I follow the suggestions Chad made on github (https://github.com/fjhenigman/waffle/commit/d0b45bb9850e6ae29ee379a2d3e8ba14afc1b872) we'll be diverging. Improving on existing tools is ok with me - I don't have a huge investment in code to parse their output - but I wonder if others feel differently. (+Jordan, +Dylan, questions below) Oh, when I made those Github comments, I didn't know you were trying to duplicate glxinfo output verbatim. Now I understand why the GLX lines look so different from wflinfo's current output. glxinfo wraps long lines for extension strings and separates extension names with commas. wflinfo intentionally prints extensions strings in their original form: single line, extension names separated by spaces. If I recall correctly, Jordan and Dylan wanted that format so that consumers who parsed wflinfo text output would be guaranteed a stable format. If wflinfo has mixed line formats (some lines are comma-separated and wrapped, some are space-separated), I fear that may cause problems for already-existing consumers. Dylan, Jordan, do you have an opinion here? Does this really matter? signature.asc Description: Digital signature ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
On 17/02/15 19:18, Chad Versace wrote:
On 02/14/2015 09:22 AM, Emil Velikov wrote:
On 13 February 2015 at 02:22, Frank Henigman fjhenig...@google.com wrote:
On Thu, Feb 12, 2015 at 5:44 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 12 February 2015 at 02:01, Chad Versace chad.vers...@intel.com wrote:
On 02/10/2015 01:20 PM, Frank Henigman wrote:
On Tue, Feb 10, 2015 at 4:08 PM, Frank Henigman fjhenig...@google.com
wrote:
Looks like Issue #3 is the format of the information. I thought it
was given we should duplicate existing glxinfo/eglinfo/etc as closely
as possible, in order to be a drop-in replacement, but if I follow the
suggestions Chad made on github
(https://github.com/fjhenigman/waffle/commit/d0b45bb9850e6ae29ee379a2d3e8ba14afc1b872)
we'll be diverging. Improving on existing tools is ok with me - I
don't have a huge investment in code to parse their output - but I
wonder if others feel differently.
(+Jordan, +Dylan, questions below)
Oh, when I made those Github comments, I didn't know you were trying to
duplicate glxinfo output verbatim. Now I understand why the GLX lines
look so different from wflinfo's current output.
glxinfo wraps long lines for extension strings and separates extension
names with commas.
wflinfo intentionally prints extensions strings in their original form:
single line,
extension names separated by spaces. If I recall correctly, Jordan and
Dylan wanted
that format so that consumers who parsed wflinfo text output would be
guaranteed a stable
format.
If wflinfo has mixed line formats (some lines are comma-separated and
wrapped, some
are space-separated), I fear that may cause problems for already-existing
consumers.
Dylan, Jordan, do you have an opinion here? Does this really matter?
The above are some examples why I am doubtful about adding such
function in waffle.
One might want the extensions listed in alphabetic order, another to
have them one per line, another will likely be interested the client
extensions, or maybe the server ones, the GLX/CGL/WGL/EGL version only
?
Imho in order for one to get some flexibility I would opt for query
mechanism for issue 1.
Chad, genuine question, can you please describe how having a string is
more extensible ?
I'm sold on easy parsing and wflinfo compatibility over {glx,egl}info
compatibility. There's no reason we can't have everything actually.
The parameter I proposed could be used to select output format: match
glxinfo, match older wflinfo, latest and easiest-to-parse, etc.
I don't mean to answer for Chad, but the nice thing about returning a
string is we can tweak it without changing the api, and maybe without
breaking existing parsers (at least not badly). You could say this is
just a fuzzy and therefore useless kind of api, but that's glass half
empty thinking. (^:
I think a string is a good start. We can lock in the format(s) if and
when we choose, it in no way hinders later attempts at something
fancier, and it shouldn't be hard to keep the string for compatibility
after something fancier is available.
I never meant the above as this is a terrible idea, but more of it
might take a while to reach a consensus about the format, stability of
it, etc.. As long as people are ok that most/some of the points are
on the trivial side, I'm happy.
Just that I cannot shake away my gift of seeing the negative
effects/impact something might cause. Sorry if I went too crazy :-)
I think Frank explained the reasons well why exposing a string is
a flexible, (mostly) future proof API. At the risk of repeating him...
Exposing the info in an easily parseable string with a well-defined format
means that, whenever wflinfo wishes to exposes more info, Waffle doesn't
need to expose additional query API. We reduce API churn.
And any well-behaved consumer will ignore
fields it doesn't recognize during parsing. If we ever want to expose the info
in a fancier way (json, xml, wrapped-to-80-columns, whatever), all that's
needed is that Waffle expose a new enum token for that format, and the user
requests the format like waffle_display_print_info(format=json).
It's extensible because it allows the producer to produce new info that the
consumer does not recognize; and it allows the consumer to discard info
it doesn't want or doesn't understand.
I see my problem now - I'm picking too much on the well-defined format
and well-behaved consumer will ignore fields.
Please ignore my bikeshedding, my OCD seems to be kicking in :-P
-Emil
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
On 2015-02-10 12:09:05, Chad Versace wrote:
On Sun, Feb 08, 2015 at 07:50:15PM -0500, Frank Henigman wrote:
I'd like to extend wflinfo so it can print platform-specific
information and eventually be able to replace glxinfo, eglinfo and the
like (I only know what's on linux). There would be a new flag to
request the platform-specific output in addition to the existing
output. For example on glx you'd see glx extensions, on egl you'd see
egl extensions.
I've started two different implementations and I'd like to know which
is preferred before I go any farther. Or if there's a better idea
than either of my approaches. I've dubbed the two approaches native
and core.
native
- all the work is done in wflinfo, no changes to waffle api
- use waffle_display_get_native() to access platform-specific stuff
- pro: changes limited to wflinfo, doesn't clutter up the rest of waffle
- con: some duplicate code to open libraries and lookup symbols
- https://github.com/fjhenigman/waffle/tree/ps_native
core
- add waffle_display_print_info() to waffle api
- add print_info() method to each platform
- pro: less code, no duplication
- con (perhaps): some wflinfo functionality is now in core waffle
- https://github.com/fjhenigman/waffle/tree/ps_core
I'm leaning toward core because there is less code. We get to
leverage the platform libraries and functions already stored in waffle
platform structs. But if the consensus is it's cleaner to keep this
stuff in wflinfo I'm ok with that too.
I prefer core too. Not for the sake of less code, but because I like
the idea of it being available as core API.
This surprised me a bit. I wouldn't think of the waffle library
wanting to embed a bunch of strings to fulfill such an API.
Anyway... how about this:
char**
waffle_display_info_strings(struct waffle_display *self, bool verbose);
The returned array of strings could have this property:
First look for a key string pointer. If it is NULL, then you are done.
If you find non-NULL key string pointer then search for 0 or more
non-NULL value string pointers. When a NULL pointer is seen, go back
to looking for a key string pointer.
I've attached an example program that sort of emulates wflinfo...
This would allow the consumer to use comma separation and/or line
breaks as desired.
-Jordan
#include stdio.h
#include stdlib.h
#include stdbool.h
#include string.h
/* Prints:
*
* key0:
* key1: value1
* key2: value2.0 value2.1
*/
struct waffle_display {
void *for_example_purposes;
};
char**
waffle_display_info_strings(struct waffle_display *self, bool verbose)
{
static char *strings[] = {
key0,
NULL, /* No value items */
key1,
value1,
NULL, /* One value item */
key2,
value2.0,
value2.1,
NULL, /* Two value items */
NULL /* End of strings */
};
char **retval = malloc(sizeof strings);
memcpy(retval, strings, sizeof strings);
return retval;
}
void
emulate_wflinfo(struct waffle_display *dpy)
{
char **strings, **pos;
strings = waffle_display_info_strings(dpy, true);
/* maybe this indicates an error? */
if (strings == NULL)
return;
for (pos = strings; *pos != NULL;) {
/* first string pointer is a key */
printf(%s:, *pos++);
/* followed by 0 or more value strings associated with the key */
for (;;) {
char *value = *pos++;
if (value == NULL) {
printf(\n);
break;
} else {
printf( %s, value);
}
}
}
/* the entire set of string pointers and string data can be
* freed together
*/
free(strings);
}
int
main(int argc, char **argv)
{
emulate_wflinfo(NULL);
}
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
On 13 February 2015 at 02:22, Frank Henigman fjhenig...@google.com wrote:
On Thu, Feb 12, 2015 at 5:44 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 12 February 2015 at 02:01, Chad Versace chad.vers...@intel.com wrote:
On 02/10/2015 01:20 PM, Frank Henigman wrote:
On Tue, Feb 10, 2015 at 4:08 PM, Frank Henigman fjhenig...@google.com
wrote:
Looks like Issue #3 is the format of the information. I thought it
was given we should duplicate existing glxinfo/eglinfo/etc as closely
as possible, in order to be a drop-in replacement, but if I follow the
suggestions Chad made on github
(https://github.com/fjhenigman/waffle/commit/d0b45bb9850e6ae29ee379a2d3e8ba14afc1b872)
we'll be diverging. Improving on existing tools is ok with me - I
don't have a huge investment in code to parse their output - but I
wonder if others feel differently.
(+Jordan, +Dylan, questions below)
Oh, when I made those Github comments, I didn't know you were trying to
duplicate glxinfo output verbatim. Now I understand why the GLX lines
look so different from wflinfo's current output.
glxinfo wraps long lines for extension strings and separates extension
names with commas.
wflinfo intentionally prints extensions strings in their original form:
single line,
extension names separated by spaces. If I recall correctly, Jordan and
Dylan wanted
that format so that consumers who parsed wflinfo text output would be
guaranteed a stable
format.
If wflinfo has mixed line formats (some lines are comma-separated and
wrapped, some
are space-separated), I fear that may cause problems for already-existing
consumers.
Dylan, Jordan, do you have an opinion here? Does this really matter?
The above are some examples why I am doubtful about adding such
function in waffle.
One might want the extensions listed in alphabetic order, another to
have them one per line, another will likely be interested the client
extensions, or maybe the server ones, the GLX/CGL/WGL/EGL version only
?
Imho in order for one to get some flexibility I would opt for query
mechanism for issue 1.
Chad, genuine question, can you please describe how having a string is
more extensible ?
Thanks
Emil
I'm sold on easy parsing and wflinfo compatibility over {glx,egl}info
compatibility. There's no reason we can't have everything actually.
The parameter I proposed could be used to select output format: match
glxinfo, match older wflinfo, latest and easiest-to-parse, etc.
I don't mean to answer for Chad, but the nice thing about returning a
string is we can tweak it without changing the api, and maybe without
breaking existing parsers (at least not badly). You could say this is
just a fuzzy and therefore useless kind of api, but that's glass half
empty thinking. (^:
I think a string is a good start. We can lock in the format(s) if and
when we choose, it in no way hinders later attempts at something
fancier, and it shouldn't be hard to keep the string for compatibility
after something fancier is available.
I never meant the above as this is a terrible idea, but more of it
might take a while to reach a consensus about the format, stability of
it, etc.. As long as people are ok that most/some of the points are
on the trivial side, I'm happy.
Just that I cannot shake away my gift of seeing the negative
effects/impact something might cause. Sorry if I went too crazy :-)
-Emil
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
On 12 February 2015 at 02:01, Chad Versace chad.vers...@intel.com wrote: On 02/10/2015 01:20 PM, Frank Henigman wrote: On Tue, Feb 10, 2015 at 4:08 PM, Frank Henigman fjhenig...@google.com wrote: Looks like Issue #3 is the format of the information. I thought it was given we should duplicate existing glxinfo/eglinfo/etc as closely as possible, in order to be a drop-in replacement, but if I follow the suggestions Chad made on github (https://github.com/fjhenigman/waffle/commit/d0b45bb9850e6ae29ee379a2d3e8ba14afc1b872) we'll be diverging. Improving on existing tools is ok with me - I don't have a huge investment in code to parse their output - but I wonder if others feel differently. (+Jordan, +Dylan, questions below) Oh, when I made those Github comments, I didn't know you were trying to duplicate glxinfo output verbatim. Now I understand why the GLX lines look so different from wflinfo's current output. glxinfo wraps long lines for extension strings and separates extension names with commas. wflinfo intentionally prints extensions strings in their original form: single line, extension names separated by spaces. If I recall correctly, Jordan and Dylan wanted that format so that consumers who parsed wflinfo text output would be guaranteed a stable format. If wflinfo has mixed line formats (some lines are comma-separated and wrapped, some are space-separated), I fear that may cause problems for already-existing consumers. Dylan, Jordan, do you have an opinion here? Does this really matter? The above are some examples why I am doubtful about adding such function in waffle. One might want the extensions listed in alphabetic order, another to have them one per line, another will likely be interested the client extensions, or maybe the server ones, the GLX/CGL/WGL/EGL version only ? Imho in order for one to get some flexibility I would opt for query mechanism for issue 1. Chad, genuine question, can you please describe how having a string is more extensible ? Thanks Emil ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
On Thu, Feb 12, 2015 at 5:44 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 12 February 2015 at 02:01, Chad Versace chad.vers...@intel.com wrote:
On 02/10/2015 01:20 PM, Frank Henigman wrote:
On Tue, Feb 10, 2015 at 4:08 PM, Frank Henigman fjhenig...@google.com
wrote:
Looks like Issue #3 is the format of the information. I thought it
was given we should duplicate existing glxinfo/eglinfo/etc as closely
as possible, in order to be a drop-in replacement, but if I follow the
suggestions Chad made on github
(https://github.com/fjhenigman/waffle/commit/d0b45bb9850e6ae29ee379a2d3e8ba14afc1b872)
we'll be diverging. Improving on existing tools is ok with me - I
don't have a huge investment in code to parse their output - but I
wonder if others feel differently.
(+Jordan, +Dylan, questions below)
Oh, when I made those Github comments, I didn't know you were trying to
duplicate glxinfo output verbatim. Now I understand why the GLX lines
look so different from wflinfo's current output.
glxinfo wraps long lines for extension strings and separates extension names
with commas.
wflinfo intentionally prints extensions strings in their original form:
single line,
extension names separated by spaces. If I recall correctly, Jordan and Dylan
wanted
that format so that consumers who parsed wflinfo text output would be
guaranteed a stable
format.
If wflinfo has mixed line formats (some lines are comma-separated and
wrapped, some
are space-separated), I fear that may cause problems for already-existing
consumers.
Dylan, Jordan, do you have an opinion here? Does this really matter?
The above are some examples why I am doubtful about adding such
function in waffle.
One might want the extensions listed in alphabetic order, another to
have them one per line, another will likely be interested the client
extensions, or maybe the server ones, the GLX/CGL/WGL/EGL version only
?
Imho in order for one to get some flexibility I would opt for query
mechanism for issue 1.
Chad, genuine question, can you please describe how having a string is
more extensible ?
Thanks
Emil
I'm sold on easy parsing and wflinfo compatibility over {glx,egl}info
compatibility. There's no reason we can't have everything actually.
The parameter I proposed could be used to select output format: match
glxinfo, match older wflinfo, latest and easiest-to-parse, etc.
I don't mean to answer for Chad, but the nice thing about returning a
string is we can tweak it without changing the api, and maybe without
breaking existing parsers (at least not badly). You could say this is
just a fuzzy and therefore useless kind of api, but that's glass half
empty thinking. (^:
I think a string is a good start. We can lock in the format(s) if and
when we choose, it in no way hinders later attempts at something
fancier, and it shouldn't be hard to keep the string for compatibility
after something fancier is available.
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
On 02/10/2015 01:20 PM, Frank Henigman wrote: On Tue, Feb 10, 2015 at 4:08 PM, Frank Henigman fjhenig...@google.com wrote: Looks like Issue #3 is the format of the information. I thought it was given we should duplicate existing glxinfo/eglinfo/etc as closely as possible, in order to be a drop-in replacement, but if I follow the suggestions Chad made on github (https://github.com/fjhenigman/waffle/commit/d0b45bb9850e6ae29ee379a2d3e8ba14afc1b872) we'll be diverging. Improving on existing tools is ok with me - I don't have a huge investment in code to parse their output - but I wonder if others feel differently. (+Jordan, +Dylan, questions below) Oh, when I made those Github comments, I didn't know you were trying to duplicate glxinfo output verbatim. Now I understand why the GLX lines look so different from wflinfo's current output. glxinfo wraps long lines for extension strings and separates extension names with commas. wflinfo intentionally prints extensions strings in their original form: single line, extension names separated by spaces. If I recall correctly, Jordan and Dylan wanted that format so that consumers who parsed wflinfo text output would be guaranteed a stable format. If wflinfo has mixed line formats (some lines are comma-separated and wrapped, some are space-separated), I fear that may cause problems for already-existing consumers. Dylan, Jordan, do you have an opinion here? Does this really matter? signature.asc Description: OpenPGP digital signature ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
On 2015-02-11 18:01:26, Chad Versace wrote: On 02/10/2015 01:20 PM, Frank Henigman wrote: On Tue, Feb 10, 2015 at 4:08 PM, Frank Henigman fjhenig...@google.com wrote: Looks like Issue #3 is the format of the information. I thought it was given we should duplicate existing glxinfo/eglinfo/etc as closely as possible, in order to be a drop-in replacement I don't think this is a goal of wflinfo. I think a goal of wflinfo would be to provide all the same information as glxinfo (but, mostly only in verbose mode), but I don't think it is a goal to match the output format of glxinfo. , but if I follow the suggestions Chad made on github (https://github.com/fjhenigman/waffle/commit/d0b45bb9850e6ae29ee379a2d3e8ba14afc1b872) we'll be diverging. Improving on existing tools is ok with me - I don't have a huge investment in code to parse their output - but I wonder if others feel differently. (+Jordan, +Dylan, questions below) Oh, when I made those Github comments, I didn't know you were trying to duplicate glxinfo output verbatim. Now I understand why the GLX lines look so different from wflinfo's current output. glxinfo wraps long lines for extension strings and separates extension names with commas. wflinfo intentionally prints extensions strings in their original form: single line, extension names separated by spaces. If I recall correctly, Jordan and Dylan wanted that format so that consumers who parsed wflinfo text output would be guaranteed a stable format. If wflinfo has mixed line formats (some lines are comma-separated and wrapped, some are space-separated), I fear that may cause problems for already-existing consumers. Dylan, Jordan, do you have an opinion here? Does this really matter? I think you are right, and for consistency we should avoid adding comma separation to values. But, I think more importantly we wanted to have each line of output follow a 'Field: Value' format. Field obviously can't contain the ':' character, and we decided that Value should not contain line breaks. -Jordan ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
On Tue, Feb 10, 2015 at 3:09 PM, Chad Versace chad.vers...@intel.com wrote: On 02/10/2015 10:31 AM, Dylan Baker wrote: I like this idea, it would be convenient for piglit to be able to assume waffle info can provide all of the information we currently call out to multiple binaries for. Yes, Piglit wants this. I imagine more users will begin using it too. On Sun, Feb 08, 2015 at 07:50:15PM -0500, Frank Henigman wrote: I'd like to extend wflinfo so it can print platform-specific information and eventually be able to replace glxinfo, eglinfo and the like (I only know what's on linux). There would be a new flag to request the platform-specific output in addition to the existing output. For example on glx you'd see glx extensions, on egl you'd see egl extensions. I've started two different implementations and I'd like to know which is preferred before I go any farther. Or if there's a better idea than either of my approaches. I've dubbed the two approaches native and core. native - all the work is done in wflinfo, no changes to waffle api - use waffle_display_get_native() to access platform-specific stuff - pro: changes limited to wflinfo, doesn't clutter up the rest of waffle - con: some duplicate code to open libraries and lookup symbols - https://github.com/fjhenigman/waffle/tree/ps_native core - add waffle_display_print_info() to waffle api - add print_info() method to each platform - pro: less code, no duplication - con (perhaps): some wflinfo functionality is now in core waffle - https://github.com/fjhenigman/waffle/tree/ps_core I'm leaning toward core because there is less code. We get to leverage the platform libraries and functions already stored in waffle platform structs. But if the consensus is it's cleaner to keep this stuff in wflinfo I'm ok with that too. I prefer core too. Not for the sake of less code, but because I like the idea of it being available as core API. I've begun adding Github comments to your ps_core branch. We can do review Github-style, if you like. If you send patches to the list, that's ok too. Thanks for feedback. From here on I'll send patch sets to the list. I'll incorporate any github suggestions in the first such set. I see two significant design decisions that need to be made: Issue #1: Should Waffle provide a query mechanism for the native platform info? Or should it just dump the info as a well-formatted string? Resolved: I like the way that your waffle_display_print_info() just dumps the information as a string. That's much simpler and more extensible than a true query mechanism. Issue #2: How should Waffle give that information string to the user? I think hardcoding stdout as the destination for the information is too restrictive. A very simple alternative would be that waffle_display_print_info() return a C-string that the user is required to free. Or perhaps the user should pass a string buffer and max length to waffle_display_print_info(), similar to snprintf(). Or maybe something completely different. What do you think is the best approach? Returning a string. If the user has to supply a buffer they won't know how big it needs to be. I think the function will want an enum or bitmask parameter for controlling, for example, verbosity. If we ever want a fancy query interface that returns structs instead of a string, we'll be able to re-implement the string-returning function over that interface for backward compatibility. I suggest calling this one waffle_display_info_string() instead of taking a name we might want to use later, like waffle_display_info or waffle_display_query. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
On 02/10/2015 10:31 AM, Dylan Baker wrote: I like this idea, it would be convenient for piglit to be able to assume waffle info can provide all of the information we currently call out to multiple binaries for. Yes, Piglit wants this. I imagine more users will begin using it too. On Sun, Feb 08, 2015 at 07:50:15PM -0500, Frank Henigman wrote: I'd like to extend wflinfo so it can print platform-specific information and eventually be able to replace glxinfo, eglinfo and the like (I only know what's on linux). There would be a new flag to request the platform-specific output in addition to the existing output. For example on glx you'd see glx extensions, on egl you'd see egl extensions. I've started two different implementations and I'd like to know which is preferred before I go any farther. Or if there's a better idea than either of my approaches. I've dubbed the two approaches native and core. native - all the work is done in wflinfo, no changes to waffle api - use waffle_display_get_native() to access platform-specific stuff - pro: changes limited to wflinfo, doesn't clutter up the rest of waffle - con: some duplicate code to open libraries and lookup symbols - https://github.com/fjhenigman/waffle/tree/ps_native core - add waffle_display_print_info() to waffle api - add print_info() method to each platform - pro: less code, no duplication - con (perhaps): some wflinfo functionality is now in core waffle - https://github.com/fjhenigman/waffle/tree/ps_core I'm leaning toward core because there is less code. We get to leverage the platform libraries and functions already stored in waffle platform structs. But if the consensus is it's cleaner to keep this stuff in wflinfo I'm ok with that too. I prefer core too. Not for the sake of less code, but because I like the idea of it being available as core API. I've begun adding Github comments to your ps_core branch. We can do review Github-style, if you like. If you send patches to the list, that's ok too. I see two significant design decisions that need to be made: Issue #1: Should Waffle provide a query mechanism for the native platform info? Or should it just dump the info as a well-formatted string? Resolved: I like the way that your waffle_display_print_info() just dumps the information as a string. That's much simpler and more extensible than a true query mechanism. Issue #2: How should Waffle give that information string to the user? I think hardcoding stdout as the destination for the information is too restrictive. A very simple alternative would be that waffle_display_print_info() return a C-string that the user is required to free. Or perhaps the user should pass a string buffer and max length to waffle_display_print_info(), similar to snprintf(). Or maybe something completely different. What do you think is the best approach? signature.asc Description: OpenPGP digital signature ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
On 02/08/2015 04:50 PM, Frank Henigman wrote: I'd like to extend wflinfo so it can print platform-specific information and eventually be able to replace glxinfo, eglinfo and the like (I only know what's on linux). There would be a new flag to request the platform-specific output in addition to the existing output. For example on glx you'd see glx extensions, on egl you'd see egl extensions. For anyone who would like to experiment with Frank's work, I've created a throw-away 'pu' branch (proposed updates) and merged Frank's 'ps_core' branch there. The 'pu' branch isn't stable and may be rewritten at any time. signature.asc Description: OpenPGP digital signature ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
On 02/10/2015 01:08 PM, Frank Henigman wrote: On Tue, Feb 10, 2015 at 3:09 PM, Chad Versace chad.vers...@intel.com wrote: I see two significant design decisions that need to be made: Issue #1: Should Waffle provide a query mechanism for the native platform info? Or should it just dump the info as a well-formatted string? Resolved: I like the way that your waffle_display_print_info() just dumps the information as a string. That's much simpler and more extensible than a true query mechanism. Issue #2: How should Waffle give that information string to the user? I think hardcoding stdout as the destination for the information is too restrictive. A very simple alternative would be that waffle_display_print_info() return a C-string that the user is required to free. Or perhaps the user should pass a string buffer and max length to waffle_display_print_info(), similar to snprintf(). Or maybe something completely different. What do you think is the best approach? Returning a string. If the user has to supply a buffer they won't know how big it needs to be. I think the function will want an enum or bitmask parameter for controlling, for example, verbosity. If we ever want a fancy query interface that returns structs instead of a string, we'll be able to re-implement the string-returning function over that interface for backward compatibility. I suggest calling this one waffle_display_info_string() instead of taking a name we might want to use later, like waffle_display_info or waffle_display_query. This all sounds good to me. signature.asc Description: OpenPGP digital signature ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
