Second batch of corrections for incorrect paths.

native_client_sdk/src/doc/devguide/coding/progress-events.rst

 .. _devcycle-progress-events:
 
 :template: standard_nacl_api
 
 ###############
 Progress Events
 ###############
 
 .. contents::
   :local:
   :backlinks: none
   :depth: 2
 
 There are five types of events that developers can respond to in Native Client:
 progress, message, view change, focus, and input events (each described in the
 glossary below). This chapter describes how to monitor progress events (events
 that occur during the loading and execution of a Native Client module). This
 chapter assumes you are familiar with the material presented in the
 :doc:`Technical Overview <../../overview>`.
 
 .. Note::
   :class: note
 
   The load_progress example illustrates progress event handling. You can find
-  this code in the ``/examples/tutorial/load_progress/`` directory in the Native
-  Client SDK download.
+  this code in the ``/pepper_<version>/examples/tutorial/load_progress/`` 
+  directory in the Native Client SDK download.
 
 Module loading and progress events
 ==================================
 
 The Native Client runtime reports a set of state changes during the module
 loading process by means of DOM progress events. This set of events is a direct
 port of the proposed W3C `Progress Events
 <http://www.w3.org/TR/progress-events/>`_ standard (except for the ``crash``
 event which is an extension of the W3C standard). The following table lists the
 events types reported by the Native Client runtime:
@@ skipping 277 matching lines @@
 crash, the ``crash`` progress event is issued and the ``exitStatus`` attribute
 will contain the numeric value of the exit status:
 
 * In the case of explicit calls to ``exit(n)``, the numeric value will be
   ``n`` (between 0 and 255).
 * In the case of crashes and calls to ``abort()``, the numeric value will
   be non-zero, but the exact value will depend on the chosen libc and the
   target architecture, and may change in the future. Applications should not
   rely on the ``exitStatus`` value being stable in these cases, but the value
   may nevertheless be useful for temporary debugging.