From a6d5bda2f35a59397d7ace53cd2aea0eed71af35 Mon Sep 17 00:00:00 2001 From: ng0 Date: Tue, 5 Sep 2017 11:12:59 +0000 Subject: [PATCH] doc: gnunet-c-tutorial: replace \texttt with @code. --- doc/gnunet-c-tutorial.texi | 54 +++++++++++++++++++------------------- 1 file changed, 27 insertions(+), 27 deletions(-) diff --git a/doc/gnunet-c-tutorial.texi b/doc/gnunet-c-tutorial.texi index e157eeceb..60188287e 100644 --- a/doc/gnunet-c-tutorial.texi +++ b/doc/gnunet-c-tutorial.texi @@ -343,12 +343,12 @@ $ cat $PREFIX/share/gnunet/config.d/*.conf > peer2.conf Now you have to edit peer2.conf and change: \begin{itemize} \itemsep0em - \item{\texttt{GNUNET\_TEST\_HOME} under \texttt{PATHS}} - \item{Every (uncommented) value for ``\texttt{PORT}'' (add 10000) in any - section (the option may be commented out if \texttt{PORT} is + \item{@code{GNUNET\_TEST\_HOME} under @code{PATHS}} + \item{Every (uncommented) value for ``@code{PORT}'' (add 10000) in any + section (the option may be commented out if @code{PORT} is prefixed by "\#", in this case, UNIX domain sockets are used and the PORT option does not need to be touched) } - \item{Every value for ``\texttt{UNIXPATH}'' in any section (e.g. by adding a "-p2" suffix)} + \item{Every value for ``@code{UNIXPATH}'' in any section (e.g. by adding a "-p2" suffix)} \end{itemize} to a fresh, unique value. Make sure that the PORT numbers stay below 65536. From now on, whenever you interact with the second @@ -384,14 +384,14 @@ If you want the two peers to connect, you have multiple options: \end{itemize} To setup peer 1 as bootstrapping server change the configuration of the first one to be a hostlist server by adding the following lines to -\texttt{peer1.conf} to enable bootstrapping server: +@code{peer1.conf} to enable bootstrapping server: @example [hostlist] OPTIONS = -p @end example -Then change {\tt peer2.conf} and replace the ``\texttt{SERVERS}'' line in the ``\texttt{[hostlist]}'' section with -``\texttt{http://localhost:8080/}''. Restart both peers using: +Then change {\tt peer2.conf} and replace the ``@code{SERVERS}'' line in the ``@code{[hostlist]}'' section with +``@code{http://localhost:8080/}''. Restart both peers using: @example $ gnunet-arm -c peer1.conf -e # stop first peer $ gnunet-arm -c peer1.conf -s # start first peer @@ -407,12 +407,12 @@ by you. @subsubsection How to connect manually -If you want to use the \texttt{peerinfo} tool to connect your peers, you should: +If you want to use the @code{peerinfo} tool to connect your peers, you should: \begin{itemize} \itemsep0em \item{Set {\tt FORCESTART = NO} in section {\tt hostlist} (to not connect to the global GNUnet)} \item{Start both peers running {\tt gnunet-arm -c peer1.conf -s} and {\tt gnunet-arm -c peer2.conf -s}} - \item{Get \texttt{HELLO} message of the first peer running {\tt gnunet-peerinfo -c peer1.conf -g}} + \item{Get @code{HELLO} message of the first peer running {\tt gnunet-peerinfo -c peer1.conf -g}} \item{Give the output to the second peer by running {\tt gnunet-peerinfo -c peer2.conf -p ''}} \end{itemize} @@ -435,7 +435,7 @@ system. The testbed service can be access through its API @file{include/gnunet\_testbed\_service.h}. The API provides many routines for managing a group of peers. It also provides a helper function -\texttt{GNUNET\_TESTBED\_test\_run()} to quickly setup a minimalistic testing +@code{GNUNET\_TESTBED\_test\_run()} to quickly setup a minimalistic testing environment on a single host. This function takes a configuration file which will be used as a template @@ -463,7 +463,7 @@ $ gcc $CPPFLAGS $LDFLAGS -o testbed-test testbed_test.c -lgnunettestbed -lgnune $ touch template.conf # Generate (empty) configuration $ ./testbed-test # run it (press CTRL-C to stop) @end example -The \texttt{CPPFLAGS} and \texttt{LDFLAGS} are necessary if GNUnet is installed +The @code{CPPFLAGS} and @code{LDFLAGS} are necessary if GNUnet is installed into a different directory other than @file{/usr/local}. All of testbed API's peer management functions treat management actions as @@ -492,17 +492,17 @@ per-peer configuration. Accessing those configurations directly through file system is discouraged as their locations are dynamically created and will be different among various runs of testbed. To make access to these configurations easy, testbed API provides the function -\texttt{GNUNET\_TESTBED\_service\_connect()}. This function fetches the +@code{GNUNET\_TESTBED\_service\_connect()}. This function fetches the configuration of a given peer and calls the \textit{Connect Adapter}. -In the example code, it is the \texttt{dht\_ca}. A connect adapter is expected +In the example code, it is the @code{dht\_ca}. A connect adapter is expected to open the connection to the needed service by using the provided configuration and return the created service connection handle. Successful connection to the -needed service is signaled through \texttt{service\_connect\_comp\_cb}. +needed service is signaled through @code{service\_connect\_comp\_cb}. A dual to connect adapter is the \textit{Disconnect Adapter}. This callback is called after the connect adapter has been called when the operation from -\texttt{GNUNET\_TESTBED\_service\_connect()} is marked as ``done''. It has to -disconnect from the service with the provided service handle (\texttt{op\_result}). +@code{GNUNET\_TESTBED\_service\_connect()} is marked as ``done''. It has to +disconnect from the service with the provided service handle (@code{op\_result}). Exercise: Find out how many peers you can run on your system. @@ -557,11 +557,11 @@ In addition the ext systems provides: The first step for writing any extension with a new service is to ensure that the @file{ext.conf.in} file contains entries for the -\texttt{UNIXPATH}, \texttt{PORT} and \texttt{BINARY} for the service in a section named after +@code{UNIXPATH}, @code{PORT} and @code{BINARY} for the service in a section named after the service. If you want to adapt the template rename the @file{ext.conf.in} to match your -services name, you have to modify the \texttt{AC\_OUTPUT} section in @file{configure.ac} +services name, you have to modify the @code{AC\_OUTPUT} section in @file{configure.ac} in the @file{gnunet-ext} root. @section Writing a Client Application @@ -903,11 +903,11 @@ Exercise: Change the service to ``handle'' the message from your FIXME: This section still needs to be updated to the lastest API! -One of the most important services in GNUnet is the \texttt{CORE} service +One of the most important services in GNUnet is the @code{CORE} service managing connections between peers and handling encryption between peers. One of the first things any service that extends the P2P protocol typically does -is connect to the \texttt{CORE} service using: +is connect to the @code{CORE} service using: \lstset{language=C} \begin{lstlisting} @@ -925,7 +925,7 @@ GNUNET_CORE_connect (const struct GNUNET_CONFIGURATION_Handle *cfg, @subsection New P2P connections} Before any traffic with a different peer can be exchanged, the peer must be -known to the service. This is notified by the \texttt{CORE} {\tt connects} callback, +known to the service. This is notified by the @code{CORE} {\tt connects} callback, which communicates the identity of the new peer to the service: \lstset{language=C} @@ -943,13 +943,13 @@ Note that whatever you return from {\tt connects} is given as the {\it cls} argument to the message handlers for messages from the respective peer. -Exercise: Create a service that connects to the \texttt{CORE}. Then +Exercise: Create a service that connects to the @code{CORE}. Then start (and connect) two peers and print a message once your connect callback is invoked.} @subsection Receiving P2P Messages -To receive messages from \texttt{CORE}, you pass the desired +To receive messages from @code{CORE}, you pass the desired {\em handlers} to the {\tt GNUNET\_CORE\_connect()} function, just as we showed for services. @@ -1449,11 +1449,11 @@ $ valgrind gnunet-service-dht -L DEBUG Assuming other services are well-written, they will automatically re-integrate the restarted service with the peer. -GNUnet provides a powerful logging mechanism providing log levels \texttt{ERROR}, -\texttt{WARNING}, \texttt{INFO} and \texttt{DEBUG}. The current log level is +GNUnet provides a powerful logging mechanism providing log levels @code{ERROR}, +@code{WARNING}, @code{INFO} and @code{DEBUG}. The current log level is configured using the \lstinline|$GNUNET_FORCE_LOG| environmental variable. -The \texttt{DEBUG} level is only available if \lstinline|--enable-logging=verbose| was used when -running \texttt{configure}. More details about logging can be found under +The @code{DEBUG} level is only available if \lstinline|--enable-logging=verbose| was used when +running @code{configure}. More details about logging can be found under @uref{https://gnunet.org/logging}. You should also probably enable the creation of core files, by setting -- 2.25.1