From stdcxx-dev-return-4138-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org Thu Aug 02 22:54:13 2007 Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 53932 invoked from network); 2 Aug 2007 22:54:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Aug 2007 22:54:13 -0000 Received: (qmail 6778 invoked by uid 500); 2 Aug 2007 22:54:12 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 6764 invoked by uid 500); 2 Aug 2007 22:54:12 -0000 Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: stdcxx-dev@incubator.apache.org Delivered-To: mailing list stdcxx-dev@incubator.apache.org Received: (qmail 6753 invoked by uid 99); 2 Aug 2007 22:54:12 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Aug 2007 15:54:12 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [208.30.140.160] (HELO moroha.quovadx.com) (208.30.140.160) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Aug 2007 22:53:48 +0000 Received: from qxvcexch01.ad.quovadx.com ([192.168.170.59]) by moroha.quovadx.com (8.13.6/8.13.6) with ESMTP id l72MrjZ0014163 for ; Thu, 2 Aug 2007 22:53:45 GMT Received: from [10.70.3.113] ([10.70.3.113]) by qxvcexch01.ad.quovadx.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 16:53:35 -0600 Message-ID: <46B26094.1000307@roguewave.com> Date: Thu, 02 Aug 2007 16:54:12 -0600 From: Martin Sebor Organization: Rogue Wave Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 MIME-Version: 1.0 To: stdcxx-dev@incubator.apache.org Subject: Re: bulletproofing exec output References: <46AD0F69.6090706@roguewave.com> <46AE4C49.60909@roguewave.com> <46AE7431.8010806@roguewave.com> <46B25BE0.5010607@roguewave.com> In-Reply-To: <46B25BE0.5010607@roguewave.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Aug 2007 22:53:36.0046 (UTC) FILETIME=[F5775CE0:01C7D557] X-Virus-Checked: Checked by ClamAV on apache.org Andrew Black wrote: > Greetings Martin > > I suppose I should elaborate on the third option I put forward, in a > more general manner. One of the long-term plans for the exec utility, > as I understand it, was to allow for alternate output modes, such as an > 'interactive' mode, which would include such sugar as colored output and > run timeout countdown and the verbose output mode. Yes. I just implemented the (a) verbose mode. > > What I picture is a structure where an arbitrary set of output mode > files can be dropped into the bin directory and compiled into the exec > utility. It ideally would be possible for the makefiles to > automatically determine which files are output mode files, and each > output mode module would add itself to an internal list of mode modules > as part of the runtime initialization. A certain number of modules > would ship with stdcxx (including the default and verbose modes, along > with the 'interactive' mode after it's written), and end users would be > able to write other modules of their own devising, if they wished. > > With this structure, we would be able to write a module of our own, > designed for the nightly testing infrastructure, add it to the testing > source tree overlay, and specify that the exec utility should use the > new module, rather than the default output. That still doesn't help with the coupling problem. We need to come up with a format that makes scripts that parse it more resilient to changes we make to the format in the future. The ideal solution is for the script to dictate the exact format. A less than ideal one but possibly good enough is to make the format robust enough so that problems like the one we just ran into are unlikely to come up. FWIW, I don't think that relying on capitalization is the best approach. It's conceivable that someone will end up "uncapitalizing" the strings, or that someone adds a test in all caps, etc. But if we were to add some special header and footer tags (as a simpler variation on the command line option specifying the exact format of the output) it seems less likely that someone would remove those, especially if they were controlled via a command line option. Martin > > --Andrew Black > > Martin Sebor wrote: >> Andrew Black wrote: >> [snipped descriptive summary] >> ... >>> Looking at the output (as it stands now), I believe the parsers could be >>> more robust if they ignored all lines that started with whitespace or >>> where the first word was in all caps. Alternately, they could start >>> processing after the first line in all caps, and stop processing before >>> the second line in all caps. I suppose a third option would be to alter >>> the exec utility so it could produce the output desired, rather than >>> doing a post-processing step. Thoughts? >> IMO, since exec already has all the data the post-processing stage >> works so hard to compute it might as well write it out in a format >> that's easy to parse by the script you're talking about. I.e., the >> summary would be it. The other script that I was referring to is >> the cross build view generation script that actually needs the >> individual examples, locales, and tests, and doesn't care (yet) >> about the summary. >> >> So if take this approach we need to "standardize" both the output >> format for the individual programs as well as the summary. The >> summary format currently looks like this: >> > [snipped sample output and initial problem]