|
|
|
|
|
|
|
Klar, deswegen gibts überhaupt erst 3D!
Wie bei Bluray und VHS: Porn is future 
|
|
|
|
|
|
|
|
|
|
|
|
Weiß jemand ein Tools für Graphen/Zustandsautomaten, welches auch Vektorgraphiken exportieren kann? Ich will das nachher in Latex importieren. TikZ kann ich nicht verwenden, da mein Graph dafür zu groß ist und ich nicht alles von Hand machen will.
|
|
|
|
|
|
|
|
|
|
|
GraphViz, Gephi. Letzteres kann mit sehr sehr großen Graphen gscheit umgehen.
Trigger: Natürlich gibt es das.
|
|
|
|
|
|
|
|
|
|
|
|
GRaphviz und dann nach PDF oder PS exportieren und einbetten.
|
|
|
|
|
|
|
|
|
|
|
|
In GraphViz kann ich aber nicht zufällig meine Nodelabels als Tex Code angeben?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Kambfhase
In GraphViz kann ich aber nicht zufällig meine Nodelabels als Tex Code angeben?
| |
dot2tex (standalone) bzw. dot2texi (package)
|
|
|
|
|
|
|
|
|
|
|
Danke, das sieht gut aus. Ich hatte vor ein kleines Beispiel für einen LR(1) Automaten zu basteln. Inzwischen habe ich 20 Zustände und zwei DINA4 Seiten gefüllt. 
|
|
|
|
|
|
|
|
|
|
|
Trigger ist in der Gegenwart angekommen.
|
|
|
|
|
|
|
|
|
|
Auf der Python Schrecklichkeitsskala: Wie schrecklich ist Folgendes?
Ich möchte eine Art Strategie-Muster anwenden, um eine WebService Anbindung an unterschiedliche Systeme zu realisieren. Das Ganze muss ich in OpenERP machen und damit es pluggable ist die einzelnen Strategien als OpenERP-Module umsetzen. Dabei muss ich von einem Objekt des Core-Moduls "erben", damit ich die einzelnen Strategien im UI als Elemente des Core-Moduls behandeln kann. Die Vererbungsmethode ist in dem Fall ein Mixin-Mechanismus bei dem die Felder und Methoden des erbenden Objekts einfach in das beerbte Objekt injeziert werden. Die Plugins sollen nun ihre eigenen Methoden mit einem Präfix versehen und dieses Präfix in dem beerbten Objekt registrieren (läuft mittels etwas black magic im Framework). Die registrierten Strategien werden dann im UI zur Auswahl angeboten wenn ein neuer Datensatz des Core-Objekts angelegt wird. Der Zugriff auf die einzelnen Methoden der Plugins erfolgt über eine Schnittstelle die vom Core-Objekt vorgegeben wird, und den Plugins eben mit ihrem Präfix implementiert wird. Das Core-Objekt mappt seine Schnittstelle mittels des im Datensatz ausgewählten Präfixes auf die entsprechenden Methoden des Plugins.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Smoking am 17.03.2013 22:18]
|
|
|
|
|
|
|
|
|
| | Zitat von Smoking
Auf der Python Schrecklichkeitsskala: Wie schrecklich ist Folgendes?
Ich möchte eine Art Strategie-Muster anwenden, um eine WebService Anbindung an unterschiedliche Systeme zu realisieren. Das Ganze muss ich in OpenERP machen und damit es pluggable ist die einzelnen Strategien als OpenERP-Module umsetzen. Dabei muss ich von einem Objekt des Core-Moduls "erben", damit ich die einzelnen Strategien im UI als Elemente des Core-Moduls behandeln kann. Die Vererbungsmethode ist in dem Fall ein Mixin-Mechanismus bei dem die Felder und Methoden des erbenden Objekts einfach in das beerbte Objekt injeziert werden. Die Plugins sollen nun ihre eigenen Methoden mit einem Präfix versehen und dieses Präfix in dem beerbten Objekt registrieren (läuft mittels etwas black magic im Framework). Die registrierten Strategien werden dann im UI zur Auswahl angeboten wenn ein neuer Datensatz des Core-Objekts angelegt wird. Der Zugriff auf die einzelnen Methoden der Plugins erfolgt über eine Schnittstelle die vom Core-Objekt vorgegeben wird, und den Plugins eben mit ihrem Präfix implementiert wird. Das Core-Objekt mappt seine Schnittstelle mittels des im Datensatz ausgewählten Präfixes auf die entsprechenden Methoden des Plugins.
| |
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Smoking
Auf der Python Schrecklichkeitsskala: Wie schrecklich ist Folgendes?
Ich möchte eine Art Strategie-Muster anwenden, um eine WebService Anbindung an unterschiedliche Systeme zu realisieren. Das Ganze muss ich in OpenERP machen und damit es pluggable ist die einzelnen Strategien als OpenERP-Module umsetzen. Dabei muss ich von einem Objekt des Core-Moduls "erben", damit ich die einzelnen Strategien im UI als Elemente des Core-Moduls behandeln kann. Die Vererbungsmethode ist in dem Fall ein Mixin-Mechanismus bei dem die Felder und Methoden des erbenden Objekts einfach in das beerbte Objekt injeziert werden. Die Plugins sollen nun ihre eigenen Methoden mit einem Präfix versehen und dieses Präfix in dem beerbten Objekt registrieren (läuft mittels etwas black magic im Framework). Die registrierten Strategien werden dann im UI zur Auswahl angeboten wenn ein neuer Datensatz des Core-Objekts angelegt wird. Der Zugriff auf die einzelnen Methoden der Plugins erfolgt über eine Schnittstelle die vom Core-Objekt vorgegeben wird, und den Plugins eben mit ihrem Präfix implementiert wird. Das Core-Objekt mappt seine Schnittstelle mittels des im Datensatz ausgewählten Präfixes auf die entsprechenden Methoden des Plugins.
| |
Klingt nach einer typischen Framework-API; schöner Code für die API-Clients, richtig bäh im API-Code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Genauso, saturn macht ja die preise von amazon mit
|
|
|
|
|
|
|
|
|
|
|
|
Wenn ihr Name Version und dazugehörige Dependencies organisieren müsst, mit welcher Datenstruktur würdet ihr da sin python am ehesten machen?
|
|
|
|
|
|
|
|
|
|
|
|
Ein gerichteter, hoffentlich azyklischer Graph. Entweder selbst bauen, oder, falls dir das nicht zu Overkill ist, networkx
|
|
|
|
|
|
|
|
|
|
|
|
Objekt pro $ding in einem Set/Liste und ein dict, das die Kanten von einem DAG repräsentiert?
|
|
|
|
|
|
|
|
|
|
|
Also ob das dict dann auch einen DAG ergibt, ist natürlich eine andere Frage
(dict von identifier=>liste_von_dependencies)
|
|
|
|
|
|
|
|
|
|
|
|
Wenn deine $ding-Objekte hashable sind, kannste die ja auch direkt als Key benutzen.
|
|
|
|
|
|
|
|
|
|
|
In CPAN hat sich was ganz einfaches etabliert: Eine Map
| |
| Code: |
my $dependencies = {
"module1" => "requiredMinVersion",
"module2" => 0, # Egal welche Version, hauptsache installiert
}
|
|
Aber man kann es sich auch kompliziert machen
|
|
|
|
|
|
|
|
|
|
|
Doofe Frage. Müsste es nicht %dependencies heißen?
Lerne gerade Perl und bin mir unsicher bzgl. deiner Deklaration.
|
|
|
|
|
|
|
|
|
|
|
|
Lern lieber was nützliches, Python z.B. ... oder C++.
|
|
|
|
|
|
|
|
|
|
|
Ich installier einfach die Ultimate. 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SkunkyVillage am 18.03.2013 18:33]
|
|
|
|
|
|
|
|
|
Lieber deinstallieren und neuinstallieren. Bei MS Office bin ich da mal hart auf die Fresse geflogen 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von DeineOmi
Doofe Frage. Müsste es nicht %dependencies heißen?
Lerne gerade Perl und bin mir unsicher bzgl. deiner Deklaration.
| |
Jein. Das ist einer der Kritikpunkte bei den wegseldenen SigIls (Vorzeichen) je nach kontext. 
{} liefert dir eine Hash-Referenz und Referenzen werden in normalen Skalaren - also mit $ - gespeichert.
Wenn man einen echten Hash haben wollte (also %dependencies) müsste man mit normalen Klammern arbeiten:
| |
| Code: |
my %dependencies = (
"module1" => "requiredMinVersion",
"module2" => 0, # Egal welche Version, hauptsache installiert
);
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Lern lieber was nützliches, Python z.B. ... oder C++. | |
perl is nützlich, wenn man viel text processing macht. perl mag ich eher deshalb nicht, weil es sigils und referenzen hat, und für alles, was kein text-munching ist, enorm viele alternativen hat, die man installiert haben und zwischen denen man wählen muss. sogar syntaktisch kann man es nach gusto anpassen, was cool ist, aber für schnelle scripte mir zu viel boilerplate erfordert.
/edit: das mit den alternativen ist schlecht, weil zwei codebases mit verschiedenen klassensystemen sich anders anfühlen, und man um von der einen zur anderen zu wechseln einlernungszeit braucht. ich bin eher so der it’s boa poo today als der tim today-typ
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von flying sheep am 18.03.2013 18:41]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Lern lieber was nützliches, Python z.B. ... oder C++.
| |
Wenn ich heute abend noch ins Hotel komme (und der Projektmanager uns nicht alle in einem Rageanfall bis Mittwoch zum Release im Keller einsperrt ) werde ich mir mal diese Perl-Script ansehen das da so langsam sein soll! Und dann gande dir Gott, dass es wirklich nur an Start-Overhead des Interpreters gegenüber einer Binary liegt!
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Lern lieber was nützliches, Python z.B. ... oder C++.
| |
Ich muss darin aber noch eine Klausur schreiben.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GH@NDI
| | Zitat von csde_rats
Lern lieber was nützliches, Python z.B. ... oder C++.
| |
Wenn ich heute abend noch ins Hotel komme (und der Projektmanager uns nicht alle in einem Rageanfall bis Mittwoch zum Release im Keller einsperrt ) werde ich mir mal diese Perl-Script ansehen das da so langsam sein soll! Und dann gande dir Gott, dass es wirklich nur an Start-Overhead des Interpreters gegenüber einer Binary liegt!
| |
Ich bin inzwischen bei Faktor 13 :P
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GH@NDI
wegseldenen
| |
Ist das dein Ernst?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von cms
| | Zitat von GH@NDI
wegseldenen
| |
Ist das dein Ernst?
| |
Ein finsterer Moment für meine Rechtschreibung.
|
|
|
|
|
|
|
|
| Thema: Gehirnsalat ( wir unter uns ) |
