non portable - a problem with direct access
in [Fortran]
|
Prev: McFor: a MATLAB-to-Fortran 95 Compiler
Next: 100% free dell laptaps offerd by dell and Vodafone companies.
From: dpb on 2 Aug 2010 17:03 Richard Maine wrote: > dpb <none(a)non.net> wrote: > >> glen herrmannsfeldt wrote: >> ... >>> While I always punched all my own cards, it seems that some would >>> write the program on such a form, then have someone else punch it, >>> verify it, and return the deck with the form. >> ... >> In the organization at which I worked (and I think fairly common), >> engineers weren't allowed access to the keypunch machines except for the >> one-off correction there was one freestanding machine (in an office of >> 1000-1500 engineers); that's what the roomful (30-some) of keypunch >> operators were there for. I remember "keypunch Shirley" quite vividly, >> in fact... :) > > We could do it either way, but I always punched my own for 2 reasons. > > 1. I got a lot faster turnaround by punching my own cards instead of > submitting them to the keypunch service and waiting until the next day > to get them back. > > 2. Comparing my keypunch and handwriting skills... well there barely is > any comparison. Sending my handwriting ti the keypunch operators would > have counted as abuse... both of them and of myself. Not that my > keypunching was great, but it beat my handwriting by a lot, and did > gradually improve. > > In my first few years, when I was still a co-op work-study peon, I'd > fairly often end up doing the keypunching for some of the senior > engineers in our office. I once got quite a lecture for "improving" the > computer code as I typed it. The lecture was indeed deserved. Besides > the basic issue of that being the wrong way to suggest improvements (I > just did it without mentioing that I had done anything other than play > keypuncher), in retrospect, some of the "improvements" I made probably > weren't good ideas anyway. For example, I would see things like > 2*some_other_literal, and do the multiplication myself instead of > leaving it that way. I probably had some notion that this would be more > efficient (which probably wasn't even so), and failed to recognize that > the original form was more clear to the reader in context. Hey, I was 18 > at the time. Regarding 1. No choice at B&W; engineers weren't keypunchers by policy, no exceptions. There was a technique/process in place to get prioritized turnaround but that was also, typically a day except in truly rare occasions that were indeed critical (so to speak :) ); the most common of those case would generally have to do w/ startup physics testing wherein a hold on power ascension to next test plateau was dependent on a computation comparison to test data to confirm or suggest alternate test if still not a clear "go". 2. You suffered if you didn't make the forms legible; no exceptions... and there was no procedure for relief from that one... <vbg> (And, I'm one who in HS had my physics/chemistry teacher fail me on a midterm w/ the comment scrawled on the top of the page "I can't grade it if I can't read it!" :) I did get the opportunity to transcribe the particular paper and submit it for a grade but not until after some time elapsed to let the lesson sink in.) Also, in the nuke design business there was the requirement for the independent QA review of every input number for computations that were related to design calculations. Most of these inputs were data decks for computational model runs, not coding however, altho the same rules applied about engineers/programmers not being keypunchers. The typical PDQ/Harmony input deck was 2-3 boxes of cards. Of course, out of that, only a few hundred were modified from run to run, the rest were a fixed geometry description, nuclear cross section interpolating tables, the isotope depletion and decay chain descriptions, etc., etc, etc., that were constant for a fixed core design. In the aspect of programming in that environment, it was for almost two years after the advent of the CRT terminal that the use of them for input was extended to engineering, again for the issue of how to do the QA process in an NRC-approved documentable manner that was finally acceptable to internal QA management. That took until the mid-70s as it hadn't been that way but just a very few years when I left in mid-78. --
From: Nick Maclaren on 2 Aug 2010 17:47 In article <i377mm$lh$1(a)speranza.aioe.org>, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: >Janus Weil <jaydub66(a)googlemail.com> wrote: > >> Well, gfortran is a command-line tool after all, not some overblown >> point-and-click all-in-one IDE. So, what do you expect? Screenshots of >> a terminal showing some gfortran command? How useful would that be? > >In the IBM S/360 and S/370 Fortran manual the sample programs >are printed as written on a "Fortran Coding Form." And a right damn-fool idea that was, too, especially for those of us who used paper-tape for input! TTYs came in in the mid-1960s but, as people have said, didn't take off as entry devices for a long time, even in the most advanced locations. We didn't use them for that at Cambridge until well into the 1970s. >A screen shot of emacs or vi editing a Fortran program also >doesn't seem so applicable to the gfortran manual. Before anyone suggests it seriously, they should consider why it would clarify anything better then the use of plain text, and try to explain that in their posting. I shall not hold my breath. Regards, Nick Maclaren.
From: Clive Page on 2 Aug 2010 17:46 >> > Screenshots? Are you serious? Why would the gfortran manual need >> > screenshots? That's ridiculous. I thought that I'd seen one somewhere, and I tracked it down: a very informative screenshot of the g95 compiler in action: http://sourceforge.net/project/screenshots.php?group_id=5179 gfortran would be very similar. Enjoy. -- Clive Page
From: Richard Maine on 2 Aug 2010 18:13 Clive Page <junk(a)nospam.net> wrote: > >> > Screenshots? Are you serious? Why would the gfortran manual need > >> > screenshots? That's ridiculous. > > I thought that I'd seen one somewhere, and I tracked it down: a very > informative screenshot of the g95 compiler in action: > > http://sourceforge.net/project/screenshots.php?group_id=5179 I don't see anything at all informative about that screenshot that wouldn't be just as well shown as text. In fact, all of the useful content is text. The rest is nothing but an image of someone's (Looks like Andy's) terminal emulator, which doesn't tell me anything about g95. I'd say this comes perilously close to Janus' comment about the worst manuals he knows being "those which spend half a page on a nice and colorful screenshot of a complete Windows desktop, just to show you how to click on an 'Ok' button". One of the two screenshots on the referenced site spends half a page on a nice and colorful screenshot of a terminal emulator just to show the single text line g95 test.f90 I see no other useful content unless one has some kind of perverse interest in what fonts, colors, and other style elements Andy uses in his terminal emulator. Of course, I had to manually retype that line into this posting. Fortunately, it was a pretty easy one to type. Attempting to select/copy it from the web page just gets me a jpg of the screen instead of the text. I suppose one could do worse, which in this case, would be to go more in the direction of gratuitously turning useful text into useless screenshots. The next step would be to show screenshots instead of text for sample code just in order to make it extra tricky for those who might want to copy the code and try it themselves. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: robin on 2 Aug 2010 20:50
"Nick Maclaren" <nmm(a)gosset.csi.cam.ac.uk> wrote in message news:i37ed5$ss1$1(a)gosset.csi.cam.ac.uk... | In article <i377mm$lh$1(a)speranza.aioe.org>, | glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: | >Janus Weil <jaydub66(a)googlemail.com> wrote: | > | >> Well, gfortran is a command-line tool after all, not some overblown | >> point-and-click all-in-one IDE. So, what do you expect? Screenshots of | >> a terminal showing some gfortran command? How useful would that be? | > | >In the IBM S/360 and S/370 Fortran manual the sample programs | >are printed as written on a "Fortran Coding Form." | | And a right damn-fool idea that was, too, especially for those of us | who used paper-tape for input! | | TTYs came in in the mid-1960s TTYs were being used in 1960 and even earlier. There were demonstrations used on remote installations back in the 1950s. | but, as people have said, didn't take | off as entry devices for a long time, even in the most advanced | locations. We didn't use them for that at Cambridge until well | into the 1970s. | | >A screen shot of emacs or vi editing a Fortran program also | >doesn't seem so applicable to the gfortran manual. | | Before anyone suggests it seriously, they should consider why it | would clarify anything better then the use of plain text, and try | to explain that in their posting. I shall not hold my breath. |