Author Archives: demensdeum

Es ist möglich, macOS in Docker auszuführen, trotz der Einwände von Leuten, die sagen, dass dies unmöglich sei, und angeblich verfügt macOS über Schutzsysteme, die dem widerstehen können.

Einige der klassischen Möglichkeiten, macOS auf PC-Rechnern auszuführen, waren in der Vergangenheit:
*Hackintosh
* Virtualisierung, zum Beispiel mit VMWare

Hackintosh setzt das Vorhandensein von Hardware voraus, die dem Original-Mac ähnelt oder diesem sehr nahe kommt. Die Virtualisierung stellt bestimmte Anforderungen an die Hardware, jedoch im Allgemeinen nicht so streng wie im Fall von Hackintosh. Allerdings kommt es bei der Virtualisierung zu Performance-Problemen, da macOS nicht für das Arbeiten in einer virtuellen Umgebung optimiert ist.

Seit kurzem ist es möglich, macOS in Docker auszuführen. Möglich wird dies durch das Docker-OSX-Projekt, das vorgefertigte macOS-Images zur Ausführung auf Docker bereitstellt. Es ist erwähnenswert, dass Docker-OSX kein offizielles Apple-Projekt ist und von diesem nicht unterstützt wird. Sie können jedoch macOS auf Docker ausführen und es zum Entwickeln und Testen von Anwendungen verwenden.

Eines der ersten Projekte, das macOS in Docker ausführt:
https://github.com/sickcodes/Docker-OSX

Allerdings konnte ich es nie vollständig starten; Nach dem Laden in Recovery OS fielen meine Tastatur und meine Maus einfach ab und ich konnte die Installation nicht fortsetzen. Gleichzeitig funktioniert im ersten Bootmenü die Tastatur. Vielleicht liegt es daran, dass dieses Projekt nicht mehr so ​​aktiv unterstützt wird und es bei der Ausführung unter Windows 11 + WSL2 + Ubuntu einige spezifische Probleme gibt.

Eines der derzeit aktivsten Projekte:
https://github.com/dockur/macos

Ermöglicht die Ausführung von macOS in Docker, die Schnittstelle funktioniert über den Browser per VNC(?)-Weiterleitung. Nach dem Start ist macOS unter http://localhost:5900 verfügbar

Ich habe es geschafft, dieses Projekt auszuführen und macOS Big Sur (Minute 2020) unter Windows 11 + WSL2 + Ubuntu zu installieren, aber nur durch Ändern der Compose-Datei, nämlich:

environment:
    VERSION: "11"
    RAM_SIZE: "8G"
    CPU_CORES: "4"

VERSION: „11“ ist die Version von macOS, in diesem Fall Big Sur
RAM_SIZE: „8G“ ist die für macOS zugewiesene RAM-Größe
CPU_CORES: „4“ ist die Anzahl der CPU-Kerne, die macOS zugewiesen sind

Derzeit ist auch die Ausführung von macOS Tahoe (16) möglich, allerdings gibt es eine Reihe von Problemen, die die Projektentwickler beherzt zu lösen versuchen.

Diese originelle Art, macOS zu starten, ermöglicht es Ihnen, es auf Ihrer Nicht-Mac-Hardware auszuprobieren und sich, nachdem Sie genug gelitten haben, einen Mac zu kaufen. Es kann jedoch zum Testen von Software auf älteren Systemen und für die allgemeine Entwicklung nützlich sein.

Das Swift-Ökosystem entwickelt sich aktiv außerhalb der Apple-Plattformen, und heute ist es recht komfortabel, darin unter Windows mit dem Windows-Subsystem für Linux (WSL2) zu schreiben. Es ist zu bedenken, dass für Assemblys unter Linux/WSL eine schlanke Version von Swift verfügbar ist – ohne proprietäre Apple-Frameworks (wie SwiftUI, UIKit, AppKit, CoreData, CoreML, ARKit, SpriteKit und andere iOS/macOS-spezifische Bibliotheken), aber für Konsolen-Dienstprogramme und das Backend ist dies mehr als ausreichend. In diesem Beitrag werden wir den Prozess der Vorbereitung der Umgebung und der Erstellung des Swift-Compilers aus dem Quellcode in WSL2 Schritt für Schritt durchgehen (am Beispiel von Ubuntu/Debian).

Wir aktualisieren die Liste der Pakete und das System selbst:

sudo apt update && sudo apt upgrade -y

Installieren Sie die erforderlichen Abhängigkeiten für den Build:

sudo apt install -y \
  git cmake ninja-build clang python3 python3-pip \
  libicu-dev libxml2-dev libcurl4-openssl-dev \
  libedit-dev libsqlite3-dev swig libncurses5-dev \
  pkg-config tzdata rsync

Installieren Sie den Compiler und Linker (LLVM und LLD):

sudo apt install -y llvm lld

Klonen Sie das Swift-Repository mit allen Abhängigkeiten:

git clone https://github.com/apple/swift.git
cd swift
utils/update-checkout --clone

Installieren Sie „swiftly“ und fertiges Swift mit Swiftc

curl -O https://download.swift.org/swiftly/linux/swiftly-$(uname -m).tar.gz && \
tar zxf swiftly-$(uname -m).tar.gz && \
./swiftly init --quiet-shell-followup && \
. "${SWIFTLY_HOME_DIR:-$HOME/.local/share/swiftly}/env.sh" && \
hash -r

Beginnen wir mit dem Build (dies wird lange dauern):

utils/build-script \
  --release-debuginfo \
  --swift-darwin-supported-archs="x86_64" \
  --llvm-targets-to-build="X86" \
  --skip-build-benchmarks \
  --skip-test-cmark \
  --skip-test-swift \
  --skip-ios \
  --skip-tvos \
  --skip-watchos \
  --skip-build-libdispatch=false \
  --skip-build-cmark=false \
  --skip-build-foundation \
  --skip-build-lldb \
  --skip-build-xctest \
  --skip-test-swift

Nachdem der Build abgeschlossen ist, fügen Sie den Pfad zum Compiler zu PATH hinzu (geben Sie Ihren Pfad zum Build-Ordner an):

export PATH=/root/Sources/3rdparty/build/Ninja-RelWithDebInfoAssert/swift-linux-x86_64/bin/swiftc:$PATH

Wir überprüfen, ob die installierte Version von Swift funktioniert:

swift --version

Erstellen Sie eine Testdatei und führen Sie sie aus:

echo "print(\"Hello, World!\")" > hello.swift
swift hello.swift

Sie können die Binärdatei auch kompilieren und ausführen:

swiftc hello.swift
./hello

Quellen

• Erste Schritte mit Swift unter Windows
• Swiftly (Versionskontrolltool)
• Swift aus Quellcode erstellen

Im letzten Artikel haben wir uns mit der Theorie des Interpreter-Musters befasst, gelernt, was ein AST-Baum ist und wie man terminale und nicht-terminale Ausdrücke abstrahiert. Lassen Sie uns dieses Mal von der Theorie Abstand nehmen und sehen, wie dieses Muster in ernsthaften kommerziellen Projekten angewendet wird, die wir alle täglich verwenden!

Spoiler: Möglicherweise verwenden Sie gerade das Interpreter-Muster, indem Sie einfach diesen Text in Ihrem Browser lesen!

Eines der auffälligsten und vielleicht wichtigsten Beispiele für die Verwendung dieses Musters in der Branche ist JavaScript. Die ursprünglich „auf dem Knie“ entstandene Sprache funktioniert heute dank des Interpretationskonzepts auf Milliarden von Geräten.

10 Tage, die das Internet verändert haben

Die Geschichte von JavaScript ist voller Legenden. Im Jahr 1995 erhielt Brendan Eich während seiner Arbeit bei Netscape Communications die Aufgabe, eine einfache Skriptsprache zu entwickeln, die direkt in einem Browser (Netscape Navigator) ausgeführt werden konnte, um Webseiten interaktiv zu gestalten. Das Management wollte etwas mit einer Syntax, die dem damals sehr beliebten Java ähnelte, aber nicht für professionelle Ingenieure, sondern für Webdesigner gedacht war.

Eich hatte nur 10 Tage Zeit, um den ersten Prototyp der Sprache zu schreiben, die damals Mocha hieß (damals LiveScript und aus Marketinggründen erst JavaScript). Der Ansturm kam nicht von ungefähr: Microsoft war ihm dicht auf den Fersen und bereitete gleichzeitig aktiv seine eigene Skriptsprache VBScript für die Einbettung in den Internet Explorer-Browser vor. Netscape musste dringend seine Antwort veröffentlichen, um im drohenden Browserkrieg nicht zu verlieren.

Es war einfach keine Zeit, einen komplexen Compiler in Maschinencode zu schreiben. Die offensichtlichste und schnellste Lösung für Eich war die Architektur des klassischen Interpreter.

Der erste Interpreter (SpiderMonkey) funktionierte folgendermaßen:

1. Der Textquellcode des Skripts wurde von der Seite gelesen.
2. Der lexikalische Analysator hat den Text in Token zerlegt.
3. Der Parser hat einen Abstract Syntax Tree (AST) erstellt. In Bezug auf das Interpreter-Muster bestand dieser Baum aus terminalen Ausdrücken (Zeichenfolgen, Zahlen wie 42) und nicht-terminalen Ausdrücken (Funktionsaufrufe, Anweisungen wie If, ​​​​While).
4. Dann „durchlief“ die virtuelle Maschine diesen Baum Schritt für Schritt und führte die darin eingebetteten Anweisungen an jedem Knoten aus (wobei sie eine Methode ähnlich Interpret() aufrief).

Kontext und Objekte

Erinnern Sie sich an das Context-Objekt, das wir in der klassischen Implementierung an die Methode Interpret(Context context) übergeben mussten? Der Interpreter benötigt es, um den aktuellen Speicherzustand zu speichern.

Im Fall von JavaScript wird die Rolle dieses Kontexts auf der obersten Ebene von einem globalen Objekt (z. B. einem Fenster in einem Browser) übernommen. Wenn Ihr AST-Knoten versucht, beispielsweise über document.write(“Hello”) Text auf den Bildschirm zu schreiben, greift der Interpreter auf seinen Kontext (das Dokumentobjekt) zu und ruft die gewünschte interne Browser-API auf.

Dank des Interpreters kann JavaScript so einfach mit dem DOM (Document Object Model) interagieren – das sind alles nur Objekte in einem Kontext, auf die über Baumknoten zugegriffen wird.

Entwicklung des Interpreters: JIT-Kompilierung

Historisch gesehen ist JS in Browsern lange Zeit ein „reiner“ Interpreter geblieben. Und das hatte einen großen Nachteil: langsame Geschwindigkeit. Das Parsen des Baums und das langsame Durchlaufen jedes Knotens bei jeder Ausführung des Skripts verlangsamte komplexe Webanwendungen.

Mit der Einführung der V8-Engine von Google (integriert in Chrome) im Jahr 2008 kam es zu einer Revolution. Ingenieure erkannten, dass ein Dolmetscher für das moderne Web nicht ausreicht. Die Engine ist komplexer geworden: Sie erstellt immer noch den AST-Baum, verwendet aber jetzt die JIT-Kompilierung (Just-In-Time).

Moderne JS-Engines (V8, SpiderMonkey) funktionieren wie eine komplexe Pipeline:

1. Der schnelle und einfache Basisinterpreter beginnt sofort mit der Ausführung Ihres JS-Codes, ohne überhaupt auf die Kompilierung warten zu müssen (das klassische Muster funktioniert hier immer noch).
2. Parallel dazu überwacht die Engine „heiße“ Codeabschnitte (Schleifen oder Funktionen, die tausende Male aufgerufen werden).
3. Diese Abschnitte werden vom JIT-Compiler unter Umgehung des langsamen Interpreters direkt in optimierten Maschinencode kompiliert.

Es war diese Kombination aus dem sofortigen Start des Interpreters und der Rechenleistung der Kompilierung, die es JavaScript ermöglichte, die Welt zu erobern und zur Sprache von Servern (Node.js) und mobilen Anwendungen (React Native) zu werden.

Dolmetscher in der Spielebranche

Trotz der Dominanz von C++ im Heavy Computing ist das Interpreter-Muster ein Industriestandard in der Spieleentwicklung zum Erstellen von Spiellogik. Wofür? Damit Spieleentwickler Spiele erstellen können, ohne das Risiko einzugehen, die Engine „abzuwerfen“ oder sie ständig neu kompilieren zu müssen.

Ein hervorragendes historisches Beispiel ist UnrealScript – die Sprache, in der die Logik der Spiele Unreal Tournament und Gears of War in den Unreal Engines 1, 2 und 3 geschrieben wurde. Der Text wurde in einen kompakten abstrakten Maschinenbytecode kompiliert, der dann Schritt für Schritt von der virtuellen Maschine der Engine (interpretiert) wurde.

Visuelle Diagrammskripte (Blueprints)

Heute wurde Text durch visuelle Programmierung ersetzt – das Blueprints-System in Unreal Engine 4 und 5.

Wenn Sie jemals einen Blueprint in Unreal Engine geöffnet haben, haben Sie viele Knoten gesehen, die durch Kabel verbunden sind. Architektonisch gesehen ist das gesamte Blueprints-Diagramm ein riesiger abstrakter Syntaxbaum (AST), der auf dem Bildschirm gezeichnet wird:

1. Terminalausdrücke: Konstante Knoten. Zum Beispiel ein Knoten, der einfach die Zahl 42 oder einen String speichert. Sie geben bei der Interpretation einen bestimmten Wert zurück.
2. Nicht-terminale Ausdrücke: Rechenknoten (Hinzufügen) oder Flusskontrollknoten (Zweig). Sie verfügen über Argumenteingänge, die der Interpreter zunächst rekursiv auswertet, bevor er das Ergebnis als Ausgabepin erzeugt.

Und die Rolle des Kontexts spielt hier die Erinnerung an eine Instanz eines bestimmten Spielobjekts (Akteur). Die Interpretermaschine „geht“ sicher durch dieses Diagramm, fordert Daten an und führt Übergänge durch.

Wo wird der Interpreter sonst noch verwendet?

Das Interpretermuster kann in fast jedem komplexen System gefunden werden, in dem dynamische Anweisungen ausgeführt werden müssen. Hier sind nur einige Beispiele aus kommerzieller Software:

• Interpretierte Programmiersprachen (Python, Ruby, PHP). Ihre gesamte Laufzeit basiert auf dem klassischen Muster. Beispielsweise analysiert die CPython-Referenzimplementierung Ihr .py-Skript zunächst in ein AST, kompiliert es in Bytecode und dann interpretiert eine riesige virtuelle Maschine (Rechenschleife) diesen Bytecode Schritt für Schritt.
• Java Virtual Machine (JVM). Zunächst wird Java-Code nicht in Maschinenanweisungen, sondern in Bytecode kompiliert. Wenn Sie die Anwendung ausführen, fungiert die JVM als Interpreter (allerdings mit aggressiver JIT-Kompilierung, genau wie in V8).
• Datenbanken und SQL Wenn Sie eine SQL-Abfrage (SELECT * FROM user) in PostgreSQL oder MySQL ausgeben, fungiert die Datenbank-Engine als Interpreter. Es führt eine lexikalische Analyse durch, erstellt einen AST-Abfragebaum, generiert einen Ausführungsplan und „interpretiert“ diesen Plan dann buchstäblich, indem es über die Zeilen der Tabellen iteriert.
• Reguläre Ausdrücke (RegEx). Jede Engine für reguläre Ausdrücke analysiert intern ein Zeichenfolgenmuster (z. B. ^\d{3}-\d{2}$) in ein Zustandsdiagramm (NFA/DFA-Automaten), das der interne Interpreter dann durchläuft und jedes Eingabezeichen mit den Eckpunkten dieses Diagramms abgleicht.
• Unity Shader Graph / Unreal Material Editor – visuelle Knoten in modularen Shader-Code (GLSL/HLSL) interpretieren.
• Blender Geometry Nodes – interpretieren mathematische und geometrische Operationen, um prozedural 3D-Modelle in Echtzeit zu generieren.

Gesamt

Das Interpreter-Muster geht längst über den Rahmen des „Schreibens eines eigenen Taschenrechners“ hinaus. Dies ist der leistungsstärkste Industriestandard. Von JavaScript-Engines, die täglich Gigabytes an Code hinter den Kulissen von Browsern ausführen, bis hin zu Spieledesignern, die es Ihnen ermöglichen, komplexe Logik ohne Kenntnisse von C++ zu erstellen, bleiben Interpreter eines der wichtigsten Architekturkonzepte in der modernen IT-Entwicklung.