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