reading config file
in [Fortran]
|
Prev: Software for plotting in Fortranxx?
Next: INTRINSIC STATEMENT for functions overloaded for user defined types
From: nmm1 on 15 Sep 2009 15:58 In article <1j634hh.tk94hf1g4fxzqN%nospam(a)see.signature>, Richard Maine <nospam(a)see.signature> wrote: >Dave Allured <nospom(a)indra.com> wrote: > >> Hmmm. I will have to go through old code and compiler docs, and get >> back to you on that in a day or two. What I remember for sure was when >> a new compiler broke old code because of the "reads to end of line" >> rule, that was the day I stopped trusting list-directed string input. > >I'm not sure what you mean by "reads to end of line rule", but it sounds >like one of two possibilities to me, both covered by the standard rather >than being portability issues. I can't remember the details any longer, but a lot of systems had other problems, that were nothing to do with the standard. Nothing to do with list-directed versus explicit formats, either. Specifically, delights like when a short record was padded and when it wasn't, which could become visible when reading a character string that spanned a line. And, of course, the systems which truncated input lines - well, you DID punch it onto cards before reading it to disk, didn't you? Regards, Nick Maclaren.
From: Richard Maine on 15 Sep 2009 16:35 <nmm1(a)cam.ac.uk> wrote: > I can't remember the details any longer, but a lot of systems > had other problems, that were nothing to do with the standard. > Nothing to do with list-directed versus explicit formats, either. > > Specifically, delights like when a short record was padded and > when it wasn't, which could become visible when reading a > character string that spanned a line. Yeah. A somewhat related possibility relevant to some current systems occurred to me right after I made my prior post. System differences in text line terminators can sometimes "hide" for a while, but bite you later; we've seen such cases here. For example, if you have a Dos text file with cr/lf line terminators, and you are reading it on a Unix system that expects only the lf, that extra cr can sometimes hide there innocuously for a while. If you are using fixed field widths that stop before the cr, it might not cause a problem. But if you are using something like list-directed input of a field that goes to the end of the line, the extra cr might look like part of the field and cause an error. Or some compilers might be "smart" enough to recognize the file as having Dos line terminators and deal with it for you. I suppose that is a portability problem that might appear to a casual glance to be related to list-directed input, though I'd say that diagnosis stops short of the root cause. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Ron Shepard on 15 Sep 2009 16:47 In article <h8oeud$g6j$1(a)news.eternal-september.org>, Bil Kleb <Bil.Kleb(a)nasa.gov> wrote: > > > > [...] It has now been > > included in the Fortran 90 language. However, NAMELIST is a > > poorly designed feature and should be avoided whenever possible." > > Interesting. I find NAMELIST to be one of the few designs in the Fortran > language that actually adheres to the Open/Closed Principle.^1 > > My only complaint with NAMELISTs are the very poor error handling > diagnostics it seems to provide. Then again, I haven't fully > investigated them yet. My current ignorant complaint: you don't > get detailed information about where a particular namelist read > went awry, e.g., a misspelled variable or bad syntax, just a > "namelist read failed" error code. I would have liked for fortran namelist to include some expression evaluation. For example, something like &input angle_1 = 12.34567 angle_2 = 2*angle_1 x = cos(angle_1) y = sin(angle_1) / would simplify a lot of things. The idea here is that the user would change only one line in the input file and the other dependent lines would change accordingly. Even if the expression evaluation were limited to only simple arithmetic (+,-,*,/), it would still be useful. > > 2) I'm not sure, but i think using NAMELIST would make it harder > > for me to allow comments starting with # in my config file... > > Yeah, you'd have to use Fortran's '!' for comments (and you'd have > to use the 14-year old F95 instead of the 19-year old F90 to portably > use them). I had forgotten that f95 changed some of the details of f90 namelist. However, for practical purposes, (almost) all compilers are (at least) f95+allocatableTR now, so it is safe to include comments. As to whether ! or # is a better delimiter, I don't know, but if it comes down to an issue of which is easier for the user to determine and use, I think it is better to stick to a standard (fortran) than something entirely ad hoc (and specific to a particular program). If the user wants to know how to format something, or how to comment something, it is easy to look it up if it is part of the fortran standard (e.g. using google). If it is something cooked up for an individual program, the documentation might be difficult, or even impossible, to find, and once found, it could well be outdated, misleading, or wrong. When you combine this with my previous comments about how namelist makes things easier for the programmer, then it seems that namelist wins all round, both from the programmer's and the user's perspective. $.02 -Ron Shepard
From: e p chandler on 15 Sep 2009 22:31 > 3) I prefer to have the freedom of organizing my config file as > *I* (and also my not-so-Fortran-educated) users want it to be. > If I use NAMELIST, i am forcing me and my users to stick with the > namelists syntax. > > But thanks for the suggestion! > > Bart So leave the original config file alone. Write a script that transforms that file into proper input for NAMELIST. I'm sure it would only be a few lines of Perl, AWK or whatever. [Sorry Fortran purists.] -- Elliot
From: Richard Maine on 16 Sep 2009 02:25
e p chandler <epc8(a)juno.com> wrote: > > 3) I prefer to have the freedom of organizing my config file as > > *I* (and also my not-so-Fortran-educated) users want it to be. > > If I use NAMELIST, i am forcing me and my users to stick with the > > namelists syntax. > > So leave the original config file alone. Write a script that > transforms that file into proper input for NAMELIST. I'm sure it would > only be a few lines of Perl, AWK or whatever. [Sorry Fortran purists.] Yukk! It isn't that I am such a Fortran purist that I object to using tools like Perl, AWK, or whatever. It is just that this seems like an excessively complicated and roundabout solution. The OP has a file, form already specified, and wants to read that file into a Fortran program, which is simple to do as is. It just seems to me to add layers of complication to add a separate step of transforming a file just so that you can then use a different way of reading it in Fortran. I'm sure you could also use perl to compute x+y for two Fortran variables x and y. Write them to a file from Fortran, have Perl process the file and write its output to another file, which you then read in Fortran. It isn't because I don't like Perl that I find that a strange way to do things. It is because I like simplicity. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |