Delete testxml code sample.

PiperOrigin-RevId: 573202693
Change-Id: Ic8d284293bd5c51693415d4186bb0b72a5416dca

doc/programming/index.rst

@@ -165,7 +165,7 @@ links below, to make this documentation self-contained.
 `mjxmacro.h <https://github.com/google-deepmind/mujoco/blob/main/include/mujoco/mjxmacro.h>`__
    This file is optional and is not included by mujoco.h. It defines :ref:`X Macros <tyXMacro>` that can
    automate the mapping of mjModel and mjData into scripting languages, as well as other operations that require
-   accessing all fields of mjModel and mjData. See code sample :ref:`testxml.cc <saTestXML>`.
+   accessing all fields of mjModel and mjData.
 `mjexport.h <https://github.com/google-deepmind/mujoco/blob/main/include/mujoco/mjexport.h>`__
    Macros used for exporting public symbols from the MuJoCo library. This header should not be used directly by client
    code.

doc/programming/samples.rst

@@ -26,28 +26,6 @@ profiling. The results are then printed in the console. To simulate controlled d
 one can either install the control callback :ref:`mjcb_control`, or set control signals
 explicitly as explained in the :ref:`simulation loop <siSimulation>` section below.
 
-.. _saTestXML:
-
-`testxml <https://github.com/google-deepmind/mujoco/blob/main/sample/testxml.cc>`_
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This code sample tests the parser, compiler and XML writer. The testing code does the following:
-
--  Parse and compile a specified XML model in MJCF or URDF. This yields an mjModel structure ready for simulation;
--  Save the model as a temporary MJCF file, using a "canonical" subset of MJCF where a number of conversions have
-   already been performed by the compiler;
--  Parse and compile the temporary MJCF file. This yields a second mjModel structure ready for simulation;
--  Compare the two mjModel structures field by field, and print the field with the largest numerical difference. Since
-   MJCF is a text format, the real-valued numbers saved in it have lower precision than the double precision used
-   internally, thus we cannot expect the two models to be identical on the bit level. But we can expect the largest
-   difference to be on the order of 1e-6. A substantially larger difference indicates a bug in the parser, compiler or
-   XML writer - and should be reported.
-
-The code uses the :ref:`X Macros <tyXMacro>` described in the Reference chapter. This is a convenient way
-to apply the same operation to all fields in mjModel, without explicitly typing their names. The code sample
-:ref:`simulate.cc <saSimulate>` also uses X Macros to implement a watch, where the user can type the name of any mjData
-field which is resolved at runtime.
-
 .. _saCompile:
 
 `compile <https://github.com/google-deepmind/mujoco/blob/main/sample/compile.cc>`_

doc/programming/simulation.rst

@@ -676,10 +676,7 @@ correct way to do it is the hard way:
    mju_copy(myqposqvel, d->qpos, m->nq + m->nv);
 
 The :ref:`X Macros <tyXMacro>` defined in the optional header file ``mjxmacro.h`` can be used to automate allocation of
-data structure that match mjModel and mjData, for example when writing a MuJoCo wrapper for a scripting language. In
-the code sample :ref:`testxml.cc <saTestXML>` we use these unusual macros to compare all data arrays from two instances
-of mjModel and find the one with the largest difference. Apparently X Macros were invented in the 1960's for assembly
-language, and remain a great idea.
+data structure that match mjModel and mjData, for example when writing a MuJoCo wrapper for a scripting language.
 
 .. _siStack:
 
@@ -841,13 +838,6 @@ forces are disabled) the underlying physical system is energy-conserving. In tha
 the total energy indicate inaccuracies in numerical integration. For such systems the Runge-Kutta integrator has much
 better performance than the default semi-implicit Euler integrator.
 
-Finally, the user can implement additional diagnostics as needed. Two examples were provided in the code samples
-``testxml.cc`` and ``derivative.cc``, where we computed model mismatches after save and load, and assessed the accuracy
-of the numerical derivatives respectively. Key to such diagnostics is to implement two different algorithms or
-simulation paths that compute the same quantity, and compare the results numerically. This type of sanity check is
-essential when dealing with complex dynamical systems where we do not really know what the numerical output should be;
-if we knew that, we would not be using a simulator in the first place.
-
 .. _siJacobian:
 
 Jacobians