Nomma py2exe

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

sape hat geschrieben:Ohh, ich dachte das "D" auch ein interpretierende Sprach sei (Wegen Garbage Collection) die sowas wie ".Net" voraussetzt oder ne andere "VM".
GC hat nichts damit zu tun ob die Sprache interpretiert ist oder nicht. Für C/C++ gibt es ja den sehr verbreiteten Boehm GC der unter anderem von Mono, Irssi, vielen Scheme-Implementationen und Mozilla verwendet wird.
sape hat geschrieben:Aber ob das wirklich irgendwann als Ersatz für C++ diene wird? Hoffen wir es mal. Den so wie ich das nun verstanden habe, bietet es die gleichen vorteile von "C#" aber ist dazu noch eine Compilierende Sprache, was ein sehr großer Pluspunkt ist!
C# ist genauso kompilierend, Python ist ebenso kompilierend. Die Sprache ist doch unabhängig davon, ob es Compiler gibt oder nicht. Wenn jemand einen C#-Compiler schriebt, der ELF-Binaries erzeugt, was wär dann?
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Leonidas hat geschrieben: C# ist genauso kompilierend, Python ist ebenso kompilierend. Die Sprache ist doch unabhängig davon, ob es Compiler gibt oder nicht.
Wir reden aneinander vorbei. Ich rede schon von Binär-Code und nicht von Bytecode (oder wie immer man das betiteln will).
Wenn jemand einen C#-Compiler schriebt, der ELF-Binaries erzeugt, was wär dann?
Sag du mir was dann wäre...
BlackJack

sape hat geschrieben:
Leonidas hat geschrieben: C# ist genauso kompilierend, Python ist ebenso kompilierend. Die Sprache ist doch unabhängig davon, ob es Compiler gibt oder nicht.
Wir reden aneinander vorbei. Ich rede schon von Binär-Code und nicht von Bytecode (oder wie immer man das betiteln will).
Ja genau, wie man das betiteln will: Was Du mit Binärcode meinst, ist einfach Bytecode für einen mehr oder weniger realen Prozessor. Es gibt Hardware-Prozessoren die Java-Bytecode ausführen können. Und Programme die x86-Binärcode in Software ausführen. In CISC-Prozessoren wie dem Pentium läuft ein Programm in Mikrocode, das beim Ausführen eines Programms die Maschineninstruktionen teilweise in RISC-Befehle übersetzt die dann von der Hardware ausgeführt werden. Die Grenzen zwischen kompiliert/interpretiert sind fliessend.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

sape hat geschrieben:
Wenn jemand einen C#-Compiler schriebt, der ELF-Binaries erzeugt, was wär dann?
Sag du mir was dann wäre...
Dann wäre das C# was in deiner Terminologie nicht kompilierend ist auf einmal kompiliert? Huch, ja sowas!
BlcakJack hat geschrieben:Es gibt Hardware-Prozessoren die Java-Bytecode ausführen können. Und Programme die x86-Binärcode in Software ausführen. In CISC-Prozessoren wie dem Pentium läuft ein Programm in Mikrocode, das beim Ausführen eines Programms die Maschineninstruktionen teilweise in RISC-Befehle übersetzt die dann von der Hardware ausgeführt werden.
Ich werf noch die Lisp Maschinen ein, die einen spezielen Fokus auf das Ausführen von Lisp-Programmen haben.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Leonidas hat geschrieben:Sag du mir was dann wäre...
Dann wäre das C# was in deiner Terminologie nicht kompilierend ist auf einmal kompiliert? Huch, ja sowas!
->
BlackJack hat geschrieben:[...]
Mal ehrlich, sieht das wie "C" aus?
Hast recht. Sieht nicht nach C/C++ aus.
BlackJack hat geschrieben: Kann man das? Da steht doch noch die .NET-VM zwischen dem Programmierer und der Hardware. Das fällt bei D weg. Man kann in D ein Betriebssystem schreiben, inklusive Interrupt-Handler und Gerätetreiber. Bei C# bräuchte man erst einmal ein Betriebssystem auf dem die .NET-Umgebung läuft. Bei D kommt aus dem Compiler ausführbarer Maschinencode raus. Die Sprache liesse sich überall dort einsetzen wo heute C++ benutzt wird. Also zum Beispiel auch in kleinen Embedded-Systemen oder in Echtzeitanwendungen.
Ohh, ich dachte das "D" auch ein interpretierende Sprach sei (Wegen Garbage Collection) die sowas wie ".Net" voraussetzt oder ne andere "VM".

Aber ob das wirklich irgendwann als Ersatz für C++ diene wird? Hoffen wir es mal. Den so wie ich das nun verstanden habe, bietet es die gleichen vorteile von "C#" aber ist dazu noch eine Compilierende Sprache, was ein sehr großer Pluspunkt ist!

lg
Ums zu klären eine neu Formulierung von mir:
Aber ob das wirklich irgendwann als Ersatz für C++ diene wird? Hoffen wir es mal. Den so wie ich das nun verstanden habe, bietet es die gleichen vorteile von "C#" aber der Compiler erzeugt ausführbaren Maschinencode.
...

Und mehr gibs da auch nicht zu sagen von meiner Seite aus. Nur darauf habe ich mich mit "Kompilierende Sprache" bezogen und habe gehofft das genau das auch ankommt.

lg
Zuletzt geändert von sape am Mittwoch 27. Dezember 2006, 13:51, insgesamt 1-mal geändert.
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

BlackJack hat geschrieben:
sape hat geschrieben:
Leonidas hat geschrieben: C# ist genauso kompilierend, Python ist ebenso kompilierend. Die Sprache ist doch unabhängig davon, ob es Compiler gibt oder nicht.
Wir reden aneinander vorbei. Ich rede schon von Binär-Code und nicht von Bytecode (oder wie immer man das betiteln will).
Ja genau, wie man das betiteln will: Was Du mit Binärcode meinst, ist einfach Bytecode für einen mehr oder weniger realen Prozessor. Es gibt Hardware-Prozessoren die Java-Bytecode ausführen können. Und Programme die x86-Binärcode in Software ausführen. In CISC-Prozessoren wie dem Pentium läuft ein Programm in Mikrocode, das beim Ausführen eines Programms die Maschineninstruktionen teilweise in RISC-Befehle übersetzt die dann von der Hardware ausgeführt werden. Die Grenzen zwischen kompiliert/interpretiert sind fliessend.
Keine Ahnung. Ich kenne nur das Schubladendenken "Ausführbarer Maschinencode -> Binärcode" und "Bytecode -> Wird von einer Virtuellen Maschine wie z.B. .Net ausgeführt oder direkt interpretiert wie das z.B. Python macht". Mehr kenne ich nicht.

Das für "EFL" oder "x86" letztendlich auch sowas wie eine """VM""" benutzt wird die den Code für die CPU aufbereitet und dann an sie schickt, war mir zwar irgendwie klar aber hielt ich nicht für vergleichbar weil es sehr low-low-level ist...

lg
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

sape hat geschrieben:Ich kenne nur das Schubladendenken "Ausführbarer Maschinencode -> Binärcode" und "Bytecode -> Wird von einer Virtuellen Maschine wie z.B. .Net ausgeführt oder direkt interpretiert wie das z.B. Python macht". Mehr kenne ich nicht.
CPython führt den Code auch nicht direkt aus, sondern hat auch eine VM.
sape hat geschrieben:Das für "EFL" oder "x86" letztendlich auch sowas wie eine """VM""" benutzt wird die den Code für die CPU aufbereitet und dann an sie schickt, war mir zwar irgendwie klar aber hielt ich nicht für vergleichbar weil es sehr low-low-level ist...
Du kannst ELF nicht mit x86-Assembly vergleichen, ELF ist das PE-Aquivalent auf den meisten Unix-Systemen, welches a.out und COFF abgelöst hat.

Auch noch einzuwerfen ist die x86-Emulation der IA-64 (Itanium) Firmware, diese übersetzt die IA-32-Befehle auf IA-64, wodurch das ausführen von x86-Assembly möglich wird. Also wieder eine VM.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Antworten