XRDMLread - Matlab function for reading X'Pert XRDML files

Download and Install

XRDMLread

XRDMLread is freely distributable under the Simplified BSD license.

In both cases you still need the XMLTree toolbox. See below.

XMLTree toolbox

The external XMLTree toolbox is required to run the XRDMLread. It can be freely downloaded under the GPL license from the XMLTree website.


XRDMLread.m file and the XMLTree toolbox are all you need to download and install for Matlab. The rest of this page describes (i) a setup for Octave and (ii) an issue concerning older Matlab versions and Win-64.


XMLTree toolbox with Octave

XRDMLread works also with Octave. Unfortunately to the XRDMLread authors' knowledge the external XMLTree toolbox does not work properly with Octave — up to the November 19, 2010 and Octave version 3.2. Fortunately it can be fixed with little modifications, which are described below.

Applying the patch
Compiling xml_findstr.c

After applying the XMLTree patch an xml_findstr.c mex-function need to be compiled. You can do this by following the instructions on the original XMLTree website.
> cd xmltree/@xmltree/private
> mex xml_findstr.c


XMLTree and Octave Incompatibility

This section describes in detail incompatibility issues of the XMLTree toolbox and Octave.

The problems can be divided in two categories.

  1. Bug(s) directly in the XMLTree Matlab code.
  2. Missing compiled XMLTree build-in mex function xml_findstr.c in the xmltree/@xmltree/private directory.

The only one critical bug, that has to be fixed in Matlab code, is in the xmltree/@xmltree/find.m file. At the line 112 a single AND operator "&" has to be changed to double "&&".

L111        %- Look for recursion '//'
L112        if j<length(i) & i(j+1)==i(j)+1
L113            recursive = 1;
L111        %- Look for recursion '//'
L112        if j<length(i) && i(j+1)==i(j)+1
L113            recursive = 1;

With this modification the XMLTree toolbox and the XRDMLread should work also with Octave. However there are still several warning messages coming from the XMLTree toolbox and it is not possible to load some xml files, e.g. this basic example note.xml from W3C. There are many small "bugs" producing these warnings garbage and they are not explicitly specified here. You can try to apply our XMLTree patch to remove them. The patch includes also complete fixes for the critical bug above and modifications of the xml_findstr.c file described below.

The next paragraphs describe in detail modifications of the xml_findstr.c file. The changes are already included in the patch, hence if you have succeed in applying it, you only need to mex the file.

The XMLTree toolbox contains a mex function, xml_findstr, for fast string parsing. At the time this information was actual, the XMLTree toolbox package contained no appropriate compiled binary mex file for Octave, hence manual compilation is necessary to get the build-in mex function.

The xml_findstr, located in the xmltree/@xmltree/private directory, works maybe fine in Octave without compilation. If compiled it looks that there is a problem.

> cd xmltree/@xmltree/private
> s = 'How much wood would a woodchuck chuck?';
> xml_findstr(s,' ') % should return [4 9 14 20 22 32]
warning: xml_findstr is not compiled for your platform.
This will result in a slowdown of the XML parsing.
ans =

    4    9   14   20   22   32

> mex xml_findstr.c
> xml_findstr(s,' ') % should return [4 9 14 20 22 32]
ans = [](0x0)

To fix this problem, it is necessary to slightly modify the C source xml_findstr file. If a line 17: "#define __HACK_MXCHAR__" is commented, which is the most simple solution, it should help, but it can result in a function slowdown. In another way, it is possible to use the Guillaume Flandin's faster version, if Octave data storage format is included. It is assumed here that Octave stores strings as uint8/char (byte). A hybrid between two original approaches is then required. This can be done by following three steps.

L16 /* Comment the following line to use standard mxGetString (slower) */
L17 /*#define __HACK_MXCHAR__*/
L41     stext = mxGetM(prhs[0]) * mxGetN(prhs[0]);
L42 #if defined(__HACK_MXCHAR__) || defined (HAVE_OCTAVE) /*#ifdef __HACK…*/
L43     text = mxGetData(prhs[0]);
L52     spattern = mxGetM(prhs[1]) * mxGetN(prhs[1]);
L53 #if defined(__HACK_MXCHAR__) || defined (HAVE_OCTAVE) /*#ifdef __HACK…*/
L52     pattern = mxGetData(prhs[1]);
L101        /* Free memory */
L102    #if defined (HAVE_OCTAVE)
L103        if (k) mxRealloc(k,0);
L104    #else
L105        if (k) mxFree(k); /* original line 102 */
L106    #endif

The XMLTree toolbox should work with the mex-ed xml_findstr now.

> cd xmltree/@xmltree/private
> mex xml_findstr.c
> s = 'How much wood would a woodchuck chuck?';
> xml_findstr(s,' ') % should return [4 9 14 20 22 32]
ans =

    4    9   14   20   22   32
    
(Note: The step no. 3 should be omitted in Octave 3.4.)

All these modifications, including m-files fixes, can be found in our full XMLTree patch.


Installing XMLTree on 64-bit Windows and some older Matlab versions

The current XMLTree toolbox distribution should already contain an xml_findstr function compiled natively also for the 64-bit Windows systems. Hence this post is of a little relevance. However, in the case a new compilation is required the following paragraphs propose few short remarks concerning the issue.

Manual how to install Microsoft VC++ 2010 Express and SDK-4 to get an amd64 compiler, how to setup them with Matlab, as well as information about compatible compiler, SDK and Matlab versions can be found e.g. by following these links:

It looks that there should be no troubles from Matlab-2010b, whereas a patch (the second link) need to be applied for Matlab-2010a. From what the present author remembers, when solving a problem on colleague's computer, the troubles lie in the point that the SDK supporting 64-bit platforms and 64-bit Windows comes with two directories for “Program Files(64)”. Required files are distributed among both of them and Matlab does not detect properly location of necessary components. As a part of the setup Matlab creates a file: “c:/Users/userName/Application Data/MathWorks/MATLAB/R2010a/mexopts.bat” After fixing the paths in this file to point to the correct SDK and MSVC directories the compiler may be working.