Editor für große Textdateien
-
sed, awk, perl...
-
mein Emacs kriegt eine 75 MB Textdatei, die ich gerade mal ausprobiert habe, problemlos gebacken.
-
u_ser-l schrieb:
mein Emacs kriegt eine 75 MB Textdatei, die ich gerade mal ausprobiert habe, problemlos gebacken.
meiner ist länger :p
-
u_ser-l schrieb:
mein Emacs kriegt eine 75 MB Textdatei, die ich gerade mal ausprobiert habe, problemlos gebacken.
Geht bis 128mb, wenn ich es gerade richtig im Kopf habe (unter 32Bit).
-
Notepad2 geht bis "etliche-hundert-MB" recht gut. Alle weiteren Scintilla basierten Editoren sollten auch gehen.
z.T. 128MB...: das ist ja Kinderkacke
-
hustbaer schrieb:
z.T. 128MB...: das ist ja Kinderkacke
Es sind 256MB auf 32Bit-Systemen. Aber wer verwendet denn heutzutage noch 32Bit-Systeme?
-
nman schrieb:
hustbaer schrieb:
z.T. 128MB...: das ist ja Kinderkacke
Es sind 256MB auf 32Bit-Systemen. Aber wer verwendet denn heutzutage noch 32Bit-Systeme?
80%?
MfG SideWinder
-
SideWinder schrieb:
nman schrieb:
hustbaer schrieb:
z.T. 128MB...: das ist ja Kinderkacke
Es sind 256MB auf 32Bit-Systemen. Aber wer verwendet denn heutzutage noch 32Bit-Systeme?
80%?
MfG SideWinder
80% von was? Von allen Nutzern? Unfair... man sollte nur die zählen, die Textdateien >256MB öffnen wollen... da dürfte die Zahl anders aussehen
-
SideWinder schrieb:
nman schrieb:
hustbaer schrieb:
z.T. 128MB...: das ist ja Kinderkacke
Es sind 256MB auf 32Bit-Systemen. Aber wer verwendet denn heutzutage noch 32Bit-Systeme?
80%?
MfG SideWinder
ich bezweifle dass 80% aller pc-benutzer cpu's benutzt, die vor 2004 gebaut worden sind. wenn man allerdings die zählt, die immer noch an 32-bit software festhalten, kommt das wohl so in ungefähr hin.
-
Welche CPU verbaut ist, ist doch irrelevant, solange ein 32-Bit-OS eingesetzt wird.
-
_matze schrieb:
Welche CPU verbaut ist, ist doch irrelevant, solange ein 32-Bit-OS eingesetzt wird.
habe ich irgendwas anderes behauptet?
-
sothis_ schrieb:
_matze schrieb:
Welche CPU verbaut ist, ist doch irrelevant, solange ein 32-Bit-OS eingesetzt wird.
habe ich irgendwas anderes behauptet?
Nee, eigentlich nicht.
-
zwutz schrieb:
80% von was? Von allen Nutzern? Unfair... man sollte nur die zählen, die Textdateien >256MB öffnen wollen... da dürfte die Zahl anders aussehen
Ich würde sogar noch weiter gehen: Emacs-User, die Dateien >256MB öffnen wollen. Da dürfte der Anteil nochmal _ganz_ anders aussehen.
-
Welchen Grund gibt es solche riesigen Textdateien zu öffnen und dann noch zu editieren? Logfiles?
-
Warum 256MB?
Warum so ein doofes Hardlimit?Warum kann ich nicht Dateien aufmachen die so groß wie der verfügbare Speicher sind? (abzüglich natürlich einem kleinen administrations overhead).
-
Shade Of Mine schrieb:
Warum 256MB?
Warum so ein doofes Hardlimit?Warum kann ich nicht Dateien aufmachen die so groß wie der verfügbare Speicher sind? (abzüglich natürlich einem kleinen administrations overhead).
Genau! Wenn ich die Datei speichern kann, dann soll ich sie auch bearbeiten können!
-
Shade Of Mine schrieb:
Warum 256MB?
Warum so ein doofes Hardlimit?Warum kann ich nicht Dateien aufmachen die so groß wie der verfügbare Speicher sind? (abzüglich natürlich einem kleinen administrations overhead).
Weil der entsprechende Code uralt ist. 1994 waren 256MB noch ziemlich groß.
Und mittlerweile gibt es seit vielen Jahren bestens funktionierende 64Bit-Versionen, dh. niemand interessiert sich für dieses Limit. Der 64Bit-Emacs hat ohnehin schon eine maximale Buffer-Size von 2^59 oder so, dh. man bewegt sich in Größenordnungen von einem halben Exabyte, wenn ich das richtig überschlagen habe. Sollte also wieder für ein paar Jahre reichen.
Der Grund dafür liegt irgendwie in der Implementierung von Point und Mark, das sind elisp-Integers, die nur relativ klein sein können. XEmacs hatte da irgendeinen ziemlich widerlichen Workaround, mit dem man auf 32Bit-Systemen Buffer bis zu 2GB bearbeiten kann, aber die Implementierung war ziemlich schauderhaft.
Ach ja, wenn ich von Emacs rede, meine ich normalerweise den GNU Emacs, da das die Implementierung meiner Wahl ist; keine Ahnung, wie das andere Emacse handhaben.
-
nman schrieb:
Der Grund dafür liegt irgendwie in der Implementierung von Point und Mark, das sind elisp-Integers, die nur relativ klein sein können.
Das ist sicher wegen der Type-Tags. 256 MB ist 1/8 von 2GB, also gehen von 32 wohl 3 Bits für den Typ und 1 Bit fürs Vorzeichen drauf, das klingt plausibel.
-
Bashar schrieb:
nman schrieb:
Der Grund dafür liegt irgendwie in der Implementierung von Point und Mark, das sind elisp-Integers, die nur relativ klein sein können.
Das ist sicher wegen der Type-Tags. 256 MB ist 1/8 von 2GB, also gehen von 32 wohl 3 Bits für den Typ und 1 Bit fürs Vorzeichen drauf, das klingt plausibel.
Ja, genauso war das.
Dachte mir nur, dass das für Nicht-Lisper eher uninteressant ist.
Habe übrigens gerade nachgelesen, weil mich interessiert hat, wie die 59Bit bei 64Bit-Systemen zustande kamen und herausgefunden, dass (a) XEmacs nur 1GB-Buffer unterstützt (2^30 = 2^(32 - Minimal-Tagbit - Sign-Bit)) und (b) es durchaus sein könnte, dass ich mich geirrt habe und GNU Emacs sogar 2^60-1 Bytes unterstützt, müsste mal in den Sourcen nachlesen um das zu überprüfen, weiß nicht, wie Elisp-Type-Tags im Detail implementiert sind.
-
nman schrieb:
Dachte mir nur, dass das für Nicht-Lisper eher uninteressant ist.
Aber vielleicht besser für Shades Blutdruck
