Ich glaube nicht, ohne es überprüft zu haben, dass der NSTextView selbst den Text speichert.

Original von below
Stimmt, das macht [myNSTextView textStorage].

Frage analog: Wie viel passt da rein? Wenn "unbegrenzt", wie kann ich das abfragen, damit ich dem User da nicht Gigabyteweise Speicher wegfresse?

Hm, gute Frage. Die Länge des Textes in Zeichen kannst Du ja über [textStorage length] abfragen.

Vielleicht setzt Du dem User dann einfach ein Limit von x Zeichen.

Naja, es könnte sein, dass der beim Editieren Kopien anlegt. Daher "ohne es überprüft zu haben".

Wenn du dem User nicht Gigabyte Speicher wegfressen willst, schreib nicht Gigabyte herein. Ich verstehe das Problem nicht ganz. Woher bekommst du denn den Text?

Ansonsten solltest du über Lazyness nachdenken.

Original von below
Es soll einfach ein Log Window sein. Allerdings kann es sein, das je nach dem, was der User so auf der Platte hat, sehr, sehr viel geloggt wird.

Ich will vermeiden, dass das zu Problemen führt.

Fertige Lösungen fallen mir da leider jetzt nicht ein, aber Du könntest vielleicht einen CustomTextStorage verwenden, welcher den Text z.B. in Blöcke aufteilt und diese Blöcke komprimiert im Speicher ablegt.

Ist für ein Log Window sicherlich recht interessant, da ja im Allgemeinen erst mal immer nur die letzten Einträge angezeigt werden. Wenn der User dann zurück scrollt, sollte die CPU schnell genug sein, die komprimierten Blöcke on-the-fly zu entpacken und den Text zur Verfügung zu stellen.

Weiterhin könntest Du auch ein NSFileWrapper im CustomTextStorage verwenden und den kompletten Log dynamisch auf der Platte halten.

Mach eine Lazy-Implementierung.

Habt Ihr schon mal eine 100MByte-Datei in TextEdit geöffnet?

Das geht sehr wohl. Und dass Apple dafür NICHT den NSTextView verwendet glaube ich nicht.

-- hns

Ich mutmaße mal, dass der selbst lazy ist, wie etwas NSData, NSBezierPath ...

Original von below
Stimmt, das macht [myNSTextView textStorage].

Frage analog: Wie viel passt da rein?

Ich sage exakt: 2.147.483.646 Zeichen, denn NSNotFound ist als 0x7FFFFFFF (2.147.483.647)definiert. Folglich dürfte NSNotFound-1 die maximale Anzahl der zulässigen Zeichen sein. Mehr kann auf 32Bit-Systemen auch nicht gehen, da NSString ja in Unicode arbeitet und zwei Bytes pro Zeichen verwendet.

Michael

Edit: noch mal nachgedacht und die Anzahl um 1 erhöht.
Noch ein Edit: nach einem Blick in die Dokumentation Anzahl wieder um 1 erniedrigt.

Die Annahme ist nicht unkühn.

Wenn ich das so implementiert hätte, dass dort sagen wir mal 2000 Zeichen hereinpassen, dann hätte ich auch 0x7fffffff als NSNotFound gewählt. Wieso sollte ich mir für zukünftige Implementierungen das Knie wegschießen?

was spricht gegen eine nutzung über nstask und 'tail' für ein log?

Original von Tom9811
Die Annahme ist nicht unkühn.

Sie stimmt aber. Ein Blick in die Dokumentation bring Klarheit. Es gibt eine Konstante, die letztendlich auf eine Compiler interne Definition führt. Also machen wir doch einfach mal ein
Und folgendes kommt dabei bei mir raus:

Maximum string length: 2147483646

Damit ist auch die Frage beantwortet, wie man die maximale Länge abfragen kann.

Original von Tom9811
Wenn ich das so implementiert hätte, dass dort sagen wir mal 2000 Zeichen hereinpassen, dann hätte ich auch 0x7fffffff als NSNotFound gewählt.

Warum hättest Du 0x7fffffff gewählt? Warum denn nicht 0xffffffff?

Michael

Punkt 1:
Der textView speichert die Daten nicht selber.
Wie korrekt erwähnt, macht das sein NSTextStorage.
Ein NSTextView stellt nur dar (aber er zeichnet nicht!) und nimmt user-input an.

Punkt 2:
TextEdit nutzt das Cocoa Text System ohne eine einzige erweiterung.
Sprich: TextEdit zeigt dir die Performance der Default-Implementierung.
Selber (auf einen speziellen Fall) optimieren kann das ganze aber noch wesentlich beschleunigen.

Punkt 3:
Das TextSystem ist lazy.
Öffnet mal einen laaaangen Text in TextEdit. Der wird erst mit der Zeit fertig ausgelegt und dann gerendert. Erkennt man an der schrumpfenden Scrollbar.

Punkt 4:
Für einen Logger würde ich an deiner Stelle einen NSTextStorage subclassen. Ne gute Anleitung dazu gibts auf CocoaDev.com. Und ich würde an deiner Stelle immer nur einen Teil des Logs einlesen. Das TextSystem wird bei langen Texten leicht träge, was aber auch klar ist. Veilleicht machst du dir ne fixe größe (5000 Zeichen oder so) und immer wenn was neues geschrieben wird, löschst du den alten rest. Zur not kannst du ne Kopie auch noch auf die HD schreiben. Die Konsole liest ja auch immer nur einen Teil der Log-Dateien ein, kann man sogar einstellen, wie viele KB.

HTH

Max

Ob eine maximum String-Length tatsächlich die maximalen Fähigkeiten eines ganzen Textsystems beschreibt?

Ich hätte übrigens ein "vorzeichenbehaftes Maximum" gewählt, um nicht für alle Ewigkeiten allen Nutzern in allen Fällen zu verbieten, vorzeichenbehaftete Zahlen zu verwenden. Ich verwende daher _nie_ unsigned int. Ich weiß nämlich nicht, ob der Wert irgendwann einmal irgendwo in einer Formel ein negatives Vorzeichen bekommt.

Original von Tom9811
Ob eine maximum String-Length tatsächlich die maximalen Fähigkeiten eines ganzen Textsystems beschreibt?

Selbstverständlich. Oder was glaubst Du, worauf NSTextStorage letztendlich aufbaut?

Michael

Original von Michael
Selbstverständlich. Oder was glaubst Du, worauf NSTextStorage letztendlich aufbaut?
Michael

Könnte eben so gut ein Array von Strings sein.

Und? Dass etwas aufbaut, heißt nicht, dass es eingrenzt? Weil der Text-Storage auf einem String aufbaut, kann er nicht eine Zeile enthalten wie "length << 1 / 3"? OOder sonstige Informationen im Striing unterbringen, die die netto Stringlänge eingrenzt?

Man weiß es einfach nicht. Deshalb kann man auch keine Behauptungen darüber aufstellen, sondern nur Vermutungen anstellen. Es wäre allerdings angebracht, wenn die Doku das irgendwo mal klar sagen würde.