EVMS Python-Bindings
Verfasst: Montag 3. April 2006, 21:44
Wer schon mal mit EVMS-Scripting (in Python, mit subprocess) rumgespielt hat und frustriert war von dem ewigen Delay was das konsekutive Aufrufen des Kommandozeilen-Interpreters mit sich bringt (aufgrund der Ladezeit der Metadaten, welche jedes mal neu geladen werden), der wird
http://svn.modelnine.org/svn/evms-python
interessant finden. Das ist ein mehr oder weniger vollständiges (noch nicht ganz, aber morgen mit Sicherheit
) Binding der gesammten appAPI.h von EVMS an Python. Es ist mit PyRex geschrieben, um besonders die ganzen Typumwandlungen (halbwegs) sauber in den Griff zu kriegen, und sollte sowohl unter x86 als auch AMD64 sauber laufen. Das einzige was das Programm annimmt ist dass auf der entsprechenden Plattform (unsigned) int = 32-bit und (unsigned) long long = 64-bit lang ist (was auf beiden die ich vorhin gesagt hab auf jeden Fall gegeben ist).
Ich werd im Laufe des morgigen Tages auch noch ein bissel mehr Beispielcode posten wie man die Bindings benutzt, aber wer zumindest schon mal EVMS direkt programmiert hat wird das Interface auch so benutzen können (es ist eine mehr oder weniger 1:1-Abbildung des C-APIs auf Python-Datentypen, das geht natürlich noch schöner, aber das mach ich in Python, und das ist die Sache die noch nicht fertig ist).
Achso, das ganze ist unter der GPL, wie EVMS auch.
Viel Spaß damit!
PS: Ich bin momentan noch am überlegen ob evms-python einen PyRex-Bug aufgedeckt hat, oder ob ich einfach falsch denke: eine Typ-Konversion von einem unsigned int zu einem Python-Integer sollte unter 32-bit (x86) Systemen PyLong_FromUnsignedLong benutzen, da int == long auf diesen Plattformen, und ein unsigned long nicht in ein python int passt/passen kann. PyRex erstellt jedoch stur für alle *int-Typen ein PyInt_FromLong() (was auch auf AMD64 Plattformen okay ist). Ich hab schon an die Mailingliste gemailt, aber hab von denen noch keine Antwort bekommen; der letzte Beitrag zu PyRex ist auch schon ein weilchen alt.
Und: wundert Euch nicht, die resultierenden Libs sind ca. 90kb groß; das kommt aufgrund des ganzen Codes den PyRex erzeugt; ich habs aber aufgegeben das Ding von Hand zu wrappen, da EVMS mit richtig ekligen Datentypen rumspielt.
http://svn.modelnine.org/svn/evms-python
interessant finden. Das ist ein mehr oder weniger vollständiges (noch nicht ganz, aber morgen mit Sicherheit
) Binding der gesammten appAPI.h von EVMS an Python. Es ist mit PyRex geschrieben, um besonders die ganzen Typumwandlungen (halbwegs) sauber in den Griff zu kriegen, und sollte sowohl unter x86 als auch AMD64 sauber laufen. Das einzige was das Programm annimmt ist dass auf der entsprechenden Plattform (unsigned) int = 32-bit und (unsigned) long long = 64-bit lang ist (was auf beiden die ich vorhin gesagt hab auf jeden Fall gegeben ist).Ich werd im Laufe des morgigen Tages auch noch ein bissel mehr Beispielcode posten wie man die Bindings benutzt, aber wer zumindest schon mal EVMS direkt programmiert hat wird das Interface auch so benutzen können (es ist eine mehr oder weniger 1:1-Abbildung des C-APIs auf Python-Datentypen, das geht natürlich noch schöner, aber das mach ich in Python, und das ist die Sache die noch nicht fertig ist
).Achso, das ganze ist unter der GPL, wie EVMS auch.
Viel Spaß damit!
PS: Ich bin momentan noch am überlegen ob evms-python einen PyRex-Bug aufgedeckt hat, oder ob ich einfach falsch denke: eine Typ-Konversion von einem unsigned int zu einem Python-Integer sollte unter 32-bit (x86) Systemen PyLong_FromUnsignedLong benutzen, da int == long auf diesen Plattformen, und ein unsigned long nicht in ein python int passt/passen kann. PyRex erstellt jedoch stur für alle *int-Typen ein PyInt_FromLong() (was auch auf AMD64 Plattformen okay ist). Ich hab schon an die Mailingliste gemailt, aber hab von denen noch keine Antwort bekommen; der letzte Beitrag zu PyRex ist auch schon ein weilchen alt.
Und: wundert Euch nicht, die resultierenden Libs sind ca. 90kb groß; das kommt aufgrund des ganzen Codes den PyRex erzeugt; ich habs aber aufgegeben das Ding von Hand zu wrappen, da EVMS mit richtig ekligen Datentypen rumspielt.
