[GNUnet-SVN] [gnunet-texinfo] branch master updated: developer.texi: syntax fixes

[gnunet]

This is an automated email from the git hooks/post-receive script.

ng0 pushed a commit to branch master
in repository gnunet-texinfo.

The following commit(s) were added to refs/heads/master by this push:
     new b71dd9e  developer.texi: syntax fixes
b71dd9e is described below

commit b71dd9ed9531f130d5fd5803e6d3a6e97db8d67a
Author: ng0 <address@hidden>
AuthorDate: Fri Feb 17 16:57:49 2017 +0000

    developer.texi: syntax fixes
---
 developer.texi | 619 +++++++++++++++++++--------------------------------------
 1 file changed, 208 insertions(+), 411 deletions(-)

diff --git a/developer.texi b/developer.texi
index b9ea42e..cacb56f 100644
--- a/developer.texi
+++ b/developer.texi
@@ -354,7 +354,6 @@ advertisements for bogus websites.
 @c ***************************************************************************
 @node Introduction
 @chapter Introduction
address@hidden %**end of header
 
 This developer handbook is intended as first introduction to GNUnet for new
 developers that want to extend the GNUnet framework. After the introduction,
@@ -367,14 +366,10 @@ New developers can have a look a the GNUnet tutorials for 
C and java available
 in the src/ directory of the repository or under the following links:
 @itemize
 @bullet
-
-
 @item GNUnet C tutorial
-
 @item GNUnet Java tutorial
 @end itemize
 
-
 In addition to this book, the GNUnet server contains various resources for
 GNUnet developers. They are all conveniently reachable via the "Developer"
 entry in the navigation menu. Some additional tools (such as static analysis
@@ -383,9 +378,7 @@ you feel you need access, you should contact
 @uref{http://grothoff.org/christian/, Christian Grothoff}, GNUnet's maintainer.
 
 The public subsystems on the GNUnet server that help developers are:
address@hidden
address@hidden
-
address@hidden @bullet
 
 @item The Version control system keeps our code and enables distributed
 development. Only developers with write access can commit code, everyone else
@@ -423,19 +416,9 @@ Automatically generated, current reports on the test suite 
are here.
 Current reports on test coverage are here.
 @end itemize
 
address@hidden @bullet
-
-
address@hidden
-
-
address@hidden Deutsch
address@hidden itemize
address@hidden Project overview @c %**end of header
-
address@hidden Top
-
-
address@hidden 
***************************************************************************
address@hidden Project overview
address@hidden Project overview
 
 The GNUnet project consists at this point of several sub-projects. This section
 is supposed to give an initial overview about the various sub-projects. Note
@@ -466,7 +449,8 @@ and media helping drive the GNUnet website
 GNUnet nodes on testbeds for research, development, testing and evaluation
 @item svn/gnunet-qt/ qt-based GNUnet GUI (dead?)
 @item svn/gnunet-cocoa/
-cocoa-based GNUnet GUI (dead?) @end table
+cocoa-based GNUnet GUI (dead?)
address@hidden table
 
 
 We are also working on various supporting libraries and tools:
@@ -486,17 +470,10 @@ accessing satellite connection quality reports @end table
 
 Finally, there are various external projects (see links for a list of those
 that have a public website) which build on top of the GNUnet framework.
address@hidden @bullet
-
-
address@hidden
-
address@hidden itemize
address@hidden Code overview @c %**end of header
-
address@hidden Top
-
 
address@hidden 
***************************************************************************
address@hidden Code overview
address@hidden Code overview
 
 This section gives a brief overview of the GNUnet source code. Specifically, we
 sketch the function of each of the subdirectories in the @code{gnunet/src/}
@@ -670,21 +647,12 @@ of peers to agree on a set of values via a distributed 
set union computation.
 @item rest/ The rest API allows access to GNUnet services using RESTful
 interaction. The services provide plugins that can exposed by the rest server.
 @item experimentation/ The experimentation daemon coordinates distributed
-experimentation to evaluate transport and ats properties @end table
-
address@hidden
address@hidden
-
-
address@hidden
-
address@hidden itemize
address@hidden System Architecture
address@hidden %**end of header
-
address@hidden Top
-
+experimentation to evaluate transport and ats properties
address@hidden table
 
address@hidden 
***************************************************************************
address@hidden System Architecture
address@hidden System Architecture
 
 GNUnet developers like legos. The blocks are indestructible, can be stacked
 together to construct complex buildings and it is generally easy to swap one
@@ -696,24 +664,20 @@ based on legos:
 This chapter documents the GNUnet lego system, also known as GNUnet's system
 architecture.
 
- The most common GNUnet component is a service. Services offer an API (or
- several, depending on what you count as "an API") which is implemented as a
- library. The library communicates with the main process of the service using a
- service-specific network protocol. The main process of the service typically
- doesn't fully provide everything that is needed --- it has holes to be filled
- by APIs to other services.
-
- A special kind of component in GNUnet are user interfaces and daemons. Like
- services, they have holes to be filled by APIs of other services. Unlike
- services, daemons do not implement their own network protocol and they have no
- API:
-
-
-
- The GNUnet system provides a range of services, daemons and user interfaces,
- which are then combined into a layered GNUnet instance (also known as a peer).
+The most common GNUnet component is a service. Services offer an API (or
+several, depending on what you count as "an API") which is implemented as a
+library. The library communicates with the main process of the service using a
+service-specific network protocol. The main process of the service typically
+doesn't fully provide everything that is needed --- it has holes to be filled
+by APIs to other services.
 
+A special kind of component in GNUnet are user interfaces and daemons. Like
+services, they have holes to be filled by APIs of other services. Unlike
+services, daemons do not implement their own network protocol and they have no
+API:
 
+The GNUnet system provides a range of services, daemons and user interfaces,
+which are then combined into a layered GNUnet instance (also known as a peer).
 
 Note that while it is generally possible to swap one service for another
 compatible service, there is often only one implementation. However, during
@@ -724,21 +688,15 @@ other parts of the service can continue their development 
by simply using the
 swapping out individual components. This is typically achieved by simply
 changing the name of the "BINARY" in the respective configuration section.
 
- Key properties of GNUnet services are that they must be separate processes and
- that they must protect themselves by applying tight error checking against the
- network protocol they implement (thereby achieving a certain degree of
- robustness).
-
- On the other hand, the APIs are implemented to tolerate failures of the
- service, isolating their host process from errors by the service. If the
- service process crashes, other services and daemons around it should not also
- fail, but instead wait for the service process to be restarted by ARM.
- @itemize @bullet
-
-
address@hidden
+Key properties of GNUnet services are that they must be separate processes and
+that they must protect themselves by applying tight error checking against the
+network protocol they implement (thereby achieving a certain degree of
+robustness).
 
address@hidden itemize
+On the other hand, the APIs are implemented to tolerate failures of the
+service, isolating their host process from errors by the service. If the
+service process crashes, other services and daemons around it should not also
+fail, but instead wait for the service process to be restarted by ARM.
 
 @multitable @columnfractions 0.333333333333333 0.333333333333333
 0.333333333333333
@@ -760,12 +718,10 @@ changing the name of the "BINARY" in the respective 
configuration section.
 @tab 23.32 KB
 
 @end multitable
address@hidden Subsystem stability
address@hidden %**end of header
-
address@hidden Top
-
 
address@hidden 
***************************************************************************
address@hidden Subsystem stability
address@hidden Subsystem stability
 
 This page documents the current stability of the various GNUnet subsystems.
 Stability here describes the expected degree of compatibility with future
@@ -780,7 +736,8 @@ relevant to developers that hope to be able to avoid 
changes to applications
 build on top of the APIs of the framework.
 
 The following table summarizes our current view of the stability of the
-respective protocols or APIs: @multitable @columnfractions 0.0263157894736842
+respective protocols or APIs: 
address@hidden @columnfractions 0.0263157894736842
 0.0263157894736842 0.0263157894736842 0.0263157894736842 0.0263157894736842
 0.0263157894736842 0.0263157894736842 0.0263157894736842 0.0263157894736842
 0.0263157894736842 0.0263157894736842 0.0263157894736842 0.0263157894736842
@@ -1121,227 +1078,151 @@ where this subsystem is headed
 @item n/a this subsystem does not have an
 API/IPC-protocol/P2P-protocol @end table
 
address@hidden @bullet
-
-
address@hidden
-
address@hidden itemize
address@hidden Naming conventions and coding style guide
address@hidden %**end of
-header
-
address@hidden Top
-
-
address@hidden 
***************************************************************************
address@hidden Naming conventions and coding style guide
address@hidden Naming conventions and coding style guide
 
 Here you can find some rules to help you write code for GNUnet.
 
address@hidden Naming conventions
address@hidden %**end of header
-
address@hidden Top
-
address@hidden include files
address@hidden %**end of header
-
address@hidden Top
address@hidden 
***************************************************************************
address@hidden Naming conventions
address@hidden Naming conventions
 
address@hidden 
***************************************************************************
address@hidden include files
address@hidden include files
 
 @itemize @bullet
-
-
 @item _lib: library without need for a process
-
 @item _service: library that needs a service process
-
 @item _plugin: plugin definition
-
 @item _protocol: structs used in network protocol
-
 @item exceptions:
 @itemize @bullet
-
-
 @item gnunet_config.h --- generated
-
 @item platform.h --- first included
-
 @item plibc.h --- external library
-
 @item gnunet_common.h --- fundamental routines
-
 @item gnunet_directories.h --- generated
-
 @item gettext.h --- external library
 @end itemize
-
 @end itemize
address@hidden binaries
address@hidden %**end of header
-
address@hidden Top
 
address@hidden 
***************************************************************************
address@hidden binaries
address@hidden binaries
 
 @itemize @bullet
-
-
 @item gnunet-service-xxx: service process (has listen socket)
-
 @item gnunet-daemon-xxx: daemon process (no listen socket)
-
 @item gnunet-helper-xxx[-yyy]: SUID helper for module xxx
-
 @item gnunet-yyy: command-line tool for end-users
-
 @item libgnunet_plugin_xxx_yyy.so: plugin for API xxx
-
 @item libgnunetxxx.so: library for API xxx
 @end itemize
address@hidden logging @c
-%**end of header
-
address@hidden Top
 
address@hidden 
***************************************************************************
address@hidden logging
address@hidden logging
 
 @itemize @bullet
-
-
 @item services and daemons use their directory name in GNUNET_log_setup (i.e.
 'core') and log using plain 'GNUNET_log'.
-
 @item command-line tools use their full name in GNUNET_log_setup (i.e.
 'gnunet-publish') and log using plain 'GNUNET_log'.
-
 @item service access libraries log using 'GNUNET_log_from' and use
 'DIRNAME-api' for the component (i.e. 'core-api')
-
 @item pure libraries (without associated service) use 'GNUNET_log_from' with
 the component set to their library name (without lib or '.so'), which should
 also be their directory name (i.e. 'nat')
-
 @item plugins should use 'GNUNET_log_from' with the directory name and the
 plugin name combined to produce the component name (i.e. 'transport-tcp').
-
 @item logging should be unified per-file by defining a LOG macro with the
 appropriate arguments, along these lines:@ #define LOG(kind,...)
-GNUNET_log_from (kind, "example-api",__VA_ARGS__) @end itemize @settitle
-configuration
address@hidden %**end of header
-
address@hidden Top
+GNUNET_log_from (kind, "example-api",__VA_ARGS__)
address@hidden itemize
 
address@hidden 
***************************************************************************
address@hidden configuration
address@hidden configuration
 
 @itemize @bullet
-
-
 @item paths (that are substituted in all filenames) are in PATHS (have as few
 as possible)
-
 @item all options for a particular module (src/MODULE) are under [MODULE]
address@hidden options for a plugin of a module are under [MODULE-PLUGINNAME]
address@hidden itemize
 
address@hidden options for a plugin of a module are under [MODULE-PLUGINNAME] 
@end
-itemize @settitle exported symbols @c %**end of header
-
address@hidden Top
-
address@hidden 
***************************************************************************
address@hidden exported symbols
address@hidden exported symbols
 
 @itemize @bullet
-
-
 @item must start with "GNUNET_modulename_" and be defined in "modulename.c"
address@hidden exceptions: those defined in gnunet_common.h
address@hidden itemize
 
address@hidden exceptions: those defined in gnunet_common.h @end itemize 
@settitle
-private (library-internal) symbols (including structs and macros) @c %**end of
-header
-
address@hidden Top
-
address@hidden 
***************************************************************************
address@hidden private (library-internal) symbols (including structs and macros)
address@hidden private (library-internal) symbols (including structs and macros)
 
 @itemize @bullet
-
-
 @item must NOT start with any prefix
-
 @item must not be exported in a way that linkers could use them or@ other
 libraries might see them via headers; they must be either@ declared/defined in
 C source files or in headers that are in@ the respective directory under
 src/modulename/ and NEVER be@ declared in src/include/.
 @end itemize
address@hidden testcases
address@hidden %**end of header
-
address@hidden Top
-
address@hidden testcases
address@hidden testcases
 
 @itemize @bullet
-
-
 @item must be called "test_module-under-test_case-description.c"
-
 @item "case-description" maybe omitted if there is only one test
 @end itemize
address@hidden performance tests
address@hidden %**end of header
-
address@hidden Top
 
address@hidden 
***************************************************************************
address@hidden performance tests
address@hidden performance tests
 
 @itemize @bullet
-
-
 @item must be called "perf_module-under-test_case-description.c"
-
 @item "case-description" maybe omitted if there is only one performance test
-
 @item Must only be run if HAVE_BENCHMARKS is satisfied
 @end itemize
address@hidden src/ directories
address@hidden %**end of header
-
address@hidden Top
 
address@hidden 
***************************************************************************
address@hidden src/ directories
address@hidden src/ directories
 
 @itemize @bullet
-
-
 @item gnunet-NAME: end-user applications (i.e., gnunet-search, gnunet-arm)
-
 @item gnunet-service-NAME: service processes with accessor library (i.e.,
 gnunet-service-arm)
-
 @item libgnunetNAME: accessor library (_service.h-header) or standalone library
 (_lib.h-header)
-
 @item gnunet-daemon-NAME: daemon process without accessor library (i.e.,
 gnunet-daemon-hostlist) and no GNUnet management port
-
 @item libgnunet_plugin_DIR_NAME: loadable plugins (i.e.,
 libgnunet_plugin_transport_tcp)
 @end itemize
address@hidden Coding style
address@hidden %**end of header
-
-
address@hidden Top
 
address@hidden 
***************************************************************************
address@hidden Coding style
address@hidden Coding style
 
 @itemize @bullet
-
-
 @item GNU guidelines generally apply
-
 @item Indentation is done with spaces, two per level, no tabs
-
 @item C99 struct initialization is fine
-
 @item declare only one variable per line, so@
-
address@hidden  int i; int j; @end example
-
-
- instead of @example  int i,j; @end example
-
address@hidden
+int i; int j;
address@hidden example
+instead of
address@hidden
+int i,j;
address@hidden example
 
 This helps keep diffs small and forces developers to think precisely about the
 type of every variable. Note that @code{char *} is different from @code{const
@@ -1356,19 +1237,25 @@ be acceptable.
 accidental assignment) and with the 'true' target being either the 'error' case
 or the significantly simpler continuation. For example:@
 
address@hidden if (0 != stat ("filename," &sbuf)) @{ error(); @} else @{
address@hidden
+if (0 != stat ("filename," &sbuf)) @{ error(); @} else @{
   /* handle normal case here */
address@hidden @end example
address@hidden
address@hidden example
 
 
-instead of @example if (stat ("filename," &sbuf) == 0) @{
+instead of
address@hidden
+if (stat ("filename," &sbuf) == 0) @{
   /* handle normal case here */
address@hidden else @{ error(); @} @end example
address@hidden else @{ error(); @}
address@hidden example
 
 
 If possible, the error clause should be terminated with a 'return' (or 'goto'
 to some cleanup routine) and in this case, the 'else' clause should be omitted:
address@hidden if (0 != stat ("filename," &sbuf)) @{ error(); return; @}
address@hidden
+if (0 != stat ("filename," &sbuf)) @{ error(); return; @}
 /* handle normal case here */
 @end example
 
@@ -1388,33 +1275,42 @@ example
 @item Use @code{break} and @code{continue} wherever possible to avoid deep(er)
 nesting. Thus, we would write:@
 
address@hidden = head; while (NULL != (pos = next)) @{ next = pos->next; if (!
address@hidden
+next = head; while (NULL != (pos = next)) @{ next = pos->next; if (!
 should_free (pos)) continue; GNUNET_CONTAINER_DLL_remove (head, tail, pos);
-GNUNET_free (pos); @} @end example
+GNUNET_free (pos); @}
address@hidden example
 
 
-instead of @examplenext = head; while (NULL != (pos = next)) @{ next =
+instead of
address@hidden
+next = head; while (NULL != (pos = next)) @{ next =
 pos->next; if (should_free (pos)) @{
     /* unnecessary nesting! */
     GNUNET_CONTAINER_DLL_remove (head, tail, pos); GNUNET_free (pos); @} @}
-    @end example
address@hidden example
 
 
 @item We primarily use @code{for} and @code{while} loops. A @code{while} loop
 is used if the method for advancing in the loop is not a straightforward
 increment operation. In particular, we use:@
 
address@hidden = head; while (NULL != (pos = next)) @{ next = pos->next; if (!
address@hidden
+next = head; while (NULL != (pos = next)) @{ next = pos->next; if (!
 should_free (pos)) continue; GNUNET_CONTAINER_DLL_remove (head, tail, pos);
-GNUNET_free (pos); @} @end example
+GNUNET_free (pos); @}
address@hidden example
 
 
 to free entries in a list (as the iteration changes the structure of the list
 due to the free; the equivalent @code{for} loop does no longer follow the
 simple @code{for} paradigm of @code{for(INIT;TEST;INC)}). However, for loops
 that do follow the simple @code{for} paradigm we do use @code{for}, even if it
-involves linked lists: @example/* simple iteration over a linked list */ for
-(pos = head; NULL != pos; pos = pos->next) @{ use (pos); @} @end example
+involves linked lists:
address@hidden
+/* simple iteration over a linked list */ for
+(pos = head; NULL != pos; pos = pos->next) @{ use (pos); @}
address@hidden example
 
 
 @item The first argument to all higher-order functions in GNUnet must be
@@ -1422,22 +1318,30 @@ declared to be of type @code{void *} and is reserved 
for a closure. We do not
 use inner functions, as trampolines would conflict with setups that use
 non-executable stacks.@ The first statement in a higher-order function, which
 unusually should be part of the variable declarations, should assign the
address@hidden argument to the precise expected type. For example: @exampleint
-callback (void *cls, char *args) @{ struct Foo *foo = cls; int other_variables;
address@hidden argument to the precise expected type. For example:
address@hidden
+int callback (void *cls, char *args) @{
+  struct Foo *foo = cls; int other_variables;
 
    /* rest of function */
address@hidden @end example
address@hidden
address@hidden example
 
 
 @item It is good practice to write complex @code{if} expressions instead of
 using deeply nested @code{if} statements. However, except for addition and
 multiplication, all operators should use parens. This is fine:@
 
address@hidden ( (1 == foo) || ((0 == bar) && (x != y)) ) return x; @end example
address@hidden
+if ( (1 == foo) || ((0 == bar) && (x != y)) ) return x;
address@hidden example
 
 
-However, this is not: @exampleif (1 == foo) return x; if (0 == bar && x != y)
-return x; @end example
+However, this is not:
address@hidden
+if (1 == foo) return x; if (0 == bar && x != y)
+return x; 
address@hidden example
 
 
 Note that splitting the @code{if} statement above is debateable as the
@@ -1454,12 +1358,10 @@ line (possibly followed by a comment describing the 
following step). The code
 should not contain empty lines in arbitrary places; if in doubt, it is likely
 better to NOT have an empty line (this way, more code will fit on the screen).
 @end itemize
address@hidden Build-system
address@hidden %**end of header
-
address@hidden Top
-
 
address@hidden 
***************************************************************************
address@hidden Build-system
address@hidden Build-system
 
 If you have code that is likely not to compile or build rules you might want to
 not trigger for most developers, use "if HAVE_EXPERIMENTAL" in your
@@ -1467,36 +1369,24 @@ Makefile.am. Then it is OK to (temporarily) add 
non-compiling (or
 known-to-not-port) code.
 
 If you want to compile all testcases but NOT run them, run configure with the@
---enable-test-suppression option.
address@hidden option.
 
 If you want to run all testcases, including those that take a while, run
-configure with the@ --enable-expensive-testcases option.
+configure with the@ @code{--enable-expensive-testcases} option.
 
 If you want to compile and run benchmarks, run configure with the@
---enable-benchmarks option.
address@hidden option.
 
 If you want to obtain code coverage results, run configure with the@
---enable-coverage option and run the coverage.sh script in contrib/.
address@hidden
address@hidden
-
-
address@hidden
-
address@hidden itemize
address@hidden Developing extensions for GNUnet using the gnunet-ext template
address@hidden %**end of header
-
address@hidden Top
address@hidden option and run the coverage.sh script in contrib/.
 
address@hidden 
***************************************************************************
address@hidden Developing extensions for GNUnet using the gnunet-ext template
address@hidden Developing extensions for GNUnet using the gnunet-ext template
 
 @itemize @bullet
-
-
 @item Matthias Wachs's blog
-
 @item
-
 @end itemize
 
 
@@ -1521,12 +1411,11 @@ path, you have to add @code{/path/to/gnunet} to the 
file @code{/etc/ld.so.conf}
 and run @code{ldconfig} or your add it to the environmental variable
 @code{LD_LIBRARY_PATH} by using
 
address@hidden LD_LIBRARY_PATH=/path/to/gnunet/address@hidden Writing testcases 
@c
-%**end of header
-
address@hidden Top
-
address@hidden LD_LIBRARY_PATH=/path/to/gnunet/lib}
 
address@hidden 
***************************************************************************
address@hidden Writing testcases
address@hidden Writing testcases
 
 Ideally, any non-trivial GNUnet code should be covered by automated testcases.
 Testcases should reside in the same place as the code that is being tested. The
@@ -1543,10 +1432,10 @@ method of the testcase. The integration with the 
autotools is relatively
 straightforward and only requires modifications to the @code{Makefile.am} in
 the directory containing the testcase. For a testcase testing the code in
 @code{foo.c} the @code{Makefile.am} would contain the following lines:
address@hidden = test_foo TESTS = $(check_PROGRAMS) test_foo_SOURCES =
-test_foo.c test_foo_LDADD = $(top_builddir)/src/util/libgnunetutil.la @end
-example
-
address@hidden
+check_PROGRAMS = test_foo TESTS = $(check_PROGRAMS) test_foo_SOURCES =
+test_foo.c test_foo_LDADD = $(top_builddir)/src/util/libgnunetutil.la
address@hidden example
 
 Naturally, other libraries used by the testcase may be specified in the
 @code{LDADD} directive as necessary.
@@ -1554,7 +1443,9 @@ Naturally, other libraries used by the testcase may be 
specified in the
 Often testcases depend on additional input files, such as a configuration file.
 These support files have to be listed using the EXTRA_DIST directive in order
 to ensure that they are included in the distribution. Example:
address@hidden = test_foo_data.conf @end example
address@hidden
+EXTRA_DIST = test_foo_data.conf
address@hidden example
 
 
 Executing @code{make check} will run all testcases in the current directory and
@@ -1563,18 +1454,11 @@ all subdirectories. Testcases can be compiled 
individually by running
 that due to the use of plugins in GNUnet, it is typically necessary to run
 @code{make install} before running any testcases. Thus the canonical command
 @code{make check install} has to be changed to @code{make install check} for
-GNUnet.  @itemize @bullet
-
-
address@hidden
-
address@hidden itemize
address@hidden GNUnet's TESTING library
address@hidden %**end of header
-
address@hidden Top
-
+GNUnet.
 
address@hidden 
***************************************************************************
address@hidden GNUnet's TESTING library
address@hidden GNUnet's TESTING library
 
 The TESTING library is used for writing testcases which involve starting a
 single or multiple peers. While peers can also be started by testcases using
@@ -1600,12 +1484,11 @@ TESTING library only handles creating, starting and 
stopping peers. Features
 useful for testcases such as connecting peers in a topology are not available
 in TESTING but are available in the TESTBED subsystem. Furthermore, TESTING
 only creates peers on the localhost, however by using TESTBED testcases can
-benefit from creating peers across multiple address@hidden API @c %**end of
-header
-
address@hidden Top
-
+benefit from creating peers across multiple hosts.
 
address@hidden 
***************************************************************************
address@hidden API
address@hidden API
 
 TESTING abstracts a group of peers as a TESTING system. All peers in a system
 have common hostname and no two services of these peers have a same port or a
@@ -1649,11 +1532,11 @@ Peers can be started and stopped by calling the 
functions
 respectively. A peer can be destroyed by calling the function
 @code{GNUNET_TESTING_peer_destroy}. When a peer is destroyed, the ports and
 paths in allocated in its configuration are reclaimed for usage in new
address@hidden Finer control over peer stop @c %**end of header
-
address@hidden Top
-
+peers.
 
address@hidden 
***************************************************************************
address@hidden Finer control over peer stop
address@hidden Finer control over peer stop
 
 Using @code{GNUNET_TESTING_peer_stop()} is normally fine for testcases.
 However, calling this function for each peer is inefficient when trying to
@@ -1676,12 +1559,10 @@ An asynchronous peer stop can be cancelled by calling 
the function
 does not prevent the peer from terminating if the termination signal has
 already been sent to it. It does, however, cancels the callback to be called
 when the peer is stopped.
address@hidden Helper functions
address@hidden %**end of header
-
address@hidden Top
-
 
address@hidden 
***************************************************************************
address@hidden Helper functions
address@hidden Helper functions
 
 Most of the testcases can benefit from an abstraction which configures a peer
 and starts it. This is provided by the function
@@ -1695,19 +1576,10 @@ peer which starts the rest of the configured services. 
A similar function
 @code{GNUNET_TESTING_service_run} can be used to just start a single service of
 a peer. In this case, the peer's ARM service is not started; instead, only the
 given service is run.
address@hidden
address@hidden
-
-
address@hidden
-
address@hidden itemize
address@hidden Testing with multiple processes
address@hidden %**end of header
-
address@hidden Top
-
 
address@hidden 
***************************************************************************
address@hidden Testing with multiple processes
address@hidden Testing with multiple processes
 
 When testing GNUnet, the splitting of the code into a services and clients
 often complicates testing. The solution to this is to have the testcase fork
@@ -1720,7 +1592,8 @@ with a @code{TERM} signal (to give it the chance to 
cleanly stop its child
 processes).
 
 The following code illustrates spawning and killing an ARM process from a
-testcase: @example
+testcase:
address@hidden
 static void run (void *cls, char *const *args, const char
 *cfgfile, const struct GNUNET_CONFIGURATION_Handle *cfg) @{ struct
 GNUNET_OS_Process *arm_pid; arm_pid = GNUNET_OS_start_process (NULL, NULL,
@@ -1737,20 +1610,10 @@ GNUNET_PROGRAM_run (argc, argv, "NAME-OF-TEST", 
"nohelp", options, &run, cls);
 An alternative way that works well to test plugins is to implement a
 mock-version of the environment that the plugin expects and then to simply load
 the plugin directly.
address@hidden
address@hidden
-
-
address@hidden
-
address@hidden itemize
address@hidden Performance regression analysis with Gauger
address@hidden %**end of header
-
-
address@hidden Top
-
 
address@hidden 
***************************************************************************
address@hidden Performance regression analysis with Gauger
address@hidden Performance regression analysis with Gauger
 
 To help avoid performance regressions, GNUnet uses Gauger. Gauger is a simple
 logging tool that allows remote hosts to send performance data to a central
@@ -1781,16 +1644,20 @@ on demand. To delete a metric, you need to contact a 
member of the GNUnet
 development team (a file will need to be removed manually from the respective
 directory).
 
-The code in the test should look like this: @example[other includes] #include
-<gauger.h>
+The code in the test should look like this:
address@hidden
+[other includes]
+#include <gauger.h>
 
 int main (int argc, char *argv[]) @{
 
   [run test, generate data] GAUGER("YOUR_MODULE", "METRIC_NAME", (float)value,
-  "UNIT"); @} @end example
+  "UNIT"); @}
address@hidden example
 
 
- Where: @table @asis
+Where:
address@hidden @asis
 
 @item @strong{YOUR_MODULE} is a category in the gauger page and should be the
 name of the module or subsystem like "Core" or "DHT"
@@ -1800,25 +1667,15 @@ like "PUT operations in sqlite-datastore".
 @item @strong{value} is the value
 of the metric that is logged for this run.
 @item @strong{UNIT} is the unit in
-which the value is measured, for instance "kb/s" or "kb of RAM/node".  @end
-table
-
+which the value is measured, for instance "kb/s" or "kb of RAM/node".
address@hidden table
 
 If you wish to use Gauger for your own project, you can grab a copy of the
 latest stable release or check out Gauger's Subversion repository.
address@hidden
address@hidden
-
-
address@hidden
-
address@hidden itemize
address@hidden GNUnet's TESTBED Subsystem
address@hidden %**end of header
-
address@hidden Top
-
 
address@hidden 
***************************************************************************
address@hidden GNUnet's TESTBED Subsystem
address@hidden GNUnet's TESTBED Subsystem
 
 The TESTBED subsystem facilitates testing and measuring of multi-peer
 deployments on a single host or over multiple hosts.
@@ -1908,19 +1765,10 @@ use this path to start helper binaries both locally and 
remotely.
 
 Testbed API can accessed by including "gnunet_testbed_service.h" file and
 linking with -lgnunettestbed.
address@hidden
address@hidden
-
-
address@hidden
-
address@hidden itemize
address@hidden Supported Topologies
address@hidden %**end of header
-
address@hidden Top
-
 
address@hidden 
***************************************************************************
address@hidden Supported Topologies
address@hidden Supported Topologies
 
 While testing multi-peer deployments, it is often needed that the peers are
 connected in some topology. This requirement is addressed by the function
@@ -1973,28 +1821,19 @@ format for the format of this file.
 The above supported topologies can be specified respectively by setting the
 variable @code{OVERLAY_TOPOLOGY} to the following values in the configuration
 passed to Testbed API functions @code{GNUNET_TESTBED_test_run()} and
address@hidden()}: @itemize @bullet
-
-
address@hidden()}:
address@hidden @bullet
 @item @code{CLIQUE}
-
 @item @code{RING}
-
 @item @code{LINE}
-
 @item @code{2D_TORUS}
-
 @item @code{RANDOM}
-
 @item @code{SMALL_WORLD}
-
 @item @code{SMALL_WORLD_RING}
-
 @item @code{SCALE_FREE}
-
 @item @code{FROM_FILE}
-
address@hidden @code{NONE} @end itemize
address@hidden @code{NONE}
address@hidden itemize
 
 
 Topologies @code{RANDOM}, @code{SMALL_WORLD} and @code{SMALL_WORLD_RING}
@@ -2011,19 +1850,10 @@ Similarly, the topology @code{FROM_FILE} requires the 
option
 @code{OVERLAY_TOPOLOGY_FILE} to contain the path of the file containing the
 topology information. This option is ignored for the rest of the topologies.
 See Topology file format for the format of this file.
address@hidden
address@hidden
-
-
address@hidden
-
address@hidden itemize
address@hidden Hosts file format
address@hidden %**end of header
-
address@hidden Top
-
 
address@hidden 
***************************************************************************
address@hidden Hosts file format
address@hidden Hosts file format
 
 The testbed API offers the function GNUNET_TESTBED_hosts_load_from_file() to
 load from a given file details about the hosts which testbed can use for
@@ -2037,38 +1867,21 @@ hosts data structures and start controllers to deploy 
peers.
 These functions require the hosts file to be of the following format:
 @itemize
 @bullet
-
-
 @item Each line is interpreted to have details about a host
-
 @item Host details should include the username to use for logging into the
 host, the hostname of the host and the port number to use for the remote shell
-program
-
-. All three values should be given.
-
+program. All thee values should be given.
 @item These details should be given in the following format:
-
 @code{<username>@@<hostname>:<port>}
 @end itemize
 
-
 Note that having canonical hostnames may cause problems while resolving the IP
 addresses (See this bug). Hence it is advised to provide the hosts' IP
 numerical addresses as hostnames whenever possible.
address@hidden
address@hidden
-
-
address@hidden
-
address@hidden itemize
address@hidden Topology file format
address@hidden %**end of header
-
address@hidden Top
-
 
address@hidden 
***************************************************************************
address@hidden Topology file format
address@hidden Topology file format
 
 A topology file describes how peers are to be connected. It should adhere to
 the following format for testbed to parse it correctly.
@@ -2080,19 +1893,10 @@ the target peer.
 
 For example, the following file will result in 5 overlay connections: [2->1],
 [3->1],[4->3], [0->3], [2->0]@ @code{@ 1:2|3@ 3:4| 0@ 0: 2@ }
address@hidden
address@hidden
-
-
address@hidden
-
address@hidden itemize
address@hidden Testbed Barriers
address@hidden %**end of header
-
address@hidden Top
-
 
address@hidden 
***************************************************************************
address@hidden Testbed Barriers
address@hidden Testbed Barriers
 
 The testbed subsystem's barriers API facilitates coordination among the peers
 run by the testbed and the experiment driver. The concept is similar to the
@@ -2108,20 +1912,16 @@ peers waiting on it are notified.
 The barriers API provides the following functions:
 @itemize
 @bullet
-
-
 @item @address@hidden()}:} function to initialse a
 barrier in the experiment
-
 @item @address@hidden()}:} function to cancel a
 barrier which has been initialised before
-
 @item @address@hidden()}:} function to signal barrier
 service that the caller has reached a barrier and is waiting for it to be
 crossed
-
 @item @address@hidden()}:} function to stop
-waiting for a barrier to be crossed @end itemize
+waiting for a barrier to be crossed
address@hidden itemize
 
 
 Among the above functions, the first two, namely
@@ -2145,13 +1945,10 @@ controller service. Calling 
@code{GNUNET_TESTBED_barrier_wait()} on an
 uninitialised barrier results in failure.
 @code{GNUNET_TESTBED_barrier_wait_cancel()} cancels the notification registered
 by @code{GNUNET_TESTBED_barrier_wait()}.
address@hidden Implementation
address@hidden %**end of header
-
-
address@hidden Top
-
 
address@hidden 
***************************************************************************
address@hidden Implementation
address@hidden Implementation
 
 Since barriers involve coordination between experiment driver and peers, the
 barrier service in the testbed controller is split into two components. The

-- 
To stop receiving notification emails like this one, please contact
address@hidden