Das deutsche Python-Forum

Weiß jemand wie man das compilieren kann?

Was sind für Dich "höhere" Sprachen? Es gibt zum Beispiel BASIC, Comal, Pascal und auch Forth für den C64, also für maximal 64 KiB RAM. Smile

Höher im Sinne von "man kann damit halbwegs anständig prozedural und / oder (wenn möglich) objektorientiert / funktional / xyz programmieren". Momentan nutze ich auf diesem Gerät, das 188kb freien Ram bei Betrieb besitzt, C. Funktioniert auch relativ gut, wenngleich meine C Kenntnisse nicht die besten sind [1]. Aber das hört sich schonmal ganz nett an. Nur wäre die Frage, inwiefern grade Sprachen wie Python oder Ruby oder auch Scheme und Io speicherhungriger sind, zb auch in Kombination mit einer StdLib.

[1] Ich habe leider immernoch keine gute Ressource für das Programmieren mit C gefunden, die mehr als nur die Syntax und ein paar Basisfunktionen erklärt gefunden. Grade bei C hat es ja oft Umwälzungen gegeben (gets?), kennt da jemand was?

burli hat geschrieben:Weiß jemand wie man das compilieren kann?

``python setup.py linux`` und das Binary findet man dann in Build. Geht übrigens sehr schnell, der Buoldvorgang dauert bei mir 4 Sekunden. Das ist etwa so lange wie sich Javac (OpenJDK Java Compiler) für eine recht kleine Java-Datei rausnimmt.

@str1442: C von A bis Z soll sehr gut sein. <anspielung>Achte bei der Qualität nicht auf den Verlag, sondern auf den Autor. </anspielung>

Danke Leonidas,
ich bin inzwischen dahinter gekommen. Ich hatte zuerst die Version 1.0 und dann hab ich versucht wie in der Readme mit pygame zu compilieren.

Leonidas hat geschrieben:

burli hat geschrieben:Weiß jemand wie man das compilieren kann?

``python setup.py linux`` und das Binary findet man dann in Build. Geht übrigens sehr schnell, der Buoldvorgang dauert bei mir 4 Sekunden. Das ist etwa so lange wie sich Javac (OpenJDK Java Compiler) für eine recht kleine Java-Datei rausnimmt.

Der ist ja nun auch nicht der schnellste ^^

lunar hat geschrieben:Der ist ja nun auch nicht der schnellste ^^

Tatsache. Ich habe mich immer gewundert warum der Scala-Compiler so lange braucht, nachdem ich javac etwas eingesetzt habe liegt die Antwort auf der Hand

@str1442: Ich finde die "man pages" vom GCC zu den C-Standardfunktionen ganz nützlich, wo zum Beispiel vor `gets()` eindringlich gewarnt wird.

Leonidas hat geschrieben:

lunar hat geschrieben:Der ist ja nun auch nicht der schnellste ^^

Tatsache. Ich habe mich immer gewundert warum der Scala-Compiler so lange braucht, nachdem ich javac etwas eingesetzt habe liegt die Antwort auf der Hand

Ich nutze ecj. Und der ist – abgesehen davon, dass er besser mit emacs-jde zusammenarbeitet – selbst bei kleinen Dateien spürbar schneller.

Zur Ehrenrettung von Java sei gesagt, dass bei mir Clojure mit 107 Dateien und 40722 Zeilen Java-Code in 2.5 Sekunden mit javac kompiliert. Clojure selbst braucht dann länger (etwa 3.5 Sekunden), seine eigenen 6333 Zeilen Code zu übersetzen. Insgesamt entstehen ~1100 class files die in einer Sekunde zu einem jar gemacht werden.

Der Scala-Compiler ist in Scala geschrieben, welches sehr viele class-Dateien erzeugt, die die JVM alle jedes Mal mühsam laden muss. Das verlängert leider die Startzeit. Für mehrere Dateien sollte man daher unbedingt ant oder eine IDE einsetzen, weil dort der Compiler jeweils nur 1x geladen werden muss. Scalas Compiler ist zudem wahrscheinlich nicht auf Geschwindigkeit optimiert und er führt IIRC mehrere Läufe über den AST des eingelesenen Programms aus, in dem jeweils verschiedene Programmtransformationen durchgeführt werden, bis dann das ganze endlich so primitiv ist, dass Bytecode und damit class files erzeugt werden können.

Ein Forth-System, das in 4 KB passte, brauchte vielleicht nochmal 2 KB RAM - je nachdem natürlich, wie groß man seine eigenen Programme machen wollte. In 2 KB passen etwa 1000 Befehle. Das mag für die Steuerung eines Radioteleskops ausgereicht haben. Man bedenke, dass man ja auch jederzeit von Diskette weitere Befehle nachladen und auf diese Weise "pagen" konnte. Forth hat die Diskette in Sektoren a 1024 Bytes eingeteilt, die dann jeweils als Seiten von 64x16 Zeichen gelesen wurden und in die man den Quelltext eintragen konnte. Natürlich müssen diese 1024 Bytes ins System passen, aber das wäre dann ja der Bildschirmspeicher, der nochmals extra zählen könnte.

Ich würde tippen, dass tinypy mit relativ wenig Hauptspeicher auskommt, da es im wesentlichen ja nur eine VM ist der Python-Code für Parser und Compiler in relativ kompaktem Bytecode hinzugefügt wird.

Aber was ist heutzutage schon wenig? Mein Rechner hat 4 GB Hauptspeicher, die ich bei Apple recht teuer bezahlen durfte, die aber auf dem freien Markt für PCs inzwischen unter 50€ kosten. Ist also 1 GB relativ wenig? Oder 1 MB?

Und was erwartet man? Reicht eine Kommandozeile und ein dünner Wrapper um Funktionen, die das Betriebssystem zur Verfügung stellt oder soll es eine grafisch opulente farbige Fensteroberfläche sein und Bibliotheken für jedes denkbare Problem verfügbar sein?

Das C64-Basic würde ich aus heutiger Sicht nicht als höhere Sprache bezeichnen :) goto, gosub und ausschließlich globale Variablen sind nicht gerade etwas, mit dem man Programmabstraktionen bauen kann. Und bei UCSD-Pascal für den C64 musste man laufend Disketten wechseln, weil es nicht komplett in den Hauptspeicher passte.

Stefan

@sma: CBM BASIC V2 ist tatsächlich reichlich eingeschränkt, aber Comal ist als Mischung zwischen BASIC und Pascal ganz nett. Ausserdem gibt's für den C64 einen ganzen Haufen "aufgebohrte" BASIC-Varianten, teilweise auch mit Prozeduren mit Namen und lokalen Variablen.

@crackpod: Schau dir mal unsere FAQ an: [wiki]FAQ[/wiki]
Ganz besonders die Punkte: "Wo gibt es einen Python-Compiler?" bis einschließlich "Was ist PyPy?"

@str1442: C von A bis Z soll sehr gut sein. <anspielung>Achte bei der Qualität nicht auf den Verlag, sondern auf den Autor. Wink </anspielung>

Hm, schau ich mir mal an. Ich hatte von dem Buch schon gehört, und hatte dann auf ProLinux einen Artikel dazu gefunden, und da wurde auf das hier verwiesen:

http://groups.google.com/group/de.comp. ... ode=source
http://groups.google.com/group/de.comp. ... ode=source

Was auch immer man sich unter Vorwärtsdeklaration von Funktionen vorstellen soll, es hört sich unschön an. Aber ich schau es mir mal an, Danke!

@str1442: Ich finde die "man pages" vom GCC zu den C-Standardfunktionen ganz nützlich, wo zum Beispiel vor `gets()` eindringlich gewarnt wird.

Welche? Also für gcc selbst finde ich nur doc Pakete die manpages zu GCC selbst enthalten und einem Tool namens gcov, und bei ersterem wird nur in aller Länge der Compiler erklärt. Meinst du dieses Manual hier: http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/ ? Das sieht ganz interessant aus.

Ups, sorry, ich meinte die zur `libc`. Bei Ubuntu AFAIK das `manpages-dev`-Paket.

Also für gcc selbst finde ich nur doc Pakete die manpages zu GCC selbst enthalten und einem Tool namens gcov, und bei ersterem wird nur in aller Länge der Compiler erklärt.

Hi,

hatte mal angefangen, selbst was über gcc zu schreiben:

http://www.angelfire.com/linux/tux25/c/gcc.html

Die Profis nörgeln mich aber immer zu ...

Schau Dir auch unbedingt mal diesen Geheimtip zu C-Strings an:

http://www.howstuffworks.com/c36.htm

Könnte noch mehr von solchen Tips vertragen. Sollte man vielleicht im Offtopic-Forum diskutieren ...

HTH

Gruß

abgdf hat geschrieben:hatte mal angefangen, selbst was über gcc zu schreiben:

Du könntest erwähnen dass GCC normalerweise gnu89 als C-Dialekt verwendet und gnu99 zusätzlich dazu verfügbar hat. Die GNU-Dialekte haben nette bis freakige Erweiterungen

Danke and BlackJack und abgdf! Habe das Paket manpages-dev gefunden und das enthält wirklich einiges zu den C Funktionen - jetzt muss ich mich darin nur noch zurechtfinden bei den vielen Namen