[Piglit] [PATCH v2 04/11] piglit-summary-py: Use the new summary class to generate HTML

[Eric Anholt]

Kenneth Graunke <kenneth at whitecape.org> writes:

> On 05/19/2013 07:30 AM, Ken Phillis Jr wrote:
>> On Sun, May 19, 2013 at 1:07 AM, Kenneth Graunke <kenneth at whitecape.org> wrote:
>>> On 05/18/2013 09:35 PM, Dylan Baker wrote:
>>>>
>>>> My problem with the current list format is its too complex, and is
>>>> trying to solve nonexistent problems. There is no reason one should need
>>>> to rename the test results in the HTML summary. It's only going to lead
>>>> to headaches later on trying to identify what is actually in that column
>>>> "corrected name".
>>>>
>>>> I personally like either nothing, since it doesn't appear that is a
>>>> popular feature, or a simple space, coma, or new line separated list of
>>>> results files. Its clean, simple, and doesn't require much explanation.
>>>
>>>
>>> Personally, I see no value in the ability to load a list of results files.
>>> Specifying them on the command line works just fine.  I had assumed it was a
>>> newline or space separated list, but apparently it's something more
>>> complicated.  I don't even know the syntax, and I've been using Piglit for
>>> years...
>>>
>>> Does anybody even use that feature?
>>>
>>
>> Yes, I am actually one of the few users that use the list feature.
>
> Okay, cool, so someone does use it...
>
>> I also knew that the name override did not work. This probably was
>> broken during one of the many changes to the piglit python scripts. As
>> for reasons to use the override, It's mainly a convenience feature to
>> help prevent people from having problems opening up the large results
>> files that is produced during the quick-driver tests.
>>
>>> I also don't understand the need to rename the columns when specifying the
>>> result files.  If I want to rename a result (usually because I typo'd when
>>> doing piglit-run), I just edit the file and change the name...
>>>
>>> I'm not a fan of making this a fancy json syntax unless there's a real
>>> compelling use case.
>>
>> The compelling reason is that it is not exactly easy for a lot of
>> developers looking at getting into fixing bugs related to mesa that
>> appear in piglit may not be able to handle the text editors nor have
>> knowledge of the various text editors. I know that vi and nano can
>> handle the larger files without a problem, but most of the time novice
>> developers will open up the text file using the easier to handle x11
>> based editors that are included with the desktop environment. This
>> means that the text editors that are used will be gedit ( for gnome ),
>> pluma ( for mate desktop), and whatever else is used in the other text
>> editors. I have personally found that gedit (and pluma ) do not handle
>> the large json results files very well even on a modern machine with 2
>> gb (or more) of system memory
>
> Frankly, the fact that gedit has trouble with this is just plain 
> embarassing.  KDE's text editors (kwrite and kate) both handle these 
> files just fine...instantly available and ready to work with.
>
> I would file a bug against those text editors.  I don't think this is 
> something we should work around in Piglit.

We shouldn't be working around bad text editors in piglit.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20130522/5b8834c0/attachment.pgp>