[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Relationship of CIF2 to legacy platforms
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] Relationship of CIF2 to legacy platforms
- From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Mon, 2 Nov 2009 13:37:34 -0500 (EST)
- In-Reply-To: <4AEF0E98.5000002@niehs.nih.gov>
- References: <279aad2a0910260542id9c0209sb8d25ae53771ceaa@mail.gmail.com><4AE84F87.8090104@mcmaster.ca><279aad2a0910281442y45b9deafvf4eefbb1940fba9c@mail.gmail.com><4AEB127A.7000007@niehs.nih.gov><20091031161934.R64143@epsilon.pair.com><4AEF0E98.5000002@niehs.nih.gov>
Dear Joe, The reality is that even among those compilers there are serious problems when using non-traditional Fortran I/O and many people (including me) still use g77 and even f2c as well as other older but still useful compilers. That is why imgCIF has to have an image pad option to allow the otherwise very nice intel compiler to be able to read it. Things should be better a few years from now, but right now we have a serious problem with arbitrary line lengths. 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 Mon, 2 Nov 2009, Joe Krahn wrote: > Herbert, > 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. > > Joe > > > 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 > ddlm-group@iucr.org > http://scripts.iucr.org/mailman/listinfo/ddlm-group > _______________________________________________ ddlm-group mailing list ddlm-group@iucr.org http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- References:
- [ddlm-group] Relationship of CIF2 to legacy platforms (James Hester)
- Re: [ddlm-group] Relationship of CIF2 to legacy platforms (David Brown)
- Re: [ddlm-group] Relationship of CIF2 to legacy platforms (James Hester)
- Re: [ddlm-group] Relationship of CIF2 to legacy platforms (Joe Krahn)
- Re: [ddlm-group] Relationship of CIF2 to legacy platforms (Herbert J. Bernstein)
- Re: [ddlm-group] Relationship of CIF2 to legacy platforms (Joe Krahn)
- Prev by Date: Re: [ddlm-group] Relationship of CIF2 to legacy platforms
- Next by Date: Re: [ddlm-group] New syntax: 'marker' characters
- Prev by thread: Re: [ddlm-group] Relationship of CIF2 to legacy platforms
- Next by thread: Re: [ddlm-group] Relationship of CIF2 to legacy platforms
- Index(es):