Help getting HelloMeshF77.F to run on GRUMMP

[Mark Miller]

Hi Tim,

Two quick points.

Its NOT just setting breakpoints via function names thats a bit
confusing. Its any time you are doing anything that involves
interpreting names in the symbol table. Call stack tracing, output from
linker, 'nm', 'gprof', etc. The names in the symbol table DO NOT match
the names in the code. I think its manageable. But, I still want to
point out that I think we could do better -- at the expense of an
additional function call for Fortran callers.

Next, can we at least put iMesh_f.h 'next to' iMesh.h in the repo?

Also, should we split out the iBase.h specific stuff in iMesh_f.h into
an iBase_f.h, too?

Mark


On Tue, 2009-11-03 at 15:46 -0600, Tim Tautges wrote:
> Not that this justifies the current approach entirely, but at least we don't need to trace through 4-6 function layers 
> from the application to the implementation, as we had to with the SIDL-based interface.  Also, it's only a subset of 
> debugging operations for which you need to specify a breakpoint in terms of the iMesh function name.  Other operations 
> include specifying by line, stepping into, specifying by name in the implementation-native function, etc.
> 
> 
> 
> >> Well, many large Fortran applications use CPP to preprocess their fortran anyway (thus the .F extension, rather than .f 
> >> or .f77), and all the systems I know of support this (that's not precise, but it's not worth the time to state 
> >> properly).  So it's not a matter of doing it easily with the preprocessor.  The real crux is that we don't want to call 
> >> wrapper functions, which impose an overhead that can be avoided.  One could argue you could do this with inlining too, 
> >> but then you wouldn't be compatible with f77.
> > 
> > Ok, I understand that. At least in theory. In practice, I really wonder
> > if that overhead -- which would exist only for a fortran caller -- is
> > going to be any factor in adoption.
> > 
> 
> Yes, so it's subjective.  Is the potential confusion during debugging (and possibly configuring for implementation 
> developers) worth the overhead of a wrapper layer.
> 
> 
> > 
> > Funny you should say that. Becuase, you just requested we add
> > iBase_OPTION_NOT_PROCESSED.
> > 
> 
> Yep, but that proves my point, I think - out of all the enum values, just one new one in about 5 years doesn't seem like 
> much.
> 
> - tim
> 
-- 
Mark C. Miller, Lawrence Livermore National Laboratory
email: mailto:miller86 at llnl.gov
(M/T/W) (925)-423-5901 (!!LLNL BUSINESS ONLY!!)
(Th/F)  (530)-753-8511 (!!LLNL BUSINESS ONLY!!)