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

Kenneth Graunke kenneth at whitecape.org
Sun May 19 14:09:52 PDT 2013


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.

That's just one opinion though, perhaps other people have thoughts.

--Ken


More information about the Piglit mailing list