qualify preformatted blocks

driver-cql-shaded/src/main/resources/advanced-cql.md

@@ -57,7 +57,7 @@ row data, you must apply a row operator as explained below.
 
 Examples:
 
-```
+```yaml
  statements:
    - s1: |
       a statement
@@ -70,7 +70,7 @@ Examples:
 
 Examples:
 
-```
+```yaml
   statements:
     - s2: |
        a statement

driver-cqld4/src/main/resources/advanced-cql.md

@@ -57,7 +57,7 @@ row data, you must apply a row operator as explained below.
 
 Examples:
 
-```
+```yaml
  statements:
    - s1: |
       a statement
@@ -70,7 +70,7 @@ Examples:
 
 Examples:
 
-```
+```yaml
   statements:
     - s2: |
        a statement

driver-http/src/main/resources/http.md

@@ -63,7 +63,6 @@ statements:
      Content-Type: application/json
     ok-status: 2[0-9][0-9]
     ok-body: ^(OK, account id is.*)$ 
-
 ```
 
 Of course, in the above form, the response validators are still separate parameters.

driver-jmx/src/main/resources/jmx.md

@@ -29,7 +29,7 @@ connection options such as SSL and authentication.
 The readvar operation is used to read a named attribute of the named object and store it in the
 thread local variable map.
 
-```
+```yaml
 statements:
   - read1:
      url: service:jmx:rmi:///jndi/rmi://dsehost:7199/jmxrmi
@@ -39,7 +39,6 @@ statements:
      as_name: pending_tasks     
      # process or thread, process is default
      scope: process
-     
 ```
 
 The `as_type` and `as_name`, and `scope` are optional, and if provided will set the name and
@@ -61,7 +60,7 @@ A combined format is available if you don't want to put every command property o
 In this format, the first entry in the command map is taken as the command name and a set of key=value
 command arguments. It is semantically equivalent to the above example, only more compact.
 
-```
+```yaml
 statements:
   - read1: readvar=Value as_type=int as_name=pending_tasks    
     url: service:jmx:rmi:///jndi/rmi://dsehost:7199/jmxrmi
@@ -74,7 +73,7 @@ If you want to simply read a value from a metric and print it out on stdout, you
 the `printvar` command. This is identical to the readvar command except that it puts the resulting
 variable (after any as_name and as_type options are applied) on the console.
 
-```
+```yaml
 statements:
   - read1: printvar=Value as_type=int as_name=pending_tasks     
     url: service:jmx:rmi:///jndi/rmi://dsehost:7199/jmxrmi
@@ -82,7 +81,8 @@ statements:
 ```
 
 This will produce an output like this:
-```
+
+```yaml
 # read JMX attribute ' Value' as class java.lang.Integer as_type=int as_name=pending_tasks
 pending_tasks=0
 ```
@@ -91,7 +91,7 @@ pending_tasks=0
 
 If you want to see the details about a managed object, you can use the explain command:
 
-```
+```yaml
 statements:
   - explain1:
      url: service:jmx:rmi:///jndi/rmi://dsehost:7199/jmxrmi
@@ -105,7 +105,7 @@ This is not meant for bulk testing, but more for explaining and documenting JMX
 
 The above example will produce an output like this:
 
-```
+```text
 ### MBeanInfo for 'org.apache.cassandra.metrics:type=Compaction,name=PendingTasks'
 # classname: org.apache.cassandra.metrics.CassandraMetricsRegistry$JmxGauge
 # Information on the management interface of the MBean

engine-docs/src/main/resources/docs-for-ebhistoric/nb-cli-docs/optimo.md

@@ -8,7 +8,7 @@ scenarios to take advantage of the BOBYQA optimization algorithm.
 To instantiate a new instance of optimo, call the extension object
 `optimos` in this way:
 
-```
+```js
 var optimo1 = optimos.init();
 ```
 
@@ -18,7 +18,7 @@ there only as a dispenser of new optimo instances, nothing more.
 To add a parameter to the optimo instance, use the `param` method like
 this:
 
-```
+```js
 optimo1.param('pressure', 1, 500);
 optimo1.param('temperature', 275, 307);
 ```
@@ -31,7 +31,7 @@ You should also set some initial parameters, which are key settings for
 the BOBYQA optimizer. Read more about BOBYQA to understand what these
 settings mean.
 
-```
+```js
 optimo1
  .setInitialRadius(10000.0) // The initial trust radius
  .setStoppingRadius(0.001)  // The stopping condition (trust radius)
@@ -47,7 +47,7 @@ parameters as you like.
 
 For example, you can add a function with this syntax:
 
-```
+```js
 optimo1.setObjectiveFunction(function(params) {
   return params.temperature * params.pressure
 });
@@ -55,7 +55,7 @@ optimo1.setObjectiveFunction(function(params) {
 
 In practice, this function will look much more like this:
 
-```
+```js
 optimo1.setObjectiveFunctikon(function(params) {
   provide_user_feedback_about_params(params);
   var result=run_test_with_params(params);
@@ -73,7 +73,7 @@ search pattern.
 Once you have configured an optimo instance, you can put it in control
 of the scenario with a call like this:
 
-```
+```js
 var result = optimo.optimize();
 ```
 

engine-docs/src/main/resources/docs-for-nb/designing_workloads/04_stmt_tags.md

@@ -88,6 +88,5 @@ I'm alive!
 # any(...) form will work as long as one of the tags match
 [test]$ ./nb run driver=stdout workload=stdout-test tags='any(name=fox.*,thisone:wontmatch)',unit=bravo
 I'm alive!
-
 ```
 

engine-docs/src/main/resources/docs-for-nb/designing_workloads/06_more_statements.md

@@ -126,7 +126,7 @@ map for the statement.
 By combining all the forms together with a map in the middle, we get this form, which allows for the
 enumeration of multiple statements, each with an obvious name, and a set of properties:
 
-```
+```yaml
 statements:
  - foostmt:
      stmt: "{alpha},{beta}\n"
@@ -284,7 +284,6 @@ statements:
  #    }
  # }
 
- # ---------------------------------------------------------------------------------------
-    
+ # ---------------------------------------------------------------------------------------    
 ```
 

engine-docs/src/main/resources/docs-for-nb/designing_workloads/10_named_scenarios.md

@@ -46,7 +46,7 @@ line, in which case it is automatically assumed to be _default_.
 
 Some examples may be more illustrative:
 
-```
+```text
 # runs the scenario named 'default' if it exists, or throws an error if it does not.
 nb myworkloads
 # or
@@ -127,6 +127,7 @@ This is a little counter-intuitive at first, but once you see some examples it s
 ## Parameter Override Examples
 
 Consider a simple workload with three named scenarios:
+
 ```yaml
 # basics.yaml
 scenarios:
@@ -142,7 +143,8 @@ statements:
 ```
 
 Running this with no options prompts the user to select one of the named scenarios:
-```
+
+```text
 $ nb basics
 ERROR: Unable to find named scenario 'default' in workload 'basics', but you can pick from s1,s2,s3
 $
@@ -153,7 +155,7 @@ $
 If you run the first scenario `s1` with your own value for `cycles=7`, it does as you
 ask:
 
-```
+```text
 $ nb basics s1 cycles=7
 Logging to logs/scenario_20200324_205121_554.log
 cycle=0
@@ -171,7 +173,7 @@ $
 If you run the second scenario `s2` with your own value for `cycles=7`, then it does what the locked parameter
 `cycles==10` requires, without telling you that it is ignoring the specified value on your command line.
 
-```
+```text
 $ nb basics s2 cycles=7
 Logging to logs/scenario_20200324_205339_486.log
 cycle=0
@@ -194,7 +196,8 @@ Sometimes, this is appropriate, such as when specifying settings like `threads==
 If you run the third scenario `s3` with your own value for `cycles=7`, then you will get an error telling you that this
 is not possible. Sometimes you want to make sure tha the user knows a parameter should not be changed, and that if they
 want to change it, they'll have to make their own custom version of the scenario in question.
-```
+
+```text
 $ nb basics s3 cycles=7
 ERROR: Unable to reassign value for locked param 'cycles===7'
 $

engine-docs/src/main/resources/docs-for-nb/getting_started/01_example_commands.md

@@ -12,7 +12,7 @@ Let's run a simple test against a cluster to establish some basic familiarity wi
 We will start by creating a simple schema in the database. From your command line, go ahead and execute the following
 command, replacing the `host=<host-or-ip>` with that of one of your database nodes.
 
-```
+```text
 ./nb run driver=cql workload=cql-keyvalue tags=phase:schema host=<host-or-ip>
 ```
 
@@ -62,7 +62,7 @@ Go ahead and execute the following command:
 
 You should see 10 of the following statements in your console
 
-```
+```cql
 insert into baselines.keyvalue (key, value) values (0,382062539);
 insert into baselines.keyvalue (key, value) values (1,774912474);
 insert into baselines.keyvalue (key, value) values (2,949364593);
@@ -101,7 +101,7 @@ These parameters are explained in detail in the section on _Activity Parameters_
 
 You should see output that looks like this
 
-```
+```text
 cql-keyvalue: 0.00%/Running (details: min=0 cycle=1 max=100000)
 cql-keyvalue: 0.00%/Running (details: min=0 cycle=1 max=100000)
 cql-keyvalue: 0.32%/Running (details: min=0 cycle=325 max=100000)
@@ -125,7 +125,7 @@ this runs a 50% read / 50% write workload.
 
 You should see output that looks like this:
 
-```
+```text
 Logging to logs/scenario_20190812_154431_028.log
 cql-keyvalue: 0.50%/Running (details: min=0 cycle=500 max=100000)
 cql-keyvalue: 2.50%/Running (details: min=0 cycle=2500 max=100000)

engine-docs/src/main/resources/docs-for-nb/getting_started/02_example_results.md

@@ -26,7 +26,7 @@ will be meaningful.
 Below is a sample of the log that gives us our basic metrics. There is a lot to digest here, for now we will only focus
 a subset of the most important metrics.
 
-```
+```text
 2019-08-12 15:46:00,274 INFO [main] i.e.c.ScenarioResult [ScenarioResult.java:48] -- BEGIN METRICS DETAIL --
 2019-08-12 15:46:00,294 INFO [main] i.e.c.ScenarioResult [Slf4jReporter.java:373] type=GAUGE, name=cql-keyvalue.cycles.config.burstrate, value=5500.0
 2019-08-12 15:46:00,295 INFO [main] i.e.c.ScenarioResult [Slf4jReporter.java:373] type=GAUGE, name=cql-keyvalue.cycles.config.cyclerate, value=5000.0

engine-docs/src/main/resources/docs-for-nb/getting_started/03_reading_metrics.md

@@ -17,7 +17,7 @@ For this example we see that we averaged 3732 operations / second with 3.6ms 75t
 percentile latency. Note the raw metrics are in microseconds. This duration_unit may change depending on how a user
 configures nosqlbench, so always double-check it.
 
-```
+```text
 2019-08-12 15:46:01,310 INFO [main] i.e.c.ScenarioResult [Slf4jReporter.java:373] type=TIMER,
  name=cql-keyvalue.result, count=100000, min=233.48, max=358596.607, mean=3732.00338612, stddev=10254.850416061185,
  median=1874.815, p75=3648.767, p95=10115.071, p98=15855.615, p99=23916.543, p999=111292.415,
@@ -34,7 +34,7 @@ Here we see that all 100k of our cycles succeeded. Note that the metrics for thr
 different than the `results` metric simply because this is a separate timer that only includes operations which
 completed with no exceptions.
 
-```
+```text
 2019-08-12 15:46:01,452 INFO [main] i.e.c.ScenarioResult [Slf4jReporter.java:373] type=TIMER,
  name=cql-keyvalue.result-success, count=100000, min=435.168, max=358645.759, mean=3752.40990808,
  stddev=10251.524945886964, median=1889.791, p75=3668.479, p95=10154.495, p98=15884.287, p99=24280.063,
@@ -47,7 +47,7 @@ completed with no exceptions.
 For read workloads, this metric shows the size of result sent back to nosqlbench from the server. This is useful to
 confirm that you are reading rows that already exist in the database.
 
-```
+```text
 2019-08-12 15:46:00,298 INFO [main] i.e.c.ScenarioResult [Slf4jReporter.java:373] type=HISTOGRAM,
  name=cql-keyvalue.resultset-size, count=100000, min=0, max=1, mean=8.0E-5, stddev=0.008943914131967056,
  median=0.0, p75=0.0, p95=0.0, p98=0.0, p99=0.0, p999=0.0
@@ -59,7 +59,7 @@ NoSQLBench will retry failures 10 times by default, this is configurable via the
 cql activity type. This metric shows a histogram of the number of tries that each operation required, in this example,
 there were no retries as the `count` is 100k.
 
-```
+```text
 2019-08-12 15:46:00,341 INFO [main] i.e.c.ScenarioResult [Slf4jReporter.java:373] type=HISTOGRAM,
  name=cql-keyvalue.tries, count=100000, min=1, max=1, mean=1.0, stddev=0.0, median=1.0,
  p75=1.0, p95=1.0, p98=1.0, p99=1.0, p999=1.0

engine-docs/src/main/resources/docs-for-nb/reference/cli_scripting.md

@@ -34,7 +34,9 @@ All activities that run during a scenario run under the control of, but independ
 means that you can have a number of activities running while the scenario script is doing its own thing. The scenario
 only completes when both the scenario script and the activities are finished.
 
-### `start driver=<activity type> alias=<alias> ...`
+### start an activity
+
+`start driver=<activity type> alias=<alias> ...`
 
 You can start an activity with this command. At the time this command is evaluated, the activity is started, and the
 script continues without blocking. This is an asynchronous start of an activity. If you start multiple activities in
@@ -44,18 +46,24 @@ The type argument is required to identify the activity type to run. The alias pa
 you want to be able to interact with the started activity later. In any case, it is a good idea to name all your
 activities with a meaningful alias.
 
-### `stop <alias>`
+### stop an activity
+
+`stop <alias>`
 
 Stop an activity with the given alias. This is synchronous, and causes the scenario to pause until the activity is
 stopped. This means that all threads for the activity have completed and signalled that they're in a stopped state.
 
-### `await <alias>`
+### await an activity
+
+`await <alias>`
 
 Await the normal completion of an activity with the given alias. This causes the scenario script to pause while it waits
 for the named activity to finish. This does not tell the activity to stop. It simply puts the scenario script into a
 paused state until the named activity is complete.
 
-### `run driver=<activity type> alias=<alias> ...`
+### run an activity
+
+`run driver=<activity type> alias=<alias> ...`
 
 Run an activity to completion, waiting until it is complete before continuing with the scenario script. It is
 effectively the same as
@@ -63,21 +71,27 @@ effectively the same as
     start driver=<activity type> ... alias=<alias>
     await <alias>
 
-### `waitmillis <milliseconds>`
+### wait millis
+
+`waitmillis <milliseconds>`
 
 Pause the scenario script for this many milliseconds. This is useful for controlling workload run duration, etc.
 
-### `script <script file>`
+### add a script
+
+`script <script file>`
 
 Add the contents of the named file to the scenario script buffer.
 
-### `fragment <script text>`
+### add a fragment
+
+`fragment <script text>`
 
 Add the contents of the next argument to the scenario script buffer.
 
 # An example CLI script
 
-~~~
+~~~text
 ./nb \
 start driver=stdout alias=a cycles=100K workload=cql-iot tags=phase:main\
 start driver=stdout alias=b cycles=200K workload=cql-iot tags=phase:main\