FW: [Nexus-developers] API state

[Nick Maliszewskyj]

Slightly off-topic but timely...

Mark, Freddy - how do you feel about pushing back the next release
a few weeks (say until June 3)? We can ensure that our dependencies
on mxml for the XML interface are straightened out and that our
autotools setup works in the different configurations we will use.

Freddy - what is the state of the NXU routines?

Nick

Peterson, Peter F. wrote:

>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
>
>
>
>_______________________________________________
>NeXus-developers mailing list
>NeXus-developers at anl.gov
>http://www.neutron.anl.gov/mailman/listinfo/nexus-developers
>
>  
>

-- 
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
o Dr. Nicholas C. Maliszewskyj
o Center for Neutron Research
o National Institute of Standards & Technology
o 100 Bureau Drive, Stop 8562
o Gaithersburg MD 20899-8562
o nickm at nist.gov     Phone: (301)975-3171    Fax: (301)921-9847
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo