Rename all files (no check yet)

```bash
for f in *.textile; do
	awk -f t.textile2md.awk $f > ${f%.textile}.md && rm $f
done
```

Author: BuonOmo

anyeval.textile anyeval.md

@@ -2,9 +2,11 @@
 layout: default
 ---
 
-h1. Final Chapter: Ruby's future
+Final Chapter: Ruby's future
+----------------------------
 
-h2. Issues to be addressed
+Issues to be addressed
+======================
 
 `ruby` isn't 'completely finished' software. It's still being developed,
 there are still a lot of issues. Firstly, we want to try removing
@@ -14,7 +16,7 @@ The order of the topics is mostly in the same order as the chapters of
 this book.
 
 
-h3. Performance of GC
+### Performance of GC
 
 The performance of the current GC might be
 "not notably bad, but not notably good".
@@ -41,7 +43,7 @@ However, if such application will actually be created in the future,
 there might be the necessity to consider Incremental GC.
 
 
-h3. Implementation of parser
+### Implementation of parser
 
 As we saw in Part 2, the implementation of `ruby` parser has already utilized
 `yacc`'s ability to almost its limit, thus I can't think it can endure further
@@ -51,7 +53,7 @@ and it's sad if we could not express another demanded grammar because of the
 limitation of `yacc`.
 
 
-h3. Reuse of parser
+### Reuse of parser
 
 Ruby's parser is very complex. In particular, dealing with around `lex_state`
 seriously is very hard. Due to this, embedding a Ruby program or creating a
@@ -84,22 +86,22 @@ while parsing.
 
 
 
-h3. Hiding Code
+### Hiding Code
 
 With current `ruby`, it does not work without the source code of the program to
 run. Thus, people who don't want others to read their source code might have
 trouble.
 
 
-h3. Interpretor Object
+### Interpretor Object
 
 Currently each process cannot have multiple `ruby` interpretors,
 this was discussed in Chapter 13.
 If having multiple interpretors is practically possible, it seems better,
 but is it possible to implement such thing?
 
 
-h3. The structure of evaluator
+### The structure of evaluator
 
 Current `eval.c` is, above all, too complex.
 Embedding Ruby's stack frames to machine stack could occasionally become the
@@ -110,7 +112,7 @@ aggressively can easily cause slowing down because `setjmp()` set aside all
 things in registers.
 
 
-h3. The performance of evaluator
+### The performance of evaluator
 
 `ruby` is already enough fast for ordinary use.
 But aside from it, regarding a language processor,
@@ -120,7 +122,7 @@ what can we do?
 In such case, the first thing we have to do is profiling.
 So I profiled.
 
-<pre class="emlist">
+```TODO-lang
   %   cumulative   self              self     total
  time   seconds   seconds    calls  ms/call  ms/call  name
  20.25      1.64     1.64  2638359     0.00     0.00  rb_eval
@@ -132,7 +134,7 @@ So I profiled.
   5.19      5.27     0.42   388066     0.00     0.00  st_foreach
   3.46      5.55     0.28  8605866     0.00     0.00  rb_gc_mark
   2.22      5.73     0.18  3819588     0.00     0.00  call_cfunc
-</pre>
+```
 
 This is a profile when running some application but
 this is approximately the profile of a general Ruby program.
@@ -152,7 +154,7 @@ In other words, without changing the way of thinking fundamentally,
 there's no room to improve.
 
 
-h3. The implementation of thread
+### The implementation of thread
 
 This was also discussed in Chapter 19. There are really a lot of issues about
 the implementation of the current ruby's thread. Particularly, it cannot mix
@@ -164,13 +166,14 @@ cannot continue to use eternally, isn't it?
 
 
 
-h2. `ruby` 2
+`ruby` 2
+========
 
 Subsequently, on the other hand, I'll introduce the trend of the original `ruby`,
 how it is trying to counter these issues.
 
 
-h3. Rite
+### Rite
 
 At the present time, ruby's edge is 1.6.7 as the stable version and 1.7.3 as the
 development version, but perhaps the next stable version 1.8 will come out in
@@ -195,7 +198,7 @@ entirely just a "plan". If you expect so much, it's possible it will turn out
 disappointments. Therefore, for now, let's just expect slightly.
 
 
-h3. The language to write
+### The language to write
 
 Firstly, the language to use. Definitely it will be C. Mr. Matsumoto said to
 `ruby-talk`, which is the English mailing list for Ruby,
@@ -210,7 +213,7 @@ so not to increase extra efforts around this is necessary.
 However, chances are good that it will be ANSI C next time.
 
 
-h3. GC
+### GC
 
 Regarding the implementation of GC,
 the good start point would be
@@ -223,7 +226,7 @@ perpetually, but anyway it will proceed for the direction to which we can expect
 somewhat improvement on speed.
 
 
-h3. Parser
+### Parser
 
 Regarding the specification, it's very likely that the nested method calls
 without parentheses will be forbidden. As we've seen, `command_call` has a great
@@ -237,7 +240,7 @@ possible to implement such complex thing by hand? Such anxiety might left.
 Whichever way we choose, the path must be thorny.
 
 
-h3. Evaluator
+### Evaluator
 
 The evaluator will be completely recreated.
 Its aims are mainly to improve speed and to simplify the implementation.
@@ -285,7 +288,7 @@ For another example, Python is a bytecode interpretor.
 
 
 
-h3. Thread
+### Thread
 
 Regarding thread, the thing is native thread support.
 The environment around thread has been significantly improved,
@@ -308,7 +311,7 @@ and it is rarely actually used. Therefore there might be no problem.
 
 
 
-h3. M17N
+### M17N
 
 In addition, I'd like to mention a few things about class libraries.
 This is about multi-lingualization (M17N for short).
@@ -325,7 +328,7 @@ it will be absorbed at some point in the middle of 1.9.
 
 
 
-h3. IO
+### IO
 
 
 The `IO` class in current Ruby is a simple wrapper of `stdio`,
@@ -342,7 +345,8 @@ Therefore, it seems Rite will have its own `stdio`.
 
 
 
-h2. Ruby Hacking Guide
+Ruby Hacking Guide
+==================
 
 
 So far, we've always acted as observers who look at `ruby` from outside.
@@ -353,7 +357,7 @@ I'll introduce the suggestions and activities for `ruby` from community,
 as a farewell gift for Ruby Hackers both at present and in the future.
 
 
-h3. Generational GC
+### Generational GC
 
 First, as also mentioned in Chapter 5,
 the generational GC made by Mr. Kiyama Masato.
@@ -368,7 +372,7 @@ more than anything else, it was the first large non-official patch.
 
 
 
-h3. Oniguruma
+### Oniguruma
 
 The regular expression engine used by current Ruby is a remodeled version of GNU
 regex. That GNU regex was in the first place written for Emacs. And then it was
@@ -386,13 +390,13 @@ absorbed as soon as possible.
 
 You can obtain Oniguruma from the `ruby`'s CVS repository in the following way.
 
-<pre class="screen">
+```TODO-lang
 % cvs -d :pserver:[email protected]:/src co oniguruma
-</pre>
+```
 
 
 
-h3. ripper
+### ripper
 
 Next, ripper is my product. It is an extension library made by remodeling
 `parse.y`. It is not a change applied to the `ruby`'s main body, but I
@@ -411,14 +415,14 @@ if this is accounted, I think it is constructed well.
 It took only three days or so to implement, really just a piece of cake.
 
 
-h3. A parser alternative
+### A parser alternative
 
 This product has not yet appeared in a clear form,
 there's a person who write a Ruby parser in C++ which can be used totally
 independent of `ruby`. (`[ruby-talk:50497]`).
 
 
-h3. JRuby
+### JRuby
 
 More aggressively, there's an attempt to rewrite entire the interpretor.
 For example, a Ruby written in Java,
@@ -452,7 +456,7 @@ However, the overall impression I got was, it's way better than I imagined.
 
 
 
-h3. NETRuby
+### NETRuby
 
 If it can run with Java, it should also with C#.
 Therefore, a Ruby written in C# appeared,
@@ -471,7 +475,7 @@ such things are the problems.
 But `instance_eval` is in effect (astounding!).
 
 
-h3. How to join `ruby` development
+### How to join `ruby` development
 
 `ruby`'s developer is really Mr. Matsumoto as an individual,
 regarding the final decision about the direction `ruby` will take,
@@ -523,7 +527,7 @@ I'll answer it as much as possible,
 and other people would respond to it, too.
 
 
-h3. Finale
+### Finale
 
 The long journey of this book is going to end now.
 As there was the limitation of the number of pages,