FW: [Nexus-developers] API state

[Peterson, Peter F.]

I agree with Freddie on hiding special attributes from the NAPI user.
The precedent that was set in Switzerland was to prefix the attribute
with "NAPI". So it would be "NAPItype".

What do you (Mark) think of this change and removing the special
attributes from the listing of attributes for a field?

P^2 

-----Original Message-----
From: nexus-developers-bounces at anl.gov
[mailto:nexus-developers-bounces at anl.gov] On Behalf Of Akeroyd, FA
(Freddie)
Sent: Friday, May 20, 2005 7:54 AM
To: nexus-developers at anl.gov
Subject: RE: [Nexus-developers] API state

The XML interface uses the XML attribute "type" to store the data type
of an item - this is treated as a real attribute by
NXgetattrinfo/NXgetnextattr so if you convert a file from HDF -> XML you
appear to gain an attribute. As the "type" attribute is special I think
it should be hidden from the user who calls NXgetattrinfo/NXgetnextattr
and also if the user tried to set "type" via NXputattr they should get
an error. In fact, protecting "type" is important because a user could
legitimately set an attribute called "type" in HDF which would cause
problems when the file was converted to XML. I guess a similar argument
applies to the "target" attribute too - we should really prefix all
NeXus special internal attributes with something ("nx","_", ...) and
then disallow setting of attributes with this prefix from the usual
interface.  

I've made the search for "libsz.a" better in configure; does that help?

Freddie

> -----Original Message-----
> From: nexus-developers-bounces at anl.gov [mailto:nexus-developers- 
> bounces at anl.gov] On Behalf Of Mark Koennecke
> Sent: 20 May 2005 10:19
> To: nexus-developers at anl.gov
> Subject: [Nexus-developers] API state
> 
> High everyone,
> 
> I fixed the issue with the XML-API by now. It actually was much more 
> serious, the XML-API was reading wrong numbers. Nobody noticed.... 
> This was a bug in mxml which
I
> resolved. Thus, the only
> version of mxml which works is 2.2.2 as released yesterday!
> 
> There is another issue with the test not working under SL 3.0.4 and
Suse
> Linux 9.2. Now, I spent a lot
> of time with this. The first result was that the test programs would 
> fail within libc if hdf5 was involved.
> I tried various ways to improve on this by trying to initialize the
hdf5
> library before use. The hdf5 library is used even if hdf4 or xml files

> are read in order to test if a given
file
> is hdf5. The hdf team told me that there is no other  means of testing

> for hdf5, no magic number. I obtained
the
> best result when I put a
> H5open into the top of the test program napi_test.c. My next guess was

> to run strace upon the problem. For non unix guys: strace traces in 
> much detail all system calls. This showed me that the segfault  was 
> right after  a call to munmap. Apparantly Linux memory maps files for 
> reading. I also ran the program through valgrind, a very thorough 
> memory debugging program. This yielded no errors in our code or the 
> hdf*, xml libraries.
> I am now coming to the conclusion that the problem is in libc or gcc, 
> both of which I do not wish to debug.
> If someone experiences the problem she should update both gcc and libc

> to newer (or older?) versions.
> 
> There is still a small issue with the build process if you build a 
> version including a recent version of hdf4 but no hdf5. Then the -lsz 
> is missing on the link. This can be overcome by setting LDFLAGS to 
> "-Lpath-to-you-szlib -lsz" before running configure.
> 
>  What do you think?
> 
>                                          Mark
> 
> 
> 
> _______________________________________________
> NeXus-developers mailing list
> NeXus-developers at anl.gov
> http://www.neutron.anl.gov/mailman/listinfo/nexus-developers



_______________________________________________
NeXus-developers mailing list
NeXus-developers at anl.gov
http://www.neutron.anl.gov/mailman/listinfo/nexus-developers