Ya, probably so.
But I'm still going to blame Fortran for that bug. Just 'cause it's easier.
:-)
(I also spent all morning writing an MPI_COMM_SPAWN_MULTIPLE test *in Fortran*,
which was exceedingly painful, and I had to send it off to a Fortran expert to
tell me what I did wrong... So my f
The value of i is exactly as it would be in C for the value of a loop control
variable at loop exit. (As opposed to being undefined, which is what is used
to be.) This dates from Fortran-77.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 11 Jul 2012, at 10:44 AM, Jeff Squyr
Ya, I saw Brian's commit, too.
Ah, I see what happens -- i is actually 101, not 100. Frackin' Fortran...
On Jul 11, 2012, at 12:57 PM, Eugene Loh wrote:
> Brian caught it. I simply applied the change to the other ibarrier_f* tests.
> With this and your "remove bozo debug statements" (+ slee
Brian caught it. I simply applied the change to the other ibarrier_f*
tests. With this and your "remove bozo debug statements" (+ sleeps)
putbacks (26768/trunk and 26769/v1.7), I'm hoping our ibarrier_f* MTT
time-outs will disappear.
On 7/11/2012 9:26 AM, Jeff Squyres wrote:
I thought i wou
I thought i would be 100 at the end of that do loop.
$%#@#@$% Fortran. :-(
On Jul 11, 2012, at 12:25 PM, wrote:
> Author: eugene (Eugene Loh)
> Date: 2012-07-11 12:25:09 EDT (Wed, 11 Jul 2012)
> New Revision: 2002
>
> Log:
> Apply the "right value when calling waitall" fix to
> all ibm/colle
