Translated bootstrapping process description page.

web/doc/ger/bootstrapping.markdown

@@ -1,37 +1,45 @@
 ---
 layout: doc_ger
 title: Bootstrapping
-previous: Build System
+previous: Bausystem
 previous_url: build-system
-next: Virtual Machine
+next: Virtuelle Maschine
 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:
+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
@@ -41,63 +49,77 @@ all Ruby code can be executed. There are seven stages to the bootstrap process:
        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.
+     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: 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.
+  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: 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.
+  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: 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.
+  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: 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.
+  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: The compiled version of kernel/loader.rb is run.
+  7. loader: Die kompilierte Version von kernel/loader.rb wird ausgeführt.
 
-     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.
+     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.
 
-     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.
+     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.
 
-## Load Order
+## Ladereihenfolge
 
-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.
+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.
 
-When an rbc file is loaded, code at the script level and in class or module
-bodies is executed. For instance, when loading
+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
 
-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.
+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.