Kenneth Graunke <[email protected]> writes: > On 05/19/2013 07:30 AM, Ken Phillis Jr wrote: >> On Sun, May 19, 2013 at 1:07 AM, Kenneth Graunke <[email protected]> >> 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.
pgpqn_2DNl3e3.pgp
Description: PGP signature
_______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
