Help getting HelloMeshF77.F to run on GRUMMP

[Mark Miller]

Recent experience with GRUMMP and the ole' string passing issue
underscores the value in fortran wrappers...

a) C callers can assume interface handles null terminated strings and do
NOT have to act like Fortran (in fact, act worse than fortran because C
callers indeed must explicitly pass string length arguments)
b) No implementations need to worry about the issue because a wrapper
layer ABOVE the implementations handles it for ALL implementations.
c) other benefits already mentioned.

In fact, if I were writing my own implementation, I would most likely
opt NOT to include iMesh_protos.h and export BOTH C and Fortran callable
functions myself. I don't think there is anything in the spec. that
would prevent me from doing that, right? I mean if one were to take this
approach, they would still be compliant with the spec., right?

Mark

On Wed, 2009-11-04 at 06:24, Tim Tautges wrote:
> Mark Miller wrote:
> > 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.
> 
> I've always viewed wrapper layers as anathema, so you know my vote on that.
> > 
> > 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?
> 
> In MOAB, we already split out iBase_f.h.  And yes, these should go into the repo; I think this is the first time anybody 
> besides me/Jason have even looked at using this from Fortran.
> 
> - tim
> > 
> > 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!!)