IM IN YR LOOP\n VISIBLE FOO\n IM OUTTA YR LOOP - Der Programmierer-Spamthread #2

[Kyuu]

MagicMagor: Python ist definitiv keine schlechte Wahl. Ich kenne einige, die mit Python + Pygame gute Erfahrungen gesammelt haben. Mit Pygame fährst du in Sachen Spieleprogrammierung sowieso gut, da die Bibliothek genau dafür entwickelt wurde und dementsprechend alles bietet, was du brauchen wirst. Für das GUI würde ich dann Qt nehmen, bzw. PythonQt. Qt ist sehr ausgereift, wird professionell weiterentwickelt und ist für zahlreiche Plattformen verfügbar. Ich glaube nicht, dass du mit Qt irgendwelche Schwierigkeiten bei der Auslieferung der Binaries haben wirst.

Bezüglich des Performanceunterschieds, da müsste eigentlich Python den kürzeren ziehen, da Java dynamisch in Maschinencode übersetzt wird. Allerdings gibt es den JIT-Compiler Psyco für Python, nur für den Fall, dass zusätzliche Performance benötigt wird.

[Miau]

Fanboy! Wobei du natürlich trotzdem Recht hast. PHP ist auch die schlechteste Lösung, und wer Ruby on Rails nicht mag, kann ja Django nehmen, das kommt effektiv fast auf das gleiche raus und ist beides so viel besser und effektiver ... ein Glück ist mein Chef da einsichtiger als deiner.

[DFYX]

Für alle, die der theoretischen Informatik zugeneigt sind: die gefühlt undertste Auflage von "Ich beweise, dass P != NP. Herausgegeben vorgestern. Hatte bis jetzt noch keine Zeit, mit das komplett durchzulesen, aber ich nehme an, dass sich irgendwo auf den 66 Seiten ein Fehler finden wird.

[Tabris]

Naja, die meisten "Beweise" waren ja für P = NP. Der Beweis scheint übrigens (zumindest in der aktuellen Version) fehlerhaft zu sein. Wer mehr erfahren will, dem empfehle ich Richard Liptons hervorragenden Blog: http://rjlipton.wordpress.com/.

[Lukas]

Aus Interesse: Was spricht für PythonQt gegenüber PyQt (bzw. PySide, was die selbe API wie PyQt implementiert und vom Qt-Hersteller kommt)? Davon hör ich nämlich zum ersten Mal, und die anderen haben eine gewisse Verbreitung …

Und Psyco ist de facto tot und macht wohl auch hauptsächlich number crunching schneller, da würd ich mich nicht drauf verlassen.

[Kyuu]

In erster Linie natürlich nichts, außer vielleicht im Vergleich zu PyQt, das keine LGPL-Lizenz anbietet, oder im Vergleich zu PySide, das laut der offiziellen Website noch keinen Windowsport besitzt.

Ehrlich gesagt habe ich mit keinem der Kandidaten Erfahrungen gesammelt und meine Python-Zeiten sind schon etwas länger her, so dass ich nicht mehr auf dem aktuellen Stand bin. Aus diesem Grund zitiere ich hier lieber die, die sich mehr auskennen:

Unlike PyQt and Qt Jambi, PythonQt is not designed to provide support for developers writing standalone applications. Instead, it provides facilities to embed a Python interpreter and focuses on making it easy to expose parts of the application to Python.

PythonQt makes extensive use of the Qt 4 meta-object system. Thus, PythonQt can dynamically script any QObject without any prior knowledge of it, using only the information supplied by QMetaObject (defined using Qt's moc tool in C++ applications). This dynamic approach allows several different script bindings to be embedded in the same application, each of which can use the same scripting API; e.g., JavaScript (QSA or QtScript) and Python.

...

Comparison with PyQt/PySide

PythonQt is not as pythonic as PyQt in many details (e.g. buffer protocol, pickling, translation support, ...) and it is mainly thought for embedding and intercommunication between Qt/Cpp and Python
PythonQt allows to communicate in both directions, e.g., calling a Python object from C++ AND calling a C++ method from Python, while PyQt only handles the Python->C++ direction
PythonQt offers properties as Python attributes, while PyQt offers them as setter/getter methods (e.g. QWidget.width is a property in PythonQt and a method in PyQt)
PythonQt currently does not support instanceof checks for Qt classes, except for the exact match and derived Python classes
QObject.emit to emit Qt signals from Python is not yet implemented but PythonQt allows to just emit a signal by calling it like a normal slot
PythonQt does not (yet) offer to add new signals to Python/C++ objects and it does not yet support the newstyle PyQt signals (so you need to connect via C++ string signatures)
Ownership of objects is a bit different in PythonQt, currently Python classes derived from a C++ class need to be manually referenced in Python to not get deleted too early (this will be fixed in a future version)
QStrings are always converted to unicode Python objects, QByteArray always stays a QByteArray and can be converted using str()
There are many details in the generated wrappers that could need some polishing, e.g., methods that use pointer arguments for additional return values could return a results tuple.
Not all types of QList/QVector/QHash templates are supported, some Qt methods use those as arguments/return values (but you can add your own handlers to handle them if you need them).
Probably there are lots of details that differ, I do not know PyQt that well to list them all.
In the long run, PythonQt will consider using/extending PySide with the features of PythonQt to get rid of its own generator and typesystem files, alternatively the KDE Smoke generator might be used in the future (this has not yet been decided, the current PythonQt generator works well and there is no hurry to switch).

...

BTW: So viel attraktiver wird PySide dadurch, dass es von einem Nokia-Tochterunternehmen entwickelt wird auch nicht. Zumindest macht MeVis ebenfalls was her.


Was Psyco angeht, kann es auf der einen Seite natürlich ein Problem darstellen, dass es nicht mehr weiterentwickelt wird, muss auf der anderen Seite aber nicht. Wie gesagt, wenn mehr Performance benötigt wird, kann man damit experimentieren.

Je nach Situation, kann eine Verbesserung der Rechenleistung durchaus etwas bringen, besonders in Spielen.

Außer Psyco kenne ich noch Unladen Swallow, aber das ist scheinbar 2009 auch ins Stocken geraten.

In jedem Fall ist es immernoch möglich performancekritischen Code nach C/C++ auszulagern. Das ist eigentlich auch eine bewährte Vorgehensweise.

[MagicMagor]

Ich bin mal so frei und nutze diesen Thread um meinen momentanen Ärger etwas Luft zu machen.

Ich sitze gerade an den Vorbereitungen für meine Bachelor-Arbeit, in der ich einen Orc Interpreter in Prolog schreiben muss.
Um mir die Arbeit des Parsings zu ersparen will ich den offiziellen Orc-Parser nutzen (in Java geschrieben, unter BSD-Lizenz verfügbar) und mit dem AST dieses Parsers weiterarbeiten.

Augenscheinlich schien bei der Entwicklung von Orc aber niemand daran gedacht zu haben, dass ein Aussenstehender jemals auf die Idee kommen könnte mit dem AST zu arbeiten.
Das fängt damit an, das es keine wirkliche Dokumentation gibt. Es gibt zwar eine Dokumentation per Javadoc, aber geschätzte 90-95% aller Klassen sind unkommentiert.
Der Versuch über die Namen der Klassen und Felder ein wenig die Bedeutung zu erfahren klappt an manchen Stellen ganz gut (Left, Right, body etc..) an anderen Stellen dafür weniger.
Was eine ConsExpr ist kann ich noch erahnen (Constant Expression?) was sich hinter den Kinderknoten "t" und "h" verrbirgt ist mir dagegen schleierhaft.

Bleibt mir nur, simple Testprogramme zu parsen und mir den resultierenden AST anzugucken. Glücklicherweise bietet der Orc-Quellcode direkt eine Funktion um den AST als XML-Datei abzulegen. Aber wirklich verständlich wird es dadurch auch nicht...
Folgendes Orc-Programm

Code:

2 + 5

Erzeugt einen AST, dessen XML-Datei zuviele Zeichen enthält, als das ich ihn hier posten könnte. Ungeachtet des Overheads der durch XML dazu kommt...
381.808 Zeichen in 1114 Zeilen sind ein wenig viel um den AST zu verstehen...

Ich glaub, bevor ich den AST verstehe krieg ich davon Alpträume.. Irgendwie hätte ich von Code, der immerhin an einer Universität entwickelt wird, ein wenig mehr Dokumentation erwartet...

[Kyuu]

Code (C++):

 
for (unsigned int i = foo.Length()-1; i >= 0; --i) //...
 

Wer findet den Bug? (Wahrscheinlich alle, ich bin nur etwas verblüfft sowas subtiles zu sehen.)

[Jesus_666]

Im Falle von foo.Length() == 0 wird die Schleife 2³²-, bzw. 2⁶⁴mal zu oft durchlaufen?

[Kyuu]

Ne, die Schleife wird nie beendet.

[DFYX]

Ah, ja, jetzt seh ichs. Ein >= 0 auf einem unsigned int... Wahnsinn.

[Mivey]

Ne, die Schleife wird nie beendet.

...

Weil sobald i 0 ist, es um eins reduziert wird, dadurch dann sofort den größtmöglichen Wert annimmt?

[Whiz-zarD]

Jop.

[DFYX]

Spaß mit verschachtelten Templates!

Code (C++):

std::map<size_t, std::map<std::string, std::pair<PropertyType, ParameterDefinitionList> > > m_mActions;

führt zu

Code:

1>c:\program files (x86)\microsoft visual studio 9.0\vc\include\xlocnum(135) : warning C4503: 'std::_Tree<_Traits>::_Buynode': Die Länge des ergänzten Namens wurde überschritten. Der Name wurde gekürzt.
1>        with
1>        [
1>            _Traits=std::_Tmap_traits<size_t,std::map<std::string,std::pair<DeviceManager::PropertyType,DeviceManager::ParameterDefinitionList>>,std::less<size_t>,std::allocator<std::pair<const size_t,std::map<std::string,std::pair<DeviceManager::PropertyType,DeviceManager::ParameterDefinitionList>>>>,false>
1>        ]

Mit komplett aufgelösten typedefs wäre es übrigens:

Code (C++):

std::map<size_t, std::map<std::string, std::pair<enum PropertyType, std::map<std::string, enum PropertyType> > > > m_mActions;

Ich könnte die Warnung umgehen, indem ich noch mehr Typedefs verwend, aber dazu bin ich ehrlich gesagt zu faul.

[nudelsalat]

Sleepsort: http://beust.com/weblog/2011/06/15/sleep-sort/

[Indy]

Code:

<?php

class tx_kbs_con_countrycon extends tx_eb_mvc_con_acon {

/**

* countryrep

*

* @var tx_kbs_dom_rep_countryrep

*/

protected $countryrep;

/**

* icountryrep

*

* @param tx_kbs_dom_rep_countryrep $countryrep

* @return void

*/

public function icountryrep(tx_kbs_dom_rep_countryrep $countryrep) {

$this->countryrep = $countryrep;

}

/**

* action list

*

* @return void

*/

public function laction() {

$country = $this->countryrep->fall();

$this->v->asn('country', $country);

}

/**

* action show

*

* @param $c

* @return void

*/

public function saction(tx_kbs_dom_mod_country $country) {

$this->v->asn('country', $country);

}

}

?>

Ich kenne die Bedeutungen hinter den Abkürzungen, also kann es eigentlich nicht so verkehrt sein.

[Indy]

Erfahrungen mit Android-Apps: ja
Erfahrungen speziell im 2D/3D-Bereich: nein
Der grafische Kram dürfte bei Android alles mit OpenGL/OpenGL ES gelöst sein.
Aber wonach suchst du überhaupt?

[Desmulator]

Es war eine Fangfrage. Natürlich ist jedes Sequenz von Ereignissen mit gleicher Länge gleich wahrscheinlich. Simple Antwort: Nein. Es ging aber hier um die subjektive Erwartungshaltung eines Beobachters, der an die gleiche Verteilung der Ereignisse glaubt und kausale Zusammenhänge dort versucht zu sehen wo sie eigentlich nicht sind. Mathematisch natürlich non-sens aber irgendwie geht es mir zumindest auch so, wenn ich sowas tippe, dass ich dazu neige nach drei mal Zahl, eher auf Kopf zu tippen ...

[DFYX]

Gut, ich denke, damit war die Frage hier einfach an der falschen Stelle. Ich gehe davon aus, dass jeder, der diesen Thread liest, sich zumindest einigermaßen mit Wahrscheinlichkeitstheorie auskennt und sowas weiß.

[DFYX]

Ich experimentiere grade mit SDL 2.0 und bin begeistert. Endlich bekomme ich die ganzen Features, die ich in SDL 1.x immer vermisst habe oder von Hand mit OpenGL lösen musste:

• Skalierte und rotierte Sprites
• Gleichzeitige Verwendung von Per-Surface-Alpha und Per-Pixel-Alpha
• Mehr Blending Modes als nur einfaches Alpha Blending
• Abstraktionslayer für Threads (sonst hab ich halt immer Pthread genommen)
• Und noch viel mehr.