Rubinius

Rubinius runs on macOS and many Unix/Linux operating systems. Microsoft Windows is not supported. We welcome contributions. For more information, see the FAQ below and read the contributing file. Contributions made prior to January 3rd, 2016 are licensed under the old BSD 3-clause license. A copy of this license can be found in the file "BSD LICENSE". In the event a directory contains a "LICENSE", "LICENSE.txt" or "COPYING" file the license specified in said file applies to the contents of said directory and all sub directories, overwriting the licenses specified above. When the install process finishes, follow the directions printed to the terminal to add the Rubinius executable (bin) directory to your PATH. Certain setups of openssl require you to pass along additional options, --with-lib-dir and --with-include-dir pointing to include the relevant openssl directories. It runs in an environment that provides various capabilities. These are presented to the machine through the Environment object. It has certain configuration values that influence how the machine operates. This is managed by the Configuration object. The machine has a boot process that carefully builds up the components in a precise order until the machine is ready to run user code. When the user code completes executing, the machine halts, again following a precise sequence of deconstructing the various components. The Rubinius instruction set includes different categories of instructions. One key aspect of the Rubinius philosophy is that the instruction set should represent any machine semantic. This contrasts with the way Rubinius has been implemented historically, which relied heavily on C++ "primitives" modeled on the Smalltalk 80 virtual machine. All the primitives are being replaced as the instruction set evolves richer capabilities. 1. Stack instructions that push, pop, and get operands from a stack; 2. Register instructions that read from and write to a set of registers; 3. Assertion instructions that can halt execution but cannot change the semantics of the program; 4. Instrumentation instructions that cannot change the semantics of the program but can emit data from the program; 5. Parsing Expression Grammar (PEG) instructions. PEGs are an elegant formalism for describing recognizers; 6. Foreign Function Interface (FFI) instructions for binding and calling external functions; 7. Concurrency instructions for execution threads and concurrent data; 8. System instructions for accessing files, directories, and other systam capabilities. TODO: There's plenty of places to help out here if parsers, compilers, and instruction sets interest you. Rubinius has two kinds of managed objects: object-oriented ones that can support inheriting from a superclass, and data objects that have no concept of object-orientation. Threads that use isolated heaps can execute fully independent of any other thread and only must synchronize with the process during boot, fork, and halt. The garbage collector for isolated heaps is run in that thread. Rubinius uses a single mechanism for garbage collection, the Immix mark-region collector. The Rubinius garbage collector currently runs on a single separate thread and must fully synchronize all threads that mutate managed memory (ie it stops the world). In the future, the single open heap will introduce a second generational area, and the isolated heaps will provide for parallel collection. TODO: There's plenty of places to help out here if garbage collectors interest you. The Rubinius CodeDB is where all compiled code for the core and standard libraries is stored. Every executable context (in Ruby, these are scripts, class & module bodies, methods, and blocks) has a unique ID and is cached in the CodeDB. In the future, all user code will also be cached in the CodeDB. The unique ID of every executable context allows for associating arbitrary dimensions of data with that instance of executable code. For example, type i