--- a/doc/tutorial/building-topologies.texi Mon Jun 30 11:42:38 2008 -0700
+++ b/doc/tutorial/building-topologies.texi Mon Jun 30 13:06:34 2008 -0700
@@ -246,9 +246,9 @@
code.
The client application is set up exactly as we did in the @code{first.cc}
-example script. We point the client to the server we just set up on the last
-of the ``extra'' CSMA nodes and install the client onto the point-to-point node
-that is not associated with any CSMA device.
+example script. We tell the client to send packets to the server we just
+installed on the last of the ``extra'' CSMA nodes. We install the client on
+the leftmost point-to-point node seen in the topology illustration.
@verbatim
UdpEchoClientHelper echoClient;
@@ -305,8 +305,8 @@
./waf --run scratch/second
@end verbatim
-Since we have set up the UDP echo applications to log just as we did in the
-@code{first.cc} script, you will see similar output.
+Since we have set up the UDP echo applications to log just as we did in
+@code{first.cc}, you will see similar output when you run the script.
@verbatim
~/repos/ns-3-dev > ./waf --run scratch/second
@@ -473,12 +473,12 @@
keep from getting all of those pcap traces with nothing but ARP exchanges in
them is to be more specific about which nodes and devices you want to trace.
-Let's take a look at @code{scratch/second.cc} and be more specific about which
-nodes and devices we want to trace. The file we provide uses the
-@code{EnablePcapAll} methods of the helpers to enable pcap on all devices.
-We want to use the more specific method, @code{EnablePcap}, which takes
-a node number and device number as parameters. Go ahead and replace the
-@code{EnablePcapAll} calls with the calls below.
+Let's take a look at @code{scratch/second.cc} and add that code enabling us
+to be more specific. The file we provided used the @code{EnablePcapAll}
+methods of the helpers to enable pcap on all devices. We now want to use the
+more specific method, @code{EnablePcap}, which takes a node number and device
+number as parameters. Go ahead and replace the @code{EnablePcapAll} calls
+with the calls below.
@verbatim
PointToPointHelper::EnablePcap ("second", p2pNodes.Get (0)->GetId (), 0);
@@ -490,30 +490,34 @@
so those parameters are not really interesting. In order to get the node
number, you have two choices: first, nodes are numbered in a monotonically
increasing fashion starting from zero in the order in which you created them.
-One way to get a node number to pass to the helper is to figure this number
-out ``manually.'' If you take a look at the network topology illustration at
-the beginning of the file, you can see that the last CSMA node is going to be
-node number code{nCsma + 1}. This can become annoyingly difficult in larger
+One way to get a node number is to figure this number out ``manually'' by
+contemplating the order of node creation. If you take a look at the network
+topology illustration at the beginning of the file, we did this for you and
+you can see that the last CSMA node is going to be node number
+@code{nCsma + 1}. This approach can become annoyingly difficult in larger
simulations.
An alternate way, which we use here, is to realize that the
@code{NodeContainers} contain pointers to @command{ns-3} @code{Node} Objects.
The @code{Node} Object has a method called @code{GetId} which will return that
-node's ID. Let's go take a look at the Doxygen for the @code{Node} and locate
-that method, which is further down in the code than we've seen so far.
+node's ID, which is the node number we seek. Let's go take a look at the
+Doxygen for the @code{Node} and locate that method, which is further down in
+the @command{ns-3} core code than we've seen so far; but sometimes you have to
+search diligently for useful things.
Go to the Doxygen documentation for your release (recall that you can find it
on the project web site). You can get to the @code{Node} documentation by
-looking through at the ``Classes'' tab in and scrolling down to
-@code{ns3::Node} in the list. Select @code{ns3::Node} and you will be taken
+looking through at the ``Classes'' tab and scrolling down the ``Class List''
+until you find @code{ns3::Node}. Select @code{ns3::Node} and you will be taken
to the documentation for the @code{Node} class. If you now scroll down to the
@code{GetId} method and select it, you will be taken to the detailed
documentation for the method. Using the @code{GetId} method can make
determining node numbers much easier in complex topologies.
Now that we have got some trace filtering in place, it is reasonable to start
-increasing the number of CSMA devices in our simulation. If you run the
-simulation setting @code{nCsma} to 100, you will see the following:
+increasing the number of CSMA devices in our simulation. If you build the
+new script and run the simulation setting @code{nCsma} to 100, you will see
+the following output:
@verbatim
~/repos/ns-3-dev > ./waf --run "scratch/second --nCsma=100"
@@ -526,8 +530,8 @@
@end verbatim
Note that the echo server is now located at 10.1.2.101 which corresponds to
-100 ``extra'' CSMA nodes with the echo server on the last one. If you list
-the pcap files in the top level directory,
+having 100 ``extra'' CSMA nodes with the echo server on the last one. If you
+list the pcap files in the top level directory,
@verbatim
~/repos/ns-3-dev > ls *.pcap
@@ -569,8 +573,8 @@
Just as in the @code{second.cc} example (and in all @command{ns-3} examples)
the file begins with an emacs mode line and some GPL boilerplate.
-Lets take a look at the ASCII art that shows the default network topology
-constructed in the example. In this case, you can see that we are going to
+Take a look at the ASCII art (reproduced below) that shows the default network
+topology constructed in the example. You can see that we are going to
further extend our example by hanging a wireless network off of the left side.
Notice that this is a default network topology since you can actually vary the
number of nodes created on the wired and wireless networks. Just as in the
@@ -762,8 +766,8 @@
tutorial into a manual on @code{Wifi}, but this model describes how the
electromagnetic signals are going to propagate. We are going to create the
simplest model, the @code{ConstantSpeedPropagationDelayModel} that, by default,
-has the signals propagating at a constant speed --- that of the speed of light
-in a vacuum.
+has the signals propagating at a constant speed --- approximately that of the
+speed of light in air.
Recall that we created the @code{WifiChannel} and assigned it to a smart
pointer. One of the features of a smart pointer is that you can use it
@@ -771,7 +775,9 @@
create a @code{ConstantSpeedPropagationDelayModel} using the
@code{CreateObject} template function and pass the resulting smart pointer
to the chanel model as an unnamed parameter of the
-@code{WifiChannel SetPropagationDelayModel} method.
+@code{WifiChannel SetPropagationDelayModel} method. In English, we create
+a model for propagation speed of electromagnetic signals and tell the
+wireless channel to use it.
@verbatim
channel->SetPropagationDelayModel (
@@ -790,12 +796,13 @@
channel->SetPropagationLossModel (log);
@end verbatim
-This snippet tells the channel how it should calculate signal attenuation
-of a signal. The details of these calcuations are beyond the scope of a
-tutorial. You are encouraged to explore the Doxygen documentation of classes
-@code{LogDistancePropagationLossModel} and
-@code{FriisPropagationLossModel} if you are interested in the details. You
-will find the documentation in the ``Classes'' tab of the Doxygen page.
+This snippet is used to tell the channel how it should calculate signal
+attenuation of waves flowing in the channel. The details of these calcuations
+are beyond the scope of a tutorial. You are encouraged to explore the Doxygen
+documentation of classes @code{LogDistancePropagationLossModel} and
+@code{FriisPropagationLossModel} if you are interested in the details. As
+usual, you will find the documentation in the ``Classes'' tab of the Doxygen
+documentation.
Now we will return to more familiar ground. We next create a @code{WifiHelper}
object and set two default atributes that it will use when creating the actual
@@ -808,9 +815,9 @@
@end verbatim
The @code{SetPhy} method tells the helper the type of physical layer class
-we want to instantiate when building @code{Wifi} devices. In this case, it
-is asking for physical layer models based on the YANS 802.11a model. Again,
-details are avialable in Doxygen.
+we want it to instantiate when building @code{Wifi} devices. In this case,
+the script is asking for physical layer models based on the YANS 802.11a
+model. Again, details are avialable in Doxygen.
The @code{SetRemoteStationManager} method tells the helper the type of
rate control algorithm to use. Here, it is asking the helper to use the AARF
@@ -836,8 +843,9 @@
Again, for the next lines of code we are back on familiar ground. This code
will @code{Install} Wifi net devices on the nodes we have created as STA nodes
-and will tie them to the @code{WifiChannel} we created manually by passing
-in the @code{channel} to the @code{Install} method.
+and will tie them to the @code{WifiChannel}. Since we created the
+@code{channel} manually rather than having the helper do it for us, we have to
+pass it into the helper when we call the @code{Install} method.
@verbatim
NetDeviceContainer staDevices;
@@ -846,7 +854,8 @@
We have configured Wifi for all of our STA nodes, and now we need to
configure the AP (access point) node. We begin this process by changing
-the default @code{Attributes} to reflect the requirements of the AP.
+the default @code{Attributes} of the @code{WifiHelper} to reflect the
+requirements of the AP.
@verbatim
wifi.SetMac ("ns3::NqapWifiMac",
@@ -869,7 +878,7 @@
@end verbatim
Now, we are going to add mobility models. We want the STA nodes to be mobile,
-wandering around inside a bounding box and we want to make the AP node
+wandering around inside a bounding box, and we want to make the AP node
stationary. We use the @code{MobilityHelper} to make this easy for us.
First, we instantiate a @code{MobilityHelper} obejct and set some attributes
controlling the ``position allocator'' functionality.
@@ -907,7 +916,7 @@
mobility.Install (wifiStaNodes);
@end verbatim
-We wanted the access point to remain in a fixed position during the simulation.
+We want the access point to remain in a fixed position during the simulation.
We accomplish this by setting the mobility model for this node to be the
@code{ns3::StaticMobilityModel}:
@@ -1145,8 +1154,8 @@
}
@end verbatim
-This code just unconditionally pulls the position information from the
-mobility model and logs the x and y position of the node. We are
+This code just pulls the position information from the mobility model and
+unconditionally logs the x and y position of the node. We are
going to arrange for this function to be called every time the wireless
node with the echo client changes its position. We do this using the
@code{Config::Connect} function. Add the following lines of code to the
@@ -1162,24 +1171,27 @@
@end verbatim
What we do here is to create a string containing the tracing namespace path
-to the event we want to connect. We have to figure out which node it is we
-want to connect to. In the case of the default number of CSMA and wireless
-nodes, this turns out to be node seven and the tracing namespace path to the
-mobility model is,
+of the event to which we want to connect. First, we have to figure out which
+node it is we want using the @code{GetId} method as described earlier. In the
+case of the default number of CSMA and wireless nodes, this turns out to be
+node seven and the tracing namespace path to the mobility model would look
+like,
@verbatim
/NodeList/7/$ns3::MobilityModel/CourseChange
@end verbatim
-Based on the discussion in the tracing section, you may easily infer that
-this string references the seventh node in the NodeList and looks for what is
-called an aggregated object of type @code{ns3::MobilityModel}. The dollar
-sign prefix implies that the MobilityModel is aggregated to node seven. The
-last component of the path means that we are hooking into the ``CourseChange''
-event of that model. We have made a connection between the trace source in
-node seven with our trace sink by calling @code{Config::Connect}. Once this
-is done, every course change event on node seven will be hooked into our trace
-sink, which will in turn print out the new position.
+Based on the discussion in the tracing section, you can easily infer that
+this trace path references the seventh node in the NodeList. It specifies
+what is called an aggregated object of type @code{ns3::MobilityModel}. The
+dollar sign prefix implies that the MobilityModel is aggregated to node seven.
+The last component of the path means that we are hooking into the
+``CourseChange'' event of that model.
+
+We make a connection between the trace source in node seven with our trace
+sink by calling @code{Config::Connect} and passing this namespace path. Once
+this is done, every course change event on node seven will be hooked into our
+trace sink, which will in turn print out the new position.
If you now run the simulation, you will see the course changes displayed as
they happen.
@@ -1225,8 +1237,7 @@
If you are feeling brave, there is a list of all trace sources in the
@command{ns-3} Doxygen which you can find in the ``NS-3 Modules'' section.
Under the ``core'' section, you will find a link to ``The list of all trace
-sources.'' In that link you will find a list of all of the trace sources that
- you can hook to. You may find it interesting to try and hook some of these
+sources.'' You may find it interesting to try and hook some of these
traces yourself. Additionally in the ``NS-3 Modules'' documentation, there is
a link to ``The list of all attributes.'' You can set the default value of
any of these atributes via the command line as we have previously discussed.
--- a/doc/tutorial/conceptual-overview.texi Mon Jun 30 11:42:38 2008 -0700
+++ b/doc/tutorial/conceptual-overview.texi Mon Jun 30 13:06:34 2008 -0700
@@ -687,7 +687,7 @@
simulation by sending a packet to the server.
The act of sending the packet to the server will trigger a chain of events
-that will be automatically scheduled behind the scene and which will perform
+that will be automatically scheduled behind the scenes and which will perform
the mechanics of the packet echo according to the various timing parameters
that we have set in the script.
--- a/doc/tutorial/tweaking.texi Mon Jun 30 11:42:38 2008 -0700
+++ b/doc/tutorial/tweaking.texi Mon Jun 30 13:06:34 2008 -0700
@@ -43,10 +43,10 @@
@command{Ns-3} takes the view that all of these verbosity levels are useful
and we provide a selectable, multi-level approach to message logging. Logging
-can be disabled completely, enabled on a component-by-component basis, enabled
-globally and has selectable verbosity levels. The @command{ns-3} log module
-provides a straightforward, relatively easy to use way to get some kinds of
-information out of your simulation.
+can be disabled completely, enabled on a component-by-component basis, or
+enabled globally; and it provides selectable verbosity levels. The
+@command{ns-3} log module provides a straightforward, relatively easy to use
+way to get useful information out of your simulation.
You should understand that we do provide a general purpose mechanism ---
tracing --- to get data out of your models which should be preferred for
@@ -78,19 +78,18 @@
Each level can be requested singly or cumulatively; and logging can be set
up using a shell environment variable (NS_LOG) or by logging system function
call. As was seen earlier in the tutorial, the logging system has Doxygen
-documentation so now would be a good time to peruse the Logging Module
-documentation.
+documentation and now would be a good time to peruse the Logging Module
+documentation if you have not done so.
-Now that you have read the documentation in great detail, we can get some
-interesting information out of the @code{first.cc} example script you dropped
-in the scratch directory after the script walkthrough.
+Now that you have read the documentation in great detail, let's use some of
+that knowledge to get some interesting information out of the @code{first.cc}
+example script you have already built.
@node Enabling Logging
@subsection Enabling Logging Using the NS_LOG Environment Variable
@cindex NS_LOG
-First, let's use the NS_LOG environment variable to turn on some more logging
-in the @code{first.cc} script you have already built. Go ahead and run the
-script just as you did previously,
+Let's use the NS_LOG environment variable to turn on some more logging, but
+to get our bearings, go ahead and run the script just as you did previously,
@verbatim
~/repos/ns-3-dev > ./waf --run scratch/first
@@ -102,16 +101,19 @@
~/repos/ns-3-dev >
@end verbatim
-The ``Sent'' and ``Received'' messages are actually logging messages from the
-@code{UdpEchoClientApplication} and @code{UdpEchoServerApplication}. We can
-ask the client application, for example, to print more information by setting
-its logging level via the NS_LOG environment variable. I am going to assume
-from here on that are using an sh-like shell that uses the``VARIABLE=value''
-syntax. If you are using a csh-like shell, then you will have to convert to
-the ``setenv VARIABLE value'' syntax required by those shells.
+It turns out that the ``Sent'' and ``Received'' messages are actually logging
+messages from the @code{UdpEchoClientApplication} and
+@code{UdpEchoServerApplication}. We can ask the client application, for
+example, to print more information by setting its logging level via the
+NS_LOG environment variable.
-Let's ask the UDP echo client application to print a little more information.
-Right now, it is responding to the following line of code in @code{first.cc},
+I am going to assume from here on that are using an sh-like shell that uses
+the``VARIABLE=value'' syntax. If you are using a csh-like shell, then you
+will have to convert my examples to the ``setenv VARIABLE value'' syntax
+required by those shells.
+
+Right now, the UDP echo client application is responding to the following line
+of code in @code{first.cc},
@verbatim
LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);
@@ -128,7 +130,7 @@
~/repos/ns-3-dev > export NS_LOG=UdpEchoClientApplication=level_all
@end verbatim
-This sets the environment variable @code{NS_LOG} to the string,
+This sets the shell environment variable @code{NS_LOG} to the string,
@verbatim
UdpEchoClientApplication=level_all
@@ -137,8 +139,8 @@
The left hand side of the assignment is the name of the logging component we
want to set, and the right hand side is the flag we want to use. In this case,
we are going to turn on all of the debugging levels for the application. If
-you run the script with NS_LOG set this way you should see the following
-output:
+you run the script with NS_LOG set this way, the @command{ns-3} logging
+system will pick up the change and you should see the following output:
@verbatim
~/repos/ns-3-dev > ./waf --run scratch/first
@@ -158,11 +160,13 @@
~/repos/ns-3-dev >
@end verbatim
-The only additional debug information provided by the application is from
-the NS_LOG_FUNCTION level. Note that there are no requirements in the
-@command{ns-3} system that logging components must support any particular
-logging functionality. The decision regarding how much information is logged
-is left to the individual developer.
+The additional debug information provided by the application is from
+the NS_LOG_FUNCTION level. This shows every time a function in the application
+is called during script execution. Note that there are no requirements in the
+@command{ns-3} system that models must support any particular logging
+functionality. The decision regarding how much information is logged
+is left to the individual model developer. In the case of the echo
+applications, a good deal of log output is available.
You can now see a log of the function calls that were made to the application.
If you look closely you will notice a single colon between the string
@@ -296,9 +300,10 @@
Recall that the @code{first.cc} script started the echo server application at
one second into the simulation. You can now see that the
-@code{StartApplication} of the server is, in fact, called at one second (or
-one billion nanoseconds). You can also see that the echo client application
-is started at a simulation time of two seconds as we requested in the script.
+@code{StartApplication} method of the server is, in fact, called at one second
+(or one billion nanoseconds). You can also see that the echo client
+application is started at a simulation time of two seconds as we requested in
+the script.
You can now follow the progress of the simulation from the
@code{ScheduleTransmit} call in the client that calls @code{Send} to the
@@ -306,7 +311,7 @@
elapsed time as the packet is sent across the point-to-point link is 3.6864
milliseconds. You see the echo server logging a message telling you that it
has echoed the packet and then, after a delay, you see the echo client receive
-the echoed packet.
+the echoed packet in its @code{HandleRead} method.
There is a lot that is happening under the covers in this simulation that you
are not seeing as well. You can very easily follow the entire process by
@@ -641,7 +646,7 @@
@end verbatim
Now if you run the script and provide the @code{--PrintHelp} argument, you
-should see your new @code{User Argument} listed in the help.
+should see your new @code{User Argument} listed in the help display.
@verbatim
~/repos/ns-3-dev > ./waf --run "scratch/first --PrintHelp"
@@ -676,12 +681,12 @@
You have now echoed two packets.
-If you are an @command{ns-3} user, you can use the command line argument
-system to control global values and attributes. If you are a model author,
-you can add new attributes to your Objects and they will automatically be
-available for setting by your users through the command line system. If you
-are a script author, you can add new variables to your scripts and hook them
-into the command line system quite painlessly.
+You can see that if you are an @command{ns-3} user, you can use the command
+line argument system to control global values and attributes. If you are a
+model author, you can add new attributes to your Objects and they will
+automatically be available for setting by your users through the command line
+system. If you are a script author, you can add new variables to your scripts
+and hook them into the command line system quite painlessly.
@c ========================================================================
@c Using the Tracing System
@@ -692,7 +697,7 @@
The whole point of simulation is to generate output for further study, and
the @command{ns-3} tracing system is a primary mechanism for this. Since
@command{ns-3} is a C++ program, standard facilities for generating output
-from C++ programs apply:
+from C++ programs could be used:
@verbatim
#include <iostream>
@@ -705,6 +710,11 @@
}
@end verbatim
+You could even use the logging module to add a little structure to your
+solution. There are many well-known problems generated by such approaches
+and so we have provided a generic event tracing subsystem to address the
+issues we thought were important.
+
The basic goals of the @command{ns-3} tracing system are:
@itemize @bullet
@@ -736,7 +746,7 @@
types of sinks to existing tracing sources, without requiring editing and
recompilation of the the core of the simulator. Thus, in the example above,
a user could define a new tracing sink in her script and attach it to an
-existing tracing source defined in the simulation core editing only the
+existing tracing source defined in the simulation core by editing only the
user script.
In this tutorial, we will walk through some pre-defined sources and sinks and
@@ -747,12 +757,12 @@
@cindex tracing
@cindex ASCII tracing
@subsection ASCII Tracing
-@command{Ns-3} provides functionality wrapping the low-level tracing system
-to help you with the details involved in configuring some easily
-understood packe traces. If you enable this functionality, you will see
-output of a trace of a simulation appear in an ASCII file --- thus the name.
-For those familiar with @command{ns-2} output, this type of trace is
-analogous to the @command{out.tr} generated by many scripts.
+@command{Ns-3} provides helper functionality that wraps the low-level tracing
+system to help you with the details involved in configuring some easily
+understood packet traces. If you enable this functionality, you will see
+output in a ASCII files --- thus the name. For those familiar with
+@command{ns-2} output, this type of trace is analogous to the @command{out.tr}
+generated by many scripts.
@cindex tracing packets
Let's just jump right in and add some ASCII tracing output to our
@@ -790,8 +800,8 @@
@cindex first.tr
Just as you have seen previously, you may see some messages from Waf and then
-the ``Compilation finished successfully'' message. The following messages are
-from the running program.
+the ``Compilation finished successfully'' with some number of messages from
+the running program.
When it ran, the program will have created a file named @code{first.tr}.
Because of the way that Waf works, the file is not created in the local
@@ -799,7 +809,7 @@
default. If you want to control where the traces are saved you can use the
@code{--cwd} option of Waf to specify this. We have not done so, thus we
need to change into the top level directory of our repo and take a look at
-the file @code{first.tr} in your favorite editor.
+the ASCII trace file @code{first.tr} in your favorite editor.
@subsubsection Parsing Ascii Traces
@cindex parsing ascii traces
@@ -808,11 +818,11 @@
be difficult to see this clearly unless you widen your window considerably.
Each line in the file corresponds to a @emph{trace event}. In this case
-we are tracing events on the @emph{transmit queue} present in every net device
-on every node in the simulation. The transmit queue is a queue through which
-every packet destined for a channel must pass. Note that each line in the
-trace file begins with a lone character (has a space after it). This
-character will have the following meaning:
+we are tracing events on the @emph{transmit queue} present in every
+point-to-point net device in the simulation. The transmit queue is a queue
+through which every packet destined for a point-to-point channel must pass.
+Note that each line in the trace file begins with a lone character (has a
+space after it). This character will have the following meaning:
@cindex ascii trace enqueue operation
@cindex ascii trace dequeue operation
@@ -855,8 +865,8 @@
@cindex node number
@cindex net device number
@cindex smart pointer
-The next line of the example trace (reference 02) tell us the trace source
-that originated this even expressed in the tracing namespace. You can think
+The next line of the example trace (reference 02) tell us which trace source
+originated this event (expressed in the tracing namespace). You can think
of the tracing namespace somewhat like you would a filesystem namespace. The
root of the namespace is the @code{NodeList}. This corresponds to a container
managed in the @command{ns-3} core code that contains all of the nodes that are
@@ -869,8 +879,8 @@
zeroth device installed in the node.
The next string, @code{$ns3::PointToPointNetDevice} tells you what kind of
-device it is that is in the zeroth position of the device list for node zero.
-Recall that the operation @code{+} found at reference 00 means an enqueue
+device is in the zeroth position of the device list for node zero.
+Recall that the operation @code{+} found at reference 00 meant that an enqueue
operation happened on the transmit queue of the device. This is reflected in
the final segments of the ``trace path'' which are @code{TxQueue/Enqueue}.
@@ -916,7 +926,7 @@
@subsection PCAP Tracing
@cindex pcap
@cindex Wireshark
-The @command{ns-3} device helpers can be used to create trace files in the
+The @command{ns-3} device helpers can also be used to create trace files in the
@code{.pcap} format. The acronym pcap (usually written in lower case) stands
for @emph{p}acket @emph{cap}ture, and is actually an API that includes the
definition of a @code{.pcap} file format. The most popular program that can
@@ -940,11 +950,12 @@
file names will be built using the prefix, the node number, the device number
and a ``.pcap'' suffix.
-In our example script, we will see a files named ``first-0-0.pcap'' and
-``first.1-0.pcap'' which are the pcap traces for node 0-device 0 and
+In our example script, we will eventually see files named ``first-0-0.pcap''
+and ``first.1-0.pcap'' which are the pcap traces for node 0-device 0 and
node 1-device 1, respectively.
-You can now run the script in the usual way:
+Once you have added the line of code to enable pcap tracing, you can run the
+script in the usual way:
@verbatim
./waf --run scratch/first