From 5415ab33037dae523ff5847f136798acacc2e9db Mon Sep 17 00:00:00 2001 From: Christopher Bertels Date: Sat, 18 Dec 2010 19:07:18 +0100 Subject: [PATCH] Translated bootstrapping process description page. --- web/doc/ger/bootstrapping.markdown | 166 ++++++++++++++++------------- 1 file changed, 94 insertions(+), 72 deletions(-) diff --git a/web/doc/ger/bootstrapping.markdown b/web/doc/ger/bootstrapping.markdown index 88d5f53d4e..fbb21759ea 100644 --- a/web/doc/ger/bootstrapping.markdown +++ b/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.