We are currently solving the following issue within our repository. Here is the issue text:
--- BEGIN ISSUE ---
Update documentation and examples/measurement.py
Ran into some issues on a fresh install from the documentation. I needed to add the package libprotobuf-dev to the apt-get install line in CONTRIBUTING.md to get protobufs to build and got an error when trying to run the example measurements.py that units could not be found, resolved by importing openhtf.utils.units

--- END ISSUE ---

Below are some code segments, each from a relevant file. One or more of these files may contain bugs.
--- BEGIN FILES ---
Path: `examples/measurements.py`
Content:
```
1 # Copyright 2016 Google Inc. All Rights Reserved.
2 
3 # Licensed under the Apache License, Version 2.0 (the "License");
4 # you may not use this file except in compliance with the License.
5 # You may obtain a copy of the License at
6 
7 #     http://www.apache.org/licenses/LICENSE-2.0
8 
9 # Unless required by applicable law or agreed to in writing, software
10 # distributed under the License is distributed on an "AS IS" BASIS,
11 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
12 # See the License for the specific language governing permissions and
13 # limitations under the License.
14 
15 """Example OpenHTF test demonstrating use of measurements.
16 
17 Run with (your virtualenv must be activated first):
18 
19   python measurements.py
20 
21 Afterwards, check out the output in measurements.json.  If you open both this
22 example test and that output file and compare them, you should be able to see
23 where measurement values end up in the output and what the corresponding code
24 looks like that sets them.
25 
26 TODO(someone): Write these examples.
27 For more complex topics, see the validators.py and dimensions.py examples.
28 
29 For a simpler example, see the hello_world.py example.  If the output of this
30 test is confusing, start with the hello_world.py output and compare it to this
31 test's output.
32 
33 Some constraints on measurements:
34 
35   - Measurement names must be valid python variable names.  This is mostly for
36     sanity, but also ensures you can access them via attribute access in phases.
37     This applies *after* any with_args() substitution (not covered in this
38     tutorial, see the phases.py example for more details).
39 
40   - You cannot declare the same measurement name multiple times on the same
41     phase.  Technically, you *can* declare the same measurement on multiple
42     phases; measurements are attached to a specific phase in the output.  This
43     isn't recommended, though, because it makes it difficult to flatten a test's
44     measurements, which some output formats require.
45 """
46 
47 # Import openhtf with an abbreviated name, as we'll be using a bunch of stuff
48 # from it throughout our test scripts. See __all__ at the top of
49 # openhtf/__init__.py for details on what's in top-of-module namespace.
50 import openhtf as htf
51 
52 # Import this output mechanism as it's the specific one we want to use.
53 from openhtf.output.callbacks import json_factory
54 
55 # You won't normally need to import this, see validators.py example for
56 # more details.  It's used for the inline measurement declaration example
57 # below, but normally you'll only import it when you want to define custom
58 # measurement validators.
59 from openhtf.util import validators
60 
61 
62 # Simple example of measurement use, similar to hello_world.py usage.
63 @htf.measures(htf.Measurement('hello_world_measurement'))
64 def hello_phase(test):
65   test.measurements.hello_world_measurement = 'Hello!'
66 
67 
68 # An alternative simpler syntax that creates the Measurement for you.
69 @htf.measures('hello_again_measurement')
70 def again_phase(test):
71   test.measurements.hello_again_measurement = 'Again!'
72 
73 
74 # Multiple measurements can be specified in a single decorator, using either of
75 # the above syntaxes.  Technically, these syntaxes can be mixed and matched, but
76 # as a matter of convention you should always use one or the other within a
77 # single decorator call.  You'll also note that you can stack multiple
78 # decorations on a single phase.  This is useful if you have a handful of simple
79 # measurements, and then one or two with more complex declarations (see below).
80 @htf.measures('first_measurement', 'second_measurement')
81 @htf.measures(htf.Measurement('third'), htf.Measurement('fourth'))
82 def lots_of_measurements(test):
83   test.measurements.first_measurement = 'First!'
84   # Measurements can also be access via indexing rather than attributes.
85   test.measurements['second_measurement'] = 'Second :('
86   # This can be handy for iterating over measurements.
87   for measurement in ('third', 'fourth'):
88     test.measurements[measurement] = measurement + ' is the best!'
89 
90 
91 # Basic key/value measurements are handy, but we may also want to validate a
92 # measurement against some criteria, or specify additional information
93 # describing the measurement.  Validators can get quite complex, for more
94 # details, see the validators.py example.
95 @htf.measures(htf.Measurement('validated_measurement').in_range(0, 10).doc(
96     'This measurement is validated.').with_units(units.SECOND))
97 def measure_seconds(test):
98   # The 'outcome' of this measurement in the test_record result will be a PASS
99   # because its value passes the validator specified (0 <= 5 <= 10).
100   test.measurements.validated_measurement = 5
101 
102 
103 # These additional attributes can also be specified inline as kwargs passed
104 # directly to the @measures decorator.  If you do so, however, you must
105 # specify exactly one measurement with that decorator (ie. the first argument
106 # must be a string containing the measurement name).  If you want to specify
107 # multiple measurements this way, you can stack multiple decorators.
108 @htf.measures('inline_kwargs', docstring='This measurement is declared inline!',
109               units=units.HERTZ, validators=[validators.in_range(0, 10)])
110 @htf.measures('another_inline', docstring='Because why not?')
111 def inline_phase(test):
112   # This measurement will have an outcome of FAIL, because the set value of 15
113   # will not pass the 0 <= x <= 10 validator.
114   test.measurements.inline_kwargs = 15
115   test.measurements.another_inline = 'This one is unvalidated.'
116 
117   # Let's log a message so the operator knows the test should fail.
118   test.logger.info('Set inline_kwargs to a failing value, test should FAIL!')
119 
120 
121 if __name__ == '__main__':
122   # We instantiate our OpenHTF test with the phases we want to run as args.
123   test = htf.Test(hello_phase, again_phase, lots_of_measurements,
124                   measure_seconds, inline_phase)
125 
126   # In order to view the result of the test, we have to output it somewhere,
127   # and a local JSON file is a convenient way to do this.  Custom output
128   # mechanisms can be implemented, but for now we'll just keep it simple.
129   # This will always output to the same ./measurements.json file, formatted
130   # slightly for human readability.
131   test.add_output_callbacks(
132       json_factory.OutputToJSON('./measurements.json', indent=2))
133 
134   # Unlike hello_world.py, where we prompt for a DUT ID, here we'll just
135   # use an arbitrary one.
136   test.execute(test_start=lambda: 'MyDutId')
137
```
--- END FILES ---

Please first localize the bug based on the issue statement, and then generate a patch according to the `git diff` format fenced by three backticks.

Here is an example:

```diff
diff --git a/examples/server_async.py b/examples/server_async.py
--- a/examples/server_async.py
+++ b/examples/server_async.py
@@ -313,4 +313,4 @@
 
 
 if __name__ == "__main__":
-    asyncio.run(run_async_server("."), debug=True)
+    asyncio.run(run_async_server(), debug=True)
diff --git a/examples/server_sync.py b/examples/server_sync.py
--- a/examples/server_sync.py
+++ b/examples/server_sync.py
@@ -313,5 +313,5 @@
 
 
 if __name__ == "__main__":
-    server = run_sync_server(".")
+    server = run_sync_server()
     server.shutdown()

```

diff --git a/examples/measurements.py b/examples/measurements.py
--- a/examples/measurements.py
+++ b/examples/measurements.py
@@ -93,7 +93,7 @@
 # describing the measurement.  Validators can get quite complex, for more
 # details, see the validators.py example.
 @htf.measures(htf.Measurement('validated_measurement').in_range(0, 10).doc(
-    'This measurement is validated.').with_units(units.SECOND))
+    'This measurement is validated.').with_units(htf.units.SECOND))
 def measure_seconds(test):
   # The 'outcome' of this measurement in the test_record result will be a PASS
   # because its value passes the validator specified (0 <= 5 <= 10).
@@ -106,7 +106,7 @@
 # must be a string containing the measurement name).  If you want to specify
 # multiple measurements this way, you can stack multiple decorators.
 @htf.measures('inline_kwargs', docstring='This measurement is declared inline!',
-              units=units.HERTZ, validators=[validators.in_range(0, 10)])
+              units=htf.units.HERTZ, validators=[validators.in_range(0, 10)])
 @htf.measures('another_inline', docstring='Because why not?')
 def inline_phase(test):
   # This measurement will have an outcome of FAIL, because the set value of 15

{"golden_diff": "diff --git a/examples/measurements.py b/examples/measurements.py\n--- a/examples/measurements.py\n+++ b/examples/measurements.py\n@@ -93,7 +93,7 @@\n # describing the measurement.  Validators can get quite complex, for more\n # details, see the validators.py example.\n @htf.measures(htf.Measurement('validated_measurement').in_range(0, 10).doc(\n-    'This measurement is validated.').with_units(units.SECOND))\n+    'This measurement is validated.').with_units(htf.units.SECOND))\n def measure_seconds(test):\n   # The 'outcome' of this measurement in the test_record result will be a PASS\n   # because its value passes the validator specified (0 <= 5 <= 10).\n@@ -106,7 +106,7 @@\n # must be a string containing the measurement name).  If you want to specify\n # multiple measurements this way, you can stack multiple decorators.\n @htf.measures('inline_kwargs', docstring='This measurement is declared inline!',\n-              units=units.HERTZ, validators=[validators.in_range(0, 10)])\n+              units=htf.units.HERTZ, validators=[validators.in_range(0, 10)])\n @htf.measures('another_inline', docstring='Because why not?')\n def inline_phase(test):\n   # This measurement will have an outcome of FAIL, because the set value of 15\n", "issue": "Update documentation and examples/measurement.py\nRan into some issues on a fresh install from the documentation. I needed to add the package libprotobuf-dev to the apt-get install line in CONTRIBUTING.md to get protobufs to build and got an error when trying to run the example measurements.py that units could not be found, resolved by importing openhtf.utils.units\n", "before_files": [{"content": "# Copyright 2016 Google Inc. All Rights Reserved.\n\n# Licensed under the Apache License, Version 2.0 (the \"License\");\n# you may not use this file except in compliance with the License.\n# You may obtain a copy of the License at\n\n#     http://www.apache.org/licenses/LICENSE-2.0\n\n# Unless required by applicable law or agreed to in writing, software\n# distributed under the License is distributed on an \"AS IS\" BASIS,\n# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\n# See the License for the specific language governing permissions and\n# limitations under the License.\n\n\"\"\"Example OpenHTF test demonstrating use of measurements.\n\nRun with (your virtualenv must be activated first):\n\n  python measurements.py\n\nAfterwards, check out the output in measurements.json.  If you open both this\nexample test and that output file and compare them, you should be able to see\nwhere measurement values end up in the output and what the corresponding code\nlooks like that sets them.\n\nTODO(someone): Write these examples.\nFor more complex topics, see the validators.py and dimensions.py examples.\n\nFor a simpler example, see the hello_world.py example.  If the output of this\ntest is confusing, start with the hello_world.py output and compare it to this\ntest's output.\n\nSome constraints on measurements:\n\n  - Measurement names must be valid python variable names.  This is mostly for\n    sanity, but also ensures you can access them via attribute access in phases.\n    This applies *after* any with_args() substitution (not covered in this\n    tutorial, see the phases.py example for more details).\n\n  - You cannot declare the same measurement name multiple times on the same\n    phase.  Technically, you *can* declare the same measurement on multiple\n    phases; measurements are attached to a specific phase in the output.  This\n    isn't recommended, though, because it makes it difficult to flatten a test's\n    measurements, which some output formats require.\n\"\"\"\n\n# Import openhtf with an abbreviated name, as we'll be using a bunch of stuff\n# from it throughout our test scripts. See __all__ at the top of\n# openhtf/__init__.py for details on what's in top-of-module namespace.\nimport openhtf as htf\n\n# Import this output mechanism as it's the specific one we want to use.\nfrom openhtf.output.callbacks import json_factory\n\n# You won't normally need to import this, see validators.py example for\n# more details.  It's used for the inline measurement declaration example\n# below, but normally you'll only import it when you want to define custom\n# measurement validators.\nfrom openhtf.util import validators\n\n\n# Simple example of measurement use, similar to hello_world.py usage.\n@htf.measures(htf.Measurement('hello_world_measurement'))\ndef hello_phase(test):\n  test.measurements.hello_world_measurement = 'Hello!'\n\n\n# An alternative simpler syntax that creates the Measurement for you.\n@htf.measures('hello_again_measurement')\ndef again_phase(test):\n  test.measurements.hello_again_measurement = 'Again!'\n\n\n# Multiple measurements can be specified in a single decorator, using either of\n# the above syntaxes.  Technically, these syntaxes can be mixed and matched, but\n# as a matter of convention you should always use one or the other within a\n# single decorator call.  You'll also note that you can stack multiple\n# decorations on a single phase.  This is useful if you have a handful of simple\n# measurements, and then one or two with more complex declarations (see below).\n@htf.measures('first_measurement', 'second_measurement')\n@htf.measures(htf.Measurement('third'), htf.Measurement('fourth'))\ndef lots_of_measurements(test):\n  test.measurements.first_measurement = 'First!'\n  # Measurements can also be access via indexing rather than attributes.\n  test.measurements['second_measurement'] = 'Second :('\n  # This can be handy for iterating over measurements.\n  for measurement in ('third', 'fourth'):\n    test.measurements[measurement] = measurement + ' is the best!'\n\n\n# Basic key/value measurements are handy, but we may also want to validate a\n# measurement against some criteria, or specify additional information\n# describing the measurement.  Validators can get quite complex, for more\n# details, see the validators.py example.\n@htf.measures(htf.Measurement('validated_measurement').in_range(0, 10).doc(\n    'This measurement is validated.').with_units(units.SECOND))\ndef measure_seconds(test):\n  # The 'outcome' of this measurement in the test_record result will be a PASS\n  # because its value passes the validator specified (0 <= 5 <= 10).\n  test.measurements.validated_measurement = 5\n\n\n# These additional attributes can also be specified inline as kwargs passed\n# directly to the @measures decorator.  If you do so, however, you must\n# specify exactly one measurement with that decorator (ie. the first argument\n# must be a string containing the measurement name).  If you want to specify\n# multiple measurements this way, you can stack multiple decorators.\n@htf.measures('inline_kwargs', docstring='This measurement is declared inline!',\n              units=units.HERTZ, validators=[validators.in_range(0, 10)])\n@htf.measures('another_inline', docstring='Because why not?')\ndef inline_phase(test):\n  # This measurement will have an outcome of FAIL, because the set value of 15\n  # will not pass the 0 <= x <= 10 validator.\n  test.measurements.inline_kwargs = 15\n  test.measurements.another_inline = 'This one is unvalidated.'\n\n  # Let's log a message so the operator knows the test should fail.\n  test.logger.info('Set inline_kwargs to a failing value, test should FAIL!')\n\n\nif __name__ == '__main__':\n  # We instantiate our OpenHTF test with the phases we want to run as args.\n  test = htf.Test(hello_phase, again_phase, lots_of_measurements,\n                  measure_seconds, inline_phase)\n\n  # In order to view the result of the test, we have to output it somewhere,\n  # and a local JSON file is a convenient way to do this.  Custom output\n  # mechanisms can be implemented, but for now we'll just keep it simple.\n  # This will always output to the same ./measurements.json file, formatted\n  # slightly for human readability.\n  test.add_output_callbacks(\n      json_factory.OutputToJSON('./measurements.json', indent=2))\n\n  # Unlike hello_world.py, where we prompt for a DUT ID, here we'll just\n  # use an arbitrary one.\n  test.execute(test_start=lambda: 'MyDutId')\n", "path": "examples/measurements.py"}], "after_files": [{"content": "# Copyright 2016 Google Inc. All Rights Reserved.\n\n# Licensed under the Apache License, Version 2.0 (the \"License\");\n# you may not use this file except in compliance with the License.\n# You may obtain a copy of the License at\n\n#     http://www.apache.org/licenses/LICENSE-2.0\n\n# Unless required by applicable law or agreed to in writing, software\n# distributed under the License is distributed on an \"AS IS\" BASIS,\n# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\n# See the License for the specific language governing permissions and\n# limitations under the License.\n\n\"\"\"Example OpenHTF test demonstrating use of measurements.\n\nRun with (your virtualenv must be activated first):\n\n  python measurements.py\n\nAfterwards, check out the output in measurements.json.  If you open both this\nexample test and that output file and compare them, you should be able to see\nwhere measurement values end up in the output and what the corresponding code\nlooks like that sets them.\n\nTODO(someone): Write these examples.\nFor more complex topics, see the validators.py and dimensions.py examples.\n\nFor a simpler example, see the hello_world.py example.  If the output of this\ntest is confusing, start with the hello_world.py output and compare it to this\ntest's output.\n\nSome constraints on measurements:\n\n  - Measurement names must be valid python variable names.  This is mostly for\n    sanity, but also ensures you can access them via attribute access in phases.\n    This applies *after* any with_args() substitution (not covered in this\n    tutorial, see the phases.py example for more details).\n\n  - You cannot declare the same measurement name multiple times on the same\n    phase.  Technically, you *can* declare the same measurement on multiple\n    phases; measurements are attached to a specific phase in the output.  This\n    isn't recommended, though, because it makes it difficult to flatten a test's\n    measurements, which some output formats require.\n\"\"\"\n\n# Import openhtf with an abbreviated name, as we'll be using a bunch of stuff\n# from it throughout our test scripts. See __all__ at the top of\n# openhtf/__init__.py for details on what's in top-of-module namespace.\nimport openhtf as htf\n\n# Import this output mechanism as it's the specific one we want to use.\nfrom openhtf.output.callbacks import json_factory\n\n# You won't normally need to import this, see validators.py example for\n# more details.  It's used for the inline measurement declaration example\n# below, but normally you'll only import it when you want to define custom\n# measurement validators.\nfrom openhtf.util import validators\n\n\n# Simple example of measurement use, similar to hello_world.py usage.\n@htf.measures(htf.Measurement('hello_world_measurement'))\ndef hello_phase(test):\n  test.measurements.hello_world_measurement = 'Hello!'\n\n\n# An alternative simpler syntax that creates the Measurement for you.\n@htf.measures('hello_again_measurement')\ndef again_phase(test):\n  test.measurements.hello_again_measurement = 'Again!'\n\n\n# Multiple measurements can be specified in a single decorator, using either of\n# the above syntaxes.  Technically, these syntaxes can be mixed and matched, but\n# as a matter of convention you should always use one or the other within a\n# single decorator call.  You'll also note that you can stack multiple\n# decorations on a single phase.  This is useful if you have a handful of simple\n# measurements, and then one or two with more complex declarations (see below).\n@htf.measures('first_measurement', 'second_measurement')\n@htf.measures(htf.Measurement('third'), htf.Measurement('fourth'))\ndef lots_of_measurements(test):\n  test.measurements.first_measurement = 'First!'\n  # Measurements can also be access via indexing rather than attributes.\n  test.measurements['second_measurement'] = 'Second :('\n  # This can be handy for iterating over measurements.\n  for measurement in ('third', 'fourth'):\n    test.measurements[measurement] = measurement + ' is the best!'\n\n\n# Basic key/value measurements are handy, but we may also want to validate a\n# measurement against some criteria, or specify additional information\n# describing the measurement.  Validators can get quite complex, for more\n# details, see the validators.py example.\n@htf.measures(htf.Measurement('validated_measurement').in_range(0, 10).doc(\n    'This measurement is validated.').with_units(htf.units.SECOND))\ndef measure_seconds(test):\n  # The 'outcome' of this measurement in the test_record result will be a PASS\n  # because its value passes the validator specified (0 <= 5 <= 10).\n  test.measurements.validated_measurement = 5\n\n\n# These additional attributes can also be specified inline as kwargs passed\n# directly to the @measures decorator.  If you do so, however, you must\n# specify exactly one measurement with that decorator (ie. the first argument\n# must be a string containing the measurement name).  If you want to specify\n# multiple measurements this way, you can stack multiple decorators.\n@htf.measures('inline_kwargs', docstring='This measurement is declared inline!',\n              units=htf.units.HERTZ, validators=[validators.in_range(0, 10)])\n@htf.measures('another_inline', docstring='Because why not?')\ndef inline_phase(test):\n  # This measurement will have an outcome of FAIL, because the set value of 15\n  # will not pass the 0 <= x <= 10 validator.\n  test.measurements.inline_kwargs = 15\n  test.measurements.another_inline = 'This one is unvalidated.'\n\n  # Let's log a message so the operator knows the test should fail.\n  test.logger.info('Set inline_kwargs to a failing value, test should FAIL!')\n\n\nif __name__ == '__main__':\n  # We instantiate our OpenHTF test with the phases we want to run as args.\n  test = htf.Test(hello_phase, again_phase, lots_of_measurements,\n                  measure_seconds, inline_phase)\n\n  # In order to view the result of the test, we have to output it somewhere,\n  # and a local JSON file is a convenient way to do this.  Custom output\n  # mechanisms can be implemented, but for now we'll just keep it simple.\n  # This will always output to the same ./measurements.json file, formatted\n  # slightly for human readability.\n  test.add_output_callbacks(\n      json_factory.OutputToJSON('./measurements.json', indent=2))\n\n  # Unlike hello_world.py, where we prompt for a DUT ID, here we'll just\n  # use an arbitrary one.\n  test.execute(test_start=lambda: 'MyDutId')\n", "path": "examples/measurements.py"}]}