Merge pull request happi#55 from hirotnk/master

minor fixes

Makefile

@@ -67,4 +67,4 @@ genop.tab:
 	touch $@
 
 clean:
-	rm -f beam-book.pdf book.html
+	rm -f beam-book.pdf site/index.html

chapters/compiler.asciidoc

@@ -57,13 +57,13 @@ compiler to return Core Erlang code you can give the options +[core,
 
 
 The compiler is made up of a number of passes as illustrated in 
-xref:fig_compiler_passes[Compiler Passes].
+xref:fig_compiler_passes[].
 
 [[fig_compiler_passes]]
 .Compiler Passes
 [shaape]
 ----
-[] = Compiler options, () = files, {} = erlang terms, boxes = passes </title>
+[] = Compiler options, () = files, {} = erlang terms, boxes = passes
          (.erl)
             |
             v
@@ -418,15 +418,15 @@ is a bit of a nuisance since you can't give options to the parse transform
 from the code.
 
 The compiler does not expand compiler options until the _expand_ pass
-which occures after the parse transform pass.
+which occurs after the parse transform pass.
 ====
 
 The documenation of the abstract format is somewhat dense and it is
 quite hard to get a grip on the abstract format by reading the
 documentation. I encourage you to use the _syntax_tools_ and
 especially +erl_syntax_lib+ for any serious work on the AST.
 
-Here we will develop a a simple parse transform just to get an
+Here we will develop a simple parse transform just to get an
 understanding of the AST. Therefore we will work directly on the AST
 and use the old reliable +io:format+ approach instead of syntax_tools.
 
@@ -614,20 +614,20 @@ And now we can compile +json_test+ without errors:
 ----
 
 The AST generated by +parse_teansfom/2+ must correspond to valid
-Erlang code. Unless you apply several parse transforms, which is
+Erlang code unless you apply several parse transforms, which is
 possible. The validity of the code is checked by the following
 compiler pass.
 
 ==== Compiler Pass: Linter
 
-The linter (+erl_lint.erl+) generaters warnings for syntactically
+The linter (+erl_lint.erl+) generates warnings for syntactically
 correct but otherwise bad code, like "export_all flag enabled".
 
 
 ==== Compiler Pass: Save AST
 
 In order to enable debugging of a module, you can "debug compile" the
-module, that is pass the option +debug_info+ to the compiler. The
+module, that is to pass the option +debug_info+ to the compiler. The
 abstract syntax tree will then be saved by the "Save AST" until the
 end of the compilation, where it will be written to the .beam file.
 
@@ -713,7 +713,7 @@ of functions to manipulate abstract forms -- Syntax Tools.
 
 Leex is the Erlang lexer generator.
 The lexer generator takes a description of a DFA from a definitions
-file (<fileextension>xrl</fileextension>) and produces an Erlang
+file +xrl+ and produces an Erlang
 program that matches tokens described by the DFA.
 
 The details of how to write a DFA definition for a tokenizer
@@ -728,7 +728,7 @@ If you have info and flex installed you can read the full manual by typing:
 ----
 
 The online Erlang documentation also has the leex manual
-(see [yecc.html](http://erlang.org/doc/man/yecc.html)).
+(see link:http://erlang.org/doc/man/yecc.html[yecc.html]).
 
 We can use the lexer generator to create an Erlang program which
 recognizes JSON tokens. By looking at the JSON definition
@@ -762,7 +762,9 @@ image::../code/compiler_chapter/json_tokens.png[]
 
 We can try our tokenizer on an example json file (test.json).
 
-include::../code/compiler_chapter/src/test.json
+----
+include::../code/compiler_chapter/src/test.json[]
+----
 
 First we need to compile our tokenizer, then we read the file
 and convert it to a string. Finally we can use
@@ -783,7 +785,7 @@ The shell function f/1 tells the shell to forget a variable
 binding. This is useful if you want to try a command that binds a
 variable multiple times, for example as you are writing the lexer and
 want to try it out after each rewrite. We will look at the shell
-commands in detail in the a later chapter.
+commands in detail in the later chapter.
 
 Armed with a tokenizer for JSON we can now write a json parser
 using the parser generator Yecc.
@@ -797,11 +799,14 @@ Yecc is a parser generator for Erlang. The name comes from Yacc
 Now that we have a lexer for JSON terms we can write a parser using
 yecc.
 
+[source,erlang]
+----
 include::../code/compiler_chapter/src/yecc_json_parser.yrl[]
+----
 
 Then we can use yecc to generate an Erlang program that implements
 the parser, and call the parse/1 function provided with the tokens
-generated by the tokenizer as argument.
+generated by the tokenizer as an argument.
 
 [source, erlang]
 ----
@@ -835,7 +840,7 @@ With Merl you can very easily manipulate the syntax tree and write
 parse stransforms in Erlang code.
 
 You can find the documentation for Syntax Tools on the
-Erlang.org site: [http://erlang.org/doc/apps/syntax_tools/chapter.html](http://erlang.org/doc/apps/syntax_tools/chapter.html).
+Erlang.org site: link:http://erlang.org/doc/apps/syntax_tools/chapter.html[http://erlang.org/doc/apps/syntax_tools/chapter.html].
 
 === Compiling Elixir
 
@@ -844,5 +849,5 @@ the meta programming tools in Elixir. Elixir compiles to Beam code through
 the Erlang abstraxt syntax tree.
 
 With Elixir's defmacro you can define your own Domain Specific Language,
-direcly in Elixir.
+directly in Elixir.
 

chapters/processes.asciidoc

@@ -348,19 +348,17 @@ or from the Erlang shell with:
 ----
 
 When the Observer is started it will show you a system overview,
-see the following screen shot.
+see the following screen shot:
 
-<figure id="fig-observer_system">
+image::../images/observer_system.png[]
 
-<imagedata fileref="images/observer_system.png"/>
-</figure>
 We will go over some of this information in detail later in
 this and the next chapter. For now we will just use the Observer to look
 at the running processes. First we take a look at the
 `Application` tab which shows the supervision
 tree of the running system:
 
-![](images/observer_applications.png)
+image::../images/observer_applications.png[]
 
 Here we get a graphical view of how the processes are linked. This is
 a very nice way to get an overview of how a system is structured.
@@ -370,7 +368,7 @@ floating in space connected to each other through links.
 To actually get some useful information about the processes
 we switch to the `Processes` tab:
 
-![](images/observer_processes.png)
+image::../images/observer_processes.png[]
 
 In this view we get basically the same information as with
 `i/0` in the shell. We see the pid, the registered name,
@@ -381,7 +379,7 @@ We can also look into a process by double clicking on its
 row, for example on the code server, to get the kind of
 information you can get with `process_info/2`:
 
-![](images/observer_code_server.png)
+image::../images/observer_code_server.png[]
 
 We will not go through what all this information means
 right now, but if you keep on reading all will eventually