Proposed rearrangement of "struct NeXusFile"

[Ray Osborn]

Freddie wrote:

> There is a further problem i have noted with the the F90 definition of
> NXstack: iRefDir and iTagDir are defined as integers whereas they are
> in fact pointers to integers. On most operating systems pointers and
> integers occupy the same storage space, but on Digital UNIX this is not
> the case (int=32bit, pointer=64bit) and the definition is incorrect.
> Should the F90 interface really need to know the format of internal NeXus
> C data structures? It strikes me that we may be making problems for
> ourselves
> ... what we should instead do is have a few "extractor" functions for any
> bit of
> a "NexusFile" structure that may be needed ... you could call these
> functions
> safely from FORTRAN with the opaque NexusFile structure and get the bits you
>
> need.

It's true that it should not really be necessary to access the internal
details of the NXhandle structure in the F90 interface.  However, I made the
structure explicit because I didn't want to interfere with the C interface.
In particular, I needed to be able to reinitialize group searches, which I
did by setting iCurDir to 0 at the current stack level (extractor functions
are not enough; I need to be able to set bits of the structure as well as
read them).  The alternative was to change NAPI.C, which I'm not qualified
to do as a non-professional C programmer.

I would not need to access these internal variables if the C interface had
the equivalent of NXgetgroupinfo, NXgroupdir, NXgetattrinfo, and NXattrdir
(see <http://www.neutron.anl.gov/NEXUS/NeXus_API.html#F90>), but I don't
want to hold up the release of v 1.2.0 if there is going to be a long delay
in agreeing to their specifications and/or in writing them.  I know how busy
everyone is.

>
> I also noticed NXgetgroupinfo() is a "core NeXus API" function in F90, but
> not implemented in C or F77. I would think the "core API" should be the same
> for all languages, so we should implement functions such as this in C/F77
> before
> releasing (or maybe make them part of NXU?)

I included them as core routines because they all required access to these
low-level NXhandle items whereas I wanted the NXU routines to be written
purely in terms of the NX core routines.  I think I hoped that they would be
rewritten in C at some time but I forgot to initiate a debate on the topic.
I note that Mark put in a NXgroupdir function into the IDL interface, but
had the opinion that they shouldn't be in the C interface because of
problems with garbage collection.  In my version, the name arrays have to be
allocated before the function call, usually by calling NXgetgroupinfo first
to determine the number of group items, so this shouldn't be a problem, but
perhaps it offends typical C design practice.

The functionality of NXgroupdir can be replicated by calling NXgetnextentry,
provided that there is a mechanism for reinitializing group searches (done
in NXinitgroupdir in NXmodule.f90).  NXgetgroupinfo is essential to cope
with jumps to other groups to which data are linked.  The user needs to be
able to determine the name of the current group and class after a call to
NXUfindlink and/or NXUresumelink.  It's also useful to have a routine that
passes back the number of group items (which is stored in the NXhandle
structure anyway) so that the programmer can allocate enough space before a
loop through NXgetnextentry.

I would welcome (reasonably quick) input from the C-writing members to see
how we resolve this impasse i.e. can we add NXgetgroupinfo, NXgetattrinfo
etc to the core routines.  Or should we have a series of NXI routines
(externally accessible) that make inquiries or manipulate low-level NeXus
information.

Ray
--
Dr Ray Osborn                Tel: +1 (630) 252-9011
Materials Science Division   Fax: +1 (630) 252-7777
Argonne National Laboratory  E-mail: ROsborn at anl.gov
Argonne, IL 60439-4845