minor fixes (happi#127)

* redbug is no longer the part of eper

* Nice system! (where 1 ≡ 0.1)

* update CONTEXT_REDS

chapters/ap-beam_instructions.asciidoc

@@ -63,7 +63,7 @@ The comparison instructions are: `is_lt`,  `is_ge`,  `is_eq`,  `is_ne`, `is_eq_e
 
 Remember that all Erlang terms are ordered so these instructions can compare any two terms. You can for example test if the atom `self` is less than the pid  returned by `self()`. (It is.)
 
-Note that for numbers the comparison is done on the Erlang type _number_, see xref:CH-TypeSystem[]. That is, for a mixed float and integer comparison the number of lower precision is converted to the other type before comparison. For example on my system 1 and 0.1 compares as equal, as well as 9999999999999999 and 1.0e16. Comparing floating point numbers is always risk and best avoided, the result may wary depending on the underlying hardware.
+Note that for numbers the comparison is done on the Erlang type _number_, see xref:CH-TypeSystem[]. That is, for a mixed float and integer comparison the number of lower precision is converted to the other type before comparison. For example on my system 1 and 1.0 compares as equal, as well as 9999999999999999 and 1.0e16. Comparing floating point numbers is always risk and best avoided, the result may wary depending on the underlying hardware.
 
 If you want to make sure that the integer 1 and the floating point number 1.0 are compared different you can use is_eq_exact and is_ne_exact. This corresponds to the Erlang operators `=:=` and `=/=`.
 

chapters/debugging.asciidoc

@@ -46,36 +46,34 @@ TODO
 == Redbug
 
 _Redbug_ is a debugging utility which allows you to easily interact
-with the Erlang _tracing facilities_. It is an external library which
-is part of the https://github.com/massemanet/eper[eper] performance
-and debugging suite for Erlang and therefore it has to be installed
-separately. One of the best Redbug features is its ability to shut
-itself down in case of overload.
+with the Erlang _tracing facilities_. It is an external library and
+therefore it has to be installed separately. One of the best Redbug
+features is its ability to shut itself down in case of overload.
 
 === Installing Redbug
 
 You can clone redbug via:
 
 [source,bash]
 ----
-$ git clone https://github.com/massemanet/eper.git
+$ git clone https://github.com/massemanet/redbug
 ----
 
 You can then compile it with:
 
 [source,bash]
 ----
-$ cd eper
+$ cd redbug
 $ make
 ----
 
-Ensure `eper` is included in your path when starting an Erlang shell
+Ensure `redbug` is included in your path when starting an Erlang shell
 and you are set to go. This can be done by explicitely adding the path
-to the eper _beam_ files when invoking `erl`:
+to the redbug _beam_ files when invoking `erl`:
 
 [source,bash]
 ----
-$ erl -pa /path/to/eper/ebin
+$ erl -pa /path/to/redbug/ebin
 ----
 
 Alternatively, the following line can be added to the `~/.erlang`
@@ -84,7 +82,7 @@ automatically at every startup:
 
 [source,erlang]
 ----
-code:add_patha("/path/to/eper/ebin").
+code:add_patha("/path/to/redbug/ebin").
 ----
 
 === Using Redbug

chapters/scheduling.asciidoc

@@ -150,7 +150,7 @@ then tries to solve each part.
 
 When a process is scheduled it will get a number of reductions defined
 by `CONTEXT_REDS` (defined in +erl_vm.h+,
-currently as 2000). After using
+currently as 4000). After using
 up its reductions or when doing a receive without a matching message
 in the inbox, the process will be suspended and a new processes will
 be scheduled.
@@ -695,9 +695,9 @@ This is done by the function _check_balance_ in _erl_process.c_.
 
 The migration is done by first setting up a migration plan and then
 letting schedulers execute on that plan until a new plan is set up.
-Every 2000*2000 reductions a scheduler calculates a migration path per
-priority per scheduler by looking at the workload of all
-schedulers. The migration path can have three different types of
+Every 2000*CONTEXT_REDS reductions a scheduler calculates
+a migration path per priority per scheduler by looking at the workload
+of all schedulers. The migration path can have three different types of
 values: 1) cleared 2) migrate to scheduler # 3) immigrate from
 scheduler #