Re: amber-developers: Ptraj Patch for Ambertools 1.2 (beta)

From: Robert Duke <rduke.email.unc.edu>
Date: Fri, 29 Aug 2008 13:48:02 -0400

This is incredibly nit-picky, and at least in my opinion, not particularly
useful. And in addition, puts() puts a \n out after the string provided, so
it is not correct (or at least will not match the fprintf()-based output).
This is not a performance issue; it is error/warning msgs, for heaven sakes!
If is not a cleaness issue. Everyone that reads c has a clue about printf /
fprintf. Not everyone clearly understands all the implications of the
various other calls...
Regards - Bob Duke

----- Original Message -----
From: "Volodymyr Babin" <vbabin.ncsu.edu>
To: <amber-developers.scripps.edu>
Sent: Friday, August 29, 2008 1:20 PM
Subject: Re: amber-developers: Ptraj Patch for Ambertools 1.2 (beta)


> Just a small note:
>
> the places like, e.g., this
>
> + fprintf(stdout,
> + " REMDTRAJ: WARNING: Replica# found lower than file
> specified with trajin!\n");
> + fprintf(stdout, " (Found %s)\n",repFilename);
> + fprintf(stdout, " trajin <file> remdtraj requires
> lowest # replica!\n");
>
> would look cleaner if done as follows:
>
> puts(" REMDTRAJ: WARNING: Replica# found lower than file specified with
> trajin!\n"
> " (Found");
> puts(repFilename);
> puts(")\n trajin <file> remdtraj requires lowest #
> replica!\n");
>
> In other words, there is no need to use (f)printf if no format conversion
> is needed (C compiler simply cannot optimize such things out).
>
> On Fri, August 29, 2008 12:04, Daniel Roe wrote:
>> Hello all,
>>
>> I've recently been working a lot on the ptraj code and I have noticed
>> a few bugs, so I've created a patch for it. The code passes all of the
>> ptraj tests and I've done what testing I can, but I would greatly
>> appreciate it if anyone would give this a spin and make sure I haven't
>> broken anything. Here is a summary of what the patch does:
>>
>> 1) Ptraj did not correctly open netcdf files.
>> 2) Ptraj misidentified Amber REMD restarts as trajectories.
>> 3) io.c contained duplicate code in openFile() that resulted in
>> strange behavior for bzipped files.
>> 4) gzipped amber remd trajectories are now handled correctly.
>> 5) remd trajectories can now have numerical extensions of arbitrary
>> width, not just %03i.
>> 6) Better error checking and more informative error messages for remd
>> traj
>> code.
>>
>> If anyone would like more details about the various fixes let me know.
>>
>> -Dan
>>
>>
>> --
>> Daniel R. Roe, Ph.D.
>> Research Chemist
>> National Institute of Standards and Technology
>> 100 Bureau Drive, Stop 8443
>> Gaithersburg, MD 20899-8443
>> (301) 975-8741
>>
>
>
Received on Sun Aug 31 2008 - 06:07:58 PDT
Custom Search