README.md in stackprof-0.2.9 vs README.md in stackprof-0.2.10

@@ -22,11 +22,11 @@
 
 in ruby:
 
 ``` ruby
 StackProf.run(mode: :cpu, out: 'tmp/stackprof-cpu-myapp.dump') do
-  ...
+  #...
 end
 ```
 
 via rack:
 
@@ -75,10 +75,26 @@
                                     |    22  |   end
 ```
 
 For an experimental version of WebUI reporting of stackprof, see [stackprof-webnav](https://github.com/alisnic/stackprof-webnav)
 
+You can generate a flamegraph however additional data must be collected using the `raw: true` flag. Once you've collected results with this flag enabled you can generate a flamegraph:
+
+```
+$ stackprof --flamegraph tmp/stackprof-cpu-myapp.dump > tmp/flamegraph
+```
+
+Once the flamegraph has been generated you can generate a viewer command with:
+
+```
+$ stackprof --flamegraph-viewer=tmp/flamegraph
+```
+
+The `--flamegraph-viewer` command will output the exact shell command you need to run to open the `tmp/flamegraph` you generated with the built in stackprof flamegraph viewer:
+
+![](http://i.imgur.com/EwndrgD.png)
+
 ### sampling
 
 four sampling modes are supported:
 
   - :wall (using `ITIMER_REAL` and `SIGALRM`)
@@ -87,13 +103,34 @@
   - :custom (user-defined via `StackProf.sample`)
 
 samplers have a tuneable interval which can be used to reduce overhead or increase granularity:
 
   - wall time: sample every _interval_ microseconds of wallclock time (default: 1000)
+
+```ruby
+StackProf.run(mode: :wall, out: 'tmp/stackprof.dump', interval: 1000) do
+  #...
+end
+```
+
   - cpu time: sample every _interval_ microseconds of cpu activity (default: 1000 = 1 millisecond)
+
+```ruby
+StackProf.run(mode: :cpu, out: 'tmp/stackprof.dump', interval: 1000) do
+  #...
+end
+```
+
   - object allocation: sample every _interval_ allocations (default: 1)
 
+
+```ruby
+StackProf.run(mode: :object, out: 'tmp/stackprof.dump', interval: 1) do
+  #...
+end
+```
+
 samples are taken using a combination of three new C-APIs in ruby 2.1:
 
   - signal handlers enqueue a sampling job using `rb_postponed_job_register_one`.
     this ensures callstack samples can be taken safely, in case the VM is garbage collecting
     or in some other inconsistent state during the interruption.
@@ -103,10 +140,10 @@
     callstacks in allocation mode.
 
   - in allocation mode, samples are taken via `rb_tracepoint_new(RUBY_INTERNAL_EVENT_NEWOBJ)`,
     which provides a notification every time the VM allocates a new object.
 
-### aggregation
+### Aggregation
 
 each sample consists of N stack frames, where a frame looks something like `MyClass#method` or `block in MySingleton.method`.
 for each of these frames in the sample, the profiler collects a few pieces of metadata:
 
   - samples: number of samples where this was the topmost frame