Prev: gfortran/ifort format issues in files
Next: Problem dynamically loading a library
From: dpb on 10 Jul 2010 13:39
Lynn McGuire wrote:
>> That's the kind of thing I was thinking about; just badly written...
>>
>> I think the option others have suggested of alternate compilers to produce warnings on at least some of these items would be
>> beneficial in the process rather than relying on the crashes to find them.
>
> I was thinking of a perl script to go through and init all local variable
> explicitely for all 5000 sibroutines. Kinda brute force but should get
> the job done.

If you're lucky and there really aren't any that actually do need their
values retained between invocations.

--
From: Louis Krupp on 10 Jul 2010 14:49
On 7/10/2010 10:50 AM, Lynn McGuire wrote:
>> That's the kind of thing I was thinking about; just badly written...
>>
>> I think the option others have suggested of alternate compilers to produce warnings on at least some of these items would be
>> beneficial in the process rather than relying on the crashes to find them.
>
> I was thinking of a perl script to go through and init all local variable
> explicitely for all 5000 sibroutines. Kinda brute force but should get
> the job done.

You might want to include some automated testing. Save the current
output in a file, change one subroutine, recompile, rerun, diff the
output with the original. If it looks good, rinse and repeat with
another subroutine, otherwise revert to the original subroutine source
and move on to the next one. Hopefully, you'll be left with n (where n
<< 5000) subroutines which will need some editing by hand.

Louis
From: Lynn McGuire on 10 Jul 2010 16:34
>> I was thinking of a perl script to go through and init all local variable
>> explicitely for all 5000 sibroutines. Kinda brute force but should get
>> the job done.
>
> You might want to include some automated testing. Save the current output in a file, change one subroutine, recompile, rerun,
> diff the output with the original. If it looks good, rinse and repeat with another subroutine, otherwise revert to the original
> subroutine source and move on to the next one. Hopefully, you'll be left with n (where n << 5000) subroutines which will need
> some editing by hand.

We have over 600 automated tests that we perform with our software
before we ship any full or patch releases. When you write and sell
commercial software, it is a given.

Thanks,
Lynn


From: Louis Krupp on 10 Jul 2010 21:03
On 7/10/2010 2:34 PM, Lynn McGuire wrote:
>>> I was thinking of a perl script to go through and init all local variable
>>> explicitely for all 5000 sibroutines. Kinda brute force but should get
>>> the job done.
>>
>> You might want to include some automated testing. Save the current output in a file, change one subroutine, recompile, rerun,
>> diff the output with the original. If it looks good, rinse and repeat with another subroutine, otherwise revert to the original
>> subroutine source and move on to the next one. Hopefully, you'll be left with n (where n<< 5000) subroutines which will need
>> some editing by hand.
>
> We have over 600 automated tests that we perform with our software
> before we ship any full or patch releases. When you write and sell
> commercial software, it is a given.
>
> Thanks,
> Lynn
>
>

You'd be surprised (or maybe not) at what gets shipped untested.

Now you get to build some or all of those tests into an automated
process to edit part of the source and retest. You could get fancy and
run complete tests only after editing every 100 subroutines or
something. Once you get it set up, you could start it just before you
go home for the day (or weekend) and let it do its thing...

Louis
From: Lynn McGuire on 12 Jul 2010 13:07
> You'd be surprised (or maybe not) at what gets shipped untested.

Not really. I've seen a lot in the commercial software arena.

> Now you get to build some or all of those tests into an automated process to edit part of the source and retest. You could get fancy
> and run complete tests only after editing every 100 subroutines or something. Once you get it set up, you could start it just before
> you go home for the day (or weekend) and let it do its thing...

It takes 72 hours to run our tests now. If nothing goes wrong.
And something almost always goes wrong <g>.

Lynn
First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: gfortran/ifort format issues in files
Next: Problem dynamically loading a library