|
|
|
|
*sigh*
Solche Vergleiche von Programmiersprachen und anderen Gegenständen sind immer "dämlich" und zeigen nur die subjektive Sicht des Autors bzw. dessen Wissensstand. /e Trotzdem wird man die aufgeführten Beispiele witzig finden dürfen
Des Weiteren wird von "reliable" gesprochen, was nicht mit "sicher" gleichzusetzen ist.
Das wäre aber eigentlich mal wieder eine gute Gelegenheit für seitenlange Programmiersprachen Diskussionen.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Krypt0n am 29.09.2014 16:38]
|
|
|
|
|
|
| Zitat von teK
Hat doch wunderbar (bisher) funktioniert, die Teile gehen weg, wie warme Semmeln.
Microsoft’s reaction to CVE-2014-6271
https://i.imgur.com/dvnEM1j.jpg
grafische Veranschaulichung meines letzten Posts (via)
| |
ach, bald ist wieder der erste dienstag im monat....
|
|
|
|
|
|
|
Naja C ist halt eine pseudo-typisierte Sprache. Ja, sie ist stark und statisch typisiert, aber in der Praxis wird ständig Typinformation weggeschmissen und das [x] Ich meine zu wissen, was ich tue-Feld angekreuzt. Häufiges Beispiel ist der typische void *data für Callbacks.
Und die Links sind halt Scheiße:
| It's been well noted that C/C++ programmers spend alot of their time finding/fixing bugs (bohrbug, heisenbugs, mandelbugs, schrödinbugs), or building/buying tools to make up for the common ambiguities and deficiencies of those languages, while Ada programmers spend most of their time adding additional functionality and value to their product. | |
Brrr... M(
Sonst kann man drüber schmunzeln, ist doch ok.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 29.09.2014 16:54]
|
|
|
|
|
|
| Zitat von Krypt0n
*sigh*
Solche Vergleiche von Programmiersprachen und anderen Gegenständen sind immer "dämlich" und zeigen nur die subjektive Sicht des Autors bzw. dessen Wissensstand. /e Trotzdem wird man die aufgeführten Beispiele witzig finden dürfen
Des Weiteren wird von "reliable" gesprochen, was nicht mit "sicher" gleichzusetzen ist.
Das wäre aber eigentlich mal wieder eine gute Gelegenheit für seitenlange Programmiersprachen Diskussionen.
| | ja mann!
ich finde schon, dass „verlässlich“ auch „sicher“ bedeutet. „verlässlich im bezug auf vorhersagbarkeit“ ist einfach nur „vorhersagbar“
so gesehen ist C vorhersagbar: wenn du code analysierst, kannst du genau rausfinden, was wie lange lebt und wo welcher speicher wie alloziert wird. aber einmal was vergessen oder vertippt oder eine pointerarithmetik vergeigt und schon hagelt es sicherheitslöcher, crashes, und undefiniertes verhalten.
das ist für mich nicht verlässlich, weil ich ein fehlerhafter mensch bin, und meine tools darauf eingehen müssen.
|
|
|
|
|
|
tiptop!
|
| Zitat von theromi
Jemand noch eine Idee, wie man das debuggen könnte?
| |
Nachtrag:
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von teK am 29.09.2014 17:42]
|
|
|
|
|
|
Oi, dass ist ein nettes Diagramm, danke!
Gespeichert. Greater Map Of UNIX Debugging.png
|
|
|
|
|
|
|
Wuhu! Ich bin kluk. GPU-Speicherverbrauch grob halbiert. ![peinlich/erstaunt](img/smilies/icon16.gif)
Statt zweidimensionale VBOs zu nehmen, nehme ich jetzt eindimensionale VBOs, in denen nur die y-Daten stehen, binde einen zweiten eindimensionalen VBO dazu, in dem nur die x-Daten stehen (die für jedes i in jedem Buffer gleich waren). Im Vertex Shader mache ich dann...
|
Code: |
uniform mat4 matMVP;
attribute float fValue;
attribute float fTime;
void main() {
gl_Position = matMVP * vec4(fTime, fValue, 0.0, 1.0);
} |
|
Das VAO merkt sich für jede Trace beide Buffer und ein fixes Profiling ergibt, dass das sogar nen ganzes Stück schneller ist als die vorige Lösung. Ich vermute mal, dass der Treiber vormals meine VBOs von Hand auf vec4 gebracht hat. (hatte vorher attribute vec4 ..., aber nur 2-Tupel übergeben).
Meine render()-Funktion ist dank VAOs _extrem_ einfach:
|
Code: |
void render()
{
m_gl.glClearColor(0.0, 0.0, 0.0, 0.0);
m_gl.glClear(GL_COLOR_BUFFER_BIT);//|GL_DEPTH_BUFFER_BIT);
if(!m_file) {
// Nothing to render
return;
}
double timeWindowWidth = 1.0 - m_timeScale + m_timeScale * m_minTimeScale;
double offset = (1.0 - timeWindowWidth) * m_position;
m_program.bind();
for(int j = 0; j < m_flatParams.length(); j++) {
const LogViewParameter *lvp = m_flatParams[j];
if(!lvp->enabled()) {
continue;
}
m_vao[j]->bind();
m_program.setUniformValue("lineColor", lvp->glColor);
QMatrix4x4 mvp;
mvp.ortho(offset, offset + timeWindowWidth, lvp->groupMin, lvp->groupMax, -1.0, 1.0);
m_program.setUniformValue("matMVP", mvp);
m_gl.glDrawArrays(GL_LINE_STRIP, 0, m_file->recordsTotal());
m_vao[j]->release();
}
m_program.release();
} |
|
Buffer clearen (Depthbuffer wird gerade nicht gebraucht) - Shader aktivieren
Für jede Trace: VAO binden - Farbe setzen - Transfo setzen - Drawcall
Ich hab das irgendwie alles viel komplizierter in Erinnerung
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 29.09.2014 18:10]
|
|
|
|
|
|
Kann jemand im Allgemeinen ein Tutorial für Threading mit Python empfehlen und kann mir im speziellen jemand folgendes Beantworten:
Ich möchte ein Programm schreiben, das im Prinzip folgenden Aufbau hat:
- Eine UI und ein Netzwerk-Port, der auf Events wartet und dann
- eine Datenerfassung steuert/aktiviert
- etwas was diese Daten speichert und übers Netzwerk verschickt.
Gibt's da irgendwie patterns, wie man das am schlauesten Implementiert?
|
|
|
|
|
|
|
Um ehrlich zu sein, würde ich inzwischen von Multithreading in Python komplett abraten. Netzwerk asynchron machen, ggfs. dito für IO. Vielleicht ist das in Python 3.4 neue asyncio was für dich.
Ich würde...
UI => Qt
Netzwerk => Qt Network - asynchron
HTTP per Qt Network beispielhaft: https://github.com/MartiniMoe/SpaceDash/blob/master/dashboard.py#L34
|
|
|
|
|
|
|
https://docs.python.org/3/library/asyncio.html dürfte dafür jedenfalls nützlich sein. Async, aber in einem Thread. Zumindest für den nicht-Gui Krams sinnvoll.
¤dit: Oller Zwipo.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von audax am 29.09.2014 20:11]
|
|
|
|
|
|
hmm... wär natürlich nett von QT, wenn das mir das alles abnehmen könnte... aber erkenn ich das richtig, dass in dem Beispiel von dir er von Hand beim Server nachfragt, was anliegt? Wenn ich dann also zwischen zwei Python Programmen Befehle/Daten schicken will, bräuchte ich also noch nen Server als Vermittler? Ich würde gerne auch die Latenz niedrig halten...
|
|
|
|
|
|
|
In dem verlinkten Sample sollte nur deutlich werden, dass das relativ einfach ist.
Genauere Empfehlungen welche API du wie nutzen kannst/solltest, gibt's erst mit genaueren Beschreibungen was du eigentlich tun willst. Ein Netzwerk-Port, der auf Events wartet und eine UI, die Datenerfassung steuert, die Daten übers Netzwerk schickt, ist ... vage.
|
|
|
|
|
|
|
|
|
|
|
hehe, naaa guuut. Also ich hab ne Datenerfassungssoftware in LabView, die ich aber gerne in Python neu schreiben möchte.
Im Kern steuert sie eine CCD-Kamera an, liest die Bilddaten und schreibt sie in eine Datei. Gewünscht ist, dass die Software übers Netzwerk ferngesteuert werden kann und auf Kommando Bilder aufnimmt und speichert.
Gleichzeitig soll aber auch lokal per UI die Kamera gesteuert werden. Außerdem soll das Programm übers Netzwerk auch Daten (=Spektrum aus dem Bild) zurück senden.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von RichterSkala am 29.09.2014 21:09]
|
|
|
|
|
|
Klassische Client/Server-Struktur dürfte deinen Bedarf decken.
Server ohne UI auf der Kiste mit der Hardware
Clients per Netzwerk.
Networking in dem Fall eher per RPC, da gibts diverse, z.B. Pyro4. Drauf achten, dass das RPC-Framework asynchron arbeiten kann.
|
|
|
|
|
|
|
|
|
|
|
Da kann ich ja gleich struct {} und write() nehmen.
|
|
|
|
|
|
|
Die Gelegenheiten, bei denen ich nicht mehr weiß, was ich hier noch antworten soll, häufen sich.
|
|
|
|
|
|
|
Der Post war auch nicht ernst gemeint :)
/e: elitärer, so is besser.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 29.09.2014 21:37]
|
|
|
|
|
|
| Zitat von csde_rats
Da kann ich ja gleich struct {} und write() nehmen.
| |
Na wie jetzt, erst hier von Threading abraten und irgendwelche High-Level APIs empfehlen und dann mit sowas kommen?
|
|
|
|
|
|
|
Ich rate ja nich von Multithreading ab (da rate ich zu), ich rate von Multithreading in Python ab.
|
|
|
|
|
|
|
Was ist überhaupt so schrecklich an Threading in Python?
|
|
|
|
|
|
|
Mach's einfach mal, siehste dann schon ![Breites Grinsen](img/smilies/biggrin.gif)
Spoiler - markieren, um zu lesen:
GIL + Threading = Die Komplexität von Multithreading ohne die Vorteile von Multithreading. Der GIL garantiert dir nur keinen Perfomancevorteil von Multithreading, aber keine Unversertheit von Operationen, also sollte man Locking machen (was wir in i3pystatus z.B. nicht machen, Fehler sind da allenfalls transienter Natur). Gleichzeitig läuft aber Code nicht parallel, also kein Perfomancevorteil. Ergo ist das Mittel der Wahl für pseudonebenläufiger, nicht perfomancekritischen Kram in Python eigentlich nie Threading*.
Multiprocessing ist hauptsächlich Scheiße, weil's explizite Interfaces erzwingt und nen erheblichen Speicheroverhead hat - .so's mögen geshared sein, Python-Module _nicht_.
* In i3pystatus neben wir eigentlich nur Threading, weil's da halbwegs bequem is und halbwegs unabhängiges Timing ermöglicht. Aber das hast du hier nicht.
|
|
|
|
|
|
|
Ebenso gespeichert. Nett.
Der Klassiker:
![](http://2.bp.blogspot.com/-B8E6Qw4sHJE/TgKQKw1Jq-I/AAAAAAAAABc/HohCyZKRhRs/s320/129447781337.jpg)
Der gefaellt mir auch, trifft Java so gut:
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 29.09.2014 23:19]
|
|
|
|
|
|
| Apples Resetfunktion in iOS 8 ist gründlicher als geplant. Die Funktion der Geräte löscht alle iWork-Dokumente in Apples Onlinespeicherdienst iCloud Drive, obwohl Apple im Menü genau das Gegenteil behauptet. | |
chrchrchr
|
|
|
|
|
|
|
| Zitat von teK
| Zitat von SwissBushIndian
Da Excel maximal einen Core für seinen Scheiss verwendet, habe ich das ganze folgendermassen gelöst: Ich starte mehrere Excelinstanzen (mein "Threadpool"), auf den ich die verschiedenen Berechnungen verteile.
| |
Du steckst aber nicht hinter Minecraft 2 für Excel, oder?
| |
Bisher hab ich mich nur mal an Snake in Excel-Vba gewagt
|
|
|
|
|
|
|
| Zitat von teK
python2 hat asyncore.
| |
das is ne nutzlose krücke.
und der tulip/asyncio-backport auf python 2 namens trollius ist auch doof:
kein yield from , kein return von coroutinen, …
vergesst einfach python 2 für neue projekte, ja?
|
|
|
|
|
|
|
jup, die beiden sind ziemlich gut! lustig und treffend.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von flying sheep am 29.09.2014 23:57]
|
|
|
|
|
|
Ich vergesse Python2 vielleicht für neue Projekte, wenn du, wo du heute schon so am Mosern bist, ordentlich quotest. Dazu gehört auch, scheiße skalierte Bilder nicht nochmal reinzunehmen. [mein letztes Bild ist übrigens klickbar]
| Zitat von SwissBushIndian
Bisher hab ich mich nur mal an Snake in Excel-Vba gewagt ![Breites Grinsen](img/smilies/biggrin.gif)
| |
Halbmasochist bleibt Masochist.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von teK am 29.09.2014 23:36]
|
|
|
|
|
|
| Zitat von teK Ich vergesse Python2 vielleicht für neue Projekte, wenn du, wo du heute schon so am Mosern bist, ordentlich quotest. Dazu gehört auch, scheiße skalierte Bilder nicht nochmal reinzunehmen. | | stimmt, sorry.
|
|
|
|
|
|
Thema: 100 gute Gründe für Linux ( Gute Informatiker für ++30 ) |