[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: Thu, 19 Nov 2009 10:19:24 -0500 (EST)
- In-Reply-To: <4B055BBA.4000803@mcmaster.ca>
- References: <C71DF6D4.12389%nick@csse.uwa.edu.au><4AFC3C0B.7060404@niehs.nih.gov><279aad2a0911181834j3c93b0f9q7bca234514df2d57@mail.gmail.com><4B055BBA.4000803@mcmaster.ca>
Just to simply the menu of choice, I'll change my vote to 4096. -- 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 Thu, 19 Nov 2009, David Brown wrote: > I have no strong views on line length, but the arrguments for keeping them > seem a little stronger than those for abolishing them. I have no views at > all on how long the lines should be other than to note that Acta Cryst. > programs get upset if there are more than 80 characters in a line. > > David > > > > James Hester wrote: > > We should resolve the Fortran line length issue as I think we've got > enough information on the table - could those who haven't indicated > their preference please vote either > > (1) CIF2 should have a maximum line length specified or > (2) no line length should be specified. > > For bonus points, you can indicate what this length should be. > > So (including Nick's recent email) I count the votes as: > > (1) Herbert (>=2048), Nick (2048), James (4096) > (2) Joe > > I've added my vote to the fixed line length simply because I accept > Herbert's argument that legacy Fortran programs are actually important > in the crystallographic world, and a restriction on line length does > not impose a burden on CIF readers. It also imposes a bit of > discipline on CIF writers and helps to produce a readable file. > > On Fri, Nov 13, 2009 at 3:47 AM, Joe Krahn <krahn@niehs.nih.gov> wrote: > > Nick Spadaccini wrote: > > On 3/11/09 12:53 AM, "Joe Krahn" <krahn@niehs.nih.gov> 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 > > Not sure what you gain by doing this. If it is pure ASCII only then the > declaration of UTF-8 inhibits nothing, since ASCII is a subset. If it is not > pure ASCII, then it needs to be UTF-8. I can't see how knowing in advance > that it is a subset of UTF-8 or possibly the full set of UTF-8 gives you > anything. > > cheers > > Nick > > A compiler/language not aware of UTF-8 could avoid errors by rejecting > CIF files that contain UTF-8. However, I think the approach being taken > is just to allow implementations to restrict usage, rather than put it > in the specifications. For example, the plan seems to be that > DDL/dictionary definitions will be used to avoid UTF-8 in data names, > where it is most likely to be a problem. So, you are right: there is no > reason for the CIF2 syntax to make UTF-8 optional when the dictionaries > can restrict characters to the ASCII subset. > > The other potential legacy issues I know of are fixed maximum line > lengths, and significant trailing blanks. Dictionary definitions cannot > avoid these. It might be possible to take a similar approach, by > avoiding them by implementation conventions rather than making it part > of the spec. If these are only going to be an issue for a few more > years, it would avoid having to make another syntax change in the near > future. > > My main interest here is to avoid incompatible implementations. I also > think that Fortran, and any other line-oriented I/O software, should be > able to do stream-oriented I/O in the near future. > > Joe > > _______________________________________________ > 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]
- Follow-Ups:
- Re: [ddlm-group] Relationship of CIF2 to legacy platforms (Nick Spadaccini)
- References:
- Re: [ddlm-group] Relationship of CIF2 to legacy platforms (Nick Spadaccini)
- Re: [ddlm-group] Relationship of CIF2 to legacy platforms (Joe Krahn)
- Re: [ddlm-group] Relationship of CIF2 to legacy platforms (James Hester)
- Re: [ddlm-group] Relationship of CIF2 to legacy platforms (David Brown)
- Prev by Date: Re: [ddlm-group] Relationship of CIF2 to legacy platforms
- Next by Date: Re: [ddlm-group] Use of elides in strings
- 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):