Asciidoctor (happi#66)

* Use asciidoctor to generate HTML version of the book
* Fix a few diagrams
* Style images
* Additions to .gitignore file
* Minor fixes

.gitignore

@@ -20,4 +20,6 @@ book.html
 chapters/contributors.txt
 xml/*.png
 xml/*.png.md5
-site
+site
+.asciidoctor
+.DS_Store

Makefile

@@ -1,45 +1,4 @@
 ABFLAGS = --backend=docbook --doctype=book
-adocs = book.asciidoc \
-	chapters/beam.asciidoc \
-	chapters/beam_instructions.asciidoc \
-	chapters/beam_internal_instructions.asciidoc \
-	chapters/beam_modules.asciidoc \
-	chapters/building.asciidoc \
-	chapters/c.asciidoc \
-	chapters/calls.asciidoc \
-	chapters/compiler.asciidoc \
-	chapters/contributors.txt \
-	chapters/data_structures.asciidoc \
-	chapters/debugging.asciidoc \
-	chapters/hipe.asciidoc \
-	chapters/introduction.asciidoc \
-	chapters/memory.asciidoc \
-	chapters/opcodes_doc.asciidoc \
-	chapters/ops.asciidoc \
-	chapters/preface.asciidoc \
-	chapters/processes.asciidoc \
-	chapters/scheduling.asciidoc \
-	chapters/tracing.asciidoc \
-	chapters/tweak.asciidoc \
-	chapters/type_system.asciidoc \
-	chapters/ap-beam_instructions.asciidoc \
-	chapters/ap-code_listings.asciidoc \
-	code/beam_modules_chapter/src/beamfile.erl \
-	code/compiler_chapter/json_tokens.png \
-	code/compiler_chapter/src/json_parser.erl \
-	code/compiler_chapter/src/json_test.erl \
-	code/compiler_chapter/src/json_tokens.xrl \
-	code/compiler_chapter/src/test.json \
-	code/compiler_chapter/src/world.erl \
-	code/memory_chapter/src/lb.erl \
-	code/memory_chapter/src/send.erl \
-	code/memory_chapter/src/share.erl \
-	code/processes_chapter/src/msg.erl \
-	images/observer_applications.png \
-	images/observer_code_server.png \
-	images/observer_load.jpg \
-	images/observer_processes.png \
-	images/observer_system.png
 
 DBLATEX_OPTS = -P latex.output.revhistory=0 -P doc.collab.show=0
 
@@ -48,14 +7,14 @@ all: beam-book.pdf index.html
 chapters/contributors.txt: .git
 	./bin/gitlog.sh $@
 
-xml/beam-book-from-ab.xml:  $(adocs)
+xml/beam-book-from-ab.xml:
 	asciidoc $(ABFLAGS) -o $@ book.asciidoc
 
 beam-book.pdf: xml/beam-book-from-ab.xml
 	dblatex $(DBLATEX_OPTS) xml/beam-book-from-ab.xml -o $@
 
 index.html:
-	asciidoc --backend=html5 --doctype=book -a icons -a toc2 -o site/index.html book.asciidoc
+	asciidoctor -r asciidoctor-diagram --backend=html5 --doctype=book -a icons -a toc2 -o site/index.html book.asciidoc
 
 code/book/ebin/generate_op_doc.beam: code/book/src/generate_op_doc.erl
 	erlc -o $(dir $@) $<

chapters/beam.asciidoc

@@ -142,6 +142,10 @@ then moves the value to a Y register.
       X1   |    |
      (X0)  |    |
            +----+
+
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
 Let us compile the following program with the _'S'_ flag:

chapters/beam_instructions.asciidoc

@@ -293,6 +293,10 @@ When allocating on the stack, the stack pointer (E) is decreased.
            ...                ...
  HTOP -> |     |    HTOP -> |     |
          | xxx |            | xxx |
+
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
 For a full listing of all types of allocate and deallocate

chapters/compiler.asciidoc

@@ -79,7 +79,7 @@ xref:fig_compiler_passes[].
     +---------------+
             |
             v
-    +---------------+    +---------------+    
+    +---------------+    +---------------+
     |     Parse     | -> | user defined  |
     |   Transform   | <- | transformation|
     +---------------+    +---------------+
@@ -173,6 +173,10 @@ xref:fig_compiler_passes[].
             |
             v
          (.beam)</pre>
+
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
 If you want to see a complete and up to date list of compiler passes

chapters/introduction.asciidoc

@@ -111,12 +111,15 @@ illustrated with two Erlang nodes running on one machine.
  | BEAM |  | BEAM |
  +------+  +------+
  | ERTS |  | ERTS |
- +------+  +------+
- +----------------+
+ +------+--+------+
  |       OS       |
  +----------------+
  |    HW or VM    |
  +----------------+
+
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
 At the bottom of the stack there is the hardware you are running
@@ -346,14 +349,16 @@ the BEAM compiler from the OTP layer to compile Erlang to Ling.
  | Ling |  | Ling |   | BEAM |  | BEAM |
  +------+  +------+   +------+  +------+
  | EoX  |  | EoX  |   | ERTS |  | ERTS |
- +------+  +------+   +------+  +------+
- +----------------+   +----------------+
+ +------+--+------+   +------+--+------+
  |      XEN       |   |       OS       |
  +----------------+   +----------------+
  |      HW        |   |    HW or VM    |
  +----------------+   +----------------+
-----
 
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
+----
 
 ==== Erjang
 
@@ -381,16 +386,17 @@ in Java on top of the VM.
  |Erjang|  |Erjang|   | BEAM |  | BEAM |
  +------+  +------+   +------+  +------+
  | JVM  |  | JVM  |   | ERTS |  | ERTS |
- +------+  +------+   +------+  +------+
- +----------------+   +----------------+
+ +------+--+------+   +------+--+------+
  |      OS        |   |       OS       |
  +----------------+   +----------------+
- |  HW or VM      |   |    HW or VM    |
+ |    HW or VM    |   |    HW or VM    |
  +----------------+   +----------------+
 
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
-
 Now that you have a basic understanding of all the major pieces of
 ERTS, and the necessary vocabulary you can dive into the details of
 each component. If you are eager to understand a certain component,

chapters/io.asciidoc

@@ -54,8 +54,11 @@ Erlang node.
   |   \__/            |
   |    P2             |
   +-------------------+
-----
 
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
+----
 
 Process P1 has opened a port (Port1) to a file, and is the owner of
 the port and can receive messages from the port. Process P2 also has a
@@ -128,6 +131,10 @@ driver like: `multi_drv` and `sig_drv`.
  |--------------------------------------------------+---------++------++----------+++-------+++--------|
  |                                                  | (Heart) || (ls) || tcp_inet ||| efile ||| ...    |
  +--------------------------------------------------+---------++------++----------+++-------+++--------+
+
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
 

chapters/memory.asciidoc

@@ -61,6 +61,10 @@ A program's memory layout looks something like this:
         +--------------+
  low
  addresses
+
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
 
@@ -339,9 +343,11 @@ multiblock |     Block 2   |       | MSmmbcs kb
  low
  addresses
 
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
-
 // Want most data un multiblock carriers mbc
 // increase sbct, then increase smbcs and lmbcs
 
@@ -591,6 +597,9 @@ similar to:
              |                ...                |
  heap ->     +-----------------------------------+
 
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
 If you then create a tuple with two instances of the list, all that is repeated is
@@ -714,6 +723,9 @@ look like this just before the send in p1/1:
 
 P2
 
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
 Then P1 start sending the message M to P2. It (through the code in
@@ -1316,17 +1328,12 @@ locality for one term most often is worse after a GC. With the size of
 modern cashes this should not be a problem. You could of course create
 a pathological example where it becomes a problem, but you can also
 create a pathological example where a depth first approach would cause
-problems. 
+problems.
 
 The third thing to note is that sharing is preserved which is really
 important otherwise we might end up using more space after a GC than
 before.
 
-
-
-
-
-
 Generations..
 
 [shaape]
@@ -1341,15 +1348,16 @@ Generations..
            |....|    |....|
   heap ->  +----+    +----+ old_heap
           The Heap   Old Heap
-----
 
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
+----
 
  +high_water, old_hend, old_htop, old_heap,
  gen_gcs, max_gen_gcs, off_heap,  mbuf, mbuf_sz, psd, bin_vheap_sz,
  bin_vheap_mature, bin_old_vheap_sz, bin_old_vheap+.
 
-
-
 //  ==== TODO
 //
 // Growth of the stack and heap, Shrinking. No Stack overflow? 

chapters/processes.asciidoc

@@ -427,6 +427,10 @@ See the following figure for an illustration of a process as memory:
   +-------+  +-------+
   | M-box |  | Heap  |
   +-------+  +-------+
+
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
 
@@ -709,6 +713,10 @@ fields from the PCB that controls the shape of the heap:
            |....|    v             v
   heap ->  +----+    -             -
           The Heap
+
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
 But wait, how come we have a heap start and a heap end, but no start
@@ -728,6 +736,10 @@ heap and the stack are actually just one memory area:
  +-------+  +-------+
  | M-box |  | Heap  |
  +-------+  +-------+
+
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
 The stack grows towards lower memory addresses and the heap towards
@@ -748,6 +760,10 @@ by adding the stack top pointer to the picture:
            |....|    v             v
   heap ->  +----+    -             -
           The Heap
+
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
 If the pointers `htop` and `stop` were to meet, the
@@ -808,6 +824,9 @@ our original picture of a process as four memory areas:
   | M-box |               | Heap  |  | Heap  |
   +-------+               +-------+  +-------+  - old_heap
 
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
 When a process starts there is no old heap, but as soon as young data
@@ -913,6 +932,9 @@ mailboxes) and a varying number of heap fragments (`m-bufs`):
  | m-buf |  | m-buf |  | m-buf |  | m-buf |
  +-------+  +-------+  +-------+  +-------+
 
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
 Each mailbox consists of a length and two pointers, stored in the fields
@@ -1048,6 +1070,9 @@ consider messages sent between Erlang nodes. Imagine two processes
  | +-------+  +-------+  +-------+ |
  +---------------------------------+
 
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
 Process `P1` will then take the following steps:
@@ -1104,6 +1129,9 @@ on the heap:
  |              +-------------+    |
  +---------------------------------+
 
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
 If `P1` can not get the `main lock` of P2 or there is not enough space
@@ -1151,6 +1179,9 @@ will end up in an `m-buf` but linked from the internal mailbox:
  |         +------------------+    |
  +---------------------------------+
 
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
 After a GC the message will be moved into
@@ -1200,6 +1231,9 @@ will end up in an `m-buf` and linked from the external mailbox:
  |                                 |
  +---------------------------------+
 
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
 After a GC the message will still be in the `M-buf`. Not until
@@ -1279,6 +1313,9 @@ memory area, PD, the process dictionary:
  | m-buf |  | m-buf |  | m-buf |  | m-buf |
  +-------+  +-------+  +-------+  +-------+
 
+options:
+ - ".*": {fill: [[0.7, 0.7, 0.7], no-shadow], frame: [[0.9, 0.9, 0.9], line]}
+ - ".*": {text : ["Monospace 10", no-shadow]}
 ----
 
 With such a small array you are bound to get some collisions before the