--- a/doc/manual/source/enable-modules.rst Tue May 24 23:44:09 2011 -0700
+++ b/doc/manual/source/enable-modules.rst Wed May 25 08:57:47 2011 +0400
@@ -12,7 +12,7 @@
If shared libraries are being built, then enabling a module will cause at least one library to be built: ::
- libns3-modulename.so.
+ libns3-modulename.so
If the module has a test library and test libraries are being built, then ::
--- a/doc/manual/source/new-models.rst Tue May 24 23:44:09 2011 -0700
+++ b/doc/manual/source/new-models.rst Wed May 25 08:57:47 2011 +0400
@@ -189,7 +189,7 @@
``src/network/wscript``. It is really just a matter of adding the .cc file to the
rest of the source files, and the .h file to the list of the header files.
-Now, pop up to the top level directory and type "./waf --check". You
+Now, pop up to the top level directory and type "./test.py". You
shouldn't have broken anything by this operation.
include guards
--- a/doc/manual/source/new-modules.rst Tue May 24 23:44:09 2011 -0700
+++ b/doc/manual/source/new-modules.rst Wed May 25 08:57:47 2011 +0400
@@ -216,14 +216,14 @@
If your new module has examples, then you must specify which of them
should be run in your ::
- src/new-module/tests/examples-to-run.py
+ src/new-module/test/examples-to-run.py
file by modifying it with your text editor. These examples are run by
test.py.
As an example, the examples that are run by test.py for the core module are specified in ::
- src/core/tests/examples-to-run
+ src/core/test/examples-to-run.py
using the following two lists of C++ and Python examples: ::
--- a/doc/models/source/organization.rst Tue May 24 23:44:09 2011 -0700
+++ b/doc/models/source/organization.rst Wed May 25 08:57:47 2011 +0400
@@ -15,7 +15,7 @@
protocols, devices, etc.
An |ns3| module may consist of more than one model (for instance, the
-:mod:`internet` model contains models for both TCP and UDP). In general,
+:mod:`internet` module contains models for both TCP and UDP). In general,
ns-3 models do not span multiple software modules, however.
This manual provides documentation about the models of |ns3|. It
@@ -31,14 +31,14 @@
`main web site <http://www.nsnam.org>`_ to find copies of the manual.
Finally, additional documentation about various aspects of |ns3| may
-exist on the `project wiki <http://www.nsnam.org/wiki>`_).
+exist on the `project wiki <http://www.nsnam.org/wiki>`_.
A sample outline of how to write model library documentation can be
found in :mod:`src/template/doc`.
The remainder of this document is organized alphabetically by module name.
-If you are new to ns3, you might first want to read below about the network
+If you are new to |ns3|, you might first want to read below about the network
module, which contains some fundamental models for the simulator.
The packet model, models for different address formats, and abstract
base classes for objects such as nodes, net devices, channels, sockets, and
--- a/doc/tutorial/source/building-topologies.rst Tue May 24 23:44:09 2011 -0700
+++ b/doc/tutorial/source/building-topologies.rst Wed May 25 08:57:47 2011 +0400
@@ -100,7 +100,7 @@
cmd.AddValue ("nCsma", "Number of \"extra\" CSMA nodes/devices", nCsma);
cmd.AddValue ("verbose", "Tell echo applications to log if true", verbose);
- cmd.Parse (argc,argv);
+ cmd.Parse (argc, argv);
if (verbose)
{
--- a/doc/tutorial/source/conceptual-overview.rst Tue May 24 23:44:09 2011 -0700
+++ b/doc/tutorial/source/conceptual-overview.rst Wed May 25 08:57:47 2011 +0400
@@ -155,10 +155,12 @@
::
- AUTHORS doc/ README utils/ wscript
- bindings/ examples/ RELEASE_NOTES VERSION wutils.py
- build/ LICENSE scratch/ waf* wutils.pyc
- CHANGES.html ns3/ src waf.bat*
+ AUTHORS examples scratch utils waf.bat*
+ bindings LICENSE src utils.py waf-tools
+ build ns3 test.py* utils.pyc wscript
+ CHANGES.html README testpy-output VERSION wutils.py
+ doc RELEASE_NOTES testpy.supp waf* wutils.pyc
+
Change into the ``examples/tutorial`` directory. You should see a file named
``first.cc`` located there. This is a script that will create a simple
@@ -735,7 +737,7 @@
::
- cd ..
+ cd ../..
cp examples/tutorial/first.cc scratch/myfirst.cc
Now build your first example script using waf:
@@ -823,7 +825,7 @@
-rw-r--r-- 2009-07-01 12:47 +0200 7673 wutils.py file | revisions | annotate
Our example scripts are in the ``examples`` directory. If you click on ``examples``
-you will see a list of files. One of the files in that directory is ``first.cc``. If
+you will see a list of subdirectories. One of the files in ``tutorial`` subdirectory is ``first.cc``. If
you click on ``first.cc`` you will find the code you just walked through.
The source code is mainly in the ``src`` directory. You can view source
--- a/doc/tutorial/source/getting-started.rst Tue May 24 23:44:09 2011 -0700
+++ b/doc/tutorial/source/getting-started.rst Wed May 25 08:57:47 2011 +0400
@@ -91,8 +91,8 @@
the |ns3| development team. The repositories of interest to you will
be prefixed with "ns-3". Official releases of |ns3| will be
numbered as ``ns-3.<release>.<hotfix>``. For example, a second hotfix to a
-still hypothetical release nine of |ns3| would be numbered as
-``ns-3.9.2``.
+still hypothetical release forty two of |ns3| would be numbered as
+``ns-3.42.2``.
The current development snapshot (unreleased) of |ns3| may be found
at http://code.nsnam.org/ns-3-dev/. The
@@ -207,10 +207,9 @@
::
- AUTHORS examples/ RELEASE_NOTES VERSION wutils.py
- bindings/ LICENSE scratch/ waf*
- CHANGES.html ns3/ src/ waf.bat*
- doc/ README utils/ wscript
+ AUTHORS doc ns3 scratch testpy.supp VERSION waf-tools
+ bindings examples README src utils waf* wscript
+ CHANGES.html LICENSE RELEASE_NOTES test.py* utils.py waf.bat* wutils.py
You are now ready to build the |ns3| distribution.
@@ -281,19 +280,19 @@
'build' finished successfully (2m30.586s)
Modules built:
- aodv applications bridge
- click config-store core
- csma csma-layout dsdv
- emu energy flow-monitor
- internet lte mesh
- mobility mpi netanim
- network nix-vector-routing ns3tcp
- ns3wifi olsr openflow
- point-to-point point-to-point-layout propagation
- spectrum stats tap-bridge
- test tools topology-read
- uan virtual-net-device visualizer
- wifi wimax
+ aodv applications bridge
+ click config-store core
+ csma csma-layout dsdv
+ emu energy flow-monitor
+ internet lte mesh
+ mobility mpi netanim
+ network nix-vector-routing ns3tcp
+ ns3wifi olsr openflow
+ point-to-point point-to-point-layout propagation
+ spectrum stats tap-bridge
+ template test tools
+ topology-read uan virtual-net-device
+ visualizer wifi wimax
Once the project has built you can say goodbye to your old friends, the
``ns-3-allinone`` scripts. You got what you needed from them and will now
@@ -459,19 +458,19 @@
'build' finished successfully (1.799s)
Modules built:
- aodv applications bridge
- click config-store core
- csma csma-layout dsdv
- emu energy flow-monitor
- internet lte mesh
- mobility mpi netanim
- network nix-vector-routing ns3tcp
- ns3wifi olsr openflow
- point-to-point point-to-point-layout propagation
- spectrum stats tap-bridge
- test tools topology-read
- uan virtual-net-device visualizer
- wifi wimax
+ aodv applications bridge
+ click config-store core
+ csma csma-layout dsdv
+ emu energy flow-monitor
+ internet lte mesh
+ mobility mpi netanim
+ network nix-vector-routing ns3tcp
+ ns3wifi olsr openflow
+ point-to-point point-to-point-layout propagation
+ spectrum stats tap-bridge
+ template test tools
+ topology-read uan virtual-net-device
+ visualizer wifi wimax
PASS: TestSuite ns3-wifi-interference
PASS: TestSuite histogram
@@ -489,7 +488,7 @@
PASS: TestSuite basic-random-number
PASS: TestSuite object
PASS: TestSuite random-number-generators
- 47 of 47 tests passed (47 passed, 0 failed, 0 crashed, 0 valgrind errors)
+ 95 of 95 tests passed (95 passed, 0 failed, 0 crashed, 0 valgrind errors)
This command is typically run by ``users`` to quickly verify that an
|ns3| distribution has built correctly.
--- a/src/click/doc/click.rst Tue May 24 23:44:09 2011 -0700
+++ b/src/click/doc/click.rst Wed May 25 08:57:47 2011 +0400
@@ -42,7 +42,7 @@
Much of the API is already well defined, which allows Click to probe for information from the simulator (like a Node's ID, an Interface ID and so forth). By retaining most of the methods, it should be possible to write new implementations specific to ns-3 for the same functionality.
-Hence, for the Click integration with ns-3, a class named Ipv4ClickRouting will handle the interaction with Click. The code for the same can be found in ``src/click/model/ipv4-click-routing.[cc,h]``.
+Hence, for the Click integration with ns-3, a class named Ipv4ClickRouting will handle the interaction with Click. The code for the same can be found in ``src/click/model/ipv4-click-routing.{cc,h}``.
Packet hand off between ns-3 and Click
######################################
@@ -132,7 +132,7 @@
click.Install (myNodeContainer);
The example scripts inside ``src/click/examples/`` demonstrate the use of Click based nodes
-in different scenarios. The helper source can be found inside ``src/click/helper/click-internet-stack-helper.[h,cc]``
+in different scenarios. The helper source can be found inside ``src/click/helper/click-internet-stack-helper.{h,cc}``
Examples
========
--- a/src/core/model/type-id.h Tue May 24 23:44:09 2011 -0700
+++ b/src/core/model/type-id.h Wed May 25 08:57:47 2011 +0400
@@ -51,7 +51,7 @@
ATTR_GET = 1<<0, /**< The attribute can be read */
ATTR_SET = 1<<1, /**< The attribute can be written */
ATTR_CONSTRUCT = 1<<2, /**< The attribute can be written at construction-time */
- ATTR_SGC = ATTR_GET | ATTR_SET | ATTR_CONSTRUCT, /** The attribute can be read, and written at any time */
+ ATTR_SGC = ATTR_GET | ATTR_SET | ATTR_CONSTRUCT, /**< The attribute can be read, and written at any time */
};
/**
--- a/src/network/model/nix-vector.h Tue May 24 23:44:09 2011 -0700
+++ b/src/network/model/nix-vector.h Wed May 25 08:57:47 2011 +0400
@@ -47,7 +47,7 @@
* bits long and can store multiple neighbor-indexes. A
* fair amount of bit manipulation is used to store these
* neighbor-indexes efficiently. A vector is used so that
- * the nix-vector can grow arbitraily if the topology and
+ * the nix-vector can grow arbitrarily if the topology and
* route requires a large number of neighbor-indexes.
*
* As the nix-vector travels along the route, an internal