[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ddlm-group] Relationship of CIF2 to legacy platforms

I am only suggesting that maintained Fortran code ought to be able to 
utilize F2003 STREAM I/O, supported by current versions of GFortran, 
Intel Fortran and Sun Fortran.

Of course, I probably am not considering all of the issues. STREAM I/O 
avoids the need for a fixed maximum record length, but even the newest 
Fortran compilers have very limited UTF-8 support. Even with STREAM I/O, 
it is not trivial to count trailing blanks as significant.

Maybe the biggest problem is UTF-8. IMHO, it makes sense for UTF-8 to be 
an optional encoding, rather than just declaring CIF2 is all UTF-8. This 
is one place where a more informative header would help. Even if CIF2 
does not allow alternate encodings, it would be nice to have a flag at 
the top stating whether UTF-8 codes are actually used in the file. This 
would allow some programs to avoid UTF-8 files for the near future, and 
UTF-8 can still be used where it is needed (i.e. publication oriented 
CIF files) and still not be a road-block to other programs.


Herbert J. Bernstein wrote:
> Dear Joe,
>    This is _not_ a matter of legacy software, but of currently maintained 
> data collection software that happens to be written in Fortran.
>    People have work to get done.  The failure of CIF2 to support fortran on 
> a wide range of platforms will not stop those applications from doing what 
> they need to do, it will just further hinder the adoption of CIF in the 
> macromolecular community.
>    Regards,
>      Herbert
> =====================================================
>   Herbert J. Bernstein, Professor of Computer Science
>     Dowling College, Kramer Science Center, KSC 121
>          Idle Hour Blvd, Oakdale, NY, 11769
>                   +1-631-244-3035
>                   yaya@dowling.edu
> =====================================================
> On Fri, 30 Oct 2009, Joe Krahn wrote:
>> IMHO, even though Fortran is not dead yet, it's quirky I/O semantics
>> should not be an important consideration for CIF2. I still write Fortran
>> code, so I am not suggesting that Fortran code be neglected. However,
>> still using Fortran should have a modern compiler that supports STREAM
>> I/O (including GFortran), which avoids these text I/O problems.
>> If you have old software that you don't want to maintain, there can
>> always be a CIF2-to-CIF1 utility, so that the old program will still
>> work as-is. For new code, it really only makes sense to use Fortran for
>> number crunching, and just use a C library to do CIF I/O.
>> Joe Krahn
>> James Hester wrote:
>>> By 'systems' I had in mind computer operating systems and programming
>>> environments, in particular multilingual support and Fortran.  So, for
>>> example, as Herbert's replies have been indicating, Fortran behaviour
>>> continues to influence the CIF standard.
>>> On Thu, Oct 29, 2009 at 1:04 AM, David Brown <idbrown@mcmaster.ca> wrote:
>>>> James asks whether we should require CIF2 to support legacy systems.  I am
>>>> not sure what James means by 'systems'.  Are these datafiles or programs?
>>>> That is to say is the queston 'should CIF2 applications be able to read
>>>> legacy CIFs?', or 'should legacy CIF1 programs be able to read CIF2
>>>> datafiles?'?
>>>> The answer to the first question is definitely 'yes'.  It is part of the
>>>> mandate of CIF2 that its programs should be able to process the existing
>>>> archive so that the archive can take advantage of the enhanced functions of
>>>> DDLm.  The CIF2 dictionaries will alias all the datanames appearing in the
>>>> CIF1 dictionaries in a way that makes such reading easy.
>>>> The answer to the second question is almost certainly no, at least in cases
>>>> where the CIF data file makes use of the added syntax features.  All the
>>>> datanames in CIF1.0 dictionaries differ from those in the CIF2 dictionary by
>>>> not using a period at the end of the category part of the name and in some
>>>> cases the names differ in other ways.  There would be no point in trying to
>>>> produce CIF2 compatible CIF1 dictionaries, since the CIF1 dictionaries are
>>>> poorly designed for maintenance and have poor aliasing features.
>>>> David
>>>> James Hester wrote:
>>>> Dear All,
>>>> I think it would be helpful to make a policy decision regarding our
>>>> treatment of legacy systems in CIF2.0.  This concerns first and
>>>> foremost Fortran derived line-length constraints, but may impact on
>>>> the encoding discussion in deciding which encodings might get some
>>>> special treatment.  There may be other such issues as well.
>>>> We have a few choices:
>>>> 1. Disregard legacy system issues when designing CIF2, on the basis
>>>> that such systems can continue to use CIF1 and will eventually
>>>> disappear at about the same time that it does (sort of like ASCII and
>>>> Fortran...)
>>>> 2. Continue to support legacy systems on the basis that we don't want
>>>> to deny such systems the chance to partake of the raw unadulterated
>>>> goodness of CIF2, or perhaps more seriously that such legacy systems
>>>> are integral to CIF2 takeup.
>>>> What do you think?
>>>> James.

ddlm-group mailing list

Reply to: [list | sender only]