Nevertheless, puts(s) simply outputs string s (followed by "\n")
while printf("s\n") examines its format string ("s\n") first.
On Fri, August 29, 2008 13:48, Robert Duke wrote:
> 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:59 PDT
