Hallo,
in meinem Webserver Projekt (http://stefanfrings.de/avr_io/index.html)
übersetze ich statische HTML Dateien und Bilder in C-Quelltext (nämlich
byte-arrays) mit Hilfe eines Perl Scriptes. Der Aufruf des Scriptes
findet durch mein Makefile statt, das Script ist also neben dem
C-Compiler und dem Linker lediglich ein weiteres Tool für den Build
Prozess.
Wer meinen Webserver modifiziert, wird das Perl script nicht verändern
wollen. Er muss sich nur mit den C Quelltexten beschäftigen.
Nun haftet Perl ein etwas altbackenes Image an, deswegen überlege ich,
ob ich in künftigen Projekten besser einen moderneren Script Interpreter
verwenden sollte. Perl erfüllt seinen Job an dieser Stelle einwandfrei.
Nur ist es noch Zeitgemäß?
Auf jeden Fall ist wichtig, dass der nötige Script-Interpreter
mindestens für Linux, Windows (ab XP) und Mac OS verfügbar ist und ohne
großartige Aufwände installiertbar ist. Bei Perl war diese Anforderung
erfüllt.
Mir fällt da spontan Python als Alternative ein.
Würdet ihr lieber Perl Scripte oder Python Scripte verwenden?
"altbackenes Image" von Perl? Ist das deine persönliche Meinung oder
behauptet es nur jemand in deinem Umfeld, der die Sprache vielleicht
überhaupt nicht kennt?
Was die Intention zur Entwicklung von Perl war kann man auf den
einschlägigen Seiten nachlesen.
Mit Perl kann man sehr gut Textdateien verarbeiten. Dafür wurde Perl
auch geschaffen. Da Du es ja genau dafür nutzt, solltest Du Perl und
Python auf dieser Ebene vergleichen.
Kannst du deine Anforderungen mit Python genauso effektiv umsetzen? Wie
viel der Perl Funktionalität nutzt Du?
Ich persönlich nutze Perl für verschiedene Gelegenheiten. Ich rufe sogar
Perl aus C/C++/Objective-C/Java Programmen auf um mir die aufwendige
Implementierungen zu sparen.
Grüsse
> "altbackenes Image" von Perl? Ist das deine persönliche Meinung> oder behauptet es nur jemand in deinem Umfeld, der die Sprache> vielleicht überhaupt nicht kennt?
Du hast es richtig geahnt: Das beahupten Leute in meinem Umfeld.
Mindestens einer davon kennt Perl mit Sicherheit sehr gut.
> Kannst du deine Anforderungen mit Python genauso effektiv umsetzen?
Noch nicht, ich muss Python erst lernen. Aber da komme ich langfristig
warscheinlich sowieso nicht drum herum, weil mein Chef Python liebt.
Dieses Webserver Projekt werde ich wohl nicht mehr ändern (never change
a running System). Die Überlegung zum Wechsel bezieht sich eher auf
künftige Projekte, wo ich eigene Anwendungsspezifische Pre-Compiler
benötige.
Stefan Frings schrieb:> Perl erfüllt seinen Job an dieser Stelle einwandfrei.> Nur ist es noch Zeitgemäß?
Es funktioniert, mehr muß doch kein Anwender deiner Software nicht
wissen. Das Script selber muß er nach deiner Aussage weder ansehen, noch
überhaupt wissen, wie es funktioniert.
Stefan Frings schrieb:> Würdet ihr lieber Perl Scripte oder Python Scripte verwenden?
Für Windows-Nutzer sind sowohl Perl als auch Python ein pain-in-the-ass,
da weder Windows-Standard, noch irgendwie installiert. Da wäre eine
kompilierte .exe das Mittel der Wahl.
Oliver
Oliver schrieb:> Für Windows-Nutzer sind sowohl Perl als auch Python ein pain-in-the-ass,> da weder Windows-Standard, noch irgendwie installiert. Da wäre eine> kompilierte .exe das Mittel der Wahl.
naja, man kann einfach die Perl.exe dazulegen und schon geht es.
> Da wäre eine kompilierte .exe das Mittel der Wahl.
Ja, aber die fuinktioniert dann nicht unter Linux. Die Installation von
Strawberry Perl ist jedoch ein Kinderspiel, deswegen hatte ich Perl
gewählt.
Ich will aber auch nicht zur Installation von Perl zwingen, wenn das
veralteter Käse ist (was ich nur vermute).
Braucht man wirklich nur die perl.exe?
Unter Linux sind sowohl Perl als auch Python in der Regel
vorinstalliert. Auch MAC OS enthält beide Sprachen standardmäßig, soweit
ich weiss. Sind also nur die Windows User genervt.
Ist Python DER Nachfolger von Perl, oder ist das Quatsch?
> weil mein Chef Python liebt
Ist zwar kein rationales Argument aber für dich in Stein gemeisselt. ;-)
Kenne ich auch. :-P
> Die Überlegung zum Wechsel bezieht sich eher auf künftige Projekte
Dann kannst Du dir natürlich die nötige Funktionalität nach deinen
Vorstellungen Implementieren. Mach dich über vorhandene
Module/Bibliotheken schlau. Da sind bestimmt einige Interessante für
dich dabei.
Grüsse
Stefan Frings schrieb:> Ist Python DER Nachfolger von Perl, oder ist das Quatsch?
Nein, beide sind reichlich eigenständig nebeneinander. Ich benutze
beides, wobei ich Perl zugegebenermaßen viel besser kenne als Python
und daher in den meisten Fällen die jeweilige Aufgabe damit schneller
erledigt habe. Für den Großteil der Aufgaben sind beide meist
gleichermaßen brauchbar.
Python ist etwas für Leute, die bei der Perl-Syntax einen Knoten im
Kopf bekommen und stattdessen kein Problem haben, Leerzeichen als
signifikante Elemente einer Programmiersprache zu akzeptieren. :-))
Da du ja offensichtlich mit der Perl-Syntax keine Problem hast, spielt
dieser Teil jedoch für dich keine Geige.
Der einzig pragmatische Grund, der in deinem Fall für Python spricht
ist, dass es irgendeine Möglichkeit gibt, aus einem Python-Script
ein self contained Windows-.exe zu basteln, mit dem du deine
Windowsianer beglücken kannst, ohne dass sie ein komplettes Python
erst installiert haben müssen. Für Perl ist mir etwas Vergleichbares
gerade nicht bekannt.
> Ist Python DER Nachfolger von Perl, oder ist das Quatsch?
Nein, Ja
Perl wurde als Tool zur einfachen Auswertung von Reporting files wie
System Logging Dateien entwickelt. Die aktuellen Versionen wurden dann
erweitert.
Python ist ein Programmiersprache wie C/C++/Java/….
Nur die Fantasie/Zeit/Kosten des Softwareentwicklers begrenzt deren
Einsatzbereich. ;-)
> stattdessen kein Problem haben, Leerzeichen als signifikante Elemente einer
Programmiersprache zu akzeptieren. :-))
Dafür hat man TABS als Teil des Syntax. Da kann man nur beten, dass
einem nicht die Formatierung flöten geht.
Grüsse
Wenn man dem Tiobe-Index glauben darf (ist natürlich auch nur eine von
vielen Statistiken), kommt Perl tatsächlich so langsam aus der Mode
zugunsten von Python, Ruby, Lua usw.:
http://www.tiobe.com/index.php/paperinfo/tpci/http://www.tiobe.com/index.php/paperinfo/tpci/Perl.htmlhttp://www.tiobe.com/index.php/paperinfo/tpci/Python.html
Das heißt aber noch lange nicht, dass man es nicht mehr benutzen sollte,
denn weiterentwickelt wird es nach wie vor.
In Python lassen sich die meisten Dinge ähnlich elegant realisieren wie
in Perl. Dabei ist die Python-Syntax weniger "unix-like", was für viele
Neueinsteiger als Vorteil gesehen wird. Aber nur wegen der Syntax und
weil Python (22 Jahre) ein wenig jünger als Perl (26 Jahre) ist, würde
dafür keine bestehenden Entwicklungen über den Haufen schmeißen.
Um bei deinem Web-Server-Projekt den Windows-Usern nicht die Installa-
tion von zusätzlichen Tools zumuten zu müssen, könntest du dein Konver-
tierungsskript auch in Bash schreiben. Die Bash ist m.W. beim AVR-GCC-
Paket für Windows mit dabei und ist auf Linux-PCs und Macs sowieso
vorhanden.
Die Bash liegt altersmäßig zwischen Perl und Python und ist laut
Tiobe-Index in den letzten Jahren ganz stark im Kommen:
http://www.tiobe.com/index.php/paperinfo/tpci/Bash.html ;-)
Ich benutze auf Arbeit perl2exe, ist zwar nicht kostenlos (125 Euro oder
so) macht aber genau was Du braucht, eine exe für Computer auf denen
kein Perl läuft. Bei uns war das Problem, dass ein anderes
Programmpaket bereits ein kastriertes Perl mitgebracht hat und bei
paralleler Installation von Strawberry Perl die Arbeit verweigerte.
Diese Probleme zu lösen wäre sicherlich teurer geworden (Zeitaufwand)
als Perl2exe zu kaufen.
Jörg
Joerg Wolfram schrieb:> Ich benutze auf Arbeit perl2exe, ist zwar nicht kostenlos (125 Euro oder> so) macht aber genau was Du braucht, eine exe für Computer auf denen> kein Perl läuft. Bei uns war das Problem, dass ein anderes> Programmpaket bereits ein kastriertes Perl mitgebracht hat und bei> paralleler Installation von Strawberry Perl die Arbeit verweigerte.> Diese Probleme zu lösen wäre sicherlich teurer geworden als Perl2exe.
wie schon oben geschrieben, kann man die perl.exe einfach mit ins
verzeichniss legen. So machen ich das immer.
Danke für eure Antworten.
Ich werde mal versuchen, einfach die perl.exe mit ins Projekt zu packen.
Da mein Script keine Module verwendet, klingt das vielversprechend.
Ich gehe gerade ein Python Tutorial durch - nur so aus neugier. Am
Anfange dachte ich noch "schön, endlich keine Klammern mehr tippen".
Aber inzwischen erinnere mich an fehlerhafte Java und C++ Konstrukte,
die gerade deswegen nicht richtig funktionierten. Beispiel gefällig?
1
for (int i=0; i<10; i++)
2
j=i+100;
3
System.out.println(j);
Python wäre hier so nett, sich an der Einrückung zu orientieren. Aber
wer manchmal Klammer falsch setzt, der wird auch bei Einrückungen Fehler
machen, fürchte ich.
Damit gewinnt man wohl nichts, außer ein paar Tastenanschläge zu sparen.
Die Art und Weise wie Python Objekte behandelt geht ja gar nicht! Da
kann ich ja gleich in C programmieren.
Insgesamt kommt mir die Sprache noch mehr "Quick and Dirty" vor, als
Java. Beispiel gefällig?:
1
class Auto:
2
raeder=4
3
def klaue_rad(self):
4
self.raeder-=1
5
6
a=Auto()
7
a.pommes="3 Tüten"
Wieso zum Henker kann ich dem Auto drei Tüten Pommes unterjubeln ohne
dass ein entsprechendes Attributes deklariert ist? Das ist doch Kacke,
das provoziert doch Fehler ohne Ende. Der Intepreter merkt ja nichtmal
Tippfehler (z.B. räder statt raeder). Und Kapselung war den Python
leuten wohl auch so fremd, dass sie es einfach mal weg gelassen haben
(von wegen private Attribute).
Ich bleibe bei Perl, Python ist Käse. Früher war alles besser :-)
Stefan Frings schrieb:> Wieso zum Henker kann ich dem Auto drei Tüten Pommes unterjubeln ohne> dass ein entsprechendes Attributes deklariert ist?
Das kannst du doch bei einem realen Auto auch, wenn du damit in den
Drive-In fährst. Und das, obwohl die wenigsten Autos einen speziellen
Pommestütenhalter eingebaut haben ;-)
Viele Python- und Ruby-Programmierer empfinden dieses "Open-Class"-
Konzept nicht als Nachteil, sondern als Vorteil. Siehe auch
http://en.wikipedia.org/wiki/Monkey_patch
Ich selber mache von dieser Möglichkeit auch nur selten Gebrauch, aber
gerade beim Debuggen ist sie oft eine große Hilfe, da man einer Klasse
oder einem Objekt nachträglich nicht nur Membervariablen, sondern auch
Memberfunktionen hinzufügen kann. Dazu möchte ich aber nicht im Biblio-
thekscode herumpfuschen.
> Der Intepreter merkt ja nichtmal Tippfehler (z.B. räder statt raeder).
Ist das nicht bei den meisten Skriptsprachen so? Man verzichtet halt auf
die meisten Deklarationen (was weniger stupide Tipparbeit bedeutet),
verliert aber auf der anderen Site auch die Redundanz, die zur frühzei-
tigen Aufdeckung von Programmierfehler beitragen könnte.
Wie sieht denn das in Perl aus? Da kann man doch mit Datentypen und
Variablennamen auch beliebig viel Schindluder treiben, oder?
Bei der Programmierung wenig komplexer Tools (wie bspw. deinem HTML-
nach-C-Konverter) sind meist weniger Restriktionen besser als mehr, weil
man dadurch schneller zu einem lauffähigen Ergebnis kommt. Große
Anwendungen hingegen werden aus gutem Grund seltener in Python, Ruby
oder Perl, sondern meist in C++ oder Java implementiert. Ich finde es
schön, dass es beide Alternativen zum Aussuchen gibt :)
Es gibt übrigens auch Programmiersprachen, die die Vorteile von geringer
Redundanz im Quellcode (wenig Deklarationen u.ä.) mit denen einer sehr
strengen Compilezeitprüfung verbinden. Haskell gehört beispielsweise
dazu. Haskell-Quellcode ist oft ähnlich kurz wie entsprechender Python-
oder Perl-Code. Trotzdem bleiben nach erfolgreicher Kompilierung i.Allg.
deutlich weniger unentdeckte Fehler übrig als bspw. in Java oder C#.
> Früher war alles besser :-)
Fast alles ;-)
Wenn man perl gewohnt ist, wirkt Python schon oft sehr geschwätzig und
einengend. unter diesem Aspekt ein wenig wie C vs. Pascal. Das hat so
seine Vor- und Nachteile.
perl hat schon eine starke angediegene Tendenz zum write-only-Code.
Python sträubt sich dagegen etwas mehr.
Es bleibt im Wesentlichen Geschmackssache.
+1 für perl. Und vi ;)
Leider reicht es wohl nicht, nur die perl.exe ins Projekt zu kopieren
(zumindest bei Strawberry Perl). Aber das war ja gar nicht mein
Haupt-Anliegen.
Ich habe nun verstanden, dass ich Perl und Python als Alternativen
betrachten kann. Perl ist nicht veraltet.
Sehr lustig finde ich, wie weit unten PL/SQL steht. Das ist zwar nicht
mein Haupt-Arbeitsmittel aber zweifellos unverzichtbar an meinem
Arbeitsplatz. ABer zurück zum Hobby:
> Wie sieht denn das in Perl aus? Da kann man doch mit Datentypen> und Variablennamen auch beliebig viel Schindluder treiben, oder?
Ja sicher. Ich hatte gehofft, dass Python sich hier "besser" verhält,
wobei ich alles als besser empfinde, was weniger Magie im Hintergrund
betreibt. Mit C, C++ und Java fühle ich mich deutlich wohler. Wobei ich
die "Magie" von Java (Garbage Collector) schon grenzwertig finde.
Fazit: Es scheint keinen vernünftigen Grund zu geben, von Perl auf
Python umzusteigen.
Yalu X. schrieb:>> Der Intepreter merkt ja nichtmal Tippfehler (z.B. räder statt raeder).> Ist das nicht bei den meisten Skriptsprachen so? [...]> Wie sieht denn das in Perl aus?
By default auch in Perl, aber jedes Perl-Programm, das nicht nur
direkt auf der Kommandozeile mit -e eingegeben oder fix in /tmp
geschrieben wird, hat als erstes wohl stehen:
use strict;
use warnings;
“use strict” bewirkt dabei einen Compilerfehler, wenn man versucht,
eine nicht explizit deklarierte Variable anzulegen.
Dadurch hat man, wenn's schnell gehen soll (und kurzlebiger write-only
code ist), die volle Flexibilität, aber trotzdem die Möglichkeit,
durch den Compiler auf saubere Deklaration achten zu lassen.
Aber das nur am Rande. Ich denke, dass die eigentliche Programmier-
sprache für den TE nicht entscheidend ist, sondern eher der Weg, wie
er das alles bequem für seine Nutzer verpacken kann. Unleserliche
Programme kann man sowieso in jeder Programmiersprache schreiben,
oder mit anderen Worten: “Real programmers can write FORTRAN in any
language.” ;-)
Stefan Frings schrieb:> Hallo,>> in meinem Webserver Projekt (http://stefanfrings.de/avr_io/index.html)> übersetze ich statische HTML Dateien und Bilder in C-Quelltext (nämlich> byte-arrays) mit Hilfe eines Perl Scriptes.
OK, soweit, so einfach.
[...]
> Nun haftet Perl ein etwas altbackenes Image an, deswegen überlege ich,> ob ich in künftigen Projekten besser einen moderneren Script Interpreter> verwenden sollte. Perl erfüllt seinen Job an dieser Stelle einwandfrei.> Nur ist es noch Zeitgemäß?
Ummm, wie jetzt?
Und ich dachte Modeerscheinungen gäbe es nur in, nun ja, der Modewelt?
Wegen der Mode die Programmiersprache zu wechseln ist ganz grober Unfug.
Nebenbei, Perl 6 wird hypermodern sein, wenn es denn mal fertig wird ;-)
[...]
> Mir fällt da spontan Python als Alternative ein.>> Würdet ihr lieber Perl Scripte oder Python Scripte verwenden?
Weder noch. Für beides muss ich irgendwelche zusätzlichen Dinge
installieren um ganz und gar simple Dinge (und nur im Buildprozess!) tun
zu können. Und Python, naja, ist wohl was auf Englisch "aquired taste"
genannt wird, signifikanter Whitespace, was muss man rauchen um auf so
eine Idee zu kommen?
Um auch etwas konstruktives zu sagen: Du hast scheinbar sowieso schon
einen C-Compiler.
Ein Tool um Binärdaten in Textdateien, enthaltend C-Arrays, zu
konvertieren sollte in C ziemlich simpel und sogar halbwegs portabel zu
schreiben sein. Das kannst Du dann von make am Anfang erzeugen lassen
und dann zur Umwandlung von HTML und Bildern in C-Code benutzen - ist
ein durchaus übliches Verfahren.
Etwas unhandlich wird das nur wenn Du mit Cross-Compilern herummachst,
wovon ich nicht ausgehe.
Jasch schrieb:> Und Python, naja, ist wohl was auf Englisch "aquired taste"> genannt wird, signifikanter Whitespace, was muss man rauchen um auf so> eine Idee zu kommen?
Python hat die Quellcodestrukturierung mittels Einrückung nicht
"erfunden". Die Idee wurde bereits 1965 in dem Artikel "The Next 700
Programming Languages" von P. J. Landin erstmals veröffentlicht.
Mittlerweile wird dieses Konzept von immer mehr Programmiersprachen
umgesetzt. Beispiele gibt es hier:
http://en.wikipedia.org/wiki/Off-side_rule
Einige der genannten Sprachen folgen allerdings auch Landins Vorschlag,
alternativ eine Strukturierung durch konventionelle Methoden wie
Interpunktion zuzulassen. So können bspw. in Haskell alternativ (oder
zusätzlich) zur Einrückung wie in C geschweifte Klammern und Semikola
verwendet werden. Weil das aber äußerst hässlich aussieht und auch der
Lesbarkeit nicht sehr zuträglich ist, wird von dieser Möglichkeit
praktisch nur in automatisch generiertem Quellcode Gebrauch gemacht.
In Python gibt es diese Alternative nicht. Eine Spracherweiterung, die
mit
1
from __future__ import braces
aktiviert werden kann, erweckt zwar die Hoffnung, dass in einer der
nächsten Sprachversionen diese Alternative eingeführt werden könnte.
Diese Hoffnung wird aber sofort wieder zunichte gemacht, denn der obige
Import wird prompt mit
1
SyntaxError: not a chance
quittiert :D
Bleibt also nur, den Programmcode immer ordentlich einzurücken, dann
wird man die fehlenden Klammern auch nicht vermissen :)
Und komischerweise kritisieren die meisten, die die Strukturierung durch
Einrückung ablehnen, auch die konsequente Strukturierung durch Klammern,
wie sie in Lisp stattfindet.
Yalu X. schrieb:> In Python gibt es diese Alternative nicht.
Was praktisch einen "schnellen Einzeiler" (auf der Kommandozeile)
bis auf ganz wenige Trivialaufgaben unmöglich macht.
In Perl nutze ich diese Möglichkeit schon hin und wieder einmal,
wenn ich eine einmalige Aufgabe genau jetzt lösen muss, ohne dass
ich davon ausgehe, dass ich das morgen oder übermorgen nochmal
gebrauchen kann.
Patrick Dohmen schrieb:> Jasch schrieb:>> [..] signifikanter Whitespace, was muss man rauchen um>> auf so eine Idee zu kommen?>> Das make manual!?>> SCNR ;-)
Treffer, versenkt... ;-)
Yalu X. schrieb:> Jasch schrieb:>> Und Python, naja, ist wohl was auf Englisch "aquired taste">> genannt wird, signifikanter Whitespace, was muss man rauchen um auf so>> eine Idee zu kommen?>> Python hat die Quellcodestrukturierung mittels Einrückung nicht> "erfunden". Die Idee wurde bereits 1965 in dem Artikel "The Next 700> Programming Languages" von P. J. Landin erstmals veröffentlicht.
Oh Gott, Dinge die ich nicht wissen will, wird ja immer schlimmer.
Etwas Redundanz ist nicht immer schlecht, denke ich.
[...]
> Bleibt also nur, den Programmcode immer ordentlich einzurücken, dann> wird man die fehlenden Klammern auch nicht vermissen :)
Das ist überhaupt nicht der Punkt!
Python und Konsorten sind in der Hinsicht einfach nicht robust gegenüber
(nicht immer kontrollierbaren) Änderungen an scheinbar irrelevanten
Details - immer daran denken, Quellcode ist oft bloss "Text" und da
spielt die Anzahl führender Leerzeichen nach Ansicht Vieler keine
signifikante Rolle. Python-Code z.B. per Mail zu verschicken kann ganz
schön böse enden, während C-Code das vielleicht sogar überlebt.
Heh, gibt es eigentlich schon eine global gültige Einigung bezüglich der
Breite eines Tabs wenn er in Leerzeichen umgewandelt werden soll bzw.
umgekehrt? Nein? Sag ich doch.
> Und komischerweise kritisieren die meisten, die die Strukturierung durch> Einrückung ablehnen, auch die konsequente Strukturierung durch Klammern,> wie sie in Lisp stattfindet.
Ich nicht. Sind zwar viele Klammern aber so funktioniert Lisp nunmal.
Und ob man die Anzahl führender Leerzeichen in Zeilen ändert tangiert
Lisp-Code eben nicht, ebensowenig ob man das Programm einfach als eine
Zeile schreibt, grins.
Markus M. schrieb:> "altbackenes Image" von Perl? Ist das deine persönliche Meinung oder> behauptet es nur jemand in deinem Umfeld, der die Sprache vielleicht> überhaupt nicht kennt?
Die IT ist eine Mode Branche. Ich bleib bei den Klassikern wie dem
eleganten "kleinen Schwarzen" alias C und dem "grauen Sakko" alias JAVA.
Und für's grobe gibt's das klassische "Flanellhemd" alias Shell gewürzt
mit awk und sed.
Wir programmieren hauptsächlich in C/C++ mit Bevorzugung von C++, wenn
es das Zielsystem zulässt.
Für Tools zur Built-automatisierung, Datenkonvertierung,
Quellcodegenerierung und auch kleinere Anwendungen (Beispiel Remote
Update und Überwachung von Systemen) benutzen wir Python.
Ich habe mir vor der Entscheidung für Python viele Scriptsprachen
angeschaut. Obwohl mir die Leerzeichen als Syntaxelement erst unorthodox
erschien und ich die Freizügigkeit z.B. in Klassen direkt reinschreiben
zu dürfen als Risiko gesehen habe, gefiel mir die konsequente
Objektorientierung und die vielen bereits eingebauten und sonst
verfügbaren Bibliotheken.
Auch die Performance ist gut, wenn auch mit C++ nicht zu vergleichen.
Und dass man C++ sowohl einbinden als auch Python Code von C++ aufrufen
kann, hat so manches Test Framework vereinfacht und manches C++ Programm
mit Skripting versüßt.
Ich habe meine damalige Entscheidung nie bereut. Es sind viele gute
Tools entstanden, die in C++ 3 mal so lange gedauert hätten. Ein
Paradebeispiel ist ein Codegenerator, der beliebig komplexe und
geschachtelte UML State Machines in sauberen, human readable C++
Quellcode übersetzt. Allein was wir dadurch an Unit Tests sparen ist
enorm. Und für den funktionalen Test gibt es Python Test scripts, die
die Requirements durch Aufruf und Stimulierung des C++ automatisch
abtesten und einen schicken HTML Report erzeugen. Ich kann mir heute
keine bessere Scriptsprache vorstellen. Ich schaue mir viele Dinge an,
aber die Eleganz von Python (natürlich nur wenn man es diszipliniert
einsetzt) ist für mich ungeschlagen.
for i in range(1000):
print "I AM A PYTHON LOVER!"
Pfingstliche Grüße
Michael
> Heh, gibt es eigentlich schon eine global gültige Einigung bezüglich der> Breite eines Tabs wenn er in Leerzeichen umgewandelt werden soll bzw.> umgekehrt? Nein? Sag ich doch.
Wer Tabs benutzt ist selber Schuld an den auftretenden Problemen.
Man kann heute jeden Texteditor so einstellen, dass er Spaces statt Tabs
einfügt.
Man sollte ohnehin viel Gebrauch von Leerzeichen machen, um die
Lesbarkeit zu erhöhen und und Folge die Fehlerrate zu senken.
A=17
MyFirstName="Michael"
MyFavoriteLanguage="PYTHON"
B=19
sieht tabellarisch (ohne Tabs) einfach übersichtlicher aus und Fehler
gehen nicht im Zeichensalat unter.
A = 17
MyFirstName = "Michael"
MyFavoriteLanguage = "PYTHON"
B = 19
Die Idee, das Hilfsprogramm mit dem C Compiler zu erzeugen, klingt
erstmal gut. Sie scheitert aber daran, dass es ein Crss-Compiler für AVR
Mikrocontroller ist. Der kann keine Programme für Linux/Windows/Mac OS
erzeugen.
Unter Linux und Mac OS ist der C Compiler meist schon installiert, und
wenn nicht, dann sehr leicht installierbar. Unter Windows sieht das
schon ganz anders aus.
Wenn ich wüsste, wie man mit der Bash Shell Binärdateien in C-Quelltext
(Arrays von Bytes) übersetzen kann, dann würde ich das tun. Für Windows
würde ich dann ein Äquivalentes Basic Script schreiben.
Jasch schrieb:> [...]>> Mir fällt da spontan Python als Alternative ein.>>>> Würdet ihr lieber Perl Scripte oder Python Scripte verwenden?>> Weder noch. Für beides muss ich irgendwelche zusätzlichen Dinge> installieren um ganz und gar simple Dinge (und nur im Buildprozess!) tun> zu können. Und Python, naja, ist wohl was auf Englisch "aquired taste"> genannt wird, signifikanter Whitespace, was muss man rauchen um auf so> eine Idee zu kommen?
Ich habe nie verstanden, warum da so viele ein Problem damit haben. Hast
du einen so schlechten und inkonsistenten Einrückungsstil, daß das für
dich so problematisch ist? Wenn man richtig einrückt, passt doch alles
ganz automatisch.
Jasch schrieb:> Python und Konsorten sind in der Hinsicht einfach nicht robust gegenüber> (nicht immer kontrollierbaren) Änderungen an scheinbar irrelevanten> Details - immer daran denken, Quellcode ist oft bloss "Text" und da> spielt die Anzahl führender Leerzeichen nach Ansicht Vieler keine> signifikante Rolle. Python-Code z.B. per Mail zu verschicken kann ganz> schön böse enden, während C-Code das vielleicht sogar überlebt.
Wenn's bei C-Code die Einrückung durch ein schlechtes Mail-Programm
zerhackstückt hat, funktioniert er zwar evtl. noch, ist aber auch sehr
schlecht lesbar. Im Zweifelsfall schickt man's halt per Anhang.
> Heh, gibt es eigentlich schon eine global gültige Einigung bezüglich der> Breite eines Tabs wenn er in Leerzeichen umgewandelt werden soll bzw.> umgekehrt? Nein? Sag ich doch.
Also ein Argument für python. Wenn da einer anfängt, wild Tabs und
Leerzeichen zu mischen, bekommt er vom Interpreter eine Fehlermeldung,
bis er das behoben hat.
Stefan Frings schrieb:> Unter Linux und Mac OS ist der C Compiler meist schon installiert, und> wenn nicht, dann sehr leicht installierbar. Unter Windows sieht das> schon ganz anders aus.
Gleiches gilt aber auch für einen perl- oder python-Interpreter.
> Wenn ich wüsste, wie man mit der Bash Shell Binärdateien in C-Quelltext> (Arrays von Bytes) übersetzen kann, dann würde ich das tun. Für Windows> würde ich dann ein Äquivalentes Basic Script schreiben.
Also alles doppelt machen, damit man nix zusätzlich installieren muß?
Jasch schrieb:> Etwas Redundanz ist nicht immer schlecht, denke ich.
Was für Redundanz? Ich hab schon genügend Code gesehen, bei dem sich die
Struktur des Codes anhand der Einrückung ganz anders liest als anhand
der Klammern. Während der Programmierer eher die Einrückung zur
Erkennung nutzt, geht der C-Compiler aber ausschließlich nach den
Klammern. Deshalb bekomme ich in so einem Fall einfach nur verwirrenden
Code.
Bei Python ist die Einrückung gezwungenermaßen konsistent mit der
Codestruktur, was ich als großen Vorteil empfinde und nicht wie
scheinbar die meisten anderen als das große Ausschlusskriterium, die
Sprache überhaupt zu nutzen.
Stefan Frings schrieb:> Unter Linux und Mac OS ist der C Compiler meist schon installiert, und> wenn nicht, dann sehr leicht installierbar. Unter Windows sieht das> schon ganz anders aus.
Stimmt, aber für solche exotischen Entwicklerfeindlichen Plattformen g
kann man auch ein fertiges Kompilat des dann in C, C++, ... schreibbaren
Tools mitliefern.
> Wenn ich wüsste, wie man mit der Bash Shell Binärdateien in C-Quelltext> (Arrays von Bytes) übersetzen kann, dann würde ich das tun. Für Windows> würde ich dann ein Äquivalentes Basic Script schreiben.
Wie findet eigentlich die Umwandlung statt?
Wird der Input ohne jede Änderung als Array bereitgestellt um dann in
die Firmware gelinkt zu werden? Dann brauchst du eigentlich nichts außer
avr-objcopy:
Beispiel für Sound, ist aber egal was drin steckt:
durch das --rename-section .data=.text landen die Daten im Flash. Sollen
sie ins SRAM, einfach das Renaming weglassen.
Verwenden kannst du die Daten dann mit:
1
externuint8_t_binary_filename_extension_start[];
2
externuint8_t_binary_filename_extension_end[];
ggFs. um PROGMEM bzw. __flash ergänzt oder zumindest im Code
entsprechend verwendet.
Alles andere erledigt der Linker. Ich hab das oben als Array gemacht,
weil es so direkt geklappt hatte. Pointer wäre logischer, funktioniert
aber wenn ich mich recht entsinne nicht, weil die Indirektion eben nicht
sein darf. Also du erhältst zwei Symbole: _binaray_*_start und
_binary_*_end für jedes so eingelinkte objcopy-Ergebnis, wobei das *
sich nach dem Dateinamen richtet, mit nicht-C-Identifier-gerechten
Zeichen transformiert zu einem Unterstrich.
Stefan Frings schrieb:> Wenn ich wüsste, wie man mit der Bash Shell Binärdateien in C-Quelltext> (Arrays von Bytes) übersetzen kann, dann würde ich das tun.
Ich habe dein Perl-Skript makefsdata mal in ein Bash-Skript übersetzt.
Es ist nicht intensiv getestet, aber bis auf die Reihenfolge der
einzelnen Arrays scheint das gleiche Ergebnis herauszukommen.
Der Unterschied kommt daher, dass die Bash beim Durchwandern eines
Verzeichnisses die Dateinamen alphabetisch sortiert, Perl aber
offensichtlich nicht. Die Reihenfolge der Arrays in der verketteten
Liste und der Listenanker (HTTPD_FS_ROOT) sind daher ebenfalls anders,
aber in sich wieder konsistent.
In deinem Skript werden die Variablennamen aus den Dateinamen durch
Ersetzen von Slashes und Punkten durch Underscores generiert. In meinem
Bash-Skript werden zusätzlich auch Leerzeichen durch Underscores
ersetzt. Sonstige Sonderzeichen, die in Variablennamen nicht zulässig
sind, werden allerdings auch hier nicht berücksichtigt.
> Für Windows würde ich dann ein Äquivalentes Basic Script schreiben.
Da das Bash-Skript außer der Bash selber keine weiteren Unix-Tools
benötigt, müsste es bei Vorhandensein einer Bash ohne Änderungen unter
beliebigen Betriebssystemen laufen. Schau mal, ob das AtmelStudio die
Bash nicht vielleicht schon enthält. Bei WinAVR war sie jedenfalls noch
mit dabei.
Stefan Frings schrieb:> Die Idee, das Hilfsprogramm mit dem C Compiler zu erzeugen, klingt> erstmal gut. Sie scheitert aber daran, dass es ein Crss-Compiler für AVR> Mikrocontroller ist. Der kann keine Programme für Linux/Windows/Mac OS> erzeugen.
Verdammt, war ja eigentlich klar dass bei mikrocontroller.net eher ein
Szenario gemeint war wo es um Cross-Compiler geht. Tja, dann sieht es
finster aus, speziell für Windows, irgendwas muss man da halt
installieren.
Rolf Magnus schrieb:> Jasch schrieb:>> [...]>>> Mir fällt da spontan Python als Alternative ein.>>>>>> Würdet ihr lieber Perl Scripte oder Python Scripte verwenden?>>>> Weder noch. Für beides muss ich irgendwelche zusätzlichen Dinge>> installieren um ganz und gar simple Dinge (und nur im Buildprozess!) tun>> zu können. Und Python, naja, ist wohl was auf Englisch "aquired taste">> genannt wird, signifikanter Whitespace, was muss man rauchen um auf so>> eine Idee zu kommen?>> Ich habe nie verstanden, warum da so viele ein Problem damit haben. Hast> du einen so schlechten und inkonsistenten Einrückungsstil, daß das für> dich so problematisch ist? Wenn man richtig einrückt, passt doch alles> ganz automatisch.
Das hast Du falsch verstanden. Ich persönlich habe damit kein Problem,
auch weil es mein Editor praktisch automatisch für micht tut (All hail
Emacs!). Natürlich nicht für Python, da lässt sich das ja nicht
automatisieren(!).
Anders sieht das aus wenn ich Quelltext per Mail, in einem Post in
Usenet oder einem Forum oder sonstwie zu sehen bekomme. Ich habe
schlicht keine Ahnung welche perversen Transformation irgendeine
Suckware daran vorgenommen haben könnte - also wäre das alles per se
suspekt wenn die Blockstruktur nicht mit richtigen Tokens markiert ist.
> Jasch schrieb:>> Python und Konsorten sind in der Hinsicht einfach nicht robust gegenüber>> (nicht immer kontrollierbaren) Änderungen an scheinbar irrelevanten>> Details - immer daran denken, Quellcode ist oft bloss "Text" und da>> spielt die Anzahl führender Leerzeichen nach Ansicht Vieler keine>> signifikante Rolle. Python-Code z.B. per Mail zu verschicken kann ganz>> schön böse enden, während C-Code das vielleicht sogar überlebt.>> Wenn's bei C-Code die Einrückung durch ein schlechtes Mail-Programm> zerhackstückt hat, funktioniert er zwar evtl. noch, ist aber auch sehr> schlecht lesbar. Im Zweifelsfall schickt man's halt per Anhang.
Nein, falsch. Als Empfänger weist man seinen Editor an, die Einrückung
gemäß der eigenen Vorlieben wiederherzustellen. Geht für Python
natürlich nicht, prinzipbedingt.
>> Heh, gibt es eigentlich schon eine global gültige Einigung bezüglich der>> Breite eines Tabs wenn er in Leerzeichen umgewandelt werden soll bzw.>> umgekehrt? Nein? Sag ich doch.>> Also ein Argument für python. Wenn da einer anfängt, wild Tabs und> Leerzeichen zu mischen, bekommt er vom Interpreter eine Fehlermeldung,> bis er das behoben hat.
Ja, würde ich im Prinzip zustimmen. Bloss ist es in der Praxis so dass
a) Python Tabs akzeptiert (als 8 Spaces breit IMHO) und b) man anderen
Programmierern eher keine Vorschriften machen kann, diesbezüglich oder
in jeder anderen Hinsicht. ;-)
Sozusagen eine Frage der Interoperabilität.
[...]
> Jasch schrieb:>> Etwas Redundanz ist nicht immer schlecht, denke ich.>> Was für Redundanz? Ich hab schon genügend Code gesehen, bei dem sich die> Struktur des Codes anhand der Einrückung ganz anders liest als anhand> der Klammern.
Dave Jones würde sagen "Trap for young players". Ja, bin ich auch schon
drüber gestolpert, darum schätze ich Editoren die entsprechend der
Syntax automatisch einrücken können. Sieht es nicht so aus wie ich
erwarte - habe ich mich irgendwo vertippt.
Die Redundanz (wahrscheinlich ist das der falsche Begriff) ist übrigens
zwischen Einrückung und geschweiften Klammern. Naja, nicht wirklich, die
Klammern sind ja was in jedem Fall entscheidet.
@Malte: Vielen Dank für Deinen Tip mit objcopy. Ich brauche allerdings
noch ein Inhaltsverzeichnis, also eine Liste der Dateinamen zusammen mit
Zeigern auf die Dateien. Ansonsten gefällt mir Dein Ansatz prima, den
kann ich sicher woanders gebrauchen. Vielleicht tippe ich die Dateinamen
manuell ein und verweise dann auf die mit objcopy erzeugten Daten.
@Yalu: Da WinAVR (und die AVR Toolchain) eine Bash enthalten und die
gleiche Shell in Linux und Mac OS enthalten ist, gefällt mir dieser
Lösungsansatz ganz besonders.
Die Unterschiedliche Reihenfolge der Dateien und die etwas andere
Behandlung von Leerzeichen sind für das Projekt kein Problem. Denn die
Dateinamen in meinem Projekt enthalten keine Sonderzeichen. Ich staune
gerade, dass die Bash Dateien byteweise lesen kann. Bisher dachte ich,
dass es gerade daran scheitern würde.
Leider klappt es (noch) nicht unter Windows mit WinAVR:
C:\Dokumente und Einstellungen\Administrator\Eigene
Dateien\NET-IO-Modul_v2.11.1
0\v2.11.10 2013-03-30\src> sh bashmakefsdata
bashmakefsdata: shopt: globstar: unknown shell option name
bashmakefsdata: varnames: bad array subscript
Schade, diese Bash (v2.0.4 bäääh, ist ja uralt!) kann wohl nicht alles,
was wir brauchen.
Wenn ich die Ersetzung von Zeichen in Dateinamen und die
Ausschlussregeln für unerwünschte Dateien entferne, funktioniert das
Script prinzipiell. += gibt auch nicht, aber das leicht zu ersetzen.
Leider scheitert es an dem read Befehl. Die Version von WinAVR kann
nämlich keine Binärdaten lesen.
Aber das macht nichts, dafür haben wir ja objcopy, wie ich gerade
gelernt habe. Ich schreibe das Script so um, dass damit nur das
Inhaltsverzechnis erzeugt wird und auf die Daten referenziert wird, die
objcopy erzeugt.
Stefan Frings schrieb:> Ich staune gerade, dass die Bash Dateien byteweise lesen kann. Bisher> dachte ich, dass es gerade daran scheitern würde.
Es geht, allerdings musste ich eine ganze Weile herumfrickeln, um read
dazu zu bringen, wirklich jedes Zeichen ohne irgendwelche Konvertie-
rungen zu lesen. Mit -N1 (kleines 'n' richt nicht), -r, LC_ALL=C und
IFS= scheint es aber zu passen.
> bashmakefsdata: shopt: globstar: unknown shell option name
Das gibt es erst in Version 4 und erlaubt es, mit '**' bei der Filename-
Expansion auch Unterverzeichnisse mit einzubeziehen. Alternativ könnte
man es auch wie in deinem Perl-Skript machen oder ein externes Tool wie
find (sofern verfügbar) verwenden.
> bashmakefsdata: varnames: bad array subscript
Das kommt wahrscheinlich vom Array-Index -1 (Zugriff auf das letzte
Array-Element, ebenfalls ab Version 4) in der drittletzten Zeile. Du
kannst ihn einfach durch $i ersetzen, da i von der letzten Schleife noch
den passenden Wert enthält.
Version 2.0.4 hört sich aber so alt an, dass da durchaus noch ein paar
andere Dinge fehlen könnten.
Stefan Frings schrieb:> Leider scheitert es an dem read Befehl. Die Version von WinAVR kann> nämlich keine Binärdaten lesen.
Falls die Installation ein Hexdump-Tool (z.B. od) enthält, könnte man
dieses die binären Bytes in Hex-Zahlen konvertieren lassen, die dann
problemlos mit read gelesen werden können. Die Formatierung mit
printf braucht man dann auch nicht, da man zwischen den gelesenen
Hex-Zahlen nur noch die Kommata und Linefeeds einfügen muss.
Ansonsten führt Google mit den Stichworten
bash read binary file
zu weiteren Vorschlägen.
> Aber das macht nichts, dafür haben wir ja objcopy
Oder so :)
Jasch schrieb:> Ja, würde ich im Prinzip zustimmen. Bloss ist es in der Praxis so dass> a) Python Tabs akzeptiert (als 8 Spaces breit IMHO) und b) man anderen> Programmierern eher keine Vorschriften machen kann, diesbezüglich oder> in jeder anderen Hinsicht. ;-)>> Sozusagen eine Frage der Interoperabilität.
Stimmt, aber wenn man als Programmierer Python ernst nimmt, so liest man
die Style Guides,
Hier zB.:
http://www.python.org/dev/peps/pep-0008/#code-lay-out> darum schätze ich Editoren die entsprechend der> Syntax automatisch einrücken können.
Eclipse:
1
def schauen_wir_mal():
2
|<== Automatische Einrückung
3
4
while(True):
5
|<== Automatische Einrückung
6
if(False):
7
|<== Automatische Einrückung
8
else: <== Automatische Ausrückung
9
|<== Automatische Einrückung
Ich gebe zu das ich vor zwei oder drei Jahren die gleichen Vorbehalte
gegenüber Python hatte, aber nun schreibe ich eine Menge kleinerer
Programme (für die ich früher den C-Compiler angeworfen hatte) in Python
in ca. 1/3 der Zeit. Doxygen geht auch, alles ist prima. ;-)
Meine Meinung:
a.) Wenn man Cross-Compiliert, hat man auch einen Host-Compiler
b.) Mit modernem C++ ist man praktisch genau so schnell, wie mit
einer Script-Sprache.
c.) Wenn man eine Script-Sprache für den Build-Prozess benötigt, kommt
es eben auf die Philosophie an, was man auf dem Host voraussetzt. Wenn
man unabhängig bleiben will, setzt man nur sehr wenig voraus.
d.) Sprachen wie Python sind zu "fett". Alleine die verschiedenen
Versionen und die verschiedenen Pakete.
Daher gehe ich inzwischen so vor, das bei C++-Projekten die Helfer auch
in C++ geschrieben werden. Geht erstaunlich gut. Klar, am Anfang muss
man sich mal eine kleine Lib mit Helfern bauen. Wenn ich z.B. eine Datei
speichern möchte, heisst das einfach save(filename, content). Ich will
dann nicht mit Streams rummachen. Die Funktion save() selbst ist
trivial. So sammeln sich im lauf der Zeit nützliche, kleine, dummer
Helfer. Und schon ist man in C++ genauso schnell wie in Script-Sprache
XYZ.
Ansonsten, Lua wurde schon genannt. Kompiliert mit jedem
ANSI-C-Compiler, ist klein und schnell, und kann problemlos beim Build
erzeugt werden.
Jasch schrieb:> Das hast Du falsch verstanden. Ich persönlich habe damit kein Problem,> auch weil es mein Editor praktisch automatisch für micht tut (All hail> Emacs!). Natürlich nicht für Python, da lässt sich das ja nicht> automatisieren(!).
Warum sollte das nicht gehen? Die Zeile vor einer eingerückten endet
immer mit einem Doppelpunkt. Und eine Einrückungsebene zurück geht man
halt mit einer entsprechenden Tastenkombination oder zur Not mit einer
(an der Stelle eh sinnvollen) Leerzeile. Das ist dann auch nicht mehr zu
tippen als mit geschweiften Klammern.
Jasch schrieb:>> Also ein Argument für python. Wenn da einer anfängt, wild Tabs und>> Leerzeichen zu mischen, bekommt er vom Interpreter eine Fehlermeldung,>> bis er das behoben hat.>> Ja, würde ich im Prinzip zustimmen. Bloss ist es in der Praxis so dass> a) Python Tabs akzeptiert (als 8 Spaces breit IMHO)
Ja, tatsächlich. Mir wäre es lieber, wenn eine Mischung aus Tabs und
Spaces grunsätzlich zum Fehler führt, und ich dachte auch, das sei so.
Hab's nur nie gemerkt, weil ich selbst keine Tabs verwende. Einen Tab
fix als 8 Zeichen zu interpretieren, halte ich für eher unsinnig. Das
heißt, daß die Umsetzung in Python nicht so gut ist, wie ich eigentlich
erwartet hätte, aber das Konzept allgemein finde ich trotzdem sinnvoll.
> und b) man anderen Programmierern eher keine Vorschriften machen kann,> diesbezüglich oder in jeder anderen Hinsicht. ;-)
Man muß ja keine Vorschriften bezüglich dem konkreten Einruckungsstil
machen, sondern nur, daß er halt immer gleich ist.
Jasch schrieb:>> Was für Redundanz? Ich hab schon genügend Code gesehen, bei dem sich die>> Struktur des Codes anhand der Einrückung ganz anders liest als anhand>> der Klammern.>> Dave Jones würde sagen "Trap for young players". Ja, bin ich auch schon> drüber gestolpert, darum schätze ich Editoren die entsprechend der> Syntax automatisch einrücken können. Sieht es nicht so aus wie ich> erwarte - habe ich mich irgendwo vertippt.
Das ergibt sich ja bei Python gar nicht, weil die Einrückung Teil der
Syntax ist. Es sieht für den Interpreter immer genau so aus wie für
dich.
Jasch schrieb:> Die Redundanz (wahrscheinlich ist das der falsche Begriff) ist übrigens> zwischen Einrückung und geschweiften Klammern. Naja, nicht wirklich, die> Klammern sind ja was in jedem Fall entscheidet.
Ja, genau das meinte ich. Deshalb ist es keine Redundanz. Es sieht nur
redundant aus, aber der Compiler meckert nicht, wenn's nicht
zusammenpasst.
Geheilter schrieb:> Meine Meinung:>> a.) Wenn man Cross-Compiliert, hat man auch einen Host-Compiler
Das dürfte unter Linux der Normalfall sein, aber Windows-Benutzer müssen
sich das erst immer noch umständlich extra runterladen und installieren.
> b.) Mit modernem C++ ist man praktisch genau so schnell, wie mit> einer Script-Sprache.
Finde ich nicht. Files parsen und ähnliches, also vor allem
Stringhandling und reguläre Ausdrücke finde ich mit einer Skriptsprache
einfacher. C++ hat gerade erst eingebauten Support für reguläre
Ausdrücke bekommen. Wenn man also nicht unbedingt die aktuellsten
C++-Compiler voraussetzen will, muß man zusätzlich noch boost oder so
installieren, um reguläre Ausdrücke zu haben. Ähnliches gilt selbst
schon für so einfache Sachen wie z.B. Verzeichnisse.
> d.) Sprachen wie Python sind zu "fett". Alleine die verschiedenen> Versionen und die verschiedenen Pakete.
Alles wesentliche, was man für die beim Buildprozess nötigen Dinge
braucht, ist schon dabei, da braucht man keine Pakete. Und bei C++
gibt's nicht nur verschiedene Versionen, sondern vor allem noch ganz
unterschiedliche APIs je nach System. Es sei denn, man installiert sich
zusätzliche Pakete...
Rolf Magnus schrieb:>> Ja, würde ich im Prinzip zustimmen. Bloss ist es in der Praxis so dass>> a) Python Tabs akzeptiert (als 8 Spaces breit IMHO)>> Ja, tatsächlich. Mir wäre es lieber, wenn eine Mischung aus Tabs und> Spaces grunsätzlich zum Fehler führt, und ich dachte auch, das sei so.
Da muss man zwischen Python 2 und Python 3 unterscheiden. Python 3
entspricht dabei eher deinen (und auch meinen) Vorstellungen, Python 2
nicht so sehr.
Python 2:
Ein Tab wird wie ein Sprung zur nächsten Spalte, die ein Vielfaches von
8 ist, behandelt. Wenn man also im Editor den Tabstop-Parameter auf 8
setzt und das Programm optisch richtig eingerückt ist, ist auch der
Compiler einverstanden. Wenn man als Tabstop-Parameter einen anderen
Wert als 8 einstellt, sieht der Code im Editor evtl. nach Kraut und
Rüben aus, wird aber trotzdem richtig ausgeführt.
Python 3:
Alle Zeilen eines Blocks müssen mit exakt der gleichen Kombination aus
Tabs und Leerzeichen beginnen. Ein untergeordneter Block (nach einem if,
while o.ä.) muss mit dem gleichen Whitespace wie der übergeordnete Block
plus mindenstens einem weiteren, an der rechten Seite hinzugefügten
Whitespace-Zeichen beginnen.
Dadurch ist gewährleistet, dass korrekter Code im Editor unabhängig von
der Tabstop-Einstellung immer konsistent aussieht, d.h.
- alle Zeilen eines Block sind gleich weit eingerückt und
- ein untergeordneter Block ist tiefer eingerückt der übergeordnete.
Folgende Einrückungen sind in Python 2 und 3 korrekt
(␣ = Leerzeichen, ⇥ = Tab):
1
␣ ⇥␣if a<0:
2
␣ ⇥␣␣ ⇥a = 0
3
␣ ⇥␣␣ ⇥b += 1
Folgende Einrückungen sind nur in Python 2 korrekt:
1
␣ ⇥␣if a<0:
2
⇥ ⇥a = 0 # Leerzeichen aus der Zeile darüber fehlen
3
␣ ⇥␣␣␣␣␣␣␣␣b += 1 # Tab wurde durch Leerzeichen ersetzt
Wird die obige Regel nicht korrekt umgesetzt, meckert der der Python-3-
Compiler
1
TabError: inconsistent use of tabs and spaces in indentation"
Python-Code, der nach den Python-3-Regeln richtig eingerückt ist, ist es
auch nach den Python-2-Regeln, umgekehrt aber nicht unbedingt.
Die Regeln in Python 3 sind strenger, aber logischer, da sie nicht von
einer angenommenen Tab-Weite abhängen.
Noch besser wäre es, die Tabs und damit sämtliche Einrückungsverwirrung
komplett aus der Sprachdefinition von Python zu verbannen. Vielleicht
kommt das ja in Python 4 :)
Rolf Magnus schrieb:> Natürlich nicht für Python, da lässt sich das ja nicht>> automatisieren(!).>> Warum sollte das nicht gehen?
Beim Neuschreiben geht's. Wenn man aber Teile per copy & paste
woanders neu einrücken muss, geht es prinzipbedingt eben nicht
mehr automatisch.
Es ist schon seltsam, dass vermutlich jeder über Programmiersprachen
wie whitespace lächelt, aber eingefleischte Python-Programmierer
plötzlich signifikante Leerräume als etwas Sinnvolles reklamieren,
wenn es um "ihre" Sprache geht, während völlig selbstverständlich
die Syntax aller anderer Programmiersprachen natürlich großer Mist
ist.
Nein, ich komme mit Python so zurecht (mit Perl deshalb besser, weil
ich es länger kenne), aber auch wenn ich es benutzen kann (und manche
Sachen darin nicht unpraktisch finde), so würde ich trotzdem nicht
auf die Idee kommen, das dämliche Konzept der signifikanten Leerzeichen
irgendwie gut zu finden. (Das der signifikanten TABs in make auch
nicht, aber dass die Mist sind, wusste man zumindest bei der Schöpfung
von Python bereits, man hätte den Fehler also nicht wiederholen
brauchen, statt ihn mit den Leerzeichen auf eine neue Stufe zu heben.)
Wenn mir ein C-Programm zu verhunzt aussieht, schicke ich es durch
indent oder den Emacs, bis es meinen Lesegewohnheiten entspricht.
Wenn mir ein Python-Programm zu verhunzt aussieht (und wir sind uns
einig, dass man verhunzte Programme in jeder Programmiersprache
hinbekommt), dann bleibt mir nur, es wegzuschmeißen.
Für den TE ist es aber vermutlich in der Tat die sinnvollste Variante,
mit objcopy aus den Binärdaten C-Code zu erzeugen und dann mit
normalen Shell-Bordmitteln ein zugehöriges Inhaltsverzeichnis.
Stefan Frings schrieb:> in meinem Webserver Projekt (http://stefanfrings.de/avr_io/index.html)> übersetze ich statische HTML Dateien und Bilder in C-Quelltext
Ich mache es auch so, halt mit einem kleinen selbstgeschriebenen
C-Tool. Eine Handvoll Makros für "<script type...>" etc. Das Tool
ist ins makefile eingebunden und erzeugt mir einfache Strings.
Sehr praktisch.
Grund: C kann ich - mit Perl habe ich noch nichts zu tun gehabt ;)
Ist zwar etwas offtopic, aber da der TE ja inzwischen für ihn zufrieden-
stellende Lösungen sein Problems erhalten hat, möchte ich doch noch
einmal kurz das Whitespace-Thema aufgreifen:
Jörg Wunsch schrieb:> Es ist schon seltsam, dass vermutlich jeder über Programmiersprachen> wie whitespace lächelt,
Was gibt es an Whitespace zu belächeln? :-/ ¹
> aber eingefleischte Python-Programmierer plötzlich signifikante> Leerräume als etwas Sinnvolles reklamieren, wenn es um "ihre" Sprache> geht, während völlig selbstverständlich die Syntax aller anderer> Programmiersprachen natürlich großer Mist ist.
Naja, in den meisten Programmiersprachen sind Leerräume signifikant.
So auch bspw. in C:
1
intakt(charlotte);// mit Spaces: Funktionsdeklaration
2
intakt(charlotte);// ohne Spaces: Funktionsaufruf
Ok, da kann man den Unterschied zwischen den beiden Zeilen noch gut
erkennen. Aber was ist hiermit:
1
voidprintUpToEightSpaces(intn){
2
// woran sieht man, dass der folgende String tatsächlich aus 8
3
// Leerzeichen und nicht etwa aus einem Tab besteht?
4
staticcharspcs[]=" ";
5
6
printf(spcs+sizeofspcs-1-n);
7
}
Auch der Linefeed (ein weiteres Whitespace-Zeichen) ist in vielen
Sprachen signifikant. Immerhin ist der Linefeed i.Allg. leicht als
solcher zu erkennen (kann allerdings auch mit dem Umbruch überlanger
Zeilen durch den Editor verwechselt werden).
In Python gibt es eben zusätzlich noch signifikanten Leerraum am
Zeilenbeginn. Böse wird es aber erst dann, wenn man Spaces unüberlegt
mit Tabs vermischt. Unüberlegte Tabs sind aber generell eine potentielle
Fehlerquelle (s. zweites C-Beispiel oben). Also sollte man doch eher
über die Tabs als über die signifikante Quellcodeeinrückung schimpfe :)
> (Das der signifikanten TABs in make auch nicht, […]
An Make stört mich nicht die verpflichtende Einrückung bei den Regeln,
sondern die Vorgabe, dass diese Einrückung mit einem Tab zu erfolgen
hat. Nachdem ich meinem Editor jegliche Verwendung von Tabs abgewöhnt
habe, muss ich nun in Make immer ein sehnenscheidenentzündungsförderndes
^V<TAB> tippen :-/
——————————
¹) s/:\(.\)\//;\1)/
Yalu X. schrieb:> Nachdem ich meinem Editor jegliche Verwendung von Tabs abgewöhnt> habe, muss ich nun in Make immer ein sehnenscheidenentzündungsförderndes> ^V<TAB> tippen :-/
Falscher Editor. :-)
Jörg Wunsch schrieb:> Falscher Editor. :-)
Ja, so wird es wohl sein.
Vielleicht ist aber auch nur die Konfiguration suboptimal. Da ich aber
recht selten neue Make-Regeln schreibe, ist wohl der Leidensdruck noch
nicht groß genug, der Sache auf den Grund zu gehen ;-)
Edit:
Mensch, jetzt hat's mir doch keine Ruhe gelassen. Eine einzige Zeile
(sogar ohne Einrückung) im Konfigurationsskript hat den Job getan. Dabei
musste nicht einmal TFM geRet werden :D
Yalu X. schrieb:> Mensch, jetzt hat's mir doch keine Ruhe gelassen. Eine einzige Zeile> (sogar ohne Einrückung) im Konfigurationsskript hat den Job getan.
Ja, schön. Hätte mich im 3. Jahrtausend schon gewundert, wenn man
dem Editor nicht dateitypabhängige Regeln beibiegen könnte, und
dass Makefiles hard TABs brauchen, sollte so ziemlich jeder bessere
auch wissen.
Da ich gerade in den verschiedenen Opensource-Projekten mit allerlei
Mischmasch aus Leerzeichen und TABs konfrontiert bin, habe ich mir
für den Emacs mal irgendwann eingestellt, dass er mir hard TABs in
einer geringfügig anderen Farbe als der normalen Hintergrundfarbe
darstellt. Damit kann man sie gut erkennen, und normalerweise
editiere ich dann die jeweiligen Dateien möglichst in der Form weiter,
wie sie bereits waren.
Was sich auch wirklich gut macht ist, den Editor "trailing whitespace"
deutlich sichtbar machen zu lassen. Das ist 'ne richtige Seuche, die
da rumfleucht ...
@Yalu und @Malte:
Ich habe mich dazu entschlossen, mein Projekt unverändert zulassen und
weiterhin das bewährte Perl Script zu verwenden. Nach dem Motto: Never
change a running system. Für Windows packe ich eine die perl.exe mit ins
Projektverzeichnis.
Aber ich konnte von euren Vorschlägen lernen und werde sie serh
warscheinlich im nächsten Projekt anwenden, wenn ich nochmal
Binärdateien in den Flash Speicher ablege.
PS: Mein Filesystem ist Kacke. Es verschwendet einige Bytes
Speicherplatz, wie mir aufgefallen ist, weil die verkettete Liste mit
den Pointern auf die Dateinamen und Datei-Inhalte im RAM liegt. Aber
egal, es funktioniert. Nächstes mal mache ich es besser.
Es ist schon erstaunlich, dass in diesem langen Thread Ruby nur zwei mal
kurz erwähnt wird -- von Yalu. Ich selbst hatte vor Jahren auch mal
angefangen Python zu lernen, war dann aber recht schnell zu Ruby
gewechselt. Mir erscheint Ruby etwas eleganter, und das Problem mit den
Einrückungen hat man mit Ruby auch nicht. Gut, einiges andere auch
nicht, wie MathPlotLib...
Stefan Frings schrieb:> Ich habe mich dazu entschlossen, mein Projekt unverändert zulassen und> weiterhin das bewährte Perl Script zu verwenden.
<seufz> Also doch noch ein Happy End!
> Nach dem Motto: Never change a running system.
Genau so.
> Für Windows packe ich eine die perl.exe mit ins Projektverzeichnis.
Würde ich nicht machen. Ich würde in README sinngemäß schreiben:
"Auf eine Entwicklermaschine gehört neben make und einem C Compiler
selbstverständlich auch ein Perl Interpreter. Falls auf deiner Maschine
kein solcher Interpreter installiert ist, dann bist du vermutlich auf
Windows unterwegs <geheucheltes Beileid>. Einen Perl Interpreter kannst
du dann hier <Link auf ActivePerl> herunterladen". Fertig.
XL
PS: vielleicht doch noch ein Wort zu Python vs. Perl. Auch ich bin
bekennender Perlianer. Ich habe nicht prinzipiell etwas gegen Python,
auch wenn ich das Konzept "Whitespace zur Strukturierung" grenzwertig
finde. Vor allem kam Python für mich zu spät, es war YASL (yet another
scripting languange). Irgendwann ist auch mal Schluß. Und im Gegensatz
zu z.B. Ruby ist Python auch nicht signifikant sexier als Perl oder
Shell (oder PHP oder awk und was man sonst als alter UNIXer noch kann,
zugegebenermaßen habe ich sogar Lebenszeit an Tcl ver(sch)wendet).
Was mich außerdem nachdenklich stimmt, ist daß ich regelmäßig Probleme
mit Programmen habe, die zwingend eine neue Python-Version haben wollen
(der Klassiker für mich: bzr) und nicht dazu zu bewegen sind, mit einer
älteren Version zu funktionieren. So etwas hatte ich mit Perl noch nie.
Schlimmstenfalls braucht man da mal eine weitere Extension, aber ein 2
oder 3 Jahre alter Interpreter war da noch nie ein Problem. Mittlerweile
stehe ich auf dem Standpunkt, daß es ein gravierender Fehler war, bzr
ausgerechnet in Python zu implementieren. Ein Interpeter mit längerer
Halbwertszeit oder etwas kompiliertes wäre deutlich besser gewesen. Ich
kann halt nicht jedesmal meine Entwicklermaschine umkrempeln bloß weil
ein weiteres externes Projekt ein neueres bzr Repository-Format
verwendet, das ein neueres bzr erfordert das ein neueres Python
erfordert.
Axel Schwenke schrieb:> zugegebenermaßen habe ich sogar Lebenszeit an Tcl ver(sch)wendet
Ich auch. ;-) Kann man auch damit zurechtkommen, wenn's denn sein
muss. Mfile ist beispielsweise damit geschrieben, und damit spannt
sich auch der Bogen zum TE: der einzige Grund, warum ich Mfile in
Tcl (+Tk) geschrieben habe war, dass es zusammen mit WinAVR
ausgeliefert werden können sollte und daher mit genau dem zurecht
kommen musste, was bei WinAVR (+ native Windows) ohnehin schon dabei
ist. Das war eben weder Perl noch Python (dessen Hype damals ohnehin
noch nicht gestartet war), sondern Tcl, infolge des Insight-GDB-
Frontends. Also habe ich Mfile in Tcl geschrieben, was soll's, man
kann es benutzen, und es hat ein paar Leuten geholfen, in der
Lernkurve die zusätzliche Aufgabe "Makefile erstellen" erstmal
aussparen zu können.
Thread beobachten
Seitenaufteilung abschalten