more syntax highlighting in tutorials

doc/tutorial_client_firstSteps.rst

@@ -1,10 +1,8 @@
 First steps with open62541-client
-===================================
+=================================
 
 In the previous :doc:`tutorial_server_firstSteps` tutorial, you should have gotten your build environment verified and created a first OPC UA server using the open62541 stack. The created server however doesn't do much yet and there is no client to interact with the server. We are going to remedy that in this tutorial by creating some nodes and variables.
 
-----------------------
-
 You should already have a basic server from the previous tutorial. open62541 provides both a server- and clientside API, so creating a client is equally as easy as creating a server. We are going to use dynamic linking (libopen62541.so) from now on, because our client and server will share a lot of code. Reusing the shared library will considerably reduce the overhead. To avoid confusion, remove the amalgated open62541.c/h files from your example directory.
 
 As a recap, your directory structure should now look like this::
@@ -70,7 +68,8 @@ Asserting success/failure
 Almost all functions of the open62541 API will return a ``UA_StatusCode``, which in the C world would be represented by a ``unsigned int``. OPC UA defines large number of good and bad return codes represented by this number. The constant UA_STATUSCODE_GOOD is defined as 0 in ``include/ua_statuscodes.h`` along with many other return codes. It pays off to check the return code of your function calls, as we already did implicitly in the client.
 
 Minimalistic introduction to OPC UA nodes and node IDs
------------------------
+------------------------------------------------------
+
 OPC UA nodespace model defines 9 standard attribute for every node:
 
 +---------------+----------------+

doc/tutorial_noderelations.rst

@@ -10,7 +10,9 @@ So far we have made due with the hardcoded mini-namespace in the server stack. W
 
 Note beforehand that the pyUANamespace compiler you can find in the *tools* subfolder is *not* a XML transformation tool but a compiler. That means that it will create an internal representation (dAST) when parsing the XML files and attempt to understand this representation in order to generate C Code. In consequence, the compiler will refuse to print any inconsistencies or invalid nodes.
 
-As an example, we will create a simple object model using UA Modeller and embed this into the servers nodeset, which is exported to the following XML file::
+As an example, we will create a simple object model using UA Modeller and embed this into the servers nodeset, which is exported to the following XML file:
+
+.. code-block:: xml
 
     <UANodeSet xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:uax="http://opcfoundation.org/UA/2008/02/Types.xsd" xmlns="http://opcfoundation.org/UA/2011/03/UANodeSet.xsd" xmlns:s1="http://yourorganisation.org/example_nodeset/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
         <NamespaceUris>
@@ -282,7 +284,9 @@ And at this point, you are going to see the compiler hanging again. If you speci
   Linking C shared library libopen62541.so
   [100%] Built target open62541
 
-If you open the header ``src_generated/ua_namespaceinit_generated.h`` and take a short look at the generated defines, you will notice the following definitions have been created::
+If you open the header ``src_generated/ua_namespaceinit_generated.h`` and take a short look at the generated defines, you will notice the following definitions have been created:
+
+.. code-block:: c
   
   #define UA_NS1ID_PROVIDESINPUTTO
   #define UA_NS1ID_FIELDDEVICE
@@ -310,16 +314,18 @@ A minor list of some of the miriad things that can go wrong:
 Creating object instances
 -------------------------
 
-Defining an object type is only usefull if it ends up making our lives easier in some way (though it is always the proper thing to do). One of the key benefits of defining object types is being able to create object instances fairly easily. As an example, we will modify the server to create 2 pump instances::
+Defining an object type is only usefull if it ends up making our lives easier in some way (though it is always the proper thing to do). One of the key benefits of defining object types is being able to create object instances fairly easily. As an example, we will modify the server to create 2 pump instances:
+
+.. code-block:: c
 
     #include <stdio.h>
     #include <signal.h>
 
-    # include "ua_types.h"
-    # include "ua_server.h"
-    # include "ua_namespaceinit_generated.h"
-    # include "logger_stdout.h"
-    # include "networklayer_tcp.h"
+    #include "ua_types.h"
+    #include "ua_server.h"
+    #include "ua_namespaceinit_generated.h"
+    #include "logger_stdout.h"
+    #include "networklayer_tcp.h"
 
     UA_Boolean running;
     UA_Int32 global_accessCounter = 0;
@@ -418,7 +424,9 @@ Iterating over Child nodes
 
 A common usecase is wanting to perform something akin to ``for each node referenced by X, call ...``; you may for example be searching for a specific browseName or instance which was created with a dynamic nodeId. There is no way of telling what you are searching for beforehand (inverse hasComponents, typedefinitions, etc.), but all usescases of "searching for" basically means iterating over each reference of a node.
 
-Since searching in nodes is a common operation, the high-level branch provides a function to help you perform this operation:  ``UA_(Server|Client)_forEachChildNodeCall();``. These functions will iterate over all references of a given node, invoking a callback (with a handle) for every found reference. Since in our last tutorial we created a server that instantiates two pumps, we are now going to build a client that will search for pumps in all object instances on the server.::
+Since searching in nodes is a common operation, the high-level branch provides a function to help you perform this operation:  ``UA_(Server|Client)_forEachChildNodeCall();``. These functions will iterate over all references of a given node, invoking a callback (with a handle) for every found reference. Since in our last tutorial we created a server that instantiates two pumps, we are now going to build a client that will search for pumps in all object instances on the server.
+
+.. code-block:: c
 
     #include <stdio.h>
 
@@ -502,16 +510,18 @@ You can use the handle to contain a pointer to a struct, which can hold multiple
 Examining node copies
 ---------------------
 
-So far we have always used the getAttribute() functions to inspect node contents. There may be isolated cases where these are insuficient because you want to examine the properties of a node "in bulk". As mentioned in the first tutorials, the user can not directly interact with the servers nodestore; but the userspace may request a copy of a node, including all its attributes and references. The following functions server the purpose of getting and getting rid of node copies::
+So far we have always used the getAttribute() functions to inspect node contents. There may be isolated cases where these are insuficient because you want to examine the properties of a node "in bulk". As mentioned in the first tutorials, the user can not directly interact with the servers nodestore; but the userspace may request a copy of a node, including all its attributes and references. The following functions server the purpose of getting and getting rid of node copies.
+
+.. code-block:: c
   
     UA_(Server|Client)_getNodeCopy()
     UA_(Server|Client)_destroyNodeCopy()
 
-
 Since you are trying to see a struct (node types) that are usually hidden from userspace, you will have to include ``include/ua_nodes.h``, ``src/ua_types_encoding_binary.h`` and ``deps/queue.h`` in addition to the previous includes (link them into the includes folder).
 
-Let's suppose we wanted to do something elaborate with our pump instance that was returned by the iterator of the previous example, or simply "print" all its fields. We could modify the above client's main function like so::
+Let's suppose we wanted to do something elaborate with our pump instance that was returned by the iterator of the previous example, or simply "print" all its fields. We could modify the above client's main function like so:
 
+.. code-block:: c
 
     int main(void) {
       UA_Client *client = UA_Client_new(UA_ClientConfig_standard, Logger_Stdout_new());

doc/tutorial_server_firstSteps.rst

@@ -124,7 +124,9 @@ Let's build a very rudimentary server. Create a separate folder for your applica
    `-- myServer.c
    :myServerApp> touch myServer.c
 
-Open myServer.c and write/paste your minimal server application::
+Open myServer.c and write/paste your minimal server application:
+
+.. code-block:: c
 
    #include <stdio.h>
 
@@ -156,15 +158,17 @@ Now execute the server::
 
 You have now compiled and started your first OPC UA Server. Though quite unspectacular and only terminatable with ``CTRL+C`` (SIGTERM) at the moment, you can already launch it and browse around with UA Expert. The Server will be listening on localhost:16664 - go ahead and give it a try.
 
-We will also make a slight change to our server: We want it to exit cleanly when pressing ``CTRL+C``. We will add signal handler for SIGINT and SIGTERM to accomplish that to the server::
+We will also make a slight change to our server: We want it to exit cleanly when pressing ``CTRL+C``. We will add signal handler for SIGINT and SIGTERM to accomplish that to the server:
+
+.. code-block:: c
 
     #include <stdio.h>
     #include <signal.h>
 
-    # include "ua_types.h"
-    # include "ua_server.h"
-    # include "logger_stdout.h"
-    # include "networklayer_tcp.h"
+    #include "ua_types.h"
+    #include "ua_server.h"
+    #include "logger_stdout.h"
+    #include "networklayer_tcp.h"
 
     UA_Boolean running;
     UA_Logger logger;
@@ -256,11 +260,12 @@ You can now start the server and browse around as before. As you might have noti
 
 The next step is to simplify the header dependencies. Instead of picking header files one-by-one, we can use the copied amalgamated header including all the public headers dependencies.
 
-Open myServer.c and simplify it to::
+Open myServer.c and simplify it to:
 
-   #include <stdio.h>
+.. code-block:: c
 
-   # include "open62541.h"
+   #include <stdio.h>
+   #include "open62541.h"
 
    UA_Boolean running;
    int main(void) {

doc/tutorial_server_variables.rst

@@ -1,13 +1,15 @@
 Adding nodes to a server and connecting nodes to user-defined values
-======================
+====================================================================
 
 This tutorial shows how to add variable nodes to a server and how these can be connected to user-defined values and callbacks.
 
 Firstly, we need to introduce a concept of Variants. This is a data structure able to hold any datatype.
 
 Variants
----------------------
-The datatype UA_Variant a belongs to the built-in datatypes of OPC UA and is used as a container type. A Variant can hold any other built-in scalar datatype (except Variants) or array built-in datatype (array of variants too). The variant is structured like this in open62541::
+--------
+The datatype UA_Variant a belongs to the built-in datatypes of OPC UA and is used as a container type. A Variant can hold any other built-in scalar datatype (except Variants) or array built-in datatype (array of variants too). The variant is structured like this in open62541:
+
+.. code-block:: c
 
 	typedef struct {
 		const UA_DataType *type; ///< The nodeid of the datatype
@@ -43,14 +45,14 @@ The members of the struct are
 * arrayDimensions: dimensinos array in case the array is interpreted as a multi-dimensional construction, e.g., [5,5] for a 5x5 matrix
 
 Adding a variable node to the server that contains a user-defined variable
----------------------
+--------------------------------------------------------------------------
 
 This simple case allows to 'inject' a pre-defined variable into a variable node. The variable is wrapped by a "UA_Variant" before being insterted into the node.
 
 Consider 'examples/server_variable.c' in the repository. The examples are compiled if the Cmake option BUILD_EXAMPLE is turned on.
 
-Adding a variable node to the server that contains a user-defined callback.
----------------------
+Adding a variable node to the server that contains a user-defined callback
+--------------------------------------------------------------------------
 
 The latter case allows to define callback functions that are executed on read or write of the node. In this case an "UA_DataSource" containing the respective callback pointer is intserted into the node.