Bernd Schmidt writes:
> On 05/25/2014 11:35 AM, Richard Sandiford wrote:
>> Bernd Schmidt writes:
>>> On 02/13/2014 10:18 AM, Richard Sandiford wrote:
contrib/
* dg-extract-results.py: New file.
* dg-extract-results.sh: Use it if the environment seems suitable.
>>>
>>> I'm no
On Jun 12, 2014, at 8:53 AM, Bernd Schmidt wrote:
> I've recently been trying to add ada to my set of tested languages, and I now
> encounter the following:
>
> File "../../git/gcc/../contrib/dg-extract-results.py", line 242, in parse_run
>line = file.readline()
> File "/usr/lib64/python3.
On 05/25/2014 11:35 AM, Richard Sandiford wrote:
Bernd Schmidt writes:
On 02/13/2014 10:18 AM, Richard Sandiford wrote:
contrib/
* dg-extract-results.py: New file.
* dg-extract-results.sh: Use it if the environment seems suitable.
I'm now seeing the following:
Traceback (mos
Bernd Schmidt writes:
> On 02/13/2014 10:18 AM, Richard Sandiford wrote:
>> contrib/
>> * dg-extract-results.py: New file.
>> * dg-extract-results.sh: Use it if the environment seems suitable.
>
> I'm now seeing the following:
>
> Traceback (most recent call last):
>File "../../git/g
On Sat, May 24, 2014 at 10:14:54AM -0700, Mike Stump wrote:
> On May 24, 2014, at 4:17 AM, Bernd Schmidt wrote:
> > On 02/13/2014 10:18 AM, Richard Sandiford wrote:
> >> contrib/
> >>* dg-extract-results.py: New file.
> >>* dg-extract-results.sh: Use it if the environment seems suitable.
>
On May 24, 2014, at 4:17 AM, Bernd Schmidt wrote:
> On 02/13/2014 10:18 AM, Richard Sandiford wrote:
>> contrib/
>> * dg-extract-results.py: New file.
>> * dg-extract-results.sh: Use it if the environment seems suitable.
>
> I'm now seeing the following:
>
> Traceback (most recent call
On 02/13/2014 10:18 AM, Richard Sandiford wrote:
contrib/
* dg-extract-results.py: New file.
* dg-extract-results.sh: Use it if the environment seems suitable.
I'm now seeing the following:
Traceback (most recent call last):
File "../../git/gcc/../contrib/dg-extract-results.p
Charles Baylis writes:
> On 19 May 2014 19:07, Richard Sandiford wrote:
>>
>> Sorry for the breakage. I wanted to make the script as picky as I could
>> get away with though, so that results aren't lost accidentally.
>>
>> Could you try the attached?
>
> That works for me.
Thanks. I also teste
On 19 May 2014 19:07, Richard Sandiford wrote:
>
> Sorry for the breakage. I wanted to make the script as picky as I could
> get away with though, so that results aren't lost accidentally.
>
> Could you try the attached?
That works for me.
Thanks for looking into it.
Charles Baylis writes:
> On 13 February 2014 09:18, Richard Sandiford
> wrote:
>> This patch tries to reduce that by providing an alternative single-script
>> version. I was torn between Python and Tcl, but given how most people
>> tend to react to Tcl, I thought I'd better go for Python. I wo
Jakub Jelinek writes:
> On Sat, May 03, 2014 at 08:34:07AM +0100, Richard Sandiford wrote:
>> Ping for this old patch. I didn't ping it before because I can imagine
>> it wasn't a good idea at that stage in 4.8. But I've been using it locally
>> since and it really does make a big difference whe
On Sat, May 03, 2014 at 08:34:07AM +0100, Richard Sandiford wrote:
> Ping for this old patch. I didn't ping it before because I can imagine
> it wasn't a good idea at that stage in 4.8. But I've been using it locally
> since and it really does make a big difference when testing lots of
> multilib
On 05/05/14 12:14, Mike Stump wrote:
On May 5, 2014, at 9:08 AM, Jeff Law wrote:
It would mean a bit of pain for initial system bootstraps by the
distributors,
I don’t expect any pain there. System distributors usually have a
distribution for the last release that includes binaries for all,
On May 5, 2014, at 9:08 AM, Jeff Law wrote:
> It would mean a bit of pain for initial system bootstraps by the distributors,
I don’t expect any pain there. System distributors usually have a distribution
for the last release that includes binaries for all, including python, tcl and
gcc. They
On 02/13/14 02:18, Richard Sandiford wrote:
http://gcc.gnu.org/ml/gcc-testresults/2014-02/msg00025.html
the script takes just over 5 hours to produce the gcc.log file.
Good grief...
This patch tries to reduce that by providing an alternative single-script
version. I was torn between P
On Feb 13, 2014, at 1:18 AM, Richard Sandiford
wrote:
> This patch tries to reduce that by providing an alternative single-script
> version.
> Python isn't yet required and I'm pretty sure this script needs 2.6
> or later.
> I'm also worried that the seek/tell stuff might not work on
> Windows.
Ping for this old patch. I didn't ping it before because I can imagine
it wasn't a good idea at that stage in 4.8. But I've been using it locally
since and it really does make a big difference when testing lots of
multilibs.
Thanks,
Richard
Richard Sandiford writes:
> dg-extract-results.sh is
dg-extract-results.sh is used to combine the various .sum.sep and .log.sep
files produced by parallel testing into single .sum and .log files.
It's written in a combination of shell scripts and awk, so stays well
within the minimum system requirements.
However, it seems to be quadratic in the numb
18 matches
Mail list logo
