Wozu (im anderen Thread gab es die Frage)? Antwort: . Symbole des Schaltplan-Editors automatisiert erstellen (aus Tabellen auslesen) . Footprints des PCB-Editors automatisiert erstellen . Netznamen an Pins der Symbole automatisiert vergeben (aus Tabellen) . automatisierte Design-Prüfungen im PCB-Editor (Impedance an Pins, Distanz bis Decouple-Cap, ...) ... Bereits existierende Tools, u.a.: https://github.com/xesscorp/kicad-3rd-party-tools ...Python2 ist auch nicht zu alt dafür.
nur verstehe ich nicht warum man dafür python verwenden will... 73
Hans schrieb: > nur verstehe ich nicht warum man dafür python verwenden will... > > 73 Ich verstehe nicht, warum man es NICHT verwenden sollte!
ähnliches problem wie node.js... es wird alles so "agil" entwickelt, dass es keine/kaum stabilen APIs gibt. python2/python3 ist immer noch nicht ganz ausgestanden langsam (im Vergleich zu V8) einfach inkonsistent (allein schon setuptools vs PEP) ... Mir ist schon klar das es keine ideale Sprache für sowas gibt, aber die V8 engine oder lua wären eine wesentlich besser wahl gewesen... dann hätte man auch eine vernünftige debug umgebung... oder habe ich da was übersehen? 73
Hallo Hans. Hans schrieb: > nur verstehe ich nicht warum man dafür python verwenden will... Weil Python zumindest für mich sehr einfach zu verstehen und zu handhaben ist. Letztlich ist das zwar nicht das grundsätzliche Argument für eine Skriptsprache, wenn man sie kann und regelmäßig nutzt, aber für so Gelegenheitsprogrammierer wie mich, die sich jedes halbe Jahr neu einlesen müssen, ist das ein schlagendes Argument. Java und die Abkömlinge mag ich irgendwie nicht. Geschwindigkeit ist nicht so furchtbar wichtig. Python2 vs. Python3 braucht in der tat noch, bis es überall durch ist. Aber auch für mich ist das konsistentere Python3 verglichen mit Python2 ein großer Vorteil....ich sehe darum den Wechsel gerne. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Mit dem Eclipse Plugin Pydev gibt es auch für Python eine Debugumgebung.
Warum man Python nicht verwenden sollte, wurde hier schon oft genug
diskutiert. { } ;-P
Ich würde JavaScript auch bevorzugen. Mittlerweile habe ich einige Kommandozeilenprogramme für Textverarbeitung (z.B. Markdown Code aus Quelltextziehen und automatisch PDF generieren, oder einen G-Code Postprozessor) programmiert und das läuft in JavaScript sehr angenehm von der Hand. Lg, Weinga-Unity
in erster linie will ich mit einer script sprache einfache dinge automatisieren/nachrüsten. dafür will ich möglichst effektiv und komfortabel arbeiten. Barrex schrieb: > Mit dem Eclipse Plugin Pydev gibt es auch für Python eine Debugumgebung. also kann ich das script, das unter kicad läuft einfach so debuggen??? Die V8 und auch SpiderMonkey können das nämlich... Beispielsweise im QtCreator (Qt5 nutzt die V8) einen breakpoint auf JavaScript exceptions und schon stoppt er falls/wenns ein Problem gibt... Console Logs gehen dort hin wo sie sollen und die scripts lassen sich ohne änderungen debuggen... Eigentlich ist's wie wenn man unter chrome (oder auch firefox) die entwickler-tools öffnet und herum zu debuggen beginnt. Ich bastle übrigens immer mehr tools als html-page... viel einfacher bekommt man einfache GUIs einfach nicht hin... und beispielsweise die XLS reader libs sowie die PDF generator libs sind auch gereift... bei der python engine muss man anscheinend im script erst den debugger aktivieren (http://winpdb.org/docs/embedded-debugging/)... und wenn's parsing nicht hinhaut, was dann? oder was wenn mehrere script rennen... wer mach dann den debugger auf???? nicht falsch verstehen, javascript ist auch nicht mein favourite da nicht streng getyped, aber debuggen macht richtig spaß mit der V8... Bernd W. schrieb: > Geschwindigkeit ist nicht so furchtbar wichtig. Naja.. hängt von der komplexität und dem umfang der tätigkeiten ab... listen und hashes muss ich sagen sind in der V8 richtig, richtig, richtig schnell und der JIT compiler ist abartig. Nachdem man aber vergleichsweise wenig rechenzeit in der Script engine verweilen wird hast du nicht unrecht... wichtiger ist in diesem fall sicher ein geringer overhead von einem nativ-zu-script aufruf... aber egal... hätte mich nicht hinreißen lassen sollen... läuft schon wieder alles richtung OT... 73
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.