Eigen erstellte PC-Software (Hardware Testprogramm mit Multimeter)
bringt komplizierte Nachverfolgung und Reporterstellung mit sich.
Deshalb versuche ich jetzt, ein XML-Logfile zu erzeugen, das eine große
Anzahl Ereignisse in der Form:
<LogEvent timestamp=""
message=""><OptionalInfo>...</OptionalInfo></LogEvent>
stets mitschreibt. Ausnahmen von Threads, Testabläufen und grafischen
Steuerlementen sollen auch mitgeschrieben werden. Auch Messergebnisse.
Man könnte auch einen XSyslog-Dienst einrichten der eine Kopie hält.
Wird eben bei dem Log-Event noch ein Herkunftsattribut eingefügt.
Zunächst steht in dem Logfile aber noch kein XML Rootelement. Somit kann
immer angehängt werden.
Zu Auswerten klammert man eine Kopie des Logfiles noch in ein
<root>...</root> - Element.
Wozu kann man es nutzen?
- Man muss auf den Schutz persönlicher Daten achten. Daher eher für
Technik-SW geeignet.
- Aus dem Logfile kann man einen Auszug mit den Messergebnissen für ein
bestimmtes Testobjekt anfertigen (wieder XML). Daraus kann XSLFO einen
PDF-Report erzeugen.
- Es sind auch aufgetretene Ausnahmen in Zusammenhang mit
Messergebnissen enthalten (z.B. Division durch NULL, zu Ende geführter
Test trotz Ausnahme, der nicht gültig ist aber Fehlerinformationen
enthält).
- Ein Editor, dessen Fensterposition mitgeloggt wurde, kann beim
nächsten Start das Logfile fragen und mit dieser Fensterposition wieder
öffnen.
- Undo-Funktionen würden auch weit zurückreichen.
Mal sehen, was sich aus dem XML alles so herausgreppen lässt...
2 cent:
Ich persönlich arbeite eigentlich lieber mit zeilenorientierten Daten
weil die Weiterverarbeitung mit grep und Ecxel deutlich flüssiger von
der Hand geht.
Für die coolen Leute ist sicher noch ein einfacher Input in R wichtig.
Aha, XML. Was sagt die W3C, Hüterin des XML-Standards, noch mal über
XML? Ach ja:
>> ... the main properties that are considered lacking from XML are>> Compactness and Processing Efficiency, ...
Daher ist XML in der Tat ein hervorragender Ansatz wenn die Mission ist,
dass jeder Embedded-Computer in Zukunft mindestens ein 8-Kern CPU mit 2
GHz Taktfrequenz und 16 GB Hauptspeicher benötigt.
Für verbesserte Wirkung, und im Hinblick auf das Missionsziel, würde ich
ein professionelles XML-Format empfehlen, wie es für wirklich große,
komplizierte Systeme eingesetzt wird. Etwas, bei dem alleine schon der
Titel der Spezifikation Fans der gepflegten Komplexität Freudentränen in
die Augen treibt.
https://www.etsi.org/deliver/etsi_ts/132400_132499/132435/15.00.00_60/ts_132435v150000p.pdf>>> Digital cellular telecommunications system (Phase 2+) (GSM);>>> Universal Mobile Telecommunications System (UMTS);>>> LTE;>>> Telecommunication management;>>> Performance measurement;>>> eXtensible Markup Language (XML) file format definition>>> (3GPP TS 32.435 version 15.0.0 Release 15)
Habe es jetzt propiert.
Jeder Logeintrag ist eine Zeile. Mit dem RandomAccessFile extrahierte
ich Byte für Byte rückwärts aus dem File bis eine Zeile erreicht war.
Bei falschem Treffer notierte ich die letzte Position und machte mit der
vorletzten Zeile weiter. Ich kettete alle Bytes der Zeile zusammen.
Dummerweise kam so das XML Element rückwärts raus. Seitdem kette ich
rückwärts damit das XML Element vorwärts entsteht.
Somit startet die Anwendung stets mit der letzten Fensterposition.
Claus W. schrieb:> Habe es jetzt propiert.>> Jeder Logeintrag ist eine Zeile. Mit dem RandomAccessFile extrahierte> ich Byte für Byte rückwärts aus dem File bis eine Zeile erreicht war.> Bei falschem Treffer notierte ich die letzte Position und machte mit der> vorletzten Zeile weiter. Ich kettete alle Bytes der Zeile zusammen.> Dummerweise kam so das XML Element rückwärts raus. Seitdem kette ich> rückwärts damit das XML Element vorwärts entsteht.>> Somit startet die Anwendung stets mit der letzten Fensterposition.
???
Sorry, aber ich verstehe nur Bahnhof.
Welche Fensterposition? Warum XML von
Hand parsen?
merciless
Ich habe ein PC-Programm geschrieben, das Embedded-Geräte mit dem Dmm
messen soll. Das PC-Programm macht ein Fenster auf und zeigt in einem
Scrollbereich sämtliche Testschritte an. Beim Schließen des Fensters
wird die Fensterposition, Fenstergröße, Scrollposition und der Name der
geöffneten Datei in das Logfile geschrieben. Und zwar als einzelnes
XML-Element das genau eine Zeile braucht. Für nähere Hinweise kann in
dieses Element auch ein Kindelement eingebaut werden aber ohne die Zeile
zu wechseln. Es kommt aber nicht alles in das Logfile, einige Dinge
werden auch einfach verworfen.
Das Auslesen des Files erfolgt, indem vom Ende des Files jeweils eine
Zeile kopiert wird. Aus dieser erzeuge ich ein Xml-Document das nur aus
dem Inhalt dieser einen Zeile besteht. So kann ich von drei, vier
letzten Zeilen mehrere kleine XmlDocumente erzeugen oder auch deren
Inhalte kombinieren.
Auf die Art könnte ich auch eine Undo-Funktion implementieren oder die
letzten fünf geöffneten Dateien auflisten, wenn es mal soweit kommt. Ein
gesamter Testlauf könnte somit ein Start-Logeintrag und ein
End-Logeintrag schreiben. Dazwischen kämen sämtliche Messergebnisse.
Somit ist alles rückverfolgbar.
Ich halte XML für keine gute Wahl für soetwas. Nimm lieber JSON. Es ist
immer möglich ein JSON Objekt in eine einzige Zeile zu Packen, und die
Datenstruktur ist einfacher.
Also ich denke du vermischst hier 2 Dinge:
Logfiles dienen normalerweise nur der Protokollierung.
Diese werden danach vielleicht ausgewertet.
Das was du aber auch darin speichern möchtest,
ist ein Zustand deines Programmes, den du
beim erneuten Start wiederherstellen willst
(so eine Art Session).
Hast du nur ein Logfile, oder erzeugst du
verschiedene (für jede Messung eines)? Willst
du diesen Zustand für alle Messungen gemeinsam
speichern oder für jede Messung separat?
Auch halte ich XML für diese Art Anwendung als
nicht geeignet: XML dient normalerweise dem
Datenaustausch mit anderen System, evtl. noch
als Ersatz für ini-Configfiles. Für alles
andere gibt es bessere Lösungen. Hast du mal
an eine Datenbank gedacht (SQLite)?
merciless
Es ergeben sich tatsächlich Performance-Probleme beim Programmstart wenn
man um die 1000 Zeilen zurücklesen muss. Wahrscheinlich benötigt der
Konstruktor für das XmlDocument einige CPU-Zeit.
Es kam zu Performance-Problemen weil das File 2MByte lang ist (und
wächst) und öfter schnell mal gelesen werden muss. Festplatten benötigen
eine geringere Zeit um den Schwenkarm zu positionieren und eine etwas
längere Zeit damit sich die Platte auf den entsprechenden Winkel dreht.
Das würde Vorwärtslesen gegenüber Rückwärtslesen bevorzugen. Z.B. wären
6000 U/min => 600U/s => 600 Hz. Der Bereich des Rückwärtslesens wäre bei
mir auf etwa 2MByte begrenzt aber Rückwärtslesen ohne Block dauert damit
fünf Sekunden pro Suche. Falls Festplatten mit FLASH optimiert sind ist
mir die Geschwindigkeit des Rückwärtslesens unbekannt (weiß nicht ob ich
eine FLASH-Platte habe) aber ich rechne mit längerer Dauer für das
Rückwärtslesen.
Somit habe ich optimiert auf jeweils einen Block von 4kByte vom Ende
beginnend vorwärts zu lesen und in XML zu parsen worauf später der
Vorgänger dieses Blockes folgt.
=> Parsen: Mit dem StringBuilder in das <root>-Element verpacken.
=> Beginn des Blockes finden: Ausnahmsweise byte für byte einzeln
rückwärts lesen bis der Zeilentrenner erreicht ist.
Somit kann man die 2MByte in weniger als einer Schrecksekunde lesen. Im
Taskmanager sieht man keinen hohen CPU-Verbrauch.
Erde an Claus, Erde an Claus, hast Du die Kommentare hier verstehen
können?
Warum XML, warum rückwärts, warum zeilenweise XML (statt zeilenweise
ODER XML)?
Claus W. schrieb:> Es kam zu Performance-Problemen weil das File 2MByte lang ist (und> wächst) und öfter schnell mal gelesen werden muss.
Dann nimm eine Datenbank wenn du das Ding wie eine Datenbanktabelle
benutzen willst, genau dazu wurden Datenbanken erfunden und hochgradig
optimiert damit man eine Datenbank benutzen kann wenn eine Datenbank
braucht und sich keine eigene Datenbank schreiben muss welche dann mit
Unzulänglichkeit und unterirdischer Performance glänzen würde so wie
Deine selbstgebastelte Datenbankattrappe.
Wieder ein Fall von "Pfuscher verwendet wieder ohne Hirn und Verstand
Technik X von der mal gehört hat dass das toll wäre".
Kennst du überhaupt die Vorteile wo man besser XML verwendet und wann
nicht? Da würde ich erst mal ansetzen, sieht nämlich nicht so aus.
Denk mal nach warum XML für dein Vorhaben von Vorteil oder Nachteil
wäre, danach entscheidet man sich.
Wenn ich schon lese "aus XML herausgreppen" da ist ja schon Hopfen und
Malz verloren.
Wegen 2MB rückwärts lesen? In mehrere 4KB Häppchen?
Das ist: Blödsinn.
Lies die 2MB am Stück, ganz normal, mit einem XML-Parser ein. Dann den
letzten XML-Node, der interessiert, verwenden. Fertich.
Dauert ca. 50ms.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang