From: dpb on 11 Jun 2010 17:25
Steve Lionel wrote:
> Yes, making guesses as to what to fix is probably not a good idea if you
> don't understand the problem.
Apparently, he didn't want to hear that message... :(
From: rfengineer55 on 11 Jun 2010 17:32
On Jun 11, 12:05 pm, dpb <n...(a)non.net> wrote:
> rfengineer55 wrote:
> > ... That's how you choose to see the situation, and I'm not at all
> > interested in hearing about it. So airing your interpretation is going
> > to do nothing but waste bandwidth.
> OK, then, <plonk>...
> If you think
> a) Showing the generation of your posted error message in two lines of
> executable code to demonstrate the "why" of the message explicitly, and
> b) The suggestion to just slow down and "think first, program second"
> are a waste of bandwidth, then
> c) I agree that in this case they undoubtedly are and regret wasting my
> Just to be certain to not ruffle any feathers in the future, I've
> notified my newsreader to be sure to skip any future threads so as to
> minimize any chance to offend...
I hesitated to respond to dpb's post but for the record. I embrace his
suggestions about modifying my fortran code. That's why I'm here. His
comments about my flailing, throwing code at my computer and needing
to think logically is what I'm not interested in hearing about because
it has nothing to do with the problem at hand.
From: dpb on 11 Jun 2010 17:31
glen herrmannsfeldt wrote:
> After a while you get used to how different people respond.
Indeed, I tend to try to add the "teach to fish" viewpoint, particularly
where a specific issue has already been addressed (in this case at least
two times previously that hadn't seem to have had much effect).
In some cases it's almost preordained to be a failure; still we must
(I'd think "flailing" is a pretty apt description of simply doing a
blanket substitution of "," for "'" in direct access READ/WRITE
statements and that pausing to consider what one was actually doing
first would be a way to gain on the objective rather than simply
compiling and posting over and over, but that's just me...what do I know
after 40 years? :( )
From: glen herrmannsfeldt on 11 Jun 2010 17:53
dpb <none(a)non.net> wrote:
> (I'd think "flailing" is a pretty apt description of simply doing a
> blanket substitution of "," for "'" in direct access READ/WRITE
> statements and that pausing to consider what one was actually doing
> first would be a way to gain on the objective rather than simply
> compiling and posting over and over, but that's just me...what do I know
> after 40 years? :( )
Many years ago I was working with a macro processor that had
built into it the idea that apostrophes should be balanced.
Note that the same compilers that used the apostrophy record
indicator also allowed apostrophes for character (replacement
for Hollerith) constants and format descriptors.
It is a pretty strange use.
From: dpb on 11 Jun 2010 18:21
glen herrmannsfeldt wrote:
> dpb <none(a)non.net> wrote:
>> blanket substitution of "," for "'" in direct access READ/WRITE
>> statements ...
> Many years ago I was working with a macro processor that had
> built into it the idea that apostrophes should be balanced.
> Note that the same compilers that used the apostrophy record
> indicator also allowed apostrophes for character (replacement
> for Hollerith) constants and format descriptors.
> It is a pretty strange use.
Speaking of "blanket substitution" reminds of a _very_ painful episode
from many years ago -- so long ago that the DEC 10 was near the king of
the hill and TECO was the editor of choice (the type your name backwards
w/o punctuation in and see what it does editor :) ).
Anyway, had contract to port a large scientific modeling code w/ it's
60-bit word to 32-bit IBM machine which necessitated changing all SP
constants to DP. We'd been at a series of modifications for months and
had TECO macros to submit every night to the DEC to edit the source
files. These would typically take two or three nights to complete a
single pass before they took the machine back for daytime interactive
use. Anyway, we got a summer intern and figured the double precision
thingie was something he could handle. Unfortunately, w/o showing his
planned work and w/o making a backup of the previous day's runs, he
submitted a macro that did a global change of all E's to D's w/ no
It wouldn't have been so bad but that the previous day's work that
hadn't yet been backed up was the cumulative effect of one of these
earlier scripts that had taken several days to complete. Our practice
(thereby modified) had been to make new backups after each completed
edit had been tested and accepted as accurate.
On the apostrophe for the direct access, I recall using it on VAX some
but it's been so long I don't recall what other ramifications it may
have had. I don't remember any bad experiences on that one... :)