Help getting HelloMeshF77.F to run on GRUMMP

[Tim Tautges]

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
>>

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706