-
- Used to set the value of a literal. The stack top is set to the literal
- indicated by the operand.
-
-
-
-
-
Before
After
-
-
-
value
value
-
...
...
-
-
-
-#### Notes
- Unlike other literals such as strings and numbers, creating a Regexp
- literal (i.e. via the /regex/ syntax) is a two step process to create the
- literal slot for the Regexp, create a literal for the string between the
- '/' delimiters and create a new Regexp object passing it the string. Only
- then can the literal value be set, using the set_literal opcode.
-
-
-
- Unconditionally moves the instruction pointer to the position specified by
- _location_.
-
-
-
-
-
Before
After
-
-
-
...
...
-
-
-
-#### Notes
- All goto instructions use absolute addressing. This is absolute movement
- rather than a relative one, so the operand must specify the ip starting
- from 0 to move to.
-
-
-
-
- Return a value to the direct caller
-
- Pops the top value from the stack, and returns to the direct caller of the
- current invocation.
-
-
-
-
-
Before
After
-
-
-
value
value
-
...
...
-
-
-
-#### Notes
- In a method, the `return` keyword uses this instruction. In a block
- though, `return` uses the raise_return instruction and `next` uses this
- instruction.
-
-
-
-
- Duplicate multiple values on the stack
-
- Read _count_ values from the stack and push them onto the stack again
- in order without removing the original values.
-
-
-
-
- Pushes the value of a local from an enclosing scope onto the stack
-
- Retrieves the value of a local variable. Operand _depth_ indicates how many
- upward enclosing scopes to walk up and then operand _index_ indicates which
- local in that context to read. The value is then pushed on the stack.
-
-
-
-
-
Before
After
-
-
-
...
value
-
...
-
-
-
-#### Example
- k = 0
- foo.each do |i|
- bar.each do |j|
- # i is a local variable from enclosing scope at depth 1
- # k is a local variable from enclosing scope at depth 2
- i = i + j + k
- end
- end
-
-
-
-
- Updates the value of a local variable contained in an enclosing scope
-
- Read a value from the top of the stack and use it to update a local
- variable in an enclosing scope. The _depth_ and _index_ operands
- identify the specific local the same as in `push_local_depth`.
-
-
-
-
-
Before
After
-
-
-
value
value
-
...
...
-
-
-
-#### Example
- foo.each do |i|
- bar.each do |j|
- i = i + j # i is a local variable from enclosing scope at depth 1
- end
- end
-
-
-
-
- Pushes the current exception onto the stack, so that it can be used for
- some purpose, such as checking the exception type, setting an exception
- variable in a rescue clause, etc.
-
-
-
-
-
Before
After
-
-
-
...
exception
-
...
-
-
-
-#### Example
- begin
- foo = BAR # BAR is not defined
- rescue NameError # push_exception used to check type of exception (via ===)
- puts "No BAR"
- end
-
-
-
-
- Package up the current exception state into an object and push it. This
- is used to preserve the exception state around code that might mutate it.
- For instance, when handling an ensure while an exception is being raised
-
-
-
-
- Pops a value off the stack and set the threads exception state from it.
- This instruction is only to be used with a value pushed on the stack
- by the push_exception_state instruction.
-
-
-
-
- Raises an exception
-
- Pops a value off the stack and make it the current exception.
- If the value is not an instance of Exception, a TypeError is raised.
-
-
-
-
- Register an unwind handler
-
- Registers what to happen when an exception wants to unwind through the
- current invocation. Operand _ip_ specifies where to set the instruction
- pointer if used. Operand _type_ is either 0 for if the value should be
- used in rescue style (not run when unwinding because of a return caused by
- `raise_return`) or 1 for ensure style (always used). The registrations are
- nested within the current invocation and are automatically removed from
- the registry when they are used. The `pop_unwind` instruction can be used
- to remove an unused registration.
-
-
-
-
-
Before
After
-
-
-
...
...
-
-
-
-#### Notes
- The registration also contains the value of the stack depth when
- created. If the registration is used, then the stack depth is
- restored to the value contained in the registration
-
-
-
-
- Remove the next unused unwind registration from the current invocation.
- This instruction is paired with `setup_unwind` to remove registrations
- when control exits a section of code that registered a handler but didn't
- use it. For example, exiting a begin that had a rescue expression.
-
-
-
-
- Cause the toplevel enclosing scope to return
-
- Only used in a block, pop a value from the stack and raise a special
- internal exception and begin unwinding the stack. The toplevel method
- scope will rescue the exception and return the value.
-
-
-
-
- Return from a scope but run ensures first
-
- A one use instruction, used only in a method toplevel within a begin
- that has an ensure. Use the same internal exception as `raise_return`
- which will coax the ensure registration to run.
-
-
-
-
- Create an array and populate with values on the stack
-
- Creates a new array, populating its contents by remove the number of
- values specified by operand _count_ and putting them into the array in the
- order they were on the stack. The resulting array is pushed onto the
- stack.
-
-
-
-
- Removes the object on the top of the stack, and:
-
- 1. If the input is a tuple, a new array object is created based on the
- tuple data.
- 2. If the input is an array, it is unmodified.
- 3. If in 1.9 mode and the input is nil, an empty Array is returned
-
- If the input is any other type, call `Rubinius::Type.coerce_to_array(value)`.
- If the return value of the method call is an `Array`, make it the result.
- Otherwise make the result an 1 element `Array` contain the original value.
-
- The resulting array is then pushed back onto the stack.
-
-
-
-
- Pops an array off the top of the stack. If the array is empty, it is
- pushed back onto the stack, followed by `nil`.
-
- Otherwise, the array is shifted, then pushed back onto the stack,
- followed by the object that was shifted from the front of the array.
-
-
-
-
- Pops a value off the stack, and uses it to set the value of the instance
- variable identifies by the literal specified by operand _literal_. The
- value popped off the stack is then pushed back on again.
-
-
-
-
- Locates the constant indicated by the operand _literal_ from the current
- context, and pushes it onto the stack. If the constant cannot be found in
- the current context, nothing is pushed onto the stack, and a NameError
- exception is raised.
-
-
-
-
-
Before
After
-
-
-
...
constant
-
...
-
-
-
-#### Example
- engine = RUBY_ENGINE # RUBY_ENGINE is a constant defined by Rubinius
-
-
-
- Pop a value from the literals table specified by the operand _literal_ and
- use it as the value of a constant named inside a Module object popped from
- the stack. The _value_ is pushed back on the stack.
-
-
-
-
- Pops _module_ off the stack, and searches within its namespace for the
- constant named by the literal specified by the operand _literal_. If found,
- it is pushed onto the stack; otherwise, nothing is pushed onto the stack,
- and a `NameError` exception is raised.
-
-
-
-
- Pushes the top-level global object that represents the top-level namespace
- for constants. Used to find constants relative to the toplevel. In Ruby,
- this is the class `Object`.
-
-
-
-
- Pushes a constant onto the stack. Caches the lookup to provide faster
- future lookup. This instruction is normally emitted only by the Generator.
-
-
-
-
-
Before
After
-
-
-
...
constant
-
...
-
-
-
-#### Example
- engine = RUBY_ENGINE # RUBY_ENGINE is a constant defined by Rubinius
-
-
-
-
- Pushes a constant onto the stack scoped under the module on the top of
- the stack. Caches the lookup to provide faster future lookup. This
- instruction is normally emitted only by the Generator.
-
-
-
-
- The call flags on the current execution context are set to the opcode
- argument _flags_.
-
-
-
-
-
Before
After
-
-
-
...
...
-
-
-
-#### Notes
- Currently this only has one use, which is that send_stack_with_splat
- checks if flags is set to CALL_FLAG_CONCAT which indicates that
- the splat represents arguments at the beginning rather than the end.
-
-
-
- Pops a _receiver_ object off the top of the stack and sends it the
- message specified by the operand _literal_ with zero arguments.
-
- When the method returns, the return value is pushed on the stack.
-
-
-
-
-
Before
After
-
-
-
receiver
value
-
...
...
-
-
-
-#### Notes
- This form of send is for methods that take no arguments.
-
-
-
-
- Sends a message with arguments on the stack
-
- Pops the _receiver_ of the message off the stack and sends the message
- specified by the operand _literal_ with _count_ arguments. The arguments
- are removed from the stack also.
-
- When the method returns, the return value is pushed on the stack.
-
-
-
-
-
Before
After
-
-
-
argN
-
value
-
-
...
-
...
-
-
arg2
-
-
arg1
-
-
receiver
-
-
-
-
-#### Notes
- This opcode does not pass a block to the receiver; see
- `send_stack_with_block` for the equivalent op code used when a block is to
- be passed.
-
-
-
-
- Sends a message with arguments and a block on the stack
-
- Pops the _receiver_ of the message off the stack and sends the message
- specified by the operand _literal_ with _count_ arguments. The arguments
- are removed from the stack also. A value that represents the block to pass
- on is popped off the stack after the normal arguments.
-
- When the method returns, the return value will be on top of the stack.
-
-
-
-
-
Before
After
-
-
-
block
-
retval
-
-
argN
-
...
-
-
...
-
-
arg2
-
-
arg1
-
-
receiver
-
-
-
-
-#### Notes
- This opcode passes a block to the receiver; see `send_stack` for the
- equivalent op code used when no block is to be passed.
-
-
-
-
- Call a method on the superclass with a block
-
- The same as `send_stack_with_block`, but receiver is the current self
- instead of being read from the stack, and the method to call is looked up
- starting with the receiver superclass.
-
-
-
-
- Call a method on the superclass, passing args plus a block.
-
- The same as `send_stack_with_block`, but receiver is the current `self`
- instead of being read from the stack, and the method to call is looked up
- starting with the receiver superclass.
-
-
-
-
- Read a CompiledCode specified by the operand +literal+ and create a
- `BlockEnvironment`. Push the new `BlockEnvironment` object on the stack.
-
-
-
-
- Converts the value on the top of the stack into an argument for a block
- taking one argument.
-
- The value on the top of the stack is popped, and:
-
- If it has no fields, the result is `nil`.
-
- If the value contains a single field, the result is the value in the
- first field.
-
- Otherwise, package up all the arguments in an `Array` as the result.
-
- The result is then pushed onto the stack.
-
-
-
-
-
Before
After
-
-
-
...
argument
-
...
-
-
-
-#### Notes
- This is a single use instruction, only used to simplify how to handle a
- block that accepts one argument.
-
-
-
- Converts a block argument single-valued tuple into multiple arguments if
- the arg is an array.
-
- If the Proc invoked from was in lambda mode, and one argument is passed:
- * and it's an Array, push it.
- * and it responds to `#to_ary`, try and convert it and push it.
- * otherwise wrap it in a one element Array and push it.
-
- Otherwise:
- Package up the arguments into an `Array` and push it onto the stack.
-
-
-
-
-
Before
After
-
-
-
value1
-
array[value1,..] | value1
-
-
value2
-
...
-
-
...
-
-
-
-
-#### Example
- [[1,2,3]].each do |i,j,k|
- # do something
- end
-
-
-#### Notes
- This is a single use instruction, only used to simplify how to handle a
- block that accepts 2 or more arguments. The semantics for this instruction
- change depending on if the current block invocation is from a Proc with
- lambda semantics or not.
-
-
-
- Build a new string using many substrings
-
- Remove _count_ elements from the stack and interpret each as a `String`.
- Build a new string which is all the removed elements concatenated together in
- the order they were on the stack.
-
- Push the resulting string.
-
-
-
-
- Consume the string on the stack, replacing it with a duplicate. Mutating
- operations on the original string will not affect the duplicate, and
- vice-versa.
-
-
-
-
- Pushes the current `ConstantScope` object on the stack. Many operations are
- defered to the current scope. This operation retrieves the current scope
- so methods can be called on it.
-
-
-
-
- Create a new `ConstantScope` object for the given Module on the stack.
- This scope is chained off the current scope of the method.
-
- This also sets the scope of the current `CompiledCode` to the new
- `ConstantScope`.
-
-
-
-
- Perform required occasional checks that must be done. This instruction is
- used by loops to allow them to be interrupted externally, and thus also
- cause the current method to heat up.
-
-
-
-
- Pauses virtual machine execution and yields control to the debugger on the
- debug channel. If no debugger is registered, an error is raised.
-
-
-
-
-
Before
After
-
-
-
...
...
-
-
-
-#### Notes
- _This instruction is deprecated and should not be used._
-
-
-
- Checks if the specified method serial number matches an expected value.
-
- Pops the _receiver_ object from the stack and checks if it responds to the
- message specified by the operand _literal_ and the target method has
- serial number _serial_. If so, push `true`, else push `false`.
-
-
-
-
-
Before
After
-
-
-
receiver
boolean
-
...
...
-
-
-
-#### Notes
- This opcode is typically used to determine at runtime whether an
- optimisation can be performed. At compile time, two code paths are
- generated: a slow, but guaranteed correct path, and a fast path that uses
- certain optimisations. The serial number check is then performed at
- runtime to determine which code path is executed.
-
- For example, a method such as `Fixnum#times` can be optimised at compile
- time, but we can't know until runtime whether or not the `Fixnum#times`
- method has been overridden. The serial number check is used to determine
- each time the code is executed, whether or not the standard `Fixnum#times`
- has been overridden. It leverages the serial number field on a
- `CompiledCode`, is initialised to either 0 (for kernel land methods) or
- 1 (for user land methods).
-
-
-
- Pushes the value of the specified field in the current object onto the
- stack.
-
-
-
-
-
Before
After
-
-
-
...
value
-
...
-
-
-
-#### Notes
- Fields are similar to instance variables, but have dedicated storage
- allocated. They are primarily used on core or bootstrap classes.
- This instruction should not be used directly. The VM will specialize
- push_ivar instructions into this.
-
-
-
- Evaluate if _object_ is an instance of _class_ or of an ancestor of
- _class_. If so, push `true`, else push `false`.
-
- The equivalent of `object.kind_of?(klass)` in Ruby.
-
-
-
-
- Evaluate if _object_ is an instance of _class_. If so, push `true`, else
- push `false`.
-
- The equivalent of `object.instance_of?(klass)` in Ruby.
-
-
-
-
- Implementation of `#+` optimised for `Fixnum`.
-
- Pops _value1_ and _value2_ off the stack, and pushes the _sum_ (_value1_
- `+` _value2_). If both values are Fixnums, the addition is done directly
- via the `fixnum_add` primitive. Otherwise, the `#+` method is called on
- _value1_, passing _value2_ as the argument.
-
-
-
-
- Implementation of `#-` optimised for `Fixnum`.
-
- Pops _value1_ and _value2_ off the stack, and pushes the _difference_ (_value1_
- `-` _value2_). If both values are Fixnums, the subtraction is done directly
- via the `fixnum_sub` primitive. Otherwise, the `#-` method is called on
- _value1_, passing _value2_ as the argument.
-
-
-
-
- Implementation of `#==` optimised for `Fixnum` and `Symbol`.
-
- Pops _value1_ and _value2_ off the stack and pushes the logical result
- of (_value1_ `==` _value2_). If _value1_ and _value2_ are both Fixnums or
- both Symbols, the comparison is done directly. Otherwise, the `#==` method
- is called on _value1_, passing _value2_ as the argument.
-
-
-
-
- Implementation of `#<` optimised for `Fixnum`.
-
- Pops _value1_ and _value2_ off the stack, and pushes the logical result
- of (_value1_ `<` _value2_). If _value1_ and _value2_ are both Fixnums, the
- comparison is done directly. Otherwise, the `#<` method is called on
- _value1_, passing _value2_ as the argument.
-
-
-
-
- Implementation of `#>` optimised for `Fixnum`.
-
- Pops _value1_ and _value2_ off the stack, and pushes the logical result
- of (_value1_ `>` _value2_). If _value1_ and _value2_ are both Fixnums, the
- comparison is done directly. Otherwise, the `#>` method is called on
- _value1_, passing _value2_ as the argument.
-
-
-
-
- Implementation of `#===` (triple equal) optimised for `Fixnum` and
- `Symbol`.
-
- Pops _value1_ and _value2_ off the stack, and pushes the logical result
- of (_value1_ `===` _value2_). If _value1_ and _value2_ are both Fixnums or
- both Symbols, the comparison is done directly. Otherwise, the `#===` method
- is called on _value1_, passing _value2_ as the argument.
-
-
-
-
-
Before
After
-
-
-
value1
boolean
-
value2
...
-
...
-
-
-
-#### Notes
- Exactly like equal, except calls `#===` if it can't handle it directly.
-
-
-
- Call a superclass method on the current, passing the arguments
- passed to the current invocation.
-
-
-
-
-
Before
After
-
-
-
argN
-
value
-
-
...
-
...
-
-
arg2
-
-
arg1
-
-
...
-
-
-
-
-#### Notes
- This is a specialization of `send_super_with_stack` that is necessary for
- Ruby semantics regarding how to read the original arguments.
-
-
-
-
- Push the block passed as an argument to the current invocation.
- This differs from `push_block` in that in is not the block for the
- current scope because of how the current block is seen within
- an existing block.
-
-
-
-
- Convert a value into an Array
-
- Pop _value_. If it is an `Array`, push it back on the stack. Otherwise,
- attempt to convert it to an `Array` using `#to_ary` and push the result.
- If the value can not be converted to an array, it is wrapped in a one
- element `Array`.
-
-
-
-
- Directly invoke a primitive by name.
-
- Pop _count_ values off the stack and pass them directly to the primitive
- operation named by the operand _literal_.
-
-
-
-
- Invoke a method via the call custom protocol.
-
- Pop the _receiver_ and _count_ values off the stack and begin the call
- custom invocation protocol with them as arguments.
-
-
-
-
- Pop a value off the stack and if it's not a `String`, call a method
- indicated by _literal_ on it. Push the resulting object back on the
- stack.
-
-
-
-
-
Before
After
-
-
-
object
string
-
...
...
-
-
-
-#### Notes
- Normally literal is `:to_s`, but this instruction leaves it up to the user
- to indicate for flexibility.
-
-
-{% include footer.html %}
diff --git a/_posts/2010-12-15-rubinius-has-a-blog.markdown b/_posts/2010-12-15-rubinius-has-a-blog.markdown
deleted file mode 100644
index 8033e26..0000000
--- a/_posts/2010-12-15-rubinius-has-a-blog.markdown
+++ /dev/null
@@ -1,55 +0,0 @@
----
-layout: post
-title: Rubinius Has a Blog!
-author: Brian Ford
----
-
-Many thought the day would never come, but Rubinius finally has a blog. That's
-not all, though: We have integrated the website, blog, and documentation using
-Jekyll. The source code for it all is in the main [Rubinius
-repository](http://github.com/rubinius/rubinius).
-
-People have often requested that we write more about the _awesome_ features in
-Rubinius. We hear you and we'd love to do this. However, there is always a
-trade-off between working on those awesome features and writing about them.
-Until now, it's been rather painful to write docs or blog posts because we did
-not have good infrastructure in place. Now, I think we do. I'm sure there are
-still a lot of improvements we can make, but we have a good place to start.
-I'd like to give a brief tour of our new system.
-
-The primary goal was to improve collaboration and reduce friction for writing
-new documentation and blog posts. That's right, improve collaboration. There
-are many people who have experience developing Rubinius and running their
-applications on it. We love how people have collaborated with source code
-commits. Now anyone has the ability to write a blog post as well. I've written
-a basic [How-To - Write a Blog Post](/doc/en/how-to/write-a-blog-post/)
-document. If you have an idea for a blog post, just let us know. We will
-exercise a bit of editorial control just to ensure the topics are appropriate
-for Rubinius, but generally, we are thrilled to have your contributions.
-
-Recently, we added the `rbx docs` command. This will run a web server on your
-machine and open a browser window to display the Rubinius documentation. Now
-the documentation will also be available at the [rubini.us](http://rubini.us)
-website. I have added a basic outline and a bunch of files to further simplify
-the task of writing docs. In many cases, merely open a file and start writing
-docs in [Markdown](http://daringfireball.net/projects/markdown/syntax) format.
-
-We have also begun translating our documentation to other languages. I am
-excited about this, being a huge language geek. I wish that I were proficient
-in 10 languages so I could polish our documentation for the many people who
-are not native English speakers. Alas, I only have a fair ability to write in
-Spanish, so we are again depending on your help. I started the translation
-effort by passing the existing English docs through Google translate. We have
-a beginning guide for [How-To - Translate
-Documentation](/doc/en/how-to/translate-documentation). I've been told by
-_kronos\_vano_ in our \#rubinius IRC channel that he's already working on a
-Russian translation. I personally would love to see Japanese and Chinese
-translations.
-
-So that's a brief introduction to our new infrastructure for documenting and
-explaining Rubinius. It's been such a joy to see so many people contribute to
-the Rubinius source code over the years. We hope that the blog, documentation,
-and translations will further empower people to contribute and benefit from
-the value that Rubinius has to offer the Ruby community.
-
-_¡Adelante!_
diff --git a/_posts/2011-02-17-rubinius-what-s-next.markdown b/_posts/2011-02-17-rubinius-what-s-next.markdown
deleted file mode 100644
index ccd6698..0000000
--- a/_posts/2011-02-17-rubinius-what-s-next.markdown
+++ /dev/null
@@ -1,319 +0,0 @@
----
-layout: post
-title: Rubinius, What's Next?
-author: Brian Ford
----
-
-On Tuesday, we released version 1.2.1 (see the [Release
-notes](http://rubini.us/releases/1.2.1/)). This release weighs in at 256
-commits and 21 tickets closed in the 56 calendar days since the release of
-1.2.0. Many thanks to those who contributed patches and to everyone who helped
-us test it.
-
-While we were working on 1.2.1, we were also working on a Top Secret project
-that we've craftily [hidden in plain
-sight](https://github.com/evanphx/rubinius/tree/hydra). I'd like to introduce
-the work we are doing on the hydra branch and the features you can expect to
-see in Rubinius soon.
-
-
-### Daedalus - A new build system
-
-Rubinius is a fairly complex project. It combines multiple components into a
-single system. We have worked hard to contain this complexity and from the
-beginning we insisted that building Rubinius be as simple as possible. For
-example, Rubinius can be run from the source directory, there is no need to
-install it first. Typically, building requires:
-
- ./configure
- rake
-
-The Rubinius system combines:
-
-1. External libraries written in C/C++, sometimes built with just Makefiles
- and sometimes using autotools.
-1. The virtual machine, garbage collector, and JIT compiler written in C++.
-1. The virtual machine interpreter instructions, including support code for
- the JIT, and instruction documentation all generated at build time from an
- instruction template.
-1. The core library and bytecode compiler written in Ruby.
-1. Various C extensions like the Melbourne parser, BigDecimal, Digest, and
- OpenSSL libraries. In the case of the parser, we have to build _two_
- versions, one for the bootstrapping system and one for the Rubinius system
- being built.
-
-It has not been easy to make this work and over the years we have compiled a
-list of exactly what we need in a build system. Evan, in typical form, started
-hacking out a first pass and created _daedalus_, our new build system. It
-features such exotic (and extremely useful) features as SHA-based change
-detection, parallel builds, single-process execution, and use-aware
-configuration options. Allow me to elaborate.
-
-* A typical build system decides to rebuild a file if the source is newer than
- the build artifact. This can result is unnecessarily building files that
- have been touched by some process (like updating from the source repository)
- but whose contents have not changed. By basing rebuild decisions on the SHA
- digest of the source, only files that have actually been changed need to be
- built. Since compiling C++ with optimizations is _not_ a fast process,
- eliminating unnecessary building is great for productivity, not to mention
- global warming.
-* With a multi-core system, builds can be done faster if they are done in
- parallel. If the build system can accurately determine dependencies, it can
- execute build sub-steps in parallel. Of course, this can cut into YouTube
- and Twitter browsing time, but that's a risk we are willing to take.
-* While parallel sub-processes during the build are excellent, the supervising
- process benefits from running as a single process from start to finish.
- Otherwise, configuration data needs to be re-parsed. To support a single
- build process, we need multiple, independent dependency graphs for the
- components. As noted above, we need to build two versions of the parser,
- which requires two dependency graphs _for the same component_! This is
- simply impossible in Rake.
-* Use-aware configuration values know that the user has set the value and can
- intelligently merge with newer configuration variables that we create
- without requiring the user to reconfigure. Ultimately, we are aiming for a
- _single_ command build. Just run 'daedalus' and done. There is no step 2.
-
-
-### Full-on Concurrency
-
-Nobody likes waiting in line. In fact, the more desirable a thing is, the less
-we want to stand idly waiting in a line for it, tapping our foot, twiddling
-our thumbs. The same could be said about our programs.
-
-Threads give us the ability to add concurrency to our programs. However,
-unless the hardware either has multiple CPUs or multiple cores per CPU (or
-both), the apparent concurrency will still be executing serially. Since there
-are so many multi-core CPUs around these days, our programs should be getting
-stuff done in parallel.
-
-Unfortunately, there's a twist. Even with native threads on a multi-core CPU,
-the amount of parallelism you get depends on how well you manage locks around
-shared data and resources. Sometimes managing these locks is complex and you
-opt for one big lock, essentially only allowing one thread at a time to run.
-That big lock is usually called a global interpreter lock (GIL) or global VM
-lock (GVL).
-
-The Rubinius VM originally had green (user-space) threads, but it has had
-native threads with a GIL for a while now. In the hydra branch, Evan and
-contributors like Dirkjan Bussink have been working on replacing the GIL with
-fine-grained locks so that threads truly execute in parallel. This work has
-been going very well, owing in part to the fact that so much code in Rubinius
-is actually written in Ruby. Contributors like Chuck Remes have been running
-hydra under heavy concurrency loads and Rubinius is performing well.
-
-Rubinius also has experimental support for Fibers and a built-in Actor
-library. There is more work to be done but Rubinius is quickly becoming an
-excellent platform for concurrency, with a variety of approaches available to
-the programmer. Evan has also suggested rewriting the Rubinius IO subsystem to
-enable even better APIs for concurrency, all from Ruby.
-
-
-### Performance
-
-Forget everything anyone has ever told you about Ruby being slow. There are
-two things that make Ruby, as implemented, slow: 1) inexperience; 2)
-inadequate tools. These two result in one big thing: _doing too much_. Or, as
-they say: _No code runs faster than no code_. We have been working for 4+
-years to build adequate tools in Rubinius, and there is plenty of experience
-in Smalltalk, Self, and other languages for making dynamic languages fast.
-
-Presently, Rubinius typically runs pure Ruby code almost 2 times faster than
-MRI 1.9. However, there are also cases where Rubinius is slower. These mostly
-involve core libraries that are implemented in C in MRI. There are three main
-fronts on which we are attacking performance issues: 1) improving the
-algorithms in the Ruby code that implements the core library; 2) continuing to
-tune the VM and garbage collector; and 3) improving the JIT compiler. Which
-leads me to one of the most exciting things we are working on...
-
-
-### JIT Intermediate Representation (IR)
-
-The just-in-time (JIT) compiler is the key to making Ruby fast. One of the
-biggest challenges with a dynamic language like Ruby is knowing what method is
-actually being invoked when a message is sent to an object. Consider the
-following code:
-
-{% highlight ruby linenos %}
-class A
- def m(x)
- ...
- end
-end
-
-class B
- def m(x)
- ...
- end
-end
-
-class C
- def work(obj)
- obj.m(y)
- end
-end
-{% endhighlight %}
-
-What method is being invoked by `obj.m(y)`? There is no way to definitively
-know this by looking at the source code. However, when the program is actually
-running, we can know precisely what `obj` is and precisely which method `m`
-was invoked. This is called type profiling and that is exactly what the Rubinius
-VM does. Then the JIT uses the type information to make decisions like whether
-to inline a method into another method. When methods are inlined, it gives the
-optimizer more data and more possibilities to remove redundant code. The less
-code we can run, the faster Ruby will be.
-
-Presently, the JIT compiler converts Rubinius bytecode into LLVM IR and LLVM
-handles the thorny task of generating machine code. However, Rubinius bytecode
-is designed for fast execution by the virtual machine rather than as a rich
-intermediate representation. So Evan has started work on a new JIT IR.
-
-This new IR will help us to express Ruby semantics in a way that enables many
-powerful optimizations and will ultimately allow LLVM to generate even better
-machine code. Put another way, _Rubinius loves Ruby code!_ Right down to the
-metal. There's no fighting a foreign type system or the semantics of a
-language at odds with Ruby's rosy view of the world.
-
-
-### Ruby 1.9
-
-MRI 1.9 introduced two completely different changes to Ruby. The first was a
-new implementation based on a bytecode virtual machine. While the virtual
-machine replaced the AST-walking interpreter, little else changed
-architecturally. Mostly the same core library and garbage collector code
-exists in MRI 1.9 as was in MRI 1.8. The second change introduced some new
-syntax (minor) and encodings (major). Many of the other changes, for example,
-returning Enumerator objects from methods that take blocks, have been
-back-ported to Ruby 1.8.7 and are already available in Rubinius.
-
-So, the key to supporting Ruby 1.9 in Rubinius essentially involves supporting
-the 1.9 syntax changes and encodings. We have begun implementing the parser
-changes and introduced the foundation for Encoding-aware Strings. A good
-amount of work remains to be done, but over the next month we expect that
-we will be starting to run Ruby 1.9-specific code in Rubinius.
-
-
-### Tools of Information
-
-It has been said that `printf` is the mother of all debuggers. That
-illustrates two points: 1) data is often buried in our program code; and 2) we
-should have tools (e.g. a debugger) that enables us to access the data without
-manually instrumenting our code.
-
-Presently, Rubinius has a built-in debugger, precise method profiler, memory
-analysis tool, and Agent interface that permits querying a running Rubinius
-VM--even one running on a remote machine--for a variety of information.
-
-We will be adding the ability to track the location where objects are
-allocated to assist finding object leaks or code that is creating unusually
-large numbers of objects. We are also working on a tool to graphically display
-information like number of running threads, amount of CPU usage, and amount of
-memory used while actively monitoring a VM.
-
-I am also curious about correlating this VM information with external data to
-enable play-back review. For example, I would like to monitor RubySpec runs
-and correlate which spec is running with the VM data. I imagine a simple
-monotonic reference ID provided by the VM would be useful in correlating these
-two otherwise unrelated pieces of data. The RubySpec runner would request the
-ID before running each spec and the Agent monitor would request the ID when
-gathering VM data. Later the two data sets could easily be merged.
-
-When you find yourself manually instrumenting some code, consider what data
-you are trying to get your hands on and let us know the scenario. We'll
-likely be able to build a tool that will open up new vistas into the behavior
-of your Ruby programs.
-
-
-### Windows®
-
-However one may feel about Windows as an operating system, it is undeniable
-that the vast majority of people in the world use Windows. We believe those
-people have an inalienable right to use Rubinius, too.
-
-Thanks to the wonderful, hard-working
-[MinGW-w64](http://mingw-w64.sourceforge.net/) folks, we are able to compile
-the Rubinius VM into a native Windows executable. Presently, the VM will
-compile, link, and attempt to load the Ruby core library. More
-platform-specific work is needed to load the library. The next step after that
-will be getting the RubySpecs to run and start fixing issues.
-
-Since the Windows work is being done on the hydra branch, the other features
-discussed above will be available on Windows as soon as we complete them.
-
-
-### Multi-language-ualization
-
-The Rubinius VM began as an effort to create a modern, first-class environment
-for running programs written in Ruby. However, it turns out that Ruby is a
-terrific language for writing subsystems for other programming languages.
-Actually, this should come as no surprise; Ruby is a fabulous general purpose
-programming language.
-
-To support experimenting with writing other languages that run on the Rubinius
-VM, Evan has started to put together a Language Toolkit. This includes things
-like a built-in PEG parser, convenient ways to create methods from Rubinius
-bytecode, and decoupling method dispatch from Ruby semantics.
-
-Hopefully, Evan will introduce us to all this in a future blog post, but
-here is a taste of what you can do:
-
-{% highlight ruby linenos %}
-class Hello
- dynamic_method :world do |g|
- g.push :self
- g.push_literal "Hello, world"
- g.send :puts, 1, true
- g.ret
- end
-end
-
-Hello.new.world
-{% endhighlight %}
-
-Of course, that is much more concisely written in Ruby, but combine this
-ability with a built-in PEG parser and you can be experimenting with your own
-fascinating syntax in a matter of minutes.
-
-Check out the Rubinius [Projects page](http://rubini.us/projects/) for some of
-these language experiments. One language in particular is
-[Fancy](https://github.com/bakkdoor/fancy), which is fully bootstrapped (i.e.
-the Fancy compiler is now written in Fancy) on Rubinius.
-
-
-### Documentation
-
-One the one hand, Rubinius just runs Ruby code, and you shouldn't need any
-special knowledge to run your application on Rubinius. On the other hand, as
-I've discussed above, there are some specific Rubinius features that may be
-very helpful to you. However, they can only be as helpful as the documentation
-we have for them.
-
-Before we released 1.2.0 in December last year, I spent quite a bit of time
-getting a new documentation system in place. Since then, we've had
-contributors help with translations to Russian, Polish, Spanish, and German.
-Adam Gardiner started documenting the garbage collector algorithms. Yehuda
-Katz (you may have heard the name) has contributed documentation for [the
-bytecode compiler](http://rubini.us/doc/en/bytecode-compiler/) complete with
-diagrams!. Chuck Remes wrote up a great piece on the [memory
-analysis](http://rubini.us/doc/en/tools/memory-analysis/) tool.
-
-We really appreciate these contributions. We understand the need for great
-documentation and we have been creating better support for it. In many cases,
-all that is needed is to just open a file and start writing. Of course, one
-cannot expect to understand much about Rubinius without digging into the code.
-If there is a particular part of Rubinius that you are curious about, jump in
-the #rubinius channel on freenode.net and ask us questions. We can point you
-in the right direction and help clarify things. If nothing else, let us know
-which part of the missing documentation is most important to you and we can
-start filling that in.
-
-
-### How you can help
-
-There you have it, some super exciting things coming very soon for Rubinius
-and for Ruby! We would love to have your help making Rubinius even better. The
-most important thing you can do is try running your Ruby code. Give us
-feedback. Let us know what features or tools would make your life easier. Help
-us to build them.
-
-Rubinius adopts Ruby's rosy view of the world. We want to empower you to solve
-your hardest problems with Ruby, and have fun doing it.
diff --git a/_posts/2011-02-22-rubinius-multiple-branches-with-rvm.markdown b/_posts/2011-02-22-rubinius-multiple-branches-with-rvm.markdown
deleted file mode 100644
index 434c234..0000000
--- a/_posts/2011-02-22-rubinius-multiple-branches-with-rvm.markdown
+++ /dev/null
@@ -1,83 +0,0 @@
----
-layout: post
-title: Running Multiple Rubinius Branches Simultaneously with RVM.
-author: Wayne E. Seguin
----
-
-This article is written with the assumption that you have RVM installed
-already. If you do not, follow the
-[Installation Instructions](https://rvm.beginrescueend.com/rvm/install/)
-followed by the
-[Basics](https://rvm.beginrescueend.com/rvm/basics/)
-closely first.
-
-
-### Named Ruby Installs
-
-Everyone familiar with RVM knows that it allows you to quickly and
-easily install a particular Ruby interpreter by simply running, for
-example,
-
- rvm install rbx
-
-What is not widely known (yet) is that there is a "Named Rubies" feature
-that allows you to install altered versions of the same Ruby
-installation along side the original.
-
-In the case of Rubinius there is this facinating branch called 'hydra'.
-So let us see how we can have the Rubinius master branch installed as
-the main rbx with the hydra branch installed along side as well.
-
-As above you first install rbx which is currently defaulted to -head
-version so
-
- rvm install rbx
-
-is currently equivalent to
-
- rvm install rbx-head
-
-After we have the mainline head Rubinus branch installed, we now want to
-use the named rubies feature. This is done using the -n specifier in the
-Ruby identifier string. So for example to install our hydra branch as an
-RVM ruby with the name 'hydra' in it we do the following:
-
- rvm install --branch hydra rbx-nhydra
-
-Now we can see that they can be used together! Using the Rubinius master
-environment,
-
-
- $ rvm rbx ; ruby -v
- rubinius 1.2.1 (1.8.7 6feb585f 2011-02-15 JI) [x86_64-apple-darwin10.6.0]
-
-Whereas using the Rubinius hydra environment,
-
- $ rvm rbx-nhydra ; ruby -v
- rubinius 1.3.0dev (1.8.7 6feb585f xxxx-xx-xx JI) [x86_64-apple-darwin10.6.0]
-
-We see that the next release of Rubinius (hydra branch) is indeed
-version 1.3.0 whereas the master branch is version 1.2.1.
-
-Also please note that RVM creates wrapper scripts, so you do not need to
-switch out the entire environment just to run the differen versions
-either:
-
-For Rubinius master,
-
- $ rbx-head -v
- rubinius 1.2.1 (1.8.7 6feb585f 2011-02-15 JI) [x86_64-apple-darwin10.6.0]
-
-For Rubinius hydra,
-
- $ rbx-head-nhydra -v
- rubinius 1.3.0dev (1.8.7 6feb585f xxxx-xx-xx JI) [x86_64-apple-darwin10.6.0]
-
-There is a lot more available to you than this, for more information on
-RVM capabilities please visit the [RVM
-Website](https://rvm.beginrescueend.com/) and also come talk to us in #rvm on
-irc.freenode.net during the daytime EDT.
-
-I hope that this is helpful and informative to you!
-
- ~Wayne
diff --git a/_posts/2011-02-23-introduction-to-fancy.markdown b/_posts/2011-02-23-introduction-to-fancy.markdown
deleted file mode 100644
index b96a411..0000000
--- a/_posts/2011-02-23-introduction-to-fancy.markdown
+++ /dev/null
@@ -1,216 +0,0 @@
----
-layout: post
-title: Introduction to Fancy
-author: Christopher Bertels
----
-
-Fancy is a new general-purpose programming language targetting the
-Rubinius VM.
-
-This blog post will give a short introduction to the language, what
-kind of problems it's trying to solve and why I chose Rubinius as the
-VM to run Fancy on.
-
-
-### What is Fancy? ###
-
-Fancy is a new general-purpose, dynamic, pure object-oriented
-programming language heavily inspired by Ruby, Smalltalk and Erlang
-that runs on the Rubinius VM. It's the first fully bootstrapped
-language, aside from Ruby, running on Rubinius. This means that the
-compiler that generates bytecode for Rubinius is written in Fancy
-itself.
-
-You can think of Fancy as a mix of features from the mentioned
-languages above, taking each of their strengths and improving upon
-their weaknesses.
-Fancy has a very small core and is largely based on the concept of
-message passing, just like Smalltalk. It tries to have as many
-language concepts being first-class values in the language.
-
-Just like Ruby, Fancy is a dynamic object-oriented language that
-allows changing code at runtime, everything being an expression and
-generally embracing more then one way to do things. Fancy also has all
-the literal support that Ruby has, plus literal syntax for Tuples and
-Patterns (more on that below).
-
-In contrast to Ruby and just like Smalltalk, Fancy has a very small
-amount of built-in keywords and all of the control structures are
-implemented in terms of message sends to objects using closures.
-
-The third language that served as an inspiration is Erlang, from which
-Fancy takes the idea that concurrent programming should be easy by
-having the Actor Model built into the language. This part is still a
-work in progress, but should come together soon. The fact that
-Rubinius has a built-in Channel type, inter-VM communication
-capabilities and even an actor library makes implementing this easier
-than in traditional systems.
-
-
-### Why Fancy? ###
-
-I believe there is real value in having a language that supports
-certain things out of the box. Especially when it comes to things like
-asynchronous and concurrent programming, having proper semantics built
-into the language can often help developers more than a library can.
-Very often it's not just about the functionality itself but also about
-the semantics you want that functionality to have. This can cause
-problems particularly if the language's semantics differ from what
-your library is trying to solve. A good example is the callback-based
-approach to asynchronous progamming which leads to code that differs
-both in semantics as well as how code is structured, compared to
-synchronous code. Ideally you'd still want to write code in a
-synchronous fashion, where exceptions pop up naturally while still
-being highly asynchronous.
-
-In that sense Fancy is more flexible than Ruby as there's not many
-special case semantics built in to the core language. Everything's
-done via message passing, which fits nicely the actor model approach
-to concurrency. Fancy's syntax is a lot simpler, too.
-
-Since all the core control structures are just implemented in Fancy
-itself and adhere to the message passing protocol, you can easily
-override them for your personal needs. This is especially interesting
-when implementing domain specific languages.
-Say, you'd want to add some logging to conditional or looping
-constructs - it's as easy as overriding a method in your DSL's
-classes. Fancy also has class-based mixins, so it makes it easy to
-share functionality across class hierarchy boundaries.
-
-Finally, I created Fancy because I wanted a language implementation
-that was well documented, easy to understand and very flexible to
-extend. Ruby is a nice language, but it has some inconsistencies and
-there's only so much you can do when you're bound by backwards
-compatibility. By starting fresh, Fancy has a clean, simple and easy
-to extend core which allows further exploration of features and
-abstractions.
-
-### Why target Rubinius? ###
-
-The initial implementation of Fancy was a simple interpreter written
-in C++, similar to how Ruby 1.8 (MRI) works. It was a simple AST
-walker. After moving to Rubinius and writing an initial bootstrap
-compiler in Ruby, the codebase shrank to about 20% of the original
-implementation while actually being more performant. This of course is
-mostly due to Rubinius' architecture and JIT compiler but it was a
-great experience nontheless.
-
-The nice part about having a common virtual machine and runtime is
-that you're not forced to a completely different platform to get the
-job done. Fancy and Ruby can coexist in the same application nicely
-and calling code from one another is dead simple. In fact, as of now,
-Rubinius doesn't know anything about Fancy. And it shouldn't. As long
-as all languages running on top of it adhere to the same interface
-(in this case the bytecode), it should just work fine.
-
-Choosing Rubinius as a successor platform for Fancy was easy. It's
-built for Ruby, a language that's closely related to Fancy. Rubinius,
-while having been developed as a VM for running Ruby code, is very
-flexible and there are many features that abstract over Ruby's
-external semantics. It was just a natural choice given the fact that
-Rubinius' architecture and design was heavily influenced by Smalltalk
-VMs. Also, it's a very nice dynamic bytecode virtual machine. The
-community is very responsive and helpful. Bugs get fixed instantly,
-there's always someone to help out and overall it's been a great
-experience.
-
-
-### Let's look at some code! ###
-
-OK, enough talking. Let's have a look on how to get some Fancy code up
-and running. Our little sample application will be a simple IRC bot
-that connects to Fancy's irc channel on Freenode and says hello to
-everyone that greets it. To make life easier, there's already a Fancy
-package out there that helps with exactly this task:
-[FancyIRC](https://github.com/bakkdoor/fancy_irc).
-
-FancyIRC is a simple IRC client library inspired by Ruby's IRC bot
-framework [Cinch](https://github.com/cinchrb/cinch). It's much simpler
-and the code is fairly easy to read, but it gives you a similar
-interface for writing IRC clients or bots.
-
-So let's get going by installing Fancy. You can either use the Fancy
-Rubygem and install it with Rubinius or get the code from GitHub and
-run `rake` in the directory. You'll also then have to add the `bin`
-directory to your `$PATH`. If you want the latest and greatest version
-of Fancy I recommend building directly from source, as the Gem might
-not be up to date all the time. For demonstration purposes, let's
-install the Rubygem.
-
- $ rbx -S gem install fancy
-
-To get the FancyIRC package we use Fancy's built-in package manager,
-which knows how to find the code on GitHub and install it locally:
-
- $ fancy install bakkdoor/fancy_irc
-
-#### Writing the code ####
-{% highlight fancy linenos %}
-require: "fancy_irc"
-
-greeter_bot = FancyIRC Client new: {
- configuration: {
- nickname: "greeter_bot"
- server: "irc.freenode.net"
- port: 6667
- channels: ["#fancy"]
- }
-
- # greet person back
- on: 'channel pattern: /^[hH]ello greeter_bot/ do: |msg| {
- msg reply: "Hello to you too, #{msg author}!"
- }
-
- # "echo" command
- # invoke with: !echo
- on: 'channel pattern: /^!echo (.*)$/ do: |msg, text| {
- msg reply: "#{msg author} said: #{text}"
- }
-
- # tell bot to shutdown via !shutdown command
- on: 'channel pattern: /^!shutdown/ do: |msg| {
- msg reply: "OK, shutting down"
- System exit
- }
-}
-
-greeter_bot connect
-greeter_bot run
-{% endhighlight %}
-
-I think the code is pretty straight forward. This should give you a
-feeling for what Fancy looks and feels like. There is of course lots
-more to Fancy than what was shown here. It would not fit into a single
-blog post.
-
-A quick list of what's currently being worked on:
-
-* New pattern matching system: Message passing based pattern matching
- that preserves encapsulation and is very extensible including
- pattern literals that allow custom pattern types to be defined by
- anyone. There's an experimental branch for that. I'm happy
- to answer questions.
-* Async support using coroutines (Fibers) - Write async code in a more
- natural way where exceptions propagate naturally and you don't have
- to think about callbacks all the time.
-* First-class support for actors - Asynchronous message sends, Futures
- and multi-vm messaging built-in.
-* And much more...
-
-
-### Interested? ###
-
-If you got interested in Fancy and want to know where to go next,
-here's a short list of things to check out:
-
-* [Fancy's GitHub repository](https://github.com/bakkdoor/fancy).
- The standard library is completely written in Fancy and most classes
- and methods have docstrings. It should be fairly easy to understand.
-* [Programming InFancy](https://github.com/fancy-lang/infancy)
- An open source tutorial on learning Fancy. Work in progress.
-* [http://api.fancy-lang.org](http://api.fancy-lang.org)
- A work in progress page containing Fancy's standard library class
- and method documentation.
-* [Fancy's Google Group mailinglist](https://groups.google.com/forum/#!forum/fancy-lang)
-* IRC Channel: #fancy @ irc.freenode.net
-* Website: [http://www.fancy-lang.org](http://www.fancy-lang.org)
diff --git a/_posts/2011-02-25-why-use-rubinius.markdown b/_posts/2011-02-25-why-use-rubinius.markdown
deleted file mode 100644
index 928f5cd..0000000
--- a/_posts/2011-02-25-why-use-rubinius.markdown
+++ /dev/null
@@ -1,557 +0,0 @@
----
-layout: post
-title: Why Use Rubinius
-author: Brian Ford
----
-
-_Why should I use Rubinius?_ We have been asked that question many, many times
-over the past four years. It is a great question. It is an important question.
-It's a _hard_ question. I'm not holding out on you. I want to give you an
-answer that sates your curiosity, helps you make informed decisions, and
-empowers you to speak eloquently when _you_ are inevitably asked, "Why do you
-use Rubinius?"
-
-The trouble is, there are many different situations in which people use Ruby
-and there is simply no answer, however comprehensive, that really speaks to
-everyone's concerns. So rather that boring you at length, I thought a _Choose
-your own adventure_ style would be a better approach.
-
-From the list below, select the persona that best describes you. Don't worry,
-if the one you select doesn't sound right, you can easily backtrack here. Read
-as many as interest you. After all, none of us fit easily into any one box.
-When you are done exploring all the fascinating reasons to use Rubinius, let's
-meet up at the Conclusion for some parting
-words.
-
-_Enjoy!_
-
-
-
-You are pretty new to programming and after hearing about Ruby on Rails you
-watched a screencast and made a website. You are curious and enthusiastic.
-
-You are the empty teacup of the Zen proverb. You are a fresh-faced flower
-glistening with the morning dew. The sun smiles on you and you smile back.
-You seem to like this Ruby language that makes programmers happy and you've
-come to lend your cheery spirit...
-
-Welcome!
-
-So, you have heard of this thing called Rubinius or rbx or whatever and some
-folks you respect or admire seem to like it and naturally you want to know
-what the big deal is and you're like, "Yo, why would I use Rubinius?".
-
-Cool.
-
-Well, you should use Rubinius because I said so. Try your code on it. Tell us
-what worked for you. Tell us if something didn't work by opening an
-[issue](https://github.com/rubinius/rubinius/issues/).
-Set your imagination loose and tell us what tool you would use if you could.
-
-Spend some time reading the Rubinius source code. Start at the `kernel/`
-directory. It's full of Ruby code! As you read through how Ruby is
-implemented, how it actually works, it will give you a level of understanding
-of your code that many programmers don't have in _any_ language.
-
-Most of all, hang on to your curiosity and enthusiasm. Those were vital to the
-creation of the Rubinius project in the beginning and have sustained us
-through many challenges. We _can_ make our Ruby experience better, freeing us
-from the shackles of other languages and foreign libraries. We _can_ have fast
-and reliable web servers, games, editors, websites and applications written in
-Ruby. We _can_ have first class tools written for and with Ruby. The world
-_can_ be rosy red without our glasses.
-
-Back to personas
-
-
-
-Ruby is groovy. No, not that Groovy, eww, no. I mean:
-
-
-
groovy |ˈgroōvē| adj.
-
-
-
fashionable and exciting : sporting a groovy new haircut
-
enjoyable and excellent : he played all the remarkably groovy guitar parts
-himself
-
-
-
(Apple's dashboard dictionary widget.)
-
-
-Ruby respects creativity. It has an _aesthetic_. You don't just write Ruby
-code, you write _beautiful_ Ruby code. It would be unthinkable to do
-otherwise. Sure, there is more than one way to do many things. This is not
-some sterile laboratory. We are not automatons; we are people. Of course,
-being utilitarian is not bad. But other languages have that angle pretty
-well covered. There is probably only one right way to implement Python.
-
-Rubinius has an aesthetic, too: excellence, utility, simplicity, beauty, joy.
-Mostly in that order. Useful code that isn't of very good quality is a drag.
-It slows you down. It gives you a headache. It drives you away. We strive to
-keep it out of Rubinius. On the other hand, we are not just writing sonnets
-here. This is Serious Business™. We have some hard-core problems to solve. So
-we strive for excellent, useful, beautiful code that is a joy to work with.
-
-Of course, this is an ongoing process. It is a journey, not a destination.
-There are areas of Rubinius that could use a thorough cleaning or a new
-perspective on making the implementation of this beautiful object-oriented
-language more beautiful and object-oriented.
-
-We welcome your artistic perspective. Help us improve the dialog between
-Rubinius and the person using it. The command line doesn't have to be a
-desolate place of obscure, condescending error messages. Web interfaces to the
-diagnostic tools deserve a good dose of user-experience and interaction
-design. You know that feeling you get when looking at an Enterprise web
-application? That weird plastic\-masquerading\-as\-quality\-material feeling?
-The too much 1996\-Enterprise\-faux\-rounded\-corner\-wanabe\-2006\-hip gloss?
-Gives me the willies whenever I have to use an app like that. Yeah, we don't
-want that.
-
-We want to create tools that are powerful, graceful, easy to use, and
-beautiful to look at. Beautiful tools are easier to use. (Yehuda Katz provided
-a couple links related to this: [The Impact of Design and Aesthetics on
-Usability, Credibility, and Learning in an Online Environment
-](https://www.westga.edu/~distance/ojdla/winter134/david_glore134.html) and
-[In Defense of Eye
-Candy](http://www.alistapart.com/articles/indefenseofeyecandy). If you know of
-other research, leave us a comment.) So if you have a creative bent but enjoy
-writing code also, try out Rubinius and let us know where it could use some
-polish.
-
-Back to personas
-
-
-
-That saying, _Time is Money_, you live by it. You have applications to deliver
-and you choose the best tool for the job. You are professional, conscientious,
-duly cautious, and not inclined to episodes of emotional exuberance about the
-latest fad. You accept compromises. There are always trade-offs. The correct
-approach is cost-benefit analysis. The numbers tell the story and level-headed
-decision making follows the numbers.
-
-You have heard about Rubinius and you are curious whether it may be
-appropriate for your current project. As usual, rather than speculating or
-paying too much heed to the buzz, you look into it yourself. After some
-investigation, you discover that:
-
-1. Much of Rubinius is implemented in Ruby itself. This may be a big help when
- tracking down troublesome bugs.
-1. Rubinius has a very fast bytecode virtual machine, as well as a modern
- generational garbage collector so memory profiles should be more
- predictable and consistent in deployed applications.
-1. It has a profile-driven JIT compiler that uses type-feedback to
- aggressively inline methods resulting in significant performance
- improvements.
-1. It has a built-in debugger and precise method profiler, both of which are
- fast due to being well integrated.
-1. It has a built-in API for monitoring a VM out-of-process, even on a remote
- machine. We are building a variety of diagnostic tools atop this API.
-
-Of course, even if the technology in Rubinius sounds terrific in theory, how
-suitable is Rubinius for your application? How does it perform under your
-specific constraints? Again, you do some investigating. You have a solid test
-suite for your application, so you start by running that. If you hit any
-problems, please open an [issue](https://github.com/rubinius/rubinius/issues/)
-to let us know.
-
-If everything goes well with the tests, you start running some of the
-benchmarks that you have accumulated while doing performance tuning. Of
-course, no sensible person asks for benchmark results from _other_ people's
-code. That defies logic. It's like asking if your program will run because
-your Aunt Mabeline likes decaf coffee. It's contrary to the very point of
-benchmarking, where you are trying to correlate two values that are connected.
-
-Again, if you note an significant issues, please let us know. Sometimes
-Rubinius exposes issues in existing code. Performance characteristics of real
-applications are vital to making Rubinius faster. Also, if you have
-suggestions for tools you would like to use, tell us. If you just want to
-chat about the technology, that's fine, too. We're hanging out in the
-#rubinius channel on freenode.net.
-
-Back to personas
-
-
-
-Well, I am being kind by saying _seasoned_. You know when you look in the
-mirror that _jaded_ and _cynical_ are much more apt. You've seen it all and it
-has worn you down. You've been fighting the good fight, carefully guarding
-that last flicker of optimism that burns in the secret place deep in your
-heart. You've programmed Java/.NET/C++ professionally. You've even sucked it
-up and written some PHP and Python when asked; you are a professional, they
-ask and you deliver. You've seen attacked servers on fire off the shoulder of
-Rackspace...
-
-Rubinius has a lot to offer you. Remember that little flicker of optimism? It
-is only the idealists that get ground down by the complete indifference to
-pursuit of an ideal in so much of the world. Deep down, you are an idealist
-and you will find plenty to refresh you here.
-
-Rubinius aims to be the best possible implementation of Ruby by putting Ruby
-itself front and center. We are using modern technology and always improving.
-We change when there is a better way to do things. We judiciously rewrite and
-are not too attached to any code or algorithm. The legacy Enterprise isn't on
-the steering committee. Our work will be done when you can use Ruby, just
-Ruby, to solve your thorny problems.
-
-Sure, that sounds idealistic. But never mind the pessimists that tell you that
-you have to compromise. If you are not idealistic, you will not be unsatisfied
-with things that are not as good as they could be; you will not try to change
-the world. So give Rubinius a try, you may be surprised. And if you are, put
-all that hard-earned wisdom you have gained to use for the betterment of Ruby.
-
-Back to personas
-
-
-
-Forgive me for staring, I know it is impolite. I'm just... intrigued. Of
-course, you know Ruby is a late bound language, every message sent could
-conceivably fail to find a target, potentially resulting in an uncaught
-exception and program termination. There's shared state, wild orgies of
-mutation that disallow any reasonable attempt at automated parallelization.
-Program proof is as oxymoronic a concept as military intelligence. It's a very
-messy affair of programming and meta-programming and meta-meta-programming,
-which, for the love of Lisp, could be done so simply with macros. There's all
-this eager evaluation and complete disregard for purity. Despite vast odds,
-somehow programs are written that actually run. You have noted all this with
-great objectivity but you are nonetheless interested.
-
-Excellent, we are pleased. We have much to learn and welcome the opportunity
-for lively discussions about bringing formal methods to bear on the problems
-of making Ruby as fast as possible.
-
-Java benefited tremendously from the amount of attention it received by
-academic researchers. Ruby can benefit from some of this research as well, not
-to mention the research into Smalltalk and Self that preceded it. But Ruby has
-its own set of problems to solve and deserves specific attention. The problems
-are hard but not insurmountable. Rubinius is already demonstrating that. The
-suggestion that we need to add more keywords, restrict Ruby dynamism, or write
-`public static final int` all over are simply nonsense.
-
-Rubinius already leverages research for fast virtual machines, garbage
-collection (e.g. the generational approach and the Immix _mark\-region_
-algorithm), and JIT compilers (based on pioneering research done in Self and
-used in the JVM Hotspot VM). Rubinius uses the exceptional
-[LLVM](http://llvm.org) project for optimization and code generation in the
-JIT compiler. We are also working on better infrastructure for the JIT to
-address Ruby complexities head-on.
-
-Rubinius would be excellent to use in teaching. A compiler construction class
-could study the architecture of the bytecode compiler written in Ruby and
-experiment with exploratory changes to the compiler using IRB without having
-to recompile anything! A 30-minute introduction to Rubinius could proceed
-immediately to simple AST generation and have students experimenting with
-their own syntax immediately. While it is easy to get started, there is plenty
-of depth for exploring complex topics in virtual-machine construction and
-garbage collection.
-
-Whether you are interested in language research or language pedagogy, Rubinius
-is an great project to consider. We look forward to hearing from you.
-
-Back to personas
-
-
-
-You learned the untyped lambda calculus sitting on your mother's knee while
-she worked on her doctorate in computer science. You were substituting terms
-before you even uttered the word, "dada". You wrote three different Lisp
-implementations in Commodore Basic before you were seven. You can write
-multi-threaded web servers in one pass with no tests and never hit a deadlock
-or critical data race. You write parsers and compilers for odd languages on a
-Friday night for the heck of it while waiting for the pizza to arrive before a
-night out at the karaoke bar where you give an inspiring performance of Laga
-Gaga's _Poker Face_.
-
-(_Loooong pause_. You're not reading this. You've already written one or a few
-languages on Rubinius and posted them to our
-[Projects](http://rubini.us/projects/) page. But anyway, I'll continue...)
-
-You are the Luke Skywalker of Ruby; Yoda has nothing more to teach you. Only
-your fate confronts you now. Use the Source Luke and save the Federation of
-Ruby loyalists from the Evil Oracle and its Java the Hurt.
-
-There are a number of domains in which Ruby could benefit tremendously from
-excellent libraries:
-
-1. **Servers and web servers**: the web is here to stay but the argument that all
- applications are going to be in Javascript on the client is not valid. A variety
- of hybrid client-server architectures will continue to be the norm. We need
- software that enables application authors to build a suitable solution to
- their particular problems rather than trying to stuff their apps into
- someone else's solution with layers of wrapping.
-1. **Concurrency**: multi-core is here to stay but it is not only functional
- programming that is suitable for high-concurrency applications.
-1. **Graphical user interface**: the web browser is also here to stay but it is
- not the last word in applications. There are many cases where GUI apps are
- the best option and Ruby needs a mature library or set of libraries to
- build these apps on any major platform. I know some of these libraries
- exist, but they seem to be collecting dust lately.
-1. **Big data and data analysis libraries**: our industry repeatedly witnesses
- the same pattern: domain X starts with huge applications running on huge
- horsepower servers for huge businesses and then it starts appearing in small
- applications on small computers for small businesses. Accounting and
- geographic information systems (GIS) are two examples. Data analysis is
- coming to a laptop near you.
-
-These are general areas in which Ruby can be an excellent solution. So how
-does Rubinius fit in? Rubinius is dedicatedly pushing more and more into Ruby
-itself. Each of these domain is typically handled in Ruby right now by going
-to find a library in a foreign language to wrap in a fuzzy Ruby embrace.
-Rubinius is calling on the über-programmers of the world to implement
-solutions in Ruby to help us identify performance challenges and address them.
-
-Rubinius is also being used in some fascinating language experiments. Two of
-these are Atomo ([http://atomo-lang.org](http://atomo-lang.org) which is
-implemented in Haskell, with a Rubinius implementation code-named
-[quanto](https://github.com/vito/quanto/)) and Fancy
-([http://fancy-lang.org](http://fancy-lang.org)). So, if language design is
-your cup of tea, Rubinius offers an excellent platform for experimentation.
-
-Back to personas
-
-
-
-Like your persona description, you tend to be long winded. You find most
-descriptions too brief, almost dismissive. There are words and words should be
-used to delve into the minutiae of minutiae. You, more than anyone, want to
-know "Why?" with every fiber of your being. You will continue asking long
-after the supply of hallucinogens has been exhausted and everyone else is
-drooling in their sleep.
-
-For you, Rubinius is an existential dilemma crying out for justification. If
-we already have MRI, why build Rubinius?
-
-It would be accurate to say that Rubinius has a philosophy. That philosophy is
-simply this: _Ruby should be a first class language_. What does that mean?
-Simply that it should be possible to solve problems writing Ruby code.
-
-Let's consider libraries: Being first class means not having to wrap a Java
-library or build a C extension. If wrapping the library were the end of the
-story, it wouldn't be so bad. But that is _never_ the case. Libraries have
-bugs, weird APIs, incompatibility with other libraries, threading issues, and
-disappearing maintainers. They may even be incompatible with newer versions of
-the language in which they are written.
-
-This list goes on. To address any one of these issues requires delving into a
-different language with weird and incompatible semantics. If the library is
-your core competency, that's not such a big deal. But I will wager that it is
-not, which is why you are using the library in the first place. Also, the
-language in which you are wrapping the library (Ruby here) is not likely the
-core competency of the library author, or you probably wouldn't need to be
-wrapping it. So Ruby wrapping one of these libraries will always be a
-second-class citizen. Decisions will be made about the library's API that do
-not give one thought to the Ruby programs using it. Furthermore, the code
-written in that foreign language does nothing to support the ecosystem of
-Ruby. The knowledge gained in writing the library and the improved skills of
-the library author do not benefit Ruby. Ruby deserves better.
-
-Ruby has gotten a big boost recently with the production release of MRI 1.9.2.
-There are significant speed improvements and welcomed additions to the core
-libraries, like powerful handling of String encodings. At the same time, the
-Complex and Rational libraries were added to the core library and rewritten
-from Ruby to C code. This is disappointing. We should be able to solve these
-problems more effectively in Ruby itself.
-
-The philosophy of Rubinius is to make Ruby a first-class citizen. Ruby plays
-second fiddle to no one. There is no other language whose history, semantics,
-or vested interests compete with Ruby's. It is true that there are difficult
-problems to solve in making Ruby fast. But much of the technology already
-exists and we will build what does not. Evan often quips that if we can get
-Rubinius caught up to the dynamic language technology of ten years ago, Ruby
-will be light-years ahead. That may be overstating how far behind Ruby is,
-but it illustrates the focus of Rubinius.
-
-There's the saying, _In theory, there is no difference between theory and
-practice. In practice, there is_. In Rubinius, theory and practice are
-merging. We are motivated by the desire for Ruby to be a first-class language.
-But we are also showing real progress in making that a reality. The Rubinius
-VM executes Ruby code blazingly fast. The JIT compiler, while still being
-quite young, is showing great promise. Compatibility with MRI is quite good
-and speed is constantly improving.
-
-Is the Rubinius philosophy valid? We think the proof is in the pudding.
-
-Back to personas
-
-
-
-No, it did not cross my mind to describe this persona as Pointy-haired Boss.
-Not only would that be unfair to Dilbert, but that persona would be reading an
-article on Web Scale. No, you are someone who has fought hard battles in the
-trenches and learned valuable lessons: it's about execution and execution
-depends on good technology.
-
-Rubinius is building solid technology. We started the RubySpec project and
-have contributed tens of thousands of lines of code to it. With the support of
-Rubyspec, in just over four years as a public project, we have basically
-caught up with MRI 1.8.7 in compatibility and performance. For some code, our
-performance is much better, for other code, it is not as good. However,
-Rubinius is built on solid, modern technology and the project's trajectory and
-velocity are outstanding.
-
-Rubinius is a completely new implementation of core Ruby. Rubinius did not
-start as a port of existing code. Furthermore, Rubinius implements its own
-virtual machine and garbage collector in C++. The bytecode compiler that
-targets the virtual machine is pure Ruby. The core Ruby library is mostly Ruby
-with some primitive operations in C++. The JIT compiler uses the
-[LLVM](http://llvm.org) project. Given the amount of work being done in the
-project, Rubinius is pacing extremely well relative to other implementations.
-
-Currently, we are working on support for Ruby 1.9 features, Windows support,
-and full concurrency with no global interpreter lock (GIL).
-
-If you are looking at Ruby to implement your next project, rest assured that
-Ruby will have the support of excellent technology. If you are already using
-Ruby, consider investigating how your application runs on Rubinius. We welcome
-the feedback and look forward to solving challenging engineering problems.
-
-Back to personas
-
-
-
-You thirst for Knowledge. You follow it wherever it leads you. You'll happily
-walk Haskell's hallowed halls of pure laziness or sit at the feet of the
-meta-program gazing raptly at class transmorgrification. You don't judge. You
-have more than enough knowledge to be dangerous, enough to know that the
-universe is amoral and knowledge is the only Truth there is. Nor does any mere
-mortal language bind you. All languages are finite. You'll be here today and
-gone tomorrow; there is no permanence for the knowledge seeker.
-
-Rubinius is merely a step along the path you journey. Take what you want, it
-is all free. As a Ruby implementation, it has much to offer your quest for
-knowledge. The Ruby code in the core library is accessible and easy to follow.
-The interface between Ruby and the C++ primitives is consistent. The C++ code
-itself is restrained. You won't need a PhD in Turing-complete template
-languages to understand it.
-
-Rubinius offers extensive opportunities to learn about programming languages
-in general and Ruby in particular. When I first started working with Rubinius,
-I knew a little bit about garbage collection and virtual machines. I would
-call what I knew, toy knowledge. As I struggled to learn more, it seemed
-helpful to consider layers of understanding:
-
-1. **General programming language semantics**: the procedure abstraction,
- looping and iteration, recursion, references and values, etc.
-1. **Ruby semantics**: modules and classes, access restrictions, blocks and
- lambdas, etc. Even with fundamental programming knowledge, a particular
- language can be confusing. When I was learning C, a friend was also
- studying it. One day he walked over and threw _The C Programming Language_
- book down on my desk and said, "This `for` loop makes no sense!" He was
- quite upset. "Look," he said, "in this example `for (i=0; i < n; i++)` how
- can `i < n` get executed _after_ the code in the body?!" It's easy to laugh
- at that confusion, but coming from BASIC, that really threw him. Deepening
- our understanding to this second level requires confronting some
- "counter-intuitive" notions.
-1. **Hypothetical implementation**: knowing how Ruby works, how might one
- implement it. I think this is an important layer of understanding and it is
- easy to miss or gloss over it. By pausing at this layer and thinking how
- you might implement something, you test whether or not you are really
- understanding it.
-1. **The MRI implementation**: Reading the MRI source code is an excellent way
- to investigate Ruby. For one thing, it will inform you how Ruby _actually_
- works, and you may be surprised.
-1. **The Rubinius implementation**: here you are exposed to the philosophy of
- Rubinius and the challenges to implementing Ruby. We are attempting to
- bring the beauty of Ruby as an object-oriented language deep into the core
- of Ruby itself.
-
-While the Rubinius code itself offers many opportunities for learning, don't
-hesitate to drop by the #rubinius channel on freenode.net and ask us
-questions. Perhaps you already know a lot about another language and are
-interested in how Rubinius implements some feature. Or you may be relatively
-new to programming languages and have some basic questions. We enjoy talking
-about these concepts. If you are quite new to Rubinius, you may find these
-posts informative:
-
-* [Making Ruby Fast: The Rubinius JIT](http://www.engineyard.com/blog/2010/making-ruby-fast-the-rubinius-jit/)
-* [Improving the Rubinius Bytecode Compiler](http://www.engineyard.com/blog/2009/improving-the-rubinius-bytecode-compiler/)
-* [Compiling Ruby: From Text to Bytecode](http://www.engineyard.com/blog/2009/the-anatomy-of-a-ruby-jit-compile/)
-
-Finally, consider helping other knowledge seekers by writing blog posts on
-what you learn about Rubinius. Or, help us [write documentation](http://rubini.us/doc/en/how-to/write-documentation/)!
-
-Back to personas
-
-
-
-You like languages for their intrinsic value. Of course the world comes in
-many shapes and sizes. You wouldn't have it any other way. That's the fun and
-spice, joie de vivre, raison d'etre, supermarché... Sometimes you get carried
-away writing a program in another language just because you like how the
-letters arrange down the screen. Ruby is definitely one of the impressive
-languages and sometimes you almost notice a tiny bit of favoritism in your
-normally egalitarian attitude.
-
-As with any enthusiast, you like to experiment. Your interest is not mere
-curiosity or sterile investigation. You want to get your feet wet and your
-hands dirty. Rubinius is an excellent opportunity to delve into a number of
-fascinating subjects. We can merely suggest a path; your experiences along the
-way will tell you whether or not Rubinius has value to you.
-
-If you are most interested in languages themselves, the syntax and arrangement
-of features, Rubinius offers you immediate gratification. Look for Evan's
-upcoming post on his Language Toolkit or check out the code to
-[prattle](https://github.com/evanphx/prattle), a Smalltalk dialect used to
-illustrate the ease of building a language on Rubinius. Also look at some of
-the existing languages [projects](http://rubini.us/projects/) targeting
-Rubinius.
-
-If it is the machinery under the covers that is more interesting, start
-reading some code. The bytecode compiler lives in `lib/compiler/`. The virtual
-machine is in `vm/`, and the garbage collector is in `vm/gc`. As you are
-reading through, consider helping us write better documentation. There are
-already sections for the [virtual
-machine](http://rubini.us/doc/en/virtual-machine/),
-[garbage-collector](http://rubini.us/doc/en/garbage-collector/), [JIT
-compiler](http://rubini.us/doc/en/jit/) and [bytecode
-compiler](http://rubini.us/doc/en/bytecode-compiler/) in the documentation, so
-adding content is easy.
-
-You may also be interested in these previous posts about Rubinius:
-
-* [Rubinius wants to help YOU make Ruby better](http://www.engineyard.com/blog/2010/rubinius-wants-to-help-you-make-ruby-better/)
-* [5 Things You'll Love About Rubinius](http://www.engineyard.com/blog/2009/5-things-youll-love-about-rubinius/)
-* [Rubinius: The Book Tour](http://www.engineyard.com/blog/2009/rubinius-the-book-tour/)
-
-Most of all, experiment. Rubinius is easy to hack on. Are you curious about a
-particular feature needed in your language? Try adding it to Rubinius. Think
-Lua is all the rage because it uses a register VM? You could probably write a
-register-based bytecode interpreter for Rubinius in an afternoon. That's just
-an example, of course. The point is to play around with your ideas and have
-fun doing it. I think you'll find Rubinius to be an adventuresome companion.
-
-Be sure to let us know what you're working on. We like to be inspired, too!
-Consider writing a blog post about things that you find interesing, like this
-[recent post](http://yehudakatz.com/2011/02/18/getting-comfortable-with-rubinius-pure-ruby-internals/) by Yehuda Katz.
-
-Back to personas
-
-
-
-So there you have it. Just like there are many different viewpoints, there are
-many different reasons to use Rubinius. Not all those reasons make sense to
-everyone. We believe, however, that Rubinius has something to offer to just
-about everyone interested in Ruby. Most importantly, try it!
-
-If we didn't answer your question here, leave us a comment. If you have a
-reason for using Rubinius that we didn't mention, let us know. As always, we
-appreciate your feedback. Chat with us in the #rubinius channel on
-freenode.net, [watch our Github project](https://github.com/rubinius/rubinius),
-and [follow us on Twitter](http://twitter.com/rubinius).
-
-P.S. Thanks to David Waite for suggesting the Academic Researcher and Language
-Enthusiast personas, I always forget those!
diff --git a/_posts/2011-03-11-making-rubinius-rbc-files-disappear.markdown b/_posts/2011-03-11-making-rubinius-rbc-files-disappear.markdown
deleted file mode 100644
index b385461..0000000
--- a/_posts/2011-03-11-making-rubinius-rbc-files-disappear.markdown
+++ /dev/null
@@ -1,192 +0,0 @@
----
-layout: post
-title: Making Rubinius .rbc Files Disappear
-author: Brian Ford
----
-
-Rubinius is rather unusual as a Ruby implementation. It both compiles Ruby
-source code to bytecode _and_ saves the compiled code to a cache so it does
-not need to recompile unless the source code changes. This can be great for
-utilities that are run often from the command line (including IRB). Rubinius
-merely reloads the cached file and runs the bytecode directly rather than
-needing to parse and compile the file. Sounds like a real win!
-
-Unfortunately, it is not that simple. We need some place to store that cache
-and this is where the thorns on that pretty rose start poking us in the
-thumbs. The solution we have been using since forever is to store the cached
-file alongside the source file in the same directory, like so:
-
- $ echo 'puts "hello!"' > hello.rb
- $ ls hello.*
- hello.rb
- $ rbx hello.rb
- hello!
- $ ls hello.*
- hello.rb hello.rbc
-
-That doesn't look too crazy, but it can get more complicated:
-
- $ mv hello.rb hello
- $ rbx hello
- $ ls hello.*
- hello.compiled.rbc hello.rbc
-
-Whoa, what is `hello.compiled.rbc`? Since `hello` did not have an extension,
-we add that longer `compiled.rbc` to make it clear which file the cache is
-for. Also, note that we have that `hello.rbc` hanging about even though the
-original `hello.rb` is gone.
-
-To summarize the issues with our caching scheme:
-
-1. It requires an additional file for every Ruby source file.
-1. It requires some potentially complicated naming scheme to associate the
- cache file with the source and not clash with other names.
-1. Removing or renaming the Ruby source file leaves the cache file behind.
-
-Again, the advantage of the cache file is that you do not have to wait for
-Rubinius to recompile the file if you have not changed the source. Let's see
-if we can get all the advantages with none of the disadvantages. That old
-saying comes to mind, _Having your cake and eating it, too_, so we may not
-be successful, but it is worth a shot.
-
-First, let's take a step back. This issue is not unique to Rubinius. Python
-has `.pyc` and `.pyo` files. Java has `.class` files. C/C++ has `.o` files.
-Lots of things need a place to store a compiled or cached representation of
-some data. Every SCM worth mention has some mechanism to ignore the files you
-don't want to track. The same is generally true of editors. So in some sense,
-this is a solved problem. However, we have always received complaints about
-the `.rbc` files, so we thought we would try to make other, hopefully better,
-solutions available.
-
-### Solution 1: No Cache
-
-One simple solution is just to never ever ever create the compiled cache files
-in any form anywhere. We have an option for that:
-
- $ ls hello.*
- hello.rb
- $ rbx -Xcompiler.no_rbc hello.rb
- hello!
- $ ls hello.*
- hello.rb
-
-Win! Not one lousy `.rbc` file in sight. Although, that's quite the option to
-type. Never fear, we have a solution to that below.
-
-Here is our scorecard for solution 1:
-
-**Use Case:** Use when you never want any compiler cache files created. For
-example, on a server where startup time is not really a concern.
-
-**Pros:** No `.rbc` files at all.
-
-**Cons:** Startup will be slightly slower depending on what Ruby code you are
-running. It will be more noticeable in a Rails application, for example.
-However, the Rubinius bytecode compiler is several times faster than it was a
-couple years ago so it may not be an issue for you.
-
-### Solution 2: Cache Database
-
-What if we could put all the compilation data in a single cache location,
-something like a database? We have an option for that.
-
-This option is a little more complex, so let's take it in two steps.
-
- $ ls hello.*
- hello.rb
- $ rbx -Xrbc.db hello.rb
- hello!
- $ ls hello.*
- hello.rb
- $ ls -R .rbx
- 60
-
- .rbx/60:
- 60c091c3ed34c1b93ffbb33d82d810772902d3f9
-
-Success! No `.rbc` files here. But what's with all the numbers in the `.rbx`
-directory and how did that directory get there?
-
-The `-Xrbc.db` option without any argument will store the compilation cache in
-the `.rbx` directory in the current working directory. The cache files
-themselves are split into subdirectories to avoid creating too many entries
-for the file system to handle in one directory.
-
-What if you have a special location where you would prefer all compilation
-cache files be saved? No problem, just give `-Xrbc.db` a path as follows:
-
- $ ls hello.*
- hello.rb
- $ rbx -Xrbc.db=$HOME/.my_special_place hello.rb
- hello!
- $ ls hello.*
- hello.rb
- $ ls -R $HOME/.my_special_place
- 60
-
- /Users/brian/.my_special_place/60:
- 60c091c3ed34c1b93ffbb33d82d810772902d3f9
-
-If you primarily work with projects, putting the `.rbx` directory in the
-current working directory may be the best solution because it keeps the
-compilation cache with the project. It is easy to add an SCM ignore for the
-directory and easy to remove the directory to clear the cache (e.g. in a clean
-task).
-
-However, if you are frequently running scripts in many directories, you may
-not want to litter `.rbx` directories everywhere. In this case, putting the
-directory in your `$HOME` dir or `/tmp` may be preferable. Additionally,
-`/tmp` may be cleared on every reboot so you will not accumulate many stale
-cache files.
-
-Note that, right now, Rubinius does not clear the cache directory. It will
-happily continue adding to it indefinitely. However, this may not be an issue
-unless you are cycling through a bunch of Ruby files, for example, working on
-a number of Ruby projects in series. In that case, using a per-project (per
-current working directory) cache is probably the best option.
-
-Here is how solution 2 shakes out:
-
-**Use Case:** You want to combine all compilation cache files in one location.
-
-**Pros:** No `.rbc` files mixed in with the rest of your files.
-
-**Cons:** You may still need a per-project or per-working-directory cache
-directory. However, you can easily specify where to put that directory.
-
-### Using RBXOPT for Options
-
-As mentioned above, the `-X` options can get a little long and you certainly
-don't want to retype them constantly. We have added support for the `RBXOPT`
-environment variable, which is an analog of the `RUBYOPT` environment variable
-that we already support.
-
-Use `RBXOPT` to specify `-X` options that Rubinius should use. For example:
-
- export RBXOPT=-Xrbc.db=/path/to/dir
-
-You can check out all the `-X` options with `rbx -Xconfig.print` or `rbx
--Xconfig.print=2` for more verbose output. If you want to use multiple `-X`
-options in `RBXOPT`, use quotes and separate the options with a space:
-
- export RBXOPT='-Xrbc.db -Xagent.start'
-
-### Conclusion
-
-Rubinius saves a compilation cache for compiled Ruby code to avoid wasting
-time and resources recompiling source that has not changed. However, we need
-some place to store the cache. Rubinius provides options for omitting the
-cache altogether or for storing it in a directory of your choosing. Note that
-the format of the compilation cache is an implementation detail and we reserve
-the right to change it at any time, so please don't rely on it being in any
-particular format.
-
-We have not turned on `-Xrbc.db` by default yet because we don't know what a
-good default is. So give us feedback on your use cases and what you would find
-most useful.
-
-Finally, whenever we discuss the compilation cache we are inevitably asked if
-you can run directly from the cache and not use the Ruby source at all after
-it has been compiled. The short answer is "Yes", the long answer is "It
-depends". I will be writing a post exploring this question in detail shortly.
-For now, get out there and write more Ruby code!
diff --git a/_posts/2011-03-17-running-ruby-with-no-ruby.markdown b/_posts/2011-03-17-running-ruby-with-no-ruby.markdown
deleted file mode 100644
index bbd028f..0000000
--- a/_posts/2011-03-17-running-ruby-with-no-ruby.markdown
+++ /dev/null
@@ -1,223 +0,0 @@
----
-layout: post
-title: Running Ruby With No Ruby
-author: Brian Ford
----
-
-Humans have come a long way since our cave-dwelling days. No, that's not a
-metaphor for primitive software. I mean literally since we lived in caves. One
-of the big inventions is the lock. There are birds that bury food and will
-move it later if they notice they were watched burying it. But they have no
-access control. Any bird may come along and dig up the food.
-
-Humans, though, are smarter than the average bird.
-
-We have numerous systems that implement the analog of a lock, namely, some
-sort of access control. For every one of these systems, we have other systems
-that attempt to circumvent or defeat the access control. Two sides of the
-ubiquitous coin of life.
-
-In software, attempts to implement access control typically involve
-distinguishing between source code and some form of executable code. Direct
-access to the source code is not permitted. Further, the format of the
-executable code resists attempts to derive the source code. There are several
-reasons for this:
-
-1. **Licenses:** If a vendor licenses individual copies of the software, they
- want to prevent unrestricted copying of the software without paying for a
- license.
-1. **Intellectual Property:** A vendor may have trade secrets or other
- proprietary information that is disclosed by the source code.
-1. **Security:** Full access to the source code may reveal vulnerabilities in
- the software or related systems. This is sometimes called _Security Through
- Obscurity_ and is generally disparaged, but things are not so black and
- white and there may be valid security concerns in the source code.
-
-The process that separates the source code from the executable program is
-typically a compilation step. However, Ruby code is not typically associated
-with any sort of compilation. That's one of the great things about Ruby,
-right? There is no _edit-compile-link-load_ cycle to wait on. Just edit and run. But
-if there is no compilation step, how do we separate the source code from the
-executable code?
-
-You may recall from my [last
-post](http://rubini.us/2011/03/11/making-rubinius-rbc-files-disappear/) that
-Rubinius does compile Ruby code to a bytecode format that the virtual machine
-executes. I also promised to explain how you could run the bytecode directly.
-
-But first, let me very clearly state that there are a number of caveats. In
-fact, I've included a whole section on them below. Please read them. We will
-assume that you have and that you understand them. If you have any questions,
-please ask.
-
-
-### Application Distribution Scenario
-
-Let's review what we would like to accomplish. We'll assume affable Abe is a
-developer writing an application for customer Cain.
-
-1. Abe writes some Ruby code.
-1. Abe compiles the code to a set of files.
-1. Abe packages the files up into an application with no Ruby source.
-1. Abe sends the application to Cain.
-1. Cain installs the application.
-1. Cain runs the application.
-
-In this scenario, I'm assuming a very vague definition of application. In
-other words, the process below will fit in with a broad spectrum of bundling
-and distribution schemes.
-
-
-### Application Layout
-
-Let's assume that you have the following application layout. This mirrors what
-you would expect to see in a gem. You could also consider this as a subtree in
-your larger project.
-
- widget
- |- lib
- |- widget.rb
- \- widget
- |- red.rb
- |- blue.rb
- \- green.rb
-
-{% highlight ruby linenos %}
-# widget.rb
-require 'widget/red'
-require 'widget/blue'
-require 'widget/green'
-{% endhighlight %}
-
-{% highlight ruby linenos %}
-# widget/red.rb
-puts "I am red"
-{% endhighlight %}
-
-{% highlight ruby linenos %}
-# widget/blue.rb
-puts "I am blue"
-{% endhighlight %}
-
-{% highlight ruby linenos %}
-# widget/green.rb
-puts "I am green"
-{% endhighlight %}
-
-
-### Compiling Ruby Files
-
-The Rubinius bytecode compiler is accessible through a command-line script.
-See `rbx compile -h` for all options. We will only need one simple option in
-our case to easily create a separate tree containing one compiled file for
-every Ruby source file in our source tree.
-
- rbx compile -s '^widget:widget-compiled' widget/
-
-Let's dissect this command. The `-s` option defines a transformation to apply
-to every filename. The transformation has the form `:`
-where `` can be a Regexp. In our case, we would like to change any
-path starting with `widget` to start with `widget-compiled`. This way, we
-create a separate tree of our compiled files. The final option is the
-`widget/` directory. The `rbx compile` command will happily compile a single
-file or a directory of files. Note that if we did not pass the `-s` option,
-`rbx compile` would have created the compiled files alongside the source
-files.
-
-If we now look at `widget-compiled`, we should see the following:
-
- widget-compiled
- |- lib
- |- widget.rbc
- \- widget
- |- red.rbc
- |- blue.rbc
- \- green.rbc
-
-
-### Loading Pre-compiled Files
-
-Now that we have a separate tree of only compiled files, how do we load them?
-Well, first, let's load our source files so we know what to expect. Note that
-the technique used in this post should not substitute for a robust test suite.
-
- $ rbx -Iwidget/lib -e "require 'widget/lib/widget'"
- I am red
- I am blue
- I am green
-
-Ok, that is what I would expect. Now, to load the compiled files:
-
- $ rbx -Iwidget-compiled/lib -e "Rubinius::CodeLoader.require_compiled 'widget/lib/widget'"
- I am red
- I am blue
- I am green
-
-_The crowed erupts with applause and hooting_.
-
-Golly gee, you guys... _Blush_
-
-Let's review. Our goal is to take a tree of Ruby source files and create a
-tree of compiled files that can be sent to a customer and loaded to perform
-exactly as the Ruby source would if loaded directly. The most direct and
-simple way to accomplish this is to use the Rubinius compiler command-line
-script to compile the tree of Ruby source files to a separate tree. Then, load
-the root of that tree with `Rubinius::CodeLoader.require_compiled "root"`.
-
-
-### Caveats
-
-I will admit, I have resisted fiercely against encouraging or even permitting
-Rubinius users from using what I showed above in their code. Not because I am
-an ogre who is trying to steal your fun, but because there are serious issues
-with allowing this. So, please read the following carefully.
-
-1. We, Rubinius, absolutely reserve the right to change any part of the
- underlying compiled file mechanism. Since we are publishing the
- `Rubinius::CodeLoader.require_compiled(name)` method, we will respect that
- contract. What it says is, given a name, we will load a representation of
- that name. _DO NOT assume that `"some_file"` is actually referencing
- `"some_file.rbc"`_. We may change the way compiled files are stored and may
- change the format of the compiled output.
-1. We have created this facility to meet a need we had in Rubinius. Since our
- compiler is written in Ruby, we have to run Ruby to run the compiler. But
- since we need to compile Ruby to run it, we need to compile the compiler.
- But since... To handle this, we build the compiler using a bootstrapping
- version of Ruby. Then we load the pre-compiled compiler files as shown
- above. The approach is quite general, as demonstrated. However, a better
- approach may be appropriate for a particular application. In that case,
- talk to us about how you think it should work and we can point you in a
- direction to try implementing what you need.
-1. **We assume no responsibility for any security breaches resulting from your
- incorrect assumption that .rbc files provides any meaningful security
- mechanism.** I cannot stress this enough. The compiled file mechanism is a
- cache. It is a way to avoid recompiling Ruby source code that has not
- changed. The compiled format is simple. We reserve the right to provide
- disassemblers for our compiled code. We are happy to assist you with
- direction for implementing a more secure system for your needs.
-1. There is no mechanism that is completely safe from cracking when it comes
- to software access control. Witness how often Microsoft's products have
- their security features defeated. Also witness how often attempts at DRM
- are circumvented. The most secure system I have seen uses a special
- compiler and a hardware dongle. The compiler takes critical parts of the
- application logic and breaks them up so that part of the computation is
- performed on the dongle. This is significantly harder to defeat than binary
- editing an executable to turn a license key check into a no-op. The folks
- you most want to keep from accessing your information are the ones most
- capable of doing so. Security and access control are very hard problems.
-
-
-### Conclusion
-
-Rubinius compiles Ruby code to bytecode before running it. It is possible to
-save the bytecode representation and reload it later. Using this mechanism, it
-is possible to avoid providing the Ruby source code and run an application
-directly from the compiled bytecode. The mechanism we use to do this was
-created to solve our problem of bootstrapping the Rubinius bytecode compiler,
-which is written in Ruby. The mechanism is not intended to be used for
-security.
-
-It is possible to extend the Rubinius code loading mechanism to support custom
-formats for on-disk compiled bytecode and to load those formats. This can be
-done entirely in Ruby code. If this interests you, please talk with us about
-it.
diff --git a/_posts/2011-04-29-rubinius-t-shirts-and-stickers.markdown b/_posts/2011-04-29-rubinius-t-shirts-and-stickers.markdown
deleted file mode 100644
index 53a34b4..0000000
--- a/_posts/2011-04-29-rubinius-t-shirts-and-stickers.markdown
+++ /dev/null
@@ -1,79 +0,0 @@
----
-layout: post
-title: Rubinius T-Shirts and Stickers
-author: Shane Becker
----
-
-### Allow Myself to Introduce Myself
-
-Hi. I'm Shane ([@veganstraightedge](http://twitter.com/veganstraightedge)
-/ [iamshane.com](http://iamshane.com)). I'll be helping out around here now.
-I was recently hired by [Engine Yard](http://engineyard.com) to be their Open
-Source Cheerleader. (Yes, there will be costumes at some point.) My
-primary focus is **Rubinius! Rubinius! Rubinius!**
-
-I have lots of big plans for helping get Rubinius used by more people
-in more places and how to have a better conversation with people who are using
-it. For now though, I tell you about just the first thing that I've done.
-
-### T-Shirts
-
-#### The First Ever Rubinius T-Shirt from RailsConf 2007
-
-
-A long time ago (2007) in a city far, far away (Seattle, WA), Evan and I made
-the first batch of Rubinius t-shirts. There were about two dozen made and
-given to the handful of contributors at the time. This was at RailsConf in
-Portland, OR. Since then there hasn't been *anything* made with the Rubinius
-logo on it.
-
-Now is the time to rectify that. We've made two different t-shirts. Same
-messaging, slightly different design orientation. Both are the same colors:
-white on asphalt. They are available in an assortment of sizes from women's
-small to unisex xx-large.
-
-#### Use Ruby™ Rubinius T-Shirts from RailsConf 2011
-
-
-
-
-If you're going to RailsConf 2011 in Baltimore, MD, stop by the Engine Yard booth
-to pick up a free Rubinius t-shirt. After RailsConf we'll have ways to get one
-from us directly.
-
-
-### Stickers
-
-To go along with the t-shirts, we're making a whole grip of Rubinius stickers.
-Most of which will also be available for free from the Engine Yard booth at
-RailsConf in Baltimore. Again, after RailsConf you'll be able to get them
-directly from us. More on that later. Here's what we have in store.
-
-#### Wide Screen (7in x 3.75in)
-
-
-
-#### Square Logo
-
-
-
-#### Die-Cut R Logo
-
-
-
-#### I'm Committed Merit Sticker
-
-This one you have to earn. At the end of each quarter, we'll send out a little
-one inch square sticker with a year/quarter combination in its corner to
-everyone who committed something to Rubinius during that calendar quarter. For
-all of the incredible folks who've contributed something (however big or small)
-already, you'll get a special sticker. Instead of a date, there's an asterisk.
-Only those of you that've committed so far will get that one.
-
-
-
-Come find us to get free Rubinius shirts and stickers. And stay tuned to
-[the Rubinius blog](http://rubini.us/blog) and to the Twitter account :
-[@rubinius](http://twitter.com/rubinius). We have lots more in store.
-
-— Use Ruby™
diff --git a/_posts/2011-05-22-adam-prescott-on-scopes.markdown b/_posts/2011-05-22-adam-prescott-on-scopes.markdown
deleted file mode 100644
index 78e8526..0000000
--- a/_posts/2011-05-22-adam-prescott-on-scopes.markdown
+++ /dev/null
@@ -1,19 +0,0 @@
----
-layout: post
-title: Adam Prescott on Scopes in Rubinius
-author: Shane Becker
-email: veganstraightedge@gmail.com
----
-
-Adam Prescott wrote a lengthy article about variables, closures and scope in Ruby, mentioning Rubinius at the end:
-
-
-
One of the really cool things about the Rubinius implementation of Ruby is that it exposes, by requirement, a level of internals which you can’t find in MRI, including some internals with scopes. Because these internals are exposed in Ruby itself, you can play around with scopes as objects, using VariableScope, including getting access to the available local variables within that scope, with VariableScope.current.locals.
-
-
-How are **you** using Rubinius? What are you doing with it that you couldn't do before? What is it missing for you to really dive in? Let us know. We're listening.
-
-* [community@rubini.us](community@rubini.us)
-* [@rubinius](http://twitter.com/rubinius "@rubinius on twitter")
-
-— Use Ruby™
diff --git a/_posts/2011-05-26-rubinius-rewards.markdown b/_posts/2011-05-26-rubinius-rewards.markdown
deleted file mode 100644
index 20c49a8..0000000
--- a/_posts/2011-05-26-rubinius-rewards.markdown
+++ /dev/null
@@ -1,110 +0,0 @@
----
-layout: post
-title: Announcing Rubinius Rewards
-author: Shane Becker
----
-
-### Update
-
-See [this post](http://rubini.us/2011/09/02/retiring-some-rubinius-rewards/ "Retiring (Some) Rubinius Rewards - Rubinius") about retired shirts/stickers and to see what's still available.
-
-## tl;dr
-
-Email [community@rubini.us](mailto:community@rubini.us) to get stickers and
-t-shirts. Include your mailing address.
-
-## We Made T-Shirts and Stickers
-
-We heard you like stickers and t-shirts, so we made some. They
-debuted at [RailsConf 2011 in Baltimore, MD](http://en.oreilly.com/rails2011 "RailsConf 2011 - O'Reilly Conferences, May 16 - 19, 2011, Baltimore, MD!").
-Then we gave almost all of them away in just a few hours. They went like
-hotcakes. It turns out that there was a lot of pent up demand for Rubinius
-swag.
-
-Not everyone could be at RailsConf to get the goods, of course. Even some
-people who were there didn't get their shirts/stickers. If you didn't get one
-and want one, we're very sorry, but don't you worry. We've got you covered.
-
-
-## General Availability Stickers
-
-[](http://www.flickr.com/photos/veganstraightedge/5742057726)
-
-We've got a box of stickers in three designs:
-[square](http://asset.rubini.us/web/images/blog/rubinius_square_sticker.png),
-[bumper](http://asset.rubini.us/web/images/blog/rubinius_bumper_sticker.png)
-and
-[die-cut](http://asset.rubini.us/web/images/blog/rubinius_diecut_sticker.png).
-
-[Email us](mailto:community@rubini.us) and tell us which one you want.
-
-## General Availability T-Shirt
-
-We're printing 500 more grey Rubinius t-shirts in the two different designs
-and in a a handful of sizes (women's small and medium, unisex small –
-xx-large).
-
-[Email us](mailto:community@rubini.us) and tell us which design / size you want:
-[square](http://asset.rubini.us/web/images/blog/rubinius_use_ruby_square_shirt.jpg)
-or
-[horizontal](http://asset.rubini.us/web/images/blog/rubinius_use_ruby_horizontal_shirt.jpg)
-in
-women's small, women's medium, unisex small, unisex medium, unisex large,
-unisex x-large or unisex xx-large.
-
-[![Rubinius "Use Ruby™" T-Shirts at the Farmhouse in Hollywood, CA](http://farm4.static.flickr.com/3469/5709097384_0bde99e1d3_z.jpg "Rubinius "Use Ruby™" T-Shirts at the Farmhouse in Hollywood, CA, on Flickr")](http://www.flickr.com/photos/veganstraightedge/5709097384)
-
-Photo by [Tj Nelson Jr](http://flickr.com/tjnelsonjunior "Flickr: tjnelsonjunior's Photostream")
-[@tjnelsonjr](http://twitter.com/tjnelsonjr "@tjnelsonjr")
-
-
-## First Commit Sticker
-
-Going forward, we want to reward everyone who makes a contribution to
-Rubinius. As a very small token of our gratitude, we're mailing a Rubinius
-sticker (and a handwritten thank you note from one of us) to everyone after
-their first commit. So, if you've ever thought about dipping your toe into
-Rubinius (or diving headlong into the deep end), now's the best time ever.
-Help us make Rubinius better (in big and small ways) and we'll send you stuff.
-
-
-## Tenth Commit Shirt
-
-We want you to stick around and keep helping Rubinius to get better and better.
-If you make 10 commits to Rubinius, we'll send you a special shirt only
-available to committers. That design is still a secret for now, but it's just
-for 10+ committers.
-
-*Please, don't try to game the system by intentionally breaking stuff up into
-smaller commits just to bump up your count. Let's keep it honest.*
-
-
-## Quarterly Committer Merit Badge Stickers
-
-In addition to getting a generally available sticker after your first commit,
-at the end of each calendar quarter (every three months) we're sending a
-sticker to everyone who committed to Rubinius **during** that quarter.
-
-E.g. after July 1, 2011, we'll print and ship a sticker to everyone who
-committed between April 1 and June 30. Each quarter's sticker has the year /
-quarter in the corner. Keep committing every quarter and you'll keep
-collecting the merit badge stickers.
-
-## One More Thing — I'm Committed* Sticker
-
-Rubinius is obviously older than the new Rubinius Rewards program. To backfill
-for all the contributions people have made over the years up until, we have a
-*super duper limited edition never to be made again* sticker... the asterisk.
-
-[](http://www.flickr.com/photos/veganstraightedge/5742135762)
-
-## Get in Touch
-
-If you're a past committer, [email us](mailto:community@rubini.us) your
-mailing address get your special merit sticker. If you're a new committer,
-we'll try to take note and reach out to you. If you don't hear from us,
-don't be afraid to contact us with your mailing address.
-
-### Up Next...
-
-Rubinius International Outposts.
diff --git a/_posts/2011-06-07-inside-rubinius-20-preview.markdown b/_posts/2011-06-07-inside-rubinius-20-preview.markdown
deleted file mode 100644
index 7262bf6..0000000
--- a/_posts/2011-06-07-inside-rubinius-20-preview.markdown
+++ /dev/null
@@ -1,151 +0,0 @@
----
-layout: post
-title: Inside the Rubinius 2.0 Preview Release
-author: Brian Ford
----
-
-Houston, we have a problem. Complex projects are difficult to transition
-forward and Rubinius is a complex project. Rubinius is at the point of a major
-transition and we need your help to move forward.
-
-Just over a year ago, Rubinius released version 1.0. Since then, dozens of
-contributors have added over 2,200 commits to the master branch and we have
-released seven new versions. At the same time, we have added nearly 450
-commits on a development branch to remove the global interpreter lock (GIL)
-and begin adding Ruby 1.9 and Windows support.
-
-
-
-Today we are releasing *Rubinius 2.0 Developer Preview*. The primary focus of
-this release is true Ruby multi-threaded concurrency. Additionally, it
-contains the beginnings of Ruby 1.9 and Microsoft Windows support.
-
-
-### Rubinius 2.0 Developer Preview
-
-We are seeking developers interested in running their Ruby and Rails projects
-on Rubinius to help us iron out issues as we work toward the final 2.0
-release. Let's look at the details of the 2.0 developer preview.
-
-One of the central features of Rubinius 2.0 is a fundamental change in the
-threading architecture. In Rubinius 2.0, Ruby threads will run with true
-concurrency. This means that if multi-core or multi-CPU hardware is available,
-Ruby code on different threads will actually run in parallel.
-
-Another central feature of Rubinius 2.0 is support for both Ruby 1.8.7 and
-Ruby 1.9.2 syntax. The Rubinius 2.0 support for Ruby 1.8.7 should be 100%
-backward compatible with the support in the Rubinius master branch. The full
-Ruby concurrency is enabled regardless of what language syntax mode is active.
-
-
-### Repository Migration
-
-We are migrating the main Rubinius repository to the [Rubinius](
-https://github.com/rubinius) organization.
-
-The RVM project has already been updated to work with the new repository. So
-`rvm install rbx` will use the new repository. If you have an existing clone
-of Rubinius, update and run `rake github` to point your existing repository to
-the new one.
-
-You can clone directly from the [new repository](https://github.com/rubinius/rubinius).
-
-
-### Installation
-
-For testing Rubinius with your application, installing with RVM is probably
-the easiest. To install the 2.0 developer preview, ensure that RVM is updated:
-
- rvm get head
- rvm reload
-
-Then, install the Rubinius 2.0.0pre branch:
-
- rvm install rbx-2.0.0pre
-
-If you are interested in helping develop Rubinius, we suggest you clone the
-repository directly and build. Rubinius runs fine from the source directory so
-you don't need to install it. For more details about building from a clone,
-see [Getting Started](http://rubini.us/doc/en/getting-started/).
-
-
-### Configuration
-
-The goal of Rubinius 2.0 is to fully support both Ruby 1.8.7 and 1.9.2 in a
-single executable. When running Rubinius, you can select which version to use.
-There are configuration options to change which versions are supported and
-which version is the default.
-
-The first configure option is `--enable-version=X[,Y]`. This option sets which
-language versions will be supported. An example is:
-
- ./configure --enable-version=1.8,1.9
-
-The language versions can be specified as `18` or `1.8`. Multiple versions are
-separated by a comma and no space.
-
-The second configure option is `--default-version=X`. This option sets which
-language version is the default when running Rubinius. An example is:
-
- ./configure --default-version=1.9
-
-These options are intended to be used together. You must enable a version to
-select it as the default, so the options must come in the following order:
-
- ./configure --enable-version=X,Y --default-version=Y
-
-Once you have enabled support for a language version, to select that mode when
-running Rubinius, use the `-X18` or `-X19` command line switches. For example:
-
- rbx -X19 -v
-
-This command will run Rubinius with the 1.9 language mode enabled.
-
-You may also use the `RBXOPT` environment variable to select the language
-mode. Assuming that 1.8 is the default mode, the following command would run
-Rubinius with the 1.9 language mode enabled:
-
- RBXOPT=-X19 rbx -v
-
-Right now, only the 1.8 language mode is enabled in the 2.0.0pre branch.
-However, we will be enabling the 1.9 mode in the very near future. The default
-mode will continue to be 1.8 unless you configure Rubinius to run in 1.9 mode.
-
-
-### Building on Windows
-
-On Windows, Rubinius uses the [MinGW-w64](http://mingw-w64.sourceforge.net/)
-compiler to build a native application. There remains a lot of work to do for
-Windows support but the Rubinius VM is currently compiling on Windows 7.
-
-If you are a bleeding-edge Windows developer interested in diving into
-Rubinius, here's how to get started:
-
-1. Install *MRI 1.9* using [RubyInstaller](http://rubyinstaller.org/).
-1. Install [MSysGit](http://code.google.com/p/msysgit/).
-1. Install the 32bit or 64bit MinGW-w64 toolchain.
-1. Clone the Rubinius repository.
-1. In CMD, run `ruby configure`.
-1. Run `rake`.
-
-
-### Moving Forward
-
-In the near future, we will release another version of Rubinius from the
-current master branch. We hope to merge 2.0.0pre into master as soon as
-possible and continue working toward the 2.0 final release. We'll make that
-decision based on your reports about how the 2.0.0pre branch is working with
-existing 1.8.7 applications.
-
-We greatly appreciate your help polishing up the Rubinius 2.0 release! Follow
-us on [Twitter](http://twitter.com/rubinius) for updates and stop by #rubinius
-on freenode.net to chat about anything on your mind.
-
-
-### Rubinius Support on EngineYard AppCloud
-
-Rubinius 1.2.3 is currently in beta on Engine Yard AppCloud, and we encourage
-users to [give it a try](http://docs.engineyard.com/rubinius.html). Engine
-Yard will support Rubinius 2.0.0 after it’s officially released.
-
-To learn more about Rubinius, join Engine Yard for a [Platform Options Webinar](http://pages.engineyard.com/RubyPlatformOptionsWebinarJuly212011.html) in July.
diff --git a/_posts/2011-07-01-rubinius-summit-in-pictures.markdown b/_posts/2011-07-01-rubinius-summit-in-pictures.markdown
deleted file mode 100644
index 8c21446..0000000
--- a/_posts/2011-07-01-rubinius-summit-in-pictures.markdown
+++ /dev/null
@@ -1,39 +0,0 @@
----
-layout: post
-title: Rubinius Summit 062011 in Pictures
-author: Shane Becker
----
-
-Once a month Evan Phoenix, Brian Ford and I (Shane Beccker) get together for a few days in-person face-time. Usually we meet up in San Francisco at the [Engine Yard](http://engineyard.com) HQ and spend time with our dear and lovely boss, [Dr Nic](http://twitter.com/drnic). We like to call these little get togethers Rubinius Summits. For the June 2011 Rubinius Summit, Brian came down to LA where both Evan and I live. We spent the week working together at [The Farmhouse](http://farmhouse.la) on moving the ball forward toward the 2.0 release. Here's a few pictures of some of the things that went down.
-
-### I Used Rubinius at RailsConf 2011 stickers
-
-[!["I Used Rubinius at RailsConf 2011" stickers at The Farmhouse in Hollywood, CA](http://farm7.static.flickr.com/6052/5885836117_ba60ba6408_z.jpg ""I Used Rubinius at RailsConf 2011" stickers at The Farmhouse in Hollywood, CA ")](http://flickr.com/photos/veganstraightedge/5885836117)
-
-These stickers arrived and are ready to be shipped out. If you DMed your address to [us on Twitter](http://twitter.com/rubinius), we've got you. If you never contacted us, but used Rubinius while at RailsConf 2011 in Baltimore, email us at [community@rubini.us](mailto:community@rubini.us) to get your sticker.
-
-### T-Shirts!
-
-[](http://flickr.com/photos/veganstraightedge/5889084175)
-
-This is what nearly 600 shirts looks like. We've got a huge back log of people all over the world who responded to our offer of free Rubinius t-shirts. Those will all get shipped out over the next week or so.
-
-### Progress on 1.9 Support
-[](http://flickr.com/photos/veganstraightedge/5888809669)
-
-Brian and Evan, like a couple of mad scientists, sketched out how to handle 1.9 block arguments for Rubinus 2.0.
-
-[](http://flickr.com/photos/veganstraightedge/5889687428)
-[](http://flickr.com/photos/veganstraightedge/5889686740)
-
-Here are the sketches of 1.9 block arguments for Rubinus 2.0.
-
-### One More Thing
-
-We came up with an idea this week for how to better communicate outwardly and be more transparent. We built it up real quick and are launching it ...*really soon*. Here's a little teaser.
-
-[](http://drbl.in/bxbg)
-[](http://drbl.in/bxbf)
-
-
-*XOXO RBX*
diff --git a/_posts/2011-07-03-all-around-the-world.markdown b/_posts/2011-07-03-all-around-the-world.markdown
deleted file mode 100644
index 9a0547a..0000000
--- a/_posts/2011-07-03-all-around-the-world.markdown
+++ /dev/null
@@ -1,18 +0,0 @@
----
-layout: post
-title: Rubinius All Around the World
-author: Shane Becker
----
-
-As a result of the [Rubinius Rewards](http://rubini.us/2011/05/26/rubinius-rewards/ "Announcing Rubinius Rewards - Rubinius"), people from all over the world have requested Rubinius stickers and t-shirts. That just warms our little hearts and humbles us everyday. Thank you so much. It means the world to us. Keep using Rubinius with passion and excitement. Keep spreading the good word to your friends and anyone who'll listen and care. And keep telling us how Rubinius is working for you. However good or bad, we want to know.
-
-Here's a map of all the places where we've sent stickers and/or t-shirts. You can also view it on
-[a larger map](http://maps.google.com/maps/ms?msa=0&msid=204706765448868864026.0004a732bcb9b5816e407&ie=UTF8&ll=19.311143,-0.351562&spn=111.602296,333.632812&z=2&source=embed "Rubinius Around the World - Google Maps"). Wow.
-
-
-
-Again, thank you from the bottom of our hearts.
-
-Stay safe, kids.
-
-**XOXO RBX**
diff --git a/_posts/2011-07-05-whats-the-status-kenneth.markdown b/_posts/2011-07-05-whats-the-status-kenneth.markdown
deleted file mode 100644
index 8165d9d..0000000
--- a/_posts/2011-07-05-whats-the-status-kenneth.markdown
+++ /dev/null
@@ -1,31 +0,0 @@
----
-layout: post
-title: What’s the Status, Kenneth?
-author: Shane Becker
----
-
-I’m pretty sure it started like this.
-
-> “Hello, Evan dear.” — *Evan’s Grandma Betty*
-
-> “Grandma Betty!” — *Evan*
-
-> “You know, I was thinking about your little Rubinius thingy while I was gardening today. How’s it doing?” — *Evan’s Grandma Betty*
-
-> “Oh, Grandma Betty, that’s so sweet of you to think of me and it. It’s coming along still, of course.” — *Evan*
-
-> “That’s good to hear. I was specifically wondering how the 1.9 support is looking.” — *Evan’s Grandma Betty*
-
-> “Grandma Betty! You do always love the Latest and Greatest™, don’t you? Well, let’s see. I’d say that *1.9 support* comes down to 7 main areas: Encoding, String, Regex, Symbol, IO, Argument Processing, Windows Support. Each has varying degrees of progress.” — *Evan*
-
-> “OK. I wish that there was some way for me to keep more up to date on these happenings without needing to calling you. When I call you, I want to hear about that wife and baby of yours.” — *Evan’s Grandma Betty*
-
-> “You got it, Grandma Betty. I’ll get my Top Nerds™ on the case.” — *Evan*
-
-> [sometime later]
-
-> “Alright, Grandma Betty. We made the Rubinius Status Board™ especially just for you. It’s [status.rubini.us](http://status.rubini.us)” — *Evan*
-
-That conversation may or may not be **completely fictionalized**. There is one thing that is most emphatically true: Rubinius has a Status Board™ now. If you are ever curious how progress is going on things, go check out [status.rubini.us](http://status.rubini.us). Tell your friends.
-
-XOXO RBX.
diff --git a/_posts/2011-07-07-rbxday.markdown b/_posts/2011-07-07-rbxday.markdown
deleted file mode 100644
index 3c4a107..0000000
--- a/_posts/2011-07-07-rbxday.markdown
+++ /dev/null
@@ -1,25 +0,0 @@
----
-layout: post
-title: rbxday
-author: Shane Becker
----
-
-### We’re having a party and you’re invited!
-
-### [rbxday.rubini.us](http://rbxday.rubini.us)
-
-#### Friday, August 5, 2011 is [#rbxday](http://rbxday.rubini.us)
-
-The Rubinius 2.0 Preview Release is still cranking along. We’re feeling good about how things are going. As always, thank you everyone for all of your contributions. The [list of authors on the 1.2.4 release](http://rubini.us/releases/1.2.4/#authors "Rubinius : Use Ruby™") is just fantastic.
-
-Moving forward to the 2.0 official release, we need more feedback from you about your code running on Rubinius. Not just what doesn’t work and not just bugs (although both of those are important too), but how is your code performing, where are the bottlenecks, etc.
-
-This is what we’re going to do about that. Everyone... everyone all around the world that uses or cares about Rubinius and its progress, all of us on one day are going to run our code, collect performance data / bug reports and send them up to the Rubinius project.
-
-[#rbxday](https://twitter.com/#!/search/%23rbxday) is a party! Take pictures of you and your buddies on the day of. If you’ve got a Rubinius t-shirt or sticker, get them in there. Tweet about it, now and on the day. Get excited. Tell your friends. Get them excited. Use the hashtag #rbxday in your tweets, blog posts and posts. We’ll repost them all on the [#rbxday](http://rbxday.rubini.us) site.
-
-Make sure you’re looking your best in your photos because we’ll be picking a winner for our favorite [#rbxday](http://twitter.com/#!/search/%23rbxday "#rbxday search on Twitter") glamourshot. Tweet them using the hashtag [#rbxday](http://twitter.com/#!/search/%23rbxday "#rbxday search on Twitter") and we’ll announce the winning photo Monday, August 8, 2011 on the [Engine Yard Facebook page](http://facebook.com/engineyard). We’ll have a nifty prize for the winner too, so make sure your pic is goofy, sultry, or otherwise impressive. Bonus points for creativity.
-
-Get your party hats on!
-
-—XOXO RBX
diff --git a/_posts/2011-07-29-rbxday-at-outright.markdown b/_posts/2011-07-29-rbxday-at-outright.markdown
deleted file mode 100644
index 2d70e0f..0000000
--- a/_posts/2011-07-29-rbxday-at-outright.markdown
+++ /dev/null
@@ -1,34 +0,0 @@
----
-layout: post
-title: Outright Hacks #rbxday
-author: Brian Ford
----
-
-Hey Ruby bytecode fans! The first ever **International Rubinius Day** is next
-Friday, August 5th. Around the world people will be trying their code on
-Rubinius and generally having a fun time. Follow the activities on Twitter
-under the _\#rbxday_ tag and use that to let folks know what you're up to. Stay
-tuned to the [rbxday website](http://rbxday.rubini.us/) for details as the day
-unfolds.
-
-If you are located in, around, or within traveling distance of beautiful
-Mountain View, CA, the terrific folks at [Outright.com](http://outright.com)
-are sponsoring a real live _\#rbxday_ event! Come hang out with a bunch of
-hardcore Ruby nerds, including Brian Ford (that's me) from the Rubinius team.
-Plan to be inspired by all the great stuff people are working on. There will
-be mountains of top-shelf Rubinius schwag, as well as _free beer and pizza_.
-(Just don't get too trashed as there will also be lightning talks and an IR
-helicopter obstacle course.)
-
-The [party](http://rbxday.eventbrite.com/) will be from 1:00 pm to 8:00 pm on
-Friday August 5th at Outright's offices in downtown Mountain View. (They have
-an application that does some seriously awesome stuff with small business
-accounting.) There are plenty of desks, monitors and whiteboards available, so
-bring your laptop and be ready to jam.
-
-Space is limited, and the coolest developers in the valley are already coming,
-so if you know your stuff and want to have fun, [rsvp
-now](http://rbxday.eventbrite.com/)!
-
-See you there!
-
diff --git a/_posts/2011-07-31-rbxday-at-80beans.markdown b/_posts/2011-07-31-rbxday-at-80beans.markdown
deleted file mode 100644
index 84585ba..0000000
--- a/_posts/2011-07-31-rbxday-at-80beans.markdown
+++ /dev/null
@@ -1,28 +0,0 @@
----
-layout: post
-title: Come hack in Amsterdam for #rbxday
-author: Dirkjan Bussink
----
-
-Not only in the US is [#rbxday](http://rbxday.rubini.us/) celebrated, but
-we have also something in Amsterdam next Friday. It's really becoming the
-International Rubinius Day that it was set out to be.
-
-The guys are [80beans](http://www.80beans.com/) are sponsoring the event and
-have graciously offered their office as the place to hang out and are
-providing refreshments. The office is located on the [Vijzelstraat 72](http://maps.google.com/maps/place?q=80beans,+Amsterdam,+The+Netherlands&hl=en&cid=15251096961071716406) in
-Amsterdam and we're starting at 3pm.
-
-If you're living in the neighborhood, please come and join us. As long
-term Rubinius contributor Dirkjan Bussink is coming over from the other side of
-the country, so don't feel held back when you're not living in Amsterdam
-itself.
-
-So be prepared for an afternoon of very interesting hacking. We really want
-to make it a fun afternoon of experimenting with Rubinius, so anything
-goes! Please leave a message on the [80beans blog](http://www.80beans.com/en/blog) if you're planning to come over:
-
-[http://www.80beans.com/en/blog/2011/07/29/rbxday-at-the-80beans-office](http://www.80beans.com/en/blog/2011/07/29/rbxday-at-the-80beans-office)
-
-Hopefully see you there!
-
diff --git a/_posts/2011-08-03-rbxday-in-real-life.markdown b/_posts/2011-08-03-rbxday-in-real-life.markdown
deleted file mode 100644
index 44e8626..0000000
--- a/_posts/2011-08-03-rbxday-in-real-life.markdown
+++ /dev/null
@@ -1,82 +0,0 @@
----
-layout: post
-title: "#rbxday In Real Life"
-author: Brian Ford
----
-
-**UPDATE:** _We have added several locations since this post was first
-published. See the list below for all the current details. Also, stay tuned to
-the official [rbxday.rubini.us](http://rbxday.rubini.us) website for updates
-throughout_ [#rbxday](https://twitter.com/#!/search/%23rbxday).
-
-**The first ever** [#rbxday](https://twitter.com/#!/search/%23rbxday) is fast
-approaching on Friday, August 5th. Depending on your time zone, that is either
-tomorrow or the day after tomorrow. To help you get prepared, here are a few
-updates.
-
-Originally, the idea for [#rbxday](https://twitter.com/#!/search/%23rbxday)
-was a day that people all around the world could have fun experimenting with
-Ruby and Rubinius. Try your application or pet Ruby project on Rubinius, or
-pull out that idea you've been wanting to explore, code it up, and run it on
-Rubinius. We are not asking anyone to contribute to Rubinius, but we would be
-most flattered if you wanted to dig into the Rubinius code to see what's going
-on under the hood. To sum up, the motto of the day is "Ruby, Rubinius, Fun Fun Fun Fun".
-
-Of course, a great way to multiply fun is to share it with others. Several
-people have taken the initiative of organizing meetups on
-[#rbxday](https://twitter.com/#!/search/%23rbxday):
-
-* **San Francisco, CA, USA**: [Melissa Sheehan - @engineyard](http://twitter.com/engineyard)
- of [Engine Yard](http://engineyard.com), sign up at [rbxdaysf.eventbrite.com](http://rbxdaysf.eventbrite.com/)
-
-* **Mountain View, CA, USA**: [Ben Curren - @bcurren](http://twitter.com/bcurren) co-founder
- of [Outright.com](http://outright.com),
- sign up at [rbxday.eventbrite.com](http://rbxday.eventbrite.com/)
-
-* **Los Angeles, CA, USA**: [Shane Becker - @veganstraightedge](http://twitter.com/veganstraightedge)
- Open Source Cheerleader at [Engine Yard](http://engineyard.com)
- for [Rubinius](http://rubini.us), 10am - 8pm at
- [the Farmhouse](http://farmhouse.la)
-
-* **Portland, OR, USA**: [Kyle Drake - @kyledrake](http://twitter.com/kyledrake)
- avid Rubyist, event at [PIE](http://piepdx.com), see
- [Calagator.org](http://calagator.org/events/1250461183) for details
-
-* **Amsterdam, Netherlands**: [Dirkjan Bussink - @dbussink](http://twitter.com/dbussink)
- long time Rubinius contributor, event at
- [80beans](http://80beans.com/en/blog/2011/07/29/rbxday-at-the-80beans-office)
-
-* **Barcelona, Spain**: [Josep M. Bach - @txustice](http://twitter.com/txustice) inventor of
- [cool Rubinius technology](http://blog.txustice.me/2011/06/rexpl-interactive-bytecode-console-for-rubinius),
- event at [Codegram](http://blog.codegram.com/2011/8/celebrate-rbxday-with-us-at-codegram)
-
-* **Montevideo, Uruguay**: [Santiago Pastorino - @spastorino](http://twitter.com/spastorino)
- co-founder of [@wyeworks](http://twitter.com/wyeworks), event at the [WyeWorks office](http://www.wyeworks.com/)
-
-A huge thanks to everyone who has organized one of these events. They did so
-on their own initiative and show the true power of a community. If you're near
-one of the events, please do attend. If not, *there's still time to organize
-one near you.*
-
-If you are joining [#rbxday](http://twitter.com/#!/search/%23rbxday) from the
-comfort of your own home, tweet about it, include pictures, and join us in
-the [\#rubinius](irc://irc.freenode.net#rubinius) IRC channel on freenode.net.
-We would love to hear from you.
-
-A final thought about all the ways you can help Rubinius. You don't have to
-contribute code directly to help. Each of these activities is just as
-valuable, and if you think of any I didn't include, please let me know:
-
-* Wearing your [Rubinius shirt](http://rubini.us/2011/05/26/rubinius-rewards)
-* Talking to co-workers about Rubinius
-* Asking your company to sponsor some of your time contributing to Rubinius
-* Writing libraries in Ruby
-* Writing blog posts or books about Ruby technology, like fully-concurrent
- threads in [JRuby](http://jruby.org) and Rubinius 2.0
-* Talking to people about what you find painful in Ruby and how we may be able
- to improve those pain points
-* Testing your code on Rubinius and submitting bug/performance reports
-
-Above all, please do have fun. That's no gimmick. The world needs more fun.
-
-Put a tag on it [#rbxday](http://twitter.com/#!/search/%23rbxday).
diff --git a/_posts/2011-08-05-rbxday-blog-posts.markdown b/_posts/2011-08-05-rbxday-blog-posts.markdown
deleted file mode 100644
index fcab93a..0000000
--- a/_posts/2011-08-05-rbxday-blog-posts.markdown
+++ /dev/null
@@ -1,58 +0,0 @@
----
-layout: post
-title: "#rbxday Blog Posts"
-author: Shane Becker
----
-
-With just a few hours left in the first [#rbxday](http://rbxday.rubini.us),
-I wanted to share a few blog posts that people have written for today.
-It seems like lots of people are having lots of fun all while using Rubinius.
-That’s what really matters.
-
-And I think [Andrew W. K.](http://twitter.com/andrewwk)
-would probably be proud of that.
-
-Onto the blog posts...
-
-Nathan Engdahl on the
-[Blue Box Group blog](http://bluebox.net/news/2011/08/rubinius-day "Rubinius Day")
-writes:
-
-> What is Rubinius you ask? Quite simply, it’s an alternative implementation
-> of Ruby, written in Ruby, designed for modern web developers. It provides
-> tools for simpler development of web applications. Rubinius strives for a
-> particularly fast and optimized implementation, ensuring applications run
-> at peak efficiency.
-
-Chris White [compares bytecode](http://rubysource.blogspot.com/2011/08/taking-byte-out-of-ruby.html "A Source For All Things Ruby: Taking A Byte Out of Ruby")
-from MRI, JRuby and Rubinius:
-
-> Many developers don’t think too much about what’s going on behind the
-> scenes when they run their Ruby code. That’s the beauty of it, easy to
-> write code that’s given to Ruby and run for the developer. At some point
-> the developer may wonder, what’s REALLY going on behind the scenes. How is
-> it that something meant to run Ruby can host [so many other languages](http://rubini.us/projects")?
-> The answer lies in what’s known as a VM, or Virtual Machine.
-
-Finally, there’s the
-[Rubysfera blog](http://rubysfera.pl/2011/08/kod-zrodlowy-rubiego-w-rubym/ "Kod źródłowy Rubiego w Rubym")
-that’s not written in a language that I can read. So, I’ll just assume that
-they’re talking about Chocolate Rubinius Cake and how to bake it. ;)
-
-> Rubiniusa (implementacji Rubiego, napisanej w Rubym) nikomu chyba
-> przedstawiać nie trzeba. Obecnie obsługiwana jest wersja języka 1.8.7, a
-> niektóre benchmarki pokazują, że Rubinius w tej wersji może osiągać szybkość
-> porównywalną z JRuby. Benchmarki, benchmarkami, najciekawsza jest możliwość
-> zajrzenia do implementacji języka w Rubym.
-
-*Seriously though, I have no idea what that post says.
-If you do, please let me know.*
-
-There’s still time. Go test your app running on Rubinius. Tweet about it.
-Use the hashtag [#rbxday](https://twitter.com/#!/search/%23rbxday), so we
-notice you and re-share your tweet. If there are bugs, please
-[create an issue](https://github.com/rubinius/rubinius/issues) on Github.
-Give us any other feedback you want on the
-[rbxday.rubini.us](http://rbxday.rubini.us/feedback) website.
-
-*— XOXO RBX*
diff --git a/_posts/2011-08-30-rubinius-3d.markdown b/_posts/2011-08-30-rubinius-3d.markdown
deleted file mode 100644
index 9ac63f7..0000000
--- a/_posts/2011-08-30-rubinius-3d.markdown
+++ /dev/null
@@ -1,20 +0,0 @@
----
-layout: post
-title: Rubinius - Now in The Third Dimension
-author: Shane Becker
----
-
-A long time ago, [Bookis Smuin](http://twitter.com/bookis "@bookis on Twitter") crafted up a 3-dimensional representation of the little Rubinius *r* logo. It was used on the Rubinius website and as the avatar for the [@Rubinius](http://twitter.com/#!/rubinius "@Rubinius on Twitter") account. And for awhile, things were good.
-
-Somewhere along the way, the original files were lost. That left us with only PNG that was 239px wide. That's no good. To the Twitters!
-
-I [lazy tweeted](http://twitter.com/#!/veganstraightedge/status/101149379880157184 "Plea for 3D Help on Twitter") asking for help re-building the logo in 3D based on the work that Bookis did. Lo and behold, I asked and the internet delivered.
-
-The very smart and good looking Roger Bacardit ([@ruxii](http://twitter.com/ruxii "@ruxii on Twitter")) from [Codegram](http://codegram.com "Codegram - Smart Web Apps") in Barcelona, España stepped up to tackle the task. Lickity split, he cranked out two versions (white on black and black on white) at super mega huge resolution (~4000px square).
-
-Like everything else we do, [these logo files](https://github.com/rubinius/collateral/tree/master/logos/3D) are [very liberally licensed](https://github.com/rubinius/collateral/blob/master/README.md) and available for download and reuse in the [Rubinius Collateral repo](https://github.com/rubinius/collateral) over on GitHub.
-
-Thank you, Bookis, for the original.
-Thank you, Roger, for the rebuild.
-
-*— XOXO RBX*
diff --git a/_posts/2011-09-02-retiring-some-rubinius-rewards.markdown b/_posts/2011-09-02-retiring-some-rubinius-rewards.markdown
deleted file mode 100644
index 1ec005a..0000000
--- a/_posts/2011-09-02-retiring-some-rubinius-rewards.markdown
+++ /dev/null
@@ -1,33 +0,0 @@
----
-layout: post
-title: Retiring (Some) Rubinius Rewards
-author: Shane Becker
----
-
-### Bad News First
-
-The [General Availability shirts](http://www.flickr.com/photos/veganstraightedge/5709097384 "Rubinius "Use Ruby™" TShirts at the Farmhouse in Hollywood, CA") are retired. We gave out about 1,000 to people all over the world. That's very awesome. We're really happy with the excitement about Rubinius from you all. Thank you, again. But it's time to move on from these shirts. If you've already got one, good on you. If you haven't yet, sorry. There will be other chances in the future, though.
-
-Likewise, the [Square](http://asset.rubini.us/web/images/blog/rubinius_square_sticker.png) and [Bumper Stickers](http://asset.rubini.us/web/images/blog/rubinius_bumper_sticker.png) have been retired, too.
-
-### Good News Next
-
-The [Diecut R stickers](http://asset.rubini.us/web/images/blog/rubinius_diecut_sticker.png) are still available. Just email us at [community@rubini.us](mailto:community@rubini.us) if you want one. [Committers stickers](http://asset.rubini.us/web/images/blog/rubinius_alumni_sticker.png) are still available too. If you committed to Rubinius before May 16, 2011 and haven't received one of these, [email us](mailto:community@rubini.us) to get yours. The 2011 Q2 committers stickers are also available.
-
-As [promised](http://rubini.us/2011/05/26/rubinius-rewards/#tenth-commit-shirt "Announcing Rubinius Rewards - Rubinius"), we have made a special t-shirt for people who have committed 10 or more times. They're at the printer right now, so no pictures yet. Here's a hint though: black on black.
-
-We'll continue to do free stuff in the future, but it will always be changing. Keep an eye on this blog for updates to what's available.
-
-### One More Thing
-
-Rubinius friend of the family, [Heather Peterson](http://hrrrthrrr.com "hrrrthrrr") ([@hrrrthrrr](http://twitter.com/hrrrthrrr)) drew up some Rubinius sketches for us to use on upcoming t-shirts and stickers. As a little thing, we're giving away her original artwork as prize.
-
-
-[](http://flickr.com/veganstraightedge/6106800183 "Rubinius sketch by Heather Peterson (@hrrrthrrr)")
-[](http://flickr.com/veganstraightedge/6106803145 "Rubinius sketch by Heather Peterson (@hrrrthrrr)")
-
-To enter, write a blog post about Rubinius and tweet at [@rubinius](http://twitter.com/rubinius) with a link to your post by Wednesday, September 7, 2011 Midnight PDT. Posts will be judged by me (Shane Becker), Evan Phoenix and Brian Ford. The winner will be announced on Friday September 9, 2011. All entrants will be linked to from [the Rubinius blog](http://rubini.us/blog "Rubinius : Use Ruby™") and [@rubinius](http://twitter.com/rubinius) Twitter account.
-
-Get blogging.
-
-*— XOXO RBX*
diff --git a/_posts/2011-09-06-drnic-interview.markdown b/_posts/2011-09-06-drnic-interview.markdown
deleted file mode 100644
index 5067c6b..0000000
--- a/_posts/2011-09-06-drnic-interview.markdown
+++ /dev/null
@@ -1,11 +0,0 @@
----
-layout: post
-title: Dr Nic Interviewed by Obie Fernandez about Rails, RailsInstaller, Ruby Virtual Machines and More
-author: Shane Becker
----
-
-> Dr Nic Williams talks about the state of the Rails community, the reasons
-> for supporting JRuby and Rubinius implementations and for creating Rails
-> Installer.
-
-[Watch and listen on InfoQ](http://www.infoq.com/interviews/drnic-rails-ruby-vm "InfoQ: Dr Nic Williams on Rails, RailsInstaller and the Future of Ruby VMs").
diff --git a/_posts/2011-10-04-steve-klabnik-thinks-rubinius-is-awesome.markdown b/_posts/2011-10-04-steve-klabnik-thinks-rubinius-is-awesome.markdown
deleted file mode 100644
index 3fffbb4..0000000
--- a/_posts/2011-10-04-steve-klabnik-thinks-rubinius-is-awesome.markdown
+++ /dev/null
@@ -1,17 +0,0 @@
----
-layout: post
-title: Steve Klabnik Thinks Rubinius is Awesome
-author: Shane Becker
----
-
-Steve Klabnik [added support for `require_relative` to Rubinius](https://github.com/rubinius/rubinius/pull/1184). He documents his process and [how much fun he had](http://blog.steveklabnik.com/2011/10/04/rubinius-is-awesome.html "Rubinius Is Awesome - Literate Programming"). We're glad to hear that Steve thinks Rubinius is awesome. Making Rubinius awesome for rubyists has always been one of our core tenets.
-
-> Even if I didn’t have some code to look at, because Rubinius is just Ruby,
-> it was really easy to dive in and check out the code, because it’s all Ruby.
-> Seriously. Rubinius is just Ruby. Just Ruby. Ruby.
-
-> So dive in and add some features today! If having an awesome alternate Ruby implementation
-> isn’t enough for you, the rbx team will bribe you with special stickers for committers, and sweet
-> black-on-black tshirts for people with 10 commits or more!
-
-[Read all about it on his blog Literate Programming](http://blog.steveklabnik.com/2011/10/04/rubinius-is-awesome.html "Rubinius Is Awesome - Literate Programming").
diff --git a/_posts/2011-10-11-matz-and-me-at-rubyconf-2011.markdown b/_posts/2011-10-11-matz-and-me-at-rubyconf-2011.markdown
deleted file mode 100644
index e101a38..0000000
--- a/_posts/2011-10-11-matz-and-me-at-rubyconf-2011.markdown
+++ /dev/null
@@ -1,13 +0,0 @@
----
-layout: post
-title: Matz and Me at RubyConf 2011
-author: Shane Becker
----
-
-I had a great time at RubyConf 2011 in New Orleans, LA. I saw old friends from all over the world. I met new friends from all over the world. We laughed and shared our dreams with each other. I gave away a huge pile of [super soft t-shirts](http://store.americanapparel.net/tr401.html "Tri-Blend Short Sleeve Track Shirt"). I heard from many of you a pledge to go back to work and deploy something meaningful on Rubinius in production (more on that soon).
-
-Oh, and we took these pictures of me and Matz in the new Rubinius shirt. Altogether, not a bad conference at all.
-
-[](http://www.flickr.com/photos/veganstraightedge/6234562423)[](http://www.flickr.com/photos/veganstraightedge/6234562147)
-
-How was *your* RubyConf?
diff --git a/_posts/2011-10-18-contributing-to-rubinius.markdown b/_posts/2011-10-18-contributing-to-rubinius.markdown
deleted file mode 100644
index f0aac4e..0000000
--- a/_posts/2011-10-18-contributing-to-rubinius.markdown
+++ /dev/null
@@ -1,401 +0,0 @@
----
-layout: post
-title: Contributing to Rubinius
-author: Brian Ford
----
-
-Implementing Ruby is a lot of hard work. The Rubinius project has been lucky
-to have [more than 240 contributors](http://it.isagit.com/rubinius/rubinius),
-many with _hundreds_ of commits, including code, benchmarks, documentation,
-translations, and more. Lately, we have seen a surge of new folks working hard
-on 1.9 language features. While we concentrate on making Rubinius easy to
-contribute to, this post should clarify some things and pave an easier road to
-your first Rubinius commit.
-
-
-### Contributions
-
-Before diving into the Rubinius code, I want to emphasize that there are many
-ways that you can contribute to Rubinius. One of the most valuable for us is
-trying your own library or application on Rubinius. We've worked super hard to
-make using Rubinius in place of MRI as simple as possible. For example, with a
-typical Rails application, here is all you should need to do to get set up:
-
- rvm install rbx
- rvm use rbx
- gem install bundler
-
-Once you've got Rubinius and Bundler installed, running your application
-should be this simple:
-
- cd
- rm Gemfile.lock
- bundle install
-
-Note the step of removing the `Gemfile.lock`. This is necessary to force
-bundler to resolve the dependencies for Rubinius. This is very important. Not
-all gems for MRI will work with Rubinius, and in some cases Rubinius has
-built-in gems or stubs that need to be considered when resolving dependencies
-(ruby-debug and ffi are two examples).
-
-Once `bundle install` is finished, you should be able to start your
-application just like you would under MRI. If you have any trouble, please let
-us know. Issues for Rubinius are [tracked on
-Github](https://github.com/rubinius/rubinius/issues).
-
-Another way to contribute to Rubinius is talking about the project. If you
-tried your application and your 50 gems installed without problems, consider
-[tweeting at us](https://twitter.com/rubinius) or writing up a quick blog post
-about your experiences. If you've done something
-[fancy](http://fancy-lang.org/) that you'd like to share with us, we're always
-happy to have [guest blog
-posts](http://rubini.us/2011/02/23/introduction-to-fancy/), too. We even have
-documentation on [how to write a blog
-post](http://rubini.us/doc/en/how-to/write-a-blog-post/).
-
-
-### Clone & Build
-
-Before we can do anything else, we need to get the Rubinius source code and
-build it. Run the commands below to do this:
-
- git clone git://github.com/rubinius/rubinius.git
- cd rubinius
- ./configure
- rake
-
-You can run Rubinius directly from the build directory, there is no need to
-install it. We provide symlinks for common commands like `gem`, `rake`, `irb`,
-`ri`, `rdoc`, and even `ruby`. Just add `/bin` to your `PATH`.
-
-If you run into any trouble with these steps, see the [Getting
-Started](http://rubini.us/doc/en/getting-started/) page for more information.
-You may need to install libraries required to build Rubinius. If you don't
-find answers there, visit the `#rubinius` channel on freenode.net and we'll
-help you out.
-
-While the build is running, let's get a quick overview of how Rubinius is
-organized.
-
-
-### Code Tour
-
-There are two main divisions in the Rubinius source code. The virtual machine,
-garbage collector, and just-in-time (JIT) compiler are written in C++. The
-Ruby core library, bytecode compiler, and various tools like the profiler and
-debugger are written mostly or all in Ruby.
-
-
-#### Ruby Core Library
-
-The Ruby core library is found in the `kernel/` directory. The kernel is
-divided into subdirectories that are loaded in order when Rubinius boots. The
-divisions were made to help share the Ruby core library with other
-implementations. I'll cover those basic divisions here. For more details about
-how the loading process works, see the
-[Bootstrapping](http://rubini.us/doc/en/bootstrapping/) documentation.
-
-1. `alpha.rb` - Sets up very basic Ruby features needed to start loading the
- rest of the core library.
-1. `bootstrap/`- Contains implementation-specific features needed to load the
- main parts of the core library.
-1. `platform/` - Contains platform-specific features like the FFI
- (foreign-function interface) code that is used extensively in Rubinius to
- bind to standard `libc` functions.
-1. `common/` - Contains the majority of the Ruby core library and the code
- should be implementation-agnostic.
-1. `delta/` - Contains more implementation-specific code that may extend or
- override code from `common/`.
-
-Most of the work on the Ruby core library will be done in `kernel/common/`.
-
-
-#### Rubinius VM
-
-The concept of a virtual machine is somewhat nebulous. It can be hard to draw
-the lines around the different components. In Rubinius, the code for the
-bytecode interpreter, garbage collector, and JIT compiler is under the `vm/`
-directory. There are subdirectories for the garbage collector (`vm/gc/`) and
-the JIT compiler (`vm/llvm/`). The `main()` function is in
-`vm/drivers/cli.cpp`.
-
-One of the important parts of Rubinius are the low-level operations that
-cannot be defined in Ruby. These are things like adding two Fixnums together.
-These operations are called primitives and the code for them is in
-`vm/builtin`. Since you will likely encounter these in the core library, we'll
-delve into them a bit.
-
-
-#### Primitives
-
-All methods that can be called in Ruby are exposed as, well, Ruby methods. If
-you open `kernel/bootstrap/fixnum.rb`, you should see the following code:
-
-{% highlight ruby linenos %}
-def to_f
- Rubinius.primitive :fixnum_to_f
- raise PrimitiveFailure, "Fixnum#to_f primitive failed"
-end
-{% endhighlight %}
-
-The `Rubinius.primitive :fixnum_to_f` code looks like a normal Ruby method
-call but it is not. It's actually a compiler directive to tag this Ruby method
-as having an associated primitive operation. The name of the primitive is
-`fixnum_to_f`. This naming convention is standard, being composed of the class
-name and the method name. Methods in Ruby that are characters, like `+`, are
-given word names for the primitives.
-
-When this method is run, the primitive operation is invoked. If the primitive
-operation fails, the Ruby code following the `Rubinius.primitive` line is run.
-This code can perform any Ruby operation. For example, it may coerce the
-arguments to a particular class and re-dispatch to itself. If no other
-operation is appropriate, the method should raise an exception.
-
-To see how the Ruby method relates to the primitive code, open
-`vm/builtin/fixnum.hpp`:
-
-{% highlight cpp linenos %}
-// Rubinius.primitive :fixnum_to_f
-Float* to_f(STATE);
-{% endhighlight %}
-
-The `vm/builtin/*.hpp` files are processed by the Rubinius build system to
-automatically generate C++ code to resolve and bind these primitive
-operations. The comment provides the link between the Ruby method and the C++
-method.
-
-Finally, the actual implementation of this primitive is found in
-`vm/builtin/fixnum.cpp`:
-
-{% highlight cpp linenos %}
-Float* Fixnum::to_f(STATE) {
- return Float::create(state, (double)to_native());
-}
-{% endhighlight %}
-
-Here you can see that a new Float object is being created from the value of
-the Fixnum. Rubinius names the C++ classes that implement the Ruby primitive
-operations the same as their Ruby counterparts. One of the goals of Rubinius
-is to build an elegant, easily comprehensible system, and we feel that this
-consistency has been a great benefit toward that goal.
-
-Now that we have a basic idea of the structure of Rubinius, let's look at some
-aspects of its runtime behavior, in particular, supporting different Ruby
-language modes.
-
-
-### Language Modes
-
-Rubinius 2.0 (the master branch) implements both 1.8 and 1.9 language features
-in one executable. You can select the language mode at runtime by passing the
-`-X18` or `-X19` flag, either as a command line option or by setting the
-`RBXOPT` environment variable. Both commands below should have the same
-effect:
-
- RBXOPT=-X19 bin/rbx -v
- bin/rbx -X19 -v
-
-If I run that on my system, I will see the following:
-
- rubinius 2.0.0dev (1.9.2 0f223599 yyyy-mm-dd JI) [x86_64-apple-darwin10.8.0]
-
-The default language mode is 1.8, so if you invoke `rbx` with no other
-options, you'll be running in 1.8 mode. You can change the default mode with a
-configure time option as follows:
-
- ./configure --default-version=1.9
-
-If you configure Rubinius to have a default language mode of 1.9, you can
-access 1.8 mode with the `-X18` runtime option as discussed above.
-
-Ok, we've got the code, we understand something about how it is organized,
-we've got the runtime behavior down, now let's look at actually implementing
-Ruby. To do that, we need to know how Ruby behaves, and that is what RubySpec
-is all about.
-
-
-### By the Spec
-
-Rubinius created the RubySpec project to ensure that we would be faithfully
-implementing Ruby behavior, and we are constantly contributing more to it.
-Basically, Rubinius does it by the spec. So, any commit to the Ruby core
-library in Rubinius must either have new specs or make existing specs pass. To
-effectively contribute to Rubinius, you'll need to understand some basics
-about RubySpec. I recommend that you have a read through the documentation at
-[rubyspec.org](http://rubyspec.org/).
-
-RubySpec includes a custom-built framework for the specs called MSpec. The
-syntax is intended to be consistent with [RSpec](http://rspec.info), but there
-are various facilities that are purpose-built to support multiple
-implementations, multiple versions of Ruby, and multiple platforms.
-
-
-#### Running Specs
-
-MSpec provides several different scripts to run the specs under different
-conditions. The default behavior is to simply run all the specs. If you invoke
-the following command, it will run all the Ruby Array specs in the default
-language mode, which should be 1.8 unless you configured 1.9 to be the
-default:
-
- bin/mspec core/array
-
-To Run the specs in 1.9 mode, add the `-tx19` option:
-
- bin/mspec -tx19 core/array
-
-The `-t` option specifies which target to run the specs under. The default in
-Rubinius is to run them with Rubinius, so `-tx` is implied. You can easily run
-with another target by giving the name of an executable on your PATH or the
-full path to an executable. Since the specs are intended to show the behavior
-of MRI, if you are writing new specs you need to run them under MRI 1.8.7 and
-1.9.2. I have those on my PATH, so I can do the following:
-
- bin/mspec -t ruby1.8.7 core/array
- bin/mspec -t ruby1.9.2 core/array
-
-Finally, if you are running `bin/mspec` in the Rubinius source directory, the
-location of the RubySpecs are known (`spec/ruby/`), so you can use the full
-path or the shortened version `core/array` above.
-
-
-#### Continuous Integration
-
-One goal of MSpec is to make it as easy as possible to run the specs for the
-parts of Ruby that have been implemented. It takes a long time to implement
-all of Ruby correctly, but we want to know that the parts we have implemented
-don't get broken while working on other parts. That is the role of continuous
-integration. To use CI effectively, we need to partition the specs into those
-that we expect to pass and those we know we don't pass yet. MSpec provides a
-facility for this, called tagging, that we'll look at shortly. For now, we'll
-just look at running the specs in CI mode.
-
-To run all the Rubinius specs in CI mode under the default language version,
-use the following command:
-
- bin/mspec ci
-
-Likewise, to run these specs in the 1.9 language mode, add the `-tx19` option:
-
- bin/mspec ci -tx19
-
-The `bin/mspec ci` command runs the `mspec-ci` script. You should be familiar
-with this mechanism from working with Git. It's the same idea. The `mspec`
-script itself is just a utility to invoke the various specific MSpec scripts.
-To see the options for `mspec`, run the following command
-
- bin/mspec -h
-
-There are three basic functions that MSpec performs and these correspond to
-`mspec-run`, `mspec-ci`, and `mspec-tag`. When not given an operation, `mspec`
-assumes `run`, so the following two commands are equivalent:
-
- mspec core/array
- mspec run core/array
-
-If the operation is given, it must be the first parameter to `mspec`. In the
-case below, the first command runs `mspec-ci` with `core/array` while the
-second command runs `mspec-run` with `core/array` and `ci` as files.
-
- mspec ci core/array
- mspec core/array ci
-
-Now that we've got the basics of MSpec down, let's look at how we find specs
-that fail on Rubinius. To do this, we'll use the `mspec tag` command.
-
-
-#### Tagged Specs
-
-Since Rubinius uses the tagging mechanism to create the set of CI specs to
-run, the best way to discover what parts of RubySpec that Rubinius isn't
-passing yet is to list the specs that are tagged. There's a command for that:
-
- bin/mspec tag --list fails -tx19 :ci_files
-
-This command lists all the specs that are tagged as failing. There's some new
-syntax here, namely `:ci_files`. MSpec has the concept of pseudo-directories.
-Basically, they are lists of files. The reason for this is that running all
-the core or standard library specs in RubySpec is not as simple as just
-running all the files under `spec/ruby/core` or `spec/ruby/library`. It's more
-complicated than that because there are 1.8- and 1.9-specific libraries.
-Rather than wrapping everything in `ruby_version_is` guards, MSpec adds
-version-specific lists and names them, for example, `:core` and `:library`.
-
-In this case, we're using the list of files specified by `:ci_files`. This
-list excludes some files that are known to cause problems if they are run.
-
-The list of specs that are currently marked as failing is pretty long. We can
-reduce the number of tags we are looking at by giving a smaller set of specs
-to run. For example, let's just run the File specs:
-
- bin/mspec tag --list fails -tx19 core/file
-
-Looking at the output from this command, we notice (at least at the time of
-writing this post) that there are several failures in the
-`File.world_writable?` specs. We can run just these specs:
-
- bin/mspec tag --list fails -tx19 core/file/world_writable
-
-If we look into the documentation for `File.world_writable?`, we'll find that
-it is a new method introduced in 1.9. Excellent, this gives us an opportunity
-to talk about language-specific changes in Rubinius.
-
-
-### Language-specific Changes
-
-When Rubinius boots, it loads different files depending on what language mode
-it is running. In the `kernel/**/` directories, there are `load_order18.txt`
-and `load_order19.txt` files. These files are used during the build process to
-create separate runtime kernels for Rubinius. You can see these in the
-`runtime/18` and `runtime/19` directories after building.
-
-Here's how language-specific features are handled in the Rubinius kernel.
-
-1. If there are no language-specific methods, the name of the file in
- `kernel/common` is the name of the class. In the case here, the file is
- `kernel/common/file.rb`. This rule applies regardless of whether the class
- is 1.8- or 1.9-specific. For example, Rational is part of the 1.9 core
- library, but does not exist in the core library in 1.8. The Rational class
- is in `kernel/core/rational.rb`.
-1. If there are version-specific methods, they go in `kernel/common/file18.rb`
- and `kernel/common/file19.rb`. The correct file is then added to the
- appropriate `load_orderNN.txt` file.
-
-In the case of `File.world_writable?`, there is no 1.8 version. So, we open
-`kernel/common/file19.rb` and add the method definition. After changing any of
-the `kernel/**/*.rb` files, we have to build Rubinius. Run the following
-command to do that:
-
- rake build
-
-After making the change, we verify that the specs pass by running the specs
-_without_ the CI tags:
-
- bin/mspec -tx19 core/file/world_writable
-
-If all the specs pass, then you're ready to remove the CI tags. To do so, run
-the following command:
-
- bin/mspec tag --del fails -tx19 core/file/world_writable
-
-After removing the CI tags, the final step is to ensure that all specs still
-pass. To run all the CI specs in both 1.8 and 1.9 modes, simply do:
-
- rake
-
-If everything passes, you're ready to submit a pull request. All in all, that
-wasn't too bad, right?
-
-One final note, if you are making changes to RubySpec, make separate commits
-in your pull request for changes to `spec/ruby/**/*_specs.rb` and another
-commit for any other Rubinius files. It is fine to commit the removed tags
-with the other Rubinius changes.
-
-
-### Wrapping Presents
-
-The information here should give you everything you need to get your feet wet
-in Rubinius. By the way, today is Evan's birthday. If you're not taking him to
-dinner, why don't you show your appreciation for this fantastic project he
-created by grabbing Rubinius and hacking on some Ruby code. Be safe and have
-fun! We can't wait to hear from you.
diff --git a/_posts/2012-01-04-debugging-rubinius.markdown b/_posts/2012-01-04-debugging-rubinius.markdown
deleted file mode 100644
index 384383b..0000000
--- a/_posts/2012-01-04-debugging-rubinius.markdown
+++ /dev/null
@@ -1,49 +0,0 @@
----
-layout: post
-title: Debugging scary crashes of Rubinius
-author: Dirkjan Bussink
----
-
-Bugs, we all are in the infinite fight of getting rid of them. Sometimes
-they are trivial, other times a bit harder. In this video I'm going to
-show how I have been debugging an issue that caused memory corruption of
-your dear Ruby objects in Rubinius.
-
-### Background
-
-It's a pretty long video clocking at 55 minutes but I'm trying to be
-detailed in the discovery process. I'm explaining the steps I'm taking
-along the way and explaining why I'm taking those.
-
-The real debugging process if of course littered with taking wrong turns
-so please don't think I'm brilliant and able to zoom into the issue
-immediately all the time. The video is not recorded as I was going
-through it the first time, so I exactly knew where I was going and
-which steps to take.
-
-If you want to look up some more information on GDB that I'm using
-in the video, here are some links that explain some of the most
-used commands in the video:
-
-[GDB - Examining data](http://sourceware.org/gdb/onlinedocs/gdb/Data.html)
-[GDB - Setting watchpoints](http://sourceware.org/gdb/onlinedocs/gdb/Set-Watchpoints.html)
-
-During the video there's a part from 8:18 until 11:28 where it's just
-watching a rebuild of Rubinius scrolling by. I'd suggest skipping it
-since it's not very useful. I tried to remove it but after having
-to reencode the video it only grew larger. If anyone has more skills
-to fix that, please let us know!
-
-### Download
-
-You can find the video on Vimeo:
-
-[Watch on Vimeo](http://vimeo.com/34622441)
-
-It's probably best to download the video and play it locally on your
-machine. It's 453 MB so it might take a while.
-
-Please let us know if you find this useful, we might do more of them
-in the future if there's interest!
-
-
diff --git a/_posts/2013-02-26-heroku-cedar-rubinius-2-puma-2-in-three-easy-steps.markdown b/_posts/2013-02-26-heroku-cedar-rubinius-2-puma-2-in-three-easy-steps.markdown
deleted file mode 100644
index 00ee6cb..0000000
--- a/_posts/2013-02-26-heroku-cedar-rubinius-2-puma-2-in-three-easy-steps.markdown
+++ /dev/null
@@ -1,74 +0,0 @@
----
-layout: post
-title: Heroku (Cedar) + Rubinius 2 + Puma 2 in Three Easy Steps
-author: Shane Becker
----
-
-### tl;dr
-
-It's now **[very easy](https://github.com/rubinius/heroku-rbx-puma-rails-app)** to get a [Rails app](https://devcenter.heroku.com/articles/rails3) on [Heroku's Cedar Stack](https://devcenter.heroku.com/articles/cedar) running on [Rubinius 2.0](http://rubini.us "Rubinius : Use Ruby™") and [Puma 2.0](http://puma.io "A Modern, Concurrent Web Server for Ruby - Puma").
-
-
-### The Backstory
-
-The fine folks at Heroku have been adding support for using [Bundler](http://gembundler.com "Bundler: The best way to manage a Ruby application's gems") to [specify which version of Ruby](https://devcenter.heroku.com/articles/ruby-versions) your app uses and even [to specify which Ruby](https://blog.heroku.com/archives/2012/12/13/run_jruby_on_heroku_right_now) it uses.
-
-I've checked in on the progress of using Rubinius with this same method every couple few months for the past year or so. I was always met with the same results... "not quite yet, we're working on it".
-
-Last night I was getting mentally packed for [Waza](https://waza.heroku.com/2013) later this week and decided to check in on the state of things so I could ask the right people the right questions in person when we're all together. Turns out that sometime between last time and this time, they've got things working. Boom diggity! And it's pretty ding-dang easy too! Double boom diggity!
-
-
-### The Build Up
-
-I'm going to assume that if you want to use Rubinius 2.0 that you also have the good sense to want to use Puma 2.0. There are three very simple steps to get up and running with Rubinius 2.0 + Puma 2.0.
-
-#### Step 1
-
-Add the Puma gem to your `Gemfile`.
-
-
-
-
-#### Step 2
-
-Tell Heroku to use Puma as your web server in your `Procfile`.
-
-
-
-#### Step 3
-
-Specify Rubinius as your Ruby engine in your `Gemfile`.
-
-
-
-
-### The Breakdown
-
-Once you've done those things, your workflow is the same as before.
-`bundle update && git commit -am "Double boom diggity!" && git push heroku master`
-
-If you're changing an existing app from Heroku's default Ruby (MRI 1.9.x) to Rubinius, you'll see a message like this when you `git push heroku master`.
-
-
-
-The important lines are `Old: ruby 1.9.3` and `New: rubinius 2.0.0.rc1`. After that, everything the same as before. The bundling starts, etc.
-
-
-### The Outro
-
-That's it. You should now be up and running with Rubinius and Puma!
-
-If you have problems, say something in the comments with a link to a gist with your problem output. If you succeed and get up and running in production, let us in the comments too. Tell the world that you love Rubinius/Puma.
-
-I threw together this [quick and dirty Rails app](https://github.com/rubinius/heroku-rbx-puma-rails-app) from scratch deployed to Heroku to show all this in action. [http://heroku-rbx-puma-rails-app.herokuapp.com](http://heroku-rbx-puma-rails-app.herokuapp.com "Using Rubinius & Puma on Heroku"). I also migrated an existing MRI 1.9.3 app ( [The Farmhouse site](http://farmhouse.la "The Farmhouse in Hollywood, California") ) to Rubinius 2.0 to show the migration is easy too.
-
-
-### The Thank Yous
-
-None of this would be possible without the hard work of [Carl Lerche](https://github.com/carllerche), [Yehuda Katz](https://github.com/wycats/), [André Arko](https://github.com/indirect/), [Terrence Lee](https://github.com/hone) and the other contributors to [Bundler](https://github.com/carlhuda/bundler). And a special thanks to Terrence Lee for his dutiful stewardship of the [Heroku Ruby Buildpack](https://github.com/heroku/heroku-buildpack-ruby/). Once again, the awesome powers of Open Source make great things possible.
-
-
-### The Footnotes
-
-As of this writing "Rubinius 2.0" actually means "Rubinius 2.0.0.rc1" and "Puma 2.0" actually means "Puma 2.0.1". The net result is the same though.
-
diff --git a/_posts/2013-03-13-welcome-dirkjan.markdown b/_posts/2013-03-13-welcome-dirkjan.markdown
deleted file mode 100644
index ab81014..0000000
--- a/_posts/2013-03-13-welcome-dirkjan.markdown
+++ /dev/null
@@ -1,126 +0,0 @@
----
-layout: post
-title: Welcome Dirkjan!
-author: Brian Shirai
----
-
-I am excited to announce that [Engine Yard](https://engineyard.com) is
-sponsoring [Dirkjan Bussink](https://github.com/dbussink) to work on Rubinius!
-
-A long time ago (around 2008) when Dirkjan first showed up in the Rubinius
-project he was still a university student finishing his Masters degree. He let
-me read a draft of his thesis on brain-computer interfaces. Dirkjan has been
-helping out on Rubinius since then. Recently, he's been fixing concurrency,
-garbage collection, and JIT issues.
-
-This week, Dirkjan is working from the Engine Yard office in Portland, OR.
-We've got a list of topics that we're delving into to get ready for several
-technology improvements in Rubinius. We started with a list of five things,
-one for each day. Unfortunately, time always goes faster than we expect so
-we've dropped one topic. I'll blog a summary of our discussions so you get an
-idea of some of the big stuff coming in Rubinius.
-
-Our first discussion was about our inline cache mechanisms. An inline cache is
-used at a method call location to speed up calling a method. The first time it
-is called, the method is looked up. Subsequently, as long as the receiver is
-the correct type, the same method can safely be used. This is a typical
-execution-time versus memory size trade-off. We cache the method we found,
-which saves time looking it up again at the expense of some additional memory
-to store the method. As with all caches, we have to carefully consider cache
-invalidation. Let's use a quick code sample to illustrate the inline cache.
-
-{% highlight ruby linenos %}
-
-class A
- def a
- end
-end
-
-class B < A
-end
-{% endhighlight %}
-
-In the example above, the class `B` inherits from `A`, which provides the method
-`a`. If we call `a` on an instance of `B`, we look up the method and find it
-in `A`.
-
-{% highlight ruby linenos %}
-b = B.new
-b.a
-{% endhighlight %}
-
-Here, in the code representation for the call `b.a`, we store an inline cache
-object. As long as the type of object we see in `b` is the same, we can safely
-call the cached method `a`. However, if the type of `b` changes, for example,
-because we define a method `a` on class `B` itself, we must invalidate the
-cache and look up the method again.
-
-The inline cache can be very important for the speed of the virtual machine
-executing Ruby code. However, the inline cache is also very important for our
-just-in-time (JIT) compiler that generates machine code, completely avoiding
-the VM interpreter. Since the inline cache records the types of the Ruby
-objects seen at the call site, we can use that information in the JIT to
-generate fast code as long as our assumptions about the object type are
-correct.
-
-Since inline caches are so important, Dirkjan and I did a complete review of
-our existing inline caching and analyzed how to improve it. The most important
-thing for improving execution speed is to do less. And the best way to do less
-is to reduce redundancy.
-
-We started our analysis with an enumeration of all the kinds of calls that we
-see in Ruby. This is the list that we made:
-
-* fixed-arity method send
-* variadic method send
-* `respond_to?`
-* `kind_of?`
-* fixed-arity `a.send`
-* variadic `a.send`
-* `super` with explicit arguments
-* `super` with implicit arguments
-* `method_missing`
-
-This list is all kinds of method sends that you can see directly in Ruby code.
-We added to this list a few other things that are not in Ruby code:
-
-* extension API calls
-* method combinations like `A.new` which reduces to `A.allocate.initialize`
-* call_custom (a special Rubinius instruction)
-* primitives (parts of Ruby functionality that must be implemented in the VM)
-
-The next thing we did was look at the method call sites from the perspective
-of the virtual machine. Certain method calls, like `respond_to?` imply certain
-VM operations. This perspective is very important. Sometimes people complain
-that Ruby is too dynamic because you could, for example, alias `respond_to?`
-or `eval` to some other name. Now any attempt to statically analyze Ruby fails
-because you can't know ahead of time what the alias may be. This is actually
-not an issue if you consider the perspective from the VM. No matter what the
-method name is, the ultimate VM operation for looking up a method will
-execute. By associating method call sites with a VM operation, we get more
-insight into how best to structure the inline cache.
-
-The next part of our analysis involved looking at what values are stored in
-the inline cache for the various types we enumerated, and what values are used
-for cache invalidation. The purpose of this analysis is two-fold: correctness
-and performance. We want to ensure that our cache invalidation is correct
-but also not generating false positives (i.e. invalidating cases that are not
-actually invalid). We also want to ensure that storing and updating the data
-in the cache can be done efficiently.
-
-The final part of our analysis concerned the cardinality of the cache. In
-object-oriented code, a method call site may be _monomorphic_ (only one type
-is seen), _polymorphic_ (a small number of different types are seen), or
-_megamorphic_ (a huge number of different types are seen). This perspective
-can be very important for performance and for memory overhead. We don't want
-to waste memory for sites that are monomorphic. Nor do we want the cache to be
-thrashing when many different types are seen.
-
-In summary, we looked at these aspects of inline caches: method call site
-types, VM operations that result from the method call, the kind of data cached
-and cache invalidation, and the cardinality of the method call site. We'll be
-taking the results of our discussion and implementing changes to our inline
-caching over the next few weeks.
-
-If you get a chance, pop into the #rubinius IRC channel on freenode.net and
-say hello to Dirkjan!
diff --git a/_posts/2013-03-19-pdx-summit-recap.markdown b/_posts/2013-03-19-pdx-summit-recap.markdown
deleted file mode 100644
index 990cda0..0000000
--- a/_posts/2013-03-19-pdx-summit-recap.markdown
+++ /dev/null
@@ -1,250 +0,0 @@
----
-layout: post
-title: PDX Summit Recap
-author: Brian Shirai
----
-
-Last week, Dirkjan spent the week with me at the Engine Yard office in
-Portland, OR. We wanted to discuss a variety of topics related to Rubinius
-technology. We started the week by making the following list:
-
-* Inline cache
-* JIT IR
-* Performance of JIT'd code
-* Extension API
-* Concurrency and garbage collection
-
-We spent the week mostly writing a ton of things on the whiteboard, discussing
-them, erasing them, and writing a bunch more. Ultimately, we touched on all
-the topics but we did not get to discussing the extension API in depth, so
-we'll skip that one for now. I've [previously
-blogged](http://rubini.us/2013/03/13/welcome-dirkjan/) about our inline cache
-discussion. Here I'll summarize the rest of our discussions.
-
-
-## Just-in-time Compiler
-
-The just-in-time (JIT) compiler that converts our virtual machine bytecode to
-machine code is a fundamental part of making Ruby fast. It is also one of the
-most complex components of Rubinius. It requires interfacing with the virtual
-machine to get runtime data and coordinating with the garbage collector to
-keep other runtime data structures consistent.
-
-We are able to leverage [LLVM](http://llvm.org) for especially difficult parts
-of machine code generation, like instruction selection, instruction scheduling
-and register allocation. However, the semantics of Ruby are so removed from
-those of the underlying CPU that we have a lot of work we still need to do to
-improve the quality of the machine code.
-
-One important component of this work is the ability to represent operations
-that have Ruby semantics (but are not part of Ruby itself) in a way that we
-can perform transformations on those operations. The "not part of Ruby" is
-actually a bit fuzzy. The concept of object allocation is certainly a part of
-Ruby. But the specific operation of reserving a region in the heap is
-invisible to Ruby.
-
-There are a couple operations in particular that are critical to Ruby
-performance, especially when emitting machine code from the JIT. Those
-operations are type guards and object allocation. If our assumptions for the
-particular type of a value hold, we want to emit the fewest number of guards
-as possible and we want the largest contiguous sequence of machine
-instructions that are valid under a specific guard.
-
-Likewise, if an object is allocated but does not get passed outside of the
-code sequence we are compiling to machine code, and we can see there are no
-other side effects, we may be able to avoid allocating the object. A good
-example of this in Rubinius, where the core library is implemented in Ruby, is
-the ByteArray object that is used by String. A ByteArray is a fixed vector of
-8-bit bytes. If an intermediate operation on a String creates a ByteArray and
-that object isn't used outside the JIT'd method, the JIT should be able to see
-through the object creation and recognize that just some machine bytes are
-being moved around or transformed. The ByteArray allocation can be elided.
-
-These two examples, type guards and object allocation, are just a couple
-things we expect the JIT to do well. There are many others.
-
-Right now, our JIT converts the virtual machine bytecode directly into LLVM
-IR. To support more sophisticated JIT transformations, we need a
-representation in between bytecode and LLVM IR, which is one of the things we
-will be working on.
-
-Another aspect of the JIT that needs an overhauls is the infrastructure around
-running the JIT. It runs on a separate native thread with few synchronization
-points. Since Rubinius has no global lock, and since we need a variety of
-auxiliary threads for system operations (e.g. handling process signals,
-running object finalizers, handling debugger events), we have some
-infrastructure for handling the lifetimes of these auxiliary threads. This is
-a particularly complicated aspect of Rubinius because when Ruby code calls
-`fork()` or `exec()`, the Ruby code knows nothing about these auxiliary
-threads. We have to be careful that state is maintained across these calls.
-This component will be enhanced to better handle auxiliary threads that are
-actually proper Ruby threads (all auxiliary threads are fundamentally Ruby
-threads but not necessarily visible in Ruby). This will permit us to have
-multiple, potentially completely different, JIT threads running
-simultaneously.
-
-
-## Performance
-
-For us as people, when our assumptions fail we often just blunder on making
-fools of ourselves. Too bad we don't have a "check your assumptions" mode as
-useful as the one we build into the JIT. In the JIT, if our assumptions fail
-and we don't catch it, we're going to compute the wrong values or cause the
-wrong actions to be performed.
-
-So, in the JIT, when our assumptions are wrong, we must change course. This
-course change may be to go down a different path in the machine code or to
-exit the machine code entirely and go back to the interpreter. Both paths have
-significant performance implications.
-
-A reason to exit the machine code is that one significant aspect of generating
-fast machine code is proper use of the type guards. If our assumptions about
-the type of a value are wrong, simply exiting back to the interpreter means
-that we don't pollute the LLVM IR with types that can inhibit LLVM
-optimizations from being as effective. On the other hand, there are runtime
-costs associated with both exiting to the interpreter and running the
-interpreter instead of machine code. Also, if we exit the generate machine code
-too often, we may trigger a de-opt, throwing away that version of the machine
-code and requiring the JIT to create a new one.
-
-Another aspect of the performance of the machine code we emit is how we handle
-virtual machine operations. Some aspects of running Ruby require very
-low-level operations that we call primitives. These are coded in C++ and
-interact with internal virtual machine facilities. When compiling machine
-code, we want as few conditionals and as few function calls as possible to get
-the highest performance. Typically, we call a function that performs the
-primitive operation and then returns to the JIT'd machine code. As we move
-more and more things into Ruby itself, it is possible for the JIT to inline
-operations and get the greatest possible optimizations. This is another area
-we will be working on as we improve the JIT.
-
-
-## Concurrency
-
-One of the goals for Rubinius since the very beginning is to provide excellent
-support for concurrency and parallelism in Ruby. We have already removed the
-global interpreter lock (GIL/GVL) from Rubinius. However, we have to ensure
-that we don't replace it with an effective global lock when we implement
-components of the system.
-
-The key to improving lock-freedom throughout the system is to use less locks.
-That may seem obvious, but it is not necessarily that simple. As I mentioned
-above, the virtual machine actually uses a variety of threads internally. And
-with no global lock, any Ruby thread could invoke any virtual machine
-operation, like `fork()`, at any time. Multiple Ruby threads could be calling
-the same method on the same object at the same time. Considering my previous
-post about inline caches, this implies that all sorts of data races and
-concurrency bugs could arise just from calling Ruby methods.
-
-In the virtual machine, we must be careful to ensure correctness under
-concurrent execution. The classical way of doing so is to use locking.
-However, there is tons of research from the '90s about lock-free and wait-free
-algorithms. This academic research is slowly trickling down to industry in
-various domains. We will be using lock-free implementations of various virtual
-machine data structures to improve support for concurrency and parallelism.
-
-
-## Garbage Collection
-
-One particularly challenging area that requires careful control of concurrency
-is the garbage collector. Rubinius provides a generational garbage collector
-with very short pause times when collecting the young generation. The
-generational architecture allows us to only collect a small region of the heap
-instead of the whole heap every time. We also support object allocation using
-thread-local buffers to avoid locking and contention when Ruby code is running
-in parallel.
-
-However, the garbage collector architecture pauses all threads to perform a
-collection. While the pause for a young generation collection is on the order
-of a few milliseconds (5-15 in many cases), there is the overhead of forcing
-all the various threads to pause.
-
-There is only one way to address this issue and that is to make the garbage
-collector concurrent. Fortunately, we can achieve this with some modifications
-to our existing garbage collector. When adding concurrency to the garbage
-collector, we want to avoid slowing down non-garbage-collector operations,
-typically referred to as mutator performance. (Operations in the system can be
-viewed as partitioned into two sets: the heap management--allocation and
-garbage collection, and the operations that mutate the heap--mutator
-operations.)
-
-With modifications to our mature generation collector (based on the Immix
-collector), we can perform partial heap collections and preserve the
-generational benefits while also limiting stop-the-world pauses to specific
-regions of the heap and bounding the pause times.
-
-
-## Semantic Versioning
-
-[Semantic Versioning](http://semver.org/) is a methodology for versioning
-software to support correct dependency management. MRI has never had
-particularly strong support for versioning, with semantic changes being added
-in patch levels (not even visible in the RUBY_VERSION constant) and major
-version increments on special dates completely devoid of semantic relevance.
-
-In Rubinius, we would like to provide a more sound versioning discipline, in
-particular, semantic versioning. However, this raises some significant
-challenges. Let's consider some of the components of Rubinius:
-
-* Ruby language itself in one of three language modes: 1.8, 1.9, and 2.0
-* Ruby core classes
-* Ruby standard library
-* MRI compatibility "C-API" for supporting C-extensions
-* Supporting core classes like ByteArray and Tuple
-* Bytecode compiler
-* Virtual machine instruction set
-* Internal APIs for JIT, garbage collection, concurrency management
-
-The key component on which semantic versioning is based is the public API. But
-what is included in that? Is it just Ruby as covered in RubySpec? Is it also
-our supporting Ruby classes or Ruby facilities like the parser and bytecode
-compiler? Since Rubinius is a language platform used to implement other
-programming languages besides Ruby, resolving these questions correctly is
-important.
-
-Along with a sound versioning discipline, we also want to promote continuous
-delivery of enhancements to Rubinius. Technically, these are compatible goals,
-but require that we consider how to organize our development and source
-branches when we create backward-incompatible API changes.
-
-As we work toward the Rubinius 2.0 release, we will do our best to implement
-semantic versioning. You can help us by testing your applications, gems, or
-libraries on Rubinius. One great place to do this, of course, is [Travis
-CI](https://travis-ci.org/).
-
-
-## All Work and No Play
-
-Portland is a beautiful city. It's not very big but has enough city things to
-feel like a proper city. I didn't want to keep Dirkjan caged in the office all
-day every day, so when the weather looked promising on Friday, we packed our
-concurrency and garbage collection conversation up and headed out. First we
-went to [Portland State University](http://www.pdx.edu/) to attend a talk at a
-programming language club. The talk was on continuation-passing style,
-defunctionalization, and transformations. It was somewhat related to our
-compiler work and it was certainly interesting. But my real motive was to
-introduce Dirkjan to my former coworker [Larry
-Diehl](https://twitter.com/larrytheliquid), who is a PhD student at PSU doing
-fascinating work in dependently typed programming language theory.
-
-After the talk at PSU, we hopped on the MAX light rail and headed toward the
-[Japanese Garden](http://japanesegarden.com/). The bus that would take us the
-rest of the way wasn't due for 25 minutes so we decided to walk. The garden is
-located in Portland's [Washington Park](http://washingtonparkpdx.org/), which
-is located in the west hills of Portland. So, we walked, uphill, for quite a
-while. We walked past the Lewis and Clark monument, through the [international
-rose garden](http://www.rosegardenstore.org/), past the tennis courts and
-finally up another steep hill to the Japanese Garden.
-
-The Japanese Garden is one of the most beautiful and authentic outside of
-Japan. We are very lucky to have it here and my wife and I visit it frequently
-to enjoy the beautiful views and bask in the tranquility. Since it is early
-spring, not many plants were blossoming yet, but we saw some huge koi, some
-water falls, beautiful trees, and a stunning view of Portland. Unfortunately,
-Mt Hood was hiding in the clouds that day.
-
-I'm not much of a photographer, but here are some pics from the trip.
-
-
-
-
diff --git a/_posts/2013-03-20-profiling-jitted-ruby-code-with-oprofile.markdown b/_posts/2013-03-20-profiling-jitted-ruby-code-with-oprofile.markdown
deleted file mode 100644
index 7444213..0000000
--- a/_posts/2013-03-20-profiling-jitted-ruby-code-with-oprofile.markdown
+++ /dev/null
@@ -1,379 +0,0 @@
----
-layout: post
-title: Profiling JIT-ted Ruby code with OProfile
-author: Ryo Onodera
----
-
-You can now profile JIT-ted Ruby code!
-
-Before:
-
- samples % linenr info app name symbol name
- 497 28.7117 instructions.cpp:82 rbx rubinius::MachineCode::interpreter(rubinius::State*, rubinius::MachineCode*, rubinius::InterpreterCallFrame*)
- 460 26.5742 (no location information) anon (tgid:4118 range:0xb581c000-0xb589c000) anon (tgid:4118 range:0xb581c000-0xb589c000)
- # => The dark world of JIT-ted Ruby code
- 158 9.1277 jit_util.cpp:787 rbx rbx_set_local_depth
- 113 6.5280 block_environment.cpp:365 rbx rubinius::BlockEnvironment::call(rubinius::State*, rubinius::CallFrame*, rubinius::Arguments&, int)
- 102 5.8925 (no location information) rbx __x86.get_pc_thunk.bx
- 93 5.3726 jit_util.cpp:848 rbx rbx_push_local_depth
- 71 4.1017 variable_scope.cpp:108 rbx rubinius::VariableScope::set_local(int, rubinius::Object*)
- 68 3.9284 block_environment.cpp:62 rbx rubinius::BlockEnvironment::invoke(rubinius::State*, rubinius::CallFrame*, rubinius::BlockEnvironment*, rubinius::Arguments&, rubinius::BlockInvocation&)
- 52 3.0040 variable_scope.cpp:126 rbx rubinius::VariableScope::get_local(int)
- 47 2.7152 variable_scope.cpp:100 rbx rubinius::VariableScope::set_local(rubinius::State*, int, rubinius::Object*)
- 45 2.5997 kind_of.hpp:153 rbx bool rubinius::kind_of(rubinius::Object const*)
- 24 1.3865 shared_state.cpp:295 rbx rubinius::SharedState::checkpoint(rubinius::ManagedThread*)
-
-After:
-
- samples % linenr info app name symbol name
- 3468 27.0388 instructions.cpp:82 rbx rubinius::MachineCode::interpreter(rubinius::State*, rubinius::MachineCode*, rubinius::InterpreterCallFrame*)
- 3048 23.7642 loop.rb:7 5060.jo _X_Object#forever$block@1
- # => Wow, the name of JIT-ted Ruby code is shown along side C++ function symbols!
- 1044 8.1397 jit_util.cpp:848 rbx rbx_push_local_depth
- 947 7.3834 (no location information) rbx __x86.get_pc_thunk.bx
- 916 7.1417 jit_util.cpp:787 rbx rbx_set_local_depth
- 781 6.0892 block_environment.cpp:365 rbx rubinius::BlockEnvironment::call(rubinius::State*, rubinius::CallFrame*, rubinius::Arguments&, int)
- 639 4.9821 block_environment.cpp:62 rbx rubinius::BlockEnvironment::invoke(rubinius::State*, rubinius::CallFrame*, rubinius::BlockEnvironment*, rubinius::Arguments&, rubinius::BlockInvocation&)
- 421 3.2824 variable_scope.cpp:108 rbx rubinius::VariableScope::set_local(int, rubinius::Object*)
- 389 3.0329 variable_scope.cpp:126 rbx rubinius::VariableScope::get_local(int)
- 326 2.5417 variable_scope.cpp:100 rbx rubinius::VariableScope::set_local(rubinius::State*, int, rubinius::Object*)
- 288 2.2454 shared_state.cpp:295 rbx rubinius::SharedState::checkpoint(rubinius::ManagedThread*)
- 283 2.2065 kind_of.hpp:153 rbx bool rubinius::kind_of(rubinius::Object const*)
-
-In short, you can tell how the machine code that the Rubinius JIT generates
-performs.
-
-Not satisfied yet? Even annotated profile is supported! That means you can even
-know how much time it spends on each line of Ruby code or even on each CPU
-instruction:
-
- /*
- * Total samples for file : "/tmp/loop.rb"
- *
- * 5658 19.9436
- */
-
-
- 718 2.5308 :def increment(i)
- 482 1.6990 : i + 1
- :end
- :
- :def forever
- : i = 0
- 2933 10.3384 : loop do /* _X_Object#forever$block@1 total: 6990 24.6387 */
- 1525 5.3754 : i = increment(i)
- : end
- :end
- :
- :forever
-
-We're using [OProfile](http://oprofile.sourceforge.net/news/), a profiling
-software. In this blog post, I'll show you how to profile using it!
-
-### What's OProfile?
-
-It's a very useful profiling tool available on Linux. It's a sampling-based
-one. That means there is absolutely no change to Rubinius and your Ruby code to
-profile. Just run it as you normally do. Also, the overhead of profiling is
-minimal.
-
-This is contrasted to measuring-based profiling. Rubinius's built-in profiler
-and ruby-prof are both examples of measuring profilers. This means the overhead
-is much bigger and can skew results because of that.
-
-Basically, it works by reporting how many individual profiled items are sampled
-compared to the overall total samples. It doesn't measure elapsed time. It's
-much like top command's individual processes' CPU % usage with far greater
-flexibility. The actual profiled items can be any of C/C++ libraries, C/C++
-functions, C/C++ source code lines, or CPU instructions.
-
-So, OProfile can't usually profile Ruby code because it works on CPU
-instruction level. From OProfile, it can't tell which Ruby source code line
-Rubinius currently executing from the CPU instructions. However, it can profile
-JIT-ted Ruby code because Rubinius compiles it very down into the CPU
-instructions by definition.
-
-OProfile works as a Linux kernel module. So, it's supported only for Linux.
-Sadly, Ubuntu's OProfile and LLVM have bugs relating to this feature.
-Apparently, there is no one using this. So you can say, we are really on the
-cutting edge. ;)
-
-Anyway, we must work around these problems. But how? There are a few options.
-:)
-
-### Setup (PPA: the super simple way; Ubuntu 12.10 only)
-
-I prepared a [PPA](https://launchpad.net/~ryoqun/+archive/ppa) just for you.
-Add it to your system. To be specific, run this:
-
- $ sudo add-apt-repository ppa:ryoqun/ppa
- $ sudo apt-get update
- $ sudo apt-get install oprofile llvm-3.1
- $ sudo apt-get dist-upgrade # Upgrade preinstalled libllvm3.1 to the PPA
-
-By default, Rubinius doesn't use system-provided LLVM, so re-configure Rubinius
-to use it and re-build Rubinius:
-
- $ cd /path/to/rubinius-git-repository
- $ rake clean
- $ ./configure --llvm-config llvm-config-3.1
- $ rake
-
-Done!
-
-### Setup (manual build: the hard way)
-
-If you really want to build LLVM and OProfile manually or if you're using an
-other Linux distribution and the distribution doesn't provide OProfile-enabled
- LLVM packages, manually build LLVM and OProfile like this:
-
-(I tested this on Ubuntu 12.10. Minor adjustments may be needed to build on
-your environment)
-
-Build and Install OProfile:
-
- $ sudo apt-get build-dep oprofile # do equivalent thing on your distro.
- $ cd /path/to/working-dir-to-build-things
- $ wget http://prdownloads.sourceforge.net/oprofile/oprofile-0.9.8.tar.gz
- $ tar -xf oprofile-0.9.8.tar.gz
- $ cd oprofile-0.9.8
- $ ./autogen.sh
- $ ./configure --prefix /usr # LLVM has a build issue. So install to /usr
- $ make
- $ sudo make install
- $ adduser oprofile # this is needed for profiling JITted code
- $ opreport --version
- # => opreport: oprofile 0.9.8 compiled on Mar 8 2013 00:57:08
-
-Build LLVM with OProfile support enabled and rebuild Rubinius:
-
- $ sudo apt-get build-dep llvm # do equivalent thing on your distro.
- $ cd /path/to/working-dir-to-build-things
- $ wget http://llvm.org/releases/3.2/llvm-3.2.src.tar.gz
- $ tar -xf llvm-3.2.src.tar.gz
- $ cd llvm-3.2.src
- $ ./configure --enable-optimized --disable-assertions --with-oprofile
- $ make
- $ sudo make install
-
-If the compilation of `OProfileWrapper.cpp` fails like this:
-
- OProfileWrapper.cpp: In member function ‘bool llvm::OProfileWrapper::checkForOProfileProcEntry()’:
- OProfileWrapper.cpp:141:62: error: ‘read’ was not declared in this scope
- OProfileWrapper.cpp:142:24: error: ‘close’ was not declared in this scope
-
-Apply this patch, then, re-`make` and continue:
-
- diff --git a/lib/ExecutionEngine/OProfileJIT/OProfileWrapper.cpp b/lib/ExecutionEngine/OProfileJIT/OProfileWrapper.cpp
- index d67f537..7c0d395 100644
- --- a/llvm-3.1-3.1/lib/ExecutionEngine/OProfileJIT/OProfileWrapper.cpp
- +++ b/llvm-3.1-3.1/lib/ExecutionEngine/OProfileJIT/OProfileWrapper.cpp
- @@ -29,6 +29,7 @@
- #include
- #include
- #include
- +#include
-
- namespace {
-
-
-Phew, finally rebuild Rubinius!:
-
- $ cd /path/to/rubinius-git-repository
- $ rake clean
- $ rm -rf vendor/llvm # If you build Rubinius with vendorized LLVM.
- $ ./configure
- $ rake
-
-### Start OProfile
-
-OProfile can be configured by a command called `opcontrol`, not by a
-configuration file, which are common.
-
- $ sudo opcontrol --deinit
- $ sudo modprobe oprofile timer=1 # Needed only inside VirtualBox VMs
- $ echo 0 | sudo tee /proc/sys/kernel/nmi_watchdog
- $ sudo opcontrol --no-vmlinux
- $ sudo opcontrol --separete all
- $ sudo opcontrol --start
- $ sudo opcontrol --dump # Flushes buffered raw profile data
- $ opreport --merge all --threshold 1 # Prints the report of profile
-
-Setup is complete if you see an output from `opreport` like this:
-
- CPU: CPU with timer interrupt, speed 1858.39 MHz (estimated)
- Profiling through timer interrupt
- TIMER:0|
- samples| %|
- ------------------
- 92127 67.6157 no-vmlinux
- 21920 16.0880 rbx
- 7950 5.8348 libc-2.15.so
- 4068 2.9857 runner
- 3429 2.5167 libstdc++.so.6.0.17
- 2139 1.5699 cc1
- 1416 1.0393 vm
-
-Congratulations!
-
-### Run Ruby code!
-
-To annotate Ruby code correctly, your current directory must be the top
-directory of the Rubinius git repository:
-
- $ cd /path/to/rubinius-git-repository
- $ ./bin/benchmark ./benchmark/core/hash/bench_access.rb
-
-### Generate profile report
-
-Let's check the profile report of the above benchmark.
-
-NOTE: try to run `opcontrol --dump` at least once while running Rubinius if
-JIT-ted Ruby code doesn't show in the profile report. OProfile automatically
-dumps periodically, but if your Ruby process terminates too quickly, you
-should manually run `opcontrol --dump` while it's still alive.
-
- $ sudo opcontrol --dump && sudo opjitconv /var/lib/oprofile/ 0 0
- $ opreport --merge all --threshold 1 image:./bin/rbx --symbols --debug-info \
- > /tmp/hash-access-symbols
- $ opannotate --merge all --threshold 0.5 image:./bin/rbx --source \
- > /tmp/hash-access-source
-
-I'll omit but you can generate profile report of annotated assembly by passing
-`--assembly` to `opannotate` instead of `--source`.
-
-### Reset current profile
-
-By default, OProfile keeps the profile data indefinitely. To reset it, run
-this:
-
- $ sudo opcontrol --reset
-
-### How to read the profile result
-
-Open `/tmp/hash-access-symbols`, the content should be like this:
-
- CPU: CPU with timer interrupt, speed 1860.42 MHz (estimated)
- Profiling through timer interrupt
- samples % linenr info app name symbol name
- 3571 31.5990 (no location information) no-vmlinux /no-vmlinux
- 619 5.4774 bench_access.rb:16 8295.jo _X_Object#__block__$block@7
- 599 5.3004 bench_access.rb:24 8295.jo _X_Object#__block__$block@11
- 531 4.6987 bench_access.rb:8 8295.jo _X_Object#__block__$block@1
- 457 4.0439 (no location information) rbx __x86.get_pc_thunk.bx
- 318 2.8139 jit_util.cpp:787 rbx rbx_set_local_depth
- 298 2.6369 bench_access.rb:42 8295.jo _X_Object#__block__$block@20
- 277 2.4511 object.cpp:362 rbx rubinius::Object::hash(rubinius::State*)
- 236 2.0883 jit_primitives.cpp:4494 rbx jit_stub_object_hash
- 236 2.0883 tuple.cpp:36 rbx rubinius::Tuple::put(rubinius::State*, int, rubinius::Object*)
- 222 1.9644 inline_cache.cpp:696 rbx rubinius::InlineCache::check_cache_poly(rubinius::State*, rubinius::InlineCache*, rubinius::CallFrame*, rubinius::Arguments&)
- 197 1.7432 jit_util.cpp:848 rbx rbx_push_local_depth
- 187 1.6547 variable_scope.cpp:126 rbx rubinius::VariableScope::get_local(int)
- 179 1.5839 compiledcode.cpp:212 rbx rubinius::CompiledCode::specialized_executor(rubinius::State*, rubinius::CallFrame*, rubinius::Executable*, rubinius::Module*, rubinius::Arguments&)
- 162 1.4335 hash.rb:220 8295.jo _X_Hash#key_index@15
- 147 1.3008 hash.rb:325 8295.jo _X_Hash#values_at$block@13
- 143 1.2654 object.cpp:400 rbx rubinius::Object::hash_prim(rubinius::State*)
- 137 1.2123 (no location information) libc-2.15.so /lib/i386-linux-gnu/libc-2.15.so
- 127 1.1238 variable_scope.cpp:100 rbx rubinius::VariableScope::set_local(rubinius::State*, int, rubinius::Object*)
- 111 0.9822 inline_cache.cpp:576 rbx rubinius::InlineCache::check_cache_reference(rubinius::State*, rubinius::InlineCache*, rubinius::CallFrame*, rubinius::Arguments&)
- 108 0.9557 vm.cpp:175 rbx rubinius::VM::new_object_typed_dirty(rubinius::Class*, unsigned int, rubinius::object_type)
- 99 0.8760 vm.cpp:207 rbx rubinius::VM::new_young_tuple_dirty(unsigned int)
- 97 0.8583 array18.rb:6 8295.jo _X_Array#map@12
- 93 0.8229 integer.cpp:84 rbx rubinius::Integer::from(rubinius::State*, int)
- 90 0.7964 hash.rb:137 8295.jo _X_Hash#[]@23
- 76 0.6725 array.cpp:205 rbx rubinius::Array::set(rubinius::State*, int, rubinius::Object*)
- 72 0.6371 linkedlist.cpp:27 rbx LinkedList::remove(LinkedList::Node*)
- 68 0.6017 tuple.cpp:64 rbx rubinius::Tuple::create(rubinius::State*, int)
- 57 0.5044 method_primitives.cpp:12327 rbx rubinius::Primitives::object_hash(rubinius::State*, rubinius::CallFrame*, rubinius::Executable*, rubinius::Module*, rubinius::Arguments&)
-
-As you can guess, symbol names beginning with `_X_` is the JIT-ted Ruby code.
-Many Ruby benchmark blocks are JIT-ted (like
-`_X_Object#__block__$block@7` at `bench_access.rb:16`) and listed near the top.
-Also, `_X_Array#map@12` is a JIT-ted code of `Array#map`. I'll explain the
-format of the report using it as an example:
-
- 97 0.8583 array18.rb:6 8295.jo _X_Array#map@12
-
-`97` is the number of counts OProfile found what Rubinius was executing, while
-periodically sampling it.
-
-`0.8583` is the percentage to the total number of samples OProfile collected.
-Note that summing all entries up doesn't equal to 100%, because `opreport` only
-reported the top part of whole profile result (by `--threshold 0.5`).
-
-[`array18.rb:6`](https://github.com/rubinius/rubinius/blob/1d7d7b2e2880478776476089d4dd93fd97aff122/kernel/bootstrap/array18.rb#L6)
-is the source location where this method is defined (this is same as
-`Method#source_location`).
-
-`8295.jo` is a special `app name` for JIT-ted code. Usually `app name` is the
-name of file C/C++ functions reside in (shared libraries or executables).
-So, for normal Rubinius' C++ functions, `app name` is just `rbx` because they
-reside in `./bin/rbx`. For JIT-ted Ruby code, there can be no meaningful `app
-name`, because JIT-ted Ruby code is generated at runtime and they reside in no
-file, but only in memory. So, OProfile uses `*.jo` as `app name` in such cases.
-And, `8295` means this is profiled when running the process of PID 8295.
-
-`_X_Array#map@12` is the name of symbol for this entry of profile report
-(duh!).
-
-Open `/tmp/hash-access-source`, the content should be like this (I'll omit some
-unimportant part, because this file is big):
-
- /*
- * Total samples for file : "kernel/common/hash18.rb"
- *
- * 4870 12.8904
- */
-
- 19 0.0503 :
- :# -*- encoding: us-ascii -*-
- :
- :class Hash
- :
- : include Enumerable
- :
- ...
- :
- : class Bucket
- : attr_accessor :key
- :
- 633 1.6755 : def match?(key, key_hash) /* _X_Hash::Bucket#match?@16 75 0.1985, _X_Hash::Bucket#match?@16 45 0.1191, total: 120 0.3176 */
- 40 0.1059 : case key
- 218 0.5770 : when Symbol, Fixnum
- 319 0.8444 : return key.equal?(@key)
- : end
- :
- : @key_hash == key_hash and (Rubinius::Type::object_equal(key, @key) or key.eql?(@key))
- : end
- : end
- ...
- :end
- ...
-
-You might wonder why `Hash::Bucket#match?` has so many counts while this didn't
-appear in the report for symbols. The reason is that the method is inlined to
-each its callers (maybe many top-appearing JIT-ted Ruby blocks). How cool this
-is! You can really know which Ruby code is actually taking too much time.
-
-### My last favor
-
-I wish the official Ubuntu packages are fixed and there is no need to add any
-PPA. I want it-just-works. I reported affecting bugs to Ubuntu's bug tracking
-system. So, please vote it up for fixing (vote them with "affects you?",
-please!!):
-
-- [Bug 1154025](https://launchpad.net/bugs/1154025) Install PIC version of libbfd.a
-- [Bug 1148682](https://launchpad.net/bugs/1148682) symbol lookup error: /usr/lib/libopagent.so: undefined symbol: bfd_init
-- [Bug 1148529](https://launchpad.net/bugs/1148529) OProfile support is disabled
-
-### Further profiling
-
-There is new profiling tool on Linux: `perf` and `operf` (OProfile's new
-command). I don't know them well, but certainly they will be useful for
-profiling Rubinius.
-
-As a last note, this is partially based on [Unladen Swallow's
-information](http://code.google.com/p/unladen-swallow/wiki/UsingOProfile)
-of profiling LLVM-based JIT-ted code by OProfile.
-
-Happy profiling!
diff --git a/_posts/2013-05-21-more-ruby-transparency.markdown b/_posts/2013-05-21-more-ruby-transparency.markdown
deleted file mode 100644
index baae07c..0000000
--- a/_posts/2013-05-21-more-ruby-transparency.markdown
+++ /dev/null
@@ -1,165 +0,0 @@
----
-layout: post
-title: Better access to runtime information from Ruby
-author: Dirkjan Bussink
----
-
-Rubinius has always tried to provide a lot of information to you as a
-developer about runtime information. Things like the variable scope and
-constant scope are already available. In this post I'd like to describe
-a small new API that is available for even more information.
-
-### Inline caching
-
-One of the important mechanisms in making your Ruby code fast is doing
-inline caching. Inline caching means that we store the result of a method
-lookup a specific call site.
-
-So what is a call site you might ask? Well, that's every place in your
-code where a method is called. So take for example the following
-snippet.
-
-{% highlight ruby linenos %}
-
-class Foo
- def bar
- @foo.quz
- end
-end
-
-{% endhighlight %}
-
-Here `@foo.quz` is a call site, so the place where quz is called. What we
-do here is cache the type of `@foo` and store which method to execute for
-this type.
-
-The fact that inline caching works well is based on the idea that at
-runtime for most call sites the receiver type never changes. So in this
-case it means that `@foo` is always of the same type. This is
-called a monomorphic call site.
-
-Of course there are cases where this reasoning doesn't apply. If we see
-multiple types at a certain call site, it's called a polymorphic call site.
-For this we store things in a different object and Rubinius currently stores
-up to 3 different types in that case.
-
-It might be surprising to some, but these cache objects are also just
-Ruby objects. This means that they can be used just like any other Ruby
-object and be inspected for example. So there are objects for an empty
-call site, for monomorphic and also polymorphic sites.
-
-There is also a specialized site for places where we call `respond_to?` since that
-happens often enough to warrant a special case. In the future there
-might be new types introduced such as a specific type for `send` calls.
-
-### Accessing inline caches stored at call sites
-
-So now that we have described all this, how do we get access to this
-information? It is actually pretty straightforward and builds on other
-things already available.
-
-Under the hood, all Ruby code in Rubinius gets translated into a
-`CompiledCode` object, which also provides the API for getting access to
-inline caches. One way to get access to the `CompiledCode` object is to
-grab it through Ruby's Method API.
-
-{% highlight ruby linenos %}
-
-class Foo
- def bar
- @foo.quz
- end
-end
-
-f = Foo.new
-compiled_code = f.method(:bar).executable
-compiled_code.call_sites.each do |cs|
- p cs # #
-end
-
-{% endhighlight %}
-
-What you can see here is that we have one call site located at `script.rb`
-on line 3 (which is the class definition). Currently it's of the type
-`CallSite`, which means that it has a basic structure in place with no
-additional information because this method was never called. This can
-also be inferred from the (0) at the end which indicates the number of
-calls through this object.
-
-So if we make sure we call this at least once, we should be able to see
-this information.
-
-{% highlight ruby linenos %}
-
-class Foo
- def bar
- @foo.quz
- end
-end
-
-f = Foo.new
-begin
- f.bar
-rescue
-end
-
-compiled_code = f.method(:bar).executable
-compiled_code.call_sites.each do |cs|
- p cs # #>
-end
-
-{% endhighlight %}
-
-What we do here is actually run this inside a begin / rescue clause
-because the call will fail because @foo being nil. But this will also
-show that we can actually cache that this will run the `method_missing`
-method and that we cache that.
-
-What you can see here is that we have a `MonoInlineCache`, because we've
-only seen one type for `@foo`, which is `nil` so the receiver class is
-`NilClass`. The `stored_module` is the module the saved method is in, which
-in this case is `Kernel`. The actual method stored is the `method_missing`
-method here. We can also see it has been called 1 time so far.
-
-### Caveats
-
-Currently you get these objects back and you can actually modify them.
-Modifying them at the moment would actually result in undefined
-behavior. You can't do this easily though since they only provide
-accessor readers, but since it's Ruby you can of course hack around with
-`instance_variable_set` for example.
-
-You can probably do really crazy stuff with this, if it crashes the vm
-it's probably a bug, otherwise you're pretty much on your own when
-hacking this.
-
-Another thing is that the counters are not guaranteed to be accurate.
-This can mainly happen when the JIT kicks in. The JIT doens't update
-counters if it inlines methods so that way the method could be called
-more often than you'd think based on the counter. If it's zero though,
-you can be sure it has been never called since it will always go through
-the interpreter path first.
-
-### Future
-
-So besides for fun and crazy, what is this actually useful for? Well,
-first of all we already use it to actually test in Ruby whether our
-inline caches work properly. This made testing this a lot easier and we
-can easily verify that an empty call sites turns into a monomorphic
-cache and subsequently in a polymorphic one if needed.
-
-Another reason this can be very useful is for building better tools.
-With this information, it would be possible to create better
-refactoring tools for example. The information provided here gives you
-insight into which methods are bound where and could help perhaps in
-renaming things.
-
-It would also be interesting to gather this information from your
-runtime application, so you could see which code does and doesn't get
-executed in your production environment. All these things are just
-ideas, but API's like the one discussed here make these future
-developments possible and allow for more insight in your Ruby code.
-
-So play with and let us know what you've done with it!
diff --git a/_posts/2013-06-22-concurrent-garbage-collection.markdown b/_posts/2013-06-22-concurrent-garbage-collection.markdown
deleted file mode 100644
index e69c67f..0000000
--- a/_posts/2013-06-22-concurrent-garbage-collection.markdown
+++ /dev/null
@@ -1,706 +0,0 @@
----
-layout: post
-title: Concurrent garbage collection
-author: Dirkjan Bussink
----
-
-Just a few days ago my work on making the Rubinius garbage collector more
-concurrent has landed in Rubinius master. In this post I'll describe how
-this work was done and what the ideas behind it and pitfalls encountered
-are. Hopefully after reading this post, you'll better understand what
-concurrent garbage collection means for your Ruby programs and how they
-operate. Note that I have explicitly chosen to keep things like benchmark
-and performance numbers out of this post - it is long enough as is.
-
-### In the beginning there were long pauses
-
-Garbage Collection pauses: anyone with a somewhat complex app usually
-knows about them. They often result in wildly varying performance of
-your web requests and cause performance issues in unexpected
-situations. There has been a lot of effort put towards working around
-these issues, such as out of band garbage collection done with servers
-such as Unicorn and Passenger. Honestly, I think these techniques are
-very useful but in essence still workarounds because of a deeper
-problem in MRI.
-
-With this work on concurrent garbage collection, long pauses are a
-thing of the past in Rubinius. You can run a single process application
-server and see stable and fast performance in highly concurrent scenarios.
-
-So for this post I'll first introduce some fundamental concepts that we
-needed to make explicit in Rubinius to support concurrent garbage
-collection. After that I'll discuss some of the issues encountered when
-stress testing and putting Rubinius under load with applications such as
-Rails and Sidekiq. Often there will be a reference to a commit, this is
-because commits won't change, but code can. This makes sure this is still
-correct and relevant even when things are changing in the future.
-
-### The tri-color invariant
-
-For people having some knowledge about garbage collection theory, the
-term tri-color invariant probably sounds familiar. It is a term that
-describes a property of the system that is important in being able to
-garbage collect properly without for example cleaning up used data.
-
-The tri-color invariant defines three different states for an object:
-white, grey and black. Each of these states describes the state of an
-object during a garbage collection phase.
-
-**White objects** are objects that the garbage collector hasn't seen yet
-and doesn't know about yet. It might be found in the future, or it might
-not if it's actually garbage and not a reachable object.
-
-**Grey objects** are objects that the garbage
-collector has seen, but hasn't completely handled yet. By handling I
-mean that this object has not been completely scanned for references to
-other objects. This means for example that we haven't visited the class
-or instance variables table in Rubinius.
-
-**Black objects** have been seen by the garbage collector
-and also has been scanned. This means that this object is handled and
-doesn't need to be revisited again during the current phase.
-
-Garbage collection works in different phases. The first phase is to
-start and mark objects known as roots. Roots are objects that we define
-as always reachable and who should never be cleaned up. One example
-of these in Rubinius are the built-in classes. We never want to garbage collect
-Module, Class or Object. Another group of root objects are the objects
-currently on the stack when we garbage collect. These might be used still
-after the garbage collection finishes and the application continues to run.
-
-When we start the garbage collection cycle, we make the roots grey. This
-is done in Rubinius by marking them and adding them to a list of objects
-that are going to be scanned in the future. This allows us to do garbage
-collection without having to use recursion here, which could lead to very
-deep call stacks and potential stack overflows.
-
-When we have done this, we start handling the so called mark stack. We
-pop off an object and scan it. This makes the object implicitly black,
-because it is marked and no longer in the mark stack. It is important to
-realize that the invariant colors are not always explicit states, but
-sometimes implied by the total system state. They are a tool for
-reasoning about garbage collection, not a design for how you must write
-an algorithm.
-
-During the scanning of an object we might encounter new ("white") objects.
-We mark them and add them to the mark stack as well, thus making them grey.
-This process of handling the mark stack continues until the entire mark
-stack is empty. At that point we know that all the reachable objects are
-now black and the remaining objects can be cleaned up.
-
-From these steps you can see the following invariant:
-
-> "A black object never points to a white object, but always only to grey or other black objects."
-
-This invariant is important because if it were to be violated, we would clean
-up a white object if it would be never marked. But that would mean the
-black object would refer to garbage instead of a valid object.
-
-### Tri-color invariant and concurrency
-
-Maintaining the tri-color invariant is important for correctness. If you
-look at the reasoning in the previous section, you might already realize
-where violation of the invariant might happen in a concurrent scenario.
-
-The simplest example is the following. When we start to handle the mark
-stack, we scan objects and make them implicitly black. Now imagine the
-case where our code (that still runs during GC) writes an unseen white
-object into that already scanned black object. In this case we can't
-guarantee the tri-color invariant because our application might change
-things behind our back without the garbage collector knowing about it.
-
-So the question is, what would be a solution for this problem? Well, the
-obvious thing would be to make sure we run some additional checks when
-we encounter the scenario of a white object being writing into a black
-object. This means, however, that we have to make sure we can catch all
-these cases where this happens. What if somewhere in the virtual machine
-we would assign a variable and not run this code? It would mean breaking
-the invariant and that leads to memory corruption down the road.
-
-This situation represents a triumph in the history of Rubinius engineering -
-because the VM already had a Generational GC and no global interpreter
-lock, the work that went toward making the GC concurrent was much simpler.
-Let's try to understand why.
-
-### The write barrier
-
-In generational collection, we have a problem that is somewhat similar
-to the tri-color invariant problem here under concurrent garbage
-collection. Generational garbage collection stems from the "weak generational
-hypothesis" which states that "objects tend to die young." One
-obvious example of this can be found in Rails. The objects loaded in
-your Rails app often consist of two classes of objects.
-
-The first class of objects are all the objects that define your app. For
-example the class definitions of your controllers and models, but also
-templates for your views. These objects stick around for the entire
-lifetime of your application. The second class of objects are the ones
-allocated when you handle a request. They only live for the lifetime
-of the request, so if you would only garbage collect those objects after
-a number of requests, you would already prevent any memory growth.
-
-This is a very simple example of the generational hypothesis and why
-generational garbage collection works well on workloads like Rails. But
-I said that this suffers from a similar problem as the tri-color
-invariant violation, so what is that problem?
-
-The problem occurs if you cross the barrier between young and old
-generations. For example you store a new object into a long existing
-array. That array is part of the mature generation. What you don't want
-to happen is that when we clean up the young generation, we miss this.
-If we would, the array would suddenly contain garbage and no longer a
-valid object. This means that also for this problem we need to run an
-additional check when writing an object into another object.
-
-The code running these checks is called a write barrier, because it's a
-piece of code that is being run on each write of object into another
-object. What exactly this code is depends on the use
-case. We have already described two of them now, one for generational
-and one for concurrent garbage collection.
-
-### The remember set
-
-So we've just discussed the write barrier. It also stated that we
-already have a write barrier for generational collection. For some of
-the issues mentioned later on, the generational concerns are also of
-significance, so it's useful to also explain the concept of the remember
-set.
-
-The remember set is a set of objects that is used to scan for young
-objects during a generational collection. This is needed for the cases
-where we store a reference to a young object into a mature object. What
-we do is store the mature object in the remember set, so we can scan it
-when we do a young collection. This makes sure we follow all the paths
-which through a young object is reachable.
-
-### Changing the write barrier for concurrent GC
-
-So we need to be able to run some code when we are writing a white
-object into a black one during generational garbage collection. Because
-we already have a write barrier, we should have a single place where we
-can change this.
-
-Well, that was not entirely true. As part of implementing the concurrent
-garbage collection solution, I also cleaned up some of the internals to
-unify for example our usage of write barriers. It wasn't a terribly
-daunting task, since the logic was already there, just that we had the
-logic in more than one place. If you want to take a look at what this
-work was, I'd suggest taking a look at the diff here:
-
-[Unify write barrier access](https://github.com/rubinius/rubinius/commit/c426e7bdfea54a742fc598d104a5fd756db27a6a "Unify write barrier access")
-
-If you read through the commit, you can see it actually removes more
-code than it adds, because it cleans up and unifies the usage of the
-write barrier.
-
-So this brings us to the next point of how to change the write barrier.
-What we need to do is to make sure we guard the case where we store a
-white object into a black object. If we detect this scenario, there are
-basically two possible strategies. The first one is the make the white
-object grey by marking it. This means we will scan it in the future. The
-other option is to make the black object grey again, so we scan that
-again in the future.
-
-The first solution has the advantage of moving the collection forward,
-not backward like the second solution. It does however have the downside
-that it could keep objects alive longer than the second solution would.
-In the implementation for Rubinius we've chosen the first option,
-mainly because it proved to be the simplest to implement and it moves
-the so-called wavefront forward.
-
-The other thing we need for this check is to know whether an object is white,
-grey or black. As you might remember, I've said before that these states
-might not be explicitly modeled. This was actually the case in
-Rubinius. There was a way to determine that an object was black, namely
-when it was marked but not in the mark stack anymore. The first check is
-easy and cheap, but the second check isn't. We would have to scan the
-entire mark stack for an object if we want to write another one into it.
-This would quickly become really expensive and isn't a good solution.
-
-### Introducing a new garbage collection state
-
-The only way to really tackle this problem is to introduce a new state
-for an object, so we can easily see that it's already scanned, not only
-just marked.
-
-For this I also have to take a sidestep and explain another concept,
-namely the rotating mark concept. If you look at how to track the state
-during the mark phase, there are a few solutions. The easiest one is to
-have a single bit to identify whether we've marked an object or not.
-This comes with a downside though, that we have to make sure we set all
-the marks back to 0 before we start a garbage collection, or at the end
-of a garbage collection so it's 0 for the next cycle.
-
-To prevent this overhead, there is a concept called a rotating mark.
-It's actually very simple, instead of having a mark of 0 or 1, we have
-0, 1 and 2. When an object is new, it still has a mark of 0. The first
-time when we garbage collect, we use 1 as the mark. This means we can
-clean up all the objects afterwards which don't have mark 1.
-
-The second time we swap the mark to 2 and do the same thing. We can
-remove anything with a mark that is not 2 after the collection cycle.
-This is a concept that the garbage collection in Rubinius already used
-before these changes. So what we did was extend the mark bits to also
-include the scanned state. Rubinius uses the object header to store
-this information inside the object and we had a few more bits of room
-to store additional information.
-
-We could have solved this basically in two ways, one would be to just
-use a single bit as the scanned state. This would work fine, but it
-would make updating the header with this bit more expensive in certain
-concurrent scenarios, where we would end up doing a compare and swap
-operation twice instead of once.
-
-Therefore we opted for merging it with the mark bits. This means that
-instead of 2 bits to store 0, 1 or 2, we now use 3 bits to store 0, 2,
-3, 4 or 5. Why is 1 not used you might ask? Well, that is a side effect
-of the combination of a rotating mark and the scanned state.
-
-The scanned state is actually represented in the last bit. So a value of
-1 would mean the object is scanned, but not marked. Since we always
-first mark an object before scanning, this scenario can't happen. The
-values 2 and 4 mean the object is only marked, the values 3 and 5 mean
-the object is marked and scanned. These values also make the operations
-for checking if a mark is set and setting the scan state simple.
-
-You can find the code that introduces this new state in the following
-commit:
-
-[Introduce explicit scanned state for mature GC](https://github.com/rubinius/rubinius/commit/d1d99d6048a01f1687080f98baa904d4562ed920 "Introduce explicit scanned state for mature GC")
-
-### A new version of the write barrier
-
-So with this new addition, we actually have the tools at hand to change
-the write barrier so we can handle this new case for the concurrent
-garbage collection. So besides checking the generations of the objects,
-we now also have to check the newly introduced scanned state, which
-represents the black state in the tri-color invariant. If the object we
-write into is already black and the object to be written is white, we
-store this object in a separate set.
-
-This set is then in the finalization phase of the concurrent garbage
-collector used. How this works exactly will be explained later, for now
-it's important to remember that objects in this set will be marked in
-the future.
-
-The new version of the write barrier can be found here in this commit:
-
-[Update write barrier with checking for scanned objects](https://github.com/rubinius/rubinius/commit/bcecb3103d450502bd43a3411461381f5452a7e0 "Update write barrier with checking for scanned objects")
-
-As you see, it also incorporates more changes, mainly the addition of
-the before mentioned set and changes to the JIT. The changes to the JIT
-are necessary because the JIT basically emits the assembly code for the
-write barrier directly, so it also needs to emit the new version of the
-code.
-
-There is one thing here that might strike some as surprising. That is
-the fact that we actually set the scanned state before scanning the
-object. This is not a bug, but deliberate, since otherwise there is a
-race condition possible. The race condition would be that a scan of on
-object is in progress while another thread runs the write barrier for
-that same object. In that case it could see the object as not scanned,
-and not store the new reference. The other thread would then mark the
-object as scanned, but it would still have a white object stored. This
-would violate the tri-color invariant and cause corruption.
-
-By setting the scanned state as the first operation, the only risk is
-perhaps adding an element unnecessary due to a race condition, but this
-isn't problematic but just a minor increment in the amount of work.
-Since this only happens with this race condition, this case is so small
-it doesn't cause any performance issues.
-
-### The actual concurrent garbage collection
-
-So with these pieces put into place, I was kind of surprised. It only
-had taken very little work to add these new concepts, a testament I
-think to the design that Evan and Brian originally started. Most of you
-probably know the feeling where you start to implement a seemingly
-daunting feature, but after starting it everything falls into place so
-easily you feel something must be wrong. Of course at this point it did
-take me longer to finish the work, but luckily not because of
-fundamental problems with the approach, but just with bugs for certain
-edge cases.
-
-So with this initial surprise out of the way, let's see how the basic
-algorithm works. The first thing that is important to realize, is that
-this is a mostly concurrent garbage collection, so it's not 100%
-concurrent. There are still stop the world pauses, but they are much
-smaller than with a complete stop the world collection.
-
-These stop the world pauses are needed to get a consistent view of the
-roots to start collection from and to finish it all up to get another
-consistent snapshot of the system. So what we do is trade one big stop
-the world pause for two much smaller ones.
-
-During the first stop the world, we do the same thing we did before to
-setup the initial state to start collection with. After this is done, we
-signal all the threads that they can continue to do their work, while a
-separate thread will start the mark phase. This mark phase will happen
-concurrently with the other threads running. When the mark thread has
-marked everything in the mark stack, we request the second stop the
-world phase. In this second phase we rescan all the roots, because they
-might have changed. This means also rescanning the thread state so we
-can see what is on the stack at that point.
-
-After we do this, we also schedule the special set that the write
-barrier has tracked during execution. We add that as well to the mark
-stack. We then scan the remaining mark stack during this stop the world
-phase. This is in general a much smaller stack, because we already
-scanned the majority of the system.
-
-After we've finished scanning the mark stack, we do the same
-finalization as we did before in the stop the world collector. We have
-to handle things like finalizers, C-API handles etc. and also sweep up
-the garbage. If this final phase has finished, we can continue running
-everything and garbage collection for this iteration is done.
-
-The commit introducing this new thread can be found in:
-
-[Introducing concurrent mature mark phase](https://github.com/rubinius/rubinius/commit/22c8c9c72e35be71d4258f00e57d8e9bb1f91a2f "Introducing concurrent mature mark phase")
-
-Most of the changes are for updating the gathering of statistics. We of
-course want to know how much time is spent in the stop the world pauses
-and the concurrent mark phase, so we can easily see the benefits of this
-strategy. Another large amount of the code is actually dedicated to
-supporting another feature, which is described in the next section.
-
-### Running young collections while concurrently marking
-
-One thing that is of concern when doing a concurrent garbage
-collection of the whole program is what happens to the young
-generation. As explained earlier, Rubinius has a generational garbage
-collector, so we run different styles of collection at different times.
-Only when a young collection can't satisfy memory release, or we have
-allocated a lot in mature space, we trigger a full concurrent
-collection.
-
-The easiest way to prevent this issue is of course preventing a young
-collection from happening while we're concurrently marking. This however,
-introduces a significant problem. The problem is that when this happens,
-any allocation that would normally create a young object can't succeed.
-This means those objects would be allocated as mature objects,
-increasing the memory pressure for the total system.
-
-In a system that for example runs Rails with reasonably complex pages,
-it's not that strange a situation that we would want to run multiple
-young collections during the runtime of the concurrent mark phase. If we
-don't solve this problem, this would mean megabytes more of mature
-objects being allocated.
-
-The young collection still happens in a stop the world phase. This stop
-is not that problematic, since it only takes a short time to collect the
-young space. This is because it only copies over live objects and it's
-limited in size. This means that collection times are usually in the
-order of a few milliseconds.
-
-So we can use the fact that we stop the world in this cases to make sure
-we update all the structures at that point for the concurrent mark
-phase. The biggest thing here is that we need to update the mark stack
-and other similar structures, such as the set of weak ref objects and
-the finalizers.
-
-Since the concurrent mark phase marks all objects, it also marks young
-objects. It needs to see the copied objects if they are still alive.
-This also applies to the set that is tracked by the write barrier.
-
-### Inflated headers and code resources
-
-Another solution to the problem of writing white objects into black ones
-is to always make all objects grey if they are allocated during
-a concurrent garbage collection cycle. This approach is similar to how
-we solved problems with other managed resources that aren't Ruby
-objects.
-
-There are two types of those objects worth mentioning, inflated headers
-and code resources. The first one is a place where we store information
-if it doesn't fit in a normal object header, or when it requires non
-moving memory. This last required applies for example to using an object
-as a Mutex, which is possible with Rubinius much like how the JVM also
-works. We can't just move memory if an object is locked, so we keep that
-information separate.
-
-The inflated headers also keep a mark. This is done so we can clean them
-up after a garbage collection cycle and deallocate space for objects
-that are not longer alive. This means we now have two marks which
-implies a possible race condition. What if an object is marked by one
-thread and concurrently inflated by another? We would need to make sure
-we don't lose information in that case about the inflated header mark.
-
-Since we don't inflate objects often, we choose a very conservative
-approach here. What that means is that if an inflated header is
-allocated, it always gets the current mark set as it's mark. It means
-that the inflated will possibly not be reclaimed during the first
-garbage collection if the object is already out of reach. We don't view
-this as a problem, since inflated headers often are allocated for
-objects that will stick around longer, for example because they are used
-as a lock.
-
-The second case is code resources. Code resources are things like code
-compiled into the virtual machine representations of bytecode, or native
-code created for jitted functions.
-
-Here we use the same approach: always allocate them with the
-current mark. Code resources are also very likely to stay around, since
-often code gets executed more than once. This approach here is also the
-simplest for fixing issues related to this problem.
-
-These changes where made in the following two commits:
-
-[We always create a code resource as marked initially](https://github.com/rubinius/rubinius/commit/c41e3a66ff476864e5996ca0a536e1644e745c66 "We always create a code resource as marked initially")
-
-[Initialize inflated header marks with current mark](https://github.com/rubinius/rubinius/commit/76039182e837d2e1460e008f2d11515d27e499cc "Initialize inflated header marks with current mark")
-
-### Fibers and how they affect stack scanning
-
-Fibers are somewhat special. They have a part that works like a normal
-Ruby object, for example where we store the return value of a fiber. The
-other parts of a fiber is the actual stack that is executing.
-
-In the past we tracked these two things separately, but that wasn't
-actually needed. The problem is that with concurrent collection, we have
-to separate them again. This is needed because we can't concurrently
-scan the stack parts of a fiber, since those stacks could be executing
-and become invalid at any moment.
-
-This means we have to separate the handling of the stacks from the
-normal object. We can then scan all the stacks in the final collection
-phase for all the fibers that are marked and thus reachable at that
-point. If we don't do this, applications like Sidekiq that heavily use
-Fibers will crash almost instantly on the first garbage collection
-cycle.
-
-This change was made in commit:
-
-[Return of tracking the fiber data explicitly](https://github.com/rubinius/rubinius/commit/b3579cfd46fb773b563e0f66154187dc32f31909 "Return of tracking the fiber data explicitly")
-
-### The first more subtle bug
-
-The additional of the concurrent mark thread is also where the first
-subtle bug was introduced and subsequently fixed. As in the previous
-section described, we have to update the mark stack during a young
-collection cycle.
-
-During a young collection cycle, objects can be promoted. This happens
-when objects are alive for a certain number of young collections and are
-moved to the mature space. During this time, the allocation mechanism
-also changes and the object gets allocated in the area where we sweep
-after a concurrent mark phase is complete.
-
-The bug only happened when a young object was promoted that was already
-marked in the concurrent mark phase. This means the object header
-already had the mark set. The tricky thing here is that the mature
-memory space also as a separate mark table. This is part of the
-Immix algorithm used.
-
-What would happen if a marked object was promoted is that the mark was
-retained. This means however, that the underlying Immix memory space was
-not marked. This means that during the sweep phase the memory was
-incorrectly seen as not in use and reclaimed. This leads to memory
-corruption because now a piece of memory is used for two different
-objects.
-
-The solution to this problem is actually very simple. The only thing we
-have to do is when an object is promoted, is to remove the mark. This
-makes sure that when this object is stored into some other object, it
-would go through the write barrier and will be scheduled for proper
-marking in the future. This will result in the underlying memory to be
-also marked and the problem is gone.
-
-[Introducing concurrent mature mark phase](https://github.com/rubinius/rubinius/commit/22c8c9c72e35be71d4258f00e57d8e9bb1f91a2f#L14R488 "Introducing concurrent mature mark phase")
-
-### Concurrency, forking and deadlock hell
-
-One of the most difficult features to get working correctly in a
-concurrent virtual machine like Rubinius is forking. I can perfectly
-understand the reason for the JVM not supporting this, besides it not
-being cross platform. It requires careful orchestration of all the threads
-to prevent the child process from ending up in a problematic state.
-
-Of course, since we added a new thread for concurrent marking, this also
-introduced a deadlock that could be triggered by forking easily. This
-was evident in a Sidekiq app that relied on forking to spawn subprocesses
-with the fork and exec pattern.
-
-The problem here was that we still had the lock that is used to
-safeguard the internals of the marker thread, while also waiting for a
-stop the world pause. This stop the world pause would then be triggered
-by a `fork()`, which then also requests all the auxiliary threads in the
-system to pause at a safe point.
-
-To get to this safe point, the forking thread would try to grab the lock
-of the Immix thread, which it couldn't because the thread itself still
-had the lock. The fix is similar to how other auxiliary threads such as
-the signal thread and finalizer thread work, by releasing their own lock
-just before they mark themselves as being dependent on the garbage
-collector again.
-
-This problem was fixed in commit:
-
-[Fix deadlock when forking when immix thread is active](https://github.com/rubinius/rubinius/commit/e74d1fa0756e3f52f3535196a8106e3d29e0c34a "Fix deadlock when forking when immix thread is active")
-
-### Finalizers are tricky to get right
-
-This last found and fixed bug was the most elusive one. It was really
-hard to trigger and only happened rarely, but luckily often enough so
-that finding it wasn't completely impossible. As always with these bugs,
-reproducing the bug is really 50% of all the work. 49% is finding what
-causes it and 1% of the time is actually spent fixing it. Remember
-though, that 80% of all statistics are made up on the spot.
-
-Here again the intricate play between different threads and the timing
-dependency of execution caused the issue to only appear rarely. The
-easiest way to reproduce it, was to run a Sidekiq test application that
-cpuguy83 graciously provided for finding another bug.
-
-After running at full speed for maybe somewhere in between 5 and 10
-minutes it would crash. Such long feedback cycles can be very
-frustrating and make digging into it slow. However, the rewarding
-feeling and actually providing people with a stable Ruby runtime is
-definitely worth the hassle.
-
-So what was at play here? First of all, it is important to know about
-finalizers. Finalizers are functions you can register that run when the
-garbage collector determines an object has gone out of scope. Inside
-Rubinius we use this for a number of classes, such as for IO to close it
-if it hasn't been and for Fiber's to clean up the stack space they might
-have allocated.
-
-This last category of object is actually what triggered the problem in
-Rubinius. It looked like a fiber during the finalization had references
-to no longer valid young objects. These young objects would for example
-be the value that a fiber stores as the return value. So the question is
-what was causing these invalid objects? It looked like the fiber was no
-longer properly scanned during young collections and didn't see any
-updated value.
-
-That last sentence might seem easy and straightforward, but it took a
-few hours to actually consciously realize the implications of it. I
-sometimes call it "A-ha driven development." The point where you just poke
-at code, trying to see through it in a concurrent scenario, until the
-case where it can go wrong pops into your head. I haven't been able to
-really identify the though processes going into it, but it includes a
-lot of poking around and pondering.
-
-Actually often in cases like that I just go and take a walk to ponder
-things, or if it's late just go to bed. I've literally had eureka
-moments the next morning in the shower, realizing what the problem was.
-If anyone has insights or ideas on how to improve this process, I really
-welcome them. I'd love to get a better handle on it to see if it can be
-made more consistent in some way.
-
-So let's go back to the original sentence that is much more important
-than it seems. It stated that the problem occurred if a mature fiber
-object would not have it's young variables updated. This should makes us
-remember the concept of the write barrier. As explained we use that to
-make sure that if we add a young object to a mature object, we register
-that. What happens in that case is that the mature object is stored in a
-remember set, that is always scanned during a young collection. This
-ensures these values get updated properly.
-
-So what was happening here? After adding some debug logic (yes, just
-lots and lots of printf statements), I could see that the Fiber was no longer in
-the remember set. But it should be, since it had young objects
-referenced to it!
-
-So the question is why is it removed from the remember set. Normally if
-a young object is collected and stored back into the mature object, the
-write barrier gets executed and the object is added to the remember set
-that is used in the next cycle. Why doesn't this happen in this case? So
-after looking for where we active remove objects from the remember set,
-I found this actually happens during finalization. After an object is
-finalized, we removed it from the remember set since it couldn't be
-referenced anywhere anymore.
-
-This reasoning was perfectly sound until we introduced concurrent
-garbage collection. Because that suddenly introduces a new place that
-the object might still be referenced from, namely the current mark
-stack! This means that this goes wrong in the following scenario. The
-fiber is in the concurrent mark stack, which could happen because for
-example it was still active when concurrent collection started. Then the
-fiber goes out of scope and during a young collection it is scheduled
-for finalization. Because finalization has to keep objects alive, it has
-to keep the fiber live. This would then cause the fiber to be promoted
-and to be a mature object. The concurrent mark stack would be updated
-with the reference to this now mature object. This would also result in
-the now mature fiber to be added to the remember set.
-
-So this sets the stage for the bug, what would happen next is that the
-finalizer would run and after it completed, it would removed the mature
-fiber from the remember set. Meanwhile, before we actually reach the
-fiber in the concurrent mark phase, another young collection runs. This
-young collection then moves the object inside the fiber, for example the
-return value. Now finally the concurrent mark stack reaches the fiber
-and crashes, because it sees an invalid object as the fiber's return value.
-
-So how do we fix this? Well, the fix is actually simple, we just don't
-remove a finalized object from the remember set. This means it still is
-scanned during young collections. The downside is that more objects
-might end up being promoted than necessary, but that's better than
-completely crashing and breaking the guarantees a garbage collector
-should give.
-
-There is room to improve here for the future though, we could check if a
-mature collection is in progress and only then not remove the object
-from the remember set. Since starting a mature mark phase always
-happens in a stop the world phase, this check shouldn't be problematic
-due to race conditions.
-
-You can find the actual fix for this bug in this commit:
-
-[Don't remove finalized objects from remember set](https://github.com/rubinius/rubinius/commit/b1c65d7e8d90e5ad3d1f63c8dc2c2f1f3e0508d6 "Don't remove finalized objects from remember set")
-
-### Unknown unknowns
-
-For now, these are the issues and problems encountered during the
-implementation of the concurrent garbage collector. I'm sure there will
-be more garbage collection related bugs in the future, although I think
-they will often be bugs that also are present for our non-concurrent
-collection. Of course there were also issues like just wrong syntax that would cause
-C++ compile errors etc, but those are of course not that interesting
-to talk about and part of the normal development progress.
-
-I've stress tested the concurrent collector under different load
-patterns, like running a concurrent Rails application and Sidekiq test
-applications. Those systems are often pretty good in finding concurrency
-bugs and race conditions and since those are stable, I'm pretty
-confident that this is ready for more broad usage. This is of course
-also why it was merged into master.
-
-I've tried to highlight the tricky and more complex issues here, so you
-hopefully have a better insight into what implementing all this means.
-
-### Resources
-
-If you're interested in more background on the things discussed here,
-these are some pointers to more resources. As a general reference work,
-there is the Garbage Collection Handbook. So far the best book on
-garbage collection I've seen with a lot of clearly explained content.
-It provides a really good starting point to learn about garbage collection
-and contains a lot of references to papers that can be read for even
-digging deeper into the subject matter at hand.
-
-[The Garbage Collection Handbook website](http://gchandbook.org)
-
-[The Garbage Collection Handbook on Amazon](http://www.amazon.com/gp/product/1420082795)
-
-The original paper in the Immix garbage collector, which Rubinius uses.
-Note that our version of Immix isn't compacting, something that made concurrent
-collection possible. In the future this is something we want to revisit
-and improve upon.
-
-[Immix: A Mark-Region Garbage Collector with Space Efficiency, Fast Collection, and Mutator Performance](http://users.cecs.anu.edu.au/~steveb/pubs/papers/immix-pldi-2008.pdf)
-
-For finding more resources on garbage collection, you can also check out
-this bibliography of garbage collection related papers:
-
-[the Garbage Collection Bibliography](http://www.cs.kent.ac.uk/people/staff/rej/gcbib/)
-
-I would also like to thank Michael R. Bernstein for reviewing this post.
-He's been writing interesting blog posts on garbage collection and gave
-a presentation at GoRuCo 2013. These articles can be really useful if
-you want to have a starting point for the basic garbage collection
-concepts that this article assumes you are somewhat familiar with.
-
-[Adventures in Garbage Collection Pedagogy and an Introduction to Racket](http://michaelrbernste.in/2013/05/20/adventures-in-GC-pedagogy.html)
-
-[To Know A Garbage Collector: GoRuCo 2013](http://michaelrbernste.in/2013/06/10/to-know-a-garbage-collector-goruco-2013.html)
diff --git a/_posts/2013-09-22-ready-set.markdown b/_posts/2013-09-22-ready-set.markdown
deleted file mode 100644
index baac193..0000000
--- a/_posts/2013-09-22-ready-set.markdown
+++ /dev/null
@@ -1,97 +0,0 @@
----
-layout: post
-title: Ready, Set, ...
-author: Brian Shirai
----
-
-
-** ED: Updated the section on How To Build and added a section on gems and
-Rubinius.**
-
-There are some big changes coming in Rubinius. A full post about this should
-arrive later in the week, but for people who are tracking master HEAD on the
-[GitHub repository](https://github.com/rubinius/rubinius), here are a few
-essential pieces of information.
-
-
-## What's Changed?
-
-I've just merged a work-in-progress branch into master. The master branch now
-supports Ruby language version 2.1 only. It also moves Rubinius components,
-such as the parser, compiler, debugger, as well as the Ruby standard library,
-to gems. The changes lay the foundation for numerous planned features to
-improve performance and concurrency support.
-
-The syntax support for 2.1 is not yet complete but should be merged in a few
-days. Applications using Ruby 1.9.3 are expected to run. The standard library
-gems are installed by default, so there should not be a noticable difference
-in how programs using the standard library run.
-
-
-## How To Build
-
-To build Rubinius, MRI 2.0 or Rubinius master are required. Other versions may
-work, but are not supported. Bundler is also required.
-
-The easiest way to get MRI 2.0 if it's not already installed on your system is
-probably [ruby-install](https://github.com/postmodern/ruby-install#readme).
-However, use whatever is easiest for you to install MRI 2.0. Rubinius also
-highly recommends using [chruby](https://github.com/postmodern/chruby) as a
-Ruby switcher.
-
-To clone and build, follow these steps:
-
-1. git clone --depth 1 https://github.com/rubinius/rubinius
-1. cd rubinius
-1. bundle
-1. ./configure --prefix=/path/to/install
-1. rake
-
-The main difference is that bundle is used to install build requirements.
-
-After building, add `path/to/install/bin:/path/to/install/gems/bin` to PATH to
-run Rubinius. Alternatively, use a Ruby switcher like
-[chruby](https://github.com/postmodern/chruby).
-
-
-## What Are Gems?
-
-As noted above, the Ruby standard library in Rubinius, and other Rubinius
-components like the code build tools and developer tools, are provided as
-gems. These are regular gems. There is nothing special about them. They are
-installed as gems, they are bundled as gems, they are updated with `gem
-update`, they are simply gems.
-
-You even have the option at configure time to not install them (except for a
-few that are required to run (e.g. IRB), but we plan to make this optional as
-well). See `configure --help` for the `--with[out]-stdlib` configure option.
-
-Since they are gems, other Ruby ecosystem components, like Bundler, need to
-know about them. When using Bundler, for example, add `gem "rubysl", "~> 2.0"`
-to your Gemfile. For other dependency management, what is needed depends on
-how intrusively it invades the Ruby require process. With plain RubyGems,
-simply install the gems and requires will work as expected.
-
-There are several meta-gems provided (e.g. rubysl, rubysl-rake,
-rubysl-bundler) that can be used to install all the standard library gems that
-those tools depend on. To install (or update) the entire standard library, run
-`gem install rubysl`.
-
-
-## Where Are 1.8 & 1.9?
-
-There are two branches under Rubinius for
-[1.8.7](https://github.com/rubinius/rubinius/tree/1.8.7) and
-[1.9.3](https://github.com/rubinius/rubinius/tree/1.9.3). The default language
-mode when building from the branches matches the branch name. These branches
-are provided to ease transitions. No active development will occurr on the
-branches. If you would like to volunteer to maintain one of the branches,
-please let us know.
-
-
-## Issues
-
-Please open an [issue](https://github.com/rubinius/rubinius/issues)
-if you have any trouble building or running the master branch.
-
-More details coming soon. Happy Rubying!
diff --git a/_posts/2013-10-04-rubinius-2-0-released.markdown b/_posts/2013-10-04-rubinius-2-0-released.markdown
deleted file mode 100644
index 9deb153..0000000
--- a/_posts/2013-10-04-rubinius-2-0-released.markdown
+++ /dev/null
@@ -1,280 +0,0 @@
----
-layout: post
-title: Rubinius 2.0 Released
-author: Brian Shirai
----
-
-We are thrilled to announce the release of Rubinius 2.0. There are many
-exciting things to share. We'll review what Rubinius is, look at what you can
-expect from this release and future releases, and talk about plans for the
-future.
-
-## Many Thanks!
-
-Rubinius 2.0 would not be possible without the tremendous support and
-contributions from so many amazing people.
-
-Thanks Matz for creating Ruby. Thanks David Heinemeier Hansson for creating
-Ruby on Rails, which spread Ruby happiness around the world. Thanks Evan
-Phoenix for creating Rubinius and inspiring us to think beyond current
-limitations.
-
-Thanks to the hundreds of contributors for their time, efforts, and frustration
-while improving Rubinius and RubySpec. There isn't room to list them all, but
-their indelible mark on Rubinius lives on in the source code.
-
-Thanks to the Ruby developers, students, and businesses that all contribute to
-making Ruby better. Thanks to Engine Yard for financially supporting Rubinius
-development and sponsoring all those rad tshirts and stickers people loved so
-much.
-
-All of these people and organizations, not just Ruby developers, are _the Ruby
-community_. Rubinius owes you a huge debt of gratitude.
-
-## The 2.0 Story
-
-With the 2.0 release, Rubinius regains a laser focus on supporting the future
-of Ruby. Rubinius 2.0 is expected to be compatible with Ruby 2.1.
-
-While MRI hasn't released 2.1 yet, Rubinius will continue improving
-compatibility as more features are finalized. Last RubyConf, Matz urged people
-to upgrade as soon as possible to Ruby 2.0. Significant effort has been
-dedicated to making the upgrade from 1.9 as simple as possible. Rubinius
-supports the effort to move Ruby into the future.
-
-Rubinius started life with the goal of bringing modern technology to Ruby's
-implementation, giving developers more power, and businesses who rely on Ruby a
-faster, more stable and more efficient platform on which to build products and
-services.
-
-Over time, we've tried to support multiple Ruby language versions, many
-different projects, old and new code, code that abuses every corner of MRI's
-*ad hoc* semantics, and every random, undocumented MRI C function with the
-Rubinius C-API compatibility layer. Unfortunately, this is unsustainable and
-not in the best interests of Ruby or Rubinius.
-
-Starting with 2.0, Rubinius will concentrate on providing exceptional Ruby
-support for building modern concurrent and distributed applications. Not every
-legacy Ruby program or quirky Ruby feature will be suitable for Rubinius.
-Instead, we'll prioritize the performance and stability of concurrent
-applications to make Ruby competitive with Go, Erlang, Clojure, Scala, and
-Node.
-
-## Versions and Releases
-
-Starting with Rubinius 2.0, we're changing the way releases are done.
-
-Every week or so, we'll release a version of Rubinius. We are not following a
-pre-determined release schedule. We will continue to keep the master branch
-extremely stable, as we have done for years. If there are only bug fixes on
-master since the last *X.Y.Z* release, the new version will be *X.Y.Z+1*. If
-there are other changes, the new version will be *X.Y+1.0*.
-
-We're moving to this release process to get updates into your hands as quickly
-as possible. No matter how much work we do, there is always more. A release
-never seems _ready_. Releases are painful to get right. So we are following the
-advice, "If something is painful, push it to the front and work to reduce the
-pain." There will be bugs with our Ruby 2.1 compatibility. If something is
-broken for you, please file an issue. Hopefully it will be fixed and released
-within days.
-
-The goal is to [semantically version](http://semver.org) the Rubinius core
-starting with version 3.0. During the 2.x to 3.0 transition, we'll be very
-careful about introducing breaking changes, but we'll do so when the benefits
-outweigh the risks. Obviously, the more we know about how Rubinius is being
-used, the better we can evaluate these decisions.
-
-We've added a subdomain [http://releases.rubini.us](http://releases.rubini.us)
-for hosting release tarballs. We expect that over the next few days the many
-Ruby installers and switchers will be updated to install Rubinius.
-
-Below, in the section on future plans, I'll explain what we hope to accomplish
-with these ambitious release plans.
-
-## Rubinius Parts
-
-Many people have heard that Rubinius is an implementation of the Ruby
-programming language. There's a lot wrapped up in that simple description.
-Let's review the major pieces of technology in Rubinius today. Later, we will
-look at plans to improve these in the future.
-
-The Rubinius architecture is fairly standard for a modern language runtime.
-
-The bytecode virtual machine (VM) runs the bytecode produced by the Ruby
-compiler. A notable feature is that every Ruby method essentially gets its own
-interpreter. This enables powerful features like the full-speed built-in
-debugger. Only the specific Ruby method with debugger breakpoints runs the
-"debug" interpreter while the rest of the methods run at normal speed.
-
-The generational garbage collector (GC) has a very fast young generation
-collector, usually pausing for less than 15 ms to complete a collection.
-Applications running on Rubinius typically see shorter GC pauses times and many
-fewer noticeable GC pauses because the entire heap needs to be collected far
-less often. Rubinius also has a partially concurrent mark phase for the mature
-generation which further reduces the GC pause times when a full collection is
-required.
-
-Rubinius implements native operating system threads for concurrency and has no
-global interpreter lock (GIL). Ruby code can run in parallel on multi-core or
-multi-CPU hardware.
-
-The Rubinius just-in-time compiler (JIT) turns Ruby bytecode into machine code.
-The JIT thread is mostly independent of the Ruby threads so the JIT operation
-doesn't impact the running code's performance. The JIT framework tracks which
-methods are often used and what types of objects are seen. Using this runtime
-data, the JIT is able to combine application methods and core library methods,
-generating highly optimized machine code that runs several times faster than
-the bytecode interpreter.
-
-The Rubinius core libraries (e.g. Array, Hash, Range, etc.), as well as
-Rubinius tools like the bytecode compiler, are written in Ruby. The Rubinius
-systems treat them just like Ruby application code (e.g. the JIT combining core
-library methods and application methods to best optimize running code). This
-consistency also improves understanding of the entire Rubinius system. Ruby
-developers can contribute to significant parts of Rubinius simply by writing
-Ruby code.
-
-## Plans, Meet Future
-
-For Rubinius to have a place in future application development, it must serve
-the needs of those applications.
-
-The world is rapidly changing and the rate of change is accelerating. Building
-software today is different than it was just five years ago. Continuous
-delivery and A/B testing are becoming commonplace. Businesses must experiment
-to discover how to compete in changing conditions. Driving down the cost of
-experimenting is essential.
-
-More now than ever, time is money. The time scale to deliver features must be
-hours or days, not weeks or months. To meet the required velocity, building
-concurrent and distributed applications in a heterogenous environment is no
-longer optional, it is essential.
-
-Ruby is more suited than many languages to rapidly deliver features, reducing
-the cost to experiment and the time needed to begin engaging customers.
-Unfortunately, Ruby development has not kept pace with the software as a
-service revolution.
-
-Ruby became popular because Ruby on Rails accelerated the delivery of value by
-an order of magnitude. This influence is rapidly declining. Efficiencies that
-Rails introduced, things like _convention over configuration_ and full-stack
-integration, also encouraged monolithic application architectures. Applications
-built this way are difficult to change and difficult to scale, which means that
-under changing conditions, their costs tend to quickly outweigh any value they
-deliver. Businesses are rapidly learning this lesson.
-
-## Future, Meet Plans
-
-Roadmaps are notoriously painful because, oddly enough, predicting the future
-continues to be an inexact science. Given the future that Rubinius wants to
-support—concurrent and distributed applications—the following are
-specific areas we plan to improve in the coming weeks.
-
-1. Rubinius has no global interpreter lock, but we can significantly improve
-concurrency coordination in the system. During some phases of garbage
-collection, some operations of the JIT, and during fork/exec, we have to stop
-all the threads. We intend to improve this significantly so that less
-coordination is required.
-1. In place of the GIL, Rubinius uses finer-grained locks internally in various
-places. These can be reduced further, improving multi-core efficiency, by using
-modern lock-free concurrent data structures.
-1. While the garbage collector has reasonably low pauses, we can improve this
-by making the GC more concurrent and parallel.
-1. The JIT compiler already often improves Ruby code performance by 2-4x over
-executing bytecode. We can do even better. We will improve communicating Ruby
-semantics to the JIT to avoid unnecessarily allocating objects and doing
-unnecessary bookkeeping that slows performance. We will expose more of the JIT
-framework to Ruby to enable rapidly coding and testing new ideas for optimizing
-Ruby.
-
-## Gems as Components
-
-The ability to compose independent components is one of the best means to
-manage high complexity. In Ruby, the natural way to package, distribute, and
-compose components is gems.
-
-Rubinius wants to bring the advantages of continuous delivery and the
-"evergreen browser" idea to Ruby developers. The Rubinius approach to this is
-to fully leverage gems.
-
-Rubinius itself has been dramatically simplified. Major components, like the
-bytecode compiler, Ruby parser, debugger, etc. have been moved to gems. These
-components can be updated easily and quickly without requiring a Rubinius
-release. These components participate in the Ruby ecosystem, for example
-[Bundler](http://bundler.io) or [dep](https://github.com/cyx/dep), like all the
-gems that Ruby developers are familiar with.
-
-In Rubinius 2.0, the [Ruby standard library](http://rubysl.github.io) has also
-been converted to gems. The Ruby standard library is some of the oldest Ruby
-code that exists. Due to being bundled with MRI all these years, it was far
-more difficult to change than a library or gem. Every change required MRI to
-accept it, and any changes required waiting for a new release of MRI, something
-which did not happen frequently.
-
-It's not surprising that many people simply went around these obstacles and
-made alternate libraries. Instead of being the pinnacle of excellent Ruby
-design and idioms, parts of the standard library bit-rotted and retained
-anachronisms like embedded tests at the end of files. Further, many of the
-critical libraries were written as C extensions, making them unusable by JRuby,
-Topaz, IronRuby, Opal, and early MagLev (which now has some C-API support).
-
-In Rubinius 2.0, the components and standard library are _just gems_. There is
-nothing special about them. They are installed as gems. They participate in gem
-sets and Bundler workflow as gems. There are some challenges required to
-bootstrap the gems, but that requires an internal Rubinius command, not changes
-to the RubyGems infrastructure.
-
-Providing the standard library as gems opens the opportunity to rebuild it _in
-Ruby_ and improve the code rapidly so that multiple implementations can share
-it. However, we are also not bound to using any of these libraries. Since they
-are just gems, they can be put in a Gemfile, _or not_, if there are better
-libraries available. There's no point spending time "improving" things that no
-one wants. Supporting newer libraries with better code and APIs may be much
-more beneficial. This is now an option.
-
-We'll be monitoring what people do and where pain points are. Building on all
-the gem infrastructure, we open up a world of possibilities for Ruby
-developers.
-
-## Rubinius Inspirations
-
-As 2.0 is a big milestone and transition, it's interesting to reflect on some
-significant Rubinius contributions to the Ruby community.
-
-Rubinius has inspired a number of projects that have benefited Ruby far beyond
-Rubinius. The best known of these is [**RubySpec**](http://rubyspec.org), which
-is used by every significant Ruby implementation, including promising new ones
-pushing the limits, like [Topaz](http://www.topazruby.com) and
-[Opal](http://opalrb.org).
-
-Rubinius also created the initial **FFI** spec that opened the world of native
-libraries to Ruby with a simple API across implementations and without needing
-to write C-extenions.
-
-Evan created [**Puma**](http://puma.io) to meet the need for a fast web server
-that would promote the Rubinius parallel thread support. Puma also works well
-on MRI and JRuby. It provides Ruby applications excellent performance and
-multi-core scaling, especially when there's no global interpreter lock.
-
-Rubinius as a language platform has inspired many
-[**projects**](http://rubini.us/projects) and encouraged people who may have
-thought language design was beyond their skills to experiment and discover the
-tremendous joy in creating [**their own programming
-language**](https://github.com/queenfrankie/lani).
-
-It is a joy that Rubinius has been a part of these efforts and we will continue
-improving developer experience in these areas.
-
-## Ready, Set, Ruby!
-
-Concurrent and distributed applications aren't the future anymore, they are the
-present. They are vital to business success. The many talented developers that
-are passing over Ruby for Erlang, Go, Clojure and Node are draining Ruby of
-talent and vitality.
-
-Ruby is an excellent language. Rubinius is dedicated to providing Ruby
-developers with excellent tools and technology competitive with these other
-languages. Developers who are happy writing Ruby shouldn't be forced to leave
-it because of technical limitations.
-
-If you are one of these developers, let's build the future.
diff --git a/_posts/2013-10-11-the-once-and-future-rubinius.markdown b/_posts/2013-10-11-the-once-and-future-rubinius.markdown
deleted file mode 100644
index a9c62ae..0000000
--- a/_posts/2013-10-11-the-once-and-future-rubinius.markdown
+++ /dev/null
@@ -1,64 +0,0 @@
----
-layout: post
-title: The Once and Future Rubinius
-author: Brian Shirai
----
-Engine Yard has [posted their
-statement](https://blog.engineyard.com/2013/the-future-of-rubinius) about
-ending sponsorship for Rubinius, which gives me the opportunity to clearly
-address the future of Rubinius.
-
-First of all, Engine Yard deserves great respect and admiration for their
-contribution to Rubinius and the entire Ruby community. I had the pleasure of
-interacting often with three of the Engine Yard founders: Tom Mornini, Lance
-Walley, and Ezra Zygmuntowicz. I have rarely had the good fortune to work with
-people as ethical, careful, and visionary as these folks. They endeavored to
-build community _and_ business together, and they were highly influential in
-both.
-
-Engine Yard's sponsorship of Rubinius certainly accelerated development and
-brought the project to the attention of many developers. Additionally, Engine
-Yard's sponsorship contributed to the success of
-[RubySpec](http://rubyspec.org) as an idea and tool for unifying Ruby
-compatibility across more than a half-dozen significant implementations of Ruby
-for the benefit of the Ruby community.
-
-So, thank you very much, Engine Yard!
-
-The simplest statement about the status of Rubinius is that there are now zero
-people paid to work on the project. This fact has several implications, none of
-which are inherently negative.
-
-On the one hand, Rubinius is free to aggressively pursue the goals of the
-project in helping build the future of Ruby. On the other hand, I have
-significantly less time to devote to the project. While unfortunate, I'm not
-discouraged. I worked on Rubinius for over a year before Engine Yard hired me
-and we accomplished a tremendous amount.
-
-We still have numerous things yet to do. Over the past several weeks, I have
-been working to simplify and focus the project so that all the time we can
-invest pays significant rewards for developers and businesses. We'll continue
-to streamline and accelerate delivering value to the people investing their
-time to use Rubinius.
-
-Rubinius has a broad and ambitious vision. Since Evan Phoenix created it,
-Rubinius has been pushing the envelope. It was one of the first projects in the
-Ruby community to use git. One of the first big projects on GitHub. One of the
-first projects to use LLVM outside of the LLVM ecosystem. There have always
-been skeptics voicing their opinions about Rubinius using Ruby, building
-RubySpec, building our own virtual machine and garbage collector, removing the
-global interpreter lock, using gems, about almost every aspect of the project.
-
-Despite this, Rubinius keeps moving forward. People are experiencing the
-tremendous value of running concurrent applications on modern hardware,
-saturating the CPU cores instead of blowing out the memory. It's trivial to
-migrate from MRI to Rubinius, continuing to use familiar platform tools and
-running C-extensions. The terrific response to the 2.0 announcement has been
-ample validation of our vision for Rubinius. We're just getting started.
-
-Visit us in the #rubinius channel on Freenode and check out ways you can
-[contribute](http://rubini.us/doc/en/contributing/) to the project. The
-simplest, and always the most fun, way to contribute is to use Rubinius to do
-something you find interesting.
-
-The future is, by definition, undefined. Let's define it.
diff --git a/_posts/2013-10-15-introducing-rubinius-x.markdown b/_posts/2013-10-15-introducing-rubinius-x.markdown
deleted file mode 100644
index 6a91ab7..0000000
--- a/_posts/2013-10-15-introducing-rubinius-x.markdown
+++ /dev/null
@@ -1,45 +0,0 @@
----
-layout: post
-title: Introducing Rubinius X
-author: Brian Shirai
----
-
-**ED: Removed a ["frequently misused English
-phrase"](https://twitter.com/reinh/status/390544258899664896) to improve
-readability.**
-
-Today, I'm announcing the [Rubinius X](http://x.rubini.us) project. Please read
-about the details at the website. Here's why I started the project.
-
-Ruby is a dying language. Business is over its dalliance with Ruby. No major
-startup is lauding their use of Ruby and existing businesses are migrating away
-or simply writing new applications in a different language.
-
-Businesses care about providing customers value so the businesses earn profits.
-That's the harsh reality. Ruby is failing to help businesses engage customers.
-It is seen as inefficient and inferior to other languages.
-
-It's not true that people are leaving Ruby because the language is no longer
-new. Javascript is not new and it's not a particularly good language. People
-use it because it helps them solve problems. Java is also not new and many
-people dislike writing Java code. But Java is evolving and businesses pay a lot
-of people to write Java. No business is rewriting their Java applications in
-Ruby because the developers are happier.
-
-Ruby has great potential to help businesses compete in tumultuous markets by
-reducing the cost to experiment with products that may interest consumers. It
-has _potential_ but fundamental things about Ruby must change. Simply writing
-some libraries or a new framework like Rails isn't enough.
-
-I _really_ want Ruby to be a language that businesses choose so that people who
-are happy writing Ruby will have a job. I'm going to test whether this is
-possible and I hope you will help.
-
-I want to thank a number of people who have inspired me: [Yehuda
-Katz](https://twitter.com/wycats), [James Coglan](https://twitter.com/jcoglan),
-[Gary Bernhardt](https://twitter.com/garybernhardt), [Evan
-Phoenix](https://twitter.com/evanphx), [Wilson
-Bilkovich](https://twitter.com/defiler), [Rich
-Hickey](https://twitter.com/richhickey), [Michael
-Bernstein](https://twitter.com/mrb_bk), [Gerlando
-Piro](https://twitter.com/gpxl), and many other.
diff --git a/_posts/2013-10-18-the-parisian-release.markdown b/_posts/2013-10-18-the-parisian-release.markdown
deleted file mode 100644
index bdee910..0000000
--- a/_posts/2013-10-18-the-parisian-release.markdown
+++ /dev/null
@@ -1,20 +0,0 @@
----
-layout: post
-title: The Parisian Release
-author: Brian Shirai
----
-
-Rubinius 2.1.0 has been released. I'm naming this "The Parisian release" in
-honor of the [dotRB conference](http://www.dotrb.eu/) in Paris and today being
-Evan's birthday. I wanted this to be the 2.0 release, but circumstances, so
-sorry about that.
-
-Following the release scheme I detailed in the [2.0
-release](http://rubini.us/2013/10/04/rubinius-2-0-released/), I've rev'd the
-minor version because we added a few C-API functions and different standard
-library loading stubs. The rest of the changes are basically bug fixes.
-
-I'll be posting more soon about gems, packaging, and releases.
-
-Enjoy! Preferably with a glass of nice wine but surely with something that
-makes you happy.
diff --git a/_posts/2013-12-03-testing-with-rbx-on-travis.markdown b/_posts/2013-12-03-testing-with-rbx-on-travis.markdown
deleted file mode 100644
index 5eadc4a..0000000
--- a/_posts/2013-12-03-testing-with-rbx-on-travis.markdown
+++ /dev/null
@@ -1,55 +0,0 @@
----
-layout: post
-title: Testing Your Project with Rubinius on Travis
-author: Brian Shirai
----
-
-[Travis CI](http://travis-ci.org) has been a tremendously useful tool for
-automating testing and has provided Ruby implementations with valuable
-feedback. However, it can be a trial-and-error process to find the right
-incantations for `.travis.yml` to get your preferred selection of Ruby
-implementations running. This post explains how to test your project on
-Rubinius.
-
-With the Rubinius 2.0 release, there are no longer language modes. Rubinius is
-presently working on compatibility with the upcoming MRI 2.1 release. There
-are still compatibility issues to be fixed, primarily keyword syntax and some
-core library API changes. What this means for your `.travis.yml` file is that
-'rbx-18mode' and 'rbx-19mode' are no longer supported. We submitted a patch to
-the [Travis lint tool](https://github.com/travis-ci/travis-lint) to check for
-this, so please use the linter!
-
-So, if those language modes are no longer available, what should you add to
-your `.travis.yml` file? Remember that Rubinius is releasing new versions every
-week or so. Together with recent changes to RVM, this gives four options for
-how specific you want to be about the Rubinius version you test against. The
-following list of Rubinius options is from least-to-most specific:
-
-1. 'rbx' - This means the most recent Rubinius release. Every time your tests
- run, the most recently released binary will be used.
-1. 'rbx-X' - This means the most recent Major release. For example, if you use
- 'rbx-2' (which is the only one available right now), your tests will run on
- the most recent 2.Y.Z release, but would not run on 3.Y.Z.
-1. 'rbx-X.Y' - This means the most recent Minor release. If you use 'rbx-2.2',
- your tests will run on the most recent 2.2.Z release, but will not use the
- 2.3.Z or 2.1.Z release.
-1. 'rbx-X.Y.Z' - This means precisely the specified release. So, 'rbx-2.2.1'
- will run only on the 2.1.1 releease and no other release.
-
-This method of designating the version of Rubinius you wish to run against
-should look similar to specifying versions of gems with the pessimistic
-operator (~>). It is intended to give you the same flexibility while allowing
-for stability constraints that you choose.
-
-Since each of these designations is independent, you can mix and match them as
-you wish. For example, if you know that Rubinius 2.2.1 is green for your
-project, you can specify both 'rbx-2.2.1' and 'rbx'. Or you can always stay on
-the cutting edge by just using 'rbx'.
-
-If you need help getting your project set up or updated on Travis, please let
-us know. I've created a simple project called
-[travis-canary](https://travis-ci.org/rubinius/travis-canary) that you can
-check to see if the ways of specifying Rubinius listed above are currently
-working on Travis.
-
-Happy testing!
diff --git a/_posts/2014-01-06-happy-2014.markdown b/_posts/2014-01-06-happy-2014.markdown
deleted file mode 100644
index 8abd7ad..0000000
--- a/_posts/2014-01-06-happy-2014.markdown
+++ /dev/null
@@ -1,41 +0,0 @@
----
-layout: post
-title: Happy 2014!
-author: Brian Shirai
----
-
-New beginnings are exciting and I'm delighted to announce that I've joined a
-terrific team of people at [Enova](http://enova.com) who are working hard to
-innovate and push Ruby well beyond its comfort zone.
-
-I'm looking forward to sharing the journey with you as we build fantastic
-developer tools, migrate giant monolithic Rails apps, and create
-next-generation distributed applications that scale efficiently to _all the
-cores_. There are huge challenges given the engineering tasks, but also
-tremendous opportunities to demonstrate how powerful Ruby is and can be.
-
-At Enova, I'll be continuing my OSS work on Rubinius and RubySpec. This is a
-generous contribution from Enova to the Ruby community. I'll also be devoting
-time to Rubinius X as we explore and address the many deficiencies in Ruby
-that continue to drive developers and businesses to other languages like Go,
-Clojure, and Node.js.
-
-For those still running on Ruby 1.8.7, we'd love for you to collaborate with
-us as we build tools to migrate to newer Ruby versions. If you're already on
-Ruby 1.9.3 or later, we'd love to help you explore migrating from MRI to a
-Ruby implementation with a modern garbage collector, JIT compiler, and good
-support for concurrency. If you're considering rewriting your Ruby app in some
-other language, please let us know why.
-
-If you've already rewritten your Ruby apps in another language, I'd especially
-like to hear from you. Rewrites always involve new architecture decisions as
-well. I'd like to understand if the Ruby _language_ prevented your new
-architecture decisions or if better technology in Ruby would have saved the
-cost of rewriting an application.
-
-Kumiko, Miwa, and I will be moving to Chicago. If you're in the area, we look
-forward to meeting you. If not, hopefully you'll come visit Chicago and say
-hello, maybe at [RailsConf 2014](http://lanyrd.com/2014/railsconf/)!
-
-Happy New Year!
-
diff --git a/about/1.1.1.markdown b/about/1.1.1.markdown
deleted file mode 100644
index faabaa1..0000000
--- a/about/1.1.1.markdown
+++ /dev/null
@@ -1,153 +0,0 @@
----
-layout: release
-class: release
----
-
-## Overview
-
-The Rubinius team is proud to announce the availability of 1.1.1.
-
-1.1.1 is bugfix release for 1.1, containing minor performance improvements,
-compatibility adjustments, and bugfixes.
-
-
-## About
-
-Rubinius is a high performance environment for running code written in the
-Ruby programming language. It provides a number of virtual machine features
-found in other popular language runtimes such as generational garbage
-collection, Just-In-Time compilation, and compatibility with existing C APIs.
-
-#### Stats
-
-* **Release Date:** November 16th, 2010
-* **Commits:** 206
-* **Days since last release:** 64
-
-#### Authors
-
-* Brian Ford
-* Charles Comstock
-* Dirkjan Bussink
-* Eero Saynatkari
-* Eric Wong
-* Evan Phoenix
-* Ivan Samsonov
-* Jari Bakken
-* Jeremy Durham
-* Matthew Draper
-* Sean Bryant
-* Tony Arcieri
-
-## Summary
-
-* Make CM#locate_line more strict. Fixes #563
-* Make sure that the preinstalled dir is always present
-* Updated Rapa source to 36f91258.
-* Fixed code confusing GCC overflow checks in unpack.
-* Show the missing file error to -c more clearly. Fixes #568
-* Add ruby-debug stub gem
-* Use redo_coerced when calling Float#divide. Fixes #564
-* Remove old SendSite/Selector cruft
-* Fix CompiledMethod#locate_line
-* Add Rubinius::OS_ARGV and Rubinius::OS_STARTUP_DIR
-* Change IO::Buffer => IO::InternalBuffer. Fixes #560
-* Make sure there is a fallback policy. Fixes #561
-* Explicitly add -fno-omit-frame-pointer to the build flags
-* Workaround for FreeBSD by exposing dlopen directly
-* Support for native extensions with a . in their name
-* Add hook to allow code to install a custom debugger
-* Add ability to scope and stop only in certain stack frames. Fixes #558
-* Add rb_set_end_proc to ruby.h
-* Make Readline library configurable.
-* Imported pure Ruby Readline (rb-readline at e591463)
-* Add Array#select via aliasing
-* Handle next'ing out of rescue handlers. Fixes #556
-* Fix Bignum#>> to respect 2s complement properly
-* Follow the weird self-in-eval behavior
-* Add enough delegation to support Method#parameters. Fixes #557
-* Wipe out CDPATH when building. Fixes #555
-* Use Kernel.exec, not just exec because self is uncontrolled.
-* Implement rb_set_end_proc
-* Add rb_thread_wait_for
-* Cleanup unused base64 code
-* Fixed rbx compile -N broken by #531 fix.
-* Ensure ObjectFlags bit fields are endian portable.
-* Check nil object identity in IO#puts. Closes #550.
-* Rework loader error reporting when running a script. Closes #551.
-* Specify the version for FFI::Library::LIBC like ffi-ruby gem. Closes #546.
-* Create gem cache dir with mkdir_p. Closes #541 again.
-* Fixed function declarations. Closes #543.
-* Backport add --cxx to configure from multiverse (6596ed7). Closes #542.
-* Add rb_struct_new and rb_ary_freeze. Fixes #540
-* Make sure the user's gem cache directory exists. Fixes #541
-* Incorporate rubygems loadtime speedup patch
-* Speed up rubygems gemspec loading via caching
-* Remove CompiledMethod#compile
-* Seperate out running finalizers in profiler output
-* Add ability to cache eval compile requests
-* Handle fixnums in JIT float ops too
-* Emit error message when attempting to run .rbc file.
-* Add RE_* option macros to CAPI
-* Get syslog passing the specs
-* Avoid exception in Backtrace#show when show_color is false.
-* Handle attr_assgn in splat properly. Fixes #531.
-* Implement rb_protect_inspect and rb_inspecting_p. Fixes #517.
-* Implement rb_exec_recursive (mostly cripped from 1.8.7)
-* Make rb_gc_force_recycle a noop
-* Add rb_cmpint, rb_cmperr, and rb_equal
-* Don't cache on autoload failure. Fixes #529
-* Write out a newline for an empty string too. Fixes #525
-* Add Regexp#search_from. Fixes #524
-* Use string coersion for filename in class_eval / module_eval
-* Current var_table can be NULL, fixes #527
-* Add missing return value used in Errno.handle checks
-* Allow for subclassing Thread, fixes #526
-* Thread#new throws an exception when not given a block
-* Propagate --cc configure setting to CC, CXX env vars. Closes #520.
-* Removed -D from 'rbx compile' options. Closes #523.
-* Better docs on installing gems with rbx.
-* Fixed String#casecmp. Closes #518.
-* Fixed --help output.
-* See README for build, install directions. Closes #521.
-* taking care of rb_ary_to_s for issue 517
-* new capi method rb_obj_dup
-* rb_str_new4 implementation.
-* Improve performance of String#gsub. Fixes #515
-* Use String#__data__ to avoid subclass clobber. Fixes #516.
-* Kernel.loop rescues StopIteration
-* Convert Generator to use Fiber
-* Add support for Enumerator#next using Threads and Fibers
-* Use offset instead of substring. Fixes #514
-* Allow for reopening subclasses of Module
-* StringIO#gets can accepts string as separator. Fixes #513
-* Better install UX and README instructions. Closes #511.
-* Discover gdbm better. (Jeremey Evans)
-* Build openssl ext with NO_STATIC_ENGINE on OpenBSD. (Jeremy Evans)
-* Remove illegal casts. Fixes #509.
-* Refuse to configure, build if RUBYLIB is set.
-* Fix OpenBSD complaints about strcpy, sprintf.
-* Don't enable execinfo by default on OpenBSD.
-* Add -D__STDC_LIMIT_MACROS to CFLAGS if it's not there.
-* Speed up rb_yield using some type checking tricks
-* Fixed pack to taint output for tainted directives string.
-* Added configure option to specify 'rake' command.
-* Fix for missing pthread functions on OpenBSD.
-* Fix String#split edge case. Fixes #505
-* Set __STDC_LIMIT_MACROS for proper C99 compat. Fixes #507
-* Relock the GIL in readline. Fixes #504.
-* Set eval introduced locals in the proper scope. Fixes #506.
-* Some OpenBSD fixes from Jeremy Evans.
-* Set the scope of masgn locals early. Fixes #502.
-* Use same wording/quoting as MRI. Fixes #503
-* subclassing IO works properly for pipe/popen
-* Enable running docs site with bootstrap Ruby using 'rake docs'.
-* Reorganize how the MRI backtrace is rendered. Fixes #501.
-* Add missing pop to fix stack effect. Fixes #490
-* Return the user's object, not the coerced one. Fixes #499.
-* Add Socket#connect_nonblock. Fixes #498.
-* Add rb_io_close
-* Add rb_memerror as a fatal condition. Fixes #496
-* Add -fPIC to rbconfig CCDLFLAGS like MRI. Closes #492.
-* Don't allow meta classes to be allocated
-* Preserve zero length captures. Fixes #495
diff --git a/about/one_one.markdown b/about/one_one.markdown
deleted file mode 100644
index bd725cd..0000000
--- a/about/one_one.markdown
+++ /dev/null
@@ -1,210 +0,0 @@
----
-layout: release
-class: release
----
-
-## Overview
-
-The Rubinius team is proud to announce the availability of 1.1.
-
-1.1 is the first feature release since 1.0, and contains a number of new
-features, performance improvements, compatibility adjustements, and bugfixes.
-
-#### Stats
-
-* **Commits:** 546
-* **Days since last release:** 112
-
-#### Authors
-
-* Evan Phoenix
-* Brian Ford
-* Dirkjan Bussink
-* Jake Douglas
-* Jose Narvaez
-* Jeremy Evans
-* Ian Leitch
-* Paolo Capriotti
-* Gavin Stark
-* Duncan Mac-Vicar P
-* Richard Musiol
-* Tim Carey-Smith
-* Ivan Evtukhovich
-* Chuck Remes
-* Konstantin Haase
-* Alex Khamutov
-
-## Summary
-
-#### Additions
-
-* Enable block inlining within the JIT
-* Implement a new GIL algorithm to prevent starvation
-* Add Debugger APIs and reference CLI debugger
-* Overhaul finalizers, support for resurecting finalizers
-* Basic 'rbx docs' command support.
-* Add 'rbx report' and support for VM and ruby crashes
-* Add CM::Script#eval_source
-* Rewrote Array#pack and String#unpack
-* Add code to detect bad extensions. Recompile your extensions.
-* Add dbm, sdbm, and gdbm extensions
-* Implement support for -n, -p, and -a. Fixes #353.
-* Add and use --agent when running the specs
-* Add String#secure_compare @x-api
-* Add heapdump capability for memory debugging
-* Add automatic object ivar packing (improves memory usage)
-
-#### Fixes
-
-* Improve FFI compatibility
-* Support reading and writing callback type fields
-* Fix a few more FFI incompat issues
-* Improve rails 3.[01] compatibility
-* Upgrade to RubyGems 1.3.7
-* Handle control flow edge case in JIT. Fixes #478.
-* A few simple fixups for stringscanner. Fixes #481.
-* Fix parser edge case
-* Support rb_sys_fail being passed NULL
-* Verify that the ruby to build with is the one it was configured with
-* Fixed Module#define_method to return a lambda Proc
-* Add Kernel#type even though it's deprecated. Fixes #469.
-* Move Etc::Passwd and Etc::Group to Struct
-* Add no-op rubysig.h to make extensions happy
-* Add unblock support to rb_thread_blocking_region. Credit: kudo. Fixes #461.
-* Add missing capi functions needed for hpricot
-* Implemented rb_struct_aset, _aref.
-* Add a rb_thread_critical and a null SIGALRM handler.
-* Flush/update CAPI handles better. Fixes #455.
-* Track the location of globals for rb_global_variable. Fixes #462.
-* Handle check EINTR in rb_thread_select properly. Fixes #462.
-* Ignore inlined methods when considering what to JIT
-* Ignore an error when all input was read. Fixes #454.
-* Temporary fix for perf regression in Array#include?.
-* Rubinius eagerly raises on frozen objects.
-* Normalizing all access of Tuple and ByteArray.
-* Update array handles the first time you see one. Fixes #455.
-* Fix docs and const-ness in capi. Fixes #457.
-* Dir.glob also takes an array or a null delim string. Fixes #458.
-* Fixed #require edge case. Closes #365.
-* Performance fix. The JIT was accidently always using the reset pointer.
-* Raise a TypeError if attempting to inherit from a metaclass.
-* Fixed class variable with metaclass. Closes #411.
-* Ensure String.pattern receives a positive size.
-* Fully implement rb_iterate
-* Added rb_hash_delete_if.
-* Deal with being interrupted while writing better. Fixes #373.
-* Fixes Float#divmod bug. Closes #451.
-* Added RBIGNUM_SIGN.
-* Added define for RB_NUM_COERCE_FUNCS_NEED_OPID. Closes #447.
-* Fixed rb_hash implementation. Closes #446.
-* Use the specified socket type instead of Socket::AF_UNSPEC, fixes #442
-* Fix fallback to ObjectMemory allocation if no new slab can be allocated
-* Use RbConfig instead of Config
-* Rework Process::Status specs to be simplified and run them on Windows
-* Keep reading if read(2) gets EINTR
-* Speed up Kernel#` by using a specialized primitive
-* Use same function signature as MRI for rb_reg_new
-* Check for and run #to_ary when passed to yield with 2+ args. Fixes #374.
-* Don't expand -I paths. Fixes #434.
-* Remove old, stale minitest
-* Slight cleanup of Socket and adding Socket.getnameinfo
-* Add support for rb_gv_get("$~")
-* Initial version.h for C-API.
-* Add the C API rb_reg_nth_match method
-* Add C API function rb_reg_new
-* Fixed compiling empty script with \_\_END\_\_ data. Closes #433.
-* Remove unused libltdl.
-* Fixes for Process::Status
-* Fix Thread.critical= allows all non-bool arguments
-* Use getrusage for Process.times
-* Disable the agent in forks and cleanup before exec
-* Check the handle against our known set of handles before marking in rb_gc_mark_maybe()
-* Validate StatiScopes in constant caches. Fixes #426.
-* Pass the current block into an sclass. Fixes #425.
-* Handle frozen strings used for a StringIO
-* Fix MatchData#string returns a frozen copy of the match string
-* Allow IO.setup to be passed a numeric mode
-* Fix IO#write_nonblock to raise on an unwritable IO even if data to write is 0 bytes
-* Enhance Rubinius::Fiber
-* Module#class_variable_set now raises a TypeError when self is frozen
-* Fix IO.foreach with a nil separator, it should yield the entire contents at once
-* Remove Ar since it's not used anymore
-* Allow splat arguments in define_method. Fixes #419.
-* Preserve path seperators in Dir.glob. Fixes #420.
-* add rb_need_block() to rbx capi
-* Kernel.extend now raises a TypeError, when called on a frozen object
-* Fix profiler graph output and handling of blocks
-* Cleanup of Bignum#%, significant performance improvement
-* Don't allow initializing a class twice
-* Move Hash#setup to Hash#\_\_setup\_\_ to allow overriding
-* Cleanup IO.popen and IO::BidirectionalPipe
-* Only run ->dfree if ->data isn't NULL
-* Fix Module#remove_const to not call Module#const_missing
-* Temporarily disable running finalizers at exit.
-* Test the proper scope when determining if long return is possible
-* Deal with Fixnum and Symbol speciallize in #methods. Fixes #403
-* Handle #inspect calling #to_s in the right cases. Fixes #405
-* Handle block arguments to a lambda specially. Fixes #398.
-* File#truncate now raises an IOError if file is not opened for writing
-* Fix R::CompiledMethod#add_metadata to allow multiple keys
-* Don't use self in a block that might be instance_evald. Fixes #399.
-* Expose the SystemExit to at_exit handlers. Fixes #395.
-* Minor performanece fix, don't initialize an object body twice
-* Have Proc#inspect use the exact same format as MRI
-* Support -1 as the free function
-* Add Rubinius specific #\_\_finalize\_\_ API for resurrectable finalizers
-* Fix Struct.specialize_initialize for subclasses of Struct
-* Add rb_throw to the C API.
-* Fix classic strncmp bug in libffi
-* Fixed be_computed_by matcher to display inspected value.
-* Add implementation for rb_yield_values
-* Include errno.h to ruby.h (MRI includes it in rubyio.h).
-* Speed/foolproof Kernel#dup. Add custom object_class inline logic.
-* Fixed File.size and .size?.
-* Fix File#size to conform to specs. Closes #392.
-* Add a primitive to calculate the MRI format backtrace. @perf @rspec
-* Check frozen on Hash#initialize.
-* Fix for next with ensure (pair Evan).
-* Fixed compiler specs for next running ensure.
-* Fixed next running ensures.
-* Specs for next running ensure blocks.
-* Fix -Xjit.profile to provide JIT specific output
-* Remove extranious cast_array from bytecode
-* Convert Hash to use #each_entry instead of #to_iter. @perf
-* Add missing OFFT2NUM. Fixes #390.
-* Time objects return T_DATA to match MRI C API
-* Remove custom sorting logic in Enumerable, use Array.
-* Added rb_set_kcode.
-* Fix warnings compiling Melbourne ext in 1.9.
-* Generalize building with MRI 1.8/1.9 or rbx.
-* Add --cc to configure Script, so you can do 'rvm install rbx -C --cc=clang', as with MRI and REE.
-* Fix building with gcc 4.4.1.
-* Run at_exit blocks and finalizers before exiting a fork. Fixes #372.
-* Add -Xgc.honor_start to control if GC.start is honored
-* Use thread-safe Array#delete_if. Fixes #361.
-* Fixed path in IO.reopen. Closes #360.
-* Minimize array contents for IO.select. Fixes #359
-* Fix TCPServer.for_fd and UNIXSocket.for_fd. Fixes #354. Fixes #355.
-* Fix ugly signal bug related to pipe fds.
-* Fix IO#write_nonblock to conform to specs
-* Allow CallFrame::print_backtrace to see included modules
-* Fix IO#write_nonblock to actually not block
-* Rework how signals are delivered. Fixes #356
-* Conform WeakRef API to MRI. Closes #370.
-* Added io/nonblock.rb from MRI 1.8.7. Test passes. Closes #346.
-* Added rb_to_int. Closes #367.
-* Added stub weakref.rb. Closes #368.
-* Adjust checking for GCC version to build on Fedora 8.
-* Dir.new needs to convert path to a String also.
-* Dir#new should call #to_str under 1.8 and #to_path under 1.9
-* Fixed Dir.open to call StringValue. Closes #362.
-* Dir should be calling to_str on non-String arguments in Ruby 1.8
-* kronos' fix for Bignum#\<\<. Closes #350.
-* Use correct module namespacing in Numeric specs.
-* Further conform Numeric to MRI. Closes #349.
-* More specs for Numeric#<=>.
-* Reworked profiler graph output change.
-* Add NUM2OFFT, fixes #348
-* Ensure argument is not modified by File.expand_path. Closes #351.
-* Spec for alias+super interaction with included modules
-* Validate the starting Module of a super call. @crash
diff --git a/about/one_point_oh.markdown b/about/one_point_oh.markdown
deleted file mode 100644
index 03eb56c..0000000
--- a/about/one_point_oh.markdown
+++ /dev/null
@@ -1,84 +0,0 @@
----
-layout: release
-class: release
----
-
-### Rubinius 1.0 (Fabius) Released!
-
-#### Thanks
-
-The Rubinius 1.0 release has been a long time coming and the team is very
-proud to announce that it is finally ready!
-
-This marks the end of a long and wonderful road we have all traveled over the
-last 3 1/2 years. There are so many people to thank for their help and
-support.
-
-[Fabius](http://en.wikipedia.org/wiki/Fabius_Maximus) is the release name of
-version 1.0. This is a reference to the great defender of Rome. This name was
-given to Rubinius by [Geoffrey Grosenbach](http://peepcode.com/), who secured
-naming rights to version 1.0 many years ago by being the very first person to
-provide some financial backing for the project. I can't thank him enough.
-
-Tom Mornini and Engine Yard deserve the lion's share of the thanks. Back in
-2007 when Tom asked me to come work on Rubinius at Engine Yard, it was a dream
-come true. They've tirelessly supported the project over the years, even when
-project momentum waned.
-
-And lastly, thanks to everyone who has contributed to the project. Over the
-years, there have been over 200 contributers who've given up their free time
-to help make Rubinius great.
-
-_- Evan Phoenix_
-
-#### What's New Since 1.0rc5
-
-* Updated README.
-* Updated getting_started.txt.
-* Handle :do in a method call properly
-* Simplify qsort to using simplified and working algorithm
-
-* Simple hack to allow using sqlite3 1.3.0
-* Include RUBY_EXTCONF_H. Fixes #281.
-* Use _exit() rather than exit() to avoid C++ finalization races
-* Catch and handle a redo passing through a rescue properly (unicorn)
-* Don't use Class#ancestors internally
-* Clean up test directory
-
-* Fixed proto for rb_define_alloc_func
-* Restrict configure to only using LLVM 2.6 from the system
-* Add rb_big2ull
-* Update version number for 1.0.0! Break out the champagne!
-
-#### Highlights
-
-* Supports a huge amount of Ruby code and popular C extensions:
- * Rails 3 and 2.3.5
- * Sinatra
- * sqlite3, mysql, nokogiri, yajl-ruby
- * Much, much more!
-* JIT compiler to accelerate running Ruby code.
-* Generational Garbage Collector.
-* Integrated profiler.
-
-#### Known Issues
-
-* String#unpack and Array#pack are currently pretty slow. We're working
- on this issue and will release a fix in the near future.
-* A number of String methods are a bit slower than in 1.8. Most of these are
- known and being addressed.
-* We've added much of the MRI C-API for running Ruby extensions, but
- there are some extensions that don't work yet. Typically, this is because
- the extension uses RBASIC(), RHASH(), or RREGEXP(). These depend on MRI's
- internal object memory layout. In most cases, there are regular functions
- available to use that do not depend on MRI internals. We will help C
- extension authors to make their code portable. Additionally, extensions
- that fail due to a missing rb_* function should be reported in the issue
- tracker so that we can add the functions.
-* Neither the builtin debugger nor ruby-debug currently work. The debugger
- is a high-priority item to work on post 1.0.
-* The set_trace_func hook and the C event hooks are not supported. This
- means that rcov currently does not work. To profile your code, use our
- builtin profiler with the
- **-Xint -P**
- options on the command line.
diff --git a/about/one_point_one.markdown b/about/one_point_one.markdown
deleted file mode 100644
index d26b397..0000000
--- a/about/one_point_one.markdown
+++ /dev/null
@@ -1,158 +0,0 @@
----
-layout: release
-class: release
----
-
-## Overview
-
-The Rubinius team is proud to announce the availability of 1.0.1.
-
-1.0.1 is primarily a bugfix release, meant to address issues found in the 1.0.
-We decided to do a 1.0.1 because there were some installations issues found in
-1.0 that prevented some new users from using Rubinius. Additionally, a few
-crash bugs were uncovered which we felt warranted a quick release.
-
-As a bonus, this release includes fixes for running a number of popular gems.
-The C-API support is extended to cover functionality required by popular gems
-such as gherkin, curb, rjb/buildr, and many more.
-
-#### Stats
-
-* **Commits:** 199
-* **Days since last release:** 23
-
-#### Authors
-
-* Brian Ford
-* Dirkjan Bussink
-* Evan Phoenix
-* Ivan Samsonov
-* Matthew Draper
-* Mikko Perttunen
-* Wilson Bilkovich
-
-## Summary
-
-#### Critical
-
-* Update StackVariable::last_match_ in the GC. Fixes #287.
-* Set the stack start and size properly in a thread. @bugfix
-* Revise GIL unlocking to keep Thread::saved_call_frame_ sane
-* Handle very large values from getrlimit properly
-* Add flag to disallow direct allocation. Fixes #335.
-
-#### Fixes
-
-* Fixed defined?(a && b). Closes #302.
-* Fixed Fixnum and Bignum bit shifts.
-* Imported lib/matrix.rb from 1.9 with many bug fixes. @bugfix
-* Revert Matrix#** behavior for exception to 1.8 version. @bugfix
-* Changed libgdtoa g_dfmt() to emit MRI format for minimal, unique String representation of Float.
-* Added to_s_minimal primitive for Float#to_s.
-* Use send to reach private extend_object methods. Closes #324.
-* Don't use a increment operation and the original value in the same expression
-* Explicitly cast the return value of stack_pop() to void*
-* Initial work to enable compiling with clang
-* Use error state for read / write and print out the message
-* Generalize jit generation for fixnum comparison operations
-* Honor read-only-ness of certain globals. Fixes #283.
-* Escape slashes in Regexp#to_s output. Fixes #308.
-* Disambiguate a vcall send to the send_method opcode. Fixes #293.
-* Evaluate next's argument even though it's ignored. Fixes #307.
-* Report path to script bodies relatively. Fixes #308.
-* Remove Numeric#==
-* Use Kernel.exit! after a forked block returns. Fixes #289.
-* Fix fork to allow SystemExit through properly
-* Be persistant with write(2)
-* Handle object_id's for immediates. Fixes #315.
-* Alter protocol for how Proc with a bound method is invoked. Fixes #277.
-* Teach Signal.trap the rest of it's tricks. Fixes #314.
-* Make sure the arguments are Strings. @bugfix
-* Cleanup and speed up Struct
-* Add missing functionality to Signal.trap
-* Introduce -Xprofile to be used instead of -P
-* Cleanup and fix irb's save history feature
-* Search Object's includes also. Fixes #328
-* Make sure thet the default vis in a script body is private. Fixes #327
-* Make STDOUT.reopen(path) effect the system fd. Fixes #322.
-* Use the encoding of the Regexp in String#split on characters. Fixes #323
-* Be sure to cleanup any temp modifications during #delete_if
-* Let --enable-llvm do something. Fixes #336.
-* Add flag support to new Dir.glob, always use it
-* Handle write() setting EAGAIN properly
-* Handle ECONNRESET like eof. Fixes #338
-* Add UNIXSocket.pair
-* Add Inliner::fixnum_le, and self recursion cuteness
-* Simplify the Class#to_s of a metaclass (rails fix)
-* Allow Modules to be dup'd, but not String
-* Flip include order so that local LLVM wins
-* Fix left shifting for fixnums
-* Repair Bignum#divmod for cases with negative numbers. Fixes #319.
-* Speed up String#[] and String#=~
-* A Time is not eql? to a non-time.
-* Raise the right exception when alias fails in a module.
-* method_defined? shouldn't search Object/Kernel.
-* Print error messages to stderr instead of stdout.
-* Ensure the proper Regexp constant is found when processing literals
-* Introduce 'push_rubinius' instruction and use it like a rented mule
-* Factor out some jit code from push_cpath_top and push_rubinius
-* Quit as early as possible if we're building on an unsupported platform
-
-#### FFI
-
-* Search all iconv FFI libs.
-* Fix FFI::DynamicLibrary::Symbol#inspect
-* Exclude info generation from all in libffi. Fixes #286.
-* Add missing header files to scan for mode_t
-* FFI API revamp, take 1.
-
-#### C-API
-
-* Added rb_ary_delete.
-* Changed rb_set_errinfo to accept Qnil like 1.9.
-* Added HAVE_STDARG_PROTOTYPES for C-API. Closes #300.
-* Added OBJ_FREEZE for bluecloth gem.
-* Added more C-API functions to get rjb to load.
-* Only set status in rb_protect if it is not NULL.
-* More C-API functions for DL.
-* Added C-API HAVE_ macros for Hash.
-* Moved C-API .h files to include directory.
-* Moved C-API specs under spec/ruby/optional.
-* Fixed rb_big2dbl.
-* Add hacked rb_iterate/rb_each
-* Add rb_reg_regcomp
-* Annotate rb_raise as not returning to fix gherkin warnings. Fixes #309.
-* Add stub of re.h
-* Add missing symbols for curb
-* Add simplicit rb_thread_blocking_region
-* Provide builtin UBF macros
-* Flesh out C-API to compile ImageMagick. Fixes #294.
-* Make readline multithread aware and minor cleanup
-* Check for async events when returning from a native method
-* Check async events and raise an exception via rb_thread_select.
-* Fix INT2NUM to actually take a long, not an int.
-* Implement rb_is_{const,instance_class}_id() in CAPI.
-* rb_protect's callback takes a VALUE, not ANYARGS.
-* Add apparently-missed prototype for rb_apply()
-* Add rb_f_global_variables() and rb_str_new3().
-* rb_define_module_under() shouldn't return a parent's module.
-* Make rb_num2dbl handle all inputs correctly.
-* Set rbconfig's LIBS to "" to to appease mkrf
-* Set rbconfig's LIBRUBYARG_SHARED to "", because we don't have a shared library yet.
-* Add NativeMethod functors up to a ten-argument version
-
-#### New
-
-* Added NKF ext from MRI 1.8.7. Closes #304.
-* Imported DL extension from 1.8.7.
-
-#### EXPERIMENTAL
-
-* Rewire debugger infrastructure, add new simple debugger.
-* Add defered breakpoints to the debugger
-* Add backtrace and discover ability to QueryAgent
-* Started on the console, pulled in our own copy of bert
-* Revamp agent API, add a number of variables
-* Get jit.inline.blocks running again
-* Add Rubinius::Agent and agent loopback connection
-* Add -Xjit.sync
diff --git a/blog.html b/blog.html
deleted file mode 100644
index 4149715..0000000
--- a/blog.html
+++ /dev/null
@@ -1,18 +0,0 @@
----
-layout: blog
-comment_count: true
----
- {% include blog_nav.html %}
-
diff --git a/doc/de/appendix-a-glossary.markdown b/doc/de/appendix-a-glossary.markdown
deleted file mode 100644
index b733d82..0000000
--- a/doc/de/appendix-a-glossary.markdown
+++ /dev/null
@@ -1,189 +0,0 @@
----
-layout: doc_de
-title: Anhang A - Glossar
-previous: Anleitung - Übersetzen von Dokumentation
-previous_url: how-to/translate-documentation
-next: Anhang B - Literaturverzeichnis
-next_url: appendix-b-reading-list
-review: true
----
-
-Eine Auflistung von Begriffsdefinitionen und Phrasen die in der
-Programmiersprache Ruby und dieser Implementierung verwendet
-werden. Siehe auch "The Ruby Programming Language" von Flanagan und
-Matsumoto [O'Reilly 2008] und "Programming Ruby: The Pragmatic
-Programmer's Guide" 2. oder 3. Auflage von Thomas et al [The Pragmatic Programmers
-2005-2008]
-
-
-* _method lookup oder method resolution_
-
- Es ist ganz einfach: Nimm das Objekt im 'class slot' des Objekts
- (welches nicht immer dem Rückgabewert von Object#class sein muss;
- wenn das Objekt eines hat, ist es die Metaklasse) und beginne die
- Suche.
-
- Der Suchvorgang geht die Superklassen-Kette aufwärts bis die
- Superklasse nil ist.
-
- In dem Fall beginne den Vorgang von vorn, nur suche diesmal nach
- method_missing. Schlägt die Suche nach method_missing fehl, wirf
- einen Fehler (Exception).
-
- +----------------+
- | nil |
- +----------------+
- ^
- | superclass
- |
- +----------------+
- | Object |
- +----------------+
- ^
- | superclass
- |
- +----------------+
- | Module |
- +----------------+
- ^
- | superclass
- |
- +----------------+
- | Class |
- +----------------+
- ^
- | superclass
- |
- +----------------+
- | SingletonClass |
- | (Object) |
- +----------------+
- ^
- | superclass
- |
- +-------------+ +----------------+
- | F | -----------------> | SingletonClass |
- +-------------+ singleton class | (F) |
- +----------------+
-
-
- class Class
- def wanker
- puts 'you are'
- end
- end
-
- class F
- def self.bloke
- wanker
- end
- end
-
- 1. Finde Methode 'wanker' -- Durchsuche Methodentabellen in:
-
- 1. SingletonClass(F)
- 1. SingletonClass(Object)
- 1. Class
-
- Gefunden.
-
-
-* _method_table (Methodentabelle)_
-
- Eine Datenstruktur die in jeder Klasse (und jedem Modul) vorhanden
- ist und die definierten Methoden der Klasse enthält.
-
- In Rubinius ist die Methodentabelle eine Instanz der Klasse
- LookupTable.
-
-
-* _MatzRuby_
-
- Siehe MRI
-
-
-* _MRI_
-
- Matz's Ruby Interpreter oder Matz's Ruby Implementation. Eine
- Abkürzung mit der die offizielle Implementierung von Ruby gemeint
- ist. Siehe .
-
-
-* _private send (Privater Nachrichtenversand / Methodenaufruf)_
-
- Ein Methodenaufruf bei dem ein expliziter lexikalischer Empfänger
- (receiver) fehlt. Der Empfänger des Aufrufs ist +self+.
- Ein Beispiel:
-
- class A
- private
- def you_are_mine
- end
- end
-
- class B < A
- def sunshine
- you_are_mine
- end
- end
-
- class C
- def dear
- today = B.new
- today.you_are_mine
- end
- end
-
- Der Aufruf von +you_are_mine+ in der Methode +sunshine+ ist ein
- private Methodenaufruf (private send). Der Aufruf von
- +today.you_are_mine+ wird nicht gelingen, da private Methoden nicht
- einen expliziten Empfänger haben können. In diesem Fall ist +today+
- der explizite Empfänger.
-
-
-* _metaclass (Metaklasse)_
-
- Auch +singleton+ class oder +eigenclass+ genannt. Jedes Objekt in
- Ruby kann eine singleton Klasse haben, wobei diese nur nach Bedarf
- erzeugt werden. Die Metaklasse enthält die Methoden- und
- Konstantentabellen welche jeweils nur zu einer bestimmten
- Objektinstanz gehören.
- Zum Beispiel existiert die unten definierte Methode +hello+ nur in
- der Metaklasse von +obj+.
-
- obj = Object.new
- def obj.hello
- puts 'hi'
- end
-
- Da alle Klassen in Ruby ebenfalls Objekte sind, können diese auch
- Metaklassen besitzen. "Klassenmethoden" sind somit lediglich
- Methoden, die in der Metaklasse einer Klasse definiert (d.h. in der
- Methodentabelle der Metaklasse eingetragen) sind. Die Methode +honk+
- existiert in der Metaklasse der Klasse +Car+.
-
- class Car
- def self.honk
- end
- end
-
- In Rubinius sind Metaklassen Instanzen der Klasse +SingletonClass+. Die
- Metaklasse eines Objektes kann durch den Aufruf der +metaclass+ Methode
- erhalten werden. Insgesamt wird die Anordnung der dabei beteiligten Konzepte
- als "Meta-Object Protocol" oder +MOP+ bezeichnet.
-
-
-* _superclass (Superklasse)_
-
- Die Klasse von der eine bestimmte Klasse direkt erbt. Die Object
- Klasse ist die Superklasse aller Klassen die nicht explizit von
- einer anderen Klasse erben.
-
- class A
- end
-
- class B < A
- end
-
- Klasse A erbt von Object. Mit anderen Worten: A.superclass == Object.
- Klasse B erbt explizit von Klasse A. Also: B.superclass == A.
diff --git a/doc/de/appendix-b-reading-list.markdown b/doc/de/appendix-b-reading-list.markdown
deleted file mode 100644
index 20e4fac..0000000
--- a/doc/de/appendix-b-reading-list.markdown
+++ /dev/null
@@ -1,57 +0,0 @@
----
-layout: doc_de
-title: Anhang B - Literaturverzeichnis
-previous: Anhang A - Glossar
-previous_url: appendix-a-glossary
-next: Begriffsindex
-next_url: index-of-terms
-review: true
----
-
-Die Entwicklung von Virtuellen Maschinen im Allgemeinen und
-Programmiersprachenimplementierungen im Speziellen bedarf einiges an
-Wissen. Das Ziel von Rubinius ist es, den Einstieg in das Thema
-einfach zu halten. Dazu verfolgt Rubinius u.a. das Ziel, so viel wie
-möglich in Ruby selbst zu implementieren. Um aber am Garbage Collector
-mitzuentwickeln, muss man wissen was hinter den High-level Konzepten
-steckt.
-
-Diese Seite enthält Verweise auf Bücher, online Literatur, Blogposts
-und sonstige Publikationen die bei der Entwicklung an Rubinius
-behilflich sein können.
-
-Beachte, dass sich einige dieser Links auf veraltete Informationen
-bzgl. Rubinius beziehen können.
-
-## Virtuelle Maschine
-
- * [Smalltalk-80: language and its
- implementation](http://tinyurl.com/3a2pdq) by Goldberg, Robson,
- Harrison (aka "The Blue Book"), Kapitel zur Implementierung der VM
- aus Teil IV sind [online verfügbar](http://tinyurl.com/6zlsd)
- * [Virtual machines](http://tinyurl.com/3ydkqg) by Iain D. Craig
- * Sehr gute Posts von Adam Gardiner: [introduction](http://tinyurl.com/35y2jh),
- [How send sites work](http://tinyurl.com/34c6e8)
-
-
-## Garbage collection
-
- * [Garbage Collection: Algorithms for Automatic Dynamic Memory
- Management](http://tinyurl.com/3dygmo) by Richard Jones
- * [Garbage collection lectures](http://tinyurl.com/2mhek4)
-
-
-## Primitive methods
-
- * [Ruby extensions and Smalltalk
- primitives](http://talklikeaduck.denhaven2.com/articles/2007/06/04/ruby-extensions-vs-smalltalk-primitives)
- * [Guide to Squeak
- primitives](http://www.fit.vutbr.cz/study/courses/OMP/public/software/sqcdrom2/Tutorials/SqOnlineBook_(SOB)/englisch/sqk/sqk00083.htm)
-
-
-## FFI
-
- * [Implementing File#link using
- FFI](http://redartisan.com/2007/10/11/rubinius-coding)
- * [Rubinius' foreign function
- interface](http://blog.segment7.net/articles/2008/01/15/rubinius-foreign-function-interface)
diff --git a/doc/de/bootstrapping.markdown b/doc/de/bootstrapping.markdown
deleted file mode 100644
index 06e6767..0000000
--- a/doc/de/bootstrapping.markdown
+++ /dev/null
@@ -1,125 +0,0 @@
----
-layout: doc_de
-title: Bootstrapping
-previous: Bausystem
-previous_url: build-system
-next: Virtuelle Maschine
-next_url: virtual-machine
----
-
-Bootstrapping nennt man den Prozess bei dem sämtliche Funktionalität
-aufgebaut wird, die benötigt wird, sodass das System sämtlichen Ruby
-code ausführen kann. Es gibt sieben Phasen beim Bootstrapping Prozess:
-
- 1. VM: Die Virtuelle Maschine kann Bytecode laden und ausführen
- sowie Nachrichten versenden (d.h. Methoden finden und
- aufrufen). Alle primitiven Funktionen sind verfügbar aber noch
- nicht als Ruby methoden eingetragen.
-
- Die Klasse Class muss manuell eingerichtet werden. Dazu wird
- deren +class+ Eintrag auf sie selbst und deren +superclass+
- Eintrag auf Module gesetzt. Neben Class und Module werden
- desweiteren einige weitere Basisklassen erstellt, darunter
- Object, Tuple, LookupTable und MethodTable.
-
- Von dem Zeitpunkt an können Klassen definiert werden. Ca. 35
- eingebaute Klassen (built in classes) werden veranlasst sich
- selbst zu initialisieren, Symbole für die top level Methoden
- (:object_id, :call, :protected etc.) werden erstellt und
- grundlegende Exceptions werden definiert. Außerdem werden alle
- Primitiven Funktionen registriert. Schließlich wird das IO System
- eingerichtet und einige fundamentale Ruby methoden mit den
- entsprechenden Primitiven Funktionen verknüpft.
-
- Zu diesem Zeitpunkt ist genügend Funktionalität im System
- definiert um den Rest des Laufzeitsystems (Kernel) zu laden,
- welche komplett in Ruby geschrieben ist. Das Laden des Kernels
- geschieht in mehreren Pässen, bei der die Sprache wächst.
-
- 2. alpha: Hier started das Laden des Ruby Codes. Das Öffnen von
- Klassen und Modulen sowie Definieren von Methoden
- funktioniert. Die Mindestfunktionalität um die folgenden Methoden
- zu unterstützen ist in kernel/alpha.rb implementiert:
-
- attr_reader :sym
- attr_writer :sym
- attr_accessor :sym
- private :sym
- protected :sym
- module_function :sym
- include mod
-
- Außerdem ist es möglich Exceptions zu werfen und den laufenden
- Prozess abzubrechen (beenden). Diese Phase stellt das Fundament
- für die beiden folgenden Phasen dar.
-
- 3. bootstrap: Diese Phase fährt damit fort die Mindestfunktionalität
- einzurichten, die benötigt wird um platform und common zu
- laden. Zusätzlich werden die Primitiven Funktionen der meisten
- Kernel Klassen hinzugefügt.
-
- 4. platform: Das FFI (foreign function interface) System wird
- eingerichtet und Ruby Methodenschnittstellen zu
- plattformabhängigen Funktionen werden erstellt. Sobald dies getan
- ist werden weitere plattformabhängige Dinge wie Pointer,
- Dateizugriff, die math Funktionen und POSIX Befehle eingehängt.
-
- 5. common: Der Großteil der Ruby core Bibliothek und deren Klassen
- werden implementiert. Die Ruby core Klassen werden so
- Implementationsneutral wie möglich gehalten. Außerdem wird die
- meiste Funktionalität der Rubinius-spezifischen Klassen
- hinzugefügt.
-
- 6. delta: Entgültige Versionen von Methoden wie #attr_reader
- etc. werden hinzugefügt. Implementationsspezifische Versionen von
- Methoden welche die in common bereitgestellten Versionen
- überschreiben werden ebenfalls in das System übernommen.
-
- 7. loader: Die kompilierte Version von kernel/loader.rb wird ausgeführt.
-
- Die finale Phase richtet den Lebenszyklus eines Rubyprozesses
- ein. Dazu wird die VM mit dem System verbunden, Loadpaths werden
- gesetzt, Anpassungsskripte aus dem Heimverzeichnis werden gelesen
- und ausgeführt, System Signale werden gefangen und
- Kommandozeilenargumente verarbeitet.
-
- Danach wird entweder das übergebene Skript (Ruby Programmdatei)
- ausgeführt oder die interaktive Ruby Shell ausgeführt (IRB).
- Sobald dies beendet ist werden alle registrierten at_exit Blöcke
- ausgeführt, alle Objekte aufgeräumt (finalized) und der Prozess
- wird beendet.
-
-## Ladereihenfolge
-
-Die Dateien in den Kernel Verzeichnissen bootstrap, platform, common
-und delta implementieren die entsprechenden bootstrapping Phasen, die
-oben beschrieben wurden. Die Reihenfolge in der diese Verzeichnisse
-geladen werden ist in runtime/index angegeben.
-
-Wenn eine rbc Datei geladen ist wird Code im Script Level und in
-Klassen- und Modulrümpfen ausgeführt. Zum Beispiel, beim Laden von
-
- class SomeClass
- attr_accessor :value
- end
-
-wird der Aufruf zu #attr_accessor ausgeführt. Das setzt voraus, dass
-jeglicher Code der in Script-, Klassen- oder Modulrümpfen definiert
-ist vor der Datei geladen werden muss, die diesen ausführen/benutzen
-möchte. Die Datei kernel/alpha.rb definiert den Großteil des Codes der
-in Script- oder Modulrümpfen benötigt wird. Jedoch gibt es auch andere
-Ladereihenfolgeabhängigkeiten zwischen einigen Dateien in platform,
-common, delta und compiler.
-
-Diese Ladereihenfolgeabhängigkeiten sind in den load_order.txt Dateien
-beschrieben, die sich jeweils in jedem der kernel/\*\* Verzeichnissen
-befinden. Falls Code verändert oder hinzugefügt wird, wodurch weitere
-Ladereihenfolgeabhängigkeiten entstehen, müssen die entsprechenden
-load_order.txt Dateien angepasst werden. Dabei muss eine Datei von der
-eine andere Abhängt über dieser platziert werden. Außerdem muss bei
-Hinzufügen einer neuen Datei in den Kernel Verzeichnissen diese
-entsprechend in die load_order.txt des Ordners eingetragen werden. Die
-Dateien werden dann beim Bauprozess in die entsprechenden runtime/\*\*
-Verzeichnisse kopiert. Während jedem der oben genannten bootstrap
-Prozesse lädt die VM die Dateien in den load_order.txt Dateien gemäß
-ihrer Anordnung.
diff --git a/doc/de/build-system.markdown b/doc/de/build-system.markdown
deleted file mode 100644
index f9eb9e0..0000000
--- a/doc/de/build-system.markdown
+++ /dev/null
@@ -1,55 +0,0 @@
----
-layout: doc_de
-title: Build System
-previous: Specs - Compiler
-previous_url: specs/compiler
-next: Bootstrapping
-next_url: bootstrapping
-review: true
----
-
-TODO: Many details are missing.
-
-Rubinius uniformly uses Rake as the build system for its own files. However
-Rubinius also includes the source for several external libraries and these
-typically use makefiles.
-
-
-## Development versus Install Builds
-
-Rubinius consists of the executable, and various support files like the core
-and standard libraries. The executable needs to know where to find these files
-even if moved to a different location. To handle this problem, Rubinius
-distinguishes two build types: development and install. The executable stores
-the full path to its base directory, relative to which it expects to find the
-files it needs.
-
-The development executable stores the path to the source directory in which it
-was built. You can then move the executable to a different location but as you
-make changes to the core library files in the kernel/\*\* directories, the
-executable will continue to use those files.
-
-The install executable stores the path to the install directory. Again, even if
-the executable is moved to a new location, it will continue to find the
-installed files.
-
-This has consequences, of course. If you build a development executable and then
-rename your source directory, you will need to rebuild. Likewise, if you build an
-install executable and rename the install directory, the executable will *not*
-function, *even if the executable is in the directory*. The executable checks a
-single, hard-coded path. If this ends up being very painful for some reason,
-we'll revise it.
-
-
-## Installing Rubinius
-
-To install Rubinius, you must first configure it with an install prefix:
-
- ./configure --prefix=/path/to/install/dir
-
-The configure process creates a 'config.rb' file that specifies the key file
-paths that Rubinius uses. Once configured, run 'rake install' to build and
-install. The install procedure builds all the files, including compiling the
-Ruby standard library files in the lib/ directory, then copies them into the
-install location using the 'install' program. The install tasks are located in
-rakelib/install.rake.
diff --git a/doc/de/bytecode-compiler.markdown b/doc/de/bytecode-compiler.markdown
deleted file mode 100644
index 15ad60f..0000000
--- a/doc/de/bytecode-compiler.markdown
+++ /dev/null
@@ -1,18 +0,0 @@
----
-layout: doc_de
-title: Bytecode Compiler
-previous: Virtual Machine - Custom Dispatch Logic
-previous_url: virtual-machine/custom-dispatch-logic
-next: Parser
-next_url: bytecode-compiler/parser
-review: true
----
-
-The Rubinius bytecode compiler converts Ruby source code to bytecode that the
-virtual machine can execute.
-
-1. [Parser](/doc/en/bytecode-compiler/parser/)
-1. [AST](/doc/en/bytecode-compiler/ast/)
-1. [Compiler](/doc/en/bytecode-compiler/compiler/)
-1. [Transformations](/doc/en/bytecode-compiler/transformations/)
-1. [Generator](/doc/en/bytecode-compiler/generator/)
diff --git a/doc/de/bytecode-compiler/ast.markdown b/doc/de/bytecode-compiler/ast.markdown
deleted file mode 100644
index 2f3fdf8..0000000
--- a/doc/de/bytecode-compiler/ast.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_de
-title: Abstract Syntax Trees
-previous: Parser
-previous_url: bytecode-compiler/parser
-next: Compiler
-next_url: bytecode-compiler/compiler
-review: true
----
diff --git a/doc/de/bytecode-compiler/compiler.markdown b/doc/de/bytecode-compiler/compiler.markdown
deleted file mode 100644
index 8a7b460..0000000
--- a/doc/de/bytecode-compiler/compiler.markdown
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: doc_de
-title: Compiler
-previous: AST
-previous_url: bytecode-compiler/ast
-next: Transformations
-next_url: bytecode-compiler/transformations
-review: true
----
-
-TODO: document the compiler.
-
-The bytecode compiler walks the AST produced by the parser and emits bytecode
-for each node. The source for the compiler is in lib/compiler.
diff --git a/doc/de/bytecode-compiler/generator.markdown b/doc/de/bytecode-compiler/generator.markdown
deleted file mode 100644
index f791ef8..0000000
--- a/doc/de/bytecode-compiler/generator.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_de
-title: Generator
-previous: Transformations
-previous_url: bytecode-compiler/transformations
-next: JIT Compiler
-next_url: jit
-review: true
----
diff --git a/doc/de/bytecode-compiler/parser.markdown b/doc/de/bytecode-compiler/parser.markdown
deleted file mode 100644
index 60d6e35..0000000
--- a/doc/de/bytecode-compiler/parser.markdown
+++ /dev/null
@@ -1,17 +0,0 @@
----
-layout: doc_de
-title: Ruby Parser
-previous: Bytecode Compiler
-previous_url: bytecode-compiler
-next: AST
-next_url: bytecode-compiler/ast
-review: true
----
-
-The parser is a C extension named melbourne. It is basically the parser from
-MRI wrapped up in a way that can be used in Rubinius. The parser converts Ruby
-source code to an internal parse tree of nodes. The parse tree is processed by
-calling a Ruby method for each node. The processor is in
-lib/melbourne/processor.rb. The methods in the processor create Ruby objects
-that are nodes in an abstract syntax tree (AST). The AST is processed to
-generate bytecode.
diff --git a/doc/de/bytecode-compiler/transformations.markdown b/doc/de/bytecode-compiler/transformations.markdown
deleted file mode 100644
index 15f9304..0000000
--- a/doc/de/bytecode-compiler/transformations.markdown
+++ /dev/null
@@ -1,50 +0,0 @@
----
-layout: doc_de
-title: Compiler Transforms
-previous: Compiler
-previous_url: bytecode-compiler/compiler
-next: Generator
-next_url: bytecode-compiler/generator
----
-
-The bytecode compiler has a simple AST transform mechanism that recognizes
-certain AST forms and replaces them. The replaced forms emit different
-bytecode than the original form would have emitted. The source for the
-transforms is in lib/compiler/ast/transforms.rb
-
-TODO: document the compiler plugin architecture.
-
-
-### Safe Math Compiler Transform
-
-Since the core libraries are built of the same blocks as any other Ruby code
-and since Ruby is a dynamic language with open classes and late binding, it is
-possible to change fundamental classes like Fixnum in ways that violate the
-semantics that other classes depend on. For example, imagine we did the
-following:
-
- class Fixnum
- def +(other)
- (self + other) % 5
- end
- end
-
-While it is certainly possible to redefine fixed point arithmetic plus to be
-modulo 5, doing so will certainly cause some class like Array to be unable to
-calculate the correct length when it needs to. The dynamic nature of Ruby is
-one of its cherished features but it is also truly a double-edged sword in
-some respects.
-
-In the standard library the 'mathn' library redefines Fixnum#/ in an unsafe
-and incompatible manner. The library aliases Fixnum#/ to Fixnum#quo, which
-returns a Float by default.
-
-Because of this there is a special compiler plugin that emits a different
-method name when it encounters the #/ method. The compiler emits #divide
-instead of #/. The numeric classes Fixnum, Bignum, Float, and Numeric all
-define this method.
-
-The safe math transform is enabled during the compilation of the Core
-libraries to enable the plugin. During regular 'user code' compilation, the
-plugin is not enabled. This enables us to support mathn without breaking the
-core libraries or forcing inconvenient practices.
diff --git a/doc/de/contributing.markdown b/doc/de/contributing.markdown
deleted file mode 100644
index 81bdaa3..0000000
--- a/doc/de/contributing.markdown
+++ /dev/null
@@ -1,76 +0,0 @@
----
-layout: doc_de
-title: Mitmachen
-previous: Problemlösungen
-previous_url: getting-started/troubleshooting
-next: Kommunikation
-next_url: contributing/communication
----
-
-Das Rubinius Projekt freut sich über deine Beiträge. Es gibt viele Dinge, die
-dieses Projekt unterstützen können. Am wichtigsten ist, dass es etwas ist, was
-dich interessiert und was du gerne machst.
-
-Falls Du Fragen zu Rubinius hast, besuche uns am besten auf dem IRC Kanal
-#rubinius auf irc.freenode.net.
-
-Im folgenden findest du ein paar Ideen, was man für Rubinius tun könnte.
-
-## Teste Deinen Code
-
-Anwendungen sind oft weniger sanft als specs und decken Fehler auf, die unsere
-Tests auslassen. Lass dein Projekt unter Rubinius laufen und melde Fehler.
-Siehe hier, [wie man ein Ticket schreibt](/doc/de/how-to/write-a-ticket).
-
-## Hilfe
-
-Soweit es uns möglich ist, werden wir helfen. Bitte sieh aber auch nach, ob Du
-im Netz eventuell schon Antworten auf deine Fragen findest. Rubinius möchte
-ein Projekt sein, in das man sich leicht einarbeiten kann, an dem man lernt
-und natürlich auch beteiligt kann.
-
-Wir schätzen und nehmen einfache Fehlermeldungen gerne an, geben aber Tickets
-mit ausführlichen Fehlerberichten und Anweisungen zur Reproduktion des Fehlers
-eine höhere Priorität. Noch besser sind Fehlermeldungen, die RubySpecs
-beinhalten, die den Fehler genau eingrenzen und womöglich schon Patches
-mitliefern, die den Fehler beheben.
-
-## Schreibe Specs
-
- 1. Starte `bin/mspec tag --list incomplete `, um zu zeigen, dass die
- Specs als unvollständig markiert sind. Diese Specs müssen dann häufig nur
- nachgeprüft werden oder es fehlen einer bestimmten Klasse noch Specs.
-
- Hinweis: Du kannst auch ein pseudo-Verzeichnis ':files' für \
- angeben, das für alle auf Rubinius laufenden Specs die Tags anzeigt. Oder
- du gibst ein Unterverzeichnis des 'spec/' Verzeichnisses an, um nur die
- Tags für dieses Verzeichnis anzuzeigen.
-
- 2. Finde nicht vorgegebenes Verhalten. Siehe auch,
- [wie man Ruby Specs schreibt](/doc/de/how-to/write-a-ruby-spec).
-
-
-
-## Fehlerhafte Specs korrigieren
- 1. Starte `bin/mspec tag --list fails ` zum Anzeigen von erfolglosen
- Specs.
-
- Hinweis: Du kannst auch ein pseudo-Verzeichnis ':files' für \
- angeben, das für alle auf Rubinius laufenden Specs die Tags anzeigt. Oder
- du gibst ein Unterverzeichnis des 'spec/' Verzeichnisses an, um nur die
- Tags für dieses Verzeichnis anzuzeigen.
-
- 2. Wähle ein Spec, dass Du interessant findest und versuche einen Patch zu
- schreiben, dass ihn bestehen lässt.
-
-## Dokumentation
-
-Lerne wie Rubinius funktioniert und schreibe deine Erfahrungen auf, damit
-andere ebenso davon profitieren und verstehen, wie Rubinius implementiert ist.
-
-
-## Tickets sichten
- * Alte Tickets prüfen oder schließen
- * Minitests schreiben, die die Fehler reproduzieren. Anschließend prüfen,
- ob es schon Specs für diese Fälle gibt. Wenn nicht, evtl. welche schreiben.
-
diff --git a/doc/de/contributing/communication.markdown b/doc/de/contributing/communication.markdown
deleted file mode 100644
index eea8f8e..0000000
--- a/doc/de/contributing/communication.markdown
+++ /dev/null
@@ -1,18 +0,0 @@
----
-layout: doc_de
-title: Kommunikation
-previous: Mitmachen
-previous_url: contributing
-next: Stilvorlage
-next_url: contributing/style-guide
-review: true
----
-Das Rubinius Team schätzt jeden deiner Beiträge sehr. Da Rubinius aber ein
-großes und teilweise auch recht komplexes Projekt ist, kann Kommunikation
-manchmal eine echte Herausforderung sein. Wir benutzen aus diesem Grund
-hauptsächlich den englischsprachigen IRC Kanal, sind aber auch über andere
-Kommunikationswege verbunden. Wir können also hauptsächlich so erreicht werden:
-
-* IRC: `#rubinius` auf irc.freenode.net
-* Twitter: [twitter.com/rubinius](http://twitter.com/rubinius)
-* Mailing Liste: [Google Groups](http://groups.google.com/group/rubinius-dev)
diff --git a/doc/de/contributing/style-guide.markdown b/doc/de/contributing/style-guide.markdown
deleted file mode 100644
index 940435c..0000000
--- a/doc/de/contributing/style-guide.markdown
+++ /dev/null
@@ -1,103 +0,0 @@
----
-layout: doc_de
-title: Stilvorlage
-previous: Kommunikation
-previous_url: contributing/communication
-next: Ruby
-next_url: ruby
----
-
-Die folgenden Richtlinien haben das Ziel den Rubinius Code möglichst
-wartungsarm zu halten. Sollte es zu einer der Richtlinien Fragen geben,
-frag am besten auf dem #rubinius IRC Kanal auf irc.freenode.net nach.
-
-
-## Grundsätzliches
-
- * Stellen deinen Editor auf soft Tabs ein, nicht hard Tabs
- * Tabs sollen in zwei Leerzeichen umgewandelt werden
- * Füge an das Ende jeder Datei eine Leerzeile ein
-
-## C++ Code
- * Kein Leerzeichen zwischen Bedingung und Klammern
- Schreibe `if(1)` NICHT `if (1)`
-
- * Schreibe die öffnende Klammer auf die gleiche Zeile wie die
- Funktionsdeklaration oder die Bedingung
-
- * Verwende immer geschweifte Klammern, auch wenn man sie weglassen kann.
-
- * Schreibe Klammern zur Darstellung von Vorrang (soweit möglich)
-
- * Alternative Versionen von Funktionen sollten mit einer Erklärung zur
- Abweichung benannt werden. Gibt es z.B. eine Funktion 'person()' und du
- möchtest eine Funktion erstellen, die den Namen der Person annimmt, dann
- solltest du sie 'person_with_name(char \*name)' oder
- 'person_with_details(char \*name, ...)' nennen.
- Nicht jedoch 'person1(char \*name)'.
-
-## Ruby Code
-
- * Methoden: Versuche deine Methoden kurz zu halten--eine Bildschirmlänge
- als Anhaltspunkt und verwende DRY in sinnvollem Maße. Üblicherweise
- sollten häufig verwendete Funktionen abstrahiert und in Helfer-Methoden
- gepackt werden (die dann auch 'private' sein können). In manchen Fällen
- macht es keinen Sinn sich an DRY zu halten, z.B. wenn es um die Core
- Klassen geht. In diesen Fällen macht DRY alles nur unnötig kompliziert und
- man muss auf zu viele Spezialfälle in der Fehlerbehandlung eingehen.
-
- * Methodennamen sollten eindeutig, ausdrucksvoll, verständlich (und damit
- auf Englisch) sein. Verwende, bis auf wenige Ausnahmen, keine
- Unterstriche, um Methoden zu schützen ('\_\_send\_\_').
-
- * Smalltalkartige Methodennamen sind ok, d.h. du kannst Methoden mit
- `SomeClass.make_from` benennen, wenn damit `SomeClass.make_from file` oder
- `SomeClass.make_from :file => name` beabsichtig ist. Dabei
- _vervollständigt_ der Parameter `name` den Methodennamen
- und ermöglicht ein natürliches Lesen des Codes.
-
- * Variablennamen: Wähle eindeutige und ausdrucksstarke Namen (zu den üblichen
- Ausnahmen gehören z.B. Zählervariablen wie `i`). Vermeide es Methodennamen
- für Variablen zu verwenden. Üblich sind 'klass' an Stelle von 'class' oder
- 'idx' innerhalb von Arrays, da 'index' bereits als Methodenname existiert.
-
- * Verwende nachgefügte 'if' und 'unless' *nur* wenn deine Ausdrücke in eine
- Zeile passen *und* es nicht zu viele Bedingungen gibt.
-
- * Blöcke: Verwende entweder `do ... end` oder `{...}` mit Leerzeichen
- zwischen den Trennzeichen und dem Programmcode (`foo { |arg| code }`).
- Verteile lange oder komplexe Ausdrücke über mehrere Zeilen. Beispiel:
-
- mapped = foo.map do |elem|
- do_something_with elem
- end
-
- * Modul- und Klassendefinitionen werden mit Gültigkeitsbereich (Scope)
- versehen:
-
- module Rubinius::Profiler
- class Sampler
- end
- end
-
-## Kernel Code
-
-Die erste Richtlinie für den kompletten Kernel Code ist einfach und
-leistungsstark zu sein. Einfach geschriebener Code ist häufig effizienter und
-meist auch leichter nachzuvollziehen. Im Bootstrap Bereich sollte keine
-Metaprogrammierung stattfinden und die #attr_xxx Methoden sollten
-grundsätzlich im gesamten Kernel Code Anwendung finden. Ebenso sollten Alias
-Methoden und solche die als _private_ gekennzeichnet sind direkt im Anschluss
-an die Methodendefinition geschrieben werden (letzteres mittels
-`private :sym`). Denke daran, dass die Methoden, die die Alpha Stage (alpha.rb)
-durchlaufen, lediglich ein :symbol Argument annehmen.
-
-## Dokumentation
-
- * Nutze für die Dokumentation des Ruby Codes RDoc
-
- * Für C++ Code verwende Doxygen.
-
- * Für die im /doc Verzeichnis vorliegende Dokumentation verwende Markdown.
- Siehe [Markdown syntax](http://daringfireball.net/projects/markdown/syntax)
- Stelle die Textbreite auf 78 Zeichen und nutze harte Zeilenumbrüche.
diff --git a/doc/de/garbage-collector.markdown b/doc/de/garbage-collector.markdown
deleted file mode 100644
index c1d449f..0000000
--- a/doc/de/garbage-collector.markdown
+++ /dev/null
@@ -1,31 +0,0 @@
----
-layout: doc_de
-title: Garbage Collector (GC)
-previous: JIT Compiler
-previous_url: jit
-next: Junge Generation
-next_url: garbage-collector/nursery
-review: true
----
-
-## Einführung
-
-Rubinius implementiert einen [Generationellen Garbage Collector
-(GC)](http://de.wikipedia.org/wiki/Garbage_Collector#Generationell). Der
-Generationelle Garbage Collector von Rubinius regelt die dynamische
-Bereitstellung und Freigabe im Speicher eines Rubinius-Prozesses.
-
-## Definitionen
-
-1. Ein Objekt ist *aktuell*, wenn es mindestens eine Struktur (Variable) im
- Interpreter gibt, die dieses Objekt referenziert.
-1. Einen Durchlauf des GC nennt man *Sammlung*.
-1. Die Anzahl der GC-Durchläufe nennt man *GC-Zyklen* oder *GC-Sammlungen*.
-
-## Lebenszyklus eines Objekts
-
-1. [Junge Generation](/doc/de/garbage-collector/nursery/)
-1. [Mittlere Generation](/doc/de/garbage-collector/young-generation/)
-1. [Alte Generation](/doc/de/garbage-collector/mature-generation/)
-1. [Große Objekte](/doc/de/garbage-collector/large-objects/)
-
diff --git a/doc/de/garbage-collector/large-objects.markdown b/doc/de/garbage-collector/large-objects.markdown
deleted file mode 100644
index dcd14a4..0000000
--- a/doc/de/garbage-collector/large-objects.markdown
+++ /dev/null
@@ -1,24 +0,0 @@
----
-layout: doc_de
-title: Große Objekte
-previous: Alte Generation
-previous_url: garbage-collector/mature-generation
-next: Rubinius Systeme
-next_url: systems
-review: true
----
-
-Jedes Objekt, das eine definierte Bytezahl für große Objekte überschreitet, wird
-direkt im Speicher für großen Objekte angelegt. Auf diese Weise lassen sich
-zeit- und kostenaufwändige Operationen für Kopien vermeiden.
-
-Bemerkt sei, dass man die Anzahl der Bytes die eine *großes Objekt* ausmachen,
-anpassen kann. Der Standard hierbei sind 2700 Bytes.
-
- rbx … -Xgc.large_object= …
-
-Weitere Informationen über die vorhandenen Konfigurationsvariablen sind in der
-[Konfigurationsdatei der
-VM](https://github.com/rubinius/rubinius/blob/master/vm/configuration.hpp)
-einzusehen.
-
diff --git a/doc/de/garbage-collector/mature-generation.markdown b/doc/de/garbage-collector/mature-generation.markdown
deleted file mode 100644
index d107a1c..0000000
--- a/doc/de/garbage-collector/mature-generation.markdown
+++ /dev/null
@@ -1,24 +0,0 @@
----
-layout: doc_de
-title: Alte Generation
-previous: Mittlere Generation
-previous_url: garbage-collector/young-generation
-next: Große Objekte
-next_url: garbage-collector/large-objects
-review: true
----
-
-Alte Objekte sind Objekte, die aus der Mittleren Generation verlagert wurden,
-nachdem sie x Sammlungen überstanden haben.
-
-Autotune ist der Mechanismus, der benutzt wird, um die Anzahl der GC-Zyklen, die
-für eine Sammlung der Alten Generation benötigt werden, dynamisch anzupassen.
-Dieser kann ausgeschaltet werden oder es kann eine konstante Anzahl der nötigen
-GC-Zyklen via `gc.lifetime` angegeben werden. `gc.lifetime` ist die
-Ausgangsanzahl der Sammlungen, die für eine Sammlung der Alten Generation nötig
-sind.
-
-Weitere Informationen über die vorhandenen Konfigurationsvariablen sind in der
-[Konfigurationsdatei der
-VM](https://github.com/rubinius/rubinius/blob/master/vm/configuration.hpp)
-einzusehen.
diff --git a/doc/de/garbage-collector/nursery.markdown b/doc/de/garbage-collector/nursery.markdown
deleted file mode 100644
index 60e018a..0000000
--- a/doc/de/garbage-collector/nursery.markdown
+++ /dev/null
@@ -1,19 +0,0 @@
----
-layout: doc_de
-title: Junge Generation
-previous: Garbage Collector (GC)
-previous_url: garbage-collector
-next: Mittlere Generation
-next_url: garbage-collector/young-generation
-review: true
----
-
-Die erste Generation in der generationellen Garbage Collection von Rubinius ist
-die Junge Generation. Der Lebenszyklus eines Objekts beginnt in der Jungen
-Generation, wo es auch erstellt (bereitgestellt) wird.
-
-Objekte sind bis zur nächsten Sammlung Mitglied der Jungen Generation. Wenn ein
-Objekt nach der Sammlung immer noch aktuell ist, wird es in die Mittlere
-Generation verlagert. Eine Sammlung sorgt selbstständig dafür, dass Objekte
-verlagert werden.
-
diff --git a/doc/de/garbage-collector/young-generation.markdown b/doc/de/garbage-collector/young-generation.markdown
deleted file mode 100644
index a22acf7..0000000
--- a/doc/de/garbage-collector/young-generation.markdown
+++ /dev/null
@@ -1,25 +0,0 @@
----
-layout: doc_de
-title: Mittlere Generation
-previous: Junge Generation
-previous_url: garbage-collector/nursery
-next: Alte Generation
-next_url: garbage-collector/mature-generation
-review: true
----
-
-Objekte, die mehr als einen GC-Zyklus aktuell sind, werden Mitglied der
-Mittleren Generation. Ein Durchlauf des GC sorgt selbstständig dafür, dass
-Objekte in die Mittlere Generation verlagert werden.
-
-Objekte verbleiben für x Sammlungen im Raum der Mittleren Generation. x wird,
-abhängig davon, wie viele Objekte in die Alte Generation verlagert werden,
-dynamisch angepasst.
-
-Wenn *zu viele* Objekte während eines GC-Zyklus verlagert werden, steigt x.
-Wenn *nicht genug* Objekte während eines GC-Zyklus verlagert werden, sinkt x.
-
-Diese Regel besteht, damit die Verlagerungsrate konstant bleibt. Konstant
-bedeutet in diesem Kontext eine geringe Schwankung in der Anzahl der
-Verlagerungen pro Zyklus zu erlangen.
-
diff --git a/doc/de/getting-started.markdown b/doc/de/getting-started.markdown
deleted file mode 100644
index 5d70e65..0000000
--- a/doc/de/getting-started.markdown
+++ /dev/null
@@ -1,21 +0,0 @@
----
-layout: doc_de
-title: Erste Schritte
-previous: Was ist Rubinius?
-previous_url: what-is-rubinius
-next: Voraussetzungen
-next_url: getting-started/requirements
----
-
-Dieser Wegweiser wird dir helfen, Rubinius zum Laufen zu
-bringen. Dabei wird angenommen, dass du bereits einiges über Ruby und
-der Installation von Software auf deinem System weißt.
-
-Falls du Probleme mit den hier beschriebenen Anleitungen hast, besuche
-einfach den #rubinius IRC Kanal auf irc.freenode.net um zusätzliche
-Hilfe zu bekommen.
-
-1. [Voraussetzungen](/doc/de/getting-started/requirements/)
-1. [Rubinius bauen](/doc/de/getting-started/building/)
-1. [Rubinius ausführen](/doc/de/getting-started/running-rubinius/)
-1. [Problemlösungen](/doc/de/getting-started/troubleshooting/)
diff --git a/doc/de/getting-started/building.markdown b/doc/de/getting-started/building.markdown
deleted file mode 100644
index d6c236c..0000000
--- a/doc/de/getting-started/building.markdown
+++ /dev/null
@@ -1,69 +0,0 @@
----
-layout: doc_de
-title: Rubinius kompilieren
-previous: Abhängigkeiten
-previous_url: getting-started/requirements
-next: Rubinius ausführen
-next_url: getting-started/running-rubinius
----
-
-Rubinius kann vom Quellverzeichnis aus kompiliert und ausgeführt
-werden. Es muss nicht systemweit installiert werden, um laufen zu
-können. Die folgende Anleitung beschreibt die Installation von
-Rubinius sowie das Ausführen aus dem Quellverzeichnis.
-
-Rubinius nutzt [LLVM](http://llvm.org/) für den eingebauten JIT (Just-in-time)
-Compiler. Dabei hängt Rubinius von einer speziellen Version von LLVM
-ab und setzt voraus, dass LLVM mit C++ RTTI (run-time type
-information) Unterstützung gebaut wurde. Das `configure` Skript wird
-automatisch diese Voraussetzungen überprüfen, wenn es nach einer
-installierten Version von LLVM im System sucht. Falls du LLVM
-installiert hast und die Voraussetzungen nicht erfüllt sind
-bzw. Rubinius nicht korrekt mit der installierten Version von LLVM
-kompiliert, kannst du `--skip-system` als Kommandozeilenflag beim
-Aufruf des `configure` Skripts angeben. Dadurch wird automatisch die
-korrekte Version von LLVM heruntergeladen und zusammen mit Rubinius
-kompiliert.
-
-### Beschaffen des Quellcodes
-
-Der Rubinius Quellcode ist als Tarball und als Projekt auf Github
-verfügbar. Der Tarball kann [hier heruntergeladen
-werden](https://github.com/rubinius/rubinius/tarball/master).
-
-Um Git zu nutzen:
-
- 1. Wechsle in dein Entwicklungsverzeichnis
- 2. `git clone git://github.com/rubinius/rubinius.git`
-
-
-### Rubinius installieren
-
-Wir empfehlen Rubinius in ein Verzeichnis zu installieren, bei dem man
-weder `sudo` noch superuser Rechte braucht. Um Rubinius zu
-installieren, befolge die folgenden Schritte:
-
- 1. `./configure --prefix=/pfad/zum/installations/verzeichnis`
- 2. `rake install`
- 3. Folge den Anweisungen, um das _bin_ Verzeichnis von Rubinius deinem PATH hinzuzufügen
-
-Falls du vorhast Rubinius zur Ausführung deiner Anwendung zu
-nutzen, ist dies die bevorzugte Methode. Allerdings kannst du
-Rubinius auch direkt aus dem Quellverzeichnis ausführen. Mehr dazu im
-nächsten Abschnitt.
-
-### Aus dem Quellverzeichnis ausführen
-
-Für die Entwicklung an Rubinius selbst sollte diese Option gewählt
-werden.
-
- 1. `./configure`
- 2. `rake`
-
-Möchtest du Rubinius lediglich ausprobieren, folge den Anweisungen, damit
-das _bin_ Verzeichnis deinem PATH hinzuzugefügt wird.
-
-Falls du hingegen an Rubinius mitentwickeln willst, sollte das _bin_
-Verzeichnis _nicht_ deinem PATH hinzugefügt werden, da Rubinius einen
-eigenständigen Ruby Interpreter benötigt, um korrekt den bootstrap
-Prozess während des Kompiliervorgangs durchführen zu können.
diff --git a/doc/de/getting-started/requirements.markdown b/doc/de/getting-started/requirements.markdown
deleted file mode 100644
index 58804de..0000000
--- a/doc/de/getting-started/requirements.markdown
+++ /dev/null
@@ -1,48 +0,0 @@
----
-layout: doc_de
-title: Abhängigkeiten
-previous: Erste Schritte
-previous_url: getting-started
-next: Rubinius kompilieren
-next_url: getting-started/building
----
-
-Es sollte sichergestellt sein, dass die folgenden Programme und Bibliotheken
-installiert sind. Außerdem sollten auch die betriebssystemabhängigen
-Voraussetzungen (in den Unterabschnitten beschrieben) erfüllt sein.
-
-Im Folgenden eine Auflistung an vorgeschlagenen Links, um weitere Informationen
-über die Programme und Bibliotheken zu erhalten, die benötigt werden, um
-Rubinius erfolgreich zu bauen. Ggf. hält dein Betriebssystem oder Paketmanager
-andere/weitere Pakete bereit.
-
- * [GCC and G++ 4.x](http://gcc.gnu.org/)
- * [GNU Bison](http://www.gnu.org/software/bison/)
- * [MRI Ruby 2.0.0+](http://www.ruby-lang.org/) Falls Ruby 2.0.0
- nicht auf deinem System installiert ist, sollte
- [RVM](https://rvm.beginrescueend.com/) in Erwägung gezogen werden.
- * [Rubygems](http://www.rubygems.org/)
- * [Git](http://git-scm.com)
- * [ZLib](http://www.zlib.net/)
- * pthread - Die pthread Bibliothek sollte auf deinem System installiert sein.
- * [gmake](http://savannah.gnu.org/projects/make/)
- * [bundler](http://bundler.io/) `[sudo] gem install bundler`
-
-
-### Mac OS X
-
-Rubinius lässt sich am leichtesten installieren, wenn
-[XCode](http://developer.apple.com/technologies/xcode.html), die
-Entwicklungsumgebung von Apple, eingerichtet ist. Sobald diese installiert
-sind, kannst du developer mode crash reporting hier aktivieren:
-/Developer/Applications/Utilities/CrashReporterPrefs.app
-
-
-### Debian/Ubuntu
-
-Es gibt folgende Pakete die installiert werden sollten:
-
- * ruby-dev oder ruby1.8-dev
- * libreadline5-dev
- * zlib1g-dev
- * libssl-dev
diff --git a/doc/de/getting-started/running-rubinius.markdown b/doc/de/getting-started/running-rubinius.markdown
deleted file mode 100644
index 0c1df51..0000000
--- a/doc/de/getting-started/running-rubinius.markdown
+++ /dev/null
@@ -1,33 +0,0 @@
----
-layout: doc_de
-title: Rubinius ausführen
-previous: Rubinius kompilieren
-previous_url: getting-started/building
-next: Problemlösungen
-next_url: getting-started/troubleshooting
----
-
-Sobald die angegebenen Schritte zum Kompilieren (und ggf. Installieren) von
-Rubinius befolgt wurden, kann überprüft werden, ob alles richtig funktioniert:
-
- rbx -v
-
-Rubinius funktioniert generell wie Ruby von der Kommandozeile. Zum Beispiel:
-
- rbx -e 'puts "Hello!"'
-
-Um eine Ruby Datei 'code.rb' auszuführen:
-
- rbx code.rb
-
-Um IRB auszuführen:
-
- rbx
-
-Falls du das _bin_ Verzeichnis von Rubinius deinem PATH hinzugefügt hast,
-sollte es so funktionieren, wie man es auch bei MRI erwarten würde. Es gibt
-Befehle für `ruby`, `rake`, `gem`, `irb`, `ri` und `rdoc`.
-
-Das _bin_ Verzeichnis solltest du nur dann deinem PATH hinzufügen, wenn du
-Rubinius aktiv einsetzen möchtest. Ansonsten kann es zu Konflikten mit anderen,
-bereits installierten Rubies kommen.
diff --git a/doc/de/getting-started/troubleshooting.markdown b/doc/de/getting-started/troubleshooting.markdown
deleted file mode 100644
index 7170157..0000000
--- a/doc/de/getting-started/troubleshooting.markdown
+++ /dev/null
@@ -1,53 +0,0 @@
----
-layout: doc_de
-title: Problemlösungen
-previous: Rubinius ausführen
-previous_url: getting-started/running-rubinius
-next: Mitmachen
-next_url: contributing
----
-
-Im Folgenden werden Fehler beschrieben, die während des Kompilierens
-oder der Installation auftreten können sowie mögliche Ansätze zur Fehlerbehebung.
-
-Sollte es vorkommen, dass ein Fehler auftritt, stelle zuerst sicher, dass eine
-aktuelle, sauber ausgecheckte (clean checkout) Version von Rubinius
-vorliegt. Dazu können folgende Befehle im Rubinius Verzeichnis ausgeführt werden:
-
- $ git co master
- $ git reset --hard
- $ git pull
- $ rake distclean
- $ rake
-
-
-möglicher Fehler:
-
- ERROR: unable to find runtime directory
-
- Rubinius was configured to find the runtime directory at:
-
- /Users/brian/devel/rubinius/runtime
-
- but that directory does not exist.
-
- Set the environment variable RBX_RUNTIME to the location
- of the directory with the compiled Rubinius kernel files.
-
- You may have configured Rubinius for a different install
- directory but you have not run 'rake install' yet.
-
-Lösung:
-
- Falls Rubinius via `--prefix` konfiguriert wurde, führe `rake install` aus.
-
- Falls Rubinius via `--prefix` konfiguriert wurde und das
- Installationsverzeichnis nach der Installation umbenannt wurde, muss
- Rubinius neu konfiguriert und installiert werden.
-
- Das gleiche gilt für das Quellverzeichnis, das nach dem Kompilieren umbenannt
- wurde. Rubinius muss neu konfiguriert und installiert werden.
-
- Generell sollte das Quell- oder Kompilierverzeichnis nicht nach dem Kompilieren
- umbenannt werden.
-
diff --git a/doc/de/guides.markdown b/doc/de/guides.markdown
deleted file mode 100644
index 662d3aa..0000000
--- a/doc/de/guides.markdown
+++ /dev/null
@@ -1,11 +0,0 @@
----
-layout: doc_de
-title: Anleitungen
-previous: Tools - Speicher Analyse
-previous_url: tools/memory-analysis
-next: Anleitungen
-next_url: how-to
-review: true
----
-
-1. [Umstellung von MRI zu Rubinius](/doc/de/guides/migrating-from-mri-to-rubinius)
diff --git a/doc/de/guides/migrating-from-mri-to-rubinius.markdown b/doc/de/guides/migrating-from-mri-to-rubinius.markdown
deleted file mode 100644
index f98c9fb..0000000
--- a/doc/de/guides/migrating-from-mri-to-rubinius.markdown
+++ /dev/null
@@ -1,118 +0,0 @@
----
-layout: doc_de
-title: Umstellung von MRI zu Rubinius
-previous: Anleitungen
-previous_url: guides
-next: How-To
-next_url: how-to
----
-
-Diese Anleitung soll dir bei der Umstellung deiner Ruby oder Ruby on Rails
-Anwendung von MRI (Matz Ruby Interpreter) zu Rubinius helfen. Dabei wird davon
-ausgegangen, dass dir Grundlegende Begriffe und Programme wie Ruby, Ruby on
-Rails, Rubygems und Bundler bekannt sind. Ebenso wird angenommen, dass du dich
-im Terminal zurechtfindest.
-
-## 1. Rubinius installieren
-
-Der erste Schritt zum erfolgreichen Umstieg auf Rubinius ist die Installation
-von Rubinius. Da du beim Umstieg notwendigerweises zwischen MRI und Rubinius
-hin- und herwechseln willst, bietet es sich an, eines der Hilfsprogramme zu
-installieren, das den schnellen Wechsel zwischen unterschiedlichen
-Ruby-Versionen ermöglicht.
-
-Zur Verwendung mit Rubinius wird an dieser Stelle das Kommandozeilenprogramm
-[chruby](https://github.com/postmodern/chruby) empfohlen.
-
-### chruby und ruby-install installieren
-
-Verwendest du Mac OS X, ist es am einfachsten `chruby`und `ruby-install` mit
-Hilfe des [Homebrew](https://github.com/Homebrew/homebrew) Paket Managers zu
-installieren:
-
- $ brew update
- $ brew install chruby ruby-install
-
-Möchtest Du Homebrew nicht verwenden oder benutzt ein anderes Betriebssystem,
-dann schlage bitte weitere Installationsmöglichkeiten unter
-[chruby Installationshandbuch](https://github.com/postmodern/chruby#install) und
-dem [ruby-install Handbuch](https://github.com/postmodern/ruby-install#install)
-nach.
-
-Um `chruby` zu konfigurieren, füge die folgende Zeile zu deiner ~/.bashrc oder
-~/.zshrc:
-
- source /usr/local/opt/chruby/share/chruby/chruby.sh
-
-Beachte das Handbuch für weitere
-[Einstellungsmöglichkeiten](https://github.com/postmodern/chruby#configuration).
-
-### ruby-install verwenden
-
-Sobald du `ruby-install` eingerichtet hast, kann Rubinius installiert werden:
-
- $ ruby-install rbx 2.2.5
-
-Für Hilfen zur Installation weiterer Ruby-Implementierungen mit `ruby-install`,
-sei an dieser Stelle auf die
-[Installationshinweise](https://github.com/postmodern/ruby-install#synopsis)
-verwiesen.
-
-### chruby verwenden
-
-Sobald Rubinius installiert ist, kann es mit folgenden Befehl aktiviert werden:
-
- $ chruby rbx
-
-## 2. Gems
-
-Die meisten Gems, die unter MRI laufen, sollten auch unter Rubinius laufen. Den
-Ausnahmen ist ein besonderer Abschnitt weiter unten gewidmet. Darüber hinaus
-stellt Rubinius viele Systemkomponenten als zusätzliche Gems zur Verfügung.
-Darunter z.B. die Komponenten, die in Rubinius für das Parsen oder die
-Bytecodekompilierung zuständig sind. Ebenso stehen ein Debugger, ein Profiler
-und die Ruby Standardbibliothek zur Verfügung. Diese Gems werden mit Rubinius
-vorinstalliert.
-
-### C-Erweiterungs-Gems
-
-Viele Gems, die C-Erweiterungen verwenden, laufen problemlos unter Rubinius.
-Davon ausgenommen sind Gems, die auf interne Datenstrukturen von MRI
-zurückgreifen. Diese Gems können von Rubinius nicht unterstützt werden. Davon
-betroffen sind gems wie `ruby-debug` oder `ruby-prof`. Rubinius bringt dafür,
-wie oben erwähnt, einen eigenen Debugger und Profiler mit. Darüber hinaus auch
-noch weitere Hilfsprogramme. Eine Übersicht befindet sich auf den Seiten der
-[Hilfsprogramme](http://rubini.us/doc/de/tools/).
-
-## 3. Gemfiles
-
-Dein Gemfile sollte problemlos unter Rubinius laufen. Zuvor solltest du aber ein
-`bundle update` durchführen, damit alle Gem-Abhängigkeiten unter Rubinius erneut
-aufgelöst werden können. Werden Gems verwendet, die mit Rubinius inkompatibel
-sind, so können sie bis zur vollständigen Umstellung deiner Anwendung auf
-Rubinius in einem `platforms`-Block aufgeführt werden:
-
- # Beispiel für einen platforms Block für MRI-spzifische Gems
- platforms :mri do
- gem 'ruby-prof'
- gem 'ruby-debug'
- end
-
-## 4. Kompatibilitätsprobleme
-
-Rubinius hat das [RubySpec](http://rubyspec.org) Projekt ins Leben gerufen und
-erweitert es kontinuierlich. Es beschreibt das Verhalten von Ruby und beobachtet
-die Kompatibilität von Rubinius (wie auch anderer Implemtationen) zu MRI.
-
-Mit wenigen Ausnahmen ist Rubinius vollständig kompatibel zu MRI 2.1. Einige
-Funktionen, wie z.B. die sogenannten `keyword argumets`, sind bislang noch nicht
-implementiert. Andere Funktionen sind möglicherweise ebenfalls nicht
-implementiert, wenn sie z.B. unbekannt sind oder keine RubySpecs dazu
-existieren. Einige Komponenten der Standardbibliothek sind ebenfalls noch nicht
-implementiert, davon sind z.B. Continuation Ripper, TracePoint und Tracer
-betroffen. Möglicherweise wird dies in Zukunf noch nachgeholt.
-
-Sollte dir ein inkompatibles Verhalten von Rubinius im Vergleich zu MRI
-auffallen, ist es höchstwahrscheinlich ein Fehler und sollte [gemeldet
-werden](https://github.com/rubinius/rubinius/issues).
-
diff --git a/doc/de/how-to.markdown b/doc/de/how-to.markdown
deleted file mode 100644
index 5d0f5df..0000000
--- a/doc/de/how-to.markdown
+++ /dev/null
@@ -1,17 +0,0 @@
----
-layout: doc_de
-title: Anleitungen
-previous: Umstellung von MRI zu Rubinius
-previous_url: guides/migrating-from-mri-to-rubinius
-next: Ein Ticket erstellen
-next_url: how-to/write-a-ticket
-review: true
----
-
-1. [Ein Ticket erstellen](/doc/de/how-to/write-a-ticket/)
-1. [Ein Ruby Spec schreiben](/doc/de/how-to/write-a-ruby-spec/)
-1. [Einen fehlgeschlagenen Spec reparieren](/doc/de/how-to/fix-a-failing-spec/)
-1. [Benchmarks schreiben](/doc/de/how-to/write-benchmarks)
-1. [Einen Blogeintrag schreiben](/doc/de/how-to/write-a-blog-post/)
-1. [Dokumentation schreiben](/doc/de/how-to/write-documentation/)
-1. [Dokumentation übersetzen](/doc/de/how-to/translate-documentation/)
diff --git a/doc/de/how-to/fix-a-failing-spec.markdown b/doc/de/how-to/fix-a-failing-spec.markdown
deleted file mode 100644
index 6136a77..0000000
--- a/doc/de/how-to/fix-a-failing-spec.markdown
+++ /dev/null
@@ -1,46 +0,0 @@
----
-layout: doc_de
-title: Anleitung - Einen fehlgeschlagenen Spec reparieren
-previous: Einen Ruby Spec schreiben
-previous_url: how-to/write-a-ruby-spec
-next: Benchmarks schreiben
-next_url: how-to/write-benchmarks
----
-
-Die folgenden Abschnitte solltest du gelesen haben:
-
- * [Erste Schritte](/doc/de/getting-started/)
- * [Specs](/doc/de/specs/)
-
-Danach folge diesen Schritten, um einen fehlgeschlagenen Spec (Test) zu
-beheben:
-
- 1. Rufe `rake` auf, um sicher zu stellen, dass alle CI Specs bestehen.
- 2. Rufe `bin/mspec spec/some/spec_file.rb` auf, um zu bestätigen, dass der
- entsprechende Spec fehlschlägt.
- 3. Bearbeite eine Quelldatei in Rubinius (vermutlich irgendwo innerhalb des
- kernel Verzeichnisses).
- 4. Rufe `rake build` auf, um deine Veränderungen zu mitzukompilieren.
- 5. Rufe `bin/mspec spec/some/spec_file.rb` auf, um zu sehen ob deine
- Veränderungen den Spec zum Laufen bringen.
- 6. Wiederhole die obigen Schritte, bis der Spec nicht mehr fehlschlägt.
- 7. Rufe `rake` auf, um sicher zu stellen, dass es keine Regressionen gibt.
- 8. Wechsle in das root Verzeichnis von Rubinius, falls noch nicht geschehen.
- 9. Rufe `git status, git add, git commit` etc. auf. Jegliche Veränderungen
- die in den Spec Dateien gemacht wurden (innerhalb des spec/ruby
- Verzeichnisses) müssen als eigener Commit eingetragen werden und sollen
- nicht in den gleichen Commits landen wie Änderungen, die am restlichen
- Rubinius Quellcode gemacht wurden.
- 10. Rufe `git format-patch origin` auf, wodurch alle Commiteinträge, die im
- aktuellen Zweig seit dem letzten Pull von origin gemacht wurden,
- extrahiert werden. Alternativ, rufe `git format-patch -N' auf, wobei N
- die Zahl der Commiteinträge ist (1, 2 etc.), für die du Patches erstellen
- willst.
- 11. Erstelle ein Gist (auf http://gist.github.com) mit deinem Patch und
- verlinke es in einem neuen Ticket im Issuetracker auf Github:
- http://github.com/rubinius/rubinius/issues Es können mehrere Patches pro
- Ticket hinzugefügt werden.
-
-Wenn dein Patch vom Rubinius Projekt akzeptiert wird, erhältst du ein sog.
-Commit Bit, d.h. Schreibzugriff, auf das Rubinius Git Repository. Gib Evan
-bescheid, wie dein Github Benutzername ist.
diff --git a/doc/de/how-to/translate-documentation.markdown b/doc/de/how-to/translate-documentation.markdown
deleted file mode 100644
index 1d3912d..0000000
--- a/doc/de/how-to/translate-documentation.markdown
+++ /dev/null
@@ -1,40 +0,0 @@
----
-layout: doc_de
-title: Anleitung - Dokumentation übersetzen
-previous: Dokumentation schreiben
-previous_url: how-to/write-documentation
-next: Anhang A - Glossar
-next_url: appendix-a-glossary
----
-
-Die zwei wichtigsten Hilfen beim Übersetzen:
-
-1. Eine existierende Übersetzung aktualisieren oder verbessern
-1. Eine komplett neue Übersetzung anlegen
-
-Zunächst sollte
-[Anleitung - Schreibe Dokumentation](/doc/de/how-to/write-documentation/)
-gelesen werden.
-
-
-### Eine existierende Übersetzung aktualisieren oder verbessern
-
-Um eine existierende Übersetzung zu aktualisieren, öffne eine Themendatei unter
-`web/doc/LANG` und bearbeite den vorhandenen Text oder füge neu übersetzten
-Text ein.
-
-
-### Eine neue Übersetzung anlegen
-
-Um eine neue Übersetzung für eine weitere Sprache anzulegen, gehe wie folgt
-vor:
-
-1. Kopiere `web/doc/en` nach `web/doc/LANG`, wobei _LANG_ der
- [ISO-639-1](http://en.wikipedia.org/wiki/List_of_ISO_639-2_codes) Code ist,
- der beim Anlegen einer neuen Sprache maßgeblich ist.
-1. Bearbeite die Links im Inhaltsverzeichnis so, dass diese auf die übersetzten
- Dateien verweisen. (Beachte, dass aus derzeit unbekannten Gründen das
- `page.base_dir` Attribut nicht verfügbar ist, wenn diese Dateien von Jekyll
- generiert werden. Das Problem muss noch untersucht werden.)
-1. Übersetzte (nach Möglichkeit) den englischen Text in die Zielsprache, damit
- die Übersetzung möglichst aktuell ist.
diff --git a/doc/de/how-to/write-a-blog-post.markdown b/doc/de/how-to/write-a-blog-post.markdown
deleted file mode 100644
index d171b22..0000000
--- a/doc/de/how-to/write-a-blog-post.markdown
+++ /dev/null
@@ -1,31 +0,0 @@
----
-layout: doc_de
-title: Anleitung - Einen Blogeintrag schreiben
-previous: Benchmarks schreiben
-previous_url: how-to/write-benchmarks
-next: Dokumentation schreiben
-next_url: how-to/write-documentation
----
-
-Der Rubinius Blog benutzt Jekyll und ist in die Webseite sowie die
-Dokumentationsseiten integriert. Wir unterstützen und schätzen Gasteinträge
-über Erfahrungen, die beim Nutzen und Entwickeln von Rubinius gemacht wurden.
-
-Für den Einstieg sollte sichergestellt sein, dass die `kramdown` and
-`jekyll` Gems installiert sind.
-
- rbx gem install jekyll kramdown
-
-Das bevorzugte Format für Blogeinträge ist Markdown. Falls allerding spezielle
-Formatierungsoptionen benötigt werden, kann der Eintrag auch direkt in HTML
-verfasst werden.
-
-1. Erstelle eine Datei in `web/_posts/` mit dem Format
- `YYYY-MM-DD-perma-link.markdown` als Dateinamen
-1. Schreibe den Eintrag
-1. Im `web/` Verzeichnis, führe `rbx -S jekyll build` aus
-1. Erstelle einen Commiteintrag mit allen Veränderungen im `web/` Verzeichnis.
-1. Reiche einen Patch ein oder falls du Commitrechte besitzt push den
- Commiteintrag in den master Zweig.
-1. Sag uns bescheid, wenn es einen neuen Blogeintrag gibt. Eventuell haben wir
- ein paar Rückmeldungen bzgl. deines Eintrags bevor er veröffentlicht wird.
diff --git a/doc/de/how-to/write-a-ruby-spec.markdown b/doc/de/how-to/write-a-ruby-spec.markdown
deleted file mode 100644
index a2e4449..0000000
--- a/doc/de/how-to/write-a-ruby-spec.markdown
+++ /dev/null
@@ -1,26 +0,0 @@
----
-layout: doc_de
-title: Anleitung - Einen Ruby Spec schreiben
-previous: Ein Ticket erstellen
-previous_url: how-to/write-a-ticket
-next: Einen fehlgeschlagenen Spec reparieren
-next_url: how-to/fix-a-failing-spec
----
-
-Du solltest folgende Artikel gelesen haben:
-
- * [Erste Schritte](/doc/de/getting-started/)
- * [Specs](/doc/de/specs/)
-
-Anschließend folge diesen Schritten, um einen Spec für eine Ruby Methode zu
-schreiben:
-
- 1. Bearbeite eine Datei unter `spec/ruby/...`
- 2. Führe `bin/mspec -tr spec/ruby/some/spec_file.rb` aus
- 3. Wiederhole die obigen Schritte so lange, bis der Spec auf MatzRuby (MRI)
- besteht
- 4. Sende ein Commit mit deinen Anderungen
- 7. Führe `git format-patch` aus
- 8. Erstelle ein Gist (auf http://gist.github.com) mit deinem Patch und
- verlinke diesen in einem Ticket auf dem Issuetracker:
-
diff --git a/doc/de/how-to/write-a-ticket.markdown b/doc/de/how-to/write-a-ticket.markdown
deleted file mode 100644
index 8ddd77c..0000000
--- a/doc/de/how-to/write-a-ticket.markdown
+++ /dev/null
@@ -1,150 +0,0 @@
----
-layout: doc_de
-title: Anleitung - Ein Ticket erstellen
-previous: Anleitungen
-previous_url: how-to
-next: Einen Ruby Spec schreiben
-next_url: how-to/write-a-ruby-spec
----
-
-Den Rubinius Issuetracker findest du hier:
-.
-
-Damit ein Ticket nützlich ist, sollte es prägnant, fokussiert und umsetzbar
-sein. Falls es diese Kriterien nicht erfüllt, wird es vermutlich nur den
-Issuetracker zumüllen. Deshalb sollten Tickets mindestens einer der folgenden
-Kategorien zugeordnet werden können:
-
- 1. Eine vollständige Kommandozeilenhistorie liegt vor, die aufzeigt, wie das
- Programm installiert und aufgerufen wurde sowie den Backtrace des
- aufgetretenen Fehlers wiedergibt.
- 2. Ein kurzes Stück Beispielcode, der das Problem illustriert sowie einein
- Kommandozeilenbefehl, um den Code auszuführen.
- 3. Ein Patch **inklusive Specs, falls es noch keine äquivalenten
- gibt** sowie ein Auszug der darstellt, wie die Specs sich vor und nach
- Anwendung des Patches verhalten.
-
-Falls die Angelegenheit nicht in eine der oben genannten Kategorien passt,
-heißt das nicht, dass sie unwichtig ist. Für Ticket ist es lediglich
-unzureichend.
-
- 1. Falls es sich um ein Feature handelt, solltest du in Betracht ziehen, es
- auf der Mailingliste zur Diskussion zu stellen. Natürlich kannst du
- außerdem auch versuchen es selbst zu implementieren und zu zeigen, warum
- und wie dein Feature nützlich sein kann.
-
- 2. Falls es sich um eine Bibliothek oder Gem handelt, das nicht korrekt
- funktioniert nimm dir etwas Zeit und versuche den Fehler zu reproduzieren
- und beschreibe daraufhin die Reproduktion in einem neuen Ticket.
-
-
-## Genereller Ablauf zur Erstellung eines Tickets
-
- 1. Doppelte Überprüfung.
-
- 1. Kompiliere Rubinius komplett neu ('rake clean; rake') nachdem du
- 'git pull' ausgeführt hast oder einen frischen Klon des Repositories
- erstellt hast.
- 2. Lies [Problemlösungen](/doc/de/getting-started/troubleshooting),
- um zu sehen, ob eine der dortigen Anleitungen das Problem beheben kann.
- 3. Lies [Specs](/doc/de/specs/).
-
- 2. Gib deinem Ticket einen spezifischen, vorzugsweise kurzen Titel
-
- 3. Beschreibe dein Ticket mit angemessenen Tags.
-
- 4. Belege dein Ticket mit hinreichend Details bzgl. des Problems.
-
- * Der Kommandozeilenbefehl, um das Programm auszuführen.
- * Der Backtrace oder das Ergebnis entgegen dem erwarteten Ergebnis.
- * Informationen über deinen Rechner und System. `uname -a` ist
- normalerweise gut (falls es irgengwelche "unknown" Felder
- gibt, erkläre/beschreibe diese bitte.)
-
-
-## Zusätzliche Instruktionen für Tickets mit angehängten Patches
-
- * Einfach nur ein paar Specs.
- * Patches müssen zusätzlich mit Specs versehen sein, es sei denn die Specs
- existieren bereits.
- * Relevante Teile der Spec Ausgabe und der exakte 'bin/mspec' Aufruf von dem
- existierenden oder hinzugefügten Spec *vor* der Veränderung.
- * Die Spec Ausgabe und der exakte 'bin/mspec' Aufruf, bei dem ein
- erfolgreicher Durchlauf *nach* der Veränderung zu sehen ist.
- * Zusätzliche Beschreibungen/Kommentare deines Patches und wie er das
- Problem löst. Insbesondere dann, wenn neue Features hinzugefügt wurden,
- sollte darauf verwiesen werden, ob der Inhalt des Tickets bereits in
- #rubinius (IRC) oder ruby-dev (Mailingliste) diskutiert wurde.
-
-Abgesehen von Fällen, bei denen es aus irgendwelchen Gründen unmöglich ist,
-sollte 'git-format-patch' benutzt werden, um den Patch zu erstellen. Das macht
-das Einbringen des Patches wesentlich einfacher und er erhält die korrekte
-Zuordnung. Ansonsten sollte ein 'unified diff' verwendet werden.
-
-## Beispiel für das Einreichen eines Patches
-
-Angenommen, der folgende Spec existiert und schlägt fehl:
-
- describe "Kernel.format" do
- it "is accessible as a module function" do
- Kernel.format("%s", "Hallo").should == "Hallo"
- end
- end
-
-1. Ticket Titel:
-
- "[PATCH] No method 'format' on Kernel (Module)"
-
-2. Tags:
-
- "patch core spec"
-
-3. Ticket Nachricht (natürlich auf Englisch)
-
- The method 'format' is not available as a module function of Kernel.
-
- $ bin/mspec spec/ruby/core/kernel/format_spec.rb
- Started
- .E
-
- 1)
- Kernel.format is accessible as a module function ERROR
- No method 'format' on Kernel (Module):
-
- The method 'format' already exists but has not been set as a module
- function. This patch does so.
-
- After the patch is applied:
-
- $ bin/mspec spec/ruby/core/kernel/format_spec.rb
- Started
- ..
-
- Finished in 0.016031 seconds
-
- 2 examples, 2 expectations, 0 failures, 0 errors
-
-4. Anhang:
-
-Schließlich, packst du deinen Patch in ein Gist und fügst den Link dazu in
-dein Ticket ein. Der Vollständigkeit halber siehst du unten den Patch aus dem
-obigen Beispiel:
-
- From c61cecce6442347ebbdf1ded7a5c0832c97582c1 Mon Sep 17 00:00:00 2001
- From: Brian Ford
- Date: Sat, 19 Jan 2008 17:48:19 -0800
- Subject: [PATCH] Set Kernel#format as a module function.
-
-
- diff --git a/kernel/core/kernel.rb b/kernel/core/kernel.rb
- index 2d2e508..f2a382e 100644
- --- a/kernel/core/kernel.rb
- +++ b/kernel/core/kernel.rb
- @@ -150,6 +150,7 @@ module Kernel
- end
- alias_method :format, :sprintf
- module_function :sprintf
- + module_function :format
- module_function :abort
-
- def puts(*a)
diff --git a/doc/de/how-to/write-benchmarks.markdown b/doc/de/how-to/write-benchmarks.markdown
deleted file mode 100644
index 1dab3bc..0000000
--- a/doc/de/how-to/write-benchmarks.markdown
+++ /dev/null
@@ -1,35 +0,0 @@
----
-layout: doc_de
-title: Anleitung - Benchmarks schreiben
-previous: Einen fehlgeschlagenen Spec reparieren
-previous_url: how-to/fix-a-failing-spec
-next: Einen Blogeintrag schreiben
-next_url: how-to/write-a-blog-post
----
-
-Warum Benchmarks?
-
-Benchmarks sind ein hervorragendes Hilfsmittel, um Rubinius mit den anderen
-Ruby Implementationen, wie z.B. MRI, JRuby, IronRuby und anderen, zu
-vergleichen. Dabei geht es weniger darum, Rubinius selber zu messen, sondern
-Vergleichswerte zu erzielen. Möchtest du Benchmarks schreiben, dann achte bitte
-auf folgende Richtlinien:
-
- 1. Schau dir bestehende Benchmarks unter rubinius/benchmarks an und versuche
- dem Schema zu folgen.
- 2. Jede Benchmark-Datei sollte sich auf einen besonderen Aspekt von Ruby
- konzentrieren, beispielsweise dem Löschen von Schlüsseln und Werten in
- Hashes.
- 3. Verwende das interne Benchmark-Framework.
- 4. Benchmarks sollten kurz und prägnant sein.
- 5. Die Benchmarks messen nicht Rubinius. Schreibst du also ein Benchmark für
- eine Klasse, die über sog. Bang-Methoden (also das Objekt verändernde
- Methoden, meist mit einem Ausrufezeichen versehen) und
- Nicht-Bang-Methoden verfügt, dann solltest du für die Bang-Methode das
- Objekt duplizieren, nicht jedoch für die Nicht-Bang-Methode.
-
-Zum Testen der Benchmarks kannst einzelne Dateien oder auch ganze Ordner
-übergeben:
-
- bin/benchmark benchmark/core/string/bench_case.rb
- bin/benchmark benchmark/core
diff --git a/doc/de/how-to/write-documentation.markdown b/doc/de/how-to/write-documentation.markdown
deleted file mode 100644
index 84008a5..0000000
--- a/doc/de/how-to/write-documentation.markdown
+++ /dev/null
@@ -1,78 +0,0 @@
----
-layout: doc_de
-title: Anleitung - Dokumentation schreiben
-previous: Einen Blogeintrag schreiben
-previous_url: how-to/write-a-blog-post
-next: Dokumentation übersetzen
-next_url: how-to/translate-documentation
----
-
-Die Dokumentation für Rubinius ist integriert mit der Website und dem Blog. Sie
-nutzt genau wie die übrigen Komponenten Jekyll.
-
-Um zu starten, stelle sicher, dass du die `kramdown` und `jekyll` Gems
-installiert hast.
-
- rbx gem install jekyll kramdown
-
-Die Dokumentationsquellen befinden sich im `web/doc` Verzeichnis. Es existieren
-dort Unterverzeichnisse für alle Sprachen, die bereits in einer Übersetzung
-vorliegen (wie z.B. diese deutschen Übersetzung).
-
-Jede Übersetzung besitzt ein Inhaltsverzeichnis
-(z.B. `/web/doc/en/index.markdown`). Der Rest der Dokumentation besteht aus
-einzelnen Dateien, die YAML Attribute benutzen, um anzugeben, wie die Dokumente
-zueinander in Beziehung stehen. Im Prinzip kann man die Dokumentation als eine
-doppelt verkettete Liste von Dokumenten verstehen, bei der jedes Dokument auf
-ein Vorgänger- sowie einen Nachfolgedokument verweist. Das Inhaltsverzeichnis
-zeigt dabei die komplette Struktur aller übrigen Dokumente an.
-
-Die YAML Attribute in einem Dokument sehen in etwa wie folgt aus:
-
- ---
- layout: doc_en
- title: How-To - Write Documentation
- previous: Write a Blog Post
- previous_url: how-to/write-a-blog-post
- next: Translate Documentation
- next_url: how-to/translate-documentation
- ---
-
-Das _layout_ gibt an, welches Jekyll Layout bei der Formatierung des Dokuments
-genutzt werden soll. Das _layout_ sollte `doc_LANG` entsprechen, wobei _LANG_
-ein ISO-639-1 Code für die Sprache ist (z.B. de, en, pl, es etc.).
-
-Das _title_ gibt den Dokumententitel an, der am oberen Rand der Seite
-dargestellt wird.
-
-Die _previous_ und _previous\_url_ Attribute stellen den Titel sowie Link zum
-vorherigen Dokument dar. Gleichermaßen entsprechen die _next_ und _next\_url_
-Attribute dem Titel und Link zum folgenden Dokument. Diese werden benutzt, um
-das Lesen und Durchstöbern der Dokumentation zu vereinfachen und den
-Arbeitsaufwand beim Neuordnen von Dokumentationsabschnitten zu minimieren.
-
-### Vorhandene Dokumentation bearbeiten
-
-Ein anfänglicher Entwurf für die Dokumentation wurde bereits erstellt. Es gibt
-aber noch viele Themen, die einer vertiefenden Dokumentation bedürfen.
-
-Um Dokumentation für ein bestehendes Thema hinzuzufügen oder vorhandene
-Dokumentation zu verbessern, öffne die Datei für das jeweilige Thema unter
-`web/doc/LANG` und füge dort neue Dokumentation hinzu oder überarbeite diese.
-
-### Neue Dokumentation hinzufügen
-
-Um neue Dokumentation für bisher nicht dokumentierte Themen hinzuzufügen:
-
-1. Erstelle eine neue Datei mit der .markdown Dateiendung unter `web/doc/LANG`.
-1. Richte die YAML Attribute ein, sodass auf die neue Datei innerhalb der
- existierenden Dokumente verlinkt wird. Dies erfordert das Bearbeiten der
- _previous_ and _next_ Attribute der bereits vorhandenen Dateien, um die neue
- Datei einzufügen. Ebenso muss ein Eintrag in der `index.markdown` gemacht
- werden.
-1. Damit du Veränderungen noch beim Bearbeiten überprüfen kannst, führe
- folgenden Befehl aus und besuche die vom Server angegebene URL:
- `rbx -S jekyll serve --watch`
-1. Bearbeite die neue Datei mit dem Markdown Syntax.
-1. Im `web/` Verzeichnis, führe `rbx -S jekyll build` aus.
-1. Mach ein Commit für alle Veränderungen im `web/` Verzeichnis.
diff --git a/doc/de/index-of-terms.markdown b/doc/de/index-of-terms.markdown
deleted file mode 100644
index 04130c8..0000000
--- a/doc/de/index-of-terms.markdown
+++ /dev/null
@@ -1,7 +0,0 @@
----
-layout: doc_de
-title: Index of Terms
-previous: Appendix B - Reading List
-previous_url: appendix-b-reading-list
-review: true
----
diff --git a/doc/de/index.markdown b/doc/de/index.markdown
deleted file mode 100644
index c978452..0000000
--- a/doc/de/index.markdown
+++ /dev/null
@@ -1,70 +0,0 @@
----
-layout: doc_de
-title: Inhaltsverzeichnis
-toc: true
-next: Was ist Rubinius?
-next_url: what-is-rubinius
----
-
-1. [Was ist Rubinius?](/doc/de/what-is-rubinius/)
-1. [Erste Schritte](/doc/de/getting-started/)
- 1. [Voraussetzungen](/doc/de/getting-started/requirements/)
- 1. [Rubinius bauen](/doc/de/getting-started/building/)
- 1. [Rubinius ausführen](/doc/de/getting-started/running-rubinius/)
- 1. [Problemlösungen](/doc/de/getting-started/troubleshooting/)
-1. [Mitmachen](/doc/de/contributing/)
- 1. [Kommunikation](/doc/de/contributing/communication/)
- 1. [Stilvorlage](/doc/de/contributing/style-guide)
-1. [Ruby](/doc/de/ruby/)
- 1. [Scripte](/doc/de/ruby/scripts/)
- 1. [Methoden](/doc/de/ruby/methods/)
- 1. [Konstanten](/doc/de/ruby/constants/)
- 1. [Klassen & Module](/doc/de/ruby/classes-and-modules/)
- 1. [Blöcke & Procs](/doc/de/ruby/blocks-and-procs/)
- 1. [Lokale Variablen](/doc/de/ruby/local-variables/)
- 1. [Instanzvariablen](/doc/de/ruby/instance-variables/)
- 1. [Klassenvariablen](/doc/de/ruby/class-variables/)
- 1. [Globale Variablen](/doc/de/ruby/global-variables/)
-1. [Specs](/doc/de/specs/)
- 1. [RubySpec](/doc/de/specs/rubyspec/)
- 1. [Compiler](/doc/de/specs/compiler/)
-1. [Build System](/doc/de/build-system/)
-1. [Bootstrapping](/doc/de/bootstrapping/)
-1. [Virtuelle Maschine](/doc/de/virtual-machine/)
- 1. [Instruktionen](/doc/de/virtual-machine/instructions/)
- 1. [Benutzerdefinierte Dispatch Logik](/doc/de/virtual-machine/custom-dispatch-logic/)
-1. [Bytecode Compiler](/doc/de/bytecode-compiler/)
- 1. [Parser](/doc/de/bytecode-compiler/parser/)
- 1. [AST](/doc/de/bytecode-compiler/ast/)
- 1. [Compiler](/doc/de/bytecode-compiler/compiler/)
- 1. [Transformationen](/doc/de/bytecode-compiler/transformations/)
- 1. [Generator](/doc/de/bytecode-compiler/generator/)
-1. [JIT Compiler](/doc/de/jit/)
-1. [Garbage Collector](/doc/de/garbage-collector/)
- 1. [Junge Generation](/doc/de/garbage-collector/nursery/)
- 1. [Mittlere Generation](/doc/de/garbage-collector/young-generation/)
- 1. [Alte Generation](/doc/de/garbage-collector/mature-generation/)
- 1. [Große Objekte](/doc/de/garbage-collector/large-objects/)
-1. [Rubinius Systeme](/doc/de/systems/)
- 1. [Primitive](/doc/de/systems/primitives/)
- 1. [FFI](/doc/de/systems/ffi/)
- 1. [Concurrency / Nebenläufigkeit](/doc/de/systems/concurrency/)
- 1. [IO](/doc/de/systems/io/)
- 1. [C-API](/doc/de/systems/c-api/)
-1. [Tools](/doc/de/tools/)
- 1. [Debugger](/doc/de/tools/debugger/)
- 1. [Profiler](/doc/de/tools/profiler/)
- 1. [Speicher Analyse](/doc/de/tools/memory-analysis/)
-1. [Anleitungen](/doc/de/guides/)
- 1. [Umstellung von MRI zu Rubinius](/doc/de/guides/migrating-from-mri-to-rubinius/)
-1. [Anleitungen](/doc/de/how-to/)
- 1. [Ein Ticket erstellen](/doc/de/how-to/write-a-ticket/)
- 1. [Einen Ruby Spec schreiben](/doc/de/how-to/write-a-ruby-spec/)
- 1. [Einen fehlgeschlagenen Spec reparieren](/doc/de/how-to/fix-a-failing-spec/)
- 1. [Benchmarks schreiben](/doc/de/how-to/write-benchmarks)
- 1. [Einen Blogeintrag schreiben](/doc/de/how-to/write-a-blog-post/)
- 1. [Dokumentation schreiben](/doc/de/how-to/write-documentation/)
- 1. [Dokumentation übersetzen](/doc/de/how-to/translate-documentation/)
-1. [Anhang A - Glossar](/doc/de/appendix-a-glossary/)
-1. [Anhang B - Literaturverzeichnis](/doc/de/appendix-b-reading-list/)
-1. [Begriffsindex](/doc/de/index-of-terms/)
diff --git a/doc/de/jit.markdown b/doc/de/jit.markdown
deleted file mode 100644
index fe03c69..0000000
--- a/doc/de/jit.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_de
-title: JIT Compiler
-previous: Bytecode Compiler - Generator
-previous_url: bytecode-compiler/generator
-next: Garbage Collector
-next_url: garbage-collector
-review: true
----
diff --git a/doc/de/ruby.markdown b/doc/de/ruby.markdown
deleted file mode 100644
index 2572954..0000000
--- a/doc/de/ruby.markdown
+++ /dev/null
@@ -1,63 +0,0 @@
----
-layout: doc_de
-title: Ruby
-previous: Stilvorlage
-previous_url: contributing/style-guide
-next: Scripte
-next_url: ruby/scripts
-review: true
----
-
-Um nachvollziehen zu können, wie Rubinius Ruby implementiert, sollte man
-versuchen einige Konzepte von Rubys Funktionsweise zu verstehen. Dieses Kapitel
-soll dazu beitragen einige Merkmale von Rubinius an Hand von Beispielen aus
-der Ruby Welt vorzustellen, die sicherlich schon vertraut sind. Die Rubinius
-Dokumentation geht grundsätzlich davon aus, dass du dich mit Ruby auskennst
-oder zumindest vertraut bist mit den Konzepten einer Virtuellen Maschine und
-Compilern.
-
-Zentral für alle Einheiten dieses Kapitels ist die Idee des _scope_, des
-Gültigkeitsbereichs. Im Ruby Syntax ist der Gültigkeitsbereich normalerweise
-ableitbar. Oder, anders ausgedrückt, es gibt keine Syntaxelemente, deren
-Hauptaufgabe es ist, den Gültigkeitsbereich festzulegen oder zu beschränken.
-Aus diesem Grund kann es manchmal etwas verwirrend sein, über den
-Gültigkeitsbereich zu reden. Ein Beispiel dazu ist eine übliche Definition
-einer Methode:
-
- a = 5
-
- def fleissig(a)
- puts a * 2
- end
-
-Hier haben wir die `#fleissig` Methode, die uns einen Namen gibt, unter dem wir
-die Berechnung `puts a * 2` erreichen können. Die Methode definiert aber ebenso
-einen geschlossenen Gültigkeitsbereich für die Variable `a`. Er ist
-geschlossen, weil das `a = 5` über der Methode keinen Bezug zu der Variable
-`a` in `#fleissig` hat.
-
-Es wird oft gesagt, dass in Ruby alles ein Objekt sei. Das ist nicht ganz
-zutreffend. _Fast_ alles ist ein Objekt. Einige Dinge die absolut
-notwendig sind, um Ruby Code laufen zu lassen, sind nicht notwendigerweise
-Objekte, an die du herankommst. Deswegen hängt es in der "ausführenden
-Umgebung" stark von der Implementation ab, welche Dinge tatsächlich Objekte
-sind. Der Gültigkeitsbereich ist eines davon.
-
-Im Wesentlichen ist der Gültigkeitsbereich eine Idee im Kontext von Antworten
-auf Fragen wie: Was ist hier der Wert von `self`? Welche lokalen Variablen
-gibt es hier? Welchen Wert wird die konstante `APPLE` an dieser Stelle im
-Programmcode haben?
-
-Jedes der folgenden Elemente aus Ruby wird unter dem Gesichtspunkt der
-Implementierung in Rubinius betrachtet und geschaut, wie sich der
-Gültigkeitsbereich in den jeweiligen Situationen äußert.
-
-1. [Scripte](/doc/de/ruby/scripts/)
-1. [Methoden](/doc/de/ruby/methods/)
-1. [Konstanten](/doc/de/ruby/constants/)
-1. [Klassen & Module](/doc/de/ruby/classes-and-modules/)
-1. [Blöcke & Procs](/doc/de/ruby/blocks-and-procs/)
-1. [Lokale Variablen](/doc/de/ruby/local-variables/)
-1. [Instanzvariablen](/doc/de/ruby/instance-variables/)
-1. [Klassenvariablen](/doc/de/ruby/class-variables/)
-1. [Globale Variablen](/doc/de/ruby/global-variables/)
diff --git a/doc/de/ruby/blocks-and-procs.markdown b/doc/de/ruby/blocks-and-procs.markdown
deleted file mode 100644
index 910112d..0000000
--- a/doc/de/ruby/blocks-and-procs.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_de
-title: Blocks & Procs
-previous: Classes & Modules
-previous_url: ruby/classes-and-modules
-next: Local Variables
-next_url: ruby/local-variables
-review: true
----
diff --git a/doc/de/ruby/class-variables.markdown b/doc/de/ruby/class-variables.markdown
deleted file mode 100644
index 64d9242..0000000
--- a/doc/de/ruby/class-variables.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_de
-title: Class Variables
-previous: Instance Variables
-previous_url: ruby/instance-variables
-next: Global Variables
-next_url: ruby/global-variables
-review: true
----
diff --git a/doc/de/ruby/classes-and-modules.markdown b/doc/de/ruby/classes-and-modules.markdown
deleted file mode 100644
index 95592ca..0000000
--- a/doc/de/ruby/classes-and-modules.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_de
-title: Classes & Modules
-previous: Constants
-previous_url: ruby/constants
-next: Blocks & Procs
-next_url: ruby/blocks-and-procs
-review: true
----
diff --git a/doc/de/ruby/constants.markdown b/doc/de/ruby/constants.markdown
deleted file mode 100644
index 1d1a7f8..0000000
--- a/doc/de/ruby/constants.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_de
-title: Constants
-previous: Methods
-previous_url: ruby/methods
-next: Classes & Modules
-next_url: ruby/classes-and-modules
-review: true
----
diff --git a/doc/de/ruby/global-variables.markdown b/doc/de/ruby/global-variables.markdown
deleted file mode 100644
index 1e8cb99..0000000
--- a/doc/de/ruby/global-variables.markdown
+++ /dev/null
@@ -1,55 +0,0 @@
----
-layout: doc_de
-title: Globale Variablen
-previous: Klassenvariablen
-previous_url: ruby/class-variables
-next: Specs
-next_url: specs
-review: true
----
-
-Syntaktisch gesehen ist eine globale Variable eine Variable, die mit einem `$`
-beginnt. Globale Variablen sollen in einem Ruby Programm aus allen Kontexten
-heraus verfügbar sein. Dennoch unterscheidet man drei Arten von globalen
-Variablen: echte Globale, thread-lokale Globale und pseudo-Globale.
-
-Echte Globale assoziieren einen Wert mit einem Global-Namen, wie z.B.
-`$LOAD_PATH`.
-
-Thread-lokale Globale haben den gleichen Syntax wie globale Variablen, aber
-es gibt unterschiedliche Versionen der Globalen für jeden Thread im laufenden
-Ruby Prozess. Beispiele für thread-lokale Globale sind `$SAFE` und `$!`. Um zu
-zeigen, dass diese Werte von dem aktuellen Thread abhängen, beachte folgendes
-Codebeispiel:
-
- puts $SAFE
-
- Thread.new do
- $SAFE = 2
- puts $SAFE
- end
-
- puts $SAFE
-
-Pseudo-Globale sind eine festgelegte Teilmenge von Namen, die nicht auf globale
-Werte verweisen, sondern auf Werte im aktuellen Geltungsbereich, ähnlich der
-lokalen Variablen. Man bezeichnet sie deshalb als globale Variablen, weil sie
-mit einem Dollarzeichen beginnen; die Bezeichnung stiftet jedoch unnötig
-Verwirrung.
-
-Alle pseudo-Globalen bauen auf eine primäre pseudo-Globale auf: `$~`. D.h. alle
-pseudo-Globalen greifen auf Teile von `$~` zu und wenn `$~` sich
-ändert, dann ändern sich alle pseudo-Globalen mit.
-
-Abhängige pseudo-Globalen sind diese hier: `$&`, $` (backtick),
-`$'` (einfache Anführungszeichen), `$+` und `$1`, `$2`, `$3`, etc.
-
-Ein kniffeliger Aspekt bei diesen Werten ist, dass sie strikt an den
-aktuellen Geltungsbereich gebunden sind. Ruby erlaubt jedoch, dass sie mit
-einem Alias versehen werden können, wie man in English.rb nachsehen kann.
-
-Diese neuen Aliase fügen im Prinzip neue lokale Variablen in allen
-Geltungsbereichen ein, auch in denen, die bereits aktiv sind. Aus diesem Grund
-unterstützt Rubinius sie nicht vollständig. Anstelle dessen bieten wir nur die
-Aliase, die es schon in English.rb gibt. Z.B. kann `$MATCH` anstelle von `$~`
-verwendet werden, egal ob English.rb eingebunden ist oder nicht.
diff --git a/doc/de/ruby/instance-variables.markdown b/doc/de/ruby/instance-variables.markdown
deleted file mode 100644
index d8df235..0000000
--- a/doc/de/ruby/instance-variables.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_de
-title: Instance Variables
-previous: Local Variables
-previous_url: ruby/locas-variables
-next: Class Variables
-next_url: ruby/class-variables
-review: true
----
diff --git a/doc/de/ruby/local-variables.markdown b/doc/de/ruby/local-variables.markdown
deleted file mode 100644
index 1f78b04..0000000
--- a/doc/de/ruby/local-variables.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_de
-title: Local Variables
-previous: Blocks & Procs
-previous_url: ruby/blocks-and-procs
-next: Instance Variables
-next_url: ruby/instance-variables
-review: true
----
diff --git a/doc/de/ruby/methods.markdown b/doc/de/ruby/methods.markdown
deleted file mode 100644
index 64e38db..0000000
--- a/doc/de/ruby/methods.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_de
-title: Methods
-previous: Scripts
-previous_url: ruby/scripts
-next: Constants
-next_url: ruby/constants
-review: true
----
diff --git a/doc/de/ruby/scripts.markdown b/doc/de/ruby/scripts.markdown
deleted file mode 100644
index 83c4ffa..0000000
--- a/doc/de/ruby/scripts.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_de
-title: Scripts
-previous: Ruby
-previous_url: ruby
-next: Methods
-next_url: ruby/methods
-review: true
----
diff --git a/doc/de/specs.markdown b/doc/de/specs.markdown
deleted file mode 100644
index 79a3387..0000000
--- a/doc/de/specs.markdown
+++ /dev/null
@@ -1,43 +0,0 @@
----
-layout: doc_de
-title: Specs
-previous: Ruby - Global Variables
-previous_url: ruby/global-variables
-next: RubySpec
-next_url: specs/rubyspec
----
-
-Im Allgemeinen verwendet das Rubinius Projekt einen TDD/BDD bezogenen Stil, um
-die weitere Entwicklung voranzubringen. Das Rubinius 'spec' Verzeichnis ist
-konzeptuell in zwei Teile aufgeteilt:
-
- 1. Alle Dateien, die sich im Verzeichnis './spec/ruby' befinden, beschreiben
- das Verhalten von MatzRuby.
- 2. Und alle anderen Dateien, die sich im './spec' Verzeichnis befinden,
- beschreiben das Verhalten von Rubinius.
-
-Die Specs unter ./spec/ruby sind eine Kopie von RubySpec und werden regelmäßig
-mit dem RubySpec Projekt abgeglichen, damit erfolglose Specs direkt
-markiert werden können. Auf diese Art und Weise kann gewährleistet werden,
-dass der CI Prozess immer auf einem sicher laufenden Set von Specs
-funktioniert. Ebenso kann so sichergestellt werden, dass Veränderungen am
-Rubinius Code keine Regressionen verursacht.
-
-Dokumentation zur Organisation der Specs und Richtlinien zum Schreiben von
-Specs befinden sich beim [RubySpec Projekt](http://rubyspec.org/).
-
-Folgender Arbeitsablauf sollte beim Hinzufügen von Specs und Code für Rubinius
-verwendet werden:
-
- 1. Schreibe Failing Specs, um das Verhalten von Ruby an einigen Stellen zu
- beschreiben. Verwende separate Commits für die unter ./spec/ruby
- angepassten zuständigen Dateien.
- 2. Füge den Rubinius Code hinzu, der die Specs bestehen lässt. Ebenso sollten
- diese Änderungen als eigenständige Commits, unabhängig von den Specs,
- übergeben werden.
- 3. Lass `rake` laufen, um zu prüfen, dass alle CI Specs bestehen.
-
-Die Veränderungen unter ./spec/ruby werden regelmäßig an das RubySpec Projekt
-weitergeleitet. Ebenso werden aktuelle Änderungen an RubySpec durch Beiträge
-anderer Ruby Implementationen übernommen. Darüber hinaus werden die CI Tags bei
-Updates von RubySpec auf den neusten Stand gebracht.
diff --git a/doc/de/specs/compiler.markdown b/doc/de/specs/compiler.markdown
deleted file mode 100644
index 7ea7870..0000000
--- a/doc/de/specs/compiler.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_de
-title: Compiler Specs
-previous: RubySpec
-previous_url: specs/rubyspec
-next: Build System
-next_url: build-system
-review: true
----
diff --git a/doc/de/specs/rubyspec.markdown b/doc/de/specs/rubyspec.markdown
deleted file mode 100644
index a2c367d..0000000
--- a/doc/de/specs/rubyspec.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_de
-title: RubySpec
-previous: Specs
-previous_url: specs
-next: Compiler Specs
-next_url: specs/compiler
-review: true
----
diff --git a/doc/de/systems.markdown b/doc/de/systems.markdown
deleted file mode 100644
index 98ae590..0000000
--- a/doc/de/systems.markdown
+++ /dev/null
@@ -1,15 +0,0 @@
----
-layout: doc_de
-title: Rubinius Systems
-previous: Garbage Collector - Large Objects
-previous_url: garbage-collector/large-objects
-next: Primitives
-next_url: systems/primitives
-review: true
----
-
-1. [Primitives](/doc/en/systems/primitives/)
-1. [FFI](/doc/en/systems/ffi/)
-1. [Concurrency](/doc/en/systems/concurrency/)
-1. [IO](/doc/en/systems/io/)
-1. [C-API](/doc/en/systems/c-api/)
diff --git a/doc/de/systems/c-api.markdown b/doc/de/systems/c-api.markdown
deleted file mode 100644
index f25f7a8..0000000
--- a/doc/de/systems/c-api.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_de
-title: C-API
-previous: IO
-previous_url: systems/io
-next: Tools
-next_url: tools
-review: true
----
diff --git a/doc/de/systems/concurrency.markdown b/doc/de/systems/concurrency.markdown
deleted file mode 100644
index 28ed57c..0000000
--- a/doc/de/systems/concurrency.markdown
+++ /dev/null
@@ -1,114 +0,0 @@
----
-layout: doc_de
-title: Concurrency
-previous: FFI
-previous_url: systems/ffi
-next: IO
-next_url: systems/io
-review: true
----
-
-Rubinius unterstützt die selben Konstrukte zur Nebenläufigkeit wie Ruby, Threads
-und Fibers, dazu aber noch eine neue API: Actors. Actors stellen Nebenläufigkeit
-ohne wechselseitigen Ausschluss (Mutex) oder Zugriffssperren (Locking) beim
-gegenseitigen Austausch von Zuständen zwischen Threads zur Verfügung.
-
-Actors führen nebenläufig aus, teilen sich aber keine Zustände. Anstelle dessen
-schicken sie Mitteilungen an andere Actors. Im folgenden Beispiel werden zwei
-Actors, ping und pong, mit Hilfe eines `Actor.spawn` erstellt. Beide schicken
-sich Mitteilungen zu, so lange bis sie gemeinsam eine Variable auf 100 erhöht
-haben:
-
- require 'actor'
- pong = nil
- ping = Actor.spawn do
- loop do
- count = Actor.receive
- break puts(count) if count > 1000
- pong << (count + 1)
- end
- end
- pong = Actor.spawn do
- loop do
- count = Actor.receive
- break puts(count) if count > 1000
- ping << (count + 1)
- end
- end
- ping << 1
- sleep 1
-
-Actors empfangen Mitteilungen über `Actor.receive`. Das blockiert den Actor so
-lange, bis eine Mitteilung eingeht. Unterschiedliche Arten von Mitteilungen
-können in einem an `Actor.receive` angehängen Block mit einem Mitteilungs-Filter
-verarbeitet werden:
-
- Actor.receive do |filter|
- filter.when(Ready) do |who|
- # SNIP
- end
- filter.when(Work) do |work|
- ready_workers.pop << work
- end
- filter.when(Actor::DeadActorError) do |exit|
- print "Actor exited with message: #{exit.reason}\n"
- ready_workers << Actor.spawn_link(&work_loop)
- end
- end
-
-Mitteilungs-Filter verwenden === für die Mitteilungen, deshalb können auch
-reguläre Ausdrücke, Klassen oder proc mit `when()` eingesetzt werden.
-
-Actors können mit Hilfe eines `Actor.spawn_link` auch eine Eltern-Kind Beziehung
-haben. Sollte der Kind-Actor aus irgendeinem Grund beendet werden, kann der
-Eltern-Actor über die Einstellung `Actor.trap_exit = true` vor dem
-`Actor.spawn_link` darüber im weiteren Verlauf benachrichtigt werden. Im
-folgenden Beispiel wird ein Supervisor-Actor erstellt, der eine Arbeits-Queue
-mit 10 Arbeitern verwaltet. Der Supervisor wird mittels einer
-`Actor::DeadActorError` Mitteilung über die Beendigung eines Arbeiters (z.B.
-wegen einer Exception) benachrichtigt:
-
- require 'actor'
-
- Ready = Struct.new(:this)
- Work = Struct.new(:msg)
-
- @supervisor = Actor.spawn do
- supervisor = Actor.current
- work_loop = Proc.new do
- loop do
- work = Actor.receive
- puts("Processing: #{work.msg}")
- supervisor << Ready[Actor.current]
- end
- end
-
- Actor.trap_exit = true
- ready_workers = []
- 10.times do |x|
- # starte 10 Arbeiter Actors
- ready_workers << Actor.spawn_link(&work_loop)
- end
- loop do
- Actor.receive do |f|
- f.when(Ready) do |who|
- # SNIP
- end
- f.when(Work) do |work|
- ready_workers.pop << work
- end
- f.when(Actor::DeadActorError) do |exit|
- print "Actor exited with message: #{exit.reason}\n"
- ready_workers << Actor.spawn_link(&work_loop)
- end
- end
- end
- end
-
- 10.times do |idx|
- @supervisor << Work[idx]
- end
- sleep 1
-
-Dieses Beispiel stammt von [girl_friday](http://github.com/mperham/girl_friday).
-Weitere Einzelheiten finden sich im Repository.
diff --git a/doc/de/systems/ffi.markdown b/doc/de/systems/ffi.markdown
deleted file mode 100644
index a4c4024..0000000
--- a/doc/de/systems/ffi.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_de
-title: Foreign Function Interface
-previous: Primitives
-previous_url: systems/primitives
-next: Concurrency
-next_url: systems/concurrency
-review: true
----
diff --git a/doc/de/systems/io.markdown b/doc/de/systems/io.markdown
deleted file mode 100644
index b1763a3..0000000
--- a/doc/de/systems/io.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_de
-title: IO
-previous: Concurrency
-previous_url: systems/concurrency
-next: C-API
-next_url: systems/c-api
-review: true
----
diff --git a/doc/de/systems/primitives.markdown b/doc/de/systems/primitives.markdown
deleted file mode 100644
index 9dd34a2..0000000
--- a/doc/de/systems/primitives.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_de
-title: Primitives
-previous: Rubinius Systems
-previous_url: systems
-next: FFI
-next_url: systems/ffi
-review: true
----
diff --git a/doc/de/tools.markdown b/doc/de/tools.markdown
deleted file mode 100644
index fd6b204..0000000
--- a/doc/de/tools.markdown
+++ /dev/null
@@ -1,13 +0,0 @@
----
-layout: doc_de
-title: Tools
-previous: Rubinius Systems - C-API
-previous_url: systems/c-api
-next: Debugger
-next_url: tools/debugger
-review: true
----
-
-1. [Debugger](/doc/en/tools/debugger/)
-1. [Profiler](/doc/en/tools/profiler/)
-1. [Memory Analysis](/doc/en/tools/memory-analysis/)
diff --git a/doc/de/tools/debugger.markdown b/doc/de/tools/debugger.markdown
deleted file mode 100644
index 273c1e3..0000000
--- a/doc/de/tools/debugger.markdown
+++ /dev/null
@@ -1,131 +0,0 @@
----
-layout: doc_de
-title: Debugger
-previous: Tools
-previous_url: tools
-next: Profiler
-next_url: tools/profiler
----
-
-Rubinius kommt mit einer eingebauten Ruby Debugger-API auf Quell-Ebene.
-
-## Aus aktivem Code heraus starten
-
-Der Rubinius Debugger kann direkt aus aktivem Code heraus mit Hilfe eines
-eingebauten Aufrufs gestartet werden.
-
-Angenommen folgender Code befindet sich in app.rb:
-
- class Toaster
- attr_accessor :einstellung
- def initialize
- require 'rubinius/debugger'
- Rubinius::Debugger.start
- @einstellung = :braun
- end
- end
-
- p Toaster.new.einstellung
-
-Bei Ausführung des Codes in Rubinius käme folgende Ausgabe:
-
- $ rbx app.rb
-
- | Breakpoint: Toaster#initialize at app.rb:5 (15)
- | 5: Rubinius::Debugger.start
- debug> help
- help: Show information about debugger commands
- b, break, brk: Set a breakpoint at a point in a method
- tb, tbreak, tbrk: Set a temporary breakpoint
- d, delete: Delete a breakpoint
- n, next: Move to the next line or conditional branch
- s, step: Step into next method call or to next line
- ni, nexti: Move to the next bytecode instruction
- f, frame: Make a specific frame in the call stack the current frame
- c, cont, continue: Continue running the target thread
- bt, backtrace: Show the current call stack
- p, eval: Run code in the current context
- dis, disassemble: Show the bytecode for the current method
- i, info: Show information about things
- set: Set a debugger config variable
- show: Display the value of a variable or variables
- debug> bt
- | Backtrace:
- | 0 Toaster#initialize at app.rb:5 (15)
- | 1 main.__script__ at app.rb:11 (46)
- | 2 Rubinius::CodeLoader#load_script(debug) at kernel/delta/codeloader.rb:67 (44)
- | 3 Rubinius::CodeLoader.load_script(name) at kernel/delta/codeloader.rb:91 (40)
- | 4 Rubinius::Loader#script at kernel/loader.rb:460 (79)
- | 5 Rubinius::Loader#main at kernel/loader.rb:571 (64)
- | 6 Rubinius::Loader.main at kernel/loader.rb:609 (33)
- | 7 Object#__script__ at kernel/loader.rb:621 (60)
- debug> n
-
- | Breakpoint: Toaster#initialize at app.rb:6 (16)
- | 6: @einstellung = :braun
- debug> n
-
- | Breakpoint: Toaster#initialize at app.rb:7 (21)
- | 7: @art = :roggen
- debug> p @einstellung = :hellbraun
- $d0 = :hellbraun
- debug> c
- :hellbraun
-
-Wie angegeben, bekommt man bei der Eingabe von `help` im Debugger eine
-englischsprachige Hilfsanzeige für die verfügbaren Befehle.
-
-
-## Starten von der Kommandozeile
-
-Der Rubinius Debugger kann ebenfalls aus der Kommandozeile heraus gestartet
-werden und zeigt das Debugger Prompt an, noch bevor das dazu angegebene Skript
-geladen wird.
-
-Angenommen folgender Code befindet sich in app.rb:
-
- def problem_code
- puts "Ich habe ein Problem"
- a = 1 + 2
- puts "ein Mathe-Problem" unless a == 4
- end
-
- problem_code
-
-Um diesen Code zu debuggen, kann der Debugger von der Kommandozeile aus mit der
-`-Xdebug` option gestartet werden:
-
- $ rbx -Xdebug bug.rb
-
- | Breakpoint: Rubinius::Loader#debugger at kernel/loader.rb:424 (34)
- | 424: Rubinius::Debugger.start
- debug> b Object#problem_code:2
- * Unable to find method 'problem_code' in Object
- | Would you like to defer this breakpoint to later? [y/n] y
- | Defered breakpoint created.
- debug> c
- | Resolved breakpoint for Object#problem_code
- | Set breakpoint 2: bug.rb:2 (+0)
-
- | Breakpoint: Object#problem_code at bug.rb:2 (0)
- | 2: puts "Ich habe ein Problem"
- debug> n
- I habe ein Problem
-
- | Breakpoint: Object#problem_code at bug.rb:3 (9)
- | 3: a = 1 + 2
- debug> n
-
- | Breakpoint: Object#problem_code at bug.rb:4 (16)
- | 4: puts "ein Mathe-Problem" unless a == 4
- debug> p a = 4
- $d0 = 4
- debug> n
-
- | Breakpoint: main.__script__ at bug.rb:7 (17)
- | 7: problem_code
- debug> c
-
-Wie man sieht, bei der Ausführung von `p a = 4` im Debugger wird der Wert der
-lokalen Variable `a` geändert und beeinflusst damit auch die weitere Ausführung
-des Ruby-Codes.
diff --git a/doc/de/tools/memory-analysis.markdown b/doc/de/tools/memory-analysis.markdown
deleted file mode 100644
index 417c25d..0000000
--- a/doc/de/tools/memory-analysis.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_de
-title: Memory Analysis
-previous: Profiler
-previous_url: tools/profiler
-next: Anleitungen
-next_url: guides
-review: true
----
diff --git a/doc/de/tools/profiler.markdown b/doc/de/tools/profiler.markdown
deleted file mode 100644
index fe8a3d7..0000000
--- a/doc/de/tools/profiler.markdown
+++ /dev/null
@@ -1,338 +0,0 @@
----
-layout: doc_de
-title: Profiler
-previous: Debugger
-previous_url: tools/debugger
-next: Memory Analysis
-next_url: tools/memory-analysis
----
-
-Rubinius hat einen eingebauten Profiler, der eine genaue Zeitmessung für alle
-durchlaufenen Methoden bietet. Der Profiler ist auf VM-Ebene implementiert und
-bietet die erbrachten Daten für Ruby zur weiteren Evaluation.
-
-
-## VM-Profiler
-
-Zur Erstellung und Erhaltung des Profilers spielen folgende Teilnehmer eine
-Rolle: VM, SharedState, ProfilerCollection und Profiler. Die VM Klasse ist eine
-Thread-lokale Datenstruktur. Das heißt, jede VM-Instanz bekommt eine eigene
-Profiler-Instanz zugewiesen. Die SharedState-Instanz hat eine
-ProfilerCollection-Instanz, die den VMs zugeordnet ist und schließlich die
-zusammenführten Ergebnisse aller Profiler generiert.
-
-Der Profiler lebt und stirbt in seiner eigenen Umgebung. Der Profiler wird bei
-seiner Erstellung an eine VM-Instanz weitergereicht, damit er zur
-Datenerstellung Zugriff auf die VM hat. Das STATE Argument könnte an alle
-Profiler-Methoden weitergegeben werden, muss aber nicht, weil es ausreicht dies
-gleich bei der Erstellung des Profilers zu machen. Der Profiler verändert niemals
-die VM-Instanz. Diese Trennung von Aufgaben muss auf jeden Fall erhalten bleiben.
-
-Die VM-Instanz generiert die Profiler-Instanz nur bei Bedarf (lazy). Die VM
-registriert den Profiler dann auch mit dem SharedState.
-
-Der SharedState unterhält die ProfilerCollection-Instanz und reicht Aufrufe zur
-Registrierung oder Löschung von Profilern weiter.
-
-Die ProfilerCollection-Instanz gibt den Befehl, dass die VM-Instanz, die einem
-Profiler zugeordnet ist, den Profiler auch entfert, wenn er gelöscht wird.
-
-
-## Ruby-Profiler
-
-In der Ruby-Welt sagt die Rubinius::Profiler::Instrumenter-Instanz nichts über
-die Multi-Thread Realität in der VM aus. Die individuellen
-C++-Profiler-Instanzen sind für Ruby unsichtbar. Wenn in Ruby eine
-Profiler-Instanz erstellt wird, dann kann diese Instanz lediglich den VM-Profiler
-starten und beenden. Wenn der Profiler gestoppt wird, werden die gesammelten
-Daten in einem LookupTable zurückgegeben. Der Ruby Profiler-Code kann dann mit
-der #show-Methode angezeigt werden.
-
-Rubinius bietet eine kompatible Standardbibliothek profile.rb und profiler.rb.
-Weitere Informationen finden sich in der MRI Dokumentation.
-
-Betrachtet man lib/profiler.rb, so kann man die grundlegenden Schritte zur
-Nutzung des Profilers in Ruby erkennen:
-
- # Eine Profiler-Instanz erstellen
- profiler = Rubinius::Profiler::Instrumenter.new
-
- # Den Profiler starten
- profiler.start
-
- # Den Profiler stoppen
- profiler.stop
-
- # Die Profiler-Daten abfragen
- data = profiler.info
-
- # Oder die Profiler-Daten ausdrucken
- profiler.show # takes on IO object, defaults to STDOUT
-
-Ebenso kann man eine Methode verwenden, die den Profiler mit einem Block
-verwendet.
-
- # Eine Profiler-Instanz erstellen
- profiler = Rubinius::Profiler::Instrumenter.new
-
- # Ein Profil erstellen
- profiler.profile do
- # einige Aufgaben
- end
-
-Die #profile-Methode startet den Profiler, macht ein yield, hält den Profiler an
-und druckt die Profiler-Daten aus. Wird 'false' als Argument an #profile
-weitergegeben, dann druckt es die Daten nicht aus. Nichtsdestotrotz werden die
-Profiler-Daten als Rückgabewert von #profile zurückgegeben.
-
-
-Wie man die Daten des Flat-Profiler liest
------------------------------------------
-
-Der Flat-Profiler gibt Ausgabe-Daten in den folgenden Spalten zurück:
-
-### % time
-
-Angabe der Zeitspanne in Prozent, die in dieser Methode verbracht wurde im
-Verhältnis zur Gesamtzeit.
-
-
-### cumulative seconds
-
-Angabe der kumulierten Zeit, die in dieser Methode, sowie aller weiteren aus ihr
-heraus rekursiv aufgerufenen Methoden verbracht wurde. Diese Methode kann auch
-als die Wurzel im Aufrufbaum gesehen werden. Die Summe aller von ihr aus
-aufgerufenen Methoden ist die kumlierte Sekundenzahl für diese Methode.
-
-
-### self seconds
-
-Die in dieser Methode verbrachte Zeit in Sekunden, ungeachtet der Aufrufe anderer
-Methoden aus ihr selbst heraus.
-
-
-### calls
-
-Die Anzahl der Aufrufe, die an diese Methode gingen.
-
-
-### self ms/call
-
-Die Angabe der self seconds in Millisekunden geteilt durch die Gesamtzahl aller
-Aufrufe.
-
-
-### total ms/call
-
-cumulative seconds als Millisekunden geteilt durch die Gesamtzahl aller Aufrufe.
-
-
-### Beispiel einer Flat-Ausgabe
-
-Das folgende Skript ist die Grundlage für die beiden unten angegebenen
-Profiler-Beispiele:
-
- class F
- def foo(a)
- 1 + a
- end
-
- def bar(a, b)
- foo(a) ** b
- end
-
- def work(a, b, n, m)
- n.times { |i| i + bar(a, b) }
- m.times { |i| foo(i) }
- end
- end
-
- p = Rubinius::Profiler::Instrumenter.new :sort => :self_seconds
- p.profile {
- F.new.work 2, 3, 10, 5
- }
-
-
-Führt man das Skript mit 'bin/rbx script.rb' aus, sollte folgende Tabelle
-ausgegeben werden:
-
-
- % cumulative self self total
- time seconds seconds calls ms/call ms/call name
- ------------------------------------------------------------
- 9.64 0.00 0.00 10 0.00 0.00 Fixnum#**
- 23.33 0.00 0.00 1 0.01 0.08 #toplevel
- 12.64 0.00 0.00 10 0.00 0.00 F#bar
- 15.38 0.00 0.00 15 0.00 0.00 F#work {}
- 17.74 0.00 0.00 2 0.00 0.03 Integer#times
- 19.29 0.00 0.00 1 0.01 0.06 F#work
- 1.12 0.00 0.00 1 0.00 0.00 Class#new
- 0.68 0.00 0.00 15 0.00 0.00 F#foo
- 0.13 0.00 0.00 1 0.00 0.00 Class#allocate
- 0.06 0.00 0.00 1 0.00 0.00 Object#initialize
-
- 10 methods called a total of 57 times
-
-
-Wie man die Graphen-Ausgabe ausliest
-------------------------------------
-
-Die Graphen-Ausgabe stellt man über eine Konfigurations-Option ein:
-
- -Xprofiler.graph
-
-Mit dem vorhin genannten Skript wird der unten angegebene Graph ausgegeben.
-Jeder "Eintrag" im Graphen hat drei Abschnitte: 1) Die Methode für den Eintrag,
-genannt Primärzeile; 2) die Aufrufer der Primärmethode; und 3) die Methoden,
-die die Primärmethode selber aufrief. Die Felder haben unterschiedliche
-Bedeutungen in Bezug auf den Ort ihres Eintrags.
-
-Für die Primärzeile gelten die folgenden Felder:
-
-
-### index
-
-Ein Index, der jeder Methode im Graphen zugeordnet ist, um cross-Referenzen
-zwischen den Einträgen zu ermöglichen.
-
-
-### % time
-
-Die Zeitspanne, die in dieser Methode verbracht wurde als Prozentangabe der
-Gesamtzeit, die für alle Methoden gebraucht wurde. Diese Angabe entspricht der
-Flat-Ausgabe.
-
-
-### self
-
-Die in dieser Methode verbrachte Zeit in Sekunden, ungeachtet der Aufrufe anderer
-Methoden aus ihr selbst heraus.
-
-
-### children
-
-Die Gesamtzeit, die in allen von die Methode aufgerufenen Methoden verbracht
-wurde.
-
-
-### called
-
-Die Anzahl der Aufrufe, die an diese Methode gingen.
-
-
-### name
-
-Der Name der Methode gefolgt von der Indexnummer.
-
-Die beiden Zeilen über der Primärzeile sind die Methoden, die die Primärmethode
-aufrufen. Die Felder der Aufrufer haben folgende Bedeutung:
-
-
-### self
-
-Die Zeitspanne, die in dieser Methode verbracht wurde als Prozentangabe der
-Gesamtzeit, die für alle Methoden gebraucht wurde. Diese Angabe entspricht der
-Flat-Ausgabe.
-
-
-### children
-
-Die Zeit, die die Methode für Aufrufe an die Primärmethode verbrauchte.
-
-
-### called
-
-Das called-Feld hat zwei Teile, getrennt durch einen Schrägstrich. Links steht
-die Anzahl der Aufrufe, die diese Methode an die Primärmethode gemacht hat und
-rechts steht die Gesamtzahl der Aufrufe, die diese Methode gemacht hat.
-In anderen Worten, die beiden Zahlen zusammen zeigen das Verhältnis zwischen
-den Aufrufen an die Primärmethode zu allen anderen Methoden.
-
-
-### name
-
-Der Name der aufrufenden Methode gefolgt vom Index. Ist der Index [0], wird die
-Methode im Grahen nicht dargestellt.
-
-
-Die Zeilen unterhalb der Primärzeile listet Methoden auf, die die Primärmethode
-aufruft.
-
-Die Felder der aufgerufenen Methoden sind wie folgt:
-
-
-### self
-
-Die Zeitspanne, die in dieser Methode verbracht wurde als Prozentangabe der
-Gesamtzeit, die für alle Methoden gebraucht wurde. Diese Angabe entspricht der
-Flat-Ausgabe.
-
-### children
-
-Die Angabe ist ein Schätzwert der Zeit, die die Aufgerufenen Methoden brauchten,
-als die Methode von der Primärmethode aufgerufen wurde. Die Schätzung basiert
-auf dem Verhältnis zwischen der Zeit, die diese Methode brauchte, als sie von
-der Primärmethode aufgerufen wurde zu der Zeit, die sie in sich selbst
-verbrauchte.
-
-
-### called
-
-Das called-Feld hat zwei Teile, getrennt durch einen Schrägstrich. Links steht
-die Anzahl der Aufrufe, die diese Methode von der Primärmethode bekam und
-rechts steht die Gesamtzahl der Aufrufe, die an diese Methode gemacht wurden.
-
-
-### name
-
-Der Name der aufgerufenen Methode gefolgt von ihrem Index [N]. Ist kein Index
-vorhanden, dann gibt es für diese Methode auch keinen Primäreintrag im Graphen.
-Um auch solche Methoden anzeigen zu lassen, wird die '-Xprofiler.full_report'
-Option verwendet, die den vollständigen Graphen generiert.
-
-
- index % time self children called name
- ----------------------------------------------------------
- 0.00 0.00 10/20 F#bar [3]
- [1] 9.6 0.00 0.00 10 Fixnum#** [1]
- -------------------------------------------------------
- [2] 23.2 0.00 0.00 1 #toplevel [2]
- 0.00 0.00 1/1 Class#new [7]
- 0.00 0.00 1/1 F#work [6]
- -------------------------------------------------------
- 0.00 0.00 10/15 F#work {} [4]
- [3] 12.7 0.00 0.00 10 F#bar [3]
- 0.00 0.00 10/15 F#foo [8]
- 0.00 0.00 10/10 Fixnum#** [1]
- -------------------------------------------------------
- 0.00 0.00 15/15 Integer#times [5]
- [4] 15.4 0.00 0.00 15 F#work {} [4]
- 0.00 0.00 10/10 F#bar [3]
- 0.00 0.00 5/15 F#foo [8]
- -------------------------------------------------------
- 0.00 0.00 2/2 F#work [6]
- [5] 17.8 0.00 0.00 2 Integer#times [5]
- 0.00 0.00 15/15 F#work {} [4]
- -------------------------------------------------------
- 0.00 0.00 1/2 #toplevel [2]
- [6] 19.3 0.00 0.00 1 F#work [6]
- 0.00 0.00 2/2 Integer#times [5]
- -------------------------------------------------------
- 0.00 0.00 1/2 #toplevel [2]
- [7] 1.1 0.00 0.00 1 Class#new [7]
- 0.00 0.00 1/1 Object#initialize [10]
- 0.00 0.00 1/1 Class#allocate [9]
- -------------------------------------------------------
- 0.00 0.00 10/20 F#bar [3]
- 0.00 0.00 5/15 F#work {} [4]
- [8] 0.7 0.00 0.00 15 F#foo [8]
- -------------------------------------------------------
- 0.00 0.00 1/2 Class#new [7]
- [9] 0.1 0.00 0.00 1 Class#allocate [9]
- -------------------------------------------------------
- 0.00 0.00 1/2 Class#new [7]
- [10] 0.1 0.00 0.00 1 Object#initialize [10]
- -------------------------------------------------------
-
- 10 methods called a total of 57 times
-
diff --git a/doc/de/virtual-machine.markdown b/doc/de/virtual-machine.markdown
deleted file mode 100644
index ad0ad4e..0000000
--- a/doc/de/virtual-machine.markdown
+++ /dev/null
@@ -1,12 +0,0 @@
----
-layout: doc_de
-title: Virtual Machine
-previous: Bootstrapping
-previous_url: bootstrapping
-next: Instructions
-next_url: virtual-machine/instructions
-review: true
----
-
-1. [Instructions](/doc/en/virtual-machine/instructions/)
-1. [Custom Dispatch Logic](/doc/en/virtual-machine/custom-dispatch-logic/)
diff --git a/doc/de/virtual-machine/custom-dispatch-logic.markdown b/doc/de/virtual-machine/custom-dispatch-logic.markdown
deleted file mode 100644
index 01876d6..0000000
--- a/doc/de/virtual-machine/custom-dispatch-logic.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_de
-title: Custom Dispatch Logic
-previous: Instructions
-previous_url: virtual-machine/instructions
-next: Bytecode Compiler
-next_url: bytecode-compiler
-review: true
----
diff --git a/doc/de/virtual-machine/instructions.markdown b/doc/de/virtual-machine/instructions.markdown
deleted file mode 100644
index 8d65423..0000000
--- a/doc/de/virtual-machine/instructions.markdown
+++ /dev/null
@@ -1,13 +0,0 @@
----
-layout: doc_de
-title: Instructions
-previous: Virtual Machine
-previous_url: virtual-machine
-next: Custom Dispatch Logic
-next_url: virtual-machine/custom-dispatch-logic
----
-
-The virtual machine instructions are contained in `vm/instructions.def`. The
-documentation below is generated by `rakelib/vm.rake`.
-
-{% include instructions.markdown %}
diff --git a/doc/de/what-is-rubinius.markdown b/doc/de/what-is-rubinius.markdown
deleted file mode 100644
index 6a3b5ff..0000000
--- a/doc/de/what-is-rubinius.markdown
+++ /dev/null
@@ -1,42 +0,0 @@
----
-layout: doc_de
-next: Erste Schritte
-next_url: getting-started
----
-
-## Was ist Rubinius?
-
-Rubinius ist eine Implementierung der [Programmiersprache Ruby](http://ruby-lang.org).
-
-Rubinius besteht aus einer Bytecode Virtuellen Maschine (VM), einem Ruby
-Syntaxparser, Bytecode Compiler, Generationellen Garbage Collector (GC),
-Just-In-Time (JIT) nativen Maschinencode Compiler und einer Ruby Core und
-Standard Bibliothek.
-
-Rubinius implementiert derzeit Ruby Version 1.8.7.
-
-
-## Lizenz
-
-Rubinius nutzt die BSD Lizenz. Siehe LICENSE Datei im Quellverzeichnis.
-
-
-## Installation
-
-Rubinius läuft auf Mac OS X und vielen Unix/Linux Betriebssystemen. Microsoft
-Windows Unterstützung kommt ebenfalls bald und ist derzeit in Entwicklung.
-
-Um Rubinius zu installieren, folge den unteren Anweisungen. Für detailliertere
-Informationen siehe auch: [Erste Schritte](/doc/de/getting-started/).
-
-1. `git clone git://github.com/rubinius/rubinius.git`
-1. `cd rubinius`
-1. `./configure --prefix=/pfad/zum/installations/verzeichnis`
-1. `rake install`
-
-Wenn der Installationsvorgang abgeschlossen ist, folge den Anweisungen, um das
-Rubinius Binärdateiverzeichnis (bin) deinem PATH hinzuzufügen.
-
-Rubinius kommt mit eingebautem RubyGems und hat die rake und rdoc Gems von Haus
-aus vorinstalliert. Um zum Beispiel das nokogiri Gem zu installieren, führe
-`rbx gem install nokogiri` aus.
diff --git a/doc/en/appendix-a-glossary.markdown b/doc/en/appendix-a-glossary.markdown
deleted file mode 100644
index db62352..0000000
--- a/doc/en/appendix-a-glossary.markdown
+++ /dev/null
@@ -1,176 +0,0 @@
----
-layout: doc_en
-title: Appendix A - Glossary
-previous: How-To - Commit Changes to Github
-previous_url: how-to/commit-to-github
-next: Appendix B - Reading List
-next_url: appendix-b-reading-list
-review: true
----
-
-Definitions of terms and phrases used in the Ruby programming language and in
-this implementation. See also "The Ruby Programming Language" by Flanagan and
-Matsumoto [O'Reilly 2008] and "Programming Ruby: The Pragmatic Programmer's
-Guide" 2nd or 3rd Edition by Thomas et al [The Pragmatic Programmers
-2005-2008]
-
-
-* _method lookup or method resolution_
-
- The rule is simple: Take the object located in the class slot of the object
- (which is not always the return value of Object#class; if the object has one,
- it'll be the singleton class) and begin searching.
-
- Searching goes up the superclass chain until the superclass is nil.
-
- In which case, redo lookup for method_missing. If we fail to find
- method_missing, fail tragically.
-
- +----------------+
- | nil |
- +----------------+
- ^
- | superclass
- |
- +----------------+
- | Object |
- +----------------+
- ^
- | superclass
- |
- +----------------+
- | Module |
- +----------------+
- ^
- | superclass
- |
- +----------------+
- | Class |
- +----------------+
- ^
- | superclass
- |
- +----------------+
- | SingletonClass |
- | (Object) |
- +----------------+
- ^
- | superclass
- |
- +-------------+ +----------------+
- | F | -----------------> | SingletonClass |
- +-------------+ singleton class | (F) |
- +----------------+
-
-
- class Class
- def wanker
- puts 'you are'
- end
- end
-
- class F
- def self.bloke
- wanker
- end
- end
-
- 1. Resolve method 'wanker' -- search method_tables in:
-
- 1. SingletonClass(F)
- 1. SingletonClass(Object)
- 1. Class
-
- Found
-
-
-* _method_table_
-
- A data structure in every class (and module) that contains the methods defined
- for that class.
-
- In Rubinius, a class's method_table is an instance of LookupTable.
-
-
-* _MatzRuby_
-
- See MRI
-
-
-* _MRI_
-
- Matz's Ruby Interpreter or Matz's Ruby Implementation. A short name to refer
- to the official implementation of Ruby. See .
-
-
-* _private send_
-
- A method call that has no explicit lexical receiver. The receiver of the
- call is +self+. For example:
-
- class A
- private
- def you_are_mine
- end
- end
-
- class B < A
- def sunshine
- you_are_mine
- end
- end
-
- class C
- def dear
- today = B.new
- today.you_are_mine
- end
- end
-
- The call to +you_are_mine+ in the method +sunshine+ is a private send. The
- call to +today.you_are_mine+ will not succeed because private methods cannot
- have an explicit receiver. In this case, the object +today+ is the explicit
- receiver.
-
-
-* _singleton class_
-
- Every object in Ruby can have one, although they are only created as
- necessary. The singleton class holds the method and constant tables that
- belong only to a particular object instance. For example, the method
- +hello+ defined below exists only in the singleton class for +obj+.
-
- obj = Object.new
- def obj.hello
- puts 'hi'
- end
-
- Since all classes in Ruby are also objects, they can have singleton classes.
- The methods called "class methods" are just methods in the method_table of
- the class's singleton class. The method +honk+ exists in the singleton class
- for the class +Car+.
-
- class Car
- def self.honk
- end
- end
-
- In Rubinius, singleton classes are all instances of the class
- SingletonClass. The singleton class for an object can be obtained by calling
- the +singleton_class+ method. The overall arrangement of concepts involved
- here is sometimes referred to as the 'Meta-Object Protocol' or +MOP+.
-
-
-* _superclass_
-
- The class that a particular class immediately inherits from. The class Object
- is the superclass of all classes that do not inherit explicitly from a class.
-
- class A
- end
-
- class B < A
- end
-
- Class A inherits from Object. In other words, A.superclass == Object. Class B
- inherits explicitly from class A. So, B.superclass == A.
diff --git a/doc/en/appendix-b-reading-list.markdown b/doc/en/appendix-b-reading-list.markdown
deleted file mode 100644
index ff0801d..0000000
--- a/doc/en/appendix-b-reading-list.markdown
+++ /dev/null
@@ -1,46 +0,0 @@
----
-layout: doc_en
-title: Appendix B - Reading List
-previous: Appendix A - Glossary
-previous_url: appendix-a-glossary
-next: Terms Index
-next_url: terms-index
-review: true
----
-
-Building virtual machines in general and programming language implementations
-in particular requires some knowledge. Rubinius' goal is to lower the barrier
-by keeping as much as possible in Ruby but to hack on the garbage collector you
-have to understand what's going on behind the curtains.
-
-This page contains references to books, online lectures, blog posts and any
-other publications you may find useful for working on Rubinius.
-
-NOTE that some of these links refer to outdated information about Rubinius.
-
-## Virtual machine
-
- * [Smalltalk-80: language and its implementation](http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf)
- by Goldberg, Robson, Harrison (aka "The Blue Book")
- * [Virtual machines](http://tinyurl.com/3ydkqg) by Iain D. Craig
- * Great posts by Adam Gardiner: [introduction](http://tinyurl.com/35y2jh),
- [How send sites work](http://tinyurl.com/34c6e8)
-
-
-## Garbage collection
-
- * [Garbage Collection: Algorithms for Automatic Dynamic Memory
- Management](http://tinyurl.com/3dygmo) by Richard Jones
- * [Garbage collection lectures](http://tinyurl.com/2mhek4)
-
-
-## Primitive methods
-
- * [Guide to Squeak
- primitives](http://www.fit.vutbr.cz/study/courses/OMP/public/software/sqcdrom2/Tutorials/SqOnlineBook_%28SOB%29/englisch/sqk/sqk00083.htm)
-
-
-## FFI
-
- * [Implementing File#link using
- FFI](http://redartisan.com/2007/10/11/rubinius-coding)
diff --git a/doc/en/bootstrapping.markdown b/doc/en/bootstrapping.markdown
deleted file mode 100644
index 8e583f9..0000000
--- a/doc/en/bootstrapping.markdown
+++ /dev/null
@@ -1,103 +0,0 @@
----
-layout: doc_en
-title: Bootstrapping
-previous: Build System
-previous_url: build-system
-next: Virtual Machine
-next_url: virtual-machine
----
-
-Bootstrapping is the process of building up functionality of the system until
-all Ruby code can be executed. There are seven stages to the bootstrap process:
-
- 1. VM: The virtual machine is able to load and execute bytecode, send
- messages (i.e. look up and execute methods), and all primitive functions
- are available, but not yet hooked up as Ruby methods.
-
- The Class class has to be manually set up this early in the process by
- setting its class to be itself and its superclass to be Module. In
- addition to Class and Module, a couple of other base classes are created
- here including Object, Tuple, LookupTable, and MethodTable.
-
- Now that classes can be defined, 35 or so built in classes are told to
- initialize themselves, symbols for top level methods (:object_id, :call,
- :protected, etc) are created, basic exceptions are defined, and
- primitives are registered. Finally IO gets hooked up. Also at this stage,
- several fundamental Ruby methods are bound to primitives.
-
- At this point there is enough defined behavior to begin to load up the
- rest of the runtime kernel which is all defined in ruby. This has to be
- done in several passes as the language grows.
-
- 2. alpha: This starts the loading of Ruby code. The ability to open classes
- and modules and define methods exists. The minimum functionality to
- support the following methods is implemented in kernel/alpha.rb:
-
- attr_reader :sym
- attr_writer :sym
- attr_accessor :sym
- private :sym
- protected :sym
- module_function :sym
- include mod
-
- Also, it is possible to raise exceptions and cause the running process to
- exit. This stage lays the foundation for the next two stages.
-
- 3. bootstrap: This stage continues to add the minimum functionality to
- support loading platform and common. The primitive functions are added
- for most of the kernel classes.
-
- 4. platform: The FFI (foreign function interface) system is implemented and
- Ruby method interfaces to platform-specific functions are created. Once
- this is set up, platform specific things such as pointers, file access,
- math, and POSIX commands are attached.
-
- 5. common: The vast majority of the Ruby core library classes are
- implemented. The Ruby core classes are kept as implementation-neutral as
- possible. Also, most of the functionality for Rubinius specific classes
- is added.
-
- 6. delta: Final versions of methods like #attr_reader, etc. are added. Also,
- implementation-specific versions of methods that override the versions
- provided in common are added.
-
- 7. loader: The compiled version of kernel/loader.rb is run.
-
- The final stage sets up the life cycle of a ruby process. It starts by
- connecting the VM to the system, sets up load paths, and reads
- customization scripts from the home directory. It traps signals, and
- processes command line arguments.
-
- After that, it either runs the script passed to it from the command line
- or boots up the interactive ruby shell. When that finishes, it runs any
- at_exit blocks that had been registered, finalizes all objects, and
- exits.
-
-## Load Order
-
-The files in the kernel directories bootstrap, platform, common, and delta,
-implement the respective bootstrapping stages above. The order in
-which these directories are loaded is specified in runtime/index.
-
-When an rbc file is loaded, code at the script level and in class or module
-bodies is executed. For instance, when loading
-
- class SomeClass
- attr_accessor :value
- end
-
-the call to #attr_accessor will be run. This requires that any code called in
-script, class, or module bodies be loaded before the file that calls the code.
-The kernel/alpha.rb defines most of the code that will be needed at the script
-or module level. However, other load order dependencies exist between some of
-the platform, common, delta, and compiler files.
-
-These load order dependencies are addressed by the load_order.txt file located
-in each of the kernel/\*\* directories. If you modify code that adds a load
-order dependency, you must edit the load_order.txt files to place the depended
-on file above the file that depends on it. Also, if you add a new file to one
-of the kernel directories, you must add the file name to the load_order.txt
-file in that directory. These files are copied to the appropriate runtime/\*\*
-directories during build. During each of the bootstrap stages above, the VM
-loads the files listed in load_order.txt in order.
diff --git a/doc/en/build-system.markdown b/doc/en/build-system.markdown
deleted file mode 100644
index 20051bc..0000000
--- a/doc/en/build-system.markdown
+++ /dev/null
@@ -1,55 +0,0 @@
----
-layout: doc_en
-title: Build System
-previous: Specs - Compiler Specs
-previous_url: specs/compiler
-next: Bootstrapping
-next_url: bootstrapping
-review: true
----
-
-TODO: Many details are missing.
-
-Rubinius uniformly uses Rake as the build system for its own files. However
-Rubinius also includes the source for several external libraries and these
-typically use makefiles.
-
-
-## Development versus Install Builds
-
-Rubinius consists of the executable, and various support files like the core
-and standard libraries. The executable needs to know where to find these files
-even if moved to a different location. To handle this problem, Rubinius
-distinguishes two build types: development and install. The executable stores
-the full path to its base directory, relative to which it expects to find the
-files it needs.
-
-The development executable stores the path to the source directory in which it
-was built. You can then move the executable to a different location but as you
-make changes to the core library files in the kernel/\*\* directories, the
-executable will continue to use those files.
-
-The install executable stores the path to the install directory. Again, even if
-the executable is moved to a new location, it will continue to find the
-installed files.
-
-This has consequences, of course. If you build a development executable and then
-rename your source directory, you will need to rebuild. Likewise, if you build an
-install executable and rename the install directory, the executable will *not*
-function, *even if the executable is in the directory*. The executable checks a
-single, hard-coded path. If this ends up being very painful for some reason,
-we'll revise it.
-
-
-## Installing Rubinius
-
-To install Rubinius, you must first configure it with an install prefix:
-
- ./configure --prefix=/path/to/install/dir
-
-The configure process creates a 'config.rb' file that specifies the key file
-paths that Rubinius uses. Once configured, run 'rake install' to build and
-install. The install procedure builds all the files, including compiling the
-Ruby standard library files in the lib/ directory, then copies them into the
-install location using the 'install' program. The install tasks are located in
-rakelib/install.rake.
diff --git a/doc/en/bytecode-compiler.markdown b/doc/en/bytecode-compiler.markdown
deleted file mode 100644
index 9b8c836..0000000
--- a/doc/en/bytecode-compiler.markdown
+++ /dev/null
@@ -1,36 +0,0 @@
----
-layout: doc_en
-title: Bytecode Compiler
-previous: Virtual Machine - Custom Dispatch Logic
-previous_url: virtual-machine/custom-dispatch-logic
-next: Parser Stage
-next_url: bytecode-compiler/parser
-review: true
----
-
-The Rubinius bytecode compiler converts Ruby source code to bytecode that the
-virtual machine can execute. It uses a series of sequential stages to
-transform the input into a form that the virtual machine can understand.
-
-Each of these stages is decoupled from the rest of the process,
-expecting only a particular input form and sending its output to the
-next stage. As a result, the compilation process is quite configurable,
-and you can instrument any of the stages simply.
-
-Each stage of the process receives an input, runs the stage, and passes
-the output from the stage to the next stage of the process. The default
-stages, as well as their inputs and outputs, are illustrated below.
-
-
-
-
-
-1. [Parser Stage](/doc/en/bytecode-compiler/parser/)
-1. [AST](/doc/en/bytecode-compiler/ast/)
-1. [Generator Stage](/doc/en/bytecode-compiler/generator/)
-1. [Encoder Stage](/doc/en/bytecode-compiler/encoder/)
-1. [Packager Stage](/doc/en/bytecode-compiler/packager/)
-1. [Writer Stage](/doc/en/bytecode-compiler/writer/)
-1. Printers
-1. [Transformations](/doc/en/bytecode-compiler/transformations/)
-1. [Customizing the Pipeline](/doc/en/bytecode-compiler/customization/)
diff --git a/doc/en/bytecode-compiler/ast.markdown b/doc/en/bytecode-compiler/ast.markdown
deleted file mode 100644
index 80d023c..0000000
--- a/doc/en/bytecode-compiler/ast.markdown
+++ /dev/null
@@ -1,106 +0,0 @@
----
-layout: doc_en
-title: Abstract Syntax Trees
-previous: Parser Stage
-previous_url: bytecode-compiler/parser
-next: Generator Stage
-next_url: bytecode-compiler/generator
-review: true
----
-
-Once the parser has finished calling `process_*` methods an
-abstract syntax tree is created. The syntax tree represents the
-abstract syntactic structure of the parsed source code. Each node in
-the tree denotes a construct in the source code. This tree is composed of instances
-of classes defined in *lib/compiler/ast/* directory.
-Each of these classes inherits from `Rubinius::AST::Node` class.
-The `Node` class defines a few methods that are utilized
-by the subclasses (eg. pos(g) which records the line number for debugging purposes).
-
-The AST classes usually define at least 3 methods:
-
-* initialize(line, args) - called by various `process_*` methods in the previous stage
-* bytecode(g) - called by the Generator in the next stage
-* to_sexp - used to represent the AST node as a symbolic expression
-
-The easiest way to see the AST that gets created is to call `to_ast`
-on a string containing the code, eg:
-
- irb(main):002:0> "a = 1".to_ast
- => #
- @name=:a @variable=nil @line=1>
-
-or compile the code and pass the -A option:
-
- rbx compile -A -e "def hello;end"
- Script
- @name: __script__
- @file: "(snippet)"
- @body: \
- Define
- @name: hello
- @line: 1
- @arguments: \
- FormalArguments
- @defaults: nil
- @names: \
- @block_arg: nil
- @optional: \
- @splat: nil
- @line: 1
- @required: \
- @body: \
- Block
- @line: 1
- @array: \
- NilLiteral
- @line: 1
-
-Similarily it's possible to get a representation of the syntax tree as
-s-expressions:
-
- irb(main):002:0> "a = 1".to_sexp
- => [:lasgn, :a, [:lit, 1]]
-
-or pass the -S option to compile:
-
- rbx compile -S -e "def hello;end"
- [:script, [:defn, :hello, [:args], [:scope, [:block, [:nil]]]]]
-
-The AST is a nested structure where nodes contain other nodes. For
-example the `hello` method defined above is composed of a `Script` node
-containing `Define` in its `@body` which in turns contains
-`FormalArguments` in its `@arguments` and `Block` in its `@body`. The
-`Block` node contains only the `NilLiteral` in its `@array`. The
-`NilLiteral` node is a leaf node, it doesn't contain other nodes.
-
-Note that the following `if` expression:
-
- rbx compile -S -e ":foo if :bar"
- [:script, [:if, [:lit, :bar], [:lit, :foo], nil]]
-
-and the same `if` expression but written differently
-
- rbx compile -S -e "if :bar then :foo; end"
- [:script, [:if, [:lit, :bar], [:lit, :foo], nil]]
-
-produce exactly the same syntax tree. Because the tree doesn't
-represent every detail that appears in the real syntax it is called
-"abstract".
-
-
-## Files Referenced
-
-* *lib/compiler/ast/*: directory containing definitions of all AST classes
-
-## Customization
-
-There are two ways to customize this stage of the compilation process.
-The easiest way to customize the creation of the AST is through
-[AST Transforms](/doc/en/bytecode-compiler/transformations/).
-
-You can also subclass the Melbourne processor and define your own
-handlers for the `process_` methods. This is an advanced topic that is
-not yet documented.
-
diff --git a/doc/en/bytecode-compiler/compiler.markdown b/doc/en/bytecode-compiler/compiler.markdown
deleted file mode 100644
index 543a061..0000000
--- a/doc/en/bytecode-compiler/compiler.markdown
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: doc_en
-title: Compiler
-previous: AST
-previous_url: bytecode-compiler/ast
-next: Transformations
-next_url: bytecode-compiler/transformations
-review: true
----
-
-TODO: document the compiler.
-
-The bytecode compiler walks the AST produced by the parser and emits bytecode
-for each node. The source for the compiler is in lib/compiler.
diff --git a/doc/en/bytecode-compiler/customization.markdown b/doc/en/bytecode-compiler/customization.markdown
deleted file mode 100644
index 4d137ed..0000000
--- a/doc/en/bytecode-compiler/customization.markdown
+++ /dev/null
@@ -1,10 +0,0 @@
----
-layout: doc_en
-title: Customizing the Compiler Pipeline
-previous: Transformations
-previous_url: bytecode-compiler/transformations
-next: JIT Compiler
-next_url: jit
-review: true
----
-
diff --git a/doc/en/bytecode-compiler/encoder.markdown b/doc/en/bytecode-compiler/encoder.markdown
deleted file mode 100644
index 81ed157..0000000
--- a/doc/en/bytecode-compiler/encoder.markdown
+++ /dev/null
@@ -1,39 +0,0 @@
----
-layout: doc_en
-title: Encoder Stage
-previous: Generator Stage
-previous_url: bytecode-compiler/generator
-next: Packager Stage
-next_url: bytecode-compiler/packager
----
-
-Once the generator has processed the AST, it needs to properly encode
-the bytecode. This stage is very simple, and is mostly for
-recordkeeping.
-
-The Encoder stage is responsible for two things:
-
-* converting the stream of instructions created in the previous stage
- (when the AST nodes called `bytecode`) into an instruction sequence.
-* validating that the stack does not underflow, overflow, or otherwise
- contain faulty semantics.
-
-It performs these steps on the main Generator object, as well as any
-child Generators (generators for blocks, methods or other structures
-encountered inside of the main body).
-
-Once this stage is complete, it passes the encoded Generator object to
-the next stage, the Packager stage.
-
-## Files Referenced
-
-* *lib/compiler/generator.rb*: The `encode` method in the file performs
- the bulk of the work in this stage.
-
-## Customization
-
-Since this stage is so simple, you will not need to customize it. You
-might want to instrument it (for instance, for profiling or printing).
-To learn more about general-purpose customization, which you can use to
-instrument any stage, check out [Customizing the Compiler
-Pipeline](/doc/en/bytecode-compiler/customization/).
diff --git a/doc/en/bytecode-compiler/generator.markdown b/doc/en/bytecode-compiler/generator.markdown
deleted file mode 100644
index 0113358..0000000
--- a/doc/en/bytecode-compiler/generator.markdown
+++ /dev/null
@@ -1,131 +0,0 @@
----
-layout: doc_en
-title: Generator Stage
-previous: AST
-previous_url: bytecode-compiler/ast
-next: Encoder Stage
-next_url: bytecode-compiler/encoder
-review: true
----
-
-Once Melbourne has created an AST, it invokes the generator stage,
-passing the AST as the input.
-
-The generator stage creates a new instance of `Rubinius::Generator`, and
-asks the root of the AST to generate its bytecode onto the `Generator`
-object.
-
-A `Generator` provides a pure-Ruby DSL for generating Rubinius bytecode.
-At its core, the `Generator` provides methods that map directly to
-[Rubinius Instructions](/doc/en/virtual-machine/instructions/). For instance,
-to create an instruction to push a nil onto the stack, you could call
-the method `push_nil` on a `Generator` instance.
-
-The `Generator` class also provides a number of convenience methods that
-allow you to generate common patterns of bytecodes without going into
-the very low-level details of some areas of the Rubinius instruction
-set.
-
-For instance, to send a method directly using Rubinius bytecode, you
-would need to create a literal representing the name of the method, and
-then call `send_stack` to send the method. In addition, if you wanted to
-call a private method, you would first need to create a bytecode
-specifically allowing private method invocation. If you wanted to invoke
-the method `puts` with no arguments, allowing private method
-invocations, you would:
-
- # here, g is a Generator instance
- g.allow_private
- name = find_literal(:puts)
- g.send_stack name, 0
-
-Using the `send` helper, you could do this more simply:
-
- g.send :puts, 0, true
-
-When generating the bytecode for an AST, Rubinius invokes the method
-`bytecode` on each AST node, passing in the current `Generator`
-instance. Here's the bytecode method for the `if` node:
-
- def bytecode(g)
- pos(g)
-
- done = g.new_label
- else_label = g.new_label
-
- @condition.bytecode(g)
- g.gif else_label
-
- @body.bytecode(g)
- g.goto done
-
- else_label.set!
- @else.bytecode(g)
-
- done.set!
- end
-
-First, the method calls the method `pos`, a method on the base `Node`
-class, which calls `g.set_line @line`. This is used by the VM to provide
-debugging information for running code.
-
-Next, the code uses the label helpers in the `Generator`. Raw Rubinius
-bytecode does not have any control structures except for a few goto
-instructions (plain `goto`, `goto_if_true` and `goto_if_false`). You can
-use the shortened form `git` for `goto_if_true` and `gif` for
-`goto_if_false`. In this case, we create two new labels, one for the end
-of the `if` condition, and one marking the start of the `else` block.
-
-After creating the two labels, the `if` node invokes the `bytecode`
-method on its `@condition` child node, passing along the current
-`Generator` object. This will emit the bytecode for the condition into
-the current stream.
-
-That process should leave the value of the condition expression on the
-stack, so the `if` node emits a `goto_if_false` instruction that will
-jump immediately to `else_label`. It then uses the same pattern we saw
-before to ask the `@body` to emit its bytecode into the current stream,
-and then emits an unconditional `goto` instruction to the end of the
-conditional.
-
-Next, we need to mark the location of the `else_label`. By decoupling the
-creation of the label from its use, we can pass it to the `goto`
-instruction before marking its location, which is crucial for many
-control structures.
-
-We then ask the `@else` node to emit its bytecode and mark the location
-of the `done` label.
-
-This process occurs recursively from the root node all the way through
-the AST, which results in populating the `Generator` object with a
-bytecode representation of the AST that started from the root.
-
-You will probably find it useful to look at the classes in the
-`lib/compiler/ast` directory, which define all of the AST nodes and
-their associated bytecode methods. This is also a good way to see
-practical examples of using the `Generator` API.
-
-Once the `Generator` has acquired the bytecode representation of the
-AST, it invokes the next stage of the compiler, the Encoder stage.
-
-## Files Referenced
-
-* *lib/compiler/generator_methods.rb*: A generated file containing Ruby
- wrappers around the Rubinius instructions. These methods map directly
- onto the [Rubinius Instructions](/doc/en/virtual-machine/instructions/)
-* *lib/compiler/generator.rb*: The definition of the `Generator` object.
- This class mixes in the raw generator methods, and defines a number of
- higher level APIs for generating common bytecode patterns.
-* *lib/compiler/ast*: The definition of all of the AST nodes created by
- the Parser stage of the compiler.
-
-## Customization
-
-The easiest way to customize the Generator stage of the compiler process
-is by creating higher-level methods in addition to the common ones
-provided by the default `Generator` implementation.
-
-You can also customize which generator class is passed in. To learn
-more about customizing individual compiler stages or the compiler
-pipeline, please read [Customizing the Compiler
-Pipeline](/doc/en/bytecode-compiler/customization/).
diff --git a/doc/en/bytecode-compiler/packager.markdown b/doc/en/bytecode-compiler/packager.markdown
deleted file mode 100644
index 0698f42..0000000
--- a/doc/en/bytecode-compiler/packager.markdown
+++ /dev/null
@@ -1,69 +0,0 @@
----
-layout: doc_en
-title: Packager Stage
-previous: Encoder Stage
-previous_url: bytecode-compiler/encoder
-next: Writer Stage
-next_url: bytecode-compiler/writer
----
-
-Once the Generator has been properly encoded in the Encoder stage,
-Rubinius packages the bytecode up as a CompiledCode by creating a new
-CompiledCode and setting a number of properties on it.
-
-These properties are available on any CompiledCode. You can retrieve
-the CompiledCode from a Ruby Method object by calling `executable` on
-it.
-
-* *iseq*: a Tuple containing the raw instruction sequence
-* *literals*: a Tuple contaning the literals used in the method.
- Literals are used internally by Rubinius for values like Strings, and
- are used by the `push_literal` and `set_literal` instructions.
-* *lines*: an Array containing the first instruction pointer for each
- line represented by the bytecode
-* *required_args*: the number of arguments required by the method
-* *total_args*: the total number of arguments, including optional
- arguments but not `*args`
-* *splat*: the position of the splat argument, if any
-* *local_count*: the number of local variables, including parameters
-* *local_names*: a Tuple containing a list of all of the local variable
- names. The first names will be the required, optional, splat and block
- arguments, in that order.
-* *file*: the name of the file that will be used in stack traces and
- other debugging information
-* *name*: the name of the method
-* *primitive*: the name of the primitive associated with this method, if
- any
-* metadata: it is possible to store additional structured metadata on a
- compiled method. The compiled method has a piece of metadata named
- `for_block` with the value `true` if the original generator was
- created for a block.
-
-The Packager stage also makes sure that any child generators (such as
-generators for blocks or methods) are also converted into compiled
-methods. These child compiled methods are included in the literals tuple
-of the parent compiled method.
-
-Once the Generator has finished packaging itself as a CompiledCode, it
-invokes the Writer stage, passing in the CompiledCode as its input.
-
-## Files Referenced
-
-* *kernel/bootstrap/compiled_code.rb*: the basic implementation of
- CompiledCode, mostly composed of wiring up primitives
-* *kernel/common/compiled_code.rb*: a more robust implementation of
- CompiledCode, a combination of primitive methods and methods written
- in Ruby
-* *vm/builtin/compiledcode.cpp*: the C++ implementation of the
- CompiledCode primitives
-* *lib/compiler/generator.rb*: The implementation of the `package`
- method, which populates the CompiledCode with information from the
- Generator object.
-
-## Customization
-
-In general, the `package` method is designed to populate the
-CompiledCode with a group of variables. However, you could also use
-the packager to populate another object with the same interface.
-However, it would not necessarily be useful on its own, without
-additional customizations later on.
diff --git a/doc/en/bytecode-compiler/parser.markdown b/doc/en/bytecode-compiler/parser.markdown
deleted file mode 100644
index f6dd06e..0000000
--- a/doc/en/bytecode-compiler/parser.markdown
+++ /dev/null
@@ -1,62 +0,0 @@
----
-layout: doc_en
-title: Ruby Parser
-previous: Bytecode Compiler
-previous_url: bytecode-compiler
-next: AST
-next_url: bytecode-compiler/ast
-review: true
----
-
-The first stage in the compilation pipeline is the Ruby Parser. The Ruby
-parser receives either a String of code or a file and passes an AST to
-the next stage of the process, the generator.
-
-The parser itself (called Melbourne) has a C part, which is essentially
-MRI's parser, and a Ruby part, which is responsible for creating the Ruby
-AST. The C parser communicates with Ruby by calling a method for each
-node in the parse tree.
-
-Each of these methods has a signature containing all of the information
-about the part of the parse tree it is processing. For instance, if the
-underlying Ruby code has an `if` statement, the C parser will call
-`process_if` with the line number, a parameter representing the
-condition, and parameters representing the body of the if statement and
-the else section, if any.
-
- def process_if(line, cond, body, else_body)
- AST::If.new line, cond, body, else_body
- end
-
-You can see all of the possible `process_` calls by taking a look at
-`lib/melbourne/processor.rb` in the Rubinius source code.
-
-Note that in many cases, the parser passes the result of calling a
-previous `process_` method as the arguments to a `process_` method. In
-the case of `true if 1`, the parser first calls `process_lit(line, 1)` and
-`process_true(line)`. It also calls `process_nil(line)`, because the
-original parse tree contains a `nil` for the `else` body. It then calls
-`process_if` with the line number, the result of `process_lit`, the
-result of `process_true`, and the result of `process_nil`.
-
-This process recursively builds up a tree structure, which Rubinius passes
-on to the next stage, the Generator stage.
-
-## Files Referenced
-
-* *lib/melbourne/processor.rb*: the Ruby interface to the C parser. This
- file contains methods beginning with `process_`, which the C parser
- calls for each node in the raw parse tree.
-* *lib/compiler/ast/\**: the definitions for each of the AST nodes used
- by the melbourne processor.
-
-## Customization
-
-There are two ways to customize this stage of the compilation process.
-The easiest way to customize the creation of the AST is through
-[AST Transforms](/doc/en/bytecode-compiler/transformations/).
-
-You can also subclass the Melbourne processor and define your own
-handlers for the `process_` methods. This is an advanced topic that is
-not yet documented.
-
diff --git a/doc/en/bytecode-compiler/transformations.markdown b/doc/en/bytecode-compiler/transformations.markdown
deleted file mode 100644
index 137ad39..0000000
--- a/doc/en/bytecode-compiler/transformations.markdown
+++ /dev/null
@@ -1,50 +0,0 @@
----
-layout: doc_en
-title: Transformations
-previous: Writer Stage
-previous_url: bytecode-compiler/writer
-next: Customizing the Pipeline
-next_url: bytecode-compiler/customization
----
-
-The bytecode compiler has a simple AST transform mechanism that recognizes
-certain AST forms and replaces them. The replaced forms emit different
-bytecode than the original form would have emitted. The source for the
-transforms is in lib/compiler/ast/transforms.rb
-
-TODO: document the compiler plugin architecture.
-
-
-### Safe Math Compiler Transform
-
-Since the core libraries are built of the same blocks as any other Ruby code
-and since Ruby is a dynamic language with open classes and late binding, it is
-possible to change fundamental classes like Fixnum in ways that violate the
-semantics that other classes depend on. For example, imagine we did the
-following:
-
- class Fixnum
- def +(other)
- (self + other) % 5
- end
- end
-
-While it is certainly possible to redefine fixed point arithmetic plus to be
-modulo 5, doing so will certainly cause some class like Array to be unable to
-calculate the correct length when it needs to. The dynamic nature of Ruby is
-one of its cherished features but it is also truly a double-edged sword in
-some respects.
-
-In the standard library the 'mathn' library redefines Fixnum#/ in an unsafe
-and incompatible manner. The library aliases Fixnum#/ to Fixnum#quo, which
-returns a Float by default.
-
-Because of this there is a special compiler plugin that emits a different
-method name when it encounters the #/ method. The compiler emits #divide
-instead of #/. The numeric classes Fixnum, Bignum, Float, and Numeric all
-define this method.
-
-The safe math transform is enabled during the compilation of the Core
-libraries to enable the plugin. During regular 'user code' compilation, the
-plugin is not enabled. This enables us to support mathn without breaking the
-core libraries or forcing inconvenient practices.
diff --git a/doc/en/bytecode-compiler/writer.markdown b/doc/en/bytecode-compiler/writer.markdown
deleted file mode 100644
index e2cf473..0000000
--- a/doc/en/bytecode-compiler/writer.markdown
+++ /dev/null
@@ -1,42 +0,0 @@
----
-layout: doc_en
-title: Writer Stage
-previous: Packager Stage
-previous_url: bytecode-compiler/packager
-next: Transformations
-next_url: bytecode-compiler/transformations
----
-
-Once the Packager has created the CompiledCode, Rubinius will write
-the method to a file for future consumption. For instance, after a file
-is required for the first time, subsequent requires will load the file
-from disk, rather than loading in the Ruby code, then parsing and
-compiling it.
-
-This stage is extremely simple. It takes the original input file name,
-appends `c` to the end, and calls Rubinius::CompiledFile.dump with the
-CompiledCode from the previous stage and the file name to write to.
-
-Once it finishes writing the file to the disk, it returns the input (the
-CompiledCode), which becomes the return value of the entire compiler
-process.
-
-## Files Referenced
-
-* *lib/compiler/compiled_file.rb*: the CompiledFile implementation.
- `CompiledFile.dump` is called in order to perform the actual dumping.
-
-## Customizing
-
-This stage is actually optional, and is only used when compiling a file.
-When compiling a String, such as with eval, this step is skipped. In
-that case, the compiler stops in the Packager stage, and returns the
-CompiledCode from that stage as the return value of the compiler.
-
-Because of the architecture of the Rubinius compiler, it is easy to add
-additional stages to the end of the process, and as long as each of
-those stages returns the inputted CompiledCode (or a different
-CompiledCode), everything will work as expected.
-
-For more information, please read [Customizing the Compiler
-Pipeline](/doc/en/bytecode-compiler/customization/).
diff --git a/doc/en/contributing.markdown b/doc/en/contributing.markdown
deleted file mode 100644
index f50e11b..0000000
--- a/doc/en/contributing.markdown
+++ /dev/null
@@ -1,82 +0,0 @@
----
-layout: doc_en
-title: Contributing
-previous: Getting Started - Troubleshooting
-previous_url: getting-started/troubleshooting
-next: Communication
-next_url: contributing/communication
----
-
-The Rubinius project welcomes your contributions. There are many things to do
-to help out. Most importantly, you should do something that interests you.
-That is the best way to have enthusiasm and energy for your work.
-
-If you have questions about Rubinius, the best way to get answers is to chat
-with us in the #rubinius IRC channel on irc.freenode.net.
-
-Below are several ideas for things to do on Rubinius.
-
-
-## Run Your Code
-
-Your code is often more vicious than the specs. Run your pet project under
-Rubinius and report issues. See [How To Write a Ticket](/doc/en/how-to/write-a-ticket).
-
-
-## Ask For Help
-
-Anything that we can do to help, we will. Make sure to do your own research
-too, if possible. Rubinius attempts to be a project that you can easily study,
-learn from, and hopefully extend.
-
-We will certainly accept and appreciate simple bug reports, but we can give
-priority to tickets that include simple steps to reproduce the issue. Even
-better are tickets that include RubySpecs that demonstrate the bug and a patch
-that fixes it.
-
-
-## Write Specs
-
- 1. Run `bin/mspec tag --list incomplete ` to show specs that have been
- tagged as incomplete. These specs may simply need review, or there could
- be specs missing for a particular class.
-
- NOTE: You can specify the pseudo-directory ':files' for \, which will
- show tags for all the specs that should run on Rubinius. Or you can
- specify any subdirectory of the spec/ directory to list tags for specs in
- that subdirectory.
-
- 2. Find unspecified behaviors. See [How To Write a Ruby
- Spec](/doc/en/how-to/write-a-ruby-spec).
-
-
-## Fix Failing Specs
-
- 1. Run `bin/mspec tag --list fails ` to show specs tagged as failing.
-
- NOTE: You can specify the pseudo-directory ':files' for \, which will
- show tags for all the specs that should run on Rubinius. Or you can
- specify any subdirectory of the spec/ directory to list tags for specs in
- that subdirectory.
-
- 2. Pick a spec that looks interesting and see if you can write a patch that
- will make it pass.
-
-
-## Write Docs
-
-Study how Rubinius works and write highlevel documentation that will help
-others learn about the implementation details.
-
-
-## Cleanup Code
-
-Review the [Style Guide](/doc/en/contributing/style-guide/) for coding
-guidelines.
-
-
-## Triage Tickets
-
- * Revive or close old tickets.
- * Build minimal test cases that reproduce the bugs. Then see if there are
- already RubySpecs for the issue. If not, consider writing some.
diff --git a/doc/en/contributing/communication.markdown b/doc/en/contributing/communication.markdown
deleted file mode 100644
index 9312c60..0000000
--- a/doc/en/contributing/communication.markdown
+++ /dev/null
@@ -1,18 +0,0 @@
----
-layout: doc_en
-title: Communication
-previous: Contributing
-previous_url: contributing
-next: Style Guide
-next_url: contributing/style-guide
-review: true
----
-
-The Rubinius team appreciates and prizes your contributions. Since Rubinius is
-a large and sometimes complex project, communication can be a challenge at
-times. We rely heavily on IRC, however, there are other communication channels
-as well. Below is a list of places we can be reached:
-
-* IRC: `#rubinius` on irc.freenode.net
-* Twitter: [twitter.com/rubinius](http://twitter.com/rubinius)
-* Mailing List: [Google Groups](http://groups.google.com/group/rubinius-dev)
diff --git a/doc/en/contributing/style-guide.markdown b/doc/en/contributing/style-guide.markdown
deleted file mode 100644
index f8d618a..0000000
--- a/doc/en/contributing/style-guide.markdown
+++ /dev/null
@@ -1,107 +0,0 @@
----
-layout: doc_en
-title: Coding Style Guide
-previous: Communication
-previous_url: contributing/communication
-next: Ruby
-next_url: ruby
----
-
-The following guidelines aim to keep the Rubinius codebase maintainable. When
-in doubt about a guideline here, ask us in the #rubinius IRC channel on
-irc.freenode.net.
-
-
-## All Code
-
- * Configure your editor for soft tabs, not hard tabs
- * Expand tabs to two spaces
- * Leave a trailing newline at the end of each file
- * Don't leave spaces at the end of each line
-
-
-## C++ Code
-
- * No space between condition and paren.
- Use `if(1)` NOT `if (1)`
-
- * Put the opening brace on the same line as the function declaration or
- conditional
-
- * Always use curly braces, even if they can be left out.
-
- * Prefer parentheses to implicit precedence rules (within reason)
-
- * Alternate versions of functions should be named why they are different
- from the primary. If there is a function 'person()' and you want a
- version that takes the name of the person, it should be
- 'person_with_name(char \*name)' or 'person_with_details(char \*name, ...)'.
- NOT 'person1(char \*name)'.
-
-
-## Ruby Code
-
- * Methods: Try to keep your methods short--one screenful and try to adhere
- to DRY within reason. Generally common functionality should be abstracted
- to helper methods (which you can make 'private') but in some cases,
- particularly working with Core, sometimes trying to DRY things up is just
- an obstacle if you have to maneuver around several different error
- conditions, for example.
-
- * Method names: should be clear, expressive and meaningful. Avoid using
- underscores to 'protect' the method ('\_\_send\_\_') with some exceptions.
-
- * Smalltalk-style method names are OK, meaning that you could have a method
- `SomeClass.make_from` when it is intended to be invoked as
- `SomeClass.make_from file` or `SomeClass.make_from :file => name`. There
- the parameter name _completes_ the method name and makes for more natural
- reading.
-
- * Variable names: make them clear and meaningful (with some well-known
- exceptions like using 'i' for a counter.) Try to avoid shadowing method
- names, for example within Array use 'idx' in favour of 'index' because the
- latter is also a method name.
-
- * Postconditions: use postconditions only *if* your expression is a
- one-liner *and* you do not have many conditions.
-
- * Blocks: Use either `do ... end` or `{...}`, spaces between the delimiters
- and code (`foo { |arg| code }`). Split long or complex expressions over
- multiple lines like this:
-
- mapped = foo.map do |elem|
- do_something_with elem
- end
-
- * Module/Class definitions with scope qualifiers:
-
- module Rubinius::Profiler
- class Sampler
- end
- end
-
- * Method definitions: don't add empty parentheses when there is no parameter.
-
- def clear
- @total = 0
- end
-
-## Kernel Code
-
-The primary guideline for all kernel code is simple and efficient. Simple code
-is often more efficient and generally more comprehensible. There should be no
-metaprogramming code in bootstrap. Use the #attr_xxx methods throughout the
-kernel source. Also, alias methods using the #alias_method call next to the
-method definition. Specify private methods with the `private :sym` method next
-to the method definition. Remember that the versions of the methods listed
-above in the alpha stage take a single, symbol argument.
-
-## Documentation
-
- * Use RDoc for documentation in Ruby code.
-
- * Use Doxygen for documentation in C++ code.
-
- * Use Markdown for documentation in the /doc directory. See [Markdown
- syntax](http://daringfireball.net/projects/markdown/syntax) Set the text
- width to 78 characters and use hard breaks.
diff --git a/doc/en/frequently-asked-questions.markdown b/doc/en/frequently-asked-questions.markdown
deleted file mode 100644
index 7af4250..0000000
--- a/doc/en/frequently-asked-questions.markdown
+++ /dev/null
@@ -1,66 +0,0 @@
----
-layout: doc_en
-title: Frequently Asked Questions
-previous: Index of Terms
-previous_url: index-of-terms
----
-
-## Can I hide source code using Rubinius' byte code format?
-
-No. Rubinius' byte code format provides no mechanisms to obfuscate the
-contents of it or the original source code. Source code obfuscation will never
-be added to the byte code format.
-
-## Does Rubinius support ARM?
-
-Not entirely. Currently the JIT does not support ARM and as such you'll have to
-disable it if you want to run Rubinius on ARM. Even then we can't guarantee
-that Rubinius will work reliably on this architecture. We hope to support ARM
-in the future.
-
-For more information, see the following issues:
-
-*
-*
-
-## Does Rubinius support Windows?
-
-No, not at the moment. While we would love to support Windows we sadly don't
-have anybody with Windows experience on the team. A corresponding issue for
-this can be found at .
-
-If you would like to help with getting Rubinius running on Windows please get
-in touch.
-
-## Why is the README of Rubinius in plain text?
-
-Various developers have opened pull requests over time to change the plain text
-README to a Markdown formatted README. Due to the simplicity of the README we
-have decided to keep it plain text only.
-
-For more information, see the following:
-
-*
-*
-*
-
-## What are all these rubysl Gems doing in my Rubinius installation?
-
-Rubinius uses Gems for its standard library. For example, `rubysl-date` is a
-Gem containing the `Date` library used by Rubinius. These components are
-installed, updated and otherwise maintained as ordinary Gems.
-
-Although you can technically remove then it is not recommended to do so. Due to
-these components being used throughout the Rubinius & Ruby ecosystem you might
-end up with a broken installation if you remove them.
-
-## How to install Rubinius on OSX 10.10 "Yosemite"?
-
-Warning: don't try to install Rubinius using system ruby. Use `rbenv`, `chruby` or `rvm` to build latest stable MRI and then run ``ruby-install`` after selecting freshly built ruby.
-
-1. Get Homewbrew if you don't have it: ``ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"``
-2. Get LLVM: ``brew install llvm``
-3. Get latest ruby-install: ``brew install ruby-install --HEAD``
-4. Install with homebrews LLVM: ``ruby-install rbx -- --llvm-path="/usr/local/Cellar/llvm/3.4.2"``
-
-
diff --git a/doc/en/getting-started.markdown b/doc/en/getting-started.markdown
deleted file mode 100644
index 4b9a51c..0000000
--- a/doc/en/getting-started.markdown
+++ /dev/null
@@ -1,19 +0,0 @@
----
-layout: doc_en
-title: Getting Started
-previous: What is Rubinius?
-previous_url: what-is-rubinius
-next: Requirements
-next_url: getting-started/requirements
----
-
-This guide will help you get Rubinius running. It assumes you know something
-about Ruby and about installing software on your system.
-
-If you have trouble following the directions here, visit the #rubinius IRC
-channel on irc.freenode.net for help.
-
-1. [Requirements](/doc/en/getting-started/requirements/)
-1. [Building](/doc/en/getting-started/building/)
-1. [Running Rubinius](/doc/en/getting-started/running-rubinius/)
-1. [Troubleshooting](/doc/en/getting-started/troubleshooting/)
diff --git a/doc/en/getting-started/building.markdown b/doc/en/getting-started/building.markdown
deleted file mode 100644
index 34c6074..0000000
--- a/doc/en/getting-started/building.markdown
+++ /dev/null
@@ -1,68 +0,0 @@
----
-layout: doc_en
-title: Building Rubinius
-previous: Requirements
-previous_url: getting-started/requirements
-next: Running Rubinius
-next_url: getting-started/running-rubinius
----
-
-You can build and run Rubinius from the source directory. You do not need to
-install Rubinius to run it. The directions below will detail both installing
-Rubinius and running it from the source directory.
-
-Rubinius uses LLVM for the JIT compiler and depends on LLVM 3.x. The
-`configure` script will automatically check whether a version is already
-available or will download one if not. If you do have LLVM installed and
-Rubinius fails to link with it for any reason, pass `--skip-system` to the
-`configure` script in the directions below.
-
-### Getting the Source
-
-The Rubinius source code is available as a tarball and as a project on Github.
-You can [download the tarball
-here](https://github.com/rubinius/rubinius/tarball/master).
-
-To use Git:
-
- 1. Change your current working directory to your development directory
- 2. `git clone git://github.com/rubinius/rubinius.git`
-
-
-### Installing Rubinius
-
-If you are planning on using Rubinius to run your application, this is a good
-option. However, you can also run Rubinius directly from the source directory.
-See the next section for more details on that.
-
-We recommend installing Rubinius to a location that does not require `sudo` or
-superuser privileges. To install Rubinius:
-
- 1. `bundle install`
- 2. `./configure --prefix=/path/to/install/dir`
- 3. `rake install`
- 4. Follow the directions to add the Rubinius _bin_ directory to your PATH
-
-
-### Running from the Source Directory
-
-If you plan to work on Rubinius itself, you should use this option.
-
- 1. `./configure`
- 2. `rake`
-
-If you are just trying out Rubinius, follow the directions to add the _bin_
-directory to your PATH.
-
-However, if you are developing Rubinius, you should NOT add the _bin_
-directory to your PATH because the Rubinius build system will pick up the
-`ruby` and `rake` links to the Rubinius executable. Rubinius needs a separate
-Ruby executable to bootstrap itself during the build process.
-
-### Development Mode for Debugging
-
-If you are trying to debug the VM and want to attach a debugger, such as GDB,
-then you will want to compile Rubinius without optimizations. You can do this
-by setting the 'DEV' environment variable and then building.
-
-For example: `DEV=1 rake build`
diff --git a/doc/en/getting-started/requirements.markdown b/doc/en/getting-started/requirements.markdown
deleted file mode 100644
index f7329da..0000000
--- a/doc/en/getting-started/requirements.markdown
+++ /dev/null
@@ -1,59 +0,0 @@
----
-layout: doc_en
-title: Requirements
-previous: Getting Started
-previous_url: getting-started
-next: Building
-next_url: getting-started/building
----
-
-Ensure you have the following programs and libraries installed. Also see the
-subsections below for special requirements for your particular operating
-system.
-
-The following are suggestions for getting more information about the programs
-and libraries needed to build Rubinius. Your operating system or package
-manager may have other packages available.
-
- * [GCC and G++ 4.x](http://gcc.gnu.org/)
- * [GNU Bison](http://www.gnu.org/software/bison/)
- * [MRI Ruby 2.0.0+](http://www.ruby-lang.org/) If your system does not have
- Ruby 2.0.0 installed, consider using [RVM](https://rvm.beginrescueend.com/)
- to install it.
- * [Rubygems](http://www.rubygems.org/)
- * [Git](http://git.or.cz/)
- * [ZLib](http://www.zlib.net/)
- * pthread - The pthread library should be installed by your operating system
- * [gmake](http://savannah.gnu.org/projects/make/)
- * [bundler](http://bundler.io/) `[sudo] gem install bundler`
-
-
-### Apple OS X
-
-The easiest way to get a build environment on Apple OS X is to install the
-XCode Tools and Utilities. Once installed, you can enable developer mode crash
-reporting at: /Developer/Applications/Utilities/CrashReporterPrefs.app
-
-
-### Debian/Ubuntu
-
-Just run this to install required packages:
-
- $ sudo apt-get install -y build-essential bison ruby-dev rake zlib1g-dev \
- libyaml-dev libssl-dev libreadline-dev libncurses5-dev llvm llvm-dev
-
-This is tested using fresh-installed Ubuntu 12.10. There may be minor differences with older
-Ubuntu, Debian or other Debian-based distributions.
-
-### Fedora/CentOS
-
- * ruby-devel
- * readline-devel
- * zlib-devel
- * openssl-devel
-
-### FreeBSD
-
-Rubinius has a port in FreeBSD ports tree. It's called `lang/rubinius`. You
-can find information about this port on [FreshPorts](http://www.freshports.org/lang/rubinius/). Once being
-installed the port installs all the dependencies automagically.
diff --git a/doc/en/getting-started/running-rubinius.markdown b/doc/en/getting-started/running-rubinius.markdown
deleted file mode 100644
index 859bf5e..0000000
--- a/doc/en/getting-started/running-rubinius.markdown
+++ /dev/null
@@ -1,33 +0,0 @@
----
-layout: doc_en
-title: Running Rubinius
-previous: Building
-previous_url: getting-started/building
-next: Troubleshooting
-next_url: getting-started/troubleshooting
----
-
-Once you have followed the steps for building (and possibly installing)
-Rubinius, you can verify it is working:
-
- rbx -v
-
-Rubinius generally works like Ruby from the command-line. For example:
-
- rbx -e 'puts "Hello!"'
-
-To run a ruby file named 'code.rb':
-
- rbx code.rb
-
-To run IRB:
-
- rbx
-
-If you added the Rubinius bin directory to your PATH, Rubinius should perform
-just as you would expect from MRI. There are commands for `ruby`, `rake`,
-`gem`, `irb`, `ri`, and `rdoc`.
-
-You can add the Rubinius bin directory to your PATH only when you want to use
-Rubinius. This way, it will not interfere with your normally installed Ruby
-when you do not want to use Rubinius.
diff --git a/doc/en/getting-started/troubleshooting.markdown b/doc/en/getting-started/troubleshooting.markdown
deleted file mode 100644
index 017988a..0000000
--- a/doc/en/getting-started/troubleshooting.markdown
+++ /dev/null
@@ -1,83 +0,0 @@
----
-layout: doc_en
-title: Troubleshooting
-previous: Running Rubinius
-previous_url: getting-started/running-rubinius
-next: Contributing
-next_url: contributing
----
-
-The following are errors that you may encounter while building, installing, or
-running Rubinius along with suggested solutions.
-
-For any error, a first step is to ensure you have a current, clean checkout of
-Rubinius. Before going further, consider running the following steps:
-
- $ git checkout master
- $ git reset --hard
- $ git pull
- $ rake distclean
- $ rake
-
-
-### Rubinius is unable to find the `runtime` directory
-
- After building or installing, the following error occurs when attempting to
- run Rubinius:
-
- ERROR: unable to find runtime directory
-
- Rubinius was configured to find the runtime directory at:
-
- /Users/brian/devel/rubinius/runtime
-
- but that directory does not exist.
-
- Set the environment variable RBX_RUNTIME to the location
- of the directory with the compiled Rubinius kernel files.
-
- You may have configured Rubinius for a different install
- directory but you have not run 'rake install' yet.
-
-#### Solution:
-
- If you configured Rubinius with a `--prefix`, run rake install.
-
- If you configured Rubinius with a `--prefix` and renamed the install
- directory after installing Rubinius, re-configure Rubinius and reinstall it.
-
- If you renamed the source directory after building Rubinius, re-configure
- and rebuild it.
-
- In general, do not rename the build or install directory after building or
- installing Rubinius.
-
-
-### Rubinius segfaults when building on FreeBSD
-
- On FreeBSD, including up to version 8.1 stable, there is an issue with execinfo that
- causes Rubinius to segfault when it loads.
-
-#### Solution:
-
- Disable execinfo when configuring Rubinius:
-
- ./configure --without-execinfo
-
-### Fail to install rubinius with ruby-build
-
- Sometimes, you may have some trouble using
- [ruby-build](https://github.com/sstephenson/ruby-build) to install Rubinius.
-
-#### Solution
-
- Please compile Rubinius yourself (ensuring that you have the required dependencies):
-
- $ git clone https://github.com/rubinius/rubinius
- $ cd rubinius
- $ ./configure --prefix=/path/to/rubinius/location
- $ rake install
-
- You don't have to specify the `--prefix` option. Just specify it if you want to put
- Rubinius into a specific directory. The best to do is to put Rubinius into a
- directory which is in your `PATH`.
diff --git a/doc/en/guides.markdown b/doc/en/guides.markdown
deleted file mode 100644
index 7b21b91..0000000
--- a/doc/en/guides.markdown
+++ /dev/null
@@ -1,12 +0,0 @@
----
-layout: doc_en
-title: Guides
-previous: Tools - Memory Analysis
-previous_url: tools/memory-analysis
-next: How-To
-next_url: how-to
-review: true
----
-
-1. [Migrating from MRI to
- Rubinius](/doc/en/guides/migrating-from-mri-to-rubinius)
diff --git a/doc/en/guides/migrating-from-mri-to-rubinius.markdown b/doc/en/guides/migrating-from-mri-to-rubinius.markdown
deleted file mode 100644
index c085de2..0000000
--- a/doc/en/guides/migrating-from-mri-to-rubinius.markdown
+++ /dev/null
@@ -1,111 +0,0 @@
----
-layout: doc_en
-title: Guides - Migrating from MRI to Rubinius
-previous: Guides
-previous_url: guides
-next: How-To
-next_url: how-to
----
-
-This guide will assist you to migrate your Ruby or Rails application from MRI
-(Matz's Ruby Implementation) to Rubinius. This guide assumes that you are
-familiar with Ruby or Ruby or Rails, RubyGems, and Bundler. It also assumes
-that you can use the command line shell.
-
-## 1. Installing Rubinius
-
-The first step in migrating to Rubinius is to install Rubinius. Since you will
-likely need to switch back and forth between MRI and Rubinius while migrating,
-the easiest approach is to use a Ruby switcher utility.
-
-The [chruby](https://github.com/postmodern/chruby) command line tool for
-switching between Ruby implementations is recommended for use with Rubinius.
-All examples in the guides will use `chruby`.
-
-### Installing chruby and ruby-install
-
-If you are using OS X, the easiest way to install `chruby` and `ruby-install`
-is to use the [Homebrew](https://github.com/Homebrew/homebrew) package manager
-as follows:
-
- $ brew update
- $ brew install chruby ruby-install
-
-If you are not using Homebrew or are using a different operating system than OS
-X, please see the the following:
-
-1. [chruby install instructions](https://github.com/postmodern/chruby#install)
-1. [ruby-install install instructions](https://github.com/postmodern/ruby-install#install)
-
-### Enabling chruby
-
-To enable `chruby`, add the following to the ~/.bashrc or ~/.zshrc file:
-
- source /usr/local/opt/chruby/share/chruby/chruby.sh
-
-See the documentation for more [configuration
-instructions](https://github.com/postmodern/chruby#configuration).
-
-### Using ruby-install
-
-Once you have installed the `ruby-install` utility, installing Rubinius is
-straightforward:
-
- $ ruby-install rbx 2.2.6
-
-For instructions for installing other Ruby implementations, please see the
-`ruby-install` [installation
-synopsis](https://github.com/postmodern/ruby-install#synopsis).
-
-### Using chruby
-
-Now that Rubinius is installed, you can make it active with the following
-command:
-
- $ chruby rbx
-
-## 2. Gems
-
-Most gems that run on MRI should run on Rubinius, with the exceptions noted
-below. Additionally, Rubinius makes many components of the system available as
-gems. These include the Rubinius tools for parsing and compiling Ruby code, the
-Ruby debugger and profiler, and the Ruby standard library. All these gems are
-pre-installed when you install Rubinius.
-
-### C-extension Gems
-
-Many gems that use C-extensions run fine on Rubinius. The exceptions are ones
-that rely on MRI internal data structures. These gems cannot be supported on
-Rubinius and include gems like `ruby-debug` and `ruby-prof`. Rubinius provides
-its own Ruby source debugger and profiler, as well as other tools. See the
-[tools documentation](http://rubini.us/doc/en/tools/) for more details.
-
-## 3. Gemfiles
-
-Your Gemfile should work fine with Rubinius but you should run `bundle update`
-to force the gem dependencies to be recomputed for Rubinius. Also, if you are
-using gems that are incompatible with Rubinius, you can put them in a
-`platforms` block until completing the migration to Rubinius as follows:
-
- # Example platforms block for MRI-specific gems
- platforms :mri do
- gem 'ruby-prof'
- gem 'ruby-debug'
- end
-
-## 4. Compatibility Issues
-
-Rubinius created the [RubySpec](http://rubyspec.org) project, and continually
-enhances it, to describe the behavior of Ruby and monitor compatibility with
-MRI.
-
-With few exceptions, Rubinius is expected to be compatible with MRI 2.1. Some
-features, like keyword arguments, are not yet implemented. Other features may
-not be implemented because they are unknown and no RubySpecs exist for the
-feature yet. Several standard library components, including Continuation,
-Ripper, TracePoint, and Tracer, are not yet implemented but may be in the
-future.
-
-If you encounter an incompatible behavior in Rubinius compared to MRI, it's
-most likely a bug. Please
-[open an issue](https://github.com/rubinius/rubinius/issues) for it.
diff --git a/doc/en/how-to.markdown b/doc/en/how-to.markdown
deleted file mode 100644
index 3ec9ea1..0000000
--- a/doc/en/how-to.markdown
+++ /dev/null
@@ -1,18 +0,0 @@
----
-layout: doc_en
-title: How-To
-previous: Guides - Migrating from MRI to Rubinius
-previous_url: guides/migrating-from-mri-to-rubinius
-next: Write a Ticket
-next_url: how-to/write-a-ticket
-review: true
----
-
-1. [Write a Ticket](/doc/en/how-to/write-a-ticket/)
-1. [Write a Ruby Spec](/doc/en/how-to/write-a-ruby-spec/)
-1. [Fix a Failing Spec](/doc/en/how-to/fix-a-failing-spec/)
-1. [Write Benchmarks](/doc/en/how-to/write-benchmarks/)
-1. [Write a Blog Post](/doc/en/how-to/write-a-blog-post/)
-1. [Write Documentation](/doc/en/how-to/write-documentation/)
-1. [Translate Documentation](/doc/en/how-to/translate-documentation/)
-1. [Commit to Github](/doc/en/how-to/commit-to-github/)
diff --git a/doc/en/how-to/commit-to-github.markdown b/doc/en/how-to/commit-to-github.markdown
deleted file mode 100644
index 55c5317..0000000
--- a/doc/en/how-to/commit-to-github.markdown
+++ /dev/null
@@ -1,53 +0,0 @@
----
-layout: doc_en
-title: How-To - Commit Changes to Github
-previous: Translate Documentation
-previous_url: how-to/translate-documentation
-next: Appendix A - Glossary
-next_url: appendix-a-glossary
----
-
-The Rubinius Project does a majority of its work on the master
-branch. The goal is to keep master "clean" so that it always builds
-a working binary and provides a snapshot of the latest fixes
-and enhancements.
-
-### Committers With Read/Write Access to Rubinius Repository
-
-We recommend that committers who have read/write access to the
-repository do their work on a branch in their local repository.
-As the changes stabilize, they should be committed in two steps.
-The first step should commit the spec that highlights the
-behavior under construction while the second commit adds the
-behavior and allows the spec to pass.
-
-After committing to the local repository's branch, the commit
-should be merged back to master and pushed to github. To avoid
-superfluous git merge messages, we ask that the committer first
-rebase the master branch prior to the merge.
-
-1. git branch name-of-fix-branch
-2. git checkout name-of-fix-branch
-3.
-4.
-5. git add
-6. git commit
-7. git add
-8. git commit
-9. git checkout master
-10. git pull --rebase
-11. git checkout name-of-fix-branch
-12. git rebase master
-13. git checkout master
-14. git merge name-of-fix-branch
-15. git push origin master
-
-Steps 9 through 15 can be automated via a script to save on all
-of that typing.
-
-### Committers With Read-only Access to Rubinius Repository
-
-Please read:
-
- * [How-To Write a Ticket](/doc/en/how-to/write-a-ticket)
-
diff --git a/doc/en/how-to/fix-a-failing-spec.markdown b/doc/en/how-to/fix-a-failing-spec.markdown
deleted file mode 100644
index 691a2ac..0000000
--- a/doc/en/how-to/fix-a-failing-spec.markdown
+++ /dev/null
@@ -1,42 +0,0 @@
----
-layout: doc_en
-title: How-To - Fix a Failing Spec
-previous: Write a Ruby Spec
-previous_url: how-to/write-a-ruby-spec
-next: Write Benchmarks
-next_url: how-to/write-benchmarks
----
-
-Make sure you have read:
-
- * [Getting Started](/doc/en/getting-started/)
- * [Specs](/doc/en/specs/)
-
-Then, follow these steps to fix a failing spec:
-
- 1. Fork the [Rubinius project on GitHub](https://github.com/rubinius/rubinius).
- 2. Clone your fork locally and run `git checkout -b branch_name` to create a new branch (where branch_name is
- a brief description for the problem you are fixing.
- 3. Run `rake` to ensure that all CI specs are passing.
- 4. Run `bin/mspec spec/some/spec_file.rb` to confirm the spec fails.
- 5. Edit a file somewhere in Rubinius (probably under the kernel directory).
- 6. Run `rake build` to build your change.
- 7. Run `bin/mspec spec/some/spec_file.rb` to see if your change makes the
- spec pass.
- Add a "-txVERSION" argument at the end if you'd want to tackle Ruby VERSION.
- For example: "-tx19" for Ruby 1.9.
- 8. Repeat until your spec passes.
- 9. Run `rake` to ensure there are no regressions.
- 10. Change directory to Rubinius root if not already there.
- 11. Run `git status, git add, git commit`, etc. Any changes made to the spec
- files under the spec/ruby directory must be in a different commit from
- changes made to other Rubinius source code files.
- 12. Push your new branch to Github.
- 13. Issue a Pull Request.
- To do this, go to your fork on GitHub, change to your new branch and click "Pull Request".
- Next, write a description of your change if required and click "Send pull request".
- 14. More commits and discussion may happen with other contributors using
- the Pull Request interface.
-
-When your pull request is accepted by the Rubinius project, you'll get a commit bit
-for the Rubinius repository. Let Evan, Brian or Dirkjan know what your Github username is.
diff --git a/doc/en/how-to/translate-documentation.markdown b/doc/en/how-to/translate-documentation.markdown
deleted file mode 100644
index cb4f146..0000000
--- a/doc/en/how-to/translate-documentation.markdown
+++ /dev/null
@@ -1,113 +0,0 @@
----
-layout: doc_en
-title: How-To - Translate Documentation
-previous: Write Documentation
-previous_url: how-to/write-documentation
-next: Commit to Github
-next_url: how-to/commit-to-github
----
-
-There are two translation tasks:
-
-1. updating an existing translation
-1. creating a completely new translation
-
-Begin by reading [How-To - Write
-Documentation](/doc/en/how-to/write-documentation/)
-
-
-### Updating an Existing Translation
-
-To update an existing translation, open the topic file under `web/doc/LANG`
-and edit the existing text or add newly translated text.
-
-
-### Creating a New Translation
-
-To create a new language translation:
-
-1. Copy `web/doc/en` to `web/doc/LANG` where _LANG_ is the
- [ISO-639-1](http://en.wikipedia.org/wiki/List_of_ISO_639-2_codes) code for
- the language translation you are creating.
-1. Edit the links in the Table of Contents to point to the location of the
- files for the translation. (Note that for some reason the `page.base_dir`
- attribute is not available when these files are being rendered by Jekyll.
- This needs to be investigated.)
-1. Translate the English text to the target language.
-1. Add a corresponding value to `languages` attribute in YAML front-matter of
- `web/_layouts/doc.html`.
-1. Add a corresponding value to `TRANS` array in `rakelib/web.rake`(see below).
-
-### Translator's Tool
-
-We've made some tiny tools to aid translators. Technically, there's only one
-such tool yet. It's **Translator Consistency Checker**.
-
-#### Short Synopsis
-
- $ cd rubinius
- $ rake -T
-
- ...
-
- rake web:translations:check # Check web documentation translations for existence and mtime consistency.
-
- $ rake web:translations:check
- (in /usr/home/paul/develop/ruby/rubinius)
-
- TRANSLATION CHECK: Checking 'web/doc/en' recursively against ["de", "es", "fr", "ja", "pl", "pt-br", "ru"] versions
-
- NB:
-
- LOST IN TRANSLATION:
- web/doc/en/how-to/write-benchmarks.markdown: doesn't exist in 'ru' edition
- web/doc/en/bytecode-compiler/customization.markdown: doesn't exist in 'ru' edition
- web/doc/en/bytecode-compiler/encoder.markdown: doesn't exist in 'ru' edition
- web/doc/en/bytecode-compiler/packager.markdown: doesn't exist in 'ru' edition
- web/doc/en/bytecode-compiler/writer.markdown: doesn't exist in 'ru' edition
-
-
- LAG IN TRANSLATION:
- web/doc/en/garbage-collector/large-objects.markdown: is younger than its 'pl' version
- web/doc/en/garbage-collector/mature-generation.markdown: is younger than its 'ru' version
- web/doc/en/garbage-collector/nursery.markdown: is younger than its 'ru' version
- web/doc/en/garbage-collector/young-generation.markdown: is younger than its 'ru' version
- web/doc/en/systems/concurrency.markdown: is younger than its 'pl' version
- web/doc/en/ruby/instance-variables.markdown: is younger than its 'ru' version
- web/doc/en/bytecode-compiler/ast.markdown: is younger than its 'ru' version
- web/doc/en/bytecode-compiler/parser.markdown: is younger than its 'pl' version
- web/doc/en/garbage-collector.markdown: is younger than its 'ru' version
-
-#### Explanation
-
-`web:translations:check` rake task recursively checks "Leader" docs version (which is
-now `web/doc/en` subtree) against the list of translated "followers". Both
-leader and translations list are defined in `rakelib/web.rake`:
-
- # This is the 'leader' version: all is translated from here.
- LEADER = "web/doc/en"
-
- # Here we MANUALLY list all official doc translations
- TRANS = [
- 'de',
- 'es',
- 'fr',
- 'ja',
- 'pl',
- 'pt-br',
- 'ru'
- ]
-
-For each Leader file the script checks whether the corresponding translation
-file exist and has `mtime` younger (less) than the Leader's. If translation is
-older than the original Leader file or doesn't exist you'll see that very nice
-annoying message as shown in the example. If all files are OK you'll see and recognize
-that.
-
-#### Conclusion
-
-This mega duper tiny stupid tool was written to help the translator to
-understand which files might obviously need alteration. No more. There's no
-intellectual analysis like translation validity check, etc. --- at all. If you
-are the smartest Rubinius contributor ever you are welcome to expand this tool
-thus helping the society and saving the world!
diff --git a/doc/en/how-to/write-a-blog-post.markdown b/doc/en/how-to/write-a-blog-post.markdown
deleted file mode 100644
index f2a0466..0000000
--- a/doc/en/how-to/write-a-blog-post.markdown
+++ /dev/null
@@ -1,55 +0,0 @@
----
-layout: doc_en
-title: How-To - Write a Blog Post
-previous: Write Benchmarks
-previous_url: how-to/write-benchmarks
-next: Write Documentation
-next_url: how-to/write-documentation
----
-
-The [Rubinius blog][1] uses [Jekyll][2] and is integrated with the website and
-documentation. We encourage and appreciate guest blog posts about your
-experiences using or developing Rubinius.
-
-The preferred format for blog posts is Markdown. However, if you have special
-formatting needs, the post can be written in HTML directly.
-
-Clone Rubinius repository as that is where the website and posts are stored.
-
- git clone https://github.com/rubinius/rubinius.git
-
-To get started, ensure you have the `kramdown` and `jekyll` gems installed.
-
- rbx gem install jekyll kramdown
-
-Now go to the posts directory
-
- cd rubinius/web/_posts
-
-Create a file in the console using the filename format `YYYY-MM-DD-perma-link.markdown`.
-
- touch "%(date +"%Y-%m-%d")-perma-link-title.markdown"
-
-Write your brilliant post.
-
- cat /dev/random > <> # :-p
-
-Run jekyll to compile the website, including your post.
-
- cd ../web/
- rbx -S jekyll build
-
-Create a commit of all the changes in the `web/` directory.
-
- cd ../
- git add web/
- git commit -m "Wrote a blog post on ....."
-
-Submit a patch, pull request, or if you have commit rights, push the commit to
-the master branch.
-
-Tell us that there is a new blog post. We may have some feedback for you before
-publishing.
-
-[1]: /blog "Rubinius' Blog"
-[2]: https://github.com/mojombo/jekyll "Mojombo's Jekyll"
diff --git a/doc/en/how-to/write-a-ruby-spec.markdown b/doc/en/how-to/write-a-ruby-spec.markdown
deleted file mode 100644
index c789599..0000000
--- a/doc/en/how-to/write-a-ruby-spec.markdown
+++ /dev/null
@@ -1,24 +0,0 @@
----
-layout: doc_en
-title: How-To - Write a Ruby Spec
-previous: Write a Ticket
-previous_url: how-to/write-a-ticket
-next: Fix a Failing Spec
-next_url: how-to/fix-a-failing-spec
----
-
-Make sure you have read:
-
- * [Getting Started](/doc/en/getting-started/)
- * [Specs](/doc/en/specs/)
-
-Then, follow these steps to write a spec for a Ruby method:
-
- 1. Edit a file under `spec/ruby/...`
- 2. Run `bin/mspec -tr spec/ruby/some/spec_file.rb`
- 3. Repeat until the spec passes on MatzRuby
- 4. Commit your changes
- 5. Open a pull request.
- If you are also implemented the method, feel free to do that
- together in a single pull request but make sure you have separate
- commits for the specs and code.
diff --git a/doc/en/how-to/write-a-ticket.markdown b/doc/en/how-to/write-a-ticket.markdown
deleted file mode 100644
index dfded18..0000000
--- a/doc/en/how-to/write-a-ticket.markdown
+++ /dev/null
@@ -1,114 +0,0 @@
----
-layout: doc_en
-title: How-To - Write a Ticket
-previous: How-To
-previous_url: how-to
-next: Write a Ruby Spec
-next_url: how-to/write-a-ruby-spec
----
-
-The Rubinius issue tracker is .
-
-To be useful, tickets must be concise, focused, and actionable. If not, the
-ticket will languish and become clutter. Accordingly, tickets must fall into
-one (or more) of the following categories:
-
- 1. A precise command line history showing how to install and invoke the
- program and showing the backtrace for an exception.
- 2. A short piece of code illustrating the problem and the command line to
- invoke it.
- 3. A pull request, **including specs if they do not already exist**, and showing
- the spec runs before and after applying the pull request.
-
-If your issue doesn't fit into one of the categories, it is not invalid. It is
-simply not appropriate for a ticket.
-
- 1. If it is a feature, consider discussing it on the mailing list. Also, you
- could take a crack at implementing it and demonstrate how your feature is
- useful.
- 2. If it is a library or gem that is not working, take some time to dig in
- and see if you can create a reproduction for an issue and post that as a
- ticket.
-
-
-## General procedure for submitting a ticket
-
- 1. Double-check.
-
- 1. Do a full rebuild ('rake clean; rake') after a 'git pull' or fresh clone.
- 2. Read [Troubleshooting](/doc/en/getting-started/troubleshooting)
- to see if something there resolves the issue.
- 3. Read [Specs](/doc/en/specs/).
-
- 2. Give your ticket a specific, preferably short title.
-
- 3. Give your ticket appropriate tags.
-
- 4. Give enough detail about the issue.
-
- * The command line for invoking the program
- * The backtrace or result from the program versus expected result.
- * Your machine information. `uname -a` is usually good (if there are any
- "unknown" fields in it, please elaborate on those.)
-
-
-## Additional instructions for pull requests
-
- * Can be just a set of specs.
- * Pull requests must be accompanied by specs unless the specs already exist.
- * Relevant part of spec output and the exact 'bin/mspec' invocation from the
- existing or added spec *before the fix*.
- * The spec output and the exact 'bin/mspec' invocation showing success
- *after* the fix.
- * Additional description of your pull request and how it fixes the problem. In
- particular with new functionality please indicate if it was already
- discussed on #rubinius or ruby-dev.
-
-Unless for some reason impossible, please use a pull request to create the
-patchset. It is the easiest way for us to review and apply the changes.
-If opening a pull request is impossible, please use git-format-patch and
-add a link to it using gist.github.com, pastie.org or a similar service.
-
-
-## Example of submitting a pull request
-
-Suppose the following spec exists and is failing:
-
- describe "Kernel.format" do
- it "is accessible as a module function" do
- Kernel.format("%s", "hello").should == "hello"
- end
- end
-
-1. Ticket Title:
-
- "[PATCH] No method 'format' on Kernel (Module)"
-
-2. Tags:
-
- "patch core spec"
-
-3. Ticket Message:
-
- The method 'format' is not available as a module function of Kernel.
-
- $ bin/mspec spec/ruby/core/kernel/format_spec.rb
- Started
- .E
-
- 1)
- Kernel.format is accessible as a module function ERROR
- No method 'format' on Kernel (Module):
-
- The method 'format' already exists but has not been set as a module
- function. This pull request does so.
-
- After the pull request is applied:
-
- $ bin/mspec spec/ruby/core/kernel/format_spec.rb
- Started
- ..
-
- Finished in 0.016031 seconds
-
- 2 examples, 2 expectations, 0 failures, 0 errors
diff --git a/doc/en/how-to/write-benchmarks.markdown b/doc/en/how-to/write-benchmarks.markdown
deleted file mode 100644
index b0416a3..0000000
--- a/doc/en/how-to/write-benchmarks.markdown
+++ /dev/null
@@ -1,30 +0,0 @@
----
-layout: doc_en
-title: How-To - Write Benchmarks
-previous: Fix a Failing Spec
-previous_url: how-to/fix-a-failing-spec
-next: Write a Blog Post
-next_url: how-to/write-a-blog-post
----
-
-Why benchmarks?
-
-Benchmarks are a great tool for comparing Rubinius with the rest of the Ruby
-runtimes, i.e. MRI, JRuby, IronRuby and other implementations. It is not so
-much intended to measure Rubinius itself so if you want to contribute writing
-benchmarks make sure to follow these steps:
-
- 1. Find existing benchmarks in rubinius/benchmarks and study their layout.
- 3. Each benchmark file should measure one specific aspect of Ruby. For
- example different ways of deleting keys/values from a Hash.
- 4. Use the benchmark framework.
- 5. Keep the benchmarks short and simple.
- 6. The benchmarks are not meant to measure Rubinius. So if you're writing a
- benchmark for a class with bang and no-bang methods you will want to use
- a duplicate of a variable in the bang method but you don't need to dup
- in the no-bang method.
-
-If you want to test a benchmark you can run it file or even directory wise:
-
- bin/benchmark benchmark/core/string/bench_case.rb
- bin/benchmark benchmark/core
diff --git a/doc/en/how-to/write-documentation.markdown b/doc/en/how-to/write-documentation.markdown
deleted file mode 100644
index 99d3a3c..0000000
--- a/doc/en/how-to/write-documentation.markdown
+++ /dev/null
@@ -1,98 +0,0 @@
----
-layout: doc_en
-title: How-To - Write Documentation
-previous: Write a Blog Post
-previous_url: how-to/write-a-blog-post
-next: Translate Documentation
-next_url: how-to/translate-documentation
----
-
-The Rubinius documentation is integrated with the website and blog. It uses
-Jekyll just like the other components.
-
-To get started, ensure you have the `kramdown` and `jekyll` gems installed.
-
- rbx gem install jekyll kramdown
-
-The documentation source is under the `web/doc` directory. There are
-subdirectories for each language to which the documentation has been
-translated (eg `en`, `es`, etc.).
-
-There is a Table of Contents for each translation (e.g.
-`/web/doc/en/index.markdown`). The rest of the documentation consists of
-single files that have YAML attributes to specify how the documents are
-connected. Essentially, the documentation can be viewed as a doubly-linked
-list of documents with each document pointing to the previous and next
-document. The Table of Contents document shows the complete structure.
-
-The YAML attributes in a document look like the following:
-
- ---
- layout: doc_en
- title: How-To - Write Documentation
- previous: Write a Blog Post
- previous_url: how-to/write-a-blog-post
- next: Translate Documentation
- next_url: how-to/translate-documentation
- ---
-
-The _layout_ specifies which Jekyll layout to use when formatting the
-document. The _layout_ should be `doc_LANG`, where _LANG_ is the ISO-639-2
-code for the language.
-
-The _title_ specifies the document title that is displayed at the top of the
-page.
-
-The _previous_ and _previous\_url_ attributes give the title and link to the
-previous document. Likewise, the _next_ and _next\_url_ attributes give the
-title and link for the next document. These are used to enhance browsing the
-documentation and limiting the amount of work necessary to re-order parts of
-the documentation.
-
-Both the source for the documentation and the files generated by Jekyll are
-committed to the Rubinius repository. When people clone the source repository,
-they can run `rake docs` to view the documentation before they have built
-Rubinius or if having problems building Rubinius.
-
-
-### Editing Existing Documentation
-
-An initial outline for the documentation has been created. There are many
-topics that merely need to have documentation written for them.
-
-To add documentation for an existing topic or to fix existing documentation:
-
-1. Open the file for the topic under `web/doc/LANG`.
-1. Add or improve the documentation.
-1. To view your updates while you are working on them, run
- `rbx -S jekyll serve --watch` in the `web/` directory.
-1. Once finished adding or editing documentation, commit your changes to the
- source files.
-1. Run `rbx -S jekyll build` in the `web/` directory to force update of all
- generated files in `web/_site`.
-1. Commit the generated files. If making a small change, the generated files
- can be committed with the documentation source files. If making many
- changes, commit the generated files separately to make reviewing changes
- more simple.
-
-
-### Adding New Documentation
-
-To add documentation for which no existing topic exists:
-
-1. Create a new file with the .markdown extension under `web/doc/LANG`.
-1. Set up the attributes to link the new file into the existing files. This
- will require editing the _previous_ and _next_ attributes of the existing
- files to insert the new file, as well as adding an entry to
- `index.markdown`.
-1. To view your updates while you are working on them, run
- `rbx -S jekyll serve --watch`
-1. Edit the new file using Markdown syntax.
-1. Once finished adding or editing documentation, commit your changes to the
- source files.
-1. Run `rbx -S jekyll build` in the `web/` directory to force update of all
- generated files in `web/_site`.
-1. Commit the generated files. If making a small change, the generated files
- can be committed with the documentation source files. If making many
- changes, commit the generated files separately to make reviewing changes
- more simple.
diff --git a/doc/en/index-of-terms.markdown b/doc/en/index-of-terms.markdown
deleted file mode 100644
index 43cfc86..0000000
--- a/doc/en/index-of-terms.markdown
+++ /dev/null
@@ -1,8 +0,0 @@
----
-layout: doc_en
-title: Index of Terms
-previous: Appendix B - Reading List
-previous_url: appendix-b-reading-list
-next_url: frequently-asked-questions
-review: true
----
diff --git a/doc/en/index.markdown b/doc/en/index.markdown
deleted file mode 100644
index 3d139d8..0000000
--- a/doc/en/index.markdown
+++ /dev/null
@@ -1,74 +0,0 @@
----
-layout: doc_en
-title: Table of Contents
-toc: true
-next: What is Rubinius?
-next_url: what-is-rubinius
----
-
-1. [What is Rubinius?](/doc/en/what-is-rubinius/)
-1. [Getting Started](/doc/en/getting-started/)
- 1. [Requirements](/doc/en/getting-started/requirements/)
- 1. [Building](/doc/en/getting-started/building/)
- 1. [Running Rubinius](/doc/en/getting-started/running-rubinius/)
- 1. [Troubleshooting](/doc/en/getting-started/troubleshooting/)
-1. [Contributing](/doc/en/contributing/)
- 1. [Communication](/doc/en/contributing/communication/)
- 1. [Style Guide](/doc/en/contributing/style-guide)
-1. [Ruby](/doc/en/ruby/)
- 1. [Scripts](/doc/en/ruby/scripts/)
- 1. [Methods](/doc/en/ruby/methods/)
- 1. [Constants](/doc/en/ruby/constants/)
- 1. [Classes & Modules](/doc/en/ruby/classes-and-modules/)
- 1. [Blocks & Procs](/doc/en/ruby/blocks-and-procs/)
- 1. [Local Variables](/doc/en/ruby/local-variables/)
- 1. [Instance Variables](/doc/en/ruby/instance-variables/)
- 1. [Class Variables](/doc/en/ruby/class-variables/)
- 1. [Global Variables](/doc/en/ruby/global-variables/)
-1. [Specs](/doc/en/specs/)
- 1. [RubySpec](/doc/en/specs/rubyspec/)
- 1. [Compiler Specs](/doc/en/specs/compiler/)
-1. [Build System](/doc/en/build-system/)
-1. [Bootstrapping](/doc/en/bootstrapping/)
-1. [Virtual Machine](/doc/en/virtual-machine/)
- 1. [Instructions](/doc/en/virtual-machine/instructions/)
- 1. [Custom Dispatch Logic](/doc/en/virtual-machine/custom-dispatch-logic/)
-1. [Bytecode Compiler](/doc/en/bytecode-compiler/)
- 1. [Parser Stage](/doc/en/bytecode-compiler/parser/)
- 1. [AST](/doc/en/bytecode-compiler/ast/)
- 1. [Generator Stage](/doc/en/bytecode-compiler/generator/)
- 1. [Encoder Stage](/doc/en/bytecode-compiler/encoder/)
- 1. [Packager Stage](/doc/en/bytecode-compiler/packager/)
- 1. [Writer Stage](/doc/en/bytecode-compiler/writer/)
- 1. Printers
- 1. [Transformations](/doc/en/bytecode-compiler/transformations/)
- 1. [Customizing the Pipeline](/doc/en/bytecode-compiler/customization/)
-1. [JIT Compiler](/doc/en/jit/)
-1. [Memory system](/doc/en/memory-system/)
- 1. [Object layout](/doc/en/memory-system/object-layout/)
- 1. [Garbage collector](/doc/en/memory-system/garbage-collector/)
-1. [Rubinius Systems](/doc/en/systems/)
- 1. [Primitives](/doc/en/systems/primitives/)
- 1. [FFI](/doc/en/systems/ffi/)
- 1. [Concurrency](/doc/en/systems/concurrency/)
- 1. [IO](/doc/en/systems/io/)
- 1. [C-API](/doc/en/systems/c-api/)
-1. [Tools](/doc/en/tools/)
- 1. [Debugger](/doc/en/tools/debugger/)
- 1. [Profiler](/doc/en/tools/profiler/)
- 1. [Memory Analysis](/doc/en/tools/memory-analysis/)
-1. [Guides](/doc/en/guides/)
- 1. [Migrating from MRI to Rubinius](/doc/en/guides/migrating-from-mri-to-rubinius/)
-1. [How-To](/doc/en/how-to/)
- 1. [Write a Ticket](/doc/en/how-to/write-a-ticket/)
- 1. [Write a Ruby Spec](/doc/en/how-to/write-a-ruby-spec/)
- 1. [Fix a Failing Spec](/doc/en/how-to/fix-a-failing-spec/)
- 1. [Write Benchmarks](/doc/en/how-to/write-benchmarks/)
- 1. [Write a Blog Post](/doc/en/how-to/write-a-blog-post/)
- 1. [Write Documentation](/doc/en/how-to/write-documentation/)
- 1. [Translate Documentation](/doc/en/how-to/translate-documentation/)
- 1. [Commit to Github](/doc/en/how-to/commit-to-github/)
-1. [Appendix A - Glossary](/doc/en/appendix-a-glossary/)
-1. [Appendix B - Reading List](/doc/en/appendix-b-reading-list/)
-1. [Index of Terms](/doc/en/index-of-terms/)
-1. [Frequently Asked Questions](/doc/en/frequently-asked-questions/)
diff --git a/doc/en/jit.markdown b/doc/en/jit.markdown
deleted file mode 100644
index 02021d8..0000000
--- a/doc/en/jit.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_en
-title: JIT Compiler
-previous: Bytecode Compiler - Customizing the Pipeline
-previous_url: bytecode-compiler/customization
-next: Memory System
-next_url: memory-system
-review: true
----
diff --git a/doc/en/memory-system.markdown b/doc/en/memory-system.markdown
deleted file mode 100644
index ff3b81d..0000000
--- a/doc/en/memory-system.markdown
+++ /dev/null
@@ -1,28 +0,0 @@
----
-layout: doc_en
-title: Memory system
-previous: JIT Compiler
-previous_url: jit
-next: Object layout
-next_url: memory-system/object-layout
-review: true
----
-
-## Introduction
-
-In this section the memory system of the Rubinius virtual machine is
-described. The first chapter explains how objects are layed out in
-memory. The concept of immediates or tagged pointers will be explained,
-as well as how we work with types the virtual machine is aware of.
-Another important thing to know is how we create compact object so we
-use the memory in your system more efficiently.
-
-The second chapter involves the garbage collector and how we use a
-[Generational Garbage Collector (GC)](http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Generational_GC_.28ephemeral_GC.29)
-to clean up after the waste your application generates. It will also
-explain how we ensure that concurrent allocation of objects performs
-well and how you have to consider the implications of a moving garbage
-collector when working with the virtual machine code.
-
-1. [Object layout](/doc/en/memory-system/object-layout/)
-1. [Garbage collector](/doc/en/memory-system/garbage-collector/)
diff --git a/doc/en/memory-system/garbage-collector.markdown b/doc/en/memory-system/garbage-collector.markdown
deleted file mode 100644
index f4301a7..0000000
--- a/doc/en/memory-system/garbage-collector.markdown
+++ /dev/null
@@ -1,69 +0,0 @@
----
-layout: doc_en
-title: Garbage Collector
-previous: Object layout
-previous_url: memory-system/object-layout
-next: Rubinius Systems
-next_url: systems
-review: true
----
-
-## Introduction
-
-Rubinius implements a [Generational Garbage Collector (GC)][gc].
-The Rubinius Generational GC manages the dynamic allocation and deallocation in
-the heap space of a running Rubinius process.
-
-## Nursery
-
-The first generation in Rubinius' generational GC is the nursery.
-An object's lifecycle begins in the nursery where it is created (allocated).
-
-Objects live in the nursery until the very next collection. If an object
-is still alive after one GC cycle then it is moved to the Young generation.
-A run of the GC handles moving objects out of the Nursery automatically.
-
-## Young generation
-
-Objects that have been alive for more than one GC cycle live in the Young
-generation space. A run of the GC handles moving objects into the Young
-generation space automatically.
-
-Objects live in the young generation space for X number of collections.
-X is dynamically adjusted based on how many objects are being promoted.
-
-If *too many* objects are promoted during a given GC cycle, then X goes up.
-If *not enough* objects are promoted during a given GC cycle, then X goes down.
-
-This is done in order to keep the rate of promotion stable.
-*stable* in this context means a low rate of change in object promotion.
-
-## Mature generation
-
-Mature objects are objects that have been promoted from the Young
-generation after living past the promotion threshold 'X'.
-
-Autotune is the mechanism that is used to dynamic adjust the GC cycles before
-mature collection occurs. This can be turned off or a static number may be used
-via gc.lifetime. gc.lifetime is used by autotune which sets the initial value.
-
-For more information on configuration variables available read the
-[vm configuration source file ](https://github.com/rubinius/rubinius/blob/master/vm/configuration.hpp)
-
-## Large objects
-
-Large objects are born in a birthing tank rather than in the nursery.
-
-Any object that exceeds the defined byte size for a large object upon
-allocation is allocated directly into the large objects space. This is done to
-avoid copying since copying large objects is an expensive operation.
-
-Note that you can tune the number of bytes that constitute a *large
-object* which by default is 2700 (such a good baud rate eh?) bytes.
-
- rbx ... -Xgc.large_object= ...
-
-For more information on configuration variables available read the
-[vm configuration source file ](https://github.com/rubinius/rubinius/blob/master/vm/configuration.hpp)
-
-[gc]: http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Generational_GC_.28ephemeral_GC.29
diff --git a/doc/en/memory-system/object-layout.markdown b/doc/en/memory-system/object-layout.markdown
deleted file mode 100644
index afadde1..0000000
--- a/doc/en/memory-system/object-layout.markdown
+++ /dev/null
@@ -1,347 +0,0 @@
----
-layout: doc_en
-title: Memory system
-previous: Memory system
-previous_url: memory-system
-next: Garbage collector
-next_url: memory-system/garbage-collector
----
-
-## Introduction
-
-The virtual machines knows about various types of objects. These objects
-can be divided into different categories where each has its specific
-properties. The first category is the so-called immediates, also known
-as tagged pointers. This is a very efficient way of storing things like
-smaller numbers and symbols.
-
-Of course there are also the object types that the virtual machine knows
-about and the general objects the virtual machine handles. They share
-some generic properties, but also have their own characteristics such as
-how they are layed out in memory and optimized.
-
-## Immediates
-
-This is the most simple and memory efficient type of objects, using only
-a single word sized piece of memory. They are also known as tagged
-pointers, because they use a simple trick that takes advantage of the
-fact that pointers to Ruby objects in virtual machine are always aligned
-and therefore not every possible word sized value is a valid pointer.
-
-On for example a 32 bit system pointers are 32 bit aligned, so that means
-that for example `0x1` can never be a valid pointer. This means that we
-can use these address values for other purposes. The same of course is
-also valid for 64 bit systems where pointers are aligned too.
-
-We use the available space for a few different types, namely the
-following ones:
-
-1. __Fixnum__: We represent Fixnums with an immediate, where we use the tag
- `0x1`. This means that for example the value `1` is stored in memory as
- `0x3`. This means that operations on Fixnums have to remove the tag,
- run the operation and re-tag the resulting value. This is however
- much more efficient that to have to allocate memory for each `Fixnum` used.
-
-1. __Symbol__: Symbols are represented by an immediate too and use the tag
- `0x6`. A separate symbol table stores the map from these immediate
- values to the corresponding string representation of the `Symbol`.
-
-1. __True__, __False__, __Nil__ and __Undef__: These special literals are also
- presented this way. The bit patterns for these values are as follows:
-
- 0x0a:false 1010
- 0x1a:nil 11010
- 0x12:true 10010
- 0x22:undef 100010
-
- Undef is actually something only used in the Rubinius kernel in order
- to distinguish between having an optional argument provided or not,
- since using `nil` in that case would not allow for properly recognizing
- the case where `nil` is actually passed in. You might also see that the
- bit pattern for `false` and `nil` end in the same bits, this way we can just
- check that patter for a Ruby `false` match.
-
-The use of these immediates means that we don't have to allocate any
-memory for these types of objects. It also means that each instance of
-for example the `Fixnum` value `1` is indistinguishable from other ones.
-
-## Objects that really need memory
-
-Besides immediates, we of course also have real objects that need memory
-to be stored. Just writing your code with Fixnums and Symbols would get
-quite tedious very fast.
-
-Rubinius has a generic layout that applies to each of these actual
-objects. The essence of this layout is as follows:
-
- +-------------------+
- | HeaderWord header |
- | Class* klass_ |
- | Object* ivars_ |
- +-------------------+
-
-The `klass_` pointer points to the `Class` this object is an instance of. The
-`ivars_` pointer points at a table that contains the instance variables
-for this object. This is however not always used for all instance
-variables, which can be read about in the section on [Packed object
-layout].
-
-This leaves us with the meaning of the first part, the `HeaderWord`. This
-contains a 32 bit integer which consists of a number of flags and basic
-properties about this object. It also has 32 bit of auxiliary data which
-contains information depending on the meaning stored in the flags.
-
-This is the order of the flags on a little endian architecture such as
-x86. On big endian systems this order is reversed, which is necessary
-since we use the meaning bits to mark if we have an inflated header or
-not. What exactly an inflated header is, can be read in [the section on
-inflated headers].
-
-The first part shows the type and name of the flag, the last column is
-the number of bits of the total flags header used for this flag.
-
-{% highlight cpp %}
-unsigned int inflated : 1;
-unsigned int meaning : 2;
-object_type obj_type : 8;
-gc_zone zone : 2;
-unsigned int age : 4;
-
-unsigned int Forwarded : 1;
-unsigned int Remember : 1;
-unsigned int Marked : 2;
-
-unsigned int InImmix : 1;
-unsigned int Pinned : 1;
-
-unsigned int Frozen : 1;
-unsigned int Tainted : 1;
-unsigned int Untrusted : 1;
-unsigned int LockContended : 1;
-unsigned int unused : 5;
-{% endhighlight %}
-
-#### inflated
-
-This header might actually not be a normal header but a pointer to an
-inflated header. This bit is `1` when this is the case. It means that this
-`1` bit should be masked and the header then be treated as a pointer to an
-`InflatedHeader`.
-
-InflatedHeaders are used when the regular header doesn't provide enough
-room, such as the case when this object is used as a full mutex in
-multiple threads.
-
-#### meaning
-
-The header might actually not be a regular header. There are 4 different
-meanings defined:
-
-1. __eAuxWordEmpty__: This is the default value and means that there's
- nothing special with this header.
-1. __eAuxWordObjID__: This value means an object id was stored inside this
- header.
-1. __eAuxWordLock__: This object is optimistically locked to a specific
- running thread. The auxiliary 32 bit of data contain the thread id
- that this object is locked for.
-1. __eAuxWordHandle__: The `aux_word` contains an index to a C-API handle.
- This happens when this object is used in a C extension and needs a
- non moving handle to support MRI's C-API semantics.
-
-#### obj\_type
-
-This flag contains the object type and indicates the layout of this
-object in memory. These types match the C++ types we have for the
-objects in the virtual machine. This allows us using C++ templates
-such as these for type safe operations:
-
-{% highlight cpp %}
-ByteArray ba = as(obj);
-{% endhighlight %}
-
-In this case it validates that the given object is actually of the
-correct `obj_type` and can throw an exception that bubbles back into Ruby
-land so we don't crash the virtual machine but just get an exception.
-
-#### zone
-
-This flag indicates in which garbage collection zone these objects are
-located. The value is one of the following:
-
-1. __UnspecifiedZone__: Not yet in a zone. This only happens when we just
- allocated the object and haven't set the value. When debugging,
- normally you would never see this value.
-1. __LargeObjectZone__: The object is a large object and therefore allocated
- in the large object zone.
-1. __MatureObjectZone__: Object is mature, which means it was either
- allocated here or promoted to here from the young generation.
-1. __YoungObjectZone__: Object is (almost) brand new and still young.
-
-#### age
-
-This is the age of the object. This tracks the number of young garbage
-collection cycles that this object has survived. After a given number of
-cycles the object is promoted to the mature generation.
-
-#### Forwarded
-
-Whether this is a forwarded object. Object forwarding is used when the
-garbage collector has moved an object so other objects can updated their
-references to it.
-
-#### Remember
-
-Set when we need to remember this object in the remember set of the
-write barrier. For documentation on the write barrier, please see
-[section on write barrier].
-
-#### Marked
-
-Mark used when garbage collecting. A rotating mark is used here, so
-possible values are `0` for no mark or `1` or `2` depending on the rotation.
-
-#### InImmix
-
-Flag for whether this object is in the Immix space or not.
-
-#### Pinned
-
-A pinned object is not moved by the garbage collector. This is for
-example used when reading data with the read system call which can block
-and allows the garbage collector to run in the meanwhile. In this case
-the buffer used to store the read data can't be moved.
-
-#### Frozen
-
-This represents the freezing concept also know in Ruby. This flag is set
-when an object is frozen.
-
-#### Tainted
-
-Representation of the tainting of objects also available in Ruby.
-
-#### Untrusted
-
-Representation of the trust status of objects also available in Ruby.
-
-#### LockContended
-
-Flag used for marking whether threads are contending for locking this
-object. When this happens, the object is inflated and the actual mutex
-is stored in the inflated header.
-
-## Virtual machine object types
-
-The virtual machine knows about a number of object types in order to be
-able to work with them. These objects also have a corresponding C++ class
-that mimics the Ruby class and makes using them in C++ very easy and almost
-transparent. As can be read in the previous section the `obj_type` flag
-indicates this type.
-
-These objects are also C++ objects and inherit from the C++ type `Object`
-which in its turn inherits from `ObjectHeader`. Instance variables that
-are defined in the C++ class can be made available in Ruby very easily
-as can be seen in the following code snippet that can be found in these
-C++ classes:
-
-{% highlight cpp %}
-namespace rubinius {
- class String : public Object {
- private:
- Fixnum* hash_value_; // slot
- public:
- attr_accessor(hash_value, Fixnum);
- }
-}
-{% endhighlight %}
-
-In this case you see here the `String` class defined which has a
-`hash_value_` instance variable. This instance variable is made
-available with accessors that work from both C++, but also are used
-when the `@hash_value` instance variable in this case is set in Ruby.
-Please note that this doesn't setup accessor methods in Ruby itself.
-This means that setting an instance variable from Ruby goes through this
-accessor in C++. If this instance variable should also be exposed in
-Ruby, you still need to add an `attr_accessor` in Ruby in the given class.
-
-This mapping between the types that the virtual machine is aware of
-makes it a very easy mental model when switching from C++ to Ruby code
-when working on Rubinius.
-
-## Generic object layout
-
-Besides these types that the virtual machine knows about, there are of
-course also your every day regular Ruby objects that everyone uses in
-their applications. These generic objects of course also have to store
-instance variables, just like the object types the virtual machine is
-aware of.
-
-As you might have seen earlier in this part of the documentation, the
-generic object layout also includes an `Object` pointer called `ivars`. As
-you might already thought, this is a pointer to a so called `LookupTable`
-that contains the instance variables for this object. A `LookupTable` is a
-structure much like Ruby's `Hash`, but it uses only Symbols as the keys.
-
-## Packed object layout
-
-Since Ruby is a very flexible language, you never know up front what the
-instance variables will be that people will use in their objects. This
-is the reason that we need the `LookupTable` as described in the previous
-section.
-
-Even though Ruby is very dynamic, a lot of code that is executed
-actually is pretty static. You almost never create all kinds of dynamic
-instance variables at runtime and this set is pretty static. We can
-actually use this property to optimize this both in terms of memory
-usage and speed.
-
-What the Rubinius compiler actually does is that it tracks all the
-instance variables it sees for a `Module` or `Class` during compilation.
-Each of those variables it encounters is stored in the given `Module` or
-`Class`, as can be seen in this code snippet.
-
-{% highlight ruby %}
-class Foo
- def initialize
- @str = "awesome"
- end
-end
-
-Foo.instance_variable_get("@seen_ivars") => [:@str]
-{% endhighlight %}
-
-As you can see here, the compiler has tracked the compilation and has
-seen the `@str` instance variable. The virtual machine can then use this
-information to create an optimized object layout for the class `Foo`. This
-tracking also works for modules that are included into classes. In that
-case the instance variables tracked for the module are added to the
-class it is included into.
-
-The first time a new instance of `Foo` is created, the virtual machine
-creates a specific layout for `Foo`. In this layout, room is reserved for
-the seen instance variables. If you would write this out in a C++
-object, it would look something like this:
-
-{% highlight cpp %}
-class Foo : public Object {
- Object* str;
-}
-{% endhighlight %}
-
-This so-called packing of instance variables has multiple advantages.
-One is that this creates more memory efficient objects. We don't have
-the overhead of a LookupTable for storing them, so we use less memory
-when we make objects like this.
-
-Another advantage is that using this also results in faster code.
-Retrieving or setting an instance variable doesn't incur a `LookupTable`
-lookup anymore. The location of where the instance variable is stored
-can be determined with just the address of the object and an offset
-because this offset is always the same for all `Foo` instances.
-
-Of course it is still possible to set an instance variable on an
-instance of `Foo` after the first instance has been created. Maybe it's
-happening due to reopening the class later on after the first `Foo` is
-instantiated or we're doing some metaprogramming. In that case we use
-the `ivars` `LookupTable` as the fallback mechanism so we can keep providing
-the flexibility that Ruby gives you.
diff --git a/doc/en/ruby.markdown b/doc/en/ruby.markdown
deleted file mode 100644
index 148fba5..0000000
--- a/doc/en/ruby.markdown
+++ /dev/null
@@ -1,58 +0,0 @@
----
-layout: doc_en
-title: Ruby
-previous: Contributing - Style Guide
-previous_url: contributing/style-guide
-next: Scripts
-next_url: ruby/scripts
-review: true
----
-
-One perspective to approach understanding how Rubinius implements Ruby begins
-with understanding how various concepts in Ruby work. The purpose of this
-topic is to introduce Rubinius features by way of Ruby concepts that should
-already be familiar. The Rubinius documentation generally assumes that you are
-either familiar with Ruby or familiar with virtual machine and compiler
-concepts.
-
-Central to each of the topics below is the concept of _scope_. In Ruby syntax,
-scope is generally a derived concept. In other words, there are not syntax
-elements whose primary responsibility it is to delimit or reference scope. For
-this reason, it can be confusing to talk about scope. An example of this is a
-normal method definition:
-
- a = 5
-
- def diligent(a)
- puts a * 2
- end
-
-Here, the `#diligent` method gives us a name with which to refer to the
-computation `puts a * 2`. But the method also defines a closed lexical scope
-for the variable `a`. The scope is closed because the `a = 5` above the method
-definition has no relation to the variable `a` in `#diligent`.
-
-Often it is asserted that everything in Ruby is an object. This is not quite
-true. _Most_ things in Ruby are objects, but some things that are absolutely
-essential for running Ruby code are not necessarily objects that you can put
-your hands on. Instead, which of these "execution environment" things are
-objects in Ruby depends heavily on the implementation. Scope is one of these
-things.
-
-Essentially, _scope_ as a concept is a context for answering questions such
-as: What is the value of `self` here? What local variables exist here? What
-value will the constant `APPLE` have at this point in the code?
-
-Each of the following elements of Ruby are discussed from the perspective of
-understanding how Rubinius implements them and how the concept of _scope_ is
-involved in each one.
-
-1. [Scripts](/doc/en/ruby/scripts/)
-1. [Methods](/doc/en/ruby/methods/)
-1. [Constants](/doc/en/ruby/constants/)
-1. [Classes & Modules](/doc/en/ruby/classes-and-modules/)
-1. [Blocks & Procs](/doc/en/ruby/blocks-and-procs/)
-1. [Local Variables](/doc/en/ruby/local-variables/)
-1. [Instance Variables](/doc/en/ruby/instance-variables/)
-1. [Class Variables](/doc/en/ruby/class-variables/)
-1. [Global Variables](/doc/en/ruby/global-variables/)
diff --git a/doc/en/ruby/blocks-and-procs.markdown b/doc/en/ruby/blocks-and-procs.markdown
deleted file mode 100644
index 89f5eec..0000000
--- a/doc/en/ruby/blocks-and-procs.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_en
-title: Blocks & Procs
-previous: Classes & Modules
-previous_url: ruby/classes-and-modules
-next: Local Variables
-next_url: ruby/local-variables
-review: true
----
diff --git a/doc/en/ruby/class-variables.markdown b/doc/en/ruby/class-variables.markdown
deleted file mode 100644
index 0019cd0..0000000
--- a/doc/en/ruby/class-variables.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_en
-title: Class Variables
-previous: Instance Variables
-previous_url: ruby/instance-variables
-next: Global Variables
-next_url: ruby/global-variables
-review: true
----
diff --git a/doc/en/ruby/classes-and-modules.markdown b/doc/en/ruby/classes-and-modules.markdown
deleted file mode 100644
index 7654e9d..0000000
--- a/doc/en/ruby/classes-and-modules.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_en
-title: Classes & Modules
-previous: Constants
-previous_url: ruby/constants
-next: Blocks & Procs
-next_url: ruby/blocks-and-procs
-review: true
----
diff --git a/doc/en/ruby/constants.markdown b/doc/en/ruby/constants.markdown
deleted file mode 100644
index dcf5441..0000000
--- a/doc/en/ruby/constants.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_en
-title: Constants
-previous: Methods
-previous_url: ruby/methods
-next: Classes & Modules
-next_url: ruby/classes-and-modules
-review: true
----
diff --git a/doc/en/ruby/global-variables.markdown b/doc/en/ruby/global-variables.markdown
deleted file mode 100644
index 59755bb..0000000
--- a/doc/en/ruby/global-variables.markdown
+++ /dev/null
@@ -1,50 +0,0 @@
----
-layout: doc_en
-title: Global Variables
-previous: Class Variables
-previous_url: ruby/class-variables
-next: Specs
-next_url: specs
-review: true
----
-
-Syntatically, a global variable is supposed to be a variable whose name begins
-with `$`. Global variables are supposed to be available from any context in a
-Ruby program. However, there are actually three different kinds of globals: true
-globals, thread-local globals, and pseudo globals.
-
-True globals associate a value with a global name, such as `$LOAD_PATH`.
-
-Thread-local globals have the syntax of a global variable but there is a
-different version of the global for each thread in the running Ruby process.
-Examples of thread-local globals are `$SAFE` and `$!`. To see that these
-values depend on the thread, consider the following code:
-
- puts $SAFE
-
- Thread.new do
- $SAFE = 2
- puts $SAFE
- end
-
- puts $SAFE
-
-Pseudo globals are a strict subset of names which refer not to global values
-but values in the current scope, like local variables. These are still
-referred to as global variables because they start with a dollar sign; this is
-a source of confusion for users.
-
-All pseudo globals are organized around one primary pseudo global: `$~`. They
-are all accessing parts of `$~` and thus when `$~` changes, they all
-change.
-
-The rest of the pseudo globals are: `$&`, $` (backtick), `$'` (single
-quote), `$+`, and `$1`, `$2`, `$3`, etc.
-
-One tricky aspect of these values is that they are strictly bound to the
-current scope but Ruby allows them to be aliased, as is done in English.rb.
-
-These new aliases are basically adding new local variables to all scopes, even
-ones already running. Thusly, Rubinius does not fully support them. Instead we
-simply provide the aliases present in English.rb by default. For example,
-`$MATCH` can be used instead `$~`, whether English.rb is included or not.
diff --git a/doc/en/ruby/instance-variables.markdown b/doc/en/ruby/instance-variables.markdown
deleted file mode 100644
index efc7c8d..0000000
--- a/doc/en/ruby/instance-variables.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_en
-title: Instance Variables
-previous: Local Variables
-previous_url: ruby/local-variables
-next: Class Variables
-next_url: ruby/class-variables
-review: true
----
diff --git a/doc/en/ruby/local-variables.markdown b/doc/en/ruby/local-variables.markdown
deleted file mode 100644
index 541d3c0..0000000
--- a/doc/en/ruby/local-variables.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_en
-title: Local Variables
-previous: Blocks & Procs
-previous_url: ruby/blocks-and-procs
-next: Instance Variables
-next_url: ruby/instance-variables
-review: true
----
diff --git a/doc/en/ruby/methods.markdown b/doc/en/ruby/methods.markdown
deleted file mode 100644
index 734d69c..0000000
--- a/doc/en/ruby/methods.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_en
-title: Methods
-previous: Scripts
-previous_url: ruby/scripts
-next: Constants
-next_url: ruby/constants
-review: true
----
diff --git a/doc/en/ruby/scripts.markdown b/doc/en/ruby/scripts.markdown
deleted file mode 100644
index 544a605..0000000
--- a/doc/en/ruby/scripts.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_en
-title: Scripts
-previous: Ruby
-previous_url: ruby
-next: Methods
-next_url: ruby/methods
-review: true
----
diff --git a/doc/en/specs.markdown b/doc/en/specs.markdown
deleted file mode 100644
index 8fbf906..0000000
--- a/doc/en/specs.markdown
+++ /dev/null
@@ -1,38 +0,0 @@
----
-layout: doc_en
-title: Specs
-previous: Ruby - Global Variables
-previous_url: ruby/global-variables
-next: RubySpec
-next_url: specs/rubyspec
----
-
-The Rubinius project generally uses TDD/BDD-style executable specifications to
-drive development. The Rubinius 'spec' directory is conceptually divided into
-two parts:
-
- 1. All the files under './spec/ruby' that describe the behavior of MatzRuby.
- 2. And all the other files under the './spec' directory that describe the
- behavior of Rubinius.
-
-The specs at ./spec/ruby are a copy of RubySpec at a particular revision.
-These are regularly imported from the RubySpec project and failing specs are
-tagged so that the CI process always runs a known good set of specs. This
-enables easily confirming that changes to Rubinius code do not cause
-regressions.
-
-Documentation about the organization of specs and guidelines for writing specs
-can be found at the [RubySpec project](http://rubyspec.org/).
-
-Use the following workflow when adding specs and code to Rubinius:
-
- 1. Write failing specs for some aspect of Ruby behavior. Commit the specs in
- a separate commit to the appropriate files under ./spec/ruby.
- 2. Add Rubinius code to make the specs pass. Again, commit these changes in
- a separate commit from the spec changes.
- 3. Run the `rake` command to ensure that all the CI specs pass.
-
-The changes to files in ./spec/ruby are regularly pushed to the RubySpec
-project. Also, current changes to RubySpec from committers to other Ruby
-implementations are regularly updated in the ./spec/ruby directories. When the
-specs are updated from RubySpec, the CI tags are also updated.
diff --git a/doc/en/specs/compiler.markdown b/doc/en/specs/compiler.markdown
deleted file mode 100644
index 33e364d..0000000
--- a/doc/en/specs/compiler.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_en
-title: Compiler Specs
-previous: RubySpec
-previous_url: specs/rubyspec
-next: Build System
-next_url: build-system
-review: true
----
diff --git a/doc/en/specs/rubyspec.markdown b/doc/en/specs/rubyspec.markdown
deleted file mode 100644
index 6c95935..0000000
--- a/doc/en/specs/rubyspec.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_en
-title: RubySpec
-previous: Specs
-previous_url: specs
-next: Compiler Specs
-next_url: specs/compiler
-review: true
----
diff --git a/doc/en/systems.markdown b/doc/en/systems.markdown
deleted file mode 100644
index 7452694..0000000
--- a/doc/en/systems.markdown
+++ /dev/null
@@ -1,15 +0,0 @@
----
-layout: doc_en
-title: Rubinius Systems
-previous: Garbage Collector - Large Objects
-previous_url: garbage-collector/large-objects
-next: Primitives
-next_url: systems/primitives
-review: true
----
-
-1. [Primitives](/doc/en/systems/primitives/)
-1. [FFI](/doc/en/systems/ffi/)
-1. [Concurrency](/doc/en/systems/concurrency/)
-1. [IO](/doc/en/systems/io/)
-1. [C-API](/doc/en/systems/c-api/)
diff --git a/doc/en/systems/c-api.markdown b/doc/en/systems/c-api.markdown
deleted file mode 100644
index b2a78b5..0000000
--- a/doc/en/systems/c-api.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_en
-title: C-API
-previous: IO
-previous_url: systems/io
-next: Tools
-next_url: tools
-review: true
----
diff --git a/doc/en/systems/concurrency.markdown b/doc/en/systems/concurrency.markdown
deleted file mode 100644
index 79b5b03..0000000
--- a/doc/en/systems/concurrency.markdown
+++ /dev/null
@@ -1,110 +0,0 @@
----
-layout: doc_en
-title: Concurrency
-previous: FFI
-previous_url: systems/ffi
-next: IO
-next_url: systems/io
----
-
-Rubinius supports the same basic concurrency constructs as Ruby, Threads and
-Fibers, along with a new API: Actors. Actors provide concurrency without any
-mutexes or locking inherent when sharing state between Threads.
-
-Actors execute concurrently but don't share state; instead they pass messages to
-other actors. Here we create two actors using `Actor.spawn`, ping and pong, who
-will send messages back and forth until they have collaboratively incremented a
-variable to 1000:
-
- require 'actor'
- pong = nil
- ping = Actor.spawn do
- loop do
- count = Actor.receive
- break puts(count) if count > 1000
- pong << (count + 1)
- end
- end
- pong = Actor.spawn do
- loop do
- count = Actor.receive
- break puts(count) if count > 1000
- ping << (count + 1)
- end
- end
- ping << 1
- sleep 1
-
-Note that actors receive messages by using `Actor.receive`. This will block the
-actor until a message arrives in its own mailbox. You can process different
-types of messages by passing a block into `Actor.receive` and using message
-filtering:
-
- Actor.receive do |filter|
- filter.when(Ready) do |who|
- # SNIP
- end
- filter.when(Work) do |work|
- ready_workers.pop << work
- end
- filter.when(Actor::DeadActorError) do |exit|
- print "Actor exited with message: #{exit.reason}\n"
- ready_workers << Actor.spawn_link(&work_loop)
- end
- end
-
-Message filtering uses === on the message so you can pass in a regexp, class or
-proc to `when()`, based on your needs.
-
-Actors can also have a parent/child relationship using `Actor.spawn_link`; if
-the child dies for some reason, the parent actor can be notified by setting
-`Actor.trap_exit` to true before spawning the child. Here we create a
-supervisor actor who manages a work queue with 10 worker actors to do queue
-processing. The supervisor will receive an `Actor::DeadActorError` message if a
-worker dies (e.g. raises an exception):
-
- require 'actor'
-
- Ready = Struct.new(:this)
- Work = Struct.new(:msg)
-
- @supervisor = Actor.spawn do
- supervisor = Actor.current
- work_loop = Proc.new do
- loop do
- work = Actor.receive
- puts("Processing: #{work.msg}")
- supervisor << Ready[Actor.current]
- end
- end
-
- Actor.trap_exit = true
- ready_workers = []
- 10.times do |x|
- # start 10 worker actors
- ready_workers << Actor.spawn_link(&work_loop)
- end
- loop do
- Actor.receive do |f|
- f.when(Ready) do |who|
- # SNIP
- end
- f.when(Work) do |work|
- ready_workers.pop << work
- end
- f.when(Actor::DeadActorError) do |exit|
- print "Actor exited with message: #{exit.reason}\n"
- ready_workers << Actor.spawn_link(&work_loop)
- end
- end
- end
- end
-
- 10.times do |idx|
- @supervisor << Work[idx]
- end
- sleep 1
-
-This example is a snippet from
-[girl_friday](http://github.com/mperham/girl_friday). You can review that
-codebase for more detail if you have questions.
diff --git a/doc/en/systems/ffi.markdown b/doc/en/systems/ffi.markdown
deleted file mode 100644
index 0c9a0be..0000000
--- a/doc/en/systems/ffi.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_en
-title: Foreign Function Interface
-previous: Primitives
-previous_url: systems/primitives
-next: Concurrency
-next_url: systems/concurrency
-review: true
----
diff --git a/doc/en/systems/io.markdown b/doc/en/systems/io.markdown
deleted file mode 100644
index 208688d..0000000
--- a/doc/en/systems/io.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_en
-title: IO
-previous: Concurrency
-previous_url: systems/concurrency
-next: C-API
-next_url: systems/c-api
-review: true
----
diff --git a/doc/en/systems/primitives.markdown b/doc/en/systems/primitives.markdown
deleted file mode 100644
index 3f989b7..0000000
--- a/doc/en/systems/primitives.markdown
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: doc_en
-title: Primitives
-previous: Rubinius Systems
-previous_url: systems
-next: FFI
-next_url: systems/ffi
-review: true
----
diff --git a/doc/en/tools.markdown b/doc/en/tools.markdown
deleted file mode 100644
index cf9ad95..0000000
--- a/doc/en/tools.markdown
+++ /dev/null
@@ -1,13 +0,0 @@
----
-layout: doc_en
-title: Tools
-previous: Rubinius Systems - C-API
-previous_url: systems/c-api
-next: Debugger
-next_url: tools/debugger
-review: true
----
-
-1. [Debugger](/doc/en/tools/debugger/)
-1. [Profiler](/doc/en/tools/profiler/)
-1. [Memory Analysis](/doc/en/tools/memory-analysis/)
diff --git a/doc/en/tools/debugger.markdown b/doc/en/tools/debugger.markdown
deleted file mode 100644
index abd25d9..0000000
--- a/doc/en/tools/debugger.markdown
+++ /dev/null
@@ -1,142 +0,0 @@
----
-layout: doc_en
-title: Debugger
-previous: Tools
-previous_url: tools
-next: Profiler
-next_url: tools/profiler
----
-
-Rubinius includes a reference Ruby source-level debugger.
-
-## Installing the Necessary Components
-
-Depending on what gems you are using, you may need to install one or both of the following.
-
-The `rubinius-compiler` gem. To install:
-
- gem install rubinius-compiler
-
-The `rubinius-debugger` gem. To install:
-
- gem install rubinius-debugger
-
-## Invoking in Code
-
-The Rubinius debugger can be invoked from code by embedding a call to start
-the debugger.
-
-Consider the following code in app.rb:
-
- class Toast
- attr_accessor :setting
- def initialize
- require 'rubinius/debugger'
- Rubinius::Debugger.start
- @setting = :brown
- end
- end
-
- p Toast.new.setting
-
-Running the code in Rubinius would produce the following:
-
- $ rbx app.rb
-
- | Breakpoint: Toast#initialize at app.rb:5 (15)
- | 5: Rubinius::Debugger.start
- debug> help
- help: Show information about debugger commands
- b, break, brk: Set a breakpoint at a point in a method
- tb, tbreak, tbrk: Set a temporary breakpoint
- d, delete: Delete a breakpoint
- n, next: Move to the next line or conditional branch
- s, step: Step into next method call or to next line
- ni, nexti: Move to the next bytecode instruction
- f, frame: Make a specific frame in the call stack the current frame
- c, cont, continue: Continue running the target thread
- bt, backtrace: Show the current call stack
- p, eval: Run code in the current context
- dis, disassemble: Show the bytecode for the current method
- i, info: Show information about things
- set: Set a debugger config variable
- show: Display the value of a variable or variables
- debug> bt
- | Backtrace:
- | 0 Toast#initialize at app.rb:5 (15)
- | 1 main.__script__ at app.rb:11 (46)
- | 2 Rubinius::CodeLoader#load_script(debug) at kernel/delta/codeloader.rb:67 (44)
- | 3 Rubinius::CodeLoader.load_script(name) at kernel/delta/codeloader.rb:91 (40)
- | 4 Rubinius::Loader#script at kernel/loader.rb:460 (79)
- | 5 Rubinius::Loader#main at kernel/loader.rb:571 (64)
- | 6 Rubinius::Loader.main at kernel/loader.rb:609 (33)
- | 7 Object#__script__ at kernel/loader.rb:621 (60)
- debug> n
-
- | Breakpoint: Toast#initialize at app.rb:6 (16)
- | 6: @setting = :brown
- debug> n
-
- | Breakpoint: Toast#initialize at app.rb:7 (21)
- | 7: @kind = :rye
- debug> p @setting = :light_brown
- $d0 = :light_brown
- debug> c
- :light_brown
-
-As shown, help for the debugger commands is available by typing `help` when in
-the debugger.
-
-
-## Invoking from the Command Line
-
-The Rubinius debugger can be invoked from the command line and will present
-the debugger prompt just before loading the script specified on the command
-line.
-
-Consider the following Ruby code in bug.rb:
-
- def problem_code
- puts "I have a problem"
- a = 1 + 2
- puts "a math problem" unless a == 4
- end
-
- problem_code
-
-To debug this code, start the debugger from the command line with the
-`-Xdebug` option:
-
- $ rbx -Xdebug bug.rb
-
- | Breakpoint: Rubinius::Loader#debugger at kernel/loader.rb:424 (34)
- | 424: Rubinius::Debugger.start
- debug> b Object#problem_code:2
- * Unable to find method 'problem_code' in Object
- | Would you like to defer this breakpoint to later? [y/n] y
- | Defered breakpoint created.
- debug> c
- | Resolved breakpoint for Object#problem_code
- | Set breakpoint 2: bug.rb:2 (+0)
-
- | Breakpoint: Object#problem_code at bug.rb:2 (0)
- | 2: puts "I have a problem"
- debug> n
- I have a problem
-
- | Breakpoint: Object#problem_code at bug.rb:3 (9)
- | 3: a = 1 + 2
- debug> n
-
- | Breakpoint: Object#problem_code at bug.rb:4 (16)
- | 4: puts "a math problem" unless a == 4
- debug> p a = 4
- $d0 = 4
- debug> n
-
- | Breakpoint: main.__script__ at bug.rb:7 (17)
- | 7: problem_code
- debug> c
-
-As you can see, executing `p a = 4` in the debugger changes the value of the
-local variable `a` and affects the execution of the Ruby code.
diff --git a/doc/en/tools/memory-analysis.markdown b/doc/en/tools/memory-analysis.markdown
deleted file mode 100644
index 333955b..0000000
--- a/doc/en/tools/memory-analysis.markdown
+++ /dev/null
@@ -1,242 +0,0 @@
----
-layout: doc_en
-title: Memory Analysis
-previous: Profiler
-previous_url: tools/profiler
-next: How-To
-next_url: how-to
-review: true
----
-
-Rubinius provides an interface for dumping the current heap to a file for
-offline analysis. Several companion projects analyze the heap dump file
-as an aid for discovering memory leaks, large collections and code issues
-that may lead to potential memory pressures at runtime.
-
-## A Sample Program
-
-The following sample code (devoid of all error checks) will form the foundation
-for a tour through tracking a memory leak in Ruby code as well as a leak in code
-using the FFI subsystem.
-
-The code example is a bit contrived, but it serves to illustrate multiple real
-world problems.
-
- require 'rubygems'
- require 'ffi-rzmq'
-
- if ARGV.length < 3
- puts "usage: ruby leak.rb "
- exit
- end
-
- link = ARGV[0]
- message_size = ARGV[1].to_i
- roundtrip_count = ARGV[2].to_i
-
- ctx = ZMQ::Context.new
- request_socket = ctx.socket ZMQ::REQ
- reply_socket = ctx.socket ZMQ::REP
-
- request_socket.connect link
- reply_socket.bind link
-
- poller = ZMQ::Poller.new
- poller.register_readable request_socket
- poller.register_readable reply_socket
-
- start_time = Time.now
-
- message = ZMQ::Message.new("a" * message_size)
- request_socket.send message, ZMQ::NOBLOCK
- i = roundtrip_count
- messages = []
-
- until i.zero?
- i -= 1
-
- poller.poll_nonblock
-
- poller.readables.each do |socket|
- message = ZMQ::Message.new
- socket.recv message, ZMQ::NOBLOCK
- messages << message
- socket.send ZMQ::Message.new(message.copy_out_string), ZMQ::NOBLOCK
- end
- end
-
- elapsed_usecs = (Time.now.to_f - start_time.to_f) * 1_000_000
- latency = elapsed_usecs / roundtrip_count / 2
-
- puts "mean latency: %.3f [us]" % latency
- puts "received #{messages.size} messages in #{elapsed_usecs / 1_000_000} seconds"
-
-Wow, this program leaks like a sieve. Let's figure out why.
-
-## Saving A Heap Dump
-
-Rubinius provides access to the VM via an agent interface. The agent opens a network
-socket and responds to commands issued by the console program. The agent must be
-started with the program.
-
- rbx -Xagent.start
+
diff --git a/source/_includes/code-of-conduct.html b/source/_includes/code-of-conduct.html
new file mode 100644
index 0000000..fc6e90b
--- /dev/null
+++ b/source/_includes/code-of-conduct.html
@@ -0,0 +1,13 @@
+
+
+
Code of Conduct
+
+
The Rubinius project commits to being inclusive to the largest number of participants, with the most varied and diverse backgrounds possible. As such, we are committed to providing a friendly, safe and welcoming environment for all, regardless of gender, sexual orientation, ability, ethnicity, socioeconomic status, religion, or non-religion.
+
+
The code of conduct outlines our expectations for all those who participate in our community, online or in person, as well as the consequences for unacceptable behavior.
+
+
We invite all those who participate in Rubinius project activities to help us create safe and positive experiences for everyone.
Since its creation, Rubinius has implemented several major versions of Ruby along with advances in technology like a bytecode-based virtual machine, generational garbage collection, just-in-time compilation, and full concurrency support with no global interpreter lock. Over time, Ruby itself has gained many of these features.
+
+
Rubinius has evolved to provide a more general platform for language developers with features that support both object-oriented and functional languages with static or dynamic types.
+
+
+
+ {% include code-of-conduct.html %}
+
+
+
+
+
+
+
+
+
+
+
Rubinius, Inc
+
+
In 2015, Brian Shirai founded Rubinius, Inc as an Oregon benefit corporation to build commercial products on Rubinius and make development of the Rubinius project sustainable. Brian has contributed to the Rubinius project since December 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+ Rubinius, Inc
+ 707 SW Broadway St, Suite 1100
+ Portland, OR 97205
+ (503) 750-5378
+ contact@rubinius.com
+
+
+
+ Mailing address
+ PO Box 28603
+ Portland, OR 97228
+
+
Two things complicate app metrics: First, if everything is important, then nothing is. Second, measuring has a cost.
+
+
Rather than tentacles of foreign code worming through your app, as the typical agent approach uses, Analyst observes every aspect of your code while it's running and can focus on the parts you think are important.
+
+
And, in most cases, Analyst adds zero runtime cost.
+
+
+
+
+
+
+
+
+
+
+
+
Exception Notification
+
+
Knowing that your application has an error in production is good. Preventing errors in production is better.
+
+
Analyst knows the context of your application errors and works to alert you about problems before they get to production.
+
+
+
+
+
+
+
+
+
+
+
+
Performance Profiling
+
+
There is only one place that your app's performance matters and that's in production.
+
+
Relying on benchmarks and profiling in an artifical environment to tell you about your app's performance is like sampling a butter and flour mixture to see how a cake will taste when it's baked.
+
+
Always know how your app is performing in production with Analyst.
+
+
+
+
+
+
+
+
+
+
+
+
Data Flow Analysis
+
+
Your app processes data, and the data flow creates a graph that is distinct from the call graph and object graph.
+
+
One of the more troublesome bits of data is nil. Where do these nil values arise and why do they always seem to pop up in production?
+
+
Never again wonder where nil values are in your app.
+
+
+
+
Code Analysis
+
+
How does your app code interact? How does that interaction change over time?
+
+
Static analysis and code churn metrics can provide valuable information. But in a highly dynamic language, app behavior is potentially invisible to these methods.
+
+
With Analyst, your app is an open book.
+
+
+
+
+
+
+
+
+
+
+
+
Sign Up For Analyst
+
+
+ {% include analyst_signup.html %}
+
+
+
+
+
+
+
+
+
+
+
+
+
Code Coverage
+
+
What app code is actually running in production?
+
+
Did you just deploy code to production that has no test coverage?
+
+
Are developers gingerly working around some particularly complex area in your app? Is that feature really used in production? What code does it interact with?
+
+
Reluctant to update a critical gem for fear of some poorly tested app code breaking?
+
+
Analyst helps you work confidently with code because it sees exactly what code is running and how it interacts.
+
+
+
+
+
+
+
+
+
+
+
+
Code Instrumentation
+
+
What can you do when you have a difficult production error and need to shine a spotlight on a troublesome part of your app?
+
+
Analyst can inject instrumentation in production that can help you understand your app's behavior, but is guaranteed to not change your app's semantics.
+
diff --git a/source/compute.html b/source/compute.html
new file mode 100644
index 0000000..84050f1
--- /dev/null
+++ b/source/compute.html
@@ -0,0 +1,101 @@
+---
+layout: page
+title: "Rubinius Compute"
+subtitle: "Programming for the Internet"
+---
+
+
+
+
+
+
+
+
+
+
{{page.title}}
+
+
{{page.subtitle}}
+
+
Industry analysts say that Amazon Lambda is a game changer. We agree.
+
+
Distributed, resilient, collaborating networks of compute nodes are the future of applications in a connected world.
+
+
Compute is a service to run distributed, resilient, scalable apps on the Rubinius language platform. Like Amazon Lambda, you pay for computing, not for having a computer sitting there waiting to run your app.
+
+
+ {% include compute_signup.html %}
+
+
+
+
+
+
+
+
+
+
+
+
+
Distributed · Resilient · Simple
+
+
The rise of mobile forced deep changes in the way GUIs are built. To a lesser extent, it also affected how apps are built.
+
+
The rising tide of connected devices will force deep changes in the way apps are built. Many apps will not have any UI.
+
+
This is happening now, under the name microservices. These are distributed, resilient, interdependent, scalable, and relatively simple computation resources.
+
+
+
+
+
+
+
+
+
+
+
+
People First
+
+
Computers are the most powerful, versatile tools that humans have created.
+
+
In a few short decades, computers have gone from nonexistent to affecting nearly everyone's life in some way. Many people use computers, but only via the confines of the apps built by a relatively tiny percentage.
+
+
Access to, and direct use of, computers is the most radical transformation of human society since the rise of democracy.
+
+
+
+
+
+
+
+
+
+
+
+
The Third Wave
+
+
Amazon EC2 (Elastic Compute Cloud) was the first large-scale shift toward abstracting computation resources.
+
+
Following this, first generation PaaS (Platform as a Service) promised simpler production environments by generalizing the platform for running apps.
+
+
Amazon Lambda is nearly pure CaaS (Compute as a Service). The platform and infrastructure are abstracted away, leaving only the app as computation.
Rubinius is committed to promoting the fair exchange of value among participants in the free and open-source software ecosystem. Business models and markets for funding work on open-source software are still young and evolving.
+
+
The opportunities presented here are merely some of the ways you can contribute to Rubinius. To explore these options further or suggest your own, please email contact@rubinius.com.
+
+
+
+
+
+
+
+
+
+
Participate
+
+
+
+
+
+
+
+
+
Become a Contributor
+
+
Join over 400 people who have contributed their time and expertise to building Rubinius. Whether you code, design, write, tutor, mentor, research, or dabble, there is an opportunity to add your mark to Rubinius.
+
+
Open source projects need diverse help but have difficulty attracting participation from people who don't view coding as their primary activity. Business, marketing, writing and communication, design, and teaching skills are valued highly. Even if you're unsure how you can help, but Rubinius sounds like an exciting project, let us know.
+
+
+
+
+
+
+
+
+
+
Sponsor
+
+
+
+
+
+
Employee Contributions
+
+
Many companies have discovered that providing employees with some time to pursue an interesting idea can pay big dividends or even spawn entirely new products.
+
+
If you sponsor your employee's work on open source projects and would like to contribute to Rubinius, tell us about it so we can give your company and employee the credit they deserve.
+
+
+
+
+
+
+
+
+
The Rubinius Book
+
+
The forms of communicating knowledge are expanding tremendously with the Internet and the rich digital media it enables. Even so, books remain one of the most effective ways to organize information for sharing.
+
+
The Rubinius book is an ambitious project to completely document the Rubinius platform, development approach, community social structure, problem solving, and experimentation with programming languages. Sponsoring Rubinius book content provides one of the highest returns in a virtuous circle of learning and building, and your sponsorship would receive prominent recognition in the book.
+
+
+
+
+
+
+
Academia and industry have different goals. Academia prioritize novelty. Since big ideas are few, this leads to specialization ond then compartmentalization. Business must be profitable to exist, so industry prioritizes working systems that generate revenue. These systems are rarely novel and tend quickly toward complexity.
+
+
The Rubinius book balances these opposed goals by documenting a complete, complex, working system, while encouraging focused, specialized learning or research.
+
+
+
+
+
+
Interns and Student Projects
+
+
Learning to code is becoming increasingly important, and not merely for a career in software development. As all professions use software more, and as software becomes more controllable through APIs (application programming interfaces), there is more opportunity or need to write code.
+
+
One of the focuses of Rubinius is learning about programming systems. It provides an excellent opportunity for an intern or student to gain practical experience with a complete industrial system like one they would encounter in a job versus only an academic research system. You can sponsor one of your interns to work on Rubinius or work with us to find a code school or university student to sponsor.
+
+
+
+
+
+
+
+
+
+
+
+
+
Fund
+
+
+
+
+
+
Specific Rubinius Projects
+
+
+
+
+
+
Rubinius is an extensive project composed of many components. We prioritize features based on what we know about how useful they can be. If there are features that would be particularly valuable to your business, let's discuss how you might fund focused work on those features. You agree that the work be contributed to Rubinius and your business would receive prominent recognition for the contribution in the Rubinius book.
+
+
Rubinius is pursing ambitious advances in the utility of programming languages and applications. Various components that significantly advance the Rubinius vision would benefit from funding.
+
+
+
+
+
+
Rubinius Projects
+
+
+
+
+
next-generation JIT framework
+
thread-local, isolatable memory heaps
+
object graph analysis tools
+
machine learning applied to program execution and evolution
+
advanced instruction set
+
interoperable type systems
+
program visualization
+
+
+
+
+
+
+
+
+
+
+
+
+
Invest
+
+
+
+
+
+
+
+
+
Support and Professional Services Contract
+
+
Wisely applying your scarcest resource, your employees' time, is essential for business success. Ensuring your employees have the support they need to do their best work is also critical.
+
+
Whether you are maintaining existing applications or have new product development planned, find out how a Rubinius support or professional services contract can help your business.
+
+
+
+
+
+
Architecture, Process, and System Migration
+
+
From monolithic application architectures to microservices, from legacy IT infrastructure to cloud, containers, and serverless compute, the pace of technology change is accelerating. Staying current is essential to staying competitive. Yet this constant march forward should not come at the significant cost of discarding investments that are still providing value. Applications and infrastructure should be evolving, not merely getting replaced.
+
+
+
+
+
+
+
+
+
+
+
Cofounder
+
+
Empowerment is fundamental to the Rubinius philosophy. Empowerment is providing the means to solve our own problems and, at the same time, working to replace structures that disempower.
+
+
Rubinius, Inc seeks cofounders from diverse and under-represented groups with experience in or deep dedication to learning business, marketing, teaching, partnerships, and technology.
+
+
+
+
+
+
VC Investment
+
+
The intersection of connected devices, machine learning and artificial intelligence, cloud infrastructure, and programming languages promise extensive changes in the way software is built and used. Conversational interfaces and autonomous will dominate.
+
+
Existing programming languages and methods of building software primtive, costly, and ill-suited to the present and future software requirements, which involve distribution, resilience, rapid change, and extensive context.
-
Tweet at @rubinius on Twitter or - email community@rubini.us. Please + email community@rubinius.com. Please report Rubinius issues to our issue tracker.