VerySimpleXML: Problem unter iOS?

[Insider2004]

Da gibts noch einen Fehler in VerySimpleXML: Wenn das XML-File keine CRLF enthält (Ident=0, LineBreak=''), kommt man beim Lesen in eine Endlosschleife.

[himitsu]

Knallt Die auch?
Im Windows macht sie es im Testprogramm zumindestens nicht. (nach Compact, wird die, im Save, ohne Zeilenumbrüche eingelesen)
Wenn ich dann wieder aufgewacht bin, kann ich gern was dazu sagen.


LLVM: Dann freu ich mich schon darauf, wenn bald auch noch die VCL-Apps knallen.

[Union]

Das hat nichts mit LLVM zu tun sondern mit der falschen Umsetzung in der RTL.

[Insider2004]

LLVM ist der größte Misst, weil es 0,0 in die Emba-Toolchain passt und total verbuggt ist. Aber wir sollten hier den schönen VerySimpleXML-Thread nicht mit LLVM verseuchen.

[Insider2004]

Zitat von himitsu:

Knallt Die auch?
Im Windows macht sie es im Testprogramm zumindestens nicht. (nach Compact, wird die, im Save, ohne Zeilenumbrüche eingelesen)

Kann ich nicht testen. Läuft nicht mit Delphi 7. Du kannst aber mal ein 1 MB xml File erstellen ohne CRLF. Alles in einer Zeile. Ich wette, das Ding frisst sich beim Laden.

[cydo]

@romber:
Das Problem liegt in der Suche des ersten Zeichens eines Strings: beim "normalen" Windows-Delphi Compiler geht das so mit S[1] während die Standardeinstellungen beim neuen Compiler (iOS/Android) man bei 0 anfangen muss: S[0].
Du kannst vorrübergehend einfach in der XML-Unit oben ein {$ZEROBASEDSTRINGS OFF} einfügen, dann gehts auch. Ich werde aber die Unit umschreiben dass diese nun S[Low(String)] (Danke für diese Lösung, ist sicher schneller als copy) verwendet, dann gehts auch mit allen anderen Delphi-Compilern (D2009 und aufwärts, da Generics verwendet werden).

Einzeilige XMLs sollten kein Problem sein. macht er ja auch selber in der Demo. Ich habe aber noch einige Fixes, die noch nicht in eine offizielle Version eingegangen sind, ich werde die nächsten Tage diese einpflegen und eine 1.5 daraus machen (ich gebe hier Bescheid, wenns fertig ist).

[Insider2004]

Problem analysiert: Die Engstelle ist GetText. Bei jedem Tag wird der gesamte XML-File-Inhalt durch die Funktion geschleust. In meinem Beispiel hat das XML-File 2.5MB und 30000 Tags, keine CRFL. Nicht sooo groß, würde ich sagen. Das sind dann 30000 Tags * 2.5MB = 75000 MB = 75GB !!!, die umgeschaufelt werden. Bei mir läuft das jetzt seit über 20 Minuten.

[romber]

@cydo
Vielen Dank für die umfassende Hilfe an Sie und alle anderen.

Ich habe die Unit für den eigenen Bedarf auch ein wenig angepasst, indem ich die Text-Eingeschaft der Node und die Attribute-Value als Variant deklariert habe. So vermeide ich unnötige umwandlungen von String in Integer oder Boolean. Nur als Verbesserungsvorschag für die nächte Version.

Vielen Dank!

[himitsu]

Das GetText ist eines der Engstellen (wenn auch die Größte) ... dieses hatte ich etwas abgeändert, so daß erst gesucht und dann der Text als ein Stück rauskopiert und gelöscht wird.
Das macht dann ein Insert+Delete pro Tag (jeweils von < bis >) und dann nochmal pro Part (die Einzelteile im Tag) und nicht mehr überall pro einzelnes Zeichen.
> siehe ExtractText ... umbenannt, da es den Text ausschneidet und nicht "nur" ausliest.

@Romber:
Eigentlich wäre es einfacher dort AsBool-, AsInt-, AsFloat-, AsDate-Property einzubauen, denn spätestens beim Float und TDateTime wird es "schlimm",
denn da nimmt der Variant die Systemeinstellungen.
- Beim Float das Dezimaltrennzeichen der aktuellen Sprache, aber eine XML ist Englisch und "muss" immer nur in einer Sprache sein, denn sonst schreibst du den Float in einer Sprache (z.B. Deutsch mit Komma als "Komma") und beim Auslesen in einer anderen Sprache (z.B. Englisch mit Punks als "Komma") da hast du dann deinen "Spaß".
- Und beim Datetime genauso, dort wird das Systemformat vom DateTimeToStr verwendet, was sich auch unterscheidet und eigentlich hat da XML sogar sein eigenes "Standard"-Format.
(bei meiner XML-Klasse hatte ich mir daher einen eigenen "Variant" gebastelt, aber hier soll es ja "Simple" sein )

[Insider2004]

Zitat von himitsu:

Das GetText ist eines der Engstellen (wenn auch die Größte) ... dieses hatte ich etwas abgeändert, so daß erst gesucht und dann der Text als ein Stück rauskopiert und gelöscht wird.
Das macht dann ein Insert+Delete pro Tag (jeweils von < bis >) und dann nochmal pro Part (die Einzelteile im Tag) und nicht mehr überall pro einzelnes Zeichen.
> siehe ExtractText ... umbenannt, da es den Text ausschneidet und nicht "nur" ausliest.

Das ist immerhin besser, als die alte Lösung, da Insert und Delete sehr teuer sind.

Vielleicht wäre es auch einfacher, den einen Monster-string beim Laden einfach in mehrere kleine von z.b. 200er Länge zu zerhacken. Der Algo sollte das trotzdem fressen, da ja die nächste Line nachgeladen wird, wenn die alte abgearbeitet ist.